Re: [PATCH][2.6-mm] i386: enable interrupts on contention inspin_lock_irq

[Zwane Mwaikambo]

On Wed, 26 May 2004, Zwane Mwaikambo wrote:

> On Wed, 26 May 2004, Duncan Sands wrote:
>
> > > However I have seen buggy code where spin_lock_irq() was issued with
> > > interrupts disabled. [...]
> >
> > Some time ago I sent a patch to lkml that tests for this [1].
> > And guess what - it happens all over the place [2].  Also, the
> > scheduler often gets called with interrupts disabled (schedule()
> > does spin_lock_irq), but the cases I checked all turned out to be
> > OK [3].  Perhaps it is more problematic now?
>
> I'll run with the debug code and audit any suspect ones. The ones
> mentioned below all seem ok.

The oft hit one is triggered from the timer softirq;

Badness in __run_timers at kernel/timer.c:427
 [<c0107705>] dump_stack+0x15/0x20
 [<c012d497>] run_timer_softirq+0x2e7/0x2f0
 [<c0128bc8>] __do_softirq+0xb8/0xc0
 [<c0128c05>] do_softirq+0x35/0x40
 [<c0108fb5>] do_IRQ+0x1a5/0x240

static inline void __run_timers(tvec_base_t *base)
{
	struct timer_list *timer;

	spin_lock_irq(&base->lock); <==
	...
		timer->base = NULL;
		spin_unlock_irq(&base->lock);
		fn(data);
		spin_lock_irq(&base->lock);
	...
	spin_unlock_irq(&base->lock);
}

Most of them would be because the timer irq is setup with SA_INTERRUPT,
this particular one looks safe too, we're on the exit path of irq handling
and there is no critical section to protect. We're also about to
unconditionally enable interrupts again before running the timers. There
also isn't much contention on this lock on most workloads, some
heavy tcp networking load should help that out.

I'll look for others too.

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