On Wed, 26 May 2010 15:39:26 -0400
Rik van Riel <riel@xxxxxxxxxx> wrote:
> @@ -303,10 +303,10 @@ again:
> goto out;
>
> anon_vma = (struct anon_vma *) (anon_mapping - PAGE_MAPPING_ANON);
> - spin_lock(&anon_vma->lock);
> + anon_vma_lock(anon_vma);
>
> if (page_rmapping(page) != anon_vma) {
> - spin_unlock(&anon_vma->lock);
> + anon_vma_unlock(anon_vma);
> goto again;
> }
>
This bit is dependent upon Peter's
mm-revalidate-anon_vma-in-page_lock_anon_vma.patch (below). I've been
twiddling thumbs for weeks awaiting the updated version of that patch
(hint).
Do we think that this patch series is needed in 2.6.35? If so, why?
And if so I guess we'll need to route around
mm-revalidate-anon_vma-in-page_lock_anon_vma.patch, or just merge it
as-is.
From: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
There is nothing preventing the anon_vma from being detached while we are
spinning to acquire the lock. Most (all?) current users end up calling
something like vma_address(page, vma) on it, which has a fairly good
chance of weeding out wonky vmas.
However suppose the anon_vma got freed and re-used while we were waiting
to acquire the lock, and the new anon_vma fits with the page->index
(because that is the only thing vma_address() uses to determine if the
page fits in a particular vma, we could end up traversing faulty anon_vma
chains.
Close this hole for good by re-validating that page->mapping still holds
the very same anon_vma pointer after we acquire the lock, if not be
utterly paranoid and retry the whole operation (which will very likely
bail, because it's unlikely the page got attached to a different anon_vma
in the meantime).
Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
Cc: Hugh Dickins <hugh.dickins@xxxxxxxxxxxxx>
Cc: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Reviewed-by: Rik van Riel <riel@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/rmap.c | 7 +++++++
1 file changed, 7 insertions(+)
diff -puN mm/rmap.c~mm-revalidate-anon_vma-in-page_lock_anon_vma mm/rmap.c
--- a/mm/rmap.c~mm-revalidate-anon_vma-in-page_lock_anon_vma
+++ a/mm/rmap.c
@@ -370,6 +370,7 @@ struct anon_vma *page_lock_anon_vma(stru
unsigned long anon_mapping;
rcu_read_lock();
+again:
anon_mapping = (unsigned long) ACCESS_ONCE(page->mapping);
if ((anon_mapping & PAGE_MAPPING_FLAGS) != PAGE_MAPPING_ANON)
goto out;
@@ -378,6 +379,12 @@ struct anon_vma *page_lock_anon_vma(stru
anon_vma = (struct anon_vma *) (anon_mapping - PAGE_MAPPING_ANON);
spin_lock(&anon_vma->lock);
+
+ if (page_rmapping(page) != anon_vma) {
+ spin_unlock(&anon_vma->lock);
+ goto again;
+ }
+
return anon_vma;
out:
rcu_read_unlock();
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>