Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp2839564pxb; Mon, 18 Apr 2022 09:17:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoIqV2EWfCSdPxSQGqipczg/Cp3EkD/bZUCCeiKp+ukm1ShjX+B+OW2c8Qz7h+EcyPoYVc X-Received: by 2002:a17:907:961f:b0:6db:c8f3:dc72 with SMTP id gb31-20020a170907961f00b006dbc8f3dc72mr9689976ejc.92.1650298675267; Mon, 18 Apr 2022 09:17:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650298675; cv=none; d=google.com; s=arc-20160816; b=Yl3kDm+77owE3zhL/OIZorzUvyk3kr4vlYnkf6krrMZDKtPu2GwfBk5k9tGAYZWBzE N52955/mH9ytohX9RDbn9G8b1jf/MxhvVX8XtdlAzSAaWztw0NI51hB/Kf17k7wnLthr Qqk0whjbrOfhloe7uf3KpZZm6zr3qDBnke16YJx97XRrHK2VMDuEXdIE+CBILuIfuiC1 cYunXgcAwJU/P3GGjCihAY7SzLxsIy/d2FuYGCXNUkyvAwffENxYa/Zqs4oLCFM5Qg4l gJRppsd1b4DdY69q2KvA8gw+lDHeHtwVFuf1aJ3UfoPQI5IS8X/oY62hkqrUdbe8Cbdr iWcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=dXd0j0IpC7+QKZlyhWe4EARIK9yR7jQl715LYnWl0E8=; b=K04wJYBItEYFpsp/KLY5UPtRYqfZYVeWhMVzBWUVow/AN0UX1N/nYEXfpvDC9em9fX kXUbkGmfme0uM5wouWtPrlLNJgR2YrnkaaSaGO0e3fl/NL1gFUA5KO2q/55ixf2cy5dA 1md3lqMcjYfQ/qRqvwqZCFyucjdOSrPmTu8vThVbYn8pHUqTOGqMl86lHN2vDe2XsK5k ULv7jnwNWQ2nIl6aipmgMcT6IzSh4LeBz06bDAPCfqNNNGHNEum8XaBjWqQitfTYSS1V ltxsUGQLbs8HG7a1LPPsQfideSjFZrm4HcicH5TRZHwVcUqVqq9izzyYCqdPUEWWdQ2R vfdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Wduep64I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i7-20020a170906264700b006e89c06638bsi6794279ejc.492.2022.04.18.09.17.29; Mon, 18 Apr 2022 09:17:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=Wduep64I; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245275AbiDROGp (ORCPT + 99 others); Mon, 18 Apr 2022 10:06:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243822AbiDRNt2 (ORCPT ); Mon, 18 Apr 2022 09:49:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1070833E9B; Mon, 18 Apr 2022 06:01:32 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 7D20860B71; Mon, 18 Apr 2022 13:01:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B93BC385A7; Mon, 18 Apr 2022 13:01:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1650286891; bh=B233ZbEmtQGrhBpokOcxFigC/8UDYIojH37NgqQyG0k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Wduep64I0oXJR2S86GmTbQ3vGVh0Hl6WmTmVe/BFYps0Vh3qJtB9hUs2ggsI3cRzb jqIy1O47iswbu4kRNBFNAc6mYYNbJUyOxoN+a8oIOeDsKxWu49avUDz62Voy3oSHJh AL4RxH6Cegxqxy8ZXBG00s4Qw2tpTrW7MYlcxdao= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Juergen Gross , =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= , Michal Hocko , David Hildenbrand , Wei Yang , Andrew Morton , Linus Torvalds Subject: [PATCH 4.14 278/284] mm, page_alloc: fix build_zonerefs_node() Date: Mon, 18 Apr 2022 14:14:19 +0200 Message-Id: <20220418121221.000615347@linuxfoundation.org> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20220418121210.689577360@linuxfoundation.org> References: <20220418121210.689577360@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Juergen Gross commit e553f62f10d93551eb883eca227ac54d1a4fad84 upstream. Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") only zones with free memory are included in a built zonelist. This is problematic when e.g. all memory of a zone has been ballooned out when zonelists are being rebuilt. The decision whether to rebuild the zonelists when onlining new memory is done based on populated_zone() returning 0 for the zone the memory will be added to. The new zone is added to the zonelists only, if it has free memory pages (managed_zone() returns a non-zero value) after the memory has been onlined. This implies, that onlining memory will always free the added pages to the allocator immediately, but this is not true in all cases: when e.g. running as a Xen guest the onlined new memory will be added only to the ballooned memory list, it will be freed only when the guest is being ballooned up afterwards. Another problem with using managed_zone() for the decision whether a zone is being added to the zonelists is, that a zone with all memory used will in fact be removed from all zonelists in case the zonelists happen to be rebuilt. Use populated_zone() when building a zonelist as it has been done before that commit. There was a report that QubesOS (based on Xen) is hitting this problem. Xen has switched to use the zone device functionality in kernel 5.9 and QubesOS wants to use memory hotplugging for guests in order to be able to start a guest with minimal memory and expand it as needed. This was the report leading to the patch. Link: https://lkml.kernel.org/r/20220407120637.9035-1-jgross@suse.com Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") Signed-off-by: Juergen Gross Reported-by: Marek Marczykowski-Górecki Acked-by: Michal Hocko Acked-by: David Hildenbrand Cc: Marek Marczykowski-Górecki Reviewed-by: Wei Yang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman --- mm/page_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -4879,7 +4879,7 @@ static int build_zonerefs_node(pg_data_t do { zone_type--; zone = pgdat->node_zones + zone_type; - if (managed_zone(zone)) { + if (populated_zone(zone)) { zoneref_set_zone(zone, &zonerefs[nr_zones++]); check_highest_zone(zone_type); }