Oleg Nesterov <oleg@xxxxxxxxxx> writes: > Not sure I understand this patch, I can't apply it. I guess I need to > clone your tree first, will do later. > > Just one question right now, > > On 03/15, Eric W. Biederman wrote: >> >> +static int ptrace_stop(int exit_code, int why, int clear_code, >> unsigned long message, kernel_siginfo_t *info) >> __releases(¤t->sighand->siglock) >> __acquires(¤t->sighand->siglock) >> { >> bool gstop_done = false; >> + bool read_code = true; >> >> if (arch_ptrace_stop_needed()) { >> /* >> @@ -2305,8 +2307,9 @@ static void ptrace_stop(int exit_code, int why, int clear_code, >> >> /* tasklist protects us from ptrace_freeze_traced() */ >> __set_current_state(TASK_RUNNING); >> + read_code = false; >> if (clear_code) >> - current->exit_code = 0; >> + exit_code = 0; >> read_unlock(&tasklist_lock); >> } >> >> @@ -2316,8 +2319,10 @@ static void ptrace_stop(int exit_code, int why, int clear_code, >> * any signal-sending on another CPU that wants to examine it. >> */ >> spin_lock_irq(¤t->sighand->siglock); >> + if (read_code) exit_code = current->exit_code; > > style ;) > >> current->last_siginfo = NULL; >> current->ptrace_message = 0; >> + current->exit_code = 0; > > OK, I like it... but can't we remove the ugly "int clear_code" arg? The flag clear_code controls what happens if a ptrace_stop does not stop. In particular clear_code means do not continue with a signal if we can not stop. For do_jobctl_trap calling ptrace_stop it clearly does not matter. For ptrace_signal it would be a change in behavior, that would cause the signal not to be delivered. For ptrace_do_notify we don't have a signal to deliver unless userspace gives us one so clear_code makes sense at that point. Which is a long way of saying that no we can not remove clear_stop because the behavior it is used to implement makes sense and userspace can reasonably depend upon it. Eric