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? > > 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"? ;-) -- 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> > >
