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

[net-next v2 0/2] seg6: add NEXT-C-SID support for SRv6 End.X behavior

by Andrea Mayer

In the Segment Routing (SR) architecture a list of instructions, called segments, can be added to the packet headers to influence the forwarding and processing of the packets in an SR enabled network. Considering the Segment Routing over IPv6 data plane (SRv6) [1], the segment identifiers (SIDs) are IPv6 addresses (128 bits) and the segment list (SID List) is carried in the Segment Routing Header (SRH). A segment may correspond to a "behavior" that is executed by a node when the packet is received. The Linux kernel currently supports a large subset of the behaviors described in [2] (e.g., End, End.X, End.T and so on). In some SRv6 scenarios, the number of segments carried by the SID List may increase dramatically, reducing the MTU (Maximum Transfer Unit) size and/or limiting the processing power of legacy hardware devices (due to longer IPv6 headers). The NEXT-C-SID mechanism [3] extends the SRv6 architecture by providing several ways to efficiently represent the SID List. By leveraging the NEXT-C-SID, it is possible to encode several SRv6 segments within a single 128 bit SID address (also referenced as Compressed SID Container). In this way, the length of the SID List can be drastically reduced. The NEXT-C-SID mechanism is built upon the "flavors" framework defined in [2]. This framework is already supported by the Linux SRv6 subsystem and is used to modify and/or extend a subset of existing behaviors. In this patchset, we extend the SRv6 End.X behavior in order to support the NEXT-C-SID mechanism. In details, the patchset is made of: - patch 1/2: add NEXT-C-SID support for SRv6 End.X behavior; - patch 2/2: add selftest for NEXT-C-SID in SRv6 End.X behavior. From the user space perspective, we do not need to change the iproute2 code to support the NEXT-C-SID flavor for the SRv6 End.X behavior. However, we will update the man page considering the NEXT-C-SID flavor applied to the SRv6 End.X behavior in a separate patch. Comments, improvements and suggestions are always appreciated. Thank you all, Andrea [1] - https://datatracker.ietf.org/doc/html/rfc8754 [2] - https://datatracker.ietf.org/doc/html/rfc8986 [3] - https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression v1 -> v2: - Fix author tags in the commit message in patch 2/2, thanks to Paolo Abeni; - Remove unnecessary supp_ops == 0 check in patch 1/2, thanks to Hangbin Liu; - Fix 'is it possible' -> 'it is possible' in cover letter, thanks to Hangbin Liu. Andrea Mayer (1): seg6: add NEXT-C-SID support for SRv6 End.X behavior Paolo Lungaroni (1): selftests: seg6: add selftest for NEXT-C-SID flavor in SRv6 End.X behavior net/ipv6/seg6_local.c | 108 +- tools/testing/selftests/net/Makefile | 1 + .../net/srv6_end_x_next_csid_l3vpn_test.sh | 1213 +++++++++++++++++ 3 files changed, 1302 insertions(+), 20 deletions(-) create mode 100755 tools/testing/selftests/net/srv6_end_x_next_csid_l3vpn_test.sh -- 2.20.1

2 years, 1 month

4
6
0 0

[PATCH bpf-next v3] selftests/bpf: trace_helpers.c: optimize kallsyms cache

by Rong Tao

From: Rong Tao <rongtao(a)cestc.cn> Static ksyms often have problems because the number of symbols exceeds the MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves the problem somewhat, but it's not the perfect way. This commit uses dynamic memory allocation, which completely solves the problem caused by the limitation of the number of kallsyms. Signed-off-by: Rong Tao <rongtao(a)cestc.cn> --- v3: Do not use structs and judge ksyms__add_symbol function return value. v2: https://lore.kernel.org/lkml/tencent_B655EE5E5D463110D70CD2846AB3262EED09@q… Do the usual len/capacity scheme here to amortize the cost of realloc, and don't free symbols. v1: https://lore.kernel.org/lkml/tencent_AB461510B10CD484E0B2F62E3754165F2909@q… --- tools/testing/selftests/bpf/trace_helpers.c | 42 ++++++++++++++++----- 1 file changed, 32 insertions(+), 10 deletions(-) diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/selftests/bpf/trace_helpers.c index f83d9f65c65b..d8391a2122b4 100644 --- a/tools/testing/selftests/bpf/trace_helpers.c +++ b/tools/testing/selftests/bpf/trace_helpers.c @@ -18,10 +18,32 @@ #define TRACEFS_PIPE "/sys/kernel/tracing/trace_pipe" #define DEBUGFS_PIPE "/sys/kernel/debug/tracing/trace_pipe" -#define MAX_SYMS 400000 -static struct ksym syms[MAX_SYMS]; +static struct ksym *syms; +static int sym_cap; static int sym_cnt; +static int ksyms__add_symbol(const char *name, unsigned long addr) +{ + void *tmp; + unsigned int new_cap; + + if (sym_cnt + 1 > sym_cap) { + new_cap = sym_cap * 4 / 3; + tmp = realloc(syms, sizeof(struct ksym) * new_cap); + if (!tmp) + return -ENOMEM; + syms = tmp; + sym_cap = new_cap; + } + + syms[sym_cnt].addr = addr; + syms[sym_cnt].name = strdup(name); + + sym_cnt++; + + return 0; +} + static int ksym_cmp(const void *p1, const void *p2) { return ((struct ksym *)p1)->addr - ((struct ksym *)p2)->addr; @@ -33,9 +55,13 @@ int load_kallsyms_refresh(void) char func[256], buf[256]; char symbol; void *addr; - int i = 0; + int ret; + sym_cap = 1024; sym_cnt = 0; + syms = malloc(sizeof(struct ksym) * sym_cap); + if (!syms) + return -ENOMEM; f = fopen("/proc/kallsyms", "r"); if (!f) @@ -46,15 +72,11 @@ int load_kallsyms_refresh(void) break; if (!addr) continue; - if (i >= MAX_SYMS) - return -EFBIG; - - syms[i].addr = (long) addr; - syms[i].name = strdup(func); - i++; + ret = ksyms__add_symbol(func, (unsigned long)addr); + if (ret) + return ret; } fclose(f); - sym_cnt = i; qsort(syms, sym_cnt, sizeof(struct ksym), ksym_cmp); return 0; } -- 2.41.0

