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] [day] [month] [year] [list]

Message-ID: <aRdfFRw1vKUHXqIg@redhat.com>
Date: Fri, 14 Nov 2025 17:55:49 +0100
From: Kevin Wolf <kwolf@...hat.com>
To: Christoph Hellwig <hch@....de>
Cc: 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

Am 14.11.2025 um 16:36 hat Christoph Hellwig geschrieben:
> 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 :)

Probably nothing then. :-) I was just confused because you called PI
passthrough from userspace a complication, but it seems we agree that
there is no real complication in the sense that it's hard to get
correct and the approach can be implemented just like that.

That's really why I posted in the first place, to agree with you that
this approach seems best to me, and because I don't want to see our
O_DIRECT requests silently fall back to buffered I/O in more cases,
especially with AIO.

Kevin