Documentation/filesystems/proc.rst | 4 ++++ 1 file changed, 4 insertions(+)
The ProtectionKey entry was added in v4.9; back then it was
x86-specific, but it now lives in generic code and applies to all
architectures supporting pkeys (currently x86, power, arm64).
Time to document it: add a paragraph to proc.rst about the
ProtectionKey entry.
Reported-by: Yury Khrustalev <yury.khrustalev@arm.com>
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org
---
Documentation/filesystems/proc.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst
index b0c0d1b45b99..d673cad7dbe4 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -549,6 +549,10 @@ does not take into account swapped out page of underlying shmem objects.
naturally aligned THP pages of any currently enabled size. 1 if true, 0
otherwise.
+If both the kernel and the system support protection keys (pkeys),
+"ProtectionKey" indicates the memory protection key associated with the
+virtual memory area.
+
"VmFlags" field deserves a separate description. This member represents the
kernel flags associated with the particular virtual memory area in two letter
encoded manner. The codes are the following:
--
2.51.2On 4/7/26 05:51, Kevin Brodsky wrote: > +If both the kernel and the system support protection keys (pkeys), > +"ProtectionKey" indicates the memory protection key associated with the > +virtual memory area. I think you're trying to get across the point here that the kernel needs to know about protection keys, have it enabled, and be running on a CPU with pkey support. 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... But I'm ok with what you have in any case. Folks will understand what you're saying: Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
On 07/04/2026 16:42, Dave Hansen wrote: > On 4/7/26 05:51, Kevin Brodsky wrote: >> +If both the kernel and the system support protection keys (pkeys), >> +"ProtectionKey" indicates the memory protection key associated with the >> +virtual memory area. > I think you're trying to get across the point here that the kernel needs > to know about protection keys, have it enabled, and be running on a CPU > with pkey support. Indeed. > 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 :) > But I'm ok with what you have in any case. Folks will understand what > you're saying: Hopefully! - Kevin > Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
On 4/7/26 8:12 AM, Kevin Brodsky wrote: > On 07/04/2026 16:42, Dave Hansen wrote: >> On 4/7/26 05:51, Kevin Brodsky wrote: >>> +If both the kernel and the system support protection keys (pkeys), >>> +"ProtectionKey" indicates the memory protection key associated with the >>> +virtual memory area. >> I think you're trying to get across the point here that the kernel needs >> to know about protection keys, have it enabled, and be running on a CPU >> with pkey support. > > Indeed. > >> 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. thanks. -- ~Randy
On 07/04/2026 20:58, Randy Dunlap 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. Ack, will send a v2. - Kevin
On 4/7/26 20:58, Randy Dunlap wrote: > > > On 4/7/26 8:12 AM, Kevin Brodsky wrote: >> On 07/04/2026 16:42, Dave Hansen wrote: >>> I think you're trying to get across the point here that the kernel needs >>> to know about protection keys, have it enabled, and be running on a CPU >>> with pkey support. >> >> Indeed. >> >>> 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 ... ? -- Cheers, David
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
On 4/8/26 09:15, Kevin Brodsky wrote: > On 08/04/2026 09:05, David Hildenbrand (Arm) wrote: >>> 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. Can we just talk about CPU support, to avoid using "system" or "hardware" ? -- Cheers, David
On 08/04/2026 09:39, David Hildenbrand (Arm) wrote: > On 4/8/26 09:15, Kevin Brodsky wrote: >> On 08/04/2026 09:05, David Hildenbrand (Arm) wrote: >>>> 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. > Can we just talk about CPU support, to avoid using "system" or "hardware" ? I'm not sure how this addresses your concern with virtualisation though, unless "CPU" is understood as whatever CPU is virtualised? But then the same logic could apply to "hardware"... Either way, I'm really not all that picky about it, I don't mind: "If both the kernel and the CPU support protection keys" - Kevin
On 4/8/26 09:50, Kevin Brodsky wrote: > On 08/04/2026 09:39, David Hildenbrand (Arm) wrote: >> On 4/8/26 09:15, Kevin Brodsky wrote: >>> 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. >> Can we just talk about CPU support, to avoid using "system" or "hardware" ? > > I'm not sure how this addresses your concern with virtualisation though, > unless "CPU" is understood as whatever CPU is virtualised? But then the > same logic could apply to "hardware"... > > Either way, I'm really not all that picky about it, I don't mind: "If > both the kernel and the CPU support protection keys" LGTM -- Cheers, David
On Tue, Apr 07, 2026 at 01:51:33PM +0100, Kevin Brodsky wrote: > The ProtectionKey entry was added in v4.9; back then it was > x86-specific, but it now lives in generic code and applies to all > architectures supporting pkeys (currently x86, power, arm64). > > Time to document it: add a paragraph to proc.rst about the > ProtectionKey entry. > > Reported-by: Yury Khrustalev <yury.khrustalev@arm.com> > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> LGTM, So: Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> > --- > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: Shuah Khan <skhan@linuxfoundation.org> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Lorenzo Stoakes <ljs@kernel.org> > Cc: Vlastimil Babka <vbabka@kernel.org> > Cc: David Hildenbrand <david@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-mm@kvack.org > --- > Documentation/filesystems/proc.rst | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst > index b0c0d1b45b99..d673cad7dbe4 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -549,6 +549,10 @@ does not take into account swapped out page of underlying shmem objects. > naturally aligned THP pages of any currently enabled size. 1 if true, 0 > otherwise. > > +If both the kernel and the system support protection keys (pkeys), > +"ProtectionKey" indicates the memory protection key associated with the > +virtual memory area. > + > "VmFlags" field deserves a separate description. This member represents the > kernel flags associated with the particular virtual memory area in two letter > encoded manner. The codes are the following: > -- > 2.51.2 >
On 4/7/26 14:51, Kevin Brodsky wrote: > The ProtectionKey entry was added in v4.9; back then it was > x86-specific, but it now lives in generic code and applies to all > architectures supporting pkeys (currently x86, power, arm64). > > Time to document it: add a paragraph to proc.rst about the > ProtectionKey entry. > > Reported-by: Yury Khrustalev <yury.khrustalev@arm.com> > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> > --- > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: Shuah Khan <skhan@linuxfoundation.org> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Lorenzo Stoakes <ljs@kernel.org> > Cc: Vlastimil Babka <vbabka@kernel.org> > Cc: David Hildenbrand <david@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-mm@kvack.org > --- > Documentation/filesystems/proc.rst | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst > index b0c0d1b45b99..d673cad7dbe4 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -549,6 +549,10 @@ does not take into account swapped out page of underlying shmem objects. > naturally aligned THP pages of any currently enabled size. 1 if true, 0 > otherwise. > > +If both the kernel and the system support protection keys (pkeys), > +"ProtectionKey" indicates the memory protection key associated with the > +virtual memory area. Reviewed-by: David Hildenbrand (Arm) <david@kernel.org> -- Cheers, David
On 4/7/26 14:51, Kevin Brodsky wrote: > The ProtectionKey entry was added in v4.9; back then it was > x86-specific, but it now lives in generic code and applies to all > architectures supporting pkeys (currently x86, power, arm64). > > Time to document it: add a paragraph to proc.rst about the > ProtectionKey entry. > > Reported-by: Yury Khrustalev <yury.khrustalev@arm.com> > Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> > --- > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: Shuah Khan <skhan@linuxfoundation.org> > Cc: Dave Hansen <dave.hansen@linux.intel.com> > Cc: Andrew Morton <akpm@linux-foundation.org> > Cc: Lorenzo Stoakes <ljs@kernel.org> > Cc: Vlastimil Babka <vbabka@kernel.org> > Cc: David Hildenbrand <david@kernel.org> > Cc: Mark Rutland <mark.rutland@arm.com> > Cc: linux-fsdevel@vger.kernel.org > Cc: linux-mm@kvack.org > --- > Documentation/filesystems/proc.rst | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst > index b0c0d1b45b99..d673cad7dbe4 100644 > --- a/Documentation/filesystems/proc.rst > +++ b/Documentation/filesystems/proc.rst > @@ -549,6 +549,10 @@ does not take into account swapped out page of underlying shmem objects. > naturally aligned THP pages of any currently enabled size. 1 if true, 0 > otherwise. > > +If both the kernel and the system support protection keys (pkeys), > +"ProtectionKey" indicates the memory protection key associated with the > +virtual memory area. > + > "VmFlags" field deserves a separate description. This member represents the > kernel flags associated with the particular virtual memory area in two letter > encoded manner. The codes are the following:
© 2016 - 2026 Red Hat, Inc.