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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0306CC47DD9 for ; Fri, 22 Mar 2024 09:53:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=/3UMn8Gpuo3Xn+Qm9MmgfQTXQBmkbtMzV+zjxHaXAjE=; b=qlOXj1ax5UNJdn tB65Qmx5Jhm/rDYNz6gaDHgVW+Pj+dTBmQzX98otV9HHugJO/LFLRMBof4JzGz6Y1m9CNw1MMG4ms rs8niYYzzV4uJZrCukTeFNAOmEUqvjd/pgddtvijUF0HnX26sYQdTqMmSAvPMOnKIjTZSOVP3jho+ Hk13oOroounwRM0J/7ZtGbArI93zISjhs5ephr1/uAzjAolNmprIOfAAf2tVd26I83Ae4/qS2Xhkd B8S7OfcBb8v7n+nvVqY+5YlBNkqQyKJUZG5pIwqBfsg2JnPYW2aadScd40TdtRtY6pZI/bONL62kf zDkxg7AWdRSdXViUh83A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnba7-00000006fuj-2ve6; Fri, 22 Mar 2024 09:52:59 +0000 Received: from pandora.armlinux.org.uk ([2001:4d48:ad52:32c8:5054:ff:fe00:142]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1rnba4-00000006ftf-1Buv for linux-arm-kernel@lists.infradead.org; Fri, 22 Mar 2024 09:52:58 +0000 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-Disposition: inline In-Reply-To: <2b2993fb215c4a5abd7d77ff1c984113@AcuMS.aculab.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240322_025256_421516_A7B3FDEA X-CRM114-Status: GOOD ( 31.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel