From owner-freebsd-current  Tue Jul 16 20:56:15 2002
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id E0B3337B400; Tue, 16 Jul 2002 20:56:11 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 1D3A843E5E; Tue, 16 Jul 2002 20:55:50 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id NAA16095;
	Wed, 17 Jul 2002 13:54:42 +1000
Date: Wed, 17 Jul 2002 13:58:25 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: John Baldwin <jhb@FreeBSD.org>
Cc: current@FreeBSD.org, Andrew Kolchoogin <andrew@snark.rinet.ru>,
	Andrew Gallatin <gallatin@cs.duke.edu>
Subject: Re: VOP_GETATTR panic on Alpha
In-Reply-To: <XFMail.20020716213951.jhb@FreeBSD.org>
Message-ID: <20020717134948.G3565-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-current.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-current>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-current>
X-Loop: FreeBSD.ORG

On Tue, 16 Jul 2002, John Baldwin wrote:

> On 17-Jul-2002 Bruce Evans wrote:
> >>         mtx_lock_spin(&sched_lock);
> >>         if (cold || panicstr) {
> >>                 /*
> >>                  * After a panic, or during autoconfiguration,
> >>                  * just give interrupts a chance, then just return;
> >                           ^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > This is the rotted comment.  No chance is given here.
>
> Well, when you unlock sched_lock you give ithreads a chance to run.  (This
> is only true in a fully preemptive kernel though.)

It now only releases the lock that it aquired.  splx(safepri) gave a
nesting-violating unlocking corresponding to releasing the caller(s)
locks.  However, it is probably a bug to call msleep() with sched_lock
held, so releasing sched_lock would release it completely but not give
interrupts any better chance than they had to begin with.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message