linux-kernel - Re: strace lockup when tracing exec in go

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <16e6f7cc-0ba1-252a-f87f-486520cd5893@suse.com>
Date:   Fri, 23 Sep 2016 11:17:03 +1000
From:   Aleksa Sarai <asarai@...e.com>
To:     Michal Hocko <mhocko@...nel.org>, Oleg Nesterov <oleg@...hat.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        strace-devel@...ts.sourceforge.net,
        Mike Galbraith <umgwanakikbuti@...il.com>
Subject: Re: strace lockup when tracing exec in go

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