> 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?
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". The ppc64 vDSO is mapped with a real VMA bot not mmap call (the vDMA is built from scratch from binfmt_elf, or rather from an arch callback issued by binfmt_elf, like the stack VMA). Though should be fine too though but you may want to double check. > 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. Why 2 ? we map the 32 bits one for 32 bits processes and the 64 bits one for 64 bits processes on ppc64 without problem ... In fact, Andi could even re-use our hook I suppose. The way I do it allows also for free copy-on-write semantics (with mprotect though, I don't set it writeable by default) so that gdb can put breakpoints in it, etc... > 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 -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> - 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/
