mprotect.2: pkey_mprotect() acts like mprotect() if pkey is set to -1, not 0

The mprotect.2 NOTES say:

    On systems that do not support protection keys in
    hardware, pkey_mprotect() may still be used, but pkey must
    be set to 0.  When called this way, the operation of
    pkey_mprotect() is equivalent to mprotect().

But this is not what the glibc manual says:

    It is also possible to call pkey_mprotect with a key value
    of -1, in which case it will behave in the same way as
    mprotect.

Which is correct. Both the glibc implementation and the
kernel check whether pkey is -1. 0 is not a valid pkey when
memory protection keys are not supported in hardware.

Signed-off-by: Mark Wielaard <mark@klomp.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Mark Wielaard 2019-05-30 01:08:39 +02:00 committed by Michael Kerrisk
parent e6017d5615
commit a4a0b74234
1 changed files with 1 additions and 1 deletions

View File

@ -274,7 +274,7 @@ On systems that do not support protection keys in hardware,
.BR pkey_mprotect ()
may still be used, but
.IR pkey
must be set to 0.
must be set to -1.
When called this way, the operation of
.BR pkey_mprotect ()
is equivalent to