v6.9.3-scx1 #27
Merged
v6.9.3-scx1 #27
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ Upstream commit 582c1ae ] pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action() fails, the irq vector is not freed, which leads to a memory leak. Replace the devm_add_action with devm_add_action_or_reset to ensure the irq vector can be destroyed when it fails. Fixes: 66637ab ("drivers/perf: hisi: add driver for HNS3 PMU") Signed-off-by: Hao Chen <[email protected]> Signed-off-by: Junhao He <[email protected]> Reviewed-by: Jijie Shao <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit cd42ba1 ] This came while reviewing commit c4e86b4 ("net: add two more call_rcu_hurry()"). Paolo asked if adding one synchronize_rcu() would help. While synchronize_rcu() does not help, making sure to call rcu_barrier() before msleep(wait) is definitely helping to make sure lazy call_rcu() are completed. Instead of waiting ~100 seconds in my tests, the ref_tracker splats occurs one time only, and netdev_wait_allrefs_any() latency is reduced to the strict minimum. Ideally we should audit our call_rcu() users to make sure no refcount (or cascading call_rcu()) is held too long, because rcu_barrier() is quite expensive. Fixes: 0e4be9e ("net: use exponential backoff in netdev_wait_allrefs") Signed-off-by: Eric Dumazet <[email protected]> Link: https://lore.kernel.org/all/[email protected]/T/#m76d73ed6b03cd930778ac4d20a777f22a08d6824 Reviewed-by: Jiri Pirko <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…context" [ Upstream commit d301a71 ] The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization. Fixes: 1da177e ("Linux-2.6.12-rc2") Signed-off-by: Finn Thain <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/419fcc09d0e563b425c419053d02236b044d86b0.1710298421.git.fthain@linux-m68k.org Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit b6dd09b ] Syzkaller reports [1] hitting a warning which is caused by presence of a wrong endpoint type at the URB sumbitting stage. While there was a check for a specific 4th endpoint, since it can switch types between bulk and interrupt, other endpoints are trusted implicitly. Similar warning is triggered in a couple of other syzbot issues [2]. Fix the issue by doing a comprehensive check of all endpoints taking into account difference between high- and full-speed configuration. [1] Syzkaller report: ... WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 </TASK> [2] Related syzkaller crashes: Link: https://syzkaller.appspot.com/bug?extid=e394db78ae0b0032cb4d Link: https://syzkaller.appspot.com/bug?extid=9468df99cb63a4a4c4e1 Reported-and-tested-by: [email protected] Fixes: a84fab3 ("carl9170: 802.11 rx/tx processing and usb backend") Signed-off-by: Nikita Zhandarovich <[email protected]> Acked-By: Christian Lamparter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 0db63c0 ] The verifier assumes that 'sk' field in 'struct socket' is valid and non-NULL when 'socket' pointer itself is trusted and non-NULL. That may not be the case when socket was just created and passed to LSM socket_accept hook. Fix this verifier assumption and adjust tests. Reported-by: Liam Wisehart <[email protected]> Acked-by: Kumar Kartikeya Dwivedi <[email protected]> Fixes: 6fcd486 ("bpf: Refactor RCU enforcement in the verifier.") Signed-off-by: Alexei Starovoitov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 19468ed ] The cgroup1_hierarchy test uses setup_classid_environment to setup cgroupv1 environment. The problem is that the environment is set in /sys/fs/cgroup and therefore, if not run under an own mount namespace, effectively deletes all system cgroups: $ ls /sys/fs/cgroup | wc -l 27 $ sudo ./test_progs -t cgroup1_hierarchy #41/1 cgroup1_hierarchy/test_cgroup1_hierarchy:OK #41/2 cgroup1_hierarchy/test_root_cgid:OK #41/3 cgroup1_hierarchy/test_invalid_level:OK #41/4 cgroup1_hierarchy/test_invalid_cgid:OK #41/5 cgroup1_hierarchy/test_invalid_hid:OK #41/6 cgroup1_hierarchy/test_invalid_cgrp_name:OK #41/7 cgroup1_hierarchy/test_invalid_cgrp_name2:OK #41/8 cgroup1_hierarchy/test_sleepable_prog:OK #41 cgroup1_hierarchy:OK Summary: 1/8 PASSED, 0 SKIPPED, 0 FAILED $ ls /sys/fs/cgroup | wc -l 1 To avoid this, run setup_cgroup_environment first which will create an own mount namespace. This only affects the cgroupv1_hierarchy test as all other cgroup1 test progs already run setup_cgroup_environment prior to running setup_classid_environment. Also add a comment to the header of setup_classid_environment to warn against this invalid usage in future. Fixes: 3607692 ("selftests/bpf: Add selftests for cgroup1 hierarchy") Signed-off-by: Viktor Malik <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit e120b63 ] Syzkaller reports [1] hitting a warning about an endpoint in use not having an expected type to it. Fix the issue by checking for the existence of all proper endpoints with their according types intact. Sadly, this patch has not been tested on real hardware. [1] Syzkaller report: ------------[ cut here ]------------ usb 1-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504 ... Call Trace: <TASK> ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 </TASK> Reported-and-tested-by: [email protected] Fixes: b7d572e ("ar5523: Add new driver") Signed-off-by: Nikita Zhandarovich <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 3e55111 ] clk_round_rate() can return not only zero if requested frequency can not be provided but also negative error code so add check for it too. Also change type of variable holding clk_round_rate() result from unsigned long to long. It's safe due to clk_round_rate() returns long. Fixes: 329db10 ("pwm: meson: make full use of common clock framework") Signed-off-by: Dmitry Rokosov <[email protected]> Signed-off-by: George Stark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 32c44e1 ] While calculating frequency for the given period u64 numbers are multiplied before division what can lead to overflow in theory so use secure mul_u64_u64_div_u64() which handles overflow correctly. Fixes: 329db10 ("pwm: meson: make full use of common clock framework") Suggested-by: Uwe Kleine-König <[email protected]> Signed-off-by: George Stark <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…_CREATE [ Upstream commit 543576e ] bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association. Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks. Fixes: af6eea5 ("bpf: Implement bpf_link-based cgroup BPF program attachment") Link: https://lore.kernel.org/bpf/[email protected]/ Reported-by: [email protected] Signed-off-by: Stanislav Fomichev <[email protected]> Acked-by: Eduard Zingerman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 1422ae0 ] arch/sh/kernel/kprobes.c:52:16: warning: no previous prototype for 'arch_copy_kprobe' [-Wmissing-prototypes] Although SH kprobes support was only merged in v2.6.28, it missed the earlier removal of the arch_copy_kprobe() callback in v2.6.15. Based on the powerpc part of commit 49a2a1b ("[PATCH] kprobes: changed from using spinlock to mutex"). Fixes: d39f545 ("sh: Add kprobes support.") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/717d47a19689cc944fae6e981a1ad7cae1642c89.1709326528.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit b5319c9 ] This reverts commit cadc4e1. Commit cadc4e1 ("sh: Handle calling csum_partial with misaligned data") causes bad checksum calculations on unaligned data. Reverting it fixes the problem. # Subtest: checksum # module: checksum_kunit 1..5 # test_csum_fixed_random_inputs: ASSERTION FAILED at lib/checksum_kunit.c:500 Expected ( u64)result == ( u64)expec, but ( u64)result == 53378 (0xd082) ( u64)expec == 33488 (0x82d0) # test_csum_fixed_random_inputs: pass:0 fail:1 skip:0 total:1 not ok 1 test_csum_fixed_random_inputs # test_csum_all_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:525 Expected ( u64)result == ( u64)expec, but ( u64)result == 65281 (0xff01) ( u64)expec == 65280 (0xff00) # test_csum_all_carry_inputs: pass:0 fail:1 skip:0 total:1 not ok 2 test_csum_all_carry_inputs # test_csum_no_carry_inputs: ASSERTION FAILED at lib/checksum_kunit.c:573 Expected ( u64)result == ( u64)expec, but ( u64)result == 65535 (0xffff) ( u64)expec == 65534 (0xfffe) # test_csum_no_carry_inputs: pass:0 fail:1 skip:0 total:1 not ok 3 test_csum_no_carry_inputs # test_ip_fast_csum: pass:1 fail:0 skip:0 total:1 ok 4 test_ip_fast_csum # test_csum_ipv6_magic: pass:1 fail:0 skip:0 total:1 ok 5 test_csum_ipv6_magic # checksum: pass:2 fail:3 skip:0 total:5 # Totals: pass:2 fail:3 skip:0 total:5 not ok 22 checksum Fixes: cadc4e1 ("sh: Handle calling csum_partial with misaligned data") Signed-off-by: Guenter Roeck <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit b473c0e ] Use the correct WMM AC queue instead of the MGMT one to fix potential issues with aggregation sequence number tracking. Drop non-bufferable packets. Fixes: fca9615 ("mt76: mt7603: fix up hardware queue index for PS filtered packets") Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 21de5f7 ] This flag is needed for the PSE client reset. Fixes watchdog reset issues. Fixes: c677dda ("wifi: mt76: mt7603: improve watchdog reset reliablity") Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit cb47c7b ] The wcid can be NULL. It should be checked for validity before dereferencing it to avoid crash. Fixes: 098428c ("wifi: mt76: connac: set correct muar_idx for mt799x chipsets") Signed-off-by: Muhammad Usama Anjum <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 66ffcb9 ] Fixes issues with scanning and low power output at some rates. Fixes: f75e477 ("wifi: mt76: mt7996: add txpower setting support") Signed-off-by: Chad Monroe <[email protected]> Signed-off-by: Ryder Lee <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit fa46bd6 ] Before sending suspend & wow command to FW, its length should be 4-bytes alignd. Fixes: c948b5d ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 1ac710a ] Set intr1 to 0 in mt7996_irq_tasklet() in order to avoid possible uninitialized variable usage if wed is not active for hif2. Fixes: 83eafc9 ("wifi: mt76: mt7996: add wed tx support") Signed-off-by: Lorenzo Bianconi <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…mperature [ Upstream commit 474b941 ] Without this commit, reading chip temperature will cause memory leakage. Fixes: 6879b2e ("wifi: mt76: mt7996: add thermal sensor device support") Reported-by: Ryder Lee <[email protected]> Signed-off-by: Howard Hsu <[email protected]> Signed-off-by: Shayne Chen <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 64bfcdb ] This is expected by the firmware of older chipsets as well, though it may not have been as strongly required as on mt799x Fixes: 098428c ("wifi: mt76: connac: set correct muar_idx for mt799x chipsets") Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 7c13ef1 ] We just failed to retrieve pattern, so we need to print spec instead. Fixes: ddc6b04 ("libbpf: Add bpf_program__attach_kprobe_multi_opts function") Reported-by: Andrii Nakryiko <[email protected]> Signed-off-by: Jiri Olsa <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
…exing [ Upstream commit 838c7b8 ] Before request->channels[] can be used, request->n_channels must be set. Additionally, address calculations for memory after the "channels" array need to be calculated from the allocation base ("request") rather than via the first "out of bounds" index of "channels", otherwise run-time bounds checking will throw a warning. Reported-by: Nathan Chancellor <[email protected]> Fixes: e3eac9f ("wifi: cfg80211: Annotate struct cfg80211_scan_request with __counted_by") Signed-off-by: Kees Cook <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
… mode [ Upstream commit baaf806 ] After enabling packet offload, the TX will be stuck after resume from WoWLAN mode. And the 8852c gets error messages like rtw89_8852ce 0000:04:00.0: No busy txwd pages available rtw89_8852ce 0000:04:00.0: queue 0 txwd 100 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 101 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 102 is not idle rtw89_8852ce 0000:04:00.0: queue 0 txwd 103 is not idle If suspend/resume many times that firmware will download failed and disconnection. To fix these issues, We removed the rtw89_hci_disable_intr() and rtw89_hci_enable_intr() during rtw89_wow_swap_fw() to prevent add packet offload can't receive c2h back due to interrupt disable. Only 8852C and 8922A needs to disable interrupt before downloading fw. Furthermore, we avoid using low power HCI mode on WoWLAN mode, to prevent interrupt enabled, then get interrupt and calculate RXBD mismatched due to software RXBD index already reset but hardware RXBD index not yet. Fixes: 5c12bb6 ("wifi: rtw89: refine packet offload flow") Signed-off-by: Chih-Kang Chang <[email protected]> Signed-off-by: Ping-Ke Shih <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 45d5a2b ] There are a couple uses of bash specific syntax in the script. Change them to the equivalent POSIX syntax. This doesn't change functionality and allows non-bash test scripts to make use of these helpers. Reported-by: Mike Looijmans <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 2dd0b5a ("selftests: ktap_helpers: Add a helper to finish the test") Fixes: 14571ab ("kselftest: Add new test for detecting unprobed Devicetree devices") Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: Muhammad Usama Anjum <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 5b1c8b1 ] There is one use of bash specific syntax in the script. Change it to the equivalent POSIX syntax. This doesn't change functionality and allows the test to be run on shells other than bash. Reported-by: Mike Looijmans <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 4a679c5 ("selftests: Add test to verify power supply properties") Signed-off-by: Nícolas F. R. A. Prado <[email protected]> Reviewed-by: Muhammad Usama Anjum <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 019baf6 ] First of all, in order to build with clang at all, one must first apply Valentin Obst's build fix for LLVM [1]. Once that is done, then when building with clang, via: make LLVM=1 -C tools/testing/selftests ...the following error occurs: clang: error: cannot specify -o when generating multiple output files This is because clang, unlike gcc, won't accept invocations of this form: clang file1.c header2.h While trying to fix this, I noticed that: a) selftests/lib.mk already avoids the problem, and b) The binderfs Makefile indavertently bypasses the selftests/lib.mk build system, and quitely uses Make's implicit build rules for .c files instead. The Makefile attempts to set up both a dependency and a source file, neither of which was needed, because lib.mk is able to automatically handle both. This line: binderfs_test: binderfs_test.c ...causes Make's implicit rules to run, which builds binderfs_test without ever looking at lib.mk. Fix this by simply deleting the "binderfs_test:" Makefile target and letting lib.mk handle it instead. [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/ Fixes: 6e29225 ("binderfs: port tests to test harness infrastructure") Cc: Christian Brauner <[email protected]> Signed-off-by: John Hubbard <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit d8171aa ] First of all, in order to build with clang at all, one must first apply Valentin Obst's build fix for LLVM [1]. Once that is done, then when building with clang, via: make LLVM=1 -C tools/testing/selftests ...the following error occurs: clang: error: cannot specify -o when generating multiple output files This is because clang, unlike gcc, won't accept invocations of this form: clang file1.c header2.h Fix this by using selftests/lib.mk facilities for tracking local header file dependencies: add them to LOCAL_HDRS, leaving only the .c files to be passed to the compiler. [1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/ Fixes: 8e289f4 ("selftests/resctrl: Add resctrl.h into build deps") Cc: Ilpo Järvinen <[email protected]> Signed-off-by: John Hubbard <[email protected]> Acked-by: Reinette Chatre <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit d4e6fbd ] Align the behavior for gcc and clang builds by interpreting unset `ARCH` and `CROSS_COMPILE` variables in `LLVM` builds as a sign that the user wants to build for the host architecture. This patch preserves the properties that setting the `ARCH` variable to an unknown value will trigger an error that complains about insufficient information, and that a set `CROSS_COMPILE` variable will override the target triple that is determined based on presence/absence of `ARCH`. When compiling with clang, i.e., `LLVM` is set, an unset `ARCH` variable in combination with an unset `CROSS_COMPILE` variable, i.e., compiling for the host architecture, leads to compilation failures since `lib.mk` can not determine the clang target triple. In this case, the following error message is displayed for each subsystem that does not set `ARCH` in its own Makefile before including `lib.mk` (lines wrapped at 75 chrs): make[1]: Entering directory '/mnt/build/linux/tools/testing/selftests/ sysctl' ../lib.mk:33: *** Specify CROSS_COMPILE or add '--target=' option to lib.mk. Stop. make[1]: Leaving directory '/mnt/build/linux/tools/testing/selftests/ sysctl' In the same scenario a gcc build would default to the host architecture, i.e., it would use plain `gcc`. Fixes: 795285e ("selftests: Fix clang cross compilation") Reviewed-by: Mark Brown <[email protected]> Signed-off-by: Valentin Obst <[email protected]> Reviewed-by: John Hubbard <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit f8aa1b9 ] There is a race condition when a kthread finishes after the deadline and before the call to kthread_stop(), which may lead to use after free. Cc: Brendan Higgins <[email protected]> Cc: Shuah Khan <[email protected]> Reviewed-by: Kees Cook <[email protected]> Fixes: adf5054 ("kunit: fix UAF when run kfence test case test_gfpzero") Reviewed-by: David Gow <[email protected]> Reviewed-by: Rae Moar <[email protected]> Signed-off-by: Mickaël Salaün <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit fabd480 ] kunit_init_device() should unregister the device on bus register error, but mistakenly it tries to unregister the bus. Unregister the device instead of the bus. Signed-off-by: Wander Lairson Costa <[email protected]> Fixes: d03c720 ("kunit: Add APIs for managing devices") Reviewed-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 8fe51b4 ] Commit ddb5cdb ("kbuild: generate KSYMTAB entries by modpost") forget drop the .export_symbol section from the final modules. Fixes: ddb5cdb ("kbuild: generate KSYMTAB entries by modpost") Signed-off-by: Wang Yao <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 8bd67eb ] syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=a63a1f6a062033cf0f40 Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…interval [ Upstream commit 06080ea ] When running the bridge IGMP/MLD selftests on debug kernels we can get spurious errors when setting up the IGMP/MLD exclude timeout tests because the membership interval is just 3 seconds and the setup has 2 seconds of sleep plus various validations, the one second that is left is not enough. Increase the membership interval from 3 to 5 seconds to make room for the setup validation and 2 seconds of sleep. Fixes: 34d7ecb ("selftests: net: bridge: update IGMP/MLD membership interval value") Reported-by: Jakub Kicinski <[email protected]> Signed-off-by: Nikolay Aleksandrov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 3a7c166 ] syzbot reported a suspicious rcu usage[1] in bridge's mst code. While fixing it I noticed that nothing prevents a vlan to be freed while walking the list from the same path (br forward delay timer). Fix the rcu usage and also make sure we are not accessing freed memory by making br_mst_vlan_set_state use rcu read lock. [1] WARNING: suspicious RCU usage 6.9.0-rc6-syzkaller #0 Not tainted ----------------------------- net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage! ... stack backtrace: CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: <IRQ> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nbp_vlan_group net/bridge/br_private.h:1599 [inline] br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105 br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47 br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88 call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793 expire_timers kernel/time/timer.c:1844 [inline] __run_timers kernel/time/timer.c:2418 [inline] __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429 run_timer_base kernel/time/timer.c:2438 [inline] run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448 __do_softirq+0x2c6/0x980 kernel/softirq.c:554 invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633 irq_exit_rcu+0x9/0x30 kernel/softirq.c:645 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758 Code: 2b 00 74 08 4c 89 f7 e8 ba d1 84 00 f6 44 24 61 02 0f 85 85 01 00 00 41 f7 c7 00 02 00 00 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 25 00 00 00 00 00 43 c7 44 25 09 00 00 00 00 43 c7 44 25 RSP: 0018:ffffc90013657100 EFLAGS: 00000206 RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0 R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28 R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246 Fixes: ec7328b ("net: bridge: mst: Multiple Spanning Tree (MST) mode") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=fa04eb8a56fd923fc5d8 Signed-off-by: Nikolay Aleksandrov <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 1de27bb ] Adjust `union bpf_attr` size passed to kernel in two feature-detecting functions to take into account prog_token_fd field. Libbpf is avoiding memset()'ing entire `union bpf_attr` by only using minimal set of bpf_attr's fields. Two places have been missed when wiring BPF token support in libbpf's feature detection logic. Fix them trivially. Fixes: f3dcee9 ("libbpf: Wire up token_fd into feature probing logic") Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit fd76e5c ] The qrtr protocol core logic and the qrtr nameservice are combined into a single module. Neither the core logic or nameservice provide much functionality by themselves; combining the two into a single module also prevents any possible issues that may stem from client modules loading inbetween qrtr and the ns. Creating a socket takes two references to the module that owns the socket protocol. Since the ns needs to create the control socket, this creates a scenario where there are always two references to the qrtr module. This prevents the execution of 'rmmod' for qrtr. To resolve this, forcefully put the module refcount for the socket opened by the nameservice. Fixes: a365023 ("net: qrtr: combine nameservice into main module") Reported-by: Jeffrey Hugo <[email protected]> Tested-by: Jeffrey Hugo <[email protected]> Signed-off-by: Chris Lew <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 83e9394 ] There is no need to add the name to ns_list again if the netns already recoreded. Fixes: 25ae948 ("selftests/net: add lib.sh") Signed-off-by: Hangbin Liu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 6770815 ] Disabling tcp-data-split on idpf silently fails: # ethtool -G $NETDEV tcp-data-split off # ethtool -g $NETDEV | grep 'TCP data split' TCP data split: on But it works if you also change 'tx' or 'rx': # ethtool -G $NETDEV tcp-data-split off tx 256 # ethtool -g $NETDEV | grep 'TCP data split' TCP data split: off The bug is in idpf_set_ringparam, where it takes a shortcut out if the TX and RX sizes are not changing. Fix it by checking also if the tcp-data-split setting remains unchanged. Only then can the soft reset be skipped. Fixes: 9b1aa3e ("idpf: add get/set for Ethtool's header split ringparam") Reported-by: Xu Du <[email protected]> Closes: https://issues.redhat.com/browse/RHEL-36182 Signed-off-by: Michal Schmidt <[email protected]> Reviewed-by: Alexander Lobakin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit e03e7f2 ] syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1] Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node) [1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted ------------------------------------------------------ syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f -> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK *** 1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697 stack backtrace: CPU: 0 PID: 5129 Comm: syz-executor350 Not tainted 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2187 check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 1da177e ("Linux-2.6.12-rc2") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 581073f ] trafgen performance considerably sank on hosts with many cores after the blamed commit. packet_read_pending() is very expensive, and calling it in af_packet fast path defeats Daniel intent in commit b013840 ("packet: use percpu mmap tx frame pending refcount") tpacket_destruct_skb() makes room for one packet, we can immediately wakeup a producer, no need to completely drain the tx ring. Fixes: 89ed5b5 ("af_packet: Block execution of tasks waiting for transmit to complete in AF_PACKET") Signed-off-by: Eric Dumazet <[email protected]> Cc: Neil Horman <[email protected]> Cc: Daniel Borkmann <[email protected]> Reviewed-by: Willem de Bruijn <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
…main_level [ Upstream commit a1fd0b9 ] Change relax_domain_level checks so that it would be possible to include or exclude all domains from newidle balancing. This matches the behavior described in the documentation: -1 no request. use system default or follow request of others. 0 no search. 1 search siblings (hyperthreads in a core). "2" enables levels 0 and 1, level_max excludes the last (level_max) level, and level_max+1 includes all levels. Fixes: 1d3504f ("sched, cpuset: customize sched domains, core") Signed-off-by: Vitalii Bursov <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Dietmar Eggemann <[email protected]> Reviewed-by: Vincent Guittot <[email protected]> Reviewed-by: Valentin Schneider <[email protected]> Link: https://lore.kernel.org/r/bd6de28e80073c79466ec6401cdeae78f0d4423d.1714488502.git.vitaly@bursov.com Signed-off-by: Sasha Levin <[email protected]>
…cpu_max_write() [ Upstream commit 49217ea ] In the cgroup v2 CPU subsystem, assuming we have a cgroup named 'test', and we set cpu.max and cpu.max.burst: # echo 1000000 > /sys/fs/cgroup/test/cpu.max # echo 1000000 > /sys/fs/cgroup/test/cpu.max.burst then we check cpu.max and cpu.max.burst: # cat /sys/fs/cgroup/test/cpu.max 1000000 100000 # cat /sys/fs/cgroup/test/cpu.max.burst 1000000 Next we set cpu.max again and check cpu.max and cpu.max.burst: # echo 2000000 > /sys/fs/cgroup/test/cpu.max # cat /sys/fs/cgroup/test/cpu.max 2000000 100000 # cat /sys/fs/cgroup/test/cpu.max.burst 1000 ... we find that the cpu.max.burst value changed unexpectedly. In cpu_max_write(), the unit of the burst value returned by tg_get_cfs_burst() is microseconds, while in cpu_max_write(), the burst unit used for calculation should be nanoseconds, which leads to the bug. To fix it, get the burst value directly from tg->cfs_bandwidth.burst. Fixes: f418371 ("sched/fair: Introduce the burstable CFS controller") Reported-by: Qixin Liao <[email protected]> Signed-off-by: Cheng Yu <[email protected]> Signed-off-by: Zhang Qiao <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Vincent Guittot <[email protected]> Tested-by: Vincent Guittot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 68067f0 ] Fix the issue where some Rx features cannot be changed. When using ethtool -K to turn off rx offload, it returns error and displays "Could not change any device features". And netdev->features is not assigned a new value to actually configure the hardware. Fixes: 6dbedcf ("net: libwx: Implement xx_set_features ops") Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit ac71ab7 ] Hardware requires VLAN CTAG and STAG configuration always matches. And whether VLAN CTAG or STAG changes, the configuration needs to be changed as well. Fixes: 6670f1e ("net: txgbe: Add netdev features support") Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Sai Krishna <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 1d3c641 ] When VLAN tag strip is changed to enable or disable, the hardware requires the Rx ring to be in a disabled state, otherwise the feature cannot be changed. Fixes: f3b03c6 ("net: wangxun: Implement vlan add and kill functions") Signed-off-by: Jiawen Wu <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 6e828dc ] Since commit a36e185 ("udp: Handle ICMP errors for tunnels with same destination port on both endpoints") UDP's handling of ICMP errors has allowed for UDP-encap tunnels to determine socket associations in scenarios where the UDP hash lookup could not. Subsequently, commit d26796a ("udp: check udp sock encap_type in __udp_lib_err") subtly tweaked the approach such that UDP ICMP error handling would be skipped for any UDP socket which has encapsulation enabled. In the case of L2TP tunnel sockets using UDP-encap, this latter modification effectively broke ICMP error reporting for the L2TP control plane. To a degree this isn't catastrophic inasmuch as the L2TP control protocol defines a reliable transport on top of the underlying packet switching network which will eventually detect errors and time out. However, paying attention to the ICMP error reporting allows for more timely detection of errors in L2TP userspace, and aids in debugging connectivity issues. Reinstate ICMP error handling for UDP encap L2TP tunnels: * implement struct udp_tunnel_sock_cfg .encap_err_rcv in order to allow the L2TP code to handle ICMP errors; * only implement error-handling for tunnels which have a managed socket: unmanaged tunnels using a kernel socket have no userspace to report errors back to; * flag the error on the socket, which allows for userspace to get an error such as -ECONNREFUSED back from sendmsg/recvmsg; * pass the error into ip[v6]_icmp_error() which allows for userspace to get extended error information via. MSG_ERRQUEUE. Fixes: d26796a ("udp: check udp sock encap_type in __udp_lib_err") Signed-off-by: Tom Parkin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit cee27ae ] This reverts commit daef47b. This framework change to add D_GNU_SOURCE to KHDR_INCLUDES to Makefile, lib.mk, and kselftest_harness.h is causing build failures and warnings. Revert this change. Reported-by: Mark Brown <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
[ Upstream commit 3da1640 ] This reverts commit 2c3b8f8. The framework change to add D_GNU_SOURCE to KHDR_INCLUDES to Makefile, lib.mk, and kselftest_harness.h is reverted as it is causing build failures and warnings. Revert this change as this change depends on the framework change. Reported-by: Mark Brown <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Link: https://lore.kernel.org/r/[email protected] Tested-by: Ronald Warsow <[email protected]> Tested-by: Pavel Machek (CIP) <[email protected]> Tested-by: Bagas Sanjaya <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: SeongJae Park <[email protected]> Tested-by: Mark Brown <[email protected]> Tested-by: Pascal Ernster <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Shuah Khan <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
This is the 6.9.3 stable release
Origin implementation of function highest_bit utilize the function of "fls()" to calculate the most significant bit of the input parameter "flags". Normally we can return the mask with "1 << (fls(flags) - 1)", but "fls(flags)" will return 0 if the value of "flags" is 0, which will cause the evaluation become "1 << (-1)" and it's illegal. So we use a branch to determine whether the return value of "fls(flags)" is 0. We can remove the use of branch first left shift "fls(flags)" number of bits and then right shift 1 bit. When the value of "fls(flags)" is 0 then this evaluation will simply become 0 without any error. As more values other than 0, evaluation is the same as it did for "1 << (fls(flags) - 1)". This implementation can prevent any possible branch prediction fault and pure shift operations are cheaper than branch operation for if-else statements. (cherry picked from commit baff66e)
Signed-off-by: I Hsin Cheng <[email protected]> (cherry picked from commit 91aa073)
We weren't synchronizing the boot CPU's online state with scx_rq's online state. This however was getting hidden through the RQ_ONOFF_TOPOLOGY update calls. 3a44769 ("scx: Replace scx_cpu_online percpu var with SCX_RQ_ONLINE flag") masked RQ_ONOFF_TOPOLOGY calls leaving the boot CPU marked offline from SCX's POV always forcing the CPU into local bypass mode, likely leading to reported interactivity problems on scx_rusty. Fix it by synchronizing SCX_RQ_ONLINE with CPU's online states in init_sched_ext_class(). (cherry picked from commit 10d167d)
Signed-off-by: David Vernet <[email protected]>
Byte-Lab
pushed a commit
that referenced
this pull request
Jun 21, 2024
[ Upstream commit 8987515 ] When request_irq() fails, error path calls vp_del_vqs(). There, as vq is present in the list, free_irq() is called for the same vector. That causes following splat: [ 0.414355] Trying to free already-free IRQ 27 [ 0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0 [ 0.414510] Modules linked in: [ 0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27 [ 0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014 [ 0.414540] RIP: 0010:free_irq+0x1a1/0x2d0 [ 0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 <0f> 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40 [ 0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086 [ 0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000 [ 0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001 [ 0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001 [ 0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760 [ 0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600 [ 0.414540] FS: 0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000 [ 0.414540] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0 [ 0.414540] Call Trace: [ 0.414540] <TASK> [ 0.414540] ? __warn+0x80/0x120 [ 0.414540] ? free_irq+0x1a1/0x2d0 [ 0.414540] ? report_bug+0x164/0x190 [ 0.414540] ? handle_bug+0x3b/0x70 [ 0.414540] ? exc_invalid_op+0x17/0x70 [ 0.414540] ? asm_exc_invalid_op+0x1a/0x20 [ 0.414540] ? free_irq+0x1a1/0x2d0 [ 0.414540] vp_del_vqs+0xc1/0x220 [ 0.414540] vp_find_vqs_msix+0x305/0x470 [ 0.414540] vp_find_vqs+0x3e/0x1a0 [ 0.414540] vp_modern_find_vqs+0x1b/0x70 [ 0.414540] init_vqs+0x387/0x600 [ 0.414540] virtnet_probe+0x50a/0xc80 [ 0.414540] virtio_dev_probe+0x1e0/0x2b0 [ 0.414540] really_probe+0xc0/0x2c0 [ 0.414540] ? __pfx___driver_attach+0x10/0x10 [ 0.414540] __driver_probe_device+0x73/0x120 [ 0.414540] driver_probe_device+0x1f/0xe0 [ 0.414540] __driver_attach+0x88/0x180 [ 0.414540] bus_for_each_dev+0x85/0xd0 [ 0.414540] bus_add_driver+0xec/0x1f0 [ 0.414540] driver_register+0x59/0x100 [ 0.414540] ? __pfx_virtio_net_driver_init+0x10/0x10 [ 0.414540] virtio_net_driver_init+0x90/0xb0 [ 0.414540] do_one_initcall+0x58/0x230 [ 0.414540] kernel_init_freeable+0x1a3/0x2d0 [ 0.414540] ? __pfx_kernel_init+0x10/0x10 [ 0.414540] kernel_init+0x1a/0x1c0 [ 0.414540] ret_from_fork+0x31/0x50 [ 0.414540] ? __pfx_kernel_init+0x10/0x10 [ 0.414540] ret_from_fork_asm+0x1a/0x30 [ 0.414540] </TASK> Fix this by calling deleting the current vq when request_irq() fails. Fixes: 0b0f9dc ("Revert "virtio_pci: use shared interrupts for virtqueues"") Signed-off-by: Jiri Pirko <[email protected]> Message-Id: <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.