On 18/02/25 16:39, Dave Hansen wrote: > 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. Urgh, that'll teach me to send emails that late - I did indeed mean the vmalloc() range, not at all VMEMMAP. IIUC *neither* are present in the user kPTI page table and AFAICT the page table swap is done before the actual vmap'd stack (CONFIG_VMAP_STACK=y) gets used.
