From: Kevin Brodsky <kevin.brodsky@arm.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>,
Randy Dunlap <rdunlap@infradead.org>,
Dave Hansen <dave.hansen@intel.com>,
linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
Yury Khrustalev <yury.khrustalev@arm.com>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] docs: proc: document ProtectionKey in smaps
Date: Wed, 8 Apr 2026 09:15:10 +0200 [thread overview]
Message-ID: <fee59f61-cf62-4a60-9d8a-4543a02a9c48@arm.com> (raw)
In-Reply-To: <8a5e4afd-cd0a-400a-8624-79c1dc9e3ff3@kernel.org>
On 08/04/2026 09:05, David Hildenbrand (Arm) wrote:
>>>> To me "system" is a bit ambiguous here but _can_ refer to the whole
>>>> hardware/software system as a whole. To avoid redundancy, I'd say either:
>>>>
>>>> If both the kernel and the processor support protection keys...
>>>>
>>>> or
>>>>
>>>> If the system supports protection keys...
>>> I see your point. By "system" I essentially mean the hardware (the SoC).
>>> In general I would tend to avoid "processor" because not all CPUs in a
>>> system necessarily have the same features, and some features require
>>> hardware support beyond the CPU itself. Terminology is hard...
>>>
>>> Happy to replace "system" with "hardware" if that's clearer 🙂
>> I think that "system" is too nebulous there, so I would prefer to see
>> "hardware" instead.
> What if you're running in a VM where the feature is hidden ... ?
Of course that's also possible, "hardware" has to be interpreted in the
context of virtualisation... But granted it is possible to hide features
even on the host with the right kernel parameter, on arm64 at least.
"If the kernel supports protection keys (pkeys) and the hardware feature
is detected"? Still vague but a little more accurate.
- Kevin
next prev parent reply other threads:[~2026-04-08 7:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 12:51 [PATCH] docs: proc: document ProtectionKey in smaps Kevin Brodsky
2026-04-07 13:00 ` Vlastimil Babka (SUSE)
2026-04-07 14:00 ` David Hildenbrand (Arm)
2026-04-07 14:33 ` Lorenzo Stoakes
2026-04-07 14:42 ` Dave Hansen
2026-04-07 15:12 ` Kevin Brodsky
2026-04-07 18:58 ` Randy Dunlap
2026-04-08 7:05 ` David Hildenbrand (Arm)
2026-04-08 7:15 ` Kevin Brodsky [this message]
2026-04-08 7:39 ` David Hildenbrand (Arm)
2026-04-08 7:50 ` Kevin Brodsky
2026-04-08 7:54 ` David Hildenbrand (Arm)
2026-04-08 7:06 ` Kevin Brodsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fee59f61-cf62-4a60-9d8a-4543a02a9c48@arm.com \
--to=kevin.brodsky@arm.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=rdunlap@infradead.org \
--cc=skhan@linuxfoundation.org \
--cc=vbabka@kernel.org \
--cc=yury.khrustalev@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox