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 0CA42D18140 for ; Tue, 15 Oct 2024 02:54:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5E7706B009A; Mon, 14 Oct 2024 22:54:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5473F6B00A5; Mon, 14 Oct 2024 22:54:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3E8906B00A6; Mon, 14 Oct 2024 22:54:04 -0400 (EDT) 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 1BD956B009A for ; Mon, 14 Oct 2024 22:54:04 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3C848AC0F5 for ; Tue, 15 Oct 2024 02:53:47 +0000 (UTC) X-FDA: 82674317040.18.74E0BFD Received: from mail.loongson.cn (mail.loongson.cn [114.242.206.163]) by imf21.hostedemail.com (Postfix) with ESMTP id E8A8A1C000F for ; Tue, 15 Oct 2024 02:53:46 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.hostedemail.com: domain of maobibo@loongson.cn designates 114.242.206.163 as permitted sender) smtp.mailfrom=maobibo@loongson.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728960794; a=rsa-sha256; cv=none; b=VOJeabxh0FyW1kP5jacdPbBFXa+0i83ezhm7WZ6SA9dGpp2ZfJQFsH9P6JwZzTZiclerRY 7eGvbRrnumGnS5adYOt9NDQVe6SqSLY/q7V3/fGDGDuivnpdzC+ImlKdlNoyIMS/yHwxnK CLmZkZU1pwrISKh1wA5oMf2DmSgP2TE= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf21.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=1728960794; 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=antQz67lcCNued2pq+xEdHFbmajHIbSvTPFsRsj2B6Y=; b=LFFFNQbrDDd4bYlEzt2Nlv30GTAMnoTyMOxl8uCbP9ImxXSvfle3/fZwpNWvd10m5rpxWs T+d3mPHqYk8YXZmIf7BDfmpu0nZeSEV1FsbJM2+nPJkXdaTvTX5qsKX84GCELUrfScJVu4 ey3i5QW97LOhMlyilwN25Un/p9+4X3w= Received: from loongson.cn (unknown [10.20.42.62]) by gateway (Coremail) with SMTP id _____8BxnnNE2Q1ni4kcAA--.41533S3; Tue, 15 Oct 2024 10:53:56 +0800 (CST) Received: from [10.20.42.62] (unknown [10.20.42.62]) by front1 (Coremail) with SMTP id qMiowMAxSeZB2Q1nClAqAA--.8242S3; Tue, 15 Oct 2024 10:53:56 +0800 (CST) Subject: Re: [PATCH v2 2/3] 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: <20241014035855.1119220-1-maobibo@loongson.cn> <20241014035855.1119220-3-maobibo@loongson.cn> From: maobibo Message-ID: Date: Tue, 15 Oct 2024 10:53:35 +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:qMiowMAxSeZB2Q1nClAqAA--.8242S3 X-CM-SenderInfo: xpdruxter6z05rqj20fqof0/ X-Coremail-Antispam: 1Uk129KBj93XoWxXw1ktw1kAFykJrWfWw15GFX_yoWrXF1Dpr W2kas8Krs7WF4fXw1jvr13Wr1kX3srWF18Jw1FvryDCwsrXFy29ryxWrW8Wry3Xa4rJa1x Cw4UKw15WFWUXFXCm3ZEXasCq-sJn29KB7ZKAUJUUUU8529EdanIXcx71UUUUU7KY7ZEXa sCq-sGcSsGvfJ3Ic02F40EFcxC0VAKzVAqx4xG6I80ebIjqfuFe4nvWSU5nxnvy29KBjDU 0xBIdaVrnRJUUUvFb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I20VC2zVCF04k26cxKx2 IYs7xG6rWj6s0DM7CIcVAFz4kK6r1Y6r17M28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48v e4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xIIjxv20xvEc7CjxVAFwI 0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I8E87Iv6xkF7I0E14v2 6r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc804VCY07AIYIkI8VC2zVCFFI0UMc 02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUGVWUXwAv7VC2z280aVAF wI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4 CEbIxvr21l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG 67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MI IYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E 14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJV W8JwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyTuYvjxU70Pf DUUUU X-Rspam-User: X-Rspamd-Queue-Id: E8A8A1C000F X-Rspamd-Server: rspam01 X-Stat-Signature: bz1q7149jrocgfmyi5sonsod3oz6sn4g X-HE-Tag: 1728960826-610349 X-HE-Meta: U2FsdGVkX1+9P2d2yYm5NHJtSfhvB+iRgrF+4rrxRjDjewDFsZErHzrXvDDggMUqUTelpjGlaVcF9VS07zC7dfpbR352Pi4ky51Nz4Uq8Ko847+XRFhbdoGK3t8f9RmRBPe/bfjdBEFF/js0utmTPKMnke4u/cYmUB4F57g5gddQMmsGDg51rmgHpohvSLGiqUnmyK4bFihFj0WUEIq8n/1W4BcbiFT4oh6j6uTQjBLUm9MJLb2TR+Mhltan6vd4UM7mhmAQ6Ba4Jnncw7KAXZQq95FAu/+RvB90Bg1jgxjuEVpzmWfp4MswmWC0J4p2LjniT6NG20dd1LDzfG5l5szdedz4Z5ixQMFqdswJBfDwryuZQTCtIVBjozQGFzuITwwTBvRJzmeJDpxtKySNx0iwQvSzfuvylpu4Vr89/jDci/WndrgMArPoqyU1QKIUVtU6oG58k4kXT7IelQT6iUnTUY7zXOzorNgi9dXVfeaQCgekm2uQDVdOa974Hm4hdiG2MmLaWywQWQq6ndYw+KrV4Ik/WPP0yu1bnWm4ICDgvo3pnvktrJOQVlKD1phYvOrSfgRwCDj+kV0yofClipAvu/KOaf7xlA9bKd4x8yQIXZjs83KLSjTHTQuHvb8GZjXrO67WpOpH7vG6pA+GPsvUQ45b66hvUTjZ9pDYF6Z78mlIiCfok/lUCSC+dy4FuA5ggWj+ltYcJ7Ws8P9hrLx04LAD2CFwqDcfrHHnBTTf0fbHSdq7p4lxN/ij59NDwvA5LGYZK2VQNJwy7BtBP+AlVMgnzb/mYlLiDL9GQDLVLKnoWA7IIzDQRQ7X24Bhbuy3OqmX/IZEpeSLa4s57OZTqTdofdnobLoStW6EYI/Sv1F6D3k3SNX3e1k01xbtETwJnlZnjALBkvskl+1Y3UU+AVpjyPuPlJXYFwMC+cyZJDljfd5tBGWM8wDdAqv2jsFf9+HXtAWe4BGkL6+ fJz3cXFO Q/V4WyOq9djx9KYOH4M7FgbKK+FiBgavxiVgoFJvGRoNXeBNP37r/zJ8AcK1PuE1/z125HWiptADABrf45yamGCXyGONSpMCB0y7v3jA0rnbkrXJq0ncoAchoKyVgHfNNgfJcRlRmVStwT+yal/SPRrPvlx/JqpqXXuEKoCqottepVJIbEaL9BTvyCCgEJhckNV9U 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/10/14 下午2:31, Huacai Chen wrote: > Hi, Bibo, > > On Mon, Oct 14, 2024 at 11:59 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(); >> +} >> +#define flush_cache_vmap flush_cache_vmap >> +#define flush_cache_vmap_early flush_cache_vmap > From the history of flush_cache_vmap_early(), It seems only archs with > "virtual cache" (VIVT or VIPT) need this API, so LoongArch can be a > no-op here. Here is usage about flush_cache_vmap_early in file linux/mm/percpu.c, map the page and access it immediately. Do you think it should be noop on LoongArch. rc = __pcpu_map_pages(unit_addr, &pages[unit * unit_pages], unit_pages); if (rc < 0) panic("failed to map percpu area, err=%d\n", rc); flush_cache_vmap_early(unit_addr, unit_addr + ai->unit_size); /* copy static data */ memcpy((void *)unit_addr, __per_cpu_load, ai->static_size); } > > And I still think flush_cache_vunmap() should be a smp_mb(). A > smp_mb() in flush_cache_vmap() prevents subsequent accesses be > reordered before pte_set(), and a smp_mb() in flush_cache_vunmap() smp_mb() in flush_cache_vmap() does not prevent reorder. It is to flush pipeline and let page table walker HW sync with data cache. For the following example. rb = vmap(pages, nr_meta_pages + 2 * nr_data_pages, VM_MAP | VM_USERMAP, PAGE_KERNEL); if (rb) { <<<<<<<<<<< * the sentence if (rb) can prevent reorder. Otherwise with any API kmalloc/vmap/vmalloc and subsequent memory access, there will be reorder issu. * kmemleak_not_leak(pages); rb->pages = pages; rb->nr_pages = nr_pages; return rb; } > prevents preceding accesses be reordered after pte_clear(). This Can you give an example about such usage about flush_cache_vunmap()? and we can continue to talk about it, else it is just guessing. Regards Bibo Mao > potential problem may not be seen from experiment, but it is needed in > theory. > > Huacai > >> + >> #define cache_op(op, addr) \ >> __asm__ __volatile__( \ >> " cacop %0, %1 \n" \ >> -- >> 2.39.3 >> >>