2 years, 1 month

3
3
0 0

[PATCH v7 0/4] iommufd: Add iommu hardware info reporting

by Yi Liu

iommufd gives userspace the capability to manipulate iommu subsytem. e.g. DMA map/unmap etc. In the near future, it will support iommu nested translation. Different platform vendors have different implementation for the nested translation. For example, Intel VT-d supports using guest I/O page table as the stage-1 translation table. This requires guest I/O page table be compatible with hardware IOMMU. So before set up nested translation, userspace needs to know the hardware iommu information to understand the nested translation requirements. This series reports the iommu hardware information for a given device which has been bound to iommufd. It is preparation work for userspace to allocate hwpt for given device. Like the nested translation support[1]. This series introduces an iommu op to report the iommu hardware info, and an ioctl IOMMU_GET_HW_INFO is added to report such hardware info to user. enum iommu_hw_info_type is defined to differentiate the iommu hardware info reported to user hence user can decode them. This series only adds the framework for iommu hw info reporting, the complete reporting path needs vendor specific definition and driver support. The full code is available in [1] as well. [1] https://github.com/yiliu1765/iommufd/tree/wip/iommufd_nesting_08112023-yi (only the hw_info report path is the latest, other parts is wip) Change log: v7: - Use clear_user() (Jason) - Add fail_nth for hw_ifo (Jason) v6: https://lore.kernel.org/linux-iommu/20230808153510.4170-1-yi.l.liu@intel.co… - Add Jingqi's comment on patch 02 - Add Baolu's r-b to patch 03 - Address Jason's comment on patch 03 v5: https://lore.kernel.org/linux-iommu/20230803143144.200945-1-yi.l.liu@intel.… - Return hw_info_type in the .hw_info op, hence drop hw_info_type field in iommu_ops (Kevin) - Add Jason's r-b for patch 01 - Address coding style comments from Jason and Kevin w.r.t. patch 02, 03 and 04 v4: https://lore.kernel.org/linux-iommu/20230724105936.107042-1-yi.l.liu@intel.… - Rename ioctl to IOMMU_GET_HW_INFO and structure to iommu_hw_info - Move the iommufd_get_hw_info handler to main.c - Place iommu_hw_info prior to iommu_hwpt_alloc - Update the function namings accordingly - Update uapi kdocs v3: https://lore.kernel.org/linux-iommu/20230511143024.19542-1-yi.l.liu@intel.c… - Add r-b from Baolu - Rename IOMMU_HW_INFO_TYPE_DEFAULT to be IOMMU_HW_INFO_TYPE_NONE to better suit what it means - Let IOMMU_DEVICE_GET_HW_INFO succeed even the underlying iommu driver does not have driver-specific data to report per below remark. https://lore.kernel.org/kvm/ZAcwJSK%2F9UVI9LXu@nvidia.com/ v2: https://lore.kernel.org/linux-iommu/20230309075358.571567-1-yi.l.liu@intel.… - Drop patch 05 of v1 as it is already covered by other series - Rename the capability info to be iommu hardware info v1: https://lore.kernel.org/linux-iommu/20230209041642.9346-1-yi.l.liu@intel.co… Regards, Yi Liu Lu Baolu (1): iommu: Add new iommu op to get iommu hardware information Nicolin Chen (1): iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl Yi Liu (2): iommu: Move dev_iommu_ops() to private header iommufd: Add IOMMU_GET_HW_INFO drivers/iommu/iommu-priv.h | 11 +++ drivers/iommu/iommufd/iommufd_test.h | 9 ++ drivers/iommu/iommufd/main.c | 85 +++++++++++++++++++ drivers/iommu/iommufd/selftest.c | 16 ++++ include/linux/iommu.h | 20 ++--- include/uapi/linux/iommufd.h | 45 ++++++++++ tools/testing/selftests/iommu/iommufd.c | 28 +++++- .../selftests/iommu/iommufd_fail_nth.c | 4 + tools/testing/selftests/iommu/iommufd_utils.h | 47 ++++++++++ 9 files changed, 253 insertions(+), 12 deletions(-) -- 2.34.1

2 years, 1 month

3
14
0 0

[PATCH 1/2] kunit: add ability to run tests after boot using debugfs

by Rae Moar

Add functionality to run built-in tests after boot by writing to a debugfs file. Add a new debugfs file labeled "run" for each test suite to use for this purpose. As an example, write to the file using the following: echo "any string" > /sys/kernel/debugfs/kunit/<testsuite>/run This will trigger the test suite to run and will print results to the kernel log. Note that what you "write" to the debugfs file will not be saved. To guard against running tests concurrently with this feature, add a mutex lock around running kunit. This supports the current practice of not allowing tests to be run concurrently on the same kernel. This functionality may not work for all tests. This new functionality could be used to design a parameter injection feature in the future. Signed-off-by: Rae Moar <rmoar(a)google.com> --- Interested in what people think of this idea. I will be adding documentation in v2. Note this may need to be changed once the patches on extending logs land. Thanks! -Rae lib/kunit/debugfs.c | 66 +++++++++++++++++++++++++++++++++++++++++++++ lib/kunit/test.c | 13 +++++++++ 2 files changed, 79 insertions(+) diff --git a/lib/kunit/debugfs.c b/lib/kunit/debugfs.c index 22c5c496a68f..7f76cb909a97 100644 --- a/lib/kunit/debugfs.c +++ b/lib/kunit/debugfs.c @@ -8,12 +8,14 @@ #include <linux/module.h> #include <kunit/test.h> +#include <kunit/test-bug.h> #include "string-stream.h" #include "debugfs.h" #define KUNIT_DEBUGFS_ROOT "kunit" #define KUNIT_DEBUGFS_RESULTS "results" +#define KUNIT_DEBUGFS_RUN "run" /* * Create a debugfs representation of test suites: @@ -21,6 +23,8 @@ * Path Semantics * /sys/kernel/debug/kunit/<testsuite>/results Show results of last run for * testsuite + * /sys/kernel/debug/kunit/<testsuite>/run Write to this file to trigger + * testsuite to run * */ @@ -93,6 +97,51 @@ static int debugfs_results_open(struct inode *inode, struct file *file) return single_open(file, debugfs_print_results, suite); } +/* + * Print a usage message to the debugfs "run" file + * (/sys/kernel/debug/kunit/<testsuite>/run) if opened. + */ +static int debugfs_print_run(struct seq_file *seq, void *v) +{ + struct kunit_suite *suite = (struct kunit_suite *)seq->private; + + seq_puts(seq, "Write to this file to trigger the test suite to run.\n"); + seq_printf(seq, "usage: echo \"any string\" > /sys/kernel/debugfs/kunit/%s/run\n", + suite->name); + return 0; +} + +/* + * The debugfs "run" file (/sys/kernel/debug/kunit/<testsuite>/run) + * contains no information. Write to the file to trigger the test suite + * to run. + */ +static int debugfs_run_open(struct inode *inode, struct file *file) +{ + struct kunit_suite *suite; + + suite = (struct kunit_suite *)inode->i_private; + + return single_open(file, debugfs_print_run, suite); +} + +/* + * Trigger a test suite to run by writing to the suite's "run" debugfs + * file found at: /sys/kernel/debug/kunit/<testsuite>/run + * + * Note: what is written to this file will not be saved. + */ +static ssize_t debugfs_run(struct file *file, + const char __user *buf, size_t count, loff_t *ppos) +{ + struct inode *f_inode = file->f_inode; + struct kunit_suite *suite = (struct kunit_suite *) f_inode->i_private; + + __kunit_test_suites_init(&suite, 1); + + return count; +} + static const struct file_operations debugfs_results_fops = { .open = debugfs_results_open, .read = seq_read, @@ -100,10 +149,23 @@ static const struct file_operations debugfs_results_fops = { .release = debugfs_release, }; +static const struct file_operations debugfs_run_fops = { + .open = debugfs_run_open, + .read = seq_read, + .write = debugfs_run, + .llseek = seq_lseek, + .release = debugfs_release, +}; + void kunit_debugfs_create_suite(struct kunit_suite *suite) { struct kunit_case *test_case; + if (suite->log) { + /* Clear the suite log that's leftover from a previous run. */ + suite->log[0] = '\0'; + return; + } /* Allocate logs before creating debugfs representation. */ suite->log = kzalloc(KUNIT_LOG_SIZE, GFP_KERNEL); kunit_suite_for_each_test_case(suite, test_case) @@ -114,6 +176,10 @@ void kunit_debugfs_create_suite(struct kunit_suite *suite) debugfs_create_file(KUNIT_DEBUGFS_RESULTS, S_IFREG | 0444, suite->debugfs, suite, &debugfs_results_fops); + + debugfs_create_file(KUNIT_DEBUGFS_RUN, S_IFREG | 0644, + suite->debugfs, + suite, &debugfs_run_fops); } void kunit_debugfs_destroy_suite(struct kunit_suite *suite) diff --git a/lib/kunit/test.c b/lib/kunit/test.c index 49698a168437..5058a72d9e8a 100644 --- a/lib/kunit/test.c +++ b/lib/kunit/test.c @@ -13,6 +13,7 @@ #include <linux/kernel.h> #include <linux/module.h> #include <linux/moduleparam.h> +#include <linux/mutex.h> #include <linux/panic.h> #include <linux/sched/debug.h> #include <linux/sched.h> @@ -22,6 +23,8 @@ #include "string-stream.h" #include "try-catch-impl.h" +static struct mutex kunit_run_lock; + /* * Hook to fail the current test and print an error message to the log. */ @@ -702,6 +705,11 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_ return 0; } + /* Use mutex lock to guard against running tests concurrently. */ + if (mutex_lock_interruptible(&kunit_run_lock)) { + pr_err("kunit: test interrupted\n"); + return -EINTR; + } static_branch_inc(&kunit_running); for (i = 0; i < num_suites; i++) { @@ -710,6 +718,7 @@ int __kunit_test_suites_init(struct kunit_suite * const * const suites, int num_ } static_branch_dec(&kunit_running); + mutex_unlock(&kunit_run_lock); return 0; } EXPORT_SYMBOL_GPL(__kunit_test_suites_init); @@ -869,6 +878,10 @@ static int __init kunit_init(void) kunit_install_hooks(); kunit_debugfs_init(); + + /* Initialize lock to guard against running tests concurrently. */ + mutex_init(&kunit_run_lock); + #ifdef CONFIG_MODULES return register_module_notifier(&kunit_mod_nb); #else base-commit: 582eb3aeed2d06b122fba95518b84506d3d4ceb9 -- 2.41.0.694.ge786442a9b-goog

2 years, 1 month

1
1
0 0

[PATCH mptcp-next v13 0/4] bpf: Force to MPTCP

