Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp1078442ybt; Wed, 8 Jul 2020 20:39:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJypmN53y5Z2GEUhNWERAT6stKN2wzAZ/BHXWtIBsj7/ds3B3nbjGmkF4EUcBEOHADRTW7AS X-Received: by 2002:a17:906:970a:: with SMTP id k10mr56466105ejx.236.1594265957449; Wed, 08 Jul 2020 20:39:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1594265957; cv=none; d=google.com; s=arc-20160816; b=yCvlGM7uNBuAK5pbr3telGZ7/hMiYfq2potZQq9VzaImL6arz318cd44sgjeWUPwnR GAssyLeKewsq9GGehsjBtOCIQF2ONGj1YUE6U+gpLcO7lDbwGzHyffWpvWPDloJTrys/ kpPlmPWrZWkFcXqy3V6XJI4GaJJitgxguYyYsAdS67gN9MhYaa/qXVoN6roxnuCKpy6w A2F/6al157Pf66J67hsnwwYmKTZo28wV1I/NEyGaHq1uS8Vo5B+uPw1M5R8E13QujE87 Y34AlpbLbRcfIS+cyMjxUExJq8C1ex+Ihsw/DFp45bljMKoh+Dw7rKJRuEX+CSFcf8SX N2zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=YtjuErNIKJPKt6mfJPuDEE1udY89MBwcN8YDulEHHpA=; b=cT4UKqFCpfj9xNcBs2nYqcoCSpfxkBsgGopPorJDviUIoGY8P61iLUIp+rf9ntWsDE Dv4hoRxhC/nt6/gbGK/Mm1k0e33RCTgcA3EFfGmOoXm5m89RJiake3gocRSWumJypzya zPieUVnolupoDy52P647waF6klhdqZcRJ5X+2led7HzSQtcqffbcsjnbL9OwWR2Gj/Ak +4ZxzSeO+graEIDLFTaK3vldq8j701RfhBaK1AEvcPV0qHvZJ4AOef8QPDvIJyLsOVTO x1x5Wk6mii+yJ0ekWhtyaAS4a01SdRYUQJ0HOQy9oCgzCQqfHRO1kWLKegQHcnNLxRjO eonQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=raobTJTp; 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 d14si1192794eds.574.2020.07.08.20.38.54; Wed, 08 Jul 2020 20:39:17 -0700 (PDT) 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=raobTJTp; 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 S1726261AbgGIDio (ORCPT + 99 others); Wed, 8 Jul 2020 23:38:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59282 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726122AbgGIDin (ORCPT ); Wed, 8 Jul 2020 23:38:43 -0400 Received: from mail-ed1-x544.google.com (mail-ed1-x544.google.com [IPv6:2a00:1450:4864:20::544]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9B2B7C08C5CE for ; Wed, 8 Jul 2020 20:38:42 -0700 (PDT) Received: by mail-ed1-x544.google.com with SMTP id g20so677599edm.4 for ; Wed, 08 Jul 2020 20:38:42 -0700 (PDT) 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=YtjuErNIKJPKt6mfJPuDEE1udY89MBwcN8YDulEHHpA=; b=raobTJTpMajWWh1DB67I4/ixIZuCT8w3vl86Q6iXHe8AqyCsaVIQnEjEhi3xpXUVSY 0sZ63uK1kh4Jq4GNjXjq1PXyhJBnXNVLrXeQybYWn7zcn8nuVxunI9SJNMAwua0zTL/6 N1PoXUBA2cUrSZwgk8tTruN0Pzjo+BpZWuk8YT47mWs7NxF6eN2RJOPiPqaA5CBkqCrA cWuPO9IW3sP/7mhUWgqHI7r2h3+L5G+GEZ+152hw2pOUVzrPYQCm4q8Mtc4j2RtD39xc 14zCSHFmqrXrZ7K1jR+L5WFLLufK7fsNNpNlnIegsjGENi2QENndj1DW7a2O57jMVMkS Kh8A== 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=YtjuErNIKJPKt6mfJPuDEE1udY89MBwcN8YDulEHHpA=; b=haF4e301TRqhPQx8zjVMRCG8Afv+tnsdIwjLn82+QHOh7eHbsNBH8jktYbDu2kURa4 p1PId4sfIUfH2DBTdE7TAqK+Vi0B4HNRpae6UuiwfsR5rJgZrXL8WQT2Yrmpxt0LjwnF WkbHskctGCfPjI5MF8szuWCwt8NHJBq1lRS3qrwI55C1XNqZirPDs7yYo4QEUalWarvn Ztu/HWcNqXOgzjJfIkEKNttXgvdYRNNCZcDaUpuzAsfMPmDIkNUOLPkMiqhTkhkfqLZJ uvHJAgQWJgNHa2Ip/wrenBM0G9qPNofS17tuBL/1P2X+9f7jE5CxOr30D1zPFGVXLWOl zAuA== X-Gm-Message-State: AOAM5334o7/Rg2eYF8oWwcYAX4mxFfbwJBlkhSYICJ6T7Q8xpv6wTVtf qb5UjWW09zUB3UpZYA8EIz+/3cJHCGuo++dtHFp3Ng== X-Received: by 2002:a05:6402:b79:: with SMTP id cb25mr49015887edb.154.1594265921222; Wed, 08 Jul 2020 20:38:41 -0700 (PDT) MIME-Version: 1.0 References: <20200709020629.91671-1-justin.he@arm.com> <20200709020629.91671-6-justin.he@arm.com> In-Reply-To: <20200709020629.91671-6-justin.he@arm.com> From: Dan Williams Date: Wed, 8 Jul 2020 20:38:30 -0700 Message-ID: Subject: Re: [PATCH v3 5/6] device-dax: use fallback nid when numa_node is invalid To: Jia He Cc: Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Yoshinori Sato , Rich Felker , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , David Hildenbrand , X86 ML , "H. Peter Anvin" , Vishal Verma , Dave Jiang , Andrew Morton , Baoquan He , Chuhong Yuan , Mike Rapoport , Logan Gunthorpe , Masahiro Yamada , Michal Hocko , Linux ARM , Linux Kernel Mailing List , linux-ia64@vger.kernel.org, Linux-sh , linux-nvdimm , Linux MM , Jonathan Cameron , Kaly Xin Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 8, 2020 at 7:07 PM Jia He wrote: > > numa_off is set unconditionally at the end of dummy_numa_init(), > even with a fake numa node. ACPI detects node id as NUMA_NO_NODE(-1) in > acpi_map_pxm_to_node() because it regards numa_off as turning off the numa > node. Hence dev_dax->target_node is NUMA_NO_NODE on arm64 with fake numa. > > Without this patch, pmem can't be probed as a RAM device on arm64 if SRAT table > isn't present: > $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g -a 64K > kmem dax0.0: rejecting DAX region [mem 0x240400000-0x2bfffffff] with invalid node: -1 > kmem: probe of dax0.0 failed with error -22 > > This fixes it by using fallback memory_add_physaddr_to_nid() as nid. > > Suggested-by: David Hildenbrand > Signed-off-by: Jia He > --- > drivers/dax/kmem.c | 21 +++++++++++++-------- > 1 file changed, 13 insertions(+), 8 deletions(-) > > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c > index 275aa5f87399..218f66057994 100644 > --- a/drivers/dax/kmem.c > +++ b/drivers/dax/kmem.c > @@ -31,22 +31,23 @@ int dev_dax_kmem_probe(struct device *dev) > int numa_node; > int rc; > > + /* Hotplug starting at the beginning of the next block: */ > + kmem_start = ALIGN(res->start, memory_block_size_bytes()); > + > /* > * Ensure good NUMA information for the persistent memory. > * Without this check, there is a risk that slow memory > * could be mixed in a node with faster memory, causing > - * unavoidable performance issues. > + * unavoidable performance issues. Furthermore, fallback node > + * id can be used when numa_node is invalid. > */ > numa_node = dev_dax->target_node; > if (numa_node < 0) { > - dev_warn(dev, "rejecting DAX region %pR with invalid node: %d\n", > - res, numa_node); > - return -EINVAL; > + numa_node = memory_add_physaddr_to_nid(kmem_start); I think this fixup belongs to the core to set a fallback value for dev_dax->target_node. I'm close to having patches to provide a functional phys_addr_to_target_node() for arm64.