Re: [v5.15 Regression] block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART

[Joseph Salisbury]

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!