https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382
--- Comment #20 from Kyle Evans <[email protected]> --- 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.
