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: <54dff33c-c289-23a8-cb02-d608e93b6ca2@redhat.com>
Date:   Fri, 7 Jul 2023 08:48:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH] x86: Remove the arch_calc_vm_prot_bits() macro from the
 uapi
To:     Dave Hansen <dave.hansen@intel.com>, Arnd Bergmann <arnd@arndb.de>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>
Cc:     x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
        Nicolas Schier <nicolas@fjasle.eu>,
        Masahiro Yamada <masahiroy@kernel.org>,
        linux-kernel@vger.kernel.org
References: <20230706190217.371721-1-thuth@redhat.com>
 <2d9bb146-e1ec-4fc2-a4bc-e1c67cfda723@app.fastmail.com>
 <8ec7f329-a0a3-7631-ba05-225944b19771@intel.com>
Content-Language: en-US
From:   Thomas Huth <thuth@redhat.com>
In-Reply-To: <8ec7f329-a0a3-7631-ba05-225944b19771@intel.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 06/07/2023 22.30, Dave Hansen wrote:
> On 7/6/23 13:22, Arnd Bergmann wrote:
>> On Thu, Jul 6, 2023, at 21:02, Thomas Huth wrote:
>>> The arch_calc_vm_prot_bits() macro uses VM_PKEY_BIT0 etc. which are
>>> not part of the uapi, so the macro is completely useless for userspace.
>>> It is also hidden behind the CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
>>> config switch which we shouldn't expose to userspace. Thus let's move
>>> this macro into a new internal header instead.
>>>
>>> Signed-off-by: Thomas Huth <thuth@redhat.com>
>> Fixes: 8f62c883222c9 ("x86/mm/pkeys: Add arch-specific VMA protection bits")
>> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>>
>> It looks like this was introduced right after the uapi split,
>> and probably is the result of an incorrect rebase.
> 
> Yeah, I bet I just glossed over the "uapi" in the path.
> 
> Is this causing any real problems?  Or is it OK to just send it along
> during the next merge window with other random cleanups?

As Arnd already said, it's not a real problem - I just came across this file 
while looking at the list in scripts/headers_install.sh.

  Thomas