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 9CF7DC54E41 for ; Wed, 6 Mar 2024 09:52:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13ABC6B007D; Wed, 6 Mar 2024 04:52:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0EBE86B0080; Wed, 6 Mar 2024 04:52:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EF56F6B0081; Wed, 6 Mar 2024 04:52:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D7F7A6B007D for ; Wed, 6 Mar 2024 04:52:32 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 640D7C04CC for ; Wed, 6 Mar 2024 09:52:32 +0000 (UTC) X-FDA: 81866149344.12.AEB6B90 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf20.hostedemail.com (Postfix) with ESMTP id 9F0021C0004 for ; Wed, 6 Mar 2024 09:52:30 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=WWfmFupb; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf20.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=1709718751; 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=+UHTxiMOCWmnYGbzdr3xdIdiyFhD3trL1IlYn9sx2Ik=; b=Y7603TjEbvE0Tobu5U90emJsWTN36mDCW3+ril6yyXywAUOTzG4PsHa2tmSRScvWdCXUYA 0bd38NHI5jTHgy0CiSdrw1ckfEWuIanW72uPrTxaMekhxsDcEeflsnhcieSzdnVyDHqzSv nbtjfkO7nYniZwwHHIJ3lnjyrGELpHc= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=WWfmFupb; dmarc=pass (policy=none) header.from=armlinux.org.uk; spf=none (imf20.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=1709718751; a=rsa-sha256; cv=none; b=AkoaY+xKeRS2s75Eer3puiv9Owkz6b6llabJvAlvsRfJF1COtjghDIlgiTg4r6St4FYtfw Pab82Wa/Cp2eD2dPru6lQmXYuNH9Twj7QZwlcTouMfr2bMA95A6QBxDr5pNSiw04g1SotV rn6IouXdnBC6xskH2KwcgzI5WRaHeSs= 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=+UHTxiMOCWmnYGbzdr3xdIdiyFhD3trL1IlYn9sx2Ik=; b=WWfmFupbS1FWFYcVIBHqaTAfFo JT81TSIj80enOhfKIvYWxZw2DEVGtf4L9tMGSmq37QOCWbTSsD8kIrIUvSTE9rWsdUOqXl0V6BGWU TJ2WCLM+C8qogGo1lg7ZCilq7+J90LxSkB5Edb57G/utb42hdwtLn8ODtjpuTt6vrYiX+uaixttSq ghFAnCsyprG0PesBYJK3+disNSjK5IECAHw/kA3E82iLCy9xQR2dH/gh8oVQ3ZmQtZSyMxctVu9w1 dnzTrvFqipnX7KbNMpsBLt+s25yM35D5l8kg7nTWo9cuzc4Nkxi+joj6DaPglnJJltC6Sk0yIGL46 HmeZKelQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:37134) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1rhnwU-00089f-0i; Wed, 06 Mar 2024 09:52:06 +0000 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1rhnwQ-0006GG-1M; Wed, 06 Mar 2024 09:52:02 +0000 Date: Wed, 6 Mar 2024 09:52:01 +0000 From: "Russell King (Oracle)" To: Josh Poimboeuf Cc: Jiangfeng Xiao , Kees Cook , Jann Horn , gustavoars@kernel.org, akpm@linux-foundation.org, peterz@infradead.org, dave.hansen@linux.intel.com, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, nixiaoming@huawei.com, kepler.chenxin@huawei.com, wangbing6@huawei.com, wangfangpeng1@huawei.com, douzhaolei@huawei.com, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel Subject: Re: [PATCH] usercopy: delete __noreturn from usercopy_abort Message-ID: References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <202403040938.D770633@keescook> <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com> <202403050129.5B72ACAA0D@keescook> <20240305175846.qnyiru7uaa7itqba@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240305175846.qnyiru7uaa7itqba@treble> X-Rspamd-Queue-Id: 9F0021C0004 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: m8k5r33xneomxym913qqoowd6kq6u4fq X-HE-Tag: 1709718750-27669 X-HE-Meta: U2FsdGVkX1+XNMMC5jQTLyjpf+uJHtJaDBiceHKZok4zZ/Cya0K8MVhzN9S8a5JTxlaDp0Eywo/I74gkUkmlaQcHTrtnO5ZtIw4aWt1cGbYD7bi5wzhwCHk8hkUqy/kQVf4evBfXqqHuBoZR4evh0MNB83r6mQXEbSIZ3eWoVW3sLD22W9cghJGtEs4cDuBTTbyfvnTh0jB8AxqWX1LcrT78iCKvJAUwdhq1L0H27PVeLnPt+GOjPsAOP5JwhOgu1ub0k5uz3eUczxCGi3TbrT7BY8+OoJemSn8hswTaUCBR68qf3amn5gbZycceVrGnvYs0CjFC9k9aZgHOwWhYS4OAhjhSTWlYDaGSbN/8VfCe8eLwiWzHPI5lD1T17eKrh+LVv6SMrKFfdJheDx0QxZH6xc4QWgtmAckhcZzTi+7hwcj+yeeV+CZvvyS/STA32C7RCHaT42hbisIbN4Osm3T2iuxUuFdr9C6Ir8PJ++Uom7DrHNnH4rvgPj7CpfPGev/TDZtMNcYHwg2mQHTi0IGyXY2i2C8nlDR4LylzvuS9TT1RVHQSda7l8MYSyzAR51xJIKbH1T+tzHvSvhG8C25ajvFjIJcvrOL+leDFstHuWxCwIGuB56g6WlxeAFRskEFgUBfEoaCyjtd86ZGesddfbipdHlPT1emVa9PkshqNr2hKLpxFr+6ddnm9vMtfH6n133iI+SSiZa2lGgwN7ax6ZJ3B8bxUwPMhYJvdkDMbhYw3nqFVKhJEFzRzZUG2zFJoBkfhUqtHEGGM1RVCOYOxcxPC2CmvO1rZzozecyeduC06umh3+j0rPXXrtf4k/kDBV+94ikXOi5Kd8++kgt2aOQjVHxDTGxCEtQJGyuVCtRMCAfMY/Pe3juBMIq+bZ59dxtcRRaxNQnfUY1EcRD/B4RQWQrhCqCZV6b+pANBHBjUOkGd30Er1VCwIg7KRgZRQIe9wIY7yowkKbIC Um4iZstb /WLWlw3zMcYj5UNgpeOPD9jfH5+zTHtDdZ40jF0kfiRLq14lBC5NC9OZEaW3moKzTWlsfCy1LzKwCSKvGGiwGBzGG/T5D3GJYqIhEi23BSX7CExh6ORi60IHSjg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.017833, 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 Tue, Mar 05, 2024 at 09:58:46AM -0800, Josh Poimboeuf 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. I suppose this can only happen in __noreturn functions because that can be: foo: ... bl bar ... end of function and thus next function ... which results in LR pointing into the next function. Would it make better sense to lookup the LR value winding it back by one instruction like ORC on x86 does (as you mention) rather than the patch you proposed which looks rather large and complicated? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!