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 2C493C6FD1F for ; Thu, 21 Mar 2024 22:44:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AF2F86B0087; Thu, 21 Mar 2024 18:44:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7C306B0088; Thu, 21 Mar 2024 18:44:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F5EA6B0089; Thu, 21 Mar 2024 18:44:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 780426B0087 for ; Thu, 21 Mar 2024 18:44:01 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 13B3016018E for ; Thu, 21 Mar 2024 22:44:01 +0000 (UTC) X-FDA: 81922525482.01.6F5446A Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf07.hostedemail.com (Postfix) with ESMTP id 7FDC840014 for ; Thu, 21 Mar 2024 22:43:58 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VUdJn0ad; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of ardb@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1711061039; 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:dkim-signature; bh=9YLEvPVut+aEhkwjdQYiPaE9xdwsFeRs7v8R3ObEQmA=; b=mJBB8f4YW80D28a6uIc9dD1aAiGZTlvytybLYscD5Uo0+hiF9pYuytru90Apq75br8/kYE e9mwrrJxyQHTMo2OnPAQv3HD7Q6+N1ksaG/0llYcCQQqefBAq3+EL9uiFquSo30pSYPaa2 lgtVGa+rfyWH77GQfJzCdGY6PM7XkHU= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VUdJn0ad; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf07.hostedemail.com: domain of ardb@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=ardb@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711061039; a=rsa-sha256; cv=none; b=D5795TpzsDiybP1Am3P/an7HK1TSTMK0nXhbDkP4pi91c9hNq0hxIU+JjYFQq8MCurxauq tZiLgctNKX2LaFgTfpWkdRA49jTU0PEjogCsWmkPNMVy0stTUYs/SrMrCb28VStp2BmQO/ So5XByhGqa4V+83N2ZSwwl8HYLMCC1g= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 3E1BCCE169E for ; Thu, 21 Mar 2024 22:43:55 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 330FBC43330 for ; Thu, 21 Mar 2024 22:43:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711061034; bh=9YLEvPVut+aEhkwjdQYiPaE9xdwsFeRs7v8R3ObEQmA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=VUdJn0adZJJQHfherYOceG2h1ETcDR1bhdhtJsUxs9wVLJSsBcSTZ+/1ksbxDTDSq u3BLCFckXqhRyGjAHy7B00ZhHsoJ84oxk+VivG6HA85k4002ivBPtLrPFttalcOTHb MxgdenyKDhWltvBzPmylYbn6xIbdV7oHVeZSqEykOsiVZlknfmP+a2tbc92B/5GGtb 8bTelp6jMGCN6wblwCuHNnmIcYOVb04Q5kB3NjlZsONvFWRg+5msMIp8DTnB4krI/q sGlUOSSGCIcblL7b0fpCtaVG2xywFwgRG453BreOhmaPKhHT3qXl1ypQF4Zc0Xv9ro 1igrJ9OYG6U8A== Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-513d247e3c4so1453199e87.0 for ; Thu, 21 Mar 2024 15:43:54 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUh+bpFalm7gbaoAROVapZrZqQ/ppnaQiXK/zLspX451w6YQ4e5Uh/GuN1YKFPjbqaxM0ZMEP9bKBmkiheqBnXLhOo= X-Gm-Message-State: AOJu0Yxf3Jo9KqgVLOD4PCXQ/sFvcWov2uqOspoVQ2qQljM/MFwatlGZ qgvyQbn6BPXSXpk9HF0/HA4jniP+Xl55RJcB9O85TH9gEsO4hnY5sOLXT/3r+zfxGyFKdUeBay3 Kbggdhn1hY2OJp1I/R7xG9VQhLs4= X-Google-Smtp-Source: AGHT+IFEt+m2d6qmvyuzhfq9miPm16KRAZyNPzt4/1WPHVMW64H38oH9/SsT+7om4AyuYaPbm+lS1yoJfQEihUk7sDQ= X-Received: by 2002:a05:6512:249:b0:515:8d79:1b37 with SMTP id b9-20020a056512024900b005158d791b37mr108001lfo.4.1711061032487; Thu, 21 Mar 2024 15:43:52 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Ard Biesheuvel Date: Thu, 21 Mar 2024 23:43:41 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] ARM: unwind: improve unwinders for noreturn case To: "Russell King (Oracle)" Cc: David Laight , 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" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 7FDC840014 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: rsbhu697usdeu7zpoan571fpo9nr5f89 X-HE-Tag: 1711061038-101939 X-HE-Meta: U2FsdGVkX1/udwKN3KwAxjDRvqPh0NVO/+FOXAq7ag2oRDFTtqCNNSgMS1SRgggyQznl/H3ZbXOeIf5pXETbFGzhOwqbtPFkUlGfnyp7dIaju+HSPC6AIqPeJWz+Juh6vk0zzPsulvbTPHOTg5PDDluyX855vADWays2wabTj3T1E1cKdH2vlW+Mjm4Mn7qJ1uJqaN2MfjjeCitznL/w45W/J2ZUouQfVjE3ZPTX8KoS9jYzp/j9AfqQqMFj8iQwuEGssunbWUvVrLZs4GW+i+PzUoQyKgPaQmDIqYvAAIo1kdsz0RQSXyUCpzcbgOh1VcSgV6IGggwNAnaSCf+rYzNfJstTeFmZ+Kqm3O35TJad1jyUL7f+5LQXg9Y2S6CjWcip8mhgpUdmDrte1leZG1KM/J6vB0yMVhGs2/SgpOqSPDIlccKWfSll7II8l4xuJAZSfJieLmSRBvUANQh4bOKekzlB3dVXBjzHXyI1trzb4cgQCNk3UVyC2Zyuybf4iQEbIclzOWXHZGjXZT3N6IL894B9aA/tvVN/nvx4+zWS8rny42SRcL77xn8WnWoSD+cnz2okampvwFKX5qcTD7MPB2JZJcHxKm+VcjrYvKaHH7W1GiGROv16Kh9Zttm7cRuS9LkKd2VjjJV75RhfDncA0ge6SO5/5CsarBiH/tnptClwc47eStXn7feAoqj1S/7XlQ4gNc6MOJHVBPBdsyZrGcO2bdxILeQrdkY6WF47b0NHyy5OKOnJ2JJPZj0kDnSquSpQReBBwOlrgbPHzc3VHOPQB2dB7GDj5GYrk5NEERgQar93OZNZ8VtqogHVs2Th9GVdfFUDdSFiq/LZ82gOpZPUyyXuKG9I+VLeTOUYpinXwDp9FThHi+Adz4ydcLTVgMp8Te0BA0DDRShbTgKp488Flz7nx1fgb9OI9rrAwPu3zf6zfnnAe9d/4H+3Vb3uPjoKkU2NDlCb4SD k9iPsLLX mnOxsXpxiucv4xjpA0+iKTXl7BpfxU1YO5o1nCMpyC952DqkLhqDB+PnfBG+6kJKepGoOlrzlQId0blA4aLqEAcvantYzRQ7fzxWMZePMCVgqoSGXTjDCBRqcFMraDizogaX2iozU4zaog+oJcFYeng2TbJl2twKZmdPOER+k9RxmtXT1N1cUAo1ThKmqHMKNR8s0jW+9oA2/bOw1bn60Hm0OjS1WI0Y2Q4xGCD2SAVMTZSXoeTG7+cNksJYfJjkzaM5s4MZ09OFbggW72nMFmIhSX8btx/4Kq2EljPn/TNh/B8DdH+Idke0d1+GsFMhUdSmb 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 Thu, 21 Mar 2024 at 12:24, Russell King (Oracle) wrote: > > On Thu, Mar 21, 2024 at 10:22:30AM +0000, David Laight wrote: > > How aggressively does the compiler optimise 'noreturn' functions? > > I've seen cases where the compiler emits a BL instruction as the very > last thing in the function, and nothing after it. > > This is where the problem lies - because the link register value > created by the BL instruction will point to the instruction after the > BL which will _not_ part of the function that invoked the BL. That > will probably cause issues for the ELF unwinder, which means this > issue probably goes beyond _just_ printing the function name. > > I have vague memories that Ard has been involved in the unwinder, > maybe he could comment on this problem? Maybe we need the unwinder > itself to do the correction? I also wonder whether we should only > do the correction if we detect that we're pointing at the first > instruction of a function, and the previous instruction in the > text segment was a BL. > First of all, I consider this to be a defect in the toolchain. Given that the compiler knows that the BL is not going to return, it should simply emit a BRK instruction or similar after it. This would catch inadvertent returns as well as eliminate this kind of confusion. The ARM unwind format is not really suitable for asynchronous unwinding, so unwinding across exceptions is always going to be hit and miss. Also, we should consider what the unwind information actually tells us: for debugging, it is useful to understand where we came from, i.e., how we ended up in the situation where the backtrace was triggered, but what it actually tells us is where we would have gone next had execution not been interrupted. The latter notion is important for things like reliable stacktrace and live patch, which need to know where a task might be returning to. Returning to the first instruction of a function is unusual, but in the light of the above, I don't think we can assume that it means that the call originated from the preceding function, even when it ends in a BL instruction (although it would be highly likely, of course). The tracers and other instrumentation might insert probes in the return path, and I suspect that this may result in a similar situation in some cases. 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.