Re: Oops with tip/x86/fpu
From: Dave Hansen
Date: Thu Mar 05 2015 - 13:41:16 EST
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/