Re: double fault -> PAGE_KERNEL flagged memory

[Mathieu Desnoyers <compudj at krystal dot dyndns dot org>]

* Tom Zanussi (zanussi@us.ibm.com) wrote:
 
> I just tried a simple experiment instrumenting do_page_fault() to log
> in the same spot LTT does, and also at the very end of of the
> vmalloc_fault case, and see the vmalloc faults (to the relayfs buffer,
> caused by a write from another page fault, since that's all that's
> instrumented) being logged without double faults.  So you don't even
> have to test whether the fault is in the relayfs buffer, just wait
> until the page table has been updated.  What would cause a double
> fault would be if the vmalloc_fault tried logging before the page
> table was updated, which would cause the same vmalloc fault.
> 


Yes, it fits with p. 5-52, vol. 3 from IA32 Intel Software Developer Manual : it
explains that a page fault handler can generate another page fault in its code.
It must save the content of the CR2 register (address of the fault) before a
nested PF can occur.

After having read the "Interrupt 8 - Double fault exception", vol3. p. 5-37 five
times, I get the difference between :

"while calling an exception handler for a prior exception"
and
"while the processor is executing an NMI interrupt handler"

The page fault case causing a double fault is only when the call to the PF
handler will itself generate a page fault. The code of the PF handler seems to
be allowed to generate a PF without any double fault occuring.

But having the PF handler causing a PF on the same address as the preceding one
before the page table has been updated could clearly end up in a recursive page
fault. I just tried it, I don't think this ends up in a double fault
(nothing shown on my debug console) and I get a system freeze (I use spinlocks
to protect my buffer in this test). It looks like a deadlock.

It could be interesting, if we want to instrument this function before the page
table is updated (i.e. have each function entry including this one, getting the
real time spent in the do_page_fault function), to have a small low traffic
memory subsystem reentrant kmalloc'd relayfs channel to log this particular
path.

Mathieu


OpenPGP public key:              http://krystal.dyndns.org:8080/key/compudj.gpg
Key fingerprint:     8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68