lkml.org 
[lkml]   [2002]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] lock assertion macros for 2.5.30
On Wed, Aug 07 2002, Jesse Barnes wrote:
> On Wed, Aug 07, 2002 at 06:02:19PM -0300, Rik van Riel wrote:
> > On Wed, 7 Aug 2002, Jesse Barnes wrote:
> >
> > > +++ linux-2.5.30-lockassert/drivers/scsi/scsi.c Wed Aug 7 11:35:32 2002
> > > @@ -262,7 +262,7 @@
> >
> > > + MUST_NOT_HOLD(q->queue_lock);
> >
> > ...
> >
> > > +#if defined(CONFIG_DEBUG_SPINLOCK) && defined(CONFIG_SMP)
> > > +#define MUST_HOLD(lock) BUG_ON(!spin_is_locked(lock))
> > > +#define MUST_NOT_HOLD(lock) BUG_ON(spin_is_locked(lock))
> >
> > Please tell me the MUST_NOT_HOLD thing is a joke.
> >
> > What is to prevent another CPU in another code path
> > from holding this spinlock when the code you've
> > inserted the MUST_NOT_HOLD in is on its merry way
> > not holding the lock ?
>
> Nothing at all, but isn't that how the scsi ASSERT_LOCK(&lock, 0)
> macro worked before? I could just remove all those checks in the scsi
> code I guess.

The SCSI ASSERT_LOCK() were never used from kernel space, they are for
the user space similator. So it was always single threaded from there
and has no bearing on what actual kernel code does.

For MUST_NOT_HOLD to work, you need to take into account which processor
took the lock etc.

> After I posted the last patch, a few people asked for MUST_NOT_HOLD so
> I added it back in. Do you think it's a bad idea? See the last

Your current version is surely worthless.

--
Jens Axboe

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

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.178 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site