[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141121121136.18df4ecb@gandalf.local.home>
Date: Fri, 21 Nov 2014 12:11:36 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Tejun Heo <tj@...nel.org>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Dave Jones <davej@...hat.com>, Don Zickus <dzickus@...hat.com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Andy Lutomirski <luto@...capital.net>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: frequent lockups in 3.18rc4
On Fri, 21 Nov 2014 12:01:51 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:
> Looking at kernel/trace/trace_functions.c: function_trace_call() which is
> registered with RECURSION_SAFE, I see that the recursion check is done
> before the per_cpu_ptr() call to the dynamically allocated per_cpu data.
>
> It looks OK, but...
>
> Oh! but if we trace the page fault handler, and we fault here too
> we just nuked the cr2 register. Not good.
Ah! Looking at the code, I see that do_page_fault (called from
assembly) is marked notrace. And the first thing it does is:
unsigned long address = read_cr2();
And uses that. Thus if the function tracer were to fault on
exception_enter() or __do_page_fautt(), the address wont be
clobbered.
-- 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/
Powered by blists - more mailing lists