[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4D5F50B4.8020306@zytor.com>
Date: Fri, 18 Feb 2011 21:10:12 -0800
From: hpas@...or.com
To: Steven Rostedt <rostedt@...dmis.org>
CC: Andi Kleen <andi@...stfloor.org>,
Dominique Toupin <dominique.toupin@...csson.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
"2nddept-manager@....hitachi.co.jp"
<2nddept-manager@....hitachi.co.jp>
Subject: Re: [RFC][PATCH 0/4] ftrace: Use -mfentry when supported (this is
for x86_64 right now)
On 02/18/2011 03:02 PM, Steven Rostedt wrote:
>
> Is there any synchronization that needs to be done when doing this? Or
> can it just be:
>
> insert_breakpoint();
> update_instruction();
> remove_breakpoint();
>
> Because we need to do this for 22,000 calls in a row.
>
The sequence needs to be:
1. Set up the breakpoint handler so that it can dismiss a breakpoint
interrupt from one of the patching addresses (it can just subtract one
from the return address and IRET).
2. Replace the first byte with a breakpoint instruction.
3. IPI all processors.
4. Write all but the first byte of the new instruction.
5. Write the first byte of the new instruction.
6. IPI all processors.
7. Tear down the breakpoint hander.
Note that "IPI all processors" does not require a rendezvous like
stop_machine(): it just means the issuing processor has to wait until
each processor has been IPI'd (e.g. via smp_call_function()), but those
processors can simply IRET and continue executing.
If the breakpoint handler can be left indefinitely, steps 6-7 can be
omitted (the IRET from the breakpoint handler will provide the necessary
serialization.)
-hpa
--
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