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.