From owner-cvs-all Wed Apr 18 14:53:20 2001 Delivered-To: cvs-all@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D8E5037B43C; Wed, 18 Apr 2001 14:53:05 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.2/8.11.2) with ESMTP id f3ILofG59964; Wed, 18 Apr 2001 14:50:41 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 18 Apr 2001 14:50:05 -0700 (PDT) From: John Baldwin To: Doug Rabson Subject: Re: cvs commit: src/sys/alpha/alpha exception.s Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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: >> > >> >> >> >> 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. Hrm. Ok. That explains why I still get sig 11's. I'll try your other patch in a second. Also, I've diked out the IPL check in exception.s. If we are returning to usermode, then the IPL should already be 0, so no sense in checking it. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message