Re: [PATCH 1/5] freepgt: free_pgtables use vma list

[Benjamin Herrenschmidt]

> 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 <benh@xxxxxxxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/