From: Olivier Galibert <galibert@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: peterz@infradead.org, Steven Rostedt <rostedt@goodmis.org>,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
mingo@elte.hu, tglx@linutronix.de
Subject: Re: [PATCH] spinlock: __raw_spin_is_locked() should return true for UP
Date: Wed, 19 Aug 2009 11:31:45 +0200 [thread overview]
Message-ID: <20090819093145.GA53298@dspnet.fr.eu.org> (raw)
In-Reply-To: <alpine.LFD.2.01.0908181937400.3158@localhost.localdomain>
On Tue, Aug 18, 2009 at 07:40:16PM -0700, Linus Torvalds wrote:
>
>
> On Tue, 18 Aug 2009, Kumar Gala wrote:
> >
> > 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.
>
> No we shouldn't.
>
> With CONFIG_DEBUG_SPINLOCK, you have an actual lock variable for debugging
> purposes, so spin_is_locked() can clearly return a _valid_ answer, and
> should do so.
>
> Without DEBUG_SPINLOCK, there isn't any answer to return.
>
> So there's no way we can or should be consistent. In one case an answer
> exists, in another one the answer is meaningless and doesn't exist.
I always thought behaviour should be consistent between code with
debugging on and code without. Otherwise you may end up with cases of
"it starts working when I turn on debugging" which are a pain to fix.
Has something changed?
Or in other words, do you think lockdep should try solving deadlocks
instead of just reporting them for instance?
OG.
next prev parent reply other threads:[~2009-08-19 9:40 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-18 22:42 [PATCH] spinlock: __raw_spin_is_locked() should return true for UP Kumar Gala
2009-08-18 23:20 ` Linus Torvalds
2009-08-18 23:36 ` Steven Rostedt
2009-08-18 23:52 ` Linus Torvalds
2009-08-19 0:07 ` Steven Rostedt
2009-08-19 1:17 ` Kumar Gala
2009-08-19 2:40 ` Linus Torvalds
2009-08-19 9:31 ` Olivier Galibert [this message]
2009-08-19 9:38 ` Peter Zijlstra
2009-08-19 18:50 ` Scott Wood
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090819093145.GA53298@dspnet.fr.eu.org \
--to=galibert@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).