Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

16 participants
5247 discussions

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.

9 months

[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>

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

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

9 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

9 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

9 months, 1 week

[PATCH] 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> --- drivers/gpu/drm/drm_gem.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index ca1956608261..e150bc1ce65a 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -1001,7 +1001,7 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, { struct drm_gem_change_handle *args = data; struct drm_gem_object *obj; - int ret; + int ret = 0; if (!drm_core_check_feature(dev, DRIVER_GEM)) return -EOPNOTSUPP; @@ -1011,7 +1011,7 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data, return -ENOENT; if (args->handle == args->new_handle) - return 0; + goto out; mutex_lock(&file_priv->prime.lock); @@ -1043,6 +1043,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

9 months, 1 week

[PATCH bpf 1/2] bpf: Fix truncated dmabuf iterator reads

by T.J. Mercier

If there is a large number (hundreds) of dmabufs allocated, the text output generated from dmabuf_iter_seq_show can exceed common user buffer sizes (e.g. PAGE_SIZE) necessitating multiple start/stop cycles to iterate through all dmabufs. However the dmabuf iterator currently returns NULL in dmabuf_iter_seq_start for all non-zero pos values, which results in the truncation of the output before all dmabufs are handled. After dma_buf_iter_begin / dma_buf_iter_next, the refcount of the buffer is elevated so that the BPF iterator program can run without holding any locks. When a stop occurs, instead of immediately dropping the reference on the buffer, stash a pointer to the buffer in seq->priv until either start is called or the iterator is released. This also enables the resumption of iteration without first walking through the list of dmabufs based on the pos value. Fixes: 76ea95534995 ("bpf: Add dmabuf iterator") Signed-off-by: T.J. Mercier <tjmercier(a)google.com> --- kernel/bpf/dmabuf_iter.c | 56 +++++++++++++++++++++++++++++++++++----- 1 file changed, 49 insertions(+), 7 deletions(-) diff --git a/kernel/bpf/dmabuf_iter.c b/kernel/bpf/dmabuf_iter.c index 4dd7ef7c145c..cd500248abd9 100644 --- a/kernel/bpf/dmabuf_iter.c +++ b/kernel/bpf/dmabuf_iter.c @@ -6,10 +6,33 @@ #include <linux/kernel.h> #include <linux/seq_file.h> +struct dmabuf_iter_priv { + /* + * If this pointer is non-NULL, the buffer's refcount is elevated to + * prevent destruction between stop/start. If reading is not resumed and + * start is never called again, then dmabuf_iter_seq_fini drops the + * reference when the iterator is released. + */ + struct dma_buf *dmabuf; +}; + static void *dmabuf_iter_seq_start(struct seq_file *seq, loff_t *pos) { - if (*pos) - return NULL; + struct dmabuf_iter_priv *p = seq->private; + + if (*pos) { + struct dma_buf *dmabuf = p->dmabuf; + + if (!dmabuf) + return NULL; + + /* + * Always resume from where we stopped, regardless of the value + * of pos. + */ + p->dmabuf = NULL; + return dmabuf; + } return dma_buf_iter_begin(); } @@ -54,8 +77,11 @@ static void dmabuf_iter_seq_stop(struct seq_file *seq, void *v) { struct dma_buf *dmabuf = v; - if (dmabuf) - dma_buf_put(dmabuf); + if (dmabuf) { + struct dmabuf_iter_priv *p = seq->private; + + p->dmabuf = dmabuf; + } } static const struct seq_operations dmabuf_iter_seq_ops = { @@ -71,11 +97,27 @@ static void bpf_iter_dmabuf_show_fdinfo(const struct bpf_iter_aux_info *aux, seq_puts(seq, "dmabuf iter\n"); } +static int dmabuf_iter_seq_init(void *priv, struct bpf_iter_aux_info *aux) +{ + struct dmabuf_iter_priv *p = (struct dmabuf_iter_priv *)priv; + + p->dmabuf = NULL; + return 0; +} + +static void dmabuf_iter_seq_fini(void *priv) +{ + struct dmabuf_iter_priv *p = (struct dmabuf_iter_priv *)priv; + + if (p->dmabuf) + dma_buf_put(p->dmabuf); +} + static const struct bpf_iter_seq_info dmabuf_iter_seq_info = { .seq_ops = &dmabuf_iter_seq_ops, - .init_seq_private = NULL, - .fini_seq_private = NULL, - .seq_priv_size = 0, + .init_seq_private = dmabuf_iter_seq_init, + .fini_seq_private = dmabuf_iter_seq_fini, + .seq_priv_size = sizeof(struct dmabuf_iter_priv), }; static struct bpf_iter_reg bpf_dmabuf_reg_info = { base-commit: 30f09200cc4aefbd8385b01e41bde2e4565a6f0e -- 2.52.0.177.g9f829587af-goog

9 months, 1 week

Re: [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled()

by kernel test robot

Hello, kernel test robot noticed "Oops:general_protection_fault,probably_for_non-canonical_address#:#[##]SMP_KASAN_PTI" on: commit: 142f20971642be40507d3a0bc94e905e251db81a ("[PATCH 1/2] dma-buf: Add __dma_fence_is_signaled()") url: https://github.com/intel-lab-lkp/linux/commits/Philipp-Stanner/dma-buf-dma-… base: git://linuxtv.org/sailus/media_tree.git master patch link: https://lore.kernel.org/all/20251125104443.82974-2-phasta@kernel.org/ patch subject: [PATCH 1/2] dma-buf: Add __dma_fence_is_signaled() in testcase: lkvs version: lkvs-x86_64-6505b18-1_20251124 with following parameters: test: rapl-client config: x86_64-rhel-9.4-func compiler: gcc-14 test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory (please refer to attached dmesg/kmsg for entire log/backtrace) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <oliver.sang(a)intel.com> | Closes: https://lore.kernel.org/oe-lkp/202512092317.8cf778a-lkp@intel.com [ 46.662293][ T179] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 46.680656][ T40] sd 1:0:0:0: [sda] Preferred minimum I/O size 4096 bytes [ 46.682302][ T59] i915 0000:00:02.0: Direct firmware load for i915/skl_dmc_ver1_27.bin failed with error -2 [ 46.698362][ T59] i915 0000:00:02.0: [drm] Failed to load DMC firmware i915/skl_dmc_ver1_27.bin (-ENOENT). Disabling runtime power management. [ 46.711256][ T59] i915 0000:00:02.0: [drm] DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git [ 46.725941][ T12] Oops: general protection fault, probably for non-canonical address 0xdffffc01544551ba: 0000 [#1] SMP KASAN PTI [ 46.725953][ T179] ------------[ cut here ]------------ [ 46.737600][ T12] KASAN: probably user-memory-access in range [0x0000000aa22a8dd0-0x0000000aa22a8dd7] [ 46.737612][ T12] CPU: 3 UID: 0 PID: 12 Comm: kworker/u16:0 Tainted: G S I 6.18.0-rc5-00236-g142f20971642 #1 PREEMPT(voluntary) [ 46.742889][ T179] Fence 0000:00:02.0:[i915]:9:2 released with pending signals! [ 46.752212][ T12] Tainted: [S]=CPU_OUT_OF_SPEC, [I]=FIRMWARE_WORKAROUND [ 46.752217][ T12] Hardware name: Dell Inc. OptiPlex 7040/0Y7WYT, BIOS 1.1.1 10/07/2015 [ 46.752220][ T12] Workqueue: i915 __i915_gem_free_work [i915] [ 46.765216][ T179] WARNING: CPU: 0 PID: 179 at drivers/dma-buf/dma-fence.c:555 dma_fence_release (kbuild/src/consumer/drivers/dma-buf/dma-fence.c:555 (discriminator 1)) [ 46.772517][ T12] [ 46.772521][ T12] RIP: 0010:__list_add_valid_or_report (kbuild/src/consumer/lib/list_debug.c:29) [ 46.772528][ T12] Code: 8b 98 fe 48 89 d3 48 85 d2 0f 84 af 8b 98 fe 4c 8d 62 08 48 89 fd 49 89 f5 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 b7 00 00 00 4c 39 6b 08 75 43 48 b8 00 00 00 00 All code ======== 0: 8b 98 fe 48 89 d3 mov -0x2c76b702(%rax),%ebx 6: 48 85 d2 test %rdx,%rdx 9: 0f 84 af 8b 98 fe je 0xfffffffffe988bbe f: 4c 8d 62 08 lea 0x8(%rdx),%r12 13: 48 89 fd mov %rdi,%rbp 16: 49 89 f5 mov %rsi,%r13 19: 48 b8 00 00 00 00 00 movabs $0xdffffc0000000000,%rax 20: fc ff df 23: 4c 89 e2 mov %r12,%rdx 26: 48 c1 ea 03 shr $0x3,%rdx 2a:* 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) <-- trapping instruction 2e: 0f 85 b7 00 00 00 jne 0xeb 34: 4c 39 6b 08 cmp %r13,0x8(%rbx) 38: 75 43 jne 0x7d 3a: 48 rex.W 3b: b8 00 00 00 00 mov $0x0,%eax Code starting with the faulting instruction =========================================== 0: 80 3c 02 00 cmpb $0x0,(%rdx,%rax,1) 4: 0f 85 b7 00 00 00 jne 0xc1 a: 4c 39 6b 08 cmp %r13,0x8(%rbx) e: 75 43 jne 0x53 10: 48 rex.W 11: b8 00 00 00 00 mov $0x0,%eax [ 46.779267][ T179] Modules linked in: [ 46.787293][ T12] RSP: 0018:ffffc9000010fac8 EFLAGS: 00010003 [ 46.787300][ T12] RAX: dffffc0000000000 RBX: 0000000aa22a8dcf RCX: ffffffff82f5859d [ 46.793179][ T179] platform_profile [ 46.803018][ T12] RDX: 00000001544551ba RSI: ffff88884fde5c90 RDI: ffffc9000010fb50 [ 46.803023][ T12] RBP: ffffc9000010fb50 R08: 0000000000000000 R09: ffffed1109fbcb96 [ 46.803025][ T12] R10: ffff88884fde5cb7 R11: fefefefefefefeff R12: 0000000aa22a8dd7 [ 46.805219][ T179] sd_mod [ 46.811413][ T12] R13: ffff88884fde5c90 R14: ffff88884fde5c90 R15: 0000000aa22a8dcf [ 46.811417][ T12] FS: 0000000000000000(0000) GS:ffff888848e3e000(0000) knlGS:0000000000000000 [ 46.811419][ T12] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.830755][ T179] intel_rapl_common [ 46.834463][ T12] CR2: 00007f3bc83ae000 CR3: 0000000868388002 CR4: 00000000003726f0 [ 46.834467][ T12] Call Trace: [ 46.834469][ T12] <TASK> [ 46.840348][ T179] snd_hda_core [ 46.848115][ T12] dma_fence_default_wait (kbuild/src/consumer/include/linux/list.h:158 (discriminator 1) kbuild/src/consumer/include/linux/list.h:177 (discriminator 1) kbuild/src/consumer/drivers/dma-buf/dma-fence.c:800 (discriminator 1)) [ 46.851758][ T179] x86_pkg_temp_thermal [ 46.859527][ T12] ? __pfx_dma_fence_default_wait (kbuild/src/consumer/drivers/dma-buf/dma-fence.c:778) The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20251209/202512092317.8cf778a-lkp@i… -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

9 months, 1 week

[RFC] dma-buf: system_heap: add PTE_CONT for larger contiguous

by gao xu

commit 04c7adb5871a ("dma-buf: system_heap: use larger contiguous mappings instead of per-page mmap") facilitates the use of PTE_CONT. The system_heap allocates pages of order 4 and 8 that meet the alignment requirements for PTE_CONT. enabling PTE_CONT for larger contiguous mappings. After applying this patch, TLB misses are reduced by approximately 5% when opening the camera on Android systems. Signed-off-by: gao xu <gaoxu2(a)honor.com> --- drivers/dma-buf/heaps/system_heap.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 4c782fe33..103b06f89 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -202,12 +202,16 @@ static int system_heap_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma) unsigned long n = (sg->length >> PAGE_SHIFT) - pgoff; struct page *page = sg_page(sg) + pgoff; unsigned long size = n << PAGE_SHIFT; + pgprot_t prot = vma->vm_page_prot; if (addr + size > vma->vm_end) size = vma->vm_end - addr; + if (((addr | size) & ~CONT_PTE_MASK) == 0) + prot = __pgprot(pgprot_val(prot) | PTE_CONT); + ret = remap_pfn_range(vma, addr, page_to_pfn(page), - size, vma->vm_page_prot); + size, prot); if (ret) return ret; -- 2.42.0

9 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