Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmasof a mergeable VMA

From: Linus Torvalds
Date: Wed Apr 07 2010 - 13:01:37 EST

On Wed, 7 Apr 2010, Rik van Riel wrote:
> You are right, the idea was to continue use the locking that
> the anon_vma code was already using, without introducing any
> new locking with the anon_vma patches.
> However, it has become clear that this is no longer possible,
> due to the need to hold a secondary lock across anon_vma_clone,
> when we come from a code path that holds the mmap_sem for read.

I do wonder if we could possibly simplify this a _lot_ by just requiring
that the anon_vma gets allocated at vma creation time (ie mmap), rather
than doing it on-demand when we actually do the page fault.

That would make all of this crap happen under mmap_sem held for writing,
and it would simplify the faulting code (which is the much more critical
code) a lot.

And it would make all your locking problems go away. Now all anon_vma code
really _would_ run with mmap_sem held exclusively, without any races.

When I tried to do a "fill in multiple page table entries in one go"
patch, that annoying anon_vma issue was a problem as well. Allocating the
anon_vma up-front would have simplified that code too.

I can't imagine that we ever really have mappings without an anon_vma in
practice _anyway_, so why delay the allocation until page fault time?

Maybe I'm missing something subtle.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at