Re: smp_rmb in mm/memory.c in 2.6.10

William Lee Irwin III
2005-01-13T20:39:54Z

On Thu, Jan 13, 2005 at 12:26:42PM -0800, Kanoj Sarcar wrote:
> The second question is that even though truncate_count
> is declared atomic (ie probably volatile on most
> architectures), that does not make gcc guarantee
> anything in terms of ordering, right?
> Finally, does anyone really believe that a smp_rmb()
> is required in step 2? My logic is that nopage() is
> guaranteed to grab/release (spin)locks etc as part of
> its processing, and that would force the snapshots of
> truncate_count to be properly ordered.

spin_unlock() does not imply a memory barrier. e.g. on ia32 it's
not even an atomic operation.

-- wli