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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0745b44456d44d1e9fc364e5a3780d9a@AcuMS.aculab.com>
Date:   Sun, 27 Mar 2022 15:24:48 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Halil Pasic <pasic@...ux.ibm.com>
CC:     Toke Høiland-Jørgensen <toke@...e.dk>,
        Robin Murphy <robin.murphy@....com>,
        Christoph Hellwig <hch@....de>,
        Maxime Bizon <mbizon@...ebox.fr>,
        Oleksandr Natalenko <oleksandr@...alenko.name>,
        "Marek Szyprowski" <m.szyprowski@...sung.com>,
        Kalle Valo <kvalo@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "Paolo Abeni" <pabeni@...hat.com>,
        Olha Cherevyk <olha.cherevyk@...il.com>,
        iommu <iommu@...ts.linux-foundation.org>,
        linux-wireless <linux-wireless@...r.kernel.org>,
        Netdev <netdev@...r.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        stable <stable@...r.kernel.org>
Subject: RE: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break
 ath9k-based AP

From: Linus Torvalds
> Sent: 27 March 2022 06:21
> 
> On Sat, Mar 26, 2022 at 10:06 PM Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > On Sat, Mar 26, 2022 at 8:49 PM Halil Pasic <pasic@...ux.ibm.com> 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.

Aren't bounce buffers just a more extreme case on non-coherent
memory accesses?
They just need explicit memory copies rather than just cache
writeback and invalidate operations.

So 'both sides modify concurrently' just has the same issue
as it does with non-coherent memory in that the locations
need to be in separate (dma) cache lines.
Indeed, if the bounce buffers are actually coherent then
arbitrary concurrent updates are possible.

One issue is that the driver needs to indicate which parts
of any buffer are dirty.
Whereas the any 'cache writeback' request will only write
dirty data.

Get everything right and you can even support hardware where
the 'bounce buffers' are actually on the card and the copies
are MMIO (or better, especially on PCIe, synchronous host
initiated dma transfers).

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)