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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Apr 2024 12:41:40 -0600
From: Keith Busch <kbusch@...nel.org>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Christoph Hellwig <hch@....de>,
	Lennart Poettering <lennart@...ttering.net>,
	linux-block@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Jens Axboe <axboe@...nel.dk>
Subject: Re: API break, sysfs "capability" file

On Mon, Apr 08, 2024 at 07:43:04PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> [adding the culprit's author to the loop; also CCing everyone else in
> the Signed-off-by chain and a few lists that should be in the loop, too]
> 
> On 08.04.24 17:13, Lennart Poettering wrote:
> > 
> > So this broke systemd:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e81cd5a983bb35dabd38ee472cf3fea1c63e0f23
>> 
> > We use the "capability" sysfs attr to figure out if a block device has
> > part scanning enabled or not. There seems to be no other API for
> > this. (We also use it in our test suite to see if devices match are
> > expectations, and older systemd/udev versions used to match agains it
> > from udev rules.)
> > 
> > The interface was part of sysfs, and documented:
> > 
> > https://www.kernel.org/doc/html/v5.5/block/capability.html
> > 
> > While it doesn't list the partscan bit it actually does document that
> > one is supposed to look into include/linux/genhd.h for the various
> > bits and their meanings. I'd argue that makes them API to some level.
> > 
> > Could this please be reverted? Just keeping the relevant bits (i.e. at
> > least the media change feature bit, and the part scanning bit) is
> > enough for retaining userspace compat.
> > 
> > (Please consider googling or a github code search or so before removing
> > a public API like this. This compat breakage was very much avoidable
> > with a tiny bit of googling.)

That is unfortunate wording in the sysfs description.

How were keeping in sync with the changing values before? The setting
you seem to care about is now defined in a different file, with a
different name, and with a different value. Or are you suggesting all
those things should have been stable API?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