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 <[email protected]> > >>> > >>> 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/[email protected]/ > >>> > >>> 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/[email protected]/ > >> > >> *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/[email protected]/ Thanks > > Regards, > Christian. > > > > > Thanks > >
