Re: [patch 2.6.7] bug_smp_call_function

[Keith Owens <kaos@sgi.com>]

On Sat, 19 Jun 2004 02:59:10 -0700, 
William Lee Irwin III <wli@holomorphy.com> wrote:
>Keith Owens <kaos@sgi.com> wrote:
>>>  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.
>
>On Sat, Jun 19, 2004 at 02:44:16AM -0700, Andrew Morton wrote:
>> 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.

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.