Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

19 participants
3649 discussions

[PATCH RFC 00/26] Add DMA-buf mapping types and convert vfio/iommufd to use them

by Jason Gunthorpe

Since its introduction, DMA-buf has only supported using scatterlist for the exporter and importer to exchange address information. This is not sufficient for all use cases as dma_addr_t is a very specific and limited type that should not be abused for things unrelated to the DMA API. There are several motivations for addressing this now: 1) VFIO to IOMMUFD and KVM requires a physical address, not a dma_addr_t scatterlist, it cannot be represented in the scatterlist structure 2) xe vGPU requires the host driver to accept a DMABUF from VFIO of its own VF and convert it into an internal VRAM address on the PF 3) We are starting to look at replacement datastructures for scatterlist 4) Ideas around UALink/etc are suggesting not using the DMA API None of these can sanely be achieved using scatterlist. Introduce a new mechanism called "mapping types" which allows DMA-buf to work with more map/unmap options than scatterlist. Each mapping type encompasses a full set of functions and data unique to itself. The core code provides a match-making system to select the best type offered by the exporter and importer to be the active mapping type for the attachment. Everything related to scatterlist is moved into a DMA-buf SGT mapping type, and into the "dma_buf_sgt_*" namespace for clarity. Existing exporters are moved over to explicitly declare SGT mapping types and importers are adjusted to use the dma_buf_sgt_* named importer helpers. Mapping types are designed to be extendable, a driver can declare its own mapping type for its internal private interconnect and use that without having to adjust the core code. The new attachment sequence starts with the importing driver declaring what mapping types it can accept: struct dma_buf_mapping_match imp_match[] = { DMA_BUF_IMAPPING_MY_DRIVER(dev, ...), DMA_BUF_IMAPPING_SGT(dev, false), }; attach = dma_buf_mapping_attach(dmabuf, imp_match, ...) Most drivers will do this via a dma_buf_sgt_*attach() helper. The exporting driver can then declare what mapping types it can supply: int exporter_match_mapping(struct dma_buf_match_args *args) { struct dma_buf_mapping_match exp_match[] = { DMA_BUF_EMAPPING_MY_DRIVER(my_ops, dev, ...), DMA_BUF_EMAPPING_SGT(sgt_ops, dev, false), DMA_BUF_EMAPPING_PAL(PAL_ops), }; return dma_buf_match_mapping(args, exp_match, ...); } Most drivers will do this via a helper: static const struct dma_buf_ops ops = { DMA_BUF_SIMPLE_SGT_EXP_MATCH(map_func, unmap_func) }; During dma_buf_mapping_attach() the core code will select a mutual match between the importer and exporter and record it as the active match in the attach->map_type. Each mapping type has its own types/function calls for mapping/unmapping, and storage in the attach->map_type for its information. As such each mapping type can offer function signatures and data that exactly matches its needs. This series goes through a sequence of: 1) Introduce the basic mapping type framework and the main components of the SGT mapping type 2) Automatically make all existing exporters and importers use core generated SGT mapping types so every attachment has a SGT mapping type 3) Convert all exporter drivers to natively create a SGT mapping type 4) Move all dma_buf_* functions and types that are related to SGT into dma_buf_sgt_* 5) Remove all the now-unused items that have been moved into SGT specific structures. 6) Demonstrate adding a new Physical Address List alongside SGT. Due to the high number of files touched I would expect this to be broken into phases, but this shows the entire picture. This is on github: https://github.com/jgunthorpe/linux/commits/dmabuf_map_type It is a followup to the discussion here: https://lore.kernel.org/dri-devel/20251027044712.1676175-1-vivek.kasireddy@… Jason Gunthorpe (26): dma-buf: Introduce DMA-buf mapping types dma-buf: Add the SGT DMA mapping type dma-buf: Add dma_buf_mapping_attach() dma-buf: Route SGT related actions through attach->map_type dma-buf: Allow single exporter drivers to avoid the match_mapping function drm: Check the SGT ops for drm_gem_map_dma_buf() dma-buf: Convert all the simple exporters to use SGT mapping type drm/vmwgfx: Use match_mapping instead of dummy calls accel/habanalabs: Use the SGT mapping type drm/xe/dma-buf: Use the SGT mapping type drm/amdgpu: Use the SGT mapping type vfio/pci: Change the DMA-buf exporter to use mapping_type dma-buf: Update dma_buf_phys_vec_to_sgt() to use the SGT mapping type iio: buffer: convert to use the SGT mapping type functionfs: convert to use the SGT mapping type dma-buf: Remove unused SGT stuff from the common structures treewide: Rename dma_buf_map_attachment(_unlocked) to dma_buf_sgt_ treewide: Rename dma_buf_unmap_attachment(_unlocked) to dma_buf_sgt_* treewide: Rename dma_buf_attach() to dma_buf_sgt_attach() treewide: Rename dma_buf_dynamic_attach() to dma_buf_sgt_dynamic_attach() dma-buf: Add the Physical Address List DMA mapping type vfio/pci: Add physical address list support to DMABUF iommufd: Use the PAL mapping type instead of a vfio function iommufd: Support DMA-bufs with multiple physical ranges iommufd/selftest: Check multi-phys DMA-buf scenarios dma-buf: Add kunit tests for mapping type Documentation/gpu/todo.rst | 2 +- drivers/accel/amdxdna/amdxdna_gem.c | 14 +- drivers/accel/amdxdna/amdxdna_ubuf.c | 10 +- drivers/accel/habanalabs/common/memory.c | 54 ++- drivers/accel/ivpu/ivpu_gem.c | 10 +- drivers/accel/ivpu/ivpu_gem_userptr.c | 11 +- drivers/accel/qaic/qaic_data.c | 8 +- drivers/dma-buf/Makefile | 1 + drivers/dma-buf/dma-buf-mapping.c | 186 ++++++++- drivers/dma-buf/dma-buf.c | 180 ++++++--- drivers/dma-buf/heaps/cma_heap.c | 12 +- drivers/dma-buf/heaps/system_heap.c | 13 +- drivers/dma-buf/st-dma-mapping.c | 373 ++++++++++++++++++ drivers/dma-buf/udmabuf.c | 8 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 98 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +- drivers/gpu/drm/armada/armada_gem.c | 33 +- drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +- drivers/gpu/drm/drm_prime.c | 31 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 18 +- drivers/gpu/drm/i915/gem/i915_gem_object.c | 2 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 8 +- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 8 +- drivers/gpu/drm/msm/msm_gem_prime.c | 7 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 11 +- drivers/gpu/drm/tegra/gem.c | 33 +- drivers/gpu/drm/virtio/virtgpu_prime.c | 23 +- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 32 +- drivers/gpu/drm/xe/xe_bo.c | 18 +- drivers/gpu/drm/xe/xe_dma_buf.c | 61 +-- drivers/iio/industrialio-buffer.c | 15 +- drivers/infiniband/core/umem_dmabuf.c | 15 +- drivers/iommu/iommufd/io_pagetable.h | 4 +- drivers/iommu/iommufd/iommufd_private.h | 8 - drivers/iommu/iommufd/iommufd_test.h | 7 + drivers/iommu/iommufd/pages.c | 85 ++-- drivers/iommu/iommufd/selftest.c | 177 ++++++--- .../media/common/videobuf2/videobuf2-core.c | 2 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 21 +- .../common/videobuf2/videobuf2-vmalloc.c | 13 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 9 +- drivers/misc/fastrpc.c | 21 +- drivers/tee/tee_heap.c | 13 +- drivers/usb/gadget/function/f_fs.c | 11 +- drivers/vfio/pci/vfio_pci_dmabuf.c | 79 ++-- drivers/xen/gntdev-dmabuf.c | 29 +- include/linux/dma-buf-mapping.h | 297 ++++++++++++++ include/linux/dma-buf.h | 168 ++++---- io_uring/zcrx.c | 9 +- net/core/devmem.c | 14 +- samples/vfio-mdev/mbochs.c | 10 +- sound/soc/fsl/fsl_asrc_m2m.c | 12 +- tools/testing/selftests/iommu/iommufd.c | 43 ++ tools/testing/selftests/iommu/iommufd_utils.h | 17 + 55 files changed, 1764 insertions(+), 614 deletions(-) create mode 100644 drivers/dma-buf/st-dma-mapping.c base-commit: c63e5a50e1dd291cd95b04291b028fdcaba4c534 -- 2.43.0

