Re: enhanced spinlock debugging code for intel

Brent Baccala (baccala@freesoft.org)
Thu, 02 Aug 2001 13:44:24 -0400


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/