On 11/24/2017 12:22 PM, Ingo Molnar wrote: > [ 8.831002] RIP: 0010:page_fault+0x11/0x60 > [ 8.831002] RSP: 0000:ffffffffff0e7fc8 EFLAGS: 00010046 > [ 8.831002] RAX: 00000000819d4d77 RBX: 0000000000000001 RCX: > ffffffff819d4d77 > [ 8.831002] RDX: 0000000000000003 RSI: 0000000000000010 RDI: > ffffffffff0e8078 > [ 8.831002] RBP: 0000000000000000 R08: 00007ffd7f1aa530 R09: > 00007f9407f98400 > [ 8.831002] R10: 0000000000000007 R11: 0000000000000000 R12: > 00007ffd7f1aa680 > [ 8.831002] R13: 00007f9407f91f80 R14: 0000000000000007 R15: > 0000000000000000 > [ 8.831002] ? native_iret+0x7/0x7 > [ 8.831002] WARNING: can't dereference iret registers at ffffffffff0e8048 > for ip page_fault+0x11/0x60 > [ 8.831002] </#DF> > [ 8.831002] <SYSENTER> > [ 8.831002] ? __do_page_fault+0x4c0/0x4c0 > [ 8.831002] ? page_fault+0x2c/0x60 > [ 8.831002] ? native_iret+0x7/0x7 > [ 8.831002] ? __do_page_fault+0x4c0/0x4c0 > [ 8.831002] ? page_fault+0x2c/0x60 > [ 8.831002] ? __entry_text_end+0x1/0x1 > [ 8.831002] </SYSENTER>
Just a stab in the dark from looking at this for a few seconds... Doesn't this stack trace mean we started C-code page fault handing on the sysenter stack? Seems like we missed a switch to the process stack.
