Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3221567imu; Mon, 28 Jan 2019 00:37:16 -0800 (PST) X-Google-Smtp-Source: AHgI3IahQHvsusgyTo0jYmabiM7AOlIxmPw+/pL1rFaPCIS0EHKCDq7wja71q4wAQasoCDd5qT3E X-Received: by 2002:a17:902:e01:: with SMTP id 1mr6456314plw.251.1548664636259; Mon, 28 Jan 2019 00:37:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548664636; cv=none; d=google.com; s=arc-20160816; b=hbxom8rDk/4WzT6fuOcM8B96Q61gZ/LJpKSHxfDQAC+A5iwpdAwHYgXSfaareUsRiI a7Mg56vHXZfiXFPyqgi+mqZJDWza3Zu2dsTIYrHi6xJF52MsS3F0pBQQkcymtU08+3sX 2mybFSrMrn7REzCppDR4WcaLPpSg5vQZgDewICdMu0XfDymZWks1NhVYmE1j+jDkQbzk +LdP6FuFp5TPlNIDhsRZexrzbZaAaAsjJ10GsWf4yP4iQzBpBJdOo8YOAlzN1duz9rg+ Yw288/5dzX6HeKBQXN4I4ulatOOTwa9T/V03A7Fa1QUpJca7q2XuWdRA3vEkXTZ4FLwe 3cSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=6BqMkqTpgyNOzNyeQi6KRweWAyqopOeP3lX4L6ggTBE=; b=kL1wl69jiS9w57idUb3QYBbYb85SgWJuhaaOWRR9a08jrYWSdkYIHzwxJsXEA7HMnX BmXDnPa2IyPCXpM8lMSaTzUnpE8LY1vtjlYNYjYn30xXtFl0KSGTeNsA+XZtcatMOO6f /ul3EeBYd+Qhsha254bP4ofM4W6mKhb6gUtDLcl3dYDRKuAT/26w0mjt8oxAe7Tsshru XcYYGvD/UNpEhoqxQBpM2UEEA2N68Fs/GO2iysUM0cQ1K7ZqaPCjDejja8+wemMKJnx1 Tj67a2LmkUxe9RRpe664ml2lrMRs2ujn7R23zkwHmLqLYUzpq6mkZmsBMw1st5ZHa1m+ M3KQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j39si4301907plb.272.2019.01.28.00.37.01; Mon, 28 Jan 2019 00:37:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726864AbfA1Ig4 (ORCPT + 99 others); Mon, 28 Jan 2019 03:36:56 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:41165 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726654AbfA1Igz (ORCPT ); Mon, 28 Jan 2019 03:36:55 -0500 Received: from p5492e0d8.dip0.t-ipconnect.de ([84.146.224.216] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1go2PU-0003EB-Ae; Mon, 28 Jan 2019 09:36:52 +0100 Date: Mon, 28 Jan 2019 09:36:51 +0100 (CET) From: Thomas Gleixner To: Zhenzhong Duan cc: linux-kernel@vger.kernel.org, mingo@redhat.com, konrad.wilk@oracle.com, x86@kernel.org, srinivas.eeda@oracle.com, bp@suse.de, tim.c.chen@linux.intel.com, peterz@infradead.org, hpa@zytor.com Subject: Re: [PATCH] x86/speculation: Update TIF_SPEC_IB before ibpb barrier In-Reply-To: <0aa09e77-1454-9eaf-ef67-b00518e6f2d2@oracle.com> Message-ID: References: <48a105d3-fa32-40e4-9775-37d49f42eac0@default> <0aa09e77-1454-9eaf-ef67-b00518e6f2d2@oracle.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 28 Jan 2019, Zhenzhong Duan wrote: > On 2019/1/26 2:03, Thomas Gleixner wrote: > > Bah, nonsense. Brain was clearly still out for lunch and I confused IBPB > > and STIBP for a moment. cond_ibpb() is the thing issues in switch_mm() and > > that is not leaving a stale MSR around because we only write to it when we > > need the barrier. The bit is not stale because the barrier is only issued > > with the write. The bit has not to be cleared. > > > > So the only 'issue' what happens is that switch_to() either issues a > > barrier too much or misses one. That's really not a problem. > > Ok, yes, the purpose of this patch is to avoid the one missed barrier. And that missed barrier is not worth it to do extra work in switch_to/mm simply because it's a one off event and there is no way to exploit that reliably. Thanks, tglx