From owner-cvs-all  Wed Apr 18 17:24:52 2001
Delivered-To: cvs-all@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id B734037B422; Wed, 18 Apr 2001 17:24:46 -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 KAA23802;
	Thu, 19 Apr 2001 10:24:43 +1000
Date: Thu, 19 Apr 2001 10:23:39 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: John Baldwin <jhb@FreeBSD.org>
Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org,
	Doug Rabson <dfr@nlsystems.com>
Subject: Re: cvs commit: src/sys/alpha/alpha exception.s
In-Reply-To: <XFMail.010418154213.jhb@FreeBSD.org>
Message-ID: <Pine.BSF.4.21.0104190948400.5211-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Wed, 18 Apr 2001, John Baldwin wrote:

> On 18-Apr-01 Bruce Evans wrote:
> > OTOH, it is a bug that interrupts sometimes aren't already disabled
> > when doreti_exit is reached.  ASTs must be checked for atomically with
> > returning, like they used to be, so that we never return to user mode
> > with an AST pending.
> 
> ast() probably should disable interrupts when it returns and it probably
> doesn't.

It also needs to loop to check for new ASTs.  Something like:

	for (;;) {
		aquire sched_lock	// no change
		// but don't need sched_lock yet, could use critical_enter()
		if (nothing to do) {
			arrange for interrupts to be disabled atomically \
			    with release of sched_lock
			release sched_lock
			return
		}
		...
		release sched_lock
		userret(...);
		release Giant if held
	}

I think astpending() and resched_wanted() should be checked in ipl.s
like they used to be (resched_wanted() at least used to imply
astpending(), so only astpending() needed to be checked).  It's not
quite true that aquiring and releasing mutexes in assembly is not fun
(the assembly can easily call a specialized C function), and anyway,
sched_lock is not required here for examining astpending().  Just
examine it with interrupts disabled.  If another CPU sets it while we
are examining it, then there will be an IPI to forward that setting,
and the IPI will be acked later.  ast() still needs to acquire sched_lock
for other reasons.

Bruce


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