Re: [PATCH 04/17] signal: In get_signal call do_exit when it is unnecessary to shoot down threads
From: Oleg Nesterov
Date: Tue Jun 25 2024 - 08:37:48 EST
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.