From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932876AbbDKIfg (ORCPT ); Sat, 11 Apr 2015 04:35:36 -0400 Received: from mail-wi0-f173.google.com ([209.85.212.173]:38239 "EHLO mail-wi0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932611AbbDKIfc (ORCPT ); Sat, 11 Apr 2015 04:35:32 -0400 Date: Sat, 11 Apr 2015 10:35:26 +0200 From: Ingo Molnar To: Borislav Petkov Cc: Andi Kleen , x86@kernel.org, luto@kernel.org, linux-kernel@vger.kernel.org, Andi Kleen , Thomas Gleixner , "H. Peter Anvin" , Peter Zijlstra , Denys Vlasenko , Andy Lutomirski Subject: Intel FSGSBASE support (was: Re: [PATCH 6/8] x86: Enumerate kernel FSGS capability in AT_HWCAP2) Message-ID: <20150411083526.GA16060@gmail.com> References: <1428681033-1549-1-git-send-email-andi@firstfloor.org> <1428681033-1549-7-git-send-email-andi@firstfloor.org> <20150410221418.GD28317@pd.tnic> <20150410230848.GC2366@two.firstfloor.org> <20150411071655.GA31568@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150411071655.GA31568@pd.tnic> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Borislav Petkov wrote: > On Sat, Apr 11, 2015 at 01:08:48AM +0200, Andi Kleen wrote: > > > > +/* HWCAP2 supplies kernel enabled CPU feature, so that the application > > > > + can know that it can safely use them. The bits are defined in > > > > + uapi/asm/hwcap.h. */ > > > > > > Comments formatting. > > > > The formatting matches all the other comments in the file. > > That doesn't mean you need to add new comments with the old > formatting which we're trying to get rid of. Exactly, and the thing is, I've seen this behavior before, so I'm also going to ignore all these Intel FSGSBASE patches from Andi Kleen, for the following technical reasons: - they are poorly written, - a necessary precondition of such features is the thorough (and constructively conducted) clean-up of the underlying code, - the series exposes a new user-space ABI that is going to be exposed forever and has to be done right on the first attempt, - unacceptable passive-aggressive behavior was directed by Andi against constructive, technical feedback from reviewers and maintainers. So consider Intel FSGSBASE support NACK-ed on these four technical grounds. All four problems have to be properly addressed (beyond addressing all the other feedback that was given) before the NACK is lifted. Maybe someone else has the time to pick up and deobfuscate (or entirely rewrite) these patches into a properly written series? The Intel FSGSBASE hardware feature itself looks potentially useful, so I'm not opposed to the concept itself. Thanks, Ingo