by Geliang Tang

As is described in the "How to use MPTCP?" section in MPTCP wiki [1]: "Your app should create sockets with IPPROTO_MPTCP as the proto: ( socket(AF_INET, SOCK_STREAM, IPPROTO_MPTCP); ). Legacy apps can be forced to create and use MPTCP sockets instead of TCP ones via the mptcpize command bundled with the mptcpd daemon." But the mptcpize (LD_PRELOAD technique) command has some limitations [2]: - it doesn't work if the application is not using libc (e.g. GoLang apps) - in some envs, it might not be easy to set env vars / change the way apps are launched, e.g. on Android - mptcpize needs to be launched with all apps that want MPTCP: we could have more control from BPF to enable MPTCP only for some apps or all the ones of a netns or a cgroup, etc. - it is not in BPF, we cannot talk about it at netdev conf. So this patchset attempts to use BPF to implement functions similer to mptcpize. The main idea is to add a hook in sys_socket() to change the protocol id from IPPROTO_TCP (or 0) to IPPROTO_MPTCP. [1] https://github.com/multipath-tcp/mptcp_net-next/wiki [2] https://github.com/multipath-tcp/mptcp_net-next/issues/79 v13: - drop "Use random netns name for mptcp" patch. v12: - update diag_* log of update_socket_protocol. - add 'ip netns show' after 'ip netns del' to check if there is a test did not clean up its netns. - return libbpf_get_error() instead of -EIO for the error from open_and_load(). - Use getsockopt(SOL_PROTOCOL) to verify mptcp protocol intead of using 'ss -tOni'. v11: - add comments about outputs of 'ss' and 'nstat'. - use "err = verify_mptcpify()" instead of using =+. v10: - drop "#ifdef CONFIG_BPF_JIT". - include vmlinux.h and bpf_tracing_net.h to avoid defining some macros. - drop unneeded checks for mptcp. v9: - update comment for 'update_socket_protocol'. v8: - drop the additional checks on the 'protocol' value after the 'update_socket_protocol()' call. v7: - add __weak and __diag_* for update_socket_protocol. v6: - add update_socket_protocol. v5: - add bpf_mptcpify helper. v4: - use lsm_cgroup/socket_create v3: - patch 8: char cmd[128]; -> char cmd[256]; v2: - Fix build selftests errors reported by CI Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/79 Geliang Tang (4): bpf: Add update_socket_protocol hook selftests/bpf: Add two mptcp netns helpers selftests/bpf: Fix error checks of mptcp open_and_load selftests/bpf: Add mptcpify test net/mptcp/bpf.c | 15 ++ net/socket.c | 26 +++- .../testing/selftests/bpf/prog_tests/mptcp.c | 141 +++++++++++++++--- tools/testing/selftests/bpf/progs/mptcpify.c | 20 +++ 4 files changed, 182 insertions(+), 20 deletions(-) create mode 100644 tools/testing/selftests/bpf/progs/mptcpify.c -- 2.35.3

2 years, 1 month

2
7
0 0

[PATCH v2] rcutorture: Copy out ftrace into its own console file

by Joel Fernandes (Google)

From: Joel Fernandes (Google) <joel(a)joelfernandes.org> Often times during debugging, it is difficult to jump to the ftrace dump in the console log and treat it independent of the result of the log file. Copy the contents of the buffers into its own file to make it easier to refer to the ftrace dump. The original ftrace dump is still available in the console log if it is desired to refer to it there. Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org> --- v1-v2: Change log updates, "From:" updates. .../selftests/rcutorture/bin/functions.sh | 24 +++++++++++++++++++ .../selftests/rcutorture/bin/parse-console.sh | 7 ++++++ 2 files changed, 31 insertions(+) mode change 100644 => 100755 tools/testing/selftests/rcutorture/bin/functions.sh diff --git a/tools/testing/selftests/rcutorture/bin/functions.sh b/tools/testing/selftests/rcutorture/bin/functions.sh old mode 100644 new mode 100755 index b8e2ea23cb3f..2ec4ab87a7f0 --- a/tools/testing/selftests/rcutorture/bin/functions.sh +++ b/tools/testing/selftests/rcutorture/bin/functions.sh @@ -331,3 +331,27 @@ specify_qemu_net () { echo $1 -net none fi } + +# Extract the ftrace output from the console log output +# The ftrace output looks in the logs looks like: +# Dumping ftrace buffer: +# --------------------------------- +# [...] +# --------------------------------- +extract_ftrace_from_console() { + awk ' + /Dumping ftrace buffer:/ { + capture = 1 + next + } + /---------------------------------/ { + if(capture == 1) { + capture = 2 + next + } else if(capture == 2) { + capture = 0 + } + } + capture == 2 + ' "$1"; +} diff --git a/tools/testing/selftests/rcutorture/bin/parse-console.sh b/tools/testing/selftests/rcutorture/bin/parse-console.sh index 9ab0f6bc172c..e3d2f69ec0fb 100755 --- a/tools/testing/selftests/rcutorture/bin/parse-console.sh +++ b/tools/testing/selftests/rcutorture/bin/parse-console.sh @@ -182,3 +182,10 @@ if ! test -s $file.diags then rm -f $file.diags fi + +# Call extract_ftrace_from_console function, if the output is empty, +# don't create $file.ftrace. Otherwise output the results to $file.ftrace +extract_ftrace_from_console $file > $file.ftrace +if [ ! -s $file.ftrace ]; then + rm -f $file.ftrace +fi -- 2.41.0.640.ga95def55d0-goog

2 years, 1 month

3
5
0 0

[PATCH v6 0/2] tools/nolibc: fix up size inflat regression

by Zhangjin Wu

