Messages in this thread | | | Date | Thu, 14 Jan 2010 11:42:15 -0500 | From | Jason Baron <> | Subject | Re: [RFC PATCH 2/8] jump label v4 - x86: Introduce generic jump patching without stop_machine |
| |
On Thu, Jan 14, 2010 at 11:23:35AM -0500, Masami Hiramatsu 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, >
sorry about that...i've updated to the latest.
thanks,
-Jason
| |