Re: [PATCH 5/6] mm: page_alloc: fix freelist movement during block conversion

[Johannes Weiner]

On Wed, Sep 13, 2023 at 09:52:17PM +0200, Vlastimil Babka wrote:
> On 9/11/23 21:41, Johannes Weiner wrote:
> > @@ -1638,26 +1629,62 @@ static int move_freepages(struct zone *zone,
> >  	return pages_moved;
> >  }
> >  
> > -int move_freepages_block(struct zone *zone, struct page *page,
> > -				int migratetype, int *num_movable)
> > +static bool prep_move_freepages_block(struct zone *zone, struct page *page,
> > +				      unsigned long *start_pfn,
> > +				      unsigned long *end_pfn,
> > +				      int *num_free, int *num_movable)
> >  {
> > -	unsigned long start_pfn, end_pfn, pfn;
> > -
> > -	if (num_movable)
> > -		*num_movable = 0;
> > +	unsigned long pfn, start, end;
> >  
> >  	pfn = page_to_pfn(page);
> > -	start_pfn = pageblock_start_pfn(pfn);
> > -	end_pfn = pageblock_end_pfn(pfn) - 1;
> > +	start = pageblock_start_pfn(pfn);
> > +	end = pageblock_end_pfn(pfn) - 1;
> 
> >  	/* Do not cross zone boundaries */
> > -	if (!zone_spans_pfn(zone, start_pfn))
> > -		start_pfn = zone->zone_start_pfn;
> > -	if (!zone_spans_pfn(zone, end_pfn))
> > -		return 0;
> > +	if (!zone_spans_pfn(zone, start))
> > +		start = zone->zone_start_pfn;
> > +	if (!zone_spans_pfn(zone, end))
> > +		return false;
> 
> This brings me back to my previous suggestion - if we update the end, won't
> the whole "block straddles >1 zones" situation to check for go away?
> 
> Hm or is it actually done because we have a problem by representing
> pageblock migratetype with multiple zones, since there's a single
> pageblock_bitmap entry per the respective pageblock range of pfn's, so one
> zone's migratetype could mess with other's? And now it matters if we want
> 100% match of freelist vs pageblock migratetype?

Yes, it's not safe to change a shared bitmap entry with only one of
the two zones locked.

So I think my range adjustment isn't a complete fix. It's okay for the
case I was directly encountering, where DMA starts with pfn 1 and pfn
0 belongs to nobody. But if the block straddles two genuine zones, a
race is possible.

> (I think even before this series it could have mattered for
> MIGRATETYPE_ISOLATE, is it broken in those corner cases?)

Yes, I think this is buggy indeed.

start_isolate_page_range() calls isolate_single_pageblock() on block
boundaries. It actually does round up to the zone start if the pfn is
below it, since b2c9e2fbba32 ("mm: make alloc_contig_range work at
pageblock granularity") from Zi last year. But it will still set the
migratetype on a straddling block.

And I don't see any handling for the end of the block being in another
zone. It won't move free pages due to the above, but it appears to set
the isolate migratetype in an unlocked zone.

Since nobody has complained about this, I wonder if blocks truly
straddling two different zones isn't just rare but actually
non-existent. The DMA and DMA32 boundaries should naturally align to
multiples of the pageblock order, but there might be exceptions with
ZONE_MOVABLE. Maybe somebody remembers situations where this occurs?

> But in that case we might not be detecting the situation properly for the
> later of the two zones in a pageblock, because if start_pfn is not spanned
> we adjust it and continue? Hmm...

I think what needs to happen is return false in both cases and reject
operation on blocks whose pages are in two different zones. None of
the callers expect it, and don't hold both zone locks that would be
necessary to safely move pages and adjust the migratetype.

This would fix the isolate race, as well as the freelist race that
this series is trying to eliminate.

It would mean that a straddling block can still be stolen from during
fallback, but cannot be claimed entirely and will stay MOVABLE.

It's not perfect, but certainly sounds a lot more reasonable than a
double zone locking scheme for all callers.