On Fri, Mar 25, 2022 at 11:46:09AM -0700, Linus Torvalds wrote:
> I think my list of three different sync cases (not just two! It's not
> just about whether to sync for the CPU or the device, it's also about
> what direction the data itself is taking) is correct.
>
> But maybe I'm wrong.
At the h
On Thu, Mar 24, 2022 at 7:46 PM Jason Gunthorpe wrote:
>
> On Thu, Mar 24, 2022 at 11:50:47AM +0800, Jason Wang wrote:
>
> > It's simply because we don't want to break existing userspace. [1]
>
> I'm still waiting to hear what exactly breaks in real systems.
>
> As I explained this is not a signif
On Sun, Mar 27, 2022 at 4:37 PM Halil Pasic wrote:
>
>
> For the record, I believe that the partial revert proposed here
> https://www.spinics.net/lists/linux-wireless/msg222300.html
> would have been a wiser choice, than a complete revert of commit
> aa6f8dcbab47 ("swiotlb: rework "fix info leak
On Sun, Mar 27, 2022 at 4:52 PM Halil Pasic wrote:
>
> 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 th
On Sat, 26 Mar 2022 22:21:03 -0700
Linus Torvalds wrote:
> 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
On Sat, 26 Mar 2022 22:06:15 -0700
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 me
On Sun, Mar 27, 2022 at 12:23 PM Linus Torvalds
wrote:
>
> So I will propose that we really make it very much about practical
> concerns, and we document things as
>
> (a) the "sync" operation has by definition a "whose _future_ access
> do we sync for" notion.
>
> So "dma_sync_single_for_cp
On Sun, Mar 27, 2022 at 8:24 AM David Laight wrote:
>
> Aren't bounce buffers just a more extreme case on non-coherent
> memory accesses?
No.
In fact, this whoe change came about exactly because bounce buffers
are different.
The difference is that bounce buffers have that (wait for it) bounce
b
From: Linus Torvalds
> Sent: 27 March 2022 06:21
>
> 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
On Sun, Mar 27, 2022 at 02:32:23AM +, Tian, Kevin wrote:
> > this looks good to me except that the 2nd patch (eab4b381) should be
> > the last one otherwise it affects bisect. and in that case the subject
> > would be simply about removing the capability instead of
> > restoring...
Oh because
The bug is here:
if (!iommu || iommu->dev->of_node != spec->np) {
The list iterator value 'iommu' will *always* be set and non-NULL by
list_for_each_entry(), so it is incorrect to assume that the iterator
value will be NULL if the list is empty or no element is found (in fact,
it will poin
11 matches
Mail list logo
