lkml.org 
[lkml]   [2017]   [Feb]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH V2 1/2] exec: don't wait for zombie threads with cred_guard_mutex held
    On 02/21, Eric W. Biederman wrote:
    >
    > Today cred_guard_mutex is part of making exec appear to be an atomic
    > operation to ptrace and and proc. To make exec appear to be atomic
    > we do need to take the mutex at the beginning and release it at the end
    > of exec.
    >
    > The semantics of exec appear atomic to ptrace_attach and to proc readers
    > are necessary to ensure we use the proper process credentials in the
    > event of a suid exec.

    This is clear. My point is that imo a) it is over-used in fs/proc and b)
    the scope of this mutex if execve is too huge. I see absolutely no reason
    to do copy_strings() with this mutex held, for example. And note that
    copy_strings() can use a lot of memory/time, it can trigger oom,swapping,
    etc.

    But let me repeat, this is a bit off-topic right now, this patch doesn't
    change anything in this respect, afaics.


    > I believe making cred_guard_mutex per task is an option. Reducing the
    > scope of cred_guard_mutex concerns me. There appear to be some fields
    > like sighand that we currently expose in proc

    please see another email, collect_sigign_sigcatch() is called without this
    mutex.

    > Do you know if we can make cred_guard_mutex a per-task lock again?

    I think we can, but this needs some (afaics simple) changes too.

    But for what? Note that the problem fixed by this series won't go away
    if we do this.


    So what do you think about this series?

    Oleg.

    \
     
     \ /
      Last update: 2017-02-21 18:55    [W:2.555 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site