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.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 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 45B3BC433DB for ; Wed, 27 Jan 2021 19:56:10 +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 CDF8860C40 for ; Wed, 27 Jan 2021 19:56:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CDF8860C40 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=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:Date:Message-ID:References: To:Subject:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=r/E9V5LaM0uUMqKvQuM6LsgtMCAfScXXeN6HeYkk5BA=; b=VCe0sjmcc3HnXKELcXdXdF5Uy aqWwOU7msWMgEmW1ulvbTATRQ6Q8MDNP/DBlcQLiNNZ0SnRqEept9pHAd6O9BMp1LVf9u8hvsJ+g3 feNxkwCYuyLtI/E4KFZAuQYYjElKQAa8Iy0IYFK1w19UD389eNoADZL3sKSG2sIYN3Y7iFuYSGZJ9 ACVWydD98DhfuMNCiVZbGz6jtx+eBKD2r56eFCXRqqexcrTzt/glNOLxauWPQ+bw13BY6k8EKD+ZR QZZa5rcLBeCXSK1uBCabQiEOZVxoM2fqHsQxuPY7TzrUdwRCHk0UfoM937lQtU6/a4Lxk16Tf40cI vn5s2HuEQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4qtb-0005JP-BM; Wed, 27 Jan 2021 19:54:31 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l4qtW-0005Hl-6E for linux-arm-kernel@lists.infradead.org; Wed, 27 Jan 2021 19:54:29 +0000 Received: from [192.168.254.32] (unknown [47.187.219.45]) by linux.microsoft.com (Postfix) with ESMTPSA id B293E20B7192; Wed, 27 Jan 2021 11:54:22 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B293E20B7192 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1611777263; bh=9Gi3U3Oe897rlvkwSrmHpGC4FNpIy9XGt1Gn6Jsl0zw=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From; b=jMPkzZuy8yXwtqq0/SaiUYsoodgudguE936q0n6ObCjz5fmF3GKfWSH4Ktb/5qlg0 hC/VYHNofHZfyEuJ7Qb3NpHqQgfHEhHQ4WA+jDOCK815UXF9DAb2KL0uo2vekGdKR5 ZhtwYKzhenYQMncaxaGP6PYffNX5Lwczi5M/rNik= From: "Madhavan T. Venkataraman" Subject: Re: [RFC PATCH 0/3] arm64: Implement reliable stack trace To: Mark Brown , Catalin Marinas , Will Deacon References: <20201012172605.10715-1-broonie@kernel.org> Message-ID: <13095563-ff6d-b806-1bf3-efde4383456e@linux.microsoft.com> Date: Wed, 27 Jan 2021 13:54:21 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201012172605.10715-1-broonie@kernel.org> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210127_145426_527476_F718964B X-CRM114-Status: GOOD ( 27.44 ) 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: Mark Rutland , Miroslav Benes , linux-arm-kernel@lists.infradead.org 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 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(-) > FP and no-FP functions ===================== I have a suggestion for objtool and the unwinder for ARM64. IIUC, objtool is responsible for walking all the code paths (except unreachable and ignored ones) and making sure that every function has proper frame pointer code (prolog, epilog, etc). If a function is found to not have it, the kernel build is failed. Is this understanding correct? If so, can we take a different approach for ARM64? Instead of failing the kernel build, can we just mark the functions as: FP Functions that have proper FP code no-FP Functions that don't May be, we can add an "FP" flag in the symbol table entry for this. Then, the unwinder can check the functions it encounters in the stack trace and inform the caller if it found any no-FP functions. The caller of the unwinder can decide what he wants to do with that information. - the caller can ignore it - the caller can print the stack trace with a warning that no-FP functions were found - if the caller is livepatch, the caller can retry until the no-FP functions disappear from the stack trace. This way, we can have live patching even when some of the functions in the kernel are no-FP. Does this make any sense? Is this acceptable? What are the pitfalls? If we can do this, the unwinder could detect cases such as: - If gcc thinks that a function is a leaf function but the function contains inline assembly code that calls another function. - If a call to a function bounces through some intermediate code such as a trampoline. - etc. For specific no-FP functions, the unwinder might be able to deduce the original caller. In these cases, the stack trace would still be reliable. For all the others, the stack trace would be considered unreliable. Compiler instead of objtool =========================== If the above suggestion is acceptable, I have another suggestion. It is a lot of work for every new architecture to add frame pointer verification support in objtool. Can we get some help from the compiler? The compiler knows which C functions it generates the FP prolog and epilog for. It can mark those functions as FP. As for assembly functions, kernel developers could manually annotate functions that have proper FP code. The compiler/assembler would mark them as FP. Only a small subset of assembly functions would even have FP prolog and epilog. Is this acceptable? What are the pitfalls? This can be implemented easily for all architectures for which the compiler generates FP code. Can this be implemented using a GCC plugin? I know squat about GCC plugins. Thanks! Madhavan _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel