Differential D20381

Do not go into sleep in sleepq_catch_signals() when SIGSTOP from PT_ATTACH was consumed.
ClosedPublic
Actions

Authored by kib on May 23 2019, 3:08 PM.

Details

Reviewers

jhb
markj

Commits

rS348360: Do not go into sleep in sleepq_catch_signals() when SIGSTOP from

Summary

In particular, do not clear TDP_FSTP in ptracestop() if td_wchan is non-NULL. Leave it to sleepq_catch_signal() to clear and convert zero return code to EINTR.

Otherwise, per submitter report, if the PT_ATTACH SIGSTOP was delivered right after the thread was added to the sleepqueue but not yet really sleep, and cursig() caused debugger attach, the thread sleeps instead of returning to the userspace boundary with EINTR.

PR: 231445

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

kib created this revision.May 23 2019, 3:08 PM

Herald added a subscriber: imp. · View Herald TranscriptMay 23 2019, 3:08 PM

Harbormaster completed remote builds in B24431: Diff 57770.May 23 2019, 3:08 PM

kib edited the summary of this revision. (Show Details)May 23 2019, 3:10 PM

markj added inline comments.May 27 2019, 3:19 PM

sys/kern/subr_sleepqueue.c
507 ↗	(On Diff #57770)	"should do that here as well"
512 ↗	(On Diff #57770)	How is it possible for FSTP to be set when ret != 0? Doesn't it imply that some non-SIGSTOP signal was handled ahead of the PT_ATTACH SIGSTOP?

kib marked an inline comment as done.May 27 2019, 3:52 PM

kib added inline comments.

sys/kern/subr_sleepqueue.c
512 ↗	(On Diff #57770)	I believe that debugger might choose to deliver some other signal when it continues from SIGSTOP, instead of ignoring it. Then issignal() would do one more iteration, with the entry to ptracestop() which would still not clear TDB_FSTP, and that signal causes specific error return from the cursig() to sleepq_catch_signals().