Re: [PATCH v2 0/5] x86/mm: Allow preemption while waiting for kernel TLB flushes

[Nadav Amit <nadav.amit@gmail.com>]

> On 5 Oct 2026, at 8:57, Chuyi Zhou <zhouchuyi@bytedance.com> wrote:
> 
> Changes in v2:
>  - Patch 2: Reuse flush_tlb_all() for kernel ranges promoted to a full
>    flush and remove kernel_tlb_flush_all() (Sebastian).
>  - Patch 4: Drop the explicit TLB_FLUSH_ALL check on the end argument.
>    Callers pass actual address ranges and can use flush_tlb_all() for
>    unconditional full flushes (Sebastian).

Chuyi,

It all looks nice and clean, but I am not sure the end result is that
great. I think that instead of consolidating different TLB flush paths,
you break them further apart. Then you try to copy the logic from
userspace TLB flushed into the kernel code (TLB flush counting and such).

I think that perhaps a better path would be to further consolidate the
two instead of separating them. There is functionality that is missing
from kernel-space TLB flushes, and might be needed in the future.

For instance, you can see userspace TLB-flushing has a mechanism to
prevent TLB shootdown storm using TLB generations; and you see it
supports TLB-flushing stride. Now, the shootdown storm might be less
of an issue (for now?) but stride support is something you may want
eventually to support range flush with stride for stuff like [1].

Nadav


[1] https://lore.kernel.org/all/20261005052302.43042-1-lance.yang@linux.dev/