Re: [PATCH v3] mm/page_alloc: Fix pcp->count race between drain_pages_zone() vs __rmqueue_pcplist()

[Vlastimil Babka <vbabka@suse.cz>]

On 7/23/24 8:44 AM, Li Zhijian wrote:
> It's expected that no page should be left in pcp_list after calling
> zone_pcp_disable() in offline_pages(). Previously, it's observed that
> offline_pages() gets stuck [1] due to some pages remaining in pcp_list.
> 
> Cause:
> There is a race condition between drain_pages_zone() and __rmqueue_pcplist()
> involving the pcp->count variable. See below scenario:
> 
>          CPU0                              CPU1
>     ----------------                    ---------------
>                                       spin_lock(&pcp->lock);
>                                       __rmqueue_pcplist() {
> zone_pcp_disable() {
>                                         /* list is empty */
>                                         if (list_empty(list)) {
>                                           /* add pages to pcp_list */
>                                           alloced = rmqueue_bulk()
>   mutex_lock(&pcp_batch_high_lock)
>   ...
>   __drain_all_pages() {
>     drain_pages_zone() {
>       /* read pcp->count, it's 0 here */
>       count = READ_ONCE(pcp->count)
>       /* 0 means nothing to drain */
>                                           /* update pcp->count */
>                                           pcp->count += alloced << order;
>       ...
>                                       ...
>                                       spin_unlock(&pcp->lock);
> 
> In this case, after calling zone_pcp_disable() though, there are still some
> pages in pcp_list. And these pages in pcp_list are neither movable nor
> isolated, offline_pages() gets stuck as a result.
> 
> Solution:
> Expand the scope of the pcp->lock to also protect pcp->count in
> drain_pages_zone(), to ensure no pages are left in the pcp list after
> zone_pcp_disable()
> 
> [1] https://lore.kernel.org/linux-mm/6a07125f-e720-404c-b2f9-e55f3f166e85@fujitsu.com/
> 
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> Reported-by: Yao Xingtao <yaoxt.fnst@fujitsu.com>
> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>

Fixes: 4b23a68f9536 ("mm/page_alloc: protect PCP lists with a spinlock")
I'd also add a Cc: stable in this case

Reviewed-by: Vlastimil Babka <vbabka@suse.cz>

Thanks!

> ---
> V3:
>     Read pcp->count in the loop with lock held to prevent unnecessary spin_lock() wasteful
> V2:
>     - Narrow down the scope of the spin_lock() to limit the draining latency. # Vlastimil and David
>     - In above scenario, it's sufficient to read pcp->count once with lock held, and it fully fixed
>       my issue[1] in thounds runs(It happened in more than 5% before).
> RFC:
>     https://lore.kernel.org/linux-mm/20240716073929.843277-1-lizhijian@fujitsu.com/
> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
> ---
>  mm/page_alloc.c | 18 +++++++++++-------
>  1 file changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 9ecf99190ea2..a32289ec4768 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -2323,16 +2323,20 @@ void drain_zone_pages(struct zone *zone, struct per_cpu_pages *pcp)
>  static void drain_pages_zone(unsigned int cpu, struct zone *zone)
>  {
>  	struct per_cpu_pages *pcp = per_cpu_ptr(zone->per_cpu_pageset, cpu);
> -	int count = READ_ONCE(pcp->count);
> -
> -	while (count) {
> -		int to_drain = min(count, pcp->batch << CONFIG_PCP_BATCH_SCALE_MAX);
> -		count -= to_drain;
> +	int count;
>  
> +	do {
>  		spin_lock(&pcp->lock);
> -		free_pcppages_bulk(zone, to_drain, pcp, 0);
> +		count = pcp->count;
> +		if (count) {
> +			int to_drain = min(count,
> +				pcp->batch << CONFIG_PCP_BATCH_SCALE_MAX);
> +
> +			free_pcppages_bulk(zone, to_drain, pcp, 0);
> +			count -= to_drain;
> +		}
>  		spin_unlock(&pcp->lock);
> -	}
> +	} while (count);
>  }
>  
>  /*