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=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 D6668C433E0 for ; Tue, 12 Jan 2021 22:20:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 383E923127 for ; Tue, 12 Jan 2021 22:20:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 383E923127 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8B2046B00FC; Tue, 12 Jan 2021 17:20:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 861A66B00FE; Tue, 12 Jan 2021 17:20:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7789C6B00FF; Tue, 12 Jan 2021 17:20:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id 6346A6B00FC for ; Tue, 12 Jan 2021 17:20:52 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1C678181AEF23 for ; Tue, 12 Jan 2021 22:20:52 +0000 (UTC) X-FDA: 77698543944.29.twist24_411819127519 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id F2141180868DE for ; Tue, 12 Jan 2021 22:20:51 +0000 (UTC) X-HE-Tag: twist24_411819127519 X-Filterd-Recvd-Size: 5688 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 22:20:50 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id q22so251654eja.2 for ; Tue, 12 Jan 2021 14:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eTIoaNVkYWwgsEp9LMpgcyP45XmLf/k0fgDnsh1vc7Q=; b=OixaNP0KdqpjiYzt/2c0kRVvoc3YdMlU0G7M1jrAHP+WZLnsjLBn2HI2a4KD49XU8k QOksFhFZvPS61lNudfnotINI5/cED2AEfo/wlKhLUj45QyiV9pMKxNRMNo/5EuhDU4j8 EPbnWKZ/3CdJIIUTRFjW/ZcaC6of0+NgM8eBCYsOhdMFQdiDdlNFsUvrib8myhSkD5hh MswOsS5zCgxRwd2dIJPjTXvxwv7PmuV9u48+GD+XLG9Zc1m6IZNtxZFD3yickfaAsUgo dg/vxNFR2H+MEZuwdoll7yOfU8nPSmp4m9DB+yASQzXhOC5Hg8KcoG0rXJHqK/awpiL/ MN2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eTIoaNVkYWwgsEp9LMpgcyP45XmLf/k0fgDnsh1vc7Q=; b=rzqN+WGdzsBAW7s7dDc8IVPQNmHWSDr5ejtLukoJR1ue+sn68NHziPuNxEFvXOeebc aGs7ZeME4/Wkm9Z+pt/zFekVPx7zO7+7TFB9PwsnlKz36DON2ysIuCNkIxxtFQ2Q/Ssv vbR9nMcwNXAKc/Z0EPVBQybc/7txyGS+WnXGGXE4cas1rjH4whpEtvIySlGfd+qiMeL4 0H1qCkPiWZM4c79sATHCj8fFxJ7o1YfbIARttwUfueiirp9l8jueOWRdnT6Ah1Q4yPvo 3Cb2jut9Ye3bhAyNVS9JY+//LXmXKQlFhhVq99tQUNxKHZgKAvQEdMc7dhsKOpt/KrzH OiZw== X-Gm-Message-State: AOAM533/woqCKaeOk0oGbmFvxsMZ1r0OA7jr/Qqgc9XM12AdTM/ffbne LOCqSW11q3WNCLTUt0er6/9pkclSgmOL+a2R1SPliw== X-Google-Smtp-Source: ABdhPJw+Gi32iWw2zRGAmyQWdcoaZTNn+kztXT/ZCK7VAyrtTePrZuY+wMdQpD/H7tRkOKeEi/FfHmD3PDqzCNyOS5A= X-Received: by 2002:a17:906:a29a:: with SMTP id i26mr647229ejz.45.1610490049654; Tue, 12 Jan 2021 14:20:49 -0800 (PST) MIME-Version: 1.0 References: <161044407603.1482714.16630477578392768273.stgit@dwillia2-desk3.amr.corp.intel.com> <161044408728.1482714.9086710868634042303.stgit@dwillia2-desk3.amr.corp.intel.com> <0586c562-787c-4872-4132-18a49c3ffc8e@redhat.com> In-Reply-To: <0586c562-787c-4872-4132-18a49c3ffc8e@redhat.com> From: Dan Williams Date: Tue, 12 Jan 2021 14:20:40 -0800 Message-ID: Subject: Re: [PATCH v2 2/5] mm: Teach pfn_to_online_page() to consider subsection validity To: David Hildenbrand Cc: Linux MM , Qian Cai , Michal Hocko , Vishal L Verma , linux-nvdimm , Linux Kernel Mailing List , Anshuman Khandual Content-Type: text/plain; charset="UTF-8" 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, Jan 12, 2021 at 1:53 AM David Hildenbrand wrote: > > On 12.01.21 10:34, Dan Williams wrote: > > pfn_section_valid() determines pfn validity on subsection granularity. > > > > pfn_valid_within() internally uses pfn_section_valid(), but gates it > > with early_section() to preserve the traditional behavior of pfn_valid() > > before subsection support was added. > > > > pfn_to_online_page() wants the explicit precision that pfn_valid() does > > not offer, so use pfn_section_valid() directly. Since > > pfn_to_online_page() already open codes the validity of the section > > number vs NR_MEM_SECTIONS, there's not much value to using > > pfn_valid_within(), just use pfn_section_valid(). This loses the > > valid_section() check that pfn_valid_within() was performing, but that > > was already redundant with the online check. > > > > Fixes: b13bc35193d9 ("mm/hotplug: invalid PFNs from pfn_to_online_page()") > > Cc: Qian Cai > > Cc: Michal Hocko > > Reported-by: David Hildenbrand > > --- > > mm/memory_hotplug.c | 16 ++++++++++++---- > > 1 file changed, 12 insertions(+), 4 deletions(-) > > > > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > > index 55a69d4396e7..a845b3979bc0 100644 > > --- a/mm/memory_hotplug.c > > +++ b/mm/memory_hotplug.c > > @@ -308,11 +308,19 @@ static int check_hotplug_memory_addressable(unsigned long pfn, > > struct page *pfn_to_online_page(unsigned long pfn) > > { > > unsigned long nr = pfn_to_section_nr(pfn); > > + struct mem_section *ms; > > + > > + if (nr >= NR_MEM_SECTIONS) > > + return NULL; > > + > > + ms = __nr_to_section(nr); > > + if (!online_section(ms)) > > + return NULL; > > + > > + if (!pfn_section_valid(ms, pfn)) > > + return NULL; > > That's not sufficient for alternative implementations of pfn_valid(). > > You still need some kind of pfn_valid(pfn) for alternative versions of > pfn_valid(). Consider arm64 memory holes in the memmap. See their > current (yet to be fixed/reworked) pfn_valid() implementation. > (pfn_valid_within() is implicitly active on arm64) > > Actually, I think we should add something like the following, to make > this clearer (pfn_valid_within() is confusing) > > #ifdef CONFIG_HAVE_ARCH_PFN_VALID > /* We might have to check for holes inside the memmap. */ > if (!pfn_valid()) > return NULL; > #endif Looks good to me, I'll take Oscar's version that uses IS_ENABLED(). Skipping the call to pfn_valid() saves 16-bytes of code text on x86_64.