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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 208EAC32772 for ; Tue, 23 Aug 2022 13:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=oUqcIzOCBmyNF5VcgtKM85DltSvqRWqwmBVkpFgxVjk=; b=h4GogKJKLA9Y7t hE/svYbBpxggiWSITZkzm5fO91mCrri5KWByRyWg56xkvJA4k4tsSOAr70q+33t04wTGzCCR7+w4k kdu41mmFEZyeqDjfZ67sDnxnI4RrrhD2cqq1RaCEOl1+zFI4u1vEaWandpuPPorGRgPppg0uG0P0r 0Uxs534L3LynKazCFYHjtz80djQrH86r8CZ5Bv4qLFvK3gDGQNb9sM35cJFbzhZcZPgATDZaBUYPD J7nmPSNm4sda1BoI3vYkbxbvVeVuhqiihNpFBMXjn7LDio/cnWrWtjoWlUy0W2GBL6AA9SmNw+R8J jf8aPpKKsY5RjJZsgKIw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oQTuD-006IfH-VW; Tue, 23 Aug 2022 13:25:22 +0000 Received: from smtp-out2.suse.de ([195.135.220.29]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oQTu2-006Id4-3V for linux-arm-kernel@lists.infradead.org; Tue, 23 Aug 2022 13:25:19 +0000 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 410E81F9DB; Tue, 23 Aug 2022 13:25:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661261106; 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=cv1hO3HEeqRXpJ1nSdv79Mae3J8Pqj+075YHW6P/5Vs=; b=f/lZp2FsfU37gpmFr0dXPtBTg8y7N1kU3eCDJGIPfLmCKd0vaMPcHXRG8zCbO3X8Mmla/x RusmA2oHio2IshDj4IlY4heMSMvh64L6aYCDgB7N4rfCO4bNw1GVjiLc/5SBG+RZYmEH1u XELPc5N9iEQffYRaTKi0AqQJZsfN4Ew= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 2FA5213A89; Tue, 23 Aug 2022 13:25:06 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id KnGYCzLVBGObYgAAMHmgww (envelope-from ); Tue, 23 Aug 2022 13:25:06 +0000 Date: Tue, 23 Aug 2022 15:25:05 +0200 From: Michal Hocko To: Mel Gorman Cc: David Hildenbrand , 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: References: <20220817104028.uin7cmkb4qlpgfbi@suse.de> <11f91089-1958-c7eb-126f-af32130d9f8a@redhat.com> <20220823083349.5c2aolc6xgfhp3k7@suse.de> <20220823094950.ocjyur2h3mqnqbeg@suse.de> <0fc01e47-51f3-baf7-2d46-72291422f695@redhat.com> <20220823110946.o3eawk3kghaykcim@suse.de> <20220823125850.o3nhkmikmv7vyxq4@suse.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220823125850.o3nhkmikmv7vyxq4@suse.de> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220823_062518_724844_04E5495C X-CRM114-Status: GOOD ( 25.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue 23-08-22 13:58:50, Mel Gorman wrote: > On Tue, Aug 23, 2022 at 02:18:27PM +0200, Michal Hocko wrote: > > On Tue 23-08-22 12:09:46, Mel Gorman wrote: > > > 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. > > > > I do not think so. 6aa303defb74 has changed the zonelist building and > > changed the check from pfn range (populated) to managed (with a memory). > > I'm not 100% convinced. The present_pages should have been the spanned range > minus any holes that exist in the zone. If the zone is completely removed, > the span should be zero meaning present and managed are both zero. No? IIRC, and David will correct me if I am mixing this up. The difference is that zonelists are rebuilt during memory offlining and that is when managed pages are removed from the allocator. Zone itself still has that physical range populated and so this patch would have made a difference. Now, you are right that this is likely possible even without that commit but it is highly unlikely because physical hotremove is a very rare operation and the race window would be so large that it would be likely unfeasible. -- Michal Hocko SUSE Labs _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel