All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Anton Arapov <anton@redhat.com>
Cc: Oleg Nesterov <oleg@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Josh Stone <jistone@redhat.com>, Frank Eigler <fche@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@elte.hu>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	adrian.m.negreanu@intel.com, Torsten.Polle@gmx.de
Subject: Re: [PATCH v1 6/9] uretprobes: Return probe exit, invoke handlers
Date: Sun, 7 Apr 2013 16:23:08 +0530	[thread overview]
Message-ID: <20130407105308.GA2899@linux.vnet.ibm.com> (raw)
In-Reply-To: <1365004839-21982-7-git-send-email-anton@redhat.com>

* Anton Arapov <anton@redhat.com> [2013-04-03 18:00:36]:

> Uretprobe handlers are invoked when the trampoline is hit, on completion the
> trampoline is replaced with the saved return address and the uretprobe instance
> deleted.
> 
> v1 changes:
> * pass bp_vaddr to ret_handler()
> * simplify handle_uretprobe()
> 
> RFCv6 changes:
> * rework handle_uretprobe()
> 
> RFCv5 changes:
> * switch to simply linked list ->return_uprobes
> * rework handle_uretprobe()
> 
> RFCv4 changes:
> * check, whether utask is not NULL in handle_uretprobe()
> * get rid of area->rp_trampoline_vaddr
> * minor handle_uretprobe() fixups
> 
> RFCv3 changes:
> * protected uprobe with refcounter. See put_uprobe() in handle_uretprobe()
>   that reflects increment in prepare_uretprobe()
> 
> RFCv2 changes:
> * get rid of ->return_consumers member from struct uprobe, introduce
>   ret_handler() in consumer instead
> 
> Signed-off-by: Anton Arapov <anton@redhat.com>
> ---
>  kernel/events/uprobes.c | 60 ++++++++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 59 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 08ecfff..d129c1d 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1609,6 +1609,57 @@ static void handler_chain(struct uprobe *uprobe, struct pt_regs *regs)
>  	up_read(&uprobe->register_rwsem);
>  }
> 
> +static void
> +handler_uretprobe_chain(struct return_instance *ri, struct pt_regs *regs)

> +{
> +	struct uprobe *uprobe = ri->uprobe;
> +	struct uprobe_consumer *uc;
> +
> +	down_read(&uprobe->register_rwsem);
> +	for (uc = uprobe->consumers; uc; uc = uc->next) {
> +		if (uc->ret_handler)
> +			uc->ret_handler(uc, ri->func, regs);
> +	}
> +	up_read(&uprobe->register_rwsem);
> +}
> +
> +static bool handler_uretprobe(struct pt_regs *regs)

Nit: can this be renamed to handle_trampoline

> +{
> +	struct uprobe_task *utask;
> +	struct return_instance *ri, *tmp;
> +	bool chained;
> +
> +	utask = current->utask;
> +	if (!utask)
> +		return false;
> +
> +	ri = utask->return_instances;
> +	if (!ri)
> +		return false;
> +
> +	instruction_pointer_set(regs, ri->orig_ret_vaddr);

Should we a check here before using top most ri.
What if the application had done a longjmp and the trampoline he hit
corresponds to something thats below in the stack?

Not sure if this what you meant by leaking return instances in your next
patch.


> +
> +	for (;;) {
> +		handler_uretprobe_chain(ri, regs);
> +
> +		chained = ri->chained;
> +		put_uprobe(ri->uprobe);
> +
> +		tmp = ri;
> +		ri = ri->next;
> +		kfree(tmp);
> +
> +		if (!chained)
> +			break;
> +
> +		BUG_ON(!ri);
> +	}
> +
> +	utask->return_instances = ri;
> +
> +	return true;
> +}
> +
>  /*
>   * Run handler and ask thread to singlestep.
>   * Ensure all non-fatal signals cannot interrupt thread while it singlesteps.
> @@ -1620,8 +1671,15 @@ static void handle_swbp(struct pt_regs *regs)
>  	int uninitialized_var(is_swbp);
> 
>  	bp_vaddr = uprobe_get_swbp_addr(regs);
> -	uprobe = find_active_uprobe(bp_vaddr, &is_swbp);
> +	if (bp_vaddr == get_trampoline_vaddr()) {
> +		if (handler_uretprobe(regs))
> +			return;
> 
> +		pr_warn("uprobe: unable to handle uretprobe pid/tgid=%d/%d\n",
> +						current->pid, current->tgid);
> +	}
> +
> +	uprobe = find_active_uprobe(bp_vaddr, &is_swbp);
>  	if (!uprobe) {
>  		if (is_swbp > 0) {
>  			/* No matching uprobe; signal SIGTRAP. */
> -- 
> 1.8.1.4
> 


  reply	other threads:[~2013-04-07 10:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 16:00 [PATCH v1 0/9] uretprobes: Return uprobes implementation Anton Arapov
2013-04-03 16:00 ` [PATCH v1 1/9] uretprobes: Introduce uprobe_consumer->ret_handler() Anton Arapov
2013-04-07 11:37   ` Srikar Dronamraju
2013-04-03 16:00 ` [PATCH v1 2/9] uretprobes: Reserve the first slot in xol_vma for trampoline Anton Arapov
2013-04-07 11:44   ` Srikar Dronamraju
2013-04-09 14:16     ` Oleg Nesterov
2013-04-03 16:00 ` [PATCH v1 3/9] uretprobes/x86: Hijack return address Anton Arapov
2013-04-07 11:48   ` Srikar Dronamraju
2013-04-03 16:00 ` [PATCH v1 4/9] uretprobes/ppc: " Anton Arapov
2013-04-04  3:31   ` Ananth N Mavinakayanahalli
2013-04-07 11:51   ` Srikar Dronamraju
2013-04-03 16:00 ` [PATCH v1 5/9] uretprobes: Return probe entry, prepare_uretprobe() Anton Arapov
2013-04-07 11:52   ` Srikar Dronamraju
2013-04-03 16:00 ` [PATCH v1 6/9] uretprobes: Return probe exit, invoke handlers Anton Arapov
2013-04-07 10:53   ` Srikar Dronamraju [this message]
2013-04-09 14:05     ` Oleg Nesterov
2013-04-09 20:13       ` Oleg Nesterov
2013-04-13 10:01         ` Srikar Dronamraju
2013-04-13 16:10           ` Oleg Nesterov
2013-04-03 16:00 ` [PATCH v1 7/9] uretprobes: Limit the depth of return probe nestedness Anton Arapov
2013-04-07 11:55   ` Srikar Dronamraju
2013-04-03 16:00 ` [PATCH v1 8/9] uretprobes: Remove -ENOSYS as return probes implemented Anton Arapov
2013-04-07 11:56   ` Srikar Dronamraju
2013-04-03 16:00 ` [PATCH v1 9/9] uretprobes: Documentation update Anton Arapov
2013-04-07 11:57   ` Srikar Dronamraju
2013-04-03 17:45 ` [PATCH v1 0/9] uretprobes: Return uprobes implementation Oleg Nesterov
2013-04-04  3:32   ` Ananth N Mavinakayanahalli

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=20130407105308.GA2899@linux.vnet.ibm.com \
    --to=srikar@linux.vnet.ibm.com \
    --cc=Torsten.Polle@gmx.de \
    --cc=adrian.m.negreanu@intel.com \
    --cc=ananth@in.ibm.com \
    --cc=anton@redhat.com \
    --cc=fche@redhat.com \
    --cc=jistone@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.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.