Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp728481imu; Wed, 23 Jan 2019 04:47:15 -0800 (PST) X-Google-Smtp-Source: ALg8bN7VBPAKd+nYsYyA+0xnUvn0muVEOSOipyfJQbdhfEmo1F396eFKGdNmMcb9ITD2J5WCuRX6 X-Received: by 2002:a63:5d20:: with SMTP id r32mr1849691pgb.329.1548247635034; Wed, 23 Jan 2019 04:47:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548247635; cv=none; d=google.com; s=arc-20160816; b=jOzOPBn66Z/8MPcR/IITq7b6bpJ2nSYOpvfGQkevWnHxrq4YuDN70quEEi3oCW7p3c 1MwaGPh+/Vr6iv1yd4BBrsrru+GUzpoEIJ/R2WvSGwvI4TNRN8ZkVhxCyHkvvdvHJTWU FQnWjvmeqrzddDoxQNNgxiRSHE6Kefw3DEHrI2negP1lKkti6ywIgWQcaV1KGpiKQLxG D3GOHvmLJelNDTGR6aE8gcJYisUJJgs0u9veXqa2ECMCLDWQlUQVcAGgnFBhH/q7Z+e2 UVNYHFpkaNYXgqd51tS44Bce7BZqNxPS9tZN5tibQY3w7mPGd4O7H5LyyeYQDkSvghzi iozA== 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=z2neDeUYWtO6+W+xmiWH85ia9iDQrkzbFFJSN5sxMBw=; b=td4jJ2ISj4la7WbrA+GnUssxKkg0Ikotvj0cePVxqC2vUof9Oh+GYX09vINrhfduRf MTC2SOdYRABtopbF5fPaVwFA0SAoSsB9O2fddqJ2nlhYsZ3Hk3V/vmH4UkOROldiVR/1 dZzoHH7CEdtvl7i/C1WWxv7D06VfpbPALD/2WxdLROykOtGV1arZDPzppc+XOpKoNzmK FQrHf8MrhNkQTiFmyEF3Z+MeBnFtgss47T62cI5Mom/IUDdPXN3zNeUsj62Pqec7Rqmp iXuA6pUxqL7yF7Of6sf8EOWv73FP1cN4XamzH96e3M4x1H0jS/sZKnYJ1IwFPN8uprkC 0zxw== 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 3si18287880plq.138.2019.01.23.04.46.58; Wed, 23 Jan 2019 04:47:15 -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 S1726167AbfAWMpx (ORCPT + 99 others); Wed, 23 Jan 2019 07:45:53 -0500 Received: from Galois.linutronix.de ([146.0.238.70]:34050 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726104AbfAWMpw (ORCPT ); Wed, 23 Jan 2019 07:45:52 -0500 Received: from p4fea4364.dip0.t-ipconnect.de ([79.234.67.100] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1gmHud-0000Qt-1C; Wed, 23 Jan 2019 13:45:47 +0100 Date: Wed, 23 Jan 2019 13:45:46 +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: <48a105d3-fa32-40e4-9775-37d49f42eac0@default> Message-ID: References: <48a105d3-fa32-40e4-9775-37d49f42eac0@default> 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 Fri, 18 Jan 2019, Zhenzhong Duan wrote: > When a task is set for updating TIF_SPEC_IB throuth SECCOMP by others > and it's scheduled in the first time, a stale TIF_SPEC_IB value is > picked in cond_ibpb(). This is due to TIF_SPEC_IB is updated later at > __switch_to_xtra(). > > Add an extra call to speculation_ctrl_update_tif() to update it before > IBPB barrier. Errm. No. It adds that call to speculation_ctrl_update_tif() for every mm switch, most of the time for nothing. If at all, and we discussed that before and decided not to worry about it (because it gets fixed up on the next context switch), then you want to handle ibpb() from there: if (likely(!((tifp | tifn) & _TIF_SPEC_FORCE_UPDATE))) { __speculation_ctrl_update(tifp, tifn); } else { speculation_ctrl_update_tif(prev_p); tifn = speculation_ctrl_update_tif(next_p); /* Enforce MSR update to ensure consistent state */ __speculation_ctrl_update(~tifn, tifn); ------> Force update IBPB } Thanks, tglx