July 2023 - Linux-kselftest-mirror

by Matthieu Baerts

Here is a first batch of fixes for v6.5 and older. The fixes are not linked to each others. Patch 1 ensures subflows are unhashed before cleaning the backlog to avoid races. This fixes another recent fix from v6.4. Patch 2 does not rely on implicit state check in mptcp_listen() to avoid races when receiving an MP_FASTCLOSE. A regression from v5.17. The rest fixes issues in the selftests. Patch 3 makes sure errors when setting up the environment are no longer ignored. For v5.17+. Patch 4 uses 'iptables-legacy' if available to be able to run on older kernels. A fix for v5.13 and newer. Patch 5 catches errors when issues are detected with packet marks. Also for v5.13+. Patch 6 uses the correct variable instead of an undefined one. Even if there was no visible impact, it can help to find regressions later. An issue visible in v5.19+. Patch 7 makes sure errors with some sub-tests are reported to have the selftest marked as failed as expected. Also for v5.19+. Patch 8 adds a kernel config that is required to execute MPTCP selftests. It is valid for v5.9+. Patch 9 fixes issues when validating the userspace path-manager with 32-bit arch, an issue affecting v5.19+. Signed-off-by: Matthieu Baerts <matthieu.baerts(a)tessares.net> --- Matthieu Baerts (7): selftests: mptcp: connect: fail if nft supposed to work selftests: mptcp: sockopt: use 'iptables-legacy' if available selftests: mptcp: sockopt: return error if wrong mark selftests: mptcp: userspace_pm: use correct server port selftests: mptcp: userspace_pm: report errors with 'remove' tests selftests: mptcp: depend on SYN_COOKIES selftests: mptcp: pm_nl_ctl: fix 32-bit support Paolo Abeni (2): mptcp: ensure subflow is unhashed before cleaning the backlog mptcp: do not rely on implicit state check in mptcp_listen() net/mptcp/protocol.c | 7 +++++- tools/testing/selftests/net/mptcp/config | 1 + tools/testing/selftests/net/mptcp/mptcp_connect.sh | 3 +++ tools/testing/selftests/net/mptcp/mptcp_sockopt.sh | 29 ++++++++++++---------- tools/testing/selftests/net/mptcp/pm_nl_ctl.c | 10 ++++---- tools/testing/selftests/net/mptcp/userspace_pm.sh | 4 ++- 6 files changed, 34 insertions(+), 20 deletions(-) --- base-commit: 14bb236b29922c4f57d8c05bfdbcb82677f917c9 change-id: 20230704-upstream-net-20230704-misc-fixes-6-5-rc1-c52608649559 Best regards, -- Matthieu Baerts <matthieu.baerts(a)tessares.net>

1 year, 2 months

2
10
0 0

[PATCH v2 0/2] mm/memfd: fix sysctl MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)google.com> When sysctl vm.memfd_noexec is 2 (MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED), memfd_create(.., MFD_EXEC) should fail. This complies with how MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED is defined - "memfd_create() without MFD_NOEXEC_SEAL will be rejected" Thanks to Dominique Martinet <asmadeus(a)codewreck.org> who reported the bug. see [1] for context. [1] https://lore.kernel.org/linux-mm/CABi2SkXUX_QqTQ10Yx9bBUGpN1wByOi_=gZU6WEy5… History: V2: fix build error when CONFIG_SYSCTL is not defined. V1: initial version https://lore.kernel.org/linux-mm/20230630031721.623955-3-jeffxu@google.com/… Jeff Xu (2): mm/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED selftests/memfd: sysctl: fix MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED mm/memfd.c | 57 +++++++++++++--------- tools/testing/selftests/memfd/memfd_test.c | 5 ++ 2 files changed, 38 insertions(+), 24 deletions(-) -- 2.41.0.255.g8b1d071c50-goog

1 year, 2 months

1
2
0 0

Loan/Investment offer.

by Frank Dawson

Hello. I am Frank Jody Dawson, I have investors and they are seeking to invest in any lucrative venture worldwide, like aviation, real estate, agriculture, industrial, medical equipment and renewable energy. My investors are mainly from the Arabian countries who are widely in real estate and oil and gas, but now they want to expand their businesses across the globe in any lucrative business. Your profile caught my attention so I decided to message and see if we can work together? Thank you, Frank.

1 year, 2 months

1
0
0 0

[PATCH 0/2] bpf, net: Allow setting SO_TIMESTAMPING* from BPF

by Jörn-Thorben Hinz

BPF applications, e.g., a TCP congestion control, might benefit from precise packet timestamps. These timestamps are already available in __sk_buff and bpf_sock_ops, but could not be requested: A BPF program was not allowed to set SO_TIMESTAMPING* on a socket. This change enables BPF programs to actively request the generation of timestamps from a stream socket. To reuse the setget_sockopt BPF prog test for bpf_{get,set}sockopt(SO_TIMESTAMPING_NEW), also implement the missing getsockopt(SO_TIMESTAMPING_NEW) in the network stack. I reckon the way I added getsockopt(SO_TIMESTAMPING_NEW) causes an API change: For existing users that set SO_TIMESTAMPING_NEW but queried SO_TIMESTAMPING_OLD afterwards, it would now look as if no timestamping flags have been set. Is this an acceptable change? If not, I’m happy to change getsockopt() to only be strict about the newly-implemented getsockopt(SO_TIMESTAMPING_NEW), or not distinguish between SO_TIMESTAMPING_NEW and SO_TIMESTAMPING_OLD at all. Jörn-Thorben Hinz (2): net: Implement missing getsockopt(SO_TIMESTAMPING_NEW) bpf: Allow setting SO_TIMESTAMPING* with bpf_setsockopt() include/uapi/linux/bpf.h | 3 ++- net/core/filter.c | 2 ++ net/core/sock.c | 9 +++++++-- tools/include/uapi/linux/bpf.h | 3 ++- tools/testing/selftests/bpf/progs/bpf_tracing_net.h | 2 ++ tools/testing/selftests/bpf/progs/setget_sockopt.c | 4 ++++ 6 files changed, 19 insertions(+), 4 deletions(-) -- 2.39.2

1 year, 2 months

4
6
0 0

[linux-next:master] BUILD REGRESSION 1c6f93977947dbba1fc4d250c4eb8a7d4cfdecf1

by kernel test robot

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 1c6f93977947dbba1fc4d250c4eb8a7d4cfdecf1 Add linux-next specific files for 20230704 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202306260401.qZlYQpV2-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202306301709.lvrxzyCj-lkp@intel.com https://lore.kernel.org/oe-kbuild-all/202306301756.x8dgyYnL-lkp@intel.com Error/Warning: (recently discovered and may have been fixed) drivers/bluetooth/btmtk.c:386:32: error: no member named 'dump' in 'struct hci_dev' drivers/bluetooth/btmtk.c:386:44: error: 'struct hci_dev' has no member named 'dump' drivers/char/mem.c:164:25: error: implicit declaration of function 'unxlate_dev_mem_ptr'; did you mean 'xlate_dev_mem_ptr'? [-Werror=implicit-function-declaration] drivers/mfd/max77541.c:176:18: warning: cast to smaller integer type 'enum max7754x_ids' from 'const void *' [-Wvoid-pointer-to-enum-cast] lib/kunit/executor_test.c:138:4: warning: cast from 'void (*)(const void *)' to 'kunit_action_t *' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict] lib/kunit/test.c:775:38: warning: cast from 'void (*)(const void *)' to 'kunit_action_t *' (aka 'void (*)(void *)') converts to incompatible function type [-Wcast-function-type-strict] Unverified Error/Warning (likely false positive, please contact us if interested): drivers/vhost/vhost.c:1654 vhost_vring_ioctl() error: uninitialized symbol 'vq'. drivers/vhost/vhost.c:1685 vhost_vring_ioctl() error: uninitialized symbol 'idx'. drivers/vhost/vhost.c:763 vhost_worker_ioctl() error: uninitialized symbol 'vq'. drivers/vhost/vhost.c:774 vhost_worker_ioctl() error: uninitialized symbol 'idx'. {standard input}: Error: local label `"2" (instance number 9 of a fb label)' is not defined Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-randconfig-r002-20230704 | `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump |-- loongarch-randconfig-r022-20230704 | `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump |-- m68k-randconfig-r016-20230704 | `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump |-- microblaze-randconfig-r073-20230703 | `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump |-- nios2-randconfig-r034-20230704 | `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump |-- riscv-randconfig-m031-20230703 | |-- drivers-vhost-vhost.c-vhost_vring_ioctl()-error:uninitialized-symbol-idx-. | |-- drivers-vhost-vhost.c-vhost_vring_ioctl()-error:uninitialized-symbol-vq-. | |-- drivers-vhost-vhost.c-vhost_worker_ioctl()-error:uninitialized-symbol-idx-. | `-- drivers-vhost-vhost.c-vhost_worker_ioctl()-error:uninitialized-symbol-vq-. |-- sh-allmodconfig | |-- drivers-char-mem.c:error:implicit-declaration-of-function-unxlate_dev_mem_ptr | `-- standard-input:Error:local-label-(instance-number-of-a-fb-label)-is-not-defined |-- sh-randconfig-r015-20230704 | |-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump | `-- drivers-char-mem.c:error:implicit-declaration-of-function-unxlate_dev_mem_ptr |-- sh-sh7710voipgw_defconfig | `-- drivers-char-mem.c:error:implicit-declaration-of-function-unxlate_dev_mem_ptr |-- sparc-randconfig-r005-20230704 | `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump `-- x86_64-buildonly-randconfig-r003-20230703 `-- drivers-bluetooth-btmtk.c:error:struct-hci_dev-has-no-member-named-dump clang_recent_errors |-- arm64-randconfig-r033-20230704 | `-- drivers-mfd-max77541.c:warning:cast-to-smaller-integer-type-enum-max7754x_ids-from-const-void |-- hexagon-randconfig-r041-20230703 | |-- drivers-bluetooth-btmtk.c:error:no-member-named-dump-in-struct-hci_dev | |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type |-- hexagon-randconfig-r045-20230703 | |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type | `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type |-- i386-randconfig-i011-20230703 | `-- drivers-bluetooth-btmtk.c:error:no-member-named-dump-in-struct-hci_dev `-- s390-randconfig-r006-20230704 |-- lib-kunit-executor_test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type `-- lib-kunit-test.c:warning:cast-from-void-(-)(const-void-)-to-kunit_action_t-(aka-void-(-)(void-)-)-converts-to-incompatible-function-type elapsed time: 734m configs tested: 148 configs skipped: 9 tested configs: alpha allyesconfig gcc alpha defconfig gcc alpha randconfig-r002-20230704 gcc alpha randconfig-r003-20230704 gcc alpha randconfig-r004-20230704 gcc alpha randconfig-r023-20230703 gcc alpha randconfig-r035-20230704 gcc arc alldefconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-r021-20230704 gcc arc randconfig-r043-20230703 gcc arm allmodconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-r002-20230704 gcc arm randconfig-r014-20230704 clang arm randconfig-r026-20230703 gcc arm randconfig-r032-20230704 gcc arm randconfig-r046-20230703 gcc arm s3c6400_defconfig gcc arm s5pv210_defconfig clang arm u8500_defconfig gcc arm64 allyesconfig gcc arm64 defconfig gcc arm64 randconfig-r033-20230704 clang csky alldefconfig gcc csky defconfig gcc csky randconfig-r022-20230703 gcc hexagon randconfig-r033-20230704 clang hexagon randconfig-r041-20230703 clang hexagon randconfig-r045-20230703 clang i386 allyesconfig gcc i386 buildonly-randconfig-r004-20230703 gcc i386 buildonly-randconfig-r005-20230703 gcc i386 buildonly-randconfig-r006-20230703 gcc i386 debian-10.3 gcc i386 defconfig gcc i386 randconfig-i001-20230704 clang i386 randconfig-i002-20230704 clang i386 randconfig-i003-20230704 clang i386 randconfig-i004-20230704 clang i386 randconfig-i005-20230704 clang i386 randconfig-i006-20230704 clang i386 randconfig-i011-20230703 clang i386 randconfig-i012-20230703 clang i386 randconfig-i013-20230703 clang i386 randconfig-i014-20230703 clang i386 randconfig-i015-20230703 clang i386 randconfig-i016-20230703 clang i386 randconfig-r005-20230704 clang i386 randconfig-r032-20230704 clang loongarch allmodconfig gcc loongarch allnoconfig gcc loongarch defconfig gcc loongarch randconfig-r022-20230704 gcc m68k allmodconfig gcc m68k allyesconfig gcc m68k defconfig gcc m68k randconfig-r016-20230704 gcc microblaze randconfig-r011-20230704 gcc microblaze randconfig-r015-20230704 gcc microblaze randconfig-r023-20230704 gcc mips allmodconfig gcc mips allyesconfig gcc mips ci20_defconfig gcc mips decstation_defconfig gcc mips decstation_r4k_defconfig gcc mips maltaup_defconfig clang mips mtx1_defconfig clang mips qi_lb60_defconfig clang mips randconfig-r013-20230704 clang mips randconfig-r031-20230704 gcc nios2 defconfig gcc nios2 randconfig-r004-20230704 gcc nios2 randconfig-r006-20230704 gcc nios2 randconfig-r012-20230704 gcc nios2 randconfig-r034-20230704 gcc openrisc alldefconfig gcc openrisc or1klitex_defconfig gcc openrisc randconfig-r014-20230704 gcc parisc allyesconfig gcc parisc defconfig gcc parisc randconfig-r001-20230704 gcc parisc randconfig-r012-20230704 gcc parisc64 defconfig gcc powerpc allmodconfig gcc powerpc allnoconfig gcc powerpc microwatt_defconfig clang powerpc randconfig-r001-20230704 clang powerpc randconfig-r011-20230704 gcc powerpc tqm8560_defconfig clang riscv allmodconfig gcc riscv allnoconfig gcc riscv allyesconfig gcc riscv defconfig gcc riscv randconfig-r024-20230704 gcc riscv randconfig-r042-20230703 clang riscv rv32_defconfig gcc s390 randconfig-r006-20230704 clang s390 randconfig-r044-20230703 clang sh allmodconfig gcc sh randconfig-r015-20230704 gcc sh randconfig-r026-20230704 gcc sh rts7751r2dplus_defconfig gcc sh sdk7786_defconfig gcc sh se7750_defconfig gcc sh sh7710voipgw_defconfig gcc sh shx3_defconfig gcc sparc allyesconfig gcc sparc defconfig gcc sparc randconfig-r005-20230704 gcc sparc randconfig-r036-20230704 gcc sparc64 defconfig gcc sparc64 randconfig-r016-20230704 gcc sparc64 randconfig-r024-20230703 gcc sparc64 randconfig-r035-20230704 gcc um alldefconfig gcc um allmodconfig clang um allnoconfig clang um allyesconfig clang um defconfig gcc um i386_defconfig gcc um randconfig-r025-20230704 clang um randconfig-r031-20230704 gcc um randconfig-r034-20230704 gcc um x86_64_defconfig gcc x86_64 allyesconfig gcc x86_64 buildonly-randconfig-r001-20230703 gcc x86_64 buildonly-randconfig-r002-20230703 gcc x86_64 buildonly-randconfig-r003-20230703 gcc x86_64 defconfig gcc x86_64 kexec gcc x86_64 randconfig-x001-20230703 clang x86_64 randconfig-x002-20230703 clang x86_64 randconfig-x003-20230703 clang x86_64 randconfig-x004-20230703 clang x86_64 randconfig-x005-20230703 clang x86_64 randconfig-x006-20230703 clang x86_64 randconfig-x011-20230703 gcc x86_64 randconfig-x012-20230703 gcc x86_64 randconfig-x013-20230703 gcc x86_64 randconfig-x014-20230703 gcc x86_64 randconfig-x015-20230703 gcc x86_64 randconfig-x016-20230703 gcc x86_64 rhel-8.3-rust clang x86_64 rhel-8.3 gcc xtensa common_defconfig gcc -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 year, 2 months

1
0
0 0

Tests documentation

by Mauro Carvalho Chehab

Hi Jon, Shuah & others, I'd like to discuss with you with regards to test documentation. I had some preliminary discussions with people interested on improving tests during EOSS last week in Prague, as we're working to improve media test coverage as well. During such discussions, I talked with developers from several companies that have been collaboration and/or using Kernel CI. I also talked with Nikolai from Red Hat, who gave a presentation about Kernel CI, which points that one of the areas to be improved there is documentation. So, it seems it is worth having some discussions about how to improve Kernel test documentation. While kernel_doc does a pretty decent job documenting functions and data structures, for tests, the most important things to be documented are: a. what the tests do; b. what functionalities they are testing. This is a lot more important than documenting functions - and the used data structures on tests are typically the ones that are part of the driver's kAPI or uAPI, so they should be documented somewhere else. Usually, (b) is not so simple, as, at least for complex hardware, the tested features are grouped on an hierarchical way, like: 1. hardware 1.1 DMA engine 1.2 output ports ... 2. firmware 2.1 firmware load 2.2 firmware DMA actions ... 3. kernel features 3.1 memory allocation 3.2 mmap 3.3 bind/unbind ... CI engines running the test sets usually want to produce a report that will be providing pass rates for the tested features and functionalites that are available at the driver's and their respective hardware and firmware. I've doing some work at the tool we use to test DRM code [1] in order to have a decent documentation of the tests we have hosted there, focusing mostly on tests for i915 and Xe Intel drivers, also covering documentation for DRM core tests - while providing support for other vendors to also improve their test documentation for IGT - IGT GPU tools and tests. The documentation tool I developed is generic enough to be used for other test sets and I believe it could be useful as well to document Kselftest and KUnit. The core of the tool (at test_list.py) is a Python class, with some callers (igt_doc.py, xls_to_doc.py, doc_to_xls.py), being extensible enough to also have other callers to integrate with external tools. We are developing internally one to integrate with our internal Grafana reports to report the pass rate per documented feature, in an hierarchical way. Something similar to: 1. hardware pass rate: 98% (98 tests passed of 100) 1.1 DMA engine pass rate: 80% (8 tests passed of 10) 1.2 output ports pass rate: 100% (10 tests passed of 10) ... It is based on the concept that test documentation should be placed as close as possible to the actual code implementing the test sets. It was also be developed in a way that the documentation grouping is flexible. The code was written from the scratch in Python and was implemented inside a class that can also be re-used to do do other nice things, like importing/exporting test documentation to spreadsheets and integration with other tools (like Grafana). The actual documentation tags look like this: /** * TEST: Check if new IGT test documentation logic functionality is working * Category: Software build block * Sub-category: documentation * Functionality: test documentation * Issue: none * Description: Complete description of this test * * SUBTEST: foo * Description: do foo things * description continuing on another line * * SUBTEST: bar * Description: do bar things * description continuing on another line * Functionality: bar test doc */ And it has support for wildcards. There, "TEST" is associated to the contents of the file, while "SUBTEST" refers to each specific subtest inside it. The valid fields are imported from JSON config files, and can be placed into an hierarchical way, in order to produce an hierarchical documentation. Fields defined at the "TEST" level are imported on "SUBTEST", but can be overriden. The JSON config file looks like this: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/blob/158feaa20fa2b9424ee… The output is in ReST, which can be generated in hierarchical or per-file way. The hierarchical output looks like this: $ ./scripts/igt_doc.py --config tests/xe/xe_test_config.json --file fubar_tests.c =============================== Implemented Tests for Xe Driver =============================== Category: Software build block ============================== Sub-category: documentation --------------------------- Functionality: bar test doc ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``igt@fubar_tests@bar`` :Description: do bar things description continuing on another line :Issue: none Functionality: test documentation ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ``igt@fubar_tests@foo`` :Description: do foo things description continuing on another line :Issue: none (if --file is not used, it will use all C files specified at the configuration) The tool already skips tags like the ones used by kernel-doc[1], so one could have both function documentation and per-test documentation on the same file, if needed. While such tool was conceived to be part of IGT, it doesn't have anything specific for it [2], and I do believe it would be a great contribution to the Kernel to have such tool upstreamed, and integrated as a Sphinx extension. If we decide to go ahead adding it, I can work on a patchset to apply it to the Kernel, modifying the scripts to better fit at the Kernel needs and start with some documentation examples for i915, DRM core and upcoming Xe KUnit tests. Comments? Regards, Mauro [1] It should be trivial to patch kernel-doc for it to skip TEST and SUBTEST tags if we decide to integrate it to the kernel. [2] except that tests there are named after IGT, as <igt <test>@<subtest>@<dynamic_subtest>, but a change to a Kernel-specific namespace would be trivial

1 year, 2 months

3
2
0 0

Re: [tip: x86/misc] x86/csum: Improve performance of `csum_partial`

by Geert Uytterhoeven

Hi Noah, On Thu, May 25, 2023 at 8:04 PM tip-bot2 for Noah Goldstein <tip-bot2(a)linutronix.de> wrote: > The following commit has been merged into the x86/misc branch of tip: > > Commit-ID: 688eb8191b475db5acfd48634600b04fd3dda9ad > Gitweb: https://git.kernel.org/tip/688eb8191b475db5acfd48634600b04fd3dda9ad > Author: Noah Goldstein <goldstein.w.n(a)gmail.com> > AuthorDate: Wed, 10 May 2023 20:10:02 -05:00 > Committer: Dave Hansen <dave.hansen(a)linux.intel.com> > CommitterDate: Thu, 25 May 2023 10:55:18 -07:00 > > x86/csum: Improve performance of `csum_partial` > > 1) Add special case for len == 40 as that is the hottest value. The > nets a ~8-9% latency improvement and a ~30% throughput improvement > in the len == 40 case. > > 2) Use multiple accumulators in the 64-byte loop. This dramatically > improves ILP and results in up to a 40% latency/throughput > improvement (better for more iterations). > > Results from benchmarking on Icelake. Times measured with rdtsc() > len lat_new lat_old r tput_new tput_old r > 8 3.58 3.47 1.032 3.58 3.51 1.021 > 16 4.14 4.02 1.028 3.96 3.78 1.046 > 24 4.99 5.03 0.992 4.23 4.03 1.050 > 32 5.09 5.08 1.001 4.68 4.47 1.048 > 40 5.57 6.08 0.916 3.05 4.43 0.690 > 48 6.65 6.63 1.003 4.97 4.69 1.059 > 56 7.74 7.72 1.003 5.22 4.95 1.055 > 64 6.65 7.22 0.921 6.38 6.42 0.994 > 96 9.43 9.96 0.946 7.46 7.54 0.990 > 128 9.39 12.15 0.773 8.90 8.79 1.012 > 200 12.65 18.08 0.699 11.63 11.60 1.002 > 272 15.82 23.37 0.677 14.43 14.35 1.005 > 440 24.12 36.43 0.662 21.57 22.69 0.951 > 952 46.20 74.01 0.624 42.98 53.12 0.809 > 1024 47.12 78.24 0.602 46.36 58.83 0.788 > 1552 72.01 117.30 0.614 71.92 96.78 0.743 > 2048 93.07 153.25 0.607 93.28 137.20 0.680 > 2600 114.73 194.30 0.590 114.28 179.32 0.637 > 3608 156.34 268.41 0.582 154.97 254.02 0.610 > 4096 175.01 304.03 0.576 175.89 292.08 0.602 > > There is no such thing as a free lunch, however, and the special case > for len == 40 does add overhead to the len != 40 cases. This seems to > amount to be ~5% throughput and slightly less in terms of latency. > > Testing: > Part of this change is a new kunit test. The tests check all > alignment X length pairs in [0, 64) X [0, 512). > There are three cases. > 1) Precomputed random inputs/seed. The expected results where > generated use the generic implementation (which is assumed to be > non-buggy). > 2) An input of all 1s. The goal of this test is to catch any case > a carry is missing. > 3) An input that never carries. The goal of this test si to catch > any case of incorrectly carrying. > > More exhaustive tests that test all alignment X length pairs in > [0, 8192) X [0, 8192] on random data are also available here: > https://github.com/goldsteinn/csum-reproduction > > The reposity also has the code for reproducing the above benchmark > numbers. > > Signed-off-by: Noah Goldstein <goldstein.w.n(a)gmail.com> > Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Thanks for your patch, which is now commit 688eb8191b475db5 ("x86/csum: Improve performance of `csum_partial`") in linus/master stable/master > Link: https://lore.kernel.org/all/20230511011002.935690-1-goldstein.w.n%40gmail.c… This does not seem to be a message sent to a public mailing list archived at lore (yet). On m68k (ARAnyM): KTAP version 1 # Subtest: checksum 1..3 # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:243 Expected result == expec, but result == 54991 (0xd6cf) expec == 33316 (0x8224) not ok 1 test_csum_fixed_random_inputs # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:267 Expected result == expec, but result == 255 (0xff) expec == 65280 (0xff00) Endianness issue in the test? not ok 2 test_csum_all_carry_inputs # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:306 Expected result == expec, but result == 64515 (0xfc03) expec == 0 (0x0) not ok 3 test_csum_no_carry_inputs # checksum: pass:0 fail:3 skip:0 total:3 # Totals: pass:0 fail:3 skip:0 total:3 not ok 1 checksum Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds

1 year, 2 months

2
2
0 0

[PATCH v5 00/13] RISCV: Add KVM_GET_REG_LIST API

by Haibo Xu

KVM_GET_REG_LIST will dump all register IDs that are available to KVM_GET/SET_ONE_REG and It's very useful to identify some platform regression issue during VM migration. Patch 1-7 re-structured the get-reg-list test in aarch64 to make some of the code as common test framework that can be shared by riscv. Patch 8 move reject_set check logic to a function so as to check for different errno for different registers. Patch 9 move finalize_vcpu back to run_test so that riscv can implement its specific operation. Patch 10 change to do the get/set operation only on present-blessed list. Patch 11 add the skip_set facilities so that riscv can skip set operation on some registers. Patch 12 enabled the KVM_GET_REG_LIST API in riscv. patch 13 added the corresponding kselftest for checking possible register regressions. The get-reg-list kvm selftest was ported from aarch64 and tested with Linux v6.4 on a Qemu riscv64 virt machine. --- Changed since v4: * Rebase to v6.4 * Address Andrew's suggestions and comments: Added skip_set concept Updated errno check logic Modified finalize_vcpu as weak function Andrew Jones (7): KVM: arm64: selftests: Replace str_with_index with strdup_printf KVM: arm64: selftests: Drop SVE cap check in print_reg KVM: arm64: selftests: Remove print_reg's dependency on vcpu_config KVM: arm64: selftests: Rename vcpu_config and add to kvm_util.h KVM: arm64: selftests: Delete core_reg_fixup KVM: arm64: selftests: Split get-reg-list test code KVM: arm64: selftests: Finish generalizing get-reg-list Haibo Xu (6): KVM: arm64: selftests: Move reject_set check logic to a function KVM: arm64: selftests: Move finalize_vcpu back to run_test KVM: selftests: Only do get/set tests on present blessed list KVM: selftests: Add skip_set facility to get_reg_list test KVM: riscv: Add KVM_GET_REG_LIST API support KVM: riscv: selftests: Add get-reg-list test Documentation/virt/kvm/api.rst | 2 +- arch/riscv/kvm/vcpu.c | 375 +++++++++ tools/testing/selftests/kvm/Makefile | 11 +- .../selftests/kvm/aarch64/get-reg-list.c | 544 ++---------- tools/testing/selftests/kvm/get-reg-list.c | 395 +++++++++ .../selftests/kvm/include/kvm_util_base.h | 21 + .../selftests/kvm/include/riscv/processor.h | 3 + .../testing/selftests/kvm/include/test_util.h | 2 + tools/testing/selftests/kvm/lib/test_util.c | 15 + .../selftests/kvm/riscv/get-reg-list.c | 780 ++++++++++++++++++ 10 files changed, 1655 insertions(+), 493 deletions(-) create mode 100644 tools/testing/selftests/kvm/get-reg-list.c create mode 100644 tools/testing/selftests/kvm/riscv/get-reg-list.c -- 2.34.1

1 year, 2 months

3
21
0 0

[PATCH] kunit: tool: undo type subscripts for subprocess.Popen

by Daniel Latypov

Writing `subprocess.Popen[str]` requires python 3.9+. kunit.py has an assertion that the python version is 3.7+, so we should try to stay backwards compatible. This conflicts a bit with commit 1da2e6220e11 ("kunit: tool: fix pre-existing `mypy --strict` errors and update run_checks.py"), since mypy complains like so > kunit_kernel.py:95: error: Missing type parameters for generic type "Popen" [type-arg] Note: `mypy --strict --python-version 3.7` does not work. We could annotate each file with comments like `# mypy: disable-error-code="type-arg" but then we might still get nudged to break back-compat in other files. This patch adds a `mypy.ini` file since it seems like the only way to disable specific error codes for all our files. Note: run_checks.py doesn't need to specify `--config_file mypy.ini`, but I think being explicit is better, particularly since most kernel devs won't be familiar with how mypy works. Fixes: 695e26030858 ("kunit: tool: add subscripts for type annotations where appropriate") Reported-by: SeongJae Park <sj(a)kernel.org> Link: https://lore.kernel.org/linux-kselftest/20230501171520.138753-1-sj@kernel.o… Signed-off-by: Daniel Latypov <dlatypov(a)google.com> --- tools/testing/kunit/kunit_kernel.py | 6 +++--- tools/testing/kunit/mypy.ini | 6 ++++++ tools/testing/kunit/run_checks.py | 2 +- 3 files changed, 10 insertions(+), 4 deletions(-) create mode 100644 tools/testing/kunit/mypy.ini diff --git a/tools/testing/kunit/kunit_kernel.py b/tools/testing/kunit/kunit_kernel.py index f01f94106129..7f648802caf6 100644 --- a/tools/testing/kunit/kunit_kernel.py +++ b/tools/testing/kunit/kunit_kernel.py @@ -92,7 +92,7 @@ class LinuxSourceTreeOperations: if stderr: # likely only due to build warnings print(stderr.decode()) - def start(self, params: List[str], build_dir: str) -> subprocess.Popen[str]: + def start(self, params: List[str], build_dir: str) -> subprocess.Popen: raise RuntimeError('not implemented!') @@ -113,7 +113,7 @@ class LinuxSourceTreeOperationsQemu(LinuxSourceTreeOperations): kconfig.merge_in_entries(base_kunitconfig) return kconfig - def start(self, params: List[str], build_dir: str) -> subprocess.Popen[str]: + def start(self, params: List[str], build_dir: str) -> subprocess.Popen: kernel_path = os.path.join(build_dir, self._kernel_path) qemu_command = ['qemu-system-' + self._qemu_arch, '-nodefaults', @@ -142,7 +142,7 @@ class LinuxSourceTreeOperationsUml(LinuxSourceTreeOperations): kconfig.merge_in_entries(base_kunitconfig) return kconfig - def start(self, params: List[str], build_dir: str) -> subprocess.Popen[str]: + def start(self, params: List[str], build_dir: str) -> subprocess.Popen: """Runs the Linux UML binary. Must be named 'linux'.""" linux_bin = os.path.join(build_dir, 'linux') params.extend(['mem=1G', 'console=tty', 'kunit_shutdown=halt']) diff --git a/tools/testing/kunit/mypy.ini b/tools/testing/kunit/mypy.ini new file mode 100644 index 000000000000..ddd288309efa --- /dev/null +++ b/tools/testing/kunit/mypy.ini @@ -0,0 +1,6 @@ +[mypy] +strict = True + +# E.g. we can't write subprocess.Popen[str] until Python 3.9+. +# But kunit.py tries to support Python 3.7+, so let's disable it. +disable_error_code = type-arg diff --git a/tools/testing/kunit/run_checks.py b/tools/testing/kunit/run_checks.py index 8208c3b3135e..c6d494ea3373 100755 --- a/tools/testing/kunit/run_checks.py +++ b/tools/testing/kunit/run_checks.py @@ -23,7 +23,7 @@ commands: Dict[str, Sequence[str]] = { 'kunit_tool_test.py': ['./kunit_tool_test.py'], 'kunit smoke test': ['./kunit.py', 'run', '--kunitconfig=lib/kunit', '--build_dir=kunit_run_checks'], 'pytype': ['/bin/sh', '-c', 'pytype *.py'], - 'mypy': ['mypy', '--strict', '--exclude', '_test.py$', '--exclude', 'qemu_configs/', '.'], + 'mypy': ['mypy', '--config-file', 'mypy.ini', '--exclude', '_test.py$', '--exclude', 'qemu_configs/', '.'], } # The user might not have mypy or pytype installed, skip them if so. base-commit: a42077b787680cbc365a96446b30f32399fa3f6f -- 2.40.1.495.gc816e09b53d-goog

1 year, 2 months

4
8
0 0

[PATCH v3 00/10] tracing: introducing eventfs

by Ajay Kaher

Events Tracing infrastructure contains lot of files, directories (internally in terms of inodes, dentries). And ends up by consuming memory in MBs. We can have multiple events of Events Tracing, which further requires more memory. Instead of creating inodes/dentries, eventfs could keep meta-data and skip the creation of inodes/dentries. As and when require, eventfs will create the inodes/dentries only for required files/directories. Also eventfs would delete the inodes/dentries once no more requires but preserve the meta data. Tracing events took ~9MB, with this approach it took ~4.5MB for ~10K files/dir. v2: Patch 01: new patch:'Require all trace events to have a TRACE_SYSTEM' Patch 02: moved from v1 1/9 Patch 03: moved from v1 2/9 As suggested by Zheng Yejian, introduced eventfs_prepare_ef() helper function to add files or directories to eventfs fix WARNING reported by kernel test robot in v1 8/9 Patch 04: moved from v1 3/9 used eventfs_prepare_ef() to add files fix WARNING reported by kernel test robot in v1 8/9 Patch 05: moved from v1 4/9 fix compiling warning reported by kernel test robot in v1 4/9 Patch 06: moved from v1 5/9 Patch 07: moved from v1 6/9 Patch 08: moved from v1 7/9 Patch 09: moved from v1 8/9 rebased because of v3 01/10 Patch 10: moved from v1 9/9 v1: Patch 1: add header file Patch 2: resolved kernel test robot issues protecting eventfs lists using nested eventfs_rwsem Patch 3: protecting eventfs lists using nested eventfs_rwsem Patch 4: improve events cleanup code to fix crashes Patch 5: resolved kernel test robot issues removed d_instantiate_anon() calls Patch 6: resolved kernel test robot issues fix kprobe test in eventfs_root_lookup() protecting eventfs lists using nested eventfs_rwsem Patch 7: remove header file Patch 8: pass eventfs_rwsem as argument to eventfs functions called eventfs_remove_events_dir() instead of tracefs_remove() from event_trace_del_tracer() Patch 9: new patch to fix kprobe test case fs/tracefs/Makefile | 1 + fs/tracefs/event_inode.c | 757 ++++++++++++++++++ fs/tracefs/inode.c | 124 ++- fs/tracefs/internal.h | 25 + include/linux/trace_events.h | 1 + include/linux/tracefs.h | 49 ++ kernel/trace/trace.h | 3 +- kernel/trace/trace_events.c | 78 +- .../ftrace/test.d/kprobe/kprobe_args_char.tc | 4 +- .../test.d/kprobe/kprobe_args_string.tc | 4 +- 10 files changed, 994 insertions(+), 52 deletions(-) create mode 100644 fs/tracefs/event_inode.c create mode 100644 fs/tracefs/internal.h -- 2.40.0

1 year, 2 months

3
23
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror July 2023