Date: Fri, 23 Nov 2018 21:22:59 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 228858] panic when delivering knote to a process who has opened a kqueue() is dying Message-ID: <bug-228858-227-egz4gVPUGV@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-228858-227@https.bugs.freebsd.org/bugzilla/> References: <bug-228858-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228858 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |markj@FreeBSD.org Status|New |In Progress --- Comment #2 from Mark Johnston <markj@FreeBSD.org> --- The process closing the kqueue should drain all of the kqueue's notes; this happens in kqueue_drain(). Unfortunately, we have a few races: - kqueue_register() doesn't check for KQ_CLOSING, so it may add knotes to t= he fdtable or hash table after we've started draining. This can be triggered = by knote_fork(). - The locking in knote_fork() is wrong: at the end of the loop we should be acquiring the list lock before the kqueue lock. Otherwise there's a window where the knote is unlocked and not in flux, and thus may be freed. To fix this I believe it's sufficient to just reorder the locking; the list lock c= omes before the kqueue lock in the lock order. The in-flux state of the knote is sufficient to prevent it from being removed, I believe, so we don't need a marker knote to hold our place in the list. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-228858-227-egz4gVPUGV>