From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.linutronix.de (193.142.43.55:993) by crypto-ml.lab.linutronix.de with IMAP4-SSL for ; 26 Feb 2020 22:37:04 -0000 Received: from mga12.intel.com ([192.55.52.136]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j75Id-0007qh-Hq for speck@linutronix.de; Wed, 26 Feb 2020 23:37:03 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 5BE566361 for ; Wed, 26 Feb 2020 22:36:59 +0000 (UTC) Date: Wed, 26 Feb 2020 14:37:00 -0800 From: mark gross Subject: [MODERATED] Re: [PATCH v2 2/2] v2: more sampling fun 2 Message-ID: <20200226223700.GE116192@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200226114641.GC17448@zn.tnic> <20200226173508.GB114268@mtg-dev.jf.intel.com> <20200226181325.GE17448@zn.tnic> MIME-Version: 1.0 In-Reply-To: <20200226181325.GE17448@zn.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Wed, Feb 26, 2020 at 07:13:25PM +0100, speck for Borislav Petkov wrote: > On Wed, Feb 26, 2020 at 09:35:08AM -0800, speck for mark gross wrote: > > > This "We" sounds like you mean Intel...? > > yes, this instance of "we" is an intel statement from that white paper I'm > > waiting on for the documentation patch. > > See how "we" means different things and how you should avoid it in > commit messages? yeah, the first instance of 'we' was an error. This second one was a copy and paste from the whitepaper. Next time I'll tweak what I copy and replace "we" with "intel" or just reword it. > IOW, pls use passive voice. ok. > > > I wrote it this way initially because at the time I expected there to be more > > dynamic support for managing this mitigation WRT post boot changes to TSX > > availability. The expectation I was later given was to make it a boot > > commandline control only. I kept it this way mostly out of laziness and > > simplification of the number of mitigation states to track. > > Drop it then. Drop it: as in disregard your comment on this point or Drop it: as in rework it to avoid the extra check for TSX availability? > > > srb_sampling is no more readable to me and doesn't convay what the > > command line is for. But, more readable is always better. > > Ok, let's see what better suggestions/preferences the others might have. > > > Perhaps changing into a single value, with any '=' like: > > disable_srbs_mitigation or srbds_mitigation_off would be better? > > You don't need to have "disable" or "off" in the actual command line > switch's name if you give it the on/off after the "=". ok > > And as I said already, you don't need to have a tautology by putting > "mitigation" in the mitigation option - it is a mitigation. My initial version just had "srbds=off" as the commanline. But, I noticed other mitigations included the "_mitigtion" and thought to mimic that. I like dropping the "_mitigation" part of the option. I will change it to just "srbds=off" for the next version. Thank you for the help! --mark