Date: Wed, 18 Mar 2026 15:49:28 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293382] Dead lock and kernel crash around closefp_impl Message-ID: <bug-293382-227-C4wIeMpsk6@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-293382-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382 --- Comment #20 from Kyle Evans <kevans@freebsd.org> --- re: deadlock, I don't really understand this part of knote_fdclose: we set influx=0 at the beginning and only `wakuep(kq)` if we personally dropped a knote from this kq. Isn't that just asking for a deadlock on the first knote? Assuming we have something like: Thread A: kn_enter_flux, drop the lock Thread B: pick up the lock, find it in flux, enter FLUXWQAIT Thread C: knote_fdclose(), acquire lock, also find it in flux, doesn't wakeup() Looking closer, I can kind of see that the pattern should be that thread A will wakeup() after a kn_leave_flux(), but I think we only have one scenario where that's *not* the case: kqueue_fork_copy() -> kqueue_fork_copy_list() will transition a number of knotes and neither would issue a wakeup(). The final KQ_UNLOCK there in kqueue_fork_copy() should probably just assume that it transitioned at least one knote through a flux state and switch to KQ_UNLOCK_FLUX to be sure. I think with those bases covered, influx + wakeup in knote_fdclose() should probably just go away. knote_drop will already wakeup any waiters after its removed the knote it transitioned from the list- another wakeup seems spurious. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293382-227-C4wIeMpsk6>