commit 2b525314c7b57eac29fe8b77a6589428e4a4f6dd Author: Greg Kroah-Hartman Date: Mon Oct 24 09:58:32 2022 +0200 Linux 5.19.17 Link: https://lore.kernel.org/r/20221022072415.034382448@linuxfoundation.org Tested-by: Guenter Roeck Tested-by: Slade Watkins Tested-by: Ron Economos Tested-by: Luna Jernberg Tested-by: Allen Pais Signed-off-by: Greg Kroah-Hartman commit 65ea3311ce7c593a33e6324b113c9343a4afa260 Author: Ville Syrjälä Date: Thu Aug 18 22:22:23 2022 +0300 drm/i915/bios: Use hardcoded fp_timing size for generating LFP data pointers commit d3a7051841f0a4bcb1ee26a1b721c6150cc4c2b1 upstream. The current scheme for generating the LFP data table pointers (when the block including them is missing from the VBT) expects the 0xffff sequence to only appear in the fp_timing terminator entries. However some VBTs also have extra 0xffff sequences elsewhere in the LFP data. When looking for the terminators we may end up finding those extra sequeneces insted, which means we deduce the wrong size for the fp_timing table. The code then notices the inconsistent looking values and gives up on the generated data table pointers, preventing us from parsing the LFP data table entirely. Let's give up on the "search for the terminators" approach and instead just hardcode the expected size for the fp_timing table. We have enough sanity checks in place to make sure we shouldn't end up parsing total garbage even if that size should change in the future (although that seems unlikely as the fp_timing and dvo_timing tables have been declared obsolete as of VBT version 229). Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6592 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit a34bc0ff223f0a51bff0d658dff6c39cbb824804 Author: Ville Syrjälä Date: Thu Aug 18 22:22:22 2022 +0300 drm/i915/bios: Validate fp_timing terminator presence commit 4e78d6023c15c6acce8fbe42e13027c460395522 upstream. Validate the LFP data block a bit hardwer by making sure the fp_timing terminators (0xffff) are where we expect them to be. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220818192223.29881-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6ba258c8082f3a17b07734d8af6aa2d9655cde98 Author: Ville Syrjälä Date: Thu May 19 17:00:10 2022 +0300 drm/i915: Rename block_size()/block_offset() commit 39b1bc4b5bcccac781267bb826b035fbb99c8b9d upstream. Give block_size()/block_offset() a "raw_" prefix since they both operate on the "raw" (as in not duplicated) BDB block contents. What actually spurred this was a conflict between intel_bios.c block_size() vs. block_size() from blkdev.h. That only happened to me on a custom tree where we somehow manage to include blkdev.h into intel_bios.c. But I think the rename makes sense anyway to clarify the purpose of these functions. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220519140010.10600-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 25151f50686e9988c3bd10e83ee46a50759018ba Author: Jerry Lee 李修賢 Date: Mon Jul 18 10:25:19 2022 +0000 ext4: continue to expand file system when the target size doesn't reach commit df3cb754d13d2cd5490db9b8d536311f8413a92e upstream. When expanding a file system from (16TiB-2MiB) to 18TiB, the operation exits early which leads to result inconsistency between resize2fs and Ext4 kernel driver. === before === ○ → resize2fs /dev/mapper/thin resize2fs 1.45.5 (07-Jan-2020) Filesystem at /dev/mapper/thin is mounted on /mnt/test; on-line resizing required old_desc_blocks = 2048, new_desc_blocks = 2304 The filesystem on /dev/mapper/thin is now 4831837696 (4k) blocks long. [ 865.186308] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 912.091502] dm-4: detected capacity change from 34359738368 to 38654705664 [ 970.030550] dm-5: detected capacity change from 34359734272 to 38654701568 [ 1000.012751] EXT4-fs (dm-5): resizing filesystem from 4294966784 to 4831837696 blocks [ 1000.012878] EXT4-fs (dm-5): resized filesystem to 4294967296 === after === [ 129.104898] EXT4-fs (dm-5): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none. [ 143.773630] dm-4: detected capacity change from 34359738368 to 38654705664 [ 198.203246] dm-5: detected capacity change from 34359734272 to 38654701568 [ 207.918603] EXT4-fs (dm-5): resizing filesystem from 4294966784 to 4831837696 blocks [ 207.918754] EXT4-fs (dm-5): resizing filesystem from 4294967296 to 4831837696 blocks [ 207.918758] EXT4-fs (dm-5): Converting file system to meta_bg [ 207.918790] EXT4-fs (dm-5): resizing filesystem from 4294967296 to 4831837696 blocks [ 221.454050] EXT4-fs (dm-5): resized to 4658298880 blocks [ 227.634613] EXT4-fs (dm-5): resized filesystem to 4831837696 Signed-off-by: Jerry Lee Link: https://lore.kernel.org/r/PU1PR04MB22635E739BD21150DC182AC6A18C9@PU1PR04MB2263.apcprd04.prod.outlook.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 5d671a666c6955c55786b14d0588156697e899ff Author: José Expósito Date: Mon Aug 15 16:26:15 2022 +0200 HID: uclogic: Add missing suffix for digitalizers commit 0977fda0587cbc5403651ba169e264aa01e8a026 upstream. The Pen (0x02) application usage was changed to Digitalizer (0x01) in commit f7d8e387d9ae ("HID: uclogic: Switch to Digitizer usage for styluses"). However, a suffix was not selected for the new usage. Handle the digitalizer application usage in uclogic_input_configured() and add the required suffix. Signed-off-by: José Expósito Signed-off-by: Jiri Kosina Signed-off-by: Greg Kroah-Hartman commit 8b922cab735b92e183e85ea0fe53b1a3c8b815c6 Author: Nathan Chancellor Date: Fri Oct 14 13:42:11 2022 -0700 lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5 commit 0a6de78cff600cb991f2a1b7ed376935871796a0 upstream. When building with a RISC-V kernel with DWARF5 debug info using clang and the GNU assembler, several instances of the following error appear: /tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported Dumping the .s file reveals these .uleb128 directives come from .debug_loc and .debug_ranges: .Ldebug_loc0: .byte 4 # DW_LLE_offset_pair .uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset .uleb128 .Ltmp1-.Lfunc_begin0 # ending offset .byte 1 # Loc expr size .byte 90 # DW_OP_reg10 .byte 0 # DW_LLE_end_of_list .Ldebug_ranges0: .byte 4 # DW_RLE_offset_pair .uleb128 .Ltmp6-.Lfunc_begin0 # starting offset .uleb128 .Ltmp27-.Lfunc_begin0 # ending offset .byte 4 # DW_RLE_offset_pair .uleb128 .Ltmp28-.Lfunc_begin0 # starting offset .uleb128 .Ltmp30-.Lfunc_begin0 # ending offset .byte 0 # DW_RLE_end_of_list There is an outstanding binutils issue to support a non-constant operand to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to be any movement on it, due to concerns over how it would work with linker relaxation. To avoid these build errors, prevent DWARF5 from being selected when using clang and an assembler that does not have support for these symbol deltas, which can be easily checked in Kconfig with as-instr plus the small test program from the dwz test suite from the binutils issue. Link: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 Link: https://github.com/ClangBuiltLinux/linux/issues/1719 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit a2f91e15ceafa1dff3aa458fdc49900ddfc343fc Author: Masahiro Yamada Date: Wed Oct 5 01:29:04 2022 +0900 Kconfig.debug: add toolchain checks for DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT commit bb1435f3f575b5213eaf27434efa3971f51c01de upstream. CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT does not give explicit -gdwarf-* flag. The actual DWARF version is up to the toolchain. The combination of GCC and GAS works fine, and Clang with the integrated assembler is good too. The combination of Clang and GAS is tricky, but at least, the -g flag works for Clang <=13, which defaults to DWARF v4. Clang 14 switched its default to DWARF v5. Now, CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT has the same issue as addressed by commit 98cd6f521f10 ("Kconfig: allow explicit opt in to DWARF v5"). CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y for Clang >= 14 and GAS < 2.35 produces a ton of errors like follows: /tmp/main-c2741c.s: Assembler messages: /tmp/main-c2741c.s:109: Error: junk at end of line, first unrecognized character is `"' /tmp/main-c2741c.s:109: Error: file number less than one Add 'depends on' to check toolchains. Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 01d15d7f3bb13ca382503587fe68c7e7af139410 Author: Masahiro Yamada Date: Wed Oct 5 01:29:03 2022 +0900 Kconfig.debug: simplify the dependency of DEBUG_INFO_DWARF4/5 commit 4f001a21080ff2e2f0e1c3692f5e119aedbb3bc1 upstream. Commit c0a5c81ca9be ("Kconfig.debug: drop GCC 5+ version check for DWARF5") could have cleaned up the code a bit more. "CC_IS_CLANG &&" is unneeded. No functional change is intended. Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 6cfc3d5b06fe82ec7b7109f5ddfb22745475d165 Author: Martin Rodriguez Reboredo Date: Fri Sep 16 14:12:34 2022 -0300 kbuild: Add skip_encoding_btf_enum64 option to pahole New pahole (version 1.24) generates by default new BTF_KIND_ENUM64 BTF tag, which is not supported by stable kernel. As a result the kernel with CONFIG_DEBUG_INFO_BTF option will fail to compile with following error: BTFIDS vmlinux FAILED: load BTF from vmlinux: Invalid argument New pahole provides --skip_encoding_btf_enum64 option to skip BTF_KIND_ENUM64 generation and produce BTF supported by stable kernel. Adding this option to scripts/pahole-flags.sh. This change does not have equivalent commit in linus tree, because linus tree has support for BTF_KIND_ENUM64 tag, so it does not need to be disabled. Signed-off-by: Martin Rodriguez Reboredo Signed-off-by: Jiri Olsa Signed-off-by: Greg Kroah-Hartman commit d8861de1c35bd003470ec317e7b90cefe9546f27 Author: Nathan Chancellor Date: Fri Oct 14 08:21:03 2022 -0700 drm/amd/display: Fix build breakage with CONFIG_DEBUG_FS=n commit 2130b87b2273389cafe6765bf09ef564cda01407 upstream. After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr transition"), a build with CONFIG_DEBUG_FS=n is broken due to a misplaced brace, along the lines of: In file included from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39, from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:41: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: At top level: ./include/drm/drm_atomic.h:864:9: error: expected identifier or ‘(’ before ‘for’ 864 | for ((__i) = 0; \ | ^~~ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8317:9: note: in expansion of macro ‘for_each_new_crtc_in_state’ 8317 | for_each_new_crtc_in_state(state, crtc, new_crtc_state, j) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ Move the brace within the #ifdef so that the file can be built with or without CONFIG_DEBUG_FS. Fixes: 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr transition") Signed-off-by: Nathan Chancellor Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 43f49952df6ac7601cb99ba88ba472df8e7b1431 Author: Nicholas Piggin Date: Thu Oct 13 16:44:18 2022 +1000 powerpc/64s/interrupt: Fix lost interrupts when returning to soft-masked context commit a4cb3651a174366cc85a677da9e3681fbe97fdae upstream. It's possible for an interrupt returning to an irqs-disabled context to lose a pending soft-masked irq because it branches to part of the exit code for irqs-enabled contexts, which is meant to clear only the PACA_IRQS_HARD_DIS flag from PACAIRQHAPPENED by zeroing the byte. This just looks like a simple thinko from a recent commit (if there was no hard mask pending, there would be no reason to clear it anyway). This also adds comment to the code that actually does need to clear the flag. Fixes: e485f6c751e0a ("powerpc/64/interrupt: Fix return to masked context after hard-mask irq becomes pending") Reported-by: Sachin Sant Reported-by: Guenter Roeck Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221013064418.1311104-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit df0da3fc131132b6c32a15c4da4ffa3a5aea1af2 Author: Tetsuo Handa Date: Tue Oct 4 21:47:50 2022 -0400 net/ieee802154: don't warn zero-sized raw_sendmsg() [ Upstream commit b12e924a2f5b960373459c8f8a514f887adf5cac ] syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1], for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting __dev_queue_xmit() with skb->len == 0. Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request was able to return 0, don't call __dev_queue_xmit() if packet length is 0. ---------- #include #include int main(int argc, char *argv[]) { struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) }; struct iovec iov = { }; struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 }; sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0); return 0; } ---------- Note that this might be a sign that commit fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len") should be reverted, for skb->len == 0 was acceptable for at least PF_IEEE802154 socket. Link: https://syzkaller.appspot.com/bug?extid=5ea725c25d06fb9114c4 [1] Reported-by: syzbot Fixes: fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len") Signed-off-by: Tetsuo Handa Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20221005014750.3685555-2-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit 7b5a94b4dccd316d334785fb7d51c1d41df69e0b Author: Alexander Aring Date: Tue Oct 4 21:47:49 2022 -0400 Revert "net/ieee802154: reject zero-sized raw_sendmsg()" [ Upstream commit 2eb2756f6c9e9621e022d78321ce40a62c4520b5 ] This reverts commit 3a4d061c699bd3eedc80dc97a4b2a2e1af83c6f5. There is a v2 which does return zero if zero length is given. Signed-off-by: Alexander Aring Link: https://lore.kernel.org/r/20221005014750.3685555-1-aahringo@redhat.com Signed-off-by: Stefan Schmidt Signed-off-by: Sasha Levin commit a2852ff5df30ffc3cc36d02a251e6921dac06837 Author: Aric Cyr Date: Mon Sep 19 17:42:22 2022 -0400 Revert "drm/amd/display: correct hostvm flag" commit 96ab3cb3b0f862308a03046d01d66c7b4154846b upstream. This reverts commit 796d6a37ff5ffaf9f2dc0f3f4bf9f4a1034c00de. 4K144 resolution isn't available on DCN31. Reviewed-by: Sherry Wang Acked-by: Hamza Mahfooz Signed-off-by: Aric Cyr Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 72fedefeaaee9aa0c7cd874bd1ac104ca2d3be17 Author: Randy Dunlap Date: Tue Aug 23 19:42:16 2022 -0700 net: ethernet: ti: davinci_mdio: fix build for mdio bitbang uses commit 35bbe652c421037822aba29423f5f1f7d0d69f3f upstream. davinci_mdio.c uses mdio bitbang APIs, so it should select MDIO_BITBANG to prevent build errors. arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdio_remove': drivers/net/ethernet/ti/davinci_mdio.c:649: undefined reference to `free_mdio_bitbang' arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdio_probe': drivers/net/ethernet/ti/davinci_mdio.c:545: undefined reference to `alloc_mdio_bitbang' arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdiobb_read': drivers/net/ethernet/ti/davinci_mdio.c:236: undefined reference to `mdiobb_read' arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdiobb_write': drivers/net/ethernet/ti/davinci_mdio.c:253: undefined reference to `mdiobb_write' Fixes: d04807b80691 ("net: ethernet: ti: davinci_mdio: Add workaround for errata i2329") Signed-off-by: Randy Dunlap Cc: Grygorii Strashko Cc: Ravi Gunasekaran Cc: Eric Dumazet Cc: Paolo Abeni Cc: Naresh Kamboju Cc: Sudip Mukherjee (Codethink) Link: https://lore.kernel.org/r/20220824024216.4939-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7a5dc0f4bc45ea8633d1248e1fffa4ce92c155b1 Author: Yu Kuai Date: Sun Oct 9 18:10:38 2022 +0800 blk-wbt: fix that 'rwb->wc' is always set to 1 in wbt_init() commit 285febabac4a16655372d23ff43e89ff6f216691 upstream. commit 8c5035dfbb94 ("blk-wbt: call rq_qos_add() after wb_normal is initialized") moves wbt_set_write_cache() before rq_qos_add(), which is wrong because wbt_rq_qos() is still NULL. Fix the problem by removing wbt_set_write_cache() and setting 'rwb->wc' directly. Noted that this patch also remove the redundant setting of 'rab->wc'. Fixes: 8c5035dfbb94 ("blk-wbt: call rq_qos_add() after wb_normal is initialized") Reported-by: kernel test robot Link: https://lore.kernel.org/r/202210081045.77ddf59b-yujie.liu@intel.com Signed-off-by: Yu Kuai Reviewed-by: Ming Lei Link: https://lore.kernel.org/r/20221009101038.1692875-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9d4f4dc3cd38e412c29a7626489fe48b79ebbf6c Author: Takashi Iwai Date: Thu Sep 15 10:59:47 2022 +0200 ALSA: usb-audio: Fix last interface check for registration commit 39efc9c8a973ddff5918191525d1679d0fb368ea upstream. The recent fix in commit 6392dcd1d0c7 ("ALSA: usb-audio: Register card at the last interface") tried to delay the card registration until the last found interface is probed. It assumed that the probe callback gets called for those later interfaces, but it's not always true; as the driver loops over the descriptor and probes the matching ones, it's not separately called via multiple probe calls. This results in the missing card registration, i.e. no sound device. For addressing this problem, replace the check whether the last interface is processed with usb_interface_claimed() instead of the comparison with the probe interface number. Fixes: 6392dcd1d0c7 ("ALSA: usb-audio: Register card at the last interface") Link: https://lore.kernel.org/r/20220915085947.7922-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0ad680a71ef65b1ceead3d7908d9563f596415a5 Author: Alexander Aring Date: Wed Oct 5 22:02:37 2022 -0400 net: ieee802154: return -EINVAL for unknown addr type commit 30393181fdbc1608cc683b4ee99dcce05ffcc8c7 upstream. This patch adds handling to return -EINVAL for an unknown addr type. The current behaviour is to return 0 as successful but the size of an unknown addr type is not defined and should return an error like -EINVAL. Fixes: 94160108a70c ("net/ieee802154: fix uninit value bug in dgram_sendmsg") Signed-off-by: Alexander Aring Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dd691973f67b2800a97db723b1ff6f07fdcf7f5a Author: Liu Shixin Date: Fri Sep 23 12:21:13 2022 +0800 mm: hugetlb: fix UAF in hugetlb_handle_userfault commit 958f32ce832ba781ac20e11bb2d12a9352ea28fc upstream. The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race, hugetlb_fault hugetlb_no_page /*unlock vma_lock */ hugetlb_handle_userfault handle_userfault /* unlock mm->mmap_lock*/ vm_mmap_pgoff do_mmap mmap_region munmap_vma_range /* clean old vma */ /* lock vma_lock again <--- UAF */ /* unlock vma_lock */ Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue. [1] https://lore.kernel.org/linux-mm/000000000000d5e00a05e834962e@google.com/ [2] https://lore.kernel.org/linux-mm/20220921014457.1668-1-liuzixian4@huawei.com/ Link: https://lkml.kernel.org/r/20220923042113.137273-1-liushixin2@huawei.com Fixes: 1a1aad8a9b7b ("userfaultfd: hugetlbfs: add userfaultfd hugetlb hook") Signed-off-by: Liu Shixin Signed-off-by: Kefeng Wang Reported-by: syzbot+193f9cee8638750b23cf@syzkaller.appspotmail.com Reported-by: Liu Zixian Reviewed-by: Mike Kravetz Cc: David Hildenbrand Cc: John Hubbard Cc: Muchun Song Cc: Sidhartha Kumar Cc: [4.14+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit bd3183508842acd156d17485bb13649585c05164 Author: Adrian Hunter Date: Wed Oct 12 11:22:59 2022 +0300 perf intel-pt: Fix system_wide dummy event for hybrid commit 6cef7dab3e2e5cb23a13569c3880c0532326748c upstream. User space tasks can migrate between CPUs, so when tracing selected CPUs, system-wide sideband is still needed, however evlist->core.has_user_cpus is not set in the hybrid case, so check the target cpu_list instead. Fixes: 7d189cadbeebc778 ("perf intel-pt: Track sideband system-wide when needed") Signed-off-by: Adrian Hunter Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221012082259.22394-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 41e4f3b6254694628e21bc62da47e83578870200 Author: Adrian Hunter Date: Wed Oct 12 11:22:58 2022 +0300 perf intel-pt: Fix segfault in intel_pt_print_info() with uClibc commit 5a3d47071f0ced0431ef82a5fb6bd077ed9493db upstream. uClibc segfaulted because NULL was passed as the format to fprintf(). That happened because one of the format strings was missing and intel_pt_print_info() didn't check that before calling fprintf(). Add the missing format string, and check format is not NULL before calling fprintf(). Fixes: 11fa7cb86b56d361 ("perf tools: Pass Intel PT information for decoding MTC and CYC") Signed-off-by: Adrian Hunter Acked-by: Namhyung Kim Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221012082259.22394-2-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 18e98d56fdf84e0fbcdfd9bf5db4fba599b1b407 Author: Rob Herring Date: Tue Oct 4 14:12:35 2022 -0500 perf: Skip and warn on unknown format 'configN' attrs commit e552b7be12ed62357df84392efa525ecb01910fb upstream. If the kernel exposes a new perf_event_attr field in a format attr, perf will return an error stating the specified PMU can't be found. For example, a format attr with 'config3:0-63' causes an error as config3 is unknown to perf. This causes a compatibility issue between a newer kernel with older perf tool. Before this change with a kernel adding 'config3' I get: $ perf record -e arm_spe// -- true event syntax error: 'arm_spe//' \___ Cannot find PMU `arm_spe'. Missing kernel support? Run 'perf list' for a list of valid events Usage: perf record [] [] or: perf record [] -- [] -e, --event event selector. use 'perf list' to list available events After this change, I get: $ perf record -e arm_spe// -- true WARNING: 'arm_spe_0' format 'inv_event_filter' requires 'perf_event_attr::config3' which is not supported by this version of perf! [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.091 MB perf.data ] To support unknown configN formats, rework the YACC implementation to pass any config[0-9]+ format to perf_pmu__new_format() to handle with a warning. Reviewed-by: Namhyung Kim Signed-off-by: Rob Herring Tested-by: Leo Yan Cc: Alexander Shishkin Cc: Ingo Molnar Cc: James Clark Cc: Jiri Olsa Cc: Mark Rutland Cc: Peter Zijlstra Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220914-arm-perf-tool-spe1-2-v2-v4-1-83c098e6212e@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit d53d82a9c51514520e5900bed504516b4ea47a22 Author: Ivan T. Ivanov Date: Mon Sep 12 11:13:04 2022 +0300 clk: bcm2835: Round UART input clock up [ Upstream commit f690a4d7a8f66430662975511c86819dc9965bcc ] It was reported that RPi3[1] and RPi Zero 2W boards have issues with the Bluetooth. It turns out that when switching from initial to operation speed host and device no longer can talk each other because host uses incorrect UART baud rate. The UART driver used in this case is amba-pl011. Original fix, see below Github link[2], was inside pl011 module, but somehow it didn't look as the right place to fix. Beside that this original rounding function is not exactly perfect for all possible clock values. So I deiced to move the hack to the platform which actually need it. The UART clock is initialised to be as close to the requested frequency as possible without exceeding it. Now that there is a clock manager that returns the actual frequencies, an expected 48MHz clock is reported as 47999625. If the requested baud rate == requested clock/16, there is no headroom and the slight reduction in actual clock rate results in failure. If increasing a clock by less than 0.1% changes it from ..999.. to ..000.., round it up. [1] https://bugzilla.suse.com/show_bug.cgi?id=1188238 [2] https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7 Cc: Phil Elwell Signed-off-by: Ivan T. Ivanov Reviewed-by: Stefan Wahren Link: https://lore.kernel.org/r/20220912081306.24662-1-iivanov@suse.de Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4fc3d834cad949cf61895b2e7fbef92cbffa0100 Author: Maxime Ripard Date: Mon Sep 26 10:45:09 2022 +0200 clk: bcm2835: Make peripheral PLLC critical [ Upstream commit 6c5422851d8be8c7451e968fd2e6da41b6109e17 ] When testing for a series affecting the VEC, it was discovered that turning off and on the VEC clock is crashing the system. It turns out that, when disabling the VEC clock, it's the only child of the PLLC-per clock which will also get disabled. The source of the crash is PLLC-per being disabled. It's likely that some other device might not take a clock reference that it actually needs, but it's unclear which at this point. Let's make PLLC-per critical so that we don't have that crash. Reported-by: Noralf Trønnes Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220926084509.12233-1-maxime@cerno.tech Reviewed-by: Stefan Wahren Acked-by: Noralf Trønnes Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 72b67ce35bcc8e46f44bf27acbc85c29b4431af8 Author: Wayne Chang Date: Tue Sep 27 21:45:12 2022 +0800 usb: typec: ucsi: Don't warn on probe deferral [ Upstream commit fce703a991b7e8c7e1371de95b9abaa832ecf9c3 ] Deferred probe is an expected return value for fwnode_usb_role_switch_get(). Given that the driver deals with it properly, there's no need to output a warning that may potentially confuse users. -- V2 -> V3: remove the Fixes and Cc V1 -> V2: adjust the coding style for better reading format. drivers/usb/typec/ucsi/ucsi.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) Signed-off-by: Wayne Chang Acked-by: Heikki Krogerus Link: https://lore.kernel.org/r/20220927134512.2651067-1-waynec@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1d5ad0a874ddfcee9f932f54b1d34cbe8b9ddcfe Author: Eddie James Date: Fri May 13 14:44:24 2022 -0500 fsi: occ: Prevent use after free [ Upstream commit d3e1e24604031b0d83b6c2d38f54eeea265cfcc0 ] Use get_device and put_device in the open and close functions to make sure the device doesn't get freed while a file descriptor is open. Also, lock around the freeing of the device buffer and check the buffer before using it in the submit function. Signed-off-by: Eddie James Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20220513194424.53468-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit fbcf76240a308be8c0761f8dce28304ec27df709 Author: Eddie James Date: Tue Apr 26 10:49:56 2022 -0500 hwmon (occ): Retry for checksum failure [ Upstream commit dbed963ed62c4c2b8870a02c8b7dcb0c2af3ee0b ] Due to the OCC communication design with a shared SRAM area, checkum errors are expected due to corrupted buffer from OCC communications with other system components. Therefore, retry the command twice in the event of a checksum failure. Signed-off-by: Eddie James Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/20220426154956.27205-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 63a681bcc32a43528ce0f690569f7f48e59c3963 Author: Keith Busch Date: Tue Sep 27 08:56:52 2022 -0700 blk-mq: use quiesced elevator switch when reinitializing queues [ Upstream commit 8237c01f1696bc53c470493bf1fe092a107648a6 ] The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally. nvme nvme0: resetting controller nvme nvme0: 32/0/0 default/read/poll queues BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70 ... Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0 Signed-off-by: Keith Busch Reviewed-by: Ming Lei Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20220927155652.3260724-1-kbusch@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6163a5ae097bc78fa26c243fb384537e25610fd7 Author: Dongliang Mu Date: Thu Sep 22 21:48:44 2022 +0800 usb: idmouse: fix an uninit-value in idmouse_open [ Upstream commit bce2b0539933e485d22d6f6f076c0fcd6f185c4c ] In idmouse_create_image, if any ftip_command fails, it will go to the reset label. However, this leads to the data in bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check for valid image incurs an uninitialized dereference. Fix this by moving the check before reset label since this check only be valid if the data after bulk_in_buffer[HEADER] has concrete data. Note that this is found by KMSAN, so only kernel compilation is tested. Reported-by: syzbot+79832d33eb89fb3cd092@syzkaller.appspotmail.com Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/r/20220922134847.1101921-1-dzm91@hust.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fcf82e4553db911d10234ff2390cfd0e2aa854e4 Author: Varun Prakash Date: Wed Sep 21 00:06:49 2022 +0530 nvmet-tcp: add bounds check on Transfer Tag [ Upstream commit b6a545ffa2c192b1e6da4a7924edac5ba9f4ea2b ] ttag is used as an index to get cmd in nvmet_tcp_handle_h2c_data_pdu(), add a bounds check to avoid out-of-bounds access. Signed-off-by: Varun Prakash Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1ce3c83795b704cf71d0c805a37f535ea0abce29 Author: Keith Busch Date: Mon Sep 19 12:45:08 2022 -0700 nvme: copy firmware_rev on each init [ Upstream commit a8eb6c1ba48bddea82e8d74cbe6e119f006be97d ] The firmware revision can change on after a reset so copy the most recent info each time instead of just the first time, otherwise the sysfs firmware_rev entry may contain stale data. Reported-by: Jeff Lien Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Reviewed-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 24e2357041c812d0748ed5c114c9100c84689351 Author: Keith Busch Date: Mon Sep 19 12:36:46 2022 -0700 nvme: handle effects after freeing the request [ Upstream commit bc8fb906b0ff9339b4286698cb7cd9cd5b8c53eb ] If a reset occurs after the scan work attempts to issue a command, the reset may quisce the admin queue, which blocks the scan work's command from dispatching. The scan work will not be able to complete while the queue is quiesced. Meanwhile, the reset work will cancel all outstanding admin tags and wait until all requests have transitioned to idle, which includes the passthrough request. But the passthrough request won't be set to idle until after the scan_work flushes, so we're deadlocked. Fix this by handling the end effects after the request has been freed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216354 Reported-by: Jonathan Derrick Signed-off-by: Keith Busch Reviewed-by: Sagi Grimberg Reviewed-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 18c37236b0b0369153ee8a976ed1baf8dc8bd7f8 Author: Jan Kara Date: Wed Sep 14 17:29:33 2022 +0200 ext2: Use kvmalloc() for group descriptor array [ Upstream commit e7c7fbb9a8574ebd89cc05db49d806c7476863ad ] Array of group descriptor block buffers can get rather large. In theory in can reach 1MB for perfectly valid filesystem and even more for maliciously crafted ones. Use kvmalloc() to allocate the array to avoid straining memory allocator with large order allocations unnecessarily. Reported-by: syzbot+0f2f7e65a3007d39539f@syzkaller.appspotmail.com Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 2ad8143884b9a14aeb7f951d3e1ba56f0be6c6d2 Author: Arun Easi Date: Wed Sep 7 16:33:08 2022 -0700 scsi: tracing: Fix compile error in trace_array calls when TRACING is disabled [ Upstream commit 1a77dd1c2bb5d4a58c16d198cf593720787c02e4 ] Fix this compilation error seen when CONFIG_TRACING is not enabled: drivers/scsi/qla2xxx/qla_os.c: In function 'qla_trace_init': drivers/scsi/qla2xxx/qla_os.c:2854:25: error: implicit declaration of function 'trace_array_get_by_name'; did you mean 'trace_array_set_clr_event'? [-Werror=implicit-function-declaration] 2854 | qla_trc_array = trace_array_get_by_name("qla2xxx"); | ^~~~~~~~~~~~~~~~~~~~~~~ | trace_array_set_clr_event drivers/scsi/qla2xxx/qla_os.c: In function 'qla_trace_uninit': drivers/scsi/qla2xxx/qla_os.c:2869:9: error: implicit declaration of function 'trace_array_put' [-Werror=implicit-function-declaration] 2869 | trace_array_put(qla_trc_array); | ^~~~~~~~~~~~~~~ Link: https://lore.kernel.org/r/20220907233308.4153-2-aeasi@marvell.com Reported-by: kernel test robot Reviewed-by: Steven Rostedt (Google) Signed-off-by: Arun Easi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a5be64ff6d21f7805a91e6d81f53fc19cd9f0fae Author: Xiaoke Wang Date: Fri Sep 9 19:27:21 2022 +0800 staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv() [ Upstream commit 708056fba733a73d926772ea4ce9a42d240345da ] In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocated in failure, then `pcmdpriv->cmd_allocated_buf` will be not properly released. Besides, considering there are only two error paths and the first one can directly return, so we do not need implicitly jump to the `exit` tag to execute the error handler. So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the error path to release the resource and simplified the return logic of rtw_init_cmd_priv(). As there is no proper device to test with, no runtime testing was performed. Signed-off-by: Xiaoke Wang Link: https://lore.kernel.org/r/tencent_2B7931B79BA38E22205C5A09EFDF11E48805@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6b2052b365f8035ab7f09ac24b5b499002b298cb Author: Xiaoke Wang Date: Fri Sep 9 18:39:35 2022 +0800 staging: rtl8723bs: fix potential memory leak in rtw_init_drv_sw() [ Upstream commit 5a5aa9cce621e2c0e25a1e5d72d6be1749167cc0 ] In rtw_init_drv_sw(), there are various init functions are called to populate the padapter structure and some checks for their return value. However, except for the first one error path, the other five error paths do not properly release the previous allocated resources, which leads to various memory leaks. This patch fixes them and keeps the success and error separate. Note that these changes keep the form of `rtw_init_drv_sw()` in "drivers/staging/r8188eu/os_dep/os_intfs.c". As there is no proper device to test with, no runtime testing was performed. Signed-off-by: Xiaoke Wang Link: https://lore.kernel.org/r/tencent_C3B899D2FC3F1BC827F3552E0B0734056006@qq.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65bb21134ffc21dd0275cae21fef180ef7d6125e Author: sunghwan jung Date: Tue Sep 13 20:49:13 2022 +0900 Revert "usb: storage: Add quirk for Samsung Fit flash" [ Upstream commit ad5dbfc123e6ffbbde194e2a4603323e09f741ee ] This reverts commit 86d92f5465958752481269348d474414dccb1552, which fix the timeout issue for "Samsung Fit Flash". But the commit affects not only "Samsung Fit Flash" but also other usb storages that use the same controller and causes severe performance regression. # hdparm -t /dev/sda (without the quirk) Timing buffered disk reads: 622 MB in 3.01 seconds = 206.66 MB/sec # hdparm -t /dev/sda (with the quirk) Timing buffered disk reads: 220 MB in 3.00 seconds = 73.32 MB/sec The commit author mentioned that "Issue was reproduced after device has bad block", so this quirk should be applied when we have the timeout issue with a device that has bad blocks. We revert the commit so that we apply this quirk by adding kernel paramters using a bootloader or other ways when we really need it, without the performance regression with devices that don't have the issue. Signed-off-by: sunghwan jung Link: https://lore.kernel.org/r/20220913114913.3073-1-onenowy@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a5ec6978e6578f4b249718a7fe42f0c71c9e92f7 Author: Piyush Mehta Date: Tue Sep 20 10:52:35 2022 +0530 usb: dwc3: core: Enable GUCTL1 bit 10 for fixing termination error after resume bug [ Upstream commit 63d7f9810a38102cdb8cad214fac98682081e1a7 ] When configured in HOST mode, after issuing U3/L2 exit controller fails to send proper CRC checksum in CRC5 field. Because of this behavior Transaction Error is generated, resulting in reset and re-enumeration of usb device attached. Enabling chicken bit 10 of GUCTL1 will correct this problem. When this bit is set to '1', the UTMI/ULPI opmode will be changed to "normal" along with HS terminations, term, and xcvr signals after EOR. This option is to support certain legacy UTMI/ULPI PHYs. Added "snps,resume-hs-terminations" quirk to resolved the above issue. Signed-off-by: Piyush Mehta Link: https://lore.kernel.org/r/20220920052235.194272-3-piyush.mehta@amd.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dd4d06dc5c12e6f7447de0595a028cdaa772aeba Author: Alexander Stein Date: Thu Sep 15 08:28:54 2022 +0200 arm64: dts: imx8mp: Add snps,gfladj-refclk-lpm-sel quirk to USB nodes [ Upstream commit 5c3d5ecf48ab06c709c012bf1e8f0c91e1fcd7ad ] With this set the SOF/ITP counter is based on ref_clk when 2.0 ports are suspended. snps,dis-u2-freeclk-exists-quirk can be removed as snps,gfladj-refclk-lpm-sel also clears the free running clock configuration bit. Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20220915062855.751881-4-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6289a58d4f198e4bf068209397c5fde0fed0611b Author: Alexander Stein Date: Thu Sep 15 08:28:53 2022 +0200 usb: dwc3: core: add gfladj_refclk_lpm_sel quirk [ Upstream commit a6fc2f1b092787e9d7dbe472d720cede81680315 ] This selects the SOF/ITP counter be running on ref_clk. As documented U2_FREECLK_EXISTS has to be set to 0 as well. Reviewed-by: Li Jun Signed-off-by: Alexander Stein Link: https://lore.kernel.org/r/20220915062855.751881-3-alexander.stein@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a9ccd2ab1becf5dcb6d57e9fcd981f5eaa606c96 Author: Robin Guo Date: Tue Sep 6 10:21:19 2022 +0800 usb: musb: Fix musb_gadget.c rxstate overflow bug [ Upstream commit eea4c860c3b366369eff0489d94ee4f0571d467d ] The usb function device call musb_gadget_queue() adds the passed request to musb_ep::req_list,If the (request->length > musb_ep->packet_sz) and (is_buffer_mapped(req) return false),the rxstate() will copy all data in fifo to request->buf which may cause request->buf out of bounds. Fix it by add the length check : fifocnt = min_t(unsigned, request->length - request->actual, fifocnt); Signed-off-by: Robin Guo Link: https://lore.kernel.org/r/20220906102119.1b071d07a8391ff115e6d1ef@inspur.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a40ad475236022f3432880e3091c380e46e71a71 Author: Jianglei Nie Date: Wed Sep 21 15:34:45 2022 +0300 usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info() [ Upstream commit 7e271f42a5cc3768cd2622b929ba66859ae21f97 ] xhci_alloc_stream_info() allocates stream context array for stream_info ->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs, stream_info->stream_ctx_array is not released, which will lead to a memory leak. We can fix it by releasing the stream_info->stream_ctx_array with xhci_free_stream_ctx() on the error path to avoid the potential memory leak. Signed-off-by: Jianglei Nie Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220921123450.671459-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2cab058f2b147e0b7c01546ba00445e5701861f5 Author: Logan Gunthorpe Date: Wed Sep 21 10:28:37 2022 -0600 md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d [ Upstream commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74 ] A complicated deadlock exists when using the journal and an elevated group_thrtead_cnt. It was found with loop devices, but its not clear whether it can be seen with real disks. The deadlock can occur simply by writing data with an fio script. When the deadlock occurs, multiple threads will hang in different ways: 1) The group threads will hang in the blk-wbt code with bios waiting to be submitted to the block layer: io_schedule+0x70/0xb0 rq_qos_wait+0x153/0x210 wbt_wait+0x115/0x1b0 io_schedule+0x70/0xb0 rq_qos_wait+0x153/0x210 wbt_wait+0x115/0x1b0 __rq_qos_throttle+0x38/0x60 blk_mq_submit_bio+0x589/0xcd0 wbt_wait+0x115/0x1b0 __rq_qos_throttle+0x38/0x60 blk_mq_submit_bio+0x589/0xcd0 __submit_bio+0xe6/0x100 submit_bio_noacct_nocheck+0x42e/0x470 submit_bio_noacct+0x4c2/0xbb0 ops_run_io+0x46b/0x1a30 handle_stripe+0xcd3/0x36b0 handle_active_stripes.constprop.0+0x6f6/0xa60 raid5_do_work+0x177/0x330 Or: io_schedule+0x70/0xb0 rq_qos_wait+0x153/0x210 wbt_wait+0x115/0x1b0 __rq_qos_throttle+0x38/0x60 blk_mq_submit_bio+0x589/0xcd0 __submit_bio+0xe6/0x100 submit_bio_noacct_nocheck+0x42e/0x470 submit_bio_noacct+0x4c2/0xbb0 flush_deferred_bios+0x136/0x170 raid5_do_work+0x262/0x330 2) The r5l_reclaim thread will hang in the same way, submitting a bio to the block layer: io_schedule+0x70/0xb0 rq_qos_wait+0x153/0x210 wbt_wait+0x115/0x1b0 __rq_qos_throttle+0x38/0x60 blk_mq_submit_bio+0x589/0xcd0 __submit_bio+0xe6/0x100 submit_bio_noacct_nocheck+0x42e/0x470 submit_bio_noacct+0x4c2/0xbb0 submit_bio+0x3f/0xf0 md_super_write+0x12f/0x1b0 md_update_sb.part.0+0x7c6/0xff0 md_update_sb+0x30/0x60 r5l_do_reclaim+0x4f9/0x5e0 r5l_reclaim_thread+0x69/0x30b However, before hanging, the MD_SB_CHANGE_PENDING flag will be set for sb_flags in r5l_write_super_and_discard_space(). This flag will never be cleared because the submit_bio() call never returns. 3) Due to the MD_SB_CHANGE_PENDING flag being set, handle_stripe() will do no processing on any pending stripes and re-set STRIPE_HANDLE. This will cause the raid5d thread to enter an infinite loop, constantly trying to handle the same stripes stuck in the queue. The raid5d thread has a blk_plug that holds a number of bios that are also stuck waiting seeing the thread is in a loop that never schedules. These bios have been accounted for by blk-wbt thus preventing the other threads above from continuing when they try to submit bios. --Deadlock. To fix this, add the same wait_event() that is used in raid5_do_work() to raid5d() such that if MD_SB_CHANGE_PENDING is set, the thread will schedule and wait until the flag is cleared. The schedule action will flush the plug which will allow the r5l_reclaim thread to continue, thus preventing the deadlock. However, md_check_recovery() calls can also clear MD_SB_CHANGE_PENDING from the same thread and can thus deadlock if the thread is put to sleep. So avoid waiting if md_check_recovery() is being called in the loop. It's not clear when the deadlock was introduced, but the similar wait_event() call in raid5_do_work() was added in 2017 by this commit: 16d997b78b15 ("md/raid5: simplfy delaying of writes while metadata is updated.") Link: https://lore.kernel.org/r/7f3b87b6-b52a-f737-51d7-a4eec5c44112@deltatee.com Signed-off-by: Logan Gunthorpe Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 6a0781b8a46d299b19aa249c5525bdbbbcaabe98 Author: Dylan Yudaken Date: Tue Aug 16 06:59:59 2022 -0700 eventfd: guard wake_up in eventfd fs calls as well [ Upstream commit 9f0deaa12d832f488500a5afe9b912e9b3cfc432 ] Guard wakeups that the user can trigger, and that may end up triggering a call back into eventfd_signal. This is in addition to the current approach that only guards in eventfd_signal. Rename in_eventfd_signal -> in_eventfd at the same time to reflect this. Without this there would be a deadlock in the following code using libaio: int main() { struct io_context *ctx = NULL; struct iocb iocb; struct iocb *iocbs[] = { &iocb }; int evfd; uint64_t val = 1; evfd = eventfd(0, EFD_CLOEXEC); assert(!io_setup(2, &ctx)); io_prep_poll(&iocb, evfd, POLLIN); io_set_eventfd(&iocb, evfd); assert(1 == io_submit(ctx, 1, iocbs)); write(evfd, &val, 8); } Signed-off-by: Dylan Yudaken Reviewed-by: Jens Axboe Link: https://lore.kernel.org/r/20220816135959.1490641-1-dylany@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f3ae6aac9e0e417c932d15ec92d6d1fe1bb86e28 Author: Johnothan King Date: Wed Sep 21 10:55:57 2022 +0000 HID: nintendo: check analog user calibration for plausibility [ Upstream commit 50503e360eeb968a3d00234c9cc4057d774c3e9a ] Arne Wendt writes: Cheap clone controllers may (falsely) report as having a user calibration for the analog sticks in place, but return wrong/impossible values for the actual calibration data. In the present case at mine, the controller reports having a user calibration in place and successfully executes the read commands. The reported user calibration however is min = center = max = 0. This pull request addresses problems of this kind by checking the provided user calibration-data for plausibility (min < center < max) and falling back to the default values if implausible. I'll note that I was experiencing a crash because of this bug when using the GuliKit KingKong 2 controller. The crash manifests as a divide by zero error in the kernel logs: kernel: divide error: 0000 [#1] PREEMPT SMP NOPTI Link: https://github.com/nicman23/dkms-hid-nintendo/pull/25 Link: https://github.com/DanielOgorchock/linux/issues/36 Co-authored-by: Arne Wendt Signed-off-by: Johnothan King Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/gvpL2G6VwXGJPvxX5KRiu9pVjvTivgayug_jdKDY6zfuAaAqncP9BkKLosjwUXNlgVVTMfJSKfwPF1K79cKAkwGComyC21vCV3q9B3EXNkE=@protonmail.com Signed-off-by: Sasha Levin commit 78b0ef14896f843c45372f9bbdb6f6070f977eaf Author: Jianglei Nie Date: Mon Sep 5 15:48:01 2022 +0800 HSI: ssi_protocol: fix potential resource leak in ssip_pn_open() [ Upstream commit b28dbcb379e6a7f80262c2732a57681b1ee548ca ] ssip_pn_open() claims the HSI client's port with hsi_claim_port(). When hsi_register_port_event() gets some error and returns a negetive value, the HSI client's port should be released with hsi_release_port(). Fix it by calling hsi_release_port() when hsi_register_port_event() fails. Signed-off-by: Jianglei Nie Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 2d38886ae0365463cdba3db669170eef1e3d55c0 Author: Hyunwoo Kim Date: Sun Sep 4 12:31:15 2022 -0700 HID: roccat: Fix use-after-free in roccat_read() [ Upstream commit cacdb14b1c8d3804a3a7d31773bc7569837b71a4 ] roccat_report_event() is responsible for registering roccat-related reports in struct roccat_device. int roccat_report_event(int minor, u8 const *data) { struct roccat_device *device; struct roccat_reader *reader; struct roccat_report *report; uint8_t *new_value; device = devices[minor]; new_value = kmemdup(data, device->report_size, GFP_ATOMIC); if (!new_value) return -ENOMEM; report = &device->cbuf[device->cbuf_end]; /* passing NULL is safe */ kfree(report->value); ... The registered report is stored in the struct roccat_device member "struct roccat_report cbuf[ROCCAT_CBUF_SIZE];". If more reports are received than the "ROCCAT_CBUF_SIZE" value, kfree() the saved report from cbuf[0] and allocates a new reprot. Since there is no lock when this kfree() is performed, kfree() can be performed even while reading the saved report. static ssize_t roccat_read(struct file *file, char __user *buffer, size_t count, loff_t *ppos) { struct roccat_reader *reader = file->private_data; struct roccat_device *device = reader->device; struct roccat_report *report; ssize_t retval = 0, len; DECLARE_WAITQUEUE(wait, current); mutex_lock(&device->cbuf_lock); ... report = &device->cbuf[reader->cbuf_start]; /* * If report is larger than requested amount of data, rest of report * is lost! */ len = device->report_size > count ? count : device->report_size; if (copy_to_user(buffer, report->value, len)) { retval = -EFAULT; goto exit_unlock; } ... The roccat_read() function receives the device->cbuf report and delivers it to the user through copy_to_user(). If the N+ROCCAT_CBUF_SIZE th report is received while copying of the Nth report->value is in progress, the pointer that copy_to_user() is working on is kfree()ed and UAF read may occur. (race condition) Since the device node of this driver does not set separate permissions, this is not a security vulnerability, but because it is used for requesting screen display of profile or dpi settings, a user using the roccat device can apply udev to this device node or There is a possibility to use it by giving. Signed-off-by: Hyunwoo Kim Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 24ba97974ef3161ec2d8141f1f3d18e6c5b952bc Author: Pierre-Louis Bossart Date: Tue Sep 20 01:57:11 2022 +0800 soundwire: intel: fix error handling on dai registration issues [ Upstream commit c6867cda906aadbce5e71efde9c78a26108b2bad ] The call to intel_register_dai() may fail because of memory allocation issues or problems reported by the ASoC core. In all cases, when a error is thrown the component is not registered, it's invalid to unregister it. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Rander Wang Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20220919175721.354679-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d4188d2e2842496354e2a6daa9691a869d6d96c9 Author: Richard Fitzgerald Date: Fri Sep 16 11:35:05 2022 +0100 soundwire: cadence: Don't overwrite msg->buf during write commands [ Upstream commit ba05b39d265bdd16913f7684600d9d41e2796745 ] The buf passed in struct sdw_msg must only be written for a READ, in that case the RDATA part of the response is the data value of the register. For a write command there is no RDATA, and buf should be assumed to be const and unmodifable. The original caller should not expect its data buffer to be corrupted by an sdw_nwrite(). Signed-off-by: Richard Fitzgerald Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220916103505.1562210-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 864934cbe72c709d9e1f64b530ca135dbfb24c30 Author: Coly Li Date: Tue Sep 20 00:16:47 2022 +0800 bcache: fix set_at_max_writeback_rate() for multiple attached devices [ Upstream commit d2d05b88035d2d51a5bb6c5afec88a0880c73df4 ] Inside set_at_max_writeback_rate() the calculation in following if() check is wrong, if (atomic_inc_return(&c->idle_counter) < atomic_read(&c->attached_dev_nr) * 6) Because each attached backing device has its own writeback thread running and increasing c->idle_counter, the counter increates much faster than expected. The correct calculation should be, (counter / dev_nr) < dev_nr * 6 which equals to, counter < dev_nr * dev_nr * 6 This patch fixes the above mistake with correct calculation, and helper routine idle_counter_exceeded() is added to make code be more clear. Reported-by: Mingzhe Zou Signed-off-by: Coly Li Acked-by: Mingzhe Zou Link: https://lore.kernel.org/r/20220919161647.81238-6-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e225ca58f63a1132e432b5dc42e6e080584cdba6 Author: Serge Semin Date: Fri Sep 9 22:36:06 2022 +0300 ata: libahci_platform: Sanity check the DT child nodes number [ Upstream commit 3c132ea6508b34956e5ed88d04936983ec230601 ] Having greater than AHCI_MAX_PORTS (32) ports detected isn't that critical from the further AHCI-platform initialization point of view since exceeding the ports upper limit will cause allocating more resources than will be used afterwards. But detecting too many child DT-nodes doesn't seem right since it's very unlikely to have it on an ordinary platform. In accordance with the AHCI specification there can't be more than 32 ports implemented at least due to having the CAP.NP field of 5 bits wide and the PI register of dword size. Thus if such situation is found the DTB must have been corrupted and the data read from it shouldn't be reliable. Let's consider that as an erroneous situation and halt further resources allocation. Note it's logically more correct to have the nports set only after the initialization value is checked for being sane. So while at it let's make sure nports is assigned with a correct value. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit cc6f0855bf8d9b729df28ff443ced7350c380dbd Author: Yu Kuai Date: Mon Aug 29 10:22:38 2022 +0800 blk-throttle: prevent overflow while calculating wait time [ Upstream commit 8d6bbaada2e0a65f9012ac4c2506460160e7237a ] There is a problem found by code review in tg_with_in_bps_limit() that 'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem by calling mul_u64_u64_div_u64() instead. Signed-off-by: Yu Kuai Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20220829022240.3348319-3-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fb5f569bcda8f87bd47d8030bfae343d757fa3ea Author: Nam Cao Date: Fri Sep 9 16:13:39 2022 +0200 staging: vt6655: fix potential memory leak [ Upstream commit c8ff91535880d41b49699b3829fb6151942de29e ] In function device_init_td0_ring, memory is allocated for member td_info of priv->apTD0Rings[i], with i increasing from 0. In case of allocation failure, the memory is freed in reversed order, with i decreasing to 0. However, the case i=0 is left out and thus memory is leaked. Modify the memory freeing loop to include the case i=0. Tested-by: Philipp Hortmann Signed-off-by: Nam Cao Link: https://lore.kernel.org/r/20220909141338.19343-1-namcaov@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 038e4aa71281d0cbc8aeb56ba05ff7fc5653a106 Author: Wei Yongjun Date: Sat Aug 27 07:32:23 2022 +0000 power: supply: adp5061: fix out-of-bounds read in adp5061_get_chg_type() [ Upstream commit 9d47e01b9d807808224347935562f7043a358054 ] ADP5061_CHG_STATUS_1_CHG_STATUS is masked with 0x07, which means a length of 8, but adp5061_chg_type array size is 4, may end up reading 4 elements beyond the end of the adp5061_chg_type[] array. Signed-off-by: Wei Yongjun Acked-by: Michael Hennerich Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit b737f60538abfeb343ac7ead216068f9fa3b087a Author: Michael Grzeschik Date: Wed Sep 7 23:58:18 2022 +0200 usb: gadget: uvc: increase worker prio to WQ_HIGHPRI [ Upstream commit 9b91a65230784a9ef644b8bdbb82a79ba4ae9456 ] This patch is changing the simple workqueue in the gadget driver to be allocated as async_wq with a higher priority. The pump worker, that is filling the usb requests, will have a higher priority and will not be scheduled away so often while the video stream is handled. This will lead to fewer streaming underruns. Signed-off-by: Michael Grzeschik Link: https://lore.kernel.org/r/20220907215818.2670097-1-m.grzeschik@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 78e83cfc64b55e706d1b050afe54c4fd0fe7d136 Author: Yicong Yang Date: Tue Aug 16 19:44:10 2022 +0800 iommu/arm-smmu-v3: Make default domain type of HiSilicon PTT device to identity [ Upstream commit 24b6c7798a0122012ca848ea0d25e973334266b0 ] The DMA operations of HiSilicon PTT device can only work properly with identical mappings. So add a quirk for the device to force the domain as passthrough. Acked-by: Will Deacon Signed-off-by: Yicong Yang Reviewed-by: John Garry Link: https://lore.kernel.org/r/20220816114414.4092-2-yangyicong@huawei.com Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 62006a72b05e0d38727eef5188700f2488be5e89 Author: Shigeru Yoshida Date: Thu Sep 8 01:35:02 2022 +0900 nbd: Fix hung when signal interrupts nbd_start_device_ioctl() [ Upstream commit 1de7c3cf48fc41cd95adb12bd1ea9033a917798a ] syzbot reported hung task [1]. The following program is a simplified version of the reproducer: int main(void) { int sv[2], fd; if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) return 1; if ((fd = open("/dev/nbd0", 0)) < 0) return 1; if (ioctl(fd, NBD_SET_SIZE_BLOCKS, 0x81) < 0) return 1; if (ioctl(fd, NBD_SET_SOCK, sv[0]) < 0) return 1; if (ioctl(fd, NBD_DO_IT) < 0) return 1; return 0; } When signal interrupt nbd_start_device_ioctl() waiting the condition atomic_read(&config->recv_threads) == 0, the task can hung because it waits the completion of the inflight IOs. This patch fixes the issue by clearing queue, not just shutdown, when signal interrupt nbd_start_device_ioctl(). Link: https://syzkaller.appspot.com/bug?id=7d89a3ffacd2b83fdd39549bc4d8e0a89ef21239 [1] Reported-by: syzbot+38e6c55d4969a14c1534@syzkaller.appspotmail.com Signed-off-by: Shigeru Yoshida Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20220907163502.577561-1-syoshida@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 53b6d7e499983bebfd8b1816e2d16ea78a0098a3 Author: Letu Ren Date: Mon Aug 29 19:01:15 2022 +0800 scsi: 3w-9xxx: Avoid disabling device if failing to enable it [ Upstream commit 7eff437b5ee1309b34667844361c6bbb5c97df05 ] The original code will "goto out_disable_device" and call pci_disable_device() if pci_enable_device() fails. The kernel will generate a warning message like "3w-9xxx 0000:00:05.0: disabling already-disabled device". We shouldn't disable a device that failed to be enabled. A simple return is fine. Link: https://lore.kernel.org/r/20220829110115.38789-1-fantasquex@gmail.com Reported-by: Zheyu Ma Signed-off-by: Letu Ren Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e0b16bfbd3a4a8d09614046335f4482313e7c0c4 Author: Vaishnav Achath Date: Tue Aug 2 11:18:35 2022 +0530 dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow [ Upstream commit 7c94dcfa8fcff2dba53915f1dabfee49a3df8b88 ] UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics. These registers are 32-bit hardware counters and the driver uses these counters to monitor the operational progress status for a channel, when transferring more than 4GB of data it was observed that these counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely. This commit adds changes to decrease the byte count for every complete transaction so that these registers never overflow and the proper byte count statistics is maintained for ongoing transaction by the RT counters. Earlier uc->bcnt used to maintain a count of the completed bytes at driver side, since the RT counters maintain the statistics of current transaction now, the maintenance of uc->bcnt is not necessary. Signed-off-by: Vaishnav Achath Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20220802054835.19482-1-vaishnav.a@ti.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 04e7cd8c85636a329d1a6e5a269a7c8b6f71c41c Author: James Smart Date: Thu Aug 18 18:17:31 2022 -0700 scsi: lpfc: Fix null ndlp ptr dereference in abnormal exit path for GFT_ID [ Upstream commit 59b7e210a522b836a01516c71ee85d1d92c1f075 ] An error case exit from lpfc_cmpl_ct_cmd_gft_id() results in a call to lpfc_nlp_put() with a null pointer to a nodelist structure. Changed lpfc_cmpl_ct_cmd_gft_id() to initialize nodelist pointer upon entry. Link: https://lore.kernel.org/r/20220819011736.14141-3-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1f7181ce5891f0362c57bfb07f0a81e1f3cde22c Author: Justin Chen Date: Wed Aug 10 15:27:35 2022 -0700 usb: host: xhci-plat: suspend/resume clks for brcm [ Upstream commit c69400b09e471a3f1167adead55a808f0da6534a ] The xhci_plat_brcm xhci block can enter suspend with clock disabled to save power and re-enable them on resume. Make use of the XHCI_SUSPEND_RESUME_CLKS quirk to do so. Reviewed-by: Florian Fainelli Signed-off-by: Justin Chen Link: https://lore.kernel.org/r/1660170455-15781-3-git-send-email-justinpopo6@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e2df82b8e742340d1965f8083b410165741d72aa Author: Justin Chen Date: Wed Aug 10 15:27:34 2022 -0700 usb: host: xhci-plat: suspend and resume clocks [ Upstream commit 8bd954c56197caf5e3a804d989094bc3fe6329aa ] Introduce XHCI_SUSPEND_RESUME_CLKS quirk as a means to suspend and resume clocks if the hardware is capable of doing so. We assume that clocks will be needed if the device may wake. Reviewed-by: Florian Fainelli Signed-off-by: Justin Chen Link: https://lore.kernel.org/r/1660170455-15781-2-git-send-email-justinpopo6@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 72dbdd00fb2a0668146a1ec117e5c48c277956bd Author: Daisuke Matsuda Date: Mon Aug 29 16:12:18 2022 +0900 RDMA/rxe: Delete error messages triggered by incoming Read requests [ Upstream commit 2c02249fcbfc066bd33e2a7375c7006d4cb367f6 ] An incoming Read request causes multiple Read responses. If a user MR to copy data from is unavailable or responder cannot send a reply, then the error messages can be printed for each response attempt, resulting in message overflow. Link: https://lore.kernel.org/r/20220829071218.1639065-1-matsuda-daisuke@fujitsu.com Signed-off-by: Daisuke Matsuda Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f2cf53ed2ce296888bf451346006d1b289a62687 Author: Quanyang Wang Date: Fri Aug 26 22:20:30 2022 +0800 clk: zynqmp: pll: rectify rate rounding in zynqmp_pll_round_rate [ Upstream commit 30eaf02149ecc3c5815e45d27187bf09e925071d ] The function zynqmp_pll_round_rate is used to find a most appropriate PLL frequency which the hardware can generate according to the desired frequency. For example, if the desired frequency is 297MHz, considering the limited range from PS_PLL_VCO_MIN (1.5GHz) to PS_PLL_VCO_MAX (3.0GHz) of PLL, zynqmp_pll_round_rate should return 1.872GHz (297MHz * 5). There are two problems with the current code of zynqmp_pll_round_rate: 1) When the rate is below PS_PLL_VCO_MIN, it can't find a correct rate when the parameter "rate" is an integer multiple of *prate, in other words, if "f" is zero, zynqmp_pll_round_rate won't return a valid frequency which is from PS_PLL_VCO_MIN to PS_PLL_VCO_MAX. For example, *prate is 33MHz and the rate is 660MHz, zynqmp_pll_round_rate will not boost up rate and just return 660MHz, and this will cause clk_calc_new_rates failure since zynqmp_pll_round_rate returns an invalid rate out of its boundaries. 2) Even if the rate is higher than PS_PLL_VCO_MIN, there is still a risk that zynqmp_pll_round_rate returns an invalid rate because the function DIV_ROUND_CLOSEST makes some loss in the fractional part. If the parent clock *prate is 33333333Hz and we want to set the PLL rate to 1.5GHz, this function will return 1499999985Hz by using the formula below: value = *prate * DIV_ROUND_CLOSEST(rate, *prate)). This value is also invalid since it's slightly smaller than PS_PLL_VCO_MIN. because DIV_ROUND_CLOSEST makes some loss in the fractional part. Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20220826142030.213805-1-quanyang.wang@windriver.com Reviewed-by: Shubhrajyoti Datta Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit fb98ebac0169690fe180120676a1ff79573e48c3 Author: Hangyu Hua Date: Tue Aug 16 10:58:19 2022 +0200 media: platform: fix some double free in meson-ge2d and mtk-jpeg and s5p-mfc [ Upstream commit c65c3f3a2cbf21ed429d9b9c725bdb5dc6abf4cf ] video_unregister_device will release device internally. There is no need to call video_device_release after video_unregister_device. Signed-off-by: Hangyu Hua Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 704838040f3bdb4aa07ff4f26505a666a3defcfe Author: Zheyu Ma Date: Thu Jul 28 04:23:38 2022 +0200 media: cx88: Fix a null-ptr-deref bug in buffer_prepare() [ Upstream commit 2b064d91440b33fba5b452f2d1b31f13ae911d71 ] When the driver calls cx88_risc_buffer() to prepare the buffer, the function call may fail, resulting in a empty buffer and null-ptr-deref later in buffer_queue(). The following log can reveal it: [ 41.822762] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI [ 41.824488] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 41.828027] RIP: 0010:buffer_queue+0xc2/0x500 [ 41.836311] Call Trace: [ 41.836945] __enqueue_in_driver+0x141/0x360 [ 41.837262] vb2_start_streaming+0x62/0x4a0 [ 41.838216] vb2_core_streamon+0x1da/0x2c0 [ 41.838516] __vb2_init_fileio+0x981/0xbc0 [ 41.839141] __vb2_perform_fileio+0xbf9/0x1120 [ 41.840072] vb2_fop_read+0x20e/0x400 [ 41.840346] v4l2_read+0x215/0x290 [ 41.840603] vfs_read+0x162/0x4c0 Fix this by checking the return value of cx88_risc_buffer() [hverkuil: fix coding style issues] Signed-off-by: Zheyu Ma Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d66fea97671fcb516bd6d34bcc033f650ac7ee91 Author: Ian Nam Date: Tue May 10 12:31:54 2022 +0530 clk: zynqmp: Fix stack-out-of-bounds in strncpy` [ Upstream commit dd80fb2dbf1cd8751efbe4e53e54056f56a9b115 ] "BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68" Linux-ATF interface is using 16 bytes of SMC payload. In case clock name is longer than 15 bytes, string terminated NULL character will not be received by Linux. Add explicit NULL character at last byte to fix issues when clock name is longer. This fixes below bug reported by KASAN: ================================================================== BUG: KASAN: stack-out-of-bounds in strncpy+0x30/0x68 Read of size 1 at addr ffff0008c89a7410 by task swapper/0/1 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.0-00396-g81ef9e7-dirty #3 Hardware name: Xilinx Versal vck190 Eval board revA (QSPI) (DT) Call trace: dump_backtrace+0x0/0x1e8 show_stack+0x14/0x20 dump_stack+0xd4/0x108 print_address_description.isra.0+0xbc/0x37c __kasan_report+0x144/0x198 kasan_report+0xc/0x18 __asan_load1+0x5c/0x68 strncpy+0x30/0x68 zynqmp_clock_probe+0x238/0x7b8 platform_drv_probe+0x6c/0xc8 really_probe+0x14c/0x418 driver_probe_device+0x74/0x130 __device_attach_driver+0xc4/0xe8 bus_for_each_drv+0xec/0x150 __device_attach+0x160/0x1d8 device_initial_probe+0x10/0x18 bus_probe_device+0xe0/0xf0 device_add+0x528/0x950 of_device_add+0x5c/0x80 of_platform_device_create_pdata+0x120/0x168 of_platform_bus_create+0x244/0x4e0 of_platform_populate+0x50/0xe8 zynqmp_firmware_probe+0x370/0x3a8 platform_drv_probe+0x6c/0xc8 really_probe+0x14c/0x418 driver_probe_device+0x74/0x130 device_driver_attach+0x94/0xa0 __driver_attach+0x70/0x108 bus_for_each_dev+0xe4/0x158 driver_attach+0x30/0x40 bus_add_driver+0x21c/0x2b8 driver_register+0xbc/0x1d0 __platform_driver_register+0x7c/0x88 zynqmp_firmware_driver_init+0x1c/0x24 do_one_initcall+0xa4/0x234 kernel_init_freeable+0x1b0/0x24c kernel_init+0x10/0x110 ret_from_fork+0x10/0x18 The buggy address belongs to the page: page:ffff0008f9be1c88 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 raw: 0008d00000000000 ffff0008f9be1c90 ffff0008f9be1c90 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff page dumped because: kasan: bad access detected addr ffff0008c89a7410 is located in stack of task swapper/0/1 at offset 112 in frame: zynqmp_clock_probe+0x0/0x7b8 this frame has 3 objects: [32, 44) 'response' [64, 80) 'ret_payload' [96, 112) 'name' Memory state around the buggy address: ffff0008c89a7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff0008c89a7380: 00 00 00 00 f1 f1 f1 f1 00 04 f2 f2 00 00 f2 f2 >ffff0008c89a7400: 00 00 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 ^ ffff0008c89a7480: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff0008c89a7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Signed-off-by: Ian Nam Signed-off-by: Shubhrajyoti Datta Link: https://lore.kernel.org/r/20220510070154.29528-3-shubhrajyoti.datta@xilinx.com Acked-by: Michal Simek Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 5f11e22d1d5a9107357438efef1559eb4fa2dde0 Author: Alex Sverdlin Date: Mon Sep 5 16:26:59 2022 +0100 ARM: 9242/1: kasan: Only map modules if CONFIG_KASAN_VMALLOC=n [ Upstream commit 823f606ab6b4759a1faf0388abcf4fb0776710d2 ] In case CONFIG_KASAN_VMALLOC=y kasan_populate_vmalloc() allocates the shadow pages dynamically. But even worse is that kasan_release_vmalloc() releases them, which is not compatible with create_mapping() of MODULES_VADDR..MODULES_END range: BUG: Bad page state in process kworker/9:1 pfn:2068b page:e5e06160 refcount:0 mapcount:0 mapping:00000000 index:0x0 flags: 0x1000(reserved) raw: 00001000 e5e06164 e5e06164 00000000 00000000 00000000 ffffffff 00000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set bad because of flags: 0x1000(reserved) Modules linked in: ip_tables CPU: 9 PID: 154 Comm: kworker/9:1 Not tainted 5.4.188-... #1 Hardware name: LSI Axxia AXM55XX Workqueue: events do_free_init unwind_backtrace show_stack dump_stack bad_page free_pcp_prepare free_unref_page kasan_depopulate_vmalloc_pte __apply_to_page_range apply_to_existing_page_range kasan_release_vmalloc __purge_vmap_area_lazy _vm_unmap_aliases.part.0 __vunmap do_free_init process_one_work worker_thread kthread Reviewed-by: Linus Walleij Signed-off-by: Alexander Sverdlin Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 0d10683a2cd3a8243f51dffe1a9457adbd54781a Author: Li Huafei Date: Fri Aug 26 09:08:46 2022 +0100 ARM: 9234/1: stacktrace: Avoid duplicate saving of exception PC value [ Upstream commit 752ec621ef5c30777958cc5eb5f1cf394f7733f4 ] Because an exception stack frame is not created in the exception entry, save_trace() does special handling for the exception PC, but this is only needed when CONFIG_FRAME_POINTER_UNWIND=y. When CONFIG_ARM_UNWIND=y, unwind annotations have been added to the exception entry and save_trace() will repeatedly save the exception PC: [0x7f000090] hrtimer_hander+0x8/0x10 [hrtimer] [0x8019ec50] __hrtimer_run_queues+0x18c/0x394 [0x8019f760] hrtimer_run_queues+0xbc/0xd0 [0x8019def0] update_process_times+0x34/0x80 [0x801ad2a4] tick_periodic+0x48/0xd0 [0x801ad3dc] tick_handle_periodic+0x1c/0x7c [0x8010f2e0] twd_handler+0x30/0x40 [0x80177620] handle_percpu_devid_irq+0xa0/0x23c [0x801718d0] generic_handle_domain_irq+0x24/0x34 [0x80502d28] gic_handle_irq+0x74/0x88 [0x8085817c] generic_handle_arch_irq+0x58/0x78 [0x80100ba8] __irq_svc+0x88/0xc8 [0x80108114] arch_cpu_idle+0x38/0x3c [0x80108114] arch_cpu_idle+0x38/0x3c <==== duplicate saved exception PC [0x80861bf8] default_idle_call+0x38/0x130 [0x8015d5cc] do_idle+0x150/0x214 [0x8015d978] cpu_startup_entry+0x18/0x1c [0x808589c0] rest_init+0xd8/0xdc [0x80c00a44] arch_post_acpi_subsys_init+0x0/0x8 We can move the special handling of the exception PC in save_trace() to the unwind_frame() of the frame pointer unwinder. Signed-off-by: Li Huafei Reviewed-by: Linus Waleij Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 91bcc794c72e8d5832054fdc8313d91a434a9f95 Author: Li Huafei Date: Fri Aug 26 09:06:22 2022 +0100 ARM: 9233/1: stacktrace: Skip frame pointer boundary check for call_with_stack() [ Upstream commit 5854e4d8530e6ed4c2532a71a6b0474e199d44dd ] When using the frame pointer unwinder, it was found that the stack trace output of stack_trace_save() is incomplete if the stack contains call_with_stack(): [0x7f00002c] dump_stack_task+0x2c/0x90 [hrtimer] [0x7f0000a0] hrtimer_hander+0x10/0x18 [hrtimer] [0x801a67f0] __hrtimer_run_queues+0x1b0/0x3b4 [0x801a7350] hrtimer_run_queues+0xc4/0xd8 [0x801a597c] update_process_times+0x3c/0x88 [0x801b5a98] tick_periodic+0x50/0xd8 [0x801b5bf4] tick_handle_periodic+0x24/0x84 [0x8010ffc4] twd_handler+0x38/0x48 [0x8017d220] handle_percpu_devid_irq+0xa8/0x244 [0x80176e9c] generic_handle_domain_irq+0x2c/0x3c [0x8052e3a8] gic_handle_irq+0x7c/0x90 [0x808ab15c] generic_handle_arch_irq+0x60/0x80 [0x8051191c] call_with_stack+0x1c/0x20 For the frame pointer unwinder, unwind_frame() checks stackframe::fp by stackframe::sp. Since call_with_stack() switches the SP from one stack to another, stackframe::fp and stackframe: :sp will point to different stacks, so we can no longer check stackframe::fp by stackframe::sp. Skip checking stackframe::fp at this point to avoid this problem. Signed-off-by: Li Huafei Reviewed-by: Linus Waleij Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 819a61301275dcc573e3f520be3dc2c8531bee2d Author: Josef Bacik Date: Mon Aug 8 16:10:26 2022 -0400 btrfs: call __btrfs_remove_free_space_cache_locked on cache load failure [ Upstream commit 8a1ae2781dee9fc21ca82db682d37bea4bd074ad ] Now that lockdep is staying enabled through our entire CI runs I started seeing the following stack in generic/475 ------------[ cut here ]------------ WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0 CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:btrfs_discard_update_discardable+0x98/0xb0 RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001 RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831e RBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010 R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80 FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0 Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock); We have a temporary free space ctl for loading the free space cache in order to avoid having allocations happening while we're loading the cache. When we hit an error we free it all up, however this also calls btrfs_discard_update_discardable, which requires block_group->free_space_ctl->tree_lock to be held. However this is our temporary ctl so this lock isn't held. Fix this by calling __btrfs_remove_free_space_cache_locked instead so that we only clean up the entries and do not mess with the discardable stats. Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 42817b55ea979d4767bab8353d4157bc629f94a1 Author: Maciej S. Szmigiero Date: Tue Aug 23 17:28:20 2022 +0200 btrfs: don't print information about space cache or tree every remount [ Upstream commit dbecac26630014d336a8e5ea67096ff18210fb9c ] btrfs currently prints information about space cache or free space tree being in use on every remount, regardless whether such remount actually enabled or disabled one of these features. This is actually unnecessary since providing remount options changing the state of these features will explicitly print the appropriate notice. Let's instead print such unconditional information just on an initial mount to avoid filling the kernel log when, for example, laptop-mode-tools remount the fs on some events. Signed-off-by: Maciej S. Szmigiero Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a5658aac9fbb62b5a97105b0dcc3e441a7baa8c3 Author: Qu Wenruo Date: Tue Aug 2 14:53:03 2022 +0800 btrfs: scrub: try to fix super block errors [ Upstream commit f9eab5f0bba76742af654f33d517bf62a0db8f12 ] [BUG] The following script shows that, although scrub can detect super block errors, it never tries to fix it: mkfs.btrfs -f -d raid1 -m raid1 $dev1 $dev2 xfs_io -c "pwrite 67108864 4k" $dev2 mount $dev1 $mnt btrfs scrub start -B $dev2 btrfs scrub start -Br $dev2 umount $mnt The first scrub reports the super error correctly: scrub done for f3289218-abd3-41ac-a630-202f766c0859 Scrub started: Tue Aug 2 14:44:11 2022 Status: finished Duration: 0:00:00 Total to scrub: 1.26GiB Rate: 0.00B/s Error summary: super=1 Corrected: 0 Uncorrectable: 0 Unverified: 0 But the second read-only scrub still reports the same super error: Scrub started: Tue Aug 2 14:44:11 2022 Status: finished Duration: 0:00:00 Total to scrub: 1.26GiB Rate: 0.00B/s Error summary: super=1 Corrected: 0 Uncorrectable: 0 Unverified: 0 [CAUSE] The comments already shows that super block can be easily fixed by committing a transaction: /* * If we find an error in a super block, we just report it. * They will get written with the next transaction commit * anyway */ But the truth is, such assumption is not always true, and since scrub should try to repair every error it found (except for read-only scrub), we should really actively commit a transaction to fix this. [FIX] Just commit a transaction if we found any super block errors, after everything else is done. We cannot do this just after scrub_supers(), as btrfs_commit_transaction() will try to pause and wait for the running scrub, thus we can not call it with scrub_lock hold. Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 1d520f11f5f4dcbd782b2ad8f0ed26ccb238a881 Author: Qu Wenruo Date: Tue Aug 2 14:53:02 2022 +0800 btrfs: scrub: properly report super block errors in system log [ Upstream commit e69bf81c9a339f1b2c041b112a6fbb9f60fc9340 ] [PROBLEM] Unlike data/metadata corruption, if scrub detected some error in the super block, the only error message is from the updated device status: BTRFS info (device dm-1): scrub: started on devid 2 BTRFS error (device dm-1): bdev /dev/mapper/test-scratch2 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 BTRFS info (device dm-1): scrub: finished on devid 2 with status: 0 This is not helpful at all. [CAUSE] Unlike data/metadata error reporting, there is no visible report in kernel dmesg to report supper block errors. In fact, return value of scrub_checksum_super() is intentionally skipped, thus scrub_handle_errored_block() will never be called for super blocks. [FIX] Make super block errors to output an error message, now the full dmesg would looks like this: BTRFS info (device dm-1): scrub: started on devid 2 BTRFS warning (device dm-1): super block error on device /dev/mapper/test-scratch2, physical 67108864 BTRFS error (device dm-1): bdev /dev/mapper/test-scratch2 errs: wr 0, rd 0, flush 0, corrupt 1, gen 0 BTRFS info (device dm-1): scrub: finished on devid 2 with status: 0 BTRFS info (device dm-1): scrub: started on devid 2 This fix involves: - Move the super_errors reporting to scrub_handle_errored_block() This allows the device status message to show after the super block error message. But now we no longer distinguish super block corruption and generation mismatch, now all counted as corruption. - Properly check the return value from scrub_checksum_super() - Add extra super block error reporting for scrub_print_warning(). Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8e0798d8fc25479b265cd85c5b91749c47e30d7d Author: Qu Wenruo Date: Mon Aug 1 09:35:57 2022 +0800 btrfs: dump extra info if one free space cache has more bitmaps than it should [ Upstream commit 62cd9d4474282a1eb84f945955c56cbfc42e1ffe ] There is an internal report on hitting the following ASSERT() in recalculate_thresholds(): ASSERT(ctl->total_bitmaps <= max_bitmaps); Above @max_bitmaps is calculated using the following variables: - bytes_per_bg 8 * 4096 * 4096 (128M) for x86_64/x86. - block_group->length The length of the block group. @max_bitmaps is the rounded up value of block_group->length / 128M. Normally one free space cache should not have more bitmaps than above value, but when it happens the ASSERT() can be triggered if CONFIG_BTRFS_ASSERT is also enabled. But the ASSERT() itself won't provide enough info to know which is going wrong. Is the bg too small thus it only allows one bitmap? Or is there something else wrong? So although I haven't found extra reports or crash dump to do further investigation, add the extra info to make it more helpful to debug. Reviewed-by: Anand Jain Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit dd0368cc7dd7a601328f7b96a7ba89cfcaf731cd Author: Sebastian Krzyszkowiak Date: Fri Sep 2 10:42:13 2022 +0200 arm64: dts: imx8mq-librem5: Add bq25895 as max17055's power supply [ Upstream commit 6effe295e1a87408033c29dbcea9d5a5c8b937d5 ] This allows the userspace to notice that there's not enough current provided to charge the battery, and also fixes issues with 0% SOC values being considered invalid. Signed-off-by: Sebastian Krzyszkowiak Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit aa7dbed46a133057a28e6ae6a8059b58da4e4c0a Author: Frieder Schrempf Date: Mon Aug 22 10:03:50 2022 +0200 arm64: dts: imx8mm-kontron: Use the VSELECT signal to switch SD card IO voltage [ Upstream commit eef2c0217e02b6c7ed5b10b82ea944127145e113 ] It turns out that it is not necessary to declare the VSELECT signal as GPIO and let the PMIC driver set it to a fixed high level. This switches the voltage between 3.3V and 1.8V by setting the PMIC register for LDO5 accordingly. Instead we can do it like other boards already do and simply mux the VSELECT signal of the USDHC interface to the pin. This makes sure that the correct voltage is selected by setting the PMIC's SD_VSEL input to high or low accordingly. Reported-by: Heiko Thiery Signed-off-by: Frieder Schrempf Reviewed-by: Heiko Thiery Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit f7205229eed29bfd5c12639b5afa6ccd3e6c4537 Author: Mark Brown Date: Mon Aug 29 17:06:56 2022 +0100 kselftest/arm64: Fix validatation termination record after EXTRA_CONTEXT [ Upstream commit 5c152c2f66f9368394b89ac90dc7483476ef7b88 ] When arm64 signal context data overflows the base struct sigcontext it gets placed in an extra buffer pointed to by a record of type EXTRA_CONTEXT in the base struct sigcontext which is required to be the last record in the base struct sigframe. The current validation code attempts to check this by using GET_RESV_NEXT_HEAD() to step forward from the current record to the next but that is a macro which assumes it is being provided with a struct _aarch64_ctx and uses the size there to skip forward to the next record. Instead validate_extra_context() passes it a struct extra_context which has a separate size field. This compiles but results in us trying to validate a termination record in completely the wrong place, at best failing validation and at worst just segfaulting. Fix this by passing the struct _aarch64_ctx we meant to into the macro. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20220829160703.874492-4-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 010d3fd16a075a2450d7f167fdb061c141077a9e Author: Marcel Ziswiler Date: Fri Aug 26 21:22:49 2022 +0200 ARM: dts: imx6sx-udoo-neo: don't use multiple blank lines [ Upstream commit fd2dd7077c7498765e7326c1b7f34bde85f1a975 ] This fixes the following warning: arch/arm/boot/dts/imx6sx-udoo-neo.dtsi:309: check: Please don't use multiple blank lines While at it, use tabs indent for some pinctrl entries. Signed-off-by: Marcel Ziswiler Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a78bbaa944552b57789dfa51b56c63904f59ccf6 Author: Marcel Ziswiler Date: Fri Aug 26 21:22:48 2022 +0200 ARM: dts: imx6sl: use tabs for code indent [ Upstream commit 218db824a7519856d0eaaeb5c41ca504ed550210 ] This fixes the following error: arch/arm/boot/dts/imx6sl.dtsi:714: error: code indent should use tabs where possible Signed-off-by: Marcel Ziswiler Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit e68c078e2f4b25b296da085a72b672ca98490bd9 Author: Alexander Stein Date: Fri Aug 26 07:53:36 2022 +0200 ARM: dts: imx6sx: add missing properties for sram [ Upstream commit 415432c008b2bce8138841356ba444631cabaa50 ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 91e4ed75545b5366bca8da4ef6d43999e13b600a Author: Alexander Stein Date: Fri Aug 26 07:53:35 2022 +0200 ARM: dts: imx6sll: add missing properties for sram [ Upstream commit 7492a83ed9b7a151e2dd11d64b06da7a7f0fa7f9 ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 295a1403c79c7c69dd08884cfc8c257a4b113c67 Author: Alexander Stein Date: Fri Aug 26 07:53:34 2022 +0200 ARM: dts: imx6sl: add missing properties for sram [ Upstream commit 60c9213a1d9941a8b33db570796c3f9be8984974 ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 37b648d675c9ee8be67eac3ad32466aa200a617e Author: Alexander Stein Date: Fri Aug 26 07:53:33 2022 +0200 ARM: dts: imx6qp: add missing properties for sram [ Upstream commit 088fe5237435ee2f7ed4450519b2ef58b94c832f ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@940000: '#address-cells' is a required property sram@940000: '#size-cells' is a required property sram@940000: 'ranges' is a required property Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a6cbafacd5a4f36025aba4f4235403316d2b2cfd Author: Alexander Stein Date: Fri Aug 26 07:53:32 2022 +0200 ARM: dts: imx6dl: add missing properties for sram [ Upstream commit f5848b95633d598bacf0500e0108dc5961af88c0 ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 008b630672576c796852cdbc9840e0583789f35e Author: Alexander Stein Date: Fri Aug 26 07:53:31 2022 +0200 ARM: dts: imx6q: add missing properties for sram [ Upstream commit b11d083c5dcec7c42fe982c854706d404ddd3a5f ] All 3 properties are required by sram.yaml. Fixes the dtbs_check warning: sram@900000: '#address-cells' is a required property sram@900000: '#size-cells' is a required property sram@900000: 'ranges' is a required property Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 8dc0c1860e382aa9238216b9cad093cd10795d01 Author: Haibo Chen Date: Mon Jul 25 18:16:22 2022 +0800 ARM: dts: imx7d-sdb: config the max pressure for tsc2046 [ Upstream commit e7c4ebe2f9cd68588eb24ba4ed122e696e2d5272 ] Use the general touchscreen method to config the max pressure for touch tsc2046(data sheet suggest 8 bit pressure), otherwise, for ABS_PRESSURE, when config the same max and min value, weston will meet the following issue, [17:19:39.183] event1 - ADS7846 Touchscreen: is tagged by udev as: Touchscreen [17:19:39.183] event1 - ADS7846 Touchscreen: kernel bug: device has min == max on ABS_PRESSURE [17:19:39.183] event1 - ADS7846 Touchscreen: was rejected [17:19:39.183] event1 - not using input device '/dev/input/event1' This will then cause the APP weston-touch-calibrator can't list touch devices. root@imx6ul7d:~# weston-touch-calibrator could not load cursor 'dnd-move' could not load cursor 'dnd-copy' could not load cursor 'dnd-none' No devices listed. And accroding to binding Doc, "ti,x-max", "ti,y-max", "ti,pressure-max" belong to the deprecated properties, so remove them. Also for "ti,x-min", "ti,y-min", "ti,x-plate-ohms", the value set in dts equal to the default value in driver, so are redundant, also remove here. Signed-off-by: Haibo Chen Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 9fb0373188af6b2a65fdb1a56aa3580805aaf14f Author: Alexander Stein Date: Wed Jul 20 08:41:58 2022 +0200 ARM: dts: imx6: delete interrupts property if interrupts-extended is set [ Upstream commit c9d38ff7080b2c4fa6786b82210fa13115895aae ] In most cases this is related to fsl,err006687-workaround-present, which requires a GPIO interrupt next a GIC interrupt. This fixes the dtbs_check warning: imx6dl-mba6a.dtb: ethernet@2188000: More than one condition true in oneOf schema: {'$filename': 'Documentation/devicetree/bindings/net/fsl,fec.yaml', [...] Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 5861c094874dc8cdb271f4b40c567afb9267bd24 Author: Felix Kuehling Date: Wed Sep 21 17:45:59 2022 -0400 drm/amdkfd: Fix UBSAN shift-out-of-bounds warning [ Upstream commit b292cafe2dd02d96a07147e4b160927e8399d5cc ] This was fixed in initialize_cpsch before, but not in initialize_nocpsch. Factor sdma bitmap initialization into a helper function to apply the correct implementation in both cases without duplicating it. v2: Added a range check Reported-by: Ellis Michael Signed-off-by: Felix Kuehling Reviewed-by: Graham Sider Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7e8d44956459a8acbffd242d946a7fd02cc6b92b Author: Wenjing Liu Date: Thu Sep 15 15:23:38 2022 -0400 drm/amd/display: polling vid stream status in hpo dp blank [ Upstream commit e32df0c7ecead95d70ca89f39b1b2b02a59ff691 ] [why] vid stream control is double bufferred, if we don't wait for video stream enable set to 0, we may get temporary image corruption showing on the stream when setting PIXEL_TO_SYMBOL_FIFO_ENABLE to 0. Reviewed-by: Ariel Bernstein Acked-by: Jasdeep Dhillon Signed-off-by: Wenjing Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 68a6337c14abfed9c955deb89c7ae556b623c064 Author: Aric Cyr Date: Fri Sep 9 18:07:59 2022 -0400 drm/amd/display: Remove interface for periodic interrupt 1 [ Upstream commit 97d8d6f075bd8f988589be02b91f6fa644d0b0b8 ] [why] Only a single VLINE interrupt is available so interface should not expose the second one which is used by DMU firmware. [how] Remove references to periodic_interrupt1 and VLINE1 from DC interfaces. Reviewed-by: Jaehyun Chung Acked-by: Jasdeep Dhillon Signed-off-by: Aric Cyr Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fc211b16a5583fb10d2611b603472eb0c252ce42 Author: Khaled Almahallawy Date: Thu Sep 15 22:49:00 2022 -0700 drm/dp: Don't rewrite link config when setting phy test pattern [ Upstream commit 7b4d8db657192066bc6f1f6635d348413dac1e18 ] The sequence for Source DP PHY CTS automation is [2][1]: 1- Emulate successful Link Training(LT) 2- Short HPD and change link rates and number of lanes by LT. (This is same flow for Link Layer CTS) 3- Short HPD and change PHY test pattern and swing/pre-emphasis levels (This step should not trigger LT) The problem is with DP PHY compliance setup as follow: [DPTX + on board LTTPR]------Main Link--->[Scope] ^ | | | | | ----------Aux Ch------>[Aux Emulator] At step 3, before writing TRAINING_LANEx_SET/LINK_QUAL_PATTERN_SET to declare the pattern/swing requested by scope, we write link config in LINK_BW_SET/LANE_COUNT_SET on a port that has LTTPR. As LTTPR snoops aux transaction, LINK_BW_SET/LANE_COUNT_SET writes indicate a LT will start [Check DP 2.0 E11 -Sec 3.6.8.2 & 3.6.8.6.3], and LTTPR will reset the link and stop sending DP signals to DPTX/Scope causing the measurements to fail. Note that step 3 will not trigger LT and DP link will never recovered by the Aux Emulator/Scope. The reset of link can be tested with a monitor connected to LTTPR port simply by writing to LINK_BW_SET or LANE_COUNT_SET as follow igt/tools/dpcd_reg write --offset=0x100 --value 0x14 --device=2 OR printf '\x14' | sudo dd of=/dev/drm_dp_aux2 bs=1 count=1 conv=notrunc seek=$((0x100)) This single aux write causes the screen to blank, sending short HPD to DPTX, setting LINK_STATUS_UPDATE = 1 in DPCD 0x204, and triggering LT. As stated in [1]: "Before any TX electrical testing can be performed, the link between a DPTX and DPRX (in this case, a piece of test equipment), including all LTTPRs within the path, shall be trained as defined in this Standard." In addition, changing Phy pattern/Swing/Pre-emphasis (Step 3) uses the same link rate and lane count applied on step 2, so no need to redo LT. The fix is to not rewrite link config in step 3, and just writes TRAINING_LANEx_SET and LINK_QUAL_PATTERN_SET [1]: DP 2.0 E11 - 3.6.11.1 LTTPR DPTX_PHY Electrical Compliance [2]: Configuring UnigrafDPTC Controller - Automation Test Sequence https://www.keysight.com/us/en/assets/9922-01244/help-files/ D9040DPPC-DisplayPort-Test-Software-Online-Help-latest.chm Cc: Imre Deak Cc: Jani Nikula Cc: Or Cochvi Signed-off-by: Khaled Almahallawy Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20220916054900.415804-1-khaled.almahallawy@intel.com Signed-off-by: Sasha Levin commit de2b6ebe0cb7746b5b6b35d79e150d934392b958 Author: Adrián Larumbe Date: Tue Sep 20 23:28:42 2022 +0100 drm/meson: remove drm bridges at aggregate driver unbind time [ Upstream commit 09847723c12fc2753749cec3939a02ee92dac468 ] drm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init were not manually removed at module unload time, which caused dangling references to freed memory to remain linked in the global bridge_list. When loading the driver modules back in, the same functions would again call drm_bridge_add, and when traversing the global bridge_list, would end up peeking into freed memory. Once again KASAN revealed the problem: [ +0.000095] ============================================================= [ +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120 [ +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483 [ +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000006] dump_backtrace+0x1ec/0x280 [ +0.000012] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000008] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] __list_add_valid+0x9c/0x120 [ +0.000009] drm_bridge_add+0x6c/0x104 [drm] [ +0.000165] dw_hdmi_probe+0x1900/0x2360 [dw_hdmi] [ +0.000022] meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi] [ +0.000014] component_bind+0x174/0x520 [ +0.000012] component_bind_all+0x1a8/0x38c [ +0.000010] meson_drv_bind_master+0x5e8/0xb74 [meson_drm] [ +0.000032] meson_drv_bind+0x20/0x2c [meson_drm] [ +0.000027] try_to_bring_up_aggregate_device+0x19c/0x390 [ +0.000010] component_master_add_with_match+0x1c8/0x284 [ +0.000009] meson_drv_probe+0x274/0x280 [meson_drm] [ +0.000026] platform_probe+0xd0/0x220 [ +0.000009] really_probe+0x3ac/0xa80 [ +0.000009] __driver_probe_device+0x1f8/0x400 [ +0.000009] driver_probe_device+0x68/0x1b0 [ +0.000009] __driver_attach+0x20c/0x480 [ +0.000008] bus_for_each_dev+0x114/0x1b0 [ +0.000009] driver_attach+0x48/0x64 [ +0.000008] bus_add_driver+0x390/0x564 [ +0.000009] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000008] meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm] [ +0.000027] do_one_initcall+0xc4/0x2b0 [ +0.000011] do_init_module+0x154/0x570 [ +0.000011] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000009] __arm64_sys_init_module+0x78/0xb0 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000016] Allocated by task 879: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc+0x278/0x4a0 [ +0.000011] mpi_resize+0x13c/0x1d0 [ +0.000011] mpi_powm+0xd24/0x1570 [ +0.000009] rsa_enc+0x1a4/0x30c [ +0.000009] pkcs1pad_verify+0x3f0/0x580 [ +0.000009] public_key_verify_signature+0x7a8/0xba4 [ +0.000010] public_key_verify_signature_2+0x40/0x60 [ +0.000008] verify_signature+0xb4/0x114 [ +0.000008] pkcs7_validate_trust_one.constprop.0+0x3b8/0x574 [ +0.000009] pkcs7_validate_trust+0xb8/0x15c [ +0.000008] verify_pkcs7_message_sig+0xec/0x1b0 [ +0.000012] verify_pkcs7_signature+0x78/0xac [ +0.000007] mod_verify_sig+0x110/0x190 [ +0.000009] module_sig_check+0x114/0x1e0 [ +0.000009] load_module+0xa0/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] Freed by task 2422: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000009] kasan_set_track+0x2c/0x40 [ +0.000007] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000010] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] take_down_aggregate_device+0xcc/0x160 [ +0.000010] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000013] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000009] platform_driver_unregister+0x20/0x2c [ +0.000007] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000009] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] The buggy address belongs to the object at ffff00003da29000 which belongs to the cache kmalloc-1k of size 1024 [ +0.000008] The buggy address is located 496 bytes inside of 1024-byte region [ffff00003da29000, ffff00003da29400) [ +0.000015] The buggy address belongs to the physical page: [ +0.000009] page:fffffc0000f68a00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x3da28 [ +0.000012] head:fffffc0000f68a00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.000009] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000019] raw: 0ffff00000010200 fffffc0000eb5c08 fffffc0000d96608 ffff000000002a80 [ +0.000008] raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000 [ +0.000008] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000009] ffff00003da29080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff00003da29100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff00003da29180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000008] ffff00003da29200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000006] ffff00003da29280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ================================================================== Fix by keeping track of which encoders were initialised in the meson_drm structure and manually removing their bridges at aggregate driver's unbind time. Signed-off-by: Adrián Larumbe Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20220920222842.1053234-1-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin commit f11aa996fc01888f870be0e79ba71526888c0d8a Author: Adrián Larumbe Date: Mon Sep 19 02:09:39 2022 +0100 drm/meson: explicitly remove aggregate driver at module unload time [ Upstream commit 8616f2a0589a80e08434212324250eb22f6a66ce ] Because component_master_del wasn't being called when unloading the meson_drm module, the aggregate device would linger forever in the global aggregate_devices list. That means when unloading and reloading the meson_dw_hdmi module, component_add would call into try_to_bring_up_aggregate_device and find the unbound meson_drm aggregate device. This would in turn dereference some of the aggregate_device's struct entries which point to memory automatically freed by the devres API when unbinding the aggregate device from meson_drv_unbind, and trigger an use-after-free bug: [ +0.000014] ============================================================= [ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500 [ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536 [ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000005] dump_backtrace+0x1ec/0x280 [ +0.000011] show_stack+0x24/0x80 [ +0.000007] dump_stack_lvl+0x98/0xd4 [ +0.000010] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000007] __asan_report_load8_noabort+0x3c/0x50 [ +0.000009] find_components+0x468/0x500 [ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390 [ +0.000009] __component_add+0x1dc/0x49c [ +0.000009] component_add+0x20/0x30 [ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi] [ +0.000013] platform_probe+0xd0/0x220 [ +0.000008] really_probe+0x3ac/0xa80 [ +0.000008] __driver_probe_device+0x1f8/0x400 [ +0.000008] driver_probe_device+0x68/0x1b0 [ +0.000008] __driver_attach+0x20c/0x480 [ +0.000009] bus_for_each_dev+0x114/0x1b0 [ +0.000007] driver_attach+0x48/0x64 [ +0.000009] bus_add_driver+0x390/0x564 [ +0.000007] driver_register+0x1a8/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi] [ +0.000014] do_one_initcall+0xc4/0x2b0 [ +0.000008] do_init_module+0x154/0x570 [ +0.000010] load_module+0x1a78/0x1ea4 [ +0.000008] __do_sys_init_module+0x184/0x1cc [ +0.000008] __arm64_sys_init_module+0x78/0xb0 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000008] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] Allocated by task 902: [ +0.000007] kasan_save_stack+0x2c/0x5c [ +0.000009] __kasan_kmalloc+0x90/0xd0 [ +0.000007] __kmalloc_node+0x240/0x580 [ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac [ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0 [ +0.000008] kmem_cache_alloc_node+0x1d0/0x490 [ +0.000009] __alloc_skb+0x1d4/0x310 [ +0.000010] alloc_skb_with_frags+0x8c/0x620 [ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0 [ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0 [ +0.000010] sock_sendmsg+0xcc/0x110 [ +0.000007] sock_write_iter+0x1d0/0x304 [ +0.000008] new_sync_write+0x364/0x460 [ +0.000007] vfs_write+0x420/0x5ac [ +0.000008] ksys_write+0x19c/0x1f0 [ +0.000008] __arm64_sys_write+0x78/0xb0 [ +0.000007] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000013] Freed by task 2509: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000007] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000008] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000010] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000008] devres_release_all+0xfc/0x180 [ +0.000008] device_unbind_cleanup+0x24/0x164 [ +0.000008] device_release_driver_internal+0x3e8/0x5b0 [ +0.000010] driver_detach+0xac/0x1b0 [ +0.000008] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000009] platform_driver_unregister+0x20/0x2c [ +0.000007] 0xffff800003722d98 [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000009] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000008] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000013] Last potentially related work creation: [ +0.000007] kasan_save_stack+0x2c/0x5c [ +0.000007] __kasan_record_aux_stack+0xb8/0xf0 [ +0.000009] kasan_record_aux_stack_noalloc+0x14/0x20 [ +0.000008] insert_work+0x54/0x290 [ +0.000009] __queue_work+0x48c/0xd24 [ +0.000008] queue_work_on+0x90/0x11c [ +0.000008] call_usermodehelper_exec+0x188/0x404 [ +0.000010] kobject_uevent_env+0x5a8/0x794 [ +0.000010] kobject_uevent+0x14/0x20 [ +0.000008] driver_register+0x230/0x3e4 [ +0.000009] __platform_driver_register+0x6c/0x94 [ +0.000007] gxbb_driver_init+0x28/0x34 [ +0.000010] do_one_initcall+0xc4/0x2b0 [ +0.000008] do_initcalls+0x20c/0x24c [ +0.000010] kernel_init_freeable+0x22c/0x278 [ +0.000009] kernel_init+0x3c/0x170 [ +0.000008] ret_from_fork+0x10/0x20 [ +0.000013] The buggy address belongs to the object at ffff000006731600 which belongs to the cache kmalloc-256 of size 256 [ +0.000009] The buggy address is located 136 bytes inside of 256-byte region [ffff000006731600, ffff000006731700) [ +0.000015] The buggy address belongs to the physical page: [ +0.000008] page:fffffc000019cc00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff000006730a00 pfn:0x6730 [ +0.000011] head:fffffc000019cc00 order:2 compound_mapcount:0 compound_pincount:0 [ +0.000008] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000016] raw: 0ffff00000010200 fffffc00000c3d08 fffffc0000ef2b08 ffff000000002680 [ +0.000009] raw: ffff000006730a00 0000000000150014 00000001ffffffff 0000000000000000 [ +0.000006] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000007] ffff000006731580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000007] ffff000006731600: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff000006731680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000006] ffff000006731700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000007] ffff000006731780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ +0.000006] ================================================================== Fix by adding 'remove' driver callback for meson-drm, and explicitly deleting the aggregate device. Signed-off-by: Adrián Larumbe Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20220919010940.419893-3-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin commit 9190d287f7a6b02b50b510045b0edf448ed68e88 Author: Adrián Larumbe Date: Mon Sep 19 02:09:38 2022 +0100 drm/meson: reorder driver deinit sequence to fix use-after-free bug [ Upstream commit 31c519981eb141c7ec39bfd5be25d35f02edb868 ] Unloading the driver triggers the following KASAN warning: [ +0.006275] ============================================================= [ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0 [ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695 [ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1 [ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT) [ +0.000008] Call trace: [ +0.000007] dump_backtrace+0x1ec/0x280 [ +0.000013] show_stack+0x24/0x80 [ +0.000008] dump_stack_lvl+0x98/0xd4 [ +0.000011] print_address_description.constprop.0+0x80/0x520 [ +0.000011] print_report+0x128/0x260 [ +0.000007] kasan_report+0xb8/0xfc [ +0.000008] __asan_report_load8_noabort+0x3c/0x50 [ +0.000010] __list_del_entry_valid+0xe0/0x1a0 [ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm] [ +0.000172] drm_bridge_detach+0x94/0x260 [drm] [ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm] [ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm] [ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm] [ +0.000144] drm_managed_release+0x170/0x414 [drm] [ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm] [ +0.000143] drm_dev_put+0x20/0x30 [drm] [ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm] [ +0.000028] take_down_aggregate_device+0xb0/0x160 [ +0.000016] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000015] platform_remove+0x64/0xb0 [ +0.000009] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000009] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000012] __do_sys_delete_module+0x288/0x400 [ +0.000011] __arm64_sys_delete_module+0x5c/0x80 [ +0.000009] invoke_syscall+0x74/0x260 [ +0.000009] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000009] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000012] el0t_64_sync_handler+0x11c/0x150 [ +0.000008] el0t_64_sync+0x18c/0x190 [ +0.000018] Allocated by task 0: [ +0.000007] (stack is not available) [ +0.000011] Freed by task 2695: [ +0.000008] kasan_save_stack+0x2c/0x5c [ +0.000011] kasan_set_track+0x2c/0x40 [ +0.000008] kasan_set_free_info+0x28/0x50 [ +0.000009] ____kasan_slab_free+0x128/0x1d4 [ +0.000008] __kasan_slab_free+0x18/0x24 [ +0.000007] slab_free_freelist_hook+0x108/0x230 [ +0.000011] kfree+0x110/0x35c [ +0.000008] release_nodes+0xf0/0x16c [ +0.000009] devres_release_group+0x180/0x270 [ +0.000008] component_unbind+0x128/0x1e0 [ +0.000010] component_unbind_all+0x1b8/0x264 [ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm] [ +0.000025] take_down_aggregate_device+0xb0/0x160 [ +0.000009] component_del+0x18c/0x360 [ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi] [ +0.000012] platform_remove+0x64/0xb0 [ +0.000008] device_remove+0xb8/0x154 [ +0.000009] device_release_driver_internal+0x398/0x5b0 [ +0.000009] driver_detach+0xac/0x1b0 [ +0.000009] bus_remove_driver+0x158/0x29c [ +0.000008] driver_unregister+0x70/0xb0 [ +0.000008] platform_driver_unregister+0x20/0x2c [ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi] [ +0.000011] __do_sys_delete_module+0x288/0x400 [ +0.000010] __arm64_sys_delete_module+0x5c/0x80 [ +0.000008] invoke_syscall+0x74/0x260 [ +0.000008] el0_svc_common.constprop.0+0xcc/0x260 [ +0.000008] do_el0_svc+0x50/0x70 [ +0.000007] el0_svc+0x68/0x1a0 [ +0.000009] el0t_64_sync_handler+0x11c/0x150 [ +0.000009] el0t_64_sync+0x18c/0x190 [ +0.000014] The buggy address belongs to the object at ffff000020c39000 which belongs to the cache kmalloc-4k of size 4096 [ +0.000008] The buggy address is located 1504 bytes inside of 4096-byte region [ffff000020c39000, ffff000020c3a000) [ +0.000016] The buggy address belongs to the physical page: [ +0.000009] page:fffffc0000830e00 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x20c38 [ +0.000013] head:fffffc0000830e00 order:3 compound_mapcount:0 compound_pincount:0 [ +0.000008] flags: 0xffff00000010200(slab|head|node=0|zone=0|lastcpupid=0xffff) [ +0.000019] raw: 0ffff00000010200 fffffc0000fd4808 fffffc0000126208 ffff000000002e80 [ +0.000009] raw: 0000000000000000 0000000000020002 00000001ffffffff 0000000000000000 [ +0.000008] page dumped because: kasan: bad access detected [ +0.000011] Memory state around the buggy address: [ +0.000008] ffff000020c39480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff000020c39500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] >ffff000020c39580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ^ [ +0.000007] ffff000020c39600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000007] ffff000020c39680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ +0.000006] ================================================================== The reason this is happening is unloading meson-dw-hdmi will cause the component API to take down the aggregate device, which in turn will cause all devres-managed memory to be freed, including the struct dw_hdmi allocated in dw_hdmi_probe. This struct embeds a struct drm_bridge that is added at the end of the function, and which is later on picked up in meson_encoder_hdmi_init. However, when attaching the bridge to the encoder created in meson_encoder_hdmi_init, it's linked to the encoder's bridge chain, from where it never leaves, even after devres_release_group is called when the driver's components are unbound and the embedding structure freed. Then, when calling drm_dev_put in the aggregate driver's unbind function, drm_bridge_detach is called for every single bridge linked to the encoder, including the one whose memory had already been deallocated. Fix by calling component_unbind_all after drm_dev_put. Signed-off-by: Adrián Larumbe Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20220919010940.419893-2-adrian.larumbe@collabora.com Signed-off-by: Sasha Levin commit fc273ad2e3f53763ac21f590fb16077b006d4b72 Author: hongao Date: Tue Sep 20 17:24:53 2022 +0800 drm/amdgpu: fix initial connector audio value [ Upstream commit 4bb71fce58f30df3f251118291d6b0187ce531e6 ] This got lost somewhere along the way, This fixes audio not working until set_property was called. Signed-off-by: hongao Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 50f9f5d15eaefc9ad4baf6a99bf0495aba14e6c0 Author: Sherry Wang Date: Wed Sep 7 00:12:44 2022 +0800 drm/amd/display: correct hostvm flag [ Upstream commit 796d6a37ff5ffaf9f2dc0f3f4bf9f4a1034c00de ] [Why] Hostvm should be enabled/disabled accordding to the status of riommu_active, but hostvm always be disabled on DCN31 which causes underflow [How] Set correct hostvm flag on DCN31 Reviewed-by: Charlene Liu Acked-by: Wayne Lin Signed-off-by: Sherry Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b892c57a3a04c8de247ab9ee08a0a8cf53290e19 Author: Philip Yang Date: Tue Sep 13 15:46:30 2022 -0400 drm/amdgpu: SDMA update use unlocked iterator [ Upstream commit 3913f0179ba366f7d7d160c506ce00de1602bbc4 ] SDMA update page table may be called from unlocked context, this generate below warning. Use unlocked iterator to handle this case. WARNING: CPU: 0 PID: 1475 at drivers/dma-buf/dma-resv.c:483 dma_resv_iter_next Call Trace: dma_resv_iter_first+0x43/0xa0 amdgpu_vm_sdma_update+0x69/0x2d0 [amdgpu] amdgpu_vm_ptes_update+0x29c/0x870 [amdgpu] amdgpu_vm_update_range+0x2f6/0x6c0 [amdgpu] svm_range_unmap_from_gpus+0x115/0x300 [amdgpu] svm_range_cpu_invalidate_pagetables+0x510/0x5e0 [amdgpu] __mmu_notifier_invalidate_range_start+0x1d3/0x230 unmap_vmas+0x140/0x150 unmap_region+0xa8/0x110 Signed-off-by: Philip Yang Suggested-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9a0b26c494d3ca37c15172bf56aa84fe2f2de722 Author: Pierre-Louis Bossart Date: Mon Sep 19 13:53:48 2022 +0200 ASoC: SOF: add quirk to override topology mclk_id [ Upstream commit d136949dd8e2e309dc2f186507486b71cbe9acdb ] Some Intel-based platforms rely on a topology file that hard-codes the use of MCLK0. This is incorrect in 10% of the cases. Rather than generating yet another set of topology files, this patch adds a kernel module parameter to override the topology value. In hindsight, we should never have allowed mclks to be specified in topology, this is a hardware-level information that should not have been visible in the topology. Future patches will try to set this value automagically, e.g. by parsing the NHLT content. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20220919115350.43104-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6a4c1ca1f3fbd849c6ac5a511a9c827f6aa48af3 Author: Jairaj Arava Date: Mon Sep 19 13:44:29 2022 +0200 ASoC: SOF: pci: Change DMI match info to support all Chrome platforms [ Upstream commit c1c1fc8103f794a10c5c15e3c17879caf4f42c8f ] In some Chrome platforms if OEM's use their own string as SYS_VENDOR than "Google", it leads to firmware load failure from intel/sof/community path. Hence, changing SYS_VENDOR to PRODUCT_FAMILY in which "Google" is used as common prefix and is supported in all Chrome platforms. Reviewed-by: Ranjani Sridharan Reviewed-by: Chao Song Reviewed-by: Curtis Malainey Signed-off-by: Jairaj Arava Signed-off-by: Curtis Malainey Signed-off-by: Sathyanarayana Nujella Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220919114429.42700-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c72d295e79ebf77d47b24ea30301eb6a15f69b1 Author: Muralidhar Reddy Date: Mon Sep 19 13:45:48 2022 +0200 ALSA: intel-dspconfig: add ES8336 support for AlderLake-PS [ Upstream commit 9db1c9fa214ef41d098633ff40a87284ca6e1870 ] added quirks for ESS8336 for AlderLake-PS Reviewed-by: Ranjani Sridharan Signed-off-by: Muralidhar Reddy Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20220919114548.42769-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6c28e90c8fd0f9491e712fd91362f032cd8cacd7 Author: Hans de Goede Date: Sat Sep 17 23:04:07 2022 +0200 platform/x86: msi-laptop: Change DMI match / alias strings to fix module autoloading [ Upstream commit 2a2565272a3628e45d61625e36ef17af7af4e3de ] On a MSI S270 with Fedora 37 x86_64 / systemd-251.4 the module does not properly autoload. This is likely caused by issues with how systemd-udevd handles the single quote char (') which is part of the sys_vendor / chassis_vendor strings on this laptop. As a workaround remove the single quote char + everything behind it from the sys_vendor + chassis_vendor matches. This fixes the module not autoloading. Link: https://github.com/systemd/systemd/issues/24715 Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220917210407.647432-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 14992b9f184baee401a7fb6bd0ce5ceae7d3a307 Author: Jorge Lopez Date: Mon Sep 12 14:26:03 2022 -0500 platform/x86: hp-wmi: Setting thermal profile fails with 0x06 [ Upstream commit 00b1829294b7c88ecba92c661fbe6fe347b364d2 ] Error 0x06 (invalid command parameter) is reported by hp-wmi module when reading the current thermal profile and then proceed to set it back. The failing condition occurs in Linux NixOS after user configures the thermal profile to ‘quiet mode’ in Windows. Quiet Fan Mode is supported in Windows but was not supported in hp-wmi module. This fix adds support for PLATFORM_PROFILE_QUIET in hp-wmi module for HP notebooks other than HP Omen series. Quiet thermal profile is not supported in HP Omen series notebooks. Signed-off-by: Jorge Lopez Link: https://lore.kernel.org/r/20220912192603.4001-1-jorge.lopez2@hp.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit c1f00121bf317f6339f2c498d691e3403fad2ba1 Author: Jameson Thies Date: Tue Sep 13 20:49:54 2022 +0000 platform/chrome: cros_ec: Notify the PM of wake events during resume [ Upstream commit 8edd2752b0aa498b3a61f3caee8f79f7e0567fad ] cros_ec_handle_event in the cros_ec driver can notify the PM of wake events. When a device is suspended, cros_ec_handle_event will not check MKBP events. Instead, received MKBP events are checked during resume by cros_ec_report_events_during_suspend. But cros_ec_report_events_during_suspend cannot notify the PM if received events are wake events, causing wake events to not be reported if received while the device is suspended. Update cros_ec_report_events_during_suspend to notify the PM of wake events during resume by calling pm_wakeup_event. Signed-off-by: Jameson Thies Reviewed-by: Prashant Malani Reviewed-by: Benson Leung Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220913204954.2931042-1-jthies@google.com Signed-off-by: Sasha Levin commit a4b47825426426a937cf7603f99825bbab48c366 Author: Maya Matuszczyk Date: Thu Aug 25 21:19:47 2022 +0200 drm: panel-orientation-quirks: Add quirk for Aya Neo Air [ Upstream commit e10ea7b9b90219da305a16b3c1252169715a807b ] Yet another x86 gaming handheld. This one has many SKUs with quite a few of DMI strings, so let's just use a catchall, just as with Aya Neo Next. Signed-off-by: Maya Matuszczyk Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20220825191946.1678798-1-maccraft123mc@gmail.com Signed-off-by: Sasha Levin commit d52193da78bdea91385a545f7b7d27e56c3a8f80 Author: Maya Matuszczyk Date: Wed Aug 3 20:24:03 2022 +0200 drm: panel-orientation-quirks: Add quirk for Anbernic Win600 [ Upstream commit 770e19076065e079a32f33eb11be2057c87f1cde ] This device is another x86 gaming handheld, and as (hopefully) there is only one set of DMI IDs it's using DMI_EXACT_MATCH Signed-off-by: Maya Matuszczyk Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20220803182402.1217293-1-maccraft123mc@gmail.com Signed-off-by: Sasha Levin commit a7f778799d49e7e0d1174ad87e513c12ad6a762a Author: Mateusz Kwiatkowski Date: Mon Aug 29 15:11:42 2022 +0200 drm/vc4: vec: Fix timings for VEC modes [ Upstream commit 30d7565be96b3946c18a1ce3fd538f7946839092 ] This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Signed-off-by: Mateusz Kwiatkowski Acked-by: Noralf Trønnes Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220728-rpi-analog-tv-properties-v2-28-459522d653a7@cerno.tech Signed-off-by: Sasha Levin commit 0f1bddc91d55a8861c7781a77a82641405aa6697 Author: Takashi Iwai Date: Sun Sep 4 18:12:47 2022 +0200 ALSA: usb-audio: Register card at the last interface [ Upstream commit 6392dcd1d0c7034ccf630ec55fc9e5810ecadf3b ] The USB-audio driver matches per interface, and as default, it registers the card instance at the very first instance. This can be a problem for the devices that have multiple interfaces to be probed, as the udev rule isn't applied properly for the later appearing interfaces. Although we introduced the delayed_register option and the quirks for covering those shortcomings, it's nothing but a workaround for specific devices. This patch is an another attempt to fix the problem in a more generic way. Now the driver checks the whole USB device descriptor at the very first time when an interface is attached to a sound card. It looks at each matching interface in the descriptor and remembers the last matching one. The snd_card_register() is invoked only when this last interface is probed. After this change, the quirks for the delayed registration become superfluous, hence they are removed along with the patch. OTOH, the delayed_register option is still kept, as it might be useful for some corner cases (e.g. a special driver overtakes the interface probe from the standard driver, and the last interface probe may miss). Link: https://lore.kernel.org/r/20220904161247.16461-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3f2cfb29dceb5a76cdf9d79fbf2b376f953d33bd Author: Yifan Zha Date: Fri Aug 19 11:02:19 2022 +0800 drm/admgpu: Skip CG/PG on SOC21 under SRIOV VF [ Upstream commit 828418259254863e0af5805bd712284e2bd88e3b ] [Why] There is no CG(Clock Gating)/PG(Power Gating) requirement on SRIOV VF. For multi VF, VF should not enable any CG/PG features. For one VF, PF will program CG/PG related registers. [How] Do not set any cg/pg flag bit at early init under sriov. Acked-by: Christian König Signed-off-by: Yifan Zha Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3509d768e206513c2ce70372a2fbc055b2956a75 Author: Yifan Zha Date: Wed Jul 27 13:43:50 2022 +0800 drm/amdgpu: Skip the program of MMMC_VM_AGP_* in SRIOV on MMHUB v3_0_0 [ Upstream commit c1026c6f319724dc88fc08d9d9d35bcbdf492b42 ] [Why] VF should not program these registers, the value were defined in the host. [How] Skip writing them in SRIOV environment and program them on host side. Acked-by: Christian König Signed-off-by: Yifan Zha Signed-off-by: Horace Chen Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e3be30aa035608aefa2de758dda9b4823856f13 Author: Lucas Stach Date: Fri Aug 26 20:57:33 2022 +0200 drm: bridge: dw_hdmi: only trigger hotplug event on link change [ Upstream commit da09daf881082266e4075657fac53c7966de8e4d ] There are two events that signal a real change of the link state: HPD going high means the sink is newly connected or wants the source to re-read the EDID, RX sense going low is a indication that the link has been disconnected. Ignore the other two events that also trigger interrupts, but don't need immediate attention: HPD going low does not necessarily mean the link has been lost and should not trigger a immediate read of the status. RX sense going high also does not require a detect cycle, as HPD going high is the right point in time to read the EDID. Signed-off-by: Lucas Stach Reviewed-by: Neil Armstrong (v1) Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220826185733.3213248-1-l.stach@pengutronix.de Signed-off-by: Sasha Levin commit c6b6279bfdc5073d717491eaffe8f81da5b4e805 Author: Andy Shevchenko Date: Mon Aug 1 14:37:32 2022 +0300 platform/x86: pmc_atom: Improve quirk message to be less cryptic [ Upstream commit 32c9b75640aeb1b144f9e2963c1640f4cef7c6f2 ] Not everyone can get what "critclks" means in the message, improve it to make less cryptic. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220801113734.36131-2-andriy.shevchenko@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit fc285549f454c0f50f87ec945fc0bf44719c0fa4 Author: Vivek Kasireddy Date: Wed Aug 24 23:35:22 2022 -0700 udmabuf: Set ubuf->sg = NULL if the creation of sg table fails [ Upstream commit d9c04a1b7a15b5e74b2977461d9511e497f05d8f ] When userspace tries to map the dmabuf and if for some reason (e.g. OOM) the creation of the sg table fails, ubuf->sg needs to be set to NULL. Otherwise, when the userspace subsequently closes the dmabuf fd, we'd try to erroneously free the invalid sg table from release_udmabuf resulting in the following crash reported by syzbot: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 3609 Comm: syz-executor487 Not tainted 5.19.0-syzkaller-13930-g7ebfc85e2cd7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022 RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline] RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline] RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 04 00 00 48 8d 7d 0c 4c 8b 63 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 e2 RSP: 0018:ffffc900037efd30 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffffffff8cb67800 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff84ad27e0 RDI: 0000000000000000 RBP: fffffffffffffff4 R08: 0000000000000005 R09: 0000000000000000 R10: 0000000000000000 R11: 000000000008c07c R12: ffff88801fa05000 R13: ffff888073db07e8 R14: ffff888025c25440 R15: 0000000000000000 FS: 0000555555fc4300(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc1c0ce06e4 CR3: 00000000715e6000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dma_buf_release+0x157/0x2d0 drivers/dma-buf/dma-buf.c:78 __dentry_kill+0x42b/0x640 fs/dcache.c:612 dentry_kill fs/dcache.c:733 [inline] dput+0x806/0xdb0 fs/dcache.c:913 __fput+0x39c/0x9d0 fs/file_table.c:333 task_work_run+0xdd/0x1a0 kernel/task_work.c:177 ptrace_notify+0x114/0x140 kernel/signal.c:2353 ptrace_report_syscall include/linux/ptrace.h:420 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:482 [inline] syscall_exit_work kernel/entry/common.c:249 [inline] syscall_exit_to_user_mode_prepare+0x129/0x280 kernel/entry/common.c:276 __syscall_exit_to_user_mode_work kernel/entry/common.c:281 [inline] syscall_exit_to_user_mode+0x9/0x50 kernel/entry/common.c:294 do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fc1c0c35b6b Code: 0f 05 48 3d 00 f0 ff ff 77 45 c3 0f 1f 40 00 48 83 ec 18 89 7c 24 0c e8 63 fc ff ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 a1 fc ff ff 8b 44 RSP: 002b:00007ffd78a06090 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000000000000007 RCX: 00007fc1c0c35b6b RDX: 0000000020000280 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 0000000000000007 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 000000000000000c R13: 0000000000000003 R14: 00007fc1c0cfe4a0 R15: 00007ffd78a06140 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:dma_unmap_sgtable include/linux/dma-mapping.h:378 [inline] RIP: 0010:put_sg_table drivers/dma-buf/udmabuf.c:89 [inline] RIP: 0010:release_udmabuf+0xcb/0x4f0 drivers/dma-buf/udmabuf.c:114 Reported-by: syzbot+c80e9ef5d8bb45894db0@syzkaller.appspotmail.com Cc: Gerd Hoffmann Signed-off-by: Vivek Kasireddy Link: http://patchwork.freedesktop.org/patch/msgid/20220825063522.801264-1-vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 1533340aa907ecab4f47ba4f347f28822d463b32 Author: David Gow Date: Thu Aug 11 17:43:26 2022 -0300 drm/amd/display: fix overflow on MIN_I64 definition [ Upstream commit 6ae0632d17759852c07e2d1e0a31c728eb6ba246 ] The definition of MIN_I64 in bw_fixed.c can cause gcc to whinge about integer overflow, because it is treated as a positive value, which is then negated. The temporary positive value is not necessarily representable. This causes the following warning: ../drivers/gpu/drm/amd/amdgpu/../display/dc/dml/calcs/bw_fixed.c:30:19: warning: integer overflow in expression ‘-9223372036854775808’ of type ‘long long int’ results in ‘-9223372036854775808’ [-Woverflow] 30 | (int64_t)(-(1LL << 63)) | ^ Writing out (-MAX_I64 - 1) works instead. Signed-off-by: David Gow Signed-off-by: Tales Aparecida Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b2e4323e0020213f44dca6ffc815d66aef39f6f6 Author: Zeng Jingxiang Date: Wed Jul 27 15:31:19 2022 +0800 gpu: lontium-lt9611: Fix NULL pointer dereference in lt9611_connector_init() [ Upstream commit ef8886f321c5dab8124b9153d25afa2a71d05323 ] A NULL check for bridge->encoder shows that it may be NULL, but it already been dereferenced on all paths leading to the check. 812 if (!bridge->encoder) { Dereference the pointer bridge->encoder. 810 drm_connector_attach_encoder(<9611->connector, bridge->encoder); Signed-off-by: Zeng Jingxiang Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220727073119.1578972-1-zengjx95@gmail.com Signed-off-by: Sasha Levin commit e71fe9b97fae98f40f781ef976413665e81abf20 Author: Liviu Dudau Date: Fri Jul 8 16:39:21 2022 +0100 drm/komeda: Fix handling of atomic commits in the atomic_commit_tail hook [ Upstream commit eaa225b6b52233d45457fd33730e1528c604d92d ] Komeda driver relies on the generic DRM atomic helper functions to handle commits. It only implements an atomic_commit_tail hook for the mode_config_helper_funcs and even that one is pretty close to the generic implementation with the exception of additional dma_fence signalling. What the generic helper framework doesn't do is waiting for the actual hardware to signal that the commit parameters have been written into the appropriate registers. As we signal CRTC events only on the irq handlers, we need to flush the configuration and wait for the hardware to respond. Add the Komeda specific implementation for atomic_commit_hw_done() that flushes and waits for flip done before calling drm_atomic_helper_commit_hw_done(). The fix was prompted by a patch from Carsten Haitzler where he was trying to solve the same issue but in a different way that I think can lead to wrong event signaling to userspace. Reported-by: Carsten Haitzler Tested-by: Carsten Haitzler Reviewed-by: Carsten Haitzler Signed-off-by: Liviu Dudau Link: https://patchwork.freedesktop.org/patch/msgid/20220722122139.288486-1-liviu.dudau@arm.com Signed-off-by: Sasha Levin commit 2d6708ea5c2033ff53267feff1876a717689989f Author: Javier Martinez Canillas Date: Tue Jul 5 12:02:14 2022 +0200 drm: Prevent drm_copy_field() to attempt copying a NULL pointer [ Upstream commit f6ee30407e883042482ad4ad30da5eaba47872ee ] There are some struct drm_driver fields that are required by drivers since drm_copy_field() attempts to copy them to user-space via DRM_IOCTL_VERSION. But it can be possible that a driver has a bug and did not set some of the fields, which leads to drm_copy_field() attempting to copy a NULL pointer: [ +10.395966] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ +0.010955] Mem abort info: [ +0.002835] ESR = 0x0000000096000004 [ +0.003872] EC = 0x25: DABT (current EL), IL = 32 bits [ +0.005395] SET = 0, FnV = 0 [ +0.003113] EA = 0, S1PTW = 0 [ +0.003182] FSC = 0x04: level 0 translation fault [ +0.004964] Data abort info: [ +0.002919] ISV = 0, ISS = 0x00000004 [ +0.003886] CM = 0, WnR = 0 [ +0.003040] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000115dad000 [ +0.006536] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ +0.006925] Internal error: Oops: 96000004 [#1] SMP ... [ +0.011113] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ +0.007061] pc : __pi_strlen+0x14/0x150 [ +0.003895] lr : drm_copy_field+0x30/0x1a4 [ +0.004156] sp : ffff8000094b3a50 [ +0.003355] x29: ffff8000094b3a50 x28: ffff8000094b3b70 x27: 0000000000000040 [ +0.007242] x26: ffff443743c2ba00 x25: 0000000000000000 x24: 0000000000000040 [ +0.007243] x23: ffff443743c2ba00 x22: ffff8000094b3b70 x21: 0000000000000000 [ +0.007241] x20: 0000000000000000 x19: ffff8000094b3b90 x18: 0000000000000000 [ +0.007241] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaab14b9af40 [ +0.007241] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ +0.007239] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa524ad67d4d8 [ +0.007242] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : 6c6e6263606e7141 [ +0.007239] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ +0.007241] x2 : 0000000000000000 x1 : ffff8000094b3b90 x0 : 0000000000000000 [ +0.007240] Call trace: [ +0.002475] __pi_strlen+0x14/0x150 [ +0.003537] drm_version+0x84/0xac [ +0.003448] drm_ioctl_kernel+0xa8/0x16c [ +0.003975] drm_ioctl+0x270/0x580 [ +0.003448] __arm64_sys_ioctl+0xb8/0xfc [ +0.003978] invoke_syscall+0x78/0x100 [ +0.003799] el0_svc_common.constprop.0+0x4c/0xf4 [ +0.004767] do_el0_svc+0x38/0x4c [ +0.003357] el0_svc+0x34/0x100 [ +0.003185] el0t_64_sync_handler+0x11c/0x150 [ +0.004418] el0t_64_sync+0x190/0x194 [ +0.003716] Code: 92402c04 b200c3e8 f13fc09f 5400088c (a9400c02) [ +0.006180] ---[ end trace 0000000000000000 ]--- Reported-by: Peter Robinson Signed-off-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220705100215.572498-3-javierm@redhat.com Signed-off-by: Sasha Levin commit 7ab28b8e182e6c27285a942267eb194b9093d3de Author: Javier Martinez Canillas Date: Tue Jul 5 12:02:13 2022 +0200 drm: Use size_t type for len variable in drm_copy_field() [ Upstream commit 94dc3471d1b2b58b3728558d0e3f264e9ce6ff59 ] The strlen() function returns a size_t which is an unsigned int on 32-bit arches and an unsigned long on 64-bit arches. But in the drm_copy_field() function, the strlen() return value is assigned to an 'int len' variable. Later, the len variable is passed as copy_from_user() third argument that is an unsigned long parameter as well. In theory, this can lead to an integer overflow via type conversion. Since the assignment happens to a signed int lvalue instead of a size_t lvalue. In practice though, that's unlikely since the values copied are set by DRM drivers and not controlled by userspace. But using a size_t for len is the correct thing to do anyways. Signed-off-by: Javier Martinez Canillas Tested-by: Peter Robinson Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220705100215.572498-2-javierm@redhat.com Signed-off-by: Sasha Levin commit 38ba098ef1b616a6212cd9fa8ade6665c514caec Author: Jianglei Nie Date: Tue Jul 5 17:43:06 2022 +0800 drm/nouveau/nouveau_bo: fix potential memory leak in nouveau_bo_alloc() [ Upstream commit 6dc548745d5b5102e3c53dc5097296ac270b6c69 ] nouveau_bo_alloc() allocates a memory chunk for "nvbo" with kzalloc(). When some error occurs, "nvbo" should be released. But when WARN_ON(pi < 0)) equals true, the function return ERR_PTR without releasing the "nvbo", which will lead to a memory leak. We should release the "nvbo" with kfree() if WARN_ON(pi < 0)) equals true. Signed-off-by: Jianglei Nie Signed-off-by: Lyude Paul Reviewed-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20220705094306.2244103-1-niejianglei2021@163.com Signed-off-by: Sasha Levin commit 2e896abccf99fef76691d8e1019bd44105a12e1f Author: Andrew Gaul Date: Sun Oct 2 12:41:28 2022 +0900 r8152: Rate limit overflow messages [ Upstream commit 93e2be344a7db169b7119de21ac1bf253b8c6907 ] My system shows almost 10 million of these messages over a 24-hour period which pollutes my logs. Signed-off-by: Andrew Gaul Link: https://lore.kernel.org/r/20221002034128.2026653-1-gaul@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2a75f83ba81cb4230f8157a6a00c41beb5263b4c Author: Andy Shevchenko Date: Thu Sep 29 12:42:14 2022 +0300 i2c: designware-pci: Group AMD NAVI quirk parts together [ Upstream commit 65769162ae4b7f2d82e54998be446226b05fcd8f ] The code is ogranized in a way that all related parts to the certain platform quirk go together. This is not the case for AMD NAVI. Shuffle code to make it happen. While at it, drop the frequency definition and use hard coded value as it's done for other platforms and add a comment to the PCI ID list. Signed-off-by: Andy Shevchenko Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6ffde6e03085874ae22263ff4cef4869f797e84f Author: Luiz Augusto von Dentz Date: Thu Sep 29 13:27:13 2022 -0700 Bluetooth: L2CAP: Fix user-after-free [ Upstream commit 35fcbc4243aad7e7d020b7c1dfb14bb888b20a4f ] This uses l2cap_chan_hold_unless_zero() after calling __l2cap_get_chan_blah() to prevent the following trace: Bluetooth: l2cap_core.c:static void l2cap_chan_destroy(struct kref *kref) Bluetooth: chan 0000000023c4974d Bluetooth: parent 00000000ae861c08 ================================================================== BUG: KASAN: use-after-free in __mutex_waiter_is_first kernel/locking/mutex.c:191 [inline] BUG: KASAN: use-after-free in __mutex_lock_common kernel/locking/mutex.c:671 [inline] BUG: KASAN: use-after-free in __mutex_lock+0x278/0x400 kernel/locking/mutex.c:729 Read of size 8 at addr ffff888006a49b08 by task kworker/u3:2/389 Link: https://lore.kernel.org/lkml/20220622082716.478486-1-lee.jones@linaro.org Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sungwoo Kim Signed-off-by: Sasha Levin commit 44bd0d19c580005a5afb2bc23f0c9391e1c12165 Author: Song Liu Date: Mon Sep 26 11:47:38 2022 -0700 bpf: use bpf_prog_pack for bpf_dispatcher [ Upstream commit 19c02415da2345d0dda2b5c4495bc17cc14b18b5 ] Allocate bpf_dispatcher with bpf_prog_pack_alloc so that bpf_dispatcher can share pages with bpf programs. arch_prepare_bpf_dispatcher() is updated to provide a RW buffer as working area for arch code to write to. This also fixes CPA W^X warnning like: CPA refuse W^X violation: 8000000000000163 -> 0000000000000163 range: ... Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20220926184739.3512547-2-song@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit d72bc08770faaf03777ac5d85dd3c2e8278ab961 Author: Jiri Olsa Date: Mon Sep 26 17:33:38 2022 +0200 bpf: Adjust kprobe_multi entry_ip for CONFIG_X86_KERNEL_IBT [ Upstream commit c09eb2e578eb1668bbc84dc07e8d8bd6f04b9a02 ] Martynas reported bpf_get_func_ip returning +4 address when CONFIG_X86_KERNEL_IBT option is enabled. When CONFIG_X86_KERNEL_IBT is enabled we'll have endbr instruction at the function entry, which screws return value of bpf_get_func_ip() helper that should return the function address. There's short term workaround for kprobe_multi bpf program made by Alexei [1], but we need this fixup also for bpf_get_attach_cookie, that returns cookie based on the entry_ip value. Moving the fixup in the fprobe handler, so both bpf_get_func_ip and bpf_get_attach_cookie get expected function address when CONFIG_X86_KERNEL_IBT option is enabled. Also renaming kprobe_multi_link_handler entry_ip argument to fentry_ip so it's clearer this is an ftrace __fentry__ ip. [1] commit 7f0059b58f02 ("selftests/bpf: Fix kprobe_multi test.") Cc: Peter Zijlstra Reported-by: Martynas Pumputis Acked-by: Andrii Nakryiko Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20220926153340.1621984-5-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 35f5e70bdfa7432762ac4ffa75e5a7574ac5563e Author: Liu Jian Date: Tue Aug 23 21:37:54 2022 +0800 net: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory [ Upstream commit 3f8ef65af927db247418d4e1db49164d7a158fc5 ] Fixes the below NULL pointer dereference: [...] [ 14.471200] Call Trace: [ 14.471562] [ 14.471882] lock_acquire+0x245/0x2e0 [ 14.472416] ? remove_wait_queue+0x12/0x50 [ 14.473014] ? _raw_spin_lock_irqsave+0x17/0x50 [ 14.473681] _raw_spin_lock_irqsave+0x3d/0x50 [ 14.474318] ? remove_wait_queue+0x12/0x50 [ 14.474907] remove_wait_queue+0x12/0x50 [ 14.475480] sk_stream_wait_memory+0x20d/0x340 [ 14.476127] ? do_wait_intr_irq+0x80/0x80 [ 14.476704] do_tcp_sendpages+0x287/0x600 [ 14.477283] tcp_bpf_push+0xab/0x260 [ 14.477817] tcp_bpf_sendmsg_redir+0x297/0x500 [ 14.478461] ? __local_bh_enable_ip+0x77/0xe0 [ 14.479096] tcp_bpf_send_verdict+0x105/0x470 [ 14.479729] tcp_bpf_sendmsg+0x318/0x4f0 [ 14.480311] sock_sendmsg+0x2d/0x40 [ 14.480822] ____sys_sendmsg+0x1b4/0x1c0 [ 14.481390] ? copy_msghdr_from_user+0x62/0x80 [ 14.482048] ___sys_sendmsg+0x78/0xb0 [ 14.482580] ? vmf_insert_pfn_prot+0x91/0x150 [ 14.483215] ? __do_fault+0x2a/0x1a0 [ 14.483738] ? do_fault+0x15e/0x5d0 [ 14.484246] ? __handle_mm_fault+0x56b/0x1040 [ 14.484874] ? lock_is_held_type+0xdf/0x130 [ 14.485474] ? find_held_lock+0x2d/0x90 [ 14.486046] ? __sys_sendmsg+0x41/0x70 [ 14.486587] __sys_sendmsg+0x41/0x70 [ 14.487105] ? intel_pmu_drain_pebs_core+0x350/0x350 [ 14.487822] do_syscall_64+0x34/0x80 [ 14.488345] entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] The test scenario has the following flow: thread1 thread2 ----------- --------------- tcp_bpf_sendmsg tcp_bpf_send_verdict tcp_bpf_sendmsg_redir sock_close tcp_bpf_push_locked __sock_release tcp_bpf_push //inet_release do_tcp_sendpages sock->ops->release sk_stream_wait_memory // tcp_close sk_wait_event sk->sk_prot->close release_sock(__sk); *** lock_sock(sk); __tcp_close sock_orphan(sk) sk->sk_wq = NULL release_sock **** lock_sock(__sk); remove_wait_queue(sk_sleep(sk), &wait); sk_sleep(sk) //NULL pointer dereference &rcu_dereference_raw(sk->sk_wq)->wait While waiting for memory in thread1, the socket is released with its wait queue because thread2 has closed it. This caused by tcp_bpf_send_verdict didn't increase the f_count of psock->sk_redir->sk_socket->file in thread1. We should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory before accessing the wait queue. Suggested-by: Jakub Sitnicki Signed-off-by: Liu Jian Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Cc: Eric Dumazet Link: https://lore.kernel.org/bpf/20220823133755.314697-2-liujian56@huawei.com Signed-off-by: Sasha Levin commit 19fced8ecda10cc26025ad40542dd27e02578fb9 Author: Jason A. Donenfeld Date: Sat Sep 24 12:11:51 2022 +0200 hwmon: (sht4x) do not overflow clamping operation on 32-bit platforms [ Upstream commit f9c0cf8f26de367c58e48b02b1cdb9c377626e6f ] On 32-bit platforms, long is 32 bits, so (long)UINT_MAX is less than (long)SHT4X_MIN_POLL_INTERVAL, which means the clamping operation is bogus. Fix this by clamping at INT_MAX, so that the upperbound is the same on all platforms. Signed-off-by: Jason A. Donenfeld Link: https://lore.kernel.org/r/20220924101151.4168414-1-Jason@zx2c4.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 68ff5178d965bd1b5bd84e46763e4f731e1c35e4 Author: Daniel Golle Date: Sat Sep 17 21:30:09 2022 +0100 wifi: rt2x00: correctly set BBP register 86 for MT7620 [ Upstream commit c9aada64fe6493461127f1522d7e2f01792d2424 ] Instead of 0 set the correct value for BBP register 86 for MT7620. Reported-by: Serge Vasilugin Signed-off-by: Daniel Golle Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/257267247ee4fa7ebc6a5d0c4948b3f8119c0d77.1663445157.git.daniel@makrotopia.org Signed-off-by: Sasha Levin commit 784881e9e7be905a5d5df393ad74ffc1888689ad Author: Daniel Golle Date: Sat Sep 17 21:29:55 2022 +0100 wifi: rt2x00: set SoC wmac clock register [ Upstream commit cbde6ed406a51092d9e8a2df058f5f8490f27443 ] Instead of using the default value 33 (pci), set US_CYC_CNT init based on Programming guide: If available, set chipset bus clock with fallback to cpu clock/3. Reported-by: Serge Vasilugin Signed-off-by: Daniel Golle Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/3e275d259f476f597dab91a9c395015ef3fe3284.1663445157.git.daniel@makrotopia.org Signed-off-by: Sasha Levin commit 227e5eb1bb5a1372a41caabcb1e6beb3781e66eb Author: Daniel Golle Date: Sat Sep 17 21:29:40 2022 +0100 wifi: rt2x00: set VGC gain for both chains of MT7620 [ Upstream commit 0e09768c085709e10ece3b68f6ac921d3f6a9caa ] Set bbp66 for all chains of the MT7620. Reported-by: Serge Vasilugin Signed-off-by: Daniel Golle Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/29e161397e5c9d9399da0fe87d44458aa2b90a78.1663445157.git.daniel@makrotopia.org Signed-off-by: Sasha Levin commit 0202c5803d642e162f3692a3f63097ec60fe3c5f Author: Daniel Golle Date: Sat Sep 17 21:29:26 2022 +0100 wifi: rt2x00: set correct TX_SW_CFG1 MAC register for MT7620 [ Upstream commit eeb50acf15762b61921f9df18663f839f387c054 ] Set correct TX_SW_CFG1 MAC register as it is done also in v3 of the vendor driver[1]. [1]: https://gitlab.com/dm38/padavan-ng/-/blob/master/trunk/proprietary/rt_wifi/rtpci/3.0.X.X/mt76x2/chips/rt6352.c#L531 Reported-by: Serge Vasilugin Signed-off-by: Daniel Golle Acked-by: Stanislaw Gruszka Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/4be38975ce600a34249e12d09a3cb758c6e71071.1663445157.git.daniel@makrotopia.org Signed-off-by: Sasha Levin commit 36576de88fbe9deb602b19dee016d5916dd131ac Author: Daniel Golle Date: Sat Sep 17 21:28:29 2022 +0100 wifi: rt2x00: don't run Rt5592 IQ calibration on MT7620 [ Upstream commit d3aad83d05aec0cfd7670cf0028f2ad4b81de92e ] The function rt2800_iq_calibrate is intended for Rt5592 only. Don't call it for MT7620 which has it's own calibration functions. Reported-by: Serge Vasilugin Signed-off-by: Daniel Golle Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/31a1c34ddbd296b82f38c18c9ae7339059215fdc.1663445157.git.daniel@makrotopia.org Signed-off-by: Sasha Levin commit a9fc0a42ccbf51bf3db71506fff612677f487efa Author: Ziyang Xuan Date: Thu Sep 15 09:55:56 2022 +0800 can: bcm: check the result of can_send() in bcm_can_tx() [ Upstream commit 3fd7bfd28cfd68ae80a2fe92ea1615722cc2ee6e ] If can_send() fail, it should not update frames_abs counter in bcm_can_tx(). Add the result check for can_send() in bcm_can_tx(). Suggested-by: Marc Kleine-Budde Suggested-by: Oliver Hartkopp Signed-off-by: Ziyang Xuan Link: https://lore.kernel.org/all/9851878e74d6d37aee2f1ee76d68361a46f89458.1663206163.git.william.xuanziyang@huawei.com Acked-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit eb0a9375bbd88a08588936ed252e36955e291d46 Author: Hou Tao Date: Wed Sep 21 15:00:35 2022 +0800 selftests/bpf: Free the allocated resources after test case succeeds [ Upstream commit 103d002fb7d548fb1187e350f2b73788558128b9 ] Free the created fd or allocated bpf_object after test case succeeds, else there will be resource leaks. Spotted by using address sanitizer and checking the content of /proc/$pid/fd directory. Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20220921070035.2016413-3-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit c72dad9a1d37302f09b12b8c6cca68bbd51ccae5 Author: Vadim Fedorenko Date: Thu Sep 22 22:10:38 2022 +0300 bnxt_en: replace reset with config timestamps [ Upstream commit 8db3d514e96715c897fe793c4d5fc0fd86aca517 ] Any change to the hardware timestamps configuration triggers nic restart, which breaks transmition and reception of network packets for a while. But there is no need to fully restart the device because while configuring hardware timestamps. The code for changing configuration runs after all of the initialisation, when the NIC is actually up and running. This patch changes the code that ioctl will only update configuration registers and will not trigger carrier status change, but in case of timestamps for all rx packetes it fallbacks to close()/open() sequnce because of synchronization issues in the hardware. Tested on BCM57504. Cc: Richard Cochran Signed-off-by: Vadim Fedorenko Reviewed-by: Michael Chan Link: https://lore.kernel.org/r/20220922191038.29921-1-vfedorenko@novek.ru Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit ef055094df4c10b73cfe67c8d43f9de1fb608a8b Author: Luiz Augusto von Dentz Date: Mon Sep 19 10:56:59 2022 -0700 Bluetooth: hci_sysfs: Fix attempting to call device_add multiple times [ Upstream commit 448a496f760664d3e2e79466aa1787e6abc922b5 ] device_add shall not be called multiple times as stated in its documentation: 'Do not call this routine or device_register() more than once for any device structure' Syzkaller reports a bug as follows [1]: ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:33! invalid opcode: 0000 [#1] PREEMPT SMP KASAN [...] Call Trace: __list_add include/linux/list.h:69 [inline] list_add_tail include/linux/list.h:102 [inline] kobj_kset_join lib/kobject.c:164 [inline] kobject_add_internal+0x18f/0x8f0 lib/kobject.c:214 kobject_add_varg lib/kobject.c:358 [inline] kobject_add+0x150/0x1c0 lib/kobject.c:410 device_add+0x368/0x1e90 drivers/base/core.c:3452 hci_conn_add_sysfs+0x9b/0x1b0 net/bluetooth/hci_sysfs.c:53 hci_le_cis_estabilished_evt+0x57c/0xae0 net/bluetooth/hci_event.c:6799 hci_le_meta_evt+0x2b8/0x510 net/bluetooth/hci_event.c:7110 hci_event_func net/bluetooth/hci_event.c:7440 [inline] hci_event_packet+0x63d/0xfd0 net/bluetooth/hci_event.c:7495 hci_rx_work+0xae7/0x1230 net/bluetooth/hci_core.c:4007 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 Link: https://syzkaller.appspot.com/bug?id=da3246e2d33afdb92d66bc166a0934c5b146404a Signed-off-by: Luiz Augusto von Dentz Tested-by: Hawkins Jiawei Signed-off-by: Sasha Levin commit e812142450e018fd7baffc8aadb48e257c97328a Author: Tetsuo Handa Date: Sun Sep 4 00:32:56 2022 +0900 Bluetooth: L2CAP: initialize delayed works at l2cap_chan_create() [ Upstream commit 2d2cb3066f2c90cd8ca540b36ba7a55e7f2406e0 ] syzbot is reporting cancel_delayed_work() without INIT_DELAYED_WORK() at l2cap_chan_del() [1], for CONF_NOT_COMPLETE flag (which meant to prevent l2cap_chan_del() from calling cancel_delayed_work()) is cleared by timer which fires before l2cap_chan_del() is called by closing file descriptor created by socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_L2CAP). l2cap_bredr_sig_cmd(L2CAP_CONF_REQ) and l2cap_bredr_sig_cmd(L2CAP_CONF_RSP) are calling l2cap_ertm_init(chan), and they call l2cap_chan_ready() (which clears CONF_NOT_COMPLETE flag) only when l2cap_ertm_init(chan) succeeded. l2cap_sock_init() does not call l2cap_ertm_init(chan), and it instead sets CONF_NOT_COMPLETE flag by calling l2cap_chan_set_defaults(). However, when connect() is requested, "command 0x0409 tx timeout" happens after 2 seconds from connect() request, and CONF_NOT_COMPLETE flag is cleared after 4 seconds from connect() request, for l2cap_conn_start() from l2cap_info_timeout() callback scheduled by schedule_delayed_work(&conn->info_timer, L2CAP_INFO_TIMEOUT); in l2cap_connect() is calling l2cap_chan_ready(). Fix this problem by initializing delayed works used by L2CAP_MODE_ERTM mode as soon as l2cap_chan_create() allocates a channel, like I did in commit be8597239379f0f5 ("Bluetooth: initialize skb_queue_head at l2cap_chan_create()"). Link: https://syzkaller.appspot.com/bug?extid=83672956c7aa6af698b3 [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 26bdfc8755598e6f3b02740c14d0fa83f67e3908 Author: Po-Hao Huang Date: Fri Sep 16 11:38:10 2022 +0800 wifi: rtw89: fix rx filter after scan [ Upstream commit 812825c2b204c491f1a5586c602e4ac75060493a ] In monitor mode we should be able to received all packets even if it's not destined to us. But after scan, the configuration was wrongly set, so we fix it. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220916033811.13862-7-pkshih@realtek.com Signed-off-by: Sasha Levin commit d4b4f6ff8ff1b87d25977423cf38fb61744d0023 Author: Po-Hao Huang Date: Fri Sep 16 11:38:09 2022 +0800 wifi: rtw89: free unused skb to prevent memory leak [ Upstream commit eae672f386049146058b9e5d3d33e9e4af9dca1d ] This avoid potential memory leak under power saving mode. Signed-off-by: Po-Hao Huang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220916033811.13862-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit b32b0cd0eddb0b1788fdc4b32c1da475e8ec125c Author: Sean Wang Date: Tue Aug 30 06:57:44 2022 +0800 wifi: mt76: mt7921: reset msta->airtime_ac while clearing up hw value [ Upstream commit 1bf66dc31032ff5292f4d5b76436653f269fcfbd ] We should reset mstat->airtime_ac along with clear up the entries in the hardware WLAN table for the Rx and Rx accumulative airtime. Otherwsie, the value msta->airtime_ac - [tx, rx]_last may be a negative and that is not the actual airtime the device took in the last run. Reported-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 72ef896e80b6ec7cdc1dd42577045f8e7c9c32b3 Author: Jianglei Nie Date: Wed Sep 7 15:37:04 2022 +0800 wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register() [ Upstream commit 43e7c3505ec70db3d3c6458824d5fa40f62e3e7b ] mhi_alloc_controller() allocates a memory space for mhi_ctrl. When gets some error, mhi_ctrl should be freed with mhi_free_controller(). But when ath11k_mhi_read_addr_from_dt() fails, the function returns without calling mhi_free_controller(), which will lead to a memory leak. We can fix it by calling mhi_free_controller() when ath11k_mhi_read_addr_from_dt() fails. Signed-off-by: Jianglei Nie Reviewed-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220907073704.58806-1-niejianglei2021@163.com Signed-off-by: Sasha Levin commit 9f2395316e4845466cb9b5b9b15a171a2c91913c Author: Patrick Rudolph Date: Fri Sep 9 14:59:53 2022 +0200 regulator: core: Prevent integer underflow [ Upstream commit 8d8e16592022c9650df8aedfe6552ed478d7135b ] By using a ratio of delay to poll_enabled_time that is not integer time_remaining underflows and does not exit the loop as expected. As delay could be derived from DT and poll_enabled_time is defined in the driver this can easily happen. Use a signed iterator to make sure that the loop exits once the remaining time is negative. Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 52b43d6402bcbc45eaeefc0f6d7f1ac544ad3328 Author: Kiran K Date: Wed Sep 7 12:49:45 2022 +0530 Bluetooth: btintel: Mark Intel controller to support LE_STATES quirk [ Upstream commit dd0a1794f4334ddbf9b7c5e7d642aaffff38c69b ] HarrrisonPeak, CyclonePeak, SnowFieldPeak and SandyPeak controllers are marked to support HCI_QUIRK_LE_STATES. Signed-off-by: Kiran K Signed-off-by: Chethan T N Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 27574a3f421c3a1694d0207f37c6bbf23d66978e Author: Alexander Coffin Date: Mon Aug 8 10:49:26 2022 -0700 wifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit() [ Upstream commit 3f42faf6db431e04bf942d2ebe3ae88975723478 ] > ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb); may be schedule, and then complete before the line > ndev->stats.tx_bytes += skb->len; [ 46.912801] ================================================================== [ 46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328 [ 46.935991] [ 46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G O 5.4.199-[REDACTED] #1 [ 46.947255] Hardware name: [REDACTED] [ 46.954568] Call trace: [ 46.957037] dump_backtrace+0x0/0x2b8 [ 46.960719] show_stack+0x24/0x30 [ 46.964052] dump_stack+0x128/0x194 [ 46.967557] print_address_description.isra.0+0x64/0x380 [ 46.972877] __kasan_report+0x1d4/0x240 [ 46.976723] kasan_report+0xc/0x18 [ 46.980138] __asan_report_load4_noabort+0x18/0x20 [ 46.985027] brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac] [ 46.990613] dev_hard_start_xmit+0x1bc/0xda0 [ 46.994894] sch_direct_xmit+0x198/0xd08 [ 46.998827] __qdisc_run+0x37c/0x1dc0 [ 47.002500] __dev_queue_xmit+0x1528/0x21f8 [ 47.006692] dev_queue_xmit+0x24/0x30 [ 47.010366] neigh_resolve_output+0x37c/0x678 [ 47.014734] ip_finish_output2+0x598/0x2458 [ 47.018927] __ip_finish_output+0x300/0x730 [ 47.023118] ip_output+0x2e0/0x430 [ 47.026530] ip_local_out+0x90/0x140 [ 47.030117] igmpv3_sendpack+0x14c/0x228 [ 47.034049] igmpv3_send_cr+0x384/0x6b8 [ 47.037895] igmp_ifc_timer_expire+0x4c/0x118 [ 47.042262] call_timer_fn+0x1cc/0xbe8 [ 47.046021] __run_timers+0x4d8/0xb28 [ 47.049693] run_timer_softirq+0x24/0x40 [ 47.053626] __do_softirq+0x2c0/0x117c [ 47.057387] irq_exit+0x2dc/0x388 [ 47.060715] __handle_domain_irq+0xb4/0x158 [ 47.064908] gic_handle_irq+0x58/0xb0 [ 47.068581] el0_irq_naked+0x50/0x5c [ 47.072162] [ 47.073665] Allocated by task 328: [ 47.077083] save_stack+0x24/0xb0 [ 47.080410] __kasan_kmalloc.isra.0+0xc0/0xe0 [ 47.084776] kasan_slab_alloc+0x14/0x20 [ 47.088622] kmem_cache_alloc+0x15c/0x468 [ 47.092643] __alloc_skb+0xa4/0x498 [ 47.096142] igmpv3_newpack+0x158/0xd78 [ 47.099987] add_grhead+0x210/0x288 [ 47.103485] add_grec+0x6b0/0xb70 [ 47.106811] igmpv3_send_cr+0x2e0/0x6b8 [ 47.110657] igmp_ifc_timer_expire+0x4c/0x118 [ 47.115027] call_timer_fn+0x1cc/0xbe8 [ 47.118785] __run_timers+0x4d8/0xb28 [ 47.122457] run_timer_softirq+0x24/0x40 [ 47.126389] __do_softirq+0x2c0/0x117c [ 47.130142] [ 47.131643] Freed by task 180: [ 47.134712] save_stack+0x24/0xb0 [ 47.138041] __kasan_slab_free+0x108/0x180 [ 47.142146] kasan_slab_free+0x10/0x18 [ 47.145904] slab_free_freelist_hook+0xa4/0x1b0 [ 47.150444] kmem_cache_free+0x8c/0x528 [ 47.154292] kfree_skbmem+0x94/0x108 [ 47.157880] consume_skb+0x10c/0x5a8 [ 47.161466] __dev_kfree_skb_any+0x88/0xa0 [ 47.165598] brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil] [ 47.171023] brcmf_txfinalize+0xec/0x190 [brcmfmac] [ 47.176016] brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac] [ 47.182056] brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac] [ 47.187568] brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac] [ 47.192529] brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac] [ 47.197859] process_one_work+0x7fc/0x1a80 [ 47.201965] worker_thread+0x31c/0xc40 [ 47.205726] kthread+0x2d8/0x370 [ 47.208967] ret_from_fork+0x10/0x18 [ 47.212546] [ 47.214051] The buggy address belongs to the object at ffffff803f588280 [ 47.214051] which belongs to the cache skbuff_head_cache of size 208 [ 47.227086] The buggy address is located 104 bytes inside of [ 47.227086] 208-byte region [ffffff803f588280, ffffff803f588350) [ 47.238814] The buggy address belongs to the page: [ 47.243618] page:ffffffff00dd6200 refcount:1 mapcount:0 mapping:ffffff804b6bf800 index:0xffffff803f589900 compound_mapcount: 0 [ 47.255007] flags: 0x10200(slab|head) [ 47.258689] raw: 0000000000010200 ffffffff00dfa980 0000000200000002 ffffff804b6bf800 [ 47.266439] raw: ffffff803f589900 0000000080190018 00000001ffffffff 0000000000000000 [ 47.274180] page dumped because: kasan: bad access detected [ 47.279752] [ 47.281251] Memory state around the buggy address: [ 47.286051] ffffff803f588180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 47.293277] ffffff803f588200: fb fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 47.300502] >ffffff803f588280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 47.307723] ^ [ 47.314343] ffffff803f588300: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc [ 47.321569] ffffff803f588380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb [ 47.328789] ================================================================== Signed-off-by: Alexander Coffin Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220808174925.3922558-1-alex.coffin@matician.com Signed-off-by: Sasha Levin commit 47c838195c7d800e1e1bc9181d588095037e4c18 Author: Michal Jaron Date: Thu Aug 18 13:32:33 2022 +0200 iavf: Fix race between iavf_close and iavf_reset_task [ Upstream commit 11c12adcbc1598d91e73ab6ddfa41d25a01478ed ] During stress tests with adding VF to namespace and changing vf's trust there was a race between iavf_reset_task and iavf_close. Sometimes when IAVF_FLAG_AQ_DISABLE_QUEUES from iavf_close was sent to PF after reset and before IAVF_AQ_GET_CONFIG was sent then PF returns error IAVF_NOT_SUPPORTED to disable queues request and following requests. There is need to get_config before other aq_required will be send but iavf_close clears all flags, if get_config was not sent before iavf_close, then it will not be send at all. In case when IAVF_FLAG_AQ_GET_OFFLOAD_VLAN_V2_CAPS was sent before IAVF_FLAG_AQ_DISABLE_QUEUES then there was rtnl_lock deadlock between iavf_close and iavf_adminq_task until iavf_close timeouts and disable queues was sent after iavf_close ends. There was also a problem with sending delete/add filters. Sometimes when filters was not yet added to PF and in iavf_close all filters was set to remove there might be a try to remove nonexistent filters on PF. Add aq_required_tmp to save aq_required flags and send them after disable_queues will be handled. Clear flags given to iavf_down different than IAVF_FLAG_AQ_GET_CONFIG as this flag is necessary to sent other aq_required. Remove some flags that we don't want to send as we are in iavf_close and we want to disable interface. Remove filters which was not yet sent and send del filters flags only when there are filters to remove. Signed-off-by: Michal Jaron Signed-off-by: Mateusz Palczewski Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8a648bb49115e7c5ec10b4b5d721aa339d9f695a Author: Zong-Zhe Yang Date: Mon Jul 4 10:34:51 2022 +0800 rtw89: ser: leave lps with mutex [ Upstream commit 8676031bae1c91037d06341214f4150b33707c68 ] Calling rtw89_leave_lps() should hold rtwdev::mutex. So, fix it. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220704023453.19935-5-pkshih@realtek.com Signed-off-by: Sasha Levin commit 56d96f8f9bbd289a79b8428ce6461ba810d74175 Author: Manikanta Pubbisetty Date: Wed Aug 31 09:04:19 2022 +0300 wifi: ath11k: Register shutdown handler for WCN6750 [ Upstream commit ac41c2b642b136a1e633379fcb87a9db0ee07f5b ] When the system shuts down, SMMU driver will be stopped and will not assist in IOVA translations. SMMU driver expects all of its consumers to shutdown before shutting down itself. WCN6750 being one of the consumer device should not perform any DMA operations after the SMMU has shutdown which will otherwise result in SMMU faults. SMMU driver will call the shutdown() callback of all its consumer devices and the consumers shall stop further DMA activity after the invocation of their respective shutdown() callbacks. Register the shutdown() callback to the platform core for WCN6750. Change will not impact other AHB ath11k devices. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Signed-off-by: Manikanta Pubbisetty Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220720134710.15523-1-quic_mpubbise@quicinc.com Signed-off-by: Sasha Levin commit f3bdba4440d82e0da2b1bfc35d3836c8a8e00677 Author: Khalid Masum Date: Thu Sep 1 13:12:10 2022 +0600 xfrm: Update ipcomp_scratches with NULL when freed [ Upstream commit 8a04d2fc700f717104bfb95b0f6694e448a4537f ] Currently if ipcomp_alloc_scratches() fails to allocate memory ipcomp_scratches holds obsolete address. So when we try to free the percpu scratches using ipcomp_free_scratches() it tries to vfree non existent vm area. Described below: static void * __percpu *ipcomp_alloc_scratches(void) { ... scratches = alloc_percpu(void *); if (!scratches) return NULL; ipcomp_scratches does not know about this allocation failure. Therefore holding the old obsolete address. ... } So when we free, static void ipcomp_free_scratches(void) { ... scratches = ipcomp_scratches; Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i)); Trying to free non existent page, causing warning: trying to vfree existent vm area. ... } Fix this breakage by updating ipcomp_scrtches with NULL when scratches is freed Suggested-by: Herbert Xu Reported-by: syzbot+5ec9bb042ddfe9644773@syzkaller.appspotmail.com Tested-by: syzbot+5ec9bb042ddfe9644773@syzkaller.appspotmail.com Signed-off-by: Khalid Masum Acked-by: Herbert Xu Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit a948da5aba024cb96b9b762feec352f21de2794f Author: Richard Gobert Date: Mon Aug 29 13:18:51 2022 +0200 net-next: Fix IP_UNICAST_IF option behavior for connected sockets [ Upstream commit 0e4d354762cefd3e16b4cff8988ff276e45effc4 ] The IP_UNICAST_IF socket option is used to set the outgoing interface for outbound packets. The IP_UNICAST_IF socket option was added as it was needed by the Wine project, since no other existing option (SO_BINDTODEVICE socket option, IP_PKTINFO socket option or the bind function) provided the needed characteristics needed by the IP_UNICAST_IF socket option. [1] The IP_UNICAST_IF socket option works well for unconnected sockets, that is, the interface specified by the IP_UNICAST_IF socket option is taken into consideration in the route lookup process when a packet is being sent. However, for connected sockets, the outbound interface is chosen when connecting the socket, and in the route lookup process which is done when a packet is being sent, the interface specified by the IP_UNICAST_IF socket option is being ignored. This inconsistent behavior was reported and discussed in an issue opened on systemd's GitHub project [2]. Also, a bug report was submitted in the kernel's bugzilla [3]. To understand the problem in more detail, we can look at what happens for UDP packets over IPv4 (The same analysis was done separately in the referenced systemd issue). When a UDP packet is sent the udp_sendmsg function gets called and the following happens: 1. The oif member of the struct ipcm_cookie ipc (which stores the output interface of the packet) is initialized by the ipcm_init_sk function to inet->sk.sk_bound_dev_if (the device set by the SO_BINDTODEVICE socket option). 2. If the IP_PKTINFO socket option was set, the oif member gets overridden by the call to the ip_cmsg_send function. 3. If no output interface was selected yet, the interface specified by the IP_UNICAST_IF socket option is used. 4. If the socket is connected and no destination address is specified in the send function, the struct ipcm_cookie ipc is not taken into consideration and the cached route, that was calculated in the connect function is being used. Thus, for a connected socket, the IP_UNICAST_IF sockopt isn't taken into consideration. This patch corrects the behavior of the IP_UNICAST_IF socket option for connect()ed sockets by taking into consideration the IP_UNICAST_IF sockopt when connecting the socket. In order to avoid reconnecting the socket, this option is still ignored when applied on an already connected socket until connect() is called again by the Richard Gobert. Change the __ip4_datagram_connect function, which is called during socket connection, to take into consideration the interface set by the IP_UNICAST_IF socket option, in a similar way to what is done in the udp_sendmsg function. [1] https://lore.kernel.org/netdev/1328685717.4736.4.camel@edumazet-laptop/T/ [2] https://github.com/systemd/systemd/issues/11935#issuecomment-618691018 [3] https://bugzilla.kernel.org/show_bug.cgi?id=210255 Signed-off-by: Richard Gobert Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20220829111554.GA1771@debian Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7d1e5f5ee93dc9ef50d8eb4191a1b907777ebad9 Author: Robert Hancock Date: Mon Aug 29 17:39:01 2022 -0600 net: axienet: Switch to 64-bit RX/TX statistics [ Upstream commit cb45a8bf4693965e89d115cd2c510f12bc127c37 ] The RX and TX byte/packet statistics in this driver could be overflowed relatively quickly on a 32-bit platform. Switch these stats to use the u64_stats infrastructure to avoid this. Signed-off-by: Robert Hancock Link: https://lore.kernel.org/r/20220829233901.3429419-1-robert.hancock@calian.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 05785ba834f23272f9d23427ae4a80ac505a5296 Author: Daniel Sneddon Date: Tue Aug 16 16:19:42 2022 -0700 x86/apic: Don't disable x2APIC if locked [ Upstream commit b8d1d163604bd1e600b062fb00de5dc42baa355f ] The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC (or x2APIC). X2APIC mode is mostly compatible with legacy APIC, but it disables the memory-mapped APIC interface in favor of one that uses MSRs. The APIC mode is controlled by the EXT bit in the APIC MSR. The MMIO/xAPIC interface has some problems, most notably the APIC LEAK [1]. This bug allows an attacker to use the APIC MMIO interface to extract data from the SGX enclave. Introduce support for a new feature that will allow the BIOS to lock the APIC in x2APIC mode. If the APIC is locked in x2APIC mode and the kernel tries to disable the APIC or revert to legacy APIC mode a GP fault will occur. Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by preventing the kernel from trying to disable the x2APIC. On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. If legacy APIC is required, then it SGX and TDX need to be disabled in the BIOS. [1]: https://aepicleak.com/aepicleak.pdf Signed-off-by: Daniel Sneddon Signed-off-by: Dave Hansen Acked-by: Dave Hansen Tested-by: Neelima Krishnan Link: https://lkml.kernel.org/r/20220816231943.1152579-1-daniel.sneddon@linux.intel.com Signed-off-by: Sasha Levin commit 650fa7d1af15d06d4b29759fd09a332fe819bc10 Author: Mika Westerberg Date: Tue Aug 30 18:32:48 2022 +0300 thunderbolt: Add back Intel Falcon Ridge end-to-end flow control workaround [ Upstream commit 54669e2f17cb5a4c41ade89427f074dc22cecb17 ] As we are now enabling full end-to-end flow control to the Thunderbolt networking driver, in order for it to work properly on second generation Thunderbolt hardware (Falcon Ridge), we need to add back the workaround that was removed with commit 53f13319d131 ("thunderbolt: Get rid of E2E workaround"). However, this time we only apply it for Falcon Ridge controllers as a form of an additional quirk. For non-Falcon Ridge this does nothing. While there fix a typo 'reqister' -> 'register' in the comment. Signed-off-by: Mika Westerberg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0d2649b288b7b9484e3d4380c0d6c4720a17e473 Author: Tetsuo Handa Date: Tue Aug 16 23:46:13 2022 +0900 wifi: ath9k: avoid uninit memory read in ath9k_htc_rx_msg() [ Upstream commit b383e8abed41cc6ff1a3b34de75df9397fa4878c ] syzbot is reporting uninit value at ath9k_htc_rx_msg() [1], for ioctl(USB_RAW_IOCTL_EP_WRITE) can call ath9k_hif_usb_rx_stream() with pkt_len = 0 but ath9k_hif_usb_rx_stream() uses __dev_alloc_skb(pkt_len + 32, GFP_ATOMIC) based on an assumption that pkt_len is valid. As a result, ath9k_hif_usb_rx_stream() allocates skb with uninitialized memory and ath9k_htc_rx_msg() is reading from uninitialized memory. Since bytes accessed by ath9k_htc_rx_msg() is not known until ath9k_htc_rx_msg() is called, it would be difficult to check minimal valid pkt_len at "if (pkt_len > 2 * MAX_RX_BUF_SIZE) {" line in ath9k_hif_usb_rx_stream(). We have two choices. One is to workaround by adding __GFP_ZERO so that ath9k_htc_rx_msg() sees 0 if pkt_len is invalid. The other is to let ath9k_htc_rx_msg() validate pkt_len before accessing. This patch chose the latter. Note that I'm not sure threshold condition is correct, for I can't find details on possible packet length used by this protocol. Link: https://syzkaller.appspot.com/bug?extid=2ca247c2d60c7023de7f [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Acked-by: Toke Høiland-Jørgensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/7acfa1be-4b5c-b2ce-de43-95b0593fb3e5@I-love.SAKURA.ne.jp Signed-off-by: Sasha Levin commit a9c5c9ce7e58a893af66a07917d80fe47b0f3257 Author: Jane Chu Date: Fri Aug 26 17:38:51 2022 -0600 x86/mce: Retrieve poison range from hardware [ Upstream commit f9781bb18ed828e7b83b7bac4a4ad7cd497ee7d7 ] When memory poison consumption machine checks fire, MCE notifier handlers like nfit_handle_mce() record the impacted physical address range which is reported by the hardware in the MCi_MISC MSR. The error information includes data about blast radius, i.e. how many cachelines did the hardware determine are impacted. A recent change 7917f9cdb503 ("acpi/nfit: rely on mce->misc to determine poison granularity") updated nfit_handle_mce() to stop hard coding the blast radius value of 1 cacheline, and instead rely on the blast radius reported in 'struct mce' which can be up to 4K (64 cachelines). It turns out that apei_mce_report_mem_error() had a similar problem in that it hard coded a blast radius of 4K rather than reading the blast radius from the error information. Fix apei_mce_report_mem_error() to convey the proper poison granularity. Signed-off-by: Jane Chu Signed-off-by: Borislav Petkov Reviewed-by: Dan Williams Reviewed-by: Ingo Molnar Link: https://lore.kernel.org/r/7ed50fd8-521e-cade-77b1-738b8bfb8502@oracle.com Link: https://lore.kernel.org/r/20220826233851.1319100-1-jane.chu@oracle.com Signed-off-by: Sasha Levin commit 6762c85aaee4b6ac33a1fe04adfd3e4e62bb619d Author: Eric Dumazet Date: Mon Aug 22 21:15:28 2022 +0000 tcp: annotate data-race around tcp_md5sig_pool_populated [ Upstream commit aacd467c0a576e5e44d2de4205855dc0fe43f6fb ] tcp_md5sig_pool_populated can be read while another thread changes its value. The race has no consequence because allocations are protected with tcp_md5sig_mutex. This patch adds READ_ONCE() and WRITE_ONCE() to document the race and silence KCSAN. Reported-by: Abhishek Shah Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 77939e5bcc50c881cd879221fcab1e34752d947a Author: Mike Pattrick Date: Wed Aug 17 11:06:35 2022 -0400 openvswitch: Fix overreporting of drops in dropwatch [ Upstream commit c21ab2afa2c64896a7f0e3cbc6845ec63dcfad2e ] Currently queue_userspace_packet will call kfree_skb for all frames, whether or not an error occurred. This can result in a single dropped frame being reported as multiple drops in dropwatch. This functions caller may also call kfree_skb in case of an error. This patch will consume the skbs instead and allow caller's to use kfree_skb. Signed-off-by: Mike Pattrick Link: https://bugzilla.redhat.com/show_bug.cgi?id=2109957 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b3fa7d5d5eaa5b65f745fddb928b4bb2df0f2b4b Author: Mike Pattrick Date: Wed Aug 17 11:06:34 2022 -0400 openvswitch: Fix double reporting of drops in dropwatch [ Upstream commit 1100248a5c5ccd57059eb8d02ec077e839a23826 ] Frames sent to userspace can be reported as dropped in ovs_dp_process_packet, however, if they are dropped in the netlink code then netlink_attachskb will report the same frame as dropped. This patch checks for error codes which indicate that the frame has already been freed. Signed-off-by: Mike Pattrick Link: https://bugzilla.redhat.com/show_bug.cgi?id=2109946 Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bc3e22550bbb769019f5d4e9eab0bf4bf3deb0a5 Author: Ravi Gunasekaran Date: Wed Aug 17 15:14:06 2022 +0530 net: ethernet: ti: davinci_mdio: Add workaround for errata i2329 [ Upstream commit d04807b80691c6041ca8e3dcf1870d1bf1082c22 ] On the CPSW and ICSS peripherals, there is a possibility that the MDIO interface returns corrupt data on MDIO reads or writes incorrect data on MDIO writes. There is also a possibility for the MDIO interface to become unavailable until the next peripheral reset. The workaround is to configure the MDIO in manual mode and disable the MDIO state machine and emulate the MDIO protocol by reading and writing appropriate fields in MDIO_MANUAL_IF_REG register of the MDIO controller to manipulate the MDIO clock and data pins. More details about the errata i2329 and the workaround is available in: https://www.ti.com/lit/er/sprz487a/sprz487a.pdf Add implementation to disable MDIO state machine, configure MDIO in manual mode and achieve MDIO read and writes via MDIO Bitbanging Signed-off-by: Ravi Gunasekaran Reported-by: kernel test robot Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 13180cb88a7be5ee389f65f6ab9f78e46f7722b2 Author: Jacob Keller Date: Wed Jul 27 16:15:57 2022 -0700 ice: set tx_tstamps when creating new Tx rings via ethtool [ Upstream commit b3b173745c8cab1e24d6821488b60abed3acb24d ] When the user changes the number of queues via ethtool, the driver allocates new rings. This allocation did not initialize tx_tstamps. This results in the tx_tstamps field being zero (due to kcalloc allocation), and would result in a NULL pointer dereference when attempting a transmit timestamp on the new ring. Signed-off-by: Jacob Keller Tested-by: Gurucharan (A Contingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 8735e5c122b6176e3017c35a24a24fcc5284d160 Author: Quentin Monnet Date: Mon Aug 15 17:22:05 2022 +0100 bpftool: Clear errno after libcap's checks [ Upstream commit cea558855c39b7f1f02ff50dcf701ca6596bc964 ] When bpftool is linked against libcap, the library runs a "constructor" function to compute the number of capabilities of the running kernel [0], at the beginning of the execution of the program. As part of this, it performs multiple calls to prctl(). Some of these may fail, and set errno to a non-zero value: # strace -e prctl ./bpftool version prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument) ** fprintf added at the top of main(): we have errno == 1 ./bpftool v7.0.0 using libbpf v1.0 features: libbfd, libbpf_strict, skeletons +++ exited with 0 +++ This has been addressed in libcap 2.63 [1], but until this version is available everywhere, we can fix it on bpftool side. Let's clean errno at the beginning of the main() function, to make sure that these checks do not interfere with the batch mode, where we error out if errno is set after a bpftool command. [0] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/cap_alloc.c?h=libcap-2.65#n20 [1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0 Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220815162205.45043-1-quentin@isovalent.com Signed-off-by: Sasha Levin commit 4d4dcfa6b4e85a878401f4fbae4cafc88cdcceb4 Author: Wright Feng Date: Fri Jul 22 13:56:28 2022 +0200 wifi: brcmfmac: fix invalid address access when enabling SCAN log level [ Upstream commit aa666b68e73fc06d83c070d96180b9010cf5a960 ] The variable i is changed when setting random MAC address and causes invalid address access when printing the value of pi->reqs[i]->reqid. We replace reqs index with ri to fix the issue. [ 136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000 [ 136.737365] Mem abort info: [ 136.740172] ESR = 0x96000004 [ 136.743359] Exception class = DABT (current EL), IL = 32 bits [ 136.749294] SET = 0, FnV = 0 [ 136.752481] EA = 0, S1PTW = 0 [ 136.755635] Data abort info: [ 136.758514] ISV = 0, ISS = 0x00000004 [ 136.762487] CM = 0, WnR = 0 [ 136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577 [ 136.772265] [0000000000000000] pgd=0000000000000000 [ 136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O) [ 136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb) [ 136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G O 4.19.42-00001-g531a5f5 #1 [ 136.805532] Hardware name: Freescale i.MX8MQ EVK (DT) [ 136.810584] pstate: 60400005 (nZCv daif +PAN -UAO) [ 136.815429] pc : brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac] [ 136.821811] lr : brcmf_pno_config_sched_scans+0x67c/0xa80 [brcmfmac] [ 136.828162] sp : ffff00000e9a3880 [ 136.831475] x29: ffff00000e9a3890 x28: ffff800020543400 [ 136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0 [ 136.842098] x25: ffff80002054345c x24: ffff800088d22400 [ 136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8 [ 136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400 [ 136.858032] x19: ffff00000e9a3946 x18: 0000000000000000 [ 136.863343] x17: 0000000000000000 x16: 0000000000000000 [ 136.868655] x15: ffff0000093f3b37 x14: 0000000000000050 [ 136.873966] x13: 0000000000003135 x12: 0000000000000000 [ 136.879277] x11: 0000000000000000 x10: ffff000009a61888 [ 136.884589] x9 : 000000000000000f x8 : 0000000000000008 [ 136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d [ 136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942 [ 136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8 [ 136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000 [ 136.911146] Call trace: [ 136.913623] brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac] [ 136.919658] brcmf_pno_start_sched_scan+0xa4/0x118 [brcmfmac] [ 136.925430] brcmf_cfg80211_sched_scan_start+0x80/0xe0 [brcmfmac] [ 136.931636] nl80211_start_sched_scan+0x140/0x308 [cfg80211] [ 136.937298] genl_rcv_msg+0x358/0x3f4 [ 136.940960] netlink_rcv_skb+0xb4/0x118 [ 136.944795] genl_rcv+0x34/0x48 [ 136.947935] netlink_unicast+0x264/0x300 [ 136.951856] netlink_sendmsg+0x2e4/0x33c [ 136.955781] __sys_sendto+0x120/0x19c Signed-off-by: Wright Feng Signed-off-by: Chi-hsien Lin Signed-off-by: Ahmad Fatoum Signed-off-by: Alvin Šipraga Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220722115632.620681-4-alvin@pqrs.dk Signed-off-by: Sasha Levin commit e7863058e529a5b96a97e7ae3cbba0dfb1523ec3 Author: Youghandhar Chintala Date: Mon Aug 1 19:19:41 2022 +0530 wifi: ath10k: Set tx credit to one for WCN3990 snoc based devices [ Upstream commit d81bbb684c250a637186d9286d75b1cb04d2986c ] Currently host can send two WMI commands at once. There is possibility to cause SMMU issues or corruption, if host wants to initiate 2 DMA transfers, it is possible when copy complete interrupt for first DMA reaches host, CE has already updated SRRI (Source ring read index) for both DMA transfers and is in the middle of 2nd DMA. Host uses SRRI (Source ring read index) to interpret how many DMA’s have been completed and tries to unmap/free both the DMA entries. Hence now it is limiting to one.Because CE is still in the middle of 2nd DMA which can cause these issues when handling two DMA transfers. This change will not impact other targets, as it is only for WCN3990. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1 Signed-off-by: Youghandhar Chintala Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220801134941.15216-1-quic_youghand@quicinc.com Signed-off-by: Sasha Levin commit 6ea71246b7a02af675d733e72d14bd0d591d5f4a Author: Dai Ngo Date: Mon Sep 26 10:59:16 2022 -0700 NFSD: fix use-after-free on source server when doing inter-server copy [ Upstream commit 019805fea91599b22dfa62ffb29c022f35abeb06 ] Use-after-free occurred when the laundromat tried to free expired cpntf_state entry on the s2s_cp_stateids list after inter-server copy completed. The sc_cp_list that the expired copy state was inserted on was already freed. When COPY completes, the Linux client normally sends LOCKU(lock_state x), FREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server. The nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state from the s2s_cp_stateids list before freeing the lock state's stid. However, sometimes the CLOSE was sent before the FREE_STATEID request. When this happens, the nfsd4_close_open_stateid call from nfsd4_close frees all lock states on its st_locks list without cleaning up the copy state on the sc_cp_list list. When the time the FREE_STATEID arrives the server returns BAD_STATEID since the lock state was freed. This causes the use-after-free error to occur when the laundromat tries to free the expired cpntf_state. This patch adds a call to nfs4_free_cpntf_statelist in nfsd4_close_open_stateid to clean up the copy state before calling free_ol_stateid_reaplist to free the lock state's stid on the reaplist. Signed-off-by: Dai Ngo Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 14bde62cef7c2a0fa1cb27f415e88b8ee0a232ad Author: Anna Schumaker Date: Tue Sep 13 14:01:50 2022 -0400 NFSD: Return nfserr_serverfault if splice_ok but buf->pages have data [ Upstream commit 06981d560606ac48d61e5f4fff6738b925c93173 ] This was discussed with Chuck as part of this patch set. Returning nfserr_resource was decided to not be the best error message here, and he suggested changing to nfserr_serverfault instead. Signed-off-by: Anna Schumaker Link: https://lore.kernel.org/linux-nfs/20220907195259.926736-1-anna@kernel.org/T/#t Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 7b593b50f20c949316581a03cd77f85974f6d652 Author: Kees Cook Date: Mon Sep 19 19:45:14 2022 -0700 x86/entry: Work around Clang __bdos() bug [ Upstream commit 3e1730842f142add55dc658929221521a9ea62b6 ] Clang produces a false positive when building with CONFIG_FORTIFY_SOURCE=y and CONFIG_UBSAN_BOUNDS=y when operating on an array with a dynamic offset. Work around this by using a direct assignment of an empty instance. Avoids this warning: ../include/linux/fortify-string.h:309:4: warning: call to __write_overflow_field declared with 'warn ing' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wat tribute-warning] __write_overflow_field(p_size_field, size); ^ which was isolated to the memset() call in xen_load_idt(). Note that this looks very much like another bug that was worked around: https://github.com/ClangBuiltLinux/linux/issues/1592 Cc: Juergen Gross Cc: Boris Ostrovsky Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: xen-devel@lists.xenproject.org Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/lkml/41527d69-e8ab-3f86-ff37-6b298c01d5bc@oracle.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit d12ad2bb3feb2954d0b5388c6ffea62e8b01897a Author: Mario Limonciello Date: Thu Sep 15 13:23:14 2022 -0500 ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable [ Upstream commit 018d6711c26e4bd26e20a819fcc7f8ab902608f3 ] Dell Inspiron 14 2-in-1 has two ACPI nodes under GPP1 both with _ADR of 0, both without _HID. It's ambiguous which the kernel should take, but it seems to take "DEV0". Unfortunately "DEV0" is missing the device property `StorageD3Enable` which is present on "NVME". To avoid this causing problems for suspend, add a quirk for this system to behave like `StorageD3Enable` property was found. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216440 Reported-and-tested-by: Luya Tshimbalanga Signed-off-by: Mario Limonciello Reviewed-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit aff390ceb39990069a4ed30c12736bd03f179591 Author: Kees Cook Date: Wed Sep 7 15:41:03 2022 -0700 ARM: decompressor: Include .data.rel.ro.local [ Upstream commit 1b64daf413acd86c2c13f5443f6b4ef3690c8061 ] The .data.rel.ro.local section has the same semantics as .data.rel.ro here, so include it in the .rodata section of the decompressor. Additionally since the .printk_index section isn't usable outside of the core kernel, discard it in the decompressor. Avoids these warnings: arm-linux-gnueabi-ld: warning: orphan section `.data.rel.ro.local' from `arch/arm/boot/compressed/fdt_rw.o' being placed in section `.data.rel.ro.local' arm-linux-gnueabi-ld: warning: orphan section `.printk_index' from `arch/arm/boot/compressed/fdt_rw.o' being placed in section `.printk_index' Reported-by: kernel test robot Link: https://lore.kernel.org/linux-mm/202209080545.qMIVj7YM-lkp@intel.com Cc: Russell King Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 6e2a347b304224b2aeb1c0ea000d1cf8a02cc592 Author: Srinivas Pandruvada Date: Tue Sep 20 04:06:57 2022 -0700 thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crash [ Upstream commit 68b99e94a4a2db6ba9b31fe0485e057b9354a640 ] When CPU 0 is offline and intel_powerclamp is used to inject idle, it generates kernel BUG: BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687 caller is debug_smp_processor_id+0x17/0x20 CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57 Call Trace: dump_stack_lvl+0x49/0x63 dump_stack+0x10/0x16 check_preemption_disabled+0xdd/0xe0 debug_smp_processor_id+0x17/0x20 powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp] ... ... Here CPU 0 is the control CPU by default and changed to the current CPU, if CPU 0 offlined. This check has to be performed under cpus_read_lock(), hence the above warning. Use get_cpu() instead of smp_processor_id() to avoid this BUG. Suggested-by: Chen Yu Signed-off-by: Srinivas Pandruvada [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6216b685b8f48ab7b721a6fd5acbf526b41c13e8 Author: Chao Qin Date: Tue Sep 20 14:08:26 2022 +0800 powercap: intel_rapl: fix UBSAN shift-out-of-bounds issue [ Upstream commit 2d93540014387d1c73b9ccc4d7895320df66d01b ] When value < time_unit, the parameter of ilog2() will be zero and the return value is -1. u64(-1) is too large for shift exponent and then will trigger shift-out-of-bounds: shift exponent 18446744073709551615 is too large for 32-bit type 'int' Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us Signed-off-by: Chao Qin Acked-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit dced4eaa9143aa5c73b3ccea2b78d2788eb5f34a Author: Kees Cook Date: Wed Sep 7 16:05:56 2022 -0700 MIPS: BCM47XX: Cast memcmp() of function to (void *) [ Upstream commit 0dedcf6e3301836eb70cfa649052e7ce4fcd13ba ] Clang is especially sensitive about argument type matching when using __overloaded functions (like memcmp(), etc). Help it see that function pointers are just "void *". Avoids this error: arch/mips/bcm47xx/prom.c:89:8: error: no matching function for call to 'memcmp' if (!memcmp(prom_init, prom_init + mem, 32)) ^~~~~~ include/linux/string.h:156:12: note: candidate function not viable: no known conversion from 'void (void)' to 'const void *' for 1st argument extern int memcmp(const void *,const void *,__kernel_size_t); Cc: Hauke Mehrtens Cc: "Rafał Miłecki" Cc: Thomas Bogendoerfer Cc: linux-mips@vger.kernel.org Cc: Nathan Chancellor Cc: Nick Desaulniers Cc: llvm@lists.linux.dev Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/202209080652.sz2d68e5-lkp@intel.com Signed-off-by: Kees Cook Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 25b364cb9b72a66d4dc9a382d7d6f9e0d0059f3e Author: Doug Smythies Date: Tue Sep 6 13:28:57 2022 -0700 cpufreq: intel_pstate: Add Tigerlake support in no-HWP mode [ Upstream commit 71bb5c82aaaea007167f3ba68d3a669c74d7d55d ] Users may disable HWP in firmware, in which case intel_pstate wouldn't load unless the CPU model is explicitly supported. Add TIGERLAKE to the list of CPUs that can register intel_pstate while not advertising the HWP capability. Without this change, an TIGERLAKE in no-HWP mode could only use the acpi_cpufreq frequency scaling driver. See also commits: d8de7a44e11f: cpufreq: intel_pstate: Add Skylake servers support fbdc21e9b038: cpufreq: intel_pstate: Add Icelake servers support in no-HWP mode 706c5328851d: cpufreq: intel_pstate: Add Cometlake support in no-HWP mode Reported by: M. Cargi Ari Signed-off-by: Doug Smythies Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 90bfc9ae875dfbed2e6089516520204cd431dba3 Author: Hans de Goede Date: Mon Sep 5 14:34:12 2022 +0200 ACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address [ Upstream commit 211391bf04b3c74e250c566eeff9cf808156c693 ] On a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table which contains invalid physical addresses, with high bits set which fall outside the range of the CPU-s supported physical address range. Calling acpi_os_map_memory() on such an invalid phys address leads to the below WARN_ON in ioremap triggering resulting in an oops/stacktrace. Add code to verify the physical address before calling acpi_os_map_memory() to fix / avoid the oops. [ 1.226900] ioremap: invalid physical address 3001000000000000 [ 1.226949] ------------[ cut here ]------------ [ 1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f [ 1.226996] Modules linked in: [ 1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490 [ 1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f [ 1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00 [ 1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286 [ 1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000 [ 1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff [ 1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18 [ 1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008 [ 1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000 [ 1.227135] FS: 0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000 [ 1.227146] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0 [ 1.227167] Call Trace: [ 1.227176] [ 1.227185] ? acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227215] ? kmem_cache_alloc_trace+0x187/0x370 [ 1.227254] acpi_os_map_iomem+0x1c9/0x1e0 [ 1.227288] acpi_init_fpdt+0xa8/0x253 [ 1.227308] ? acpi_debugfs_init+0x1f/0x1f [ 1.227339] do_one_initcall+0x5a/0x300 [ 1.227406] ? rcu_read_lock_sched_held+0x3f/0x80 [ 1.227442] kernel_init_freeable+0x28b/0x2cc [ 1.227512] ? rest_init+0x170/0x170 [ 1.227538] kernel_init+0x16/0x140 [ 1.227552] ret_from_fork+0x1f/0x30 [ 1.227639] [ 1.227647] irq event stamp: 186819 [ 1.227656] hardirqs last enabled at (186825): [] __up_console_sem+0x5e/0x70 [ 1.227672] hardirqs last disabled at (186830): [] __up_console_sem+0x43/0x70 [ 1.227686] softirqs last enabled at (186576): [] __irq_exit_rcu+0xed/0x160 [ 1.227701] softirqs last disabled at (186569): [] __irq_exit_rcu+0xed/0x160 [ 1.227715] ---[ end trace 0000000000000000 ]--- Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ed42391164e6839a48aaf4c53eefda516835e799 Author: Kees Cook Date: Fri Sep 2 13:02:26 2022 -0700 fortify: Fix __compiletime_strlen() under UBSAN_BOUNDS_LOCAL [ Upstream commit d07c0acb4f41cc42a0d97530946965b3e4fa68c1 ] With CONFIG_FORTIFY=y and CONFIG_UBSAN_LOCAL_BOUNDS=y enabled, we observe a runtime panic while running Android's Compatibility Test Suite's (CTS) android.hardware.input.cts.tests. This is stemming from a strlen() call in hidinput_allocate(). __compiletime_strlen() is implemented in terms of __builtin_object_size(), then does an array access to check for NUL-termination. A quirk of __builtin_object_size() is that for strings whose values are runtime dependent, __builtin_object_size(str, 1 or 0) returns the maximum size of possible values when those sizes are determinable at compile time. Example: static const char *v = "FOO BAR"; static const char *y = "FOO BA"; unsigned long x (int z) { // Returns 8, which is: // max(__builtin_object_size(v, 1), __builtin_object_size(y, 1)) return __builtin_object_size(z ? v : y, 1); } So when FORTIFY_SOURCE is enabled, the current implementation of __compiletime_strlen() will try to access beyond the end of y at runtime using the size of v. Mixed with UBSAN_LOCAL_BOUNDS we get a fault. hidinput_allocate() has a local C string whose value is control flow dependent on a switch statement, so __builtin_object_size(str, 1) evaluates to the maximum string length, making all other cases fault on the last character check. hidinput_allocate() could be cleaned up to avoid runtime calls to strlen() since the local variable can only have literal values, so there's no benefit to trying to fortify the strlen call site there. Perform a __builtin_constant_p() check against index 0 earlier in the macro to filter out the control-flow-dependant case. Add a KUnit test for checking the expected behavioral characteristics of FORTIFY_SOURCE internals. Cc: Nathan Chancellor Cc: Tom Rix Cc: Andrew Morton Cc: Vlastimil Babka Cc: "Steven Rostedt (Google)" Cc: David Gow Cc: Yury Norov Cc: Masami Hiramatsu Cc: Sander Vanheule Cc: linux-hardening@vger.kernel.org Cc: llvm@lists.linux.dev Reviewed-by: Nick Desaulniers Tested-by: Android Treehugger Robot Link: https://android-review.googlesource.com/c/kernel/common/+/2206839 Co-developed-by: Nick Desaulniers Signed-off-by: Nick Desaulniers Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit bf873a25c55278ea4b7acae3f11111d8a30e5c84 Author: Arvid Norlander Date: Wed Aug 24 20:49:50 2022 +0200 ACPI: video: Add Toshiba Satellite/Portege Z830 quirk [ Upstream commit 574160b8548deff8b80b174f03201e94ab8431e2 ] Toshiba Satellite Z830 needs the quirk video_disable_backlight_sysfs_if for proper backlight control after suspend/resume cycles. Toshiba Portege Z830 is simply the same laptop rebranded for certain markets (I looked through the manual to other language sections to confirm this) and thus also needs this quirk. Thanks to Hans de Goede for suggesting this fix. Link: https://www.spinics.net/lists/platform-driver-x86/msg34394.html Suggested-by: Hans de Goede Signed-off-by: Arvid Norlander Reviewed-by: Hans de Goede Tested-by: Arvid Norlander Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8ce338db7440a1b7f2d48d1a78df2548ebd4a935 Author: Perry Yuan Date: Mon Aug 15 00:35:45 2022 +0800 cpufreq: amd_pstate: fix wrong lowest perf fetch [ Upstream commit b185c5053c65b7704ead4537e4d4d9b33dc398dc ] Fix the wrong lowest perf value reading which is used for new des_perf calculation by governor requested, the incorrect min_perf will get incorrect des_perf to be set , that will cause the system frequency changing unexpectedly. Reviewed-by: Huang Rui Acked-by: Viresh Kumar Signed-off-by: Perry Yuan Signed-off-by: Su Jinzhou Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit aaa63801145ac184f051a0ab6927b887274d3bf4 Author: Michal Hocko Date: Wed Jun 22 13:47:11 2022 +0200 rcu: Back off upon fill_page_cache_func() allocation failure [ Upstream commit 093590c16b447f53e66771c8579ae66c96f6ef61 ] The fill_page_cache_func() function allocates couple of pages to store kvfree_rcu_bulk_data structures. This is a lightweight (GFP_NORETRY) allocation which can fail under memory pressure. The function will, however keep retrying even when the previous attempt has failed. This retrying is in theory correct, but in practice the allocation is invoked from workqueue context, which means that if the memory reclaim gets stuck, these retries can hog the worker for quite some time. Although the workqueues subsystem automatically adjusts concurrency, such adjustment is not guaranteed to happen until the worker context sleeps. And the fill_page_cache_func() function's retry loop is not guaranteed to sleep (see the should_reclaim_retry() function). And we have seen this function cause workqueue lockups: kernel: BUG: workqueue lockup - pool cpus=93 node=1 flags=0x1 nice=0 stuck for 32s! [...] kernel: pool 74: cpus=37 node=0 flags=0x1 nice=0 hung=32s workers=2 manager: 2146 kernel: pwq 498: cpus=249 node=1 flags=0x1 nice=0 active=4/256 refcnt=5 kernel: in-flight: 1917:fill_page_cache_func kernel: pending: dbs_work_handler, free_work, kfree_rcu_monitor Originally, we thought that the root cause of this lockup was several retries with direct reclaim, but this is not yet confirmed. Furthermore, we have seen similar lockups without any heavy memory pressure. This suggests that there are other factors contributing to these lockups. However, it is not really clear that endless retries are desireable. So let's make the fill_page_cache_func() function back off after allocation failure. Cc: Uladzislau Rezki (Sony) Cc: "Paul E. McKenney" Cc: Frederic Weisbecker Cc: Neeraj Upadhyay Cc: Josh Triplett Cc: Steven Rostedt Cc: Mathieu Desnoyers Cc: Lai Jiangshan Cc: Joel Fernandes Signed-off-by: Michal Hocko Reviewed-by: Uladzislau Rezki (Sony) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit eaa91f54df78bcbafd112ef1babbdf417ff54104 Author: Zqiang Date: Mon Aug 8 10:26:26 2022 +0800 rcu: Avoid triggering strict-GP irq-work when RCU is idle [ Upstream commit 621189a1fe93cb2b34d62c5cdb9e258bca044813 ] Kernels built with PREEMPT_RCU=y and RCU_STRICT_GRACE_PERIOD=y trigger irq-work from rcu_read_unlock(), and the resulting irq-work handler invokes rcu_preempt_deferred_qs_handle(). The point of this triggering is to force grace periods to end quickly in order to give tools like KASAN a better chance of detecting RCU usage bugs such as leaking RCU-protected pointers out of an RCU read-side critical section. However, this irq-work triggering is unconditional. This works, but there is no point in doing this irq-work unless the current grace period is waiting on the running CPU or task, which is not the common case. After all, in the common case there are many rcu_read_unlock() calls per CPU per grace period. This commit therefore triggers the irq-work only when the current grace period is waiting on the running CPU or task. This change was tested as follows on a four-CPU system: echo rcu_preempt_deferred_qs_handler > /sys/kernel/debug/tracing/set_ftrace_filter echo 1 > /sys/kernel/debug/tracing/function_profile_enabled insmod rcutorture.ko sleep 20 rmmod rcutorture.ko echo 0 > /sys/kernel/debug/tracing/function_profile_enabled echo > /sys/kernel/debug/tracing/set_ftrace_filter This procedure produces results in this per-CPU set of files: /sys/kernel/debug/tracing/trace_stat/function* Sample output from one of these files is as follows: Function Hit Time Avg s^2 -------- --- ---- --- --- rcu_preempt_deferred_qs_handle 838746 182650.3 us 0.217 us 0.004 us The baseline sum of the "Hit" values (the number of calls to this function) was 3,319,015. With this commit, that sum was 1,140,359, for a 2.9x reduction. The worst-case variance across the CPUs was less than 25%, so this large effect size is statistically significant. The raw data is available in the Link: URL. Link: https://lore.kernel.org/all/20220808022626.12825-1-qiang1.zhang@intel.com/ Signed-off-by: Zqiang Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit eb97e60a9eae632ff9104a580dbc4fdc58dc23cb Author: Alexander Aring Date: Mon Aug 15 15:43:13 2022 -0400 fs: dlm: fix race in lowcomms [ Upstream commit 30ea3257e8766027c4d8d609dcbd256ff9a76073 ] This patch fixes a race between queue_work() in _dlm_lowcomms_commit_msg() and srcu_read_unlock(). The queue_work() can take the final reference of a dlm_msg and so msg->idx can contain garbage which is signaled by the following warning: [ 676.237050] ------------[ cut here ]------------ [ 676.237052] WARNING: CPU: 0 PID: 1060 at include/linux/srcu.h:189 dlm_lowcomms_commit_msg+0x41/0x50 [ 676.238945] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common iTCO_wdt iTCO_vendor_support qxl kvm_intel drm_ttm_helper vmw_vsock_virtio_transport kvm vmw_vsock_virtio_transport_common ttm irqbypass crc32_pclmul joydev crc32c_intel serio_raw drm_kms_helper vsock virtio_scsi virtio_console virtio_balloon snd_pcm drm syscopyarea sysfillrect sysimgblt snd_timer fb_sys_fops i2c_i801 lpc_ich snd i2c_smbus soundcore pcspkr [ 676.244227] CPU: 0 PID: 1060 Comm: lock_torture_wr Not tainted 5.19.0-rc3+ #1546 [ 676.245216] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 676.246460] RIP: 0010:dlm_lowcomms_commit_msg+0x41/0x50 [ 676.247132] Code: fe ff ff ff 75 24 48 c7 c6 bd 0f 49 bb 48 c7 c7 38 7c 01 bd e8 00 e7 ca ff 89 de 48 c7 c7 60 78 01 bd e8 42 3d cd ff 5b 5d c3 <0f> 0b eb d8 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 [ 676.249253] RSP: 0018:ffffa401c18ffc68 EFLAGS: 00010282 [ 676.249855] RAX: 0000000000000001 RBX: 00000000ffff8b76 RCX: 0000000000000006 [ 676.250713] RDX: 0000000000000000 RSI: ffffffffbccf3a10 RDI: ffffffffbcc7b62e [ 676.251610] RBP: ffffa401c18ffc70 R08: 0000000000000001 R09: 0000000000000001 [ 676.252481] R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000005 [ 676.253421] R13: ffff8b76786ec370 R14: ffff8b76786ec370 R15: ffff8b76786ec480 [ 676.254257] FS: 0000000000000000(0000) GS:ffff8b7777800000(0000) knlGS:0000000000000000 [ 676.255239] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 676.255897] CR2: 00005590205d88b8 CR3: 000000017656c003 CR4: 0000000000770ee0 [ 676.256734] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 676.257567] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 676.258397] PKRU: 55555554 [ 676.258729] Call Trace: [ 676.259063] [ 676.259354] dlm_midcomms_commit_mhandle+0xcc/0x110 [ 676.259964] queue_bast+0x8b/0xb0 [ 676.260423] grant_pending_locks+0x166/0x1b0 [ 676.261007] _unlock_lock+0x75/0x90 [ 676.261469] unlock_lock.isra.57+0x62/0xa0 [ 676.262009] dlm_unlock+0x21e/0x330 [ 676.262457] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 676.263183] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 676.263815] ? preempt_count_sub+0xba/0x100 [ 676.264361] ? complete+0x1d/0x60 [ 676.264777] lock_torture_writer+0xb8/0x150 [dlm_locktorture] [ 676.265555] kthread+0x10a/0x130 [ 676.266007] ? kthread_complete_and_exit+0x20/0x20 [ 676.266616] ret_from_fork+0x22/0x30 [ 676.267097] [ 676.267381] irq event stamp: 9579855 [ 676.267824] hardirqs last enabled at (9579863): [] __up_console_sem+0x58/0x60 [ 676.268896] hardirqs last disabled at (9579872): [] __up_console_sem+0x3d/0x60 [ 676.270008] softirqs last enabled at (9579798): [] __do_softirq+0x349/0x4c7 [ 676.271438] softirqs last disabled at (9579897): [] irq_exit_rcu+0xb0/0xf0 [ 676.272796] ---[ end trace 0000000000000000 ]--- I reproduced this warning with dlm_locktorture test which is currently not upstream. However this patch fix the issue by make a additional refcount between dlm_lowcomms_new_msg() and dlm_lowcomms_commit_msg(). In case of the race the kref_put() in dlm_lowcomms_commit_msg() will be the final put. Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit d1bfec0f742c379e7318c9a3fb2f3d313256c0ba Author: Aaron Tomlin Date: Fri Oct 7 14:38:12 2022 +0100 module: tracking: Keep a record of tainted unloaded modules only [ Upstream commit 47cc75aa92837a9d3f15157d6272ff285585d75d ] This ensures that no module record/or entry is added to the unloaded_tainted_modules list if it does not carry a taint. Reported-by: Alexey Dobriyan Fixes: 99bd9956551b ("module: Introduce module unload taint tracking") Signed-off-by: Aaron Tomlin Acked-by: Luis Chamberlain Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit b9ffdfc1bedbc83747be3e55e2de3119928b3a16 Author: Stefan Berger Date: Tue Sep 20 09:15:18 2022 -0400 selftest: tpm2: Add Client.__del__() to close /dev/tpm* handle [ Upstream commit 2d869f0b458547386fbcd8cf3004b271b7347b7f ] The following output can bee seen when the test is executed: test_flush_context (tpm2_tests.SpaceTest) ... \ /usr/lib64/python3.6/unittest/case.py:605: ResourceWarning: \ unclosed file <_io.FileIO name='/dev/tpmrm0' mode='rb+' closefd=True> An instance of Client does not implicitly close /dev/tpm* handle, once it gets destroyed. Close the file handle in the class destructor Client.__del__(). Fixes: 6ea3dfe1e0732 ("selftests: add TPM 2.0 tests") Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org Cc: Jarkko Sakkinen Signed-off-by: Stefan Berger Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 0c3d50b49337e77485941bf16a1455f2deeb48a8 Author: Chao Yu Date: Wed Sep 14 21:28:46 2022 +0800 f2fs: fix to account FS_CP_DATA_IO correctly [ Upstream commit d80afefb17e01aa0c46a8eebc01882e0ebd8b0f6 ] f2fs_inode_info.cp_task was introduced for FS_CP_DATA_IO accounting since commit b0af6d491a6b ("f2fs: add app/fs io stat"). However, cp_task usage coverage has been increased due to below commits: commit 040d2bb318d1 ("f2fs: fix to avoid deadloop if data_flush is on") commit 186857c5a14a ("f2fs: fix potential recursive call when enabling data_flush") So that, if data_flush mountoption is on, when data flush was triggered from background, the IO from data flush will be accounted as checkpoint IO type incorrectly. In order to fix this issue, this patch splits cp_task into two: a) cp_task: used for IO accounting b) wb_task: used to avoid deadlock Fixes: 040d2bb318d1 ("f2fs: fix to avoid deadloop if data_flush is on") Fixes: 186857c5a14a ("f2fs: fix potential recursive call when enabling data_flush") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1f4d5d31ddfffbbdb24d8b34b012b528e241a1ea Author: Zhang Qilong Date: Mon Sep 5 12:59:17 2022 +0800 f2fs: fix race condition on setting FI_NO_EXTENT flag [ Upstream commit 07725adc55c0a414c10acb5c8c86cea34b95ddef ] The following scenarios exist. process A: process B: ->f2fs_drop_extent_tree ->f2fs_update_extent_cache_range ->f2fs_update_extent_tree_range ->write_lock ->set_inode_flag ->is_inode_flag_set ->__free_extent_tree // Shouldn't // have been // cleaned up // here ->write_lock In this case, the "FI_NO_EXTENT" flag is set between f2fs_update_extent_tree_range and is_inode_flag_set by other process. it leads to clearing the whole exten tree which should not have happened. And we fix it by move the setting it to the range of write_lock. Fixes:5f281fab9b9a3 ("f2fs: disable extent_cache for fcollapse/finsert inodes") Signed-off-by: Zhang Qilong Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a3e69948da570167a147ac53404d0801ddcc6564 Author: Shuai Xue Date: Sat Sep 24 15:49:53 2022 +0800 ACPI: APEI: do not add task_work to kernel thread to avoid memory leak [ Upstream commit 415fed694fe11395df56e05022d6e7cee1d39dd3 ] If an error is detected as a result of user-space process accessing a corrupt memory location, the CPU may take an abort. Then the platform firmware reports kernel via NMI like notifications, e.g. NOTIFY_SEA, NOTIFY_SOFTWARE_DELEGATED, etc. For NMI like notifications, commit 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors") keep track of whether memory_failure() work was queued, and make task_work pending to flush out the queue so that the work is processed before return to user-space. The code use init_mm to check whether the error occurs in user space: if (current->mm != &init_mm) The condition is always true, becase _nobody_ ever has "init_mm" as a real VM any more. In addition to abort, errors can also be signaled as asynchronous exceptions, such as interrupt and SError. In such case, the interrupted current process could be any kind of thread. When a kernel thread is interrupted, the work ghes_kick_task_work deferred to task_work will never be processed because entry_handler returns to call ret_to_kernel() instead of ret_to_user(). Consequently, the estatus_node alloced from ghes_estatus_pool in ghes_in_nmi_queue_one_entry() will not be freed. After around 200 allocations in our platform, the ghes_estatus_pool will run of memory and ghes_in_nmi_queue_one_entry() returns ENOMEM. As a result, the event failed to be processed. sdei: event 805 on CPU 113 failed with error: -2 Finally, a lot of unhandled events may cause platform firmware to exceed some threshold and reboot. The condition should generally just do if (current->mm) as described in active_mm.rst documentation. Then if an asynchronous error is detected when a kernel thread is running, (e.g. when detected by a background scrubber), do not add task_work to it as the original patch intends to do. Fixes: 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors") Signed-off-by: Shuai Xue Reviewed-by: Tony Luck Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 57bf2897692b12cc89551cc5d656d240a1def18e Author: Vincent Knecht Date: Thu Aug 11 12:50:14 2022 +0200 thermal/drivers/qcom/tsens-v0_1: Fix MSM8939 fourth sensor hw_id [ Upstream commit b0c883e900702f408d62cf92b0ef01303ed69be9 ] Reading temperature from this sensor fails with 'Invalid argument'. Looking at old vendor dts [1], its hw_id should be 3 instead of 4. Change this hw_id accordingly. [1] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/master/arch/arm/boot/dts/qcom/msm8939-common.dtsi#L511 Fixes: 332bc8ebab2c ("thermal: qcom: tsens-v0_1: Add support for MSM8939") Signed-off-by: Vincent Knecht Reviewed-by: Dmitry Baryshkov Reviewed-by: Bjorn Andersson Reviewed-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20220811105014.7194-1-vincent.knecht@mailoo.org Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit ccc9abee86c5cf7e0a1805ec3fbab6c4566a2413 Author: Jason A. Donenfeld Date: Sat Oct 1 00:31:00 2022 +0200 random: schedule jitter credit for next jiffy, not in two jiffies [ Upstream commit 122733471384be8c23f019fbbd46bdf7be561dcd ] Counterintuitively, mod_timer(..., jiffies + 1) will cause the timer to fire not in the next jiffy, but in two jiffies. The way to cause the timer to fire in the next jiffy is with mod_timer(..., jiffies). Doing so then lets us bump the upper bound back up again. Fixes: 50ee7529ec45 ("random: try to actively add entropy rather than passively wait for it") Fixes: 829d680e82a9 ("random: cap jitter samples per bit to factor of HZ") Cc: Dominik Brodowski Cc: Sebastian Andrzej Siewior Cc: Sultan Alsawaf Signed-off-by: Jason A. Donenfeld Signed-off-by: Sasha Levin commit 371fa5129af53a79f6dddc90fe5bb0825cbe72a4 Author: Dan Carpenter Date: Mon Sep 19 09:43:27 2022 +0300 crypto: cavium - prevent integer overflow loading firmware [ Upstream commit 2526d6bf27d15054bb0778b2f7bc6625fd934905 ] The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The "ntohl(ucode->code_length) * 2" multiplication can have an integer overflow. Fixes: 9e2c7d99941d ("crypto: cavium - Add Support for Octeon-tx CPT Engine") Signed-off-by: Dan Carpenter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8f5eee162e55175d9dac98b5e9b8da76449d2257 Author: Dan Carpenter Date: Mon Sep 19 09:43:19 2022 +0300 crypto: marvell/octeontx - prevent integer overflows [ Upstream commit caca37cf6c749ff0303f68418cfe7b757a4e0697 ] The "code_length" value comes from the firmware file. If your firmware is untrusted realistically there is probably very little you can do to protect yourself. Still we try to limit the damage as much as possible. Also Smatch marks any data read from the filesystem as untrusted and prints warnings if it not capped correctly. The "code_length * 2" can overflow. The round_up(ucode_size, 16) + sizeof() expression can overflow too. Prevent these overflows. Fixes: d9110b0b01ff ("crypto: marvell - add support for OCTEON TX CPT engine") Signed-off-by: Dan Carpenter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 9bb18a8bb3118a1a0d93cf1731308b61497dbff8 Author: Janis Schoetterl-Glausch Date: Fri Sep 16 14:41:12 2022 +0200 kbuild: rpm-pkg: fix breakage when V=1 is used [ Upstream commit 2e07005f4813a9ff6e895787e0c2d1fea859b033 ] Doing make V=1 binrpm-pkg results in: Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.EgV6qJ + umask 022 + cd . + /bin/rm -rf /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x + /bin/mkdir -p /home/scgl/rpmbuild/BUILDROOT + /bin/mkdir /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x + mkdir -p /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x/boot + make -f ./Makefile image_name + cp test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo >&2; \ echo >&2 " ERROR: Kernel configuration is invalid."; \ echo >&2 " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo >&2 " Run 'make oldconfig && make prepare' on kernel src to fix it."; \ echo >&2 ; \ /bin/false) arch/s390/boot/bzImage /home/scgl/rpmbuild/BUILDROOT/kernel-6.0.0_rc5+-1.s390x/boot/vmlinuz-6.0.0-rc5+ cp: invalid option -- 'e' Try 'cp --help' for more information. error: Bad exit status from /var/tmp/rpm-tmp.EgV6qJ (%install) Because the make call to get the image name is verbose and prints additional information. Fixes: 993bdde94547 ("kbuild: add image_name to no-sync-config-targets") Signed-off-by: Janis Schoetterl-Glausch Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 6f7b372ec68f9e4edc438b14b91332914d1c433d Author: Masahiro Yamada Date: Fri Sep 16 15:29:53 2022 +0900 linux/export: use inline assembler to populate symbol CRCs [ Upstream commit f3304ecd7f060db1d4197fbdce5a503259f770d3 ] Since commit 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS"), the module versioning on the (non-upstreamed-yet) kvx Linux port is broken due to unexpected padding for __crc_* symbols. The kvx GCC adds padding so u32 gets 8-byte alignment instead of 4. I do not know if this happens for upstream architectures in general, but any compiler has the freedom to insert padding for faster access. Use the inline assembler to directly specify the wanted data layout. This is how we previously did before the breakage. Link: https://lore.kernel.org/lkml/20220817161438.32039-1-ysionneau@kalray.eu/ Link: https://lore.kernel.org/linux-kbuild/31ce5305-a76b-13d7-ea55-afca82c46cf2@kalray.eu/ Fixes: 7b4537199a4a ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS") Reported-by: Yann Sionneau Signed-off-by: Masahiro Yamada Tested-by: Yann Sionneau Signed-off-by: Sasha Levin commit 00b64949b8c2047c09e4b78862a00e9012acd108 Author: Masahiro Yamada Date: Sun Aug 7 09:48:09 2022 +0900 kbuild: remove the target in signal traps when interrupted [ Upstream commit a7f3257da8a86b96fb9bf1bba40ae0bbd7f1885a ] When receiving some signal, GNU Make automatically deletes the target if it has already been changed by the interrupted recipe. If the target is possibly incomplete due to interruption, it must be deleted so that it will be remade from scratch on the next run of make. Otherwise, the target would remain corrupted permanently because its timestamp had already been updated. Thanks to this behavior of Make, you can stop the build any time by pressing Ctrl-C, and just run 'make' to resume it. Kbuild also relies on this feature, but it is equivalently important for any build systems that make decisions based on timestamps (if you want to support Ctrl-C reliably). However, this does not always work as claimed; Make immediately dies with Ctrl-C if its stderr goes into a pipe. [Test Makefile] foo: echo hello > $@ sleep 3 echo world >> $@ [Test Result] $ make # hit Ctrl-C echo hello > foo sleep 3 ^Cmake: *** Deleting file 'foo' make: *** [Makefile:3: foo] Interrupt $ make 2>&1 | cat # hit Ctrl-C echo hello > foo sleep 3 ^C$ # 'foo' is often left-over The reason is because SIGINT is sent to the entire process group. In this example, SIGINT kills 'cat', and 'make' writes the message to the closed pipe, then dies with SIGPIPE before cleaning the target. A typical bad scenario (as reported by [1], [2]) is to save build log by using the 'tee' command: $ make 2>&1 | tee log This can be problematic for any build systems based on Make, so I hope it will be fixed in GNU Make. The maintainer of GNU Make stated this is a long-standing issue and difficult to fix [3]. It has not been fixed yet as of writing. So, we cannot rely on Make cleaning the target. We can do it by ourselves, in signal traps. As far as I understand, Make takes care of SIGHUP, SIGINT, SIGQUIT, and SITERM for the target removal. I added the traps for them, and also for SIGPIPE just in case cmd_* rule prints something to stdout or stderr (but I did not observe an actual case where SIGPIPE was triggered). [Note 1] The trap handler might be worth explaining. rm -f $@; trap - $(sig); kill -s $(sig) $$ This lets the shell kill itself by the signal it caught, so the parent process can tell the child has exited on the signal. Generally, this is a proper manner for handling signals, in case the calling program (like Bash) may monitor WIFSIGNALED() and WTERMSIG() for WCE although this may not be a big deal here because GNU Make handles SIGHUP, SIGINT, SIGQUIT in WUE and SIGTERM in IUE. IUE - Immediate Unconditional Exit WUE - Wait and Unconditional Exit WCE - Wait and Cooperative Exit For details, see "Proper handling of SIGINT/SIGQUIT" [4]. [Note 2] Reverting 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") would directly address [1], but it only saves if_changed_dep. As reported in [2], all commands that use redirection can potentially leave an empty (i.e. broken) target. [Note 3] Another (even safer) approach might be to always write to a temporary file, and rename it to $@ at the end of the recipe. > $(tmp-target) mv $(tmp-target) $@ It would require a lot of Makefile changes, and result in ugly code, so I did not take it. [Note 4] A little more thoughts about a pattern rule with multiple targets (or a grouped target). %.x %.y: %.z When interrupted, GNU Make deletes both %.x and %.y, while this solution only deletes $@. Probably, this is not a big deal. The next run of make will execute the rule again to create $@ along with the other files. [1]: https://lore.kernel.org/all/YLeot94yAaM4xbMY@gmail.com/ [2]: https://lore.kernel.org/all/20220510221333.2770571-1-robh@kernel.org/ [3]: https://lists.gnu.org/archive/html/help-make/2021-06/msg00001.html [4]: https://www.cons.org/cracauer/sigint.html Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd files") Reported-by: Ingo Molnar Reported-by: Rob Herring Signed-off-by: Masahiro Yamada Tested-by: Ingo Molnar Reviewed-by: Nicolas Schier Signed-off-by: Sasha Levin commit fc9a0aa8361433dfd4df216d211ba6f110293ff3 Author: Nico Pache Date: Mon Sep 19 08:49:32 2022 -0600 tracing/osnoise: Fix possible recursive locking in stop_per_cpu_kthreads [ Upstream commit 99ee9317a1305cd5626736785c8cb38b0e47686c ] There is a recursive lock on the cpu_hotplug_lock. In kernel/trace/trace_osnoise.c:_per_cpu_kthreads: - start_per_cpu_kthreads calls cpus_read_lock() and if start_kthreads returns a error it will call stop_per_cpu_kthreads. - stop_per_cpu_kthreads then calls cpus_read_lock() again causing deadlock. Fix this by calling cpus_read_unlock() before calling stop_per_cpu_kthreads. This behavior can also be seen in commit f46b16520a08 ("trace/hwlat: Implement the per-cpu mode"). This error was noticed during the LTP ftrace-stress-test: WARNING: possible recursive locking detected -------------------------------------------- sh/275006 is trying to acquire lock: ffffffffb02f5400 (cpu_hotplug_lock){++++}-{0:0}, at: stop_per_cpu_kthreads but task is already holding lock: ffffffffb02f5400 (cpu_hotplug_lock){++++}-{0:0}, at: start_per_cpu_kthreads other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(cpu_hotplug_lock); lock(cpu_hotplug_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by sh/275006: #0: ffff8881023f0470 (sb_writers#24){.+.+}-{0:0}, at: ksys_write #1: ffffffffb084f430 (trace_types_lock){+.+.}-{3:3}, at: rb_simple_write #2: ffffffffb02f5400 (cpu_hotplug_lock){++++}-{0:0}, at: start_per_cpu_kthreads Link: https://lkml.kernel.org/r/20220919144932.3064014-1-npache@redhat.com Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Signed-off-by: Nico Pache Acked-by: Daniel Bristot de Oliveira Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit f433d954d0325eb025f9dbb2e336d036860b2b6a Author: Yipeng Zou Date: Mon Sep 19 20:56:29 2022 +0800 tracing: kprobe: Make gen test module work in arm and riscv [ Upstream commit d8ef45d66c01425ff748e13ef7dd1da7a91cc93c ] For now, this selftest module can only work in x86 because of the kprobe cmd was fixed use of x86 registers. This patch adapted to register names under arm and riscv, So that this module can be worked on those platform. Link: https://lkml.kernel.org/r/20220919125629.238242-3-zouyipeng@huawei.com Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Fixes: 64836248dda2 ("tracing: Add kprobe event command generation test module") Signed-off-by: Yipeng Zou Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 1e7a061f0c52a4c56491f86ea82ff99e153293b6 Author: Yipeng Zou Date: Mon Sep 19 20:56:28 2022 +0800 tracing: kprobe: Fix kprobe event gen test module on exit [ Upstream commit ac48e189527fae87253ef2bf58892e782fb36874 ] Correct gen_kretprobe_test clr event para on module exit. This will make it can't to delete. Link: https://lkml.kernel.org/r/20220919125629.238242-2-zouyipeng@huawei.com Cc: Cc: Cc: Cc: Cc: Cc: Cc: Cc: Fixes: 64836248dda2 ("tracing: Add kprobe event command generation test module") Signed-off-by: Yipeng Zou Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 544763643a24d79a76beea435049e4419c77f043 Author: Robin Murphy Date: Tue Sep 13 12:47:20 2022 +0100 iommu/iova: Fix module config properly [ Upstream commit 4f58330fcc8482aa90674e1f40f601e82f18ed4a ] IOMMU_IOVA is intended to be an optional library for users to select as and when they desire. Since it can be a module now, this means that built-in code which has chosen not to select it should not fail to link if it happens to have selected as a module by someone else. Replace IS_ENABLED() with IS_REACHABLE() to do the right thing. CC: Thierry Reding Reported-by: John Garry Fixes: 15bbdec3931e ("iommu: Make the iova library a module") Signed-off-by: Robin Murphy Reviewed-by: Thierry Reding Link: https://lore.kernel.org/r/548c2f683ca379aface59639a8f0cccc3a1ac050.1663069227.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c28acd0039fa5ae04f01e22acae8d6f5ce84750d Author: Enzo Matsumiya Date: Fri Sep 16 20:57:05 2022 -0300 cifs: return correct error in ->calc_signature() [ Upstream commit 09a1f9a168ae1f69f701689429871793174417d2 ] If an error happens while getting the key or session in the ->calc_signature implementations, 0 (success) is returned. Fix it by returning a proper error code. Since it seems to be highly unlikely to happen wrap the rc check in unlikely() too. Reviewed-by: Ronnie Sahlberg Fixes: 32811d242ff6 ("cifs: Start using per session key for smb2/3 for signature generation") Signed-off-by: Enzo Matsumiya Signed-off-by: Steve French Signed-off-by: Sasha Levin commit c3a130431c5544c235f2f8d79fb73775f3d51f3a Author: Lin Yujun Date: Wed Sep 14 11:30:18 2022 +0800 clocksource/drivers/timer-gxp: Add missing error handling in gxp_timer_probe [ Upstream commit 0e2c8e6d769bcdc4f6634a02c545356282275e68 ] Add platform_device_put() to make sure to free the platform device in the event platform_device_add() fails. Fixes: 5184f4bf151b ("clocksource/drivers/timer-gxp: Add HPE GXP Timer") Signed-off-by: Lin Yujun Link: https://lore.kernel.org/r/20220914033018.97484-1-linyujun809@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 3da5b75beef00195a68c188ea59ad59b4ed7b67e Author: Kunkun Jiang Date: Wed Sep 14 14:14:24 2022 +0800 clocksource/drivers/arm_arch_timer: Fix handling of ARM erratum 858921 [ Upstream commit 6c3b62d93e195f78c1437c8fa7581e9b2f00886e ] The commit a38b71b0833e ("clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVAL") moves the programming of the timers from the countdown timer (TVAL) over to the comparator (CVAL). This makes it necessary to read the counter when programming next event. However, the workaround of Cortex-A73 erratum 858921 does not set the corresponding set_next_event_phys and set_next_event_virt. Add the appropriate hooks to apply the erratum mitigation when programming the next timer event. Fixes: a38b71b0833e ("clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVAL") Signed-off-by: Kunkun Jiang Acked-by: Marc Zyngier Reviewed-by: Oliver Upton Link: https://lore.kernel.org/r/20220914061424.1260-1-jiangkunkun@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 429348d4f675e9eb418d0829064c4d7d06bd66a3 Author: Damian Muszynski Date: Fri Sep 9 11:49:12 2022 +0100 crypto: qat - fix DMA transfer direction [ Upstream commit cf5bb835b7c8a5fee7f26455099cca7feb57f5e9 ] When CONFIG_DMA_API_DEBUG is selected, while running the crypto self test on the QAT crypto algorithms, the function add_dma_entry() reports a warning similar to the one below, saying that overlapping mappings are not supported. This occurs in tests where the input and the output scatter list point to the same buffers (i.e. two different scatter lists which point to the same chunks of memory). The logic that implements the mapping uses the flag DMA_BIDIRECTIONAL for both the input and the output scatter lists which leads to overlapped write mappings. These are not supported by the DMA layer. Fix by specifying the correct DMA transfer directions when mapping buffers. For in-place operations where the input scatter list matches the output scatter list, buffers are mapped once with DMA_BIDIRECTIONAL, otherwise input buffers are mapped using the flag DMA_TO_DEVICE and output buffers are mapped with DMA_FROM_DEVICE. Overlapping a read mapping with a write mapping is a valid case in dma-coherent devices like QAT. The function that frees and unmaps the buffers, qat_alg_free_bufl() has been changed accordingly to the changes to the mapping function. DMA-API: 4xxx 0000:06:00.0: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 53 PID: 4362 at kernel/dma/debug.c:570 add_dma_entry+0x1e9/0x270 ... Call Trace: dma_map_page_attrs+0x82/0x2d0 ? preempt_count_add+0x6a/0xa0 qat_alg_sgl_to_bufl+0x45b/0x990 [intel_qat] qat_alg_aead_dec+0x71/0x250 [intel_qat] crypto_aead_decrypt+0x3d/0x70 test_aead_vec_cfg+0x649/0x810 ? number+0x310/0x3a0 ? vsnprintf+0x2a3/0x550 ? scnprintf+0x42/0x70 ? valid_sg_divisions.constprop.0+0x86/0xa0 ? test_aead_vec+0xdf/0x120 test_aead_vec+0xdf/0x120 alg_test_aead+0x185/0x400 alg_test+0x3d8/0x500 ? crypto_acomp_scomp_free_ctx+0x30/0x30 ? __schedule+0x32a/0x12a0 ? ttwu_queue_wakelist+0xbf/0x110 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? try_to_wake_up+0x83/0x570 ? _raw_spin_unlock_irqrestore+0x23/0x40 ? __set_cpus_allowed_ptr_locked+0xea/0x1b0 ? crypto_acomp_scomp_free_ctx+0x30/0x30 cryptomgr_test+0x27/0x50 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Fixes: d370cec ("crypto: qat - Intel(R) QAT crypto interface") Link: https://lore.kernel.org/linux-crypto/20220223080400.139367-1-gilad@benyossef.com/ Signed-off-by: Damian Muszynski Signed-off-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5b48d7f97a57802dbad2bf46bd08d0db336ff41d Author: Peter Harliman Liem Date: Tue Sep 6 10:51:28 2022 +0800 crypto: inside-secure - Change swab to swab32 [ Upstream commit 664593407e936b6438fbfaaf98876910fd31cf9a ] The use of swab() is causing failures in 64-bit arch, as it translates to __swab64() instead of the intended __swab32(). It eventually causes wrong results in xcbcmac & cmac algo. Fixes: 78cf1c8bfcb8 ("crypto: inside-secure - Move ipad/opad into safexcel_context") Signed-off-by: Peter Harliman Liem Acked-by: Antoine Tenart Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8900bf5bb269a45115897119bdfef59bc2707378 Author: Koba Ko Date: Thu Sep 1 22:47:12 2022 +0800 crypto: ccp - Release dma channels before dmaengine unrgister [ Upstream commit 68dbe80f5b510c66c800b9e8055235c5b07e37d1 ] A warning is shown during shutdown, __dma_async_device_channel_unregister called while 2 clients hold a reference WARNING: CPU: 15 PID: 1 at drivers/dma/dmaengine.c:1110 __dma_async_device_channel_unregister+0xb7/0xc0 Call dma_release_channel for occupied channles before dma_async_device_unregister. Fixes: 54cce8ecb925 ("crypto: ccp - ccp_dmaengine_unregister release dma channels") Reported-by: kernel test robot Signed-off-by: Koba Ko Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 85bc736a18b872f54912e8bb70682d11770aece0 Author: Ignat Korchagin Date: Wed Aug 31 19:37:06 2022 +0100 crypto: akcipher - default implementation for setting a private key [ Upstream commit bc155c6c188c2f0c5749993b1405673d25a80389 ] Changes from v1: * removed the default implementation from set_pub_key: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public key Many akcipher implementations (like ECDSA) support only signature verifications, so they don't have all callbacks defined. Commit 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") introduced default callbacks for sign/verify operations, which just return an error code. However, these are not enough, because before calling sign the caller would likely call set_priv_key first on the instantiated transform (as the in-kernel testmgr does). This function does not have a default stub, so the kernel crashes, when trying to set a private key on an akcipher, which doesn't support signature generation. I've noticed this, when trying to add a KAT vector for ECDSA signature to the testmgr. With this patch the testmgr returns an error in dmesg (as it should) instead of crashing the kernel NULL ptr dereference. Fixes: 78a0324f4a53 ("crypto: akcipher - default implementations for request callbacks") Signed-off-by: Ignat Korchagin Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit bd0438f534b2e31b12f0b39b355c5dc2bbdaf854 Author: Dan Carpenter Date: Thu Aug 4 17:32:39 2022 +0300 iommu/omap: Fix buffer overflow in debugfs [ Upstream commit 184233a5202786b20220acd2d04ddf909ef18f29 ] There are two issues here: 1) The "len" variable needs to be checked before the very first write. Otherwise if omap2_iommu_dump_ctx() with "bytes" less than 32 it is a buffer overflow. 2) The snprintf() function returns the number of bytes that *would* have been copied if there were enough space. But we want to know the number of bytes which were *actually* copied so use scnprintf() instead. Fixes: bd4396f09a4a ("iommu/omap: Consolidate OMAP IOMMU modules") Signed-off-by: Dan Carpenter Reviewed-by: Robin Murphy Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/YuvYh1JbE3v+abd5@kili Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 893aa489388f90e9233820c33b269147658b8c88 Author: Waiman Long Date: Thu Sep 1 16:57:36 2022 -0400 cgroup/cpuset: Enable update_tasks_cpumask() on top_cpuset [ Upstream commit ec5fbdfb99d18482619ac42605cb80fbb56068ee ] Previously, update_tasks_cpumask() is not supposed to be called with top cpuset. With cpuset partition that takes CPUs away from the top cpuset, adjusting the cpus_mask of the tasks in the top cpuset is necessary. Percpu kthreads, however, are ignored. Fixes: ee8dde0cd2ce ("cpuset: Add new v2 cpuset.sched.partition flag") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 8fa437e48007059a9957c8ec1fcae34497fef865 Author: Weili Qian Date: Sat Aug 27 18:27:37 2022 +0800 crypto: hisilicon/qm - fix missing put dfx access [ Upstream commit 5afc904f443de2afd31c4e0686ba178beede86fe ] In function qm_cmd_write(), if function returns from branch 'atomic_read(&qm->status.flags) == QM_STOP', the got dfx access is forgotten to put. Fixes: 607c191b371d ("crypto: hisilicon - support runtime PM for accelerator device") Signed-off-by: Weili Qian Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit dcd7b39a599a4f618b780baa42ff64b4b2590eed Author: Lucas Segarra Fernandez Date: Thu Aug 25 12:32:16 2022 +0200 crypto: qat - fix default value of WDT timer [ Upstream commit cc40b04c08400d86d2d6ea0159e0617e717f729c ] The QAT HW supports an hardware mechanism to detect an accelerator hang. The reporting of a hang occurs after a watchdog timer (WDT) expires. The value of the WDT set previously was too small and was causing false positives. Change the default value of the WDT to 0x7000000ULL to avoid this. Fixes: 1c4d9d5bbb5a ("crypto: qat - enable detection of accelerators hang") Reviewed-by: Giovanni Cabiddu Signed-off-by: Lucas Segarra Fernandez Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 12fe03cee274927ef0b0912cda7fd6a62db0117b Author: Kshitiz Varshney Date: Mon Aug 22 13:19:03 2022 +0200 hwrng: imx-rngc - Moving IRQ handler registering after imx_rngc_irq_mask_clear() [ Upstream commit 10a2199caf437e893d9027d97700b3c6010048b7 ] Issue: While servicing interrupt, if the IRQ happens to be because of a SEED_DONE due to a previous boot stage, you end up completing the completion prematurely, hence causing kernel to crash while booting. Fix: Moving IRQ handler registering after imx_rngc_irq_mask_clear() Fixes: 1d5449445bd0 (hwrng: mx-rngc - add a driver for Freescale RNGC) Signed-off-by: Kshitiz Varshney Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 5ade5762b4a52ffd2aedd029ecc0bb05cba95641 Author: Michal Koutný Date: Fri Aug 26 18:52:35 2022 +0200 cgroup: Honor caller's cgroup NS when resolving path [ Upstream commit 74e4b956eb1cac0e4c10c240339b1bbfbc9a4c48 ] cgroup_get_from_path() is not widely used function. Its callers presume the path is resolved under cgroup namespace. (There is one caller currently and resolving in init NS won't make harm (netfilter). However, future users may be subject to different effects when resolving globally.) Since, there's currently no use for the global resolution, modify the existing function to take cgroup NS into account. Fixes: a79a908fd2b0 ("cgroup: introduce cgroup namespaces") Signed-off-by: Michal Koutný Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit d398cb165d1981720f01aeac3ff4c691b5361b9c Author: Jacky Li Date: Tue Aug 16 19:32:09 2022 +0000 crypto: ccp - Fail the PSP initialization when writing psp data file failed [ Upstream commit efb4b01c1c993d245e6608076684ff2162cf9dc6 ] Currently the OS continues the PSP initialization when there is a write failure to the init_ex_file. Therefore, the userspace would be told that SEV is properly INIT'd even though the psp data file is not updated. This is problematic because later when asked for the SEV data, the OS won't be able to provide it. Fixes: 3d725965f836 ("crypto: ccp - Add SEV_INIT_EX support") Reported-by: Peter Gonda Reported-by: kernel test robot Signed-off-by: Jacky Li Acked-by: David Rientjes Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 25dddddafe6eb022e928a48cce7c659282831dbe Author: James Cowgill Date: Mon Aug 1 20:04:18 2022 +0000 hwrng: arm-smccc-trng - fix NO_ENTROPY handling [ Upstream commit 042b4b169c6fb9d4df268d66282d7302dd73d37b ] The SMCCC_RET_TRNG_NO_ENTROPY switch arm is never used because the NO_ENTROPY return value is negative and negative values are handled above the switch by immediately returning. Fix by handling errors using a default arm in the switch. Fixes: 0888d04b47a1 ("hwrng: Add Arm SMCCC TRNG based driver") Signed-off-by: James Cowgill Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f8a983d6e01b198320d310cb1326364d7d973b2a Author: Ye Weihua Date: Thu Jul 28 10:07:58 2022 +0800 crypto: hisilicon/zip - fix mismatch in get/set sgl_sge_nr [ Upstream commit d74f9340097a881869c4c22ca376654cc2516ecc ] KASAN reported this Bug: [17619.659757] BUG: KASAN: global-out-of-bounds in param_get_int+0x34/0x60 [17619.673193] Read of size 4 at addr fffff01332d7ed00 by task read_all/1507958 ... [17619.698934] The buggy address belongs to the variable: [17619.708371] sgl_sge_nr+0x0/0xffffffffffffa300 [hisi_zip] There is a mismatch in hisi_zip when get/set the variable sgl_sge_nr. The type of sgl_sge_nr is u16, and get/set sgl_sge_nr by param_get/set_int. Replacing param_get/set_int to param_get/set_ushort can fix this bug. Fixes: f081fda293ffb ("crypto: hisilicon - add sgl_sge_nr module param for zip") Signed-off-by: Ye Weihua Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 50d4feadcc95d6fa972cbb37e78ee25c0e3b7d25 Author: Zhengchao Shao Date: Mon Jul 25 12:09:28 2022 +0800 crypto: sahara - don't sleep when in softirq [ Upstream commit 108586eba094b318e6a831f977f4ddcc403a15da ] Function of sahara_aes_crypt maybe could be called by function of crypto_skcipher_encrypt during the rx softirq, so it is not allowed to use mutex lock. Fixes: c0c3c89ae347 ("crypto: sahara - replace tasklets with...") Signed-off-by: Zhengchao Shao Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f03add92f4b219523b7c05b78a76abfa0289f2fe Author: Haren Myneni Date: Wed Sep 28 18:57:33 2022 -0700 powerpc/pseries/vas: Pass hw_cpu_id to node associativity HCALL [ Upstream commit f3e5d9e53e74d77e711a2c90a91a8b0836a9e0b3 ] Generally the hypervisor decides to allocate a window on different VAS instances. But if user space wishes to allocate on the current VAS instance where the process is executing, the kernel has to pass associativity domain IDs to allocate VAS window HCALL. To determine the associativity domain IDs for the current CPU, smp_processor_id() is passed to node associativity HCALL which may return H_P2 (-55) error during DLPAR CPU event. This is because Linux CPU numbers (smp_processor_id()) are not the same as the hypervisor's view of CPU numbers. Fix the issue by passing hard_smp_processor_id() with VPHN_FLAG_VCPU flag (PAPR 14.11.6.1 H_HOME_NODE_ASSOCIATIVITY). Fixes: b22f2d88e435 ("powerpc/pseries/vas: Integrate API with open/close windows") Reviewed-by: Nathan Lynch Signed-off-by: Haren Myneni [mpe: Update change log to mention Linux vs HV CPU numbers] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/55380253ea0c11341824cd4c0fc6bbcfc5752689.camel@linux.ibm.com Signed-off-by: Sasha Levin commit 4eac4f6a86ae73ef4b772d37398beeba2fbfde4e Author: Li Huafei Date: Fri Sep 23 17:32:53 2022 +0800 powerpc/kprobes: Fix null pointer reference in arch_prepare_kprobe() [ Upstream commit 97f88a3d723162781d6cbfdc7b9617eefab55b19 ] I found a null pointer reference in arch_prepare_kprobe(): # echo 'p cmdline_proc_show' > kprobe_events # echo 'p cmdline_proc_show+16' >> kprobe_events Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000000050bfc Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: CPU: 0 PID: 122 Comm: sh Not tainted 6.0.0-rc3-00007-gdcf8e5633e2e #10 NIP: c000000000050bfc LR: c000000000050bec CTR: 0000000000005bdc REGS: c0000000348475b0 TRAP: 0300 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e) MSR: 9000000000009033 CR: 88002444 XER: 20040006 CFAR: c00000000022d100 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0 ... NIP arch_prepare_kprobe+0x10c/0x2d0 LR arch_prepare_kprobe+0xfc/0x2d0 Call Trace: 0xc0000000012f77a0 (unreliable) register_kprobe+0x3c0/0x7a0 __register_trace_kprobe+0x140/0x1a0 __trace_kprobe_create+0x794/0x1040 trace_probe_create+0xc4/0xe0 create_or_delete_trace_kprobe+0x2c/0x80 trace_parse_run_command+0xf0/0x210 probes_write+0x20/0x40 vfs_write+0xfc/0x450 ksys_write+0x84/0x140 system_call_exception+0x17c/0x3a0 system_call_vectored_common+0xe8/0x278 --- interrupt: 3000 at 0x7fffa5682de0 NIP: 00007fffa5682de0 LR: 0000000000000000 CTR: 0000000000000000 REGS: c000000034847e80 TRAP: 3000 Not tainted (6.0.0-rc3-00007-gdcf8e5633e2e) MSR: 900000000280f033 CR: 44002408 XER: 00000000 The address being probed has some special: cmdline_proc_show: Probe based on ftrace cmdline_proc_show+16: Probe for the next instruction at the ftrace location The ftrace-based kprobe does not generate kprobe::ainsn::insn, it gets set to NULL. In arch_prepare_kprobe() it will check for: ... prev = get_kprobe(p->addr - 1); preempt_enable_no_resched(); if (prev && ppc_inst_prefixed(ppc_inst_read(prev->ainsn.insn))) { ... If prev is based on ftrace, 'ppc_inst_read(prev->ainsn.insn)' will occur with a null pointer reference. At this point prev->addr will not be a prefixed instruction, so the check can be skipped. Check if prev is ftrace-based kprobe before reading 'prev->ainsn.insn' to fix this problem. Fixes: b4657f7650ba ("powerpc/kprobes: Don't allow breakpoints on suffixes") Signed-off-by: Li Huafei [mpe: Trim oops] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220923093253.177298-1-lihuafei1@huawei.com Signed-off-by: Sasha Levin commit dba386d93409502d18269f2eeee6be9495212089 Author: Pali Rohár Date: Fri Sep 2 23:21:02 2022 +0200 powerpc: Fix SPE Power ISA properties for e500v1 platforms [ Upstream commit 37b9345ce7f4ab17538ea62def6f6d430f091355 ] Commit 2eb28006431c ("powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1") introduced new include file e500v2_power_isa.dtsi and should have used it for all e500v2 platforms. But apparently it was used also for e500v1 platforms mpc8540, mpc8541, mpc8555 and mpc8560. e500v1 cores compared to e500v2 do not support double precision floating point SPE instructions. Hence power-isa-sp.fd should not be set on e500v1 platforms, which is in e500v2_power_isa.dtsi include file. Fix this issue by introducing a new e500v1_power_isa.dtsi include file and use it in all e500v1 device tree files. Fixes: 2eb28006431c ("powerpc/e500v2: Add Power ISA properties to comply with ePAPR 1.1") Signed-off-by: Pali Rohár Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220902212103.22534-1-pali@kernel.org Signed-off-by: Sasha Levin commit a47254a9adac4cab162cb4dda88195d9514f77b8 Author: Nicholas Piggin Date: Mon Sep 26 15:43:01 2022 +1000 powerpc/64/interrupt: Fix return to masked context after hard-mask irq becomes pending [ Upstream commit e485f6c751e0a969327336c635ca602feea117f0 ] If a synchronous interrupt (e.g., hash fault) is taken inside an irqs-disabled region which has MSR[EE]=1, then an asynchronous interrupt that is PACA_IRQ_MUST_HARD_MASK (e.g., PMI) is taken inside the synchronous interrupt handler, then the synchronous interrupt will return with MSR[EE]=1 and the asynchronous interrupt fires again. If the asynchronous interrupt is a PMI and the original context does not have PMIs disabled (only Linux IRQs), the asynchronous interrupt will fire despite having the PMI marked soft pending. This can confuse the perf code and cause warnings. This patch changes the interrupt return so that irqs-disabled MSR[EE]=1 contexts will be returned to with MSR[EE]=0 if a PACA_IRQ_MUST_HARD_MASK interrupt has become pending in the meantime. The longer explanation for what happens: 1. local_irq_disable() 2. Hash fault interrupt fires, do_hash_fault handler runs 3. interrupt_enter_prepare() sets IRQS_ALL_DISABLED 4. interrupt_enter_prepare() sets MSR[EE]=1 5. PMU interrupt fires, masked handler runs 6. Masked handler marks PMI pending 7. Masked handler returns with PACA_IRQ_HARD_DIS set, MSR[EE]=0 8. do_hash_fault interrupt return handler runs 9. interrupt_exit_kernel_prepare() clears PACA_IRQ_HARD_DIS 10. interrupt returns with MSR[EE]=1 11. PMU interrupt fires, perf handler runs Fixes: 4423eb5ae32e ("powerpc/64/interrupt: make normal synchronous interrupts enable MSR[EE] if possible") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220926054305.2671436-4-npiggin@gmail.com Signed-off-by: Sasha Levin commit 5e3186b70002ce5570e3fff99f7ed059317a9183 Author: Nicholas Piggin Date: Mon Sep 26 15:43:00 2022 +1000 powerpc/64: mark irqs hard disabled in boot paca [ Upstream commit 799f7063c7645f9a751d17f5dfd73b952f962cd2 ] This prevents interrupts in early boot (e.g., program check) from enabling MSR[EE], potentially causing endian mismatch or other crashes when reporting early boot traps. Fixes: 4423eb5ae32ec ("powerpc/64/interrupt: make normal synchronous interrupts enable MSR[EE] if possible") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220926054305.2671436-3-npiggin@gmail.com Signed-off-by: Sasha Levin commit ef58c97f97d3884ee9262820517c62b6611ad63f Author: Nicholas Piggin Date: Wed Sep 21 11:41:02 2022 +1000 powerpc/64s: Fix GENERIC_CPU build flags for PPC970 / G5 [ Upstream commit 58ec7f06b74e0d6e76c4110afce367c8b5f0837d ] Big-endian GENERIC_CPU supports 970, but builds with -mcpu=power5. POWER5 is ISA v2.02 whereas 970 is v2.01 plus Altivec. 2.02 added the popcntb instruction which a compiler might use. Use -mcpu=power4. Fixes: 471d7ff8b51b ("powerpc/64s: Remove POWER4 support") Signed-off-by: Nicholas Piggin Reviewed-by: Segher Boessenkool Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220921014103.587954-1-npiggin@gmail.com Signed-off-by: Sasha Levin commit 99ac12f287d6c227e9ba8b718b3a0312e1714f86 Author: Vitaly Kuznetsov Date: Tue Aug 30 15:37:05 2022 +0200 x86/hyperv: Fix 'struct hv_enlightened_vmcs' definition [ Upstream commit ea9da788a61e47e7ab9cbad397453e51cd82ac0d ] Section 1.9 of TLFS v6.0b says: "All structures are padded in such a way that fields are aligned naturally (that is, an 8-byte field is aligned to an offset of 8 bytes and so on)". 'struct enlightened_vmcs' has a glitch: ... struct { u32 nested_flush_hypercall:1; /* 836: 0 4 */ u32 msr_bitmap:1; /* 836: 1 4 */ u32 reserved:30; /* 836: 2 4 */ } hv_enlightenments_control; /* 836 4 */ u32 hv_vp_id; /* 840 4 */ u64 hv_vm_id; /* 844 8 */ u64 partition_assist_page; /* 852 8 */ ... And the observed values in 'partition_assist_page' make no sense at all. Fix the layout by padding the structure properly. Fixes: 68d1eb72ee99 ("x86/hyper-v: define struct hv_enlightened_vmcs and clean field bits") Reviewed-by: Maxim Levitsky Reviewed-by: Michael Kelley Signed-off-by: Vitaly Kuznetsov Signed-off-by: Sean Christopherson Link: https://lore.kernel.org/r/20220830133737.1539624-2-vkuznets@redhat.com Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit fd4b22c4b1f07ccb57727b244fc5c0b61de9677e Author: Rohan McLure Date: Wed Sep 21 16:55:48 2022 +1000 powerpc: Fix fallocate and fadvise64_64 compat parameter combination [ Upstream commit 016ff72bd2090903715c0f9422a44afbb966f4ee ] As reported[1] by Arnd, the arch-specific fadvise64_64 and fallocate compatibility handlers assume parameters are passed with 32-bit big-endian ABI. This affects the assignment of odd-even parameter pairs to the high or low words of a 64-bit syscall parameter. Fix fadvise64_64 fallocate compat handlers to correctly swap upper/lower 32 bits conditioned on endianness. A future patch will replace the arch-specific compat fallocate with an asm-generic implementation. This patch is intended for ease of back-port. [1]: https://lore.kernel.org/all/be29926f-226e-48dc-871a-e29a54e80583@www.fastmail.com/ Fixes: 57f48b4b74e7 ("powerpc/compat_sys: swap hi/lo parts of 64-bit syscall args in LE mode") Reported-by: Arnd Bergmann Signed-off-by: Rohan McLure Reviewed-by: Arnd Bergmann Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220921065605.1051927-9-rmclure@linux.ibm.com Signed-off-by: Sasha Levin commit 4140fd90c93e99577b5bc17293c0c5c5f108aee8 Author: Anup Patel Date: Mon Jul 18 14:15:53 2022 +0530 cpuidle: riscv-sbi: Fix CPU_PM_CPU_IDLE_ENTER_xyz() macro usage [ Upstream commit cfadbb9df8c4dc917787da4458327e5ec14743d4 ] Currently, we are using CPU_PM_CPU_IDLE_ENTER_PARAM() for all SBI HSM suspend types so retentive suspend types are also treated non-retentive and kernel will do redundant additional work for these states. The BIT[31] of SBI HSM suspend types allows us to differentiate between retentive and non-retentive suspend types so we should use this BIT to call appropriate CPU_PM_CPU_IDLE_ENTER_xyz() macro. Fixes: 6abf32f1d9c5 ("cpuidle: Add RISC-V SBI CPU idle driver") Signed-off-by: Anup Patel Link: https://lore.kernel.org/r/20220718084553.2056169-1-apatel@ventanamicro.com/ Reviewed-by: Andrew Jones Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit b57099a6aa9e94cc3849a5cf6ef4450e544f2ff2 Author: Zheng Yongjun Date: Tue Sep 6 14:17:03 2022 +0000 powerpc/powernv: add missing of_node_put() in opal_export_attrs() [ Upstream commit 71a92e99c47900cc164620948b3863382cec4f1a ] After using 'np' returned by of_find_node_by_path(), of_node_put() need be called to decrease the refcount. Fixes: 11fe909d2362 ("powerpc/powernv: Add OPAL exports attributes to sysfs") Signed-off-by: Zheng Yongjun Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220906141703.118192-1-zhengyongjun3@huawei.com Signed-off-by: Sasha Levin commit a2c3374dc364a4c42a5812ee124e8fb31c2e0224 Author: Liang He Date: Fri Jul 1 21:17:50 2022 +0800 powerpc/pci_dn: Add missing of_node_put() [ Upstream commit 110a1fcb6c4d55144d8179983a475f17a1d6f832 ] In pci_add_device_node_info(), use of_node_put() to drop the reference to 'parent' returned by of_get_parent() to keep refcount balance. Fixes: cca87d303c85 ("powerpc/pci: Refactor pci_dn") Co-authored-by: Miaoqian Lin Signed-off-by: Liang He Signed-off-by: Michael Ellerman Reviewed-by: Tyrel Datwyler Link: https://lore.kernel.org/r/20220701131750.240170-1-windhl@126.com Signed-off-by: Sasha Levin commit 9c7b092253c3cc88f3dbcbf03bc8c017507f779d Author: Liang He Date: Mon Jul 4 22:52:33 2022 +0800 powerpc/sysdev/fsl_msi: Add missing of_node_put() [ Upstream commit def435c04ee984a5f9ed2711b2bfe946936c6a21 ] In fsl_setup_msi_irqs(), use of_node_put() to drop the reference returned by of_parse_phandle(). Fixes: 895d603f945ba ("powerpc/fsl_msi: add support for the fsl, msi property in PCI nodes") Co-authored-by: Miaoqian Lin Signed-off-by: Liang He Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220704145233.278539-1-windhl@126.com Signed-off-by: Sasha Levin commit 5c140a35c1d6997ad40223786d1df623297e635b Author: Nathan Chancellor Date: Fri Sep 2 18:00:08 2022 +0200 powerpc/math_emu/efp: Include module.h [ Upstream commit cfe0d370e0788625ce0df3239aad07a2506c1796 ] When building with a recent version of clang, there are a couple of errors around the call to module_init(): arch/powerpc/math-emu/math_efp.c:927:1: error: type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int [-Wimplicit-int] module_init(spe_mathemu_init); ^ int arch/powerpc/math-emu/math_efp.c:927:13: error: a parameter list without types is only allowed in a function definition module_init(spe_mathemu_init); ^ 2 errors generated. module_init() is a macro, which is not getting expanded because module.h is not included in this file. Add the include so that the macro can expand properly, clearing up the build failure. Fixes: ac6f120369ff ("powerpc/85xx: Workaroudn e500 CPU erratum A005") [chleroy: added fixes tag] Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/r/8403854a4c187459b2f4da3537f51227b70b9223.1662134272.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 6f20506c3e9d9ce4182e46ab365b17a67eccdb09 Author: Michael Ellerman Date: Thu Sep 1 11:42:53 2022 +1000 powerpc/configs: Properly enable PAPR_SCM in pseries_defconfig [ Upstream commit aa398d88aea4ec863bd7aea35d5035a37096dc59 ] My commit to add PAPR_SCM to pseries_defconfig failed to add the required dependencies, meaning the driver doesn't get built. Add the required LIBNVDIMM=m. Fixes: d6481a7195df ("powerpc/configs: Add PAPR_SCM to pseries_defconfig") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220901014253.252927-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit a1f321051e0dcf2415fb94f81fdc5044cad4c1d6 Author: Hangyu Hua Date: Fri Jul 15 14:23:01 2022 +0800 ipc: mqueue: fix possible memory leak in init_mqueue_fs() [ Upstream commit c579d60f0d0cd87552f64fdebe68b5d941d20309 ] commit db7cfc380900 ("ipc: Free mq_sysctls if ipc namespace creation failed") Here's a similar memory leak to the one fixed by the patch above. retire_mq_sysctls need to be called when init_mqueue_fs fails after setup_mq_sysctls. Fixes: dc55e35f9e81 ("ipc: Store mqueue sysctls in the ipc namespace") Signed-off-by: Hangyu Hua Link: https://lkml.kernel.org/r/20220715062301.19311-1-hbh25y@gmail.com Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit 908bfb4f5ff88dc1a85820110a38e6ba9082ff2b Author: Jack Wang Date: Fri Aug 26 12:13:35 2022 +0200 mailbox: bcm-ferxrm-mailbox: Fix error check for dma_map_sg [ Upstream commit 6b207ce8a96a71e966831e3a13c38143ba9a73c1 ] dma_map_sg return 0 on error, fix the error check, and return -EIO to caller. Fixes: dbc049eee730 ("mailbox: Add driver for Broadcom FlexRM ring manager") Signed-off-by: Jack Wang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit adc15eefb41770433e1c80cda92bdf58fb6ab0c1 Author: Conor Dooley Date: Wed Aug 24 08:08:12 2022 +0100 mailbox: mpfs: account for mbox offsets while sending [ Upstream commit 0d1aadfe10ba17ebdeb96abb9638eb0f623f9b55 ] The mailbox offset is not only used for receiving messages, but it is also used by messages sent to the system controller by Linux that have a payload, such as the "digital signature service". It is also overloaded by certain other services (reprogramming of the FPGA fabric, see Link:) to have a meaning other than the offset the system controller should read from. When the driver was written, no such services of the latter type were in use & those of the former used an offset of zero so this has gone un-noticed. Link: https://www.microsemi.com/document-portal/doc_download/1245815-polarfire-fpga-and-polarfire-soc-fpga-system-services-user-guide # Section 5.2 Fixes: 83d7b1560810 ("mbox: add polarfire soc system controller mailbox") Signed-off-by: Conor Dooley Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 0b921157ee9f4619b68de580017a8c8606abbb23 Author: Conor Dooley Date: Wed Aug 24 08:08:11 2022 +0100 mailbox: mpfs: fix handling of the reg property [ Upstream commit 2e10289d1f304f5082a4dda55a677b72b3bdb581 ] The "data" region of the PolarFire SoC's system controller mailbox is not one continuous register space - the system controller's QSPI sits between the control and data registers. Split the "data" reg into two parts: "data" & "control". Optionally get the "data" register address from the 3rd reg property in the devicetree & fall back to using the old base + MAILBOX_REG_OFFSET that the current code uses. Fixes: 83d7b1560810 ("mbox: add polarfire soc system controller mailbox") Signed-off-by: Conor Dooley Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 5edb0618919e5210d4ecdf53cc70673d4c8c9157 Author: Joel Stanley Date: Thu Apr 21 13:34:26 2022 +0930 clk: ast2600: BCLK comes from EPLL [ Upstream commit b8c1dc9c00b252b3be853720a71b05ed451ddd9f ] This correction was made in the u-boot SDK recently. There are no in-tree users of this clock so the impact is minimal. Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC") Link: https://github.com/AspeedTech-BMC/u-boot/commit/8ad54a5ae15f27fea5e894cc2539a20d90019717 Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20220421040426.171256-1-joel@jms.id.au Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit a9f69663ad571cbd7814dde38e3fcb4876341ed6 Author: Miaoqian Lin Date: Thu Jun 2 07:08:36 2022 +0400 clk: ti: dra7-atl: Fix reference leak in of_dra7_atl_clk_probe [ Upstream commit 9c59a01caba26ec06fefd6ca1f22d5fd1de57d63 ] pm_runtime_get_sync() will increment pm usage counter. Forgetting to putting operation will result in reference leak. Add missing pm_runtime_put_sync in some error paths. Fixes: 9ac33b0ce81f ("CLK: TI: Driver for DRA7 ATL (Audio Tracking Logic)") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220602030838.52057-1-linmq006@gmail.com Reviewed-by: Tony Lindgren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 7125637a6cc42947a753ec42355e913a7e4de1bf Author: Liang He Date: Thu Sep 15 11:11:21 2022 +0800 clk: ti: Balance of_node_get() calls for of_find_node_by_name() [ Upstream commit 058a3996b888ab60eb1857fb4fd28f1b89a9a95a ] In ti_find_clock_provider(), of_find_node_by_name() will call of_node_put() for the 'from' argument, possibly putting the node one too many times. Let's maintain the of_node_get() from the previous search and only put when we're exiting the function early. This should avoid a misbalanced reference count on the node. Fixes: 51f661ef9a10 ("clk: ti: Add ti_find_clock_provider() to use clock-output-names") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220915031121.4003589-1-windhl@126.com [sboyd@kernel.org: Rewrite commit text, maintain reference instead of get again] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 43c589b7a187ef481b594317eaab8c8f269e4a68 Author: Lin Yujun Date: Wed Sep 14 11:32:06 2022 +0800 clk: imx: scu: fix memleak on platform_device_add() fails [ Upstream commit 855ae87a2073ebf1b395e020de54fdf9ce7d166f ] No error handling is performed when platform_device_add() fails. Add error processing before return, and modified the return value. Fixes: 77d8f3068c63 ("clk: imx: scu: add two cells binding support") Signed-off-by: Lin Yujun Link: https://lore.kernel.org/r/20220914033206.98046-1-linyujun809@huawei.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 13fc676c7185fce8588729b1d87745152c51d487 Author: Stefan Wahren Date: Sun Sep 4 16:10:37 2022 +0200 clk: bcm2835: fix bcm2835_clock_rate_from_divisor declaration [ Upstream commit 0b919a3728691c172312dee99ba654055ccd8c84 ] The return value of bcm2835_clock_rate_from_divisor is always unsigned and also all caller expect this. So fix the declaration accordingly. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20220904141037.38816-1-stefan.wahren@i2se.com Reviewed-by: Ivan T. Ivanov Reviewed-by: Florian Fainelli Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit c20099c19cb3fa83a2b63cf341718ecd3949d0b7 Author: Serge Semin Date: Fri Sep 30 01:53:58 2022 +0300 clk: baikal-t1: Add SATA internal ref clock buffer [ Upstream commit 081a9b7c74eae4e12b2cb1b86720f836a8f29247 ] It turns out the internal SATA reference clock signal will stay unavailable for the SATA interface consumer until the buffer on it's way is ungated. So aside with having the actual clock divider enabled we need to ungate a buffer placed on the signal way to the SATA controller (most likely some rudiment from the initial SoC release). Seeing the switch flag is placed in the same register as the SATA-ref clock divider at a non-standard ffset, let's implement it as a separate clock controller with the set-rate propagation to the parental clock divider wrapper. As such we'll be able to disable/enable and still change the original clock source rate. Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20220929225402.9696-5-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4dc50ce40b590d2b5a7544fd29b53fe85eb6b68a Author: Serge Semin Date: Fri Sep 30 01:53:57 2022 +0300 clk: baikal-t1: Add shared xGMAC ref/ptp clocks internal parent [ Upstream commit e2eef312762e0b5a5a70d29fe59a245c0a3cffa0 ] Baikal-T1 CCU reference manual says that both xGMAC reference and xGMAC PTP clocks are generated by two different wrappers with the same constant divider thus each producing a 156.25 MHz signal. But for some reason both of these clock sources are gated by a single switch-flag in the CCU registers space - CCU_SYS_XGMAC_BASE.BIT(0). In order to make the clocks handled independently we need to define a shared parental gate so the base clock signal would be switched off only if both of the child-clocks are disabled. Note the ID is intentionally set to -2 since we are going to add a one more internal clock identifier in the next commit. Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20220929225402.9696-4-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6e2394f58dd1461d1d166a991776a710ceee297c Author: Serge Semin Date: Fri Sep 30 01:53:56 2022 +0300 clk: baikal-t1: Fix invalid xGMAC PTP clock divider [ Upstream commit 3c742088686ce922704aec5b11d09bcc5a396589 ] Most likely due to copy-paste mistake the divider has been set to 10 while according to the SoC reference manual it's supposed to be 8 thus having PTP clock frequency of 156.25 MHz. Fixes: 353afa3a8d2e ("clk: Add Baikal-T1 CCU Dividers driver") Signed-off-by: Serge Semin Link: https://lore.kernel.org/r/20220929225402.9696-3-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 4dcae3385ced0ed2852fabfebce817eb51cef8db Author: Serge Semin Date: Fri Sep 30 01:53:55 2022 +0300 clk: vc5: Fix 5P49V6901 outputs disabling when enabling FOD [ Upstream commit c388cc804016cf0f65afdc2362b120aa594ff3e6 ] We have discovered random glitches during the system boot up procedure. The problem investigation led us to the weird outcomes: when none of the Renesas 5P49V6901 ports are explicitly enabled by the kernel driver, the glitches disappeared. It was a mystery since the SoC external clock domains were fed with different 5P49V6901 outputs. The driver code didn't seem like bogus either. We almost despaired to find out a root cause when the solution has been found for a more modern revision of the chip. It turned out the 5P49V6901 clock generator stopped its output for a short period of time during the VC5_OUT_DIV_CONTROL register writing. The same problem was found for the 5P49V6965 revision of the chip and was successfully fixed in commit fc336ae622df ("clk: vc5: fix output disabling when enabling a FOD") by enabling the "bypass_sync" flag hidden inside "Unused Factory Reserved Register". Even though the 5P49V6901 registers description and programming guide doesn't provide any intel regarding that flag, setting it up anyway in the officially unused register completely eliminated the denoted glitches. Thus let's activate the functionality submitted in commit fc336ae622df ("clk: vc5: fix output disabling when enabling a FOD") for the Renesas 5P49V6901 chip too in order to remove the ports implicit inter-dependency. Fixes: dbf6b16f5683 ("clk: vc5: Add support for IDT VersaClock 5P49V6901") Signed-off-by: Serge Semin Reviewed-by: Luca Ceresoli Link: https://lore.kernel.org/r/20220929225402.9696-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 03c55521879a8d08de0255918ce7ab44e0b103f5 Author: David Collins Date: Thu Sep 29 17:50:16 2022 -0700 spmi: pmic-arb: correct duplicate APID to PPID mapping logic [ Upstream commit 1f1693118c2476cb1666ad357edcf3cf48bf9b16 ] Correct the way that duplicate PPID mappings are handled for PMIC arbiter v5. The final APID mapped to a given PPID should be the one which has write owner = APPS EE, if it exists, or if not that, then the first APID mapped to the PPID, if it exists. Fixes: 40f318f0ed67 ("spmi: pmic-arb: add support for HW version 5") Signed-off-by: David Collins Signed-off-by: Fenglin Wu Link: https://lore.kernel.org/r/1655004286-11493-7-git-send-email-quic_fenglinw@quicinc.com Signed-off-by: Stephen Boyd Link: https://lore.kernel.org/r/20220930005019.2663064-8-sboyd@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 69e1e6a82ef424dc763f38dbd1f244f6a2856e7e Author: Chunfeng Yun Date: Thu Sep 29 14:44:59 2022 +0800 usb: mtu3: fix failed runtime suspend in host only mode [ Upstream commit 1c703e29da5efac6180e4c189029fa34b7e48e97 ] When the dr_mode is "host", after the host enter runtime suspend, the mtu3 can't do it, because the mtu3's device wakeup function is not enabled, instead it's enabled in gadget init function, to fix the issue, init wakeup early in mtu3's probe() Fixes: 6b587394c65c ("usb: mtu3: support suspend/resume for dual-role mode") Reviewed-by: AngeloGioacchino Del Regno Reported-by: Tianping Fang Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/20220929064459.32522-1-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c1914501c13404f4ac715e6b2282387d3791e03e Author: Dave Jiang Date: Mon Sep 19 09:58:42 2022 -0700 dmaengine: ioat: stop mod_timer from resurrecting deleted timer in __cleanup() [ Upstream commit 898ec89dbb55b8294695ad71694a0684e62b2a73 ] User reports observing timer event report channel halted but no error observed in CHANERR register. The driver finished self-test and released channel resources. Debug shows that __cleanup() can call mod_timer() after the timer has been deleted and thus resurrect the timer. While harmless, it causes suprious error message to be emitted. Use mod_timer_pending() call to prevent deleted timer from being resurrected. Fixes: 3372de5813e4 ("dmaengine: ioatdma: removal of dma_v3.c and relevant ioat3 references") Signed-off-by: Dave Jiang Link: https://lore.kernel.org/r/166360672197.3851724.17040290563764838369.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 23c9084645f03cce06b2a67fdd80367bfc7833e2 Author: Chen-Yu Tsai Date: Mon Sep 26 18:25:19 2022 +0800 clk: mediatek: Migrate remaining clk_unregister_*() to clk_hw_unregister_*() [ Upstream commit fef14676fc4be40b8441745a3c96b7e7d7d8592d ] During the previous |struct clk| to |struct clk_hw| clk provider API migration in commit 6f691a586296 ("clk: mediatek: Switch to clk_hw provider APIs"), a few clk_unregister_*() calls were missed. Migrate the remaining ones to the |struct clk_hw| provider API, i.e. change clk_unregister_*() to clk_hw_unregister_*(). Fixes: 6f691a586296 ("clk: mediatek: Switch to clk_hw provider APIs") Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220926102523.2367530-3-wenst@chromium.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 1a328477ea1792ec0fe65661bafaf2e0f5ee8f73 Author: Chen-Yu Tsai Date: Mon Sep 26 18:25:18 2022 +0800 clk: mediatek: fix unregister function in mtk_clk_register_dividers cleanup [ Upstream commit 20f7a0dba9075fb0e3d645495bc24d7025b58de1 ] When the cleanup paths for the various clk register APIs in the MediaTek clk library were added, the one in the dividers type used the wrong type of unregister function. This would result in incorrect dereferencing of the clk pointer and freeing of invalid pointers. Fix this by switching to the correct type of clk unregistration call. Fixes: 3c3ba2ab0226 ("clk: mediatek: mtk: Implement error handling in register APIs") Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220926102523.2367530-2-wenst@chromium.org Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 05ff2207fa040e31b248aae72e2cb5946c45a213 Author: AngeloGioacchino Del Regno Date: Tue Sep 27 12:11:23 2022 +0200 clk: mediatek: clk-mt8195-mfg: Reparent mfg_bg3d and propagate rate changes [ Upstream commit a5f7bf5458c2cf6730106e16a6373638a0e5ed1e ] The MFG_BG3D is a gate to enable/disable clock output to the GPU, but the actual output is decided by multiple muxes; in particular: mfg_ck_fast_ref muxes between "slow" (top_mfg_core_tmp) and "fast" (MFGPLL) clock, while top_mfg_core_tmp muxes between the 26MHz clock and various system PLLs. The clock gate comes after all the muxes, so its parent is mfg_ck_fast_reg, not top_mfg_core_tmp. Reparent MFG_BG3D to the latter to match the hardware and add the CLK_SET_RATE_PARENT flag to it: this way we ensure propagating rate changes that are requested on MFG_BG3D along its entire clock tree. Fixes: 35016f10c0e5 ("clk: mediatek: Add MT8195 mfgcfg clock support") Signed-off-by: AngeloGioacchino Del Regno Reviewed-by: Chen-Yu Tsai Link: https://lore.kernel.org/r/20220927101128.44758-6-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit fddb8f871a1f94a4998198bc7ee4e73caf13b912 Author: Chen-Yu Tsai Date: Tue Sep 27 12:11:20 2022 +0200 clk: mediatek: mt8183: mfgcfg: Propagate rate changes to parent [ Upstream commit 9f94f545f258b15bfa6357eb62e1e307b712851e ] The only clock in the MT8183 MFGCFG block feeds the GPU. Propagate its rate change requests to its parent, so that DVFS for the GPU can work properly. Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220927101128.44758-3-angelogioacchino.delregno@collabora.com Signed-off-by: Chen-Yu Tsai Signed-off-by: Sasha Levin commit 85c7a6837ea769d3af4b49552da8c111a951efab Author: Jens Hillenstedt Date: Thu Sep 15 11:20:04 2022 +0200 mfd: da9061: Fix Failed to set Two-Wire Bus Mode. [ Upstream commit 834382ea32865a4bdeae83ec2dcb9321dc9489f2 ] In da9062_i2c_probe() regmap_clear_bits() tries to access CONFIG_J register. As CONFIG_J is not present in da9061_aa_writeable_ranges[] probe of da9061 fails: da9062 2-0058: Entering I2C mode! da9062 2-0058: Failed to set Two-Wire Bus Mode. da9062: probe of 2-0058 failed with error -5 Add CONFIG_J register to da9061_aa_writeable_ranges[]. Fixes: 5c6f0f456351 ("mfd: da9062: Support SMBus and I2C mode") Signed-off-by: Jens Hillenstedt Reviewed-by: Adam Ward Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220915092004.168744-1-jens.hillenstedt@ise.de Signed-off-by: Sasha Levin commit e878673f5635202cbf2a93c1932820b6384b710f Author: Jiasheng Jiang Date: Tue Sep 13 17:11:12 2022 +0800 mfd: sm501: Add check for platform_driver_register() [ Upstream commit 8325a6c24ad78b8c1acc3c42b098ee24105d68e5 ] As platform_driver_register() can return error numbers, it should be better to check platform_driver_register() and deal with the exception. Fixes: b6d6454fdb66 ("[PATCH] mfd: SM501 core driver") Signed-off-by: Jiasheng Jiang Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220913091112.1739138-1-jiasheng@iscas.ac.cn Signed-off-by: Sasha Levin commit deaafe55a1d0f486665b4f0279c19fff3f9ce754 Author: Dan Carpenter Date: Thu Aug 11 13:53:05 2022 +0300 mfd: fsl-imx25: Fix check for platform_get_irq() errors [ Upstream commit 75db7907355ca5e2ff606e9dd3e86b6c3a455fe2 ] The mx25_tsadc_remove() function assumes all non-zero returns are success but the platform_get_irq() function returns negative on error and positive non-zero values on success. It never returns zero, but if it did then treat that as a success. Fixes: 18f773937968 ("mfd: fsl-imx25: Clean up irq settings during removal") Signed-off-by: Dan Carpenter Reviewed-by: Martin Kaiser Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/YvTfkbVQWYKMKS/t@kili Signed-off-by: Sasha Levin commit c337ff96ef9ec404ffabf33d0c3ca0a4ccbdcf82 Author: Christophe JAILLET Date: Sun Jul 31 11:55:38 2022 +0200 mfd: lp8788: Fix an error handling path in lp8788_irq_init() and lp8788_irq_init() [ Upstream commit 557244f6284f30613f2d61f14b579303165876c3 ] In lp8788_irq_init(), if an error occurs after a successful irq_domain_add_linear() call, it must be undone by a corresponding irq_domain_remove() call. irq_domain_remove() should also be called in lp8788_irq_exit() for the same reason. Fixes: eea6b7cc53aa ("mfd: Add lp8788 mfd driver") Signed-off-by: Christophe JAILLET Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/bcd5a72c9c1c383dd6324680116426e32737655a.1659261275.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit ab94a72c82cc650bb489529019137b4c6f371b4f Author: Christophe JAILLET Date: Sun Jul 31 11:55:27 2022 +0200 mfd: lp8788: Fix an error handling path in lp8788_probe() [ Upstream commit becfdcd75126b20b8ec10066c5e85b34f8994ad5 ] Should an error occurs in mfd_add_devices(), some resources need to be released, as already done in the .remove() function. Add an error handling path and a lp8788_irq_exit() call to undo a previous lp8788_irq_init(). Fixes: eea6b7cc53aa ("mfd: Add lp8788 mfd driver") Signed-off-by: Christophe JAILLET Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/18398722da9df9490722d853e4797350189ae79b.1659261275.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 9bb4cb60c0320f577f698cf15c2789f5cb2ad8d4 Author: Christophe JAILLET Date: Sun Jul 31 14:06:23 2022 +0200 mfd: fsl-imx25: Fix an error handling path in mx25_tsadc_setup_irq() [ Upstream commit 3fa9e4cfb55da512ebfd57336fde468830719298 ] If devm_of_platform_populate() fails, some resources need to be released. Introduce a mx25_tsadc_unset_irq() function that undoes mx25_tsadc_setup_irq() and call it both from the new error handling path of the probe and in the remove function. Fixes: a55196eff6d6 ("mfd: fsl-imx25: Use devm_of_platform_populate()") Signed-off-by: Christophe JAILLET Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/d404e04828fc06bcfddf81f9f3e9b4babbe35415.1659269156.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit 36905589383fdff2491c57d358eab6fe1efdf6ab Author: Christophe JAILLET Date: Mon Aug 1 14:42:02 2022 +0300 mfd: intel_soc_pmic: Fix an error handling path in intel_soc_pmic_i2c_probe() [ Upstream commit 48749cabba109397b4e7dd556e85718ec0ec114d ] The commit in Fixes: has added a pwm_add_table() call in the probe() and a pwm_remove_table() call in the remove(), but forget to update the error handling path of the probe. Add the missing pwm_remove_table() call. Fixes: a3aa9a93df9f ("mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM") Signed-off-by: Christophe JAILLET Signed-off-by: Andy Shevchenko Reviewed-by: Hans de Goede Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220801114211.36267-1-andriy.shevchenko@linux.intel.com Signed-off-by: Sasha Levin commit 8c24097d6fb90369e76a25e7b201a05f550e6468 Author: Jiasheng Jiang Date: Tue Jan 11 15:34:11 2022 +0800 fsi: core: Check error number after calling ida_simple_get [ Upstream commit 35af9fb49bc5c6d61ef70b501c3a56fe161cce3e ] If allocation fails, the ida_simple_get() will return error number. So master->idx could be error number and be used in dev_set_name(). Therefore, it should be better to check it and return error if fails, like the ida_simple_get() in __fsi_get_new_minor(). Fixes: 09aecfab93b8 ("drivers/fsi: Add fsi master definition") Signed-off-by: Jiasheng Jiang Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20220111073411.614138-1-jiasheng@iscas.ac.cn Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 52dd1b675ed93420e7eee310dca39557cc06cdeb Author: Bob Pearson Date: Thu Aug 25 17:14:47 2022 -0500 RDMA/rxe: Fix resize_finish() in rxe_queue.c [ Upstream commit fda5d0cf8aef12f0a4f714a96a4b2fce039a3e55 ] Currently in resize_finish() in rxe_queue.c there is a loop which copies the entries in the original queue into a newly allocated queue. The termination logic for this loop is incorrect. The call to queue_next_index() updates cons but has no effect on whether the queue is empty. So if the queue starts out empty nothing is copied but if it is not then the loop will run forever. This patch changes the loop to compare the value of cons to the original producer index. Fixes: ae6e843fe08d0 ("RDMA/rxe: Add memory barriers to kernel queues") Link: https://lore.kernel.org/r/20220825221446.6512-1-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson Reviewed-by: Li Zhijian Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8dec723159886e01ce450c2d827e628dcef540e0 Author: Adam Skladowski Date: Tue Aug 30 10:56:18 2022 +0300 clk: qcom: gcc-sm6115: Override default Alpha PLL regs [ Upstream commit 068a0605ef5a6b430e7278c169bfcd25b680b28f ] The DEFAULT and BRAMMO PLL offsets are non-standard in downstream, but currently only BRAMMO ones are overridden. Override DEFAULT ones too. A very similar thing is happening in gcc-qcm2290 driver. Fixes: cbe63bfdc54f ("clk: qcom: Add Global Clock controller (GCC) driver for SM6115") Signed-off-by: Adam Skladowski Signed-off-by: Iskren Chernev Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220830075620.974009-2-iskren.chernev@gmail.com Signed-off-by: Sasha Levin commit a1ba69d624a109d89090a7d202c49cbb605e85ca Author: Robert Marko Date: Fri Aug 19 00:06:22 2022 +0200 clk: qcom: apss-ipq6018: mark apcs_alias0_core_clk as critical [ Upstream commit 86e78995c93ee182433f965babfccd48417d4dcf ] While fixing up the driver I noticed that my IPQ8074 board was hanging after CPUFreq switched the frequency during boot, WDT would eventually reset it. So mark apcs_alias0_core_clk as critical since its the clock feeding the CPU cluster and must never be disabled. Fixes: 5e77b4ef1b19 ("clk: qcom: Add ipq6018 apss clock controller") Signed-off-by: Robert Marko Reviewed-by: Dmitry Baryshkov Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220818220628.339366-3-robimarko@gmail.com Signed-off-by: Sasha Levin commit 897dbbc57d71e8a34ec1af8e573a142de457da38 Author: Mike Christie Date: Wed Sep 7 17:17:00 2022 -0500 scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername() [ Upstream commit 57569c37f0add1b6489e1a1563c71519daf732cf ] Fix a NULL pointer crash that occurs when we are freeing the socket at the same time we access it via sysfs. The problem is that: 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold() does a get on the "struct sock". 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put on the "struct socket" and that does __sock_release() which sets the sock->ops to NULL. 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then call kernel_getpeername() which accesses the NULL sock->ops. Above we do a get on the "struct sock", but we needed a get on the "struct socket". Originally, we just held the frwd_lock the entire time but in commit bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername()") we switched to refcount based because the network layer changed and started taking a mutex in that path, so we could no longer hold the frwd_lock. Instead of trying to maintain multiple refcounts, this just has us use a mutex for accessing the socket in the interface code paths. Link: https://lore.kernel.org/r/20220907221700.10302-1-michael.christie@oracle.com Fixes: bcf3a2953d36 ("scsi: iscsi: iscsi_tcp: Avoid holding spinlock while calling getpeername()") Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c5922e8e42b8db7916ddf27362faf9e0b39f96d4 Author: Mike Christie Date: Thu Jun 16 17:45:51 2022 -0500 scsi: iscsi: Run recv path from workqueue [ Upstream commit f1d269765ee29da56b32818b7a08054484ed89f2 ] We don't always want to run the recv path from the network softirq because when we have to have multiple sessions sharing the same CPUs, some sessions can eat up the NAPI softirq budget and affect other sessions or users. Allow us to queue the recv handling to the iscsi workqueue so we can have the scheduler/wq code try to balance the work and CPU use across all sessions' worker threads. Note: It wasn't the original intent of the change but a nice side effect is that for some workloads/configs we get a nice performance boost. For a simple read heavy test: fio --direct=1 --filename=/dev/dm-0 --rw=randread --bs=256K --ioengine=libaio --iodepth=128 --numjobs=4 where the iscsi threads, fio jobs, and rps_cpus share CPUs we see a 32% throughput boost. We also see increases for small I/O IOPs tests but it's not as high. Link: https://lore.kernel.org/r/20220616224557.115234-4-michael.christie@oracle.com Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") Signed-off-by: Sasha Levin commit bd16ec67e9959b749cc228baea06f670381c2ebb Author: Mike Christie Date: Thu Jun 16 17:45:50 2022 -0500 scsi: iscsi: Add recv workqueue helpers [ Upstream commit 8af809966c0b34cfacd8da9a412689b8e9910354 ] Add helpers to allow the drivers to run their recv paths from libiscsi's workqueue. Link: https://lore.kernel.org/r/20220616224557.115234-3-michael.christie@oracle.com Reviewed-by: Lee Duncan Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") Signed-off-by: Sasha Levin commit 38a118abf5ccafd54ad4f24556ee3ff1b0351a21 Author: Mike Christie Date: Thu Jun 16 17:45:49 2022 -0500 scsi: iscsi: Rename iscsi_conn_queue_work() [ Upstream commit 4b9f8ce4d5e823e42944c5a0a4842b0f936365ad ] Rename iscsi_conn_queue_work() to iscsi_conn_queue_xmit() to reflect that it handles queueing of xmits only. Link: https://lore.kernel.org/r/20220616224557.115234-2-michael.christie@oracle.com Reviewed-by: Lee Duncan Reviewed-by: Wu Bo Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Stable-dep-of: 57569c37f0ad ("scsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()") Signed-off-by: Sasha Levin commit 4e750e0d8e486569fcb7f4ba6f6471673ce7d8a2 Author: John Garry Date: Thu Sep 22 21:51:04 2022 +0800 scsi: pm8001: Fix running_req for internal abort commands [ Upstream commit d8c22c4697c11ed28062afe3c2b377025be11a23 ] Disabling the remote phy for a SATA disk causes a hang: root@(none)$ more /sys/class/sas_phy/phy-0:0:8/target_port_protocols sata root@(none)$ echo 0 > sys/class/sas_phy/phy-0:0:8/enable root@(none)$ [ 67.855950] sas: ex 500e004aaaaaaa1f phy08 change count has changed [ 67.920585] sd 0:0:2:0: [sdc] Synchronizing SCSI cache [ 67.925780] sd 0:0:2:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK [ 67.935094] sd 0:0:2:0: [sdc] Stopping disk [ 67.939305] sd 0:0:2:0: [sdc] Start/Stop Unit failed: Result: hostbyte=0x04 driverbyte=DRIVER_OK ... [ 123.998998] INFO: task kworker/u192:1:642 blocked for more than 30 seconds. [ 124.005960] Not tainted 6.0.0-rc1-205202-gf26f8f761e83 #218 [ 124.012049] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 124.019872] task:kworker/u192:1 state:D stack:0 pid: 642 ppid: 2 flags:0x00000008 [ 124.028223] Workqueue: 0000:04:00.0_event_q sas_port_event_worker [ 124.034319] Call trace: [ 124.036758] __switch_to+0x128/0x278 [ 124.040333] __schedule+0x434/0xa58 [ 124.043820] schedule+0x94/0x138 [ 124.047045] schedule_timeout+0x2fc/0x368 [ 124.051052] wait_for_completion+0xdc/0x200 [ 124.055234] __flush_workqueue+0x1a8/0x708 [ 124.059328] sas_porte_broadcast_rcvd+0xa8/0xc0 [ 124.063858] sas_port_event_worker+0x60/0x98 [ 124.068126] process_one_work+0x3f8/0x660 [ 124.072134] worker_thread+0x70/0x700 [ 124.075793] kthread+0x1a4/0x1b8 [ 124.079014] ret_from_fork+0x10/0x20 The issue is that the per-device running_req read in pm8001_dev_gone_notify() never goes to zero and we never make progress. This is caused by missing accounting for running_req for when an internal abort command completes. In commit 2cbbf489778e ("scsi: pm8001: Use libsas internal abort support") we started to send internal abort commands as a proper sas_task. In this when we deliver a sas_task to HW the per-device running_req is incremented in pm8001_queue_command(). However it is never decremented for internal abort commnds, so decrement in pm8001_mpi_task_abort_resp(). Link: https://lore.kernel.org/r/1663854664-76165-1-git-send-email-john.garry@huawei.com Fixes: 2cbbf489778e ("scsi: pm8001: Use libsas internal abort support") Acked-by: Jack Wang Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f7a785177611ffc97d645fcbc196e6de6ad2421d Author: Duoming Zhou Date: Tue Sep 20 22:42:13 2022 +0800 scsi: libsas: Fix use-after-free bug in smp_execute_task_sg() [ Upstream commit 46ba53c30666717cb06c2b3c5d896301cd00d0c0 ] When executing SMP task failed, the smp_execute_task_sg() calls del_timer() to delete "slow_task->timer". However, if the timer handler sas_task_internal_timedout() is running, the del_timer() in smp_execute_task_sg() will not stop it and a UAF will happen. The process is shown below: (thread 1) | (thread 2) smp_execute_task_sg() | sas_task_internal_timedout() ... | del_timer() | ... | ... sas_free_task(task) | kfree(task->slow_task) //FREE| | task->slow_task->... //USE Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure the timer handler have finished before the "task->slow_task" is deallocated. Link: https://lore.kernel.org/r/20220920144213.10536-1-duoming@zju.edu.cn Fixes: 2908d778ab3e ("[SCSI] aic94xx: new driver") Reviewed-by: Jason Yan Signed-off-by: Duoming Zhou Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dae33133f255c1b4c6ffd355742e6395e63cef43 Author: Pali Rohár Date: Sat Sep 24 12:43:24 2022 +0200 serial: 8250: Fix restoring termios speed after suspend [ Upstream commit 379a33786d489ab81885ff0b3935cfeb36137fea ] Since commit edc6afc54968 ("tty: switch to ktermios and new framework") termios speed is no longer stored only in c_cflag member but also in new additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag then termios speed is stored only in these new members. Since commit 027b57170bf8 ("serial: core: Fix initializing and restoring termios speed") termios speed is available also in struct console. So properly restore also c_ispeed and c_ospeed members after suspend to fix restoring termios speed which is not represented by Bnnn constant. Fixes: 4516d50aabed ("serial: 8250: Use canary to restart console after suspend") Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20220924104324.4035-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c6ce163bb827361d2872f31a5aaae6bd45feeee4 Author: Guilherme G. Piccoli Date: Fri Sep 9 17:07:55 2022 -0300 firmware: google: Test spinlock on panic path to avoid lockups [ Upstream commit 3e081438b8e639cc76ef1a5ce0c1bd8a154082c7 ] Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic and very limited context - for instance, panic disables preemption and local IRQs, also all secondary CPUs (not executing the panic path) are shutdown. With that said, taking a spinlock in this scenario is a dangerous invitation for lockup scenarios. So, fix that by checking if the spinlock is free to acquire in the panic notifier callback - if not, bail-out and avoid a potential hang. Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: Andrew Morton Cc: Ard Biesheuvel Cc: David Gow Cc: Greg Kroah-Hartman Cc: Julius Werner Cc: Petr Mladek Reviewed-by: Evan Green Signed-off-by: Guilherme G. Piccoli Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit eec8e868bdc9fb64ba41e0923c49b0cd315ea744 Author: Lin Yujun Date: Wed Sep 14 11:19:53 2022 +0800 slimbus: qcom-ngd: Add error handling in of_qcom_slim_ngd_register [ Upstream commit 42992cf187e4e4bcfe3c58f8fc7b1832c5652d9f ] No error handling is performed when platform_device_add() return fails. Refer to the error handling of driver_set_override(), add error handling for platform_device_add(). Fixes: 917809e2280b ("slimbus: ngd: Add qcom SLIMBus NGD driver") Reviewed-by: Neil Armstrong Signed-off-by: Lin Yujun Link: https://lore.kernel.org/r/20220914031953.94061-1-linyujun809@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e8ce7655fd1f30b783bdae7225a227fd28dd9bbd Author: Krzysztof Kozlowski Date: Fri Sep 16 13:29:10 2022 +0100 slimbus: qcom-ngd-ctrl: allow compile testing without QCOM_RPROC_COMMON [ Upstream commit e291691c69776ad278cd39dec2306dd39d681a9f ] The Qualcomm common remote-proc code (CONFIG_QCOM_RPROC_COMMON) has necessary stubs, so it is not needed for compile testing. Signed-off-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220916122910.170730-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Stable-dep-of: 42992cf187e4 ("slimbus: qcom-ngd: Add error handling in of_qcom_slim_ngd_register") Signed-off-by: Sasha Levin commit a9e9806d1c315bc50dce05479a079b9a104474b8 Author: Nam Cao Date: Mon Sep 12 19:04:31 2022 +0200 staging: vt6655: fix some erroneous memory clean-up loops [ Upstream commit 2a2db520e3ca5aafba7c211abfd397666c9b5f9d ] In some initialization functions of this driver, memory is allocated with 'i' acting as an index variable and increasing from 0. The commit in "Fixes" introduces some clean-up codes in case of allocation failure, which free memory in reverse order with 'i' decreasing to 0. However, there are some problems: - The case i=0 is left out. Thus memory is leaked. - In case memory allocation fails right from the start, the memory freeing loops will start with i=-1 and invalid memory locations will be accessed. One of these loops has been fixed in commit c8ff91535880 ("staging: vt6655: fix potential memory leak"). Fix the remaining erroneous loops. Link: https://lore.kernel.org/linux-staging/Yx9H1zSpxmNqx6Xc@kadam/ Fixes: 5341ee0adb17 ("staging: vt6655: check for memory allocation failures") Reported-by: Dan Carpenter Tested-by: Philipp Hortmann Signed-off-by: Nam Cao Link: https://lore.kernel.org/r/20220912170429.29852-1-namcaov@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2afdd2d9cf279cebffac157b54607dd8f123ff65 Author: Dongliang Mu Date: Wed Sep 14 13:13:33 2022 +0800 phy: qualcomm: call clk_disable_unprepare in the error handling [ Upstream commit c3966ced8eb8dc53b6c8d7f97d32cc8a2107d83e ] Smatch reports the following error: drivers/phy/qualcomm/phy-qcom-usb-hsic.c:82 qcom_usb_hsic_phy_power_on() warn: 'uphy->cal_clk' from clk_prepare_enable() not released on lines: 58. drivers/phy/qualcomm/phy-qcom-usb-hsic.c:82 qcom_usb_hsic_phy_power_on() warn: 'uphy->cal_sleep_clk' from clk_prepare_enable() not released on lines: 58. drivers/phy/qualcomm/phy-qcom-usb-hsic.c:82 qcom_usb_hsic_phy_power_on() warn: 'uphy->phy_clk' from clk_prepare_enable() not released on lines: 58. Fix this by calling proper clk_disable_unprepare calls. Fixes: 0b56e9a7e835 ("phy: Group vendor specific phy drivers") Signed-off-by: Dongliang Mu Reviewed-by: Neil Armstrong Link: https://lore.kernel.org/r/20220914051334.69282-1-dzm91@hust.edu.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d554c14eb73ee91d76fc9aece4616f0b687c295d Author: Sherry Sun Date: Tue Sep 20 19:17:03 2022 +0800 tty: serial: fsl_lpuart: disable dma rx/tx use flags in lpuart_dma_shutdown [ Upstream commit 316ae95c175a7d770d1bfe4c011192712f57aa4a ] lpuart_dma_shutdown tears down lpuart dma, but lpuart_flush_buffer can still occur which in turn tries to access dma apis if lpuart_dma_tx_use flag is true. At this point since dma is torn down, these dma apis can abort. Set lpuart_dma_tx_use and the corresponding rx flag lpuart_dma_rx_use to false in lpuart_dma_shutdown so that dmas are not accessed after they are relinquished. Otherwise, when try to kill btattach, kernel may panic. This patch may fix this issue. root@imx8ulpevk:~# btattach -B /dev/ttyLP2 -S 115200 ^C[ 90.182296] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP [ 90.189806] Modules linked in: moal(O) mlan(O) [ 90.194258] CPU: 0 PID: 503 Comm: btattach Tainted: G O 5.15.32-06136-g34eecdf2f9e4 #37 [ 90.203554] Hardware name: NXP i.MX8ULP 9X9 EVK (DT) [ 90.208513] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 90.215470] pc : fsl_edma3_disable_request+0x8/0x60 [ 90.220358] lr : fsl_edma3_terminate_all+0x34/0x20c [ 90.225237] sp : ffff800013f0bac0 [ 90.228548] x29: ffff800013f0bac0 x28: 0000000000000001 x27: ffff000008404800 [ 90.235681] x26: ffff000008404960 x25: ffff000008404a08 x24: ffff000008404a00 [ 90.242813] x23: ffff000008404a60 x22: 0000000000000002 x21: 0000000000000000 [ 90.249946] x20: ffff800013f0baf8 x19: ffff00000559c800 x18: 0000000000000000 [ 90.257078] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 90.264211] x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000040 [ 90.271344] x11: ffff00000600c248 x10: ffff800013f0bb10 x9 : ffff000057bcb090 [ 90.278477] x8 : fffffc0000241a08 x7 : ffff00000534ee00 x6 : ffff000008404804 [ 90.285609] x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff0000055b3480 [ 90.292742] x2 : ffff8000135c0000 x1 : ffff00000534ee00 x0 : ffff00000559c800 [ 90.299876] Call trace: [ 90.302321] fsl_edma3_disable_request+0x8/0x60 [ 90.306851] lpuart_flush_buffer+0x40/0x160 [ 90.311037] uart_flush_buffer+0x88/0x120 [ 90.315050] tty_driver_flush_buffer+0x20/0x30 [ 90.319496] hci_uart_flush+0x44/0x90 [ 90.323162] +0x34/0x12c [ 90.327253] tty_ldisc_close+0x38/0x70 [ 90.331005] tty_ldisc_release+0xa8/0x190 [ 90.335018] tty_release_struct+0x24/0x8c [ 90.339022] tty_release+0x3ec/0x4c0 [ 90.342593] __fput+0x70/0x234 [ 90.345652] ____fput+0x14/0x20 [ 90.348790] task_work_run+0x84/0x17c [ 90.352455] do_exit+0x310/0x96c [ 90.355688] do_group_exit+0x3c/0xa0 [ 90.359259] __arm64_sys_exit_group+0x1c/0x20 [ 90.363609] invoke_syscall+0x48/0x114 [ 90.367362] el0_svc_common.constprop.0+0xd4/0xfc [ 90.372068] do_el0_svc+0x2c/0x94 [ 90.375379] el0_svc+0x28/0x80 [ 90.378438] el0t_64_sync_handler+0xa8/0x130 [ 90.382711] el0t_64_sync+0x1a0/0x1a4 [ 90.386376] Code: 17ffffda d503201f d503233f f9409802 (b9400041) [ 90.392467] ---[ end trace 2f60524b4a43f1f6 ]--- [ 90.397073] note: btattach[503] exited with preempt_count 1 [ 90.402636] Fixing recursive fault but reboot is needed! Fixes: 6250cc30c4c4 ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx") Reviewed-by: Ilpo Järvinen Signed-off-by: Thara Gopinath Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20220920111703.1532-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 97e79713db81d1662d60edb763b4042ff433ccf4 Author: Ilpo Järvinen Date: Thu Sep 22 10:00:05 2022 +0300 serial: 8250: Toggle IER bits on only after irq has been set up [ Upstream commit 039d4926379b1d1c17b51cf21c500a5eed86899e ] Invoking TIOCVHANGUP on 8250_mid port on Ice Lake-D and then reopening the port triggers these faults during serial8250_do_startup(): DMAR: DRHD: handling fault status reg 3 DMAR: [DMA Write NO_PASID] Request device [00:1a.0] fault addr 0x0 [fault reason 0x05] PTE Write access is not set If the IRQ hasn't been set up yet, the UART will have zeroes in its MSI address/data registers. Disabling the IRQ at the interrupt controller won't stop the UART from performing a DMA write to the address programmed in its MSI address register (zero) when it wants to signal an interrupt. The UARTs (in Ice Lake-D) implement PCI 2.1 style MSI without masking capability, so there is no way to mask the interrupt at the source PCI function level, except disabling the MSI capability entirely, but that would cause it to fall back to INTx# assertion, and the PCI specification prohibits disabling the MSI capability as a way to mask a function's interrupt service request. The MSI address register is zeroed by the hangup as the irq is freed. The interrupt is signalled during serial8250_do_startup() performing a THRE test that temporarily toggles THRI in IER. The THRE test currently occurs before UART's irq (and MSI address) is properly set up. Refactor serial8250_do_startup() such that irq is set up before the THRE test. The current irq setup code is intermixed with the timer setup code. As THRE test must be performed prior to the timer setup, extract it into own function and call it only after the THRE test. The ->setup_timer() needs to be part of the struct uart_8250_ops in order to not create circular dependency between 8250 and 8250_base modules. Fixes: 40b36daad0ac ("[PATCH] 8250 UART backup timer") Reported-by: Lennert Buytenhek Tested-by: Lennert Buytenhek Reviewed-by: Andy Shevchenko Signed-off-by: Ilpo Järvinen Link: https://lore.kernel.org/r/20220922070005.2965-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 737594536dc3ce732976c0d84bb1dcc842065521 Author: Dan Carpenter Date: Thu Sep 22 14:22:47 2022 +0300 drivers: serial: jsm: fix some leaks in probe [ Upstream commit 1d5859ef229e381f4db38dce8ed58e4bf862006b ] This error path needs to unwind instead of just returning directly. Fixes: 03a8482c17dd ("drivers: serial: jsm: Enable support for Digi Classic adapters") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YyxFh1+lOeZ9WfKO@kili Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79c3afb55942368921237d7b5355d48c52bdde20 Author: Dan Carpenter Date: Thu Sep 22 14:22:08 2022 +0300 usb: dwc3: core: fix some leaks in probe [ Upstream commit 2a735e4b5580a2a6bbd6572109b4c4f163c57462 ] The dwc3_get_properties() function calls: dwc->usb_psy = power_supply_get_by_name(usb_psy_name); so there is some additional clean up required on these error paths. Fixes: 6f0764b5adea ("usb: dwc3: add a power supply for current control") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YyxFYFnP53j9sCg+@kili Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 77333f9cc3e151cfaa118b18f2d14ff1e8044e6d Author: Albert Briscoe Date: Sun Sep 11 15:37:55 2022 -0700 usb: gadget: function: fix dangling pnp_string in f_printer.c [ Upstream commit 24b7ba2f88e04800b54d462f376512e8c41b8a3c ] When opts->pnp_string is changed with configfs, new memory is allocated for the string. It does not, however, update dev->pnp_string, even though the memory is freed. When rquesting the string, the host then gets old or corrupted data rather than the new string. The ieee 1284 id string should be allowed to change while the device is connected. The bug was introduced in commit fdc01cc286be ("usb: gadget: printer: Remove pnp_string static buffer"), which changed opts->pnp_string from a char[] to a char*. This patch changes dev->pnp_string from a char* to a char** pointing to opts->pnp_string. Fixes: fdc01cc286be ("usb: gadget: printer: Remove pnp_string static buffer") Signed-off-by: Albert Briscoe Link: https://lore.kernel.org/r/20220911223753.20417-1-albertsbriscoe@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a6ba28c418047b34c1be0b463b9f4e3e46b03c47 Author: Mario Limonciello Date: Wed Sep 21 15:34:47 2022 +0300 xhci: Don't show warning for reinit on known broken suspend [ Upstream commit 484d6f7aa3283d082c87654b7fe7a7f725423dfb ] commit 8b328f8002bc ("xhci: re-initialize the HC during resume if HCE was set") introduced a new warning message when the host controller error was set and re-initializing. This is expected behavior on some designs which already set `xhci->broken_suspend` so the new warning is alarming to some users. Modify the code to only show the warning if this was a surprising behavior to the XHCI driver. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216470 Fixes: 8b328f8002bc ("xhci: re-initialize the HC during resume if HCE was set") Reported-by: Artem S. Tashkinov Signed-off-by: Mario Limonciello Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220921123450.671459-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit df4bf3a2371f7a725fab3ee70f5a8dbde34ac9e6 Author: Daisuke Matsuda Date: Wed Sep 21 17:08:43 2022 +0900 IB: Set IOVA/LENGTH on IB_MR in core/uverbs layers [ Upstream commit 241f9a27e0fc0eaf23e3d52c8450f10648cd11f1 ] Set 'iova' and 'length' on ib_mr in ib_uverbs and ib_core layers to let all drivers have the members filled. Also, this commit removes redundancy in the respective drivers. Previously, commit 04c0a5fcfcf65 ("IB/uverbs: Set IOVA on IB MR in uverbs layer") changed to set 'iova', but seems to have missed 'length' and the ib_core layer at that time. Fixes: 04c0a5fcfcf65 ("IB/uverbs: Set IOVA on IB MR in uverbs layer") Signed-off-by: Daisuke Matsuda Link: https://lore.kernel.org/r/20220921080844.1616883-1-matsuda-daisuke@fujitsu.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 43e2f80cda2988a3dca83e8852683305c2264464 Author: Mark Zhang Date: Thu Sep 8 13:09:02 2022 +0300 RDMA/cm: Use SLID in the work completion as the DLID in responder side [ Upstream commit b7d95040c13f61a4a6a859c5355faf583eff9658 ] The responder should always use WC's SLID as the dlid, to follow the IB SPEC section "13.5.4.2 COMMON RESPONSE ACTIONS": A responder always takes the following actions in constructing a response packet: - The SLID of the received packet is used as the DLID in the response packet. Fixes: ac3a949fb2ff ("IB/CM: Set appropriate slid and dlid when handling CM request") Signed-off-by: Mark Zhang Reviewed-by: Mark Bloch Link: https://lore.kernel.org/r/cd17c240231e059d2fc07c17dfe555d548b917eb.1662631201.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit c0fd5d4d8fd7b1a50306d7a23c720cf808f41fdf Author: David Sloan Date: Thu Sep 8 10:15:14 2022 -0600 md/raid5: Remove unnecessary bio_put() in raid5_read_one_chunk() [ Upstream commit c66a6f41e09ad386fd2cce22b9cded837bbbc704 ] When running chunk-sized reads on disks with badblocks duplicate bio free/puts are observed: ============================================================================= BUG bio-200 (Not tainted): Object already free ----------------------------------------------------------------------------- Allocated in mempool_alloc_slab+0x17/0x20 age=3 cpu=2 pid=7504 __slab_alloc.constprop.0+0x5a/0xb0 kmem_cache_alloc+0x31e/0x330 mempool_alloc_slab+0x17/0x20 mempool_alloc+0x100/0x2b0 bio_alloc_bioset+0x181/0x460 do_mpage_readpage+0x776/0xd00 mpage_readahead+0x166/0x320 blkdev_readahead+0x15/0x20 read_pages+0x13f/0x5f0 page_cache_ra_unbounded+0x18d/0x220 force_page_cache_ra+0x181/0x1c0 page_cache_sync_ra+0x65/0xb0 filemap_get_pages+0x1df/0xaf0 filemap_read+0x1e1/0x700 blkdev_read_iter+0x1e5/0x330 vfs_read+0x42a/0x570 Freed in mempool_free_slab+0x17/0x20 age=3 cpu=2 pid=7504 kmem_cache_free+0x46d/0x490 mempool_free_slab+0x17/0x20 mempool_free+0x66/0x190 bio_free+0x78/0x90 bio_put+0x100/0x1a0 raid5_make_request+0x2259/0x2450 md_handle_request+0x402/0x600 md_submit_bio+0xd9/0x120 __submit_bio+0x11f/0x1b0 submit_bio_noacct_nocheck+0x204/0x480 submit_bio_noacct+0x32e/0xc70 submit_bio+0x98/0x1a0 mpage_readahead+0x250/0x320 blkdev_readahead+0x15/0x20 read_pages+0x13f/0x5f0 page_cache_ra_unbounded+0x18d/0x220 Slab 0xffffea000481b600 objects=21 used=0 fp=0xffff8881206d8940 flags=0x17ffffc0010201(locked|slab|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 0 PID: 34525 Comm: kworker/u24:2 Not tainted 6.0.0-rc2-localyes-265166-gf11c5343fa3f #143 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: raid5wq raid5_do_work Call Trace: dump_stack_lvl+0x5a/0x78 dump_stack+0x10/0x16 print_trailer+0x158/0x165 object_err+0x35/0x50 free_debug_processing.cold+0xb7/0xbe __slab_free+0x1ae/0x330 kmem_cache_free+0x46d/0x490 mempool_free_slab+0x17/0x20 mempool_free+0x66/0x190 bio_free+0x78/0x90 bio_put+0x100/0x1a0 mpage_end_io+0x36/0x150 bio_endio+0x2fd/0x360 md_end_io_acct+0x7e/0x90 bio_endio+0x2fd/0x360 handle_failed_stripe+0x960/0xb80 handle_stripe+0x1348/0x3760 handle_active_stripes.constprop.0+0x72a/0xaf0 raid5_do_work+0x177/0x330 process_one_work+0x616/0xb20 worker_thread+0x2bd/0x6f0 kthread+0x179/0x1b0 ret_from_fork+0x22/0x30 The double free is caused by an unnecessary bio_put() in the if(is_badblock(...)) error path in raid5_read_one_chunk(). The error path was moved ahead of bio_alloc_clone() in c82aa1b76787c ("md/raid5: move checking badblock before clone bio in raid5_read_one_chunk"). The previous code checked and freed align_bio which required a bio_put. After the move that is no longer needed as raid_bio is returned to the control of the common io path which performs its own endio resulting in a double free on bad device blocks. Fixes: c82aa1b76787c ("md/raid5: move checking badblock before clone bio in raid5_read_one_chunk") Signed-off-by: David Sloan Signed-off-by: Logan Gunthorpe Reviewed-by: Christoph Hellwig Acked-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit edce7cb3d8d10996af86d84dd3334242940e8c80 Author: Logan Gunthorpe Date: Thu Aug 25 09:46:27 2022 -0600 md/raid5: Ensure stripe_fill happens on non-read IO with journal [ Upstream commit e2eed85bc75138a9eeb63863d20f8904ac42a577 ] When doing degrade/recover tests using the journal a kernel BUG is hit at drivers/md/raid5.c:4381 in handle_parity_checks5(): BUG_ON(!test_bit(R5_UPTODATE, &dev->flags)); This was found to occur because handle_stripe_fill() was skipped for stripes in the journal due to a condition in that function. Thus blocks were not fetched and R5_UPTODATE was not set when the code reached handle_parity_checks5(). To fix this, don't skip handle_stripe_fill() unless the stripe is for read. Fixes: 07e83364845e ("md/r5cache: shift complex rmw from read path to write path") Link: https://lore.kernel.org/linux-raid/e05c4239-41a9-d2f7-3cfa-4aa9d2cea8c1@deltatee.com/ Suggested-by: Song Liu Signed-off-by: Logan Gunthorpe Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 41ca95033a0c47cd6dace1f0a36a6eb5ebe799e6 Author: Saurabh Sengar Date: Tue Aug 23 11:51:04 2022 -0700 md: Replace snprintf with scnprintf [ Upstream commit 1727fd5015d8f93474148f94e34cda5aa6ad4a43 ] Current code produces a warning as shown below when total characters in the constituent block device names plus the slashes exceeds 200. snprintf() returns the number of characters generated from the given input, which could cause the expression “200 – len” to wrap around to a large positive number. Fix this by using scnprintf() instead, which returns the actual number of characters written into the buffer. [ 1513.267938] ------------[ cut here ]------------ [ 1513.267943] WARNING: CPU: 15 PID: 37247 at /lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510 [ 1513.267944] Modules linked in: [ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu [ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510 <-snip-> [ 1513.267982] Call Trace: [ 1513.267986] snprintf+0x45/0x70 [ 1513.267990] ? disk_name+0x71/0xa0 [ 1513.267993] dump_zones+0x114/0x240 [raid0] [ 1513.267996] ? _cond_resched+0x19/0x40 [ 1513.267998] raid0_run+0x19e/0x270 [raid0] [ 1513.268000] md_run+0x5e0/0xc50 [ 1513.268003] ? security_capable+0x3f/0x60 [ 1513.268005] do_md_run+0x19/0x110 [ 1513.268006] md_ioctl+0x195e/0x1f90 [ 1513.268007] blkdev_ioctl+0x91f/0x9f0 [ 1513.268010] block_ioctl+0x3d/0x50 [ 1513.268012] do_vfs_ioctl+0xa9/0x640 [ 1513.268014] ? __fput+0x162/0x260 [ 1513.268016] ksys_ioctl+0x75/0x80 [ 1513.268017] __x64_sys_ioctl+0x1a/0x20 [ 1513.268019] do_syscall_64+0x5e/0x200 [ 1513.268021] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 766038846e875 ("md/raid0: replace printk() with pr_*()") Reviewed-by: Michael Kelley Acked-by: Guoqing Jiang Signed-off-by: Saurabh Sengar Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit b892ff7dc03e1047acbcca02988fcf36d7a64780 Author: Dan Carpenter Date: Thu Jul 28 10:12:12 2022 +0300 mtd: rawnand: meson: fix bit map use in meson_nfc_ecc_correct() [ Upstream commit 3e4ad3212cf22687410b1e8f4e68feec50646113 ] The meson_nfc_ecc_correct() function accidentally does a right shift instead of a left shift so it only works for BIT(0). Also use BIT_ULL() because "correct_bitmap" is a u64 and we want to avoid shift wrapping bugs. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Dan Carpenter Acked-by: Liang Yang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/YuI2zF1hP65+LE7r@kili Signed-off-by: Sasha Levin commit 9d4c05ea946171dab7a79c87c0121a57ab364f85 Author: Niklas Cassel Date: Fri Sep 16 14:28:35 2022 +0200 ata: fix ata_id_has_dipm() [ Upstream commit 630624cb1b5826d753ac8e01a0e42de43d66dedf ] ACS-5 section 7.13.6.36 Word 78: Serial ATA features supported states that: If word 76 is not 0000h or FFFFh, word 78 reports the features supported by the device. If this word is not supported, the word shall be cleared to zero. (This text also exists in really old ACS standards, e.g. ACS-3.) The problem with ata_id_has_dipm() is that the while it performs a check against 0 and 0xffff, it performs the check against ATA_ID_FEATURE_SUPP (word 78), the same word where the feature bit is stored. Fix this by performing the check against ATA_ID_SATA_CAPABILITY (word 76), like required by the spec. The feature bit check itself is of course still performed against ATA_ID_FEATURE_SUPP (word 78). Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros (which already have this check), thus making it more likely that the next ATA_ID_FEATURE_SUPP macro that is added will include this check. Fixes: ca77329fb713 ("[libata] Link power management infrastructure") Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit cb0e2986c81acca9dc934e954aca78d10e5d833d Author: Niklas Cassel Date: Fri Sep 16 14:28:34 2022 +0200 ata: fix ata_id_has_ncq_autosense() [ Upstream commit a5fb6bf853148974dbde092ec1bde553bea5e49f ] ACS-5 section 7.13.6.36 Word 78: Serial ATA features supported states that: If word 76 is not 0000h or FFFFh, word 78 reports the features supported by the device. If this word is not supported, the word shall be cleared to zero. (This text also exists in really old ACS standards, e.g. ACS-3.) Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros (which already have this check), thus making it more likely that the next ATA_ID_FEATURE_SUPP macro that is added will include this check. Fixes: 5b01e4b9efa0 ("libata: Implement NCQ autosense") Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 23be940d99d007d04ec8d43b255526c1f5ff0ada Author: Niklas Cassel Date: Fri Sep 16 14:28:33 2022 +0200 ata: fix ata_id_has_devslp() [ Upstream commit 9c6e09a434e1317e09b78b3b69cd384022ec9a03 ] ACS-5 section 7.13.6.36 Word 78: Serial ATA features supported states that: If word 76 is not 0000h or FFFFh, word 78 reports the features supported by the device. If this word is not supported, the word shall be cleared to zero. (This text also exists in really old ACS standards, e.g. ACS-3.) Additionally, move the macro to the other ATA_ID_FEATURE_SUPP macros (which already have this check), thus making it more likely that the next ATA_ID_FEATURE_SUPP macro that is added will include this check. Fixes: 65fe1f0f66a5 ("ahci: implement aggressive SATA device sleep support") Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 295ef6a0327d3781e16820fffac177b7df26dded Author: Niklas Cassel Date: Fri Sep 16 14:28:32 2022 +0200 ata: fix ata_id_sense_reporting_enabled() and ata_id_has_sense_reporting() [ Upstream commit 690aa8c3ae308bc696ec8b1b357b995193927083 ] ACS-5 section 7.13.6.41 Words 85..87, 120: Commands and feature sets supported or enabled states that: If bit 15 of word 86 is set to one, bit 14 of word 119 is set to one, and bit 15 of word 119 is cleared to zero, then word 119 is valid. If bit 15 of word 86 is set to one, bit 14 of word 120 is set to one, and bit 15 of word 120 is cleared to zero, then word 120 is valid. (This text also exists in really old ACS standards, e.g. ACS-3.) Currently, ata_id_sense_reporting_enabled() and ata_id_has_sense_reporting() both check bit 15 of word 86, but neither of them check that bit 14 of word 119 is set to one, or that bit 15 of word 119 is cleared to zero. Additionally, make ata_id_sense_reporting_enabled() return false if !ata_id_has_sense_reporting(), similar to how e.g. ata_id_flush_ext_enabled() returns false if !ata_id_has_flush_ext(). Fixes: e87fd28cf9a2 ("libata: Implement support for sense data reporting") Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 74ad141e995a730760b1bcfa14854b7f1057d6bc Author: Bernard Metzler Date: Tue Sep 20 10:25:03 2022 +0200 RDMA/siw: Fix QP destroy to wait for all references dropped. [ Upstream commit a3c278807a459e6f50afee6971cabe74cccfb490 ] Delay QP destroy completion until all siw references to QP are dropped. The calling RDMA core will free QP structure after successful return from siw_qp_destroy() call, so siw must not hold any remaining reference to the QP upon return. A use-after-free was encountered in xfstest generic/460, while testing NFSoRDMA. Here, after a TCP connection drop by peer, the triggered siw_cm_work_handler got delayed until after QP destroy call, referencing a QP which has already freed. Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Reported-by: Olga Kornievskaia Signed-off-by: Bernard Metzler Link: https://lore.kernel.org/r/20220920082503.224189-1-bmt@zurich.ibm.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 0c14f795a9eab9344230f9933798b8ee496f497d Author: Bernard Metzler Date: Tue Sep 20 10:12:02 2022 +0200 RDMA/siw: Always consume all skbuf data in sk_data_ready() upcall. [ Upstream commit 754209850df8367c954ac1de7671c7430b1f342c ] For header and trailer/padding processing, siw did not consume new skb data until minimum amount present to fill current header or trailer structure, including potential payload padding. Not consuming any data during upcall may cause a receive stall, since tcp_read_sock() is not upcalling again if no new data arrive. A NFSoRDMA client got stuck at RDMA Write reception of unaligned payload, if the current skb did contain only the expected 3 padding bytes, but not the 4 bytes CRC trailer. Expecting 4 more bytes already arrived in another skb, and not consuming those 3 bytes in the current upcall left the Write incomplete, waiting for the CRC forever. Fixes: 8b6a361b8c48 ("rdma/siw: receive path") Reported-by: Olga Kornievskaia Tested-by: Olga Kornievskaia Signed-off-by: Bernard Metzler Link: https://lore.kernel.org/r/20220920081202.223629-1-bmt@zurich.ibm.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit f741a9c64e4ede49f99f8fba33570866236796b9 Author: Bart Van Assche Date: Thu Sep 8 16:31:39 2022 -0700 RDMA/srp: Fix srp_abort() [ Upstream commit 6dbe4a8dead84de474483910b02ec9e6a10fc1a9 ] Fix the code for converting a SCSI command pointer into an SRP request pointer. Cc: Xiao Yang Fixes: ad215aaea4f9 ("RDMA/srp: Make struct scsi_cmnd and struct srp_request adjacent") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20220908233139.3042628-1-bvanassche@acm.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit b72d09c3769640cb4f71be229af1f585c5564b0f Author: Shiraz Saleem Date: Wed Sep 7 14:13:24 2022 -0500 RDMA/irdma: Validate udata inlen and outlen [ Upstream commit 34acb833cc83bdea912a160ff99b537e62bb4cf3 ] Currently ib_copy_from_udata and ib_copy_to_udata could underfill the request and response buffer if the user-space passes an undersized value for udata->inlen or udata->outlen respectively [1] This could lead to undesirable behavior. Zero initing the buffer only goes as far as preventing using the buffer uninitialized. Validate udata->inlen and udata->outlen passed from user-space to ensure they are at least the required minimum size. [1] https://lore.kernel.org/linux-rdma/MWHPR11MB0029F37D40D9D4A993F8F549E9D79@MWHPR11MB0029.namprd11.prod.outlook.com/ Fixes: b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs") Reported-by: Dan Carpenter Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20220907191324.1173-3-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 4665894629c82ed7c398b0aceac0e3f74868d320 Author: Sindhu-Devale Date: Wed Sep 7 14:13:23 2022 -0500 RDMA/irdma: Align AE id codes to correct flush code and event [ Upstream commit 7f51a961f8c6b84752a48e950074a8c4a0808d91 ] A number of asynchronous event (AE) ids were not aligned to the correct flush_code and event_type. Fix these up so that the correct IBV error and event codes are returned to application. Also, add handling for new AE ids like IRDMA_AE_INVALID_REQUEST to return the correct WC error code. Fixes: 44d9e52977a1 ("RDMA/irdma: Implement device initialization definitions") Signed-off-by: Sindhu-Devale Signed-off-by: Shiraz Saleem Link: https://lore.kernel.org/r/20220907191324.1173-2-shiraz.saleem@intel.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 5e871bacc5b9a5d1b6e14d46aad2a7810bf611d5 Author: Pali Rohár Date: Thu Jul 7 20:43:28 2022 +0200 mtd: rawnand: fsl_elbc: Fix none ECC mode [ Upstream commit 049e43b9fd8fd2966940485da163d67e96ee3fea ] Commit f6424c22aa36 ("mtd: rawnand: fsl_elbc: Make SW ECC work") added support for specifying ECC mode via DTS and skipping autodetection. But it broke explicit specification of HW ECC mode in DTS as correct settings for HW ECC mode are applied only when NONE mode or nothing was specified in DTS file. Also it started aliasing NONE mode to be same as when ECC mode was not specified and disallowed usage of ON_DIE mode. Fix all these issues. Use autodetection of ECC mode only in case when mode was really not specified in DTS file by checking that ecc value is invalid. Set HW ECC settings either when HW ECC was specified in DTS or it was autodetected. And do not fail when ON_DIE mode is set. Fixes: f6424c22aa36 ("mtd: rawnand: fsl_elbc: Make SW ECC work") Signed-off-by: Pali Rohár Reviewed-by: Marek Behún Reviewed-by: Marek Behún Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220707184328.3845-1-pali@kernel.org Signed-off-by: Sasha Levin commit 5f344bd994da4150b4e41e8d9f90d5a61357cc8c Author: Martin Blumenstingl Date: Sun Jul 3 01:12:23 2022 +0200 mtd: rawnand: intel: Remove undocumented compatible string [ Upstream commit 68c02ebaa34d41063ccbbc789a352537ddc3cd8a ] The "intel,nand-controller" compatible string is not part of the dt-bindings. Remove it from the driver as it's not supposed to be used without any documentation for it. Fixes: 0b1039f016e8a3 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Martin Blumenstingl Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220702231227.1579176-5-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 79cea59c1348dc940a337767d9251a7be5a8d86c Author: Martin Blumenstingl Date: Sun Jul 3 01:12:22 2022 +0200 mtd: rawnand: intel: Read the chip-select line from the correct OF node [ Upstream commit bfc618fcc3f167ad082053e81e9d664e724c6288 ] The chip select has to be read from the flash node which is a child node of the NAND controller. Fixes: 0b1039f016e8a3 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Martin Blumenstingl Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220702231227.1579176-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 876ee3ce4c0286e40785779913260bf5bbefb44c Author: Chunfeng Yun Date: Wed Sep 14 14:07:46 2022 +0800 phy: phy-mtk-tphy: fix the phy type setting issue [ Upstream commit 931c05a8cb1be029ef2fbc1e4af313d4cb297c47 ] The PHY type is not set if the index is non zero, prepare type value according to the index, like as mask value. Fixes: 39099a443358 ("phy: phy-mtk-tphy: support type switch by pericfg") Signed-off-by: Chunfeng Yun Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220914060746.10004-7-chunfeng.yun@mediatek.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit bea05e8f3b7a1b1230e52b7a52c81b1737043013 Author: Liang He Date: Thu Sep 15 17:35:06 2022 +0800 phy: amlogic: phy-meson-axg-mipi-pcie-analog: Hold reference returned by of_get_parent() [ Upstream commit c4c349be07aeec5f397a349046dc5fc0f2657691 ] As the of_get_parent() will increase the refcount of the node->parent and the reference will be discarded, so we should hold the reference with which we can decrease the refcount when done. Fixes: 8eff8b4e22d9 ("phy: amlogic: phy-meson-axg-mipi-pcie-analog: add support for MIPI DSI analog") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220915093506.4009456-1-windhl@126.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d86b5cab8e6b057407d9f988bf6cb54948508542 Author: Dan Carpenter Date: Thu Sep 15 17:11:44 2022 +0300 remoteproc: Harden rproc_handle_vdev() against integer overflow [ Upstream commit 7d7f8fe4e399519cc9ac68a475fec6d3a996341b ] The struct_size() macro protects against integer overflows but adding "+ rsc->config_len" introduces the risk of integer overflows again. Use size_add() to be safe. Fixes: c87846571587 ("remoteproc: use struct_size() helper") Signed-off-by: Dan Carpenter Reviewed-by: Gustavo A. R. Silva Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/YyMyoPoGOJUcEpZT@kili Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit e51207113b368851bd83f1554726f0047b026c12 Author: William Dean Date: Fri Jul 22 17:16:44 2022 +0800 mtd: devices: docg3: check the return value of devm_ioremap() in the probe [ Upstream commit 26e784433e6c65735cd6d93a8db52531970d9a60 ] The function devm_ioremap() in docg3_probe() can fail, so its return value should be checked. Fixes: 82402aeb8c81e ("mtd: docg3: Use devm_*() functions") Reported-by: Hacash Robot Signed-off-by: William Dean Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220722091644.2937953-1-williamsukatube@163.com Signed-off-by: Sasha Levin commit f5e41e860a3a75e2dd5768b0d0a79d6e36db2e3c Author: Dang Huynh Date: Sun Sep 11 00:02:07 2022 +0700 clk: qcom: sm6115: Select QCOM_GDSC [ Upstream commit 50ee65dc512b9b5c4de354cf3b4dded34f46c571 ] While working on the Fxtec Pro1X device, this error shows up with my own minimal configuration: gcc-sm6115: probe of 1400000.clock-controller failed with error -38 The clock driver depends on CONFIG_QCOM_GDSC and after enabling that, the driver probes successfully. Signed-off-by: Dang Huynh Fixes: cbe63bfdc54f ("clk: qcom: Add Global Clock controller (GCC) Reviewed-by: Dmitry Baryshkov Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220910170207.1592220-1-danct12@riseup.net Signed-off-by: Sasha Levin commit d074a8721b40e53c973381641c6284c6d3131b01 Author: Jim Cromie Date: Sun Sep 4 15:40:46 2022 -0600 dyndbg: drop EXPORTed dynamic_debug_exec_queries [ Upstream commit e26ef3af964acfea311403126acee8c56c89e26b ] This exported fn is unused, and will not be needed. Lets dump it. The export was added to let drm control pr_debugs, as part of using them to avoid drm_debug_enabled overheads. But its better to just implement the drm.debug bitmap interface, then its available for everyone. Fixes: a2d375eda771 ("dyndbg: refine export, rename to dynamic_debug_exec_queries()") Fixes: 4c0d77828d4f ("dyndbg: export ddebug_exec_queries") Acked-by: Jason Baron Acked-by: Daniel Vetter Signed-off-by: Jim Cromie Link: https://lore.kernel.org/r/20220904214134.408619-10-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a5389101936ae556f4c32cc12bb83743901405d5 Author: Jim Cromie Date: Sun Sep 4 15:40:44 2022 -0600 dyndbg: let query-modname override actual module name [ Upstream commit e75ef56f74965f426dd819a41336b640ffdd8fbc ] dyndbg's control-parser: ddebug_parse_query(), requires that search terms: module, func, file, lineno, are used only once in a query; a thing cannot be named both foo and bar. The cited commit added an overriding module modname, taken from the module loader, which is authoritative. So it set query.module 1st, which disallowed its use in the query-string. But now, its useful to allow a module-load to enable classes across a whole (or part of) a subsystem at once. # enable (dynamic-debug in) drm only modprobe drm dyndbg="class DRM_UT_CORE +p" # get drm_helper too modprobe drm dyndbg="class DRM_UT_CORE module drm* +p" # get everything that knows DRM_UT_CORE modprobe drm dyndbg="class DRM_UT_CORE module * +p" # also for boot-args: drm.dyndbg="class DRM_UT_CORE module * +p" So convert the override into a default, by filling it only when/after the query-string omitted the module. NB: the query class FOO handling is forthcoming. Fixes: 8e59b5cfb9a6 dynamic_debug: add modname arg to exec_query callchain Acked-by: Jason Baron Acked-by: Daniel Vetter Signed-off-by: Jim Cromie Link: https://lore.kernel.org/r/20220904214134.408619-8-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6fe65c4de7f1cf27b4c0f779d64e4dbdba959826 Author: Jim Cromie Date: Sun Sep 4 15:40:39 2022 -0600 dyndbg: fix module.dyndbg handling [ Upstream commit 85d6b66d31c35158364058ee98fb69ab5bb6a6b1 ] For CONFIG_DYNAMIC_DEBUG=N, the ddebug_dyndbg_module_param_cb() stub-fn is too permissive: bash-5.1# modprobe drm JUNKdyndbg bash-5.1# modprobe drm dyndbgJUNK [ 42.933220] dyndbg param is supported only in CONFIG_DYNAMIC_DEBUG builds [ 42.937484] ACPI: bus type drm_connector registered This caused no ill effects, because unknown parameters are either ignored by default with an "unknown parameter" warning, or ignored because dyndbg allows its no-effect use on non-dyndbg builds. But since the code has an explicit feedback message, it should be issued accurately. Fix with strcmp for exact param-name match. Fixes: b48420c1d301 dynamic_debug: make dynamic-debug work for module initialization Reported-by: Rasmus Villemoes Acked-by: Jason Baron Acked-by: Daniel Vetter Signed-off-by: Jim Cromie Link: https://lore.kernel.org/r/20220904214134.408619-3-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7059d5c462fb694ef3e0c694214305af30263d08 Author: Jim Cromie Date: Sun Sep 4 15:40:38 2022 -0600 dyndbg: fix static_branch manipulation [ Upstream commit ee879be38bc87f8cedc79ae2742958db6533ca59 ] In https://lore.kernel.org/lkml/20211209150910.GA23668@axis.com/ Vincent's patch commented on, and worked around, a bug toggling static_branch's, when a 2nd PRINTK-ish flag was added. The bug results in a premature static_branch_disable when the 1st of 2 flags was disabled. The cited commit computed newflags, but then in the JUMP_LABEL block, failed to use that result, instead using just one of the terms in it. Using newflags instead made the code work properly. This is Vincents test-case, reduced. It needs the 2nd flag to demonstrate the bug, but it's explanatory here. pt_test() { echo 5 > /sys/module/dynamic_debug/verbose site="module tcp" # just one callsite echo " $site =_ " > /proc/dynamic_debug/control # clear it # A B ~A ~B for flg in +T +p "-T #broke here" -p; do echo " $site $flg " > /proc/dynamic_debug/control done; # A B ~B ~A for flg in +T +p "-p #broke here" -T; do echo " $site $flg " > /proc/dynamic_debug/control done } pt_test Fixes: 84da83a6ffc0 dyndbg: combine flags & mask into a struct, simplify with it CC: vincent.whitchurch@axis.com Acked-by: Jason Baron Acked-by: Daniel Vetter Signed-off-by: Jim Cromie Link: https://lore.kernel.org/r/20220904214134.408619-2-jim.cromie@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0cb8d0d420d464b8ad8685357e57784887243b35 Author: Dan Carpenter Date: Thu Sep 1 17:59:42 2022 +0300 usb: gadget: f_fs: stricter integer overflow checks [ Upstream commit f57004b9d96755cd6a243b51c267be4016b4563c ] This from static analysis. The vla_item() takes a size and adds it to the total. It has a built in integer overflow check so if it encounters an integer overflow anywhere then it records the total as SIZE_MAX. However there is an issue here because the "lang_count*(needed_count+1)" multiplication can overflow. Technically the "lang_count + 1" addition could overflow too, but that would be detected and is harmless. Fix both using the new size_add() and size_mul() functions. Fixes: e6f3862fa1ec ("usb: gadget: FunctionFS: Remove VLAIS usage from gadget code") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YxDI3lMYomE7WCjn@kili Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d4a8ec5cc7ff5d442bd49a44f26d74b2021ba4c8 Author: Jie Hai Date: Tue Aug 30 14:22:47 2022 +0800 dmaengine: hisilicon: Add multi-thread support for a DMA channel [ Upstream commit 2cbb95883c990d0002a77e13d3278913ab26ad79 ] When we get a DMA channel and try to use it in multiple threads it will cause oops and hanging the system. % echo 100 > /sys/module/dmatest/parameters/threads_per_chan % echo 100 > /sys/module/dmatest/parameters/iterations % echo 1 > /sys/module/dmatest/parameters/run [383493.327077] Unable to handle kernel paging request at virtual address dead000000000108 [383493.335103] Mem abort info: [383493.335103] ESR = 0x96000044 [383493.335105] EC = 0x25: DABT (current EL), IL = 32 bits [383493.335107] SET = 0, FnV = 0 [383493.335108] EA = 0, S1PTW = 0 [383493.335109] FSC = 0x04: level 0 translation fault [383493.335110] Data abort info: [383493.335111] ISV = 0, ISS = 0x00000044 [383493.364739] CM = 0, WnR = 1 [383493.367793] [dead000000000108] address between user and kernel address ranges [383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP [383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump: loaded Tainted: GO 5.17.0-rc4+ #2 [383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [383493.465331] pc : vchan_tx_submit+0x64/0xa0 [383493.469957] lr : vchan_tx_submit+0x34/0xa0 This occurs because the transmission timed out, and that's due to data race. Each thread rewrite channels's descriptor as soon as device_issue_pending is called. It leads to the situation that the driver thinks that it uses the right descriptor in interrupt handler while channels's descriptor has been changed by other thread. The descriptor which in fact reported interrupt will not be handled any more, as well as its tx->callback. That's why timeout reports. With current fixes channels' descriptor changes it's value only when it has been used. A new descriptor is acquired from vc->desc_issued queue that is already filled with descriptors that are ready to be sent. Threads have no direct access to DMA channel descriptor. In case of channel's descriptor is busy, try to submit to HW again when a descriptor is completed. In this case, vc->desc_issued may be empty when hisi_dma_start_transfer is called, so delete error reporting on this. Now it is just possible to queue a descriptor for further processing. Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by: Jie Hai Acked-by: Zhou Wang Link: https://lore.kernel.org/r/20220830062251.52993-4-haijie1@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 60d48e197289323c96e2ba820db1da935409b3b1 Author: Jie Hai Date: Tue Aug 30 14:22:46 2022 +0800 dmaengine: hisilicon: Fix CQ head update [ Upstream commit 94477a79cf80e8ab55b68f14bc579a12ddea1e0b ] After completion of data transfer of one or multiple descriptors, the completion status and the current head pointer to submission queue are written into the CQ and interrupt can be generated to inform the software. In interrupt process CQ is read and cq_head is updated. hisi_dma_irq updates cq_head only when the completion status is success. When an abnormal interrupt reports, cq_head will not update which will cause subsequent interrupt processes read the error CQ and never report the correct status. This patch updates cq_head whenever CQ is accessed. Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by: Jie Hai Acked-by: Zhou Wang Link: https://lore.kernel.org/r/20220830062251.52993-3-haijie1@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 435c85735572b3a8b7ad245c88c4ed06f6de378a Author: Jie Hai Date: Tue Aug 30 14:22:45 2022 +0800 dmaengine: hisilicon: Disable channels when unregister hisi_dma [ Upstream commit e3bdaa04ada31f46d0586df83a2789b8913053c5 ] When hisi_dma is unloaded or unbinded, all of channels should be disabled. This patch disables DMA channels when driver is unloaded or unbinded. Fixes: e9f08b65250d ("dmaengine: hisilicon: Add Kunpeng DMA engine support") Signed-off-by: Jie Hai Acked-by: Zhou Wang Link: https://lore.kernel.org/r/20220830062251.52993-2-haijie1@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4b05c3e771a6fc8744323e214cc050a1f63e960e Author: Jerry Snitselaar Date: Tue Aug 23 09:37:09 2022 -0700 dmaengine: idxd: avoid deadlock in process_misc_interrupts() [ Upstream commit 407171717a4f4d2d80825584643374a2dfdb0540 ] idxd_device_clear_state() now grabs the idxd->dev_lock itself, so don't grab the lock prior to calling it. This was seen in testing after dmar fault occurred on system, resulting in lockup stack traces. Cc: Fenghua Yu Cc: Dave Jiang Cc: Vinod Koul Cc: dmaengine@vger.kernel.org Fixes: cf4ac3fef338 ("dmaengine: idxd: fix lockdep warning on device driver removal") Signed-off-by: Jerry Snitselaar Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20220823163709.2102468-1-jsnitsel@redhat.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 6afdab9bdad1a44f86123e9ca4aeab16c27f80b5 Author: Peter Geis Date: Fri Sep 2 14:45:42 2022 -0400 phy: rockchip-inno-usb2: Return zero after otg sync [ Upstream commit f340ed8664a55a467850ec1689996e63d9ee971a ] The otg sync state patch reuses the ret variable, but fails to set it to zero after use. This leads to a situation when the otg port is in peripheral mode where the otg phy aborts halfway through setup. It also fails to account for a failure to register the extcon notifier. Fix this by using our own variable and skipping otg sync in case of failure. Fixes: 8dc60f8da22f ("phy: rockchip-inno-usb2: Sync initial otg state") Reported-by: Markus Reichl Reported-by: Michael Riesch Signed-off-by: Peter Geis Tested-by: Michael Riesch Tested-by: Markus Reichl Reviewed-by: Samuel Holland Link: https://lore.kernel.org/r/20220902184543.1234835-1-pgwipeout@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 1b5a931594f7ffd26d706614c37d4da0f2ffb6e7 Author: Dan Carpenter Date: Thu Sep 1 08:18:45 2022 +0300 fpga: prevent integer overflow in dfl_feature_ioctl_set_irq() [ Upstream commit 939bc5453b8cbdde9f1e5110ce8309aedb1b501a ] The "hdr.count * sizeof(s32)" multiplication can overflow on 32 bit systems leading to memory corruption. Use array_size() to fix that. Fixes: 322b598be4d9 ("fpga: dfl: introduce interrupt trigger setting API") Signed-off-by: Dan Carpenter Acked-by: Xu Yilun Link: https://lore.kernel.org/r/YxBAtYCM38dM7yzI@kili Signed-off-by: Xu Yilun Signed-off-by: Sasha Levin commit 843433a02e344d30fbb62dfd834c60631baaa527 Author: Hangyu Hua Date: Wed Aug 24 16:26:00 2022 +0800 misc: ocxl: fix possible refcount leak in afu_ioctl() [ Upstream commit c3b69ba5114c860d730870c03ab4ee45276e5e35 ] eventfd_ctx_put need to be called to put the refcount that gotten by eventfd_ctx_fdget when ocxl_irq_set_handler fails. Fixes: 060146614643 ("ocxl: move event_fd handling to frontend") Acked-by: Frederic Barrat Signed-off-by: Hangyu Hua Link: https://lore.kernel.org/r/20220824082600.36159-1-hbh25y@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a02209e256d393db118d700946aedb3acd76c0a Author: AngeloGioacchino Del Regno Date: Tue Jul 19 11:33:16 2022 +0200 clk: mediatek: mt8195-infra_ao: Set pwrmcu clocks as critical [ Upstream commit 3f10f49cd9f8ab6471639d4ca2c6db9451121779 ] The pwrmcu is responsible for power management and idle states in SSPM: on older SoCs this was managed in Linux drivers like sspm/mcupm/eemgpu but, at least on MT8195, this functionality was transferred to the ATF firmware. For this reason, turning off the pwrmcu related clocks from the kernel will lead to unability to resume the platform after suspend and other currently unknown PM related side-effects. Set the PWRMCU and PWRMCU_BUS_H clocks as critical to prevent the kernel from turning them off, fixing the aforementioned issue. Fixes: e2edf59dec0b ("clk: mediatek: Add MT8195 infrastructure clock support") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220719093316.37253-1-angelogioacchino.delregno@collabora.com Reviewed-by: Matthias Brugger Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f6794d82c0d52ca7be32302dfe8208a9f95bf60f Author: AngeloGioacchino Del Regno Date: Tue Aug 16 15:32:56 2022 -0400 clk: mediatek: clk-mt8195-vdo1: Reparent and set rate on vdo1_dpintf's parent [ Upstream commit f24d71feb206631116ff9adaa6d43650c5dd8849 ] Like it was done for the vdo0_dp_intf0_dp_intf clock (used for eDP), add the CLK_SET_RATE_PARENT flag to CLK_VDO1_DPINTF (used for DP) and also fix its parent clock name as it has to be "top_dp" for two reasons: - This is its real parent! - Likewise to eDP/VDO0 counterpart, we need clock source selection on CLK_TOP_DP. Fixes: 269987505ba9 ("clk: mediatek: Add MT8195 vdosys1 clock support") Signed-off-by: AngeloGioacchino Del Regno Tested-by: Bo-Chen Chen Reviewed-by: Bo-Chen Chen Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220816193257.658487-3-nfraprado@collabora.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 79b90df9b9e8ec11aa0ca2eada12d9cf2ef57204 Author: AngeloGioacchino Del Regno Date: Tue Aug 16 15:32:55 2022 -0400 clk: mediatek: clk-mt8195-vdo0: Set rate on vdo0_dp_intf0_dp_intf's parent [ Upstream commit 3f0dadd230cc2630202a977fe52cd1dd7a7579a7 ] Add the CLK_SET_RATE_PARENT flag to the CLK_VDO0_DP_INTF0_DP_INTF clock: this is required to trigger clock source selection on CLK_TOP_EDP, while avoiding to manage the enablement of the former separately from the latter in the displayport driver. Fixes: 70282c90d4a2 ("clk: mediatek: Add MT8195 vdosys0 clock support") Signed-off-by: AngeloGioacchino Del Regno Tested-by: Bo-Chen Chen Reviewed-by: Bo-Chen Chen Signed-off-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220816193257.658487-2-nfraprado@collabora.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit aedd895b3820a9b0125fb1e5749368cd482cd374 Author: Zhu Yanjun Date: Sun Aug 21 21:16:14 2022 -0400 RDMA/rxe: Fix the error caused by qp->sk [ Upstream commit 548ce2e66725dcba4e27d1e8ac468d5dd17fd509 ] When sock_create_kern in the function rxe_qp_init_req fails, qp->sk is set to NULL. Then the function rxe_create_qp will call rxe_qp_do_cleanup to handle allocated resource. Before handling qp->sk, this variable should be checked. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20220822011615.805603-3-yanjun.zhu@linux.dev Signed-off-by: Zhu Yanjun Reviewed-by: Li Zhijian Reviewed-by: Bob Pearson Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit bb33fa65da77f5f02dbee6f25cebaeedfcd70028 Author: Zhu Yanjun Date: Sun Aug 21 21:16:13 2022 -0400 RDMA/rxe: Fix "kernel NULL pointer dereference" error [ Upstream commit a625ca30eff806395175ebad3ac1399014bdb280 ] When rxe_queue_init in the function rxe_qp_init_req fails, both qp->req.task.func and qp->req.task.arg are not initialized. Because of creation of qp fails, the function rxe_create_qp will call rxe_qp_do_cleanup to handle allocated resource. Before calling __rxe_do_task, both qp->req.task.func and qp->req.task.arg should be checked. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20220822011615.805603-2-yanjun.zhu@linux.dev Reported-by: syzbot+ab99dc4c6e961eed8b8e@syzkaller.appspotmail.com Signed-off-by: Zhu Yanjun Reviewed-by: Li Zhijian Reviewed-by: Bob Pearson Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 22b93530bbe6af9dce8e520bb6e978d1bda39d2b Author: Miaoqian Lin Date: Wed Jun 1 06:25:14 2022 +0200 media: xilinx: vipp: Fix refcount leak in xvip_graph_dma_init [ Upstream commit 1c78f19c3a0ea312a8178a6bfd8934eb93e9b10a ] of_get_child_by_name() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: df3305156f98 ("[media] v4l: xilinx: Add Xilinx Video IP core") Signed-off-by: Miaoqian Lin Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1b2f6d1d5abf41257d09509fb2bfe86374c581fd Author: Yunke Cao Date: Thu Jul 7 10:53:31 2022 +0200 media: uvcvideo: Use entity get_cur in uvc_ctrl_set [ Upstream commit 5f36851c36b30f713f588ed2b60aa7b4512e2c76 ] Entity controls should get_cur using an entity-defined function instead of via a query. Fix this in uvc_ctrl_set. Fixes: 65900c581d01 ("media: uvcvideo: Allow entity-defined get_info and get_cur") Signed-off-by: Yunke Cao Reviewed-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit deb8f32ae4b10a48c433f2da1b1159521ac24674 Author: José Expósito Date: Sat Jan 8 18:04:39 2022 +0100 media: uvcvideo: Fix memory leak in uvc_gpio_parse [ Upstream commit f0f078457f18f10696888f8d0e6aba9deb9cde92 ] Previously the unit buffer was allocated before checking the IRQ for privacy GPIO. In case of error, the unit buffer was leaked. Allocate the unit buffer after the IRQ to avoid it. Addresses-Coverity-ID: 1474639 ("Resource leak") Fixes: 2886477ff987 ("media: uvcvideo: Implement UVC_EXT_GPIO_UNIT") Signed-off-by: José Expósito Reviewed-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 73bf38baa8acd0fee8ef2e0cd3a337103567cc35 Author: Xu Qiang Date: Thu Aug 18 08:57:53 2022 +0200 media: meson: vdec: add missing clk_disable_unprepare on error in vdec_hevc_start() [ Upstream commit 4029372233e13e281f8c387f279f9f064ced3810 ] Add the missing clk_disable_unprepare() before return from vdec_hevc_start() in the error handling case. Fixes: 823a7300340e (“media: meson: vdec: add common HEVC decoder support”) Signed-off-by: Xu Qiang Reviewed-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 325de494d8ce4d595849e83dc1bc856e30b83c4e Author: Ming Qian Date: Thu Aug 18 05:18:21 2022 +0200 media: amphion: fix a bug that vpu core may not resume after suspend [ Upstream commit 0202a665bf17fbe98fed954944aabbcb4f14a4cc ] driver will enable the vpu core when request the first instance on the core. one vpu core can only support 8 streaming instances in the same time, the instance won't be added to core's list before streamon. so the actual instance count may be greater then the number in the core's list. in pm resume callback, driver will resume the core immediately if core's list is not empty. but this check is not accurate, if suspend during one instance is requested, but not streamon, then after suspend, the core won't be resume, and led to instance failure. use the request_count instead of the core's list to check whether is the core needed to resume immediately after suspend. And it can make the pm suspend and resume callback more clear. Fixes: 9f599f351e86 ("media: amphion: add vpu core driver") Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 47fd2c400869a29f0fbc2837207a04f49665d3d3 Author: Ming Qian Date: Tue Jul 26 05:02:29 2022 +0200 media: amphion: don't change the colorspace reported by decoder. [ Upstream commit 61c2698ee60630c6a7d2e99850fa81ff6450270a ] decoder will report the colorspace information which is parsed from the sequence header, if they are unspecified, just let application to determine it, don't change it in driver. Fixes: 6de8d628df6ef ("media: amphion: add v4l2 m2m vpu decoder stateful driver") Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 50c335d997738b17bb42c6cbc9a5771caabb54d4 Author: Ming Qian Date: Fri Jul 15 09:38:00 2022 +0200 media: amphion: adjust the encoder's value range of gop size [ Upstream commit 996f4e89fabe44ab9ac0aabb0697aeecbe717eca ] adjust the value range of gop size from [0, 65535] to [1, 8000]. when the gop size is set to a too large value, it may affect the encoded picture quality. so constrain it to a reasonable range. Fixes: 0401e659c1f92 ("media: amphion: add v4l2 m2m vpu encoder stateful driver") Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 96fe4befacef40dd9cc37da4de60c5dda9e13764 Author: Ming Qian Date: Fri Jul 15 09:15:49 2022 +0200 media: amphion: insert picture startcode after seek for vc1g format [ Upstream commit f7fd6c318c8a5d06bf3fe611f30763d62eaaf7f0 ] For format vc1, the amphion vpu requires driver to help insert some custom startcode before sequence and frame. the startcode is different for vc1l and vc1g format. But the sequence startcode is only needed at the beginning, and it's not expected after seek. driver need to treat the codec header and the first frame after seek as a normal frame, and insert picture startcode for it. In previous patch, I just fix it for vc1l format, and should fix the similar issue for vc1g too. Fixes: e670f5d672ef (media: amphion: only insert the first sequence startcode for vc1l format) Signed-off-by: Ming Qian Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e15db9a24df13708d60eee9bb904b7c2ff44c5d8 Author: Shubhrajyoti Datta Date: Fri Jul 29 17:17:45 2022 +0530 tty: xilinx_uartps: Fix the ignore_status [ Upstream commit b8a6c3b3d4654fba19881cc77da61eac29f57cae ] Currently the ignore_status is not considered in the isr. Add a check to add the ignore_status. Fixes: 61ec9016988f ("tty/serial: add support for Xilinx PS UART") Signed-off-by: Shubhrajyoti Datta Link: https://lore.kernel.org/r/20220729114748.18332-5-shubhrajyoti.datta@xilinx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9eabf73391b6f783560afea7d50bc5700b8d1c6d Author: Liang He Date: Wed Jul 20 16:30:03 2022 +0200 media: exynos4-is: fimc-is: Add of_node_put() when breaking out of loop [ Upstream commit 211f8304fa21aaedc2c247f0c9d6c7f1aaa61ad7 ] In fimc_is_register_subdevs(), we need to call of_node_put() for the reference 'i2c_bus' when breaking out of the for_each_compatible_node() which has increased the refcount. Fixes: 9a761e436843 ("[media] exynos4-is: Add Exynos4x12 FIMC-IS driver") Signed-off-by: Liang He Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 99e30bd761c5c96665281c4e3aefe031c0ced255 Author: Marijn Suijten Date: Thu Jul 14 22:38:22 2022 +0200 clk: qcom: gcc-sdm660: Use floor ops for SDCC1 clock [ Upstream commit 6956c18f4ad9200aa945f7ea37d65a05afc49d51 ] In commit 3f905469c8ce ("clk: qcom: gcc: Use floor ops for SDCC clocks") floor ops were applied to SDCC2 only, but flooring is also required on the SDCC1 apps clock which is used by the eMMC card on Sony's Nile platform, and otherwise result in the typicial "Card appears overclocked" warnings observed on many other platforms before: mmc0: Card appears overclocked; req 52000000 Hz, actual 100000000 Hz mmc0: Card appears overclocked; req 52000000 Hz, actual 100000000 Hz mmc0: Card appears overclocked; req 104000000 Hz, actual 192000000 Hz Fixes: f2a76a2955c0 ("clk: qcom: Add Global Clock controller (GCC) driver for SDM660") Signed-off-by: Marijn Suijten Tested-by: Alexey Minnekhanov Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220714203822.186448-1-marijn.suijten@somainline.org Signed-off-by: Sasha Levin commit fcc076fecca631db430b8c8d19a31bc587088170 Author: Jack Wang Date: Fri Aug 26 12:12:27 2022 +0200 HSI: omap_ssi_port: Fix dma_map_sg error check [ Upstream commit 551e325bbd3fb8b5a686ac1e6cf76e5641461cf2 ] dma_map_sg return 0 on error, in case of error return -EIO to caller. Cc: Sebastian Reichel Cc: linux-kernel@vger.kernel.org (open list) Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver") Signed-off-by: Jack Wang Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit e25f56f8bdf66126a54b5a88bc021c82bfb50b75 Author: Miaoqian Lin Date: Mon Apr 4 08:52:32 2022 +0000 HSI: omap_ssi: Fix refcount leak in ssi_probe [ Upstream commit 9a2ea132df860177b33c9fd421b26c4e9a0a9396 ] When returning or breaking early from a for_each_available_child_of_node() loop, we need to explicitly call of_node_put() on the child node to possibly release the node. Fixes: b209e047bc74 ("HSI: Introduce OMAP SSI driver") Signed-off-by: Miaoqian Lin Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 00f6ce0d1baf86bdb024b26267ae8f52e90f7734 Author: Chanho Park Date: Wed Jul 27 11:13:57 2022 +0900 clk: samsung: exynosautov9: correct register offsets of peric0/c1 [ Upstream commit 67d98943408bce835185688cb75ebbb45b91e572 ] Some register offsets of peric0 and peric1 cmu blocks need to be corrected and re-ordered by numerical order. Fixes: f2dd366992d0 ("clk: samsung: exynosautov9: add cmu_peric0 clock support") Fixes: b35f27fe73d8 ("clk: samsung: exynosautov9: add cmu_peric1 clock support") Signed-off-by: Chanho Park Reviewed-by: Krzysztof Kozlowski Acked-by: Chanwoo Choi Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220727021357.152421-4-chanho61.park@samsung.com Signed-off-by: Sasha Levin commit 8cd228892759d37f36a46616025f4fa0d0a63b5d Author: Miaoqian Lin Date: Mon May 23 19:28:11 2022 +0400 clk: tegra20: Fix refcount leak in tegra20_clock_init [ Upstream commit 4e343bafe03ff68a62f48f8235cf98f2c685468b ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 37c26a906527 ("clk: tegra: add clock support for Tegra20") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220523152811.19692-1-linmq006@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 8e1fe30253930c6a67385c19802c5ab8706a76d9 Author: Miaoqian Lin Date: Mon May 23 18:38:34 2022 +0400 clk: tegra: Fix refcount leak in tegra114_clock_init [ Upstream commit db16a80c76ea395766913082b1e3f939dde29b2c ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 2cb5efefd6f7 ("clk: tegra: Implement clocks for Tegra114") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220523143834.7587-1-linmq006@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1a6d97139b0a370a9d0809a00e91c41f5bcd3ef1 Author: Miaoqian Lin Date: Mon May 23 18:26:08 2022 +0400 clk: tegra: Fix refcount leak in tegra210_clock_init [ Upstream commit 56c78cb1f00a9dde8cd762131ce8f4c5eb046fbb ] of_find_matching_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when not need anymore. Add missing of_node_put() to avoid refcount leak. Fixes: 6b301a059eb2 ("clk: tegra: Add support for Tegra210 clocks") Signed-off-by: Miaoqian Lin Link: https://lore.kernel.org/r/20220523142608.65074-1-linmq006@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit a065f836c9380a03c81b0c712964c05417c91d58 Author: Liang He Date: Mon Jul 4 08:47:29 2022 +0800 clk: sprd: Hold reference returned by of_get_parent() [ Upstream commit 91e6455bf715fb1558a0bf8f645ec1c131254a3c ] We should hold the reference returned by of_get_parent() and use it to call of_node_put() for refcount balance. Fixes: f95e8c7923d1 ("clk: sprd: support to get regmap from parent node") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220704004729.272481-1-windhl@126.com Reviewed-by: Orson Zhai Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2c4137393bcf73e6bdbc94318660e9c59fe0e653 Author: Liang He Date: Fri Jul 8 16:49:00 2022 +0800 clk: berlin: Add of_node_put() for of_get_parent() [ Upstream commit 37c381b812dcbfde9c3f1f3d3e75fdfc1b40d5bc ] In berlin2_clock_setup() and berlin2q_clock_setup(), we need to call of_node_put() for the reference returned by of_get_parent() which has increased the refcount. We should call *_put() in fail path or when it is not used anymore. Fixes: 26b3b6b959b2 ("clk: berlin: prepare simple-mfd conversion") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220708084900.311684-1-windhl@126.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 42ecb6c427ee602398b23f1305681986ba4fe7e3 Author: Liang He Date: Tue Jun 28 22:38:51 2022 +0800 clk: qoriq: Hold reference returned by of_get_parent() [ Upstream commit a8ea4273bc26256ce3cce83164f0f51c5bf6e127 ] In legacy_init_clockgen(), we need to hold the reference returned by of_get_parent() and use it to call of_node_put() for refcount balance. Beside, in create_sysclk(), we need to call of_node_put() on 'sysclk' also for refcount balance. Fixes: 0dfc86b3173f ("clk: qoriq: Move chip-specific knowledge into driver") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220628143851.171299-1-windhl@126.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 23e0893862ba592b8ae3e83de8c2ae7bac40efaa Author: Liang He Date: Tue Jun 28 22:31:55 2022 +0800 clk: oxnas: Hold reference returned by of_get_parent() [ Upstream commit 1d6aa08c54cd0e005210ab8e3b1e92ede70f8a4f ] In oxnas_stdclk_probe(), we need to hold the reference returned by of_get_parent() and use it to call of_node_put() for refcount balance. Fixes: 0bbd72b4c64f ("clk: Add Oxford Semiconductor OXNAS Standard Clocks") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220628143155.170550-1-windhl@126.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 3c3292f490e7e8c3eb9072f97fb194ef806f79ec Author: Liang He Date: Tue Jun 28 22:24:15 2022 +0800 clk: st: Hold reference returned by of_get_parent() [ Upstream commit 429973306f860470cbbb8402c8c53143b450faba ] We should hold the reference returned by of_get_parent() and use it to call of_node_put() for refcount balance. Fixes: 3efe64ef5186 ("clk: st: clkgen-fsyn: search reg within node or parent") Fixes: 810251b0d36a ("clk: st: clkgen-mux: search reg within node or parent") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220628142416.169808-1-windhl@126.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 0068ca80dcfaf628df4f39ef7fde7b64ccb24fe8 Author: Liang He Date: Tue Jun 28 22:10:38 2022 +0800 clk: meson: Hold reference returned by of_get_parent() [ Upstream commit 89ab396d712f7c91fe94f55cff23460426f5fc81 ] We should hold the reference returned by of_get_parent() and use it to call of_node_put() for refcount balance. Fixes: 88e2da81241e ("clk: meson: aoclk: refactor common code into dedicated file") Fixes: 6682bd4d443f ("clk: meson: factorise meson64 peripheral clock controller drivers") Fixes: bb6eddd1d28c ("clk: meson: meson8b: use the HHI syscon if available") Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220628141038.168383-1-windhl@126.com Reviewed-by: Neil Armstrong Reviewed-by: Martin Blumenstingl Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 40c485c8b1f741f47835497f9f2e8dea87d29e1a Author: Thinh Nguyen Date: Wed Jul 27 18:38:01 2022 -0700 usb: common: debug: Check non-standard control requests [ Upstream commit b6155eaf6b05e558218b44b88a6cad03f15a586c ] Previously usb_decode_ctrl() only decodes standard control requests, but it was used for non-standard requests also. If it's non-standard or unknown standard bRequest, print the Setup data values. Fixes: af32423a2d86 ("usb: dwc3: trace: decode ctrl request") Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/8d6a30f2f2f953eff833a5bc5aac640a4cc2fc9f.1658971571.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dd1db668449d76d4288f35404d584138b90c3f63 Author: Aharon Landau Date: Sun Jul 31 11:26:36 2022 +0300 RDMA/mlx5: Don't compare mkey tags in DEVX indirect mkey [ Upstream commit 13ad1125b941a5f257d9d3ae70485773abd34792 ] According to the ib spec: If the CI supports the Base Memory Management Extensions defined in this specification, the L_Key format must consist of: 24 bit index in the most significant bits of the R_Key, and 8 bit key in the least significant bits of the R_Key Through a successful Allocate L_Key verb invocation, the CI must let the consumer own the key portion of the returned R_Key Therefore, when creating a mkey using DEVX, the consumer is allowed to change the key part. The kernel should compare only the index part of a R_Key to determine equality with another R_Key. Adding capability in order not to break backward compatibility. Fixes: 534fd7aac56a ("IB/mlx5: Manage indirection mkey upon DEVX flow for ODP") Link: https://lore.kernel.org/r/3d669aacea85a3a15c3b3b953b3eaba3f80ef9be.1659255945.git.leonro@nvidia.com Signed-off-by: Aharon Landau Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 30e20981b08a33be3f6b5292d6fd2cdf6bd7c024 Author: Jakob Hauser Date: Fri Aug 12 23:54:06 2022 +0200 iio: magnetometer: yas530: Change data type of hard_offsets to signed [ Upstream commit e137fafc8985cf152a4bb6f18ae83ebb06816df1 ] The "hard_offsets" are currently unsigned u8 but they should be signed as they can get negative. They are signed in function yas5xx_meaure_offsets() and in the Yamaha drivers [1][2]. [1] https://github.com/NovaFusion/android_kernel_samsung_golden/blob/cm-12.1/drivers/sensor/compass/yas.h#L156 [2] https://github.com/msm8916-mainline/android_kernel_qcom_msm8916/blob/GT-I9195I/drivers/iio/magnetometer/yas_mag_drv-yas532.c#L91 Fixes: de8860b1ed47 ("iio: magnetometer: Add driver for Yamaha YAS530") Signed-off-by: Jakob Hauser Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/40f052bf6491457d0c5c0ed4c3534dc6fa251c3c.1660337264.git.jahau@rocketmail.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 39eb39a592fbed8890706f9f07c42c1df4f4a344 Author: Jonathan Cameron Date: Sun Jun 26 13:29:23 2022 +0100 iio: ABI: Fix wrong format of differential capacitance channel ABI. [ Upstream commit 1efc41035f1841acf0af2bab153158e27ce94f10 ] in_ only occurs once in these attributes. Fixes: 0baf29d658c7 ("staging:iio:documentation Add abi docs for capacitance adcs.") Signed-off-by: Jonathan Cameron Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220626122938.582107-3-jic23@kernel.org Signed-off-by: Sasha Levin commit 144ef27e46e077c444709a5dc2e5d58fe99d7825 Author: Nuno Sá Date: Fri Jul 15 14:28:50 2022 +0200 iio: inkern: fix return value in devm_of_iio_channel_get_by_name() [ Upstream commit 9e878dbc0e8322f8b2f5ab0093c1e89926362dbe ] of_iio_channel_get_by_name() can either return NULL or an error pointer so that only doing IS_ERR() is not enough. Fix it by checking the NULL pointer case and return -ENODEV in that case. Note this is done like this so that users of the function (which only check for error pointers) do not need to be changed. This is not ideal since we are losing error codes and as such, in a follow up change, things will be unified so that of_iio_channel_get_by_name() only returns error codes. Fixes: 6e39b145cef7 ("iio: provide of_iio_channel_get_by_name() and devm_ version it") Signed-off-by: Nuno Sá Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220715122903.332535-3-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4e416e52185f507740706c519a01ebd376847332 Author: Nuno Sá Date: Fri Jul 15 14:28:49 2022 +0200 iio: inkern: only release the device node when done with it [ Upstream commit 79c3e84874c7d14f04ad58313b64955a0d2e9437 ] 'of_node_put()' can potentially release the memory pointed to by 'iiospec.np' which would leave us with an invalid pointer (and we would still pass it in 'of_xlate()'). Note that it is not guaranteed for the of_node lifespan to be attached to the device (to which is attached) lifespan so that there is (even though very unlikely) the possibility for the node to be freed while the device is still around. Thus, as there are indeed some of_xlate users which do access the node, a race is indeed possible. As such, we can only release the node after we are done with it. Fixes: 17d82b47a215d ("iio: Add OF support") Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20220715122903.332535-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 8394db2d4ffbfdb04c0475e414290b38e1d76b51 Author: Claudiu Beznea Date: Wed Aug 3 13:28:40 2022 +0300 iio: adc: at91-sama5d2_adc: disable/prepare buffer on suspend/resume [ Upstream commit 808175e21d9b7f866eda742e8970f27b78afe5db ] In case triggered buffers are enabled while system is suspended they will not work anymore after resume. For this call at91_adc_buffer_postdisable() on suspend and at91_adc_buffer_prepare() on resume. On tests it has been seen that at91_adc_buffer_postdisable() call is not necessary but it has been kept because it also does the book keeping for DMA. On resume path there is no need to call at91_adc_configure_touch() as it is embedded in at91_adc_buffer_prepare(). Fixes: 073c662017f2f ("iio: adc: at91-sama5d2_adc: add support for DMA") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220803102855.2191070-5-claudiu.beznea@microchip.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e0b504be6e42dce5b2d87c871093925e76e7b8a7 Author: Claudiu Beznea Date: Wed Aug 3 13:28:39 2022 +0300 iio: adc: at91-sama5d2_adc: lock around oversampling and sample freq [ Upstream commit 9780a23ed5a0a0a63683e078f576719a98d4fb70 ] .read_raw()/.write_raw() could be called asynchronously from user space or other in kernel drivers. Without locking on st->lock these could be called asynchronously while there is a conversion in progress. Read will be harmless but changing registers while conversion is in progress may lead to inconsistent results. Thus, to avoid this lock st->lock. Fixes: 27e177190891 ("iio:adc:at91_adc8xx: introduce new atmel adc driver") Fixes: 6794e23fa3fe ("iio: adc: at91-sama5d2_adc: add support for oversampling resolution") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220803102855.2191070-4-claudiu.beznea@microchip.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 44f46f904d8c73435b1f1355ca8255a4dfcd4d64 Author: Claudiu Beznea Date: Wed Aug 3 13:28:38 2022 +0300 iio: adc: at91-sama5d2_adc: check return status for pressure and touch [ Upstream commit d84ace944a3b24529798dbae1340dea098473155 ] Check return status of at91_adc_read_position() and at91_adc_read_pressure() in at91_adc_read_info_raw(). Fixes: 6794e23fa3fe ("iio: adc: at91-sama5d2_adc: add support for oversampling resolution") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220803102855.2191070-3-claudiu.beznea@microchip.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit b8c127184bc5071006cafec49e1173df425703c5 Author: Claudiu Beznea Date: Wed Aug 3 13:28:37 2022 +0300 iio: adc: at91-sama5d2_adc: fix AT91_SAMA5D2_MR_TRACKTIM_MAX [ Upstream commit bb73d5d9164c57c4bb916739a98e5cd8e0a5ed8c ] All ADC HW versions handled by this driver (SAMA5D2, SAM9X60, SAMA7G5) have MR.TRACKTIM on 4 bits. Fix AT91_SAMA5D2_MR_TRACKTIM_MAX to reflect this. Fixes: 27e177190891 ("iio:adc:at91_adc8xx: introduce new atmel adc driver") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220803102855.2191070-2-claudiu.beznea@microchip.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 82c66c46f73b88be74c869e2cbfef45281adf3c6 Author: Darrick J. Wong Date: Fri Sep 30 17:02:32 2022 -0700 iomap: iomap: fix memory corruption when recording errors during writeback [ Upstream commit 3d5f3ba1ac28059bdf7000cae2403e4e984308d2 ] Every now and then I see this crash on arm64: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dm_thin_pool dm_persistent_data XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECT potentially unexpected fatal signal 6. nf_reject_ipv6 potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tables pc : 000003fd6d7df200 x_tables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wb_workfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseq_set+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: 1 PID: 122167 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 do_writepages+0x90/0x1c4 __writeback_single_inode+0x4c/0x4ac Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 writeback_sb_inodes+0x214/0x4ac wb_writeback+0xf4/0x3b0 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) wb_workfn+0xfc/0x580 process_one_work+0x1e8/0x480 pc : 000003fd6d7df200 worker_thread+0x78/0x430 This crash is a result of iomap_writepage_map encountering some sort of error during writeback and wanting to set that error code in the file mapping so that fsync will report it. Unfortunately, the code dereferences folio->mapping after unlocking the folio, which means that another thread could have removed the page from the page cache (writeback doesn't hold the invalidation lock) and give it to somebody else. At best we crash the system like above; at worst, we corrupt memory or set an error on some other unsuspecting file while failing to record the problems with *this* file. Regardless, fix the problem by reporting the error to the inode mapping. NOTE: Commit 598ecfbaa742 lifted the XFS writeback code to iomap, so this fix should be backported to XFS in the 4.6-5.4 kernels in addition to iomap in the 5.5-5.19 kernels. Fixes: e735c0079465 ("iomap: Convert iomap_add_to_ioend() to take a folio") # 5.17 onward Fixes: 598ecfbaa742 ("iomap: lift the xfs writeback code to iomap") # 5.5-5.16, needs backporting Fixes: 150d5be09ce4 ("xfs: remove xfs_cancel_ioend") # 4.6-5.4, needs backporting Signed-off-by: Darrick J. Wong Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 0530055d5b967dbf29ff480841819ab6348a003d Author: Dmitry Torokhov Date: Tue Sep 27 15:05:03 2022 -0700 ARM: dts: exynos: fix polarity of VBUS GPIO of Origen [ Upstream commit a08137bd1e0a7ce951dce9ce4a83e39d379b6e1b ] EHCI Oxynos (drivers/usb/host/ehci-exynos.c) drives VBUS GPIO high when trying to power up the bus, therefore the GPIO in DTS must be marked as "active high". This will be important when EHCI driver is converted to gpiod API that respects declared polarities. Fixes: 4e8991def565 ("ARM: dts: exynos: Enable AX88760 USB hub on Origen board") Signed-off-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20220927220504.3744878-1-dmitry.torokhov@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 0f77b6b2ba70d7c9d69ef39694e283ded9f8b5f2 Author: Mark Rutland Date: Thu Sep 29 14:45:25 2022 +0100 arm64: ftrace: fix module PLTs with mcount [ Upstream commit 8cfb08575c6d4585f1ce0deeb189e5c824776b04 ] Li Huafei reports that mcount-based ftrace with module PLTs was broken by commit: a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.") When a module PLTs are used and a module is loaded sufficiently far away from the kernel, we'll create PLTs for any branches which are out-of-range. These are separate from the special ftrace trampoline PLTs, which the module PLT code doesn't directly manipulate. When mcount is in use this is a problem, as each mcount callsite in a module will be initialized to point to a module PLT, but since commit a6253579977e4c6f ftrace_make_nop() will assume that the callsite has been initialized to point to the special ftrace trampoline PLT, and ftrace_find_callable_addr() rejects other cases. This means that when ftrace tries to initialize a callsite via ftrace_make_nop(), the call to ftrace_find_callable_addr() will find that the `_mcount` stub is out-of-range and is not handled by the ftrace PLT, resulting in a splat: | ftrace_test: loading out-of-tree module taints kernel. | ftrace: no module PLT for _mcount | ------------[ ftrace bug ]------------ | ftrace failed to modify | [] 0xffff800029180014 | actual: 44:00:00:94 | Initializing ftrace call sites | ftrace record flags: 2000000 | (0) | expected tramp: ffff80000802eb3c | ------------[ cut here ]------------ | WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270 | Modules linked in: | CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22 | Hardware name: linux,dummy-virt (DT) | pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : ftrace_bug+0x94/0x270 | lr : ftrace_bug+0x21c/0x270 | sp : ffff80000b2bbaf0 | x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000 | x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00 | x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8 | x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff | x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118 | x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666 | x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030 | x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4 | x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001 | x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022 | Call trace: | ftrace_bug+0x94/0x270 | ftrace_process_locs+0x308/0x430 | ftrace_module_init+0x44/0x60 | load_module+0x15b4/0x1ce8 | __do_sys_init_module+0x1ec/0x238 | __arm64_sys_init_module+0x24/0x30 | invoke_syscall+0x54/0x118 | el0_svc_common.constprop.4+0x84/0x100 | do_el0_svc+0x3c/0xd0 | el0_svc+0x1c/0x50 | el0t_64_sync_handler+0x90/0xb8 | el0t_64_sync+0x15c/0x160 | ---[ end trace 0000000000000000 ]--- | ---------test_init----------- Fix this by reverting to the old behaviour of ignoring the old instruction when initialising an mcount callsite in a module, which was the behaviour prior to commit a6253579977e4c6f. Signed-off-by: Mark Rutland Fixes: a6253579977e ("arm64: ftrace: consistently handle PLTs.") Reported-by: Li Huafei Link: https://lore.kernel.org/linux-arm-kernel/20220929094134.99512-1-lihuafei1@huawei.com Cc: Ard Biesheuvel Cc: Will Deacon Link: https://lore.kernel.org/r/20220929134525.798593-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 75e60ad770e21159a4d82840195533603dd69194 Author: Josh Triplett Date: Sun Jul 31 20:24:53 2022 -0700 ext4: don't run ext4lazyinit for read-only filesystems [ Upstream commit 426d15ad11419066f7042ffa8fbf1b5c21a1ecbe ] On a read-only filesystem, we won't invoke the block allocator, so we don't need to prefetch the block bitmaps. This avoids starting and running the ext4lazyinit thread at all on a system with no read-write ext4 filesystems (for instance, a container VM with read-only filesystems underneath an overlayfs). Fixes: 21175ca434c5 ("ext4: make prefetch_block_bitmaps default") Signed-off-by: Josh Triplett Reviewed-by: Lukas Czerner Link: https://lore.kernel.org/r/48b41da1498fcac3287e2e06b660680646c1c050.1659323972.git.josh@joshtriplett.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 59cdd0794d5959ef5cbacde264d8ce91520ecd16 Author: Geert Uytterhoeven Date: Tue Sep 27 15:28:26 2022 +0200 ARM: Drop CMDLINE_* dependency on ATAGS [ Upstream commit 136f4b1ec7c962ee37a787e095fd37b058d72bd3 ] On arm32, the configuration options to specify the kernel command line type depend on ATAGS. However, the actual CMDLINE cofiguration option does not depend on ATAGS, and the code that handles this is not specific to ATAGS (see drivers/of/fdt.c:early_init_dt_scan_chosen()). Hence users who desire to override the kernel command line on arm32 must enable support for ATAGS, even on a pure-DT system. Other architectures (arm64, loongarch, microblaze, nios2, powerpc, and riscv) do not impose such a restriction. Hence drop the dependency on ATAGS. Fixes: bd51e2f595580fb6 ("ARM: 7506/1: allow for ATAGS to be configured out when DT support is selected") Signed-off-by: Geert Uytterhoeven Acked-by: Ard Biesheuvel Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit c665b41db85213c73a8d04c781dac32b3d483ef0 Author: Dmitry Torokhov Date: Mon Sep 26 12:43:53 2022 +0200 ARM: dts: exynos: correct s5k6a3 reset polarity on Midas family [ Upstream commit 3ba2d4bb9592bf7a6a3fe3dbe711ecfc3d004bab ] According to s5k6a3 driver code, the reset line for the chip appears to be active low. This also matches the typical polarity of reset lines in general. Let's fix it up as having correct polarity in DTS is important when the driver will be switched over to gpiod API. Fixes: b4fec64758ab ("ARM: dts: Add camera device nodes for Exynos4412 TRATS2 board") Signed-off-by: Dmitry Torokhov Signed-off-by: Krzysztof Kozlowski Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20220913164104.203957-1-dmitry.torokhov@gmail.com Link: https://lore.kernel.org/r/20220926104354.118578-2-krzysztof.kozlowski@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 0d54c26d0adea39b4ce1bc21028b49af6326f263 Author: Matt Ranostay Date: Mon Sep 19 13:57:23 2022 -0700 arm64: dts: ti: k3-j7200: fix main pinmux range [ Upstream commit 0d0a0b4413460383331088b2203ba09a6971bc3a ] Range size of 0x2b4 was incorrect since there isn't 173 configurable pins for muxing. Additionally there is a non-addressable region in the mapping which requires splitting into two ranges. main_pmx0 -> 67 pins main_pmx1 -> 3 pins Fixes: d361ed88455f ("arm64: dts: ti: Add support for J7200 SoC") Signed-off-by: Matt Ranostay Signed-off-by: Vignesh Raghavendra Tested-by: Vaishnav Achath Link: https://lore.kernel.org/r/20220919205723.8342-1-mranostay@ti.com Signed-off-by: Sasha Levin commit a39307c7c75019d2eb3ffac722b9f83243c8a465 Author: Dmitry Osipenko Date: Wed Sep 23 03:34:21 2020 +0300 soc/tegra: fuse: Drop Kconfig dependency on TEGRA20_APB_DMA [ Upstream commit 2254182807fc09ba9dec9a42ef239e373796f1b2 ] The DMA subsystem could be entirely disabled in Kconfig and then the TEGRA20_APB_DMA option isn't available too. Hence kernel configuration fails if DMADEVICES Kconfig option is disabled due to the unsatisfiable dependency. The FUSE driver isn't a critical driver and currently it only provides NVMEM interface to userspace which isn't known to be widely used, and thus, it's fine if FUSE driver fails to load. Let's remove the erroneous Kconfig dependency and let the FUSE driver to fail the probing if DMA is unavailable. Fixes: 19d41e5e9c68 ("soc/tegra: fuse: Add APB DMA dependency for Tegra20") Reported-by: Necip Fazil Yildiran Link: https://bugzilla.kernel.org/show_bug.cgi?id=209301 Signed-off-by: Dmitry Osipenko Signed-off-by: Sasha Levin commit 2f91772a5f8a41fc06a07369223987209d1e3cc7 Author: Randy Dunlap Date: Sat Sep 10 18:26:16 2022 -0700 ia64: export memory_add_physaddr_to_nid to fix cxl build error [ Upstream commit 97c318bfbe84efded246e80428054f300042f110 ] cxl_pmem.ko uses memory_add_physaddr_to_nid() but ia64 does not export it, so this causes a build error: ERROR: modpost: "memory_add_physaddr_to_nid" [drivers/cxl/cxl_pmem.ko] undefined! Fix this by exporting that function. Fixes: 8c2676a5870a ("hot-add-mem x86_64: memory_add_physaddr_to_nid node fixup") Reported-by: kernel test robot Signed-off-by: Randy Dunlap Cc: Dan Williams Cc: Ben Widawsky Cc: Jonathan Cameron Cc: linux-ia64@vger.kernel.org Cc: Arnd Bergmann Cc: Keith Mannthey Cc: Andrew Morton Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 664c6b13332ab3d72a4ba38000d6ac8a9414579e Author: Michael Walle Date: Tue Aug 16 02:10:25 2022 +0200 ARM: dts: kirkwood: lsxl: remove first ethernet port [ Upstream commit 2d528eda7c96ce5c70f895854ecd5684bd5d80b9 ] Both the Linkstation LS-CHLv2 and the LS-XHL have only one ethernet port. This has always been wrong, i.e. the board code used to set up both ports, but the driver will play nice and return -ENODEV if the assiciated PHY is not found. Nevertheless, it is wrong. Remove it. Fixes: 876e23333511 ("ARM: kirkwood: add gigabit ethernet and mvmdio device tree nodes") Signed-off-by: Michael Walle Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit e3ab51897adc7336b32b9c3ede876c5851a9e239 Author: Michael Walle Date: Tue Aug 16 02:10:24 2022 +0200 ARM: dts: kirkwood: lsxl: fix serial line [ Upstream commit 04eabc6ac10fda9424606d9a7ab6ab9a5d95350a ] Commit 327e15428977 ("ARM: dts: kirkwood: consolidate common pinctrl settings") unknowingly broke the serial output on this board. Before this commit, the pinmux was still configured by the bootloader and the kernel didn't reconfigured it again. This was an oversight by the initial board support where the pinmux for the serial line was never configured by the kernel. But with this commit, the serial line will be reconfigured to the wrong pins. This is especially confusing, because the output still works, but the input doesn't. Presumingly, the input is reconfigured to MPP10, but the output is connected to both MPP11 and MPP5. Override the pinmux in the board device tree. Fixes: 327e15428977 ("ARM: dts: kirkwood: consolidate common pinctrl settings") Signed-off-by: Michael Walle Reviewed-by: Andrew Lunn Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 1764fd62a86c068817fbbcacc33d441e6e07b89c Author: Marek Behún Date: Wed Jul 27 14:56:10 2022 +0200 ARM: dts: turris-omnia: Fix mpp26 pin name and comment [ Upstream commit 49e93898f0dc177e645c22d0664813567fd9ec00 ] There is a bug in Turris Omnia's schematics, whereupon the MPP[26] pin, which is routed to CN11 pin header, is documented as SPI CS1, but MPP[26] pin does not support this function. Instead it controls chip select 2 if in "spi0" mode. Fix the name of the pin node in pinctrl node and fix the comment in SPI node. Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia") Signed-off-by: Marek Behún Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit b3f82935c77ab6204c6bc2260c054d387824b884 Author: Chanho Park Date: Wed Jul 27 11:13:55 2022 +0900 dt-bindings: clock: exynosautov9: correct clock numbering of peric0/c1 [ Upstream commit b6740089b740b842d5e6ff55b4b2c3bf5961c69a ] There are duplicated definitions of peric0 and peric1 cmu blocks. Thus, they should be defined correctly as numerical order. Fixes: 680e1c8370a2 ("dt-bindings: clock: add clock binding definitions for Exynos Auto v9") Signed-off-by: Chanho Park Reviewed-by: Krzysztof Kozlowski Acked-by: Chanwoo Choi Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220727021357.152421-2-chanho61.park@samsung.com Signed-off-by: Sasha Levin commit bba8ed1946c06aa0b92acf059f63285763047339 Author: Biju Das Date: Tue Aug 2 11:15:34 2022 +0100 arm64: dts: renesas: r9a07g043: Fix SCI{Rx,Tx} interrupt types [ Upstream commit 72a482dbaec4b9e4d54b81be6bdb8c016fd2f4bd ] As per the RZ/G2UL Hardware User's Manual (Rev.1.00 Apr, 2022), the interrupt type of SCI{Rx,Tx} is edge triggered. Signed-off-by: Biju Das Fixes: cf40c9689e5109bf ("arm64: dts: renesas: Add initial DTSI for RZ/G2UL SoC") Link: https://lore.kernel.org/r/20220802101534.1401342-3-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 4522a6fe84cb3359c0d2786a6d87a5e4335bcec3 Author: Biju Das Date: Tue Aug 2 11:15:33 2022 +0100 arm64: dts: renesas: r9a07g054: Fix SCI{Rx,Tx} interrupt types [ Upstream commit 13dec051c7f139eef345c55a60941843e72128f1 ] As per the RZ/V2L Hardware User's Manual (Rev.1.00 Nov, 2021), the interrupt type of SCI{Rx,Tx} is edge triggered. Signed-off-by: Biju Das Fixes: 7c2b8198f4f321df ("arm64: dts: renesas: Add initial DTSI for RZ/V2L SoC") Link: https://lore.kernel.org/r/20220802101534.1401342-2-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 964cf7f0d477d246e3d88f5cfbc279c1cf43c30d Author: Biju Das Date: Tue Aug 2 11:15:32 2022 +0100 arm64: dts: renesas: r9a07g044: Fix SCI{Rx,Tx} interrupt types [ Upstream commit f3b7bc89c97b98aa6f157d5f296695af8940a5ac ] As per the latest RZ/G2L Hardware User's Manual (Rev.1.10 Apr, 2022), the interrupt type of SCI{Rx,Tx} is edge triggered. Signed-off-by: Biju Das Fixes: f9a2adcc9e908907 ("arm64: dts: renesas: r9a07g044: Add SCI[0-1] nodes") Link: https://lore.kernel.org/r/20220802101534.1401342-1-biju.das.jz@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 02e3b6404d2685828648228613ebe314f2853af6 Author: Lucas Stach Date: Tue Jul 26 15:05:23 2022 +0200 ARM: dts: imx6qdl-kontron-samx6i: hook up DDC i2c bus [ Upstream commit afd8f77957e3e83adf21d9229c61ff37f44a177a ] i2c2 is routed to the pins dedicated as DDC in the module standard. Reduce clock rate to 100kHz to be in line with VESA standard and hook this bus up to the HDMI node. Fixes: 708ed2649ad8 ("ARM: dts: imx6qdl-kontron-samx6i: increase i2c-frequency") Signed-off-by: Lucas Stach [m.felsch@pengutronix.de: add fixes line] Signed-off-by: Marco Felsch Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit c1bc4ab733ecc25bce455caf7536012c76b245f4 Author: Liang He Date: Thu Jul 21 21:52:17 2022 +0800 soc: qcom: smem_state: Add refcounting for the 'state->of_node' [ Upstream commit 90681f53b9381c23ff7762a3b13826d620c272de ] In qcom_smem_state_register() and qcom_smem_state_release(), we should better use of_node_get() and of_node_put() for the reference creation and destruction of 'device_node'. Fixes: 9460ae2ff308 ("soc: qcom: Introduce common SMEM state machine code") Signed-off-by: Liang He Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220721135217.1301039-2-windhl@126.com Signed-off-by: Sasha Levin commit 8fb6112bd49c0e49f2cf51604231d85ff00284bb Author: Liang He Date: Thu Jul 21 21:52:16 2022 +0800 soc: qcom: smsm: Fix refcount leak bugs in qcom_smsm_probe() [ Upstream commit af8f6f39b8afd772fda4f8e61823ef8c021bf382 ] There are two refcount leak bugs in qcom_smsm_probe(): (1) The 'local_node' is escaped out from for_each_child_of_node() as the break of iteration, we should call of_node_put() for it in error path or when it is not used anymore. (2) The 'node' is escaped out from for_each_available_child_of_node() as the 'goto', we should call of_node_put() for it in goto target. Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Signed-off-by: Liang He Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220721135217.1301039-1-windhl@126.com Signed-off-by: Sasha Levin commit e0b55fd272ae64542c0a50b733cbfb8872518efe Author: Amir Goldstein Date: Tue Aug 16 17:53:17 2022 +0300 locks: fix TOCTOU race when granting write lease [ Upstream commit d6da19c9cace63290ccfccb1fc35151ffefc0bec ] Thread A trying to acquire a write lease checks the value of i_readcount and i_writecount in check_conflicting_open() to verify that its own fd is the only fd referencing the file. Thread B trying to open the file for read will call break_lease() in do_dentry_open() before incrementing i_readcount, which leaves a small window where thread A can acquire the write lease and then thread B completes the open of the file for read without breaking the write lease that was acquired by thread A. Fix this race by incrementing i_readcount before checking for existing leases, same as the case with i_writecount. Use a helper put_file_access() to decrement i_readcount or i_writecount in do_dentry_open() and __fput(). Fixes: 387e3746d01c ("locks: eliminate false positive conflicts for write lease") Reviewed-by: Jeff Layton Signed-off-by: Amir Goldstein Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit daab421fc2dc7d6ae7eb20a3f565ae09652c68b9 Author: Liang He Date: Tue Jul 19 16:56:40 2022 +0800 memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings() [ Upstream commit 48af14fb0eaa63d9aa68f59fb0b205ec55a95636 ] We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount. Fixes: 976897dd96db ("memory: Extend of_memory with LPDDR3 support") Signed-off-by: Liang He Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220719085640.1210583-2-windhl@126.com Signed-off-by: Sasha Levin commit 62ccab6e3376f8a22167c3b81468ae4f3e7d25f1 Author: Liang He Date: Tue Jul 19 16:56:39 2022 +0800 memory: of: Fix refcount leak bug in of_get_ddr_timings() [ Upstream commit 05215fb32010d4afb68fbdbb4d237df6e2d4567b ] We should add the of_node_put() when breaking out of for_each_child_of_node() as it will automatically increase and decrease the refcount. Fixes: e6b42eb6a66c ("memory: emif: add device tree support to emif driver") Signed-off-by: Liang He Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220719085640.1210583-1-windhl@126.com Signed-off-by: Sasha Levin commit 44db35ceb94756ba513dcf6b69bf9e949b28469c Author: Liang He Date: Sat Jul 16 11:13:24 2022 +0800 memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe() [ Upstream commit 61b3c876c1cbdb1efd1f52a1f348580e6e14efb6 ] The break of for_each_available_child_of_node() needs a corresponding of_node_put() when the reference 'child' is not used anymore. Here we do not need to call of_node_put() in fail path as '!match' means no break. While the of_platform_device_create() will created a new reference by 'child' but it has considered the refcounting. Fixes: fee10bd22678 ("memory: pl353: Add driver for arm pl353 static memory controller") Signed-off-by: Liang He Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220716031324.447680-1-windhl@126.com Signed-off-by: Sasha Levin commit 7cdc122f28d71a8170be467323eebc5bfef32476 Author: Takashi Iwai Date: Sat Oct 1 09:48:10 2022 +0200 ALSA: hda/hdmi: Don't skip notification handling during PM operation [ Upstream commit 5226c7b9784eee215e3914f440b3c2e1764f67a8 ] The HDMI driver skips the notification handling from the graphics driver when the codec driver is being in the PM operation. This behavior was introduced by the commit eb399d3c99d8 ("ALSA: hda - Skip ELD notification during PM process"). This skip may cause a problem, as we may miss the ELD update when the connection/disconnection happens right at the runtime-PM operation of the audio codec. Although this workaround was valid at that time, it's no longer true; the fix was required just because the ELD update procedure needed to wake up the audio codec, which had lead to a runtime-resume during a runtime-suspend. Meanwhile, the ELD update procedure doesn't need a codec wake up any longer since the commit 788d441a164c ("ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling"); i.e. there is no much reason for skipping the notification. Let's drop those checks for addressing the missing notification. Fixes: 788d441a164c ("ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling") Reported-by: Brent Lu Link: https://lore.kernel.org/r/20220927135807.4097052-1-brent.lu@intel.com Link: https://lore.kernel.org/r/20221001074809.7461-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8679d53050807bc62ed426936e4c04206e69ce39 Author: Zhang Qilong Date: Thu Sep 29 00:01:16 2022 +0800 ASoC: mt6660: Fix PM disable depth imbalance in mt6660_i2c_probe [ Upstream commit b73f11e895e140537e7f8c7251211ccd3ce0782b ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of mt6660_i2c_probe. Fixes:f289e55c6eeb4 ("ASoC: Add MediaTek MT6660 Speaker Amp Driver") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220928160116.125020-5-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bac2dd72fcfb4cfdfef3f11f9ecd304dd831879f Author: Zhang Qilong Date: Thu Sep 29 00:01:15 2022 +0800 ASoC: wm5102: Fix PM disable depth imbalance in wm5102_probe [ Upstream commit fcbb60820cd3008bb44334a0395e5e57ccb77329 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of wm5102_probe. Fixes:93e8791dd34ca ("ASoC: wm5102: Initial driver") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220928160116.125020-4-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f54f599c8e2fb1eddee6c5a820f0be641cd28ec3 Author: Zhang Qilong Date: Thu Sep 29 00:01:14 2022 +0800 ASoC: wm5110: Fix PM disable depth imbalance in wm5110_probe [ Upstream commit 86b46bf1feb83898d89a2b4a8d08d21e9ea277a7 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of wm5110_probe. Fixes:5c6af635fd772 ("ASoC: wm5110: Add audio CODEC driver") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220928160116.125020-3-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 530b9c0e4121dc7fb6e8da118b27376509343617 Author: Zhang Qilong Date: Thu Sep 29 00:01:13 2022 +0800 ASoC: wm8997: Fix PM disable depth imbalance in wm8997_probe [ Upstream commit 41a736ac20602f64773e80f0f5b32cde1830a44a ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of wm8997_probe Fixes:40843aea5a9bd ("ASoC: wm8997: Initial CODEC driver") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220928160116.125020-2-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 16226421b10a14d24ca8f4709fe53369e775c745 Author: Zhang Qilong Date: Tue Sep 27 22:26:40 2022 +0800 ASoC: stm: Fix PM disable depth imbalance in stm32_i2s_probe [ Upstream commit 93618e5e05a3ce4aa6750268c5025bdb4cb7dc6e ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of stm32_i2s_probe. Fixes:32a956a1fadf ("ASoC: stm32: i2s: add pm_runtime support") Signed-off-by: Zhang Qilong Reviewed-by: Olivier Moysan Link: https://lore.kernel.org/r/20220927142640.64647-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eb7bcd48fc8eca610265b75ed1a65e90603d0e35 Author: Zhang Qilong Date: Tue Sep 27 22:26:01 2022 +0800 ASoC: stm32: spdifrx: Fix PM disable depth imbalance in stm32_spdifrx_probe [ Upstream commit 0325cc0ac7980e1c7b744aab8df59afab6daeb43 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of stm32_spdifrx_probe. Fixes:ac5e3efd55868 ("ASoC: stm32: spdifrx: add pm_runtime support") Signed-off-by: Zhang Qilong Reviewed-by: Olivier Moysan Link: https://lore.kernel.org/r/20220927142601.64266-3-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aa7f877d2d073985049695b6d0fb444f49242a3d Author: Zhang Qilong Date: Tue Sep 27 22:26:00 2022 +0800 ASoC: stm32: dfsdm: Fix PM disable depth imbalance in stm32_adfsdm_probe [ Upstream commit b9a0da5b2edcae2a901b85c8cc42efc5bec4bd7b ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. We fix it by moving pm_runtime_enable to the endding of stm32_adfsdm_probe. Fixes:98e500a12f934 ("ASoC: stm32: dfsdm: add pm_runtime support for audio") Signed-off-by: Zhang Qilong Reviewed-by: Olivier Moysan Link: https://lore.kernel.org/r/20220927142601.64266-2-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 06821c68d9ed82d7d0c0041e1f9352e196354fe0 Author: Christophe JAILLET Date: Thu Sep 22 21:06:40 2022 +0200 mmc: wmt-sdmmc: Fix an error handling path in wmt_mci_probe() [ Upstream commit cb58188ad90a61784a56a64f5107faaf2ad323e7 ] A dma_free_coherent() call is missing in the error handling path of the probe, as already done in the remove function. Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650") Signed-off-by: Christophe JAILLET Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/53fc6ffa5d1c428fefeae7d313cf4a669c3a1e98.1663873255.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2e2c57f660a63842d6f461c7643dd1f45c1cac63 Author: Andreas Pape Date: Mon Sep 26 18:58:13 2022 +0200 ALSA: dmaengine: increment buffer pointer atomically [ Upstream commit d1c442019594692c64a70a86ad88eb5b6db92216 ] Setting pointer and afterwards checking for wraparound leads to the possibility of returning the inconsistent pointer position. This patch increments buffer pointer atomically to avoid this issue. Fixes: e7f73a1613567a ("ASoC: Add dmaengine PCM helper functions") Signed-off-by: Andreas Pape Signed-off-by: Eugeniu Rosca Link: https://lore.kernel.org/r/1664211493-11789-1-git-send-email-erosca@de.adit-jv.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ec692f0b51006de1138cd1f82cae625f0d2888d1 Author: Christophe JAILLET Date: Thu Sep 22 21:44:57 2022 +0200 ASoC: da7219: Fix an error handling path in da7219_register_dai_clks() [ Upstream commit abb4e4349afe7eecdb0499582f1c777031e3a7c8 ] If clk_hw_register() fails, the corresponding clk should not be unregistered. To handle errors from loops, clean up partial iterations before doing the goto. So add a clk_hw_unregister(). Then use a while (--i >= 0) loop in the unwind section. Fixes: 78013a1cf297 ("ASoC: da7219: Fix clock handling around codec level probe") Reported-by: Dan Carpenter Signed-off-by: Christophe JAILLET Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/e4acceab57a0d9e477a8d5890a45c5309e553e7c.1663875789.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 40aba726b2cdc1a5f30f18f0dcd2bf13c6864b91 Author: Srinivas Kandagatla Date: Tue Sep 6 18:01:05 2022 +0100 ASoC: codecs: tx-macro: fix kcontrol put [ Upstream commit c1057a08af438e0cf5450c1d977a3011198ed2f8 ] tx_macro_tx_mixer_put() and tx_macro_dec_mode_put() currently returns zero eventhough it changes the value. Fix this, so that change notifications are sent correctly. Fixes: d207bdea0ca9 ("ASoC: codecs: lpass-tx-macro: add dapm widgets and route") Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220906170112.1984-6-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 60f6d4f9d9036ed758465b89b8caa0ec34bfa55d Author: Dan Carpenter Date: Mon Sep 19 09:36:30 2022 +0300 virtio-gpu: fix shift wrapping bug in virtio_gpu_fence_event_create() [ Upstream commit 37a78445763a5921bb54e9bad01937d0dfa521c1 ] The ->ring_idx_mask variable is a u64 so static checkers, Smatch in this case, complain if the BIT() is not also a u64. drivers/gpu/drm/virtio/virtgpu_ioctl.c:50 virtio_gpu_fence_event_create() warn: should '(1 << ring_idx)' be a 64 bit type? Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add virtio_gpu_fence_event") Signed-off-by: Dan Carpenter Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/YygN7jY0GdUSQSy0@kili Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 6ad40bbb2c25f17b899fcea114ebc0a46d8a938b Author: Rafael Mendonca Date: Fri Sep 16 17:47:51 2022 -0300 drm/vmwgfx: Fix memory leak in vmw_mksstat_add_ioctl() [ Upstream commit a40c7f61d12fbd1e785e59140b9efd57127c0c33 ] If the copy of the description string from userspace fails, then the page for the instance descriptor doesn't get freed before returning -EFAULT, which leads to a memleak. Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce VMware mks-guest-stats") Signed-off-by: Rafael Mendonca Reviewed-by: Martin Krastev Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20220916204751.720716-1-rafaelmendsr@gmail.com Signed-off-by: Sasha Levin commit dea4873556910b16109727d034fd16abf21ef201 Author: Takashi Iwai Date: Tue Sep 20 20:11:26 2022 +0200 ALSA: usb-audio: Properly refcounting clock rate [ Upstream commit 9a737e7f8b371e97eb649904276407cee2c9cf30 ] We fixed the bug introduced by the patch for managing the shared clocks at the commit 809f44a0cc5a ("ALSA: usb-audio: Clear fixed clock rate at closing EP"), but it was merely a workaround. By this change, the clock reference rate is cleared at each EP close, hence the still remaining EP may need a re-setup of rate unnecessarily. This patch introduces the proper refcounting for the clock reference object so that the clock setup is done only when needed. Fixes: 809f44a0cc5a ("ALSA: usb-audio: Clear fixed clock rate at closing EP") Fixes: c11117b634f4 ("ALSA: usb-audio: Refcount multiple accesses on the single clock") Link: https://lore.kernel.org/r/20220920181126.4912-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7a2bead0355755f190bc4ef5ed804a93239f611e Author: Kuogee Hsieh Date: Wed Aug 24 13:15:50 2022 -0700 drm/msm/dp: correct 1.62G link rate at dp_catalog_ctrl_config_msa() [ Upstream commit aa0bff10af1c4b92e6b56e3e1b7f81c660d3ba78 ] At current implementation there is an extra 0 at 1.62G link rate which cause no correct pixel_div selected for 1.62G link rate to calculate mvid and nvid. This patch delete the extra 0 to have mvid and nvid be calculated correctly. Changes in v2: -- fix Fixes tag's text Changes in v3: -- fix misspelling of "Reviewed-by" Fixes: 937f941ca06f ("drm/msm/dp: Use qmp phy for DP PLL and PHY") Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/499328/ Link: https://lore.kernel.org/r/1661372150-3764-1-git-send-email-quic_khsieh@quicinc.com [DB: rewrapped commit message] Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 512c4d444c69952cb1033731af5afbc50f1dbcc3 Author: Dmitry Baryshkov Date: Wed Jun 15 15:57:01 2022 +0300 drm/msm/dpu: index dpu_kms->hw_vbif using vbif_idx [ Upstream commit 7538f80ae0d98bf51eb89eee5344aec219902d42 ] Remove loops over hw_vbif. Instead always VBIF's idx as an index in the array. This fixes an error in dpu_kms_hw_init(), where we fill dpu_kms->hw_vbif[i], but check for an error pointer at dpu_kms->hw_vbif[vbif_idx]. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov Reviewed-by: Abhinav Kumar Patchwork: https://patchwork.freedesktop.org/patch/489569/ Link: https://lore.kernel.org/r/20220615125703.24647-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit ab03e61c5cf76cd8a1a119c1def80f1c8c941626 Author: Dmitry Baryshkov Date: Fri Aug 5 14:56:30 2022 +0300 drm/msm: lookup the ICC paths in both mdp5/dpu and mdss devices [ Upstream commit 5ccdcecaf8f732f593e359ebfb65de96b11bae66 ] The commit 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components") changed the MDP5 driver to look for the interconnect paths in the MDSS device rather than in the MDP5 device itself. This was left unnoticed since on my testing devices the interconnects probably didn't reach the sync state. Rather than just using the MDP5 device for ICC path lookups for the MDP5 devices, introduce an additional helper to check both MDP5/DPU and MDSS nodes. This will be helpful for the MDP5->DPU conversion, since the driver will have to check both nodes. Fixes: 6874f48bb8b0 ("drm/msm: make mdp5/dpu devices master components") Reported-by: Marijn Suijten Reported-by: Yassine Oudjana Signed-off-by: Dmitry Baryshkov Tested-by: Marijn Suijten # On sdm630 Tested-by: Yassine Oudjana # msm8996 Patchwork: https://patchwork.freedesktop.org/patch/496488/ Link: https://lore.kernel.org/r/20220805115630.506391-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit b58efaf656abd661e99479243aa27389edfd1b74 Author: Liang He Date: Wed Sep 14 21:43:54 2022 +0800 ASoC: eureka-tlv320: Hold reference returned from of_find_xxx API [ Upstream commit bfb735a3ceff0bab6473bac275da96f9b2a06dec ] In eukrea_tlv320_probe(), we need to hold the reference returned from of_find_compatible_node() which has increased the refcount and then call of_node_put() with it when done. Fixes: 66f232908de2 ("ASoC: eukrea-tlv320: Add DT support.") Co-authored-by: Kelin Wang Signed-off-by: Liang He Link: https://lore.kernel.org/r/20220914134354.3995587-1-windhl@126.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit beffe91431ba91860a5c48f9c186dc452b7f22a1 Author: Christophe JAILLET Date: Thu Aug 25 09:33:57 2022 +0200 mmc: au1xmmc: Fix an error handling path in au1xmmc_probe() [ Upstream commit 5cbedf52608cc3cbc1c2a9a861fb671620427a20 ] If clk_prepare_enable() fails, there is no point in calling clk_disable_unprepare() in the error handling path. Move the out_clk label at the right place. Fixes: b6507596dfd6 ("MIPS: Alchemy: au1xmmc: use clk framework") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/21d99886d07fa7fcbec74992657dabad98c935c4.1661412818.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8b8da09da2701330e7f2c371655887e3d7defe90 Author: Rafael Mendonca Date: Mon Sep 12 19:34:32 2022 -0300 drm/amdgpu: Fix memory leak in hpd_rx_irq_create_workqueue() [ Upstream commit 7136f956c73c4ba50bfeb61653dfd6a9669ea915 ] If construction of the array of work queues to handle hpd_rx_irq offload work fails, we need to unwind. Destroy all the created workqueues and the allocated memory for the hpd_rx_irq_offload_work_queue struct array. Fixes: 8e794421bc98 ("drm/amd/display: Fork thread to offload work of hpd_rx_irq") Signed-off-by: Rafael Mendonca Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e55261beb86a15c190b2ff9090cb47bc06765353 Author: Liang He Date: Fri Jul 22 22:43:48 2022 +0800 drm/omap: dss: Fix refcount leak bugs [ Upstream commit 8b42057e62120813ebe9274f508fa785b7cab33a ] In dss_init_ports() and __dss_uninit_ports(), we should call of_node_put() for the reference returned by of_graph_get_port_by_id() in fail path or when it is not used anymore. Fixes: 09bffa6e5192 ("drm: omap: use common OF graph helpers") Signed-off-by: Liang He Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20220722144348.1306569-1-windhl@126.com Signed-off-by: Sasha Levin commit d1087cfd437086c2c12d5e5a610e7c9f9ef08b2f Author: AngeloGioacchino Del Regno Date: Tue Sep 6 11:27:24 2022 +0200 ASoC: SOF: mediatek: mt8195: Import namespace SND_SOC_SOF_MTK_COMMON [ Upstream commit 404bec4c8f6c38ae5fa208344f1086d38026e93d ] Here we're using function mtk_adsp_dump() from mtk-adsp-common: explicitly import its namespace. Fixes: 3a054f90e955 ("ASoC: SOF: mediatek: Add mt8195 debug dump") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20220906092727.37324-3-angelogioacchino.delregno@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a3c55862c67ebde5a7ed4265edd5e6721acf555 Author: Gerd Hoffmann Date: Tue Sep 6 16:29:57 2022 +0200 drm/bochs: fix blanking [ Upstream commit e740ceb53e4579a7a4063712cebecac3c343b189 ] VGA_IS1_RC is the color mode register (VGA_IS1_RM the one for monochrome mode, note C vs. M at the end). So when using VGA_IS1_RC make sure the vga device is actually in color mode and set the corresponding bit in the misc register. Reproducible when booting VMs in UEFI mode with some edk2 versions (edk2 fix is on the way too). Doesn't happen in BIOS mode because in that case the vgabios already flips the bit. Fixes: 250e743915d4 ("drm/bochs: Add screen blanking support") Signed-off-by: Gerd Hoffmann Acked-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20220906142957.2763577-1-kraxel@redhat.com Signed-off-by: Sasha Levin commit fc8eea8ec3caffe44ad872e1e4e2798d8eb382d4 Author: Chia-I Wu Date: Wed Aug 31 12:06:01 2022 -0700 drm/virtio: set fb_modifiers_not_supported [ Upstream commit 85faca8ca0f659263b5fb2385e4c231cc075bd84 ] Without this, the drm core advertises LINEAR modifier which is incorrect. Also userspace virgl does not support modifiers. For example, it causes chrome on ozone/drm to fail with "Failed to create scanout buffer". Fixes: 2af104290da5 ("drm: introduce fb_modifiers_not_supported flag in mode_config") Suggested-by: Shao-Chuan Lee Signed-off-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20220831190601.1295129-1-olvaffe@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit d6e150e84f168de8d40795128a5d53b2fe9a3d87 Author: Takashi Iwai Date: Tue Sep 6 11:23:06 2022 +0200 ALSA: hda: beep: Simplify keep-power-at-enable behavior [ Upstream commit 4c8d695cb9bc5f6fd298a586602947b2fc099a64 ] The recent fix for IDT codecs to keep the power up while the beep is enabled can be better integrated into the beep helper code. This patch cleans up the code with refactoring. Fixes: 414d38ba8710 ("ALSA: hda/sigmatel: Keep power up while beep is enabled") Link: https://lore.kernel.org/r/20220906092306.26183-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 45416de9ad462030a501ab1e6455b76d3d4383d6 Author: Cristian Ciocaltea Date: Fri Aug 26 01:05:30 2022 +0300 ASoC: wm_adsp: Handle optional legacy support [ Upstream commit 35c8ae25c4fdeabf490e005692795a3be17ca5f6 ] The tracing capabilities for the speaker protection fw enabled via commit c55b3e46cb99 ("ASoC: wm_adsp: Add trace caps to speaker protection FW") are not be available on all platforms, such as the Valve's Steam Deck which is based on the Halo Core DSP. As a consequence, whenever the firmware is loaded, a rather misleading 'Failed to parse legacy: -19' error message is written to the kernel ring buffer: [ 288.977412] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Firmware version: 3 [ 288.978002] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: cs35l41-dsp1-spk-prot.wmfw: Fri 02 Apr 2021 21:03:50 W. Europe Daylight Time [ 289.094065] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Firmware: 400a4 vendor: 0x2 v0.33.0, 2 algorithms [ 289.095073] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: 0: ID cd v29.53.0 XM@94 YM@e [ 289.095665] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: 1: ID f20b v0.0.1 XM@170 YM@0 [ 289.096275] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Protection: C:\Users\ocanavan\Desktop\cirrusTune_july2021.bin [ 291.172383] steamdeck kernel: cs35l41 spi-VLV1776:01: DSP1: Failed to parse legacy: -19 Update wm_adsp_buffer_init() to print a more descriptive info message when wm_adsp_buffer_parse_legacy() returns -ENODEV. Fixes: c55b3e46cb99 ("ASoC: wm_adsp: Add trace caps to speaker protection FW") Signed-off-by: Cristian Ciocaltea Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20220825220530.1205141-1-cristian.ciocaltea@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3f8546391e039974d11583830d63d1577885eb2a Author: Jiasheng Jiang Date: Fri Sep 2 09:30:30 2022 +0800 ASoC: rsnd: Add check for rsnd_mod_power_on [ Upstream commit 376be51caf8871419bbcbb755e1e615d30dc3153 ] As rsnd_mod_power_on() can return negative numbers, it should be better to check the return value and deal with the exception. Fixes: e7d850dd10f4 ("ASoC: rsnd: use mod base common method on SSI-parent") Signed-off-by: Jiasheng Jiang Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20220902013030.3691266-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 93e06be3f518b42434c29124e5dce8a463d60bbb Author: Pin-yen Lin Date: Tue Aug 30 12:57:56 2022 +0800 drm/bridge: it6505: Fix the order of DP_SET_POWER commands [ Upstream commit 7c1dceaffd99247bf443606730515b54d6285969 ] Send DP_SET_POWER_D3 command to the downstream before stopping DP, so the suspend process will not be interrupted by the HPD interrupt. Also modify the order in .atomic_enable callback to make the callbacks symmetric. Fixes: 46ca7da7f1e8 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream") Signed-off-by: Pin-yen Lin Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220830045756.1655954-1-treapking@chromium.org Signed-off-by: Sasha Levin commit 21764467ab396d9f08921e0a5ffa1214244e1ad9 Author: Zheyu Ma Date: Tue Aug 30 15:34:50 2022 +0800 drm/bridge: megachips: Fix a null pointer dereference bug [ Upstream commit 1ff673333d46d2c1b053ebd0c1c7c7c79e36943e ] When removing the module we will get the following warning: [ 31.911505] i2c-core: driver [stdp2690-ge-b850v3-fw] unregistered [ 31.912484] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI [ 31.913338] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] [ 31.915280] RIP: 0010:drm_bridge_remove+0x97/0x130 [ 31.921825] Call Trace: [ 31.922533] stdp4028_ge_b850v3_fw_remove+0x34/0x60 [megachips_stdpxxxx_ge_b850v3_fw] [ 31.923139] i2c_device_remove+0x181/0x1f0 The two bridges (stdp2690, stdp4028) do not probe at the same time, so the driver does not call ge_b850v3_resgiter() when probing, causing the driver to try to remove the object that has not been initialized. Fix this by checking whether both the bridges are probed. Fixes: 11632d4aa2b3 ("drm/bridge: megachips: Ensure both bridges are probed before registration") Signed-off-by: Zheyu Ma Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220830073450.1897020-1-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit be6ad75a500ef0f86c52300abf7af7e3f621745f Author: Yang Yingliang Date: Fri Aug 26 16:57:54 2022 +0800 drm/amdgpu: add missing pci_disable_device() in amdgpu_pmops_runtime_resume() [ Upstream commit 6b11af6d1c8f5d4135332bb932baaa06e511173d ] Add missing pci_disable_device() if amdgpu_device_resume() fails. Fixes: 8e4d5d43cc6c ("drm/amdgpu: Handling of amdgpu_device_resume return value for graceful teardown") Signed-off-by: Yang Yingliang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2c9db240575c6596a4b0a09641b13160f9c9fc9d Author: Prashant Malani Date: Fri Aug 19 19:08:03 2022 +0000 platform/chrome: cros_ec_typec: Correct alt mode index [ Upstream commit 4e477663e396f48c5cfc5f2d75d4b514f409516a ] Alt mode indices used by USB PD (Power Delivery) start with 1, not 0. Update the alt mdoe registration code to factor this in to the alt mode descriptor. Fixes: de0f49487db3 ("platform/chrome: cros_ec_typec: Register partner altmodes") Signed-off-by: Prashant Malani Acked-by: Heikki Krogerus Reviewed-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220819190807.1275937-3-pmalani@chromium.org Signed-off-by: Sasha Levin commit 862f641cadf1c675daa0d139187d60034911ba64 Author: Hans de Goede Date: Thu Aug 25 16:13:36 2022 +0200 platform/x86: msi-laptop: Fix resource cleanup [ Upstream commit 5523632aa10f906dfe2eb714ee748590dc7fc6b1 ] Fix the input-device not getting free-ed on probe-errors and fix the msi_touchpad_dwork not getting cancelled on neither probe-errors nor on remove. Fixes: 143a4c0284dc ("msi-laptop: send out touchpad on/off key") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220825141336.208597-3-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 21cd17aedbbf52c1a44bca8c667411ad8b717a8e Author: Hans de Goede Date: Thu Aug 25 16:13:34 2022 +0200 platform/x86: msi-laptop: Fix old-ec check for backlight registering [ Upstream commit 83ac7a1c2ed5f17caa07cbbc84bad3c05dc3bf22 ] Commit 2cc6c717799f ("msi-laptop: Port to new backlight interface selection API") replaced this check: if (!quirks->old_ec_model || acpi_video_backlight_support()) pr_info("Brightness ignored, ..."); else do_register(); With: if (quirks->old_ec_model || acpi_video_get_backlight_type() == acpi_backlight_vendor) do_register(); But since the do_register() part was part of the else branch, the entire condition should be inverted. So not only the 2 statements on either side of the || should be inverted, but the || itself should be replaced with a &&. In practice this has likely not been an issue because the new-ec models (old_ec_model==false) likely all support ACPI video backlight control, making acpi_video_get_backlight_type() return acpi_backlight_video turning the second part of the || also false when old_ec_model == false. Fixes: 2cc6c717799f ("msi-laptop: Port to new backlight interface selection API") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20220825141336.208597-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit f8365e4ae5b113c01d14ce382a684bf40e3df6b2 Author: Martin Povišer Date: Thu Aug 25 16:02:39 2022 +0200 ASoC: tas2764: Fix mute/unmute [ Upstream commit f5ad67f13623548e5aff847f89700c178aaf2a98 ] Because the PWR_CTRL field is modeled as the power state of the DAC widget, and at the same time it is used to implement mute/unmute, we need some additional book-keeping to have the right end result no matter the sequence of calls. Without this fix, one permanently mutes an ongoing stream by toggling the associated speaker pin control. (This mirrors commit 1e5907bcb3a3 ("ASoC: tas2770: Fix handling of mute/unmute") which was a fix to the tas2770 driver.) Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20220825140241.53963-4-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7960f1a4cb2f9b242be6303b08eec5d42e5305a3 Author: Martin Povišer Date: Thu Aug 25 16:02:38 2022 +0200 ASoC: tas2764: Drop conflicting set_bias_level power setting [ Upstream commit 09273f38832406db19a8907a934687cc10660a6b ] The driver is setting the PWR_CTRL field in both the set_bias_level callback and on DAPM events of the DAC widget (and also in the mute_stream method). Drop the set_bias_level callback altogether as the power setting it does is in conflict with the other code paths. (This mirrors commit c8a6ae3fe1c8 ("ASoC: tas2770: Drop conflicting set_bias_level power setting") which was a fix to the tas2770 driver.) Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20220825140241.53963-3-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9575bd32c344622ba77067e000e7e393c588a46f Author: Martin Povišer Date: Thu Aug 25 16:02:37 2022 +0200 ASoC: tas2764: Allow mono streams [ Upstream commit 23204d928a27146d13e11c9383632775345ecca8 ] The part is a mono speaker amp, but it can do downmix and switch between left and right channel, so the right channel range is 1 to 2. (This mirrors commit bf54d97a835d ("ASoC: tas2770: Allow mono streams") which was a fix to the tas2770 driver.) Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764") Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20220825140241.53963-2-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1f35a8afe8db7d921d074ad87c485b7ad878f7d2 Author: Kuninori Morimoto Date: Mon Aug 22 02:35:32 2022 +0000 ASoC: soc-pcm.c: call __soc_pcm_close() in soc_pcm_close() [ Upstream commit 6bbabd28805f36baf6d0f3eb082db032a638f612 ] commit b7898396f4bbe16 ("ASoC: soc-pcm: Fix and cleanup DPCM locking") added __soc_pcm_close() for non-lock version of soc_pcm_close(). But soc_pcm_close() is not using it. It is no problem, but confusable. static int __soc_pcm_close(...) { => return soc_pcm_clean(rtd, substream, 0); } static int soc_pcm_close(...) { ... snd_soc_dpcm_mutex_lock(rtd); => soc_pcm_clean(rtd, substream, 0); snd_soc_dpcm_mutex_unlock(rtd); return 0; } This patch use it. Fixes: b7898396f4bbe16 ("ASoC: soc-pcm: Fix and cleanup DPCM locking") Cc: Takashi Iwai Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87czctgg3w.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit cfbf43124e0dbfd0092847f6bb137199e5d2ddfe Author: Rob Clark Date: Fri Aug 12 15:40:00 2022 -0700 drm/virtio: Fix same-context optimization [ Upstream commit 3007dc2af6e86ac00b4daf7414142637fdf50bfa ] When VIRTGPU_EXECBUF_RING_IDX is used, we should be considering the timeline that the EB if running on rather than the global driver fence context. Fixes: 85c83ea915ed ("drm/virtio: implement context init: allocate an array of fence contexts") Signed-off-by: Rob Clark Link: http://patchwork.freedesktop.org/patch/msgid/20220812224001.2806463-1-robdclark@gmail.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit f143f1d9a8e5c6c9db3de81ca270191226fcce36 Author: Dan Carpenter Date: Fri Aug 19 08:20:36 2022 +0300 platform/chrome: fix memory corruption in ioctl [ Upstream commit 8a07b45fd3c2dda24fad43639be5335a4595196a ] If "s_mem.bytes" is larger than the buffer size it leads to memory corruption. Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC") Signed-off-by: Dan Carpenter Reviewed-by: Guenter Roeck Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/Yv8dpCFZJdbUT5ye@kili Signed-off-by: Sasha Levin commit c2fbf1b1fff638beac33f20b960b71125a5449a8 Author: Rustam Subkhankulov Date: Sun Aug 14 01:08:43 2022 +0300 platform/chrome: fix double-free in chromeos_laptop_prepare() [ Upstream commit 6ad4194d6a1e1d11b285989cd648ef695b4a93c0 ] If chromeos_laptop_prepare_i2c_peripherals() fails after allocating memory for 'cros_laptop->i2c_peripherals', this memory is freed at 'err_out' label and nonzero value is returned. Then chromeos_laptop_destroy() is called, resulting in double-free error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Rustam Subkhankulov Fixes: 5020cd29d8bf ("platform/chrome: chromeos_laptop - supply properties for ACPI devices") Reviewed-by: Dmitry Torokhov Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220813220843.2373004-1-subkhankulov@ispras.ru Signed-off-by: Sasha Levin commit 26f9a766f87b33c50ed400a9500cc1dc9aced953 Author: Javier Martinez Canillas Date: Tue Aug 16 15:46:12 2022 +0200 drm/msm: Make .remove and .shutdown HW shutdown consistent [ Upstream commit 0a58d2ae572adaec8d046f8d35b40c2c32ac7468 ] Drivers' .remove and .shutdown callbacks are executed on different code paths. The former is called when a device is removed from the bus, while the latter is called at system shutdown time to quiesce the device. This means that some overlap exists between the two, because both have to take care of properly shutting down the hardware. But currently the logic used in these two callbacks isn't consistent in msm drivers, which could lead to kernel panic. For example, on .remove the component is deleted and its .unbind callback leads to the hardware being shutdown but only if the DRM device has been marked as registered. That check doesn't exist in the .shutdown logic and this can lead to the driver calling drm_atomic_helper_shutdown() for a DRM device that hasn't been properly initialized. A situation like this can happen if drivers for expected sub-devices fail to probe, since the .bind callback will never be executed. If that is the case, drm_atomic_helper_shutdown() will attempt to take mutexes that are only initialized if drm_mode_config_init() is called during a device bind. This bug was attempted to be fixed in commit 623f279c7781 ("drm/msm: fix shutdown hook in case GPU components failed to bind"), but unfortunately it still happens in some cases as the one mentioned above, i.e: systemd-shutdown[1]: Powering off. kvm: exiting hardware virtualization platform wifi-firmware.0: Removing from iommu group 12 platform video-firmware.0: Removing from iommu group 10 ------------[ cut here ]------------ WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0 ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0 lr : drm_modeset_lock_all_ctx+0x48/0x3d0 sp : ffff80000805bb80 x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030 x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800 x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0 Call trace: drm_modeset_lock_all_ctx+0x3c4/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 ---[ end trace 0000000000000000 ]--- Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000 [0000000000000018] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP ... Hardware name: Google CoachZ (rev3+) (DT) pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ww_mutex_lock+0x28/0x32c lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0 sp : ffff80000805bb50 x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000001 x24: 0000000000000018 x23: ffff80000805bc10 x22: ffff327c039c5ad8 x21: ffff327c039c5800 x20: ffff80000805bbe8 x19: 0000000000000018 x18: 0000000000000034 x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000 x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff327c00128000 x1 : 0000000000000000 x0 : 0000000000000018 Call trace: ww_mutex_lock+0x28/0x32c drm_modeset_lock_all_ctx+0x1b0/0x3d0 drm_atomic_helper_shutdown+0x70/0x134 msm_drv_shutdown+0x30/0x40 platform_shutdown+0x28/0x40 device_shutdown+0x148/0x350 kernel_power_off+0x38/0x80 __do_sys_reboot+0x288/0x2c0 __arm64_sys_reboot+0x28/0x34 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0x44/0xec do_el0_svc+0x2c/0xc0 el0_svc+0x2c/0x84 el0t_64_sync_handler+0x11c/0x150 el0t_64_sync+0x18c/0x190 Code: aa0103f4 d503201f d2800001 aa0103e3 (c8e37c02) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Kernel Offset: 0x495d77c00000 from 0xffff800008000000 PHYS_OFFSET: 0xffffcd8500000000 CPU features: 0x800,00c2a015,19801c82 Memory Limit: none ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver") Signed-off-by: Javier Martinez Canillas Reviewed-by: Abhinav Kumar Link: https://patchwork.freedesktop.org/patch/msgid/20220816134612.916527-1-javierm@redhat.com Signed-off-by: Sasha Levin commit 4e5287acc036f52fff99535a78049077ffd0e523 Author: Dan Carpenter Date: Thu Aug 11 14:01:26 2022 +0300 ASoC: mt6359: fix tests for platform_get_irq() failure [ Upstream commit 51eea3a6fb4d39c2cc71824e6eee5949d7ae4d1c ] The platform_get_irq() returns negative error codes. It can't actually return zero, but if it did that should be treated as success. Fixes: eef07b9e0925 ("ASoC: mediatek: mt6359: add MT6359 accdet jack driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YvThhr86N3qQM2EO@kili Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a656ff69fe13d1792b92f633e8c0d2362c0ca5ee Author: Liang He Date: Mon Jul 11 21:15:50 2022 +0800 drm:pl111: Add of_node_put() when breaking out of for_each_available_child_of_node() [ Upstream commit e0686dc6f2252e009c455fe99e2ce9d62a60eb47 ] The reference 'child' in the iteration of for_each_available_child_of_node() is only escaped out into a local variable which is only used to check its value. So we still need to the of_node_put() when breaking of the for_each_available_child_of_node() which will automatically increase and decrease the refcount. Fixes: ca454bd42dc2 ("drm/pl111: Support the Versatile Express") Signed-off-by: Liang He Reviewed-by: Rob Herring Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220711131550.361350-1-windhl@126.com Signed-off-by: Sasha Levin commit 79878d6829b53c392c20f25208ba8d8a5ce4fbd4 Author: Simon Ser Date: Thu Feb 10 15:40:25 2022 +0000 drm/dp_mst: fix drm_dp_dpcd_read return value checks [ Upstream commit 2ac6cdd581f48c8f68747156fde5868486a44985 ] drm_dp_dpcd_read returns the number of bytes read. The previous code would print garbage on DPCD error, and would exit with on error on success. Signed-off-by: Simon Ser Fixes: cb897542c6d2 ("drm/dp_mst: Fix W=1 warnings") Cc: Lyude Paul Cc: Benjamin Gaignard Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/473500/ Signed-off-by: Sasha Levin commit fd85e0eeaa6519dd367b4e0800cb123dc464ba67 Author: Chen-Yu Tsai Date: Thu Jul 21 17:22:58 2022 +0800 drm/bridge: parade-ps8640: Fix regulator supply order [ Upstream commit fc94224c2e0ae8d83ac511a3ef4962178505469d ] The datasheet says that VDD12 must be enabled and at full voltage before VDD33 is enabled. Reorder the bulk regulator supply names so that VDD12 is enabled before VDD33. Any enable ramp delays should be handled by setting proper constraints on the regulators. Fixes: bc1aee7fc8f0 ("drm/bridge: Add I2C based driver for ps8640 bridge") Signed-off-by: Chen-Yu Tsai Reviewed-by: Neil Armstrong Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220721092258.3397461-1-wenst@chromium.org Signed-off-by: Sasha Levin commit 38edd69b0065b3a9001679bea3e1b4d922e8c033 Author: Liang He Date: Tue Jul 19 14:54:47 2022 +0800 drm/bridge: tc358767: Add of_node_put() when breaking out of loop [ Upstream commit 14e7157afb055248ed34901fcd6fbf54201cfea1 ] In tc_probe_bridge_endpoint(), we should call of_node_put() when breaking out of the for_each_endpoint_of_node() which will automatically increase and decrease the refcount. Fixes: 71f7d9c03118 ("drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT") Signed-off-by: Liang He Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220719065447.1080817-2-windhl@126.com Signed-off-by: Sasha Levin commit 61d0c94c3725bae24d3632daf1661b0f52e90158 Author: Dmitry Osipenko Date: Thu Jun 30 23:07:18 2022 +0300 drm/virtio: Correct drm_gem_shmem_get_sg_table() error handling [ Upstream commit 64b88afbd92fbf434759d1896a7cf705e1c00e79 ] Previous commit fixed checking of the ERR_PTR value returned by drm_gem_shmem_get_sg_table(), but it missed to zero out the shmem->pages, which will crash virtio_gpu_cleanup_object(). Add the missing zeroing of the shmem->pages. Fixes: c24968734abf ("drm/virtio: Fix NULL vs IS_ERR checking in virtio_gpu_object_shmem_init") Reviewed-by: Emil Velikov Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-2-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 99fae8294e2860738b8a401ac18a25b44374108a Author: Pin-Yen Lin Date: Thu Jul 14 17:39:20 2022 +0800 drm/bridge: it6505: Power on downstream device in .atomic_enable [ Upstream commit fbc1fdaa8338ec4ebd862d918a0ce3e12033e8a3 ] Send DPCD DP_SET_POWER_D0 command to the monitor in .atomic_enable callback. Without this command, some monitors won't show up again after changing the resolution. Fixes: 46ca7da7f1e8 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream") Signed-off-by: Pin-Yen Lin Reviewed-by: Allen Chen Fixes: 46ca7da7f1e8 ("drm/bridge: it6505: Send DPCD SET_POWER to downstream") Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220714173715.v2.1.I85af54e9ceda74ec69f661852825845f983fc343@changeid Signed-off-by: Sasha Levin commit 353ab1c13fdd6e524edde780235a8ce9b892c81c Author: Maxime Ripard Date: Mon Jul 11 19:38:31 2022 +0200 drm/mipi-dsi: Detach devices when removing the host [ Upstream commit 668a8f17b5290d04ef7343636a5588a0692731a1 ] Whenever the MIPI-DSI host is unregistered, the code of mipi_dsi_host_unregister() loops over every device currently found on that bus and will unregister it. However, it doesn't detach it from the bus first, which leads to all kind of resource leaks if the host wants to perform some clean up whenever a device is detached. Fixes: 068a00233969 ("drm: Add MIPI DSI bus support") Acked-by: Thomas Zimmermann Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20220711173939.1132294-2-maxime@cerno.tech Signed-off-by: Sasha Levin commit 3051f34c01935d14f09f7d0c7fb1cd568d6e3e81 Author: Dan Carpenter Date: Mon Jul 4 13:55:40 2022 +0300 drm/bridge: Avoid uninitialized variable warning [ Upstream commit 7d1202738efda60155d98b370b3c70d336be0eea ] This code works, but technically it uses "num_in_bus_fmts" before it has been initialized so it leads to static checker warnings and probably KMEMsan warnings at run time. Initialize the variable to zero to silence the warning. Fixes: f32df58acc68 ("drm/bridge: Add the necessary bits to support bus format negotiation") Signed-off-by: Dan Carpenter Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/YrrIs3hoGcPVmXc5@kili Signed-off-by: Sasha Levin commit 4d4d5bc659206b187263190ad9a03513f625659d Author: Alvin Šipraga Date: Sun Jun 12 16:48:54 2022 +0200 drm: bridge: adv7511: unregister cec i2c device after cec adapter [ Upstream commit 40cdb02cb9f965732eb543d47f15bef8d10f0f5f ] cec_unregister_adapter() assumes that the underlying adapter ops are callable. For example, if the CEC adapter currently has a valid physical address, then the unregistration procedure will invalidate the physical address by setting it to f.f.f.f. Whence the following kernel oops observed after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]--- Protect against this scenario by unregistering i2c_cec after unregistering the CEC adapter. Duly disable the CEC clock afterwards too. Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support") Signed-off-by: Alvin Šipraga Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220612144854.2223873-3-alvin@pqrs.dk Signed-off-by: Sasha Levin commit 903c2b9bced8636a5853c34c7c20db4d2903c592 Author: Alvin Šipraga Date: Sun Jun 12 16:48:53 2022 +0200 drm: bridge: adv7511: fix CEC power down control register offset [ Upstream commit 1d22b6033ea113a4c3850dfa2c0770885c81aec8 ] The ADV7511_REG_CEC_CTRL = 0xE2 register is part of the main register map - not the CEC register map. As such, we shouldn't apply an offset to the register address. Doing so will cause us to address a bogus register for chips with a CEC register map offset (e.g. ADV7533). Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support") Signed-off-by: Alvin Šipraga Reviewed-by: Robert Foss Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20220612144854.2223873-2-alvin@pqrs.dk Signed-off-by: Sasha Levin commit 169aa2664639de359a7c723ba55023ef57c0dc15 Author: Russell King (Oracle) Date: Mon Oct 3 17:19:27 2022 +0100 net: mvpp2: fix mvpp2 debugfs leak [ Upstream commit 0152dfee235e87660f52a117fc9f70dc55956bb4 ] When mvpp2 is unloaded, the driver specific debugfs directory is not removed, which technically leads to a memory leak. However, this directory is only created when the first device is probed, so the hardware is present. Removing the module is only something a developer would to when e.g. testing out changes, so the module would be reloaded. So this memory leak is minor. The original attempt in commit fe2c9c61f668 ("net: mvpp2: debugfs: fix memory leak when using debugfs_lookup()") that was labelled as a memory leak fix was not, it fixed a refcount leak, but in doing so created a problem when the module is reloaded - the directory already exists, but mvpp2_root is NULL, so we lose all debugfs entries. This fix has been reverted. This is the alternative fix, where we remove the offending directory whenever the driver is unloaded. Fixes: 21da57a23125 ("net: mvpp2: add a debugfs interface for the Header Parser") Signed-off-by: Russell King (Oracle) Reviewed-by: Greg Kroah-Hartman Reviewed-by: Marcin Wojtas Link: https://lore.kernel.org/r/E1ofOAB-00CzkG-UO@rmk-PC.armlinux.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b0eb0d577635a5e5e4ac4a034a38a1e8b0b7a933 Author: Eric Dumazet Date: Sat Oct 1 13:51:02 2022 -0700 once: add DO_ONCE_SLOW() for sleepable contexts [ Upstream commit 62c07983bef9d3e78e71189441e1a470f0d1e653 ] Christophe Leroy reported a ~80ms latency spike happening at first TCP connect() time. This is because __inet_hash_connect() uses get_random_once() to populate a perturbation table which became quite big after commit 4c2c8f03a5ab ("tcp: increase source port perturb table to 2^16") get_random_once() uses DO_ONCE(), which block hard irqs for the duration of the operation. This patch adds DO_ONCE_SLOW() which uses a mutex instead of a spinlock for operations where we prefer to stay in process context. Then __inet_hash_connect() can use get_random_slow_once() to populate its perturbation table. Fixes: 4c2c8f03a5ab ("tcp: increase source port perturb table to 2^16") Fixes: 190cc82489f4 ("tcp: change source port randomizarion at connect() time") Reported-by: Christophe Leroy Link: https://lore.kernel.org/netdev/CANn89iLAEYBaoYajy0Y9UmGFff5GPxDUoG-ErVB2jDdRNQ5Tug@mail.gmail.com/T/#t Signed-off-by: Eric Dumazet Cc: Willy Tarreau Tested-by: Christophe Leroy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51d4260585cf36106d29dcefeafa09d9cd5972cf Author: Tetsuo Handa Date: Sun Oct 2 01:43:44 2022 +0900 net/ieee802154: reject zero-sized raw_sendmsg() [ Upstream commit 3a4d061c699bd3eedc80dc97a4b2a2e1af83c6f5 ] syzbot is hitting skb_assert_len() warning at raw_sendmsg() for ieee802154 socket. What commit dc633700f00f726e ("net/af_packet: check len when min_header_len equals to 0") does also applies to ieee802154 socket. Link: https://syzkaller.appspot.com/bug?extid=5ea725c25d06fb9114c4 Reported-by: syzbot Fixes: fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len") Signed-off-by: Tetsuo Handa Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 39365e1b0eb56cd221c7b1c5ff7a59c2a1e91a56 Author: Maxim Mikityanskiy Date: Sat Oct 1 13:57:13 2022 +0300 net: wwan: iosm: Call mutex_init before locking it [ Upstream commit ba0fbdb95da5ddd8db457ce6ba09d16dd979a294 ] wwan_register_ops calls wwan_create_default_link, which ends up in the ipc_wwan_newlink callback that locks ipc_wwan->if_mutex. However, this mutex is not yet initialized by that point. Fix it by moving mutex_init above the wwan_register_ops call. This also makes the order of operations in ipc_wwan_init symmetric to ipc_wwan_deinit. Fixes: 83068395bbfc ("net: iosm: create default link via WWAN core") Signed-off-by: Maxim Mikityanskiy Reviewed-by: M Chetan Kumar Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b47bc8202b31a2677a344322b3c4b7f8750c5e66 Author: Zheng Wang Date: Sat Oct 1 01:57:25 2022 +0800 eth: sp7021: fix use after free bug in spl2sw_nvmem_get_mac_address [ Upstream commit 12aece8b01507a2d357a1861f470e83621fbb6f2 ] This frees "mac" and tries to display its address as part of the error message on the next line. Swap the order. Fixes: fd3040b9394c ("net: ethernet: Add driver for Sunplus SP7021") Signed-off-by: Zheng Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 96c0c14135f5803f9e94e6da2ee9c4b012fdcb20 Author: Jianglei Nie Date: Fri Sep 30 14:28:43 2022 +0800 bnx2x: fix potential memory leak in bnx2x_tpa_stop() [ Upstream commit b43f9acbb8942b05252be83ac25a81cec70cc192 ] bnx2x_tpa_stop() allocates a memory chunk from new_data with bnx2x_frag_alloc(). The new_data should be freed when gets some error. But when "pad + len > fp->rx_buf_size" is true, bnx2x_tpa_stop() returns without releasing the new_data, which will lead to a memory leak. We should free the new_data with bnx2x_frag_free() when "pad + len > fp->rx_buf_size" is true. Fixes: 07b0f00964def8af9321cfd6c4a7e84f6362f728 ("bnx2x: fix possible panic under memory stress") Signed-off-by: Jianglei Nie Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d06ee1cbffc6a84ef28a65beec1a2c19b830c77a Author: Raju Lakkaraju Date: Fri Sep 30 14:57:40 2022 +0530 eth: lan743x: reject extts for non-pci11x1x devices [ Upstream commit cb4b12071a4b68df323c339f60805834246b3e9e ] Remove PTP_PF_EXTTS support for non-PCI11x1x devices since they do not support the PTP-IO Input event triggered timestamping mechanisms added Fixes: 60942c397af6 ("net: lan743x: Add support for PTP-IO Event Input External Timestamp (extts)") Signed-off-by: Raju Lakkaraju Reviewed-by: Horatiu Vultur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 49c1729b5563c21ad91d6f794881465ef86e0f46 Author: Jiasheng Jiang Date: Fri Sep 30 12:48:43 2022 +0800 net: prestera: acl: Add check for kmemdup [ Upstream commit 9e6fd874c7bb47b6a4295abc4c81b2f41b97e970 ] As the kemdup could return NULL, it should be better to check the return value and return error if fails. Moreover, the return value of prestera_acl_ruleset_keymask_set() should be checked by cascade. Fixes: 604ba230902d ("net: prestera: flower template support") Signed-off-by: Jiasheng Jiang Reviewed-by: Taras Chornyi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e2e49822a0a16d306bf6fe0009fe3136a3318f36 Author: Kuniyuki Iwashima Date: Thu Sep 29 08:52:04 2022 -0700 af_unix: Fix memory leaks of the whole sk due to OOB skb. [ Upstream commit 7a62ed61367b8fd01bae1e18e30602c25060d824 ] syzbot reported a sequence of memory leaks, and one of them indicated we failed to free a whole sk: unreferenced object 0xffff8880126e0000 (size 1088): comm "syz-executor419", pid 326, jiffies 4294773607 (age 12.609s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 7d 00 00 00 00 00 00 00 ........}....... 01 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000006fefe750>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:1970 [<0000000074006db5>] sk_alloc+0x3b/0x800 net/core/sock.c:2029 [<00000000728cd434>] unix_create1+0xaf/0x920 net/unix/af_unix.c:928 [<00000000a279a139>] unix_create+0x113/0x1d0 net/unix/af_unix.c:997 [<0000000068259812>] __sock_create+0x2ab/0x550 net/socket.c:1516 [<00000000da1521e1>] sock_create net/socket.c:1566 [inline] [<00000000da1521e1>] __sys_socketpair+0x1a8/0x550 net/socket.c:1698 [<000000007ab259e1>] __do_sys_socketpair net/socket.c:1751 [inline] [<000000007ab259e1>] __se_sys_socketpair net/socket.c:1748 [inline] [<000000007ab259e1>] __x64_sys_socketpair+0x97/0x100 net/socket.c:1748 [<000000007dedddc1>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<000000007dedddc1>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<000000009456679f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd We can reproduce this issue by creating two AF_UNIX SOCK_STREAM sockets, send()ing an OOB skb to each other, and close()ing them without consuming the OOB skbs. int skpair[2]; socketpair(AF_UNIX, SOCK_STREAM, 0, skpair); send(skpair[0], "x", 1, MSG_OOB); send(skpair[1], "x", 1, MSG_OOB); close(skpair[0]); close(skpair[1]); Currently, we free an OOB skb in unix_sock_destructor() which is called via __sk_free(), but it's too late because the receiver's unix_sk(sk)->oob_skb is accounted against the sender's sk->sk_wmem_alloc and __sk_free() is called only when sk->sk_wmem_alloc is 0. In the repro sequences, we do not consume the OOB skb, so both two sk's sock_put() never reach __sk_free() due to the positive sk->sk_wmem_alloc. Then, no one can consume the OOB skb nor call __sk_free(), and we finally leak the two whole sk. Thus, we must free the unconsumed OOB skb earlier when close()ing the socket. Fixes: 314001f0bf92 ("af_unix: Add OOB support") Reported-by: syzbot Signed-off-by: Kuniyuki Iwashima Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c380c28ab9b15fc53565909c814f6dd3e7f77c4b Author: Tetsuo Handa Date: Thu Sep 29 00:25:37 2022 +0900 net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks() [ Upstream commit a91b750fd6629354460282bbf5146c01b05c4859 ] syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], for commit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in rds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a section protected by lock_sock() without realizing that rds_send_xmit() might call lock_sock(). We don't need to protect cancel_delayed_work_sync() using lock_sock(), for even if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete, retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UP bit. Link: https://syzkaller.appspot.com/bug?extid=78c55c7bc6f66e53dce2 [1] Reported-by: syzbot Co-developed-by: Hillf Danton Signed-off-by: Hillf Danton Signed-off-by: Tetsuo Handa Tested-by: syzbot Fixes: ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication in rds_tcp_reset_callbacks()") Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 248bed1dbf5a40e38e0c9b0a02214969af7e6a04 Author: Oleksandr Shamray Date: Thu Sep 29 15:16:42 2022 +0300 hwmon: (pmbus/mp2888) Fix sensors readouts for MPS Multi-phase mp2888 controller [ Upstream commit 525dd5aed67a2f4f7278116fb92a24e6a53e2622 ] Fix scale factors for reading MPS Multi-phase mp2888 controller. Fixed sensors: - PIN/POUT: based on vendor documentation, set bscale factor 0.5W/LSB - IOUT: based on vendor documentation, set scale factor 0.25 A/LSB Fixes: e4db7719d037 ("hwmon: (pmbus) Add support for MPS Multi-phase mp2888 controller") Signed-off-by: Oleksandr Shamray Reviewed-by: Vadim Pasternak Link: https://lore.kernel.org/r/20220929121642.63051-1-oleksandrs@nvidia.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 742e595f1949171ddcb1c6560d6619ae61c0e9db Author: Luiz Augusto von Dentz Date: Fri Sep 30 13:12:30 2022 -0700 Bluetooth: hci_sync: Fix not indicating power state [ Upstream commit 6abf0dae8c3c927f54e62c46faf8aba580ba0d04 ] When setting power state using legacy/non-mgmt API (e.g hcitool hci0 up) the likes of mgmt_set_powered_complete won't be called causing clients of the MGMT API to not be notified of the change of the state. Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Signed-off-by: Luiz Augusto von Dentz Tested-by: Tedd Ho-Jeong An Signed-off-by: Sasha Levin commit 37ad7c5990c038060cca8e6a87a93399f5a6dfc2 Author: Marek Szyprowski Date: Fri Sep 30 13:34:08 2022 +0200 spi: Ensure that sg_table won't be used after being freed [ Upstream commit 8e9204cddcc3fea9affcfa411715ba4f66e97587 ] SPI code checks for non-zero sgt->orig_nents to determine if the buffer has been DMA-mapped. Ensure that sg_table is really zeroed after free to avoid potential NULL pointer dereference if the given SPI xfer object is reused again without being DMA-mapped. Fixes: 0c17ba73c08f ("spi: Fix cache corruption due to DMA/PIO overlap") Signed-off-by: Marek Szyprowski Link: https://lore.kernel.org/r/20220930113408.19720-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ccbfe4d0bce465d3af8c39041a7b02014ca31b09 Author: Neal Cardwell Date: Wed Sep 28 16:03:31 2022 -0400 tcp: fix tcp_cwnd_validate() to not forget is_cwnd_limited [ Upstream commit f4ce91ce12a7c6ead19b128ffa8cff6e3ded2a14 ] This commit fixes a bug in the tracking of max_packets_out and is_cwnd_limited. This bug can cause the connection to fail to remember that is_cwnd_limited is true, causing the connection to fail to grow cwnd when it should, causing throughput to be lower than it should be. The following event sequence is an example that triggers the bug: (a) The connection is cwnd_limited, but packets_out is not at its peak due to TSO deferral deciding not to send another skb yet. In such cases the connection can advance max_packets_seq and set tp->is_cwnd_limited to true and max_packets_out to a small number. (b) Then later in the round trip the connection is pacing-limited (not cwnd-limited), and packets_out is larger. In such cases the connection would raise max_packets_out to a bigger number but (unexpectedly) flip tp->is_cwnd_limited from true to false. This commit fixes that bug. One straightforward fix would be to separately track (a) the next window after max_packets_out reaches a maximum, and (b) the next window after tp->is_cwnd_limited is set to true. But this would require consuming an extra u32 sequence number. Instead, to save space we track only the most important information. Specifically, we track the strongest available signal of the degree to which the cwnd is fully utilized: (1) If the connection is cwnd-limited then we remember that fact for the current window. (2) If the connection not cwnd-limited then we track the maximum number of outstanding packets in the current window. In particular, note that the new logic cannot trigger the buggy (a)/(b) sequence above because with the new logic a condition where tp->packets_out > tp->max_packets_out can only trigger an update of tp->is_cwnd_limited if tp->is_cwnd_limited is false. This first showed up in a testing of a BBRv2 dev branch, but this buggy behavior highlighted a general issue with the tcp_cwnd_validate() logic that can cause cwnd to fail to increase at the proper rate for any TCP congestion control, including Reno or CUBIC. Fixes: ca8a22634381 ("tcp: make cwnd-limited checks measurement-based, and gentler") Signed-off-by: Neal Cardwell Signed-off-by: Kevin(Yudong) Yang Signed-off-by: Yuchung Cheng Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0f90099d18e3abdc01babf686f41f63fe04939c1 Author: Xin Long Date: Wed Sep 28 14:10:13 2022 -0400 sctp: handle the error returned from sctp_auth_asoc_init_active_key [ Upstream commit 022152aaebe116a25c39818a07e175a8cd3c1e11 ] When it returns an error from sctp_auth_asoc_init_active_key(), the active_key is actually not updated. The old sh_key will be freeed while it's still used as active key in asoc. Then an use-after-free will be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 This patch is to fix it by not replacing the sh_key when it returns errors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key(). For sctp_auth_set_active_key(), old active_key_id will be set back to asoc->active_key_id when the same thing happens. Fixes: 58acd1009226 ("sctp: update active_key for asoc when old key is being replaced") Reported-by: syzbot+a236dd8e9622ed8954a3@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1f76323ac43fe0b00677794c930dee9f66ea2999 Author: Duoming Zhou Date: Wed Sep 28 21:39:38 2022 +0800 mISDN: fix use-after-free bugs in l1oip timer handlers [ Upstream commit 2568a7e0832ee30b0a351016d03062ab4e0e0a3f ] The l1oip_cleanup() traverses the l1oip_ilist and calls release_card() to cleanup module and stack. However, release_card() calls del_timer() to delete the timers such as keep_tl and timeout_tl. If the timer handler is running, the del_timer() will not stop it and result in UAF bugs. One of the processes is shown below: (cleanup routine) | (timer handler) release_card() | l1oip_timeout() ... | del_timer() | ... ... | kfree(hc) //FREE | | hc->timeout_on = 0 //USE Fix by calling del_timer_sync() in release_card(), which makes sure the timer handlers have finished before the resources, such as l1oip and so on, have been deallocated. What's more, the hc->workq and hc->socket_thread can kick those timers right back in. We add a bool flag to show if card is released. Then, check this flag in hc->workq and hc->socket_thread. Fixes: 3712b42d4b1b ("Add layer1 over IP support") Signed-off-by: Duoming Zhou Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a845a0c4bdece2c0073ecea2fca7c4d5f0550f78 Author: Jakub Kicinski Date: Wed Sep 28 11:12:36 2022 -0700 eth: alx: take rtnl_lock on resume [ Upstream commit 6ad1c94e1e7e374d88f0cfd77936dddb8339aaba ] Zbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0 indeed the driver does not hold rtnl_lock during its internal close and re-open functions during suspend/resume. Note that this is not a huge bug as the driver implements its own locking, and does not implement changing the number of queues, but we need to silence the splat. Fixes: 4a5fe57e7751 ("alx: use fine-grained locking instead of RTNL") Reported-and-tested-by: Zbynek Michl Reviewed-by: Niels Dossche Link: https://lore.kernel.org/r/20220928181236.1053043-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a99fc6d818161d6f1ff3307de8bf5237f6cc34d8 Author: Junichi Uekawa Date: Wed Sep 28 15:45:38 2022 +0900 vhost/vsock: Use kvmalloc/kvfree for larger packets. [ Upstream commit 0e3f72931fc47bb81686020cc643cde5d9cd0bb8 ] When copying a large file over sftp over vsock, data size is usually 32kB, and kmalloc seems to fail to try to allocate 32 32kB regions. vhost-5837: page allocation failure: order:4, mode:0x24040c0 Call Trace: [] dump_stack+0x97/0xdb [] warn_alloc_failed+0x10f/0x138 [] ? __alloc_pages_direct_compact+0x38/0xc8 [] __alloc_pages_nodemask+0x84c/0x90d [] alloc_kmem_pages+0x17/0x19 [] kmalloc_order_trace+0x2b/0xdb [] __kmalloc+0x177/0x1f7 [] ? copy_from_iter+0x8d/0x31d [] vhost_vsock_handle_tx_kick+0x1fa/0x301 [vhost_vsock] [] vhost_worker+0xf7/0x157 [vhost] [] kthread+0xfd/0x105 [] ? vhost_dev_set_owner+0x22e/0x22e [vhost] [] ? flush_kthread_worker+0xf3/0xf3 [] ret_from_fork+0x4e/0x80 [] ? flush_kthread_worker+0xf3/0xf3 Work around by doing kvmalloc instead. Fixes: 433fc58e6bf2 ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by: Junichi Uekawa Reviewed-by: Stefano Garzarella Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20220928064538.667678-1-uekawa@chromium.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 505ac55467dfc2f0433bced6230bda0de0cc1e5c Author: Bitterblue Smith Date: Sun Sep 18 15:42:25 2022 +0300 wifi: rtl8xxxu: Fix AIFS written to REG_EDCA_*_PARAM [ Upstream commit 5574d3290449916397f3092dcd2bac92415498e1 ] ieee80211_tx_queue_params.aifs is not supposed to be written directly to the REG_EDCA_*_PARAM registers. Instead process it like the vendor drivers do. It's kinda hacky but it works. This change boosts the download speed and makes it more stable. Tested with RTL8188FU but all the other supported chips should also benefit. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Bitterblue Smith Acked-by: Jes Sorensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/038cc03f-3567-77ba-a7bd-c4930e3b2fad@gmail.com Signed-off-by: Sasha Levin commit 7050e56333f1f03f4154129e28392df818655cd9 Author: Bitterblue Smith Date: Sun Sep 18 15:40:56 2022 +0300 wifi: rtl8xxxu: gen2: Enable 40 MHz channel width [ Upstream commit a8b5aef2cca15b7fa533421d462e4e0a3429bd6f ] The module parameter ht40_2g was supposed to enable 40 MHz operation, but it didn't. Tell the firmware about the channel width when updating the rate mask. This makes it work with my gen 2 chip RTL8188FU. I'm not sure if anything needs to be done for the gen 1 chips, if 40 MHz channel width already works or not. They update the rate mask with a different structure which doesn't have a field for the channel width. Also set the channel width correctly for sta_statistics. Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function") Fixes: bd917b3d28c9 ("rtl8xxxu: fill up txrate info for gen1 chips") Signed-off-by: Bitterblue Smith Acked-by: Jes Sorensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/3a950997-7580-8a6b-97a0-e0a81a135456@gmail.com Signed-off-by: Sasha Levin commit 71314ed41425c3f461b0f0aac01bba06cae623cc Author: Vincent Whitchurch Date: Tue Sep 27 13:21:17 2022 +0200 spi: s3c64xx: Fix large transfers with DMA [ Upstream commit 1224e29572f655facfcd850cf0f0a4784f36a903 ] The COUNT_VALUE in the PACKET_CNT register is 16-bit so the maximum value is 65535. Asking the driver to transfer a larger size currently leads to the DMA transfer timing out. Implement ->max_transfer_size() and have the core split the transfer as needed. Fixes: 230d42d422e7 ("spi: Add s3c64xx SPI Controller driver") Signed-off-by: Vincent Whitchurch Link: https://lore.kernel.org/r/20220927112117.77599-5-vincent.whitchurch@axis.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 27d23b84b244a8aea316f9ef43f9164e1d2a9703 Author: Phil Sutter Date: Wed Sep 21 13:07:31 2022 +0200 netfilter: nft_fib: Fix for rpath check with VRF devices [ Upstream commit 2a8a7c0eaa8747c16aa4a48d573aa920d5c00a5c ] Analogous to commit b575b24b8eee3 ("netfilter: Fix rpfilter dropping vrf packets by mistake") but for nftables fib expression: Add special treatment of VRF devices so that typical reverse path filtering via 'fib saddr . iif oif' expression works as expected. Fixes: f6d0cbcf09c50 ("netfilter: nf_tables: add fib expression") Signed-off-by: Phil Sutter Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit f520075da484306bbb8425afd2c42404ba74816f Author: Liu Jian Date: Sat Sep 24 16:01:57 2022 +0800 xfrm: Reinject transport-mode packets through workqueue [ Upstream commit 4f4920669d21e1060b7243e5118dc3b71ced1276 ] The following warning is displayed when the tcp6-multi-diffip11 stress test case of the LTP test suite is tested: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198] CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : des3_ede_encrypt+0x27c/0x460 [libdes] lr : 0x3f sp : ffff80000ceaa1b0 x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280 x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003b x23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038 x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033 x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248 x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548 x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748 x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001b x5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3 x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872 Call trace: des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_genicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184 Get softirq info by bcc tool: ./softirqs -NT 10 Tracing soft irq event time... Hit Ctrl-C to end. 15:34:34 SOFTIRQ TOTAL_nsecs block 158990 timer 20030920 sched 46577080 net_rx 676746820 tasklet 9906067650 15:34:45 SOFTIRQ TOTAL_nsecs block 86100 sched 38849790 net_rx 676532470 timer 1163848790 tasklet 9409019620 15:34:55 SOFTIRQ TOTAL_nsecs sched 58078450 net_rx 475156720 timer 533832410 tasklet 9431333300 The tasklet software interrupt takes too much time. Therefore, the xfrm_trans_reinject executor is changed from tasklet to workqueue. Add add spin lock to protect the queue. This reduces the processing flow of the tcp_sendmsg function in this scenario. Fixes: acf568ee859f0 ("xfrm: Reinject transport-mode packets through tasklet") Signed-off-by: Liu Jian Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit 0f1a762184a6d819019c9adb0e0e0ed2f424b6d7 Author: Luiz Augusto von Dentz Date: Mon Sep 26 15:44:42 2022 -0700 Bluetooth: hci_core: Fix not handling link timeouts propertly [ Upstream commit 116523c8fac05d1d26f748fee7919a4ec5df67ea ] Change that introduced the use of __check_timeout did not account for link types properly, it always assumes ACL_LINK is used thus causing hdev->acl_last_tx to be used even in case of LE_LINK and then again uses ACL_LINK with hci_link_tx_to. To fix this __check_timeout now takes the link type as parameter and then procedure to use the right last_tx based on the link type and pass it to hci_link_tx_to. Fixes: 1b1d29e51499 ("Bluetooth: Make use of __check_timeout on hci_sched_le") Signed-off-by: Luiz Augusto von Dentz Tested-by: David Beinder Signed-off-by: Sasha Levin commit de0ccb13d9ead4d5abd55ad6a7d35aec4d4aaa00 Author: Asmaa Mnebhi Date: Mon Sep 26 15:45:04 2022 -0400 i2c: mlxbf: support lock mechanism [ Upstream commit 86067ccfa1424a26491542d6f6d7546d40b61a10 ] Linux is not the only entity using the BlueField I2C busses so support a lock mechanism provided by hardware to avoid issues when multiple entities are trying to access the same bus. The lock is acquired whenever written explicitely or the lock register is read. So make sure it is always released at the end of a successful or failed transaction. Fixes: b5b5b32081cd206b (i2c: mlxbf: I2C SMBus driver for Mellanox BlueField SoC) Reviewed-by: Khalil Blaiech Signed-off-by: Asmaa Mnebhi Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit db41ae562b641486d765be86cad602bdaefcb3de Author: Xiaomeng Tong Date: Wed Apr 13 17:17:23 2022 +0800 cw1200: fix incorrect check to determine if no element is found in list [ Upstream commit 86df5de5c632d3bd940f59bbb14ae912aa9cc363 ] The bug is here: "} else if (item) {". The list iterator value will *always* be set and non-NULL by list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found in list. Use a new value 'iter' as the list iterator, while use the old value 'item' as a dedicated pointer to point to the found element, which 1. can fix this bug, due to now 'item' is NULL only if it's not found. 2. do not need to change all the uses of 'item' after the loop. 3. can also limit the scope of the list iterator 'iter' *only inside* the traversal loop by simply declaring 'iter' inside the loop in the future, as usage of the iterator outside of the list_for_each_entry is considered harmful. https://lkml.org/lkml/2022/2/17/1032 Fixes: a910e4a94f692 ("cw1200: add driver for the ST-E CW1100 & CW1200 WLAN chipsets") Signed-off-by: Xiaomeng Tong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220413091723.17596-1-xiam0nd.tong@gmail.com Signed-off-by: Sasha Levin commit e4be1cf9ba24c828809a420abf9ad46f34bc18b9 Author: Liu Jian Date: Wed Sep 7 15:13:11 2022 +0800 skmsg: Schedule psock work if the cached skb exists on the psock [ Upstream commit bec217197b412d74168c6a42fc0f76d0cc9cad00 ] In sk_psock_backlog function, for ingress direction skb, if no new data packet arrives after the skb is cached, the cached skb does not have a chance to be added to the receive queue of psock. As a result, the cached skb cannot be received by the upper-layer application. Fix this by reschedule the psock work to dispose the cached skb in sk_msg_recvmsg function. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Liu Jian Signed-off-by: Daniel Borkmann Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20220907071311.60534-1-liujian56@huawei.com Signed-off-by: Sasha Levin commit 7b24819bd6a2d8275df791ddf63dc8d61a8b3afd Author: Zhang Qilong Date: Sat Sep 24 20:13:09 2022 +0800 spi/omap100k:Fix PM disable depth imbalance in omap1_spi100k_probe [ Upstream commit 29f65f2171c85a9633daa380df14009a365f42f2 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes:db91841b58f9a ("spi/omap100k: Convert to runtime PM") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220924121310.78331-4-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2a354023d3b5a998a09bfb456dcc5d0d7400de69 Author: Zhang Qilong Date: Sat Sep 24 20:13:08 2022 +0800 spi: dw: Fix PM disable depth imbalance in dw_spi_bt1_probe [ Upstream commit 618d815fc93477b1675878f3c04ff32657cc18b4 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes:abf00907538e2 ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220924121310.78331-3-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 71d2ef419e0424c7c284c505353a95508ae17309 Author: Zhang Qilong Date: Sat Sep 24 20:13:07 2022 +0800 spi: cadence-quadspi: Fix PM disable depth imbalance in cqspi_probe [ Upstream commit 4d0ef0a1c35189a6e8377d8ee8310ea5ef22c5f3 ] The pm_runtime_enable will increase power disable depth. Thus a pairing decrement is needed on the error handling path to keep it balanced according to context. Fixes:73d5fe0462702 ("spi: cadence-quadspi: Remove spi_master_put() in probe failure path") Signed-off-by: Zhang Qilong Link: https://lore.kernel.org/r/20220924121310.78331-2-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c5b8e7ca8befdce12e0bcdcf67693e4167e74e3 Author: Luciano Leão Date: Thu Sep 22 17:00:54 2022 -0300 x86/cpu: Include the header of init_ia32_feat_ctl()'s prototype [ Upstream commit 30ea703a38ef76ca119673cd8bdd05c6e068e2ac ] Include the header containing the prototype of init_ia32_feat_ctl(), solving the following warning: $ make W=1 arch/x86/kernel/cpu/feat_ctl.o arch/x86/kernel/cpu/feat_ctl.c:112:6: warning: no previous prototype for ‘init_ia32_feat_ctl’ [-Wmissing-prototypes] 112 | void init_ia32_feat_ctl(struct cpuinfo_x86 *c) This warning appeared after commit 5d5103595e9e5 ("x86/cpu: Reinitialize IA32_FEAT_CTL MSR on BSP during wakeup") had moved the function init_ia32_feat_ctl()'s prototype from arch/x86/kernel/cpu/cpu.h to arch/x86/include/asm/cpu.h. Note that, before the commit mentioned above, the header include "cpu.h" (arch/x86/kernel/cpu/cpu.h) was added by commit 0e79ad863df43 ("x86/cpu: Fix a -Wmissing-prototypes warning for init_ia32_feat_ctl()") solely to fix init_ia32_feat_ctl()'s missing prototype. So, the header include "cpu.h" is no longer necessary. [ bp: Massage commit message. ] Fixes: 5d5103595e9e5 ("x86/cpu: Reinitialize IA32_FEAT_CTL MSR on BSP during wakeup") Signed-off-by: Luciano Leão Signed-off-by: Borislav Petkov Reviewed-by: Nícolas F. R. A. Prado Link: https://lore.kernel.org/r/20220922200053.1357470-1-lucianorsleao@gmail.com Signed-off-by: Sasha Levin commit 2042092204f80d6a3792ca0aa44ca96895341aad Author: Christian Marangi Date: Thu Sep 22 10:35:14 2022 +0300 wifi: ath11k: fix peer addition/deletion error on sta band migration [ Upstream commit d673cb6fe6c03b2be157cc6c5db40481828d282d ] This patch try to fix the following error. Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.561227] ath11k c000000.wifi: peer already added vdev id 0 req, vdev id 1 present Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.561282] ath11k c000000.wifi: Failed to add peer: 28:c2:1f:xx:xx:xx for VDEV: 0 Wed Jun 1 22:19:30 2022 kern.warn kernel: [ 119.568053] ath11k c000000.wifi: Failed to add station: 28:c2:1f:xx:xx:xx for VDEV: 0 Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: Could not add STA to kernel driver Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan2: STA 28:c2:1f:xx:xx:xx IEEE 802.11: did not acknowledge authentication response Wed Jun 1 22:19:31 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED 28:c2:1f:xx:xx:xx Wed Jun 1 22:19:31 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: disassociated due to inactivity Wed Jun 1 22:19:32 2022 daemon.info hostapd: wlan1: STA 28:c2:1f:xx:xx:xx IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE) To repro this: - Have 2 Wifi with the same bssid and pass on different band (2.4 and 5GHz) - Enable 802.11r Fast Transaction with same mobility domain - FT Protocol: FT over the Air From a openwrt system issue the command (with the correct mac) ubus call hostapd.wlan1 wnm_disassoc_imminent '{"addr":"28:C2:1F:xx:xx:xx"}' Notice the log printing the errors. The cause of this error has been investigated and we found that this is related to the WiFi Fast Transaction feature. We observed that this is triggered when the router tells the device to change band. In this case the device first auth to the other band and then the disconnect path from the prev band is triggered. This is problematic with the current rhash implementation since the addrs is used as key and the logic of "adding first, delete later" conflicts with the rhash logic. In fact peer addition will fail since the peer is already added and with that fixed a peer deletion will cause unitended effect by removing the peer just added. Current solution to this is to add additional logic to the peer delete, make sure we are deleting the correct peer taken from the rhash table (and fallback to the peer list) and for the peer add logic delete the peer entry for the rhash list before adding the new one (counting as an error only when a peer with the same vlan_id is asked to be added). With this change, a sta can correctly transition from 2.4GHz and 5GHZ with no drop and no error are printed. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 Fixes: 7b0c70d92a43 ("ath11k: Add peer rhash table support") Signed-off-by: Christian 'Ansuel' Marangi Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220603164559.27769-1-ansuelsmth@gmail.com Signed-off-by: Sasha Levin commit bbcc38c4450e689ce2ea0e1c2109e7f7a3a75ae8 Author: Kees Cook Date: Wed Sep 21 20:10:10 2022 -0700 x86/microcode/AMD: Track patch allocation size explicitly [ Upstream commit 712f210a457d9c32414df246a72781550bc23ef6 ] In preparation for reducing the use of ksize(), record the actual allocation size for later memcpy(). This avoids copying extra (uninitialized!) bytes into the patch buffer when the requested allocation size isn't exactly the size of a kmalloc bucket. Additionally, fix potential future issues where runtime bounds checking will notice that the buffer was allocated to a smaller value than returned by ksize(). Fixes: 757885e94a22 ("x86, microcode, amd: Early microcode patch loading support for AMD") Suggested-by: Daniel Micay Signed-off-by: Kees Cook Signed-off-by: Borislav Petkov Link: https://lore.kernel.org/lkml/CA+DvKQ+bp7Y7gmaVhacjv9uF6Ar-o4tet872h4Q8RPYPJjcJQA@mail.gmail.com/ Signed-off-by: Sasha Levin commit ba46813ae735daa5305c1e0856bb3c7edd20c041 Author: Arınç ÜNAL Date: Tue Sep 20 20:25:55 2022 +0300 mips: dts: ralink: mt7621: fix external phy on GB-PC2 [ Upstream commit 247825f991b34440f9b9d4fe607502435a42ac7b ] The address of the external phy on the mdio bus is 5. Update the devicetree for GB-PC2 accordingly. Fixes: 5bc148649cf3 ("staging: mt7621-dts: fix GB-PC2 devicetree") Signed-off-by: Arınç ÜNAL Reviewed-by: Sergio Paracuellos Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8d6b977ddf0600922e0f1236a25143eebd483b05 Author: Jesus Fernandez Manzano Date: Thu Sep 22 10:35:14 2022 +0300 wifi: ath11k: fix number of VHT beamformee spatial streams [ Upstream commit 55b5ee3357d7bb98ee578cf9b84a652e7a1bc199 ] The number of spatial streams used when acting as a beamformee in VHT mode are reported by the firmware as 7 (8 sts - 1) both in IPQ6018 and IPQ8074 which respectively have 2 and 4 sts each. So the firmware should report 1 (2 - 1) and 3 (4 - 1). Fix this by checking that the number of VHT beamformee sts reported by the firmware is not greater than the number of receiving antennas - 1. The fix is based on the same approach used in this same function for sanitizing the number of sounding dimensions reported by the firmware. Without this change, acting as a beamformee in VHT mode is not working properly. Tested-on: IPQ6018 hw1.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01208-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Jesus Fernandez Manzano Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220616173947.21901-1-jesus.manzano@galgus.net Signed-off-by: Sasha Levin commit c0bb97a90b133416b50b3ffbdb7efca9253cc687 Author: Wen Gong Date: Tue Sep 20 18:23:41 2022 +0300 wifi: ath11k: fix failed to find the peer with peer_id 0 when disconnected [ Upstream commit a20ed60bb357776301c2dad7b4a4f0db97e143e9 ] It has a fail log which is ath11k_dbg in ath11k_dp_rx_process_mon_status(), as below, it will not print when debug_mask is not set ATH11K_DBG_DATA. ath11k_dbg(ab, ATH11K_DBG_DATA, "failed to find the peer with peer_id %d\n", ppdu_info.peer_id); When run scan with station disconnected, the peer_id is 0 for case HAL_RX_MPDU_START in ath11k_hal_rx_parse_mon_status_tlv() which called from ath11k_dp_rx_process_mon_status(), and the peer_id of ppdu_info is reset to 0 in the while loop, so it does not match condition of the check "if (ppdu_info->peer_id == HAL_INVALID_PEERID" in the loop, and then the log "failed to find the peer with peer_id 0" print after the check in the loop, it is below call stack when debug_mask is set ATH11K_DBG_DATA. The reason is this commit 01d2f285e3e5 ("ath11k: decode HE status tlv") add "memset(ppdu_info, 0, sizeof(struct hal_rx_mon_ppdu_info))" in ath11k_dp_rx_process_mon_status(), but the commit does not initialize the peer_id to HAL_INVALID_PEERID, then lead the check mis-match. Callstack of the failed log: [12335.689072] RIP: 0010:ath11k_dp_rx_process_mon_status+0x9ea/0x1020 [ath11k] [12335.689157] Code: 89 ff e8 f9 10 00 00 be 01 00 00 00 4c 89 f7 e8 dc 4b 4e de 48 8b 85 38 ff ff ff c7 80 e4 07 00 00 01 00 00 00 e9 20 f8 ff ff <0f> 0b 41 0f b7 96 be 06 00 00 48 c7 c6 b8 50 44 c1 4c 89 ff e8 fd [12335.689180] RSP: 0018:ffffb874001a4ca0 EFLAGS: 00010246 [12335.689210] RAX: 0000000000000000 RBX: ffff995642cbd100 RCX: 0000000000000000 [12335.689229] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff99564212cd18 [12335.689248] RBP: ffffb874001a4dc0 R08: 0000000000000001 R09: 0000000000000000 [12335.689268] R10: 0000000000000220 R11: ffffb874001a48e8 R12: ffff995642473d40 [12335.689286] R13: ffff99564212c5b8 R14: ffff9956424736a0 R15: ffff995642120000 [12335.689303] FS: 0000000000000000(0000) GS:ffff995739000000(0000) knlGS:0000000000000000 [12335.689323] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [12335.689341] CR2: 00007f43c5d5e039 CR3: 000000011c012005 CR4: 00000000000606e0 [12335.689360] Call Trace: [12335.689377] [12335.689418] ? rcu_read_lock_held_common+0x12/0x50 [12335.689447] ? rcu_read_lock_sched_held+0x25/0x80 [12335.689471] ? rcu_read_lock_held_common+0x12/0x50 [12335.689504] ath11k_dp_rx_process_mon_rings+0x8d/0x4f0 [ath11k] [12335.689578] ? ath11k_dp_rx_process_mon_rings+0x8d/0x4f0 [ath11k] [12335.689653] ? lock_acquire+0xef/0x360 [12335.689681] ? rcu_read_lock_sched_held+0x25/0x80 [12335.689713] ath11k_dp_service_mon_ring+0x38/0x60 [ath11k] [12335.689784] ? ath11k_dp_rx_process_mon_rings+0x4f0/0x4f0 [ath11k] [12335.689860] call_timer_fn+0xb2/0x2f0 [12335.689897] ? ath11k_dp_rx_process_mon_rings+0x4f0/0x4f0 [ath11k] [12335.689970] run_timer_softirq+0x21f/0x540 [12335.689999] ? ktime_get+0xad/0x160 [12335.690025] ? lapic_next_deadline+0x2c/0x40 [12335.690053] ? clockevents_program_event+0x82/0x100 [12335.690093] __do_softirq+0x151/0x4a8 [12335.690135] irq_exit_rcu+0xc9/0x100 [12335.690165] sysvec_apic_timer_interrupt+0xa8/0xd0 [12335.690189] [12335.690204] [12335.690225] asm_sysvec_apic_timer_interrupt+0x12/0x20 Reset the default value to HAL_INVALID_PEERID each time after memset of ppdu_info as well as others memset which existed in function ath11k_dp_rx_process_mon_status(), then the failed log disappeared. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: 01d2f285e3e5 ("ath11k: decode HE status tlv") Signed-off-by: Wen Gong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220518033556.31940-1-quic_wgong@quicinc.com Signed-off-by: Sasha Levin commit 520b81520191b8ddea477587dc69a8cb934156bf Author: Qingqing Yang Date: Mon Sep 19 15:48:08 2022 +0800 flow_dissector: Do not count vlan tags inside tunnel payload [ Upstream commit 9f87eb4246994e32a4e4ea88476b20ab3b412840 ] We've met the problem that when there is a vlan tag inside GRE encapsulation, the match of num_of_vlans fails. It is caused by the vlan tag inside GRE payload has been counted into num_of_vlans, which is not expected. One example packet is like this: Ethernet II, Src: Broadcom_68:56:07 (00:10:18:68:56:07) Dst: Broadcom_68:56:08 (00:10:18:68:56:08) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 100 Internet Protocol Version 4, Src: 192.168.1.4, Dst: 192.168.1.200 Generic Routing Encapsulation (Transparent Ethernet bridging) Ethernet II, Src: Broadcom_68:58:07 (00:10:18:68:58:07) Dst: Broadcom_68:58:08 (00:10:18:68:58:08) 802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 200 ... It should match the (num_of_vlans 1) rule, but it matches the (num_of_vlans 2) rule. The vlan tags inside the GRE or other tunnel encapsulated payload should not be taken into num_of_vlans. The fix is to stop counting the vlan number when the encapsulation bit is set. Fixes: 34951fcf26c5 ("flow_dissector: Add number of vlan tags dissector") Signed-off-by: Qingqing Yang Reviewed-by: Boris Sukholitko Link: https://lore.kernel.org/r/20220919074808.136640-1-qingqing.yang@broadcom.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 973ddaffd2b7852630f2a6b7f0c1d1cb5fa731c7 Author: Antoine Tenart Date: Fri Sep 16 11:29:41 2022 +0200 netfilter: conntrack: revisit the gc initial rescheduling bias [ Upstream commit 2aa192757005f130b2dd3547dda6e462e761199f ] The previous commit changed the way the rescheduling delay is computed which has a side effect: the bias is now represented as much as the other entries in the rescheduling delay which makes the logic to kick in only with very large sets, as the initial interval is very large (INT_MAX). Revisit the GC initial bias to allow more frequent GC for smaller sets while still avoiding wakeups when a machine is mostly idle. We're moving from a large initial value to pretending we have 100 entries expiring at the upper bound. This way only a few entries having a small timeout won't impact much the rescheduling delay and non-idle machines will have enough entries to lower the delay when needed. This also improves readability as the initial bias is now linked to what is computed instead of being an arbitrary large value. Fixes: 2cfadb761d3d ("netfilter: conntrack: revisit gc autotuning") Suggested-by: Florian Westphal Signed-off-by: Antoine Tenart Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit b3104ef0663537284efaac2b46fd110fc7958d6e Author: Antoine Tenart Date: Fri Sep 16 11:29:40 2022 +0200 netfilter: conntrack: fix the gc rescheduling delay [ Upstream commit 95eabdd207024312876d0ebed90b4c977e050e85 ] Commit 2cfadb761d3d ("netfilter: conntrack: revisit gc autotuning") changed the eviction rescheduling to the use average expiry of scanned entries (within 1-60s) by doing: for (...) { expires = clamp(nf_ct_expires(tmp), ...); next_run += expires; next_run /= 2; } The issue is the above will make the average ('next_run' here) more dependent on the last expiration values than the firsts (for sets > 2). Depending on the expiration values used to compute the average, the result can be quite different than what's expected. To fix this we can do the following: for (...) { expires = clamp(nf_ct_expires(tmp), ...); next_run += (expires - next_run) / ++count; } Fixes: 2cfadb761d3d ("netfilter: conntrack: revisit gc autotuning") Cc: Florian Westphal Signed-off-by: Antoine Tenart Signed-off-by: Florian Westphal Signed-off-by: Sasha Levin commit 75b2c71ea581c7bb1303860d89366a42ad0506d2 Author: Tetsuo Handa Date: Mon Aug 29 23:58:12 2022 +0900 Bluetooth: hci_{ldisc,serdev}: check percpu_init_rwsem() failure [ Upstream commit 3124d320c22f3f4388d9ac5c8f37eaad0cefd6b1 ] syzbot is reporting NULL pointer dereference at hci_uart_tty_close() [1], for rcu_sync_enter() is called without rcu_sync_init() due to hci_uart_tty_open() ignoring percpu_init_rwsem() failure. While we are at it, fix that hci_uart_register_device() ignores percpu_init_rwsem() failure and hci_uart_unregister_device() does not call percpu_free_rwsem(). Link: https://syzkaller.appspot.com/bug?extid=576dfca25381fb6fbc5f [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 67d2f8781b9f00d1 ("Bluetooth: hci_ldisc: Allow sleeping while proto locks are held.") Fixes: d73e172816652772 ("Bluetooth: hci_serdev: Init hci_uart proto_lock to avoid oops") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit f8a77dbb88377b16760bc6e1881630f2e3dcaff4 Author: Baochen Qiang Date: Tue Sep 13 12:43:58 2022 +0800 wifi: ath11k: Include STA_KEEPALIVE_ARP_RESPONSE TLV header by default [ Upstream commit b7b6f86149a7e06269d61a7a5206360f5b642f80 ] In current code STA_KEEPALIVE_ARP_RESPONSE TLV header is included only when ARP method is used, this causes firmware always to crash when wowlan is enabled because firmware needs it to be present no matter ARP method is used or not. Fix this issue by including STA_KEEPALIVE_ARP_RESPONSE TLV header by default. Also fix below typo: s/WMI_TAG_STA_KEEPALVE_ARP_RESPONSE/WMI_TAG_STA_KEEPALIVE_ARP_RESPONSE/ Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3 Fixes: 0f84a156aa3b ("ath11k: Handle keepalive during WoWLAN suspend and resume") Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220913044358.2037-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin commit 7de3297a9239dbcadd7c52eaab3b75cb6cf522e4 Author: Lee Jones Date: Mon Sep 12 14:38:55 2022 +0100 bpf: Ensure correct locking around vulnerable function find_vpid() [ Upstream commit 83c10cc362d91c0d8d25e60779ee52fdbbf3894d ] The documentation for find_vpid() clearly states: "Must be called with the tasklist_lock or rcu_read_lock() held." Presently we do neither for find_vpid() instance in bpf_task_fd_query(). Add proper rcu_read_lock/unlock() to fix the issue. Fixes: 41bdc4b40ed6f ("bpf: introduce bpf subcommand BPF_TASK_FD_QUERY") Signed-off-by: Lee Jones Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20220912133855.1218900-1-lee@kernel.org Signed-off-by: Sasha Levin commit 5ae7255b9ab3595ecfc4108269a7e5c0eeebb495 Author: Zheng Yongjun Date: Thu Sep 8 13:55:13 2022 +0000 net: fs_enet: Fix wrong check in do_pd_setup [ Upstream commit ec3f06b542a960806a81345042e4eee3f8c5dec4 ] Should check of_iomap return value 'fep->fec.fecp' instead of 'fep->fcc.fccp' Fixes: 976de6a8c304 ("fs_enet: Be an of_platform device when CONFIG_PPC_CPM_NEW_BINDING is set.") Signed-off-by: Zheng Yongjun Reviewed-by: Christophe Leroy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e706cc24b6796f483f4e37457d9d9c49689a4080 Author: Luiz Augusto von Dentz Date: Tue Sep 13 16:08:13 2022 -0700 Bluetooth: RFCOMM: Fix possible deadlock on socket shutdown/release [ Upstream commit 812e92b824c1db16c9519f8624d48a9901a0d38f ] Due to change to switch to use lock_sock inside rfcomm_sk_state_change the socket shutdown/release procedure can cause a deadlock: rfcomm_sock_shutdown(): lock_sock(); __rfcomm_sock_close(): rfcomm_dlc_close(): __rfcomm_dlc_close(): rfcomm_dlc_lock(); rfcomm_sk_state_change(): lock_sock(); To fix this when the call __rfcomm_sock_close is now done without holding the lock_sock since rfcomm_dlc_lock exists to protect the dlc data there is no need to use lock_sock in that code path. Link: https://lore.kernel.org/all/CAD+dNTsbuU4w+Y_P7o+VEN7BYCAbZuwZx2+tH+OTzCdcZF82YA@mail.gmail.com/ Fixes: b7ce436a5d79 ("Bluetooth: switch to lock_sock in RFCOMM") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 1034d8e08508830161377f136a060e78fc24f2a5 Author: Deren Wu Date: Tue Sep 6 20:39:43 2022 +0800 wifi: mt76: mt7921e: fix rmmod crash in driver reload test [ Upstream commit b5a62d612b7baf6e09884e4de94decb6391d6a9d ] In insmod/rmmod stress test, the following crash dump shows up immediately. The problem is caused by missing mt76_dev in mt7921_pci_remove(). We should make sure the drvdata is ready before probe() finished. [168.862789] ================================================================== [168.862797] BUG: KASAN: user-memory-access in try_to_grab_pending+0x59/0x480 [168.862805] Write of size 8 at addr 0000000000006df0 by task rmmod/5361 [168.862812] CPU: 7 PID: 5361 Comm: rmmod Tainted: G OE 5.19.0-rc6 #1 [168.862816] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, 05/04/2020 [168.862820] Call Trace: [168.862822] [168.862825] dump_stack_lvl+0x49/0x63 [168.862832] print_report.cold+0x493/0x6b7 [168.862845] kasan_report+0xa7/0x120 [168.862857] kasan_check_range+0x163/0x200 [168.862861] __kasan_check_write+0x14/0x20 [168.862866] try_to_grab_pending+0x59/0x480 [168.862870] __cancel_work_timer+0xbb/0x340 [168.862898] cancel_work_sync+0x10/0x20 [168.862902] mt7921_pci_remove+0x61/0x1c0 [mt7921e] [168.862909] pci_device_remove+0xa3/0x1d0 [168.862914] device_remove+0xc4/0x170 [168.862920] device_release_driver_internal+0x163/0x300 [168.862925] driver_detach+0xc7/0x1a0 [168.862930] bus_remove_driver+0xeb/0x2d0 [168.862935] driver_unregister+0x71/0xb0 [168.862939] pci_unregister_driver+0x30/0x230 [168.862944] mt7921_pci_driver_exit+0x10/0x1b [mt7921e] [168.862949] __x64_sys_delete_module+0x2f9/0x4b0 [168.862968] do_syscall_64+0x38/0x90 [168.862973] entry_SYSCALL_64_after_hwframe+0x63/0xcd Test steps: 1. insmode 2. do not ifup 3. rmmod quickly (within 1 second) Fixes: 1c71e03afe4b ("mt76: mt7921: move mt7921_init_hw in a dedicated work") Signed-off-by: Deren Wu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f5e6d7ba8329a009264963370949a8da65814834 Author: Howard Hsu Date: Thu Aug 18 10:44:07 2022 +0800 wifi: mt76: mt7915: do not check state before configuring implicit beamform [ Upstream commit d2b5bb6dfab29fe32bedefaade88dcd182c03a00 ] Do not need to check running state before configuring implicit Tx beamform. It is okay to configure implicit Tx beamform in run time. Noted that the existing connected stations will be applied for new configuration only if they reconnected to the interface. Fixes: 6d6dc980e07d ("mt76: mt7915: add implicit Tx beamforming support") Signed-off-by: Howard Hsu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 540f17a503dbd29d41c7b00a2d7d697f592491b0 Author: Howard Hsu Date: Mon Aug 15 11:29:31 2022 +0800 wifi: mt76: mt7915: fix mcs value in ht mode [ Upstream commit c6d3e16ad4362502e804a6ca01e955612f3b8222 ] Fix the error that mcs will be reduced to a range of 0 to 7 in ht mode. Fixes: 70fd1333cd32 ("mt76: mt7915: rework .set_bitrate_mask() to support more options") Signed-off-by: Howard Hsu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit ce02cd82abada4cf3fdefb12593939c8aa3093a5 Author: Sean Wang Date: Fri Jul 29 22:44:57 2022 +0800 wifi: mt76: mt7921: add mt7921_mutex_acquire at mt7921_sta_set_decap_offload [ Upstream commit 59c20b91786d5f140ee7be2f24c242b5f8986046 ] Add mt7921_mutex_acquire at mt7921_[start, stop]_ap to fix the race with the context holding dev->muxtex and the driver might access the device in low power state. Fixes: 24299fc869f7 ("mt76: mt7921: enable rx header traslation offload") Tested-by: AngeloGioacchino Del Regno Acked-by: Lorenzo Bianconi Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f31aa5196463ff0529b6d91d5c7ceb0fb57709fd Author: Sean Wang Date: Fri Jul 29 22:44:56 2022 +0800 wifi: mt76: mt7921: add mt7921_mutex_acquire at mt7921_[start, stop]_ap [ Upstream commit 52b44015f031f629f1ce1d73415a2017593c7ade ] Add mt7921_mutex_acquire at mt7921_[start, stop]_ap to fix the race with the context holding dev->muxtex and the driver might access the device in low power state. Fixes: 9d958b60ebc2 ("mt76: mt7921: fix command timeout in AP stop period") Tested-by: AngeloGioacchino Del Regno Signed-off-by: Sean Wang Acked-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f5275e2e41eb487ec68ea6f3f7f35b8d4bc6dc8b Author: Lorenzo Bianconi Date: Mon Jul 25 16:12:06 2022 +0200 wifi: mt76: connac: fix possible unaligned access in mt76_connac_mcu_add_nested_tlv [ Upstream commit 0a4860f627f1f2b2b777f54f993de1638a79da9f ] Fix possible unaligned pointer in mt76_connac_mcu_add_nested_tlv routine. Reported-by: kernel test robot Fixes: 25702d9c55dc5 ("mt76: connac: rely on le16_add_cpu in mt76_connac_mcu_add_nested_tlv") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c5bc23134c0ce0ad66164e7b46de49a445d801f5 Author: Lorenzo Bianconi Date: Mon Jul 25 11:50:03 2022 +0200 wifi: mt76: mt7915: fix possible unaligned access in mt7915_mac_add_twt_setup [ Upstream commit 3d9aa54355d863e5412a7e08180f50a8f1827b7f ] Fix possible unaligned pointer in mt7915_mac_add_twt_setup routine. Reported-by: kernel test robot Fixes: 3782b69d03e71 ("mt76: mt7915: introduce mt7915_mac_add_twt_setup routine") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0160c341d836b97cb73b03fe7bf23bc1d64223c3 Author: Lorenzo Bianconi Date: Mon Jul 25 10:26:40 2022 +0200 wifi: mt76: mt7615: add mt7615_mutex_acquire/release in mt7615_sta_set_decap_offload [ Upstream commit 765c69d477a44c088e5d19e7758dfa4db418e3ba ] Similar to mt7921 driver, introduce mt7615_mutex_acquire/release in mt7615_sta_set_decap_offload in order to avoid sending mcu commands while the device is in low-power state. Fixes: d4b98c63d7a77 ("mt76: mt7615: add support for rx decapsulation offload") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 327c14cf7b5f39354d54df843746f3963ddc1802 Author: YN Chen Date: Sat Jul 23 05:59:23 2022 +0800 wifi: mt76: sdio: fix transmitting packet hangs [ Upstream commit 250b1827205846ff346a76044955cb79d4963f70 ] Fix transmitting packets hangs with continuing to pull the pending packet from mac80211 queues when receiving Tx status notification from the device. Fixes: aac5104bf631 ("mt76: sdio: do not run mt76_txq_schedule directly") Acked-by: Sean Wang Signed-off-by: YN Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 8b133eb8af6715b99bb85e3b5056e259a99914bd Author: Sean Wang Date: Fri Jul 22 06:39:36 2022 +0800 wifi: mt76: sdio: poll sta stat when device transmits data [ Upstream commit a323e5f041dd11af5e3de19ed7ea95a97d588c11 ] It is not meaningful to poll sta stat when there is no data traffic. So polling sta stat when the device has transmitted data instead to save CPU power. That implies that it is unallowed the stat_work to work while MCU is being initialized in the really early stage to fix the possible time to time MCU initialization failure. Fixes: d39b52e31aa6 ("mt76: introduce mt76_sdio module") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 0641218a8143341d3d2f44cba3aa0be0e77e8bba Author: Sean Wang Date: Fri Jul 22 06:39:35 2022 +0800 wifi: mt76: sdio: fix the deadlock caused by sdio->stat_work [ Upstream commit e5d78fd998be94fb459a3d625df7367849b997b8 ] Because wake_work and sdio->stat_work share the same workqueue mt76->wq, if sdio->stat_work cannot acquire the mutex lock such as that was possibly held up by [mt7615, mt7921]_mutex_acquire. Additionally, if [mt7615, mt7921]_mutex_acquire was called by sdio->stat_work self, the wake would be blocked by itself. Thus, we move the stat_work into ieee80211_workqueue instead to break the deadlock. Fixes: d39b52e31aa6 ("mt76: introduce mt76_sdio module") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 30a09a8ca499f6d26296f6eb3030d866634333df Author: Sean Wang Date: Thu Jul 21 06:25:39 2022 +0800 wifi: mt76: mt7921u: fix race issue between reset and suspend/resume [ Upstream commit 86f15d043ba7f13211d5c3e41961c3381fb12880 ] It is unexpected that the reset work is running simultaneously with the suspend or resume context and it is possible that reset work is still running even after mt7921 is suspended if we don't fix the race issue. Thus, the suspend procedure should be waiting until the reset is completed at the beginning and ignore the subsequent the reset requests. In case there is an error that happens during either suspend or resume handler, we will schedule a reset task to recover the error before returning the error code to ensure we can immediately fix the error there. Fixes: df3e4143ba8a ("mt76: mt7921u: add suspend/resume support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d2d352124e19e44dd7a4f874cb2205810706ea2e Author: Sean Wang Date: Thu Jul 21 06:25:38 2022 +0800 wifi: mt76: mt7921s: fix race issue between reset and suspend/resume [ Upstream commit e86f10e6809add9132ecc2c6b3184ed59db7ca71 ] It is unexpected that the reset work is running simultaneously with the suspend or resume context and it is possible that reset work is still running even after mt7921 is suspended if we don't fix the race issue. Thus, the suspend procedure should be waiting until the reset is completed at the beginning and ignore the subsequent the reset requests. In case there is an error that happens during either suspend or resume handler, we will schedule a reset task to recover the error before returning the error code to ensure we can immediately fix the error there. Fixes: ca74b9b907f9 ("mt76: mt7921s: add reset support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 7aa91aa9daa7dceb84ca401269733991e5dab252 Author: Sean Wang Date: Thu Jul 21 06:25:37 2022 +0800 wifi: mt76: mt7921e: fix race issue between reset and suspend/resume [ Upstream commit ff6c4a6449793e9718ef2e9ad46864b63022648e ] It is unexpected that the reset work is running simultaneously with the suspend or resume context and it is possible that reset work is still running even after mt7921 is suspended if we don't fix the race issue. Thus, the suspend procedure should be waiting until the reset is completed at the beginning and ignore the subsequent the reset requests. In case there is an error that happens during either suspend or resume handler, we will schedule a reset task to recover the error before returning the error code to ensure we can immediately fix the error there. Fixes: 0c1ce9884607 ("mt76: mt7921: add wifi reset support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c24ab2685bc2015fb4036d6f03a1b2ca2678f54e Author: Bitterblue Smith Date: Fri Sep 2 16:15:30 2022 +0300 wifi: rtl8xxxu: Remove copy-paste leftover in gen2_update_rate_mask [ Upstream commit d5350756c03cdf18696295c6b11d7acc4dbf825c ] It looks like a leftover from copying rtl8xxxu_update_rate_mask, which is used with the gen1 chips. It wasn't causing any problems for my RTL8188FU test device, but it's clearly a mistake, so remove it. Fixes: f653e69009c6 ("rtl8xxxu: Implement basic 8723b specific update_rate_mask() function") Signed-off-by: Bitterblue Smith Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/d5544fe8-9798-28f1-54bd-6839a1974b10@gmail.com Signed-off-by: Sasha Levin commit 09ef9d732664495b0d24d0e256275c64b4f1e802 Author: Bitterblue Smith Date: Fri Sep 2 14:48:32 2022 +0300 wifi: rtl8xxxu: gen2: Fix mistake in path B IQ calibration [ Upstream commit e963a19c64ac0d2f8785d36a27391abd91ac77aa ] Found by comparing with the vendor driver. Currently this affects only the RTL8192EU, which is the only gen2 chip with 2 TX paths supported by this driver. It's unclear what kind of effect the mistake had in practice, since I don't have any RTL8192EU devices to test it. Fixes: e1547c535ede ("rtl8xxxu: First stab at adding IQK calibration for 8723bu parts") Signed-off-by: Bitterblue Smith Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/30a59f3a-cfa9-8379-7af0-78a8f4c77cfd@gmail.com Signed-off-by: Sasha Levin commit c586349191fb36c5a0bc8a005461cc76b403fa97 Author: Lorenz Bauer Date: Sat Sep 10 11:01:20 2022 +0000 bpf: btf: fix truncated last_member_type_id in btf_struct_resolve [ Upstream commit a37a32583e282d8d815e22add29bc1e91e19951a ] When trying to finish resolving a struct member, btf_struct_resolve saves the member type id in a u16 temporary variable. This truncates the 32 bit type id value if it exceeds UINT16_MAX. As a result, structs that have members with type ids > UINT16_MAX and which need resolution will fail with a message like this: [67414] STRUCT ff_device size=120 vlen=12 effect_owners type_id=67434 bits_offset=960 Member exceeds struct_size Fix this by changing the type of last_member_type_id to u32. Fixes: a0791f0df7d2 ("bpf: fix BTF limits") Reviewed-by: Stanislav Fomichev Signed-off-by: Lorenz Bauer Link: https://lore.kernel.org/r/20220910110120.339242-1-oss@lmb.io Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit bcc34897bd58f758d4983cd08cced09ff139d2d8 Author: Neil Armstrong Date: Thu Sep 8 14:18:03 2022 +0200 spi: meson-spicc: do not rely on busy flag in pow2 clk ops [ Upstream commit 36acf80fc0c4b5ebe6fa010b524d442ee7f08fd3 ] Since [1], controller's busy flag isn't set anymore when the __spi_transfer_message_noqueue() is used instead of the __spi_pump_transfer_message() logic for spi_sync transfers. Since the pow2 clock ops were limited to only be available when a transfer is ongoing (between prepare_transfer_hardware and unprepare_transfer_hardware callbacks), the only way to track this down is to check for the controller cur_msg. [1] ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync") Fixes: 09992025dacd ("spi: meson-spicc: add local pow2 clock ops to preserve rate between messages") Fixes: ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync") Reported-by: Markus Schneider-Pargmann Signed-off-by: Neil Armstrong Tested-by: Markus Schneider-Pargmann Link: https://lore.kernel.org/r/20220908121803.919943-1-narmstrong@baylibre.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5ee77839f3c4e814141c3f9653216a25972d3bff Author: Bitterblue Smith Date: Wed Aug 31 19:12:36 2022 +0300 wifi: rtl8xxxu: Fix skb misuse in TX queue selection [ Upstream commit edd5747aa12ed61a5ecbfa58d3908623fddbf1e8 ] rtl8xxxu_queue_select() selects the wrong TX queues because it's reading memory from the wrong address. It expects to find ieee80211_hdr at skb->data, but that's not the case after skb_push(). Move the call to rtl8xxxu_queue_select() before the call to skb_push(). Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Bitterblue Smith Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/7fa4819a-4f20-b2af-b7a6-8ee01ac49295@gmail.com Signed-off-by: Sasha Levin commit 4bf42b30a98e6dc9562565a8679d025a4f9a2dc0 Author: Xu Qiang Date: Thu Aug 25 06:53:24 2022 +0000 spi: qup: add missing clk_disable_unprepare on error in spi_qup_pm_resume_runtime() [ Upstream commit 494a22765ce479c9f8ad181c5d24cffda9f534bb ] Add the missing clk_disable_unprepare() before return from spi_qup_pm_resume_runtime() in the error handling case. Fixes: dae1a7700b34 (“spi: qup: Handle clocks in pm_runtime suspend and resume”) Signed-off-by: Xu Qiang Link: https://lore.kernel.org/r/20220825065324.68446-2-xuqiang36@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 36ad3e1467326d669cfd30652196c41a3fcfcf0c Author: Xu Qiang Date: Thu Aug 25 06:53:23 2022 +0000 spi: qup: add missing clk_disable_unprepare on error in spi_qup_resume() [ Upstream commit 70034320fdc597b8f58b4a43bb547f17c4c5557a ] Add the missing clk_disable_unprepare() before return from spi_qup_resume() in the error handling case. Fixes: 64ff247a978f (“spi: Add Qualcomm QUP SPI controller support”) Signed-off-by: Xu Qiang Link: https://lore.kernel.org/r/20220825065324.68446-1-xuqiang36@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a3db90398a1c31a468adbd4a889cf81f621725b2 Author: Ian Rogers Date: Thu Sep 1 13:26:45 2022 -0700 selftests/xsk: Avoid use-after-free on ctx [ Upstream commit af515a5587b8f45f19e11657746e0c89411b0380 ] The put lowers the reference count to 0 and frees ctx, reading it afterwards is invalid. Move the put after the uses and determine the last use by the reference count being 1. Fixes: 39e940d4abfa ("selftests/xsk: Destroy BPF resources only when ctx refcount drops to 0") Signed-off-by: Ian Rogers Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20220901202645.1463552-1-irogers@google.com Signed-off-by: Sasha Levin commit 79329f970ae64a05de527cb53a3606077cf3dd83 Author: Yang Yingliang Date: Fri Aug 26 10:38:17 2022 +0800 wifi: rtw88: add missing destroy_workqueue() on error path in rtw_core_init() [ Upstream commit b0ea758b30bbdf7c4323c78b7c50c05d2e1224d5 ] Add the missing destroy_workqueue() before return from rtw_core_init() in error path. Fixes: fe101716c7c9 ("rtw88: replace tx tasklet with work queue") Signed-off-by: Yang Yingliang Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220826023817.3908255-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin commit d02a74c722582f513a001c96de7db8d0f9a94432 Author: Dan Carpenter Date: Fri Aug 19 08:23:43 2022 +0300 wifi: wfx: prevent underflow in wfx_send_pds() [ Upstream commit f97c81f5b7f8047810b0d79a8f759a83951210a0 ] This does a "chunk_len - 4" subtraction later when it calls: ret = wfx_hif_configuration(wdev, buf + 4, chunk_len - 4); so check for "chunk_len" is less than 4. Fixes: dcbecb497908 ("staging: wfx: allow new PDS format") Signed-off-by: Dan Carpenter Reviewed-by: Jérôme Pouiller Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/Yv8eX7Xv2ubUOvW7@kili Signed-off-by: Sasha Levin commit 5fff0f1b5d5749ef95163c576cd61586d3867205 Author: Dan Carpenter Date: Fri Aug 19 08:22:32 2022 +0300 wifi: rtl8xxxu: tighten bounds checking in rtl8xxxu_read_efuse() [ Upstream commit 620d5eaeb9059636864bda83ca1c68c20ede34a5 ] There some bounds checking to ensure that "map_addr" is not out of bounds before the start of the loop. But the checking needs to be done as we iterate through the loop because "map_addr" gets larger as we iterate. Fixes: 26f1fad29ad9 ("New driver: rtl8xxxu (mac80211)") Signed-off-by: Dan Carpenter Acked-by: Jes Sorensen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/Yv8eGLdBslLAk3Ct@kili Signed-off-by: Sasha Levin commit 7b8389b7e160dbb6cbcfcc3f847d8b368e8255c8 Author: Ping-Ke Shih Date: Wed Aug 24 14:33:12 2022 +0800 wifi: rtw89: pci: correct TX resource checking in low power mode [ Upstream commit 4a29213cd775cabcbe395229d175903accedbb9d ] Number of TX resource must be minimum of TX_BD and TX_WD. Only considering TX_BD could drop TX packets pulled from mac80211 if TX_WD is unavailable. Fixes: 52edbb9fb78a ("rtw89: ps: access TX/RX rings via another registers in low power mode") Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220824063312.15784-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit edb0fde1f7f3ca84580da62e0ce77cf32e6f8415 Author: Ping-Ke Shih Date: Wed Aug 24 14:33:11 2022 +0800 wifi: rtw89: pci: fix interrupt stuck after leaving low power mode [ Upstream commit b7e715d3dcd2e9fa3a689ba0dd7ab85f8aaf6e9a ] We turn off interrupt in ISR, and re-enable interrupt in threadfn or napi_poll according to the mode it stays. If we are turning off interrupt, rtwpci->running flag is unset and interrupt handler stop processing even if it was called, so disallow to re-enable interrupt in this situation. Or, wifi chip doesn't trigger interrupt events anymore because interrupt status (ISR) isn't clear by interrupt handler anymore. Fixes: c83dcd0508e2 ("rtw89: pci: add a separate interrupt handler for low power mode") Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220824063312.15784-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 85a642c3455fb0354b058a601a37bf311890ffb7 Author: Sean Wang Date: Thu Aug 11 08:49:07 2022 +0800 Bluetooth: btusb: mediatek: fix WMT failure during runtime suspend [ Upstream commit fd3f106677bac70437dc12e76c827294ed495a44 ] WMT cmd/event doesn't follow up the generic HCI cmd/event handling, it needs constantly polling control pipe until the host received the WMT event, thus, we should require to specifically acquire PM counter on the USB to prevent the interface from entering auto suspended while WMT cmd/event in progress. Fixes: a1c49c434e15 ("Bluetooth: btusb: Add protocol support for MediaTek MT7668U USB devices") Co-developed-by: Jing Cai Signed-off-by: Jing Cai Signed-off-by: Sean Wang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit dd5273e07984e0b8ee959cf4ccac8c1a99be329c Author: Hou Tao Date: Thu Sep 1 14:19:36 2022 +0800 bpf: Use this_cpu_{inc_return|dec} for prog->active [ Upstream commit c89e843a11f1075d27684f6b42256213e4592383 ] Both __this_cpu_inc_return() and __this_cpu_dec() are not preemption safe and now migrate_disable() doesn't disable preemption, so the update of prog-active is not atomic and in theory under fully preemptible kernel recurisve prevention may do not work. Fixing by using the preemption-safe and IRQ-safe variants. Fixes: ca06f55b9002 ("bpf: Add per-program recursion prevention mechanism") Signed-off-by: Hou Tao Acked-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20220901061938.3789460-3-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit ecbbef374ce5fad877104e107e180ce2fb3ce3b5 Author: Hou Tao Date: Thu Sep 1 14:19:35 2022 +0800 bpf: Use this_cpu_{inc|dec|inc_return} for bpf_task_storage_busy [ Upstream commit 197827a05e13808c60f52632e9887eede63f1c16 ] Now migrate_disable() does not disable preemption and under some architectures (e.g. arm64) __this_cpu_{inc|dec|inc_return} are neither preemption-safe nor IRQ-safe, so for fully preemptible kernel concurrent lookups or updates on the same task local storage and on the same CPU may make bpf_task_storage_busy be imbalanced, and bpf_task_storage_trylock() on the specific cpu will always fail. Fixing it by using this_cpu_{inc|dec|inc_return} when manipulating bpf_task_storage_busy. Fixes: bc235cdb423a ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]") Signed-off-by: Hou Tao Acked-by: Alexei Starovoitov Link: https://lore.kernel.org/r/20220901061938.3789460-2-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 75d287186b98d2b7058d759a0d8ba963e5a4bd25 Author: Manikanta Pubbisetty Date: Wed Aug 31 09:04:19 2022 +0300 wifi: ath11k: Fix incorrect QMI message ID mappings [ Upstream commit b3ca32308e46b6384fdcb7e64b3fca4f61aff14b ] QMI message IDs for some of the QMI messages were incorrectly defined in the original implementation. These have to be corrected to enable cold boot support on WCN6750. These corrections are applicable for all chipsets and will not impact them. Refactor the code accordingly. Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.1.0.1-00887-QCAMSLSWPLZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Manikanta Pubbisetty Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220720134909.15626-2-quic_mpubbise@quicinc.com Signed-off-by: Sasha Levin commit 6bfee6eb3d6b96ae730a542909dd22b5f9f50d58 Author: Hou Tao Date: Wed Aug 31 12:26:28 2022 +0800 bpf: Propagate error from htab_lock_bucket() to userspace [ Upstream commit 66a7a92e4d0d091e79148a4c6ec15d1da65f4280 ] In __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns -EBUSY, it will go to next bucket. Going to next bucket may not only skip the elements in current bucket silently, but also incur out-of-bound memory access or expose kernel memory to userspace if current bucket_cnt is greater than bucket_size or zero. Fixing it by stopping batch operation and returning -EBUSY when htab_lock_bucket() fails, and the application can retry or skip the busy batch as needed. Fixes: 20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked") Reported-by: Hao Sun Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20220831042629.130006-3-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit a759911bd1c678fe3795eda410946b0afe6eb96d Author: Hou Tao Date: Wed Aug 31 12:26:27 2022 +0800 bpf: Disable preemption when increasing per-cpu map_locked [ Upstream commit 2775da21628738ce073a3a6a806adcbaada0f091 ] Per-cpu htab->map_locked is used to prohibit the concurrent accesses from both NMI and non-NMI contexts. But since commit 74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT"), migrate_disable() is also preemptible under CONFIG_PREEMPT case, so now map_locked also disallows concurrent updates from normal contexts (e.g. userspace processes) unexpectedly as shown below: process A process B htab_map_update_elem() htab_lock_bucket() migrate_disable() /* return 1 */ __this_cpu_inc_return() /* preempted by B */ htab_map_update_elem() /* the same bucket as A */ htab_lock_bucket() migrate_disable() /* return 2, so lock fails */ __this_cpu_inc_return() return -EBUSY A fix that seems feasible is using in_nmi() in htab_lock_bucket() and only checking the value of map_locked for nmi context. But it will re-introduce dead-lock on bucket lock if htab_lock_bucket() is re-entered through non-tracing program (e.g. fentry program). One cannot use preempt_disable() to fix this issue as htab_use_raw_lock being false causes the bucket lock to be a spin lock which can sleep and does not work with preempt_disable(). Therefore, use migrate_disable() when using the spinlock instead of preempt_disable() and defer fixing concurrent updates to when the kernel has its own BPF memory allocator. Fixes: 74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT") Reviewed-by: Hao Luo Signed-off-by: Hou Tao Link: https://lore.kernel.org/r/20220831042629.130006-2-houtao@huaweicloud.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit dd88139cb53c87b6a3ad4ccbc04cdf66c196f8ec Author: Maciej Fijalkowski Date: Tue Aug 30 15:39:05 2022 +0200 selftests/xsk: Add missing close() on netns fd [ Upstream commit 8a7d61bdc2fac2c460a2f32a062f5c6dbd21a764 ] Commit 1034b03e54ac ("selftests: xsk: Simplify cleanup of ifobjects") removed close on netns fd, which is not correct, so let us restore it. Fixes: 1034b03e54ac ("selftests: xsk: Simplify cleanup of ifobjects") Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20220830133905.9945-1-maciej.fijalkowski@intel.com Signed-off-by: Sasha Levin commit 5f2a838113bd045b1080cc8d4bfefa6cd94b6d9e Author: Maciej Fijalkowski Date: Tue Aug 30 14:17:05 2022 +0200 xsk: Fix backpressure mechanism on Tx [ Upstream commit c00c4461689e15ac2cc3b9a595a54e4d8afd3d77 ] Commit d678cbd2f867 ("xsk: Fix handling of invalid descriptors in XSK TX batching API") fixed batch API usage against set of descriptors with invalid ones but introduced a problem when AF_XDP SW rings are smaller than HW ones. Mismatch of reported Tx'ed frames between HW generator and user space app was observed. It turned out that backpressure mechanism became a bottleneck when the amount of produced descriptors to CQ is lower than what we grabbed from XSK Tx ring. Say that 512 entries had been taken from XSK Tx ring but we had only 490 free entries in CQ. Then callsite (ZC driver) will produce only 490 entries onto HW Tx ring but 512 entries will be released from Tx ring and this is what will be seen by the user space. In order to fix this case, mix XSK Tx/CQ ring interractions by moving around internal functions and changing call order: * pull out xskq_prod_nb_free() from xskq_prod_reserve_addr_batch() up to xsk_tx_peek_release_desc_batch(); ** move xskq_cons_release_n() into xskq_cons_read_desc_batch() After doing so, algorithm can be described as follows: 1. lookup Tx entries 2. use value from 1. to reserve space in CQ (*) 3. Read from Tx ring as much descriptors as value from 2 3a. release descriptors from XSK Tx ring (**) 4. Finally produce addresses to CQ Fixes: d678cbd2f867 ("xsk: Fix handling of invalid descriptors in XSK TX batching API") Signed-off-by: Magnus Karlsson Signed-off-by: Maciej Fijalkowski Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220830121705.8618-1-maciej.fijalkowski@intel.com Signed-off-by: Sasha Levin commit 3345cd3612b57f229017f82b270b9dde3fb5f5b8 Author: Kohei Tarumizu Date: Wed Aug 24 09:44:10 2022 -0700 x86/resctrl: Fix to restore to original value when re-enabling hardware prefetch register [ Upstream commit 499c8bb4693d1c8d8f3d6dd38e5bdde3ff5bd906 ] The current pseudo_lock.c code overwrites the value of the MSR_MISC_FEATURE_CONTROL to 0 even if the original value is not 0. Therefore, modify it to save and restore the original values. Fixes: 018961ae5579 ("x86/intel_rdt: Pseudo-lock region creation/removal core") Fixes: 443810fe6160 ("x86/intel_rdt: Create debugfs files for pseudo-locking testing") Fixes: 8a2fc0e1bc0c ("x86/intel_rdt: More precise L2 hit/miss measurements") Signed-off-by: Kohei Tarumizu Signed-off-by: Dave Hansen Acked-by: Reinette Chatre Link: https://lkml.kernel.org/r/eb660f3c2010b79a792c573c02d01e8e841206ad.1661358182.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin commit e90195d5bbb96b0131641c4d73ce96ada37f5ceb Author: Christophe JAILLET Date: Sat Aug 27 13:42:07 2022 +0200 spi: mt7621: Fix an error message in mt7621_spi_probe() [ Upstream commit 2b2bf6b7faa9010fae10dc7de76627a3fdb525b3 ] 'status' is known to be 0 at this point. The expected error code is PTR_ERR(clk). Switch to dev_err_probe() in order to display the expected error code (in a human readable way). This also filters -EPROBE_DEFER cases, should it happen. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Christophe JAILLET Reviewed-by: Matthias Brugger Link: https://lore.kernel.org/r/928f3fb507d53ba0774df27cea0bbba4b055993b.1661599671.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f53f2814e914d678b4521513d082b60a1b1470dd Author: Sabrina Dubroca Date: Thu Aug 25 17:16:51 2022 +0200 esp: choose the correct inner protocol for GSO on inter address family tunnels [ Upstream commit 26dbd66eab8080be51759e48280da04015221e22 ] Commit 23c7f8d7989e ("net: Fix esp GSO on inter address family tunnels.") is incomplete. It passes to skb_eth_gso_segment the protocol for the outer IP version, instead of the inner IP version, so we end up calling inet_gso_segment on an inner IPv6 packet and ipv6_gso_segment on an inner IPv4 packet and the packets are dropped. This patch completes the fix by selecting the correct protocol based on the inner mode's family. Fixes: c35fe4106b92 ("xfrm: Add mode handlers for IPsec on layer 2") Signed-off-by: Sabrina Dubroca Signed-off-by: Steffen Klassert Signed-off-by: Sasha Levin commit d3c1fb19ca1ec2e7b6c26549f4fe4c3707be13bf Author: Richard Guy Briggs Date: Thu Aug 25 15:32:39 2022 -0400 audit: free audit_proctitle only on task exit [ Upstream commit c3f3ea8af44d0c5fba79fe8b198087342d0c7e04 ] Since audit_proctitle is generated at syscall exit time, its value is used immediately and cached for the next syscall. Since this is the case, then only clear it at task exit time. Otherwise, there is no point in caching the value OR bearing the overhead of regenerating it. Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts beyond syscalls") Signed-off-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 44fe6d9a0d8d4554cd450baf754e4e6eb6b44e65 Author: Richard Guy Briggs Date: Thu Aug 25 15:32:38 2022 -0400 audit: explicitly check audit_context->context enum value [ Upstream commit 3ed66951f952ed8f1a5d03e171722bf2631e8d58 ] Be explicit in checking the struct audit_context "context" member enum value rather than assuming the order of context enum values. Fixes: 12c5e81d3fd0 ("audit: prepare audit_context for use in calling contexts beyond syscalls") Signed-off-by: Richard Guy Briggs Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit b35f60d6cf97b1518c3d60f52a9a395bb7f614a4 Author: Lam Thai Date: Wed Aug 24 15:59:00 2022 -0700 bpftool: Fix a wrong type cast in btf_dumper_int [ Upstream commit 7184aef9c0f7a81db8fd18d183ee42481d89bf35 ] When `data` points to a boolean value, casting it to `int *` is problematic and could lead to a wrong value being passed to `jsonw_bool`. Change the cast to `bool *` instead. Fixes: b12d6ec09730 ("bpf: btf: add btf print functionality") Signed-off-by: Lam Thai Signed-off-by: Andrii Nakryiko Reviewed-by: Quentin Monnet Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20220824225859.9038-1-lamthai@arista.com Signed-off-by: Sasha Levin commit de5b1600689c8d9be44ceafbc9a24e68fe5b61d7 Author: Hari Chandrakanthan Date: Wed Jul 27 12:02:29 2022 +0530 wifi: mac80211: allow bw change during channel switch in mesh [ Upstream commit 6b75f133fe05c36c52d691ff21545d5757fff721 ] From 'IEEE Std 802.11-2020 section 11.8.8.4.1': The mesh channel switch may be triggered by the need to avoid interference to a detected radar signal, or to reassign mesh STA channels to ensure the MBSS connectivity. A 20/40 MHz MBSS may be changed to a 20 MHz MBSS and a 20 MHz MBSS may be changed to a 20/40 MHz MBSS. Since the standard allows the change of bandwidth during the channel switch in mesh, remove the bandwidth check present in ieee80211_set_csa_beacon. Fixes: c6da674aff94 ("{nl,cfg,mac}80211: enable the triggering of CSA frame in mesh") Signed-off-by: Hari Chandrakanthan Link: https://lore.kernel.org/r/1658903549-21218-1-git-send-email-quic_haric@quicinc.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a43b2d121829616e5d0ef7e50bd735d123fe45db Author: Shaul Triebitz Date: Mon Aug 1 14:12:29 2022 +0300 wifi: cfg80211: get correct AP link chandef [ Upstream commit bc1857619cc7612117d2ee1ed05b5bfeb638614b ] When checking for channel regulatory validity, use the AP link chandef (and not mesh's chandef). Fixes: 7b0a0e3c3a88 ("wifi: cfg80211: do some rework towards MLO link APIs") Signed-off-by: Shaul Triebitz Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit caa176c0953cdfd5ce500fb517ce1ea924a8bc4c Author: Kumar Kartikeya Dwivedi Date: Tue Aug 23 03:31:25 2022 +0200 bpf: Fix reference state management for synchronous callbacks [ Upstream commit 9d9d00ac29d0ef7ce426964de46fa6b380357d0a ] Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback. While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times. A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack). Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks. Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame. Hence async callback is safe. Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks). In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller). Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Signed-off-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220823013125.24938-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit 160b9f792f994364ed3bbc6b11a7e9adf2df8ca3 Author: Gerhard Engleder Date: Wed Aug 17 21:30:13 2022 +0200 tsnep: Fix TSNEP_INFO_TX_TIME register define [ Upstream commit 7d8dd6b5cd1d67dd96c132f91d7ad29c49ed3c59 ] Fixed register define is not used, but register definition shall be kept in sync. Fixes: 403f69bbdbad ("tsnep: Add TSN endpoint Ethernet MAC driver") Signed-off-by: Gerhard Engleder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 385072c05eb9e882da45a5150dc1543a4da22305 Author: Uwe Kleine-König Date: Mon Aug 15 10:02:27 2022 +0200 leds: lm3601x: Don't use mutex after it was destroyed [ Upstream commit 32f7eed0c763a9b89f6b357ec54b48398fc7b99e ] The mutex might still be in use until the devm cleanup callback devm_led_classdev_flash_release() is called. This only happens some time after lm3601x_remove() completed. Fixes: e63a744871a3 ("leds: lm3601x: Convert class registration to device managed") Acked-by: Pavel Machek Signed-off-by: Uwe Kleine-König Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 707d7a774dccba1607d4d844d146eb8794e0799b Author: Dave Marchevsky Date: Mon Aug 8 10:15:59 2022 -0700 bpf: Cleanup check_refcount_ok [ Upstream commit b2d8ef19c6e7ed71ba5092feb0710063a751834f ] Discussion around a recently-submitted patch provided historical context for check_refcount_ok [0]. Specifically, the function and its helpers - may_be_acquire_function and arg_type_may_be_refcounted - predate the OBJ_RELEASE type flag and the addition of many more helpers with acquire/release semantics. The purpose of check_refcount_ok is to ensure: 1) Helper doesn't have multiple uses of return reg's ref_obj_id 2) Helper with release semantics only has one arg needing to be released, since that's tracked using meta->ref_obj_id With current verifier, it's safe to remove check_refcount_ok and its helpers. Since addition of OBJ_RELEASE type flag, case 2) has been handled by the arg_type_is_release check in check_func_arg. To ensure case 1) won't result in verifier silently prioritizing one use of ref_obj_id, this patch adds a helper_multiple_ref_obj_use check which fails loudly if a helper passes > 1 test for use of ref_obj_id. [0]: lore.kernel.org/bpf/20220713234529.4154673-1-davemarchevsky@fb.com Signed-off-by: Dave Marchevsky Acked-by: Martin KaFai Lau Acked-by: Joanne Koong Acked-by: Kumar Kartikeya Dwivedi Link: https://lore.kernel.org/r/20220808171559.3251090-1-davemarchevsky@fb.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 883743422ced ("bpf: Fix ref_obj_id for dynptr data slices in verifier") Signed-off-by: Sasha Levin commit 606cfa07908957c05d9f340c9f399cfaa96fd7f5 Author: Stanislav Fomichev Date: Tue Jun 28 10:43:05 2022 -0700 bpf: convert cgroup_bpf.progs to hlist [ Upstream commit 00442143a2ab7f1da46fbf4d2a99c85df767d49a ] This lets us reclaim some space to be used by new cgroup lsm slots. Before: struct cgroup_bpf { struct bpf_prog_array * effective[23]; /* 0 184 */ /* --- cacheline 2 boundary (128 bytes) was 56 bytes ago --- */ struct list_head progs[23]; /* 184 368 */ /* --- cacheline 8 boundary (512 bytes) was 40 bytes ago --- */ u32 flags[23]; /* 552 92 */ /* XXX 4 bytes hole, try to pack */ /* --- cacheline 10 boundary (640 bytes) was 8 bytes ago --- */ struct list_head storages; /* 648 16 */ struct bpf_prog_array * inactive; /* 664 8 */ struct percpu_ref refcnt; /* 672 16 */ struct work_struct release_work; /* 688 32 */ /* size: 720, cachelines: 12, members: 7 */ /* sum members: 716, holes: 1, sum holes: 4 */ /* last cacheline: 16 bytes */ }; After: struct cgroup_bpf { struct bpf_prog_array * effective[23]; /* 0 184 */ /* --- cacheline 2 boundary (128 bytes) was 56 bytes ago --- */ struct hlist_head progs[23]; /* 184 184 */ /* --- cacheline 5 boundary (320 bytes) was 48 bytes ago --- */ u8 flags[23]; /* 368 23 */ /* XXX 1 byte hole, try to pack */ /* --- cacheline 6 boundary (384 bytes) was 8 bytes ago --- */ struct list_head storages; /* 392 16 */ struct bpf_prog_array * inactive; /* 408 8 */ struct percpu_ref refcnt; /* 416 16 */ struct work_struct release_work; /* 432 72 */ /* size: 504, cachelines: 8, members: 7 */ /* sum members: 503, holes: 1, sum holes: 1 */ /* last cacheline: 56 bytes */ }; Suggested-by: Jakub Sitnicki Reviewed-by: Jakub Sitnicki Reviewed-by: Martin KaFai Lau Signed-off-by: Stanislav Fomichev Link: https://lore.kernel.org/r/20220628174314.1216643-3-sdf@google.com Signed-off-by: Alexei Starovoitov Stable-dep-of: 883743422ced ("bpf: Fix ref_obj_id for dynptr data slices in verifier") Signed-off-by: Sasha Levin commit 044bc355cdb57b05394902e60b75f9b39740a33a Author: Joanne Koong Date: Thu Jun 16 15:54:07 2022 -0700 bpf: Fix non-static bpf_func_proto struct definitions [ Upstream commit dc368e1c658e4f478a45e8d1d5b0c8392ca87506 ] This patch does two things: 1) Marks the dynptr bpf_func_proto structs that were added in [1] as static, as pointed out by the kernel test robot in [2]. 2) There are some bpf_func_proto structs marked as extern which can instead be statically defined. [1] https://lore.kernel.org/bpf/20220523210712.3641569-1-joannelkoong@gmail.com/ [2] https://lore.kernel.org/bpf/62ab89f2.Pko7sI08RAKdF8R6%25lkp@intel.com/ Reported-by: kernel test robot Signed-off-by: Joanne Koong Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20220616225407.1878436-1-joannelkoong@gmail.com Stable-dep-of: 883743422ced ("bpf: Fix ref_obj_id for dynptr data slices in verifier") Signed-off-by: Sasha Levin commit 2bf916418d2141b810c40812433ab4ecfd3c2934 Author: Wen Gong Date: Mon Aug 1 10:19:30 2022 -0400 wifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state() [ Upstream commit f020d9570a04df0762a2ac5c50cf1d8c511c9164 ] When peer delete failed in a disconnect operation, use-after-free detected by KFENCE in below log. It is because for each vdev_id and address, it has only one struct ath10k_peer, it is allocated in ath10k_peer_map_event(). When connected to an AP, it has more than one HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then the array peer_map of struct ath10k will be set muti-elements to the same ath10k_peer in ath10k_peer_map_event(). When peer delete failed in ath10k_sta_state(), the ath10k_peer will be free for the 1st peer id in array peer_map of struct ath10k, and then use-after-free happened for the 2nd peer id because they map to the same ath10k_peer. And clean up all peers in array peer_map for the ath10k_peer, then user-after-free disappeared peer map event log: [ 306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e [ 306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33 [ 306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246 [ 306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198 [ 306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166 peer unmap event log: [ 435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING) [ 435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone) [ 435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246 [ 435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198 [ 435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166 use-after-free log: [21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING) [21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110 [21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed [21713.799968] ================================================================== [21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core] [21713.799991] [21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69): [21713.800010] ath10k_sta_state+0x265/0xb8a [ath10k_core] [21713.800041] drv_sta_state+0x115/0x677 [mac80211] [21713.800059] __sta_info_destroy_part2+0xb1/0x133 [mac80211] [21713.800076] __sta_info_flush+0x11d/0x162 [mac80211] [21713.800093] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211] [21713.800110] ieee80211_mgd_deauth+0x26c/0x29b [mac80211] [21713.800137] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211] [21713.800153] nl80211_deauthenticate+0xf8/0x121 [cfg80211] [21713.800161] genl_rcv_msg+0x38e/0x3be [21713.800166] netlink_rcv_skb+0x89/0xf7 [21713.800171] genl_rcv+0x28/0x36 [21713.800176] netlink_unicast+0x179/0x24b [21713.800181] netlink_sendmsg+0x3a0/0x40e [21713.800187] sock_sendmsg+0x72/0x76 [21713.800192] ____sys_sendmsg+0x16d/0x1e3 [21713.800196] ___sys_sendmsg+0x95/0xd1 [21713.800200] __sys_sendmsg+0x85/0xbf [21713.800205] do_syscall_64+0x43/0x55 [21713.800210] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [21713.800213] [21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k [21713.800219] [21713.800224] allocated by task 13 on cpu 0 at 21705.501373s: [21713.800241] ath10k_peer_map_event+0x7e/0x154 [ath10k_core] [21713.800254] ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core] [21713.800265] ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core] [21713.800277] ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core] [21713.800283] ath10k_pci_process_rx_cb+0x195/0x1df [ath10k_pci] [21713.800294] ath10k_ce_per_engine_service+0x55/0x74 [ath10k_core] [21713.800305] ath10k_ce_per_engine_service_any+0x76/0x84 [ath10k_core] [21713.800310] ath10k_pci_napi_poll+0x49/0x144 [ath10k_pci] [21713.800316] net_rx_action+0xdc/0x361 [21713.800320] __do_softirq+0x163/0x29a [21713.800325] asm_call_irq_on_stack+0x12/0x20 [21713.800331] do_softirq_own_stack+0x3c/0x48 [21713.800337] __irq_exit_rcu+0x9b/0x9d [21713.800342] common_interrupt+0xc9/0x14d [21713.800346] asm_common_interrupt+0x1e/0x40 [21713.800351] ksoftirqd_should_run+0x5/0x16 [21713.800357] smpboot_thread_fn+0x148/0x211 [21713.800362] kthread+0x150/0x15f [21713.800367] ret_from_fork+0x22/0x30 [21713.800370] [21713.800374] freed by task 708 on cpu 1 at 21713.799953s: [21713.800498] ath10k_sta_state+0x2c6/0xb8a [ath10k_core] [21713.800515] drv_sta_state+0x115/0x677 [mac80211] [21713.800532] __sta_info_destroy_part2+0xb1/0x133 [mac80211] [21713.800548] __sta_info_flush+0x11d/0x162 [mac80211] [21713.800565] ieee80211_set_disassoc+0x12d/0x2f4 [mac80211] [21713.800581] ieee80211_mgd_deauth+0x26c/0x29b [mac80211] [21713.800598] cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211] [21713.800614] nl80211_deauthenticate+0xf8/0x121 [cfg80211] [21713.800619] genl_rcv_msg+0x38e/0x3be [21713.800623] netlink_rcv_skb+0x89/0xf7 [21713.800628] genl_rcv+0x28/0x36 [21713.800632] netlink_unicast+0x179/0x24b [21713.800637] netlink_sendmsg+0x3a0/0x40e [21713.800642] sock_sendmsg+0x72/0x76 [21713.800646] ____sys_sendmsg+0x16d/0x1e3 [21713.800651] ___sys_sendmsg+0x95/0xd1 [21713.800655] __sys_sendmsg+0x85/0xbf [21713.800659] do_syscall_64+0x43/0x55 [21713.800663] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 Fixes: d0eeafad1189 ("ath10k: Clean up peer when sta goes away.") Signed-off-by: Wen Gong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220801141930.16794-1-quic_wgong@quicinc.com Signed-off-by: Sasha Levin commit aaf7ca4714151605cacb23642e8d0245d36ec9ab Author: Ping-Ke Shih Date: Mon Aug 1 19:33:45 2022 +0800 wifi: rtlwifi: 8192de: correct checking of IQK reload [ Upstream commit 93fbc1ebd978cf408ef5765e9c1630fce9a8621b ] Since IQK could spend time, we make a cache of IQK result matrix that looks like iqk_matrix[channel_idx].val[x][y], and we can reload the matrix if we have made a cache. To determine a cache is made, we check iqk_matrix[channel_idx].val[0][0]. The initial commit 7274a8c22980 ("rtlwifi: rtl8192de: Merge phy routines") make a mistake that checks incorrect iqk_matrix[channel_idx].val[0] that is always true, and this mistake is found by commit ee3db469dd31 ("wifi: rtlwifi: remove always-true condition pointed out by GCC 12"), so I recall the vendor driver to find fix and apply the correctness. Fixes: 7274a8c22980 ("rtlwifi: rtl8192de: Merge phy routines") Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220801113345.42016-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit 082eb9beed5db6f3cc918f786cfeef04ab643aec Author: Bill Wendling Date: Fri Sep 2 21:37:50 2022 +0000 x86/paravirt: add extra clobbers with ZERO_CALL_USED_REGS enabled [ Upstream commit 8c86f29bfb18465d15b05cfd26a6454ec787b793 ] The ZERO_CALL_USED_REGS feature may zero out caller-saved registers before returning. In spurious_kernel_fault(), the "pte_offset_kernel()" call results in this assembly code: .Ltmp151: #APP # ALT: oldnstr .Ltmp152: .Ltmp153: .Ltmp154: .section .discard.retpoline_safe,"",@progbits .quad .Ltmp154 .text callq *pv_ops+536(%rip) .Ltmp155: .section .parainstructions,"a",@progbits .p2align 3, 0x0 .quad .Ltmp153 .byte 67 .byte .Ltmp155-.Ltmp153 .short 1 .text .Ltmp156: # ALT: padding .zero (-(((.Ltmp157-.Ltmp158)-(.Ltmp156-.Ltmp152))>0))*((.Ltmp157-.Ltmp158)-(.Ltmp156-.Ltmp152)),144 .Ltmp159: .section .altinstructions,"a",@progbits .Ltmp160: .long .Ltmp152-.Ltmp160 .Ltmp161: .long .Ltmp158-.Ltmp161 .short 33040 .byte .Ltmp159-.Ltmp152 .byte .Ltmp157-.Ltmp158 .text .section .altinstr_replacement,"ax",@progbits # ALT: replacement 1 .Ltmp158: movq %rdi, %rax .Ltmp157: .text #NO_APP .Ltmp162: testb $-128, %dil The "testb" here is using %dil, but the %rdi register was cleared before returning from "callq *pv_ops+536(%rip)". Adding the proper constraints results in the use of a different register: movq %r11, %rdi # Similar to above. testb $-128, %r11b Link: https://github.com/KSPP/linux/issues/192 Signed-off-by: Bill Wendling Reported-and-tested-by: Nathan Chancellor Fixes: 035f7f87b729 ("randstruct: Enable Clang support") Reviewed-by: Juergen Gross Link: https://lore.kernel.org/lkml/fa6df43b-8a1a-8ad1-0236-94d2a0b588fa@suse.com/ Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220902213750.1124421-3-morbo@google.com Signed-off-by: Sasha Levin commit 221cb89ff40e6b530f5bc76187c151e9f7a18912 Author: Chuck Lever Date: Mon Sep 5 15:33:32 2022 -0400 NFSD: Fix handling of oversized NFSv4 COMPOUND requests [ Upstream commit 7518a3dc5ea249d4112156ce71b8b184eb786151 ] If an NFS server returns NFS4ERR_RESOURCE on the first operation in an NFSv4 COMPOUND, there's no way for a client to know where the problem is and then simplify the compound to make forward progress. So instead, make NFSD process as many operations in an oversized COMPOUND as it can and then return NFS4ERR_RESOURCE on the first operation it did not process. pynfs NFSv4.0 COMP6 exercises this case, but checks only for the COMPOUND status code, not whether the server has processed any of the operations. pynfs NFSv4.1 SEQ6 and SEQ7 exercise the NFSv4.1 case, which detects too many operations per COMPOUND by checking against the limits negotiated when the session was created. Suggested-by: Bruce Fields Fixes: 0078117c6d91 ("nfsd: return RESOURCE not GARBAGE_ARGS on too many ops") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit c2a878095b5c6f04f90553a3c45872f990dab14e Author: Chuck Lever Date: Thu Sep 1 15:10:05 2022 -0400 NFSD: Protect against send buffer overflow in NFSv2 READDIR [ Upstream commit 00b4492686e0497fdb924a9d4c8f6f99377e176c ] Restore the previous limit on the @count argument to prevent a buffer overflow attack. Fixes: 53b1119a6e50 ("NFSD: Fix READDIR buffer overflow") Signed-off-by: Chuck Lever Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 692b69ddb786a10dd4252d4eb121be8e1946b72a Author: Chuck Lever Date: Thu Sep 1 15:09:59 2022 -0400 SUNRPC: Fix svcxdr_init_encode's buflen calculation [ Upstream commit 1242a87da0d8cd2a428e96ca68e7ea899b0f4624 ] Commit 2825a7f90753 ("nfsd4: allow encoding across page boundaries") added an explicit computation of the remaining length in the rq_res XDR buffer. The computation appears to suffer from an "off-by-one" bug. Because buflen is too large by one page, XDR encoding can run off the end of the send buffer by eventually trying to use the struct page address in rq_page_end, which always contains NULL. Fixes: bddfdbcddbe2 ("NFSD: Extract the svcxdr_init_encode() helper") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2eea66b010f72da266496d0a209a80fb8048797d Author: Chuck Lever Date: Thu Sep 1 15:09:53 2022 -0400 SUNRPC: Fix svcxdr_init_decode's end-of-buffer calculation [ Upstream commit 90bfc37b5ab91c1a6165e3e5cfc49bf04571b762 ] Ensure that stream-based argument decoding can't go past the actual end of the receive buffer. xdr_init_decode's calculation of the value of xdr->end over-estimates the end of the buffer because the Linux kernel RPC server code does not remove the size of the RPC header from rqstp->rq_arg before calling the upper layer's dispatcher. The server-side still uses the svc_getnl() macros to decode the RPC call header. These macros reduce the length of the head iov but do not update the total length of the message in the buffer (buf->len). A proper fix for this would be to replace the use of svc_getnl() and friends in the RPC header decoder, but that would be a large and invasive change that would be difficult to backport. Fixes: 5191955d6fc6 ("SUNRPC: Prepare for xdr_stream-style decoding on the server-side") Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 733dd17158f96aaa25408dc39bbb2738fda9300e Author: Christophe JAILLET Date: Thu Sep 1 07:27:04 2022 +0200 nfsd: Fix a memory leak in an error handling path [ Upstream commit fd1ef88049de09bc70d60b549992524cfc0e66ff ] If this memdup_user() call fails, the memory allocated in a previous call a few lines above should be freed. Otherwise it leaks. Fixes: 6ee95d1c8991 ("nfsd: add support for upcall version 2") Signed-off-by: Christophe JAILLET Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e58eef8ee86c239a73234e3b97d68ad82bc1f894 Author: Sami Tolvanen Date: Thu Sep 8 14:54:58 2022 -0700 objtool: Preserve special st_shndx indexes in elf_update_symbol [ Upstream commit 5141d3a06b2da1731ac82091298b766a1f95d3d8 ] elf_update_symbol fails to preserve the special st_shndx values between [SHN_LORESERVE, SHN_HIRESERVE], which results in it converting SHN_ABS entries into SHN_UNDEF, for example. Explicitly check for the special indexes and ensure these symbols are not marked undefined. Fixes: ead165fa1042 ("objtool: Fix symbol creation") Signed-off-by: Sami Tolvanen Acked-by: Peter Zijlstra (Intel) Tested-by: Peter Zijlstra (Intel) Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220908215504.3686827-17-samitolvanen@google.com Signed-off-by: Sasha Levin commit 970812475926b525b3f421fdb5d9dfa880189162 Author: Huisong Li Date: Tue Sep 20 17:45:00 2022 +0800 ACPI: PCC: Fix Tx acknowledge in the PCC address space handler [ Upstream commit 18729106c26fb97d4c9ae63ba7aba9889a058dc4 ] Currently, mbox_client_txdone() is called from the PCC address space handler and that expects the user the Tx state machine to be controlled by the client which is not the case and the below warning is thrown: | PCCT: Client can't run the TX ticker Let the controller run the state machine and the end of Tx can be acknowledge by calling mbox_chan_txdone() instead. Fixes: 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") Signed-off-by: Huisong Li Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f1f8085da2cacdf5d0b52e3fcf860043cf4cb97b Author: Huisong Li Date: Tue Sep 20 17:44:59 2022 +0800 ACPI: PCC: replace wait_for_completion() [ Upstream commit 91cefefb699120efd0a5ba345d12626b688f86ce ] Currently, the function waiting for completion of mailbox operation is 'wait_for_completion()'. The PCC method will be permanently blocked if this mailbox message fails to execute. So this patch replaces it with 'wait_for_completion_timeout()'. And set the timeout interval to an arbitrary retries on top of nominal to prevent the remote processor is slow to respond to PCC commands. Fixes: 77e2a04745ff ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") Signed-off-by: Huisong Li Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 4e714c4c370e131779a0c4273c6b65fcdae4271d Author: Rafael Mendonca Date: Fri Sep 9 12:33:19 2022 -0300 ACPI: PCC: Release resources on address space setup failure path [ Upstream commit f890157e61b85ce8ae01a41ffa375e3b99853698 ] The allocated memory for the pcc_data struct doesn't get freed under an error path in pcc_mbox_request_channel() or acpi_os_ioremap(). Also, the PCC mailbox channel doesn't get freed under an error path in acpi_os_ioremap(). Fixes: 77e2a04745ff8 ("ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype") Signed-off-by: Rafael Mendonca Reviewed-by: Sudeep Holla Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 65cfd9c59fd8ef681d47a146dbd631df0828aefb Author: Wang Kefeng Date: Fri Sep 16 12:10:49 2022 +0100 ARM: 9247/1: mm: set readonly for MT_MEMORY_RO with ARM_LPAE [ Upstream commit 14ca1a4690750bb54e1049e49f3140ef48958a6e ] MT_MEMORY_RO is introduced by commit 598f0a99fa8a ("ARM: 9210/1: Mark the FDT_FIXED sections as shareable"), which is a readonly memory type for FDT area, but there are some different between ARM_LPAE and non-ARM_LPAE, we need to setup PMD_SECT_AP2 and L_PMD_SECT_RDONLY for MT_MEMORY_RO when ARM_LAPE enabled. non-ARM_LPAE 0xff800000-0xffa00000 2M PGD KERNEL ro NX SHD ARM_LPAE 0xff800000-0xffc00000 4M PMD RW NX SHD ARM_LPAE+fix 0xff800000-0xffc00000 4M PMD ro NX SHD Fixes: 598f0a99fa8a ("ARM: 9210/1: Mark the FDT_FIXED sections as shareable") Signed-off-by: Kefeng Wang Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit f6fe0681bdd03e91ca479be13fea92a9426d5163 Author: Wang Kefeng Date: Tue Sep 13 05:25:51 2022 +0100 ARM: 9244/1: dump: Fix wrong pg_level in walk_pmd() [ Upstream commit 2ccd19b3ffac07cc7e75a2bd1ed779728bb67197 ] After ARM supports p4d page tables, the pg_level for note_page() in walk_pmd() should be 4, not 3, fix it. Fixes: 84e6ffb2c49c ("arm: add support for folded p4d page tables") Signed-off-by: Kefeng Wang Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 80ec7f839264c59a6fbecc6f308058b910c13ac0 Author: Bart Van Assche Date: Mon Sep 12 23:13:53 2022 +0100 ARM: 9243/1: riscpc: Unbreak the build [ Upstream commit 32844a8eecaa4a3e65841c53e43e04a9087d1ef6 ] This patch fixes the following build error: In file included from ./include/linux/io.h:13, from ./arch/arm/mach-rpc/include/mach/uncompress.h:9, from arch/arm/boot/compressed/misc.c:31: ./arch/arm/include/asm/io.h:85:22: error: conflicting types for ‘__raw_writeb’ 85 | #define __raw_writeb __raw_writeb | ^~~~~~~~~~~~ ./arch/arm/include/asm/io.h:86:20: note: in expansion of macro ‘__raw_writeb’ 86 | static inline void __raw_writeb(u8 val, volatile void __iomem *addr) | ^~~~~~~~~~~~ In file included from arch/arm/boot/compressed/misc.c:26: arch/arm/boot/compressed/misc-ep93xx.h:13:20: note: previous definition of ‘__raw_writeb’ was here 13 | static inline void __raw_writeb(unsigned char value, unsigned int ptr) | ^~~~~~~~~~~~ To: Russell King Cc: Arnd Bergmann Cc: linux-arm-kernel@lists.infradead.org Fixes: 0361c7e504b1 ("ARM: ep93xx: multiplatform support") Signed-off-by: Bart Van Assche Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit f27bafeb9fb455a686c47389e96193d7b2931de9 Author: Jia Zhu Date: Sun Sep 18 12:34:51 2022 +0800 erofs: use kill_anon_super() to kill super in fscache mode [ Upstream commit 1015c1016c231b26d4e2c9b3da65b6c043eb97a3 ] Use kill_anon_super() instead of generic_shutdown_super() since the mount() in erofs fscache mode uses get_tree_nodev() and associated anon bdev needs to be freed. Fixes: 9c0cc9c729657 ("erofs: add 'fsid' mount option") Suggested-by: Jingbo Xu Signed-off-by: Jia Zhu Reviewed-by: Jingbo Xu Link: https://lore.kernel.org/r/20220918043456.147-2-zhujia.zj@bytedance.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit b6c8330f5b0f22149957a2e4977fd0f01a9db7cd Author: Gao Xiang Date: Fri Sep 9 10:39:48 2022 +0800 erofs: fix order >= MAX_ORDER warning due to crafted negative i_size [ Upstream commit 1dd73601a1cba37a0ed5f89a8662c90191df5873 ] As syzbot reported [1], the root cause is that i_size field is a signed type, and negative i_size is also less than EROFS_BLKSIZ. As a consequence, it's handled as fast symlink unexpectedly. Let's fall back to the generic path to deal with such unusual i_size. [1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com Reported-by: syzbot+f966c13b1b4fc0403b19@syzkaller.appspotmail.com Fixes: 431339ba9042 ("staging: erofs: add inode operations") Reviewed-by: Yue Hu Link: https://lore.kernel.org/r/20220909023948.28925-1-hsiangkao@linux.alibaba.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit d7ac29e60d0ff71e9e414af595b8c92800f7fa90 Author: Lin Yujun Date: Wed Sep 14 11:29:17 2022 +0800 MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create() [ Upstream commit 11bec9cba4de06b3c0e9e4041453c2caaa1cbec1 ] In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed 'pdev' or it will be leak, call platform_device_put() to fix this problem. Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd', use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails. Fixes: 5dc76a96e95a ("MIPS: PCI: use information from 1-wire PROM for IOC3 detection") Signed-off-by: Lin Yujun Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit a253f3b59ff0e6ab2f63483180c4b421cc96fca6 Author: Lin Yujun Date: Wed Sep 14 11:28:07 2022 +0800 MIPS: SGI-IP30: Fix platform-device leak in bridge_platform_create() [ Upstream commit 1e6d11fe72e311c1989991ee318d239f650fa318 ] In error case in bridge_platform_create after calling platform_device_add()/platform_device_add_data()/ platform_device_add_resources(), release the failed 'pdev' or it will be leak, call platform_device_put() to fix this problem. Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd', use platform_device_unregister() to release sgi_w1 resources when xtalk-bridge registration fails. Fixes: fd27234f24ae ("MIPS: add support for SGI Octane (IP30)") Signed-off-by: Lin Yujun Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 8010fece7cd03235762ea109a9612ba467bb9259 Author: Kees Cook Date: Wed Sep 7 16:40:44 2022 -0700 sh: machvec: Use char[] for section boundaries [ Upstream commit c5783af354688b24abd359f7086c282ec74de993 ] As done for other sections, define the extern as a character array, which relaxes many of the compiler-time object size checks, which would otherwise assume it's a single long. Solves the following build error: arch/sh/kernel/machvec.c: error: array subscript 'struct sh_machine_vector[0]' is partly outside array bounds of 'long int[1]' [-Werror=array-bounds]: => 105:33 Cc: Yoshinori Sato Cc: Rich Felker Cc: linux-sh@vger.kernel.org Reported-by: Geert Uytterhoeven Link: https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2209050944290.964530@ramsan.of.borg/ Fixes: 9655ad03af2d ("sh: Fixup machvec support.") Reviewed-by: Geert Uytterhoeven Reviewed-by: Gustavo A. R. Silva Acked-by: Rich Felker Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 7c0258acaf71284a281a9470aad6d16defef7ec2 Author: Perry Yuan Date: Tue Aug 30 09:56:00 2022 +0800 cpufreq: amd-pstate: Fix initial highest_perf value [ Upstream commit bedadcfb011fef55273bd686e8893fdd8911dcdb ] To avoid some new AMD processors use wrong highest perf when amd pstate driver loaded, this fix will query the highest perf from MSR register MSR_AMD_CPPC_CAP1 and cppc_acpi interface firstly, then compare with the highest perf value got by calling amd_get_highest_perf() function. The lower value will be the correct highest perf we need to use. Otherwise the CPU max MHz will be incorrect if the amd_get_highest_perf() did not cover the new process family and model ID. Like this lscpu info, the max frequency is incorrect. Vendor ID: AuthenticAMD Socket(s): 1 Stepping: 2 CPU max MHz: 5410.0000 CPU min MHz: 400.0000 BogoMIPS: 5600.54 Fixes: 3743d55b289c2 (x86, sched: Fix the AMD CPPC maximum performance value on certain AMD Ryzen generations) Acked-by: Huang Rui Signed-off-by: Perry Yuan Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 7750f52ce090eb27db1c8aefcfce1bef9f6256ab Author: Xuewen Yan Date: Thu Aug 25 19:40:17 2022 +0800 thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register() [ Upstream commit cff895277c8558221ba180aefe26799dcb4eec86 ] Since the policy needs to be accessed first when obtaining cpu devices, first check whether the policy is legal before this. Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits") Signed-off-by: Xuewen Yan Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit db4de8bb61713bd3198705cb67c085f56f50ab2f Author: Christian Brauner Date: Mon Aug 29 14:38:40 2022 +0200 ntfs3: rework xattr handlers and switch to POSIX ACL VFS helpers [ Upstream commit a26aa12384158116c0d80d50e0bdc7b3323551e2 ] The xattr code in ntfs3 is currently a bit confused. For example, it defines a POSIX ACL i_op->set_acl() method but instead of relying on the generic POSIX ACL VFS helpers it defines its own set of xattr helpers with the consequence that i_op->set_acl() is currently dead code. Switch ntfs3 to rely on the VFS POSIX ACL xattr handlers. Also remove i_op->{g,s}et_acl() methods from symlink inode operations. Symlinks don't support xattrs. This is a preliminary change for the following patches which move handling idmapped mounts directly in posix_acl_xattr_set(). This survives POSIX ACL xfstests. Fixes: be71b5cba2e6 ("fs/ntfs3: Add attrib operations") Signed-off-by: Christian Brauner (Microsoft) Reviewed-by: Seth Forshee (DigitalOcean) > Signed-off-by: Sasha Levin commit e5a37972ab868ab201772139d7e913cd01746970 Author: Ondrej Mosnacek Date: Fri Jul 8 11:34:51 2022 +0200 userfaultfd: open userfaultfds with O_RDONLY [ Upstream commit abec3d015fdfb7c63105c7e1c956188bf381aa55 ] Since userfaultfd doesn't implement a write operation, it is more appropriate to open it read-only. When userfaultfds are opened read-write like it is now, and such fd is passed from one process to another, SELinux will check both read and write permissions for the target process, even though it can't actually do any write operation on the fd later. Inspired by the following bug report, which has hit the SELinux scenario described above: https://bugzilla.redhat.com/show_bug.cgi?id=1974559 Reported-by: Robert O'Callahan Fixes: 86039bd3b4e6 ("userfaultfd: add new syscall to provide memory externalization") Signed-off-by: Ondrej Mosnacek Acked-by: Peter Xu Acked-by: Christian Brauner (Microsoft) Signed-off-by: Paul Moore Signed-off-by: Sasha Levin commit 5e6f29a2ed378753f2f9a5210e7ef8bdaf6830ef Author: Mimi Zohar Date: Wed Aug 17 17:18:42 2022 -0400 ima: fix blocking of security.ima xattrs of unsupported algorithms [ Upstream commit 5926586f291b53cb8a0c9631fc19489be1186e2d ] Limit validating the hash algorithm to just security.ima xattr, not the security.evm xattr or any of the protected EVM security xattrs, nor posix acls. Fixes: 50f742dd9147 ("IMA: block writes of the security.ima xattr with unsupported algorithms") Reported-by: Christian Brauner Acked-by: Christian Brauner (Microsoft) Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit a2db2328886f3a6b11bf75cfba6968e72d819cb1 Author: Greg Kroah-Hartman Date: Tue Sep 20 19:12:52 2022 +0200 selinux: use "grep -E" instead of "egrep" commit c969bb8dbaf2f3628927eae73e7c579a74cf1b6e upstream. The latest version of grep claims that egrep is now obsolete so the build now contains warnings that look like: egrep: warning: egrep is obsolescent; using grep -E fix this by using "grep -E" instead. Cc: Paul Moore Cc: Stephen Smalley Cc: Eric Paris Cc: selinux@vger.kernel.org Signed-off-by: Greg Kroah-Hartman [PM: tweak to remove vdso reference, cleanup subj line] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit d296b4fd4c159f21985537bd0f9cfcb21112e992 Author: Steve French Date: Fri Oct 14 18:50:20 2022 -0500 smb3: must initialize two ACL struct fields to zero commit f09bd695af3b8ab46fc24e5d6954a24104c38387 upstream. Coverity spotted that we were not initalizing Stbz1 and Stbz2 to zero in create_sd_buf. Addresses-Coverity: 1513848 ("Uninitialized scalar variable") Cc: Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4370ef79742030cb11ea7fa99f88e07b2b41a3b0 Author: Shirish S Date: Fri Oct 7 20:31:49 2022 +0530 drm/amd/display: explicitly disable psr_feature_enable appropriately commit 6094b9136ca9038b61e9c4b5d25cd5512ce50b34 upstream. [Why] If psr_feature_enable is set to true by default, it continues to be enabled for non capable links. [How] explicitly disable the feature on links that are not capable of the same. Fixes: 8c322309e48e9 ("drm/amd/display: Enable PSR") Signed-off-by: Shirish S Reviewed-by: Leo Li Reviewed-by: Mario Limonciello Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.15+ Signed-off-by: Greg Kroah-Hartman commit 6f377e9affd5a752f5f43cb0b64d81013cb10d01 Author: Yunxiang Li Date: Wed Sep 21 17:20:19 2022 -0400 drm/amd/display: Fix vblank refcount in vrr transition commit 8799c0be89ebb99a16098bdf618f49f817bef76a upstream. manage_dm_interrupts disable/enable vblank using drm_crtc_vblank_off/on which causes drm_crtc_vblank_get in vrr_transition to fail, and later when drm_crtc_vblank_put is called the refcount on vblank will be messed up. Therefore move the call to after manage_dm_interrupts. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1247 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1380 Tested-by: Daniel Wheeler Reviewed-by: Rodrigo Siqueira Signed-off-by: Yunxiang Li Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit df4d55302ee30c00eed25454cce286cef378b538 Author: Ville Syrjälä Date: Mon Oct 3 14:15:43 2022 +0300 drm/i915: Fix watermark calculations for DG2 CCS+CC modifier commit b2e3a1af8cce4117de06ff1a4eab0749753ede27 upstream. Take the DG2 CCS+CC modifier into account when calculating the watermarks. Othwerwise we'll calculate the watermarks thinking this tile-4 modifier is linear. The rc_surface part is actually a nop since that is not used for any glk+ platform. Cc: stable@vger.kernel.org Fixes: 680025dcc400 ("drm/i915/dg2: Add support for DG2 clear color compression") Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221003111544.8007-6-ville.syrjala@linux.intel.com (cherry picked from commit 334810f82024815283a6e7febd3d2de1fed6c232) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 27bb1962725e78f1c38953169f54de42ff421f04 Author: Ville Syrjälä Date: Mon Oct 3 14:15:42 2022 +0300 drm/i915: Fix watermark calculations for DG2 CCS modifiers commit ccfa6d35f9233702c924316cdf40c05b6ce88113 upstream. Take the DG2 CCS modifiers into account when calculating the watermarks. Othwerwise we'll calculate the watermarks thinking these tile-4 modifiers are linear. The rc_surface part is actually a nop since that is not used for any glk+ platform. Cc: stable@vger.kernel.org Fixes: 4c3afa72138c ("drm/i915/dg2: Add support for DG2 render and media compression") Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221003111544.8007-5-ville.syrjala@linux.intel.com (cherry picked from commit f25d9f81a8e09ace4f04106995550bae1f522143) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit cd82aaf05c50a4e1ab5debab17e6b5f37aa49c18 Author: Ville Syrjälä Date: Mon Oct 3 14:15:41 2022 +0300 drm/i915: Fix watermark calculations for gen12+ CCS+CC modifier commit 070a2855900de17b1e11a0dc35af9794e80f1a28 upstream. Take the gen12+ CCS+CC modifier into account when calculating the watermarks. Othwerwise we'll calculate the watermarks thinking this Y-tiled modifier is linear. The rc_surface part is actually a nop since that is not used for any glk+ platform. Cc: stable@vger.kernel.org Fixes: d1e2775e9b96 ("drm/i915/tgl: Add Clear Color support for TGL Render Decompression") Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221003111544.8007-4-ville.syrjala@linux.intel.com (cherry picked from commit a627455bbe50a111475d7a42beb58fa64bd96c83) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 66b0ea47534cfd7ec0fb0cf6fdf565ade4c343a7 Author: Ville Syrjälä Date: Mon Oct 3 14:15:40 2022 +0300 drm/i915: Fix watermark calculations for gen12+ MC CCS modifier commit 484b2b9281000274ef7c5cb0a9ebc5da6f5c281c upstream. Take the gen12+ MC CCS modifier into account when calculating the watermarks. Othwerwise we'll calculate the watermarks thinking this Y-tiled modifier is linear. The rc_surface part is actually a nop since that is not used for any glk+ platform. v2: Split RC CCS vs. MC CCS to separate patches Cc: stable@vger.kernel.org Fixes: 2dfbf9d2873a ("drm/i915/tgl: Gen-12 display can decompress surfaces compressed by the media engine") Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221003111544.8007-3-ville.syrjala@linux.intel.com (cherry picked from commit 91c9651425fe955b1387f3637607dda005f3f710) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit b6d0783eed8268c59f96970dbf913dd7af8ed647 Author: Ville Syrjälä Date: Mon Oct 3 14:15:39 2022 +0300 drm/i915: Fix watermark calculations for gen12+ RC CCS modifier commit c56453a00f19ccddee302f5f9fe96b80e0b47fd3 upstream. Take the gen12+ RC CCS modifier into account when calculating the watermarks. Othwerwise we'll calculate the watermarks thinking this Y-tiled modifier is linear. The rc_surface part is actually a nop since that is not used for any glk+ platform. v2: Split RC CCS vs. MC CCS to separate patches Cc: stable@vger.kernel.org Fixes: b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression") Reviewed-by: Juha-Pekka Heikkila Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221003111544.8007-2-ville.syrjala@linux.intel.com (cherry picked from commit a89a96a586114f67598c6391c75678b4dba5c2da) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit a2a457c8166dbc5945002ecfd868df204b2121c9 Author: Chris Wilson Date: Mon Sep 26 16:33:33 2022 +0100 drm/i915/gt: Use i915_vm_put on ppgtt_create error paths commit 20e377e7b2e7c327039f10db80ba5bcc1f6c882d upstream. Now that the scratch page and page directories have a reference back to the i915_address_space, we cannot do an immediate free of the ppgtt upon error as those buffer objects will perform a later i915_vm_put in their deferred frees. The downside is that by replacing the onion unwind along the error paths, the ppgtt cleanup must handle a partially constructed vm. This includes ensuring that the vm->cleanup is set prior to the error path. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6900 Signed-off-by: Chris Wilson Fixes: 4d8151ae5329 ("drm/i915: Don't free shared locks while shared") Cc: Thomas Hellström Cc: Matthew Auld Cc: # v5.14+ Reviewed-by: Matthew Auld Signed-off-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20220926153333.102195-1-matthew.auld@intel.com (cherry picked from commit c286558f58535cf97b717b946d6c96d774a09d17) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 3aeda2fe6517cc52663d4ce3588dd43f0d4124a7 Author: Jianglei Nie Date: Tue Jul 5 21:25:46 2022 +0800 drm/nouveau: fix a use-after-free in nouveau_gem_prime_import_sg_table() commit 540dfd188ea2940582841c1c220bd035a7db0e51 upstream. nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm will call nouveau_bo_del_ttm() and free the memory.Thus, when nouveau_bo_init() returns an error, the gem object has already been released. Then the call to nouveau_bo_ref() will use the freed "nvbo->bo" and lead to a use-after-free bug. We should delete the call to nouveau_bo_ref() to avoid the use-after-free. Signed-off-by: Jianglei Nie Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding Cc: # v5.4+ Link: https://patchwork.freedesktop.org/patch/msgid/20220705132546.2247677-1-niejianglei2021@163.com Signed-off-by: Greg Kroah-Hartman commit 6dd1b90e56df10d54640b11f718679ef84afce14 Author: Lyude Paul Date: Tue Aug 16 14:04:36 2022 -0400 drm/nouveau/kms/nv140-: Disable interlacing commit 8ba9249396bef37cb68be9e8dee7847f1737db9d upstream. As it turns out: while Nvidia does actually have interlacing knobs on their GPU still pretty much no current GPUs since Volta actually support it. Trying interlacing on these GPUs will result in NVDisplay being quite unhappy like so: nouveau 0000:1f:00.0: disp: chid 0 stat 00004802 reason 4 [INVALID_ARG] mthd 2008 data 00000001 code 00080000 nouveau 0000:1f:00.0: disp: chid 0 stat 10005080 reason 5 [INVALID_STATE] mthd 0200 data 00000001 code 00000001 So let's fix this by following the same behavior Nvidia's driver does and disable interlacing entirely. Signed-off-by: Lyude Paul Cc: stable@vger.kernel.org Reviewed-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20220816180436.156310-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit 5699afbff1fa2972722e863906c0320d55dd4d58 Author: Greg Kroah-Hartman Date: Fri Sep 2 16:37:15 2022 +0200 staging: greybus: audio_helper: remove unused and wrong debugfs usage commit d517cdeb904ddc0cbebcc959d43596426cac40b0 upstream. In the greybus audio_helper code, the debugfs file for the dapm has the potential to be removed and memory will be leaked. There is also the very real potential for this code to remove ALL debugfs entries from the system, and it seems like this is what will really happen if this code ever runs. This all is very wrong as the greybus audio driver did not create this debugfs file, the sound core did and controls the lifespan of it. So remove all of the debugfs logic from the audio_helper code as there's no way it could be correct. If this really is needed, it can come back with a fixup for the incorrect usage of the debugfs_lookup() call which is what caused this to be noticed at all. Cc: Johan Hovold Cc: Alex Elder Cc: Greg Kroah-Hartman Cc: stable Link: https://lore.kernel.org/r/20220902143715.320500-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit dd8cf031cf9f40a7e8e3fa74e66e51337156be79 Author: Sean Christopherson Date: Tue Aug 30 23:15:49 2022 +0000 KVM: VMX: Drop bits 31:16 when shoving exception error code into VMCS commit eba9799b5a6efe2993cf92529608e4aa8163d73b upstream. Deliberately truncate the exception error code when shoving it into the VMCS (VM-Entry field for vmcs01 and vmcs02, VM-Exit field for vmcs12). Intel CPUs are incapable of handling 32-bit error codes and will never generate an error code with bits 31:16, but userspace can provide an arbitrary error code via KVM_SET_VCPU_EVENTS. Failure to drop the bits on exception injection results in failed VM-Entry, as VMX disallows setting bits 31:16. Setting the bits on VM-Exit would at best confuse L1, and at worse induce a nested VM-Entry failure, e.g. if L1 decided to reinject the exception back into L2. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20220830231614.3580124-3-seanjc@google.com Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 9bf561c4db89879fe2e2b6d3dbabbc077dcbcaac Author: Sean Christopherson Date: Tue Aug 30 15:37:21 2022 +0200 KVM: nVMX: Don't propagate vmcs12's PERF_GLOBAL_CTRL settings to vmcs02 commit def9d705c05eab3fdedeb10ad67907513b12038e upstream. Don't propagate vmcs12's VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL to vmcs02. KVM doesn't disallow L1 from using VM_ENTRY_LOAD_IA32_PERF_GLOBAL_CTRL even when KVM itself doesn't use the control, e.g. due to the various CPU errata that where the MSR can be corrupted on VM-Exit. Preserve KVM's (vmcs01) setting to hopefully avoid having to toggle the bit in vmcs02 at a later point. E.g. if KVM is loading PERF_GLOBAL_CTRL when running L1, then odds are good KVM will also load the MSR when running L2. Fixes: 8bf00a529967 ("KVM: VMX: add support for switching of PERF_GLOBAL_CTRL") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Signed-off-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20220830133737.1539624-18-vkuznets@redhat.com Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit a0b4d7524abfdb2feb8c76381a201be3d253a3b3 Author: Sean Christopherson Date: Tue Aug 30 23:15:48 2022 +0000 KVM: nVMX: Unconditionally purge queued/injected events on nested "exit" commit d953540430c5af57f5de97ea9e36253908204027 upstream. Drop pending exceptions and events queued for re-injection when leaving nested guest mode, even if the "exit" is due to VM-Fail, SMI, or forced by host userspace. Failure to purge events could result in an event belonging to L2 being injected into L1. This _should_ never happen for VM-Fail as all events should be blocked by nested_run_pending, but it's possible if KVM, not the L1 hypervisor, is the source of VM-Fail when running vmcs02. SMI is a nop (barring unknown bugs) as recognition of SMI and thus entry to SMM is blocked by pending exceptions and re-injected events. Forced exit is definitely buggy, but has likely gone unnoticed because userspace probably follows the forced exit with KVM_SET_VCPU_EVENTS (or some other ioctl() that purges the queue). Fixes: 4f350c6dbcb9 ("kvm: nVMX: Handle deferred early VMLAUNCH/VMRESUME failure properly") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Reviewed-by: Jim Mattson Reviewed-by: Maxim Levitsky Link: https://lore.kernel.org/r/20220830231614.3580124-2-seanjc@google.com Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 7984c13868859c1e791a77e3915d0666e7c31392 Author: Michal Luczaj Date: Mon Aug 22 00:06:47 2022 +0200 KVM: x86/emulator: Fix handing of POP SS to correctly set interruptibility commit 6aa5c47c351b22c21205c87977c84809cd015fcf upstream. The emulator checks the wrong variable while setting the CPU interruptibility state, the target segment is embedded in the instruction opcode, not the ModR/M register. Fix the condition. Signed-off-by: Michal Luczaj Fixes: a5457e7bcf9a ("KVM: emulate: POP SS triggers a MOV SS shadow too") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/all/20220821215900.1419215-1-mhal@rbox.co Signed-off-by: Sean Christopherson Signed-off-by: Greg Kroah-Hartman commit dd54b94e72d0cb307dfec677518ac33f6a8ea483 Author: Yu Kuai Date: Tue Sep 13 18:57:49 2022 +0800 blk-wbt: call rq_qos_add() after wb_normal is initialized commit 8c5035dfbb9475b67c82b3fdb7351236525bf52b upstream. Our test found a problem that wbt inflight counter is negative, which will cause io hang(noted that this problem doesn't exist in mainline): t1: device create t2: issue io add_disk blk_register_queue wbt_enable_default wbt_init rq_qos_add // wb_normal is still 0 /* * in mainline, disk can't be opened before * bdev_add(), however, in old kernels, disk * can be opened before blk_register_queue(). */ blkdev_issue_flush // disk size is 0, however, it's not checked submit_bio_wait submit_bio blk_mq_submit_bio rq_qos_throttle wbt_wait bio_to_wbt_flags rwb_enabled // wb_normal is 0, inflight is not increased wbt_queue_depth_changed(&rwb->rqos); wbt_update_limits // wb_normal is initialized rq_qos_track wbt_track rq->wbt_flags |= bio_to_wbt_flags(rwb, bio); // wb_normal is not 0，wbt_flags will be set t3: io completion blk_mq_free_request rq_qos_done wbt_done wbt_is_tracked // return true __wbt_done wbt_rqw_done atomic_dec_return(&rqw->inflight); // inflight is decreased commit 8235b5c1e8c1 ("block: call bdev_add later in device_add_disk") can avoid this problem, however it's better to fix this problem in wbt: 1) Lower kernel can't backport this patch due to lots of refactor. 2) Root cause is that wbt call rq_qos_add() before wb_normal is initialized. Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism") Cc: Signed-off-by: Yu Kuai Link: https://lore.kernel.org/r/20220913105749.3086243-1-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8b1f9fde48aa8cc3f1c73356be40f9b15fe6d1ee Author: Yu Kuai Date: Mon Aug 29 10:22:37 2022 +0800 blk-throttle: fix that io throttle can only work for single bio commit 320fb0f91e55ba248d4bad106b408e59099cfa89 upstream. Test scripts: cd /sys/fs/cgroup/blkio/ echo "8:0 1024" > blkio.throttle.write_bps_device echo $$ > cgroup.procs dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct & dd if=/dev/zero of=/dev/sda bs=10k count=1 oflag=direct & Test result: 10240 bytes (10 kB, 10 KiB) copied, 10.0134 s, 1.0 kB/s 10240 bytes (10 kB, 10 KiB) copied, 10.0135 s, 1.0 kB/s The problem is that the second bio is finished after 10s instead of 20s. Root cause: 1) second bio will be flagged: __blk_throtl_bio while (true) { ... if (sq->nr_queued[rw]) -> some bio is throttled already break }; bio_set_flag(bio, BIO_THROTTLED); -> flag the bio 2) flagged bio will be dispatched without waiting: throtl_dispatch_tg tg_may_dispatch tg_with_in_bps_limit if (bps_limit == U64_MAX || bio_flagged(bio, BIO_THROTTLED)) *wait = 0; -> wait time is zero return true; commit 9f5ede3c01f9 ("block: throttle split bio in case of iops limit") support to count split bios for iops limit, thus it adds flagged bio checking in tg_with_in_bps_limit() so that split bios will only count once for bps limit, however, it introduce a new problem that io throttle won't work if multiple bios are throttled. In order to fix the problem, handle iops/bps limit in different ways: 1) for iops limit, there is no flag to record if the bio is throttled, and iops is always applied. 2) for bps limit, original bio will be flagged with BIO_BPS_THROTTLED, and io throttle will ignore bio with the flag. Noted this patch also remove the code to set flag in __bio_clone(), it's introduced in commit 111be8839817 ("block-throttle: avoid double charge"), and author thinks split bio can be resubmited and throttled again, which is wrong because split bio will continue to dispatch from caller. Fixes: 9f5ede3c01f9 ("block: throttle split bio in case of iops limit") Cc: Signed-off-by: Yu Kuai Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20220829022240.3348319-2-yukuai1@huaweicloud.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1e5c75634e3eed3c7a56cfaca6ba85e864258365 Author: Dmitry Osipenko Date: Thu Aug 18 22:33:08 2022 +0200 media: cedrus: Fix endless loop in cedrus_h265_skip_bits() commit 91db7a3fc7fe670cf1770a398a43bb4a1f776bf1 upstream. The busy status bit may never de-assert if number of programmed skip bits is incorrect, resulting in a kernel hang because the bit is polled endlessly in the code. Fix it by adding timeout for the bit-polling. This problem is reproducible by setting the data_bit_offset field of the HEVC slice params to a wrong value by userspace. Cc: stable@vger.kernel.org Fixes: 7678c5462680 (media: cedrus: Fix decoding for some HEVC videos) Reported-by: Nicolas Dufresne Signed-off-by: Dmitry Osipenko Signed-off-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit c3977e0bcb4b835a23e5f2fba7ead23e02306dd3 Author: Dmitry Osipenko Date: Thu Aug 18 22:33:07 2022 +0200 media: cedrus: Set the platform driver data earlier commit 708938f8495147fe2e77a9a3e1015d8e6899323e upstream. The cedrus_hw_resume() crashes with NULL deference on driver probe if runtime PM is disabled because it uses platform data that hasn't been set up yet. Fix this by setting the platform data earlier during probe. Cc: stable@vger.kernel.org Fixes: 50e761516f2b (media: platform: Add Cedrus VPU decoder driver) Signed-off-by: Dmitry Osipenko Signed-off-by: Nicolas Dufresne Reviewed-by: Samuel Holland Acked-by: Paul Kocialkowski Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit b2c57e92747069c21474160b3594f4008e31127c Author: Ard Biesheuvel Date: Thu Sep 15 19:00:24 2022 +0200 efi: libstub: drop pointless get_memory_map() call commit d80ca810f096ff66f451e7a3ed2f0cd9ef1ff519 upstream. Currently, the non-x86 stub code calls get_memory_map() redundantly, given that the data it returns is never used anywhere. So drop the call. Cc: # v4.14+ Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size") Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit f897e1ce696a6ef43a058152833a33954bbe0def Author: Mario Limonciello Date: Mon Sep 26 09:33:50 2022 -0500 thunderbolt: Explicitly enable lane adapter hotplug events at startup commit 5d2569cb4a65c373896ec0217febdf88739ed295 upstream. Software that has run before the USB4 CM in Linux runs may have disabled hotplug events for a given lane adapter. Other CMs such as that one distributed with Windows 11 will enable hotplug events. Do the same thing in the Linux CM which fixes hotplug events on "AMD Pink Sardine". Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello Signed-off-by: Mika Westerberg Signed-off-by: Greg Kroah-Hartman commit ef828a39d6a7028836eaf37df3ad568c8c2dd6f9 Author: Shengjiu Wang Date: Wed Sep 21 09:58:43 2022 +0800 rpmsg: char: Avoid double destroy of default endpoint commit 467233a4ac29b215d492843d067a9f091e6bf0c5 upstream. The rpmsg_dev_remove() in rpmsg_core is the place for releasing this default endpoint. So need to avoid destroying the default endpoint in rpmsg_chrdev_eptdev_destroy(), this should be the same as rpmsg_eptdev_release(). Otherwise there will be double destroy issue that ept->refcount report warning: refcount_t: underflow; use-after-free. Call trace: refcount_warn_saturate+0xf8/0x150 virtio_rpmsg_destroy_ept+0xd4/0xec rpmsg_dev_remove+0x60/0x70 The issue can be reproduced by stopping remoteproc before closing the /dev/rpmsgX. Fixes: bea9b79c2d10 ("rpmsg: char: Add possibility to use default endpoint of the rpmsg device") Signed-off-by: Shengjiu Wang Reviewed-by: Arnaud Pouliquen Reviewed-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/1663725523-6514-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 149198d0b884e4606ed1d29b330c70016d878276 Author: Steven Rostedt (Google) Date: Wed Oct 12 06:40:58 2022 -0400 tracing: Fix reading strings from synthetic events commit 0934ae9977c27133449b6dd8c6213970e7eece38 upstream. The follow commands caused a crash: # cd /sys/kernel/tracing # echo 's:open char file[]' > dynamic_events # echo 'hist:keys=common_pid:file=filename:onchange($file).trace(open,$file)' > events/syscalls/sys_enter_openat/trigger' # echo 1 > events/synthetic/open/enable BOOM! The problem is that the synthetic event field "char file[]" will read the value given to it as a string without any memory checks to make sure the address is valid. The above example will pass in the user space address and the sythetic event code will happily call strlen() on it and then strscpy() where either one will cause an oops when accessing user space addresses. Use the helper functions from trace_kprobe and trace_eprobe that can read strings safely (and actually succeed when the address is from user space and the memory is mapped in). Now the above can show: packagekitd-1721 [000] ...2. 104.597170: open: file=/usr/lib/rpm/fileattrs/cmake.attr in:imjournal-978 [006] ...2. 104.599642: open: file=/var/lib/rsyslog/imjournal.state.tmp packagekitd-1721 [000] ...2. 104.626308: open: file=/usr/lib/rpm/fileattrs/debuginfo.attr Link: https://lkml.kernel.org/r/20221012104534.826549315@goodmis.org Cc: stable@vger.kernel.org Cc: Andrew Morton Cc: Tom Zanussi Acked-by: Masami Hiramatsu (Google) Reviewed-by: Tom Zanussi Fixes: bd82631d7ccdc ("tracing: Add support for dynamic strings to synthetic events") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 966ffabf69904659c8d3ad2a0575b4e61e56a48a Author: Steven Rostedt (Google) Date: Wed Oct 12 06:40:57 2022 -0400 tracing: Add "(fault)" name injection to kernel probes commit 2e9906f84fc7c99388bb7123ade167250d50f1c0 upstream. Have the specific functions for kernel probes that read strings to inject the "(fault)" name directly. trace_probes.c does this too (for uprobes) but as the code to read strings are going to be used by synthetic events (and perhaps other utilities), it simplifies the code by making sure those other uses do not need to implement the "(fault)" name injection as well. Link: https://lkml.kernel.org/r/20221012104534.644803645@goodmis.org Cc: stable@vger.kernel.org Cc: Andrew Morton Cc: Tom Zanussi Acked-by: Masami Hiramatsu (Google) Reviewed-by: Tom Zanussi Fixes: bd82631d7ccdc ("tracing: Add support for dynamic strings to synthetic events") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 860e8fbde4233606f016cee043ca49a1c3b51b64 Author: Steven Rostedt (Google) Date: Wed Oct 12 06:40:56 2022 -0400 tracing: Move duplicate code of trace_kprobe/eprobe.c into header commit f1d3cbfaafc10464550c6d3a125f4fc802bbaed5 upstream. The functions: fetch_store_strlen_user() fetch_store_strlen() fetch_store_string_user() fetch_store_string() are identical in both trace_kprobe.c and trace_eprobe.c. Move them into a new header file trace_probe_kernel.h to share it. This code will later be used by the synthetic events as well. Marked for stable as a fix for a crash in synthetic events requires it. Link: https://lkml.kernel.org/r/20221012104534.467668078@goodmis.org Cc: stable@vger.kernel.org Cc: Andrew Morton Cc: Tom Zanussi Acked-by: Masami Hiramatsu (Google) Reviewed-by: Tom Zanussi Fixes: bd82631d7ccdc ("tracing: Add support for dynamic strings to synthetic events") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 2fcd9e27640f10b5f11a8a9644fc4a042d07703a Author: Steven Rostedt (Google) Date: Wed Oct 5 11:37:57 2022 -0400 tracing: Do not free snapshot if tracer is on cmdline commit a541a9559bb0a8ecc434de01d3e4826c32e8bb53 upstream. The ftrace_boot_snapshot and alloc_snapshot cmdline options allocate the snapshot buffer at boot up for use later. The ftrace_boot_snapshot in particular requires the snapshot to be allocated because it will take a snapshot at the end of boot up allowing to see the traces that happened during boot so that it's not lost when user space takes over. When a tracer is registered (started) there's a path that checks if it requires the snapshot buffer or not, and if it does not and it was allocated it will do a synchronization and free the snapshot buffer. This is only required if the previous tracer was using it for "max latency" snapshots, as it needs to make sure all max snapshots are complete before freeing. But this is only needed if the previous tracer was using the snapshot buffer for latency (like irqoff tracer and friends). But it does not make sense to free it, if the previous tracer was not using it, and the snapshot was allocated by the cmdline parameters. This basically takes away the point of allocating it in the first place! Note, the allocated snapshot worked fine for just trace events, but fails when a tracer is enabled on the cmdline. Further investigation, this goes back even further and it does not require a tracer on the cmdline to fail. Simply enable snapshots and then enable a tracer, and it will remove the snapshot. Link: https://lkml.kernel.org/r/20221005113757.041df7fe@gandalf.local.home Cc: Masami Hiramatsu Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: 45ad21ca5530 ("tracing: Have trace_array keep track if snapshot buffer is allocated") Reported-by: Ross Zwisler Tested-by: Ross Zwisler Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 864f10063efc575308b6d1705aa7ed2d38fe8a9d Author: Steven Rostedt (Google) Date: Thu Sep 29 09:50:29 2022 -0400 tracing: Add ioctl() to force ring buffer waiters to wake up commit 01b2a52171735c6eea80ee2f355f32bea6c41418 upstream. If a process is waiting on the ring buffer for data, there currently isn't a clean way to force it to wake up. Add an ioctl call that will force any tasks that are waiting on the trace_pipe_raw file to wake up. Link: https://lkml.kernel.org/r/20220929095029.117f913f@gandalf.local.home Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Andrew Morton Fixes: e30f53aad2202 ("tracing: Do not busy wait in buffer splice") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit e91ef98eeefd3fba95d9846aeb8d70b6cb96cd83 Author: Steven Rostedt (Google) Date: Wed Sep 28 18:22:20 2022 -0400 tracing: Wake up waiters when tracing is disabled commit 2b0fd9a59b7990c161fa1cb7b79edb22847c87c2 upstream. When tracing is disabled, there's no reason that waiters should stay waiting, wake them up, otherwise tasks get stuck when they should be flushing the buffers. Cc: stable@vger.kernel.org Fixes: e30f53aad2202 ("tracing: Do not busy wait in buffer splice") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 5544f411a4e8bc39e6a444badbac37dd0e0caf0a Author: Steven Rostedt (Google) Date: Tue Sep 27 19:15:27 2022 -0400 tracing: Wake up ring buffer waiters on closing of the file commit f3ddb74ad0790030c9592229fb14d8c451f4e9a8 upstream. When the file that represents the ring buffer is closed, there may be waiters waiting on more input from the ring buffer. Call ring_buffer_wake_waiters() to wake up any waiters when the file is closed. Link: https://lkml.kernel.org/r/20220927231825.182416969@goodmis.org Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Andrew Morton Fixes: e30f53aad2202 ("tracing: Do not busy wait in buffer splice") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 220d170455aa849ad0c45e5190dfe4698c167502 Author: Waiman Long Date: Thu Sep 22 10:56:22 2022 -0400 tracing: Disable interrupt or preemption before acquiring arch_spinlock_t commit c0a581d7126c0bbc96163276f585fd7b4e4d8d0e upstream. It was found that some tracing functions in kernel/trace/trace.c acquire an arch_spinlock_t with preemption and irqs enabled. An example is the tracing_saved_cmdlines_size_read() function which intermittently causes a "BUG: using smp_processor_id() in preemptible" warning when the LTP read_all_proc test is run. That can be problematic in case preemption happens after acquiring the lock. Add the necessary preemption or interrupt disabling code in the appropriate places before acquiring an arch_spinlock_t. The convention here is to disable preemption for trace_cmdline_lock and interupt for max_lock. Link: https://lkml.kernel.org/r/20220922145622.1744826-1-longman@redhat.com Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Will Deacon Cc: Boqun Feng Cc: stable@vger.kernel.org Fixes: a35873a0993b ("tracing: Add conditional snapshot") Fixes: 939c7a4f04fc ("tracing: Introduce saved_cmdlines_size file") Suggested-by: Steven Rostedt Signed-off-by: Waiman Long Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit ceb52ccfb01dede8f2e462b985fd7e2b259fa85d Author: Steven Rostedt (Google) Date: Thu Sep 29 10:49:09 2022 -0400 ring-buffer: Fix race between reset page and reading page commit a0fcaaed0c46cf9399d3a2d6e0c87ddb3df0e044 upstream. The ring buffer is broken up into sub buffers (currently of page size). Each sub buffer has a pointer to its "tail" (the last event written to the sub buffer). When a new event is requested, the tail is locally incremented to cover the size of the new event. This is done in a way that there is no need for locking. If the tail goes past the end of the sub buffer, the process of moving to the next sub buffer takes place. After setting the current sub buffer to the next one, the previous one that had the tail go passed the end of the sub buffer needs to be reset back to the original tail location (before the new event was requested) and the rest of the sub buffer needs to be "padded". The race happens when a reader takes control of the sub buffer. As readers do a "swap" of sub buffers from the ring buffer to get exclusive access to the sub buffer, it replaces the "head" sub buffer with an empty sub buffer that goes back into the writable portion of the ring buffer. This swap can happen as soon as the writer moves to the next sub buffer and before it updates the last sub buffer with padding. Because the sub buffer can be released to the reader while the writer is still updating the padding, it is possible for the reader to see the event that goes past the end of the sub buffer. This can cause obvious issues. To fix this, add a few memory barriers so that the reader definitely sees the updates to the sub buffer, and also waits until the writer has put back the "tail" of the sub buffer back to the last event that was written on it. To be paranoid, it will only spin for 1 second, otherwise it will warn and shutdown the ring buffer code. 1 second should be enough as the writer does have preemption disabled. If the writer doesn't move within 1 second (with preemption disabled) something is horribly wrong. No interrupt should last 1 second! Link: https://lore.kernel.org/all/20220830120854.7545-1-jiazi.li@transsion.com/ Link: https://bugzilla.kernel.org/show_bug.cgi?id=216369 Link: https://lkml.kernel.org/r/20220929104909.0650a36c@gandalf.local.home Cc: Ingo Molnar Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: c7b0930857e22 ("ring-buffer: prevent adding write in discarded area") Reported-by: Jiazi.Li Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit f026e18300d8a179e33a6cf1f0f13eef85389e2f Author: Steven Rostedt (Google) Date: Wed Sep 28 13:39:38 2022 -0400 ring-buffer: Add ring_buffer_wake_waiters() commit 7e9fbbb1b776d8d7969551565bc246f74ec53b27 upstream. On closing of a file that represents a ring buffer or flushing the file, there may be waiters on the ring buffer that needs to be woken up and exit the ring_buffer_wait() function. Add ring_buffer_wake_waiters() to wake up the waiters on the ring buffer and allow them to exit the wait loop. Link: https://lkml.kernel.org/r/20220928133938.28dc2c27@gandalf.local.home Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Andrew Morton Fixes: 15693458c4bc0 ("tracing/ring-buffer: Move poll wake ups into ring buffer code") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 79f3d1facbdb97a254fd49945bfbb1dd905ed558 Author: Steven Rostedt (Google) Date: Tue Sep 27 19:15:25 2022 -0400 ring-buffer: Check pending waiters when doing wake ups as well commit ec0bbc5ec5664dcee344f79373852117dc672c86 upstream. The wake up waiters only checks the "wakeup_full" variable and not the "full_waiters_pending". The full_waiters_pending is set when a waiter is added to the wait queue. The wakeup_full is only set when an event is triggered, and it clears the full_waiters_pending to avoid multiple calls to irq_work_queue(). The irq_work callback really needs to check both wakeup_full as well as full_waiters_pending such that this code can be used to wake up waiters when a file is closed that represents the ring buffer and the waiters need to be woken up. Link: https://lkml.kernel.org/r/20220927231824.209460321@goodmis.org Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Andrew Morton Fixes: 15693458c4bc0 ("tracing/ring-buffer: Move poll wake ups into ring buffer code") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 51a51a1a715276496d211817bccc08476e62b45b Author: Steven Rostedt (Google) Date: Tue Sep 27 19:15:24 2022 -0400 ring-buffer: Have the shortest_full queue be the shortest not longest commit 3b19d614b61b93a131f463817e08219c9ce1fee3 upstream. The logic to know when the shortest waiters on the ring buffer should be woken up or not has uses a less than instead of a greater than compare, which causes the shortest_full to actually be the longest. Link: https://lkml.kernel.org/r/20220927231823.718039222@goodmis.org Cc: stable@vger.kernel.org Cc: Ingo Molnar Cc: Andrew Morton Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 0a2fe268e8f67bcb763354fd536bf967e3243245 Author: Steven Rostedt (Google) Date: Tue Sep 27 14:43:17 2022 -0400 ring-buffer: Allow splice to read previous partially read pages commit fa8f4a89736b654125fb254b0db753ac68a5fced upstream. If a page is partially read, and then the splice system call is run against the ring buffer, it will always fail to read, no matter how much is in the ring buffer. That's because the code path for a partial read of the page does will fail if the "full" flag is set. The splice system call wants full pages, so if the read of the ring buffer is not yet full, it should return zero, and the splice will block. But if a previous read was done, where the beginning has been consumed, it should still be given to the splice caller if the rest of the page has been written to. This caused the splice command to never consume data in this scenario, and let the ring buffer just fill up and lose events. Link: https://lkml.kernel.org/r/20220927144317.46be6b80@gandalf.local.home Cc: stable@vger.kernel.org Fixes: 8789a9e7df6bf ("ring-buffer: read page interface") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 0abc3bb1706b8e4c07204510959144766a5f9eee Author: Steven Rostedt (Google) Date: Wed Oct 5 00:38:09 2022 -0400 ftrace: Still disable enabled records marked as disabled commit cf04f2d5df0037741207382ac8fe289e8bf84ced upstream. Weak functions started causing havoc as they showed up in the "available_filter_functions" and this confused people as to why some functions marked as "notrace" were listed, but when enabled they did nothing. This was because weak functions can still have fentry calls, and these addresses get added to the "available_filter_functions" file. kallsyms is what converts those addresses to names, and since the weak functions are not listed in kallsyms, it would just pick the function before that. To solve this, there was a trick to detect weak functions listed, and these records would be marked as DISABLED so that they do not get enabled and are mostly ignored. As the processing of the list of all functions to figure out what is weak or not can take a long time, this process is put off into a kernel thread and run in parallel with the rest of start up. Now the issue happens whet function tracing is enabled via the kernel command line. As it starts very early in boot up, it can be enabled before the records that are weak are marked to be disabled. This causes an issue in the accounting, as the weak records are enabled by the command line function tracing, but after boot up, they are not disabled. The ftrace records have several accounting flags and a ref count. The DISABLED flag is just one. If the record is enabled before it is marked DISABLED it will get an ENABLED flag and also have its ref counter incremented. After it is marked for DISABLED, neither the ENABLED flag nor the ref counter is cleared. There's sanity checks on the records that are performed after an ftrace function is registered or unregistered, and this detected that there were records marked as ENABLED with ref counter that should not have been. Note, the module loading code uses the DISABLED flag as well to keep its functions from being modified while its being loaded and some of these flags may get set in this process. So changing the verification code to ignore DISABLED records is a no go, as it still needs to verify that the module records are working too. Also, the weak functions still are calling a trampoline. Even though they should never be called, it is dangerous to leave these weak functions calling a trampoline that is freed, so they should still be set back to nops. There's two places that need to not skip records that have the ENABLED and the DISABLED flags set. That is where the ftrace_ops is processed and sets the records ref counts, and then later when the function itself is to be updated, and the ENABLED flag gets removed. Add a helper function "skip_record()" that returns true if the record has the DISABLED flag set but not the ENABLED flag. Link: https://lkml.kernel.org/r/20221005003809.27d2b97b@gandalf.local.home Cc: Masami Hiramatsu Cc: Andrew Morton Cc: stable@vger.kernel.org Fixes: b39181f7c6907 ("ftrace: Add FTRACE_MCOUNT_MAX_OFFSET to avoid adding weak function") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 8f81aee36ba1ed2697b022b3c6c1cd57e9ead274 Author: Zheng Yejian Date: Mon Sep 26 15:20:08 2022 +0000 ftrace: Properly unset FTRACE_HASH_FL_MOD commit 0ce0638edf5ec83343302b884fa208179580700a upstream. When executing following commands like what document said, but the log "#### all functions enabled ####" was not shown as expect: 1. Set a 'mod' filter: $ echo 'write*:mod:ext3' > /sys/kernel/tracing/set_ftrace_filter 2. Invert above filter: $ echo '!write*:mod:ext3' >> /sys/kernel/tracing/set_ftrace_filter 3. Read the file: $ cat /sys/kernel/tracing/set_ftrace_filter By some debugging, I found that flag FTRACE_HASH_FL_MOD was not unset after inversion like above step 2 and then result of ftrace_hash_empty() is incorrect. Link: https://lkml.kernel.org/r/20220926152008.2239274-1-zhengyejian1@huawei.com Cc: Cc: stable@vger.kernel.org Fixes: 8c08f0d5c6fb ("ftrace: Have cached module filters be an active filter") Signed-off-by: Zheng Yejian Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit ebf0beb855e202a824c0b074d529400eac90879d Author: Rik van Riel Date: Mon Aug 8 15:00:19 2022 -0400 livepatch: fix race between fork and KLP transition commit 747f7a2901174c9afa805dddfb7b24db6f65e985 upstream. The KLP transition code depends on the TIF_PATCH_PENDING and the task->patch_state to stay in sync. On a normal (forward) transition, TIF_PATCH_PENDING will be set on every task in the system, while on a reverse transition (after a failed forward one) first TIF_PATCH_PENDING will be cleared from every task, followed by it being set on tasks that need to be transitioned back to the original code. However, the fork code copies over the TIF_PATCH_PENDING flag from the parent to the child early on, in dup_task_struct and setup_thread_stack. Much later, klp_copy_process will set child->patch_state to match that of the parent. However, the parent's patch_state may have been changed by KLP loading or unloading since it was initially copied over into the child. This results in the KLP code occasionally hitting this warning in klp_complete_transition: for_each_process_thread(g, task) { WARN_ON_ONCE(test_tsk_thread_flag(task, TIF_PATCH_PENDING)); task->patch_state = KLP_UNDEFINED; } Set, or clear, the TIF_PATCH_PENDING flag in the child task depending on whether or not it is needed at the time klp_copy_process is called, at a point in copy_process where the tasklist_lock is held exclusively, preventing races with the KLP code. The KLP code does have a few places where the state is changed without the tasklist_lock held, but those should not cause problems because klp_update_patch_state(current) cannot be called while the current task is in the middle of fork, klp_check_and_switch_task() which is called under the pi_lock, which prevents rescheduling, and manipulation of the patch state of idle tasks, which do not fork. This should prevent this warning from triggering again in the future, and close the race for both normal and reverse transitions. Signed-off-by: Rik van Riel Reported-by: Breno Leitao Reviewed-by: Petr Mladek Acked-by: Josh Poimboeuf Fixes: d83a7cb375ee ("livepatch: change to a per-task consistency model") Cc: stable@kernel.org Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20220808150019.03d6a67b@imladris.surriel.com Signed-off-by: Greg Kroah-Hartman commit caf34de4951d7c624a6eef6d41ff2436bf27ba1b Author: Ye Bin Date: Wed Sep 21 14:40:40 2022 +0800 ext4: update 'state->fc_regions_size' after successful memory allocation commit 27cd49780381c6ccbf248798e5e8fd076200ffba upstream. To avoid to 'state->fc_regions_size' mismatch with 'state->fc_regions' when fail to reallocate 'fc_reqions',only update 'state->fc_regions_size' after 'state->fc_regions' is allocated successfully. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220921064040.3693255-4-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a4058b869e6c5e517c79e30532a350d0f3115c3e Author: Ye Bin Date: Wed Sep 21 14:40:39 2022 +0800 ext4: fix potential memory leak in ext4_fc_record_regions() commit 7069d105c1f15c442b68af43f7fde784f3126739 upstream. As krealloc may return NULL, in this case 'state->fc_regions' may not be freed by krealloc, but 'state->fc_regions' already set NULL. Then will lead to 'state->fc_regions' memory leak. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220921064040.3693255-3-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c0be17635f039f864b1108efec0015c73736e414 Author: Ye Bin Date: Wed Sep 21 14:40:38 2022 +0800 ext4: fix potential memory leak in ext4_fc_record_modified_inode() commit 9305721a309fa1bd7c194e0d4a2335bf3b29dca4 upstream. As krealloc may return NULL, in this case 'state->fc_modified_inodes' may not be freed by krealloc, but 'state->fc_modified_inodes' already set NULL. Then will lead to 'state->fc_modified_inodes' memory leak. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220921064040.3693255-2-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit a4a8c7e51ec2751eeaed1fc940275c8c30e13dc7 Author: Ye Bin Date: Wed Sep 14 18:08:59 2022 +0800 ext4: fix miss release buffer head in ext4_fc_write_inode commit ccbf8eeb39f2ff00b54726a2b20b35d788c4ecb5 upstream. In 'ext4_fc_write_inode' function first call 'ext4_get_inode_loc' get 'iloc', after use it miss release 'iloc.bh'. So just release 'iloc.bh' before 'ext4_fc_write_inode' return. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220914100859.1415196-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 2bf6f14e9ddca39877d262dd8730001658866adc Author: Zhihao Cheng Date: Sun Sep 11 12:52:04 2022 +0800 ext4: fix dir corruption when ext4_dx_add_entry() fails commit 7177dd009c7c04290891e9a534cd47d1b620bd04 upstream. Following process may lead to fs corruption: 1. ext4_create(dir/foo) ext4_add_nondir ext4_add_entry ext4_dx_add_entry a. add_dirent_to_buf ext4_mark_inode_dirty ext4_handle_dirty_metadata // dir inode bh is recorded into journal b. ext4_append // dx_get_count(entries) == dx_get_limit(entries) ext4_bread(EXT4_GET_BLOCKS_CREATE) ext4_getblk ext4_map_blocks ext4_ext_map_blocks ext4_mb_new_blocks dquot_alloc_block dquot_alloc_space_nodirty inode_add_bytes // update dir's i_blocks ext4_ext_insert_extent ext4_ext_dirty // record extent bh into journal ext4_handle_dirty_metadata(bh) // record new block into journal inode->i_size += inode->i_sb->s_blocksize // new size(in mem) c. ext4_handle_dirty_dx_node(bh2) // record dir's new block(dx_node) into journal d. ext4_handle_dirty_dx_node((frame - 1)->bh) e. ext4_handle_dirty_dx_node(frame->bh) f. do_split // ret err! g. add_dirent_to_buf ext4_mark_inode_dirty(dir) // update raw_inode on disk(skipped) 2. fsck -a /dev/sdb drop last block(dx_node) which beyonds dir's i_size. /dev/sdb: recovering journal /dev/sdb contains a file system with errors, check forced. /dev/sdb: Inode 12, end of extent exceeds allowed value (logical block 128, physical block 3938, len 1) 3. fsck -fn /dev/sdb dx_node->entry[i].blk > dir->i_size Pass 2: Checking directory structure Problem in HTREE directory inode 12 (/dir): bad block number 128. Clear HTree index? no Problem in HTREE directory inode 12: block #3 has invalid depth (2) Problem in HTREE directory inode 12: block #3 has bad max hash Problem in HTREE directory inode 12: block #3 not referenced Fix it by marking inode dirty directly inside ext4_append(). Fetch a reproducer in [Link]. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216466 Cc: stable@vger.kernel.org Signed-off-by: Zhihao Cheng Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220911045204.516460-1-chengzhihao1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c2ddd16160de40a21e31a961b9e1df5036464461 Author: Jeff Layton Date: Thu Sep 8 13:24:42 2022 -0400 ext4: fix i_version handling in ext4 commit a642c2c0827f5604a93f9fa1e5701eecdce4ae22 upstream. ext4 currently updates the i_version counter when the atime is updated during a read. This is less than ideal as it can cause unnecessary cache invalidations with NFSv4 and unnecessary remeasurements for IMA. The increment in ext4_mark_iloc_dirty is also problematic since it can corrupt the i_version counter for ea_inodes. We aren't bumping the file times in ext4_mark_iloc_dirty, so changing the i_version there seems wrong, and is the cause of both problems. Remove that callsite and add increments to the setattr, setxattr and ioctl codepaths, at the same times that we update the ctime. The i_version bump that already happens during timestamp updates should take care of the rest. In ext4_move_extents, increment the i_version on both inodes, and also add in missing ctime updates. [ Some minor updates since we've already enabled the i_version counter unconditionally already via another patch series. -- TYT ] Cc: stable@kernel.org Cc: Lukas Czerner Reviewed-by: Jan Kara Reviewed-by: Christian Brauner (Microsoft) Signed-off-by: Jeff Layton Link: https://lore.kernel.org/r/20220908172448.208585-3-jlayton@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c839f6b1e8a68a381702c9ea123d17c3be60b779 Author: Jinke Han Date: Sat Sep 3 09:24:29 2022 +0800 ext4: place buffer head allocation before handle start commit d1052d236eddf6aa851434db1897b942e8db9921 upstream. In our product environment, we encounter some jbd hung waiting handles to stop while several writters were doing memory reclaim for buffer head allocation in delay alloc write path. Ext4 do buffer head allocation with holding transaction handle which may be blocked too long if the reclaim works not so smooth. According to our bcc trace, the reclaim time in buffer head allocation can reach 258s and the jbd transaction commit also take almost the same time meanwhile. Except for these extreme cases, we often see several seconds delays for cgroup memory reclaim on our servers. This is more likely to happen considering docker environment. One thing to note, the allocation of buffer heads is as often as page allocation or more often when blocksize less than page size. Just like page cache allocation, we should also place the buffer head allocation before startting the handle. Cc: stable@kernel.org Signed-off-by: Jinke Han Link: https://lore.kernel.org/r/20220903012429.22555-1-hanjinke.666@bytedance.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 01e159ec806681ef29d5172cdd93693eaaba74f9 Author: Zhang Yi Date: Wed Aug 31 15:46:29 2022 +0800 ext4: ext4_read_bh_lock() should submit IO if the buffer isn't uptodate commit 0b73284c564d3ae4feef4bc920292f004acf4980 upstream. Recently we notice that ext4 filesystem would occasionally fail to read metadata from disk and report error message, but the disk and block layer looks fine. After analyse, we lockon commit 88dbcbb3a484 ("blkdev: avoid migration stalls for blkdev pages"). It provide a migration method for the bdev, we could move page that has buffers without extra users now, but it lock the buffers on the page, which breaks the fragile metadata read operation on ext4 filesystem, ext4_read_bh_lock() was copied from ll_rw_block(), it depends on the assumption of that locked buffer means it is under IO. So it just trylock the buffer and skip submit IO if it lock failed, after wait_on_buffer() we conclude IO error because the buffer is not uptodate. This issue could be easily reproduced by add some delay just after buffer_migrate_lock_buffers() in __buffer_migrate_folio() and do fsstress on ext4 filesystem. EXT4-fs error (device pmem1): __ext4_find_entry:1658: inode #73193: comm fsstress: reading directory lblock 0 EXT4-fs error (device pmem1): __ext4_find_entry:1658: inode #75334: comm fsstress: reading directory lblock 0 Fix it by removing the trylock logic in ext4_read_bh_lock(), just lock the buffer and submit IO if it's not uptodate, and also leave over readahead helper. Cc: stable@kernel.org Signed-off-by: Zhang Yi Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220831074629.3755110-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit f35e65d686cfd16907060584e47249511af20278 Author: Jeff Layton Date: Wed Aug 24 18:03:49 2022 +0200 ext4: unconditionally enable the i_version counter commit 1ff20307393e17dc57fde62226df625a3a3c36e9 upstream. The original i_version implementation was pretty expensive, requiring a log flush on every change. Because of this, it was gated behind a mount option (implemented via the MS_I_VERSION mountoption flag). Commit ae5e165d855d (fs: new API for handling inode->i_version) made the i_version flag much less expensive, so there is no longer a performance penalty from enabling it. xfs and btrfs already enable it unconditionally when the on-disk format can support it. Have ext4 ignore the SB_I_VERSION flag, and just enable it unconditionally. While we're in here, mark the i_version mount option Opt_removed. [ Removed leftover bits of i_version from ext4_apply_options() since it now can't ever be set in ctx->mask_s_flags -- lczerner ] Cc: stable@kernel.org Cc: Dave Chinner Cc: Benjamin Coddington Cc: Christoph Hellwig Cc: Darrick J. Wong Signed-off-by: Jeff Layton Signed-off-by: Lukas Czerner Reviewed-by: Christian Brauner (Microsoft) Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220824160349.39664-3-lczerner@redhat.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 44c79a757437ff35bdb347de465e18d980c4e137 Author: Lukas Czerner Date: Wed Aug 24 18:03:47 2022 +0200 ext4: don't increase iversion counter for ea_inodes commit 50f094a5580e6297bf10a807d16f0ee23fa576cf upstream. ea_inodes are using i_version for storing part of the reference count so we really need to leave it alone. The problem can be reproduced by xfstest ext4/026 when iversion is enabled. Fix it by not calling inode_inc_iversion() for EXT4_EA_INODE_FL inodes in ext4_mark_iloc_dirty(). Cc: stable@kernel.org Signed-off-by: Lukas Czerner Reviewed-by: Jan Kara Reviewed-by: Jeff Layton Reviewed-by: Christian Brauner (Microsoft) Link: https://lore.kernel.org/r/20220824160349.39664-1-lczerner@redhat.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit edb71f055684f9023fd97e2f85c6f31380d163c1 Author: Jan Kara Date: Mon Aug 22 13:48:32 2022 +0200 ext4: fix check for block being out of directory size commit 61a1d87a324ad5e3ed27c6699dfc93218fcf3201 upstream. The check in __ext4_read_dirblock() for block being outside of directory size was wrong because it compared block number against directory size in bytes. Fix it. Fixes: 65f8ea4cd57d ("ext4: check if directory block is within i_size") CVE: CVE-2022-1184 CC: stable@vger.kernel.org Signed-off-by: Jan Kara Reviewed-by: Lukas Czerner Link: https://lore.kernel.org/r/20220822114832.1482-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit d0681b447f5b9f15338ff4e04889f1e8f1bd61f1 Author: Lalith Rajendran Date: Thu Aug 18 21:40:49 2022 +0000 ext4: make ext4_lazyinit_thread freezable commit 3b575495ab8dbb4dbe85b4ac7f991693c3668ff5 upstream. ext4_lazyinit_thread is not set freezable. Hence when the thread calls try_to_freeze it doesn't freeze during suspend and continues to send requests to the storage during suspend, resulting in suspend failures. Cc: stable@kernel.org Signed-off-by: Lalith Rajendran Link: https://lore.kernel.org/r/20220818214049.1519544-1-lalithkraj@google.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 4a657319cfabd6199fd0b7b65bbebf6ded7a11c1 Author: Baokun Li Date: Fri Aug 5 20:39:47 2022 +0800 ext4: fix null-ptr-deref in ext4_write_info commit f9c1f248607d5546075d3f731e7607d5571f2b60 upstream. I caught a null-ptr-deref bug as follows: ================================================================== KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 1 PID: 1589 Comm: umount Not tainted 5.10.0-02219-dirty #339 RIP: 0010:ext4_write_info+0x53/0x1b0 [...] Call Trace: dquot_writeback_dquots+0x341/0x9a0 ext4_sync_fs+0x19e/0x800 __sync_filesystem+0x83/0x100 sync_filesystem+0x89/0xf0 generic_shutdown_super+0x79/0x3e0 kill_block_super+0xa1/0x110 deactivate_locked_super+0xac/0x130 deactivate_super+0xb6/0xd0 cleanup_mnt+0x289/0x400 __cleanup_mnt+0x16/0x20 task_work_run+0x11c/0x1c0 exit_to_user_mode_prepare+0x203/0x210 syscall_exit_to_user_mode+0x5b/0x3a0 do_syscall_64+0x59/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ================================================================== Above issue may happen as follows: ------------------------------------- exit_to_user_mode_prepare task_work_run __cleanup_mnt cleanup_mnt deactivate_super deactivate_locked_super kill_block_super generic_shutdown_super shrink_dcache_for_umount dentry = sb->s_root sb->s_root = NULL <--- Here set NULL sync_filesystem __sync_filesystem sb->s_op->sync_fs > ext4_sync_fs dquot_writeback_dquots sb->dq_op->write_info > ext4_write_info ext4_journal_start(d_inode(sb->s_root), EXT4_HT_QUOTA, 2) d_inode(sb->s_root) s_root->d_inode <--- Null pointer dereference To solve this problem, we use ext4_journal_start_sb directly to avoid s_root being used. Cc: stable@kernel.org Signed-off-by: Baokun Li Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220805123947.565152-1-libaokun1@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 89db2b50469bdbccb06ab072096d9d403124abac Author: Jan Kara Date: Wed Jul 27 17:57:53 2022 +0200 ext4: avoid crash when inline data creation follows DIO write commit 4bb26f2885ac6930984ee451b952c5a6042f2c0e upstream. When inode is created and written to using direct IO, there is nothing to clear the EXT4_STATE_MAY_INLINE_DATA flag. Thus when inode gets truncated later to say 1 byte and written using normal write, we will try to store the data as inline data. This confuses the code later because the inode now has both normal block and inline data allocated and the confusion manifests for example as: kernel BUG at fs/ext4/inode.c:2721! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 359 Comm: repro Not tainted 5.19.0-rc8-00001-g31ba1e3b8305-dirty #15 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014 RIP: 0010:ext4_writepages+0x363d/0x3660 RSP: 0018:ffffc90000ccf260 EFLAGS: 00010293 RAX: ffffffff81e1abcd RBX: 0000008000000000 RCX: ffff88810842a180 RDX: 0000000000000000 RSI: 0000008000000000 RDI: 0000000000000000 RBP: ffffc90000ccf650 R08: ffffffff81e17d58 R09: ffffed10222c680b R10: dfffe910222c680c R11: 1ffff110222c680a R12: ffff888111634128 R13: ffffc90000ccf880 R14: 0000008410000000 R15: 0000000000000001 FS: 00007f72635d2640(0000) GS:ffff88811b000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000565243379180 CR3: 000000010aa74000 CR4: 0000000000150eb0 Call Trace: do_writepages+0x397/0x640 filemap_fdatawrite_wbc+0x151/0x1b0 file_write_and_wait_range+0x1c9/0x2b0 ext4_sync_file+0x19e/0xa00 vfs_fsync_range+0x17b/0x190 ext4_buffered_write_iter+0x488/0x530 ext4_file_write_iter+0x449/0x1b90 vfs_write+0xbcd/0xf40 ksys_write+0x198/0x2c0 __x64_sys_write+0x7b/0x90 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Fix the problem by clearing EXT4_STATE_MAY_INLINE_DATA when we are doing direct IO write to a file. Cc: stable@kernel.org Reported-by: Tadeusz Struk Reported-by: syzbot+bd13648a53ed6933ca49@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=a1e89d09bbbcbd5c4cb45db230ee28c822953984 Signed-off-by: Jan Kara Reviewed-by: Lukas Czerner Tested-by: Tadeusz Struk Link: https://lore.kernel.org/r/20220727155753.13969-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 40ff52527daec00cf1530c17a95636916ddd3b38 Author: Jan Kara Date: Wed Sep 14 17:24:42 2022 +0200 ext2: Add sanity checks for group and filesystem size commit d766f2d1e3e3bd44024a7f971ffcf8b8fbb7c5d2 upstream. Add sanity check that filesystem size does not exceed the underlying device size and that group size is big enough so that metadata can fit into it. This avoid trying to mount some crafted filesystems with extremely large group counts. Reported-by: syzbot+0f2f7e65a3007d39539f@syzkaller.appspotmail.com Reported-by: kernel test robot # Test fixup CC: stable@vger.kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 27c7bd35135d5ab38b9138ecf186ce54a96c98d9 Author: Ye Bin Date: Sat Sep 17 17:38:05 2022 +0800 jbd2: add miss release buffer head in fc_do_one_pass() commit dfff66f30f66b9524b661f311bbed8ff3d2ca49f upstream. In fc_do_one_pass() miss release buffer head after use which will lead to reference count leak. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220917093805.1782845-1-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 2e6d9f381c1ed844531a577783fc352de7a44c8a Author: Ye Bin Date: Wed Sep 14 18:08:12 2022 +0800 jbd2: fix potential use-after-free in jbd2_fc_wait_bufs commit 243d1a5d505d0b0460c9af0ad56ed4a56ef0bebd upstream. In 'jbd2_fc_wait_bufs' use 'bh' after put buffer head reference count which may lead to use-after-free. So judge buffer if uptodate before put buffer head reference count. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220914100812.1414768-3-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 68ed9c76b2affd47177b92495446abb7262d0ef7 Author: Ye Bin Date: Wed Sep 14 18:08:11 2022 +0800 jbd2: fix potential buffer head reference count leak commit e0d5fc7a6d80ac2406c7dfc6bb625201d0250a8a upstream. As in 'jbd2_fc_wait_bufs' if buffer isn't uptodate, will return -EIO without update 'journal->j_fc_off'. But 'jbd2_fc_release_bufs' will release buffer head from ‘j_fc_off - 1’ if 'bh' is NULL will terminal release which will lead to buffer head buffer head reference count leak. To solve above issue, update 'journal->j_fc_off' before return -EIO. Cc: stable@kernel.org Signed-off-by: Ye Bin Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220914100812.1414768-2-yebin10@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit aa972fe0f2aba854eb3003f7d166f1277ba1d8ac Author: Andrew Perepechko Date: Wed Sep 7 19:59:59 2022 +0300 jbd2: wake up journal waiters in FIFO order, not LIFO commit 34fc8768ec6089565d6d73bad26724083cecf7bd upstream. LIFO wakeup order is unfair and sometimes leads to a journal user not being able to get a journal handle for hundreds of transactions in a row. FIFO wakeup can make things more fair. Cc: stable@kernel.org Signed-off-by: Alexey Lyashkov Reviewed-by: Ritesh Harjani (IBM) Link: https://lore.kernel.org/r/20220907165959.1137482-1-alexey.lyashkov@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e168f819bfa42459b14f479e55ebd550bcc78899 Author: Chao Yu Date: Wed Sep 14 19:51:51 2022 +0800 f2fs: fix to do sanity check on summary info commit c6ad7fd16657ebd34a87a97d9588195aae87597d upstream. As Wenqing Liu reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216456 BUG: KASAN: use-after-free in recover_data+0x63ae/0x6ae0 [f2fs] Read of size 4 at addr ffff8881464dcd80 by task mount/1013 CPU: 3 PID: 1013 Comm: mount Tainted: G W 6.0.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Call Trace: dump_stack_lvl+0x45/0x5e print_report.cold+0xf3/0x68d kasan_report+0xa8/0x130 recover_data+0x63ae/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd The root cause is: in fuzzed image, SSA table is corrupted: ofs_in_node is larger than ADDRS_PER_PAGE(), result in out-of-range access on 4k-size page. - recover_data - do_recover_data - check_index_in_prev_nodes - f2fs_data_blkaddr This patch adds sanity check on summary info in recovery and GC flow in where the flows rely on them. After patch: [ 29.310883] F2FS-fs (loop0): Inconsistent ofs_in_node:65286 in summary, ino:0, nid:6, max:1018 Cc: stable@vger.kernel.org Reported-by: Wenqing Liu Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 8f0a47def4722c5fd8d6b9268b5ffed8a249e2db Author: Chao Yu Date: Tue Sep 13 10:08:41 2022 +0800 f2fs: fix to do sanity check on destination blkaddr during recovery commit 0ef4ca04a3f9223ff8bc440041c524b2123e09a3 upstream. As Wenqing Liu reported in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216456 loop5: detected capacity change from 0 to 131072 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1 F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0 F2FS-fs (loop5): Bitmap was wrongly set, blk:5634 ------------[ cut here ]------------ WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198 RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs] Call Trace: f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic instead of warning. The root cause is: in fuzzed image, SIT table is inconsistent with inode mapping table, result in triggering such warning during SIT table update. This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this flag, data block recovery flow can check destination blkaddr's validation in SIT table, and skip f2fs_replace_block() to avoid inconsistent status. Cc: stable@vger.kernel.org Reported-by: Wenqing Liu Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 43341cb9547d753184ecec3c67876efb374cc2c3 Author: Jaegeuk Kim Date: Tue Aug 23 10:18:42 2022 -0700 f2fs: increase the limit for reserve_root commit da35fe96d12d15779f3cb74929b7ed03941cf983 upstream. This patch increases the threshold that limits the reserved root space from 0.2% to 12.5% by using simple shift operation. Typically Android sets 128MB, but if the storage capacity is 32GB, 0.2% which is around 64MB becomes too small. Let's relax it. Cc: stable@vger.kernel.org Reported-by: Aran Dalton Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit ce0892c0fcf54a7b0b3f3edd326923f8f76237d7 Author: Jaegeuk Kim Date: Fri Aug 19 15:52:02 2022 -0700 f2fs: flush pending checkpoints when freezing super commit c7b58576370147833999fd4cc874d0f918bdf9ca upstream. This avoids -EINVAL when trying to freeze f2fs. Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 0fa4033d00be98741169f92be340d29a25be9094 Author: Jaegeuk Kim Date: Thu Aug 18 22:40:09 2022 -0700 f2fs: complete checkpoints during remount commit 4f99484d27961cb194cebcd917176fa038a5025f upstream. Otherwise, pending checkpoints can contribute a race condition to give a quota warning. - Thread - checkpoint thread add checkpoints to the list do_remount() down_write(&sb->s_umount); f2fs_remount() block_operations() down_read_trylock(&sb->s_umount) = 0 up_write(&sb->s_umount); f2fs_quota_sync() dquot_writeback_dquots() WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)); Or, do_remount() down_write(&sb->s_umount); f2fs_remount() create a ckpt thread f2fs_enable_checkpoint() adds checkpoints wait for f2fs_sync_fs() trigger another pending checkpoint block_operations() down_read_trylock(&sb->s_umount) = 0 up_write(&sb->s_umount); f2fs_quota_sync() dquot_writeback_dquots() WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount)); Cc: stable@vger.kernel.org Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 6ab09156093309fb571a6401b6f6fc509f891e2e Author: Jaegeuk Kim Date: Fri Aug 12 22:49:50 2022 -0700 f2fs: fix wrong continue condition in GC commit 605b0a778aa2599aa902ae639b8e9937c74b869b upstream. We should decrease the frozen counter. Cc: stable@vger.kernel.org Fixes: 325163e9892b ("f2fs: add gc_urgent_high_remaining sysfs node") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit a687c2890fe4a2acaac6941fa4097a1264d8f3eb Author: Tetsuo Handa Date: Tue Sep 20 22:43:51 2022 +0900 btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffer commit cbddcc4fa3443fe8cfb2ff8e210deb1f6a0eea38 upstream. syzbot is reporting uninit-value in btrfs_clean_tree_block() [1], for commit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code") missed that btrfs_set_header_generation() in btrfs_init_new_buffer() must not be moved to after clean_tree_block() because clean_tree_block() is calling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs: Fix extent_buffer usage when nodesize != leafsize"). Since memzero_extent_buffer() will reset "struct btrfs_header" part, we can't move btrfs_set_header_generation() to before memzero_extent_buffer(). Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block(). Link: https://syzkaller.appspot.com/bug?extid=fba8e2116a12609b6c59 [1] Reported-by: syzbot Fixes: bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code") CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Tetsuo Handa Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b81d8146f51a91d8acd9766bbacaf64422087792 Author: Filipe Manana Date: Mon Sep 19 15:06:28 2022 +0100 btrfs: fix missed extent on fsync after dropping extent maps commit cef7820d6abf8d61f8e1db411eae3c712f6d72a2 upstream. When dropping extent maps for a range, through btrfs_drop_extent_cache(), if we find an extent map that starts before our target range and/or ends before the target range, and we are not able to allocate extent maps for splitting that extent map, then we don't fail and simply remove the entire extent map from the inode's extent map tree. This is generally fine, because in case anyone needs to access the extent map, it can just load it again later from the respective file extent item(s) in the subvolume btree. However, if that extent map is new and is in the list of modified extents, then a fast fsync will miss the parts of the extent that were outside our range (that needed to be split), therefore not logging them. Fix that by marking the inode for a full fsync. This issue was introduced after removing BUG_ON()s triggered when the split extent map allocations failed, done by commit 7014cdb49305ed ("Btrfs: btrfs_drop_extent_cache should never fail"), back in 2012, and the fast fsync path already existed but was very recent. Also, in the case where we could allocate extent maps for the split operations but then fail to add a split extent map to the tree, mark the inode for a full fsync as well. This is not supposed to ever fail, and we assert that, but in case assertions are disabled (CONFIG_BTRFS_ASSERT is not set), it's the correct thing to do to make sure a fast fsync will not miss a new extent. CC: stable@vger.kernel.org # 5.15+ Reviewed-by: Anand Jain Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 0efd9dfc00d677a1d0929319a6103cb2dfc41c22 Author: Filipe Manana Date: Tue Aug 23 12:45:42 2022 +0100 btrfs: fix race between quota enable and quota rescan ioctl commit 331cd9461412e103d07595a10289de90004ac890 upstream. When enabling quotas, at btrfs_quota_enable(), after committing the transaction, we change fs_info->quota_root to point to the quota root we created and set BTRFS_FS_QUOTA_ENABLED at fs_info->flags. Then we try to start the qgroup rescan worker, first by initializing it with a call to qgroup_rescan_init() - however if that fails we end up freeing the quota root but we leave fs_info->quota_root still pointing to it, this can later result in a use-after-free somewhere else. We have previously set the flags BTRFS_FS_QUOTA_ENABLED and BTRFS_QGROUP_STATUS_FLAG_ON, so we can only fail with -EINPROGRESS at btrfs_quota_enable(), which is possible if someone already called the quota rescan ioctl, and therefore started the rescan worker. So fix this by ignoring an -EINPROGRESS and asserting we can't get any other error. Reported-by: Ye Bin Link: https://lore.kernel.org/linux-btrfs/20220823015931.421355-1-yebin10@huawei.com/ CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Qu Wenruo Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit dfb9fbc5accffccbf86350cb3e6edbcce0ccb2ef Author: Qu Wenruo Date: Tue Aug 9 13:02:16 2022 +0800 btrfs: enhance unsupported compat RO flags handling commit 81d5d61454c365718655cfc87d8200c84e25d596 upstream. Currently there are two corner cases not handling compat RO flags correctly: - Remount We can still mount the fs RO with compat RO flags, then remount it RW. We should not allow any write into a fs with unsupported RO flags. - Still try to search block group items In fact, behavior/on-disk format change to extent tree should not need a full incompat flag. And since we can ensure fs with unsupported RO flags never got any writes (with above case fixed), then we can even skip block group items search at mount time. This patch will enhance the unsupported RO compat flags by: - Reject read-write remount if there are unsupported RO compat flags - Go dummy block group items directly for unsupported RO compat flags In fact, only changes to chunk/subvolume/root/csum trees should go incompat flags. The latter part should allow future change to extent tree to be compat RO flags. Thus this patch also needs to be backported to all stable trees. CC: stable@vger.kernel.org # 4.9+ Reviewed-by: Nikolay Borisov Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9bf3abc8bcc6e3b758043095439a1651365db1f3 Author: Alexander Zhu Date: Tue Aug 2 13:32:46 2022 -0700 btrfs: fix alignment of VMA for memory mapped files on THP commit b0c582233a8563f3c4228df838cdc67a8807ec78 upstream. With CONFIG_READ_ONLY_THP_FOR_FS, the Linux kernel supports using THPs for read-only mmapped files, such as shared libraries. However, the kernel makes no attempt to actually align those mappings on 2MB boundaries, which makes it impossible to use those THPs most of the time. This issue applies to general file mapping THP as well as existing setups using CONFIG_READ_ONLY_THP_FOR_FS. This is easily fixed by using thp_get_unmapped_area for the unmapped_area function in btrfs, which is what ext2, ext4, fuse, and xfs all use. Initially btrfs had been left out in commit 8c07fc452ac0 ("btrfs: fix alignment of VMA for memory mapped files on THP") as btrfs does not support DAX. However, commit 1854bc6e2420 ("mm/readahead: Align file mappings for non-DAX") removed the DAX requirement. We should now be able to call thp_get_unmapped_area() for btrfs. The problem can be seen in /proc/PID/smaps where THPeligible is set to 0 on mappings to eligible shared object files as shown below. Before this patch: 7fc6a7e18000-7fc6a80cc000 r-xp 00000000 00:1e 199856 /usr/lib64/libcrypto.so.1.1.1k Size: 2768 kB THPeligible: 0 VmFlags: rd ex mr mw me With this patch the library is mapped at a 2MB aligned address: fbdfe200000-7fbdfe4b4000 r-xp 00000000 00:1e 199856 /usr/lib64/libcrypto.so.1.1.1k Size: 2768 kB THPeligible: 1 VmFlags: rd ex mr mw me This fixes the alignment of VMAs for any mmap of a file that has the rd and ex permissions and size >= 2MB. The VMA alignment and THPeligible field for anonymous memory is handled separately and is thus not effected by this change. CC: stable@vger.kernel.org # 5.18+ Signed-off-by: Alexander Zhu Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit b59deb46a675a6460b6b474ce5ff5041a86fbd90 Author: Lukas Czerner Date: Thu Aug 25 12:06:57 2022 +0200 fs: record I_DIRTY_TIME even if inode already has I_DIRTY_INODE commit cbfecb927f429a6fa613d74b998496bd71e4438a upstream. Currently the I_DIRTY_TIME will never get set if the inode already has I_DIRTY_INODE with assumption that it supersedes I_DIRTY_TIME. That's true, however ext4 will only update the on-disk inode in ->dirty_inode(), not on actual writeback. As a result if the inode already has I_DIRTY_INODE state by the time we get to __mark_inode_dirty() only with I_DIRTY_TIME, the time was already filled into on-disk inode and will not get updated until the next I_DIRTY_INODE update, which might never come if we crash or get a power failure. The problem can be reproduced on ext4 by running xfstest generic/622 with -o iversion mount option. Fix it by allowing I_DIRTY_TIME to be set even if the inode already has I_DIRTY_INODE. Also make sure that the case is properly handled in writeback_single_inode() as well. Additionally changes in xfs_fs_dirty_inode() was made to accommodate for I_DIRTY_TIME in flag. Thanks Jan Kara for suggestions on how to make this work properly. Cc: Dave Chinner Cc: Christoph Hellwig Cc: stable@kernel.org Signed-off-by: Lukas Czerner Suggested-by: Jan Kara Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20220825100657.44217-1-lczerner@redhat.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit be394e8a205c2dfb36db9a02fea13887efafe1f6 Author: Mickaël Salaün Date: Thu Sep 29 12:04:47 2022 +0200 ksmbd: Fix user namespace mapping commit 7c88c1e0ab1704bacb751341ee6431c3be34b834 upstream. A kernel daemon should not rely on the current thread, which is unknown and might be malicious. Before this security fix, ksmbd_override_fsids() didn't correctly override FS UID/GID which means that arbitrary user space threads could trick the kernel to impersonate arbitrary users or groups for file system access checks, leading to file system access bypass. This was found while investigating truncate support for Landlock: https://lore.kernel.org/r/CAKYAXd8fpMJ7guizOjHgxEyyjoUwPsx3jLOPZP=wPYcbhkVXqA@mail.gmail.com Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: Hyunchul Lee Cc: Steve French Cc: stable@vger.kernel.org Signed-off-by: Mickaël Salaün Link: https://lore.kernel.org/r/20220929100447.108468-1-mic@digikod.net Acked-by: Christian Brauner (Microsoft) Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 1c1225288bde032283dd1b5f0c43cea2216ab1af Author: Zhang Xiaoxu Date: Mon Sep 26 11:36:30 2022 +0800 ksmbd: Fix wrong return value and message length check in smb2_ioctl() commit b1763d265af62800ec96eeb79803c4c537dcef3a upstream. Commit c7803b05f74b ("smb3: fix ksmbd bigendian bug in oplock break, and move its struct to smbfs_common") use the defination of 'struct validate_negotiate_info_req' in smbfs_common, the array length of 'Dialects' changed from 1 to 4, but the protocol does not require the client to send all 4. This lead the request which satisfied with protocol and server to fail. So just ensure the request payload has the 'DialectCount' in smb2_ioctl(), then fsctl_validate_negotiate_info() will use it to validate the payload length and each dialect. Also when the {in, out}_buf_len is less than the required, should goto out to initialize the status in the response header. Fixes: f7db8fd03a4b ("ksmbd: add validation in smb2_ioctl") Cc: stable@vger.kernel.org Signed-off-by: Zhang Xiaoxu Acked-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 230a44aaf9a082c8cc0bdf42e7690b6d8365d4af Author: Namjae Jeon Date: Thu Sep 22 23:35:43 2022 +0900 ksmbd: fix endless loop when encryption for response fails commit 360c8ee6fefdb496fffd2c18bb9a96a376a1a804 upstream. If ->encrypt_resp return error, goto statement cause endless loop. It send an error response immediately after removing it. Fixes: 0626e6641f6b ("cifsd: add server handler for central processing and tranport layers") Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit ff5814fdced4c13557606ae78998db5e591a9142 Author: Namjae Jeon Date: Fri Sep 9 17:43:53 2022 +0900 ksmbd: fix incorrect handling of iterate_dir commit 88541cb414b7a2450c45fc9c131b37b5753b7679 upstream. if iterate_dir() returns non-negative value, caller has to treat it as normal and check there is any error while populating dentry information. ksmbd doesn't have to do anything because ksmbd already checks too small OutputBufferLength to store one file information. And because ctx->pos is set to file->f_pos when iterative_dir is called, remove restart_ctx(). And if iterate_dir() return -EIO, which mean directory entry is corrupted, return STATUS_FILE_CORRUPT_ERROR error response. This patch fixes some failure of SMB2_QUERY_DIRECTORY, which happens when ntfs3 is local filesystem. Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Cc: stable@vger.kernel.org Signed-off-by: Hyunchul Lee Signed-off-by: Namjae Jeon Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit d2c9555cce37984c94a65b6386c992ed40632a68 Author: Steve French Date: Sat Oct 1 11:44:08 2022 -0500 smb3: do not log confusing message when server returns no network interfaces commit 4659f01e3cd94f64d9bd06764ace2ef8fe1b6227 upstream. Some servers can return an empty network interface list so, unless multichannel is requested, no need to log an error for this, and when multichannel is requested on mount but no interfaces, log something less confusing. For this case change parse_server_interfaces: malformed interface info to empty network interface list returned by server localhost Also do not relog this error every ten minutes (only log on mount, once) Cc: Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit a54676340b0e45e84f2d21df2e71b3b7888fde89 Author: Jason A. Donenfeld Date: Thu Jul 28 18:22:20 2022 +0800 hwrng: core - let sleep be interrupted when unregistering hwrng commit 36cb6494429bd64b27b7ff8b4af56f8e526da2b4 upstream. There are two deadlock scenarios that need addressing, which cause problems when the computer goes to sleep, the interface is set down, and hwrng_unregister() is called. When the deadlock is hit, sleep is delayed for tens of seconds, causing it to fail. These scenarios are: 1) The hwrng kthread can't be stopped while it's sleeping, because it uses msleep_interruptible() which does not react to kthread_stop. 2) A normal user thread can't be interrupted by hwrng_unregister() while it's sleeping, because hwrng_unregister() is called from elsewhere. We solve both issues by add a completion object called dying that fulfils waiters once we have started the process in hwrng_unregister. At the same time, we should cleanup a common and useless dmesg splat in the same area. Cc: Reported-by: Gregory Erwin Fixes: fcd09c90c3c5 ("ath9k: use hw_random API instead of directly dumping into random.c") Link: https://lore.kernel.org/all/CAO+Okf6ZJC5-nTE_EJUGQtd8JiCkiEHytGgDsFGTEjs0c00giw@mail.gmail.com/ Link: https://lore.kernel.org/lkml/CAO+Okf5k+C+SE6pMVfPf-d8MfVPVq4PO7EY8Hys_DVXtent3HA@mail.gmail.com/ Link: https://bugs.archlinux.org/task/75138 Signed-off-by: Jason A. Donenfeld Signed-off-by: Herbert Xu Acked-by: Toke Høiland-Jørgensen Acked-by: Kalle Valo Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit 02c871d44090c851b07770176f88c6f5564808a1 Author: Hyunwoo Kim Date: Sun Sep 25 06:32:43 2022 -0700 fbdev: smscufx: Fix use-after-free in ufx_ops_open() commit 5610bcfe8693c02e2e4c8b31427f1bdbdecc839c upstream. A race condition may occur if the user physically removes the USB device while calling open() for this device node. This is a race condition between the ufx_ops_open() function and the ufx_usb_disconnect() function, which may eventually result in UAF. So, add a mutex to the ufx_ops_open() and ufx_usb_disconnect() functions to avoid race contidion of krefs. Signed-off-by: Hyunwoo Kim Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 0ec105bf417690bef99536e12be42a497203d26f Author: Quentin Schulz Date: Fri Sep 30 15:20:32 2022 +0200 pinctrl: rockchip: add pinmux_ops.gpio_set_direction callback commit 4635c0e2a7f7f3568cbfccae70121f9835efa62c upstream. Before the split of gpio and pinctrl sections in their own driver, rockchip_set_mux was called in pinmux_ops.gpio_set_direction for configuring a pin in its GPIO function. This is essential for cases where pinctrl is "bypassed" by gpio consumers otherwise the GPIO function is not configured for the pin and it does not work. Such was the case for the sysfs/libgpiod userspace GPIO handling. Let's re-implement the pinmux_ops.gpio_set_direction callback so that the gpio subsystem can request from the pinctrl driver to put the pin in its GPIO function. Fixes: 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes") Cc: stable@vger.kernel.org Reviewed-by: Heiko Stuebner Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20220930132033.4003377-2-foss+kernel@0leil.net Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit a11544efbcf5caa1c6e7ccc8e0f3bf1b63c9b500 Author: Quentin Schulz Date: Fri Sep 30 15:20:33 2022 +0200 gpio: rockchip: request GPIO mux to pinctrl when setting direction commit 8ea8af6c8469156ac2042d83d73f6b74eb4b4b45 upstream. Before the split of gpio and pinctrl sections in their own driver, rockchip_set_mux was called in pinmux_ops.gpio_set_direction for configuring a pin in its GPIO function. This is essential for cases where pinctrl is "bypassed" by gpio consumers otherwise the GPIO function is not configured for the pin and it does not work. Such was the case for the sysfs/libgpiod userspace GPIO handling. Let's call pinctrl_gpio_direction_input/output when setting the direction of a GPIO so that the pinctrl core requests from the rockchip pinctrl driver to put the pin in its GPIO function. Fixes: 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes") Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio") Cc: stable@vger.kernel.org Reviewed-by: Heiko Stuebner Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20220930132033.4003377-3-foss+kernel@0leil.net Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 6f9a24b4ac16487943bcd0781d8345702494a800 Author: Saurav Kashyap Date: Mon Sep 19 06:44:34 2022 -0700 scsi: qedf: Populate sysfs attributes for vport commit 592642e6b11e620e4b43189f8072752429fc8dc3 upstream. Few vport parameters were displayed by systool as 'Unknown' or 'NULL'. Copy speed, supported_speed, frame_size and update port_type for NPIV port. Link: https://lore.kernel.org/r/20220919134434.3513-1-njavali@marvell.com Cc: stable@vger.kernel.org Tested-by: Guangwu Zhang Reviewed-by: John Meneghini Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 147d397e08a406f5997f8a1c7f747fe546bf8395 Author: James Smart Date: Thu Aug 18 18:17:32 2022 -0700 scsi: lpfc: Rework MIB Rx Monitor debug info logic commit bd269188ea94e40ab002cad7b0df8f12b8f0de54 upstream. The kernel test robot reported the following sparse warning: arch/arm64/include/asm/cmpxchg.h:88:1: sparse: sparse: cast truncates bits from constant value (369 becomes 69) On arm64, atomic_xchg only works on 8-bit byte fields. Thus, the macro usage of LPFC_RXMONITOR_TABLE_IN_USE can be unintentionally truncated leading to all logic involving the LPFC_RXMONITOR_TABLE_IN_USE macro to not work properly. Replace the Rx Table atomic_t indexing logic with a new lpfc_rx_info_monitor structure that holds a circular ring buffer. For locking semantics, a spinlock_t is used. Link: https://lore.kernel.org/r/20220819011736.14141-4-jsmart2021@gmail.com Fixes: 17b27ac59224 ("scsi: lpfc: Add rx monitoring statistics") Cc: # v5.15+ Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0c76110a3129c8d56d8fb7b6270dcc0c5c2f1a41 Author: Krzysztof Kozlowski Date: Fri Sep 16 13:29:08 2022 +0100 slimbus: qcom-ngd: cleanup in probe error path commit 16f14551d0df9e7cd283545d7d748829594d912f upstream. Add proper error path in probe() to cleanup resources previously acquired/allocated to fix warnings visible during probe deferral: notifier callback qcom_slim_ngd_ssr_notify already registered WARNING: CPU: 6 PID: 70 at kernel/notifier.c:28 notifier_chain_register+0x5c/0x90 Modules linked in: CPU: 6 PID: 70 Comm: kworker/u16:1 Not tainted 6.0.0-rc3-next-20220830 #380 Call trace: notifier_chain_register+0x5c/0x90 srcu_notifier_chain_register+0x44/0x90 qcom_register_ssr_notifier+0x38/0x4c qcom_slim_ngd_ctrl_probe+0xd8/0x400 platform_probe+0x6c/0xe0 really_probe+0xbc/0x2d4 __driver_probe_device+0x78/0xe0 driver_probe_device+0x3c/0x12c __device_attach_driver+0xb8/0x120 bus_for_each_drv+0x78/0xd0 __device_attach+0xa8/0x1c0 device_initial_probe+0x18/0x24 bus_probe_device+0xa0/0xac deferred_probe_work_func+0x88/0xc0 process_one_work+0x1d4/0x320 worker_thread+0x2cc/0x44c kthread+0x110/0x114 ret_from_fork+0x10/0x20 Fixes: e1ae85e1830e ("slimbus: qcom-ngd-ctrl: add Protection Domain Restart Support") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220916122910.170730-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman commit 30e704e063cbf1354a254d22affb022e7cdc42ce Author: Krzysztof Kozlowski Date: Fri Sep 16 13:29:07 2022 +0100 slimbus: qcom-ngd: use correct error in message of pdr_add_lookup() failure commit 5038d21dde818fe74ba1fcb6f2cee35b8c2ebbf2 upstream. Use correct error code, instead of previous 'ret' value, when printing error from pdr_add_lookup() failure. Fixes: e1ae85e1830e ("slimbus: qcom-ngd-ctrl: add Protection Domain Restart Support") Cc: Signed-off-by: Krzysztof Kozlowski Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220916122910.170730-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman commit 5c87da431c18cdac012b777fb91a96a4dfbeac45 Author: Pali Rohár Date: Sat Aug 27 15:44:54 2022 +0200 powerpc/boot: Explicitly disable usage of SPE instructions commit 110a58b9f91c66f743c01a2c217243d94c899c23 upstream. uImage boot wrapper should not use SPE instructions, like kernel itself. Boot wrapper has already disabled Altivec and VSX instructions but not SPE. Options -mno-spe and -mspe=no already set when compilation of kernel, but not when compiling uImage wrapper yet. Fix it. Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220827134454.17365-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit 81a12906cb760988d70efc8699dcfee893411d25 Author: Christophe Leroy Date: Mon Sep 19 19:01:25 2022 +0200 powerpc/Kconfig: Fix non existing CONFIG_PPC_FSL_BOOKE commit d1203f32d86987a3ccd7de9ba2448ba12d86d125 upstream. CONFIG_PPC_FSL_BOOKE doesn't exist. Should be CONFIG_FSL_BOOKE. Fixes: 49e3d8ea6248 ("powerpc/fsl_booke: Enable STRICT_KERNEL_RWX") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/828f6a64eeb51ce9abfa1d4e84c521a02fecebb8.1663606875.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 6396d57b8c4fa38ce4c090f9fd2711493b2abb9a Author: Zhang Rui Date: Sat Sep 24 13:47:36 2022 +0800 powercap: intel_rapl: Use standard Energy Unit for SPR Dram RAPL domain commit 4c081324df5608b73428662ca54d5221ea03a6bd upstream. Intel Xeon servers used to use a fixed energy resolution (15.3uj) for Dram RAPL domain. But on SPR, Dram RAPL domain follows the standard energy resolution as described in MSR_RAPL_POWER_UNIT. Remove the SPR dram_domain_energy_unit quirk. Fixes: 2d798d9f5967 ("powercap: intel_rapl: add support for Sapphire Rapids") Signed-off-by: Zhang Rui Tested-by: Wang Wendy Cc: 5.9+ # 5.9+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit c5f1c47aaa3fea115d355d5a3ec321d4063d128d Author: Viresh Kumar Date: Wed Sep 21 12:30:38 2022 +0530 cpufreq: qcom-cpufreq-hw: Fix uninitialized throttled_freq warning commit 91dc90fdb8b8199519a3aac9c46a433b02223c5b upstream. Commit 6240aaad75e1 was supposed to drop the reference count to the OPP, instead it avoided more stuff if the OPP isn't found. This isn't entirely correct. We already have a frequency value available, we just couldn't align it with an OPP in case of IS_ERR(opp). Lets continue with updating thermal pressure, etc, even if we aren't able to find an OPP here. This fixes warning generated by the 'smatch' tool. Fixes: 6240aaad75e1 ("cpufreq: qcom-hw: fix the opp entries refcounting") Cc: v5.18+ # v5.18+ Reported-by: kernel test robot Reported-by: Dan Carpenter Reviewed-by: Neil Armstrong Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit bc6c0ed253cd4763dba7541d558e4b704f33176f Author: Chuck Lever Date: Thu Sep 1 15:10:24 2022 -0400 NFSD: Protect against send buffer overflow in NFSv3 READ commit fa6be9cc6e80ec79892ddf08a8c10cabab9baf38 upstream. Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. Cc: Signed-off-by: Chuck Lever Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit ea4c3eee0fd72fcedaa238556044825639cd3607 Author: Chuck Lever Date: Thu Sep 1 15:10:18 2022 -0400 NFSD: Protect against send buffer overflow in NFSv2 READ commit 401bc1f90874280a80b93f23be33a0e7e2d1f912 upstream. Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. Cc: Signed-off-by: Chuck Lever Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 9c3224826ec17f14e8bdfc86cb7e82fe52d744a7 Author: Chuck Lever Date: Thu Sep 1 15:10:12 2022 -0400 NFSD: Protect against send buffer overflow in NFSv3 READDIR commit 640f87c190e0d1b2a0fcb2ecf6d2cd53b1c41991 upstream. Since before the git era, NFSD has conserved the number of pages held by each nfsd thread by combining the RPC receive and send buffers into a single array of pages. This works because there are no cases where an operation needs a large RPC Call message and a large RPC Reply message at the same time. Once an RPC Call has been received, svc_process() updates svc_rqst::rq_res to describe the part of rq_pages that can be used for constructing the Reply. This means that the send buffer (rq_res) shrinks when the received RPC record containing the RPC Call is large. A client can force this shrinkage on TCP by sending a correctly- formed RPC Call header contained in an RPC record that is excessively large. The full maximum payload size cannot be constructed in that case. Thanks to Aleksi Illikainen and Kari Hulkko for uncovering this issue. Reported-by: Ben Ronallo Cc: Signed-off-by: Chuck Lever Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 003505406a505e92dfc1d9424ad0175a8a920647 Author: Maciej W. Rozycki Date: Wed Sep 21 00:35:37 2022 +0100 serial: 8250: Request full 16550A feature probing for OxSemi PCIe devices commit 00b7a4d4ee42be1c515e56cb1e8ba0f25e271d8e upstream. Oxford Semiconductor PCIe (Tornado) 950 serial port devices need to operate in the enhanced mode via the EFR register for the Divide-by-M N/8 baud rate generator prescaler to be used in their native UART mode. Otherwise the prescaler is fixed at 1 causing grossly incorrect baud rates to be programmed. Accessing the EFR register requires 16550A features to have been probed for, so request this to happen regardless of SERIAL_8250_16550A_VARIANTS by setting UPF_FULL_PROBE in port flags. Fixes: 366f6c955d4d ("serial: 8250: Add proper clock handling for OxSemi PCIe devices") Cc: stable@vger.kernel.org # v5.19+ Reported-by: Anders Blomdell Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209210005040.41633@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 8f9bd3fdc8d3e03c451df2fee6124fe2cccda16e Author: Maciej W. Rozycki Date: Wed Sep 21 00:35:32 2022 +0100 serial: 8250: Let drivers request full 16550A feature probing commit 9906890c89e4dbd900ed87ad3040080339a7f411 upstream. A SERIAL_8250_16550A_VARIANTS configuration option has been recently defined that lets one request the 8250 driver not to probe for 16550A device features so as to reduce the driver's device startup time in virtual machines. Some actual hardware devices require these features to have been fully determined however for their driver to work correctly, so define a flag to let drivers request full 16550A feature probing on a device-by-device basis if required regardless of the SERIAL_8250_16550A_VARIANTS option setting chosen. Fixes: dc56ecb81a0a ("serial: 8250: Support disabling mdelay-filled probes of 16550A variants") Cc: stable@vger.kernel.org # v5.6+ Reported-by: Anders Blomdell Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209202357520.41633@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman commit 232509094ea5e76824cc0c35638b095410b9d2f2 Author: Lukas Wunner Date: Sun Sep 11 11:02:03 2022 +0200 serial: stm32: Deassert Transmit Enable on ->rs485_config() commit adafbbf6895eb0ce41a313c6ee68870ab9aa93cd upstream. The STM32 USART can control RS-485 Transmit Enable in hardware. Since commit 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control"), it can alternatively be controlled in software. That was done to allow RS-485 even if the RTS pin is unavailable because it's pinmuxed to a different function. However the commit neglected to deassert Transmit Enable upon invocation of the ->rs485_config() callback. Fix it. Avoid forward declarations by moving stm32_usart_tx_empty(), stm32_usart_rs485_rts_enable() and stm32_usart_rs485_rts_disable() further up in the driver. Fixes: 7df5081cbf5e ("serial: stm32: Add RS485 RTS GPIO control") Cc: stable@vger.kernel.org # v5.9+ Cc: Marek Vasut Reviewed-by: Ilpo Järvinen Signed-off-by: Lukas Wunner Link: https://lore.kernel.org/r/6059eab35dba394468335ef640df8b0050fd9dbd.1662886616.git.lukas@wunner.de Signed-off-by: Greg Kroah-Hartman commit 5064982437a1b24195c7928067ef7b6391a102c8 Author: Christophe Leroy Date: Fri Sep 30 10:33:56 2022 +0200 serial: cpm_uart: Don't request IRQ too early for console port commit 30963b2f75bfdbbcf1cc5d80bf88fec7aaba808d upstream. The following message is seen during boot and the activation of console port gets delayed until normal serial ports activation. [ 0.001346] irq: no irq domain found for pic@930 ! The console port doesn't need irq, perform irq reservation later, during cpm_uart probe. While at it, don't use NO_IRQ but 0 which is the value returned by irq_of_parse_and_map() in case of error. By chance powerpc's NO_IRQ has value 0 but on some architectures it is -1. Fixes: 14d893fc6846 ("powerpc/8xx: Convert CPM1 interrupt controller to platform_device") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/8bed0f30c2e9ef16ae64fb1243a16d54a48eb8da.1664526717.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman commit 1680dbf5128128a8daf9deae904b35da20d40ccc Author: Maciej W. Rozycki Date: Wed Sep 21 20:49:16 2022 +0100 PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge commit 0e32818397426a688f598f35d3bc762eca6d7592 upstream. When pci_assign_resource() is unable to assign resources to a BAR, it uses pci_revert_fw_address() to fall back to a firmware assignment (if any). Previously pci_revert_fw_address() assumed all addresses could reach the device, but this is not true if the device is below a bridge that only forwards addresses within its windows. This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS did not assign valid addresses to several bridges and USB devices: pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff] pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff] pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff] pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable pci 0000:06:08.0: USB UHCI 1.1 pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.1: USB UHCI 1.1 pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window During the first pass of assigning unassigned resources, there was not enough I/O space available, so we couldn't assign the 06:08.0 BAR and reverted to the firmware assignment (still unreachable). Reverting the 06:08.1 assignment failed because it conflicted with 06:08.0: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] pci 0000:01:00.0: no space for bridge window [io size 0x2000] pci 0000:02:02.0: no space for bridge window [io size 0x1000] pci 0000:05:00.0: no space for bridge window [io size 0x1000] pci 0000:06:08.0: BAR 4: no space for [io size 0x0020] pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: no space for [io size 0x0020] pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff] pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff] A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR, but left the 06:08.0 BAR alone, so the UHCI device was still unusable: pci 0000:00:11.0: bridge window [io 0xe000-0xefff] released pci 0000:00:11.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:01:00.0: bridge window [io 0x1000-0x2fff] # reassigned pci 0000:02:02.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] # reassigned pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff] # left alone pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f] ... uhci_hcd 0000:06:08.0: host system error, PCI problems? uhci_hcd 0000:06:08.0: host controller process error, something bad happened! uhci_hcd 0000:06:08.0: host controller halted, very bad! uhci_hcd 0000:06:08.0: HCRESET not completed yet! uhci_hcd 0000:06:08.0: HC died; cleaning up If the address assigned by firmware is not reachable because it's not within upstream bridge windows, fail instead of assigning the unusable address from firmware. [bhelgaas: commit log, use pci_upstream_bridge()] Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263 Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk Fixes: 58c84eda0756 ("PCI: fall back to original BIOS BAR addresses") Signed-off-by: Maciej W. Rozycki Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v2.6.35+ Signed-off-by: Greg Kroah-Hartman commit 4fb4053d90caa9985b87ec0e0c32c66a55bdfa3a Author: M. Vefa Bicakci Date: Sun Oct 2 18:20:06 2022 -0400 xen/gntdev: Accommodate VMA splitting commit 5c13a4a0291b30191eff9ead8d010e1ca43a4d0c upstream. Prior to this commit, the gntdev driver code did not handle the following scenario correctly with paravirtualized (PV) Xen domains: * User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain). * User process munmap()s one of the pages. * User process munmap()s the remaining page. * User process exits. In the scenario above, the user process would cause the kernel to log the following messages in dmesg for the first munmap(), and the second munmap() call would result in similar log messages: BUG: Bad page map in process doublemap.test pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... page dumped because: bad pte ... file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0 ... Call Trace: dump_stack_lvl+0x46/0x5e print_bad_pte.cold+0x66/0xb6 unmap_page_range+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110 __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_munmap+0x28/0x40 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb ... For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG) would print out the following and trigger a general protection fault in the affected Xen PV domain: (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... As of this writing, gntdev_grant_map structure's vma field (referred to as map->vma below) is mainly used for checking the start and end addresses of mappings. However, with split VMAs, these may change, and there could be more than one VMA associated with a gntdev mapping. Hence, remove the use of map->vma and rely on map->pages_vm_start for the original start address and on (map->count << PAGE_SHIFT) for the original mapping size. Let the invalidate() and find_special_page() hooks use these. Also, given that there can be multiple VMAs associated with a gntdev mapping, move the "mmu_interval_notifier_remove(&map->notifier)" call to the end of gntdev_put_map, so that the MMU notifier is only removed after the closing of the last remaining VMA. Finally, use an atomic to prevent inadvertent gntdev mapping re-use, instead of using the map->live_grants atomic counter and/or the map->vma pointer (the latter of which is now removed). This prevents the userspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over the same address range as a previously set up gntdev mapping. This scenario can be summarized with the following call-trace, which was valid prior to this commit: mmap gntdev_mmap mmap (repeat mmap with MAP_FIXED over the same address range) gntdev_invalidate unmap_grant_pages (sets 'being_removed' entries to true) gnttab_unmap_refs_async unmap_single_vma gntdev_mmap (maps the shared pages again) munmap gntdev_invalidate unmap_grant_pages (no-op because 'being_removed' entries are true) unmap_single_vma (For PV domains, Xen reports that a granted page is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIG_DEBUG) The fix for this last scenario could be worth its own commit, but we opted for a single commit, because removing the gntdev_grant_map structure's vma field requires guarding the entry to gntdev_mmap(), and the live_grants atomic counter is not sufficient on its own to prevent the mmap() over a pre-existing mapping. Link: https://github.com/QubesOS/qubes-issues/issues/7631 Fixes: ab31523c2fca ("xen/gntdev: allow usermode to map granted pages") Cc: stable@vger.kernel.org Signed-off-by: M. Vefa Bicakci Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221002222006.2077-3-m.v.b@runbox.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 0bccddd9b8f03ad57bb738f0d3da8845d4e1e579 Author: M. Vefa Bicakci Date: Sun Oct 2 18:20:05 2022 -0400 xen/gntdev: Prevent leaking grants commit 0991028cd49567d7016d1b224fe0117c35059f86 upstream. Prior to this commit, if a grant mapping operation failed partially, some of the entries in the map_ops array would be invalid, whereas all of the entries in the kmap_ops array would be valid. This in turn would cause the following logic in gntdev_map_grant_pages to become invalid: for (i = 0; i < map->count; i++) { if (map->map_ops[i].status == GNTST_okay) { map->unmap_ops[i].handle = map->map_ops[i].handle; if (!use_ptemod) alloced++; } if (use_ptemod) { if (map->kmap_ops[i].status == GNTST_okay) { if (map->map_ops[i].status == GNTST_okay) alloced++; map->kunmap_ops[i].handle = map->kmap_ops[i].handle; } } } ... atomic_add(alloced, &map->live_grants); Assume that use_ptemod is true (i.e., the domain mapping the granted pages is a paravirtualized domain). In the code excerpt above, note that the "alloced" variable is only incremented when both kmap_ops[i].status and map_ops[i].status are set to GNTST_okay (i.e., both mapping operations are successful). However, as also noted above, there are cases where a grant mapping operation fails partially, breaking the assumption of the code excerpt above. The aforementioned causes map->live_grants to be incorrectly set. In some cases, all of the map_ops mappings fail, but all of the kmap_ops mappings succeed, meaning that live_grants may remain zero. This in turn makes it impossible to unmap the successfully grant-mapped pages pointed to by kmap_ops, because unmap_grant_pages has the following snippet of code at its beginning: if (atomic_read(&map->live_grants) == 0) return; /* Nothing to do */ In other cases where only some of the map_ops mappings fail but all kmap_ops mappings succeed, live_grants is made positive, but when the user requests unmapping the grant-mapped pages, __unmap_grant_pages_done will then make map->live_grants negative, because the latter function does not check if all of the pages that were requested to be unmapped were actually unmapped, and the same function unconditionally subtracts "data->count" (i.e., a value that can be greater than map->live_grants) from map->live_grants. The side effects of a negative live_grants value have not been studied. The net effect of all of this is that grant references are leaked in one of the above conditions. In Qubes OS v4.1 (which uses Xen's grant mechanism extensively for X11 GUI isolation), this issue manifests itself with warning messages like the following to be printed out by the Linux kernel in the VM that had granted pages (that contain X11 GUI window data) to dom0: "g.e. 0x1234 still pending", especially after the user rapidly resizes GUI VM windows (causing some grant-mapping operations to partially or completely fail, due to the fact that the VM unshares some of the pages as part of the window resizing, making the pages impossible to grant-map from dom0). The fix for this issue involves counting all successful map_ops and kmap_ops mappings separately, and then adding the sum to live_grants. During unmapping, only the number of successfully unmapped grants is subtracted from live_grants. The code is also modified to check for negative live_grants values after the subtraction and warn the user. Link: https://github.com/QubesOS/qubes-issues/issues/7631 Fixes: dbe97cff7dd9 ("xen/gntdev: Avoid blocking in unmap_grant_pages()") Cc: stable@vger.kernel.org Signed-off-by: M. Vefa Bicakci Acked-by: Demi Marie Obenour Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221002222006.2077-2-m.v.b@runbox.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit 6757330b1be5b0606125b65ed50caac69bccf9a5 Author: Carlos Llamas Date: Fri Sep 30 00:38:43 2022 +0000 mm/mmap: undo ->mmap() when arch_validate_flags() fails commit deb0f6562884b5b4beb883d73e66a7d3a1b96d99 upstream. Commit c462ac288f2c ("mm: Introduce arch_validate_flags()") added a late check in mmap_region() to let architectures validate vm_flags. The check needs to happen after calling ->mmap() as the flags can potentially be modified during this callback. If arch_validate_flags() check fails we unmap and free the vma. However, the error path fails to undo the ->mmap() call that previously succeeded and depending on the specific ->mmap() implementation this translates to reference increments, memory allocations and other operations what will not be cleaned up. There are several places (mainly device drivers) where this is an issue. However, one specific example is bpf_map_mmap() which keeps count of the mappings in map->writecnt. The count is incremented on ->mmap() and then decremented on vm_ops->close(). When arch_validate_flags() fails this count is off since bpf_map_mmap_close() is never called. One can reproduce this issue in arm64 devices with MTE support. Here the vm_flags are checked to only allow VM_MTE if VM_MTE_ALLOWED has been set previously. From userspace then is enough to pass the PROT_MTE flag to mmap() syscall to trigger the arch_validate_flags() failure. The following program reproduces this issue: #include #include #include #include #include int main(void) { union bpf_attr attr = { .map_type = BPF_MAP_TYPE_ARRAY, .key_size = sizeof(int), .value_size = sizeof(long long), .max_entries = 256, .map_flags = BPF_F_MMAPABLE, }; int fd; fd = syscall(__NR_bpf, BPF_MAP_CREATE, &attr, sizeof(attr)); mmap(NULL, 4096, PROT_WRITE | PROT_MTE, MAP_SHARED, fd, 0); return 0; } By manually adding some log statements to the vm_ops callbacks we can confirm that when passing PROT_MTE to mmap() the map->writecnt is off upon ->release(): With PROT_MTE flag: root@debian:~# ./bpf-test [ 111.263874] bpf_map_write_active_inc: map=9 writecnt=1 [ 111.288763] bpf_map_release: map=9 writecnt=1 Without PROT_MTE flag: root@debian:~# ./bpf-test [ 157.816912] bpf_map_write_active_inc: map=10 writecnt=1 [ 157.830442] bpf_map_write_active_dec: map=10 writecnt=0 [ 157.832396] bpf_map_release: map=10 writecnt=0 This patch fixes the above issue by calling vm_ops->close() when the arch_validate_flags() check fails, after this we can proceed to unmap and free the vma on the error path. Link: https://lkml.kernel.org/r/20220930003844.1210987-1-cmllamas@google.com Fixes: c462ac288f2c ("mm: Introduce arch_validate_flags()") Signed-off-by: Carlos Llamas Reviewed-by: Catalin Marinas Acked-by: Andrii Nakryiko Reviewed-by: Liam Howlett Cc: Christian Brauner (Microsoft) Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: [5.10+] Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit b76e4eb02e9edb9a0a51942acdb373ca01346e8c Author: Peter Xu Date: Fri Sep 30 20:25:55 2022 -0400 mm/uffd: fix warning without PTE_MARKER_UFFD_WP compiled in commit 515778e2d790652a38a24554fdb7f21420d91efc upstream. When PTE_MARKER_UFFD_WP not configured, it's still possible to reach pte marker code and trigger an warning. Add a few CONFIG_PTE_MARKER_UFFD_WP ifdefs to make sure the code won't be reached when not compiled in. Link: https://lkml.kernel.org/r/YzeR+R6b4bwBlBHh@x1n Fixes: b1f9e876862d ("mm/uffd: enable write protection for shmem & hugetlbfs") Signed-off-by: Peter Xu Reported-by: Cc: Axel Rasmussen Cc: Brian Geffon Cc: Edward Liaw Cc: Liu Shixin Cc: Mike Kravetz Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e77f4ddc7e1134c476f308fc5d88877316e44b1c Author: Baolin Wang Date: Thu Aug 18 15:37:43 2022 +0800 mm/damon: validate if the pmd entry is present before accessing commit c8b9aff419303e4d4219b5ff64b1c7e062dee48e upstream. pmd_huge() is used to validate if the pmd entry is mapped by a huge page, also including the case of non-present (migration or hwpoisoned) pmd entry on arm64 or x86 architectures. This means that pmd_pfn() can not get the correct pfn number for a non-present pmd entry, which will cause damon_get_page() to get an incorrect page struct (also may be NULL by pfn_to_online_page()), making the access statistics incorrect. This means that the DAMON may make incorrect decision according to the incorrect statistics, for example, DAMON may can not reclaim cold page in time due to this cold page was regarded as accessed mistakenly if DAMOS_PAGEOUT operation is specified. Moreover it does not make sense that we still waste time to get the page of the non-present entry. Just treat it as not-accessed and skip it, which maintains consistency with non-present pte level entries. So add pmd entry present validation to fix the above issues. Link: https://lkml.kernel.org/r/58b1d1f5fbda7db49ca886d9ef6783e3dcbbbc98.1660805030.git.baolin.wang@linux.alibaba.com Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces") Signed-off-by: Baolin Wang Reviewed-by: SeongJae Park Reviewed-by: Muchun Song Cc: Mike Kravetz Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 86a913d55c89dd13ba070a87f61a493563e94b54 Author: Baolin Wang Date: Thu Sep 1 18:41:31 2022 +0800 mm/hugetlb: fix races when looking up a CONT-PTE/PMD size hugetlb page commit fac35ba763ed07ba93154c95ffc0c4a55023707f upstream. On some architectures (like ARM64), it can support CONT-PTE/PMD size hugetlb, which means it can support not only PMD/PUD size hugetlb (2M and 1G), but also CONT-PTE/PMD size(64K and 32M) if a 4K page size specified. So when looking up a CONT-PTE size hugetlb page by follow_page(), it will use pte_offset_map_lock() to get the pte entry lock for the CONT-PTE size hugetlb in follow_page_pte(). However this pte entry lock is incorrect for the CONT-PTE size hugetlb, since we should use huge_pte_lock() to get the correct lock, which is mm->page_table_lock. That means the pte entry of the CONT-PTE size hugetlb under current pte lock is unstable in follow_page_pte(), we can continue to migrate or poison the pte entry of the CONT-PTE size hugetlb, which can cause some potential race issues, even though they are under the 'pte lock'. For example, suppose thread A is trying to look up a CONT-PTE size hugetlb page by move_pages() syscall under the lock, however antoher thread B can migrate the CONT-PTE hugetlb page at the same time, which will cause thread A to get an incorrect page, if thread A also wants to do page migration, then data inconsistency error occurs. Moreover we have the same issue for CONT-PMD size hugetlb in follow_huge_pmd(). To fix above issues, rename the follow_huge_pmd() as follow_huge_pmd_pte() to handle PMD and PTE level size hugetlb, which uses huge_pte_lock() to get the correct pte entry lock to make the pte entry stable. Mike said: Support for CONT_PMD/_PTE was added with bb9dd3df8ee9 ("arm64: hugetlb: refactor find_num_contig()"). Patch series "Support for contiguous pte hugepages", v4. However, I do not believe these code paths were executed until migration support was added with 5480280d3f2d ("arm64/mm: enable HugeTLB migration for contiguous bit HugeTLB pages") I would go with 5480280d3f2d for the Fixes: targe. Link: https://lkml.kernel.org/r/635f43bdd85ac2615a58405da82b4d33c6e5eb05.1662017562.git.baolin.wang@linux.alibaba.com Fixes: 5480280d3f2d ("arm64/mm: enable HugeTLB migration for contiguous bit HugeTLB pages") Signed-off-by: Baolin Wang Suggested-by: Mike Kravetz Reviewed-by: Mike Kravetz Cc: David Hildenbrand Cc: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit ed5895be34b6e7981739f39602a94f66a5897abc Author: Yang Guo Date: Tue Sep 27 11:32:21 2022 +0800 clocksource/drivers/arm_arch_timer: Fix CNTPCT_LO and CNTVCT_LO value commit af246cc6d0ed11318223606128bb0b09866c4c08 upstream. CNTPCT_LO and CNTVCT_LO are defined by mistake in commit '8b82c4f883a7', so fix them according to the Arm ARM DDI 0487I.a, Table I2-4 "CNTBaseN memory map" as follows: Offset Register Type Description 0x000 CNTPCT[31:0] RO Physical Count register. 0x004 CNTPCT[63:32] RO 0x008 CNTVCT[31:0] RO Virtual Count register. 0x00C CNTVCT[63:32] RO Fixes: 8b82c4f883a7 ("clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL") Cc: stable@vger.kernel.org Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: Marc Zyngier Cc: Mark Rutland Acked-by: Marc Zyngier Signed-off-by: Yang Guo Signed-off-by: Shaokun Zhang Link: https://lore.kernel.org/r/20220927033221.49589-1-zhangshaokun@hisilicon.com Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman commit 53177c8253e33312cfddd5d7afa6215ff6041b96 Author: James Morse Date: Fri Sep 30 14:19:59 2022 +0100 arm64: errata: Add Cortex-A55 to the repeat tlbi list commit 171df58028bf4649460fb146a56a58dcb0c8f75a upstream. Cortex-A55 is affected by an erratum where in rare circumstances the CPUs may not handle a race between a break-before-make sequence on one CPU, and another CPU accessing the same page. This could allow a store to a page that has been unmapped. Work around this by adding the affected CPUs to the list that needs TLB sequences to be done twice. Signed-off-by: James Morse Cc: Link: https://lore.kernel.org/r/20220930131959.3082594-1-james.morse@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit c9ded3c93132d40b2a1f702f5e604a7dcd91486e Author: Peter Collingbourne Date: Thu Sep 15 15:20:53 2022 -0700 arm64: mte: move register initialization to C commit 973b9e37330656dec719ede508e4dc40e5c2d80c upstream. If FEAT_MTE2 is disabled via the arm64.nomte command line argument on a CPU that claims to support FEAT_MTE2, the kernel will use Tagged Normal in the MAIR. If we interpret arm64.nomte to mean that the CPU does not in fact implement FEAT_MTE2, setting the system register like this may lead to UNSPECIFIED behavior. Fix it by arranging for MAIR to be set in the C function cpu_enable_mte which is called based on the sanitized version of the system register. There is no need for the rest of the MTE-related system register initialization to happen from assembly, with the exception of TCR_EL1, which must be set to include at least TBI1 because the secondary CPUs access KASan-allocated data structures early. Therefore, make the TCR_EL1 initialization unconditional and move the rest of the initialization to cpu_enable_mte so that we no longer have a dependency on the unsanitized ID register value. Co-developed-by: Evgenii Stepanov Signed-off-by: Peter Collingbourne Signed-off-by: Evgenii Stepanov Suggested-by: Catalin Marinas Reported-by: kernel test robot Fixes: 3b714d24ef17 ("arm64: mte: CPU feature detection and initial sysreg configuration") Cc: # 5.10.x Link: https://lore.kernel.org/r/20220915222053.3484231-1-eugenis@google.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 921384209d10b5c7938ce5124271c967aee1f814 Author: Takashi Iwai Date: Thu Sep 8 11:51:04 2022 +0200 drm/udl: Restore display mode on resume commit 6d6e732835db92e66c28dbcf258a7e3d3c71420d upstream. Restore the display mode whne resuming from suspend. Currently, the display remains dark. On resume, the CRTC's mode does not change, but the 'active' flag changes to 'true'. Taking this into account when considering a mode switch restores the display mode. The bug is reproducable by using Gnome with udl and observing the adapter's suspend/resume behavior. Actually, the whole check added in udl_simple_display_pipe_enable() about the crtc_state->mode_changed was bogus. We should drop the whole check and always apply the mode change in this function. [ tiwai -- Drop the mode_changed check entirely instead, per Daniel's suggestion ] Fixes: 997d33c35618 ("drm/udl: Inline DPMS code into CRTC enable and disable functions") Cc: Suggested-by: Daniel Vetter Reviewed-by: Daniel Vetter Signed-off-by: Takashi Iwai Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20220908095115.23396-2-tiwai@suse.de Signed-off-by: Greg Kroah-Hartman commit 60538f6bf14f791abec5cde12eee632334feb59f Author: Dmitry Osipenko Date: Thu Jun 30 23:07:22 2022 +0300 drm/virtio: Use appropriate atomic state in virtio_gpu_plane_cleanup_fb() commit 4656b3a26a9e9fe5f04bfd2ab55b066266ba7f4d upstream. Make virtio_gpu_plane_cleanup_fb() to clean the state which DRM core wants to clean up and not the current plane's state. Normally the older atomic state is cleaned up, but the newer state could also be cleaned up in case of aborted commits. Cc: stable@vger.kernel.org Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-6-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit 86475df5fb576fd10dab54b622bb1d0fc2e9ba3d Author: Dmitry Osipenko Date: Thu Jun 30 23:07:21 2022 +0300 drm/virtio: Unlock reservations on dma_resv_reserve_fences() error commit 0f877398d30e1df657a31a62f7c7de1869b072b5 upstream. Unlock reservations on dma_resv_reserve_fences() error to fix recursive locking of the reservations when this error happens. Cc: stable@vger.kernel.org Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4") Reviewed-by: Thomas Hellström Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-5-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit 846e8a76221a59a5dc33038c3ed98e2414a39a26 Author: Dmitry Osipenko Date: Thu Jun 30 23:07:20 2022 +0300 drm/virtio: Unlock reservations on virtio_gpu_object_shmem_init() error commit fdf0ff4d12cbcd76b53f27c96ce51ddca400884a upstream. Unlock reservations in the error code path of virtio_gpu_object_create() to silence debug warning splat produced by ww_mutex_destroy(&obj->lock) when GEM is released with the held lock. Cc: stable@vger.kernel.org Fixes: 30172efbfb84 ("drm/virtio: blob prep: refactor getting pages and attaching backing") Reviewed-by: Emil Velikov Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-4-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit 989164305b933af06d69bb91044dafbd01025371 Author: Dmitry Osipenko Date: Thu Jun 30 23:07:19 2022 +0300 drm/virtio: Check whether transferred 2D BO is shmem commit e473216b42aa1fd9fc6b94b608b42c210c655908 upstream. Transferred 2D BO always must be a shmem BO. Add check for that to prevent NULL dereference if userspace passes a VRAM BO. Cc: stable@vger.kernel.org Reviewed-by: Emil Velikov Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-3-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit 5653bd0200944e5803fa8e32dc36aa49931312f9 Author: Christian Marangi Date: Fri Sep 16 06:12:56 2022 +0200 dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sg commit b9d2140c3badf4107973ad77c5a0ec3075705c85 upstream. The calling convention for pre_slave_sg is to return NULL on error and provide an error log to the system. Qcom-adm instead provide error pointer when an error occur. This indirectly cause kernel panic for example for the nandc driver that checks only if the pointer returned by device_prep_slave_sg is not NULL. Returning an error pointer makes nandc think the device_prep_slave_sg function correctly completed and makes the kernel panics later in the code. While nandc is the one that makes the kernel crash, it was pointed out that the real problem is qcom-adm not following calling convention for that function. To fix this, drop returning error pointer and return NULL with an error log. Fixes: 03de6b273805 ("dmaengine: qcom-adm: stop abusing slave_id config") Fixes: 5c9f8c2dbdbe ("dmaengine: qcom: Add ADM driver") Signed-off-by: Christian Marangi Cc: stable@vger.kernel.org # v5.11+ Link: https://lore.kernel.org/r/20220916041256.7104-1-ansuelsmth@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit f1dd45a6585a1689e1e8906b3f9e302b9d40c715 Author: Christian Marangi Date: Thu Sep 15 22:48:44 2022 +0200 dmaengine: qcom-adm: fix wrong sizeof config in slave_config commit 7c8765308371be30f50c1b5b97618b731514b207 upstream. Fix broken slave_config function that uncorrectly compare the peripheral_size with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver. To fix this, compare to the size of the struct and NOT the size of the pointer. Fixes: 03de6b273805 ("dmaengine: qcom-adm: stop abusing slave_id config") Signed-off-by: Christian Marangi Cc: stable@vger.kernel.org # v5.17+ Reviewed-by: Arnd Bergmann Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20220915204844.3838-1-ansuelsmth@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 94e002aec4663b60bf177d6571674c19a28385cc Author: Dario Binacchi Date: Wed Sep 21 19:05:56 2022 +0200 dmaengine: mxs: use platform_driver_register commit 26696d4657167112a1079f86cba1739765c1360e upstream. Driver registration fails on SOC imx8mn as its supplier, the clock control module, is probed later than subsys initcall level. This driver uses platform_driver_probe which is not compatible with deferred probing and won't be probed again later if probe function fails due to clock not being available at that time. This patch replaces the use of platform_driver_probe with platform_driver_register which will allow probing the driver later again when the clock control module will be available. The __init annotation has been dropped because it is not compatible with deferred probing. The code is not executed once and its memory cannot be freed. Fixes: a580b8c5429a ("dmaengine: mxs-dma: add dma support for i.MX23/28") Co-developed-by: Michael Trimarchi Signed-off-by: Michael Trimarchi Signed-off-by: Dario Binacchi Acked-by: Sascha Hauer Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20220921170556.1055962-1-dario.binacchi@amarulasolutions.com Signed-off-by: Vinod Koul commit a2fcd90ab840a90349a14a71561a44430e964dec Author: Hamza Mahfooz Date: Wed Oct 5 11:30:38 2022 -0400 Revert "drm/amdgpu: use dirty framebuffer helper" commit 17d819e2828cacca2e4c909044eb9798ed379cd2 upstream. This reverts commit 66f99628eb24409cb8feb5061f78283c8b65f820. Unfortunately, that commit causes performance regressions on non-PSR setups. So, just revert it until FB_DAMAGE_CLIPS support can be added. Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2189 Link: https://bugzilla.kernel.org/show_bug.cgi?id=216554 Fixes: 66f99628eb2440 ("drm/amdgpu: use dirty framebuffer helper") Fixes: abbc7a3dafb91b ("drm/amdgpu: don't register a dirty callback for non-atomic") Signed-off-by: Hamza Mahfooz Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 6bf83b0f7cf79751496edecda6c7b8e6499f4a71 Author: Sagi Grimberg Date: Thu Sep 29 10:36:47 2022 +0300 nvme-multipath: fix possible hang in live ns resize with ANA access commit 72e3b8883a36e80ebfa41015c7b6926ce31ace05 upstream. When we revalidate paths as part of ns size change (as of commit e7d65803e2bb), it is possible that during the path revalidation, the only paths that is IO capable (i.e. optimized/non-optimized) are the ones that ns resize was not yet informed to the host, which will cause inflight requests to be requeued (as we have available paths but none are IO capable). These requests on the requeue list are waiting for someone to resubmit them at some point. The IO capable paths will eventually notify the ns resize change to the host, but there is nothing that will kick the requeue list to resubmit the queued requests. Fix this by always kicking the requeue list, and if no IO capable path exists, these requests will be queued again. A typical log that indicates that IOs are requeued: -- nvme nvme1: creating 4 I/O queues. nvme nvme1: new ctrl: "testnqn1" nvme nvme2: creating 4 I/O queues. nvme nvme2: mapped 4/0/0 default/read/poll queues. nvme nvme2: new ctrl: NQN "testnqn1", addr 127.0.0.1:8009 nvme nvme1: rescanning namespaces. nvme1n1: detected capacity change from 2097152 to 4194304 block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O block nvme1n1: no usable path - requeuing I/O nvme nvme2: rescanning namespaces. -- Reported-by: Yogev Cohen Fixes: e7d65803e2bb ("nvme-multipath: revalidate paths during rescan") Signed-off-by: Sagi Grimberg Cc: # v5.15+ Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 2bd2774df0ce37920b23819a860a66fdbdd90823 Author: Gaosheng Cui Date: Fri Sep 16 13:04:02 2022 +0100 nvmem: core: Fix memleak in nvmem_register() commit bd1244561fa2a4531ded40dbf09c9599084f8b29 upstream. dev_set_name will alloc memory for nvmem->dev.kobj.name in nvmem_register, when nvmem_validate_keepouts failed, nvmem's memory will be freed and return, but nobody will free memory for nvmem->dev.kobj.name, there will be memleak, so moving nvmem_validate_keepouts() after device_register() and let the device core deal with cleaning name in error cases. Fixes: de0534df9347 ("nvmem: core: fix error handling while validating keepout regions") Cc: stable@vger.kernel.org Signed-off-by: Gaosheng Cui Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220916120402.38753-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 5177bdc38eaa1c1ca6302214ab06913540cd00a2 Author: Huacai Chen Date: Tue Jul 12 15:52:55 2022 +0800 UM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK commit 16c546e148fa6d14a019431436a6f7b4087dbccd upstream. When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected, cpu_max_bits_warn() generates a runtime warning similar as below while we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) instead of NR_CPUS to iterate CPUs. [ 3.052463] ------------[ cut here ]------------ [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 [ 3.070072] Modules linked in: efivarfs autofs4 [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c [ 3.195868] ... [ 3.199917] Call Trace: [ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c [ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 [ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 [ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc [ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 [ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 [ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 [ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 [ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 [ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 [ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 [ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen Signed-off-by: Richard Weinberger Signed-off-by: Greg Kroah-Hartman commit 0a46c031d03ee0c9ebf1c7508c4bfab31ca22527 Author: Fangrui Song Date: Sun Sep 18 02:29:34 2022 -0700 riscv: Pass -mno-relax only on lld < 15.0.0 commit 3cebf80e9a0d3adcb174053be32c88a640b3344b upstream. lld since llvm:6611d58f5bbc ("[ELF] Relax R_RISCV_ALIGN"), which will be included in the 15.0.0 release, has implemented some RISC-V linker relaxation. -mno-relax is no longer needed in KBUILD_CFLAGS/KBUILD_AFLAGS to suppress R_RISCV_ALIGN which older lld can not handle: ld.lld: error: capability.c:(.fixup+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax but the .o is already compiled with -mno-relax Signed-off-by: Fangrui Song Link: https://lore.kernel.org/r/20220710071117.446112-1-maskray@google.com/ Link: https://lore.kernel.org/r/20220918092933.19943-1-palmer@rivosinc.com Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Tested-by: Nathan Chancellor Tested-by: Conor Dooley Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit c579c0aa78107f0f8c30730f8166624319e88c22 Author: Wenting Zhang Date: Fri Jul 8 16:38:22 2022 -0400 riscv: always honor the CONFIG_CMDLINE_FORCE when parsing dtb commit 10f6913c548b32ecb73801a16b120e761c6957ea upstream. When CONFIG_CMDLINE_FORCE is enabled, cmdline provided by CONFIG_CMDLINE are always used. This allows CONFIG_CMDLINE to be used regardless of the result of device tree scanning. This especially fixes the case where a device tree without the chosen node is supplied to the kernel. In such cases, early_init_dt_scan would return true. But inside early_init_dt_scan_chosen, the cmdline won't be updated as there is no chosen node in the device tree. As a result, CONFIG_CMDLINE is not copied into boot_command_line even if CONFIG_CMDLINE_FORCE is enabled. This commit allows properly update boot_command_line in this situation. Fixes: 8fd6e05c7463 ("arch: riscv: support kernel command line forcing when no DTB passed") Signed-off-by: Wenting Zhang Reviewed-by: Björn Töpel Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/PSBPR04MB399135DFC54928AB958D0638B1829@PSBPR04MB3991.apcprd04.prod.outlook.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 98c981715e8f2edb84e403826f8b3cbb456c7a5f Author: Andrew Bresticker Date: Thu Sep 15 15:37:01 2022 -0400 riscv: Make VM_WRITE imply VM_READ commit 7ab72c597356be1e7f0f3d856e54ce78527f43c8 upstream. RISC-V does not presently have write-only mappings as that PTE bit pattern is considered reserved in the privileged spec, so allow handling of read faults in VMAs that have VM_WRITE without VM_READ in order to be consistent with other architectures that have similar limitations. Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") Reviewed-by: Atish Patra Signed-off-by: Andrew Bresticker Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220915193702.2201018-2-abrestic@rivosinc.com/ Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit cf8535076464834d2647c4c6ced08eedbd77635c Author: Andrew Bresticker Date: Thu Sep 15 15:37:02 2022 -0400 riscv: Allow PROT_WRITE-only mmap() commit 9e2e6042a7ec6504fe8e366717afa2f40cf16488 upstream. Commit 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") made mmap() return EINVAL if PROT_WRITE was set wihtout PROT_READ with the justification that a write-only PTE is considered a reserved PTE permission bit pattern in the privileged spec. This check is unnecessary since we let VM_WRITE imply VM_READ on RISC-V, and it is inconsistent with other architectures that don't support write-only PTEs, creating a potential software portability issue. Just remove the check altogether and let PROT_WRITE imply PROT_READ as is the case on other architectures. Note that this also allows PROT_WRITE|PROT_EXEC mappings which were disallowed prior to the aforementioned commit; PROT_READ is implied in such mappings as well. Fixes: 2139619bcad7 ("riscv: mmap with PROT_WRITE but no PROT_READ is invalid") Reviewed-by: Atish Patra Signed-off-by: Andrew Bresticker Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220915193702.2201018-3-abrestic@rivosinc.com/ Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit df30c4feba51beeb138f3518c2421abc8cbda3c1 Author: Jisheng Zhang Date: Sat Sep 24 15:07:37 2022 +0800 riscv: vdso: fix NULL deference in vdso_join_timens() when vfork commit a8616d2dc193b6becc36b5f3cfeaa9ac7a5762f9 upstream. Testing tools/testing/selftests/timens/vfork_exec.c got below kernel log: [ 6.838454] Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000020 [ 6.842255] Oops [#1] [ 6.842871] Modules linked in: [ 6.844249] CPU: 1 PID: 64 Comm: vfork_exec Not tainted 6.0.0-rc3-rt15+ #8 [ 6.845861] Hardware name: riscv-virtio,qemu (DT) [ 6.848009] epc : vdso_join_timens+0xd2/0x110 [ 6.850097] ra : vdso_join_timens+0xd2/0x110 [ 6.851164] epc : ffffffff8000635c ra : ffffffff8000635c sp : ff6000000181fbf0 [ 6.852562] gp : ffffffff80cff648 tp : ff60000000fdb700 t0 : 3030303030303030 [ 6.853852] t1 : 0000000000000030 t2 : 3030303030303030 s0 : ff6000000181fc40 [ 6.854984] s1 : ff60000001e6c000 a0 : 0000000000000010 a1 : ffffffff8005654c [ 6.856221] a2 : 00000000ffffefff a3 : 0000000000000000 a4 : 0000000000000000 [ 6.858114] a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038 [ 6.859484] s2 : ff60000001e6c068 s3 : ff6000000108abb0 s4 : 0000000000000000 [ 6.860751] s5 : 0000000000001000 s6 : ffffffff8089dc40 s7 : ffffffff8089dc38 [ 6.862029] s8 : ffffffff8089dc30 s9 : ff60000000fdbe38 s10: 000000000000005e [ 6.863304] s11: ffffffff80cc3510 t3 : ffffffff80d1112f t4 : ffffffff80d1112f [ 6.864565] t5 : ffffffff80d11130 t6 : ff6000000181fa00 [ 6.865561] status: 0000000000000120 badaddr: 0000000000000020 cause: 000000000000000d [ 6.868046] [] timens_commit+0x38/0x11a [ 6.869089] [] timens_on_fork+0x72/0xb4 [ 6.870055] [] begin_new_exec+0x3c6/0x9f0 [ 6.871231] [] load_elf_binary+0x628/0x1214 [ 6.872304] [] bprm_execve+0x1f2/0x4e4 [ 6.873243] [] do_execveat_common+0x16e/0x1ee [ 6.874258] [] sys_execve+0x3c/0x48 [ 6.875162] [] ret_from_syscall+0x0/0x2 [ 6.877484] ---[ end trace 0000000000000000 ]--- This is because the mm->context.vdso_info is NULL in vfork case. From another side, mm->context.vdso_info either points to vdso info for RV64 or vdso info for compat, there's no need to bloat riscv's mm_context_t, we can handle the difference when setup the additional page for vdso. Signed-off-by: Jisheng Zhang Suggested-by: Palmer Dabbelt Fixes: 3092eb456375 ("riscv: compat: vdso: Add setup additional pages implementation") Link: https://lore.kernel.org/r/20220924070737.3048-1-jszhang@kernel.org Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 68a1aac5bdd5ba681d6406115ac0214d74bf498f Author: Helge Deller Date: Fri Oct 14 10:18:53 2022 +0200 parisc: Fix userspace graphics card breakage due to pgtable special bit commit 70be49f2f6223ddd2fcddb0089a40864c37e1494 upstream. Commit df24e1783e6e ("parisc: Add vDSO support") introduced the vDSO support, for which a _PAGE_SPECIAL page table flag was needed. Since we wanted to keep every page table entry in 32-bits, this patch re-used the existing - but yet unused - _PAGE_DMB flag (which triggers a hardware break if a page is accessed) to store the special bit. But when graphics card memory is mmapped into userspace, the kernel uses vm_iomap_memory() which sets the the special flag. So, with the DMB bit set, every access to the graphics memory now triggered a hardware exception and segfaulted the userspace program. Fix this breakage by dropping the DMB bit when writing the page protection bits to the CPU TLB. In addition this patch adds a small optimization: if huge pages aren't configured (which is at least the case for 32-bit kernels), then the special bit is stored in the hpage (HUGE PAGE) bit instead. That way we can skip to reset the DMB bit. Fixes: df24e1783e6e ("parisc: Add vDSO support") Cc: # 5.18+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 5017f2f7b138793e430c5b4633eb6ce52d70fcfd Author: Helge Deller Date: Fri Oct 14 10:13:55 2022 +0200 parisc: fbdev/stifb: Align graphics memory size to 4MB commit aca7c13d3bee81a968337a5515411409ae9d095d upstream. Independend of the current graphics resolution, adjust the reported graphics card memory size to the next 4MB boundary. This fixes the fbtest program which expects a naturally aligned size. Signed-off-by: Helge Deller Cc: Signed-off-by: Greg Kroah-Hartman commit 140b2b92dbefffa7f4f7211a1fd399a6e79e71c4 Author: Maciej W. Rozycki Date: Thu Sep 22 22:56:06 2022 +0100 RISC-V: Make port I/O string accessors actually work commit 9cc205e3c17d5716da7ebb7fa0c985555e95d009 upstream. Fix port I/O string accessors such as `insb', `outsb', etc. which use the physical PCI port I/O address rather than the corresponding memory mapping to get at the requested location, which in turn breaks at least accesses made by our parport driver to a PCIe parallel port such as: PCI parallel port detected: 1415:c118, I/O at 0x1000(0x1008), IRQ 20 parport0: PC-style at 0x1000 (0x1008), irq 20, using FIFO [PCSPP,TRISTATE,COMPAT,EPP,ECP] causing a memory access fault: Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000001008 Oops [#1] Modules linked in: CPU: 1 PID: 350 Comm: cat Not tainted 6.0.0-rc2-00283-g10d4879f9ef0-dirty #23 Hardware name: SiFive HiFive Unmatched A00 (DT) epc : parport_pc_fifo_write_block_pio+0x266/0x416 ra : parport_pc_fifo_write_block_pio+0xb4/0x416 epc : ffffffff80542c3e ra : ffffffff80542a8c sp : ffffffd88899fc60 gp : ffffffff80fa2700 tp : ffffffd882b1e900 t0 : ffffffd883d0b000 t1 : ffffffffff000002 t2 : 4646393043330a38 s0 : ffffffd88899fcf0 s1 : 0000000000001000 a0 : 0000000000000010 a1 : 0000000000000000 a2 : ffffffd883d0a010 a3 : 0000000000000023 a4 : 00000000ffff8fbb a5 : ffffffd883d0a001 a6 : 0000000100000000 a7 : ffffffc800000000 s2 : ffffffffff000002 s3 : ffffffff80d28880 s4 : ffffffff80fa1f50 s5 : 0000000000001008 s6 : 0000000000000008 s7 : ffffffd883d0a000 s8 : 0004000000000000 s9 : ffffffff80dc1d80 s10: ffffffd8807e4000 s11: 0000000000000000 t3 : 00000000000000ff t4 : 393044410a303930 t5 : 0000000000001000 t6 : 0000000000040000 status: 0000000200000120 badaddr: 0000000000001008 cause: 000000000000000f [] parport_pc_compat_write_block_pio+0xfe/0x200 [] parport_write+0x46/0xf8 [] lp_write+0x158/0x2d2 [] vfs_write+0x8e/0x2c2 [] ksys_write+0x52/0xc2 [] sys_write+0xe/0x16 [] ret_from_syscall+0x0/0x2 ---[ end trace 0000000000000000 ]--- For simplicity address the problem by adding PCI_IOBASE to the physical address requested in the respective wrapper macros only, observing that the raw accessors such as `__insb', `__outsb', etc. are not supposed to be used other than by said macros. Remove the cast to `long' that is no longer needed on `addr' now that it is used as an offset from PCI_IOBASE and add parentheses around `addr' needed for predictable evaluation in macro expansion. No need to make said adjustments in separate changes given that current code is gravely broken and does not ever work. Signed-off-by: Maciej W. Rozycki Fixes: fab957c11efe2 ("RISC-V: Atomic and Locking Code") Cc: stable@vger.kernel.org # v4.15+ Reviewed-by: Arnd Bergmann Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209220223080.29493@angie.orcam.me.uk Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit e08302134d59b4378b7264e195406e05eb147fcb Author: Palmer Dabbelt Date: Wed Sep 28 06:18:07 2022 -0700 RISC-V: Re-enable counter access from userspace commit 5a5294fbe0200d1327f0e089135dad77b45aa2ee upstream. These counters were part of the ISA when we froze the uABI, removing them breaks userspace. Link: https://lore.kernel.org/all/YxEhC%2FmDW1lFt36J@aurel32.net/ Fixes: e9991434596f ("RISC-V: Add perf platform driver based on SBI PMU extension") Tested-by: Conor Dooley Reviewed-by: Conor Dooley Link: https://lore.kernel.org/r/20220928131807.30386-1-palmer@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 1379df4c0697cc12050ced22284c0d2aefbc319c Author: Conor Dooley Date: Fri Jul 15 18:51:56 2022 +0100 riscv: topology: fix default topology reporting commit fbd92809997a391f28075f1c8b5ee314c225557c upstream. RISC-V has no sane defaults to fall back on where there is no cpu-map in the devicetree. Without sane defaults, the package, core and thread IDs are all set to -1. This causes user-visible inaccuracies for tools like hwloc/lstopo which rely on the sysfs cpu topology files to detect a system's topology. On a PolarFire SoC, which should have 4 harts with a thread each, lstopo currently reports: Machine (793MB total) Package L#0 NUMANode L#0 (P#0 793MB) Core L#0 L1d L#0 (32KB) + L1i L#0 (32KB) + PU L#0 (P#0) L1d L#1 (32KB) + L1i L#1 (32KB) + PU L#1 (P#1) L1d L#2 (32KB) + L1i L#2 (32KB) + PU L#2 (P#2) L1d L#3 (32KB) + L1i L#3 (32KB) + PU L#3 (P#3) Adding calls to store_cpu_topology() in {boot,smp} hart bringup code results in the correct topolgy being reported: Machine (793MB total) Package L#0 NUMANode L#0 (P#0 793MB) L1d L#0 (32KB) + L1i L#0 (32KB) + Core L#0 + PU L#0 (P#0) L1d L#1 (32KB) + L1i L#1 (32KB) + Core L#1 + PU L#1 (P#1) L1d L#2 (32KB) + L1i L#2 (32KB) + Core L#2 + PU L#2 (P#2) L1d L#3 (32KB) + L1i L#3 (32KB) + Core L#3 + PU L#3 (P#3) CC: stable@vger.kernel.org # 456797da792f: arm64: topology: move store_cpu_topology() to shared code Fixes: 03f11f03dbfe ("RISC-V: Parse cpu topology during boot.") Reported-by: Brice Goglin Link: https://github.com/open-mpi/hwloc/issues/536 Reviewed-by: Sudeep Holla Reviewed-by: Atish Patra Signed-off-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman commit 32863f41ee774d3e1fc787e07bf31bdf9d9953f9 Author: Conor Dooley Date: Fri Jul 15 18:51:55 2022 +0100 arm64: topology: move store_cpu_topology() to shared code commit 456797da792fa7cbf6698febf275fe9b36691f78 upstream. arm64's method of defining a default cpu topology requires only minimal changes to apply to RISC-V also. The current arm64 implementation exits early in a uniprocessor configuration by reading MPIDR & claiming that uniprocessor can rely on the default values. This is appears to be a hangover from prior to '3102bc0e6ac7 ("arm64: topology: Stop using MPIDR for topology information")', because the current code just assigns default values for multiprocessor systems. With the MPIDR references removed, store_cpu_topolgy() can be moved to the common arch_topology code. Reviewed-by: Sudeep Holla Acked-by: Catalin Marinas Reviewed-by: Atish Patra Signed-off-by: Conor Dooley Signed-off-by: Greg Kroah-Hartman commit 12965b43cc23e271bc9e1ced68d5c7385302c8e4 Author: Linus Walleij Date: Fri Sep 9 13:25:29 2022 +0200 regulator: qcom_rpm: Fix circular deferral regression commit 8478ed5844588703a1a4c96a004b1525fbdbdd5e upstream. On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator) does not come up if they are supplied by an SMPS-regulator. This is not very strange since the regulators are registered in a long array and the L-regulators are registered before the S-regulators, and if an L-regulator defers, it will never get around to registering the S-regulator that it needs. See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts: pm8058-regulators { (...) vdd_l13_l16-supply = <&pm8058_s4>; (...) Ooops. Fix this by moving the PM8058 S-regulators first in the array. Do the same for the PM8901 S-regulators (though this is currently not causing any problems with out device trees) so that the pattern of registration order is the same on all PMnnnn chips. Fixes: 087a1b5cdd55 ("regulator: qcom: Rework to single platform device") Cc: stable@vger.kernel.org Cc: Andy Gross Cc: Bjorn Andersson Cc: Konrad Dybcio Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 878929b56705ff0ab7a71a7f49176bb0382169ce Author: Mika Westerberg Date: Tue Aug 30 18:32:46 2022 +0300 net: thunderbolt: Enable DMA paths only after rings are enabled commit ff7cd07f306406493f7b78890475e85b6d0811ed upstream. If the other host starts sending packets early on it is possible that we are still in the middle of populating the initial Rx ring packets to the ring. This causes the tbnet_poll() to mess over the queue and causes list corruption. This happens specifically when connected with macOS as it seems start sending various IP discovery packets as soon as its side of the paths are configured. To prevent this we move the DMA path enabling to happen after we have primed the Rx ring. This makes sure no incoming packets can arrive before we are ready to handle them. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e8762009513a2dc0189490973238484670205c4f Author: Liang He Date: Fri Sep 16 23:47:08 2022 +0800 hwmon: (gsc-hwmon) Call of_node_get() before of_find_xxx API commit 7f62cf781e6567d59c8935dc8c6068ce2bb904b7 upstream. In gsc_hwmon_get_devtree_pdata(), we should call of_node_get() before the of_find_compatible_node() which will automatically call of_node_put() for the 'from' argument. Fixes: 3bce5377ef66 ("hwmon: Add Gateworks System Controller support") Signed-off-by: Liang He Co-developed-by: Mengda Chen Signed-off-by: Mengda Chen Link: https://lore.kernel.org/r/20220916154708.3084515-1-chenmengda2009@163.com Cc: stable@vger.kernel.org Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 9f329cf8c693047596a69ad31df3c8f7fac5ee41 Author: Krzysztof Kozlowski Date: Wed Sep 21 16:53:54 2022 +0200 ASoC: wcd934x: fix order of Slimbus unprepare/disable commit e96bca7eaa5747633ec638b065630ff83728982a upstream. Slimbus streams are first prepared and then enabled, so the cleanup path should reverse it. The unprepare sets stream->num_ports to 0 and frees the stream->ports. Calling disable after unprepare was not really effective (channels was not deactivated) and could lead to further issues due to making transfers on unprepared stream. Fixes: a61f3b4f476e ("ASoC: wcd934x: add support to wcd9340/wcd9341 codec") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220921145354.1683791-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 942228543a6de2b1d40c334e5d602533386772aa Author: Krzysztof Kozlowski Date: Wed Sep 21 16:53:53 2022 +0200 ASoC: wcd9335: fix order of Slimbus unprepare/disable commit ea8ef003aa53ad23e7705c5cab1c4e664faa6c79 upstream. Slimbus streams are first prepared and then enabled, so the cleanup path should reverse it. The unprepare sets stream->num_ports to 0 and frees the stream->ports. Calling disable after unprepare was not really effective (channels was not deactivated) and could lead to further issues due to making transfers on unprepared stream. Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220921145354.1683791-1-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit cc2a1297b07ab9bb8bf516e9972b889bf7141fc5 Author: Krzysztof Kozlowski Date: Sun Aug 28 11:43:39 2022 +0300 arm64: dts: qcom: sdm845-mtp: correct ADC settle time commit 209a04885ab5f76722a1671d0fbf0a5b4bccacec upstream. The PMIC's VADC property for settle time is qcom,hw-settle-time, not qcom,hw-settle-time-us. The latter is used in PMIC's TM ADC. qcom/sdm845-mtp.dtb: pmic@0: adc@3100:adc-chan@4c: 'qcom,hw-settle-time-us' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: d5e12f3823ae ("arm64: dts: qcom: sdm845: mtp: Add vadc channels and thermal zones") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Stephen Boyd Reviewed-by: Vinod Koul Reviewed-by: David Heidelberg Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220828084341.112146-13-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit b3ededa17504f468f45543734df2458493a8b373 Author: Patryk Duda Date: Tue Aug 2 17:41:28 2022 +0200 platform/chrome: cros_ec_proto: Update version on GET_NEXT_EVENT failure commit f74c7557ed0d321947e8bb4e9d47c1013f8b2227 upstream. Some EC based devices (e.g. Fingerpint MCU) can jump to RO part of the firmware (intentionally or due to device reboot). The RO part doesn't change during the device lifecycle, so it won't support newer version of EC_CMD_GET_NEXT_EVENT command. Function cros_ec_query_all() is responsible for finding maximum supported MKBP event version. It's usually called when the device is running RW part of the firmware, so the command version can be potentially higher than version supported by the RO. The problem was fixed by updating maximum supported version when the device returns EC_RES_INVALID_VERSION (mapped to -ENOPROTOOPT). That way the kernel will use highest common version supported by RO and RW. Fixes: 3300fdd630d4 ("platform/chrome: cros_ec: handle MKBP more events flag") Cc: # 5.10+ Reviewed-by: Guenter Roeck Signed-off-by: Patryk Duda Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20220802154128.21175-1-pdk@semihalf.com Signed-off-by: Greg Kroah-Hartman commit e4acbd10620ff524316c16cd322361250cb4abef Author: Zhihao Cheng Date: Fri Sep 23 21:45:52 2022 +0800 quota: Check next/prev free block number after reading from quota file commit 6c8ea8b8cd4722efd419f91ca46a2dc81b7d89a3 upstream. Following process: Init: v2_read_file_info: <3> dqi_free_blk 0 dqi_free_entry 5 dqi_blks 6 Step 1. chown bin f_a -> dquot_acquire -> v2_write_dquot: qtree_write_dquot do_insert_tree find_free_dqentry get_free_dqblk write_blk(info->dqi_blocks) // info->dqi_blocks = 6, failure. The content in physical block (corresponding to blk 6) is random. Step 2. chown root f_a -> dquot_transfer -> dqput_all -> dqput -> ext4_release_dquot -> v2_release_dquot -> qtree_delete_dquot: dquot_release remove_tree free_dqentry put_free_dqblk(6) info->dqi_free_blk = blk // info->dqi_free_blk = 6 Step 3. drop cache (buffer head for block 6 is released) Step 4. chown bin f_b -> dquot_acquire -> commit_dqblk -> v2_write_dquot: qtree_write_dquot do_insert_tree find_free_dqentry get_free_dqblk dh = (struct qt_disk_dqdbheader *)buf blk = info->dqi_free_blk // 6 ret = read_blk(info, blk, buf) // The content of buf is random info->dqi_free_blk = le32_to_cpu(dh->dqdh_next_free) // random blk Step 5. chown bin f_c -> notify_change -> ext4_setattr -> dquot_transfer: dquot = dqget -> acquire_dquot -> ext4_acquire_dquot -> dquot_acquire -> commit_dqblk -> v2_write_dquot -> dq_insert_tree: do_insert_tree find_free_dqentry get_free_dqblk blk = info->dqi_free_blk // If blk < 0 and blk is not an error code, it will be returned as dquot transfer_to[USRQUOTA] = dquot // A random negative value __dquot_transfer(transfer_to) dquot_add_inodes(transfer_to[cnt]) spin_lock(&dquot->dq_dqb_lock) // page fault , which will lead to kernel page fault: Quota error (device sda): qtree_write_dquot: Error -8000 occurred while creating quota BUG: unable to handle page fault for address: ffffffffffffe120 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 5974 Comm: chown Not tainted 6.0.0-rc1-00004 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:_raw_spin_lock+0x3a/0x90 Call Trace: dquot_add_inodes+0x28/0x270 __dquot_transfer+0x377/0x840 dquot_transfer+0xde/0x540 ext4_setattr+0x405/0x14d0 notify_change+0x68e/0x9f0 chown_common+0x300/0x430 __x64_sys_fchownat+0x29/0x40 In order to avoid accessing invalid quota memory address, this patch adds block number checking of next/prev free block read from quota file. Fetch a reproducer in [Link]. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216372 Fixes: 1da177e4c3f4152 ("Linux-2.6.12-rc2") CC: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220923134555.2623931-2-chengzhihao1@huawei.com Signed-off-by: Zhihao Cheng Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 93a3a3e745ed4627f44ffeebce417b4f314b5175 Author: Andri Yngvason Date: Wed Sep 7 15:01:59 2022 +0000 HID: multitouch: Add memory barriers commit be6e2b5734a425941fcdcdbd2a9337be498ce2cf upstream. This fixes broken atomic checks which cause a race between the release-timer and processing of hid input. I noticed that contacts were sometimes sticking, even with the "sticky fingers" quirk enabled. This fixes that problem. Cc: stable@vger.kernel.org Fixes: 9609827458c3 ("HID: multitouch: optimize the sticky fingers timer") Signed-off-by: Andri Yngvason Signed-off-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20220907150159.2285460-1-andri@yngvason.is Signed-off-by: Greg Kroah-Hartman commit 19906949ca61a121a1f78733034aaeeaef2e6a9d Author: Roberto Sassu Date: Tue Sep 20 09:59:40 2022 +0200 btf: Export bpf_dynptr definition commit 00f146413ccb6c84308e559281449755c83f54c5 upstream. eBPF dynamic pointers is a new feature recently added to upstream. It binds together a pointer to a memory area and its size. The internal kernel structure bpf_dynptr_kern is not accessible by eBPF programs in user space. They instead see bpf_dynptr, which is then translated to the internal kernel structure by the eBPF verifier. The problem is that it is not possible to include at the same time the uapi include linux/bpf.h and the vmlinux BTF vmlinux.h, as they both contain the definition of some structures/enums. The compiler complains saying that the structures/enums are redefined. As bpf_dynptr is defined in the uapi include linux/bpf.h, this makes it impossible to include vmlinux.h. However, in some cases, e.g. when using kfuncs, vmlinux.h has to be included. The only option until now was to include vmlinux.h and add the definition of bpf_dynptr directly in the eBPF program source code from linux/bpf.h. Solve the problem by using the same approach as for bpf_timer (which also follows the same scheme with the _kern suffix for the internal kernel structure). Add the following line in one of the dynamic pointer helpers, bpf_dynptr_from_mem(): BTF_TYPE_EMIT(struct bpf_dynptr); Cc: stable@vger.kernel.org Cc: Joanne Koong Fixes: 97e03f521050c ("bpf: Add verifier support for dynptrs") Signed-off-by: Roberto Sassu Acked-by: Yonghong Song Tested-by: KP Singh Link: https://lore.kernel.org/r/20220920075951.929132-3-roberto.sassu@huaweicloud.com Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 1ab6d3030652b5de0015176a5b0ad9df9b847514 Author: Alexander Aring Date: Mon Aug 15 15:43:19 2022 -0400 fs: dlm: fix invalid derefence of sb_lvbptr commit 7175e131ebba47afef47e6ac4d5bab474d1e6e49 upstream. I experience issues when putting a lkbsb on the stack and have sb_lvbptr field to a dangled pointer while not using DLM_LKF_VALBLK. It will crash with the following kernel message, the dangled pointer is here 0xdeadbeef as example: [ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef [ 102.749320] #PF: supervisor read access in kernel mode [ 102.749323] #PF: error_code(0x0000) - not-present page [ 102.749325] PGD 0 P4D 0 [ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI [ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565 [ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014 [ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10 [ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe [ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202 [ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040 [ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070 [ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001 [ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70 [ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001 [ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000 [ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0 [ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 102.749379] PKRU: 55555554 [ 102.749381] Call Trace: [ 102.749382] [ 102.749383] ? send_args+0xb2/0xd0 [ 102.749389] send_common+0xb7/0xd0 [ 102.749395] _unlock_lock+0x2c/0x90 [ 102.749400] unlock_lock.isra.56+0x62/0xa0 [ 102.749405] dlm_unlock+0x21e/0x330 [ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture] [ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture] [ 102.749419] ? preempt_count_sub+0xba/0x100 [ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture] [ 102.786186] kthread+0x10a/0x130 [ 102.786581] ? kthread_complete_and_exit+0x20/0x20 [ 102.787156] ret_from_fork+0x22/0x30 [ 102.787588] [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw [ 102.792536] CR2: 00000000deadbeef [ 102.792930] ---[ end trace 0000000000000000 ]--- This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags is set when copying the lvbptr array instead of if it's just null which fixes for me the issue. I think this patch can fix other dlm users as well, depending how they handle the init, freeing memory handling of sb_lvbptr and don't set DLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a hidden issue all the time. However with checking on DLM_LKF_VALBLK the user always need to provide a sb_lvbptr non-null value. There might be more intelligent handling between per ls lvblen, DLM_LKF_VALBLK and non-null to report the user the way how DLM API is used is wrong but can be added for later, this will only fix the current behaviour. Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 05b02a81fcca2ffd8f8855a6e00cdd2f14c90bbf Author: Alexander Aring Date: Mon Aug 15 15:43:15 2022 -0400 fs: dlm: handle -EBUSY first in lock arg validation commit 44637ca41d551d409a481117b07fa209b330fca9 upstream. During lock arg validation, first check for -EBUSY cases, then for -EINVAL cases. The -EINVAL checks look at lkb state variables which are not stable when an lkb is busy and would cause an -EBUSY result, e.g. lkb->lkb_grmode. Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit 5fe0184d47e0714fd89a8424d94960b511f241c3 Author: Alexander Aring Date: Mon Aug 15 15:43:14 2022 -0400 fs: dlm: fix race between test_bit() and queue_work() commit eef6ec9bf390e836a6c4029f3620fe49528aa1fe upstream. This patch fixes a race by using ls_cb_mutex around the bit operations and conditional code blocks for LSFL_CB_DELAY. The function dlm_callback_stop() expects to stop all callbacks and flush all currently queued onces. The set_bit() is not enough because there can still be queue_work() after the workqueue was flushed. To avoid queue_work() after set_bit(), surround both by ls_cb_mutex. Cc: stable@vger.kernel.org Signed-off-by: Alexander Aring Signed-off-by: David Teigland Signed-off-by: Greg Kroah-Hartman commit a206f7fbe9589c60fafad12884628c909ecb042f Author: Jarkko Nikula Date: Tue Sep 27 16:56:44 2022 +0300 i2c: designware: Fix handling of real but unexpected device interrupts commit 301c8f5c32c8fb79c67539bc23972dc3ef48024c upstream. Commit c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") caused a regression on certain Gigabyte motherboards for Intel Alder Lake-S where system crashes to NULL pointer dereference in i2c_dw_xfer_msg() when system resumes from S3 sleep state ("deep"). I was able to debug the issue on Gigabyte Z690 AORUS ELITE and made following notes: - Issue happens when resuming from S3 but not when resuming from "s2idle" - PCI device 00:15.0 == i2c_designware.0 is already in D0 state when system enters into pci_pm_resume_noirq() while all other i2c_designware PCI devices are in D3. Devices were runtime suspended and in D3 prior entering into suspend - Interrupt comes after pci_pm_resume_noirq() when device interrupts are re-enabled - According to register dump the interrupt really comes from the i2c_designware.0. Controller is enabled, I2C target address register points to a one detectable I2C device address 0x60 and the DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and TX_EMPTY bits are set indicating completed I2C transaction. My guess is that the firmware uses this controller to communicate with an on-board I2C device during resume but does not disable the controller before giving control to an operating system. I was told the UEFI update fixes this but never the less it revealed the driver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device is supposed to be idle and state variables are not set (especially the dev->msgs pointer which may point to NULL or stale old data). Introduce a new software status flag STATUS_ACTIVE indicating when the controller is active in driver point of view. Now treat all interrupts that occur when is not set as unexpected and mask all interrupts from the controller. Fixes: c7b79a752871 ("mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI IDs") Reported-by: Samuel Clark Link: https://bugzilla.kernel.org/show_bug.cgi?id=215907 Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Jarkko Nikula Reviewed-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit bcd98bf4093dd527354420411551ce03e84d4d60 Author: Wenchao Chen Date: Tue Oct 11 18:49:35 2022 +0800 mmc: sdhci-sprd: Fix minimum clock limit commit 6e141772e6465f937458b35ddcfd0a981b6f5280 upstream. The Spreadtrum controller supports 100KHz minimal clock rate, which means that the current value 400KHz is wrong. Unfortunately this has also lead to fail to initialize some cards, which are allowed to require 100KHz to work. So, let's fix the problem by changing the minimal supported clock rate to 100KHz. Signed-off-by: Wenchao Chen Acked-by: Adrian Hunter Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221011104935.10980-1-wenchao.chen666@gmail.com [Ulf: Clarified to commit-message] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 3035cc02a4994bcf3db5def9e982fc9e6c6e632e Author: Prathamesh Shete Date: Thu Oct 6 18:36:22 2022 +0530 mmc: sdhci-tegra: Use actual clock rate for SW tuning correction commit b78870e7f41534cc719c295d1f8809aca93aeeab upstream. Ensure tegra_host member "curr_clk_rate" holds the actual clock rate instead of requested clock rate for proper use during tuning correction algorithm. Actual clk rate may not be the same as the requested clk frequency depending on the parent clock source set. Tuning correction algorithm depends on certain parameters which are sensitive to current clk rate. If the host clk is selected instead of the actual clock rate, tuning correction algorithm may end up applying invalid correction, which could result in errors Fixes: ea8fc5953e8b ("mmc: tegra: update hw tuning process") Signed-off-by: Aniruddha TVS Rao Signed-off-by: Prathamesh Shete Acked-by: Adrian Hunter Acked-by: Thierry Reding Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221006130622.22900-4-pshete@nvidia.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ce08a030ef7be6df60c444578c249a6c68ef180b Author: Biju Das Date: Wed Sep 28 12:07:55 2022 +0100 mmc: renesas_sdhi: Fix rounding errors commit f0c00454bf78975925eccc9737faaa4d4951edbf upstream. Due to clk rounding errors on RZ/G2L platforms, it selects a clock source with a lower clock rate compared to a higher one. For eg: The rounding error (533333333 Hz / 4 * 4 = 533333332 Hz < 5333333 33 Hz) selects a clk source of 400 MHz instead of 533.333333 MHz. This patch fixes this issue by adding a margin of (1/1024) higher to the clock rate. Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Tested-by: Wolfram Sang Fixes: bb6d3fa98a41 ("clk: renesas: rcar-gen3: Switch to new SD clock handling") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220928110755.849275-1-biju.das.jz@bp.renesas.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7f7a491719bfd76179659c93993921a586c634dc Author: Anssi Hannula Date: Mon Oct 10 17:08:29 2022 +0200 can: kvaser_usb_leaf: Fix CAN state after restart commit 0be1a655fe68c8e6dcadbcbddb69cf2fb29881f5 upstream. can_restart() expects CMD_START_CHIP to set the error state to ERROR_ACTIVE as it calls netif_carrier_on() immediately afterwards. Otherwise the user may immediately trigger restart again and hit a BUG_ON() in can_restart(). Fix kvaser_usb_leaf set_mode(CMD_START_CHIP) to set the expected state. Cc: stable@vger.kernel.org Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010150829.199676-5-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit d99b9999b4d1b808d9af691a88af096d328193ea Author: Anssi Hannula Date: Mon Oct 10 17:08:28 2022 +0200 can: kvaser_usb_leaf: Fix TX queue out of sync after restart commit 455561fb618fde40558776b5b8435f9420f335db upstream. The TX queue seems to be implicitly flushed by the hardware during bus-off or bus-off recovery, but the driver does not reset the TX bookkeeping. Despite not resetting TX bookkeeping the driver still re-enables TX queue unconditionally, leading to "cannot find free context" / NETDEV_TX_BUSY errors if the TX queue was full at bus-off time. Fix that by resetting TX bookkeeping on CAN restart. Tested with 0bfd:0124 Kvaser Mini PCI Express 2xHS FW 4.18.778. Cc: stable@vger.kernel.org Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010150829.199676-4-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit b1f958afb433d3c734a77f428f5111db0571c9cf Author: Anssi Hannula Date: Mon Oct 10 17:08:26 2022 +0200 can: kvaser_usb_leaf: Fix overread with an invalid command commit 1499ecaea9d2ba68d5e18d80573b4561a8dc4ee7 upstream. For command events read from the device, kvaser_usb_leaf_read_bulk_callback() verifies that cmd->len does not exceed the size of the received data, but the actual kvaser_cmd handlers will happily read any kvaser_cmd fields without checking for cmd->len. This can cause an overread if the last cmd in the buffer is shorter than expected for the command type (with cmd->len showing the actual short size). Maximum overread seems to be 22 bytes (CMD_LEAF_LOG_MESSAGE), some of which are delivered to userspace as-is. Fix that by verifying the length of command before handling it. This issue can only occur after RX URBs have been set up, i.e. the interface has been opened at least once. Cc: stable@vger.kernel.org Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010150829.199676-2-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 3d3c7eb843d80f11759977124f003240286a8051 Author: Anssi Hannula Date: Mon Oct 10 17:08:27 2022 +0200 can: kvaser_usb: Fix use of uninitialized completion commit cd7f30e174d09a02ca2afa5ef093fb0f0352e0d8 upstream. flush_comp is initialized when CMD_FLUSH_QUEUE is sent to the device and completed when the device sends CMD_FLUSH_QUEUE_RESP. This causes completion of uninitialized completion if the device sends CMD_FLUSH_QUEUE_RESP before CMD_FLUSH_QUEUE is ever sent (e.g. as a response to a flush by a previously bound driver, or a misbehaving device). Fix that by initializing flush_comp in kvaser_usb_init_one() like the other completions. This issue is only triggerable after RX URBs have been set up, i.e. the interface has been opened at least once. Cc: stable@vger.kernel.org Fixes: aec5fb2268b7 ("can: kvaser_usb: Add support for Kvaser USB hydra family") Tested-by: Jimmy Assarsson Signed-off-by: Anssi Hannula Signed-off-by: Jimmy Assarsson Link: https://lore.kernel.org/all/20221010150829.199676-3-extja@kvaser.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 268bd6b5b8fec1d1f701a67f53c9ac86c5a38840 Author: Avri Altman Date: Wed Sep 28 12:57:44 2022 +0300 mmc: core: Add SD card quirk for broken discard commit 07d2872bf4c864eb83d034263c155746a2fb7a3b upstream. Some SD-cards from Sandisk that are SDA-6.0 compliant reports they supports discard, while they actually don't. This might cause mk2fs to fail while trying to format the card and revert it to a read-only mode. To fix this problem, let's add a card quirk (MMC_QUIRK_BROKEN_SD_DISCARD) to indicate that we shall fall-back to use the legacy erase command instead. Signed-off-by: Avri Altman Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220928095744.16455-1-avri.altman@wdc.com [Ulf: Updated the commit message] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit b52eecc616c97aee51d6a54d791ced96f749dd7e Author: Jean-Francois Le Fillatre Date: Tue Sep 27 09:34:07 2022 +0200 usb: add quirks for Lenovo OneLink+ Dock commit 37d49519b41405b08748392c6a7f193d9f77ecd2 upstream. The Lenovo OneLink+ Dock contains two VL812 USB3.0 controllers: 17ef:1018 upstream 17ef:1019 downstream These hubs suffer from two separate problems: 1) After the host system was suspended and woken up, the hubs appear to be in a random state. Some downstream ports (both internal to the built-in audio and network controllers, and external to USB sockets) may no longer be functional. The exact list of disabled ports (if any) changes from wakeup to wakeup. Ports remain in that state until the dock is power-cycled, or until the laptop is rebooted. Wakeup sources connected to the hubs (keyboard, WoL on the integrated gigabit controller) will wake the system up from suspend, but they may no longer work after wakeup (and in that case will no longer work as wakeup source in a subsequent suspend-wakeup cycle). This issue appears in the logs with messages such as: usb 1-6.1-port4: cannot disable (err = -71) usb 1-6-port2: cannot disable (err = -71) usb 1-6.1: clear tt 1 (80c0) error -71 usb 1-6-port4: cannot disable (err = -71) usb 1-6.4: PM: dpm_run_callback(): usb_dev_resume+0x0/0x10 [usbcore] returns -71 usb 1-6.4: PM: failed to resume async: error -71 usb 1-7: reset full-speed USB device number 5 using xhci_hcd usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad? usb 1-6.1-port1: cannot disable (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: cannot reset (err = -71) usb 1-6.1-port1: Cannot enable. Maybe the USB cable is bad? usb 1-6.1-port1: cannot disable (err = -71) 2) Some USB devices cannot be enumerated properly. So far I have only seen the issue with USB 3.0 devices. The same devices work without problem directly connected to the host system, to other systems or to other hubs (even when those hubs are connected to the OneLink+ dock). One very reliable reproducer is this USB 3.0 HDD enclosure: 152d:9561 JMicron Technology Corp. / JMicron USA Technology Corp. Mobius I have seen it happen sporadically with other USB 3.0 enclosures, with controllers from different manufacturers, all self-powered. Typical messages in the logs: xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 6, error -62 xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 7, error -62 usb 2-1-port4: attempt power cycle xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 8, error -62 xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command usb 2-1.4: device not accepting address 9, error -62 usb 2-1-port4: unable to enumerate USB device Through trial and error, I found that the USB_QUIRK_RESET_RESUME solved the second issue. Further testing then uncovered the first issue. Test results are summarized in this table: ======================================================================================= Settings USB2 hotplug USB3 hotplug State after waking up --------------------------------------------------------------------------------------- power/control=auto works fails broken usbcore.autosuspend=-1 works works broken OR power/control=on power/control=auto works (1) works (1) works and USB_QUIRK_RESET_RESUME power/control=on works works works and USB_QUIRK_RESET_RESUME HUB_QUIRK_DISABLE_AUTOSUSPEND works works works and USB_QUIRK_RESET_RESUME ======================================================================================= In those results, the power/control settings are applied to both hubs, both on the USB2 and USB3 side, before each test. From those results, USB_QUIRK_RESET_RESUME is required to reset the hubs properly after a suspend-wakeup cycle, and the hubs must not autosuspend to work around the USB3 issue. A secondary effect of USB_QUIRK_RESET_RESUME is to prevent the hubs' upstream links from suspending (the downstream ports can still suspend). This secondary effect is used in results (1). It is enough to solve the USB3 problem. Setting USB_QUIRK_RESET_RESUME on those hubs is the smallest patch that solves both issues. Prior to creating this patch, I have used the USB_QUIRK_RESET_RESUME via the kernel command line for over a year without noticing any side effect. Thanks to Oliver Neukum @Suse for explanations of the operations of USB_QUIRK_RESET_RESUME, and requesting more testing. Signed-off-by: Jean-Francois Le Fillatre Cc: stable Link: https://lore.kernel.org/r/20220927073407.5672-1-jflf_kernel@gmx.com Signed-off-by: Greg Kroah-Hartman commit 07a844821b74129efa88ad9dad3f238bbd8f3cfa Author: Nathan Chancellor Date: Wed Sep 28 13:19:21 2022 -0700 usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video() commit a15e17acce5aaae54243f55a7349c2225450b9bc upstream. When building s390 allmodconfig after commit 9b91a6523078 ("usb: gadget: uvc: increase worker prio to WQ_HIGHPRI"), the following error occurs: In file included from ../include/linux/string.h:253, from ../include/linux/bitmap.h:11, from ../include/linux/cpumask.h:12, from ../include/linux/smp.h:13, from ../include/linux/lockdep.h:14, from ../include/linux/rcupdate.h:29, from ../include/linux/rculist.h:11, from ../include/linux/pid.h:5, from ../include/linux/sched.h:14, from ../include/linux/ratelimit.h:6, from ../include/linux/dev_printk.h:16, from ../include/linux/device.h:15, from ../drivers/usb/gadget/function/f_uvc.c:9: In function ‘fortify_memset_chk’, inlined from ‘uvc_register_video’ at ../drivers/usb/gadget/function/f_uvc.c:424:2: ../include/linux/fortify-string.h:301:25: error: call to ‘__write_overflow_field’ declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 301 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This points to the memset() in uvc_register_video(). It is clear that the argument to sizeof() is incorrect, as uvc->vdev (a 'struct video_device') is being zeroed out but the size of uvc->video (a 'struct uvc_video') is being used as the third arugment to memset(). pahole shows that prior to commit 9b91a6523078 ("usb: gadget: uvc: increase worker prio to WQ_HIGHPRI"), 'struct video_device' and 'struct ucv_video' had the same size, meaning that the argument to sizeof() is incorrect semantically but there is no visible issue: $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+" video_device 1400 4 uvc_video 1400 3 After that change, uvc_video becomes slightly larger, meaning that the memset() will overwrite by 8 bytes: $ pahole -s build/drivers/usb/gadget/function/f_uvc.o | grep -E "(uvc_video|video_device)\s+" video_device 1400 4 uvc_video 1408 3 Fix the arugment to sizeof() so that there is no overwrite. Cc: stable@vger.kernel.org Fixes: e4ce9ed835bc ("usb: gadget: uvc: ensure the vdev is unset") Signed-off-by: Nathan Chancellor Reviewed-by: Laurent Pinchart Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/20220928201921.3152163-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 116d6a6964986ea7eb516daa36128d270f1f248d Author: Rafael Mendonca Date: Wed Sep 21 15:34:46 2022 +0300 xhci: dbc: Fix memory leak in xhci_alloc_dbc() commit d591b32e519603524a35b172156db71df9116902 upstream. If DbC is already in use, then the allocated memory for the xhci_dbc struct doesn't get freed before returning NULL, which leads to a memleak. Fixes: 534675942e90 ("xhci: dbc: refactor xhci_dbc_init()") Cc: stable@vger.kernel.org Signed-off-by: Rafael Mendonca Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20220921123450.671459-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 819f7a73c36bc4f2edf82038cbcefbcc4b7cb426 Author: Eddie James Date: Thu Sep 15 14:57:19 2022 -0500 iio: pressure: dps310: Reset chip after timeout commit 7b4ab4abcea4c0c10b25187bf2569e5a07e9a20c upstream. The DPS310 chip has been observed to get "stuck" such that pressure and temperature measurements are never indicated as "ready" in the MEAS_CFG register. The only solution is to reset the device and try again. In order to avoid continual failures, use a boolean flag to only try the reset after timeout once if errors persist. Fixes: ba6ec48e76bc ("iio: Add driver for Infineon DPS310") Cc: Signed-off-by: Eddie James Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220915195719.136812-3-eajames@linux.ibm.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit b871461eda8bdc4b6ec151f2230a1f69dd3fae1f Author: Eddie James Date: Thu Sep 15 14:57:18 2022 -0500 iio: pressure: dps310: Refactor startup procedure commit c2329717bdd3fa62f8a2f3d8d85ad0bee4556bd7 upstream. Move the startup procedure into a function, and correct a missing check on the return code for writing the PRS_CFG register. Cc: Signed-off-by: Eddie James Reviewed-by: Joel Stanley Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220915195719.136812-2-eajames@linux.ibm.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 467d556aa12cb4ae6c5d69b76f7585c402b11a15 Author: Nuno Sá Date: Mon Sep 12 10:12:21 2022 +0200 iio: adc: ad7923: fix channel readings for some variants commit f4f43f01cff2f29779343ade755191afd2581c77 upstream. Some of the supported devices have 4 or 2 LSB trailing bits that should not be taken into account. Hence we need to shift these bits out which fits perfectly on the scan type shift property. This change fixes both raw and buffered reads. Fixes: f2f7a449707e ("iio:adc:ad7923: Add support for the ad7904/ad7914/ad7924") Fixes: 851644a60d20 ("iio: adc: ad7923: Add support for the ad7908/ad7918/ad7928") Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20220912081223.173584-2-nuno.sa@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2fabf2d80ce0622dcdea840be03d0f1ccda27bbc Author: Uwe Kleine-König Date: Mon Aug 15 09:16:47 2022 +0000 iio: ltc2497: Fix reading conversion results commit 7f4f1096d5921f5d90547596f9ce80e0b924f887 upstream. After the result of the previous conversion is read the chip automatically starts a new conversion and doesn't accept new i2c transfers until this conversion is completed which makes the function return failure. So add an early return iff the programming of the new address isn't needed. Note this will not fix the problem in general, but all cases that are currently used. Once this changes we get the failure back, but this can be addressed when the need arises. Fixes: 69548b7c2c4f ("iio: adc: ltc2497: split protocol independent part in a separate module ") Reported-by: Meng Li Signed-off-by: Uwe Kleine-König Tested-by: Denys Zagorui Cc: Link: https://lore.kernel.org/r/20220815091647.1523532-1-dzagorui@cisco.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 81c68fb490e284ca91388f66f08e0b25e905b3d1 Author: Michael Hennerich Date: Tue Sep 13 09:34:12 2022 +0200 iio: dac: ad5593r: Fix i2c read protocol requirements commit 558a25f903b4af6361b7fbeea08a6446a0745653 upstream. For reliable operation across the full range of supported interface rates, the AD5593R needs a STOP condition between address write, and data read (like show in the datasheet Figure 40) so in turn i2c_smbus_read_word_swapped cannot be used. While at it, a simple helper was added to make the code simpler. Fixes: 56ca9db862bf ("iio: dac: Add support for the AD5592R/AD5593R ADCs/DACs") Signed-off-by: Michael Hennerich Signed-off-by: Nuno Sá Cc: Link: https://lore.kernel.org/r/20220913073413.140475-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 943eb0ede74ecd609fdfd3f0b83e0d237613e526 Author: Zhang Xiaoxu Date: Mon Sep 26 11:36:29 2022 +0800 cifs: Fix the error length of VALIDATE_NEGOTIATE_INFO message commit e98ecc6e94f4e6d21c06660b0f336df02836694f upstream. Commit d5c7076b772a ("smb3: add smb3.1.1 to default dialect list") extend the dialects from 3 to 4, but forget to decrease the extended length when specific the dialect, then the message length is larger than expected. This maybe leak some info through network because not initialize the message body. After apply this patch, the VALIDATE_NEGOTIATE_INFO message length is reduced from 28 bytes to 26 bytes. Fixes: d5c7076b772a ("smb3: add smb3.1.1 to default dialect list") Signed-off-by: Zhang Xiaoxu Cc: Acked-by: Paulo Alcantara (SUSE) Reviewed-by: Tom Talpey Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 56fc362eb3db6a330e1a26f88f3d6648da42de27 Author: Ronnie Sahlberg Date: Tue Sep 20 14:32:02 2022 +1000 cifs: destage dirty pages before re-reading them for cache=none commit bb44c31cdcac107344dd2fcc3bd0504a53575c51 upstream. This is the opposite case of kernel bugzilla 216301. If we mmap a file using cache=none and then proceed to update the mmapped area these updates are not reflected in a later pread() of that part of the file. To fix this we must first destage any dirty pages in the range before we allow the pread() to proceed. Cc: stable@vger.kernel.org Reviewed-by: Paulo Alcantara (SUSE) Reviewed-by: Enzo Matsumiya Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bf28cb8811b5f6eb74d5ec39b019cb40de3fedb3 Author: Gaurav Kohli Date: Wed Oct 5 22:52:59 2022 -0700 hv_netvsc: Fix race between VF offering and VF association message from host commit 365e1ececb2905f94cc10a5817c5b644a32a3ae2 upstream. During vm boot, there might be possibility that vf registration call comes before the vf association from host to vm. And this might break netvsc vf path, To prevent the same block vf registration until vf bind message comes from host. Cc: stable@vger.kernel.org Fixes: 00d7ddba11436 ("hv_netvsc: pair VF based on serial number") Reviewed-by: Haiyang Zhang Signed-off-by: Gaurav Kohli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 796da2e0eff10b7ae7d8d6bd397d5399dd28e57b Author: Pavel Begunkov Date: Tue Oct 4 03:19:08 2022 +0100 io_uring: correct pinned_vm accounting commit 42b6419d0aba47c5d8644cdc0b68502254671de5 upstream. ->mm_account should be released only after we free all registered buffers, otherwise __io_sqe_buffers_unregister() will see a NULL ->mm_account and skip locked_vm accounting. Cc: Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/6d798f65ed4ab8db3664c4d3397d4af16ca98846.1664849932.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b4293c01ee0d0ecdd3cb5801e13f62271144667a Author: Pavel Begunkov Date: Mon Oct 3 13:59:47 2022 +0100 io_uring/af_unix: defer registered files gc to io_uring release commit 0091bfc81741b8d3aeb3b7ab8636f911b2de6e80 upstream. Instead of putting io_uring's registered files in unix_gc() we want it to be done by io_uring itself. The trick here is to consider io_uring registered files for cycle detection but not actually putting them down. Because io_uring can't register other ring instances, this will remove all refs to the ring file triggering the ->release path and clean up with io_ring_ctx_free(). Cc: stable@vger.kernel.org Fixes: 6b06314c47e1 ("io_uring: add file set registration") Reported-and-tested-by: David Bouman Signed-off-by: Pavel Begunkov Signed-off-by: Thadeu Lima de Souza Cascardo [axboe: add kerneldoc comment to skb, fold in skb leak fix] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3e7f0e0f3744dc562235c1ebfd5b2277a5c0faed Author: Pavel Begunkov Date: Thu Sep 29 22:23:18 2022 +0100 io_uring/net: don't update msg_name if not provided commit 6f10ae8a155446248055c7ddd480ef40139af788 upstream. io_sendmsg_copy_hdr() may clear msg->msg_name if the userspace didn't provide it, we should retain NULL in this case. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/97d49f61b5ec76d0900df658cfde3aa59ff22121.1664486545.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit e45a798637290f2a95fc1919ae4e9eb712f2acd4 Author: Stefan Metzmacher Date: Thu Sep 29 09:39:10 2022 +0200 io_uring/net: fix fast_iov assignment in io_setup_async_msg() commit 3e4cb6ebbb2bad201c1186bc0b7e8cf41dd7f7e6 upstream. I hit a very bad problem during my tests of SENDMSG_ZC. BUG(); in first_iovec_segment() triggered very easily. The problem was io_setup_async_msg() in the partial retry case, which seems to happen more often with _ZC. iov_iter_iovec_advance() may change i->iov in order to have i->iov_offset being only relative to the first element. Which means kmsg->msg.msg_iter.iov is no longer the same as kmsg->fast_iov. But this would rewind the copy to be the start of async_msg->fast_iov, which means the internal state of sync_msg->msg.msg_iter is inconsitent. I tested with 5 vectors with length like this 4, 0, 64, 20, 8388608 and got a short writes with: - ret=2675244 min_ret=8388692 => remaining 5713448 sr->done_io=2675244 - ret=-EAGAIN => io_uring_poll_arm - ret=4911225 min_ret=5713448 => remaining 802223 sr->done_io=7586469 - ret=-EAGAIN => io_uring_poll_arm - ret=802223 min_ret=802223 => res=8388692 While this was easily triggered with SENDMSG_ZC (queued for 6.1), it was a potential problem starting with 7ba89d2af17aa879dda30f5d5d3f152e587fc551 in 5.18 for IORING_OP_RECVMSG. And also with 4c3c09439c08b03d9503df0ca4c7619c5842892e in 5.19 for IORING_OP_SENDMSG. However 257e84a5377fbbc336ff563833a8712619acce56 introduced the critical code into io_setup_async_msg() in 5.11. Fixes: 7ba89d2af17aa ("io_uring: ensure recv and recvmsg handle MSG_WAITALL correctly") Fixes: 257e84a5377fb ("io_uring: refactor sendmsg/recvmsg iov managing") Cc: stable@vger.kernel.org Signed-off-by: Stefan Metzmacher Reviewed-by: Pavel Begunkov Link: https://lore.kernel.org/r/b2e7be246e2fb173520862b0c7098e55767567a2.1664436949.git.metze@samba.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9197a1364d41b342b3b59a9c8ef7a4920deb6409 Author: Pavel Begunkov Date: Tue Sep 27 00:44:39 2022 +0100 io_uring/rw: fix unexpected link breakage commit bf68b5b34311ee57ed40749a1257a30b46127556 upstream. req->cqe.res is set in io_read() to the amount of bytes left to be done, which is used to figure out whether to fail a read or not. However, io_read() may do another without returning, and we stash the previous value into ->bytes_done but forget to update cqe.res. Then we ask a read to do strictly less than cqe.res but expect the return to be exactly cqe.res. Fix the bug by updating cqe.res for retries. Cc: stable@vger.kernel.org Reported-and-Tested-by: Beld Zhang Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3a1088440c7be98e5800267af922a67da0ef9f13.1664235732.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 8f0a63743f1efa02913d7afe564e6044e7c73102 Author: Tudor Ambarus Date: Thu Jul 28 10:40:14 2022 +0300 mtd: rawnand: atmel: Unmap streaming DMA mappings commit 1161703c9bd664da5e3b2eb1a3bb40c210e026ea upstream. Every dma_map_single() call should have its dma_unmap_single() counterpart, because the DMA address space is a shared resource and one could render the machine unusable by consuming all DMA addresses. Link: https://lore.kernel.org/lkml/13c6c9a2-6db5-c3bf-349b-4c127ad3496a@axentia.se/ Cc: stable@vger.kernel.org Fixes: f88fc122cc34 ("mtd: nand: Cleanup/rework the atmel_nand driver") Signed-off-by: Tudor Ambarus Acked-by: Alexander Dahl Reported-by: Peter Rosin Tested-by: Alexander Dahl Reviewed-by: Boris Brezillon Tested-by: Peter Rosin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220728074014.145406-1-tudor.ambarus@microchip.com Signed-off-by: Greg Kroah-Hartman commit d60ad28f750b086e06aebfcba5746f1a06d4e38d Author: Saranya Gopal Date: Tue Oct 11 10:19:16 2022 +0530 ALSA: hda/realtek: Add Intel Reference SSID to support headset keys commit 4f2e56a59b9947b3e698d3cabcb858765c12b1e8 upstream. This patch fixes the issue with 3.5mm headset keys on RPL-P platform. [ Rearranged the entry in SSID order by tiwai ] Signed-off-by: Saranya Gopal Signed-off-by: Ninad Naik Cc: Link: https://lore.kernel.org/r/20221011044916.2278867-1-saranya.gopal@intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit dc8e0bbf724fa820449c793ac0dcea7dd26bee09 Author: Luke D. Jones Date: Mon Oct 10 20:03:47 2022 +1300 ALSA: hda/realtek: Add quirk for ASUS GV601R laptop commit 2ea8e1297801f7b0220ebf6ae61a5b74ca83981e upstream. The ASUS ROG X16 (GV601R) series laptop has the same node-to-DAC pairs as early models and the G14, this includes bass speakers which are by default mapped incorrectly to the 0x06 node. Add a quirk to use the same DAC pairs as the G14. Signed-off-by: Luke D. Jones Cc: Link: https://lore.kernel.org/r/20221010070347.36883-1-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 390578404823792eda4b8445dd8c4238e3c08e00 Author: Luke D. Jones Date: Mon Oct 10 19:57:02 2022 +1300 ALSA: hda/realtek: Correct pin configs for ASUS G533Z commit 66ba7c88507344dee68ad1acbdb630473ab36114 upstream. The initial fix for ASUS G533Z was based on faulty information. This fixes the pincfg to values that have been verified with no existing module options or other hacks enabled. Enables headphone jack, and 5.1 surround. [ corrected the indent level by tiwai ] Fixes: bc2c23549ccd ("ALSA: hda/realtek: Add pincfg for ASUS G533Z HP jack") Signed-off-by: Luke D. Jones Cc: Link: https://lore.kernel.org/r/20221010065702.35190-1-luke@ljones.dev Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9108dee38d2214be7b85375851981ad9126924cd Author: Callum Osmotherly Date: Wed Oct 5 17:44:16 2022 +1030 ALSA: hda/realtek: remove ALC289_FIXUP_DUAL_SPK for Dell 5530 commit 417b9c51f59734d852e47252476fadc293ad994a upstream. After some feedback from users with Dell Precision 5530 machines, this patch reverts the previous change to add ALC289_FIXUP_DUAL_SPK. While it improved the speaker output quality, it caused the headphone jack to have an audible "pop" sound when power saving was toggled. Fixes: 1885ff13d4c4 ("ALSA: hda/realtek: Enable 4-speaker output Dell Precision 5530 laptop") Signed-off-by: Callum Osmotherly Cc: Link: https://lore.kernel.org/r/Yz0uyN1zwZhnyRD6@piranha Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3965d9b056676b3538f9835752c45c49d630558b Author: Takashi Iwai Date: Fri Sep 30 12:01:29 2022 +0200 ALSA: usb-audio: Fix NULL dererence at error path commit 568be8aaf8a535f79c4db76cabe17b035aa2584d upstream. At an error path to release URB buffers and contexts, the driver might hit a NULL dererence for u->urb pointer, when u->buffer_size has been already set but the actual URB allocation failed. Fix it by adding the NULL check of urb. Also, make sure that buffer_size is cleared after the error path or the close. Cc: Reported-by: Sabri N. Ferreiro Link: https://lore.kernel.org/r/CAKG+3NRjTey+fFfUEGwuxL-pi_=T4cUskYG9OzpzHytF+tzYng@mail.gmail.com Link: https://lore.kernel.org/r/20220930100129.19445-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit faa8c1ed77d0169955b9b3516b714cc5fb512f27 Author: Takashi Iwai Date: Fri Sep 30 12:01:51 2022 +0200 ALSA: usb-audio: Fix potential memory leaks commit 6382da0828995af87aa8b8bef28cc61aceb4aff3 upstream. When the driver hits -ENOMEM at allocating a URB or a buffer, it aborts and goes to the error path that releases the all previously allocated resources. However, when -ENOMEM hits at the middle of the sync EP URB allocation loop, the partially allocated URBs might be left without released, because ep->nurbs is still zero at that point. Fix it by setting ep->nurbs at first, so that the error handler loops over the full URB list. Cc: Link: https://lore.kernel.org/r/20220930100151.19461-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a394f0197dd0d87ec858d67256d9f8c626001559 Author: Takashi Iwai Date: Tue Oct 11 09:01:46 2022 +0200 ALSA: rawmidi: Drop register_mutex in snd_rawmidi_free() commit a70aef7982b012e86dfd39fbb235e76a21ae778a upstream. The register_mutex taken around the dev_unregister callback call in snd_rawmidi_free() may potentially lead to a mutex deadlock, when OSS emulation and a hot unplug are involved. Since the mutex doesn't protect the actual race (as the registration itself is already protected by another means), let's drop it. Link: https://lore.kernel.org/r/CAB7eexJP7w1B0mVgDF0dQ+gWor7UdkiwPczmL7pn91xx8xpzOA@mail.gmail.com Cc: Link: https://lore.kernel.org/r/20221011070147.7611-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a74003b10bbb956b3dda63d30e1e13565addfabb Author: Takashi Iwai Date: Tue Oct 11 09:01:47 2022 +0200 ALSA: oss: Fix potential deadlock at unregistration commit 97d917879d7f92df09c3f21fd54609a8bcd654b2 upstream. We took sound_oss_mutex around the calls of unregister_sound_special() at unregistering OSS devices. This may, however, lead to a deadlock, because we manage the card release via the card's device object, and the release may happen at unregister_sound_special() call -- which will take sound_oss_mutex again in turn. Although the deadlock might be fixed by relaxing the rawmidi mutex in the previous commit, it's safer to move unregister_sound_special() calls themselves out of the sound_oss_mutex, too. The call is race-safe as the function has a spinlock protection by itself. Link: https://lore.kernel.org/r/CAB7eexJP7w1B0mVgDF0dQ+gWor7UdkiwPczmL7pn91xx8xpzOA@mail.gmail.com Cc: Link: https://lore.kernel.org/r/20221011070147.7611-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit eb9af45d0a4a6199acf371aa4806a777489aef7f Author: Sasha Levin Date: Sat Oct 15 07:18:38 2022 -0400 Revert "fs: check FMODE_LSEEK to control internal pipe splicing" This reverts commit fd0a6e99b61e6c08fa5cf585d54fd956f70c73a6. Which was upstream commit 97ef77c52b789ec1411d360ed99dca1efe4b2c81. The commit is missing dependencies and breaks NFS tests, remove it for now. Reported-by: Saeed Mirzamohammadi Signed-off-by: Sasha Levin