Messages in this thread |  | | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 | From | Bernd Edlinger <> | Date | Mon, 6 Apr 2020 08:41:30 +0200 |
| |
On 4/4/20 7:48 AM, Bernd Edlinger wrote: > > > 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. >>
I mean it, I could not imagine a greater honor, than You improving one of my patches.
Just please consider what I said below before you do it.
Thanks Bernd.
>>> @@ -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 >>>
|  |