Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Feb 2010 17:02:06 +0000 (UTC)
From:      Edward Tomasz Napierala <trasz@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   svn commit: r203759 - head/share/man/man9
Message-ID:  <201002101702.o1AH26HA052465@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: trasz
Date: Wed Feb 10 17:02:06 2010
New Revision: 203759
URL: http://svn.freebsd.org/changeset/base/203759

Log:
  Improve description for Giant and mention blocking inside interrupt threads.

Modified:
  head/share/man/man9/locking.9

Modified: head/share/man/man9/locking.9
==============================================================================
--- head/share/man/man9/locking.9	Wed Feb 10 16:30:04 2010	(r203758)
+++ head/share/man/man9/locking.9	Wed Feb 10 17:02:06 2010	(r203759)
@@ -24,7 +24,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd January 29, 2010
+.Dd February 10, 2010
 .Dt LOCKING 9
 .Os
 .Sh NAME
@@ -191,13 +191,16 @@ Giant is an instance of a mutex, with so
 .It
 It is recursive.
 .It
-Drivers can request that Giant be locked around them, but this is
-going away.
-.It
-You can sleep while it has recursed, but other recursive locks cannot.
+Drivers and filesystems can request that Giant be locked around them
+by not marking themselves MPSAFE.  Note that infrastructure to do this
+is slowly going away as non-MPSAFE drivers either became properly locked
+or disappear.
 .It
 Giant must be locked first before other locks.
 .It
+It is OK to hold Giant while performing unbounded sleep; in such case,
+Giant will be dropped before sleeping and picked up after wakeup.
+.It
 There are places in the kernel that drop Giant and pick it back up
 again.
 Sleep locks will do this before sleeping.
@@ -315,6 +318,9 @@ If any caller above you has any mutex or
 rwlock, your sleep, will cause a panic.
 If the sleep only happens rarely it may be years before the 
 bad code path is found.
+.Pp
+It is an error to do any operation that could result in unbounded sleep when
+running inside an interrupt thread.
 .Ss Interaction table
 The following table shows what you can and can not do if you hold
 one of the synchronization primitives discussed here:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201002101702.o1AH26HA052465>