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=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable 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 2A7F7C433E9 for ; Mon, 8 Mar 2021 08:39:54 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 A8E9E651C3 for ; Mon, 8 Mar 2021 08:39:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A8E9E651C3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com 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=desiato.20200630; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:Cc:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=kqjHmbEsHlir+TSEvmmp9PyotLLweXEjswH4muYAFFc=; b=O6+LQe7XVm7aBb5piYXi9iBUr 2SOtNFhlLw7PVwYeU8hF/eVJbF+/h3mAF1GF0UAyReEbMEd/1V4Z8/D0iH+0dwM+mRSkSJP79M4Bu xHTxt5D6Pmp0d6+sTpyUokRGN7YuBEozqEYNs2v+025pai5NzdN5RAmugnxdeONavVPsWESvC8a9C 2htYPDIKP4+40BNLWEnaQECndgvCFCKIkqoFe/Vc23yZ2BmtujnJAULkvBAavQhqiW07jN3xUY7ri 9SjzdozW4fehncFmCpmArCcgMJCPf5ZSfdxbgx/2KlP3bKotV/86JiASyyj7SbPxMykd8zAnxj5hm cwwF5TR/Q==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lJBP4-00FyGN-7g; Mon, 08 Mar 2021 08:38:14 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJBP0-00FyFy-P8 for linux-arm-kernel@desiato.infradead.org; Mon, 08 Mar 2021 08:38:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Subject:From:References:Cc:To:Sender :Reply-To:Content-ID:Content-Description; bh=VSeZk3InN/9j9fIXKRvmBsyCrTSCQ5Gd7zaa1tggq28=; b=sr/6WwBaS+LGKgRP34Qj9nt56a Ttlke7iJeyjjoN4d4rH3d5cCkzv6ac82SW1JJy4Ut4Wfuf1Mp5PiAMfxLlBP8QN86SpuI5mj2pThS lg1Sw6lD5AGbyDHxtfQS4V838d+HUq8a/wZbwbACSF5P2NABlHnCMmgVstrxmF7sbr4AeDYag21uy DSs40IR6dv5yp2VrKPErK2zV6SK9g5gozp5wAWjqF3kU0/8erPa4PFwyZn4h0UUQZTAgJ89Amvo89 nSVuAdzqfCbDD5y5IwLkBMgl4XNZt3ceXBB8HmXywlfzyjW+nKAK1mCYQNjLuzNejUF+cmSNtmoOs GewsZ9CQ==; Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by casper.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lJBOX-00FEV0-QQ for linux-arm-kernel@lists.infradead.org; Mon, 08 Mar 2021 08:38:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615192650; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VSeZk3InN/9j9fIXKRvmBsyCrTSCQ5Gd7zaa1tggq28=; b=XPzXBWTAHjr/TSQKldfa6lsFTt0WbvLNleQbYz7Chf/pUsSVwGEGuKKopGLi84Kq1y1MAU Gy9iKtH4F9Ly254UtM54qGCTUA2Gl9Nz6AuEvv7VqYNvgvi8zYEoLy7tPIJtWUq8KZQEXS RLwbLvaIOtYcVNyYBBl9ik7v94Us/2I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615192653; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=VSeZk3InN/9j9fIXKRvmBsyCrTSCQ5Gd7zaa1tggq28=; b=dsUdjHkOhS8fSWJEDOiEK3M9/mFuZVOsuBLtb9j0o/nR9bY3IOH95GWHyBV/5DmhB+qWZg /Wjb0c57cVzb0iX7oKtgijZ05Zh5abUtr29bBlqIzkBNtllVpnyjz5ICnWvXpPrA8YCRhr ApgkhcpCypj/Ra6w5Ns7fJggnVCnB9A= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-150-pNJuItIwPwCPGRE46QMh_g-1; Mon, 08 Mar 2021 03:37:25 -0500 X-MC-Unique: pNJuItIwPwCPGRE46QMh_g-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 3FF3E804333; Mon, 8 Mar 2021 08:37:24 +0000 (UTC) Received: from [10.36.113.123] (ovpn-113-123.ams2.redhat.com [10.36.113.123]) by smtp.corp.redhat.com (Postfix) with ESMTP id C94C861F2B; Mon, 8 Mar 2021 08:37:21 +0000 (UTC) To: Anshuman Khandual , linux-mm@kvack.org Cc: Russell King , Catalin Marinas , Will Deacon , Andrew Morton , Mike Rapoport , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <1615174073-10520-1-git-send-email-anshuman.khandual@arm.com> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [RFC] mm: Enable generic pfn_valid() to handle early sections with memmap holes Message-ID: <745496f5-e099-8780-e42e-f347b55e8476@redhat.com> Date: Mon, 8 Mar 2021 09:37:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <1615174073-10520-1-git-send-email-anshuman.khandual@arm.com> Content-Language: en-US X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210308_083748_037785_05B46582 X-CRM114-Status: GOOD ( 38.07 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 08.03.21 04:27, Anshuman Khandual wrote: > Platforms like arm and arm64 have redefined pfn_valid() because their early > memory sections might have contained memmap holes caused by memblock areas > tagged with MEMBLOCK_NOMAP, which should be skipped while validating a pfn > for struct page backing. This scenario could be captured with a new option > CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES and then generic pfn_valid() can be > improved to accommodate such platforms. This reduces overall code footprint > and also improves maintainability. > > Commit 4f5b0c178996 ("arm, arm64: move free_unused_memmap() to generic mm") > had used CONFIG_HAVE_ARCH_PFN_VALID to gate free_unused_memmap(), which in > turn had expanded its scope to new platforms like arc and m68k. Rather lets > restrict back the scope for free_unused_memmap() to arm and arm64 platforms > using this new config option i.e CONFIG_HAVE_EARLY_SECTION_MEMMAP. > > While here, it exports the symbol memblock_is_map_memory() to build drivers > that depend on pfn_valid() but does not have the required visibility. After > this new config is in place, just drop CONFIG_HAVE_ARCH_PFN_VALID from both > arm and arm64 platforms. > > Cc: Russell King > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Andrew Morton > Cc: Mike Rapoport > Cc: David Hildenbrand > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Cc: linux-mm@kvack.org > Suggested-by: David Hildenbrand > Signed-off-by: Anshuman Khandual > --- > This applies on 5.12-rc2 along with arm64 pfn_valid() fix patches [1] and > has been lightly tested on the arm64 platform. The idea to represent this > unique situation on the arm and arm64 platforms with a config option was > proposed by David H during an earlier discussion [2]. This still does not > build on arm platform due to pfn_valid() resolution errors. Nonetheless > wanted to get some early feedback whether the overall approach here, is > acceptable or not. It might make sense to keep the arm variant for now. The arm64 variant is where the magic happens and where we missed updates when working on the generic variant. The generic variant really only applies to 64bit targets where we have SPARSEMEM. See x86 as an example. [...] > /* > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > index 47946cec7584..93532994113f 100644 > --- a/include/linux/mmzone.h > +++ b/include/linux/mmzone.h > @@ -1409,8 +1409,23 @@ static inline int pfn_section_valid(struct mem_section *ms, unsigned long pfn) > } > #endif > > +bool memblock_is_map_memory(phys_addr_t addr); > + > #ifndef CONFIG_HAVE_ARCH_PFN_VALID > static inline int pfn_valid(unsigned long pfn) > +{ > + phys_addr_t addr = PFN_PHYS(pfn); > + > + /* > + * Ensure the upper PAGE_SHIFT bits are clear in the > + * pfn. Else it might lead to false positives when > + * some of the upper bits are set, but the lower bits > + * match a valid pfn. > + */ > + if (PHYS_PFN(addr) != pfn) > + return 0; I think this should be fine for other archs as well. > + > +#ifdef CONFIG_SPARSEMEM Why do we need the ifdef now? If that's to cover the arm case, then please consider the arm64 case only for now. > { > struct mem_section *ms; > > @@ -1423,7 +1438,14 @@ static inline int pfn_valid(unsigned long pfn) > * Traditionally early sections always returned pfn_valid() for > * the entire section-sized span. > */ > - return early_section(ms) || pfn_section_valid(ms, pfn); > + if (early_section(ms)) > + return IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) ? > + memblock_is_map_memory(pfn << PAGE_SHIFT) : 1; > + > + return pfn_section_valid(ms, pfn); > +} > +#endif > + return 1; > } > #endif > > diff --git a/mm/Kconfig b/mm/Kconfig > index 24c045b24b95..0ec20f661b3f 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -135,6 +135,16 @@ config HAVE_FAST_GUP > config ARCH_KEEP_MEMBLOCK > bool > > +config HAVE_EARLY_SECTION_MEMMAP_HOLES > + depends on ARCH_KEEP_MEMBLOCK && SPARSEMEM_VMEMMAP > + def_bool n > + help > + Early sections on certain platforms might have portions which are > + not backed with struct page mapping as their memblock entries are > + marked with MEMBLOCK_NOMAP. When subscribed, this option enables > + specific handling for those memory sections in certain situations > + such as pfn_valid(). > + > # Keep arch NUMA mapping infrastructure post-init. > config NUMA_KEEP_MEMINFO > bool > diff --git a/mm/memblock.c b/mm/memblock.c > index afaefa8fc6ab..d9fa2e62ab7a 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1744,6 +1744,7 @@ bool __init_memblock memblock_is_map_memory(phys_addr_t addr) > return false; > return !memblock_is_nomap(&memblock.memory.regions[i]); > } > +EXPORT_SYMBOL(memblock_is_map_memory); > > int __init_memblock memblock_search_pfn_nid(unsigned long pfn, > unsigned long *start_pfn, unsigned long *end_pfn) > @@ -1926,7 +1927,7 @@ static void __init free_unused_memmap(void) > unsigned long start, end, prev_end = 0; > int i; > > - if (!IS_ENABLED(CONFIG_HAVE_ARCH_PFN_VALID) || > + if (!IS_ENABLED(CONFIG_HAVE_EARLY_SECTION_MEMMAP_HOLES) || > IS_ENABLED(CONFIG_SPARSEMEM_VMEMMAP)) > return; > > With commit 1f90a3477df3ff1a91e064af554cdc887c8f9e5e Author: Dan Williams Date: Thu Feb 25 17:17:05 2021 -0800 mm: teach pfn_to_online_page() about ZONE_DEVICE section collisions (still in -next I think) You'll also have to take care of pfn_to_online_page(). -- Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel