anon_vma_prepare: properly lock even newly allocated entries
authorLinus Torvalds <torvalds@linux-foundation.org>
Sun, 19 Oct 2008 17:32:20 +0000 (10:32 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sun, 19 Oct 2008 18:50:35 +0000 (11:50 -0700)
commitd9d332e0874f46b91d8ac4604b68ee42b8a7a2c6
tree070023e76343c4713c352aba31faae042ad3d4a6
parent0cfd81031a26717fe14380d18275f8e217571615
anon_vma_prepare: properly lock even newly allocated entries

The anon_vma code is very subtle, and we end up doing optimistic lookups
of anon_vmas under RCU in page_lock_anon_vma() with no locking.  Other
CPU's can also see the newly allocated entry immediately after we've
exposed it by setting "vma->anon_vma" to the new value.

We protect against the anon_vma being destroyed by having the SLAB
marked as SLAB_DESTROY_BY_RCU, so the RCU lookup can depend on the
allocation not being destroyed - but it might still be free'd and
re-allocated here to a new vma.

As a result, we should not do the anon_vma list ops on a newly allocated
vma without proper locking.

Acked-by: Nick Piggin <npiggin@suse.de>
Acked-by: Hugh Dickins <hugh@veritas.com>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/rmap.c