Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1640947yba; Tue, 2 Apr 2019 12:49:54 -0700 (PDT) X-Google-Smtp-Source: APXvYqxdYPWC0yS3n+ttUrhcg8UIOLrkMucWHCqA2xTAXO8Twpva9asAov5Qh0JZrmi6wxx5Fcym X-Received: by 2002:a17:902:b617:: with SMTP id b23mr10725489pls.73.1554234594658; Tue, 02 Apr 2019 12:49:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554234594; cv=none; d=google.com; s=arc-20160816; b=ODuZ33bAenfNXz7mqTQSmNJwgWP8x1MGLOT0ja1gTXWx0Qa2ydROf7rZ8E0fLvGSf0 ZnhpeP6B8yd5A25pORy1KS3Yyj+u/7VRfIUbrR+O+3uO+f/lEl0w1YqAPrsd+HDMaeaK J9yTJDeiP23z5JXUCxaUbLL876Crz3QlFgHTZJVcT5kUH0lUTioZN4u9jyg0+n7nH951 ESbW+dHp0OHQpgneaDCKSsRJNXrekY4X0FMdnPIsNPicvsPn0mERc6tnqxe+2coNbyoA yekDkU1MSUq0u+rmDazLV7R978sMf5CnbJktxaM+SJS1OwCQFl7f02KxVdsHYugw9vKV tDGQ== 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=o3eATjW/7DApu2a0xvGqrUf/BYe+xtEMhngNaiG07Fk=; b=y5jhqovlO1Xv7PzwuYscpGnSEWyS+zZDEjyjvRV9HAQTTK26sGWQ9A6VIiP+orMqeB Vxrciz4N2yUP9/+GcRX2TsRKWDCPFbrEDWupeot0se5X3btJ6mT7tICSkQLH55BwM/6W Wkic3dILyDGoppAb5bSuQM2isiGtRf29dl5MTwykqqJMvYcvA3UxS3qfmPcaTA/1yIHs 0PMCuazAJMVVDTq+GRi9dDjpzVIrjU2u08vb9AWw5AmCKVK2rQXs+HzLheNT3TdKGDqg nI8VVQ3+ZEBnTcaPCRnytRXVF8NKzNQV9zNyL1z/gWgQXgfK3S9fgeWJdAQpIfCUs+rO mx3w== 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 f66si12814607plb.378.2019.04.02.12.49.39; Tue, 02 Apr 2019 12:49:54 -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 S1730668AbfDBTVi (ORCPT + 99 others); Tue, 2 Apr 2019 15:21:38 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:37758 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726083AbfDBTVi (ORCPT ); Tue, 2 Apr 2019 15:21: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 1hBOyU-0006lf-Rf; Tue, 02 Apr 2019 21:21:34 +0200 Date: Tue, 2 Apr 2019 21:21:34 +0200 (CEST) From: Thomas Gleixner To: Rasmus Villemoes cc: Josh Poimboeuf , LKML , x86@kernel.org, Andy Lutomirski Subject: Re: [patch 15/14] x86/dumpstack/64: Speedup in_exception_stack() In-Reply-To: <4db4323f-3416-54a8-27e3-c491827a2fbd@rasmusvillemoes.dk> Message-ID: References: <20190331214020.836098943@linutronix.de> <20190331215136.039902969@linutronix.de> <20190402154329.scp7i7uqevubgwrz@treble> <4db4323f-3416-54a8-27e3-c491827a2fbd@rasmusvillemoes.dk> 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, Rasmus Villemoes wrote: > On 02/04/2019 17.48, 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. > > Eh, but why do you need the CONDRANGE thing at all? [5 ... 5] is a > perfectly fine designator, equivalent to [5]. So you can just use > PAGERANGE in all cases, no? Indeed. I tried that before and at some point GCC barfed, but probably due to some other slipup. The macro expansion error messages are soo helpful... Thanks, tglx