From nobody Sat Jul 25 21:59:22 2026 Received: from cstnet.cn (smtp81.cstnet.cn [159.226.251.81]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9043937EFF1 for ; Mon, 13 Jul 2026 06:15:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.226.251.81 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783923364; cv=none; b=rtp75CXzwU92rg17uBwM9AY1Wbyn6mlBnbuRDHTL+JAYUd3/Qyk8HUfygWslcrmMykieW0fa87B2Csv/r/hvbdCaLXazFByWLhjPX/6AbvcDs/EQjPsIY7CnXH16Wo5TRadgrrnR75iKuWJ2+YuvaCI/Tw0JARzBhsXocel5c9k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783923364; c=relaxed/simple; bh=Z29/gLxndQs7KeU76LNMgImStGwEask/s1EkeDtBn6s=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=bjPwMhF7866QwdYQuDwQG/Ga+SHfQBbQMq1geRD3tHZ2l8e1LCgto8aSxK+r61Wh4THSFVDyRzfZrFgL3ImSS1JgJlgPRE0f+g0vPdnXxVkTGiKi9NvMqg33q+AAc/tE7187r2oGJb8VZNLlA5n71AjVraoMrxvPW0fzMRlfcqI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn; spf=pass smtp.mailfrom=iscas.ac.cn; arc=none smtp.client-ip=159.226.251.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iscas.ac.cn Received: from [127.0.0.2] (unknown [36.110.52.2]) by APP-03 (Coremail) with SMTP id rQCowAAHF86CglRqddeRFw--.29971S3; Mon, 13 Jul 2026 14:15:31 +0800 (CST) From: Vivian Wang Date: Mon, 13 Jul 2026 14:15:20 +0800 Subject: [PATCH v6 1/2] riscv: mm: Make mark_new_valid_map() stuff depend on 64BIT && MMU Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260713-mark-after-vmemmap-populate-v6-1-b945ceba29d4@iscas.ac.cn> References: <20260713-mark-after-vmemmap-populate-v6-0-b945ceba29d4@iscas.ac.cn> In-Reply-To: <20260713-mark-after-vmemmap-populate-v6-0-b945ceba29d4@iscas.ac.cn> To: Alexandre Ghiti , Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Suren Baghdasaryan , Vlastimil Babka Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Vivian Wang X-Mailer: b4 0.15.2 X-CM-TRANSID: rQCowAAHF86CglRqddeRFw--.29971S3 X-Coremail-Antispam: 1UD129KBjvJXoWxJr15ZrWUXF4rXw18uF1DAwb_yoW8tF13pF sFkrn5Gryrur1xZ3y2vr1DWrW3Kw1qga4aq3WDur15Xa1qvr48Jrn5Kry7AryDXFWjgFWF kFyxCryFkw1jy37anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmF14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jr4l82xGYIkIc2 x26xkF7I0E14v26r4j6ryUM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2 IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY 6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17 CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF 0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIx AIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2 KfnxnUUI43ZEXa7VUjhFxUUUUUU== X-CM-SenderInfo: pzdqw2pxlnt03j6l2u1dvotugofq/ None of the code relating to mark_new_valid_map() does anything useful without CONFIG_64BIT=3Dy && CONFIG_MMU=3Dy, because the new_valid_map_cpus_check code is only used if CONFIG_64BIT, and the exception codes checked there can only happen with CONFIG_MMU=3Dy. Therefore, make these conditional on CONFIG_64BIT=3Dy && CONFIG_MMU=3Dy to simplify programming, since we do not have to handle CONFIG_MMU=3Dn when changing this code in the future. This also removes some unused code on the entry path for CONFIG_MMU=3Dn. Signed-off-by: Vivian Wang --- arch/riscv/include/asm/cacheflush.h | 2 +- arch/riscv/kernel/entry.S | 2 +- arch/riscv/mm/init.c | 2 ++ 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/c= acheflush.h index 8cfe59483a8f..58e787fad029 100644 --- a/arch/riscv/include/asm/cacheflush.h +++ b/arch/riscv/include/asm/cacheflush.h @@ -40,7 +40,7 @@ do { \ flush_icache_mm(vma->vm_mm, 0); \ } while (0) =20 -#ifdef CONFIG_64BIT +#if defined(CONFIG_64BIT) && defined(CONFIG_MMU) /* This is accessed in assembly code. cpumask_var_t would be too complex. = */ extern DECLARE_BITMAP(new_valid_map_cpus, NR_CPUS); extern char _end[]; diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S index c6988983cdf7..3ae498779adf 100644 --- a/arch/riscv/kernel/entry.S +++ b/arch/riscv/kernel/entry.S @@ -137,7 +137,7 @@ SYM_CODE_START(handle_exception) .Lrestore_kernel_tpsp: csrr tp, CSR_SCRATCH =20 -#ifdef CONFIG_64BIT +#if defined(CONFIG_64BIT) && defined(CONFIG_MMU) /* * The RISC-V kernel does not flush TLBs on all CPUS after each new * vmalloc mapping or kfence_unprotect(), which may result in diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 5b1b3c88b4d1..3e450890be07 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -37,7 +37,9 @@ =20 #include "../kernel/head.h" =20 +#if defined(CONFIG_64BIT) && defined(CONFIG_MMU) DECLARE_BITMAP(new_valid_map_cpus, NR_CPUS); +#endif =20 struct kernel_mapping kernel_map __ro_after_init; EXPORT_SYMBOL(kernel_map); --=20 2.54.0 From nobody Sat Jul 25 21:59:22 2026 Received: from cstnet.cn (smtp81.cstnet.cn [159.226.251.81]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B8B93815FA for ; Mon, 13 Jul 2026 06:16:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.226.251.81 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783923363; cv=none; b=vC9DNpMQS+BvC8W5+/cZ+UibHXdFEzANUknAwRA2NlRi+ZHlFgdTYqVrQNOzqe/DlhR7BBwnwjgH3F5nN40vnyKvfIlgGWrCqBjUbc1R8CDAAg28Z8Tg5lEPnm9TVst+OxfuA5xwA5aG8a70KcrbbjqssvgVk+NU1mvpH4uaqNA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783923363; c=relaxed/simple; bh=eZ31qpKVUIBcCjI/mLuvTOSP7SITSpKBMPhily8XQfo=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=ViBc0kOKh5FF738iha8H/301uBCtgUxtT0M9poQnXS7fupegqYGXboKaQgKd/KH9bOPj8r/bftFsWmUB5QNUtkSzok8Yo53owLWxmxMPruCS+EqBn7lYsKzwHoq9NZkY0mPd3dmnpj6/NFRmiXwj+s4207jPhlrkx8Vfq/3sILg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn; spf=pass smtp.mailfrom=iscas.ac.cn; arc=none smtp.client-ip=159.226.251.81 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iscas.ac.cn Received: from [127.0.0.2] (unknown [36.110.52.2]) by APP-03 (Coremail) with SMTP id rQCowAAHF86CglRqddeRFw--.29971S4; Mon, 13 Jul 2026 14:15:31 +0800 (CST) From: Vivian Wang Date: Mon, 13 Jul 2026 14:15:21 +0800 Subject: [PATCH v6 2/2] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260713-mark-after-vmemmap-populate-v6-2-b945ceba29d4@iscas.ac.cn> References: <20260713-mark-after-vmemmap-populate-v6-0-b945ceba29d4@iscas.ac.cn> In-Reply-To: <20260713-mark-after-vmemmap-populate-v6-0-b945ceba29d4@iscas.ac.cn> To: Alexandre Ghiti , Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Suren Baghdasaryan , Vlastimil Babka Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Muchun Song , Vivian Wang X-Mailer: b4 0.15.2 X-CM-TRANSID: rQCowAAHF86CglRqddeRFw--.29971S4 X-Coremail-Antispam: 1UD129KBjvJXoW7Zw15urWxZFW5AF4UJr18Krg_yoW8tFy3pF ZrCwn5trZ5WFyxW34UA3W2gr1Fg3sIga48G3WrA34UAwn8XFyUWr98Kay0kryUXFWrXayx Crs0kry5WFyDZ3DanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUmF14x267AKxVWrJVCq3wAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2048vs2IY020E87I2jVAFwI0_Jryl82xGYIkIc2 x26xkF7I0E14v26ryj6s0DM28lY4IEw2IIxxk0rwA2F7IY1VAKz4vEj48ve4kI8wA2z4x0 Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xIIjxv20xvEc7CjxVAFwI0_Cr0_Gr1UM2 8EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVCY1x0267AKxVW0oVCq3wAS 0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG6I80ewAv7VC0I7IYx2 IY67AKxVWUAVWUtwAv7VC2z280aVAFwI0_Gr1j6F4UJwAm72CE4IkC6x0Yz7v_Jr0_Gr1l F7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E8cxan2 IY04v7MxkF7I0En4kS14v26r1q6r43MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY 6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17 CEb7AF67AKxVW8ZVWrXwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF 0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIx AIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVW8JVW8JrUvcSsGvfC2 KfnxnUUI43ZEXa7VUb_HUDUUUUU== X-CM-SenderInfo: pzdqw2pxlnt03j6l2u1dvotugofq/ section_activate() does not flush TLB after populating new vmemmap pages. On most architectures, this is okay. However it is a problem on RISC-V since there the TLB caching non-present entries is permitted, which causes spurious faults on some hardwares. This seems to be most easily reproduced with DEBUG_VM=3Dy and PAGE_POISONING=3Dy, which causes these newly mapped struct pages to be poisoned i.e. written to immediately after mapping. Extend the RISC-V flush_cache_vmap() to also handle the vmemmap range, and call it after hotplugging vmemmap, which gets the possible spurious fault handled in the exception handler. At least for now, the only other architecture with both SPARSEMEM_VMEMMAP and flush_cache_vmap() is PowerPC, which has a similar problem with newly valid PTEs. But there flush_cache_vmap() is just a ptesync. So it should be safe to do this for generic code while having minimal performance impact. Suggested-by: Muchun Song Signed-off-by: Vivian Wang Acked-by: David Hildenbrand (Arm) Reviewed-by: Muchun Song --- arch/riscv/include/asm/cacheflush.h | 3 ++- mm/sparse-vmemmap.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/c= acheflush.h index 58e787fad029..c2b0a2928f06 100644 --- a/arch/riscv/include/asm/cacheflush.h +++ b/arch/riscv/include/asm/cacheflush.h @@ -56,7 +56,8 @@ static inline void mark_new_valid_map(void) #define flush_cache_vmap flush_cache_vmap static inline void flush_cache_vmap(unsigned long start, unsigned long end) { - if (is_vmalloc_or_module_addr((void *)start)) + if (is_vmalloc_or_module_addr((void *)start) || + (start >=3D VMEMMAP_START && end <=3D VMEMMAP_END)) mark_new_valid_map(); } #define flush_cache_vmap_early(start, end) local_flush_tlb_kernel_range(st= art, end) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 99e2be39671b..ebd3ac997f64 100644 --- a/mm/sparse-vmemmap.c +++ b/mm/sparse-vmemmap.c @@ -564,6 +564,8 @@ struct page * __meminit __populate_section_memmap(unsig= ned long pfn, if (r < 0) return NULL; =20 + flush_cache_vmap(start, end); + return pfn_to_page(pfn); } =20 --=20 2.54.0