lkml.org 
[lkml]   [2020]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [GIT PULL] Please pull proc and exec work for 5.7-rc1
    From
    Date


    On 4/4/20 7:43 AM, Bernd Edlinger wrote:
    >
    >
    > On 4/3/20 6:23 PM, Linus Torvalds wrote:
    >> On Fri, Apr 3, 2020 at 8:09 AM Bernd Edlinger <bernd.edlinger@hotmail.de> wrote:
    >>>
    >>> On 4/2/20 9:04 PM, Linus Torvalds wrote:
    >>>> In fact, then you could drop the
    >>>>
    >>>> mutex_unlock(&tsk->signal->exec_update_mutex);
    >>>>
    >>>> in the error case of exec_mmap(), because now the error handling in
    >>>> free_bprm() would do the cleanup automatically.
    >>>>
    >>>
    >>> The error handling is sometimes called when the exec_update_mutex is
    >>> not taken, in fact even de_thread not called.
    >>
    >> But that's the whole point of the flag. Make the flag be about "do I
    >> hold the mutex", and then the error handling does the right thing
    >> regardless.
    >>
    >>> Can you say how you would suggest that to be done?
    >>
    >> I think the easiest thing to do to explain is to just write the patch.
    >>
    >> This is entirely untested, but see what the difference is? I make the
    >> flag be about exactly where I take the lock, not about some "I have
    >> called exec_mmap".
    >>
    >> Which means that now exec_mmap() doesn't even need to unlock it in the
    >> error case, because the unlocking will happen properly in the
    >> bprm_exit regardless.
    >>
    >> This makes that unconditional unlocking logic much more obvious.
    >>
    >> That said, Eric says he can make it all properly static so that it
    >> doesn't need that kind of dynamic "if (x) unlock()" logic at all,
    >> which is much better.
    >>
    >> So this patch is not for consumption, it's purely for "look, something
    >> like this"
    >>
    >
    >
    > Just one suggestion, in general It would feel pretty much okay if you
    > like to improve the naming, and the consistency in any of my patches.
    >
    >> @@ -1067,7 +1069,6 @@ static int exec_mmap(struct mm_struct *mm)
    >> down_read(&old_mm->mmap_sem);
    >> if (unlikely(old_mm->core_state)) {
    >> up_read(&old_mm->mmap_sem);
    >> - mutex_unlock(&tsk->signal->exec_update_mutex);
    >
    > I was trying to replicate the behavior of prepare_bprm_creds
    > which also unlocks the mutex in the error case, therefore it felt
    > okay to unlock the mutex here, but it will work either way.
    >
    > I should further note, that the mutex would be locked if this
    > error exit is taken, and unlocked if this error happens:
    >
    > ret = mutex_lock_killable(&tsk->signal->exec_update_mutex);
    > if (ret)
    > return ret;
    >
    > so at least the function comment I introduced above should be updated:
    > * Maps the mm_struct mm into the current task struct.
    > * On success, this function returns with the mutex
    > * exec_update_mutex locked.
    >
    >
    >> put_binfmt(fmt);
    >> - if (retval < 0 && bprm->called_exec_mmap) {
    >> + if (retval < 0 && !bprm->mm) {
    >
    > Using bprm->mm like this feels like a hack to me. It works here,
    > but nowhere else. Therefore I changed this line.
    >
    > Using !bprm->mm in the error handling code made Eric's patch fail.
    >

    That does probably work better it the boolean is named
    after_the_point_of_no_return or something....


    >
    > Thanks
    > Bernd.
    >
    >
    >> Linus
    >>

    \
     
     \ /
      Last update: 2020-04-04 07:50    [W:4.154 / U:0.696 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site