Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp737371ybf; Sat, 29 Feb 2020 14:48:47 -0800 (PST) X-Google-Smtp-Source: APXvYqx5CxNPBYrumDs2jHUnA/xD1VJlu0Lyxwt6KoLVLa7uljsAd28xmFe/YArER5gFoBR8XMoA X-Received: by 2002:a05:6830:310a:: with SMTP id b10mr3944782ots.210.1583016527383; Sat, 29 Feb 2020 14:48:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583016527; cv=none; d=google.com; s=arc-20160816; b=0pLTuZ4Yxnhutna15r6m/xCf5Yh57BgtG25twUtsPUBYwjNkRU6Vphk16OJwAPBPul cwQOwjd6PLPu7RfAaPZk5uEQOGA3dRi/JX2c226RyK+elrrSWE1aSRTrFR12WwU5sFCX /MXwMcm1GgB/9oeNTTJDInaH57/Hf2jHNY61qArYAr8nKlft10W+2nEQQuGHHcfDCnfP 50sbcYFZxeG+Tn4daW2raGNuFYSibza1KDVfvtP3n7zP1PhAb+gnb1yO3yepuCEF1Iv1 pILKGJ8llI7GIi+v9JVTwImmfogZSRvCnlcqGC1oYPm411J2H1t+vXqQgHY+iUWgVOJ6 F16w== 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=7fImmI76PTkUm0FnhIT75xAfAmVx1VzhBKKsN9mVGyw=; b=AxconPP1Pk3KcA2RrnL+P6YzjdcCA5zii+82AQxLbs/XUYI7pnmgvciq+Tx+Hew0CH khMh06diEkl7pV3uddy+sN80tsxBJZELtyRaz8JUKqh5uv47SuyDiW7DYJemT+Ng/4Rf 7oC0xDZmyMN30CEwp6tC5tNnOGsVjHFCLb5GbKzQWgKf5sleYqmvwwGzMPq8kP+vLDR2 yP7A+zvT2NVA9KiTWG9InzwOXv22GtoWJN9MaG8QgK1rJbZCzb+tIF/gMXCRV8M/Ycqc S/fXmTiiArXuSkTjntS6K7FGpUTDpiEobzIZDgLvt1BFZJOWrSNg27ACUlbb7ZeFHos/ gHdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="CqI85+c/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id x79si4220682oif.180.2020.02.29.14.48.33; Sat, 29 Feb 2020 14:48:47 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b="CqI85+c/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1727468AbgB2Woc (ORCPT + 99 others); Sat, 29 Feb 2020 17:44:32 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38212 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727445AbgB2Wob (ORCPT ); Sat, 29 Feb 2020 17:44:31 -0500 Received: by mail-oi1-f193.google.com with SMTP id 2so6666779oiz.5 for ; Sat, 29 Feb 2020 14:44:30 -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=7fImmI76PTkUm0FnhIT75xAfAmVx1VzhBKKsN9mVGyw=; b=CqI85+c/yRtEkfdvKZhyimiv+7VpsWo116oMWIFfgpozuKdLs8C42nteZDsX5BGC18 YFA3FIVS39K+jrHV363NgaZbyyIgxeUDc50ebfZEV6Dg195VTUcmJ5ks4GK7LLMTfdRG eyz/jrExrPaaWO449Bs08Z5ZvCBAF8pQBclZvBaZdySo4pDGyePu6OJWj4OeXrvOl5KY ro66cJo/Qcj1ASkeP0uL8RRPE1gEVH5S6C3g2weZyNNFDalPOuYmVgtTK4js076KGUP1 sjl87SdTRjtqnsitz4qtdRmuFsvpmQAbp/SMu5PjS/fDvEIs6oFk7/24LGUbW+6A+6f/ UVDQ== 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=7fImmI76PTkUm0FnhIT75xAfAmVx1VzhBKKsN9mVGyw=; b=lHMZNY32CS3cvkjvElFD5DKy34W4wtfM8ObKU7SNlRN7dbtjK4LHxlOkvplst/H63i ZkD19gtZeDW7m0S/v7QiDfnwN589d3/AN5YSDB7UpnN74C8xBmmsf49Yda783ksqUAU5 DKU8Cgc7V70GWMH7FvsChiWCM8h7rhOL5hKrBCWn7Ex96Oh6FvFicJpt9ho/un8RNEst OtE/Xe3YYi4KDfVs0kD4A+7yiURUjLTn9hA29GncTfArrWKFH5PBKxhYkb8E8rCzCebY hstEpySuCCjpXdo1orBlUd6GR891JS/zX6LvtGWn9sMuR2FQDBgqcCx7lhk6TqGUA3iT fqxg== X-Gm-Message-State: APjAAAXkAHiD3EdaMc7F/hdmDW2a5zmktv+aUlhTV3una27oA2xPQRAa ZVQkoRdm2jx27WSgc/SAykLoVdDTyVo8pT7RK4YdSg== X-Received: by 2002:aca:ec02:: with SMTP id k2mr7594496oih.105.1583016270294; Sat, 29 Feb 2020 14:44:30 -0800 (PST) MIME-Version: 1.0 References: <20200221182503.28317-1-logang@deltatee.com> <20200221182503.28317-7-logang@deltatee.com> In-Reply-To: <20200221182503.28317-7-logang@deltatee.com> From: Dan Williams Date: Sat, 29 Feb 2020 14:44:19 -0800 Message-ID: Subject: Re: [PATCH v3 6/7] mm/memory_hotplug: Add pgprot_t to mhp_params To: Logan Gunthorpe Cc: Linux Kernel Mailing List , Linux ARM , linux-ia64@vger.kernel.org, linuxppc-dev , linux-s390 , Linux-sh , platform-driver-x86@vger.kernel.org, Linux MM , Michal Hocko , David Hildenbrand , Andrew Morton , Christoph Hellwig , Catalin Marinas , Will Deacon , Benjamin Herrenschmidt , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Eric Badger , Michal Hocko 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 Fri, Feb 21, 2020 at 10:25 AM Logan Gunthorpe wrote: > > devm_memremap_pages() is currently used by the PCI P2PDMA code to create > struct page mappings for IO memory. At present, these mappings are created > with PAGE_KERNEL which implies setting the PAT bits to be WB. However, on > x86, an mtrr register will typically override this and force the cache > type to be UC-. In the case firmware doesn't set this register it is > effectively WB and will typically result in a machine check exception > when it's accessed. > > Other arches are not currently likely to function correctly seeing they > don't have any MTRR registers to fall back on. > > To solve this, provide a way to specify the pgprot value explicitly to > arch_add_memory(). > > Of the arches that support MEMORY_HOTPLUG: x86_64, and arm64 need a simple > change to pass the pgprot_t down to their respective functions which set > up the page tables. For x86_32, set the page tables explicitly using > _set_memory_prot() (seeing they are already mapped). For ia64, s390 and > sh, reject anything but PAGE_KERNEL settings -- this should be fine, > for now, seeing these architectures don't support ZONE_DEVICE. > > A check in __add_pages() is also added to ensure the pgprot parameter was > set for all arches. > > Cc: Dan Williams > Signed-off-by: Logan Gunthorpe > Acked-by: David Hildenbrand > Acked-by: Michal Hocko > --- > arch/arm64/mm/mmu.c | 3 ++- > arch/ia64/mm/init.c | 3 +++ > arch/powerpc/mm/mem.c | 3 ++- > arch/s390/mm/init.c | 3 +++ > arch/sh/mm/init.c | 3 +++ > arch/x86/mm/init_32.c | 5 +++++ > arch/x86/mm/init_64.c | 2 +- > include/linux/memory_hotplug.h | 2 ++ > mm/memory_hotplug.c | 5 ++++- > mm/memremap.c | 6 +++--- > 10 files changed, 28 insertions(+), 7 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index ee37bca8aba8..ea3fa844a8a2 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -1058,7 +1058,8 @@ int arch_add_memory(int nid, u64 start, u64 size, > flags = NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS; > > __create_pgd_mapping(swapper_pg_dir, start, __phys_to_virt(start), > - size, PAGE_KERNEL, __pgd_pgtable_alloc, flags); > + size, params->pgprot, __pgd_pgtable_alloc, > + flags); > > memblock_clear_nomap(start, size); > > diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c > index 97bbc23ea1e3..d637b4ea3147 100644 > --- a/arch/ia64/mm/init.c > +++ b/arch/ia64/mm/init.c > @@ -676,6 +676,9 @@ int arch_add_memory(int nid, u64 start, u64 size, > unsigned long nr_pages = size >> PAGE_SHIFT; > int ret; > > + if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot)) > + return -EINVAL; > + > ret = __add_pages(nid, start_pfn, nr_pages, params); > if (ret) > printk("%s: Problem encountered in __add_pages() as ret=%d\n", > diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c > index 19b1da5d7eca..832412bc7fad 100644 > --- a/arch/powerpc/mm/mem.c > +++ b/arch/powerpc/mm/mem.c > @@ -138,7 +138,8 @@ int __ref arch_add_memory(int nid, u64 start, u64 size, > resize_hpt_for_hotplug(memblock_phys_mem_size()); > > start = (unsigned long)__va(start); > - rc = create_section_mapping(start, start + size, nid, PAGE_KERNEL); > + rc = create_section_mapping(start, start + size, nid, > + params->pgprot); > if (rc) { > pr_warn("Unable to create mapping for hot added memory 0x%llx..0x%llx: %d\n", > start, start + size, rc); > diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c > index e9e4a7abd0cc..87b2d024e75a 100644 > --- a/arch/s390/mm/init.c > +++ b/arch/s390/mm/init.c > @@ -277,6 +277,9 @@ int arch_add_memory(int nid, u64 start, u64 size, > if (WARN_ON_ONCE(params->altmap)) > return -EINVAL; > > + if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot)) > + return -EINVAL; > + > rc = vmem_add_mapping(start, size); > if (rc) > return rc; > diff --git a/arch/sh/mm/init.c b/arch/sh/mm/init.c > index e5114c053364..b9de2d4fa57e 100644 > --- a/arch/sh/mm/init.c > +++ b/arch/sh/mm/init.c > @@ -412,6 +412,9 @@ int arch_add_memory(int nid, u64 start, u64 size, > unsigned long nr_pages = size >> PAGE_SHIFT; > int ret; > > + if (WARN_ON_ONCE(params->pgprot.pgprot != PAGE_KERNEL.pgprot) > + return -EINVAL; > + > /* We only have ZONE_NORMAL, so this is easy.. */ > ret = __add_pages(nid, start_pfn, nr_pages, params); > if (unlikely(ret)) > diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c > index e25a4218e6ff..96d8e4fb1cc8 100644 > --- a/arch/x86/mm/init_32.c > +++ b/arch/x86/mm/init_32.c > @@ -858,6 +858,11 @@ int arch_add_memory(int nid, u64 start, u64 size, > { > unsigned long start_pfn = start >> PAGE_SHIFT; > unsigned long nr_pages = size >> PAGE_SHIFT; > + int ret; > + > + ret = _set_memory_prot(start, nr_pages, params->pgprot); Perhaps a comment since it's not immediately obvious where the PAGE_KERNEL prot was established, and perhaps add a conditional to skip this call in the param->pgprot == PAGE_KERNEL case? Other than that looks good to me, but only an ack since I'm only testing the x86 changes. Acked-by: Dan Williams