Messages in this thread |  | | Date | Wed, 30 Mar 2005 17:08:13 +0200 | From | Andi Kleen <> | Subject | Re: [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.
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |