On Mon, Oct 14, 2024 at 09:41:51AM +0200, Christoph Hellwig wrote: > On Mon, Oct 14, 2024 at 09:23:14AM +0200, Hannes Reinecke wrote: > >> 3) some storage utilities > >> - dm thin provisioning utility of thin_check > >> - `dt`(https://github.com/RobinTMiller/dt) > >> > >> I looks like same user buffer is used in more than 1 dio. > >> > >> 4) some self cooked test code which does same thing with 1) > >> > >> In storage stack, the buffer provider is far away from the actual DMA > >> controller operating code, which doesn't have the knowledge if > >> DMA_ATTR_SKIP_CPU_SYNC should be set. > >> > >> And suggestions for avoiding this noise? > >> > > Can you check if this is the NULL page? Operations like 'discard' will > > create bios with several bvecs all pointing to the same NULL page. > > That would be the most obvious culprit. > > The only case I fully understand without looking into the details > is raid1, and that will obviously map the same data multiple times > because it writes it out multiple time. Now mapping a buffer > multiple times for a DMA_TO_DEVICE is relatively harmless in > practice as the data is transferred to the device, but it it > still breaks the dma buffer ownership model in the dma which is > really helpful to find bugs where people don't think about this > at all. Not sure if there is any good solution here. > Another related topic: Recently direct IO buffer alignment changes to just respect DMA controller alignment which is often too relax, such as dma_alignment is just 3 for many host controllers, then two direct IO buffers may cross same DMA mapping cache line. Is this one real problem? Thanks, Ming
