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
