From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09A32C00140 for ; Wed, 24 Aug 2022 09:45:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8407C6B0073; Wed, 24 Aug 2022 05:45:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F00A940007; Wed, 24 Aug 2022 05:45:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DE9C6B0075; Wed, 24 Aug 2022 05:45:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5A4696B0073 for ; Wed, 24 Aug 2022 05:45:16 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2016AC0261 for ; Wed, 24 Aug 2022 09:45:16 +0000 (UTC) X-FDA: 79834003032.09.95FBE4A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf12.hostedemail.com (Postfix) with ESMTP id 8810340002 for ; Wed, 24 Aug 2022 09:45:14 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 33FC234086; Wed, 24 Aug 2022 09:45:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1661334313; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eXGR3/jAJ7H/cJMbbrQMWgiSPkKQgZgPXx9TsmRcU4c=; b=sVTVWSI7o/QuZD+1JyzXl4ZjEG5mD6NFnF3zskp7kB9cznOEIW5HAO5H+7ptGcpLzdPbHe 3LbQHtj7E6EONxvB1c/ZKxzEKPebFZDnT5jS/gHYi/GlzTEgRt7t3rGLIe9ofO4BI6yvyo sOwvh+PCBD6k+naUhsOdS3m+AG523Jc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1661334313; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eXGR3/jAJ7H/cJMbbrQMWgiSPkKQgZgPXx9TsmRcU4c=; b=l7myvifIr0Q30JXNGO8UzIa1YkzX13jjV9G3JYrhXISNMdskr+unRRthXyCW7uEJ+iaE/E EJ0mNSKBMJxSbXCw== Received: from suse.de (unknown [10.163.43.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id CA2822C141; Wed, 24 Aug 2022 09:45:12 +0000 (UTC) Date: Wed, 24 Aug 2022 10:45:11 +0100 From: Mel Gorman To: David Hildenbrand Cc: Michal Hocko , Patrick Daly , linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Juergen Gross Subject: Re: Race condition in build_all_zonelists() when offlining movable zone Message-ID: <20220824094511.e6ygoure34mqqbiw@suse.de> References: <0fc01e47-51f3-baf7-2d46-72291422f695@redhat.com> <20220823110946.o3eawk3kghaykcim@suse.de> <20220823125850.o3nhkmikmv7vyxq4@suse.de> <37031749-ff57-2f90-5c90-f16473f31e37@redhat.com> <20220823151415.zorod7xtmoiu6wy3@suse.de> <23eda994-44bc-b05c-9e1b-e0095f7ca547@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <23eda994-44bc-b05c-9e1b-e0095f7ca547@redhat.com> ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=sVTVWSI7; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=l7myvifI; spf=pass (imf12.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661334314; a=rsa-sha256; cv=none; b=VdJac+EOm/FFtikw4+B/pTBApIsmlSnFqoOULUWTDPaJlgyYGwCFKBXcmNR1donWQzcfGo 5RM8OyMQ+ul00sq405pZuUWXagkJnskZcyG0vrjIqmmp1bGRaAIgE97HjCq5kf3xDdoBBa /Lz5GlZu2eaJ5w+eYZP100K86wECRTg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661334314; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eXGR3/jAJ7H/cJMbbrQMWgiSPkKQgZgPXx9TsmRcU4c=; b=5e4Os2pK3QE+kCAvGxFlK/+qP9Sn+rNR9b4sUidKfr1Lw5b4cU0QlMiVVQI/ivHYTBY0hQ DTX+LKSCrS8AIu9HEEk1ut2to/QwhAFV3qkdVFEsTYlKC6VRCugLawvBWe2WFg3PGqCHDH /0x6HZYepWsawll9stGJmBdofLXpX+g= Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.de header.s=susede2_rsa header.b=sVTVWSI7; dkim=pass header.d=suse.de header.s=susede2_ed25519 header.b=l7myvifI; spf=pass (imf12.hostedemail.com: domain of mgorman@suse.de designates 195.135.220.28 as permitted sender) smtp.mailfrom=mgorman@suse.de; dmarc=pass (policy=none) header.from=suse.de X-Rspam-User: X-Rspamd-Queue-Id: 8810340002 X-Rspamd-Server: rspam05 X-Stat-Signature: ztf4tm5ghk1njoo5kcr1uo8tu9e6sp4s X-HE-Tag: 1661334314-586483 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Aug 23, 2022 at 05:51:25PM +0200, David Hildenbrand wrote: > >> The race is simple -- page allocation could be in progress when a memory > >> hot-remove operation triggers a zonelist rebuild that removes zones. > >> The allocation request will still have a valid ac->preferred_zoneref that > >> is now pointing to NULL and triggers an OOM kill. > >> > >> This problem probably always existed but may be slighly easier to trigger > > s/slighly/slightly/ > Fixed. > >> due to 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones > >> with pages managed by the buddy allocator") which distinguishes between > >> zones that are completely unpopulated versus zones that have valid pages > >> but they are all reserved. Memory hotplug had multiple stages with > > Not necessarily reserved, simply not managed by the buddy (e.g., early > allocations, memory ballooning / virtio-mem). > Fair point, I filed all that under "reserved" but you're right, this is clearer. > >> +/* > >> + * Zonelists may change due to hotplug during allocation. Detect when zonelists > >> + * have been rebuilt so allocation retries. Reader side does not lock and > >> + * retries the allocation if zonelist changes. Writer side is protected by the > >> + * embedded spin_lock. > >> + */ > >> +DEFINE_SEQLOCK(zonelist_update_seq); > >> + > >> +static unsigned int zonelist_iter_begin(void) > >> +{ > > > > You likely want something like > > if (IS_ENABLED(CONFIG_MEMORY_HOTREMOVE)) > > return read_seqbegin(&zonelist_update_seq); > > return 0; > > > >> + return read_seqbegin(&zonelist_update_seq); > >> +} > >> + > >> +static unsigned int check_retry_zonelist(unsigned int seq) > >> +{ > > if (IS_ENABLED(CONFIG_MEMORY_HOTREMOVE)) > > return read_seqretry(&zonelist_update_seq, seq); > > return seq; > > > >> + return read_seqretry(&zonelist_update_seq, seq); > >> +} > >> + > > > > to avoid overhead on systems without HOTREMOVE configured. > > > > Other than that LGTM. > > Acked-by: Michal Hocko > It's a minor saving but fair enough. HOTREMOVE is now the only reason zonelists can be rebuilt. While that was not always true, if it ever changes again, it's a simple fix. Thanks Michal. > Makes sense to me, although I wonder how much it will matter in practice. > Probably none at all as it's one branch but it's still valid. > Reviewed-by: David Hildenbrand > Thanks David. -- Mel Gorman SUSE Labs