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: <aRb2g3VLjz1Q_rLa@redhat.com>
Date: Fri, 14 Nov 2025 10:29:39 +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 06:39 hat Christoph Hellwig geschrieben:
> On Thu, Nov 13, 2025 at 06:39:07PM +0100, Kevin Wolf wrote:
> > > A complication is that PI could relax that requirement if we support
> > > PI passthrough from userspace (currently only for block device, but I
> > > plan to add file system support), where the device checks it, but we
> > > can't do that for parity RAID.
> > 
> > Not sure I understand the problem here. If it's passed through from
> > userspace, isn't its validity the problem of userspace, too? I'd expect
> > that you only need a bounce buffer in the kernel if the kernel itself
> > does something like a checksum calculation?
> 
> Yes, the PI validity is a userspace problem.  But if you then also use
> software RAID (right now mdraid RAID5/6 does not support PI, so that's a
> theoretical case), a (potentially malicious) modification of in-flight
> data could still corrupt data in another stripe.  So we'd still have to
> bounce buffer for user passed PI when using parity RAID below, but not
> when just sending on the PI to a device (which also checks the validity
> and rejects the I/O).

Right, but since this is direct I/O and the approach with only declaring
I/O from the page cache safe without a bounce buffer means that RAID has
to use a bounce buffer here anyway (with or without PI), doesn't this
automatically solve it?

So if it's only PI, it's the problem of userspace, and if you add RAID
on top, then the normal rules for RAID apply. (And that the buffer
doesn't get modified and PI doesn't become invalid until RAID does its
thing is still a userspace problem.)

Kevin