Fix handling of p_xthread

[kib]

Summary

ptrace(): p_xthread could be NULL for P_STOPPED_TRACE

Suppose that ptrace(PT_ATTACH) is called on mt process, and the thread
arbitrary selected as leader (p_xthread) by the attach code, is already
in kernel preparing to exit as the process lock becomes available.  Then
the thread_exit() function clears p->p_xthread, and we end up with the
traced signal-stopped process with NULL p_xthread.

This state is legitimate, and really p_xthread must point to a thread
that is inside ptracestop().  If p_xthread is NULL, but ptrace code
requires some leader thread, arbitrarly designate it as needed.

Reported and tested by: pho

sig_handle_first_stop(): allow NULL leader thread

Remove the ext argument, the ext condition is indicated by NULL td.
If the td argument is NULL, p_xthread is set to NULL, for initial
attach. Previous commit prepared ptrace() code for the case.

sig_suspend_thread() only uses the td arg to avoid interrupting the
current thread as micro-optimization, so it is fine to pass NULL.

Tested by:      pho

[markj]

Is this a regression from the previous ptrace commits, or was it a preexisting bug? If the proc is preparing to exit, why not abort the attach?

sys/kern/sys_process.c

1323–1327

This comment should be updated to explain the case p_xthread == NULL.

[kib]

In D49961#1141070, @markj wrote:

Is this a regression from the previous ptrace commits, or was it a preexisting bug?

This is a regression.

If the proc is preparing to exit, why not abort the attach?

It is not proc that exiting (in this case we do not allow attach indeed). It is the thread that was selected for p_xthread without going into ptracestop() that could be exiting, but it is not yet recorded in the thread state.

[kib]

Update comment.