On 03/05/2015 10:22 AM, Oleg Nesterov wrote: > On 03/05, Oleg Nesterov wrote: >> >> I _think_ that the difference is that eager_fpu_init()->xrstor_state() >> was called before apply_alternatives(), so it used XRSTOR. >> >> Note also that (before this commit) restore_fpu_checking() was almost >> never called right after init_fpu(). If use_eager_fpu() == T. >> >> After this commit the first xrstor_state() uses XRSTORS. And that is >> how (I think) 'noxsaves' makes the difference. >> >> >> So. I can be easily wrong, but so far I _think_ that this commit disclosed >> another problem. And even if I am wrong and this commit is buggy, we need >> to understand why ;) >> >> I'll try to think about debugging patch, I can't reproduce this problem >> on my machine... > > Dave. could please run the test-case below? > > Without 'noxsaves', and without my commit. > > Please compile it "cc --static -m32 -Wall T.c". In case you do not have > the 32-bit libs, I also attached the static binary. > > It should trigger another known problem which I was going to fix later, > math_state_restore() wrongly does cli/sti. Please ignore the "sleeping > function called from invalid context" warning in dmesg. > > Does it trigger something else on your machine?
Triggers this: > [ 125.384358] general protection fault: 0000 [#1] SMP > [ 125.390033] Modules linked in: > [ 125.393521] CPU: 0 PID: 1417 Comm: oleg-test Not tainted > 3.19.0-00428-g4b2e762 #774 > [ 125.402222] Hardware name: Intel Corporation Skylake Client > platform/Skylake Y LPDDR3 RVP3, BIOS SKLSE2P1.86C.X062.R00.1411270820 > 11/27/2014 > [ 125.416537] task: ffff88009af0e100 ti: ffff88009bf24000 task.ti: > ffff88009bf24000 > [ 125.425034] RIP: 0010:[<ffffffff810556cb>] [<ffffffff810556cb>] > math_state_restore+0x8b/0x1c0 > [ 125.434839] RSP: 0000:ffff88009bf27e08 EFLAGS: 00010046 > [ 125.440873] RAX: 00000000ffffffff RBX: ffff88009af0e100 RCX: > 0000000000000000 > [ 125.448972] RDX: 00000000ffffffff RSI: 0000000000000000 RDI: > ffff880148020780 > [ 125.457073] RBP: ffff88009bf27e18 R08: 0000000000000000 R09: > ffff880148020780 > [ 125.465175] R10: 0000000000000001 R11: ffffffff817a0829 R12: > ffff88009af0e100 > [ 125.473274] R13: 0000000000000071 R14: 0000000000000200 R15: > 0000000000000000 > [ 125.481367] FS: 0000000000000000(0003) GS:ffff88014e400000(0063) > knlGS:00000000089ea840 > [ 125.490551] CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 > [ 125.497075] CR2: 0000000000000071 CR3: 000000007f8ce000 CR4: > 00000000003407f0 > [ 125.505177] DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > [ 125.513283] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: > 0000000000000400 > [ 125.521381] Stack: > [ 125.523664] 0000000000000000 00000000ffffffff ffff88009bf27ed8 > ffffffff81061106 > [ 125.532114] ffff880148020780 000000019be24928 0000000000000000 > 0000000000000000 > [ 125.540571] 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > [ 125.549032] Call Trace: > [ 125.551814] [<ffffffff81061106>] __restore_xstate_sig+0x246/0x6c0 > [ 125.558841] [<ffffffff810ace1f>] ? recalc_sigpending+0x1f/0x60 > [ 125.565555] [<ffffffff8109d054>] ia32_restore_sigcontext+0x194/0x1b0 > [ 125.572874] [<ffffffff8109d4bd>] sys32_rt_sigreturn+0xad/0xd0 > [ 125.579505] [<ffffffff817a0985>] ia32_ptregs_common+0x25/0x4b > [ 125.586129] Code: fb 7e e9 11 00 00 00 db e2 0f 77 db 83 44 06 00 00 0f 1f > 80 00 00 00 00 0f 1f 44 00 00 b8 ff ff ff ff 48 8b bb 48 06 00 00 89 c2 <48> > 0f c7 1f 31 c0 eb 20 0f 1f 44 00 00 bf 9a 00 00 00 e8 ce 11 > [ 125.608467] RIP [<ffffffff810556cb>] math_state_restore+0x8b/0x1c0 > [ 125.615599] RSP <ffff88009bf27e08> > [ 125.619563] ---[ end trace 71f0a6784c4b2590 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