Hi, Willy As we discussed in v5, I have proposed a my_syscall() macro, it can convert all of the sys_* functions to macros, and such macros can simply preserve input types from library routines and inherit the 'long' return type from my_syscall<N>. As a result, our __sysret() helper will only require to accept integer types and therefore we can simply revert it to our old sign comparison version (but as macro). I have already prepared a series of my_syscall() patchset but it includes several not that simple patches, before sending it for review, to directly solve the __sysret() issue at first, it is better to only convert the current three sys_* functions to return 'long' instead of pointer, which will make things easier. Here is the testing result on all archs (except loongarch) with Arnd's gcc 13.2.0, before testing it, we'd better apply the CROSS_COMPILE patchset [1] manually: // before $ ARCHS="i386 x86_64 arm64 arm mips ppc ppc64 ppc64le riscv s390" $ for arch in ${ARCHS[@]}; do printf "%9s: " $arch; make run-user XARCH=$arch 2>/dev/null | grep status | tr '\n' ' '; \ size nolibc-test | tail -1 | tr '\t' ' ' | tr -s ' ' | cut -d ' ' -f2; done i386: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 19654 x86_64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22337 arm64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26292 arm: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 23140 mips: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 23164 ppc: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26812 ppc64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 27380 ppc64le: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 28004 riscv: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22062 s390: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 22592 // after $ for arch in ${ARCHS[@]}; do printf "%9s: " $arch; make run-user XARCH=$arch 2>/dev/null | grep status | tr '\n' ' '; \ size nolibc-test | tail -1 | tr '\t' ' ' | tr -s ' ' | cut -d ' ' -f2; done i386: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 19502 x86_64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22000 arm64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 25860 arm: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 23108 mips: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 22908 ppc: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26616 ppc64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 27192 ppc64le: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 27816 riscv: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 21790 s390: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 22184 // compare i386: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 19654 -> 19502 x86_64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22337 -> 22000 arm64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26292 -> 25860 arm: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 23140 -> 23108 mips: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 23164 -> 22908 ppc: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26812 -> 26616 ppc64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 27380 -> 27192 ppc64le: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 28004 -> 27816 riscv: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22062 -> 21790 s390: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 22592 -> 22184 After these two patches, will send the proposed my_syscall() patchset tomorrow, it can even further reduce more type conversions and therefore reduce more binary bytes, here is a preview of the testing result: // with the coming my_syscall() patchset, sys_* from functionsn to macros i386: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 19250 x86_64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 21733 arm64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 25804 arm: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22828 mips: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 22740 ppc: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26376 ppc64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26752 ppc64le: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 27360 riscv: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 21746 s390: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 21928 // compare: __sysret() function -> __sysret() macro -> sys_* macros i386: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 19654 -> 19502 -> 19250 x86_64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22337 -> 22000 -> 21733 arm64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26292 -> 25860 -> 25804 arm: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 23140 -> 23108 -> 22828 mips: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 23164 -> 22908 -> 22740 ppc: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 26812 -> 26616 -> 26376 ppc64: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 27380 -> 27192 -> 26752 ppc64le: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 28004 -> 27816 -> 27360 riscv: 160 test(s): 158 passed, 2 skipped, 0 failed => status: warning 22062 -> 21790 -> 21746 s390: 160 test(s): 157 passed, 3 skipped, 0 failed => status: warning 22592 -> 22184 -> 21928 It can also shrink the whole sys.h from 1171 lines to around 738 lines. Changes from v5 --> v6: * The method introduced in v5 works but it is too complex ;-) * Convert the return type of sys_brk/mmap/mmap2 from pointer to 'long' (like my_syscall<N> does), after this, all of the sys_* functions return integer. * Restore __sysret() helper to sign comparison as originally, but also use macro instead of inline function to avoid useless input type and return type conversion. Changes from v4 --> v5: * Use __typeof__((arg) + 0) to lose the 'const' flag for old gcc versions. * Import the famous __is_constexpr() macro from kernel side and add a __is_pointer() macro based on it. (David, to avoid introduce extra discuss on the prove-in-use __is_constexpr macro, this patch uses the original version instead of your suggested version, more info here: https://lore.kernel.org/lkml/20220131204357.1133674-1-keescook@chromium.org/) * Use __builtin_choose_expr() to merge two comparisons to share the same errno setting code and the -1L assignment code. Changes from v3 --> v4: * fix up a new warning about 'ret < 0' when the input arg type is (void *) Changes from v2 --> v3: * define a __GXX_HAS_AUTO_TYPE_WITH_CONST_SUPPORT for gcc >= 11.0 (ABI_VERSION >= 1016) * split __sysret() to two versions by the macro instead of a mixed unified and unreadable version * use shorter __ret instead of __sysret_arg Changes from v1 --> v2: * fix up argument with 'const' in the type * support "void *" argument Best regards, Zhangjin Wu --- v5: https://lore.kernel.org/lkml/b6ff2684f557f6ce00151905990643e651391614.16914… v4: https://lore.kernel.org/lkml/a4084f7fac7a89f861b5582774bc7a98634d1e76.16913… v3: https://lore.kernel.org/lkml/8eaab5da2dcbba42e3f3efc2ae686a22c95f84f0.16913… v2: https://lore.kernel.org/lkml/95fe3e732f455fab653fe1427118d905e4d04257.16913… v1: https://lore.kernel.org/lkml/20230806131921.52453-1-falcon@tinylab.org/ [1]: https://lore.kernel.org/lkml/cover.1691783604.git.falcon@tinylab.org/ Zhangjin Wu (2): tools/nolibc: let sys_brk, sys_mmap and sys_mmap2 return long tools/nolibc: fix up size inflate regression tools/include/nolibc/arch-s390.h | 4 +-- tools/include/nolibc/sys.h | 43 +++++++++++++------------------- 2 files changed, 20 insertions(+), 27 deletions(-) -- 2.25.1

2 years, 1 month

2
9
0 0

[PATCH V2 0/7] AMD Pstate Preferred Core

by Meng Li

Hi all: The core frequency is subjected to the process variation in semiconductors. Not all cores are able to reach the maximum frequency respecting the infrastructure limits. Consequently, AMD has redefined the concept of maximum frequency of a part. This means that a fraction of cores can reach maximum frequency. To find the best process scheduling policy for a given scenario, OS needs to know the core ordering informed by the platform through highest performance capability register of the CPPC interface. Earlier implementations of AMD Pstate Preferred Core only support a static core ranking and targeted performance. Now it has the ability to dynamically change the preferred core based on the workload and platform conditions and accounting for thermals and aging. AMD Pstate driver utilizes the functions and data structures provided by the ITMT architecture to enable the scheduler to favor scheduling on cores which can be get a higher frequency with lower voltage. We call it AMD Pstate Preferrred Core. Here sched_set_itmt_core_prio() is called to set priorities and sched_set_itmt_support() is called to enable ITMT feature. AMD Pstate driver uses the highest performance value to indicate the priority of CPU. The higher value has a higher priority. AMD Pstate driver will provide an initial core ordering at boot time. It relies on the CPPC interface to communicate the core ranking to the operating system and scheduler to make sure that OS is choosing the cores with highest performance firstly for scheduling the process. When AMD Pstate driver receives a message with the highest performance change, it will update the core ranking. Changes form V1->V2: - acpi: cppc: - - Add reference link. - cpufreq: - - Moidfy link error. - cpufreq: amd-pstate: - - Init the priorities of all online CPUs - - Use a single variable to represent the status of Preferred Core. - Documentation: - - Default enabled preferred core. - Documentation: amd-pstate: - - Modify inappropriate descriptions. - - Default enabled preferred core. - - Use a single variable to represent the status of Preferred Core. Meng Li (7): x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion. acpi: cppc: Add get the highest performance cppc control cpufreq: amd-pstate: Enable AMD Pstate Preferred Core Supporting. cpufreq: Add a notification message that the highest perf has changed cpufreq: amd-pstate: Update AMD Pstate Preferred Core ranking dynamically Documentation: amd-pstate: introduce AMD Pstate Preferred Core Documentation: introduce AMD Pstate Preferrd Core mode kernel command line options .../admin-guide/kernel-parameters.txt | 5 + Documentation/admin-guide/pm/amd-pstate.rst | 54 +++++++ arch/x86/Kconfig | 3 +- drivers/acpi/cppc_acpi.c | 13 ++ drivers/acpi/processor_driver.c | 6 + drivers/cpufreq/amd-pstate.c | 152 ++++++++++++++++-- drivers/cpufreq/cpufreq.c | 13 ++ include/acpi/cppc_acpi.h | 5 + include/linux/amd-pstate.h | 1 + include/linux/cpufreq.h | 4 + 10 files changed, 239 insertions(+), 17 deletions(-) -- 2.34.1

2 years, 1 month

2
12
0 0

[PATCH -next 0/4] kselftest/arm64: Add crypto-related feature checks to hwcap test

by Zeng Heng

Add new feature checks related to crypto to the hwcap test. The following is a log snippet from my local testing environment based on for-next/selftests: ~~~ TAP version 13 1..111 # AES present ok 1 cpuinfo_match_AES ok 2 sigill_AES ok 3 # SKIP sigbus_AES # CRC32 present ok 4 cpuinfo_match_CRC32 ok 5 sigill_CRC32 ok 6 # SKIP sigbus_CRC32 ok 7 cpuinfo_match_CSSC # sigill_reported for CSSC ok 8 # SKIP sigill_CSSC ok 9 # SKIP sigbus_CSSC # FP present ok 10 cpuinfo_match_FP ok 11 sigill_FP ok 12 # SKIP sigbus_FP # JSCVT present ok 13 cpuinfo_match_JSCVT ok 14 sigill_JSCVT ok 15 # SKIP sigbus_JSCVT # LRCPC present ok 16 cpuinfo_match_LRCPC ok 17 sigill_LRCPC ok 18 # SKIP sigbus_LRCPC # LRCPC2 present ok 19 cpuinfo_match_LRCPC2 ok 20 sigill_LRCPC2 ok 21 # SKIP sigbus_LRCPC2 # LSE present ok 22 cpuinfo_match_LSE ok 23 sigill_LSE ok 24 # SKIP sigbus_LSE # LSE2 present ok 25 cpuinfo_match_LSE2 ok 26 sigill_LSE2 ok 27 sigbus_LSE2 ok 28 cpuinfo_match_MOPS ok 29 sigill_MOPS ok 30 # SKIP sigbus_MOPS # RNG present ok 31 cpuinfo_match_RNG ok 32 sigill_RNG ok 33 # SKIP sigbus_RNG # PMULL present ok 34 cpuinfo_match_PMULL ok 35 sigill_PMULL ok 36 # SKIP sigbus_PMULL ok 37 cpuinfo_match_RPRFM ok 38 # SKIP sigill_RPRFM ok 39 # SKIP sigbus_RPRFM # SHA1 present ok 40 cpuinfo_match_SHA1 ok 41 sigill_SHA1 ok 42 # SKIP sigbus_SHA1 # SHA2 present ok 43 cpuinfo_match_SHA2 ok 44 sigill_SHA2 ok 45 # SKIP sigbus_SHA2 # SHA512 present ok 46 cpuinfo_match_SHA512 ok 47 sigill_SHA512 ok 48 # SKIP sigbus_SHA512 ok 49 cpuinfo_match_SME ok 50 sigill_SME ok 51 # SKIP sigbus_SME ok 52 cpuinfo_match_SME2 ok 53 sigill_SME2 ok 54 # SKIP sigbus_SME2 ok 55 cpuinfo_match_SME 2.1 # sigill_reported for SME 2.1 ok 56 # SKIP sigill_SME 2.1 ok 57 # SKIP sigbus_SME 2.1 ok 58 cpuinfo_match_SME I16I32 # sigill_reported for SME I16I32 ok 59 # SKIP sigill_SME I16I32 ok 60 # SKIP sigbus_SME I16I32 ok 61 cpuinfo_match_SME BI32I32 # sigill_reported for SME BI32I32 ok 62 # SKIP sigill_SME BI32I32 ok 63 # SKIP sigbus_SME BI32I32 ok 64 cpuinfo_match_SME B16B16 # sigill_reported for SME B16B16 ok 65 # SKIP sigill_SME B16B16 ok 66 # SKIP sigbus_SME B16B16 ok 67 cpuinfo_match_SME F16F16 # sigill_reported for SME F16F16 ok 68 # SKIP sigill_SME F16F16 ok 69 # SKIP sigbus_SME F16F16 # SVE present ok 70 cpuinfo_match_SVE ok 71 sigill_SVE ok 72 # SKIP sigbus_SVE ok 73 cpuinfo_match_SVE 2 # sigill_reported for SVE 2 ok 74 # SKIP sigill_SVE 2 ok 75 # SKIP sigbus_SVE 2 ok 76 cpuinfo_match_SVE 2.1 # sigill_reported for SVE 2.1 ok 77 # SKIP sigill_SVE 2.1 ok 78 # SKIP sigbus_SVE 2.1 ok 79 cpuinfo_match_SVE AES # sigill_reported for SVE AES ok 80 # SKIP sigill_SVE AES ok 81 # SKIP sigbus_SVE AES ok 82 cpuinfo_match_SVE2 PMULL # sigill_reported for SVE2 PMULL ok 83 # SKIP sigill_SVE2 PMULL ok 84 # SKIP sigbus_SVE2 PMULL ok 85 cpuinfo_match_SVE2 BITPERM # sigill_reported for SVE2 BITPERM ok 86 # SKIP sigill_SVE2 BITPERM ok 87 # SKIP sigbus_SVE2 BITPERM ok 88 cpuinfo_match_SVE2 SHA3 # sigill_reported for SVE2 SHA3 ok 89 # SKIP sigill_SVE2 SHA3 ok 90 # SKIP sigbus_SVE2 SHA3 ok 91 cpuinfo_match_SVE2 SM4 # sigill_reported for SVE2 SM4 ok 92 # SKIP sigill_SVE2 SM4 ok 93 # SKIP sigbus_SVE2 SM4 # SVE2 I8MM present ok 94 cpuinfo_match_SVE2 I8MM ok 95 sigill_SVE2 I8MM ok 96 # SKIP sigbus_SVE2 I8MM # SVE2 F32MM present ok 97 cpuinfo_match_SVE2 F32MM ok 98 sigill_SVE2 F32MM ok 99 # SKIP sigbus_SVE2 F32MM # SVE2 F64MM present ok 100 cpuinfo_match_SVE2 F64MM ok 101 sigill_SVE2 F64MM ok 102 # SKIP sigbus_SVE2 F64MM # SVE2 BF16 present ok 103 cpuinfo_match_SVE2 BF16 ok 104 sigill_SVE2 BF16 ok 105 # SKIP sigbus_SVE2 BF16 ok 106 cpuinfo_match_SVE2 EBF16 ok 107 # SKIP sigill_SVE2 EBF16 ok 108 # SKIP sigbus_SVE2 EBF16 ok 109 cpuinfo_match_HBC ok 110 sigill_HBC ok 111 # SKIP sigbus_HBC # Totals: pass:60 fail:0 xfail:0 xpass:0 skip:51 error:0 ~~~ Zeng Heng (4): kselftest/arm64: add SHA1 and related features to hwcap test kselftest/arm64: add AES feature check to hwcap test kselftest/arm64: add pmull feature to hwcap test kselftest/arm64: add jscvt feature to hwcap test tools/testing/selftests/arm64/abi/hwcap.c | 77 +++++++++++++++++++++++ 1 file changed, 77 insertions(+) -- 2.25.1

2 years, 1 month

1
4
0 0

[PATCH -next 0/4] kselftest/arm64: Add crypto-related feature checks to hwcap test

by Zeng Heng

Add new feature checks related to crypto to the hwcap test. The following is a log snippet from my local testing environment based on for-next/selftests: ~~~ TAP version 13 1..111 # AES present ok 1 cpuinfo_match_AES ok 2 sigill_AES ok 3 # SKIP sigbus_AES # CRC32 present ok 4 cpuinfo_match_CRC32 ok 5 sigill_CRC32 ok 6 # SKIP sigbus_CRC32 ok 7 cpuinfo_match_CSSC # sigill_reported for CSSC ok 8 # SKIP sigill_CSSC ok 9 # SKIP sigbus_CSSC # FP present ok 10 cpuinfo_match_FP ok 11 sigill_FP ok 12 # SKIP sigbus_FP # JSCVT present ok 13 cpuinfo_match_JSCVT ok 14 sigill_JSCVT ok 15 # SKIP sigbus_JSCVT # LRCPC present ok 16 cpuinfo_match_LRCPC ok 17 sigill_LRCPC ok 18 # SKIP sigbus_LRCPC # LRCPC2 present ok 19 cpuinfo_match_LRCPC2 ok 20 sigill_LRCPC2 ok 21 # SKIP sigbus_LRCPC2 # LSE present ok 22 cpuinfo_match_LSE ok 23 sigill_LSE ok 24 # SKIP sigbus_LSE # LSE2 present ok 25 cpuinfo_match_LSE2 ok 26 sigill_LSE2 ok 27 sigbus_LSE2 ok 28 cpuinfo_match_MOPS ok 29 sigill_MOPS ok 30 # SKIP sigbus_MOPS # RNG present ok 31 cpuinfo_match_RNG ok 32 sigill_RNG ok 33 # SKIP sigbus_RNG # PMULL present ok 34 cpuinfo_match_PMULL ok 35 sigill_PMULL ok 36 # SKIP sigbus_PMULL ok 37 cpuinfo_match_RPRFM ok 38 # SKIP sigill_RPRFM ok 39 # SKIP sigbus_RPRFM # SHA1 present ok 40 cpuinfo_match_SHA1 ok 41 sigill_SHA1 ok 42 # SKIP sigbus_SHA1 # SHA2 present ok 43 cpuinfo_match_SHA2 ok 44 sigill_SHA2 ok 45 # SKIP sigbus_SHA2 # SHA512 present ok 46 cpuinfo_match_SHA512 ok 47 sigill_SHA512 ok 48 # SKIP sigbus_SHA512 ok 49 cpuinfo_match_SME ok 50 sigill_SME ok 51 # SKIP sigbus_SME ok 52 cpuinfo_match_SME2 ok 53 sigill_SME2 ok 54 # SKIP sigbus_SME2 ok 55 cpuinfo_match_SME 2.1 # sigill_reported for SME 2.1 ok 56 # SKIP sigill_SME 2.1 ok 57 # SKIP sigbus_SME 2.1 ok 58 cpuinfo_match_SME I16I32 # sigill_reported for SME I16I32 ok 59 # SKIP sigill_SME I16I32 ok 60 # SKIP sigbus_SME I16I32 ok 61 cpuinfo_match_SME BI32I32 # sigill_reported for SME BI32I32 ok 62 # SKIP sigill_SME BI32I32 ok 63 # SKIP sigbus_SME BI32I32 ok 64 cpuinfo_match_SME B16B16 # sigill_reported for SME B16B16 ok 65 # SKIP sigill_SME B16B16 ok 66 # SKIP sigbus_SME B16B16 ok 67 cpuinfo_match_SME F16F16 # sigill_reported for SME F16F16 ok 68 # SKIP sigill_SME F16F16 ok 69 # SKIP sigbus_SME F16F16 # SVE present ok 70 cpuinfo_match_SVE ok 71 sigill_SVE ok 72 # SKIP sigbus_SVE ok 73 cpuinfo_match_SVE 2 # sigill_reported for SVE 2 ok 74 # SKIP sigill_SVE 2 ok 75 # SKIP sigbus_SVE 2 ok 76 cpuinfo_match_SVE 2.1 # sigill_reported for SVE 2.1 ok 77 # SKIP sigill_SVE 2.1 ok 78 # SKIP sigbus_SVE 2.1 ok 79 cpuinfo_match_SVE AES # sigill_reported for SVE AES ok 80 # SKIP sigill_SVE AES ok 81 # SKIP sigbus_SVE AES ok 82 cpuinfo_match_SVE2 PMULL # sigill_reported for SVE2 PMULL ok 83 # SKIP sigill_SVE2 PMULL ok 84 # SKIP sigbus_SVE2 PMULL ok 85 cpuinfo_match_SVE2 BITPERM # sigill_reported for SVE2 BITPERM ok 86 # SKIP sigill_SVE2 BITPERM ok 87 # SKIP sigbus_SVE2 BITPERM ok 88 cpuinfo_match_SVE2 SHA3 # sigill_reported for SVE2 SHA3 ok 89 # SKIP sigill_SVE2 SHA3 ok 90 # SKIP sigbus_SVE2 SHA3 ok 91 cpuinfo_match_SVE2 SM4 # sigill_reported for SVE2 SM4 ok 92 # SKIP sigill_SVE2 SM4 ok 93 # SKIP sigbus_SVE2 SM4 # SVE2 I8MM present ok 94 cpuinfo_match_SVE2 I8MM ok 95 sigill_SVE2 I8MM ok 96 # SKIP sigbus_SVE2 I8MM # SVE2 F32MM present ok 97 cpuinfo_match_SVE2 F32MM ok 98 sigill_SVE2 F32MM ok 99 # SKIP sigbus_SVE2 F32MM # SVE2 F64MM present ok 100 cpuinfo_match_SVE2 F64MM ok 101 sigill_SVE2 F64MM ok 102 # SKIP sigbus_SVE2 F64MM # SVE2 BF16 present ok 103 cpuinfo_match_SVE2 BF16 ok 104 sigill_SVE2 BF16 ok 105 # SKIP sigbus_SVE2 BF16 ok 106 cpuinfo_match_SVE2 EBF16 ok 107 # SKIP sigill_SVE2 EBF16 ok 108 # SKIP sigbus_SVE2 EBF16 ok 109 cpuinfo_match_HBC ok 110 sigill_HBC ok 111 # SKIP sigbus_HBC # Totals: pass:60 fail:0 xfail:0 xpass:0 skip:51 error:0 ~~~ Zeng Heng (4): kselftest/arm64: add SHA1 and related features to hwcap test kselftest/arm64: add AES feature check to hwcap test kselftest/arm64: add pmull feature to hwcap test kselftest/arm64: add jscvt feature to hwcap test tools/testing/selftests/arm64/abi/hwcap.c | 77 +++++++++++++++++++++++ 1 file changed, 77 insertions(+) -- 2.25.1

2 years, 1 month

2
7
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror