commit 18d179e11910a53ef98791eabc410d5abcfa377e Author: Greg Kroah-Hartman Date: Mon Feb 5 20:17:12 2024 +0000 Linux 6.7.4 Link: https://lore.kernel.org/r/20240203035403.657508530@linuxfoundation.org Tested-by: Salvatore Bonaccorso Tested-by: Ronald Warsow Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20240203174813.681845076@linuxfoundation.org Tested-by: Luna Jernberg Tested-by: Ronald Warsow Tested-by: Ricardo B. Marliere Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Bagas Sanjaya Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit 11a4f471d868b7fe5a8d8bb1653270b6e4e85591 Author: Srinivasan Shanmugam Date: Tue Jan 30 12:10:38 2024 +0530 drm/amdgpu: Fix missing error code in 'gmc_v6/7/8/9_0_hw_init()' [ Upstream commit 16da399091dca3d1e48109086403587af37cc196 ] Return 0 for success scenairos in 'gmc_v6/7/8/9_0_hw_init()' Fixes the below: drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:920 gmc_v6_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1104 gmc_v7_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1224 gmc_v8_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2347 gmc_v9_0_hw_init() warn: missing error code? 'r' Fixes: fac4ebd79fed ("drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()'") Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f3570675bf09af2f35516b2ac84ac59a075b32b0 Author: Johan Hovold Date: Fri Jan 19 12:24:17 2024 +0100 ASoC: codecs: wsa883x: fix PA volume control commit b53cc6144a3f6c8b56afcdec89d81195c9b0dc69 upstream. The PA gain can be set in steps of 1.5 dB from -3 dB to 18 dB, that is, in 15 levels. Fix the dB values for the PA volume control as experiments using wsa8835 show that the first 16 levels all map to the same lowest gain while the last three map to the highest gain. These values specifically need to be correct for the sound server to provide proper volume control. Note that level 0 (-3 dB) does not mute the PA so the mute flag should also not be set. Fixes: cdb09e623143 ("ASoC: codecs: wsa883x: add control, dapm widgets and map") Cc: stable@vger.kernel.org # 6.0 Cc: Srinivas Kandagatla Signed-off-by: Johan Hovold Link: https://msgid.link/r/20240119112420.7446-2-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2f8e9b77ca2feab6d20938bc551dbb3d8a7a47e2 Author: Johan Hovold Date: Fri Jan 19 12:24:19 2024 +0100 ASoC: codecs: lpass-wsa-macro: fix compander volume hack commit 46188db080bd1df7d2d28031b89e56f2fdbabd67 upstream. The LPASS WSA macro codec driver is updating the digital gain settings behind the back of user space on DAPM events if companding has been enabled. As compander control is exported to user space, this can result in the digital gain setting being incremented (or decremented) every time the sound server is started and the codec suspended depending on what the UCM configuration looks like. Soon enough playback will become distorted (or too quiet). This is specifically a problem on the Lenovo ThinkPad X13s as this bypasses the limit for the digital gain setting that has been set by the machine driver. Fix this by simply dropping the compander gain offset hack. If someone cares about modelling the impact of the compander setting this can possibly be done by exporting it as a volume control later. Note that the volume registers still need to be written after enabling clocks in order for any prior updates to take effect. Fixes: 2c4066e5d428 ("ASoC: codecs: lpass-wsa-macro: add dapm widgets and route") Cc: stable@vger.kernel.org # 5.11 Cc: Srinivas Kandagatla Signed-off-by: Johan Hovold Link: https://msgid.link/r/20240119112420.7446-4-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5b465d6384e4eb79a0e049c7646fb0284af0501f Author: Johan Hovold Date: Mon Jan 22 10:11:30 2024 +0100 ASoC: codecs: wcd938x: fix headphones volume controls commit 4d0e8bdfa4a57099dc7230952a460903f2e2f8de upstream. The lowest headphones volume setting does not mute so the leave the TLV mute flag unset. This is specifically needed to let the sound server use the lowest gain setting. Fixes: c03226ba15fe ("ASoC: codecs: wcd938x: fix dB range for HPHL and HPHR") Cc: # 6.5 Cc: Srinivas Kandagatla Signed-off-by: Johan Hovold Link: https://msgid.link/r/20240122091130.27463-1-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 1673211a38012e731373177b3a820a257b7964d2 Author: Johan Hovold Date: Mon Jan 22 19:18:17 2024 +0100 ASoC: qcom: sc8280xp: limit speaker volumes commit c481016bb4f8a9c059c39ac06e7b65e233a61f6a upstream. The UCM configuration for the Lenovo ThinkPad X13s has up until now been setting the speaker PA volume to the minimum -3 dB when enabling the speakers, but this does not prevent the user from increasing the volume further. Limit the digital gain and PA volumes to a combined -3 dB in the machine driver to reduce the risk of speaker damage until we have active speaker protection in place (or higher safe levels have been established). Note that the PA volume limit cannot be set lower than 0 dB or PulseAudio gets confused when the first 16 levels all map to -3 dB. Also note that this will probably need to be generalised using machine-specific limits, but a common limit should do for now. Cc: # 6.5 Signed-off-by: Johan Hovold Link: https://msgid.link/r/20240122181819.4038-3-johan+linaro@kernel.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit b8a8c5760d76aa73bfaa9b619bfdaffbc4038463 Author: Zhengchao Shao Date: Thu Nov 23 09:55:15 2023 +0800 bonding: remove print in bond_verify_device_path commit 486058f42a4728053ae69ebbf78e9731d8ce6f8b upstream. As suggested by Paolo in link[1], if the memory allocation fails, the mm layer will emit a lot warning comprising the backtrace, so remove the print. [1] https://lore.kernel.org/all/20231118081653.1481260-1-shaozhengchao@huawei.com/ Suggested-by: Paolo Abeni Signed-off-by: Zhengchao Shao Reviewed-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3cef284626425533491a2283820a0c41c68aec40 Author: Yonghong Song Date: Thu Dec 14 12:38:20 2023 -0800 selftests/bpf: Remove flaky test_btf_id test commit 56925f389e152dcb8d093435d43b78a310539c23 upstream. With previous patch, one of subtests in test_btf_id becomes flaky and may fail. The following is a failing example: Error: #26 btf Error: #26/174 btf/BTF ID Error: #26/174 btf/BTF ID btf_raw_create:PASS:check 0 nsec btf_raw_create:PASS:check 0 nsec test_btf_id:PASS:check 0 nsec ... test_btf_id:PASS:check 0 nsec test_btf_id:FAIL:check BTF lingersdo_test_get_info:FAIL:check failed: -1 The test tries to prove a btf_id not available after the map is closed. But btf_id is freed only after workqueue and a rcu grace period, compared to previous case just after a rcu grade period. Depending on system workload, workqueue could take quite some time to execute function bpf_map_free_deferred() which may cause the test failure. Instead of adding arbitrary delays, let us remove the logic to check btf_id availability after map is closed. Signed-off-by: Yonghong Song Link: https://lore.kernel.org/r/20231214203820.1469402-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Samasth Norway Ananda Signed-off-by: Greg Kroah-Hartman commit f65ab9e94bff28d3401ceda3cae62cad6d22336d Author: Konrad Dybcio Date: Tue Jun 20 13:43:21 2023 +0200 drm/msm/dsi: Enable runtime PM commit 6ab502bc1cf3147ea1d8540d04b83a7a4cb6d1f1 upstream. Some devices power the DSI PHY/PLL through a power rail that we model as a GENPD. Enable runtime PM to make it suspendable. Signed-off-by: Konrad Dybcio Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/543352/ Link: https://lore.kernel.org/r/20230620-topic-dsiphy_rpm-v2-2-a11a751f34f0@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Amit Pundir Signed-off-by: Greg Kroah-Hartman commit f9fd5a630b5b0df672367c84117e9a2e821be4aa Author: Jonathan Gray Date: Fri Feb 2 13:05:05 2024 +1100 Revert "drm/amd/display: Disable PSR-SU on Parade 0803 TCON again" This reverts commit f015d8b6405d950f30826b4d8d9e1084dd9ea2a4. duplicated a change made in 6.7 e7ab758741672acb21c5d841a9f0309d30e48a06 Cc: stable@vger.kernel.org # 6.7 Signed-off-by: Jonathan Gray Signed-off-by: Greg Kroah-Hartman commit 5a33420599fa0288792537e6872fd19cc8607ea6 Author: Marco Elver Date: Thu Jan 18 11:59:14 2024 +0100 mm, kmsan: fix infinite recursion due to RCU critical section commit f6564fce256a3944aa1bc76cb3c40e792d97c1eb upstream. Alexander Potapenko writes in [1]: "For every memory access in the code instrumented by KMSAN we call kmsan_get_metadata() to obtain the metadata for the memory being accessed. For virtual memory the metadata pointers are stored in the corresponding `struct page`, therefore we need to call virt_to_page() to get them. According to the comment in arch/x86/include/asm/page.h, virt_to_page(kaddr) returns a valid pointer iff virt_addr_valid(kaddr) is true, so KMSAN needs to call virt_addr_valid() as well. To avoid recursion, kmsan_get_metadata() must not call instrumented code, therefore ./arch/x86/include/asm/kmsan.h forks parts of arch/x86/mm/physaddr.c to check whether a virtual address is valid or not. But the introduction of rcu_read_lock() to pfn_valid() added instrumented RCU API calls to virt_to_page_or_null(), which is called by kmsan_get_metadata(), so there is an infinite recursion now. I do not think it is correct to stop that recursion by doing kmsan_enter_runtime()/kmsan_exit_runtime() in kmsan_get_metadata(): that would prevent instrumented functions called from within the runtime from tracking the shadow values, which might introduce false positives." Fix the issue by switching pfn_valid() to the _sched() variant of rcu_read_lock/unlock(), which does not require calling into RCU. Given the critical section in pfn_valid() is very small, this is a reasonable trade-off (with preemptible RCU). KMSAN further needs to be careful to suppress calls into the scheduler, which would be another source of recursion. This can be done by wrapping the call to pfn_valid() into preempt_disable/enable_no_resched(). The downside is that this sacrifices breaking scheduling guarantees; however, a kernel compiled with KMSAN has already given up any performance guarantees due to being heavily instrumented. Note, KMSAN code already disables tracing via Makefile, and since mmzone.h is included, it is not necessary to use the notrace variant, which is generally preferred in all other cases. Link: https://lkml.kernel.org/r/20240115184430.2710652-1-glider@google.com [1] Link: https://lkml.kernel.org/r/20240118110022.2538350-1-elver@google.com Fixes: 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memory_section->usage") Signed-off-by: Marco Elver Reported-by: Alexander Potapenko Reported-by: syzbot+93a9e8a3dea8d6085e12@syzkaller.appspotmail.com Reviewed-by: Alexander Potapenko Tested-by: Alexander Potapenko Cc: Charan Teja Kalla Cc: Borislav Petkov (AMD) Cc: Dave Hansen Cc: Dmitry Vyukov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b625f148f540356e04264f4c4d90120d4ec6a928 Author: Huang Shijie Date: Wed Dec 13 09:20:46 2023 +0800 arm64: irq: set the correct node for shadow call stack commit 7b1a09e44dc64f4f5930659b6d14a27183c00705 upstream. The init_irq_stacks() has been changed to use the correct node: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf The init_irq_scs() has the same issue with init_irq_stacks(): cpu_to_node() is not initialized yet, it does not work. This patch uses early_cpu_to_node() to set the init_irq_scs() with the correct node. Signed-off-by: Huang Shijie Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20231213012046.12014-1-shijie@os.amperecomputing.com Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit 3ca3901a88c08279c118f7c13dc4390ce61f96dc Author: Pavan Kumar Linga Date: Wed Jan 31 14:22:40 2024 -0800 idpf: avoid compiler padding in virtchnl2_ptype struct [ Upstream commit f0588b157f48b9c6277a75c9f14650e86d969e03 ] In the arm random config file, kconfig option 'CONFIG_AEABI' is disabled which results in adding the compiler flag '-mabi=apcs-gnu'. This causes the compiler to add padding in virtchnl2_ptype structure to align it to 8 bytes, resulting in the following size check failure: include/linux/build_bug.h:78:41: error: static assertion failed: "(6) == sizeof(struct virtchnl2_ptype)" 78 | #define __static_assert(expr, msg, ...) _Static_assert(expr, msg) | ^~~~~~~~~~~~~~ include/linux/build_bug.h:77:34: note: in expansion of macro '__static_assert' 77 | #define static_assert(expr, ...) __static_assert(expr, ##__VA_ARGS__, #expr) | ^~~~~~~~~~~~~~~ drivers/net/ethernet/intel/idpf/virtchnl2.h:26:9: note: in expansion of macro 'static_assert' 26 | static_assert((n) == sizeof(struct X)) | ^~~~~~~~~~~~~ drivers/net/ethernet/intel/idpf/virtchnl2.h:982:1: note: in expansion of macro 'VIRTCHNL2_CHECK_STRUCT_LEN' 982 | VIRTCHNL2_CHECK_STRUCT_LEN(6, virtchnl2_ptype); | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Avoid the compiler padding by using "__packed" structure attribute for the virtchnl2_ptype struct. Also align the structure by using "__aligned(2)" for better code optimization. Fixes: 0d7502a9b4a7 ("virtchnl: add virtchnl version 2 ops") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312220250.ufEm8doQ-lkp@intel.com Reviewed-by: Przemek Kitszel Reviewed-by: Paul Menzel Reviewed-by: Simon Horman Signed-off-by: Pavan Kumar Linga Tested-by: Krishneil Singh Signed-off-by: Tony Nguyen Link: https://lore.kernel.org/r/20240131222241.2087516-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2304c22d43691ec72064d018d10e676511fc0039 Author: Paolo Abeni Date: Wed Jan 31 18:52:29 2024 +0100 selftests: net: enable some more knobs [ Upstream commit c15a729c9d45aa142fb01a3afee822ab1f0e62a8 ] The rtnetlink tests require additional options currently off by default. Fixes: 2766a11161cc ("selftests: rtnetlink: add ipsec offload API test") Fixes: 5e596ee171ba ("selftests: add xfrm state-policy-monitor to rtnetlink.sh") Signed-off-by: Paolo Abeni Link: https://lore.kernel.org/r/9048ca58e49b962f35dba1dfb2beaf3dab3e0411.1706723341.git.pabeni@redhat.com/ Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 976e0fa443684023ab2de0aba2a5b8620bf38abe Author: Jakub Kicinski Date: Wed Jan 31 08:56:05 2024 -0800 selftests: net: add missing config for NF_TARGET_TTL [ Upstream commit 1939f738c73dfdb8389839bdc9624c765e3326e6 ] amt test uses the TTL iptables module: ip netns exec "${RELAY}" iptables -t mangle -I PREROUTING \ -d 239.0.0.1 -j TTL --ttl-set 2 Fixes: c08e8baea78e ("selftests: add amt interface selftest script") Link: https://lore.kernel.org/r/20240131165605.4051645-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5fdba5acd3e171ff23ea8a8c10ae4adf07621178 Author: Benjamin Poirier Date: Wed Jan 31 09:08:45 2024 -0500 selftests: bonding: Check initial state [ Upstream commit 8cc063ae1b3dbe416ce62a15d49af4c2314b45fe ] The purpose of the test_LAG_cleanup() function is to check that some hardware addresses are removed from underlying devices after they have been unenslaved. The test function simply checks that those addresses are not present at the end. However, if the addresses were never added to begin with due to some error in device setup, the test function currently passes. This is a false positive since in that situation the test did not actually exercise the intended functionality. Add a check that the expected addresses are indeed present after device setup. This makes the test function more robust. I noticed this problem when running the team/dev_addr_lists.sh test on a system without support for dummy and ipv6: tools/testing/selftests/drivers/net/team# ./dev_addr_lists.sh Error: Unknown device type. Error: Unknown device type. This program is not intended to be run as root. RTNETLINK answers: Operation not supported TEST: team cleanup mode lacp [ OK ] Fixes: bbb774d921e2 ("net: Add tests for bonding and team address list management") Signed-off-by: Benjamin Poirier Link: https://lore.kernel.org/r/20240131140848.360618-3-bpoirier@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8c8f6cf6be8aec55fd0b195aac505b0f76e5c271 Author: Benjamin Poirier Date: Wed Jan 31 09:08:44 2024 -0500 selftests: team: Add missing config options [ Upstream commit 7b6fb3050d8f5e2b6858eef344e47ac1f5442827 ] Similar to commit dd2d40acdbb2 ("selftests: bonding: Add more missing config options"), add more networking-specific config options which are needed for team device tests. For testing, I used the minimal config generated by virtme-ng and I added the options in the config file. Afterwards, the team device test passed. Fixes: bbb774d921e2 ("net: Add tests for bonding and team address list management") Reviewed-by: Petr Machata Signed-off-by: Benjamin Poirier Link: https://lore.kernel.org/r/20240131140848.360618-2-bpoirier@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 648be8308114be1a276211f4eb0a37ebff5dd261 Author: Breno Leitao Date: Wed Jan 31 02:21:49 2024 -0800 net: sysfs: Fix /sys/class/net/ path [ Upstream commit ae3f4b44641dfff969604735a0dcbf931f383285 ] The documentation is pointing to the wrong path for the interface. Documentation is pointing to /sys/class/, instead of /sys/class/net/. Fix it by adding the `net/` directory before the interface. Fixes: 1a02ef76acfa ("net: sysfs: add documentation entries for /sys/class//queues") Signed-off-by: Breno Leitao Link: https://lore.kernel.org/r/20240131102150.728960-2-leitao@debian.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 79d52172cfb1a5598da6dfbd4adf1ca91609b2eb Author: Geetha sowjanya Date: Tue Jan 30 17:36:10 2024 +0530 octeontx2-pf: Remove xdp queues on program detach [ Upstream commit 04f647c8e456fcfabe9c252a4dcaee03b586fa4f ] XDP queues are created/destroyed when a XDP program is attached/detached. In current driver xdp_queues are not getting destroyed on program exit due to incorrect xdp_queue and tot_tx_queue count values. This patch fixes the issue by setting tot_tx_queue and xdp_queue count to correct values. It also fixes xdp.data_hard_start address. Fixes: 06059a1a9a4a ("octeontx2-pf: Add XDP support to netdev PF") Signed-off-by: Geetha sowjanya Link: https://lore.kernel.org/r/20240130120610.16673-1-gakula@marvell.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit a3cc7f4a17792d68a293da10d62b2dfd4d6c4142 Author: Paolo Abeni Date: Tue Jan 30 18:47:18 2024 +0100 selftests: net: don't access /dev/stdout in pmtu.sh [ Upstream commit bc0970d5ac1d1317e212bdf55533935ecb6ae95c ] When running the pmtu.sh via the kselftest infra, accessing /dev/stdout gives unexpected results: # dd: failed to open '/dev/stdout': Device or resource busy # TEST: IPv4, bridged vxlan4: PMTU exceptions [FAIL] Let dd use directly the standard output to fix the above: # TEST: IPv4, bridged vxlan4: PMTU exceptions - nexthop objects [ OK ] Fixes: 136a1b434bbb ("selftests: net: test vxlan pmtu exceptions with tcp") Signed-off-by: Paolo Abeni Reviewed-by: Guillaume Nault Reviewed-by: David Ahern Link: https://lore.kernel.org/r/23d7592c5d77d75cff9b34f15c227f92e911c2ae.1706635101.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c75c2f9e14861e299229d5c8db4d4e6b3b151275 Author: Paolo Abeni Date: Tue Jan 30 18:47:17 2024 +0100 selftests: net: fix available tunnels detection [ Upstream commit e4e4b6d568d2549583cbda3f8ce567e586cb05da ] The pmtu.sh test tries to detect the tunnel protocols available in the running kernel and properly skip the unsupported cases. In a few more complex setup, such detection is unsuccessful, as the script currently ignores some intermediate error code at setup time. Before: # which: no nettest in (/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin) # TEST: vti6: PMTU exceptions (ESP-in-UDP) [FAIL] # PMTU exception wasn't created after creating tunnel exceeding link layer MTU # ./pmtu.sh: line 931: kill: (7543) - No such process # ./pmtu.sh: line 931: kill: (7544) - No such process After: # xfrm4 not supported # TEST: vti4: PMTU exceptions [SKIP] Fixes: ece1278a9b81 ("selftests: net: add ESP-in-UDP PMTU test") Signed-off-by: Paolo Abeni Reviewed-by: Guillaume Nault Reviewed-by: David Ahern Link: https://lore.kernel.org/r/cab10e75fda618e6fff8c595b632f47db58b9309.1706635101.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b8a599535293d9b4cc9113b37cde5d4428f24204 Author: Paolo Abeni Date: Tue Jan 30 18:47:16 2024 +0100 selftests: net: add missing config for pmtu.sh tests [ Upstream commit f7c25d8e17dd759d97ca093faf92eeb7da7b3890 ] The mentioned test uses a few Kconfig still missing the net config, add them. Before: # Error: Specified qdisc kind is unknown. # Error: Specified qdisc kind is unknown. # Error: Qdisc not classful. # We have an error talking to the kernel # Error: Qdisc not classful. # We have an error talking to the kernel # policy_routing not supported # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions [SKIP] After: # TEST: ICMPv4 with DSCP and ECN: PMTU exceptions [ OK ] Fixes: ec730c3e1f0e ("selftest: net: Test IPv4 PMTU exceptions with DSCP and ECN") Signed-off-by: Paolo Abeni Reviewed-by: Guillaume Nault Reviewed-by: David Ahern Link: https://lore.kernel.org/r/8d27bf6762a5c7b3acc457d6e6872c533040f9c1.1706635101.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 40d7bec12697e8839dffece1047edcab175ec970 Author: Jakub Kicinski Date: Fri Jan 26 12:13:08 2024 -0800 selftests: net: add missing config for nftables-backed iptables [ Upstream commit 59c93583491ab15db109f9902524d241c4fa4c0b ] Modern OSes use iptables implementation with nf_tables as a backend, e.g.: $ iptables -V iptables v1.8.8 (nf_tables) Pablo points out that we need CONFIG_NFT_COMPAT to make that work, otherwise we see a lot of: Warning: Extension DNAT revision 0 not supported, missing kernel module? with DNAT being just an example here, other modules we need include udp, TTL, length etc. Link: https://lore.kernel.org/r/20240126201308.2903602-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Stable-dep-of: f7c25d8e17dd ("selftests: net: add missing config for pmtu.sh tests") Signed-off-by: Sasha Levin commit 3ffe14c36985e3174933127c9efad82ac8f3fefb Author: Brett Creeley Date: Mon Jan 29 15:40:35 2024 -0800 pds_core: Rework teardown/setup flow to be more common [ Upstream commit bc90fbe0c3182157d2be100a2f6c2edbb1820677 ] Currently the teardown/setup flow for driver probe/remove is quite a bit different from the reset flows in pdsc_fw_down()/pdsc_fw_up(). One key piece that's missing are the calls to pci_alloc_irq_vectors() and pci_free_irq_vectors(). The pcie reset case is calling pci_free_irq_vectors() on reset_prepare, but not calling the corresponding pci_alloc_irq_vectors() on reset_done. This is causing unexpected/unwanted interrupt behavior due to the adminq interrupt being accidentally put into legacy interrupt mode. Also, the pci_alloc_irq_vectors()/pci_free_irq_vectors() functions are being called directly in probe/remove respectively. Fix this inconsistency by making the following changes: 1. Always call pdsc_dev_init() in pdsc_setup(), which calls pci_alloc_irq_vectors() and get rid of the now unused pds_dev_reinit(). 2. Always free/clear the pdsc->intr_info in pdsc_teardown() since this structure will get re-alloced in pdsc_setup(). 3. Move the calls of pci_free_irq_vectors() to pdsc_teardown() since pci_alloc_irq_vectors() will always be called in pdsc_setup()->pdsc_dev_init() for both the probe/remove and reset flows. 4. Make sure to only create the debugfs "identity" entry when it doesn't already exist, which it will in the reset case because it's already been created in the initial call to pdsc_dev_init(). Fixes: ffa55858330f ("pds_core: implement pci reset handlers") Signed-off-by: Brett Creeley Reviewed-by: Shannon Nelson Link: https://lore.kernel.org/r/20240129234035.69802-7-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 692488941283d72362274620b9abd28109fc459f Author: Brett Creeley Date: Mon Jan 29 15:40:34 2024 -0800 pds_core: Clear BARs on reset [ Upstream commit e96094c1d11cce4deb5da3c0500d49041ab845b8 ] During reset the BARs might be accessed when they are unmapped. This can cause unexpected issues, so fix it by clearing the cached BAR values so they are not accessed until they are re-mapped. Also, make sure any places that can access the BARs when they are NULL are prevented. Fixes: 49ce92fbee0b ("pds_core: add FW update feature to devlink") Signed-off-by: Brett Creeley Reviewed-by: Shannon Nelson Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/20240129234035.69802-6-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5939feb63ea1f011027576c64b68b681cbad31ca Author: Brett Creeley Date: Mon Jan 29 15:40:33 2024 -0800 pds_core: Prevent race issues involving the adminq [ Upstream commit 7e82a8745b951b1e794cc780d46f3fbee5e93447 ] There are multiple paths that can result in using the pdsc's adminq. [1] pdsc_adminq_isr and the resulting work from queue_work(), i.e. pdsc_work_thread()->pdsc_process_adminq() [2] pdsc_adminq_post() When the device goes through reset via PCIe reset and/or a fw_down/fw_up cycle due to bad PCIe state or bad device state the adminq is destroyed and recreated. A NULL pointer dereference can happen if [1] or [2] happens after the adminq is already destroyed. In order to fix this, add some further state checks and implement reference counting for adminq uses. Reference counting was used because multiple threads can attempt to access the adminq at the same time via [1] or [2]. Additionally, multiple clients (i.e. pds-vfio-pci) can be using [2] at the same time. The adminq_refcnt is initialized to 1 when the adminq has been allocated and is ready to use. Users/clients of the adminq (i.e. [1] and [2]) will increment the refcnt when they are using the adminq. When the driver goes into a fw_down cycle it will set the PDSC_S_FW_DEAD bit and then wait for the adminq_refcnt to hit 1. Setting the PDSC_S_FW_DEAD before waiting will prevent any further adminq_refcnt increments. Waiting for the adminq_refcnt to hit 1 allows for any current users of the adminq to finish before the driver frees the adminq. Once the adminq_refcnt hits 1 the driver clears the refcnt to signify that the adminq is deleted and cannot be used. On the fw_up cycle the driver will once again initialize the adminq_refcnt to 1 allowing the adminq to be used again. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Signed-off-by: Brett Creeley Reviewed-by: Shannon Nelson Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/20240129234035.69802-5-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c1f105c92919741ada726f3efd1d31fa0499bf44 Author: Brett Creeley Date: Mon Jan 29 15:40:32 2024 -0800 pds_core: Use struct pdsc for the pdsc_adminq_isr private data [ Upstream commit 951705151e50f9022bc96ec8b3fd5697380b1df6 ] The initial design for the adminq interrupt was done based on client drivers having their own adminq and adminq interrupt. So, each client driver's adminq isr would use their specific adminqcq for the private data struct. For the time being the design has changed to only use a single adminq for all clients. So, instead use the struct pdsc for the private data to simplify things a bit. This also has the benefit of not dereferencing the adminqcq to access the pdsc struct when the PDSC_S_STOPPING_DRIVER bit is set and the adminqcq has actually been cleared/freed. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Signed-off-by: Brett Creeley Reviewed-by: Shannon Nelson Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/20240129234035.69802-4-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 26621164707b90dfcd122bb82b063b8ecd7280f9 Author: Brett Creeley Date: Mon Jan 29 15:40:31 2024 -0800 pds_core: Cancel AQ work on teardown [ Upstream commit d321067e2cfa4d5e45401a00912ca9da8d1af631 ] There is a small window where pdsc_work_thread() calls pdsc_process_adminq() and pdsc_process_adminq() passes the PDSC_S_STOPPING_DRIVER check and starts to process adminq/notifyq work and then the driver starts a fw_down cycle. This could cause some undefined behavior if the notifyqcq/adminqcq are free'd while pdsc_process_adminq() is running. Use cancel_work_sync() on the adminqcq's work struct to make sure any pending work items are cancelled and any in progress work items are completed. Also, make sure to not call cancel_work_sync() if the work item has not be initialized. Without this, traces will happen in cases where a reset fails and teardown is called again or if reset fails and the driver is removed. Fixes: 01ba61b55b20 ("pds_core: Add adminq processing and commands") Signed-off-by: Brett Creeley Reviewed-by: Shannon Nelson Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/20240129234035.69802-3-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46826a3844068c0d3919eb4a24c3ba7bf5d24449 Author: Brett Creeley Date: Mon Jan 29 15:40:30 2024 -0800 pds_core: Prevent health thread from running during reset/remove [ Upstream commit d9407ff11809c6812bb84fe7be9c1367d758e5c8 ] The PCIe reset handlers can run at the same time as the health thread. This can cause the health thread to stomp on the PCIe reset. Fix this by preventing the health thread from running while a PCIe reset is happening. As part of this use timer_shutdown_sync() during reset and remove to make sure the timer doesn't ever get rearmed. Fixes: ffa55858330f ("pds_core: implement pci reset handlers") Signed-off-by: Brett Creeley Reviewed-by: Shannon Nelson Reviewed-by: Przemek Kitszel Link: https://lore.kernel.org/r/20240129234035.69802-2-brett.creeley@amd.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c2d272a9a1e8f22ba584589219f6fe1886a3595f Author: Eric Dumazet Date: Tue Jan 30 18:42:35 2024 +0000 af_unix: fix lockdep positive in sk_diag_dump_icons() [ Upstream commit 4d322dce82a1d44f8c83f0f54f95dd1b8dcf46c9 ] syzbot reported a lockdep splat [1]. Blamed commit hinted about the possible lockdep violation, and code used unix_state_lock_nested() in an attempt to silence lockdep. It is not sufficient, because unix_state_lock_nested() is already used from unix_state_double_lock(). We need to use a separate subclass. This patch adds a distinct enumeration to make things more explicit. Also use swap() in unix_state_double_lock() as a clean up. v2: add a missing inline keyword to unix_state_lock_nested() [1] WARNING: possible circular locking dependency detected 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Not tainted syz-executor.1/2542 is trying to acquire lock: ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, at: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 but task is already holding lock: ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&u->lock/1){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [inline] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c:196 [inline] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:338 [inline] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724 __do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&u->lock/1); lock(rlock-AF_UNIX); lock(&u->lock/1); lock(rlock-AF_UNIX); *** DEADLOCK *** 1 lock held by syz-executor.1/2542: #0: ffff88808b5dfe70 (&u->lock/1){+.+.}-{2:2}, at: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 stack backtrace: CPU: 1 PID: 2542 Comm: syz-executor.1 Not tainted 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 check_noncircular+0x366/0x490 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+0x1909/0x5ab0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_sendmsg+0x15d9/0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724 __do_sys_sendmmsg net/socket.c:2753 [inline] __se_sys_sendmmsg net/socket.c:2750 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7f26d887cda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f26d95a60c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f26d89abf80 RCX: 00007f26d887cda9 RDX: 000000000000003e RSI: 00000000200bd000 RDI: 0000000000000004 RBP: 00007f26d88c947a R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000008c0 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f26d89abf80 R15: 00007ffcfe081a68 Fixes: 2aac7a2cb0d9 ("unix_diag: Pending connections IDs NLA") Reported-by: syzbot Signed-off-by: Eric Dumazet Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240130184235.1620738-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 205659dbb880b23a680e87dd1c814b97fc72be3d Author: Zhipeng Lu Date: Mon Jan 29 17:10:17 2024 +0800 net: ipv4: fix a memleak in ip_setup_cork [ Upstream commit 5dee6d6923458e26966717f2a3eae7d09fc10bf6 ] When inetdev_valid_mtu fails, cork->opt should be freed if it is allocated in ip_setup_cork. Otherwise there could be a memleak. Fixes: 501a90c94510 ("inet: protect against too small mtu values.") Signed-off-by: Zhipeng Lu Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20240129091017.2938835-1-alexious@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 38cc1605338d99205a263707f4dde76408d3e0e8 Author: Pablo Neira Ayuso Date: Mon Jan 29 13:12:33 2024 +0100 netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations [ Upstream commit 8059918a1377f2f1fff06af4f5a4ed3d5acd6bc4 ] - Disallow families other than NFPROTO_{IPV4,IPV6,INET}. - Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object. Fixes: 857b46027d6f ("netfilter: nft_ct: add ct expectations support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 1c856889fe5fa106f16385646360704a2b25415a Author: Pablo Neira Ayuso Date: Mon Jan 29 11:09:43 2024 +0100 netfilter: nf_log: replace BUG_ON by WARN_ON_ONCE when putting logger [ Upstream commit 259eb32971e9eb24d1777a28d82730659f50fdcb ] Module reference is bumped for each user, this should not ever happen. But BUG_ON check should use rcu_access_pointer() instead. If this ever happens, do WARN_ON_ONCE() instead of BUG_ON() and consolidate pointer check under the rcu read side lock section. Fixes: fab4085f4e24 ("netfilter: log: nf_log_packet() as real unified interface") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 83505390aa28482a0deebb5866596a133101279b Author: Pablo Neira Ayuso Date: Tue Jan 23 23:45:32 2024 +0100 netfilter: nf_tables: restrict tunnel object to NFPROTO_NETDEV [ Upstream commit 776d451648443f9884be4a1b4e38e8faf1c621f9 ] Bail out on using the tunnel dst template from other than netdev family. Add the infrastructure to check for the family in objects. Fixes: af308b94a2a4 ("netfilter: nf_tables: add tunnel support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 03dc4dbcca5d408ebe978cb26ca7cfeb9314bd30 Author: Ryan Schaefer Date: Sun Jan 21 21:51:44 2024 +0000 netfilter: conntrack: correct window scaling with retransmitted SYN [ Upstream commit fb366fc7541a1de521ab3df58471746aa793b833 ] commit c7aab4f17021 ("netfilter: nf_conntrack_tcp: re-init for syn packets only") introduces a bug where SYNs in ORIGINAL direction on reused 5-tuple result in incorrect window scale negotiation. This commit merged the SYN re-initialization and simultaneous open or SYN retransmits cases. Merging this block added the logic in tcp_init_sender() that performed window scale negotiation to the retransmitted syn case. Previously. this would only result in updating the sender's scale and flags. After the merge the additional logic results in improperly clearing the scale in ORIGINAL direction before any packets in the REPLY direction are received. This results in packets incorrectly being marked invalid for being out-of-window. This can be reproduced with the following trace: Packet Sequence: > Flags [S], seq 1687765604, win 62727, options [.. wscale 7], length 0 > Flags [S], seq 1944817196, win 62727, options [.. wscale 7], length 0 In order to fix the issue, only evaluate window negotiation for packets in the REPLY direction. This was tested with simultaneous open, fast open, and the above reproduction. Fixes: c7aab4f17021 ("netfilter: nf_conntrack_tcp: re-init for syn packets only") Signed-off-by: Ryan Schaefer Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 90747b75e6c903784697bdef86f99da0bf0229b0 Author: Matthias May Date: Tue Jan 30 10:12:18 2024 +0000 selftests: net: add missing config for GENEVE [ Upstream commit c9ec85153fea6873c52ed4f5055c87263f1b54f9 ] l2_tos_ttl_inherit.sh verifies the inheritance of tos and ttl for GRETAP, VXLAN and GENEVE. Before testing it checks if the required module is available and if not skips the tests accordingly. Currently only GRETAP and VXLAN are tested because the GENEVE module is missing. Fixes: b690842d12fd ("selftests/net: test l2 tunnel TOS/TTL inheriting") Signed-off-by: Matthias May Link: https://lore.kernel.org/r/20240130101157.196006-1-matthias.may@westermo.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 086160d08a1a369d83fb82f3eed6f0a49fcff056 Author: Parav Pandit Date: Mon Jan 29 21:10:59 2024 +0200 devlink: Fix referring to hw_addr attribute during state validation [ Upstream commit 1a89e24f8bfd3e3562d69709c9d9cd185ded869b ] When port function state change is requested, and when the driver does not support it, it refers to the hw address attribute instead of state attribute. Seems like a copy paste error. Fix it by referring to the port function state attribute. Fixes: c0bea69d1ca7 ("devlink: Validate port function request") Signed-off-by: Parav Pandit Reviewed-by: Jiri Pirko Link: https://lore.kernel.org/r/20240129191059.129030-1-parav@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef95493d6814bd72fcbb8d39c201bbbcdaaa4770 Author: Linus Lüssing Date: Sat Jan 27 18:50:32 2024 +0100 bridge: mcast: fix disabled snooping after long uptime [ Upstream commit f5c3eb4b7251baba5cd72c9e93920e710ac8194a ] The original idea of the delay_time check was to not apply multicast snooping too early when an MLD querier appears. And to instead wait at least for MLD reports to arrive before switching from flooding to group based, MLD snooped forwarding, to avoid temporary packet loss. However in a batman-adv mesh network it was noticed that after 248 days of uptime 32bit MIPS based devices would start to signal that they had stopped applying multicast snooping due to missing queriers - even though they were the elected querier and still sending MLD queries themselves. While time_is_before_jiffies() generally is safe against jiffies wrap-arounds, like the code comments in jiffies.h explain, it won't be able to track a difference larger than ULONG_MAX/2. With a 32bit large jiffies and one jiffies tick every 10ms (CONFIG_HZ=100) on these MIPS devices running OpenWrt this would result in a difference larger than ULONG_MAX/2 after 248 (= 2^32/100/60/60/24/2) days and time_is_before_jiffies() would then start to return false instead of true. Leading to multicast snooping not being applied to multicast packets anymore. Fix this issue by using a proper timer_list object which won't have this ULONG_MAX/2 difference limitation. Fixes: b00589af3b04 ("bridge: disable snooping if there is no querier") Signed-off-by: Linus Lüssing Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20240127175033.9640-1-linus.luessing@c0d3.blue Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 289bf49818917044b0fb2406922c3507911f0bee Author: Ido Schimmel Date: Mon Jan 29 14:37:03 2024 +0200 selftests: net: Add missing matchall classifier [ Upstream commit b40f873a7c80dbafbb6f4a7a569f2dcaf969d283 ] One of the test cases in the test_bridge_backup_port.sh selftest relies on a matchall classifier to drop unrelated traffic so that the Tx drop counter on the VXLAN device will only be incremented as a result of traffic generated by the test. However, the configuration option for the matchall classifier is missing from the configuration file which might explain the failures we see in the netdev CI [1]. Fix by adding CONFIG_NET_CLS_MATCHALL to the configuration file. [1] # Backup nexthop ID - invalid IDs # ------------------------------- [...] # TEST: Forwarding out of vx0 [ OK ] # TEST: No forwarding using backup nexthop ID [ OK ] # TEST: Tx drop increased [FAIL] # TEST: IPv6 address family nexthop as backup nexthop [ OK ] # TEST: No forwarding out of swp1 [ OK ] # TEST: Forwarding out of vx0 [ OK ] # TEST: No forwarding using backup nexthop ID [ OK ] # TEST: Tx drop increased [FAIL] [...] Fixes: b408453053fb ("selftests: net: Add bridge backup port and backup nexthop ID test") Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20240129123703.1857843-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8e51f084b5716653f19e291ed5f026791d4b3ed4 Author: Eric Dumazet Date: Fri Jan 26 16:55:32 2024 +0000 llc: call sock_orphan() at release time [ Upstream commit aa2b2eb3934859904c287bf5434647ba72e14c1c ] syzbot reported an interesting trace [1] caused by a stale sk->sk_wq pointer in a closed llc socket. In commit ff7b11aa481f ("net: socket: set sock->sk to NULL after calling proto_ops::release()") Eric Biggers hinted that some protocols are missing a sock_orphan(), we need to perform a full audit. In net-next, I plan to clear sock->sk from sock_orphan() and amend Eric patch to add a warning. [1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Freed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inline] slab_free mm/slub.c:4299 [inline] kmem_cache_free+0x129/0x350 mm/slub.c:4363 i_callback+0x43/0x70 fs/inode.c:249 rcu_do_batch kernel/rcu/tree.c:2158 [inline] rcu_core+0x819/0x1680 kernel/rcu/tree.c:2433 __do_softirq+0x21a/0x8de kernel/softirq.c:553 Last potentially related work creation: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 __kasan_record_aux_stack+0xba/0x100 mm/kasan/generic.c:586 __call_rcu_common.constprop.0+0x9a/0x7b0 kernel/rcu/tree.c:2683 destroy_inode+0x129/0x1b0 fs/inode.c:315 iput_final fs/inode.c:1739 [inline] iput.part.0+0x560/0x7b0 fs/inode.c:1765 iput+0x5c/0x80 fs/inode.c:1755 dentry_unlink_inode+0x292/0x430 fs/dcache.c:400 __dentry_kill+0x1ca/0x5f0 fs/dcache.c:603 dput.part.0+0x4ac/0x9a0 fs/dcache.c:845 dput+0x1f/0x30 fs/dcache.c:835 __fput+0x3b9/0xb70 fs/file_table.c:384 task_work_run+0x14d/0x240 kernel/task_work.c:180 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0xa8a/0x2ad0 kernel/exit.c:871 do_group_exit+0xd4/0x2a0 kernel/exit.c:1020 __do_sys_exit_group kernel/exit.c:1031 [inline] __se_sys_exit_group kernel/exit.c:1029 [inline] __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b The buggy address belongs to the object at ffff88802f4fc800 which belongs to the cache sock_inode_cache of size 1408 The buggy address is located 128 bytes inside of freed 1408-byte region [ffff88802f4fc800, ffff88802f4fcd80) The buggy address belongs to the physical page: page:ffffea0000bd3e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x2f4f8 head:ffffea0000bd3e00 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0xfff00000000840(slab|head|node=0|zone=1|lastcpupid=0x7ff) page_type: 0xffffffff() raw: 00fff00000000840 ffff888013b06b40 0000000000000000 0000000000000001 raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected page_owner tracks the page as allocated page last allocated via order 3, migratetype Reclaimable, gfp_mask 0xd20d0(__GFP_IO|__GFP_FS|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_RECLAIMABLE), pid 4956, tgid 4956 (sshd), ts 31423924727, free_ts 0 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x2d0/0x350 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c:1540 [inline] get_page_from_freelist+0xa28/0x3780 mm/page_alloc.c:3311 __alloc_pages+0x22f/0x2440 mm/page_alloc.c:4567 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0xcc/0x3a0 mm/slub.c:2407 ___slab_alloc+0x4af/0x19a0 mm/slub.c:3540 __slab_alloc.constprop.0+0x56/0xa0 mm/slub.c:3625 __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x379/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b page_owner free stack trace missing Memory state around the buggy address: ffff88802f4fc780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88802f4fc800: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88802f4fc880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88802f4fc900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88802f4fc980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: 43815482370c ("net: sock_def_readable() and friends RCU conversion") Reported-and-tested-by: syzbot+32b89eaa102b372ff76d@syzkaller.appspotmail.com Signed-off-by: Eric Dumazet Cc: Eric Biggers Cc: Kuniyuki Iwashima Reviewed-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240126165532.3396702-1-edumazet@google.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 273bc8022cb8d818b26234b36ee5b00a237677bd Author: Helge Deller Date: Fri Jan 26 09:32:20 2024 +0100 ipv6: Ensure natural alignment of const ipv6 loopback and router addresses [ Upstream commit 60365049ccbacd101654a66ddcb299abfabd4fc5 ] On a parisc64 kernel I sometimes notice this kernel warning: Kernel unaligned access to 0x40ff8814 at ndisc_send_skb+0xc0/0x4d8 The address 0x40ff8814 points to the in6addr_linklocal_allrouters variable and the warning simply means that some ipv6 function tries to read a 64-bit word directly from the not-64-bit aligned in6addr_linklocal_allrouters variable. Unaligned accesses are non-critical as the architecture or exception handlers usually will fix it up at runtime. Nevertheless it may trigger a performance penality for some architectures. For details read the "unaligned-memory-access" kernel documentation. The patch below ensures that the ipv6 loopback and router addresses will always be naturally aligned. This prevents the unaligned accesses for all architectures. Signed-off-by: Helge Deller Fixes: 034dfc5df99eb ("ipv6: export in6addr_loopback to modules") Acked-by: Paolo Abeni Link: https://lore.kernel.org/r/ZbNuFM1bFqoH-UoY@p100 Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 8fea8355a91687027adde80cdaf2bbeb613f820f Author: Michal Vokáč Date: Fri Jan 26 11:49:35 2024 +0100 net: dsa: qca8k: fix illegal usage of GPIO [ Upstream commit c44fc98f0a8ffd94fa0bd291928e7e312ffc7ca4 ] When working with GPIO, its direction must be set either when the GPIO is requested by gpiod_get*() or later on by one of the gpiod_direction_*() functions. Neither of this is done here which results in undefined behavior on some systems. As the reset GPIO is used right after it is requested here, it makes sense to configure it as GPIOD_OUT_HIGH right away. With that, the following gpiod_set_value_cansleep(1) becomes redundant and can be safely removed. Fixes: a653f2f538f9 ("net: dsa: qca8k: introduce reset via gpio feature") Signed-off-by: Michal Vokáč Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/1706266175-3408-1-git-send-email-michal.vokac@ysoft.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b355270f96ab15a0ce6673a6cce275f4402125d6 Author: Christophe JAILLET Date: Sat Jan 20 18:25:36 2024 +0100 ixgbe: Fix an error handling path in ixgbe_read_iosf_sb_reg_x550() [ Upstream commit bbc404d20d1b46d89b461918bc44587620eda200 ] All error handling paths, except this one, go to 'out' where release_swfw_sync() is called. This call balances the acquire_swfw_sync() call done at the beginning of the function. Branch to the error handling path in order to correctly release some resources in case of error. Fixes: ae14a1d8e104 ("ixgbe: Fix IOSF SB access issues") Signed-off-by: Christophe JAILLET Reviewed-by: Simon Horman Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit bbe51648a7ad96af5bb67459f1167c05dfff0879 Author: Jedrzej Jagielski Date: Mon Dec 18 11:39:25 2023 +0100 ixgbe: Refactor overtemp event handling [ Upstream commit 6c1b4af8c1b20c70dde01e58381685d6a4a1d2c8 ] Currently ixgbe driver is notified of overheating events via internal IXGBE_ERR_OVERTEMP error code. Change the approach for handle_lasi() to use freshly introduced is_overtemp function parameter which set when such event occurs. Change check_overtemp() to bool and return true if overtemp event occurs. Reviewed-by: Przemek Kitszel Signed-off-by: Jedrzej Jagielski Reviewed-by: Jacob Keller Reviewed-by: Simon Horman Tested-by: Sunitha Mekala (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 7de154f66db5f9d5beae82b61cf6a916725a8edc Author: Jedrzej Jagielski Date: Mon Dec 18 11:39:26 2023 +0100 ixgbe: Refactor returning internal error codes [ Upstream commit 5795f533f30a80aa0473652876296ebc9129e33a ] Change returning codes to the kernel ones instead of the internal ones for the entire ixgbe driver. Reviewed-by: Jacob Keller Reviewed-by: Przemek Kitszel Reviewed-by: Simon Horman Signed-off-by: Jedrzej Jagielski Tested-by: Sunitha Mekala (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Stable-dep-of: bbc404d20d1b ("ixgbe: Fix an error handling path in ixgbe_read_iosf_sb_reg_x550()") Signed-off-by: Sasha Levin commit 8ad7b0ac9f6744d4aa7cb2d2481cf863be7a3f70 Author: Jacob Keller Date: Mon Dec 11 18:05:52 2023 -0800 e1000e: correct maximum frequency adjustment values [ Upstream commit f1f6a6b1830a8f1dc92ee26fae76333f446b0663 ] The e1000e driver supports hardware with a variety of different clock speeds, and thus a variety of different increment values used for programming its PTP hardware clock. The values currently programmed in e1000e_ptp_init are incorrect. In particular, only two maximum adjustments are used: 24000000 - 1, and 600000000 - 1. These were originally intended to be used with the 96 MHz clock and the 25 MHz clock. Both of these values are actually slightly too high. For the 96 MHz clock, the actual maximum value that can safely be programmed is 23,999,938. For the 25 MHz clock, the maximum value is 599,999,904. Worse, several devices use a 24 MHz clock or a 38.4 MHz clock. These parts are incorrectly assigned one of either the 24million or 600million values. For the 24 MHz clock, this is not a significant issue: its current increment value can support an adjustment up to 7billion in the positive direction. However, the 38.4 KHz clock uses an increment value which can only support up to 230,769,157 before it starts overflowing. To understand where these values come from, consider that frequency adjustments have the form of: new_incval = base_incval + (base_incval * adjustment) / (unit of adjustment) The maximum adjustment is reported in terms of parts per billion: new_incval = base_incval + (base_incval * adjustment) / 1 billion The largest possible adjustment is thus given by the following: max_incval = base_incval + (base_incval * max_adj) / 1 billion Re-arranging to solve for max_adj: max_adj = (max_incval - base_incval) * 1 billion / base_incval We also need to ensure that negative adjustments cannot underflow. This can be achieved simply by ensuring max_adj is always less than 1 billion. Introduce new macros in e1000.h codifying the maximum adjustment in PPB for each frequency given its associated increment values. Also clarify where these values come from by commenting about the above equations. Replace the switch statement in e1000e_ptp_init with one which mirrors the increment value switch statement from e1000e_get_base_timinica. For each device, assign the appropriate maximum adjustment based on its frequency. Some parts can have one of two frequency modes as determined by E1000_TSYNCRXCTL_SYSCFI. Since the new flow directly matches the assignments in e1000e_get_base_timinca, and uses well defined macro names, it is much easier to verify that the resulting maximum adjustments are correct. It also avoids difficult to parse construction such as the "hw->mac.type < e1000_phc_lpt", and the use of fallthrough which was especially confusing when combined with a conditional block. Note that I believe the current increment value configuration used for 24MHz clocks is sub-par, as it leaves at least 3 extra bits available in the INCVALUE register. However, fixing that requires more careful review of the clock rate and associated values. Reported-by: Trey Harrison Fixes: 68fe1d5da548 ("e1000e: Add Support for 38.4MHZ frequency") Fixes: d89777bf0e42 ("e1000e: add support for IEEE-1588 PTP") Signed-off-by: Jacob Keller Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1b8adcc0e2c584fec778add7777fe28e20781e60 Author: Eric Dumazet Date: Thu Jan 25 10:33:17 2024 +0000 tcp: add sanity checks to rx zerocopy [ Upstream commit 577e4432f3ac810049cb7e6b71f4d96ec7c6e894 ] TCP rx zerocopy intent is to map pages initially allocated from NIC drivers, not pages owned by a fs. This patch adds to can_map_frag() these additional checks: - Page must not be a compound one. - page->mapping must be NULL. This fixes the panic reported by ZhangPeng. syzbot was able to loopback packets built with sendfile(), mapping pages owned by an ext4 file to TCP rx zerocopy. r3 = socket$inet_tcp(0x2, 0x1, 0x0) mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0) r4 = socket$inet_tcp(0x2, 0x1, 0x0) bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10) connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10) r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) fallocate(r5, 0x0, 0x0, 0x85b8) sendfile(r4, r5, 0x0, 0x8ba0) getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40) r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0) Fixes: 93ab6cc69162 ("tcp: implement mmap() for zero copy receive") Link: https://lore.kernel.org/netdev/5106a58e-04da-372a-b836-9d3d0bd2507b@huawei.com/T/ Reported-and-bisected-by: ZhangPeng Signed-off-by: Eric Dumazet Cc: Arjun Roy Cc: Matthew Wilcox Cc: linux-mm@vger.kernel.org Cc: Andrew Morton Cc: linux-fsdevel@vger.kernel.org Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7271930bc9de0c780676b0129b0f693419035bea Author: Linus Torvalds Date: Sat Jan 27 13:21:14 2024 -0800 tracefs: remove stale 'update_gid' code [ Upstream commit 29142dc92c37d3259a33aef15b03e6ee25b0d188 ] The 'eventfs_update_gid()' function is no longer called, so remove it (and the helper function it uses). Link: https://lore.kernel.org/all/CAHk-=wj+DsZZ=2iTUkJ-Nojs9fjYMvPs1NuoM3yK7aTDtJfPYQ@mail.gmail.com/ Fixes: 8186fff7ab64 ("tracefs/eventfs: Use root and instance inodes as default ownership") Signed-off-by: Linus Torvalds Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit f006b7d61cc55e74159ec4170aaf28ffad99b241 Author: Horatiu Vultur Date: Wed Jan 24 11:17:58 2024 +0100 net: lan966x: Fix port configuration when using SGMII interface [ Upstream commit 62b4248105353e7d1debd30ca5c57ec5e5f28e35 ] In case the interface between the MAC and the PHY is SGMII, then the bit GIGA_MODE on the MAC side needs to be set regardless of the speed at which it is running. Fixes: d28d6d2e37d1 ("net: lan966x: add port module support") Signed-off-by: Horatiu Vultur Reviewed-by: Maxime Chevallier Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2e8c9ae40adda2be1ba41c05fd3cd1e61cce3207 Author: Nicolas Dichtel Date: Thu Jan 25 15:18:47 2024 +0100 ipmr: fix kernel panic when forwarding mcast packets [ Upstream commit e622502c310f1069fd9f41cd38210553115f610a ] The stacktrace was: [ 86.305548] BUG: kernel NULL pointer dereference, address: 0000000000000092 [ 86.306815] #PF: supervisor read access in kernel mode [ 86.307717] #PF: error_code(0x0000) - not-present page [ 86.308624] PGD 0 P4D 0 [ 86.309091] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Tainted: G U 6.8.0-6wind-knet #1 [ 86.311027] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [ 86.313399] Code: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff ff 49 83 47 38 01 45 85 e4 0f [ 86.316565] RSP: 0018:ffffad21c0583ae0 EFLAGS: 00010246 [ 86.317497] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 86.318596] RDX: ffff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000 [ 86.319627] RBP: ffffad21c0583b30 R08: 0000000000000000 R09: 0000000000000000 [ 86.320650] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 [ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80 [ 86.322873] FS: 00007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000 [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0 [ 86.326589] Call Trace: [ 86.327036] [ 86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479) [ 86.328049] ? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434) [ 86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707) [ 86.329107] ? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264) [ 86.329756] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.330350] ? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminator 1)) [ 86.331013] ? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch/x86/mm/fault.c:1563) [ 86.331702] ? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570) [ 86.332468] ? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [ 86.333183] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet/net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273) [ 86.334583] ? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363) [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.336854] ? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944) [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862) [ 86.339232] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.339809] ? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181) [ 86.340342] ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:1415) [ 86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836) [ 86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminator 13)) [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716) [ 86.342747] do_sock_setsockopt (/build/work/knet/net/socket.c:2313) [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/knet/net/socket.c:2336) [ 86.344020] __x64_sys_setsockopt (/build/work/knet/net/socket.c:2340) [ 86.344766] do_syscall_64 (/build/work/knet/arch/x86/entry/common.c:52 /build/work/knet/arch/x86/entry/common.c:83) [ 86.345433] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.346161] ? syscall_exit_work (/build/work/knet/./include/linux/audit.h:357 /build/work/knet/kernel/entry/common.c:160) [ 86.346938] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.347657] ? syscall_exit_to_user_mode (/build/work/knet/kernel/entry/common.c:215) [ 86.348538] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.349262] ? do_syscall_64 (/build/work/knet/./arch/x86/include/asm/cpufeature.h:171 /build/work/knet/arch/x86/entry/common.c:98) [ 86.349971] entry_SYSCALL_64_after_hwframe (/build/work/knet/arch/x86/entry/entry_64.S:129) The original packet in ipmr_cache_report() may be queued and then forwarded with ip_mr_forward(). This last function has the assumption that the skb dst is set. After the below commit, the skb dst is dropped by ipv4_pktinfo_prepare(), which causes the oops. Fixes: bb7403655b3c ("ipmr: support IP_PKTINFO on cache report IGMP msg") Signed-off-by: Nicolas Dichtel Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20240125141847.1931933-1-nicolas.dichtel@6wind.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e151d85777d99a0b2ded3210bf2b636fc6aaf2fa Author: Daniel Golle Date: Wed Jan 24 05:17:25 2024 +0000 net: dsa: mt7530: fix 10M/100M speed on MT7988 switch [ Upstream commit dfa988b4c7c3a48bde7c2713308920c7741fff29 ] Setup PMCR port register for actual speed and duplex on internally connected PHYs of the MT7988 built-in switch. This fixes links with speeds other than 1000M. Fixes: 110c18bfed41 ("net: dsa: mt7530: introduce driver for MT7988 built-in switch") Signed-off-by: Daniel Golle Reviewed-by: Vladimir Oltean Acked-by: Arınç ÜNAL Link: https://lore.kernel.org/r/a5b04dfa8256d8302f402545a51ac4c626fdba25.1706071272.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit c835df3bcc14858ae9b27315dd7de76370b94f3a Author: Eric Dumazet Date: Thu Jan 25 17:05:57 2024 +0000 ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv() [ Upstream commit 8d975c15c0cd744000ca386247432d57b21f9df0 ] syzbot found __ip6_tnl_rcv() could access unitiliazed data [1]. Call pskb_inet_may_pull() to fix this, and initialize ipv6h variable after this call as it can change skb->head. [1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023 Fixes: 0d3c703a9d17 ("ipv6: Cleanup IPv6 tunnel receive path") Reported-by: syzbot Signed-off-by: Eric Dumazet Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240125170557.2663942-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fbe4ba473428bd65329d50821d76884c0d0d162d Author: Paolo Abeni Date: Thu Jan 25 19:09:06 2024 +0100 selftests: net: give more time for GRO aggregation [ Upstream commit 89abe628375301fedb68770644df845d49018d8b ] The gro.sh test-case relay on the gro_flush_timeout to ensure that all the segments belonging to any given batch are properly aggregated. The other end, the sender is a user-space program transmitting each packet with a separate write syscall. A busy host and/or stracing the sender program can make the relevant segments reach the GRO engine after the flush timeout triggers. Give the GRO flush timeout more slack, to avoid sporadic self-tests failures. Fixes: 9af771d2ec04 ("selftests/net: allow GRO coalesce test on veth") Signed-off-by: Paolo Abeni Reviewed-by: Eric Dumazet Tested-by: Eric Dumazet Link: https://lore.kernel.org/r/bffec2beab3a5672dd13ecabe4fad81d2155b367.1706206101.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dcf532c72ea1ca3e5f60eaa14fc756305f96b811 Author: Paolo Abeni Date: Thu Jan 25 09:22:50 2024 +0100 selftests: net: add missing required classifier [ Upstream commit d3cb3b0088ca92082e2bebc40cc6894a632173e2 ] the udpgro_fraglist self-test uses the BPF classifiers, but the current net self-test configuration does not include it, causing CI failures: # selftests: net: udpgro_frglist.sh # ipv6 # tcp - over veth touching data # -l 4 -6 -D 2001:db8::1 -t rx -4 -t # Error: TC classifier not found. # We have an error talking to the kernel # Error: TC classifier not found. # We have an error talking to the kernel Add the missing knob. Fixes: edae34a3ed92 ("selftests net: add UDP GRO fraglist + bpf self-tests") Signed-off-by: Paolo Abeni Reviewed-by: Maciej Żenczykowski Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/7c3643763b331e9a400e1874fe089193c99a1c3f.1706170897.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4edbcd0c23de893ce3c403dfe9ebe5b2a01157d9 Author: Paolo Abeni Date: Fri Jan 26 16:32:36 2024 +0100 selftests: net: add missing config for big tcp tests [ Upstream commit fcf67d82b8b878bdd95145382be43927bce07ec6 ] The big_tcp test-case requires a few kernel knobs currently not specified in the net selftests config, causing the following failure: # selftests: net: big_tcp.sh # Error: Failed to load TC action module. # We have an error talking to the kernel ... # Testing for BIG TCP: # CLI GSO | GW GRO | GW GSO | SER GRO # ./big_tcp.sh: line 107: test: !=: unary operator expected ... # on on on on : [FAIL_on_link1] Add the missing configs Fixes: 6bb382bcf742 ("selftests: add a selftest for big tcp") Signed-off-by: Paolo Abeni Acked-by: Aaron Conole Acked-by: Xin Long Link: https://lore.kernel.org/all/21630ecea872fea13f071342ac64ef52a991a9b5.1706282943.git.pabeni@redhat.com/ Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1cb0d682a8b0cd196a88e90398157430793efdbd Author: Gaurav Jain Date: Thu Jan 18 14:55:57 2024 +0530 crypto: caam - fix asynchronous hash [ Upstream commit c5a2f74db71a849f3a60bc153d684d6d28a0c665 ] ahash_alg->setkey is updated to ahash_nosetkey in ahash.c so checking setkey() function to determine hmac algorithm is not valid. to fix this added is_hmac variable in structure caam_hash_alg to determine whether the algorithm is hmac or not. Fixes: 2f1f34c1bf7b ("crypto: ahash - optimize performance when wrapping shash") Signed-off-by: Gaurav Jain Reviewed-by: Eric Biggers Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a9a9ebac5ccf173061dd7f359d2dd8691c7aeb0b Author: Daniel Golle Date: Wed Jan 24 05:18:23 2024 +0000 net: phy: mediatek-ge-soc: sync driver with MediaTek SDK [ Upstream commit ff63cc2e95065bea978d2db01f7e7356cca3d021 ] Sync initialization and calibration routines with MediaTek's reference driver. Improves compliance and resolves link stability issues with CH340 IoT devices connected to MT798x built-in PHYs. Fixes: 98c485eaf509 ("net: phy: add driver for MediaTek SoC built-in GE PHYs") Signed-off-by: Daniel Golle Link: https://lore.kernel.org/r/f2195279c234c0f618946424b8236026126bc595.1706071311.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 06cbb48eece99a509d95e3a8a3e3fbe1720d9f8c Author: Daniel Golle Date: Wed Jan 24 16:22:09 2024 +0000 net: ethernet: mtk_eth_soc: set DMA coherent mask to get PPE working [ Upstream commit cae1f1c36661f28c92a1db9113961a9ebd61dbaa ] Set DMA coherent mask to 32-bit which makes PPE offloading engine start working on BPi-R4 which got 4 GiB of RAM. Fixes: 2d75891ebc09 ("net: ethernet: mtk_eth_soc: support 36-bit DMA addressing on MT7988") Suggested-by: Elad Yifee Signed-off-by: Daniel Golle Link: https://lore.kernel.org/r/97e90925368b405f0974b9b15f1b7377c4a329ad.1706113251.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3d9c788612d1d6fc9038d0992b75949d93fc34eb Author: Praveen Kaligineedi Date: Wed Jan 24 08:10:25 2024 -0800 gve: Fix skb truesize underestimation [ Upstream commit 534326711000c318fe1523c77308450522baa499 ] For a skb frag with a newly allocated copy page, the true size is incorrectly set to packet buffer size. It should be set to PAGE_SIZE instead. Fixes: 82fd151d38d9 ("gve: Reduce alloc and copy costs in the GQ rx path") Signed-off-by: Praveen Kaligineedi Link: https://lore.kernel.org/r/20240124161025.1819836-1-pkaligineedi@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45db5ea14a7787bc9386517bdc7d962bb2fb75e8 Author: Paolo Abeni Date: Wed Jan 24 22:33:22 2024 +0100 selftests: net: explicitly wait for listener ready [ Upstream commit 4acffb66630a0e4800880baa61a54ef18047ccd3 ] The UDP GRO forwarding test still hard-code an arbitrary pause to wait for the UDP listener becoming ready in background. That causes sporadic failures depending on the host load. Replace the sleep with the existing helper waiting for the desired port being exposed. Fixes: a062260a9d5f ("selftests: net: add UDP GRO forwarding self-tests") Signed-off-by: Paolo Abeni Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/4d58900fb09cef42749cfcf2ad7f4b91a97d225c.1706131762.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5b2f2ea79b7a1b54867d74d1524bbc5883c91c2f Author: Paolo Abeni Date: Wed Jan 24 22:33:20 2024 +0100 selftests: net: remove dependency on ebpf tests [ Upstream commit 98cb12eb52a780e682bea8372fdb2912c08132dd ] Several net tests requires an XDP program build under the ebpf directory, and error out if such program is not available. That makes running successful net test hard, let's duplicate into the net dir the [very small] program, re-using the existing rules to build it, and finally dropping the bogus dependency. Signed-off-by: Paolo Abeni Reviewed-by: Willem de Bruijn Link: https://lore.kernel.org/r/28e7af7c031557f691dc8045ee41dd549dd5e74c.1706131762.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski Stable-dep-of: 4acffb66630a ("selftests: net: explicitly wait for listener ready") Signed-off-by: Sasha Levin commit af6cf5a166641ebc8dbf5fa1697d0cfe327c80d3 Author: Su Hui Date: Thu Jan 25 14:32:26 2024 +0800 HID: hidraw: fix a problem of memory leak in hidraw_release() [ Upstream commit a3bdcdd022c68942a774e8e63424cc11c85aab78 ] 'struct hidraw_list' is a circular queue whose head can be smaller than tail. Using 'list->tail != list->head' to release all memory that should be released. Fixes: a5623a203cff ("HID: hidraw: fix memory leak in hidraw_release()") Signed-off-by: Su Hui Reviewed-by: Dan Carpenter Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 07e3ca0f17f579491b5f54e9ed05173d6c1d6fcb Author: Ming Lei Date: Fri Jan 12 15:00:00 2024 +0800 scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler [ Upstream commit 4373534a9850627a2695317944898eb1283a2db0 ] Inside scsi_eh_wakeup(), scsi_host_busy() is called & checked with host lock every time for deciding if error handler kthread needs to be waken up. This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requests If recovery is triggered in case that all requests are in-flight, each scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called for the last in-flight request, scsi_host_busy() has been run for (N * M - 1) times, and request has been iterated for (N*M - 1) * (N * M) times. If both N and M are big enough, hard lockup can be triggered on acquiring host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169). Fix the issue by calling scsi_host_busy() outside the host lock. We don't need the host lock for getting busy count because host the lock never covers that. [mkp: Drop unnecessary 'busy' variables pointed out by Bart] Cc: Ewan Milne Fixes: 6eb045e092ef ("scsi: core: avoid host-wide host_busy counter for scsi_mq") Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20240112070000.4161982-1-ming.lei@redhat.com Reviewed-by: Ewan D. Milne Reviewed-by: Sathya Prakash Veerichetty Tested-by: Sathya Prakash Veerichetty Reviewed-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 01091df9fa7c1412609eb30f5dd08c55ba74153f Author: Romain Naour Date: Tue Jan 23 12:14:56 2024 +0100 regulator: ti-abb: don't use devm_platform_ioremap_resource_byname for shared interrupt register [ Upstream commit a67e1f0bd4564b485e0f0c3ed7f6bf17688be268 ] We can't use devm_platform_ioremap_resource_byname() to remap the interrupt register that can be shared between regulator-abb-{ivahd,dspeve,gpu} drivers instances. The combined helper introduce a call to devm_request_mem_region() that creates a new busy resource region on PRM_IRQSTATUS_MPU register (0x4ae06010). The first devm_request_mem_region() call succeeds for regulator-abb-ivahd but fails for the two other regulator-abb-dspeve and regulator-abb-gpu. # cat /proc/iomem | grep -i 4ae06 4ae06010-4ae06013 : 4ae07e34.regulator-abb-ivahd int-address 4ae06014-4ae06017 : 4ae07ddc.regulator-abb-mpu int-address regulator-abb-dspeve and regulator-abb-gpu are missing due to devm_request_mem_region() failure (EBUSY): [ 1.326660] ti_abb 4ae07e30.regulator-abb-dspeve: can't request region for resource [mem 0x4ae06010-0x4ae06013] [ 1.326660] ti_abb: probe of 4ae07e30.regulator-abb-dspeve failed with error -16 [ 1.327239] ti_abb 4ae07de4.regulator-abb-gpu: can't request region for resource [mem 0x4ae06010-0x4ae06013] [ 1.327270] ti_abb: probe of 4ae07de4.regulator-abb-gpu failed with error -16 >From arm/boot/dts/dra7.dtsi: The abb_mpu is the only instance using its own interrupt register: (0x4ae06014) PRM_IRQSTATUS_MPU_2, ABB_MPU_DONE_ST (bit 7) The other tree instances (abb_ivahd, abb_dspeve, abb_gpu) share PRM_IRQSTATUS_MPU register (0x4ae06010) but use different bits ABB_IVA_DONE_ST (bit 30), ABB_DSPEVE_DONE_ST( bit 29) and ABB_GPU_DONE_ST (but 28). The commit b36c6b1887ff ("regulator: ti-abb: Make use of the helper function devm_ioremap related") overlooked the following comment implicitly explaining why devm_ioremap() is used in this case: /* * We may have shared interrupt register offsets which are * write-1-to-clear between domains ensuring exclusivity. */ Fixes and partially reverts commit b36c6b1887ff ("regulator: ti-abb: Make use of the helper function devm_ioremap related"). Improve the existing comment to avoid further conversion to devm_platform_ioremap_resource_byname(). Fixes: b36c6b1887ff ("regulator: ti-abb: Make use of the helper function devm_ioremap related") Signed-off-by: Romain Naour Reviewed-by: Yoann Congal Link: https://msgid.link/r/20240123111456.739381-1-romain.naour@smile.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c2112d9d1559a963dc7de5037b74870f5f6e3c87 Author: Marco Pagani Date: Wed Jan 10 16:59:47 2024 +0100 kunit: run test suites only after module initialization completes [ Upstream commit a1af6a2bfa0cb46d70b7df5352993e750da6c79b ] Commit 2810c1e99867 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()") fixed a wild-memory-access bug that could have happened during the loading phase of test suites built and executed as loadable modules. However, it also introduced a problematic side effect that causes test suites modules to crash when they attempt to register fake devices. When a module is loaded, it traverses the MODULE_STATE_UNFORMED and MODULE_STATE_COMING states before reaching the normal operating state MODULE_STATE_LIVE. Finally, when the module is removed, it moves to MODULE_STATE_GOING before being released. However, if the loading function load_module() fails between complete_formation() and do_init_module(), the module goes directly from MODULE_STATE_COMING to MODULE_STATE_GOING without passing through MODULE_STATE_LIVE. This behavior was causing kunit_module_exit() to be called without having first executed kunit_module_init(). Since kunit_module_exit() is responsible for freeing the memory allocated by kunit_module_init() through kunit_filter_suites(), this behavior was resulting in a wild-memory-access bug. Commit 2810c1e99867 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()") fixed this issue by running the tests when the module is still in MODULE_STATE_COMING. However, modules in that state are not fully initialized, lacking sysfs kobjects. Therefore, if a test module attempts to register a fake device, it will inevitably crash. This patch proposes a different approach to fix the original wild-memory-access bug while restoring the normal module execution flow by making kunit_module_exit() able to detect if kunit_module_init() has previously initialized the tests suite set. In this way, test modules can once again register fake devices without crashing. This behavior is achieved by checking whether mod->kunit_suites is a virtual or direct mapping address. If it is a virtual address, then kunit_module_init() has allocated the suite_set in kunit_filter_suites() using kmalloc_array(). On the contrary, if mod->kunit_suites is still pointing to the original address that was set when looking up the .kunit_test_suites section of the module, then the loading phase has failed and there's no memory to be freed. v4: - rebased on 6.8 - noted that kunit_filter_suites() must return a virtual address v3: - add a comment to clarify why the start address is checked v2: - add include Fixes: 2810c1e99867 ("kunit: Fix wild-memory-access bug in kunit_free_suite_set()") Reviewed-by: David Gow Tested-by: Rae Moar Tested-by: Richard Fitzgerald Reviewed-by: Javier Martinez Canillas Signed-off-by: Marco Pagani Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 27dea596af6bc7fdc012b8ff27cbe8448a74c58a Author: Su Hui Date: Fri Jan 12 12:19:27 2024 +0800 scsi: isci: Fix an error code problem in isci_io_request_build() [ Upstream commit 658365c6b0857e6a306436e315a8633937e3af42 ] Clang static complains that Value stored to 'status' is never read. Return 'status' rather than 'SCI_SUCCESS'. Fixes: f1f52e75939b ("isci: uplevel request infrastructure") Signed-off-by: Su Hui Link: https://lore.kernel.org/r/20240112041926.3924315-1-suhui@nfschina.com Reviewed-by: Artur Paszkiewicz Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6fd3577b917a644b28134e6ed61420af453877de Author: Alexandre Ghiti Date: Thu Jan 18 22:21:20 2024 +0100 riscv: Fix build error on rv32 + XIP [ Upstream commit 66f962d8939fd2ac74de901d30d30310c8ddca79 ] commit 66f1e6809397 ("riscv: Make XIP bootable again") restricted page offset to the sv39 page offset instead of the default sv57, which makes sense since probably the platforms that target XIP kernels do not support anything else than sv39 and we do not try to find out the largest address space supported on XIP kernels (ie set_satp_mode()). But PAGE_OFFSET_L3 is not defined for rv32, so fix the build error by restoring the previous behaviour which picks CONFIG_PAGE_OFFSET for rv32. Fixes: 66f1e6809397 ("riscv: Make XIP bootable again") Reported-by: Randy Dunlap Closes: https://lore.kernel.org/linux-riscv/344dca85-5c48-44e1-bc64-4fa7973edd12@infradead.org/T/#u Signed-off-by: Alexandre Ghiti Acked-by: Randy Dunlap Tested-by: Randy Dunlap # build-tested Link: https://lore.kernel.org/r/20240118212120.2087803-1-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 4df01ecba883c2b4ca3e24f746d3b01e528e19e0 Author: Jonathan Kim Date: Wed Dec 13 22:08:03 2023 -0500 drm/amdkfd: only flush mes process context if mes support is there [ Upstream commit 24149412dfc71f7f4a54868702e9145e396263d3 ] Fix up on mes process context flush to prevent non-mes devices from spamming error messages or running into undefined behaviour during process termination. Fixes: bd33bb1409b4 ("drm/amdkfd: fix mes set shader debugger process management") Signed-off-by: Jonathan Kim Reviewed-by: Eric Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 86bd8334af92440253f0a9b18e85e97b70659dea Author: Rob Clark Date: Thu Nov 30 11:21:18 2023 -0800 drm/msm/dpu: Correct UBWC settings for sc8280xp [ Upstream commit 0b414c731432917c83353c446e60ee838c9a9cfd ] The UBWC settings need to match between the display and GPU. When we updated the GPU settings, we forgot to make the corresponding update on the display side. Reported-by: Steev Klimaszewski Fixes: 07e6de738aa6 ("drm/msm/a690: Fix reg values for a690") Signed-off-by: Rob Clark Tested-by: Steev Klimaszewski Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/569817/ Link: https://lore.kernel.org/r/20231130192119.32538-1-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e2dc8036aed0f57adba59b1ebee034a372e509a5 Author: Stephen Rothwell Date: Tue Dec 19 14:57:34 2023 +1100 drm: using mul_u32_u32() requires linux/math64.h [ Upstream commit 933a2a376fb3f22ba4774f74233571504ac56b02 ] Some pending include file cleanups produced this error: In file included from include/linux/kernel.h:27, from drivers/gpu/ipu-v3/ipu-dp.c:7: include/drm/drm_color_mgmt.h: In function 'drm_color_lut_extract': include/drm/drm_color_mgmt.h:45:46: error: implicit declaration of function 'mul_u32_u32' [-Werror=implicit-function-declaration] 45 | return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(user_input, (1 << bit_precision) - 1), | ^~~~~~~~~~~ Fixes: c6fbb6bca108 ("drm: Fix color LUT rounding") Signed-off-by: Stephen Rothwell Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20231219145734.13e40e1e@canb.auug.org.au Signed-off-by: Sasha Levin commit 171cd66ffd0a05082cb08e09f7037866c960179b Author: Edward Adam Davis Date: Wed Jan 3 20:13:51 2024 +0800 wifi: cfg80211: fix RCU dereference in __cfg80211_bss_update [ Upstream commit 1184950e341c11b6f82bc5b59564411d9537ab27 ] Replace rcu_dereference() with rcu_access_pointer() since we hold the lock here (and aren't in an RCU critical section). Fixes: 32af9a9e1069 ("wifi: cfg80211: free beacon_ies when overridden from hidden BSS") Reported-and-tested-by: syzbot+864a269c27ee06b58374@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Link: https://msgid.link/tencent_BF8F0DF0258C8DBF124CDDE4DD8D992DCF07@qq.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit bb94033815c1d1fd1241885604e4ba60563172e2 Author: Peter Zijlstra Date: Wed Nov 22 11:07:56 2023 +0100 perf: Fix the nr_addr_filters fix [ Upstream commit 388a1fb7da6aaa1970c7e2a7d7fcd983a87a8484 ] Thomas reported that commit 652ffc2104ec ("perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file") made the entire attribute group vanish, instead of only the nr_addr_filters attribute. Additionally a stray return. Insufficient coffee was involved with both writing and merging the patch. Fixes: 652ffc2104ec ("perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file") Reported-by: Thomas Richter Signed-off-by: Peter Zijlstra (Intel) Tested-by: Thomas Richter Link: https://lkml.kernel.org/r/20231122100756.GP8262@noisy.programming.kicks-ass.net Signed-off-by: Sasha Levin commit df1fdef5e64c8de0ca0a665973b4f2a571f37227 Author: Tim Lunn Date: Sun Dec 3 23:39:59 2023 +1100 i2c: rk3x: Adjust mask/value offset for i2c2 on rv1126 [ Upstream commit 92a85b7c6262f19c65a1c115cf15f411ba65a57c ] Rockchip RV1126 is using old style i2c controller, the i2c2 bus uses a non-sequential offset in the grf register for the mask/value bits for this bus. This patch fixes i2c2 bus on rv1126 SoCs. Signed-off-by: Tim Lunn Acked-by: Heiko Stuebner Reviewed-by: Andi Shyti Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 9b12bd7679990bb87684ed82350982f9615fe4de Author: Srinivasan Shanmugam Date: Tue Jan 9 16:57:26 2024 +0530 drm/amdkfd: Fix 'node' NULL check in 'svm_range_get_range_boundaries()' [ Upstream commit d7a254fad873775ce6c32b77796c81e81e6b7f2e ] Range interval [start, last] is ordered by rb_tree, rb_prev, rb_next return value still needs NULL check, thus modified from "node" to "rb_node". Fixes the below: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:2691 svm_range_get_range_boundaries() warn: can 'node' even be NULL? Suggested-by: Philip Yang Cc: Felix Kuehling Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ee3dbf27cfba42fb960cdc6c64867405401ce7fb Author: Srinivasan Shanmugam Date: Thu Dec 21 18:13:11 2023 +0530 drm/amdgpu: Release 'adev->pm.fw' before return in 'amdgpu_device_need_post()' [ Upstream commit 8a44fdd3cf91debbd09b43bd2519ad2b2486ccf4 ] In function 'amdgpu_device_need_post(struct amdgpu_device *adev)' - 'adev->pm.fw' may not be released before return. Using the function release_firmware() to release adev->pm.fw. Thus fixing the below: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1571 amdgpu_device_need_post() warn: 'adev->pm.fw' from request_firmware() not released on lines: 1554. Cc: Monk Liu Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Suggested-by: Lijo Lazar Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 12c8628dc53e030e008abc25b9a3a59ae56e4c5b Author: Srinivasan Shanmugam Date: Thu Jan 4 15:26:42 2024 +0530 drm/amdgpu: Fix with right return code '-EIO' in 'amdgpu_gmc_vram_checking()' [ Upstream commit fac4ebd79fed60e79cccafdad45a2bb8d3795044 ] The amdgpu_gmc_vram_checking() function in emulation checks whether all of the memory range of shared system memory could be accessed by GPU, from this aspect, -EIO is returned for error scenarios. Fixes the below: drivers/gpu/drm/amd/amdgpu/gmc_v6_0.c:919 gmc_v6_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c:1103 gmc_v7_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c:1223 gmc_v8_0_hw_init() warn: missing error code? 'r' drivers/gpu/drm/amd/amdgpu/gmc_v9_0.c:2344 gmc_v9_0_hw_init() warn: missing error code? 'r' Cc: Xiaojian Du Cc: Lijo Lazar Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Suggested-by: Christian König Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3a4391fb28cbe0e649e56ce670486667b36f1999 Author: Srinivasan Shanmugam Date: Fri Jan 5 12:05:09 2024 +0530 drm/amd/powerplay: Fix kzalloc parameter 'ATOM_Tonga_PPM_Table' in 'get_platform_power_management_table()' [ Upstream commit 6616b5e1999146b1304abe78232af810080c67e3 ] In 'struct phm_ppm_table *ptr' allocation using kzalloc, an incorrect structure type is passed to sizeof() in kzalloc, larger structure types were used, thus using correct type 'struct phm_ppm_table' fixes the below: drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/process_pptables_v1_0.c:203 get_platform_power_management_table() warn: struct type mismatch 'phm_ppm_table vs _ATOM_Tonga_PPM_Table' Cc: Eric Huang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d72a91de56bbbf918d44da6dfcfd6909daf8c1b9 Author: Alex Deucher Date: Mon Oct 2 14:27:13 2023 -0400 drm/amdgpu: fix avg vs input power reporting on smu7 [ Upstream commit 25852d4b97572ff62ffee574cb8bb4bc551af23a ] Hawaii, Bonaire, Fiji, and Tonga support average power, the others support current power. Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f3113dfb5a39a8afb9eb6c425ca09835ab84e420 Author: Wenchao Hao Date: Thu Nov 23 09:53:40 2023 +0800 ceph: fix invalid pointer access if get_quota_realm return ERR_PTR [ Upstream commit 0f4cf64eabc6e16cfc2704f1960e82dc79d91c8d ] This issue is reported by smatch that get_quota_realm() might return ERR_PTR but we did not handle it. It's not a immediate bug, while we still should address it to avoid potential bugs if get_quota_realm() is changed to return other ERR_PTR in future. Set ceph_snap_realm's pointer in get_quota_realm()'s to address this issue, the pointer would be set to NULL if get_quota_realm() failed to get struct ceph_snap_realm, so no ERR_PTR would happen any more. [ xiubli: minor code style clean up ] Signed-off-by: Wenchao Hao Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 76cb2aa3421fee4fde706dec41b1344bc0a9ad67 Author: Xiubo Li Date: Fri Nov 17 13:26:18 2023 +0800 ceph: fix deadlock or deadcode of misusing dget() [ Upstream commit b493ad718b1f0357394d2cdecbf00a44a36fa085 ] The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first. But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it. Link: https://lore.kernel.org/r/20231116081919.GZ1957730@ZenIV Reported-by: Al Viro Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 62b3b5271bd974a26b67aa5087e0a651b77d7b22 Author: Venky Shankar Date: Mon Nov 6 10:02:32 2023 +0530 ceph: reinitialize mds feature bit even when session in open [ Upstream commit f48e0342a74d7770cdf1d11894bdc3b6d989b29e ] Following along the same lines as per the user-space fix. Right now this isn't really an issue with the ceph kernel driver because of the feature bit laginess, however, that can change over time (when the new snaprealm info type is ported to the kernel driver) and depending on the MDS version that's being upgraded can cause message decoding issues - so, fix that early on. Link: http://tracker.ceph.com/issues/63188 Signed-off-by: Venky Shankar Reviewed-by: Xiubo Li Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit f1bc0d8163f8ee84a8d5affdf624cfad657df1d2 Author: Ming Lei Date: Fri Jan 12 20:26:26 2024 +0800 blk-mq: fix IO hang from sbitmap wakeup race [ Upstream commit 5266caaf5660529e3da53004b8b7174cab6374ed ] In blk_mq_mark_tag_wait(), __add_wait_queue() may be re-ordered with the following blk_mq_get_driver_tag() in case of getting driver tag failure. Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observe the added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantime blk_mq_mark_tag_wait() can't get driver tag successfully. This issue can be reproduced by running the following test in loop, and fio hang can be observed in < 30min when running it on my test VM in laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaio Fix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), which is just fine in case of running out of tag. Cc: Jan Kara Cc: Kemeng Shi Reported-by: Changhui Zhong Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20240112122626.4181044-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b2b4599cd10c210191bd4d7362c54db1fdd84976 Author: Zhu Yanjun Date: Thu Jan 4 10:09:02 2024 +0800 virtio_net: Fix "‘%d’ directive writing between 1 and 11 bytes into a region of size 10" warnings [ Upstream commit e3fe8d28c67bf6c291e920c6d04fa22afa14e6e4 ] Fix the warnings when building virtio_net driver. " drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4551:48: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Wformat-overflow=] 4551 | sprintf(vi->rq[i].name, "input.%d", i); | ^~ In function ‘virtnet_find_vqs’, inlined from ‘init_vqs’ at drivers/net/virtio_net.c:4645:8: drivers/net/virtio_net.c:4551:41: note: directive argument in the range [-2147483643, 65534] 4551 | sprintf(vi->rq[i].name, "input.%d", i); | ^~~~~~~~~~ drivers/net/virtio_net.c:4551:17: note: ‘sprintf’ output between 8 and 18 bytes into a destination of size 16 4551 | sprintf(vi->rq[i].name, "input.%d", i); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/virtio_net.c: In function ‘init_vqs’: drivers/net/virtio_net.c:4552:49: warning: ‘%d’ directive writing between 1 and 11 bytes into a region of size 9 [-Wformat-overflow=] 4552 | sprintf(vi->sq[i].name, "output.%d", i); | ^~ In function ‘virtnet_find_vqs’, inlined from ‘init_vqs’ at drivers/net/virtio_net.c:4645:8: drivers/net/virtio_net.c:4552:41: note: directive argument in the range [-2147483643, 65534] 4552 | sprintf(vi->sq[i].name, "output.%d", i); | ^~~~~~~~~~~ drivers/net/virtio_net.c:4552:17: note: ‘sprintf’ output between 9 and 19 bytes into a destination of size 16 4552 | sprintf(vi->sq[i].name, "output.%d", i); " Reviewed-by: Xuan Zhuo Signed-off-by: Zhu Yanjun Link: https://lore.kernel.org/r/20240104020902.2753599-1-yanjun.zhu@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 1556c242e64cdffe58736aa650b0b395854fe4d4 Author: Philip Yang Date: Fri Dec 29 15:19:25 2023 -0500 drm/amdkfd: Fix lock dependency warning with srcu [ Upstream commit 2a9de42e8d3c82c6990d226198602be44f43f340 ] ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu); Signed-off-by: Philip Yang Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ce330615d4aebef3ff292ba3e403207dd7e1e1a0 Author: Daniel Miess Date: Wed Dec 20 10:34:32 2023 -0500 Revert "drm/amd/display: Fix conversions between bytes and KB" [ Upstream commit bf282eb92b84709d99186ad5940b9997eb3c1ff2 ] This reverts commit d0f639c5869399bf6dde4d694d5f8c0ab8c0ec46. The previous commit causes failure to light up for 1080p eDP + 8k HDMI panel combo. Reviewed-by: Charlene Liu Acked-by: Rodrigo Siqueira Signed-off-by: Daniel Miess Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 61b918ca6094a7db965827f2217b60f4ad0ac602 Author: Martin Tsai Date: Mon Dec 18 16:36:44 2023 +0800 drm/amd/display: To adjust dprefclk by down spread percentage [ Upstream commit 17e74e11ac2b46e7514705ae7abfb93ac0e20bd6 ] [Why] Panels show corruption with high refresh rate timings when ssc is enabled. [How] Read down-spread percentage from lut to adjust dprefclk. Issues come from S0i3 with this commit has been fixed by SMU. Reviewed-by: Nicholas Kazlauskas Acked-by: Rodrigo Siqueira Signed-off-by: Martin Tsai Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cb96e492d72d143d57db2d2bc143a1cee8741807 Author: Felix Kuehling Date: Tue Jan 2 15:07:44 2024 -0500 drm/amdkfd: Fix lock dependency warning [ Upstream commit 47bf0f83fc86df1bf42b385a91aadb910137c5c9 ] ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-fkuehlin #276 Not tainted ------------------------------------------------------ kworker/8:2/2676 is trying to acquire lock: ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}, at: __flush_work+0x52/0x550 but task is already holding lock: ffff9435cd8e1720 (&svms->lock){+.+.}-{3:3}, at: svm_range_deferred_list_work+0xe8/0x340 [amdgpu] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&svms->lock){+.+.}-{3:3}: __mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2/0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}: down_read+0x42/0x160 svm_range_evict_svm_bo_worker+0x8b/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}: __lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175/0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] process_one_work+0x27a/0x540 worker_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 other info that might help us debug this: Chain exists of: (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&svms->lock); lock(&mm->mmap_lock); lock(&svms->lock); lock((work_completion)(&svm_bo->eviction_work)); I believe this cannot really lead to a deadlock in practice, because svm_range_evict_svm_bo_worker only takes the mmap_read_lock if the BO refcount is non-0. That means it's impossible that svm_range_bo_release is running concurrently. However, there is no good way to annotate this. To avoid the problem, take a BO reference in svm_range_schedule_evict_svm_bo instead of in the worker. That way it's impossible for a BO to get freed while eviction work is pending and the cancel_work_sync call in svm_range_bo_release can be eliminated. v2: Use svm_bo_ref_unless_zero and explained why that's safe. Also removed redundant checks that are already done in amdkfd_fence_enable_signaling. Signed-off-by: Felix Kuehling Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 242b5bffa23a9c108aa3383d207b6fc31d4de95b Author: ChiYuan Huang Date: Fri Dec 29 09:46:02 2023 +0800 ASoC: codecs: rtq9128: Fix TDM enable and DAI format control flow [ Upstream commit 415d10ccef712f3ec73cd880c1fef3eb48601c3a ] To enable TDM mode, the current control flow limits the function calling order should be 'set_tdm_slot->set_dai_fmt'. But not all platform sound card like as simeple card to follow this design. To bypass this limit, adjust the DAI format setting in runtime 'hw_param' callback. Signed-off-by: ChiYuan Huang Link: https://msgid.link/r/c4c8df00d8d179b8b5b39a8521de3a85325c57e8.1703813842.git.cy_huang@richtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c272ff9859601eb2ede3275af8f58777fd87928 Author: ChiYuan Huang Date: Fri Dec 29 09:46:01 2023 +0800 ASoC: codecs: rtq9128: Fix PM_RUNTIME usage [ Upstream commit 35040410372ca27a33cec8382d42c90b6b6c99f6 ] If 'pm_runtime_resume_and_get' is used, must check the return value to prevent the active count not matched problem. Signed-off-by: ChiYuan Huang Link: https://msgid.link/r/bebd9e2bed9e0528a7fd9c528d785da02caf4f1a.1703813842.git.cy_huang@richtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c331709fb533b52f390067c635a219aaac805a02 Author: Ian Rogers Date: Thu Dec 7 16:05:13 2023 -0800 libsubcmd: Fix memory leak in uniq() [ Upstream commit ad30469a841b50dbb541df4d6971d891f703c297 ] uniq() will write one command name over another causing the overwritten string to be leaked. Fix by doing a pass that removes duplicates and a second that removes the holes. Signed-off-by: Ian Rogers Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Chenyuan Mi Cc: Ingo Molnar Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: https://lore.kernel.org/r/20231208000515.1693746-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 755182e1e8667272a082506a2a20b4cdd78ab4c2 Author: Hans de Goede Date: Sun Dec 24 19:34:02 2023 +0100 misc: lis3lv02d_i2c: Add missing setting of the reg_ctrl callback [ Upstream commit b1b9f7a494400c0c39f8cd83de3aaa6111c55087 ] The lis3lv02d_i2c driver was missing a line to set the lis3_dev's reg_ctrl callback. lis3_reg_ctrl(on) is called from the init callback, but due to the missing reg_ctrl callback the regulators where never turned off again leading to the following oops/backtrace when detaching the driver: [ 82.313527] ------------[ cut here ]------------ [ 82.313546] WARNING: CPU: 1 PID: 1724 at drivers/regulator/core.c:2396 _regulator_put+0x219/0x230 ... [ 82.313695] RIP: 0010:_regulator_put+0x219/0x230 ... [ 82.314767] Call Trace: [ 82.314770] [ 82.314772] ? _regulator_put+0x219/0x230 [ 82.314777] ? __warn+0x81/0x170 [ 82.314784] ? _regulator_put+0x219/0x230 [ 82.314791] ? report_bug+0x18d/0x1c0 [ 82.314801] ? handle_bug+0x3c/0x80 [ 82.314806] ? exc_invalid_op+0x13/0x60 [ 82.314812] ? asm_exc_invalid_op+0x16/0x20 [ 82.314845] ? _regulator_put+0x219/0x230 [ 82.314857] regulator_bulk_free+0x39/0x60 [ 82.314865] i2c_device_remove+0x22/0xb0 Add the missing setting of the callback so that the regulators properly get turned off again when not used. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20231224183402.95640-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6104a875ccc8f3bc6941ca4a5054fc3e2ca59a8 Author: Yinbo Zhu Date: Thu Dec 28 15:11:13 2023 +0800 usb: xhci-plat: fix usb disconnect issue after s4 [ Upstream commit 6d6887c42e946f43bed2e64571a40c8476a1e4a9 ] The xhci retaining bogus hardware states cause usb disconnect devices connected before hibernation(s4) and refer to the commit 'f3d478858be ("usb: ohci-platform: fix usb disconnect issue after s4")' which set flag "hibernated" as true when resume-from-hibernation and that the drivers will reset the hardware to get rid of any existing state and make sure resume from hibernation re-enumerates everything for xhci. Signed-off-by: Yinbo Zhu Link: https://lore.kernel.org/r/20231228071113.1719-1-zhuyinbo@loongson.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9c2ac5e0ea7899411fd900d4681890722a020735 Author: Steven Rostedt (Google) Date: Wed Jan 3 21:50:16 2024 -0500 tracefs/eventfs: Use root and instance inodes as default ownership [ Upstream commit 8186fff7ab649085e2c60d032d9a20a85af1d87c ] Instead of walking the dentries on mount/remount to update the gid values of all the dentries if a gid option is specified on mount, just update the root inode. Add .getattr, .setattr, and .permissions on the tracefs inode operations to update the permissions of the files and directories. For all files and directories in the top level instance: /sys/kernel/tracing/* It will use the root inode as the default permissions. The inode that represents: /sys/kernel/tracing (or wherever it is mounted). When an instance is created: mkdir /sys/kernel/tracing/instance/foo The directory "foo" and all its files and directories underneath will use the default of what foo is when it was created. A remount of tracefs will not affect it. If a user were to modify the permissions of any file or directory in tracefs, it will also no longer be modified by a change in ownership of a remount. The events directory, if it is in the top level instance, will use the tracefs root inode as the default ownership for itself and all the files and directories below it. For the events directory in an instance ("foo"), it will keep the ownership of what it was when it was created, and that will be used as the default ownership for the files and directories beneath it. Link: https://lore.kernel.org/linux-trace-kernel/CAHk-=wjVdGkjDXBbvLn2wbZnqP4UsH46E3gqJ9m7UG6DpX2+WA@mail.gmail.com/ Link: https://lore.kernel.org/linux-trace-kernel/20240103215016.1e0c9811@gandalf.local.home Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Linus Torvalds Cc: Al Viro Cc: Christian Brauner Cc: Greg Kroah-Hartman Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 763d40980339507b2c30759f7290405a387b166a Author: David Howells Date: Tue Jan 2 20:33:17 2024 +0000 9p: Fix initialisation of netfs_inode for 9p [ Upstream commit 9546ac78b232bac56ff975072b1965e0e755ebd4 ] The 9p filesystem is calling netfs_inode_init() in v9fs_init_inode() - before the struct inode fields have been initialised from the obtained file stats (ie. after v9fs_stat2inode*() has been called), but netfslib wants to set a couple of its fields from i_size. Reported-by: Marc Dionne Signed-off-by: David Howells Tested-by: Marc Dionne Tested-by: Dominique Martinet Acked-by: Dominique Martinet cc: Eric Van Hensbergen cc: Latchesar Ionkov cc: Dominique Martinet cc: Christian Schoenebeck cc: v9fs@lists.linux.dev cc: linux-cachefs@redhat.com cc: linux-fsdevel@vger.kernel.org Signed-off-by: Sasha Levin commit 98806139562988f93d0fab881408995628ae115f Author: Bjorn Helgaas Date: Wed Dec 6 16:42:30 2023 -0600 PCI/AER: Decode Requester ID when no error info found [ Upstream commit 1291b716bbf969e101d517bfb8ba18d958f758b8 ] When a device with AER detects an error, it logs error information in its own AER Error Status registers. It may send an Error Message to the Root Port (RCEC in the case of an RCiEP), which logs the fact that an Error Message was received (Root Error Status) and the Requester ID of the message source (Error Source Identification). aer_print_port_info() prints the Requester ID from the Root Port Error Source in the usual Linux "bb:dd.f" format, but when find_source_device() finds no error details in the hierarchy below the Root Port, it printed the raw Requester ID without decoding it. Decode the Requester ID in the usual Linux format so it matches other messages. Sample message changes: - pcieport 0000:00:1c.5: AER: Correctable error received: 0000:00:1c.5 - pcieport 0000:00:1c.5: AER: can't find device of ID00e5 + pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5 + pcieport 0000:00:1c.5: AER: found no error details for 0000:00:1c.5 Link: https://lore.kernel.org/r/20231206224231.732765-3-helgaas@kernel.org Signed-off-by: Bjorn Helgaas Reviewed-by: Jonathan Cameron Reviewed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Sasha Levin commit 5924739486f08fa85e82794cdab2d62da25e70fc Author: Ilpo Järvinen Date: Tue Jan 2 19:27:00 2024 +0200 PCI: Fix 64GT/s effective data rate calculation [ Upstream commit ac4f1897fa5433a1b07a625503a91b6aa9d7e643 ] Unlike the lower rates, the PCIe 64GT/s Data Rate uses 1b/1b encoding, not 128b/130b (PCIe r6.1 sec 1.2, Table 1-1). Correct the PCIE_SPEED2MBS_ENC() calculation to reflect that. Link: https://lore.kernel.org/r/20240102172701.65501-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 07c1243457aa63dbbe8fa9718ceaa3e75f353192 Author: Piro Yang Date: Wed Dec 20 01:04:47 2023 +0800 staging: vme_user: Fix the issue of return the wrong error code [ Upstream commit 5090a4bc2a2f04b7693b49500ad1287e8d0fb6c3 ] Fix the issue of returning the -ENOSYS error code when an error occurs. The error code of -ENOSYS indicates Invalid system call number, but there is not system call error. So replace -ENOSYS error code by the return -EINVAL error code. Signed-off-by: Piro Yang Link: https://lore.kernel.org/r/20231219170447.51237-1-piroyangg@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9a3881b1f07db1bb55cb0108e6f05cfd027eaf2e Author: Yu-Che Cheng Date: Wed Dec 6 15:17:25 2023 -0800 spmi: mediatek: Fix UAF on device remove [ Upstream commit e821d50ab5b956ed0effa49faaf29912fd4106d9 ] The pmif driver data that contains the clocks is allocated along with spmi_controller. On device remove, spmi_controller will be freed first, and then devres , including the clocks, will be cleanup. This leads to UAF because putting the clocks will access the clocks in the pmif driver data, which is already freed along with spmi_controller. This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and building the kernel with KASAN. Fix the UAF issue by using unmanaged clk_bulk_get() and putting the clocks before freeing spmi_controller. Reported-by: Fei Shao Signed-off-by: Yu-Che Cheng Link: https://lore.kernel.org/r/20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeid Tested-by: Fei Shao Reviewed-by: Fei Shao Reviewed-by: Chen-Yu Tsai Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20231206231733.4031901-3-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a85606425955b1b6f4e1febde1c9278c2ea2fb3 Author: Max Kellermann Date: Fri Dec 8 10:33:10 2023 +0100 fs/kernfs/dir: obey S_ISGID [ Upstream commit 5133bee62f0ea5d4c316d503cc0040cac5637601 ] Handling of S_ISGID is usually done by inode_init_owner() in all other filesystems, but kernfs doesn't use that function. In kernfs, struct kernfs_node is the primary data structure, and struct inode is only created from it on demand. Therefore, inode_init_owner() can't be used and we need to imitate its behavior. S_ISGID support is useful for the cgroup filesystem; it allows subtrees managed by an unprivileged process to retain a certain owner gid, which then enables sharing access to the subtree with another unprivileged process. -- v1 -> v2: minor coding style fix (comment) Signed-off-by: Max Kellermann Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20231208093310.297233-2-max.kellermann@ionos.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aacfe589fcfd92b8cc65634502eedc3aa0e6e10c Author: Crescent CY Hsieh Date: Thu Dec 14 14:02:34 2023 +0800 tty: serial: 8250: Set RS422 interface by default to fix Moxa RS422/RS485 PCIe boards [ Upstream commit 43f012df3c1e979966524f79b5371fde6545488a ] MOXA PCIe RS422/RS485 boards will not function by default because of the initial default serial interface of all MOXA PCIe boards is set to RS232. This patch fixes the problem above by setting the initial default serial interface to RS422 for those MOXA RS422/RS485 PCIe boards. Signed-off-by: Crescent CY Hsieh Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20231214060234.6147-1-crescentcy.hsieh@moxa.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2e95411fb60505c389fde2f8aad974c353822dd2 Author: Adrian Reber Date: Fri Dec 8 15:36:56 2023 +0100 tty: allow TIOCSLCKTRMIOS with CAP_CHECKPOINT_RESTORE [ Upstream commit e0f25b8992345aa5f113da2815f5add98738c611 ] The capability CAP_CHECKPOINT_RESTORE was introduced to allow non-root users to checkpoint and restore processes as non-root with CRIU. This change extends CAP_CHECKPOINT_RESTORE to enable the CRIU option '--shell-job' as non-root. CRIU's man-page describes the '--shell-job' option like this: Allow one to dump shell jobs. This implies the restored task will inherit session and process group ID from the criu itself. This option also allows to migrate a single external tty connection, to migrate applications like top. TIOCSLCKTRMIOS can only be done if the process has CAP_SYS_ADMIN and this change extends it to CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE. With this change it is possible to checkpoint and restore processes which have a tty connection as non-root if CAP_CHECKPOINT_RESTORE is set. Acked-by: Christian Brauner Signed-off-by: Adrian Reber Acked-by: Andrei Vagin Link: https://lore.kernel.org/r/20231208143656.1019-1-areber@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1b09cc24b1c9744c288d680c254f47b79c4143a3 Author: Jo Van Bulck Date: Thu Oct 5 17:38:50 2023 +0200 selftests/sgx: Fix linker script asserts [ Upstream commit 9fd552ee32c6c1e27c125016b87d295bea6faea7 ] DEFINED only considers symbols, not section names. Hence, replace the check for .got.plt with the _GLOBAL_OFFSET_TABLE_ symbol and remove other (non-essential) asserts. Signed-off-by: Jo Van Bulck Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Link: https://lore.kernel.org/all/20231005153854.25566-10-jo.vanbulck%40cs.kuleuven.be Signed-off-by: Sasha Levin commit cc5b0357818b0f99389fa70ec3194de8a926fe47 Author: Hardik Gajjar Date: Tue Dec 5 19:18:29 2023 +0100 usb: hub: Add quirk to decrease IN-ep poll interval for Microchip USB491x hub [ Upstream commit 855d75cf8311fee156fabb5639bb53757ca83dd4 ] There is a potential delay in notifying Linux USB drivers of downstream USB bus activity when connecting a high-speed or superSpeed device via the Microchip USB491x hub. This delay is due to the fixed bInterval value of 12 in the silicon of the Microchip USB491x hub. Microchip requested to ignore the device descriptor and decrease that value to 9 as it was too late to modify that in silicon. This patch speeds up the USB enummeration process that helps to pass Apple Carplay certifications and improve the User experience when utilizing the USB device via Microchip Multihost USB491x Hub. A new hub quirk HUB_QUIRK_REDUCE_FRAME_INTR_BINTERVAL speeds up the notification process for Microchip USB491x hub by limiting the maximum bInterval value to 9. Signed-off-by: Hardik Gajjar Reviewed-by: Alan Stern Link: https://lore.kernel.org/r/20231205181829.127353-2-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 36f4121e4908c03b390756e025c5ec834505a3ca Author: Hardik Gajjar Date: Tue Dec 5 19:18:28 2023 +0100 usb: hub: Replace hardcoded quirk value with BIT() macro [ Upstream commit 6666ea93d2c422ebeb8039d11e642552da682070 ] This patch replaces the hardcoded quirk value in the macro with BIT(). Signed-off-by: Hardik Gajjar Reviewed-by: Alan Stern Link: https://lore.kernel.org/r/20231205181829.127353-1-hgajjar@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 25ae41fc398a870562cf08e594eca055cc82ba97 Author: Yaxiong Tian Date: Fri Nov 24 09:49:13 2023 +0800 extcon: fix possible name leak in extcon_dev_register() [ Upstream commit e66523c72c9aae0ff0dae6859eb77b04de1e8e5f ] In the error path after calling dev_set_name(), the device name is leaked. To fix this, moving dev_set_name() after the error path and before device_register. Link: https://lore.kernel.org/lkml/TYZPR01MB4784ADCD3E951E0863F3DB72D5B8A@TYZPR01MB4784.apcprd01.prod.exchangelabs.com/ Signed-off-by: Yaxiong Tian Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit ad3710d297a51050988615f90e76de13eaf2d1d2 Author: James Clark Date: Fri Sep 1 14:37:15 2023 +0100 perf cs-etm: Bump minimum OpenCSD version to ensure a bugfix is present [ Upstream commit 2dbba30fd69b604802a9535b74bddb5bcca23793 ] Since commit d927ef5004ef ("perf cs-etm: Add exception level consistency check"), the exception that was added to Perf will be triggered unless the following bugfix from OpenCSD is present: - _Version 1.2.1_: - __Bugfix__: ETM4x / ETE - output of context elements to client can in some circumstances be delayed until after subsequent atoms have been processed leading to incorrect memory decode access via the client callbacks. Fixed to flush context elements immediately they are committed. Rather than remove the assert and silently fail, just increase the minimum version requirement to avoid hard to debug issues and regressions. Reviewed-by: Ian Rogers Signed-off-by: James Clark Tested-by: Leo Yan Cc: John Garry Cc: Mike Leach Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Link: https://lore.kernel.org/r/20230901133716.677499-1-james.clark@arm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e129c7fa7070fbce57feb0bfc5eaa65eef44b693 Author: Daniel Stodden Date: Tue Nov 21 20:23:16 2023 -0800 PCI: switchtec: Fix stdev_release() crash after surprise hot remove [ Upstream commit df25461119d987b8c81d232cfe4411e91dcabe66 ] A PCI device hot removal may occur while stdev->cdev is held open. The call to stdev_release() then happens during close or exit, at a point way past switchtec_pci_remove(). Otherwise the last ref would vanish with the trailing put_device(), just before return. At that later point in time, the devm cleanup has already removed the stdev->mmio_mrpc mapping. Also, the stdev->pdev reference was not a counted one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause a fatal page fault, and the subsequent dma_free_coherent(), if reached, would pass a stale &stdev->pdev->dev pointer. Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after stdev_kill(). Counting the stdev->pdev ref is now optional, but may prevent future accidents. Reproducible via the script at https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com Link: https://lore.kernel.org/r/20231122042316.91208-2-dns@arista.com Signed-off-by: Daniel Stodden Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Reviewed-by: Dmitry Safonov Signed-off-by: Sasha Levin commit ce115227422a915c70db1ae04144690d5fe755fd Author: Guilherme G. Piccoli Date: Mon Nov 20 13:04:36 2023 -0300 PCI: Only override AMD USB controller if required [ Upstream commit e585a37e5061f6d5060517aed1ca4ccb2e56a34c ] By running a Van Gogh device (Steam Deck), the following message was noticed in the kernel log: pci 0000:04:00.3: PCI class overridden (0x0c03fe -> 0x0c03fe) so dwc3 driver can claim this instead of xhci Effectively this means the quirk executed but changed nothing, since the class of this device was already the proper one (likely adjusted by newer firmware versions). Check and perform the override only if necessary. Link: https://lore.kernel.org/r/20231120160531.361552-1-gpiccoli@igalia.com Signed-off-by: Guilherme G. Piccoli Signed-off-by: Bjorn Helgaas Cc: Huang Rui Cc: Vicki Pfau Signed-off-by: Sasha Levin commit 1e6d636c5d8fea807954fe310fa3f427358a6ca8 Author: Xiaowu.ding Date: Tue Dec 12 19:37:22 2023 +0800 mailbox: arm_mhuv2: Fix a bug for mhuv2_sender_interrupt [ Upstream commit ee01c0b4384d19ecc5dfa7db3fd4303f965c3eba ] Message Handling Unit version is v2.1. When arm_mhuv2 working with the data protocol transfer mode. We have split one mhu into two channels, and every channel include four channel windows, the two channels share one gic spi interrupt. There is a problem with the sending scenario. The first channel will take up 0-3 channel windows, and the second channel take up 4-7 channel windows. When the first channel send the data, and the receiver will clear all the four channels status. Although we only enabled the interrupt on the last channel window with register CH_INT_EN,the register CHCOMB_INT_ST0 will be 0xf, not be 0x8. Currently we just clear the last channel windows int status with the data proctol mode.So after that,the CHCOMB_INT_ST0 status will be 0x7, not be the 0x0. Then the second channel send the data, the receiver read the data, clear all the four channel windows status, trigger the sender interrupt. But currently the CHCOMB_INT_ST0 register will be 0xf7, get_irq_chan_comb function will always return the first channel. So this patch clear all channel windows int status to avoid this interrupt confusion. Signed-off-by: Xiaowu.ding Acked-by: Viresh Kumar Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit bf1214df42def9e55906abafa47589825b7696ef Author: Peter Robinson Date: Wed Dec 20 15:56:39 2023 +0000 mfd: ti_am335x_tscadc: Fix TI SoC dependencies [ Upstream commit 284d16c456e5d4b143f375b8ccc4038ab3f4ee0f ] The ti_am335x_tscadc is specific to some TI SoCs, update the dependencies for those SoCs and compile testing. Signed-off-by: Peter Robinson Link: https://lore.kernel.org/r/20231220155643.445849-1-pbrobinson@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit bd50a7b5c13e84c5db3b030b7cb71106c1582308 Author: Oleksandr Tyshchenko Date: Sun Jan 7 12:34:26 2024 +0200 xen/gntdev: Fix the abuse of underlying struct page in DMA-buf import [ Upstream commit 2d2db7d40254d5fb53b11ebd703cd1ed0c5de7a1 ] DO NOT access the underlying struct page of an sg table exported by DMA-buf in dmabuf_imp_to_refs(), this is not allowed. Please see drivers/dma-buf/dma-buf.c:mangle_sg_table() for details. Fortunately, here (for special Xen device) we can avoid using pages and calculate gfns directly from dma addresses provided by the sg table. Suggested-by: Daniel Vetter Signed-off-by: Oleksandr Tyshchenko Acked-by: Christian König Reviewed-by: Stefano Stabellini Acked-by: Daniel Vetter Link: https://lore.kernel.org/r/20240107103426.2038075-1-olekstysh@gmail.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 7d174793ca1eab16f65b117d4436fd5e0455fc11 Author: Frederik Haxel Date: Tue Dec 12 14:01:12 2023 +0100 riscv: Make XIP bootable again [ Upstream commit 66f1e68093979816a23412a3fad066f5bcbc0360 ] Currently, the XIP kernel seems to fail to boot due to missing XIP_FIXUP and a wrong page_offset value. A superfluous XIP_FIXUP has also been removed. Signed-off-by: Frederik Haxel Link: https://lore.kernel.org/r/20231212130116.848530-2-haxel@fzi.de Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 499197b5ec5c591a11a4938f30d199a0311e2c30 Author: Michael Maltsev Date: Sun Jan 7 13:53:07 2024 +0500 ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CGA [ Upstream commit e315e8692f7922cd1b2a26bd7a1741cc8ce77085 ] Like the ASUS ExpertBook B1502CBA and various ASUS laptops, the ASUS ExpertBook B1502CGA has an ACPI DSDT table that describes IRQ 1 as ActiveLow while the kernel overrides it to Edge_High. $ sudo dmesg | grep DMI [ 0.000000] DMI: ASUSTeK COMPUTER INC. ASUS EXPERTBOOK B1502CGA_B1502CGA/B1502CGA, BIOS B1502CGA.303 06/05/2023 $ grep -A 40 PS2K dsdt.dsl | grep IRQ -A 1 IRQ (Level, ActiveLow, Exclusive, ) {1} This prevents the keyboard from working. To fix this issue, add this laptop to the skip_override_table so that the kernel does not override IRQ 1. Signed-off-by: Michael Maltsev [ rjw: rebase, replace .ident field with a comment ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8e7b6adcb89016321575ab498e9e39e62dd4eb41 Author: Ben Mayo Date: Sat Jan 6 21:13:23 2024 -0500 ACPI: resource: Add DMI quirks for ASUS Vivobook E1504GA and E1504GAB [ Upstream commit d2aaf19965045f70bb2ece514399cdc6fcce2e73 ] Asus Vivobook E1504GA and E1504GAB notebooks are affected by bug #216158 (DSDT specifies the kbd IRQ as level active-low and using the override changes this to rising edge, stopping the keyboard from working). Users of these notebooks do not have a working keyboard unless they add their DMI information to the struct irq1_level_low_skip_override array and compile a custom kernel. Add support for these computers to the Linux kernel without requiring the end-user to recompile the kernel. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216158 Signed-off-by: Ben Mayo [ rjw: Link tag, subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5b6831d90078a9f81cddaa95a184e29dd59fc820 Author: Harshit Shah Date: Sat Dec 30 14:41:23 2023 +0530 i3c: master: cdns: Update maximum prescaler value for i2c clock [ Upstream commit 374c13f9080a1b9835a5ed3e7bea93cf8e2dc262 ] As per the Cadence IP document fixed the I2C clock divider value limit from 16 bits instead of 10 bits. Without this change setting up the I2C clock to low frequencies will not work as the prescaler value might be greater than 10 bit number. I3C clock divider value is 10 bits only. Updating the macro names for both. Signed-off-by: Harshit Shah Link: https://lore.kernel.org/r/1703927483-28682-1-git-send-email-harshitshah.opendev@gmail.com Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit b427f55e9d4185f6f17cc1e3296eb8d0c4425283 Author: Johannes Berg Date: Wed Oct 25 22:45:05 2023 +0200 um: time-travel: fix time corruption [ Upstream commit abe4eaa8618bb36c2b33e9cdde0499296a23448c ] In 'basic' time-travel mode (without =inf-cpu or =ext), we still get timer interrupts. These can happen at arbitrary points in time, i.e. while in timer_read(), which pushes time forward just a little bit. Then, if we happen to get the interrupt after calculating the new time to push to, but before actually finishing that, the interrupt will set the time to a value that's incompatible with the forward, and we'll crash because time goes backwards when we do the forwarding. Fix this by reading the time_travel_time, calculating the adjustment, and doing the adjustment all with interrupts disabled. Reported-by: Vincent Whitchurch Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 96cec20795cf563a11ebf361f498c5e279603d32 Author: Nathan Chancellor Date: Wed Dec 6 09:49:46 2023 -0700 um: net: Fix return type of uml_net_start_xmit() [ Upstream commit 7d748f60a4b82b50bf25fad1bd42d33f049f76aa ] With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG), indirect call targets are validated against the expected function pointer prototype to make sure the call target is valid to help mitigate ROP attacks. If they are not identical, there is a failure at run time, which manifests as either a kernel panic or thread getting killed. A warning in clang aims to catch these at compile time, which reveals: arch/um/drivers/net_kern.c:353:21: warning: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Wincompatible-function-pointer-types-strict] 353 | .ndo_start_xmit = uml_net_start_xmit, | ^~~~~~~~~~~~~~~~~~ 1 warning generated. ->ndo_start_xmit() in 'struct net_device_ops' expects a return type of 'netdev_tx_t', not 'int'. Adjust the return type of uml_net_start_xmit() to match the prototype's to resolve the warning. While UML does not currently implement support for kCFI, it could in the future, which means this warning becomes a fatal CFI failure at run time. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202310031340.v1vPh207-lkp@intel.com/ Acked-by: Anton Ivanov Signed-off-by: Nathan Chancellor Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit dcfd9ceb7338a53f988a39bcb67a3f831bcc7c78 Author: Benjamin Berg Date: Fri Nov 10 12:03:41 2023 +0100 um: Don't use vfprintf() for os_info() [ Upstream commit 236f9fe39b02c15fa5530b53e9cca48354394389 ] The threads allocated inside the kernel have only a single page of stack. Unfortunately, the vfprintf function in standard glibc may use too much stack-space, overflowing it. To make os_info safe to be used by helper threads, use the kernel vscnprintf function into a smallish buffer and write out the information to stderr. Signed-off-by: Benjamin Berg Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 9d44712788ef4814487ab8574f2422a6f2108ec5 Author: Anton Ivanov Date: Thu Sep 21 15:34:44 2023 +0100 um: Fix naming clash between UML and scheduler [ Upstream commit 541d4e4d435c8b9bfd29f70a1da4a2db97794e0a ] __cant_sleep was already used and exported by the scheduler. The name had to be changed to a UML specific one. Signed-off-by: Anton Ivanov Reviewed-by: Peter Lafreniere Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit a42a9307aef242a7e916facd29e8884f97aff336 Author: Heiner Kallweit Date: Sat Dec 16 21:05:33 2023 +0100 leds: trigger: panic: Don't register panic notifier if creating the trigger failed [ Upstream commit afacb21834bb02785ddb0c3ec197208803b74faa ] It doesn't make sense to register the panic notifier if creating the panic trigger failed. Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/8a61e229-5388-46c7-919a-4d18cc7362b2@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit b84c91d34b4454a329951d14a6ed45b453591216 Author: Andy Shevchenko Date: Wed Nov 22 19:50:36 2023 +0200 pinctrl: baytrail: Fix types of config value in byt_pin_config_set() [ Upstream commit 1a856a22e6036c5f0d6da7568b4550270f989038 ] When unpacked, the config value is split to two of different types. Fix the types accordingly. Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 4a28302b2c681e3cf85e3b41231fff363c4c6a0e Author: bo liu Date: Mon Jan 8 19:02:35 2024 +0800 ALSA: hda/conexant: Fix headset auto detect fail in cx8070 and SN6140 [ Upstream commit 7aeb259086487417f0fecf66e325bee133e8813a ] When OMTP headset plugin the headset jack of CX8070 and SN6160 sound cards, the headset type detection circuit will recognize the headset type as CTIA. At this point, plugout and plugin the headset will get the correct headset type as OMTP. The reason for the failure of headset type recognition is that the sound card creation will enable the VREF voltage of the headset mic, which interferes with the headset type automatic detection circuit. Plugout and plugin the headset will restart the headset detection and get the correct headset type. The patch is disable the VREF voltage when the headset is not present, and will enable the VREF voltage when the headset is present. Signed-off-by: bo liu Link: https://lore.kernel.org/r/20240108110235.3867-1-bo.liu@senarytech.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 180357b6d2756a137281dea219fb490cb621eb04 Author: Alex Deucher Date: Wed Jan 3 11:55:53 2024 -0500 drm/amdgpu: apply the RV2 system aperture fix to RN/CZN as well [ Upstream commit 16783d8ef08448815e149e40c82fc1e1fc41ddbf ] These chips needs the same fix. This was previously not seen on then since the AGP aperture expanded the system aperture, but this showed up again when AGP was disabled. Reviewed-and-tested-by: Jiadong Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0b2672804eba6234599a89b2295d356eed7c26f8 Author: Srinivasan Shanmugam Date: Fri Dec 29 15:07:09 2023 +0530 drm/amdkfd: Fix iterator used outside loop in 'kfd_add_peer_prop()' [ Upstream commit b1a428b45dc7e47c7acc2ad0d08d8a6dda910c4c ] Fix the following about iterator use: drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_topology.c:1456 kfd_add_peer_prop() warn: iterator used outside loop: 'iolink3' Cc: Felix Kuehling Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a26a9b16c469c018f2bf8cc422a92091aec38a46 Author: Srinivasan Shanmugam Date: Wed Dec 27 12:54:44 2023 +0530 drm/amdgpu: Drop 'fence' check in 'to_amdgpu_amdkfd_fence()' [ Upstream commit bf2ad4fb8adca89374b54b225d494e0b1956dbea ] Return value of container_of(...) can't be null, so null check is not required for 'fence'. Hence drop its NULL check. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c:93 to_amdgpu_amdkfd_fence() warn: can 'fence' even be NULL? Cc: Felix Kuehling Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ed145ab7381eff99c263089d876867daeb3b8112 Author: Srinivasan Shanmugam Date: Wed Jan 3 22:22:44 2024 +0530 drm/amdgpu: Fix '*fw' from request_firmware() not released in 'amdgpu_ucode_request()' [ Upstream commit 13a1851f923d9a7a78a477497295c2dfd16ad4a4 ] Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c:1404 amdgpu_ucode_request() warn: '*fw' from request_firmware() not released on lines: 1404. Cc: Mario Limonciello Cc: Lijo Lazar Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7b5d58c07024516c0e81b95e98f37710cf402c53 Author: Srinivasan Shanmugam Date: Wed Jan 3 22:05:16 2024 +0530 drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()' [ Upstream commit 4f32504a2f85a7b40fe149436881381f48e9c0c0 ] Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368) 357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, enum amdgpu_mca_error_type type, 358 int idx, struct mca_bank_entry *entry) 359 { 360 const struct amdgpu_mca_smu_funcs *mca_funcs = adev->mca.mca_funcs; 361 int count; 362 363 switch (type) { 364 case AMDGPU_MCA_ERROR_TYPE_UE: 365 count = mca_funcs->max_ue_count; mca_funcs is dereferenced here. 366 break; 367 case AMDGPU_MCA_ERROR_TYPE_CE: 368 count = mca_funcs->max_ce_count; mca_funcs is dereferenced here. 369 break; 370 default: 371 return -EINVAL; 372 } 373 374 if (idx >= count) 375 return -EINVAL; 376 377 if (mca_funcs && mca_funcs->mca_get_mca_entry) ^^^^^^^^^ Checked too late! Cc: Yang Wang Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Yang Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 195a6289282e039024ad30ba66e6f94a4d0fbe49 Author: Srinivasan Shanmugam Date: Tue Dec 26 15:32:19 2023 +0530 drm/amdgpu: Fix possible NULL dereference in amdgpu_ras_query_error_status_helper() [ Upstream commit b8d55a90fd55b767c25687747e2b24abd1ef8680 ] Return invalid error code -EINVAL for invalid block id. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1183 amdgpu_ras_query_error_status_helper() error: we previously assumed 'info' could be null (see line 1176) Suggested-by: Hawking Zhang Cc: Tao Zhou Cc: Hawking Zhang Cc: Christian König Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8a89fc4f75c0c0b49321d12558b8a846d6419408 Author: Ivan Lipski Date: Mon Oct 2 13:47:54 2023 -0400 Re-revert "drm/amd/display: Enable Replay for static screen use cases" [ Upstream commit d6398866a6b47e92319ef6efdb0126a4fbb7796a ] This reverts commit 44e60b14d5a72f91fd0bdeae8da59ae37a3ca8e5. Since, it causes a regression in which eDP displays with PSR support, but no Replay support (Sink support <= 0x03), fail to enable PSR and consequently all IGT amd_psr tests fail. So, revert this until a more suitable fix can be found. This got brought back accidently with the backmerge. Acked-by: Leo Li Signed-off-by: Ivan Lipski Signed-off-by: Hamza Mahfooz Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 03d5ec901a2377920990e4bf157b82564e7f78a6 Author: Felix Kuehling Date: Mon Dec 18 16:17:23 2023 -0500 drm/amdgpu: Let KFD sync with VM fences [ Upstream commit ec9ba4821fa52b5efdbc4cdf0a77497990655231 ] Change the rules for amdgpu_sync_resv to let KFD synchronize with VM fences on page table reservations. This fixes intermittent memory corruption after evictions when using amdgpu_vm_handle_moved to update page tables for VM mappings managed through render nodes. Signed-off-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0ebb69e30d20957e1a151301799f620a4f80261e Author: Meenakshikumar Somasundaram Date: Mon Dec 4 10:57:45 2023 -0500 drm/amd/display: Fix minor issues in BW Allocation Phase2 [ Upstream commit aa5dc05340eb97486a631ce6bccb8d020bf6b56b ] [Why] Fix minor issues in BW Allocation Phase2. [How] - In set_usb4_req_bw_req(), link->dpia_bw_alloc_config.response_ready flag should be reset before writing DPCD REQUEST_BW. - Fix the granularity for value of 2 in get_bw_granularity(). - Removed bandwidth allocation support display fw boot option as the fw would read feature enable status from bios. - Clean up DPIA_EST_BW_CHANGED and DPIA_BW_REQ_SUCCESS cases in dpia_handle_bw_alloc_response(). - Removed allocate_usb4_bw and deallocate_usb4_bw. - Optimized loop in get_lowest_dpia_index(). - Updated link_dp_dpia_allocate_usb4_bandwidth_for_stream() and set_usb4_req_bw_req() to always issue request bw. Tested-by: Daniel Wheeler Reviewed-by: PeiChen Huang Acked-by: Rodrigo Siqueira Signed-off-by: Meenakshikumar Somasundaram Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c028919a4717909b610eb19f4911a76a32b49d8d Author: Stanley.Yang Date: Fri Dec 15 16:13:23 2023 +0800 drm/amdgpu: Fix ecc irq enable/disable unpaired [ Upstream commit a32c6f7f5737cc7e31cd7ad5133f0d96fca12ea6 ] The ecc_irq is disabled while GPU mode2 reset suspending process, but not be enabled during GPU mode2 reset resume process. Changed from V1: only do sdma/gfx ras_late_init in aldebaran_mode2_restore_ip delete amdgpu_ras_late_resume function Changed from V2: check umc ras supported before put ecc_irq Signed-off-by: Stanley.Yang Reviewed-by: Tao Zhou Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8c959a1e82f5d55322d7c70fc8ee49101afff7f2 Author: Alexander Stein Date: Mon Dec 18 13:24:07 2023 +0100 clk: imx: clk-imx8qxp: fix LVDS bypass, pixel and phy clocks [ Upstream commit 3f5f63adeea7e7aa715e101ffe4b4ac9705f9664 ] To be compatible with SCU firmware based on 1.15 a different clock routing for LVDS is needed. Signed-off-by: Oliver F. Brown Signed-off-by: Ranjani Vaidyanathan Signed-off-by: Alexander Stein Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20231218122407.2757175-1-alexander.stein@ew.tq-group.com/ Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 37bc012fcbdfd26dd4007a81a5012d7f30352974 Author: Kuan-Wei Chiu Date: Mon Dec 11 01:19:07 2023 +0800 clk: imx: scu: Fix memory leak in __imx_clk_gpr_scu() [ Upstream commit 21c0efbcb45cf94724d17b040ebc03fcd4a81f22 ] In cases where imx_clk_is_resource_owned() returns false, the code path does not handle the failure gracefully, potentially leading to a memory leak. This fix ensures proper cleanup by freeing the allocated memory for 'clk_node' before returning. Signed-off-by: Kuan-Wei Chiu Reviewed-by: Peng Fan Link: https://lore.kernel.org/all/20231210171907.3410922-1-visitorckw@gmail.com/ Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 2c046cb3339c2b5b2c0dbd8c6f5cf0a692299fcc Author: Alvin Lee Date: Fri Dec 8 11:56:56 2023 -0500 drm/amd/display: Only clear symclk otg flag for HDMI [ Upstream commit dff45f03f508c92cd8eb2050e27b726726b8ae0b ] [Description] There is a corner case where the symclk otg flag is cleared when disabling the phantom pipe for subvp (because the phantom and main pipe share the same link). This is undesired because we need the maintain the correct symclk otg flag state for the main pipe. For now only clear the flag only for HDMI signal type, since it's only set for HDMI signal type (phantom is virtual). The ideal solution is to not clear it if the stream is phantom but currently there's a bug that doesn't allow us to do this. Once this issue is fixed the proper fix can be implemented. Reviewed-by: Samson Tam Acked-by: Wayne Lin Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ae5c2289b2b98fc8479c5b7c19e82c7ca34eb290 Author: Michael Strauss Date: Thu Nov 30 10:44:36 2023 -0500 drm/amd/display: Fix lightup regression with DP2 single display configs [ Upstream commit 5a82b8d6c05f9b30828ede1b103b9ee5cb5c912e ] [WHY] Previous fix for multiple displays downstream of DP2 MST hub caused regression [HOW] Match sink IDs instead of sink struct addresses Reviewed-by: Nicholas Kazlauskas Reviewed-by: Charlene Liu Acked-by: Wayne Lin Signed-off-by: Michael Strauss Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c5fd93a4bbfec6f9ff3e36ed87b6179ee404d2f5 Author: Allen Pan Date: Thu Dec 7 17:26:10 2023 -0500 drm/amd/display: fix usb-c connector_type [ Upstream commit 0d26644bc57d8737c8e2fb3145366f7d0b941935 ] [why] BIOS switches to use USB-C connector type 0x18, but VBIOS's objectInfo table not supported yet. driver needs to patch it based on enc_cap from system integration info table. Reviewed-by: Charlene Liu Acked-by: Wayne Lin Signed-off-by: Allen Pan Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b80ca22d47f600c3121b5e9f2c1202fdc075dc88 Author: Josip Pavic Date: Tue Dec 5 12:01:05 2023 -0500 drm/amd/display: make flip_timestamp_in_us a 64-bit variable [ Upstream commit 6fb12518ca58412dc51054e2a7400afb41328d85 ] [Why] This variable currently overflows after about 71 minutes. This doesn't cause any known functional issues but it does make debugging more difficult. [How] Make it a 64-bit variable. Reviewed-by: Aric Cyr Acked-by: Wayne Lin Signed-off-by: Josip Pavic Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a27dcc218c33d4a5a6b020ae6a85706e976f0e54 Author: Dafna Hirschfeld Date: Tue Oct 31 13:51:10 2023 +0200 accel/habanalabs/gaudi2: fix undef opcode reporting [ Upstream commit 0ec346779644039c4c05cfa7f071b1a24e54d8d9 ] currently the undefined opcode event bit in set only for lower cp and only if 'write_enable' is true. It should be set anyway and for all streams in order to report that event to userspace. Signed-off-by: Dafna Hirschfeld Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit d312312f3e918c89617a1cafec14d9415e9e15eb Author: Farah Kassabri Date: Tue Oct 31 12:20:36 2023 +0200 accel/habanalabs: fix EQ heartbeat mechanism [ Upstream commit d1958dce5ab6a3e089c60cf474e8c9b7e96e70ad ] Stop rescheduling another heartbeat check when EQ heartbeat check fails as it generates confusing logs in dmesg that the heartbeat fails. Signed-off-by: Farah Kassabri Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 014bc0f4a5255b2562305d2d08aee17e81b5ceeb Author: Oded Gabbay Date: Mon Oct 30 12:23:57 2023 +0200 accel/habanalabs: add support for Gaudi2C device [ Upstream commit 42422993cf28d456778ee9168d73758ec037cd51 ] Gaudi2 with PCI revision ID with the value of '3' represents Gaudi2C device and should be detected and initialized as Gaudi2. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit bd77f5e86d5239091af0ab45b32f7c597cc21a1e Author: Werner Fischer Date: Wed Dec 13 10:45:25 2023 +0100 watchdog: it87_wdt: Keep WDTCTRL bit 3 unmodified for IT8784/IT8786 [ Upstream commit d12971849d71781c1e4ffd1117d4878ce233d319 ] WDTCTRL bit 3 sets the mode choice for the clock input of IT8784/IT8786. Some motherboards require this bit to be set to 1 (= PCICLK mode), otherwise the watchdog functionality gets broken. The BIOS of those motherboards sets WDTCTRL bit 3 already to 1. Instead of setting all bits of WDTCTRL to 0 by writing 0x00 to it, keep bit 3 of it unchanged for IT8784/IT8786 chips. In this way, bit 3 keeps the status as set by the BIOS of the motherboard. Watchdog tests have been successful with this patch with the following systems: IT8784: Thomas-Krenn LES plus v2 (YANLING YL-KBRL2 V2) IT8786: Thomas-Krenn LES plus v3 (YANLING YL-CLU L2) IT8786: Thomas-Krenn LES network 6L v2 (YANLING YL-CLU6L) Link: https://lore.kernel.org/all/140b264d-341f-465b-8715-dacfe84b3f71@roeck-us.net/ Signed-off-by: Werner Fischer Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20231213094525.11849-4-devlists@wefi.net Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit c6235cd5162d529620412a80be7df4a2edd818df Author: Ben Dooks Date: Wed Nov 22 08:51:18 2023 +0000 watchdog: starfive: add lock annotations to fix context imbalances [ Upstream commit f77999887235f8c378af343df11a6bcedda5b284 ] Add the necessary __acquires() and __releases() to the functions that take and release the wdt lock to avoid the following sparse warnings: drivers/watchdog/starfive-wdt.c:204:13: warning: context imbalance in 'starfive_wdt_unlock' - wrong count at exit drivers/watchdog/starfive-wdt.c:212:9: warning: context imbalance in 'starfive_wdt_lock' - unexpected unlock Signed-off-by: Ben Dooks Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20231122085118.177589-1-ben.dooks@codethink.co.uk Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit bc53dc88f7072dc42ddbeaa23961f77e5b58505d Author: Kuan-Wei Chiu Date: Mon Dec 11 01:52:32 2023 +0800 clk: mmp: pxa168: Fix memory leak in pxa168_clk_init() [ Upstream commit 2fbabea626b6467eb4e6c4cb7a16523da12e43b4 ] In cases where mapping of mpmu/apmu/apbc registers fails, the code path does not handle the failure gracefully, potentially leading to a memory leak. This fix ensures proper cleanup by freeing the allocated memory for 'pxa_unit' before returning. Signed-off-by: Kuan-Wei Chiu Link: https://lore.kernel.org/r/20231210175232.3414584-1-visitorckw@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2fece04533d249a8e6611e704beeda725b9710b2 Author: Kuan-Wei Chiu Date: Mon Dec 11 00:50:40 2023 +0800 clk: hi3620: Fix memory leak in hi3620_mmc_clk_init() [ Upstream commit bfbea9e5667cfa9552c3d88f023386f017f6c308 ] In cases where kcalloc() fails for the 'clk_data->clks' allocation, the code path does not handle the failure gracefully, potentially leading to a memory leak. This fix ensures proper cleanup by freeing the allocated memory for 'clk_data' before returning. Signed-off-by: Kuan-Wei Chiu Link: https://lore.kernel.org/r/20231210165040.3407545-1-visitorckw@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1cd2b612474c07b17a21e27f2eed8dff75cb5057 Author: Wang, Beyond Date: Tue Dec 12 21:03:04 2023 +0800 drm/amdgpu: fix ftrace event amdgpu_bo_move always move on same heap [ Upstream commit 94aeb4117343d072e3a35b9595bcbfc0058ee724 ] Issue: during evict or validate happened on amdgpu_bo, the 'from' and 'to' is always same in ftrace event of amdgpu_bo_move where calling the 'trace_amdgpu_bo_move', the comment says move_notify is called before move happens, but actually it is called after move happens, here the new_mem is same as bo->resource Fix: move trace_amdgpu_bo_move from move_notify to amdgpu_bo_move Signed-off-by: Wang, Beyond Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 14f109bf74dd67e1d0469fed859c8e506b0df53f Author: Paloma Arellano Date: Tue Dec 12 15:10:58 2023 -0800 drm/msm/dpu: Add mutex lock in control vblank irq [ Upstream commit 45284ff733e4caf6c118aae5131eb7e7cf3eea5a ] Add a mutex lock to control vblank irq to synchronize vblank enable/disable operations happening from different threads to prevent race conditions while registering/unregistering the vblank irq callback. v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a parameter of dpu_encoder_phys. -Switch from atomic refcnt to a simple int counter as mutex has now been added v3: Mistakenly did not change wording in last version. It is done now. v2: Slightly changed wording of commit message Signed-off-by: Paloma Arellano Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/571854/ Link: https://lore.kernel.org/r/20231212231101.9240-2-quic_parellan@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit c9348e01c308e333ddbb49c4944427d2fa697cc8 Author: Abhinav Kumar Date: Tue Dec 12 12:52:41 2023 -0800 drm/msm/dpu: fix writeback programming for YUV cases [ Upstream commit 79caf2f2202b9eaad3a5a726e4b33807f67d0f1b ] For YUV cases, setting the required format bits was missed out in the register programming. Lets fix it now in preparation of adding YUV formats support for writeback. changes in v2: - dropped the fixes tag as its not a fix but adding new functionality Signed-off-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/571814/ Link: https://lore.kernel.org/r/20231212205254.12422-4-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit cc74988a5b07d251e3a59c35bd4a1e380249cd61 Author: Rob Clark Date: Mon Dec 11 10:19:55 2023 -0800 drm/msm/dpu: Ratelimit framedone timeout msgs [ Upstream commit 2b72e50c62de60ad2d6bcd86aa38d4ccbdd633f2 ] When we start getting these, we get a *lot*. So ratelimit it to not flood dmesg. Signed-off-by: Rob Clark Reviewed-by: Abhinav Kumar Reviewed-by: Marijn Suijten Patchwork: https://patchwork.freedesktop.org/patch/571584/ Link: https://lore.kernel.org/r/20231211182000.218088-1-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit 9275c0d534cc3315c25c68a8381d18ba5c7515a2 Author: Dmitry Baryshkov Date: Sun Dec 3 03:27:43 2023 +0300 drm/msm/dpu: enable writeback on SM8450 [ Upstream commit eaa647cdbf2e357b4a14903f2f1e47ed9c4f8df3 ] Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/570187/ Link: https://lore.kernel.org/r/20231203002743.1291956-4-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 3139efb47d85d4329ee174eb4c6cb96e2f76abd5 Author: Dmitry Baryshkov Date: Sun Dec 3 03:27:42 2023 +0300 drm/msm/dpu: enable writeback on SM8350 [ Upstream commit c2949a49dfe960e952400029e14751dceff79d38 ] Enable WB2 hardware block, enabling writeback support on this platform. Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/570188/ Link: https://lore.kernel.org/r/20231203002743.1291956-3-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 83271b65f701356f0e34dde6e994744ff0ec5347 Author: Jonathan Kim Date: Tue Dec 5 12:22:07 2023 -0500 drm/amdkfd: fix mes set shader debugger process management [ Upstream commit bd33bb1409b494558a2935f7bbc7842def957fcd ] MES provides the driver a call to explicitly flush stale process memory within the MES to avoid a race condition that results in a fatal memory violation. When SET_SHADER_DEBUGGER is called, the driver passes a memory address that represents a process context address MES uses to keep track of future per-process calls. Normally, MES will purge its process context list when the last queue has been removed. The driver, however, can call SET_SHADER_DEBUGGER regardless of whether a queue has been added or not. If SET_SHADER_DEBUGGER has been called with no queues as the last call prior to process termination, the passed process context address will still reside within MES. On a new process call to SET_SHADER_DEBUGGER, the driver may end up passing an identical process context address value (based on per-process gpu memory address) to MES but is now pointing to a new allocated buffer object during KFD process creation. Since the MES is unaware of this, access of the passed address points to the stale object within MES and triggers a fatal memory violation. The solution is for KFD to explicitly flush the process context address from MES on process termination. Note that the flush call and the MES debugger calls use the same MES interface but are separated as KFD calls to avoid conflicting with each other. Signed-off-by: Jonathan Kim Tested-by: Alice Wong Reviewed-by: Eric Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fb93e7f26fb80143bcf96e731275a4dec0fb11e3 Author: Alvin Lee Date: Wed Dec 6 14:52:32 2023 -0500 drm/amd/display: Force p-state disallow if leaving no plane config [ Upstream commit 9a902a9073c287353e25913c0761bfed49d75a88 ] [Description] - When we're in a no plane config, DCN is always asserting P-State allow - This creates a scenario where the P-State blackout can start just as VUPDATE takes place and transitions the DCN config to a one where one or more HUBP's are active which can result in underflow - To fix this issue, force p-state disallow and unforce after the transition from no planes case -> one or more planes active Reviewed-by: Samson Tam Acked-by: Aurabindo Pillai Signed-off-by: Alvin Lee Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 44d12324d342ac0e28df81a027a79d50f7cc95e0 Author: Alvin Lee Date: Wed Dec 6 14:52:31 2023 -0500 drm/amd/display: For prefetch mode > 0, extend prefetch if possible [ Upstream commit dd4e4bb28843393065eed279e869fac248d03f0f ] [Description] For mode programming we want to extend the prefetch as much as possible (up to oto, or as long as we can for equ) if we're not already applying the 60us prefetch requirement. This is to avoid intermittent underflow issues during prefetch. The prefetch extension is applied under the following scenarios: 1. We're in prefetch mode 1 (i.e. we don't support MCLK switch in blank) 2. We're using subvp or drr methods of p-state switch, in which case we we don't care if prefetch takes up more of the blanking time Mode programming typically chooses the smallest prefetch time possible (i.e. highest bandwidth during prefetch) presumably to create margin between p-states / c-states that happen in vblank and prefetch. Therefore we only apply this prefetch extension when p-state in vblank is not required (UCLK p-states take up the most vblank time). Reviewed-by: Jun Lei Acked-by: Aurabindo Pillai Signed-off-by: Alvin Lee Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fadb7d053de5d48d081fd5d5203ecad31fab53e2 Author: Kieran Bingham Date: Mon Dec 11 18:29:48 2023 +0530 media: i2c: imx335: Fix hblank min/max values [ Upstream commit d7b95ad7a8d56248dfc34f861e445fad7a4004f4 ] The V4L2_CID_HBLANK control is marked as readonly and can only be a single value. Set the minimum and maximum value to match the mode value. Reviewed-by: Umang Jain Signed-off-by: Kieran Bingham Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit c5883a8a3676b94fe7cefde97c8eec50bb879eb2 Author: Hans de Goede Date: Mon Dec 4 13:39:42 2023 +0100 media: ov2740: Fix hts value [ Upstream commit 3735228bbe3511f844e03dfcc4003fadb59dde23 ] HTS must be more then width, so the 1080 value clearly is wrong, this is then corrected with some weird math dividing clocks in to_pixels_per_line() which results in the hts getting multiplied by 2, resulting in 2160. Instead just directly set hts to the correct value of 2160 and drop to_pixels_per_line(). Signed-off-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 39a2ed12a6c9f9e8ea2c39c743e760d96e4e9b8c Author: Su Hui Date: Fri Oct 20 17:17:23 2023 +0800 media: ddbridge: fix an error code problem in ddb_probe [ Upstream commit 09b4195021be69af1e1936cca995712a6d0f2562 ] Error code is assigned to 'stat', return 'stat' rather than '-1'. Signed-off-by: Su Hui Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 2398e29ad47294a5ccca5dab0f82ddfeed4d7a72 Author: Ming Qian Date: Fri Dec 8 15:33:42 2023 +0800 media: amphion: remove mutext lock in condition of wait_event [ Upstream commit f9c8ddce2fe3b767582f299d03fc8fb85943568c ] mutext_lock should not be called in condition of wait_event, otherwise, when CONFIG_DEBUG_ATOMIC_SLEEP is enabled, we may meet the following warning: do not call blocking ops when !TASK_RUNNING; state=2 WARNING: CPU: 5 PID: 741 at kernel/sched/core.c:9859 __might_sleep+0x80/0xa4 Hardware name: Freescale i.MX8QM MEK (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __might_sleep+0x80/0xa4 lr : __might_sleep+0x80/0xa4 sp : ffffffc0123738a0 x29: ffffffc0123738a0 x28: ffffffc009194c48 x27: ffffffc00bbc1050 x26: ffffff8814b282f0 x25: ffffff8814b280d0 x24: ffffff8814b28080 x23: 0000000000000001 x22: 0000000000000032 x21: ffffffc00bbc1000 x20: 000000000000011b x19: ffffffc009324670 x18: 00000000fffffffd x17: 30303c5b20746120 x16: 74657320323d6574 x15: 617473203b474e49 x14: 00058b5b8b9aa1f1 x13: ffffffc00903cda0 x12: 00000000d744fcc9 x11: 000000000000001c x10: 00000000000009a0 x9 : ffffffc0090201f4 x8 : ffffff8828245000 x7 : 0000000000000001 x6 : 0000000000000001 x5 : 00000000410fd080 x4 : 0000000000000002 x3 : ffffff8815aab4c8 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8828244600 Call trace: __might_sleep+0x80/0xa4 mutex_lock+0x2c/0x80 sync_session_response+0x110/0x310 vpu_session_send_cmd+0x18c/0x244 vpu_session_start+0x38/0x70 vdec_start_session+0x1b4/0x3e0 vpu_vb2_start_streaming+0xa0/0x1c4 vb2_start_streaming+0x74/0x160 vb2_core_qbuf+0x488/0x650 vb2_qbuf+0x9c/0x100 v4l2_m2m_qbuf+0x7c/0x224 v4l2_m2m_ioctl_qbuf+0x20/0x2c v4l_qbuf+0x50/0x6c __video_do_ioctl+0x174/0x3f0 video_usercopy+0x210/0x7cc video_ioctl2+0x20/0x30 v4l2_ioctl+0x48/0x6c we need to refine check_is_responsed() to remove the mutext_lock, each cmd has a monotonically increasing id, and cmds are executed sequentially, so we can check the id of the last reponsed cmd, then determine whether a command has been responded or not. Signed-off-by: Ming Qian CC: Xiaolei Wang Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 7c7bd4d561e9dc6f5b7df9e184974915f6701a89 Author: Daniel Vacek Date: Tue Dec 12 09:07:45 2023 +0100 IB/ipoib: Fix mcast list locking [ Upstream commit 4f973e211b3b1c6d36f7c6a19239d258856749f9 ] Releasing the `priv->lock` while iterating the `priv->multicast_list` in `ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to remove the items while in the middle of iteration. If the mcast is removed while the lock was dropped, the for loop spins forever resulting in a hard lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below) -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.) Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on the code review I think this fix should address such lockups. crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2" -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 Signed-off-by: Sasha Levin commit c53dd64daa697e58b885e2810c111b5a76809893 Author: Douglas Anderson Date: Thu Sep 21 12:26:52 2023 -0700 drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind time [ Upstream commit 16ac5b21b31b439f03cdf44c153c5f5af94fb3eb ] Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about this fix: - When adding drm_atomic_helper_shutdown() to the unbind path, I added it after drm_kms_helper_poll_fini() since that's when other drivers seemed to have it. - Technically with a previous patch, ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"), we don't actually need to check to see if our "drm" pointer is NULL before calling drm_atomic_helper_shutdown(). We'll leave the "if" test in, though, so that this patch can land without any dependencies. It could potentially be removed later. - This patch also makes sure to set the drvdata to NULL in the case of bind errors to make sure that shutdown can't access freed data. Suggested-by: Maxime Ripard Reviewed-by: Maxime Ripard Signed-off-by: Douglas Anderson Tested-by: Marek Szyprowski Reviewed-by: Marek Szyprowski Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit b8094c0f1aae329b1c60a275a780d6c2c9ff7aa3 Author: Chao Yu Date: Sun Dec 10 19:35:42 2023 +0800 f2fs: fix to tag gcing flag on page during block migration [ Upstream commit 4961acdd65c956e97c1a000c82d91a8c1cdbe44b ] It needs to add missing gcing flag on page during block migration, in order to garantee migrated data be persisted during checkpoint, otherwise out-of-order persistency between data and node may cause data corruption after SPOR. Similar issue was fixed by commit 2d1fe8a86bf5 ("f2fs: fix to tag gcing flag on page during file defragment"). Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 30ec53ab595a54f66e4ec09345c5c8698c6b3123 Author: James Seo Date: Wed Nov 22 21:49:19 2023 -0800 hwmon: (hp-wmi-sensors) Fix failure to load on EliteDesk 800 G6 [ Upstream commit c9ba592580947b81f33f514320aeef02ddc001fd ] The EliteDesk 800 G6 stores a raw WMI string within the ACPI object in its BIOS corresponding to one instance of HPBIOS_PlatformEvents.Name. This is evidently a valid way of representing a WMI data item as far as the Microsoft ACPI-WMI mapper is concerned, but is preventing the driver from loading. This seems quite rare, but add support for such strings. Treating this as a quirk pretty much means adding that support anyway. Also clean up an oversight in update_numeric_sensor_from_wobj() in which the result of hp_wmi_strdup() was being used without error checking. Reported-by: Lukasz Stelmach Closes: https://lore.kernel.org/linux-hwmon/7850a0bd-60e7-88f8-1d6c-0bb0e3234fdc@roeck-us.net/ Tested-by: Lukasz Stelmach Signed-off-by: James Seo Link: https://lore.kernel.org/r/20231123054918.157098-1-james@equiv.tech Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit fd9c8c60c7945a85c0ec7aabd92c5af1d67b1a1b Author: Xing Tong Wu Date: Tue Nov 21 16:16:04 2023 +0800 hwmon: (nct6775) Fix fan speed set failure in automatic mode [ Upstream commit 8b3800256abad20e91c2698607f9b28591407b19 ] Setting the fan speed is only valid in manual mode; it is not possible to set the fan's speed in automatic mode. Return error when attempting to set the fan speed in automatic mode. Signed-off-by: Xing Tong Wu Link: https://lore.kernel.org/r/20231121081604.2499-3-xingtong_wu@163.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 6b24d0d8d16850d59170b8848592956a7d9bdd9a Author: Laurent Pinchart Date: Sun Nov 26 03:09:48 2023 +0100 media: rkisp1: resizer: Stop manual allocation of v4l2_subdev_state [ Upstream commit efa28efd9cba015f8c3d88123527c3c3cfcd13d0 ] Supported media bus codes on the resizer sink pad are identical to the ISP source pad. The .enum_mbus_code() handler thus delegates the enumeration to the ISP's operation. This is problematic for two reasons: - Format enumeration on the ISP source pad is dependent on the format configured on the ISP sink pad for the same subdev state (TRY or ACTIVE), while format enumeration on the resizer sink pad should return all formats supported by the resizer subdev, regardless of the ISP configuration. - Delegating the operation involves creating a fake v4l2_subdev_state on the stack to pass to the ISP .enum_mbus_code() handler. This gets in the way of evolution of both the ISP enumeration handler and, more generally, the V4L2 subdev state infrastructure. Fix those two issues by implementing format enumeration manually for the resizer. Link: https://lore.kernel.org/r/20231126020948.2700-1-laurent.pinchart@ideasonboard.com Reviewed-by: Paul Elder Reviewed-by: Tomi Valkeinen Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7bb1a2822aa2c2de4e09bf7c56dd93bd532f1fa7 Author: Tomi Valkeinen Date: Thu Dec 7 08:57:48 2023 +0100 media: rkisp1: Fix IRQ disable race issue [ Upstream commit 870565f063a58576e8a4529f122cac4325c6b395 ] In rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks the interrupts and then apparently assumes that the interrupt handler won't be running, and proceeds in the stop procedure. This is not the case, as the interrupt handler can already be running, which would lead to the ISP being disabled while the interrupt handler handling a captured frame. This brings up two issues: 1) the ISP could be powered off while the interrupt handler is still running and accessing registers, leading to board lockup, and 2) the interrupt handler code and the code that disables the streaming might do things that conflict. It is not clear to me if 2) causes a real issue, but 1) can be seen with a suitable delay (or printk in my case) in the interrupt handler, leading to board lockup. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-4-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford #imx8mp-beacon Signed-off-by: Tomi Valkeinen Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b53352b73501a3cea827c56b9dd094221f399f30 Author: Tomi Valkeinen Date: Thu Dec 7 08:57:47 2023 +0100 media: rkisp1: Store IRQ lines [ Upstream commit 0753874617de883c6d4da903142f334f76a75d70 ] Store the IRQ lines used by the driver for easy access. These are needed in future patches which fix IRQ race issues. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-3-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford #imx8mp-beacon Signed-off-by: Tomi Valkeinen Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e970de041399ba3dc1a44c840eee44f45aa681d7 Author: Tomi Valkeinen Date: Thu Dec 7 08:57:46 2023 +0100 media: rkisp1: Fix IRQ handler return values [ Upstream commit 3eb7910e1b16a2c136be26a8380f21469225b2f6 ] The IRQ handler rkisp1_isr() calls sub-handlers, all of which returns an irqreturn_t value, but rkisp1_isr() ignores those values and always returns IRQ_HANDLED. Fix this by collecting the return values, and returning IRQ_HANDLED or IRQ_NONE as appropriate. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-2-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford #imx8mp-beacon Signed-off-by: Tomi Valkeinen Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c58cf93e879d0dd0021909e72e0ba6378aa87ab7 Author: Tomi Valkeinen Date: Thu Dec 7 08:57:45 2023 +0100 media: rkisp1: Drop IRQF_SHARED [ Upstream commit 85d2a31fe4d9be1555f621ead7a520d8791e0f74 ] In all known platforms the ISP has dedicated IRQ lines, but for some reason the driver uses IRQF_SHARED. Supporting IRQF_SHARED properly requires handling interrupts even when our device is disabled, and the driver does not handle this. To avoid adding such code, and to be sure the driver won't accidentally be used in a platform with shared interrupts, let's drop the IRQF_SHARED flag. Link: https://lore.kernel.org/r/20231207-rkisp-irq-fix-v3-1-358a2c871a3c@ideasonboard.com Tested-by: Adam Ford #imx8mp-beacon Signed-off-by: Tomi Valkeinen Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b8b7a0e09ac678a24cc29c76dba581b710c5692c Author: Ricardo Ribalda Date: Sat Oct 28 09:55:04 2023 +0200 media: uvcvideo: Fix power line control for SunplusIT camera [ Upstream commit 6180056b0e0c097dad5d1569dcd661eaf509ea43 ] The device does not implement the power line frequency control correctly. It is a UVC 1.5 device, but implements the control as a UVC 1.1 device. Add the corresponding control mapping override. Bus 003 Device 002: ID 2b7e:b752 SunplusIT Inc HD Camera Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.01 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x2b7e idProduct 0xb752 bcdDevice 0.04 iManufacturer 1 SunplusIT Inc iProduct 2 HD Camera iSerial 3 01.00.00 bNumConfigurations 1 Cc: Yunke Cao Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0b4ea7fff0f0e0ed17e90ae9b9575fd8360ae62b Author: Ricardo Ribalda Date: Tue Sep 5 17:29:52 2023 +0200 media: uvcvideo: Fix power line control for a Chicony camera [ Upstream commit dba3e701917a4cce92920f8ccb9fa4d4ee5ac07e ] The device does not implement the control properly. Fixes v4l2-compliance error: info: checking control 'Power Line Frequency' (0x00980918) fail: v4l2-test-controls.cpp(552): could not set valid menu item 3 Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 610c86fa6494e23f49cbdd55630d0ec047f7dc6f Author: Neil Armstrong Date: Thu Dec 7 17:37:18 2023 +0100 drm/msm/dp: Add DisplayPort controller for SM8650 [ Upstream commit 1b2d98bdd7b7c64265732f5f0dace4c52c9ba8a8 ] The Qualcomm SM8650 platform comes with a DisplayPort controller with a different base offset than the previous SM8550 SoC, add support for this in the DisplayPort driver. Signed-off-by: Neil Armstrong Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/571132/ Link: https://lore.kernel.org/r/20231207-topic-sm8650-upstream-dp-v1-2-b762c06965bb@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin commit e37a96941fdd53318413833294f4b1142ee86a8d Author: Pierre-Louis Bossart Date: Mon Dec 4 15:27:08 2023 -0600 ALSA: hda: intel-dspcfg: add filters for ARL-S and ARL [ Upstream commit 7a9d6bbe8a663c817080be55d9fecf19a4a8fd8f ] Same usual filters, SOF is required for DMIC and/or SoundWire support. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Acked-by: Mark Brown Link: https://lore.kernel.org/r/20231204212710.185976-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ffa3eea886c6fe1f69847549365f1380e953220d Author: Pierre-Louis Bossart Date: Mon Dec 4 15:27:07 2023 -0600 ALSA: hda: Intel: add HDA_ARL PCI ID support [ Upstream commit a31014ebad617868c246d3985ff80d891f03711e ] Yet another PCI ID. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Acked-by: Mark Brown Link: https://lore.kernel.org/r/20231204212710.185976-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 831513ab600633eea6d1c8d28cfb5978f4171d78 Author: Pierre-Louis Bossart Date: Mon Dec 4 15:27:06 2023 -0600 PCI: add INTEL_HDA_ARL to pci_ids.h [ Upstream commit 5ec42bf04d72fd6d0a6855810cc779e0ee31dfd7 ] The PCI ID insertion follows the increasing order in the table, but this hardware follows MTL (MeteorLake). Signed-off-by: Pierre-Louis Bossart Reviewed-by: Péter Ujfalusi Reviewed-by: Kai Vehmanen Acked-by: Mark Brown Link: https://lore.kernel.org/r/20231204212710.185976-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e6b4dfc22148534c318103dbb53d678ed1dd17b3 Author: Michael Tretter Date: Fri Oct 13 13:00:22 2023 +0200 media: rockchip: rga: fix swizzling for RGB formats [ Upstream commit 9e7dc39260edac180c206bb6149595a40eabae3e ] When using 32 bit RGB formats, the RGA on the rk3568 produces wrong colors as the wrong color channels are read or written. The reason is that the format description for the channel swizzeling is wrong and the wrong bits are configured. For example, when converting ARGB32 to NV12, the alpha channel is used as blue channel.. This doesn't happen if the color format is the same on both sides. Fix the color_swap settings of the formats to correctly handle 32 bit RGB formats. For RGA_COLOR_FMT_XBGR8888, the RGA_COLOR_ALPHA_SWAP bit doesn't have an effect. Thus, it isn't possible to handle the V4L2_PIX_FMT_XRGB32. Thus, it is removed from the list of supported formats. Signed-off-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 5786d24b00f62a8838060c0dcc13932b32d9d082 Author: Ghanshyam Agrawal Date: Sat Nov 25 14:32:36 2023 +0530 media: stk1160: Fixed high volume of stk1160_dbg messages [ Upstream commit b3695e86d25aafbe175dd51f6aaf6f68d341d590 ] The function stk1160_dbg gets called too many times, which causes the output to get flooded with messages. Since stk1160_dbg uses printk, it is now replaced with printk_ratelimited. Suggested-by: Phillip Potter Signed-off-by: Ghanshyam Agrawal Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin commit 813bd97cf175dec86d60bd7cb7cbd87c4798aebc Author: Tomi Valkeinen Date: Thu Sep 21 13:50:32 2023 +0300 drm/mipi-dsi: Fix detach call without attach [ Upstream commit 90d50b8d85834e73536fdccd5aa913b30494fef0 ] It's been reported that DSI host driver's detach can be called without the attach ever happening: https://lore.kernel.org/all/20230412073954.20601-1-tony@atomide.com/ After reading the code, I think this is what happens: We have a DSI host defined in the device tree and a DSI peripheral under that host (i.e. an i2c device using the DSI as data bus doesn't exhibit this behavior). The host driver calls mipi_dsi_host_register(), which causes (via a few functions) mipi_dsi_device_add() to be called for the DSI peripheral. So now we have a DSI device under the host, but attach hasn't been called. Normally the probing of the devices continues, and eventually the DSI peripheral's driver will call mipi_dsi_attach(), attaching the peripheral. However, if the host driver's probe encounters an error after calling mipi_dsi_host_register(), and before the peripheral has called mipi_dsi_attach(), the host driver will do cleanups and return an error from its probe function. The cleanups include calling mipi_dsi_host_unregister(). mipi_dsi_host_unregister() will call two functions for all its DSI peripheral devices: mipi_dsi_detach() and mipi_dsi_device_unregister(). The latter makes sense, as the device exists, but the former may be wrong as attach has not necessarily been done. To fix this, track the attached state of the peripheral, and only detach from mipi_dsi_host_unregister() if the peripheral was attached. Note that I have only tested this with a board with an i2c DSI peripheral, not with a "pure" DSI peripheral. However, slightly related, the unregister machinery still seems broken. E.g. if the DSI host driver is unbound, it'll detach and unregister the DSI peripherals. After that, when the DSI peripheral driver unbound it'll call detach either directly or using the devm variant, leading to a crash. And probably the driver will crash if it happens, for some reason, to try to send a message via the DSI bus. But that's another topic. Tested-by: H. Nikolaus Schaller Acked-by: Maxime Ripard Reviewed-by: Sebastian Reichel Tested-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20230921-dsi-detach-fix-v1-1-d0de2d1621d9@ideasonboard.com Signed-off-by: Sasha Levin commit 69cdec3b860e56c30f01033ae9658886ea8822f3 Author: Tomi Valkeinen Date: Fri Nov 3 15:14:04 2023 +0200 drm/framebuffer: Fix use of uninitialized variable [ Upstream commit f9af8f0c1dc567a5a6a6318ff324c45d80d4a60f ] smatch reports: drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: uninitialized symbol 'ret'. 'ret' is possibly not set when there are no errors, causing the error above. I can't say if that ever happens in real-life, but in any case I think it is good to initialize 'ret' to 0. Reviewed-by: Laurent Pinchart Acked-by: Maxime Ripard Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-2-c22b2444f5f5@ideasonboard.com Signed-off-by: Sasha Levin commit 87ea60fce614decaa56e53cd45f3766860464f4f Author: Tomi Valkeinen Date: Fri Nov 3 15:14:03 2023 +0200 drm/drm_file: fix use of uninitialized variable [ Upstream commit 1d3062fad9c7313fff9970a88e0538a24480ffb8 ] smatch reports: drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized symbol 'supported_status'. 'supported_status' is only set in one code path. I'm not familiar with the code to say if that path will always be ran in real life, but whether that is the case or not, I think it is good to initialize 'supported_status' to 0 to silence the warning (and possibly fix a bug). Reviewed-by: Laurent Pinchart Acked-by: Maxime Ripard Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20231103-uninit-fixes-v2-1-c22b2444f5f5@ideasonboard.com Signed-off-by: Sasha Levin commit 17ba4ac891142a9d6d3909bfb33426b6e987e867 Author: Wenjing Liu Date: Fri Dec 1 06:25:20 2023 -0700 drm/amd/display: add support for DTO genarated dscclk [ Upstream commit 08a32addf17317b9fac55be9b31275cbf6e41fb7 ] Current implementation will choose to use refclk as dscclk. This is not recommended by hardware team as refclk is a fixed value which could cause unnecessary power consumption or it could be not enough for large DSC timings. So we are adding new interfaces so we could switch to use dynamically generated DSCCLK by DTO. So DSCCLK is programmable based on current pixel clock and dispclk. Tested-by: Daniel Wheeler Reviewed-by: Chaitanya Dhere Acked-by: Rodrigo Siqueira Signed-off-by: Wenjing Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 89824a09dda528236af70a4ca375c3cd69539744 Author: Dennis Chan Date: Fri Dec 1 06:25:19 2023 -0700 drm/amd/display: Fix Replay Desync Error IRQ handler [ Upstream commit dd5c6362ddcd8bdb07704faff8648593885ecfa1 ] In previous case, Replay didn't identify the IRQ type, This commit fixes the issues for the interrupt. Tested-by: Daniel Wheeler Reviewed-by: Robin Chen Acked-by: Rodrigo Siqueira Signed-off-by: Dennis Chan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ce29728ef6485a367934cc100249c66dd3cde5b6 Author: Nicholas Susanto Date: Fri Dec 1 06:25:15 2023 -0700 drm/amd/display: Fix disable_otg_wa logic [ Upstream commit 2ce156482a6fef349d2eba98e5070c412d3af662 ] [Why] When switching to another HDMI mode, we are unnecesarilly disabling/enabling FIFO causing both HPO and DIG registers to be set at the same time when only HPO is supposed to be set. This can lead to a system hang the next time we change refresh rates as there are cases when we don't disable OTG/FIFO but FIFO is enabled when it isn't supposed to be. [How] Removing the enable/disable FIFO entirely. Tested-by: Daniel Wheeler Reviewed-by: Nicholas Kazlauskas Acked-by: Rodrigo Siqueira Signed-off-by: Nicholas Susanto Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d38bc19978f26415979a58b1572e1a9c785c5eaf Author: Ilya Bakoulin Date: Fri Dec 1 06:25:06 2023 -0700 drm/amd/display: Fix MST PBN/X.Y value calculations [ Upstream commit 94bbf802efd0a8f13147d6664af6e653637340a8 ] Changing PBN calculation to be more in line with spec. We don't need to inflate PBN_NATIVE value by the 1.006 margin, since that is already taken care of in the get_pbn_per_slot function. Tested-by: Daniel Wheeler Reviewed-by: Wenjing Liu Acked-by: Rodrigo Siqueira Signed-off-by: Ilya Bakoulin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4b6986b170f2f23e390bbd2d50784caa9cb67093 Author: Venkata Prasad Potturu Date: Wed Dec 6 16:36:12 2023 +0530 ASoC: amd: Add new dmi entries for acp5x platform [ Upstream commit c3ab23a10771bbe06300e5374efa809789c65455 ] Add sys_vendor and product_name dmi entries for acp5x platform. Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/20231206110620.1695591-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bc64437cfa833dbe5001d796f68af1afab72eabb Author: Jaegeuk Kim Date: Sat Dec 2 00:08:57 2023 -0800 f2fs: fix write pointers on zoned device after roll forward [ Upstream commit 9dad4d964291295ef48243d4e03972b85138bc9f ] 1. do roll forward recovery 2. update current segments pointers 3. fix the entire zones' write pointers 4. do checkpoint Reviewed-by: Daeho Jeong Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 10d0701ad7a38960b06ea5715c8baadfd12ffbbe Author: Meenakshikumar Somasundaram Date: Thu Nov 9 00:04:36 2023 -0500 drm/amd/display: Fix tiled display misalignment [ Upstream commit c4b8394e76adba4f50a3c2696c75b214a291e24a ] [Why] When otg workaround is applied during clock update, otgs of tiled display went out of sync. [How] To call dc_trigger_sync() after clock update to sync otgs again. Reviewed-by: Nicholas Kazlauskas Acked-by: Hamza Mahfooz Signed-off-by: Meenakshikumar Somasundaram Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e856bb6079d12f16cafc75bf6efb5430aae91b8c Author: Xin Ji Date: Mon Nov 20 17:10:37 2023 +0800 drm/bridge: anx7625: Fix Set HPD irq detect window to 2ms [ Upstream commit e3af7053de3f685c96158373bc234b2feca1f160 ] Polling firmware HPD GPIO status, set HPD irq detect window to 2ms after firmware HPD GPIO initial done Signed-off-by: Xin Ji Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20231120091038.284825-2-xji@analogixsemi.com Signed-off-by: Sasha Levin commit 4306ce2a1f24a2d4bf32ff38dbad1c0a6dd59ed1 Author: Hsin-Yi Wang Date: Fri Nov 17 13:46:32 2023 -0800 drm/panel-edp: Add override_edid_mode quirk for generic edp [ Upstream commit 9f7843b515811aea6c56527eb195b622e9c01f12 ] Generic edp gets mode from edid. However, some panels report incorrect mode in this way, resulting in glitches on panel. Introduce a new quirk additional_mode to the generic edid to pick a correct hardcoded mode. Signed-off-by: Hsin-Yi Wang Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20231117215056.1883314-2-hsinyi@chromium.org Signed-off-by: Sasha Levin commit c5d1f47450c5a73a550e628bd643c50045d42918 Author: Jack Wang Date: Tue Nov 21 14:03:15 2023 +0100 RDMA/IPoIB: Fix error code return in ipoib_mcast_join [ Upstream commit 753fff78f430704548f45eda52d6d55371a52c0f ] Return the error code in case of ib_sa_join_multicast fail. Signed-off-by: Jack Wang Link: https://lore.kernel.org/r/20231121130316.126364-2-jinpu.wang@ionos.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5bc1b5ce24fb761dd14aa4ebe6884801fe371eb8 Author: Danylo Piliaiev Date: Sat Nov 25 11:11:51 2023 -0800 drm/msm/a690: Fix reg values for a690 [ Upstream commit 07e6de738aa6f0e873463e9ca88bdb7081c4bfd4 ] KGSL doesn't support a690 so all reg values were the same as on a660. Now we know the values and they are different from the windows driver. This fixes hangs on D3D12 games and some CTS tests. Signed-off-by: Danylo Piliaiev Signed-off-by: Rob Clark Patchwork: https://patchwork.freedesktop.org/patch/568931/ Signed-off-by: Sasha Levin commit de940cede3c41624e2de27f805b490999f419df9 Author: Jan Kara Date: Thu Oct 12 23:14:21 2023 +0200 ocfs2: Avoid touching renamed directory if parent does not change [ Upstream commit 9d618d19b29c2943527e3a43da0a35aea91062fc ] The VFS will not be locking moved directory if its parent does not change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem. Signed-off-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit c04c162f82ac403917780eb6d1654694455d4e7c Author: Jan Kara Date: Thu Oct 12 23:14:20 2023 +0200 reiserfs: Avoid touching renamed directory if parent does not change [ Upstream commit 49db9b1b86a82448dfaf3fcfefcf678dee56c8ed ] The VFS will not be locking moved directory if its parent does not change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem. Signed-off-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit b0be96903d4fcf6d5cf763985b9712020b23a2ea Author: Al Viro Date: Wed Nov 1 01:08:54 2023 -0400 fast_dput(): handle underflows gracefully [ Upstream commit 504e08cebe1d4e1efe25f915234f646e74a364a8 ] If refcount is less than 1, we should just warn, unlock dentry and return true, so that the caller doesn't try to do anything else. Taking care of that leaves the rest of "lockref_put_return() has failed" case equivalent to "decrement refcount and rejoin the normal slow path after the point where we grab ->d_lock". NOTE: lockref_put_return() is strictly a fastpath thing - unlike the rest of lockref primitives, it does not contain a fallback. Caller (and it looks like fast_dput() is the only legitimate one in the entire kernel) has to do that itself. Reasons for lockref_put_return() failures: * ->d_lock held by somebody * refcount <= 0 * ... or an architecture not supporting lockref use of cmpxchg - sparc, anything non-SMP, config with spinlock debugging... We could add a fallback, but it would be a clumsy API - we'd have to distinguish between: (1) refcount > 1 - decremented, lock not held on return (2) refcount < 1 - left alone, probably no sense to hold the lock (3) refcount is 1, no cmphxcg - decremented, lock held on return (4) refcount is 1, cmphxcg supported - decremented, lock *NOT* held on return. We want to return with no lock held in case (4); that's the whole point of that thing. We very much do not want to have the fallback in case (3) return without a lock, since the caller might have to retake it in that case. So it wouldn't be more convenient than doing the fallback in the caller and it would be very easy to screw up, especially since the test coverage would suck - no way to test (3) and (4) on the same kernel build. Reviewed-by: Christian Brauner Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 21e906f941d0576523bc82fc143f2b8f31e9b005 Author: Cristian Ciocaltea Date: Tue Nov 21 14:07:51 2023 +0200 ASoC: doc: Fix undefined SND_SOC_DAPM_NOPM argument [ Upstream commit 67c7666fe808c3a7af3cc6f9d0a3dd3acfd26115 ] The virtual widget example makes use of an undefined SND_SOC_DAPM_NOPM argument passed to SND_SOC_DAPM_MIXER(). Replace with the correct SND_SOC_NOPM definition. Signed-off-by: Cristian Ciocaltea Link: https://lore.kernel.org/r/20231121120751.77355-1-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e38ad4ace20b4d8408c472a33bd915e64c1b078e Author: Takashi Iwai Date: Tue Nov 21 16:41:25 2023 +0100 ALSA: hda: Refer to correct stream index at loops [ Upstream commit 26257869672fd4a06a60c2da841e15fb2cb47bbe ] In a couple of loops over the all streams, we check the bitmap against the loop counter. A more correct reference would be, however, the index of each stream, instead. This patch corrects the check of bitmaps to the stream index. Note that this change doesn't fix anything for now; all existing drivers set up the stream indices properly, hence the loop count is always equal with the stream index. That said, this change is only for consistency. Link: https://lore.kernel.org/r/20231121154125.4888-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b29cc6e29b5e6037e1bcd2b2ac67b7d89acd194c Author: Chao Yu Date: Thu Nov 16 14:25:56 2023 +0800 f2fs: fix to check return value of f2fs_reserve_new_block() [ Upstream commit 956fa1ddc132e028f3b7d4cf17e6bfc8cb36c7fd ] Let's check return value of f2fs_reserve_new_block() in do_recover_data() rather than letting it fails silently. Also refactoring check condition on return value of f2fs_reserve_new_block() as below: - trigger f2fs_bug_on() only for ENOSPC case; - use do-while statement to avoid redundant codes; Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 933fc06f37a5a8086dfd802ad63bd100314f6b68 Author: Linus Walleij Date: Fri Oct 20 15:11:41 2023 +0200 ARM: dts: usr8200: Fix phy registers [ Upstream commit 18a1ee9d716d355361da2765f87dbbadcdea03bf ] The MV88E6060 switch has internal PHY registers at MDIO addresses 0x00..0x04. Tie each port to the corresponding PHY. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20231020-ixp4xx-usr8200-dtsfix-v1-1-3a8591dea259@linaro.org Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 6a849b5e91d8ac24441282ae92a35da560de623d Author: Vladimir Oltean Date: Thu Jan 4 16:00:31 2024 +0200 net: dsa: qca8k: put MDIO bus OF node on qca8k_mdio_register() failure [ Upstream commit 68e1010cda7967cfca9c8650ee1f4efcae54ab90 ] of_get_child_by_name() gives us an OF node with an elevated refcount, which should be dropped when we're done with it. This is so that, if (of_node_check_flag(node, OF_DYNAMIC)) is true, the node's memory can eventually be freed. There are 2 distinct paths to be considered in qca8k_mdio_register(): - devm_of_mdiobus_register() succeeds: since commit 3b73a7b8ec38 ("net: mdio_bus: add refcounting for fwnodes to mdiobus"), the MDIO core treats this well. - devm_of_mdiobus_register() or anything up to that point fails: it is the duty of the qca8k driver to release the OF node. This change addresses the second case by making sure that the OF node reference is not leaked. The "mdio" node may be NULL, but of_node_put(NULL) is safe. Signed-off-by: Vladimir Oltean Reviewed-by: Alvin Šipraga Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ad39ed642f0afa6f47e3e6a871ccefd32bd59f2f Author: Mina Almasry Date: Tue Jan 2 12:59:58 2024 -0800 net: kcm: fix direct access to bv_len [ Upstream commit b15a4cfe100b9acd097d3ae7052448bd1cdc2a3b ] Minor fix for kcm: code wanting to access the fields inside an skb frag should use the skb_frag_*() helpers, instead of accessing the fields directly. Signed-off-by: Mina Almasry Link: https://lore.kernel.org/r/20240102205959.794513-1-almasrymina@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 90d76270f7fe89a209f52182dd1c0d46f538a268 Author: Suman Ghosh Date: Mon Jan 1 20:20:42 2024 +0530 octeontx2-af: Fix max NPC MCAM entry check while validating ref_entry [ Upstream commit 4ebb1f95e0c3c3e0eec5bb21aa43097580c4b6e4 ] As of today, the last MCAM entry was not getting allocated because of a <= check with the max_bmap count. This patch modifies that and if the requested entry is greater than the available entries then set it to the max value. Signed-off-by: Suman Ghosh Link: https://lore.kernel.org/r/20240101145042.419697-1-sumang@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 087ef07c32ed8105e2ec2c5ed2ecfd7f94106e7c Author: Andrii Staikov Date: Wed Nov 29 15:24:12 2023 +0100 i40e: Fix VF disable behavior to block all traffic [ Upstream commit 31deb12e85c35ddd2c037f0107d05d8674cab2c0 ] Currently, if a VF is disabled using the 'ip link set dev $ETHX vf $VF_NUM state disable' command, the VF is still able to receive traffic. Fix the behavior of the 'ip link set dev $ETHX vf $VF_NUM state disable' to completely shutdown the VF's queues making it entirely disabled and not able to receive or send any traffic. Modify the behavior of the 'ip link set $ETHX vf $VF_NUM state enable' command to make a VF do reinitialization bringing the queues back up. Co-developed-by: Aleksandr Loktionov Signed-off-by: Aleksandr Loktionov Reviewed-by: Jan Sokolowski Reviewed-by: Wojciech Drewek Reviewed-by: Przemek Kitszel Signed-off-by: Andrii Staikov Tested-by: Rafal Romanowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9f5fd537d3ab29cbb592ca851a4caed9d0fdc7c3 Author: Chunyan Zhang Date: Thu Dec 21 17:28:24 2023 +0800 arm64: dts: sprd: Change UMS512 idle-state nodename to match bindings [ Upstream commit 1cff7243334f851b7dddf450abdaa6223a7a28e3 ] Fix below dtbs_check warning: idle-states: 'core-pd' does not match any of the regexes: '^(cpu|cluster)-', 'pinctrl-[0-9]+' Link: https://lore.kernel.org/r/20231221092824.1169453-3-chunyan.zhang@unisoc.com Signed-off-by: Chunyan Zhang Signed-off-by: Sasha Levin commit a42c27cb81bd757114ef738f538eb8da135c1185 Author: Chunyan Zhang Date: Thu Dec 21 17:28:23 2023 +0800 arm64: dts: sprd: Add clock reference for pll2 on UMS512 [ Upstream commit 829e3e70fe72edc084fbfc4964669594ebe427ce ] Fix below dtbs_check warning: 'clocks' is a dependency of 'clock-names' Link: https://lore.kernel.org/r/20231221092824.1169453-2-chunyan.zhang@unisoc.com Signed-off-by: Chunyan Zhang Signed-off-by: Sasha Levin commit 2d6edeaf0d9fa8e34a6385b1c340cb35606e9af6 Author: Lin Ma Date: Thu Dec 21 00:34:51 2023 +0800 bridge: cfm: fix enum typo in br_cc_ccm_tx_parse [ Upstream commit c2b2ee36250d967c21890cb801e24af4b6a9eaa5 ] It appears that there is a typo in the code where the nlattr array is being parsed with policy br_cfm_cc_ccm_tx_policy, but the instance is being accessed via IFLA_BRIDGE_CFM_CC_RDI_INSTANCE, which is associated with the policy br_cfm_cc_rdi_policy. This problem was introduced by commit 2be665c3940d ("bridge: cfm: Netlink SET configuration Interface."). Though it seems like a harmless typo since these two enum owns the exact same value (1 here), it is quite misleading hence fix it by using the correct enum IFLA_BRIDGE_CFM_CC_CCM_TX_INSTANCE here. Signed-off-by: Lin Ma Reviewed-by: Simon Horman Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57bd38eb97a8bcb72dc7f0c890f012538103c216 Author: Wen Gu Date: Tue Dec 19 22:26:15 2023 +0800 net/smc: disable SEID on non-s390 archs where virtual ISM may be used [ Upstream commit c6b8b8eb49904018e22e4e4b1fa502e57dc747d9 ] The system EID (SEID) is an internal EID used by SMC-D to represent the s390 physical machine that OS is executing on. On s390 architecture, it predefined by fixed string and part of cpuid and is enabled regardless of whether underlay device is virtual ISM or platform firmware ISM. However on non-s390 architectures where SMC-D can be used with virtual ISM devices, there is no similar information to identify physical machines, especially in virtualization scenarios. So in such cases, SEID is forcibly disabled and the user-defined UEID will be used to represent the communicable space. Signed-off-by: Wen Gu Reviewed-and-tested-by: Wenjia Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d136385406676ff6f9021762bd66d6b387c5cf3e Author: Frédéric Danis Date: Tue Dec 19 09:10:22 2023 +0100 Bluetooth: L2CAP: Fix possible multiple reject send [ Upstream commit 96a3398b467ab8aada3df2f3a79f4b7835d068b8 ] In case of an incomplete command or a command with a null identifier 2 reject packets will be sent, one with the identifier and one with 0. Consuming the data of the command will prevent it. This allows to send a reject packet for each corrupted command in a multi-command packet. Signed-off-by: Frédéric Danis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d5761e2f66b3ecea483147855935320590d22096 Author: clancy shang Date: Mon Dec 18 18:24:17 2023 +0800 Bluetooth: hci_sync: fix BR/EDR wakeup bug [ Upstream commit d4b70ba1eab450eff9c5ef536f07c01d424b7eda ] when Bluetooth set the event mask and enter suspend, the controller has hci mode change event coming, it cause controller can not enter sleep mode. so it should to set the hci mode change event mask before enter suspend. Signed-off-by: clancy shang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f291566ad1b10986ce5725ce9348a54e771e19ec Author: Iulia Tanasescu Date: Tue Dec 5 18:11:40 2023 +0200 Bluetooth: ISO: Avoid creating child socket if PA sync is terminating [ Upstream commit 9f150019f176078144b02c4b9b9dbe7fd5a2fcc3 ] When a PA sync socket is closed, the associated hcon is also unlinked and cleaned up. If there are no other hcons marked with the HCI_CONN_PA_SYNC flag, HCI_OP_LE_PA_TERM_SYNC is sent to controller. Between the time of the command and the moment PA sync is terminated in controller, residual BIGInfo reports might continue to come. This causes a new PA sync hcon to be added, and a new socket to be notified to user space. This commit fixs this by adding a flag on a Broadcast listening socket to mark when the PA sync child has been closed. This flag is checked when BIGInfo reports are indicated in iso_connect_ind, to avoid recreating a hcon and socket if residual reports arrive before PA sync is terminated. Signed-off-by: Iulia Tanasescu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit d9763a01e308fa1b60548354a76d6074f9c05594 Author: Zijun Hu Date: Mon Nov 6 14:02:46 2023 +0800 Bluetooth: qca: Set both WIDEBAND_SPEECH and LE_STATES quirks for QCA2066 [ Upstream commit 5d192b697c7417254cdd9edc3d5e9e0364eb9045 ] Set both WIDEBAND_SPEECH_SUPPORTED and VALID_LE_STATES quirks for QCA2066. Signed-off-by: Zijun Hu Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 357c371dfd06f0fda3c690de84ed4bceff43e1f7 Author: Benjamin Berg Date: Wed Dec 20 13:41:41 2023 +0200 wifi: cfg80211: free beacon_ies when overridden from hidden BSS [ Upstream commit 32af9a9e1069e55bc02741fb00ac9d0ca1a2eaef ] This is a more of a cosmetic fix. The branch will only be taken if proberesp_ies is set, which implies that beacon_ies is not set unless we are connected to an AP that just did a channel switch. And, in that case we should have found the BSS in the internal storage to begin with. Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20231220133549.b898e22dadff.Id8c4c10aedd176ef2e18a4cad747b299f150f9df@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c369a21382a68ee5ee9e0856d48c26c43bd99e8f Author: Su Hui Date: Tue Dec 19 14:57:39 2023 +0800 wifi: rtlwifi: rtl8723{be,ae}: using calculate_bit_shift() [ Upstream commit 5c16618bc06a41ad68fd8499a21d35ef57ca06c2 ] Using calculate_bit_shift() to replace rtl8723_phy_calculate_bit_shift(). And fix an undefined bitwise shift behavior problem. Signed-off-by: Su Hui Signed-off-by: Kalle Valo Link: https://msgid.link/20231219065739.1895666-12-suhui@nfschina.com Signed-off-by: Sasha Levin commit ab26541270c722eedf8eefd62797c3ce3d18a91b Author: Mingyi Zhang Date: Thu Dec 21 11:39:47 2023 +0800 libbpf: Fix NULL pointer dereference in bpf_object__collect_prog_relos [ Upstream commit fc3a5534e2a8855427403113cbeb54af5837bbe0 ] An issue occurred while reading an ELF file in libbpf.c during fuzzing: Program received signal SIGSEGV, Segmentation fault. 0x0000000000958e97 in bpf_object.collect_prog_relos () at libbpf.c:4206 4206 in libbpf.c (gdb) bt #0 0x0000000000958e97 in bpf_object.collect_prog_relos () at libbpf.c:4206 #1 0x000000000094f9d6 in bpf_object.collect_relos () at libbpf.c:6706 #2 0x000000000092bef3 in bpf_object_open () at libbpf.c:7437 #3 0x000000000092c046 in bpf_object.open_mem () at libbpf.c:7497 #4 0x0000000000924afa in LLVMFuzzerTestOneInput () at fuzz/bpf-object-fuzzer.c:16 #5 0x000000000060be11 in testblitz_engine::fuzzer::Fuzzer::run_one () #6 0x000000000087ad92 in tracing::span::Span::in_scope () #7 0x00000000006078aa in testblitz_engine::fuzzer::util::walkdir () #8 0x00000000005f3217 in testblitz_engine::entrypoint::main::{{closure}} () #9 0x00000000005f2601 in main () (gdb) scn_data was null at this code(tools/lib/bpf/src/libbpf.c): if (rel->r_offset % BPF_INSN_SZ || rel->r_offset >= scn_data->d_size) { The scn_data is derived from the code above: scn = elf_sec_by_idx(obj, sec_idx); scn_data = elf_sec_data(obj, scn); relo_sec_name = elf_sec_str(obj, shdr->sh_name); sec_name = elf_sec_name(obj, scn); if (!relo_sec_name || !sec_name)// don't check whether scn_data is NULL return -EINVAL; In certain special scenarios, such as reading a malformed ELF file, it is possible that scn_data may be a null pointer Signed-off-by: Mingyi Zhang Signed-off-by: Xin Liu Signed-off-by: Changye Wu Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20231221033947.154564-1-liuxin350@huawei.com Signed-off-by: Sasha Levin commit f84e56599f3b08e2ac35218f493acacb8a6889dc Author: Ching-Te Ku Date: Mon Dec 18 14:13:31 2023 +0800 wifi: rtw89: coex: Fix wrong Wi-Fi role info and FDDT parameter members [ Upstream commit acc55d7dd4de525ac07e43e90ea3cc630677ec8a ] The Wi-Fi firmware 29.29.X should use version 2 role info format. FDDT mechanism version 5 use the same cell members to judge traffic situation, don't need to add another new format. Signed-off-by: Ching-Te Ku Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/20231218061341.51255-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 03d0be863227ffa6fd4b87e20c7f92bdf0e80d23 Author: Zenm Chen Date: Sun Dec 17 20:30:17 2023 +0800 wifi: rtl8xxxu: Add additional USB IDs for RTL8192EU devices [ Upstream commit 4e87ca403e2008b9e182239e1abbf6876a55eb33 ] Add additional USB IDs found in the vendor driver from https://github.com/Mange/rtl8192eu-linux-driver to support more RTL8192EU devices. Signed-off-by: Zenm Chen Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/20231217123017.1982-1-zenmchen@gmail.com Signed-off-by: Sasha Levin commit 1edcc3302cc6bc9df20cf2d465c643a2b324439d Author: Xianwei Zhao Date: Fri Dec 15 16:28:00 2023 +0800 arm64: dts: amlogic: fix format for s4 uart node [ Upstream commit eb54ef36282f670c704ed5af8593da62bebba80d ] Aliases use lowercase letters and place status in end. Signed-off-by: Xianwei Zhao Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20231215-s4-dts-v1-1-7831ab6972be@amlogic.com Signed-off-by: Neil Armstrong Signed-off-by: Sasha Levin commit 55fd6e3c348ddbb6d2b7f6b707ca1ae343030cc3 Author: Jesse Brandeburg Date: Tue Dec 5 17:01:06 2023 -0800 ice: fix pre-shifted bit usage [ Upstream commit 7173be21ae29ef50ada42fd4464056a9d3f55bb3 ] While converting to FIELD_PREP() and FIELD_GET(), it was noticed that some of the RSS defines had *included* the shift in their definitions. This is completely outside of normal, such that a developer could easily make a mistake and shift at the usage site (like when using FIELD_PREP()). Rename the defines and set them to the "pre-shifted values" so they match the template the driver normally uses for masks and the member bits of the mask, which also allows the driver to use FIELD_PREP correctly with these values. Use GENMASK() for this changed MASK value. Do the same for the VLAN EMODE defines as well. Reviewed-by: Marcin Szycik Reviewed-by: Simon Horman Signed-off-by: Jesse Brandeburg Tested-by: Pucha Himasekhar Reddy (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 2c8cd52a0298493ea62f9f180edaf326f20c01c3 Author: Jesse Brandeburg Date: Tue Dec 5 17:01:01 2023 -0800 intel: add bit macro includes where needed [ Upstream commit 3314f2097dee43defc20554f961a8b17f4787e2d ] This series is introducing the use of FIELD_GET and FIELD_PREP which requires bitfield.h to be included. Fix all the includes in this one change, and rearrange includes into alphabetical order to ease readability and future maintenance. virtchnl.h and it's usage was modified to have it's own includes as it should. This required including bits.h for virtchnl.h. Reviewed-by: Marcin Szycik Signed-off-by: Jesse Brandeburg Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9cf8631b3a0d535d2bad1207b04645e44229c466 Author: Mao Jinlong Date: Sat Dec 9 23:26:31 2023 -0800 arm64: dts: qcom: Fix coresight warnings in in-ports and out-ports [ Upstream commit bdb6339fd46b8702ea7411b0b414587b86a40562 ] When a node is only one in port or one out port, address-cells and size-cells are not required in in-ports and out-ports. And the number and reg of the port need to be removed. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mao Jinlong Link: https://lore.kernel.org/r/20231210072633.4243-5-quic_jinlmao@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 191a6a6e859527dcb9222eb1b19696da152ce2c2 Author: Mao Jinlong Date: Sat Dec 9 23:26:30 2023 -0800 arm64: dts: qcom: msm8998: Fix 'out-ports' is a required property [ Upstream commit ae5ee3562a2519214b12228545e88a203dd68bbd ] out-ports is a required property for coresight ETM. Add out-ports for ETM nodes to fix the warning. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mao Jinlong Link: https://lore.kernel.org/r/20231210072633.4243-4-quic_jinlmao@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 3168ad44fb4ff106b803a10707411700886cf557 Author: Mao Jinlong Date: Sat Dec 9 23:26:29 2023 -0800 arm64: dts: qcom: msm8996: Fix 'in-ports' is a required property [ Upstream commit 9a6fc510a6a3ec150cb7450aec1e5f257e6fc77b ] Add the inport of funnel@3023000 to fix 'in-ports' is a required property warning. Reviewed-by: Krzysztof Kozlowski Signed-off-by: Mao Jinlong Link: https://lore.kernel.org/r/20231210072633.4243-3-quic_jinlmao@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 450371ed5b66334091aa5c7d360570d7cad758f4 Author: Alexei Starovoitov Date: Fri Dec 15 10:12:23 2023 +0100 x86/cfi,bpf: Fix bpf_exception_cb() signature [ Upstream commit 852486b35f344887786d63250946dd921a05d7e8 ] As per the earlier patches, BPF sub-programs have bpf_callback_t signature and CFI expects callers to have matching signature. This is violated by bpf_prog_aux::bpf_exception_cb(). [peterz: Changelog] Reported-by: Peter Zijlstra Signed-off-by: Alexei Starovoitov Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/CAADnVQ+Z7UcXXBBhMubhcMM=R-dExk-uHtfOLtoLxQ1XxEpqEA@mail.gmail.com Link: https://lore.kernel.org/r/20231215092707.910319166@infradead.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 10e40cdeebdfedc1871c2046873dc0db9673a34a Author: Alex Lyakas Date: Wed Dec 13 14:24:31 2023 +0200 md: Whenassemble the array, consult the superblock of the freshest device [ Upstream commit dc1cc22ed58f11d58d8553c5ec5f11cbfc3e3039 ] Upon assembling the array, both kernel and mdadm allow the devices to have event counter difference of 1, and still consider them as up-to-date. However, a device whose event count is behind by 1, may in fact not be up-to-date, and array resync with such a device may cause data corruption. To avoid this, consult the superblock of the freshest device about the status of a device, whose event counter is behind by 1. Signed-off-by: Alex Lyakas Signed-off-by: Song Liu Link: https://lore.kernel.org/r/1702470271-16073-1-git-send-email-alex.lyakas@zadara.com Signed-off-by: Sasha Levin commit 9f75ebaad75d183c38b4081edb1035bab27b6ee7 Author: Christoph Hellwig Date: Mon Dec 4 18:34:18 2023 +0100 block: prevent an integer overflow in bvec_try_merge_hw_page [ Upstream commit 3f034c374ad55773c12dd8f3c1607328e17c0072 ] Reordered a check to avoid a possible overflow when adding len to bv_len. Signed-off-by: Christoph Hellwig Reviewed-by: Johannes Thumshirn Link: https://lore.kernel.org/r/20231204173419.782378-2-hch@lst.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b7e02a27738f0629bc20be65f16c6fc18bd5ccac Author: Linus Walleij Date: Mon Nov 27 16:51:01 2023 +0100 ARM64: dts: marvell: Fix some common switch mistakes [ Upstream commit fedb923aaf611e36adad4cd8c91d35bc283d3eea ] Fix some errors in the Marvell MV88E6xxx switch descriptions: - The top node had no address size or cells. - switch0@0 is not OK, should be ethernet-switch@0. - ports should be ethernet-ports - port@0 should be ethernet-port@0 - PHYs should be named ethernet-phy@ Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 803923b017a0131ecdfc3c7350f7eac06528d1e3 Author: Linus Walleij Date: Mon Nov 27 16:51:00 2023 +0100 ARM: dts: marvell: Fix some common switch mistakes [ Upstream commit 6e75ac5a824e1551764cd4bfce5ede3d5fafc407 ] Fix some errors in the Marvell MV88E6xxx switch descriptions: - The top node had no address size or cells. - switch0@0 is not OK, should be ethernet-switch@0. - The ports node should be named ethernet-ports - The ethernet-ports node should have port@0 etc children, no plural "ports" in the children. - Ports should be named ethernet-port@0 etc - PHYs should be named ethernet-phy@0 etc This serves as an example of fixes needed for introducing a schema for the bindings, but the patch can simply be applied. Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit bb844806b58d869ed83ad4448feea778b8496dcd Author: Tobias Waldekranz Date: Thu Dec 14 14:50:24 2023 +0100 net: dsa: mv88e6xxx: Fix mv88e6352_serdes_get_stats error path [ Upstream commit fc82a08ae795ee6b73fb6b50785f7be248bec7b5 ] mv88e6xxx_get_stats, which collects stats from various sources, expects all callees to return the number of stats read. If an error occurs, 0 should be returned. Prevent future mishaps of this kind by updating the return type to reflect this contract. Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Tobias Waldekranz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1fde4a7e1dcc4d49cce285107a7a43c3030878d Author: Igor Russkikh Date: Wed Dec 13 10:50:44 2023 +0100 net: atlantic: eliminate double free in error handling logic [ Upstream commit b3cb7a830a24527877b0bc900b9bd74a96aea928 ] Driver has a logic leak in ring data allocation/free, where aq_ring_free could be called multiple times on same ring, if system is under stress and got memory allocation error. Ring pointer was used as an indicator of failure, but this is not correct since only ring data is allocated/deallocated. Ring itself is an array member. Changing ring allocation functions to return error code directly. This simplifies error handling and eliminates aq_ring_free on higher layer. Signed-off-by: Igor Russkikh Link: https://lore.kernel.org/r/20231213095044.23146-1-irusskikh@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 447ac7fccdc96ead9d063554159f95e004faaa62 Author: Ahmed Zaki Date: Tue Dec 12 17:33:17 2023 -0700 ice: fix ICE_AQ_VSI_Q_OPT_RSS_* register values [ Upstream commit 20f73b60bb5c276cee9b1a530f100c677bc74af8 ] Fix the values of the ICE_AQ_VSI_Q_OPT_RSS_* registers. Shifting is already done when the values are used, no need to double shift. Bug was not discovered earlier since only ICE_AQ_VSI_Q_OPT_RSS_TPLZ (Zero) is currently used. Also, rename ICE_AQ_VSI_Q_OPT_RSS_XXX to ICE_AQ_VSI_Q_OPT_RSS_HASH_XXX for consistency. Co-developed-by: Jesse Brandeburg Signed-off-by: Jesse Brandeburg Reviewed-by: Wojciech Drewek Signed-off-by: Ahmed Zaki Link: https://lore.kernel.org/r/20231213003321.605376-5-ahmed.zaki@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f9403653ca98d7842cc35cead82b42fe05a6a121 Author: Yihang Li Date: Thu Dec 14 11:45:12 2023 +0800 scsi: hisi_sas: Set .phy_attached before notifing phyup event HISI_PHYE_PHY_UP_PM [ Upstream commit ce26497c745d0541aec930d5211b431a1c26af97 ] Currently in directly attached scenario, the phyup event HISI_PHYE_PHY_UP_PM is notified before .phy_attached is set - this may cause the phyup work hisi_sas_bytes_dmaed() execution failed and the attached device will not be found. To fix it, set .phy_attached before notifing phyup event. Signed-off-by: Yihang Li Signed-off-by: Xiang Chen Link: https://lore.kernel.org/r/1702525516-51258-2-git-send-email-chenxiang66@hisilicon.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 48f61faa585fa610d20dbc7a1898e9f92c841184 Author: Justin Tee Date: Thu Dec 7 14:40:38 2023 -0800 scsi: lpfc: Move determination of vmid_flag after VMID reinitialization completes [ Upstream commit aba0fb0ef607a71511d23a07406f11130c1a54c5 ] If priority tagging is set in the service parameters of a FLOGI cmpl, then we update the vmid_flag. In the current logic, if a follow up FLOGI cmpl updates its service parameters such that priority tagging is no longer set, then the vmid_flag ends up keeping stale data. Fix by ensuring we clear the vmid_flag member during lpfc_reinit_vmid, and check the priority tagging service parameter after reinitialization of the vmid data structures. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20231207224039.35466-4-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fa5561b6b30118fdd38ae213bc736f1949364f17 Author: Justin Tee Date: Thu Dec 7 14:40:37 2023 -0800 scsi: lpfc: Reinitialize an NPIV's VMID data structures after FDISC [ Upstream commit 8dc8eb89f4df74593ba4bf30c3d31a0fc6d3ea47 ] After a follow up FDISC cmpl, an NPIV's VMID data structures are not updated. Fix by calling lpfc_reinit_vmid and copying the physical port's vmid_flag to the NPIV's vmid_flag in the NPIV registration cmpl code path. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20231207224039.35466-3-justintee8345@gmail.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 039339940e8c0f2130e8ae1d118fa5a28100309d Author: Fabio Estevam Date: Thu Dec 7 07:26:31 2023 -0300 ARM: dts: imx23/28: Fix the DMA controller node name [ Upstream commit 858d83ca4b50bbc8693d95cc94310e6d791fb2e6 ] Per fsl,mxs-dma.yaml, the node name should be 'dma-controller'. Change it to fix the following dt-schema warning. imx28-apf28.dtb: dma-apbx@80024000: $nodename:0: 'dma-apbx@80024000' does not match '^dma-controller(@.*)?$' from schema $id: http://devicetree.org/schemas/dma/fsl,mxs-dma.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 73ad41f52c949c49e12cb51602f35bd91293e5b1 Author: Fabio Estevam Date: Thu Dec 7 07:12:12 2023 -0300 ARM: dts: imx23-sansa: Use preferred i2c-gpios properties [ Upstream commit e3aa1a82fb20ee97597022f6528823a8ab82bde6 ] The 'gpios' property to describe the SDA and SCL GPIOs is considered deprecated according to i2c-gpio.yaml. Switch to the preferred 'sda-gpios' and 'scl-gpios' properties. This fixes the following schema warnings: imx23-sansa.dtb: i2c-0: 'sda-gpios' is a required property from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml# imx23-sansa.dtb: i2c-0: 'scl-gpios' is a required property from schema $id: http://devicetree.org/schemas/i2c/i2c-gpio.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 0069227346ee2fcf4f6776803efaf51d64d1f994 Author: Fabio Estevam Date: Wed Dec 6 17:19:05 2023 -0300 ARM: dts: imx27-apf27dev: Fix LED name [ Upstream commit dc35e253d032b959d92e12f081db5b00db26ae64 ] Per leds-gpio.yaml, the led names should start with 'led'. Change it to fix the following dt-schema warning: imx27-apf27dev.dtb: leds: 'user' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/leds/leds-gpio.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit dc9e0d1d75321faa33dc32ff8ce7fb72ccf4325f Author: Fabio Estevam Date: Wed Dec 6 17:14:05 2023 -0300 ARM: dts: imx25/27: Pass timing0 [ Upstream commit 11ab7ad6f795ae23c398a4a5c56505d3dab27c4c ] Per display-timings.yaml, the 'timing' pattern should be used to describe the display timings. Change it accordingly to fix the following dt-schema warning: imx27-apf27dev.dtb: display-timings: '800x480' does not match any of the regexes: '^timing', 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/display/panel/display-timings.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit bb0a2724d73c0e436b4f2f82758bd384d6eb33f9 Author: Fabio Estevam Date: Wed Dec 6 17:00:33 2023 -0300 ARM: dts: imx25: Fix the iim compatible string [ Upstream commit f0b929f58719fc57a4926ab4fc972f185453d6a5 ] Per imx-iim.yaml, the compatible string should only contain a single entry. Use it as "fsl,imx25-iim" to fix the following dt-schema warning: imx25-karo-tx25.dtb: efuse@53ff0000: compatible: ['fsl,imx25-iim', 'fsl,imx27-iim'] is too long from schema $id: http://devicetree.org/schemas/nvmem/imx-iim.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit e7a5977c8efab4cb6fe4c3444c5c5abf7ab7423e Author: Andrii Nakryiko Date: Tue Dec 12 14:53:43 2023 -0800 selftests/bpf: fix compiler warnings in RELEASE=1 mode [ Upstream commit 62d9a969f4a95219c757831e9ad66cd4dd9edee5 ] When compiling BPF selftests with RELEASE=1, we get two new warnings, which are treated as errors. Fix them. Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Acked-by: John Fastabend Link: https://lore.kernel.org/r/20231212225343.1723081-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 916bc604dbe4afb30d2bfeef698ae57dae973f6f Author: Michal Simek Date: Thu Nov 30 10:59:16 2023 +0100 arm64: zynqmp: Fix clock node name in kv260 cards [ Upstream commit 0bfb7950cc1975372c4c58c3d3f9803f05245d46 ] node name shouldn't use '_' that's why convert it to '-'. Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 6b82b1e83ceaf7df2b8a1ff93080f1762314d349 Author: Michal Simek Date: Thu Nov 30 10:59:15 2023 +0100 arm64: zynqmp: Move fixed clock to / for kv260 [ Upstream commit 6a10a19a6bd2fd8d27a510678bf87bd9408f51d8 ] fixed clock nodes can't be on the bus because they are missing reg property. That's why move them to root. And because it is root it is good to have it as the first node in a file. Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit a2c6206f18104fba7f887bf4dbbfe4c41adc4339 Author: Kees Cook Date: Tue Dec 12 13:47:42 2023 -0800 block/rnbd-srv: Check for unlikely string overflow [ Upstream commit 9e4bf6a08d1e127bcc4bd72557f2dfafc6bc7f41 ] Since "dev_search_path" can technically be as large as PATH_MAX, there was a risk of truncation when copying it and a second string into "full_path" since it was also PATH_MAX sized. The W=1 builds were reporting this warning: drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra': drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~ In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ To fix this, unconditionally check for truncation (as was already done for the case where "%SESSNAME%" was present). Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312100355.lHoJPgKy-lkp@intel.com/ Cc: Md. Haris Iqbal Cc: Jack Wang Cc: Jens Axboe Cc: Signed-off-by: Kees Cook Acked-by: Guoqing Jiang Acked-by: Jack Wang Link: https://lore.kernel.org/r/20231212214738.work.169-kees@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5241fab05f1632b8a66726d9e7681f575b731df4 Author: Shannon Nelson Date: Mon Dec 11 10:57:59 2023 -0800 ionic: bypass firmware cmds when stuck in reset [ Upstream commit ca5fdf9a7c5b65968c718f2be159cda4c13556a1 ] If the driver or firmware is stuck in reset state, don't bother trying to use adminq commands. This speeds up shutdown and prevents unnecessary timeouts and error messages. This includes a bit of rework on ionic_adminq_post_wait() and ionic_adminq_post_wait_nomsg() to both use __ionic_adminq_post_wait() which can do the checks needed in both cases. Signed-off-by: Shannon Nelson Reviewed-by: Brett Creeley Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c01dfb3ef3db07862c90b6ae1e78b85d38aded50 Author: Shannon Nelson Date: Mon Dec 11 10:57:57 2023 -0800 ionic: pass opcode to devcmd_wait [ Upstream commit 24f110240c03c6b5368f1203bac72883d511e606 ] Don't rely on the PCI memory for the devcmd opcode because we read a 0xff value if the PCI bus is broken, which can cause us to report a bogus dev_cmd opcode later. Signed-off-by: Shannon Nelson Reviewed-by: Brett Creeley Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 01bb6c177452ef4f76c426191e5ce6ba8f8edbfd Author: Christian Marangi Date: Fri Dec 8 15:51:48 2023 +0100 net: phy: at803x: fix passing the wrong reference for config_intr [ Upstream commit f8fdbf3389f44c7026f16e36cb1f2ff017f7f5b2 ] Fix passing the wrong reference for config_initr on passing the function pointer, drop the wrong & from at803x_config_intr in the PHY struct. Signed-off-by: Christian Marangi Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9d350b23349fdcde03de528f17ebe9bcc571dd88 Author: Fabio Estevam Date: Wed Dec 6 09:39:21 2023 -0300 ARM: dts: imx1: Fix sram node [ Upstream commit c248e535973088ba7071ff6f26ab7951143450af ] Per sram.yaml, address-cells, size-cells and ranges are mandatory. The node name should be sram. Change the node name and pass the required properties to fix the following dt-schema warnings: imx1-apf9328.dtb: esram@300000: $nodename:0: 'esram@300000' does not match '^sram(@.*)?' from schema $id: http://devicetree.org/schemas/sram/sram.yaml# imx1-apf9328.dtb: esram@300000: '#address-cells' is a required property from schema $id: http://devicetree.org/schemas/sram/sram.yaml# imx1-apf9328.dtb: esram@300000: '#size-cells' is a required property from schema $id: http://devicetree.org/schemas/sram/sram.yaml# imx1-apf9328.dtb: esram@300000: 'ranges' is a required property from schema $id: http://devicetree.org/schemas/sram/sram.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit fca6c926eb786d869128cc4a20e01cf7f8700bae Author: Fabio Estevam Date: Wed Dec 6 09:39:20 2023 -0300 ARM: dts: imx27: Fix sram node [ Upstream commit 2fb7b2a2f06bb3f8321cf26c33e4e820c5b238b6 ] Per sram.yaml, address-cells, size-cells and ranges are mandatory. Pass them to fix the following dt-schema warnings: Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 37d4d09a229cb94f2061cb06c62bfb9e9dffa32a Author: Fabio Estevam Date: Wed Dec 6 09:36:05 2023 -0300 ARM: dts: imx: Use flash@0,0 pattern [ Upstream commit 1e1d7cc478fb16816de09740e3c323c0c188d58f ] Per mtd-physmap.yaml, 'nor@0,0' is not a valid node pattern. Change it to 'flash@0,0' to fix the following dt-schema warning: imx1-ads.dtb: nor@0,0: $nodename:0: 'nor@0,0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 29cec0131a2580427b24bd5b323b48ccc835bbeb Author: Fabio Estevam Date: Wed Dec 6 08:58:26 2023 -0300 ARM: dts: imx25/27-eukrea: Fix RTC node name [ Upstream commit 68c711b882c262e36895547cddea2c2d56ce611d ] Node names should be generic. Use 'rtc' as node name to fix the following dt-schema warning: imx25-eukrea-mbimxsd25-baseboard.dtb: pcf8563@51: $nodename:0: 'pcf8563@51' does not match '^rtc(@.*|-([0-9]|[1-9][0-9]+))?$' from schema $id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml# Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 298a3d775d78a8ff4cf5ddddcd79db6f27d48ed1 Author: Johan Jonker Date: Mon Dec 4 18:40:27 2023 +0100 ARM: dts: rockchip: fix rk3036 hdmi ports node [ Upstream commit 27ded76ef0fcfcf939914532aae575cf23c221b4 ] Fix hdmi ports node so that it matches the rockchip,inno-hdmi.yaml binding. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/9a2afac1-ed5c-382d-02b0-b2f5f1af3abb@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 8c7e1faa0356beba8551bb6c4c6a57f717f37474 Author: Lingbo Kong Date: Wed Dec 6 22:17:59 2023 +0800 wifi: ath12k: fix the issue that the multicast/broadcast indicator is not read correctly for WCN7850 [ Upstream commit 7133b072dfbfac8763ffb017642c9c894894c50d ] We observe some packets are discarded in ieee80211_rx_handlers_result function for WCN7850. This is because the way to get multicast/broadcast indicator with RX_MSDU_END_INFO5_DA_IS_MCBC & info5 is incorrect. It should use RX_MSDU_END_INFO13_MCAST_BCAST & info13 to get multicast/broadcast indicator. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by: Lingbo Kong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231206141759.5430-1-quic_lingbok@quicinc.com Signed-off-by: Sasha Levin commit 3739121443f5114c6bcf6d841a5124deb006b878 Author: Dmitry Antipov Date: Mon Dec 4 20:11:28 2023 +0300 wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap() [ Upstream commit fe0a7776d4d19e613bb8dd80fe2d78ae49e8b49d ] Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()' should check the return value before examining skb data. So convert the latter to return an appropriate error code and propagate it to return from 'wfx_start_ap()' as well. Compile tested only. Signed-off-by: Dmitry Antipov Tested-by: Jérôme Pouiller Acked-by: Jérôme Pouiller Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231204171130.141394-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin commit fe77396943a02bc82b8d7c55fcb1838a015831ca Author: Hou Tao Date: Fri Dec 8 18:23:53 2023 +0800 bpf: Set uattr->batch.count as zero before batched update or deletion [ Upstream commit 06e5c999f10269a532304e89a6adb2fbfeb0593c ] generic_map_{delete,update}_batch() doesn't set uattr->batch.count as zero before it tries to allocate memory for key. If the memory allocation fails, the value of uattr->batch.count will be incorrect. Fix it by setting uattr->batch.count as zero beore batched update or deletion. Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20231208102355.2628918-6-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 23587d856aa956183a083a0c16cc6e801aae10e7 Author: StanleyYP Wang Date: Mon Nov 13 15:06:19 2023 +0800 wifi: mt76: mt7996: add PCI IDs for mt7992 [ Upstream commit 3d3f117a259a65353bf2714a18e25731b3ca5770 ] Add PCI device IDs to enable mt7992 chipsets support. Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b6bbbba3b85c51f99830c29fd062a7c234c97f92 Author: MeiChia Chiu Date: Thu Nov 2 18:03:02 2023 +0800 wifi: mt76: connac: fix EHT phy mode check [ Upstream commit 2c2f50bf6407e1fd43a1a257916aeaa5ffdacd6c ] Add a BSS eht_support check before returning EHT phy mode. Without this patch, there might be an inconsistency where the softmac layer thinks the BSS is in HE mode, while the FW thinks it is in EHT mode. Signed-off-by: MeiChia Chiu Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 6d67311241d55bcf7bb05dfcee6c6d510b8f9343 Author: Nia Espera Date: Sat Nov 11 23:07:42 2023 +0100 arm64: dts: qcom: sm8350: Fix remoteproc interrupt type [ Upstream commit 54ee322f845c7f25fbf6e43e11147b6cae8eff56 ] In a similar vein to https://lore.kernel.org/lkml/20220530080842.37024-3-manivannan.sadhasivam@linaro.org/, the remote processors on sm8350 fail to initialize with the 'correct' (i.e., specified in downstream) IRQ type. Change this to EDGE_RISING. Signed-off-by: Nia Espera Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231111-nia-sm8350-for-upstream-v4-4-3a638b02eea5@igalia.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 8be69984659d68848024c2744bbc5ad59343a407 Author: Neil Armstrong Date: Mon Nov 6 16:58:33 2023 +0100 arm64: dts: qcom: sm8450: fix soundwire controllers node name [ Upstream commit 11fcb81373de52eeb1d3ff135a8d24a4b18978d3 ] Fix the following dt bindings check: arch/arm64/boot/dts/qcom/sm8450-hdk.dtb: soundwire-controller@31f0000: $nodename:0: 'soundwire-controller@31f0000' does not match '^soundwire(@.*)?$' from schema $id: http://devicetree.org/schemas/soundwire/qcom,soundwire.yaml# Signed-off-by: Neil Armstrong Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231106-topic-sm8450-upstream-soundwire-bindings-fix-v1-1-41d4844a5a7d@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 38cfaa6bc6e7b1b2b2f6d985620abf86264770f5 Author: Neil Armstrong Date: Mon Nov 6 15:23:57 2023 +0100 arm64: dts: qcom: sm8550: fix soundwire controllers node name [ Upstream commit 07c88da81caf0e72c3690b689d30f0d325cfeff4 ] Fix the following dt bindings check: arch/arm64/boot/dts/qcom/sm8550-mtp.dtb: soundwire-controller@6ab0000: $nodename:0: 'soundwire-controller@6ab0000' does not match '^soundwire(@.*)?$' from schema $id: http://devicetree.org/schemas/soundwire/qcom,soundwire.yaml# Signed-off-by: Neil Armstrong Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231106-topic-sm8550-upstream-soundwire-bindings-fix-v1-1-4ded91c805a1@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit d5be50156a26293f8bbb1a8accb3f081305ad2ad Author: Tobias Waldekranz Date: Mon Dec 4 11:08:10 2023 +0100 net: mvmdio: Avoid excessive sleeps in polled mode [ Upstream commit 7dd12fe34686d89c332b1a05104d18d728591f0a ] Before this change, when operating in polled mode, i.e. no IRQ is available, every individual C45 access would be hit with a 150us sleep after the bus access. For example, on a board with a CN9130 SoC connected to an MV88X3310 PHY, a single C45 read would take around 165us: root@infix:~$ mdio f212a600.mdio-mii mmd 4:1 bench 0xc003 Performed 1000 reads in 165ms By replacing the long sleep with a tighter poll loop, we observe a 10x increase in bus throughput: root@infix:~$ mdio f212a600.mdio-mii mmd 4:1 bench 0xc003 Performed 1000 reads in 15ms Signed-off-by: Tobias Waldekranz Reviewed-by: Andrew Lunn Tested-by: Andrew Lunn Link: https://lore.kernel.org/r/20231204100811.2708884-3-tobias@waldekranz.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit de201a8bd54e4df0594cb5982c18bf47eff207ec Author: Hannes Reinecke Date: Wed Nov 29 17:58:31 2023 +0100 scsi: libfc: Fix up timeout error in fc_fcp_rec_error() [ Upstream commit 53122a49f49796beb2c4a1bb702303b66347e29f ] We should set the status to FC_TIMED_OUT when a timeout error is passed to fc_fcp_rec_error(). Signed-off-by: Hannes Reinecke Link: https://lore.kernel.org/r/20231129165832.224100-3-hare@kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 159442593f20443e5274c4d330f467e8bccca571 Author: Hannes Reinecke Date: Wed Nov 29 17:58:30 2023 +0100 scsi: libfc: Don't schedule abort twice [ Upstream commit b57c4db5d23b9df0118a25e2441c9288edd73710 ] The current FC error recovery is sending up to three REC (recovery) frames in 10 second intervals, and as a final step sending an ABTS after 30 seconds for the command itself. Unfortunately sending an ABTS is also the action for the SCSI abort handler, and the default timeout for SCSI commands is also 30 seconds. This causes two ABTS to be scheduled, with the libfc one slightly earlier. The ABTS scheduled by SCSI EH then sees the command to be already aborted, and will always return with a 'GOOD' status irrespective on the actual result from the first ABTS. This causes the SCSI EH abort handler to always succeed, and SCSI EH never to be engaged. Fix this by not issuing an ABTS when a SCSI command is present for the exchange, but rather wait for the abort scheduled from SCSI EH. And warn if an abort is already scheduled to avoid similar errors in the future. Signed-off-by: Hannes Reinecke Link: https://lore.kernel.org/r/20231129165832.224100-2-hare@kernel.org Reviewed-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7409b7e5714dc8e59460b6de50c6c08692b2d1c1 Author: Kang Yang Date: Fri Dec 1 18:09:48 2023 +0200 wifi: ath12k: fix and enable AP mode for WCN7850 [ Upstream commit ed7e818a7b501012038d6bc6fedadaf7375a380a ] For AP mode, the peer is created earlier in ath12k_mac_op_add_interface() but ath12k_mac_op_assign_vif_chanctx() will try to create peer again. Then an error will return which makes AP mode startup fail. Kernel log: [ 5017.665006] ath12k_pci 0000:04:00.0: failed to create peer after vdev start delay: -22 wpa_supplicant log: Failed to set beacon parameters Interface initialization failed wls1: interface state UNINITIALIZED->DISABLED wls1: AP-DISABLED wls1: Unable to setup interface. Failed to initialize AP interface wls1: interface state DISABLED->DISABLED wls1: AP-DISABLED So fix this check and enable AP mode for WCN7850, as now AP mode works normally. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4 Signed-off-by: Kang Yang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231121022459.17209-1-quic_kangyang@quicinc.com Signed-off-by: Sasha Levin commit 776c56ef119a795260021f0608e9a1609832b658 Author: Hou Tao Date: Mon Dec 4 22:04:21 2023 +0800 bpf: Set need_defer as false when clearing fd array during map free [ Upstream commit 79d93b3c6ffd79abcd8e43345980aa1e904879c4 ] Both map deletion operation, map release and map free operation use fd_array_map_delete_elem() to remove the element from fd array and need_defer is always true in fd_array_map_delete_elem(). For the map deletion operation and map release operation, need_defer=true is necessary, because the bpf program, which accesses the element in fd array, may still alive. However for map free operation, it is certain that the bpf program which owns the fd array has already been exited, so setting need_defer as false is appropriate for map free operation. So fix it by adding need_defer parameter to bpf_fd_array_map_clear() and adding a new helper __fd_array_map_delete_elem() to handle the map deletion, map release and map free operations correspondingly. Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20231204140425.1480317-4-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit c7f1b6146f4a46d727c0d046284c28b6882c6304 Author: Hou Tao Date: Mon Dec 4 22:04:19 2023 +0800 bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers [ Upstream commit 169410eba271afc9f0fb476d996795aa26770c6d ] These three bpf_map_{lookup,update,delete}_elem() helpers are also available for sleepable bpf program, so add the corresponding lock assertion for sleepable bpf program, otherwise the following warning will be reported when a sleepable bpf program manipulates bpf map under interpreter mode (aka bpf_jit_enable=0): WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ...... CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:bpf_map_lookup_elem+0x54/0x60 ...... Call Trace: ? __warn+0xa5/0x240 ? bpf_map_lookup_elem+0x54/0x60 ? report_bug+0x1ba/0x1f0 ? handle_bug+0x40/0x80 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1b/0x20 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ? rcu_lockdep_current_cpu_online+0x65/0xb0 ? rcu_is_watching+0x23/0x50 ? bpf_map_lookup_elem+0x54/0x60 ? __pfx_bpf_map_lookup_elem+0x10/0x10 ___bpf_prog_run+0x513/0x3b70 __bpf_prog_run32+0x9d/0xd0 ? __bpf_prog_enter_sleepable_recur+0xad/0x120 ? __bpf_prog_enter_sleepable_recur+0x3e/0x120 bpf_trampoline_6442580665+0x4d/0x1000 __x64_sys_getpgid+0x5/0x30 ? do_syscall_64+0x36/0xb0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20231204140425.1480317-2-houtao@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 5b89a66cde6601eee2ca3760631066d4fb906969 Author: Chih-Kang Chang Date: Wed Nov 29 15:00:46 2023 +0800 wifi: rtw89: fix misbehavior of TX beacon in concurrent mode [ Upstream commit 756b31203d482d2dd1aa6c208978b0410dc7530f ] In concurrent mode, when STA interface is scanning, it causes AP interface TX beacon on wrong channel. We modified it to scan with the operating channel when one of the interfaces is already connected. Additionally, STA interface need to stop scan when AP interface is starting to avoid TX beacon on wrong channel. Finally, AP interface need to stop TX beacon when STA interface is scanning and switching to non-OP channel,This prevent other device to get beacons on wrong channel. Signed-off-by: Chih-Kang Chang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231129070046.18443-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit 4a3650a72daf8c2ae2135eaf398f432ea908fd13 Author: Po-Hao Huang Date: Wed Nov 29 15:00:43 2023 +0800 wifi: rtw89: fix not entering PS mode after AP stops [ Upstream commit 0052b3c401cdf39d3c3d12a0c3852175bc9a39c7 ] The attempt to enter power save mode might fail if there are still beacons pending in the queue. This sometimes happens after stopping P2P GO or AP mode. Extend stop AP function and flush all beacons to resolve this. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231129070046.18443-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit ecb6658d2b8b1947f023cd7ee7e3a7c20b6036e2 Author: Baochen Qiang Date: Fri Nov 17 08:39:19 2023 +0800 wifi: ath11k: fix race due to setting ATH11K_FLAG_EXT_IRQ_ENABLED too early [ Upstream commit 5082b3e3027eae393a4e86874bffb4ce3f83c26e ] We are seeing below error randomly in the case where only one MSI vector is configured: kernel: ath11k_pci 0000:03:00.0: wmi command 16387 timeout The reason is, currently, in ath11k_pcic_ext_irq_enable(), ATH11K_FLAG_EXT_IRQ_ENABLED is set before NAPI is enabled. This results in a race condition: after ATH11K_FLAG_EXT_IRQ_ENABLED is set but before NAPI enabled, CE interrupt breaks in. Since IRQ is shared by CE and data path, ath11k_pcic_ext_interrupt_handler() is also called where we call disable_irq_nosync() to disable IRQ. Then napi_schedule() is called but it does nothing because NAPI is not enabled at that time, meaning ath11k_pcic_ext_grp_napi_poll() will never run, so we have no chance to call enable_irq() to enable IRQ back. Finally we get above error. Fix it by setting ATH11K_FLAG_EXT_IRQ_ENABLED after all NAPI and IRQ work are done. With the fix, we are sure that by the time ATH11K_FLAG_EXT_IRQ_ENABLED is set, NAPI is enabled. Note that the fix above also introduce some side effects: if ath11k_pcic_ext_interrupt_handler() breaks in after NAPI enabled but before ATH11K_FLAG_EXT_IRQ_ENABLED set, nothing will be done by the handler this time, the work will be postponed till the next time the IRQ fires. Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.23 Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231117003919.26218-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit be609c7002dd4504b15b069cb7582f4c778548d1 Author: Minsuk Kang Date: Wed Nov 22 20:31:04 2023 +0200 wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus() [ Upstream commit 2adc886244dff60f948497b59affb6c6ebb3c348 ] Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug occurs when txs->cnt, data from a URB provided by a USB device, is bigger than the size of the array txs->txstatus, which is HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug handling code after the check. Make the function return if that is the case. Found by a modified version of syzkaller. UBSAN: array-index-out-of-bounds in htc_drv_txrx.c index 13 is out of range for type '__wmi_event_txstatus [12]' Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt Signed-off-by: Minsuk Kang Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231113065756.1491991-1-linuxlovemin@yonsei.ac.kr Signed-off-by: Sasha Levin commit 58bb568d03eb21adcdb1c6902f2e6a1ef1feedd6 Author: Yonghong Song Date: Sun Nov 26 21:03:42 2023 -0800 bpf: Fix a few selftest failures due to llvm18 change [ Upstream commit b16904fd9f01b580db357ef2b1cc9e86d89576c2 ] With latest upstream llvm18, the following test cases failed: $ ./test_progs -j #13/2 bpf_cookie/multi_kprobe_link_api:FAIL #13/3 bpf_cookie/multi_kprobe_attach_api:FAIL #13 bpf_cookie:FAIL #77 fentry_fexit:FAIL #78/1 fentry_test/fentry:FAIL #78 fentry_test:FAIL #82/1 fexit_test/fexit:FAIL #82 fexit_test:FAIL #112/1 kprobe_multi_test/skel_api:FAIL #112/2 kprobe_multi_test/link_api_addrs:FAIL [...] #112 kprobe_multi_test:FAIL #356/17 test_global_funcs/global_func17:FAIL #356 test_global_funcs:FAIL Further analysis shows llvm upstream patch [1] is responsible for the above failures. For example, for function bpf_fentry_test7() in net/bpf/test_run.c, without [1], the asm code is: 0000000000000400 : 400: f3 0f 1e fa endbr64 404: e8 00 00 00 00 callq 0x409 409: 48 89 f8 movq %rdi, %rax 40c: c3 retq 40d: 0f 1f 00 nopl (%rax) ... and with [1], the asm code is: 0000000000005d20 : 5d20: e8 00 00 00 00 callq 0x5d25 5d25: c3 retq ... and is called instead of and this caused test failures for #13/#77 etc. except #356. For test case #356/17, with [1] (progs/test_global_func17.c)), the main prog looks like: 0000000000000000 : 0: b4 00 00 00 2a 00 00 00 w0 = 0x2a 1: 95 00 00 00 00 00 00 00 exit ... which passed verification while the test itself expects a verification failure. Let us add 'barrier_var' style asm code in both places to prevent function specialization which caused selftests failure. [1] https://github.com/llvm/llvm-project/pull/72903 Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20231127050342.1945270-1-yonghong.song@linux.dev Signed-off-by: Sasha Levin commit 6c17bbe101fee8795af0910da52b0336b0e25d8e Author: Alexander Stein Date: Thu Oct 12 10:15:55 2023 +0200 ARM: dts: imx7s: Fix nand-controller #size-cells [ Upstream commit 4aadb841ed49bada1415c48c44d21f5b69e01299 ] nand-controller.yaml bindings says #size-cells shall be set to 0. Fixes the dtbs_check warning: arch/arm/boot/dts/nxp/imx/imx7s-mba7.dtb: nand-controller@33002000: #size-cells:0:0: 0 was expected from schema $id: http://devicetree.org/schemas/mtd/gpmi-nand.yaml# Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 7d8ccfc60738ccfd66b5871c76dfe995f3722e5c Author: Alexander Stein Date: Thu Oct 12 10:15:54 2023 +0200 ARM: dts: imx7s: Fix lcdif compatible [ Upstream commit 5f55da4cc37051cda600ea870ce8cf29f1297715 ] imx7d-lcdif is compatible to imx6sx-lcdif. MXSFB_V6 supports overlay by using LCDC_AS_CTRL register. This registers used by overlay plane: * LCDC_AS_CTRL * LCDC_AS_BUF * LCDC_AS_NEXT_BUF are listed in i.MX7D RM as well. Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8dbbdb56ee5d2a68b0bf05024a1903d62233f0d6 Author: Alexander Stein Date: Thu Oct 12 10:15:53 2023 +0200 ARM: dts: imx7d: Fix coresight funnel ports [ Upstream commit 0d4ac04fa7c3f6dc263dba6f575a2ec7a2d4eca8 ] imx7d uses two ports for 'in-ports', so the syntax port@ has to be used. imx7d has both port and port@1 nodes present, raising these error: funnel@30041000: in-ports: More than one condition true in oneOf schema funnel@30041000: Unevaluated properties are not allowed ('in-ports' was unexpected) Fix this by also using port@0 for imx7s as well. Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit ef015ff14fc285b69338f2a0eda40db0cb40b446 Author: ching Huang Date: Mon Oct 2 17:50:27 2023 +0800 scsi: arcmsr: Support new PCI device IDs 1883 and 1886 [ Upstream commit 41c8a1a1e90fa4721f856bf3cf71211fd16d6434 ] Add support for Areca RAID controllers with PCI device IDs 1883 and 1886. Signed-off-by: ching Huang Link: https://lore.kernel.org/r/7732e743eaad57681b1552eec9c6a86c76dbe459.camel@areca.com.tw Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 352ad5001b86b84466574b1e60c22ca7e68a47a3 Author: Sumit Saxena Date: Thu Nov 23 21:31:29 2023 +0530 scsi: mpi3mr: Add PCI checks where SAS5116 diverges from SAS4116 [ Upstream commit c9260ff28ee561fca5f96425c9328a9698e8427b ] Add PCI IDs checks for the cases where SAS5116 diverges from SAS4116 in behavior. Signed-off-by: Sumit Saxena Link: https://lore.kernel.org/r/20231123160132.4155-3-sumit.saxena@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit aca1b66eb75e9e67df372398f1b4fa7058c08b5c Author: Sumit Saxena Date: Thu Nov 23 21:31:28 2023 +0530 scsi: mpi3mr: Add support for SAS5116 PCI IDs [ Upstream commit 6fa21eab82be57a3ad2470fac27b982793805336 ] Add support for Broadcom's SAS5116 IO/RAID controllers PCI IDs. Signed-off-by: Sumit Saxena Link: https://lore.kernel.org/r/20231123160132.4155-2-sumit.saxena@broadcom.com Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3348afa20eeec49cf6ca98a18e4d26d94f263185 Author: Jose Ignacio Tornos Martinez Date: Mon Nov 20 13:11:41 2023 +0100 net: usb: ax88179_178a: avoid two consecutive device resets [ Upstream commit d2689b6a86b9d23574bd4b654bf770b6034e2c7e ] The device is always reset two consecutive times (ax88179_reset is called twice), one from usbnet_probe during the device binding and the other from usbnet_open. Remove the non-necessary reset during the device binding and let the reset operation from open to keep the normal behavior (tested with generic ASIX Electronics Corp. AX88179 Gigabit Ethernet device). Reported-by: Herb Wei Tested-by: Herb Wei Signed-off-by: Jose Ignacio Tornos Martinez Link: https://lore.kernel.org/r/20231120121239.54504-1-jtornosm@redhat.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 00359cf5217a51ecdc540c03bc7e28d779b27d4a Author: Zhengchao Shao Date: Sat Nov 18 16:16:53 2023 +0800 bonding: return -ENOMEM instead of BUG in alb_upper_dev_walk [ Upstream commit d6b83f1e3707c4d60acfa58afd3515e17e5d5384 ] If failed to allocate "tags" or could not find the final upper device from start_dev's upper list in bond_verify_device_path(), only the loopback detection of the current upper device should be affected, and the system is no need to be panic. So return -ENOMEM in alb_upper_dev_walk to stop walking, print some warn information when failed to allocate memory for vlan tags in bond_verify_device_path. I also think that the following function calls netdev_walk_all_upper_dev_rcu ---->>>alb_upper_dev_walk ---------->>>bond_verify_device_path From this way, "end device" can eventually be obtained from "start device" in bond_verify_device_path, IS_ERR(tags) could be instead of IS_ERR_OR_NULL(tags) in alb_upper_dev_walk. Signed-off-by: Zhengchao Shao Acked-by: Jay Vosburgh Link: https://lore.kernel.org/r/20231118081653.1481260-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 6b0e5ba96f8f962a8651ec8b82ce9575eded277d Author: Ido Schimmel Date: Wed Nov 15 13:17:16 2023 +0100 PCI: Add no PM reset quirk for NVIDIA Spectrum devices [ Upstream commit 3ed48c80b28d8dcd584d6ddaf00c75b7673e1a05 ] Spectrum-{1,2,3,4} devices report that a D3hot->D0 transition causes a reset (i.e., they advertise NoSoftRst-). However, this transition does not have any effect on the device: It continues to be operational and network ports remain up. Advertising this support makes it seem as if a PM reset is viable for these devices. Mark it as unavailable to skip it when testing reset methods. Before: # cat /sys/bus/pci/devices/0000\:03\:00.0/reset_method pm bus After: # cat /sys/bus/pci/devices/0000\:03\:00.0/reset_method bus Signed-off-by: Ido Schimmel Acked-by: Bjorn Helgaas Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af13b0b12ada31250124f2110e4cb11f86f37fcd Author: Kory Maincent Date: Tue Nov 14 12:28:34 2023 +0100 net: phy: micrel: fix ts_info value in case of no phc [ Upstream commit 915d25a9d69be969c1cc6c1dd0c3861f6da7b55e ] In case of no phc we should not return SOFTWARE TIMESTAMPING flags as we do not know whether the netdev supports of timestamping. Remove it from the lan8841_ts_info and simply return 0. Signed-off-by: Kory Maincent Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 99b1d9f5fedc03df64c959628063cf97c16eef10 Author: Krzysztof Kozlowski Date: Sat Jul 22 14:17:19 2023 +0200 ARM: dts: samsung: s5pv210: fix camera unit addresses/ranges [ Upstream commit 07e6a553c2f1d385edfc9185081dee442a9dd38d ] The camera node has both unit address and children within the same bus mapping, thus needs proper ranges property to fix dtc W=1 warnings: Warning (unit_address_vs_reg): /soc/camera@fa600000: node has a unit name, but no reg or ranges property Warning (simple_bus_reg): /soc/camera@fa600000: missing or empty reg/ranges property Subtract 0xfa600000 from all its children nodes. No functional impact expected. Link: https://lore.kernel.org/r/20230722121719.150094-3-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit c32eda9872dfe999b2948f63bd58f1d38fa64aac Author: Krzysztof Kozlowski Date: Sat Jul 22 14:17:18 2023 +0200 ARM: dts: samsung: exynos4: fix camera unit addresses/ranges [ Upstream commit ba2a45a48503665f7e8eeec51f8b40456566b0cd ] The camera node has both unit address and children within the same bus mapping, thus needs proper ranges property to fix dtc W=1 warnings: Warning (unit_address_vs_reg): /soc/camera@11800000: node has a unit name, but no reg or ranges property Warning (simple_bus_reg): /soc/camera@11800000: missing or empty reg/ranges property Subtract 0x11800000 from all its children nodes. No functional impact expected. Link: https://lore.kernel.org/r/20230722121719.150094-2-krzysztof.kozlowski@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit afcaecba1c4c2719b6cd323957bce77c88e19401 Author: Justin Tee Date: Tue Oct 31 12:12:17 2023 -0700 scsi: lpfc: Fix possible file string name overflow when updating firmware [ Upstream commit f5779b529240b715f0e358489ad0ed933bf77c97 ] Because file_name and phba->ModelName are both declared a size 80 bytes, the extra ".grp" file extension could cause an overflow into file_name. Define a ELX_FW_NAME_SIZE macro with value 84. 84 incorporates the 4 extra characters from ".grp". file_name is changed to be declared as a char and initialized to zeros i.e. null chars. Signed-off-by: Justin Tee Link: https://lore.kernel.org/r/20231031191224.150862-3-justintee8345@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1aab60bb9c203f7723cc23ad262d63420791293f Author: Tanmay Shah Date: Fri Oct 27 23:53:59 2023 +0530 soc: xilinx: fix unhandled SGI warning message [ Upstream commit 9c6724abf969251af53cdae525ad8100ec78d3c2 ] Xen broadcasts SGI to each VM when multiple VMs run on Xen hypervisor. In such case spurious SGI is expected if one event is registered by one VM and not registered by another VM. We let users know that Unhandled SGI is not error and expected if kernel is running on Xen hypervisor. Signed-off-by: Tanmay Shah Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1698431039-2734260-1-git-send-email-radhey.shyam.pandey@amd.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit 548bdbbdcd355f5a844c7122c83c9aab115051fa Author: HariBabu Gattem Date: Thu Oct 26 22:56:22 2023 -0700 soc: xilinx: Fix for call trace due to the usage of smp_processor_id() [ Upstream commit daed80ed07580e5adc0e6d8bc79933a35154135a ] When preemption is enabled in kernel and if any task which can be preempted should not use smp_processor_id() directly, since CPU switch can happen at any time, the previous value of cpu_id differs with current cpu_id. As a result we see the below call trace during xlnx_event_manager_probe. [ 6.140197] dump_backtrace+0x0/0x190 [ 6.143884] show_stack+0x18/0x40 [ 6.147220] dump_stack_lvl+0x7c/0xa0 [ 6.150907] dump_stack+0x18/0x34 [ 6.154241] check_preemption_disabled+0x124/0x134 [ 6.159068] debug_smp_processor_id+0x20/0x2c [ 6.163453] xlnx_event_manager_probe+0x48/0x250 To protect cpu_id, It is recommended to use get_cpu()/put_cpu() to disable preemption, get the cpu_id and enable preemption respectively. (For Reference, Documentation/locking/preempt-locking.rst and Documentation/kernel-hacking/hacking.rst) Use preempt_disable()/smp_processor_id()/preempt_enable() API's to achieve the same. Signed-off-by: HariBabu Gattem Signed-off-by: Jay Buddhabhatti Link: https://lore.kernel.org/r/20231027055622.21544-1-jay.buddhabhatti@amd.com Signed-off-by: Michal Simek Signed-off-by: Sasha Levin commit f6d841f154edf003ea2ed893fac7bbbe6f841767 Author: Dmitry Baryshkov Date: Thu Sep 28 14:02:43 2023 +0300 ARM: dts: qcom: msm8660: fix PMIC node labels [ Upstream commit c6d86aa8a12194d1c9c2f9108910a46c8a3ddc90 ] Change PM8058 node labels to start with pm8058_ prefix, following other Qualcomm PMIC device nodes. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20230928110309.1212221-11-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7caed5e2a46db720802e15493c6bd5861f7807bf Author: Dmitry Baryshkov Date: Thu Sep 28 14:02:42 2023 +0300 ARM: dts: qcom: mdm9615: fix PMIC node labels [ Upstream commit 0e4688cd4ee6efbeae2b31f75e16961fd7f72735 ] Change PM8018 node labels to start with pm8018_ prefix, following other Qualcomm PMIC device nodes. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20230928110309.1212221-10-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 33e3cb41bed4d4cc6a2b522f64f328aa0361454f Author: Dmitry Baryshkov Date: Thu Sep 28 14:02:40 2023 +0300 ARM: dts: qcom: strip prefix from PMIC files [ Upstream commit 455a4c46e023ab84263eae0fc7acca9a5ee8b7ac ] As the vendor DTS files were moved to per-vendor subdirs, there no need to use common prefixes. Drop the `qcom-' prefix from PMIC dtsi file. This makes 32-bit qcom/ dts files closer to arm64 ones. Reviewed-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20230928110309.1212221-8-dmitry.baryshkov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 9d2aac117d11d7ab6ca503a04ad03e73e100839b Author: Yafang Shao Date: Sat Nov 11 09:00:30 2023 +0000 selftests/bpf: Fix issues in setup_classid_environment() [ Upstream commit 4849775587844e44d215289c425bcd70f315efe7 ] If the net_cls subsystem is already mounted, attempting to mount it again in setup_classid_environment() will result in a failure with the error code EBUSY. Despite this, tmpfs will have been successfully mounted at /sys/fs/cgroup/net_cls. Consequently, the /sys/fs/cgroup/net_cls directory will be empty, causing subsequent setup operations to fail. Here's an error log excerpt illustrating the issue when net_cls has already been mounted at /sys/fs/cgroup/net_cls prior to running setup_classid_environment(): - Before that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 test_cgroup_v1v2:PASS:server_fd 0 nsec test_cgroup_v1v2:PASS:client_fd 0 nsec test_cgroup_v1v2:PASS:cgroup_fd 0 nsec test_cgroup_v1v2:PASS:server_fd 0 nsec run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec test_cgroup_v1v2:PASS:cgroup-v2-only 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs (cgroup_helpers.c:540: errno: No such file or directory) Opening cgroup classid: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/net_cls.classid run_test:PASS:skel_open 0 nsec run_test:PASS:prog_attach 0 nsec (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup-test-work-dir/cgroup.procs run_test:FAIL:join_classid unexpected error: 1 (errno 2) test_cgroup_v1v2:FAIL:cgroup-v1v2 unexpected error: -1 (errno 2) (cgroup_helpers.c:248: errno: No such file or directory) Opening Cgroup Procs: /sys/fs/cgroup/net_cls/cgroup.procs #44 cgroup_v1v2:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED - After that change $ tools/testing/selftests/bpf/test_progs --name=cgroup_v1v2 #44 cgroup_v1v2:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Signed-off-by: Yafang Shao Link: https://lore.kernel.org/r/20231111090034.4248-3-laoar.shao@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 3eb0fff7fbbf2d33959b1a65e439710ce619b894 Author: Shiji Yang Date: Thu Nov 9 12:38:51 2023 +0800 wifi: rt2x00: correct wrong BBP register in RxDCOC calibration [ Upstream commit 50da74e1e8b682853d1e07fc8bbe3a0774ae5e09 ] Refer to Mediatek vendor driver RxDCOC_Calibration() function, when performing gainfreeze calibration, we should write register 140 instead of 141. This fix can reduce the total calibration time from 6 seconds to 1 second. Signed-off-by: Shiji Yang Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/TYAP286MB0315B13B89DF57B6B27BB854BCAFA@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Sasha Levin commit 3135c3c05487fbd0917212c537e2bcff4a789edf Author: Yonghong Song Date: Fri Nov 10 11:36:44 2023 -0800 selftests/bpf: Fix pyperf180 compilation failure with clang18 [ Upstream commit 100888fb6d8a185866b1520031ee7e3182b173de ] With latest clang18 (main branch of llvm-project repo), when building bpf selftests, [~/work/bpf-next (master)]$ make -C tools/testing/selftests/bpf LLVM=1 -j The following compilation error happens: fatal error: error in backend: Branch target out of insn range ... Stack dump: 0. Program arguments: clang -g -Wall -Werror -D__TARGET_ARCH_x86 -mlittle-endian -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf/tools/include -I/home/yhs/work/bpf-next/tools/testing/selftests/bpf -I/home/yhs/work/bpf-next/tools/include/uapi -I/home/yhs/work/bpf-next/tools/testing/selftests/usr/include -idirafter /home/yhs/work/llvm-project/llvm/build.18/install/lib/clang/18/include -idirafter /usr/local/include -idirafter /usr/include -Wno-compare-distinct-pointer-types -DENABLE_ATOMICS_TESTS -O2 --target=bpf -c progs/pyperf180.c -mcpu=v3 -o /home/yhs/work/bpf-next/tools/testing/selftests/bpf/pyperf180.bpf.o 1. parser at end of file 2. Code generation ... The compilation failure only happens to cpu=v2 and cpu=v3. cpu=v4 is okay since cpu=v4 supports 32-bit branch target offset. The above failure is due to upstream llvm patch [1] where some inlining behavior are changed in clang18. To workaround the issue, previously all 180 loop iterations are fully unrolled. The bpf macro __BPF_CPU_VERSION__ (implemented in clang18 recently) is used to avoid unrolling changes if cpu=v4. If __BPF_CPU_VERSION__ is not available and the compiler is clang18, the unrollng amount is unconditionally reduced. [1] https://github.com/llvm/llvm-project/commit/1a2e77cf9e11dbf56b5720c607313a566eebb16e Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Tested-by: Alan Maguire Link: https://lore.kernel.org/bpf/20231110193644.3130906-1-yonghong.song@linux.dev Signed-off-by: Sasha Levin commit ccc125e4ba6be211d6fd5fcc9ff2d5d00c2a8835 Author: Yonghong Song Date: Tue Nov 7 12:15:11 2023 -0800 libbpf: Fix potential uninitialized tail padding with LIBBPF_OPTS_RESET [ Upstream commit 7f7c43693c1b46652cfafb7af67ba31726d6ec4e ] Martin reported that there is a libbpf complaining of non-zero-value tail padding with LIBBPF_OPTS_RESET macro if struct bpf_netkit_opts is modified to have a 4-byte tail padding. This only happens to clang compiler. The commend line is: ./test_progs -t tc_netkit_multi_links Martin and I did some investigation and found this indeed the case and the following are the investigation details. Clang: clang version 18.0.0 tools/lib/bpf/libbpf_common.h: #define LIBBPF_OPTS_RESET(NAME, ...) \ do { \ memset(&NAME, 0, sizeof(NAME)); \ NAME = (typeof(NAME)) { \ .sz = sizeof(NAME), \ __VA_ARGS__ \ }; \ } while (0) #endif tools/lib/bpf/libbpf.h: struct bpf_netkit_opts { /* size of this struct, for forward/backward compatibility */ size_t sz; __u32 flags; __u32 relative_fd; __u32 relative_id; __u64 expected_revision; size_t :0; }; #define bpf_netkit_opts__last_field expected_revision In the above struct bpf_netkit_opts, there is no tail padding. prog_tests/tc_netkit.c: static void serial_test_tc_netkit_multi_links_target(int mode, int target) { ... LIBBPF_OPTS(bpf_netkit_opts, optl); ... LIBBPF_OPTS_RESET(optl, .flags = BPF_F_BEFORE, .relative_fd = bpf_program__fd(skel->progs.tc1), ); ... } Let us make the following source change, note that we have a 4-byte tailing padding now. # diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h # index 6cd9c501624f..0dd83910ae9a 100644 # --- a/tools/lib/bpf/libbpf.h # +++ b/tools/lib/bpf/libbpf.h # @@ -803,13 +803,13 @@ bpf_program__attach_tcx(const struct bpf_program *prog, int ifindex, # struct bpf_netkit_opts { # /* size of this struct, for forward/backward compatibility */ # size_t sz; # - __u32 flags; # __u32 relative_fd; # __u32 relative_id; # __u64 expected_revision; # + __u32 flags; # size_t :0; # }; # -#define bpf_netkit_opts__last_field expected_revision # +#define bpf_netkit_opts__last_field flags The clang 18 generated asm code looks like below: ; LIBBPF_OPTS_RESET(optl, 55e3: 48 8d 7d 98 leaq -0x68(%rbp), %rdi 55e7: 31 f6 xorl %esi, %esi 55e9: ba 20 00 00 00 movl $0x20, %edx 55ee: e8 00 00 00 00 callq 0x55f3 55f3: 48 c7 85 10 fd ff ff 20 00 00 00 movq $0x20, -0x2f0(%rbp) 55fe: 48 8b 85 68 ff ff ff movq -0x98(%rbp), %rax 5605: 48 8b 78 18 movq 0x18(%rax), %rdi 5609: e8 00 00 00 00 callq 0x560e 560e: 89 85 18 fd ff ff movl %eax, -0x2e8(%rbp) 5614: c7 85 1c fd ff ff 00 00 00 00 movl $0x0, -0x2e4(%rbp) 561e: 48 c7 85 20 fd ff ff 00 00 00 00 movq $0x0, -0x2e0(%rbp) 5629: c7 85 28 fd ff ff 08 00 00 00 movl $0x8, -0x2d8(%rbp) 5633: 48 8b 85 10 fd ff ff movq -0x2f0(%rbp), %rax 563a: 48 89 45 98 movq %rax, -0x68(%rbp) 563e: 48 8b 85 18 fd ff ff movq -0x2e8(%rbp), %rax 5645: 48 89 45 a0 movq %rax, -0x60(%rbp) 5649: 48 8b 85 20 fd ff ff movq -0x2e0(%rbp), %rax 5650: 48 89 45 a8 movq %rax, -0x58(%rbp) 5654: 48 8b 85 28 fd ff ff movq -0x2d8(%rbp), %rax 565b: 48 89 45 b0 movq %rax, -0x50(%rbp) ; link = bpf_program__attach_netkit(skel->progs.tc2, ifindex, &optl); At -O0 level, the clang compiler creates an intermediate copy. We have below to store 'flags' with 4-byte store and leave another 4 byte in the same 8-byte-aligned storage undefined, 5629: c7 85 28 fd ff ff 08 00 00 00 movl $0x8, -0x2d8(%rbp) and later we store 8-byte to the original zero'ed buffer 5654: 48 8b 85 28 fd ff ff movq -0x2d8(%rbp), %rax 565b: 48 89 45 b0 movq %rax, -0x50(%rbp) This caused a problem as the 4-byte value at [%rbp-0x2dc, %rbp-0x2e0) may be garbage. gcc (gcc 11.4) does not have this issue as it does zeroing struct first before doing assignments: ; LIBBPF_OPTS_RESET(optl, 50fd: 48 8d 85 40 fc ff ff leaq -0x3c0(%rbp), %rax 5104: ba 20 00 00 00 movl $0x20, %edx 5109: be 00 00 00 00 movl $0x0, %esi 510e: 48 89 c7 movq %rax, %rdi 5111: e8 00 00 00 00 callq 0x5116 5116: 48 8b 45 f0 movq -0x10(%rbp), %rax 511a: 48 8b 40 18 movq 0x18(%rax), %rax 511e: 48 89 c7 movq %rax, %rdi 5121: e8 00 00 00 00 callq 0x5126 5126: 48 c7 85 40 fc ff ff 00 00 00 00 movq $0x0, -0x3c0(%rbp) 5131: 48 c7 85 48 fc ff ff 00 00 00 00 movq $0x0, -0x3b8(%rbp) 513c: 48 c7 85 50 fc ff ff 00 00 00 00 movq $0x0, -0x3b0(%rbp) 5147: 48 c7 85 58 fc ff ff 00 00 00 00 movq $0x0, -0x3a8(%rbp) 5152: 48 c7 85 40 fc ff ff 20 00 00 00 movq $0x20, -0x3c0(%rbp) 515d: 89 85 48 fc ff ff movl %eax, -0x3b8(%rbp) 5163: c7 85 58 fc ff ff 08 00 00 00 movl $0x8, -0x3a8(%rbp) ; link = bpf_program__attach_netkit(skel->progs.tc2, ifindex, &optl); It is not clear how to resolve the compiler code generation as the compiler generates correct code w.r.t. how to handle unnamed padding in C standard. So this patch changed LIBBPF_OPTS_RESET macro to avoid uninitialized tail padding. We already knows LIBBPF_OPTS macro works on both gcc and clang, even with tail padding. So LIBBPF_OPTS_RESET is changed to be a LIBBPF_OPTS followed by a memcpy(), thus avoiding uninitialized tail padding. The below is asm code generated with this patch and with clang compiler: ; LIBBPF_OPTS_RESET(optl, 55e3: 48 8d bd 10 fd ff ff leaq -0x2f0(%rbp), %rdi 55ea: 31 f6 xorl %esi, %esi 55ec: ba 20 00 00 00 movl $0x20, %edx 55f1: e8 00 00 00 00 callq 0x55f6 55f6: 48 c7 85 10 fd ff ff 20 00 00 00 movq $0x20, -0x2f0(%rbp) 5601: 48 8b 85 68 ff ff ff movq -0x98(%rbp), %rax 5608: 48 8b 78 18 movq 0x18(%rax), %rdi 560c: e8 00 00 00 00 callq 0x5611 5611: 89 85 18 fd ff ff movl %eax, -0x2e8(%rbp) 5617: c7 85 1c fd ff ff 00 00 00 00 movl $0x0, -0x2e4(%rbp) 5621: 48 c7 85 20 fd ff ff 00 00 00 00 movq $0x0, -0x2e0(%rbp) 562c: c7 85 28 fd ff ff 08 00 00 00 movl $0x8, -0x2d8(%rbp) 5636: 48 8b 85 10 fd ff ff movq -0x2f0(%rbp), %rax 563d: 48 89 45 98 movq %rax, -0x68(%rbp) 5641: 48 8b 85 18 fd ff ff movq -0x2e8(%rbp), %rax 5648: 48 89 45 a0 movq %rax, -0x60(%rbp) 564c: 48 8b 85 20 fd ff ff movq -0x2e0(%rbp), %rax 5653: 48 89 45 a8 movq %rax, -0x58(%rbp) 5657: 48 8b 85 28 fd ff ff movq -0x2d8(%rbp), %rax 565e: 48 89 45 b0 movq %rax, -0x50(%rbp) ; link = bpf_program__attach_netkit(skel->progs.tc2, ifindex, &optl); In the above code, a temporary buffer is zeroed and then has proper value assigned. Finally, values in temporary buffer are copied to the original variable buffer, hence tail padding is guaranteed to be 0. Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Tested-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20231107201511.2548645-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 8de7f5f1363b108c0d4e9914963ec3e956ad4763 Author: Andrii Nakryiko Date: Wed Nov 1 20:37:44 2023 -0700 selftests/bpf: satisfy compiler by having explicit return in btf test [ Upstream commit f4c7e887324f5776eef6e6e47a90e0ac8058a7a8 ] Some compilers complain about get_pprint_mapv_size() not returning value in some code paths. Fix with explicit return. Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20231102033759.2541186-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 31e03eaa4820679f8f1cb83d21bd55501df5c990 Author: Andrii Nakryiko Date: Wed Nov 1 20:37:43 2023 -0700 selftests/bpf: fix RELEASE=1 build for tc_opts [ Upstream commit 2b62aa59d02ed281fa4fc218df3ca91b773e1e62 ] Compiler complains about malloc(). We also don't need to dynamically allocate anything, so make the life easier by using statically sized buffer. Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20231102033759.2541186-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit fdb580ed05df8973aa5149cafa598c64bebcd0cb Author: Shiji Yang Date: Sat Nov 4 16:58:00 2023 +0800 wifi: rt2x00: restart beacon queue when hardware reset [ Upstream commit a11d965a218f0cd95b13fe44d0bcd8a20ce134a8 ] When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw(). Signed-off-by: Shiji Yang Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/TYAP286MB031530EB6D98DCE4DF20766CBCA4A@TYAP286MB0315.JPNP286.PROD.OUTLOOK.COM Signed-off-by: Sasha Levin commit c039cda8d878522d8ea823b424b7ee4d863d4ee1 Author: Dmitry Antipov Date: Tue Oct 24 17:31:33 2023 +0300 wifi: rtw89: fix timeout calculation in rtw89_roc_end() [ Upstream commit e416514e309f7e25e577fee45a65f246f67b2261 ] Since 'rtw89_core_tx_kick_off_and_wait()' assumes timeout (actually RTW89_ROC_TX_TIMEOUT) in milliseconds, I suppose that RTW89_ROC_IDLE_TIMEOUT is in milliseconds as well. If so, 'msecs_to_jiffies()' should be used in a call to 'ieee80211_queue_delayed_work()' from 'rtw89_roc_end()'. Compile tested only. Signed-off-by: Dmitry Antipov Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20231024143137.30393-1-dmantipov@yandex.ru Signed-off-by: Sasha Levin commit dc3e0f55bec4410f3d74352c4a7c79f518088ee2 Author: Baokun Li Date: Mon Oct 23 09:30:56 2023 +0800 ext4: avoid online resizing failures due to oversized flex bg [ Upstream commit 5d1935ac02ca5aee364a449a35e2977ea84509b0 ] When we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16G the following WARN_ON is triggered: ================================================================== WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550 Modules linked in: sg(E) CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314 RIP: 0010:__alloc_pages+0x411/0x550 Call Trace: __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90 ================================================================== This is because flexbg_size is too large and the size of the new_group_data array to be allocated exceeds MAX_ORDER. Currently, the minimum value of MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding maximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845 And the value that is down-aligned to the power of 2 is 16384. Therefore, this value is defined as MAX_RESIZE_BG, and the number of groups added each time does not exceed this value during resizing, and is added multiple times to complete the online resizing. The difference is that the metadata in a flex_bg may be more dispersed. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20231023013057.2117948-4-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4b07b03d24ff462ea8e1251a1674c8f85fda56e7 Author: Baokun Li Date: Mon Oct 23 09:30:55 2023 +0800 ext4: remove unnecessary check from alloc_flex_gd() [ Upstream commit b099eb87de105cf07cad731ded6fb40b2675108b ] In commit 967ac8af4475 ("ext4: fix potential integer overflow in alloc_flex_gd()"), an overflow check is added to alloc_flex_gd() to prevent the allocated memory from being smaller than expected due to the overflow. However, after kmalloc() is replaced with kmalloc_array() in commit 6da2ec56059c ("treewide: kmalloc() -> kmalloc_array()"), the kmalloc_array() function has an overflow check, so the above problem will not occur. Therefore, the extra check is removed. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20231023013057.2117948-3-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Stable-dep-of: 5d1935ac02ca ("ext4: avoid online resizing failures due to oversized flex bg") Signed-off-by: Sasha Levin commit 3ea824b924b908cb79caea4e732e646332f8ae35 Author: Baokun Li Date: Mon Oct 23 09:30:54 2023 +0800 ext4: unify the type of flexbg_size to unsigned int [ Upstream commit 658a52344fb139f9531e7543a6e0015b630feb38 ] The maximum value of flexbg_size is 2^31, but the maximum value of int is (2^31 - 1), so overflow may occur when the type of flexbg_size is declared as int. For example, when uninit_mask is initialized in ext4_alloc_group_tables(), if flexbg_size == 2^31, the initialized uninit_mask is incorrect, and this may causes set_flexbg_block_bitmap() to trigger a BUG_ON(). Therefore, the flexbg_size type is declared as unsigned int to avoid overflow and memory waste. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20231023013057.2117948-2-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Stable-dep-of: 5d1935ac02ca ("ext4: avoid online resizing failures due to oversized flex bg") Signed-off-by: Sasha Levin commit e623f147c8525199878cfacf9de7a0aac8d8fa0d Author: Ye Bin Date: Sat Dec 16 09:09:19 2023 +0800 ext4: fix inconsistent between segment fstrim and full fstrim [ Upstream commit 68da4c44b994aea797eb9821acb3a4a36015293e ] Suppose we issue two FITRIM ioctls for ranges [0,15] and [16,31] with mininum length of trimmed range set to 8 blocks. If we have say a range of blocks 10-22 free, this range will not be trimmed because it straddles the boundary of the two FITRIM ranges and neither part is big enough. This is a bit surprising to some users that call FITRIM on smaller ranges of blocks to limit impact on the system. Also XFS trims all free space extents that overlap with the specified range so we are inconsistent among filesystems. Let's change ext4_try_to_trim_range() to consider for trimming the whole free space extent that straddles the end of specified range, not just the part of it within the range. Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20231216010919.1995851-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 69a23d44008aa0b85773d82c9b00993685738cd7 Author: Gabriel Krisman Bertazi Date: Fri Aug 11 14:38:12 2023 -0400 ecryptfs: Reject casefold directory inodes [ Upstream commit cd72c7ef5fed44272272a105b1da22810c91be69 ] Even though it seems to be able to resolve some names of case-insensitive directories, the lack of d_hash and d_compare means we end up with a broken state in the d_cache. Considering it was never a goal to support these two together, and we are preparing to use d_revalidate in case-insensitive filesystems, which would make the combination even more broken, reject any attempt to get a casefolded inode from ecryptfs. Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Eric Biggers Signed-off-by: Sasha Levin commit 3fee2dd3a30ee7b23b3ca741ca02b416877d6e8f Author: Shyam Prasad N Date: Fri Dec 29 11:16:18 2023 +0000 cifs: fix in logging in cifs_chan_update_iface [ Upstream commit 516eea97f92f1e7271f20835cfe9e73774b0f8cc ] Recently, cifs_chan_update_iface was modified to not remove an iface if a suitable replacement was not found. With that, there were two conditionals that were exactly the same. This change removes that extra condition check. Also, fixed a logging in the same function to indicate the correct message. Signed-off-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d6e541105ccaf05ab0bd694332e0cd8bcd324891 Author: Paulo Alcantara Date: Sat Nov 25 23:55:07 2023 -0300 smb: client: fix hardlinking of reparse points [ Upstream commit 5408990aa662bcfd6ba894734023a023a16e8729 ] The client was sending an SMB2_CREATE request without setting OPEN_REPARSE_POINT flag thus failing the entire hardlink operation. Fix this by setting OPEN_REPARSE_POINT in create options for SMB2_CREATE request when the source inode is a repase point. Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c699a983def5d6a7c3ac16d16bd831d37934a86f Author: Paulo Alcantara Date: Sat Nov 25 23:55:06 2023 -0300 smb: client: fix renaming of reparse points [ Upstream commit 7435d51b7ea2ab7801279c43ecd72063e9d5c92f ] The client was sending an SMB2_CREATE request without setting OPEN_REPARSE_POINT flag thus failing the entire rename operation. Fix this by setting OPEN_REPARSE_POINT in create options for SMB2_CREATE request when the source inode is a repase point. Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit aafac00a0423531d6a1417ecfe780c28b8214500 Author: Ojaswin Mujoo Date: Wed Nov 1 22:08:10 2023 +0530 ext4: treat end of range as exclusive in ext4_zero_range() [ Upstream commit 92573369144f40397e8514440afdf59f24905b40 ] The call to filemap_write_and_wait_range() assumes the range passed to be inclusive, so fix the call to make sure we follow that. Signed-off-by: Ojaswin Mujoo Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/e503107a7c73a2b68dec645c5ad798c437717c45.1698856309.git.ojaswin@linux.ibm.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 8f860c8407470baff2beb9982ad6b172c94f1d0a Author: Anna Schumaker Date: Mon Nov 27 17:06:18 2023 -0500 SUNRPC: Fix a suspicious RCU usage warning [ Upstream commit 31b62908693c90d4d07db597e685d9f25a120073 ] I received the following warning while running cthon against an ontap server running pNFS: [ 57.202521] ============================= [ 57.202522] WARNING: suspicious RCU usage [ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted [ 57.202525] ----------------------------- [ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!! [ 57.202527] other info that might help us debug this: [ 57.202528] rcu_scheduler_active = 2, debug_locks = 1 [ 57.202529] no locks held by test5/3567. [ 57.202530] stack backtrace: [ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e [ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022 [ 57.202536] Call Trace: [ 57.202537] [ 57.202540] dump_stack_lvl+0x77/0xb0 [ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0 [ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6] [ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a] [ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202866] write_cache_pages+0x265/0x450 [ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202913] do_writepages+0xd2/0x230 [ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80 [ 57.202921] filemap_fdatawrite_wbc+0x67/0x80 [ 57.202924] filemap_write_and_wait_range+0xd9/0x170 [ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902] [ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9] [ 57.202969] __se_sys_close+0x46/0xd0 [ 57.202972] do_syscall_64+0x68/0x100 [ 57.202975] ? do_syscall_64+0x77/0x100 [ 57.202976] ? do_syscall_64+0x77/0x100 [ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 57.202982] RIP: 0033:0x7fe2b12e4a94 [ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3 [ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 [ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94 [ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003 [ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49 [ 57.202993] R10: 00007fe2b11f8300 R11: 0000000000000202 R12: 0000000000000000 [ 57.202994] R13: 00007ffe857dfd80 R14: 00007fe2b1445000 R15: 0000000000000000 [ 57.202999] The problem seems to be that two out of three callers aren't taking the rcu_read_lock() before calling the list_for_each_entry_rcu() function in rpc_xprt_switch_has_addr(). I fix this by having rpc_xprt_switch_has_addr() unconditionaly take the rcu_read_lock(), which is okay to do recursively in the case that the lock has already been taken by a caller. Reviewed-by: Jeff Layton Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2ae7081bc10123b187e36a4f3a8e53768de31489 Author: Joel Granados Date: Tue Nov 21 12:02:18 2023 +0100 sysctl: Fix out of bounds access for empty sysctl registers [ Upstream commit 315552310c7de92baea4e570967066569937a843 ] When registering tables to the sysctl subsystem there is a check to see if header is a permanently empty directory (used for mounts). This check evaluates the first element of the ctl_table. This results in an out of bounds evaluation when registering empty directories. The function register_sysctl_mount_point now passes a ctl_table of size 1 instead of size 0. It now relies solely on the type to identify a permanently empty register. Make sure that the ctl_table has at least one element before testing for permanent emptiness. Signed-off-by: Joel Granados Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-lkp/202311201431.57aae8f3-oliver.sang@intel.com Signed-off-by: Luis Chamberlain Signed-off-by: Sasha Levin commit 2823db0010c400e4b2b12d02aa5d0d3ecb15d7c7 Author: Heiko Carstens Date: Thu Nov 30 18:56:00 2023 +0100 KVM: s390: fix setting of fpc register [ Upstream commit b988b1bb0053c0dcd26187d29ef07566a565cf55 ] kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control (fpc) register of a guest cpu. The new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the host process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space / host process fpc register value, however it will be discarded, when returning to user space. In result the host process will incorrectly continue to run with the value that was supposed to be used for a guest cpu. Fix this by simply removing the test. There is another test right before the SIE context is entered which will handles invalid values. This results in a change of behaviour: invalid values will now be accepted instead of that the ioctl fails with -EINVAL. This seems to be acceptable, given that this interface is most likely not used anymore, and this is in addition the same behaviour implemented with the memory mapped interface (replace invalid values with zero) - see sync_regs() in kvm-s390.c. Reviewed-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit bdce67df7f12fb0409fbc604ce7c4254703f56d4 Author: Heiko Carstens Date: Thu Nov 30 18:55:59 2023 +0100 s390/ptrace: handle setting of fpc register correctly [ Upstream commit 8b13601d19c541158a6e18b278c00ba69ae37829 ] If the content of the floating point control (fpc) register of a traced process is modified with the ptrace interface the new value is tested for validity by temporarily loading it into the fpc register. This may lead to corruption of the fpc register of the tracing process: if an interrupt happens while the value is temporarily loaded into the fpc register, and within interrupt context floating point or vector registers are used, the current fp/vx registers are saved with save_fpu_regs() assuming they belong to user space and will be loaded into fp/vx registers when returning to user space. test_fp_ctl() restores the original user space fpc register value, however it will be discarded, when returning to user space. In result the tracer will incorrectly continue to run with the value that was supposed to be used for the traced process. Fix this by saving fpu register contents with save_fpu_regs() before using test_fp_ctl(). Reviewed-by: Claudio Imbrenda Signed-off-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 72125978d7a04acce7142632c67895e9bd0ea8b1 Author: Tony Krowiak Date: Wed Nov 8 15:11:30 2023 -0500 s390/vfio-ap: fix sysfs status attribute for AP queue devices [ Upstream commit a0d8f4eeb7c4ffaee21702bcc91a09b3988c5b7a ] The 'status' attribute for AP queue devices bound to the vfio_ap device driver displays incorrect status when the mediated device is attached to a guest, but the queue device is not passed through. In the current implementation, the status displayed is 'in_use' which is not correct; it should be 'assigned'. This can happen if one of the queue devices associated with a given adapter is not bound to the vfio_ap device driver. For example: Queues listed in /sys/bus/ap/drivers/vfio_ap: 14.0005 14.0006 14.000d 16.0006 16.000d Queues listed in /sys/devices/vfio_ap/matrix/$UUID/matrix 14.0005 14.0006 14.000d 16.0005 16.0006 16.000d Queues listed in /sys/devices/vfio_ap/matrix/$UUID/guest_matrix 14.0005 14.0006 14.000d The reason no queues for adapter 0x16 are listed in the guest_matrix is because queue 16.0005 is not bound to the vfio_ap device driver, so no queue associated with the adapter is passed through to the guest; therefore, each queue device for adapter 0x16 should display 'assigned' instead of 'in_use', because those queues are not in use by a guest, but only assigned to the mediated device. Let's check the AP configuration for the guest to determine whether a queue device is passed through before displaying a status of 'in_use'. Signed-off-by: Tony Krowiak Acked-by: Halil Pasic Acked-by: Harald Freudenberger Link: https://lore.kernel.org/r/20231108201135.351419-1-akrowiak@linux.ibm.com Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit fc8b79112128911d5b6b96dc94fee0909911ae72 Author: Arnd Bergmann Date: Wed Nov 8 13:58:30 2023 +0100 arch: fix asm-offsets.c building with -Wmissing-prototypes [ Upstream commit 4d86896793dd6eeacdf32b85af1ef130349db4be ] When -Wmissing-prototypes is enabled, the some asm-offsets.c files fail to build, even when this warning is disabled in the Makefile for normal files: arch/sparc/kernel/asm-offsets.c:22:5: error: no previous prototype for 'sparc32_foo' [-Werror=missing-prototypes] arch/sparc/kernel/asm-offsets.c:48:5: error: no previous prototype for 'foo' [-Werror=missing-prototypes] Address this by making use of the same trick as x86, marking these functions as 'static __used' to avoid the need for a prototype by not drop them in dead-code elimination. Suggested-by: Masahiro Yamada Reviewed-by: Sam Ravnborg Link: https://lore.kernel.org/lkml/CAK7LNARfEmFk0Du4Hed19eX_G6tUC5wG0zP+L1AyvdpOF4ybXQ@mail.gmail.com/ Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 642102953a81561665055e27eb01a046f3ddb7b0 Author: Arnd Bergmann Date: Wed Nov 8 13:58:29 2023 +0100 arch: consolidate arch_irq_work_raise prototypes [ Upstream commit 64bac5ea17d527872121adddfee869c7a0618f8f ] The prototype was hidden in an #ifdef on x86, which causes a warning: kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise' [-Werror=missing-prototypes] Some architectures have a working prototype, while others don't. Fix this by providing it in only one place that is always visible. Reviewed-by: Alexander Gordeev Acked-by: Catalin Marinas Acked-by: Palmer Dabbelt Acked-by: Guo Ren Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit b5a35d12e751c8641e73e40d9b1f521cc2bb9916 Author: Alexander Gordeev Date: Sun Jul 16 10:56:00 2023 +0200 s390/boot: always align vmalloc area on segment boundary [ Upstream commit 65f8780e2d70257200547b5a7654974aa7c37ce1 ] The size of vmalloc area depends from various factors on boot and could be set to: 1. Default size as determined by VMALLOC_DEFAULT_SIZE macro; 2. One half of the virtual address space not occupied by modules and fixed mappings; 3. The size provided by user with vmalloc= kernel command line parameter; In cases [1] and [2] the vmalloc area base address is aligned on Region3 table type boundary, while in case [3] in might get aligned on page boundary. Limit the waste of page tables and always align vmalloc area size and base address on segment boundary. Acked-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit 5a6660139195f5e2fbbda459eeecb8788f3885fe Author: Edward Adam Davis Date: Tue Dec 12 09:36:22 2023 +0800 jfs: fix array-index-out-of-bounds in diNewExt [ Upstream commit 49f9637aafa6e63ba686c13cb8549bf5e6920402 ] [Syz report] UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2 index -878706688 is out of range for type 'struct iagctl[128]' CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360 diAllocExt fs/jfs/jfs_imap.c:1949 [inline] diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106 do_mkdirat+0x264/0x3a0 fs/namei.c:4129 __do_sys_mkdir fs/namei.c:4149 [inline] __se_sys_mkdir fs/namei.c:4147 [inline] __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6b RIP: 0033:0x7fcb7e6a0b57 Code: ff ff 77 07 31 c0 c3 0f 1f 40 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053 RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57 RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140 RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [Analysis] When the agstart is too large, it can cause agno overflow. [Fix] After obtaining agno, if the value is invalid, exit the subsequent process. Reported-and-tested-by: syzbot+553d90297e6d2f50dbc7@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Modified the test from agno > MAXAG to agno >= MAXAG based on linux-next report by kernel test robot (Dan Carpenter). Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 4c89c30d20c44bd01d5a62711cde924fd4e356e8 Author: Oleg Nesterov Date: Fri Nov 17 17:48:46 2023 +0100 rxrpc_find_service_conn_rcu: fix the usage of read_seqbegin_or_lock() [ Upstream commit bad1a11c0f061aa073bab785389fe04f19ba02e1 ] rxrpc_find_service_conn_rcu() should make the "seq" counter odd on the second pass, otherwise read_seqbegin_or_lock() never takes the lock. Signed-off-by: Oleg Nesterov Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20231117164846.GA10410@redhat.com/ Signed-off-by: Sasha Levin commit 779f4b22fb253ed2fc278fdea4e64502817faf90 Author: Oleg Nesterov Date: Thu Nov 30 12:56:06 2023 +0100 afs: fix the usage of read_seqbegin_or_lock() in afs_lookup_volume_rcu() [ Upstream commit 4121b4337146b64560d1e46ebec77196d9287802 ] David Howells says: (2) afs_lookup_volume_rcu(). There can be a lot of volumes known by a system. A thousand would require a 10-step walk and this is drivable by remote operation, so I think this should probably take a lock on the second pass too. Make the "seq" counter odd on the 2nd pass, otherwise read_seqbegin_or_lock() never takes the lock. Signed-off-by: Oleg Nesterov Signed-off-by: David Howells cc: Marc Dionne cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/r/20231130115606.GA21571@redhat.com/ Signed-off-by: Sasha Levin commit 08f5b181f51cb064aba0439da34aa5fd8eb4d4f6 Author: Thomas Bourgoin Date: Fri Dec 15 12:17:24 2023 +0100 crypto: stm32/crc32 - fix parsing list of devices [ Upstream commit 0eaef675b94c746900dcea7f6c41b9a103ed5d53 ] smatch warnings: drivers/crypto/stm32/stm32-crc32.c:108 stm32_crc_get_next_crc() warn: can 'crc' even be NULL? Use list_first_entry_or_null instead of list_first_entry to retrieve the first device registered. The function list_first_entry always return a non NULL pointer even if the list is empty. Hence checking if the pointer returned is NULL does not tell if the list is empty or not. Reported-by: kernel test robot Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202311281111.ou2oUL2i-lkp@intel.com/ Signed-off-by: Thomas Bourgoin Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ecf369741d4c3c2081e0d373c5de80c3b3309a7e Author: Gao Xiang Date: Fri Dec 15 00:13:37 2023 +0800 erofs: fix ztailpacking for subpage compressed blocks [ Upstream commit e5aba911dee5e20fa82efbe13e0af8f38ea459e7 ] `pageofs_in` should be the compressed data offset of the page rather than of the block. Acked-by: Chao Yu Reviewed-by: Yue Hu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20231214161337.753049-1-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit e518dfc3ac1da98592a4dd0fa21d4ae18075d904 Author: Bharat Bhushan Date: Mon Dec 11 15:59:11 2023 +0530 crypto: octeontx2 - Fix cptvf driver cleanup [ Upstream commit c480a421a4faf693c38e60b0fe6e554c9a3fee02 ] This patch fixes following cleanup issues: - Missing instruction queue free on cleanup. This will lead to memory leak. - lfs->lfs_num is set to zero before cleanup, which will lead to improper cleanup. Signed-off-by: Bharat Bhushan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cda72949e62f3717cf06fcf9b4064a1fe9f28011 Author: Jia Jie Ho Date: Mon Dec 4 11:04:13 2023 +0800 crypto: starfive - Fix dev_err_probe return error [ Upstream commit 8517c34e87025b3f74f3c07813d493828f369598 ] Current dev_err_probe will return 0 instead of proper error code if driver failed to get irq number. Fix the return code. Signed-off-by: Jia Jie Ho Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 22438a34d383ec2789eaf450728e38abc53051f8 Author: Gao Xiang Date: Wed Dec 6 17:10:55 2023 +0800 erofs: fix up compacted indexes for block size < 4096 [ Upstream commit 8d2517aaeea3ab8651bb517bca8f3c8664d318ea ] Previously, the block size always equaled to PAGE_SIZE, therefore `lclusterbits` couldn't be less than 12. Since sub-page compressed blocks are now considered, `lobits` for a lcluster in each pack cannot always be `lclusterbits` as before. Otherwise, there is no enough room for the special value `Z_EROFS_LI_D0_CBLKCNT`. To support smaller block sizes, `lobits` for each compacted lcluster is now calculated as: lobits = max(lclusterbits, ilog2(Z_EROFS_LI_D0_CBLKCNT) + 1) Reviewed-by: Yue Hu Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Link: https://lore.kernel.org/r/20231206091057.87027-4-hsiangkao@linux.alibaba.com Signed-off-by: Sasha Levin commit cd40e43f870cf21726b22487a95ed223790b3542 Author: Weichen Chen Date: Fri Feb 24 10:36:32 2023 +0800 pstore/ram: Fix crash when setting number of cpus to an odd number [ Upstream commit d49270a04623ce3c0afddbf3e984cb245aa48e9c ] When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va. So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug. Signed-off-by: Weichen Chen Reviewed-by: Matthias Brugger Tested-by: "Guilherme G. Piccoli" Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit e85918ca8a2dc6a88c58f6d7bb34bd2e28bea421 Author: Gustavo A. R. Silva Date: Tue Nov 21 12:52:44 2023 -0600 crypto: p10-aes-gcm - Avoid -Wstringop-overflow warnings [ Upstream commit aaa03fdb56c781db4a4831dd5d6ec8817918c726 ] The compiler doesn't know that `32` is an offset into the Hash table: 56 struct Hash_ctx { 57 u8 H[16]; /* subkey */ 58 u8 Htable[256]; /* Xi, Hash table(offset 32) */ 59 }; So, it legitimately complains about a potential out-of-bounds issue if `256 bytes` are accessed in `htable` (this implies going `32 bytes` beyond the boundaries of `Htable`): arch/powerpc/crypto/aes-gcm-p10-glue.c: In function 'gcmp10_init': arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: error: 'gcm_init_htable' accessing 256 bytes in a region of size 224 [-Werror=stringop-overflow=] 120 | gcm_init_htable(hash->Htable+32, hash->H); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: note: referencing argument 1 of type 'unsigned char[256]' arch/powerpc/crypto/aes-gcm-p10-glue.c:120:9: note: referencing argument 2 of type 'unsigned char[16]' arch/powerpc/crypto/aes-gcm-p10-glue.c:40:17: note: in a call to function 'gcm_init_htable' 40 | asmlinkage void gcm_init_htable(unsigned char htable[256], unsigned char Xi[16]); | ^~~~~~~~~~~~~~~ Address this by avoiding specifying the size of `htable` in the function prototype; and just for consistency, do the same for parameter `Xi`. Reported-by: Stephen Rothwell Closes: https://lore.kernel.org/linux-next/20231121131903.68a37932@canb.auug.org.au/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 942a6cd7fba20bccdcf486fe81839449f8d87360 Author: Jia Jie Ho Date: Mon Nov 20 23:11:21 2023 +0800 hwrng: starfive - Fix dev_err_probe return error [ Upstream commit 2d37b3649c412b3bcecfea932cb677f7a5775b15 ] Current dev_err_probe will return 0 instead of proper error code if driver failed to get irq number. Fix the return err code. Signed-off-by: Jia Jie Ho Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202311160649.3GhKCfhd-lkp@intel.com/ Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bacdaa04251382d7efd4f09f9a0686bfcc297e2e Author: Edward Adam Davis Date: Tue Oct 31 13:39:04 2023 +0800 jfs: fix uaf in jfs_evict_inode [ Upstream commit e0e1958f4c365e380b17ccb35617345b31ef7bf3 ] When the execution of diMount(ipimap) fails, the object ipimap that has been released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs when rcu_core() calls jfs_free_node(). Therefore, when diMount(ipimap) fails, sbi->ipimap should not be initialized as ipimap. Reported-and-tested-by: syzbot+01cf2dbcbe2022454388@syzkaller.appspotmail.com Signed-off-by: Edward Adam Davis Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit fc67a2e18f4c4e3f07e9f9ae463da24530470e73 Author: Manas Ghandat Date: Tue Oct 17 17:33:56 2023 +0530 jfs: fix array-index-out-of-bounds in dbAdjTree [ Upstream commit 74ecdda68242b174920fe7c6133a856fb7d8559b ] Currently there is a bound check missing in the dbAdjTree while accessing the dmt_stree. To add the required check added the bool is_ctl which is required to determine the size as suggest in the following commit. https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/ Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb Signed-off-by: Manas Ghandat Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit bff9d4078a232c01e42e9377d005fb2f4d31a472 Author: Manas Ghandat Date: Wed Oct 25 11:39:07 2023 +0530 jfs: fix slab-out-of-bounds Read in dtSearch [ Upstream commit fa5492ee89463a7590a1449358002ff7ef63529f ] Currently while searching for current page in the sorted entry table of the page there is a out of bound access. Added a bound check to fix the error. Dave: Set return code to -EIO Reported-by: kernel test robot Reported-by: Dan Carpenter Closes: https://lore.kernel.org/r/202310241724.Ed02yUz9-lkp@intel.com/ Signed-off-by: Manas Ghandat Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 6e2902ecc77e9760a9fc447f56d598383e2372d2 Author: Osama Muhammad Date: Sat Oct 14 00:10:28 2023 +0500 UBSAN: array-index-out-of-bounds in dtSplitRoot [ Upstream commit 27e56f59bab5ddafbcfe69ad7a4a6ea1279c1b16 ] Syzkaller reported the following issue: oop0: detected capacity change from 0 to 32768 UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9 index -2 is out of range for type 'struct dtslot [128]' CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline] dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013 do_mkdirat+0x279/0x550 fs/namei.c:4038 __do_sys_mkdirat fs/namei.c:4053 [inline] __se_sys_mkdirat fs/namei.c:4051 [inline] __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fcdc0113fd9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9 RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003 RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0 R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000 R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000 The issue is caused when the value of fsi becomes less than -1. The check to break the loop when fsi value becomes -1 is present but syzbot was able to produce value less than -1 which cause the error. This patch simply add the change for the values less than 0. The patch is tested via syzbot. Reported-and-tested-by: syzbot+d4b1df2e9d4ded6488ec@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=d4b1df2e9d4ded6488ec Signed-off-by: Osama Muhammad Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 59342822276f753e49d27ef5eebffbba990572b9 Author: Osama Muhammad Date: Wed Oct 11 23:46:37 2023 +0500 FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree [ Upstream commit 9862ec7ac1cbc6eb5ee4a045b5d5b8edbb2f7e68 ] Syzkaller reported the following issue: UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6 index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]') CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:217 [inline] __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 ================================================================================ Kernel panic - not syncing: UBSAN: panic_on_warn set ... CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 panic+0x30f/0x770 kernel/panic.c:340 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236 ubsan_epilogue lib/ubsan.c:223 [inline] __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline] dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534 txUpdateMap+0x342/0x9e0 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline] jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732 kthread+0x2d3/0x370 kernel/kthread.c:388 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 Kernel Offset: disabled Rebooting in 86400 seconds.. The issue is caused when the value of lp becomes greater than CTLTREESIZE which is the max size of stree. Adding a simple check solves this issue. Dave: As the function returns a void, good error handling would require a more intrusive code reorganization, so I modified Osama's patch at use WARN_ON_ONCE for lack of a cleaner option. The patch is tested via syzbot. Reported-by: syzbot+39ba34a099ac2e9bd3cb@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=39ba34a099ac2e9bd3cb Signed-off-by: Osama Muhammad Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit f4a3fdbd26e7e94b4cf8c86aabec6a37a53e18e0 Author: Rafael J. Wysocki Date: Mon Dec 18 20:25:02 2023 +0100 thermal: core: Fix thermal zone suspend-resume synchronization [ Upstream commit 4e814173a8c4f432fd068b1c796f0416328c9d99 ] There are 3 synchronization issues with thermal zone suspend-resume during system-wide transitions: 1. The resume code runs in a PM notifier which is invoked after user space has been thawed, so it can run concurrently with user space which can trigger a thermal zone device removal. If that happens, the thermal zone resume code may use a stale pointer to the next list element and crash, because it does not hold thermal_list_lock while walking thermal_tz_list. 2. The thermal zone resume code calls thermal_zone_device_init() outside the zone lock, so user space or an update triggered by the platform firmware may see an inconsistent state of a thermal zone leading to unexpected behavior. 3. Clearing the in_suspend global variable in thermal_pm_notify() allows __thermal_zone_device_update() to continue for all thermal zones and it may as well run before the thermal_tz_list walk (or at any point during the list walk for that matter) and attempt to operate on a thermal zone that has not been resumed yet. It may also race destructively with thermal_zone_device_init(). To address these issues, add thermal_list_lock locking to thermal_pm_notify(), especially arount the thermal_tz_list, make it call thermal_zone_device_init() back-to-back with __thermal_zone_device_update() under the zone lock and replace in_suspend with per-zone bool "suspend" indicators set and unset under the given zone's lock. Link: https://lore.kernel.org/linux-pm/20231218162348.69101-1-bo.ye@mediatek.com/ Reported-by: Bo Ye Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 5f93c49247dc645aa249534ed1147d2739f698a1 Author: Viresh Kumar Date: Tue Dec 19 11:32:39 2023 +0530 OPP: The level field is always of unsigned int type [ Upstream commit ba367479c7ad0b870461024cd5ae7a1ea6e1e3db ] By mistake, dev_pm_opp_find_level_floor() used the level parameter as unsigned long instead of unsigned int. Fix it. Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit f6d6e9cfce7d6e576216ea54bfeae504dd6b4e73 Author: Shuai Xue Date: Mon Dec 18 14:45:18 2023 +0800 ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events [ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ] There are two major types of uncorrected recoverable (UCR) errors : - Synchronous error: The error is detected and raised at the point of the consumption in the execution flow, e.g. when a CPU tries to access a poisoned cache line. The CPU will take a synchronous error exception such as Synchronous External Abort (SEA) on Arm64 and Machine Check Exception (MCE) on X86. OS requires to take action (for example, offline failure page/kill failure thread) to recover this uncorrectable error. - Asynchronous error: The error is detected out of processor execution context, e.g. when an error is detected by a background scrubber. Some data in the memory are corrupted. But the data have not been consumed. OS is optional to take action to recover this uncorrectable error. When APEI firmware first is enabled, a platform may describe one error source for the handling of synchronous errors (e.g. MCE or SEA notification ), or for handling asynchronous errors (e.g. SCI or External Interrupt notification). In other words, we can distinguish synchronous errors by APEI notification. For synchronous errors, kernel will kill the current process which accessing the poisoned page by sending SIGBUS with BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in early kill mode. However, the GHES driver always sets mf_flags to 0 so that all synchronous errors are handled as asynchronous errors in memory failure. To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous events. Signed-off-by: Shuai Xue Tested-by: Ma Wupeng Reviewed-by: Kefeng Wang Reviewed-by: Xiaofei Tan Reviewed-by: Baolin Wang Reviewed-by: James Morse Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ae815e2fdc284ab31651d52460698bd89c0fce22 Author: Mukesh Ojha Date: Sat Nov 25 02:41:58 2023 +0530 PM / devfreq: Synchronize devfreq_monitor_[start/stop] [ Upstream commit aed5ed595960c6d301dcd4ed31aeaa7a8054c0c6 ] There is a chance if a frequent switch of the governor done in a loop result in timer list corruption where timer cancel being done from two place one from cancel_delayed_work_sync() and followed by expire_timers() can be seen from the traces[1]. while true do echo "simple_ondemand" > /sys/class/devfreq/1d84000.ufshc/governor echo "performance" > /sys/class/devfreq/1d84000.ufshc/governor done It looks to be issue with devfreq driver where device_monitor_[start/stop] need to synchronized so that delayed work should get corrupted while it is either being queued or running or being cancelled. Let's use polling flag and devfreq lock to synchronize the queueing the timer instance twice and work data being corrupted. [1] ... .. -0 [003] 9436.209662: timer_cancel timer=0xffffff80444f0428 -0 [003] 9436.209664: timer_expire_entry timer=0xffffff80444f0428 now=0x10022da1c function=__typeid__ZTSFvP10timer_listE_global_addr baseclk=0x10022da1c -0 [003] 9436.209718: timer_expire_exit timer=0xffffff80444f0428 kworker/u16:6-14217 [003] 9436.209863: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2b now=0x10022da1c flags=182452227 vendor.xxxyyy.ha-1593 [004] 9436.209888: timer_cancel timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216390: timer_init timer=0xffffff80444f0428 vendor.xxxyyy.ha-1593 [004] 9436.216392: timer_start timer=0xffffff80444f0428 function=__typeid__ZTSFvP10timer_listE_global_addr expires=0x10022da2c now=0x10022da1d flags=186646532 vendor.xxxyyy.ha-1593 [005] 9436.220992: timer_cancel timer=0xffffff80444f0428 xxxyyyTraceManag-7795 [004] 9436.261641: timer_cancel timer=0xffffff80444f0428 [2] 9436.261653][ C4] Unable to handle kernel paging request at virtual address dead00000000012a [ 9436.261664][ C4] Mem abort info: [ 9436.261666][ C4] ESR = 0x96000044 [ 9436.261669][ C4] EC = 0x25: DABT (current EL), IL = 32 bits [ 9436.261671][ C4] SET = 0, FnV = 0 [ 9436.261673][ C4] EA = 0, S1PTW = 0 [ 9436.261675][ C4] Data abort info: [ 9436.261677][ C4] ISV = 0, ISS = 0x00000044 [ 9436.261680][ C4] CM = 0, WnR = 1 [ 9436.261682][ C4] [dead00000000012a] address between user and kernel address ranges [ 9436.261685][ C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP [ 9436.261701][ C4] Skip md ftrace buffer dump for: 0x3a982d0 ... [ 9436.262138][ C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S W O 5.10.149-android12-9-o-g17f915d29d0c #1 [ 9436.262141][ C4] Hardware name: Qualcomm Technologies, Inc. (DT) [ 9436.262144][ C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--) [ 9436.262161][ C4] pc : expire_timers+0x9c/0x438 [ 9436.262164][ C4] lr : expire_timers+0x2a4/0x438 [ 9436.262168][ C4] sp : ffffffc010023dd0 [ 9436.262171][ C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18 [ 9436.262178][ C4] x27: ffffffd063569dd0 x26: ffffffd063536008 [ 9436.262182][ C4] x25: 0000000000000001 x24: ffffff88f7c69280 [ 9436.262185][ C4] x23: 00000000000000e0 x22: dead000000000122 [ 9436.262188][ C4] x21: 000000010022da29 x20: ffffff8af72b4e80 [ 9436.262191][ C4] x19: ffffffc010023e50 x18: ffffffc010025038 [ 9436.262195][ C4] x17: 0000000000000240 x16: 0000000000000201 [ 9436.262199][ C4] x15: ffffffffffffffff x14: ffffff889f3c3100 [ 9436.262203][ C4] x13: ffffff889f3c3100 x12: 00000000049f56b8 [ 9436.262207][ C4] x11: 00000000049f56b8 x10: 00000000ffffffff [ 9436.262212][ C4] x9 : ffffffc010023e50 x8 : dead000000000122 [ 9436.262216][ C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8 [ 9436.262220][ C4] x5 : 0000000000000000 x4 : 0000000000000101 [ 9436.262223][ C4] x3 : 0000000000000080 x2 : ffffff889edc155c [ 9436.262227][ C4] x1 : ffffff8001005200 x0 : ffffff80444f0428 [ 9436.262232][ C4] Call trace: [ 9436.262236][ C4] expire_timers+0x9c/0x438 [ 9436.262240][ C4] __run_timers+0x1f0/0x330 [ 9436.262245][ C4] run_timer_softirq+0x28/0x58 [ 9436.262255][ C4] efi_header_end+0x168/0x5ec [ 9436.262265][ C4] __irq_exit_rcu+0x108/0x124 [ 9436.262274][ C4] __handle_domain_irq+0x118/0x1e4 [ 9436.262282][ C4] gic_handle_irq.30369+0x6c/0x2bc [ 9436.262286][ C4] el0_irq_naked+0x60/0x6c Link: https://lore.kernel.org/all/1700860318-4025-1-git-send-email-quic_mojha@quicinc.com/ Reported-by: Joyyoung Huang Acked-by: MyungJoo Ham Signed-off-by: Mukesh Ojha Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit bc9b9c5026964ec66a307f6ba71cfd3428aaa2b4 Author: Michal Wajdeczko Date: Fri Dec 15 16:13:27 2023 +0100 kunit: Reset test->priv after each param iteration [ Upstream commit 342fb9789267ee3908959bfa136b82e88e2ce918 ] If we run parameterized test that uses test->priv to prepare some custom data, then value of test->priv will leak to the next param iteration and may be unexpected. This could be easily seen if we promote example_priv_test to parameterized test as then only first test iteration will be successful: $ ./tools/testing/kunit/kunit.py run \ --kunitconfig ./lib/kunit/.kunitconfig *.example_priv* [ ] Starting KUnit Kernel (1/1)... [ ] ============================================================ [ ] =================== example (1 subtest) ==================== [ ] ==================== example_priv_test ==================== [ ] [PASSED] example value 3 [ ] # example_priv_test: initializing [ ] # example_priv_test: ASSERTION FAILED at lib/kunit/kunit-example-test.c:230 [ ] Expected test->priv == ((void *)0), but [ ] test->priv == 0000000060dfe290 [ ] ((void *)0) == 0000000000000000 [ ] # example_priv_test: cleaning up [ ] [FAILED] example value 2 [ ] # example_priv_test: initializing [ ] # example_priv_test: ASSERTION FAILED at lib/kunit/kunit-example-test.c:230 [ ] Expected test->priv == ((void *)0), but [ ] test->priv == 0000000060dfe290 [ ] ((void *)0) == 0000000000000000 [ ] # example_priv_test: cleaning up [ ] [FAILED] example value 1 [ ] # example_priv_test: initializing [ ] # example_priv_test: ASSERTION FAILED at lib/kunit/kunit-example-test.c:230 [ ] Expected test->priv == ((void *)0), but [ ] test->priv == 0000000060dfe290 [ ] ((void *)0) == 0000000000000000 [ ] # example_priv_test: cleaning up [ ] [FAILED] example value 0 [ ] # example_priv_test: initializing [ ] # example_priv_test: cleaning up [ ] # example_priv_test: pass:1 fail:3 skip:0 total:4 [ ] ================ [FAILED] example_priv_test ================ [ ] # example: initializing suite [ ] # module: kunit_example_test [ ] # example: exiting suite [ ] # Totals: pass:1 fail:3 skip:0 total:4 [ ] ===================== [FAILED] example ===================== Fix that by resetting test->priv after each param iteration, in similar way what we did for the test->status. Signed-off-by: Michal Wajdeczko Cc: David Gow Cc: Rae Moar Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 79b907b29b8f2fbd2f4a6723f91cae9372e0e413 Author: Rae Moar Date: Thu Dec 7 21:34:09 2023 +0000 kunit: tool: fix parsing of test attributes [ Upstream commit 8ae27bc7fff4ef467a7964821a6cedb34a05d3b2 ] Add parsing of attributes as diagnostic data. Fixes issue with test plan being parsed incorrectly as diagnostic data when located after suite-level attributes. Note that if there does not exist a test plan line, the diagnostic lines between the suite header and the first result will be saved in the suite log rather than the first test case log. Signed-off-by: Rae Moar Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 00601d3f2993755c2420f6257e4f38b44c03f8b4 Author: Yuntao Wang Date: Wed Dec 6 18:43:18 2023 +0800 ACPI: NUMA: Fix the logic of getting the fake_pxm value [ Upstream commit e3f577830ce216b0ca21d4750cbbd64cfc21efff ] The for loop does not iterate over the last element of the node_to_pxm_map array. This could lead to a conflict between the final fake_pxm value and the existing pxm values. That is, the final fake_pxm value can not be guaranteed to be an unused pxm value. While at it, fix up white space in slit_valid(). Signed-off-by: Yuntao Wang [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit efcb2e89b2f35ad1f13e6d01bee7215ace7d6cea Author: Thomas Weißschuh Date: Sun Nov 5 15:16:38 2023 +0100 selftests/nolibc: fix testcase status alignment [ Upstream commit 07f679b50252dc9e3d0c19aca5801f82c230c527 ] Center-align all possible status reports. Before OK and FAIL were center-aligned in relation to each other but SKIPPED and FAILED would be left-aligned. Before: 7 environ_addr = <0x7fffef3e7c50> [OK] 8 environ_envp = <0x7fffef3e7c58> [FAIL] 9 environ_auxv [SKIPPED] 10 environ_total [SKIPPED] 11 environ_HOME = <0x7fffef3e99bd> [OK] 12 auxv_addr [SKIPPED] 13 auxv_AT_UID = 1000 [OK] After: 7 environ_addr = <0x7ffff13b00a0> [OK] 8 environ_envp = <0x7ffff13b00a8> [FAIL] 9 environ_auxv [SKIPPED] 10 environ_total [SKIPPED] 11 environ_HOME = <0x7ffff13b19bd> [OK] 12 auxv_addr [SKIPPED] 13 auxv_AT_UID = 1000 [OK] Signed-off-by: Thomas Weißschuh Signed-off-by: Sasha Levin commit 77846571b3ba6a6125a20ad109bb8514ba884cf9 Author: Prarit Bhargava Date: Mon Dec 4 13:00:37 2023 -0500 ACPI: extlog: fix NULL pointer dereference check [ Upstream commit 72d9b9747e78979510e9aafdd32eb99c7aa30dd1 ] The gcc plugin -fanalyzer [1] tries to detect various patterns of incorrect behaviour. The tool reports: drivers/acpi/acpi_extlog.c: In function ‘extlog_exit’: drivers/acpi/acpi_extlog.c:307:12: warning: check of ‘extlog_l1_addr’ for NULL after already dereferencing it [-Wanalyzer-deref-before-check] | | 306 | ((struct extlog_l1_head *)extlog_l1_addr)->flags &= ~FLAG_OS_OPTIN; | | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~ | | | | | (1) pointer ‘extlog_l1_addr’ is dereferenced here | 307 | if (extlog_l1_addr) | | ~ | | | | | (2) pointer ‘extlog_l1_addr’ is checked for NULL here but it was already dereferenced at (1) | Fix the NULL pointer dereference check in extlog_exit(). Link: https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Static-Analyzer-Options.html # [1] Signed-off-by: Prarit Bhargava Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 1fa669da8f22f1d35f1bc7bd1e8be7a70c0f605f Author: Dmitry Antipov Date: Tue Nov 28 05:52:10 2023 +0300 PNP: ACPI: fix fortify warning [ Upstream commit ba3f5058db437d919f8468db50483dd9028ff688 ] When compiling with gcc version 14.0.0 20231126 (experimental) and CONFIG_FORTIFY_SOURCE=y, I've noticed the following: In file included from ./include/linux/string.h:295, from ./include/linux/bitmap.h:12, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/paravirt.h:17, from ./arch/x86/include/asm/cpuid.h:62, from ./arch/x86/include/asm/processor.h:19, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:60, from ./arch/x86/include/asm/preempt.h:9, from ./include/linux/preempt.h:79, from ./include/linux/spinlock.h:56, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:7, from ./include/linux/slab.h:16, from ./include/linux/resource_ext.h:11, from ./include/linux/acpi.h:13, from drivers/pnp/pnpacpi/rsparser.c:11: In function 'fortify_memcpy_chk', inlined from 'pnpacpi_parse_allocated_vendor' at drivers/pnp/pnpacpi/rsparser.c:158:3, inlined from 'pnpacpi_allocated_resource' at drivers/pnp/pnpacpi/rsparser.c:249:3: ./include/linux/fortify-string.h:588:25: warning: call to '__read_overflow2_field' declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 588 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to the comments in include/linux/fortify-string.h, 'memcpy()', 'memmove()' and 'memset()' must not be used beyond individual struct members to ensure that the compiler can enforce protection against buffer overflows, and, IIUC, this also applies to partial copies from the particular member ('vendor->byte_data' in this case). So it should be better (and safer) to do both copies at once (and 'byte_data' of 'struct acpi_resource_vendor_typed' seems to be a good candidate for '__counted_by(byte_length)' as well). Signed-off-by: Dmitry Antipov Reviewed-by: Kees Cook Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b74d7d3e9817b82fe376b30932dee31ad3824e47 Author: Yuluo Qiu Date: Sun Nov 26 21:59:13 2023 +0800 ACPI: video: Add quirk for the Colorful X15 AT 23 Laptop [ Upstream commit 143176a46bdd3bfbe9ba2462bf94458e80d65ebf ] The Colorful X15 AT 23 ACPI video-bus device report spurious ACPI_VIDEO_NOTIFY_CYCLE events resulting in spurious KEY_SWITCHVIDEOMODE events being reported to userspace (and causing trouble there) when an external screen plugged in. Add a quirk setting the report_key_events mask to REPORT_BRIGHTNESS_KEY_EVENTS so that the ACPI_VIDEO_NOTIFY_CYCLE events will be ignored, while still reporting brightness up/down hotkey-presses to userspace normally. Signed-off-by: Yuluo Qiu Co-developed-by: Celeste Liu Signed-off-by: Celeste Liu Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit b15552f629dd836d9d3d125cbe5731ce39151fb3 Author: Yuntao Wang Date: Mon Nov 20 19:41:43 2023 +0800 ACPI: tables: Correct and clean up the logic of acpi_parse_entries_array() [ Upstream commit 4b3805daaacb2168665c6222f261e68accb120dc ] The original intention of acpi_parse_entries_array() is to return the number of all matching entries on success. This number may be greater than the value of the max_entries parameter. When this happens, the function will output a warning message, indicating that `count - max_entries` matching entries remain unprocessed and have been ignored. However, commit 4ceacd02f5a1 ("ACPI / table: Always count matched and successfully parsed entries") changed this logic to return the number of entries successfully processed by the handler. In this case, when the max_entries parameter is not zero, the number of entries successfully processed can never be greater than the value of max_entries. In other words, the expression `count > max_entries` will always evaluate to false. This means that the logic in the final if statement will never be executed. Commit 99b0efd7c886 ("ACPI / tables: do not report the number of entries ignored by acpi_parse_entries()") mentioned this issue, but it tried to fix it by removing part of the warning message. This is meaningless because the pr_warn statement will never be executed in the first place. Commit 8726d4f44150 ("ACPI / tables: fix acpi_parse_entries_array() so it traverses all subtables") introduced an errs variable, which is intended to make acpi_parse_entries_array() always traverse all of the subtables, calling as many of the callbacks as possible. However, it seems that the commit does not achieve this goal. For example, when a handler returns an error, none of the handlers will be called again in the subsequent iterations. This result appears to be no different from before the change. This patch corrects and cleans up the logic of acpi_parse_entries_array(), making it return the number of all matching entries, rather than the number of entries successfully processed by handlers. Additionally, if an error occurs when executing a handler, the function will return -EINVAL immediately. This patch should not affect existing users of acpi_parse_entries_array(). Signed-off-by: Yuntao Wang Reviewed-by: Dave Jiang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit aa7f84f6626fa2372588635b6bf6ce97dfd5379f Author: Chris Riches Date: Wed Oct 18 09:23:51 2023 +0000 audit: Send netlink ACK before setting connection in auditd_set [ Upstream commit 022732e3d846e197539712e51ecada90ded0572a ] When auditd_set sets the auditd_conn pointer, audit messages can immediately be put on the socket by other kernel threads. If the backlog is large or the rate is high, this can immediately fill the socket buffer. If the audit daemon requested an ACK for this operation, a full socket buffer causes the ACK to get dropped, also setting ENOBUFS on the socket. To avoid this race and ensure ACKs get through, fast-track the ACK in this specific case to ensure it is sent before auditd_conn is set. Signed-off-by: Chris Riches [PM: fix some tab vs space damage] Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 2801b6299f833ad47b4ee76b1dd998096497f455 Author: Rui Zhang Date: Fri Nov 3 15:42:31 2023 +0800 regulator: core: Only increment use_count when enable_count changes [ Upstream commit 7993d3a9c34f609c02171e115fd12c10e2105ff4 ] The use_count of a regulator should only be incremented when the enable_count changes from 0 to 1. Similarly, the use_count should only be decremented when the enable_count changes from 1 to 0. In the previous implementation, use_count was sometimes decremented to 0 when some consumer called unbalanced disable, leading to unexpected disable even the regulator is enabled by other consumers. With this change, the use_count accurately reflects the number of users which the regulator is enabled. This should make things more robust in the case where a consumer does leak references. Signed-off-by: Rui Zhang Link: https://lore.kernel.org/r/20231103074231.8031-1-zr.zhang@vivo.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c8b3ed00535aa66d22ea9d52fd1def7c28845587 Author: Vincent Guittot Date: Thu Dec 21 17:40:14 2023 +0100 sched/fair: Fix tg->load when offlining a CPU [ Upstream commit f60a631ab9ed5df15e446269ea515f2b8948ba0c ] When a CPU is taken offline, the contribution of its cfs_rqs to task_groups' load may remain and will negatively impact the calculation of the share of the online CPUs. To fix this bug, clear the contribution of an offlining CPU to task groups' load and skip its contribution while it is inactive. Here's the reproducer of the anomaly, by Imran Khan: "So far I have encountered only one rather lengthy way of reproducing this issue, which is as follows: 1. Take a KVM guest (booted with 4 CPUs and can be scaled up to 124 CPUs) and create 2 custom cgroups: /sys/fs/cgroup/cpu/test_group_1 and /sys/fs/cgroup/ cpu/test_group_2 2. Assign a CPU intensive workload to each of these cgroups and start the workload. For my tests I am using following app: int main(int argc, char *argv[]) { unsigned long count, i, val; if (argc != 2) { printf("usage: ./a.out \n"); return 0; } count = strtoul(argv[1], NULL, 10); printf("Generating %lu random numbers \n", count); for (i = 0; i < count; i++) { val = rand(); val = val % 2; //usleep(1); } printf("Generated %lu random numbers \n", count); return 0; } Also since the system is booted with 4 CPUs, in order to completely load the system I am also launching 4 instances of same test app under: /sys/fs/cgroup/cpu/ 3. We can see that both of the cgroups get similar CPU time: # systemd-cgtop --depth 1 Path Tasks %CPU Memory Input/s Output/s / 659 - 5.5G - - /system.slice - - 5.7G - - /test_group_1 4 - - - - /test_group_2 3 - - - - /user.slice 31 - 56.5M - - Path Tasks %CPU Memory Input/s Output/s / 659 394.6 5.5G - - /test_group_2 3 65.7 - - - /user.slice 29 55.1 48.0M - - /test_group_1 4 47.3 - - - /system.slice - 2.2 5.7G - - Path Tasks %CPU Memory Input/s Output/s / 659 394.8 5.5G - - /test_group_1 4 62.9 - - - /user.slice 28 44.9 54.2M - - /test_group_2 3 44.7 - - - /system.slice - 0.9 5.7G - - Path Tasks %CPU Memory Input/s Output/s / 659 394.4 5.5G - - /test_group_2 3 58.8 - - - /test_group_1 4 51.9 - - - /user.slice 30 39.3 59.6M - - /system.slice - 1.9 5.7G - - Path Tasks %CPU Memory Input/s Output/s / 659 394.7 5.5G - - /test_group_1 4 60.9 - - - /test_group_2 3 57.9 - - - /user.slice 28 43.5 36.9M - - /system.slice - 3.0 5.7G - - Path Tasks %CPU Memory Input/s Output/s / 659 395.0 5.5G - - /test_group_1 4 66.8 - - - /test_group_2 3 56.3 - - - /user.slice 29 43.1 51.8M - - /system.slice - 0.7 5.7G - - 4. Now move systemd-udevd to one of these test groups, say test_group_1, and perform scale up to 124 CPUs followed by scale down back to 4 CPUs from the host side. 5. Run the same workload i.e 4 instances of CPU hogger under /sys/fs/cgroup/cpu and one instance of CPU hogger each in /sys/fs/cgroup/cpu/test_group_1 and /sys/fs/cgroup/test_group_2. It can be seen that test_group_1 (the one where systemd-udevd was moved) is getting much less CPU time than the test_group_2, even though at this point of time both of these groups have only CPU hogger running: # systemd-cgtop --depth 1 Path Tasks %CPU Memory Input/s Output/s / 1219 - 5.4G - - /system.slice - - 5.6G - - /test_group_1 4 - - - - /test_group_2 3 - - - - /user.slice 26 - 91.3M - - Path Tasks %CPU Memory Input/s Output/s / 1221 394.3 5.4G - - /test_group_2 3 82.7 - - - /test_group_1 4 14.3 - - - /system.slice - 0.8 5.6G - - /user.slice 26 0.4 91.2M - - Path Tasks %CPU Memory Input/s Output/s / 1221 394.6 5.4G - - /test_group_2 3 67.4 - - - /system.slice - 24.6 5.6G - - /test_group_1 4 12.5 - - - /user.slice 26 0.4 91.2M - - Path Tasks %CPU Memory Input/s Output/s / 1221 395.2 5.4G - - /test_group_2 3 60.9 - - - /system.slice - 27.9 5.6G - - /test_group_1 4 12.2 - - - /user.slice 26 0.4 91.2M - - Path Tasks %CPU Memory Input/s Output/s / 1221 395.2 5.4G - - /test_group_2 3 69.4 - - - /test_group_1 4 13.9 - - - /user.slice 28 1.6 92.0M - - /system.slice - 1.0 5.6G - - Path Tasks %CPU Memory Input/s Output/s / 1221 395.6 5.4G - - /test_group_2 3 59.3 - - - /test_group_1 4 14.1 - - - /user.slice 28 1.3 92.2M - - /system.slice - 0.7 5.6G - - Path Tasks %CPU Memory Input/s Output/s / 1221 395.5 5.4G - - /test_group_2 3 67.2 - - - /test_group_1 4 11.5 - - - /user.slice 28 1.3 92.5M - - /system.slice - 0.6 5.6G - - Path Tasks %CPU Memory Input/s Output/s / 1221 395.1 5.4G - - /test_group_2 3 76.8 - - - /test_group_1 4 12.9 - - - /user.slice 28 1.3 92.8M - - /system.slice - 1.2 5.6G - - From sched_debug data it can be seen that in bad case the load.weight of per-CPU sched entities corresponding to test_group_1 has reduced significantly and also load_avg of test_group_1 remains much higher than that of test_group_2, even though systemd-udevd stopped running long time back and at this point of time both cgroups just have the CPU hogger app as running entity." [ mingo: Added details from the original discussion, plus minor edits to the patch. ] Reported-by: Imran Khan Tested-by: Imran Khan Tested-by: Aaron Lu Signed-off-by: Vincent Guittot Signed-off-by: Ingo Molnar Reviewed-by: Imran Khan Cc: Peter Zijlstra Cc: Borislav Petkov Link: https://lore.kernel.org/r/20231223111545.62135-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit 2be831bbf57ba6cf76c85b9e96c008f4d04a26b1 Author: Andrzej Hajda Date: Wed Oct 25 23:39:07 2023 +0200 debugobjects: Stop accessing objects after releasing hash bucket lock [ Upstream commit 9bb6362652f3f4d74a87d572a91ee1b38e673ef6 ] After release of the hashbucket lock the tracking object can be modified or freed by a concurrent thread. Using it in such a case is error prone, even for printing the object state: 1. T1 tries to deactivate destroyed object, debugobjects detects it, hash bucket lock is released. 2. T2 preempts T1 and frees the tracking object. 3. The freed tracking object is allocated and initialized for a different to be tracked kernel object. 4. T1 resumes and reports error for wrong kernel object. Create a local copy of the tracking object before releasing the hash bucket lock and use the local copy for reporting and fixups to prevent this. Signed-off-by: Andrzej Hajda Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20231025-debugobjects_fix-v3-1-2bc3bf7084c2@intel.com Signed-off-by: Sasha Levin commit 07786d86e6da363cc6f6303ed5b120704ab468d1 Author: Greg KH Date: Mon Jun 12 15:09:09 2023 +0200 perf/core: Fix narrow startup race when creating the perf nr_addr_filters sysfs file [ Upstream commit 652ffc2104ec1f69dd4a46313888c33527145ccf ] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/2023061204-decal-flyable-6090@gregkh Signed-off-by: Sasha Levin commit f1c4ed0b5f8b11aa5cd725f2bbaaa9ba6f8738f3 Author: Raghavendra K T Date: Fri Oct 20 21:27:46 2023 +0530 sched/numa: Fix mm numa_scan_seq based unconditional scan [ Upstream commit 84db47ca7146d7bd00eb5cf2b93989a971c84650 ] Since commit fc137c0ddab2 ("sched/numa: enhance vma scanning logic") NUMA Balancing allows updating PTEs to trap NUMA hinting faults if the task had previously accessed VMA. However unconditional scan of VMAs are allowed during initial phase of VMA creation until process's mm numa_scan_seq reaches 2 even though current task had not accessed VMA. Rationale: - Without initial scan subsequent PTE update may never happen. - Give fair opportunity to all the VMAs to be scanned and subsequently understand the access pattern of all the VMAs. But it has a corner case where, if a VMA is created after some time, process's mm numa_scan_seq could be already greater than 2. For e.g., values of mm numa_scan_seq when VMAs are created by running mmtest autonuma benchmark briefly looks like: start_seq=0 : 459 start_seq=2 : 138 start_seq=3 : 144 start_seq=4 : 8 start_seq=8 : 1 start_seq=9 : 1 This results in no unconditional PTE updates for those VMAs created after some time. Fix: - Note down the initial value of mm numa_scan_seq in per VMA start_seq. - Allow unconditional scan till start_seq + 2. Result: SUT: AMD EPYC Milan with 2 NUMA nodes 256 cpus. base kernel: upstream 6.6-rc6 with Mels patches [1] applied. kernbench ========== base patched %gain Amean elsp-128 165.09 ( 0.00%) 164.78 * 0.19%* Duration User 41404.28 41375.08 Duration System 9862.22 9768.48 Duration Elapsed 519.87 518.72 Ops NUMA PTE updates 1041416.00 831536.00 Ops NUMA hint faults 263296.00 220966.00 Ops NUMA pages migrated 258021.00 212769.00 Ops AutoNUMA cost 1328.67 1114.69 autonumabench NUMA01_THREADLOCAL ================== Amean elsp-NUMA01_THREADLOCAL 81.79 (0.00%) 67.74 * 17.18%* Duration User 54832.73 47379.67 Duration System 75.00 185.75 Duration Elapsed 576.72 476.09 Ops NUMA PTE updates 394429.00 11121044.00 Ops NUMA hint faults 1001.00 8906404.00 Ops NUMA pages migrated 288.00 2998694.00 Ops AutoNUMA cost 7.77 44666.84 Signed-off-by: Raghavendra K T Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mel Gorman Link: https://lore.kernel.org/r/2ea7cbce80ac7c62e90cbfb9653a7972f902439f.1697816692.git.raghavendra.kt@amd.com Signed-off-by: Sasha Levin commit 6182cb4d5272087a05ebe9c828367ec933910ea8 Author: Zhiquan Li Date: Thu Oct 26 08:39:03 2023 +0800 x86/mce: Mark fatal MCE's page as poison to avoid panic in the kdump kernel [ Upstream commit 9f3b130048bfa2e44a8cfb1b616f826d9d5d8188 ] Memory errors don't happen very often, especially fatal ones. However, in large-scale scenarios such as data centers, that probability increases with the amount of machines present. When a fatal machine check happens, mce_panic() is called based on the severity grading of that error. The page containing the error is not marked as poison. However, when kexec is enabled, tools like makedumpfile understand when pages are marked as poison and do not touch them so as not to cause a fatal machine check exception again while dumping the previous kernel's memory. Therefore, mark the page containing the error as poisoned so that the kexec'ed kernel can avoid accessing the page. [ bp: Rewrite commit message and comment. ] Co-developed-by: Youquan Song Signed-off-by: Youquan Song Signed-off-by: Zhiquan Li Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Naoya Horiguchi Link: https://lore.kernel.org/r/20231014051754.3759099-1-zhiquan1.li@intel.com Signed-off-by: Sasha Levin commit 848e1d7fd710900397e1d0e7584680c1c04e3afd Author: Naveen N Rao Date: Thu Nov 23 12:47:05 2023 +0530 powerpc/lib: Validate size for vector operations [ Upstream commit 8f9abaa6d7de0a70fc68acaedce290c1f96e2e59 ] Some of the fp/vmx code in sstep.c assume a certain maximum size for the instructions being emulated. The size of those operations however is determined separately in analyse_instr(). Add a check to validate the assumption on the maximum size of the operations, so as to prevent any unintended kernel stack corruption. Signed-off-by: Naveen N Rao Reviewed-by: Gustavo A. R. Silva Build-tested-by: Gustavo A. R. Silva Signed-off-by: Michael Ellerman Link: https://msgid.link/20231123071705.397625-1-naveen@kernel.org Signed-off-by: Sasha Levin commit eec31eb2baf23f950448b8ba356b4b9d32b4add6 Author: Stephen Rothwell Date: Mon Nov 27 13:28:09 2023 +1100 powerpc: pmd_move_must_withdraw() is only needed for CONFIG_TRANSPARENT_HUGEPAGE [ Upstream commit 0d555b57ee660d8a871781c0eebf006e855e918d ] The linux-next build of powerpc64 allnoconfig fails with: arch/powerpc/mm/book3s64/pgtable.c:557:5: error: no previous prototype for 'pmd_move_must_withdraw' 557 | int pmd_move_must_withdraw(struct spinlock *new_pmd_ptl, | ^~~~~~~~~~~~~~~~~~~~~~ Caused by commit: c6345dfa6e3e ("Makefile.extrawarn: turn on missing-prototypes globally") Fix it by moving the function definition under CONFIG_TRANSPARENT_HUGEPAGE like the prototype. The function is only called when CONFIG_TRANSPARENT_HUGEPAGE=y. Signed-off-by: Stephen Rothwell [mpe: Flesh out change log from linux-next patch] Signed-off-by: Michael Ellerman Link: https://msgid.link/20231127132809.45c2b398@canb.auug.org.au Signed-off-by: Sasha Levin commit 042dd3ac6870e6c8769e72cba8da4c76a686fe86 Author: Jun'ichi Nomura Date: Wed Nov 29 15:44:49 2023 -0500 x86/boot: Ignore NMIs during very early boot [ Upstream commit 78a509fba9c9b1fcb77f95b7c6be30da3d24823a ] When there are two racing NMIs on x86, the first NMI invokes NMI handler and the 2nd NMI is latched until IRET is executed. If panic on NMI and panic kexec are enabled, the first NMI triggers panic and starts booting the next kernel via kexec. Note that the 2nd NMI is still latched. During the early boot of the next kernel, once an IRET is executed as a result of a page fault, then the 2nd NMI is unlatched and invokes the NMI handler. However, NMI handler is not set up at the early stage of boot, which results in a boot failure. Avoid such problems by setting up a NOP handler for early NMIs. [ mingo: Refined the changelog. ] Signed-off-by: Jun'ichi Nomura Signed-off-by: Derek Barbosa Signed-off-by: Ingo Molnar Cc: Kees Cook Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Andy Lutomirski Cc: "H. Peter Anvin" Cc: Peter Zijlstra Signed-off-by: Sasha Levin commit 668067fbfaf433278eee092910cfd4a9acf86352 Author: Michael Ellerman Date: Thu Nov 30 00:19:19 2023 +1100 powerpc/64s: Fix CONFIG_NUMA=n build due to create_section_mapping() [ Upstream commit ede66cd22441820cbd399936bf84fdc4294bc7fa ] With CONFIG_NUMA=n the build fails with: arch/powerpc/mm/book3s64/pgtable.c:275:15: error: no previous prototype for ‘create_section_mapping’ [-Werror=missing-prototypes] 275 | int __meminit create_section_mapping(unsigned long start, unsigned long end, | ^~~~~~~~~~~~~~~~~~~~~~ That happens because the prototype for create_section_mapping() is in asm/mmzone.h, but asm/mmzone.h is only included by linux/mmzone.h when CONFIG_NUMA=y. In fact the prototype is only needed by arch/powerpc/mm code, so move the prototype into arch/powerpc/mm/mmu_decl.h, which also fixes the build error. Signed-off-by: Michael Ellerman Link: https://msgid.link/20231129131919.2528517-5-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 66ddd3c89596ad7b3d1ce157af847d27b1ff84bb Author: Michael Ellerman Date: Thu Nov 30 22:44:32 2023 +1100 powerpc/mm: Fix build failures due to arch_reserved_kernel_pages() [ Upstream commit d8c3f243d4db24675b653f0568bb65dae34e6455 ] With NUMA=n and FA_DUMP=y or PRESERVE_FA_DUMP=y the build fails with: arch/powerpc/kernel/fadump.c:1739:22: error: no previous prototype for ‘arch_reserved_kernel_pages’ [-Werror=missing-prototypes] 1739 | unsigned long __init arch_reserved_kernel_pages(void) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ The prototype for arch_reserved_kernel_pages() is in include/linux/mm.h, but it's guarded by __HAVE_ARCH_RESERVED_KERNEL_PAGES. The powerpc headers define __HAVE_ARCH_RESERVED_KERNEL_PAGES in asm/mmzone.h, which is not included into the generic headers when NUMA=n. Move the definition of __HAVE_ARCH_RESERVED_KERNEL_PAGES into asm/mmu.h which is included regardless of NUMA=n. Additionally the ifdef around __HAVE_ARCH_RESERVED_KERNEL_PAGES needs to also check for CONFIG_PRESERVE_FA_DUMP. Signed-off-by: Michael Ellerman Link: https://msgid.link/20231130114433.3053544-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 0884f6aee51ec4620a6d913fe14aa68c90637a82 Author: Michael Ellerman Date: Thu Nov 30 22:44:33 2023 +1100 powerpc: Fix build error due to is_valid_bugaddr() [ Upstream commit f8d3555355653848082c351fa90775214fb8a4fa ] With CONFIG_GENERIC_BUG=n the build fails with: arch/powerpc/kernel/traps.c:1442:5: error: no previous prototype for ‘is_valid_bugaddr’ [-Werror=missing-prototypes] 1442 | int is_valid_bugaddr(unsigned long addr) | ^~~~~~~~~~~~~~~~ The prototype is only defined, and the function is only needed, when CONFIG_GENERIC_BUG=y, so move the implementation under that. Signed-off-by: Michael Ellerman Link: https://msgid.link/20231130114433.3053544-2-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit ccf24e91ec189f4bb408c353d572d5f9890d1056 Author: Mark Rutland Date: Mon Dec 4 11:58:47 2023 +0000 drivers/perf: pmuv3: don't expose SW_INCR event in sysfs [ Upstream commit ca6f537e459e2da4b331fe8928d1a0b0f9301f42 ] The SW_INCR event is somewhat unusual, and depends on the specific HW counter that it is programmed into. When programmed into PMEVCNTR, SW_INCR will count any writes to PMSWINC_EL0 with bit n set, ignoring writes to SW_INCR with bit n clear. Event rotation means that there's no fixed relationship between perf_events and HW counters, so this isn't all that useful. Further, we program PMUSERENR.{SW,EN}=={0,0}, which causes EL0 writes to PMSWINC_EL0 to be trapped and handled as UNDEFINED, resulting in a SIGILL to userspace. Given that, it's not a good idea to expose SW_INCR in sysfs. Hide it as we did for CHAIN back in commit: 4ba2578fa7b55701 ("arm64: perf: don't expose CHAIN event in sysfs") Signed-off-by: Mark Rutland Cc: Will Deacon Link: https://lore.kernel.org/r/20231204115847.2993026-1-mark.rutland@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8ba9ec639019aef9e2271858c2b70499edf4e54e Author: Huang Shijie Date: Fri Nov 24 11:15:13 2023 +0800 arm64: irq: set the correct node for VMAP stack [ Upstream commit 75b5e0bf90bffaca4b1f19114065dc59f5cc161f ] In current code, init_irq_stacks() will call cpu_to_node(). The cpu_to_node() depends on percpu "numa_node" which is initialized in: arch_call_rest_init() --> rest_init() -- kernel_init() --> kernel_init_freeable() --> smp_prepare_cpus() But init_irq_stacks() is called in init_IRQ() which is before arch_call_rest_init(). So in init_irq_stacks(), the cpu_to_node() does not work, it always return 0. In NUMA, it makes the node 1 cpu accesses the IRQ stack which is in the node 0. This patch fixes it by: 1.) export the early_cpu_to_node(), and use it in the init_irq_stacks(). 2.) change init_irq_stacks() to __init function. Reviewed-by: Catalin Marinas Signed-off-by: Huang Shijie Link: https://lore.kernel.org/r/20231124031513.81548-1-shijie@os.amperecomputing.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ffd29dc45bc0355393859049f6becddc3ed08f74 Author: Kunwu Chan Date: Mon Dec 4 10:32:23 2023 +0800 powerpc/mm: Fix null-pointer dereference in pgtable_cache_add [ Upstream commit f46c8a75263f97bda13c739ba1c90aced0d3b071 ] kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Suggested-by: Christophe Leroy Suggested-by: Michael Ellerman Signed-off-by: Kunwu Chan Signed-off-by: Michael Ellerman Link: https://msgid.link/20231204023223.2447523-1-chentao@kylinos.cn Signed-off-by: Sasha Levin commit 60c333480967c643892f856e88d226f3126fe3a4 Author: Dmitry Torokhov Date: Sun Jan 7 22:16:45 2024 -0800 asm-generic: make sparse happy with odd-sized put_unaligned_*() [ Upstream commit 1ab33c03145d0f6c345823fc2da935d9a1a9e9fc ] __put_unaligned_be24() and friends use implicit casts to convert larger-sized data to bytes, which trips sparse truncation warnings when the argument is a constant: CC [M] drivers/input/touchscreen/hynitron_cstxxx.o CHECK drivers/input/touchscreen/hynitron_cstxxx.c drivers/input/touchscreen/hynitron_cstxxx.c: note: in included file (through arch/x86/include/generated/asm/unaligned.h): include/asm-generic/unaligned.h:119:16: warning: cast truncates bits from constant value (aa01a0 becomes a0) include/asm-generic/unaligned.h:120:20: warning: cast truncates bits from constant value (aa01 becomes 1) include/asm-generic/unaligned.h:119:16: warning: cast truncates bits from constant value (ab00d0 becomes d0) include/asm-generic/unaligned.h:120:20: warning: cast truncates bits from constant value (ab00 becomes 0) To avoid this let's mask off upper bits explicitly, the resulting code should be exactly the same, but it will keep sparse happy. Reported-by: kernel test robot Suggested-by: Linus Torvalds Closes: https://lore.kernel.org/oe-kbuild-all/202401070147.gqwVulOn-lkp@intel.com/ Signed-off-by: Dmitry Torokhov Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin