On Fri, Jun 26, 2020 at 10:00:01AM +0100, Christoph Hellwig wrote: > On Fri, Jun 26, 2020 at 07:22:34AM +0200, Christian Borntraeger wrote: > > > > > > On 26.06.20 04:54, Luis Chamberlain wrote: > > > On Wed, Jun 24, 2020 at 08:37:55PM +0200, Christian Borntraeger wrote: > > >> > > >> > > >> On 24.06.20 20:32, Christian Borntraeger wrote: > > >> [...]> > > >>> So the translations look correct. But your change is actually a sematic > > >>> change > > >>> if(ret) will only trigger if there is an error > > >>> if (KWIFEXITED(ret)) will always trigger when the process ends. So we > > >>> will always overwrite -ECHILD > > >>> and we did not do it before. > > >>> > > >> > > >> So the right fix is > > >> > > >> diff --git a/kernel/umh.c b/kernel/umh.c > > >> index f81e8698e36e..a3a3196e84d1 100644 > > >> --- a/kernel/umh.c > > >> +++ b/kernel/umh.c > > >> @@ -154,7 +154,7 @@ static void call_usermodehelper_exec_sync(struct > > >> subprocess_info *sub_info) > > >> * the real error code is already in sub_info->retval or > > >> * sub_info->retval is 0 anyway, so don't mess with it > > >> then. > > >> */ > > >> - if (KWIFEXITED(ret)) > > >> + if (KWEXITSTATUS(ret)) > > >> sub_info->retval = KWEXITSTATUS(ret); > > >> } > > >> > > >> I think. > > > > > > Nope, the right form is to check for WIFEXITED() before using > > > WEXITSTATUS(). > > > > But this IS a change over the previous code, no? > > I will test next week as I am travelling right now. > > I'm all for reverting back to the previous behavior. If someone wants > a behavior change it should be a separate patch. And out of pure self > interest I'd like to see that change after my addition of the > kernel_wait helper to replace the kernel_wait4 abuse :)
Yeah sure, this will be *slightly* cleaner after that. Today we implicitly return -ECHLD as well under the assumption the kernel_wait4() call failed. Andrew, can you please revert these two for now: selftests: simplify kmod failure value umh: fix processed error when UMH_WAIT_PROC is used Later, we'll add Christoph's simplier kernel wait, and make the change directly there to catpure the right error. That still won't fix this reported issue, but it will be cleaner and will go tested by Christian Borntraeger before. Luis
