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

From: Rik van Riel
Date: Wed Apr 07 2010 - 20:40:48 EST

On 04/07/2010 06:15 PM, Linus Torvalds wrote:
On Wed, 7 Apr 2010, Linus Torvalds wrote:

In the long run, it would be nicer to actually return an error from the
mmap() that fails, but that's more complicated, and as mentioned, it's not
what the old code used to do either (since the failure point was always at
the page fault stage).

Put another way: I'm not proud of it, but the new code isn't any worse
than what we used to have, and I think the new code is _fixable_.

Agreed, it is no worse than what we had before.

As to fixable, I supect both situations are fixable.
The new code by getting the error paths right, the
old code by completely bailing out of the page fault
and retrying it (the pageout code should trigger an
OOM kill at some point, if we are really out of memory).

The easiest way to do that would likely be to pre-allocate the anon_vma
struct (and anon_vma_chain), and pass it down to anon_vma_prepare. That
way anon_vma_prepare() itself can never fail, and all we need to do is a
simple allocation earlier in the call-chain.

That may not work, because we may want to merge the anon_vma
with the anon_vma in an adjacant VMA ... and that adjacant
VMA could be chained onto multiple anon_vmas.

That means allocating a single anon_vma_chain may not be
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