On 4/24/26 10:06, Mukesh Kumar Chaurasiya wrote:
> [Sie erhalten nicht häufig E-Mails von [email protected]. 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) <[email protected]>
>>> ---
>>> 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
>>>
>>
