On 11/11, Bernd Edlinger wrote: > > On 11/11/25 14:12, Oleg Nesterov wrote: > > On 11/11, Bernd Edlinger wrote: > >> > >> Well when this is absolutely not acceptable then I would have to change > >> all security engines to be aware of the current and the new credentials. > > > > Hmm... even if we find another way to avoid the deadlock? Say, the patches > > I sent... > > > > Maybe, but it looks almost too simple ;-) > > 164 sleep(2); > 165 /* deadlock may happen here */ > 166 k = ptrace(PTRACE_ATTACH, thread2_tid, 0L, 0L); > > what happens if you change the test expectation here, that the > ptrace may fail instead of succeed? > > What signals does the debugger receive after that point? > Is the debugger notified that the debugged process continues, > has the same PID, and is no longer ptraced?
Ah, but this is another thing... OK, you dislike 3/3 and I have to agree. Yes, de_thread() silently untraces/reaps the old leader and after 3/3 debugger can't rely on PTRACE_EVENT_EXIT, so unless the debugger has already attached to all sub-threads (at least to execing thread) it looks as if the leader was just untraced somehow. OK, this is probably too bad, we need another solution... Oleg.
