All of lore.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>,
	Christoph Hellwig <hch@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Roland McGrath <roland@hack.frob.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Anton Arapov <anton@redhat.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH v10 3.3-rc2 1/9] uprobes: Install and remove breakpoints.
Date: Thu, 09 Feb 2012 17:17:57 +0900	[thread overview]
Message-ID: <4F338135.5090407@hitachi.com> (raw)
In-Reply-To: <20120209063745.GB16600@linux.vnet.ibm.com>

(2012/02/09 15:37), Srikar Dronamraju wrote:
>>
>> No, that is a meaningless operation.
>> As I originally said,
>>
>>> insn_get_length(insn);
>>> if (insn->rex_prefix.nbytes) {
>>> 	cursor = uprobe->insn + insn_offset_rex_prefix(insn);
>>> 	*cursor &= 0xfe;	/* Clearing REX.B bit */
>>> }
>>
> 
> I am confused by why we need to call insn_get_length(insn) before
> checking insn->rex_prefix.nbytes? Is it needed.

Ah, certainly, no, if the insn is already decoded.

> Denys and Masami, can you please confirm if below is fine.
> 
> 
> #ifdef CONFIG_X86_64
> /*
>  * If uprobe->insn doesn't use rip-relative addressing, return
>  * immediately.  Otherwise, rewrite the instruction so that it accesses
>  * its memory operand indirectly through a scratch register.  Set
>  * uprobe->arch_info.fixups and uprobe->arch_info.rip_rela_target_address
>  * accordingly.  (The contents of the scratch register will be saved
>  * before we single-step the modified instruction, and restored
>  * afterward.)
>  *
>  * We do this because a rip-relative instruction can access only a
>  * relatively small area (+/- 2 GB from the instruction), and the XOL
>  * area typically lies beyond that area.  At least for instructions
>  * that store to memory, we can't execute the original instruction
>  * and "fix things up" later, because the misdirected store could be
>  * disastrous.
>  *
>  * Some useful facts about rip-relative instructions:
>  * - There's always a modrm byte.
>  * - There's never a SIB byte.
>  * - The displacement is always 4 bytes.
>  */
> static void handle_riprel_insn(struct mm_struct *mm, struct uprobe *uprobe,
> 							struct insn *insn)
> {

> 	u8 *cursor;
> 	u8 reg;
> 
> 	if (mm->context.ia32_compat)
> 		return;
> 
> 	uprobe->arch_info.rip_rela_target_address = 0x0;
> 	if (!insn_rip_relative(insn))
> 		return;

Here, I think it is better to add a comment that
insn_rip_relative() decodes until modrm. :)

> 
> 	/* Clear REX.b bit (extension of MODRM.rm field):
> 	 * we want to encode rax/rcx, not r8/r9.
> 	 */
> 	if (insn->rex_prefix.nbytes) {
> 		cursor = uprobe->insn + insn_offset_rex_prefix(insn);
> 		*cursor &= 0xfe;
> 	}
> 
> 	/*
> 	 * Point cursor at the modrm byte.  The next 4 bytes are the
> 	 * displacement.  Beyond the displacement, for some instructions,
> 	 * is the immediate operand.
> 	 */
> 	cursor = uprobe->insn + insn_offset_modrm(insn);
> 	insn_get_length(insn);
> 
> 	/*
> 	 * Convert from rip-relative addressing to indirect addressing
> 	 * via a scratch register.  Change the r/m field from 0x5 (%rip)
> 	 * to 0x0 (%rax) or 0x1 (%rcx), and squeeze out the offset field.
> 	 */
> 	reg = MODRM_REG(insn);
> 	if (reg == 0) {
> 		/*
> 		 * The register operand (if any) is either the A register
> 		 * (%rax, %eax, etc.) or (if the 0x4 bit is set in the
> 		 * REX prefix) %r8.  In any case, we know the C register
> 		 * is NOT the register operand, so we use %rcx (register
> 		 * #1) for the scratch register.
> 		 */
> 		uprobe->arch_info.fixups = UPROBES_FIX_RIP_CX;
> 		/* Change modrm from 00 000 101 to 00 000 001. */
> 		*cursor = 0x1;
> 	} else {
> 		/* Use %rax (register #0) for the scratch register. */
> 		uprobe->arch_info.fixups = UPROBES_FIX_RIP_AX;
> 		/* Change modrm from 00 xxx 101 to 00 xxx 000 */
> 		*cursor = (reg << 3);
> 	}
> 
> 	/* Target address = address of next instruction + (signed) offset */
> 	uprobe->arch_info.rip_rela_target_address = (long)insn->length
> 					+ insn->displacement.value;
> 	/* Displacement field is gone; slide immediate field (if any) over. */
> 	if (insn->immediate.nbytes) {
> 		cursor++;
> 		memmove(cursor, cursor + insn->displacement.nbytes,
> 						insn->immediate.nbytes);
> 	}
> 	return;
> }

Confirmed, this looks good to me ;)

Thanks!


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Oleg Nesterov <oleg@redhat.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux-mm <linux-mm@kvack.org>, Andi Kleen <andi@firstfloor.org>,
	Christoph Hellwig <hch@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Roland McGrath <roland@hack.frob.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Anton Arapov <anton@redhat.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	yrl.pp-manager.tt@hitachi.com
Subject: Re: [PATCH v10 3.3-rc2 1/9] uprobes: Install and remove breakpoints.
Date: Thu, 09 Feb 2012 17:17:57 +0900	[thread overview]
Message-ID: <4F338135.5090407@hitachi.com> (raw)
In-Reply-To: <20120209063745.GB16600@linux.vnet.ibm.com>

(2012/02/09 15:37), Srikar Dronamraju wrote:
>>
>> No, that is a meaningless operation.
>> As I originally said,
>>
>>> insn_get_length(insn);
>>> if (insn->rex_prefix.nbytes) {
>>> 	cursor = uprobe->insn + insn_offset_rex_prefix(insn);
>>> 	*cursor &= 0xfe;	/* Clearing REX.B bit */
>>> }
>>
> 
> I am confused by why we need to call insn_get_length(insn) before
> checking insn->rex_prefix.nbytes? Is it needed.

Ah, certainly, no, if the insn is already decoded.

> Denys and Masami, can you please confirm if below is fine.
> 
> 
> #ifdef CONFIG_X86_64
> /*
>  * If uprobe->insn doesn't use rip-relative addressing, return
>  * immediately.  Otherwise, rewrite the instruction so that it accesses
>  * its memory operand indirectly through a scratch register.  Set
>  * uprobe->arch_info.fixups and uprobe->arch_info.rip_rela_target_address
>  * accordingly.  (The contents of the scratch register will be saved
>  * before we single-step the modified instruction, and restored
>  * afterward.)
>  *
>  * We do this because a rip-relative instruction can access only a
>  * relatively small area (+/- 2 GB from the instruction), and the XOL
>  * area typically lies beyond that area.  At least for instructions
>  * that store to memory, we can't execute the original instruction
>  * and "fix things up" later, because the misdirected store could be
>  * disastrous.
>  *
>  * Some useful facts about rip-relative instructions:
>  * - There's always a modrm byte.
>  * - There's never a SIB byte.
>  * - The displacement is always 4 bytes.
>  */
> static void handle_riprel_insn(struct mm_struct *mm, struct uprobe *uprobe,
> 							struct insn *insn)
> {

> 	u8 *cursor;
> 	u8 reg;
> 
> 	if (mm->context.ia32_compat)
> 		return;
> 
> 	uprobe->arch_info.rip_rela_target_address = 0x0;
> 	if (!insn_rip_relative(insn))
> 		return;

Here, I think it is better to add a comment that
insn_rip_relative() decodes until modrm. :)

> 
> 	/* Clear REX.b bit (extension of MODRM.rm field):
> 	 * we want to encode rax/rcx, not r8/r9.
> 	 */
> 	if (insn->rex_prefix.nbytes) {
> 		cursor = uprobe->insn + insn_offset_rex_prefix(insn);
> 		*cursor &= 0xfe;
> 	}
> 
> 	/*
> 	 * Point cursor at the modrm byte.  The next 4 bytes are the
> 	 * displacement.  Beyond the displacement, for some instructions,
> 	 * is the immediate operand.
> 	 */
> 	cursor = uprobe->insn + insn_offset_modrm(insn);
> 	insn_get_length(insn);
> 
> 	/*
> 	 * Convert from rip-relative addressing to indirect addressing
> 	 * via a scratch register.  Change the r/m field from 0x5 (%rip)
> 	 * to 0x0 (%rax) or 0x1 (%rcx), and squeeze out the offset field.
> 	 */
> 	reg = MODRM_REG(insn);
> 	if (reg == 0) {
> 		/*
> 		 * The register operand (if any) is either the A register
> 		 * (%rax, %eax, etc.) or (if the 0x4 bit is set in the
> 		 * REX prefix) %r8.  In any case, we know the C register
> 		 * is NOT the register operand, so we use %rcx (register
> 		 * #1) for the scratch register.
> 		 */
> 		uprobe->arch_info.fixups = UPROBES_FIX_RIP_CX;
> 		/* Change modrm from 00 000 101 to 00 000 001. */
> 		*cursor = 0x1;
> 	} else {
> 		/* Use %rax (register #0) for the scratch register. */
> 		uprobe->arch_info.fixups = UPROBES_FIX_RIP_AX;
> 		/* Change modrm from 00 xxx 101 to 00 xxx 000 */
> 		*cursor = (reg << 3);
> 	}
> 
> 	/* Target address = address of next instruction + (signed) offset */
> 	uprobe->arch_info.rip_rela_target_address = (long)insn->length
> 					+ insn->displacement.value;
> 	/* Displacement field is gone; slide immediate field (if any) over. */
> 	if (insn->immediate.nbytes) {
> 		cursor++;
> 		memmove(cursor, cursor + insn->displacement.nbytes,
> 						insn->immediate.nbytes);
> 	}
> 	return;
> }

