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: <CAHk-=wgKF5GfLXyVGDQDifh0MpMccDdmBvJBG3dt2+idCa5DzQ@mail.gmail.com>
Date:   Fri, 25 Mar 2022 11:46:09 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Toke Høiland-Jørgensen <toke@...e.dk>,
        Christoph Hellwig <hch@....de>,
        Halil Pasic <pasic@...ux.ibm.com>,
        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

On Fri, Mar 25, 2022 at 11:42 AM Robin Murphy <robin.murphy@....com> wrote:
>
> Note that the current code is already a violation of the DMA
> API (because the device keeps writing even when it doesn't have
> ownership), so there's not a very strong argument in that regard.

See my other email. I actually think that the ath9k code is 100%
correct, adn it's the dma-mapping code that is in violation of the
rules.

And a big part of the problem - I think - is that the rules are so
badly documented and not explicitly listed.

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.

I really want people to think about this, because right now my gut
feel is that commit aa6f8dcbab47 was just absolutely incorrect.

              Linus