Race in kevent

[John Baldwin]

On 09-Jul-2003 Harti Brandt wrote:
> 
> Hi,
> 
> I just had a crash while typing ^C to a program that has a kevent timer
> running. The crash was:
> 
> callout_stop
> callout_reset
> filt_timerexpire
> softclock
> 
> and callout_stop was accessing freed memory (0xdeadc0e2). After looking
> some time at the filt_timerdetach, callout_stop and softclock I think the
> following happened:
> 
> 
> Proc 1                                  Proc 2
> ------                                  ------
> filt_timerdetach                      softclock called
> call with Giant locked
> 
>                                       lock_spin(callout_lock)
>                                       ...
> call callout_stop which hangs on
> lock_spin(callout_lock)
> 
>                                       sofclock finds the callout,
>                                       removes it from its queue and
>                                       clears PENDING
> 
>                                       unlock_spin(callout_lock)
>                                       lock(&Giant) blocks
> 
> callout_stop finds the callout to
> be not pending and returns
> 
> filt_timerdetach frees the callout
> 
> ...
> 
> unlock(&Giant)
>                                       softclock continues and calls
>                                       the (stopped) callout
> 
>                                       KABOOM because the pointer used
>                                       by filt_timerexpire is gone

This is becoming a common race unfortunately. :(  See the hacks in
msleep() that use TDF_TIMEOUT in coooperationg with endtsleep() and
the recent commit to the realtimer callout code for ways to work around
this race.

-- 

John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/