From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936488AbcIWLXn (ORCPT ); Fri, 23 Sep 2016 07:23:43 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36003 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932127AbcIWLXl (ORCPT ); Fri, 23 Sep 2016 07:23:41 -0400 Date: Fri, 23 Sep 2016 13:23:38 +0200 From: Michal Hocko To: Oleg Nesterov Cc: LKML , strace-devel@lists.sourceforge.net, Aleksa Sarai Subject: Re: strace lockup when tracing exec in go Message-ID: <20160923112338.GK4478@dhcp22.suse.cz> References: <20160921152946.GA24210@dhcp22.suse.cz> <20160923095031.GA14923@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160923095031.GA14923@redhat.com> User-Agent: Mutt/1.6.0 (2016-04-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 23-09-16 11:50:32, Oleg Nesterov wrote: > Sorry for delay, I was offline. I'll try to return to this problem next > week, currently I can't even read this thread but at first glance the > proposed patch(es) do not look right... > > On 09/21, Michal Hocko wrote: > > > > The further investigation shown that the tracer (strace) is stuck > > waiting for cred_guard_mutex > > [<0000000000000000>] mm_access+0x22/0xa0 > > [<0000000000000000>] process_vm_rw_core.isra.1+0x112/0x6c0 > > [<0000000000000000>] process_vm_rw+0xab/0x110 > > [<0000000000000000>] SyS_process_vm_readv+0x15/0x20 > > [<0000000000000000>] system_call_fastpath+0x16/0x1b > > [<0000000000000000>] 0x7f186f031c3a > > [<0000000000000000>] 0xffffffffffffffff > ... > > this however doesn't happen because both threads which are dead > > are zombies waiting to be reaped by the parent and to call their > > release_task->__exit_signal. > > Yes, I know, this was already reported. And so far I do not see any > reasonable fix. I _think_ that the "real" fix should rework the > security_bprm_* helpers, but unlikely this is possible. Rework them to not rely on the cred_guard_mutex? Is there any way to workaround this in the strace code? > The trivial test-case: > > void *thread(void *arg) > { > ptrace(PTRACE_TRACEME, 0,0,0); > return NULL; > } > > int main(void) > { > int pid = fork(); > > if (!pid) { > pthread_t pt; > pthread_create(&pt, NULL, thread, NULL); > pthread_join(pt, NULL); > execlp("echo", "echo", "passed", NULL); > } > > sleep(1); > // or anything else which needs ->cred_guard_mutex, > // say open(/proc/$pid/mem) > ptrace(PTRACE_ATTACH, pid, 0,0); > kill(pid, SIGCONT); > > return 0; > } > > Oleg. -- Michal Hocko SUSE Labs