Re: perf_event_mmap(vma) && !vma->vm_mm

From: Peter Zijlstra
Date: Mon Oct 14 2013 - 06:24:42 EST


On Sat, Oct 12, 2013 at 09:22:03PM +0200, Oleg Nesterov wrote:
> Hi,
>
> I am fighting with uprobe bug, and perf_event_mmap() complicates
> the problem, it is the only reason (afaics) why the forking task
> can not do install_special_mapping(new_child_mm). This means that
> the child should do this itself, say, from task_work_run() but
> this way it can't handle the error if get_xol_area() fails, too
> late to abort the already finished copy_process().
>
> But please ignore, the only question is that I can't understand
> this
>
> if (!vma->vm_mm) {
> name = strncpy(tmp, "[vdso]", sizeof(tmp));
> goto got_name;
> }
>
> code in perf_event_mmap_event() and I am just curious. How it is
> possible that vma->vm_mm == NULL ? perf_event_mmap(vma) is never
> called with, say, vma == gate_vma. And even if it was possible
> arch_vma_name() should handle this case?

Uuuhhhh... I wrote that didn't I ;-)

So I think that was due to the x86_32 gate_vma, but yes I don't think
we'd ever call perf_event_mmap() (perf_counter_mmap at the time) on it.

Also, the x86_32 arch_vma_name() didn't deal with the gate_vma (it still
doesn't appear to do so) as opposed to x86_64 which does.

But the main reason I added it was because task_mmu.c:show_map_vma() did
so too; I just wanted to be extra careful.

--
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/