On 9/2/26 11:53, Leon Romanovsky wrote:
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 xuehaohu@google.com > > 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@google.com/ > > 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@x6u.co/
*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.
The PCI_P2PDMA_MAP_BUS_ADDR is not supported by DMA-buf and as far as I can see is a complete dead end.
All of this information is lost if only the dma_addr_t is stored.
Yes and that is fully intentional.
DMA-buf handles that cleanly on the buffer object level and not like PCI_P2PDMA_MAP_BUS_ADDR as a completely broken design on a per address/page basis.
Technical background is that the PCI_P2PDMA_MAP_BUS_ADDR approach can only be handled by a very very small subset of HW.
Regards, Christian.
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/0-v1-b5cab63049c0+191af-dmabuf_map_type_jgg@nvid...
Yeah, I have commented quite a bit on that.
Right, I posted it for reference.
Thanks
Regards, Christian.
Thanks
Regards, Christian.
Thanks