Tachino Nobuhiro wrote:
>
> Hello,
>
> At Thu, 02 Aug 2001 03:02:12 -0400,
> Brent Baccala wrote:
> >
> > Hi -
> >
> > I'm having a problem with my USB CD burner that involves spinlocks - in
> > particular, some code that trys to grab a spinlock that's already locked
> > (this on a uni-processor machine).
> >
> > The existing spinlock debug code on intel only checked for unlocking an
> > unlocked spinlock, so I added code to check for locking a locked
> > spinlock as well - it now catches my problem.
>
> I think your code has a race. See following sequence.
You're right. And I thought this code was simple :-)
I guess what suggests itself to me is something like:
static inline void spin_unlock(spinlock_t *lock)
{
#if SPINLOCK_DEBUG
if (lock->magic != SPINLOCK_MAGIC)
BUG();
if (!spin_is_locked(lock))
BUG();
+ lock->last_lock_processor = -1;
#endif
__asm__ __volatile__(
spin_unlock_string
:"=m" (lock->lock) : : "memory");
}
No longer any race (right?) and we don't lose anything since the one
processor is about to drop the lock it (presumably) held. I wonder if
it should check to make sure the same processor that grabbed the lock is
releasing it. Not exactly a bug, and somebody might write code like
that, but it seems suspicious. Comments?
--
-bwb
Brent Baccala
baccala@freesoft.org
==============================================================================
For news from freesoft.org, subscribe to announce@freesoft.org:
mailto:announce-request@freesoft.org?subject=subscribe&body=subscribe
==============================================================================
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:23 EST