Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp730273ybf; Sat, 29 Feb 2020 14:34:40 -0800 (PST) X-Google-Smtp-Source: APXvYqwpvzxDRFZjbzGS4dxjH1OrH43/fzYAb0DY0xhWaEJ1G+/a6pg+U9UH/30JjUJYbGf85zub X-Received: by 2002:a9d:1921:: with SMTP id j33mr7767815ota.96.1583015680107; Sat, 29 Feb 2020 14:34:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583015680; cv=none; d=google.com; s=arc-20160816; b=yNWp0NNOHsIY8UWNwIaRVD2ZBtCra8wBXx1WKlaLKmGk2wpiOUFF+4GYoAu/VM3vBJ bxgXzA9bgg7DkNDwGv0r3rF0Ww4cwxsKxJ1/Jln7joCdLZ94Qw9iJpGJSQ224WOxUj7D AawgL7dLvsuUPkbUCXjetPu68n5/NJ+rSn/1XpwNGPanJrSLbtiziAqwC2uYtgrEmSe6 GbQsVfYJFnFPIHUhN8XtJAk/w0DoJrN2eZ2b/wrHdNoJoxBfLxlOVdiDHANyK0Srz6WH m5//W2RdpYzHelGOwUHI++8SfGE7kuamczH0/z6x2fBno3y5AJGIsHD105KVkQ8BcqVX d02Q== 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=0+qFmqhcgb7jhEPbeVLEVdCHOr+If3XHxdqQ1tb+5pc=; b=NFsTfmzissA7BVZH+X0UwVNT1DvFiUebRRfwBqL2rAPrAXU16zHe5S9NNOtxRs77gI vmT5hE5Y5Zane5QGu5b2CsgcW1y5gYlXE8C+00mfijkZhXpqbrCodjYv49HOkb8JVkFP v3hjSMC2C09g25iwDopirv0FU2meEbhXHgkoq5y98jqFSQ0Tb/+rVR0S5lTEub5O02Ia PZxofGmleKxbF5BsehSzXzcgPA7ergucwmL0mkB/JeFvwQTSU8+6PErbgchjiSKaFbEo NcwHPdMJdeEK3l8pDQ0/YsSljJ33uSNVb1HXCwGnEGwsRtQB2EncQW9piXSyxIMsC0vW wwuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=MJlh0jh6; 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 a12si3739537oie.87.2020.02.29.14.34.27; Sat, 29 Feb 2020 14:34:40 -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=MJlh0jh6; 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 S1727322AbgB2WdU (ORCPT + 99 others); Sat, 29 Feb 2020 17:33:20 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:38991 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727244AbgB2WdU (ORCPT ); Sat, 29 Feb 2020 17:33:20 -0500 Received: by mail-oi1-f193.google.com with SMTP id r16so6621586oie.6 for ; Sat, 29 Feb 2020 14:33:20 -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=0+qFmqhcgb7jhEPbeVLEVdCHOr+If3XHxdqQ1tb+5pc=; b=MJlh0jh6fKGmlMf8QKHfSMGKxkzGHEeUxIKuMK576jnOzp5ajBbWFd723+Nwz5sX5o kd5kFB1Qa4nMK4C2Quz1EtosMFhbFGty2TrTrSeM0926YL1M9TjPuncmtlZef3BqKcKO 0QMDkTU7/GfTsJIR/w5n5LoqIVS0h8Ha+vMH2bvx31vmcGio+VmcVwwkaawh8iuK3FDK B8oJ2LCRKfwY4UJPa+Ufg0yoRxTMpdzcD2JzNOx//OiTA4E21r9KhphDTjUvXXJpa4mN qph+2qengVBm0C0Rc0eQp7M69RV9q8SQixDZKId1V2L1G6rpoNj9Qc0++zW1EeGd/ZTO X0Mw== 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=0+qFmqhcgb7jhEPbeVLEVdCHOr+If3XHxdqQ1tb+5pc=; b=sdlqW5phjzxF66vGDi/16y4nb8s1p5WKp2ofO4LQ+KyybVpAlCk1cCHmhseofm2I3V etPEzUQdXV36b6k6oPW+e5ZRC/3ip7E08AJLMgt4w23RiDHt2Ex//lcY4m47jjdEENr9 wJxbKXJOniz71skht3GDgJmDu1r62g5l4CcSXcZpI+e5OrGND3Ffp6qOAW8ag4VnHHsV BIeqXHL5hh9y+s8E/zVszr0+wOjWtPjw9rHbHouFXnO8J8BmprlnVBNHGLTIkc/XOVL9 0slvlmRYdJopriEsH5ECGeBxwDGu4IFL2+WRMxKXual1TghCpCB/7bUluUtKBANsK6WM N7lw== X-Gm-Message-State: APjAAAV0/9F75FssVVfh60/o1aY9vLWtpz/NyGts4UOzsCZ3Av/DL4bF UcvNaZ+yZOdONUcTeEpc/keIIum3HRzS4mmi3jcWBg== X-Received: by 2002:a54:4791:: with SMTP id o17mr6946593oic.70.1583015599612; Sat, 29 Feb 2020 14:33:19 -0800 (PST) MIME-Version: 1.0 References: <20200221182503.28317-1-logang@deltatee.com> <20200221182503.28317-5-logang@deltatee.com> In-Reply-To: <20200221182503.28317-5-logang@deltatee.com> From: Dan Williams Date: Sat, 29 Feb 2020 14:33:08 -0800 Message-ID: Subject: Re: [PATCH v3 4/7] x86/mm: Introduce _set_memory_prot() 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 , "H. Peter Anvin" , X86 ML 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: > > For use in the 32bit arch_add_memory() to set the pgprot type of the > memory to add. > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > Cc: x86@kernel.org > Cc: Dave Hansen > Cc: Andy Lutomirski > Cc: Peter Zijlstra > Signed-off-by: Logan Gunthorpe > --- > arch/x86/include/asm/set_memory.h | 1 + > arch/x86/mm/pat/set_memory.c | 7 +++++++ > 2 files changed, 8 insertions(+) > > diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h > index 64c3dce374e5..0aca959cf9a4 100644 > --- a/arch/x86/include/asm/set_memory.h > +++ b/arch/x86/include/asm/set_memory.h > @@ -34,6 +34,7 @@ > * The caller is required to take care of these. > */ > > +int _set_memory_prot(unsigned long addr, int numpages, pgprot_t prot); I wonder if this should be separated from the naming convention of the other routines because this is only an internal helper for code paths where the prot was established by an upper layer. For example, I expect that the kernel does not want new usages to make the mistake of calling: _set_memory_prot(..., pgprot_writecombine(pgprot)) ...instead of _set_memory_wc() I'm thinking just a double underscore rename (__set_memory_prot) and a kerneldoc comment for that pointing people to use the direct _set_memory_ helpers. With that you can add: Reviewed-by: Dan Williams