All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roland Dreier <rdreier@cisco.com>
To: Ingo Molnar <mingo@elte.hu>, linux-kernel@vger.kernel.org
Subject: On some configs, sparse spinlock balance checking is broken
Date: Tue, 16 Jan 2007 15:47:42 -0800	[thread overview]
Message-ID: <adaejpumt41.fsf@cisco.com> (raw)

(Ingo -- you seem to be the last person to touch all this stuff, and I
can't untangle what you did, hence I'm sending this email to you)

On at least some of my configs on x86_64, when running sparse, I see
bogus 'warning: context imbalance in '<func>' - wrong count at exit'.

This seems to be because I have CONFIG_SMP=y, CONFIG_DEBUG_SPINLOCK=n
and CONFIG_PREEMPT=n.  Therefore, <linux/spinlock.h> does

	#define spin_lock(lock)			_spin_lock(lock)

which picks up

	void __lockfunc _spin_lock(spinlock_t *lock)		__acquires(lock);

from <linux/spinlock_api_smp.h>, but <linux/spinlock.h> also has:

	#if defined(CONFIG_DEBUG_SPINLOCK) || defined(CONFIG_PREEMPT) || \
		!defined(CONFIG_SMP)
	//...
	#else
	# define spin_unlock(lock)		__raw_spin_unlock(&(lock)->raw_lock)

and <asm-x86_64/spinlock.h> has:

	static inline void __raw_spin_unlock(raw_spinlock_t *lock)
	{
		asm volatile("movl $1,%0" :"=m" (lock->slock) :: "memory");
	}

so sparse doesn't see any __releases() to match the __acquires.

This all seems to go back to commit bda98685 ("x86: inline spin_unlock
if !CONFIG_DEBUG_SPINLOCK and !CONFIG_PREEMPT") but I don't know what
motivated that change.

Anyway, Ingo or anyone else, what's the best way to fix this?  Maybe
the right way to fix this is just to define away __acquires/__releases
unless CONFIG_DEBUG_SPINLOCK is set, but that seems suboptimal.

Thanks,
  Roland

             reply	other threads:[~2007-01-16 23:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-16 23:47 Roland Dreier [this message]
2007-01-17  6:34 ` On some configs, sparse spinlock balance checking is broken Ingo Molnar
2007-01-17 15:37   ` Roland Dreier
2007-01-17 16:28     ` Ingo Molnar

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=adaejpumt41.fsf@cisco.com \
    --to=rdreier@cisco.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.