On 07/11, Andy Lutomirski wrote: > > On Mon, Jul 11, 2016 at 11:26 AM, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > > > > Do we really care? I mean, the kernel can't crash or something like this, > > just the old vdso mapping can faultin the "wrong" page from the new > > vdso_image, right? > > That makes me nervous. IMO a mapping should have well-defined > semantics. Perhaps. but map_vdso() will be special anyway, it also changes ->vdso. For example, if a 32-bit application calls prctl(ARCH_MAP_VDSO) from a signal handler and we unmap the old vdso mapping, it will crash later trying to call the (unmapped) restorer == kernel_rt_sigreturn. > If nothing else, could be really messy if the list of > pages were wrong. I do not see anything really wrong, but I can easily miss something. And don't get me wrong, I agree that any cleanup (say, associate vdso image with vma) makes sense. > My real concern is DoS: I doubt that __install_special_mapping gets > all the accounting right. Yes, and if it was not clear I fully agree. Even if we forget about the accounting, I feel that special mappings must not be abused by userspace. > > So it seems that we should do this by hand somehow. But in fact, what > > I actually think right now is that I am totally confused and got lost ;) > > I'm starting to wonder if we should finally suck it up and give > special mappings a non-NULL vm_file so we can track them properly. > Oleg, weren't you thinking of doing that for some other reason? Yes, uprobes. Currently we can't probe vdso page(s). Oleg. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>