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

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

[Andrea Arcangeli]

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 -----

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

[Hugh Dickins]

On Tue, 30 Mar 2004, Andrea Arcangeli wrote:
> On Mon, Mar 29, 2004 at 08:44:25PM +0100, Hugh Dickins wrote:
> 
> > 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.

Sure, and I most certainly haven't read your future code well enough.
Your present implementation, one vma per page (in that real case where
vmas are properly merged by mainline or anonmm), is far from perfect.

anon_vma has surprised me more than once by working smoothly just
where I thought it must go wrong.  Please do surprise me again:
write that code and post the patch which resolves this doubt.

Thanks,
Hugh

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

[Andrea Arcangeli]

On Tue, Mar 30, 2004 at 06:27:18AM +0100, Hugh Dickins wrote:
> On Tue, 30 Mar 2004, Andrea Arcangeli wrote:
> > On Mon, Mar 29, 2004 at 08:44:25PM +0100, Hugh Dickins wrote:
> > 
> > > 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.
> 
> Sure, and I most certainly haven't read your future code well enough.
> Your present implementation, one vma per page (in that real case where
> vmas are properly merged by mainline or anonmm), is far from perfect.
> 
> anon_vma has surprised me more than once by working smoothly just
> where I thought it must go wrong.  Please do surprise me again:
> write that code and post the patch which resolves this doubt.

I will, it just wasn't high prio enough at this time (I mean, I still
have pending some prio-tree bit to fixup with the xfs, that was higher
prio since it impacts functionality, and the mremap race may also be
higher prio).

My point is that merging in your program will work fine, this is what
matters to me, it doesn't right now because I didn't fixup the merging
code yet, but there's nothing that will prevent your program to use just
1 single vma for the whole thing (after I fixup the merging code ;). The
bonus is that after I fixup the merging, it'll use 1 vma even for the
file mappings, not just for anonymous memory, something that is not true
with anonmm (and the complexity of doing file merging or anon-vma
merging is the same, so I will do both at the same cost).