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")
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? Is there a
specific need that you know of that requires this commit in the 5.15 and
earlier stable kernels?
Thanks,
Joe
[0] http://pad.lv/2053101
Hi Joseph.
given that Canonical ignores our kernel licensing rules and tries to
get away with it I'm not going to offer any help to Canonical at all.
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.
>
>> 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?
>
> thanks,
>
> greg k-h
On 4/3/24 14:05, Christoph Hellwig wrote:
> Hi Joseph.
>
> given that Canonical ignores our kernel licensing rules and tries to
> get away with it I'm not going to offer any help to Canonical at all.
Sorry, I was trying to help the community since this is affecting
upstream stable kernels.
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?
If userspace, please point me at this and why hasn't it broken in newer
kernel releases where this change came from?
thanks,
greg k-h
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"?
> 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?
thanks,
greg k-h
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
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!