https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228858
Bug ID: 228858
Summary: panic when delivering knote to a process who has
opened a kqueue() is dying
Product: Base System
Version: 11.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: b...@freebsd.org
Reporter: siddhartht...@gmail.com
The following race can occur on multi-processor systems resulting in this
panic.
-- Race --
cpu x
cpu y
process X dies
Process Y is sending knote() to kqueue() opened by X
kqueue_close
knote (due to exec, exit, fork etc of any process)
kqueue_drain
KQ_LOCK(kq) << Acquired the lock
KQ_LOCK(kq) << sleep and loop in __mtx_lock_sleep
….
KQ_UNLOCK(kq)
kqueue_destory
mtx_destroy(>kq_lock);
set MTX_UNOWNED|MTX_CONTESTED
__mtx_lock_sleep()
Panic because no owner and (MTX_UNOWNED|MTX_CONTESTED) are set
free(kq, M_KQUEUE)
Process X is listening to NOTE_EXIT|NOTE_EXEC|NOTE_TRACK|NOTE_TRACKERR on all
the running processes. When process X dies, kernel will close kqueue
descriptor. The kq_lock is therefore destroyed - MTX_UNOWNED|MTX_CONTESTED.
Due to the above race, the other thread that is trying to deliver a knote() to
process X could panic in __mtx_lock_sleep() because it finds that lock is not
exclusively MTX_UNOWNED and tries to deref the owner of the lock (which is
NULL). Other api’s like knote_fork() could also run into this problem.
<2>fault virtual address = 0x3b0
<2>fault code = supervisor read data, page not present
<2>instruction pointer = 0x20:0x804169f6
<2>stack pointer = 0x28:0xfe011f1db9a0
<2>frame pointer = 0x28:0xfe011f1dba10
<2>code segment = base 0x0, limit 0xf, type 0x1b
<2> = DPL 0, pres 1, long 1, def32 0, gran 1
<2>processor eflags = interrupt enabled, resume, IOPL = 0
<2>current process = 9199 (rcp)
<2>trap number = 12
<2>panic: page fault
(kgdb) bt
#0 __curthread () at ./machine/pcpu.h:221
#1 doadump (textdump=1) at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_shutdown.c:313
#2 0x8042b93f in kern_reboot (howto=260)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_shutdown.c:381
#3 0x8042be9f in vpanic (fmt=, ap=)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_shutdown.c:792
#4 0x8042bee3 in panic (fmt=)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_shutdown.c:705
#5 0x80572b51 in trap_fatal (frame=, eva=)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/amd64/amd64/trap.c:841
#6 0x80572d44 in trap_pfault (frame=0xfe011f1db8f0,
usermode=)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/amd64/amd64/trap.c:691
#7 0x805724dc in trap (frame=0xfe011f1db8f0)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/amd64/amd64/trap.c:442
#8 0x8055a661 in calltrap ()
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/amd64/amd64/exception.S:236
#9 0x804169f6 in __mtx_lock_sleep (c=0xf8006ec00d18,
tid=18446735282413282656, opts=0, file=0x0, line=96)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_mutex.c:435
#10 0x803f5175 in knote (list=0xf80089f6c5c0, hint=2147483648,
lockflags=)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_event.c:2047
#11 0x803fa46a in exit1 (td=0xf8011de8a560, rval=,
signo=0)
at
/.amd/svl-engdata1vs1/occamdev/build/freebsd/stable_11/20180413.165755_fbsd-builder_stable_11.0.dc8ec62/src/sys/kern/kern_exit.c:515
#12 0x803f9b7d in sys_sys_exit (td=0xf8006ec00d00, uap=)
at
