linux-kernel - Re: [Xen-devel] [PATCH v15 12/15] pvqspinlock, x86: Enable PV qspinlock for Xen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <552518A0.10205@citrix.com>
Date:	Wed, 8 Apr 2015 13:01:36 +0100
From:	David Vrabel <david.vrabel@...rix.com>
To:	Waiman Long <Waiman.Long@...com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"Peter Zijlstra" <peterz@...radead.org>
CC:	<linux-arch@...r.kernel.org>, Rik van Riel <riel@...hat.com>,
	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>,
	<kvm@...r.kernel.org>, Daniel J Blueman <daniel@...ascale.com>,
	<x86@...nel.org>, Paolo Bonzini <paolo.bonzini@...il.com>,
	<linux-kernel@...r.kernel.org>,
	<virtualization@...ts.linux-foundation.org>,
	Scott J Norton <scott.norton@...com>,
	David Vrabel <david.vrabel@...rix.com>,
	Oleg Nesterov <oleg@...hat.com>,
	<xen-devel@...ts.xenproject.org>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Douglas Hatch <doug.hatch@...com>
Subject: Re: [Xen-devel] [PATCH v15 12/15] pvqspinlock, x86: Enable PV qspinlock
 for Xen

On 07/04/15 03:55, Waiman Long wrote:
> This patch adds the necessary Xen specific code to allow Xen to
> support the CPU halting and kicking operations needed by the queue
> spinlock PV code.

This basically looks the same as the version I wrote, except I think you
broke it.

> +static void xen_qlock_wait(u8 *byte, u8 val)
> +{
> +	int irq = __this_cpu_read(lock_kicker_irq);
> +
> +	/* If kicker interrupts not initialized yet, just spin */
> +	if (irq == -1)
> +		return;
> +
> +	/* clear pending */
> +	xen_clear_irq_pending(irq);
> +
> +	/*
> +	 * We check the byte value after clearing pending IRQ to make sure
> +	 * that we won't miss a wakeup event because of the clearing.

My version had a barrier() here to ensure this.  The documentation of
READ_ONCE() suggests that it is not sufficient to meet this requirement
(and a READ_ONCE() here is not required anyway).

> +	 *
> +	 * The sync_clear_bit() call in xen_clear_irq_pending() is atomic.
> +	 * So it is effectively a memory barrier for x86.
> +	 */
> +	if (READ_ONCE(*byte) != val)
> +		return;
> +
> +	/*
> +	 * If an interrupt happens here, it will leave the wakeup irq
> +	 * pending, which will cause xen_poll_irq() to return
> +	 * immediately.
> +	 */
> +
> +	/* Block until irq becomes pending (or perhaps a spurious wakeup) */
> +	xen_poll_irq(irq);
> +}

David

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/