qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/2] file-posix: fix Linux alignment probing when EIO is r


From: Kevin Wolf
Subject: Re: [PATCH v2 1/2] file-posix: fix Linux alignment probing when EIO is returned
Date: Fri, 11 Nov 2022 12:08:36 +0100

Am 03.11.2022 um 19:36 hat Stefan Hajnoczi geschrieben:
> Linux v6.0 dm-crypt returns errno EIO from unaligned O_DIRECT pread(2)
> calls. Alignment probing fails on dm-crypt devices because the code
> expects EINVAL. This is a kernel regression that is expected to be fixed
> upstream:
> https://lore.kernel.org/linux-block/20221103193837.3b5b4bac@xps.demsh.org/T/#t
> 
> Treating any errno as an "unaligned" indicator would be easy, but breaks
> commit 22d182e82b4b ("block/raw-posix: fix launching with failed
> disks"). Offline disks return EIO for correctly aligned requests and
> EINVAL for unaligned requests.
> 
> It's possible to make both v6.0 dm-crypt and offline disks work: look
> for the transition from EINVAL to EIO instead of for a single EINVAL
> value.
> 
> Buglink: https://gitlab.com/qemu-project/qemu/-/issues/1290
> Fixes: 22d182e82b4b ("block/raw-posix: fix launching with failed disks")
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

I haven't tested it myself, but from the comments in the bug tracker and
on the mailing this, I don't think this can actually distinguish the two
cases: AIUI, even with the buggy dm-crypt, you get a transition from
EINVAL to EIO because everything < 512 (such as our first probed value
1) will still return EINVAL.

So even with this patch, I think we would still probe the incorrect
512 bytes when the dm-crypt bug is present.

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]