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 EAC06C54E58 for ; Thu, 21 Mar 2024 09:44:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48EE66B0087; Thu, 21 Mar 2024 05:44:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 43F156B0088; Thu, 21 Mar 2024 05:44:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 307A86B0089; Thu, 21 Mar 2024 05:44:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 21BA36B0087 for ; Thu, 21 Mar 2024 05:44:22 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B86BAA100E for ; Thu, 21 Mar 2024 09:44:21 +0000 (UTC) X-FDA: 81920560722.18.FB01722 Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf13.hostedemail.com (Postfix) with ESMTP id 21C052000A for ; Thu, 21 Mar 2024 09:44:17 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.35 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=1711014259; a=rsa-sha256; cv=none; b=L+HPG9ACLEZINIpZOzkuVqT06CoBle/vL1PVCCqSI7Duh+4Sd0Q2VuHkUMBnPx1Ej2khdj l0ZYxDvRH6rA29Q4wE56R+KELCBOXi9+n1HZWdykYafZLV+RFpXAz9CpzZopy1vVm/eian B466YdoAHwqo5YQvK4ttwkuXVpNDhhs= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.35 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=1711014259; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G8W851vGJgllndMVT93YKSPiOHm5O+GzZntaTnMX6F0=; b=VEZFCr/AxX6/ZxTIfriIIw+yxLlC6r7WA/2w9T03Om9FluIx1asQtui3nIoKlWYYMGgTpT Oa8isui3HGpKaTdjrfeCpgcUMFiHjz09uiZKuC7i2Ym7VzYmHcOwD6chi+KsVTX3XQCQBG /YrHWT57QtBtx3MSIqLc8ZmueiKbESg= Received: from mail.maildlp.com (unknown [172.19.163.17]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4V0gTH1hZzz1R7hs; Thu, 21 Mar 2024 17:41:39 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id CD0C81A0188; Thu, 21 Mar 2024 17:44:13 +0800 (CST) Received: from [10.67.111.82] (10.67.111.82) 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 17:44:13 +0800 Subject: Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case To: "Russell King (Oracle)" References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com> <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> CC: , , , , , , , , , , , , , , , , , , , , , , From: Jiangfeng Xiao Message-ID: Date: Thu, 21 Mar 2024 17:44:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.67.111.82] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To canpemm500010.china.huawei.com (7.192.105.118) X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 21C052000A X-Stat-Signature: 4s7wfkr8nj3mj8oabt733kcki4xehsqg X-HE-Tag: 1711014257-87511 X-HE-Meta: U2FsdGVkX1/YY3+ZIOn/VMCLt3fWIhciAH5nCS8NKTNQDgmn7rCeV/jeXURGcAJi6UwaJelbY/VVnrAXVTIh3lQ6Ck7Yzp6LMcGPvhP1GSLg7fmqMMDPhC7kVCbqcMidplBwk3+XsvGFEoG7J/Q8nzuWhrUfCxEfWzQWQsko4kC2t99urrwy68rHGRn6VMK1Uc2RR98jTxX0X+MaaCjYMAmpMV2S+vJvi7e2riK+40NZ5mfJes93DsOAyh8KXdwLyu9plZ3n0jepNWt5lxb7pmirwasIqdXcgohtugPymVdkrnXSJSJsnJzdpn849VrmZzZ7Ohji1fIW+KpYrGXPwyFc0JJXYJCkFZEO3hNKxUAJHEHz46sB0PYZlkc9Nr/ZCjPP0na6dVxma2wTEUF0y2hksZa+ut7eQPQwStuInXL0p5413ogFL1l6quCs/cWqJj7BktNFZ/sM0CzoxaO7BmXkmgpG2wBxxWs0RnnyTYTr1N1eAhSpWeZesoxdrJdFcUA1wIJNVwqltacZATQF5Lxn3npsZgOKgjOtZCIbFJXxnXV3nX1S7o5MIg9sDkdLls80MZaH5+8d+eM6faELFBbz/BDhTyTEtLt1Tf/0E/XFVLWXbHlpBaTBgL+xIkERLtaNzymoSp62Lc21uSNheZhRkj66g3tgcki9fOm0Au1d5rB0+P9m5apLB/cHtplHTfx7etFrzkpxpgDm3KeqYEAVsoHRtHQ0hripZMFQfTgmQrA08I0rXT+DPx1s5hM/mTeK/F/2SsKa6n7cAHt9V8frhGU8u7kuKPd62l7z92sCk+nwEV/8C2vOSBzCjK9lfTKxN6+N35l4icREzV4eGi113yEgcWhSx8GAMRmwKhiUVrRjx1UFUXKcRW0fUHwKCFlJG3j3lATZwfPj347PkcaPcHuWtKssLJcY3zTdIo79lCpt0nmn6QgLF2nsvZOqZdXfAQ6fyz7sUHJjo9R VPmbVx7l ESzFt89bfiPWHkeK2gM30RxA2gDP88crpTnhSzYqwufSSEjD4OH/0q9n/cee+4TpPlamJDMG2eT5Z0poaqMeMe/8K4O/D8DtnbvmpFQSgevz1TKM2sKCjOsvmqwj1b1ZnuQI6 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: On 2024/3/21 3:40, Russell King (Oracle) wrote: > On Wed, Mar 20, 2024 at 11:30:05PM +0800, Jiangfeng Xiao wrote: >> >> >> On 2024/3/20 16:45, Russell King (Oracle) wrote: >>> On Wed, Mar 20, 2024 at 11:44:38AM +0800, Jiangfeng Xiao wrote: >>>> 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 >>>> (but not exception frames) like ORC on x86 does. >>> >>> The reason that I'm not accepting this patch is because the above says >>> that it fixes it by subtracting 1 from the PC value, but the patch is >>> *way* more complicated than that and there's no explanation why. >>> >>> For example, the following are unexplained: >>> >>> - Why do we always need ex_frame >> >> ``` >> bar: >> ... >> ... end of function bar ... >> >> foo: >> BUG(); >> ... end of function foo ... >> ``` >> >> For example, when the first instruction of function 'foo' >> is a undefined instruction, after function 'foo' is executed >> to trigger an exception, 'arm_get_current_stackframe' assigns >> 'regs->ARM_pc' to 'frame.pc'. >> >> If we always decrement frame.pc by 1, unwinder will incorrectly >> try to unwind from the function 'bar' before the function 'foo'. >> >> So we need to 'ext_frame' to distinguish this case >> where we don't need to subtract 1. > > This just sounds wrong to me. We have two different cases: > > 1) we're unwinding a frame where PC points at the offending instruction. > This may or may not be in the exception text. > 2) we're unwinding a frame that has been created because of a branch, > where the PC points at the next instruction _after_ that callsite. > > While we're unwinding, we will mostly hit the second type of frames, but > we'll only hit the first type on the initial frame. Some exception > entries will have the PC pointing at the next instruction to be > executed, others will have it pointing at the offending instruction > (e.g. if it needs to be retried.) Thank you for your summary. Now we try to enumerate all cases: 1) When we hit the first type of frames 1.1) If the pc pointing at the next instruction of the offending instruction 1.1.1) If the offending instruction is the first instruction of the function pc: cause to unwind from current function pc-1: casue to unwind from current function 1.1.2) If the offending instruction is neither the first instruction nor the last instruction of the function pc: cause to unwind from current function pc-1: casue to unwind from current function 1.1.3) If the offending instruction is the last instruction of the function pc: cause to unwind from next function pc-1: casue to unwind from current function 1.2) If the pc pointing at the offending instruction 1.2.1) If the offending instruction is the first instruction of the function pc: cause to unwind from current function pc-1: casue to unwind from previous function 1.2.2) If the offending instruction is neither the first instruction nor the last instruction of the function pc: cause to unwind from current function pc-1: casue to unwind from current function 1.2.3) If the offending instruction is the last instruction of the function pc: cause to unwind from current function pc-1: casue to unwind from current function 2) When we hit the second type of frames 2.1) pc always pointing at the next instruction after that callsite 2.1.1) If the callsite is the first instruction pc: cause to unwind from current function pc-1: casue to unwind from current function 2.1.2) If the callsite is neither the first nor last instruction pc: cause to unwind from current function pc-1: casue to unwind from current function 2.1.3) If the callsite is the last instruction pc: cause to unwind from next function pc-1: casue to unwind from current function All in all, I think you are right. In case 2), We can always unwind by 'pc-1'. In case 1), If we unwind by 'pc', case 1.1.3) is problematic. If we unwind by 'pc-1', 1.2.1) is problematic. > > So, I don't see what being in the exception/entry text really has much > to do with any decision making here. I think you've found that it works > for your case, but it won't _always_ work and you're just shifting the > "bug" with how these traces work from one issue to a different but > similar issue.