Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp485678imm; Mon, 4 Jun 2018 22:37:36 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKwUjSSGrgN3QtBBQqaB3WanGXD/OBsxvIM/LS20FszDWMNopgHOQSf8Ts77rHrvRyMQxt2 X-Received: by 2002:a62:a09c:: with SMTP id p28-v6mr24301175pfl.9.1528177055976; Mon, 04 Jun 2018 22:37:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528177055; cv=none; d=google.com; s=arc-20160816; b=LynECVSBJYYb65sID6fN5hkuFq+lPfah4aqudqoKGakV75MSYFO22dlxKnqivYa90y Mmz4OIuc49lc8dz2+6GTkW/Mugy+PgymVBVEuBpxrKkBigr6uQ6nIhXyIeTpxb5QMTuZ f6BG36rp0xoW014XqjcMJlyH2Uba9s1llysQFfargkHcJcv3dDiyzPAL5Cy6sVTxPlby 81U0HU/jtNVPLsPLXIgDZ/aQzUaLT6Em5IuHBcu86XVALv4UaoRGKojdquh9fbZ4OhLl 7yfDNl+H7O0PBHCIdsT1emmAdu2kNNGiPdiURZMMIM/cJguLSeN5Ocuuv63sh3nOttQX Uxew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=p19DD1d+cxcY8GFaE7u8KEZd+1camQtJP/g0oe9AMiE=; b=QSq8kWhJW13b68FPjl6AnZcEhQv9xt7yKrW0CUoEyJywanGzHSgG4h7qwFXrVT7UdS lEvKfGd3JOWCUHEWRTQN31Q5IyQSdckMT4P5PUtQlwHbx1RAdbs+RgsnpEG3NhWmgy00 EhxBAyPX2fCy0v272xSx+N08bGMRhERGpqeKSMwzhNVYcfqPLdMQzffxckX+4bmKPodu 8KT/yAb6ytzMqaDVG4KVSrb/lb94nM523hrbotq2y0oNFEx/6XVZvI1tWqUvoDj9G6ZD Hu2C59+LeyiQWIet4KsE1TPfH/iv/e4X/PjwrXcmujkIeQy3XD5TXrQ+tzyUy4rVbtGW IHLg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m9-v6si11649139pll.578.2018.06.04.22.37.21; Mon, 04 Jun 2018 22:37:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751605AbeFEFgp (ORCPT + 99 others); Tue, 5 Jun 2018 01:36:45 -0400 Received: from terminus.zytor.com ([198.137.202.136]:54435 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751501AbeFEFgo (ORCPT ); Tue, 5 Jun 2018 01:36:44 -0400 Received: from carbon-x1.hos.anvin.org (c-24-5-245-234.hsd1.ca.comcast.net [24.5.245.234] (may be forged)) (authenticated bits=0) by mail.zytor.com (8.15.2/8.15.2) with ESMTPSA id w555aWmm1244793 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 4 Jun 2018 22:36:33 -0700 Subject: Re: [PATCH 6/6] x86/vdso: Move out the CPU number store To: =?UTF-8?Q?Mika_Penttil=c3=a4?= , "Chang S. Bae" , Andy Lutomirski , Thomas Gleixner , Ingo Molnar Cc: Andi Kleen , Dave Hansen , Markus T Metzger , "Ravi V . Shankar" , LKML References: <1528140269-26205-1-git-send-email-chang.seok.bae@intel.com> <1528140269-26205-7-git-send-email-chang.seok.bae@intel.com> <8a41304a-3517-003a-badf-1ba8f7ababe4@nextfour.com> From: "H. Peter Anvin" Message-ID: <51587908-9652-6a8e-0e01-f387e3ae5852@zytor.com> Date: Mon, 4 Jun 2018 22:36:27 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <8a41304a-3517-003a-badf-1ba8f7ababe4@nextfour.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/04/18 20:57, Mika Penttilä wrote: > > This won't work on X86-32 because it actually uses the segment limit with fs: access. So there > is a reason why the lsl based method is X86-64 only. > Why does that matter in any shape, way, or form? The LSL instruction doesn't touch any of the segment registers, it just uses a segment selector number. I see... we have a VERY unfortunate name collision: the x86-64 GDT_ENTRY_PERC_PU and the i386 GDT_ENTRY_PERCPU are in fact two completely different things, with the latter being the actual percpu offset used by the kernel. So yes, this patch is wrong, because the naming of the x86-64 segment is insane especially in the proximity of the -- it should be something like GDT_ENTRY_CPU_NUMBER. Unfortunately we probably can't use the same GDT entry on x86-32 and x86-64, because entry 15 (selector 0x7b) is USER_DS, which is something we really don't want to screw with. This means i386 programs that execute LSL directly for whatever reason will have to understand the difference, but most of the other segment numbers differ as well, including user space %cs (USER_CS/USER32_CS) and %ds/%es/%ss (USER_DS). Perhaps we could bump down segments 23-28 by one and put it as 23, that way the CPU_NUMBER segment would always be at %ss+80 for the default (flat, initial) user space %ss. (We want to specify using %ss rather than %ds, because it is less likely to be changed and because 64 bits, too, have %ss defined, but not %ds.) Rename the x86-64 segment to CPU_NUMBER, fixing the naming conflict. Add 1 to GDT entry numbers 23-28 for i386 (all of these are kernel-internal segments and so have no impact on user space). Add i386 CPU_NUMBER equivalent to x86-64 at GDT entry 23. Document the above relationship between segments. OK, everyone? -hpa