Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp1836188ybh; Thu, 23 Jul 2020 20:11:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwSXYgVxMsKTAZeC7zBs9IxIYb6F+g9LK85hxQJRkD5K4lfU8BmPrAFhculStWC2CT1583G X-Received: by 2002:a17:906:cc0e:: with SMTP id ml14mr7149560ejb.432.1595560297643; Thu, 23 Jul 2020 20:11:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595560297; cv=none; d=google.com; s=arc-20160816; b=FHNzY1QKmOogZk3ZoYiGDoo0DoSKULcXv/dvdnqd3G4ZczzMCwgrt/Y2JZ1ENDEbbi lQoDfsCXABbefwInYZvPUehlwue2QD4sQlHSHokcCWzNY4G8ni8k1KH4jK/gz9M6lqRT ReIhvJKlXWcEEBwVRCFR6+TswpU7C/XXw2484yoy947QIXF29JJay0UPl+YQ8Ke9B9f+ ue9km4k+0tFcNQnH/itr8hkBYHmSc3xrQ0zPcLRtK4wSNmAsuih4zdyvonOCYwo6UYpL wTWd77roNwvdyCEPq8KqDVf8L+wLU0DdCO8NTeCwGCdCg48JUX94TWrg0L3Jf4eplm2I +hfQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=S6HzG9JVhpYkS6XU1q2Ri7kI6VPeM5Q4rQxCDAQWz8k=; b=LpoF5ssaWvlGQ3NWXxw3MdS11UMrX9QsVJqAIkRquvQyHCQEKzg8ANePiYGNRslKQD tEpCMF6qGo90giCFg8N2pdt11jYaNCSFmntv1KOzrvskrI+xmA4+PSY3374oQzFoh/dF 0eTaFawiKUnT579U0/iVNtYyk0dlDHw1j0mImudGhgCfKSD5Fs7lE7UGScQ88bmiEryu Bdere6NmzQlvyjVsXWiHXj63G4fEbkFYDZCuH6WUpX1oVHw11oaQbirNCgUfWvEF3iHZ RUlVqHlzuxEV8qKP2UIvksgxulW+J4s5ouJ1XK/z73jk+kZ38OVgKm0b9kK1SWLVGxZ2 FYNg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=BePtWmcW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ly20si3115099ejb.607.2020.07.23.20.11.15; Thu, 23 Jul 2020 20:11:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=BePtWmcW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726607AbgGXDIs (ORCPT + 99 others); Thu, 23 Jul 2020 23:08:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:42484 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726178AbgGXDIr (ORCPT ); Thu, 23 Jul 2020 23:08:47 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id F134B20786; Fri, 24 Jul 2020 03:08:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595560127; bh=Mi81Uejk0h0q25VxMgNb+0huSyrbkp+jl5hwFhOM7Z0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=BePtWmcWENl9v0Un95gA1NkIlo1AIrn4iCnulq4SWSlp3W7wd0wplS/5Z8Du5wfTv 4Bq8wsbGQI1eLG0tcA+Y8Bt0VjyZzx19HW5H1UcFQekAoV76WwecT7n0i6aA+R7Pgq zMavmYb/bTO5zXpkM/5oaHTftWqqiqK88KfPBDmU= Date: Thu, 23 Jul 2020 20:08:46 -0700 From: Andrew Morton To: Wei Yang Cc: David Hildenbrand , Wei Yang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Michal Hocko , stable@vger.kernel.org, Johannes Weiner , Minchan Kim , Huang Ying , Mel Gorman , Dan Williams Subject: Re: [PATCH v2 1/3] mm/shuffle: don't move pages between zones and don't read garbage memmaps Message-Id: <20200723200846.768513d7c122ac11b6e73538@linux-foundation.org> In-Reply-To: <20200623093018.GA6069@L-31X9LVDL-1304.local> References: <20200619125923.22602-2-david@redhat.com> <20200622082635.GA93552@L-31X9LVDL-1304.local> <2185539f-b210-5d3f-5da2-a497b354eebb@redhat.com> <20200622092221.GA96699@L-31X9LVDL-1304.local> <34f36733-805e-cc61-38da-2ee578ae096c@redhat.com> <20200622131003.GA98415@L-31X9LVDL-1304.local> <0f4edc1f-1ce2-95b4-5866-5c4888db7c65@redhat.com> <20200622215520.wa6gjr2hplurwy57@master> <4b7ee49c-9bee-a905-3497-e3addd8896b8@redhat.com> <20200623093018.GA6069@L-31X9LVDL-1304.local> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 23 Jun 2020 17:30:18 +0800 Wei Yang wrote: > On Tue, Jun 23, 2020 at 09:55:43AM +0200, David Hildenbrand wrote: > >On 23.06.20 09:39, David Hildenbrand wrote: > >>> Hmm.. I thought this is the behavior for early section, while it looks current > >>> code doesn't work like this: > >>> > >>> if (section_is_early && memmap) > >>> free_map_bootmem(memmap); > >>> else > >>> depopulate_section_memmap(pfn, nr_pages, altmap); > >>> > >>> section_is_early is always "true" for early section, while memmap is not-NULL > >>> only when sub-section map is empty. > >>> > >>> If my understanding is correct, when we remove a sub-section in early section, > >>> the code would call depopulate_section_memmap(), which in turn free related > >>> memmap. By removing the memmap, the return value from pfn_to_online_page() is > >>> not a valid one. > >> > >> I think you're right, and pfn_valid() would also return true, as it is > >> an early section. This looks broken. > >> > >>> > >>> Maybe we want to write the code like this: > >>> > >>> if (section_is_early) > >>> if (memmap) > >>> free_map_bootmem(memmap); > >>> else > >>> depopulate_section_memmap(pfn, nr_pages, altmap); > >>> > >> > >> I guess that should be the way to go > >> > >> @Dan, I think what Wei proposes here is correct, right? Or how does it > >> work in the VMEMMAP case with early sections? > >> > > > >Especially, if you would re-hot-add, section_activate() would assume > >there is a memmap, it must not be removed. > > > > You are right here. I didn't notice it. > > >@Wei, can you send a patch? > > > > Sure, let me prepare for it. Still awaiting this, and the v3 patch was identical to this v2 patch. It's tagged for -stable, so there's some urgency. Should we just go ahead with the decently-tested v2?