On Thu, Feb 06, 2025 at 09:48:25AM -0500, Rik van Riel wrote: > On Thu, 2025-02-06 at 15:23 +0100, Peter Zijlstra wrote: > > On Thu, Feb 06, 2025 at 09:16:35AM -0500, Rik van Riel wrote: > > > > > This can result in flush_tlb_mm_range being called > > > with a stride_shift for 2MB pages, but a range ending > > > on a 4kB aligned (not 2MB aligned) boundary. > > > > > > Peter, how should we solve this one? > > > > I don't think that's wrong per-se, since all we really need is for > > end > > to be past the end, one byte, one page, or one stride don't matter > > much. > > > > Anyway, I'm in desperate need of a break, so I'm not quite sure what > > the > > best way forward is. > > > Given that the tlb_flush() code is used only for > page table freeing, mmu_gather is used for both page and page-table freeing. > we can just round up the > end address to the nearest stride boundary > there, with a comment explaining why? Well, why are we rounding at all? I don't think I've seen an explanation for that anywhere yet. What made you do this? > Alternatively, we could just change the page > sizes used in pmd_free_tlb, pud_free_tlb, > and p4d_free_tlb, given that the functions > called now have parameters they didn't seem > to have back in 2014, when the linked email > in the comment was written? Well, it really shouldn't matter. Notably, stride is simply the smallest size encountered during the gather; not something that can be determined a priory. Like I said, end is exclusive, so it doesn't really matter how much further it is, and PAGE_SIZE is a natural enough step, seeing it is the smallest granularity. So start and end not being page aligned is a definite fail. And start should be stride aligned. But other than that, I don't see it matters much.
