On Tue, Mar 10, 2020 at 09:34:03PM +0100, Bernd Edlinger wrote: > On 3/10/20 9:29 PM, Kees Cook wrote: > > On Sun, Mar 08, 2020 at 04:36:17PM -0500, Eric W. Biederman wrote: > >> > >> 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" <ebiederm@xxxxxxxxxxxx> > >> --- > >> 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
