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

[Andi Kleen]

On Tue, Mar 29, 2005 at 11:03:02PM +0100, Hugh Dickins wrote:
> 
> > Nice approach....
> 
> Thanks.
> 
> > It will not work as well
> > on large sparse mappings as the bit vectors, but that may be tolerable.
> 
> Exactly.  It's simply what what we should be doing first, making use of
> the infrastructure we already have.  If that proves inadequate, add on top.

Ok. I will defer the bitvector patch now. 

I had it mostly working with hacks, but than I ran into
a nasty include ordering problem that scared me off so far.

> I do.  I'll resend you an earlier mail I wrote about it, I think x86_64
> is liable to leak pagetables or conversely rip pagetables out from under
> the vsyscall page - in the 32-bit emulation case, with my patches, if
> that vsyscall page has been mapped.  That it'll be fine or unnoticed
> most of the time, but really not right.
> 
> I'll also resend you Ben's mail on the subject, what he does on ppc64.

Thanks.
> 
> Ah, you do SetPageReserved on that page.  That's good, rmap would have
> a problem with it, since it doesn't belong to a file, yet is shared
> between all tasks, so is quite unlike an anonymous page.  I suggest
> you make the vma VM_RESERVED too, but that doesn't really matter yet.

Ok. I will change it to a VMA.

Only bad thing is that this has to be done at program startup.
At fault time we cannot upgrade the read lock on mmap sem to a write
lock that is needed to insert the VMA :/ But I guess that is ok
because with modern glibc basically all programs will use vsyscsall.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/