Messages in this thread | | | Date | Fri, 23 Sep 2016 13:23:38 +0200 | From | Michal Hocko <> | Subject | Re: strace lockup when tracing exec in go |
| |
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
| |