On Sat, 26 Mar 2022 22:21:03 -0700 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic <pasic@xxxxxxxxxxxxx> wrote: > > > > > > I agree it CPU modified buffers *concurrently* with DMA can never work, > > > and I believe the ownership model was conceived to prevent this > > > situation. > > > > But that just means that the "ownership" model is garbage, and cannot > > handle this REAL LIFE situation. > > Just to clarify: I obviously agree that the "both sides modify > concurrently" obviously cannot work with bounce buffers. > > People still do want to do that, but they'll limit themselves to > actual cache-coherent DMA when they do so (or do nasty uncached > accesses but at least no bounce buffering). Thanks for the explanation! > > But the "bounce ownership back and forth" model comes up empty when > the CPU wants to read while the DMA is still going on. And that not > only can work, but *has* worked. > > You could have a new "get me a non-ownership copy" operation of > course, Yes, https://www.spinics.net/lists/linux-wireless/msg222442.html was mostly about exploring that idea. > but that hits the problem of "which existing drivers need it?" > > We have no idea, outside of ath9k. > > This is why I believe we have to keep the existing semantics in a way > that keep ath9k - and any number of unknown other drivers - happy. I agree. > > And then for the cases where you want to introduce the zeroing because > you don't know how much data the DMA returned - those are the ones > you'll have to mark some way. I have no intention of pursuing this. When fixing the information leak, I happened to realize, that a somewhat similar situation can emerge when mappings are reused. It seemed like an easy fix, so I asked the swiotlb maintainers, and they agreed. It ain't my field of expertise, and the drivers I'm interested in don't need this functionality. Regards, Halil > > Linus
