Re: enhanced spinlock debugging code for intel

[Brent Baccala <baccala@freesoft.org>]

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