From owner-freebsd-hackers Tue Sep 25 15:52:42 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from warspite.cnchost.com (warspite.concentric.net [207.155.248.9]) by hub.freebsd.org (Postfix) with ESMTP id 95A1637B401 for ; Tue, 25 Sep 2001 15:52:38 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by warspite.cnchost.com id MAA18919; Tue, 25 Sep 2001 12:10:30 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200109251610.MAA18919@warspite.cnchost.com> To: Bernd Walter Cc: hackers@FreeBSD.ORG Subject: Re: VM Corruption - stumped, anyone have any ideas? In-reply-to: Your message of "Tue, 25 Sep 2001 09:56:07 +0200." <20010925095607.B27615@cicely20.cicely.de> Date: Tue, 25 Sep 2001 09:10:21 -0700 From: Bakul Shah Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > FWIW, in a Unix port we did I remember putting the user > > struct *above* the kernel stack. The stack grew down so you > > hit the red zone (the guard pages) without clobbering the > > user struct. Since struct user _ended_ on a page boundary, > > its size was needed at locore.s assembly time but that was a > > small price to pay for the added safety. > > I don't think a guard page can help here, because the page fault > handler needs a working stack. You can't continue if you run out of the stack in any case but the issue is what happens when you run off the end of the stack. In the FreeBSD case you trash the user struct and discover this problem in a very indirect way and possibly after trashing god-knows-what-else. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message