On Wed, Nov 02, 2022 at 02:45:10PM -0400, Mikulas Patocka wrote: > 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. I hope we can make that option a last resort. > > 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. It looks straight forward to relocate the attribute to the the queue_limits. If it stacks correctly, then no one would encounter a problem no matter what md/dm combination you have. I have something that looks promising, but I'm trying to give it a thorough test before sending out another incomplete patch. Hopefully ready by end of the day. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
