From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx2.suse.de ([195.135.220.15]) by Galois.linutronix.de with esmtps (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1fKTNu-00060C-UK for speck@linutronix.de; Sun, 20 May 2018 20:48:47 +0200 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 65578AC50 for ; Sun, 20 May 2018 18:48:41 +0000 (UTC) Date: Sun, 20 May 2018 20:48:38 +0200 (CEST) From: Jiri Kosina Subject: [MODERATED] Re: Date/Time? In-Reply-To: Message-ID: References: <20180519172627.GB1239@kroah.com> <20180520181934.GA705@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: speck@linutronix.de List-ID: On Sun, 20 May 2018, speck for Linus Torvalds wrote: > > Why wouldn't I also want the IBRS stuff for the upstream 4.4.y? Am I > > missing patches that I should have backported but didn't? > > I think Jiri is talking about the bat-shit-crazy stuff that I refused to > take upstream. The stuff that adds thousands of cycles to every kernel > entry and doesn't actually fix any real problem except for "but but in > theory" PR problems. Yes, that is exactly the one :) We are providing the option of toggling the IBRS on kernel entry/exit only on CPUs that can fall back to using (potentially) poisoned indirect branch predictor in case of RSB underflow (Skylake; fortunately on those CPUs the IBRS overhead is considerably lower than on other CPUs) if the user/admin wants to. And that is the same MSR as SSBD, so there will be some minor conflicts to resolve. -- Jiri Kosina SUSE Labs