From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2] kvm: fix waitqueue_active without memory barrier in
 virt/kvm/async_pf.c
Date: Fri, 9 Oct 2015 14:55:07 +0200
Message-ID: <20151009125507.GA7520@twins.programming.kicks-ass.net>
References: <17EC94B0A072C34B8DCF0D30AD16044A02874DB5@BPXM09GP.gisp.nec.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Gleb Natapov <gleb@kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
To: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Return-path: <linux-kernel-owner@vger.kernel.org>
Content-Disposition: inline
In-Reply-To: <17EC94B0A072C34B8DCF0D30AD16044A02874DB5@BPXM09GP.gisp.nec.co.jp>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On Fri, Oct 09, 2015 at 12:21:55PM +0000, Kosuke Tatsukawa wrote:

> +	 * Memory barrier is required here to make sure change to
> +	 * vcpu->async_pf.done is visible from other CPUs.  This memory
> +	 * barrier pairs with prepare_to_wait's set_current_state()

That is not how memory barriers work; they don't 'make visible'. They
simply ensure order between operations.

  X = Y = 0

	CPU0			CPU1

	[S] X=1			[S] Y=1
	 MB			 MB
	[L] y=Y			[L] x=X

  assert(x || y)

The issue of the memory barrier does not mean the store is visible, it
merely means that the load _must_ happen after the store (in the above
scenario).

This gives a guarantee that not both x and y can be 0. Because either
being 0, means the other has not yet executed and must therefore observe
your store.

Nothing more, nothing less.

So your comment is misleading at best.