On Wed, Sep 23, 2015 at 11:54:40AM -0400, Tejun Heo wrote: > > Hmm... lemme try again. When using barriers or RCU, it's desirable to > establish certain invariants because it usually is extremely easy to > miss corner cases. It is helpful to have an abstraction, even if just > conceptual, where people can go "this thing is barrier / RCU protected > to guarantee XYZ". Going more towards RCU example, this is why we > annotate variables as RCU protected to detect incorrect usages. There > sure are exceptions but most are of the sort "this is write path and > protected by something else which is annotated differently". Doing > things this way makes it a lot easier to get right.
Well if someone provided helpers which 1) uses smp_wmb and smp_rmb instead of full barriers; 2) provides raw variants for the cases that barriers aren't needed then I'm more than happy to use them. Having reviewed the situation again I'm even more convincend now that smp_load_acquire/smp_store_release aren't the appropriate primitives for us. They are meant for situations that are similar to spin lock/unlock where you need to prevent all reads/writes from floating above or below the load/store, respectively. For our situation we only need write or read ordering, so they are literally the wrong tool for the job and will only cause confusion in future when someone tries to do a major rewrite of the code and they will be scratching their head as to why we needed locking-like semantics here. Cheers, -- Email: Herbert Xu <herb...@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html