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 31734C433EF for ; Thu, 5 May 2022 01:21:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ABC96B0071; Wed, 4 May 2022 21:21:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 25AB86B0073; Wed, 4 May 2022 21:21:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 123206B0074; Wed, 4 May 2022 21:21:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 019696B0071 for ; Wed, 4 May 2022 21:21:17 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CA3E560C35 for ; Thu, 5 May 2022 01:21:17 +0000 (UTC) X-FDA: 79429936194.11.D35A6F3 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf11.hostedemail.com (Postfix) with ESMTP id A604C40082 for ; Thu, 5 May 2022 01:21:12 +0000 (UTC) Received: from dggpemm500021.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4KtwnK3MHbzGpTN; Thu, 5 May 2022 09:18:29 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by dggpemm500021.china.huawei.com (7.185.36.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 5 May 2022 09:21:12 +0800 Received: from [10.174.177.243] (10.174.177.243) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 5 May 2022 09:21:11 +0800 Message-ID: <83e5bbe7-0880-3534-897a-156a4d2b4451@huawei.com> Date: Thu, 5 May 2022 09:21:11 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH -next v4 1/7] x86, powerpc: fix function define in copy_mc_to_user Content-Language: en-US To: Tong Tiangen , Christophe Leroy , Mark Rutland , "James Morse" , Andrew Morton , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Robin Murphy , "Dave Hansen" , Catalin Marinas , Will Deacon , Alexander Viro , Michael Ellerman , "Benjamin Herrenschmidt" , Paul Mackerras , "x86@kernel.org" , "H . Peter Anvin" CC: Xie XiuQi , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Guohanjun , "linuxppc-dev@lists.ozlabs.org" , "linux-arm-kernel@lists.infradead.org" References: <20220420030418.3189040-1-tongtiangen@huawei.com> <20220420030418.3189040-2-tongtiangen@huawei.com> <91011a66-b125-b445-1486-bada8e06b994@csgroup.eu> <48f2779d-bc62-c7f5-c40e-7238a16b90fb@huawei.com> From: Kefeng Wang In-Reply-To: <48f2779d-bc62-c7f5-c40e-7238a16b90fb@huawei.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm500001.china.huawei.com (7.185.36.107) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: A604C40082 X-Stat-Signature: 7ohbauf9y5ex14pajnps3maosw1o6oa9 X-Rspam-User: Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com X-Rspamd-Server: rspam09 X-HE-Tag: 1651713672-93886 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: On 2022/5/3 9:06, Tong Tiangen wrote: > > > 在 2022/5/2 22:24, Christophe Leroy 写道: >> >> >> Le 20/04/2022 à 05:04, Tong Tiangen a écrit : >>> x86/powerpc has it's implementation of copy_mc_to_user but not use >>> #define >>> to declare. >>> >>> This may cause problems, for example, if other architectures open >>> CONFIG_ARCH_HAS_COPY_MC, but want to use copy_mc_to_user() outside the >>> architecture, the code add to include/linux/uaddess.h is as follows: >>> >>>       #ifndef copy_mc_to_user >>>       static inline unsigned long __must_check >>>       copy_mc_to_user(void *dst, const void *src, size_t cnt) >>>       { >>>         ... >>>       } >>>       #endif >>> >>> Then this definition will conflict with the implementation of >>> x86/powerpc >>> and cause compilation errors as follow: >>> >>> Fixes: ec6347bb4339 ("x86, powerpc: Rename memcpy_mcsafe() to >>> copy_mc_to_{user, kernel}()") >> >> I don't understand, what does it fix really ? What was the >> (existing/real) bug introduced by that patch and that your are fixing ? >> >> If those defined had been expected and missing, we would have had a >> build failure. If you have one, can you describe it ? > It could prevent future problems when patch3 is introduced， and yes，for now， this patch won't fix any issue，we could drop the fix tag, and update the changelog. > There will be build failure after patch 3 is added, there is a little > confusing for a reader of this commit in isolation. > In the next version, I will put this patch after patch 3. This is an alternative. > > Thanks, > Tong. > .