From: Linus Torvalds Date: Sun, 19 Oct 2008 17:32:20 +0000 (-0700) Subject: anon_vma_prepare: properly lock even newly allocated entries X-Git-Tag: v2.6.27.4~9 X-Git-Url: http://git.openpandora.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=07a96d7019701ce9e6be9bd975e4f9d021649a8f;p=pandora-kernel.git anon_vma_prepare: properly lock even newly allocated entries commit d9d332e0874f46b91d8ac4604b68ee42b8a7a2c6 upstream 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 Acked-by: Hugh Dickins Acked-by: Peter Zijlstra Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- Reading git-diff-tree failed