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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 28 Mar 2022 11:48:36 +0200 From: Johannes Berg <johannes@...solutions.net> To: Halil Pasic <pasic@...ux.ibm.com> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Maxime Bizon <mbizon@...ebox.fr>, Toke Høiland-Jørgensen <toke@...e.dk>, Robin Murphy <robin.murphy@....com>, Christoph Hellwig <hch@....de>, 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 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. Right. > 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 new/else... johannes
Powered by blists - more mailing lists