[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140305072022.6f69f699@gandalf.local.home>
Date: Wed, 5 Mar 2014 07:20:22 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: mingo@...nel.org, hpa@...or.com, paulus@...ba.org,
linux-kernel@...r.kernel.org, acme@...stprotocols.net,
seiji.aguchi@....com, jolsa@...hat.com, vincent.weaver@...ne.edu,
tglx@...utronix.de, hpa@...ux.intel.com,
linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86, trace: Fix CR2 corruption when tracing
page faults
On Wed, 5 Mar 2014 12:14:15 +0100
Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Mar 04, 2014 at 04:03:25PM -0800, tip-bot for Jiri Olsa wrote:
>
> FWIW I also prefer this patch.
>
> > @@ -1252,9 +1249,11 @@ dotraplinkage void __kprobes
> > do_page_fault(struct pt_regs *regs, unsigned long error_code)
> > {
> > enum ctx_state prev_state;
> > + /* Get the faulting address: */
> > + unsigned long address = read_cr2();
> >
> > prev_state = exception_enter();
> > - __do_page_fault(regs, error_code);
> > + __do_page_fault(regs, error_code, address);
> > exception_exit(prev_state);
> > }
> >
> > @@ -1271,9 +1270,16 @@ dotraplinkage void __kprobes
> > trace_do_page_fault(struct pt_regs *regs, unsigned long error_code)
> > {
> > enum ctx_state prev_state;
> > + /*
> > + * The exception_enter and tracepoint processing could
> > + * trigger another page faults (user space callchain
> > + * reading) and destroy the original cr2 value, so read
> > + * the faulting address now.
> > + */
> > + unsigned long address = read_cr2();
> >
> > prev_state = exception_enter();
> > trace_page_fault_entries(regs, error_code);
> > - __do_page_fault(regs, error_code);
> > + __do_page_fault(regs, error_code, address);
> > exception_exit(prev_state);
> > }
>
> How about also marking these two functions as notrace? That would also
> avoid getting __mcount calls from before we read CR2.
Please no! I used tracing of the do_page_fault function all the time.
It is very useful.
Call backs from function tracing are to be very limited. They are more
restrictive than NMI contexts. One thing you shouldn't do is to have
page faults. Thus, fix the callback.
-- 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