On Thu, Nov 03, 2022 at 10:52:43AM +0100, Kevin Wolf wrote: > Am 02.11.2022 um 03:49 hat Eric Biggers geschrieben: > > On Tue, Nov 01, 2022 at 07:27:16PM -0700, Eric Biggers wrote: > > > On Tue, Nov 01, 2022 at 03:00:30PM -0400, Stefan Hajnoczi wrote: > > > > Linux dm-crypt returns errno EIO from unaligned O_DIRECT pread(2) calls. > > > > > > Citation needed. For direct I/O to block devices, the kernel's block > > > layer > > > checks the alignment before the I/O is actually submitted to the > > > underlying > > > block device. See > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/block/fops.c?h=v6.1-rc3#n306 > > > > > > > Buglink: https://gitlab.com/qemu-project/qemu/-/issues/1290 > > > > > > That "bug" seems to be based on a misunderstanding of the kernel source > > > code, > > > and not any actual testing. > > > > > > I just tested it, and the error code is EINVAL. > > > > > > > I think I see what's happening. The kernel code was broken just a few > > months > > ago, in v6.0 by the commit "block: relax direct io memory alignment" > > (https://git.kernel.org/linus/b1a000d3b8ec582d). Now the block layer lets > > DIO > > through when the user buffer is only aligned to the device's dma_alignment. > > But > > a dm-crypt device has a dma_alignment of 512 even when the crypto sector > > size > > (and thus also the logical block size) is 4096. So there is now a case > > where > > misaligned DIO can reach dm-crypt, when that shouldn't be possible. > > > > It also means that STATX_DIOALIGN will give the wrong value for > > stx_dio_mem_align in the above case, 512 instead of 4096. This is because > > STATX_DIOALIGN for block devices relies on the dma_alignment. > > In other words, STATX_DIOALIGN is unusable from the start because we > don't know whether the information it returns is actually correct? :-/ > > I guess we could still use the value returned by STATX_DIOALIGN as a > preferred value that we'll use if it survives probing, and otherwise > fall back to the same probing we've always been doing because there was > no (or no sane) way to get the information from the kernel.
Yes, it seems probing is required to verify the values returned by STATX_DIOALIGN. At least until enough time passes so we can say "STATX_DIOALIGN has been correct for X years and no one is running those old kernels anymore". Stefan
signature.asc
Description: PGP signature