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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
