Strangeness with spinlocks declared static
From: Robert Hancock
Date: Wed Sep 22 2004 - 23:28:03 EST
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/