Re: [PATCH 1/5] freepgt: free_pgtables use vma list

[Hugh Dickins <hugh@veritas.com>]

On Wed, 23 Mar 2005, Benjamin Herrenschmidt wrote:
> On Tue, 2005-03-22 at 16:37 +0000, Hugh Dickins wrote:
> > 
> > I cannot see those arches doing pte_allocs outside their vmas,
> > that of course could cause it.  And nr_ptes is initialized to 0
> > once by memset and again by assignment, so it should be starting
> > out even zeroer than most fields.
> 
> We do funny things in arch/ppc64/mm/init.c in the ioremap_mm, where we
> don't use VMAs but our own mecanism (yah, ugly, but that's some legacy
> we have from the original port, though I do intend to change that at one
> point).

Thanks for the warning, Ben, but I don't see a problem there: that's
in your separate ioremap_mm, which is rather like init_mm, and won't
ever go through exit_mmap, and doesn't need its page tables freed -
isn't that right?

But it was worth auditing the different architectures for this: there
seems to be just one problem, where the x86_64 32-bit vsyscall page
is mapped into userspace by __map_syscall32 without linking a real
vma into mm.  Which Andi has already marked with his "RED-PEN".

That's not something I can fix up in a hurry.  Yes, as the comment
suggests we should probably allocate a real vma for it, but that might
have a few consequences (if only /proc/<pid>/maps showing two vdsos?).
I'll have to let someone else deal with that.

For the moment, I think the behaviour of x86_64 32bit-support with
the freepgt patches will depend on personality - ADDR_LIMIT_32BIT
should usually work fine (unless the app moves its stack elsewhere
and munmaps the old one: that might well unmap its vdso too); but
ADDR_LIMIT_3GB will be liable to leak tables (if get_user_pages or
its /proc/<pid>/maps has been examined).  I don't know how common
ADDR_LIMIT_3GB use is, but whatever: okay for testing, but not for
including the patches in a release.

Hugh