Public bug reported:
SRU Justification: This patch has been accepted into the upstream 2.6.27.4
stable kernel.
It should be pulled into the Ubuntu kernel as well.
TEST CASE: TBD
commit 07a96d7019701ce9e6be9bd975e4f9d021649a8f
Author: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sun Oct 19 10:32:20 2008 -0700
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 <[EMAIL PROTECTED]>
Acked-by: Hugh Dickins <[EMAIL PROTECTED]>
Acked-by: Peter Zijlstra <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
anon_vma_prepare: properly lock even newly allocated entries
https://bugs.launchpad.net/bugs/294003
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
