Date: Tue, 24 May 2022 21:10:04 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 258412] kevent EVFILT_TIMER, EV_DISPATCH lost if event is re-enabled Message-ID: <bug-258412-227-dXP66ccIUh@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-258412-227@https.bugs.freebsd.org/bugzilla/> References: <bug-258412-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=3D258412 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org Status|New |Open --- Comment #2 from Mark Johnston <markj@FreeBSD.org> --- Thanks for the report and the pointer to the updated libkqueue tests. I'm sorry this didn't get any attention sooner. I ported three new timer tests to our in-tree copy of the libkqueue test su= ite, periodic_modify, periodic_to_oneshot, and dispatch. They found a couple of kernel bugs unrelated to the one that you described. Looking at our documentation, it's not obvious to me that FreeBSD's behavio= ur in the dispatch test is incorrect. With a periodic timer, EV_DISPATCH masks the knote after its state is retrieved by kqueue(), but the timer continues= to fire and we continue to count events. So when the timer filter is unmasked with EV_ENABLE | EV_DISPATCH, the knote is immediately activated. That see= ms consistent with my reading of the documentation. > The above step fails on FreeBSD 13, we get one event with the data field = set to 1. I would expect this to be 2 =3D 500ms / 200ms. That itself is a kernel bug= which I have a patch for. > Adding EV_ADD to the call re-enabling the timer does nothing, as does onl= y passing EV_ENABLE. In fact, adding EV_ADD fixes the test for me on FreeBSD. That also seems to make sense, since EV_ADD causes the timer state to be reset, throwing away timer firings that occurred while the knote was masked. So, I'm not sure what to do here. I spent some time looking at the XNU sou= rces to better understand what macos is doing but don't quite understand their t= imer state machine yet. --=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-258412-227-dXP66ccIUh>