"Dr. Thomas Orgis" thomas.orgis@uni-hamburg.de writes:
Am Mon, 21 Feb 2022 09:49:12 +0100 schrieb Greg Kroah-Hartman gregkh@linuxfoundation.org:
As best as I can figure the intent is to return task->exit_code after a task exits. The field is returned with per task fields, so the exit_code of the entire process is not wanted.
I wondered about the use of exit_code, too, when preparing my patch that introduces ac_tgid and the AGROUP flag to identify the first and last tasks of a task group/process, see
https://lkml.org/lkml/2022/2/18/887
With the information about the position of this task in the group, users can take some meaning from the exit code (individual kills?). The old style ensured that you got one exit code per process.
How do you figure?
For single-threaded processes ac_exitcode would always be reasonable, and be what userspace passed to exit(3).
For multi-threaded processes ac_exitcode before my change was set to some completely arbitrary value for the thread whose tgid == tid.
Frequently the thread whose tgid == tid is the last thread to exit and is brought down by a call to group_exit so it makes sense. Unfortunately there is no requirement for that to be the case.
If the thread whose tgid == tid happens to call pthread_exit the value in ac_exitcode for that thread is pretty much undefined.
The ac_exitcode for the other threads would be the useless value of 0 that the field was initialized to. With my change the value returned is at least well defined.
But thread_group_leader in this context does nothing except limit the value that is returned.
I addressing ac_exitcode fits together with my patch, while increasing the version of taskstats helps clients that then can know that ac_exitcode now has a different meaning. Right now this is a change under the hood and you can just guess (or have to know from the kernel version).
As best as I can tell I did not change the meaning of the field. I change buggy code, and removed an arbitrary and senseless filter.
Now maybe it would have been better to flag the bug fix with a version number. Unfortunately I did not even realize taskstats had a version number. I just know the code made no sense.
Eric