On Wed, Sep 02, 2026 at 10:44:59AM +0200, Christian König wrote: > On 9/2/26 10:32, Leon Romanovsky wrote: > > 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. > > Yes, because that is the right thing todo as far as I can see. > > > 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. > > Yes they are. They must be DMA addresses because that is the only thing the > importer needs to do it's DMA.
They can perform DMA, but that still does not make them suitable for the dma_addr_t type. For the PCI_P2PDMA_MAP_BUS_ADDR flow, these addresses follow completely different rules: they are not unmapped, require no cache synchronization, are valid only for peer access, and require separate error handling. All of this information is lost if only the dma_addr_t is stored. > > It can be that those are DMA addresses on private interconnects between > devices, but it should *never* be a phys_addr_t because that is limited to > the address space the CPU can see. > > > Jason's proposal: > > https://lore.kernel.org/all/[email protected]/ > > Yeah, I have commented quite a bit on that. Right, I posted it for reference. Thanks > > Regards, > Christian. > > > > > Thanks > > > >> > >> Regards, > >> Christian. > >> > >>> > >>> Thanks > >> > >> > >
