Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

25 participants
6311 discussions

Re: [PATCH] dma-fence: Move signalling tracepoint to before ops detach

by Christian König

On 3/30/26 15:36, Tvrtko Ursulin wrote: > Move the signalling tracepoint to before fence->ops are reset otherwise > tracepoint will dereference a null pointer. > > Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)igalia.com> > Fixes: 541c8f2468b9 ("dma-buf: detach fence ops on signal v3") > Cc: Christian König <christian.koenig(a)amd.com> > Cc: Philipp Stanner <phasta(a)kernel.org> > Cc: Boris Brezillon <boris.brezillon(a)collabora.com> > Cc: linux-media(a)vger.kernel.org > Cc: linaro-mm-sig(a)lists.linaro.org Good catch. I just silently assumed that the fence is not signaled when we traced signaling. Going to take another look since there might be more problems, but for now: Reviewed-by: Christian König <christian.koenig(a)amd.com> > --- > drivers/dma-buf/dma-fence.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index 1826ba73094c..1c1eaecaf1b0 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -363,6 +363,8 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > &fence->flags))) > return; > > + trace_dma_fence_signaled(fence); > + > /* > * When neither a release nor a wait operation is specified set the ops > * pointer to NULL to allow the fence structure to become independent > @@ -377,7 +379,6 @@ void dma_fence_signal_timestamp_locked(struct dma_fence *fence, > > fence->timestamp = timestamp; > set_bit(DMA_FENCE_FLAG_TIMESTAMP_BIT, &fence->flags); > - trace_dma_fence_signaled(fence); > > list_for_each_entry_safe(cur, tmp, &cb_list, node) { > INIT_LIST_HEAD(&cur->node);

2 weeks

[PATCH v2] dma/contiguous: Fix broken build

by Maxime Ripard

Commit 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") didn't remove one last call to dma_heap_cma_register_heap() that it removed, thus breaking the build. That last call is in dma_contiguous_reserve(), to handle the registration of the default CMA region heap instance. The default CMA region instance is already somewhat handled by retrieving it through the dev_get_cma_area() call in the CMA heap driver. However, since commit 854acbe75ff4 ("dma-buf: heaps: Give default CMA heap a fixed name"), we will create two heap instances for the CMA default region. The first one is always called "default_cma_region", and is the one handled by the call to dev_get_cma_area() mentioned earlier. The second one is the name it used to have prior to that last commit for backward compatibility. In the case where the default CMA region is defined in the DT, then that region is registered through rmem_cma_setup() and that region is added to the list of CMA regions to create a CMA heap instance for. In the case where the default CMA region is not defined in the DT though used to be the case covered by the now removed dma_heap_cma_register_heap() in dma_contiguous_reserve(). If we only remove the call to dma_heap_cma_register_heap(), then the legacy name of the CMA heap will not be registered anymore. We thus need to replace that call with a call to rmem_cma_insert_area() to make sure we queue this instance, if created, to create a heap instance. Once that call to dma_heap_cma_register_heap() replaced, we can also remove the now unused function definition, its now empty header, and all includes of this header. Fixes: 3a236f6a5cf2 ("dma: contiguous: Turn heap registration logic around") Reported-by: Mark Brown <broonie(a)kernel.org> Closes: https://lore.kernel.org/linux-next/acbjaDJ1a-YQC64d@sirena.co.uk/ Signed-off-by: Maxime Ripard <mripard(a)kernel.org> --- Changes in v2: - Fix creation of the CMA heap instance with the legacy name when not declared in the DT. - Link to v1: https://lore.kernel.org/r/20260330-dma-build-fix-v1-1-748b64f0d8af@kernel.o… --- drivers/dma-buf/heaps/cma_heap.c | 1 - include/linux/dma-buf/heaps/cma.h | 16 ---------------- kernel/dma/contiguous.c | 14 +++++++++++--- 3 files changed, 11 insertions(+), 20 deletions(-) diff --git a/drivers/dma-buf/heaps/cma_heap.c b/drivers/dma-buf/heaps/cma_heap.c index 7216a14262b04bb6130ddf26b7d009f7d15b03fd..9a8b36bc929f6daa483a0139a2919d95127e0d23 100644 --- a/drivers/dma-buf/heaps/cma_heap.c +++ b/drivers/dma-buf/heaps/cma_heap.c @@ -12,11 +12,10 @@ #define pr_fmt(fmt) "cma_heap: " fmt #include <linux/cma.h> #include <linux/dma-buf.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-heap.h> #include <linux/dma-map-ops.h> #include <linux/err.h> #include <linux/highmem.h> #include <linux/io.h> diff --git a/include/linux/dma-buf/heaps/cma.h b/include/linux/dma-buf/heaps/cma.h deleted file mode 100644 index e751479e21e703e24a5f799b4a7fc8bd0df3c1c4..0000000000000000000000000000000000000000 --- a/include/linux/dma-buf/heaps/cma.h +++ /dev/null @@ -1,16 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef DMA_BUF_HEAP_CMA_H_ -#define DMA_BUF_HEAP_CMA_H_ - -struct cma; - -#ifdef CONFIG_DMABUF_HEAPS_CMA -int dma_heap_cma_register_heap(struct cma *cma); -#else -static inline int dma_heap_cma_register_heap(struct cma *cma) -{ - return 0; -} -#endif // CONFIG_DMABUF_HEAPS_CMA - -#endif // DMA_BUF_HEAP_CMA_H_ diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c index ad50512d71d3088a73e4b1ac02d6e6122374888e..d5d15983060c5c54744d6a63f2b591e1a3455b86 100644 --- a/kernel/dma/contiguous.c +++ b/kernel/dma/contiguous.c @@ -40,11 +40,10 @@ #include <asm/page.h> #include <linux/memblock.h> #include <linux/err.h> #include <linux/sizes.h> -#include <linux/dma-buf/heaps/cma.h> #include <linux/dma-map-ops.h> #include <linux/cma.h> #include <linux/nospec.h> #ifdef CONFIG_CMA_SIZE_MBYTES @@ -217,10 +216,19 @@ static void __init dma_numa_cma_reserve(void) static inline void __init dma_numa_cma_reserve(void) { } #endif +#ifdef CONFIG_OF_RESERVED_MEM +static int rmem_cma_insert_area(struct cma *cma); +#else +static inline int rmem_cma_insert_area(struct cma *cma) +{ + return 0; +} +#endif + /** * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling * @limit: End address of the reserved memory (optional, 0 for any). * * This function reserves memory from early allocator. It should be @@ -271,13 +279,13 @@ void __init dma_contiguous_reserve(phys_addr_t limit) &dma_contiguous_default_area, fixed); if (ret) return; - ret = dma_heap_cma_register_heap(dma_contiguous_default_area); + ret = rmem_cma_insert_area(dma_contiguous_default_area); if (ret) - pr_warn("Couldn't register default CMA heap."); + pr_warn("Couldn't queue default CMA region for heap creation."); } } void __weak dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) --- base-commit: 6c683d5b1903a14e362c9f1628ce9fe61eac35e7 change-id: 20260330-dma-build-fix-706a4feb0e0f Best regards, -- Maxime Ripard <mripard(a)kernel.org>

2 weeks

Re: [PATCH RESEND] dma-fence: Dereference correct dma_fence in dma_fence_chain_find_seqno()

by Christian König

On 3/28/26 11:26, Li Ming wrote: > > 在 2026/3/28 02:47, Li Ming 写道: >> dma_fence_chain_find_seqno() uses dma_fence_chain_for_each() to walk a >> given dma_fence_chain. dma_fence_chain_for_each() always holds a >> reference for the current fence during iteration. The reference must >> be dropped after breaking out. Instead of dereferencing the last fence >> as intended, dma_fence_chain_find_seqno() incorrectly dereferences the >> first fence in the chain. >> >> Fixes: 7bf60c52e093 ("dma-buf: add new dma_fence_chain container v7") >> Signed-off-by: Li Ming <ming.li(a)zohomail.com> >> --- >> drivers/dma-buf/dma-fence-chain.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c >> index a8a90acf4f34..71fa173aef13 100644 >> --- a/drivers/dma-buf/dma-fence-chain.c >> +++ b/drivers/dma-buf/dma-fence-chain.c >> @@ -103,7 +103,7 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno) >> to_dma_fence_chain(*pfence)->prev_seqno < seqno) >> break; >> } >> - dma_fence_put(&chain->base); >> + dma_fence_put(*pfence); >> return 0; >> } >> >> --- >> base-commit: c369299895a591d96745d6492d4888259b004a9e >> change-id: 20260327-fix_dma_fence_chain_find_seqno-7adea64efe01 >> >> Best regards, > > After looking deeper into this issue, it is not a bug. > > Seems like this function requires that caller needs to hold the reference of the give fence before calling it. When pfence changed, need to transfer the reference from the original fence to the new fence. That is why it releases the reference for the original fence in the end. Yeah exactly that. We have documented the behavior in the kerneldoc: * Advance the fence pointer to the chain node which will signal this sequence * number. But that is somehow not enough. If you have suggestions how to improve the comments then please speak up. This patch has been suggested as "fix" numerous times. Regards, Christian. > > Sorry to make this noise. > > > Ming >

2 weeks, 1 day

[PATCH] dma/contiguous: Fix broken build

by Maxime Ripard

2 weeks, 1 day

Expertise in Recovery

by penelopestaunton931＠gmail.com

Safeguard is not just another name in the crowded field of cryptocurrency recovery; they are renowned for their effectiveness and expertise in tracing lost funds. Their team comprises skilled professionals who understand the intricate workings of blockchain technology and the tactics employed by online scammers. This specialized knowledge enables them to devise tailored strategies to recover your assets. Email: safeguardbitcoin(a)consultant.com WhatsApp: +44 7426 168300 Website: https://safeguardbitcoin.wixsite.com/safeguard-bitcoin--1

2 weeks, 1 day

Why Choose Betafort Recovery

by brandonbarry676＠gmail.com

With professionalism and integrity, Betafort Recovery assures that their clients get the finest possible help in retrieving their lost digital assets. With a staff of professionals dedicated to assisting individuals in navigating the recovery process, they provide 24 hour support to guarantee that customers receive timely and effective assistance when they need it the most. Testimonials from delighted clients demonstrate Betafort Recovery abilities in recovering lost digital assets, emphasizing their dedication to client satisfaction and good outcomes. NO UPFRONT FEES REQUIRED. Online presence: Betafort Recovery

2 weeks, 1 day

Re: [RFC v2 PATCH 09/10] vfio/pci: Add mmap() attributes to DMABUF feature

by Jason Gunthorpe

On Thu, Mar 12, 2026 at 11:46:07AM -0700, Matt Evans wrote: > A new field is reserved in vfio_device_feature_dma_buf.flags to > request CPU-facing memory type attributes for mmap()s of the buffer. > Add a flag VFIO_DEVICE_FEATURE_DMA_BUF_ATTR_WC, which results in WC > PTEs for the DMABUF's BAR region. This seems very straightforward, I like it Did I get it right that the idea is the user would request a dmabuf with these flags and then mmap the dmabuf? Jason

2 weeks, 1 day

Re: [RFC v2 PATCH 02/10] vfio/pci: Clean up DMABUFs before disabling function

by Jason Gunthorpe

On Thu, Mar 12, 2026 at 11:46:00AM -0700, Matt Evans wrote: > On device shutdown, make vfio_pci_core_close_device() call > vfio_pci_dma_buf_cleanup() before the function is disabled via > vfio_pci_core_disable(). This ensures that all access via DMABUFs is > revoked before the function's BARs become inaccessible. > > This fixes an issue where, if the function is disabled first, a tiny > window exists in which the function's MSE is cleared and yet BARs > could still be accessed via the DMABUF. The resources would also be > freed and up for grabs by a different driver. > > Fixes: 5d74781ebc86c ("vfio/pci: Add dma-buf export support for MMIO regions") > Signed-off-by: Matt Evans <mattev(a)meta.com> > --- > drivers/vfio/pci/vfio_pci_core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) This seems like it should not be RFC and it should go to stable? The normal mmaps are cleaned because they hold the file open while they exist, dmabuf upends that and it does need zapping early. Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Jason

2 weeks, 1 day

Re: [PATCH] dma-fence: Dereference correct dma_fence in dma_fence_chain_find_seqno()

by Christian König

On 3/27/26 15:33, Li Ming wrote: > dma_fence_chain_find_seqno() uses dma_fence_chain_for_each() to walk a > given dma_fence_chain. dma_fence_chain_for_each() always holds a > reference for the current fence during iteration. The reference must > be dropped after breaking out. Instead of dereferencing the last fence > as intended, dma_fence_chain_find_seqno() incorrectly dereferences the > first fence in the chain. Well once more: Absolutely clear NAK and please search the mailing list for similar changes before you send a patch out. The existing code is perfectly correct and I can't count how often I had to reject that patch. I think the functionality is obvious but it looks like we really need to add a comment here. Regards, Christian. > > Fixes: 7bf60c52e093 ("dma-buf: add new dma_fence_chain container v7") > Signed-off-by: Li Ming <ming.li(a)zohomail.com> > --- > drivers/dma-buf/dma-fence-chain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/dma-buf/dma-fence-chain.c b/drivers/dma-buf/dma-fence-chain.c > index a8a90acf4f34..71fa173aef13 100644 > --- a/drivers/dma-buf/dma-fence-chain.c > +++ b/drivers/dma-buf/dma-fence-chain.c > @@ -103,7 +103,7 @@ int dma_fence_chain_find_seqno(struct dma_fence **pfence, uint64_t seqno) > to_dma_fence_chain(*pfence)->prev_seqno < seqno) > break; > } > - dma_fence_put(&chain->base); > + dma_fence_put(*pfence); > > return 0; > } > > --- > base-commit: c369299895a591d96745d6492d4888259b004a9e > change-id: 20260327-fix_dma_fence_chain_find_seqno-7adea64efe01 > > Best regards, > -- > Li Ming <ming.li(a)zohomail.com> >

2 weeks, 1 day

(no subject)

by Johnson Henry

The Best Crypto recovery Expert Consult Ghost Mystery Recovery Hacker The best cryptocurrency recovery service,is well-known for its meticulous method of retrieving lost or stolen cryptocurrencies. ghost mystery recovery hacker recovery uses forensic investigations and state-of-the-art blockchain analytics techniques to locate and help victims recover their stolen digital assets. Its team includes professionals, who concentrate on regulatory Email address: support(a)ghostmysteryrecovery.com WhatsApp on +44 7480 061765 Website;https://ghostmysteryrecovery.com

2 weeks, 2 days

← Newer
1
...
5
6
7
8
9
10
11
...
632
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig