linux-kernel - Re: fall back from direct to buffered I/O when stable writes are required

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: <20251114153644.GA31395@lst.de>
Date: Fri, 14 Nov 2025 16:36:44 +0100
From: Christoph Hellwig <hch@....de>
To: Kevin Wolf <kwolf@...hat.com>
Cc: Christoph Hellwig <hch@....de>, Jan Kara <jack@...e.cz>,
	Keith Busch <kbusch@...nel.org>, Dave Chinner <david@...morbit.com>,
	Carlos Maiolino <cem@...nel.org>,
	Christian Brauner <brauner@...nel.org>,
	"Martin K. Petersen" <martin.petersen@...cle.com>,
	linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-raid@...r.kernel.org,
	linux-block@...r.kernel.org
Subject: Re: fall back from direct to buffered I/O when stable writes are
 required

On Fri, Nov 14, 2025 at 01:31:20PM +0100, Kevin Wolf wrote:
> My main point above was that RAID and (potentially passed through) PI
> are independent of each other and I think that's still true with or
> without multiple stability levels.
> 
> If you don't have these levels, you just have to treat level 1 and 2 the
> same, i.e. bounce all the time if the kernel needs the guarantee (which
> is not for userspace PI, unless the same request needs the bounce buffer
> for another reason in a different place like RAID). That might be less
> optimal, but still correct and better than what happens today because at
> least you don't bounce for level 0 any more.

Agreed.

> If there is something you can optimise by delegating the responsibility
> to userspace in some cases - like you can prove that only the
> application itself would be harmed by doing things wrong - then having
> level 1 separate could certainly be interesting. In this case, I'd
> consider adding an RWF_* flag for userspace to make the promise even
> outside PI passthrough. But while potentially worthwhile, it feels like
> this is a separate optimisation from what you tried to address here.

Agreed as well.

In fact I'm kinda lost what we're even arguing about :)