Re: [PATCH v2 27/47] mm/mmu_gather: fix flushing ranges with 4 GiB or larger

From: SJ Park

Date: Fri Oct 30 2026 - 19:58:00 EST


On Fri, 30 Oct 2026 12:19:46 +0100 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:

> On 10/30/26 12:15, David Hildenbrand (Arm) wrote:
> > On 10/30/26 01:57, SJ Park wrote:
> >> On Thu, 29 Oct 2026 21:33:22 +0100 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
> >>
> >>> From: Josef Bacik <josef@xxxxxxxxxxxxxx>
> >>>
> >>> __tlb_adjust_range() takes the size of the range which has to be flushed
> >>> as an unsigned int. Its callers, tlb_flush_{pte,pmd,pud,p4d}_range(), get
> >>> and pass an unsigned long. Consequently, a range that is 4 GiB or larger
> >>> gets truncated, possibly to 0.
> >>>
> >>> On arm64 with hugetlb, a 64k kernel can have 16 GiB hugetlb folios
> >>> mapped contiguously at the PMD level and flush them when unmapping, and a
> >>> 16k kernel can flush 64 GiB PUDs through tlb_unshare_pmd_ptdesc(). So
> >>> at least these two scenarios are affected.
> >>>
> >>> Fix it by flushing the proper range instead of the truncated one by
> >>> properly using "unsigned long" for range_size.
> >>
> >> Makes sense to me.
> >>
> >>>
> >>> Fix generated by an LLM and sent by Josef Bacik in private.
> >>>
> >>> Fixes: b528e4b6405b ("mm/hugetlb: add tlb_remove_hugetlb_entry for handling hugetlb pages")
> >>> Fixes: 8ce720d5bd91 ("mm/hugetlb: fix excessive IPI broadcasts when unsharing PMD tables using mmu_gather")
> >>> Cc: stable@xxxxxxxxxxxxxxx
> >>> Signed-off-by: Josef Bacik <josef@xxxxxxxxxxxxxx>
> >>> Acked-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> >>> [ david: use two-tab indent, simplify description ]
> >>
> >> It seems the convention [1] is to put the above modification note right before
> >> the last S-o-b: of David. Maybe you forgot moving it after adding R-b: and
> >> T-b: from great reviewers?
> >
> > It's "b4 trailers" that apparently messes this up. I don't think it really
> > matters (some move it above all trailers), but I'll fix this up when applying.
>
> Thinking again, I *think* this order is correct.
>
> People reviewed and tested with these changes.
>
> it would be something different if I modify a patch while applying it. Because
> then, what people reviewed and tested would be different to the original version.

Makes sense to me. Thank you for the kind clarification!


Thanks,
SJ

[...]