Messages in this thread | | | Date | Thu, 30 Aug 2012 22:42:09 +0200 | From | Sebastian Andrzej Siewior <> | Subject | Re: [RFC 5/5 v2] uprobes: add global breakpoints |
| |
On 08/29/2012 05:49 PM, Oleg Nesterov wrote: >> That would help but would require a change in ptrace_attach() or >> something in gdb/strace/… > > Well, I still think you should not touch ptrace_attach() at all.
Okay.
>> 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. > > Not really delivered... OK, it can be delivered (dequeued) before > the task sees SIGKILL, but this can be changed. > > In short: in this case the task is correctly SIGKILL'ed. See sig_fatal() > in complete_signal(). > >> If I register a signal handler for it than it >> gets blocked and delivered once I resume the task. > > Sure, if you have a handler, the signal is not fatal. > >> Shouldn't it get blocked even if I don't register a handler for it? > > No.
Now, that I read again it looks like a brain fart on my side.
>> ach, those signals make everything complicated. I though signals are >> blocked until the single step is done > > Yes, see uprobe_deny_signal(). > >> but my test just showed my >> something different. > > I guess you missed the UTASK_SSTEP_TRAPPED logic. > > But this doesn't matter. Surely we must not "block" signals _after_ > the single step is done, and this is the problem. > >> Okay, what now? > > IMHO: don't do this ;) > >> Blocking signals isn't probably a good idea. > > This is bad and wrong idea, I think. > > And, once again. Whatever you do, you can race with uprobe_register(). > I mean, you must never expect that the task will hit the same uprobe > again, even if you are going to re-execute the same insn.
After witting why I think you are wrong I understood what you meant :) So let me try to get this right…
> > Oleg.
Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |