On Mon, Oct 14, 2013 at 02:23:55AM -0700, Paul E. McKenney wrote: > On Mon, Oct 14, 2013 at 11:05:08AM +0200, Peter Zijlstra wrote: > > On Sat, Oct 12, 2013 at 07:06:56PM +0200, Oleg Nesterov wrote: > > > it even disables irqs, so this should always imply rcu_read_lock() with > > > any implementation, > > > > Not so; I could make an RCU implementation that drives the state machine > > from rcu_read_unlock(). Such an implementation doesn't need the > > interrupt driven poll-state driver we currently have and could thus > > subvert that assumption :-) > > > > Then again, there's a good reason PaulMck didn't pick this > > implementation. > > True enough, but there really are some out-of-tree RCU implementations > that do take this approach and where disabling interrupts would not > block preemptible RCU. So please do not rely on this implementation > detail. You never know...
Actually, the current implementation of SRCU is not blocked by CPUs disabling interrupts! Thanx, Paul > > > In fact I do not even understand why getaffinity() doesn't simply > > > return ->cpus_allowed, but this is off-topic. > > > > Yeah, me neither :-(, it always surprises me. But changing it is likely > > to break stuff so there we are. > > I know that feeling... > > Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/