Re: [PATCH 2/4] check_unsafe_exec: kill the dead -EAGAIN and clear_in_exec logic

[KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>]

(11/22/2013 12:54 PM), Oleg Nesterov wrote:
> fs_struct->in_exec == T means that this ->fs is used by a single
> process (thread group), and one of the treads does do_execve().
> 
> To avoid the mt-exec races this code has the following complications:
> 
> 	1. check_unsafe_exec() returns -EBUSY if ->in_exec was
> 	   already set by another thread.
> 
> 	2. do_execve_common() records "clear_in_exec" to ensure
> 	   that the error path can only clear ->in_exec if it was
> 	   set by current.
> 
> However, after 9b1bf12d5d51 "signals: move cred_guard_mutex from
> task_struct to signal_struct" we do not need these complications:
> 
> 	1. We can't race with our sub-thread, this is called under
> 	   per-process ->cred_guard_mutex. And we can't race with
> 	   another CLONE_FS task, we already checked that this fs
> 	   is not shared.
> 
> 	   We can remove the  dead -EAGAIN logic.
> 
> 	2. "out_unmark:" in do_execve_common() is either called
> 	   under ->cred_guard_mutex, or after de_thread() which
> 	   kills other threads, so we can't race with sub-thread
> 	   which could set ->in_exec. And if ->fs is shared with
> 	   another process ->in_exec should be false anyway.
> 
> 	   We can clear in_exec unconditionally.
> 
> This also means that check_unsafe_exec() can be void.
> 
> Signed-off-by: Oleg Nesterov <oleg@redhat.com>

I have found no problem in this patch. However, I have a very basic question.
Why do we need to keep fs->in_exec? If I understand correctly, it is needed for
retrieving fork() and exec() race in the same process. If it is correct,
can't we move it it to signal->in_exec? It seems to match signal->cred_guard_mutex
and _I_ can easily understand what the code want.

In the other words, currently we have no protection against making new thread when
p->fs is shared w/ another process and I have no idea why multi process sharing influence
multi thread behavior.

I am not expert in this area and I may overlook something. Please correct me if I am silly.