Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Linus Torvalds
On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds wrote: > > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic 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

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Linus Torvalds
On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic 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

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Halil Pasic
On Thu, 24 Mar 2022 12:26:53 -0700 Linus Torvalds wrote: > So I don't think the dma_sync_single_for_device() is *wrong* per se, > because the CPU didn't actually do any modifications. > > But yes, I think it's unnecessary - because any later CPU accesses > would need that

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Halil Pasic
On Fri, 25 Mar 2022 22:13:08 +0100 Johannes Berg wrote: > > > Then, however, we need to define what happens if you pass > > > DMA_BIDIRECTIONAL to the sync_for_cpu() and sync_for_device() functions, > > > which adds two more cases? Or maybe we eventually just think that's not > > > valid at all,

RE: [PATCH RFC 08/12] iommufd: IOCTLs for the io_pagetable

2022-03-26 Thread Tian, Kevin
> From: Tian, Kevin > Sent: Friday, March 25, 2022 10:16 AM > > > From: Jason Gunthorpe > > Sent: Thursday, March 24, 2022 9:46 PM > > > > On Thu, Mar 24, 2022 at 07:25:03AM +, Tian, Kevin wrote: > > > > > Based on that here is a quick tweak of the force-snoop part (not > compiled). > > > >

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Linus Torvalds
On Sat, Mar 26, 2022 at 3:38 PM David Laight wrote: > > Is the idea of 'buffer ownership' even a good one? I do think it might be best to not think in those terms, but literally just in data movement terms. Because the "buffer ownership" mental model is clearly confused, when data transfer

RE: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread David Laight
From: Linus Torvalds > Sent: 26 March 2022 18:39 > > On Sat, Mar 26, 2022 at 9:06 AM Toke Høiland-Jørgensen wrote: > > > > I was also toying with the idea of having a copy-based peek helper like: > > > > u32 data = dma_peek_word(buf, offset) > > I really don't think you can or want to have a

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Linus Torvalds
On Sat, Mar 26, 2022 at 9:06 AM Toke Høiland-Jørgensen wrote: > > I was also toying with the idea of having a copy-based peek helper like: > > u32 data = dma_peek_word(buf, offset) I really don't think you can or want to have a word-based one. That said, I like the *name* of that thing. I

Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP

2022-03-26 Thread Toke Høiland-Jørgensen via iommu
Halil Pasic writes: > On Fri, 25 Mar 2022 11:27:41 + > Robin Murphy wrote: > >> What muddies the waters a bit is that the opposite combination >> sync_for_cpu(DMA_TO_DEVICE) really *should* always be a no-op, and I for >> one have already made the case for eliding that in code elsewhere,