diff -urN linux-2.6.1/include/linux/spinlock.h linux-2.6.1-rwlock-patch/include/linux/spinlock.h
--- linux-2.6.1/include/linux/spinlock.h 2004-01-09 12:29:33.000000000 +0530
+++ linux-2.6.1-rwlock-patch/include/linux/spinlock.h 2004-01-16 18:15:10.000000000 +0530
@@ -176,6 +176,7 @@
#endif
#define rwlock_init(lock) do { (void)(lock); } while(0)
+#define rwlock_is_locked(lock) ((void)(lock), 0)
#define _raw_read_lock(lock) do { (void)(lock); } while(0)
#define _raw_read_unlock(lock) do { (void)(lock); } while(0)
#define _raw_write_lock(lock) do { (void)(lock); } while(0)
On Fri, 2004-01-16 at 14:45, Prashanth T wrote:
> Hi,
> I had to use rwlock_is_locked( ) with linux2.6 for kdb and noticed that
> this routine to be undefined for UP. I have attached the patch for 2.6.1
> below to return 0 for rwlock_is_locked( ) on UP systems.
> Please let me know.
I consider any user of this on UP to be broken, just like UP use of
spin_is_locked() is always a bug..... better a compiletime bug than a
runtime bug I guess...
On Fri, Jan 16, 2004 at 07:15:11PM +0530, Prashanth T wrote:
> Hi,
> I had to use rwlock_is_locked( ) with linux2.6 for kdb and noticed that
> this routine to be undefined for UP. I have attached the patch for 2.6.1
> below to return 0 for rwlock_is_locked( ) on UP systems.
> Please let me know.
we don't implement spin_is_locked on UP either because there's no really
usefull return value. The lock will never be taken on !SMP && !PREEMPT,
but OTOH it's also not needed, so any assert on will give false results.
And the assert is probably the only thing that the _is_locked routines
could used for sanely.
On Fri, Jan 16, 2004 at 02:55:50PM +0100, Arjan van de Ven wrote:
> On Fri, 2004-01-16 at 14:45, Prashanth T wrote:
> > Hi,
> > I had to use rwlock_is_locked( ) with linux2.6 for kdb and noticed that
> > this routine to be undefined for UP. I have attached the patch for 2.6.1
> > below to return 0 for rwlock_is_locked( ) on UP systems.
> > Please let me know.
>
> I consider any user of this on UP to be broken, just like UP use of
> spin_is_locked() is always a bug..... better a compiletime bug than a
> runtime bug I guess...
Then maybe a #error explaining this is in order ?
- Joe
Joe Thornber writes:
> On Fri, Jan 16, 2004 at 02:55:50PM +0100, Arjan van de Ven wrote:
> > On Fri, 2004-01-16 at 14:45, Prashanth T wrote:
> > > Hi,
> > > I had to use rwlock_is_locked( ) with linux2.6 for kdb and noticed that
> > > this routine to be undefined for UP. I have attached the patch for 2.6.1
> > > below to return 0 for rwlock_is_locked( ) on UP systems.
> > > Please let me know.
> >
> > I consider any user of this on UP to be broken, just like UP use of
> > spin_is_locked() is always a bug..... better a compiletime bug than a
> > runtime bug I guess...
>
> Then maybe a #error explaining this is in order ?
So, if there is a function
void foo_locked(struct bar *obj)
{
/* check that we are called with obj's lock held */
BUG_ON(!rwlock_is_locked(&obj->lock));
/* proceed with obj. */
}
it should now be changed to the
void foo_locked(struct bar *obj)
{
#ifdef CONFIG_SMP
BUG_ON(!rwlock_is_locked(&obj->lock));
#endif
/* proceed with obj. */
}
?
>
> - Joe
>
Nikita.
>
On Fri, Jan 16, 2004 at 06:14:06PM +0300, Nikita Danilov wrote:
> it should now be changed to the
>
> void foo_locked(struct bar *obj)
> {
> #ifdef CONFIG_SMP
> BUG_ON(!rwlock_is_locked(&obj->lock));
> #endif
> /* proceed with obj. */
> }
You forgot preempt... ;)
ok....I understand that rwlock_is_locked( ) is to be protected by
CONFIG_SMP. But I was tempted when I saw spin_is_locked( )
to be returning zero for !SMP in include/linux/spinlock.h .
Am I seeing something wrong here?
Christoph Hellwig wrote:
>On Fri, Jan 16, 2004 at 07:15:11PM +0530, Prashanth T wrote:
>
>
>>Hi,
>> I had to use rwlock_is_locked( ) with linux2.6 for kdb and noticed that
>>this routine to be undefined for UP. I have attached the patch for 2.6.1
>>below to return 0 for rwlock_is_locked( ) on UP systems.
>>Please let me know.
>>
>>
>
>we don't implement spin_is_locked on UP either because there's no really
>usefull return value. The lock will never be taken on !SMP && !PREEMPT,
>but OTOH it's also not needed, so any assert on will give false results.
>And the assert is probably the only thing that the _is_locked routines
>could used for sanely.
>
>
>
>