Date: Tue, 25 Sep 2001 00:48:57 +0100 From: Ian Dowse <iedowse@maths.tcd.ie> To: Matt Dillon <dillon@earth.backplane.com> Cc: Julian Elischer <julian@elischer.org>, hackers@freebsd.org Subject: Re: VM Corruption - stumped, anyone have any ideas? Message-ID: <200109250048.aa97220@salmon.maths.tcd.ie> In-Reply-To: Your message of "Mon, 24 Sep 2001 16:22:36 PDT." <200109242322.f8ONMaT97469@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200109250048.aa97220>