Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1580234yba; Tue, 2 Apr 2019 11:33:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqweD9l37BlLiBzvMrQIctIuE+uD/KouqQIBhYYE7athiGBAVanblHd5pkkZDrcU35FOa4L7 X-Received: by 2002:a63:fd06:: with SMTP id d6mr46294545pgh.183.1554230024676; Tue, 02 Apr 2019 11:33:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554230024; cv=none; d=google.com; s=arc-20160816; b=0/qA0El2R4WpU1OId/daeAmtCG/354eNq/4qTlxu1AvNxjmDa+X3Qmu1RboUPcIgyR RCNsC+fk52WVeeIFRyhgEvfPE6qKMbHKtw5ZAPK/aHwMa87WaD6Q6Sdutvm3z9e9KkNI 0JKWxnqK/ctjJEZlshTbi5Scf5lDTSXOcPiAWYYf0lpORhXc6MiVCrdxASQt6S98qWoy 6XJtthftMM1EVk+/wwcewDVwEQm7cWzfcNlrFHOgNjsmHg8deWLdrZ/KGKRFxd4QHw0z n/PUweeJ1f6KE5nAaGplMSkVtXwmNl/3NCjy3KhJhtIzLwjr8lS45ESe8KSRtLXPRa0O shkg== 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=qLSNNtp4FaUHsLoi9KCwKN7VfEMVSudDfNxqBvcFFPA=; b=Fy26SkUrCcRZcMn+RBjWYkLRo+dSwYheZJDtrC+50HECeSg17cQlxzgHRosDqelP/M P5Otj+sRZa4JkVLUOP/NWbMXy4Yoi50xkIBopB1VpyOKdCcxAoWYWgmbYjYp3QmW6ivd 2dY2FRyURMbQITCPO2F7N7+PSIFwaoHxY3tmyGOpRaduPDoWmaJFDOOtQC//wtFIB5YJ WWOIfl+KDVjW7etBweWLTMGUfnThrxAdypEAJkJv4vRche6hag4hGkGJh8XReIuWA5V6 mTQCMHwSQIcPpneOqfLo+5cPUuTkPe5UhhF5f27ARSSCzkLRbWSDFTKoQvJV/bEv9AKE qqBQ== 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 l7si11126962pgp.161.2019.04.02.11.33.29; Tue, 02 Apr 2019 11:33:44 -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 S1729482AbfDBS20 (ORCPT + 99 others); Tue, 2 Apr 2019 14:28:26 -0400 Received: from Galois.linutronix.de ([146.0.238.70]:37680 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726558AbfDBS2Z (ORCPT ); Tue, 2 Apr 2019 14:28:25 -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 1hBO8z-0005zt-Dc; Tue, 02 Apr 2019 20:28:21 +0200 Date: Tue, 2 Apr 2019 20:27:45 +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: <7789E14E-C623-4DB7-B076-76B931957C9C@amacapital.net> 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, 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. Thanks, tglx