Re: [PATCH V2 2/7] rcu: cleanup rcu_preempt_deferred_qs()
From: Paul E. McKenney
Date: Tue Feb 18 2020 - 11:43:17 EST
On Tue, Feb 18, 2020 at 09:41:24AM -0500, Steven Rostedt wrote:
> On Mon, 17 Feb 2020 15:23:07 -0800
> "Paul E. McKenney" <paulmck@xxxxxxxxxx> wrote:
> > > I'm still asking for more comments.
> > >
> > > By now, I have received some precious comments, mainly due to my
> > > stupid naming mistakes and a misleading changelog. I should have
> How about typos?
We appear to have enough typos, thank you!
> > > updated all these with a new series patches. But I hope I
> > > can polish more in the new patchset with more suggestions from
> > > valuable comments, especially in x86,scheduler,percpu and rcu
> > > areas.
> > >
> > > I'm very obliged to hear anything.
> > commit 23a58acde0eea57ac77377e5d50d9562b2dbdfaa
> > Author: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx>
> > Date: Sat Feb 15 14:37:26 2020 -0800
> > rcu: Don't set nesting depth negative in rcu_preempt_deferred_qs()
> > Now that RCU flavors have been consolidated, an RCU-preempt
> > rcu_rea_unlock() in an interrupt or softirq handler cannot possibly
> What's a "rea"? ;-)
A typo. Probably mine. Thank you for catching it, will fix! ;-)
But maybe an rcu_rhea_lock()? Just in case the rheas are getting loose?
> -- Steve
> > end the RCU read-side critical section. Consider the old vulnerability
> > involving rcu_preempt_deferred_qs() being invoked within such a handler
> > that interrupted an extended RCU read-side critical section, in which
> > a wakeup might be invoked with a scheduler lock held. Because
> > rcu_read_unlock_special() no longer does wakeups in such situations,
> > it is no longer necessary for rcu_preempt_deferred_qs() to set the
> > nesting level negative.
> > This commit therfore removes this recursion-protection code from
> > rcu_preempt_deferred_qs().
> > Signed-off-by: Lai Jiangshan <laijs@xxxxxxxxxxxxxxxxx>
> > Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>