From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932260AbbJIMzM (ORCPT ); Fri, 9 Oct 2015 08:55:12 -0400 Received: from casper.infradead.org ([85.118.1.10]:56341 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755820AbbJIMzK (ORCPT ); Fri, 9 Oct 2015 08:55:10 -0400 Date: Fri, 9 Oct 2015 14:55:07 +0200 From: Peter Zijlstra To: Kosuke Tatsukawa Cc: Gleb Natapov , Paolo Bonzini , "kvm@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 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 Content-Disposition: inline In-Reply-To: <17EC94B0A072C34B8DCF0D30AD16044A02874DB5@BPXM09GP.gisp.nec.co.jp> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@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.