linux-ext4 - Re: [PATCHv4 5/8] iomap: simplify direct io validity check

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: <aP-hByAKuQ7ycNwM@kbusch-mbp>
Date: Mon, 27 Oct 2025 10:42:47 -0600
From: Keith Busch <kbusch@...nel.org>
To: Carlos Llamas <cmllamas@...gle.com>
Cc: Keith Busch <kbusch@...a.com>, linux-block@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-xfs@...r.kernel.org,
	linux-ext4@...r.kernel.org, hch@....de, axboe@...nel.dk,
	Hannes Reinecke <hare@...e.de>,
	"Martin K. Petersen" <martin.petersen@...cle.com>
Subject: Re: [PATCHv4 5/8] iomap: simplify direct io validity check

On Mon, Oct 27, 2025 at 04:25:10PM +0000, Carlos Llamas wrote:
> Hey Keith, I'be bisected an LTP issue down to this patch. There is a
> O_DIRECT read test that expects EINVAL for a bad buffer alignment.
> However, if I understand the patchset correctly, this is intentional
> move which makes this LTP test obsolete, correct?
> 
> The broken test is "test 5" here:
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/read/read02.c
> 
> ... and this is what I get now:
>   read02.c:87: TFAIL: read() failed unexpectedly, expected EINVAL: EIO (5)

Yes, the changes are intentional. Your test should still see the read
fail since it looks like its attempting a byte aligned memory offset,
and most storage controllers don't advertise support for byte aligned
DMA. So the problem is that you got EIO instead of EINVAL? The block
layer that finds your misaligned address should have still failed with
EINVAL, but that check is deferred to pretty low in the stack rather
than preemptively checked as before. The filesystem may return a generic
EIO in that case, but not sure. What filesystem was this using?