Re: [PATCH 07/25] mm/fbatch: LRU_NEXT_ACTIVATE bit to optimize folio_activate()

[Hugh Dickins <hughd@google.com>]

On Thu, 27 Aug 2026, Kiryl Shutsemau wrote:
> On Mon, Aug 24, 2026 at 07:09:34AM -0700, Hugh Dickins wrote:
> > @@ -355,6 +356,8 @@ bool lru_add_del_folio(struct folio *folio)
> >  	/* BUG_ON(folio_test_lru(folio)); */
> >  	if (!(folio->lru_next & BIT(LRU_NEXT_BATCHED)))
> >  		return false;
> > +	if (folio->lru_next & BIT(LRU_NEXT_ACTIVATE))
> > +		folio_set_active(folio);
> >  	folio->lru.next = LIST_POISON1;
> >  	/* BUG_ON(folio->lru_next & BIT(LRU_NEXT_BATCHED)); */
> >  	return true;
> 
> folio_activate()'s try_cmpxchg() can land in between two lru_next reads.
> Logically, it is safe but I suspect KCSAN would not be happy about it.
> 
> Maybe READ_ONCE() here?

I expect you're right, and I or someone should add that in due course.

But I'm not in a hurry to do so: I did run KCSAN while testing before
posting, and amongst 770 KCSAN reports did see a few which looked
likely to come from these changes - yes, something in lru_activate(),
which would be the WRITE_ONCE() end of the READ_ONCE() you suggest.

I decided it was more urgent to get on with posting the series,
than take another pass working out where perhaps to add those:
needs a different mindset.

I'll grouchily get around to agreeing to add them: but I think
they hurt readability, and I'm surprised that KCSAN doe not object
to almost every line I've ever written - that's what we do throughout
the kernel, make racy unlocked choices to minimize overhead.

Do you have a head for smp_mb__ barriers? I'm more anxious that
I might be missing one or two of those.

> 
> Other note, page_pool (pp_magic) seems to be using bit 2, but I don't
> think there's a real conflict.

Yes, again not a problem, as with bit 1.

Hugh