summaryrefslogtreecommitdiffstats
path: root/.mailmap
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2008-10-19 10:32:20 -0700
committerLinus Torvalds <torvalds@linux-foundation.org>2008-10-19 11:50:35 -0700
commitd9d332e0874f46b91d8ac4604b68ee42b8a7a2c6 (patch)
tree070023e76343c4713c352aba31faae042ad3d4a6 /.mailmap
parent0cfd81031a26717fe14380d18275f8e217571615 (diff)
downloadop-kernel-dev-d9d332e0874f46b91d8ac4604b68ee42b8a7a2c6.zip
op-kernel-dev-d9d332e0874f46b91d8ac4604b68ee42b8a7a2c6.tar.gz
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>
Diffstat (limited to '.mailmap')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud