Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3693330imm; Tue, 29 May 2018 11:45:05 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoA3XXI4lpCvNwS9KCVPMUha+ssDwW7FZGxZpFoGZnLPv0psMgQRRXpu7rTu1iXiKBIk1EL X-Received: by 2002:a17:902:8307:: with SMTP id bd7-v6mr18626810plb.234.1527619504970; Tue, 29 May 2018 11:45:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527619504; cv=none; d=google.com; s=arc-20160816; b=IjK3Ky1NhBfj3GAzapzpayG4EVF8uXPUOhotzoCbGwE+JxxVE3ZP49LT3TTwQNhAkV AFUrQ0DCj3hgtvzV0eqOTDsOy7O5tdDedfW+EQF7fOWzoOnB4FBDuh4lLe88B5myKsqU LJtyIgBMY4U9GAaXh9ecy+h4DWfJnRe+jsMSD3Ddwg/FzdFhACIwsfUsN/3yrgoe/JX1 m/tOi0shUl6zzV1Lxep47jf9I2rW0MsjCIMlwMehBxYQqd3XVRcte1ZNizhZf66qxort PEMctMV/BRc3z3HsbY8jupxciZoEPn8ATAMYhwv5hr00uIl2XUqJ8MypVxtjb1TYlIE/ pvQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=LgeeEpI4mYibLDnWjwFllPkWruFymgV3jRA1bvG2mB4=; b=mmlgA7jBj4UsuhhXDQllpRrOQKHSi5Ca4hlweQOsOgIvrxF0kRDvuWkxtAd3fd11UH w/tTsDgydjohUe0ZAGtnyZMPrwCD4fiY4ZsM7Uwm4mtt/q41T8f+oXLudH5A/Ckpd9wT 0qb/xrtHvGJWnIRB4KgQRGSViT3C/FHs8ElgSqazxiD1x0lK+q3f1vK++yU0oBUj79by bAh0zMUny93Ww5wiJbzR7+WlWy5z+hIfxfYKPvSy5kQ0Ag5XxzdWCDBxcNairlMxjNP1 YPHn1tQt7q58ILEx1C+8wY0LCrBGaiS+hRRXDzjV1TaJk6YKpwEPdwng6fhfXRCz2hRL ullA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=hvR8CTeI; 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 d17-v6si31104878pll.590.2018.05.29.11.44.50; Tue, 29 May 2018 11:45:04 -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; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=hvR8CTeI; 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 S966230AbeE2Snd (ORCPT + 99 others); Tue, 29 May 2018 14:43:33 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:40741 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965960AbeE2Sn3 (ORCPT ); Tue, 29 May 2018 14:43:29 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9564321C34; Tue, 29 May 2018 14:43:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 29 May 2018 14:43:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=LgeeEpI4mYibLDnWjwFllPkWruFym gV3jRA1bvG2mB4=; b=hvR8CTeIkEPheWw//Wam6n1LOz0NFt1FVa1hSvjANN/J6 W415MvzaUBusZ0kxxnMZdxTQW+7TToMszJsFQbij7442a371QE7x88d7+dJ+Twxe YIyFKCFLFh7Z8cxYMslYt4ihsXLSRkZtWSg8/G39/s6g1AInn3BZYrrG9qBHkNgc mRNFFHpOhRQF42NPsHCaFHHS3IZ2TbfCiCZapkXGoZHrhq+3yhR26RLKqY/15alY g9zSr2ewjPUZktHOl9nL07316P6YhhtyCj62I5IyxtvjflmVSp8+G0HSU6dqjiLT Y+xet1pfaTKATFB7deBaS1dL2Tuq9vSldItBJxosg== X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Proxy: X-ME-Sender: Received: from localhost (lfbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.messagingengine.com (Postfix) with ESMTPA id D883EE4F68; Tue, 29 May 2018 14:43:27 -0400 (EDT) Date: Tue, 29 May 2018 20:43:08 +0200 From: Greg KH To: Fenghua Yu Cc: Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Ashok Raj , Dave Hansen , Rafael Wysocki , Tony Luck , Alan Cox , Ravi V Shankar , Arjan van de Ven , linux-kernel , x86 Subject: Re: [RFC PATCH 10/16] x86/split_lock: Add a debugfs interface to allow user to enable or disable #AC for split lock during run time Message-ID: <20180529184308.GC10618@kroah.com> References: <1527435965-202085-1-git-send-email-fenghua.yu@intel.com> <1527435965-202085-11-git-send-email-fenghua.yu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1527435965-202085-11-git-send-email-fenghua.yu@intel.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 27, 2018 at 08:45:59AM -0700, Fenghua Yu wrote: > User wants to enable or disable #AC for split lock during run time. > > The interface /sys/kernel/debug/x86/split_lock/enable is added to allow > user to control #AC for split lock and show current split lock status > during run time. > > Writing 1 to the file enables #AC for split lock and writing 0 disables > #AC for split lock. > > Reading the file shows current eanbled/disabled status of #AC for split > lock: > 0: disabled and 1: enabled. > > Signed-off-by: Fenghua Yu > --- > arch/x86/kernel/cpu/test_ctl.c | 92 ++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 92 insertions(+) > > diff --git a/arch/x86/kernel/cpu/test_ctl.c b/arch/x86/kernel/cpu/test_ctl.c > index a2f84fcd4da1..e8b3032f3db0 100644 > --- a/arch/x86/kernel/cpu/test_ctl.c > +++ b/arch/x86/kernel/cpu/test_ctl.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > > #define DISABLE_SPLIT_LOCK_AC 0 > @@ -34,6 +35,14 @@ static DEFINE_MUTEX(reexecute_split_lock_mutex); > static int split_lock_ac_kernel = DISABLE_SPLIT_LOCK_AC; > static int split_lock_ac_firmware = DISABLE_SPLIT_LOCK_AC; > > +static DEFINE_MUTEX(split_lock_mutex); > + > +struct debugfs_file { > + char name[32]; > + int mode; > + const struct file_operations *fops; > +}; > + > /* Detete feature of #AC for split lock by probing bit 29 in MSR_TEST_CTL. */ > void detect_split_lock_ac(void) > { > @@ -292,6 +301,85 @@ static struct syscore_ops split_lock_syscore_ops = { > .resume = split_lock_bsp_resume, > }; > > +static int enable_show(void *data, u64 *val) > +{ > + *val = split_lock_ac_kernel; > + > + return 0; > +} > + > +static int enable_store(void *data, u64 val) > +{ > + u64 msr_val; > + int cpu; > + > + if (val != DISABLE_SPLIT_LOCK_AC && val != ENABLE_SPLIT_LOCK_AC) > + return -EINVAL; > + > + /* No need to update MSR if new setting is the same as old one. */ > + if (val == split_lock_ac_kernel) > + return 0; > + > + mutex_lock(&split_lock_mutex); > + mutex_lock(&reexecute_split_lock_mutex); > + > + /* > + * Wait until it's out of any re-executed split lock instruction > + * window. > + */ > + wait_for_reexecution(); > + > + split_lock_ac_kernel = val; > + /* Read split lock setting on the current CPU. */ > + rdmsrl(MSR_TEST_CTL, msr_val); > + /* Change the split lock setting. */ > + if (split_lock_ac_kernel == DISABLE_SPLIT_LOCK_AC) > + msr_val &= ~MSR_TEST_CTL_ENABLE_AC_SPLIT_LOCK; > + else > + msr_val |= MSR_TEST_CTL_ENABLE_AC_SPLIT_LOCK; > + /* Update the split lock setting on all online CPUs. */ > + for_each_online_cpu(cpu) > + wrmsrl_on_cpu(cpu, MSR_TEST_CTL, msr_val); > + > + mutex_unlock(&reexecute_split_lock_mutex); > + mutex_unlock(&split_lock_mutex); > + > + return 0; > +} > + > +DEFINE_DEBUGFS_ATTRIBUTE(enable_ops, enable_show, enable_store, "%llx\n"); > + > +static int __init debugfs_setup_split_lock(void) > +{ > + struct debugfs_file debugfs_files[] = { > + {"enable", 0600, &enable_ops}, > + }; > + struct dentry *split_lock_dir, *fd; > + int i; > + > + split_lock_dir = debugfs_create_dir("split_lock", arch_debugfs_dir); > + if (!split_lock_dir) > + goto out; > + No need to test this, just keep moving on. You should never need to test the result of any debugfs call at all. > + /* Create files under split_lock_dir. */ > + for (i = 0; i < ARRAY_SIZE(debugfs_files); i++) { > + fd = debugfs_create_file(debugfs_files[i].name, > + debugfs_files[i].mode, > + split_lock_dir, NULL, > + debugfs_files[i].fops); > + if (!fd) > + goto out_cleanup; Same here, no need to test anything. > + } > + > + return 0; This function can not fail, might as well make it return void :) thanks, greg k-h