> Date: Sat, 20 Mar 2021 13:10:17 +0100 > From: Martin Pieuchot <[email protected]> > > On SP systems, like bluhm@'s armv7 regression machine, the kern/ptrace2 > test is failing due to a subtle behavior. Diff below makes it pass. > > http://bluhm.genua.de/regress/results/2021-03-19T15%3A17%3A02Z/logs/sys/kern/ptrace2/make.log > > The failing test does a fork(2) and the parent issues a PT_ATTACH on the > child before it has been scheduled for the first time. Then the parent > goes to sleep in waitpid() and when the child starts executing the check > below overwrites the ptrace(2)-received SIGSTOP by a SIGTRAP. > > This scenario doesn't seem to happen on MP machine because the child > starts to execute itself on a different core right after sys_fork() is > finished. > > What is the purpose of this check? Should it be relaxed or removed?
This is part of PT_SET_EVENT_MASK/PTRACE_FORK support: https://github.com/openbsd/src/commit/f38bed7f869bd3503530c554b4860228ea4e8641 When reporting of the PTRACE_FORK event is requested, the debugger expects to see a SIGTRAP in both the parent and the child. The code expects that the only way to have PS_TRACED set in the child from the start is when PTRACE_FORK is requested. But the failing test shows there is a race with PT_ATTACH. I think the solution is to have fork1() only run fork_return() if the FORK_PTRACE flag is set, and use run child_return() otherwise. > Index: kern/kern_fork.c > =================================================================== > RCS file: /cvs/src/sys/kern/kern_fork.c,v > retrieving revision 1.234 > diff -u -p -r1.234 kern_fork.c > --- kern/kern_fork.c 15 Feb 2021 09:35:59 -0000 1.234 > +++ kern/kern_fork.c 20 Mar 2021 11:59:18 -0000 > @@ -86,9 +86,6 @@ fork_return(void *arg) > { > struct proc *p = (struct proc *)arg; > > - if (p->p_p->ps_flags & PS_TRACED) > - psignal(p, SIGTRAP); > - > child_return(p); > } > > >
