[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.0810020910040.19018@gandalf.stny.rr.com>
Date: Thu, 2 Oct 2008 09:16:19 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Ingo Molnar <mingo@...e.hu>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Jonathan Corbet <corbet@....net>,
Mathieu Desnoyers <compudj@...stal.dyndns.org>,
LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Andrew Morton <akpm@...ux-foundation.org>,
prasad@...ux.vnet.ibm.com, "Frank Ch. Eigler" <fche@...hat.com>,
David Wilder <dwilder@...ibm.com>, hch@....de,
Martin Bligh <mbligh@...gle.com>,
Christoph Hellwig <hch@...radead.org>,
Masami Hiramatsu <mhiramat@...hat.com>,
Steven Rostedt <srostedt@...hat.com>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: [boot crash] Re: [PATCH] ring-buffer: fix build error
On Thu, 2 Oct 2008, Ingo Molnar wrote:
> [ 0.332002] Kernel panic - not syncing: Fatal exception
>
> full serial log and config attached. I'm excluding these latest commits
> from tip/master for now:
Thanks I'll take a look at this.
>
> 339ce9a: ring-buffer: fix build error
> b6eeea4: ftrace: preempt disable over interrupt disable
The above "preempt disable" is the most likely culprit. I'm trying to get
towards an interrupt disabled free and lockless code path. But in doing
so, one must be extra careful. This is why I'm taking baby steps towards
this approach. Any little error in one of these steps, and you have race
conditions biting you.
The above replaces interrupt disables with preempt disables, uses the
atomic data disable to protect against reentrancy. But this could also
have opened up a bug that was not present with the interrupts disabled
version.
> 52abc82: ring_buffer: allocate buffer page pointer
> da78331: ftrace: type cast filter+verifier
>
> i'm quite sure 52abc82 causes this problem.
Hmm, that was a trivial patch. Perhaps the trivial ones are the ones that
are most likely to be error prone. A developer will take much more care in
developing a patch that is complex than something he sees as trivial ;-)
-- Steve
>
> Another 64-bit testbox crashed too meanwhile.
>
> 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/
Powered by blists - more mailing lists