Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp4069884rwb; Tue, 20 Sep 2022 08:24:47 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6mQGy9OqaapfZGIDEOjKMuddaD5DwyADuj3GlTo4fvYEhERKp+RK3a+y1V7K6+f8zcuRPq X-Received: by 2002:a17:90b:1e0d:b0:202:91ec:e167 with SMTP id pg13-20020a17090b1e0d00b0020291ece167mr4373329pjb.174.1663687487584; Tue, 20 Sep 2022 08:24:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663687487; cv=none; d=google.com; s=arc-20160816; b=mgJB65xUCclXQ3Ae8YjXBG1ROyMTK0SexJSUrRva2Zxj+s/siuue6+fSYYMLEMGTwp JDGsqU5sttLVo2pvywwO+vJ8WI2txmaYKD3RgvSD+imeBTs7yORyvZ24LvBgPkZCvXdA 9NRWNQrPXcCPV+UAiJc4yTgwhNk+DVhz0UERO6JILRg6f9oBfFcNOzcUcIK8YuVQ4Fpd hrZ2571ZEFpnwh+0h+l63HQZKlA5CDpnCskiHTutsj1dFsiYhhpMUt9n71TUjXie18GM zT91ImUjRLNehGzXMSOwY5gbp/Vm9Xl9fJ01OA+tuJN51AFbdDqp9erBd5SvBs9JB8aj jGZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=rVCj1Z6o47e32mIXRmowfP7fQ3qZLRNq+TWzmyTF7eg=; b=vfYDxsH0rkU2NN6dpKMC2KTZ1snPBv7YfuYrlZcCw2aAIHYW4rSxlEQQex4kjgjeqI QshZoTet/A+AoH2+gGNvuXGILO5SyUeW7zgLAeruCrSrfuLrtQ48w7s94JoRwlADWkw8 DNTfLv2S4iMehW0LUvOP5x4/KgySQyMJh9+6FBInbrBhotpwD0yuEChg82l7OkKZoCse U83xCjTtxT8dWFZyASVDpytCscGPbIsx/Al5OxRkJNOok6tloW/JESbVI7SFn0V6NUR7 JJoJsFF9l8hJPIMfqQKVaQs3JWzOoCLbJ5jb2z0lKXdmfU2wXsZo+JZCVo6IYyR0zpnT VCFQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id u6-20020a170902e80600b0016a6381f70esi100841plg.42.2022.09.20.08.24.35; Tue, 20 Sep 2022 08:24:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231469AbiITPQO (ORCPT + 99 others); Tue, 20 Sep 2022 11:16:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32884 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231363AbiITPPv (ORCPT ); Tue, 20 Sep 2022 11:15:51 -0400 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 31718606A7; Tue, 20 Sep 2022 08:15:49 -0700 (PDT) Received: from dggpemm500023.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4MX4mV3FPczpTJm; Tue, 20 Sep 2022 23:12:58 +0800 (CST) Received: from dggpemm500013.china.huawei.com (7.185.36.172) by dggpemm500023.china.huawei.com (7.185.36.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 20 Sep 2022 23:15:46 +0800 Received: from ubuntu1804.huawei.com (10.67.175.36) by dggpemm500013.china.huawei.com (7.185.36.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Tue, 20 Sep 2022 23:15:46 +0800 From: Chen Zhongjin To: , , CC: , , , , , , , , , , , , , , , , , , , , Subject: [PATCH -next 3/7] riscv: stacktrace: Save pt_regs in encoded fp on irq entry Date: Tue, 20 Sep 2022 23:11:58 +0800 Message-ID: <20220920151202.180057-4-chenzhongjin@huawei.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20220920151202.180057-1-chenzhongjin@huawei.com> References: <20220920151202.180057-1-chenzhongjin@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.175.36] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemm500013.china.huawei.com (7.185.36.172) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org To support stack unwinding at irq entry, the position of pt_regs saved on stack is nessesary. Because for some functions, compiler only push s0/fp on stack without ra. As the situation described in commit f766f77a74f5("riscv/stacktrace: Fix stack output without ra on the stack top") When irq happens there, the the function frame looks like: prev function | ... | | | normal function +-----------------+ | ra to prev | | s0 of prev | | ... |<-+ leaf function +-----------------+ | | s0 of normal | | | empty slot | | irq pt_regs +-----------------+ | | epc (ra to leaf)| | | ra (ra to norm)| | | ... | | | s0 of leaf |--+ | ... | +-----------------+ If the position of register in pt_regs is {epc, s0}, we can easily unwind from irq frame to leaf function, as normal functions do. However when unwinding from unwinding from leaf to normal, beacause (ra to norm) is saved in pt_regs, but not stackframe of leaf, we have to get pt_regs for that. To get pt_regs position on stack, we can save the encoded *pt_regs in s0, as x86 architecture did. Then we can get s0, epc and ra easily. Signed-off-by: Chen Zhongjin --- arch/riscv/include/asm/frame.h | 45 ++++++++++++++++++++++++++++++++++ arch/riscv/kernel/entry.S | 3 +++ 2 files changed, 48 insertions(+) create mode 100644 arch/riscv/include/asm/frame.h diff --git a/arch/riscv/include/asm/frame.h b/arch/riscv/include/asm/frame.h new file mode 100644 index 000000000000..2a1f45cf3a4e --- /dev/null +++ b/arch/riscv/include/asm/frame.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_RISCV_FRAME_H +#define _ASM_RISCV_FRAME_H + +#include + +#ifdef CONFIG_FRAME_POINTER + +#ifdef __ASSEMBLY__ + +/* + * This is a sneaky trick to help the unwinder find pt_regs on the stack. The + * frame pointer is replaced with an encoded pointer to pt_regs. The encoding + * is just setting the LSB, which makes it an invalid stack address and is also + * a signal to the unwinder that it's a pt_regs pointer in disguise. + * + * This macro must be used when sp point to pt_regs + */ +.macro ENCODE_FRAME_POINTER + add s0, sp, 0x1 +.endm + +#else /* !__ASSEMBLY__ */ + +#define ENCODE_FRAME_POINTER \ + "add s0, sp, 0x1\n\t" + +#endif /* __ASSEMBLY__ */ + +#else /* !CONFIG_FRAME_POINTER */ + +#ifdef __ASSEMBLY__ + +.macro ENCODE_FRAME_POINTER ptregs_offset=0 +.endm + +#else /* !__ASSEMBLY */ + +#define ENCODE_FRAME_POINTER + +#endif /* !__ASSEMBLY */ + +#endif /* CONFIG_FRAME_POINTER */ + +#endif /* _ASM_RISCV_FRAME_H */ diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index b9eda3fcbd6d..ecb15c7430b4 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -13,6 +13,7 @@ #include #include #include +#include #if !IS_ENABLED(CONFIG_PREEMPTION) .set resume_kernel, restore_all @@ -95,6 +96,8 @@ _save_context: REG_S s4, PT_CAUSE(sp) REG_S s5, PT_TP(sp) + ENCODE_FRAME_POINTER + /* * Set the scratch register to 0, so that if a recursive exception * occurs, the exception vector knows it came from the kernel -- 2.17.1