public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Waiman Long <Waiman.Long@hp.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] locking/pvqspinlock: Fix kernel panic in locking-selftest
Date: Sun, 12 Jul 2015 12:13:05 +0900	[thread overview]
Message-ID: <55A1DB41.7050108@hitachi.com> (raw)
In-Reply-To: <1436663959-53092-1-git-send-email-Waiman.Long@hp.com>

On 2015/07/12 10:19, Waiman Long wrote:
> Enabling locking-selftest in a VM guest may cause the following
> kernel panic:
> 
> kernel BUG at .../kernel/locking/qspinlock_paravirt.h:137!
> 
> This is due to the fact that the pvqspinlock unlock function is
> expecting either a _Q_LOCKED_VAL or _Q_SLOW_VAL in the lock byte. This
> patch prevents that bug report by ignoring it when debug_locks_silent
> is set. Otherwise, a warning will be printed if it contains an
> unexpected value.
> 
> With this patch applied, the kernel locking-selftest completed without
> any noise.
> 

OK, I've tested this with make allmodconfig && make localmodconfig kernel.
(I've hit another issue to boot, but it seems not related to this issue)

Tested-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>

Thank you!



> Signed-off-by: Waiman Long <Waiman.Long@hp.com>
> ---
>  kernel/locking/qspinlock_paravirt.h |   12 +++++++++++-
>  1 files changed, 11 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/locking/qspinlock_paravirt.h b/kernel/locking/qspinlock_paravirt.h
> index 04ab181..15d3733 100644
> --- a/kernel/locking/qspinlock_paravirt.h
> +++ b/kernel/locking/qspinlock_paravirt.h
> @@ -4,6 +4,7 @@
>  
>  #include <linux/hash.h>
>  #include <linux/bootmem.h>
> +#include <linux/debug_locks.h>
>  
>  /*
>   * Implement paravirt qspinlocks; the general idea is to halt the vcpus instead
> @@ -286,15 +287,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)) {
> +		if (debug_locks_silent)
> +			return;
> +		WARN(1, "pvqspinlock: lock 0x%lx has corrupted value 0x%x!\n",
> +		    (unsigned long)lock, atomic_read(&lock->val));
> +		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

  reply	other threads:[~2015-07-12  3:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-12  1:19 [PATCH] locking/pvqspinlock: Fix kernel panic in locking-selftest Waiman Long
2015-07-12  3:13 ` Masami Hiramatsu [this message]
2015-07-21  9:41 ` [tip:locking/urgent] " tip-bot for Waiman Long

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=55A1DB41.7050108@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=Waiman.Long@hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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