From: Peter Zijlstra <peterz@infradead.org>
To: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
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>
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 [thread overview]
Message-ID: <20151009125507.GA7520@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <17EC94B0A072C34B8DCF0D30AD16044A02874DB5@BPXM09GP.gisp.nec.co.jp>
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.
next prev parent reply other threads:[~2015-10-09 12:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 12:21 [PATCH v2] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c Kosuke Tatsukawa
2015-10-09 12:55 ` Peter Zijlstra [this message]
2015-10-09 13:56 ` Paolo Bonzini
2015-11-06 13:02 ` William Dauchy
2015-11-06 16:30 ` Paolo Bonzini
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=20151009125507.GA7520@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=gleb@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=tatsu@ab.jp.nec.com \
/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;
as well as URLs for NNTP newsgroup(s).