Messages in this thread | | | Date | Sat, 26 Mar 2011 19:25:54 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCHSET] ptrace,signal: Improve ptrace and job control interaction |
| |
Hello Tejun,
On 03/25, Tejun Heo wrote: > > Hello, Oleg. > > On Wed, Mar 23, 2011 at 07:38:37PM +0100, Oleg Nesterov wrote: > > But of course we need more changes. In particular, there is still the > > small problem with the CLD_CONTINUED notification. > > > > __ptrace_unlink() does signal_wake_up() if it adds SIGNAL_STOP_STOPPED. > > This is correct, but it should also add TIF_SIGPENDING if > > (signal->flags & SIGNAL_CLD_MASK) != 0. > > > > Otherwise, if the stopped tracee was PTRACE_CONT'ed and then SIGCONT > > ends the group-stop, the real_parent won't be notified after detach. > > Heh, that's an interesting one. I don't think it has much to do with > __ptrace_unlink() tho. Isn't the proper solution using something akin > to signal_wake_up() in SIGCONT generation path in prepare_signal()?
I am not sure... but please see below.
> Explicit wake_up_state() without kick_process() is okay there because > if the code assumes that the tasks are guaranteed to pass through > signal delivery path whenever event worthy of notification happens > (either SIGNAL_STOP_STOPPED or group_stop_count is set). PTRACE_CONT > breaks that as the tracee could be running in userland and thus the > solution is to add kick_process() as in signal_wake_up(). > > Am I making any sense?
Perhaps. This depends on how we define/implement the new behaviour.
It is not clear to me what the new trap should actually do. And how. Either way, prepare_signal(SIGCONT) should do something with the ptraced threads, and this is what we should care about. Probably we can set TIF_SIGPENDING if task_ptrace() is true.
Anyway we should ensure SIGCONT can't race with detach.
> > Unfortunately, this means that recalc_sigpending_tsk() has to check > > SIGNAL_CLD_MASK as well. Do you see another solution? > > Hmmm... I think the above subtle breakage exists for !ptrace case too. > Please consider the following scenario. > > * SIGSTOP is sent to a task and group stop is initiated. > > * Before the task participates in group stop, SIGCONT is sent.
In this case we are doing nothing intentionally, as if SIGSTOP wasn't sent.
> * Before CLD_STOPPED notification for the incomplete-stop/cont > sequence can be made, recalc_sigpending() happens. > > * CLD_STOPPED notification is pending but TIF_SIGPENDING isn't set and > the task isn't in signal delivery path and can continue execution.
This doesn't matter, or I misunderstood.
We only add "SIGNAL_CLD_* | SIGNAL_STOP_CONTINUED" if we know there is at least one thread in get_signal_to_deliver()->do_signal_stop() paths. In this case we do not rely on TIF_SIGPENDING at all.
(just in case, I am ignoring the current problems with group-stop and PTRACE_CONT).
Oleg.
| |