On Tue, Aug 18, 2009 at 08:19:33PM -0400, Masami Hiramatsu wrote:
> Frederic Weisbecker wrote:
> > On Tue, Aug 18, 2009 at 07:17:39PM -0400, Masami Hiramatsu wrote:
> >> Frederic Weisbecker wrote:
> >>>> + while (addr < paddr) {
> >>>> + kernel_insn_init(&insn, (void *)addr);
> >>>> + insn_get_opcode(&insn);
> >>>> +
> >>>> + /* Check if the instruction has been modified. */
> >>>> + if (insn.opcode.bytes[0] == BREAKPOINT_INSTRUCTION) {
> >>>> + ret = recover_probed_instruction(buf, addr);
> >>>
> >>>
> >>>
> >>> I'm confused about the reason of this recovering. Is it to remove
> >>> kprobes behind the current setting one in the current function?
> >>
> >> No, it recovers just an instruction which is probed by a kprobe,
> >> because we need to know the first byte of this instruction for
> >> decoding it.
>
> Ah, sorry, it was not accurate. the function recovers an instruction
> on the buffer(buf), not on the real kernel text. :)
Ah ok. I'll just add a small comment about that then, and apply
it.
> >>
> >> Perhaps we'd better to have more generic interface (text_peek?)
> >> for it because another subsystem (e.g. kgdb) may want to insert int3...
> >>
> >> Thank you,
> >
> >
> > Aah, I see now, it's to keep a sane check of the instructions
> > boundaries without int 3 artifacts in the middle.
> >
> > But in that case, you should re-arm the breakpoint after your
> > check, right?
> >
> > Or may be you could do the check without repatching?
>
> Yes, it doesn't modify kernel text, just recover an original
> instruction from kernel text and backup byte on a buffer.
Ok.
> > May be by doing a copy of insn.opcode.bytes and replacing bytes[0]
> > with what a random kprobe has stolen?
>
> Hm, no, this function is protected from other kprobes by kprobe_mutex.
>
> Thank you,
Right, thanks!
> --
> Masami Hiramatsu
>
> Software Engineer
> Hitachi Computer Products (America), Inc.
> Software Solutions Division
>
> e-mail: mhiramat@xxxxxxxxxx
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
