On Fri, Oct 16, 2015 at 09:28:24AM -0700, Paul E. McKenney wrote: > > Maybe some previous RCU variant relied on this? > > Yes, older versions did rely on this. Now, only the CPU itself observes > RCU's state changes during context switch. I couldn't tell you exactly > when this changed. :-/ > > With the exception of some synchronize_sched_expedited() cases, but in > those cases, RCU code acquires the CPU's leaf rcu_node structure's > ->lock, and with the required strong transitivity.
OK, so I can scrap this 'requirement' from my list. All sorted, thanks! > > > Well, arm64 might well need smp_mb__after_unlock_lock() to be non-empty. > > > > Its UNLOCK+LOCK should be RCsc, so that should be good. Its just that > > LOCK+UNLOCK isn't anything. > > Ah! If RCU relies on LOCK+UNLOCK being a barrier of any sort, that is a > bug in RCU that needs fixing. Don't think RCU does that, But its what schedule() provides in the weakest case. Hence my question here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
