From owner-freebsd-hackers Mon Sep 24 16:49: 5 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id C760037B421 for ; Mon, 24 Sep 2001 16:48:58 -0700 (PDT) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 25 Sep 2001 00:48:57 +0100 (BST) To: Matt Dillon Cc: Julian Elischer , hackers@freebsd.org Subject: Re: VM Corruption - stumped, anyone have any ideas? In-Reply-To: Your message of "Mon, 24 Sep 2001 16:22:36 PDT." <200109242322.f8ONMaT97469@earth.backplane.com> Date: Tue, 25 Sep 2001 00:48:57 +0100 From: Ian Dowse Message-ID: <200109250048.aa97220@salmon.maths.tcd.ie> 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 In message <200109242322.f8ONMaT97469@earth.backplane.com>, Matt Dillon writes: > > Hmm. Do we have a guard page at the base of the per process kernel > stack? As I understand it, no. In RELENG_4 there are UPAGES (== 2 on i386) pages of per-process kernel state at p->p_addr. The stack grows down from the top, and struct user (sys/user.h) sits at the bottom. According to the comment in the definition of struct user, only the first three items in struct user are valid in normal running conditions: 8192 ??? 8176 <---- Top of stack stack space (4672 bytes) 3504 struct timeval p_start struct uprof p_prof struct itimerval p_timer[ITIMER_PROF] (for SIGPROF) struct itimerval p_timer[ITIMER_VIRTUAL] struct itimerval p_timer[ITIMER_REAL] struct rusage p_cru; struct rusage p_ru; u_stats 3280 u_sigacts 608 u_pcb 0 <---- p->p_addr So if the stack does overflow, p_timer[ITIMER_PROF] is about the first noticable thing that gets clobbered, causing a SIGPROF signal delivery to the process some time later. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message