On 2/12/25 12:34 PM, Dave Hansen wrote:
> Hi John,
> 
> On 6/13/24 19:30, John Hubbard wrote:
>> --- a/tools/testing/selftests/mm/protection_keys.c
>> +++ b/tools/testing/selftests/mm/protection_keys.c
>> @@ -42,7 +42,7 @@
>>   #include <sys/wait.h>
>>   #include <sys/stat.h>
>>   #include <fcntl.h>
>> -#include <unistd.h>
>> +#include <linux/unistd.h>
>>   #include <sys/ptrace.h>
>>   #include <setjmp.h>
> 
> I'm not quite sure how but this broke the protection_keys.c selftest for
> me. Before this commit (a5c6bc590094a1a73cf6fa3f505e1945d2bf2461) things
> are fine.  But after, I get:
> 
> 	running PKEY tests for unsupported CPU/OS
> 
> The "unsupported" test just makes a pkey_alloc() syscall. It's probably
> calling the wrong syscall number or something.
> 
> I think it's still broken in mainline. What's the right fix?

A couple of thoughts:

1) I now think that that commit was a bad idea, because it turns out
kselftests doesn't make it easy to set up an asm/header.h approach.
And this partial approach seems like it won't work at all for syscalls
in particular.

I think reverting the commit is appropriate. It doesn't revert cleanly
at top of tree, but a very small fix allows a revert.

I'm attaching a patch that does that.

2) I'm unable to reproduce what you saw, because in ALL cases (before
or after the commit, and with or without a revert), I get the same
results on my Intel test machine:

     $ ./protection_keys_64
     has pkeys: 0
     running PKEY tests for unsupported CPU/OS

...so that's why I'm attaching a patch, in case you can verify that a
revert fixes it.


thanks,
-- 
John Hubbard