Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1516299imm; Sun, 27 May 2018 08:50:55 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqc8Vq97ukL9HVHPGYXVvZjKRi57C8ycl/HOVLMbmr4z69DgGpwa56fdiq/TagGvcSfqSoh X-Received: by 2002:a17:902:8a8c:: with SMTP id p12-v6mr10081210plo.94.1527436255923; Sun, 27 May 2018 08:50:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527436255; cv=none; d=google.com; s=arc-20160816; b=p/l8GdQsBLznG3sweg8/MOVmYefcX9I8fY9yy9LDkHRgkoMMk45x8dDwtvsS5v/7IT Ra84O2F/aXDwT/IVsu0D9RpsFG7ibvDdg/JydGBfqWSDMHeZKfVZIANoGVX6Qu7O/Wv2 9LAzujwWWqgkhV23g5Vxc4TunF/uAN440lQ1dH6IiCrlmSceMW6e5UPdm2amDghMHF5/ zbugECWVbjPzINa1W9SQsy7oxsV+ho96VF9eiiCa0fegRZgoAMG+Ze9WM7+9kTGJmwAa o1SUa8THd5zpSIhb2a+NrLGbzsl2atfb68xWpdnt6oQuBCAyPd8zOWgKB7urfrh3q13Y BU+g== 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=uI2rzvD9R4XUOHq/gRMSSBstOcRSOq7X12Cvi84L0js=; b=Nj0v4d4TR5GVk5K7o/zEHCBI2xdF3M+fG/7TmfHpvuZT+AfwvDIgdT9shsK2SrCrSM f2Bkm3wtoaweo7EH2znqdVER/feBK5A0NAvPSeHkubPcnJ4UHj9QRXbee6MNedeuhDR9 kLwheboLJrXvehnGodsOKUgL+tfVEuPj7uENZYNz87QnXZIbFiuQJebJexBnbocH6Hwt mixZqzgnphKw92cp7QfaQvnSP7MZnwPOYHAGmlEPSY5PHnxPCjKA04+ggbHtHAznI+xY rLomD76gPS/7wXurP+DP5qGw+t5dsllhoHrb98qIeipHPWmQ0TPxZU5NQjdd6RbhLVJE xn+w== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q23-v6si27735668pfd.153.2018.05.27.08.50.41; Sun, 27 May 2018 08:50:55 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033163AbeE0Ptw (ORCPT + 99 others); Sun, 27 May 2018 11:49:52 -0400 Received: from mga02.intel.com ([134.134.136.20]:28381 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032723AbeE0PqS (ORCPT ); Sun, 27 May 2018 11:46:18 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 May 2018 08:46:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,448,1520924400"; d="scan'208";a="227741073" Received: from romley-ivt3.sc.intel.com ([172.25.110.60]) by orsmga005.jf.intel.com with ESMTP; 27 May 2018 08:46:12 -0700 From: Fenghua Yu To: "Thomas Gleixner" , "Ingo Molnar" , "H. Peter Anvin" Cc: "Ashok Raj" , "Dave Hansen" , "Rafael Wysocki" , "Tony Luck" , "Alan Cox" , "Ravi V Shankar" , "Arjan van de Ven" , "linux-kernel" , "x86" , Fenghua Yu Subject: [RFC PATCH 04/16] x86/split_lock: Use non locked bit set instruction in set_cpu_cap Date: Sun, 27 May 2018 08:45:53 -0700 Message-Id: <1527435965-202085-5-git-send-email-fenghua.yu@intel.com> X-Mailer: git-send-email 2.5.0 In-Reply-To: <1527435965-202085-1-git-send-email-fenghua.yu@intel.com> References: <1527435965-202085-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 set_bit() called by set_cpu_cap() is a locked bit set instruction for atomic operation. Since the c->x86_capability can span two cache lines depending on kernel configuration and building evnironment, the locked bit set instruction may cause #AC exception when #AC exception for split lock is enabled. But set_cpu_cap() is only called in early init phase on one CPU and therefore there is no contention for set_cpu_cap(). It's unnecessary to be atomic operation. Using __set_bit(), which is not a locked instruction, is faster than the locked instruction and can fix kernel split lock issue. Signed-off-by: Fenghua Yu Acked-by: Dave Hansen --- arch/x86/include/asm/cpufeature.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index aced6c9290d6..0793ec95d18b 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -128,7 +128,8 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; #define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit) -#define set_cpu_cap(c, bit) set_bit(bit, (unsigned long *)((c)->x86_capability)) +#define set_cpu_cap(c, bit) \ + __set_bit(bit, (unsigned long *)((c)->x86_capability)) extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); -- 2.5.0