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;
Message-ID: <87f171f1-c44b-5103-f9e5-20a6b5c257dd@intel.com>
Date:   Tue, 1 Feb 2022 09:40:06 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Content-Language: en-US
To:     ira.weiny@intel.com, Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Dan Williams <dan.j.williams@intel.com>
Cc:     Fenghua Yu <fenghua.yu@intel.com>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        linux-kernel@vger.kernel.org
References: <20220127175505.851391-1-ira.weiny@intel.com>
 <20220127175505.851391-17-ira.weiny@intel.com>
From:   Dave Hansen <dave.hansen@intel.com>
Subject: Re: [PATCH V8 16/44] mm/pkeys: Introduce pks_mk_readwrite()
In-Reply-To: <20220127175505.851391-17-ira.weiny@intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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()

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

	pks_set_key_readwrite()