On Tue, Jun 09, 2020 at 11:02:27AM -0700, Paul E. McKenney wrote: > > > > And anyway we still want to unconditionally lock on many places, > > > > regardless of the offloaded state. I don't know how we could have > > > > a magic helper do the unconditional lock on some places and the > > > > conditional on others. > > > > > > I was assuming (perhaps incorrectly) that an intermediate phase between > > > not-offloaded and offloaded would take care of all of those cases. > > > > Perhaps partly but I fear that won't be enough. > > One approach is to rely on RCU read-side critical sections surrounding > the lock acquisition and to stay in the intermediate phase until a grace > period completes, preferably call_rcu() instead of synchronize_rcu(). > > This of course means refusing to do a transition if the CPU is still > in the intermediate state from a prior transition.
That sounds good. But using synchronize_rcu() would be far easier. We need to keep the hotplug and rcu barrier locked during the transition. > > Also I've been thinking that rcu_nocb_lock() should meet any of these > > requirements: > > > > * hotplug is locked > > * rcu barrier is locked > > * rnp is locked > > > > Because checking the offloaded state (when nocb isn't locked yet) of > > an rdp without any of the above locks held is racy. And that should > > be easy to check and prevent from copy-pasta accidents. > > > > What do you think? > > An RCU read-side critical section might be simpler. Ok I think I can manage that. Thanks.
