next BUG: using smp_processor_id() in preemptible

7 messages, 2 authors, 2012-02-01 · open the first message on its own page

next BUG: using smp_processor_id() in preemptible

From: Hugh Dickins <hughd@google.com>
Date: 2011-12-05 23:51:54 

3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of

Dec  4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec  4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: Call Trace:
Dec  4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec  4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec  4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec  4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed

from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.

Hugh

Re: next BUG: using smp_processor_id() in preemptible

From: Hugh Dickins <hughd@google.com>
Date: 2011-12-22 12:07:27 

On Mon, 5 Dec 2011, Hugh Dickins wrote:

3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of

Dec  4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec  4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: Call Trace:
Dec  4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec  4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec  4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec  4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed

from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Still a problem in 3.2.0-rc6-next-20111222

Hugh

Re: next BUG: using smp_processor_id() in preemptible

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2011-12-22 21:17:59 

On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
On Mon, 5 Dec 2011, Hugh Dickins wrote:
quoted
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of

Dec  4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec  4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: Call Trace:
Dec  4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec  4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec  4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec  4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed

from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Still a problem in 3.2.0-rc6-next-20111222
Ah forgot about that, I'll have a look. Thanks for the reminder.

Cheers,
Ben.

Re: next BUG: using smp_processor_id() in preemptible

From: Hugh Dickins <hughd@google.com>
Date: 2012-01-14 22:22:02 

On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
quoted
On Mon, 5 Dec 2011, Hugh Dickins wrote:
quoted
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of

Dec  4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec  4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: Call Trace:
Dec  4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec  4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec  4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec  4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed

from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Still a problem in 3.2.0-rc6-next-20111222
Ah forgot about that, I'll have a look. Thanks for the reminder.
I'm afraid it's now blighting Linus's tree for 3.3.

Hugh

Re: next BUG: using smp_processor_id() in preemptible

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2012-01-15 05:05:28 

On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
quoted
On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
quoted
On Mon, 5 Dec 2011, Hugh Dickins wrote:
quoted
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of

Dec  4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec  4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: Call Trace:
Dec  4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec  4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec  4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec  4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed

from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Still a problem in 3.2.0-rc6-next-20111222
Ah forgot about that, I'll have a look. Thanks for the reminder.
I'm afraid it's now blighting Linus's tree for 3.3.
Grrr, my memory is a colander... And now am in Ballarat for the week
with a semi working 3g connection. I'll see what I can do.

Cheers,
Ben.

Re: next BUG: using smp_processor_id() in preemptible

From: Hugh Dickins <hughd@google.com>
Date: 2012-02-01 06:12:41 

On Sun, 15 Jan 2012, Benjamin Herrenschmidt wrote:
On Sat, 2012-01-14 at 14:21 -0800, Hugh Dickins wrote:
quoted
On Fri, 23 Dec 2011, Benjamin Herrenschmidt wrote:
quoted
On Thu, 2011-12-22 at 04:07 -0800, Hugh Dickins wrote:
quoted
On Mon, 5 Dec 2011, Hugh Dickins wrote:
quoted
3.2.0-rc3-next-20111202 with CONFIG_DEBUG_PREEMPT=y gives me lots of

Dec  4 20:03:19 thorn kernel: BUG: using smp_processor_id() in preemptible [00000000] code: startpar/1365
Dec  4 20:03:19 thorn kernel: caller is .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: Call Trace:
Dec  4 20:03:19 thorn kernel: [c0000001b45a7c60] [c000000000011fe8] .show_stack+0x6c/0x16c (unreliable)
Dec  4 20:03:19 thorn kernel: [c0000001b45a7d10] [c00000000024318c] .debug_smp_processor_id+0xe4/0x11c
Dec  4 20:03:19 thorn kernel: [c0000001b45a7da0] [c00000000000e2e8] .arch_local_irq_restore+0x44/0x90
Dec  4 20:03:19 thorn kernel: [c0000001b45a7e30] [c000000000005870] .do_hash_page+0x70/0x74
Dec  4 20:03:21 thorn kernel: debug_smp_processor_id: 21950 callbacks suppressed

from the u64 *next_tb = &__get_cpu_var(decrementers_next_tb)
in decrementer_check_overflow(): I've no idea whether it's safe
just to use get_cpu_var then put_cpu_var there instead,
but no hurry, I can survive with DEBUG_PREEMPT off.
Still a problem in 3.2.0-rc6-next-20111222
Ah forgot about that, I'll have a look. Thanks for the reminder.
I'm afraid it's now blighting Linus's tree for 3.3.
Grrr, my memory is a colander... And now am in Ballarat for the week
with a semi working 3g connection. I'll see what I can do.
Sorry to be such a bore - you can guess what I have to say about 3.3-rc2 :()

Hugh

Re: next BUG: using smp_processor_id() in preemptible

From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: 2012-02-01 10:48:46 

On Tue, 2012-01-31 at 22:12 -0800, Hugh Dickins wrote:
quoted
Grrr, my memory is a colander... And now am in Ballarat for the week
with a semi working 3g connection. I'll see what I can do.
Sorry to be such a bore - you can guess what I have to say about
3.3-rc2 :()
Yeah, I'm looking at reworking the whole thing, I think we have another
deeper problem with lazy interrupt disable and implicit re-enable from
an exception exit too... stay tuned.

Cheers,
Ben.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help