I've been investigating the race in ptrace(2) ATF tests: dbregs_* for x86 (i386 and amd64).
Examples: NetBSD/amd64 http://releng.netbsd.org/b5reports/amd64/2018/2018.03.06.11.21.31/test.html#lib_libc_sys_t_ptrace_wait6_dbregs_dr3_trap_variable_readwrite_write_2bytes NetBSD/i386 http://releng.netbsd.org/b5reports/i386/2017/2017.12.06.17.54.58/test.html#lib_libc_sys_t_ptrace_wait3_dbregs_dr2_trap_variable_readwrite_read_2bytes I still don't know what is the root cause for the race and I'm open for suggestions. Observations: 1. This bug is reproducible only for the scenario with debug register trap according to the tests of mine. 2. It's reproducible on slower x86 hardware or in softemu (qemu). I have not been able to reproduce a single failure on post-Core2Duo CPU. 3. Adding or changing the scenario slightly of tests (like to PT_STEP or changing SIGSTOP to other signal) makes the test disappear at all. 4. Adding almost any debug code anywhere makes this test either disappear or make reproducible much less frequently (sometimes once a day). 5. I've detected that the bug is caused by the fact that _lwp_kill(2) (called via raise(2)) [under a debugger] can trigger two calls of wait(2) to return for the same signal. A few days ago, I've prepared this document: http://netbsd.org/~kamil/kernel/sigstop.txt 6. According to my tests in lwp_userret(): 1549 /* 1550 * It is safe to do this read unlocked on a MP system.. 1551 */ 1552 while ((l->l_flag & LW_USERRET) != 0) { 1553 /* 1554 * Process pending signals first, unless the process 1555 * is dumping core or exiting, where we will instead 1556 * enter the LW_WSUSPEND case below. 1557 */ 1558 if ((l->l_flag & (LW_PENDSIG | LW_WCORE | LW_WEXIT)) == 1559 LW_PENDSIG) { 1560 mutex_enter(p->p_lock); 1561 while ((sig = issignal(l)) != 0) 1562 postsig(sig); 1563 mutex_exit(p->p_lock); 1564 } 1565 -- src/sys/kern/kern_lwp.c We always enter the while() loop and call issignal(). Sometimes we extract a signal and call postsig(). Usually for the call, we see no misbehavior. 7. I've checked that PT_CONTINUE branch where p_stat != SSTOP is never taken, at least for this race. We always call: 828 /* Finally, deliver the requested signal (or none). */ 829 if (t->p_stat == SSTOP) { 830 /* 831 * Unstop the process. If it needs to take a 832 * signal, make all efforts to ensure that at 833 * an LWP runs to see it. 834 */ 835 t->p_xsig = signo; 836 if (resume_all) 837 proc_unstop(t); 838 else 839 lwp_unstop(lt); 840 return 0; 841 } -- src/sys/kern/sys_ptrace_common.c 8. We checked that we call sigpost() twice for a single _lwp_kill(2) call: A. handle_syscall() -> syscall() -> sv_invoke() -> sys__lwp_kill() -> kpsignal2() -> sigpost() B. lwp_userret() -> issignal() -> sigswitch() -> proc_stop() -> sigpost() 9. Adding two consequential wait(2) calls, one after (checking for error condition for another with WNOHANG) - makes the bug disappear completely. I'm looking for hints to speedup the research.
signature.asc
Description: OpenPGP digital signature
