linux-kernel - Re: [PATCH][GIT PULL] tracing: Fix compile issue for trace_sched

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 25 Oct 2010 14:32:48 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	Jason Baron <jbaron@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	masami.hiramatsu.pt@...achi.com
Subject: Re: [PATCH][GIT PULL] tracing: Fix compile issue for
 trace_sched_wakeup.c


* Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:

> > i.e. the 'fn(timer)' call crashed.
> 
> Right, and its doing an indirect function call from the first stack entry.. which 
> would seem to suggest someone scribbled our stack..

The ESP value itself seems generally sane:

> > [   11.980010] ESI: f65bdf50 EDI: f6806a00 EBP: f6806a30 ESP: c13dff04
> > [   11.980010] Process swapper (pid: 0, ti=c13de000 task=c13e2f20 task.ti=c13de000

As task.ti is 8K aligned (as it should be), and ESP is just a tad off the top of the 
stack (as it should be: a light timer irq interrupted the idle task).

The relevant stack section looks like this:

[   11.980010]  c103d297 00000000 c10460c1 c13dff4c ca105369 00000002 ffffffff 7fffffff
[   11.980010]  c103d52b ca105369 00000002 ca105369 0000002c f6806a00 00000000 f6806a04
[   11.980010]  ca105369 00000002 ca105369 00000002 00000000 f6805dac 00000000 c1420788

and that 00000000 value after c103d297 seems to be the called fn().

The stack content looks sane as well - we have the NULL entry, then various other, 
good looking entries that dont look corrupted per se. So either there's a 4 byte 
corruption of the stack, or the place where we took 'fn' from got corrupted: either 
the timer structure or the hrtimer per-cpu data area.

(More exotic crash scenarios as possible as well, if we consider .text corruption.)

Thanks,

	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/