On Wed, 7 Apr 2010, Rik van Riel wrote:
quoted text
> 
> 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. 

			Linus
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/