All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>,
	systemtap <systemtap@sources.redhat.com>,
	kvm <kvm@vger.kernel.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Jim Keniston <jkenisto@us.ibm.com>
Subject: Re: [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86
Date: Mon, 11 May 2009 11:14:36 -0400	[thread overview]
Message-ID: <4A0840DC.7080507@redhat.com> (raw)
In-Reply-To: <4A083DAD.8000009@redhat.com>

Masami Hiramatsu wrote:
>>> +	if (!kallsyms_lookup(paddr, NULL, &offset, NULL, __dummy_buf))
>>> +		return 0;
>>> +
>>> +	/* Decode instructions */
>>> +	addr = paddr - offset;
>>> +	while (addr < paddr) {
>>> +		insn_init_kernel(&insn, (void *)addr);
>>> +		insn_get_opcode(&insn);
>>> +		if (OPCODE1(&insn) == BREAKPOINT_INSTRUCTION) {
>>> +			ret = recover_probed_instruction(buf, addr);
>> Oh, the above puts back the original op code. That is why it is OK?
> 
> Oops, no. I have to use get_kprobe() instead. Thanks!

Ah, I forgot another possibility. There might be another subsystem,
like kgdb, will put their break point on the kernel.
In that case, decoder will decode the instruction is a break point
instruction and the first opcode is int3. So, this part is correct.
In the future, we need to add a generic recover_instruction() code
for those text modification subsystems.

Thank you,
-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com


WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <mhiramat@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ingo Molnar <mingo@elte.hu>, lkml <linux-kernel@vger.kernel.org>,
	        systemtap <systemtap@sources.redhat.com>,
	kvm <kvm@vger.kernel.org>,
	        Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	        Jim Keniston <jkenisto@us.ibm.com>
Subject: Re: [PATCH -tip v5 2/7] kprobes: checks probe address is instruction  boudary on x86
Date: Mon, 11 May 2009 11:14:36 -0400	[thread overview]
Message-ID: <4A0840DC.7080507@redhat.com> (raw)
In-Reply-To: <4A083DAD.8000009@redhat.com>

Masami Hiramatsu wrote:
>>> +	if (!kallsyms_lookup(paddr, NULL, &offset, NULL, __dummy_buf))
>>> +		return 0;
>>> +
>>> +	/* Decode instructions */
>>> +	addr = paddr - offset;
>>> +	while (addr < paddr) {
>>> +		insn_init_kernel(&insn, (void *)addr);
>>> +		insn_get_opcode(&insn);
>>> +		if (OPCODE1(&insn) == BREAKPOINT_INSTRUCTION) {
>>> +			ret = recover_probed_instruction(buf, addr);
>> Oh, the above puts back the original op code. That is why it is OK?
> 
> Oops, no. I have to use get_kprobe() instead. Thanks!

Ah, I forgot another possibility. There might be another subsystem,
like kgdb, will put their break point on the kernel.
In that case, decoder will decode the instruction is a break point
instruction and the first opcode is int3. So, this part is correct.
In the future, we need to add a generic recover_instruction() code
for those text modification subsystems.

Thank you,
-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@redhat.com

  reply	other threads:[~2009-05-11 15:13 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-09  0:48 [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Masami Hiramatsu
2009-05-09  0:48 ` Masami Hiramatsu
2009-05-09  0:48 ` [PATCH -tip v5 1/7] x86: instruction decorder API Masami Hiramatsu
2009-05-11  9:27   ` Christoph Hellwig
2009-05-11  9:27     ` Christoph Hellwig
2009-05-11 14:36     ` Masami Hiramatsu
2009-05-11 14:36       ` Masami Hiramatsu
2009-05-13  8:23   ` Gleb Natapov
2009-05-13  8:23     ` Gleb Natapov
2009-05-13  9:35     ` Przemysław Pawełczyk
2009-05-13  9:43       ` Gleb Natapov
2009-05-13  9:43         ` Gleb Natapov
2009-05-13 14:35         ` Masami Hiramatsu
2009-05-13 14:35           ` Masami Hiramatsu
2009-05-13 15:20           ` Gleb Natapov
2009-05-09  0:48 ` [PATCH -tip v5 2/7] kprobes: checks probe address is instruction boudary on x86 Masami Hiramatsu
2009-05-09  0:48   ` Masami Hiramatsu
2009-05-11 14:20   ` Steven Rostedt
2009-05-11 15:01     ` Masami Hiramatsu
2009-05-11 15:01       ` Masami Hiramatsu
2009-05-11 15:14       ` Masami Hiramatsu [this message]
2009-05-11 15:14         ` Masami Hiramatsu
2009-05-11 15:22       ` Steven Rostedt
2009-05-11 18:21         ` Masami Hiramatsu
2009-05-11 18:21           ` Masami Hiramatsu
2009-05-09  0:48 ` [PATCH -tip v5 3/7] kprobes: cleanup fix_riprel() using insn decoder " Masami Hiramatsu
2009-05-09  0:48   ` Masami Hiramatsu
2009-05-09  0:48 ` [PATCH -tip v5 4/7] tracing: add kprobe-based event tracer Masami Hiramatsu
2009-05-09 16:36   ` Frédéric Weisbecker
2009-05-09 16:36     ` Frédéric Weisbecker
2009-05-09 17:33     ` Masami Hiramatsu
2009-05-11 21:26       ` Frederic Weisbecker
2009-05-11  9:32   ` Christoph Hellwig
2009-05-11 10:53     ` Ingo Molnar
2009-05-11 10:53       ` Ingo Molnar
2009-05-11 15:28     ` Frank Ch. Eigler
2009-05-11 15:28       ` Frank Ch. Eigler
2009-05-09  0:49 ` [PATCH -tip v5 5/7] x86: fix kernel_trap_sp() Masami Hiramatsu
2009-05-11  9:28   ` Christoph Hellwig
2009-05-11 13:48     ` Masami Hiramatsu
2009-05-11 13:48       ` Masami Hiramatsu
2009-05-09  0:49 ` [PATCH -tip v5 6/7] x86: add pt_regs register and stack access APIs Masami Hiramatsu
2009-05-09  0:49 ` [PATCH -tip v5 7/7] tracing: add arguments support on kprobe-based event tracer Masami Hiramatsu
2009-05-11 14:35   ` Steven Rostedt
2009-05-11 14:35     ` Steven Rostedt
2009-05-09  4:43 ` [PATCH -tip v5 0/7] tracing: kprobe-based event tracer and x86 instruction decoder Ingo Molnar
2009-05-09  4:43   ` Ingo Molnar
2009-05-11 14:40   ` Masami Hiramatsu
2009-05-11 14:56     ` Steven Rostedt
2009-05-11 20:05       ` Masami Hiramatsu
2009-05-11 20:05         ` Masami Hiramatsu
2009-05-11 21:47         ` Ingo Molnar
2009-05-11 21:47           ` Ingo Molnar
2009-05-12 22:03   ` Masami Hiramatsu
2009-05-12 22:03     ` Masami Hiramatsu
2009-05-13 13:21     ` Ingo Molnar
2009-05-13 13:21       ` Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A0840DC.7080507@redhat.com \
    --to=mhiramat@redhat.com \
    --cc=ananth@in.ibm.com \
    --cc=jkenisto@us.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.