This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v2 2.6.38-rc8-tip 5/20] 5: Uprobes: register/unregister probes.
- From: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- To: Peter Zijlstra <peterz at infradead dot org>
- Cc: Steven Rostedt <rostedt at goodmis dot org>, Thomas Gleixner <tglx at linutronix dot de>, Ingo Molnar <mingo at elte dot hu>, Linux-mm <linux-mm at kvack dot org>, Arnaldo Carvalho de Melo <acme at infradead dot org>, Linus Torvalds <torvalds at linux-foundation dot org>, Christoph Hellwig <hch at infradead dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, Ananth N Mavinakayanahalli <ananth at in dot ibm dot com>, Oleg Nesterov <oleg at redhat dot com>, LKML <linux-kernel at vger dot kernel dot org>, SystemTap <systemtap at sources dot redhat dot com>, Jim Keniston <jkenisto at linux dot vnet dot ibm dot com>, Roland McGrath <roland at hack dot frob dot com>, Andi Kleen <andi at firstfloor dot org>, Andrew Morton <akpm at linux-foundation dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>
- Date: Sat, 19 Mar 2011 00:23:14 +0530
- Subject: Re: [PATCH v2 2.6.38-rc8-tip 5/20] 5: Uprobes: register/unregister probes.
- References: <20110314133403.27435.7901.sendpatchset@localhost6.localdomain6> <20110314133454.27435.81020.sendpatchset@localhost6.localdomain6> <alpine.LFD.2.00.1103151439400.2787@localhost6.localdomain6> <20110315171536.GA24254@linux.vnet.ibm.com> <1300211262.9910.295.camel@gandalf.stny.rr.com> <1300211411.2203.290.camel@twins> <20110315180423.GA10429@linux.vnet.ibm.com> <1300212949.2203.324.camel@twins>
- Reply-to: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
> >
> > One of the install_uprobe could be failing because the process was
> > almost exiting, something like there was no mm->owner. Also lets
> > assume that the first few install_uprobes go thro and the last
> > install_uprobe fails. There could be breakpoint hits corresponding to
> > the already installed uprobes that get displayed. i.e all
> > breakpoint hits from the first install_uprobe to the time we detect a
> > failed a install_uprobe and revert all inserted breakpoints will be
> > shown as being captured.
>
> I think you can gracefully deal with the exit case and simply ignore
> that one. But you cannot let arbitrary installs fail and still report
> success, that gives very weak and nearly useless semantics.
If there are more than one instance of a process running and if one
instance of a process has a probe thro ptrace, install_uprobe would fail
for that process with -EEXIST since we dont want to probe locations that
have breakpoints already. Should we then act similar to the exit case,
do we also deal gracefully?
--
Thanks and Regards
Srikar