# kernel space vs user space memory doubt



## fluca1978 (Jul 31, 2013)

Sometimes this puzzles me: suppose a 32 bit architecture. The kernel is assigned the last gigabyte of virtual addressing, and the user space has the first three gigabytes. One advantage of this is that process switch does not invalidate the kernel memory mapping, right? This also means that a context switch does not move the kernel around, that is the kernel memory can be considered resident (not meaning wired). If this is right, what happens if the kernel switches within a kernel path? That is the kernel is serving a syscal and an interrupt arrives, therefore the kernel is executing with some data of the user (syscal) process and interrupts within the same space?
I have a fog in my mind...


----------



## throAU (Aug 1, 2013)

I *believe* that whilst servicing an interrupt, lower priority interrupts are disabled, and user level interrupts are lower priority than the kernel, and thus held off until the kernel completes.


Disclaimer:  
I haven't done any interrupt programming for about 20 years and even back then it was only a keyboard interrupt handler for DOS.  But one of the first things in the handler was to disable interrupts until I was done.  There's no point in interrupting the kernel to do something else when it is already trying to service an interrupt, unless the new interrupt is higher priority.

I haven't done a lot of low level interrupt programming on x86, and especially not i386 or later, but this sort of thing is why you have various CPU modes like (on 680x0) user mode and supervisor mode. Interrupts, etc. from user mode are lower priority.


----------



## xibo (Aug 3, 2013)

Depending on what part of the interrupt handling routine is being active the userspace of the process that was interrupted might not be accessible.
Generally supported CPUs have Advanced Programmable Interrupt Controllers (APIC) which can queue (or drop) interrupts in whatever order the OS sees it fit. Once an hardware interrupt has occured (or was forwarded by the APIC), it's interrupt handler will try to obtain a copy of any relevant data associated with that interrupt and push it on a work-queue (which resides in kernel address space) for some software interrupt handlers to handle later. After having pushed the data onto the work-queue, the hardware interrupt handler resumes execution of the interrupted proccess (in some events, it calls the scheduler instead).
A software interrupt handler might cause a scheduler run (or cause a hardware interrupt) instead of returning to the interrupted process.

Memory Mappings are process bound and the softint handler is AFAIK considered a proccess from the process and memory management point of view, therefore it can only access it's local kernel resources on top of the current process ones. A Pentium 3/4/D/M as well as any Core-i or Xeon (including Pentium Pro) and most of the AMD chips released in the last decade can address more than 4GB RAM while in 32 mode using physical address extensions (PAE). Nevertheless a single proccess running in 32-bit mode can never address more than 4 GB of memory at any time due to the address registers being limited. To address a different memory region (or range composition) the kernel's memory manager needs to reprogramm the MMU, which invalidates all previously active virtual<->physical mappings.

EDIT:
A process can never invalidate kernel resources unless the kernel allows this to the process. Nor can a process compromize or corrupt memory of other processes. In both cases, when a memory access is made, the CPU's integrated Translation Lookup Buffer (TLB) which only has limited size is checked. If the accessed memory page is "known" to the TLB, the address is permuted by it's TLB entry and the permutated value is used to handle the physical access. If the page is not in the TLB, the Memory Management Unit (MMU) issues a hardware interrupt called page fault, which causes the same-called kernel-routine to lookup the physical page corresponding to the virtual address of any segments allocated by the process. If a segment containing the virtual mapping is found, the corresponding entry is setup into the TLB (eventually after having been loaded from the file system or swap space) with some flags like Read-Only (e.g. to page-fault on write access and do a Copy-on-Write operation) or Not-Executable (for Data, mostly a security thing) and return to the process where the memory access is re-requested. If no segment containing the virtual mapping is found, the handler returns to the issuing proccess, just that it returns to the signal handler for the Segmentation Fault event, which about always ends up with "Segmentation Fault." being written onto stderr and the proccess aborting 

By using this technique the kernel can granulate memory access on page (256 Bytes-Sequence in 32-bit mode) level, allow "load-on-demand" of any programm code, shared memory and context sharing (with and without copy-on-write) by assigning the same physical page to two or more processes or memory locking (by assigning the corresponding pages as inaccessible for any other proccess), efficient swapping (since the kernel keeps track of which pages are asked for at what regularity and swaps those least asked for) and of cause allocate-on-demand (malloc of 2GB data takes just a few cycles since the real allocation is done only when you actually access the memory).


----------

