Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4680004iob; Sun, 8 May 2022 21:45:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzOaXPEBYl6RaR6DVOGg23tFWyiy6kH9n7uhXpr5qrcOnkukays7olg6U0S+xWicFIyLaO0 X-Received: by 2002:a17:902:ca0b:b0:15c:f94a:bdd8 with SMTP id w11-20020a170902ca0b00b0015cf94abdd8mr14883307pld.17.1652071526880; Sun, 08 May 2022 21:45:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652071526; cv=none; d=google.com; s=arc-20160816; b=pHbmKU0qeVSTljIDknO6wIfxNmFDDGAJPlxsPMYKTSLUb8kNEfEVJRDp+UHBviWzgE Xu2FUd9MUwBuFUVu9EL1+Pr9l8G9KUk9JcWK+iBaUittDGz8UclWte8SwYKU5rudoXU9 qkLttuDYCclXyMsHnZJsBaH2j9uexcn16puSSK6ItG6E7RD5QciSAbgaSq4hh+bV1muU I/DrEeGqBndaJEp/7YMRgN4kGW46r8VkXkY1Rpart3w+s0Q97txVkGb2N4+ToxbKAEvI MAwQ7CIVrBce3+NBNt6drA/zwvt96ZaDMjJZer8Our5xSsr536oA6ygjlbRL0nvkuw2d oN9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=gNCKlNKh/ts9kPt+8kczJ8tOTypBz2R9Ysk2fsHEba4=; b=RAwyU3kR2bya7Fn0kAzANgj3v1QpN3vmWB5jNd6WR7TWdR8oUSgetcAnyLUvGljCym qh5AzQnWY/Y1Yq2YzKBC4O2ystcUFTkarWwqRUvrQAUUlfQapL7uj972pVzt9MuxJszN /gChyTbmv7Kf/O8qbCDC+JNCW1AJ7BS3KyXmGDVb+G31luUQmNgDwjaChRKHEc3MOmeK 5XQoJi6XdUwLKgk+WgLwo/Aau81TYxwf89hjPFIILO20p/RyEhNv3i26vBWOP7y7KMHP v1k/fpmFTFjDuNnWGzcMxfJmFTHvzBGqid4y1vnaqzGHzuNxCO9A7IVAYDwAeBQMRZjn olIA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id f14-20020a170902ce8e00b00153b2d164cdsi12090633plg.213.2022.05.08.21.45.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 21:45:26 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D9CAB10B3EE; Sun, 8 May 2022 21:45:18 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235223AbiEEBYy (ORCPT + 99 others); Wed, 4 May 2022 21:24:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42916 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230176AbiEEBYw (ORCPT ); Wed, 4 May 2022 21:24:52 -0400 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 653C1506DB for ; Wed, 4 May 2022 18:21:14 -0700 (PDT) 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-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > .