bug_smp_call_function
Subsystems (6)
PATCH 1/1 bug_smp_call_function
sg.c has been fixed to no longer call vfree() with interrupts disabled. Change smp_call_function() from WARN_ON to BUG_ON when interrupts are disabled. It was only set to WARN_ON because of sg.c.
arch/alpha/kernel/smp.c +1 -1
@@ -821,7 +821,7 @@ smp_call_function_on_cpu (void (*func) (int num_cpus_to_call;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/i386/kernel/smp.c +1 -1
@@ -520,7 +520,7 @@ int smp_call_function (void (*func) (voireturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/ia64/kernel/smp.c +1 -1
@@ -332,7 +332,7 @@ smp_call_function (void (*func) (void *ireturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/mips/kernel/smp.c +1 -1
@@ -152,7 +152,7 @@ int smp_call_function (void (*func) (voireturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/parisc/kernel/smp.c +1 -1
@@ -326,7 +326,7 @@ smp_call_function (void (*func) (void *istatic spinlock_t lock =SPIN_LOCK_UNLOCKED ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/ppc/kernel/smp.c +1 -1
@@ -212,7 +212,7 @@ int smp_call_function(void (*func) (voidif (num_online_cpus () <=1 )return 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ());return __smp_call_function (func, info, wait,MSG_ALL_BUT_SELF ); }
arch/ppc64/kernel/smp.c +1 -1
@@ -692,7 +692,7 @@ int smp_call_function (void (*func) (voiunsigned long timeout;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/s390/kernel/smp.c +1 -1
@@ -129,7 +129,7 @@ int smp_call_function (void (*func) (voireturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/sh/kernel/smp.c +1 -1
@@ -182,7 +182,7 @@ int smp_call_function(void (*func)(voidreturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ());spin_lock (&smp_fn_call.lock);
arch/sparc64/kernel/smp.c +1 -1
@@ -602,7 +602,7 @@ int smp_call_function(void (*func)(voidreturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
arch/um/kernel/smp.c +1 -1
@@ -267,7 +267,7 @@ int smp_call_function(void (*_func)(voidreturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ());spin_lock_bh (&call_lock);atomic_set (&scf_started,0 );
arch/x86_64/kernel/smp.c +1 -1
@@ -405,7 +405,7 @@ int smp_call_function (void (*func) (voireturn 0 ;/* Can deadlock when called with interrupts disabled */ -WARN_ON (irqs_disabled ()); +BUG_ON (irqs_disabled ()); data.func = func; data.info = info;
Quoted 4 lines · Keith Owens
sg.chas been fixed to no longer callvfree()with interrupts disabled. Changesmp_call_function()fromWARN_ONtoBUG_ONwhen interrupts are disabled. It was only set toWARN_ONbecause ofsg.c.
I prefer the WARN_ON. It is exceedingly unlikely that the bug will cause lockups or memory/data corruption or anything else, so why nuke the user's box when we can trivially continue?
We'll be sent the bug report either way.
Quoted 11 lines · Andrew Morton
Quoted 4 lines · Keith Owens
sg.chas been fixed to no longer callvfree()with interrupts disabled. Changesmp_call_function()fromWARN_ONtoBUG_ONwhen interrupts are disabled. It was only set toWARN_ONbecause ofsg.c.I prefer the
WARN_ON. It is exceedingly unlikely that the bug will cause lockups or memory/data corruption or anything else, so why nuke the user's box when we can trivially continue?We'll be sent the bug report either way.
I prefer to catch this bug every time instead of assuming that somebody will see the report in the syslog. Once the kernel code is clean (which it should be now), BUG_ON() will prevent any new code reintroducing this error.
Quoted 3 lines · Keith Owens
Quoted 3 lines
sg.chas been fixed to no longer callvfree()with interrupts disabled. Changesmp_call_function()fromWARN_ONtoBUG_ONwhen interrupts are disabled. It was only set toWARN_ONbecause ofsg.c.
Quoted 4 lines · Andrew Morton
I prefer the
WARN_ON. It is exceedingly unlikely that the bug will cause lockups or memory/data corruption or anything else, so why nuke the user's box when we can trivially continue?
We'll be sent the bug report either way.
Calls to smp_call_function() with interrupts off or spinlocks held typically causes deadlocks on SMP systems. ISTR debugging such an issue in the scheduler a while back, i.e. mmdrop() under rq->lock doing vfree() of an LDT. Basically smp_call_function() will spin waiting for the other cpus to answer the interrupt on multiple cpus. It also doesn't need to be the same function doing smp_call_function(); generally TLB flushing deadlocks against anything doing this.
-- wli
Quoted 11 lines · William Lee Irwin III
Quoted 3 lines · Keith Owens
Quoted 3 lines
sg.chas been fixed to no longer callvfree()with interrupts disabled. Changesmp_call_function()fromWARN_ONtoBUG_ONwhen interrupts are disabled. It was only set toWARN_ONbecause ofsg.c.Quoted 4 lines · Andrew Morton
I prefer the
WARN_ON. It is exceedingly unlikely that the bug will cause lockups or memory/data corruption or anything else, so why nuke the user's box when we can trivially continue?
We'll be sent the bug report either way.
Quoted 7 lines
Calls to
smp_call_function()with interrupts off or spinlocks held typically causes deadlocks on SMP systems. ISTR debugging such an issue in the scheduler a while back, i.e.mmdrop()underrq->lockdoingvfree()of an LDT. Basicallysmp_call_function()will spin waiting for the other cpus to answer the interrupt on multiple cpus. It also doesn't need to be the same function doingsmp_call_function(); generally TLB flushing deadlocks against anything doing this.
Agreed, that is exactly the class of problems that I spent days debugging. WARN_ON() lets developers add code that breaks the rules and assumes that we will have to fix the bad code later. BUG_ON() prevents any bad code being added because it catches the developer as soon as they add it.
Quoted 6 lines · William Lee Irwin III
Quoted 3 lines · Keith Owens
Quoted 3 lines
sg.chas been fixed to no longer callvfree()with interrupts disabled. Changesmp_call_function()fromWARN_ONtoBUG_ONwhen interrupts are disabled. It was only set toWARN_ONbecause ofsg.c.
Quoted 8 lines
Quoted 4 lines · Andrew Morton
I prefer the
WARN_ON. It is exceedingly unlikely that the bug will cause lockups or memory/data corruption or anything else, so why nuke the user's box when we can trivially continue?
We'll be sent the bug report either way.Calls to
smp_call_function()with interrupts off or spinlocks held typically causes deadlocks on SMP systems.
No, this doesn't "typically" deadlock. It will deadlock on every ten millionth call. The preceding 9,999,999 warnings should have imparted sufficient clue?
Quoted 2 lines · William Lee Irwin III
Quoted 2 lines
Calls to
smp_call_function()with interrupts off or spinlocks held typically causes deadlocks on SMP systems.
Quoted 3 lines · Andrew Morton
No, this doesn't "typically" deadlock. It will deadlock on every ten millionth call. The preceding 9,999,999 warnings should have imparted sufficient clue?
I wasn't counting function calls. I suppose it won't deadlock on every call.
-- wli