Confirmed, this looks good to me ;)

Thanks!


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

  parent reply	other threads:[~2012-02-09  8:18 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-02 14:18 [PATCH v10 3.3-rc2 0/9] Uprobes patchset with perf probe support Srikar Dronamraju
2012-02-02 14:18 ` Srikar Dronamraju
2012-02-02 14:18 ` [PATCH v10 3.3-rc2 1/9] uprobes: Install and remove breakpoints Srikar Dronamraju
2012-02-02 14:18   ` Srikar Dronamraju
2012-02-03 12:01   ` Masami Hiramatsu
2012-02-03 12:01     ` Masami Hiramatsu
2012-02-07 17:17   ` Srikar Dronamraju
2012-02-07 17:17     ` Srikar Dronamraju
2012-02-08  9:40     ` Denys Vlasenko
2012-02-08  9:40       ` Denys Vlasenko
2012-02-08  9:40       ` Srikar Dronamraju
2012-02-08  9:40         ` Srikar Dronamraju
2012-02-09  1:27       ` Masami Hiramatsu
2012-02-09  1:27         ` Masami Hiramatsu
2012-02-09  6:37         ` Srikar Dronamraju
2012-02-09  6:37           ` Srikar Dronamraju
2012-02-09  7:53           ` Ingo Molnar
2012-02-09  7:53             ` Ingo Molnar
2012-02-09  8:14             ` Srikar Dronamraju
2012-02-09  8:14               ` Srikar Dronamraju
2012-02-09  8:17           ` Masami Hiramatsu [this message]
2012-02-09  8:17             ` Masami Hiramatsu
2012-02-09  8:27             ` Srikar Dronamraju
2012-02-09  8:27               ` Srikar Dronamraju
2012-02-08 14:08     ` Srikar Dronamraju
2012-02-08 14:08       ` Srikar Dronamraju
2012-02-09  9:26       ` [PATCH v10 take 3 " Srikar Dronamraju
2012-02-09  9:26         ` Srikar Dronamraju
2012-02-17  9:58         ` [tip:perf/uprobes] uprobes, mm, x86: Add the ability to install and remove uprobes breakpoints tip-bot for Srikar Dronamraju
2012-02-17  9:58           ` tip-bot for Srikar Dronamraju
2012-05-21 21:37           ` Andrew Morton
2012-05-21 21:37             ` Andrew Morton
2012-05-21 22:00             ` Linus Torvalds
2012-05-21 22:00               ` Linus Torvalds
2012-05-21 22:13               ` Andrew Morton
2012-05-21 22:13                 ` Andrew Morton
2012-05-22  1:16                 ` Stephen Rothwell
2012-05-22  2:27                   ` Andrew Morton
2012-05-22  2:27                     ` Andrew Morton
2012-05-22  6:50                     ` Stephen Rothwell
2012-05-23  0:37                 ` Stephen Rothwell
2012-05-22  1:10               ` Stephen Rothwell
2012-05-22  6:01               ` Srikar Dronamraju
2012-05-22  6:01                 ` Srikar Dronamraju
2012-05-22  8:05             ` Srikar Dronamraju
2012-05-22  8:05               ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 2/9] uprobes: handle breakpoint and signal step exception Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 3/9] uprobes: slot allocation Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 4/9] uprobes: counter to optimize probe hits Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:19 ` [PATCH v10 3.3-rc2 5/9] tracing: modify is_delete, is_return from ints to bool Srikar Dronamraju
2012-02-02 14:19   ` Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 6/9] tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 7/9] tracing: uprobes trace_event interface Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 8/9] perf: rename target_module to target Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju
2012-02-07 19:33   ` [tip:perf/core] perf probe: Rename " tip-bot for Srikar Dronamraju
2012-02-07 19:33     ` tip-bot for Srikar Dronamraju
2012-02-02 14:20 ` [PATCH v10 3.3-rc2 9/9] perf: perf interface for uprobes Srikar Dronamraju
2012-02-02 14:20   ` Srikar Dronamraju

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=4F338135.5090407@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=anton@redhat.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=roland@hack.frob.com \
    --cc=rostedt@goodmis.org \
    --cc=sfr@canb.auug.org.au \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=vda.linux@googlemail.com \
    --cc=yrl.pp-manager.tt@hitachi.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.