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:   Mon, 28 Mar 2022 11:48:36 +0200
From:   Johannes Berg <>
To:     Halil Pasic <>
Cc:     Linus Torvalds <>,
        Maxime Bizon <>,
        Toke Høiland-Jørgensen <>,
        Robin Murphy <>,
        Christoph Hellwig <>,
        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, 2022-03-27 at 05:15 +0200, Halil Pasic wrote:

> The key here is "sync_sg API, all the parameters must be the same
> as those passed into the single mapping API", but I have to admit,
> I don't understand the *single* in here.

Hah. So I wasn't imagining things after all.

However, as the rest of the thread arrives, this still means it's all
broken ... :)

> The intended meaning of the
> last sentence is that one can do partial sync by choose 
> dma_hande_sync, size_sync such that dma_handle_mapping <= dma_handle_sync
> < dma_handle_mapping + size_mapping and dma_handle_sync + size_sync <=
> dma_handle_mapping + size_mapping. But the direction has to remain the
> same.


> BTW, the current documented definition of the direction is about the
> data transfer direction between memory and the device, and how the CPU
> is interacting with the memory is not in scope. A quote form the
> documentation.
> """
> ======================= =============================================
> DMA_NONE                no direction (used for debugging)
> DMA_TO_DEVICE           data is going from the memory to the device
> DMA_FROM_DEVICE         data is coming from the device to the memory
> DMA_BIDIRECTIONAL       direction isn't known
> ======================= =============================================
> """
> (Documentation/core-api/dma-api.rst)
> My feeling is, that re-defining the dma direction is not a good idea. But
> I don't think my opinion has much weight here.

However, this basically means that the direction argument to the flush
APIs are completely useless, and we do have to define something


Powered by blists - more mailing lists