On 9/22/24 23:35, Muhammad Usama Anjum wrote:
...
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.
I'm sending 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.
Added authors of these patches.
Thank you. Would you be able top follow up on this and send patches
to remove these defines if it deemed to be the correct solution?
thanks,
-- Shuah
