- Linux-kselftest-mirror - lists.linaro.org

by Shuah Khan

Hi Alexei and Daniel, bpf test doesn't build on Linux 5.4 mainline. Do you know what's happening here. make -C tools/testing/selftests/bpf/ -c progs/test_core_reloc_ptr_as_arr.c -o - || echo "clang failed") | \ llc -march=bpf -mcpu=generic -filetype=obj -o /mnt/data/lkml/linux_5.4/tools/testing/selftests/bpf/test_core_reloc_ptr_as_arr.o progs/test_core_reloc_ptr_as_arr.c:25:6: error: use of unknown builtin '__builtin_preserve_access_index' [-Wimplicit-function-declaration] if (BPF_CORE_READ(&out->a, &in[2].a)) ^ ./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ' __builtin_preserve_access_index(src)) ^ progs/test_core_reloc_ptr_as_arr.c:25:6: warning: incompatible integer to pointer conversion passing 'int' to parameter of type 'const void *' [-Wint-conversion] if (BPF_CORE_READ(&out->a, &in[2].a)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ' __builtin_preserve_access_index(src)) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 warning and 1 error generated. llc: error: llc: <stdin>:1:1: error: expected top-level entity clang failed Also make TARGETS=bpf kselftest fails as well. Dependency between tools/lib/bpf and the test. How can we avoid this type of dependency or resolve it in a way it doesn't result in build failures? thanks, -- Shuah

5 years, 11 months

5
13
0 0

Lucrative for You and Me

by Rose

Ohayou Gozaimasu. My name is Yuval Rose. I have an urgent lucrative business opportunity for you worth over 15 Milli0n US D0llars. This is by virtue of the signficance of your nationality (Japanese). Waiting for your speedy reply for further and complete details. Doumo Arigatou. Yuval Toronto-Canada

5 years, 11 months

1
0
0 0

[PATCH v2] selftests: execveat: Fix _GNU_SOURCE redefined build warn

by Shuah Khan

Fix the following _GNU_SOURCE redefined build warn: execveat.c:8: warning: "_GNU_SOURCE" redefined Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> --- No code changes. Sending to right people. tools/testing/selftests/exec/execveat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/exec/execveat.c b/tools/testing/selftests/exec/execveat.c index cbb6efbdb786..045a3794792a 100644 --- a/tools/testing/selftests/exec/execveat.c +++ b/tools/testing/selftests/exec/execveat.c @@ -5,7 +5,9 @@ * Selftests for execveat(2). */ +#ifndef _GNU_SOURCE #define _GNU_SOURCE /* to get O_PATH, AT_EMPTY_PATH */ +#endif #include <sys/sendfile.h> #include <sys/stat.h> #include <sys/syscall.h> -- 2.20.1

5 years, 11 months

2
3
0 0

[PATCH] selftests: pidfd: Fix undefined reference to pthread_create()

by Shuah Khan

