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.