On Sat, 8 Nov 2008, Mathieu Desnoyers wrote: > > I used a rmb() so this is also safe for mixed usages in and out of > > interrupt context. On the architecture I care about this is turned into > > a simple compiler barrier and therefore doesn't make a difference, while > > smp_rmb() is a noop which isn't right. > > > > Hum ? smp_rmb() is turned into a compiler barrier on !SMP architectures. > Turning it into a NOP would be broken. Actually, ARM defines it as a > barrier(). Oh, right. I got confused somehow with read_barrier_depends(). > I *think* that smp_rmb() would be enough, supposing the access to memory > is done in program order wrt local interrupts in UP. This is basically > Steven's question, which has not received any clear answer yet. I'd like > to know what others think about it. In the mean time a pure rmb() is the safest thing to do now. Once we can convince ourselves that out-of-order reads are always rolled back upon the arrival of an interrupt then this could be relaxed. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
