linux-kernel - Re: [PATCHv3 0/8] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <bqfazli7us3afm5opm5c6ntrblw2tekshd7ohf7nqagyoauwd7@6biytmjbkqgz>
Date: Mon, 1 Sep 2025 10:22:20 +0200
From: Jan Kara <jack@...e.cz>
To: Keith Busch <kbusch@...nel.org>
Cc: Jan Kara <jack@...e.cz>, Ritesh Harjani <ritesh.list@...il.com>, 
	Keith Busch <kbusch@...a.com>, linux-block@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org, snitzer@...nel.org, axboe@...nel.dk, 
	dw@...idwei.uk, brauner@...nel.org, hch@....de, martin.petersen@...cle.com, 
	djwong@...nel.org, linux-xfs@...r.kernel.org, viro@...iv.linux.org.uk, 
	Jan Kara <jack@...e.com>, Brian Foster <bfoster@...hat.com>
Subject: Re: [PATCHv3 0/8] direct-io: even more flexible io vectors

On Wed 27-08-25 13:20:56, Keith Busch wrote:
> On Wed, Aug 27, 2025 at 05:20:53PM +0200, Jan Kara wrote:
> > Now both the old and new behavior make some sense so I won't argue that the
> > new iomap_iter() behavior is wrong. But I think we should change ext4 back
> > to the old behavior of failing unaligned dio writes instead of them falling
> > back to buffered IO. I think something like the attached patch should do
> > the trick - it makes unaligned dio writes fail again while writes to holes
> > of indirect-block mapped files still correctly fall back to buffered IO.
> > Once fstests run completes, I'll do a proper submission...
> 
> Your suggestion looks all well and good, but I have a general question
> about fstests. I've written up some to test this series, and I have
> filesystem specific expectations for what should error or succeed. If
> you modify ext4 to fail direct-io as described, my test will have to be
> kernel version specific too. Is there a best practice in fstests for
> handling such scenarios?

Well, I'd just expect EINVAL for ext4 in the test. Certain kernel versions
(since February or so) will fail but that's just an indication you should
backport the fix if you care...

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