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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 D58DAC433E0 for ; Tue, 2 Feb 2021 12:32:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 44C3864F49 for ; Tue, 2 Feb 2021 12:32:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 44C3864F49 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A96186B0072; Tue, 2 Feb 2021 07:32:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A44ED6B0073; Tue, 2 Feb 2021 07:32:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90E4E6B0074; Tue, 2 Feb 2021 07:32:23 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id 7AF0E6B0072 for ; Tue, 2 Feb 2021 07:32:23 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 41DBD8249980 for ; Tue, 2 Feb 2021 12:32:23 +0000 (UTC) X-FDA: 77773265766.17.bean56_360fb0f275ca Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 2822E180D0180 for ; Tue, 2 Feb 2021 12:32:23 +0000 (UTC) X-HE-Tag: bean56_360fb0f275ca X-Filterd-Recvd-Size: 4116 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf38.hostedemail.com (Postfix) with ESMTP for ; Tue, 2 Feb 2021 12:32:22 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 78F6264E27; Tue, 2 Feb 2021 12:32:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1612269141; bh=CCjPtrOe2z7rwX8Ik4iHxMcLMZzQg3xF3GCxJVyvafQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U/vmCypYEGCPJOifz8Z6dnFhNAYTdIG3vLzXViuo5lNvBGxQ0GDKN1/vKi98IPUbP KasrUJ9k4YCxQqKVnFwVmUtWlvhQkbJgQ5GO58WZU+jQ3GdnuJKZTorTZmYl791/1K Q7TZsXcLMeUIfjc7lT5lkbXOUHK/c5Vz9tdvn3Yyrzk87mhfYHAqnTdx5DCSB9hTGF b4IM0MoYNzBF6APnf6TKWZG9i78VQ1ji6US8999JPJ4D8L8V4O4Nyd0hH2WofhuqyN oB7N9PFwnLryHYgNwNsCFEZudg/N1mMEmtU6rldLiO5qSUwfMcXfNHgWc2Oj0QmLOM a7DtbvsXoKylQ== Date: Tue, 2 Feb 2021 12:32:16 +0000 From: Will Deacon To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Catalin Marinas , Ard Biesheuvel , Mark Rutland , James Morse , Robin Murphy , =?iso-8859-1?B?Suly9G1l?= Glisse , Dan Williams , David Hildenbrand , Mike Rapoport Subject: Re: [PATCH V2 1/2] arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory Message-ID: <20210202123215.GA16868@willie-the-truck> References: <1612239114-28428-1-git-send-email-anshuman.khandual@arm.com> <1612239114-28428-2-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1612239114-28428-2-git-send-email-anshuman.khandual@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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, Feb 02, 2021 at 09:41:53AM +0530, Anshuman Khandual wrote: > pfn_valid() validates a pfn but basically it checks for a valid struct page > backing for that pfn. It should always return positive for memory ranges > backed with struct page mapping. But currently pfn_valid() fails for all > ZONE_DEVICE based memory types even though they have struct page mapping. > > pfn_valid() asserts that there is a memblock entry for a given pfn without > MEMBLOCK_NOMAP flag being set. The problem with ZONE_DEVICE based memory is > that they do not have memblock entries. Hence memblock_is_map_memory() will > invariably fail via memblock_search() for a ZONE_DEVICE based address. This > eventually fails pfn_valid() which is wrong. memblock_is_map_memory() needs > to be skipped for such memory ranges. As ZONE_DEVICE memory gets hotplugged > into the system via memremap_pages() called from a driver, their respective > memory sections will not have SECTION_IS_EARLY set. > > Normal hotplug memory will never have MEMBLOCK_NOMAP set in their memblock > regions. Because the flag MEMBLOCK_NOMAP was specifically designed and set > for firmware reserved memory regions. memblock_is_map_memory() can just be > skipped as its always going to be positive and that will be an optimization > for the normal hotplug memory. Like ZONE_DEVICE based memory, all normal > hotplugged memory too will not have SECTION_IS_EARLY set for their sections > > Skipping memblock_is_map_memory() for all non early memory sections would > fix pfn_valid() problem for ZONE_DEVICE based memory and also improve its > performance for normal hotplug memory as well. Hmm. Although I follow your logic, this does seem to rely on an awful lot of assumptions to continue to hold true as the kernel evolves. In particular, how do we ensure that early sections are always fully backed with 'struct page's and never contain any nomap entries? What's to stop somebody changing that and quietly breaking our pfn_valid() implementation? And to be clear, I'm not trying to say that this patch is broken. I'm just trying to work out how on Earth we can maintain it! Will