[andrea@suse.de: Re: 2.6.5-rc2-aa vma merging]

[Andrea Arcangeli <andrea@suse.de>]

though it was a private email.

----- Forwarded message from Andrea Arcangeli <andrea@suse.de> -----

Date: Tue, 30 Mar 2004 00:32:30 +0200
From: Andrea Arcangeli <andrea@suse.de>
To: Hugh Dickins <hugh@veritas.com>
Subject: Re: 2.6.5-rc2-aa vma merging

On Mon, Mar 29, 2004 at 08:44:25PM +0100, Hugh Dickins wrote:
> Andrea,
> 
> Again I beg you to attend to vma merging in your anon_vma tree.
> Still you have #if VMA_MERGING_FIXUP throughout mm/mprotect.c
> (and much less seriously in mremap.c), and that's just masking
> the real problem: that when you do enable vma merging there, your
> anon_vmas will get in the way of merging in significant cases.
> 
> Try the example below, on mainline and on anonmm and on anon_vma,
> even when you've done the VMA_MERGING_FIXUP: you're limited by the
> MAX_MAP_COUNT of vmas, one per page.  Now, I know there's a move
> afoot to have /proc/sys/vm/max_map_count tunable, but I don't
> think that's the right answer for you ;)
> 
> If I remember rightly, Linus tried to do away with a lot of the
> vma merging about three years ago, but some had to be reinstated.

it was me to reistantiate it. And it wasn't for mprotect. Infact it was
me adding it to mprotect and mremap too, it has never been there before
(the day I did mprotect and mremap I got bored at some point and that's
why we never had it for mlock yet).

> So I assume that what's there is needed, and the example below
> does looks plausible enough: add page, fill it, protect it, ...

this will work perfect, absolutely perfect. You didn't read my code well
enough.

You still can write an exploit for it, but it will not be a real life
one.

----- End forwarded message -----