public inbox for bpf@vger.kernel.org
 help / color / mirror / Atom feed
From: Puranjay Mohan <puranjay@kernel.org>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf v1 1/2] bpf: Fix grace period wait for tracepoint bpf_link
Date: Mon, 30 Mar 2026 10:52:12 +0100	[thread overview]
Message-ID: <m28qb91w6r.fsf@kernel.org> (raw)
In-Reply-To: <20260330032124.3141001-2-memxor@gmail.com>

Kumar Kartikeya Dwivedi <memxor@gmail.com> writes:

> Recently, tracepoints were switched from using disabled preemption
> (which acts as RCU read section) to SRCU-fast when they are not
> faultable. This means that to do a proper grace period wait for programs
> running in such tracepoints, we must use SRCU's grace period wait.
> This is only for non-faultable tracepoints, faultable ones continue
> using RCU Tasks Trace.
>
> However, bpf_link_free() currently does call_rcu() for all cases when
> the link is non-sleepable (hence, for tracepoints, non-faultable). Fix
> this by doing a call_srcu() grace period wait.
>
> As far RCU Tasks Trace gp -> RCU gp chaining is concerned, it is deemed
> unnecessary for tracepoint programs. The link and program are either
> accessed under RCU Tasks Trace protection, or SRCU-fast protection now.
>
> The earlier logic of chaining both RCU Tasks Trace and RCU gp waits was
> to generalize the logic, even if it conceded an extra RCU gp wait,
> however that is unnecessary for tracepoints even before this change.
> In practice no cost was paid since rcu_trace_implies_rcu_gp() was always
> true.
>
> Hence we need not chain any SRCU gp waits after RCU Tasks Trace.
>
> Fixes: a46023d5616e ("tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast")
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

With a nit below which is mostly informational.

Reviewed-by: Puranjay Mohan <puranjay@kernel.org>

> ---
>  include/linux/tracepoint.h |  8 ++++++++
>  kernel/bpf/syscall.c       | 22 ++++++++++++++++++++--
>  2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
> index 22ca1c8b54f3..8227102a771f 100644
> --- a/include/linux/tracepoint.h
> +++ b/include/linux/tracepoint.h
> @@ -113,6 +113,10 @@ void for_each_tracepoint_in_module(struct module *mod,
>   */
>  #ifdef CONFIG_TRACEPOINTS
>  extern struct srcu_struct tracepoint_srcu;
> +static inline struct srcu_struct *tracepoint_srcu_ptr(void)
> +{
> +	return &tracepoint_srcu;
> +}
>  static inline void tracepoint_synchronize_unregister(void)
>  {
>  	synchronize_rcu_tasks_trace();
> @@ -123,6 +127,10 @@ static inline bool tracepoint_is_faultable(struct tracepoint *tp)
>  	return tp->ext && tp->ext->faultable;
>  }
>  #else
> +static inline struct srcu_struct *tracepoint_srcu_ptr(void)
> +{
> +	return NULL;
> +}
>  static inline void tracepoint_synchronize_unregister(void)
>  { }
>  static inline bool tracepoint_is_faultable(struct tracepoint *tp)
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 274039e36465..ab61a5ce35af 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -3261,6 +3261,13 @@ static void bpf_link_defer_dealloc_rcu_gp(struct rcu_head *rcu)
>  	bpf_link_dealloc(link);
>  }
>  
> +static bool bpf_link_is_tracepoint(struct bpf_link *link)
> +{
> +	/* Only these combinations support a tracepoint bpf_link. */
> +	return link->type == BPF_LINK_TYPE_RAW_TRACEPOINT ||
> +	       (link->type == BPF_LINK_TYPE_TRACING && link->attach_type == BPF_TRACE_RAW_TP);

nit: this second check is never true here, because BPF_LINK_TYPE_TRACING
uses bpf_tracing_link_lops, which has .dealloc (not .dealloc_deferred)
and this function is only called from dealloc_deferred() path.

> +}
> +
>  static void bpf_link_defer_dealloc_mult_rcu_gp(struct rcu_head *rcu)
>  {
>  	if (rcu_trace_implies_rcu_gp())
> @@ -3279,16 +3286,27 @@ static void bpf_link_free(struct bpf_link *link)
>  	if (link->prog)
>  		ops->release(link);
>  	if (ops->dealloc_deferred) {
> -		/* Schedule BPF link deallocation, which will only then
> +		struct srcu_struct *tp_srcu = tracepoint_srcu_ptr();
> +
> +		/*
> +		 * Schedule BPF link deallocation, which will only then
>  		 * trigger putting BPF program refcount.
>  		 * If underlying BPF program is sleepable or BPF link's target
>  		 * attach hookpoint is sleepable or otherwise requires RCU GPs
>  		 * to ensure link and its underlying BPF program is not
>  		 * reachable anymore, we need to first wait for RCU tasks
> -		 * trace sync, and then go through "classic" RCU grace period
> +		 * trace sync, and then go through "classic" RCU grace period.
> +		 *
> +		 * For tracepoint BPF links, we need to go through SRCU grace
> +		 * period wait instead when non-faultable tracepoint is used. We
> +		 * don't need to chain SRCU grace period waits, however, for the
> +		 * faultable case, since it exclusively uses RCU Tasks Trace.
>  		 */
>  		if (link->sleepable || (link->prog && link->prog->sleepable))
>  			call_rcu_tasks_trace(&link->rcu, bpf_link_defer_dealloc_mult_rcu_gp);
> +		/* We need to do a SRCU grace period wait for tracepoint-based BPF links. */
> +		else if (bpf_link_is_tracepoint(link) && tp_srcu)
> +			call_srcu(tp_srcu, &link->rcu, bpf_link_defer_dealloc_rcu_gp);
>  		else
>  			call_rcu(&link->rcu, bpf_link_defer_dealloc_rcu_gp);
>  	} else if (ops->dealloc) {
> -- 
> 2.52.0

  parent reply	other threads:[~2026-03-30  9:52 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-30  3:21 [PATCH bpf v1 0/2] Fix bpf_link grace period wait for tracepoints Kumar Kartikeya Dwivedi
2026-03-30  3:21 ` [PATCH bpf v1 1/2] bpf: Fix grace period wait for tracepoint bpf_link Kumar Kartikeya Dwivedi
2026-03-30  3:36   ` Kumar Kartikeya Dwivedi
2026-03-30 10:00     ` Puranjay Mohan
2026-03-30 14:03       ` Kumar Kartikeya Dwivedi
2026-03-30  9:52   ` Puranjay Mohan [this message]
2026-03-30 14:02     ` Kumar Kartikeya Dwivedi
2026-03-30 15:07   ` Steven Rostedt
2026-03-30 15:27     ` Kumar Kartikeya Dwivedi
2026-03-30 16:10       ` Steven Rostedt
2026-03-30  3:21 ` [PATCH bpf v1 2/2] bpf: Retire rcu_trace_implies_rcu_gp() Kumar Kartikeya Dwivedi
2026-03-30 10:17   ` Puranjay Mohan
2026-03-30 10:40   ` Paul E. McKenney

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=m28qb91w6r.fsf@kernel.org \
    --to=puranjay@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=martin.lau@kernel.org \
    --cc=memxor@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.org \
    /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