Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp4725633imm; Mon, 14 May 2018 11:55:38 -0700 (PDT) X-Google-Smtp-Source: AB8JxZplKEh7t3/9aA+VymlYlsgVmw3mt0Lc8+Ar/0wpoW0GYzDCZeiLmdKDdPzcQMtlG7u2QFuc X-Received: by 2002:a17:902:a711:: with SMTP id w17-v6mr11099105plq.292.1526324138001; Mon, 14 May 2018 11:55:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526324137; cv=none; d=google.com; s=arc-20160816; b=JrjEFIbyW17PFE8aJ7b4Du+JK4rfA+SM2aG8CjvR2uP5BCYkmXQrqF4ZI8Jz2eHj74 zlzFN4rCeiMDRir7l48BL4+wAfhbbUcnB9/dkT7hcxbcGsjlwgi3Jku6qFlhrh+6vscx Sqvj656bh6Ai7J/Efmg4+9UjFFK3HYnGp5GqaTRLj4PjQgrw9Fr+UU/tX5fJAhVeD/qr d34AmqISrz2Icp6cYMWs8+V9b0QivaVJa5XrovmgzKwABGjp2nqbOjgjUd0AOVSW63ng /lGaoNC7rJvugwu06YXX7mCcFp6u+nBwMLPnAtX/US5SsE67+nEQB1svMim9E63Tl88g jFNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=ajs/PtTLy0oMAu4SzKksiohdJpF7fuvSXQKUdOZZNWI=; b=0cbI0LqO2HNw5rCSOIgl5gGWNzRbegtOgUBmJKYWhqZr2JfA3UiXyVahgcm0tzJn3m 1g5VCGhhhWr7oasrpopShQcqUdxOtc0lSrYKnxqx0a75N/9o8M2bXsFYz9M6LjzNCtHB RtJDNwBMs5YvIIFi0R67bmRhoFq/9QtaTSNAFM1lj1mMzjToLil1KIa/NNAxhYGftBNA n9XWyycR2ETztgwkcxV4JV0GDDi2Re98KjOF/Vwruc9PXE14AeQRCbN5yeOqjflgpT8f T7H342Fu4TfOIZByGfMfJfSdglM77DWrxZmqcnQr0dICbTTrmEEu9IUF4V+eZ/vLhoLs YizQ== 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 a68-v6si10215047pli.158.2018.05.14.11.55.23; Mon, 14 May 2018 11:55:37 -0700 (PDT) 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 S1752365AbeENSyS (ORCPT + 99 others); Mon, 14 May 2018 14:54:18 -0400 Received: from mga06.intel.com ([134.134.136.31]:55035 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752031AbeENSwa (ORCPT ); Mon, 14 May 2018 14:52:30 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2018 11:52:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,401,1520924400"; d="scan'208";a="39244635" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by fmsmga007.fm.intel.com with ESMTP; 14 May 2018 11:52:27 -0700 From: Fenghua Yu To: "Thomas Gleixner" , "Ingo Molnar" , "H. Peter Anvin" , "Ashok Raj" , "Ravi V Shankar" , "Tony Luck" , "Dave Hansen" , "Rafael Wysocki" , "Arjan van de Ven" , "Alan Cox" Cc: "x86" , "linux-kernel" , Fenghua Yu Subject: [PATCH 05/15] x86/split_lock: Use non atomic set and clear bit instructions to clear cpufeature Date: Mon, 14 May 2018 11:52:15 -0700 Message-Id: <1526323945-211107-6-git-send-email-fenghua.yu@intel.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1526323945-211107-1-git-send-email-fenghua.yu@intel.com> References: <1526323945-211107-1-git-send-email-fenghua.yu@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When #AC exception is enabled for split locked accesses, clear_cpufeature() generates #AC exception because of atomic setting or clearing bits in non cache line aligned x86_capability depending on compiler. But kernel clears cpufeatures only when a CPU boots up. Therefore, there is no racing condition when clear_cpufeature() is called and no need to atomically clear or set x86_capability. To avoid #AC exception caused by split lock and get better performance, call non atomic __set_bit() and __clear_bit(). Signed-off-by: Fenghua Yu --- arch/x86/kernel/cpu/cpuid-deps.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index 2c0bd38a44ab..0c02c6e44ea7 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -65,15 +65,15 @@ static const struct cpuid_dep cpuid_deps[] = { static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature) { /* - * Note: This could use the non atomic __*_bit() variants, but the - * rest of the cpufeature code uses atomics as well, so keep it for - * consistency. Cleanup all of it separately. + * Because this code is only called during boot time and there + * is no need to be atomic, use non atomic __*_bit() to avoid + * #AC exception for split locked access. */ if (!c) { clear_cpu_cap(&boot_cpu_data, feature); - set_bit(feature, (unsigned long *)cpu_caps_cleared); + __set_bit(feature, (unsigned long *)cpu_caps_cleared); } else { - clear_bit(feature, (unsigned long *)c->x86_capability); + __clear_bit(feature, (unsigned long *)c->x86_capability); } } -- 2.5.0