Re: [PATCH v4 29/30] x86/mm, mm/vmalloc: Defer flush_tlb_kernel_range() targeting NOHZ_FULL CPUs

[Dave Hansen <dave.hansen@xxxxxxxxx>]

On 2/18/25 14:40, Valentin Schneider wrote:
>> In practice, it's mostly limited like that.
>>
>> Architecturally, there are no promises from the CPU. It is within its
>> rights to cache anything from the page tables at any time. If it's in
>> the CR3 tree, it's fair game.
>>
> So what if the VMEMMAP range *isn't* in the CR3 tree when a CPU is
> executing in userspace?
> 
> AIUI that's the case with kPTI - the remaining kernel pages should mostly
> be .entry.text and cpu_entry_area, at least for x86.

Having part of VMEMMAP not in the CR3 tree should be harmless while
running userspace. VMEMMAP is a purely software structure; the hardware
doesn't do implicit supervisor accesses to it. It's also not needed in
super early entry.

Maybe I missed part of the discussion though. Is VMEMMAP your only
concern? I would have guessed that the more generic vmalloc()
functionality would be harder to pin down.