https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200958
Bug ID: 200958
Summary: filemon has insufficient proc locking
Product: Base System
Version: 11.0-CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: pe...@freebsd.org
sys/dev/filemon_wrapper.c:filemon_pid_check() walks the curproc-p_pptr chain
without the required proc locking.
proc.h:
* c - locked by proc mtx
..
* e - locked by proctree_lock lock
..
* If the locking key specifies two identifiers (for example, p_pptr) then
* either lock is sufficient for read access, but both locks must be held
* for write access.
..
struct proc *p_pptr;/* (c + e) Pointer to parent process.
*/
The p_pptr scanner in filemon_pid_check() probably needs to hold a read rwlock
of proctree_lock.
This normally works fine, except when ptrace is involved. With ptrace actively
reparenting things it can end up where it sits in an infinite loop in
filemon_pid_check().
Tracing pid 97757 tid 100728 td 0xf8012938a980
kdb_alt_break_internal() at kdb_alt_break_internal+0x197/frame
0xfe085fac7730
kdb_alt_break() at kdb_alt_break+0xb/frame 0xfe085fac7740
uart_intr_rxready() at uart_intr_rxready+0x99/frame 0xfe085fac7770
uart_intr() at uart_intr+0x111/frame 0xfe085fac77b0
intr_event_handle() at intr_event_handle+0x9b/frame 0xfe085fac7800
intr_execute_handlers() at intr_execute_handlers+0x48/frame 0xfe085fac7830
lapic_handle_intr() at lapic_handle_intr+0x3f/frame 0xfe085fac7850
Xapic_isr1() at Xapic_isr1+0xba/frame 0xfe085fac7850
--- interrupt, rip = 0x805244ed, rsp = 0xfe085fac7910, rbp =
0xfe085fac7990 ---
filemon_wrapper_freebsd32_stat() at filemon_wrapper_freebsd32_stat+0x6d/frame
0xfe085fac7990
ia32_syscall() at ia32_syscall+0x41b/frame 0xfe085fac7ab0
Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe085fac7ab0
--- syscall (188, FreeBSD ELF32, filemon_wrapper_freebsd32_stat), rip =
0x284aa6d7, rsp = 0x987c, rbp = 0x9918 ---
In this case, it is looping infinitely in filemon_pid_check() and the process
in question is gdb from the gdb test suite.
On the ref* machines we ended up with 8 gdb processes all consuming 100% cpu in
this function.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
