[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <BB2762BC-C760-4D4C-BDCF-76EFD3E1B18D@kernel.crashing.org>
Date: Tue, 18 Aug 2009 20:17:28 -0500
From: Kumar Gala <galak@...nel.crashing.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, mingo@...e.hu, tglx@...utronix.de,
linuxppc-dev@...abs.org, peterz@...radead.org
Subject: Re: [PATCH] spinlock: __raw_spin_is_locked() should return true for UP
On Aug 18, 2009, at 7:07 PM, Steven Rostedt wrote:
> On Tue, 18 Aug 2009, Linus Torvalds wrote:
>>
>>> Thinking about it, UP probably should have spin_is_locked always
>>> return
>>> false, but if you want to make sure you are not in a critical
>>> section
>>> with the lock not held, then use assert_spin_locked, which on UP
>>> should be
>>> a nop.
>>
>> That's what we do. That said, I also think we should generally try to
>> avoid the kind of code that depends on spin_is_locked always
>> returning
>> false, for the same reason we should try to avoid any code that
>> depends on
>> it always returning true.
>
> Perhaps we can deprecate spin_is_locked and replace it with
> "expect_spin_locked" and "expect_spin_unlocked" which on SMP would
> return
> true and false respectively if the lock was locked. But both would
> always
> return true on UP.
>
> Or do some thing similar, that would remove the ambiguity on UP.
I agree its a little too easy to abuse spin_is_locked. However we
should be consistent between spin_is_locked on UP between with and
without CONFIG_DEBUG_SPINLOCK enabled. How much of this do we want to
try and address in .31?
The PPC test really should be using assert_spin_locked and I'll send a
patch to Ben for that.
- k
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists