Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Oleg Nesterov
On 02/13, Mika Penttilä wrote: > > > +int de_thread(struct task_struct *tsk) > > { > > struct signal_struct *sig = tsk->signal; > > struct sighand_struct *oldsighand = tsk->sighand; > > @@ -1051,60 +1100,24 @@ static int de_thread(struct task_struct *tsk) > > if

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Oleg Nesterov
On 02/13, Mika Penttilä wrote: > > > +int de_thread(struct task_struct *tsk) > > { > > struct signal_struct *sig = tsk->signal; > > struct sighand_struct *oldsighand = tsk->sighand; > > @@ -1051,60 +1100,24 @@ static int de_thread(struct task_struct *tsk) > > if

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Mika Penttilä
On 13.02.2017 16:15, Oleg Nesterov wrote: > + retval = de_thread(current); > + if (retval) > + return retval; > > if (N_MAGIC(ex) == OMAGIC) { > unsigned long text_addr, map_size; > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 4223702..79508f7

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Mika Penttilä
On 13.02.2017 16:15, Oleg Nesterov wrote: > + retval = de_thread(current); > + if (retval) > + return retval; > > if (N_MAGIC(ex) == OMAGIC) { > unsigned long text_addr, map_size; > diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c > index 4223702..79508f7

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Oleg Nesterov
On 02/14, kbuild test robot wrote: > > Hi Oleg, > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.10-rc8 next-20170213] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Oleg Nesterov
On 02/14, kbuild test robot wrote: > > Hi Oleg, > > [auto build test ERROR on linus/master] > [also build test ERROR on v4.10-rc8 next-20170213] > [if your patch is applied to the wrong git tree, please drop us a note to > help improve the system] > > url: >

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread kbuild test robot
Hi Oleg, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc8 next-20170213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread kbuild test robot
Hi Oleg, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc8 next-20170213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread kbuild test robot
Hi Oleg, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc8 next-20170213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread kbuild test robot
Hi Oleg, [auto build test ERROR on linus/master] [also build test ERROR on v4.10-rc8 next-20170213] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Oleg Nesterov
de_thread() waits for other threads with ->cred_guard_mutex held and this is really bad because the time is not bounded, debugger can delay the exit and this lock has a lot of users (mostly abusers imo) in fs/proc and more. And this leads to deadlock if debugger tries to take the same mutex:

[PATCH 1/2] exec: don't wait for zombie threads with cred_guard_mutex held

2017-02-13 Thread Oleg Nesterov
de_thread() waits for other threads with ->cred_guard_mutex held and this is really bad because the time is not bounded, debugger can delay the exit and this lock has a lot of users (mostly abusers imo) in fs/proc and more. And this leads to deadlock if debugger tries to take the same mutex: