* [PATCH] eliminate spurious pointless WARN_ON()s
@ 2009-03-12 12:16 Jan Beulich
2009-03-12 12:19 ` Ingo Molnar
0 siblings, 1 reply; 2+ messages in thread
From: Jan Beulich @ 2009-03-12 12:16 UTC (permalink / raw)
To: linux-kernel; +Cc: Andi Kleen
Namely during early boot, the panic() or BUG() paths may end up in
smp_call_function_*() with just a single online CPU. In that situation
the warnings generated are not only meaningless, but also result in
relevant output being cluttered.
Therefore, defer the WARN_ON() checks until after the (unaffected from
the problem that is being attempted to be detected here) cases have
been handled.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Cc: Andi Kleen <andi@firstfloor.org>
---
kernel/smp.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
--- linux-2.6.29-rc7/kernel/smp.c 2009-03-04 09:11:00.000000000 +0100
+++ 2.6.29-rc7-smp-call-defer-warn/kernel/smp.c 2009-02-13 12:17:02.000000000 +0100
@@ -222,9 +222,6 @@ int smp_call_function_single(int cpu, vo
int me = get_cpu();
int err = 0;
- /* Can deadlock when called with interrupts disabled */
- WARN_ON(irqs_disabled());
-
if (cpu == me) {
local_irq_save(flags);
func(info);
@@ -232,6 +229,9 @@ int smp_call_function_single(int cpu, vo
} else if ((unsigned)cpu < nr_cpu_ids && cpu_online(cpu)) {
struct call_single_data *data;
+ /* Can deadlock when called with interrupts disabled */
+ WARN_ON(irqs_disabled());
+
if (!wait) {
/*
* We are calling a function on a single CPU
@@ -325,9 +325,6 @@ void smp_call_function_many(const struct
unsigned long flags;
int cpu, next_cpu;
- /* Can deadlock when called with interrupts disabled */
- WARN_ON(irqs_disabled());
-
/* So, what's a CPU they want? Ignoring this one. */
cpu = cpumask_first_and(mask, cpu_online_mask);
if (cpu == smp_processor_id())
@@ -347,6 +344,9 @@ void smp_call_function_many(const struct
return;
}
+ /* Can deadlock when called with interrupts disabled */
+ WARN_ON(irqs_disabled());
+
data = kmalloc(sizeof(*data) + cpumask_size(), GFP_ATOMIC);
if (unlikely(!data)) {
/* Slow path. */
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [PATCH] eliminate spurious pointless WARN_ON()s
2009-03-12 12:16 [PATCH] eliminate spurious pointless WARN_ON()s Jan Beulich
@ 2009-03-12 12:19 ` Ingo Molnar
0 siblings, 0 replies; 2+ messages in thread
From: Ingo Molnar @ 2009-03-12 12:19 UTC (permalink / raw)
To: Jan Beulich, Peter Zijlstra; +Cc: linux-kernel, Andi Kleen
* Jan Beulich <jbeulich@novell.com> wrote:
> Namely during early boot, the panic() or BUG() paths may end
> up in smp_call_function_*() with just a single online CPU. In
> that situation the warnings generated are not only
> meaningless, but also result in relevant output being
> cluttered.
>
> Therefore, defer the WARN_ON() checks until after the
> (unaffected from the problem that is being attempted to be
> detected here) cases have been handled.
Makes sense probably - but please send a patch against -tip as
we've got quite many changes queued up in that area and your
patch does not apply cleanly:
patching file kernel/smp.c
Hunk #1 FAILED at 222.
Hunk #2 FAILED at 229.
Hunk #3 FAILED at 325.
Hunk #4 FAILED at 344.
4 out of 4 hunks FAILED -- rejects in file kernel/smp.c
Thanks,
Ingo
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-03-12 12:19 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-12 12:16 [PATCH] eliminate spurious pointless WARN_ON()s Jan Beulich
2009-03-12 12:19 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®