From owner-freebsd-hackers@FreeBSD.ORG  Wed Nov  2 20:29:21 2005
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: freebsd-hackers@freebsd.org
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 83B5416A41F
	for <freebsd-hackers@freebsd.org>; Wed,  2 Nov 2005 20:29:21 +0000 (GMT)
	(envelope-from imp@bsdimp.com)
Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0BC6443D48
	for <freebsd-hackers@freebsd.org>; Wed,  2 Nov 2005 20:29:20 +0000 (GMT)
	(envelope-from imp@bsdimp.com)
Received: from localhost (localhost.village.org [127.0.0.1] (may be forged))
	by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jA2KQrA0038934;
	Wed, 2 Nov 2005 13:26:53 -0700 (MST) (envelope-from imp@bsdimp.com)
Date: Wed, 02 Nov 2005 13:27:09 -0700 (MST)
Message-Id: <20051102.132709.101593999.imp@bsdimp.com>
To: julian@elischer.org
From: "M. Warner Losh" <imp@bsdimp.com>
In-Reply-To: <43690EED.10703@elischer.org>
References: <20051027.205250.55834228.imp@bsdimp.com>
	<43690424.1040904@alphaque.com> <43690EED.10703@elischer.org>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0
	(harmony.bsdimp.com [127.0.0.1]);
	Wed, 02 Nov 2005 13:26:54 -0700 (MST)
Cc: freebsd-hackers@freebsd.org
Subject: Re: locking in a device driver
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2005 20:29:21 -0000

In message: <43690EED.10703@elischer.org>
            Julian Elischer <julian@elischer.org> writes:
: Dinesh Nair wrote:
: 
: >
: >
: > On 10/28/05 10:52 M. Warner Losh said the following:
: >
: >> libc_r will block all other threads in the application while an ioctl
: >> executes.  libpthread and libthr won't.  I've had several bugs at work
: >
: >
: > so if the userland thread does an ioctl, and the the driver goes to 
: > tsleep() when the ioctl is received, all other threads are also 
: > blocked from executing, i.e wont be context switched to run ?
: 
: in 4.x and earlier. a tsleep saves your spl level but re-enables the 
: interrupts (from memory)
: when you re-awaken you are given your spl level again.. 

That's true, but irrelevant.

: All other threads are allowed to run.

That is not true.[*] *NO* other threads in your process run.  Period.
None.  Zero.  Nada.  Zilch.  Your process is hung until the ioctl
returns.  That's the fundamental problem with userland thread packages
such as libc_r.

I've had to work around this issue many times, and I'm 100% certain
that this is the case: sleep in an ioctl, and the entire process hangs
until the ioctl returns.

Warner

[*] Other processes on the system will run, true.  Interrutps will
happen and run.  But that's not what was being ask.