Will Deacon <will.dea...@arm.com> wrote: > FWIW, that's exactly what my patches do, this fixup looks a bit weird > because it removes a prior barrier which suggests that either (a) it's in > the wrong place to start with, or (b) we're annotating the wrong load.
There is a loop involved. The barrier is against the read in the previous iteration of the loop. IIRC, the reason I did it this way is to avoid the need for the barrier if there's nothing on the 'after-side' - ie. we examine the pointer and see that it's NULL or a leaf. However, I'm not sure that's a particularly necessary optimisation. So if READ_ONCE() issues a smp_read_barrier_depends() after the read, then I've no problem with the removal of these explicit barriers. I will, however, quibble with the appropriateness of the name READ_ONCE()... I still think it's not sufficiently obvious that this is a barrier and the barrier is after. Maybe READ_AND_BARRIER()? Also, does WRITE_ONCE() imply a preceding barrier? David
