callout(9) and Giant lock

[Robert Watson]

On Sun, 28 Jun 2009, Sebastian Huber wrote:

> suppose that a certain time event triggered several callout functions. What 
> happens if the first of these callout functions blocks on the Giant lock? 
> Does this delay all further callout functions until the Giant lock is 
> available for the first callout function? What happens if one of the callout 
> function blocks forever? Does this deadlock the system?

Callouts are marked as MPSAFE or non-MPSAFE when registered.  If non-MPSAFE, 
we will acquire Giant automatically for the callout, but I believe we'll also 
try and sort non-MPSAFE callouts behind MPSAFE ones in execution order to 
minimize latency for MPSAFE callouts.  Most callouts acquire locks of some 
sort, and stalling any callout indefinitely will stall the entire callout 
thread indefinitely, which in turn could lead to a variety of odd behaviors 
and potentially (although not necessarily) deadlock.

In general, we do not allow callouts to "block", however, in the sense that 
with INVARIANTS enabled we will actually panic if a callout tries to call 
msleep() or related functions.  Likewise, if another thread sleeps while 
holding Giant, it will automatically release it when it sleeps.

Relatively few kernel subsystems use Giant at this point, FYI, and even fewer 
in FreeBSD 8.  One of our goals for FreeBSD 9 is to eliminate all last 
remaining references to the Giant lock in the kernel.

Robert N M Watson
Computer Laboratory
University of Cambridge