Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1458150yba; Tue, 2 Apr 2019 09:12:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqxT/bdKepxF8RGRgt3QNWJRp4kBu0bRnPJSB8oCuvuwd8S1gF9GxC6KzdqKjVb9slDF4Ddu X-Received: by 2002:a63:f707:: with SMTP id x7mr59387025pgh.343.1554221577386; Tue, 02 Apr 2019 09:12:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554221577; cv=none; d=google.com; s=arc-20160816; b=fYUNTEbRF/vwdh38jgkMUui2oljao3SMwwl4wR+3SIQIEud1zHsOXsZCA3alY7iT64 QQO3L1Wrd+ihcgRJVi0SqHFdwUvHGeiasLyenecLVdq52P2yFT+212uIX5gYDJXY9AYI jR0KyweNP2zjlRkv9t31JRA+LMmZSsKqL3yjAm/ZyTMezSKK1pJQnuD5NTjI3sSjUbby ZmOf8uBjjzGgcsmHHnLxjXBrRFzhr2Hy6mAOuSBl+nhvlvTtPryIsNbhNJ1ui7W/f4XR V+mSWQgz4735NkFcAEAaS2xlLIGSYt3c+OXEnuf7YTMkYdzbt5CPZRdAqm8Z66g3ZUhw x7Nw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=R5sYu8eFEFWeOED/6+uFY3pY5zrSN/jFLcMXCXb72Oc=; b=slf5pEbj2fCrucP4rGe3XI3CfKQW2vThv/GWThZdLTZi5n4xWfsASZi24/PZagxlwT ulq+9900U6KRTlxzZWfRTsG84xKe9r0cbyGsRhbStNaz7kyEHI0XbBe6AN30ZG0cERhF bC40W0QdRjSjWkwdRB2bg76UhguJx8olWpxHXiYRILoCS9usvpJDAUMs6zzTkSg0B27y N/6MJPYFVlNkHxPyArEiYuw6XDe3L7zWvZlKo2TCWTlfWLxmQBcTuKQKTgvFWUeJLklM p8MVVLHTlVxkyASTQAg78hDgL1cHo6RTt9vVSxTP5DBiZQxrn3ySBST8kYiUq2ssa8rb aMjQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=N8lS+KOJ; 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 h25si3161966pgv.244.2019.04.02.09.12.41; Tue, 02 Apr 2019 09:12:57 -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; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=N8lS+KOJ; 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 S1730089AbfDBQLX (ORCPT + 99 others); Tue, 2 Apr 2019 12:11:23 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:44460 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726792AbfDBQLX (ORCPT ); Tue, 2 Apr 2019 12:11:23 -0400 Received: by mail-pg1-f193.google.com with SMTP id i2so6796530pgj.11 for ; Tue, 02 Apr 2019 09:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R5sYu8eFEFWeOED/6+uFY3pY5zrSN/jFLcMXCXb72Oc=; b=N8lS+KOJ1/xe+vodMT0FXgXWRkaWf0Y8Hrt6dbd7LqpskOBBWQWGJxToIJo7S3Oq5u qqqtQ0RaOS54608K1HWBpeleUoR6ScuNpWxQxMNdLKS60a7H55ydyRG5rMHZmV5qdFCR lIBQFo+628b7u6N/RzeORwdSkhz+lc/3/3NJUzPnNxUvEa9MkZMGJaPQG8Wyh8xDIP2F 8cAthFMLlC2AY2ZWayNZS63oemkvjOCPKX6ftufNf2qvXxs2Qp/RKhK7kGN51Rpj53iY oaB+uQk00ftEbTtRTRpjvxw7tseVYx7oVfd8uHEYZbDtNe5FMuo6mX3DHKatr11boFHS 94aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R5sYu8eFEFWeOED/6+uFY3pY5zrSN/jFLcMXCXb72Oc=; b=SUVZoCMHv9Y3MYJvzhJG3ZtjkMzOLxZkFwLuoWR7dzaJKmWOM3NpnjPlF6mZa59ZFF qUV08yqUtqma9exho8vJtMQ4rkpkbDWXCVIL738jUNgUoLdNCE9NaqOO33vpBId+sm21 Twwy1nMjPFLmL2a5Bs/+yxlRUKGSy5oYe8PzhrLvShDCCDpy5zYFMRbJD3NeBV+/mDb6 6dATZtlaxyVnpjOiz0wWhIW2bJi9hzXNFvIpaaq52x7UskXdnQkDxxdwtBnUukleYb5i qTzqDvZKoaspEKPMTzPmNET7aFk/Nlm73BUbPblo54a08B3MBbpiGb9xiNcQbJjQm0/E AofA== X-Gm-Message-State: APjAAAVqJ7H3letrnh00Y3j7cgdxnB9cRU2v3Uvt581UkxbZKfsHJhPQ djsDEXZKb863jT2PZQFcd/8ZNQ== X-Received: by 2002:a63:4e5b:: with SMTP id o27mr67984364pgl.204.1554221482513; Tue, 02 Apr 2019 09:11:22 -0700 (PDT) Received: from ?IPv6:2600:100e:b118:ffaf:d107:e4b0:1269:f9d6? ([2600:100e:b118:ffaf:d107:e4b0:1269:f9d6]) by smtp.gmail.com with ESMTPSA id v188sm23811377pgb.7.2019.04.02.09.11.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 09:11:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: [patch 15/14] x86/dumpstack/64: Speedup in_exception_stack() From: Andy Lutomirski X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Tue, 2 Apr 2019 10:11:19 -0600 Cc: Josh Poimboeuf , LKML , x86@kernel.org, Andy Lutomirski Content-Transfer-Encoding: quoted-printable Message-Id: <7789E14E-C623-4DB7-B076-76B931957C9C@amacapital.net> References: <20190331214020.836098943@linutronix.de> <20190331215136.039902969@linutronix.de> <20190402154329.scp7i7uqevubgwrz@treble> To: Thomas Gleixner Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 2, 2019, at 9:48 AM, Thomas Gleixner wrote: >=20 >> 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 th= an >>> + * PAGE_SIZE, all pages covering a particular stack will have the same >>> + * info. >>> + */ >>> +static const struct estack_pages estack_pages[ESTACK_PAGES] ____cacheli= ne_aligned =3D { >>> + [CONDRANGE(DF)] =3D ESTACK_PAGE(DOUBLEFAULT_IST, DF), >>> + [CONDRANGE(NMI)] =3D ESTACK_PAGE(NMI_IST, NMI), >>> + [PAGERANGE(DB)] =3D ESTACK_PAGE(DEBUG_IST, DB), >>> + [CONDRANGE(MCE)] =3D ESTACK_PAGE(MCE_IST, MCE), >>=20 >> 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). >=20 > Yes, lemme fix that up. >=20 >> 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. >=20 > 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 o= thers and just have 4 of them (DB0, DB1, DB2, and DB3. After all, overflowi= ng from one debug stack into another is just as much of a bug as overflowing= into a different IST stack.