From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932319AbeAMPgq (ORCPT + 1 other); Sat, 13 Jan 2018 10:36:46 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:34478 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755000AbeAMPgp (ORCPT ); Sat, 13 Jan 2018 10:36:45 -0500 Date: Sat, 13 Jan 2018 16:36:44 +0100 From: Greg KH To: Andi Kleen Cc: tglx@linutronix.de, dwmw@amazon.co.uk, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, arjan.van.de.ven@intel.com, peterz@infradead.org, Andi Kleen , jeyu@kernel.org Subject: Re: [PATCH] retpoline/module: Taint kernel for missing retpoline in module Message-ID: <20180113153644.GA25956@kroah.com> References: <20180112175507.31750-1-andi@firstfloor.org> <20180113141209.GA13015@kroah.com> <20180113145259.ofw2u656h4awdyzw@two.firstfloor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180113145259.ofw2u656h4awdyzw@two.firstfloor.org> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Sat, Jan 13, 2018 at 06:53:00AM -0800, Andi Kleen wrote: > > > When the a module hasn't been compiled with a retpoline > > > aware compiler, print a warning and set a taint flag. > > > > Isn't that caught by the "build with a different compiler/version" check > > that we have? Or used to have? If not, can't we just make it into that > > - the compiler version number may not change if a distribution backports > the gcc changes for the new flag > - the module might be using a custom make file that does not correctly > set the flag, even if the compiler supports it > > > type of check to catch this type of problem no matter what type of > > feature/option it is trying to catch? > > I suspect that would be far more complicated. Really? As Arjan points out, just mix it into the modversion symbol generation, that should cause it to be caught properly and trivially. > Also what's the point of putting this information into every symbol? It makes it easy to check :) > Once per module is good enough. > > We already have similar checks for staging etc. Sure, but this is more of a "Hey, your version of GCC is doing something different than what you built the kernel with, watch out!" which is much more generic and good to know. A whole taint for one CPU bug type seems overkill to me. thanks, greg k-h