Page MenuHomeFreeBSD
Differential D57482

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

Authored by kib on Jun 5 2026, 9:50 PM.
Tags
None
Referenced Files
F163444420: D57482.id179323.diff
Thu, Jul 23, 6:33 AM
F163421892: D57482.diff
Thu, Jul 23, 2:02 AM
Unknown Object (File)
Tue, Jul 21, 12:29 PM
Unknown Object (File)
Mon, Jul 20, 11:40 PM
Unknown Object (File)
Sun, Jul 19, 6:37 AM
Unknown Object (File)
Sun, Jul 19, 2:41 AM
Unknown Object (File)
Sat, Jul 18, 7:55 PM
Unknown Object (File)
Sat, Jul 18, 11:42 AM
View All 59 Files
Subscribers
imp
olce

Details

Reviewers
markj
jhb
kevans
Commits
rGa2cfe535771d: exit1(9): do not deadlock if exit is called due to PT_SC_REMOTERQ
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.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

kib created this revision.Jun 5 2026, 9:50 PM
Herald added subscribers: olce, imp. · View Herald TranscriptJun 5 2026, 9:50 PM
kib requested review of this revision.Jun 5 2026, 9:50 PM
kib updated this revision to Diff 179311.Jun 5 2026, 9:58 PM

Commit everything before generating diff from git.

markj added inline comments.Jun 5 2026, 11:00 PM
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 marked an inline comment as done.Jun 5 2026, 11:03 PM
kib added inline comments.
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 updated this revision to Diff 179316.Jun 5 2026, 11:09 PM
kib marked an inline comment as done.

Plug exit call in execve

markj added inline comments.Jun 5 2026, 11:36 PM
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 marked 2 inline comments as done.Jun 6 2026, 12:16 AM
kib added inline comments.
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 updated this revision to Diff 179323.Jun 6 2026, 12:16 AM
kib marked 2 inline comments as done.

Handle linux_exit()

markj added inline comments.Jun 6 2026, 1:27 AM
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 updated this revision to Diff 179333.Jun 6 2026, 3:50 AM
kib marked an inline comment as done.

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

markj added a comment.Jun 8 2026, 2:25 PM

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 updated this revision to Diff 179400.Jun 8 2026, 5:26 PM
kib marked 2 inline comments as done.

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

markj accepted this revision.Jun 8 2026, 7:50 PM
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.

This revision is now accepted and ready to land.Jun 8 2026, 7:50 PM
Closed by commit rGa2cfe535771d: exit1(9): do not deadlock if exit is called due to PT_SC_REMOTERQ (authored by kib). · Explain WhyJun 8 2026, 8:15 PM
This revision was automatically updated to reflect the committed changes.
kib added a commit: rGa2cfe535771d: exit1(9): do not deadlock if exit is called due to PT_SC_REMOTERQ.

Revision Contents
Changeset List

PathSize
sys/
compat/
linux/
4 lines
4 lines
kern/
13 lines
57 lines
3 lines
4 lines
sys/
4 lines
2 lines
1 line

Diff 179400

View Options

sys/compat/linux/linux_fork.c

Loading...
View Options

sys/compat/linux/linux_misc.c

Loading...
View Options

sys/kern/kern_exec.c

Loading...
View Options

sys/kern/kern_exit.c

Loading...
View Options

sys/kern/kern_fork.c

Loading...
View Options

sys/kern/kern_ucoredump.c

Loading...
View Options

sys/sys/proc.h

Loading...
View Options

sys/sys/signalvar.h

Loading...
View Options

sys/sys/syscallsubr.h

Loading...