Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753405AbbGKGr7 (ORCPT ); Sat, 11 Jul 2015 02:47:59 -0400 Received: from fallback.hitachi.co.jp ([133.145.228.49]:45083 "EHLO mailx.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753281AbbGKGr5 (ORCPT ); Sat, 11 Jul 2015 02:47:57 -0400 Message-ID: <55A0A413.7020507@hitachi.com> Date: Sat, 11 Jul 2015 14:05:23 +0900 From: Masami Hiramatsu Organization: Hitachi, Ltd., Japan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Waiman Long CC: Peter Zijlstra , Ingo Molnar , Ingo Molnar , linux-kernel Subject: Re: [BUG][tip/master] kernel panic while locking selftest at qspinlock_paravirt.h:137! References: <559FAD5E.3080309@hitachi.com> <20150710130028.GI19282@twins.programming.kicks-ass.net> <20150710135746.GA13461@gmail.com> <20150710142824.GK19282@twins.programming.kicks-ass.net> <55A06439.90002@hitachi.com> <55A07111.6030900@hp.com> In-Reply-To: <55A07111.6030900@hp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2923 Lines: 76 On 2015/07/11 10:27, Waiman Long wrote: > On 07/10/2015 08:32 PM, Masami Hiramatsu wrote: >> On 2015/07/10 23:28, Peter Zijlstra wrote: >>> On Fri, Jul 10, 2015 at 03:57:46PM +0200, Ingo Molnar wrote: >>>> * Peter Zijlstra wrote: >>>>> Do we want to make double unlock non-fatal unconditionally? >>>> No, just don't BUG() out, don't crash the system - generate a warning? >>> So that would be a yes.. >>> >>> Something like so then? Won't this generate a splat on that locking self >>> test then? And upset people? >> Hmm, yes, this still noisy... >> Can't we avoid double-unlock completely? it seems that this warning can >> happen randomly, which means pv-spinlock randomly broken, doesn't it? > > It shouldn't randomly happen. The message should be printed at the first > instance of double-unlock. If that is not case, there may be some > problem in the code. Ah, OK. That comes from locking selftest. In that case, do we really need the warning while selftest, since we know it always fails ? > Anyway, I have an alternative fix that should better capture the problem: Do we need both Peter's BUG() removing patch and this? Thank you, > ------------------------------- > diff --git a/kernel/locking/qspinlock_paravirt.h > b/kernel/locking/qspinlock_paravirt.h > index 04ab181..92fc54f 100644 > --- a/kernel/locking/qspinlock_paravirt.h > +++ b/kernel/locking/qspinlock_paravirt.h > @@ -286,15 +286,24 @@ __visible void __pv_queued_spin_unlock(struct > qspinlock *lock) > { > struct __qspinlock *l = (void *)lock; > struct pv_node *node; > + u8 lockval = cmpxchg(&l->locked, _Q_LOCKED_VAL, 0); > > /* > * We must not unlock if SLOW, because in that case we must first > * unhash. Otherwise it would be possible to have multiple @lock > * entries, which would be BAD. > */ > - if (likely(cmpxchg(&l->locked, _Q_LOCKED_VAL, 0) == _Q_LOCKED_VAL)) > + if (likely(lockval == _Q_LOCKED_VAL)) > return; > > + if (unlikely(lockval != _Q_SLOW_VAL)) { > + printk(KERN_WARNING > + "pvqspinlock: lock 0x%lx has corrupted value 0x%x!\n", > + (unsigned long)lock, atomic_read(&lock->val)); > + WARN_ON_ONCE(1); > + return; > + } > + > /* > * Since the above failed to release, this must be the SLOW path. > * Therefore start by looking up the blocked node and unhashing it. > > -- Masami HIRAMATSU Linux Technology Research Center, System Productivity Research Dept. Center for Technology Innovation - Systems Engineering Hitachi, Ltd., Research & Development Group E-mail: masami.hiramatsu.pt@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/