From: Joseph Salisbury <joseph.salisbury@canonical.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: hch@lst.de, linux-kernel@vger.kernel.org,
linux-block@vger.kernel.org, axboe@kernel.dk, sashal@kernel.org,
stable@vger.kernel.org,
Francis Ginther <francis.ginther@canonical.com>
Subject: Re: [v5.15 Regression] block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART
Date: Thu, 4 Apr 2024 11:02:50 -0400 [thread overview]
Message-ID: <b167caba-0e6c-4f95-9ade-76d352f9e676@canonical.com> (raw)
In-Reply-To: <2024040407-bucket-sank-25a4@gregkh>
On 4/4/24 01:13, Greg KH wrote:
> On Wed, Apr 03, 2024 at 08:40:00PM +0200, Greg KH wrote:
>> On Wed, Apr 03, 2024 at 02:06:28PM -0400, Joseph Salisbury wrote:
>>>
>>> On 4/3/24 13:54, Greg KH wrote:
>>>> On Wed, Apr 03, 2024 at 01:50:09PM -0400, Joseph Salisbury wrote:
>>>>> Hi Christoph,
>>>>>
>>>>> A kernel bug report was opened against Ubuntu [0]. This bug is a regression
>>>>> introduced in mainline version v5.17-rc1 and made it's way into v5.15 stable
>>>>> updates.
>>>>>
>>>>> The following commit was identified as the cause of the regression in 5.15:
>>>>>
>>>>> c6ce1c5dd327 ("block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART")
>>>> How is renaming a define a "regression"?
>>> The "regression" is experienced after upgrading to the kernel to the version
>>> that introduced this commit.
>>> The v5.15.131 kernel works as expected, upgrading the kernel to v5.15.132
>>> breaks behavior that worked in a prior kernel version.
>>> Reverting commit c6ce1c5dd327 in v5.15.132 allows the experience to be as
>>> before in v5.15.131.
>> What "experience" are you talking about here? Please be specific. What
>> exactly "broke", what is the build error that happens?
>>
>>>>> I was hoping to get your feedback, since you are the patch author. Is the
>>>>> best approach to revert this commit, since many third parties rely on the
>>>>> name being GENHD_FL_NO_PART_SCAN in kernel headers?
>>>> External kernel modules are never an issue. Is this a userspace thing?
>>>>
>>>>> Is there a specific need that you know of that requires this commit
>>>>> in the 5.15 and earlier stable kernels?
>>>> Yes. And Christoph did not do the backport, so I doubt he cares :)
>>>>
>>>> Again, what in-kernel issue is caused by this?
>>> Third party code that relies on the kernel-headers will no longer compile
>>> due to the name change. Should we not care if we break things, even in
>>> userspace?
>> Is this userspace, or is it kernel drivers?
>>
>> If kernel drivers, you know that there s no stable kernel api, we
>> rename and change things all the time, even in stable kernel trees, for
>> good reasons (see the set of patches that were applied that contained
>> this change.) Do you want to have unfixed security issues, or do you
>> want a secure kernel that happens to rename variables at times?
> Given the lack of response, I am going to assume that this means you are
> referring to out-of-tree kernel code and this is not a real "regression"
> at all.
>
> greg k-h
I now know that the kernel internal interface changes all the time in
stable, and it cannot take into account out of tree modules. I will
always keep this in mind in the future. Thanks for all the assistance!
next prev parent reply other threads:[~2024-04-04 15:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-03 17:50 [v5.15 Regression] block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART Joseph Salisbury
2024-04-03 17:54 ` Greg KH
2024-04-03 18:06 ` Joseph Salisbury
2024-04-03 18:40 ` Greg KH
2024-04-04 5:13 ` Greg KH
2024-04-04 15:02 ` Joseph Salisbury [this message]
2024-04-03 18:05 ` Christoph Hellwig
2024-04-03 18:10 ` Joseph Salisbury
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b167caba-0e6c-4f95-9ade-76d352f9e676@canonical.com \
--to=joseph.salisbury@canonical.com \
--cc=axboe@kernel.dk \
--cc=francis.ginther@canonical.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).