On Tue, Mar 10, 2020 at 09:34:03PM +0100, Bernd Edlinger wrote:

On 3/10/20 9:29 PM, Kees Cook wrote:

quoted

On Sun, Mar 08, 2020 at 04:36:17PM -0500, Eric W. Biederman wrote:

quoted

This makes the code clearer and makes it easier to implement a mutex
that is not taken over any locations that may block indefinitely waiting
for userspace.

Signed-off-by: "Eric W. Biederman" <redacted>
---
 fs/exec.c | 39 ++++++++++++++++++++++++++-------------
 1 file changed, 26 insertions(+), 13 deletions(-)

diff --git a/fs/exec.c b/fs/exec.c
index c3f34791f2f0..ff74b9a74d34 100644
--- a/fs/exec.c
+++ b/fs/exec.c

@@ -1194,6 +1194,23 @@ static int de_thread(struct task_struct *tsk)
 	flush_itimer_signals();
 #endif

Semi-related (existing behavior): in de_thread(), what keeps the thread
group from changing? i.e.:

        if (thread_group_empty(tsk))
                goto no_thread_group;

        /*
         * Kill all other threads in the thread group.
         */
        spin_lock_irq(lock);
	... kill other threads under lock ...

Why is the thread_group_emtpy() test not under lock?

A new thread cannot created when only one thread is executing,
right?

*face palm* Yes, of course. :) I'm thinking too hard.

-- 
Kees Cook