Messages in this thread |  | | | Date | Wed, 22 Sep 2004 22:25:31 -0600 | | From | Robert Hancock <> | | Subject | Strangeness with spinlocks declared static |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |