Re: Race condition in build_all_zonelists() when offlining movable zone

From: Mel Gorman <mgorman@suse.de>
To: David Hildenbrand <david@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>,
	Patrick Daly <quic_pdaly@quicinc.com>,
	linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
	Juergen Gross <jgross@suse.com>
Subject: Re: Race condition in build_all_zonelists() when offlining movable zone
Date: Tue, 23 Aug 2022 12:09:46 +0100	[thread overview]
Message-ID: <20220823110946.o3eawk3kghaykcim@suse.de> (raw)
In-Reply-To: <0fc01e47-51f3-baf7-2d46-72291422f695@redhat.com>

On Tue, Aug 23, 2022 at 12:34:09PM +0200, David Hildenbrand wrote:
> > @@ -6553,7 +6576,7 @@ static void __build_all_zonelists(void *data)
> >  #endif
> >  	}
> >  
> > -	spin_unlock(&lock);
> > +	write_sequnlock(&zonelist_update_seq);
> >  }
> >  
> >  static noinline void __init
> > 
> 
> LGTM. The "retry_cpuset" label might deserve a better name now.
> 

Good point ...  "restart"?

> Would
> 
> Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones
> with pages managed by the buddy allocator")
> 
> be correct?
> 

Not specifically because the bug is due to a zone being completely removed
resulting in a rebuild. This race probably existed ever since memory
hotremove could theoritically remove a complete zone. A Cc: Stable would
be appropriate as it'll apply with fuzz back to at least 5.4.210 but beyond
that, it should be driven by a specific bug report showing that hot-remove
of a full zone was possible and triggered the race.

-- 
Mel Gorman
SUSE Labs

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel