Strangeness with spinlocks declared static

[Robert Hancock]

I was recently debugging a Linux driver for a PCI card that was developed 
in-house at our company. I was having a problem whereby a function which did 
a spin_lock_irqsave and spin_unlock_irqsave seemed to hang up sometimes, 
especially when the function was called very rapidly. It appeared that 
sometimes the spin_lock_irqsave was blocking, even though the spinlock 
should not have been locked. (This was on an SMP system, dual Xeon 
processors or 4 logical CPUs.)

The spinlock was declared like this (outside of any function):

static spinlock_t debug_spinlock;

and initialized with spin_lock_init.

Eventually I went and looked at the assembly that gcc was generating for the 
spinlock operations, and noticed that the spin loop appeared to be 
performing operations checking the %ebx register instead of the actual 
memory location of the spinlock. That explains why it was behaving so 
strangely, since clearly another CPU won't be able to see/affect the 
register contents.

I then changed the declaration of the spinlock to do it more like most other 
code I've seen:

spinlock_t debug_spinlock = SPIN_LOCK_UNLOCKED;

When I looked at the code for the operations then, it was operating on the 
spinlock in memory as I expected, and the hang problem went away.

This was on Red Hat 9, kernel version 2.4.20-31.9, compiler version gcc 
3.2.2.

I am curious whether this is a known/unknown gcc bug, or whether the 
declaration as static causes it to legally assume that the spinlock counter 
can be cached in a register? The latter seems rather insane to me, 
considering that the lock variable inside the spinlock_t is declared as 
volatile..

-
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/