Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

23 participants
7061 discussions

Re: [PATCH 05/19] dma-buf/selftests: test RCU ops and inline lock

by tursulin＠ursulin.net

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

8 months

[PATCH 00/14] Assorted kernel-doc fixes

by Bagas Sanjaya

Hi, Here are assorted kernel-doc fixes for 6.19 cycle. As the name implies, for the merging strategy, the patches can be taken by respective maintainers to appropriate fixes branches (targetting 6.19 of course) (e.g. for mm it will be mm-hotfixes). Enjoy! Bagas Sanjaya (14): genalloc: Describe @start_addr parameter in genpool_algo_t mm: Describe @flags parameter in memalloc_flags_save() textsearch: Describe @list member in ts_ops search mm: vmalloc: Fix up vrealloc_node_align() kernel-doc macro name mm, kfence: Describe @slab parameter in __kfence_obj_info() virtio: Describe @map and @vmap members in virtio_device struct fs: Describe @isnew parameter in ilookup5_nowait() VFS: fix __start_dirop() kernel-doc warnings drm/amd/display: Don't use kernel-doc comment in dc_register_software_state struct drm/amdgpu: Describe @AMD_IP_BLOCK_TYPE_RAS in amd_ip_block_type enum drm/gem/shmem: Describe @shmem and @size parameters drm/scheduler: Describe @result in drm_sched_job_done() drm/gpusvm: Fix drm_gpusvm_pages_valid_unlocked() kernel-doc comment net: bridge: Describe @tunnel_hash member in net_bridge_vlan_group struct drivers/gpu/drm/amd/display/dc/dc.h | 2 +- drivers/gpu/drm/amd/include/amd_shared.h | 1 + drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++- drivers/gpu/drm/drm_gpusvm.c | 4 ++-- drivers/gpu/drm/scheduler/sched_main.c | 1 + fs/inode.c | 1 + fs/namei.c | 3 ++- include/linux/genalloc.h | 1 + include/linux/kfence.h | 1 + include/linux/sched/mm.h | 1 + include/linux/textsearch.h | 1 + include/linux/virtio.h | 2 ++ mm/vmalloc.c | 2 +- net/bridge/br_private.h | 1 + 14 files changed, 18 insertions(+), 6 deletions(-) base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8 -- An old man doll... just what I always wanted! - Clara

8 months

[PATCH v6 00/11] vfio/pci: Allow MMIO regions to be exported through dma-buf

by Leon Romanovsky

Changelog: v6: * Fixed wrong error check from pcim_p2pdma_init(). * Documented pcim_p2pdma_provider() function. * Improved commit messages. * Added VFIO DMA-BUF selftest. * Added __counted_by(nr_ranges) annotation to struct vfio_device_feature_dma_buf. * Fixed error unwind when dma_buf_fd() fails. * Document latest changes to p2pmem. * Removed EXPORT_SYMBOL_GPL from pci_p2pdma_map_type. * Moved DMA mapping logic to DMA-BUF. * Removed types patch to avoid dependencies between subsystems. * Moved vfio_pci_dma_buf_move() in err_undo block. * Added nvgrace patch. v5: https://lore.kernel.org/all/cover.1760368250.git.leon@kernel.org * Rebased on top of v6.18-rc1. * Added more validation logic to make sure that DMA-BUF length doesn't overflow in various scenarios. * Hide kernel config from the users. * Fixed type conversion issue. DMA ranges are exposed with u64 length, but DMA-BUF uses "unsigned int" as a length for SG entries. * Added check to prevent from VFIO drivers which reports BAR size different from PCI, do not use DMA-BUF functionality. v4: https://lore.kernel.org/all/cover.1759070796.git.leon@kernel.org * Split pcim_p2pdma_provider() to two functions, one that initializes array of providers and another to return right provider pointer. v3: https://lore.kernel.org/all/cover.1758804980.git.leon@kernel.org * Changed pcim_p2pdma_enable() to be pcim_p2pdma_provider(). * Cache provider in vfio_pci_dma_buf struct instead of BAR index. * Removed misleading comment from pcim_p2pdma_provider(). * Moved MMIO check to be in pcim_p2pdma_provider(). v2: https://lore.kernel.org/all/cover.1757589589.git.leon@kernel.org/ * Added extra patch which adds new CONFIG, so next patches can reuse * it. * Squashed "PCI/P2PDMA: Remove redundant bus_offset from map state" into the other patch. * Fixed revoke calls to be aligned with true->false semantics. * Extended p2pdma_providers to be per-BAR and not global to whole * device. * Fixed possible race between dmabuf states and revoke. * Moved revoke to PCI BAR zap block. v1: https://lore.kernel.org/all/cover.1754311439.git.leon@kernel.org * Changed commit messages. * Reused DMA_ATTR_MMIO attribute. * Returned support for multiple DMA ranges per-dMABUF. v0: https://lore.kernel.org/all/cover.1753274085.git.leonro@nvidia.com --------------------------------------------------------------------------- Based on "[PATCH v6 00/16] dma-mapping: migrate to physical address-based API" https://lore.kernel.org/all/cover.1757423202.git.leonro@nvidia.com/ series. --------------------------------------------------------------------------- This series extends the VFIO PCI subsystem to support exporting MMIO regions from PCI device BARs as dma-buf objects, enabling safe sharing of non-struct page memory with controlled lifetime management. This allows RDMA and other subsystems to import dma-buf FDs and build them into memory regions for PCI P2P operations. The series supports a use case for SPDK where a NVMe device will be owned by SPDK through VFIO but interacting with a RDMA device. The RDMA device may directly access the NVMe CMB or directly manipulate the NVMe device's doorbell using PCI P2P. However, as a general mechanism, it can support many other scenarios with VFIO. This dmabuf approach can be usable by iommufd as well for generic and safe P2P mappings. In addition to the SPDK use-case mentioned above, the capability added in this patch series can also be useful when a buffer (located in device memory such as VRAM) needs to be shared between any two dGPU devices or instances (assuming one of them is bound to VFIO PCI) as long as they are P2P DMA compatible. The implementation provides a revocable attachment mechanism using dma-buf move operations. MMIO regions are normally pinned as BARs don't change physical addresses, but access is revoked when the VFIO device is closed or a PCI reset is issued. This ensures kernel self-defense against potentially hostile userspace. The series includes significant refactoring of the PCI P2PDMA subsystem to separate core P2P functionality from memory allocation features, making it more modular and suitable for VFIO use cases that don't need struct page support. ----------------------------------------------------------------------- The series is based originally on https://lore.kernel.org/all/20250307052248.405803-1-vivek.kasireddy@intel.c… but heavily rewritten to be based on DMA physical API. ----------------------------------------------------------------------- The WIP branch can be found here: https://git.kernel.org/pub/scm/linux/kernel/git/leon/linux-rdma.git/log/?h=… Thanks --- Jason Gunthorpe (2): PCI/P2PDMA: Document DMABUF model vfio/nvgrace: Support get_dmabuf_phys Leon Romanovsky (7): PCI/P2PDMA: Separate the mmap() support from the core logic PCI/P2PDMA: Simplify bus address mapping API PCI/P2PDMA: Refactor to separate core P2P functionality from memory allocation PCI/P2PDMA: Provide an access to pci_p2pdma_map_type() function dma-buf: provide phys_vec to scatter-gather mapping routine vfio/pci: Enable peer-to-peer DMA transactions by default vfio/pci: Add dma-buf export support for MMIO regions Vivek Kasireddy (2): vfio: Export vfio device get and put registration helpers vfio/pci: Share the core device pointer while invoking feature functions Documentation/driver-api/pci/p2pdma.rst | 95 +++++++--- block/blk-mq-dma.c | 2 +- drivers/dma-buf/dma-buf.c | 235 ++++++++++++++++++++++++ drivers/iommu/dma-iommu.c | 4 +- drivers/pci/p2pdma.c | 182 +++++++++++++----- drivers/vfio/pci/Kconfig | 3 + drivers/vfio/pci/Makefile | 1 + drivers/vfio/pci/nvgrace-gpu/main.c | 56 ++++++ drivers/vfio/pci/vfio_pci.c | 5 + drivers/vfio/pci/vfio_pci_config.c | 22 ++- drivers/vfio/pci/vfio_pci_core.c | 56 ++++-- drivers/vfio/pci/vfio_pci_dmabuf.c | 315 ++++++++++++++++++++++++++++++++ drivers/vfio/pci/vfio_pci_priv.h | 23 +++ drivers/vfio/vfio_main.c | 2 + include/linux/dma-buf.h | 18 ++ include/linux/pci-p2pdma.h | 120 +++++++----- include/linux/vfio.h | 2 + include/linux/vfio_pci_core.h | 42 +++++ include/uapi/linux/vfio.h | 27 +++ kernel/dma/direct.c | 4 +- mm/hmm.c | 2 +- 21 files changed, 1077 insertions(+), 139 deletions(-) --- base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787 change-id: 20251016-dmabuf-vfio-6cef732adf5a Best regards, -- Leon Romanovsky <leonro(a)nvidia.com>

8 months

[PATCH] dma-buf: really enable DMABUF_DEBUG by default on DEBUG kernels

by Lukas Bulwahn

From: Lukas Bulwahn <lukas.bulwahn(a)redhat.com> The intent of commit 646013f513f3 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG kernels") is clear, but it mixes up the config option name. The config option for kernel debugging is named DEBUG_KERNEL, not DEBUG. Fix up the DMABUF_DEBUG definition to use the intended name. Fixes: 646013f513f3 ("dma-buf: enable DMABUF_DEBUG by default on DEBUG kernels") Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)redhat.com> --- drivers/dma-buf/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig index fdd823e446cc..426c9ad3364f 100644 --- a/drivers/dma-buf/Kconfig +++ b/drivers/dma-buf/Kconfig @@ -55,7 +55,7 @@ config DMABUF_MOVE_NOTIFY config DMABUF_DEBUG bool "DMA-BUF debug checks" depends on DMA_SHARED_BUFFER - default y if DEBUG + default y if DEBUG_KERNEL help This option enables additional checks for DMA-BUF importers and exporters. Specifically it validates that importers do not peek at the -- 2.51.1

8 months

Independence for dma_fences! v4

by Christian König

Hi everyone, dma_fences have ever lived under the tyranny dictated by the module lifetime of their issuer, leading to crashes should anybody still holding a reference to a dma_fence when the module of the issuer was unloaded. The basic problem is that when buffer are shared between drivers dma_fence objects can leak into external drivers and stay there even after they are signaled. The dma_resv object for example only lazy releases dma_fences. So what happens is that when the module who originally created the dma_fence unloads the dma_fence_ops function table becomes unavailable as well and so any attempt to release the fence crashes the system. Previously various approaches have been discussed, including changing the locking semantics of the dma_fence callbacks (by me) as well as using the drm scheduler as intermediate layer (by Sima) to disconnect dma_fences from their actual users, but none of them are actually solving all problems. Tvrtko did some really nice prerequisite work by protecting the returned strings of the dma_fence_ops by RCU. This way dma_fence creators where able to just wait for an RCU grace period after fence signaling before they could be save to free those data structures. Now this patch set here goes a step further and protects the whole dma_fence_ops structure by RCU, so that after the fence signals the pointer to the dma_fence_ops is set to NULL when there is no wait nor release callback given. All functionality which use the dma_fence_ops reference are put inside an RCU critical section, except for the deprecated issuer specific wait and of course the optional release callback. Additional to the RCU changes the lock protecting the dma_fence state previously had to be allocated external. This set here now changes the functionality to make that external lock optional and allows dma_fences to use an inline lock and be self contained. v4: Rebases the whole set on upstream changes, especially the cleanup from Philip in patch "drm/amdgpu: independence for the amdkfd_fence!". Adding two patches which brings the DMA-fence self tests up to date. The first selftest changes removes the mock_wait and so actually starts testing the default behavior instead of some hacky implementation in the test. This one should probably go upstream independent of this set. The second drops the mock_fence as well and tests the new RCU and inline spinlock functionality. Especially the first patch still needs a Reviewed-by, apart from that I think I've addressed all review comments. The plan is to push the core DMA-buf changes to drm-misc-next and then the driver specific changes through the driver channels as approprite. Please review and comment, Christian.

8 months, 1 week

[PATCH net-next v2 0/7] net: ethernet: ti: am65-cpsw: add AF_XDP zero copy support

by Roger Quadros

This series adds AF_XDP zero coppy support to am65-cpsw driver. Tests were performed on AM62x-sk with xdpsock application [1]. A clear improvement is seen in 64 byte packets on Transmit (txonly) and receive (rxdrop). 1500 byte test seems to be limited by line rate (1G link) so no improvement seen there in packet rate. A test on higher speed link (or PHY-less setup) might be worthwile. There is some issue during l2fwd with 64 byte packets and benchmark results show 0. This issue needs to be debugged further. A 512 byte l2fwd test result has been added to compare instead. AF_XDP performance using 64 byte packets in Kpps. Benchmark: XDP-SKB XDP-Native XDP-Native(ZeroCopy) rxdrop 322 491 845 txonly 390 394 723 l2fwd 205 257 0 AF_XDP performance using 512 byte packets in Kpps. l2fwd 140 167 231 AF_XDP performance using 1500 byte packets in Kpps. Benchmark: XDP-SKB XDP-Native XDP-Native(ZeroCopy) rxdrop 82 82 82 txonly 82 82 82 l2fwd 82 82 82 [1]: https://github.com/xdp-project/bpf-examples/tree/master/AF_XDP-example Signed-off-by: Roger Quadros <rogerq(a)kernel.org> --- Changes in v2: - Prevent crash on systems with 1 of 2 ports disabled in device tree. check for valid ndev before registering/unregistering XDP RXQ. Reported-by: Meghana Malladi <m-malladi(a)ti.com> - Retain page pool on XDP program exchangae so we don't have to re-alloacate memory. - Fix clearing of irq_disabled flag in am65_cpsw_nuss_rx_poll(). - Link to v1: https://lore.kernel.org/r/20250520-am65-cpsw-xdp-zc-v1-0-45558024f566@kerne… --- Roger Quadros (7): net: ethernet: ti: am65-cpsw: fix BPF Program change on multi-port CPSW net: ethernet: ti: am65-cpsw: Retain page_pool on XDP program exchange net: ethernet: ti: am65-cpsw: add XSK pool helpers net: ethernet: ti: am65-cpsw: Add AF_XDP zero copy for RX net: ethernet: ti: am65-cpsw: Add AF_XDP zero copy for TX net: ethernet: ti: am65-cpsw: enable zero copy in XDP features net: ethernet: ti: am65-cpsw: Fix clearing of irq_disabled flag in rx_poll drivers/net/ethernet/ti/Makefile | 2 +- drivers/net/ethernet/ti/am65-cpsw-nuss.c | 583 ++++++++++++++++++++++++++----- drivers/net/ethernet/ti/am65-cpsw-nuss.h | 37 +- drivers/net/ethernet/ti/am65-cpsw-xdp.c | 155 ++++++++ 4 files changed, 692 insertions(+), 85 deletions(-) --- base-commit: a0c3aefb08cd81864b17c23c25b388dba90b9dad change-id: 20250225-am65-cpsw-xdp-zc-2af9e4be1356 Best regards, -- Roger Quadros <rogerq(a)kernel.org>

8 months, 1 week

[RFC v2 03/11] block: move around bio flagging helpers

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

8 months, 1 week

[RFC v2 00/11] Add dmabuf read/write via io_uring

by asml.silence＠gmail.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

8 months, 1 week

[PATCH v3] drm: Fix object leak in DRM_IOCTL_GEM_CHANGE_HANDLE

by Karol Wachowski

Add missing drm_gem_object_put() call when drm_gem_object_lookup() successfully returns an object. This fixes a GEM object reference leak that can prevent driver modules from unloading when using prime buffers. Fixes: 53096728b891 ("drm: Add DRM prime interface to reassign GEM handle") Cc: <stable(a)vger.kernel.org> # v6.18+ Signed-off-by: Karol Wachowski <karol.wachowski(a)linux.intel.com> --- Changes between v3 and v2: - correctly add CC: tag this time Changes between v1 and v2: - move setting ret value under if branch as suggested in review - add Cc: stable 6.18+ --- drivers/gpu/drm/drm_gem.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ca1956608261..bcc08a6aebf8 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1010,8 +1010,10 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, if (!obj) return -ENOENT; - if (args->handle == args->new_handle) - return 0; + if (args->handle == args->new_handle) { + ret = 0; + goto out; + } mutex_lock(&file_priv->prime.lock); @@ -1043,6 +1045,8 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, out_unlock: mutex_unlock(&file_priv->prime.lock); +out: + drm_gem_object_put(obj); return ret; } -- 2.43.0

8 months, 1 week

[PATCH v2] drm: Fix object leak in DRM_IOCTL_GEM_CHANGE_HANDLE

by Karol Wachowski

Add missing drm_gem_object_put() call when drm_gem_object_lookup() successfully returns an object. This fixes a GEM object reference leak that can prevent driver modules from unloading when using prime buffers. Fixes: 53096728b891 ("drm: Add DRM prime interface to reassign GEM handle") Signed-off-by: Karol Wachowski <karol.wachowski(a)linux.intel.com> --- Changes between v1 and v2: - move setting ret value under if branch as suggested in review - add Cc: stable 6.18+ --- drivers/gpu/drm/drm_gem.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ca1956608261..bcc08a6aebf8 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1010,8 +1010,10 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, if (!obj) return -ENOENT; - if (args->handle == args->new_handle) - return 0; + if (args->handle == args->new_handle) { + ret = 0; + goto out; + } mutex_lock(&file_priv->prime.lock); @@ -1043,6 +1045,8 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, out_unlock: mutex_unlock(&file_priv->prime.lock); +out: + drm_gem_object_put(obj); return ret; } -- 2.43.0

8 months, 1 week

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig