On 12/29/2017 10:46 AM, Alexander Tsoy wrote: > В Пт, 29/12/2017 в 09:32 -0800, Dave Hansen пишет: >> Does anyone have the results of build that they can share? (vmlinux, >> vmlinuz/bzImage, System.map, .config). That, plus a corresponding >> serial log with an oops would be helpful. > > Here you are: > https://www.dropbox.com/s/yesupqgig3uxf73/linux-4.15-rc5%2B.tar.xz?dl=0 Alexander, thanks a bunch for the quick turnaround on this. It is much appreciated! With your binary, I can reproduce this in a KVM guest. Seems we manage to get to paranoid_entry with a kernel GS value, but the user page tables in place. We don't smash the #DF stack because we reset the stack at each new #DF. I think the loop that we get stuck in goes something like this: 1. Hardware does #DF, calls double_fault 2. call paranoid_entry 3. check MSR for GSBASE, see it has kernel value, skip SWAPGS and switch to kernel page tables 4. touch stack, try to #PF, but can't touch stack, so #DF and goto 1 The real question is where we double-faulted from in the first place with a kernel GSBASE and user CR3. I think I just need to disable KASLR and do a little work in gdb to look at the stack on the first double-fault, but we'll see.