From 745b4d68dc76ac7091bf07827d641fa4d2b07648 Mon Sep 17 00:00:00 2001 From: Godmar Back Date: Wed, 1 Nov 2006 00:00:42 +0000 Subject: [PATCH] corrected wrong statement about content of f->esp when page fault occurs in kernel mode. See [IA32-v3a], figure 5.4 in section 5.12.1.1. --- doc/vm.texi | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/doc/vm.texi b/doc/vm.texi index cf4f764..3210bbc 100644 --- a/doc/vm.texi +++ b/doc/vm.texi @@ -582,11 +582,13 @@ by a user program, you can retrieve it from @code{esp} member of the accessing them (@pxref{Accessing User Memory}), these are the only cases you need to handle. On the other hand, if you depend on page faults to detect invalid memory access, you will need to handle another case, -where a page fault occurs in the kernel. Reading @code{esp} out of the -@struct{intr_frame} passed to @func{page_fault} in that case will obtain -the kernel stack pointer, not the user stack pointer. You will need to -arrange another way, e.g.@: by saving @code{esp} into @struct{thread} on -the initial transition from user to kernel mode. +where a page fault occurs in the kernel. Since the processor only +saves the stack pointer when an exception causes a switch from user +to kernel mode, reading @code{esp} out of the @struct{intr_frame} +passed to @func{page_fault} would yield an undefined value, not the +user stack pointer. You will need to arrange another way, such as +saving @code{esp} into @struct{thread} on the initial transition +from user to kernel mode. You may impose some absolute limit on stack size, as do most OSes. Some OSes make the limit user-adjustable, e.g.@: with the -- 2.30.2