385d9c8955
Add support for tracing vfork(2) events in the context of ptrace(2). This API covers other frontends to fork1(9) like posix_spawn(2) or clone(2), if they cause parent to wait for exec(2) or exit(2) of the child. Changes: - Add new argument to sigswitch() determining whether we need to acquire the proc_lock or whether it's already held. - Refactor fork1(9) for fork(2) and vfork(2)-like events. Call sigswitch() from fork(1) for forking or vforking parent, instead of emitting kpsignal(9). We need to emit the signal and suspend the parent, returning to user and relock proc_lock. - Add missing prototype for proc_stop_done() in kern_sig.c. - Make sigswitch a public function accessible from other kernel code including <sys/signalvar.h>. - Remove an entry about unimplemented PTRACE_VFORK in the ptrace(2) man page. - Permin PTRACE_VFORK in the ptrace(2) frontend for userland. - Remove expected failure for unimplemented PTRACE_VFORK tests in the ATF ptrace(2) test-suite. - Relax signal routing constraints under a debugger for a vfork(2)ed child. This intended to protect from signaling a parent of a vfork(2)ed child that called PT_TRACE_ME, but wrongly misrouted other signals in vfork(2) use-cases. Add XXX comments about still existing problems and future enhancements: - correct vfork(2) + PT_TRACE_ME handling. - fork1(2) handling of scenarios when a process is collected in valid but rare cases. All ATF ptrace(2) fork[1-8] and vfork[1-8] tests pass. Fix PR kern/51630 by Kamil Rytarowski (myself). Sponsored by <The NetBSD Foundation> |
||
|---|---|---|
| .. | ||
| bin | ||
| crypto | ||
| dev | ||
| fs | ||
| games | ||
| include | ||
| ipf | ||
| kernel | ||
| lib | ||
| libexec | ||
| modules | ||
| net | ||
| rump | ||
| sbin | ||
| share | ||
| sys | ||
| usr.bin | ||
| usr.sbin | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
| h_macros.h | ||
README
$NetBSD: README,v 1.4 2012/05/18 15:36:21 jruoho Exp $ When adding new tests, please try to follow the following conventions. 1. For library routines, including system calls, the directory structure of the tests should follow the directory structure of the real source tree. For instance, interfaces available via the C library should follow: src/lib/libc/gen -> src/tests/lib/libc/gen src/lib/libc/sys -> src/tests/lib/libc/sys ... 2. Equivalently, all tests for userland utilities should try to follow their location in the source tree. If this can not be satisfied, the tests for a utility should be located under the directory to which the utility is installed. Thus, a test for env(1) should go to src/tests/usr.bin/env. Likewise, a test for tcpdump(8) should be in src/tests/usr.sbin/tcpdump, even though the source code for the program is located under src/external. 3. Otherwise use your own discretion.