lkml.org 
[lkml]   [2013]   [Nov]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/4] check_unsafe_exec: kill the dead -EAGAIN and clear_in_exec logic
(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.




\
 
 \ /
  Last update: 2013-11-22 21:41    [W:0.115 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site