All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
	Arnaldo Carvalho de Melo <acme@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Christoph Hellwig <hch@infradead.org>,
	Andi Kleen <andi@firstfloor.org>, Oleg Nesterov <oleg@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	SystemTap <systemtap@sources.redhat.com>,
	Linux-mm <linux-mm@vger.kernel.org>,
	Jim Keniston <jkenisto@linux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [RFC] [PATCH 2.6.37-rc5-tip 7/20]  7: uprobes: store/restore original instruction.
Date: Tue, 25 Jan 2011 13:15:43 +0100	[thread overview]
Message-ID: <1295957743.28776.721.camel@laptop> (raw)
In-Reply-To: <20101216095837.23751.45271.sendpatchset@localhost6.localdomain6>

On Thu, 2010-12-16 at 15:28 +0530, Srikar Dronamraju wrote:
> On the first probe insertion, copy the original instruction and opcode.
> If multiple vmas map the same text area corresponding to an inode, we
> only need to copy the instruction just once.
> The copied instruction is further copied to a designated slot on probe
> hit.  Its also used at the time of probe removal to restore the original
> instruction.
> opcode is used to analyze the instruction and determine the fixups.
> Determining fixups at probe hit time would result in doing the same
> operation on every probe hit. Hence Instruction analysis using the
> opcode is done at probe insertion time.
> 
> Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> ---
>  arch/Kconfig     |    1 +
>  kernel/uprobes.c |   61 ++++++++++++++++++++++++++++++++++++++++++++++++++----
>  2 files changed, 57 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/Kconfig b/arch/Kconfig
> index 6e8f26e..bba8108 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -65,6 +65,7 @@ config UPROBES
>  	bool "User-space probes (EXPERIMENTAL)"
>  	depends on ARCH_SUPPORTS_UPROBES
>  	depends on MMU
> +	select MM_OWNER
>  	help
>  	  Uprobes enables kernel subsystems to establish probepoints
>  	  in user applications and execute handler functions when
> diff --git a/kernel/uprobes.c b/kernel/uprobes.c
> index 8a5da38..858ddb1 100644
> --- a/kernel/uprobes.c
> +++ b/kernel/uprobes.c
> @@ -448,21 +448,72 @@ static int del_consumer(struct uprobe *uprobe,
>  	return ret;
>  }
>  
> +static int copy_insn(struct task_struct *tsk, unsigned long vaddr,
> +						struct uprobe *uprobe)
> +{
> +	int len;
> +
> +	len = uprobes_read_vm(tsk, (void __user *)vaddr, uprobe->insn,
> +						MAX_UINSN_BYTES);
> +	if (len < uprobe_opcode_sz) {
> +		print_insert_fail(tsk, vaddr,
> +				"error reading original instruction");
> +		return -EINVAL;
> +	}
> +	memcpy(&uprobe->opcode, uprobe->insn, uprobe_opcode_sz);
> +	if (is_bkpt_insn(uprobe)) {
> +		print_insert_fail(tsk, vaddr,
> +				"breakpoint instruction already exists");
> +		return -EEXIST;
> +	}
> +	if (analyze_insn(tsk, uprobe)) {
> +		print_insert_fail(tsk, vaddr,
> +					"instruction type cannot be probed");
> +		return -EINVAL;
> +	}
> +	uprobe->copy = 1;
> +	return 0;
> +}

Since you actually have the inode, you could read it from the
page-cache. Also, why do you have the whole opcode/insn thing, that
looks like its data duplication.

>  static int install_uprobe(struct mm_struct *mm, struct uprobe *uprobe)
>  {
> -	int ret = 0;
> +	struct task_struct *tsk;
> +	int ret = -EINVAL;
>  
> -	/*TODO: install breakpoint */
> -	if (!ret)
> +	get_task_struct(mm->owner);
> +	tsk = mm->owner;
> +	if (!tsk)
> +		return ret;
> +
> +	if (!uprobe->copy) {
> +		ret = copy_insn(tsk, mm->uprobes_vaddr, uprobe);
> +		if (ret)
> +			goto put_return;
> +	}

So you do know that uprobes_vaddr can point to some random piece of
memory by now, right? :-)

