linux-kernel - Re: [PATCHv2 0/7] direct-io: even more flexible io vectors

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] [day] [month] [year] [list]

Message-ID: <aJNr9svJav0DgZ-E@infradead.org>
Date: Wed, 6 Aug 2025 07:51:34 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Keith Busch <kbusch@...a.com>
Cc: linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, snitzer@...nel.org, axboe@...nel.dk,
	dw@...idwei.uk, brauner@...nel.org, Keith Busch <kbusch@...nel.org>
Subject: Re: [PATCHv2 0/7] direct-io: even more flexible io vectors

Just jumping in while travelling with almost time available:  I like the
idea, but you have to be really, really careful for writes through file
systems with this.  Deferred errors happening after bio submission are
nasty and we tend to get things wrong there too often.

So this needs to come with an xfstests to actually hit the alignment
errors, including something that is not the first bio submitted.

Even with that it will change behavior quite a bit, e.g. for file
systems that can do direct I/O write without the exclusive i_rwsem will
leak newly allocated space on errors asynchronously reported through bio
completions, so you'll need to get fs maintainer buy in for that.

Given all that I'm not sure converting the legacy fs/direct-io.c path
is such a good idea as the only file systems left using it are those
that are more less unmaintained (or at least severely undermaintained).