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: <5ef0ac71-21dd-46d7-a0c1-1b1b391e51a8@leemhuis.info>
Date: Wed, 24 Apr 2024 10:09:35 +0200
From: "Linux regression tracking (Thorsten Leemhuis)"
 <regressions@...mhuis.info>
To: Jens Axboe <axboe@...nel.dk>
Cc: Christoph Hellwig <hch@....de>, Keith Busch <kbusch@...nel.org>,
 Linux regressions mailing list <regressions@...ts.linux.dev>,
 linux-block@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
 Lennart Poettering <mzxreary@...inter.de>
Subject: Re: API break, sysfs "capability" file

On 16.04.24 16:33, Jens Axboe wrote:
> On 4/16/24 8:25 AM, Lennart Poettering wrote:
>> On Di, 16.04.24 08:22, Jens Axboe (axboe@...nel.dk) wrote:
>>> On 4/16/24 8:18 AM, Lennart Poettering wrote:
>>>> On Di, 09.04.24 09:17, Jens Axboe (axboe@...nel.dk) wrote:
>>>>
>>>>> On 4/9/24 8:15 AM, Christoph Hellwig wrote:
>>>>>> On Tue, Apr 09, 2024 at 10:19:09AM +0200, Lennart Poettering wrote:
>>>>>>> All I am looking for is a very simple test that returns me a boolean:
>>>>>>> is there kernel-level partition scanning enabled on this device or
>>>>>>> not.
>>>>>> And we can add a trivial sysfs attribute for that.
>>>>>
>>>>> And I think we should. I don't know what was being smoked adding a sysfs
>>>>> interface that exposed internal flag values - and honestly what was
>>>>> being smoked to rely on that, but I think it's fair to say that the
>>>>> majority of the fuckup here is on the kernel side.
> [...]
> Doesn't really change my conclusion from earlier. As mentioned, this is
> clearly a kernel fuckup, and honestly since it's being presented as ABI,
> we definitely need to rectify this and provide an alternative. Even
> though I'm not a huge fan of it, might just be best to re-introduce
> 'capability' and just have conversions of the flags so we retain the
> user side of it the same. That can then also go into stable, so we'll
> end up with something that at least looks cohesive on the user side.

Jens, quick question: what's the plan forward here and who will realize
what you outlined?

I'm asking, as afaics nothing happened for a week (hope I didn't miss
anything!). Sure, it's not a regression from the last cycle or so, so
it's not that urgent. But hch's "It is not a regression at all" last
week made me worry that this in the end might not be solved unless
somebody has it on the todo list. Normally I would have CCed Linus at
that point anyway to get his stance, but from your statements it sounds
like this is unnecessary here.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