lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131014102426.GX3081@twins.programming.kicks-ass.net>
Date:	Mon, 14 Oct 2013 12:24:26 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: perf_event_mmap(vma) && !vma->vm_mm

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