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: <zqnjwqiqjhtr74ixaaqwm3vxyfyhzln3a7vbol3z4qmyebryar@v42uqt4lnmxh>
Date: Thu, 30 Oct 2025 13:54:53 +0100
From: Jan Kara <jack@...e.cz>
To: Geoff Back <geoff@...onlair.co.uk>
Cc: Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@....de>, 
	Carlos Maiolino <cem@...nel.org>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	"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 Thu 30-10-25 12:00:26, Geoff Back wrote:
> On 30/10/2025 11:20, Dave Chinner wrote:
> > On Wed, Oct 29, 2025 at 08:15:01AM +0100, Christoph Hellwig wrote:
> >> Hi all,
> >>
> >> we've had a long standing issue that direct I/O to and from devices that
> >> require stable writes can corrupt data because the user memory can be
> >> modified while in flight.  This series tries to address this by falling
> >> back to uncached buffered I/O.  Given that this requires an extra copy it
> >> is usually going to be a slow down, especially for very high bandwith
> >> use cases, so I'm not exactly happy about.
> > How many applications actually have this problem? I've not heard of
> > anyone encoutnering such RAID corruption problems on production
> > XFS filesystems -ever-, so it cannot be a common thing.
> >
> > So, what applications are actually tripping over this, and why can't
> > these rare instances be fixed instead of penalising the vast
> > majority of users who -don't have a problem to begin with-?
> I don't claim to have deep knowledge of what's going on here, but if I
> understand correctly the problem occurs only if the process submitting
> the direct I/O is breaking the semantic "contract" by modifying the page
> after submitting the I/O but before it completes.  Since the page
> referenced by the I/O is supposed to be immutable until the I/O
> completes, what about marking the page read only at time of submission
> and restoring the original page permissions after the I/O completes? 
> Then if the process writes to the page (triggering a fault) make a copy
> of the page that can be mapped back as writeable for the process - i.e.
> normal copy-on-write behaviour - and write a once-per-process dmesg
> warning that the process broke the direct I/O "contract".  And maybe tag
> the process with a flag that forces all future "direct I/O" requests
> made by that process to be automatically made buffered?
> 
> That way, processes that behave correctly still get direct I/O, and
> those that do break the rules get degraded to buffered I/O.
> 
> Unfortunately I don't know enough to know what the performance impact of
> changing the page permissions for every direct I/O would be.

That is a fine idea and we've considered that. The trouble is this gets
quite complex because buffers may be modified not only through the
application directly writing to the buffer while the IO is in flight but
also by setting up another IO to the same buffer. As soon as you let the
first IO use the buffer, the kernel would need to block all the other IOs
to the same buffer and doing all this without providing malicious apps with
a way to deadlock the kernel by cleverly chaining IOs & buffers.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR