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 4665E1FE471 for ; Fri, 10 Jul 2026 01:58:25 +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=1783648707; cv=none; b=IYm5OCzK0YlEAyM9HGX1Qsxk5IF5mBe2FbW1dpqMahBFKaVuZrmwrcft1Z6bVmKIc8JT7OfJ3UMIwJVkgpcVzfb/rRmj/4zqbt+mkgk3mnnxCHg5dWgyUsM6oaBHhlX47FbLtjNVdyA86dxQzgZa9oKuNYrKd8ZLfJ9S9swRWHo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783648707; c=relaxed/simple; bh=6NmzgxXICIx40l1HpZrPXDckU9PsakfdIc1uuqUevlA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=AKQdvRDnSgX/J7IUcVX0ktR7NnxZcaqc5FuvS5+NJHBOtHCgKpZ9nGG7q607VbbacZLJaPqPwBoFCyK46cUx56PFi6s+AJqmIMvAWAOXQU5VbcgvBWA5nMr1Zzc5Bn/V+YWBHhN6+5W8Z+G77byrHxRYa6fe4xzvYphdtQRFrtc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MGalIMuS; 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="MGalIMuS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDC281F000E9; Fri, 10 Jul 2026 01:58:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783648705; bh=31QGHBL7hL4Fq4DMfqiOa2FOYxi7YJIdv0o6jQ5a0cE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MGalIMuSksQjYh3t9v2KG/f3fveZH7k1wlOpxdiQrmVDRZTtwPlcMyaO5qXxQTHo7 +yK3DO3g3dkP/103x3fpxGVwvsG0aEUo5o+FfBbjaFsq03/jnJ0SOimJ76IXBL8zjg gP186Lyy7UJQ9xoyIJ6GGR1lBEKONAAn5d+N1Jow/we7QS1mq+9Qee9rGzjgouUqf8 +Aqfw0SZrsj02mxky66wvNy2dQQAaOm1zh+QsdwoqO69fsUvzJK8FETbE6o9Xy7bgI F11xwp/iOfKPjg5Qd+PoOeh1VZA5HNR7TXc7XCu3FPfUG18fEDf3cXm4gBFrEdVh12 7AcCj1awkMXpQ== Date: Thu, 9 Jul 2026 19:58:23 -0600 (MDT) From: Paul Walmsley To: Vivian Wang cc: Alexandre Ghiti , Andrew Morton , David Hildenbrand , "Liam R. Howlett" , Lorenzo Stoakes , Michal Hocko , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Suren Baghdasaryan , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org, Muchun Song Subject: Re: [PATCH v5] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap In-Reply-To: <20260707-mark-after-vmemmap-populate-v5-1-77d1ded3cae3@iscas.ac.cn> Message-ID: References: <20260707-mark-after-vmemmap-populate-v5-1-77d1ded3cae3@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 Hi Vivian, On Tue, 7 Jul 2026, Vivian Wang wrote: > 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=y and > PAGE_POISONING=y, 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 > --- > Changes in v5: > - Remove hook, use existing flush_cache_vmap() (Muchun) > - Link to v4: https://patch.msgid.link/20260630-mark-after-vmemmap-populate-v4-1-febbc15da028@iscas.ac.cn > > Changes in v4: > - Rebase on v7.2-rc1, drop dependencies > - (No code changes otherwise) > - (A concurrency fix for mark_new_valid_map was sent independently) > https://lore.kernel.org/linux-riscv/20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn/ > - Link to v3: https://patch.msgid.link/20260605-mark-after-vmemmap-populate-v3-1-a06001ac9264@iscas.ac.cn > > (See v3 link for older changes) > --- > arch/riscv/include/asm/cacheflush.h | 3 ++- > arch/riscv/mm/init.c | 1 + > mm/sparse-vmemmap.c | 2 ++ > 3 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/include/asm/cacheflush.h b/arch/riscv/include/asm/cacheflush.h > index 8cfe59483a8f..e935db27f09f 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 >= VMEMMAP_START && end <= VMEMMAP_END)) Is there an off-by-one error here? VMEMMAP_END is currently set to VMALLOC_START on RISC-V. Am assuming you'll update this patch one more time? At that point I'll plan to add it into v7.2-rc, assuming Andrew doesn't object. - Paul