Re: [PATCH 04/17] signal: In get_signal call do_exit when it is unnecessary to shoot down threads

[Oleg Nesterov <oleg@redhat.com>]

On 06/18, Eric W. Biederman wrote:
>
> --- a/kernel/exit.c
> +++ b/kernel/exit.c
> @@ -1001,8 +1001,6 @@ do_group_exit(int exit_code)
>
>  	if (sig->flags & SIGNAL_GROUP_EXIT)
>  		exit_code = sig->group_exit_code;
> -	else if (sig->group_exec_task)
> -		exit_code = 0;

OK...

> @@ -1010,8 +1008,6 @@ do_group_exit(int exit_code)
>  		if (sig->flags & SIGNAL_GROUP_EXIT)
>  			/* Another thread got here before we took the lock.  */
>  			exit_code = sig->group_exit_code;
> -		else if (sig->group_exec_task)
> -			exit_code = 0;

Well... So with this change do_group_exit() always "wins" the race if it is
called when another thread has already started de_thread().

But de_thread() won't necessarily notice SIGKILL. Sure, the execing thread
can't return to user-space, but it can do a lot of things after de_thread().

Just for example, can it reach trace_sched_process_exec() ? If yes, then it
will look as if it exits with the exit_code provided by do_group_exit()
_after_ exec.

This differs from case when the execing thread is killed after de_thread(),
in this case exit_code = SIGKILL...

I do not see anything really wrong, just trying to understand the impact of
this change, it looks a bit subtle...

Oleg.