On 10/5/26 08:41, Karl Mehltretter wrote:
> With DMABUF_DEBUG, dma_buf_map_attachment() hands the importer a copy
> of the sg_table that keeps only sg_dma_address() and sg_dma_len(). The
> dma_flags (SG_DMA_BUS_ADDRESS, SG_DMA_SWIOTLB) are dropped.
>
> The flags describe the DMA side of an entry, which is the side
> importers may use. Copy them as well.
>
> This is not a bug fix. No importer reads the flags today. Their only
> readers are dma-iommu, dma-direct and iommu_map_sg(), which are not
> supposed to see an importer's copy at all. The warn mode added in the
> next patch keeps its marker in dma_flags and lets importers that do
> get there continue. They should then see the same flags as without
> DMABUF_DEBUG.
>
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter(a)gmail.com>
I've reviewed the patch and pushed it to drm-misc-fixes.
Sorry for the delay,
Christian.
> ---
>
> Notes:
> Built alone on x86_64 with NEED_SG_DMA_FLAGS=y (dma-buf.o, W=1). The
> KUnit test in patch 3 checks the flags in the copy. It passes on x86_64
> under QEMU in strict and in warn mode.
>
> drivers/dma-buf/dma-buf.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 4c9add51f9ef..b3d311acb883 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -904,6 +904,10 @@ static int dma_buf_wrap_sg_table(struct sg_table **sg_table)
> sg_assign_page(to_sg, NULL);
> sg_dma_address(to_sg) = sg_dma_address(from_sg);
> sg_dma_len(to_sg) = sg_dma_len(from_sg);
> +#ifdef CONFIG_NEED_SG_DMA_FLAGS
> + /* the flags describe the DMA side, e.g. SG_DMA_BUS_ADDRESS */
> + to_sg->dma_flags = from_sg->dma_flags;
> +#endif
> to_sg = sg_next(to_sg);
> }
>
On 10/27/26 14:34, Mikko Perttunen wrote:
> On Tuesday, October 27, 2026 9:33 PM Jason Gunthorpe wrote:
>> On Tue, Oct 27, 2026 at 12:42:32PM +0900, Mikko Perttunen wrote:
>>
>>>> This page-side use predates the series, so the fault is not itself a v2
>>>> regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
>>>> need a page/physical mapping type first?
>>>
>>> Sounds like a bug in TegraDRM; we should be using the DMA addr/length
>>> for the explicit IOMMU mapping as the sgt attachment is for the dummy
>>> DRM device explicitly intended to give us physical addresses.
>>
>> No, you cannot connect dmabuf to an iommu_domain. It is 100% always
>> illegal. DMABUF does not support this. Do not pass sg_dma to iommu
>> functions either.
>
> Sure, I agree -- so let's say it's a bug on top of the baseline crimes
> TegraDRM commits :)
Well the initial crime was to abuse sgt to transport dma addresses, don't document how all of this works and then be surprised when everything blew up.
But yeah don't touch the pages in sgt exposed by DMA-buf, that is pretty much one of the most fundamental rules we have now.
Regards,
Christian.
>
>>
>>> I'm currently in the process of removing the whole explicit IOMMU path
>>> so if this only occurs with CONFIG_DMABUF_DEBUG enabled, I don't think
>>> there's a pressing need to fix this before then.
>>
>> Yes I think this is probably the only way to fix it :| You have to
>> always use the DMA API
>>
>> Jason
>>
>
>
>
>
On Tue, Oct 27, 2026 at 07:03:29AM -0600, Jens Axboe wrote:
> On 10/27/26 3:08 AM, Li Wang wrote:
> > From: Mengmeng Zhao <zhaomengmeng(a)kylinos.cn>
> >
> > This patch introduces a driver that allows moving data between a GPU
> > dma-buf and a regular file on NVME without staging it through the page
> > cache. Userspace registers the GPU dma-buf with the device, then issues
> > read and write requests via the device's ioctls. Each transfer is direct
> > I/O: an ITER_DMABUF_MAP iterator is passed to the file's read_iter or
> > write_iter, and the filesystem's iomap path submits REQ_DMABUF bios that
> > already carry the dma addresses.
> >
> > Signed-off-by: Mengmeng Zhao <zhaomengmeng(a)kylinos.cn>
> > Signed-off-by: Li Wang <liwang(a)kylinos.cn>
> > ---
> > .../userspace-api/ioctl/ioctl-number.rst | 2 +
> > drivers/dma-buf/dma-buf-io.c | 3 +
> > drivers/misc/Kconfig | 16 +
> > drivers/misc/Makefile | 1 +
> > drivers/misc/fgds.c | 506 ++++++++++++++++++
> > fs/iomap/buffered-io.c | 11 +
> > fs/iomap/direct-io.c | 23 +-
> > fs/xfs/xfs_file.c | 4 +
> > include/linux/iov_iter.h | 4 +
> > include/uapi/linux/fgds.h | 124 +++++
> > lib/iov_iter.c | 1 +
> > mm/filemap.c | 22 +-
> > 12 files changed, 713 insertions(+), 4 deletions(-)
> > create mode 100644 drivers/misc/fgds.c
> > create mode 100644 include/uapi/linux/fgds.h
>
> What's the point of this, when you can just use io_uring to do
> the same?!
Agreed, I thought that the summary of the last round of reviews was
"this isn't needed at all". Li, what changed from that?
thanks,
greg k-h
On Tue, Oct 27, 2026 at 12:42:32PM +0900, Mikko Perttunen wrote:
> > This page-side use predates the series, so the fault is not itself a v2
> > regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
> > need a page/physical mapping type first?
>
> Sounds like a bug in TegraDRM; we should be using the DMA addr/length
> for the explicit IOMMU mapping as the sgt attachment is for the dummy
> DRM device explicitly intended to give us physical addresses.
No, you cannot connect dmabuf to an iommu_domain. It is 100% always
illegal. DMABUF does not support this. Do not pass sg_dma to iommu
functions either.
> I'm currently in the process of removing the whole explicit IOMMU path
> so if this only occurs with CONFIG_DMABUF_DEBUG enabled, I don't think
> there's a pressing need to fix this before then.
Yes I think this is probably the only way to fix it :| You have to
always use the DMA API
Jason
On Tue, Oct 27, 2026 at 03:15:34AM +0100, Karl Mehltretter wrote:
> On Mon, Oct 26, 2026 at 04:36:14PM +0100, Alistair Popple wrote:
>
> Testing the series on a Jetson Nano exposed this path. A 3 MiB system-heap
> buffer was imported into Tegra DRM and scanned out over HDMI. With
> CONFIG_DMABUF_DEBUG=y the PRIME import succeeded, but scanout immediately
> produced display SMMU faults starting at 0x300000.
Why is this being reported here? Shouldn't CONFIG_DMABUF_DEBUG=y have
always caused tegra to fail?
> > @@ -475,7 +475,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device *drm,
> > * domain, map it first to the DRM device to get an sgt.
> > */
> > if (tegra->domain) {
> > - attach = dma_buf_attach(buf, drm->dev);
> > + attach = dma_buf_sgt_attach(buf, drm->dev);
>
> tegra_bo_import() passes the attachment SGT to iommu_map_sgtable(),
> which
This is illegal use of dmabuf, this was discussed in some other driver
recently.
All DRM drivers trying to use custom iommu domains are busted this
way. AFAIK there is no solution besides "don't do that".
> This page-side use predates the series, so the fault is not itself a v2
> regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
> need a page/physical mapping type first?
Tegra is broken.
Jason
On 10/27/26 03:15, Karl Mehltretter wrote:
> On Mon, Oct 26, 2026 at 04:36:14PM +0100, Alistair Popple wrote:
>
> Testing the series on a Jetson Nano exposed this path. A 3 MiB system-heap
> buffer was imported into Tegra DRM and scanned out over HDMI. With
> CONFIG_DMABUF_DEBUG=y the PRIME import succeeded, but scanout immediately
> produced display SMMU faults starting at 0x300000.
>
> Tracing the fault led here:
>
>> @@ -475,7 +475,7 @@ static struct tegra_bo *tegra_bo_import(struct drm_device *drm,
>> * domain, map it first to the DRM device to get an sgt.
>> */
>> if (tegra->domain) {
>> - attach = dma_buf_attach(buf, drm->dev);
>> + attach = dma_buf_sgt_attach(buf, drm->dev);
>
> tegra_bo_import() passes the attachment SGT to iommu_map_sgtable(), which
> uses sg_phys() and sg->length. The SGT mapping contract only guarantees the
> DMA address and length fields. The debug wrapper clears the page-side fields,
> so iommu_map_sgtable() maps zero bytes.
>
> Tegra only treats negative returns as errors and keeps the reserved
> IOVA, which scanout then faults on.
>
> This page-side use predates the series, so the fault is not itself a v2
> regression. Is dma_buf_sgt_attach() valid for this call site, or does Tegra
> need a page/physical mapping type first?
Sharing page/physical to be used with the IOMMU functions through DMA-buf is an absolutely hard NAK from my side.
We still need to figure out how to do this between KVM, IOMMUFD and virtio so that it is limited to only those three.
Regards,
Christian.
>
> Karl