summaryrefslogtreecommitdiff
path: root/tools
AgeCommit message (Collapse)Author
2026-05-04net: selftests: add getsockopt_iter regression testsBreno Leitao
Add a single kselftest covering the proto_ops getsockopt_iter conversions for AF_NETLINK and AF_VSOCK, using one fixture per protocol: netlink: NETLINK_PKTINFO covers the flag-style int path (exact size, oversize clamp, undersize -EINVAL); NETLINK_LIST_MEMBERSHIPS covers the size-discovery path that always reports the required buffer length back via optlen, even when the user buffer is too small to receive any group bits. vsock: SO_VM_SOCKETS_BUFFER_SIZE covers the u64 path (exact size, oversize clamp, undersize -EINVAL). Each fixture also exercises an unknown optname and a bogus level so the returned-length / errno semantics preserved by the sockopt_t conversion are pinned down. Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260501-getsock_one-v1-3-810ce23ea70e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-04selftests/resctrl: Reduce L2 impact on CAT testReinette Chatre
The L3 CAT test loads a buffer into cache that is proportional to the L3 size allocated for the workload and measures cache misses when accessing the buffer as a test of L3 occupancy. When loading the buffer it can be assumed that a portion of the buffer will be loaded into the L2 cache and depending on cache design may not be present in L3. It is thus possible for data to not be in L3 but also not trigger an L3 cache miss when accessed. Reduce impact of L2 on the L3 CAT test by, if L2 allocation is supported, minimizing the portion of L2 that the workload can allocate into. This encourages most of buffer to be loaded into L3 and support better comparison between buffer size, cache portion, and cache misses when accessing the buffer. Link: https://lore.kernel.org/r/1f5aad318889cd6d4f9a8d8b0fbe83e3848d41a9.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Simplify perf usage in CAT testReinette Chatre
The CAT test relies on the PERF_COUNT_HW_CACHE_MISSES event to determine if modifying a cache portion size is successful. This event is configured to report the data as part of an event group, but no other events are added to the group. Remove the unnecessary PERF_FORMAT_GROUP format setting. This eliminates the need for struct perf_event_read and results in read() of the associated file descriptor to return just one value associated with the PERF_COUNT_HW_CACHE_MISSES event of interest. Link: https://lore.kernel.org/r/fb69325eba5031b735fa79effaaacd797c9c6040.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Remove requirement on cache miss rateReinette Chatre
As the CAT test reads the same buffer into different sized cache portions it compares the number of cache misses against an expected percentage based on the size of the cache portion. Systems and test conditions vary. The CAT test is a test of resctrl subsystem health and not a test of the hardware architecture so it is not required to place requirements on the size of the difference in cache misses, just that the number of cache misses when reading a buffer increase as the cache portion used for the buffer decreases. Remove additional constraint on how big the difference between cache misses should be as the cache portion size changes. Only test that the cache misses increase as the cache portion size decreases. This remains a good sanity check of resctrl subsystem health while reducing impact of hardware architectural differences and the various conditions under which the test may run. Increase the size difference between cache portions to additionally avoid any consequences resulting from smaller increments. Link: https://lore.kernel.org/r/6de4da5486354c0f25fef0d194956470cb744041.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Raise threshold at which MBM and PMU values are comparedReinette Chatre
Commit 501cfdba0a40 ("selftests/resctrl: Do not compare performance counters and resctrl at low bandwidth") introduced a threshold under which memory bandwidth values from MBM and performance counters are not compared. This is needed because MBM and the PMUs do not have an identical view of memory bandwidth since PMUs can count all memory traffic while MBM does not count "overhead" (for example RAS) traffic that cannot be attributed to an RMID. As a ratio this difference in view of memory bandwidth is pronounced at low memory bandwidths. The 750MiB threshold was chosen arbitrarily after comparisons on different platforms. Exposed to more platforms after introduction this threshold has proven to be inadequate. Having accurate comparison between performance counters and MBM requires careful management of system load as well as control of features that introduce extra memory traffic, for example, patrol scrub. This is not appropriate for the resctrl selftests that are intended to run on a variety of systems with various configurations. Increase the memory bandwidth threshold under which no comparison is made between performance counters and MBM. Add additional leniency by increasing the percentage of difference that will be tolerated between these counts. There is no impact to the validity of the resctrl selftests results as a measure of resctrl subsystem health. Link: https://lore.kernel.org/r/b374c33ddd324130d6255cbb91c3dd500e8277e7.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Increase size of buffer used in MBM and MBA testsReinette Chatre
Errata for Sierra Forest [1] (SRF42) and Granite Rapids [2] (GNR12) describe the problem that MBM on Intel RDT may overcount memory bandwidth measurements. The resctrl tests compare memory bandwidth reported by iMC PMU to that reported by MBM causing the tests to fail on these systems depending on the settings of the platform related to the errata. Since the resctrl tests need to run under various conditions it is not possible to ensure system settings are such that MBM will not overcount. It has been observed that the overcounting can be controlled via the buffer size used in the MBM and MBA tests that rely on comparisons between iMC PMU and MBM measurements. Running the MBM test on affected platforms with different buffer sizes it can be observed that the difference between iMC PMU and MBM counts reduce as the buffer size increases. After increasing the buffer size to more than 4X the differences between iMC PMU and MBM become insignificant. Increase the buffer size used in MBM and MBA tests to 4X L3 size to reduce possibility of tests failing due to difference in counts reported by iMC PMU and MBM. Link: https://lore.kernel.org/r/1bd4d8c5fc791234b0a9da94f29a3e278ba2f7ee.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/sierra-forest/xeon-6700-series-processor-with-e-cores-specification-update/errata-details/ # [1] Link: https://edc.intel.com/content/www/us/en/design/products-and-solutions/processors-and-chipsets/birch-stream/xeon-6900-6700-6500-series-processors-with-p-cores-specification-update/011US/errata-details/ # [2] Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Support multiple events associated with iMCReinette Chatre
The resctrl selftests discover needed parameters to perf_event_open() via sysfs. The PMU associated with every memory controller (iMC) is discovered via the /sys/bus/event_source/devices/uncore_imc_N/type file while the read memory bandwidth event type and umask is discovered via /sys/bus/event_source/devices/uncore_imc_N/events/cas_count_read. Newer systems may have multiple events that expose read memory bandwidth. Running a recent kernel that includes commit 6a8a48644c4b ("perf/x86/intel/uncore: Add per-scheduler IMC CAS count events") on these systems expose the multiple events. For example, /sys/bus/event_source/devices/uncore_imc_N/events/cas_count_read_sch0 /sys/bus/event_source/devices/uncore_imc_N/events/cas_count_read_sch1 Support parsing of iMC PMU properties when the PMU may have multiple events to measure read memory bandwidth. The PMU only needs to be discovered once. Split the parsing of event details from actual PMU discovery in order to loop over all events associated with the PMU. Match all events with the cas_count_read prefix instead of requiring there to be one file with that name. Make the parsing code more robust. With strings passed around to create needed paths, use snprintf() instead of sprintf() to ensure there is always enough space to create the path while using the standard PATH_MAX for path lengths. Ensure there is enough room in imc_counters_config[] before attempting to add an entry. Link: https://lore.kernel.org/r/b03ca0fa21a09500c56ee589e32516c2c5effeaf.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Prepare for parsing multiple events per iMCReinette Chatre
The events needed to read memory bandwidth are discovered by iterating over every memory controller (iMC) within /sys/bus/event_source/devices. Each iMC's PMU is assumed to have one event to measure read memory bandwidth that is represented by the sysfs cas_count_read file. The event's configuration is read from "cas_count_read" and stored as an element of imc_counters_config[] by read_from_imc_dir() that receives the index of the array where to store the configuration as argument. It is possible that an iMC's PMU may have more than one event that should be used to measure memory bandwidth. Change semantics to not provide the index of the array to read_from_imc_dir() but instead a pointer to the index. This enables read_from_imc_dir() to store configurations for more than one event by incrementing the index to imc_counters_config[] itself. Ensure that the same type is consistently used for the index as it is passed around during counter configuration. Link: https://lore.kernel.org/r/549e026d20af0381349e645c912e6470fce8bd7e.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Zide Chen <zide.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Do not store iMC counter value in counter config structureReinette Chatre
The MBM and MBA tests compare MBM memory bandwidth measurements against the memory bandwidth event values obtained from each memory controller's PMU. The memory bandwidth event settings are discovered from the memory controller details found in /sys/bus/event_source/devices/uncore_imc_N and stored in struct imc_counter_config. In addition to event settings struct imc_counter_config contains imc_counter_config::return_value in which the associated event value is stored on every read. The event value is consumed and immediately recorded at regular intervals. The stored value is never consumed afterwards, making its storage as part of event configuration unnecessary. Remove the return_value member from struct imc_counter_config. Instead just use a more aptly named "measurement" local variable for use during event reading. Link: https://lore.kernel.org/r/e0b6ad2755e2fd802f54b0bc07eeb90247baca19.1775266384.git.reinette.chatre@intel.com Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Reduce interference from L2 occupancy during cache ↵Reinette Chatre
occupancy test The CMT test creates a new control group that is also capable of monitoring and assigns the workload to it. The workload allocates a buffer that by default fills a portion of the L3 and keeps reading from the buffer, measuring the L3 occupancy at intervals. The test passes if the workload's L3 occupancy is within 15% of the buffer size. The CMT test does not take into account that some of the workload's data may land in L2/L1. Matching L3 occupancy to the size of the buffer while a portion of the buffer can be allocated into L2 is not accurate. Take the L2 cache into account to improve test accuracy: - Reduce the workload's L2 cache allocation to the minimum on systems that support L2 cache allocation. Do so with a new utility in preparation for all L3 cache allocation tests needing the same capability. - Increase the buffer size to accommodate data that may be allocated into the L2 cache. Use a buffer size double the L3 portion to keep using the L3 portion size as goal for L3 occupancy while taking into account that some of the data may be in L2. Running the CMT test on a sample system while introducing significant cache misses using "stress-ng --matrix-3d 0 --matrix-3d-zyx" shows significant improvement in L3 cache occupancy: Before: # Starting CMT test ... # Mounting resctrl to "/sys/fs/resctrl" # Cache size :335544320 # Writing benchmark parameters to resctrl FS # Write schema "L3:0=fffe0" to resctrl FS # Write schema "L3:0=1f" to resctrl FS # Benchmark PID: 7089 # Checking for pass/fail # Pass: Check cache miss rate within 15% # Percent diff=12 # Number of bits: 5 # Average LLC val: 73269248 # Cache span (bytes): 83886080 ok 1 CMT: test After: # Starting CMT test ... # Mounting resctrl to "/sys/fs/resctrl" # Cache size :335544320 # Writing benchmark parameters to resctrl FS # Write schema "L3:0=fffe0" to resctrl FS # Write schema "L3:0=1f" to resctrl FS # Write schema "L2:1=0x1" to resctrl FS # Benchmark PID: 7171 # Checking for pass/fail # Pass: Check cache miss rate within 15% # Percent diff=0 # Number of bits: 5 # Average LLC val: 83755008 # Cache span (bytes): 83886080 ok 1 CMT: test Link: https://lore.kernel.org/r/00445fa64c251b86b86023f87220ee1ad8561460.1775266384.git.reinette.chatre@intel.com Reported-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/lkml/aO+7MeSMV29VdbQs@e133380.arm.com/ Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04selftests/resctrl: Improve accuracy of cache occupancy testReinette Chatre
Dave Martin reported inconsistent CMT test failures. In one experiment the first run of the CMT test failed because of too large (24%) difference between measured and achievable cache occupancy while the second run passed with an acceptable 4% difference. The CMT test is susceptible to interference from the rest of the system. This can be demonstrated with a utility like stress-ng by running the CMT test while introducing cache misses using: stress-ng --matrix-3d 0 --matrix-3d-zyx Below shows an example of the CMT test failing because of a significant difference between measured and achievable cache occupancy when run with interference: # Starting CMT test ... # Mounting resctrl to "/sys/fs/resctrl" # Cache size :335544320 # Writing benchmark parameters to resctrl FS # Benchmark PID: 7011 # Checking for pass/fail # Fail: Check cache miss rate within 15% # Percent diff=99 # Number of bits: 5 # Average LLC val: 235929 # Cache span (bytes): 83886080 not ok 1 CMT: test The CMT test creates a new control group that is also capable of monitoring and assigns the workload to it. The workload allocates a buffer that by default fills a portion of the L3 and keeps reading from the buffer, measuring the L3 occupancy at intervals. The test passes if the workload's L3 occupancy is within 15% of the buffer size. By not adjusting any capacity bitmasks the workload shares the cache with the rest of the system. Any other task that may be running could evict the workload's data from the cache causing it to have low cache occupancy. Reduce interference from the rest of the system by ensuring that the workload's control group uses the capacity bitmask found in the user parameters for L3 and that the rest of the system can only allocate into the inverse of the workload's L3 cache portion. Other tasks can thus no longer evict the workload's data from L3. With the above adjustments the CMT test is more consistent. Repeating the CMT test while generating interference with stress-ng on a sample system after applying the fixes show significant improvement in test accuracy: # Starting CMT test ... # Mounting resctrl to "/sys/fs/resctrl" # Cache size :335544320 # Writing benchmark parameters to resctrl FS # Write schema "L3:0=fffe0" to resctrl FS # Write schema "L3:0=1f" to resctrl FS # Benchmark PID: 7089 # Checking for pass/fail # Pass: Check cache miss rate within 15% # Percent diff=12 # Number of bits: 5 # Average LLC val: 73269248 # Cache span (bytes): 83886080 ok 1 CMT: test Link: https://lore.kernel.org/r/b160592179f88069cdc679563e152007998a0d76.1775266384.git.reinette.chatre@intel.com Reported-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Tested-by: Chen Yu <yu.c.chen@intel.com> Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/lkml/aO+7MeSMV29VdbQs@e133380.arm.com/ Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04Merge tag 'linux_kselftest-fixes-7.1-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kselftest fixes from Shuah Khan: - Fix extra test number increment in ksft_exit_skip() that results in incorrect KTAP result - Fix regression introduced by addition of explicit constructor orders for fixture tests. This addition broke the ordering of those relative to non-fixture tests and the reverse-constructor-order detection * tag 'linux_kselftest-fixes-7.1-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: selftests: harness: Restore order of test functions selftests: kselftest: fix wrong test number in ksft_exit_skip
2026-05-05selftests: ovpn: reduce ping count in test.shRalf Lici
The second stage of test.sh ("run baseline data traffic") performs a basic connectivity check with ping -qfc 500 -w 3. On slower CI instances this is too strict for TCP: the RTT is high enough that 500 echo requests do not reliably complete within 3 seconds, so the stage flakes and the test fails even though the ovpn setup is healthy. Reduce the packet count to 100 for both the plain and 3000-byte pings in that stage. This still verifies peer setup, key exchange, routing, and data-path traffic, without making the basic connectivity check depend on timing out under load. Fixes: 959bc330a439 ("testing/selftests: add test tool and scripts for ovpn module") Signed-off-by: Ralf Lici <ralf@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
2026-05-04kunit: Fix spelling mistakes in comments and messagesJinseok Kim
Fix two spelling mistakes in kunit tooling: Bascially -> Basically higer -> higher Link: https://lore.kernel.org/r/20260501162739.3861-1-always.starving0@gmail.com Signed-off-by: Jinseok Kim <always.starving0@gmail.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04kunit: qemu_configs: Add or1k / openrisc configurationThomas Weißschuh
Add a basic configuration to run kunit tests on or1k / openrisc. Link: https://lore.kernel.org/r/20260427-kunit-or1k-v1-2-9d3109e991e8@weissschuh.net Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-05-04Merge tag 'v7.1-rc2' into nolibc/for-nextThomas Weißschuh
Pick up commit b0aa5e4b087b ("sh: Fix fallout from ZERO_PAGE consolidation") to fix the sh4 selftests. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
2026-05-03tools/nolibc: add support for 32-bit pariscThomas Weißschuh
Extend nolibc to target the 32-bit parisc architecture. 64-bit is not yet supported. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch/msgid.link/20260428-nolibc-hppa-v5-2-d843d573111a@weissschuh.net
2026-05-03selftests/nolibc: avoid function pointer comparisonsThomas Weißschuh
The upcoming parisc support would require libgcc to implement function pointer comparisons. As we try to avoid the libgcc dependency rework the logic to work without such comparisons. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260428-nolibc-hppa-v5-1-d843d573111a@weissschuh.net
2026-05-03tools/nolibc: add support for OpenRISC / or1kThomas Weißschuh
Add support for OpenRISC / or1k to nolibc. _start() uses the same wrapper construct as in arch-sh.h. libgcc is necessary as OpenRISC is missing 64-bit multiplication. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Stafford Horne <shorne@gmail.com> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-openrisc-v2-1-8d7d7a2f3fec@weissschuh.net
2026-05-03selftests/nolibc: use vmlinux for MIPS testsThomas Weißschuh
QEMU for MIPS can also load 'vmlinux'. Slim down the table by using that from the fallback. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-7-a2ca07eab297@weissschuh.net
2026-05-03selftests/nolibc: trim IMAGE mappingsThomas Weißschuh
For many configurations QEMU_ARCH is simply 'vmlinux'. Slim down the table by automatically falling back to 'vmlinux'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-6-a2ca07eab297@weissschuh.net
2026-05-03selftests/nolibc: trim DEFCONFIG mappingsThomas Weißschuh
For many configurations DEFCONFIG is simply 'defconfig'. Slim down the table by automatically falling back to 'defconfig'. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-5-a2ca07eab297@weissschuh.net
2026-05-03selftests/nolibc: trim QEMU_ARCH mappingsThomas Weißschuh
For many configurations QEMU_ARCH is the same as XARCH. Slim down the table by automatically falling back to XARCH. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-4-a2ca07eab297@weissschuh.net
2026-05-03selftests/nolibc: use QEMU_ARCH for QEMU_ARCH_USERThomas Weißschuh
The current logic forces the XARCH to QEMU_ARCH mapping to contain entries for all architectures. This will change. To avoid duplication of that logic, reuse the already computed QEMU_ARCH variable. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-3-a2ca07eab297@weissschuh.net
2026-05-03selftests/nolibc: drop riscv configurationThomas Weißschuh
The riscv configuration is just a duplication of the riscv64 one. Remove it. Passing ARCH=riscv will be rerouted to riscv64 anyways. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-2-a2ca07eab297@weissschuh.net
2026-05-03selftests/nolibc: align QEMU_ARCH_mips32beThomas Weißschuh
The variable is slightly misaligned. Fix that. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260429-nolibc-qemu-arch-v1-1-a2ca07eab297@weissschuh.net
2026-05-02selftests: tls: add test for data loss on small pipeJakub Kicinski
Add selftest for data loss on short splice. Link: https://patch.msgid.link/20260429222944.2139041-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02selftests/tc-testing: Add tests that force red and sfb to dequeue from ↵Victor Nogueira
child's gso_skb Create 4 test cases: - Force red to dequeue from its child's gso_skb with qfq leaf - Force sfb to dequeue from its child's gso_skb with qfq leaf - Force red to dequeue from its child's gso_skb with dualpi2 leaf - Force sfb to dequeue from its child's gso_skb with dualpi2 leaf All of them have tbf followed by red (or sfb) followed by qfq (or dualpi2). Since tbf calls its child's peek followed by qdisc_dequeue_peeked, it will force red/sfb to call their child's peek. In this case, since the child (qfq/dualpi2) has qdisc_peek_dequeued as its peek callback, the packet will be stored in its gso_skb queue. During the subsequent call to qdisc_dequeue_peeked, red/sfb will have to dequeue from the child's gso_skb to retrieve the packet. Not doing so will cause a NULL ptr deref which was happening before a recent fix. Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260430152957.194015-4-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-02tools/headers: Regenerate stddef.h to fix BPF selftestsPaul Chaignon
With commit dacbfc167808 ("crypto: af_alg - Annotate struct af_alg_iv with __counted_by"), two selftests, test_tag and crypto_sanity, now indirectly rely on the __counted_by macro. On systems with commit dacbfc167808 in the installed UAPI headers, the selftests build fails with: In file included from tools/testing/selftests/bpf/prog_tests/crypto_sanity.c:7: /usr/include/linux/if_alg.h:45:22: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘__counted_by’ 45 | __u8 iv[] __counted_by(ivlen); | ^~~~~~~~~~~~ This patch fixes it by regenerating stddef.h in tools/include using the instructions from commit a778f5d46b62 ("tools/headers: Pull in stddef.h to uapi to fix BPF selftests build in CI"). Fixes: dacbfc167808 ("crypto: af_alg - Annotate struct af_alg_iv with __counted_by") Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Reviewed-by: Alan Maguire <alan.maguire@oracle.com> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/8da8ef16055aa452d940668ed5359ce54adc6b0b.1777715500.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2026-05-01selftest: net: Add test for TCP flow failover with ECMP routes.Kuniyuki Iwashima
Without the previous commit, TCP failed to switch to alternative IPv6 routes immediately upon carrier loss. It would persist with the dead route until reaching the threshold net.ipv4.tcp_retries1, leading to unnecessary delays in failover. Let's add a selftest for this scenario to ensure TCP fails over immediately upon a carrier loss event. Before: TEST: TCP IPv4 failover [ OK ] TEST: TCP IPv6 failover [FAIL] After: TEST: TCP IPv4 failover [ OK ] TEST: TCP IPv6 failover [ OK ] Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Signed-off-by: Sagarika Sharma <sharmasagarika@google.com> Link: https://patch.msgid.link/20260430200909.527827-3-sharmasagarika@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01selftests: drv-net: Enable ntuple-filters if supportedDimitri Daskalakis
Certain devices which support ntuple-filters do not enable the feature by default. The existing tests will skip (if they check for the feature), or fail if they blindly attempt to install rules. Therefore, attempt to turn on ntuple-filters if the device supports them. Signed-off-by: Dimitri Daskalakis <daskald@meta.com> Reviewed-by: Joe Damato <joe@dama.to> Link: https://patch.msgid.link/20260430165217.3700469-1-dimitri.daskalakis1@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-05-01Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - Avoid writing an uninitialised stack variable to POR_EL0 on sigreturn if the poe_context record is absent - Reserve one more page for the early 4K-page kernel mapping to cover the extra [_text, _stext) split introduced by the non-executable read-only mapping - Force the arch_local_irq_*() wrappers to be __always_inline so that noinstr entry and idle paths cannot call out-of-line, instrumentable copies - Fix potential sign extension in the arm64 SCS unwinder's DWARF advance_loc4 decoding - Tolerate arm64 ACPI platforms with only WFI and no deeper PSCI idle states, restoring cpuidle registration on such systems - Include the UAPI <asm/ptrace.h> header in the arm64 GCS libc test rather than carrying a duplicate struct user_gcs definition (the original #ifdef NT_ARM_GCS was wrong to cover the structure definition as it would be masked out if the toolchain defined it) * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: signal: Preserve POR_EL0 if poe_context is missing arm64: Reserve an extra page for early kernel mapping kselftest/arm64: Include <asm/ptrace.h> for user_gcs definition ACPI: arm64: cpuidle: Tolerate platforms with no deep PSCI idle states arm64/irqflags: __always_inline the arch_local_irq_*() helpers arm64/scs: Fix potential sign extension issue of advance_loc4
2026-05-01selftests/rseq: Don't run tests with runner scripts outside of the scriptsMark Brown
The rseq selftests include two runner scripts run_param_test.sh and run_syscall_errors_test.sh which set up the environment for test binaries and run them with various parameters. Currently we list these test binaries in TEST_GEN_PROGS but this results in the kselftest framework running them directly as well as via the runners, resulting in duplication and spurious failures when the environment is not correctly set up (eg, if glibc tries to use rseq). Move the binaries the runners invoke to TEST_GEN_PROGS_EXTENDED, binaries listed there are built but not run by the framework. The param_test benchmarks are not moved since they are not run by run_param_test.sh. Fixes: 830969e7821a ("selftests/rseq: Implement time slice extension test") Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://patch.msgid.link/20260423-selftests-rseq-use-runner-v1-1-e13a133754c1@kernel.org Cc: stable@vger.kernel.org
2026-05-01Merge tag 'mm-hotfixes-stable-2026-04-30-15-39' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull MM fixes from Andrew Morton: "20 hotfixes. All are for MM (and for MMish maintainers). 9 are cc:stable and the remainder are for post-7.0 issues or aren't deemed suitable for backporting. There are two DAMON series from SeongJae Park which address races which could lead to use-after-free errors, and avoid the possibility of presenting stale parameter values to users" * tag 'mm-hotfixes-stable-2026-04-30-15-39' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: mm: memcontrol: fix rcu unbalance in get_non_dying_memcg_end() mm/userfaultfd: detect VMA type change after copy retry in mfill_copy_folio_retry() MAINTAINERS: remove stale kdump project URL mm/damon/stat: detect and use fresh enabled value mm/damon/lru_sort: detect and use fresh enabled and kdamond_pid values mm/damon/reclaim: detect and use fresh enabled and kdamond_pid values selftests/mm: specify requirement for PROC_MEM_ALWAYS_FORCE=y mm/damon/sysfs-schemes: protect path kfree() with damon_sysfs_lock mm/damon/sysfs-schemes: protect memcg_path kfree() with damon_sysfs_lock MAINTAINERS: update Li Wang's email address MAINTAINERS, mailmap: update email address for Qi Zheng MAINTAINERS: update Liam's email address mm/hugetlb_cma: round up per_node before logging it MAINTAINERS: fix regex pattern in CORE MM category mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap() mm: start background writeback based on per-wb threshold for strictlimit BDIs kho: fix error handling in kho_add_subtree() liveupdate: fix return value on session allocation failure mailmap: update entry for Dan Carpenter vmalloc: fix buffer overflow in vrealloc_node_align()
2026-05-01kselftest/arm64: Include <asm/ptrace.h> for user_gcs definitionLeo Yan
kselftest includes kernel uAPI headers with option: -isystem $(top_srcdir)/usr/include Include <asm/ptrace.h> in libc-gcs.c for the definition of struct user_gcs from the uAPI headers, and remove the redundant definition in gcs-util.h. This fixes a compilation error on systems where the toolchain defines NT_ARM_GCS. Fixes: a505a52b4e29 ("kselftest/arm64: Add a GCS test program built with the system libc") Signed-off-by: Leo Yan <leo.yan@arm.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2026-04-30selftests/net: packetdrill: add tcp_syncookies_ip[46]_9kEric Dumazet
These tests check syncookie mode is able to reconstruct some client options when TCP TS are used: - wscale option. - sackOK. - MSS (in a limited way, especially for IPv4). - ECN : not enabled. Note that IPv4 and IPv6 have different msstab[] values: IPv4 msstab[4] = { 536, 1300, 1440, 1460 } IPv6 msstab[4] = { 1280 - 60, 1480 - 60, 1500 - 60, 9000 - 60 } IPv4 is currently capping SND_MSS to 1460, even on a 9K MTU network. Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Neal Cardwell <ncardwell@google.com> Link: https://patch.msgid.link/20260430021444.2929534-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30selftests: net: Add tests for ARP probe and DAD NS handlingDanielle Ratson
Add test cases to verify that ARP probes and DAD Neighbor Solicitations are handled correctly by the bridge neighbor suppression feature. When neighbor suppression is enabled on a bridge VXLAN port, the bridge should reply to ARP/NS messages on behalf of remote hosts when both FDB and neighbor entries exist, and the answer is known. However, when either the FDB or the neighbor exists, ARP probes / DAD NS should be treated like regular ARP requests / NS and flood to VXLAN. Add two new test functions: neigh_suppress_arp_probe(): Tests ARP probe handling by triggering duplicate address detection using arping -D. Verifies that probes are flooded when the bridge doesn't know the answer, and suppressed when FDB and neighbor entries exist. neigh_suppress_dad_ns(): Tests DAD NS handling by constructing DAD NS packets using mausezahn and verifies correct flooding/suppression behavior. Before the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [FAIL] TEST: ARP probe suppression [FAIL] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [FAIL] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [FAIL] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [FAIL] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [FAIL] TEST: DAD NS proxy NA reply [FAIL] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [FAIL] Tests passed: 10 Tests failed: 10 After the previous patch: $ ./test_bridge_neigh_suppress.sh -t "neigh_suppress_arp_probe neigh_suppress_dad_ns" Per-port ARP probe suppression ------------------------------ TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: ARP probe suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: arping [ OK ] TEST: ARP probe suppression [ OK ] TEST: neighbor removal [ OK ] TEST: ARP probe suppression [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: ARP probe suppression [ OK ] Per-port DAD NS suppression --------------------------- TEST: DAD NS suppression [ OK ] TEST: "neigh_suppress" is on [ OK ] TEST: DAD NS suppression [ OK ] TEST: FDB and neighbor entry installation [ OK ] TEST: DAD NS suppression [ OK ] TEST: neighbor removal [ OK ] TEST: DAD NS suppression [ OK ] TEST: DAD NS proxy NA reply [ OK ] TEST: "neigh_suppress" is off [ OK ] TEST: DAD NS suppression [ OK ] Tests passed: 20 Tests failed: 0 Signed-off-by: Danielle Ratson <danieller@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260429062405.1386417-3-danieller@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski
Cross-merge networking fixes after downstream PR (net-7.1-rc2). No conflicts, or adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-30PM: tools: pm-graph: fix ValueError when parsing incomplete device propertiesGongwei Li
When parsing device properties from ftrace data, the devprops() function assumes that each line has at least three fields and that the third field (f[2]) always contains a valid integer. However, due to incomplete or corrupted ftrace logs, f[2] may be missing, empty, or non-existent. This can lead to the following error: Traceback (most recent call last): File "../sleepgraph.py", line 7142, in <module> stamp = rerunTest(sysvals.outdir) File "../sleepgraph.py", line 6255, in rerunTest testruns, stamp = processData() File "../sleepgraph.py", line 6181, in processData testruns, error = parseTraceLog(live) File "../sleepgraph.py", line 3470, in parseTraceLog tp, tf = loadTraceLog() File "../sleepgraph.py", line 3398, in loadTraceLog if tp.stampInfo(line, sysvals): File "../sleepgraph.py", line 3073, in stampInfo self.parsePlatformInfo(line, sv) File "../sleepgraph.py", line 3177, in parsePlatformInfo sv.devprops = self.devprops(sv.b64unzip(info)) File "../sleepgraph.py", line 3158, in devprops if int(f[2]): ValueError: invalid literal for int() with base 10: '' To prevent this crash, add proper validation before accessing. Signed-off-by: Gongwei Li <ligongwei@kylinos.cn> Acked-by: Todd Brandt <todd.e.brandt@intel.com> [ rjw: Subject tweak ] Link: https://patch.msgid.link/20260424071208.3610628-1-13875017792@163.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2026-04-30Merge tag 'net-7.1-rc2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Paolo Abeni: "Including fixes from netfilter. Current release - regressions: - ipmr: free mr_table after RCU grace period. Previous releases - regressions: - core: add net_iov_init() and use it to initialize ->page_type - sched: taprio: fix NULL pointer dereference in class dump - netfilter: nf_tables: - use list_del_rcu for netlink hooks - fix strict mode inbound policy matching - tcp: make probe0 timer handle expired user timeout - vrf: fix a potential NPD when removing a port from a VRF - eth: ice: - fix NULL pointer dereference in ice_reset_all_vfs() - fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw Previous releases - always broken: - page_pool: fix memory-provider leak in error path - sched: sch_cake: annotate data-races in cake_dump_stats() - mptcp: fix scheduling with atomic in timestamp sockopt - psp: check for device unregister when creating assoc - tls: fix strparser anchor skb leak on offload RX setup failure - eth: - stmmac: prevent NULL deref when RX memory exhausted - airoha: do not read uninitialized fragment address - rtl8150: fix use-after-free in rtl8150_start_xmit() Misc: - add Ido Schimmel as IPv4/IPv6 maintainer - add David Heidelberg as NFC subsystem maintainer" * tag 'net-7.1-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (79 commits) net/sched: cls_flower: revert unintended changes sfc: fix error code in efx_devlink_info_running_versions() net: tls: fix strparser anchor skb leak on offload RX setup failure ice: add dpll peer notification for paired SMA and U.FL pins ice: fix missing dpll notifications for SW pins dpll: export __dpll_pin_change_ntf() for use under dpll_lock ice: fix SMA and U.FL pin state changes affecting paired pin ice: fix missing SMA pin initialization in DPLL subsystem ice: fix infinite recursion in ice_cfg_tx_topo via ice_init_dev_hw ice: fix NULL pointer dereference in ice_reset_all_vfs() iavf: add VIRTCHNL_OP_ADD_VLAN to success completion handler iavf: wait for PF confirmation before removing VLAN filters iavf: stop removing VLAN filters from PF on interface down iavf: rename IAVF_VLAN_IS_NEW to IAVF_VLAN_ADDING page_pool: fix memory-provider leak in page_pool_create_percpu() error path bonding: 3ad: implement proper RCU rules for port->aggregator net: airoha: Do not return err in ndo_stop() callback hv_sock: fix ARM64 support MAINTAINERS: update the IPv4/IPv6 entry and add Ido Schimmel selftests: drv-net: clarify linters and frameworks in README ...
2026-04-30selftests/bpf: Test insns processed breakdownPaul Chaignon
This patch covers in global subprog selftests the new verifier log with the breakdown of instructions processed by global subprogs. The test ensures the log line is present and that it has the right number of subcounts. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/bpf/3a5157f4573edaa8846f6fc4041f715136f693b1.1777538384.git.paul.chaignon@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
2026-04-30net/tcp-ao: Use crypto library API instead of crypto_ahashEric Biggers
Currently the kernel's TCP-AO implementation does the MAC and KDF computations using the crypto_ahash API. This API is inefficient and difficult to use, and it has required extensive workarounds in the form of per-CPU preallocated objects (tcp_sigpool) to work at all. Let's use lib/crypto/ instead. This means switching to straightforward stack-allocated structures, virtually addressed buffers, and direct function calls. It also means removing quite a bit of error handling. This makes TCP-AO quite a bit faster. This also enables many additional cleanups, which later commits will handle: removing tcp-sigpool, removing support for crypto_tfm cloning, removing more error handling, and replacing more dynamically-allocated buffers with stack buffers based on the now-statically-known limits. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-3-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-30net/tcp-ao: Drop support for most non-RFC-specified algorithmsEric Biggers
RFC 5926 (https://datatracker.ietf.org/doc/html/rfc5926) specifies the use of AES-128-CMAC and HMAC-SHA1 with TCP-AO. This includes a specification for how traffic keys shall be derived for each algorithm. Support for any other algorithms with TCP-AO isn't standardized, though an expired Internet Draft (a work-in-progress document, not a standard) from 2019 does propose adding HMAC-SHA256 support: https://datatracker.ietf.org/doc/html/draft-nayak-tcp-sha2-03 Since both documents specify the KDF for each algorithm individually, it isn't necessarily clear how any other algorithm should be integrated. Nevertheless, the Linux implementation of TCP-AO allows userspace to specify the MAC algorithm as a string tcp_ao_add::alg_name naming either "cmac(aes128)" or an arbitrary algorithm in the crypto_ahash API. The set of valid strings is undocumented. The implementation assumes that "cmac(aes128)" is the only algorithm that requires an entropy extraction step and that all algorithms accept keys with length equal to the untruncated MAC; thus, arbitrary HMAC algorithms probably do work, but some other MAC algorithms like AES-256-CMAC have never actually worked. Unfortunately, this undocumented string allows many obsolete, insecure, or redundant algorithms. For example, "hmac(md5)" and the non-cryptographic "crc32" are accepted. It also ties the implementation to crypto_ahash and requires that most memory be dynamically allocated, making the implementation unnecessarily complex and inefficient. Still furthermore, this implementation requires the crypto API to support "transformation cloning", whose only user is this feature. Fortunately, it's very likely that only a few algorithms are actually used in practice. Let's restrict the set of allowed algorithms to "cmac(aes128)" (or "cmac(aes)" with keylen=16), "hmac(sha1)", and "hmac(sha256)". The first two are the actually standard ones, while HMAC-SHA256 seems like a reasonable algorithm to continue supporting as a Linux extension, considering the Internet Draft for it and the fact that SHA-256 is the usual choice of upgrade from the outdated SHA-1. If any other algorithm ever turns out to be needed, e.g. HMAC-SHA512, it can of course be (re-)added in library form. However, note that the TCP options space limits TCP-AO MACs to 20 bytes (160 bits) anyway, which limits the potential benefit of any further upgrade to the algorithm. Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Link: https://patch.msgid.link/20260427172727.9310-2-ebiggers@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-04-29selftests: drv-net: rss: add case for field config on RSS contextJakub Kicinski
We had some issues with a suspected traffic imbalance on an RSS context. Make sure the tests cover the RXFH field selection vs additional contexts. Tested-by: Pavan Chebbi <pavan.chebbi@broadcom.com> Link: https://patch.msgid.link/20260428203624.1224387-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-29selftests: drv-net: clarify linters and frameworks in READMEJakub Kicinski
Minor clarifications in the README: - call out what linters we expect to be clean - make it clear that by "frameworks" we mean code under lib/ not just factoring code out in the same file Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2026-04-29tools/sched_ext: scx_qmap: Port to cid-form struct_opsTejun Heo
Flip qmap's struct_ops to bpf_sched_ext_ops_cid. The kernel now passes cids and cmasks to callbacks directly, so the per-callback cpu<->cid translations that the prior patch added drop out and cpu_ctxs[] is reindexed by cid. Cpu-form kfunc calls switch to their cid-form counterparts. The cpu-only kfuncs (idle/any pick, cpumask iteration) have no cid substitute. Their callers already moved to cmask scans against qa_idle_cids and taskc->cpus_allowed in the prior patch, so the kfunc calls drop here without behavior changes. set_cmask is wired up via cmask_copy_from_kernel() to copy the kernel-supplied cmask into the arena-resident taskc cmask. The cpuperf monitor iterates the cid-form perf kfuncs. v4: Match scx_bpf_cid_override()'s 2-arg form, drop the shard test plumbing, bound nr_cpu_ids for the verifier, and switch mode 3 from bad-mono to bad-range (Changwoo, Andrea). Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Reviewed-by: Changwoo Min <changwoo@igalia.com> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-04-29tools/sched_ext: scx_qmap: Add cmask-based idle tracking and cid-based idle pickTejun Heo
Switch qmap's idle-cpu picker from scx_bpf_pick_idle_cpu() to a BPF-side bitmap scan, still under cpu-form struct_ops. qa_idle_cids tracks idle cids (updated in update_idle / cpu_offline) and each task's taskc->cpus_allowed tracks its allowed cids (built in set_cpumask / init_task); select_cpu / enqueue scan the intersection for an idle cid. Callbacks translate cpu <-> cid on entry; cid-qmap-port drops those translations. The scan is barebone - no core preference or other topology-aware picks like the in-kernel picker - but qmap is a demo and this is enough to exercise the plumbing. v3: qmap_init() refuses to load when nr_cids exceeds SCX_QMAP_MAX_CPUS; task_ctx's flex array would otherwise overflow into the next slab entry. (Sashiko) Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Reviewed-by: Changwoo Min <changwoo@igalia.com> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-04-29tools/sched_ext: scx_qmap: Restart on hotplug instead of cpu_online/offlineTejun Heo
The cid mapping is built from the online cpu set at scheduler enable and stays valid for that set; routine hotplug invalidates it. The default cid behavior is to restart the scheduler so the mapping gets rebuilt against the new online set, and that requires not implementing cpu_online / cpu_offline (which suppress the kernel's ACT_RESTART). Drop the two ops along with their print_cpus() helper - the cluster view was only useful as a hotplug demo and is meaningless over the dense cid space the scheduler will move to. Wire main() to handle the ACT_RESTART exit by reopening the skel and reattaching, matching the pattern in scx_simple / scx_central / scx_flatcg etc. Reset optind so getopt re-parses argv into the fresh skel rodata each iteration. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Reviewed-by: Changwoo Min <changwoo@igalia.com> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-04-29sched_ext: Add bpf_sched_ext_ops_cid struct_ops typeTejun Heo
cpumask is awkward from BPF and unusable from arena; cid/cmask work in both. Sub-sched enqueue will need cmask. Without a full cid interface, schedulers end up mixing forms - a subtle-bug factory. Add sched_ext_ops_cid, which mirrors sched_ext_ops with cid/cmask replacing cpu/cpumask in the topology-carrying callbacks. cpu_acquire/cpu_release are deprecated and absent; a prior patch moved them past @priv so the cid-form can omit them without disturbing shared-field offsets. The two structs share byte-identical layout up to @priv, so the existing bpf_scx init/check hooks, has_op bitmap, and scx_kf_allow_flags[] are offset-indexed and apply to both. BUILD_BUG_ON in scx_init() pins the shared-field and renamed-callback offsets so any future drift trips at boot. The kernel<->BPF boundary translates between cpu and cid: - A static key, enabled on cid-form sched load, gates the translation so cpu-form schedulers pay nothing. - dispatch, update_idle, cpu_online/offline and dump_cpu translate the cpu arg at the callsite. - select_cpu also translates the returned cid back to a cpu. - set_cpumask is wrapped to synthesize a cmask in a per-cpu scratch before calling the cid-form callback. All scheds in a hierarchy share one form. The static key drives the hot-path branch. v2: Use struct_size() for the set_cmask_scratch percpu alloc. Move cid-shard fields and assertions into the later cid-shard patch. v3: Drop `static` on scx_set_cmask_scratch; add extern in ext_internal.h. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Reviewed-by: Changwoo Min <changwoo@igalia.com> Reviewed-by: Andrea Righi <arighi@nvidia.com>
2026-04-29sched_ext: Add cid-form kfunc wrappers alongside cpu-formTejun Heo
cpumask is awkward from BPF and unusable from arena; cid/cmask work in both. Sub-sched enqueue will need cmask. Without full cid coverage a scheduler has to mix cid and cpu forms, which is a subtle-bug factory. Close the gap with a cid-native interface. Pair every cpu-form kfunc that takes a cpu id with a cid-form equivalent (kick, task placement, cpuperf query/set, per-cpu current task, nr-cpu-ids). Add two cid-natives with no cpu-form sibling: scx_bpf_this_cid() (cid of the running cpu, scx equivalent of bpf_get_smp_processor_id) and scx_bpf_nr_online_cids(). scx_bpf_cpu_rq is deprecated; no cid-form counterpart. NUMA node info is reachable via scx_bpf_cid_topo() on the BPF side. Each cid-form wrapper is a thin cid -> cpu translation that delegates to the cpu path, registered in the same context sets so usage constraints match. Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Cheng-Yang Chou <yphbchou0911@gmail.com> Reviewed-by: Changwoo Min <changwoo@igalia.com> Reviewed-by: Andrea Righi <arighi@nvidia.com>