From 0b0b48c06af49f49f82bbc874ad44a49a90db11a Mon Sep 17 00:00:00 2001 From: Edward Tomasz Napierala Date: Wed, 10 Feb 2010 17:02:06 +0000 Subject: [PATCH] Improve description for Giant and mention blocking inside interrupt threads. --- share/man/man9/locking.9 | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/share/man/man9/locking.9 b/share/man/man9/locking.9 index 280140c525e..7dd08092753 100644 --- a/share/man/man9/locking.9 +++ b/share/man/man9/locking.9 @@ -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 some special characteristics: .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: