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 17:11:09 -0000 Received: from mga06.intel.com ([134.134.136.31]) by Galois.linutronix.de with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1j70DD-0002cf-6E for speck@linutronix.de; Wed, 26 Feb 2020 18:11:08 +0100 Received: from localhost (mtg-dev.jf.intel.com [10.54.74.10]) by smtp.ostc.intel.com (Postfix) with ESMTP id 4D87D6361 for ; Wed, 26 Feb 2020 17:11:02 +0000 (UTC) Date: Wed, 26 Feb 2020 09:11:03 -0800 From: mark gross Subject: [MODERATED] Re: [PATCH v2 1/2] v2: more sampling fun 1 Message-ID: <20200226171103.GA114268@mtg-dev.jf.intel.com> Reply-To: mgross@linux.intel.com References: <20200226110737.GB17448@zn.tnic> MIME-Version: 1.0 In-Reply-To: <20200226110737.GB17448@zn.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: speck@linutronix.de List-ID: On Wed, Feb 26, 2020 at 12:07:37PM +0100, speck for Borislav Petkov wrote: > On Thu, Feb 06, 2020 at 02:11:02PM -0800, speck for mark gross wrote: > > From: mark gross > > Subject: [PATCH v2 1/2] Add capability to specify a range of steppings in= the > > vulnerability white list structure. > >=20 > > From: mark gross > > Subject: [PATCH v2 1/2] Add capability to specify a range of steppings in= the >=20 > That second subject is incomplete. Do just one pls. Ok FWIW the instructions for using the speckify-gitmail said something about copying the subject and from lines into the body. > Also, you need a subject prefix: >=20 > x86/CPU: Add ... ok >=20 > git log arch/x86/ >=20 > is your friend if you're wondering what to call it. Thanks! > > Intel has produced processors with the same CPUID family+model. Code > > may need to check the stepping when programming model specific behavior. > >=20 > > Add an API to allow easy specification of stepping or range of steppings > > with a 16 bit bitmask. > >=20 > > Update cpu_vuln_whitelist using this new API. > >=20 > > I implemented this in the way I did to avoid modifying x86_cpu_id as > > that structure is an exported ABI and any change would impact user mode > > code using the structure. >=20 > Exported ABI? Which usermode code uses this? The module loading tools? Yeah, Andi pointed it out to me on an internal review. I don't know what tool is using it. >=20 > Even if, we do add new struct members at the end of exported structs > just fine. So what is the problem here? FWIW doing it this way made a cleaner patch without touching a dozen other files using that structure. I'd rather stay with the way it is but, if you feel strongly I can do a version of what I had before only adding the new members to the end. Please let me know. > > Signed-off-by: mark gross > > Reviewed-by: tony luck >=20 > Please write names capitalized. Ok. Thanks! --mark > --=20 > Regards/Gruss, > Boris. >=20 > SUSE Software Solutions Germany GmbH, GF: Felix Imend=C3=B6rffer, HRB 36809= , AG N=C3=BCrnberg > --=20