lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a0819f54-7469-4c94-b567-71f634c84ac1@canonical.com>
Date: Wed, 3 Apr 2024 14:06:28 -0400
From: Joseph Salisbury <joseph.salisbury@...onical.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: hch@....de, linux-kernel@...r.kernel.org, linux-block@...r.kernel.org,
 axboe@...nel.dk, sashal@...nel.org, stable@...r.kernel.org,
 Francis Ginther <francis.ginther@...onical.com>
Subject: Re: [v5.15 Regression] block: rename GENHD_FL_NO_PART_SCAN to
 GENHD_FL_NO_PART



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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