Re: [PATCH v2 3/3] drivers/iommu: Catch scatterlist length overflows

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Jul 06, 2026 at 02:08:14PM +0100, Robin Murphy wrote:

> modern use-cases anyway, and is being replaced, so limitations of a "legacy"
> API that don't have any meaningful impact to its existing users are hardly
> something to panic about. If DRM does want to be able to *reliably* map
> massive amounts of RAM then it can adopt the new IOMMU API, for this and all
> the other reasons that that new API was promised to be "better".

Yes the new API does solve these issues, and it avoids padding
destroying the iova contiguity.

> > So I wouldn't be quite so dismissive that this is not something a real
> > user can hit.
> 
> I'm not being dismissive - clearly it can be hit. My point is that anyone
> who *does* hit it can only expect it to fail (as indeed this particular IGT
> test seems to), because it has never worked.

Today you can allocate memory from hugetlbfs and map it through
RDMA. The user can set 1G hugetlbfs page size and allocate 16G of
memory, and RDMA map it. Databases and HPC, for example, love to do
work loads like this.

So there is an unlucky hugetlbfs FD that has an internal memory layout
that will build a scatterlist that cannot be mapped by the iommu.

The user's application that normally works will fail randomly and
infrequently for no fault of their own. This isn't "can only expect it
to fail".

> So yes, limiting any individual segment to <=2GB would end up avoiding both
> those conditions, but it would also impact plenty of cases that *do*
> currently work fine, e.g. 1GB+3GB+3GB. The limitation is really that you
> can't have two consecutive segments where the first starts exactly on a 4GB
> boundary and the sum of both their sizes >=4GB.

Yeah, but that's hard to express.

My feeling was supporting >2GB without a split is not really so
important. You are (righly) arguing these huge sizes are usually rare.
Places like RDMA where they are not rare people already added
re-assembly logic to join SGLs so HW optimizations for >= 4G mappings
can be used, so smaller splitting doesn't really matter.

> > 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..
> 
> Technically sg_alloc_table_from_pages() carries no such assumption,
> only

There are lots of callers that just do sg_alloc_table_from_pages()
then dma_map_sg(). Callers can use this simplified API when they don't
need any segmentation logic in the DMA API.

> sg_alloc_table_from_pages_segment() (or __sg_alloc_table_from_pages()) with
> the correct dma_seg_boundary value for the given device. 

_segment is the segment size, not boundary. The sg_alloc_table
functions don't support the seg_boundary limitation.

So, how about instead of failing we just don't do any padding? Ie
ignore dma_seg_boundary, and hope the device is modern and doesn't
need it?

Alternatively, can we request to disable dma_seg_boundary somehow in
the driver and stick with the WARN_ON?

Jason