From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 21CF6C4360F for ; Tue, 2 Apr 2019 19:29:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E67EE2084B for ; Tue, 2 Apr 2019 19:29:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730970AbfDBT3i (ORCPT ); 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