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 63D99C47DD9 for ; Fri, 22 Mar 2024 09:52:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FA7A6B0088; Fri, 22 Mar 2024 05:52:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9839A6B0089; Fri, 22 Mar 2024 05:52:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7FCFD6B008C; Fri, 22 Mar 2024 05:52:56 -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 6940D6B0088 for ; Fri, 22 Mar 2024 05:52:56 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 015C6C1392 for ; Fri, 22 Mar 2024 09:52:55 +0000 (UTC) X-FDA: 81924211152.29.039A6AA Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf16.hostedemail.com (Postfix) with ESMTP id E6824180002 for ; Fri, 22 Mar 2024 09:52:53 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=Y384k+jz; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf16.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711101174; h=from:from:sender: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:dkim-signature; bh=uY3ErBRSm13BWg/PRQDPTz4nkc8UUIhrKSwSU3A1w7U=; b=wZcguLQMZIv09zSiV8yuRy6WPIbRnDO0JW67xKU3WfqMUIQla+1yVlXbzIfZLubFHPXMMu EXCSIBfB2OXpYCk0nwBVd2xy7C9FtEzCTk+lg8CSoYa8htz0OYvvxsfeCGChxfQJD/McVv VAA61BwtPu0aRHO7dFx5uInbxDp0xms= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=Y384k+jz; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf16.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711101174; a=rsa-sha256; cv=none; b=vzL6/C9fDBKepFLX0kYUmU05NjUt4Jt8DlAppJDI+CnHVAkTvoAy1TDzCwCBDXjY7Rx7aJ 5+SlYHEgfohFgtaFuxZL1j+7w9SoZoKern9stBofkvpalGZH3ZE3KDtdrQ2XQrqLeaC02s YHKSuJrOmfLKYpvcF3Ui0+pwZNLj5Oc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uY3ErBRSm13BWg/PRQDPTz4nkc8UUIhrKSwSU3A1w7U=; b=Y384k+jzKaq1zpLti0tPPj9ga5 MNe50rOqiaFr4DqqJtrpa5NP1INK5UeoY34zpnnSteBYYYUajBQLdyy1U9zWiG+/kgjgaffsnzQ0J 1keQ8qPvs8MHWpN9QXTeEvBiMg37vNC0qwPQC6JVGIqKs563vXAJ37YbSJ/xvT1xWHIYRjFp09otU OYbqxq5EXKWY+ARCABdGy8Xr+tcpLKRNzl9CkkLqGLgIuRiYdgvSwbhg5xAHUwuUWE8ENBgmH0jfX 0NETo0ksPxJpcda3ZrZALDQO0wDdwRAhbd5TkOsT9YkqP+rFlBporRUq1fni/+o8sTOcKBTxNe/N3 jgcRP+Wg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:54618) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rnbZT-0000BM-0N; Fri, 22 Mar 2024 09:52:19 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rnbZL-0004bs-DT; Fri, 22 Mar 2024 09:52:11 +0000 Date: Fri, 22 Mar 2024 09:52:11 +0000 From: "Russell King (Oracle)" To: David Laight Cc: Ard Biesheuvel , Jiangfeng Xiao , "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" Subject: Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case Message-ID: References: <1710906278-23851-1-git-send-email-xiaojiangfeng@huawei.com> <84a57ca8-8963-ca24-8bd1-ddc5c33bf4da@huawei.com> <2b2993fb215c4a5abd7d77ff1c984113@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b2993fb215c4a5abd7d77ff1c984113@AcuMS.aculab.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: E6824180002 X-Stat-Signature: 964c4tzaqpbkau7ok65ga15tabhousdb X-Rspam-User: X-HE-Tag: 1711101173-380838 X-HE-Meta: U2FsdGVkX1+lXX3bB+nJlwnB6sXcU7fl0fvQz/p5TKtHWqRM4eqYBV5zjMsZoIwNJ2arcSiSwQ/U+LPxhkzFYq9S5Oyt5rvWt6jAO6RRmusUEzURTW+4felvPJhTj0kBTSiHaey+msQLycB9CU9it7t0i5/rm9J7ABhTWW/DbzdEIkuX/ZDB+6VyPDGcPsuecXIhaCBRoxXtucBk/l4fTew/9sgP3PESExpesoHC36JbaDl7VfUKzc7dv6UdvYB2Ogx2TQhPvbjwSRi8IKzUr5JSSlLT9dVixbgBQY5tGJN08rcKhdbx4JzaG5msBwOEtzTZdTYIygEt7xR6FoxkvWBY9dFagJRWLcjj/rmR03VPBW3DDmt4aAXWOridesxDaoGJhNqXwwvWCE2V6f0Co8D5pq1vhko4PHy5JsBKtY14cHmpYRXc9DOtUsBURsm6+Hxb/MOxxEttqrvXDf1vjGlInx0ctU0vBIOMUKSbnYNCbX046iYIxVi9Dhk7+8d5MRusRa2CYry7wM59/99yLReMC+Wd7BZ8jScPIUiLSE44RfWy15tzNksmsyKw0UGTD5Ijm5OzBsJnJKBxqcHKnMaCiB8KzKfGtztiY5HZGKnSjqJc+47vOMjodaMNu+fGJIIl9ALsX4Vl28xvnVQrQGwAD1vZTF7wRIGxUyfuKgUAA1RYzu0SEvREJ47DVg2aipxJuy4RAMiYoCti+MfOvVFrs2kG7AujxiVTiCuCtCXuruK5c5iLqTVoEmwammcahf1fI+B1eXr/4K8vy6hL3+W2AgnpG3X6eQR8R9x5SRUpdPcmleapf7EaO5RYny917BUn8WIsr8vKhSpVU2v5gp3t6mb/wl2F8yaj2wGwQH0hDATCzZyWYUPzt/T5detGU6TOPKphMsjDvs+JvR6PVk+Ns9U1WRHHVt8mZX1+MsooEOL2bvMwPDCcmTHps+6efPEeGlh93v8UiUKUJje XSfLUItt 9tmMFFLQbEzg1KeWgBWyrYhoa4jbDHSAzgHfVsmi2qDzMmFzYks1G4vAs9mjemq/sKhNFc/r3pH76Sd8DEPVyr4d8a1f3gPsKdpoznLJ+amVdQQE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.018790, 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 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. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!