callout(9) and Giant lock

[Sebastian Huber-4]

Hi,

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?

CU

--
Sebastian Huber, Embedded Brains GmbH

Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone   : [phone]
Fax     : [phone]
E-Mail  : sebastian.huber@...
PGP     : Public key available on request

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Robert N. M. 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
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[jhb-3]

On Sunday 28 June 2009 11:57:05 am Robert Watson wrote:

>
> 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.

FWIW, we do not actually sort the callouts in this manner, so all callouts
will be blocked until Giant is acquired.

--
John Baldwin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Robert N. M. Watson]

On 13 Jul 2009, at 19:17, John Baldwin wrote:

>> 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.
>
> FWIW, we do not actually sort the callouts in this manner, so all  
> callouts
> will be blocked until Giant is acquired.

I must have been remembering a proposed change -- as you say, it's  
certainly not in kern_timeout.c. However, I'd rather just eliminate  
support for Giant in callouts in 9.x than try to further facilitate  
them :-)

Robert
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[jhb-3]

On Monday 13 July 2009 2:49:24 pm Robert N. M. Watson wrote:

>
> On 13 Jul 2009, at 19:17, John Baldwin wrote:
>
> >> 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.
> >
> > FWIW, we do not actually sort the callouts in this manner, so all  
> > callouts
> > will be blocked until Giant is acquired.
>
> I must have been remembering a proposed change -- as you say, it's  
> certainly not in kern_timeout.c. However, I'd rather just eliminate  
> support for Giant in callouts in 9.x than try to further facilitate  
> them :-)

Agreed. :)

--
John Baldwin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."