From keramida@ceid.upatras.gr  Tue Dec 28 23:30:43 2004
Return-Path: <keramida@ceid.upatras.gr>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7427D16A4CE; Tue, 28 Dec 2004 23:30:43 +0000 (GMT)
Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 91BFE43D2D; Tue, 28 Dec 2004 23:30:41 +0000 (GMT)
	(envelope-from keramida@ceid.upatras.gr)
Received: from gothmog.gr (patr530-a152.otenet.gr [212.205.215.152])
	by kane.otenet.gr (8.13.2/8.13.2/Debian-OTEnet-2) with ESMTP id iBSNUccH003373;
	Wed, 29 Dec 2004 01:30:39 +0200
Received: from gothmog.gr (gothmog [127.0.0.1])
	by gothmog.gr (8.13.1/8.13.1) with ESMTP id iBSNUaJ9001076;
	Wed, 29 Dec 2004 01:30:36 +0200 (EET)
	(envelope-from keramida@ceid.upatras.gr)
Received: (from giorgos@localhost)
	by gothmog.gr (8.13.1/8.13.1/Submit) id iBSNTH01001045;
	Wed, 29 Dec 2004 01:29:17 +0200 (EET)
	(envelope-from keramida@ceid.upatras.gr)
Message-Id: <20041228232917.GA749@gothmog.gr>
Date: Wed, 29 Dec 2004 01:29:17 +0200
From: Giorgos Keramidas <keramida@ceid.upatras.gr>
To: Darren Reed <darrenr@FreeBSD.ORG>
Cc: bug-followup@FreeBSD.ORG
In-Reply-To: <20041228135534.F30B916A4CF@hub.freebsd.org>
Subject: Re: man page for sx(9) is misleading
References: <20041228135534.F30B916A4CF@hub.freebsd.org>

>Number:         75587
>Category:       docs
>Synopsis:       Re: man page for sx(9) is misleading
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gnats-admin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 28 23:40:20 GMT 2004
>Closed-Date:    Wed Dec 29 08:32:48 GMT 2004
>Last-Modified:  Fri Sep 02 00:10:34 GMT 2005
>Originator:     
>Release:        
>Organization:
>Environment:
>Description:
 On 2004-12-28 13:55, Darren Reed <darrenr@FreeBSD.ORG> wrote:
 >
 > According to discussion on freebsd mailing lists, it is not possible
 > to hold an sx lock when you want a mtx lock.  This should be documented.
 
 As far as I can tell, by looking at kern_sx.c and sys/sx.h, this is
 because the sx lock initialization uses an mtxpool for the mutex used to
 serialize access to the internal sx lock data.
 
 Leaf locks may be used in operations that msleep() but there can be only
 one of them in each lock path and no other lock can be obtained after
 them.
 
 This is sort of implied by the SEE ALSO reference of mtx_pool(9), but we
 should probably state it explicitly in CONTEXT.
 
 %%%
 Index: sx.9
 ===================================================================
 RCS file: /home/ncvs/src/share/man/man9/sx.9,v
 retrieving revision 1.29
 diff -u -r1.29 sx.9
 --- sx.9        11 Jul 2004 16:08:25 -0000      1.29
 +++ sx.9        28 Dec 2004 23:28:22 -0000
 @@ -196,6 +196,11 @@
  A thread may hold a shared or exclusive lock on an
  .Nm
  lock while sleeping.
 +The
 +.Nm
 +locks are implemented using
 +.Xr mtxpool 9
 +shared leaf locks, so they should always be the last lock obtained.
  .Sh SEE ALSO
  .Xr condvar 9 ,
  .Xr mtx_pool 9 ,
 %%%
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: keramida 
State-Changed-When: Wed Dec 29 08:32:28 GMT 2004 
State-Changed-Why:  
Followup to docs/75571, misfiled as a new PR. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=75587 
>Unformatted:
