Messages in this thread |  | | | Date | Thu, 14 Jan 2010 11:23:35 -0500 | | From | Masami Hiramatsu <> | | Subject | Re: [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine |
| |
Mathieu Desnoyers wrote: > * Steven Rostedt (rostedt@goodmis.org) wrote: >> On Tue, 2010-01-12 at 11:26 -0500, Jason Baron wrote: >> >>> +/** >>> + * text_poke_fixup() -- cross-modifying kernel text with fixup address. >>> + * @addr: Modifying address. >>> + * @opcode: New instruction. >>> + * @len: length of modifying bytes. >>> + * @fixup: Fixup address. >>> + * >>> + * Note: You must backup replaced instructions before calling this, >>> + * if you need to recover it. >>> + * Note: Must be called under text_mutex. >>> + */ >>> +void *__kprobes text_poke_fixup(void *addr, const void *opcode, size_t len, >>> + void *fixup) >>> +{ >>> + static const unsigned char int3_insn = BREAKPOINT_INSTRUCTION; >>> + static const int int3_size = sizeof(int3_insn); >>> + >>> + /* Replacing 1 byte can be done atomically. */ >>> + if (unlikely(len <= 1)) >>> + return text_poke(addr, opcode, len); >> >> This part bothers me. The text_poke just writes over the text directly >> (using a separate mapping). But if that memory is in the pipeline of >> another CPU, I think this could cause a GPF. > > It looks like we are thinking along the same lines. > > I'm under the impression that I pointed out this exact same issue in the > previous round of review a few weeks ago. Does this submission reflect > the up-to-date state of this patch ?
No, the latest patch just skips step 3 if len == 1. (Jason, could you update your repository?) I thought I sent it the end of the last year ... :)
http://lkml.org/lkml/2009/12/18/312
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
|  |