From: Paul Burton <paul.burton@xxxxxxxxxx> Date: Tue, 26 Sep 2017 11:48:19 -0700 >> The device writes into only the bytes it was given access to, which >> starts at the DMA address. > > OK - still fine but *only* if we don't write to anything that happens to be > part of the cache lines that are only partially covered by the DMA mapping & > make them dirty. If we do then any writeback of those lines will clobber data > the device wrote, and any invalidation of them will discard data the CPU > wrote. > > How would you have us ensure that such writes don't occur? > > This really does not feel to me like something to leave up to drivers without > any means of checking or enforcing correctness. The requirement to align DMA > mappings at cache-line boundaries, as outlined in Documentation/DMA-API.txt, > allows this to be enforced. If you want to ignore this requirement then there > is no clear way to verify that we aren't writing to cache lines involved in a > DMA transfer whilst the transfer is occurring, and no sane way to handle those > cache lines if we do. The memory immediately before skb->data and immediately after skb->data+skb->len will not be accessed. This is guaranteed. I will request something exactly one more time to give you the benfit of the doubt that you want to show me why this is _really_ a problem and not a problem only in theory. Please show me an exact sequence, with current code, in a current driver that uses the DMA API properly, where corruption really can occur. The new restriction is absolutely not reasonable for this use case. It it furthermore impractical to require the 200+ drivers the use this technique to allocate and map networking buffers to abide by this new rule. Many platforms with even worse cache problems that MIPS handle this just fine. Thank you.
