From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C25561A3172 for ; Mon, 1 Jun 2026 07:13:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780298039; cv=none; b=G0fwnfMp45lj+h2M6xX+9w3ubdUE2ho3PUMQNWWp0L5qxNxOrLmcXAvXc2Kx1ZAkABqSZcg68hYYoCK37Fsdjm9uybuXrA7uVMm6KTTJd39gq/PYVuhaHhG3obZv+epseqTNW43L5Ml9NeOcW2DSYOjrHsn3YhNm604LrYJscns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780298039; c=relaxed/simple; bh=NQw6sY7FDgG9yw4ZGRGGG1RT1B5/JgWjmn1j2mT+55k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=papOcYeCxO8jM3BzoZydJ7m+CfVgB5716VaSY149jZOufMxbl8HLXjHyB7SyhQDBA6NkCYvpmQu6NIyCuhhgyXEBDCQpDN9L/iQCV1uQrGhvzFox5murguMhqbqYvtXYTlVaBkPPKl4EJzJ8P5Iy+17XeiHs7rCjbycPhfP2s8A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GikPScST; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GikPScST" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14EDD1F00898; Mon, 1 Jun 2026 07:13:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780298038; bh=uJvEmv+W0qDNB0rejgQapdJuH96Fa9lGuF//EYZmLLc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=GikPScST/JdGxywFRDULWNH7RT2OD7214GAe1g7QCDbKOyunBXFEScW2eXeSdFBPX 1nmcWK2mHQDwPeaDPZXRm/6Bvs/9e5PY0+uhi6uaM8IM3pMX3wxGR1mqYzxqKy9xXN ae/gKZTG6FKLOXf0W8IqggTU5Qm1U2lkWpnzmJcCIPd/8GPvwIjoIPiMTQYXz9zgM3 OkrKoMuqeZLFrg+CgQybiH1dWrvfv/PMV20Px6ijnfJ2omnTN7SO/hCx0nccWkLV7p Jf6WK823XOMgBj7INRW39n3G9pazy3NTIE1Ix6CtCLZRH0GMC/mD4oQdQtJZKDtell zPk8/h+cl6k2Q== Date: Mon, 1 Jun 2026 10:13:49 +0300 From: Mike Rapoport To: Vivian Wang Cc: Paul Walmsley , Palmer Dabbelt , Alexandre Ghiti , Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] riscv: mm: Call mark_new_valid_map() after hotplugging vmemmap Message-ID: References: <20260525-mark-after-vmemmap-populate-v1-1-e698d859ba16@iscas.ac.cn> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260525-mark-after-vmemmap-populate-v1-1-e698d859ba16@iscas.ac.cn> Hi, On Mon, May 25, 2026 at 12:23:29PM +0800, Vivian Wang wrote: > section_activate() creates new mappings in the vmemmap range without > flushing TLB, which may cause faults on some RISC-V implementations that > cache non-present PTEs and crashes. > > This seems to be most easily reproduced with DEBUG_VM=y and > PAGE_POISONING=y, which causes these newly mapped struct pages to be > poisoned i.e. written to immediately after mapping. > > Add a hook vmemmap_populate_finalize() in __populate_section_memmap(), > and implement it as calling mark_new_valid_map() on RISC-V, which > arranges for the exception handler to deal with these faults if they > happen. > > Signed-off-by: Vivian Wang > --- > I'm not sure if this is the right place to add this hook. I didn't add > it to vmemmap_populate because it doesn't seem to be called in all > cases. Please advise. Indeed it looks like we'd need a new hook to let architectures run post-populate actions. The explanation that says why a new hook is needed should be a part of the changelog. > Depends on my earlier kfence fixes for mark_new_valid_map() [1]. > > Found while testing AMD_HSA/ZONE_DEVICE on SpacemiT K3. Using > ZONE_DEVICE requires another fix [2]. > > [1]: https://lore.kernel.org/linux-riscv/20260303-handle-kfence-protect-spurious-fault-v2-0-f80d8354d79d@iscas.ac.cn > [2]: https://lore.kernel.org/linux-riscv/20260309-riscv-sparsemem-vmemmap-limits-v1-2-f40efe18e3cd@iscas.ac.cn > --- > arch/riscv/mm/init.c | 6 ++++++ > include/linux/mm.h | 1 + > mm/sparse-vmemmap.c | 6 ++++++ > 3 files changed, 13 insertions(+) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 706f43523935..cf9ae4099f82 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -1360,6 +1360,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > */ > return vmemmap_populate_hugepages(start, end, node, altmap); > } > + > +void __meminit vmemmap_populate_finalize(void) > +{ > + /* Avoid faults on cached non-present TLB entries. */ > + mark_new_valid_map(); > +} > #endif > > #if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > diff --git a/include/linux/mm.h b/include/linux/mm.h > index 0b776907152e..65deccbd7e31 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -4882,6 +4882,7 @@ int vmemmap_populate_hugepages(unsigned long start, unsigned long end, > int node, struct vmem_altmap *altmap); > int vmemmap_populate(unsigned long start, unsigned long end, int node, > struct vmem_altmap *altmap); > +void vmemmap_populate_finalize(void); > int vmemmap_populate_hvo(unsigned long start, unsigned long end, > unsigned int order, struct zone *zone, > unsigned long headsize); > diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c > index 6eadb9d116e4..2b860d2b1703 100644 > --- a/mm/sparse-vmemmap.c > +++ b/mm/sparse-vmemmap.c > @@ -544,6 +544,10 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn, > > #endif > > +void __weak __meminit vmemmap_populate_finalize(void) > +{ > +} > + The existing hooks in sparse-vmemmap use #ifdef rather than __weak functions. Take a look at vmemmap_can_optimize() and vmemmap_populate_compound_pages(). Let's keep it consistent. > struct page * __meminit __populate_section_memmap(unsigned long pfn, > unsigned long nr_pages, int nid, struct vmem_altmap *altmap, > struct dev_pagemap *pgmap) > @@ -561,6 +565,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn, > else > r = vmemmap_populate(start, end, nid, altmap); > > + vmemmap_populate_finalize(); > + > if (r < 0) > return NULL; > > > --- > base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731 > change-id: 20260525-mark-after-vmemmap-populate-68bd790839c9 > prerequisite-message-id: <20260303-handle-kfence-protect-spurious-fault-v2-0-f80d8354d79d@iscas.ac.cn> > prerequisite-patch-id: fdc42f2647e21d111f44a6532887a6705cd470a9 > prerequisite-patch-id: 096fa339c84c36643ae4311fd8362dc63e23d950 > prerequisite-patch-id: 305c876a5f4a23a840a8142aea79b796ed297545 > prerequisite-patch-id: d78cb55d6a616b1170f06a401c8fd44acd11e5d5 > prerequisite-patch-id: b02b4a76e94f3e2821291d4c23b46f6e5ecf5203 > > Best regards, > -- > Vivian Wang > -- Sincerely yours, Mike.