Messages in this thread | | | From | Keith Owens <> | Subject | Re: [patch 2.6.7] bug_smp_call_function | Date | Sat, 19 Jun 2004 20:05:13 +1000 |
| |
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/
| |