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

[Christian König]

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@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.

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.

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@xxxxxxxxxx/

Yeah, I have commented quite a bit on that.

Regards,
Christian.

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