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.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,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 6F605C433E0 for ; Wed, 27 Jan 2021 16:42:35 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 0B51B64D9D for ; Wed, 27 Jan 2021 16:42:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B51B64D9D 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=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=Sw2v7HEOOe1O2fM16cISiCqiYupKiUEGXvc1J1gPcfU=; b=gOdSNX+k/gS26vrjZbWTuqlYG SHt9AzCfZaN6s4gXttUQZ7aViZ73aRYEuQ7iNZRQgG6jCbupf616WT7MbOxnGFyg26sZiRCe0X8Cc NUVAiJqbR0xqeGfP/tFqTgXUG7SrhkDFzXEYUiHnut08JLGIOVS15G3XDzoKFnhsAJh1tSmrPmaIS f3yKPGP3bHxqPZ9U0Cxx5Dq69PCtd1gzkkLC/1LHYE9KOyKBh5Yo+2kJFs8NkaFvJmG4jwylxRafe zqlH18L3nTR+zOPNmih35AaMk8ZWzjDelnkvIp+rZ7Vcs8V9jbmisT1S47p88iFbvDcAobZb6ePWH 5BpMDrEcA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4nsZ-00056I-Jw; Wed, 27 Jan 2021 16:41:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4nsW-00055T-Lp for linux-arm-kernel@lists.infradead.org; Wed, 27 Jan 2021 16:41:13 +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 8DEB431B; Wed, 27 Jan 2021 08:41:03 -0800 (PST) Received: from C02TD0UTHF1T.local (unknown [10.57.42.54]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1406E3F66E; Wed, 27 Jan 2021 08:41:01 -0800 (PST) Date: Wed, 27 Jan 2021 16:40:56 +0000 From: Mark Rutland To: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace Message-ID: <20210127164056.GA66953@C02TD0UTHF1T.local> References: <20201012172605.10715-1-broonie@kernel.org> <6439edfb-5d4f-cf15-0059-bf7ff3bebb5c@linux.microsoft.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <6439edfb-5d4f-cf15-0059-bf7ff3bebb5c@linux.microsoft.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210127_114112_833916_1B3CF80C X-CRM114-Status: GOOD ( 28.37 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Catalin Marinas , Mark Brown , Will Deacon , linux-arm-kernel@lists.infradead.org, Miroslav Benes 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 Wed, Jan 27, 2021 at 08:02:41AM -0600, Madhavan T. Venkataraman wrote: > > > On 10/12/20 12:26 PM, Mark Brown wrote: > > This patch series aims to implement reliable stacktrace for arm64. > > Reliable stacktrace exists mainly to support live patching, it provides > > a version of stacktrace that checks for consistency problems in the > > traces it generates and provides an error code to callers indicating if > > any problems were detected. > > > > This is a first cut of support for arm64, I've not really even started > > testing it meaningfully at this point. The main thing I'm looking for > > here is that I'm not sure if there are any more potential indicators of > > unrelabile stacks that I'm missing tests for or anything about the > > interfaces that I've misunderstood. > > > > There's more work that can be done here, mainly that we could sync our > > unwinder more with what's done on S/390 and x86 which should if nothing > > else help with keeping up to date with generic changes, but this should > > be what's needed to allow reliable stack trace. > > > > Mark Brown (2): > > arm64: stacktrace: Report when we reach the end of the stack > > arm64: stacktrace: Implement reliable stacktrace > > > > Mark Rutland (1): > > arm64: remove EL0 exception frame record > > > > arch/arm64/Kconfig | 1 + > > arch/arm64/kernel/entry.S | 10 +++---- > > arch/arm64/kernel/stacktrace.c | 55 ++++++++++++++++++++++++++++------ > > 3 files changed, 52 insertions(+), 14 deletions(-) > > > > This is mostly a question to improve my understanding of the current ARM64 > unwinder. > > Currently, ARM64 defines different stack types - task stack, IRQ stack, etc. > When it unwinds, it appears to unwind only the currently active stack. The current (unreliable) unwinder will unwind across stack changes. That detects stack transiations and will happily unwind across multiple stacks so long as these do not loop. However, where a backtrace crosses an exception boundary, there are cases where this could in theory omit an entry from the backtrace because. The LR and FP are only guaranteed to be in a consistent state at function call boudaries, and since exceptions can be taken in the middle of functions (or trampolines which transiently place these in an inconsistent state) we cannot reliably backtrace across exception boundaries (which may or may not involve a change of stack), unless we had additional metadata and/or guarantees from compilers on how these are manipulated. Where we change stack without an exception boundary, we can reliably unwind. > Specifically, if an interrupt has happened and the IRQ stack is the one that > is active, only the IRQ stack is unwound. The task stack is not. Is this > accurate? The existing (unreliable) unwinder will unwind this case. The last frame record on the IRQ stack will point to a frame record on the task stack, and the unwinder will determine this can be safely accessed via the on_accessible_stack() check. It will subsequently reject any frame records on the IRQ stack (i.e. loops). > My question is - for live patching, we would need to look at the task stack > as well, right? Ideally, we would be able to do this, but currently we cannot safely do so. IIUC this means that live patching is still possible, but is potentially much slower to apply updates. > May be, we need to pass a flag to the unwinder to check the > task stack in addition to the active task? The logic to unwind across stack and exception boundaries already exists, but to make this reliable we will need more invasive work, potentially changing trampolines and/or adding metadata for these, perhaps requiring objtool and/or toolchain changes. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel