Messages in this thread | | | Date | Wed, 18 May 2011 18:48:14 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 02/10] job control: introduce JOBCTL_TRAP_STOP and use it for group stop trap |
| |
On 05/16, Tejun Heo wrote: > > This patch adds a new jobctl flag - JOBCTL_TRAP_STOP. When set, it > triggers a trap site, which behaves like group stop trap, in > get_signal_to_deliver() before checking for pending signals. While > ptraced, do_signal_stop() doesn't stop itself. It initiates group > stop if requested and schedules JOBCTL_TRAP_STOP and returns, which > makes its caller - get_signal_to_deliver() - to relock, check and > enter the trap.
Heh. Starting from this patch, I think I will never understand this code in details ;)
> Although this adds an unlock-relocking between checking of > JOBCTL_STOP_PENDING and actually trapping for STOP, this doesn't > affect correctness.
Well, I think it does affect. Although the problem is minor.
> ptrace_stop() already had conditional > unlock-relocking
Yes, but ptrace_stop() can't send the CLD_STOPPED notfication before the tracee is ready for do_wait(WNOHANG). Contrary, get_signal_to_deliver() can if we race with SIGCONT.
> While at it, add proper function comment to do_signal_stop() and make > it return bool. > ... > > + * RETURNS: > + * %false if group stop is already cancelled and nothing happened. %true > + * if participated in group stop.
Well, the traced task didn't participate yet... Nevermind.
So far I can't really understand why do we have both JOBCTL_TRAP_STOP and and JOBCTL_TRAPPING... Please ignore, I didn't read other patches yet.
Hmm. And afaics there is a bug in do_signal_stop(), after "[PATCH 6/9] job control: make task_clear_jobctl_pending() clear TRAPPING automatically" ->jobctl &= ~JOBCTL_STOP_SIGMASK is no longer safe. We can clear _TRAPPING without wakeup.
Oleg.
| |