linux-trace-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Menglong Dong <dongml2@chinatelecom.cn>,
	mhiramat@kernel.org, mathieu.desnoyers@efficios.com,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	oliver.sang@intel.com
Subject: Re: [PATCH] tracing: fprobe: fix suspicious rcu usage in fprobe_entry
Date: Tue, 2 Sep 2025 10:57:57 -0400	[thread overview]
Message-ID: <20250902105757.16a78aea@batman.local.home> (raw)
In-Reply-To: <aLa2D4It1Zxc7bs0@gondor.apana.org.au>

On Tue, 2 Sep 2025 17:17:03 +0800
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> Menglong Dong <dongml2@chinatelecom.cn> wrote:
> >
> > diff --git a/kernel/trace/fprobe.c b/kernel/trace/fprobe.c
> > index fb127fa95f21..fece0f849c1c 100644
> > --- a/kernel/trace/fprobe.c
> > +++ b/kernel/trace/fprobe.c
> > @@ -269,7 +269,9 @@ static int fprobe_entry(struct ftrace_graph_ent *trace, struct fgraph_ops *gops,
> >        if (WARN_ON_ONCE(!fregs))
> >                return 0;
> > 
> > +       rcu_read_lock();
> >        head = rhltable_lookup(&fprobe_ip_table, &func, fprobe_rht_params);
> > +       rcu_read_unlock();
> >        reserved_words = 0;
> >        rhl_for_each_entry_rcu(node, pos, head, hlist) {
> >                if (node->addr != func)  
> 
> Actually this isn't quite right.  I know that it is a false-positive
> so that it's actually safe, but if you're going to mark it with
> rcu_read_lock, it should cover both the lookup as well as the
> dereference which happens in the loop rhl_for_each_entry_rcu.
> 

I disagree. It's a false positive as RCU is actually enabled here
because preemption is disabled. Now we are spreading the internals of
rhltable into the fprobe code.

We should just wrap it as is with a comment saying that currently RCU
checking doesn't have a good way to know preemption is disabled in all
config settings.

That is, I don't want rcu disabled here where people will think it's
actually needed when it isn't. Wrapping the call with rcu_read_lock()
with a comment that says it's to quiet a false positive is enough, as
then we are not misrepresenting the code.

Maybe instead have:

/*
 * fprobes calls rhltable_lookup() from a preempt_disabled location.
 * This is equivalent to rcu_read_lock(). But rcu_deferefernce_check()
 * will trigger a false positive when PREEMPT_COUNT is not defined.
 * Quiet the check.
 */
#ifndef CONFIG_PREEMPT_COUNT
# define quiet_rcu_lock_check() rcu_read_lock()
# define quiet_rcu_unlock_check() rcu_read_unlock()
#else
# define quiet_rcu_lock_check()
# define_quiet_rcu_unlock_check()
#endif

And then have:

       quiet_rcu_read_lock_check();
       head = rhltable_lookup(&fprobe_ip_table, &func, fprobe_rht_params);
       quiet_rcu_read_unlock_check();

-- Steve

  parent reply	other threads:[~2025-09-02 14:58 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29  2:14 [PATCH] tracing: fprobe: fix suspicious rcu usage in fprobe_entry Menglong Dong
2025-08-29  2:23 ` Steven Rostedt
2025-08-29  2:49   ` menglong.dong
2025-08-29 11:12     ` Paul E. McKenney
2025-08-29 11:11   ` Paul E. McKenney
2025-09-01  8:06     ` Masami Hiramatsu
2025-09-01 15:00       ` Paul E. McKenney
2025-09-02  6:59         ` Masami Hiramatsu
2025-09-02 11:58           ` Paul E. McKenney
2025-09-03  9:43         ` Herbert Xu
2025-09-04  9:44         ` [PATCH] rhashtable: Use rcu_dereference_all and rcu_dereference_all_check Herbert Xu
2025-09-01 10:06     ` [PATCH] tracing: fprobe: fix suspicious rcu usage in fprobe_entry Herbert Xu
2025-09-01  8:22 ` Masami Hiramatsu
2025-09-02  9:17 ` Herbert Xu
2025-09-02  9:50   ` menglong.dong
2025-09-03  4:22     ` Herbert Xu
2025-09-04  3:37       ` Menglong Dong
2025-09-04  4:29         ` Masami Hiramatsu
2025-09-04  5:42           ` Menglong Dong
2025-09-04  9:08         ` Herbert Xu
2025-09-02 14:57   ` Steven Rostedt [this message]
2025-09-03  4:23     ` Herbert Xu
2025-09-04  5:41     ` menglong.dong

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=20250902105757.16a78aea@batman.local.home \
    --to=rostedt@goodmis.org \
    --cc=dongml2@chinatelecom.cn \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=oliver.sang@intel.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;
as well as URLs for NNTP newsgroup(s).