0

I'm trying to understand how page faults are handled by the OS kernel. The wikipedia article at https://en.wikipedia.org/wiki/Page_fault distinguishes between Minor, Major and Invalid page faults.

A major page fault is one where the virtual->real address mapping is not yet present in main memory, but the real address is present on disk, and for this page fault exception, the exception handler searches the disk and brings the page frame to main memory and does the virtual->real address mapping.

An invalid page fault is when an application tries to access an unmapped address, for example, a rogue pointer. The same page fault exception is raised, but the exception handler now decides to terminate the program, mostly with a Seg Fault (core dumped) error.

My question is, how does the kernel distinguish between these two types of page faults? I'd like the answer to go into a bit of depth about this, and hopefully link me to more elaborate articles if possible. Please ask me for any clarifications!

Thanks.

nirvanaswap
  • 859
  • 2
  • 11
  • 21
  • Removed the linux tag. I'd rather have the question answered on this page; for some reason a straightforward answer is hard to come by for this question... – nirvanaswap Jan 15 '16 at 18:25

2 Answers2

1

Grossly speaking, the kernel has some representation of the virtual address space of the (current) process. It knows for each segment of pages how to handle page faults for it. It works in physical addresses (so its address space is not the user-mode address space), but maintain some complex data structures to efficiently represent the mapping between virtual and physical addresses (if any) and configure the MMU according to these.

See for example Gorman's book understanding the Linux virtual memory manager (some details are probably outdated).

Read also about GNU Hurd external pager mechanism.

A page fault is given the relevant (physical and/or virtual) addresses at fault (e.g. by MMU hardware). See the paging web page of osdev, and read about page tables. The kernel handles all page faults (it gets the same hardware exception for every page faults, with data describing the fault - including faulting virtual address) and determine what kind of fault it is.

On Linux you could even handle (in a non-portable, ABI & processor specific manner) the SIGSEGV signal. (Hence the kernel has gathered all the information it is able to give to your SIGSEGV handler. But read carefully signal(7)). But it is usually not worth the pain.

Look also inside the mm/ subtree of the Linux kernel source.

Read also the extensive documentation of Intel processors. Perhaps read some books on processor architecture and on operating systems, and study simpler architectures (like MMIX or RISC-V).

See Operating Systems : Three Easy Pieces notably its introduction to paging.

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Yeah, but let's say the process wants to MOV an address into a register; this virtual address is not yet mapped in the virtual address space. How does the kernel know that this virtual address is not, in fact, a rogue address? – nirvanaswap Jan 14 '16 at 16:58
  • I answered, but I am not sure to understand what exactly you are asking. Details are complex and processor and OS specific. Read OS & processor architecture books – Basile Starynkevitch Jan 14 '16 at 17:30
  • Hey Basile, thanks for your answer. My questions I guess is like the chicken-and-egg problem. How does the kernel __italic__(know) that the virtual address requested by the instruction actually does really correspond to a physical address, albeit the page frame is not yet loaded into memory? – nirvanaswap Jan 14 '16 at 17:34
  • Read all the references I gave you... it should answer your questions. – Basile Starynkevitch Jan 14 '16 at 17:49
1

I would ignore the model in the Wikipedia article. An invalid page fault, is not a page fault at all but rather a failure of logical memory translation.

The concept of a major and minor page fault, IMHO is confusing. In fact, the Wikipedia article describes two different things as being a minor page fault. I even wonder if something different was intended than how the text reads.

I would rethink as this:

  1. A process accesses a memory address.
  2. The memory management unit attempts to translate the referenced LOGICAL PAGE to a PHYSICAL PAGE FRAME using the page tables. If no such translation is possible (no corresponding table table entry, page table entry is marked as invalid), an access violation fault exception of some kind is generated (Invalid Page Fault in the Wiki article).
  3. If there is already a direct mapping between the logical page and the physical page frame, we're all done.
  4. If the page table indicates there is no physical page frame corresponding to the logical page at the moment, the CPU triggers a page fault exception.
  5. The page fault handler executes.
  6. The page fault handler has to find where the logical (now a virtual) page is stored.
  7. During this process, the page fault handler may find that the page is sitting in physical memory already. There are a number of ways in which this can occur. Be this the case, all the page fault handler has to do is update the page table to reference the physical page frame and restart the instruction (This is one of the circumstances the wiki article calls "minor page fault"). All done.
  8. The other alternative is that the virtual page is stored on disk in a page file, executable file, or shared file. In that case, the handler needs to allocate a physical page frame, read the virtual page from disk into the page frame, update the page table, then restart the instruction (what the wiki calls a "major page fault"). Because of the disk read, the "major" fault takes much longer to handle than the "minor" fault.

One of the functions of the operating system is to keep track of where all the virtual pages are stored. The specific mechanism used to find the page will depend upon a nmber of factors.

user3344003
  • 20,574
  • 3
  • 26
  • 62
  • An "invalid page fault" is called that because the hardware raises a page-fault exception, running the OS's handler for that HW exception. e.g. on x86 it's called `#PF`. The OS code for that handler figures out if it can be resolved by copy-on-write or allocating a new physical page and wiring it up in the page tables (soft page fault), doing I/O (hard page fault), or if it can't be resolved (invalid page fault) because the process doesn't even *logically* own that virtual address. i.e. if it's the process's fault instead of the kernel's responsibility. – Peter Cordes May 24 '22 at 15:38
  • All 3 cases look the same to hardware: an instruction tried to do something that the hardware page tables didn't allow. So it's up to software to check its data structures because paging and lazy allocation and so on mean they're not in sync. – Peter Cordes May 24 '22 at 15:39