Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp34418pxb; Tue, 12 Jan 2021 19:11:22 -0800 (PST) X-Google-Smtp-Source: ABdhPJzzpilEHVT4P2FoTJMOdiWOkLmE2TZaYXNYRz6/tRWY54IdWSgus9uEjAhZv7nFLArfvcnt X-Received: by 2002:a17:906:6b88:: with SMTP id l8mr31226ejr.482.1610507481901; Tue, 12 Jan 2021 19:11:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610507481; cv=none; d=google.com; s=arc-20160816; b=Nd92wu7BfLTl3OipXdOg0AERRh47NZdmFdOAMvPJMXU6MHLTlyDJ3vggWEG+vs/317 EWriacPSpgXHqrt/l8VYKkF+FxaEvmG4bwxLZ93yiQxr20fYY1g3GohNQl++MKZivPCT mQHY5ckEAXiCEydo/uMkEEvrgLT+ZCjHAgqh2QgKJzgg7eFq8JoML0cWxu0OEZJRgjsw WhZsnJ1Ut8/pQv9ca9VD9XXy+dH1oNwDjUKk3LRzZ7aFjcoVMGtsp3IomN65Y00d77d1 LvCZ+mSs+wv3L5HyeUaqa2sMJ3Ed5KrHIEllkI8biMeRvzkC45dh0HkEe/k6bxSgKWTc AkCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=eTIoaNVkYWwgsEp9LMpgcyP45XmLf/k0fgDnsh1vc7Q=; b=Kj7//PVKJiFkzog9ahIsWRVevCKvs/Z+unTC5FTzQ+n0EVmdfpTazsW87yWT9zagrM hqafCe5NkeMjZD7irlhw1lWMB5c4jhM17A1MvpkBTDeVdwGmoQ3Vuu69t5xRX+BAkTmc hcYuOTA4TEXwHQOr4lYyyfe+pcEp9PXami0iWzgHzGddQFlJaQEi4ldzSnnTjMlld4Sd vVmWMEpZz3iF883tBiETkim+c/9ml/r/lHI9HfmMBUzqM5Ktj6yhu0BEZxFq6dDhhz8l s8T9EpkyVO4GdsQNpgMV/5iSI2wQb2UzXzdMBlUX4WvHgPPQZU+nI42L4WnJs2EL05X0 G/zQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=OixaNP0K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id a15si312871edm.287.2021.01.12.19.10.58; Tue, 12 Jan 2021 19:11:21 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=OixaNP0K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404869AbhALWVk (ORCPT + 99 others); Tue, 12 Jan 2021 17:21:40 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2404847AbhALWVb (ORCPT ); Tue, 12 Jan 2021 17:21:31 -0500 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC3A4C06179F for ; Tue, 12 Jan 2021 14:20:50 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id ga15so237730ejb.4 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=nfZkrBQxIeXDzRAGamAri2AwdZO3BD5Fc/XhTbQDNdMkHeZ3tUbHeZX5TGJHliEE+e /3lmVSJunJHXRo7bMAL9Lca59BEE0Tcb3tYJqTS9fVfEMGz8PWRn16cRE8R57s324e0E fDvqyyWSeCUJvEmr6HpYVugHwqfove0D14Y3ZPk7xKrhOzN+bRX9ap8BiG9NRKiGEnPg vhltexu+KVSNALqwvjRUsz6Eeet3IiH69AJqXDWDtD7U87TqNQd3E2idU2qw/LQQLKhl 6vXJbxSW9AUon7c1QoOns9q/lucm6a5H+VUN1IyNRMN8Vrk7zSr5fWf9fY6SG0iM2kgH HPig== X-Gm-Message-State: AOAM533HrGZVPwTRvIqhKWO5MDt3z/+BaCy7OQG4reqJD6ZCx2hJalC+ UAOJ3dDWG29aDxXJqh171qXrPcZDWCifWcXf4oxIgg== 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" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.