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: <20251105141130.GB22325@lst.de>
Date: Wed, 5 Nov 2025 15:11:30 +0100
From: Christoph Hellwig <hch@....de>
To: "Darrick J. Wong" <djwong@...nel.org>
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 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.