All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@kernel.org>
To: Frederic Weisbecker <frederic@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	lkml <linux-kernel@vger.kernel.org>,
	Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@chromium.org>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr
Date: Mon, 16 May 2022 06:39:36 -0700	[thread overview]
Message-ID: <20220516133936.GW1790663@paulmck-ThinkPad-P17-Gen-1> (raw)
In-Reply-To: <20220516114922.GA349949@lothringen>

On Mon, May 16, 2022 at 01:49:22PM +0200, Frederic Weisbecker wrote:
> On Sun, May 15, 2022 at 09:25:35PM -0700, Paul E. McKenney wrote:
> > On Sun, May 15, 2022 at 10:36:52PM +0200, Jiri Olsa wrote:
> > > Making arch_cpu_idle and rcu_idle_exit noinstr. Both functions run
> > > in rcu 'not watching' context and if there's tracer attached to
> > > them, which uses rcu (e.g. kprobe multi interface) it will hit RCU
> > > warning like:
> > > 
> > >   [    3.017540] WARNING: suspicious RCU usage
> > >   ...
> > >   [    3.018363]  kprobe_multi_link_handler+0x68/0x1c0
> > >   [    3.018364]  ? kprobe_multi_link_handler+0x3e/0x1c0
> > >   [    3.018366]  ? arch_cpu_idle_dead+0x10/0x10
> > >   [    3.018367]  ? arch_cpu_idle_dead+0x10/0x10
> > >   [    3.018371]  fprobe_handler.part.0+0xab/0x150
> > >   [    3.018374]  0xffffffffa00080c8
> > >   [    3.018393]  ? arch_cpu_idle+0x5/0x10
> > >   [    3.018398]  arch_cpu_idle+0x5/0x10
> > >   [    3.018399]  default_idle_call+0x59/0x90
> > >   [    3.018401]  do_idle+0x1c3/0x1d0
> > > 
> > > The call path is following:
> > > 
> > > default_idle_call
> > >   rcu_idle_enter
> > >   arch_cpu_idle
> > >   rcu_idle_exit
> > > 
> > > The arch_cpu_idle and rcu_idle_exit are the only ones from above
> > > path that are traceble and cause this problem on my setup.
> > > 
> > > Signed-off-by: Jiri Olsa <jolsa@kernel.org>
> > 
> > From an RCU viewpoint:
> > 
> > Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> > 
> > [ I considered asking for an instrumentation_on() in rcu_idle_exit(),
> > but there is no point given that local_irq_restore() isn't something
> > you instrument anyway. ]
> 
> So local_irq_save() in the beginning of rcu_idle_exit() is unsafe because
> it is instrumentable by the function (graph)  tracers and the irqsoff tracer.
> 
> Also it calls into lockdep that might make use of RCU.
> 
> That's why rcu_idle_exit() is not noinstr yet. See this patch:
> 
> https://lore.kernel.org/lkml/20220503100051.2799723-4-frederic@kernel.org/

Ah, I should have looked at the context-tracking series again!

And I have to ask...  How much debugging capability are we really losing
by continuing to use the raw versions of local_irq_{save,restore}()?

							Thanx, Paul

> Thanks.
> 
> > 
> > > ---
> > >  arch/x86/kernel/process.c | 2 +-
> > >  kernel/rcu/tree.c         | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> > > index b370767f5b19..1345cb0124a6 100644
> > > --- a/arch/x86/kernel/process.c
> > > +++ b/arch/x86/kernel/process.c
> > > @@ -720,7 +720,7 @@ void arch_cpu_idle_dead(void)
> > >  /*
> > >   * Called from the generic idle code.
> > >   */
> > > -void arch_cpu_idle(void)
> > > +void noinstr arch_cpu_idle(void)
> > >  {
> > >  	x86_idle();
> > >  }
> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index a4b8189455d5..20d529722f51 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -896,7 +896,7 @@ static void noinstr rcu_eqs_exit(bool user)
> > >   * If you add or remove a call to rcu_idle_exit(), be sure to test with
> > >   * CONFIG_RCU_EQS_DEBUG=y.
> > >   */
> > > -void rcu_idle_exit(void)
> > > +void noinstr rcu_idle_exit(void)
> > >  {
> > >  	unsigned long flags;
> > >  
> > > -- 
> > > 2.35.3
> > > 

  reply	other threads:[~2022-05-16 13:39 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15 20:36 [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr Jiri Olsa
2022-05-15 20:36 ` [PATCH bpf-next 2/2] selftests/bpf: Remove filter for unsafe functions in kprobe_multi test Jiri Olsa
2022-05-16  4:25 ` [PATCH bpf-next 1/2] cpuidle/rcu: Making arch_cpu_idle and rcu_idle_exit noinstr Paul E. McKenney
2022-05-16 11:49   ` Frederic Weisbecker
2022-05-16 13:39     ` Paul E. McKenney [this message]
2022-05-17 10:13     ` Jiri Olsa
2022-05-18 16:21       ` Paul E. McKenney
2022-05-19 11:33         ` Jiri Olsa
2022-05-19 13:54           ` Paul E. McKenney
2022-05-23 13:12             ` Jiri Olsa
2022-05-24 17:33               ` Paul E. McKenney
2022-05-17  2:39 ` kernel test robot
2022-05-17  2:54 ` Yonghong Song
2022-05-17  7:49   ` Jiri Olsa
2022-05-19  0:00     ` Masami Hiramatsu
2022-05-17  9:19 ` kernel test robot
2023-05-20  9:47 ` Ze Gao
2023-05-21  3:58   ` Yonghong Song
2023-05-21 15:10     ` Re: Ze Gao
2023-05-21 20:26       ` Re: Jiri Olsa
2023-05-22  1:36         ` Re: Masami Hiramatsu
2023-05-22  2:07         ` Re: Ze Gao
2023-05-23  4:38           ` Re: Yonghong Song
2023-05-23  5:30           ` Re: Masami Hiramatsu
2023-05-23  6:59             ` Re: Paul E. McKenney
2023-05-25  0:13               ` Re: Masami Hiramatsu
2023-05-23 14:10           ` kprobes and rcu_is_watching() Steven Rostedt
2023-05-24  3:51             ` Ze Gao
2023-05-21  8:08   ` Jiri Olsa
2023-05-21 10:09     ` Re: Masami Hiramatsu
2023-05-21 14:19       ` Re: Ze Gao

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=20220516133936.GW1790663@paulmck-ThinkPad-P17-Gen-1 \
    --to=paulmck@kernel.org \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=frederic@kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.