Date: Sat, 02 Jul 2022 17:21:07 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 264867] kevent EVFILT_TIMER, timer expiration with twice the period Message-ID: <bug-264867-227-HpWOVSddnd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-264867-227@https.bugs.freebsd.org/bugzilla/> References: <bug-264867-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=3D264867 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |markj@FreeBSD.org --- Comment #16 from Mark Johnston <markj@FreeBSD.org> --- Ok, I'm still able to reproduce the problem with my patch. But, the freque= ncy of the late wakeups is much much lower, and I'm fairly sure that the patch solves a legitimate problem on its own. Specifically, getnextcpuevent() contains the following bit of code: /* Handle callout events. */ if (event > state->nextcall) event =3D state->nextcall; It gets called when a CPU goes idle, and the idle thread is scheduling the = next timer interrupt. "nextcall" is not volatile, and interrupts are enabled, so state->nextcall can be modified between the check and the load, and the CPU will end up using a stale value. It might be that there is another, similar race in handleevents(), since a different CPU might be updating state->nextcall concurrently. But I think = the race is harmless since callout_process() should be able to find the next callout... --=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-264867-227-HpWOVSddnd>