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: <20251030143550.GB31550@lst.de>
Date: Thu, 30 Oct 2025 15:35:50 +0100
From: Christoph Hellwig <hch@....de>
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, Oct 30, 2025 at 12:00:26PM +0000, Geoff Back wrote:
> 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.

Except that there never has been any such "contract", written or
unwritten.  Modifying in-flight I/O is perfectly fine IFF the data
is sampled once as in the usual non-checksum non-RAID mode, and nothing
ever told applications not to do it.

>   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".

That would be nice, but also pretty hard.  See various previous
discussions on this topic.  Also at least for small I/O it probably
is more expensive than bounce buffering while for large enough I/O,
especially using PMD mappings or similar avoiding the copy will be
very beneficial.