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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,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 6B526C433DB for ; Tue, 2 Feb 2021 12:33:45 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id ED4F564E27 for ; Tue, 2 Feb 2021 12:33:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ED4F564E27 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=xMktSNdyMsNCkvP2Zh1GaAH4kLNCy0GhtcMzI2k/RFE=; b=RsgrWtuvbkdklEO9sdQWZpVMH HUtOpGeKipnjCo4UVCRvMzRZkCTK+jzak5uYAYJF94wfhvtxqYIN9MDJVjRZ9O8nccsoeUS+uxuhc 4TeM7Rx/ZW1Vm0oMt8Rmhe64fZHe8MMU7S2kkyIWCpf7xMaLTT6uxlQ4IOOFpG9q2eZ96LJkifZrk 40HH4ewI5is4lopcOPlhAPhktPIaHmU23Ngkni9iWxU7d7kfRGvbBXM4aBwFJsjlfQcEqgoDiMDEi tjwRiEJXyevWKGXpxgcMlV1V1oNHuVsMUjvskCfAOl5Q9YS1mt/xjAj6SE109Kg0yVDC25/ZLzOea SwqjBLWYQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6ur4-0001lh-1v; Tue, 02 Feb 2021 12:32:26 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l6ur1-0001kx-E3 for linux-arm-kernel@lists.infradead.org; Tue, 02 Feb 2021 12:32:24 +0000 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 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-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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210202_073223_552459_1C2C9860 X-CRM114-Status: GOOD ( 17.68 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , David Hildenbrand , Catalin Marinas , linux-kernel@vger.kernel.org, Mike Rapoport , linux-mm@kvack.org, =?iso-8859-1?B?Suly9G1l?= Glisse , James Morse , Dan Williams , Robin Murphy , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org 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, 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel