From: Yunseong Kim <ysk@kzalloc.com>
To: linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
"kernel_team @ skhynix . com" <kernel_team@skhynix.com>
Cc: "Nathan Chancellor" <nathan@kernel.org>,
"Christian König" <christian.koenig@amd.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Mikhail Gavrilov" <mikhail.v.gavrilov@gmail.com>,
"Dave Airlie" <airlied@redhat.com>,
"Marco Elver" <elver@google.com>,
"Nick Desaulniers" <ndesaulniers@google.com>,
"Yeoreum Yun" <yeoreum.yun@arm.com>,
"Yeoreum Yun" <ppbuk5246@gmail.com>,
"Byungchul Park" <byungchul@sk.com>,
"Byungchul Park" <max.byungchul.park@gmail.com>
Subject: Re: [PATCH v19 28/40] dept: assign unique dept_key to each distinct dma fence caller
Date: Tue, 25 Aug 2026 14:33:14 +0200 [thread overview]
Message-ID: <61f8b60e-3477-465c-b6e9-c5a76de210f3@kzalloc.com> (raw)
In-Reply-To: <20260706061928.66713-29-byungchul@sk.com>
Hi Nathan,
After reading your thoughtful comments, I tested the Clang build issue
related to "indirect goto" on a v7.2 kernel with DEPT enabled:
$ clang -v
Debian clang version 21.1.8 (10)
$ vng --arch arm64 --build LLVM=1 --configitem CONFIG_DEPT=y \
--configitem CONFIG_DRM_XE=m --configitem CONFIG_ARCH_QCOM=y \
--configitem CONFIG_DRM_MSM=m
Tested branch is here: https://github.com/yskzalloc/linux-dept/tree/dept19_v7.2
Since the update to the dma_fence_wait() usage in the 7.2 rc, Clang has no
longer reported the "indirect goto" issue.
Link: https://github.com/llvm/llvm-project/issues/138272#issuecomment-5404767476
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e28aa8f7ee26d67a4addee6e3980f1cbf861b49
Tested-by: Yunseong Kim <yunseong.kim@est.tech>
On 06/07/2026 8:19 am, Byungchul Park wrote:
> dma fence can be used at various points in the code and it's very hard
> to distinguish dma fences between different usages. Using a single
> dept_key for all the dma fences could trigger false positive reports.
>
> Assign unique dept_key to each distinct dma fence wait to avoid false
> positive reports.
>
> Signed-off-by: Byungchul Park <byungchul@sk.com>
> ---
> drivers/dma-buf/dma-fence.c | 18 ++++-----
> include/linux/dma-fence.h | 74 +++++++++++++++++++++++++++++--------
> 2 files changed, 68 insertions(+), 24 deletions(-)
>
[snip...]
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index d4c92fd35092..3732849a30b7 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -370,8 +370,22 @@ bool dma_fence_check_and_signal_locked(struct dma_fence *fence);
> void dma_fence_signal_locked(struct dma_fence *fence);
> void dma_fence_signal_timestamp(struct dma_fence *fence, ktime_t timestamp);
> void dma_fence_signal_timestamp_locked(struct dma_fence *fence, ktime_t timestamp);
> -signed long dma_fence_default_wait(struct dma_fence *fence,
> +signed long __dma_fence_default_wait(struct dma_fence *fence,
> bool intr, signed long timeout);
> +
> +/*
> + * Associate every caller with its own dept map.
> + */
> +#define dma_fence_default_wait(f, intr, t) \
> +({ \
> + signed long __ret; \
> + \
> + sdt_might_sleep_start_timeout(NULL, t); \
> + __ret = __dma_fence_default_wait(f, intr, t); \
> + sdt_might_sleep_end(); \
> + __ret; \
> +})
> +
> int dma_fence_add_callback(struct dma_fence *fence,
> struct dma_fence_cb *cb,
> dma_fence_func_t func);
> @@ -628,12 +642,37 @@ static inline ktime_t dma_fence_timestamp(struct dma_fence *fence)
> return fence->timestamp;
> }
>
> -signed long dma_fence_wait_timeout(struct dma_fence *,
> +signed long __dma_fence_wait_timeout(struct dma_fence *,
> bool intr, signed long timeout);
> -signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
> +signed long __dma_fence_wait_any_timeout(struct dma_fence **fences,
> uint32_t count,
> bool intr, signed long timeout,
> uint32_t *idx);
> +/*
> + * Associate every caller with its own dept map.
> + */
> +#define dma_fence_wait_timeout(f, intr, t) \
> +({ \
> + signed long __ret; \
> + \
> + sdt_might_sleep_start_timeout(NULL, t); \
> + __ret = __dma_fence_wait_timeout(f, intr, t); \
> + sdt_might_sleep_end(); \
> + __ret; \
> +})
> +
> +/*
> + * Associate every caller with its own dept map.
> + */
> +#define dma_fence_wait_any_timeout(fpp, count, intr, t, idx) \
> +({ \
> + signed long __ret; \
> + \
> + sdt_might_sleep_start_timeout(NULL, t); \
> + __ret = __dma_fence_wait_any_timeout(fpp, count, intr, t, idx); \
> + sdt_might_sleep_end(); \
> + __ret; \
> +})
>
> /**
> * dma_fence_wait - sleep until the fence gets signaled
> @@ -649,19 +688,24 @@ signed long dma_fence_wait_any_timeout(struct dma_fence **fences,
> * fence might be freed before return, resulting in undefined behavior.
> *
> * See also dma_fence_wait_timeout() and dma_fence_wait_any_timeout().
> + *
> + * Associate every caller with its own dept map.
> */
> -static inline signed long dma_fence_wait(struct dma_fence *fence, bool intr)
> -{
> - signed long ret;
> -
> - /* Since dma_fence_wait_timeout cannot timeout with
> - * MAX_SCHEDULE_TIMEOUT, only valid return values are
> - * -ERESTARTSYS and MAX_SCHEDULE_TIMEOUT.
> - */
> - ret = dma_fence_wait_timeout(fence, intr, MAX_SCHEDULE_TIMEOUT);
> -
> - return ret < 0 ? ret : 0;
> -}
> +#define dma_fence_wait(f, intr) \
> +({ \
> + signed long __ret; \
> + \
> + sdt_might_sleep_start_timeout(NULL, MAX_SCHEDULE_TIMEOUT); \
> + __ret = __dma_fence_wait_timeout(f, intr, MAX_SCHEDULE_TIMEOUT);\
> + sdt_might_sleep_end(); \
> + \
> + /* \
> + * Since dma_fence_wait_timeout cannot timeout with \
> + * MAX_SCHEDULE_TIMEOUT, only valid return values are \
> + * -ERESTARTSYS and MAX_SCHEDULE_TIMEOUT. \
> + */ \
> + __ret < 0 ? __ret : 0; \
> +})
Thank you all! :)
Best regards,
Yunseong
parent reply other threads:[~2026-08-25 12:33 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20260706061928.66713-29-byungchul@sk.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61f8b60e-3477-465c-b6e9-c5a76de210f3@kzalloc.com \
--to=ysk@kzalloc.com \
--cc=airlied@redhat.com \
--cc=byungchul@sk.com \
--cc=christian.koenig@amd.com \
--cc=elver@google.com \
--cc=kernel_team@skhynix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=max.byungchul.park@gmail.com \
--cc=mikhail.v.gavrilov@gmail.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=ppbuk5246@gmail.com \
--cc=yeoreum.yun@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox