Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 17 Feb 2022 20:39:46 -0800
From:   Ira Weiny <ira.weiny@intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Fenghua Yu <fenghua.yu@intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH V8 16/44] mm/pkeys: Introduce pks_mk_readwrite()
Message-ID: <Yg8jEltirmvzWOAs@iweiny-desk3>
References: <20220127175505.851391-1-ira.weiny@intel.com>
 <20220127175505.851391-17-ira.weiny@intel.com>
 <87f171f1-c44b-5103-f9e5-20a6b5c257dd@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87f171f1-c44b-5103-f9e5-20a6b5c257dd@intel.com>
Precedence: bulk

On Tue, Feb 01, 2022 at 09:40:06AM -0800, Dave Hansen wrote:
> On 1/27/22 09:54, ira.weiny@intel.com wrote:
> > +static inline void pks_mk_readwrite(int pkey)
> > +{
> > +	pks_update_protection(pkey, PKEY_READ_WRITE);
> > +}
> 
> I don't really like the "mk" terminology in here.  Maybe it's from
> dealing with the PTE helpers, but "mk" to me means that it won't do
> anything observable by itself.  We're also not starved for space here,
> and it's really odd to abbreviate "make->mk" but not do "readwrite->rw".
> 
> This really is going off and changing a register value.  I think:
> 
> 	pks_set_readwrite()

Ok  For completeness I'm changing the pgmap_mk_* calls to match; pgmap_set_*.

> 
> would be fine.  This starts to get a bit redundant, but looks fine too:
> 
> 	pks_set_key_readwrite()

Yes I think that is a bit to verbose.

I think pks_set_xxx() reads nicely.

Ira