exit1(9): do not deadlock if exit is called due to PT_SC_REMOTERQ

[kib]

Summary

The remote syscall is executed in the context where debugger owns a
p_lock hold on the target. Due to this, exit1() waiting for p_lock
going to zero, never happen.

Postpone the exit1() call to ast then, saving the provided rval and
signo in the struct proc. Mark the async-exiting proc with the new
p_flag P_ASYNC_EXIT.

While p_xexit can be reused, p_xsig can be only set by actual exit1(),
otherwise it breaks the ptrace mechanism. Allocate a dedicated p_asig
for it.

[kib]

Commit everything before generating diff from git.

[markj]

sys/kern/kern_ucoredump.c

201

What about the exit1() calls from do_execve() and fork_return()? Can't they be triggered via ptrace(PT_SC_REMOTE)?

[kib]

sys/kern/kern_ucoredump.c

201

From fork_return it cannot, I believe.
For execve yes, and I had it changed in the previous version of the patch: I had exit1 and exit2 swapped. Then I decided to keep exit1 synchronous and forgot to update execve.

[kib]

Plug exit call in execve

[markj]

sys/kern/kern_exit.c

229

Is there any reason this shouldn't be spelled kern_exit(), and all external consumers updated to use it? e.g., shouldn't linux_exit() call this function as well? AFAIK it is possible to use ptrace(PT_SC_REMOTE) with foreign ABIs.

245

How can this case happen?

[kib]

sys/kern/kern_exit.c

229

I like the exit2() name, it has the same weirdness flavor as exit1(). If you insist, I will change it.

245

I believe e.g. ptrace(PT_CONTINUE, pid, 1, SIGKILL) could trigger it. Any killing signal processed by TDA_SIG before TDA_ASYNC_EXIT would get there through sigexit().

[kib]

Handle linux_exit()

[markj]

sys/kern/kern_exit.c

229

I think it's not very nice to force others to figure out whether they should use exit1() or exit2(), when there is no comment explaining the difference, nor any clue in the names (shouldn't exit1() at least call exit2()?).

If we keep both names, then one of them should be local to kern_exit.c.

[kib]

Rename exit2() to kern_exit().
Add comment.

[markj]

I'm not sure about the exit1() call in fork_return(). Isn't it possible for the debugger to attach to the nascent process (see the earlier ptracestop() calls there) and then trigger a system call immediately?

sys/kern/kern_exec.c

1045

This annotation isn't true anymore.

sys/kern/kern_exit.c

240

[kib]

kern_exit() in fork_return()
Remove unreached comment.
Fix function name in kassert.

[markj]

In D57482#1317457, @markj wrote:

I'm not sure about the exit1() call in fork_return(). Isn't it possible for the debugger to attach to the nascent process (see the earlier ptracestop() calls there) and then trigger a system call immediately?

I added a test for this scenario to D57485. PT_SC_REMOTE requires the target to be stopped at the user/kernel boundary so cannot be used while the new child is blocked in fork_return(). But I think using kern_exit() in fork_return() is okay anyway.