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

Bernd Edlinger
2020-04-04T05:49:04Z

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
>>