Re: [RFC PATCH 1/5] mm/mlock: rework mlock_count to use _mapcount for order-0 folios

[Matthew Wilcox]

On Sun, Jun 18, 2023 at 06:57:44AM +0000, Yosry Ahmed wrote:
> @@ -337,6 +318,7 @@ struct folio {
>  			atomic_t _entire_mapcount;
>  			atomic_t _nr_pages_mapped;
>  			atomic_t _pincount;
> +			atomic_t _mlock_count;
>  #ifdef CONFIG_64BIT
>  			unsigned int _folio_nr_pages;
>  #endif

You can't quite do this.  On 32-bt systems (I know, I know ...),
we have:

offset	page 0		page 1
0	flags		flags
4	lru		head
8	lru		dtor+order
12	mapping		entire_mapcount
16	index		nr_pages_napped
20	private		pincount
24	mapcount
28	refcount

so it actually ends up overlapping page->mapcount on the second page,
which is of course used for counting the number of PTEs which map
that specific page.

I don't have a scenario where this would matter, but we are quite
careful to only allocate order-2+ large folios, so I'd suggest putting
it in page 2 instead of page 1.

I should probably add a comment to struct folio warning of this dragon.
I thought the #ifdef CONFIG_64BIT would be enough to warn unwary
passers-by of its presence, but a more explicit sign must be in order.