From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965134AbbJIIvN (ORCPT ); Fri, 9 Oct 2015 04:51:13 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:59245 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965090AbbJIIuq (ORCPT ); Fri, 9 Oct 2015 04:50:46 -0400 Date: Fri, 9 Oct 2015 10:50:40 +0200 From: Peter Zijlstra To: Paolo Bonzini Cc: Kosuke Tatsukawa , Gleb Natapov , "kvm@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] kvm: fix waitqueue_active without memory barrier in virt/kvm/async_pf.c Message-ID: <20151009085040.GZ7520@twins.programming.kicks-ass.net> References: <17EC94B0A072C34B8DCF0D30AD16044A028747C1@BPXM09GP.gisp.nec.co.jp> <56177EAC.2070601@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56177EAC.2070601@redhat.com> 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 10:45:32AM +0200, Paolo Bonzini wrote: > So you need another smp_mb() after prepare_to_wait(). I'm not sure > if it's needed also for your original tty report, but I think it is > for https://lkml.org/lkml/2015/10/8/989 ("mei: fix waitqueue_active > without memory barrier in mei drivers"). > > I wonder if it makes sense to introduce smp_mb__before_spin_lock() > and smp_mb__after_spin_unlock(). On x86 the former could be a > simple compiler barrier, and on s390 both of them could. But that > should be a separate patch. Not having actually read or thought about the issue at hand, its perfectly valid to pair an smp_mb() with either spin_lock() or spin_unlock(). IOW. MB <-> {ACQUIRE, RELEASE} is a valid pairing.