Re: [PATCH v3 1/5] mm: rmap: support batched checks of the references for large folios

[Baolin Wang]

On 2025/12/20 00:09, Matthew Wilcox wrote:
> 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.

Ah, yes, my mistake. Thanks for pointing it out. Will fix.

> > 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.

Yes.

> That said, I'm not sure why ptep_clear_flush_young_notify() needs
> to be a macro instead of a static inline?

Lorenzo also mentioned this. I'll clean up these macros in a follow-up 
after this patchset. Thanks.