On 3/2/20 1:28 PM, Oleg Nesterov wrote: > On 03/01, Bernd Edlinger wrote: >> >> This fixes a deadlock in the tracer when tracing a multi-threaded >> application that calls execve while more than one thread are running. > > Heh. Yes, known problem. See my attempt to fix it: > https://lore.kernel.org/lkml/20170213141452.GA30203@xxxxxxxxxx/ > >> @@ -1224,7 +1224,7 @@ struct mm_struct *mm_access(struct task_struct *task, unsigned int mode) >> struct mm_struct *mm; >> int err; >> >> - err = mutex_lock_killable(&task->signal->cred_guard_mutex); >> + err = mutex_lock_killable(&task->signal->cred_change_mutex); > > So if I understand correctly your patch doesn't fix other problems > with debugger waiting for cred_guard_mutex. > No, but I see this just as a first step. > I too do not think this can justify the new mutex in signal_struct... > I think for the vm_access the semantic of this mutex is clear, that it prevents the credentials to change while it is held by vm_access, and probably other places can take advantage of this mutex as well. While on the other hand, the cred_guard_mutex is needed to avoid two threads calling execve at the same time. So that is needed as well. What remains is probably making PTHREAD_ATTACH detect that the process is currently in execve, and make that call fail in that situation. I have not thought in depth about that problem, but it will probably just need the right mutex to access current->in_execve. That's at least how I see it. Thanks Bernd.
