Date: Fri, 11 Jan 2002 13:26:15 -0800 From: Skye Poier <skye@ffwd.cx> To: FreeBSD 31337 H4X0RZ <freebsd-hackers@freebsd.org> Subject: Possible problem with timeouts? Message-ID: <20020111132615.A36583@ffwd.cx>
next in thread | raw e-mail | index | archive | help
Hello Hackers,
While doing an audit of the timer code in FreeBSD's kernel one of our
developers came across a theoretical bug and I thought I'd run it by the
gurus on this list before we hack around it.
It seems that it is possible to call untimeout and then have your timer
called immediately thereafter. However, we haven't actually seen this in
practice, this is a theoretical bug. If this is indeed the case, it will
break lots of our code (misunderstood semantics..)
If you look at softclock, you will see that the callout_lock mutex is
released after we have decided on the callback to call next, but right
before we actually call it. Theoretically, the following seems possible:
callout thread our kern thread
-------------- ---------------
acquire Giant
try to acquire callout_lock
choose callout
release callout_lock
try to acquire Giant
remove callout
release callout_lock
release Giant
untimeout returns
caller removes resource callout needs
acquire Giant
call callout
BIG TROUBLE FOR MOOSE
AND SQUIRREL
With these semantics, things get severely broken, because there's no
reliable way to clean up after timeouts except to just never call
untimeout and have the timeouts themselves realize they have been
cancelled.
Now, its possible that this has been fixed since we took a snapshot of
-current way back around Feb/Mar 2001.
If anyone has some insight into this it would be much appreciated. I
have a second question around softclock but I'll save it for later..
Thanks,
Skye Poier
--
"Natural Gas. It sure gives you some ideas!" - Space Ghost
[ www.ffwd.cx ] ffwd internet division
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020111132615.A36583>