From owner-cvs-all Wed Apr 18 13:49:38 2001 Delivered-To: cvs-all@freebsd.org Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by hub.freebsd.org (Postfix) with ESMTP id F06B937B424; Wed, 18 Apr 2001 13:49:30 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 14pytF-0009A8-0C; Wed, 18 Apr 2001 20:49:30 +0000 Received: from salmon.nlsystems.com (salmon [10.0.0.3]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id f3IKmE787503; Wed, 18 Apr 2001 21:48:14 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Wed, 18 Apr 2001 21:48:14 +0100 (BST) From: Doug Rabson To: John Baldwin Cc: , Subject: Re: cvs commit: src/sys/alpha/alpha exception.s In-Reply-To: Message-ID: 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 Doug Rabson wrote: > > On Wed, 18 Apr 2001, John Baldwin wrote: > > > >> > >> On 18-Apr-01 Doug Rabson wrote: > >> > On Wed, 18 Apr 2001, John Baldwin wrote: > >> > > >> >> jhb 2001/04/18 10:17:55 PDT > >> >> > >> >> Modified files: > >> >> sys/alpha/alpha exception.s > >> >> Log: > >> >> Back out the previous revision as it causes random sig 11's to userland > >> >> processes until a better fix is found. > >> > > >> > I can see several possible races here. For instance, if an interrupt > >> > happened partway through restoring registers trying to return to userland, > >> > we could corrupt the user's t7 pretty easily. > >> > > >> > I can't quite think of the correct solution yet though. > >> > >> Oh, we share the same stack frame for user and kernel returns? Oh yuck. > >> I can hack around that by raising the IPL in Lkernelret before changing t7, > >> but > >> if we use the same stackframe how do interrupts in the kernel work at all > >> w/o > >> trashing the user frame? > > > > Of course we have to use the kernel stack for all exceptions. The user > > stack might not even be a valid virtual address. We could raise the IPL > > before saving or restoring but it just seems like such a hack. I still > > haven't thought of a better fix though. > > Ok, I've read more of exception.s and my head feels better, sort of. The > problem with t7 being that we might get an interrupt after we restore the > registers and thus we trash the t7 right before the rti PAL call? Hmmm. > I think we only need to raise the IPL just before we do the bsr to > exception_restore_regs(), so it would only be raised for the length of the > register restore and the call_pal. I wonder if x86 has the same race condition > with %fs. We might need to be doing a 'cli' in doreti_exit just before we pop > %fs. This is not enough. There is an equivalent race when saving the registers. Also we can't raise IPL without trashing registers which adds to our problems. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message