On 2/13/25 3:32 AM, Li Wang wrote:
Hi John, On Thu, Feb 13, 2025 at 6:31 AM John Hubbard <jhubbard@xxxxxxxxxx <mailto:jhubbard@xxxxxxxxxx>> wrote: 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? omg I think this is an asm-generic include mistake, I'll check on it in an hour or so, in more depth. I just found that mlock2_() return a wrong valuein mlock2-test, I guess that was caused by including the wrong header file <asm-generic/unistd.h>,which might define a different syscall number than what the kernel uses on the test system.
Agreed.
Shouldn't we make use of <unistd.h> directly?
Well, yes and no. For now, there appear to be two commits involved in causing these problems, and the __NR_* parts need to be reverted. I'll explain more when I post later today, but for the moment, the first, mseal- related commit below has some hints about how we got here: 504d8a5e0fd4 selftests/mm: mseal, self_elf: fix missing __NR_mseal a5c6bc590094 selftests/mm: remove local __NR_* definitions thanks, -- John Hubbard
