On Thu, 2009-08-20 at 09:21 +0400, Nikita V. Youshchenko wrote: > > On Wed, 2009-08-19 at 22:36 +0400, Nikita V. Youshchenko wrote: [...] > > I'm glad it works for you, but it isn't a proper fix. > > Could you please explain? How that code line cod hit if not in interrupt > handler? > > Here is my understanding of the logic of that code. They try to track > spinlocks CPU currently spins at. CPU spinning may be interrupted only by > irq. There "normal" (not SA_NODELAY) interrupt handlers can't be active at > the same CPU at the same time. That leads to maximum 3 spinings: > - one from process context, > - one from "normal" irq handler that interrupted that process context, > - and one from SA_NODELAY irq handler that interrupted normal irq handler. > This one can't be interrupted since it runs with interrupts disabled. > > If such, the code path in question corresponds to "normal" interrupt > handler starting to spin. Thus it should be in_interrupt(). > > How this is wrong? > > Perhaps softirq handler could be activated at exit of the "normal" handler?
Correct. > Maybe better check is BUG_ON(!in_interrupt() && !in_softrq()). Need to > check the code ... There are three spinning-state structures (per CPU) here, allowing for spinning in process context, in bottom-half (softirq) context, and in hard-interrupt context. Since interrupts are generally enabled during interrupt handlers, there need to be multiple levels of hard-interrupt contexts (one per IRQ), if I'm not mistaken. The code in SLE 11 and XCI appears to implement this. Ben. -- Ben Hutchings If at first you don't succeed, you're doing about average.
signature.asc
Description: This is a digitally signed message part
