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: Fri, 25 Mar 2022 16:25:08 +0100 From: Halil Pasic <pasic@...ux.ibm.com> To: Robin Murphy <robin.murphy@....com> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Oleksandr Natalenko <oleksandr@...alenko.name>, Christoph Hellwig <hch@....de>, Marek Szyprowski <m.szyprowski@...sung.com>, Toke Høiland-Jørgensen <toke@...e.dk>, 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>, Halil Pasic <pasic@...ux.ibm.com> Subject: Re: [REGRESSION] Recent swiotlb DMA_FROM_DEVICE fixes break ath9k-based AP On Thu, 24 Mar 2022 19:02:16 +0100 Halil Pasic <pasic@...ux.ibm.com> wrote: > > I'll admit I still never quite grasped the reason for also adding the > > override to swiotlb_sync_single_for_device() in aa6f8dcbab47, but I > > think by that point we were increasingly tired and confused and starting > > to second-guess ourselves (well, I was, at least). > > I raised the question, do we need to do the same for > swiotlb_sync_single_for_device(). Did that based on my understanding of the > DMA API documentation. I had the following scenario in mind > > SWIOTLB without the snyc_single: > Memory Bounce buffer Owner > -------------------------------------------------------------------------- > start 12345678 xxxxxxxx C > dma_map(DMA_FROM_DEVICE) 12345678 -> 12345678 C->D > device writes partial data 12345678 12ABC678 <- ABC D > sync_for_cpu(DMA_FROM_DEVICE) 12ABC678 <- 12ABC678 D->C > cpu modifies buffer 66666666 12ABC678 C > sync_for_device(DMA_FROM_DEVICE) 66666666 12ABC678 C->D > device writes partial data 66666666 1EFGC678 <-EFG D > dma_unmap(DMA_FROM_DEVICE) 1EFGC678 <- 1EFGC678 D->C > > Legend: in Owner column C stands for cpu and D for device. > > Without swiotlb, I believe we should have arrived at 6EFG6666. To get the > same result, IMHO, we need to do a sync in sync_for_device(). > And aa6f8dcbab47 is an imperfect solution to that (because of size). > @Robin, Christoph: Do we consider this a valid scenario? Regards, Halil
Powered by blists - more mailing lists