Il 31/10/2013 07:47, Gleb Natapov ha scritto: > This looks dubious to me. All other smp_mb__after_* variants are there > because some atomic operations have different memory barrier semantics on > different arches, It doesn't have to be arches; unlock APIs typically have release semantics only, but SRCU is stronger. > but srcu_read_unlock() have the same semantics on all > arches, so smp_mb__after_srcu_read_unlock() becomes > smp_mb__after_a_function_that_happens_to_have_mb_now_but_may_not_have_in_the_feature(). > How likely it is that smp_mb() will disappear from srcu_read_unlock() > (if was added for a reason I guess)? May be we should change documentation > to say that srcu_read_unlock() is a memory barrier which will reflect > the reality. That would be different from all other unlock APIs. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
