Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

73 participants
6255 discussions

by Chong Criston

3 hours, 35 minutes

Re: [PATCH V13 5/7] rust: Make __udivdi3() and __umoddi3() panic

by Arnd Bergmann

On Fri, Apr 24, 2026, at 11:43, Link Mauve wrote: > On Fri, Apr 24, 2026 at 10:14:25AM +0100, David Laight wrote: >> On Fri, 24 Apr 2026 11:17:40 +0530 >> "Mukesh Kumar Chaurasiya (IBM)" <mkchauras(a)gmail.com> wrote: >> >> > From: Link Mauve <linkmauve(a)linkmauve.fr> >> > >> > The core crate currently depends on these two functions for i64/u64/ >> > i128/u128/core::time::Duration formatting, but we shouldn’t use that in >> > the kernel so let’s panic if they are ever called. >> >> Ugg. >> Surely you can make it a link-time failure? >> Or change the underlying code to avoid the divide. > > This is currently a link-time failure, which means if any of the core > crate or drm_panic_qr are linked in, the kernel will fail to link. > > And since we rely on core, that means no kernel can be built on PowerPC > without this patch. > > A possible solution would be to change the core crate to not divide > u64s, but the last time I tried to do that I couldn’t quite figure out > how to do formatting without it, maybe I will just open an issue against > Rust. How hard would it be to have a private copy of the parts of the core crate that the kernel actually needs? Since Linux is neither quite hosted (using a full libc) nor entirely freestanding (still using some library interfaces), the C implementation on most architectures has a small subset of the libgcc that we ship with the kernel. I assume the core crate is larger than libgcc, but I don't know how much of it is actually needed here. Arnd

4 hours, 59 minutes

Re: [PATCH V13 5/7] rust: Make __udivdi3() and __umoddi3() panic

by Miguel Ojeda

On Fri, Apr 24, 2026 at 11:43 AM Link Mauve <linkmauve(a)linkmauve.fr> wrote: > > A possible solution would be to change the core crate to not divide > u64s, but the last time I tried to do that I couldn’t quite figure out > how to do formatting without it, maybe I will just open an issue against > Rust. Yeah, I have some context at: https://github.com/Rust-for-Linux/linux/issues/2 -> feature(compiler_builtins) and a way to avoid certain intrinsics (f32, f64, i128, u128 and 64-bit divisions/modulos). We have discussed it at some points with upstream Rust (including related discussions about having more `cfg`s in `core` or a `cfg(linux_kernel)` etc.). I don't think we have an open issue concretely for it, apart from the Clippy one to flag the use the use of the 64-bit division, but if you open a more general one with some details, that would be great. Thanks! Cheers, Miguel

5 hours, 7 minutes

Re: [PATCH V13 5/7] rust: Make __udivdi3() and __umoddi3() panic

by Arnd Bergmann

On Fri, Apr 24, 2026, at 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: > > This doesn’t yet fix drm_panic_qr.rs, which also uses __udivdi3 when > CONFIG_CC_OPTIMIZE_FOR_SIZE=y, but at least makes the rest of the kernel > build on PPC32. It looks like the problem is commit 9af8f2b469c0 ("drm/panic: Add a u64 divide by 10 for arm32") describing this as an arm32 specific issue rather than something common for any 32-bit architecture. You can probably add a rust version of div_u64() and use that there. Arnd

6 hours, 34 minutes

Re: [PATCH V13 2/7] dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

by Christian König

On 4/24/26 10:34, Mukesh Kumar Chaurasiya wrote: > On Fri, Apr 24, 2026 at 10:25:25AM +0200, Christian König wrote: >> On 4/24/26 10:06, Mukesh Kumar Chaurasiya wrote: >>> [Sie erhalten nicht häufig E-Mails von mkchauras(a)gmail.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] >>> >>> On Fri, Apr 24, 2026 at 09:56:16AM +0200, Christian König wrote: >>>> On 4/24/26 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: >>>>> When building with LLVM=1 for architectures like powerpc where >>>>> CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: >>>>> >>>>> ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>>>> >>> referenced by helpers.c >>>>> >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) >>>>> >>>>> The issue occurs because: >>>>> 1. CONFIG_DEBUG_MUTEXES=y is enabled >>>>> 2. CONFIG_DMA_SHARED_BUFFER is not enabled >>>>> 3. dma_resv_reset_max_fences() is declared in the header when >>>>> CONFIG_DEBUG_MUTEXES is set >>>>> 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, >>>>> which is only built when CONFIG_DMA_SHARED_BUFFER is enabled >>>>> 5. Rust helpers call dma_resv_unlock() which calls >>>>> dma_resv_reset_max_fences(), causing an undefined symbol >>>>> >>>>> Fix this by making the function declaration conditional on both >>>>> CONFIG_DEBUG_MUTEXES and CONFIG_DMA_SHARED_BUFFER. When either is >>>>> disabled, use a static inline stub instead. >>>> >>>> Well we are clearly missing something here, but of hand that doesn't looks like the right fix. >>>> >>>> When CONFIG_DMA_SHARED_BUFFER isn't enabled then the whole dma-resv.h header can't be used at all. >>>> >>>> So you also can't call dma_resv_unlock() from the Rust helpers. Which means that we need to make the Rust helpers somehow depend on CONFIG_DMA_SHARED_BUFFER. >>>> >>>> Alternative would be to provide dummies for the functions in dma-resv.h when CONFIG_DMA_SHARED_BUFFER isn't set, but that looks a bit like it just hides the issue. >>>> >>>> Regards, >>>> Christian. >>>> >>> What about something like this: >>> >>> diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c >>> index 71914d8241e2..53c119f1b144 100644 >>> --- a/rust/helpers/dma-resv.c >>> +++ b/rust/helpers/dma-resv.c >>> @@ -2,6 +2,7 @@ >>> >>> #include <linux/dma-resv.h> >>> >>> +#ifdef CONFIG_DMA_SHARED_BUFFER >>> __rust_helper >>> int rust_helper_dma_resv_lock(struct dma_resv *obj, struct ww_acquire_ctx *ctx) >>> { >>> @@ -12,3 +13,4 @@ __rust_helper void rust_helper_dma_resv_unlock(struct dma_resv *obj) >>> { >>> dma_resv_unlock(obj); >>> } >>> +#endif >>> >>> This seems to fix the issue and makes sense, whoever wants to use the >>> dma shared buffer will anyway enable the config >> >> Yeah that directions makes sense. >> >> I would maybe go a step further and don't even compile rust/helpers/dma-resv.c when CONFIG_DMA_SHARED_BUFFER isn't set. >> > This makes sense. >> But if that is not possible for some reason then this solution is perfectly fine with me as well. >> >> The general goal is to make the error messages when you haven't set CONFIG_DMA_SHARED_BUFFER and still try to use the DMA-buf functions easy to understand and not something cryptic. >> >> Thanks, >> Christian. >> > > What about this one? > > diff --git a/rust/helpers/helpers.c b/rust/helpers/helpers.c > index 625921e27dfb..09ee5cac600d 100644 > --- a/rust/helpers/helpers.c > +++ b/rust/helpers/helpers.c > @@ -57,7 +57,9 @@ > #include "cred.c" > #include "device.c" > #include "dma.c" > +#ifdef CONFIG_DMA_SHARED_BUFFER > #include "dma-resv.c" > +#endif > #include "drm.c" > #include "err.c" > #include "irq.c" Looks good, feel free to add Reviewed-by: Christian König <christian.koenig(a)amd.com> But somebody more familiar with the Rust helpers should take another look on it. Regards, Christian. > > Regards, > Mukesh > >>> >>> Regards, >>> Mukesh >>>>> >>>>> Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") >>>>> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> >>>>> --- >>>>> include/linux/dma-resv.h | 2 +- >>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>> >>>>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h >>>>> index c5ab6fd9ebe8..23c8db0b5214 100644 >>>>> --- a/include/linux/dma-resv.h >>>>> +++ b/include/linux/dma-resv.h >>>>> @@ -311,7 +311,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) >>>>> #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) >>>>> #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) >>>>> >>>>> -#ifdef CONFIG_DEBUG_MUTEXES >>>>> +#if IS_ENABLED(CONFIG_DEBUG_MUTEXES) && IS_ENABLED(CONFIG_DMA_SHARED_BUFFER) >>>>> void dma_resv_reset_max_fences(struct dma_resv *obj); >>>>> #else >>>>> static inline void dma_resv_reset_max_fences(struct dma_resv *obj) {} >>>>> -- >>>>> 2.53.0 >>>>> >>>> >>

6 hours, 49 minutes

Re: [PATCH V13 2/7] dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

by Christian König

On 4/24/26 10:06, Mukesh Kumar Chaurasiya wrote: > [Sie erhalten nicht häufig E-Mails von mkchauras(a)gmail.com. Weitere Informationen, warum dies wichtig ist, finden Sie unter https://aka.ms/LearnAboutSenderIdentification ] > > On Fri, Apr 24, 2026 at 09:56:16AM +0200, Christian König wrote: >> On 4/24/26 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: >>> When building with LLVM=1 for architectures like powerpc where >>> CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: >>> >>> ld.lld: error: undefined symbol: dma_resv_reset_max_fences >>> >>> referenced by helpers.c >>> >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) >>> >>> The issue occurs because: >>> 1. CONFIG_DEBUG_MUTEXES=y is enabled >>> 2. CONFIG_DMA_SHARED_BUFFER is not enabled >>> 3. dma_resv_reset_max_fences() is declared in the header when >>> CONFIG_DEBUG_MUTEXES is set >>> 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, >>> which is only built when CONFIG_DMA_SHARED_BUFFER is enabled >>> 5. Rust helpers call dma_resv_unlock() which calls >>> dma_resv_reset_max_fences(), causing an undefined symbol >>> >>> Fix this by making the function declaration conditional on both >>> CONFIG_DEBUG_MUTEXES and CONFIG_DMA_SHARED_BUFFER. When either is >>> disabled, use a static inline stub instead. >> >> Well we are clearly missing something here, but of hand that doesn't looks like the right fix. >> >> When CONFIG_DMA_SHARED_BUFFER isn't enabled then the whole dma-resv.h header can't be used at all. >> >> So you also can't call dma_resv_unlock() from the Rust helpers. Which means that we need to make the Rust helpers somehow depend on CONFIG_DMA_SHARED_BUFFER. >> >> Alternative would be to provide dummies for the functions in dma-resv.h when CONFIG_DMA_SHARED_BUFFER isn't set, but that looks a bit like it just hides the issue. >> >> Regards, >> Christian. >> > What about something like this: > > diff --git a/rust/helpers/dma-resv.c b/rust/helpers/dma-resv.c > index 71914d8241e2..53c119f1b144 100644 > --- a/rust/helpers/dma-resv.c > +++ b/rust/helpers/dma-resv.c > @@ -2,6 +2,7 @@ > > #include <linux/dma-resv.h> > > +#ifdef CONFIG_DMA_SHARED_BUFFER > __rust_helper > int rust_helper_dma_resv_lock(struct dma_resv *obj, struct ww_acquire_ctx *ctx) > { > @@ -12,3 +13,4 @@ __rust_helper void rust_helper_dma_resv_unlock(struct dma_resv *obj) > { > dma_resv_unlock(obj); > } > +#endif > > This seems to fix the issue and makes sense, whoever wants to use the > dma shared buffer will anyway enable the config Yeah that directions makes sense. I would maybe go a step further and don't even compile rust/helpers/dma-resv.c when CONFIG_DMA_SHARED_BUFFER isn't set. But if that is not possible for some reason then this solution is perfectly fine with me as well. The general goal is to make the error messages when you haven't set CONFIG_DMA_SHARED_BUFFER and still try to use the DMA-buf functions easy to understand and not something cryptic. Thanks, Christian. > > Regards, > Mukesh >>> >>> Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") >>> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> >>> --- >>> include/linux/dma-resv.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h >>> index c5ab6fd9ebe8..23c8db0b5214 100644 >>> --- a/include/linux/dma-resv.h >>> +++ b/include/linux/dma-resv.h >>> @@ -311,7 +311,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) >>> #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) >>> #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) >>> >>> -#ifdef CONFIG_DEBUG_MUTEXES >>> +#if IS_ENABLED(CONFIG_DEBUG_MUTEXES) && IS_ENABLED(CONFIG_DMA_SHARED_BUFFER) >>> void dma_resv_reset_max_fences(struct dma_resv *obj); >>> #else >>> static inline void dma_resv_reset_max_fences(struct dma_resv *obj) {} >>> -- >>> 2.53.0 >>> >>

7 hours, 8 minutes

Re: [PATCH V13 2/7] dma-resv: Fix undefined symbol when CONFIG_DMA_SHARED_BUFFER is disabled

by Christian König

On 4/24/26 07:47, Mukesh Kumar Chaurasiya (IBM) wrote: > When building with LLVM=1 for architectures like powerpc where > CONFIG_DMA_SHARED_BUFFER is not enabled, the build fails with: > > ld.lld: error: undefined symbol: dma_resv_reset_max_fences > >>> referenced by helpers.c > >>> rust/helpers/helpers.o:(rust_helper_dma_resv_unlock) > > The issue occurs because: > 1. CONFIG_DEBUG_MUTEXES=y is enabled > 2. CONFIG_DMA_SHARED_BUFFER is not enabled > 3. dma_resv_reset_max_fences() is declared in the header when > CONFIG_DEBUG_MUTEXES is set > 4. But the function is only compiled in drivers/dma-buf/dma-resv.c, > which is only built when CONFIG_DMA_SHARED_BUFFER is enabled > 5. Rust helpers call dma_resv_unlock() which calls > dma_resv_reset_max_fences(), causing an undefined symbol > > Fix this by making the function declaration conditional on both > CONFIG_DEBUG_MUTEXES and CONFIG_DMA_SHARED_BUFFER. When either is > disabled, use a static inline stub instead. Well we are clearly missing something here, but of hand that doesn't looks like the right fix. When CONFIG_DMA_SHARED_BUFFER isn't enabled then the whole dma-resv.h header can't be used at all. So you also can't call dma_resv_unlock() from the Rust helpers. Which means that we need to make the Rust helpers somehow depend on CONFIG_DMA_SHARED_BUFFER. Alternative would be to provide dummies for the functions in dma-resv.h when CONFIG_DMA_SHARED_BUFFER isn't set, but that looks a bit like it just hides the issue. Regards, Christian. > > Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") > Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras(a)gmail.com> > --- > include/linux/dma-resv.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h > index c5ab6fd9ebe8..23c8db0b5214 100644 > --- a/include/linux/dma-resv.h > +++ b/include/linux/dma-resv.h > @@ -311,7 +311,7 @@ static inline bool dma_resv_iter_is_restarted(struct dma_resv_iter *cursor) > #define dma_resv_held(obj) lockdep_is_held(&(obj)->lock.base) > #define dma_resv_assert_held(obj) lockdep_assert_held(&(obj)->lock.base) > > -#ifdef CONFIG_DEBUG_MUTEXES > +#if IS_ENABLED(CONFIG_DEBUG_MUTEXES) && IS_ENABLED(CONFIG_DMA_SHARED_BUFFER) > void dma_resv_reset_max_fences(struct dma_resv *obj); > #else > static inline void dma_resv_reset_max_fences(struct dma_resv *obj) {} > -- > 2.53.0 >

7 hours, 37 minutes

[PATCH v12 0/5] Rust bindings for gem shmem

by Lyude Paul

Most of this patch series has already been pushed upstream, this is just the second half of the patch series that has not been pushed yet + some additional changes which were required to implement changes requested by the mailing list. This patch series is originally from Asahi, previously posted by Daniel Almeida. The previous version of the patch series can be found here: https://patchwork.freedesktop.org/series/164580/ Branch with patches applied available here sure this builds: https://gitlab.freedesktop.org/lyudess/linux/-/commits/rust/gem-shmem This patch series applies on top of drm-rust-next Lyude Paul (5): rust: drm: gem: s/device::Device/Device/ for shmem.rs drm/gem/shmem: Introduce __drm_gem_shmem_free_sgt_locked() drm/gem/shmem: Export drm_gem_shmem_get_pages_sgt_locked() rust: drm: gem: Introduce shmem::SGTable rust: drm: gem: Add vmap functions to shmem bindings drivers/gpu/drm/drm_gem_shmem_helper.c | 48 ++- include/drm/drm_gem_shmem_helper.h | 2 + rust/kernel/drm/gem/shmem.rs | 557 ++++++++++++++++++++++++- 3 files changed, 593 insertions(+), 14 deletions(-) base-commit: a7a080bb4236ebe577b6776d940d1717912ff6dd -- 2.53.0

23 hours, 20 minutes

[PATCH v2] dma-buf/udmabuf: skip redundant cpu sync to fix cacheline EEXIST warning

by Mikhail Gavrilov

When CONFIG_DMA_API_DEBUG_SG is enabled, importing a udmabuf into a DRM driver (e.g. amdgpu for video playback in GNOME Videos / Showtime) triggers a spurious warning: DMA-API: amdgpu 0000:03:00.0: cacheline tracking EEXIST, \ overlapping mappings aren't supported WARNING: kernel/dma/debug.c:619 at add_dma_entry+0x473/0x5f0 The call chain is: amdgpu_cs_ioctl -> amdgpu_ttm_backend_bind -> dma_buf_map_attachment -> [udmabuf] map_udmabuf -> get_sg_table -> dma_map_sgtable(dev, sg, direction, 0) // attrs=0 -> debug_dma_map_sg -> add_dma_entry -> EEXIST This happens because udmabuf builds a per-page scatter-gather list via sg_set_folio(). When begin_cpu_udmabuf() has already created an sg table mapped for the misc device, and an importer such as amdgpu maps the same pages for its own device via map_udmabuf(), the DMA debug infrastructure sees two active mappings whose physical addresses share cacheline boundaries and warns about the overlap. The DMA_ATTR_SKIP_CPU_SYNC flag suppresses this check in add_dma_entry() because it signals that no CPU cache maintenance is performed at map/unmap time, making the cacheline overlap harmless. All other major dma-buf exporters already pass this flag: - drm_gem_map_dma_buf() passes DMA_ATTR_SKIP_CPU_SYNC - amdgpu_dma_buf_map() passes DMA_ATTR_SKIP_CPU_SYNC The CPU sync at map/unmap time is also redundant for udmabuf: begin_cpu_udmabuf() and end_cpu_udmabuf() already perform explicit cache synchronization via dma_sync_sgtable_for_cpu/device() when CPU access is requested through the dma-buf interface. Pass DMA_ATTR_SKIP_CPU_SYNC to dma_map_sgtable() and dma_unmap_sgtable() in udmabuf to suppress the spurious warning and skip the redundant sync. Fixes: 284562e1f348 ("udmabuf: implement begin_cpu_access/end_cpu_access hooks") Cc: stable(a)vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov(a)gmail.com> --- v1 -> v2: - Rebased on drm-tip to resolve conflict with folio conversion patches. No code change, same two-line fix. v1: https://lore.kernel.org/all/20260317053653.28888-1-mikhail.v.gavrilov@gmail… drivers/dma-buf/udmabuf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 94b26ea706a3..bced421c0d65 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -145,7 +145,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, if (ret < 0) goto err_alloc; - ret = dma_map_sgtable(dev, sg, direction, 0); + ret = dma_map_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); if (ret < 0) goto err_map; return sg; @@ -160,7 +160,7 @@ static struct sg_table *get_sg_table(struct device *dev, struct dma_buf *buf, static void put_sg_table(struct device *dev, struct sg_table *sg, enum dma_data_direction direction) { - dma_unmap_sgtable(dev, sg, direction, 0); + dma_unmap_sgtable(dev, sg, direction, DMA_ATTR_SKIP_CPU_SYNC); sg_free_table(sg); kfree(sg); } -- 2.53.0

1 day, 2 hours

(no subject)

by leoevelyn768＠gmail.com

Recovering Your Lost Bitcoin: Trust Almighty Recovery Hacker In the ever-evolving world of cryptocurrency, the allure of investment opportunities has attracted many, but unfortunately, it has also led to a rise in fraudulent schemes. If you've fallen victim to a deceptive investment firm and lost your hard-earned Bitcoin, you're not alone. Fortunately, there is help available. Almighty Recovery Hacker is a specialized recovery firm dedicated to helping individuals like you trace and recover lost or stolen Bitcoin. Email... almightyrecoverycoin{(a)}mail.com Whatsapp... {+53 5 1 556969}

1 day, 3 hours

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig