I've been walking through the scenario of why some kernel
addresses are not visible to some processes. Think of a block of
memory allocated by the kernel for internal use, but triggering
a page fault, e.g. because page is swapped, or hasnt been touched
yet, by the user space.
When the page fault handler is invoked, the address of the buffer
exists only in some process page tables.
Turns out this is a (nice!) clever trick of the kernel. When things
are allocated in the kernel, and should be visible to all processes,
e.g. a driver module or other buffer, when the page fault kicks in,
a check is made if the page is valid in the "master page table".
Process #0, created on kernel boot up, houses the master table.
The currently running process may not have the mapping in place, and instead
of paying a large cost to update all processes page tables to represent
these kernel pages, the page fault handler will update the local process
page table when the fault occurs.
This explains why some processes can see the page in question, and, others
Bear in mind we are putting in place a page-fault interrupt handler.
This *must*, repeat *MUST* be visible at the time of a page fault, else
we get a cascade of nested page-faults because the handler isnt mapped
in the process page tables.
So, we need to arrange this to be true. At the moment, the options
include: (a) see if anything in the kernel allows us to propagate the
page-table mapping across all procs (nobody else, other than possibly
a Virtualisation guest, such as Xen/VMWare/VirtualBox, is likely to do this),
or, (b) do the hard work myself, (c) move the interrupt handler
into an existing page of mapped memory [hard], or (d) dont patch the
IDT, but patch the existing page fault handler [not sure if this doesnt
just put off the problem].
Let me scrape some cobwebs off my brain...