Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
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

           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