From owner-freebsd-current  Mon Aug  7 13: 2:46 2000
Delivered-To: freebsd-current@freebsd.org
Received: from earth.backplane.com (placeholder-dcat-1076843290.broadbandoffice.net [64.47.83.26])
	by hub.freebsd.org (Postfix) with ESMTP
	id 4FF9337BEDE; Mon,  7 Aug 2000 13:02:40 -0700 (PDT)
	(envelope-from dillon@earth.backplane.com)
Received: (from dillon@localhost)
	by earth.backplane.com (8.9.3/8.9.3) id NAA38592;
	Mon, 7 Aug 2000 13:02:37 -0700 (PDT)
	(envelope-from dillon)
Date: Mon, 7 Aug 2000 13:02:37 -0700 (PDT)
From: Matt Dillon <dillon@earth.backplane.com>
Message-Id: <200008072002.NAA38592@earth.backplane.com>
To: David Greenman <dg@root.com>
Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>,
	Alfred Perlstein <bright@wintelcom.net>,
	Mike Smith <msmith@FreeBSD.ORG>, Stephen McKay <mckay@thehub.com.au>,
	freebsd-current@FreeBSD.ORG, dillon@FreeBSD.ORG
Subject: Re: Ugly, slow shutdown 
References:  <200008071903.MAA03649@implode.root.com>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

    Just a quick perusal of the kernel code shows a number of possible
    unexpected side effects from unexpected wakeups.  I see several places
    where a 'WANTED' flag is set in a loop waiting for something and assumed
    to be cleared after the tsleep() returns.   Some of these side effects
    are quite persistent.  For example, if PG_WANTED is set in a page the
    VM system will activate the page rather then deactivate it.  An unexpected
    wakeup in the VM system could lead to a page with PG_WANTED *LEFT* *SET*
    on the page!  It might not be fatal, but it sure isn't the type of
    operation we want!

    There are a couple of places in the NFS code where a sleep wakeup
    results in a retry.  There is a place where LC_EXPIREDWANTED is 
    checked and causes a whole sequence of conditionals to be skipped.

    This is after 5 minutes of searching.  I'm not going to spend N hours
    trying to find every case.  Just finding two in 5 minutes is enough
    proof for me that it's just too dangerous to go and change expected
    tsleep/wakeup semantics without going through and auditing and
    documenting every piece of code that uses tsleep/wakeup.

						-Matt




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