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:
- CONFIG_DEBUG_MUTEXES=y is enabled
- CONFIG_DMA_SHARED_BUFFER is not enabled
- dma_resv_reset_max_fences() is declared in the header when CONFIG_DEBUG_MUTEXES is set
- But the function is only compiled in drivers/dma-buf/dma-resv.c, which is only built when CONFIG_DMA_SHARED_BUFFER is enabled
- 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
Regards, Mukesh
Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit v2") Signed-off-by: Mukesh Kumar Chaurasiya (IBM) mkchauras@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