From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755939Ab0JDWUq (ORCPT ); Mon, 4 Oct 2010 18:20:46 -0400 Received: from terminus.zytor.com ([198.137.202.10]:58115 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753934Ab0JDWUp (ORCPT ); Mon, 4 Oct 2010 18:20:45 -0400 Message-ID: <4CAA52EF.3030302@zytor.com> Date: Mon, 04 Oct 2010 15:19:27 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100921 Fedora/3.1.4-1.fc13 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hugh Dickins CC: Linus Torvalds , Borislav Petkov , Ingo Molnar , Thomas Gleixner , lkml Subject: Re: [PATCH] x86, cpu: Fix X86_FEATURE_NOPL References: <20101003093701.GB3733@liondog.tnic> <4CA89681.8000202@zytor.com> <20101003152212.GA13233@liondog.tnic> <20101003201139.GA16532@liondog.tnic> <20101004073127.GA20305@liondog.tnic> <4CAA4102.3070205@zytor.com> <4CAA455D.8000902@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/04/2010 03:17 PM, Hugh Dickins wrote: > On Mon, Oct 4, 2010 at 2:21 PM, H. Peter Anvin wrote: >> On 10/04/2010 02:12 PM, Linus Torvalds wrote: >>> On Mon, Oct 4, 2010 at 2:02 PM, H. Peter Anvin wrote: >>>> >>>> Actually, cpu_has() depends on: >>>> #if defined(CONFIG_X86_P6_NOP) || defined(CONFIG_X86_64) >>> >>> Ahh. Right you are. The place that depends on just P6_NOP is the >>> default NOP choice logic in >>> >>> But the end result ends up being the same: can we please clean this >>> all up so that it isn't so confusing? Rather than add to the >>> confusion? >>> >> >> Agreed that this should be cleaned up. However, in the meantime I'd >> like to keep Borislav's patch in the tree since it makes the code >> technically correct at least. > > Another piece of the confusion I noticed a couple of days ago: > X86_MINIMUM_CPU_FAMILY defaults to "6" if X86_32 && > X86_P6_NOP; whereas X86_P6_NOP depends on X86_64. > Again, it's completely consistent -- if you keep in mind that CONFIG_X86_P6_NOP depending on X86_64 is a policy decision; that policy can theoretically be changed. However, it really doesn't seem worth it to ever contemplate at this point. -hpa