Author: Dominique Martinet <[email protected]> Date: Wed May 3 16:49:27 2023 +0900 9p: virtio: make sure 'offs' is initialized in zc_request [ Upstream commit 4a73edab69d3a6623f03817fe950a2d9585f80e4 ] Similarly to the previous patch: offs can be used in handle_rerrors without initializing on small payloads; in this case handle_rerrors will not use it because of the size check, but it doesn't hurt to make sure it is zero to please scan-build. This fixes the following warning: net/9p/trans_virtio.c:539:3: warning: 3rd function call argument is an uninitialized value [core.CallAndMessage] handle_rerror(req, in_hdr_len, offs, in_pages); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Dominique Martinet <[email protected]> Signed-off-by: Eric Van Hensbergen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Fri Aug 18 14:40:04 2023 -0500 ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table [ Upstream commit 9cc8cd086f05d9a01026c65c98da88561e9c619e ] The constraints table should be resetting the `list` object after running through all of `info_obj` iterations. This adjusts whitespace as well as less code will now be included with each loop. This fixes a functional problem is fixed where a badly formed package in the inner loop may have incorrect data. Fixes: 146f1ed852a8 ("ACPI: PM: s2idle: Add AMD support to handle _DSM") Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mario Limonciello <[email protected]> Date: Fri Aug 18 14:40:02 2023 -0500 ACPI: x86: s2idle: Post-increment variables when getting constraints [ Upstream commit 3c6b1212d20bbbffcad5709ab0f2d5ed9b5859a8 ] When code uses a pre-increment it makes the reader question "why". In the constraint fetching code there is no reason for the variables to be pre-incremented so adjust to post-increment. No intended functional changes. Reviewed-by: Kuppuswamy Sathyanarayanan <[email protected]> Suggested-by: Bjorn Helgaas <[email protected]> Signed-off-by: Mario Limonciello <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Stable-dep-of: 9cc8cd086f05 ("ACPI: x86: s2idle: Fix a logic error parsing AMD constraints table") Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Fri Sep 1 17:27:08 2023 -0700 af_unix: Fix data race around sk->sk_err. [ Upstream commit b192812905e4b134f7b7994b079eb647e9d2d37e ] As with sk->sk_shutdown shown in the previous patch, sk->sk_err can be read locklessly by unix_dgram_sendmsg(). Let's use READ_ONCE() for sk_err as well. Note that the writer side is marked by commit cc04410af7de ("af_unix: annotate lockless accesses to sk->sk_err"). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Fri Sep 1 17:27:06 2023 -0700 af_unix: Fix data-race around unix_tot_inflight. [ Upstream commit ade32bd8a738d7497ffe9743c46728db26740f78 ] unix_tot_inflight is changed under spin_lock(unix_gc_lock), but unix_release_sock() reads it locklessly. Let's use READ_ONCE() for unix_tot_inflight. Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix: annote lockless accesses to unix_tot_inflight & gc_in_progress") BUG: KCSAN: data-race in unix_inflight / unix_release_sock write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1: unix_inflight+0x130/0x180 net/unix/scm.c:64 unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1832 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x148/0x160 net/socket.c:747 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493 ___sys_sendmsg+0xc6/0x140 net/socket.c:2547 __sys_sendmsg+0x94/0x140 net/socket.c:2576 __do_sys_sendmsg net/socket.c:2585 [inline] __se_sys_sendmsg net/socket.c:2583 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0: unix_release_sock+0x608/0x910 net/unix/af_unix.c:671 unix_release+0x59/0x80 net/unix/af_unix.c:1058 __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1385 __fput+0x179/0x5e0 fs/file_table.c:321 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdc value changed: 0x00000000 -> 0x00000001 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Fixes: 9305cfa4443d ("[AF_UNIX]: Make unix_tot_inflight counter non-atomic") Reported-by: syzkaller <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Fri Sep 1 17:27:07 2023 -0700 af_unix: Fix data-races around sk->sk_shutdown. [ Upstream commit afe8764f76346ba838d4f162883e23d2fcfaa90e ] sk->sk_shutdown is changed under unix_state_lock(sk), but unix_dgram_sendmsg() calls two functions to read sk_shutdown locklessly. sock_alloc_send_pskb `- sock_wait_for_wmem Let's use READ_ONCE() there. Note that the writer side was marked by commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown."). BUG: KCSAN: data-race in sock_alloc_send_pskb / unix_release_sock write (marked) to 0xffff8880069af12c of 1 bytes by task 1 on cpu 1: unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631 unix_release+0x59/0x80 net/unix/af_unix.c:1053 __sock_release+0x7d/0x170 net/socket.c:654 sock_close+0x19/0x30 net/socket.c:1386 __fput+0x2a3/0x680 fs/file_table.c:384 ____fput+0x15/0x20 fs/file_table.c:412 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 read to 0xffff8880069af12c of 1 bytes by task 28650 on cpu 0: sock_alloc_send_pskb+0xd2/0x620 net/core/sock.c:2767 unix_dgram_sendmsg+0x2f8/0x14f0 net/unix/af_unix.c:1944 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 value changed: 0x00 -> 0x03 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 28650 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzkaller <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Fri Sep 1 17:27:05 2023 -0700 af_unix: Fix data-races around user->unix_inflight. [ Upstream commit 0bc36c0650b21df36fbec8136add83936eaf0607 ] user->unix_inflight is changed under spin_lock(unix_gc_lock), but too_many_unix_fds() reads it locklessly. Let's annotate the write/read accesses to user->unix_inflight. BUG: KCSAN: data-race in unix_attach_fds / unix_inflight write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 value changed: 0x000000000000000c -> 0x000000000000000d Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Fixes: 712f4aad406b ("unix: properly account for FDs passed over unix sockets") Reported-by: syzkaller <[email protected]> Signed-off-by: Kuniyuki Iwashima <[email protected]> Acked-by: Willy Tarreau <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Su Hui <[email protected]> Date: Wed Aug 23 10:52:13 2023 +0800 ALSA: ac97: Fix possible error value of *rac97 [ Upstream commit 67de40c9df94037769967ba28c7d951afb45b7fb ] Before committing 79597c8bf64c, *rac97 always be NULL if there is an error. When error happens, make sure *rac97 is NULL is safer. For examble, in snd_vortex_mixer(): err = snd_ac97_mixer(pbus, &ac97, &vortex->codec); vortex->isquad = ((vortex->codec == NULL) ? 0 : (vortex->codec->ext_id&0x80)); If error happened but vortex->codec isn't NULL, this may cause some problems. Move the judgement order to be clearer and better. Fixes: 79597c8bf64c ("ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixer") Suggested-by: Christophe JAILLET <[email protected]> Acked-by: Christophe JAILLET <[email protected]> Signed-off-by: Su Hui <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Tue Aug 29 15:43:44 2023 +0200 ALSA: pcm: Fix missing fixup call in compat hw_refine ioctl commit 358040e3807754944dbddf948a23c6d914297ed7 upstream. The update of rate_num/den and msbits were factored out to fixup_unreferenced_params() function to be called explicitly after the hw_refine or hw_params procedure. It's called from snd_pcm_hw_refine_user(), but it's forgotten in the PCM compat ioctl. This ended up with the incomplete rate_num/den and msbits parameters when 32bit compat ioctl is used. This patch adds the missing call in snd_pcm_ioctl_hw_params_compat(). Reported-by: [email protected] Fixes: f9a076bff053 ("ALSA: pcm: calculate non-mask/non-interval parameters always when possible") Reviewed-by: Takashi Sakamoto <[email protected]> Reviewed-by: Jaroslav Kysela <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Takashi Iwai <[email protected]> Date: Mon Jun 12 14:55:33 2023 +0200 ALSA: seq: oss: Fix racy open/close of MIDI devices [ Upstream commit 297224fc0922e7385573a30c29ffdabb67f27b7d ] Although snd_seq_oss_midi_open() and snd_seq_oss_midi_close() can be called concurrently from different code paths, we have no proper data protection against races. Introduce open_mutex to each seq_oss_midi object for avoiding the races. Reported-by: "Gong, Sishuai" <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Takashi Iwai <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Peng Fan <[email protected]> Date: Mon Aug 21 10:39:27 2023 +0800 amba: bus: fix refcount leak [ Upstream commit e312cbdc11305568554a9e18a2ea5c2492c183f3 ] commit 5de1540b7bc4 ("drivers/amba: create devices from device tree") increases the refcount of of_node, but not releases it in amba_device_release, so there is refcount leak. By using of_node_put to avoid refcount leak. Fixes: 5de1540b7bc4 ("drivers/amba: create devices from device tree") Signed-off-by: Peng Fan <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Kozlov <[email protected]> Date: Tue Aug 15 19:11:36 2023 +0400 ARC: atomics: Add compiler barrier to atomic operations... commit 42f51fb24fd39cc547c086ab3d8a314cc603a91c upstream. ... to avoid unwanted gcc optimizations SMP kernels fail to boot with commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations"). | | percpu: BUG: failure at mm/percpu.c:2981/pcpu_build_alloc_info()! | The write operation performed by the SCOND instruction in the atomic inline asm code is not properly passed to the compiler. The compiler cannot correctly optimize a nested loop that runs through the cpumask in the pcpu_build_alloc_info() function. Fix this by add a compiler barrier (memory clobber in inline asm). Apparently atomic ops used to have memory clobber implicitly via surrounding smp_mb(). However commit b64be6836993c431e ("ARC: atomics: implement relaxed variants") removed the smp_mb() for the relaxed variants, but failed to add the explicit compiler barrier. Link: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/135 Cc: <[email protected]> # v6.3+ Fixes: b64be6836993c43 ("ARC: atomics: implement relaxed variants") Signed-off-by: Pavel Kozlov <[email protected]> Signed-off-by: Vineet Gupta <[email protected]> [vgupta: tweaked the changelog and added Fixes tag] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Will Deacon <[email protected]> Date: Thu Sep 7 09:54:11 2023 +0100 arm64: csum: Fix OoB access in IP checksum code for negative lengths commit 8bd795fedb8450ecbef18eeadbd23ed8fc7630f5 upstream. Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length calls") added an early return for zero-length input, syzkaller has popped up with an example of a _negative_ length which causes an undefined shift and an out-of-bounds read: | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975 | | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 | Call trace: | dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 | show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 | __dump_stack lib/dump_stack.c:88 [inline] | dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 | print_address_description mm/kasan/report.c:351 [inline] | print_report+0x174/0x514 mm/kasan/report.c:462 | kasan_report+0xd4/0x130 mm/kasan/report.c:572 | kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 | __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31 | do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | csum_partial+0x30/0x58 lib/checksum.c:128 | gso_make_checksum include/linux/skbuff.h:4928 [inline] | __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332 | udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47 | ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119 | skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141 | __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401 | skb_gso_segment include/linux/netdevice.h:4859 [inline] | validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659 | validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709 | sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327 | __dev_xmit_skb net/core/dev.c:3805 [inline] | __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210 | dev_queue_xmit include/linux/netdevice.h:3085 [inline] | packet_xmit+0x6c/0x318 net/packet/af_packet.c:276 | packet_snd net/packet/af_packet.c:3081 [inline] | packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113 | sock_sendmsg_nosec net/socket.c:724 [inline] | sock_sendmsg net/socket.c:747 [inline] | __sys_sendto+0x3b4/0x538 net/socket.c:2144 Extend the early return to reject negative lengths as well, aligning our implementation with the generic code in lib/checksum.c Cc: Robin Murphy <[email protected]> Fixes: 5777eaed566a ("arm64: Implement optimised checksum routine") Reported-by: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bryan O'Donoghue <[email protected]> Date: Sat Aug 12 00:47:33 2023 +0100 arm64: dts: qcom: apq8016-sbc: Fix ov5640 regulator supply names [ Upstream commit 43a684580819e7f35b6cb38236be63c4cba26ef4 ] The ov5640 driver expects DOVDD, AVDD and DVDD as regulator supply names. The ov5640 has depended on these names since the driver was committed upstream in 2017. Similarly apq8016-sbc.dtsi has had completely different regulator names since its own initial commit in 2020. Perhaps the regulators were left on in previous 410c bootloaders. In any case today on 6.5 we won't switch on the ov5640 without correctly naming the regulators. Fixes: 39e0ce6cd1bf ("arm64: dts: qcom: apq8016-sbc: Add CCI/Sensor nodes") Signed-off-by: Bryan O'Donoghue <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu May 5 17:47:02 2022 +0200 arm64: dts: qcom: correct SPMI WLED register range encoding [ Upstream commit d66b1d2e4afc0c8a9eb267740825240b67f6b1d1 ] On PM660L, PMI8994 and PMI8998, the WLED has two address spaces and with size-cells=0, they should be encoded as two separate items. Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 9a4ac09db3c7 ("arm64: dts: qcom: pm660l: Add missing short interrupt") Signed-off-by: Sasha Levin <[email protected]>
Author: Marijn Suijten <[email protected]> Date: Thu Oct 7 23:33:59 2021 +0200 arm64: dts: qcom: Move WLED num-strings from pmi8994 to sony-xperia-tone [ Upstream commit 360f20c801f7ea2ddc9afcbc5ab74cebf8adea6b ] The number of WLED strings used by a certain platform depend on the panel connected to that board and may not be the same for every user of pmi8994. Signed-off-by: Marijn Suijten <[email protected]> Reviewed-By: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 8db944326903 ("arm64: dts: qcom: pmi8994: Add missing OVP interrupt") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 27 18:24:27 2023 +0200 arm64: dts: qcom: msm8996: Add missing interrupt to the USB2 controller [ Upstream commit 36541089c4733355ed844c67eebd0c3936953454 ] The interrupt line was previously not described. Take care of that. Fixes: 1e39255ed29d ("arm64: dts: msm8996: Add device node for qcom,dwc3") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 22:00:26 2023 +0200 arm64: dts: qcom: pm660l: Add missing short interrupt [ Upstream commit 9a4ac09db3c7413e334b4abd6b2f6de8930dd781 ] Add the missing short interrupt. This fixes the schema warning: wled@d800: interrupt-names: ['ovp'] is too short Fixes: 7b56a804e58b ("arm64: dts: qcom: pm660l: Add WLED support") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Mon Jun 26 22:00:28 2023 +0200 arm64: dts: qcom: pmi8994: Add missing OVP interrupt [ Upstream commit 8db94432690371b1736e9a2566a9b3d8a73d5a97 ] Add the missing OVP interrupt. This fixes the schema warning: wled@d800: interrupt-names: ['short'] is too short Fixes: 37aa540cbd30 ("arm64: dts: qcom: pmi8994: Add WLED node") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marijn Suijten <[email protected]> Date: Thu Oct 7 23:33:58 2021 +0200 arm64: dts: qcom: pmi8994: Remove hardcoded linear WLED enabled-strings [ Upstream commit 9b729b0932d0e6097d9f103e9dd149ef10881f43 ] The driver now sets an appropriate default for WLED4 (and WLED5) just like WLED3 making this linear array from 0-3 redundant. In addition the driver is now able to parse arrays of variable length solving the "all four strings *have to* be defined" comment. Besides the driver will now warn when both properties are specified to prevent ambiguity: the length of the array is enough to imply a set number of strings. Signed-off-by: Marijn Suijten <[email protected]> Reviewed-By: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 8db944326903 ("arm64: dts: qcom: pmi8994: Add missing OVP interrupt") Signed-off-by: Sasha Levin <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Thu Sep 9 14:36:28 2021 +0200 arm64: dts: qcom: pmi8998: Add node for WLED [ Upstream commit 17d32c10a2880ae7702d8e56128a542d9c6e9c75 ] The PMI8998 PMIC has a WLED backlight controller, which is used on most MSM8998 and SDM845 based devices: add a base configuration for it and keep it disabled. This contains only the PMIC specific configuration that does not change across boards; parameters like number of strings, OVP and current limits are product specific and shall be specified in the product DT in order to achieve functionality. Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 9a4ac09db3c7 ("arm64: dts: qcom: pm660l: Add missing short interrupt") Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Fri Jul 7 15:30:24 2023 +0300 arm64: dts: qcom: pmk8350: fix ADC-TM compatible string [ Upstream commit 435a73d7377ceb29c1a22d2711dd85c831b40c45 ] The commit b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350") for the ADC TM (thermal monitoring device) have used the compatible string from the vendor kernel ("qcom,adc-tm7"). Use the proper compatible string that is defined in the upstream kernel ("qcom,spmi-adc-tm5-gen2"). Fixes: b2de43136058 ("arm64: dts: qcom: pmk8350: Add peripherals for pmk8350") Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Jul 20 11:10:48 2023 +0530 arm64: dts: qcom: sdm845: Add missing RPMh power domain to GCC [ Upstream commit 4b6ea15c0a1122422b44bf6c47a3c22fc8d46777 ] GCC and it's GDSCs are under the RPMh CX power domain. So let's add the missing RPMh power domain to the GCC node. Fixes: 6d4cf750d03a ("arm64: dts: sdm845: Add minimal dts/dtsi files for sdm845 SoC and MTP") Reviewed-by: Konrad Dybcio <[email protected]> Co-developed-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Thu Jul 20 11:10:49 2023 +0530 arm64: dts: qcom: sdm845: Fix the min frequency of "ice_core_clk" [ Upstream commit bbbef6e24bc4493602df68b052f6f48d48e3184a ] Minimum frequency of the "ice_core_clk" should be 75MHz as specified in the downstream vendor devicetree. So fix it! https://git.codelinaro.org/clo/la/kernel/msm-4.9/-/blob/LA.UM.7.3.r1-09300-sdm845.0/arch/arm64/boot/dts/qcom/sdm845.dtsi Fixes: 433f9a57298f ("arm64: dts: sdm845: add Inline Crypto Engine registers and clock") Signed-off-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zeyan Li <[email protected]> Date: Thu Jul 27 10:53:21 2023 +0800 arm64: dts: qcom: sm8150: Fix the I2C7 interrupt [ Upstream commit f9568d22ce06192a7e14bda3a29dc216659554ff ] I2C6 and I2C7 use the same interrupts, which is incorrect. In the downstream kernel, I2C7 has interrupts of 608 instead of 607. Fixes: 81bee6953b58 ("arm64: dts: qcom: sm8150: add i2c nodes") Signed-off-by: Zeyan Li <[email protected]> Reviewed-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/SY7P282MB378712225CBCEA95FE71554DB201A@SY7P282MB3787.AUSP282.PROD.OUTLOOK.COM Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 20 13:05:35 2023 +0200 arm64: dts: qcom: sm8250-edo: Add GPIO line names for PMIC GPIOs [ Upstream commit 6b8a63350752c6a5e4b54f2de6174084652cd3cd ] Sony ever so graciously provides GPIO line names in their downstream kernel (though sometimes they are not 100% accurate and you can judge that by simply looking at them and with what drivers they are used). Add these to the PDX203&206 DTSIs to better document the hardware. Diff between 203 and 206: pm8009_gpios < "CAM_PWR_LD_EN", > "NC", pm8150_gpios < "NC", > "G_ASSIST_N", < "WLC_EN_N", /* GPIO_10 */ > "NC", /* GPIO_10 */ Which is due to 5 II having an additional Google Assistant hardware button and 1 II having a wireless charger & different camera wiring to accommodate the additional 3D iToF sensor. Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Stable-dep-of: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 20 13:05:34 2023 +0200 arm64: dts: qcom: sm8250-edo: Add gpio line names for TLMM [ Upstream commit 40b398beabdfe0e9088b13976e56b1dc706fe851 ] Sony ever so graciously provides GPIO line names in their downstream kernel (though sometimes they are not 100% accurate and you can judge that by simply looking at them and with what drivers they are used). Add these to the PDX203&206 DTSIs to better document the hardware. Diff between 203 and 206: < "CAM_PWR_A_CS", > "FRONTC_PWR_EN", < "CAM4_MCLK", < "TOF_RST_N", > "NC", > "NC", < "WLC_I2C_SDA", < "WLC_I2C_SCL", /* GPIO_120 */ > "NC", > "NC", < "WLC_INT_N", > "NC", Which makes sense, as 203 has a 3D iToF, slightly different camera power wiring and WLC (WireLess Charging). Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Stable-dep-of: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys") Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jun 20 13:05:37 2023 +0200 arm64: dts: qcom: sm8250-edo: Rectify gpio-keys [ Upstream commit a422c6a91a667b309ca1a6c08b30dbfcf7d4e866 ] Set up the corresponding GPIOs properly and add the leftover hardware buttons to mark this piece of the puzzle complete. Fixes: 46e14907c716 ("arm64: dts: qcom: sm8250-edo: Add hardware keys") Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Jul 11 08:30:11 2023 +0200 arm64: dts: qcom: sm8250-sony-xperia: correct GPIO keys wakeup again [ Upstream commit b8fbeea0253211d97c579eae787274633d3eaf0d ] gpio-keys,wakeup is a deprecated property: m8250-sony-xperia-edo-pdx206.dtb: gpio-keys: key-camera-focus: Unevaluated properties are not allowed ('gpio-key,wakeup' was unexpected) Fixes: a422c6a91a66 ("arm64: dts: qcom: sm8250-edo: Rectify gpio-keys") Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vincent Guittot <[email protected]> Date: Thu Jun 15 17:48:52 2023 +0200 arm64: dts: qcom: sm8250: correct dynamic power coefficients [ Upstream commit 775a5283c25d160b2a1359018c447bc518096547 ] sm8250 faces the same problem with its Energy Model as sdm845. The energy cost of LITTLE cores is reported to be higher than medium or big cores EM computes the energy with formula: energy = OPP's cost / maximum cpu capacity * utilization On v6.4-rc6 we have: max capacity of CPU0 = 284 capacity of CPU0's OPP(1612800 Hz) = 253 cost of CPU0's OPP(1612800 Hz) = 191704 max capacity of CPU4 = 871 capacity of CPU4's OPP(710400 Hz) = 255 cost of CPU4's OPP(710400 Hz) = 343217 Both OPPs have almost the same compute capacity but the estimated energy per unit of utilization will be estimated to: energy CPU0 = 191704 / 284 * 1 = 675 energy CPU4 = 343217 / 871 * 1 = 394 EM estimates that little CPU0 will consume 71% more than medium CPU4 for the same compute capacity. According to [1], little consumes 25% less than medium core for Coremark benchmark at those OPPs for the same duration. Set the dynamic-power-coefficient of CPU0-3 to 105 to fix the energy model for little CPUs. [1] https://github.com/kdrag0n/freqbench/tree/master/results/sm8250/k30s Fixes: 6aabed5526ee ("arm64: dts: qcom: sm8250: Add CPU capacities and energy model") Signed-off-by: Vincent Guittot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue Jul 4 14:23:17 2023 +0200 arm64: dts: qcom: sm8250: Mark PCIe hosts as DMA coherent [ Upstream commit 339d38a436f30d0f874815eafc7de2257346bf26 ] The PCIe hosts on SM8250 are cache-coherent. Mark them as such. Fixes: e53bdfc00977 ("arm64: dts: qcom: sm8250: Add PCIe support") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Wed Jul 5 15:36:23 2023 +0200 arm64: dts: qcom: sm8350: Add missing LMH interrupts to cpufreq [ Upstream commit 951151c2bb548e0f6b2c40ab4c48675f5342c914 ] Add the missing interrupts that communicate the hardware-managed throttling to Linux. Fixes: ccbb3abb23a5 ("arm64: dts: qcom: sm8350: Add cpufreq node") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Thu Jul 6 18:35:37 2023 +0200 arm64: dts: qcom: sm8350: Use proper CPU compatibles [ Upstream commit 4390730cc12af25f7c997f477795f5f4200149c0 ] The Kryo names (once again) turned out to be fake. The CPUs report: 0x412fd050 (CA55 r2p0) (0 - 3) 0x411fd410 (CA78 r1p1) (4 - 6) 0x411fd440 (CX1 r1p1) (7) Use the compatibles that reflect that. Fixes: b7e8f433a673 ("arm64: dts: qcom: Add basic devicetree support for SM8350 SoC") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joey Gouly <[email protected]> Date: Tue Mar 1 10:14:34 2022 +0000 arm64: lib: Import latest version of Arm Optimized Routines' strncmp commit 387d828adffcf1eb949f3141079c479793c59aac upstream. Import the latest version of the Arm Optimized Routines strncmp function based on the upstream code of string/aarch64/strncmp.S at commit 189dfefe37d5 from: https://github.com/ARM-software/optimized-routines This latest version includes MTE support. Note that for simplicity Arm have chosen to contribute this code to Linux under GPLv2 rather than the original MIT OR Apache-2.0 WITH LLVM-exception license. Arm is the sole copyright holder for this code. Signed-off-by: Joey Gouly <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Catalin Marinas <[email protected]> Cc: Will Deacon <[email protected]> Acked-by: Mark Rutland <[email protected]> Acked-by: Catalin Marinas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: 020b199bc70d ("arm64: Import latest version of Cortex Strings' strncmp") Reported-by: John Hsu <[email protected]> Link: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: D Scott Phillips <[email protected]> Date: Mon Jun 26 17:29:39 2023 -0700 arm64: sdei: abort running SDEI handlers during crash commit 5cd474e57368f0957c343bb21e309cf82826b1ef upstream. Interrupts are blocked in SDEI context, per the SDEI spec: "The client interrupts cannot preempt the event handler." If we crashed in the SDEI handler-running context (as with ACPI's AGDI) then we need to clean up the SDEI state before proceeding to the crash kernel so that the crash kernel can have working interrupts. Track the active SDEI handler per-cpu so that we can COMPLETE_AND_RESUME the handler, discarding the interrupted context. Fixes: f5df26961853 ("arm64: kernel: Add arch-specific SDEI entry code and CPU masking") Signed-off-by: D Scott Phillips <[email protected]> Cc: [email protected] Reviewed-by: James Morse <[email protected]> Tested-by: Mihai Carabas <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksey Nasibulin <[email protected]> Date: Wed Jul 12 03:40:17 2023 +0200 ARM: dts: BCM5301X: Extend RAM to full 256MB for Linksys EA6500 V2 [ Upstream commit 91994e59079dcb455783d3f9ea338eea6f671af3 ] Linksys ea6500-v2 have 256MB of ram. Currently we only use 128MB. Expand the definition to use all the available RAM. Fixes: 03e96644d7a8 ("ARM: dts: BCM5301X: Add basic DT for Linksys EA6500 V2") Signed-off-by: Aleksey Nasibulin <[email protected]> Signed-off-by: Christian Marangi <[email protected]> Cc: [email protected] Acked-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Fri Jul 7 13:40:03 2023 +0200 ARM: dts: BCM53573: Add cells sizes to PCIe node [ Upstream commit 3392ef368d9b04622fe758b1079b512664b6110a ] This fixes: arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: pcie@2000: '#address-cells' is a required property From schema: /lib/python3.10/site-packages/dtschema/schemas/pci/pci-bus.yaml arch/arm/boot/dts/broadcom/bcm47189-luxul-xap-1440.dtb: pcie@2000: '#size-cells' is a required property From schema: /lib/python3.10/site-packages/dtschema/schemas/pci/pci-bus.yaml Two properties that need to be added later are "device_type" and "ranges". Adding "device_type" on its own causes a new warning and the value of "ranges" needs to be determined yet. Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Thu Jul 13 13:11:45 2023 +0200 ARM: dts: BCM53573: Fix Ethernet info for Luxul devices [ Upstream commit 44ad8207806973f4e4f7d870fff36cc01f494250 ] Both Luxul's XAP devices (XAP-810 and XAP-1440) are access points that use a non-default design. They don't include switch but have a single Ethernet port and BCM54210E PHY connected to the Ethernet controller's MDIO bus. Support for those devices regressed due to two changes: 1. Describing MDIO bus with switch After commit 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch") Linux stopped probing for MDIO devices. 2. Dropping hardcoded BCM54210E delays In commit fea7fda7f50a ("net: phy: broadcom: Fix RGMII delays configuration for BCM54210E") support for other PHY modes was added but that requires a proper "phy-mode" value in DT. Both above changes are correct (they don't need to be reverted or anything) but they need this fix for DT data to be correct and for Linux to work properly. Fixes: 9fb90ae6cae7 ("ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch") Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rafał Miłecki <[email protected]> Date: Fri Jul 7 13:40:04 2023 +0200 ARM: dts: BCM53573: Use updated "spi-gpio" binding properties [ Upstream commit 2c0fd6b3d0778ceab40205315ccef74568490f17 ] Switch away from deprecated properties. This fixes: arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-sck: False schema does not allow [[3, 21, 0]] From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-miso: False schema does not allow [[3, 22, 0]] From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: gpio-mosi: False schema does not allow [[3, 23, 0]] From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: 'sck-gpios' is a required property From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml arch/arm/boot/dts/broadcom/bcm947189acdbmr.dtb: spi: Unevaluated properties are not allowed ('gpio-miso', 'gpio-mosi', 'gpio-sck' were unexpected) From schema: Documentation/devicetree/bindings/spi/spi-gpio.yaml Signed-off-by: Rafał Miłecki <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Sat Dec 17 02:08:53 2022 +0100 ARM: dts: imx7s: Drop dma-apb interrupt-names [ Upstream commit 9928f0a9e7c0cee3360ca1442b4001d34ad67556 ] Drop "interrupt-names" property, since it is broken. The drivers/dma/mxs-dma.c in Linux kernel does not use it, the property contains duplicate array entries in existing DTs, and even malformed entries (gmpi, should have been gpmi). Get rid of that optional property altogether. Signed-off-by: Marek Vasut <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Stable-dep-of: be18293e47cb ("ARM: dts: imx: Set default tuning step for imx7d usdhc") Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Wahren <[email protected]> Date: Fri Apr 14 11:19:46 2023 +0200 ARM: dts: imx: Adjust dma-apbh node name [ Upstream commit e9f5cd85f1f931bb7b64031492f7051187ccaac7 ] Currently the dtbs_check generates warnings like this: $nodename:0: 'dma-apbh@110000' does not match '^dma-controller(@.*)?$' So fix all affected dma-apbh node names. Signed-off-by: Stefan Wahren <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Stable-dep-of: be18293e47cb ("ARM: dts: imx: Set default tuning step for imx7d usdhc") Signed-off-by: Sasha Levin <[email protected]>
Author: Xiaolei Wang <[email protected]> Date: Mon Jul 24 23:45:10 2023 +0800 ARM: dts: imx: Set default tuning step for imx7d usdhc [ Upstream commit be18293e47cbca7c6acee9231fc851601d69563a ] If the tuning step is not set, the tuning step is set to 1. For some sd cards, the following Tuning timeout will occur. Tuning failed, falling back to fixed sampling clock mmc0: Tuning failed, falling back to fixed sampling clock So set the default tuning step. This refers to the NXP vendor's commit below: https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/ arch/arm/boot/dts/imx7s.dtsi#L1216-L1217 Fixes: 1e336aa0c025 ("mmc: sdhci-esdhc-imx: correct the tuning start tap and step setting") Signed-off-by: Xiaolei Wang <[email protected]> Reviewed-by: Fabio Estevam <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joy Zou <[email protected]> Date: Mon Sep 5 16:36:15 2022 +0800 ARM: dts: imx: update sdma node name format [ Upstream commit 6769089ecb5073b0896addffe72c89a4d80258c9 ] Node names should be generic, so change the sdma node name format 'sdma' into 'dma-controller'. Acked-by: Fabio Estevam <[email protected]> Signed-off-by: Joy Zou <[email protected]> Signed-off-by: Shawn Guo <[email protected]> Stable-dep-of: be18293e47cb ("ARM: dts: imx: Set default tuning step for imx7d usdhc") Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Tue Jan 11 21:17:16 2022 +0100 ARM: dts: s3c64xx: align pinctrl with dtschema [ Upstream commit 9e47ccc01284aba7fe5fbf6ee2a7abc29bf2a740 ] Align the pin controller related nodes with dtschema. No functional change expected. Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: cf0cb2af6a18 ("ARM: dts: samsung: s3c6410-mini6410: correct ethernet reg addresses (split)") Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Apr 21 11:57:21 2023 +0200 ARM: dts: s5pv210: add dummy 5V regulator for backlight on SMDKv210 [ Upstream commit b77904ba177a9c67b6dbc3637fdf1faa22df6e5c ] Backlight is supplied by DC5V regulator. The DTS has no PMIC node, so just add a regulator-fixed to solve it and fix dtbs_check warning: s5pv210-smdkv210.dtb: backlight: 'power-supply' is a required property Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Stable-dep-of: 982655cb0e7f ("ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split)") Signed-off-by: Sasha Levin <[email protected]>
Author: Paul Cercueil <[email protected]> Date: Fri Jul 14 17:37:20 2023 +0200 ARM: dts: samsung: exynos4210-i9100: Fix LCD screen's physical size [ Upstream commit b3f3fc32e5ff1e848555af8616318cc667457f90 ] The previous values were completely bogus, and resulted in the computed DPI ratio being much lower than reality, causing applications and UIs to misbehave. The new values were measured by myself with a ruler. Signed-off-by: Paul Cercueil <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Fixes: 8620cc2f99b7 ("ARM: dts: exynos: Add devicetree file for the Galaxy S2") Cc: <[email protected]> # v5.8+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Jul 13 17:29:25 2023 +0200 ARM: dts: samsung: s3c6410-mini6410: correct ethernet reg addresses (split) [ Upstream commit cf0cb2af6a18f28b84f9f1416bff50ca60d6e98a ] The davicom,dm9000 Ethernet Controller accepts two reg addresses. Fixes: a43736deb47d ("ARM: dts: Add dts file for S3C6410-based Mini6410 board") Reviewed-by: Alim Akhtar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Thu Jul 13 17:29:26 2023 +0200 ARM: dts: samsung: s5pv210-smdkv210: correct ethernet reg addresses (split) [ Upstream commit 982655cb0e7f18934d7532c32366e574ad61dbd7 ] The davicom,dm9000 Ethernet Controller accepts two reg addresses. Fixes: b672b27d232e ("ARM: dts: Add Device tree for s5pc110/s5pv210 boards") Reviewed-by: Alim Akhtar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Krzysztof Kozlowski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gustavo A. R. Silva <[email protected]> Date: Wed Jun 7 22:12:11 2023 -0600 ARM: OMAP2+: Fix -Warray-bounds warning in _pwrdm_state_switch() commit 847fb80cc01a54bc827b02547bb8743bdb59ddab upstream. If function pwrdm_read_prev_pwrst() returns -EINVAL, we will end up accessing array pwrdm->state_counter through negative index -22. This is wrong and the compiler is legitimately warning us about this potential problem. Fix this by sanity checking the value stored in variable _prev_ before accessing array pwrdm->state_counter. Address the following -Warray-bounds warning: arch/arm/mach-omap2/powerdomain.c:178:45: warning: array subscript -22 is below array bounds of 'unsigned int[4]' [-Warray-bounds] Link: https://github.com/KSPP/linux/issues/307 Fixes: ba20bb126940 ("OMAP: PM counter infrastructure.") Cc: [email protected] Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/lkml/20230607050639.LzbPn%[email protected]/ Signed-off-by: Gustavo A. R. Silva <[email protected]> Message-ID: <ZIFVGwImU3kpaGeH@work> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Aug 10 12:54:18 2023 -0700 ARM: ptrace: Restore syscall restart tracing [ Upstream commit cf007647475b5090819c5fe8da771073145c7334 ] Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall"), the seccomp selftests "syscall_restart" has been broken. This was caused by the restart syscall not being stored to "abi_syscall" during restart setup before branching to the "local_restart" label. Tracers would see the wrong syscall, and scno would get overwritten while returning from the TIF_WORK path. Add the missing store. Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Lecopzer Chen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Fixes: 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall") Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Aug 10 12:54:19 2023 -0700 ARM: ptrace: Restore syscall skipping for tracers [ Upstream commit 4697b5848bd933f68ebd04836362c8de0cacaf71 ] Since commit 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall"), the seccomp selftests "syscall_errno" and "syscall_faked" have been broken. Both seccomp and PTRACE depend on using the special value of "-1" for skipping syscalls. This value wasn't working because it was getting masked by __NR_SYSCALL_MASK in both PTRACE_SET_SYSCALL and get_syscall_nr(). Explicitly test for -1 in PTRACE_SET_SYSCALL and get_syscall_nr(), leaving it exposed when present, allowing tracers to skip syscalls again. Cc: Russell King <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Lecopzer Chen <[email protected]> Cc: Oleg Nesterov <[email protected]> Cc: [email protected] Fixes: 4e57a4ddf6b0 ("ARM: 9107/1: syscall: always store thread_info->abi_syscall") Reviewed-by: Arnd Bergmann <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guiting Shen <[email protected]> Date: Sat Jul 15 11:06:20 2023 +0800 ASoC: atmel: Fix the 8K sample parameter in I2SC master [ Upstream commit f85739c0b2b0d98a32f5ca4fcc5501d2b76df4f6 ] The 8K sample parameter of 12.288Mhz main system bus clock doesn't work because the I2SC_MR.IMCKDIV must not be 0 according to the sama5d2 series datasheet(I2SC Mode Register of Register Summary). So use the 6.144Mhz instead of 12.288Mhz to support 8K sample. Signed-off-by: Guiting Shen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Edgar <[email protected]> Date: Wed Jul 19 13:47:22 2023 +0800 ASoc: codecs: ES8316: Fix DMIC config [ Upstream commit d20d35d1ad62c6cca36368c1e8f29335a068659e ] According to the datasheet, the DMIC config should be changed to { 0, 2 ,3 } Signed-off-by: Edgar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Maluka <[email protected]> Date: Mon Jul 17 21:37:37 2023 +0200 ASoC: da7219: Check for failure reading AAD IRQ events [ Upstream commit f0691dc16206f21b13c464434366e2cd632b8ed7 ] When handling an AAD interrupt, if IRQ events read failed (for example, due to i2c "Transfer while suspended" failure, i.e. when attempting to read it while DA7219 is suspended, which may happen due to a spurious AAD interrupt), the events array contains garbage uninitialized values. So instead of trying to interprete those values and doing any actions based on them (potentially resulting in misbehavior, e.g. reporting bogus events), refuse to handle the interrupt. Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmytro Maluka <[email protected]> Date: Mon Jul 17 21:37:36 2023 +0200 ASoC: da7219: Flush pending AAD IRQ when suspending [ Upstream commit 91e292917dad64ab8d1d5ca2ab3069ad9dac6f72 ] da7219_aad_suspend() disables jack detection, which should prevent generating new interrupts by DA7219 while suspended. However, there is a theoretical possibility that there is a pending interrupt generated just before suspending DA7219 and not handled yet, so the IRQ handler may still run after DA7219 is suspended. To prevent that, wait until the pending IRQ handling is done. This patch arose as an attempt to fix the following I2C failure occurring sometimes during system suspend or resume: [ 355.876211] i2c_designware i2c_designware.3: Transfer while suspended [ 355.876245] WARNING: CPU: 2 PID: 3576 at drivers/i2c/busses/i2c-designware-master.c:570 i2c_dw_xfer+0x411/0x440 ... [ 355.876462] Call Trace: [ 355.876468] <TASK> [ 355.876475] ? update_load_avg+0x1b3/0x615 [ 355.876484] __i2c_transfer+0x101/0x1d8 [ 355.876494] i2c_transfer+0x74/0x10d [ 355.876504] regmap_i2c_read+0x6a/0x9c [ 355.876513] _regmap_raw_read+0x179/0x223 [ 355.876521] regmap_raw_read+0x1e1/0x28e [ 355.876527] regmap_bulk_read+0x17d/0x1ba [ 355.876532] ? __wake_up+0xed/0x1bb [ 355.876542] da7219_aad_irq_thread+0x54/0x2c9 [snd_soc_da7219 5fb8ebb2179cf2fea29af090f3145d68ed8e2184] [ 355.876556] irq_thread+0x13c/0x231 [ 355.876563] ? irq_forced_thread_fn+0x5f/0x5f [ 355.876570] ? irq_thread_fn+0x4d/0x4d [ 355.876576] kthread+0x13a/0x152 [ 355.876581] ? synchronize_irq+0xc3/0xc3 [ 355.876587] ? kthread_blkcg+0x31/0x31 [ 355.876592] ret_from_fork+0x1f/0x30 [ 355.876601] </TASK> which indicates that the AAD IRQ handler is unexpectedly running when DA7219 is suspended, and as a result, is trying to read data from DA7219 over I2C and is hitting the I2C driver "Transfer while suspended" failure. However, with this patch the above failure is still reproducible. So this patch does not fix any real observed issue so far, but at least is useful for confirming that the above issue is not caused by a pending IRQ but rather looks like a DA7219 hardware issue with an IRQ unexpectedly generated after jack detection is already disabled. Signed-off-by: Dmytro Maluka <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:06:43 2023 +0800 ASoC: rt5682-sdw: fix for JD event handling in ClockStop Mode0 [ Upstream commit 02fb23d72720df2b6be3f29fc5787ca018eb92c3 ] When the system suspends, peripheral Imp-defined interrupt is disabled. When system level resume is invoked, the peripheral Imp-defined interrupts should be enabled to handle JD events. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:07:11 2023 +0800 ASoC: rt711-sdca: fix for JD event handling in ClockStop Mode0 [ Upstream commit 23adeb7056acd4fd866969f4afb91441776cc4f5 ] When the system suspends, peripheral SDCA interrupts are disabled. When system level resume is invoked, the peripheral SDCA interrupts should be enabled to handle JD events. Enable SDCA interrupts in resume sequence when ClockStop Mode0 is applied. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shuming Fan <[email protected]> Date: Fri Jul 21 17:06:54 2023 +0800 ASoC: rt711: fix for JD event handling in ClockStop Mode0 [ Upstream commit b69de265bd0e877015a00fbba453ef72af162e0f ] When the system suspends, peripheral Imp-defined interrupt is disabled. When system level resume is invoked, the peripheral Imp-defined interrupts should be enabled to handle JD events. Signed-off-by: Shuming Fan <[email protected]> Reported-by: Vijendar Mukunda <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Fri Jun 30 21:48:36 2023 -0700 ASoC: stac9766: fix build errors with REGMAP_AC97 [ Upstream commit c70064b96f509daa78f57992aeabcf274fb2fed4 ] Select REGMAP_AC97 to fix these build errors: ERROR: modpost: "regmap_ac97_default_volatile" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! ERROR: modpost: "__regmap_init_ac97" [sound/soc/codecs/snd-soc-stac9766.ko] undefined! Fixes: 6bbf787bb70c ("ASoC: stac9766: Convert to regmap") Signed-off-by: Randy Dunlap <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Cc: Mark Brown <[email protected]> Cc: Liam Girdwood <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Minjie Du <[email protected]> Date: Tue Jul 25 11:06:25 2023 +0800 ata: pata_arasan_cf: Use dev_err_probe() instead dev_err() in data_xfer() [ Upstream commit 4139f992c49356391fb086c0c8ce51f66c26d623 ] It is possible for dma_request_chan() to return EPROBE_DEFER, which means acdev->host->dev is not ready yet. At this point dev_err() will have no output. Use dev_err_probe() instead. Signed-off-by: Minjie Du <[email protected]> Acked-by: Viresh Kumar <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Schmitz <[email protected]> Date: Sun Aug 27 16:13:47 2023 +1200 ata: pata_falcon: fix IO base selection for Q40 commit 8a1f00b753ecfdb117dc1a07e68c46d80e7923ea upstream. With commit 44b1fbc0f5f3 ("m68k/q40: Replace q40ide driver with pata_falcon and falconide"), the Q40 IDE driver was replaced by pata_falcon.c. Both IO and memory resources were defined for the Q40 IDE platform device, but definition of the IDE register addresses was modeled after the Falcon case, both in use of the memory resources and in including register shift and byte vs. word offset in the address. This was correct for the Falcon case, which does not apply any address translation to the register addresses. In the Q40 case, all of device base address, byte access offset and register shift is included in the platform specific ISA access translation (in asm/mm_io.h). As a consequence, such address translation gets applied twice, and register addresses are mangled. Use the device base address from the platform IO resource for Q40 (the IO address translation will then add the correct ISA window base address and byte access offset), with register shift 1. Use MMIO base address and register shift 2 as before for Falcon. Encode PIO_OFFSET into IO port addresses for all registers for Q40 except the data transfer register. Encode the MMIO offset there (pata_falcon_data_xfer() directly uses raw IO with no address translation). Reported-by: William R Sowerbutts <[email protected]> Closes: https://lore.kernel.org/r/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com Link: https://lore.kernel.org/r/CAMuHMdUU62jjunJh9cqSqHT87B0H0A4udOOPs=WN7WZKpcagVA@mail.gmail.com Fixes: 44b1fbc0f5f3 ("m68k/q40: Replace q40ide driver with pata_falcon and falconide") Cc: [email protected] Cc: Finn Thain <[email protected]> Cc: Geert Uytterhoeven <[email protected]> Tested-by: William R Sowerbutts <[email protected]> Signed-off-by: Michael Schmitz <[email protected]> Reviewed-by: Sergey Shtylyov <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Damien Le Moal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Thu Aug 24 07:41:59 2023 +0900 ata: pata_ftide010: Add missing MODULE_DESCRIPTION commit 7274eef5729037300f29d14edeb334a47a098f65 upstream. Add the missing MODULE_DESCRIPTION() to avoid warnings such as: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/ata/pata_ftide010.o when compiling with W=1. Fixes: be4e456ed3a5 ("ata: Add driver for Faraday Technology FTIDE010") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Damien Le Moal <[email protected]> Date: Thu Aug 24 07:43:18 2023 +0900 ata: sata_gemini: Add missing MODULE_DESCRIPTION commit 8566572bf3b4d6e416a4bf2110dbb4817d11ba59 upstream. Add the missing MODULE_DESCRIPTION() to avoid warnings such as: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/ata/sata_gemini.o when compiling with W=1. Fixes: be4e456ed3a5 ("ata: Add driver for Faraday Technology FTIDE010") Cc: [email protected] Signed-off-by: Damien Le Moal <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Gaosheng Cui <[email protected]> Date: Tue Aug 8 20:14:35 2023 +0800 audit: fix possible soft lockup in __audit_inode_child() [ Upstream commit b59bc6e37237e37eadf50cd5de369e913f524463 ] Tracefs or debugfs maybe cause hundreds to thousands of PATH records, too many PATH records maybe cause soft lockup. For example: 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4. mkdir /sys/kernel/debug/tracing/instances/test There may be a soft lockup as follows: watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498] Kernel panic - not syncing: softlockup: hung tasks Call trace: dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340 __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140 __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180 Therefore, we add cond_resched() to __audit_inode_child() to fix it. Fixes: 5195d8e217a7 ("audit: dynamically allocate audit_names when not enough space is in the names array") Signed-off-by: Gaosheng Cui <[email protected]> Signed-off-by: Paul Moore <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:36 2023 +0200 backlight/bd6107: Compare against struct fb_info.device commit 992bdddaabfba19bdc77c1c7a4977b2aa41ec891 upstream. Struct bd6107_platform_data refers to a platform device within the Linux device hierarchy. The test in bd6107_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Fixes: 67b43e590415 ("backlight: Add ROHM BD6107 backlight driver") Signed-off-by: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Lee Jones <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Jingoo Han <[email protected]> Cc: [email protected] Cc: <[email protected]> # v3.12+ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:38 2023 +0200 backlight/gpio_backlight: Compare against struct fb_info.device commit 7b91d017f77c1bda56f27c2f4bbb70de7c6eca08 upstream. Struct gpio_backlight_platform_data refers to a platform device within the Linux device hierarchy. The test in gpio_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 8b770e3c9824 ("backlight: Add GPIO-based backlight driver") Cc: Laurent Pinchart <[email protected]> Cc: Rich Felker <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Lee Jones <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Jingoo Han <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v3.12+ Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:40 2023 +0200 backlight/lv5207lp: Compare against struct fb_info.device commit 1ca8819320fd84e7d95b04e7668efc5f9fe9fa5c upstream. Struct lv5207lp_platform_data refers to a platform device within the Linux device hierarchy. The test in lv5207lp_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device. Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional. v2: * move renames into separate patch (Javier, Sam, Michael) Fixes: 82e5c40d88f9 ("backlight: Add Sanyo LV5207LP backlight driver") Signed-off-by: Thomas Zimmermann <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Cc: Lee Jones <[email protected]> Cc: Daniel Thompson <[email protected]> Cc: Jingoo Han <[email protected]> Cc: [email protected] Cc: [email protected] Cc: <[email protected]> # v3.12+ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Reviewed-by: Daniel Thompson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ying Liu <[email protected]> Date: Fri Jul 21 09:29:03 2023 +0000 backlight: gpio_backlight: Drop output GPIO direction check for initial power state [ Upstream commit fe1328b5b2a087221e31da77e617f4c2b70f3b7f ] So, let's drop output GPIO direction check and only check GPIO value to set the initial power state. Fixes: 706dc68102bc ("backlight: gpio: Explicitly set the direction of the GPIO") Signed-off-by: Liu Ying <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Bartosz Golaszewski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Lingfeng <[email protected]> Date: Thu Aug 31 15:59:00 2023 +0800 block: don't add or resize partition on the disk with GENHD_FL_NO_PART [ Upstream commit 1a721de8489fa559ff4471f73c58bb74ac5580d3 ] Commit a33df75c6328 ("block: use an xarray for disk->part_tbl") remove disk_expand_part_tbl() in add_partition(), which means all kinds of devices will support extended dynamic `dev_t`. However, some devices with GENHD_FL_NO_PART are not expected to add or resize partition. Fix this by adding check of GENHD_FL_NO_PART before add or resize partition. Fixes: a33df75c6328 ("block: use an xarray for disk->part_tbl") Signed-off-by: Li Lingfeng <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Nov 22 14:06:13 2021 +0100 block: move GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE to disk->event_flags [ Upstream commit 1545e0b419ba1d9b9bee4061d4826340afe6b0aa ] GENHD_FL_BLOCK_EVENTS_ON_EXCL_WRITE is all about the event reporting mechanism, so move it to the event_flags field. Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Nov 22 14:06:12 2021 +0100 block: move GENHD_FL_NATIVE_CAPACITY to disk->state [ Upstream commit 86416916466514e4ae0b7296d20133b6427c4c1f ] The flag to indicate an unlocked native capacity is dynamic state, not a driver capability flag, so move it to disk->state. Signed-off-by: Christoph Hellwig <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") Signed-off-by: Sasha Levin <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Nov 22 14:06:17 2021 +0100 block: rename GENHD_FL_NO_PART_SCAN to GENHD_FL_NO_PART [ Upstream commit 46e7eac647b34ed4106a8262f8bedbb90801fadd ] The GENHD_FL_NO_PART_SCAN controls more than just partitions canning, so rename it to GENHD_FL_NO_PART. Signed-off-by: Christoph Hellwig <[email protected]> Acked-by: Ulf Hansson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") Signed-off-by: Sasha Levin <[email protected]>
Author: Jinjie Ruan <[email protected]> Date: Wed Aug 23 11:46:37 2023 +0800 Bluetooth: btusb: Do not call kfree_skb() under spin_lock_irqsave() [ Upstream commit 2a05334d7f91ff189692089c05fc48cc1d8204de ] It is not allowed to call kfree_skb() from hardware interrupt context or with hardware interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under spin_lock_irqsave(). Compile tested only. Fixes: baac6276c0a9 ("Bluetooth: btusb: handle mSBC audio over USB Endpoints") Signed-off-by: Jinjie Ruan <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Min Li <[email protected]> Date: Mon Aug 7 19:07:41 2023 +0800 Bluetooth: Fix potential use-after-free when clear keys [ Upstream commit 3673952cf0c6cf81b06c66a0b788abeeb02ff3ae ] Similar to commit c5d2b6fa26b5 ("Bluetooth: Fix use-after-free in hci_remove_ltk/hci_remove_irk"). We can not access k after kfree_rcu() call. Fixes: d7d41682efc2 ("Bluetooth: Fix Suspicious RCU usage warnings") Signed-off-by: Min Li <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuanjun Gong <[email protected]> Date: Wed Jul 26 21:30:00 2023 +0800 Bluetooth: nokia: fix value check in nokia_bluetooth_serdev_probe() [ Upstream commit e8b5aed31355072faac8092ead4938ddec3111fd ] in nokia_bluetooth_serdev_probe(), check the return value of clk_prepare_enable() and return the error code if clk_prepare_enable() returns an unexpected value. Fixes: 7bb318680e86 ("Bluetooth: add nokia driver") Signed-off-by: Yuanjun Gong <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Christensen <[email protected]> Date: Thu Jun 8 16:01:43 2023 -0400 bnx2x: fix page fault following EEH recovery [ Upstream commit 7ebe4eda4265642859507d1b3ca330d8c196cfe5 ] In the last step of the EEH recovery process, the EEH driver calls into bnx2x_io_resume() to re-initialize the NIC hardware via the function bnx2x_nic_load(). If an error occurs during bnx2x_nic_load(), OS and hardware resources are released and an error code is returned to the caller. When called from bnx2x_io_resume(), the return code is ignored and the network interface is brought up unconditionally. Later attempts to send a packet via this interface result in a page fault due to a null pointer reference. This patch checks the return code of bnx2x_nic_load(), prints an error message if necessary, and does not enable the interface. Signed-off-by: David Christensen <[email protected]> Reviewed-by: Sridhar Samudrala <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yafang Shao <[email protected]> Date: Sun Jul 9 02:56:25 2023 +0000 bpf: Clear the probe_addr for uprobe [ Upstream commit 5125e757e62f6c1d5478db4c2b61a744060ddf3f ] To avoid returning uninitialized or random values when querying the file descriptor (fd) and accessing probe_addr, it is necessary to clear the variable prior to its use. Fixes: 41bdc4b40ed6 ("bpf: introduce bpf subcommand BPF_TASK_FD_QUERY") Signed-off-by: Yafang Shao <[email protected]> Acked-by: Yonghong Song <[email protected]> Acked-by: Jiri Olsa <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lorenz Bauer <[email protected]> Date: Thu Jul 20 17:30:06 2023 +0200 bpf: reject unhashed sockets in bpf_sk_assign [ Upstream commit 67312adc96b5a585970d03b62412847afe2c6b01 ] The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets. A new UDP socket is created in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only added in udp_lib_get_port() which happens when a socket is bound. When bpf_sk_assign was added it wasn't possible to access unhashed UDP sockets from BPF, so this wasn't a problem. This changed in commit 0c48eefae712 ("sock_map: Lift socket state restriction for datagram sockets"), but the helper wasn't adjusted accordingly. The following sequence of events will therefore lead to a refcount leak: 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap. 2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount. 3. bind() or connect() the socket, setting SOCK_RCU_FREE. 4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE. 5. tcp_v4_rcv() skips sock_put(). Fix the problem by rejecting unhashed sockets in bpf_sk_assign(). This matches the behaviour of __inet_lookup_skb which is ultimately the goal of bpf_sk_assign(). Fixes: cf7fbe660f2d ("bpf: Add socket assign support") Cc: Joe Stringer <[email protected]> Signed-off-by: Lorenz Bauer <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alexander Lobakin <[email protected]> Date: Fri Jul 7 10:54:25 2023 +0100 bpftool: Use a local bpf_perf_event_value to fix accessing its fields [ Upstream commit 658ac06801315b739774a15796ff06913ef5cad5 ] Fix the following error when building bpftool: CLANG profiler.bpf.o CLANG pid_iter.bpf.o skeleton/profiler.bpf.c:18:21: error: invalid application of 'sizeof' to an incomplete type 'struct bpf_perf_event_value' __uint(value_size, sizeof(struct bpf_perf_event_value)); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:13:39: note: expanded from macro '__uint' tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helper_defs.h:7:8: note: forward declaration of 'struct bpf_perf_event_value' struct bpf_perf_event_value; ^ struct bpf_perf_event_value is being used in the kernel only when CONFIG_BPF_EVENTS is enabled, so it misses a BTF entry then. Define struct bpf_perf_event_value___local with the `preserve_access_index` attribute inside the pid_iter BPF prog to allow compiling on any configs. It is a full mirror of a UAPI structure, so is compatible both with and w/o CO-RE. bpf_perf_event_read_value() requires a pointer of the original type, so a cast is needed. Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command") Suggested-by: Andrii Nakryiko <[email protected]> Signed-off-by: Alexander Lobakin <[email protected]> Signed-off-by: Quentin Monnet <[email protected]> Signed-off-by: Andrii Nakryiko <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Filipe Manana <[email protected]> Date: Wed Jul 26 16:56:57 2023 +0100 btrfs: don't start transaction when joining with TRANS_JOIN_NOSTART commit 4490e803e1fe9fab8db5025e44e23b55df54078b upstream. When joining a transaction with TRANS_JOIN_NOSTART, if we don't find a running transaction we end up creating one. This goes against the purpose of TRANS_JOIN_NOSTART which is to join a running transaction if its state is at or below the state TRANS_STATE_COMMIT_START, otherwise return an -ENOENT error and don't start a new transaction. So fix this to not create a new transaction if there's no running transaction at or below that state. CC: [email protected] # 4.14+ Fixes: a6d155d2e363 ("Btrfs: fix deadlock between fiemap and transaction commits") Signed-off-by: Filipe Manana <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Boris Burkov <[email protected]> Date: Fri Jul 21 09:02:06 2023 -0700 btrfs: free qgroup rsv on io failure commit e28b02118b94e42be3355458a2406c6861e2dd32 upstream. If we do a write whose bio suffers an error, we will never reclaim the qgroup reserved space for it. We allocate the space in the write_iter codepath, then release the reservation as we allocate the ordered extent, but we only create a delayed ref if the ordered extent finishes. If it has an error, we simply leak the rsv. This is apparent in running any error injecting (dmerror) fstests like btrfs/146 or btrfs/160. Such tests fail due to dmesg on umount complaining about the leaked qgroup data space. When we clean up other aspects of space on failed ordered_extents, also free the qgroup rsv. Reviewed-by: Josef Bacik <[email protected]> CC: [email protected] # 5.10+ Signed-off-by: Boris Burkov <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anand Jain <[email protected]> Date: Mon Jul 31 19:16:34 2023 +0800 btrfs: use the correct superblock to compare fsid in btrfs_validate_super commit d167aa76dc0683828588c25767da07fb549e4f48 upstream. The function btrfs_validate_super() should verify the fsid in the provided superblock argument. Because, all its callers expect it to do that. Such as in the following stack: write_all_supers() sb = fs_info->super_for_commit; btrfs_validate_write_super(.., sb) btrfs_validate_super(.., sb, ..) scrub_one_super() btrfs_validate_super(.., sb, ..) And check_dev_super() btrfs_validate_super(.., sb, ..) However, it currently verifies the fs_info::super_copy::fsid instead, which is not correct. Fix this using the correct fsid in the superblock argument. CC: [email protected] # 5.4+ Reviewed-by: Johannes Thumshirn <[email protected]> Tested-by: Guilherme G. Piccoli <[email protected]> Signed-off-by: Anand Jain <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qiang Yu <[email protected]> Date: Thu May 18 14:22:39 2023 +0800 bus: mhi: host: Skip MHI reset if device is in RDDM commit cabce92dd805945a090dc6fc73b001bb35ed083a upstream. In RDDM EE, device can not process MHI reset issued by host. In case of MHI power off, host is issuing MHI reset and polls for it to get cleared until it times out. Since this timeout can not be avoided in case of RDDM, skip the MHI reset in this scenarios. Cc: <[email protected]> Fixes: a6e2e3522f29 ("bus: mhi: core: Add support for PM state transitions") Signed-off-by: Qiang Yu <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tony Lindgren <[email protected]> Date: Fri Aug 4 13:38:01 2023 +0300 bus: ti-sysc: Fix build warning for 64-bit build [ Upstream commit e1e1e9bb9d943ec690670a609a5f660ca10eaf85 ] Fix "warning: cast from pointer to integer of different size" on 64-bit builds. Note that this is a cosmetic fix at this point as the driver is not yet used for 64-bit systems. Fixes: feaa8baee82a ("bus: ti-sysc: Implement SoC revision handling") Reviewed-by: Dhruva Gole <[email protected]> Reviewed-by: Nishanth Menon <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Tony Lindgren <[email protected]> Date: Tue Aug 15 08:49:05 2023 +0300 bus: ti-sysc: Fix cast to enum warning [ Upstream commit de44bf2f7683347f75690ef6cf61a1d5ba8f0891 ] Fix warning for "cast to smaller integer type 'enum sysc_soc' from 'const void *'". Cc: Nishanth Menon <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: e1e1e9bb9d94 ("bus: ti-sysc: Fix build warning for 64-bit build") Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marc Kleine-Budde <[email protected]> Date: Tue Jul 4 11:23:37 2023 +0200 can: gs_usb: gs_usb_receive_bulk_callback(): count RX overflow errors also in case of OOM [ Upstream commit 6c8bc15f02b85bc8f47074110d8fd8caf7a1e42d ] In case of an RX overflow error from the CAN controller and an OOM where no skb can be allocated, the error counters are not incremented. Fix this by first incrementing the error counters and then allocate the skb. Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lu Jialin <[email protected]> Date: Thu Aug 10 11:25:28 2023 +0000 cgroup:namespace: Remove unused cgroup_namespaces_init() [ Upstream commit 82b90b6c5b38e457c7081d50dff11ecbafc1e61a ] cgroup_namspace_init() just return 0. Therefore, there is no need to call it during start_kernel. Just remove it. Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces") Signed-off-by: Lu Jialin <[email protected]> Signed-off-by: Tejun Heo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baoquan He <[email protected]> Date: Fri Jul 7 21:58:51 2023 +0800 clk: fixed-mmio: make COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM [ Upstream commit e7dd44f4f3166db45248414f5df8f615392de47a ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let COMMON_CLK_FIXED_MMIO depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset: ------ ld: drivers/clk/clk-fixed-mmio.o: in function `fixed_mmio_clk_setup': clk-fixed-mmio.c:(.text+0x5e): undefined reference to `of_iomap' ld: clk-fixed-mmio.c:(.text+0xba): undefined reference to `iounmap' ------ Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Baoquan He <[email protected]> Cc: Michael Turquette <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marco Felsch <[email protected]> Date: Mon Jul 31 16:21:49 2023 +0200 clk: imx8mp: fix sai4 clock [ Upstream commit c30f600f1f41dcf5ef0fb02e9a201f9b2e8f31bd ] The reference manual don't mention a SAI4 hardware block. This would be clock slice 78 which is skipped (TRM, page 237). Remove any reference to this clock to align the driver with the reality. Fixes: 9c140d992676 ("clk: imx: Add support for i.MX8MP clock driver") Acked-by: Stephen Boyd <[email protected]> Signed-off-by: Marco Felsch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ahmad Fatoum <[email protected]> Date: Mon Aug 7 10:22:00 2023 +0200 clk: imx: composite-8m: fix clock pauses when set_rate would be a no-op [ Upstream commit 4dd432d985ef258e3bc436e568fba4b987b59171 ] Reconfiguring the clock divider to the exact same value is observed on an i.MX8MN to often cause a longer than usual clock pause, probably because the divider restarts counting whenever the register is rewritten. This issue doesn't show up normally, because the clock framework will take care to not call set_rate when the clock rate is the same. However, when we reconfigure an upstream clock, the common code will call set_rate with the newly calculated rate on all children, e.g.: - sai5 is running normally and divides Audio PLL out by 16. - Audio PLL rate is increased by 32Hz (glitch-free kdiv change) - rates for children are recalculated and rates are set recursively - imx8m_clk_composite_divider_set_rate(sai5) is called with 32/16 = 2Hz more - imx8m_clk_composite_divider_set_rate computes same divider as before - divider register is written, so it restarts counting from zero and MCLK is briefly paused, so instead of e.g. 40ns, MCLK is low for 120ns. Some external clock consumers can be upset by such unexpected clock pauses, so let's make sure we only rewrite the divider value when the value to be written is actually different. Fixes: d3ff9728134e ("clk: imx: Add imx composite clock") Signed-off-by: Ahmad Fatoum <[email protected]> Reviewed-by: Peng Fan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ahmad Fatoum <[email protected]> Date: Mon Aug 7 10:47:44 2023 +0200 clk: imx: pll14xx: dynamically configure PLL for 393216000/361267200Hz commit 72d00e560d10665e6139c9431956a87ded6e9880 upstream. Since commit b09c68dc57c9 ("clk: imx: pll14xx: Support dynamic rates"), the driver has the ability to dynamically compute PLL parameters to approximate the requested rates. This is not always used, because the logic is as follows: - Check if the target rate is hardcoded in the frequency table - Check if varying only kdiv is possible, so switch over is glitch free - Compute rate dynamically by iterating over pdiv range If we skip the frequency table for the 1443x PLL, we find that the computed values differ to the hardcoded ones. This can be valid if the hardcoded values guarantee for example an earlier lock-in or if the divisors are chosen, so that other important rates are more likely to be reached glitch-free. For rates (393216000 and 361267200, this doesn't seem to be the case: They are only approximated by existing parameters (393215995 and 361267196 Hz, respectively) and they aren't reachable glitch-free from other hardcoded frequencies. Dropping them from the table allows us to lock-in to these frequencies exactly. This is immediately noticeable because they are the assigned-clock-rates for IMX8MN_AUDIO_PLL1 and IMX8MN_AUDIO_PLL2, respectively and a look into clk_summary so far showed that they were a few Hz short of the target: imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary audio_pll2_out 0 0 0 361267196 0 0 50000 N audio_pll1_out 1 1 0 393215995 0 0 50000 Y and afterwards: imx8mn-board:~# grep audio_pll[12]_out /sys/kernel/debug/clk/clk_summary audio_pll2_out 0 0 0 361267200 0 0 50000 N audio_pll1_out 1 1 0 393216000 0 0 50000 Y This change is equivalent to adding following hardcoded values: /* rate mdiv pdiv sdiv kdiv */ PLL_1443X_RATE(393216000, 655, 5, 3, 23593), PLL_1443X_RATE(361267200, 497, 33, 0, -16882), Fixes: 053a4ffe2988 ("clk: imx: imx8mm: fix audio pll setting") Cc: [email protected] # v5.18+ Signed-off-by: Ahmad Fatoum <[email protected]> Signed-off-by: Marco Felsch <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Abel Vesa <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 18 15:28:55 2023 +0200 clk: qcom: camcc-sc7180: fix async resume during probe commit c948ff727e25297f3a703eb5349dd66aabf004e4 upstream. To make sure that the controller is runtime resumed and its power domain is enabled before accessing its registers during probe, the synchronous runtime PM interface must be used. Fixes: 8d4025943e13 ("clk: qcom: camcc-sc7180: Use runtime PM ops instead of clk ones") Cc: [email protected] # 5.11 Cc: Stephen Boyd <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Baryshkov <[email protected]> Date: Sat May 13 00:17:23 2023 +0300 clk: qcom: gcc-mdm9615: use proper parent for pll0_vote clock commit 1583694bb4eaf186f17131dbc1b83d6057d2749b upstream. The pll0_vote clock definitely should have pll0 as a parent (instead of pll8). Fixes: 7792a8d6713c ("clk: mdm9615: Add support for MDM9615 Clock Controllers") Cc: [email protected] Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: David Wronek <[email protected]> Date: Sun Jul 23 21:05:02 2023 +0200 clk: qcom: gcc-sc7180: Fix up gcc_sdcc2_apps_clk_src [ Upstream commit fd0b5ba87ad5709f0fd3d2bc4b7870494a75f96a ] Set .flags = CLK_OPS_PARENT_ENABLE to fix "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error. Fixes: 17269568f726 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180") Signed-off-by: David Wronek <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Fri Aug 4 16:09:30 2023 +0200 clk: qcom: gcc-sm6350: Fix gcc_sdcc2_apps_clk_src [ Upstream commit df04d166d1f346dbf740bbea64a3bed3e7f14c8d ] GPLL7 is not on by default, which causes a "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error when booting. Set .flags = CLK_OPS_PARENT_ENABLE to fix the error. Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Patrick Whewell <[email protected]> Date: Wed Aug 2 14:04:00 2023 -0700 clk: qcom: gcc-sm8250: Fix gcc_sdcc2_apps_clk_src [ Upstream commit 783cb693828ce487cf0bc6ad16cbcf2caae6f8d9 ] GPLL9 is not on by default, which causes a "gcc_sdcc2_apps_clk_src: rcg didn't update its configuration" error when booting. Set .flags = CLK_OPS_PARENT_ENABLE to fix the error. Fixes: 3e5770921a88 ("clk: qcom: gcc: Add global clock controller driver for SM8250") Reviewed-by: Konrad Dybcio <[email protected]> Reviewed-by: Bryan O'Donoghue <[email protected]> Signed-off-by: Patrick Whewell <[email protected]> Reviewed-by: Vinod Koul <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 18 15:29:01 2023 +0200 clk: qcom: mss-sc7180: fix missing resume during probe commit e2349da0fa7ca822cda72f427345b95795358fe7 upstream. Drivers that enable runtime PM must make sure that the controller is runtime resumed before accessing its registers to prevent the power domain from being disabled. Fixes: 8def929c4097 ("clk: qcom: Add modem clock controller driver for SC7180") Cc: [email protected] # 5.7 Cc: Taniya Das <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 18 15:29:00 2023 +0200 clk: qcom: q6sstop-qcs404: fix missing resume during probe commit 97112c83f4671a4a722f99a53be4e91fac4091bc upstream. Drivers that enable runtime PM must make sure that the controller is runtime resumed before accessing its registers to prevent the power domain from being disabled. Fixes: 6cdef2738db0 ("clk: qcom: Add Q6SSTOP clock controller for QCS404") Cc: [email protected] # 5.5 Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Fri Jul 28 09:57:38 2023 +0200 clk: qcom: reset: Use the correct type of sleep/delay based on length [ Upstream commit 181b66ee7cdd824797fc99b53bec29cf5630a04f ] Use the fsleep() helper that (based on the length of the delay, see: [1]) chooses the correct sleep/delay functions. [1] https://www.kernel.org/doc/Documentation/timers/timers-howto.txt Fixes: 2cb8a39b6781 ("clk: qcom: reset: Allow specifying custom reset delay") Signed-off-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Johan Hovold <[email protected]> Date: Tue Jul 18 15:29:02 2023 +0200 clk: qcom: turingcc-qcs404: fix missing resume during probe commit a9f71a033587c9074059132d34c74eabbe95ef26 upstream. Drivers that enable runtime PM must make sure that the controller is runtime resumed before accessing its registers to prevent the power domain from being disabled. Fixes: 892df0191b29 ("clk: qcom: Add QCS404 TuringCC") Cc: [email protected] # 5.2 Cc: Bjorn Andersson <[email protected]> Signed-off-by: Johan Hovold <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Jianhua <[email protected]> Date: Sat Jul 22 15:31:07 2023 +0000 clk: sunxi-ng: Modify mismatched function name [ Upstream commit 075d9ca5b4e17f84fd1c744a405e69ec743be7f0 ] No functional modification involved. drivers/clk/sunxi-ng/ccu_mmc_timing.c:54: warning: expecting prototype for sunxi_ccu_set_mmc_timing_mode(). Prototype was for sunxi_ccu_get_mmc_timing_mode() instead Fixes: f6f64ed868d3 ("clk: sunxi-ng: Add interface to query or configure MMC timing modes.") Signed-off-by: Zhang Jianhua <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jernej Skrabec <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruidong Tian <[email protected]> Date: Fri Aug 4 16:15:14 2023 +0800 coresight: tmc: Explicit type conversions to prevent integer overflow [ Upstream commit fd380097cdb305582b7a1f9476391330299d2c59 ] Perf cs_etm session executed unexpectedly when AUX buffer > 1G. perf record -C 0 -m ,2G -e cs_etm// -- <workload> [ perf record: Captured and wrote 2.615 MB perf.data ] Perf only collect about 2M perf data rather than 2G. This is becasuse the operation, "nr_pages << PAGE_SHIFT", in coresight tmc driver, will overflow when nr_pages >= 0x80000(correspond to 1G AUX buffer). The overflow cause buffer allocation to fail, and TMC driver will alloc minimal buffer size(1M). You can just get about 2M perf data(1M AUX buffer + perf data header) at least. Explicit convert nr_pages to 64 bit to avoid overflow. Fixes: 22f429f19c41 ("coresight: etm-perf: Add support for ETR backend") Fixes: 99443ea19e8b ("coresight: Add generic TMC sg table framework") Fixes: 2e499bbc1a92 ("coresight: tmc: implementing TMC-ETF AUX space API") Signed-off-by: Ruidong Tian <[email protected]> Reviewed-by: James Clark <[email protected]> Signed-off-by: Suzuki K Poulose <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Gustavo A. R. Silva <[email protected]> Date: Mon Jul 31 21:15:48 2023 -0600 cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug commit e520d0b6be950ce3738cf4b9bd3b392be818f1dc upstream. Allocate extra space for terminating element at: drivers/cpufreq/brcmstb-avs-cpufreq.c: 449 table[i].frequency = CPUFREQ_TABLE_END; and add code comment to make this clear. This fixes the following -Warray-bounds warning seen after building ARM with multi_v7_defconfig (GCC 13): In function 'brcm_avs_get_freq_table', inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15: drivers/cpufreq/brcmstb-avs-cpufreq.c:449:28: warning: array subscript 5 is outside array bounds of 'void[60]' [-Warray-bounds=] 449 | table[i].frequency = CPUFREQ_TABLE_END; In file included from include/linux/node.h:18, from include/linux/cpu.h:17, from include/linux/cpufreq.h:12, from drivers/cpufreq/brcmstb-avs-cpufreq.c:44: In function 'devm_kmalloc_array', inlined from 'devm_kcalloc' at include/linux/device.h:328:9, inlined from 'brcm_avs_get_freq_table' at drivers/cpufreq/brcmstb-avs-cpufreq.c:437:10, inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15: include/linux/device.h:323:16: note: at offset 60 into object of size 60 allocated by 'devm_kmalloc' 323 | return devm_kmalloc(dev, bytes, flags); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -Warray-bounds. Link: https://github.com/KSPP/linux/issues/324 Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs") Cc: [email protected] Signed-off-by: Gustavo A. R. Silva <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liao Chang <[email protected]> Date: Tue Aug 29 07:03:18 2023 +0000 cpufreq: Fix the race condition while updating the transition_task of policy [ Upstream commit 61bfbf7951ba561dcbdd5357702d3cbc2d447812 ] The field 'transition_task' of policy structure is used to track the task which is performing the frequency transition. Using this field to print a warning once detect a case where the same task is calling _begin() again before completing the preivous frequency transition via the _end(). However, there is a potential race condition in _end() and _begin() APIs while updating the field 'transition_task' of policy, the scenario is depicted below: Task A Task B /* 1st freq transition */ Invoke _begin() { ... ... } /* 2nd freq transition */ Invoke _begin() { ... //waiting for A to ... //clear ... //transition_ongoing ... //in _end() for ... //the 1st transition | Change the frequency | | Invoke _end() { | ... | ... | transition_ongoing = false; V transition_ongoing = true; transition_task = current; transition_task = NULL; ... //A overwrites the task ... //performing the transition ... //result in error warning. } To fix this race condition, the transition_lock of policy structure is now acquired before updating policy structure in _end() API. Which ensure that only one task can update the 'transition_task' field at a time. Link: https://lore.kernel.org/all/[email protected]/ Fixes: ca654dc3a93d ("cpufreq: Catch double invocations of cpufreq_freq_transition_begin/end") Signed-off-by: Liao Chang <[email protected]> Acked-by: Viresh Kumar <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liao Chang <[email protected]> Date: Sat Aug 26 09:51:13 2023 +0000 cpufreq: powernow-k8: Use related_cpus instead of cpus in driver.exit() [ Upstream commit 03997da042dac73c69e60d91942c727c76828b65 ] Since the 'cpus' field of policy structure will become empty in the cpufreq core API, it is better to use 'related_cpus' in the exit() callback of driver. Fixes: c3274763bfc3 ("cpufreq: powernow-k8: Initialize per-cpu data-structures properly") Signed-off-by: Liao Chang <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Thu Aug 3 17:59:28 2023 +0800 crypto: api - Use work queue in crypto_destroy_instance [ Upstream commit 9ae4577bc077a7e32c3c7d442c95bc76865c0f17 ] The function crypto_drop_spawn expects to be called in process context. However, when an instance is unregistered while it still has active users, the last user may cause the instance to be freed in atomic context. Fix this by delaying the freeing to a work queue. Fixes: 6bfd48096ff8 ("[CRYPTO] api: Added spawns") Reported-by: Florent Revest <[email protected]> Reported-by: [email protected] Reported-by: [email protected] Signed-off-by: Herbert Xu <[email protected]> Tested-by: Florent Revest <[email protected]> Acked-by: Florent Revest <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gaurav Jain <[email protected]> Date: Tue Aug 8 12:55:25 2023 +0200 crypto: caam - fix unchecked return value error [ Upstream commit e30685204711a6be40dec2622606950ccd37dafe ] error: Unchecked return value (CHECKED_RETURN) check_return: Calling sg_miter_next without checking return value fix: added check if(!sg_miter_next) Fixes: 8a2a0dd35f2e ("crypto: caam - strip input zeros from RSA input buffer") Signed-off-by: Gaurav Jain <[email protected]> Signed-off-by: Meenakshi Aggarwal <[email protected]> Reviewed-by: Gaurav Jain <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Herbert Xu <[email protected]> Date: Tue Nov 22 13:53:38 2022 +0800 crypto: rsa-pkcs1pad - Use helper to set reqsize commit 5b11d1a360ea23c80c6d4ec3f5986a788d0a0995 upstream. The value of reqsize must only be changed through the helper. Signed-off-by: Herbert Xu <[email protected]> Cc: Giovanni Cabiddu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Thomas Bourgoin <[email protected]> Date: Thu Jul 13 17:15:15 2023 +0200 crypto: stm32 - fix loop iterating through scatterlist for DMA commit d9c83f71eeceed2cb54bb78be84f2d4055fd9a1f upstream. We were reading the length of the scatterlist sg after copying value of tsg inside. So we are using the size of the previous scatterlist and for the first one we are using an unitialised value. Fix this by copying tsg in sg[0] before reading the size. Fixes : 8a1012d3f2ab ("crypto: stm32 - Support for STM32 HASH module") Cc: [email protected] Signed-off-by: Thomas Bourgoin <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Mon Jul 31 18:54:54 2023 +0200 crypto: stm32 - Properly handle pm_runtime_get failing [ Upstream commit aec48805163338f8413118796c1dd035661b9140 ] If pm_runtime_get() (disguised as pm_runtime_resume_and_get()) fails, this means the clk wasn't prepared and enabled. Returning early in this case however is wrong as then the following resource frees are skipped and this is never catched up. So do all the cleanups but clk_disable_unprepare(). Also don't emit a warning, as stm32_hash_runtime_resume() already emitted one. Note that the return value of stm32_hash_remove() is mostly ignored by the device core. The only effect of returning zero instead of an error value is to suppress another warning in platform_remove(). So return 0 even if pm_runtime_resume_and_get() failed. Fixes: 8b4d566de6a5 ("crypto: stm32/hash - Add power management support") Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jann Horn <[email protected]> Date: Fri Aug 25 15:32:41 2023 +0200 dccp: Fix out of bounds access in DCCP error handler commit 977ad86c2a1bcaf58f01ab98df5cc145083c489c upstream. There was a previous attempt to fix an out-of-bounds access in the DCCP error handlers, but that fix assumed that the error handlers only want to access the first 8 bytes of the DCCP header. Actually, they also look at the DCCP sequence number, which is stored beyond 8 bytes, so an explicit pskb_may_pull() is required. Fixes: 6706a97fec96 ("dccp: fix out of bound access in dccp_v4_err()") Fixes: 1aa9d1a0e7ee ("ipv6: dccp: fix out of bound access in dccp_v6_err()") Cc: [email protected] Signed-off-by: Jann Horn <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexander Aring <[email protected]> Date: Thu Aug 24 16:51:42 2023 -0400 dlm: fix plock lookup when using multiple lockspaces commit 7c53e847ff5e97f033fdd31f71949807633d506b upstream. All posix lock ops, for all lockspaces (gfs2 file systems) are sent to userspace (dlm_controld) through a single misc device. The dlm_controld daemon reads the ops from the misc device and sends them to other cluster nodes using separate, per-lockspace cluster api communication channels. The ops for a single lockspace are ordered at this level, so that the results are received in the same sequence that the requests were sent. When the results are sent back to the kernel via the misc device, they are again funneled through the single misc device for all lockspaces. When the dlm code in the kernel processes the results from the misc device, these results will be returned in the same sequence that the requests were sent, on a per-lockspace basis. A recent change in this request/reply matching code missed the "per-lockspace" check (fsid comparison) when matching request and reply, so replies could be incorrectly matched to requests from other lockspaces. Cc: [email protected] Reported-by: Barry Marson <[email protected]> Fixes: 57e2c2f2d94c ("fs: dlm: fix mismatch of plock results from userspace") Signed-off-by: Alexander Aring <[email protected]> Signed-off-by: David Teigland <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Rob Clark <[email protected]> Date: Mon Jul 24 07:49:41 2023 -0700 dma-buf/sync_file: Fix docs syntax [ Upstream commit 05d56d8079d510a2994039470f65bea85f0075ee ] Fixes the warning: include/uapi/linux/sync_file.h:77: warning: Function parameter or member 'num_fences' not described in 'sync_file_info' Fixes: 2d75c88fefb2 ("staging/android: refactor SYNC IOCTLs") Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Randy Dunlap <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hien Huynh <[email protected]> Date: Thu Jul 6 12:21:50 2023 +0100 dmaengine: sh: rz-dmac: Fix destination and source data size setting commit c6ec8c83a29fb3aec3efa6fabbf5344498f57c7f upstream. Before setting DDS and SDS values, we need to clear its value first otherwise, we get incorrect results when we change/update the DMA bus width several times due to the 'OR' expression. Fixes: 5000d37042a6 ("dmaengine: sh: Add DMAC driver for RZ/G2L SoC") Cc: [email protected] Signed-off-by: Hien Huynh <[email protected]> Signed-off-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: ruanjinjie <[email protected]> Date: Mon Jul 24 14:41:08 2023 +0000 dmaengine: ste_dma40: Add missing IRQ check in d40_probe [ Upstream commit c05ce6907b3d6e148b70f0bb5eafd61dcef1ddc1 ] Check for the return value of platform_get_irq(): if no interrupt is specified, it wouldn't make sense to call request_irq(). Fixes: 8d318a50b3d7 ("DMAENGINE: Support for ST-Ericssons DMA40 block v3") Signed-off-by: Ruan Jinjie <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 18 10:03:49 2023 +0300 driver core: test_async: fix an error code [ Upstream commit 22d2381bbd70a5853c2ee77522f4965139672db9 ] The test_platform_device_register_node() function should return error pointers instead of NULL. That is what the callers are expecting. Fixes: 57ea974fb871 ("driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Minjie Du <[email protected]> Date: Wed Jul 12 18:22:46 2023 +0800 drivers: clk: keystone: Fix parameter judgment in _of_pll_clk_init() [ Upstream commit a995c50db887ef97f3160775aef7d772635a6f6e ] The function clk_register_pll() may return NULL or an ERR_PTR. Don't treat an ERR_PTR as valid. Signed-off-by: Minjie Du <[email protected]> Link: https://lore.kernel.org/r/[email protected] Fixes: b9e0d40c0d83 ("clk: keystone: add Keystone PLL clock driver") [[email protected]: Reword commit text] Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dongliang Mu <[email protected]> Date: Mon Feb 27 18:24:08 2023 +0800 drivers: usb: smsusb: fix error handling code in smsusb_init_device [ Upstream commit b9c7141f384097fa4fa67d2f72e5731d628aef7c ] The previous commit 4b208f8b561f ("[media] siano: register media controller earlier")moves siano_media_device_register before smscore_register_device, and adds corresponding error handling code if smscore_register_device fails. However, it misses the following error handling code of smsusb_init_device. Fix this by moving error handling code at the end of smsusb_init_device and adding a goto statement in the following error handling parts. Fixes: 4b208f8b561f ("[media] siano: register media controller earlier") Signed-off-by: Dongliang Mu <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Leo Chen <[email protected]> Date: Wed Jul 12 16:50:15 2023 -0400 drm/amd/display: Exit idle optimizations before attempt to access PHY [ Upstream commit de612738e9771bd66aeb20044486c457c512f684 ] [Why & How] DMUB may hang when powering down pixel clocks due to no dprefclk. It is fixed by exiting idle optimization before the attempt to access PHY. Reviewed-by: Nicholas Kazlauskas <[email protected]> Acked-by: Alex Hung <[email protected]> Signed-off-by: Leo Chen <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wesley Chalmers <[email protected]> Date: Wed Jun 21 19:13:26 2023 -0400 drm/amd/display: Fix a bug when searching for insert_above_mpcc commit 3d028d5d60d516c536de1ddd3ebf3d55f3f8983b upstream. [WHY] Currently, when insert_plane is called with insert_above_mpcc parameter that is equal to tree->opp_list, the function returns NULL. [HOW] Instead, the function should insert the plane at the top of the tree. Cc: Mario Limonciello <[email protected]> Cc: Alex Deucher <[email protected]> Cc: [email protected] Reviewed-by: Jun Lei <[email protected]> Acked-by: Tom Chung <[email protected]> Signed-off-by: Wesley Chalmers <[email protected]> Tested-by: Daniel Wheeler <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hamza Mahfooz <[email protected]> Date: Tue Sep 5 13:27:22 2023 -0400 drm/amd/display: prevent potential division by zero errors commit 07e388aab042774f284a2ad75a70a194517cdad4 upstream. There are two places in apply_below_the_range() where it's possible for a divide by zero error to occur. So, to fix this make sure the divisor is non-zero before attempting the computation in both cases. Cc: [email protected] Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637 Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math") Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization") Reviewed-by: Aurabindo Pillai <[email protected]> Signed-off-by: Hamza Mahfooz <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yang Wang <[email protected]> Date: Tue Aug 1 16:53:23 2023 +0800 drm/amd/pm: fix variable dereferenced issue in amdgpu_device_attr_create() [ Upstream commit 25e6373a5b8efc623443f2699d2b929bf3067d76 ] - fix variable ('attr') dereferenced issue. - using condition check instead of BUG_ON(). Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code") Cc: Dan Carpenter <[email protected]> Signed-off-by: Yang Wang <[email protected]> Reviewed-by: Kenneth Feng <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnd Bergmann <[email protected]> Date: Fri Jul 7 13:11:51 2023 +0200 drm/amdgpu: avoid integer overflow warning in amdgpu_device_resize_fb_bar() [ Upstream commit 822130b5e8834ab30ad410cf19a582e5014b9a85 ] On 32-bit architectures comparing a resource against a value larger than U32_MAX can cause a warning: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:1344:18: error: result of comparison of constant 4294967296 with expression of type 'resource_size_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] res->start > 0x100000000ull) ~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ As gcc does not warn about this in dead code, add an IS_ENABLED() check at the start of the function. This will always return success but not actually resize the BAR on 32-bit architectures without high memory, which is exactly what we want here, as the driver can fall back to bank switching the VRAM access. Fixes: 31b8adab3247 ("drm/amdgpu: require a root bus window above 4GB for BAR resize") Reviewed-by: Christian König <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lijo Lazar <[email protected]> Date: Tue Jul 25 19:11:54 2023 +0530 drm/amdgpu: Match against exact bootloader status [ Upstream commit d3de41ee5febe5c2d9989fe9810bce2bb54a3a8e ] On PSP v13.x ASICs, boot loader will set only the MSB to 1 and clear the least significant bits for any command submission. Hence match against the exact register value, otherwise a register value of all 0xFFs also could falsely indicate that boot loader is ready. Also, from PSP v13.0.6 and newer, bits[7:0] will be used to indicate command error status. Signed-off-by: Lijo Lazar <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Srinivasan Shanmugam <[email protected]> Date: Sun Jul 23 12:29:14 2023 +0530 drm/amdgpu: Update min() to min_t() in 'amdgpu_info_ioctl' [ Upstream commit a0cc8e1512ad72c9f97cdcb76d42715730adaf62 ] Fixes the following: WARNING: min() should probably be min_t(size_t, size, sizeof(ip)) + ret = copy_to_user(out, &ip, min((size_t)size, sizeof(ip))); And other style fixes: WARNING: Prefer 'unsigned int' to bare use of 'unsigned' WARNING: Missing a blank line after declarations Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:57 2023 +0300 drm/amdgpu: Use RMW accessors for changing LNKCTL [ Upstream commit ce7d88110b9ed5f33fe79ea6d4ed049fb0e57bce ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <[email protected]> Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts") Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Mon Jul 17 15:25:40 2023 +0200 drm/armada: Fix off-by-one error in armada_overlay_get_property() [ Upstream commit 5f0d984053f74983a287100a9519b2fabb785fb5 ] As ffs() returns one more than the index of the first bit set (zero means no bits set), the color key mode value is shifted one position too much. Fix this by using FIELD_GET() instead. Fixes: c96103b6c49ff9a8 ("drm/armada: move colorkey properties into overlay plane state") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a4d779d954a7515ddbbf31cb0f0d8184c0e7c879.1689600265.git.geert+renesas@glider.be Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Wed Jun 21 14:53:35 2023 +0200 drm/ast: Fix DRAM init on AST2200 commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream. Fix the test for the AST2200 in the DRAM initialization. The value in ast->chip has to be compared against an enum constant instead of a numerical value. This bug got introduced when the driver was first imported into the kernel. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") Cc: Dave Airlie <[email protected]> Cc: [email protected] Cc: <[email protected]> # v3.5+ Reviewed-by: Sui Jingfeng <[email protected]> Reviewed-by: Jocelyn Falempe <[email protected]> Tested-by: Jocelyn Falempe <[email protected]> # AST2600 Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Marek Vasut <[email protected]> Date: Thu Jun 15 17:28:17 2023 +0200 drm/bridge: tc358764: Fix debug print parameter order [ Upstream commit 7f947be02aab5b154427cb5b0fffe858fc387b02 ] The debug print parameters were swapped in the output and they were printed as decimal values, both the hardware address and the value. Update the debug print to print the parameters in correct order, and use hexadecimal print for both address and value. Fixes: f38b7cca6d0e ("drm/bridge: tc358764: Add DSI to LVDS bridge driver") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Lucas Stach <[email protected]> Date: Fri Apr 14 16:38:10 2023 +0200 drm/etnaviv: fix dumping of active MMU context [ Upstream commit 20faf2005ec85fa1a6acc9a74ff27de667f90576 ] gpu->mmu_context is the MMU context of the last job in the HW queue, which isn't necessarily the same as the context from the bad job. Dump the MMU context from the scheduler determined bad submit to make it work as intended. Fixes: 17e4660ae3d7 ("drm/etnaviv: implement per-process address spaces on MMUv2") Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Jul 28 18:35:16 2023 -0700 drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt() [ Upstream commit a90c367e5af63880008e21dd199dac839e0e9e0f ] Drop intel_vgpu_reset_gtt() as it no longer has any callers. In addition to eliminating dead code, this eliminates the last possible scenario where __kvmgt_protect_table_find() can be reached without holding vgpu_lock. Requiring vgpu_lock to be held when calling __kvmgt_protect_table_find() will allow a protecting the gfn hash with vgpu_lock without too much fuss. No functional change intended. Fixes: ba25d977571e ("drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.") Reviewed-by: Yan Zhao <[email protected]> Tested-by: Yongwei Ma <[email protected]> Reviewed-by: Zhi Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sui Jingfeng <[email protected]> Date: Thu Jul 6 21:40:00 2023 +0800 drm/mediatek: Fix potential memory leak if vmap() fail [ Upstream commit 379091e0f6d179d1a084c65de90fa44583b14a70 ] Also return -ENOMEM if such a failure happens, the implement should take responsibility for the error handling. Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap function") Reviewed-by: Matthias Brugger <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Reviewed-by: CK Hu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason-JH.Lin <[email protected]> Date: Fri Jul 14 17:49:05 2023 +0800 drm/mediatek: Remove freeing not dynamic allocated memory [ Upstream commit 27b9e2ea3f2757da26bb8280e46f7fdbb1acb219 ] Fixing the coverity issue of: mtk_drm_cmdq_pkt_destroy frees address of mtk_crtc->cmdq_handle So remove the free function. Fixes: 7627122fd1c0 ("drm/mediatek: Add cmdq_handle in mtk_crtc") Signed-off-by: Jason-JH.Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: CK Hu <[email protected]> Reviewed-by: Alexandre Mergnat <[email protected]> Link: https://patchwork.kernel.org/project/dri-devel/patch/[email protected]/ Signed-off-by: Chun-Kuang Hu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fabio Estevam <[email protected]> Date: Tue Jun 20 20:23:19 2023 -0300 drm/msm/a2xx: Call adreno_gpu_init() earlier [ Upstream commit db07ce5da8b26bfeaf437a676ae49bd3bb1eace6 ] The adreno_is_a20x() and adreno_is_a225() functions rely on the GPU revision, but such information is retrieved inside adreno_gpu_init(), which is called afterwards. Fix this problem by caling adreno_gpu_init() earlier, so that the GPU information revision is available when adreno_is_a20x() and adreno_is_a225() run. Tested on a imx53-qsb board. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Fabio Estevam <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/543456/ Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Vetter <[email protected]> Date: Thu Aug 3 22:45:21 2023 +0200 drm/msm/mdp5: Don't leak some plane state [ Upstream commit fd0ad3b2365c1c58aa5a761c18efc4817193beb6 ] Apparently no one noticed that mdp5 plane states leak like a sieve ever since we introduced plane_state->commit refcount a few years ago in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Fix it by using the right helpers. Fixes: 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.") Cc: Maarten Lankhorst <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Rob Clark <[email protected]> Cc: Abhinav Kumar <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: [email protected] Cc: [email protected] Reported-and-tested-by: [email protected] Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]> Reviewed-by: Rob Clark <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/551236/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ryan McCann <[email protected]> Date: Fri Jul 7 18:24:40 2023 -0700 drm/msm: Update dev core dump to not print backwards [ Upstream commit 903705111d863ed8ccf73465da77d232fc422ec1 ] Device core dump add block method adds hardware blocks to dumping queue with stack behavior which causes the hardware blocks to be printed in reverse order. Change the addition to dumping queue data structure from "list_add" to "list_add_tail" for FIFO queue behavior. Fixes: 98659487b845 ("drm/msm: add support to take dpu snapshot") Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Ryan McCann <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/546200/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Sun Jul 9 15:49:14 2023 +0200 drm/panel: simple: Add missing connector type and pixel format for AUO T215HVN01 [ Upstream commit 7a675a8fa598edb29a664a91adb80f0340649f6f ] The connector type and pixel format are missing for this panel, add them to prevent various drivers from failing to determine either of those parameters. Fixes: 7ee933a1d5c4 ("drm/panel: simple: Add support for AUO T215HVN01") Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:58 2023 +0300 drm/radeon: Use RMW accessors for changing LNKCTL [ Upstream commit 7189576e8a829130192b33c5b64e8a475369c776 ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <[email protected]> Fixes: 8a7cd27679d0 ("drm/radeon/cik: add support for pcie gen1/2/3 switching") Fixes: b9d305dfb66c ("drm/radeon: implement pcie gen2/3 support for SI") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yangtao Li <[email protected]> Date: Mon Jul 10 11:23:49 2023 +0800 drm/tegra: dpaux: Fix incorrect return value of platform_get_irq [ Upstream commit 2a1ca44b654346cadfc538c4fb32eecd8daf3140 ] When platform_get_irq fails, we should return dpaux->irq instead of -ENXIO. Fixes: 6b6b604215c6 ("drm/tegra: Add eDP support") Signed-off-by: Yangtao Li <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Bogdan Togorean <[email protected]> Date: Wed Jul 19 09:01:43 2023 +0300 drm: adv7511: Fix low refresh rate register for ADV7533/5 [ Upstream commit d281eeaa4de2636ff0c8e6ae387bb07b50e5fcbb ] For ADV7533 and ADV7535 low refresh rate is selected using bits [3:2] of 0x4a main register. So depending on ADV model write 0xfb or 0x4a register. Fixes: 2437e7cd88e8 ("drm/bridge: adv7533: Initial support for ADV7533") Reviewed-by: Robert Foss <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Signed-off-by: Bogdan Togorean <[email protected]> Signed-off-by: Alexandru Ardelean <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Wed Jun 7 10:05:29 2023 +0800 drm: xlnx: zynqmp_dpsub: Add missing check for dma_set_mask [ Upstream commit 1832fba7f9780aff67c96ad30f397c2d76141833 ] Add check for dma_set_mask() and return the error if it fails. Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by: Jiasheng Jiang <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Laurent Pinchart <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Krzysztof Kozlowski <[email protected]> Date: Fri Jul 28 18:59:23 2023 +0200 dt-bindings: clock: xlnx,versal-clk: drop select:false commit 172044e30b00977784269e8ab72132a48293c654 upstream. select:false makes the schema basically ignored and not effective, which is clearly not what we want for a device binding. Fixes: 352546805a44 ("dt-bindings: clock: Add bindings for versal clock driver") Cc: <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Conor Dooley <[email protected]> Reviewed-by: Shubhrajyoti Datta <[email protected]> Signed-off-by: Stephen Boyd <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Qiuxu Zhuo <[email protected]> Date: Tue Jul 25 16:04:27 2023 +0800 EDAC/igen6: Fix the issue of no error events [ Upstream commit ce53ad81ed36c24aff075f94474adecfabfcf239 ] Current igen6_edac checks for pending errors before the registration of the error handler. However, there is a possibility that the error occurs during the registration process, leading to unhandled pending errors and no future error events. This issue can be reproduced by repeatedly injecting errors during the loading of the igen6_edac. Fix this issue by moving the pending error handler after the registration of the error handler, ensuring that no pending errors are left unhandled. Fixes: 10590a9d4f23 ("EDAC/igen6: Add EDAC driver for Intel client SoCs using IBECC") Reported-by: Ee Wey Lim <[email protected]> Tested-by: Ee Wey Lim <[email protected]> Signed-off-by: Qiuxu Zhuo <[email protected]> Signed-off-by: Tony Luck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Yuanjun Gong <[email protected]> Date: Thu Jul 20 22:42:08 2023 +0800 ethernet: atheros: fix return value check in atl1c_tso_csum() [ Upstream commit 8d01da0a1db237c44c92859ce3612df7af8d3a53 ] in atl1c_tso_csum, it should check the return value of pskb_trim(), and return an error code if an unexpected value is returned by pskb_trim(). Signed-off-by: Yuanjun Gong <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wen Yang <[email protected]> Date: Sun Jul 9 14:54:51 2023 +0800 eventfd: prevent underflow for eventfd semaphores [ Upstream commit 758b492047816a3158d027e9fca660bc5bcf20bf ] For eventfd with flag EFD_SEMAPHORE, when its ctx->count is 0, calling eventfd_ctx_do_read will cause ctx->count to overflow to ULLONG_MAX. An underflow can happen with EFD_SEMAPHORE eventfds in at least the following three subsystems: (1) virt/kvm/eventfd.c (2) drivers/vfio/virqfd.c (3) drivers/virt/acrn/irqfd.c where (2) and (3) are just modeled after (1). An eventfd must be specified for use with the KVM_IRQFD ioctl(). This can also be an EFD_SEMAPHORE eventfd. When the eventfd count is zero or has been decremented to zero an underflow can be triggered when the irqfd is shut down by raising the KVM_IRQFD_FLAG_DEASSIGN flag in the KVM_IRQFD ioctl(): // ctx->count == 0 kvm_vm_ioctl() -> kvm_irqfd() -> kvm_irqfd_deassign() -> irqfd_deactivate() -> irqfd_shutdown() -> eventfd_ctx_remove_wait_queue(&cnt) -> eventfd_ctx_do_read(&cnt) Userspace polling on the eventfd wouldn't notice the underflow because 1 is always returned as the value from eventfd_read() while ctx->count would've underflowed. It's not a huge deal because this should only be happening when the irqfd is shutdown but we should still fix it and avoid the spurious wakeup. Fixes: cb289d6244a3 ("eventfd - allow atomic read and waitqueue remove") Signed-off-by: Wen Yang <[email protected]> Cc: Alexander Viro <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Dylan Yudaken <[email protected]> Cc: David Woodhouse <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: [email protected] Cc: [email protected] Message-Id: <[email protected]> [brauner: rewrite commit message and add explanation how this underflow can happen] Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Jianjian <[email protected]> Date: Thu Aug 3 00:28:39 2023 +0800 ext4: add correct group descriptors and reserved GDT blocks to system zone commit 68228da51c9a436872a4ef4b5a7692e29f7e5bc7 upstream. When setup_system_zone, flex_bg is not initialized so it is always 1. Use a new helper function, ext4_num_base_meta_blocks() which does not depend on sbi->s_log_groups_per_flex being initialized. [ Squashed two patches in the Link URL's below together into a single commit, which is simpler to review/understand. Also fix checkpatch warnings. --TYT ] Cc: [email protected] Signed-off-by: Wang Jianjian <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Tue Aug 1 22:31:56 2023 +0800 ext4: avoid potential data overflow in next_linear_group [ Upstream commit 60c672b7f2d1e5dd1774f2399b355c9314e709f8 ] ngroups is ext4_group_t (unsigned int) while next_linear_group treat it in int. If ngroups is bigger than max number described by int, it will be treat as a negative number. Then "return group + 1 >= ngroups ? 0 : group + 1;" may keep returning 0. Switch int to ext4_group_t in next_linear_group to fix the overflow. Fixes: 196e402adf2e ("ext4: improve cr 0 / cr 1 group scanning") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kemeng Shi <[email protected]> Date: Tue Aug 1 22:31:55 2023 +0800 ext4: correct grp validation in ext4_mb_good_group [ Upstream commit a9ce5993a0f5c0887c8a1b4ffa3b8046fbcfdc93 ] Group corruption check will access memory of grp and will trigger kernel crash if grp is NULL. So do NULL check before corruption check. Fixes: 5354b2af3406 ("ext4: allow ext4_get_group_info() to fail") Signed-off-by: Kemeng Shi <[email protected]> Reviewed-by: Ritesh Harjani (IBM) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhihao Cheng <[email protected]> Date: Wed Jun 28 21:20:11 2023 +0800 ext4: fix unttached inode after power cut with orphan file feature enabled [ Upstream commit 1524773425ae8113b0b782886366e68656b34e53 ] Running generic/475(filesystem consistent tests after power cut) could easily trigger unattached inode error while doing fsck: Unattached zero-length inode 39405. Clear? no Unattached inode 39405 Connect to /lost+found? no Above inconsistence is caused by following process: P1 P2 ext4_create inode = ext4_new_inode_start_handle // itable records nlink=1 ext4_add_nondir err = ext4_add_entry // ENOSPC ext4_append ext4_bread ext4_getblk ext4_map_blocks // returns ENOSPC drop_nlink(inode) // won't be updated into disk inode ext4_orphan_add(handle, inode) ext4_orphan_file_add ext4_journal_stop(handle) jbd2_journal_commit_transaction // commit success >> power cut << ext4_fill_super ext4_load_and_init_journal // itable records nlink=1 ext4_orphan_cleanup ext4_process_orphan if (inode->i_nlink) // true, inode won't be deleted Then, allocated inode will be reserved on disk and corresponds to no dentries, so e2fsck reports 'unattached inode' problem. The problem won't happen if orphan file feature is disabled, because ext4_orphan_add() will update disk inode in orphan list mode. There are several places not updating disk inode while putting inode into orphan area, such as ext4_add_nondir(), ext4_symlink() and whiteout in ext4_rename(). Fix it by updating inode into disk in all error branches of these places. Link: https://bugzilla.kernel.org/show_bug.cgi?id=217605 Fixes: 02f310fcf47f ("ext4: Speedup ext4 orphan inode handling") Signed-off-by: Zhihao Cheng <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thomas Zimmermann <[email protected]> Date: Tue Jun 13 13:06:49 2023 +0200 fbdev/ep93xx-fb: Do not assign to struct fb_info.dev commit f90a0e5265b60cdd3c77990e8105f79aa2fac994 upstream. Do not assing the Linux device to struct fb_info.dev. The call to register_framebuffer() initializes the field to the fbdev device. Drivers should not override its value. Fixes a bug where the driver incorrectly decreases the hardware device's reference counter and leaks the fbdev device. v2: * add Fixes tag (Dan) Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 88017bda96a5 ("ep93xx video driver") Cc: <[email protected]> # v2.6.32+ Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Shurong <[email protected]> Date: Sat Jul 15 22:13:38 2023 +0800 firmware: meson_sm: fix to avoid potential NULL pointer dereference [ Upstream commit f2ed165619c16577c02b703a114a1f6b52026df4 ] of_match_device() may fail and returns a NULL pointer. Fix this by checking the return value of of_match_device. Fixes: 8cde3c2153e8 ("firmware: meson_sm: Rework driver as a proper platform driver") Signed-off-by: Zhang Shurong <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Winston Wen <[email protected]> Date: Mon Jul 24 10:10:56 2023 +0800 fs/nls: make load_nls() take a const parameter [ Upstream commit c1ed39ec116272935528ca9b348b8ee79b0791da ] load_nls() take a char * parameter, use it to find nls module in list or construct the module name to load it. This change make load_nls() take a const parameter, so we don't need do some cast like this: ses->local_nls = load_nls((char *)ctx->local_nls->charset); Suggested-by: Stephen Rothwell <[email protected]> Signed-off-by: Winston Wen <[email protected]> Reviewed-by: Paulo Alcantara <[email protected]> Reviewed-by: Christian Brauner <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Ming <[email protected]> Date: Thu Jul 13 20:05:42 2023 +0800 fs: Fix error checking for d_hash_and_lookup() [ Upstream commit 0d5a4f8f775ff990142cdc810a84eae078589d27 ] The d_hash_and_lookup() function returns error pointers or NULL. Most incorrect error checks were fixed, but the one in int path_pts() was forgotten. Fixes: eedf265aa003 ("devpts: Make each mount of devpts an independent filesystem.") Signed-off-by: Wang Ming <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Su Hui <[email protected]> Date: Fri Aug 4 09:26:57 2023 +0800 fs: lockd: avoid possible wrong NULL parameter [ Upstream commit de8d38cf44bac43e83bad28357ba84784c412752 ] clang's static analysis warning: fs/lockd/mon.c: line 293, column 2: Null pointer passed as 2nd argument to memory copy function. Assuming 'hostname' is NULL and calling 'nsm_create_handle()', this will pass NULL as 2nd argument to memory copy function 'memcpy()'. So return NULL if 'hostname' is invalid. Fixes: 77a3ef33e2de ("NSM: More clean up of nsm_get_handle()") Signed-off-by: Su Hui <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Artem Chernyshev <[email protected]> Date: Thu Aug 3 17:54:17 2023 +0300 fs: ocfs2: namei: check return value of ocfs2_add_entry() [ Upstream commit 6b72e5f9e79360fce4f2be7fe81159fbdf4256a5 ] Process result of ocfs2_add_entry() in case we have an error value. Found by Linux Verification Center (linuxtesting.org) with SVACE. Link: https://lkml.kernel.org/r/[email protected] Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Artem Chernyshev <[email protected]> Reviewed-by: Joseph Qi <[email protected]> Cc: Artem Chernyshev <[email protected]> Cc: Joel Becker <[email protected]> Cc: Kurt Hackel <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Junxiao Bi <[email protected]> Cc: Changwei Ge <[email protected]> Cc: Gang He <[email protected]> Cc: Jun Piao <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eddie James <[email protected]> Date: Mon Jun 12 14:56:50 2023 -0500 fsi: aspeed: Reset master errors after CFAM reset [ Upstream commit 52300909f4670ac552bfeb33c1355b896eac8c06 ] It has been observed that sometimes the FSI master will return all 0xffs after a CFAM has been taken out of reset, without presenting any error. Resetting the FSI master errors resolves the issue. Fixes: 4a851d714ead ("fsi: aspeed: Support CFAM reset GPIO") Signed-off-by: Eddie James <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joel Stanley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Biggers <[email protected]> Date: Tue Aug 1 21:03:53 2023 -0700 fsverity: skip PKCS#7 parser when keyring is empty commit 919dc320956ea353a7fb2d84265195ad5ef525ac upstream. If an fsverity builtin signature is given for a file but the ".fs-verity" keyring is empty, there's no real reason to run the PKCS#7 parser. Skip this to avoid the PKCS#7 attack surface when builtin signature support is configured into the kernel but is not being used. This is a hardening improvement, not a fix per se, but I've added Fixes and Cc stable to get it out to more users. Fixes: 432434c9f8e1 ("fs-verity: support builtin file signatures") Cc: [email protected] Reviewed-by: Jarkko Sakkinen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Eric Biggers <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: ruanmeisi <[email protected]> Date: Tue Apr 25 19:13:54 2023 +0800 fuse: nlookup missing decrement in fuse_direntplus_link commit b8bd342d50cbf606666488488f9fea374aceb2d5 upstream. During our debugging of glusterfs, we found an Assertion failed error: inode_lookup >= nlookup, which was caused by the nlookup value in the kernel being greater than that in the FUSE file system. The issue was introduced by fuse_direntplus_link, where in the function, fuse_iget increments nlookup, and if d_splice_alias returns failure, fuse_direntplus_link returns failure without decrementing nlookup https://github.com/gluster/glusterfs/pull/4081 Signed-off-by: ruanmeisi <[email protected]> Fixes: 0b05b18381ee ("fuse: implement NFS-like readdirplus support") Cc: <[email protected]> # v3.9 Signed-off-by: Miklos Szeredi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Andreas Gruenbacher <[email protected]> Date: Thu Aug 10 17:15:46 2023 +0200 gfs2: low-memory forced flush fixes [ Upstream commit b74cd55aa9a9d0aca760028a51343ec79812e410 ] First, function gfs2_ail_flush_reqd checks the SDF_FORCE_AIL_FLUSH flag to determine if an AIL flush should be forced in low-memory situations. However, it also immediately clears the flag, and when called repeatedly as in function gfs2_logd, the flag will be lost. Fix that by pulling the SDF_FORCE_AIL_FLUSH flag check out of gfs2_ail_flush_reqd. Second, function gfs2_writepages sets the SDF_FORCE_AIL_FLUSH flag whether or not enough pages were written. If enough pages could be written, flushing the AIL is unnecessary, though. Third, gfs2_writepages doesn't wake up logd after setting the SDF_FORCE_AIL_FLUSH flag, so it can take a long time for logd to react. It would be preferable to wake up logd, but that hurts the performance of some workloads and we don't quite understand why so far, so don't wake up logd so far. Fixes: b066a4eebd4f ("gfs2: forcibly flush ail to relieve memory pressure") Signed-off-by: Andreas Gruenbacher <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andreas Gruenbacher <[email protected]> Date: Thu Aug 17 15:46:16 2023 +0200 gfs2: Switch to wait_event in gfs2_logd [ Upstream commit 6df373b09b1dcf2f7d579f515f653f89a896d417 ] In gfs2_logd(), switch from an open-coded wait loop to wait_event_interruptible_timeout(). Signed-off-by: Andreas Gruenbacher <[email protected]> Stable-dep-of: b74cd55aa9a9 ("gfs2: low-memory forced flush fixes") Signed-off-by: Sasha Levin <[email protected]>
Author: Nikita Zhandarovich <[email protected]> Date: Tue Jun 13 03:16:35 2023 -0700 HID: logitech-dj: Fix error handling in logi_dj_recv_switch_to_dj_mode() [ Upstream commit 6f20d3261265885f6a6be4cda49d7019728760e0 ] Presently, if a call to logi_dj_recv_send_report() fails, we do not learn about the error until after sending short HID_OUTPUT_REPORT with hid_hw_raw_request(). To handle this somewhat unlikely issue, return on error in logi_dj_recv_send_report() (minding ugly sleep workaround) and take into account the result of hid_hw_raw_request(). Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 6a9ddc897883 ("HID: logitech-dj: enable notifications on connect/disconnect") Signed-off-by: Nikita Zhandarovich <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rahul Rameshbabu <[email protected]> Date: Thu Aug 24 06:14:33 2023 +0000 HID: multitouch: Correct devm device reference for hidinput input_dev name [ Upstream commit 4794394635293a3e74591351fff469cea7ad15a2 ] Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management. Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string. Reported-by: Maxime Ripard <[email protected]> Closes: https://lore.kernel.org/linux-input/ZOZIZCND+L0P1wJc@penguin/T/#m443f3dce92520f74b6cf6ffa8653f9c92643d4ae Fixes: c08d46aa805b ("HID: multitouch: devm conversion") Suggested-by: Maxime Ripard <[email protected]> Suggested-by: Dmitry Torokhov <[email protected]> Signed-off-by: Rahul Rameshbabu <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Benjamin Tissoires <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ziyang Xuan <[email protected]> Date: Fri Sep 8 18:17:52 2023 +0800 hsr: Fix uninit-value access in fill_frame_info() [ Upstream commit 484b4833c604c0adcf19eac1ca14b60b757355b5 ] Syzbot reports the following uninit-value access problem. ===================================================== BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline] BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82 It is because VLAN not yet supported in hsr driver. Return error when protocol is ETH_P_8021Q in fill_frame_info() now to fix it. Fixes: 451d8123f897 ("net: prp: add packet handling support") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=bf7e6250c7ce248f3ec9 Signed-off-by: Ziyang Xuan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Biju Das <[email protected]> Date: Thu Aug 24 21:44:54 2023 +0100 hwmon: (tmp513) Fix the channel number in tmp51x_is_visible() [ Upstream commit d103337e38e7e64c3d915029e947b1cb0b512737 ] The supported channels for this driver are {0..3}. Fix the incorrect channel in tmp51x_is_visible(). Reported-by: Guenter Roeck <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Fixes: 59dfa75e5d82 ("hwmon: Add driver for Texas Instruments TMP512/513 sensor chips.") Signed-off-by: Biju Das <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Fainelli <[email protected]> Date: Thu Aug 10 12:22:08 2023 -0700 hwrng: iproc-rng200 - Implement suspend and resume calls [ Upstream commit 8e03dd62e5be811efbf0cbeba47e79e793519105 ] Chips such as BCM7278 support system wide suspend/resume which will cause the HWRNG block to lose its state and reset to its power on reset register values. We need to cleanup and re-initialize the HWRNG for it to be functional coming out of a system suspend cycle. Fixes: c3577f6100ca ("hwrng: iproc-rng200 - Add support for BCM7278") Signed-off-by: Florian Fainelli <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kaiser <[email protected]> Date: Sun Jul 2 19:35:02 2023 +0200 hwrng: nomadik - keep clock enabled while hwrng is registered [ Upstream commit 039980de89dc9dd757418d6f296e4126cc3f86c3 ] The nomadik driver uses devres to register itself with the hwrng core, the driver will be unregistered from hwrng when its device goes out of scope. This happens after the driver's remove function is called. However, nomadik's clock is disabled in the remove function. There's a short timeframe where nomadik is still registered with the hwrng core although its clock is disabled. I suppose the clock must be active to access the hardware and serve requests from the hwrng core. Switch to devm_clk_get_enabled and let devres disable the clock and unregister the hwrng. This avoids the race condition. Fixes: 3e75241be808 ("hwrng: drivers - Use device-managed registration API") Signed-off-by: Martin Kaiser <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kaiser <[email protected]> Date: Tue Jul 4 19:32:01 2023 +0200 hwrng: pic32 - use devm_clk_get_enabled [ Upstream commit 6755ad74aac0fb1c79b14724feb81b2f6ff25847 ] Use devm_clk_get_enabled in the pic32 driver. Ensure that the clock is enabled as long as the driver is registered with the hwrng core. Fixes: 7ea39973d1e5 ("hwrng: pic32 - Use device-managed registration API") Signed-off-by: Martin Kaiser <[email protected]> Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Li <[email protected]> Date: Thu Aug 31 10:13:24 2023 -0400 i3c: master: svc: fix probe failure when no i3c device exist commit 6e13d6528be2f7e801af63c8153b87293f25d736 upstream. I3C masters are expected to support hot-join. This means at initialization time we might not yet discover any device and this should not be treated as a fatal error. During the DAA procedure which happens at probe time, if no device has joined, all CCC will be NACKed (from a bus perspective). This leads to an early return with an error code which fails the probe of the master. Let's avoid this by just telling the core through an I3C_ERROR_M2 return command code that no device was discovered, which is a valid situation. This way the master will no longer bail out and fail to probe for a wrong reason. Cc: [email protected] Fixes: dd3c52846d59 ("i3c: master: svc: Add Silvaco I3C master driver") Signed-off-by: Frank Li <[email protected]> Acked-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexandre Belloni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Xiang Yang <[email protected]> Date: Fri Aug 4 10:25:25 2023 +0800 IB/uverbs: Fix an potential error pointer dereference [ Upstream commit 26b7d1a27167e7adf75b150755e05d2bc123ce55 ] smatch reports the warning below: drivers/infiniband/core/uverbs_std_types_counters.c:110 ib_uverbs_handler_UVERBS_METHOD_COUNTERS_READ() error: 'uattr' dereferencing possible ERR_PTR() The return value of uattr maybe ERR_PTR(-ENOENT), fix this by checking the value of uattr before using it. Fixes: ebb6796bd397 ("IB/uverbs: Add read counters support") Signed-off-by: Xiang Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Przemek Kitszel <[email protected]> Date: Tue Aug 8 17:54:15 2023 -0400 ice: ice_aq_check_events: fix off-by-one check when filling buffer [ Upstream commit e1e8a142c43336e3d25bfa1cb3a4ae7d00875c48 ] Allow task's event buffer to be filled also in the case that it's size is exactly the size of the message. Fixes: d69ea414c9b4 ("ice: implement device flash update via devlink") Reviewed-by: Jacob Keller <[email protected]> Signed-off-by: Przemek Kitszel <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baoquan He <[email protected]> Date: Fri Jul 7 21:58:45 2023 +0800 idmaengine: make FSL_EDMA and INTEL_IDMA64 depends on HAS_IOMEM [ Upstream commit b1e213a9e31c20206f111ec664afcf31cbfe0dbb ] On s390 systems (aka mainframes), it has classic channel devices for networking and permanent storage that are currently even more common than PCI devices. Hence it could have a fully functional s390 kernel with CONFIG_PCI=n, then the relevant iomem mapping functions [including ioremap(), devm_ioremap(), etc.] are not available. Here let FSL_EDMA and INTEL_IDMA64 depend on HAS_IOMEM so that it won't be built to cause below compiling error if PCI is unset. -------- ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! -------- Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Baoquan He <[email protected]> Cc: Vinod Koul <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ariel Marcovitch <[email protected]> Date: Sat Aug 26 20:33:17 2023 +0300 idr: fix param name in idr_alloc_cyclic() doc [ Upstream commit 2a15de80dd0f7e04a823291aa9eb49c5294f56af ] The relevant parameter is 'start' and not 'nextid' Fixes: 460488c58ca8 ("idr: Remove idr_alloc_ext") Signed-off-by: Ariel Marcovitch <[email protected]> Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Zaborska <[email protected]> Date: Tue Jul 25 10:10:58 2023 +0200 igb: Change IGB_MIN to allow set rx/tx value between 64 and 80 [ Upstream commit 6319685bdc8ad5310890add907b7c42f89302886 ] Change the minimum value of RX/TX descriptors to 64 to enable setting the rx/tx value between 64 and 80. All igb devices can use as low as 64 descriptors. This change will unify igb with other drivers. Based on commit 7b1be1987c1e ("e1000e: lower ring minimum size to 64") Fixes: 9d5c824399de ("igb: PCI-Express 82575 Gigabit Ethernet driver") Signed-off-by: Olga Zaborska <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Corinna Vinschen <[email protected]> Date: Thu Aug 31 14:19:13 2023 +0200 igb: disable virtualization features on 82580 [ Upstream commit fa09bc40b21a33937872c4c4cf0f266ec9fa4869 ] Disable virtualization features on 82580 just as on i210/i211. This avoids that virt functions are acidentally called on 82850. Fixes: 55cac248caa4 ("igb: Add full support for 82580 devices") Signed-off-by: Corinna Vinschen <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Radoslaw Tyl <[email protected]> Date: Thu Aug 24 13:46:19 2023 -0700 igb: set max size RX buffer when store bad packet is enabled commit bb5ed01cd2428cd25b1c88a3a9cba87055eb289f upstream. Increase the RX buffer size to 3K when the SBP bit is on. The size of the RX buffer determines the number of pages allocated which may not be sufficient for receive frames larger than the set MTU size. Cc: [email protected] Fixes: 89eaefb61dc9 ("igb: Support RX-ALL feature flag.") Reported-by: Manfred Rudigier <[email protected]> Signed-off-by: Radoslaw Tyl <[email protected]> Tested-by: Arpana Arland <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Olga Zaborska <[email protected]> Date: Tue Jul 25 10:10:57 2023 +0200 igbvf: Change IGBVF_MIN to allow set rx/tx value between 64 and 80 [ Upstream commit 8360717524a24a421c36ef8eb512406dbd42160a ] Change the minimum value of RX/TX descriptors to 64 to enable setting the rx/tx value between 64 and 80. All igbvf devices can use as low as 64 descriptors. This change will unify igbvf with other drivers. Based on commit 7b1be1987c1e ("e1000e: lower ring minimum size to 64") Fixes: d4e0fe01a38a ("igbvf: add new driver to support 82576 virtual functions") Signed-off-by: Olga Zaborska <[email protected]> Tested-by: Rafal Romanowski <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Zaborska <[email protected]> Date: Tue Jul 25 10:10:56 2023 +0200 igc: Change IGC_MIN to allow set rx/tx value between 64 and 80 [ Upstream commit 5aa48279712e1f134aac908acde4df798955a955 ] Change the minimum value of RX/TX descriptors to 64 to enable setting the rx/tx value between 64 and 80. All igc devices can use as low as 64 descriptors. This change will unify igc with other drivers. Based on commit 7b1be1987c1e ("e1000e: lower ring minimum size to 64") Fixes: 0507ef8a0372 ("igc: Add transmit and receive fastpath and interrupt handlers") Signed-off-by: Olga Zaborska <[email protected]> Tested-by: Naama Meir <[email protected]> Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Sep 5 04:23:38 2023 +0000 igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU commit c3b704d4a4a265660e665df51b129e8425216ed1 upstream. This is a follow up of commit 915d975b2ffa ("net: deal with integer overflows in kmalloc_reserve()") based on David Laight feedback. Back in 2010, I failed to realize malicious users could set dev->mtu to arbitrary values. This mtu has been since limited to 0x7fffffff but regardless of how big dev->mtu is, it makes no sense for igmpv3_newpack() to allocate more than IP_MAX_MTU and risk various skb fields overflows. Fixes: 57e1ab6eaddc ("igmp: refine skb allocations") Link: https://lore.kernel.org/netdev/[email protected]/ Signed-off-by: Eric Dumazet <[email protected]> Reported-by: David Laight <[email protected]> Cc: Kyle Zeng <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nayna Jain <[email protected]> Date: Tue Jul 11 12:44:47 2023 -0400 ima: Remove deprecated IMA_TRUSTED_KEYRING Kconfig [ Upstream commit 5087fd9e80e539d2163accd045b73da64de7de95 ] Time to remove "IMA_TRUSTED_KEYRING". Fixes: f4dc37785e9b ("integrity: define '.evm' as a builtin 'trusted' keyring") # v4.5+ Signed-off-by: Nayna Jain <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Sun Jul 23 22:30:18 2023 -0700 Input: tca6416-keypad - always expect proper IRQ number in i2c client [ Upstream commit 687fe7dfb736b03ab820d172ea5dbfc1ec447135 ] Remove option having i2c client contain raw gpio number instead of proper IRQ number. There are no users of this facility in mainline and it will allow cleaning up the driver code with regard to wakeup handling, etc. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Stable-dep-of: cc141c35af87 ("Input: tca6416-keypad - fix interrupt enable disbalance") Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Torokhov <[email protected]> Date: Sun Jul 23 22:30:20 2023 -0700 Input: tca6416-keypad - fix interrupt enable disbalance [ Upstream commit cc141c35af873c6796e043adcb820833bd8ef8c5 ] The driver has been switched to use IRQF_NO_AUTOEN, but in the error unwinding and remove paths calls to enable_irq() were left in place, which will lead to an incorrect enable counter value. Fixes: bcd9730a04a1 ("Input: move to use request_irq by IRQF_NO_AUTOEN flag") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Tue Sep 12 15:01:59 2023 +0100 io_uring: always lock in io_apoll_task_func From: Dylan Yudaken <[email protected]> [ upstream commit c06c6c5d276707e04cedbcc55625e984922118aa ] This is required for the failure case (io_req_complete_failed) and is missing. The alternative would be to only lock in the failure path, however all of the non-error paths in io_poll_check_events that do not do not return IOU_POLL_NO_ACTION end up locking anyway. The only extraneous lock would be for the multishot poll overflowing the CQE ring, however multishot poll would probably benefit from being locked as it will allow completions to be batched. So it seems reasonable to lock always. Signed-off-by: Dylan Yudaken <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Tue Sep 12 15:02:01 2023 +0100 io_uring: break iopolling on signal [ upstream commit dc314886cb3d0e4ab2858003e8de2917f8a3ccbd ] Don't keep spinning iopoll with a signal set. It'll eventually return back, e.g. by virtue of need_resched(), but it's not a nice user experience. Cc: [email protected] Fixes: def596e9557c9 ("io_uring: support for IO polling") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/eeba551e82cad12af30c3220125eb6cb244cc94c.1691594339.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Tue Sep 12 15:02:00 2023 +0100 io_uring: break out of iowq iopoll on teardown [ upstream commit 45500dc4e01c167ee063f3dcc22f51ced5b2b1e9 ] io-wq will retry iopoll even when it failed with -EAGAIN. If that races with task exit, which sets TIF_NOTIFY_SIGNAL for all its workers, such workers might potentially infinitely spin retrying iopoll again and again and each time failing on some allocation / waiting / etc. Don't keep spinning if io-wq is dying. Fixes: 561fb04a6a225 ("io_uring: replace workqueue usage with io-wq") Cc: [email protected] Signed-off-by: Pavel Begunkov <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Pavel Begunkov <[email protected]> Date: Wed Aug 9 13:21:41 2023 +0100 io_uring: fix drain stalls by invalid SQE [ Upstream commit cfdbaa3a291d6fd2cb4a1a70d74e63b4abc2f5ec ] cq_extra is protected by ->completion_lock, which io_get_sqe() misses. The bug is harmless as it doesn't happen in real life, requires invalid SQ index array and racing with submission, and only messes up the userspace, i.e. stall requests execution but will be cleaned up on ring destruction. Fixes: 15641e427070f ("io_uring: don't cache number of dropped SQEs") Signed-off-by: Pavel Begunkov <[email protected]> Link: https://lore.kernel.org/r/66096d54651b1a60534bb2023f2947f09f50ef73.1691538547.git.asml.silence@gmail.com Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel Marcovitch <[email protected]> Date: Fri Jun 9 10:51:45 2023 +0000 iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbind [ Upstream commit 534103bcd52ca9c1fecbc70e717b4a538dc4ded8 ] When unbinding pasid - a race condition exists vs outstanding page faults. To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbind Since refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory") Fix this issue by changing refcount_dec to refcount_dec_and_test to explicitly handle refcount=1. Fixes: 8bc54824da4e ("iommu/amd: Convert from atomic_t to refcount_t on pasid_state->count") Signed-off-by: Daniel Marcovitch <[email protected]> Signed-off-by: Vasant Hegde <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: AngeloGioacchino Del Regno <[email protected]> Date: Thu Jun 22 11:27:39 2023 +0200 iommu/qcom: Disable and reset context bank before programming [ Upstream commit 9f3fef23d9b5a858a6e6d5f478bb1b6b76265e76 ] Writing the new TTBRs, TCRs and MAIRs on a previously enabled context bank may trigger a context fault, resulting in firmware driven AP resets: change the domain initialization programming sequence to disable the context bank(s) and to also clear the related fault address (CB_FAR) and fault status (CB_FSR) registers before writing new values to TTBR0/1, TCR/TCR2, MAIR0/1. Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu") Signed-off-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jason Gunthorpe <[email protected]> Date: Mon Jul 24 14:36:05 2023 -0300 iommu/sprd: Add missing force_aperture [ Upstream commit d48a51286c698f7fe8efc688f23a532f4fe9a904 ] force_aperture was intended to false only by GART drivers that have an identity translation outside the aperture. This does not describe sprd, so add the missing 'force_aperture = true'. Fixes: b23e4fc4e3fa ("iommu: add Unisoc IOMMU basic driver") Signed-off-by: Jason Gunthorpe <[email protected]> Acked-by: Chunyan Zhang <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yanfei Xu <[email protected]> Date: Wed Aug 9 20:48:04 2023 +0800 iommu/vt-d: Fix to flush cache of PASID directory table [ Upstream commit 8a3b8e63f8371c1247b7aa24ff9c5312f1a6948b ] Even the PCI devices don't support pasid capability, PASID table is mandatory for a PCI device in scalable mode. However flushing cache of pasid directory table for these devices are not taken after pasid table is allocated as the "size" of table is zero. Fix it by calculating the size by page order. Found this when reading the code, no real problem encountered for now. Fixes: 194b3348bdbb ("iommu/vt-d: Fix PASID directory pointer coherency") Suggested-by: Lu Baolu <[email protected]> Signed-off-by: Yanfei Xu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lu Baolu <[email protected]> Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Sat Jun 17 18:25:45 2023 +0000 iommu: rockchip: Fix directory table address encoding [ Upstream commit 6df63b7ebdaf5fcd75dceedf6967d0761e56eca1 ] The physical address to the directory table is currently encoded using the following bit layout for IOMMU v2. 31:12 - Address bit 31:0 11: 4 - Address bit 39:32 This is also the bit layout used by the vendor kernel. However, testing has shown that addresses to the directory/page tables and memory pages are all encoded using the same bit layout. IOMMU v1: 31:12 - Address bit 31:0 IOMMU v2: 31:12 - Address bit 31:0 11: 8 - Address bit 35:32 7: 4 - Address bit 39:36 Change to use the mk_dtentries ops to encode the directory table address correctly. The value written to DTE_ADDR may include the valid bit set, a bit that is ignored and DTE_ADDR reg read it back as 0. This also update the bit layout comment for the page address and the number of nybbles that are read back for DTE_ADDR comment. These changes render the dte_addr_phys and dma_addr_dte ops unused and is removed. Fixes: 227014b33f62 ("iommu: rockchip: Add internal ops to handle variants") Fixes: c55356c534aa ("iommu: rockchip: Add support for iommu v2") Fixes: c987b65a574f ("iommu/rockchip: Fix physical address decoding") Signed-off-by: Jonas Karlman <[email protected]> Reviewed-by: Robin Murphy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Joerg Roedel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Sep 5 13:40:46 2023 +0000 ip_tunnels: use DEV_STATS_INC() [ Upstream commit 9b271ebaf9a2c5c566a54bc6cd915962e8241130 ] syzbot/KCSAN reported data-races in iptunnel_xmit_stats() [1] This can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. [1] BUG: KCSAN: data-race in iptunnel_xmit / iptunnel_xmit read-write to 0xffff8881353df170 of 8 bytes by task 30263 on cpu 1: iptunnel_xmit_stats include/net/ip_tunnels.h:493 [inline] iptunnel_xmit+0x432/0x4a0 net/ipv4/ip_tunnel_core.c:87 ip_tunnel_xmit+0x1477/0x1750 net/ipv4/ip_tunnel.c:831 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:662 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3560 __dev_queue_xmit+0xeee/0x1de0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] __bpf_tx_skb net/core/filter.c:2129 [inline] __bpf_redirect_no_mac net/core/filter.c:2159 [inline] __bpf_redirect+0x723/0x9c0 net/core/filter.c:2182 ____bpf_clone_redirect net/core/filter.c:2453 [inline] bpf_clone_redirect+0x16c/0x1d0 net/core/filter.c:2425 ___bpf_prog_run+0xd7d/0x41e0 kernel/bpf/core.c:1954 __bpf_prog_run512+0x74/0xa0 kernel/bpf/core.c:2195 bpf_dispatcher_nop_func include/linux/bpf.h:1181 [inline] __bpf_prog_run include/linux/filter.h:609 [inline] bpf_prog_run include/linux/filter.h:616 [inline] bpf_test_run+0x15d/0x3d0 net/bpf/test_run.c:423 bpf_prog_test_run_skb+0x77b/0xa00 net/bpf/test_run.c:1045 bpf_prog_test_run+0x265/0x3d0 kernel/bpf/syscall.c:3996 __sys_bpf+0x3af/0x780 kernel/bpf/syscall.c:5353 __do_sys_bpf kernel/bpf/syscall.c:5439 [inline] __se_sys_bpf kernel/bpf/syscall.c:5437 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5437 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read-write to 0xffff8881353df170 of 8 bytes by task 30249 on cpu 0: iptunnel_xmit_stats include/net/ip_tunnels.h:493 [inline] iptunnel_xmit+0x432/0x4a0 net/ipv4/ip_tunnel_core.c:87 ip_tunnel_xmit+0x1477/0x1750 net/ipv4/ip_tunnel.c:831 __gre_xmit net/ipv4/ip_gre.c:469 [inline] ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:662 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x11b/0x3f0 net/core/dev.c:3560 __dev_queue_xmit+0xeee/0x1de0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] __bpf_tx_skb net/core/filter.c:2129 [inline] __bpf_redirect_no_mac net/core/filter.c:2159 [inline] __bpf_redirect+0x723/0x9c0 net/core/filter.c:2182 ____bpf_clone_redirect net/core/filter.c:2453 [inline] bpf_clone_redirect+0x16c/0x1d0 net/core/filter.c:2425 ___bpf_prog_run+0xd7d/0x41e0 kernel/bpf/core.c:1954 __bpf_prog_run512+0x74/0xa0 kernel/bpf/core.c:2195 bpf_dispatcher_nop_func include/linux/bpf.h:1181 [inline] __bpf_prog_run include/linux/filter.h:609 [inline] bpf_prog_run include/linux/filter.h:616 [inline] bpf_test_run+0x15d/0x3d0 net/bpf/test_run.c:423 bpf_prog_test_run_skb+0x77b/0xa00 net/bpf/test_run.c:1045 bpf_prog_test_run+0x265/0x3d0 kernel/bpf/syscall.c:3996 __sys_bpf+0x3af/0x780 kernel/bpf/syscall.c:5353 __do_sys_bpf kernel/bpf/syscall.c:5439 [inline] __se_sys_bpf kernel/bpf/syscall.c:5437 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5437 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000018830 -> 0x0000000000018831 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 30249 Comm: syz-executor.4 Not tainted 6.5.0-syzkaller-11704-g3f86ed6ec0b3 #0 Fixes: 039f50629b7f ("ip_tunnel: Move stats update to iptunnel_xmit()") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Mon Jun 19 17:28:02 2023 +0800 ipmi:ssif: Add check for kstrdup [ Upstream commit c5586d0f711e9744d0cade39b0c4a2d116a333ca ] Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface") Signed-off-by: Jiasheng Jiang <[email protected]> Message-Id: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Corey Minyard <[email protected]> Date: Mon Jun 19 11:43:33 2023 -0500 ipmi:ssif: Fix a memory leak when scanning for an adapter [ Upstream commit b8d72e32e1453d37ee5c8a219f24e7eeadc471ef ] The adapter scan ssif_info_find() sets info->adapter_name if the adapter info came from SMBIOS, as it's not set in that case. However, this function can be called more than once, and it will leak the adapter name if it had already been set. So check for NULL before setting it. Fixes: c4436c9149c5 ("ipmi_ssif: avoid registering duplicate ssif interface") Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Yang <[email protected]> Date: Thu Jun 29 20:33:28 2023 +0800 ipmi_si: fix a memleak in try_smi_init() commit 6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f upstream. Kmemleak reported the following leak info in try_smi_init(): unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180 The problem was that when an error occurred before handlers registration and after allocating `new_smi->si_sm`, the variable wouldn't be freed in the error handling afterwards since `shutdown_smi()` hadn't been registered yet. Fix it by adding a `kfree()` in the error handling path in `try_smi_init()`. Cc: [email protected] # 4.19+ Fixes: 7960f18a5647 ("ipmi_si: Convert over to a shutdown handler") Signed-off-by: Yi Yang <[email protected]> Co-developed-by: GONG, Ruiqi <[email protected]> Signed-off-by: GONG, Ruiqi <[email protected]> Message-Id: <[email protected]> Signed-off-by: Corey Minyard <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Aug 30 09:55:20 2023 +0000 ipv4: annotate data-races around fi->fib_dead [ Upstream commit fce92af1c29d90184dfec638b5738831097d66e9 ] syzbot complained about a data-race in fib_table_lookup() [1] Add appropriate annotations to document it. [1] BUG: KCSAN: data-race in fib_release_info / fib_table_lookup write to 0xffff888150f31744 of 1 bytes by task 1189 on cpu 0: fib_release_info+0x3a0/0x460 net/ipv4/fib_semantics.c:281 fib_table_delete+0x8d2/0x900 net/ipv4/fib_trie.c:1777 fib_magic+0x1c1/0x1f0 net/ipv4/fib_frontend.c:1106 fib_del_ifaddr+0x8cf/0xa60 net/ipv4/fib_frontend.c:1317 fib_inetaddr_event+0x77/0x200 net/ipv4/fib_frontend.c:1448 notifier_call_chain kernel/notifier.c:93 [inline] blocking_notifier_call_chain+0x90/0x200 kernel/notifier.c:388 __inet_del_ifa+0x4df/0x800 net/ipv4/devinet.c:432 inet_del_ifa net/ipv4/devinet.c:469 [inline] inetdev_destroy net/ipv4/devinet.c:322 [inline] inetdev_event+0x553/0xaf0 net/ipv4/devinet.c:1606 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 call_netdevice_notifiers_info net/core/dev.c:1962 [inline] call_netdevice_notifiers_mtu+0xd2/0x130 net/core/dev.c:2037 dev_set_mtu_ext+0x30b/0x3e0 net/core/dev.c:8673 do_setlink+0x5be/0x2430 net/core/rtnetlink.c:2837 rtnl_setlink+0x255/0x300 net/core/rtnetlink.c:3177 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6445 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2549 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6463 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1914 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg net/socket.c:748 [inline] sock_write_iter+0x1aa/0x230 net/socket.c:1129 do_iter_write+0x4b4/0x7b0 fs/read_write.c:860 vfs_writev+0x1a8/0x320 fs/read_write.c:933 do_writev+0xf8/0x220 fs/read_write.c:976 __do_sys_writev fs/read_write.c:1049 [inline] __se_sys_writev fs/read_write.c:1046 [inline] __x64_sys_writev+0x45/0x50 fs/read_write.c:1046 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd read to 0xffff888150f31744 of 1 bytes by task 21839 on cpu 1: fib_table_lookup+0x2bf/0xd50 net/ipv4/fib_trie.c:1585 fib_lookup include/net/ip_fib.h:383 [inline] ip_route_output_key_hash_rcu+0x38c/0x12c0 net/ipv4/route.c:2751 ip_route_output_key_hash net/ipv4/route.c:2641 [inline] __ip_route_output_key include/net/route.h:134 [inline] ip_route_output_flow+0xa6/0x150 net/ipv4/route.c:2869 send4+0x1e7/0x500 drivers/net/wireguard/socket.c:61 wg_socket_send_skb_to_peer+0x94/0x130 drivers/net/wireguard/socket.c:175 wg_socket_send_buffer_to_peer+0xd6/0x100 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation drivers/net/wireguard/send.c:40 [inline] wg_packet_handshake_send_worker+0x10c/0x150 drivers/net/wireguard/send.c:51 process_one_work+0x434/0x860 kernel/workqueue.c:2600 worker_thread+0x5f2/0xa10 kernel/workqueue.c:2751 kthread+0x1d7/0x210 kernel/kthread.c:389 ret_from_fork+0x2e/0x40 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 21839 Comm: kworker/u4:18 Tainted: G W 6.5.0-syzkaller #0 Fixes: dccd9ecc3744 ("ipv4: Do not use dead fib_info entries.") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sriram Yagnaraman <[email protected]> Date: Thu Aug 31 10:03:30 2023 +0200 ipv4: ignore dst hint for multipath routes [ Upstream commit 6ac66cb03ae306c2e288a9be18226310529f5b25 ] Route hints when the nexthop is part of a multipath group causes packets in the same receive batch to be sent to the same nexthop irrespective of the multipath hash of the packet. So, do not extract route hint for packets whose destination is part of a multipath group. A new SKB flag IPSKB_MULTIPATH is introduced for this purpose, set the flag when route is looked up in ip_mkroute_input() and use it in ip_extract_route_hint() to check for the existence of the flag. Fixes: 02b24941619f ("ipv4: use dst hint for ipv4 list receive") Signed-off-by: Sriram Yagnaraman <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: David Ahern <[email protected]> Date: Fri Feb 11 09:15:07 2022 -0800 ipv6: Add reasons for skb drops to __udp6_lib_rcv [ Upstream commit 4cf91f825b2777f81799f98ce32172b829acd1b2 ] Add reasons to __udp6_lib_rcv for skb drops. The only twist is that the NO_SOCKET takes precedence over the CSUM or other counters for that path (motivation behind this patch - csum counter was misleading). Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]> Stable-dep-of: 9c02bec95954 ("bpf, net: Support SO_REUSEPORT sockets with bpf_sk_assign") Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Mon Sep 11 15:42:13 2023 +0000 ipv6: fix ip6_sock_set_addr_preferences() typo [ Upstream commit 8cdd9f1aaedf823006449faa4e540026c692ac43 ] ip6_sock_set_addr_preferences() second argument should be an integer. SUNRPC attempts to set IPV6_PREFER_SRC_PUBLIC were translated to IPV6_PREFER_SRC_TMP Fixes: 18d5ad623275 ("ipv6: add ip6_sock_set_addr_preferences") Signed-off-by: Eric Dumazet <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Chuck Lever <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vadim Fedorenko <[email protected]> Date: Mon Sep 11 13:28:14 2023 -0700 ixgbe: fix timestamp configuration code [ Upstream commit 3c44191dd76cf9c0cc49adaf34384cbd42ef8ad2 ] The commit in fixes introduced flags to control the status of hardware configuration while processing packets. At the same time another structure is used to provide configuration of timestamper to user-space applications. The way it was coded makes this structures go out of sync easily. The repro is easy for 82599 chips: [root@hostname ~]# hwstamp_ctl -i eth0 -r 12 -t 1 current settings: tx_type 0 rx_filter 0 new settings: tx_type 1 rx_filter 12 The eth0 device is properly configured to timestamp any PTPv2 events. [root@hostname ~]# hwstamp_ctl -i eth0 -r 1 -t 1 current settings: tx_type 1 rx_filter 12 SIOCSHWTSTAMP failed: Numerical result out of range The requested time stamping mode is not supported by the hardware. The error is properly returned because HW doesn't support all packets timestamping. But the adapter->flags is cleared of timestamp flags even though no HW configuration was done. From that point no RX timestamps are received by user-space application. But configuration shows good values: [root@hostname ~]# hwstamp_ctl -i eth0 current settings: tx_type 1 rx_filter 12 Fix the issue by applying new flags only when the HW was actually configured. Fixes: a9763f3cb54c ("ixgbe: Update PTP to support X550EM_x devices") Signed-off-by: Vadim Fedorenko <[email protected]> Reviewed-by: Simon Horman <[email protected]> Tested-by: Pucha Himasekhar Reddy <[email protected]> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zhihao Cheng <[email protected]> Date: Fri Jul 14 10:55:27 2023 +0800 jbd2: check 'jh->b_transaction' before removing it from checkpoint commit 590a809ff743e7bd890ba5fb36bc38e20a36de53 upstream. Following process will corrupt ext4 image: Step 1: jbd2_journal_commit_transaction __jbd2_journal_insert_checkpoint(jh, commit_transaction) // Put jh into trans1->t_checkpoint_list journal->j_checkpoint_transactions = commit_transaction // Put trans1 into journal->j_checkpoint_transactions Step 2: do_get_write_access test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2 Step 3: drop_cache journal_shrink_one_cp_list jbd2_journal_try_remove_checkpoint if (!trylock_buffer(bh)) // lock bh, true if (buffer_dirty(bh)) // buffer is not dirty __jbd2_journal_remove_checkpoint(jh) // remove jh from trans1->t_checkpoint_list Step 4: jbd2_log_do_checkpoint trans1 = journal->j_checkpoint_transactions // jh is not in trans1->t_checkpoint_list jbd2_cleanup_journal_tail(journal) // trans1 is done Step 5: Power cut, trans2 is not committed, jh is lost in next mounting. Fix it by checking 'jh->b_transaction' before remove it from checkpoint. Cc: [email protected] Fixes: 46f881b5b175 ("jbd2: fix a race when checking checkpoint buffer busy") Signed-off-by: Zhihao Cheng <[email protected]> Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Yi <[email protected]> Date: Fri Jul 14 10:55:26 2023 +0800 jbd2: fix checkpoint cleanup performance regression commit 373ac521799d9e97061515aca6ec6621789036bb upstream. journal_clean_one_cp_list() has been merged into journal_shrink_one_cp_list(), but do chekpoint buffer cleanup from the committing process is just a best effort, it should stop scan once it meet a busy buffer, or else it will cause a lot of invalid buffer scan and checks. We catch a performance regression when doing fs_mark tests below. Test cmd: ./fs_mark -d scratch -s 1024 -n 10000 -t 1 -D 100 -N 100 Before merging checkpoint buffer cleanup: FSUse% Count Size Files/sec App Overhead 95 10000 1024 8304.9 49033 After merging checkpoint buffer cleanup: FSUse% Count Size Files/sec App Overhead 95 10000 1024 7649.0 50012 FSUse% Count Size Files/sec App Overhead 95 10000 1024 2107.1 50871 After merging checkpoint buffer cleanup, the total loop count in journal_shrink_one_cp_list() could be up to 6,261,600+ (50,000+ ~ 100,000+ in general), most of them are invalid. This patch fix it through passing 'shrink_type' into journal_shrink_one_cp_list() and add a new 'SHRINK_BUSY_STOP' to indicate it should stop once meet a busy buffer. After fix, the loop count descending back to 10,000+. After this fix: FSUse% Count Size Files/sec App Overhead 95 10000 1024 8558.4 49109 Cc: [email protected] Fixes: b98dba273a0e ("jbd2: remove journal_clean_one_cp_list()") Signed-off-by: Zhang Yi <[email protected]> Reviewed-by: Jan Kara <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Theodore Ts'o <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alexei Filippov <[email protected]> Date: Sat Aug 19 20:32:16 2023 +0300 jfs: validate max amount of blocks before allocation. [ Upstream commit 0225e10972fa809728b8d4c1bd2772b3ec3fdb57 ] The lack of checking bmp->db_max_freebud in extBalloc() can lead to shift out of bounds, so this patch prevents undefined behavior, because bmp->db_max_freebud == -1 only if there is no free space. Signed-off-by: Aleksei Filippov <[email protected]> Signed-off-by: Dave Kleikamp <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?id=01abadbd6ae6a08b1f1987aa61554c6b3ac19ff2 Signed-off-by: Sasha Levin <[email protected]>
Author: Masahiro Yamada <[email protected]> Date: Wed Aug 23 20:50:41 2023 +0900 kbuild: do not run depmod for 'make modules_sign' [ Upstream commit 2429742e506a2b5939a62c629c4a46d91df0ada8 ] Commit 961ab4a3cd66 ("kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinst") started to run depmod at the end of 'make modules_sign'. Move the depmod rule to scripts/Makefile.modinst and run it only when $(modules_sign_only) is empty. Fixes: 961ab4a3cd66 ("kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinst") Signed-off-by: Masahiro Yamada <[email protected]> Reviewed-by: Nicolas Schier <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shigeru Yoshida <[email protected]> Date: Sun Sep 3 02:07:08 2023 +0900 kcm: Destroy mutex in kcm_exit_net() [ Upstream commit 6ad40b36cd3b04209e2d6c89d252c873d8082a59 ] kcm_exit_net() should call mutex_destroy() on knet->mutex. This is especially needed if CONFIG_DEBUG_MUTEXES is enabled. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Shigeru Yoshida <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Mon Sep 11 19:27:53 2023 -0700 kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg(). [ Upstream commit a22730b1b4bf437c6bbfdeff5feddf54be4aeada ] syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720 ("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it by updating kcm_tx_msg(head)->last_skb if partial data is copied so that the following sendmsg() will resume from the skb. However, we cannot know how many bytes were copied when we get the error. Thus, we could mess up the MSG_MORE queue. When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as we do so for UDP by udp_flush_pending_frames(). Even without this change, when the error occurred, the following sendmsg() resumed from a wrong skb and the queue was messed up. However, we have yet to get such a report, and only syzkaller stumbled on it. So, this can be changed safely. Note this does not change SOCK_SEQPACKET behaviour. Fixes: c821a88bd720 ("kcm: Fix memory leak in error path of kcm_sendmsg()") Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Kuniyuki Iwashima <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shigeru Yoshida <[email protected]> Date: Sun Sep 10 02:03:10 2023 +0900 kcm: Fix memory leak in error path of kcm_sendmsg() [ Upstream commit c821a88bd720b0046433173185fd841a100d44ad ] syzbot reported a memory leak like below: BUG: memory leak unreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff83e5d5ff>] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [<ffffffff84606e59>] alloc_skb include/linux/skbuff.h:1289 [inline] [<ffffffff84606e59>] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [<ffffffff83e479c6>] sock_sendmsg_nosec net/socket.c:725 [inline] [<ffffffff83e479c6>] sock_sendmsg+0x56/0xb0 net/socket.c:748 [<ffffffff83e47f55>] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [<ffffffff83e4c389>] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [<ffffffff83e4c536>] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [<ffffffff84ad7bb8>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84ad7bb8>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd In kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to append newly allocated skbs to 'head'. If some bytes are copied, an error occurred, and jumped to out_error label, 'last_skb' is left unmodified. A later kcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the 'head' frag_list and causing the leak. This patch fixes this issue by properly updating the last allocated skb in 'last_skb'. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Reported-and-tested-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=6f98de741f7dbbfc4ccb Signed-off-by: Shigeru Yoshida <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konstantin Meskhidze <[email protected]> Date: Tue Sep 5 17:59:14 2023 +0800 kconfig: fix possible buffer overflow [ Upstream commit a3b7039bb2b22fcd2ad20d59c00ed4e606ce3754 ] Buffer 'new_argv' is accessed without bound check after accessing with bound check via 'new_argc' index. Fixes: e298f3b49def ("kconfig: add built-in function support") Co-developed-by: Ivanov Mikhail <[email protected]> Signed-off-by: Konstantin Meskhidze <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Masami Hiramatsu (Google) <[email protected]> Date: Tue Jul 11 10:50:47 2023 +0900 kprobes: Prohibit probing on CFI preamble symbol [ Upstream commit de02f2ac5d8cfb311f44f2bf144cc20002f1fbbd ] Do not allow to probe on "__cfi_" or "__pfx_" started symbol, because those are used for CFI and not executed. Probing it will break the CFI. Link: https://lore.kernel.org/all/168904024679.116016.18089228029322008512.stgit@devnote2/ Signed-off-by: Masami Hiramatsu (Google) <[email protected]> Reviewed-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Björn Töpel <[email protected]> Date: Wed Jul 5 13:53:17 2023 +0200 kselftest/runner.sh: Propagate SIGTERM to runner child [ Upstream commit 9616cb34b08ec86642b162eae75c5a7ca8debe3c ] Timeouts in kselftest are done using the "timeout" command with the "--foreground" option. Without the "foreground" option, it is not possible for a user to cancel the runner using SIGINT, because the signal is not propagated to timeout which is running in a different process group. The "forground" options places the timeout in the same process group as its parent, but only sends the SIGTERM (on timeout) signal to the forked process. Unfortunately, this does not play nice with all kselftests, e.g. "net:fcnal-test.sh", where the child processes will linger because timeout does not send SIGTERM to the group. Some users have noted these hangs [1]. Fix this by nesting the timeout with an additional timeout without the foreground option. Link: https://lore.kernel.org/all/[email protected]/ # [1] Fixes: 651e0d881461 ("kselftest/runner: allow to properly deliver signals to tests") Signed-off-by: Björn Töpel <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sat Jul 22 00:09:28 2023 +0900 ksmbd: fix out of bounds in smb3_decrypt_req() [ Upstream commit dc318846f3dd54574a36ae97fc8d8b75dd7cdb1e ] smb3_decrypt_req() validate if pdu_length is smaller than smb2_transform_hdr size. Reported-by: [email protected] # ZDI-CAN-21589 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namjae Jeon <[email protected]> Date: Sun Jul 23 15:22:33 2023 +0900 ksmbd: no response from compound read [ Upstream commit e202a1e8634b186da38cbbff85382ea2b9e297cf ] ksmbd doesn't support compound read. If client send read-read in compound to ksmbd, there can be memory leak from read buffer. Windows and linux clients doesn't send it to server yet. For now, No response from compound read. compound read will be supported soon. Reported-by: [email protected] # ZDI-CAN-21587, ZDI-CAN-21588 Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Behún <[email protected]> Date: Tue Aug 1 14:49:31 2023 +0200 leds: multicolor: Use rounded division when calculating color components [ Upstream commit 065d099f1be58187e6629273c50b948a02b7e1bf ] Given channel intensity, LED brightness and max LED brightness, the multicolor LED framework helper led_mc_calc_color_components() computes the color channel brightness as chan_brightness = brightness * chan_intensity / max_brightness Consider the situation when (brightness, intensity, max_brightness) is for example (16, 15, 255), then chan_brightness is computed to 0 although the fractional divison would give 0.94, which should be rounded to 1. Use DIV_ROUND_CLOSEST here for the division to give more realistic component computation: chan_brightness = DIV_ROUND_CLOSEST(brightness * chan_intensity, max_brightness) Fixes: 55d5d3b46b08 ("leds: multicolor: Introduce a multicolor class definition") Signed-off-by: Marek Behún <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Tue Jul 11 09:13:34 2023 +0300 leds: pwm: Fix error code in led_pwm_create_fwnode() [ Upstream commit cadb2de2a7fd9e955381307de3eddfcc386c208e ] Negative -EINVAL was intended, not positive EINVAL. Fix it. Fixes: 95138e01275e ("leds: pwm: Make error handling more robust") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Behún <[email protected]> Date: Wed Aug 2 11:07:53 2023 +0200 leds: trigger: tty: Do not use LED_ON/OFF constants, use led_blink_set_oneshot instead [ Upstream commit 730094577e0c37e1bc40be37cbd41f71b0a8a2a4 ] The tty LED trigger uses the obsolete LED_ON & LED_OFF constants when setting LED brightness. This is bad because the LED_ON constant is equal to 1, and so when activating the tty LED trigger on a LED class device with max_brightness greater than 1, the LED is dimmer than it can be (when max_brightness is 255, the LED is very dimm indeed; some devices translate 1/255 to 0, so the LED is OFF all the time). Instead of directly setting brightness to a specific value, use the led_blink_set_oneshot() function from LED core to configure the blink. This function takes the current configured brightness as blink brightness if not zero, and max brightness otherwise. This also changes the behavior of the TTY LED trigger. Previously if rx/tx stats kept changing, the LED was ON all the time they kept changing. With this patch the LED will blink on TTY activity. Fixes: fd4a641ac88f ("leds: trigger: implement a tty trigger") Signed-off-by: Marek Behún <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andrew Donnellan <[email protected]> Date: Fri Jul 14 11:52:38 2023 +1000 lib/test_meminit: allocate pages up to order MAX_ORDER commit efb78fa86e95832b78ca0ba60f3706788a818938 upstream. test_pages() tests the page allocator by calling alloc_pages() with different orders up to order 10. However, different architectures and platforms support different maximum contiguous allocation sizes. The default maximum allocation order (MAX_ORDER) is 10, but architectures can use CONFIG_ARCH_FORCE_MAX_ORDER to override this. On platforms where this is less than 10, test_meminit() will blow up with a WARN(). This is expected, so let's not do that. Replace the hardcoded "10" with the MAX_ORDER macro so that we test allocations up to the expected platform limit. Link: https://lkml.kernel.org/r/[email protected] Fixes: 5015a300a522 ("lib: introduce test_meminit module") Signed-off-by: Andrew Donnellan <[email protected]> Reviewed-by: Alexander Potapenko <[email protected]> Cc: Xiaoke Wang <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Mon Aug 7 08:36:28 2023 -0700 lib: test_scanf: Add explicit type cast to result initialization in test_number_prefix() commit 92382d744176f230101d54f5c017bccd62770f01 upstream. A recent change in clang allows it to consider more expressions as compile time constants, which causes it to point out an implicit conversion in the scanf tests: lib/test_scanf.c:661:2: warning: implicit conversion from 'int' to 'unsigned char' changes value from -168 to 88 [-Wconstant-conversion] 661 | test_number_prefix(unsigned char, "0xA7", "%2hhx%hhx", 0, 0xa7, 2, check_uchar); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ lib/test_scanf.c:609:29: note: expanded from macro 'test_number_prefix' 609 | T result[2] = {~expect[0], ~expect[1]}; \ | ~ ^~~~~~~~~~ 1 warning generated. The result of the bitwise negation is the type of the operand after going through the integer promotion rules, so this truncation is expected but harmless, as the initial values in the result array get overwritten by _test() anyways. Add an explicit cast to the expected type in test_number_prefix() to silence the warning. There is no functional change, as all the tests still pass with GCC 13.1.0 and clang 18.0.0. Cc: [email protected] Link: https://github.com/ClangBuiltLinux/linuxq/issues/1899 Link: https://github.com/llvm/llvm-project/commit/610ec954e1f81c0e8fcadedcd25afe643f5a094e Suggested-by: Nick Desaulniers <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/20230807-test_scanf-wconstant-conversion-v2-1-839ca39083e1@kernel.org Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Tue Sep 19 12:23:04 2023 +0200 Linux 5.15.132 Link: https://lore.kernel.org/r/[email protected] Tested-by: SeongJae Park <[email protected]> Tested-by: Ron Economos <[email protected]> Tested-by: Jon Hunter <[email protected]> Tested-by: Florian Fainelli <[email protected]> Tested-by: Harshit Mogalapalli <[email protected]> Tested-by: Linux Kernel Functional Testing <[email protected]> Tested-by: Shuah Khan <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yan Zhai <[email protected]> Date: Thu Aug 17 19:58:14 2023 -0700 lwt: Check LWTUNNEL_XMIT_CONTINUE strictly [ Upstream commit a171fbec88a2c730b108c7147ac5e7b2f5a02b47 ] LWTUNNEL_XMIT_CONTINUE is implicitly assumed in ip(6)_finish_output2, such that any positive return value from a xmit hook could cause unexpected continue behavior, despite that related skb may have been freed. This could be error-prone for future xmit hook ops. One of the possible errors is to return statuses of dst_output directly. To make the code safer, redefine LWTUNNEL_XMIT_CONTINUE value to distinguish from dst_output statuses and check the continue condition explicitly. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Suggested-by: Dan Carpenter <[email protected]> Signed-off-by: Yan Zhai <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/96b939b85eda00e8df4f7c080f770970a4c5f698.1692326837.git.yan@cloudflare.com Signed-off-by: Sasha Levin <[email protected]>
Author: Yan Zhai <[email protected]> Date: Thu Aug 17 19:58:11 2023 -0700 lwt: Fix return values of BPF xmit ops [ Upstream commit 29b22badb7a84b783e3a4fffca16f7768fb31205 ] BPF encap ops can return different types of positive values, such like NET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from function skb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such return values would be treated implicitly as LWTUNNEL_XMIT_CONTINUE in ip(6)_finish_output2. When this happens, skbs that have been freed would continue to the neighbor subsystem, causing use-after-free bug and kernel crashes. To fix the incorrect behavior, skb_do_redirect return values can be simply discarded, the same as tc-egress behavior. On the other hand, bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTU information. Thus convert its return values to avoid the conflict with LWTUNNEL_XMIT_CONTINUE. Fixes: 3a0af8fd61f9 ("bpf: BPF for lightweight tunnel infrastructure") Reported-by: Jordan Griege <[email protected]> Suggested-by: Martin KaFai Lau <[email protected]> Suggested-by: Stanislav Fomichev <[email protected]> Signed-off-by: Yan Zhai <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/0d2b878186cfe215fec6b45769c1cd0591d3628d.1692326837.git.yan@cloudflare.com Signed-off-by: Sasha Levin <[email protected]>
Author: Ben Hutchings <[email protected]> Date: Fri Jun 16 17:36:10 2023 +0200 m68k: Fix invalid .section syntax [ Upstream commit 922a9bd138101e3e5718f0f4d40dba68ef89bb43 ] gas supports several different forms for .section for ELF targets, including: .section NAME [, "FLAGS"[, @TYPE[,FLAG_SPECIFIC_ARGUMENTS]]] and: .section "NAME"[, #FLAGS...] In several places we use a mix of these two forms: .section NAME, #FLAGS... A current development snapshot of binutils (2.40.50.20230611) treats this mixed syntax as an error. Change to consistently use: .section NAME, "FLAGS" as is used elsewhere in the kernel. Link: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=m68k&ver=6.4%7Erc6-1%7Eexp1&stamp=1686907300&raw=1 Signed-off-by: Ben Hutchings <[email protected]> Tested-by: Jan-Benedict Glaw <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guoqing Jiang <[email protected]> Date: Sun Oct 17 21:50:17 2021 +0800 md/bitmap: don't set max_write_behind if there is no write mostly device [ Upstream commit 8c13ab115b577bd09097b9d77916732e97e31b7b ] We shouldn't set it since write behind IO should only happen to write mostly device. Signed-off-by: Guoqing Jiang <[email protected]> Signed-off-by: Song Liu <[email protected]> Stable-dep-of: 44abfa6a95df ("md/md-bitmap: hold 'reconfig_mutex' in backlog_store()") Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jul 6 16:37:27 2023 +0800 md/md-bitmap: hold 'reconfig_mutex' in backlog_store() [ Upstream commit 44abfa6a95df425c0660d56043020b67e6d93ab8 ] Several reasons why 'reconfig_mutex' should be held: 1) rdev_for_each() is not safe to be called without the lock, because rdev can be removed concurrently. 2) mddev_destroy_serial_pool() and mddev_create_serial_pool() should not be called concurrently. 3) mddev_suspend() from mddev_destroy/create_serial_pool() should be protected by the lock. Fixes: 10c92fca636e ("md-bitmap: create and destroy wb_info_pool with the change of backlog") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yu Kuai <[email protected]> Date: Thu Jul 6 16:37:26 2023 +0800 md/md-bitmap: remove unnecessary local variable in backlog_store() commit b4d129640f194ffc4cc64c3e97f98ae944c072e8 upstream. Local variable is definied first in the beginning of backlog_store(), there is no need to define it again. Fixes: 8c13ab115b57 ("md/bitmap: don't set max_write_behind if there is no write mostly device") Signed-off-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Kara <[email protected]> Date: Mon Aug 14 11:27:07 2023 +0200 md/raid0: Factor out helper for mapping and submitting a bio [ Upstream commit af50e20afb401cc203bd2a9ff62ece0ae4976103 ] Factor out helper function for mapping and submitting a bio out of raid0_make_request(). We will use it later for submitting both parts of a split bio. Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Stable-dep-of: 319ff40a5427 ("md/raid0: Fix performance regression for large sequential writes") Signed-off-by: Sasha Levin <[email protected]>
Author: Jan Kara <[email protected]> Date: Mon Aug 14 11:27:08 2023 +0200 md/raid0: Fix performance regression for large sequential writes [ Upstream commit 319ff40a542736d67e5bce18635de35d0e7a0bff ] Commit f00d7c85be9e ("md/raid0: fix up bio splitting.") among other things changed how bio that needs to be split is submitted. Before this commit, we have split the bio, mapped and submitted each part. After this commit, we map only the first part of the split bio and submit the second part unmapped. Due to bio sorting in __submit_bio_noacct() this results in the following request ordering: 9,0 18 1181 0.525037895 15995 Q WS 1479315464 + 63392 Split off chunk-sized (1024 sectors) request: 9,0 18 1182 0.629019647 15995 X WS 1479315464 / 1479316488 Request is unaligned to the chunk so it's split in raid0_make_request(). This is the first part mapped and punted to bio_list: 8,0 18 7053 0.629020455 15995 A WS 739921928 + 1016 <- (9,0) 1479315464 Now raid0_make_request() returns, second part is postponed on bio_list. __submit_bio_noacct() resorts the bio_list, mapped request is submitted to the underlying device: 8,0 18 7054 0.629022782 15995 G WS 739921928 + 1016 Now we take another request from the bio_list which is the remainder of the original huge request. Split off another chunk-sized bit from it and the situation repeats: 9,0 18 1183 0.629024499 15995 X WS 1479316488 / 1479317512 8,16 18 6998 0.629025110 15995 A WS 739921928 + 1016 <- (9,0) 1479316488 8,16 18 6999 0.629026728 15995 G WS 739921928 + 1016 ... 9,0 18 1184 0.629032940 15995 X WS 1479317512 / 1479318536 [libnetacq-write] 8,0 18 7059 0.629033294 15995 A WS 739922952 + 1016 <- (9,0) 1479317512 8,0 18 7060 0.629033902 15995 G WS 739922952 + 1016 ... This repeats until we consume the whole original huge request. Now we finally get to processing the second parts of the split off requests (in reverse order): 8,16 18 7181 0.629161384 15995 A WS 739952640 + 8 <- (9,0) 1479377920 8,0 18 7239 0.629162140 15995 A WS 739952640 + 8 <- (9,0) 1479376896 8,16 18 7186 0.629163881 15995 A WS 739951616 + 8 <- (9,0) 1479375872 8,0 18 7242 0.629164421 15995 A WS 739951616 + 8 <- (9,0) 1479374848 ... I guess it is obvious that this IO pattern is extremely inefficient way to perform sequential IO. It also makes bio_list to grow to rather long lengths. Change raid0_make_request() to map both parts of the split bio. Since we know we are provided with at most chunk-sized bios, we will always need to split the incoming bio at most once. Fixes: f00d7c85be9e ("md/raid0: fix up bio splitting.") Signed-off-by: Jan Kara <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Li Nan <[email protected]> Date: Sat Jul 1 16:05:28 2023 +0800 md/raid10: factor out dereference_rdev_and_rrdev() [ Upstream commit b99f8fd2d91eb734f13098aa1cf337edaca454b7 ] Factor out a helper to get 'rdev' and 'replacement' from config->mirrors. Just to make code cleaner and prepare to fix the bug of io loss while 'replacement' replace 'rdev'. There is no functional change. Signed-off-by: Li Nan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Stable-dep-of: 673643490b9a ("md/raid10: use dereference_rdev_and_rrdev() to get devices") Signed-off-by: Sasha Levin <[email protected]>
Author: Li Nan <[email protected]> Date: Sat Jul 1 16:05:29 2023 +0800 md/raid10: use dereference_rdev_and_rrdev() to get devices [ Upstream commit 673643490b9a0eb3b25633abe604f62b8f63dba1 ] Commit 2ae6aaf76912 ("md/raid10: fix io loss while replacement replace rdev") reads replacement first to prevent io loss. However, there are same issue in wait_blocked_dev() and raid10_handle_discard(), too. Fix it by using dereference_rdev_and_rrdev() to get devices. Fixes: d30588b2731f ("md/raid10: improve raid10 discard request") Fixes: f2e7e269a752 ("md/raid10: pull the code that wait for blocked dev into one function") Signed-off-by: Li Nan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Song Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mariusz Tkaczyk <[email protected]> Date: Mon Mar 6 14:03:17 2023 +0100 md: add error_handlers for raid0 and linear [ Upstream commit c31fea2f8e2a72c817f318016bbc327095175a9f ] After the commit 9631abdbf406c("md: Set MD_BROKEN for RAID1 and RAID10") MD_BROKEN must be set if array is failed because state_store() checks it. If it is set then -EBUSY is returned to userspace. For raid0 and linear MD_BROKEN is not set by error_handler(). As a result mdadm is unable to trigger clean-up actions. It is a regression. This patch adds appropriate error_handler for raid0 and linear. The error handler sets MD_BROKEN for this device. Reviewed-by: Xiao Ni <[email protected]> Signed-off-by: Mariusz Tkaczyk <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: 319ff40a5427 ("md/raid0: Fix performance regression for large sequential writes") Signed-off-by: Sasha Levin <[email protected]>
Author: David Jeffery <[email protected]> Date: Wed Aug 16 14:13:55 2023 -0400 md: raid0: account for split bio in iostat accounting [ Upstream commit cc22b5407e9ca76adb7efeed843146510b1b72a5 ] When a bio is split by md raid0, the newly created bio will not be tracked by md for I/O accounting. Only the portion of I/O still assigned to the original bio which was reduced by the split will be accounted for. This results in md iostat data sometimes showing I/O values far below the actual amount of data being sent through md. md_account_bio() needs to be called for all bio generated by the bio split. A simple example of the issue was generated using a raid0 device on partitions to the same device. Since all raid0 I/O then goes to one device, it makes it easy to see a gap between the md device and its sd storage. Reading an lvm device on top of the md device, the iostat output (some 0 columns and extra devices removed to make the data more compact) was: Device tps kB_read/s kB_wrtn/s kB_dscd/s kB_read md2 0.00 0.00 0.00 0.00 0 sde 0.00 0.00 0.00 0.00 0 md2 1364.00 411496.00 0.00 0.00 411496 sde 1734.00 646144.00 0.00 0.00 646144 md2 1699.00 510680.00 0.00 0.00 510680 sde 2155.00 802784.00 0.00 0.00 802784 md2 803.00 241480.00 0.00 0.00 241480 sde 1016.00 377888.00 0.00 0.00 377888 md2 0.00 0.00 0.00 0.00 0 sde 0.00 0.00 0.00 0.00 0 I/O was generated doing large direct I/O reads (12M) with dd to a linear lvm volume on top of the 4 leg raid0 device. The md2 reads were showing as roughly 2/3 of the reads to the sde device containing all of md2's raid partitions. The sum of reads to sde was 1826816 kB, which was the expected amount as it was the amount read by dd. With the patch, the total reads from md will match the reads from sde and be consistent with the amount of I/O generated. Fixes: 10764815ff47 ("md: add io accounting for raid0 and raid5") Signed-off-by: David Jeffery <[email protected]> Tested-by: Laurence Oberman <[email protected]> Reviewed-by: Laurence Oberman <[email protected]> Reviewed-by: Yu Kuai <[email protected]> Signed-off-by: Song Liu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mariusz Tkaczyk <[email protected]> Date: Tue Mar 22 16:23:38 2022 +0100 md: Set MD_BROKEN for RAID1 and RAID10 [ Upstream commit 9631abdbf406c764f2a5d8305eac063bc3396a0a ] There is no direct mechanism to determine raid failure outside personality. It is done by checking rdev->flags after executing md_error(). If "faulty" flag is not set then -EBUSY is returned to userspace. -EBUSY means that array will be failed after drive removal. Mdadm has special routine to handle the array failure and it is executed if -EBUSY is returned by md. There are at least two known reasons to not consider this mechanism as correct: 1. drive can be removed even if array will be failed[1]. 2. -EBUSY seems to be wrong status. Array is not busy, but removal process cannot proceed safe. -EBUSY expectation cannot be removed without breaking compatibility with userspace. In this patch first issue is resolved by adding support for MD_BROKEN flag for RAID1 and RAID10. Support for RAID456 is added in next commit. The idea is to set the MD_BROKEN if we are sure that raid is in failed state now. This is done in each error_handler(). In md_error() MD_BROKEN flag is checked. If is set, then -EBUSY is returned to userspace. As in previous commit, it causes that #mdadm --set-faulty is able to fail array. Previously proposed workaround is valid if optional functionality[1] is disabled. [1] commit 9a567843f7ce("md: allow last device to be forcibly removed from RAID1/RAID10.") Reviewd-by: Xiao Ni <[email protected]> Signed-off-by: Mariusz Tkaczyk <[email protected]> Signed-off-by: Song Liu <[email protected]> Stable-dep-of: 319ff40a5427 ("md/raid0: Fix performance regression for large sequential writes") Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sun Jun 18 20:17:40 2023 +0200 media: ad5820: Drop unsupported ad5823 from i2c_ and of_device_id tables [ Upstream commit f126ff7e4024f6704e6ec0d4137037568708a3c7 ] The supported ad5820 and ad5821 VCMs both use a single 16 bit register which is written by sending 2 bytes with the data directly after sending the i2c-client address. The ad5823 OTOH has a more typical i2c / smbus device setup with multiple 8 bit registers where the first byte send after the i2c-client address is the register address and the actual data only starts from the second byte after the i2c-client address. The ad5823 i2c_ and of_device_id-s was added at the same time as the ad5821 ids with as rationale: """ Some camera modules also refer that AD5823 is a replacement of AD5820: https://download.kamami.com/p564094-OV8865_DS.pdf """ The AD5823 may be an electrical and functional replacement of the AD5820, but from a software pov it is not compatible at all and it is going to need its own driver, drop its id from the ad5820 driver. Fixes: b8bf73136bae ("media: ad5820: Add support for ad5821 and ad5823") Cc: Pavel Machek <[email protected]> Cc: Ricardo Ribalda Delgado <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ricardo Ribalda <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniil Dulov <[email protected]> Date: Fri Jun 2 01:55:01 2023 -0700 media: cx24120: Add retval check for cx24120_message_send() [ Upstream commit 96002c0ac824e1773d3f706b1f92e2a9f2988047 ] If cx24120_message_send() returns error, we should keep local struct unchanged. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5afc9a25be8d ("[media] Add support for TechniSat Skystar S2") Signed-off-by: Daniil Dulov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniil Dulov <[email protected]> Date: Fri Mar 24 06:38:32 2023 -0700 media: dib7000p: Fix potential division by zero [ Upstream commit a1db7b2c5533fc67e2681eb5efc921a67bc7d5b8 ] Variable loopdiv can be assigned 0, then it is used as a denominator, without checking it for 0. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 713d54a8bd81 ("[media] DiB7090: add support for the dib7090 based") Signed-off-by: Daniil Dulov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> [hverkuil: (bw != NULL) -> bw] Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Mon May 29 07:58:36 2023 +0200 media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer() [ Upstream commit ea9ef6c2e001c5dc94bee35ebd1c8a98621cf7b8 ] 'read' is freed when it is known to be NULL, but not when a read error occurs. Revert the logic to avoid a small leak, should a m920x_read() call fail. Fixes: a2ab06d7c4d6 ("media: m920x: don't use stack on USB reads") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Fri Sep 8 10:20:36 2023 +0100 media: dvb: symbol fixup for dvb_attach() commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream. In commit 9011e49d54dc ("modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules") the use of symbol_get is properly restricted to GPL-only marked symbols. This interacts oddly with the DVB logic which only uses dvb_attach() to load the dvb driver which then uses symbol_get(). Fix this up by properly marking all of the dvb_attach attach symbols as EXPORT_SYMBOL_GPL(). Fixes: 9011e49d54dc ("modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules") Cc: stable <[email protected]> Reported-by: Stefan Lippers-Hollmann <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Luis Chamberlain <[email protected]> Acked-by: Hans Verkuil <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Colin Ian King <[email protected]> Date: Thu Jul 27 19:40:07 2023 +0200 media: go7007: Remove redundant if statement [ Upstream commit f33cb49081da0ec5af0888f8ecbd566bd326eed1 ] The if statement that compares msgs[i].len != 3 is always false because it is in a code block where msg[i].len is equal to 3. The check is redundant and can be removed. As detected by cppcheck static analysis: drivers/media/usb/go7007/go7007-i2c.c:168:20: warning: Opposite inner 'if' condition leads to a dead code block. [oppositeInnerCondition] Link: https://lore.kernel.org/linux-media/[email protected] Fixes: 866b8695d67e ("Staging: add the go7007 video driver") Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sakari Ailus <[email protected]> Date: Sat Jul 29 20:59:25 2023 +0200 media: i2c: ccs: Check rules is non-NULL commit 607bcc4213d998d051541d8f10b5bbb7d546c0be upstream. Fix the following smatch warning: drivers/media/i2c/ccs/ccs-data.c:524 ccs_data_parse_rules() warn: address of NULL pointer 'rules' The CCS static data rule parser does not check an if rule has been obtained before checking for other rule types (which depend on the if rule). In practice this means parsing invalid CCS static data could lead to dereferencing a NULL pointer. Reported-by: Hans Verkuil <[email protected]> Fixes: a6b396f410b1 ("media: ccs: Add CCS static data parser library") Cc: [email protected] # for 5.11 and up Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Stevenson <[email protected]> Date: Mon Dec 5 15:21:45 2022 +0000 media: i2c: ov2680: Set V4L2_CTRL_FLAG_MODIFY_LAYOUT on flips [ Upstream commit 66274280b2c745d380508dc27b9a4dfd736e5eda ] The driver changes the Bayer order based on the flips, but does not define the control correctly with the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag. Add the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag. Signed-off-by: Dave Stevenson <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Stable-dep-of: 7b5a42e6ae71 ("media: ov2680: Remove auto-gain and auto-exposure controls") Signed-off-by: Sasha Levin <[email protected]>
Author: Jacopo Mondi <[email protected]> Date: Thu Aug 10 15:33:37 2023 +0200 media: i2c: rdacm21: Fix uninitialized value [ Upstream commit 33c7ae8f49e3413c81e879e1fdfcea4c5516e37b ] Fix the following smatch warning: drivers/media/i2c/rdacm21.c:373 ov10640_check_id() error: uninitialized symbol 'val'. Initialize 'val' to 0 in the ov10640_check_id() function. Fixes: 2b821698dc73 ("media: i2c: rdacm21: Power up OV10640 before OV490") Reported-by: Hans Verkuil <[email protected]> Signed-off-by: Jacopo Mondi <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Thu Jun 15 12:30:30 2023 +0200 media: i2c: tvp5150: check return value of devm_kasprintf() [ Upstream commit 26ce7054d804be73935b9268d6e0ecf2fbbc8aef ] devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 0556f1d580d4 ("media: tvp5150: add input source selection of_graph support") Signed-off-by: Claudiu Beznea <[email protected]> Reviewed-by: Marco Felsch <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Irui Wang <[email protected]> Date: Wed Jul 5 17:14:41 2023 +0800 media: mediatek: vcodec: Return NULL if no vdec_fb is found [ Upstream commit dfa2d6e07432270330ae191f50a0e70636a4cd2b ] "fb_use_list" is used to store used or referenced frame buffers for vp9 stateful decoder. "NULL" should be returned when getting target frame buffer failed from "fb_use_list", not a random unexpected one. Fixes: f77e89854b3e ("[media] vcodec: mediatek: Add Mediatek VP9 Video Decoder Driver") Signed-off-by: Irui Wang <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:21 2023 +0200 media: ov2680: Add ov2680_fill_format() helper function [ Upstream commit 6d6849b2203f3244b575ba01d3e41ee19aa2cadf ] Add a ov2680_fill_format() helper function and use this everywhere were a v4l2_mbus_framefmt struct needs to be filled in so that the driver always fills it consistently. This is a preparation patch for fixing ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in the passed in v4l2_mbus_framefmt struct. Note that for ov2680_init_cfg() this now simply always fills the try_fmt struct of the passed in sd_state. This is correct because ov2680_init_cfg() is never called with a NULL sd_state so the old sd_state check is not necessary. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by: Rui Miguel Silva <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:20 2023 +0200 media: ov2680: Don't take the lock for try_fmt calls [ Upstream commit e521b9cc1a49de677f4fc65909ce4877fbf7b113 ] On ov2680_set_fmt() calls with format->which == V4L2_SUBDEV_FORMAT_TRY, ov2680_set_fmt() does not talk to the sensor. So in this case there is no need to lock the sensor->lock mutex or to check that the sensor is streaming. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by: Rui Miguel Silva <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:17 2023 +0200 media: ov2680: Fix ov2680_bayer_order() [ Upstream commit 50a7bad4e0a37d7018ab6fe843dd84bc6b2ecf72 ] The index into ov2680_hv_flip_bayer_order[] should be 0-3, but ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as max index, while the intention was to use: 0 + 1 + 2 as max index. Fix the index calculation in ov2680_bayer_order(), while at it also just use the ctrl values rather then reading them back using a slow i2c-read transaction. This also allows making the function void, since there now are no more i2c-reads to error check. Note the check for the ctrls being NULL is there to allow adding an ov2680_fill_format() helper later, which will call ov2680_set_bayer_order() during probe() before the ctrls are created. [Sakari Ailus: Change all users of ov2680_set_bayer_order() here] Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:22 2023 +0200 media: ov2680: Fix ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY not working [ Upstream commit c0e97a4b4f20639f74cd5809b42ba6cbf9736a7d ] ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY was getting the try_fmt v4l2_mbus_framefmt struct from the passed in sd_state and then storing the contents of that into the return by reference format->format struct. While the right thing to do would be filling format->format based on the just looked up mode and then store the results of that in sd_state->pads[0].try_fmt . Before the previous change introducing ov2680_fill_format() this resulted in ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY always returning the zero-ed out sd_state->pads[0].try_fmt in format->format breaking callers using this. After the introduction of ov2680_fill_format() which at least initializes sd_state->pads[0].try_fmt properly, format->format is now always being filled with the default 800x600 mode set by ov2680_init_cfg() independent of the actual requested mode. Move the filling of format->format with ov2680_fill_format() to before the if (which == V4L2_SUBDEV_FORMAT_TRY) and then store the filled in format->format in sd_state->pads[0].try_fmt to fix this. Note this removes the fmt local variable because IMHO having a local variable which points to a sub-struct of one of the function arguments just leads to confusion when reading the code. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Acked-by: Rui Miguel Silva <[email protected]> Reviewed-by: Daniel Scally <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:23 2023 +0200 media: ov2680: Fix regulators being left enabled on ov2680_power_on() errors [ Upstream commit 84b4bd7e0d98166aa32fd470e672721190492eae ] When the ov2680_power_on() "sensor soft reset failed" path is hit during probe() the WARN() about putting an enabled regulator at drivers/regulator/core.c:2398 triggers 3 times (once for each regulator), filling dmesg with backtraces. Fix this by properly disabling the regulators on ov2680_power_on() errors. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:18 2023 +0200 media: ov2680: Fix vflip / hflip set functions [ Upstream commit d5d08ad330c9ccebc5e066fda815423a290f48b0 ] ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of 0 as value to ov2680_mod_reg(). While fixing this also: 1. Stop having separate enable/disable functions for hflip / vflip 2. Move the is_streaming check, which is unique to hflip / vflip into the ov2680_set_?flip() functions. for a nice code cleanup. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:16 2023 +0200 media: ov2680: Remove auto-gain and auto-exposure controls [ Upstream commit 7b5a42e6ae71927359ea67a2c22570ba97fa4059 ] Quoting the OV2680 datasheet: "3.2 exposure and gain control In the OV2680, the exposure time and gain are set manually from an external controller. The OV2680 supports manual gain and exposure control only for normal applications, no auto mode." And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that auto-exposure and auto-gain do not work. Note that the code setting the auto-exposure flag was broken, callers of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as "bool auto_exp" value, but ctrls->auto_exp is a menu control with: enum v4l2_exposure_auto_type { V4L2_EXPOSURE_AUTO = 0, V4L2_EXPOSURE_MANUAL = 1, ... So instead of passing !!ctrls->auto_exp->val they should have been passing ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was inverted of what it should have been. Also remove ov2680_g_volatile_ctrl() since without auto support the gain and exposure controls are not volatile. This also fixes the control values not being properly applied in ov2680_mode_set(). The 800x600 mode register-list also sets gain, exposure and vflip overriding the last set ctrl values. ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set() but did this before writing the mode register-list, so these values would still be overridden by the mode register-list. Add a v4l2_ctrl_handler_setup() call after writing the mode register-list to restore all ctrl values. Also remove the ctrls->gain->is_new check from ov2680_gain_set() so that the gain always gets restored properly. Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since ov2680_mode_restore() calls ov2680_mode_set(). Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Thu Aug 3 11:33:19 2023 +0200 media: ov2680: Remove VIDEO_V4L2_SUBDEV_API ifdef-s [ Upstream commit 49c282d5a8c5f4d1d9088622bec792294c716010 ] VIDEO_V4L2_SUBDEV_API is now automatically selected in Kconfig for all sensor drivers. Remove the ifdef CONFIG_VIDEO_V4L2_SUBDEV_API checks. This is a preparation patch for fixing ov2680_set_fmt() which == V4L2_SUBDEV_FORMAT_TRY calls not properly filling in the passed in v4l2_mbus_framefmt struct. Fixes: 3ee47cad3e69 ("media: ov2680: Add Omnivision OV2680 sensor driver") Reviewed-by: Daniel Scally <[email protected]> Acked-by: Rui Miguel Silva <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Marek Vasut <[email protected]> Date: Wed Aug 2 16:47:25 2023 +0200 media: ov5640: Enable MIPI interface in ov5640_set_power_mipi() [ Upstream commit 98cb72d3b9c5e03b10fa993752ecfcbd9c572d8c ] Set OV5640_REG_IO_MIPI_CTRL00 bit 2 to 1 instead of 0, since 1 means MIPI CSI2 interface, while 0 means CPI parallel interface. In the ov5640_set_power_mipi() the interface should obviously be set to MIPI CSI2 since this functions is used to power up the sensor when operated in MIPI CSI2 mode. The sensor should not be in CPI mode in that case. This fixes a corner case where capturing the first frame on i.MX8MN with CSI/ISI resulted in corrupted frame. Fixes: aa4bb8b8838f ("media: ov5640: Re-work MIPI startup sequence") Reviewed-by: Jacopo Mondi <[email protected]> Tested-by: Jacopo Mondi <[email protected]> # [Test on imx6q] Signed-off-by: Marek Vasut <[email protected]> Tested-by: Jai Luthra <[email protected]> # [Test on bplay, sk-am62] Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nikolay Burykin <[email protected]> Date: Tue Jan 10 10:09:00 2023 +0100 media: pci: cx23885: fix error handling for cx23885 ATSC boards [ Upstream commit 4aaa96b59df5fac41ba891969df6b092061ea9d7 ] After having been assigned to NULL value at cx23885-dvb.c:1202, pointer '0' is dereferenced at cx23885-dvb.c:2469. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Nikolay Burykin <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Tue Jun 6 06:38:15 2023 +0200 media: pulse8-cec: handle possible ping error [ Upstream commit 92cbf865ea2e0f2997ff97815c6db182eb23df1b ] Handle (and warn about) possible error waiting for MSGCODE_PING result. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Benjamin Gaignard <[email protected]> Date: Mon Jul 17 17:06:11 2023 +0200 media: rkvdec: increase max supported height for H.264 [ Upstream commit f000e6ca2d60fefd02a180a57df2c4162fa0c1b7 ] After testing it is possible for the hardware to decode H264 bistream with a height up to 2560. Signed-off-by: Benjamin Gaignard <[email protected]> Fixes: cd33c830448ba ("media: rkvdec: Add the rkvdec driver") Reviewed-by: Nicolas Dufresne <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe JAILLET <[email protected]> Date: Wed Jun 14 20:31:05 2023 +0200 media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link() [ Upstream commit d7b13edd4cb4bfa335b6008ab867ac28582d3e5c ] If fwnode_graph_get_remote_endpoint() fails, 'fwnode' is known to be NULL, so fwnode_handle_put() is a no-op. Release the reference taken from a previous fwnode_graph_get_port_parent() call instead. Also handle fwnode_graph_get_port_parent() failures. In order to fix these issues, add an error handling path to the function and the needed gotos. Fixes: ca50c197bd96 ("[media] v4l: fwnode: Support generic fwnode for parsing standardised properties") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Sakari Ailus <[email protected]> Signed-off-by: Mauro Carvalho Chehab <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue May 30 14:30:35 2023 +0200 media: venus: hfi_venus: Only consider sys_idle_indicator on V1 [ Upstream commit 6283e4834c69fa93a108efa18c6aa09c7e626f49 ] As per information from Qualcomm [1], this property is not really supported beyond msm8916 (HFI V1) and some newer HFI versions really dislike receiving it, going as far as crashing the device. Only consider toggling it (via the module option) on HFIV1. While at it, get rid of the global static variable (which defaulted to zero) which was never explicitly assigned to for V1. Note: [1] is a reply to the actual message in question, as lore did not properly receive some of the emails.. [1] https://lore.kernel.org/lkml/[email protected]/ Fixes: 7ed9e0b3393c ("media: venus: hfi, vdec: v6 Add IS_V6() to existing IS_V4() if locations") Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konrad Dybcio <[email protected]> Date: Tue May 30 14:30:36 2023 +0200 media: venus: hfi_venus: Write to VIDC_CTRL_INIT after unmasking interrupts commit d74e481609808330b4625b3691cf01e1f56e255e upstream. The startup procedure shouldn't be started with interrupts masked, as that may entail silent failures. Kick off initialization only after the interrupts are unmasked. Cc: [email protected] # v4.12+ Fixes: d96d3f30c0f2 ("[media] media: venus: hfi: add Venus HFI files") Signed-off-by: Konrad Dybcio <[email protected]> Signed-off-by: Stanimir Varbanov <[email protected]> Signed-off-by: Hans Verkuil <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maciej W. Rozycki <[email protected]> Date: Tue Jul 18 15:37:18 2023 +0100 MIPS: Fix CONFIG_CPU_DADDI_WORKAROUNDS `modules_install' regression commit a79a404e6c2241ebc528b9ebf4c0832457b498c3 upstream. Remove a build-time check for the presence of the GCC `-msym32' option. This option has been there since GCC 4.1.0, which is below the minimum required as at commit 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler is needed"), when an error message: arch/mips/Makefile:306: *** CONFIG_CPU_DADDI_WORKAROUNDS unsupported without -msym32. Stop. started to trigger for the `modules_install' target with configurations such as `decstation_64_defconfig' that set CONFIG_CPU_DADDI_WORKAROUNDS, because said commit has made `cc-option-yn' an undefined function for non-build targets. Reported-by: Jan-Benedict Glaw <[email protected]> Signed-off-by: Maciej W. Rozycki <[email protected]> Fixes: 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler is needed") Cc: [email protected] # v5.13+ Reviewed-by: Philippe Mathieu-Daudé <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Maciej W. Rozycki <[email protected]> Date: Tue Jul 18 15:37:23 2023 +0100 MIPS: Only fiddle with CHECKFLAGS if `need-compiler' commit 4fe4a6374c4db9ae2b849b61e84b58685dca565a upstream. We have originally guarded fiddling with CHECKFLAGS in our arch Makefile by checking for the CONFIG_MIPS variable, not set for targets such as `distclean', etc. that neither include `.config' nor use the compiler. Starting from commit 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler is needed") we have had a generic `need-compiler' variable explicitly telling us if the compiler will be used and thus its capabilities need to be checked and expressed in the form of compilation flags. If this variable is not set, then `make' functions such as `cc-option' are undefined, causing all kinds of weirdness to happen if we expect specific results to be returned, most recently: cc1: error: '-mloongson-mmi' must be used with '-mhard-float' messages with configurations such as `fuloong2e_defconfig' and the `modules_install' target, which does include `.config' and yet does not use the compiler. Replace the check for CONFIG_MIPS with one for `need-compiler' instead, so as to prevent the compiler from being ever called for CHECKFLAGS when not needed. Reported-by: Guillaume Tucker <[email protected]> Closes: https://lore.kernel.org/r/[email protected]/ Signed-off-by: Maciej W. Rozycki <[email protected]> Fixes: 805b2e1d427a ("kbuild: include Makefile.compiler only when compiler is needed") Cc: [email protected] # v5.13+ Reported-by: "kernelci.org bot" <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vadim Pasternak <[email protected]> Date: Thu Aug 24 15:43:08 2023 +0200 mlxsw: i2c: Fix chunk size setting in output mailbox buffer [ Upstream commit 146c7c330507c0384bf29d567186632bfe975927 ] The driver reads commands output from the output mailbox. If the size of the output mailbox is not a multiple of the transaction / block size, then the driver will not issue enough read transactions to read the entire output, which can result in driver initialization errors. Fix by determining the number of transactions using DIV_ROUND_UP(). Fixes: 3029a693beda ("mlxsw: i2c: Allow flexible setting of I2C transactions size") Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vadim Pasternak <[email protected]> Date: Thu Aug 24 15:43:09 2023 +0200 mlxsw: i2c: Limit single transaction buffer size [ Upstream commit d7248f1cc835bd80e936dc5b2d94b149bdd0077d ] Maximum size of buffer is obtained from underlying I2C adapter and in case adapter allows I2C transaction buffer size greater than 100 bytes, transaction will fail due to firmware limitation. As a result driver will fail initialization. Limit the maximum size of transaction buffer by 100 bytes to fit to firmware. Remove unnecessary calculation: max_t(u16, MLXSW_I2C_BLK_DEF, quirk_size). This condition can not happened. Fixes: 3029a693beda ("mlxsw: i2c: Allow flexible setting of I2C transactions size") Signed-off-by: Vadim Pasternak <[email protected]> Reviewed-by: Petr Machata <[email protected]> Signed-off-by: Petr Machata <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Joel Fernandes (Google) <[email protected]> Date: Mon Sep 4 18:08:04 2023 +0000 mm/vmalloc: add a safer version of find_vm_area() for debug commit 0818e739b5c061b0251c30152380600fb9b84c0c upstream. It is unsafe to dump vmalloc area information when trying to do so from some contexts. Add a safer trylock version of the same function to do a best-effort VMA finding and use it from vmalloc_dump_obj(). [applied test robot feedback on unused function fix.] [applied Uladzislau feedback on locking.] Link: https://lkml.kernel.org/r/[email protected] Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory") Signed-off-by: Joel Fernandes (Google) <[email protected]> Reviewed-by: Uladzislau Rezki (Sony) <[email protected]> Reported-by: Zhen Lei <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Zqiang <[email protected]> Cc: <[email protected]> Cc: Matthew Wilcox (Oracle) <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wolfram Sang <[email protected]> Date: Wed Jul 12 16:00:11 2023 +0200 mmc: renesas_sdhi: register irqs before registering controller commit 74f45de394d979cc7770271f92fafa53e1ed3119 upstream. IRQs should be ready to serve when we call mmc_add_host() via tmio_mmc_host_probe(). To achieve that, ensure that all irqs are masked before registering the handlers. Signed-off-by: Wolfram Sang <[email protected]> Tested-by: Biju Das <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Zhang <[email protected]> Date: Thu Jul 6 11:29:07 2023 -0700 mtd: rawnand: brcmnand: Fix crash during the panic_write commit e66dd317194daae0475fe9e5577c80aa97f16cb9 upstream. When executing a NAND command within the panic write path, wait for any pending command instead of calling BUG_ON to avoid crashing while already crashing. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: William Zhang <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Reviewed-by: Kursad Oney <[email protected]> Reviewed-by: Kamal Dasu <[email protected]> Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Zhang <[email protected]> Date: Thu Jul 6 11:29:09 2023 -0700 mtd: rawnand: brcmnand: Fix mtd oobsize [ Upstream commit 60177390fa061c62d156f4a546e3efd90df3c183 ] brcmnand controller can only access the flash spare area up to certain bytes based on the ECC level. It can be less than the actual flash spare area size. For example, for many NAND chip supporting ECC BCH-8, it has 226 bytes spare area. But controller can only uses 218 bytes. So brcmand driver overrides the mtd oobsize with the controller's accessible spare area size. When the nand base driver utilizes the nand_device object, it resets the oobsize back to the actual flash spare aprea size from nand_memory_organization structure and controller may not able to access all the oob area as mtd advises. This change fixes the issue by overriding the oobsize in the nand_memory_organization structure to the controller's accessible spare area size. Fixes: a7ab085d7c16 ("mtd: rawnand: Initialize the nand_device object") Signed-off-by: William Zhang <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: William Zhang <[email protected]> Date: Thu Jul 6 11:29:06 2023 -0700 mtd: rawnand: brcmnand: Fix potential false time out warning commit 9cc0a598b944816f2968baf2631757f22721b996 upstream. If system is busy during the command status polling function, the driver may not get the chance to poll the status register till the end of time out and return the premature status. Do a final check after time out happens to ensure reading the correct status. Fixes: 9d2ee0a60b8b ("mtd: nand: brcmnand: Check flash #WP pin status before nand erase/program") Signed-off-by: William Zhang <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: William Zhang <[email protected]> Date: Thu Jul 6 11:29:08 2023 -0700 mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write commit 5d53244186c9ac58cb88d76a0958ca55b83a15cd upstream. When the oob buffer length is not in multiple of words, the oob write function does out-of-bounds read on the oob source buffer at the last iteration. Fix that by always checking length limit on the oob buffer read and fill with 0xff when reaching the end of the buffer to the oob registers. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: William Zhang <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Cc: [email protected] Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Yi Yang <[email protected]> Date: Thu Aug 17 19:58:39 2023 +0800 mtd: rawnand: fsmc: handle clk prepare error in fsmc_nand_resume() [ Upstream commit a5a88125d00612586e941ae13e7fcf36ba8f18a7 ] In fsmc_nand_resume(), the return value of clk_prepare_enable() should be checked since it might fail. Fixes: e25da1c07dfb ("mtd: fsmc_nand: Add clk_{un}prepare() support") Signed-off-by: Yi Yang <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hsin-Yi Wang <[email protected]> Date: Fri Aug 18 14:42:23 2023 +0800 mtd: spi-nor: Check bus width while setting QE bit [ Upstream commit f01d8155a92e33cdaa85d20bfbe6c441907b3c1f ] spi_nor_write_16bit_sr_and_check() should also check if bus width is 4 before setting QE bit. Fixes: 39d1e3340c73 ("mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()") Suggested-by: Michael Walle <[email protected]> Suggested-by: Tudor Ambarus <[email protected]> Signed-off-by: Hsin-Yi Wang <[email protected]> Reviewed-by: Michael Walle <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Tudor Ambarus <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Abel Wu <[email protected]> Date: Mon Aug 14 15:09:11 2023 +0800 net-memcg: Fix scope of sockmem pressure indicators [ Upstream commit ac8a52962164a50e693fa021d3564d7745b83a7f ] Now there are two indicators of socket memory pressure sit inside struct mem_cgroup, socket_pressure and tcpmem_pressure, indicating memory reclaim pressure in memcg->memory and ->tcpmem respectively. When in legacy mode (cgroupv1), the socket memory is charged into ->tcpmem which is independent of ->memory, so socket_pressure has nothing to do with socket's pressure at all. Things could be worse by taking socket_pressure into consideration in legacy mode, as a pressure in ->memory can lead to premature reclamation/throttling in socket. While for the default mode (cgroupv2), the socket memory is charged into ->memory, and ->tcpmem/->tcpmem_pressure are simply not used. So {socket,tcpmem}_pressure are only used in default/legacy mode respectively for indicating socket memory pressure. This patch fixes the pieces of code that make mixed use of both. Fixes: 8e8ae645249b ("mm: memcontrol: hook up vmpressure to socket pressure") Signed-off-by: Abel Wu <[email protected]> Acked-by: Shakeel Butt <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quan Tian <[email protected]> Date: Tue Sep 5 10:36:10 2023 +0000 net/ipv6: SKB symmetric hash should incorporate transport ports commit a5e2151ff9d5852d0ababbbcaeebd9646af9c8d9 upstream. __skb_get_hash_symmetric() was added to compute a symmetric hash over the protocol, addresses and transport ports, by commit eb70db875671 ("packet: Use symmetric hash for PACKET_FANOUT_HASH."). It uses flow_keys_dissector_symmetric_keys as the flow_dissector to incorporate IPv4 addresses, IPv6 addresses and ports. However, it should not specify the flag as FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL, which stops further dissection when an IPv6 flow label is encountered, making transport ports not being incorporated in such case. As a consequence, the symmetric hash is based on 5-tuple for IPv4 but 3-tuple for IPv6 when flow label is present. It caused a few problems, e.g. when nft symhash and openvswitch l4_sym rely on the symmetric hash to perform load balancing as different L4 flows between two given IPv6 addresses would always get the same symmetric hash, leading to uneven traffic distribution. Removing the use of FLOW_DISSECTOR_F_STOP_AT_FLOW_LABEL makes sure the symmetric hash is based on 5-tuple for both IPv4 and IPv6 consistently. Fixes: eb70db875671 ("packet: Use symmetric hash for PACKET_FANOUT_HASH.") Reported-by: Lars Ekman <[email protected]> Closes: https://github.com/antrea-io/antrea/issues/5457 Signed-off-by: Quan Tian <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Saeed Mahameed <[email protected]> Date: Thu Jun 8 12:00:54 2023 -0700 net/mlx5: Free IRQ rmap and notifier on kernel shutdown commit 314ded538e5f22e7610b1bf621402024a180ec80 upstream. The kernel IRQ system needs the irq affinity notifier to be clear before attempting to free the irq, see WARN_ON log below. On a normal driver unload we don't have this issue since we do the complete cleanup of the irq resources. To fix this, put the important resources cleanup in a helper function and use it in both normal driver unload and shutdown flows. [ 4497.498434] ------------[ cut here ]------------ [ 4497.498726] WARNING: CPU: 0 PID: 9 at kernel/irq/manage.c:2034 free_irq+0x295/0x340 [ 4497.499193] Modules linked in: [ 4497.499386] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.4.0-rc4+ #10 [ 4497.499876] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-1.fc38 04/01/2014 [ 4497.500518] Workqueue: events do_poweroff [ 4497.500849] RIP: 0010:free_irq+0x295/0x340 [ 4497.501132] Code: 85 c0 0f 84 1d ff ff ff 48 89 ef ff d0 0f 1f 00 e9 10 ff ff ff 0f 0b e9 72 ff ff ff 49 8d 7f 28 ff d0 0f 1f 00 e9 df fd ff ff <0f> 0b 48 c7 80 c0 008 [ 4497.502269] RSP: 0018:ffffc90000053da0 EFLAGS: 00010282 [ 4497.502589] RAX: ffff888100949600 RBX: ffff88810330b948 RCX: 0000000000000000 [ 4497.503035] RDX: ffff888100949600 RSI: ffff888100400490 RDI: 0000000000000023 [ 4497.503472] RBP: ffff88810330c7e0 R08: ffff8881004005d0 R09: ffffffff8273a260 [ 4497.503923] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8881009ae000 [ 4497.504359] R13: ffff8881009ae148 R14: 0000000000000000 R15: ffff888100949600 [ 4497.504804] FS: 0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 [ 4497.505302] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4497.505671] CR2: 00007fce98806298 CR3: 000000000262e005 CR4: 0000000000370ef0 [ 4497.506104] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4497.506540] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4497.507002] Call Trace: [ 4497.507158] <TASK> [ 4497.507299] ? free_irq+0x295/0x340 [ 4497.507522] ? __warn+0x7c/0x130 [ 4497.507740] ? free_irq+0x295/0x340 [ 4497.507963] ? report_bug+0x171/0x1a0 [ 4497.508197] ? handle_bug+0x3c/0x70 [ 4497.508417] ? exc_invalid_op+0x17/0x70 [ 4497.508662] ? asm_exc_invalid_op+0x1a/0x20 [ 4497.508926] ? free_irq+0x295/0x340 [ 4497.509146] mlx5_irq_pool_free_irqs+0x48/0x90 [ 4497.509421] mlx5_irq_table_free_irqs+0x38/0x50 [ 4497.509714] mlx5_core_eq_free_irqs+0x27/0x40 [ 4497.509984] shutdown+0x7b/0x100 [ 4497.510184] pci_device_shutdown+0x30/0x60 [ 4497.510440] device_shutdown+0x14d/0x240 [ 4497.510698] kernel_power_off+0x30/0x70 [ 4497.510938] process_one_work+0x1e6/0x3e0 [ 4497.511183] worker_thread+0x49/0x3b0 [ 4497.511407] ? __pfx_worker_thread+0x10/0x10 [ 4497.511679] kthread+0xe0/0x110 [ 4497.511879] ? __pfx_kthread+0x10/0x10 [ 4497.512114] ret_from_fork+0x29/0x50 [ 4497.512342] </TASK> Fixes: 9c2d08010963 ("net/mlx5: Free irqs only on shutdown callback") Signed-off-by: Saeed Mahameed <[email protected]> Reviewed-by: Shay Drory <[email protected]> Signed-off-by: Mathieu Tortuyaux <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:59 2023 +0300 net/mlx5: Use RMW accessors for changing LNKCTL [ Upstream commit 30de872537bda526664d7a20b646adfb3e7ce6e6 ] Don't assume that only the driver would be accessing LNKCTL of the upstream bridge. ASPM policy changes can trigger write to LNKCTL outside of driver's control. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <[email protected]> Fixes: eabe8e5e88f5 ("net/mlx5: Handle sync reset now event") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Moshe Shemesh <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Aug 29 12:35:41 2023 +0000 net/sched: fq_pie: avoid stalls in fq_pie_timer() [ Upstream commit 8c21ab1bae945686c602c5bfa4e3f3352c2452c5 ] When setting a high number of flows (limit being 65536), fq_pie_timer() is currently using too much time as syzbot reported. Add logic to yield the cpu every 2048 flows (less than 150 usec on debug kernels). It should also help by not blocking qdisc fast paths for too long. Worst case (65536 flows) would need 31 jiffies for a complete scan. Relevant extract from syzbot report: rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/. rcu: blocking rcu_node structures (internal RCU debug): Sending NMI from CPU 1 to CPUs 0: NMI backtrace for cpu 0 CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline] RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236 Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 <a9> 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8b RSP: 0018:ffffc90000007bb8 EFLAGS: 00000206 RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0 RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <NMI> </NMI> <IRQ> pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700 Fixes: ec97ecf1ebe4 ("net: sched: add Flow Queue PIE packet scheduler") Link: https://lore.kernel.org/lkml/[email protected]/ Reported-by: [email protected] Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Michal Kubiak <[email protected]> Reviewed-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Budimir Markovic <[email protected]> Date: Thu Aug 24 01:49:05 2023 -0700 net/sched: sch_hfsc: Ensure inner classes have fsc curve [ Upstream commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f ] HFSC assumes that inner classes have an fsc curve, but it is currently possible for classes without an fsc curve to become parents. This leads to bugs including a use-after-free. Don't allow non-root classes without HFSC_FSC to become parents. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Budimir Markovic <[email protected]> Signed-off-by: Budimir Markovic <[email protected]> Acked-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Guangguan Wang <[email protected]> Date: Fri Sep 8 11:31:43 2023 +0800 net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add [ Upstream commit f5146e3ef0a9eea405874b36178c19a4863b8989 ] While doing smcr_port_add, there maybe linkgroup add into or delete from smc_lgr_list.list at the same time, which may result kernel crash. So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_add. The crash calltrace show below: BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: G Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014 Workqueue: events smc_ib_port_event_work [smc] RIP: 0010:smcr_port_add+0xa6/0xf0 [smc] RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297 RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000 RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918 R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4 R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08 FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0 PKRU: 55555554 Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30 Fixes: 1f90a05d9ff9 ("net/smc: add smcr_port_add() and smcr_link_up() processing") Signed-off-by: Guangguan Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liu Jian <[email protected]> Date: Sat Sep 9 16:14:34 2023 +0800 net/tls: do not free tls_rec on async operation in bpf_exec_tx_verdict() [ Upstream commit cfaa80c91f6f99b9342b6557f0f0e1143e434066 ] I got the below warning when do fuzzing test: BUG: KASAN: null-ptr-deref in scatterwalk_copychunks+0x320/0x470 Read of size 4 at addr 0000000000000008 by task kworker/u8:1/9 CPU: 0 PID: 9 Comm: kworker/u8:1 Tainted: G OE Hardware name: linux,dummy-virt (DT) Workqueue: pencrypt_parallel padata_parallel_worker Call trace: dump_backtrace+0x0/0x420 show_stack+0x34/0x44 dump_stack+0x1d0/0x248 __kasan_report+0x138/0x140 kasan_report+0x44/0x6c __asan_load4+0x94/0xd0 scatterwalk_copychunks+0x320/0x470 skcipher_next_slow+0x14c/0x290 skcipher_walk_next+0x2fc/0x480 skcipher_walk_first+0x9c/0x110 skcipher_walk_aead_common+0x380/0x440 skcipher_walk_aead_encrypt+0x54/0x70 ccm_encrypt+0x13c/0x4d0 crypto_aead_encrypt+0x7c/0xfc pcrypt_aead_enc+0x28/0x84 padata_parallel_worker+0xd0/0x2dc process_one_work+0x49c/0xbdc worker_thread+0x124/0x880 kthread+0x210/0x260 ret_from_fork+0x10/0x18 This is because the value of rec_seq of tls_crypto_info configured by the user program is too large, for example, 0xffffffffffffff. In addition, TLS is asynchronously accelerated. When tls_do_encryption() returns -EINPROGRESS and sk->sk_err is set to EBADMSG due to rec_seq overflow, skmsg is released before the asynchronous encryption process ends. As a result, the UAF problem occurs during the asynchronous processing of the encryption module. If the operation is asynchronous and the encryption module returns EINPROGRESS, do not free the record information. Fixes: 635d93981786 ("net/tls: free record only on encryption error") Signed-off-by: Liu Jian <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jinjie Ruan <[email protected]> Date: Thu Aug 24 14:43:36 2023 +0800 net: arcnet: Do not call kfree_skb() under local_irq_disable() [ Upstream commit 786c96e92fb9e854cb8b0cb7399bb2fb28e15c4b ] It is not allowed to call kfree_skb() from hardware interrupt context or with hardware interrupts being disabled. So replace kfree_skb() with dev_kfree_skb_irq() under local_irq_disable(). Compile tested only. Fixes: 05fcd31cc472 ("arcnet: add err_skb package for package status feedback") Signed-off-by: Jinjie Ruan <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jordan Rife <[email protected]> Date: Mon Aug 21 16:45:23 2023 -0500 net: Avoid address overwrite in kernel_connect commit 0bdf399342c5acbd817c9098b6c7ed21f1974312 upstream. BPF programs that run on connect can rewrite the connect address. For the connect system call this isn't a problem, because a copy of the address is made when it is moved into kernel space. However, kernel_connect simply passes through the address it is given, so the caller may observe its address value unexpectedly change. A practical example where this is problematic is where NFS is combined with a system such as Cilium which implements BPF-based load balancing. A common pattern in software-defined storage systems is to have an NFS mount that connects to a persistent virtual IP which in turn maps to an ephemeral server IP. This is usually done to achieve high availability: if your server goes down you can quickly spin up a replacement and remap the virtual IP to that endpoint. With BPF-based load balancing, mounts will forget the virtual IP address when the address rewrite occurs because a pointer to the only copy of that address is passed down the stack. Server failover then breaks, because clients have forgotten the virtual IP address. Reconnects fail and mounts remain broken. This patch was tested by setting up a scenario like this and ensuring that NFS reconnects worked after applying the patch. Signed-off-by: Jordan Rife <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vladimir Oltean <[email protected]> Date: Wed Sep 6 00:53:38 2023 +0300 net: dsa: sja1105: complete tc-cbs offload support on SJA1110 [ Upstream commit 180a7419fe4adc8d9c8e0ef0fd17bcdd0cf78acd ] The blamed commit left this delta behind: struct sja1105_cbs_entry { - u64 port; - u64 prio; + u64 port; /* Not used for SJA1110 */ + u64 prio; /* Not used for SJA1110 */ u64 credit_hi; u64 credit_lo; u64 send_slope; u64 idle_slope; }; but did not actually implement tc-cbs offload fully for the new switch. The offload is accepted, but it doesn't work. The difference compared to earlier switch generations is that now, the table of CBS shapers is sparse, because there are many more shapers, so the mapping between a {port, prio} and a table index is static, rather than requiring us to store the port and prio into the sja1105_cbs_entry. So, the problem is that the code programs the CBS shaper parameters at a dynamic table index which is incorrect. All that needs to be done for SJA1110 CBS shapers to work is to bypass the logic which allocates shapers in a dense manner, as for SJA1105, and use the fixed mapping instead. Fixes: 3e77e59bf8cf ("net: dsa: sja1105: add support for the SJA1110 switch family") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Oltean <[email protected]> Date: Wed Sep 6 00:53:37 2023 +0300 net: dsa: sja1105: fix -ENOSPC when replacing the same tc-cbs too many times [ Upstream commit 894cafc5c62ccced758077bd4e970dc714c42637 ] After running command [2] too many times in a row: [1] $ tc qdisc add dev sw2p0 root handle 1: mqprio num_tc 8 \ map 0 1 2 3 4 5 6 7 queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 [2] $ tc qdisc replace dev sw2p0 parent 1:1 cbs offload 1 \ idleslope 120000 sendslope -880000 locredit -1320 hicredit 180 (aka more than priv->info->num_cbs_shapers times) we start seeing the following error message: Error: Specified device failed to setup cbs hardware offload. This comes from the fact that ndo_setup_tc(TC_SETUP_QDISC_CBS) presents the same API for the qdisc create and replace cases, and the sja1105 driver fails to distinguish between the 2. Thus, it always thinks that it must allocate the same shaper for a {port, queue} pair, when it may instead have to replace an existing one. Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Oltean <[email protected]> Date: Wed Sep 6 00:53:36 2023 +0300 net: dsa: sja1105: fix bandwidth discrepancy between tc-cbs software and offload [ Upstream commit 954ad9bf13c4f95a4958b5f8433301f2ab99e1f5 ] More careful measurement of the tc-cbs bandwidth shows that the stream bandwidth (effectively idleslope) increases, there is a larger and larger discrepancy between the rate limit obtained by the software Qdisc, and the rate limit obtained by its offloaded counterpart. The discrepancy becomes so large, that e.g. at an idleslope of 40000 (40Mbps), the offloaded cbs does not actually rate limit anything, and traffic will pass at line rate through a 100 Mbps port. The reason for the discrepancy is that the hardware documentation I've been following is incorrect. UM11040.pdf (for SJA1105P/Q/R/S) states about IDLE_SLOPE that it is "the rate (in unit of bytes/sec) at which the credit counter is increased". Cross-checking with UM10944.pdf (for SJA1105E/T) and UM11107.pdf (for SJA1110), the wording is different: "This field specifies the value, in bytes per second times link speed, by which the credit counter is increased". So there's an extra scaling for link speed that the driver is currently not accounting for, and apparently (empirically), that link speed is expressed in Kbps. I've pondered whether to pollute the sja1105_mac_link_up() implementation with CBS shaper reprogramming, but I don't think it is worth it. IMO, the UAPI exposed by tc-cbs requires user space to recalculate the sendslope anyway, since the formula for that depends on port_transmit_rate (see man tc-cbs), which is not an invariant from tc's perspective. So we use the offload->sendslope and offload->idleslope to deduce the original port_transmit_rate from the CBS formula, and use that value to scale the offload->sendslope and offload->idleslope to values that the hardware understands. Some numerical data points: 40Mbps stream, max interfering frame size 1500, port speed 100M --------------------------------------------------------------- tc-cbs parameters: idleslope 40000 sendslope -60000 locredit -900 hicredit 600 which result in hardware values: Before (doesn't work) After (works) credit_hi 600 600 credit_lo 900 900 send_slope 7500000 75 idle_slope 5000000 50 40Mbps stream, max interfering frame size 1500, port speed 1G ------------------------------------------------------------- tc-cbs parameters: idleslope 40000 sendslope -960000 locredit -1440 hicredit 60 which result in hardware values: Before (doesn't work) After (works) credit_hi 60 60 credit_lo 1440 1440 send_slope 120000000 120 idle_slope 5000000 5 5.12Mbps stream, max interfering frame size 1522, port speed 100M ----------------------------------------------------------------- tc-cbs parameters: idleslope 5120 sendslope -94880 locredit -1444 hicredit 77 which result in hardware values: Before (doesn't work) After (works) credit_hi 77 77 credit_lo 1444 1444 send_slope 11860000 118 idle_slope 640000 6 Tested on SJA1105T, SJA1105S and SJA1110A, at 1Gbps and 100Mbps. Fixes: 4d7525085a9b ("net: dsa: sja1105: offload the Credit-Based Shaper qdisc") Reported-by: Yanan Yang <[email protected]> Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Oltean <[email protected]> Date: Fri Sep 8 16:33:48 2023 +0300 net: dsa: sja1105: hide all multicast addresses from "bridge fdb show" [ Upstream commit 02c652f5465011126152bbd93b6a582a1d0c32f1 ] Commit 4d9423549501 ("net: dsa: sja1105: offload bridge port flags to device") has partially hidden some multicast entries from showing up in the "bridge fdb show" output, but it wasn't enough. Addresses which are added through "bridge mdb add" still show up. Hide them all. Fixes: 291d1e72b756 ("net: dsa: sja1105: Add support for FDB and MDB management") Signed-off-by: Vladimir Oltean <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangyu Hua <[email protected]> Date: Fri Sep 8 14:19:50 2023 +0800 net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all() [ Upstream commit e4c79810755f66c9a933ca810da2724133b1165a ] rule_locs is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rule_locs to avoid NULL pointer dereference. Fixes: 7aab747e5563 ("net: ethernet: mediatek: add ethtool functions to configure RX flows of HW LRO") Signed-off-by: Hangyu Hua <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hangyu Hua <[email protected]> Date: Fri Sep 8 14:19:49 2023 +0800 net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc() [ Upstream commit 51fe0a470543f345e3c62b6798929de3ddcedc1d ] rules is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rules to avoid OOB writing or NULL pointer dereference. Fixes: 90b509b39ac9 ("net: mvpp2: cls: Add Classification offload support") Signed-off-by: Hangyu Hua <[email protected]> Reviewed-by: Marcin Wojtas <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Wed Aug 30 13:00:37 2023 +0200 net: fib: avoid warn splat in flow dissector [ Upstream commit 8aae7625ff3f0bd5484d01f1b8d5af82e44bec2d ] New skbs allocated via nf_send_reset() have skb->dev == NULL. fib*_rules_early_flow_dissect helpers already have a 'struct net' argument but its not passed down to the flow dissector core, which will then WARN as it can't derive a net namespace to use: WARNING: CPU: 0 PID: 0 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0xa91/0x1cd0 [..] ip_route_me_harder+0x143/0x330 nf_send_reset+0x17c/0x2d0 [nf_reject_ipv4] nft_reject_inet_eval+0xa9/0xf2 [nft_reject_inet] nft_do_chain+0x198/0x5d0 [nf_tables] nft_do_chain_inet+0xa4/0x110 [nf_tables] nf_hook_slow+0x41/0xc0 ip_local_deliver+0xce/0x110 .. Cc: Stanislav Fomichev <[email protected]> Cc: David Ahern <[email protected]> Cc: Ido Schimmel <[email protected]> Fixes: 812fa71f0d96 ("netfilter: Dissect flow after packet mangling") Link: https://bugzilla.kernel.org/show_bug.cgi?id=217826 Signed-off-by: Florian Westphal <[email protected]> Reviewed-by: Ido Schimmel <[email protected]> Reviewed-by: David Ahern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nicolas Dichtel <[email protected]> Date: Wed Aug 23 15:41:02 2023 +0200 net: handle ARPHRD_PPP in dev_is_mac_header_xmit() commit a4f39c9f14a634e4cd35fcd338c239d11fcc73fc upstream. The goal is to support a bpf_redirect() from an ethernet device (ingress) to a ppp device (egress). The l2 header is added automatically by the ppp driver, thus the ethernet header should be removed. CC: [email protected] Fixes: 27b29f63058d ("bpf: add bpf_redirect() helper") Signed-off-by: Nicolas Dichtel <[email protected]> Tested-by: Siwar Zitouni <[email protected]> Reviewed-by: Guillaume Nault <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Hao Chen <[email protected]> Date: Wed Sep 6 15:20:14 2023 +0800 net: hns3: fix byte order conversion issue in hclge_dbg_fd_tcam_read() [ Upstream commit efccf655e99b6907ca07a466924e91805892e7d3 ] req1->tcam_data is defined as "u8 tcam_data[8]", and we convert it as (u32 *) without considerring byte order conversion, it may result in printing wrong data for tcam_data. Convert tcam_data to (__le32 *) first to fix it. Fixes: b5a0b70d77b9 ("net: hns3: refactor dump fd tcam of debugfs") Signed-off-by: Hao Chen <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hao Chen <[email protected]> Date: Wed Sep 6 15:20:15 2023 +0800 net: hns3: fix debugfs concurrency issue between kfree buffer and read [ Upstream commit c295160b1d95e885f1af4586a221cb221d232d10 ] Now in hns3_dbg_uninit(), there may be concurrency between kfree buffer and read, it may result in memory error. Moving debugfs_remove_recursive() in front of kfree buffer to ensure they don't happen at the same time. Fixes: 5e69ea7ee2a6 ("net: hns3: refactor the debugfs process") Signed-off-by: Hao Chen <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jijie Shao <[email protected]> Date: Wed Sep 6 15:20:16 2023 +0800 net: hns3: fix invalid mutex between tc qdisc and dcb ets command issue [ Upstream commit fa5564945f7d15ae2390b00c08b6abaef0165cda ] We hope that tc qdisc and dcb ets commands can not be used crosswise. If we want to use any of the commands to configure tc, We must use the other command to clear the existing configuration. However, when we configure a single tc with tc qdisc, we can still configure it with dcb ets. Because we use mqprio_active as the tag of tc qdisc configuration, but with dcb ets, we do not check mqprio_active. This patch fix this issue by check mqprio_active before executing the dcb ets command. and add dcb_ets_active to replace HCLGE_FLAG_DCB_ENABLE and HCLGE_FLAG_MQPRIO_ENABLE at the hclge layer, Fixes: cacde272dd00 ("net: hns3: Add hclge_dcb module for the support of DCB feature") Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yisen Zhuang <[email protected]> Date: Wed Sep 6 15:20:17 2023 +0800 net: hns3: fix the port information display when sfp is absent [ Upstream commit 674d9591a32d01df75d6b5fffed4ef942a294376 ] When sfp is absent or unidentified, the port type should be displayed as PORT_OTHERS, rather than PORT_FIBRE. Fixes: 88d10bd6f730 ("net: hns3: add support for multiple media type") Signed-off-by: Yisen Zhuang <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jie Wang <[email protected]> Date: Wed Sep 6 15:20:18 2023 +0800 net: hns3: remove GSO partial feature bit [ Upstream commit 60326634f6c54528778de18bfef1e8a7a93b3771 ] HNS3 NIC does not support GSO partial packets segmentation. Actually tunnel packets for example NvGRE packets segment offload and checksum offload is already supported. There is no need to keep gso partial feature bit. So this patch removes it. Fixes: 76ad4f0ee747 ("net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC") Signed-off-by: Jie Wang <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jian Shen <[email protected]> Date: Mon Aug 7 19:34:49 2023 +0800 net: hns3: restore user pause configure when disable autoneg [ Upstream commit 15159ec0c831b565820c2de05114ea1b4cf07681 ] Restore the mac pause state to user configuration when autoneg is disabled Signed-off-by: Jian Shen <[email protected]> Signed-off-by: Peiyang Wang <[email protected]> Signed-off-by: Jijie Shao <[email protected]> Reviewed-by: Leon Romanovsky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liu Jian <[email protected]> Date: Thu Sep 7 10:57:09 2023 +0800 net: ipv4: fix one memleak in __inet_del_ifa() [ Upstream commit ac28b1ec6135649b5d78b028e47264cb3ebca5ea ] I got the below warning when do fuzzing test: unregister_netdevice: waiting for bond0 to become free. Usage count = 2 It can be repoduced via: ip link add bond0 type bond sysctl -w net.ipv4.conf.bond0.promote_secondaries=1 ip addr add 4.117.174.103/0 scope 0x40 dev bond0 ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0 ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0 ip addr del 4.117.174.103/0 scope 0x40 dev bond0 ip link delete bond0 type bond In this reproduction test case, an incorrect 'last_prim' is found in __inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40) is lost. The memory of the secondary address is leaked and the reference of in_device and net_device is leaked. Fix this problem: Look for 'last_prim' starting at location of the deleted IP and inserting the promoted IP into the location of 'last_prim'. Fixes: 0ff60a45678e ("[IPV4]: Fix secondary IP addresses after promotion") Signed-off-by: Liu Jian <[email protected]> Signed-off-by: Julian Anastasov <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alex Henrie <[email protected]> Date: Thu Aug 31 22:41:27 2023 -0600 net: ipv6/addrconf: avoid integer underflow in ipv6_create_tempaddr [ Upstream commit f31867d0d9d82af757c1e0178b659438f4c1ea3c ] The existing code incorrectly casted a negative value (the result of a subtraction) to an unsigned value without checking. For example, if /proc/sys/net/ipv6/conf/*/temp_prefered_lft was set to 1, the preferred lifetime would jump to 4 billion seconds. On my machine and network the shortest lifetime that avoided underflow was 3 seconds. Fixes: 76506a986dc3 ("IPv6: fix DESYNC_FACTOR") Signed-off-by: Alex Henrie <[email protected]> Reviewed-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksij Rempel <[email protected]> Date: Fri Sep 1 06:53:23 2023 +0200 net: phy: micrel: Correct bit assignments for phy_device flags [ Upstream commit 719c5e37e99d2fd588d1c994284d17650a66354c ] Previously, the defines for phy_device flags in the Micrel driver were ambiguous in their representation. They were intended to be bit masks but were mistakenly defined as bit positions. This led to the following issues: - MICREL_KSZ8_P1_ERRATA, designated for KSZ88xx switches, overlapped with MICREL_PHY_FXEN and MICREL_PHY_50MHZ_CLK. - Due to this overlap, the code path for MICREL_PHY_FXEN, tailored for the KSZ8041 PHY, was not executed for KSZ88xx PHYs. - Similarly, the code associated with MICREL_PHY_50MHZ_CLK wasn't triggered for KSZ88xx. To rectify this, all three flags have now been explicitly converted to use the `BIT()` macro, ensuring they are defined as bit masks and preventing potential overlaps in the future. Fixes: 49011e0c1555 ("net: phy: micrel: ksz886x/ksz8081: add cabletest support") Signed-off-by: Oleksij Rempel <[email protected]> Reviewed-by: Russell King (Oracle) <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Aug 30 10:12:44 2023 +0000 net: read sk->sk_family once in sk_mc_loop() [ Upstream commit a3e0fdf71bbe031de845e8e08ed7fba49f9c702c ] syzbot is playing with IPV6_ADDRFORM quite a lot these days, and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop() We have many more similar issues to fix. WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260 Modules linked in: CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 Workqueue: events_power_efficient gc_worker RIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782 Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48 RSP: 0018:ffffc90000388530 EFLAGS: 00010246 RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980 RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011 RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65 R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000 R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000 FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> [<ffffffff8507734f>] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83 [<ffffffff85062766>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff85062766>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff85061f8c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff85061f8c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff852071cf>] dst_output include/net/dst.h:444 [inline] [<ffffffff852071cf>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff83618fb4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff83618fb4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff83618fb4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff83618fb4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff8361ddd9>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84763fc0>] netdev_start_xmit include/linux/netdevice.h:4925 [inline] [<ffffffff84763fc0>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84763fc0>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff8494c650>] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342 [<ffffffff8494d883>] qdisc_restart net/sched/sch_generic.c:407 [inline] [<ffffffff8494d883>] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415 [<ffffffff8478c426>] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [<ffffffff84796eac>] net_tx_action+0x7ac/0x940 net/core/dev.c:5247 [<ffffffff858002bd>] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599 [<ffffffff814c3fe8>] invoke_softirq kernel/softirq.c:430 [inline] [<ffffffff814c3fe8>] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683 [<ffffffff814c3f09>] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695 Fixes: 7ad6848c7e81 ("ip: fix mc_loop checks for tunnels with multicast outer addresses") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Reviewed-by: Kuniyuki Iwashima <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: valis <[email protected]> Date: Fri Sep 1 12:22:37 2023 -0400 net: sched: sch_qfq: Fix UAF in qfq_dequeue() [ Upstream commit 8fc134fee27f2263988ae38920bc03da416b03d8 ] When the plug qdisc is used as a class of the qfq qdisc it could trigger a UAF. This issue can be reproduced with following commands: tc qdisc add dev lo root handle 1: qfq tc class add dev lo parent 1: classid 1:1 qfq weight 1 maxpkt 512 tc qdisc add dev lo parent 1:1 handle 2: plug tc filter add dev lo parent 1: basic classid 1:1 ping -c1 127.0.0.1 and boom: [ 285.353793] BUG: KASAN: slab-use-after-free in qfq_dequeue+0xa7/0x7f0 [ 285.354910] Read of size 4 at addr ffff8880bad312a8 by task ping/144 [ 285.355903] [ 285.356165] CPU: 1 PID: 144 Comm: ping Not tainted 6.5.0-rc3+ #4 [ 285.357112] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 285.358376] Call Trace: [ 285.358773] <IRQ> [ 285.359109] dump_stack_lvl+0x44/0x60 [ 285.359708] print_address_description.constprop.0+0x2c/0x3c0 [ 285.360611] kasan_report+0x10c/0x120 [ 285.361195] ? qfq_dequeue+0xa7/0x7f0 [ 285.361780] qfq_dequeue+0xa7/0x7f0 [ 285.362342] __qdisc_run+0xf1/0x970 [ 285.362903] net_tx_action+0x28e/0x460 [ 285.363502] __do_softirq+0x11b/0x3de [ 285.364097] do_softirq.part.0+0x72/0x90 [ 285.364721] </IRQ> [ 285.365072] <TASK> [ 285.365422] __local_bh_enable_ip+0x77/0x90 [ 285.366079] __dev_queue_xmit+0x95f/0x1550 [ 285.366732] ? __pfx_csum_and_copy_from_iter+0x10/0x10 [ 285.367526] ? __pfx___dev_queue_xmit+0x10/0x10 [ 285.368259] ? __build_skb_around+0x129/0x190 [ 285.368960] ? ip_generic_getfrag+0x12c/0x170 [ 285.369653] ? __pfx_ip_generic_getfrag+0x10/0x10 [ 285.370390] ? csum_partial+0x8/0x20 [ 285.370961] ? raw_getfrag+0xe5/0x140 [ 285.371559] ip_finish_output2+0x539/0xa40 [ 285.372222] ? __pfx_ip_finish_output2+0x10/0x10 [ 285.372954] ip_output+0x113/0x1e0 [ 285.373512] ? __pfx_ip_output+0x10/0x10 [ 285.374130] ? icmp_out_count+0x49/0x60 [ 285.374739] ? __pfx_ip_finish_output+0x10/0x10 [ 285.375457] ip_push_pending_frames+0xf3/0x100 [ 285.376173] raw_sendmsg+0xef5/0x12d0 [ 285.376760] ? do_syscall_64+0x40/0x90 [ 285.377359] ? __static_call_text_end+0x136578/0x136578 [ 285.378173] ? do_syscall_64+0x40/0x90 [ 285.378772] ? kasan_enable_current+0x11/0x20 [ 285.379469] ? __pfx_raw_sendmsg+0x10/0x10 [ 285.380137] ? __sock_create+0x13e/0x270 [ 285.380673] ? __sys_socket+0xf3/0x180 [ 285.381174] ? __x64_sys_socket+0x3d/0x50 [ 285.381725] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 285.382425] ? __rcu_read_unlock+0x48/0x70 [ 285.382975] ? ip4_datagram_release_cb+0xd8/0x380 [ 285.383608] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 285.384295] ? preempt_count_sub+0x14/0xc0 [ 285.384844] ? __list_del_entry_valid+0x76/0x140 [ 285.385467] ? _raw_spin_lock_bh+0x87/0xe0 [ 285.386014] ? __pfx__raw_spin_lock_bh+0x10/0x10 [ 285.386645] ? release_sock+0xa0/0xd0 [ 285.387148] ? preempt_count_sub+0x14/0xc0 [ 285.387712] ? freeze_secondary_cpus+0x348/0x3c0 [ 285.388341] ? aa_sk_perm+0x177/0x390 [ 285.388856] ? __pfx_aa_sk_perm+0x10/0x10 [ 285.389441] ? check_stack_object+0x22/0x70 [ 285.390032] ? inet_send_prepare+0x2f/0x120 [ 285.390603] ? __pfx_inet_sendmsg+0x10/0x10 [ 285.391172] sock_sendmsg+0xcc/0xe0 [ 285.391667] __sys_sendto+0x190/0x230 [ 285.392168] ? __pfx___sys_sendto+0x10/0x10 [ 285.392727] ? kvm_clock_get_cycles+0x14/0x30 [ 285.393328] ? set_normalized_timespec64+0x57/0x70 [ 285.393980] ? _raw_spin_unlock_irq+0x1b/0x40 [ 285.394578] ? __x64_sys_clock_gettime+0x11c/0x160 [ 285.395225] ? __pfx___x64_sys_clock_gettime+0x10/0x10 [ 285.395908] ? _copy_to_user+0x3e/0x60 [ 285.396432] ? exit_to_user_mode_prepare+0x1a/0x120 [ 285.397086] ? syscall_exit_to_user_mode+0x22/0x50 [ 285.397734] ? do_syscall_64+0x71/0x90 [ 285.398258] __x64_sys_sendto+0x74/0x90 [ 285.398786] do_syscall_64+0x64/0x90 [ 285.399273] ? exit_to_user_mode_prepare+0x1a/0x120 [ 285.399949] ? syscall_exit_to_user_mode+0x22/0x50 [ 285.400605] ? do_syscall_64+0x71/0x90 [ 285.401124] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 285.401807] RIP: 0033:0x495726 [ 285.402233] Code: ff ff ff f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 09 [ 285.404683] RSP: 002b:00007ffcc25fb618 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 285.405677] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 0000000000495726 [ 285.406628] RDX: 0000000000000040 RSI: 0000000002518750 RDI: 0000000000000000 [ 285.407565] RBP: 00000000005205ef R08: 00000000005f8838 R09: 000000000000001c [ 285.408523] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000002517634 [ 285.409460] R13: 00007ffcc25fb6f0 R14: 0000000000000003 R15: 0000000000000000 [ 285.410403] </TASK> [ 285.410704] [ 285.410929] Allocated by task 144: [ 285.411402] kasan_save_stack+0x1e/0x40 [ 285.411926] kasan_set_track+0x21/0x30 [ 285.412442] __kasan_slab_alloc+0x55/0x70 [ 285.412973] kmem_cache_alloc_node+0x187/0x3d0 [ 285.413567] __alloc_skb+0x1b4/0x230 [ 285.414060] __ip_append_data+0x17f7/0x1b60 [ 285.414633] ip_append_data+0x97/0xf0 [ 285.415144] raw_sendmsg+0x5a8/0x12d0 [ 285.415640] sock_sendmsg+0xcc/0xe0 [ 285.416117] __sys_sendto+0x190/0x230 [ 285.416626] __x64_sys_sendto+0x74/0x90 [ 285.417145] do_syscall_64+0x64/0x90 [ 285.417624] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 285.418306] [ 285.418531] Freed by task 144: [ 285.418960] kasan_save_stack+0x1e/0x40 [ 285.419469] kasan_set_track+0x21/0x30 [ 285.419988] kasan_save_free_info+0x27/0x40 [ 285.420556] ____kasan_slab_free+0x109/0x1a0 [ 285.421146] kmem_cache_free+0x1c2/0x450 [ 285.421680] __netif_receive_skb_core+0x2ce/0x1870 [ 285.422333] __netif_receive_skb_one_core+0x97/0x140 [ 285.423003] process_backlog+0x100/0x2f0 [ 285.423537] __napi_poll+0x5c/0x2d0 [ 285.424023] net_rx_action+0x2be/0x560 [ 285.424510] __do_softirq+0x11b/0x3de [ 285.425034] [ 285.425254] The buggy address belongs to the object at ffff8880bad31280 [ 285.425254] which belongs to the cache skbuff_head_cache of size 224 [ 285.426993] The buggy address is located 40 bytes inside of [ 285.426993] freed 224-byte region [ffff8880bad31280, ffff8880bad31360) [ 285.428572] [ 285.428798] The buggy address belongs to the physical page: [ 285.429540] page:00000000f4b77674 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbad31 [ 285.430758] flags: 0x100000000000200(slab|node=0|zone=1) [ 285.431447] page_type: 0xffffffff() [ 285.431934] raw: 0100000000000200 ffff88810094a8c0 dead000000000122 0000000000000000 [ 285.432757] raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 [ 285.433562] page dumped because: kasan: bad access detected [ 285.434144] [ 285.434320] Memory state around the buggy address: [ 285.434828] ffff8880bad31180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 285.435580] ffff8880bad31200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 285.436264] >ffff8880bad31280: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 285.436777] ^ [ 285.437106] ffff8880bad31300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 285.437616] ffff8880bad31380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 285.438126] ================================================================== [ 285.438662] Disabling lock debugging due to kernel taint Fix this by: 1. Changing sch_plug's .peek handler to qdisc_peek_dequeued(), a function compatible with non-work-conserving qdiscs 2. Checking the return value of qdisc_dequeue_peeked() in sch_qfq. Fixes: 462dbc9101ac ("pkt_sched: QFQ Plus: fair-queueing service at DRR cost") Reported-by: valis <[email protected]> Signed-off-by: valis <[email protected]> Signed-off-by: Jamal Hadi Salim <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Menglong Dong <[email protected]> Date: Fri Aug 11 10:55:29 2023 +0800 net: tcp: fix unexcepted socket die when snd_wnd is 0 [ Upstream commit e89688e3e97868451a5d05b38a9d2633d6785cd4 ] In tcp_retransmit_timer(), a window shrunk connection will be regarded as timeout if 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX'. This is not right all the time. The retransmits will become zero-window probes in tcp_retransmit_timer() if the 'snd_wnd==0'. Therefore, the icsk->icsk_rto will come up to TCP_RTO_MAX sooner or later. However, the timer can be delayed and be triggered after 122877ms, not TCP_RTO_MAX, as I tested. Therefore, 'tcp_jiffies32 - tp->rcv_tstamp > TCP_RTO_MAX' is always true once the RTO come up to TCP_RTO_MAX, and the socket will die. Fix this by replacing the 'tcp_jiffies32' with '(u32)icsk->icsk_timeout', which is exact the timestamp of the timeout. However, "tp->rcv_tstamp" can restart from idle, then tp->rcv_tstamp could already be a long time (minutes or hours) in the past even on the first RTO. So we double check the timeout with the duration of the retransmission. Meanwhile, making "2 * TCP_RTO_MAX" as the timeout to avoid the socket dying too soon. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/netdev/CADxym3YyMiO+zMD4zj03YPM3FBi-1LHi6gSD2XT8pyAMM096pg@mail.gmail.com/ Signed-off-by: Menglong Dong <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Martin Kohn <[email protected]> Date: Thu Jul 27 20:00:43 2023 +0000 net: usb: qmi_wwan: add Quectel EM05GV2 [ Upstream commit d4480c9bb9258db9ddf2e632f6ef81e96b41089c ] Add support for Quectel EM05GV2 (G=global) with vendor ID 0x2c7c and product ID 0x030e Enabling DTR on this modem was necessary to ensure stable operation. Patch for usb: serial: option: is also in progress. T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=2c7c ProdID=030e Rev= 3.18 S: Manufacturer=Quectel S: Product=Quectel EM05-G C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Martin Kohn <[email protected]> Link: https://lore.kernel.org/r/AM0PR04MB57648219DE893EE04FA6CC759701A@AM0PR04MB5764.eurprd04.prod.outlook.com Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kyle Zeng <[email protected]> Date: Tue Sep 5 15:04:09 2023 -0700 netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c commit 050d91c03b28ca479df13dfb02bcd2c60dd6a878 upstream. The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong `CIDR_POS(c)` for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access. This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue. Fixes: 886503f34d63 ("netfilter: ipset: actually allow allowable CIDR 0 in hash:net,port,net") Suggested-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Kyle Zeng <[email protected]> Acked-by: Jozsef Kadlecsik <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wander Lairson Costa <[email protected]> Date: Fri Sep 1 10:50:20 2023 -0300 netfilter: nfnetlink_osf: avoid OOB read [ Upstream commit f4f8a7803119005e87b716874bec07c751efafec ] The opt_num field is controlled by user mode and is not currently validated inside the kernel. An attacker can take advantage of this to trigger an OOB read and potentially leak information. BUG: KASAN: slab-out-of-bounds in nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88 Read of size 2 at addr ffff88804bc64272 by task poc/6431 CPU: 1 PID: 6431 Comm: poc Not tainted 6.0.0-rc4 #1 Call Trace: nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88 nf_osf_find+0x186/0x2f0 net/netfilter/nfnetlink_osf.c:281 nft_osf_eval+0x37f/0x590 net/netfilter/nft_osf.c:47 expr_call_ops_eval net/netfilter/nf_tables_core.c:214 nft_do_chain+0x2b0/0x1490 net/netfilter/nf_tables_core.c:264 nft_do_chain_ipv4+0x17c/0x1f0 net/netfilter/nft_chain_filter.c:23 [..] Also add validation to genre, subtype and version fields. Fixes: 11eeef41d5f6 ("netfilter: passive OS fingerprint xtables match") Reported-by: Lucas Leong <[email protected]> Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Florian Westphal <[email protected]> Date: Tue Sep 5 23:13:56 2023 +0200 netfilter: nftables: exthdr: fix 4-byte stack OOB write [ Upstream commit fd94d9dadee58e09b49075240fe83423eb1dcd36 ] If priv->len is a multiple of 4, then dst[len / 4] can write past the destination array which leads to stack corruption. This construct is necessary to clean the remainder of the register in case ->len is NOT a multiple of the register size, so make it conditional just like nft_payload.c does. The bug was added in 4.1 cycle and then copied/inherited when tcp/sctp and ip option support was added. Bug reported by Zero Day Initiative project (ZDI-CAN-21950, ZDI-CAN-21951, ZDI-CAN-21961). Fixes: 49499c3e6e18 ("netfilter: nf_tables: switch registers to 32 bit addressing") Fixes: 935b7f643018 ("netfilter: nft_exthdr: add TCP option matching") Fixes: 133dc203d77d ("netfilter: nft_exthdr: Support SCTP chunks") Fixes: dbb5281a1f84 ("netfilter: nf_tables: add support for matching IPv4 options") Signed-off-by: Florian Westphal <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wander Lairson Costa <[email protected]> Date: Mon Aug 28 19:12:55 2023 -0300 netfilter: xt_sctp: validate the flag_info count commit e99476497687ef9e850748fe6d232264f30bc8f9 upstream. sctp_mt_check doesn't validate the flag_count field. An attacker can take advantage of that to trigger a OOB read and leak memory information. Add the field validation in the checkentry function. Fixes: 2e4e6a17af35 ("[NETFILTER] x_tables: Abstraction layer for {ip,ip6,arp}_tables") Cc: [email protected] Reported-by: Lucas Leong <[email protected]> Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Wander Lairson Costa <[email protected]> Date: Mon Aug 28 10:21:07 2023 -0300 netfilter: xt_u32: validate user space input commit 69c5d284f67089b4750d28ff6ac6f52ec224b330 upstream. The xt_u32 module doesn't validate the fields in the xt_u32 structure. An attacker may take advantage of this to trigger an OOB read by setting the size fields with a value beyond the arrays boundaries. Add a checkentry function to validate the structure. This was originally reported by the ZDI project (ZDI-CAN-18408). Fixes: 1b50b8a371e9 ("[NETFILTER]: Add u32 match") Cc: [email protected] Signed-off-by: Wander Lairson Costa <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dmitry Mastykin <[email protected]> Date: Thu Jun 8 16:57:54 2023 +0300 netlabel: fix shift wrapping bug in netlbl_catmap_setlong() [ Upstream commit b403643d154d15176b060b82f7fc605210033edd ] There is a shift wrapping bug in this code on 32-bit architectures. NETLBL_CATMAP_MAPTYPE is u64, bitmap is unsigned long. Every second 32-bit word of catmap becomes corrupted. Signed-off-by: Dmitry Mastykin <[email protected]> Acked-by: Paul Moore <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kuniyuki Iwashima <[email protected]> Date: Thu Aug 24 09:50:59 2023 -0700 netrom: Deny concurrent connect(). [ Upstream commit c2f8fd7949603efb03908e05abbf7726748c8de3 ] syzkaller reported null-ptr-deref [0] related to AF_NETROM. This is another self-accept issue from the strace log. [1] syz-executor creates an AF_NETROM socket and calls connect(), which is blocked at that time. Then, sk->sk_state is TCP_SYN_SENT and sock->state is SS_CONNECTING. [pid 5059] socket(AF_NETROM, SOCK_SEQPACKET, 0) = 4 [pid 5059] connect(4, {sa_family=AF_NETROM, sa_data="..." <unfinished ...> Another thread calls connect() concurrently, which finally fails with -EINVAL. However, the problem here is the socket state is reset even while the first connect() is blocked. [pid 5060] connect(4, NULL, 0 <unfinished ...> [pid 5060] <... connect resumed>) = -1 EINVAL (Invalid argument) As sk->state is TCP_CLOSE and sock->state is SS_UNCONNECTED, the following listen() succeeds. Then, the first connect() looks up itself as a listener and puts skb into the queue with skb->sk itself. As a result, the next accept() gets another FD of itself as 3, and the first connect() finishes. [pid 5060] listen(4, 0 <unfinished ...> [pid 5060] <... listen resumed>) = 0 [pid 5060] accept(4, NULL, NULL <unfinished ...> [pid 5060] <... accept resumed>) = 3 [pid 5059] <... connect resumed>) = 0 Then, accept4() is called but blocked, which causes the general protection fault later. [pid 5059] accept4(4, NULL, 0x20000400, SOCK_NONBLOCK <unfinished ...> After that, another self-accept occurs by accept() and writev(). [pid 5060] accept(4, NULL, NULL <unfinished ...> [pid 5061] writev(3, [{iov_base=...}] <unfinished ...> [pid 5061] <... writev resumed>) = 99 [pid 5060] <... accept resumed>) = 6 Finally, the leader thread close()s all FDs. Since the three FDs reference the same socket, nr_release() does the cleanup for it three times, and the remaining accept4() causes the following fault. [pid 5058] close(3) = 0 [pid 5058] close(4) = 0 [pid 5058] close(5) = -1 EBADF (Bad file descriptor) [pid 5058] close(6) = 0 [pid 5058] <... exit_group resumed>) = ? [ 83.456055][ T5059] general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN To avoid the issue, we need to return an error for connect() if another connect() is in progress, as done in __inet_stream_connect(). [0]: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] CPU: 0 PID: 5059 Comm: syz-executor.0 Not tainted 6.5.0-rc5-syzkaller-00194-gace0ab3a4b54 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 RIP: 0010:__lock_acquire+0x109/0x5de0 kernel/locking/lockdep.c:5012 Code: 45 85 c9 0f 84 cc 0e 00 00 44 8b 05 11 6e 23 0b 45 85 c0 0f 84 be 0d 00 00 48 ba 00 00 00 00 00 fc ff df 4c 89 d1 48 c1 e9 03 <80> 3c 11 00 0f 85 e8 40 00 00 49 81 3a a0 69 48 90 0f 84 96 0d 00 RSP: 0018:ffffc90003d6f9e0 EFLAGS: 00010006 RAX: ffff8880244c8000 RBX: 1ffff920007adf6c RCX: 0000000000000003 RDX: dffffc0000000000 RSI: 0000000000000000 RDI: 0000000000000018 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000018 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f51d519a6c0(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f51d5158d58 CR3: 000000002943f000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> lock_acquire kernel/locking/lockdep.c:5761 [inline] lock_acquire+0x1ae/0x510 kernel/locking/lockdep.c:5726 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3a/0x50 kernel/locking/spinlock.c:162 prepare_to_wait+0x47/0x380 kernel/sched/wait.c:269 nr_accept+0x20d/0x650 net/netrom/af_netrom.c:798 do_accept+0x3a6/0x570 net/socket.c:1872 __sys_accept4_file net/socket.c:1913 [inline] __sys_accept4+0x99/0x120 net/socket.c:1943 __do_sys_accept4 net/socket.c:1954 [inline] __se_sys_accept4 net/socket.c:1951 [inline] __x64_sys_accept4+0x96/0x100 net/socket.c:1951 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f51d447cae9 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:00007f51d519a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000120 RAX: ffffffffffffffda RBX: 00007f51d459bf80 RCX: 00007f51d447cae9 RDX: 0000000020000400 RSI: 0000000000000000 RDI: 0000000000000004 RBP: 00007f51d44c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000800 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f51d459bf80 R15: 00007ffc25c34e48 </TASK> Link: https://syzkaller.appspot.com/text?tag=CrashLog&x=152cdb63a80000 [1] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: [email protected] Closes: https://syzkaller.appspot.com/bug?extid=666c97e4686410e79649 Signed-off-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Mon Jul 24 11:08:46 2023 +0300 nfs/blocklayout: Use the passed in gfp flags [ Upstream commit 08b45fcb2d4675f6182fe0edc0d8b1fe604051fa ] This allocation should use the passed in GFP_ flags instead of GFP_KERNEL. One places where this matters is in filelayout_pg_init_write() which uses GFP_NOFS as the allocation flags. Fixes: 5c83746a0cf2 ("pnfs/blocklayout: in-kernel GETDEVICEINFO XDR parsing") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Trond Myklebust <[email protected]> Date: Sat Aug 19 17:22:14 2023 -0400 NFS: Fix a potential data corruption commit 88975a55969e11f26fe3846bf4fbf8e7dc8cbbd4 upstream. We must ensure that the subrequests are joined back into the head before we can retransmit a request. If the head was not on the commit lists, because the server wrote it synchronously, we still need to add it back to the retransmission list. Add a call that mirrors the effect of nfs_cancel_remove_inode() for O_DIRECT. Fixes: ed5d588fe47f ("NFS: Try to join page groups before an O_DIRECT retransmission") Cc: [email protected] Signed-off-by: Trond Myklebust <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Benjamin Coddington <[email protected]> Date: Tue Aug 22 14:22:38 2023 -0400 NFS: Guard against READDIR loop when entry names exceed MAXNAMELEN [ Upstream commit f67b55b6588bcf9316a1e6e8d529100a5aa3ebe6 ] Commit 64cfca85bacd asserts the only valid return values for nfs2/3_decode_dirent should not include -ENAMETOOLONG, but for a server that sends a filename3 which exceeds MAXNAMELEN in a READDIR response the client's behavior will be to endlessly retry the operation. We could map -ENAMETOOLONG into -EBADCOOKIE, but that would produce truncated listings without any error. The client should return an error for this case to clearly assert that the server implementation must be corrected. Fixes: 64cfca85bacd ("NFS: Return valid errors from nfs2/3_decode_dirent()") Signed-off-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chuck Lever <[email protected]> Date: Wed Aug 16 10:20:52 2023 -0400 NFSD: da_addr_body field missing in some GETDEVICEINFO replies [ Upstream commit 6372e2ee629894433fe6107d7048536a3280a284 ] The XDR specification in RFC 8881 looks like this: struct device_addr4 { layouttype4 da_layout_type; opaque da_addr_body<>; }; struct GETDEVICEINFO4resok { device_addr4 gdir_device_addr; bitmap4 gdir_notification; }; union GETDEVICEINFO4res switch (nfsstat4 gdir_status) { case NFS4_OK: GETDEVICEINFO4resok gdir_resok4; case NFS4ERR_TOOSMALL: count4 gdir_mincount; default: void; }; Looking at nfsd4_encode_getdeviceinfo() .... When the client provides a zero gd_maxcount, then the Linux NFS server implementation encodes the da_layout_type field and then skips the da_addr_body field completely, proceeding directly to encode gdir_notification field. There does not appear to be an option in the specification to skip encoding da_addr_body. Moreover, Section 18.40.3 says: > If the client wants to just update or turn off notifications, it > MAY send a GETDEVICEINFO operation with gdia_maxcount set to zero. > In that event, if the device ID is valid, the reply's da_addr_body > field of the gdir_device_addr field will be of zero length. Since the layout drivers are responsible for encoding the da_addr_body field, put this fix inside the ->encode_getdeviceinfo methods. Fixes: 9cf514ccfacb ("nfsd: implement pNFS operations") Reviewed-by: Christoph Hellwig <[email protected]> Cc: Tom Haynes <[email protected]> Signed-off-by: Chuck Lever <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Olga Kornievskaia <[email protected]> Date: Thu Aug 24 16:43:53 2023 -0400 NFSv4.2: fix handling of COPY ERR_OFFLOAD_NO_REQ [ Upstream commit 5690eed941ab7e33c3c3d6b850100cabf740f075 ] If the client sent a synchronous copy and the server replied with ERR_OFFLOAD_NO_REQ indicating that it wants an asynchronous copy instead, the client should retry with asynchronous copy. Fixes: 539f57b3e0fd ("NFS handle COPY ERR_OFFLOAD_NO_REQS") Signed-off-by: Olga Kornievskaia <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Thu Jul 20 18:37:51 2023 +0300 NFSv4/pnfs: minor fix for cleanup path in nfs4_get_device_info commit 96562c45af5c31b89a197af28f79bfa838fb8391 upstream. It is an almost improbable error case but when page allocating loop in nfs4_get_device_info() fails then we should only free the already allocated pages, as __free_page() can't deal with NULL arguments. Found by Linux Verification Center (linuxtesting.org). Cc: [email protected] Signed-off-by: Fedor Pchelkin <[email protected]> Reviewed-by: Benjamin Coddington <[email protected]> Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Jiang <[email protected]> Date: Tue Aug 22 09:04:45 2023 -0700 ntb: Clean up tx tail index on link down commit cc79bd2738c2d40aba58b2be6ce47dc0e471df0e upstream. The tx tail index is not reset when the link goes down. This causes the tail index to go out of sync when the link goes down and comes back up. Refactor the ntb_qp_link_down_reset() and reset the tail index as well. Fixes: 2849b5d70641 ("NTB: Reset transport QP link stats on down") Reported-by: Yuan Y Lu <[email protected]> Tested-by: Yuan Y Lu <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Jiang <[email protected]> Date: Tue Aug 22 09:04:51 2023 -0700 ntb: Drop packets when qp link is down commit f195a1a6fe416882984f8bd6c61afc1383171860 upstream. Currently when the transport receive packets after netdev has closed the transport returns error and triggers tx errors to be incremented and carrier to be stopped. There is no reason to return error if the device is already closed. Drop the packet and return 0. Fixes: e26a5843f7f5 ("NTB: Split ntb_hw_intel and ntb_transport drivers") Reported-by: Yuan Y Lu <[email protected]> Tested-by: Yuan Y Lu <[email protected]> Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Jiang <[email protected]> Date: Tue Aug 22 09:04:57 2023 -0700 ntb: Fix calculation ntb_transport_tx_free_entry() commit 5a7693e6bbf19b22fd6c1d2c4b7beb0a03969e2c upstream. ntb_transport_tx_free_entry() never returns 0 with the current calculation. If head == tail, then it would return qp->tx_max_entry. Change compare to tail >= head and when they are equal, a 0 would be returned. Fixes: e74bfeedad08 ("NTB: Add flow control to the ntb_netdev") Reviewed-by: Logan Gunthorpe <[email protected]> Signed-off-by: renlonglong <[email protected]> Signed-off-by: Dave Jiang <[email protected]> Signed-off-by: Jon Mason <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geetha sowjanya <[email protected]> Date: Tue Sep 5 12:18:16 2023 +0530 octeontx2-af: Fix truncation of smq in CN10K NIX AQ enqueue mbox handler [ Upstream commit 29fe7a1b62717d58f033009874554d99d71f7d37 ] The smq value used in the CN10K NIX AQ instruction enqueue mailbox handler was truncated to 9-bit value from 10-bit value because of typecasting the CN10K mbox request structure to the CN9K structure. Though this hasn't caused any problems when programming the NIX SQ context to the HW because the context structure is the same size. However, this causes a problem when accessing the structure parameters. This patch reads the right smq value for each platform. Fixes: 30077d210c83 ("octeontx2-af: cn10k: Update NIX/NPA context structure") Signed-off-by: Geetha sowjanya <[email protected]> Signed-off-by: Sunil Kovvuri Goutham <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nathan Chancellor <[email protected]> Date: Tue Sep 5 13:36:11 2023 -0700 of: kexec: Mark ima_{free,stable}_kexec_buffer() as __init This commit has no direct upstream equivalent. After commit d48016d74836 ("mm,ima,kexec,of: use memblock_free_late from ima_free_kexec_buffer") in 5.15, there is a modpost warning for certain configurations: WARNING: modpost: vmlinux.o(.text+0xb14064): Section mismatch in reference from the function ima_free_kexec_buffer() to the function .init.text:__memblock_free_late() The function ima_free_kexec_buffer() references the function __init __memblock_free_late(). This is often because ima_free_kexec_buffer lacks a __init annotation or the annotation of __memblock_free_late is wrong. In mainline, there is no issue because ima_free_kexec_buffer() is marked as __init, which was done as part of commit b69a2afd5afc ("x86/kexec: Carry forward IMA measurement log on kexec") in 6.0, which is not suitable for stable. Mark ima_free_kexec_buffer() and its single caller ima_load_kexec_buffer() as __init in 5.15, as ima_load_kexec_buffer() is only called from ima_init(), which is __init, clearing up the warning. Signed-off-by: Nathan Chancellor <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Fri Jul 28 10:50:28 2023 +0200 of: overlay: Call of_changeset_init() early [ Upstream commit a9515ff4fb142b690a0d2b58782b15903b990dba ] When of_overlay_fdt_apply() fails, the changeset may be partially applied, and the caller is still expected to call of_overlay_remove() to clean up this partial state. However, of_overlay_apply() calls of_resolve_phandles() before init_overlay_changeset(). Hence if the overlay fails to apply due to an unresolved symbol, the overlay_changeset.cset.entries list is still uninitialized, and cleanup will crash with a NULL-pointer dereference in overlay_removal_is_ok(). Fix this by moving the call to of_changeset_init() from init_overlay_changeset() to of_overlay_fdt_apply(), where all other early initialization is done. Fixes: f948d6d8b792bb90 ("of: overlay: avoid race condition between applying multiple overlays") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/4f1d6d74b61cba2599026adb6d1948ae559ce91f.1690533838.git.geert+renesas@glider.be Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ruan Jinjie <[email protected]> Date: Thu Jul 27 16:02:46 2023 +0800 of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name() [ Upstream commit d6ce4f0ea19c32f10867ed93d8386924326ab474 ] when kmalloc() fail to allocate memory in kasprintf(), name or full_name will be NULL, strcmp() will cause null pointer dereference. Fixes: 0d638a07d3a1 ("of: Convert to using %pOF instead of full_name") Signed-off-by: Ruan Jinjie <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Geert Uytterhoeven <[email protected]> Date: Fri Jul 28 10:50:29 2023 +0200 of: unittest: Fix overlay type in apply/revert check [ Upstream commit 6becf8f845ae1f0b1cfed395bbeccbd23654162d ] The removal check in of_unittest_apply_revert_overlay_check() always uses the platform device overlay type, while it should use the actual overlay type, as passed as a parameter to the function. This has no impact on any current test, as all tests calling of_unittest_apply_revert_overlay_check() use the platform device overlay type. Fixes: d5e75500ca401d31 ("of: unitest: Add I2C overlay unit tests.") Signed-off-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/r/ba0234c41ba808f10112094f88792beeb6dbaedf.1690533838.git.geert+renesas@glider.be Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Manivannan Sadhasivam <[email protected]> Date: Fri Jul 21 18:16:34 2023 +0530 OPP: Fix passing 0 to PTR_ERR in _opp_attach_genpd() [ Upstream commit d920920f85a82c1c806a4143871a0e8f534732f2 ] If dev_pm_domain_attach_by_name() returns NULL, then 0 will be passed to PTR_ERR() as reported by the smatch warning below: drivers/opp/core.c:2456 _opp_attach_genpd() warn: passing zero to 'PTR_ERR' Fix it by checking for the non-NULL virt_dev pointer before passing it to PTR_ERR. Otherwise return -ENODEV. Fixes: 4ea9496cbc95 ("opp: Fix error check in dev_pm_opp_attach_genpd()") Signed-off-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Snowberg <[email protected]> Date: Tue Jul 25 17:56:46 2023 -0400 ovl: Always reevaluate the file signature for IMA [ Upstream commit 18b44bc5a67275641fb26f2c54ba7eef80ac5950 ] Commit db1d1e8b9867 ("IMA: use vfs_getattr_nosec to get the i_version") partially closed an IMA integrity issue when directly modifying a file on the lower filesystem. If the overlay file is first opened by a user and later the lower backing file is modified by root, but the extended attribute is NOT updated, the signature validation succeeds with the old original signature. Update the super_block s_iflags to SB_I_IMA_UNVERIFIABLE_SIGNATURE to force signature reevaluation on every file access until a fine grained solution can be found. Signed-off-by: Eric Snowberg <[email protected]> Signed-off-by: Mimi Zohar <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Helge Deller <[email protected]> Date: Fri Aug 18 22:48:04 2023 +0200 parisc: Fix /proc/cpuinfo output for lscpu commit 9f5ba4b3e1b3c123eeca5d2d09161e8720048b5c upstream. The lscpu command is broken since commit cab56b51ec0e ("parisc: Fix device names in /proc/iomem") added the PA pathname to all PA devices, includig the CPUs. lscpu parses /proc/cpuinfo and now believes it found different CPU types since every CPU is listed with an unique identifier (PA pathname). Fix this problem by simply dropping the PA pathname when listing the CPUs in /proc/cpuinfo. There is no need to show the pathname in this procfs file. Fixes: cab56b51ec0e ("parisc: Fix device names in /proc/iomem") Signed-off-by: Helge Deller <[email protected]> Cc: <[email protected]> # v4.9+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Sun Aug 27 13:46:11 2023 +0200 parisc: led: Fix LAN receive and transmit LEDs commit 4db89524b084f712a887256391fc19d9f66c8e55 upstream. Fix the LAN receive and LAN transmit LEDs, which where swapped up to now. Signed-off-by: Helge Deller <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Helge Deller <[email protected]> Date: Fri Aug 25 17:46:39 2023 +0200 parisc: led: Reduce CPU overhead for disk & lan LED computation commit 358ad816e52d4253b38c2f312e6b1cbd89e0dbf7 upstream. Older PA-RISC machines have LEDs which show the disk- and LAN-activity. The computation is done in software and takes quite some time, e.g. on a J6500 this may take up to 60% time of one CPU if the machine is loaded via network traffic. Since most people don't care about the LEDs, start with LEDs disabled and just show a CPU heartbeat LED. The disk and LAN LEDs can be turned on manually via /proc/pdc/led. Signed-off-by: Helge Deller <[email protected]> Cc: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Sep 27 15:01:04 2021 -0700 pcd: cleanup initialization [ Upstream commit af761f277b7fd896c27cb1100b25f11567987822 ] Refactor the pcd initialization to have a dedicated helper to initialize a single disk. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Oct 1 15:26:23 2021 +0300 pcd: fix error codes in pcd_init_unit() commit d0ac7a30e41174c794fbfa53ea986d9555e5b9f4 upstream. Return -ENODEV on these error paths instead of returning success. Fixes: af761f277b7f ("pcd: cleanup initialization") Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/20211001122623.GA2283@kili Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Christoph Hellwig <[email protected]> Date: Mon Sep 27 15:01:03 2021 -0700 pcd: move the identify buffer into pcd_identify [ Upstream commit 7d8b72aaddd3ec5f350d3e9988d6735a7b9b18e9 ] No need to pass it through a bunch of functions. Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]> Stable-dep-of: 1a721de8489f ("block: don't add or resize partition on the disk with GENHD_FL_NO_PART") Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:56 2023 +0300 PCI/ASPM: Use RMW accessors for changing LNKCTL [ Upstream commit e09060b3b6b4661278ff8e1b7b81a37d5ea86eae ] Don't assume that the device is fully under the control of ASPM and use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register values. If configuration fails in pcie_aspm_configure_common_clock(), the function attempts to restore the old PCI_EXP_LNKCTL_CCC settings. Store only the old PCI_EXP_LNKCTL_CCC bit for the relevant devices rather than the content of the whole LNKCTL registers. It aligns better with how pcie_lnkctl_clear_and_set() expects its parameter and makes the code more obvious to understand. Suggested-by: Lukas Wunner <[email protected]> Fixes: 2a42d9dba784 ("PCIe: ASPM: Break out of endless loop waiting for PCI config bits to switch") Fixes: 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Serge Semin <[email protected]> Date: Fri Jun 24 17:34:23 2022 +0300 PCI: dwc: Add start_link/stop_link inlines [ Upstream commit a37beefbde8802a4eab2545fee1b1780a03f2aa0 ] Factor out this pattern: if (!pci->ops || !pci->ops->start_link) return -EINVAL; return pci->ops->start_link(pci); into a new dw_pcie_start_link() wrapper and do the same for the stop_link() method. Note that dw_pcie_ep_start() previously returned -EINVAL if there was no platform start_link() method, which didn't make much sense since that is not an error. It will now return 0 in that case. As a side-effect, drop the empty start_link() and dummy dw_pcie_ops instances from the generic DW PCIe and Layerscape EP platform drivers. [bhelgaas: commit log] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Serge Semin <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Rob Herring <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Stable-dep-of: 17cf8661ee0f ("PCI: layerscape: Add workaround for lost link capabilities during reset") Signed-off-by: Sasha Levin <[email protected]>
Author: Frank Li <[email protected]> Date: Mon May 15 11:10:49 2023 -0400 PCI: layerscape: Add the endpoint linkup notifier support [ Upstream commit 061cbfab09fb35898f2907d42f936cf9ae271d93 ] Layerscape has PME interrupt, which can be used as linkup notifier. Set CFG_READY bit of PEX_PF0_CONFIG to enable accesses from root complex when linkup detected. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xiaowei Bao <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Stable-dep-of: 17cf8661ee0f ("PCI: layerscape: Add workaround for lost link capabilities during reset") Signed-off-by: Sasha Levin <[email protected]>
Author: Xiaowei Bao <[email protected]> Date: Thu Jul 20 09:58:34 2023 -0400 PCI: layerscape: Add workaround for lost link capabilities during reset [ Upstream commit 17cf8661ee0f065c08152e611a568dd1fb0285f1 ] The endpoint controller loses the Maximum Link Width and Supported Link Speed value from the Link Capabilities Register - initially configured by the Reset Configuration Word (RCW) - during a link-down or hot reset event. Address this issue in the endpoint event handler. Link: https://lore.kernel.org/r/[email protected] Fixes: a805770d8a22 ("PCI: layerscape: Add EP mode support") Signed-off-by: Xiaowei Bao <[email protected]> Signed-off-by: Hou Zhiqiang <[email protected]> Signed-off-by: Frank Li <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Acked-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wu Zongyong <[email protected]> Date: Mon Apr 10 20:34:11 2023 +0800 PCI: Mark NVIDIA T4 GPUs to avoid bus reset [ Upstream commit d5af729dc2071273f14cbb94abbc60608142fd83 ] NVIDIA T4 GPUs do not work with SBR. This problem is found when the T4 card is direct attached to a Root Port only. Avoid bus reset by marking T4 GPUs PCI_DEV_FLAGS_NO_BUS_RESET. Fixes: 4c207e7121fa ("PCI: Mark some NVIDIA GPUs to avoid bus reset") Link: https://lore.kernel.org/r/2dcebea53a6eb9bd212ec6d8974af2e5e0333ef6.1681129861.git.wuzongyong@linux.alibaba.com Signed-off-by: Wu Zongyong <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daire McNamara <[email protected]> Date: Fri Jul 28 14:13:55 2023 +0100 PCI: microchip: Correct the DED and SEC interrupt bit offsets [ Upstream commit 6d473a5a26136edf55c435a1c433e52910e03926 ] The SEC and DED interrupt bits are laid out the wrong way round so the SEC interrupt handler attempts to mask, unmask, and clear the DED interrupt and vice versa. Correct the bit offsets so that each interrupt handler operates properly. Link: https://lore.kernel.org/r/[email protected] Fixes: 6f15a9c9f941 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver") Signed-off-by: Daire McNamara <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:04:55 2023 +0300 PCI: pciehp: Use RMW accessors for changing LNKCTL [ Upstream commit 5f75f96c61039151c193775d776fde42477eace1 ] As hotplug is not the only driver touching LNKCTL, use the RMW capability accessor which handles concurrent changes correctly. Suggested-by: Lukas Wunner <[email protected]> Fixes: 7f822999e12a ("PCI: pciehp: Add Disable/enable link functions") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: "Rafael J. Wysocki" <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Rick Wertenbroek <[email protected]> Date: Mon Jul 3 10:58:45 2023 +0200 PCI: rockchip: Use 64-bit mask on MSI 64-bit PCI address commit cdb50033dd6dfcf02ae3d4ee56bc1a9555be6d36 upstream. A 32-bit mask was used on the 64-bit PCI address used for mapping MSIs. This would result in the upper 32 bits being unintentionally zeroed and MSIs getting mapped to incorrect PCI addresses if the address had any of the upper bits set. Replace 32-bit mask by appropriate 64-bit mask. [kwilczynski: use GENMASK_ULL() over GENMASK() for 32-bit compatibility] Fixes: dc73ed0f1b8b ("PCI: rockchip: Fix window mapping and address translation for endpoint") Closes: https://lore.kernel.org/linux-pci/[email protected] Link: https://lore.kernel.org/linux-pci/[email protected] Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Rick Wertenbroek <[email protected]> Signed-off-by: Krzysztof Wilczyński <[email protected]> Reviewed-by: Damien Le Moal <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Wed Aug 2 18:22:14 2023 -0300 perf annotate bpf: Don't enclose non-debug code with an assert() [ Upstream commit 979e9c9fc9c2a761303585e07fe2699bdd88182f ] In 616b14b47a86d880 ("perf build: Conditionally define NDEBUG") we started using NDEBUG=1 when DEBUG=1 isn't present, so code that is enclosed with assert() is not called. In dd317df072071903 ("perf build: Make binutil libraries opt in") we stopped linking against binutils-devel, for licensing reasons. Recently people asked me why annotation of BPF programs wasn't working, i.e. this: $ perf annotate bpf_prog_5280546344e3f45c_kfree_skb was returning: case SYMBOL_ANNOTATE_ERRNO__NO_LIBOPCODES_FOR_BPF: scnprintf(buf, buflen, "Please link with binutils's libopcode to enable BPF annotation"); This was on a fedora rpm, so its new enough that I had to try to test by rebuilding using BUILD_NONDISTRO=1, only to get it segfaulting on me. This combination made this libopcode function not to be called: assert(bfd_check_format(bfdf, bfd_object)); Changing it to: if (!bfd_check_format(bfdf, bfd_object)) abort(); Made it work, looking at this "check" function made me realize it changes the 'bfdf' internal state, i.e. we better call it. So stop using assert() on it, just call it and abort if it fails. Probably it is better to propagate the error, etc, but it seems it is unlikely to fail from the usage done so far and we really need to stop using libopcodes, so do the quick fix above and move on. With it we have BPF annotation back working when built with BUILD_NONDISTRO=1: ⬢[acme@toolbox perf-tools-next]$ perf annotate --stdio2 bpf_prog_5280546344e3f45c_kfree_skb | head No kallsyms or vmlinux with build-id 939bc71a1a51cdc434e60af93c7e734f7d5c0e7e was found Samples: 12 of event 'cpu-clock:ppp', 4000 Hz, Event count (approx.): 3000000, [percent: local period] bpf_prog_5280546344e3f45c_kfree_skb() bpf_prog_5280546344e3f45c_kfree_skb Percent int kfree_skb(struct trace_event_raw_kfree_skb *args) { nop 33.33 xchg %ax,%ax push %rbp mov %rsp,%rbp sub $0x180,%rsp push %rbx push %r13 ⬢[acme@toolbox perf-tools-next]$ Fixes: 6987561c9e86eace ("perf annotate: Enable annotation of BPF programs") Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Mohamed Mahmoud <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Dave Tucker <[email protected]> Cc: Derek Barbosa <[email protected]> Cc: Song Liu <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Mon Jul 31 02:49:32 2023 -0700 perf hists browser: Fix hierarchy mode header commit e2cabf2a44791f01c21f8d5189b946926e34142e upstream. The commit ef9ff6017e3c4593 ("perf ui browser: Move the extra title lines from the hists browser") introduced ui_browser__gotorc_title() to help moving non-title lines easily. But it missed to update the title for the hierarchy mode so it won't print the header line on TUI at all. $ perf report --hierarchy Fixes: ef9ff6017e3c4593 ("perf ui browser: Move the extra title lines from the hists browser") Signed-off-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Mon Jul 31 02:49:33 2023 -0700 perf hists browser: Fix the number of entries for 'e' key commit f6b8436bede3e80226e8b2100279c4450c73806a upstream. The 'e' key is to toggle expand/collapse the selected entry only. But the current code has a bug that it only increases the number of entries by 1 in the hierarchy mode so users cannot move under the current entry after the key stroke. This is due to a wrong assumption in the hist_entry__set_folding(). The commit b33f922651011eff ("perf hists browser: Put hist_entry folding logic into single function") factored out the code, but actually it should be handled separately. The hist_browser__set_folding() is to update fold state for each entry so it needs to traverse all (child) entries regardless of the current fold state. So it increases the number of entries by 1. But the hist_entry__set_folding() only cares the currently selected entry and its all children. So it should count all unfolded child entries. This code is implemented in hist_browser__toggle_fold() already so we can just call it. Fixes: b33f922651011eff ("perf hists browser: Put hist_entry folding logic into single function") Signed-off-by: Namhyung Kim <[email protected]> Tested-by: Arnaldo Carvalho de Melo <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Namhyung Kim <[email protected]> Date: Fri Aug 25 08:25:49 2023 -0700 perf tools: Handle old data in PERF_RECORD_ATTR commit 9bf63282ea77a531ea58acb42fb3f40d2d1e4497 upstream. The PERF_RECORD_ATTR is used for a pipe mode to describe an event with attribute and IDs. The ID table comes after the attr and it calculate size of the table using the total record size and the attr size. n_ids = (total_record_size - end_of_the_attr_field) / sizeof(u64) This is fine for most use cases, but sometimes it saves the pipe output in a file and then process it later. And it becomes a problem if there is a change in attr size between the record and report. $ perf record -o- > perf-pipe.data # old version $ perf report -i- < perf-pipe.data # new version For example, if the attr size is 128 and it has 4 IDs, then it would save them in 168 byte like below: 8 byte: perf event header { .type = PERF_RECORD_ATTR, .size = 168 }, 128 byte: perf event attr { .size = 128, ... }, 32 byte: event IDs [] = { 1234, 1235, 1236, 1237 }, But when report later, it thinks the attr size is 136 then it only read the last 3 entries as ID. 8 byte: perf event header { .type = PERF_RECORD_ATTR, .size = 168 }, 136 byte: perf event attr { .size = 136, ... }, 24 byte: event IDs [] = { 1235, 1236, 1237 }, // 1234 is missing So it should use the recorded version of the attr. The attr has the size field already then it should honor the size when reading data. Fixes: 2c46dbb517a10b18 ("perf: Convert perf header attrs into attr events") Signed-off-by: Namhyung Kim <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Ingo Molnar <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Tom Zanussi <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Thu Aug 17 09:11:21 2023 -0300 perf top: Don't pass an ERR_PTR() directly to perf_session__delete() [ Upstream commit ef23cb593304bde0cc046fd4cc83ae7ea2e24f16 ] While debugging a segfault on 'perf lock contention' without an available perf.data file I noticed that it was basically calling: perf_session__delete(ERR_PTR(-1)) Resulting in: (gdb) run lock contention Starting program: /root/bin/perf lock contention [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". failed to open perf.data: No such file or directory (try 'perf record' first) Initializing perf session failed Program received signal SIGSEGV, Segmentation fault. 0x00000000005e7515 in auxtrace__free (session=0xffffffffffffffff) at util/auxtrace.c:2858 2858 if (!session->auxtrace) (gdb) p session $1 = (struct perf_session *) 0xffffffffffffffff (gdb) bt #0 0x00000000005e7515 in auxtrace__free (session=0xffffffffffffffff) at util/auxtrace.c:2858 #1 0x000000000057bb4d in perf_session__delete (session=0xffffffffffffffff) at util/session.c:300 #2 0x000000000047c421 in __cmd_contention (argc=0, argv=0x7fffffffe200) at builtin-lock.c:2161 #3 0x000000000047dc95 in cmd_lock (argc=0, argv=0x7fffffffe200) at builtin-lock.c:2604 #4 0x0000000000501466 in run_builtin (p=0xe597a8 <commands+552>, argc=2, argv=0x7fffffffe200) at perf.c:322 #5 0x00000000005016d5 in handle_internal_command (argc=2, argv=0x7fffffffe200) at perf.c:375 #6 0x0000000000501824 in run_argv (argcp=0x7fffffffe02c, argv=0x7fffffffe020) at perf.c:419 #7 0x0000000000501b11 in main (argc=2, argv=0x7fffffffe200) at perf.c:535 (gdb) So just set it to NULL after using PTR_ERR(session) to decode the error as perf_session__delete(NULL) is supported. The same problem was found in 'perf top' after an audit of all perf_session__new() failure handling. Fixes: 6ef81c55a2b6584c ("perf session: Return error code for perf_session__new() function on failure") Cc: Adrian Hunter <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alexey Budankov <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Jeremie Galarneau <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Kate Stewart <[email protected]> Cc: Mamatha Inamdar <[email protected]> Cc: Mukesh Ojha <[email protected]> Cc: Nageswara R Sastry <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Ravi Bangoria <[email protected]> Cc: Shawn Landden <[email protected]> Cc: Song Liu <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Tzvetomir Stoyanov <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Wed Jul 19 15:37:14 2023 -0300 perf trace: Really free the evsel->priv area [ Upstream commit 7962ef13651a9163f07b530607392ea123482e8a ] In 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in evsel->priv") it only was freeing if strcmp(evsel->tp_format->system, "syscalls") returned zero, while the corresponding initialization of evsel->priv was being performed if it was _not_ zero, i.e. if the tp system wasn't 'syscalls'. Just stop looking for that and free it if evsel->priv was set, which should be equivalent. Also use the pre-existing evsel_trace__delete() function. This resolves these leaks, detected with: $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin ================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]# With this we plug all leaks with "perf trace sleep 1". Fixes: 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields in evsel->priv") Acked-by: Ian Rogers <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Riccardo Mancini <[email protected]> Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Wed Apr 12 09:50:08 2023 -0300 perf trace: Use zfree() to reduce chances of use after free [ Upstream commit 9997d5dd177c52017fa0541bf236a4232c8148e6 ] Do defensive programming by using zfree() to initialize freed pointers to NULL, so that eventual use after free result in a NULL pointer deref instead of more subtle behaviour. Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Stable-dep-of: 7962ef13651a ("perf trace: Really free the evsel->priv area") Signed-off-by: Sasha Levin <[email protected]>
Author: Kajol Jain <[email protected]> Date: Mon Aug 14 16:57:58 2023 +0530 perf vendor events: Drop some of the JSON/events for power10 platform [ Upstream commit e104df97b8dcfbab2e42de634b99bf03f0805d85 ] Drop some of the JSON/events for power10 platform due to counter data mismatch. Fixes: 32daa5d7899e0343 ("perf vendor events: Initial JSON/events list for power10 platform") Signed-off-by: Kajol Jain <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Disha Goel <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kajol Jain <[email protected]> Date: Mon Aug 14 16:57:57 2023 +0530 perf vendor events: Update the JSON/events descriptions for power10 platform [ Upstream commit 3286f88f31da060ac2789cee247153961ba57e49 ] Update the description for some of the JSON/events for power10 platform. Fixes: 32daa5d7899e0343 ("perf vendor events: Initial JSON/events list for power10 platform") Signed-off-by: Kajol Jain <[email protected]> Cc: Athira Rajeev <[email protected]> Cc: Disha Goel <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Kajol Jain <[email protected]> Cc: Madhavan Srinivasan <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Yang <[email protected]> Date: Fri Aug 11 09:54:38 2023 +0800 perf/imx_ddr: don't enable counter0 if none of 4 counters are used [ Upstream commit f4e2bd91ddf5e8543cbe7ad80b3fba3d2dc63fa3 ] In current driver, counter0 will be enabled after ddr_perf_pmu_enable() is called even though none of the 4 counters are used. This will cause counter0 continue to count until ddr_perf_pmu_disabled() is called. If pmu is not disabled all the time, the pmu interrupt will be asserted from time to time due to counter0 will overflow and irq handler will clear it. It's not an expected behavior. This patch will not enable counter0 if none of 4 counters are used. Fixes: 9a66d36cc7ac ("drivers/perf: imx_ddr: Add DDR performance counter support to perf") Signed-off-by: Xu Yang <[email protected]> Reviewed-by: Frank Li <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kan Liang <[email protected]> Date: Tue Sep 5 06:42:48 2023 -0700 perf/x86/uncore: Correct the number of CHAs on EMR commit 6f7f984fa85b305799076a1bcec941b9377587de upstream. Starting from SPR, the basic uncore PMON information is retrieved from the discovery table (resides in an MMIO space populated by BIOS). It is called the discovery method. The existing value of the type->num_boxes is from the discovery table. On some SPR variants, there is a firmware bug that makes the value from the discovery table incorrect. We use the value from the SPR_MSR_UNC_CBO_CONFIG MSR to replace the one from the discovery table: 38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR") Unfortunately, the SPR_MSR_UNC_CBO_CONFIG isn't available for the EMR XCC (Always returns 0), but the above firmware bug doesn't impact the EMR XCC. Don't let the value from the MSR replace the existing value from the discovery table. Fixes: 38776cc45eb7 ("perf/x86/uncore: Correct the number of CHAs on SPR") Reported-by: Stephane Eranian <[email protected]> Reported-by: Yunying Sun <[email protected]> Signed-off-by: Kan Liang <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Yunying Sun <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Thu Jun 15 17:10:21 2023 +0000 phy/rockchip: inno-hdmi: do not power on rk3328 post pll on reg write [ Upstream commit 19a1d46bd699940a496d3b0d4e142ef99834988c ] inno_write is used to configure 0xaa reg, that also hold the POST_PLL_POWER_DOWN bit. When POST_PLL_REFCLK_SEL_TMDS is configured the power down bit is not taken into consideration. Fix this by keeping the power down bit until configuration is complete. Also reorder the reg write order for consistency. Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Yang <[email protected]> Date: Thu Jun 15 17:10:19 2023 +0000 phy/rockchip: inno-hdmi: round fractal pixclock in rk3328 recalc_rate [ Upstream commit d5ef343c1d62bc4c4c2c393af654a41cb34b449f ] inno_hdmi_phy_rk3328_clk_recalc_rate() is returning a rate not found in the pre pll config table when the fractal divider is used. This can prevent proper power_on because a tmdsclock for the new rate is not found in the pre pll config table. Fix this by saving and returning a rounded pixel rate that exist in the pre pll config table. Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy") Signed-off-by: Zheng Yang <[email protected]> Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jonas Karlman <[email protected]> Date: Thu Jun 15 17:10:17 2023 +0000 phy/rockchip: inno-hdmi: use correct vco_div_5 macro on rk3328 [ Upstream commit 644c06dfbd0da713f772abf0a8f8581ac78e6264 ] inno_hdmi_phy_rk3328_clk_set_rate() is using the RK3228 macro when configuring vco_div_5 on RK3328. Fix this by using correct vco_div_5 macro for RK3328. Fixes: 53706a116863 ("phy: add Rockchip Innosilicon hdmi phy") Signed-off-by: Jonas Karlman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Adrien Thierry <[email protected]> Date: Thu Jun 29 10:45:40 2023 -0400 phy: qcom-snps-femto-v2: use qcom_snps_hsphy_suspend/resume error code [ Upstream commit 8932089b566c24ea19b57e37704c492678de1420 ] The return value from qcom_snps_hsphy_suspend/resume is not used. Make sure qcom_snps_hsphy_runtime_suspend/resume return this value as well. Signed-off-by: Adrien Thierry <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raag Jadav <[email protected]> Date: Tue Aug 22 12:53:40 2023 +0530 pinctrl: cherryview: fix address_space_handler() argument commit d5301c90716a8e20bc961a348182daca00c8e8f0 upstream. First argument of acpi_*_address_space_handler() APIs is acpi_handle of the device, which is incorrectly passed in driver ->remove() path here. Fix it by passing the appropriate argument and while at it, make both API calls consistent using ACPI_HANDLE(). Fixes: a0b028597d59 ("pinctrl: cherryview: Add support for GMMR GPIO opregion") Cc: [email protected] Signed-off-by: Raag Jadav <[email protected]> Acked-by: Mika Westerberg <[email protected]> Signed-off-by: Andy Shevchenko <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Claudiu Beznea <[email protected]> Date: Wed Jun 21 13:04:09 2023 +0300 pinctrl: mcp23s08: check return value of devm_kasprintf() [ Upstream commit f941714a7c7698eadb59bc27d34d6d6f38982705 ] devm_kasprintf() returns a pointer to dynamically allocated memory. Pointer could be NULL in case allocation fails. Check pointer validity. Identified with coccinelle (kmerr.cocci script). Fixes: 0f04a81784fe ("pinctrl: mcp23s08: Split to three parts: core, I²C, SPI") Signed-off-by: Claudiu Beznea <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shih-Yi Chen <[email protected]> Date: Mon Aug 21 11:06:27 2023 -0400 platform/mellanox: Fix mlxbf-tmfifo not handling all virtio CONSOLE notifications [ Upstream commit 0848cab765c634597636810bf76d0934003cce28 ] rshim console does not show all entries of dmesg. Fixed by setting MLXBF_TM_TX_LWM_IRQ for every CONSOLE notification. Signed-off-by: Shih-Yi Chen <[email protected]> Reviewed-by: Liming Sung <[email protected]> Reviewed-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shravan Kumar Ramani <[email protected]> Date: Tue Sep 5 08:49:32 2023 -0400 platform/mellanox: mlxbf-pmc: Fix potential buffer overflows [ Upstream commit 80ccd40568bcd3655b0fd0be1e9b3379fd6e1056 ] Replace sprintf with sysfs_emit where possible. Size check in mlxbf_pmc_event_list_show should account for "\0". Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Shravan Kumar Ramani <[email protected]> Reviewed-by: Vadim Pasternak <[email protected]> Reviewed-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/bef39ef32319a31b32f999065911f61b0d3b17c3.1693917738.git.shravankr@nvidia.com Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shravan Kumar Ramani <[email protected]> Date: Tue Sep 5 08:49:33 2023 -0400 platform/mellanox: mlxbf-pmc: Fix reading of unprogrammed events [ Upstream commit 0f5969452e162efc50bdc98968fb62b424a9874b ] This fix involves 2 changes: - All event regs have a reset value of 0, which is not a valid event_number as per the event_list for most blocks and hence seen as an error. Add a "disable" event with event_number 0 for all blocks. - The enable bit for each counter need not be checked before reading the event info, and hence removed. Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver") Signed-off-by: Shravan Kumar Ramani <[email protected]> Reviewed-by: Vadim Pasternak <[email protected]> Reviewed-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/04d0213932d32681de1c716b54320ed894e52425.1693917738.git.shravankr@nvidia.com Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liming Sun <[email protected]> Date: Tue Aug 29 13:43:00 2023 -0400 platform/mellanox: mlxbf-tmfifo: Drop jumbo frames [ Upstream commit fc4c655821546239abb3cf4274d66b9747aa87dd ] This commit drops over-sized network packets to avoid tmfifo queue stuck. Fixes: 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by: Liming Sun <[email protected]> Reviewed-by: Vadim Pasternak <[email protected]> Reviewed-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/9318936c2447f76db475c985ca6d91f057efcd41.1693322547.git.limings@nvidia.com Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Liming Sun <[email protected]> Date: Tue Aug 29 13:42:59 2023 -0400 platform/mellanox: mlxbf-tmfifo: Drop the Rx packet if no more descriptors [ Upstream commit 78034cbece79c2d730ad0770b3b7f23eedbbecf5 ] This commit fixes tmfifo console stuck issue when the virtual networking interface is in down state. In such case, the network Rx descriptors runs out and causes the Rx network packet staying in the head of the tmfifo thus blocking the console packets. The fix is to drop the Rx network packet when no more Rx descriptors. Function name mlxbf_tmfifo_release_pending_pkt() is also renamed to mlxbf_tmfifo_release_pkt() to be more approperiate. Fixes: 1357dfd7261f ("platform/mellanox: Add TmFifo driver for Mellanox BlueField Soc") Signed-off-by: Liming Sun <[email protected]> Reviewed-by: Vadim Pasternak <[email protected]> Reviewed-by: David Thompson <[email protected]> Link: https://lore.kernel.org/r/8c0177dc938ae03f52ff7e0b62dbeee74b7bec09.1693322547.git.limings@nvidia.com Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Maxim Mikityanskiy <[email protected]> Date: Sun Jul 16 21:32:13 2023 +0300 platform/x86/intel/hid: Add HP Dragonfly G2 to VGBS DMI quirks [ Upstream commit 7783e97f8558ad7a4d1748922461bc88483fbcdf ] HP Elite Dragonfly G2 (a convertible laptop/tablet) has a reliable VGBS method. If VGBS is not called on boot, the firmware sends an initial 0xcd event shortly after calling the BTNL method, but only if the device is booted in the laptop mode. However, if the device is booted in the tablet mode and VGBS is not called, there is no initial 0xcc event, and the input device for SW_TABLET_MODE is not registered up until the user turns the device into the laptop mode. Call VGBS on boot on this device to get the initial state of SW_TABLET_MODE in a reliable way. Tested with BIOS 1.13.1. Signed-off-by: Maxim Mikityanskiy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Armin Wolf <[email protected]> Date: Sat Aug 5 07:36:10 2023 +0200 platform/x86: dell-sysman: Fix reference leak [ Upstream commit 7295a996fdab7bf83dc3d4078fa8b139b8e0a1bf ] If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned. This means that we need to dispose it accordingly. Use kobject_put() to dispose the duplicate attribute in such a case. Compile-tested only. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Signed-off-by: Armin Wolf <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Konstantin Shelekhin <[email protected]> Date: Sat Jul 22 18:59:20 2023 +0300 platform/x86: huawei-wmi: Silence ambient light sensor [ Upstream commit c21733754cd6ecbca346f2adf9b17d4cfa50504f ] Currently huawei-wmi causes a lot of spam in dmesg on my Huawei MateBook X Pro 2022: ... [36409.328463] input input9: Unknown key pressed, code: 0x02c1 [36411.335104] input input9: Unknown key pressed, code: 0x02c1 [36412.338674] input input9: Unknown key pressed, code: 0x02c1 [36414.848564] input input9: Unknown key pressed, code: 0x02c1 [36416.858706] input input9: Unknown key pressed, code: 0x02c1 ... Fix that by ignoring events generated by ambient light sensor. This issue was reported on GitHub and resolved with the following merge request: https://github.com/aymanbagabas/Huawei-WMI/pull/70 I've contacted the mainter of this repo and he gave me the "go ahead" to send this patch to the maling list. Signed-off-by: Konstantin Shelekhin <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sat Jul 15 20:15:16 2023 +0200 platform/x86: intel: hid: Always call BTNL ACPI method [ Upstream commit e3ab18de2b09361d6f0e4aafb9cfd6d002ce43a1 ] On a HP Elite Dragonfly G2 the 0xcc and 0xcd events for SW_TABLET_MODE are only send after the BTNL ACPI method has been called. Likely more devices need this, so make the BTNL ACPI method unconditional instead of only doing it on devices with a 5 button array. Note this also makes the intel_button_array_enable() call in probe() unconditional, that function does its own priv->array check. This makes the intel_button_array_enable() call in probe() consistent with the calls done on suspend/resume which also rely on the priv->array check inside the function. Reported-by: Maxim Mikityanskiy <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Boris Brezillon <[email protected]> Date: Wed Aug 9 13:31:08 2023 +0200 PM / devfreq: Fix leak in devfreq_dev_release() commit 5693d077595de721f9ddbf9d37f40e5409707dfe upstream. srcu_init_notifier_head() allocates resources that need to be released with a srcu_cleanup_notifier_head() call. Reported by kmemleak. Fixes: 0fe3a66410a3 ("PM / devfreq: Add new DEVFREQ_TRANSITION_NOTIFIER notifier") Cc: <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Reviewed-by: Dhruva Gole <[email protected]> Signed-off-by: Chanwoo Choi <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Anna Schumaker <[email protected]> Date: Wed Aug 30 14:31:31 2023 -0400 pNFS: Fix assignment of xprtdata.cred [ Upstream commit c4a123d2e8c4dc91d581ee7d05c0cd51a0273fab ] The comma at the end of the line was leftover from an earlier refactor of the _nfs4_pnfs_v3_ds_connect() function. This is technically valid C, so the compilers didn't catch it, but if I'm understanding how it works correctly it assigns the return value of rpc_clnt_add_xprtr() to xprtdata.cred. Reported-by: Olga Kornievskaia <[email protected]> Fixes: a12f996d3413 ("NFSv4/pNFS: Use connections to a DS that are all of the same protocol family") Signed-off-by: Anna Schumaker <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sourabh Jain <[email protected]> Date: Tue Jul 4 10:37:15 2023 +0530 powerpc/fadump: reset dump area size if fadump memory reserve fails [ Upstream commit d1eb75e0dfed80d2d85b664e28a39f65b290ab55 ] In case fadump_reserve_mem() fails to reserve memory, the reserve_dump_area_size variable will retain the reserve area size. This will lead to /sys/kernel/fadump/mem_reserved node displaying an incorrect memory reserved by fadump. To fix this problem, reserve dump area size variable is set to 0 if fadump failed to reserve memory. Fixes: 8255da95e545 ("powerpc/fadump: release all the memory above boot memory size") Signed-off-by: Sourabh Jain <[email protected]> Acked-by: Mahesh Salgaonkar <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Russell Currey <[email protected]> Date: Wed Mar 22 14:53:22 2023 +1100 powerpc/iommu: Fix notifiers being shared by PCI and VIO buses [ Upstream commit c37b6908f7b2bd24dcaaf14a180e28c9132b9c58 ] fail_iommu_setup() registers the fail_iommu_bus_notifier struct to both PCI and VIO buses. struct notifier_block is a linked list node, so this causes any notifiers later registered to either bus type to also be registered to the other since they share the same node. This causes issues in (at least) the vgaarb code, which registers a notifier for PCI buses. pci_notify() ends up being called on a vio device, converted with to_pci_dev() even though it's not a PCI device, and finally makes a bad access in vga_arbiter_add_pci_device() as discovered with KASAN: BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00 Read of size 4 at addr c000000264c26fdc by task swapper/0/1 Call Trace: dump_stack_lvl+0x1bc/0x2b8 (unreliable) print_report+0x3f4/0xc60 kasan_report+0x244/0x698 __asan_load4+0xe8/0x250 vga_arbiter_add_pci_device+0x60/0xe00 pci_notify+0x88/0x444 notifier_call_chain+0x104/0x320 blocking_notifier_call_chain+0xa0/0x140 device_add+0xac8/0x1d30 device_register+0x58/0x80 vio_register_device_node+0x9ac/0xce0 vio_bus_scan_register_devices+0xc4/0x13c __machine_initcall_pseries_vio_device_init+0x94/0xf0 do_one_initcall+0x12c/0xaa8 kernel_init_freeable+0xa48/0xba8 kernel_init+0x64/0x400 ret_from_kernel_thread+0x5c/0x64 Fix this by creating separate notifier_block structs for each bus type. Fixes: d6b9a81b2a45 ("powerpc: IOMMU fault injection") Reported-by: Nageswara R Sastry <[email protected]> Signed-off-by: Russell Currey <[email protected]> Tested-by: Nageswara R Sastry <[email protected]> Reviewed-by: Andrew Donnellan <[email protected]> [mpe: Add #ifdef to fix CONFIG_IBMVIO=n build] Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Fri Aug 18 10:59:44 2023 +0200 powerpc/perf: Convert fsl_emb notifier to state machine callbacks [ Upstream commit 34daf445f82bd3a4df852bb5f1dffd792ac830a0 ] CC arch/powerpc/perf/core-fsl-emb.o arch/powerpc/perf/core-fsl-emb.c:675:6: error: no previous prototype for 'hw_perf_event_setup' [-Werror=missing-prototypes] 675 | void hw_perf_event_setup(int cpu) | ^~~~~~~~~~~~~~~~~~~ Looks like fsl_emb was completely missed by commit 3f6da3905398 ("perf: Rework and fix the arch CPU-hotplug hooks") So, apply same changes as commit 3f6da3905398 ("perf: Rework and fix the arch CPU-hotplug hooks") then commit 57ecde42cc74 ("powerpc/perf: Convert book3s notifier to state machine callbacks") While at it, also fix following error: arch/powerpc/perf/core-fsl-emb.c: In function 'perf_event_interrupt': arch/powerpc/perf/core-fsl-emb.c:648:13: error: variable 'found' set but not used [-Werror=unused-but-set-variable] 648 | int found = 0; | ^~~~~ Fixes: 3f6da3905398 ("perf: Rework and fix the arch CPU-hotplug hooks") Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/603e1facb32608f88f40b7d7b9094adc50e7b2dc.1692349125.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]>
Author: Russell Currey <[email protected]> Date: Wed Aug 23 15:53:17 2023 +1000 powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT [ Upstream commit eac030b22ea12cdfcbb2e941c21c03964403c63f ] lppaca_shared_proc() takes a pointer to the lppaca which is typically accessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leads to checking if preemption is enabled, for example: BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693 caller is lparcfg_data+0x408/0x19a0 CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2 Call Trace: dump_stack_lvl+0x154/0x200 (unreliable) check_preemption_disabled+0x214/0x220 lparcfg_data+0x408/0x19a0 ... This isn't actually a problem however, as it does not matter which lppaca is accessed, the shared proc state will be the same. vcpudispatch_stats_procfs_init() already works around this by disabling preemption, but the lparcfg code does not, erroring any time /proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled. Instead of disabling preemption on the caller side, rework lppaca_shared_proc() to not take a pointer and instead directly access the lppaca, bypassing any potential preemption checks. Fixes: f13c13a00512 ("powerpc: Stop using non-architected shared_proc field in lppaca") Signed-off-by: Russell Currey <[email protected]> [mpe: Rework to avoid needing a definition in paca.h and lppaca.h] Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Christophe Leroy <[email protected]> Date: Wed Aug 9 10:01:43 2023 +0200 powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE [ Upstream commit 4a9dd8f292efd614f0a18452e6474fe19ae17b47 ] With skiboot_defconfig, Clang reports: CC arch/powerpc/mm/book3s64/radix_tlb.o arch/powerpc/mm/book3s64/radix_tlb.c:419:20: error: unused function '_tlbie_pid_lpid' [-Werror,-Wunused-function] static inline void _tlbie_pid_lpid(unsigned long pid, unsigned long lpid, ^ arch/powerpc/mm/book3s64/radix_tlb.c:663:20: error: unused function '_tlbie_va_range_lpid' [-Werror,-Wunused-function] static inline void _tlbie_va_range_lpid(unsigned long start, unsigned long end, ^ This is because those functions are only called from functions enclosed in a #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE Move below functions inside that #ifdef * __tlbie_pid_lpid(unsigned long pid, * __tlbie_va_lpid(unsigned long va, unsigned long pid, * fixup_tlbie_pid_lpid(unsigned long pid, unsigned long lpid) * _tlbie_pid_lpid(unsigned long pid, unsigned long lpid, * fixup_tlbie_va_range_lpid(unsigned long va, * __tlbie_va_range_lpid(unsigned long start, unsigned long end, * _tlbie_va_range_lpid(unsigned long start, unsigned long end, Fixes: f0c6fbbb9050 ("KVM: PPC: Book3S HV: Add support for H_RPT_INVALIDATE") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Christophe Leroy <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/3d72efd39f986ee939d068af69fdce28bd600766.1691568093.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Ellerman <[email protected]> Date: Wed Aug 23 15:53:16 2023 +1000 powerpc: Don't include lppaca.h in paca.h [ Upstream commit 1aa000667669fa855853decbb1c69e974d8ff716 ] By adding a forward declaration for struct lppaca we can untangle paca.h and lppaca.h. Also move get_lppaca() into lppaca.h for consistency. Add includes of lppaca.h to some files that need it. Signed-off-by: Michael Ellerman <[email protected]> Link: https://msgid.link/[email protected] Stable-dep-of: eac030b22ea1 ("powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPT") Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Thu Aug 10 22:45:32 2023 -0700 printk: ringbuffer: Fix truncating buffer size min_t cast commit 53e9e33ede37a247d926db5e4a9e56b55204e66c upstream. If an output buffer size exceeded U16_MAX, the min_t(u16, ...) cast in copy_data() was causing writes to truncate. This manifested as output bytes being skipped, seen as %NUL bytes in pstore dumps when the available record size was larger than 65536. Fix the cast to no longer truncate the calculation. Cc: Petr Mladek <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: John Ogness <[email protected]> Reported-by: Vijay Balakrishna <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: b6cf8b3f3312 ("printk: add lockless ringbuffer") Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Tested-by: Vijay Balakrishna <[email protected]> Tested-by: Guilherme G. Piccoli <[email protected]> # Steam Deck Reviewed-by: Tyler Hicks (Microsoft) <[email protected]> Tested-by: Tyler Hicks (Microsoft) <[email protected]> Reviewed-by: John Ogness <[email protected]> Reviewed-by: Sergey Senozhatsky <[email protected]> Reviewed-by: Petr Mladek <[email protected]> Signed-off-by: Petr Mladek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Aleksa Sarai <[email protected]> Date: Fri Jul 14 00:09:58 2023 +1000 procfs: block chmod on /proc/thread-self/comm commit ccf61486fe1e1a48e18c638d1813cda77b3c0737 upstream. Due to an oversight in commit 1b3044e39a89 ("procfs: fix pthread cross-thread naming if !PR_DUMPABLE") in switching from REG to NOD, chmod operations on /proc/thread-self/comm were no longer blocked as they are on almost all other procfs files. A very similar situation with /proc/self/environ was used to as a root exploit a long time ago, but procfs has SB_I_NOEXEC so this is simply a correctness issue. Ref: https://lwn.net/Articles/191954/ Ref: 6d76fa58b050 ("Don't allow chmod() on the /proc/<pid>/ files") Fixes: 1b3044e39a89 ("procfs: fix pthread cross-thread naming if !PR_DUMPABLE") Cc: [email protected] # v4.7+ Signed-off-by: Aleksa Sarai <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Enlin Mu <[email protected]> Date: Tue Aug 1 14:04:32 2023 +0800 pstore/ram: Check start of empty przs during init commit fe8c3623ab06603eb760444a032d426542212021 upstream. After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as valid"), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to: sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ... To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start > size) and zap the buffer back to a sane state. Fixes: 30696378f68a ("pstore/ram: Do not treat empty buffers as valid") Cc: Yunlong Xing <[email protected]> Cc: [email protected] Signed-off-by: Enlin Mu <[email protected]> Link: https://lore.kernel.org/r/[email protected] [kees: update commit log with backtrace and clarifications] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Fri Mar 3 19:54:17 2023 +0100 pwm: atmel-tcb: Convert to platform remove callback returning void [ Upstream commit 9609284a76978daf53a54e05cff36873a75e4d13 ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Stable-dep-of: c11622324c02 ("pwm: atmel-tcb: Fix resource freeing in error path and remove") Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Wed Jul 19 21:20:10 2023 +0200 pwm: atmel-tcb: Fix resource freeing in error path and remove [ Upstream commit c11622324c023415fb69196c5fc3782d2b8cced0 ] Several resources were not freed in the error path and the remove function. Add the forgotten items. Fixes: 34cbcd72588f ("pwm: atmel-tcb: Add sama5d2 support") Fixes: 061f8572a31c ("pwm: atmel-tcb: Switch to new binding") Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Claudiu Beznea <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Uwe Kleine-König <[email protected]> Date: Wed Jul 19 21:20:09 2023 +0200 pwm: atmel-tcb: Harmonize resource allocation order [ Upstream commit 0323e8fedd1ef25342cf7abf3a2024f5670362b8 ] Allocate driver data as first resource in the probe function. This way it can be used during allocation of the other resources (instead of assigning these to local variables first and update driver data only when it's allocated). Also as driver data is allocated using a devm function this should happen first to have the order of freeing resources in the error path and the remove function in reverse. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Stable-dep-of: c11622324c02 ("pwm: atmel-tcb: Fix resource freeing in error path and remove") Signed-off-by: Sasha Levin <[email protected]>
Author: Vladimir Zapolskiy <[email protected]> Date: Mon Jul 17 17:52:57 2023 +0200 pwm: lpc32xx: Remove handling of PWM channels [ Upstream commit 4aae44f65827f0213a7361cf9c32cfe06114473f ] Because LPC32xx PWM controllers have only a single output which is registered as the only PWM device/channel per controller, it is known in advance that pwm->hwpwm value is always 0. On basis of this fact simplify the code by removing operations with pwm->hwpwm, there is no controls which require channel number as input. Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL before devm_pwmchip_add() is called. Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Vladimir Zapolskiy <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Fixes: 3d2813fb17e5 ("pwm: lpc32xx: Don't modify HW state in .probe() after the PWM chip was registered") Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Fri Jun 30 19:08:20 2023 +0800 quota: add new helper dquot_active() [ Upstream commit 33bcfafc48cb186bc4bbcea247feaa396594229e ] Add new helper function dquot_active() to make the code more concise. Signed-off-by: Baokun Li <[email protected]> Signed-off-by: Jan Kara <[email protected]> Message-Id: <[email protected]> Stable-dep-of: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Fri Jun 30 19:08:18 2023 +0800 quota: factor out dquot_write_dquot() [ Upstream commit 024128477809f8073d870307c8157b8826ebfd08 ] Refactor out dquot_write_dquot() to reduce duplicate code. Signed-off-by: Baokun Li <[email protected]> Signed-off-by: Jan Kara <[email protected]> Message-Id: <[email protected]> Stable-dep-of: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Fri Jun 30 19:08:21 2023 +0800 quota: fix dqput() to follow the guarantees dquot_srcu should provide [ Upstream commit dabc8b20756601b9e1cc85a81d47d3f98ed4d13a ] The dquot_mark_dquot_dirty() using dquot references from the inode should be protected by dquot_srcu. quota_off code takes care to call synchronize_srcu(&dquot_srcu) to not drop dquot references while they are used by other users. But dquot_transfer() breaks this assumption. We call dquot_transfer() to drop the last reference of dquot and add it to free_dquots, but there may still be other users using the dquot at this time, as shown in the function graph below: cpu1 cpu2 _________________|_________________ wb_do_writeback CHOWN(1) ... ext4_da_update_reserve_space dquot_claim_block ... dquot_mark_dquot_dirty // try to dirty old quota test_bit(DQ_ACTIVE_B, &dquot->dq_flags) // still ACTIVE if (test_bit(DQ_MOD_B, &dquot->dq_flags)) // test no dirty, wait dq_list_lock ... dquot_transfer __dquot_transfer dqput_all(transfer_from) // rls old dquot dqput // last dqput dquot_release clear_bit(DQ_ACTIVE_B, &dquot->dq_flags) atomic_dec(&dquot->dq_count) put_dquot_last(dquot) list_add_tail(&dquot->dq_free, &free_dquots) // add the dquot to free_dquots if (!test_and_set_bit(DQ_MOD_B, &dquot->dq_flags)) add dqi_dirty_list // add released dquot to dirty_list This can cause various issues, such as dquot being destroyed by dqcache_shrink_scan() after being added to free_dquots, which can trigger a UAF in dquot_mark_dquot_dirty(); or after dquot is added to free_dquots and then to dirty_list, it is added to free_dquots again after dquot_writeback_dquots() is executed, which causes the free_dquots list to be corrupted and triggers a UAF when dqcache_shrink_scan() is called for freeing dquot twice. As Honza said, we need to fix dquot_transfer() to follow the guarantees dquot_srcu should provide. But calling synchronize_srcu() directly from dquot_transfer() is too expensive (and mostly unnecessary). So we add dquot whose last reference should be dropped to the new global dquot list releasing_dquots, and then queue work item which would call synchronize_srcu() and after that perform the final cleanup of all the dquots on releasing_dquots. Fixes: 4580b30ea887 ("quota: Do not dirty bad dquots") Suggested-by: Jan Kara <[email protected]> Signed-off-by: Baokun Li <[email protected]> Signed-off-by: Jan Kara <[email protected]> Message-Id: <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Baokun Li <[email protected]> Date: Fri Jun 30 19:08:19 2023 +0800 quota: rename dquot_active() to inode_quota_active() [ Upstream commit 4b9bdfa16535de8f49bf954aeed0f525ee2fc322 ] Now we have a helper function dquot_dirty() to determine if dquot has DQ_MOD_B bit. dquot_active() can easily be misunderstood as a helper function to determine if dquot has DQ_ACTIVE_B bit. So we avoid this by renaming it to inode_quota_active() and later on we will add the helper function dquot_active() to determine if dquot has DQ_ACTIVE_B bit. Signed-off-by: Baokun Li <[email protected]> Signed-off-by: Jan Kara <[email protected]> Message-Id: <[email protected]> Stable-dep-of: dabc8b207566 ("quota: fix dqput() to follow the guarantees dquot_srcu should provide") Signed-off-by: Sasha Levin <[email protected]>
Author: Hayes Wang <[email protected]> Date: Fri Sep 8 15:01:52 2023 +0800 r8152: check budget for r8152_poll() [ Upstream commit a7b8d60b37237680009dd0b025fe8c067aba0ee3 ] According to the document of napi, there is no rx process when the budget is 0. Therefore, r8152_poll() has to return 0 directly when the budget is equal to 0. Fixes: d2187f8e4454 ("r8152: divide the tx and rx bottom functions") Signed-off-by: Hayes Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zqiang <[email protected]> Date: Mon Sep 4 18:08:05 2023 +0000 rcu: dump vmalloc memory info safely commit c83ad36a18c02c0f51280b50272327807916987f upstream. Currently, for double invoke call_rcu(), will dump rcu_head objects memory info, if the objects is not allocated from the slab allocator, the vmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to be held, since the call_rcu() can be invoked in interrupt context, therefore, there is a possibility of spinlock deadlock scenarios. And in Preempt-RT kernel, the rcutorture test also trigger the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 3 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70 irq event stamp: 565512 hardirqs last enabled at (565511): [<ffffffffb379b138>] __call_rcu_common+0x218/0x940 hardirqs last disabled at (565512): [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370 softirqs last enabled at (399112): [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170 softirqs last disabled at (399106): [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0 Preemption disabled at: [<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370 CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> The previous patch fixes this by using the deadlock-safe best-effort version of find_vm_area. However, in case of failure print the fact that the pointer was a vmalloc pointer so that we print at least something. Link: https://lkml.kernel.org/r/[email protected] Fixes: 98f180837a89 ("mm: Make mem_dump_obj() handle vmalloc() memory") Signed-off-by: Zqiang <[email protected]> Signed-off-by: Joel Fernandes (Google) <[email protected]> Reported-by: Zhen Lei <[email protected]> Reviewed-by: Matthew Wilcox (Oracle) <[email protected]> Cc: Paul E. McKenney <[email protected]> Cc: Uladzislau Rezki (Sony) <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Chengchang Tang <[email protected]> Date: Fri Aug 4 09:27:11 2023 +0800 RDMA/hns: Fix CQ and QP cache affinity [ Upstream commit 9e03dbea2b0634b21a45946b4f8097e0dc86ebe1 ] Currently, the affinity between QP cache and CQ cache is not considered when assigning QPN, it will affect the message rate of HW. Allocate QPN from QP cache with better CQ affinity to get better performance. Fixes: 71586dd20010 ("RDMA/hns: Create QP with selected QPN for bank load balance") Signed-off-by: Chengchang Tang <[email protected]> Signed-off-by: Junxian Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Junxian Huang <[email protected]> Date: Fri Aug 4 09:27:09 2023 +0800 RDMA/hns: Fix incorrect post-send with direct wqe of wr-list [ Upstream commit 706efac4477cdb8be857f6322457de524acc02ff ] Currently, direct wqe is not supported for wr-list. RoCE driver excludes direct wqe for wr-list by judging whether the number of wr is 1. For a wr-list where the second wr is a length-error atomic wr, the post-send driver handles the first wr and adds 1 to the wr number counter firstly. While handling the second wr, the driver finds out a length error and terminates the wr handle process, remaining the counter at 1. This causes the driver mistakenly judges there is only 1 wr and thus enters the direct wqe process, carrying the current length-error atomic wqe. This patch fixes the error by adding a judgement whether the current wr is a bad wr. If so, use the normal doorbell process but not direct wqe despite the wr number is 1. Fixes: 01584a5edcc4 ("RDMA/hns: Add support of direct wqe") Signed-off-by: Junxian Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengchang Tang <[email protected]> Date: Fri Aug 4 09:27:08 2023 +0800 RDMA/hns: Fix port active speed [ Upstream commit df1bcf90a66a10967a3a43510b42cb3566208011 ] HW supports a variety of different speed, but the current speed is fixed. The real speed should be querried from ethernet. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by: Chengchang Tang <[email protected]> Signed-off-by: Junxian Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Gustavo A. R. Silva <[email protected]> Date: Wed Aug 2 08:46:26 2023 -0600 RDMA/irdma: Replace one-element array with flexible-array member [ Upstream commit 38313c6d2a02c28162e06753b01bd885caf9386d ] One-element and zero-length arrays are deprecated. So, replace one-element array in struct irdma_qvlist_info with flexible-array member. A patch for this was sent a while ago[1]. However, it seems that, at the time, the changes were partially folded[2][3], and the actual flexible-array transformation was omitted. This patch fixes that. The only binary difference seen before/after changes is shown below: | drivers/infiniband/hw/irdma/hw.o | @@ -868,7 +868,7 @@ | drivers/infiniband/hw/irdma/hw.c:484 (discriminator 2) | size += struct_size(iw_qvlist, qv_info, rf->msix_count); | 55b: imul $0x45c,%rdi,%rdi |- 562: add $0x10,%rdi |+ 562: add $0x4,%rdi which is, of course, expected as it reflects the mistake made while folding the patch I've mentioned above. Worth mentioning is the fact that with this change we save 12 bytes of memory, as can be inferred from the diff snapshot above. Notice that: $ pahole -C rdma_qv_info idrivers/infiniband/hw/irdma/hw.o struct irdma_qv_info { u32 v_idx; /* 0 4 */ u16 ceq_idx; /* 4 2 */ u16 aeq_idx; /* 6 2 */ u8 itr_idx; /* 8 1 */ /* size: 12, cachelines: 1, members: 4 */ /* padding: 3 */ /* last cacheline: 12 bytes */ }; Link: https://lore.kernel.org/linux-hardening/20210525230038.GA175516@embeddedor/ [1] Link: https://lore.kernel.org/linux-hardening/[email protected]/ [2] Link: https://lore.kernel.org/linux-rdma/[email protected]/T/#u [3] Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/ZMpsQrZadBaJGkt4@work Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Minjie Du <[email protected]> Date: Thu Jul 6 10:27:03 2023 +0800 RDMA/qedr: Remove a duplicate assignment in irdma_query_ah() [ Upstream commit 65e02e840847158c7ee48ca8e6e91062b0f78662 ] Delete a duplicate statement from this function implementation. Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Signed-off-by: Minjie Du <[email protected]> Acked-by: Alok Prasad <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Waiman Long <[email protected]> Date: Fri Jul 7 13:53:55 2023 -0400 refscale: Fix uninitalized use of wait_queue_head_t [ Upstream commit f5063e8948dad7f31adb007284a5d5038ae31bb8 ] Running the refscale test occasionally crashes the kernel with the following error: [ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8 [ 8569.952900] #PF: supervisor read access in kernel mode [ 8569.952902] #PF: error_code(0x0000) - not-present page [ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0 [ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI [ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021 [ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 : [ 8569.952940] Call Trace: [ 8569.952941] <TASK> [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale] [ 8569.952959] kthread+0x10e/0x130 [ 8569.952966] ret_from_fork+0x1f/0x30 [ 8569.952973] </TASK> The likely cause is that init_waitqueue_head() is called after the call to the torture_create_kthread() function that creates the ref_scale_reader kthread. Although this init_waitqueue_head() call will very likely complete before this kthread is created and starts running, it is possible that the calling kthread will be delayed between the calls to torture_create_kthread() and init_waitqueue_head(). In this case, the new kthread will use the waitqueue head before it is properly initialized, which is not good for the kernel's health and well-being. The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash here The offset of flags from list_head entry in wait_queue_entry is -0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_task structure is zero initialized, the instruction will try to access address 0xffffffffffffffe8, which is exactly the fault address listed above. This commit therefore invokes init_waitqueue_head() before creating the kthread. Fixes: 653ed64b01dc ("refperf: Add a test to measure performance of read-side synchronization") Signed-off-by: Waiman Long <[email protected]> Reviewed-by: Qiuxu Zhuo <[email protected]> Reviewed-by: Davidlohr Bueso <[email protected]> Acked-by: Joel Fernandes (Google) <[email protected]> Signed-off-by: Paul E. McKenney <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jul 21 17:55:33 2023 +0300 regmap: rbtree: Use alloc_flags for memory allocations [ Upstream commit 0c8b0bf42c8cef56f7cd9cd876fbb7ece9217064 ] The kunit tests discovered a sleeping in atomic bug. The allocations in the regcache-rbtree code should use the map->alloc_flags instead of GFP_KERNEL. [ 5.005510] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306 [ 5.005960] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 117, name: kunit_try_catch [ 5.006219] preempt_count: 1, expected: 0 [ 5.006414] 1 lock held by kunit_try_catch/117: [ 5.006590] #0: 833b9010 (regmap_kunit:86:(config)->lock){....}-{2:2}, at: regmap_lock_spinlock+0x14/0x1c [ 5.007493] irq event stamp: 162 [ 5.007627] hardirqs last enabled at (161): [<80786738>] crng_make_state+0x1a0/0x294 [ 5.007871] hardirqs last disabled at (162): [<80c531ec>] _raw_spin_lock_irqsave+0x7c/0x80 [ 5.008119] softirqs last enabled at (0): [<801110ac>] copy_process+0x810/0x2138 [ 5.008356] softirqs last disabled at (0): [<00000000>] 0x0 [ 5.008688] CPU: 0 PID: 117 Comm: kunit_try_catch Tainted: G N 6.4.4-rc3-g0e8d2fdfb188 #1 [ 5.009011] Hardware name: Generic DT based system [ 5.009277] unwind_backtrace from show_stack+0x18/0x1c [ 5.009497] show_stack from dump_stack_lvl+0x38/0x5c [ 5.009676] dump_stack_lvl from __might_resched+0x188/0x2d0 [ 5.009860] __might_resched from __kmem_cache_alloc_node+0x1dc/0x25c [ 5.010061] __kmem_cache_alloc_node from kmalloc_trace+0x30/0xc8 [ 5.010254] kmalloc_trace from regcache_rbtree_write+0x26c/0x468 [ 5.010446] regcache_rbtree_write from _regmap_write+0x88/0x140 [ 5.010634] _regmap_write from regmap_write+0x44/0x68 [ 5.010803] regmap_write from basic_read_write+0x8c/0x270 [ 5.010980] basic_read_write from kunit_try_run_case+0x48/0xa0 Fixes: 28644c809f44 ("regmap: Add the rbtree cache support") Reported-by: Guenter Roeck <[email protected]> Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Dan Carpenter <[email protected]> Tested-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Matthew Wilcox <[email protected]> Date: Sun Jun 4 12:16:06 2023 +0100 reiserfs: Check the return value from __getblk() [ Upstream commit ba38980add7ffc9e674ada5b4ded4e7d14e76581 ] __getblk() can return a NULL pointer if we run out of memory or if we try to access beyond the end of the device; check it and handle it appropriately. Signed-off-by: Matthew Wilcox (Oracle) <[email protected]> Link: https://lore.kernel.org/lkml/CAFcO6XOacq3hscbXevPQP7sXRoYFz34ZdKPYjmd6k5sZuhGFDw@mail.gmail.com/ Tested-by: butt3rflyh4ck <[email protected]> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") # probably introduced in 2002 Acked-by: Edward Shishkin <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Greg Kroah-Hartman <[email protected]> Date: Tue Sep 12 13:28:47 2023 +0200 Revert "drm/amdgpu: install stub fence into potential unused fence pointers" This reverts commit 4921792e04f2125b5eadef9dbe9417a8354c7eff which is commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 upstream. It is reported to cause a lot of log spam, so should be reverted. Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/BL1PR12MB5144A0E84378A2666A26AE18F7F2A@BL1PR12MB5144.namprd12.prod.outlook.com Reported-by: Bryan Jennings <[email protected]> Reported-by: Alexander Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: Lang Yu <[email protected]> Cc: Alex Deucher <[email protected]> Cc: Sasha Levin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Leon Romanovsky <[email protected]> Date: Mon Aug 21 10:57:14 2023 +0300 Revert "IB/isert: Fix incorrect release of isert connection" [ Upstream commit dfe261107c080709459c32695847eec96238852b ] Commit: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") is causing problems on OPA when DEVICE_REMOVAL is happening. ------------[ cut here ]------------ WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359 ib_cq_pool_cleanup+0xac/0xb0 [ib_core] Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfc scsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_file rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_mod opa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cm ib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_core x86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdt ipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdma intel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahci ghash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1 Hardware name: Intel Corporation S2600CWR/S2600CW, BIOS SE5C610.86B.01.01.0014.121820151719 12/18/2015 RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core] Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83 c4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b eb a1 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206 RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640 RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18 R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38 FS: 00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0 Call Trace: <TASK> ? __warn+0x80/0x130 ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core] ? report_bug+0x195/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core] disable_device+0x9d/0x160 [ib_core] __ib_unregister_device+0x42/0xb0 [ib_core] ib_unregister_device+0x22/0x30 [ib_core] rvt_unregister_device+0x20/0x90 [rdmavt] hfi1_unregister_ib_device+0x16/0xf0 [hfi1] remove_one+0x55/0x1a0 [hfi1] pci_device_remove+0x36/0xa0 device_release_driver_internal+0x193/0x200 driver_detach+0x44/0x90 bus_remove_driver+0x69/0xf0 pci_unregister_driver+0x2a/0xb0 hfi1_mod_cleanup+0xc/0x3c [hfi1] __do_sys_delete_module.constprop.0+0x17a/0x2f0 ? exit_to_user_mode_prepare+0xc4/0xd0 ? syscall_trace_enter.constprop.0+0x126/0x1a0 do_syscall_64+0x5c/0x90 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? exc_page_fault+0x65/0x150 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7ff1e643f5ab Code: 73 01 c3 48 8b 0d 75 a8 1b 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 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8 RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000 R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8 R13: 0000000000000000 R14: 00005615267fdcb8 R15: 00007ffec9105ff8 </TASK> ---[ end trace 0000000000000000 ]--- And... restrack: ------------[ cut here ]------------ infiniband hfi1_0: BUG: RESTRACK detected leak of resources restrack: Kernel PD object allocated by ib_isert is not freed restrack: Kernel CQ object allocated by ib_core is not freed restrack: Kernel QP object allocated by rdma_cm is not freed restrack: ------------[ cut here ]------------ Fixes: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") Reported-by: Dennis Dalessandro <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Link: https://lore.kernel.org/r/a27982d3235005c58f6d321f3fad5eb6e1beaf9e.1692604607.git.leonro@nvidia.com Tested-by: Dennis Dalessandro <[email protected]> Signed-off-by: Leon Romanovsky <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sabrina Dubroca <[email protected]> Date: Mon Sep 4 10:56:04 2023 +0200 Revert "net: macsec: preserve ingress frame ordering" commit d3287e4038ca4f81e02067ab72d087af7224c68b upstream. This reverts commit ab046a5d4be4c90a3952a0eae75617b49c0cb01b. It was trying to work around an issue at the crypto layer by excluding ASYNC implementations of gcm(aes), because a bug in the AESNI version caused reordering when some requests bypassed the cryptd queue while older requests were still pending on the queue. This was fixed by commit 38b2f68b4264 ("crypto: aesni - Fix cryptd reordering problem on gcm"), which pre-dates ab046a5d4be4. Herbert Xu confirmed that all ASYNC implementations are expected to maintain the ordering of completions wrt requests, so we can use them in MACsec. On my test machine, this restores the performance of a single netperf instance, from 1.4Gbps to 4.4Gbps. Link: https://lore.kernel.org/netdev/9328d206c5d9f9239cae27e62e74de40b258471d.1692279161.git.sd@queasysnail.net/T/ Link: https://lore.kernel.org/netdev/[email protected]/ Link: https://lore.kernel.org/netdev/[email protected]/ Fixes: ab046a5d4be4 ("net: macsec: preserve ingress frame ordering") Signed-off-by: Sabrina Dubroca <[email protected]> Link: https://lore.kernel.org/r/11c952469d114db6fb29242e1d9545e61f52f512.1693757159.git.sd@queasysnail.net Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Bjorn Helgaas <[email protected]> Date: Fri Sep 8 14:55:30 2023 -0500 Revert "PCI: Mark NVIDIA T4 GPUs to avoid bus reset" commit 5260bd6d36c83c5b269c33baaaf8c78e520908b0 upstream. This reverts commit d5af729dc2071273f14cbb94abbc60608142fd83. d5af729dc207 ("PCI: Mark NVIDIA T4 GPUs to avoid bus reset") avoided Secondary Bus Reset on the T4 because the reset seemed to not work when the T4 was directly attached to a Root Port. But NVIDIA thinks the issue is probably related to some issue with the Root Port, not with the T4. The T4 provides neither PM nor FLR reset, so masking bus reset compromises this device for assignment scenarios. Revert d5af729dc207 as requested by Wu Zongyong. This will leave SBR broken in the specific configuration Wu tested, as it was in v6.5, so Wu will debug that further. Link: https://lore.kernel.org/r/ZPqMCDWvITlOLHgJ@wuzongyong-alibaba Link: https://lore.kernel.org/r/20230908201104.GA305023@bhelgaas Signed-off-by: Bjorn Helgaas <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nilesh Javali <[email protected]> Date: Mon Aug 21 18:30:44 2023 +0530 Revert "scsi: qla2xxx: Fix buffer overrun" commit 641671d97b9199f1ba35ccc2222d4b189a6a5de5 upstream. Revert due to Get PLOGI Template failed. This reverts commit b68710a8094fdffe8dd4f7a82c82649f479bb453. Cc: [email protected] Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jiasheng Jiang <[email protected]> Date: Mon Jun 19 11:06:31 2023 +0800 rpmsg: glink: Add check for kstrdup [ Upstream commit b5c9ee8296a3760760c7b5d2e305f91412adc795 ] Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver") Signed-off-by: Jiasheng Jiang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Haberland <[email protected]> Date: Fri Jul 21 21:36:46 2023 +0200 s390/dasd: fix hanging device after request requeue [ Upstream commit 8a2278ce9c25048d999fe1a3561def75d963f471 ] The DASD device driver has a function to requeue requests to the blocklayer. This function is used in various cases when basic settings for the device have to be changed like High Performance Ficon related parameters or copy pair settings. The functions iterates over the device->ccw_queue and also removes the requests from the block->ccw_queue. In case the device is started on an alias device instead of the base device it might be removed from the block->ccw_queue without having it canceled properly before. This might lead to a hanging device since the request is no longer on a queue and can not be handled properly. Fix by iterating over the block->ccw_queue instead of the device->ccw_queue. This will take care of all blocklayer related requests and handle them on all associated DASD devices. Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Haberland <[email protected]> Date: Fri Jul 21 21:36:45 2023 +0200 s390/dasd: use correct number of retries for ERP requests [ Upstream commit acea28a6b74f458defda7417d2217b051ba7d444 ] If a DASD request fails an error recovery procedure (ERP) request might be built as a copy of the original request to do error recovery. The ERP request gets a number of retries assigned. This number is always 256 no matter what other value might have been set for the original request. This is not what is expected when a user specifies a certain amount of retries for the device via sysfs. Correctly use the number of retries of the original request for ERP requests. Signed-off-by: Stefan Haberland <[email protected]> Reviewed-by: Jan Hoeppner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jens Axboe <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sven Schnelle <[email protected]> Date: Tue Aug 15 09:26:06 2023 +0200 s390/ipl: add missing secure/has_secure file to ipl type 'unknown' commit ea5717cb13468323a7c3dd394748301802991f39 upstream. OS installers are relying on /sys/firmware/ipl/has_secure to be present on machines supporting secure boot. This file is present for all IPL types, but not the unknown type, which prevents a secure installation when an LPAR is booted in HMC via FTP(s), because this is an unknown IPL type in linux. While at it, also add the secure file. Fixes: c9896acc7851 ("s390/ipl: Provide has_secure sysfs attribute") Cc: [email protected] Signed-off-by: Sven Schnelle <[email protected]> Reviewed-by: Heiko Carstens <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Holger Dengler <[email protected]> Date: Wed Aug 9 14:23:45 2023 +0200 s390/paes: fix PKEY_TYPE_EP11_AES handling for secure keyblobs [ Upstream commit cba33db3fc4dbf2e54294b0e499d2335a3a00d78 ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES securekey blobs as a supplement to the PKEY_TYPE_EP11 (which won't work in environments with session-bound keys). This new keyblobs has a different maximum size, so fix paes crypto module to accept also these larger keyblobs. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler <[email protected]> Reviewed-by: Ingo Franzki <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Holger Dengler <[email protected]> Date: Wed Jul 26 11:33:45 2023 +0200 s390/pkey: fix/harmonize internal keyblob headers [ Upstream commit 37a08f010b7c423b5e4c9ed3b187d21166553007 ] Commit 'fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys")' introduced PKEY_TYPE_EP11_AES as a supplement to PKEY_TYPE_EP11. All pkeys have an internal header/payload structure, which is opaque to the userspace. The header structures for PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES are nearly identical and there is no reason, why different structures are used. In preparation to fix the keyversion handling in the broken PKEY IOCTLs, the same header structure is used for PKEY_TYPE_EP11 and PKEY_TYPE_EP11_AES. This reduces the number of different code paths and increases the readability. Fixes: fa6999e326fe ("s390/pkey: support CCA and EP11 secure ECC private keys") Signed-off-by: Holger Dengler <[email protected]> Reviewed-by: Ingo Franzki <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Andy Shevchenko <[email protected]> Date: Thu Aug 31 13:59:59 2023 +0300 s390/zcrypt: don't leak memory if dev_set_name() fails [ Upstream commit 6252f47b78031979ad919f971dc8468b893488bd ] When dev_set_name() fails, zcdn_create() doesn't free the newly allocated resources. Do it. Fixes: 00fab2350e6b ("s390/zcrypt: multiple zcrypt device nodes support") Signed-off-by: Andy Shevchenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Harald Freudenberger <[email protected]> Signed-off-by: Heiko Carstens <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Daniel T. Lee <[email protected]> Date: Fri Aug 18 18:01:17 2023 +0900 samples/bpf: fix broken map lookup probe [ Upstream commit d93a7cf6ca2cfcd7de5d06f753ce8d5e863316ac ] In the commit 7c4cd051add3 ("bpf: Fix syscall's stackmap lookup potential deadlock"), a potential deadlock issue was addressed, which resulted in *_map_lookup_elem not triggering BPF programs. (prior to lookup, bpf_disable_instrumentation() is used) To resolve the broken map lookup probe using "htab_map_lookup_elem", this commit introduces an alternative approach. Instead, it utilize "bpf_map_copy_value" and apply a filter specifically for the hash table with map_type. Signed-off-by: Daniel T. Lee <[email protected]> Fixes: 7c4cd051add3 ("bpf: Fix syscall's stackmap lookup potential deadlock") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Ma <[email protected]> Date: Sun Jul 23 15:59:38 2023 +0800 scsi: be2iscsi: Add length check when parsing nlattrs [ Upstream commit ee0268f230f66cb472df3424f380ea668da2749a ] beiscsi_iface_set_param() parses nlattr with nla_for_each_attr and assumes every attributes can be viewed as struct iscsi_iface_param_info. This is not true because there is no any nla_policy to validate the attributes passed from the upper function iscsi_set_iface_params(). Add the nla_len check before accessing the nlattr data and return EINVAL if the length check fails. Fixes: 0e43895ec1f4 ("[SCSI] be2iscsi: adding functionality to change network settings using iscsiadm") Signed-off-by: Lin Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Fri Jul 21 09:01:32 2023 -0700 scsi: core: Fix the scsi_set_resid() documentation commit f669b8a683e4ee26fa5cafe19d71cec1786b556a upstream. Because scsi_finish_command() subtracts the residual from the buffer length, residual overflows must not be reported. Reflect this in the SCSI documentation. See also commit 9237f04e12cc ("scsi: core: Fix scsi_get/set_resid() interface") Cc: Damien Le Moal <[email protected]> Cc: Hannes Reinecke <[email protected]> Cc: Douglas Gilbert <[email protected]> Cc: [email protected] Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tony Battersby <[email protected]> Date: Mon Aug 14 10:03:25 2023 -0400 scsi: core: Use 32-bit hostnum in scsi_host_lookup() [ Upstream commit 62ec2092095b678ff89ce4ba51c2938cd1e8e630 ] Change scsi_host_lookup() hostnum argument type from unsigned short to unsigned int to match the type used everywhere else. Fixes: 6d49f63b415c ("[SCSI] Make host_no an unsigned int") Signed-off-by: Tony Battersby <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bart Van Assche <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengfeng Ye <[email protected]> Date: Thu Aug 17 07:47:08 2023 +0000 scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock [ Upstream commit 1a1975551943f681772720f639ff42fbaa746212 ] There is a long call chain that &fip->ctlr_lock is acquired by isr fnic_isr_msix_wq_copy() under hard IRQ context. Thus other process context code acquiring the lock should disable IRQ, otherwise deadlock could happen if the IRQ preempts the execution while the lock is held in process context on the same CPU. [ISR] fnic_isr_msix_wq_copy() -> fnic_wq_copy_cmpl_handler() -> fnic_fcpio_cmpl_handler() -> fnic_fcpio_flogi_reg_cmpl_handler() -> fnic_flush_tx() -> fnic_send_frame() -> fcoe_ctlr_els_send() -> spin_lock_bh(&fip->ctlr_lock) [Process Context] 1. fcoe_ctlr_timer_work() -> fcoe_ctlr_flogi_send() -> spin_lock_bh(&fip->ctlr_lock) 2. fcoe_ctlr_recv_work() -> fcoe_ctlr_recv_handler() -> fcoe_ctlr_recv_els() -> fcoe_ctlr_announce() -> spin_lock_bh(&fip->ctlr_lock) 3. fcoe_ctlr_recv_work() -> fcoe_ctlr_recv_handler() -> fcoe_ctlr_recv_els() -> fcoe_ctlr_flogi_retry() -> spin_lock_bh(&fip->ctlr_lock) 4. -> fcoe_xmit() -> fcoe_ctlr_els_send() -> spin_lock_bh(&fip->ctlr_lock) spin_lock_bh() is not enough since fnic_isr_msix_wq_copy() is a hardirq. These flaws were found by an experimental static analysis tool I am developing for irq-related deadlock. The patch fix the potential deadlocks by spin_lock_irqsave() to disable hard irq. Fixes: 794d98e77f59 ("[SCSI] libfcoe: retry rejected FLOGI to another FCF if possible") Signed-off-by: Chengfeng Ye <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Davidlohr Bueso <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xingui Yang <[email protected]> Date: Tue Jul 11 11:14:58 2023 +0800 scsi: hisi_sas: Fix normally completed I/O analysed as failed [ Upstream commit f5393a5602cacfda2014e0ff8220e5a7564e7cd1 ] The PIO read command has no response frame and the struct iu[1024] won't be filled. I/Os which are normally completed will be treated as failed in sas_ata_task_done() when iu contains abnormal dirty data. Consequently ending_fis should not be filled by iu when the response frame hasn't been written to memory. Fixes: d380f55503ed ("scsi: hisi_sas: Don't bother clearing status buffer IU in task prep") Signed-off-by: Xingui Yang <[email protected]> Signed-off-by: Xiang Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xingui Yang <[email protected]> Date: Mon May 15 10:41:21 2023 +0800 scsi: hisi_sas: Fix warnings detected by sparse [ Upstream commit c0328cc595124579328462fc45d7a29a084cf357 ] This patch fixes the following warning: drivers/scsi/hisi_sas/hisi_sas_v3_hw.c:2168:43: sparse: sparse: restricted __le32 degrades to integer Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Xingui Yang <[email protected]> Signed-off-by: Xiang Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: f5393a5602ca ("scsi: hisi_sas: Fix normally completed I/O analysed as failed") Signed-off-by: Sasha Levin <[email protected]>
Author: Xingui Yang <[email protected]> Date: Fri Jul 15 02:23:21 2022 +0800 scsi: hisi_sas: Modify v3 HW SATA completion error processing [ Upstream commit 7e15334f5d256367fb4c77f4ee0003e1e3d9bf9d ] If the I/O completion response frame returned by the target device has been written to the host memory and the err bit in the status field of the received fis is 1, ts->stat should set to SAS_PROTO_RESPONSE, and this will let EH analyze and further determine cause of failure. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xingui Yang <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: f5393a5602ca ("scsi: hisi_sas: Fix normally completed I/O analysed as failed") Signed-off-by: Sasha Levin <[email protected]>
Author: Xingui Yang <[email protected]> Date: Thu Feb 24 19:51:29 2022 +0800 scsi: hisi_sas: Modify v3 HW SSP underflow error processing [ Upstream commit 62413199cd6d2906c121c2dfa3d7b82fd05f08db ] In case of SSP underflow allow the response frame IU to be examined for setting the response stat value rather than always setting SAS_DATA_UNDERRUN. This will mean that we call sas_ssp_task_response() in those scenarios and may send sense data to upper layer. Such a condition would be for bad blocks were we just reporting an underflow error to upper layer, but now the sense data will tell immediately that the media is faulty. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Xingui Yang <[email protected]> Signed-off-by: Qi Liu <[email protected]> Signed-off-by: John Garry <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: f5393a5602ca ("scsi: hisi_sas: Fix normally completed I/O analysed as failed") Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Ma <[email protected]> Date: Tue Jul 25 10:45:29 2023 +0800 scsi: iscsi: Add length check for nlattr payload [ Upstream commit 971dfcb74a800047952f5288512b9c7ddedb050a ] The current NETLINK_ISCSI netlink parsing loop checks every nlmsg to make sure the length is bigger than sizeof(struct iscsi_uevent) and then calls iscsi_if_recv_msg(). nlh = nlmsg_hdr(skb); if (nlh->nlmsg_len < sizeof(*nlh) + sizeof(*ev) || skb->len < nlh->nlmsg_len) { break; } ... err = iscsi_if_recv_msg(skb, nlh, &group); Hence, in iscsi_if_recv_msg() the nlmsg_data can be safely converted to iscsi_uevent as the length is already checked. However, in other cases the length of nlattr payload is not checked before the payload is converted to other data structures. One example is iscsi_set_path() which converts the payload to type iscsi_path without any checks: params = (struct iscsi_path *)((char *)ev + sizeof(*ev)); Whereas iscsi_if_transport_conn() correctly checks the pdu_len: pdu_len = nlh->nlmsg_len - sizeof(*nlh) - sizeof(*ev); if ((ev->u.send_pdu.hdr_size > pdu_len) .. err = -EINVAL; To sum up, some code paths called in iscsi_if_recv_msg() do not check the length of the data (see below picture) and directly convert the data to another data structure. This could result in an out-of-bound reads and heap dirty data leakage. _________ nlmsg_len(nlh) _______________ / \ +----------+--------------+---------------------------+ | nlmsghdr | iscsi_uevent | data | +----------+--------------+---------------------------+ \ / iscsi_uevent->u.set_param.len Fix the issue by adding the length check before accessing it. To clean up the code, an additional parameter named rlen is added. The rlen is calculated at the beginning of iscsi_if_recv_msg() which avoids duplicated calculation. Fixes: ac20c7bf070d ("[SCSI] iscsi_transport: Added Ping support") Fixes: 43514774ff40 ("[SCSI] iscsi class: Add new NETLINK_ISCSI messages for cnic/bnx2i driver.") Fixes: 1d9bf13a9cf9 ("[SCSI] iscsi class: add iscsi host set param event") Fixes: 01cb225dad8d ("[SCSI] iscsi: add target discvery event to transport class") Fixes: 264faaaa1254 ("[SCSI] iscsi: add transport end point callbacks") Fixes: fd7255f51a13 ("[SCSI] iscsi: add sysfs attrs for uspace sync up") Signed-off-by: Lin Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Ma <[email protected]> Date: Sun Jul 23 15:58:20 2023 +0800 scsi: iscsi: Add strlen() check in iscsi_if_set{_host}_param() [ Upstream commit ce51c817008450ef4188471db31639d42d37a5e1 ] The functions iscsi_if_set_param() and iscsi_if_set_host_param() convert an nlattr payload to type char* and then call C string handling functions like sscanf and kstrdup: char *data = (char*)ev + sizeof(*ev); ... sscanf(data, "%d", &value); However, since the nlattr is provided by the user-space program and the nlmsg skb is allocated with GFP_KERNEL instead of GFP_ZERO flag (see netlink_alloc_large_skb() in netlink_sendmsg()), dirty data on the heap can lead to an OOB access for those string handling functions. By investigating how the bug is introduced, we find it is really interesting as the old version parsing code starting from commit fd7255f51a13 ("[SCSI] iscsi: add sysfs attrs for uspace sync up") treated the nlattr as integer bytes instead of string and had length check in iscsi_copy_param(): if (ev->u.set_param.len != sizeof(uint32_t)) BUG(); But, since the commit a54a52caad4b ("[SCSI] iscsi: fixup set/get param functions"), the code treated the nlattr as C string while forgetting to add any strlen checks(), opening the possibility of an OOB access. Fix the potential OOB by adding the strlen() check before accessing the buf. If the data passes this check, all low-level set_param handlers can safely treat this buf as legal C string. Fixes: fd7255f51a13 ("[SCSI] iscsi: add sysfs attrs for uspace sync up") Fixes: 1d9bf13a9cf9 ("[SCSI] iscsi class: add iscsi host set param event") Signed-off-by: Lin Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Wenchao Hao <[email protected]> Date: Tue Nov 22 18:11:05 2022 +0000 scsi: iscsi: Rename iscsi_set_param() to iscsi_if_set_param() [ Upstream commit 0c26a2d7c98039e913e63f9250fde738a3f88a60 ] There are two iscsi_set_param() functions defined in libiscsi.c and scsi_transport_iscsi.c respectively which is confusing. Rename the one in scsi_transport_iscsi.c to iscsi_if_set_param(). Signed-off-by: Wenchao Hao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Mike Christie <[email protected]> Reviewed-by: Lee Duncan <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Stable-dep-of: 971dfcb74a80 ("scsi: iscsi: Add length check for nlattr payload") Signed-off-by: Sasha Levin <[email protected]>
Author: Justin Tee <[email protected]> Date: Wed Jun 14 10:59:44 2023 -0700 scsi: lpfc: Fix incorrect big endian type assignment in bsg loopback path [ Upstream commit 9cefd6e7e0a77b0fbca5c793f6fb6821b0962775 ] The kernel test robot reported sparse warnings regarding incorrect type assignment for __be16 variables in bsg loopback path. Change the flagged lines to use the be16_to_cpu() and cpu_to_be16() macros appropriately. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Justin Tee <[email protected]> Date: Thu Aug 3 14:19:32 2023 -0700 scsi: lpfc: Remove reftag check in DIF paths [ Upstream commit 8eebf0e84f0614cebc7347f7bbccba4056d77d42 ] When preparing protection DIF I/O for DMA, the driver obtains reference tags from scsi_prot_ref_tag(). Previously, there was a wrong assumption that an all 0xffffffff value meant error and thus the driver failed the I/O. This patch removes the evaluation code and accepts whatever the upper layer returns. Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ranjan Kumar <[email protected]> Date: Tue Aug 29 14:30:19 2023 +0530 scsi: mpt3sas: Perform additional retries if doorbell read returns 0 commit 4ca10f3e31745d35249a727ecd108eb58f0a8c5e upstream. The driver retries certain register reads 3 times if the returned value is 0. This was done because the controller could return 0 for certain registers if other registers were being accessed concurrently by the BMC. In certain systems with increased BMC interactions, the register values returned can be 0 for longer than 3 retries. Change the retry count from 3 to 30 for the affected registers to prevent problems with out-of-band management. Fixes: b899202901a8 ("scsi: mpt3sas: Add separate function for aero doorbell reads") Cc: [email protected] Signed-off-by: Ranjan Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Oleksandr Natalenko <[email protected]> Date: Mon Jul 31 10:40:33 2023 +0200 scsi: qedf: Do not touch __user pointer in qedf_dbg_debug_cmd_read() directly [ Upstream commit 31b5991a9a91ba97237ac9da509d78eec453ff72 ] The qedf_dbg_debug_cmd_read() function invokes sprintf() directly on a __user pointer, which may crash the kernel. Avoid doing that by using a small on-stack buffer for scnprintf() and then calling simple_read_from_buffer() which does a proper copy_to_user() call. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/linux-scsi/[email protected]/ Cc: Saurav Kashyap <[email protected]> Cc: Rob Evers <[email protected]> Cc: Johannes Thumshirn <[email protected]> Cc: David Laight <[email protected]> Cc: Jozef Bacik <[email protected]> Cc: Laurence Oberman <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Laurence Oberman <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Tested-by: Laurence Oberman <[email protected]> Acked-by: Saurav Kashyap <[email protected]> Signed-off-by: Oleksandr Natalenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksandr Natalenko <[email protected]> Date: Mon Jul 31 10:40:34 2023 +0200 scsi: qedf: Do not touch __user pointer in qedf_dbg_fp_int_cmd_read() directly [ Upstream commit 25dbc20deab5165f847b4eb42f376f725a986ee8 ] The qedf_dbg_fp_int_cmd_read() function invokes sprintf() directly on a __user pointer, which may crash the kernel. Avoid doing that by vmalloc()'ating a buffer for scnprintf() and then calling simple_read_from_buffer() which does a proper copy_to_user() call. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/linux-scsi/[email protected]/ Cc: Saurav Kashyap <[email protected]> Cc: Rob Evers <[email protected]> Cc: Johannes Thumshirn <[email protected]> Cc: David Laight <[email protected]> Cc: Jozef Bacik <[email protected]> Cc: Laurence Oberman <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Laurence Oberman <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Tested-by: Laurence Oberman <[email protected]> Acked-by: Saurav Kashyap <[email protected]> Signed-off-by: Oleksandr Natalenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Oleksandr Natalenko <[email protected]> Date: Mon Jul 31 10:40:32 2023 +0200 scsi: qedf: Do not touch __user pointer in qedf_dbg_stop_io_on_error_cmd_read() directly [ Upstream commit 7d3d20dee4f648ec44e9717d5f647d594d184433 ] The qedf_dbg_stop_io_on_error_cmd_read() function invokes sprintf() directly on a __user pointer, which may crash the kernel. Avoid doing that by using a small on-stack buffer for scnprintf() and then calling simple_read_from_buffer() which does a proper copy_to_user() call. Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Link: https://lore.kernel.org/lkml/[email protected]/ Link: https://lore.kernel.org/linux-scsi/[email protected]/ Cc: Saurav Kashyap <[email protected]> Cc: Rob Evers <[email protected]> Cc: Johannes Thumshirn <[email protected]> Cc: David Laight <[email protected]> Cc: Jozef Bacik <[email protected]> Cc: Laurence Oberman <[email protected]> Cc: "James E.J. Bottomley" <[email protected]> Cc: "Martin K. Petersen" <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Laurence Oberman <[email protected]> Reviewed-by: Johannes Thumshirn <[email protected]> Tested-by: Laurence Oberman <[email protected]> Acked-by: Saurav Kashyap <[email protected]> Signed-off-by: Oleksandr Natalenko <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chengfeng Ye <[email protected]> Date: Wed Jul 26 12:56:55 2023 +0000 scsi: qedi: Fix potential deadlock on &qedi_percpu->p_work_lock [ Upstream commit dd64f80587190265ca8a0f4be6c64c2fda6d3ac2 ] As &qedi_percpu->p_work_lock is acquired by hard IRQ qedi_msix_handler(), other acquisitions of the same lock under process context should disable IRQ, otherwise deadlock could happen if the IRQ preempts the execution while the lock is held in process context on the same CPU. qedi_cpu_offline() is one such function which acquires the lock in process context. [Deadlock Scenario] qedi_cpu_offline() ->spin_lock(&p->p_work_lock) <irq> ->qedi_msix_handler() ->edi_process_completions() ->spin_lock_irqsave(&p->p_work_lock, flags); (deadlock here) This flaw was found by an experimental static analysis tool I am developing for IRQ-related deadlocks. The tentative patch fix the potential deadlock by spin_lock_irqsave() under process context. Signed-off-by: Chengfeng Ye <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Manish Rangankar <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:30:56 2023 +0530 scsi: qla2xxx: Adjust IOCB resource on qpair create commit efa74a62aaa2429c04fe6cb277b3bf6739747d86 upstream. During NVMe queue creation, a new qpair is created. FW resource limit needs to be re-adjusted to take into account the new qpair. Otherwise, NVMe command can not go through. This issue was discovered while testing/forcing FW execution to fail at load time. Add call to readjust IOCB and exchange limit. In addition, get FW state command and require FW to be running. Otherwise, error is generated. Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Aug 21 18:30:41 2023 +0530 scsi: qla2xxx: Error code did not return to upper layer commit 0ba0b018f94525a6b32f5930f980ce9b62b72e6f upstream. TMF was returned with an error code. The error code was not preserved to be returned to upper layer. Instead, the error code from the Marker was returned. Preserve error code from TMF and return it to upper layer. Cc: [email protected] Fixes: da7c21b72aa8 ("scsi: qla2xxx: Fix command flush during TMF") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:30:58 2023 +0530 scsi: qla2xxx: Fix command flush during TMF commit da7c21b72aa86e990af5f73bce6590b8d8d148d0 upstream. For each TMF request, driver iterates through each qpair and flushes commands associated to the TMF. At the end of the qpair flush, a Marker is used to complete the flush transaction. This process was repeated for each qpair. The multiple flush and marker for this TMF request seems to cause confusion for FW. Instead, 1 flush is sent to FW. Driver would wait for FW to go through all the I/Os on each qpair to be read then return. Driver then closes out the transaction with a Marker. Cc: [email protected] Fixes: d90171dd0da5 ("scsi: qla2xxx: Multi-que support for TMF") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:30:55 2023 +0530 scsi: qla2xxx: Fix deletion race condition commit 6dfe4344c168c6ca20fe7640649aacfcefcccb26 upstream. System crash when using debug kernel due to link list corruption. The cause of the link list corruption is due to session deletion was allowed to queue up twice. Here's the internal trace that show the same port was allowed to double queue for deletion on different cpu. 20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 20808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1 Move the clearing/setting of deleted flag lock. Cc: [email protected] Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:30:59 2023 +0530 scsi: qla2xxx: Fix erroneous link up failure commit 5b51f35d127e7bef55fa869d2465e2bca4636454 upstream. Link up failure occurred where driver failed to see certain events from FW indicating link up (AEN 8011) and fabric login completion (AEN 8014). Without these 2 events, driver would not proceed forward to scan the fabric. The cause of this is due to delay in the receive of interrupt for Mailbox 60 that causes qla to set the fw_started flag late. The late setting of this flag causes other interrupts to be dropped. These dropped interrupts happen to be the link up (AEN 8011) and fabric login completion (AEN 8014). Set fw_started flag early to prevent interrupts being dropped. Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Aug 21 18:30:39 2023 +0530 scsi: qla2xxx: Fix firmware resource tracking commit e370b64c7db96384a0886a09a9d80406e4c663d7 upstream. The storage was not draining I/Os and the work load was not spread out across different CPUs evenly. This led to firmware resource counters getting overrun on the busy CPU. This overrun prevented error recovery from happening in a timely manner. By switching the counter to atomic, it allows the count to be little more accurate to prevent the overrun. Cc: [email protected] Fixes: da7c21b72aa8 ("scsi: qla2xxx: Fix command flush during TMF") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:31:03 2023 +0530 scsi: qla2xxx: fix inconsistent TMF timeout commit 009e7fe4a1ed52276b332842a6b6e23b07200f2d upstream. Different behavior were experienced of session being torn down vs not when TMF is timed out. When FW detects the time out, the session is torn down. When driver detects the time out, the session is not torn down. Allow TMF error to return to upper layer without session tear down. Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:31:00 2023 +0530 scsi: qla2xxx: Fix session hang in gnl commit 39d22740712c7563a2e18c08f033deeacdaf66e7 upstream. Connection does not resume after a host reset / chip reset. The cause of the blockage is due to the FCF_ASYNC_ACTIVE left on. The gnl command was interrupted by the chip reset. On exiting the command, this flag should be turn off to allow relogin to reoccur. Clear this flag to prevent blockage. Cc: [email protected] Fixes: 17e64648aa47 ("scsi: qla2xxx: Correct fcport flags handling") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Nilesh Javali <[email protected]> Date: Mon Aug 21 18:30:43 2023 +0530 scsi: qla2xxx: Fix smatch warn for qla_init_iocb_limit() commit b496953dd0444001b12f425ea07d78c1f47e3193 upstream. Fix indentation for warning reported by smatch: drivers/scsi/qla2xxx/qla_init.c:4199 qla_init_iocb_limit() warn: inconsistent indenting Fixes: efa74a62aaa2 ("scsi: qla2xxx: Adjust IOCB resource on qpair create") Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:31:02 2023 +0530 scsi: qla2xxx: Fix TMF leak through commit 5d3148d8e8b05f084e607ac3bd55a4c317a9f934 upstream. Task management can retry up to 5 times when FW resource becomes bottle neck. Between the retries, there is a short sleep. Current code assumes the chip has not reset or session has not changed. Check for chip reset or session change before sending Task management. Cc: [email protected] Fixes: 9803fb5d2759 ("scsi: qla2xxx: Fix task management cmd failure") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Mon Aug 21 18:30:38 2023 +0530 scsi: qla2xxx: Flush mailbox commands on chip reset commit 6d0b65569c0a10b27c49bacd8d25bcd406003533 upstream. Fix race condition between Interrupt thread and Chip reset thread in trying to flush the same mailbox. With the race condition, the "ha->mbx_intr_comp" will get an extra complete() call. The extra complete call create erroneous mailbox timeout condition when the next mailbox is sent where the mailbox call does not wait for interrupt to arrive. Instead, it advances without waiting. Add lock protection around the check for mailbox completion. Cc: [email protected] Fixes: b2000805a975 ("scsi: qla2xxx: Flush mailbox commands on chip reset") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:30:57 2023 +0530 scsi: qla2xxx: Limit TMF to 8 per function commit a8ec192427e0516436e61f9ca9eb49c54eadfe0a upstream. Per FW recommendation, 8 TMF's can be outstanding for each function. Previously, it allowed 8 per target. Limit TMF to 8 per function. Cc: [email protected] Fixes: 6a87679626b5 ("scsi: qla2xxx: Fix task management cmd fail due to unavailable resource") Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Manish Rangankar <[email protected]> Date: Mon Aug 21 18:30:42 2023 +0530 scsi: qla2xxx: Remove unsupported ql2xenabledif option commit e9105c4b7a9208a21a9bda133707624f12ddabc2 upstream. User accidently passed module parameter ql2xenabledif=1 which is unsupported. However, driver still initialized which lead to guard tag errors during device discovery. Remove unsupported ql2xenabledif=1 option and validate the user input. Cc: [email protected] Signed-off-by: Manish Rangankar <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Quinn Tran <[email protected]> Date: Fri Jul 14 12:31:01 2023 +0530 scsi: qla2xxx: Turn off noisy message log commit 8ebaa45163a3fedc885c1dc7d43ea987a2f00a06 upstream. Some consider noisy log as test failure. Turn off noisy message log. Cc: [email protected] Signed-off-by: Quinn Tran <[email protected]> Signed-off-by: Nilesh Javali <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lin Ma <[email protected]> Date: Sun Jul 23 16:00:53 2023 +0800 scsi: qla4xxx: Add length check when parsing nlattrs [ Upstream commit 47cd3770e31df942e2bb925a9a855c79ed0662eb ] There are three places that qla4xxx parses nlattrs: - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param() and each of them directly converts the nlattr to specific pointer of structure without length checking. This could be dangerous as those attributes are not validated and a malformed nlattr (e.g., length 0) could result in an OOB read that leaks heap dirty data. Add the nla_len check before accessing the nlattr data and return EINVAL if the length check fails. Fixes: 26ffd7b45fe9 ("[SCSI] qla4xxx: Add support to set CHAP entries") Fixes: 1e9e2be3ee03 ("[SCSI] qla4xxx: Add flash node mgmt support") Fixes: 00c31889f751 ("[SCSI] qla4xxx: fix data alignment and use nl helpers") Signed-off-by: Lin Ma <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Chris Leech <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Bart Van Assche <[email protected]> Date: Mon Jul 24 13:08:30 2023 -0700 scsi: RDMA/srp: Fix residual handling [ Upstream commit 89e637c19b2441aabc8dbf22a8745b932fd6996e ] Although the code for residual handling in the SRP initiator follows the SCSI documentation, that documentation has never been correct. Because scsi_finish_command() starts from the data buffer length and subtracts the residual, scsi_set_resid() must not be called if a residual overflow occurs. Hence remove the scsi_set_resid() calls from the SRP initiator if a residual overflow occurrs. Cc: Leon Romanovsky <[email protected]> Cc: Jason Gunthorpe <[email protected]> Fixes: 9237f04e12cc ("scsi: core: Fix scsi_get/set_resid() interface") Fixes: e714531a349f ("IB/srp: Fix residual handling") Signed-off-by: Bart Van Assche <[email protected]> Link: https://lore.kernel.org/r/[email protected] Acked-by: Leon Romanovsky <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Michael Kelley <[email protected]> Date: Fri Jun 9 13:38:21 2023 -0700 scsi: storvsc: Always set no_report_opcodes [ Upstream commit 31d16e712bdcaee769de4780f72ff8d6cd3f0589 ] Hyper-V synthetic SCSI devices do not support the MAINTENANCE_IN SCSI command, so scsi_report_opcode() always fails, resulting in messages like this: hv_storvsc <guid>: tag#205 cmd 0xa3 status: scsi 0x2 srb 0x86 hv 0xc0000001 The recently added support for command duration limits calls scsi_report_opcode() four times as each device comes online, which significantly increases the number of messages logged in a system with many disks. Fix the problem by always marking Hyper-V synthetic SCSI devices as not supporting scsi_report_opcode(). With this setting, the MAINTENANCE_IN SCSI command is not issued and no messages are logged. Signed-off-by: Michael Kelley <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Wed Aug 30 09:45:19 2023 +0000 sctp: annotate data-races around sk->sk_wmem_queued [ Upstream commit dc9511dd6f37fe803f6b15b61b030728d7057417 ] sk->sk_wmem_queued can be read locklessly from sctp_poll() Use sk_wmem_queued_add() when the field is changed, and add READ_ONCE() annotations in sctp_writeable() and sctp_assocs_seq_show() syzbot reported: BUG: KCSAN: data-race in sctp_poll / sctp_wfree read-write to 0xffff888149d77810 of 4 bytes by interrupt on cpu 0: sctp_wfree+0x170/0x4a0 net/sctp/socket.c:9147 skb_release_head_state+0xb7/0x1a0 net/core/skbuff.c:988 skb_release_all net/core/skbuff.c:1000 [inline] __kfree_skb+0x16/0x140 net/core/skbuff.c:1016 consume_skb+0x57/0x180 net/core/skbuff.c:1232 sctp_chunk_destroy net/sctp/sm_make_chunk.c:1503 [inline] sctp_chunk_put+0xcd/0x130 net/sctp/sm_make_chunk.c:1530 sctp_datamsg_put+0x29a/0x300 net/sctp/chunk.c:128 sctp_chunk_free+0x34/0x50 net/sctp/sm_make_chunk.c:1515 sctp_outq_sack+0xafa/0xd70 net/sctp/outqueue.c:1381 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:834 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1366 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline] sctp_do_sm+0x12c7/0x31b0 net/sctp/sm_sideeffect.c:1169 sctp_assoc_bh_rcv+0x2b2/0x430 net/sctp/associola.c:1051 sctp_inq_push+0x108/0x120 net/sctp/inqueue.c:80 sctp_rcv+0x116e/0x1340 net/sctp/input.c:243 sctp6_rcv+0x25/0x40 net/sctp/ipv6.c:1120 ip6_protocol_deliver_rcu+0x92f/0xf30 net/ipv6/ip6_input.c:437 ip6_input_finish net/ipv6/ip6_input.c:482 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] ip6_input+0xbd/0x1b0 net/ipv6/ip6_input.c:491 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish+0x1e2/0x2e0 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:303 [inline] ipv6_rcv+0x74/0x150 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core net/core/dev.c:5452 [inline] __netif_receive_skb+0x90/0x1b0 net/core/dev.c:5566 process_backlog+0x21f/0x380 net/core/dev.c:5894 __napi_poll+0x60/0x3b0 net/core/dev.c:6460 napi_poll net/core/dev.c:6527 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6660 __do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/softirq.c:921 smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:389 ret_from_fork+0x2e/0x40 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 read to 0xffff888149d77810 of 4 bytes by task 17828 on cpu 1: sctp_writeable net/sctp/socket.c:9304 [inline] sctp_poll+0x265/0x410 net/sctp/socket.c:8671 sock_poll+0x253/0x270 net/socket.c:1374 vfs_poll include/linux/poll.h:88 [inline] do_pollfd fs/select.c:873 [inline] do_poll fs/select.c:921 [inline] do_sys_poll+0x636/0xc00 fs/select.c:1015 __do_sys_ppoll fs/select.c:1121 [inline] __se_sys_ppoll+0x1af/0x1f0 fs/select.c:1101 __x64_sys_ppoll+0x67/0x80 fs/select.c:1101 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00019e80 -> 0x0000cc80 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17828 Comm: syz-executor.1 Not tainted 6.5.0-rc7-syzkaller-00185-g28f20a19294d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Marcelo Ricardo Leitner <[email protected]> Acked-by: Xin Long <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Fri Jun 9 14:04:43 2023 +0300 sctp: handle invalid error codes without calling BUG() [ Upstream commit a0067dfcd9418fd3b0632bc59210d120d038a9c6 ] The sctp_sf_eat_auth() function is supposed to return enum sctp_disposition values but if the call to sctp_ulpevent_make_authkey() fails, it returns -ENOMEM. This results in calling BUG() inside the sctp_side_effects() function. Calling BUG() is an over reaction and not helpful. Call WARN_ON_ONCE() instead. This code predates git. Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Göttsche <[email protected]> Date: Thu May 11 14:32:52 2023 +0200 security: keys: perform capable check only on privileged operations [ Upstream commit 2d7f105edbb3b2be5ffa4d833abbf9b6965e9ce7 ] If the current task fails the check for the queried capability via `capable(CAP_SYS_ADMIN)` LSMs like SELinux generate a denial message. Issuing such denial messages unnecessarily can lead to a policy author granting more privileges to a subject than needed to silence them. Reorder CAP_SYS_ADMIN checks after the check whether the operation is actually privileged. Signed-off-by: Christian Göttsche <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yipeng Zou <[email protected]> Date: Mon Aug 14 11:07:27 2023 +0800 selftests/bpf: Clean up fmod_ret in bench_rename test script [ Upstream commit 83a89c4b6ae93481d3f618aba6a29d89208d26ed ] Running the bench_rename test script, the following error occurs: # ./benchs/run_bench_rename.sh base : 0.819 ± 0.012M/s kprobe : 0.538 ± 0.009M/s kretprobe : 0.503 ± 0.004M/s rawtp : 0.779 ± 0.020M/s fentry : 0.726 ± 0.007M/s fexit : 0.691 ± 0.007M/s benchmark 'rename-fmodret' not found The bench_rename_fmodret has been removed in commit b000def2e052 ("selftests: Remove fmod_ret from test_overhead"), thus remove it from the runners in the test script. Fixes: b000def2e052 ("selftests: Remove fmod_ret from test_overhead") Signed-off-by: Yipeng Zou <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Alan Maguire <[email protected]> Date: Wed Aug 2 08:39:06 2023 +0100 selftests/bpf: fix static assert compilation issue for test_cls_*.c [ Upstream commit 416c6d01244ecbf0abfdb898fd091b50ef951b48 ] commit bdeeed3498c7 ("libbpf: fix offsetof() and container_of() to work with CO-RE") ...was backported to stable trees such as 5.15. The problem is that with older LLVM/clang (14/15) - which is often used for older kernels - we see compilation failures in BPF selftests now: In file included from progs/test_cls_redirect_subprogs.c:2: progs/test_cls_redirect.c:90:2: error: static assertion expression is not an integral constant expression sizeof(flow_ports_t) != ^~~~~~~~~~~~~~~~~~~~~~~ progs/test_cls_redirect.c:91:3: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression offsetofend(struct bpf_sock_tuple, ipv4.dport) - ^ progs/test_cls_redirect.c:32:3: note: expanded from macro 'offsetofend' (offsetof(TYPE, MEMBER) + sizeof((((TYPE *)0)->MEMBER))) ^ tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:86:33: note: expanded from macro 'offsetof' ^ In file included from progs/test_cls_redirect_subprogs.c:2: progs/test_cls_redirect.c:95:2: error: static assertion expression is not an integral constant expression sizeof(flow_ports_t) != ^~~~~~~~~~~~~~~~~~~~~~~ progs/test_cls_redirect.c:96:3: note: cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression offsetofend(struct bpf_sock_tuple, ipv6.dport) - ^ progs/test_cls_redirect.c:32:3: note: expanded from macro 'offsetofend' (offsetof(TYPE, MEMBER) + sizeof((((TYPE *)0)->MEMBER))) ^ tools/testing/selftests/bpf/tools/include/bpf/bpf_helpers.h:86:33: note: expanded from macro 'offsetof' ^ 2 errors generated. make: *** [Makefile:594: tools/testing/selftests/bpf/test_cls_redirect_subprogs.bpf.o] Error 1 The problem is the new offsetof() does not play nice with static asserts. Given that the context is a static assert (and CO-RE relocation is not needed at compile time), offsetof() usage can be replaced by restoring the original offsetof() definition as __builtin_offsetof(). Fixes: bdeeed3498c7 ("libbpf: fix offsetof() and container_of() to work with CO-RE") Reported-by: Colm Harrington <[email protected]> Signed-off-by: Alan Maguire <[email protected]> Tested-by: Yipeng Zou <[email protected]> Acked-by: Yonghong Song <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alexei Starovoitov <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Nysal Jan K.A <[email protected]> Date: Mon Aug 14 13:39:27 2023 +0530 selftests/futex: Order calls to futex_lock_pi [ Upstream commit fbf4dec702774286db409815ffb077711a96b824 ] Observed occassional failures in the futex_wait_timeout test: ok 1 futex_wait relative succeeds ok 2 futex_wait_bitset realtime succeeds ok 3 futex_wait_bitset monotonic succeeds ok 4 futex_wait_requeue_pi realtime succeeds ok 5 futex_wait_requeue_pi monotonic succeeds not ok 6 futex_lock_pi realtime returned 0 ...... The test expects the child thread to complete some steps before the parent thread gets to run. There is an implicit expectation of the order of invocation of futex_lock_pi between the child thread and the parent thread. Make this order explicit. If the order is not met, the futex_lock_pi call in the parent thread succeeds and will not timeout. Fixes: f4addd54b161 ("selftests: futex: Expand timeout test") Signed-off-by: Nysal Jan K.A <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Kees Cook <[email protected]> Date: Mon Aug 7 10:43:58 2023 -0700 selftests/harness: Actually report SKIP for signal tests [ Upstream commit b3d46e11fec0c5a8972e5061bb1462119ae5736d ] Tests that were expecting a signal were not correctly checking for a SKIP condition. Move the check before the signal checking when processing test result. Cc: Shuah Khan <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Will Drewry <[email protected]> Cc: [email protected] Fixes: 9847d24af95c ("selftests/harness: Refactor XFAIL into SKIP") Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 16:14:49 2023 +0300 selftests/resctrl: Add resctrl.h into build deps [ Upstream commit 8e289f4542890168705219e54f0231dccfabddbe ] Makefile only lists *.c as build dependencies for the resctrl_tests executable which excludes resctrl.h. Add *.h to wildcard() to include resctrl.h. Fixes: 591a6e8588fc ("selftests/resctrl: Add basic resctrl file system operations and data") Signed-off-by: Ilpo Järvinen <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Tested-by: Shaopeng Tan (Fujitsu) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 16:14:52 2023 +0300 selftests/resctrl: Close perf value read fd on errors [ Upstream commit 51a0c3b7f028169e40db930575dd01fe81c3e765 ] Perf event fd (fd_lm) is not closed when run_fill_buf() returns error. Close fd_lm only in cat_val() to make it easier to track it is always closed. Fixes: 790bf585b0ee ("selftests/resctrl: Add Cache Allocation Technology (CAT) selftest") Signed-off-by: Ilpo Järvinen <[email protected]> Tested-by: Babu Moger <[email protected]> Tested-by: Shaopeng Tan (Fujitsu) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 16:14:50 2023 +0300 selftests/resctrl: Don't leak buffer in fill_cache() [ Upstream commit 2d320b1029ee7329ee0638181be967789775b962 ] The error path in fill_cache() does return before the allocated buffer is freed leaking the buffer. The leak was introduced when fill_cache_read() started to return errors in commit c7b607fa9325 ("selftests/resctrl: Fix null pointer dereference on open failed"), before that both fill functions always returned 0. Move free() earlier to prevent the mem leak. Fixes: c7b607fa9325 ("selftests/resctrl: Fix null pointer dereference on open failed") Signed-off-by: Ilpo Järvinen <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Tested-by: Shaopeng Tan (Fujitsu) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Shaopeng Tan <[email protected]> Date: Wed Mar 23 17:12:25 2022 +0900 selftests/resctrl: Make resctrl_tests run using kselftest framework [ Upstream commit b733143cc455bf83fa5fbd2e0eac63fb2d302461 ] In kselftest framework, all tests can be build/run at a time, and a sub test also can be build/run individually. As follows: $ make kselftest-all TARGETS=resctrl $ make -C tools/testing/selftests run_tests $ make -C tools/testing/selftests TARGETS=resctrl run_tests However, resctrl_tests cannot be run using kselftest framework, users have to change directory to tools/testing/selftests/resctrl/, run "make" to build executable file "resctrl_tests", and run "sudo ./resctrl_tests" to execute the test. To build/run resctrl_tests using kselftest framework. Modify tools/testing/selftests/Makefile and tools/testing/selftests/resctrl/Makefile. Even after this change, users can still build/run resctrl_tests without using framework as before. Reviewed-by: Reinette Chatre <[email protected]> # resctrl changes Reviewed-by: Fenghua Yu <[email protected]> Signed-off-by: Shaopeng Tan <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Stable-dep-of: 8e289f454289 ("selftests/resctrl: Add resctrl.h into build deps") Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 16:14:51 2023 +0300 selftests/resctrl: Unmount resctrl FS if child fails to run benchmark [ Upstream commit f99e413eb54652e2436cc56d081176bc9a34cd8d ] A child calls PARENT_EXIT() when it fails to run a benchmark to kill the parent process. PARENT_EXIT() lacks unmount for the resctrl FS and the parent won't be there to unmount it either after it gets killed. Add the resctrl FS unmount also to PARENT_EXIT(). Fixes: 591a6e8588fc ("selftests/resctrl: Add basic resctrl file system operations and data") Signed-off-by: Ilpo Järvinen <[email protected]> Reviewed-by: Reinette Chatre <[email protected]> Tested-by: Babu Moger <[email protected]> Tested-by: Shaopeng Tan (Fujitsu) <[email protected]> Signed-off-by: Shuah Khan <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chunyan Zhang <[email protected]> Date: Tue Jul 25 14:40:52 2023 +0800 serial: sprd: Assign sprd_port after initialized to avoid wrong access [ Upstream commit f9608f1887568b728839d006024585ab02ef29e5 ] The global pointer 'sprd_port' may not zero when sprd_probe returns failure, that is a risk for sprd_port to be accessed afterward, and may lead to unexpected errors. For example: There are two UART ports, UART1 is used for console and configured in kernel command line, i.e. "console="; The UART1 probe failed and the memory allocated to sprd_port[1] was released, but sprd_port[1] was not set to NULL; In UART2 probe, the same virtual address was allocated to sprd_port[2], and UART2 probe process finally will go into sprd_console_setup() to register UART1 as console since it is configured as preferred console (filled to console_cmdline[]), but the console parameters (sprd_port[1]) belong to UART2. So move the sprd_port[] assignment to where the port already initialized can avoid the above issue. Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support") Signed-off-by: Chunyan Zhang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chunyan Zhang <[email protected]> Date: Tue Jul 25 14:40:53 2023 +0800 serial: sprd: Fix DMA buffer leak issue [ Upstream commit cd119fdc3ee1450fbf7f78862b5de44c42b6e47f ] Release DMA buffer when _probe() returns failure to avoid memory leak. Fixes: f4487db58eb7 ("serial: sprd: Add DMA mode support") Signed-off-by: Chunyan Zhang <[email protected]> Reviewed-by: Baolin Wang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yi Yang <[email protected]> Date: Thu Aug 17 18:54:06 2023 +0800 serial: tegra: handle clk prepare error in tegra_uart_hw_init() [ Upstream commit 5abd01145d0cc6cd1b7c2fe6ee0b9ea0fa13671e ] In tegra_uart_hw_init(), the return value of clk_prepare_enable() should be checked since it might fail. Fixes: e9ea096dd225 ("serial: tegra: add serial driver") Signed-off-by: Yi Yang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Petr Tesarik <[email protected]> Date: Mon Jul 24 14:07:42 2023 +0200 sh: boards: Fix CEU buffer size passed to dma_declare_coherent_memory() [ Upstream commit fb60211f377b69acffead3147578f86d0092a7a5 ] In all these cases, the last argument to dma_declare_coherent_memory() is the buffer end address, but the expected value should be the size of the reserved region. Fixes: 39fb993038e1 ("media: arch: sh: ap325rxa: Use new renesas-ceu camera driver") Fixes: c2f9b05fd5c1 ("media: arch: sh: ecovec: Use new renesas-ceu camera driver") Fixes: f3590dc32974 ("media: arch: sh: kfr2r09: Use new renesas-ceu camera driver") Fixes: 186c446f4b84 ("media: arch: sh: migor: Use new renesas-ceu camera driver") Fixes: 1a3c230b4151 ("media: arch: sh: ms7724se: Use new renesas-ceu camera driver") Signed-off-by: Petr Tesarik <[email protected]> Reviewed-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Jacopo Mondi <[email protected]> Reviewed-by: John Paul Adrian Glaubitz <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: John Paul Adrian Glaubitz <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mohamed Khalfella <[email protected]> Date: Thu Aug 31 02:17:02 2023 -0600 skbuff: skb_segment, Call zero copy functions before using skbuff frags commit 2ea35288c83b3d501a88bc17f2df8f176b5cc96f upstream. Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions once per nskb") added the call to zero copy functions in skb_segment(). The change introduced a bug in skb_segment() because skb_orphan_frags() may possibly change the number of fragments or allocate new fragments altogether leaving nrfrags and frag to point to the old values. This can cause a panic with stacktrace like the one below. [ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc [ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26 [ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0 [ 194.021892] Call Trace: [ 194.027422] <TASK> [ 194.072861] tcp_gso_segment+0x107/0x540 [ 194.082031] inet_gso_segment+0x15c/0x3d0 [ 194.090783] skb_mac_gso_segment+0x9f/0x110 [ 194.095016] __skb_gso_segment+0xc1/0x190 [ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem] [ 194.107071] dev_qdisc_enqueue+0x16/0x70 [ 194.110884] __dev_queue_xmit+0x63b/0xb30 [ 194.121670] bond_start_xmit+0x159/0x380 [bonding] [ 194.128506] dev_hard_start_xmit+0xc3/0x1e0 [ 194.131787] __dev_queue_xmit+0x8a0/0xb30 [ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan] [ 194.141477] dev_hard_start_xmit+0xc3/0x1e0 [ 194.144622] sch_direct_xmit+0xe3/0x280 [ 194.147748] __dev_queue_xmit+0x54a/0xb30 [ 194.154131] tap_get_user+0x2a8/0x9c0 [tap] [ 194.157358] tap_sendmsg+0x52/0x8e0 [tap] [ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net] [ 194.173631] handle_tx+0xcd/0xe0 [vhost_net] [ 194.176959] vhost_worker+0x76/0xb0 [vhost] [ 194.183667] kthread+0x118/0x140 [ 194.190358] ret_from_fork+0x1f/0x30 [ 194.193670] </TASK> In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags local variable in skb_segment() stale. This resulted in the code hitting i >= nrfrags prematurely and trying to move to next frag_skb using list_skb pointer, which was NULL, and caused kernel panic. Move the call to zero copy functions before using frags and nr_frags. Fixes: bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions once per nskb") Signed-off-by: Mohamed Khalfella <[email protected]> Reported-by: Amit Goyal <[email protected]> Cc: [email protected] Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dan Carpenter <[email protected]> Date: Thu Jul 6 08:52:39 2023 +0300 smackfs: Prevent underflow in smk_set_cipso() [ Upstream commit 3ad49d37cf5759c3b8b68d02e3563f633d9c1aee ] There is a upper bound to "catlen" but no lower bound to prevent negatives. I don't see that this necessarily causes a problem but we may as well be safe. Fixes: e114e473771c ("Smack: Simplified Mandatory Access Control Kernel") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Casey Schaufler <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Mon May 29 10:41:15 2023 +0200 soc: qcom: ocmem: Add OCMEM hardware version print [ Upstream commit e81a16e77259294cd4ff0a9c1fbe5aa0e311a47d ] It might be useful to know what hardware version of the OCMEM block the SoC contains. Add a debug print for that. Signed-off-by: Luca Weiss <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Bjorn Andersson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Stable-dep-of: a7b484b1c933 ("soc: qcom: ocmem: Fix NUM_PORTS & NUM_MACROS macros") Signed-off-by: Sasha Levin <[email protected]>
Author: Luca Weiss <[email protected]> Date: Wed Jun 14 18:35:47 2023 +0200 soc: qcom: ocmem: Fix NUM_PORTS & NUM_MACROS macros [ Upstream commit a7b484b1c9332a1ee12e8799d62a11ee3f8e0801 ] Since we're using these two macros to read a value from a register, we need to use the FIELD_GET instead of the FIELD_PREP macro, otherwise we're getting wrong values. So instead of: [ 3.111779] ocmem fdd00000.sram: 2 ports, 1 regions, 512 macros, not interleaved we now get the correct value of: [ 3.129672] ocmem fdd00000.sram: 2 ports, 1 regions, 2 macros, not interleaved Fixes: 88c1e9404f1d ("soc: qcom: add OCMEM driver") Reviewed-by: Caleb Connolly <[email protected]> Reviewed-by: Konrad Dybcio <[email protected]> Signed-off-by: Luca Weiss <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Chris Lew <[email protected]> Date: Tue Aug 1 12:17:12 2023 +0530 soc: qcom: qmi_encdec: Restrict string length in decode commit 8d207400fd6b79c92aeb2f33bb79f62dff904ea2 upstream. The QMI TLV value for strings in a lot of qmi element info structures account for null terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of bounds access when the NULL character is appended in decoding. Fixes: 9b8a11e82615 ("soc: qcom: Introduce QMI encoder/decoder") Cc: [email protected] Signed-off-by: Chris Lew <[email protected]> Signed-off-by: Praveenkumar I <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Bjorn Andersson <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Zhang Shurong <[email protected]> Date: Sat Jul 22 23:49:09 2023 +0800 spi: tegra20-sflash: fix to check return value of platform_get_irq() in tegra_sflash_probe() [ Upstream commit 29a449e765ff70a5bd533be94babb6d36985d096 ] The platform_get_irq might be failed and return a negative result. So there should have an error handling code. Fixed this by adding an error handling code. Fixes: 8528547bcc33 ("spi: tegra: add spi driver for sflash controller") Signed-off-by: Zhang Shurong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Eric Dumazet <[email protected]> Date: Tue Jul 18 16:20:49 2023 +0000 tcp: tcp_enter_quickack_mode() should be static [ Upstream commit 03b123debcbc8db987bda17ed8412cc011064c22 ] After commit d2ccd7bc8acd ("tcp: avoid resetting ACK timer in DCTCP"), tcp_enter_quickack_mode() is only used from net/ipv4/tcp_input.c. Fixes: d2ccd7bc8acd ("tcp: avoid resetting ACK timer in DCTCP") Signed-off-by: Eric Dumazet <[email protected]> Cc: Yuchung Cheng <[email protected]> Cc: Neal Cardwell <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Christian Brauner <[email protected]> Date: Tue Aug 1 18:17:04 2023 +0200 tmpfs: verify {g,u}id mount options correctly [ Upstream commit 0200679fc7953177941e41c2a4241d0b6c2c5de8 ] A while ago we received the following report: "The other outstanding issue I noticed comes from the fact that fsconfig syscalls may occur in a different userns than that which called fsopen. That means that resolving the uid/gid via current_user_ns() can save a kuid that isn't mapped in the associated namespace when the filesystem is finally mounted. This means that it is possible for an unprivileged user to create files owned by any group in a tmpfs mount (since we can set the SUID bit on the tmpfs directory), or a tmpfs that is owned by any user, including the root group/user." The contract for {g,u}id mount options and {g,u}id values in general set from userspace has always been that they are translated according to the caller's idmapping. In so far, tmpfs has been doing the correct thing. But since tmpfs is mountable in unprivileged contexts it is also necessary to verify that the resulting {k,g}uid is representable in the namespace of the superblock to avoid such bugs as above. The new mount api's cross-namespace delegation abilities are already widely used. After having talked to a bunch of userspace this is the most faithful solution with minimal regression risks. I know of one users - systemd - that makes use of the new mount api in this way and they don't set unresolable {g,u}ids. So the regression risk is minimal. Link: https://lore.kernel.org/lkml/CALxfFW4BXhEwxR0Q5LSkg-8Vb4r2MONKCcUCVioehXQKr35eHg@mail.gmail.com Fixes: f32356261d44 ("vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API") Reviewed-by: "Seth Forshee (DigitalOcean)" <[email protected]> Reported-by: Seth Jenkins <[email protected]> Message-Id: <[email protected]> Signed-off-by: Christian Brauner <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Yejian <[email protected]> Date: Thu Aug 31 21:27:39 2023 +0800 tracing: Fix race issue between cpu buffer write and swap [ Upstream commit 3163f635b20e9e1fb4659e74f47918c9dddfe64e ] Warning happened in rb_end_commit() at code: if (RB_WARN_ON(cpu_buffer, !local_read(&cpu_buffer->committing))) WARNING: CPU: 0 PID: 139 at kernel/trace/ring_buffer.c:3142 rb_commit+0x402/0x4a0 Call Trace: ring_buffer_unlock_commit+0x42/0x250 trace_buffer_unlock_commit_regs+0x3b/0x250 trace_event_buffer_commit+0xe5/0x440 trace_event_buffer_reserve+0x11c/0x150 trace_event_raw_event_sched_switch+0x23c/0x2c0 __traceiter_sched_switch+0x59/0x80 __schedule+0x72b/0x1580 schedule+0x92/0x120 worker_thread+0xa0/0x6f0 It is because the race between writing event into cpu buffer and swapping cpu buffer through file per_cpu/cpu0/snapshot: Write on CPU 0 Swap buffer by per_cpu/cpu0/snapshot on CPU 1 -------- -------- tracing_snapshot_write() [...] ring_buffer_lock_reserve() cpu_buffer = buffer->buffers[cpu]; // 1. Suppose find 'cpu_buffer_a'; [...] rb_reserve_next_event() [...] ring_buffer_swap_cpu() if (local_read(&cpu_buffer_a->committing)) goto out_dec; if (local_read(&cpu_buffer_b->committing)) goto out_dec; buffer_a->buffers[cpu] = cpu_buffer_b; buffer_b->buffers[cpu] = cpu_buffer_a; // 2. cpu_buffer has swapped here. rb_start_commit(cpu_buffer); if (unlikely(READ_ONCE(cpu_buffer->buffer) != buffer)) { // 3. This check passed due to 'cpu_buffer->buffer' [...] // has not changed here. return NULL; } cpu_buffer_b->buffer = buffer_a; cpu_buffer_a->buffer = buffer_b; [...] // 4. Reserve event from 'cpu_buffer_a'. ring_buffer_unlock_commit() [...] cpu_buffer = buffer->buffers[cpu]; // 5. Now find 'cpu_buffer_b' !!! rb_commit(cpu_buffer) rb_end_commit() // 6. WARN for the wrong 'committing' state !!! Based on above analysis, we can easily reproduce by following testcase: ``` bash #!/bin/bash dmesg -n 7 sysctl -w kernel.panic_on_warn=1 TR=/sys/kernel/tracing echo 7 > ${TR}/buffer_size_kb echo "sched:sched_switch" > ${TR}/set_event while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & while [ true ]; do echo 1 > ${TR}/per_cpu/cpu0/snapshot done & ``` To fix it, IIUC, we can use smp_call_function_single() to do the swap on the target cpu where the buffer is located, so that above race would be avoided. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: <[email protected]> Fixes: f1affcaaa861 ("tracing: Add snapshot in the per_cpu trace directories") Signed-off-by: Zheng Yejian <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Zheng Yejian <[email protected]> Date: Fri Aug 18 10:26:45 2023 +0800 tracing: Introduce pipe_cpumask to avoid race on trace_pipes [ Upstream commit c2489bb7e6be2e8cdced12c16c42fa128403ac03 ] There is race issue when concurrently splice_read main trace_pipe and per_cpu trace_pipes which will result in data read out being different from what actually writen. As suggested by Steven: > I believe we should add a ref count to trace_pipe and the per_cpu > trace_pipes, where if they are opened, nothing else can read it. > > Opening trace_pipe locks all per_cpu ref counts, if any of them are > open, then the trace_pipe open will fail (and releases any ref counts > it had taken). > > Opening a per_cpu trace_pipe will up the ref count for just that > CPU buffer. This will allow multiple tasks to read different per_cpu > trace_pipe files, but will prevent the main trace_pipe file from > being opened. But because we only need to know whether per_cpu trace_pipe is open or not, using a cpumask instead of using ref count may be easier. After this patch, users will find that: - Main trace_pipe can be opened by only one user, and if it is opened, all per_cpu trace_pipes cannot be opened; - Per_cpu trace_pipes can be opened by multiple users, but each per_cpu trace_pipe can only be opened by one user. And if one of them is opened, main trace_pipe cannot be opened. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Suggested-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Zheng Yejian <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Mikhail Kobuk <[email protected]> Date: Fri Aug 25 13:34:30 2023 +0300 tracing: Remove extra space at the end of hwlat_detector/mode [ Upstream commit 2cf0dee989a8b2501929eaab29473b6b1fa11057 ] Space is printed after each mode value including the last one: $ echo \"$(sudo cat /sys/kernel/tracing/hwlat_detector/mode)\" "none [round-robin] per-cpu " Found by Linux Verification Center (linuxtesting.org) with SVACE. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: Masami Hiramatsu <[email protected]> Fixes: 8fa826b7344d ("trace/hwlat: Implement the mode config option") Signed-off-by: Mikhail Kobuk <[email protected]> Reviewed-by: Alexey Khoroshilov <[email protected]> Acked-by: Daniel Bristot de Oliveira <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Brian Foster <[email protected]> Date: Thu Aug 31 08:55:00 2023 -0400 tracing: Zero the pipe cpumask on alloc to avoid spurious -EBUSY commit 3d07fa1dd19035eb0b13ae6697efd5caa9033e74 upstream. The pipe cpumask used to serialize opens between the main and percpu trace pipes is not zeroed or initialized. This can result in spurious -EBUSY returns if underlying memory is not fully zeroed. This has been observed by immediate failure to read the main trace_pipe file on an otherwise newly booted and idle system: # cat /sys/kernel/debug/tracing/trace_pipe cat: /sys/kernel/debug/tracing/trace_pipe: Device or resource busy Zero the allocation of pipe_cpumask to avoid the problem. Link: https://lore.kernel.org/linux-trace-kernel/[email protected] Cc: [email protected] Fixes: c2489bb7e6be ("tracing: Introduce pipe_cpumask to avoid race on trace_pipes") Reviewed-by: Zheng Yejian <[email protected]> Reviewed-by: Masami Hiramatsu (Google) <[email protected]> Signed-off-by: Brian Foster <[email protected]> Signed-off-by: Steven Rostedt (Google) <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Vladislav Efanov <[email protected]> Date: Thu Feb 2 17:04:56 2023 +0300 udf: Check consistency of Space Bitmap Descriptor commit 1e0d4adf17e7ef03281d7b16555e7c1508c8ed2d upstream. Bits, which are related to Bitmap Descriptor logical blocks, are not reset when buffer headers are allocated for them. As the result, these logical blocks can be treated as free and be used for other blocks.This can cause usage of one buffer header for several types of data. UDF issues WARNING in this situation: WARNING: CPU: 0 PID: 2703 at fs/udf/inode.c:2014 __udf_add_aext+0x685/0x7d0 fs/udf/inode.c:2014 RIP: 0010:__udf_add_aext+0x685/0x7d0 fs/udf/inode.c:2014 Call Trace: udf_setup_indirect_aext+0x573/0x880 fs/udf/inode.c:1980 udf_add_aext+0x208/0x2e0 fs/udf/inode.c:2067 udf_insert_aext fs/udf/inode.c:2233 [inline] udf_update_extents fs/udf/inode.c:1181 [inline] inode_getblk+0x1981/0x3b70 fs/udf/inode.c:885 Found by Linux Verification Center (linuxtesting.org) with syzkaller. [JK: Somewhat cleaned up the boundary checks] Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Vladislav Efanov <[email protected]> Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Jan Kara <[email protected]> Date: Mon Dec 19 20:10:35 2022 +0100 udf: Handle error when adding extent to a file commit 19fd80de0a8b5170ef34704c8984cca920dffa59 upstream. When adding extent to a file fails, so far we've silently squelshed the error. Make sure to propagate it up properly. Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Tom Rix <[email protected]> Date: Fri Dec 30 12:53:41 2022 -0500 udf: initialize newblock to 0 commit 23970a1c9475b305770fd37bebfec7a10f263787 upstream. The clang build reports this error fs/udf/inode.c:805:6: error: variable 'newblock' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] if (*err < 0) ^~~~~~~~ newblock is never set before error handling jump. Initialize newblock to 0 and remove redundant settings. Fixes: d8b39db5fab8 ("udf: Handle error when adding extent to a file") Reported-by: Nathan Chancellor <[email protected]> Signed-off-by: Tom Rix <[email protected]> Signed-off-by: Jan Kara <[email protected]> Message-Id: <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Lorenz Bauer <[email protected]> Date: Thu Jul 20 17:30:05 2023 +0200 udp: re-score reuseport groups when connected sockets are present [ Upstream commit f0ea27e7bfe1c34e1f451a63eb68faa1d4c3a86d ] Contrary to TCP, UDP reuseport groups can contain TCP_ESTABLISHED sockets. To support these properly we remember whether a group has a connected socket and skip the fast reuseport early-return. In effect we continue scoring all reuseport sockets and then choose the one with the highest score. The current code fails to re-calculate the score for the result of lookup_reuseport. According to Kuniyuki Iwashima: 1) SO_INCOMING_CPU is set -> selected sk might have +1 score 2) BPF prog returns ESTABLISHED and/or SO_INCOMING_CPU sk -> selected sk will have more than 8 Using the old score could trigger more lookups depending on the order that sockets are created. sk -> sk (SO_INCOMING_CPU) -> sk (ESTABLISHED) | | `-> select the next SO_INCOMING_CPU sk | `-> select itself (We should save this lookup) Fixes: efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") Reviewed-by: Kuniyuki Iwashima <[email protected]> Signed-off-by: Lorenz Bauer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin KaFai Lau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Tue Aug 1 22:15:00 2023 -0700 um: Fix hostaudio build errors [ Upstream commit db4bfcba7bb8d10f00bba2a3da6b9a9c2a1d7b71 ] Use "select" to ensure that the required kconfig symbols are set as expected. Drop HOSTAUDIO since it is now equivalent to UML_SOUND. Set CONFIG_SOUND=m in ARCH=um defconfig files to maintain the status quo of the default configs. Allow SOUND with UML regardless of HAS_IOMEM. Otherwise there is a kconfig warning for unmet dependencies. (This was not an issue when SOUND was defined in arch/um/drivers/Kconfig. I have done 50 randconfig builds and didn't find any issues.) This fixes build errors when CONFIG_SOUND is not set: ld: arch/um/drivers/hostaudio_kern.o: in function `hostaudio_cleanup_module': hostaudio_kern.c:(.exit.text+0xa): undefined reference to `unregister_sound_mixer' ld: hostaudio_kern.c:(.exit.text+0x15): undefined reference to `unregister_sound_dsp' ld: arch/um/drivers/hostaudio_kern.o: in function `hostaudio_init_module': hostaudio_kern.c:(.init.text+0x19): undefined reference to `register_sound_dsp' ld: hostaudio_kern.c:(.init.text+0x31): undefined reference to `register_sound_mixer' ld: hostaudio_kern.c:(.init.text+0x49): undefined reference to `unregister_sound_dsp' and this kconfig warning: WARNING: unmet direct dependencies detected for SOUND Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: d886e87cb82b ("sound: make OSS sound core optional") Signed-off-by: Randy Dunlap <[email protected]> Reported-by: kernel test robot <[email protected]> Closes: lore.kernel.org/r/[email protected] Cc: Richard Weinberger <[email protected]> Cc: Anton Ivanov <[email protected]> Cc: Johannes Berg <[email protected]> Cc: [email protected] Cc: Tejun Heo <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Jaroslav Kysela <[email protected]> Cc: Masahiro Yamada <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Nicolas Schier <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Alan Stern <[email protected]> Date: Fri Aug 4 15:12:21 2023 -0400 USB: core: Change usb_get_device_descriptor() API commit de28e469da75359a2bb8cd8778b78aa64b1be1f4 upstream. The usb_get_device_descriptor() routine reads the device descriptor from the udev device and stores it directly in udev->descriptor. This interface is error prone, because the USB subsystem expects in-memory copies of a device's descriptors to be immutable once the device has been initialized. The interface is changed so that the device descriptor is left in a kmalloc-ed buffer, not copied into the usb_device structure. A pointer to the buffer is returned to the caller, who is then responsible for kfree-ing it. The corresponding changes needed in the various callers are fairly small. Signed-off-by: Alan Stern <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alan Stern <[email protected]> Date: Fri Aug 11 13:38:46 2023 -0400 USB: core: Fix oversight in SuperSpeed initialization commit 59cf445754566984fd55af19ba7146c76e6627bc upstream. Commit 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") altered the way USB devices are enumerated following detection, and in the process it messed up the initialization of SuperSpeed (or faster) devices: [ 31.650759] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd [ 31.663107] usb 2-1: device descriptor read/8, error -71 [ 31.952697] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd [ 31.965122] usb 2-1: device descriptor read/8, error -71 [ 32.080991] usb usb2-port1: attempt power cycle ... The problem was caused by the commit forgetting that in SuperSpeed or faster devices, the device descriptor uses a logarithmic encoding of the bMaxPacketSize0 value. (For some reason I thought the 255 case in the switch statement was meant for these devices, but it isn't -- it was meant for Wireless USB and is no longer needed.) We can fix the oversight by testing for buf->bMaxPacketSize0 = 9 (meaning 512, the actual maxpacket size for ep0 on all SuperSpeed devices) and straightening out the logic that checks and adjusts our initial guesses of the maxpacket value. Reported-and-tested-by: Thinh Nguyen <[email protected]> Closes: https://lore.kernel.org/linux-usb/[email protected]/ Signed-off-by: Alan Stern <[email protected]> Fixes: 85d07c556216 ("USB: core: Unite old scheme and new scheme descriptor reads") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alan Stern <[email protected]> Date: Fri Aug 4 15:14:14 2023 -0400 USB: core: Fix race by not overwriting udev->descriptor in hub_port_init() commit ff33299ec8bb80cdcc073ad9c506bd79bb2ed20b upstream. Syzbot reported an out-of-bounds read in sysfs.c:read_descriptors(): BUG: KASAN: slab-out-of-bounds in read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 Read of size 8 at addr ffff88801e78b8c8 by task udevd/5011 CPU: 0 PID: 5011 Comm: udevd Not tainted 6.4.0-rc6-syzkaller-00195-g40f71e7cd3c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 read_descriptors+0x263/0x280 drivers/usb/core/sysfs.c:883 ... Allocated by task 758: ... __do_kmalloc_node mm/slab_common.c:966 [inline] __kmalloc+0x5e/0x190 mm/slab_common.c:979 kmalloc include/linux/slab.h:563 [inline] kzalloc include/linux/slab.h:680 [inline] usb_get_configuration+0x1f7/0x5170 drivers/usb/core/config.c:887 usb_enumerate_device drivers/usb/core/hub.c:2407 [inline] usb_new_device+0x12b0/0x19d0 drivers/usb/core/hub.c:2545 As analyzed by Khazhy Kumykov, the cause of this bug is a race between read_descriptors() and hub_port_init(): The first routine uses a field in udev->descriptor, not expecting it to change, while the second overwrites it. Prior to commit 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") this race couldn't occur, because the routines were mutually exclusive thanks to the device locking. Removing that locking from read_descriptors() exposed it to the race. The best way to fix the bug is to keep hub_port_init() from changing udev->descriptor once udev has been initialized and registered. Drivers expect the descriptors stored in the kernel to be immutable; we should not undermine this expectation. In fact, this change should have been made long ago. So now hub_port_init() will take an additional argument, specifying a buffer in which to store the device descriptor it reads. (If udev has not yet been initialized, the buffer pointer will be NULL and then hub_port_init() will store the device descriptor in udev as before.) This eliminates the data race responsible for the out-of-bounds read. The changes to hub_port_init() appear more extensive than they really are, because of indentation changes resulting from an attempt to avoid writing to other parts of the usb_device structure after it has been initialized. Similar changes should be made to the code that reads the BOS descriptor, but that can be handled in a separate patch later on. This patch is sufficient to fix the bug found by syzbot. Reported-and-tested-by: [email protected] Closes: https://lore.kernel.org/linux-usb/[email protected]/#r Signed-off-by: Alan Stern <[email protected]> Cc: Khazhy Kumykov <[email protected]> Fixes: 45bf39f8df7f ("USB: core: Don't hold device lock while reading the "descriptors" sysfs file") Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alan Stern <[email protected]> Date: Fri Aug 4 15:10:59 2023 -0400 USB: core: Unite old scheme and new scheme descriptor reads commit 85d07c55621676d47d873d2749b88f783cd4d5a1 upstream. In preparation for reworking the usb_get_device_descriptor() routine, it is desirable to unite the two different code paths responsible for initially determining endpoint 0's maximum packet size in a newly discovered USB device. Making this determination presents a chicken-and-egg sort of problem, in that the only way to learn the maxpacket value is to get it from the device descriptor retrieved from the device, but communicating with the device to retrieve a descriptor requires us to know beforehand the ep0 maxpacket size. In practice this problem is solved in two different ways, referred to in hub.c as the "old scheme" and the "new scheme". The old scheme (which is the approach recommended by the USB-2 spec) involves asking the device to send just the first eight bytes of its device descriptor. Such a transfer uses packets containing no more than eight bytes each, and every USB device must have an ep0 maxpacket size >= 8, so this should succeed. Since the bMaxPacketSize0 field of the device descriptor lies within the first eight bytes, this is all we need. The new scheme is an imitation of the technique used in an early Windows USB implementation, giving it the happy advantage of working with a wide variety of devices (some of them at the time would not work with the old scheme, although that's probably less true now). It involves making an initial guess of the ep0 maxpacket size, asking the device to send up to 64 bytes worth of its device descriptor (which is only 18 bytes long), and then resetting the device to clear any error condition that might have resulted from the guess being wrong. The initial guess is determined by the connection speed; it should be correct in all cases other than full speed, for which the allowed values are 8, 16, 32, and 64 (in this case the initial guess is 64). The reason for this patch is that the old- and new-scheme parts of hub_port_init() use different code paths, one involving usb_get_device_descriptor() and one not, for their initial reads of the device descriptor. Since these reads have essentially the same purpose and are made under essentially the same circumstances, this is illogical. It makes more sense to have both of them use a common subroutine. This subroutine does basically what the new scheme's code did, because that approach is more general than the one used by the old scheme. It only needs to know how many bytes to transfer and whether or not it is being called for the first iteration of a retry loop (in case of certain time-out errors). There are two main differences from the former code: We initialize the bDescriptorType field of the transfer buffer to 0 before performing the transfer, to avoid possibly accessing an uninitialized value afterward. We read the device descriptor into a temporary buffer rather than storing it directly into udev->descriptor, which the old scheme implementation used to do. Since the whole point of this first read of the device descriptor is to determine the bMaxPacketSize0 value, that is what the new routine returns (or an error code). The value is stored in a local variable rather than in udev->descriptor. As a side effect, this necessitates moving a section of code that checks the bcdUSB field for SuperSpeed devices until after the full device descriptor has been retrieved. Signed-off-by: Alan Stern <[email protected]> Cc: Oliver Neukum <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Alan Stern <[email protected]> Date: Fri Aug 11 13:47:04 2023 -0400 USB: gadget: f_mass_storage: Fix unused variable warning [ Upstream commit 55c3e571d2a0aabef4f1354604443f1c415d2e85 ] Fix a "variable set but not used" warning in f_mass_storage.c. rc is used if verbose debugging is enabled but not otherwise. Signed-off-by: Alan Stern <[email protected]> Fixes: d5e2b67aae79 ("USB: g_mass_storage: template f_mass_storage.c file created") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Xu Yang <[email protected]> Date: Tue Jun 27 19:03:52 2023 +0800 usb: phy: mxs: fix getting wrong state with mxs_phy_is_otg_host() [ Upstream commit 5eda42aebb7668b4dcff025cd3ccb0d3d7c53da6 ] The function mxs_phy_is_otg_host() will return true if OTG_ID_VALUE is 0 at USBPHY_CTRL register. However, OTG_ID_VALUE will not reflect the real state if the ID pin is float, such as Host-only or Type-C cases. The value of OTG_ID_VALUE is always 1 which means device mode. This patch will fix the issue by judging the current mode based on last_event. The controller will update last_event in time. Fixes: 7b09e67639d6 ("usb: phy: mxs: refine mxs_phy_disconnect_line") Signed-off-by: Xu Yang <[email protected]> Acked-by: Peter Chen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: RD Babiera <[email protected]> Date: Mon Aug 14 18:05:59 2023 +0000 usb: typec: bus: verify partner exists in typec_altmode_attention commit f23643306430f86e2f413ee2b986e0773e79da31 upstream. Some usb hubs will negotiate DisplayPort Alt mode with the device but will then negotiate a data role swap after entering the alt mode. The data role swap causes the device to unregister all alt modes, however the usb hub will still send Attention messages even after failing to reregister the Alt Mode. type_altmode_attention currently does not verify whether or not a device's altmode partner exists, which results in a NULL pointer error when dereferencing the typec_altmode and typec_altmode_ops belonging to the altmode partner. Verify the presence of a device's altmode partner before sending the Attention message to the Alt Mode driver. Fixes: 8a37d87d72f0 ("usb: typec: Bus type for alternate modes") Cc: [email protected] Signed-off-by: RD Babiera <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: RD Babiera <[email protected]> Date: Mon Jul 31 16:59:23 2023 +0000 usb: typec: tcpm: set initial svdm version based on pd revision commit c97cd0b4b54eb42aed7f6c3c295a2d137f6d2416 upstream. When sending Discover Identity messages to a Port Partner that uses Power Delivery v2 and SVDM v1, we currently send PD v2 messages with SVDM v2.0, expecting the port partner to respond with its highest supported SVDM version as stated in Section 6.4.4.2.3 in the Power Delivery v3 specification. However, sending SVDM v2 to some Power Delivery v2 port partners results in a NAK whereas sending SVDM v1 does not. NAK messages can be handled by the initiator (PD v3 section 6.4.4.2.5.1), and one solution could be to resend Discover Identity on a lower SVDM version if possible. But, Section 6.4.4.3 of PD v2 states that "A NAK response Should be taken as an indication not to retry that particular Command." Instead, we can set the SVDM version to the maximum one supported by the negotiated PD revision. When operating in PD v2, this obeys Section 6.4.4.2.3, which states the SVDM field "Shall be set to zero to indicate Version 1.0." In PD v3, the SVDM field "Shall be set to 01b to indicate Version 2.0." Fixes: c34e85fa69b9 ("usb: typec: tcpm: Send DISCOVER_IDENTITY from dedicated work") Cc: [email protected] Signed-off-by: RD Babiera <[email protected]> Reviewed-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Liang Chen <[email protected]> Date: Fri Sep 1 12:09:21 2023 +0800 veth: Fixing transmit return status for dropped packets [ Upstream commit 151e887d8ff97e2e42110ffa1fb1e6a2128fb364 ] The veth_xmit function returns NETDEV_TX_OK even when packets are dropped. This behavior leads to incorrect calculations of statistics counts, as well as things like txq->trans_start updates. Fixes: e314dbdc1c0d ("[NET]: Virtual ethernet device driver.") Signed-off-by: Liang Chen <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Stefan Hajnoczi <[email protected]> Date: Tue Aug 1 11:53:52 2023 -0400 vfio/type1: fix cap_migration information leak [ Upstream commit cd24e2a60af633f157d7e59c0a6dba64f131c0b1 ] Fix an information leak where an uninitialized hole in struct vfio_iommu_type1_info_cap_migration on the stack is exposed to userspace. The definition of struct vfio_iommu_type1_info_cap_migration contains a hole as shown in this pahole(1) output: struct vfio_iommu_type1_info_cap_migration { struct vfio_info_cap_header header; /* 0 8 */ __u32 flags; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __u64 pgsize_bitmap; /* 16 8 */ __u64 max_dirty_bitmap_size; /* 24 8 */ /* size: 32, cachelines: 1, members: 4 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ }; The cap_mig variable is filled in without initializing the hole: static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps) { struct vfio_iommu_type1_info_cap_migration cap_mig; cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION; cap_mig.header.version = 1; cap_mig.flags = 0; /* support minimum pgsize */ cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap); cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX; return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig)); } The structure is then copied to a temporary location on the heap. At this point it's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspace later: int vfio_info_add_capability(struct vfio_info_cap *caps, struct vfio_info_cap_header *cap, size_t size) { struct vfio_info_cap_header *header; header = vfio_info_cap_add(caps, size, cap->id, cap->version); if (IS_ERR(header)) return PTR_ERR(header); memcpy(header + 1, cap + 1, size - sizeof(*header)); return 0; } This issue was found by code inspection. Signed-off-by: Stefan Hajnoczi <[email protected]> Reviewed-by: Kevin Tian <[email protected]> Fixes: ad721705d09c ("vfio iommu: Add migration capability to report supported features") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Alex Williamson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Yuan Yao <[email protected]> Date: Tue Aug 8 05:10:59 2023 +0000 virtio_ring: fix avail_wrap_counter in virtqueue_add_packed [ Upstream commit 1acfe2c1225899eab5ab724c91b7e1eb2881b9ab ] In current packed virtqueue implementation, the avail_wrap_counter won't flip, in the case when the driver supplies a descriptor chain with a length equals to the queue size; total_sg == vq->packed.vring.num. Let’s assume the following situation: vq->packed.vring.num=4 vq->packed.next_avail_idx: 1 vq->packed.avail_wrap_counter: 0 Then the driver adds a descriptor chain containing 4 descriptors. We expect the following result with avail_wrap_counter flipped: vq->packed.next_avail_idx: 1 vq->packed.avail_wrap_counter: 1 But, the current implementation gives the following result: vq->packed.next_avail_idx: 1 vq->packed.avail_wrap_counter: 0 To reproduce the bug, you can set a packed queue size as small as possible, so that the driver is more likely to provide a descriptor chain with a length equal to the packed queue size. For example, in qemu run following commands: sudo qemu-system-x86_64 \ -enable-kvm \ -nographic \ -kernel "path/to/kernel_image" \ -m 1G \ -drive file="path/to/rootfs",if=none,id=disk \ -device virtio-blk,drive=disk \ -drive file="path/to/disk_image",if=none,id=rwdisk \ -device virtio-blk,drive=rwdisk,packed=on,queue-size=4,\ indirect_desc=off \ -append "console=ttyS0 root=/dev/vda rw init=/bin/bash" Inside the VM, create a directory and mount the rwdisk device on it. The rwdisk will hang and mount operation will not complete. This commit fixes the wrap counter error by flipping the packed.avail_wrap_counter, when start of descriptor chain equals to the end of descriptor chain (head == i). Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") Signed-off-by: Yuan Yao <[email protected]> Message-Id: <[email protected]> Acked-by: Jason Wang <[email protected]> Signed-off-by: Michael S. Tsirkin <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ani Sinha <[email protected]> Date: Wed Jul 5 19:14:07 2023 +0530 vmbus_testing: fix wrong python syntax for integer value comparison [ Upstream commit ed0cf84e9cc42e6310961c87709621f1825c2bb8 ] It is incorrect in python to compare integer values using the "is" keyword. The "is" keyword in python is used to compare references to two objects, not their values. Newer version of python3 (version 3.8) throws a warning when such incorrect comparison is made. For value comparison, "==" should be used. Fix this in the code and suppress the following warning: /usr/sbin/vmbus_testing:167: SyntaxWarning: "is" with a literal. Did you mean "=="? Signed-off-by: Ani Sinha <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Wei Liu <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Jiri Benc <[email protected]> Date: Fri Jul 21 16:30:46 2023 +0200 vxlan: generalize vxlan_parse_gpe_hdr and remove unused args [ Upstream commit 17a0a64448b568442a101de09575f81ffdc45d15 ] The vxlan_parse_gpe_hdr function extracts the next protocol value from the GPE header and marks GPE bits as parsed. In order to be used in the next patch, split the function into protocol extraction and bit marking. The bit marking is meaningful only in vxlan_rcv; move it directly there. Rename the function to vxlan_parse_gpe_proto to reflect what it now does. Remove unused arguments skb and vxflags. Move the function earlier in the file to allow it to be called from more places in the next patch. Signed-off-by: Jiri Benc <[email protected]> Signed-off-by: David S. Miller <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Raag Jadav <[email protected]> Date: Fri Aug 11 17:32:20 2023 +0530 watchdog: intel-mid_wdt: add MODULE_ALIAS() to allow auto-load [ Upstream commit cf38e7691c85f1b09973b22a0b89bf1e1228d2f9 ] When built with CONFIG_INTEL_MID_WATCHDOG=m, currently the driver needs to be loaded manually, for the lack of module alias. This causes unintended resets in cases where watchdog timer is set-up by bootloader and the driver is not explicitly loaded. Add MODULE_ALIAS() to load the driver automatically at boot and avoid this issue. Fixes: 87a1ef8058d9 ("watchdog: add Intel MID watchdog driver support") Signed-off-by: Raag Jadav <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:05:02 2023 +0300 wifi: ath10k: Use RMW accessors for changing LNKCTL [ Upstream commit f139492a09f15254fa261245cdbd65555cdf39e3 ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. Use RMW capability accessors which does proper locking to avoid losing concurrent updates to the register value. On restore, clear the ASPMC field properly. Suggested-by: Lukas Wunner <[email protected]> Fixes: 76d870ed09ab ("ath10k: enable ASPM") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Kalle Valo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ilpo Järvinen <[email protected]> Date: Mon Jul 17 15:05:00 2023 +0300 wifi: ath11k: Use RMW accessors for changing LNKCTL [ Upstream commit 6c1b6bdb34aaf8f94f65a9cae1d63490320c11bc ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. On restore, clear the ASPMC field properly. Suggested-by: Lukas Wunner <[email protected]> Fixes: e9603f4bdcc0 ("ath11k: pci: disable ASPM L0sLs before downloading firmware") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ilpo Järvinen <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Simon Horman <[email protected]> Acked-by: Kalle Valo <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Tue Apr 25 22:26:06 2023 +0300 wifi: ath9k: fix races between ath9k_wmi_cmd and ath9k_wmi_ctrl_rx [ Upstream commit b674fb513e2e7a514fcde287c0f73915d393fdb6 ] Currently, the synchronization between ath9k_wmi_cmd() and ath9k_wmi_ctrl_rx() is exposed to a race condition which, although being rather unlikely, can lead to invalid behaviour of ath9k_wmi_cmd(). Consider the following scenario: CPU0 CPU1 ath9k_wmi_cmd(...) mutex_lock(&wmi->op_mutex) ath9k_wmi_cmd_issue(...) wait_for_completion_timeout(...) --- timeout --- /* the callback is being processed * before last_seq_id became zero */ ath9k_wmi_ctrl_rx(...) spin_lock_irqsave(...) /* wmi->last_seq_id check here * doesn't detect timeout yet */ spin_unlock_irqrestore(...) /* last_seq_id is zeroed to * indicate there was a timeout */ wmi->last_seq_id = 0 mutex_unlock(&wmi->op_mutex) return -ETIMEDOUT ath9k_wmi_cmd(...) mutex_lock(&wmi->op_mutex) /* the buffer is replaced with * another one */ wmi->cmd_rsp_buf = rsp_buf wmi->cmd_rsp_len = rsp_len ath9k_wmi_cmd_issue(...) spin_lock_irqsave(...) spin_unlock_irqrestore(...) wait_for_completion_timeout(...) /* the continuation of the * callback left after the first * ath9k_wmi_cmd call */ ath9k_wmi_rsp_callback(...) /* copying data designated * to already timeouted * WMI command into an * inappropriate wmi_cmd_buf */ memcpy(...) complete(&wmi->cmd_wait) /* awakened by the bogus callback * => invalid return result */ mutex_unlock(&wmi->op_mutex) return 0 To fix this, update last_seq_id on timeout path inside ath9k_wmi_cmd() under the wmi_lock. Move ath9k_wmi_rsp_callback() under wmi_lock inside ath9k_wmi_ctrl_rx() so that the wmi->cmd_wait can be completed only for initially designated wmi_cmd call, otherwise the path would be rejected with last_seq_id check. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Fedor Pchelkin <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Fedor Pchelkin <[email protected]> Date: Tue Apr 25 22:26:07 2023 +0300 wifi: ath9k: protect WMI command response buffer replacement with a lock [ Upstream commit 454994cfa9e4c18b6df9f78b60db8eadc20a6c25 ] If ath9k_wmi_cmd() has exited with a timeout, it is possible that during next ath9k_wmi_cmd() call the wmi_rsp callback for previous wmi command writes to new wmi->cmd_rsp_buf and makes a completion. This results in an invalid ath9k_wmi_cmd() return value. Move the replacement of WMI command response buffer and length under wmi_lock. Note that last_seq_id value is updated there, too. Thus, the buffer cannot be written to by a belated wmi_rsp callback because that path is properly rejected by the last_seq_id check. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: fb9987d0f748 ("ath9k_htc: Support for AR9271 chipset.") Signed-off-by: Fedor Pchelkin <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Wang Ming <[email protected]> Date: Thu Jul 13 11:03:44 2023 +0800 wifi: ath9k: use IS_ERR() with debugfs_create_dir() [ Upstream commit 1e4134610d93271535ecf900a676e1f094e9944c ] The debugfs_create_dir() function returns error pointers, it never returns NULL. Most incorrect error checks were fixed, but the one in ath9k_htc_init_debug() was forgotten. Fix the remaining error check. Fixes: e5facc75fa91 ("ath9k_htc: Cleanup HTC debugfs") Signed-off-by: Wang Ming <[email protected]> Acked-by: Toke Høiland-Jørgensen <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Hans de Goede <[email protected]> Date: Sat Jul 29 16:05:00 2023 +0200 wifi: brcmfmac: Fix field-spanning write in brcmf_scan_params_v2_to_v1() [ Upstream commit 16e455a465fca91907af0108f3d013150386df30 ] Using brcmfmac with 6.5-rc3 on a brcmfmac43241b4-sdio triggers a backtrace caused by the following field-spanning warning: memcpy: detected field-spanning write (size 120) of single field "¶ms_le->channel_list[0]" at drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c:1072 (size 2) The driver still works after this warning. The warning was introduced by the new field-spanning write checks which were enabled recently. Fix this by replacing the channel_list[1] declaration at the end of the struct with a flexible array declaration. Most users of struct brcmf_scan_params_le calculate the size to alloc using the size of the non flex-array part of the struct + needed extra space, so they do not care about sizeof(struct brcmf_scan_params_le). brcmf_notify_escan_complete() however uses the struct on the stack, expecting there to be room for at least 1 entry in the channel-list to store the special -1 abort channel-id. To make this work use an anonymous union with a padding member added + the actual channel_list flexible array. Cc: Kees Cook <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Kees Cook <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Ryder Lee <[email protected]> Date: Thu Jul 27 02:35:06 2023 +0800 wifi: mt76: mt7915: fix power-limits while chan_switch [ Upstream commit 6c0570bc21ec2073890aa252c8420ca7bec402e4 ] If user changes the channel without completely disabling the interface the txpower_sku values reported track the old channel the device was operating on. If user bounces the interface the correct power tables are applied. mt7915_sku_group_len array gets updated before the channel switch happens so it uses data from the old channel. Fixes: ecb187a74e18 ("mt76: mt7915: rework the flow of txpower setting") Fixes: f1d962369d56 ("mt76: mt7915: implement HE per-rate tx power support") Reported-By: Chad Monroe <[email protected]> Tested-by: Chad Monroe <[email protected]> Signed-off-by: Allen Ye <[email protected]> Signed-off-by: Ryder Lee <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Ma <[email protected]> Date: Sun Jul 23 16:03:50 2023 +0800 wifi: mt76: testmode: add nla_policy for MT76_TM_ATTR_TX_LENGTH [ Upstream commit 74f12d511625e603fac8c0c2b6872e687e56dd61 ] It seems that the nla_policy in mt76_tm_policy is missed for attribute MT76_TM_ATTR_TX_LENGTH. This patch adds the correct description to make sure the u32 val = nla_get_u32(tb[MT76_TM_ATTR_TX_LENGTH]); in function mt76_testmode_cmd() is safe and will not result in out-of-attribute read. Fixes: f0efa8621550 ("mt76: add API for testmode support") Signed-off-by: Lin Ma <[email protected]> Signed-off-by: Felix Fietkau <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Mon Aug 14 12:49:57 2023 +0300 wifi: mwifiex: avoid possible NULL skb pointer dereference [ Upstream commit 35a7a1ce7c7d61664ee54f5239a1f120ab95a87e ] In 'mwifiex_handle_uap_rx_forward()', always check the value returned by 'skb_copy()' to avoid potential NULL pointer dereference in 'mwifiex_uap_queue_bridged_pkt()', and drop original skb in case of copying failure. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 838e4f449297 ("mwifiex: improve uAP RX handling") Acked-by: Brian Norris <[email protected]> Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Mon Jul 31 10:43:07 2023 +0300 wifi: mwifiex: fix error recovery in PCIE buffer descriptor management [ Upstream commit 288c63d5cb4667a51a04668b3e2bb0ea499bc5f4 ] Add missing 'kfree_skb()' in 'mwifiex_init_rxq_ring()' and never do 'kfree(card->rxbd_ring_vbase)' because this area is DMAed and should be released with 'dma_free_coherent()'. The latter is performed in 'mwifiex_pcie_delete_rxbd_ring()', which is now called to recover from possible errors in 'mwifiex_pcie_create_rxbd_ring()'. Likewise for 'mwifiex_pcie_init_evt_ring()', 'kfree(card->evtbd_ring_vbase)' 'mwifiex_pcie_delete_evtbd_ring()' and 'mwifiex_pcie_create_rxbd_ring()'. Fixes: d930faee141b ("mwifiex: add support for Marvell pcie8766 chipset") Signed-off-by: Dmitry Antipov <[email protected]> Acked-by: Brian Norris <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Dmitry Antipov <[email protected]> Date: Wed Aug 2 19:07:15 2023 +0300 wifi: mwifiex: fix memory leak in mwifiex_histogram_read() [ Upstream commit 9c8fd72a5c2a031cbc680a2990107ecd958ffcdb ] Always free the zeroed page on return from 'mwifiex_histogram_read()'. Fixes: cbf6e05527a7 ("mwifiex: add rx histogram statistics support") Acked-by: Brian Norris <[email protected]> Signed-off-by: Dmitry Antipov <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Polaris Pi <[email protected]> Date: Thu Aug 10 08:39:11 2023 +0000 wifi: mwifiex: Fix missed return in oob checks failed path [ Upstream commit 2785851c627f2db05f9271f7f63661b5dbd95c4c ] Add missed return in mwifiex_uap_queue_bridged_pkt() and mwifiex_process_rx_packet(). Fixes: 119585281617 ("wifi: mwifiex: Fix OOB and integer underflow when rx packets") Signed-off-by: Polaris Pi <[email protected]> Reported-by: Dmitry Antipov <[email protected]> Acked-by: Brian Norris <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Polaris Pi <[email protected]> Date: Sun Jul 23 07:07:41 2023 +0000 wifi: mwifiex: Fix OOB and integer underflow when rx packets [ Upstream commit 11958528161731c58e105b501ed60b83a91ea941 ] Make sure mwifiex_process_mgmt_packet, mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet, mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet not out-of-bounds access the skb->data buffer. Fixes: 2dbaf751b1de ("mwifiex: report received management frames to cfg80211") Signed-off-by: Polaris Pi <[email protected]> Reviewed-by: Matthew Wang <[email protected]> Reviewed-by: Brian Norris <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Lin Ma <[email protected]> Date: Wed Aug 9 11:31:51 2023 +0800 wifi: nl80211/cfg80211: add forgotten nla_policy for BSS color attribute [ Upstream commit 218d690c49b7e9c94ad0d317adbdd4af846ea0dc ] The previous commit dd3e4fc75b4a ("nl80211/cfg80211: add BSS color to NDP ranging parameters") adds a parameter for NDP ranging by introducing a new attribute type named NL80211_PMSR_FTM_REQ_ATTR_BSS_COLOR. However, the author forgot to also describe the nla_policy at nl80211_pmsr_ftm_req_attr_policy (net/wireless/nl80211.c). Just complement it to avoid malformed attribute that causes out-of-attribute access. Fixes: dd3e4fc75b4a ("nl80211/cfg80211: add BSS color to NDP ranging parameters") Signed-off-by: Lin Ma <[email protected]> Reviewed-by: Simon Horman <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Thore Sommer <[email protected]> Date: Tue Aug 15 14:29:42 2023 +0300 X.509: if signature is unsupported skip validation commit ef5b52a631f8c18353e80ccab8408b963305510c upstream. When the hash algorithm for the signature is not available the digest size is 0 and the signature in the certificate is marked as unsupported. When validating a self-signed certificate, this needs to be checked, because otherwise trying to validate the signature will fail with an warning: Loading compiled-in X.509 certificates WARNING: CPU: 0 PID: 1 at crypto/rsa-pkcs1pad.c:537 \ pkcs1pad_verify+0x46/0x12c ... Problem loading in-kernel X.509 certificate (-22) Signed-off-by: Thore Sommer <[email protected]> Cc: [email protected] # v4.7+ Fixes: 6c2dc5ae4ab7 ("X.509: Extract signature digest and make self-signed cert checks earlier") Signed-off-by: Herbert Xu <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Randy Dunlap <[email protected]> Date: Thu Jul 27 18:11:20 2023 -0700 x86/APM: drop the duplicate APM_MINOR_DEV macro [ Upstream commit 4ba2909638a29630a346d6c4907a3105409bee7d ] This source file already includes <linux/miscdevice.h>, which contains the same macro. It doesn't need to be defined here again. Fixes: 874bcd00f520 ("apm-emulation: move APM_MINOR_DEV to include/linux/miscdevice.h") Signed-off-by: Randy Dunlap <[email protected]> Cc: Jiri Kosina <[email protected]> Cc: [email protected] Cc: Sohil Mehta <[email protected]> Cc: Corentin Labbe <[email protected]> Reviewed-by: Sohil Mehta <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Ard Biesheuvel <[email protected]> Date: Mon Aug 7 18:26:58 2023 +0200 x86/decompressor: Don't rely on upper 32 bits of GPRs being preserved [ Upstream commit 264b82fdb4989cf6a44a2bcd0c6ea05e8026b2ac ] The 4-to-5 level mode switch trampoline disables long mode and paging in order to be able to flick the LA57 bit. According to section 3.4.1.1 of the x86 architecture manual [0], 64-bit GPRs might not retain the upper 32 bits of their contents across such a mode switch. Given that RBP, RBX and RSI are live at this point, preserve them on the stack, along with the return address that might be above 4G as well. [0] Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 1: Basic Architecture "Because the upper 32 bits of 64-bit general-purpose registers are undefined in 32-bit modes, the upper 32 bits of any general-purpose register are not preserved when switching from 64-bit mode to a 32-bit mode (to protected mode or compatibility mode). Software must not depend on these bits to maintain a value after a 64-bit to 32-bit mode switch." Fixes: 194a9749c73d650c ("x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G") Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Borislav Petkov (AMD) <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Mikel Rychliski <[email protected]> Date: Wed Aug 23 17:51:58 2023 -0400 x86/efistub: Fix PCI ROM preservation in mixed mode [ Upstream commit 8b94da92559f7e403dc7ab81937cc50f949ee2fd ] preserve_pci_rom_image() was accessing the romsize field in efi_pci_io_protocol_t directly instead of using the efi_table_attr() helper. This prevents the ROM image from being saved correctly during a mixed mode boot. Fixes: 2c3625cb9fa2 ("efi/x86: Fold __setup_efi_pci32() and __setup_efi_pci64() into one function") Signed-off-by: Mikel Rychliski <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Janusz Krzysztofik <[email protected]> Date: Mon Jul 10 09:36:14 2023 +0200 x86/mm: Fix PAT bit missing from page protection modify mask [ Upstream commit 548cb932051fb6232ac983ed6673dae7bdf3cf4c ] Visible glitches have been observed when running graphics applications on Linux under Xen hypervisor. Those observations have been confirmed with failures from kms_pwrite_crc Intel GPU test that verifies data coherency of DRM frame buffer objects using hardware CRC checksums calculated by display controllers, exposed to userspace via debugfs. Affected processing paths have then been identified with new IGT test variants that mmap the objects using different methods and caching modes [1]. When running as a Xen PV guest, Linux uses Xen provided PAT configuration which is different from its native one. In particular, Xen specific PTE encoding of write-combining caching, likely used by graphics applications, differs from the Linux default one found among statically defined minimal set of supported modes. Since Xen defines PTE encoding of the WC mode as _PAGE_PAT, it no longer belongs to the minimal set, depends on correct handling of _PAGE_PAT bit, and can be mismatched with write-back caching. When a user calls mmap() for a DRM buffer object, DRM device specific .mmap file operation, called from mmap_region(), takes care of setting PTE encoding bits in a vm_page_prot field of an associated virtual memory area structure. Unfortunately, _PAGE_PAT bit is not preserved when the vma's .vm_flags are then applied to .vm_page_prot via vm_set_page_prot(). Bits to be preserved are determined with _PAGE_CHG_MASK symbol that doesn't cover _PAGE_PAT. As a consequence, WB caching is requested instead of WC when running under Xen (also, WP is silently changed to WT, and UC downgraded to UC_MINUS). When running on bare metal, WC is not affected, but WP and WT extra modes are unintentionally replaced with WC and UC, respectively. WP and WT modes, encoded with _PAGE_PAT bit set, were introduced by commit 281d4078bec3 ("x86: Make page cache mode a real type"). Care was taken to extend _PAGE_CACHE_MASK symbol with that additional bit, but that symbol has never been used for identification of bits preserved when applying page protection flags. Support for all cache modes under Xen, including the problematic WC mode, was then introduced by commit 47591df50512 ("xen: Support Xen pv-domains using PAT"). The issue needs to be fixed by including _PAGE_PAT bit into a bitmask used by pgprot_modify() for selecting bits to be preserved. We can do that either internally to pgprot_modify() (as initially proposed), or by making _PAGE_PAT a part of _PAGE_CHG_MASK. If we go for the latter then, since _PAGE_PAT is the same as _PAGE_PSE, we need to note that _HPAGE_CHG_MASK -- a huge pmds' counterpart of _PAGE_CHG_MASK, introduced by commit c489f1257b8c ("thp: add pmd_modify"), defined as (_PAGE_CHG_MASK | _PAGE_PSE) -- will no longer differ from _PAGE_CHG_MASK. If such modification of _PAGE_CHG_MASK was irrelevant to its users then one might wonder why that new _HPAGE_CHG_MASK symbol was introduced instead of reusing the existing one with that otherwise irrelevant bit (_PAGE_PSE in that case) added. Add _PAGE_PAT to _PAGE_CHG_MASK and _PAGE_PAT_LARGE to _HPAGE_CHG_MASK for symmetry. Split out common bits from both symbols to a common symbol for clarity. [ dhansen: tweak the solution changelog description ] [1] https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/0f0754413f14 Fixes: 281d4078bec3 ("x86: Make page cache mode a real type") Signed-off-by: Janusz Krzysztofik <[email protected]> Signed-off-by: Dave Hansen <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Juergen Gross <[email protected]> Tested-by: Marek Marczykowski-Górecki <[email protected]> Link: https://gitlab.freedesktop.org/drm/intel/-/issues/7648 Link: https://lore.kernel.org/all/20230710073613.8006-2-janusz.krzysztofik%40linux.intel.com Signed-off-by: Sasha Levin <[email protected]>
Author: Jack Wang <[email protected]> Date: Wed Sep 6 15:17:12 2023 +0200 x86/sgx: Break up long non-preemptible delays in sgx_vepc_release() commit 3d7d72a34e05b23e21bafc8bfb861e73c86b31f3 upstream. On large enclaves we hit the softlockup warning with following call trace: xa_erase() sgx_vepc_release() __fput() task_work_run() do_exit() The latency issue is similar to the one fixed in: 8795359e35bc ("x86/sgx: Silence softlockup detection when releasing large enclaves") The test system has 64GB of enclave memory, and all is assigned to a single VM. Release of 'vepc' takes a longer time and causes long latencies, which triggers the softlockup warning. Add cond_resched() to give other tasks a chance to run and reduce latencies, which also avoids the softlockup detector. [ mingo: Rewrote the changelog. ] Fixes: 540745ddbc70 ("x86/sgx: Introduce virtual EPC for use by KVM guests") Reported-by: Yu Zhang <[email protected]> Signed-off-by: Jack Wang <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Tested-by: Yu Zhang <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Reviewed-by: Kai Huang <[email protected]> Acked-by: Haitao Huang <[email protected]> Cc: [email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
Author: Dave Hansen <[email protected]> Date: Tue Aug 29 08:07:25 2023 -0700 x86/speculation: Mark all Skylake CPUs as vulnerable to GDS [ Upstream commit c9f4c45c8ec3f07f4f083f9750032a1ec3eab6b2 ] The Gather Data Sampling (GDS) vulnerability is common to all Skylake processors. However, the "client" Skylakes* are now in this list: https://www.intel.com/content/www/us/en/support/articles/000022396/processors.html which means they are no longer included for new vulnerabilities here: https://www.intel.com/content/www/us/en/developer/topic-technology/software-security-guidance/processors-affected-consolidated-product-cpu-model.html or in other GDS documentation. Thus, they were not included in the original GDS mitigation patches. Mark SKYLAKE and SKYLAKE_L as vulnerable to GDS to match all the other Skylake CPUs (which include Kaby Lake). Also group the CPUs so that the ones that share the exact same vulnerabilities are next to each other. Last, move SRBDS to the end of each line. This makes it clear at a glance that SKYLAKE_X is unique. Of the five Skylakes, it is the only "server" CPU and has a different implementation from the clients of the "special register" hardware, making it immune to SRBDS. This makes the diff much harder to read, but the resulting table is worth it. I very much appreciate the report from Michael Zhivich about this issue. Despite what level of support a hardware vendor is providing, the kernel very much needs an accurate and up-to-date list of vulnerable CPUs. More reports like this are very welcome. * Client Skylakes are CPUID 406E3/506E3 which is family 6, models 0x4E and 0x5E, aka INTEL_FAM6_SKYLAKE and INTEL_FAM6_SKYLAKE_L. Reported-by: Michael Zhivich <[email protected]> Fixes: 8974eb588283 ("x86/speculation: Add Gather Data Sampling mitigation") Signed-off-by: Dave Hansen <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Reviewed-by: Daniel Sneddon <[email protected]> Cc: Linus Torvalds <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Sean Christopherson <[email protected]> Date: Fri Jul 21 13:18:52 2023 -0700 x86/virt: Drop unnecessary check on extended CPUID level in cpu_has_svm() [ Upstream commit 5df8ecfe3632d5879d1f154f7aa8de441b5d1c89 ] Drop the explicit check on the extended CPUID level in cpu_has_svm(), the kernel's cached CPUID info will leave the entire SVM leaf unset if said leaf is not supported by hardware. Prior to using cached information, the check was needed to avoid false positives due to Intel's rather crazy CPUID behavior of returning the values of the maximum supported leaf if the specified leaf is unsupported. Fixes: 682a8108872f ("x86/kvm/svm: Simplify cpu_has_svm()") Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sean Christopherson <[email protected]> Signed-off-by: Sasha Levin <[email protected]>
Author: Magnus Karlsson <[email protected]> Date: Thu Aug 31 12:01:17 2023 +0200 xsk: Fix xsk_diag use-after-free error during socket cleanup [ Upstream commit 3e019d8a05a38abb5c85d4f1e85fda964610aa14 ] Fix a use-after-free error that is possible if the xsk_diag interface is used after the socket has been unbound from the device. This can happen either due to the socket being closed or the device disappearing. In the early days of AF_XDP, the way we tested that a socket was not bound to a device was to simply check if the netdevice pointer in the xsk socket structure was NULL. Later, a better system was introduced by having an explicit state variable in the xsk socket struct. For example, the state of a socket that is on the way to being closed and has been unbound from the device is XSK_UNBOUND. The commit in the Fixes tag below deleted the old way of signalling that a socket is unbound, setting dev to NULL. This in the belief that all code using the old way had been exterminated. That was unfortunately not true as the xsk diagnostics code was still using the old way and thus does not work as intended when a socket is going down. Fix this by introducing a test against the state variable. If the socket is in the state XSK_UNBOUND, simply abort the diagnostic's netlink operation. Fixes: 18b1ab7aa76b ("xsk: Fix race at socket teardown") Reported-by: [email protected] Signed-off-by: Magnus Karlsson <[email protected]> Signed-off-by: Daniel Borkmann <[email protected]> Tested-by: [email protected] Tested-by: Maciej Fijalkowski <[email protected]> Reviewed-by: Maciej Fijalkowski <[email protected]> Link: https://lore.kernel.org/bpf/[email protected] Signed-off-by: Sasha Levin <[email protected]>
Author: Max Filippov <[email protected]> Date: Mon Jul 24 00:58:24 2023 -0700 xtensa: PMU: fix base address for the newer hardware commit 687eb3c42f4ad81e7c947c50e2d865f692064291 upstream. With introduction of ERI access control in RG.0 base address of the PMU unit registers has changed. Add support for the new PMU configuration. Cc: [email protected] Signed-off-by: Max Filippov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>