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: <20251105214407.GN196362@frogsfrogsfrogs>
Date: Wed, 5 Nov 2025 13:44:07 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
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

On Wed, Nov 05, 2025 at 03:11:30PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 04, 2025 at 03:38:24PM -0800, Darrick J. Wong wrote:
> > IIRC, a PI disk is supposed to check the supplied CRC against the
> > supplied data, and fail the write if there's a discrepancy, right?
> 
> Yes.
> 
> > In
> > that case, an application can't actually corrupt its own data because
> > hardware will catch it.
> 
> Yes.
> 
> > A. We can allow mutant directio to non-PI devices because buggy programs
> >    can only screw themselves over.  Not great but we've allowed this
> >    forever.
> >
> > B. We can also allow it to PI devices because those buggy programs will
> >    get hit with EIOs immediately.
> 
> Well, those "buggy programs" include qemu and probably others.  Which
> immediately limits the usefulness of operating with PI.
> 
> This also does not help with non-PI checksums - one thing my RFC series
> did is to allow storing checksums in non-PI metadata, which is useful
> for devices that are too cheap for PI, but still provide metadata.  These
> do exist, although are not very wide spread, and this will require an
> on-disk flag in XFS, so it's not right there.  But compared to all the
> others methods to provide checksums, block metdata is by far the best,
> so I'll keep it on the agenda in the hope that such devices become
> more prelevant.
> 
> > I wonder if that means we really need a way to convey the potential
> > damage of a mutant write through the block layer / address space so that
> > the filesystem can do the right thing?  IOWs, instead of a single
> > stable-pages flag, something along the lines of:
> 
> Maybe, I actually suggested this earlier.  But breaking the biggest user
> of direct I/O (qemu) by default once we have checksums still feels like a
> losing proposition.

Just out of curiosity -- is qemu itself mutating the buffers that it is
passing down to the lower levels via dio?  Or is it a program in the
guest that's mutating buffers that are submitted for dio, which then get
zerocopied all the way down to the hypervisor?

(But yeah, I'm coming back around to the notion that the dio ->
dontcache transition is needed for all of the PI/raid cases...)

--D