Linux-kselftest-mirror

linux-kselftest-mirror@lists.linaro.org

125 participants
14266 discussions

[PATCH net-next v2 0/6] selftests: drv-net: gro: enable HW GRO and LRO testing

by Jakub Kicinski

Add support for running our existing GRO test against HW GRO and LRO implementation. The first 3 patches are just ksft lib nice-to-haves, and patch 4 cleans up the existing gro Python. Patches 5 and 6 are of most practical interest. The support reconfiguring the NIC to disable SW GRO and enable HW GRO and LRO. Additionally last patch breaks up the existing GRO cases to track HW compliance at finer granularity. v2: - fix restoring all features - apply the generic XDP hack selectively (print a msg when it happens) - a lot of small tweaks and 4 extra patches v1: https://lore.kernel.org/20251128005242.2604732-1-kuba@kernel.org Jakub Kicinski (6): selftests: net: py: teach ksft_pr() multi-line safety selftests: net: py: teach cmd() how to print itself selftests: drv-net: gro: use cmd print selftests: drv-net: gro: improve feature config selftests: drv-net: gro: run the test against HW GRO and LRO selftests: drv-net: gro: break out all individual test cases tools/testing/selftests/drivers/net/gro.c | 399 +++++++++++--------- tools/testing/selftests/drivers/net/gro.py | 158 ++++++-- tools/testing/selftests/net/lib/py/ksft.py | 29 +- tools/testing/selftests/net/lib/py/utils.py | 23 ++ 4 files changed, 406 insertions(+), 203 deletions(-) -- 2.52.0

5 hours, 46 minutes

next-20251020: selftests: helpers.h:10:10: fatal error: kselftest.h: No such file or directory

by Naresh Kamboju

The selftests x86_64 builds failed due to following build warnings / errors on the Linux next-20251020 and next-20251021 tags with gcc-14 and clang-21. First seen on next-20251020 Good: next-20251020 Bad: next-20251017 Regression Analysis: - New regression? yes - Reproducibility? yes ### Build errors x86_64-linux-gnu-gcc -m64 -o kselftest/x86/single_step_syscall_64 -O2 -g -std=gnu99 -pthread -Wall -isystem usr/include -no-pie -DCAN_BUILD_64 single_step_syscall.c -lrt -ldl In file included from single_step_syscall.c:34: helpers.h:10:10: fatal error: kselftest.h: No such file or directory 10 | #include "kselftest.h" | ^~~~~~~~~~~~~ compilation terminated. make[4]: *** [Makefile:86: kselftest/x86/single_step_syscall_64] Error 1 ### Suspected patch git log --oneline next-20251017..next-20251020 -- tools/testing/selftests/x86/ 4d89827dfb274 selftests: complete kselftest include centralization Build regressions: next-20251020: selftests: helpers.h:10:10: fatal error: kselftest.h: No such file or directory Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> ### Steps to reproduce - tuxmake --runtime podman --target-arch x86_64 --toolchain gcc-14 \ --kconfig https://storage.tuxsuite.com/public/linaro/lkft/builds/34JgN0fZ9uXj6HVnjvjq… \ debugkernel cpupower headers kernel kselftest modules ## Source * Kernel version: 6.18.0-rc2 * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git * Git describe: next-20251021 and next-20251020 * Git commit: fe45352cd106ae41b5ad3f0066c2e54dbb2dfd70 * Architectures: x86_64 * Toolchains: gcc-14 and clang-21 * Kconfigs: defconfig+selftests/*/configs ## Build * Build log: https://storage.tuxsuite.com/public/linaro/lkft/builds/34JgN0fZ9uXj6HVnjvjq… * Build details: https://regressions.linaro.org/lkft/linux-next-master/next-20251020/kselfte… * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/34JgN0fZ9uXj6HVnjvjq… * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/34JgN0fZ9uXj6HVnjvjq… -- Linaro LKFT https://lkft.linaro.org

5 hours, 57 minutes

[PATCH v2 0/8] Various mm kselftests improvements/fixes

by Kevin Brodsky

Various improvements/fixes for the mm kselftests: - Patch 1-3 extend support for more build configurations: out-of-tree $KDIR, cross-compilation, etc. - Patch 4-6 fix issues related to faulting in pages, introducing a new helper for that purpose. - Patch 7 fixes the value returned by pagemap_ioctl (PASS was always returned, which explains why the issue fixed in patch 6 went unnoticed). - Patch 8 improves the exit code of pfnmap. Net results: - 1 test no longer fails (patch 6) - 3 tests are no longer skipped (patch 4) - More accurate return values for whole suites (patch 7, 8) - Extra tests are more likely to be built (patch 1-3) --- v1..v2: - New patches: 1, 4, 5, 8 v1: https://lore.kernel.org/all/20251216142633.2401447-1-kevin.brodsky@arm.com/ --- Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: David Hildenbrand <david(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mark Brown <broonie(a)kernel.org> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Shuah Khan <shuah(a)kernel.org> --- Kevin Brodsky (8): selftests/mm: default KDIR to build directory selftests/mm: remove flaky header check selftests/mm: pass down full CC and CFLAGS to check_config.sh selftests/mm: fix usage of FORCE_READ() in cow tests selftests/mm: introduce helper to read every page in range selftests/mm: fix faulting-in code in pagemap_ioctl test selftests/mm: fix exit code in pagemap_ioctl selftests/mm: report SKIP in pfnmap if a check fails tools/testing/selftests/mm/Makefile | 8 +- tools/testing/selftests/mm/check_config.sh | 3 +- tools/testing/selftests/mm/cow.c | 16 ++-- tools/testing/selftests/mm/hugetlb-madvise.c | 9 +- tools/testing/selftests/mm/page_frag/Makefile | 2 +- tools/testing/selftests/mm/pagemap_ioctl.c | 10 +- tools/testing/selftests/mm/pfnmap.c | 95 ++++++++++++------- .../selftests/mm/split_huge_page_test.c | 6 +- tools/testing/selftests/mm/vm_util.h | 6 ++ 9 files changed, 84 insertions(+), 71 deletions(-) base-commit: 9ace4753a5202b02191d54e9fdf7f9e3d02b85eb -- 2.51.2

5 hours, 58 minutes

[PATCH net-next 0/2] selftests: net: improve error handling in passive TFO test

by Yohei Kojima

This series improves error handling in the passive TFO test by (1) fixing a broken behavior when the child processes failed (or timed out), and (2) adding more error handlng code in the test program. The first patch fixes the behavior that the test didn't report failure even if the server or the client process exited with non-zero status. The second patch adds error handling code in the test program to improve reliability of the test. This series was split out from the following series to address the feedback from Andrew Lunn: https://lore.kernel.org/netdev/cover.1767032397.git.yk@y-koj.net/ Yohei Kojima (2): selftests: net: fix passive TFO test to fail if child processes failed selftests: net: improve error handling in passive TFO test tools/testing/selftests/net/tfo.c | 10 +++++++--- tools/testing/selftests/net/tfo_passive.sh | 13 ++++++++++++- 2 files changed, 19 insertions(+), 4 deletions(-) -- 2.52.0

7 hours, 32 minutes

Re: [PATCH 5/6] powerpc64/bpf: Support exceptions

by Christophe Leroy (CS GROUP)

Le 12/01/2026 à 07:58, adubey a écrit : > [Vous ne recevez pas souvent de courriers de adubey(a)imap.linux.ibm.com. > D?couvrez pourquoi ceci est important ? https://aka.ms/ > LearnAboutSenderIdentification ] > > On 2026-01-12 11:21, Saket Kumar Bhaskar wrote: >> On Mon, Jan 05, 2026 at 04:22:11PM +0530, adubey(a)linux.ibm.com wrote: >>> From: Abhishek Dubey <adubey(a)linux.ibm.com> >>> >>> The modified prologue/epilogue generation code now >>> enables exception-callback to use the stack frame of >>> the program marked as exception boundary, where callee >>> saved registers are stored. >>> >>> As per ppc64 ABIv2 documentation[1], r14-r31 are callee >>> saved registers. BPF programs on ppc64 already saves >>> r26-r31 registers. Saving the remaining set of callee >>> saved registers(r14-r25) is handled in the next patch. >>> >>> [1] >>> https://eur01.safelinks.protection.outlook.com/? >>> url=https%3A%2F%2Fftp.rtems.org%2Fpub%2Frtems%2Fpeople%2Fsebh%2FABI64BitOpenPOWERv1.1_16July2015_pub.pdf&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Cdecf1943ac9949608edb08de51a7f357%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639037978954052961%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uCfpmnY2bQT7yD3esp8nkyLPGfEzpK9UoCgV2sm0j80%3D&reserved=0 >>> >>> Following is exceptions selftest result on ppc64le: >>> >>> # ./test_progs -t exceptions >>> #100/1 exceptions/exception_throw_always_1:OK >>> #100/2 exceptions/exception_throw_always_2:OK >>> #100/3 exceptions/exception_throw_unwind_1:OK >>> #100/4 exceptions/exception_throw_unwind_2:OK >>> #100/5 exceptions/exception_throw_default:OK >>> #100/6 exceptions/exception_throw_default_value:OK >>> #100/7 exceptions/exception_tail_call:OK >>> #100/8 exceptions/exception_ext:OK >>> #100/9 exceptions/exception_ext_mod_cb_runtime:OK >>> #100/10 exceptions/exception_throw_subprog:OK >>> #100/11 exceptions/exception_assert_nz_gfunc:OK >>> #100/12 exceptions/exception_assert_zero_gfunc:OK >>> #100/13 exceptions/exception_assert_neg_gfunc:OK >>> #100/14 exceptions/exception_assert_pos_gfunc:OK >>> #100/15 exceptions/exception_assert_negeq_gfunc:OK >>> #100/16 exceptions/exception_assert_poseq_gfunc:OK >>> #100/17 exceptions/exception_assert_nz_gfunc_with:OK >>> #100/18 exceptions/exception_assert_zero_gfunc_with:OK >>> #100/19 exceptions/exception_assert_neg_gfunc_with:OK >>> #100/20 exceptions/exception_assert_pos_gfunc_with:OK >>> #100/21 exceptions/exception_assert_negeq_gfunc_with:OK >>> #100/22 exceptions/exception_assert_poseq_gfunc_with:OK >>> #100/23 exceptions/exception_bad_assert_nz_gfunc:OK >>> #100/24 exceptions/exception_bad_assert_zero_gfunc:OK >>> #100/25 exceptions/exception_bad_assert_neg_gfunc:OK >>> #100/26 exceptions/exception_bad_assert_pos_gfunc:OK >>> #100/27 exceptions/exception_bad_assert_negeq_gfunc:OK >>> #100/28 exceptions/exception_bad_assert_poseq_gfunc:OK >>> #100/29 exceptions/exception_bad_assert_nz_gfunc_with:OK >>> #100/30 exceptions/exception_bad_assert_zero_gfunc_with:OK >>> #100/31 exceptions/exception_bad_assert_neg_gfunc_with:OK >>> #100/32 exceptions/exception_bad_assert_pos_gfunc_with:OK >>> #100/33 exceptions/exception_bad_assert_negeq_gfunc_with:OK >>> #100/34 exceptions/exception_bad_assert_poseq_gfunc_with:OK >>> #100/35 exceptions/exception_assert_range:OK >>> #100/36 exceptions/exception_assert_range_with:OK >>> #100/37 exceptions/exception_bad_assert_range:OK >>> #100/38 exceptions/exception_bad_assert_range_with:OK >>> #100/39 exceptions/non-throwing fentry -> exception_cb:OK >>> #100/40 exceptions/throwing fentry -> exception_cb:OK >>> #100/41 exceptions/non-throwing fexit -> exception_cb:OK >>> #100/42 exceptions/throwing fexit -> exception_cb:OK >>> #100/43 exceptions/throwing extension (with custom cb) -> >>> exception_cb:OK >>> #100/44 exceptions/throwing extension -> global func in >>> exception_cb:OK >>> #100/45 exceptions/exception_ext_mod_cb_runtime:OK >>> #100/46 exceptions/throwing extension (with custom cb) -> global func >>> in exception_cb:OK >>> #100/47 exceptions/exception_ext:OK >>> #100/48 exceptions/non-throwing fentry -> non-throwing subprog:OK >>> #100/49 exceptions/throwing fentry -> non-throwing subprog:OK >>> #100/50 exceptions/non-throwing fentry -> throwing subprog:OK >>> #100/51 exceptions/throwing fentry -> throwing subprog:OK >>> #100/52 exceptions/non-throwing fexit -> non-throwing subprog:OK >>> #100/53 exceptions/throwing fexit -> non-throwing subprog:OK >>> #100/54 exceptions/non-throwing fexit -> throwing subprog:OK >>> #100/55 exceptions/throwing fexit -> throwing subprog:OK >>> #100/56 exceptions/non-throwing fmod_ret -> non-throwing subprog:OK >>> #100/57 exceptions/non-throwing fmod_ret -> non-throwing global >>> subprog:OK >>> #100/58 exceptions/non-throwing extension -> non-throwing subprog:OK >>> #100/59 exceptions/non-throwing extension -> throwing subprog:OK >>> #100/60 exceptions/non-throwing extension -> non-throwing subprog:OK >>> #100/61 exceptions/non-throwing extension -> throwing global >>> subprog:OK >>> #100/62 exceptions/throwing extension -> throwing global subprog:OK >>> #100/63 exceptions/throwing extension -> non-throwing global >>> subprog:OK >>> #100/64 exceptions/non-throwing extension -> main subprog:OK >>> #100/65 exceptions/throwing extension -> main subprog:OK >>> #100/66 exceptions/reject_exception_cb_type_1:OK >>> #100/67 exceptions/reject_exception_cb_type_2:OK >>> #100/68 exceptions/reject_exception_cb_type_3:OK >>> #100/69 exceptions/reject_exception_cb_type_4:OK >>> #100/70 exceptions/reject_async_callback_throw:OK >>> #100/71 exceptions/reject_with_lock:OK >>> #100/72 exceptions/reject_subprog_with_lock:OK >>> #100/73 exceptions/reject_with_rcu_read_lock:OK >>> #100/74 exceptions/reject_subprog_with_rcu_read_lock:OK >>> #100/75 exceptions/reject_with_rbtree_add_throw:OK >>> #100/76 exceptions/reject_with_reference:OK >>> #100/77 exceptions/reject_with_cb_reference:OK >>> #100/78 exceptions/reject_with_cb:OK >>> #100/79 exceptions/reject_with_subprog_reference:OK >>> #100/80 exceptions/reject_throwing_exception_cb:OK >>> #100/81 exceptions/reject_exception_cb_call_global_func:OK >>> #100/82 exceptions/reject_exception_cb_call_static_func:OK >>> #100/83 exceptions/reject_multiple_exception_cb:OK >>> #100/84 exceptions/reject_exception_throw_cb:OK >>> #100/85 exceptions/reject_exception_throw_cb_diff:OK >>> #100/86 exceptions/reject_set_exception_cb_bad_ret1:OK >>> #100/87 exceptions/reject_set_exception_cb_bad_ret2:OK >>> #100/88 exceptions/check_assert_eq_int_min:OK >>> #100/89 exceptions/check_assert_eq_int_max:OK >>> #100/90 exceptions/check_assert_eq_zero:OK >>> #100/91 exceptions/check_assert_eq_llong_min:OK >>> #100/92 exceptions/check_assert_eq_llong_max:OK >>> #100/93 exceptions/check_assert_lt_pos:OK >>> #100/94 exceptions/check_assert_lt_zero:OK >>> #100/95 exceptions/check_assert_lt_neg:OK >>> #100/96 exceptions/check_assert_le_pos:OK >>> #100/97 exceptions/check_assert_le_zero:OK >>> #100/98 exceptions/check_assert_le_neg:OK >>> #100/99 exceptions/check_assert_gt_pos:OK >>> #100/100 exceptions/check_assert_gt_zero:OK >>> #100/101 exceptions/check_assert_gt_neg:OK >>> #100/102 exceptions/check_assert_ge_pos:OK >>> #100/103 exceptions/check_assert_ge_zero:OK >>> #100/104 exceptions/check_assert_ge_neg:OK >>> #100/105 exceptions/check_assert_range_s64:OK >>> #100/106 exceptions/check_assert_range_u64:OK >>> #100/107 exceptions/check_assert_single_range_s64:OK >>> #100/108 exceptions/check_assert_single_range_u64:OK >>> #100/109 exceptions/check_assert_generic:OK >>> #100/110 exceptions/check_assert_with_return:OK >>> #100 exceptions:OK >>> Summary: 1/110 PASSED, 0 SKIPPED, 0 FAILED >>> >> It would be great to include this selftest output in the cover letter >> instead, since it makes the git log excessively long. >> >> Thanks, >> Saket > > Major contributors in the community routinely include test case results > in commit messages, and this is not viewed as problematic. > Eg: bpf-next : e59997d9052599feb17419289f2a57ed300e1dfa, This is a merge commit, the message comes from the cover letter of the series: https://lore.kernel.org/all/20240201125225.72796-1-puranjay12@gmail.com/ > 6c17a882d3804dce1c66e1fec25f96d39a184067 In this one the list of tests is rather small compared to the entire commit message. So I also recommend to move this big list of tests in the cover letter. Christophe

9 hours, 4 minutes

[PATCH 0/6] powerpc64/bpf: Support tailcalls with subprogs & BPF exceptions

by adubey＠linux.ibm.com

From: Abhishek Dubey <adubey(a)linux.ibm.com> This patch series enables support for two BPF JIT features on powerpc64. The first three patches target support for tail calls with subprogram combinations. The third patch includes an optimization in which NVRs are accommodated in the stack save area of the trampoline frame. Implementation details are provided in the commit messages. The last three patches add support for BPF exceptions. An architecture-specific stack walker is implemented to assist with stack walk during exceptions. BPF selftest results and implementation details are presented in the corresponding commits. Abhishek Dubey (6): powerpc64/bpf: Support tailcalls with subprogs powerpc64/bpf: Tailcall handling with trampolines powerpc/bpf: use BPF_PPC_STACK_SAVE to spill trampoline NVRs powerpc64/bpf: Add arch_bpf_stack_walk() for BPF JIT powerpc64/bpf: Support exceptions powerpc64/bpf: Additional NVR handling for bpf_throw arch/powerpc/net/bpf_jit.h | 16 ++- arch/powerpc/net/bpf_jit_comp.c | 90 +++++++++---- arch/powerpc/net/bpf_jit_comp64.c | 214 ++++++++++++++++++++++++------ 3 files changed, 256 insertions(+), 64 deletions(-) -- 2.48.1

10 hours, 33 minutes

[PATCH] kunit: tool: suppress confusing error output in test

by Jinseok Kim

When running kunit_tool_test.py, the test_run_raw_output_invalid test prints invalid usage text and error messages to stderr. This happens because the test triggers kunit.main() with an invalid argument, causing argparse to print the usage and exit. This output is confusing to the user because it looks like a test failure or usage error, even though the test passed successfully. Furthermore, argparse displays 'usage: kunit_tool_test.py run ...', which is misleading since the test script itself does not accept the 'run' command. This patch mocks sys.stderr in the test to suppress this expected error output, making the test execution output cleaner. Signed-off-by: Jinseok Kim <always.starving0(a)gmail.com> --- tools/testing/kunit/kunit_tool_test.py | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/kunit/kunit_tool_test.py b/tools/testing/kunit/kunit_tool_test.py index bbba921e0eac..7a8ba8e4f1d4 100755 --- a/tools/testing/kunit/kunit_tool_test.py +++ b/tools/testing/kunit/kunit_tool_test.py @@ -8,6 +8,7 @@ import unittest from unittest import mock +import io import tempfile, shutil # Handling test_tmpdir @@ -688,8 +689,9 @@ class KUnitMainTest(unittest.TestCase): def test_run_raw_output_invalid(self): self.linux_source_mock.run_kernel = mock.Mock(return_value=[]) - with self.assertRaises(SystemExit) as e: - kunit.main(['run', '--raw_output=invalid']) + with mock.patch('sys.stderr', new=io.StringIO()): + with self.assertRaises(SystemExit) as e: + kunit.main(['run', '--raw_output=invalid']) self.assertNotEqual(e.exception.code, 0) def test_run_raw_output_does_not_take_positional_args(self): -- 2.43.0

12 hours, 11 minutes

[PATCH cgroup/for-6.20 v3 0/5] cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict

by Waiman Long

v3: - Patch 2: Change the condition for calling reset_partition_data() to (new_prs <= 0). - Patch 4: Update commit log and code comment to clarify the change. - Add a new patch 5 to move the empty cpus/mems check to cpuset1_validate_change(). v2: - Patch 1: additional comment - Patch 2: simplify the conditions for triggering call to compute_excpus(). - Patch 3: update description of cpuset.cpus.exclusive in cgroup-v2.rst to reflect the new behavior and change the name of the new cpus_excl_conflict() parameter to xcpus_changed. - Patch 4: update description of cpuset.cpus.partition in cgroup-v2.rst to clarify what exclusive CPUs will be used when a partition is created. This patch series is inspired by the cpuset patch sent by Sun Shaojie [1]. The idea is to avoid invalidating sibling partitions when there is a cpuset.cpus conflict. However this patch series does it in a slightly different way to make its behavior more consistent with other cpuset properties. The first 3 patches are just some cleanup and minor bug fixes on issues found during the investigation process. The last one is the major patch that changes the way cpuset.cpus is being handled during the partition creation process. Instead of invalidating sibling partitions when there is a conflict, it will strip out the conflicting exclusive CPUs and assign the remaining non-conflicting exclusive CPUs to the new partition unless there is no more CPU left which will fail the partition creation process. It is similar to the idea that cpuset.cpus.effective may only contain a subset of CPUs specified in cpuset.cpus. So cpuset.cpus.exclusive.effective may contain only a subset of cpuset.cpus when a partition is created without setting cpuset.cpus.exclusive. Even setting cpuset.cpus.exclusive instead of cpuset.cpus may not guarantee all the requested CPUs can be granted if parent doesn't have access to some of those exclusive CPUs. The difference is that conflicts from siblings is not possible with cpuset.cpus.exclusive as long as it can be set successfully without failure. [1] https://lore.kernel.org/lkml/20251117015708.977585-1-sunshaojie@kylinos.cn/ Waiman Long (5): cgroup/cpuset: Streamline rm_siblings_excl_cpus() cgroup/cpuset: Consistently compute effective_xcpus in update_cpumasks_hier() cgroup/cpuset: Don't fail cpuset.cpus change in v2 cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict cgroup/cpuset: Move the v1 empty cpus/mems check to cpuset1_validate_change() Documentation/admin-guide/cgroup-v2.rst | 40 +++-- kernel/cgroup/cpuset-internal.h | 12 ++ kernel/cgroup/cpuset-v1.c | 33 ++++ kernel/cgroup/cpuset.c | 163 ++++++------------ .../selftests/cgroup/test_cpuset_prs.sh | 29 +++- 5 files changed, 150 insertions(+), 127 deletions(-) -- 2.52.0

12 hours, 20 minutes

[cgroup/for-6.20 PATCH v2 0/4] cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict

by Waiman Long

v2: - Patch 1: additional comment - Patch 2: simplify the conditions for triggering call to compute_excpus(). - Patch 3: update description of cpuset.cpus.exclusive in cgroup-v2.rst to reflect the new behavior and change the name of the new cpus_excl_conflict() parameter to xcpus_changed. - Patch 4: update description of cpuset.cpus.partition in cgroup-v2.rst to clarify what exclusive CPUs will be used when a partition is created. This patch series is inspired by the cpuset patch sent by Sun Shaojie [1]. The idea is to avoid invalidating sibling partitions when there is a cpuset.cpus conflict. However this patch series does it in a slightly different way to make its behavior more consistent with other cpuset properties. The first 3 patches are just some cleanup and minor bug fixes on issues found during the investigation process. The last one is the major patch that changes the way cpuset.cpus is being handled during the partition creation process. Instead of invalidating sibling partitions when there is a conflict, it will strip out the conflicting exclusive CPUs and assign the remaining non-conflicting exclusive CPUs to the new partition unless there is no more CPU left which will fail the partition creation process. It is similar to the idea that cpuset.cpus.effective may only contain a subset of CPUs specified in cpuset.cpus. So cpuset.cpus.exclusive.effective may contain only a subset of cpuset.cpus when a partition is created without setting cpuset.cpus.exclusive. Even setting cpuset.cpus.exclusive instead of cpuset.cpus may not guarantee all the requested CPUs can be granted if parent doesn't have access to some of those exclusive CPUs. The difference is that conflicts from siblings is not possible with cpuset.cpus.exclusive as long as it can be set successfully without failure. [1] https://lore.kernel.org/lkml/20251117015708.977585-1-sunshaojie@kylinos.cn/ Waiman Long (4): cgroup/cpuset: Streamline rm_siblings_excl_cpus() cgroup/cpuset: Consistently compute effective_xcpus in update_cpumasks_hier() cgroup/cpuset: Don't fail cpuset.cpus change in v2 cgroup/cpuset: Don't invalidate sibling partitions on cpuset.cpus conflict Documentation/admin-guide/cgroup-v2.rst | 40 +++-- kernel/cgroup/cpuset-internal.h | 3 + kernel/cgroup/cpuset-v1.c | 19 +++ kernel/cgroup/cpuset.c | 141 +++++++----------- .../selftests/cgroup/test_cpuset_prs.sh | 26 +++- 5 files changed, 125 insertions(+), 104 deletions(-) -- 2.52.0

15 hours, 13 minutes

[PATCH] selftests/x86: clean up sysret_rip coding style

by neogulmanpassingby

Tidy up sysret_rip style (cast spacing, main(void), const placement). No functional change intended. Signed-off-by: neogulmanpassingby <jouyeol8739(a)gmail.com> --- tools/testing/selftests/x86/sysret_rip.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/tools/testing/selftests/x86/sysret_rip.c b/tools/testing/selftests/x86/sysret_rip.c index 5fb531e3ad7c..2e423a335e1c 100644 --- a/tools/testing/selftests/x86/sysret_rip.c +++ b/tools/testing/selftests/x86/sysret_rip.c @@ -31,7 +31,7 @@ void test_syscall_ins(void); extern const char test_page[]; -static void const *current_test_page_addr = test_page; +static const void *current_test_page_addr = test_page; /* State used by our signal handlers. */ static gregset_t initial_regs; @@ -40,7 +40,7 @@ static volatile unsigned long rip; static void sigsegv_for_sigreturn_test(int sig, siginfo_t *info, void *ctx_void) { - ucontext_t *ctx = (ucontext_t*)ctx_void; + ucontext_t *ctx = (ucontext_t *)ctx_void; if (rip != ctx->uc_mcontext.gregs[REG_RIP]) { printf("[FAIL]\tRequested RIP=0x%lx but got RIP=0x%lx\n", @@ -56,7 +56,7 @@ static void sigsegv_for_sigreturn_test(int sig, siginfo_t *info, void *ctx_void) static void sigusr1(int sig, siginfo_t *info, void *ctx_void) { - ucontext_t *ctx = (ucontext_t*)ctx_void; + ucontext_t *ctx = (ucontext_t *)ctx_void; memcpy(&initial_regs, &ctx->uc_mcontext.gregs, sizeof(gregset_t)); @@ -69,8 +69,6 @@ static void sigusr1(int sig, siginfo_t *info, void *ctx_void) ctx->uc_mcontext.gregs[REG_R11]); sethandler(SIGSEGV, sigsegv_for_sigreturn_test, SA_RESETHAND); - - return; } static void test_sigreturn_to(unsigned long ip) @@ -84,7 +82,7 @@ static jmp_buf jmpbuf; static void sigsegv_for_fallthrough(int sig, siginfo_t *info, void *ctx_void) { - ucontext_t *ctx = (ucontext_t*)ctx_void; + ucontext_t *ctx = (ucontext_t *)ctx_void; if (rip != ctx->uc_mcontext.gregs[REG_RIP]) { printf("[FAIL]\tExpected SIGSEGV at 0x%lx but got RIP=0x%lx\n", @@ -130,7 +128,7 @@ static void test_syscall_fallthrough_to(unsigned long ip) printf("[OK]\tWe survived\n"); } -int main() +int main(void) { /* * When the kernel returns from a slow-path syscall, it will -- 2.43.0

19 hours, 23 minutes

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror