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 44ED5C47DD9 for ; Fri, 22 Mar 2024 12:54:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CD4086B008A; Fri, 22 Mar 2024 08:54:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C84986B008C; Fri, 22 Mar 2024 08:54:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4BEC6B0092; Fri, 22 Mar 2024 08:54:23 -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 A57486B008A for ; Fri, 22 Mar 2024 08:54:23 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 71061C07F3 for ; Fri, 22 Mar 2024 12:54:23 +0000 (UTC) X-FDA: 81924668406.14.B17F8FD Received: from szxga07-in.huawei.com (szxga07-in.huawei.com [45.249.212.35]) by imf12.hostedemail.com (Postfix) with ESMTP id 5759240019 for ; Fri, 22 Mar 2024 12:54:19 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711112061; 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=FC5a2f4FI4n8MEDecQbGG7hGTZpMO0lnAmW5pKg69gU=; b=bBmOxyvyGBOTKbpXnR5He099wdmMg8dTaquIrr6skLAPmB71hkPNW0ux7TycCV4gQtMoL0 n1tLbOnv9e6MnxpA/EOTIYx++wtMtYdTuPTxtlqBaCWUs3ac2f/NSxwSYZ/khwX9LH2ZIM 8qjo9jWA/M2sinphyZyVQPaA8vWiFFc= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf12.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.35 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711112061; a=rsa-sha256; cv=none; b=wyTo1ohE8QvfZfdXH5+XdL3qCQx8t2xtM9NSA7heeY2i8HGsRuMHy62W79HEcLB8oauYx9 7DTmq0I2fCNMGw8wiXOYecXVgo+gtXjJzJRMhkyumEPSl8xKQnWDo9a0nkyxD5vGBkYjji +9OD8yrNCNm7xMK9beKfus+2aGibYh0= Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga07-in.huawei.com (SkyGuard) with ESMTP id 4V1Mf408bbz1R7yR; Fri, 22 Mar 2024 20:51:40 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id 93F6118005F; Fri, 22 Mar 2024 20:54:15 +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; Fri, 22 Mar 2024 20:54:15 +0800 Subject: Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case To: "Russell King (Oracle)" , David Laight References: <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com> <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> <2b2993fb215c4a5abd7d77ff1c984113@AcuMS.aculab.com> CC: Ard Biesheuvel , "arnd@arndb.de" , "keescook@chromium.org" , "haibo.li@mediatek.com" , "angelogioacchino.delregno@collabora.com" , "amergnat@baylibre.com" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "douzhaolei@huawei.com" , "gustavoars@kernel.org" , "jpoimboe@kernel.org" , "kepler.chenxin@huawei.com" , "kirill.shutemov@linux.intel.com" , "linux-hardening@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-arm-kernel@lists.infradead.org" , "nixiaoming@huawei.com" , "peterz@infradead.org" , "wangbing6@huawei.com" , "wangfangpeng1@huawei.com" , "jannh@google.com" , "willy@infradead.org" From: Jiangfeng Xiao Message-ID: <18f5c5fd-4a5d-0c33-9d73-7e94c1e42f3f@huawei.com> Date: Fri, 22 Mar 2024 20:54:09 +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: dggems706-chm.china.huawei.com (10.3.19.183) To canpemm500010.china.huawei.com (7.192.105.118) X-Rspamd-Queue-Id: 5759240019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xg6y1zaymetkawsc45x9z6n1598efqze X-HE-Tag: 1711112059-226562 X-HE-Meta: U2FsdGVkX1/IsSuxCNDVNKSi+bcW6MBS2ed7JTcc3wU2TC7K0jknOZsWby/YsgCgzPkthy0yB2SpYi7117462euW7xeKXxKkY4HWrwR+bAHO4c5aJYTk6XyPYd/h8ZGG3qLq8BsHOglaMhsfB0owjsmJ0bqBgQiuQo5MdP7YogKO3DLz3PC/jhYbk8cQgVzJIPxOoM2A3+3K+xEHbfoWdFjtXkHqqh+p+fF1CRJFbtOS0DE97bXf4vaQV6yX33HhsP5axP9z6HB/Agp4QLnjRbtwNgJnLvNj+qaLiy9Shqz+b1l72w+5CFtOcFO0ZebOvI8K0rg821PVmxFVTGuCrIO2N03l9BCD8r4pvS9kOFdXOP2IfKT+C/ceb4Ij8DegfnWaAcbLficYd1moRMYjaB8WASo6NlvJyXLcB36Pp/2B/DTuZzcjaIG6wqNcfmG4/4jKhaDLGQrDDedjPXBljjIgv2mXOmj+gIhkCbGJsPgd7KfCVhlgiMzUbHiqy1BLB+5yNeovHYbe1SVq7en62mHgpFRonsfzUgoa4z2m8VUYASjY5BIv6NoMbfzYA8Jx47kIdI3V3usIKDyhmNNbX8kr6uQwP9OnYCTtv1GHhE1w3dPunPITxkbWCTWTKnyO4C13nHv4Ff7KpifohrSExIBgPW2HHhwwiQUG4d/1XHyn749LpqXDcnbRHhM9Vrc0EdMMsUmC1EYI44fHJdHnBQBaiav2OZ7DJxYRq3bJ/sCz5odAvg4K2FVL7AaNlL8qRAf89fF5EM3AAFalybBW98ud9nEgWyNoixFmePZ5ma209hHARceqDl5S6uYqD7om1quk9cDCPyscx9tUqUytp1qp32o5E8f3s6CobBYbtJkr6LoUKrrBrvcxMPm443LYJR4FDSKeiNbFc3hPjBOsemro3Gl+GdePupz1tsnTsllWW3R38O6diu7W3gygXA/bjnYsz3losYzj6uyfrHC kiLEp41J PKtxV4dF4Pb8i0Y0YNETdfQNOIhwvFaO/QNR3uvMfvRpya4BYNP4whzKOtTcCP4EspoqrUaICGHw0yswMaVoVrUURroH2kMkl7WlT8NPMSuqwXq64G+sVb6ICwX7pVqJi7TH35o8lGqipId4Ol+zWIOG1HPeCGjz/jQKd3fD5YwJYIKY= 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/22 17:52, Russell King (Oracle) wrote: > On Fri, Mar 22, 2024 at 09:24:20AM +0000, David Laight wrote: >> From: Russell King >>> Sent: 22 March 2024 00:09 >>> >>> On Thu, Mar 21, 2024 at 11:43:41PM +0100, Ard Biesheuvel wrote: >>>> Given that this particular issue would just disappear if the compiler >>>> would just insert a BRK after the BL, I'd prefer to explore first >>>> whether we can get this fixed on the compiler side. >>> >>> Arm32 doesn't have a BRK instruction. What would be appropriate after >>> the no-return BL would be OS specific. >> >> It would need to depend on what was being compiled. > > Yes, but as for the rest... > >> For the kernel it could be much the same as BUG(). >> (Probably without any extra data.) >> I suspect that arm32 could use 'swi' in kernel space, >> but you wouldn't want to use that in userspace. >> >> Looks like armv5 has a bkpt instruction - could that be used? >> Or does the kernel need to support armv4? >> >> The last arm I wrote anything for was a strongarm. > > Thank you David, but remember - I have programmed 32-bit Arm since 1992, > and wrote the majority of the 32-bit Arm kernel support. I think I know > what I'm walking about by now. > > The compiler can't do the same as BUG() - that is a kernel specific > construct and not an architecture one. It is an undefined instruction > specifically chosen to be undefined on both 32-bit and 16-bit Arm ISAs. > > As for your idea of using "swi" in kernel space, no that's never going > to happen - to shoe-horn that into the SWI exception path for the sake > of the compiler would be totally idiotic - it would cause userspace > performance regressions for something that never happens. Moreover, > with EABI the "comment" field in the "swi" instruction is ignored so > all SWIs under EABI are treated the same. So no, that's not going to > work without causing inefficiencies - again - for a case that will > likely never happen. > > Whereas we already provide an abort() function because iirc the > compiler used to emit branches to that due to noreturn functions. If > correct, there's previous convention for doing this - and abort() is > still exists in the kernel and in userspace since it's part of ANSI > C. This would be a more reliable and portable solution, but probably > not for embedded platforms - and that's probably why it got removed. > > There isn't going to be a single solution to this which satisfies > everyone, and I don't blame the compiler people for deciding to > basically give up with putting any instruction after a call to a > no-return function - because there isn't an instruction defined in > the architecture that _could_ be put there that would work everywhere. > If the compiler inserts (a branch to 'abort') behind (no-return BL) that does not apply to ARM32 embedded platforms, do you think the "[PATCH v3] ARM: unwind: improve unwinders for noreturn case" submitted the day before yesterday can be used as a complementary solution? 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. When we hit the second type of frame, "pc-1" is closer to callsite, and no problem is introduced. In addition, the issue of the 'noreturn' can be solved.