[lkml]   [2005]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/6] freepgt: free_pgtables use vma list
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.

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-04-06 13:31    [W:0.061 / U:6.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site