In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
