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=-9.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 5D82BC433C1 for ; Tue, 23 Mar 2021 14:59:28 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0466161983 for ; Tue, 23 Mar 2021 14:59:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0466161983 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=W+jXx77L8bpvf/1pdZsAHOzQ5A6xEp6EojfEkryhoyA=; b=j0VfPhoUTX1e/PxtTc/f9T3aR WM2WFD7SLcu31xmI58OL4dbqpi43yxmR0blD/b1BRHHf5yAASiZfQWnT39gOYgneLCfUkXmO7k44Z /L8hEBid/jGr7cj0J64DfaRbEy/wpeD0peAXGiqJcfNqERvxLIBbXnOFgyt26RnTqxQMKqaUzzrei d6Wkn1ztml9kCO+AOWG3Pj9EzLRbRHRC6ElILb6HxBiwo2E6qnar+8clxHAHrBAwPS1sqKLd233tC NN7TyAEWXRA9nnxx8Rm3MFrFDLTMxUqfCHYuvkYs8hbAojm4N9dvZNjyKg2qbthVdBlYfWQ3U+knz cehLpRvyQ==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lOiTZ-00FD9h-F0; Tue, 23 Mar 2021 14:57:45 +0000 Received: from foss.arm.com ([217.140.110.172]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lOiTU-00FD7n-LT for linux-arm-kernel@lists.infradead.org; Tue, 23 Mar 2021 14:57:42 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8CC77D6E; Tue, 23 Mar 2021 07:57:38 -0700 (PDT) Received: from C02TD0UTHF1T.local (unknown [10.57.24.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ADC963F718; Tue, 23 Mar 2021 07:57:36 -0700 (PDT) Date: Tue, 23 Mar 2021 14:57:34 +0000 From: Mark Rutland To: "Madhavan T. Venkataraman" Cc: broonie@kernel.org, jpoimboe@redhat.com, jthierry@redhat.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v2 5/8] arm64: Detect an FTRACE frame and mark a stack trace unreliable Message-ID: <20210323145734.GD98545@C02TD0UTHF1T.local> References: <5997dfe8d261a3a543667b83c902883c1e4bd270> <20210315165800.5948-1-madvenka@linux.microsoft.com> <20210315165800.5948-6-madvenka@linux.microsoft.com> <20210323105118.GE95840@C02TD0UTHF1T.local> <2167f3c5-e7d0-40c8-99e3-ae89ceb2d60e@linux.microsoft.com> <20210323133611.GB98545@C02TD0UTHF1T.local> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210323_145740_952733_5096D44B X-CRM114-Status: GOOD ( 13.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Mar 23, 2021 at 09:15:36AM -0500, Madhavan T. Venkataraman wrote: > Hi Mark, > > I have a general question. When exceptions are nested, how does it work? Let us consider 2 cases: > > 1. Exception in a page fault handler itself. In this case, I guess one more pt_regs will get > established in the task stack for the second exception. Generally (ignoring SDEI and stack overflow exceptions) the regs will be placed on the stack that was in use when the exception occurred, e.g. task -> task irq -> irq overflow -> overflow For SDEI and stack overflow, we'll place the regs on the relevant SDEI or overflow stack, e.g. task -> overflow irq -> overflow task -> sdei irq -> sdei I tried to explain the nesting rules in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/stacktrace.c?h=v5.11#n59 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64/kernel/stacktrace.c?h=v5.11&id=592700f094be229b5c9cc1192d5cea46eb4c7afc > 2. Exception in an interrupt handler. Here the interrupt handler is running on the IRQ stack. > Will the pt_regs get created on the IRQ stack? For an interrupt the regs will be placed on the stack that was in use when the interrupt was taken. The kernel switches to the IRQ stack *after* stacking the registers. e.g. task -> task // subsequently switches to IRQ stack irq -> irq > Also, is there a maximum nesting for exceptions? In practice, yes, but the specific number isn't a constant, so in the unwind code we have to act as if there is no limit other than stack sizing. We try to prevent cerain exceptions from nesting (e.g. debug exceptions cannot nest), but there are still several level sof nesting, and some exceptions which can be nested safely (like faults). For example, it's possible to have a chain: syscall -> fault -> interrupt -> fault -> pNMI -> fault -> SError -> fault -> watchpoint -> fault -> overflow -> fault -> BRK ... and potentially longer than that. The practical limit is the size of all the stacks, and the unwinder's stack monotonicity checks ensure that an unwind will terminate. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel