This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 5/5 v2] uprobes: add global breakpoints
- From: Sebastian Andrzej Siewior <bigeasy at linutronix dot de>
- To: Oleg Nesterov <oleg at redhat dot com>
- Cc: Peter Zijlstra <a dot p dot zijlstra at chello dot nl>, linux-kernel at vger dot kernel dot org, x86 at kernel dot org, Arnaldo Carvalho de Melo <acme at ghostprotocols dot net>, Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>, Ananth N Mavinakaynahalli <ananth at in dot ibm dot com>, stan_shebs at mentor dot com, gdb-patches at sourceware dot org
- Date: Mon, 27 Aug 2012 20:56:49 +0200
- Subject: Re: [RFC 5/5 v2] uprobes: add global breakpoints
- References: <1344355952-2382-1-git-send-email-bigeasy@linutronix.de> <1344355952-2382-6-git-send-email-bigeasy@linutronix.de> <1344857686.31459.25.camel@twins> <20120821194200.GA32293@linutronix.de> <20120822134837.GA28878@redhat.com>
On 08/22/2012 03:48 PM, Oleg Nesterov wrote:
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.
At least for the ptrace part I would prefer to have your blessing
instead something that seems to work but is wrong.
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
That would help but would require a change in ptrace_attach() or
something in gdb/strace/…
One thing I just noticed: If I don't register a handler for SIGUSR1 and
send one to the application while it is in TASK_KILLABLE then the
signal gets delivered. If I register a signal handler for it than it
gets blocked and delivered once I resume the task.
Shouldn't it get blocked even if I don't register a handler for it?
- 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().
Okay, okay. It looks like it is better to stick with TASK_KILLABLE
instead of fixing the issues you pointed out.
--- 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.
ach, those signals make everything complicated. I though signals are
blocked until the single step is done but my test just showed my
something different. Okay, what now? A simple nested struct uprobe_task
and struct uprobe? Blocking signals isn't probably a good idea.
And this can race with uprobe_register() afaics.
Oleg.
Sebastian