-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
get kselftests
target building
#1698
Comments
Well there are a bunch of errors but some tests are building OK as far as I can tell: |
Note that there are 2 fixes applied on this KernelCI staging-next branch, for when the arch is They've been reviewed on the mailing list by @nathanchance so in principle it's just a matter of time until they get applied to the kselftest tree. Not sure if that's related to the issues you're seeing, but worth mentioning anyway. |
Here's a tentative series from the mailing list that Benjamin and I have worked on that solves (at least) my kselftest build issues: https://lore.kernel.org/all/20230825182316.m2ksjoxe4s7dsapn@google.com/ After discussion, Benjamin proposed a 3-patch series which fixed some of the issues I was experiencing. I, then, added a 4th patch which should be applied on top of this series. Hopefully Benjamin can re-roll this into an n=4 patch series so that Once this is re-rolled into a single n=4 series (and subsequently applied to next) I think we can close this issue 😸 |
Update: I pinged Benjamin off-list regarding the state of this series. Fingers crossed 🤞 |
Hi, I am experiencing many warnings when trying to build tools/testing/selftests. Here's one such example from rseq tree: | param_test.c:1234:10: error: address argument to atomic operation must be a pointer to _Atomic type ('intptr_t *' (aka 'long *') invalid) | 1234 | while (!atomic_load(&args->percpu_list_ptr)) {} | | ^ ~~~~~~~~~~~~~~~~~~~~~~ | /usr/local/google/home/justinstitt/repos/tc-build/build/llvm/final/lib/clang/18/include/stdatomic.h:140:29: note: expanded from macro 'atomic_load' | 140 | #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST) | | ^ ~~~~~~ I added the _Atomic type in various locations to silence _all_ (10) of these warnings. I'm wondering, though, perhaps the absence of these _Atomic types in the first place is on purpose? Am I on the right track to fix these warnings without damaging the legitimacy of the tests at hand? I'd like some feedback about where to go from here and if others are experiencing the same issues. Thanks! FWIW here's my specific build incantation on Clang-18 (49d41de57896e935cd5726719c5208bce22694ae): $ make LLVM=1 -j128 ARCH=x86_64 mrproper headers defconfig kselftest-merge $ make LLVM=1 ARCH=x86_64 -C tools/testing/selftests Link: ClangBuiltLinux#1698 Link: ClangBuiltLinux/continuous-integration2#61 Signed-off-by: Justin Stitt <justinstitt@google.com>
Just to keep this issue up-to-date... Here are some patches in the works: |
When building with Clang, I am getting many warnings from the selftests/rseq tree. Here's one such example from rseq tree: | param_test.c:1234:10: error: address argument to atomic operation must be a pointer to _Atomic type ('intptr_t *' (aka 'long *') invalid) | 1234 | while (!atomic_load(&args->percpu_list_ptr)) {} | | ^ ~~~~~~~~~~~~~~~~~~~~~~ | /usr/local/google/home/justinstitt/repos/tc-build/build/llvm/final/lib/clang/18/include/stdatomic.h:140:29: note: expanded from macro 'atomic_load' | 140 | #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST) | | ^ ~~~~~~ Use compiler builtins `__atomic_load_n()` and `__atomic_store_n()` with accompanying __ATOMIC_ACQUIRE and __ATOMIC_RELEASE, respectively. This will fix the warnings because the compiler builtins do not expect their arguments to have _Atomic type. This should also make TSAN happier. Link: ClangBuiltLinux#1698 Link: ClangBuiltLinux/continuous-integration2#61 Suggested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Justin Stitt <justinstitt@google.com>
When building with Clang, I am getting many warnings from the selftests/rseq tree. Here's one such example from rseq tree: | param_test.c:1234:10: error: address argument to atomic operation must be a pointer to _Atomic type ('intptr_t *' (aka 'long *') invalid) | 1234 | while (!atomic_load(&args->percpu_list_ptr)) {} | | ^ ~~~~~~~~~~~~~~~~~~~~~~ | /usr/local/google/home/justinstitt/repos/tc-build/build/llvm/final/lib/clang/18/include/stdatomic.h:140:29: note: expanded from macro 'atomic_load' | 140 | #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST) | | ^ ~~~~~~ Use compiler builtins `__atomic_load_n()` and `__atomic_store_n()` with accompanying __ATOMIC_ACQUIRE and __ATOMIC_RELEASE, respectively. This will fix the warnings because the compiler builtins do not expect their arguments to have _Atomic type. This should also make TSAN happier. Link: ClangBuiltLinux#1698 Link: ClangBuiltLinux/continuous-integration2#61 Suggested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Justin Stitt <justinstitt@google.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Another update, Benjamin has the hid/bpf fixes applied: https://lore.kernel.org/all/169703194378.3126081.13251971976785038026.b4-ty@kernel.org/ |
The plot thickens... It looked like we were finally going to get some clean builds with an incantation like:
... but Commit 14571ab ("kselftest: Add new test for detecting unprobed Devicetree devices") which is in v6.7-rc1 has introduced some problems. For me, the build just hangs when it gets to the |
Yes I saw it got stuck in an infinite loop in the Python script. @nfraprado Looks like it wasn't just me seeing this problem, do you need some help to fix it or reproduce it? |
@gctucker Hi, I just got back from vacation and saw that report in the list regarding the infinite symlinks. I'll look into it and report back. |
I've replied to the thread on the mailing list, but just to close the loop, I've sent this patch fixing the issue: |
Hi everyone, @nickdesaulniers asked me to respond here. I recently posted 30 or 35 patches to fix all clang errors and warnings in the kselftests. Status: 11 patches are already merged into Linux main: These patches are pending. Most have been reviewed, with the notable exception of the x86 subsystem. I'll rebase on top of 6.10-rc1 and repost at that time (Monday): [PATCH 0/7] selftests/x86: fix build errors and warnings found via clang [1] Here's a few more that are most likely resolved by other authors' patches: [PATCH v2] selftests/alsa: missing a return value in unused dump_config_tree() [1] https://lore.kernel.org/20240503030214.86681-1-jhubbard@nvidia.com |
Looking at #906 , I noticed that
make LLVM=1 -j72 kselftest
fails with tons of warnings and errors; maybe we can use this as a metabug, since there will probably be lots of fixes necessary for this.The text was updated successfully, but these errors were encountered: