[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-arm-kernel
Subject:    Re: race condition in do_IRQ
From:       Matthias Welwarsky <mwelwarsky () web ! de>
Date:       2004-05-06 7:50:30
Message-ID: 200405061003.56241.mwelwarsky () web ! de
[Download RAW message or body]

On Thursday 06 May 2004 09:07, Marius Groeger wrote:
> Hello Pite,
>
> On Wed, 5 May 2004, Nicolas Pitre wrote:
> > > the following code snipet can be found in /kernel/irq.c: do_IRQ(...)
> > > [line 231- 237].
> > > In my opinion this code should be atomic!
> > >
> > > ...
> > > if (desc->running || desc->disable_depth)
> > >                goto running;
> > > /*
> > > * Mark the IRQ currently in progress.
> > > */
> > > desc->running = 1;
> > > ...
> > >
> > > Can anyone please tell me why it isn't ?
> >
> > What makes you think it isn't?
>
> What makes you think it is? :-) I can't see any locking mechanisms. And if
> there's some locking outside do_IRQ(), then what is desc->running for
> anyway? Or could this be an SMPism?
>
> Just looking at this snippet, it suggests two threads  of execution can
> enter this region. If the first one makes it just between the "if" and the
> assigment, the next could still get equally far.

This is the interrupt handler. The code you're talking about is run with 
interrupts disabled and is protected with the irq_controller spinlock - no 
atomicity problem there. The desc->running lock is there because later 
interrupts may become enabled again.

regards,
	matthias

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php
[prev in list] [next in list] [prev in thread] [next in thread]