Re: [PATCH v8 0/2] dma-buf: Fix silent overflow and alignment

[Leon Romanovsky]

On Wed, Sep 02, 2026 at 09:56:06AM +0200, Christian König wrote:
> On 9/2/26 09:39, Leon Romanovsky wrote:
> > On Wed, Sep 02, 2026 at 09:00:46AM +0200, Christian König wrote:
> >> On 9/1/26 19:08, David Hu wrote:
> >>> From: David Hu <xuehaohu@xxxxxxxxxx>
> >>>
> >>> This series address two related issues in scatter-gather mapping,
> >>> specifically for the MMIO based dma-buf mapping. The fixes ensure
> >>> sgt mapping is correct, and proper for large MMIO regions.
> >>>
> >>> Patch 1 fixes a silent integer overflow for mapping length exceeding 4G
> >>> (Previously submitted as [PATCH v7] dma-buf: Fix silent overflow for
> >>> phys vec to sgt)
> >>> https://lore.kernel.org/all/20260609164047.486227-1-xuehaohu@xxxxxxxxxx/
> >>>
> >>> Patch 2 Splits sgl by largest page aligned chunk
> >>> (Previously submitted as [PATCH v3] dma-buf: Split sgl by largest page-aligned chunk)
> >>> https://lore.kernel.org/all/20260722233806.3922093-1-dhu@xxxxxx/
> >>
> >> *sigh* such issues are exactly the reason why I didn't wanted the dma-mapping stuff inside DMA-buf. That clearly doesn't belong here.
> > 
> > And this is why so many in the kernel community want to get rid of SG
> > lists. It would be great if DMA-BUF could also eliminate the need to
> > convert to an SGL, like Jason proposed.
> > 
> > The DMA layer no longer needs SGL. These bugs belong to the DMA-BUF layer,
> > which is the one that depends on it.
> 
> I'm all fine using an array/xarray of dma_addr_t in DMA-buf, just phys_vec is a clear no-go.

You are proposing the same thing as an SGL, just in a different format.
It does not address the issue that dma_addr_t is expected to hold a DMA
address, while that is not always the case. For example, in the P2P case,
the addresses are not DMA addresses.

Jason's proposal:
https://lore.kernel.org/all/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@xxxxxxxxxx/

Thanks

> 
> Regards,
> Christian.
> 
> > 
> > Thanks
> 
>