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
| ||
|
Date: Fri, 27 Nov 2020 17:19:00 +0100 From: Christoph Hellwig <hch@....de> To: Hans de Goede <hdegoede@...hat.com> Cc: Christoph Hellwig <hch@....de>, Tom Yan <tom.ty89@...il.com>, Mathias Nyman <mathias.nyman@...el.com>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, linux-usb <linux-usb@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-pci@...r.kernel.org, Lu Baolu <baolu.lu@...ux.intel.com> Subject: Re: 5.10 regression caused by: "uas: fix sdev->host->dma_dev": many XHCI swiotlb buffer is full / DMAR: Device bounce map failed errors on thunderbolt connected XHCI controller On Fri, Nov 27, 2020 at 01:32:16PM +0100, Hans de Goede wrote: > I ran some more tests, I can confirm that reverting: > > 5df7ef7d32fe "uas: bump hw_max_sectors to 2048 blocks for SS or faster drives" > 558033c2828f "uas: fix sdev->host->dma_dev" > > Makes the problem go away while running a 5.10 kernel. I also tried doubling > the swiotlb size by adding: swiotlb=65536 to the kernel commandline but that > does not help. > > Some more observations: > > 1. The usb-storage driver does not cause this issue, even though it has a > very similar change. > > 2. The problem does not happen until I plug an UAS decvice into the dock. > > 3. The problem continues to happen even after I unplug the UAS device and > rmmod the uas module > > 3. made me take a bit closer look to the troublesome commit, it passes: > udev->bus->sysdev, which I assume is the XHCI controller itself as device > to scsi_add_host_with_dma, which in turn seems to cause permanent changes > to the dma settings for the XHCI controller. I'm not all that familiar with > the DMA APIs but I'm getting the feeling that passing the actual XHCI-controller's > device as dma-device to scsi_add_host_with_dma is simply the wrong thing to > do; and that the intended effects (honor XHCI dma limits, but do not cause > any changes the XHCI dma settings) should be achieved differently. > > Note that if this is indeed wrong, the matching usb-storage change should > likely also be dropped. One problem in this area is that the clamping of the DMA size through dma_max_mapping_size mentioned in the commit log doesn't work when swiotlb is called from intel-iommu. I think we need to wire up those calls there as well.
Powered by blists - more mailing lists