On Thu, Apr 30, 2020 at 1:22 AM Linus Torvalds <[email protected]> wrote: > On Wed, Apr 29, 2020 at 3:38 PM Linus Torvalds > <[email protected]> wrote: > > > > If you do it properly, with a helper function instead of repeating > > that fragile nasty thing, maybe it will look better to me. > > Side note: if it has a special helper function for the "get lock, > repeat if it was invalid", you can do a better job than return > -EAGAIN. > > In particular, you can do this > > set_thread_flag(TIF_SIGPENDING); > return -RESTARTNOINTR; > > which will actually restart the system call. So a ptrace() user (or > somebody doing a "write()" to /proc/<pid>/attr/xyz, wouldn't even see > the impossible EAGAIN error.
Wouldn't you end up livelocked in the scenario that currently deadlocks? Like: - tracer attaches to thread A - thread B goes into execve, blocks on waiting for A's death - tracer tries to attach to B and hits the -EAGAIN If we make the PTRACE_ATTACH call restart, the tracer will just end up looping without ever resolving the deadlock. If we want to get through this cleanly with this approach, userspace needs to either deprioritize the "I want to attach to pid X" and go back into its eventloop, or to just treat -EAGAIN as a fatal error and give up trying to attach to that task.
