Messages in this thread | | | Date | Thu, 28 Apr 2022 22:59:57 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH v2 2/5] sched,ptrace: Fix ptrace_check_attach() vs PREEMPT_RT |
| |
On 04/28, Peter Zijlstra wrote: > > Oleg pointed out that the tracee can already be killed such that > fatal_signal_pending() is true. In that case signal_wake_up_state() > cannot be relied upon to be responsible for the wakeup -- something > we're going to want to rely on.
Peter, I am all confused...
If this patch is against the current tree, we don't need it.
If it is on top of JOBCTL_TRACED/DELAY_WAKEKILL changes (yours or Eric's), then it can't help - SIGKILL can come right after the tracee drops siglock and calls schedule().
Perhaps I missed something, but let me repeat the 3rd time: I'd suggest to simply clear JOBCTL_TRACED along with LISTENING/DELAY_WAKEKILL before return to close this race.
Oleg.
> --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -2226,6 +2226,10 @@ static int ptrace_stop(int exit_code, in > spin_lock_irq(¤t->sighand->siglock); > } > > + /* Don't stop if the task is dying. */ > + if (unlikely(__fatal_signal_pending(current))) > + return exit_code; > + > /* > * schedule() will not sleep if there is a pending signal that > * can awaken the task. >
| |