From: Oleg Nesterov <oleg@redhat.com>
To: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
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 v2] uprobes: add global breakpoints
Date: Wed, 22 Aug 2012 15:48:37 +0200 [thread overview]
Message-ID: <20120822134837.GA28878@redhat.com> (raw)
In-Reply-To: <20120821194200.GA32293@linutronix.de>
On 08/21, Sebastian Andrzej Siewior wrote:
>
> 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.
Sorry Sebastian, I didn't even try to read the patch ;) Fortunately I am
not maintainer, I can only reapeat that you do not need to convince me.
> Oleg: The change in ptrace_attach() is still as it was. I tried to
> address Peter concern here.
> Now what options do I have here:
> - not putting the task in TASK_TRACED but simply halt. This would work
> without a change to ptrace_attach() but the task continues on any
> signal. So a signal friendly task would continue and not notice a
> thing.
TASK_KILLABLE
> - putting the TASK_TRACED
This is simply wrong, in many ways.
For example, what if the probed task is already ptraced? Or debugger
attaches via PTRACE_SEIZE? How can debugger know it is stopped?
uprobe_wait_traced() goes to sleep in TASK_TRACED without notification.
And it does not set ->exit_code, this means do_wait() won't work.
And note ptrace_stop()->recalc_sigpending_tsk().
> @@ -76,6 +79,7 @@ struct uprobe_task {
>
> unsigned long xol_vaddr;
> unsigned long vaddr;
> + int skip_handler;
I am trying to guess what this skip_handler does...
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1513,7 +1513,16 @@ static void handle_swbp(struct pt_regs *regs)
> goto cleanup_ret;
> }
> utask->active_uprobe = uprobe;
> - handler_chain(uprobe, regs);
> + if (utask->skip_handler)
> + utask->skip_handler = 0;
> + else
> + handler_chain(uprobe, regs);
> +
> + if (utask->state == UTASK_TRACE_WOKEUP_TRACED) {
> + send_sig(SIGTRAP, current, 0);
> + utask->skip_handler = 1;
> + goto cleanup_ret;
> + }
> if (uprobe->flags & UPROBE_SKIP_SSTEP && can_skip_sstep(uprobe, regs))
> goto cleanup_ret;
>
> @@ -1528,7 +1537,7 @@ cleanup_ret:
> utask->active_uprobe = NULL;
> utask->state = UTASK_RUNNING;
> }
> - if (!(uprobe->flags & UPROBE_SKIP_SSTEP))
> + if (!(uprobe->flags & UPROBE_SKIP_SSTEP) || utask->skip_handler)
Am I understand correctly?
If it was woken by PTRACE_ATTACH we set utask->skip_handler = 1 and
re-execute the instruction (yes, SIGTRAP, but this doesn't matter).
When the task hits this bp again we skip handler_chain() because it
was already reported.
Yes? If yes, I don't think this can work. Suppose that the task
dequeues a signal before it returns to the usermode to re-execute
and enters the signal handler which can hit another uprobe.
And this can race with uprobe_register() afaics.
Oleg.
next prev parent reply other threads:[~2012-08-22 13:53 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
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 [this message]
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=20120822134837.GA28878@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).