All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: Vivian Wang <wangruikang@iscas.ac.cn>
Cc: Alexandre Ghiti <alex@ghiti.fr>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Mike Rapoport <rppt@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <pjw@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v5] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap
Date: Tue, 7 Jul 2026 17:07:00 +0800	[thread overview]
Message-ID: <77B0BBBA-0CDF-49F4-9B07-D35D0D864612@linux.dev> (raw)
In-Reply-To: <99eac2ba-a4e5-4885-aa81-b0c43f6fc4b2@iscas.ac.cn>



> On Jul 7, 2026, at 13:03, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> 
> Please disregard. I made a mistake while submitting this patch.
> 
> I'll send a fixed v6 later. Sorry.

Please fix issues reported by Sashiko excluding pre-existing ones.

Thanks.

> 
> On 7/7/26 12:10, 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 <muchun.song@linux.dev>
>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
>> ---
> [...]



WARNING: multiple messages have this Message-ID (diff)
From: Muchun Song <muchun.song@linux.dev>
To: Vivian Wang <wangruikang@iscas.ac.cn>
Cc: Alexandre Ghiti <alex@ghiti.fr>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	"Liam R. Howlett" <liam@infradead.org>,
	Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
	Mike Rapoport <rppt@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <pjw@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-riscv@lists.infradead.org
Subject: Re: [PATCH v5] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap
Date: Tue, 7 Jul 2026 17:07:00 +0800	[thread overview]
Message-ID: <77B0BBBA-0CDF-49F4-9B07-D35D0D864612@linux.dev> (raw)
In-Reply-To: <99eac2ba-a4e5-4885-aa81-b0c43f6fc4b2@iscas.ac.cn>



> On Jul 7, 2026, at 13:03, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
> 
> Please disregard. I made a mistake while submitting this patch.
> 
> I'll send a fixed v6 later. Sorry.

Please fix issues reported by Sashiko excluding pre-existing ones.

Thanks.

> 
> On 7/7/26 12:10, 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 <muchun.song@linux.dev>
>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
>> ---
> [...]



_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-07-07  9:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07  4:10 [PATCH v5] mm/sparse-vmemmap: flush_cache_vmap() after hotplugging vmemmap Vivian Wang
2026-07-07  4:10 ` Vivian Wang
2026-07-07  5:03 ` Vivian Wang
2026-07-07  5:03   ` Vivian Wang
2026-07-07  9:07   ` Muchun Song [this message]
2026-07-07  9:07     ` Muchun Song
2026-07-09 13:34 ` kernel test robot
2026-07-09 13:34   ` kernel test robot
2026-07-10  1:58 ` Paul Walmsley
2026-07-10  1:58   ` Paul Walmsley
2026-07-10  3:51   ` Vivian Wang
2026-07-10  3:51     ` Vivian Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=77B0BBBA-0CDF-49F4-9B07-D35D0D864612@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=david@kernel.org \
    --cc=liam@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    --cc=wangruikang@iscas.ac.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.