In D10515#217891, @jhb wrote:

Also, to be clear, this would just be a direct commit to stable/{10,11}, it would not go into HEAD.

Hmm, if the return is fired here, both parent and child report the same pid (the parent's pid). It would be nice if the child reported its new pid. Why not fire in fork_return() ? One might use td_dbg_sc_code to store which fork variant we should fire the probe for.

• Add kyua test
• restore SIGKILL: in comment

In D9939#205622, @jhb wrote:

It would be nice to add a new test case for this if it isn't too much trouble.

In D9802#202491, @bcr wrote:

OK from the manpages part of the change. Make sure to bump the document date when you commit.
Do we need an entry in ObsoleteFiles.inc for the deleted sys/fs/procfs/procfs_ctl.c ?

• Remove procfs' README file

• style fix

• Add sq_ptrace
• check for P_KILLED inside while loop
• Add tests for full sigqueue and competing stop events

• Make comparisons against NULL/0 explicit

• Style/spelling corrections

• Style/spelling corrections

John - your PT_KILL tests are in this diff since I've been running with them, but I'll remove them before commit to preserve provenance (unless you ask me otherwise).

Take a different direction

• thread_suspend_check: don't sleep if return_instead is 1
• Remove early return that can no longer be hit. Move
• remove redundant conditional
• undo thread_suspend_check_changes
• sleepq_catch_signals: check for suspension before signals
• Use ternary conditional to save lines (note: wrapped at 80 cols)

I first tried putting in a loop that would retry the signal check after suspension if TDF_NEEDSIGCHK was true, but that was tricky since TDF_NEEDSIGCHK can be true even when cursig() will return 0 (there is a potential loop that needs to be broken somehow).

• undo thread_suspend_check_changes
• sleepq_catch_signals: check for suspension before signals

Perhaps an alternative solution would be to recheck TDF_NEEDSIGCHK after returning from thread_suspend_check(), and only in that case do a ERESTART/EINTR? (just brainstorming)

• remove redundant conditional

Here is a more detailed description of the problem:

• Remove early return that can no longer be hit. Move general case early return after more specific case.

Thanks. In fact it seems like this block:

In testing, I find that sending a signal from multiple ptracestop() calls before having a chance to deliver any signals does not work as I'd expect. I now think it would be best, if a ptracestop() call wants to send a new signal to the process but there is already a deferred signal, it should be replaced by the new one.

In D9260#193435, @jhb wrote:

As I said previously, I'm not strongly tied to any particular solution (and was still thinking about what the right solution is). I'm quite happy to defer to kib@'s judgement on not losing signals from ptracestop(). That said, I do think the PT_KILL tests I've added are still relevant and it would be good to verify that those are fixed by this change. (I have some other tests that I need to add to ensure we don't get extra stops for thread exit events if we PT_KILL a multithreaded process as well, but that is orthogonal to this change)

In D9260#192516, @kib wrote:

I think that I have some preference to the patch posted in this review, over the solution where callers of ptracestop() handle further signals. But then, shouldn't ptracestop() clear p_xsig is the signal is posted ?

So in the places where there's a printf now ("Dropping signal from ptracestop") you'd tdsignal() (or some other variant) the return value of ptracestop()? Won't that cause a second, unexpected stop when the time comes to actually act on the signal? (the ptracestop() in kern_sig.c, which, in this review's patch, I skip if there's already a pending signal from the debugger)

Optionally stop scheduler when using "reboot -d". I considered a couple of
other options:

Thanks mav. Originally, I'd thought stopping the scheduler when using 'reboot -d' was the correct way. kib and I discussed a bit though, and I was convinced to look for another option ( https://lists.freebsd.org/pipermail/freebsd-hackers/2016-November/050108.html ). Your first bullet would seem to suggest that stopping the scheduler is necessary.

Giving this review a gentle prod in case anyone willing to review might have forgotten about it. I'd also appreciate any suggestions of reviewers if folks in the current set don't have time to review or feel it's outside their area. Thanks.

Minor tweaks:

Remove @PREFIX@.