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 95663C48BF6 for ; Tue, 5 Mar 2024 02:56:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D4486B006E; Mon, 4 Mar 2024 21:56:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2842C6B0085; Mon, 4 Mar 2024 21:56:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 174D56B0071; Mon, 4 Mar 2024 21:56:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 085836B0085 for ; Mon, 4 Mar 2024 21:56:20 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9F2861408AC for ; Tue, 5 Mar 2024 02:56:19 +0000 (UTC) X-FDA: 81861471678.04.67B1BE0 Received: from szxga05-in.huawei.com (szxga05-in.huawei.com [45.249.212.191]) by imf15.hostedemail.com (Postfix) with ESMTP id 9E92CA0016 for ; Tue, 5 Mar 2024 02:56:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf15.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.191 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=1709607377; 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=0PNzBlgvWQlNy609aMLX3b+mPN/QUvXYDZKkFpp6U/g=; b=ttwjRlq0HlgNxIKVlUMT6mz36/B7srtfJkzmEgeBcNvQzMYrHBG/s6JBYDPv2Yx1wMRs3h cgNLuZZBG+YvEzGZ3V6Jy0pwtmnCESMzuNtSwsNMwdA4CFuFwFoSPZebKD0R0MleWsXCEm eDENyF/3moVpMGb1zKCGwq2Z6AuqFUI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf15.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.191 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709607377; a=rsa-sha256; cv=none; b=mBaucH1g4Qo8oChMCkLaywLiMaua53dRaQT96vzZ63VKoF31M+0ETGm9jay1hgZxj55Uex 9u7bdp2HyrxKIuJOpHmkEK4DdkyoII2SXAwVj2PLxADxJd5Mo483ZZD9ez2FcYQS6ULBIk RM1npi9EndW3URgNseO+MIjKDPgeHq0= Received: from mail.maildlp.com (unknown [172.19.162.112]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4TpgB66kKKz1h1C5; Tue, 5 Mar 2024 10:53:50 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id B633C140158; Tue, 5 Mar 2024 10:55:55 +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; Tue, 5 Mar 2024 10:54:37 +0800 Subject: Re: [PATCH] usercopy: delete __noreturn from usercopy_abort To: Jann Horn References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> CC: , , , , , , , , , , , , , , From: Jiangfeng Xiao Message-ID: Date: Tue, 5 Mar 2024 10:54:32 +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="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.111.82] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To canpemm500010.china.huawei.com (7.192.105.118) X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9E92CA0016 X-Stat-Signature: 4798exy96nmugeyabn5z3tmnx1k3dbd6 X-HE-Tag: 1709607376-593315 X-HE-Meta: U2FsdGVkX18dFytpbQQQ591N8YwQnJIYorL8AjeAwtsPlM2Nd4+/xZTudS6cNt3wyyqjh6BYOydBSVrXvOuEY7VbXPkBa9EdVklcPAkIEDxpyMGBA39Dt/PZHpo7AzkMmXDSu1W5+nBb4Xrn8ShH0FFXHUiZlWKv2RHlod/Ei5yN0lbJdf3y1U7Ci1uyT4VuZnciE0RpQRkrO9oQHm09ZQjSrxXZgePIHFV7HnW3neVa3dkaxMTv1bwSAFmVpY2jBNGTZ5KBtI4cEgYgL87dhrjZF7WJAOFuv4q6nZn+XF75rNmFuuzeVXHyE0T3QdYjxo8PF32J0wCMZezaWC6/A5qUoYlX2kFyxN85r04a4w363mjQVoatCIe3Kw5s9rmKosB8TFOsR208TrmReoMdi1FY5ZQ6wYp4TJQnT7RLLaMY3azic5ljmAnh72NtKciSYlSnOigkiFOp/bqs4jA1cIiVtdRPoZTDUWZLY8ZGUKNOMXEUZsGmEiAWWEAoB3GY/ZuhZ78jAVXmA7FvwYuQ0uv1PHufUoBFTgOnHMyGGep1ke99d3PVsf2sq9uWYl5OcxjzBT6/SVJys96X3p9nAhUgPJMyJcdaLRhZxd1TyYTFcwYXuidu09EVGAKlpn6HbjA2eg7+Xm9QG3Cs8uVF/8UgGAuB5l3WHiHXoVYTM/PTFLxDPu53E85/jxpJs+e4r3B7eXzyiifL80pbXLXKjQZciC4qW+k++YddGHjUex/gyLy6jfYhhtV1q0trCKiyAgJA5jTyWbvCZ+GWbrl04u+2Pzy+rnKIU+VqDdTeUnDLCmnhOXxWL+NEYO89oua+1y28qyoDQ399YypA4AeDptMU10NNjC8f 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/4 23:15, Jann Horn wrote: > On Mon, Mar 4, 2024 at 3:02 AM Jiangfeng Xiao wrote: >> When the last instruction of a noreturn function is a call >> to another function, the return address falls outside >> of the function boundary. This seems to cause kernel >> to interrupt the backtrace. > [...] >> Delete __noreturn from usercopy_abort, > > This sounds like the actual bug is in the backtracing logic? I don't > think removing __noreturn annotations from an individual function is a > good fix, since the same thing can happen with other __noreturn > functions depending on what choices the compiler makes. > . > Yes, you make a point. This may be a bug is in the backtracing logic, but the kernel backtracing always parses symbols using (lr) instead of (lr-4). This may be due to historical reasons or more comprehensive considerations. In addition, modifying the implementation logic of the kernel backtracing has a great impact. Therefore, I do not dare to modify the implementation logic of the kernel backtracing. Not all noreturn functions are ended with calling other functions. Therefore, only a few individual functions may have the same problem. In addition, deleting '__noreturn' from usercopy_abort does not change the internal behavior of usercopy_abort function. Therefore, there is no risk. Deleting '__noreturn' from usercopy_abort is the solution that I can think of with minimal impact and minimum risk. If you will submit a better patch to solve this problem, I would like to learn from you. Thank you.