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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADFE0C433E0 for ; Wed, 6 Jan 2021 11:38:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A8AE23100 for ; Wed, 6 Jan 2021 11:38:07 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A8AE23100 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 57B548D0109; Wed, 6 Jan 2021 06:38:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 52AC78D0090; Wed, 6 Jan 2021 06:38:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F2558D0109; Wed, 6 Jan 2021 06:38:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id 259188D0090 for ; Wed, 6 Jan 2021 06:38:07 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E6631824556B for ; Wed, 6 Jan 2021 11:38:06 +0000 (UTC) X-FDA: 77675151372.20.dock00_2516e06274e1 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id C7BC9180C07A3 for ; Wed, 6 Jan 2021 11:38:06 +0000 (UTC) X-HE-Tag: dock00_2516e06274e1 X-Filterd-Recvd-Size: 3970 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Jan 2021 11:38:06 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1609933084; 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=v7Nwai2b36E4PhjVqMjGa8YBAPAahmnOcM2dSGchQYc=; b=f9M8+8NJbvL9i4aGj8NPFHBx549GQTh/WlzgJUZxSHClZvzf8cQDu4Ofc4+gaM2s7EBQMV DpyApGDOAtoNf0WC7+z1ljZt3O5w8lHBt2PDNV1slYLbzFuFZ4JC7/AGeAq1u5847Mm2iy qaK2+UhBgMn31EM7qxH9bGz1SZ5G0QQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id BCDB2AA35; Wed, 6 Jan 2021 11:38:04 +0000 (UTC) Date: Wed, 6 Jan 2021 12:38:04 +0100 From: Michal Hocko To: David Hildenbrand Cc: Dan Williams , linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: Teach pfn_to_online_page() about ZONE_DEVICE section collisions Message-ID: <20210106113804.GL13207@dhcp22.suse.cz> References: <160990599013.2430134.11556277600719835946.stgit@dwillia2-desk3.amr.corp.intel.com> <785b9095-eca4-8100-33ea-6ae84e02a92e@redhat.com> <20210106104255.GK13207@dhcp22.suse.cz> <7d7c5dc4-7784-5dcc-fc00-4fe99f0a4a90@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d7c5dc4-7784-5dcc-fc00-4fe99f0a4a90@redhat.com> 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 Wed 06-01-21 12:22:57, David Hildenbrand wrote: > On 06.01.21 11:42, Michal Hocko wrote: > > On Wed 06-01-21 10:56:19, David Hildenbrand wrote: > > [...] > >> Note that this is not sufficient in the general case. I already > >> mentioned that we effectively override an already initialized memmap. > >> > >> --- > >> > >> [ SECTION ] > >> Before: > >> [ ZONE_NORMAL ][ Hole ] > >> > >> The hole has some node/zone (currently 0/0, discussions ongoing on how > >> to optimize that to e.g., ZONE_NORMAL in this example) and is > >> PG_reserved - looks like an ordinary memory hole. > >> > >> After memremap: > >> [ ZONE_NORMAL ][ ZONE_DEVICE ] > >> > >> The already initialized memmap was converted to ZONE_DEVICE. Your > >> slowpath will work. > >> > >> After memunmap (no poisioning): > >> [ ZONE_NORMAL ][ ZONE_DEVICE ] > >> > >> The slow path is no longer working. pfn_to_online_page() might return > >> something that is ZONE_DEVICE. > >> > >> After memunmap (poisioning): > >> [ ZONE_NORMAL ][ POISONED ] > >> > >> The slow path is no longer working. pfn_to_online_page() might return > >> something that will BUG_ON via page_to_nid() etc. > >> > >> --- > >> > >> Reason is that pfn_to_online_page() does no care about sub-sections. And > >> for now, it didn't had to. If there was an online section, it either was > >> > >> a) Completely present. The whole memmap is initialized to sane values. > >> b) Partially present. The whole memmap is initialized to sane values. > >> > >> memremap/memunmap messes with case b) > > > > I do not see we ever clear the newly added flag and my understanding is > > that the subsection removed would lead to get_dev_pagemap returning a > > NULL. Which would obviously need to be checked for pfn_to_online_page. > > Or do I miss anything and the above is not the case and we could still > > get false positives? > > See my example above ("After memunmap"). > > We're still in the slow pathg. pfn_to_online_page() will return a struct > page as get_dev_pagemap() is now NULL. Yeah, my bad. I have clearly misread the patch. We would need som other means than relying on get_dev_pagemap if it doesn't survive the memunmap. :/ -- Michal Hocko SUSE Labs