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  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]
Date:   Sun, 27 Mar 2022 17:30:01 -0700
From:   Linus Torvalds <>
To:     Halil Pasic <>
Cc:     Toke Høiland-Jørgensen <>,
        Robin Murphy <>,
        Christoph Hellwig <>,
        Maxime Bizon <>,
        Oleksandr Natalenko <>,
        Marek Szyprowski <>,
        Kalle Valo <>,
        "David S. Miller" <>,
        Jakub Kicinski <>,
        Paolo Abeni <>,
        Olha Cherevyk <>,
        iommu <>,
        linux-wireless <>,
        Netdev <>,
        Linux Kernel Mailing List <>,
        Greg Kroah-Hartman <>,
        stable <>
Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break
 ath9k-based AP

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 they agreed. It ain't my field of expertise, and the
> drivers I'm interested in don't need this functionality.


That said, I think you are putting yourself down when you said in an
earlier email that you aren't veryt knowledgeable in this area.

I think the fact that you *did* think of this other similar situation
is actually very interesting, and it's something people probably
_haven't_ been thinking about.

So I think your first commit fixes the straightforward and common case
where you do that "map / partial dma / unmap" case.

And that straightforward case is probably all that the disk IO case
ever really triggers, which is presumably why those "drivers I'm
interested in don't need this functionality" don't need anything else?

And yes, your second commit didn't work, but hey, whatever. The whole
"multiple operations on the same double buffering allocation"
situation is something I don't think people have necessarily thought
about enough.

And by that I don't mean you. I mean very much the whole history of
our dma mapping code.

I then get opinionated and probably too forceful, but please don't
take it as being about you - it's about just my frustration with that
code - and if it comes off too negative then please accept my


Powered by blists - more mailing lists