Nearly every kernel mode developer will tell you that page faults processing is impossible when a scheduling is not allowed, for example when IRQL >= DISPATCH_LEVEL on Windows or preemption is not allowed on Linux or 64 bit Mac OS X. So the page fault handler should not be called in this cases. Right? Wrong. There is a special type of page fault that is accepted and processed at any IRQL in Windows and with disabled preemption on Linux - this is a fault taken when a root page directory table(PDT) entry does not exist for a memory accessed when a scheduler is disabled.
Just imagine what happens when one process allocates some virtual memory that results in updates to upper half of PDT ( where kernel lives ), locks ( wires ) the memory and somehow passes a pointer to an ISR ( interrupt service routine ) that being called in the context of another process ( and may be on another CPU ) and this ISR tries to access this memory . In that case the page fault handler updates PDT for another process by coping the entry from the "System" PDT. Simple !
Some relevant illustration on Linux kernel page fault processing implementation can be found here http://www.utdallas.edu/~zhiqiang.lin/spring2012/public/lec11-handout.pdf , I've just borrowed the two most interesting
- Page table fixing :
- Control flow for the page fault handler :
Some relevant illustration on Linux kernel page fault processing implementation can be found here http://www.utdallas.edu/~zhiqiang.lin/spring2012/public/lec11-handout.pdf , I've just borrowed the two most interesting
- Page table fixing :
- Control flow for the page fault handler :
