On 9/17/24 23:46, Muhammad Usama Anjum wrote:
On 9/17/24 6:56 AM, Shuah Khan wrote:
On 9/16/24 00:32, Muhammad Usama Anjum wrote:
On 9/12/24 8:44 PM, Shuah Khan wrote:
On 9/12/24 04:31, Muhammad Usama Anjum wrote:
The value of __NR_userfaultfd was changed to 282 when asm-generic/unistd.h was included. It makes the test to fail every time as the correct number of this syscall on x86_64 is 323. Fix the header to asm/unistd.h.
"please elaborate every time" - I just built on my x86_64 and built just fine.
The build isn't broken.
I am not saying this isn't a problem, it is good to understand why and how it is failing before making the change.
I mean to say that the test is failing at run time because the correct userfaultfd syscall isn't being found with __NR_userfaultfd = 282. _NR_userfaultfd's value depends on the header. When asm-generic/unistd.h is included, its value (282) is wrong. I've tested on x86_64.
Okay - how do you know this is wrong? can you provide more details.
git grep _NR_userfaultfd include/uapi/asm-generic/unistd.h:#define __NR_userfaultfd 282 include/uapi/asm-generic/unistd.h:__SYSCALL(__NR_userfaultfd, sys_userfaultfd) tools/include/uapi/asm-generic/unistd.h:#define __NR_userfaultfd 282
The fix is simple. Add the correct header which has _NR_userfaultfd = 323.
grep -rnIF "#define __NR_userfaultfd" tools/include/uapi/asm-generic/unistd.h:681:#define __NR_userfaultfd 282 arch/x86/include/generated/uapi/asm/unistd_32.h:374:#define __NR_userfaultfd 374 arch/x86/include/generated/uapi/asm/unistd_64.h:327:#define __NR_userfaultfd 323 arch/x86/include/generated/uapi/asm/unistd_x32.h:282:#define __NR_userfaultfd (__X32_SYSCALL_BIT + 323) arch/arm/include/generated/uapi/asm/unistd-eabi.h:347:#define __NR_userfaultfd (__NR_SYSCALL_BASE + 388) arch/arm/include/generated/uapi/asm/unistd-oabi.h:359:#define __NR_userfaultfd (__NR_SYSCALL_BASE + 388) include/uapi/asm-generic/unistd.h:681:#define __NR_userfaultfd 282
The number is dependent on the architecture. The above data shows that: x86 374 x86_64 323
Correct and the generated header files do the right thing and it is good to include them as this patch does.
This is a good find and fix. I wish you explained this in your changelog. Please add more details when you send v2.
There could be other issues lurking based on what I found.
The other two files are the problem where they hard code it to 282 without taking the __NR_SYSCALL_BASE for the arch into consideration:
tools/include/uapi/asm-generic/unistd.h:681:#define __NR_userfaultfd 282 include/uapi/asm-generic/unistd.h:681:#define __NR_userfaultfd 282
I'm unable to find the history of why it is set to 282 in unistd.h and when this problem happened.
According to git history it is added in the following commit to include/uapi/asm-generic/unistd.h:
09f7298100ea9767324298ab0c7979f6d7463183 Subject: [PATCH] userfaultfd: register uapi generic syscall (aarch64)
and it is added in the following commit to tools/include/uapi/asm-generic/unistd.h 34b009cfde2b8ce20a69c7bfd6bad4ce0e7cd970 Subject: [PATCH] tools include: Grab copies of arm64 dependent unistd.h files
I think, the above defines from include/uapi/asm-generic/unistd.h and tools/include/uapi/asm-generic/unistd.h should be removed.
Maybe others familiar with userfaultfd can determine the best course of action. We might have other NR_ defines in these two files that are causing problems for tests and tools that we haven't uncovered yet.
thanks, -- Shuah