On Thu, Aug 29, 2019 at 01:14:54PM -0400, Joel Fernandes wrote:
> On Thu, Aug 29, 2019 at 09:13:01AM -0700, Paul E. McKenney wrote:
> > On Thu, Aug 29, 2019 at 11:13:25AM -0400, Joel Fernandes wrote:
> > > On Thu, Aug 29, 2019 at 10:43:55AM -0400, Joel Fernandes wrote:
> > > > On Wed, Aug 28, 2019 at 08:43:36PM -0700, Paul E. McKenney wrote:
> > > > [snip]
> > > > > > > > > This change is not fixing a bug, so there is no need for an
> > > > > > > > > emergency fix,
> > > > > > > > > and thus no point in additional churn. I understand that it
> > > > > > > > > is a bit
> > > > > > > > > annoying to code and test something and have your friendly
> > > > > > > > > maintainer say
> > > > > > > > > "sorry, wrong rocks", and the reason that I understand this
> > > > > > > > > is that I do
> > > > > > > > > that to myself rather often.
> > > > > > > >
> > > > > > > > The motivation for me for this change is to avoid future bugs
> > > > > > > > such as with
> > > > > > > > the following patch where "== 2" did not take the force write of
> > > > > > > > DYNTICK_IRQ_NONIDLE into account:
> > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git/commit/?h=dev&id=13c4b07593977d9288e5d0c21c89d9ba27e2ea1f
> > > > > > >
> > > > > > > Yes, the current code does need some simplification.
> > > > > > >
> > > > > > > > I still don't see it as pointless churn, it is also a
> > > > > > > > maintenance cost in its
> > > > > > > > current form and the simplification is worth it IMHO both from
> > > > > > > > a readability,
> > > > > > > > and maintenance stand point.
> > > > > > > >
> > > > > > > > I still don't see what's technically wrong with the patch. I
> > > > > > > > could perhaps
> > > > > > > > add the above "== 2" point in the patch?
> > > > > > >
> > > > > > > I don't know of a crash or splat your patch would cause, if that
> > > > > > > is
> > > > > > > your question. But that is also true of the current code, so the
> > > > > > > point
> > > > > > > is simplification, not bug fixing. And from what I can see,
> > > > > > > there is an
> > > > > > > opportunity to simplify quite a bit further. And with something
> > > > > > > like
> > > > > > > RCU, further simplification is worth -serious- consideration.
> > > > > > >
> > > > > > > > We could also discuss f2f at LPC to see if we can agree about
> > > > > > > > it?
> > > > > > >
> > > > > > > That might make a lot of sense.
> > > > > >
> > > > > > Sure. I am up for a further redesign / simplification. I will think
> > > > > > more
> > > > > > about your suggestions and can also further discuss at LPC.
> > > > >
> > > > > One question that might (or might not) help: Given the compound
> > > > > counter,
> > > > > where the low-order hex digit indicates whether the corresponding CPU
> > > > > is running in a non-idle kernel task and the rest of the hex digits
> > > > > indicate the NMI-style nesting counter shifted up by four bits, what
> > > > > could rcu_is_cpu_rrupt_from_idle() be reduced to?
> > > > >
> > > > > > And this patch is on LKML archives and is not going anywhere so
> > > > > > there's no
> > > > > > rush I guess ;-)
> > > > >
> > > > > True enough! ;-)
> > > >
> > > > Paul, do we also nuke rcu_eqs_special_set()? Currently I don't see
> > > > anyone
> > > > using it. And also remove the bottom most bit of dynticks?
> > > >
> > > > Also what happens if a TLB flush broadcast is needed? Do we IPI nohz or
> > > > idle
> > > > CPUs are the moment?
> > > >
> > > > All of this was introduced in:
> > > > b8c17e6664c4 ("rcu: Maintain special bits at bottom of ->dynticks
> > > > counter")
> > >
> > >
> > > Paul, also what what happens in the following scenario:
> > >
> > > CPU0 CPU1
> > >
> > > A syscall causes rcu_eqs_exit()
> > > rcu_read_lock();
> > > ---> FQS loop
> > > waiting on
> > > dyntick_snap
> > > usermode-upcall entry -->causes rcu_eqs_enter();
> > >
> > > usermode-upcall exit -->causes rcu_eqs_exit();
> > >
> > > ---> FQS loop sees
> > > dyntick snap
> > > increment and
> > > declares CPU0 is
> > > in a QS state
> > > before the
> > > rcu_read_unlock!
> > >
> > > rcu_read_unlock();
> > > ---
> > >
> > > Does the context tracking not call rcu_user_enter() in this case, or did I
> > > really miss something?
> >
> > Holding rcu_read_lock() across usermode execution (in this case,
> > the usermode upcall) is a bad idea. Why is CPU 0 doing that?
>
> Oh, ok. I was just hypothesizing that since usermode upcalls from
> something as heavy as interrupts, it could also mean we had the same from
> some path that held an rcu_read_lock() as well. It was just a theoretical
> concern, if it is not an issue, no problem.
Are there the usual lockdep checks in the upcall code? Holding a spinlock
across them would seem to be at least as bad as holding an rcu_read_lock()
across them.
> The other question I had was, in which cases would dyntick_nesting in current
> RCU code be > 1 (after removing the lower bit and any crowbarring) ? In the
> scenarios I worked out on paper, I can only see this as 1 or 0. But the
> wording of it is 'dynticks_nesting'. May be I am missing a nesting scenario?
> We can exit RCU-idleness into process context only once (either exiting idle
> mode or user mode). Both cases would imply a value of 1.
Interrrupt -> NMI -> certain types of tracing. I believe that can get
it to 5. There might be even more elaborate sequences of events.
Thanx, Paul
