summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-01-19devlink: remove reporter reference countingJiri Pirko
As long as the reporter life time is protected by devlink instance lock, the reference counting is no longer needed. Remove it. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19devlink: remove devl*_port_health_reporter_destroy()Jiri Pirko
Remove port-specific health reporter destroy function as it is currently the same as the instance one so no longer needed. Inline __devlink_health_reporter_destroy() as it is no longer called from multiple places. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19devlink: remove reporters_lockJiri Pirko
Similar to other devlink objects, rely on devlink instance lock and remove object specific reporters_lock. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19devlink: protect health reporter operation with instance lockJiri Pirko
Similar to other devlink objects, protect the reporters list by devlink instance lock. Alongside add unlocked versions of health reporter create/destroy functions and use them in drivers on call paths where the instance lock is held. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net/mlx5: Remove MLX5E_LOCKED_FLOW flagJiri Pirko
The MLX5E_LOCKED_FLOW flag is not checked anywhere now so remove it entirely. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net/mlx5e: Create separate devlink instance for ethernet auxiliary deviceJiri Pirko
The fact that devlink instance lock is held over mlx5 auxiliary devices probe and remove routines brought a need to conditionally take devlink instance lock there. The code is checking a MLX5E_LOCKED_FLOW flag in mlx5 priv struct. This is racy and may lead to access devlink objects without holding instance lock or deadlock. To avoid this, the only lock-wise sane solution is to make the devlink entities created by the auxiliary device independent on the original pci devlink instance. Create devlink instance for the auxiliary device and put the uplink port instance there alongside with the port health reporters. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19devlink: remove linecard reference countingJiri Pirko
As long as the linecard life time is protected by devlink instance lock, the reference counting is no longer needed. Remove it. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19devlink: remove linecards lockJiri Pirko
Similar to other devlink objects, convert the linecards list to be protected by devlink instance lock. Alongside with that rename the create/destroy() functions to devl_* to indicate the devlink instance lock needs to be held while calling them. Signed-off-by: Jiri Pirko <jiri@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: ethernet: ti: am65-cpsw: Handle -EPROBE_DEFER for Serdes PHYSiddharth Vadapalli
In the am65_cpsw_init_serdes_phy() function, the error handling for the call to the devm_of_phy_get() function misses the case where the return value of devm_of_phy_get() is ERR_PTR(-EPROBE_DEFER). Proceeding without handling this case will result in a crash when the "phy" pointer with this value is dereferenced by phy_init() in am65_cpsw_enable_phy(). Fix this by adding appropriate error handling code. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: dab2b265dd23 ("net: ethernet: ti: am65-cpsw: Add support for SERDES configuration") Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Reviewed-by: Roger Quadros <rogerq@kernel.org> Link: https://lore.kernel.org/r/20230118112136.213061-1-s-vadapalli@ti.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: dsa: microchip: ptp: Fix error code in ksz_hwtstamp_set()Dan Carpenter
We want to return negative error codes here but the copy_to/from_user() functions return the number of bytes remaining to be copied. Fixes: c59e12a140fb ("net: dsa: microchip: ptp: Initial hardware time stamping support") Signed-off-by: Dan Carpenter <error27@gmail.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/Y8fJxSvbl7UNVHh/@kili Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19Merge branch 'net-sfp-cleanup-i2c-dt-acpi-fwnode-includes'Jakub Kicinski
Russell King says: ==================== net: sfp: cleanup i2c / dt / acpi / fwnode / includes This series cleans up the DT/fwnode/ACPI code in the SFP cage driver: 1. Use the newly introduced i2c_get_adapter_by_fwnode(), which removes the need to know about ACPI handles to find the I2C device. 2. Use device_get_match_data() to get the match data, rather than having to look up the matching DT device_id to get at the data. 3. Rename gpio_of_names, as this is not DT specific. 4. Remove acpi.h include which is no longer necessary. 5. Remove ctype.h include which, as far as I can tell, was never necessary. ==================== Link: https://lore.kernel.org/r/Y8fH+Vqx6huYQFDU@shell.armlinux.org.uk Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: sfp: remove unused ctype.h includeRussell King (Oracle)
An include of linux/ctype.h was added in commit 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") but nothing was used from this header file. Remove this unnecessary include. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: sfp: remove acpi.h includeRussell King (Oracle)
Nothing in the sfp code now references anything from the ACPI header, everything is done via fwnode APIs, so get rid of this header. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: sfp: rename gpio_of_names[]Russell King (Oracle)
There's nothing DT specific about the gpio_of_names array, let's drop the _of infix. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: sfp: use device_get_match_data()Russell King (Oracle)
Rather than using of_match_node() to get the matching of_device_id to then retrieve the match data, use device_get_match_data() instead to avoid firmware specific functions, and free the driver from having firmware specific code. Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net: sfp: use i2c_get_adapter_by_fwnode()Russell King (Oracle)
Use the newly introduced i2c_get_adapter_by_fwnode() API, so that we can retrieve the I2C adapter in a firmware independent manner once we have the fwnode handle for the adapter. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-20Merge tag 'amd-drm-fixes-6.2-2023-01-19' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes amd-drm-fixes-6.2-2023-01-19: amdgpu: - Fix display scaling - Fix RN/CZN power reporting on some firmware versions - Colorspace fixes - Fix resource freeing in error case in CS IOCTL - Fix warning on driver unload - GC11 fixes - DCN 3.1.4/5 S/G display workarounds Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230119195908.7670-1-alexander.deucher@amd.com
2023-01-20Merge tag 'drm-misc-fixes-2023-01-19' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes A fix for vc4 to address a memory leak when allocating a buffer, a Kconfig fix for panfrost and two fixes for i915 and fb-helper to address some bugs with vga-switcheroo. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230119082059.h32bs7zqoxmjbcvn@houat
2023-01-19Merge branch 'kallsyms: Optimize the search for module symbols by livepatch ↵Alexei Starovoitov
and bpf' Jiri Olsa says: ==================== hi, sending new version of [1] patchset posted originally by Zhen Lei. It contains 2 changes that improove search performance for livepatch and bpf. v3 changes: - fixed off by 1 issue, simplified condition, added acks [Song] - added module attach as subtest [Andrii] v2 changes: - reworked the bpf change and meassured the performance - adding new selftest to benchmark kprobe multi module attachment - skipping patch 3 as requested by Zhen Lei - added Reviewed-by for patch 1 [Petr Mladek] thanks, jirka [1] https://lore.kernel.org/bpf/20221230112729.351-1-thunder.leizhen@huawei.com/ --- Jiri Olsa (2): selftests/bpf: Add serial_test_kprobe_multi_bench_attach_kernel/module tests bpf: Change modules resolving for kprobe multi link ==================== Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19bpf: Change modules resolving for kprobe multi linkJiri Olsa
We currently use module_kallsyms_on_each_symbol that iterates all modules/symbols and we try to lookup each such address in user provided symbols/addresses to get list of used modules. This fix instead only iterates provided kprobe addresses and calls __module_address on each to get list of used modules. This turned out to be simpler and also bit faster. On my setup with workload (executed 10 times): # test_progs -t kprobe_multi_bench_attach/modules Current code: Performance counter stats for './test.sh' (5 runs): 76,081,161,596 cycles:k ( +- 0.47% ) 18.3867 +- 0.0992 seconds time elapsed ( +- 0.54% ) With the fix: Performance counter stats for './test.sh' (5 runs): 74,079,889,063 cycles:k ( +- 0.04% ) 17.8514 +- 0.0218 seconds time elapsed ( +- 0.12% ) Signed-off-by: Jiri Olsa <jolsa@kernel.org> Reviewed-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20230116101009.23694-4-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19selftests/bpf: Add serial_test_kprobe_multi_bench_attach_kernel/module testsJiri Olsa
Add bench test for module portion of the symbols as well. # ./test_progs -v -t kprobe_multi_bench_attach_module bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_kprobe_multi_bench_attach:PASS:get_syms 0 nsec test_kprobe_multi_bench_attach:PASS:kprobe_multi_empty__open_and_load 0 nsec test_kprobe_multi_bench_attach:PASS:bpf_program__attach_kprobe_multi_opts 0 nsec test_kprobe_multi_bench_attach: found 26620 functions test_kprobe_multi_bench_attach: attached in 0.182s test_kprobe_multi_bench_attach: detached in 0.082s #96 kprobe_multi_bench_attach_module:OK Summary: 1/0 PASSED, 0 SKIPPED, 0 FAILED Successfully unloaded bpf_testmod.ko. It's useful for testing kprobe multi link modules resolving. Acked-by: Song Liu <song@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/r/20230116101009.23694-3-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19livepatch: Improve the search performance of module_kallsyms_on_each_symbol()Zhen Lei
Currently we traverse all symbols of all modules to find the specified function for the specified module. But in reality, we just need to find the given module and then traverse all the symbols in it. Let's add a new parameter 'const char *modname' to function module_kallsyms_on_each_symbol(), then we can compare the module names directly in this function and call hook 'fn' after matching. If 'modname' is NULL, the symbols of all modules are still traversed for compatibility with other usage cases. Phase1: mod1-->mod2..(subsequent modules do not need to be compared) | Phase2: -->f1-->f2-->f3 Assuming that there are m modules, each module has n symbols on average, then the time complexity is reduced from O(m * n) to O(m) + O(n). Reviewed-by: Petr Mladek <pmladek@suse.com> Acked-by: Song Liu <song@kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Acked-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org> Link: https://lore.kernel.org/r/20230116101009.23694-2-jolsa@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19riscv: fix -Wundef warning for CONFIG_RISCV_BOOT_SPINWAITMasahiro Yamada
Since commit 80b6093b55e3 ("kbuild: add -Wundef to KBUILD_CPPFLAGS for W=1 builds"), building with W=1 detects misuse of #if. $ make W=1 ARCH=riscv CROSS_COMPILE=riscv64-linux-gnu- arch/riscv/kernel/ [snip] AS arch/riscv/kernel/head.o arch/riscv/kernel/head.S:329:5: warning: "CONFIG_RISCV_BOOT_SPINWAIT" is not defined, evaluates to 0 [-Wundef] 329 | #if CONFIG_RISCV_BOOT_SPINWAIT | ^~~~~~~~~~~~~~~~~~~~~~~~~~ CONFIG_RISCV_BOOT_SPINWAIT is a bool option. #ifdef should be used. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Fixes: 2ffc48fc7071 ("RISC-V: Move spinwait booting method to its own config") Link: https://lore.kernel.org/r/20230106161213.2374093-1-masahiroy@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-01-19MAINTAINERS: add an IRC entry for RISC-VConor Dooley
I remember being told "Just ping me on IRC" about patches, but googling at the time was not helpful. #riscv on libera is not linux specific, but a bunch of contributors etc do hang out there. Add a link to the maintainers entry to help others find it in the future! Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230106125344.1685266-1-conor@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-01-19RISC-V: fix compile error from deduplicated __ALTERNATIVE_CFG_2Heiko Stuebner
On the non-assembler-side wrapping alternative-macros inside other macros to prevent duplication of code works, as the end result will just be a string that gets fed to the asm instruction. In real assembler code, wrapping .macro blocks inside other .macro blocks brings more restrictions on usage it seems and the optimization done by commit 2ba8c7dc71c0 ("riscv: Don't duplicate __ALTERNATIVE_CFG in __ALTERNATIVE_CFG_2") results in a compile error like: ../arch/riscv/lib/strcmp.S: Assembler messages: ../arch/riscv/lib/strcmp.S:15: Error: too many positional arguments ../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "886:" ../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "887:" ../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "886:" ../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "887:" ../arch/riscv/lib/strcmp.S:15: Error: backward ref to unknown label "886:" ../arch/riscv/lib/strcmp.S:15: Error: attempt to move .org backwards Wrapping the variables containing assembler code in quotes solves this issue, compilation and the code in question still works and objdump also shows sane decompiled results of the affected code. Fixes: 2ba8c7dc71c0 ("riscv: Don't duplicate __ALTERNATIVE_CFG in __ALTERNATIVE_CFG_2") Signed-off-by: Heiko Stuebner <heiko.stuebner@vrull.eu> Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Link: https://lore.kernel.org/r/20230105192610.1940841-1-heiko@sntech.de Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-01-20Merge tag 'drm-intel-fixes-2023-01-19' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Reject display plane with height == 0 (Drew) - re-disable RC6p on Sandy Bridge (Sasa) - Fix hugepages' selftest (Chris) - DG2 hw workarounds (Matt Atwood) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/Y8mf3/ANNWctpc7R@intel.com
2023-01-19Merge tag 'perf-tools-fixes-for-v6.2-3-2023-01-19' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull perf tools fixes from Arnaldo Carvalho de Melo: - Prevent reading into undefined memory in the expression lexer, accounting for a trailer backslash followed by the null byte. - Fix file mode when copying files to the build id cache, the problem happens when the cache directory is in a different file system than the file being cached, otherwise the mode was preserved as only a hard link would be done to save space. - Fix a related build-id 'perf test' entry that checked that permission when caching PE (Portable Executable) files, used when profiling Windows executables under wine. - Sync the tools/ copies of kvm headers, build_bug.h, socket.h and arm64's cputype.h with the kernel sources. * tag 'perf-tools-fixes-for-v6.2-3-2023-01-19' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: perf test build-id: Fix test check for PE file perf buildid-cache: Fix the file mode with copyfile() while adding file to build-id cache perf expr: Prevent normalize() from reading into undefined memory in the expression lexer tools headers: Syncronize linux/build_bug.h with the kernel sources perf beauty: Update copy of linux/socket.h with the kernel sources tools headers arm64: Sync arm64's cputype.h with the kernel sources tools kvm headers arm64: Update KVM header from the kernel sources tools headers UAPI: Sync x86's asm/kvm.h with the kernel sources tools headers UAPI: Sync linux/kvm.h with the kernel sources
2023-01-19Merge branch 'bpf: Fix to preserve reg parent/live fields when copying range ↵Alexei Starovoitov
info' Eduard Zingerman says: ==================== Struct bpf_reg_state is copied directly in several places including: - check_stack_write_fixed_off() (via save_register_state()); - check_stack_read_fixed_off(); - find_equal_scalars(). However, a literal copy of this struct also copies the following fields: struct bpf_reg_state { ... struct bpf_reg_state *parent; ... enum bpf_reg_liveness live; ... }; This breaks register parentage chain and liveness marking logic. The commit message for the first patch has a detailed example. This patch-set replaces direct copies with a call to a function copy_register_state(dst,src), which preserves 'parent' and 'live' fields of the 'dst'. The fix comes with a significant verifier runtime penalty for some selftest binaries listed in tools/testing/selftests/bpf/veristat.cfg and cilium BPF binaries (see [1]): $ ./veristat -e file,prog,states -C -f 'states_diff>10' master-baseline.log current.log File Program States (A) States (B) States (DIFF) -------------------------- -------------------------------- ---------- ---------- --------------- bpf_host.o tail_handle_ipv4_from_host 231 299 +68 (+29.44%) bpf_host.o tail_handle_nat_fwd_ipv4 1088 1320 +232 (+21.32%) bpf_host.o tail_handle_nat_fwd_ipv6 716 729 +13 (+1.82%) bpf_host.o tail_nodeport_nat_ingress_ipv4 281 314 +33 (+11.74%) bpf_host.o tail_nodeport_nat_ingress_ipv6 245 256 +11 (+4.49%) bpf_lxc.o tail_handle_nat_fwd_ipv4 1088 1320 +232 (+21.32%) bpf_lxc.o tail_handle_nat_fwd_ipv6 716 729 +13 (+1.82%) bpf_lxc.o tail_ipv4_ct_egress 239 262 +23 (+9.62%) bpf_lxc.o tail_ipv4_ct_ingress 239 262 +23 (+9.62%) bpf_lxc.o tail_ipv4_ct_ingress_policy_only 239 262 +23 (+9.62%) bpf_lxc.o tail_ipv6_ct_egress 181 195 +14 (+7.73%) bpf_lxc.o tail_ipv6_ct_ingress 181 195 +14 (+7.73%) bpf_lxc.o tail_ipv6_ct_ingress_policy_only 181 195 +14 (+7.73%) bpf_lxc.o tail_nodeport_nat_ingress_ipv4 281 314 +33 (+11.74%) bpf_lxc.o tail_nodeport_nat_ingress_ipv6 245 256 +11 (+4.49%) bpf_overlay.o tail_handle_nat_fwd_ipv4 799 829 +30 (+3.75%) bpf_overlay.o tail_nodeport_nat_ingress_ipv4 281 314 +33 (+11.74%) bpf_overlay.o tail_nodeport_nat_ingress_ipv6 245 256 +11 (+4.49%) bpf_sock.o cil_sock4_connect 47 70 +23 (+48.94%) bpf_sock.o cil_sock4_sendmsg 45 68 +23 (+51.11%) bpf_sock.o cil_sock6_post_bind 31 42 +11 (+35.48%) bpf_xdp.o tail_lb_ipv4 4413 6457 +2044 (+46.32%) bpf_xdp.o tail_lb_ipv6 6876 7249 +373 (+5.42%) test_cls_redirect.bpf.o cls_redirect 4704 4799 +95 (+2.02%) test_tcp_hdr_options.bpf.o estab 180 206 +26 (+14.44%) xdp_synproxy_kern.bpf.o syncookie_tc 21059 21485 +426 (+2.02%) xdp_synproxy_kern.bpf.o syncookie_xdp 21857 23122 +1265 (+5.79%) -------------------------- -------------------------------- ---------- ---------- --------------- I looked through verification log for bpf_xdp.o tail_lb_ipv4 program in order to identify the reason for ~50% visited states increase. The slowdown is triggered by a difference in handling of three stack slots: fp-56, fp-72 and fp-80, with the main difference coming from fp-72. In fact the following change removes all the difference: @@ -3256,7 +3256,10 @@ static void save_register_state(struct bpf_func_state *state, { int i; - copy_register_state(&state->stack[spi].spilled_ptr, reg); + if ((spi == 6 /*56*/ || spi == 8 /*72*/ || spi == 9 /*80*/) && size != BPF_REG_SIZE) + state->stack[spi].spilled_ptr = *reg; + else + copy_register_state(&state->stack[spi].spilled_ptr, reg); For fp-56 I found the following pattern for divergences between verification logs with and w/o this patch: - At some point insn 1862 is reached and checkpoint is created; - At some other point insn 1862 is reached again: - with this patch: - the current state is considered *not* equivalent to the old checkpoint; - the reason for mismatch is the state of fp-56: - current state: fp-56=????mmmm - checkpoint: fp-56_rD=mmmmmmmm - without this patch the current state is considered equivalent to the checkpoint, the fp-56 is not present in the checkpoint. Here is a fragment of the verification log for when the checkpoint in question created at insn 1862: checkpoint 1862: ... fp-56=mmmmmmmm ... 1862: ... 1863: ... 1864: (61) r1 = *(u32 *)(r0 +0) 1865: ... 1866: (63) *(u32 *)(r10 -56) = r1 ; R1_w=scalar(...) R10=fp0 fp-56= 1867: (bf) r2 = r10 ; R2_w=fp0 R10=fp0 1868: (07) r2 += -56 ; R2_w=fp-56 ; return map_lookup_elem(&LB4_BACKEND_MAP_V2, &backend_id); 1869: (18) r1 = 0xffff888100286000 ; R1_w=map_ptr(off=0,ks=4,vs=8,imm=0) 1871: (85) call bpf_map_lookup_elem#1 - Without this patch: - at insn 1864 r1 liveness is set to REG_LIVE_WRITTEN; - at insn 1866 fp-56 liveness is set REG_LIVE_WRITTEN mark because of the direct r1 copy in save_register_state(); - at insn 1871 REG_LIVE_READ is not propagated to fp-56 at checkpoint 1862 because of the REG_LIVE_WRITTEN mark; - eventually fp-56 is pruned from checkpoint at 1862 in clean_func_state(). - With this patch: - at insn 1864 r1 liveness is set to REG_LIVE_WRITTEN; - at insn 1866 fp-56 liveness is *not* set to REG_LIVE_WRITTEN mark because write size is not equal to BPF_REG_SIZE; - at insn 1871 REG_LIVE_READ is propagated to fp-56 at checkpoint 1862. Hence more states have to be visited by verifier with this patch compared to current master. Similar patterns could be found for both fp-72 and fp-80, although these are harder to track trough the log because of a big number of insns between slot write and bpf_map_lookup_elem() call triggering read mark, boils down to the following C code: struct ipv4_frag_id frag_id = { .daddr = ip4->daddr, .saddr = ip4->saddr, .id = ip4->id, .proto = ip4->protocol, .pad = 0, }; ... map_lookup_elem(..., &frag_id); Where: - .id is mapped to fp-72, write of size u16; - .saddr is mapped to fp-80, write of size u32. This patch-set is a continuation of discussion from [2]. Changes v1 -> v2 (no changes in the code itself): - added analysis for the tail_lb_ipv4 verification slowdown; - rebase against fresh master branch. [1] git@github.com:anakryiko/cilium.git [2] https://lore.kernel.org/bpf/517af2c57ee4b9ce2d96a8cf33f7295f2d2dfe13.camel@gmail.com/ ==================== Acked-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19selftests/bpf: Verify copy_register_state() preserves parent/live fieldsEduard Zingerman
A testcase to check that verifier.c:copy_register_state() preserves register parentage chain and livness information. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20230106142214.1040390-3-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19bpf: Fix to preserve reg parent/live fields when copying range infoEduard Zingerman
Register range information is copied in several places. The intent is to transfer range/id information from one register/stack spill to another. Currently this is done using direct register assignment, e.g.: static void find_equal_scalars(..., struct bpf_reg_state *known_reg) { ... struct bpf_reg_state *reg; ... *reg = *known_reg; ... } However, such assignments also copy the following bpf_reg_state fields: struct bpf_reg_state { ... struct bpf_reg_state *parent; ... enum bpf_reg_liveness live; ... }; Copying of these fields is accidental and incorrect, as could be demonstrated by the following example: 0: call ktime_get_ns() 1: r6 = r0 2: call ktime_get_ns() 3: r7 = r0 4: if r0 > r6 goto +1 ; r0 & r6 are unbound thus generated ; branch states are identical 5: *(u64 *)(r10 - 8) = 0xdeadbeef ; 64-bit write to fp[-8] --- checkpoint --- 6: r1 = 42 ; r1 marked as written 7: *(u8 *)(r10 - 8) = r1 ; 8-bit write, fp[-8] parent & live ; overwritten 8: r2 = *(u64 *)(r10 - 8) 9: r0 = 0 10: exit This example is unsafe because 64-bit write to fp[-8] at (5) is conditional, thus not all bytes of fp[-8] are guaranteed to be set when it is read at (8). However, currently the example passes verification. First, the execution path 1-10 is examined by verifier. Suppose that a new checkpoint is created by is_state_visited() at (6). After checkpoint creation: - r1.parent points to checkpoint.r1, - fp[-8].parent points to checkpoint.fp[-8]. At (6) the r1.live is set to REG_LIVE_WRITTEN. At (7) the fp[-8].parent is set to r1.parent and fp[-8].live is set to REG_LIVE_WRITTEN, because of the following code called in check_stack_write_fixed_off(): static void save_register_state(struct bpf_func_state *state, int spi, struct bpf_reg_state *reg, int size) { ... state->stack[spi].spilled_ptr = *reg; // <--- parent & live copied if (size == BPF_REG_SIZE) state->stack[spi].spilled_ptr.live |= REG_LIVE_WRITTEN; ... } Note the intent to mark stack spill as written only if 8 bytes are spilled to a slot, however this intent is spoiled by a 'live' field copy. At (8) the checkpoint.fp[-8] should be marked as REG_LIVE_READ but this does not happen: - fp[-8] in a current state is already marked as REG_LIVE_WRITTEN; - fp[-8].parent points to checkpoint.r1, parentage chain is used by mark_reg_read() to mark checkpoint states. At (10) the verification is finished for path 1-10 and jump 4-6 is examined. The checkpoint.fp[-8] never gets REG_LIVE_READ mark and this spill is pruned from the cached states by clean_live_states(). Hence verifier state obtained via path 1-4,6 is deemed identical to one obtained via path 1-6 and program marked as safe. Note: the example should be executed with BPF_F_TEST_STATE_FREQ flag set to force creation of intermediate verifier states. This commit revisits the locations where bpf_reg_state instances are copied and replaces the direct copies with a call to a function copy_register_state(dst, src) that preserves 'parent' and 'live' fields of the 'dst'. Fixes: 679c782de14b ("bpf/verifier: per-register parent pointers") Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20230106142214.1040390-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-01-19acpi: Fix suspend with Xen PVJuergen Gross
Commit f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") missed one code path accessing real_mode_header, leading to dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20 Fix that by adding an optional acpi callback allowing to skip setting the wakeup address, as in the Xen PV case this will be handled by the hypervisor anyway. Fixes: f1e525009493 ("x86/boot: Skip realmode init code when running as Xen PV guest") Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Juergen Gross <jgross@suse.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/all/20230117155724.22940-1-jgross%40suse.com
2023-01-20Merge tag 'drm-msm-fixes-2023-01-16' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/msm into drm-fixes msm-fixes for v6.3-rc5 Two GPU fixes which were meant to be part of the previous pull request, but I'd forgotten to fetch from gitlab after the MR was merged so that git tag was applied to the wrong commit. - kexec shutdown fix - fix potential double free Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGskguoVsz2wqAK2k+f32LwcVY5JC6+e2RwLqZswz3RY2Q@mail.gmail.com
2023-01-19Merge tag 'printk-for-6.2-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux Pull printk fixes from Petr Mladek: - Prevent a potential deadlock when configuring kgdb console - Fix a kernel doc warning * tag 'printk-for-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/printk/linux: kernel/printk/printk.c: Fix W=1 kernel-doc warning tty: serial: kgdboc: fix mutex locking order for configure_kgdboc()
2023-01-19Merge tag 's390-6.2-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux Pull s390 build fix from Heiko Carstens: - Workaround invalid gcc-11 out of bounds read warning caused by s390's S390_lowcore definition. This happens only with gcc 11.1.0 and 11.2.0. The code which causes this warning will be gone with the next merge window. Therefore just replace the memcpy() with a for loop to get rid of the warning. * tag 's390-6.2-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390: workaround invalid gcc-11 out of bounds read warning
2023-01-19Merge tag 'slab-for-6.2-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab Pull slab fix from Vlastimil Babka: "Just a single fix, since the lkp report originally for a slub-tiny commit ended up being a gcov/compiler bug: - periodically resched in SLAB's drain_freelist(), by David Rientjes" * tag 'slab-for-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab: mm, slab: periodically resched in drain_freelist()
2023-01-19thermal: core: call put_device() only after device_register() failsViresh Kumar
put_device() shouldn't be called before a prior call to device_register(). __thermal_cooling_device_register() doesn't follow that properly and needs fixing. Also thermal_cooling_device_destroy_sysfs() is getting called unnecessarily on few error paths. Fix all this by placing the calls at the right place. Based on initial work done by Caleb Connolly. Fixes: 4748f9687caa ("thermal: core: fix some possible name leaks in error paths") Fixes: c408b3d1d9bb ("thermal: Validate new state in cur_state_store()") Reported-by: Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Tested-by: Frank Rowand <frowand.list@gmail.com> Reviewed-by: Yang Yingliang <yangyingliang@huawei.com> Tested-by: Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2023-01-19Merge tag 'usb-serial-6.2-rc5' of ↵Greg Kroah-Hartman
https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus Johan writes: "USB-serial fixes for 6.2-rc5 Here are some new device ids, mostly for Quectel modems. All have been in linux-next with no reported issues." * tag 'usb-serial-6.2-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Quectel EM05CN modem USB: serial: option: add Quectel EM05CN (SG) modem USB: serial: cp210x: add SCALANCE LPE-9000 device id USB: serial: option: add Quectel EC200U modem USB: serial: option: add Quectel EM05-G (RS) modem USB: serial: option: add Quectel EM05-G (GR) modem USB: serial: option: add Quectel EM05-G (CS) modem
2023-01-19wifi: wireless: deny wireless extensions on MLO-capable devicesJohannes Berg
These are WiFi 7 devices that will be introduced into the market in 2023, with new drivers. Wireless extensions haven't been in real development since 2006. Since wireless has evolved a lot, and continues to evolve significantly with Multi-Link Operation, there's really no good way to still support wireless extensions for devices that do MLO. Stop supporting wireless extensions for new devices. We don't consider this a regression since no such devices (apart from hwsim) exist yet. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230118105152.45f85078a1e0.Ib9eabc2ec5bf6b0244e4d973e93baaa3d8c91bd8@changeid
2023-01-19wifi: wireless: warn on most wireless extension usageJohannes Berg
With WiFi 7 (802.11ax, MLO/EHT) around the corner, we're going to remove support for wireless extensions with new devices since MLO (multi-link operation) cannot be properly indicated using them. Add a warning to indicate which processes are still using wireless extensions, if being used with modern (i.e. cfg80211) drivers. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230118105152.a7158a929a6f.Ifcf30eeeb8fc7019e4dcf2782b04515254d165e1@changeid
2023-01-19Merge tag 'zonefs-6.2-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs Pull zonefs fix from Damien Le Moal: - A single patch to fix sync write operations to detect and handle errors due to external zone corruptions resulting in writes at invalid location, from me. * tag 'zonefs-6.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/zonefs: zonefs: Detect append writes at invalid locations
2023-01-19io_uring/msg_ring: fix missing lock on overflow for IOPOLLJens Axboe
If the target ring is configured with IOPOLL, then we always need to hold the target ring uring_lock before posting CQEs. We could just grab it unconditionally, but since we don't expect many target rings to be of this type, make grabbing the uring_lock conditional on the ring type. Link: https://lore.kernel.org/io-uring/Y8krlYa52%2F0YGqkg@ip-172-31-85-199.ec2.internal/ Reported-by: Xingyuan Mo <hdthky0@gmail.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2023-01-19net: dsa: microchip: ksz9477: port map correction in ALU table entry registerRakesh Sankaranarayanan
ALU table entry 2 register in KSZ9477 have bit positions reserved for forwarding port map. This field is referred in ksz9477_fdb_del() for clearing forward port map and alu table. But current fdb_del refer ALU table entry 3 register for accessing forward port map. Update ksz9477_fdb_del() to get forward port map from correct alu table entry register. With this bug, issue can be observed while deleting static MAC entries. Delete any specific MAC entry using "bridge fdb del" command. This should clear all the specified MAC entries. But it is observed that entries with self static alone are retained. Tested on LAN9370 EVB since ksz9477_fdb_del() is used common across LAN937x and KSZ series. Fixes: b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477") Signed-off-by: Rakesh Sankaranarayanan <rakesh.sankaranarayanan@microchip.com> Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20230118174735.702377-1-rakesh.sankaranarayanan@microchip.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19selftests/net: toeplitz: fix race on tpacket_v3 block closeWillem de Bruijn
Avoid race between process wakeup and tpacket_v3 block timeout. The test waits for cfg_timeout_msec for packets to arrive. Packets arrive in tpacket_v3 rings, which pass packets ("frames") to the process in batches ("blocks"). The sk waits for req3.tp_retire_blk_tov msec to release a block. Set the block timeout lower than the process waiting time, else the process may find that no block has been released by the time it scans the socket list. Convert to a ring of more than one, smaller, blocks with shorter timeouts. Blocks must be page aligned, so >= 64KB. Fixes: 5ebfb4cc3048 ("selftests/net: toeplitz test") Signed-off-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20230118151847.4124260-1-willemdebruijn.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19net/ulp: use consistent error code when blocking ULPPaolo Abeni
The referenced commit changed the error code returned by the kernel when preventing a non-established socket from attaching the ktls ULP. Before to such a commit, the user-space got ENOTCONN instead of EINVAL. The existing self-tests depend on such error code, and the change caused a failure: RUN global.non_established ... tls.c:1673:non_established:Expected errno (22) == ENOTCONN (107) non_established: Test failed at step #3 FAIL global.non_established In the unlikely event existing applications do the same, address the issue by restoring the prior error code in the above scenario. Note that the only other ULP performing similar checks at init time - smc_ulp_ops - also fails with ENOTCONN when trying to attach the ULP to a non-established socket. Reported-by: Sabrina Dubroca <sd@queasysnail.net> Fixes: 2c02d41d71f9 ("net/ulp: prevent ULP without clone op from entering the LISTEN status") Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Link: https://lore.kernel.org/r/7bb199e7a93317fb6f8bf8b9b2dc71c18f337cde.1674042685.git.pabeni@redhat.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-01-19ASoC: Intel: sof_ssp_amp: always set dpcm_capture for amplifiersPierre-Louis Bossart
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20230119163459.2235843-5-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-19ASoC: Intel: sof_nau8825: always set dpcm_capture for amplifiersPierre-Louis Bossart
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20230119163459.2235843-4-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-19ASoC: Intel: sof_cs42l42: always set dpcm_capture for amplifiersPierre-Louis Bossart
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20230119163459.2235843-3-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-19ASoC: Intel: sof_rt5682: always set dpcm_capture for amplifiersPierre-Louis Bossart
The amplifier may provide hardware support for I/V feedback, or alternatively the firmware may generate an echo reference attached to the SSP and dailink used for the amplifier. To avoid any issues with invalid/NULL substreams in the latter case, always unconditionally set dpcm_capture. Link: https://github.com/thesofproject/linux/issues/4083 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20230119163459.2235843-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-01-19x86/sev: Add SEV-SNP guest feature negotiation supportNikunj A Dadhania
The hypervisor can enable various new features (SEV_FEATURES[1:63]) and start a SNP guest. Some of these features need guest side implementation. If any of these features are enabled without it, the behavior of the SNP guest will be undefined. It may fail booting in a non-obvious way making it difficult to debug. Instead of allowing the guest to continue and have it fail randomly later, detect this early and fail gracefully. The SEV_STATUS MSR indicates features which the hypervisor has enabled. While booting, SNP guests should ascertain that all the enabled features have guest side implementation. In case a feature is not implemented in the guest, the guest terminates booting with GHCB protocol Non-Automatic Exit(NAE) termination request event, see "SEV-ES Guest-Hypervisor Communication Block Standardization" document (currently at https://developer.amd.com/wp-content/resources/56421.pdf), section "Termination Request". Populate SW_EXITINFO2 with mask of unsupported features that the hypervisor can easily report to the user. More details in the AMD64 APM Vol 2, Section "SEV_STATUS MSR". [ bp: - Massage. - Move snp_check_features() call to C code. Note: the CC:stable@ aspect here is to be able to protect older, stable kernels when running on newer hypervisors. Or not "running" but fail reliably and in a well-defined manner instead of randomly. ] Fixes: cbd3d4f7c4e5 ("x86/sev: Check SEV-SNP features support") Signed-off-by: Nikunj A Dadhania <nikunj@amd.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Cc: <stable@kernel.org> Link: https://lore.kernel.org/r/20230118061943.534309-1-nikunj@amd.com
2023-01-19driver core: Fix test_async_probe_init saves device in wrong arrayChen Zhongjin
In test_async_probe_init, second set of asynchronous devices are saved in sync_dev[sync_id], which should be async_dev[async_id]. This makes these devices not unregistered when exit. > modprobe test_async_driver_probe && \ > modprobe -r test_async_driver_probe && \ > modprobe test_async_driver_probe ... > sysfs: cannot create duplicate filename '/devices/platform/test_async_driver.4' > kobject_add_internal failed for test_async_driver.4 with -EEXIST, don't try to register things with the same name in the same directory. Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity") Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com> Link: https://lore.kernel.org/r/20221125063541.241328-1-chenzhongjin@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-14 00:45:10 +0000