Date: Thu, 19 Apr 2001 10:23:39 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> 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 Message-ID: <Pine.BSF.4.21.0104190948400.5211-100000@besplex.bde.org> In-Reply-To: <XFMail.010418154213.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0104190948400.5211-100000>