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 0FD63C54798 for ; Tue, 5 Mar 2024 03:31:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8BB7D6B0093; Mon, 4 Mar 2024 22:31:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 86BCF6B0095; Mon, 4 Mar 2024 22:31:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7317B6B0096; Mon, 4 Mar 2024 22:31:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 636166B0093 for ; Mon, 4 Mar 2024 22:31:17 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 46E141201BF for ; Tue, 5 Mar 2024 03:31:16 +0000 (UTC) X-FDA: 81861559752.25.D5D4B80 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf16.hostedemail.com (Postfix) with ESMTP id 148C6180002 for ; Tue, 5 Mar 2024 03:31:12 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.187 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=1709609474; 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=WpEOCsMoFrFDQQ82vJpgHlUuGiMDrS6uwMoFfJkO9WE=; b=et70JfZBrXz9VFnw5zH47z42yaZc5KGI9llpzqUZWCOsrKPi/8pdFvMa39d1ii0vCx1IAX adSPZ0AvuQqAY3e72HJggKglWOzYgcCLuex9avaNqlQgwC2f3Zha0Sh8SfZhF1mGQAYFUj BjzHOeiZdBv5apnftkfjHvTtus2K39E= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf16.hostedemail.com: domain of xiaojiangfeng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=xiaojiangfeng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709609474; a=rsa-sha256; cv=none; b=Z011FEM5Axd8o6VPPY30gnJmY9lSdiKX/leGqq5YitkOqd9hbRkczN012x50zCDozHGT4R j6xryPyeblDnDPPpaJm/7Zn0kgVckaTzv1fFBeIWWgjUfL/tgVt75k1pIw/QjA6dK1nQl+ ntotv64Mg6Te2ULKDUQNX9pAaenYN+E= Received: from mail.maildlp.com (unknown [172.19.163.252]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Tpgyv2TMfzsX7B; Tue, 5 Mar 2024 11:29:11 +0800 (CST) Received: from canpemm500010.china.huawei.com (unknown [7.192.105.118]) by mail.maildlp.com (Postfix) with ESMTPS id 7CF0C18005C; Tue, 5 Mar 2024 11:31:07 +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:31:07 +0800 Subject: Re: [PATCH] usercopy: delete __noreturn from usercopy_abort To: Kees Cook , Jann Horn References: <1709516385-7778-1-git-send-email-xiaojiangfeng@huawei.com> <202403040938.D770633@keescook> CC: , , , , , , , , , , , , , From: Jiangfeng Xiao Message-ID: <77bb0d81-f496-7726-9495-57088a4c0bfc@huawei.com> Date: Tue, 5 Mar 2024 11:31:06 +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: <202403040938.D770633@keescook> 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-Rspamd-Queue-Id: 148C6180002 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: 4mjg75o4gwbs41csqcn9koieca76gszs X-HE-Tag: 1709609472-817450 X-HE-Meta: U2FsdGVkX1/Cfe91WCVNgzhaKkNr0B+cPPD0xgPBCg/YSQ14l1aUnkf7W4l4c4C7/b1vbAO0LG6b9T82GP86W0wq20W+ZOMDlfgTz8jHgX+GkkdfxdEm5AqX5nEVn/xAEsBVgqAEWIwtzdtBbdWNakYvleBhQIDUvJG73go3olT3bir1Ko1Vrk/ZLPLXdqZv2HbLWY3ns1TPXZcgLGnVZRLbOOCMJW1g25M2HbTgC+G/Q73k4gpvIi678OBm8jEoi2eMqeItHXFN7nVD+BQ+PD5eGhT5QobXaeo5xlqW9qWhljh3OKR8dtwFkkssAmor8yKB8MX1vbs7L1DbIM9b9QBG7NV0R91+Dr6SLefXTkxUzCxt14n0rqFVCUsWjRIkPh+N1HQwObIk84S2A5H5W9rjScdBHj3FxV78BIFY/A8aGNUEB85H+ubN9qTHOI7k0tvAgOy1R0ZByI/QhAMnyQc+CNaiiBkt6TclRx9Bnhj7/KLCqiYRBcBIePjZGragK2ldCcCsd3TMWja9774XOUG7bWq4S4Gahaq10tjPNJiIN1r1R6HovgRpqQa5bXHiaC1QNT5/0+UZHd8WwundHNi/lFZPBGMu8acpirONa9tyoN1k059cPdg0ogdixw9gY0JOKOEVZTlmZ4IOgEdJPGH1MZSfw5UND7nyM9OqegNA6qPCztK1GXcfgMb7tBKeFauVbquEjq/BgV5kM4bX6UE8vtENs4ems1KlOVnB/4hXsPDmEY1vV9pm9LPeAY3TBR/2/jcB95vea8kM7kILpBggWfhXmXaGtlUcybRMQo+06Uy+pSQGlnBhFcnHcR4bTbPo3ZFlAMNlPIdCELhyJ0ZmKf9LXtKxClWiAhI94X+bXN9Jj5oxRL1+/PTLJoUMJXq5gh7mpju1ljlG7qXBcVAKD5LAsvE+Csfzcl9ojBhqVmNczvvv7SnMs9+Z0g3UMaql8GcbWtRB21enq4W BLkqpfhS soEBWbMCXN7MmmglTEtAc2PQRgClW5i7xNzrUPq5Vsf1HxxwAM6V+I/Z4tudbci9ZTMBpltP2QiPYlUhg8aWT0oiBQIQmRVvtV9Z23PZLqsfTkNgMaOhh8KD9l3YHUSmTnlbbhG/dBxZJQqxJnXYwQrldZiZwQeTaZxmypNh5i42Joot6CBoXDxptICWFMHFrBmIzW9XRChrw1+tMDzfQXnu9TCrG+WxexnKU 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 1:40, Kees Cook wrote: > On Mon, Mar 04, 2024 at 04:15:07PM +0100, 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. > > FWIW, all email from huawei.com continues to get eaten by anti-spam > checking. I've reported this a few times -- it'd be really nice if the > domain configuration could get fixed. > >> [...] >>> 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. > > Yeah, NAK. usercopy_abort() doesn't return. It ends with BUG(). > When the user directly or indirectly calls usercopy_abort, the final call stack is incorrect, and the code where the problem occurs cannot be located. In this case, the user will be frustrated. For the usercopy_abort function, whether '__noreturn' is added does not affect the internal behavior of the usercopy_abort function. Therefore, it is recommended that '__noreturn' be deleted so that backtrace can work properly.