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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8801C54E58 for ; Wed, 20 Mar 2024 16:05:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49EA76B0092; Wed, 20 Mar 2024 12:05:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 427546B0093; Wed, 20 Mar 2024 12:05:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A1176B0095; Wed, 20 Mar 2024 12:05:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 155A86B0092 for ; Wed, 20 Mar 2024 12:05:45 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D4F75160A3E for ; Wed, 20 Mar 2024 16:05:44 +0000 (UTC) X-FDA: 81917893008.01.3BAB79A Received: from szxga06-in.huawei.com (szxga06-in.huawei.com [45.249.212.32]) by imf04.hostedemail.com (Postfix) with ESMTP id 1F19940008 for ; Wed, 20 Mar 2024 16:05:40 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710950741; a=rsa-sha256; cv=none; b=2kxyciMJl40tAGg/yh0v9jx9ERlO1f47GiJZVmW1YP5RzGvh96Ce/Pn2P0Z0cMtsisKS3t Fi7z75tGRGShCBoUbzaT3633Igku5yohgxqtGuh6Gb6AMGK+GS1J6DTCD6DfNM99+eDun0 UIxGV0b7R8Ncy2DZ0q8qEg3WS4gbzWM= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.32 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710950741; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8JAfPmVmAiz7WkpkBS7ITg3x+3WG1bnmMr6RVjs7op4=; b=xaIZSKesybIXZImCbk3mu1Dh1aAlepgQ36IreohqBMjNExeSj8XwVXiWjP+2Gq5XsFLL49 BveG+avzo555EIlnFCb0rZq+iIVhqIagDJrLt1oxYbrrWn4kDbVvOUL4YXiDKWNk41sSO0 uSslbkMmgZx5jh/Xr0b6Eh95znmlO4c= Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga06-in.huawei.com (SkyGuard) with ESMTP id 4V0D1W2jdvz1vxBr; Thu, 21 Mar 2024 00:04:31 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id B91A41A0172; Thu, 21 Mar 2024 00:05:17 +0800 (CST) Received: from huawei.com (10.67.189.167) by canpemm500010.china.huawei.com (7.192.105.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 21 Mar 2024 00:05:17 +0800 From: Jiangfeng Xiao To: , , , , , , , , CC: , , , , , , , , , , , , , , , , , Subject: [PATCH v3] ARM: unwind: improve unwinders for noreturn case Date: Wed, 20 Mar 2024 23:41:34 +0800 Message-ID: <1710949294-29287-1-git-send-email-xiaojiangfeng@huawei.com> X-Mailer: git-send-email 1.8.5.6 In-Reply-To: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.67.189.167] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To canpemm500010.china.huawei.com (7.192.105.118) X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1F19940008 X-Stat-Signature: nbw5wd7yyfnutcrk7puhnzedi9mz3gqa X-HE-Tag: 1710950740-907033 X-HE-Meta: U2FsdGVkX18eTVtMlg00mke9Z0IYDHkmX8Kow0TGSY6AC07yW0D9bJSj48AepsfSEZ+tvvtmj40HzoBTVrRrbKYOL98i8go4raNLvEi6UQSFn2QJrm4XL9eWbiEh3lg27ieZGcVyD9qkagkbyamp81z3Rr2xucwX/SbtNH2c792MXe8ysiPRIAz0fsKrgrPLo0tOYtj0+assI8GXRPFRNc/bNSkc8VOTaC7P6N9BXeqc/Ivd6xjQBqJZjNuglIzczCX2gTkqaUJpGHPjiUqzBYOXo3JTDYzDSdx5HmqVaq9m86unmcABvFHlNukv5lEZmox7pjsdMf/xBXYxTGUZUQRhuknc/kS9ernpxIN+wZr/jlwTTEGJ6+B8iu7+EjrLXOaHxod5msL8KhoPN98AU+2TEOeMXZ/Zv0l63YVg6xsJatmT3pGKG7igN112FIf2DyIQQ1fE4swXDUimO7w80LgW6fGzCkidYFpJJGvP1e7K8jJ//mvm6sBtMIll71m8yckv3g8DjRvqNQYyYx+NU99mggyvKKF70tCuAfgh6HQaRoEFd14LjEc7pJLEGh50ijczzVsXI503dFA16NOs3CK2cderQlcfTCN+A2Q+XhIUADrHM3bvRB2ee60Bfjs6PKaupzVzM1HNteCvEUh6teeCmdwrl6Y3pQcV87e7VIjKXiXUJV64z6GuVnApgTEj9bwK9cf211YzTcXvZxHKtya8DvEgFkqLlpse2ULg8uWhnn0nIuP9fXGOADSI4JZlB5Qshn948jKAWg2fk9aYkMAdHSFIWKWcFSut3yOwCbqRs/OuSTUNzIw5ck7g45ZPXVYLS4lsnkBUUK/+jOwz+y3EpRownSmmIpRammR1pn1uh69kRkUu1yEYDFQnL5aU2aV0Tn6ZX0Meqg+hvr1J1jAdwPYZOG0KnRMsmnwvhc4k01/qR3mE3pSVlOG8ZKmzV0f0p2wG4lppTT//JCQ dwoJT8hE beqJptv1mXwojQ8NWlXqZ0JHeKr6oDcPPzxujWDrGyz9wkRJOhFhEPmk+kc4XYimQNG6VNFO0D2HbNmEDJu8tHQc+tJ3u0QlhzqKim505/urdVaWt7tQZD1kU1PkcZskC9y4hQm/L1f7M6S489e54CSjpGUjbl9pFVrGWJ4nDcNNsMhqjZsSA1iYeI+2HXHaPnag/vCU3ZwmX0s/7PKK9NBzGfr+uZW6fZQKQNobQg5Imz+H3TuR0mxK04WBiQSlXoYRzbDHgJm16uEoT4ghpoqRcsxHYPM9+t234s5HoWB45f/4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: This is an off-by-one bug which is common in unwinders, due to the fact that the address on the stack points to the return address rather than the call address. So, for example, when the last instruction of a function is a function call (e.g., to a noreturn function), it can cause the unwinder to incorrectly try to unwind from the function after the callee. foo: ... bl bar ... end of function and thus next function ... which results in LR pointing into the next function. Fixed this by subtracting 1 from frmae->pc in the call frame like ORC on x86 does. Refer to the unwind_next_frame function in the unwind_orc.c Suggested-by: Josh Poimboeuf Link: https://lkml.kernel.org/lkml/20240305175846.qnyiru7uaa7itqba@treble/ Suggested-by: "Russell King (Oracle)" Link: https://lkml.kernel.org/lkml/Zeg8wRYFemMjcCxG@shell.armlinux.org.uk/ Signed-off-by: Jiangfeng Xiao --- ChangeLog v1->v2 - stay printk("%s...", loglvl, ...) ChangeLog v2->v3 - Redundant code is deleted to simplify the code --- arch/arm/kernel/unwind.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c index 9d21921..abfa8e9 100644 --- a/arch/arm/kernel/unwind.c +++ b/arch/arm/kernel/unwind.c @@ -514,6 +514,14 @@ int unwind_frame(struct stackframe *frame) frame->sp = ctrl.vrs[SP]; frame->lr = ctrl.vrs[LR]; frame->pc = ctrl.vrs[PC]; + /* + * When the last instruction of a function is a function call + * (e.g., to a noreturn function), it can cause the unwinder + * incorrectly try to unwind from the function after the callee, + * fixed this by subtracting 1 from frame->pc in the call frame + * like ORC on x86 does. + */ + frame->pc = frame->pc - 1; frame->lr_addr = ctrl.lr_addr; return URC_OK; -- 1.8.5.6