Date: Sat, 22 Mar 2008 07:29:45 +0000 (UTC) From: Alfred Perlstein <alfred@FreeBSD.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/kern kern_timeout.c Message-ID: <200803220729.m2M7TjaK026470@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
alfred 2008-03-22 07:29:45 UTC
FreeBSD src repository
Modified files:
sys/kern kern_timeout.c
Log:
Fix a race where timeout/untimeout could cause crashes for Giant locked
code.
The bug:
There exists a race condition for timeout/untimeout(9) due to the
way that the softclock thread dequeues timeouts.
The softclock thread sets the c_func and c_arg of the callout to
NULL while holding the callout lock but not Giant. It then drops
the callout lock and acquires Giant.
It is at this point where untimeout(9) on another cpu/thread could
be called.
Since c_arg and c_func are cleared, untimeout(9) does not touch the
callout and returns as if the callout is canceled.
The softclock then tries to acquire Giant and likely blocks due to
the other cpu/thread holding it.
The other cpu/thread then likely deallocates the backing store that
c_arg points to and finishes working and hence drops Giant.
Softclock resumes and acquires giant and calls the function with
the now free'd c_arg and we have corruption/crash.
The fix:
We need to track curr_callout even for timeout(9) (LOCAL_ALLOC)
callouts. We need to free the callout after the softclock processes
it to deal with the race here.
Obtained from: Juniper Networks, iedowse
Reviewed by: jhb, iedowse
MFC After: 2 weeks.
Revision Changes Path
1.111 +19 -4 src/sys/kern/kern_timeout.c
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200803220729.m2M7TjaK026470>