On 03/08/20 4:34 pm, Michael Ellerman wrote:
Sandipan Das [off-list ref] writes:
quoted
On some distros, there are conflicts w.r.t to redefinition
of pkey syscall numbers which cause build failures. This
fixes them.
Reported-by: Sachin Sant <redacted>
Signed-off-by: Sandipan Das <redacted>
---
Previous versions can be found at:
v1: https://lore.kernel.org/linuxppc-dev/20200803074043.466809-1-sandipan@linux.ibm.com/ (local)
Changes in v2:
- Fix incorrect commit message.
---
tools/testing/selftests/powerpc/include/pkeys.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/powerpc/include/pkeys.h b/tools/testing/selftests/powerpc/include/pkeys.h
index 6ba95039a034..26eef5c1f8ea 100644
--- a/tools/testing/selftests/powerpc/include/pkeys.h
+++ b/tools/testing/selftests/powerpc/include/pkeys.h
@@ -31,8 +31,13 @@
#define SI_PKEY_OFFSET 0x20
+#undef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
We shouldn't undef them.
They should obviously never change, but if the system headers already
have a definition then we should use that, so I think it should be:
#ifndef SYS_pkey_mprotect
#define SYS_pkey_mprotect 386
#endif
Agreed. This had me confused.
$ grep -nr "#define __NR_pkey_" /usr/include/
/usr/include/asm-generic/unistd.h:767:#define __NR_pkey_mprotect 288
/usr/include/asm-generic/unistd.h:769:#define __NR_pkey_alloc 289
/usr/include/asm-generic/unistd.h:771:#define __NR_pkey_free 290
/usr/include/powerpc64le-linux-gnu/asm/unistd_32.h:374:#define __NR_pkey_alloc 384
/usr/include/powerpc64le-linux-gnu/asm/unistd_32.h:375:#define __NR_pkey_free 385
/usr/include/powerpc64le-linux-gnu/asm/unistd_32.h:376:#define __NR_pkey_mprotect 386
/usr/include/powerpc64le-linux-gnu/asm/unistd_64.h:365:#define __NR_pkey_alloc 384
/usr/include/powerpc64le-linux-gnu/asm/unistd_64.h:366:#define __NR_pkey_free 385
/usr/include/powerpc64le-linux-gnu/asm/unistd_64.h:367:#define __NR_pkey_mprotect 386
...
But it looks like including unistd.h from a C program picks the
right values.
- Sandipan