* Lockdep warning with init_espfix_ap()
@ 2014-10-09 15:35 Prarit Bhargava
2014-10-15 15:57 ` H. Peter Anvin
0 siblings, 1 reply; 4+ messages in thread
From: Prarit Bhargava @ 2014-10-09 15:35 UTC (permalink / raw)
To: linux-kernel; +Cc: x86
Non-fatal warning seen with latest kernel tree during kernel boot.
WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2744
lockdep_trace_alloc+0xdd/0xe0()
DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
Modules linked in:
CPU: 64 PID: 0 Comm: swapper/64 Not tainted 3.17.0+ #10
Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BIVTSDP1.86B.0049.R00.1403081207 03/08/2014
0000000000000000 d27b9ea0e3821f35 ffff88084edc3ce0 ffffffff8171cbd8
ffff88084edc3d28 ffff88084edc3d18 ffffffff8108424d 0000000000000046
0000000000000000 00000000000000d0 0000000000000002 0000000000000000
Call Trace:
[<ffffffff8171cbd8>] dump_stack+0x4d/0x66
[<ffffffff8108424d>] warn_slowpath_common+0x7d/0xa0
[<ffffffff810842cc>] warn_slowpath_fmt+0x5c/0x80
[<ffffffff810e3e2d>] lockdep_trace_alloc+0xdd/0xe0
[<ffffffff811c0aaf>] __alloc_pages_nodemask+0x9f/0x4b0
[<ffffffff81025365>] ? native_sched_clock+0x35/0xa0
[<ffffffff810253d9>] ? sched_clock+0x9/0x10
[<ffffffff8120981a>] alloc_page_interleave+0x3a/0x90
[<ffffffff8120ae8d>] alloc_pages_current+0x17d/0x1f0
[<ffffffff811bab24>] ? __get_free_pages+0x14/0x50
[<ffffffff811bab24>] __get_free_pages+0x14/0x50
[<ffffffff8102225d>] init_espfix_ap+0x17d/0x320
[<ffffffff8105254e>] start_secondary+0x19e/0x350
---[ end trace 2b62d796aa7ae001 ]---
Debugging ... but sorta hoping someone else may have already seen it ;)
P.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Lockdep warning with init_espfix_ap()
2014-10-09 15:35 Lockdep warning with init_espfix_ap() Prarit Bhargava
@ 2014-10-15 15:57 ` H. Peter Anvin
2014-10-15 16:03 ` Prarit Bhargava
0 siblings, 1 reply; 4+ messages in thread
From: H. Peter Anvin @ 2014-10-15 15:57 UTC (permalink / raw)
To: Prarit Bhargava, linux-kernel; +Cc: x86
On 10/09/2014 08:35 AM, Prarit Bhargava wrote:
>
> Non-fatal warning seen with latest kernel tree during kernel boot.
>
> WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2744
> lockdep_trace_alloc+0xdd/0xe0()
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> Modules linked in:
>
> CPU: 64 PID: 0 Comm: swapper/64 Not tainted 3.17.0+ #10
> Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
> BIVTSDP1.86B.0049.R00.1403081207 03/08/2014
> 0000000000000000 d27b9ea0e3821f35 ffff88084edc3ce0 ffffffff8171cbd8
> ffff88084edc3d28 ffff88084edc3d18 ffffffff8108424d 0000000000000046
> 0000000000000000 00000000000000d0 0000000000000002 0000000000000000
> Call Trace:
> [<ffffffff8171cbd8>] dump_stack+0x4d/0x66
> [<ffffffff8108424d>] warn_slowpath_common+0x7d/0xa0
> [<ffffffff810842cc>] warn_slowpath_fmt+0x5c/0x80
> [<ffffffff810e3e2d>] lockdep_trace_alloc+0xdd/0xe0
> [<ffffffff811c0aaf>] __alloc_pages_nodemask+0x9f/0x4b0
> [<ffffffff81025365>] ? native_sched_clock+0x35/0xa0
> [<ffffffff810253d9>] ? sched_clock+0x9/0x10
> [<ffffffff8120981a>] alloc_page_interleave+0x3a/0x90
> [<ffffffff8120ae8d>] alloc_pages_current+0x17d/0x1f0
> [<ffffffff811bab24>] ? __get_free_pages+0x14/0x50
> [<ffffffff811bab24>] __get_free_pages+0x14/0x50
> [<ffffffff8102225d>] init_espfix_ap+0x17d/0x320
> [<ffffffff8105254e>] start_secondary+0x19e/0x350
> ---[ end trace 2b62d796aa7ae001 ]---
>
> Debugging ... but sorta hoping someone else may have already seen it ;)
>
It is kind of a messy situation, because this code needs to allocate
memory but is run before the secondary CPU is fully up. As such, it is
a false positive, at least in some ways.
-hpa
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Lockdep warning with init_espfix_ap()
2014-10-15 15:57 ` H. Peter Anvin
@ 2014-10-15 16:03 ` Prarit Bhargava
2014-10-15 16:05 ` H. Peter Anvin
0 siblings, 1 reply; 4+ messages in thread
From: Prarit Bhargava @ 2014-10-15 16:03 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linux-kernel, x86
On 10/15/2014 11:57 AM, H. Peter Anvin wrote:
> On 10/09/2014 08:35 AM, Prarit Bhargava wrote:
>>
>> Non-fatal warning seen with latest kernel tree during kernel boot.
>>
>> WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2744
>> lockdep_trace_alloc+0xdd/0xe0()
>> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>> Modules linked in:
>>
>> CPU: 64 PID: 0 Comm: swapper/64 Not tainted 3.17.0+ #10
>> Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
>> BIVTSDP1.86B.0049.R00.1403081207 03/08/2014
>> 0000000000000000 d27b9ea0e3821f35 ffff88084edc3ce0 ffffffff8171cbd8
>> ffff88084edc3d28 ffff88084edc3d18 ffffffff8108424d 0000000000000046
>> 0000000000000000 00000000000000d0 0000000000000002 0000000000000000
>> Call Trace:
>> [<ffffffff8171cbd8>] dump_stack+0x4d/0x66
>> [<ffffffff8108424d>] warn_slowpath_common+0x7d/0xa0
>> [<ffffffff810842cc>] warn_slowpath_fmt+0x5c/0x80
>> [<ffffffff810e3e2d>] lockdep_trace_alloc+0xdd/0xe0
>> [<ffffffff811c0aaf>] __alloc_pages_nodemask+0x9f/0x4b0
>> [<ffffffff81025365>] ? native_sched_clock+0x35/0xa0
>> [<ffffffff810253d9>] ? sched_clock+0x9/0x10
>> [<ffffffff8120981a>] alloc_page_interleave+0x3a/0x90
>> [<ffffffff8120ae8d>] alloc_pages_current+0x17d/0x1f0
>> [<ffffffff811bab24>] ? __get_free_pages+0x14/0x50
>> [<ffffffff811bab24>] __get_free_pages+0x14/0x50
>> [<ffffffff8102225d>] init_espfix_ap+0x17d/0x320
>> [<ffffffff8105254e>] start_secondary+0x19e/0x350
>> ---[ end trace 2b62d796aa7ae001 ]---
>>
>> Debugging ... but sorta hoping someone else may have already seen it ;)
>>
>
> It is kind of a messy situation, because this code needs to allocate
> memory but is run before the secondary CPU is fully up. As such, it is
> a false positive, at least in some ways.
Interesting -- FWIW, I can reproduce this 100% of the time on _one_ system. It
isn't a big deal and likely just worth noting at this point. I *always* see it
when bringing up CPU 64 (of 128).
P.
>
> -hpa
>
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Lockdep warning with init_espfix_ap()
2014-10-15 16:03 ` Prarit Bhargava
@ 2014-10-15 16:05 ` H. Peter Anvin
0 siblings, 0 replies; 4+ messages in thread
From: H. Peter Anvin @ 2014-10-15 16:05 UTC (permalink / raw)
To: Prarit Bhargava; +Cc: linux-kernel, x86
On 10/15/2014 09:03 AM, Prarit Bhargava wrote:
>>
>> It is kind of a messy situation, because this code needs to allocate
>> memory but is run before the secondary CPU is fully up. As such, it is
>> a false positive, at least in some ways.
>
> Interesting -- FWIW, I can reproduce this 100% of the time on _one_ system. It
> isn't a big deal and likely just worth noting at this point. I *always* see it
> when bringing up CPU 64 (of 128).
>
... because that is the first CPU which needs to allocate memory.
-hpa
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-15 16:05 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-10-09 15:35 Lockdep warning with init_espfix_ap() Prarit Bhargava
2014-10-15 15:57 ` H. Peter Anvin
2014-10-15 16:03 ` Prarit Bhargava
2014-10-15 16:05 ` H. Peter Anvin
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.