From: Oleg Nesterov <oleg@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Roland McGrath <roland@redhat.com>,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
Ananth N Mavinakaynahalli <ananth@in.ibm.com>,
stan_shebs@mentor.com, gdb-patches@sourceware.org
Subject: Re: [RFC 5/5] uprobes: add global breakpoints
Date: Wed, 8 Aug 2012 15:14:57 +0200 [thread overview]
Message-ID: <20120808131457.GA5309@redhat.com> (raw)
In-Reply-To: <1344355952-2382-6-git-send-email-bigeasy@linutronix.de>
On 08/07, Sebastian Andrzej Siewior wrote:
>
> By setting an uprobe tracepoint, one learns whenever a certain point
> within a program is reached / passed. This is recorded and the
> application continues.
> This patch adds the ability to hold the program once this point has been
> passed and the user may attach to the program via ptrace.
> First, setup a global breakpoint which is very similar to a uprobe trace
> point:
>
> |echo 'g /home/bigeasy/sample:0x0000044d %ip %ax' > uprobe_events
>
> This is exactly what uprobe does except that it starts with the letter
> 'g' instead of 'p'.
>
> Step two is to enable it:
> |echo 1 > events/uprobes/enable
>
> Lets assume you execute ./sample and the breakpoint is hit. In ps you will
> see:
> |1938 pts/1 t+ 0:00 ./sample
>
> Now you can attach gdb via 'gdb -p 1938'. The gdb can now interact with
> the tracee and inspect its registers, its stack, single step, let it
> run…
> In case the process is not of great interest, the user may continue
> without gdb by writting its pid into the uprobe_gp_wakeup file
>
> |echo 1938 > uprobe_gp_wakeup
>
> What I miss right now is an interface to tell the user/gdb that there is a
> program that hit a global breakpoint and is waiting for further instructions.
> A "tail -f trace" does not work and may contain also a lot of other
> informations. I've been thinking about a poll()able file which returns pids of
> tasks which are put on hold. Other suggestions?
Honestly, I am not sure this is that useful...
OK, I'll try to read this patch later. But, at first glance,
> +int uprobe_wakeup_task(struct task_struct *t, int traced)
> +{
> + struct uprobe_task *utask;
> +
> + utask = t->utask;
> + if (!utask)
> + return -EINVAL;
> + if (utask->state != UTASK_TRACE_SLEEP)
> + return -EINVAL;
> +
> + utask->state = traced ?
> + UTASK_TRACE_WOKEUP_TRACED : UTASK_TRACE_WOKEUP_NORMAL;
> + wake_up_state(t, __TASK_TRACED);
> + return 0;
> +}
This can obviously race with uprobe_wait_traced(), see below
> @@ -286,8 +286,10 @@ static int ptrace_attach(struct task_struct *task, long request,
> __ptrace_link(task, current);
>
> /* SEIZE doesn't trap tracee on attach */
> - if (!seize)
> + if (!seize) {
> send_sig_info(SIGSTOP, SEND_SIG_FORCED, task);
> + uprobe_wakeup_task(task, 1);
> + }
Can't understand why uprobe_wakeup_task() depends on !PTRACE_SEIZE
> +static void uprobe_wait_traced(struct trace_uprobe *tu)
> +{
> + struct uprobe_task *utask;
> +
> + utask = current->utask;
> + utask->state = UTASK_TRACE_SLEEP;
WINDOW
> +
> + set_current_state(TASK_TRACED);
> + schedule();
> +}
Suppose that uprobe_wakeup_task() is called in the WINDOW above.
OTOH, uprobe_wakeup_task() can race with itself if it is called
twice at the same time, say from uprobes_gp_wakeup_write() and
ptrace_attach().
Oleg.
next prev parent reply other threads:[~2012-08-08 13:19 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-07 16:12 uprobe: single step over uprobe & global breakpoints Sebastian Andrzej Siewior
2012-08-07 16:12 ` [PATCH 1/5] uprobes: Use a helper instead of ptrace's single step enable Sebastian Andrzej Siewior
2012-08-07 16:12 ` [PATCH 2/5] x86/uprobes: implement x86 specific arch_uprobe_*_step Sebastian Andrzej Siewior
2012-08-08 12:57 ` Oleg Nesterov
2012-08-08 13:17 ` Sebastian Andrzej Siewior
2012-08-08 14:53 ` Oleg Nesterov
2012-08-08 15:02 ` Sebastian Andrzej Siewior
2012-08-09 4:43 ` Ananth N Mavinakayanahalli
2012-08-09 17:09 ` [PATCH v2 " Sebastian Andrzej Siewior
2012-08-13 13:24 ` Oleg Nesterov
2012-08-14 8:28 ` Sebastian Andrzej Siewior
2012-08-14 14:27 ` Oleg Nesterov
2012-08-20 10:47 ` [PATCH v3] " Sebastian Andrzej Siewior
2012-08-22 14:03 ` Oleg Nesterov
2012-08-22 14:11 ` Sebastian Andrzej Siewior
2012-08-22 15:59 ` Oleg Nesterov
2012-08-29 17:37 ` Oleg Nesterov
2012-08-30 8:47 ` Ananth N Mavinakayanahalli
2012-08-30 11:18 ` [PATCH] x86/uprobes: don't disable single stepping if it was already on Sebastian Andrzej Siewior
2012-08-30 14:37 ` [PATCH v3] x86/uprobes: implement x86 specific arch_uprobe_*_step Oleg Nesterov
2012-08-30 15:03 ` Ananth N Mavinakayanahalli
2012-08-30 15:11 ` Oleg Nesterov
2012-08-07 16:12 ` [PATCH 3/5] uprobes: remove check for uprobe variable in handle_swbp() Sebastian Andrzej Siewior
2012-08-08 9:10 ` Suzuki K. Poulose
2012-08-08 9:35 ` Sebastian Andrzej Siewior
2012-08-10 5:23 ` Suzuki K. Poulose
2012-08-08 12:58 ` Oleg Nesterov
2012-08-07 16:12 ` [PATCH 4/5] uprobes: probe definiton can only start with 'p' and '-' Sebastian Andrzej Siewior
2012-08-07 16:12 ` [RFC 5/5] uprobes: add global breakpoints Sebastian Andrzej Siewior
2012-08-08 13:14 ` Oleg Nesterov [this message]
2012-08-09 17:18 ` Sebastian Andrzej Siewior
2012-08-13 13:16 ` Oleg Nesterov
2012-08-14 11:43 ` Sebastian Andrzej Siewior
2012-08-13 11:34 ` Peter Zijlstra
2012-08-20 15:26 ` Sebastian Andrzej Siewior
2012-08-21 19:42 ` [RFC 5/5 v2] " Sebastian Andrzej Siewior
2012-08-22 13:48 ` Oleg Nesterov
2012-08-27 18:56 ` Sebastian Andrzej Siewior
2012-08-29 15:49 ` Oleg Nesterov
2012-08-30 20:42 ` Sebastian Andrzej Siewior
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=20120808131457.GA5309@redhat.com \
--to=oleg@redhat.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=ananth@in.ibm.com \
--cc=bigeasy@linutronix.de \
--cc=gdb-patches@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=srikar@linux.vnet.ibm.com \
--cc=stan_shebs@mentor.com \
--cc=x86@kernel.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.