On Fri, 7 Feb 2025 at 21:25, Rik van Riel <riel@xxxxxxxxxxx> wrote: > > On Fri, 2025-02-07 at 15:50 +0100, Brendan Jackman wrote: > > On Thu, 6 Feb 2025 at 05:45, Rik van Riel <riel@xxxxxxxxxxx> wrote: > > > @@ -1276,7 +1282,7 @@ void arch_tlbbatch_flush(struct > > > arch_tlbflush_unmap_batch *batch) > > > > > > int cpu = get_cpu(); > > > > > > - info = get_flush_tlb_info(NULL, 0, TLB_FLUSH_ALL, 0, false, > > > + info = get_flush_tlb_info(NULL, 0, TLB_FLUSH_ALL, > > > PAGE_SHIFT, false, > > > TLB_GENERATION_INVALID); > > > > [Why] do we need this change? If it's necessary here, why isn't it > > needed everywhere else that does TLB_FLUSH_ALL too, like > > flush_tlb_mm()? > > > flush_tlb_mm() calls flush_tlb_mm_range(), which > does also use get_flush_tlb_info(). > > We pass in PAGE_SHIFT here to ensure that the > stride shift is specified correctly to the > INVLPGB instruction later on. Hm I don't follow your answer here so lemme just state my current understanding more verbosely... flush_tlb_mm() indirectly calls get_flush_tlb_info() with end=TLB_FLUSH_ALL and stride_shift=0. That's an invalid stride shift, but this doesn't break anything because with TLB_FLUSH_ALL the stride shift is never used (except to check for values above PMD_SHIFT). So here I think passing stride_shift=0 would be fine too. Concretely, here we specifically call invlpgb_flush_all_nonglobals() which doesn't care about stride_shift, and flush_tlb_func() is the same as before this patchset in this respect. I would be quite happy with removing the "it's invalid but it doesn't matter" thing everywhere but this seems to be localised and I think the issue is orthogonal to the presence of invlpgb.
