linux-kernel - Re: [PATCH 5.4 32/80] taskstats: Cleanup the use of task->exit

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 23 Feb 2022 23:40:27 +0100
From:   "Dr. Thomas Orgis" <thomas.orgis@...-hamburg.de>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
CC:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        <linux-kernel@...r.kernel.org>, <stable@...r.kernel.org>,
        Balbir Singh <bsingharora@...il.com>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>
Subject: Re: [PATCH 5.4 32/80] taskstats: Cleanup the use of task->exit_code

Am Tue, 22 Feb 2022 17:53:12 -0600
schrieb "Eric W. Biederman" <ebiederm@...ssion.com>: 

> How do you figure?

I admit that I am struggling with understanding where exit codes come
from in the non-usual cases. During my taskstats tests, I played with
writing a multithreaded application that does call pthread_exit() in
the main thread (pid==tgid), for example. I slowly had to learn just
how messy this can be …

Is it clearly defined what the exitcode of a task as part of a process
is/should/can mean, as opposed to the process as a whole?

> For single-threaded processes ac_exitcode would always be reasonable,
> and be what userspace passed to exit(3).

Yes. That is the one case where we all know what we are dealing with;-)

> For multi-threaded processes ac_exitcode before my change was set to
> some completely arbitrary value for the thread whose tgid == tid.

Isn't the only place where it really makes sense to set the exitcode
when the last task of the process exits? I guess that was the intention
of the earlier code — with the same wrong assumption that I fell victim
to for quite some time: That the group leader (first task, tgid == pid)
always exits last.

I do not know in which cases group member threads have meaningful exit
codes different from the last one (which is the one returned for the
process in whole … ?). I'd love to see the exact reasoning on how
multithreading got mapped into kernel tasks which used to track only
single-threaded processes before.

> With my change the value returned
> is at least well defined.

But defined to what?

> 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.

Well, fixing a bug that has been there from the beginning (of adding
multithreading, at least) is a significant change that one might want
to know about. And I do think that it fits to thouroughly fix these
issues that relate to identifying threads and processes (the shameless
plug of my taskstats patch that I'm working on since 2018, and only got
right in 2022, finally — I hope), while at that.

Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg