Hi On Tue, 1 Nov 2022, Eric Biggers wrote: > Hi, > > I happened to notice the following QEMU bug report: > > https://gitlab.com/qemu-project/qemu/-/issues/1290 > > I believe it's a regression from the following kernel commit: > > commit b1a000d3b8ec582da64bb644be633e5a0beffcbf > Author: Keith Busch <kbusch@xxxxxxxxxx> > Date: Fri Jun 10 12:58:29 2022 -0700 > > block: relax direct io memory alignment I suggest to revert this patch. > The bug is that if a dm-crypt device is set up with a crypto sector size (and > thus also a logical_block_size) of 4096, then the block layer now lets through > direct I/O requests to dm-crypt when the user buffer has only 512-byte > alignment, instead of the 4096-bytes expected by dm-crypt in that case. This is > because the dma_alignment of the device-mapper device is only 511 bytes. Propagating dma_alignment through the device mapper stack would be hard (because it is not in struct queue_limits). Perhaps we could set dma_alignment to be the equivalent to logical_block_size, if the above patch could not be reverted - but the we would hit the issue again when someone stacks md or other devices over dm. > This has two effects in this case: > > - The error code for DIO with a misaligned buffer is now EIO, instead of > EINVAL as expected and documented. This is because the I/O reaches > dm-crypt instead of being rejected by the block layer. > > - STATX_DIOALIGN reports 512 bytes for stx_dio_mem_align, instead of the > correct value of 4096. (Technically not a regression since STATX_DIOALIGN > is new in v6.1, but still a bug.) > > Any thoughts on what the correct fix is here? Maybe the device-mapper layer > needs to set dma_alignment correctly? Or maybe the block layer needs to set it > to 'logical_block_size - 1' by default? > > - Eric > > -- > dm-devel mailing list > dm-devel@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/dm-devel Mikulas -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
