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/19/25 09:08, Joel Fernandes wrote:
>> Pretty much so yeah. That is, *if* there such a vmalloc'd address access in
>> early entry code - testing says it's not the case, but I haven't found a
>> way to instrumentally verify this.
> Ok, thanks for confirming. Maybe there is an address sanitizer way of 
> verifying,
> but yeah it is subtle and there could be more than one way of solving it. Too
> much 'fun' 😉
For debugging, you could just make a copy of part or all of the page
tables and run the NOHZ_FULL tasks from those while they're in
userspace. Then, instead of flushing the TLB in the deferred work, you
switch over to the "real" page tables.

That would _behave_ like a CPU with a big TLB and really old, crusty TLB
entries from the last time the kernel ran.

BTW, the other option for all of this is just to say that if you want
IPI-free TLB flushing that you need to go buy some hardware with it as
opposed to all of this complexity.