Re: [PATCH 11/11] Process exit status is leader exit status testcase

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Thu, 2022-03-03 at 14:40 +0000, Pedro Alves wrote:
> From: Lancelot SIX <lancelot.six@amd.com>
> 
> This adds a multi-threaded testcase that has all threads in the
> process exit with a different exit code, and ensures that GDB reports
> the thread group leader's exit status as the whole-process exit
> status.  Before this set of patches, this would randomly report the
> exit code of some other thread, and thus fail.
> 
> Tested on Linux-x86_64, native and gdbserver.
> 
> Co-Authored-By: Pedro Alves <pedro@palves.net>
> Change-Id: I30cba2ff4576fb01b5169cc72667f3268d919557
> ---
>  ...rocess-exit-status-is-leader-exit-status.c | 64
> +++++++++++++++++++
>  ...cess-exit-status-is-leader-exit-status.exp | 45 +++++++++++++
>  2 files changed, 109 insertions(+)
>  create mode 100644 gdb/testsuite/gdb.threads/process-exit-status-is-
> leader-exit-status.c
>  create mode 100644 gdb/testsuite/gdb.threads/process-exit-status-is-
> leader-exit-status.exp

This test fails on kernels >= 6.1.  The symptom is that the kernel
reports that all threads exit with the same status - that of the first
thread to exit.  Bisect points to:


commit d80f7d7b2c75c5954d335dffbccca62a5002c3e0
Author: Eric W. Biederman <ebiederm@xmission.com>
Date:   Tue Jun 21 14:38:52 2022 -0500

signal: Guarantee that SIGNAL_GROUP_EXIT is set on process exit

Track how many threads have not started exiting and when the last
thread starts exiting set SIGNAL_GROUP_EXIT.

This guarantees that SIGNAL_GROUP_EXIT will get set when a process
exits.  In practice this achieves nothing as glibc's implementation of
_exit calls sys_group_exit then sys_exit.  While glibc's implemenation
of pthread_exit calls exit (which cleansup and calls _exit) if it is
the last thread and sys_exit if it is the last thread.

This means the only way the kernel might observe a process that does
not set call exit_group is if the language runtime does not use glibc.

With more cleanups I hope to move the decrement of quick_threads
earlier.

Link:
https://lkml.kernel.org/r/87bkukd4tc.fsf_-_@email.froward.int.ebiederm.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>


I'm not sure what to do with it - can one claim that this is a kernel
regression?  Or should GDB be able to deal with that?