[linux-dvb] [BUG] flexcop lockdep

Patrick Boettcher patrick.boettcher at desy.de
Fri Apr 6 11:12:10 CEST 2007

On Thu, 5 Apr 2007, Trent Piepho wrote:

> On Thu, 5 Apr 2007, Patrick Boettcher wrote:
> > On Thu, 5 Apr 2007, Borgi2008 wrote:
> > > Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Seppälä:
> > > >
> > > > Actually, looking at the code I cannot figure out why there has to be a
> > > > spinlock in the first place.
> > > >
> > > > The lock is only taken in the interrupt handler which already runs in
> > > > atomic context so there is no use in making the handler protected by a
> > > > spinlock. Am I missing something here?
> > > >
> > > > I think the spinlock is unnecessary and should be removed entirely.
> >
> > Even on SMP systems? ISRs are only atomic on one CPU.
> I thought ISRs were normally atomic even on SMP systems.  When an interrupt
> occurs, that interrupt is disabled until the ISR returns.  Except in fast
> handlers (which flexcop is not) all interrupts aren't disabled, and so an
> ISR can be interrupted by a _different_ ISR, and a different ISR could be
> running at the same time on another CPU.  But an ISR doesn't have to worry
> about two copies of itself running at the same time.
> At least, that's how I think it works.
> I don't see how a spin lock that is only used from the ISR could be useful,
> assuming the ISR is only called via an interrupt.  There is no reason you
> couldn't call the isr function from some system call handler, but that
> would be an unusual thing to do.
> Normally an ISR does need a spinlock, to access data shared by the
> non-interrupt part of the driver.  I wonder if there is a bug in flexcop in
> that nothing else uses irq_lock?

You can only take a spinlock at IRQ-level and not at normal kernel level. 
So you cannot protect from shared data access without delegating the work 
to a lower level and there to use mutexes to protect.

As there is only the isr which is at IRQ-level you might be right, it can 
be removed. 

Someone outthere with a SMP-system and a flexcop who could see if e.g. 
dvbscan or dvbtraffic is killing the system/flexcop when removing the 


More information about the linux-dvb mailing list