[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170508205143.a3wsxefs4lcxityl@treble>
Date: Mon, 8 May 2017 15:51:43 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>, Jessica Yu <jeyu@...hat.com>,
Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is
broken in RCU code
On Mon, May 08, 2017 at 03:43:33PM -0500, Josh Poimboeuf wrote:
> On Mon, May 08, 2017 at 01:15:58PM -0700, Paul E. McKenney wrote:
> > On Mon, May 08, 2017 at 02:47:29PM -0500, Josh Poimboeuf wrote:
> > > On Mon, May 08, 2017 at 03:13:22PM -0400, Steven Rostedt wrote:
> >
> > [ . . . ]
> >
> > > > If rcu is not watching, calling rcu_enter_irq() will have it watch
> > > > again. Even in NMI context I believe.
> > >
> > > What if you get an NMI while running in rcu_dynticks_eqs_enter() before
> > > it increments rdtp->dynticks? Will rcu_enter_irq() still work from the
> > rcu_irq_enter()
> > > NMI?
> >
> > The rcu_nmi_enter() function willl notice that RCU is not watching, and
> > will therefore atomically increment RCU's dynticks-idle counter, which
> > will be atomically incremented again upon return. Since the bottom bit
> > of this counter controls whether or not RCU is watching, RCU will be
> > watching during the NMI, will stop watching upon return from the NMI,
> > which restores state so as to allow rcu_irq_enter() to cause RCU to once
> > again watch. (NMI algorithm due to Andy Lutomirski.)
> >
> > > I'm just trying to understand what are the cases where rcu_enter_irq()
> > > *doesn't* work from an ftrace handler.
> >
> > It doesn't work from an NMI handler. Aside from possible architecture
> > specific special cases, it should work everywhere else.
>
> Ok, so just to clarify. Is there a bug in the ftrace stack tracer in
> the following situation?
>
> 1. RCU isn't watching
> 2. An NMI hits
> 3. ist_enter() calls into the ftrace stack tracer, before
> rcu_nmi_enter() is called, so RCU isn't watching yet
> 4. The ftrace stack tracer calls rcu_irq_enter(), which has no effect,
> so RCU still isn't watching
> 5. Hilarity ensues in the ftrace stack tracer
Hm, technically, ist_enter() is for exceptions other than NMI, so the
question itself is buggy. I suppose the scenario is still possible if
you replace NMI with a debug exception or a double fault.
--
Josh
Powered by blists - more mailing lists