3 hours, 44 minutes

Re: [RFC PATCH 0/6] iommufd: harden DMA-BUF PAL setup and release

by Jason Gunthorpe

On Tue, Oct 20, 2026 at 10:16:26PM +1100, Alistair Popple wrote: > I haven't had a chance to look at these patches yet, but if some of them are > fixing bugs in Jason's series it might be best for us to fold them into that > series, with correct attribution of course. Anyway I will take a closer look in > the morning. Are any fixing bugs in tree right now? I think one of them is already applied from someone else.. Jason

15 hours, 49 minutes

Re: [PATCH RFC 03/26] dma-buf: Add dma_buf_mapping_attach()

by Christian König

On 10/16/26 22:26, Karl Mehltretter wrote: > On Tue, Feb 17, 2026 at 08:11:34PM -0400, Jason Gunthorpe wrote: >> + match_args.attach = attach; >> + if (dmabuf->ops->match_mapping) { >> + ret = dmabuf->ops->match_mapping(&match_args); >> + } >> + >> attach->dmabuf = dmabuf; >> attach->importer_ops = importer_ops; >> attach->importer_priv = importer_priv; > > I may misunderstand the intended contract. match_mapping() runs while the > attachment is still zeroed and without dmabuf->resv held. > > Patch 11's amdgpu callback needs importer_ops and importer_priv, so its XGMI > match cannot work here. Patch 12's VFIO callback asserts dmabuf->resv and > reads priv->vdev, which cleanup changes under that lock. > > Should the core initialize the attachment and hold dmabuf->resv for > match_mapping(), or should callbacks avoid attachment and lock-protected > state? Right. This completely misplaced. The matching can't be done at attachment time, but rather needs to be done before creating a mapping while holding the resv lock so that the matching decision can't change. Regards, Christian. > > Thanks, > Karl

19 hours, 38 minutes

Re: [PATCH] dma-buf: Fix IOVA offset when linking phys vecs to sgt

by Christian König

On 10/20/26 11:19, Yili Zhang wrote: > Hi Sumit, Christian, > > Gentle ping on this patch. > > It has two Reviewed-by tags from Dawid and Leon, but I don't see the fix in > v7.3. Since the 7.4 merge window is now open, could it be queued for v7.4? > > I'm happy to resend with the collected Reviewed-by tags if that helps. I've just pushed it to drm-misc-fixes. Sorry I'm way to busy at the moment. Regards, Christian. > > Thanks, > Yili

22 hours, 12 minutes

Re: [PATCH v3 1/2] drm/drm_crtc: ensure dma_fence_ops remain valid during device unbind

by Christian König

On 10/20/26 09:14, Philipp Stanner wrote: > On Tue, 2026-07-21 at 09:21 +0100, André Draszik wrote: >> > > […] > >> >> >> --- >> v3: >> - Philipp: update kerneldoc, add Fixes: >> >> v2: new patch >> --- >> drivers/gpu/drm/drm_crtc.c | 15 ++++++++++++--- >> 1 file changed, 12 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c >> index 63ead8ba6756..e8e80c936852 100644 >> --- a/drivers/gpu/drm/drm_crtc.c >> +++ b/drivers/gpu/drm/drm_crtc.c >> @@ -493,14 +493,23 @@ EXPORT_SYMBOL(__drmm_crtc_alloc_with_planes); >> * drm_crtc_cleanup - Clean up the core crtc usage >> * @crtc: CRTC to cleanup >> * >> - * This function cleans up @crtc and removes it from the DRM mode setting >> - * core. Note that the function does *not* free the crtc structure itself, >> - * this is the responsibility of the caller. >> + * This function cleans up @crtc and removes it from the DRM mode setting core, >> + * after first waiting an RCU grace period to ensure @crtc->dev can safely be >> + * dereferenced by our dma_fence_ops. >> + * >> + * Note that the function does *not* free the crtc structure itself, this is the >> + * responsibility of the caller. >> */ >> void drm_crtc_cleanup(struct drm_crtc *crtc) >> { >> struct drm_device *dev = crtc->dev; >> >> + /* Ensure our dma_fence_ops remain valid for an RCU grace period after >> + * the fence is signaled. This is necessary because our dma_fence_ops >> + * dereference crtc->dev. >> + */ >> + synchronize_rcu(); >> + >> /* Note that the crtc_list is considered to be static; should we >> * remove the drm_crtc at runtime we would have to decrement all >> * the indices on the drm_crtc after us in the crtc_list. > > > Seems we forgot [1] this patch. Sorry about that. > > This fix also looks fine to me (for now) since it's what the dma_fence > contract currently demands. > > I'm a bit nervous about a synchronize_rcu() being in every cleanup > path, but I suspect it's the most reasonable thing to do now. > > Let's wait a day or two to see if anyone has fundamental objections. > Could someone with some CRTC knowledge give it an R-b? Otherwise I'd > push it this week. I just picked them up and I'm about to push them to drm-misc-fixes. Regards, Christian. > > > Regards, > Philipp > > > [1] https://lore.kernel.org/dri-devel/73fc12734386c9bebc9cf6d3cea4c5f8e125255e.…

22 hours, 49 minutes

[PATCH v11 00/19] PCI/P2PDMA: Route peer-to-peer DMA by TLP class

by Leon Romanovsky

PCI P2PDMA applies Request and Completion Redirect throughout both paths. This misclassifies asymmetric and nested switches, and reports one answer for every kind of TLP. Three ACS controls act on TLP attributes the Requester chooses rather than on the topology: Translation Blocking and Direct Translated P2P act on a Request's Address Type, and Completion Redirect skips Completions carrying Relaxed Ordering. Evaluate each direction at the path divergence, decide every class from the one walk, and treat a client with ATS enabled as translating unless its driver declares per-mapping ATS. This completes the P2PDMA side; dma-buf and mlx5 follow separately. Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- Changes in v11: - Applied the client ATS policy in pci_p2pdma_distance_many() too, as local Sashiko pointed out. - Read the ATS Enable bit once per query, so the class and the ATS policy always agree. - Documented that pcim_p2pdma_set_ats_per_mapping() needs a successful pcim_p2pdma_init(). - The path diagnostics no longer read ACS Control or the bridge bus range, and they report a failed cache store. - Added a KUnit case for Direct Translated P2P without a redirect. - Clarified the Relaxed Ordering and diagnostics commit messages. - Honored device-specific ACS redirection, such as Zhaoxin Downstream Ports, in a new first patch with a KUnit case, as local Sashiko pointed out. Relaxed Ordering Completions are redirected at such a port too. - Clarified in the documentation that a quirk also redirects Relaxed Ordering Completions and that Translation Blocking applies only to upstream Requests, and labelled the ACS routing debug line with its class, as local Sashiko pointed out. - Treated ACS registers that read as all ones as unreadable, and named ports that a quirk redirects instead of suggesting pci=disable_acs_redir= for them, as local Sashiko pointed out. - Ignored ACS quirks of endpoints, which only describe traffic between their own functions. - Link to v10: https://patch.msgid.link/20261012-fix-p2p-acs-v4-0-v10-0-6ffe7b7a4517@nvidi… Changes in v10: - Fixed the Relaxed Ordering description: a Completion carries the attribute of its Request (PCIe r7.0 sec 2.2.9.1). - Used the PCIe terms Requester and Completer for TLPs, ACS and ports; client and provider remain for P2PDMA objects. - Rebased on pci/p2pdma, which includes the prerequisite P2PDMA fixes. - Added a topology example to the path divergence patch. - Removed a repeated sentence from the disable_acs_redir documentation. - Explained the path divergence in the documentation. - Link to v9: https://patch.msgid.link/20261001-fix-p2p-acs-v4-0-v9-0-1a8e0f50ddd9@nvidia… Changes in v9: - Removed dmabuf patches for now. - Removed mlx5 per-mapping ATS declaration for now; it comes back with the dmabuf patches. - Link to v8: https://patch.msgid.link/20260928-fix-p2p-acs-v4-0-v8-0-404453b9c435@nvidia… Changes in v8: - Added extra Reviewed-by from Logan. - Added patches to take care of ATS per-device vs. per-mapping option - Link to v7: https://patch.msgid.link/20260920-fix-p2p-acs-v4-0-v7-0-ca0828ab697c@nvidia… Changes in v7: - Removed "Document pdev->p2pdma lifetime rules" patch, it gives nothing after p2pmem fix. - Split dmabuf patch. - Tushar retested the series, so added his Tested-by. - Added Logan's ROB tags and fixed minor documentation issues pointed by him. - Link to v6: https://lore.kernel.org/all/20260914-fix-p2p-acs-v4-0-v6-0-5ef07ec9ef06@nvi… Changes in v6: - Changed DMABUF to use callbacks and not directly stored pointer. - Link to v5: https://patch.msgid.link/20260910-fix-p2p-acs-v4-0-v5-0-856087f63c0d@nvidia… Changes in v5: - Rebase on the posted fixes. - Dropped tags from changed patches. - Remove Egress Control Vector interpretation and coverage. - Keep enabled Egress Control conservative as a Request redirect. - Use pci_dbg()/dev_dbg() for diagnostics and drop the "debug" prefix. - Removed code comments from "Document the pdev->p2pdma lifetime and RCU rules" patch and reduced description to actual lifetime explanation. - Added note that Linux assumes that TLPs are in strict-ordering and untranslated. - Added code to calculate p2p paths per-TLP type. - Converted mlx5 to use that new proposed API. - Link to https://patch.msgid.link/20260821-fix-p2p-acs-v4-0-v4-0-94426b96de73@nvidia… Changes in v4: - Reject ACS Violations and unreadable routing state instead of treating them as host-bridge redirects - Added Tested-by tags from Tushar Dave - Added support to asymmetric ACS routing - Limited redirect checks to the two ports at the path divergence - Added standalone ACS routing diagnostics for hardware retesting - Dropped " PCI: Account for Direct Translated P2P in ACS isolation checks" patch - Link to v3: https://patch.msgid.link/20260811-fix-p2p-acs-v3-0-efc488ee7c03@nvidia.com Changes in v3: - Fixed pci_p2pdma_add_resource() error unwinding - Made pdev->p2pdma teardown wait unconditionally for RCU readers - Restricted pci_p2pmem_find_many() to pool-backed providers - Documented the pdev->p2pdma lifetime and RCU rules - Fixed calc_map_type_and_dist() handling of the verbose argument - Required the ACS port and target to share a bus before indexing the Egress Control Vector - Gave pci_acs_enabled() and pci_acs_path_enabled() a scope, so the ACS Direct Translated P2P rule no longer stops pci_enable_pasid() from enabling PASID - Dropped "Report ACS ports when the paths share no upstream bridge": the mapping type cannot change without a shared upstream bridge, so the pci=disable_acs_redir= hint was not actionable there and the ACS walk only cost config space reads - Folded the Request Redirect rule into pci_acs_rr_ineffective(), so pci_acs_flags_enabled() and the Intel SPT PCH quirk share one copy - Renamed pci_acs_egress_ctrl_set() to pci_acs_egress_ctrl_is_set(), it reads the bit rather than setting it - Reworded the blocked-path warning: ACS may also leave the direct route indeterminate rather than blocked - Added KUnit coverage for the shared-bus guard, a device with no ACS capability and an unreadable ACS Control register - Added the missing Fixes: tags, a second one on the pci_p2pdma_add_resource() unwinding fix (the dangling devres action dates to f58ef9d1d135) and one on the Egress Control isolation change - Link to v2: https://patch.msgid.link/20260806-fix-p2p-acs-v2-0-0cec14812965@nvidia.com Changes in v2: - Added Logan's ROB tags - Added commas in Documentation patch - Link to v1: https://patch.msgid.link/20260802-fix-p2p-acs-v1-0-a7c5eb64fff6@nvidia.com --- Leon Romanovsky (19): PCI/P2PDMA: Honor device-specific ACS redirection PCI/P2PDMA: Document the TLP attribute assumptions PCI/P2PDMA: Derive routing from directional ACS controls PCI: Reject unreadable ACS controls in isolation checks PCI/P2PDMA: Evaluate ACS controls at the path divergence PCI/P2PDMA: Document directional ACS routing PCI/P2PDMA: Collect the path's ACS controls before deciding PCI/P2PDMA: Answer routing per TLP class PCI/P2PDMA: Route Relaxed Ordering Completions directly PCI/P2PDMA: Reject Translated Requests blocked by Translation Blocking PCI/P2PDMA: Route Translated Requests under Direct Translated P2P PCI/P2PDMA: Log detailed ACS routing diagnostics PCI/P2PDMA: Add KUnit tests for the ACS routing decisions PCI/P2PDMA: Test the ACS P2P routing walk PCI: Add KUnit coverage for ACS isolation checks PCI/P2PDMA: Document TLP-class routing PCI/P2PDMA: Let a client declare that it selects ATS per mapping PCI/P2PDMA: Evaluate the ATS path for clients with ATS enabled PCI/P2PDMA: Test the routing of clients with ATS enabled Documentation/admin-guide/kernel-parameters.txt | 11 +- Documentation/driver-api/pci/p2pdma.rst | 105 ++ drivers/pci/Kconfig | 15 + drivers/pci/Makefile | 1 + drivers/pci/p2pdma.c | 942 +++++++++++++++-- drivers/pci/pci.c | 8 +- drivers/pci/pci.h | 57 ++ drivers/pci/pci_acs_test.c | 1225 +++++++++++++++++++++++ drivers/pci/quirks.c | 8 +- include/linux/pci-p2pdma.h | 12 +- 10 files changed, 2292 insertions(+), 92 deletions(-) --- base-commit: 36038f0e8377ef316b723d0d85b1510bc64069ab change-id: 20260821-fix-p2p-acs-v4-0-e72455e3a261 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

23 hours, 44 minutes

[PATCH] dma-buf: Restore the scatterlist entry count before freeing

by Leon Romanovsky

From: Leon Romanovsky <leonro(a)nvidia.com> dma_buf_phys_vec_to_sgt() clears orig_nents to mark the returned table as DMA-only. Since sg_free_table() uses orig_nents to walk and free the scatterlist, dma_buf_free_sgt() leaks the allocation on every successful map/unmap cycle. Restore orig_nents from nents before freeing the table. The helper allocates the DMA list directly, so nents retains the allocation count, including for chained scatterlists. The reported kmemleak output was: KMEMLEAK LEAK: 2 driver-related leak(s) KMEMLEAK LEAK: unreferenced object 0xff11000125ceff00 (size 32): KMEMLEAK LEAK: comm dtr, pid 4432, jiffies 4295031027 KMEMLEAK LEAK: hex dump (first 32 bytes): KMEMLEAK LEAK: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ KMEMLEAK LEAK: 00 00 01 00 28 38 00 00 00 10 00 00 00 00 00 00 ....(8.......... KMEMLEAK LEAK: backtrace (crc 4e8077f2): KMEMLEAK LEAK: __kmalloc_noprof+0x451/0x8b0 KMEMLEAK LEAK: __sg_alloc_table+0x2a0/0x4d0 KMEMLEAK LEAK: sg_alloc_table+0x24/0x170 KMEMLEAK LEAK: dma_buf_phys_vec_to_sgt+0x84f/0xed0 KMEMLEAK LEAK: 0xffffffffa1ad21a8 KMEMLEAK LEAK: dma_buf_map_attachment+0x138/0x690 KMEMLEAK LEAK: ib_umem_dmabuf_map_pages+0x249/0xc90 [ib_core] KMEMLEAK LEAK: 0xffffffffa138f8d2 KMEMLEAK LEAK: 0xffffffffa1396abe KMEMLEAK LEAK: 0xffffffffa1331a5f KMEMLEAK LEAK: 0xffffffffa13320dd KMEMLEAK LEAK: 0xffffffffa1ad696d KMEMLEAK LEAK: 0xffffffffa1acecc7 KMEMLEAK LEAK: 0xffffffffa1acfd17 KMEMLEAK LEAK: __x64_sys_ioctl+0x72c/0x11f0 KMEMLEAK LEAK: do_syscall_64+0xa1/0x4f0 KMEMLEAK LEAK: unreferenced object 0xff1100016dbf3a80 (size 32): KMEMLEAK LEAK: comm dtr, pid 4432, jiffies 4295034705 KMEMLEAK LEAK: hex dump (first 32 bytes): KMEMLEAK LEAK: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ KMEMLEAK LEAK: 00 20 10 00 28 38 00 00 00 10 00 00 00 00 00 00 . ..(8.......... Fixes: 3aa31a8bb11e ("dma-buf: provide phys_vec to scatter-gather mapping routine") Signed-off-by: Leon Romanovsky <leonro(a)nvidia.com> --- drivers/dma-buf/dma-buf-mapping.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/dma-buf/dma-buf-mapping.c b/drivers/dma-buf/dma-buf-mapping.c index 833be519e1e6..cbdf99cb0e05 100644 --- a/drivers/dma-buf/dma-buf-mapping.c +++ b/drivers/dma-buf/dma-buf-mapping.c @@ -251,6 +251,8 @@ void dma_buf_free_sgt(struct dma_buf_attachment *attach, struct sg_table *sgt, sg_dma_len(sgl), dir, DMA_ATTR_MMIO); } + /* Restore the allocation count cleared for the DMA-only table. */ + sgt->orig_nents = sgt->nents; sg_free_table(sgt); kfree(dma->state); kfree(dma); --- base-commit: 39d3758108bb0ef9da484062d65288bbe9cada0e change-id: 20261013-dma-buf-fixes-99dd3fd00f48 Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

1 day, 3 hours

Re: [PATCH 0/4] media: synchronize CPU access to imported DMA-BUFs

by Laurent Pinchart

On Mon, Oct 19, 2026 at 09:14:07AM +0200, Karl Mehltretter wrote: > UVC and vivid access imported DMA-BUFs with the CPU without cache > synchronization. On a Pi 400, captured data remained in the CPU cache > while physical RAM was stale. > > Add an opt-in queue flag to bracket CPU access from buf_prepare() through > buf_finish(). The allocator cannot imply CPU use because some vb2-vmalloc > drivers pass buffers to hardware. Patch 1 balances finish operations in > VIDIOC_REMOVE_BUFS so removing prepared buffers closes this interval. This seems completely wrong. > This follows the per-queue flag proposed here: > https://lists.openwall.net/linux-kernel/2024/06/20/236 > > Based on Linux 7.3. Tests cover the same code on these earlier bases: > > - Pi 400, 7.3-rc4, all four patches: eight 640x480 YUYV frames per run, > imported CMA DMA-BUFs with a DRM device mapping: > > Path Runs Stale frames > UVC, vb2-vmalloc 12 0/96 > vivid, vb2-vmalloc 12 0/96 > vivid, vb2-dma-contig 12 0/96 > > All six lifecycle cases passed with both vivid allocators. Read-only > output USERPTR passed. The test added no warnings or failed CPU-access > callbacks. A control without the DRM mapping found 4/16 stale frames. > > - SAM9X75 (ARMv5), 6.18 backport of all four patches: the baseline > PREPARE_BUF/REMOVE_BUFS imbalance was fixed. USERPTR and six lifecycle > cases passed. All 128 vivid and 96 UVC frames matched RAM, with 100/100 > begin/end calls. The baseline was already coherent. > > - BeagleV Ahead (RISC-V), 7.3-rc7, patches 1, 2 and 4: read-only USERPTR, > six traced lifecycle cases and 60 repeats passed with balanced callbacks > and no kernel diagnostics. A vendor 5.10 backport of patches 2 and 3 > captured 96 UVC frames without stale data, with 100/100 begin/end calls. > Its baseline was already coherent. > > Karl Mehltretter (4): > media: videobuf2: finish prepared buffers in VIDIOC_REMOVE_BUFS > media: videobuf2: add opt-in DMA-BUF CPU access > media: uvcvideo: synchronize imported DMA-BUFs for CPU access > media: vivid: synchronize imported DMA-BUFs for CPU access > > .../media/common/videobuf2/videobuf2-core.c | 96 ++++++++++++++++++- > .../common/videobuf2/videobuf2-dma-contig.c | 5 +- > .../media/common/videobuf2/videobuf2-dma-sg.c | 5 +- > .../common/videobuf2/videobuf2-vmalloc.c | 5 +- > drivers/media/test-drivers/vivid/vivid-core.c | 1 + > drivers/media/usb/uvc/uvc_queue.c | 1 + > include/media/videobuf2-core.h | 12 ++- > 7 files changed, 116 insertions(+), 9 deletions(-) > > > base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222 -- Regards, Laurent Pinchart

1 day, 19 hours

Re: [PATCH 2/3] iio: adc: add stm32 mdf support

by Jonathan Cameron

On Thu, 1 Oct 2026 16:56:46 +0200 Olivier Moysan <olivier.moysan(a)foss.st.com> wrote: > Add the STM32 Multi-function Digital Filter (MDF) core, serial interface > and digital filter drivers. The MDF converts bitstreams from sigma-delta > modulators or digital microphones into samples exposed through IIO. > > Audio: capture PDM microphones via cyclic DMA for an ASoC consumer. > Support CIC scaling and filtering, synchronized and interleaving modes. > Audio use case requires a DMIC filter, and a separate ASoC DAI. > > Analog: expose sigma-delta modulators as IIO voltage channels with > direct reads or DMA buffering mode. STM32 timer triggers can be used as > clock source. > Analog use case requires an IIO backend for the SD modulator. > > Signed-off-by: Olivier Moysan <olivier.moysan(a)foss.st.com> I'm not going to spend long on this today, but a few trivial things noted from a quick glance. > diff --git a/drivers/iio/adc/stm32-mdf-serial.c b/drivers/iio/adc/stm32-mdf-serial.c > new file mode 100644 > index 000000000000..15a58cf833be > --- /dev/null > +++ b/drivers/iio/adc/stm32-mdf-serial.c ... > + > +int stm32_mdf_sitf_stop(struct stm32_mdf_sitf *sitf) > +{ > + int ret = 0; > + > + spin_lock(&sitf->lock); Use guard() for cases like this. Simplifies the flow and helps readabilty as a result. Everyone loves an early return. > + > + if (!sitf->refcnt) { > + dev_err(sitf->dev, "Unbalanced serial interface stop ?\n"); > + ret = -EPERM; > + goto out; > + } else { > + sitf->refcnt--; > + } > + > + if (!sitf->refcnt) > + ret = regmap_clear_bits(sitf->regmap, MDF_SITFCR_REG, MDF_SITFCR_SITFEN); > + > +out: > + spin_unlock(&sitf->lock); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(stm32_mdf_sitf_stop); > > +static int stm32_mdf_sitf_runtime_suspend(struct device *dev) > +{ Add a comment on why you need these. > + return 0; > +} > + > +static int stm32_mdf_sitf_runtime_resume(struct device *dev) > +{ > + return 0; > +} > diff --git a/drivers/iio/adc/stm32-mdf.h b/drivers/iio/adc/stm32-mdf.h > new file mode 100644 > index 000000000000..7e403c26d4dc > --- /dev/null > +++ b/drivers/iio/adc/stm32-mdf.h > @@ -0,0 +1,312 @@ > +/* SPDX-License-Identifier: GPL-2.0-or-later */ > +/* > + * This file is part of STM32 MDF driver > + * > + * Copyright (C) 2023, STMicroelectronics - All Rights Reserved I'd guess you'll modify it enough that this might need an update! > +/* MDF_SIDR: Size Identification Register */ > +#define MDF_SIDR_SID_MASK GENMASK(31, 0) > +#define MDF_SIDR_SID(v) FIELD_PREP(MDF_SIDR_SID_MASK, v) I'd not bother with the second macro. It is only a little shorter than FIELD_PREP() in most case. >

2 days, 8 hours

Re: [PATCH rdma-rc 0/2] RDMA/uverbs: Fix DMABUF lifetime bugs

by Leon Romanovsky

On Thu, 15 Oct 2026 08:36:35 +0000, Deep Shah wrote: > Fix two lifetime bugs in the uverbs DMABUF export path. Patch 1 fixes > leaked uobject and ufile references when the uverbs FD is closed first. > Patch 2 fixes a use-after-free when dma-buf release races with ufile > cleanup. > > Tested on mainline 4056b3c9d3c9 in x86_64 QEMU with KASAN and lockdep, > using test-only siw export hooks. The unpatched kernel reproduces both > bugs. Patch 1 fixes the leak, confirmed by tracing ufile release. With > both patches, the same tests complete without KASAN or lockdep reports. > > [...] Applied, thanks! [1/2] RDMA/uverbs: Fix uobject leak in DMABUF release https://git.kernel.org/rdma/rdma/c/4a953ee228f554 [2/2] RDMA/uverbs: Fix DMABUF use-after-free during ufile cleanup https://git.kernel.org/rdma/rdma/c/2854f9025d4ef6 Best regards, -- Leon Romanovsky <leon(a)kernel.org>

2 days, 22 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig