Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

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.


Thanks
Bernd.


>               Linus
>