Re: [PATCH 0/4] x86: FPU detection in C
On Wed, Apr 10, 2013 at 08:35:43AM -0700, H. Peter Anvin wrote: > OK, this thread took off in another direction but you're still looking > at this, right? Yep, and I think I have the rootcause, let's start (oops below for info). When the oops happens, we're on the following path: start_kernel |-> trap_init |-> cpu_init |-> fpu_init and down that path we do mxcsr_feature_mask_init() at some point which does b13cf456: 0f ae 05 80 54 58 b1fxsave 0xb1585480 This causes an #NM for the first time since we have CR0.EM set. We enter the handler do_device_not_available which calls into math_emulate() because we have CONFIG_MATH_EMULATION on. It, in the beginning, does init_fpu(current) which does fpu_alloc, which in turn, does kmem_cache_alloc(task_xstate_cachep... Since we have SLUB on in this particular .config, we go to slab_alloc_node() in slub.c and the following code (cf. the Code section below): kmem_cache_alloc: pushl %ebp# movl%esp, %ebp #, pushl %edi# pushl %esi# pushl %ebx# subl$32, %esp #, callmcount movl%eax, %edi # s, s movl%edx, -28(%ebp) # gfpflags, %sfp .L825: movl(%edi), %eax# s_3(D)->cpu_slab, tcp_ptr__ <--- #APP # 2341 "mm/slub.c" 1 add %fs:this_cpu_off, %eax # this_cpu_off, tcp_ptr__ # 0 "" 2 #NO_APP and %edi, is of course, 0. Finally, this happens because we haven't initialized task_xstate_cachep. We still do the initialization albeit a bit further down in the same function: start_kernel |-> fork_init(totalram_pages) |-> arch_task_cache_init This, however, is *after* trap_init -> Boom. Provided I haven't made a mistake, this is the problem we're seeing. [0.00] Initializing CPU#0 [0.00] BUG: unable to handle kernel NULL pointer dereference at (null) [0.00] IP: [] kmem_cache_alloc+0x13/0x130 [0.00] *pde = [0.00] Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC [0.00] Modules linked in: [0.00] Pid: 0, comm: swapper Not tainted 3.9.0-rc5+ #2 [0.00] EIP: 0060:[] EFLAGS: 00210046 CPU: 0 [0.00] EIP is at kmem_cache_alloc+0x13/0x130 [0.00] EAX: EBX: b1557fa0 ECX: 007b EDX: 00d0 [0.00] ESI: f77df9a0 EDI: EBP: b154dea4 ESP: b154de78 [0.00] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 [0.00] CR0: 80050037 CR2: CR3: 015e8000 CR4: 0290 [0.00] DR0: DR1: DR2: DR3: [0.00] DR6: 0ff0 DR7: 0400 [0.00] Process swapper (pid: 0, ti=b154c000 task=b1557fa0 task.ti=b154c000) [0.00] Stack: [0.00] 3b9aca00 b154de8c b11d033c 00d0 b154deb8 b1028952 b16f4040 [0.00] b1557fa0 f77df9a0 b13de290 b154deb0 b1009897 b154df44 b154df3c b1320715 [0.00] b154ded8 b1028e00 b16f4062 0001 b154dee0 00200046 [0.00] Call Trace: [0.00] [] ? sprintf+0x1c/0x20 [0.00] [] ? print_time.part.5+0x82/0xc0 [0.00] [] ? do_debug+0x150/0x150 [0.00] [] init_fpu+0x67/0xa0 [0.00] [] math_emulate+0x695/0xc40 [0.00] [] ? print_prefix+0x60/0xa0 [0.00] [] ? sub_preempt_count+0x8/0x80 [0.00] [] ? sub_preempt_count+0x8/0x80 [0.00] [] ? wake_up_klogd+0x49/0x70 [0.00] [] ? console_unlock+0x365/0x4c0 [0.00] [] ? do_debug+0x150/0x150 [0.00] [] do_device_not_available+0x3e/0x80 [0.00] [] error_code+0x6c/0x74 [0.00] [] ? fpu_init+0x80/0xf5 [0.00] [] cpu_init+0x2b0/0x2b8 [0.00] [] trap_init+0x243/0x24b [0.00] [] start_kernel+0x1a2/0x34f [0.00] [] ? repair_env_string+0x51/0x51 [0.00] [] i386_start_kernel+0x12c/0x12f [0.00] Code: 0c 89 f0 e8 50 f4 ff ff 5b 5e 5d c3 8d b6 00 00 00 00 8d bf 00 00 00 00 55 89 e5 57 56 53 83 ec 20 e8 72 93 2e 00 89 c7 89 55 e4 <8b> 07 64 03 05 94 b6 5d b1 8b 58 04 8b 00 85 c0 89 45 ec 74 76 [0.00] EIP: [] kmem_cache_alloc+0x13/0x130 SS:ESP 0068:b154de78 [0.00] CR2: [0.00] ---[ end trace a7919e7f17c0a725 ]--- [0.00] Kernel panic - not syncing: Attempted to kill the idle task! -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/
Re: [PATCH 0/4] x86: FPU detection in C
On 04/10/2013 06:32 AM, Borislav Petkov wrote: > (let's test the reply-to-all settings now :-)) > > On Wed, Apr 10, 2013 at 02:25:27PM +0200, Ingo Molnar wrote: >> In my builds I disable that. So I'd suggest to disable that bit in the >> .config and retry. > > Yep, did that and was able to reproduce the issue in qemu. At a first > glance, it looks like we're calling kmalloc too early but I need to > verify this is actually the case. Stay tuned. > OK, this thread took off in another direction but you're still looking at this, right? -hpa -- 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/
Re: [PATCH 0/4] x86: FPU detection in C
(let's test the reply-to-all settings now :-)) On Wed, Apr 10, 2013 at 02:25:27PM +0200, Ingo Molnar wrote: > In my builds I disable that. So I'd suggest to disable that bit in the > .config and retry. Yep, did that and was able to reproduce the issue in qemu. At a first glance, it looks like we're calling kmalloc too early but I need to verify this is actually the case. Stay tuned. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/
Re: [PATCH 0/4] x86: FPU detection in C
* Borislav Petkov wrote: > On Wed, Apr 10, 2013 at 01:08:40PM +0200, Ingo Molnar wrote: > > Config attached. > > How do you even build this? I tried tip:x86/cpu but it fails here: > > drivers/misc/lkdtm.c: In function ???recursive_loop.constprop.3???: > drivers/misc/lkdtm.c:276:1: warning: the frame size of 1028 bytes is larger > than 1024 bytes [-Wframe-larger-than=] > In file included from > /w/kernel/linux-2.6/arch/x86/include/asm/uaccess.h:537:0, > from include/linux/uaccess.h:5, > from include/linux/highmem.h:8, > from include/linux/pagemap.h:10, > from fs/binfmt_misc.c:27: > /w/kernel/linux-2.6/arch/x86/include/asm/uaccess_32.h: In function > ???parse_command.part.2???: > /w/kernel/linux-2.6/arch/x86/include/asm/uaccess_32.h:211:26: error: call to > ???copy_from_user_overflow??? declared with attribute error: copy_from_user() > buffer size is not provably correct > make[1]: *** [fs/binfmt_misc.o] Error 1 > make[1]: *** Waiting for unfinished jobs > make: *** [fs] Error 2 > make: *** Waiting for unfinished jobs > > because of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y. In my builds I disable that. So I'd suggest to disable that bit in the .config and retry. Thanks, Ingo -- 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/
Re: [PATCH 0/4] x86: FPU detection in C
On Wed, Apr 10, 2013 at 01:08:40PM +0200, Ingo Molnar wrote: > Config attached. How do you even build this? I tried tip:x86/cpu but it fails here: drivers/misc/lkdtm.c: In function ‘recursive_loop.constprop.3’: drivers/misc/lkdtm.c:276:1: warning: the frame size of 1028 bytes is larger than 1024 bytes [-Wframe-larger-than=] In file included from /w/kernel/linux-2.6/arch/x86/include/asm/uaccess.h:537:0, from include/linux/uaccess.h:5, from include/linux/highmem.h:8, from include/linux/pagemap.h:10, from fs/binfmt_misc.c:27: /w/kernel/linux-2.6/arch/x86/include/asm/uaccess_32.h: In function ‘parse_command.part.2’: /w/kernel/linux-2.6/arch/x86/include/asm/uaccess_32.h:211:26: error: call to ‘copy_from_user_overflow’ declared with attribute error: copy_from_user() buffer size is not provably correct make[1]: *** [fs/binfmt_misc.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [fs] Error 2 make: *** Waiting for unfinished jobs because of CONFIG_DEBUG_STRICT_USER_COPY_CHECKS=y. Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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/
