lkml.org 
[lkml]   [2004]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch 2.6.7] bug_smp_call_function
Date
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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:03    [W:0.108 / U:0.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site