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 C5BD8C54798 for ; Tue, 5 Mar 2024 03:12:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5555E6B008C; Mon, 4 Mar 2024 22:12:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5054A6B0092; Mon, 4 Mar 2024 22:12:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A6576B0093; Mon, 4 Mar 2024 22:12:50 -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 2674B6B008C for ; Mon, 4 Mar 2024 22:12:50 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 015E7C065F for ; Tue, 5 Mar 2024 03:12:49 +0000 (UTC) X-FDA: 81861513300.22.74F1523 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf30.hostedemail.com (Postfix) with ESMTP id 250CF8000B for ; Tue, 5 Mar 2024 03:12:46 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.190 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=1709608368; 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=KS04KTMX6GbmNNn56te8CFTmROj6hX+FCQXsz3btgFA=; b=XjoDyvhZrdkZPNcqUnnzuqDsdKG0X2d2kLUiVhnSZInq2KxcvqOa77oFeVq6H/CCwxcZuh DLUbiOZawVMKhGECE67+1PKJ1CKYQe21c9cAlgfoycmpMR2pW5zPBcnwuFcn3mJbsU9auK SwsOmQl5HREPHrGyWp79mQ2Xwn/XaTg= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf30.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709608368; a=rsa-sha256; cv=none; b=r5x8rmabm8DU0l/29k1/Uvo0I4mv19+w4y/9p564cHLO1pyPp36cevfC0SqzSdXeBd87Qd yEMCrgcUI/YCva/iHNB8qKzdb95HRay1ayw0gjBoRB7lBToGatBN3VTxR0D7cjspQIrLxD VHvPKTqap7amRvFqqOlqUH19xFwHtgE= Received: from mail.maildlp.com (unknown [172.19.88.234]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4TpgYB01HDz2BfJh; Tue, 5 Mar 2024 11:10:21 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id F41BD1402CB; Tue, 5 Mar 2024 11:12:41 +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 11:12:41 +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: <7dfef7b1-8c5a-dd0a-2653-15a9c656f111@huawei.com> Date: Tue, 5 Mar 2024 11:12:41 +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: dggems702-chm.china.huawei.com (10.3.19.179) To canpemm500010.china.huawei.com (7.192.105.118) X-Rspamd-Queue-Id: 250CF8000B X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: qks1xy5herjw4xpchfy97xtxb5xowbmo X-HE-Tag: 1709608366-822370 X-HE-Meta: U2FsdGVkX1+EKMmNyDZsF0Djc6C2MPnyJdiDZhCGLkpbUejfGNPz8T1Wq+HMOdgWNx1nIMV/vFUYHpmXl9+EtHntsdqgCihW6HJlcH+Hv+7mGvvNypTVRrgRvrB8vrdBzc1SLsBVPHYcGgW2STPcm5pSo3t27JYnwztIIdDu7sGwkNfAGmuwEiVBxCuSes2wJkXaPhAPsgNhkq2lsklXInBtqDGBqLvSjK8UoIG7jnDSOAdexzfBxVSz0PJh/DccPE0TCS8QGqaaRC1F2R6Z/oazq7LE2djgJ4roj0o9u27nXij8ewvGUiCsdMhXOutV3FKMr7ALn9V2LT0B73aRpzQursNqEIDKP9kb+9mhLU1D/JKTL/HsvvgF/0J3coDfFlV4Zm+xs2dw1EKQULDvVDbkWMtP/2gkbmanDNpDxnUxqHLjmH986x8jj0W1A1KtVqhI/CEnYtOq3caUS2AZSDP8q6A7EKB0rlfCkwqYyn/o5+vzlrorFft3tdEcHmJV1lfxgy2ISlrc49Ah+L/534U37+Mn4XVtVqlV6kPrt/V1G5C3XaavFmV1AxASnm0FwufqTV0tOxojdyc9bQxmUHEA+DX6LABcmDPAJcVU8+QwBOGCrLCrn5bT+QuNUQbpg8hxs3lTl9v8I/rh238uzVkpprW4HpDZVDuh3BC+6J6MeXJBWu+76Jwg810mt8XVEh1QMUW8Y0T+YzXtVSR89t+1r+7emoqFplOmebEnzXyaYlDcf0P7rRTYo/lQKeIevaeMmWKC6AyqcDBFTwlFuTykdUI57QbXVbCdAmHabrX0No54uwMJp5qVHe5+ZUCytlrDj375ryWKUaIj3dmG2dFd0KfLI97MTZG6pFrDZsM= 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/5 10:54, Jiangfeng Xiao wrote: > > > 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. > What are your suggestions on modifying the kernel backtracing logic or deleting '__noretrun'? If you insist on modifying the kernel backtracing logic and persuade me with good reasons, I can also try to submit the patch for modifying the kernel backtracing logic to the community.