Fix build failure: undefined reference to `pthread_create' collect2: error: ld returned 1 exit status Fix CFLAGS to include pthread correctly. Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> --- tools/testing/selftests/pidfd/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/pidfd/Makefile b/tools/testing/selftests/pidfd/Makefile index 464c9b76148f..7550f08822a3 100644 --- a/tools/testing/selftests/pidfd/Makefile +++ b/tools/testing/selftests/pidfd/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0-only -CFLAGS += -g -I../../../../usr/include/ -lpthread +CFLAGS += -g -I../../../../usr/include/ -pthread TEST_GEN_PROGS := pidfd_test pidfd_open_test pidfd_poll_test pidfd_wait -- 2.20.1

5 years, 11 months

2
1
0 0

[PATCH] selftests: execveat: Fix _GNU_SOURCE redefined build warn

by Shuah Khan

Fix the following _GNU_SOURCE redefined build warn: execveat.c:8: warning: "_GNU_SOURCE" redefined Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> --- tools/testing/selftests/exec/execveat.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/exec/execveat.c b/tools/testing/selftests/exec/execveat.c index cbb6efbdb786..045a3794792a 100644 --- a/tools/testing/selftests/exec/execveat.c +++ b/tools/testing/selftests/exec/execveat.c @@ -5,7 +5,9 @@ * Selftests for execveat(2). */ +#ifndef _GNU_SOURCE #define _GNU_SOURCE /* to get O_PATH, AT_EMPTY_PATH */ +#endif #include <sys/sendfile.h> #include <sys/stat.h> #include <sys/syscall.h> -- 2.20.1

5 years, 11 months

1
0
0 0

[PATCH AUTOSEL 5.2 48/70] selftests/powerpc: Retry on host facility unavailable

by Sasha Levin

From: Gustavo Romero <gromero(a)linux.vnet.ibm.com> [ Upstream commit 6652bf6408895b09d31fd4128a1589a1a0672823 ] TM test tm-unavailable must take into account aborts due to host aborting a transactin because of a facility unavailable exception, just like it already does for aborts on reschedules (TM_CAUSE_KVM_RESCHED). Reported-by: Desnes A. Nunes do Rosario <desnesn(a)linux.ibm.com> Tested-by: Desnes A. Nunes do Rosario <desnesn(a)linux.ibm.com> Signed-off-by: Gustavo Romero <gromero(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/1566341651-19747-1-git-send-email-gromero@linux.v… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/powerpc/tm/tm.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/tm/tm.h b/tools/testing/selftests/powerpc/tm/tm.h index 97f9f491c541a..c402464b038fc 100644 --- a/tools/testing/selftests/powerpc/tm/tm.h +++ b/tools/testing/selftests/powerpc/tm/tm.h @@ -55,7 +55,8 @@ static inline bool failure_is_unavailable(void) static inline bool failure_is_reschedule(void) { if ((failure_code() & TM_CAUSE_RESCHED) == TM_CAUSE_RESCHED || - (failure_code() & TM_CAUSE_KVM_RESCHED) == TM_CAUSE_KVM_RESCHED) + (failure_code() & TM_CAUSE_KVM_RESCHED) == TM_CAUSE_KVM_RESCHED || + (failure_code() & TM_CAUSE_KVM_FAC_UNAV) == TM_CAUSE_KVM_FAC_UNAV) return true; return false; -- 2.20.1

5 years, 11 months

1
0
0 0

[PATCH AUTOSEL 5.3 63/87] selftests/powerpc: Retry on host facility unavailable

by Sasha Levin

From: Gustavo Romero <gromero(a)linux.vnet.ibm.com> [ Upstream commit 6652bf6408895b09d31fd4128a1589a1a0672823 ] TM test tm-unavailable must take into account aborts due to host aborting a transactin because of a facility unavailable exception, just like it already does for aborts on reschedules (TM_CAUSE_KVM_RESCHED). Reported-by: Desnes A. Nunes do Rosario <desnesn(a)linux.ibm.com> Tested-by: Desnes A. Nunes do Rosario <desnesn(a)linux.ibm.com> Signed-off-by: Gustavo Romero <gromero(a)linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> Link: https://lore.kernel.org/r/1566341651-19747-1-git-send-email-gromero@linux.v… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/powerpc/tm/tm.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/powerpc/tm/tm.h b/tools/testing/selftests/powerpc/tm/tm.h index 97f9f491c541a..c402464b038fc 100644 --- a/tools/testing/selftests/powerpc/tm/tm.h +++ b/tools/testing/selftests/powerpc/tm/tm.h @@ -55,7 +55,8 @@ static inline bool failure_is_unavailable(void) static inline bool failure_is_reschedule(void) { if ((failure_code() & TM_CAUSE_RESCHED) == TM_CAUSE_RESCHED || - (failure_code() & TM_CAUSE_KVM_RESCHED) == TM_CAUSE_KVM_RESCHED) + (failure_code() & TM_CAUSE_KVM_RESCHED) == TM_CAUSE_KVM_RESCHED || + (failure_code() & TM_CAUSE_KVM_FAC_UNAV) == TM_CAUSE_KVM_FAC_UNAV) return true; return false; -- 2.20.1

5 years, 11 months

1
0
0 0

kunit: what do we do with the 'kunit/alpha/master' branch?

by David Gow

TL;DR: We expect KUnit to be accepted upstream into Linus' branch in the next week or two, and we now need to figure out what we are going to do with our non-upstream 'kunit/alpha/master' branch. Hello everyone, We've put together a rough proposal of what we should do with our not-upstream branch, known to most people using it as 'kunit/alpha/master'[1], now that KUnit's acceptance into mainline appears to be imminent (the KUnit MVP patchset is now in linux-next, and the merge window just opened). ========== Background ========== KUnit development is currently split between two versions: the 'kunit/alpha/master'[1] git branch, and the version being submitted to the upstream Linux kernel. While there are some good reasons to continue to have two separate versions of KUnit, at present there is some uncertainty around the difference between these versions, and in which circumstances each version is useful. At present, the 'kunit/alpha/master' branch serves a few different purposes. It is a place for code not-yet-ready for upstream -- such as the mocking framework -- while being developed, while also acting as a stable version for customers who do not wish to follow along with the changes made during the upstreaming process. Adding to the confusion, the name 'kunit/alpha/master' refers to an early (alpha) version of KUnit, and the version of KUnit being upstreamed has now diverged significantly from this version, requiring significant differences in documentation, and requiring a number of changes to tests when porting from one version to the other. Finally, it is not clear how the 'kunit/alpha/master' version should evolve as features it contains are upstreamed. On the other hand, the version being upstreamed has its own complications. It contains significantly fewer features (as features such as the mocking frameworks will be upstreamed individually), and so is less useful for the average customer. Until each feature is upstreamed, it is iterated on rapidly to address comments from the kernel community, so in-progress features are not stable enough to reasonably build on. Finally, it exists only as a set of patches on mailing lists, rather than as a maintained git repository (due to the fact that the patches themselves are changing rapidly), making it difficult for early adopters to incorporate into their own trees. Whilst we believe there to be enough (at times conflicting) goals above to justify having multiple versions of KUnit, we want to ensure that they are meeting their goals, and that we have a process to ensure that code finds its way into the correct version, that we can deprecate and remove failed experiments or superseded versions, and that we can keep pace with upstream kernel releases. ============ The Proposal ============ We propose having two tracks of development: the upstream kernel (comprising both code that has been upstreamed, and code which is in the process of being upstreamed -- i.e. is being reviewed on the mailing lists), and an 'experimental' branch, which contains features which are yet to be submitted upstream. Periodically, the 'experimental' branch will be replaced with a new 'experimental' branch based on the latest upstream version. This will allow us to focus on code based on upstream versions by deprecating earlier, experimental versions of features. The older experimental branch will stay around, but receive no new features or support: customers will need to eventually migrate to either the upstream kernel (if all of the features they require have been upstreamed), or to the latest 'experimental' branch (if they still require non-upstreamed features). Where practical, 'experimental' branches will try to provide a stable interface (and/or compatibility layers/shims) such that users can write tests against an experimental version and expect our changes to break them infrequently. We don't intend to make any solid guarantee, however: so users will need to be able to deal with some breakage. We expect most changes to KUnit to be submitted directly upstream, and reserve the 'experimental' branch for features where: a) the design is yet to be proven by early adopters, and is likely to change; b) the feature is large enough that having a solid staging environment in which several developers can work is necessary; and/or c) it depends on existing features only available in the 'experimental' branch. An example of features suited to the 'experimental' branch are the mocking systems[2]. ===================== Lifetime of a feature ===================== A new feature (that for one of the above reasons may require some experimentation before being sent upstream) would typically be developed as follows: 1. An initial version of the feature is developed against the latest 'experimental' branch. 2. The feature is tested by users of the 'experimental' branch. 3. It is revised as needed within the 'experimental' branch. If breaking changes are required, and supporting some form of compatibility layer is practical, such a layer is implemented to avoid breaking existing 'experimental' customers. 4. Once the feature is deemed ready, it is submitted to the mailing lists for the upstream kernel. Any compatibility layers for earlier experimental version are removed -- this is a 'clean' version of the change. 5. Development of the change continues on the kernel mailing lists: any particularly important changes or bugfixes are ported to the 'experimental' branch if feasible, but complete convergence is not expected at this stage. 6. When the feature is accepted upstream, a new 'experimental' branch is created based on the new upstream kernel. Development on the old 'experimental' branch ceases. 7. The upstream version of the feature has now superseded the experimental version. All future development is done based on the upstream version, either in the new 'experimental' branch, or directly against the upstream kernel. 8. Any customers still using the experimental version of the feature will need to update their code to work with the upstream version in order to update to the new (supported) 'experimental' branch, or to the upstream kernel. =========================== What does this mean for me? =========================== ...as a user? ------------- If you're using the upstream version of KUnit, nothing! Features will continue to be pushed upstream when they're ready. If you're using the 'kunit/alpha/master' branch, then you'll need to switch to the new 'experimental-<version>' branches. Every so often, we'll create a new 'experimental-<version>' branch, and you'll need to rebase your code on top of that to keep receiving updated features and bugfixes. While we intend to make this as painless as possible, there may be breaking changes which require you to rework some of your tests. Once a feature exists in the upstream kernel, the version of that feature in the 'experimental' branches should stabilise somewhat. ...as a KUnit developer? ------------------------ For most changes/bugfixes which apply cleanly to the upstream version, you should directly submit these upstream as before. If it is feasible and useful to backport them to the latest 'experimental' branch (e.g., they are bugfixes to code that the experimental branch already has), please do so. For more major features (or anything which depends on yet-to-be-upstreamed code), you should develop them in the latest 'experimental' branch. For the most part, you can treat this the same way as the old 'kunit/alpha/master' branch, but note that changes will need to be rebased on top of a newer experimental branch periodically. It may make sense to use this as an opportunity to tidy the code up somewhat: by removing compatibility code for deprecated features, or to merge 'fixup' commits. Once the code has been upstreamed, the next rebase of the 'experimental' branch should only use the upstream version: there should not be a separate 'experimental' version of upstream code save for the development of a new 'experimental' feature or bugfix. For more details, see the 'Lifetime of a feature' section above. ============= In Conclusion ============= We'll continue to be working with upstream as before, but we intend to rename and more explicitly specify the purpose of the 'kunit/alpha/master' branch as above. This will require a bit more work from people using and developing against this 'experimental' branch, but allows us to continue to use it for features such as the mocking framework while limiting its divergence from upstream. Do let us know if this sounds reasonable to you, if it will affect your use case, or if you have any questions. Cheers, -- David & Brendan [1] https://kunit.googlesource.com/linux/+/refs/heads/kunit/alpha/master [2] https://kunit.googlesource.com/linux/+/kunit/alpha/master/Documentation/tes…

5 years, 11 months

4
7
0 0

[PATCH v17 00/19] kunit: introduce KUnit, the Linux kernel unit testing framework

by Brendan Higgins

## TL;DR This revision addresses comments from Linus[1] and Randy[2], by moving top level `kunit/` directory to `lib/kunit/` and likewise moves top level Kconfig entry under lib/Kconfig.debug, so the KUnit submenu now shows up under the "Kernel Hacking" menu. As a consequence of this, I rewrote patch 06/18 (kbuild: enable building KUnit), and now needs to be re-acked/reviewed. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[3]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[4]. Additionally for convenience, I have applied these patches to a branch[5]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/initial/v5.3/v17 branch. ## History since v15 ### v17 - Addressed comments on 06/19 (lib: enable building KUnit in lib/) from Stephen Boyd by moving KUnit submenu ahead of Runtime Testing submenu. ### v16 - Addressed comments from Linus Torvalds by moving all kunit/ paths to lib/kunit/. - Addressed comments by Randy Dunlap by moving KUnit Kconfig under lib/Kconfig.debug so the KUnit submenu shows up under the "Kernel Hacking" menu. [1] https://www.lkml.org/lkml/2019/9/20/696 [2] https://www.lkml.org/lkml/2019/9/20/738 [3] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni… [4] https://google.github.io/kunit-docs/third_party/kernel/docs/ [5] https://kunit.googlesource.com/linux/+/kunit/initial/v5.3/v17 --- Avinash Kondareddy (1): kunit: test: add tests for KUnit managed resources Brendan Higgins (16): kunit: test: add KUnit test runner core kunit: test: add test resource management API kunit: test: add string_stream a std::stream like string builder kunit: test: add assertion printing library kunit: test: add the concept of expectations lib: enable building KUnit in lib/ kunit: test: add initial tests objtool: add kunit_try_catch_throw to the noreturn list kunit: test: add support for test abort kunit: test: add tests for kunit test abort kunit: test: add the concept of assertions kunit: defconfig: add defconfigs for building KUnit tests Documentation: kunit: add documentation for KUnit MAINTAINERS: add entry for KUnit the unit testing framework MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section kunit: fix failure to build without printk Felix Guo (1): kunit: tool: add Python wrappers for running KUnit tests Iurii Zaikin (1): kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec() Documentation/dev-tools/index.rst | 1 + Documentation/dev-tools/kunit/api/index.rst | 16 + Documentation/dev-tools/kunit/api/test.rst | 11 + Documentation/dev-tools/kunit/faq.rst | 62 + Documentation/dev-tools/kunit/index.rst | 79 + Documentation/dev-tools/kunit/start.rst | 180 ++ Documentation/dev-tools/kunit/usage.rst | 576 +++++++ MAINTAINERS | 13 + arch/um/configs/kunit_defconfig | 3 + include/kunit/assert.h | 356 ++++ include/kunit/string-stream.h | 51 + include/kunit/test.h | 1490 +++++++++++++++++ include/kunit/try-catch.h | 75 + kernel/Makefile | 2 + kernel/sysctl-test.c | 392 +++++ lib/Kconfig.debug | 13 + lib/Makefile | 2 + lib/kunit/Kconfig | 38 + lib/kunit/Makefile | 9 + lib/kunit/assert.c | 141 ++ lib/kunit/example-test.c | 88 + lib/kunit/string-stream-test.c | 52 + lib/kunit/string-stream.c | 217 +++ lib/kunit/test-test.c | 331 ++++ lib/kunit/test.c | 478 ++++++ lib/kunit/try-catch.c | 118 ++ tools/objtool/check.c | 1 + tools/testing/kunit/.gitignore | 3 + tools/testing/kunit/configs/all_tests.config | 3 + tools/testing/kunit/kunit.py | 136 ++ tools/testing/kunit/kunit_config.py | 66 + tools/testing/kunit/kunit_kernel.py | 149 ++ tools/testing/kunit/kunit_parser.py | 310 ++++ tools/testing/kunit/kunit_tool_test.py | 206 +++ .../test_is_test_passed-all_passed.log | 32 + .../test_data/test_is_test_passed-crash.log | 69 + .../test_data/test_is_test_passed-failure.log | 36 + .../test_is_test_passed-no_tests_run.log | 75 + .../test_output_isolated_correctly.log | 106 ++ .../test_data/test_read_from_file.kconfig | 17 + 40 files changed, 6003 insertions(+) create mode 100644 Documentation/dev-tools/kunit/api/index.rst create mode 100644 Documentation/dev-tools/kunit/api/test.rst create mode 100644 Documentation/dev-tools/kunit/faq.rst create mode 100644 Documentation/dev-tools/kunit/index.rst create mode 100644 Documentation/dev-tools/kunit/start.rst create mode 100644 Documentation/dev-tools/kunit/usage.rst create mode 100644 arch/um/configs/kunit_defconfig create mode 100644 include/kunit/assert.h create mode 100644 include/kunit/string-stream.h create mode 100644 include/kunit/test.h create mode 100644 include/kunit/try-catch.h create mode 100644 kernel/sysctl-test.c create mode 100644 lib/kunit/Kconfig create mode 100644 lib/kunit/Makefile create mode 100644 lib/kunit/assert.c create mode 100644 lib/kunit/example-test.c create mode 100644 lib/kunit/string-stream-test.c create mode 100644 lib/kunit/string-stream.c create mode 100644 lib/kunit/test-test.c create mode 100644 lib/kunit/test.c create mode 100644 lib/kunit/try-catch.c create mode 100644 tools/testing/kunit/.gitignore create mode 100644 tools/testing/kunit/configs/all_tests.config create mode 100755 tools/testing/kunit/kunit.py create mode 100644 tools/testing/kunit/kunit_config.py create mode 100644 tools/testing/kunit/kunit_kernel.py create mode 100644 tools/testing/kunit/kunit_parser.py create mode 100755 tools/testing/kunit/kunit_tool_test.py create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-all_passed.log create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-crash.log create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-failure.log create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-no_tests_run.log create mode 100644 tools/testing/kunit/test_data/test_output_isolated_correctly.log create mode 100644 tools/testing/kunit/test_data/test_read_from_file.kconfig -- 2.23.0.351.gc4317032e6-goog

5 years, 11 months

2
21
0 0

[PATCH] selftests/net: replace AF_MAX with INT_MAX in socket.c

by Marcelo Henrique Cerri

Use INT_MAX instead of AF_MAX, since libc might have a smaller value of AF_MAX than the kernel, what causes the test to fail. Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri(a)canonical.com> --- tools/testing/selftests/net/socket.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/socket.c b/tools/testing/selftests/net/socket.c index afca1ead677f..10e75ba90124 100644 --- a/tools/testing/selftests/net/socket.c +++ b/tools/testing/selftests/net/socket.c @@ -6,6 +6,7 @@ #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> +#include <limits.h> struct socket_testcase { int domain; @@ -24,7 +25,10 @@ struct socket_testcase { }; static struct socket_testcase tests[] = { - { AF_MAX, 0, 0, -EAFNOSUPPORT, 0 }, + /* libc might have a smaller value of AF_MAX than the kernel + * actually supports, so use INT_MAX instead. + */ + { INT_MAX, 0, 0, -EAFNOSUPPORT, 0 }, { AF_INET, SOCK_STREAM, IPPROTO_TCP, 0, 1 }, { AF_INET, SOCK_DGRAM, IPPROTO_TCP, -EPROTONOSUPPORT, 1 }, { AF_INET, SOCK_DGRAM, IPPROTO_UDP, 0, 1 }, -- 2.20.1

5 years, 11 months

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror