On Fri, Jul 03, 2026 at 07:58:32PM +0100, Robin Murphy wrote: > On 03/07/2026 5:22 pm, Jason Gunthorpe wrote: > > On Wed, Jul 01, 2026 at 10:44:37AM +0000, Krzysztof Karas wrote: > > > It is possible, when a very large mapping uses a single > > > scatterlist, that padding overflows scatterlist's length field. > > > This results in: > > > 1) silently wrapping the value > > > 2) smaller than desired mappings produced by iommu_map_sg > > > 3) leaving mapped bytes in memory (no iommu_unmap) > > > > > > Address this issue by adding overflow detection for previous > > > scatterlist length field. > > > > Urk, this is unfortunate, it means we cannot map certain kinds of > > scatterlists? Meaning there is a condition that makes a scatterlist > > ill formed? > > > > This seems like something that needs to be more clearly documented and > > we need to ensure at least the common scatterlist builders don't hit > > it.. > > Well, it's taken 10 years to be caught by a test which seemingly expects the > mapping of a single absurdly giant scatterlist to fail anyway,
If your server has 0.5TB of ram a 4G IO isn't actually that large. Randomly getting a few contiguous 1G hugetlbfs pages is not even that unlikely. Something like FSDAX has a very high chance of getting high contiguity pages in files. So I wouldn't be quite so dismissive that this is not something a real user can hit. > here, but I suspect this is likely just regular iova_granule rounding > overflowing when the segment boundary is the maximum 4GB, since the largest > representable segment length is 4GB - 1. It looks like the iommu_dma_map_sg() algorithm only works reliably if the scatterlist entry size is less than UINT_MAX/2, otherwise it can risk overflowing when it pads. API wise I expect any arbitary input to sg_alloc_table_from_pages() to result in a scatterlist that iommu_dma_map_sg() will map. This patch highlights there are cornere cases where that isn't true, it should be fixed.. I agree we shouldn't overcomplicate iommu_dma_map_sg(), so the simplest fix is to introduce a SG_MAX_LENGTH set to UINT_MAX/2, justified by the logic in iommu_dma_map_sg(). Fixup the core sg_alloc code to respect that. WARN_ON in iommu_dma_map_sg() if a malformed scatterlist entry is presented. Add a WARN_ON under DMA debugging kconfig as well for the physical path. DRM would then have to generate scatterlists with a max segment size. Jason
