Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1642165yba; Tue, 2 Apr 2019 12:51:45 -0700 (PDT) X-Google-Smtp-Source: APXvYqzH88wL7xStVJePoRmTLhVfzcktTvD1AV7lbRsuvXUH1ks9HbMKqH7LR07QZjRDLBugUQzy X-Received: by 2002:a65:51c9:: with SMTP id i9mr12819971pgq.187.1554234705081; Tue, 02 Apr 2019 12:51:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554234705; cv=none; d=google.com; s=arc-20160816; b=pZ6Of2EFXTKsr5vuoS9235MAE/cW9R+gH6e2jVeEwe2PftaMlHA9EJKx2fv3nN5jCh NcHFOJR9R1u4llmx6cEj0hFeDDh1rSIcq8cx73nMQRf/ZCMFcnYi5D6eXsLsxLren9Z9 1njObQZhMBzHWjboVvPFgRQJFdshxhOV9k1ZrKU2cH6f3wVz18W0wOTqgc01gjO7Km2t l1RNJaVRwIfVEFn1koMQeFbTBOX6S+mGfGFhQZnh3oLOojCAV5MeJp7l1CSnKb5uNVq4 3UfOEw3zaQu1e0A/Y8hyTkthFEgc6rsN7eaXK5aS6NzSU4/dGEIQU4lHegYcD23xqlEv K66A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=QypfFQDWaHSQxWHtC2nZM5uZY69oVJ/XuzRPGxk4GiU=; b=OY5ys0y81M9CSAKygEWXWXZleXpDzX0E3YMHPazQ/GxlhgwmcDboPOEaKCX/m9pl/U GCB1nA3bISeag0XV1jfYQncoTFBGKDBcGzGCWejl+qgnN21OSCVVtPn2qE6WxY5CH2Iz 6P8NCJYMlb/9UEltFiS6FaLIiLvevJhaAZ2iBdwiCO1nGHoO4VdIG2wV2NoT+l6KO4O7 CEyogAOR15yOY7fljfZpRjLW2GeRmVm3yIpH+Q019ReHWGn8alIRcmlimIbKf3A0nVia QXdaJjUJfc3Pux4sjB5AtKgrApDfsbGR3A9Q3UBC3XPpqplJDvIJSVkavOA1lDOpKgiu PzvQ== 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 t66si12122391pfb.178.2019.04.02.12.51.29; Tue, 02 Apr 2019 12:51:45 -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 S1730931AbfDBT3i (ORCPT + 99 others); Tue, 2 Apr 2019 15:29:38 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:37771 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726732AbfDBT3i (ORCPT ); Tue, 2 Apr 2019 15:29:38 -0400 Received: from p5492e2fc.dip0.t-ipconnect.de ([84.146.226.252] helo=nanos) by Galois.linutronix.de with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1hBP6E-0006sp-Mt; Tue, 02 Apr 2019 21:29:34 +0200 Date: Tue, 2 Apr 2019 21:29:34 +0200 (CEST) From: Thomas Gleixner To: Andy Lutomirski cc: Josh Poimboeuf , LKML , x86@kernel.org, Andy Lutomirski Subject: Re: [patch 15/14] x86/dumpstack/64: Speedup in_exception_stack() In-Reply-To: Message-ID: References: <20190331214020.836098943@linutronix.de> <20190331215136.039902969@linutronix.de> <20190402154329.scp7i7uqevubgwrz@treble> <7789E14E-C623-4DB7-B076-76B931957C9C@amacapital.net> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Linutronix-Spam-Score: -1.0 X-Linutronix-Spam-Level: - X-Linutronix-Spam-Status: No , -1.0 points, 5.0 required, ALL_TRUSTED=-1,SHORTCIRCUIT=-0.0001 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Apr 2019, Thomas Gleixner wrote: > On Tue, 2 Apr 2019, Andy Lutomirski wrote: > > > On Apr 2, 2019, at 9:48 AM, Thomas Gleixner wrote: > > > > > >> On Tue, 2 Apr 2019, Josh Poimboeuf wrote: > > >>> On Tue, Apr 02, 2019 at 12:19:46PM +0200, Thomas Gleixner wrote: > > >>> +/* > > >>> + * Array of exception stack page descriptors. If the stack is larger than > > >>> + * PAGE_SIZE, all pages covering a particular stack will have the same > > >>> + * info. > > >>> + */ > > >>> +static const struct estack_pages estack_pages[ESTACK_PAGES] ____cacheline_aligned = { > > >>> + [CONDRANGE(DF)] = ESTACK_PAGE(DOUBLEFAULT_IST, DF), > > >>> + [CONDRANGE(NMI)] = ESTACK_PAGE(NMI_IST, NMI), > > >>> + [PAGERANGE(DB)] = ESTACK_PAGE(DEBUG_IST, DB), > > >>> + [CONDRANGE(MCE)] = ESTACK_PAGE(MCE_IST, MCE), > > >> > > >> It would be nice if the *_IST macro naming aligned with the struct > > >> cea_exception_stacks field naming. Then you could just do, e.g. > > >> ESTACKPAGE(DF). > > > > > > Yes, lemme fix that up. > > > > > >> Also it's a bit unfortunate that some of the stack size knowledge is > > >> hard-coded here, i.e #DB always being > 1 page and non-#DB being > > >> sometimes 1 page. > > > > > > The problem is that there is no way to make this macro maze conditional on > > > sizeof(). But my macro foo is rusty. > > > > How about a much better fix: make the DB stack be the same size as all > > the others and just have 4 of them (DB0, DB1, DB2, and DB3. After all, > > overflowing from one debug stack into another is just as much of a bug as > > overflowing into a different IST stack. > > That makes sense. Except that we just have two not four. It needs some tweaking of the ist_shift stuff in entry_64.S but that's not rocket science. Famous last words.... Thanks, tglx