linux-kernel - Re: [PATCH 3/3] tracing/function-return-tracer: add the overrun field

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: <alpine.DEB.1.10.0811180918480.15003@gandalf.stny.rr.com>
Date:	Tue, 18 Nov 2008 09:21:38 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] tracing/function-return-tracer: add the overrun
 field


On Mon, 17 Nov 2008, Ingo Molnar wrote:

> 
> * Frederic Weisbecker <fweisbec@...il.com> wrote:
> 
> > Impact: help to find the better depth of trace
> > 
> > We decided to arbitrary define the depth of function return trace as 
> > "20". Perhaps this is not enough. To help finding an optimal depth, 
> > we measure now the overrun: the number of functions that have been 
> > missed for the current thread. By default this is not displayed, we 
> > have to do set a particular flag on the return tracer: echo overrun 
> > > /debug/tracing/trace_options And the overrun will be printed on 
> > the right.
> > 
> > As the trace shows below, the current 20 depth is not enough.
> > 
> > update_wall_time+0x37f/0x8c0 -> update_xtime_cache (345 ns) (Overruns: 2838)
> > update_wall_time+0x384/0x8c0 -> clocksource_get_next (1141 ns) (Overruns: 2838)
> > do_timer+0x23/0x100 -> update_wall_time (3882 ns) (Overruns: 2838)
> 
> hm, interesting. Have you tried to figure out what a practical depth 
> limit would be?
> 
> With lockdep we made the experience that function call stacks can be 
> very deep - if we count IRQ contexts too it can be up to 100 in the 
> extreme cases. (but at that stage kernel stack limits start hitting 
> us)
> 
> I'd say 50 would be needed.

I was just looking at the stack tracer, and it pretty much gives us the 
answer ;-)  I'm hitting on max traces around 55, but some of those are asm 
calls. We could do 50 or 60?  We probably want to make sure that the two 
do not come close to hitting. That is, the bottom of the stack to 
overwrite the saved return addresses.

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