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 89EC2CF259D for ; Mon, 14 Oct 2024 06:31:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 002F26B0085; Mon, 14 Oct 2024 02:31:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EF2536B0088; Mon, 14 Oct 2024 02:31:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBA376B0089; Mon, 14 Oct 2024 02:31:18 -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 BD94E6B0085 for ; Mon, 14 Oct 2024 02:31:18 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 14A7A80BB9 for ; Mon, 14 Oct 2024 06:31:12 +0000 (UTC) X-FDA: 82671235668.24.AEE6CF5 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id A9660C0009 for ; Mon, 14 Oct 2024 06:31:09 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HuQhmyUs; spf=pass (imf22.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728887404; a=rsa-sha256; cv=none; b=zlMBzRd4kOl5J0VaRATpYF//bDTVB1Q89hENFHYMXrInuMVQWEa2XiLcYmBpaG+eatjgqB viQVYY0iekPMmnkAVIAmeM3ANFvmJP4BFRoZoHPWKISOEbUACjshbRDuF8bob6XbDgSmnH GC1NVhwvFSBHokrLFz+/dKMxKRLVh/k= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=HuQhmyUs; spf=pass (imf22.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728887404; 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:dkim-signature; bh=SQmEFW7STiOc3KKW8fprzn3mBCo6X6T822so98r9IJ0=; b=mq33M6TN/5pFSuxJRNFfBOfEQTIUnqW1nCEmQimZyZGc/+MvVsKCbbZFfjpl0q8AFKgOil zc00v2lqyB1YO86Ium8lG0T5CF+D0SmXfekDjgtXoOxgLjl/srNTk7f7M0US/J23O/eidu a0BgKF0LP7dAFqrP0as+avHjt7kTgkE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 29BAD5C5A31 for ; Mon, 14 Oct 2024 06:31:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BFDBC4CED0 for ; Mon, 14 Oct 2024 06:31:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1728887475; bh=gtdpBTeQLmr18gVrhQkVp+R+fm5FD66vp+1RtcWutpI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=HuQhmyUsxHFQosKnFrRPoQFxO3qFr4NwggE3ksPLx9oycfgViN4ZTGJhLXWsXjIU8 ntd66f/prdD5VrSjGyi8nFxZJ7bsfnabc/eF6nTwdYcCayDM+k3NnFSi4wMVAcgj6s wFPB2arEtAtaA6TIH3dwaiS+ZTflir5FESdte65uqM3CA6BRjq4Ka/ZL8RMydvqYb9 M/6a5G6LyV3jlpHLZfwQwqi0L7ufQpe9rT+tni85EGxSDpe2l4DzkPzvZpbTLGsclq HDxhLzrC78sANOS0fHx+dcoJ/mWVzdGfzwrQX6y8K0lu+y+O9TlqQbdbs5OGg38xKg jOBE/IrYJZI4w== Received: by mail-lf1-f46.google.com with SMTP id 2adb3069b0e04-539fb49c64aso241996e87.0 for ; Sun, 13 Oct 2024 23:31:15 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXYW+fwb1KFzLzsopV6M94299aE/16ywz/OOvrtOP+WrQuVpNKe9r10qB6GxITqGIfMxgFZpX+FSw==@kvack.org X-Gm-Message-State: AOJu0YzWLB6IA+L04BoEKCrqxmj++1rS4poGKzFJNQve5wcq+HVDP5hZ uuGZHeF+/11Jg2W3qNOBwtwzFzL5ZJq9f/56kISOyeJanT+pUP17R3dqTnkqSYeemPM6BXWfxCm l1aCNxnk1flfsnyrhQcJ6i7+UhV8= X-Google-Smtp-Source: AGHT+IE2ikZfTCj1ldIG4d5HvpoPlo2JvKFiNjMNNj8Hkiza0u+9foosUHeMoLBWDVDJbRUUk8gLgI7f1jDWzR6Lh6E= X-Received: by 2002:a05:6512:1598:b0:530:b773:b4ce with SMTP id 2adb3069b0e04-539e551a25emr2964252e87.33.1728887473738; Sun, 13 Oct 2024 23:31:13 -0700 (PDT) MIME-Version: 1.0 References: <20241014035855.1119220-1-maobibo@loongson.cn> <20241014035855.1119220-3-maobibo@loongson.cn> In-Reply-To: <20241014035855.1119220-3-maobibo@loongson.cn> From: Huacai Chen Date: Mon, 14 Oct 2024 14:31:02 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 2/3] LoongArch: Add barrier between set_pte and memory access To: Bibo Mao 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 9tetxo8jdf1pywq6ihsp5mopej8jumnc X-Rspamd-Queue-Id: A9660C0009 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1728887469-614535 X-HE-Meta: U2FsdGVkX1/OUancp8s6Wz2oiDK2HkYrLiWjhpySav7eqWxMNtGHnFRdgvkLYDH4zzTXr6dw/KBSwDKoPTfazGHT+JWjbobOMgVara4tsjXBtHm5knDuYypEzjnqCV9FNMCJatzjR4W66K02tWpb7np3bTroYUBqKix1VjV98l5c5/1P/Z1uChliLid3NpqfvEPEy6pBtZYJYLjlzvvkFF1rUs6vRuI6Xi0UnTUwHzJXu76WzZoGln/senyy5D5MPPen6PWThc52MKV/GQ0FT3re6CFXI1A5IR+QyK10V9uYeu0BwUKAep39ZZUF163YDTL0Yn+lJmjVzkAyHvAUv+g4YChu7BgHO5Z6cdZNf+exjxY8RGZPacJ402VRhOc8nbSG5hDMuZ6PvuOBCeCZQHZQdc90jb2wkFKcoNd6LRQcL6uagGbxXC0qDmVGG9jfRmMZD5RLcpiW5PzlmNUNSqSAvJykRnSGIqJvZ4TvanKrJsFUKvVrqyO1Ao3Pg/o5pW1u6Bp2IdRk/azKXfx9K1IexESYI2tNyD730mpFKs47xIbS7aRUVMHyBHSSxNMOQcP0mBU5f4uvyo5UH4JP27mX0oLa9k8KaQWJk99q9zBUTVzX2PW7iVBU3kNOzQro5exRhixryFYH598FnJWiv2OEUa+tq7Em7U/RQ6rCVlW8tIWSnaY3vydEI/VPBQqeYyiW9Zxs9iUAXQXnX8w7fP4ANRghY80c4wRYClUWyI8iKsDPyG7v3mp1Qfg1SUfd+HkbMACKfNS5QO0PZy3WLrpkgCjwQ8DgoEgXywGE1muDn6UbPjmrcpmGFhXK+8v6ujqiZkvqi7N4qa9E5gyVLmB+ACzFF5GVVH7ZDmSwLJIfFNq+HXoWYWfVi37ZpC31YJyIaLCTLtaOCkIPyJzaYaSb7dw3tLa0ADD3MtFefLgtV3oauQ9ehsgfBupolyitLeRLJ3bjMSrO+ikjP6x zrZxQKa1 5IRMJbE+DRpwNovErdSK1qpx1lBeTLVIUu0Mp2TN2Sjxy/jzldijPBb5avp5pDRt1Gttg6AHiTEs3R0mHl8uyvhyDx1VUoVXllKruzJyboWBADQnXgqh/07xAq7DBfaVC7rPpUcLmQMB5p0z9IxCEv+pkKJjJ2Sj7C/tCCTLUtKGoWWvntN7deiQtsJqSIxz+04hZ74D44F/cwedbEWpeCDowIMgO5qQzlXuV2YWXjaaZCVd81XZ9eizCuzeNyjUYA0XPuSS0TVCLfuQercX5Hdju4jzE/bIXuD8cf3jzurZmudEG/d4EruBDpvPL8wz4ZWt2OaNzJy28IePEGMSBRKd0y1OQOiFTU3d3fa1u0VBhAcUJ/PoUVCoMmkhPAnR97mcsQlbBJPwGtiqRk4yKSuTeWg== 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: Hi, Bibo, On Mon, Oct 14, 2024 at 11:59=E2=80=AFAM Bibo Mao wro= te: > > 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/inc= lude/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, un= signed 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 { } wh= ile (0) > #define flush_dcache_mmap_unlock(mapping) do { } while (0) > > +/* > + * It is possible for a kernel virtual mapping access to return a spurio= us > + * fault if it's accessed right after the pte is set. The page fault han= dler > + * does not expect this type of fault. flush_cache_vmap is not exactly t= he > + * right place to put this, but it seems to work well enough. > + */ > +static inline void flush_cache_vmap(unsigned long start, unsigned long e= nd) > +{ > + 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. 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() prevents preceding accesses be reordered after pte_clear(). This 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 > >