* Roland Dreier <[EMAIL PROTECTED]> wrote: > (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)
this is the direct-inlining speedup some people insisted on. > 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. i think the right way to fix it might be to define a _spin_unlock() within those #ifdef branches, and then to define spin_lock as: static inline void spin_lock(spinlock_t *lock) __acquires(lock) { _spin_lock(lock); } ? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/