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 AD505D1A42C for ; Sat, 12 Oct 2024 02:49:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E32E6B009B; Fri, 11 Oct 2024 22:49:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 393546B009E; Fri, 11 Oct 2024 22:49:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25A176B009F; Fri, 11 Oct 2024 22:49:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 07C576B009B for ; Fri, 11 Oct 2024 22:49:19 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 98765141A53 for ; Sat, 12 Oct 2024 02:49:13 +0000 (UTC) X-FDA: 82663418754.15.C711054 Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by imf19.hostedemail.com (Postfix) with ESMTP id 316681A0005 for ; Sat, 12 Oct 2024 02:49:11 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728701218; 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=EgfVMQ505JhtZRIyJWfm34fHt7zMejpm4MBtyVmSdqo=; b=lbi+9oloZyIaBDiyBmXMEJOiGQzE3p4GFgBtH52idZtS2E0eyzzyBI3cGjiYf4vqjzfbiL byfxNkcmSB3MRzGMFatmS/3249d3siapWo5PSEYZnwDjPDNwVGij92dxJeIeLnwYXeMnXe 02FunQctMn0MDRFLVJFUY26ITE0Y5Sc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728701218; a=rsa-sha256; cv=none; b=xXeodWt6c7k+PwRGZVJwQjba2LW71Pkshzk80zRTx26Ak7+Srb8/DB9fkfYf6UOPPdXEgH eEFv9BuxNYGZElHfmuSUquGX6+Hqa+HtZ/K0c0g8qa48ZU7po4O0dhegQpsvBMfQTSQm23 a3iXj2Irhq9Ek+61u1JQYCR++LrSFCk= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf19.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn Received: from loongson.cn (unknown [10.20.42.62]) by gateway (Coremail) with SMTP id _____8Bxkuin4wlnMGoUAA--.30138S3; Sat, 12 Oct 2024 10:49:11 +0800 (CST) Received: from [10.20.42.62] (unknown [10.20.42.62]) by front1 (Coremail) with SMTP id qMiowMDx_9en4wlnIaAkAA--.51933S3; Sat, 12 Oct 2024 10:49:11 +0800 (CST) Subject: Re: [PATCH 3/4] LoongArch: Add barrier between set_pte and memory access To: Huacai Chen Cc: Andrey Ryabinin , Andrew Morton , David Hildenbrand , Barry Song , loongarch@lists.linux.dev, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-mm@kvack.org References: <20241010035048.3422527-1-maobibo@loongson.cn> <20241010035048.3422527-4-maobibo@loongson.cn> From: maobibo Message-ID: <1141ad15-26ae-71a9-9f6f-26671d01a30e@loongson.cn> Date: Sat, 12 Oct 2024 10:48:53 +0800 User-Agent: Mozilla/5.0 (X11; Linux loongarch64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CM-TRANSID:qMiowMDx_9en4wlnIaAkAA--.51933S3 X-CM-SenderInfo: xpdruxter6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoWxCr13WF4fZry7Kr43Wry7twc_yoW5Aw48pr y2k3Z8Krs7WF4fJw1jvr1rWr18X39rWF1xK3ySvryUCw1DXF12gryrWws5ury7Xa4rJa1x u3yUK345WFWUAagCm3ZEXasCq-sJn29KB7ZKAUJUUUU5529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUvYb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r106r15M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc 02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUtVWrXwAv7VC2z280aVAF wI0_Gr0_Cr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4 CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG 67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MI IYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_JFI_Gr1lIxAIcVC0I7IYx2IY6xkF7I0E 14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jOdb8U UUUU= X-Rspamd-Queue-Id: 316681A0005 X-Stat-Signature: aynb55dw577mjbu96rsyscw5sfj64183 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1728701351-160802 X-HE-Meta: U2FsdGVkX18ZHHQqexGnUystu5C4E1Lddn29XDzTWQG+jKseVnVZYpUNQieHrO936fcwlezkWUkjnTiI8YDm3c5LNnoH6VypAgO1uky0IPutlBBOoIDgNJgoKPq4YbAh6HHjccOxoj0tXEDej9Wz3ue+eobhW72sk52Z5xyJQFajfR/FS1PCljY3Wju5a4JEjiVnPxCU4Cq/L3Eq7TBqVxeqm3CiyHM7C1uJ0IsMaUj0kdNN3Ttpkp+KKUScF9B2+tl9GLBwK9wUq7wUNUc0FzxmNorqUrZmZYl18DawTjpEVTNfefco7OU1REV0CawP+qQqwTyft8vsCAYEv+p+LaGo21risTT2K5MJ5bfeUe8GVvAk+bbKPPn3EY6PmSKONGtGypYI9vAnzxaDYe+Du9MhLrTp3vs3OFHgaNZ8bdZZdXVL8o0VoUjDgBiNhBFYQYMnR9gxe3J/QroPPHar+UZTwyoDCNGM6wSSvJN7kQII+sDO5+jyOG8neGg8AW/sRIizLEFlK+ra0MNlGZA0oxUgTTvPS1sx0PpBNKZsSW/+y/d8MV9doGDMwjjBIKYFITtT5AklSdrD4U865kqmM0lN1kXsYA65UkM6NqJANaUUp8fS9mvAMMYoNZm4qvLqjiMXX705kwNnh8J9zQEe/CW8Jf9ijsAS/6G5ssac4v0QnkchJPQHnC6O0TWp4vIiR9YpzayNn9HtAGJBC9uU5r4pE1IKLNZPDV95sPZpuuRN3otm0Nh58OWvyQMRcbUic79wotqk82PdJDcQL8HgEtT5hyiaq8TZcnciDCL48JotiBvKcbNFfz3nr7DL6bWhN7w7KbfFl3ZJh8jgPqxJ+CTZft/TYXzR22VN5WSblUi5Z4zskLuqJuvOfXNc+GJm8Md/T6l4EQktXsEAfhFcVETF9+6yBHvcComQTpgS+p1FhjR4Fp50IKJYHMfyRGUeqMyP+0sHYFQuc15QlKi 7VVFVaQX Tieq7Dx5mpFTuYRcDe1ImnFIHiWuoJsWCiu1IsA/QXFvJqQ75WBMWW8uOA5M98DvAKjrfMTKCSLs9aVKPCfkMrtJOEtAXnxG4tXF8+265zN3IFNSa5qB0XB1JGUyR+2mfDqjk5PKxzuCsIPiyBTJuIZXACjjiUfbnShSyaVS9CejyrnBs9BxGnltdg1mumEo42uQO 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: Huacai, On 2024/10/12 上午10:16, Huacai Chen wrote: > Hi, Bibo, > > On Thu, Oct 10, 2024 at 11:50 AM Bibo Mao wrote: >> >> It is possible to return a spurious fault if memory is accessed >> right after the pte is set. For user address space, pte is set >> in kernel space and memory is accessed in user space, there is >> long time for synchronization, no barrier needed. However for >> kernel address space, it is possible that memory is accessed >> right after the pte is set. >> >> Here flush_cache_vmap/flush_cache_vmap_early is used for >> synchronization. >> >> Signed-off-by: Bibo Mao >> --- >> arch/loongarch/include/asm/cacheflush.h | 14 +++++++++++++- >> 1 file changed, 13 insertions(+), 1 deletion(-) >> >> diff --git a/arch/loongarch/include/asm/cacheflush.h b/arch/loongarch/include/asm/cacheflush.h >> index f8754d08a31a..53be231319ef 100644 >> --- a/arch/loongarch/include/asm/cacheflush.h >> +++ b/arch/loongarch/include/asm/cacheflush.h >> @@ -42,12 +42,24 @@ void local_flush_icache_range(unsigned long start, unsigned long end); >> #define flush_cache_dup_mm(mm) do { } while (0) >> #define flush_cache_range(vma, start, end) do { } while (0) >> #define flush_cache_page(vma, vmaddr, pfn) do { } while (0) >> -#define flush_cache_vmap(start, end) do { } while (0) >> #define flush_cache_vunmap(start, end) do { } while (0) >> #define flush_icache_user_page(vma, page, addr, len) do { } while (0) >> #define flush_dcache_mmap_lock(mapping) do { } while (0) >> #define flush_dcache_mmap_unlock(mapping) do { } while (0) >> >> +/* >> + * It is possible for a kernel virtual mapping access to return a spurious >> + * fault if it's accessed right after the pte is set. The page fault handler >> + * does not expect this type of fault. flush_cache_vmap is not exactly the >> + * right place to put this, but it seems to work well enough. >> + */ >> +static inline void flush_cache_vmap(unsigned long start, unsigned long end) >> +{ >> + smp_mb(); >> +} > I don't know whether this is the best API to do this, and I think > flush_cache_vunmap() also should be a smp_mb(). I do not know neither -:(, it seems that flush_cache_vmap() is better than arch_sync_kernel_mappings(), since function flush_cache_vmap() is used in vmalloc/kasan/percpu module, however arch_sync_kernel_mappings is only used in vmalloc. For flush_cache_vunmap(), it is used before pte_clear(), here is usage example. void vunmap_range(unsigned long addr, unsigned long end) { flush_cache_vunmap(addr, end); vunmap_range_noflush(addr, end); flush_tlb_kernel_range(addr, end); } So I think it is not necessary to add smp_mb() in flush_cache_vunmap(). Regards Bibo Mao > > > Huacai > >> +#define flush_cache_vmap flush_cache_vmap >> +#define flush_cache_vmap_early flush_cache_vmap >> + >> #define cache_op(op, addr) \ >> __asm__ __volatile__( \ >> " cacop %0, %1 \n" \ >> -- >> 2.39.3 >>