> +	ret = set_bkpt(tsk, mm->uprobes_vaddr);
> +	if (ret < 0)
> +		print_insert_fail(tsk, mm->uprobes_vaddr,
> +					"failed to insert bkpt instruction");
> +	else
>  		atomic_inc(&mm->uprobes_count);
> +
> +put_return:
> +	put_task_struct(tsk);
>  	return ret;
>  }
>  
>  static int remove_uprobe(struct mm_struct *mm, struct uprobe *uprobe)
>  {
> -	int ret = 0;
> +	struct task_struct *tsk;
> +	int ret;
> +
> +	get_task_struct(mm->owner);
> +	tsk = mm->owner;
> +	if (!tsk)
> +		return -EINVAL;
>  
> -	/*TODO: remove breakpoint */
> +	ret = set_orig_insn(tsk, mm->uprobes_vaddr, true, uprobe);
>  	if (!ret)
>  		atomic_dec(&mm->uprobes_count);

Same here, there is no guarantee vaddr is even still mapped.



  reply	other threads:[~2011-01-25 12:15 UTC|newest]

Thread overview: 116+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-16  9:57 [RFC] [PATCH 2.6.37-rc5-tip 0/20] 0: Inode based uprobes Srikar Dronamraju
2010-12-16  9:57 ` [RFC] [PATCH 2.6.37-rc5-tip 1/20] 1: mm: Move replace_page() / write_protect_page() to mm/memory.c Srikar Dronamraju
2010-12-16  9:57 ` [RFC] [PATCH 2.6.37-rc5-tip 2/20] 2: X86 specific breakpoint definitions Srikar Dronamraju
2010-12-16  9:57 ` [RFC] [PATCH 2.6.37-rc5-tip 3/20] 3: uprobes: Breakground page replacement Srikar Dronamraju
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 4/20] 4: uprobes: Adding and remove a uprobe in a rb tree Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  8:37     ` Srikar Dronamraju
2011-01-26  8:37       ` Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  8:41     ` Srikar Dronamraju
2011-01-26 10:13       ` Peter Zijlstra
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  8:38     ` Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-26  8:45     ` Srikar Dronamraju
2011-01-26 10:14       ` Peter Zijlstra
2011-01-26 15:18         ` Srikar Dronamraju
2011-01-26 15:33           ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 5/20] 5: Uprobes: register/unregister probes Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  7:55     ` Srikar Dronamraju
2011-01-26  7:55       ` Srikar Dronamraju
2011-01-26 10:11       ` Peter Zijlstra
2011-01-26 10:11         ` Peter Zijlstra
2011-01-26 15:30         ` Srikar Dronamraju
2011-01-26 15:30           ` Srikar Dronamraju
2011-01-26 15:45           ` Peter Zijlstra
2011-01-26 15:45             ` Peter Zijlstra
2011-01-26 16:56             ` Srikar Dronamraju
2011-01-26 16:56               ` Srikar Dronamraju
2011-01-26 17:12               ` Peter Zijlstra
2011-01-26 17:12                 ` Peter Zijlstra
2011-01-27 10:01                 ` Srikar Dronamraju
2011-01-27 10:01                   ` Srikar Dronamraju
2011-01-27 10:23                   ` Peter Zijlstra
2011-01-27 10:23                     ` Peter Zijlstra
2011-01-27 10:25                     ` Srikar Dronamraju
2011-01-27 10:25                       ` Srikar Dronamraju
2011-01-27 10:41                       ` Peter Zijlstra
2011-01-27 10:41                         ` Peter Zijlstra
2011-01-27 10:29                   ` Peter Zijlstra
2011-01-27 10:29                     ` Peter Zijlstra
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  7:47     ` Srikar Dronamraju
2011-01-26  7:47       ` Srikar Dronamraju
2011-01-26 10:10       ` Peter Zijlstra
2011-01-26 10:10         ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 6/20] 6: x86: analyze instruction and determine fixups Srikar Dronamraju
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 7/20] 7: uprobes: store/restore original instruction Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra [this message]
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 8/20] 8: uprobes: mmap and fork hooks Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-26  9:03     ` Srikar Dronamraju
2011-01-26  9:03       ` Srikar Dronamraju
2011-01-26 10:20       ` Peter Zijlstra
2011-01-26 10:20         ` Peter Zijlstra
2011-01-26 14:59         ` Srikar Dronamraju
2011-01-26 14:59           ` Srikar Dronamraju
2011-01-26 15:16           ` Peter Zijlstra
2011-01-26 15:16             ` Peter Zijlstra
2011-01-26 16:30             ` Srikar Dronamraju
2011-01-26 16:30               ` Srikar Dronamraju
2011-01-25 12:15   ` Peter Zijlstra
2011-01-25 20:05     ` Steven Rostedt
2011-01-26  9:06       ` Srikar Dronamraju
2011-01-27 17:03         ` Steven Rostedt
2011-01-28  4:53           ` Srikar Dronamraju
2011-01-28 13:57             ` Steven Rostedt
2011-01-28 14:28               ` Steven Rostedt
2011-01-28 14:46                 ` Srikar Dronamraju
2011-01-28 15:02                   ` Steven Rostedt
2011-01-26 15:09     ` Srikar Dronamraju
2011-01-26 15:09       ` Srikar Dronamraju
2011-01-26 15:20       ` Peter Zijlstra
2011-01-26 15:20         ` Peter Zijlstra
2010-12-16  9:58 ` [RFC] [PATCH 2.6.37-rc5-tip 9/20] 9: x86: architecture specific task information Srikar Dronamraju
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 10/20] 10: uprobes: task specific information Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-25 18:38     ` Josh Stone
2011-01-25 18:55       ` Roland McGrath
2011-01-25 19:56       ` Peter Zijlstra
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 11/20] 11: uprobes: slot allocation for uprobes Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 12/20] 12: uprobes: get the breakpoint address Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 13/20] 13: x86: x86 specific probe handling Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-27  9:40     ` Srikar Dronamraju
2011-01-27 10:22       ` Peter Zijlstra
2011-01-27 19:11         ` Roland McGrath
2011-01-28  4:57           ` Srikar Dronamraju
2011-01-28  6:23             ` Roland McGrath
2011-01-28  8:36               ` Peter Zijlstra
2011-01-28 18:23                 ` Roland McGrath
2010-12-16  9:59 ` [RFC] [PATCH 2.6.37-rc5-tip 14/20] 14: uprobes: Handing int3 and singlestep exception Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-25 13:56   ` Peter Zijlstra
2011-01-26  8:52     ` Srikar Dronamraju
2011-01-26  8:52       ` Srikar Dronamraju
2011-01-26 10:17       ` Peter Zijlstra
2011-01-26 10:17         ` Peter Zijlstra
2011-01-26 15:14         ` Srikar Dronamraju
2011-01-26 15:14           ` Srikar Dronamraju
2011-01-26 15:29           ` Peter Zijlstra
2011-01-26 15:29             ` Peter Zijlstra
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 15/20] 15: x86: uprobes exception notifier for x86 Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 16/20] 16: uprobes: register a notifier for uprobes Srikar Dronamraju
2011-01-25 13:56   ` Peter Zijlstra
2011-01-27  6:50     ` Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 17/20] 17: uprobes: filter chain Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 18/20] 18: uprobes: commonly used filters Srikar Dronamraju
2010-12-17 19:32   ` Valdis.Kletnieks
2010-12-18  3:04     ` Srikar Dronamraju
2010-12-16 10:00 ` [RFC] [PATCH 2.6.37-rc5-tip 19/20] 19: tracing: Extract out common code for kprobes/uprobes traceevents Srikar Dronamraju
2010-12-16 10:01 ` [RFC] [PATCH 2.6.37-rc5-tip 20/20] 20: tracing: uprobes trace_event interface Srikar Dronamraju
2010-12-16 10:07 ` [RFC] [PATCH 2.6.37-rc5-tip 0/20] 0: Inode based uprobes 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=1295957743.28776.721.camel@laptop \
    --to=peterz@infradead.org \
    --cc=acme@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=ananth@in.ibm.com \
    --cc=andi@firstfloor.org \
    --cc=fweisbec@gmail.com \
    --cc=hch@infradead.org \
    --cc=jkenisto@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=systemtap@sources.redhat.com \
    --cc=torvalds@linux-foundation.org \
    /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.