lkml.org 
[lkml]   [2002]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] lock assertion macros for 2.5.30
Date
In article <0C01A29FBAE24448A792F5C68F5EA47D2D4437@nasdaq.ms.ensim.com>,
you write:
>
>> Agreed. I'll post another patch that doesn't mess with the scsi
>> stuff. Maybe later I can put together a useful
>> 'lock-not-held-on-this-cpu' macro.
>
>You don't need to put this in a macro. This test is valid
>for ALL spinlocks in the kernel and can be done from inside
>the spin_lock() macro itself, when spinlock debugging is on.
>

There are some cases where this might not be true - e.g. in the
migration code in at least one version of the O(1) scheduler (included
in RedHat's 2.4.18-4) the migration_lock is taken on one CPU and
released on another (following an IPI being sent from the CPU that took
the lock).

So at the very least you'd need a separate set of spinlock primitives
that don't perform this test, which would have to be used by anyone
taking/releasing such a lock.

Paul
-
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.026 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site