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=-10.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 73BD4C433DB for ; Tue, 23 Mar 2021 15:28: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 15956619B4 for ; Tue, 23 Mar 2021 15:28:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 15956619B4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.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:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AFo4O1yjHqok4VFFIWgsGZWRAdHZjYJxWeP+gawlNTQ=; b=d+JNs6OvuG8Zf1v5skUcblP0j mecxK2sdnw6X348sqEZ9sy8AIsJCWncYZvNzqLr+oR0W6m4rBzPgMtdUhKWUvBDGXeSciHkWSGJ8v JMd/gMkoO3cOqNXfV3NQzrHtX9hTRXfZzKwH/anx6DHv/ZcbqIXbNBBpuC1SOotLHhrWC0wxsG+sX QKTH5x81OZHlOL2ZyuPkSgiAHvSizoyvytN8a1rYeEZ5L+gJ361wyYbjOmSOLT/XN1JNGpyrFf7jQ /948WDiv6niUZfOHeVvlZDj2Zw8A00Bg5376sGlG/qC2vrBqntba5tm3nWADCImDGKaKvQZ3QF559 xbyRL7d9A==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lOivq-00FG5o-8R; Tue, 23 Mar 2021 15:26:58 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lOivl-00FG5I-4C for linux-arm-kernel@lists.infradead.org; Tue, 23 Mar 2021 15:26:55 +0000 Received: from [192.168.254.32] (unknown [47.187.194.202]) by linux.microsoft.com (Postfix) with ESMTPSA id 96DC720B5680; Tue, 23 Mar 2021 08:26:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 96DC720B5680 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1616513212; bh=d5zEZG4k7ovVr063Y6JJHF1nJVd22PuP0B4L3ZYyzlQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hnDT7VH5CrXQzd4FIlxRs4CW5S2gk098IVDOJi7NeUr3hSO9HAhljqBufGdG3THsw 1AvJIsXA+5MOYYxb3TTPtpKg17PWf0Ejpys7Ef51hcp1dcl6i7o8sGQuNoxsS9xizL Tr42rBSUgPKG3jS0twkIXT2dHNvVXNcPCtBBgCTY= Subject: Re: [RFC PATCH v2 5/8] arm64: Detect an FTRACE frame and mark a stack trace unreliable To: Mark Rutland 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 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> <20210323145734.GD98545@C02TD0UTHF1T.local> From: "Madhavan T. Venkataraman" Message-ID: Date: Tue, 23 Mar 2021 10:26:50 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210323145734.GD98545@C02TD0UTHF1T.local> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210323_152653_590592_67609B53 X-CRM114-Status: GOOD ( 24.40 ) 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 3/23/21 9:57 AM, Mark Rutland wrote: > 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 for explaining the nesting. It is now clear to me. So, my next question is - can we define a practical limit for the nesting so that any nesting beyond that is fatal? The reason I ask is - if there is a max, then we can allocate an array of stack frames out of band for the special frames so they are not part of the stack and will not likely get corrupted. Also, we don't have to do any special detection. If the number of out of band frames used is one or more then we have exceptions and the stack trace is unreliable. Thanks. Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel