strace lockup when tracing exec in go

[Aleksa Sarai]

>>>>> This patch doesn't help, nor does the previous patch... but with both
>>>>> applied, all is well.  All you have to do now is figure out why :)
>>>>
>>>> Ohh, I should be more explicit, this needs the mm_access part as well.
>>>> Sorry for not being clear enough. So the full change is
>>>
>>> Ah.  That was gonna happen after lunch, but since you already know it
>>> works, I can get back to un-b0rking one of my trees.
>>
>> Yeah, it should work. The testcase is running in a loop for more than
>> hour already and everything seems to be ok. Now the question is whether
>> the fix is really correct which is something for Oleg.
>>
>> Also I think there is at least one more issue lurking there. Without or
>> without the patch I can make tracer get stuck in do_wait waiting for
>> task which doesn't seem to be alive anymore. I will report it separately
>> after this one gets resolved to not pull more confusion in.
>
> OK, the test in the loop has survived 3h of runtime without a single
> lockup so the patch seems to be working for this case. I am posting the
> patch with the full changelog, let's see if it is correct as well. As
> I've said earlier this might be a strace bug which does an unexpected
> syscall while it should be doing wait on the child process instead.
>
> If the patch is correct then I would mark it for stable as well.

This patch fixes the test case, but it also fixes the original issue 
(that strace of runC would fail when the container init process is 
exec-ing the user init process). Thanks Michal, I'll apply it to my 
local kernel. :D

-- 
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/