Re: 2.6.11: spinlock problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[ Charset ISO-8859-1 unsupported, converting... ]
> On Fri, 23 Jun 2006, Darren Reed wrote:
> 
> > Hi,
> >
> > I'm seeing a spinlock held panic with a kernel stack like this:
> >
> > spinlock - panic, lock already held
> > ..
> > __do_softirq
> > do_softirq
> > =========
> > do_IRQ
> > common_interrupt
> > spinlock/spinunlock
> > ..
> >
> > when I load up the system in testing.
> > The code protected by the spinlock is quite small - counter increment.
> >
> > I'm using 2.6.11-1.1369_FC4 #1, installed inside of vmware,
> > running as a guest on a Windows XP box.
> >
> > Is this
> > (a) linux allowing the IRQ too early
> > (b) vmware not doing something right
> > (c) enivitable
> > (d) somehow my fault
> > (e) something else?
> >
> > Thanks,
> > Darren
> 
> Where's the code? Also, did you initialize the spin-lock variable
> before use?

locks are intialised...code runs for a minute or so before panic'ing

I write my own wrappers to read/write_lock/unlock.

The call stack for the panic is:
panic
ipf_read_enter
..
do_softirq
=====
do_IRQ
common_interrupt
ipf_rw_exit

ipf_read_enter and ipf_rw_exit are being called for different locks.
The panic is occuring in the spin_lock() for the counter increment.
The counter incrememnt/decrement uses the same lock, regardless of
the counter being used.

I believe I'm hitting a race condition of sorts...I just don't know
who owns it yet - vmware or linux and I cant test running linux
natively at present because I only have one computer.

Darren

INLINE void ipf_rw_exit(rwlk)
ipfrwlock_t *rwlk;
{
        if (rwlk->ipf_isw > 0) {
                rwlk->ipf_isw = 0;
                write_unlock(&rwlk->ipf_lk);
        } else if (rwlk->ipf_isr > 0) {
                ATOMIC_DEC32(rwlk->ipf_isr);
                read_unlock(&rwlk->ipf_lk);
        } else {
                panic("rwlk->ipf_isw %d isr %d rwlk %p name [%s]\n",
                      rwlk->ipf_isw, rwlk->ipf_isr, rwlk, rwlk->ipf_lname);
        }
}

INLINE void ipf_read_enter(rwlk)
ipfrwlock_t *rwlk;
{
        read_lock(&rwlk->ipf_lk);
        ATOMIC_INC32(rwlk->ipf_isr);
}

#  define       ATOMIC_INC32(x)         MUTEX_ENTER(&ipf_rw); (x)++; \
                                        MUTEX_EXIT(&ipf_rw)
#  define       ATOMIC_DEC32(x)         MUTEX_ENTER(&ipf_rw); (x)--; \
                                        MUTEX_EXIT(&ipf_rw)
#  define       MUTEX_ENTER(x)          spin_lock(&(x)->ipf_lk)
#  define       MUTEX_EXIT(x)           spin_unlock(&(x)->ipf_lk)

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux