linux-kernel - Re: [PATCH] Identify which executable object the userspace address belongs to. Store thread group leader id, and use it to lookup the address in the process's map. We could have looked up the address on thread's map, but the thread might not exist by the time we are called. The process might not exist either, but if you are reading trace

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]

Date:	Mon, 3 Nov 2008 15:04:06 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Török Edwin <edwintorok@...il.com>
Cc:	Robert Richter <robert.richter@....com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	srostedt@...hat.com, a.p.zijlstra@...llo.nl, sandmann@...mi.au.dk,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Identify which executable object the userspace address
	belongs to. Store thread group leader id, and use it to lookup the
	address in the process's map. We could have looked up the address
	on thread's map, but the thread might not exist by the time we are
	called. The process might not exist either, but if you are reading
	trace_pipe, that is unlikely.


* Török Edwin <edwintorok@...il.com> wrote:

> > note that NMI interaction of user-space stackframe walkers can be 
> > a bit tricky: the basic problem is that if you fetch a user-space 
> > stackframe that can create a fault
> 
> The code in trace_sysprof.c (which I used as a base for the 
> save_stack_trace_user) disables pagefaults before reading the 
> stackframe from userspace. Does it avoid this problem then?

no, it does not solve it - because pagefault_disable is a "soft" 
mechanism which does not disable the faults themselves. (it only 
disables some of their effects)

> > , and the IRET at the end of the fault handler will re-enable NMIs 
> > (violating the NMI code's assumptions).
> 
> Is this already a problem with oprofile's user-stack walker?

yes, oprofile's code is buggy here too. And not enabled by default, 
and probably not used by many people. The bug would show up as 
mistakenly enabled NMIs from within NMIs - the kernel will _probably_ 
live but could lock up or overflow its stack, etc.

> > The best approach would be if the kernel could output the best 
> > info by default
> 
> The kernel could do some grouping and counting (as latencytop does), 
> but I don't see where it would fit in frace's infrastructure.
>
> I think ftrace's one entry per event is useful in many situations 
> (debugging, latency measurements), but if the events occur too 
> frequently it could produce too much data, and it would be more 
> efficient to do some counting/grouping of similar info in-kernel 
> before outputting to userspace. Perhaps as a layer on top of ftrace? 
> What do you think?

yes, histogram generation would be a natural 'view' of a tracer: have 
a look at Steve's likely()/unlikely() tracer that introduces that 
notion into ftrace.

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