From owner-cvs-all Thu Feb 22 11:48:58 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 23B4337B4EC; Thu, 22 Feb 2001 11:48:48 -0800 (PST) (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 f1MJkYl00728; Thu, 22 Feb 2001 11:46:34 -0800 (PST) (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: <200102221935.f1MJZLx89084@freefall.freebsd.org> Date: Thu, 22 Feb 2001 11:48:34 -0800 (PST) From: John Baldwin To: John Baldwin Subject: RE: cvs commit: src/sys/i386/i386 trap.c Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 22-Feb-01 John Baldwin wrote: > jhb 2001/02/22 11:35:21 PST > > Modified files: > sys/i386/i386 trap.c > Log: > The p_md.md_regs member of proc is used in signal handling to reference > the the original trapframe of the syscall, trap, or interrupt that entered > the kernel. Before SMPng, ast's were handled via a psuedo trap at the > end of doerti. With the SMPng commit, ast's were broken out into a > separate ast() function that was called from doreti to match the behavior > of other architectures. Unfortunately, when this was done, the > p_md.md_regs member of curproc was not updateda in ast(), thus when > signals are handled by userret() after an interrupt that returns to > userland, we end up using a stale trapframe that will result in the > registers from the old trapframe overwriting the real trapframe and > smashing all the registers right before we return to usermode. The saved > %cs:%eip from where we were in usermode are saved in the trapframe for > example. The breakage here could only occur if we had an interrupt to userland and that interrupt ended up sending a signal to the process. Actually, one realistic case this might have happended would be with teh SIGPROF and SIGVTALRM signals set by hardclock(). This could have manifested itself as programs exhibiting rather errant execution and very strange behavior. I'm not sure if this could have crashed the kernel itself or not. I'm not sure if this could have resulted in the stack pointer and/or the stack contents getting corrupted as it apparently seems to be happening for some people right now, but I would encourage anyone seeing weird bugs on x86 to try this out and see if it helps. :) -- 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