[PATCH v3 1/5] mm: rmap: support batched checks of the references for large folios
Matthew Wilcox
willy at infradead.org
Fri Dec 19 08:09:31 PST 2025
On Fri, Dec 19, 2025 at 10:47:52AM -0500, Liam R. Howlett wrote:
> > -#define ptep_clear_flush_young_notify(__vma, __address, __ptep) \
> > +#define ptep_clear_flush_young_notify(__vma, __address, __ptep, __nr) \
> > ({ \
> > int __young; \
> > struct vm_area_struct *___vma = __vma; \
> > unsigned long ___address = __address; \
> > - __young = ptep_clear_flush_young(___vma, ___address, __ptep); \
> > + unsigned int ___nr = __nr; \
> > + __young = clear_flush_young_ptes(___vma, ___address, __ptep, ___nr); \
> > __young |= mmu_notifier_clear_flush_young(___vma->vm_mm, \
> > ___address, \
> > ___address + \
> > - PAGE_SIZE); \
> > + nr * PAGE_SIZE); \
>
> Did you mean nr * PAGE_SIZE here? I think it should be __nr or ___nr?
> I think this nr variable works because it exists where this macro is
> expanded?
Yes, this should clearly be ___nr.
> I am also not sure why you have ___nr at all?
It's a macro cleanliness thing. Imagine that we have a caller:
a = ptep_clear_flush_young_notify(vma, addr, ptep, nr++);
If you have two references to the __nr macro argument, then you end up
incrementing nr twice. Assigning __nr to ___nr and then referring to
___nr within the macro prevents this.
That said, I'm not sure why ptep_clear_flush_young_notify() needs
to be a macro instead of a static inline?
More information about the linux-arm-kernel
mailing list