Received: by 2002:a25:ca44:0:0:0:0:0 with SMTP id a65csp1507012ybg; Wed, 29 Jul 2020 16:29:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVUqtC5oAr7E+ayLIDh6lqL21U0ngTAiufs4E3towVSSH3vzHzlKOzMyx1oRl7tDnAdZeA X-Received: by 2002:a17:906:1986:: with SMTP id g6mr4390ejd.404.1596065360778; Wed, 29 Jul 2020 16:29:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596065360; cv=none; d=google.com; s=arc-20160816; b=J+cewmynUVjAhLKELNQZOq07fwCIPndqHbrUZFvc7cUymCN/esO6+lHZISmbqdTCHg s9HdOvmzSXkQHFSVXvcw2AHkDuzCW7e8T5fAn8z5unidsuB4CDeIzMQXk0NrsL7JfnXU afc3xud1BevgI8mkYjGcpKNDWzO6KYKyV4/os0cft0rGvjQCHrGSpKwGXXWERm43zYAp syFyw3YKN8a2V+T5Nzq4zWiMQdXa+TCzDsdOVEQLz3MSQq7dsuoxhWsQKmcaNTcy1+Wh 74y3rOUj4Q7lE/g/Q6QIBPywBne5GDTZ2FY0loaa7l4ECbjdmEpidFJtSehuQHo397BQ VcRA== 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:ironport-sdr:ironport-sdr; bh=kbJLxZ3CfnPXFBV46W7igmXQ5tmyq7NS0ngd1fBYOQc=; b=RlJrOFrwvblUC4exRQY7o04WvODEWIJQ/EG3rUteyltJmTWMuyQ902vsiKOaI0HF81 NPLPReCVgXlj3RLYkReR76mPaAUhIGDuqUqEx3ltjAv/HUmR+4tSxZCHBVuqSaAjogdj R2jYEl4FxSyqKuhiLM5Q0JVSwYE6tFVC4vwqxkQu/B7VfmxIcjtwzUJ1SXJ40Uh2ohed 1VyQ0kv7mmUL2Gmns2AE0IEWPiCJLYeb8LXWlLzs6bvRpwm2oa/HX0HJKKwBkuSYw9lK h2+8o3mY8XJgSMZNSvGtw0NEwrfYGGYetRxxAiF27+C96M7GBE9M74BO6dR3DXqZmE9D 0StQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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. [23.128.96.18]) by mx.google.com with ESMTP id ds20si2512250ejc.65.2020.07.29.16.28.58; Wed, 29 Jul 2020 16:29:20 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1728052AbgG2X2L (ORCPT + 99 others); Wed, 29 Jul 2020 19:28:11 -0400 Received: from mga05.intel.com ([192.55.52.43]:31754 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726718AbgG2X2K (ORCPT ); Wed, 29 Jul 2020 19:28:10 -0400 IronPort-SDR: INjKOM/+yw7RBJgVKmxjxv1O/yz16A7RkrwIeODznbGGkaXlIxJ+BKnhTy43/np2N9N83E+Qzp 3MvaYLM4kgIQ== X-IronPort-AV: E=McAfee;i="6000,8403,9697"; a="236379224" X-IronPort-AV: E=Sophos;i="5.75,412,1589266800"; d="scan'208";a="236379224" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jul 2020 16:28:09 -0700 IronPort-SDR: 6IXRQWPsYnycLnkAm/UyYMMR5UZE3qBPgzTNyH6mvZ9S59ktFDmD4Pala+4/KnlmVTTrjlYyVL CX3Jm5sa3jMg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,412,1589266800"; d="scan'208";a="394804237" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.152]) by fmsmga001.fm.intel.com with ESMTP; 29 Jul 2020 16:28:08 -0700 Date: Wed, 29 Jul 2020 16:28:08 -0700 From: Sean Christopherson To: Fenghua Yu Cc: Thomas Gleixner , Borislav Petkov , Ingo Molnar , Peter Zijlstra , "Shanbhogue, Vedvyas" , "Luck, Tony" , H Peter Anvin , Andy Lutomirski , "Shankar, Ravi V" , "Li, Xiaoyao" , x86 , linux-kernel Subject: Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection Message-ID: <20200729232808.GP27751@linux.intel.com> References: <1595021700-68460-1-git-send-email-fenghua.yu@intel.com> <20200729030232.GE5583@linux.intel.com> <20200729184614.GI27751@linux.intel.com> <20200729194259.GA318576@otcwcpicx6.sc.intel.com> <20200729200033.GJ27751@linux.intel.com> <20200729203557.GA318595@otcwcpicx6.sc.intel.com> <20200729203905.GN27751@linux.intel.com> <20200729220714.GA318659@otcwcpicx6.sc.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200729220714.GA318659@otcwcpicx6.sc.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 29, 2020 at 10:07:14PM +0000, Fenghua Yu wrote: > Hi, Sean, > > On Wed, Jul 29, 2020 at 01:39:05PM -0700, Sean Christopherson wrote: > > On Wed, Jul 29, 2020 at 08:35:57PM +0000, Fenghua Yu wrote: > > > If sld=fatal and bld=ratelimit (both sld and bld are enabled in hw), > > > a split lock always generates #AC and kills the app and bld will never have > > > a chance to trigger #DB for split lock. So effectively the combination makes > > > the kernel to take two different actions after detecting a bus lock: if the > > > bus lock comes from a split lock, fatal (sld); if the bus lock comes from > > > lock to non-WB memory, ratelimit (bld). Seems this is not a useful combination > > > and is not what the user really wants to do because the user wants ratelimit > > > for BLD, right? > > > > I understood all off that. And as I user I want to run sld=fatal and > > bld=ratelimit to provide maximum protection, i.e. disallow split locks at > > all times, and ratelimit the crud SLD #AC can't catch. > > Then this will expand the current usages and do need two options. Let me work > on adding a new "bus_lock_detect=" option as you suggested. I'd wait for feedback from others before spending too much effort rewriting everything, I'm just one person with an opinion.