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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3730EC433F5 for ; Wed, 9 Mar 2022 12:14:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Date:Message-Id:MIME-Version:Subject:To :From:Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=xxqKqhAxf1lvYynyacVTEdV/tl6I6BZvI29d/8o4O9A=; b=R76HONEJijHfWf RZgQPsWqrzXRYujP2pmpbxErPmUVdhwkop8BwAV1tcsiAQK0lyUsSYtZqgBdyrXWHCjGnLOHIY8EE /JmRR63qNXUa+7kAiC1gCTNo23ZfrauIH2Jf+EaL4FJk0d7Hnix4OkOfOpPBAWV2GLxPyUH6VBvpF LMJ3QEg8kxBS749KIqoacGOfQFet28+q1roa88TJFSkTKwFPDQtf4c4Xd6yGcn4vpagQdEkICZcj/ Ndxx1XHwnJ7/wm5OK1BW9TsxHfN27Rwx8B0Ax7IO7gVa1cC33JMvuS3qNT5cUU0rtaisC2VvBIgwd XXxaEdujrX9WvQgxXg5g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRvBb-008W3X-W2; Wed, 09 Mar 2022 12:13:00 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nRvBW-008VP9-Iy for linux-arm-kernel@lists.infradead.org; Wed, 09 Mar 2022 12:12:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Date:Sender:Message-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:Subject:To:From:Reply-To:Cc:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gSAGfLmK6HH8v9hsNNADluE9gZwEqvY8dDBBV1yaLtc=; b=SgJEaoH9hgiP8D6ZQzRDDOpLGq X0uaBElDvkyF8bp19WegRcpM575RxV8IDIPyn5+xwh6bEUE8JcZzrE/33QQr+J9LfEt6PYmJC9V41 BK6BEws558QBdSZ15Wjfc46KxbWMt6OE4ETDEUCZDTZoMk1Eqpvi/1lvPOLEB+4bFS8zRQ6LXjCRw gzk80aNS1aMITUHYc1C8LpcoRarcOP4Vv6QuJ4APiXXt1aX1piixyDqpTVNyaotPqrfTLJLcoqCBZ Ay3ZusVCtyPtkwx0ULznK7Di04aXm+OlCUZVEfcLKCRq9c80OyuYfxpQEVwL3YyELEy2SzWVnEd95 V8TVqNlA==; Received: from e0022681537dd.dyn.armlinux.org.uk ([fd8f:7570:feb6:1:222:68ff:fe15:37dd]:52656 helo=rmk-PC.armlinux.org.uk) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nRv9V-0001mk-8q; Wed, 09 Mar 2022 12:10:49 +0000 Received: from rmk by rmk-PC.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1nRv9U-00F7R4-Mn; Wed, 09 Mar 2022 12:10:48 +0000 From: "Russell King (Oracle)" To: linux-arm-kernel@lists.infradead.org, Ard Biesheuvel Subject: [PATCH] ARM: unwind: set frame.pc correctly for current-thread unwinding MIME-Version: 1.0 Content-Disposition: inline Message-Id: Date: Wed, 09 Mar 2022 12:10:48 +0000 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220309_041254_670982_0B725432 X-CRM114-Status: GOOD ( 13.35 ) 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 When e.g. a WARN_ON() is encountered, we attempt to unwind the current thread. To do this, we set frame.pc to unwind_backtrace, which means it points at the beginning of the function. However, the rest of the state is initialised from within the function, which means the function prologue has already been run. This can be confusing, and with a recent patch from Ard, can result in the unwinder misbehaving if we want to be strict about the PC value. If we correctly initialise the state so it is self-consistent (in other words, set frame.pc to the location we are initialising it) then we eliminate this confusion, and avoid possible future issues. Signed-off-by: Russell King (Oracle) --- arch/arm/kernel/unwind.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c index a007af0f0209..0e2244e26f37 100644 --- a/arch/arm/kernel/unwind.c +++ b/arch/arm/kernel/unwind.c @@ -487,7 +487,12 @@ void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk, frame.fp = (unsigned long)__builtin_frame_address(0); frame.sp = current_stack_pointer; frame.lr = (unsigned long)__builtin_return_address(0); - frame.pc = (unsigned long)unwind_backtrace; + /* We are saving the stack and execution state at this + * point, so we should ensure that frame.pc is within + * this block of code. + */ +here: + frame.pc = (unsigned long)&&here; } else { /* task blocked in __switch_to */ frame.fp = thread_saved_fp(tsk); -- 2.30.2 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel