On Wed, Oct 09, 2013 at 05:28:33PM -0700, Paul E. McKenney wrote: > On Wed, Oct 09, 2013 at 05:12:40PM -0700, Eric Dumazet wrote: > > On Wed, 2013-10-09 at 16:40 -0700, Josh Triplett wrote: > > > > > that. Constructs like list_del_rcu are much clearer, and not > > > open-coded. Open-coding synchronization code is almost always a Bad > > > Idea. > > > > OK, so you think there is synchronization code. > > > > I will shut up then, no need to waste time. > > As you said earlier, we should at least get rid of the memory barrier > as long as we are changing the code. > > Josh, what would you suggest as the best way to avoid the memory barrier, > keep sparse happy, and not be too ugly?
The more I think about it, the more I realize that assigning an __rcu pointer to an __rcu pointer *without* a memory barrier is a sufficiently uncommon case that you probably *should* just write an open-coded assignment. Just please put a very clear comment right before it. I'd originally thought it might make sense to have a macro similar to rcu_assign_pointer, but I just don't think this is a common enough case, and we don't want people thinking they can use this in general for __rcu to __rcu assignments (most of which still need a memory barrier). - Josh Triplett -- 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/
