Re: [PATCH] vm_area_struct slab corruption

[Hugh Dickins <hugh@veritas.com>]

On Thu, 6 Mar 2003, Andrew Morton wrote:
> Hugh Dickins <hugh@veritas.com> wrote:
> >
> > +	 * Note: mremap's move_vma VM_ACCOUNT handling assumes a partially
> > +	 * unmapped vm_area_struct will remain in use: so lower split_vma
> > +	 * places tmp vma above, and higher split_vma places tmp vma below.
> 
> Cough.  Would it be clearer to just return the address of the surviving vma
> from do_munmap()?  Via an extra arg, or a PTR_ERR thingy?

Sneeze.  Address of the surviving?  I think you must mean address of
the vma now previous to what's been unmapped, NULL if none previous.

Hmm, could do that: it would make the interface between move_vma and
do_munmap less fragile.  But it wouldn't make move_vma any clearer or
easier - can't make use of that previous vma without the same analysis
of cases as before.

If adding an extra arg, then the extra arg to add would be what Alan
did in 2.4-ac, int acct to control whether it does the VM_ACCOUNTing.
I resisted adding that (changing odd distant drivers), and I may have
been wrong to do so.

I'm just reluctant to make more change here at this moment, my focus
is elsewhere.  I cannot approach move_vma without wanting to change
more than is safe to do in a rush: it should be using your newer
can_vma_merge_ stuff; does its merging have to look so complex?
needs to check if do_munmap failed and behave sanely if so.
But I can't let slab corruption and backtraces await my leisure.

Hugh