Messages in this thread | | | Date | Wed, 23 Mar 2005 13:28:34 +0000 (GMT) | From | Hugh Dickins <> | Subject | Re: [PATCH 1/5] freepgt: free_pgtables use vma list |
| |
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 - 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/
| |