commit dab0efee14dd1ca363ef5ceae36018b72fc52037 Author: Greg Kroah-Hartman Date: Sat Nov 26 09:27:56 2022 +0100 Linux 6.0.10 Link: https://lore.kernel.org/r/20221123084625.457073469@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Fenil Jain Tested-by: Ronald Warsow Tested-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya =20 Tested-by: Sudip Mukherjee Tested-by: Justin M. Forbes Link: https://lore.kernel.org/r/20221125075804.064161337@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman commit 785b2af9654b8beac55644e36da0085c5d776361 Author: Hawkins Jiawei Date: Thu Sep 1 00:09:38 2022 +0800 ntfs: check overflow when iterating ATTR_RECORDs commit 63095f4f3af59322bea984a6ae44337439348fe0 upstream. Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the next ATTR_RECORD from end address of current ATTR_RECORD, through current ATTR_RECORD length field. The problem is that during iteration, when kernel calculates the end address of current ATTR_RECORD, kernel may trigger an integer overflow bug in executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. This may wrap, leading to a forever iteration on 32bit systems. This patch solves it by adding some checks on calculating end address of current ATTR_RECORD during iteration. Link: https://lkml.kernel.org/r/20220831160935.3409-4-yin31149@gmail.com Link: https://lore.kernel.org/all/20220827105842.GM2030@kadam/ Signed-off-by: Hawkins Jiawei Suggested-by: Dan Carpenter Cc: Anton Altaparmakov Cc: chenxiaosong (A) Cc: syzkaller-bugs Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit e9b64d1faa58a4ae3454acbf9c80483dd16692d4 Author: Hawkins Jiawei Date: Thu Sep 1 00:09:36 2022 +0800 ntfs: fix out-of-bounds read in ntfs_attr_find() commit 36a4d82dddbbd421d2b8e79e1cab68c8126d5075 upstream. Kernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). To ensure access on these ATTR_RECORDs are within bounds, kernel will do some checking during iteration. The problem is that during checking whether ATTR_RECORD's name is within bounds, kernel will dereferences the ATTR_RECORD name_offset field, before checking this ATTR_RECORD strcture is within bounds. This problem may result out-of-bounds read in ntfs_attr_find(), reported by Syzkaller: ================================================================== BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607 [...] Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854 mount_bdev+0x34d/0x410 fs/super.c:1400 legacy_get_tree+0x105/0x220 fs/fs_context.c:610 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] The buggy address belongs to the physical page: page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350 head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140 raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== This patch solves it by moving the ATTR_RECORD strcture's bounds checking earlier, then checking whether ATTR_RECORD's name is within bounds. What's more, this patch also add some comments to improve its maintainability. Link: https://lkml.kernel.org/r/20220831160935.3409-3-yin31149@gmail.com Link: https://lore.kernel.org/all/1636796c-c85e-7f47-e96f-e074fee3c7d3@huawei.com/ Link: https://groups.google.com/g/syzkaller-bugs/c/t_XdeKPGTR4/m/LECAuIGcBgAJ Signed-off-by: chenxiaosong (A) Signed-off-by: Dan Carpenter Signed-off-by: Hawkins Jiawei Reported-by: syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com Tested-by: syzbot+5f8dcabe4a3b2c51c607@syzkaller.appspotmail.com Cc: Anton Altaparmakov Cc: syzkaller-bugs Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 4863f815463034f588a035cfd99cdca97a4f1069 Author: Hawkins Jiawei Date: Thu Sep 1 00:09:34 2022 +0800 ntfs: fix use-after-free in ntfs_attr_find() commit d85a1bec8e8d552ab13163ca1874dcd82f3d1550 upstream. Patch series "ntfs: fix bugs about Attribute", v2. This patchset fixes three bugs relative to Attribute in record: Patch 1 adds a sanity check to ensure that, attrs_offset field in first mft record loading from disk is within bounds. Patch 2 moves the ATTR_RECORD's bounds checking earlier, to avoid dereferencing ATTR_RECORD before checking this ATTR_RECORD is within bounds. Patch 3 adds an overflow checking to avoid possible forever loop in ntfs_attr_find(). Without patch 1 and patch 2, the kernel triggersa KASAN use-after-free detection as reported by Syzkaller. Although one of patch 1 or patch 2 can fix this, we still need both of them. Because patch 1 fixes the root cause, and patch 2 not only fixes the direct cause, but also fixes the potential out-of-bounds bug. This patch (of 3): Syzkaller reported use-after-free read as follows: ================================================================== BUG: KASAN: use-after-free in ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 Read of size 2 at addr ffff88807e352009 by task syz-executor153/3607 [...] Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report+0xb1/0x1e0 mm/kasan/report.c:495 ntfs_attr_find+0xc02/0xce0 fs/ntfs/attrib.c:597 ntfs_attr_lookup+0x1056/0x2070 fs/ntfs/attrib.c:1193 ntfs_read_inode_mount+0x89a/0x2580 fs/ntfs/inode.c:1845 ntfs_fill_super+0x1799/0x9320 fs/ntfs/super.c:2854 mount_bdev+0x34d/0x410 fs/super.c:1400 legacy_get_tree+0x105/0x220 fs/fs_context.c:610 vfs_get_tree+0x89/0x2f0 fs/super.c:1530 do_new_mount fs/namespace.c:3040 [inline] path_mount+0x1326/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] The buggy address belongs to the physical page: page:ffffea0001f8d400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x7e350 head:ffffea0001f8d400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0xfff00000010200(slab|head|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000010200 0000000000000000 dead000000000122 ffff888011842140 raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88807e351f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88807e351f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88807e352000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88807e352080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88807e352100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Kernel will loads $MFT/$DATA's first mft record in ntfs_read_inode_mount(). Yet the problem is that after loading, kernel doesn't check whether attrs_offset field is a valid value. To be more specific, if attrs_offset field is larger than bytes_allocated field, then it may trigger the out-of-bounds read bug(reported as use-after-free bug) in ntfs_attr_find(), when kernel tries to access the corresponding mft record's attribute. This patch solves it by adding the sanity check between attrs_offset field and bytes_allocated field, after loading the first mft record. Link: https://lkml.kernel.org/r/20220831160935.3409-1-yin31149@gmail.com Link: https://lkml.kernel.org/r/20220831160935.3409-2-yin31149@gmail.com Signed-off-by: Hawkins Jiawei Cc: Anton Altaparmakov Cc: ChenXiaoSong Cc: syzkaller-bugs Cc: Dan Carpenter Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 2e5399879024fedd6cdc41f73fbf9bbe7208f899 Author: Jiri Olsa Date: Fri Sep 16 09:19:14 2022 +0200 bpf: Prevent bpf program recursion for raw tracepoint probes commit 05b24ff9b2cfabfcfd951daaa915a036ab53c9e1 upstream. We got report from sysbot [1] about warnings that were caused by bpf program attached to contention_begin raw tracepoint triggering the same tracepoint by using bpf_trace_printk helper that takes trace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ... The can be reproduced by attaching bpf program as raw tracepoint on contention_begin tracepoint. The bpf prog calls bpf_trace_printk helper. Then by running perf bench the spin lock code is forced to take slow path and call contention_begin tracepoint. Fixing this by skipping execution of the bpf program if it's already running, Using bpf prog 'active' field, which is being currently used by trampoline programs for the same reason. Moving bpf_prog_inc_misses_counter to syscall.c because trampoline.c is compiled in just for CONFIG_BPF_JIT option. Reviewed-by: Stanislav Fomichev Reported-by: syzbot+2251879aa068ad9c960d@syzkaller.appspotmail.com [1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t Signed-off-by: Jiri Olsa Link: https://lore.kernel.org/r/20220916071914.7156-1-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 717b9b4f38703d7f5293059e3a242d16f76fa045 Author: Dominique Martinet Date: Sun Sep 4 20:17:49 2022 +0900 net/9p: use a dedicated spinlock for trans_fd commit 296ab4a813841ba1d5f40b03190fd1bd8f25aab0 upstream. Shamelessly copying the explanation from Tetsuo Handa's suggested patch[1] (slightly reworded): syzbot is reporting inconsistent lock state in p9_req_put()[2], for p9_tag_remove() from p9_req_put() from IRQ context is using spin_lock_irqsave() on "struct p9_client"->lock but trans_fd (not from IRQ context) is using spin_lock(). Since the locks actually protect different things in client.c and in trans_fd.c, just replace trans_fd.c's lock by a new one specific to the transport (client.c's protect the idr for fid/tag allocations, while trans_fd.c's protects its own req list and request status field that acts as the transport's state machine) Link: https://lore.kernel.org/r/20220904112928.1308799-1-asmadeus@codewreck.org Link: https://lkml.kernel.org/r/2470e028-9b05-2013-7198-1fdad071d999@I-love.SAKURA.ne.jp [1] Link: https://syzkaller.appspot.com/bug?extid=2f20b523930c32c160cc [2] Reported-by: syzbot Reported-by: Tetsuo Handa Reviewed-by: Christian Schoenebeck Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 80ec940ee52feec55200d116a4987511524dc928 Author: Alexander Potapenko Date: Thu Sep 15 17:04:16 2022 +0200 mm: fs: initialize fsdata passed to write_begin/write_end interface commit 1468c6f4558b1bcd92aa0400f2920f9dc7588402 upstream. Functions implementing the a_ops->write_end() interface accept the `void *fsdata` parameter that is supposed to be initialized by the corresponding a_ops->write_begin() (which accepts `void **fsdata`). However not all a_ops->write_begin() implementations initialize `fsdata` unconditionally, so it may get passed uninitialized to a_ops->write_end(), resulting in undefined behavior. Fix this by initializing fsdata with NULL before the call to write_begin(), rather than doing so in all possible a_ops implementations. This patch covers only the following cases found by running x86 KMSAN under syzkaller: - generic_perform_write() - cont_expand_zero() and generic_cont_expand_simple() - page_symlink() Other cases of passing uninitialized fsdata may persist in the codebase. Link: https://lkml.kernel.org/r/20220915150417.722975-43-glider@google.com Signed-off-by: Alexander Potapenko Cc: Alexander Viro Cc: Alexei Starovoitov Cc: Andrey Konovalov Cc: Andrey Konovalov Cc: Andy Lutomirski Cc: Arnd Bergmann Cc: Borislav Petkov Cc: Christoph Hellwig Cc: Christoph Lameter Cc: David Rientjes Cc: Dmitry Vyukov Cc: Eric Biggers Cc: Eric Biggers Cc: Eric Dumazet Cc: Greg Kroah-Hartman Cc: Herbert Xu Cc: Ilya Leoshkevich Cc: Ingo Molnar Cc: Jens Axboe Cc: Joonsoo Kim Cc: Kees Cook Cc: Marco Elver Cc: Mark Rutland Cc: Matthew Wilcox Cc: Michael S. Tsirkin Cc: Pekka Enberg Cc: Peter Zijlstra Cc: Petr Mladek Cc: Stephen Rothwell Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vegard Nossum Cc: Vlastimil Babka Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman commit 96c8e90da1ce43eb9a156c3a3425955306e77deb Author: Mathieu Desnoyers Date: Wed Nov 2 09:06:35 2022 -0400 rseq: Use pr_warn_once() when deprecated/unknown ABI flags are encountered commit 448dca8c88755b768552e19bd1618be34ef6d1ff upstream. These commits use WARN_ON_ONCE() and kill the offending processes when deprecated and unknown flags are encountered: commit c17a6ff93213 ("rseq: Kill process when unknown flags are encountered in ABI structures") commit 0190e4198e47 ("rseq: Deprecate RSEQ_CS_FLAG_NO_RESTART_ON_* flags") The WARN_ON_ONCE() triggered by userspace input prevents use of Syzkaller to fuzz the rseq system call. Replace this WARN_ON_ONCE() by pr_warn_once() messages which contain actually useful information. Reported-by: Mark Rutland Signed-off-by: Mathieu Desnoyers Signed-off-by: Peter Zijlstra (Intel) Acked-by: Mark Rutland Acked-by: Paul E. McKenney Link: https://lkml.kernel.org/r/20221102130635.7379-1-mathieu.desnoyers@efficios.com Signed-off-by: Greg Kroah-Hartman commit 46a0d79486fdee5386c6625055e999d2e2df0477 Author: Hawkins Jiawei Date: Tue Sep 27 07:34:59 2022 +0800 wifi: wext: use flex array destination for memcpy() commit e3e6e1d16a4cf7b63159ec71774e822194071954 upstream. Syzkaller reports buffer overflow false positive as follows: ------------[ cut here ]------------ memcpy: detected field-spanning write (size 8) of single field "&compat_event->pointer" at net/wireless/wext-core.c:623 (size 4) WARNING: CPU: 0 PID: 3607 at net/wireless/wext-core.c:623 wireless_send_event+0xab5/0xca0 net/wireless/wext-core.c:623 Modules linked in: CPU: 1 PID: 3607 Comm: syz-executor659 Not tainted 6.0.0-rc6-next-20220921-syzkaller #0 [...] Call Trace: ioctl_standard_call+0x155/0x1f0 net/wireless/wext-core.c:1022 wireless_process_ioctl+0xc8/0x4c0 net/wireless/wext-core.c:955 wext_ioctl_dispatch net/wireless/wext-core.c:988 [inline] wext_ioctl_dispatch net/wireless/wext-core.c:976 [inline] wext_handle_ioctl+0x26b/0x280 net/wireless/wext-core.c:1049 sock_ioctl+0x285/0x640 net/socket.c:1220 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] Wireless events will be sent on the appropriate channels in wireless_send_event(). Different wireless events may have different payload structure and size, so kernel uses **len** and **cmd** field in struct __compat_iw_event as wireless event common LCP part, uses **pointer** as a label to mark the position of remaining different part. Yet the problem is that, **pointer** is a compat_caddr_t type, which may be smaller than the relative structure at the same position. So during wireless_send_event() tries to parse the wireless events payload, it may trigger the memcpy() run-time destination buffer bounds checking when the relative structure's data is copied to the position marked by **pointer**. This patch solves it by introducing flexible-array field **ptr_bytes**, to mark the position of the wireless events remaining part next to LCP part. What's more, this patch also adds **ptr_len** variable in wireless_send_event() to improve its maintainability. Reported-and-tested-by: syzbot+473754e5af963cf014cf@syzkaller.appspotmail.com Link: https://lore.kernel.org/all/00000000000070db2005e95a5984@google.com/ Suggested-by: Kees Cook Reviewed-by: Kees Cook Signed-off-by: Hawkins Jiawei Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit aff4eb16f589c3af322a2582044bca365381fcd6 Author: Kees Cook Date: Fri Sep 2 21:37:49 2022 -0700 netlink: Bounds-check struct nlmsgerr creation commit 710d21fdff9a98d621cd4e64167f3ef8af4e2fd1 upstream. In preparation for FORTIFY_SOURCE doing bounds-check on memcpy(), switch from __nlmsg_put to nlmsg_put(), and explain the bounds check for dealing with the memcpy() across a composite flexible array struct. Avoids this future run-time warning: memcpy: detected field-spanning write (size 32) of single field "&errmsg->msg" at net/netlink/af_netlink.c:2447 (size 16) Cc: Jakub Kicinski Cc: Pablo Neira Ayuso Cc: Jozsef Kadlecsik Cc: Florian Westphal Cc: "David S. Miller" Cc: Eric Dumazet Cc: Paolo Abeni Cc: syzbot Cc: netfilter-devel@vger.kernel.org Cc: coreteam@netfilter.org Cc: netdev@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220901071336.1418572-1-keescook@chromium.org Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5af16182c5639349415118e9e9aecd8355f7a08b Author: Tetsuo Handa Date: Sat Aug 27 00:27:46 2022 +0900 9p/trans_fd: always use O_NONBLOCK read/write commit ef575281b21e9a34dfae544a187c6aac2ae424a9 upstream. syzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is failing to interrupt already started kernel_read() from p9_fd_read() from p9_read_work() and/or kernel_write() from p9_fd_write() from p9_write_work() requests. Since p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not need to interrupt kernel_read()/kernel_write(). However, since p9_fd_open() does not set O_NONBLOCK flag, but pipe blocks unless signal is pending, p9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when the file descriptor refers to a pipe. In other words, pipe file descriptor needs to be handled as if socket file descriptor. We somehow need to interrupt kernel_read()/kernel_write() on pipes. A minimal change, which this patch is doing, is to set O_NONBLOCK flag from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing of regular files. But this approach changes O_NONBLOCK flag on userspace- supplied file descriptors (which might break userspace programs), and O_NONBLOCK flag could be changed by userspace. It would be possible to set O_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still remains small race window for clearing O_NONBLOCK flag. If we don't want to manipulate O_NONBLOCK flag, we might be able to surround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING) and recalc_sigpending(). Since p9_read_work()/p9_write_work() works are processed by kernel threads which process global system_wq workqueue, signals could not be delivered from remote threads when p9_mux_poll_stop() from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling set_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be needed if we count on signals for making kernel_read()/kernel_write() non-blocking. Link: https://lkml.kernel.org/r/345de429-a88b-7097-d177-adecf9fed342@I-love.SAKURA.ne.jp Link: https://syzkaller.appspot.com/bug?extid=8b41a1365f1106fd0f33 [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Tested-by: syzbot Reviewed-by: Christian Schoenebeck [Dominique: add comment at Christian's suggestion] Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 59400a5120f4a0b5a6e26fffc501556218a3e319 Author: Andreas Gruenbacher Date: Fri Aug 26 15:12:17 2022 +0200 gfs2: Switch from strlcpy to strscpy commit 204c0300c4e99707e9fb6e57840aa1127060e63f upstream. Switch from strlcpy to strscpy and make sure that @count is the size of the smaller of the source and destination buffers. This prevents reading beyond the end of the source buffer when the source string isn't null terminated. Found by a modified version of syzkaller. Suggested-by: Wolfram Sang Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 16670534c7cff1acd918a6a5ec751b14e7436b76 Author: Andrew Price Date: Wed Aug 17 13:22:00 2022 +0100 gfs2: Check sb_bsize_shift after reading superblock commit 670f8ce56dd0632dc29a0322e188cc73ce3c6b92 upstream. Fuzzers like to scribble over sb_bsize_shift but in reality it's very unlikely that this field would be corrupted on its own. Nevertheless it should be checked to avoid the possibility of messy mount errors due to bad calculations. It's always a fixed value based on the block size so we can just check that it's the expected value. Tested with: mkfs.gfs2 -O -p lock_nolock /dev/vdb for i in 0 -1 64 65 32 33; do gfs2_edit -p sb field sb_bsize_shift $i /dev/vdb mount /dev/vdb /mnt/test && umount /mnt/test done Before this patch we get a withdraw after [ 76.413681] gfs2: fsid=loop0.0: fatal: invalid metadata block [ 76.413681] bh = 19 (type: exp=5, found=4) [ 76.413681] function = gfs2_meta_buffer, file = fs/gfs2/meta_io.c, line = 492 and with UBSAN configured we also get complaints like [ 76.373395] UBSAN: shift-out-of-bounds in fs/gfs2/ops_fstype.c:295:19 [ 76.373815] shift exponent 4294967287 is too large for 64-bit type 'long unsigned int' After the patch, these complaints don't appear, mount fails immediately and we get an explanation in dmesg. Reported-by: syzbot+dcf33a7aae997956fe06@syzkaller.appspotmail.com Signed-off-by: Andrew Price Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 612c977f5d481f551d03d83d0aef588845c1300c Author: Dominique Martinet Date: Wed Aug 17 14:58:44 2022 +0900 9p: trans_fd/p9_conn_cancel: drop client lock earlier commit 52f1c45dde9136f964d63a77d19826c8a74e2c7f upstream. syzbot reported a double-lock here and we no longer need this lock after requests have been moved off to local list: just drop the lock earlier. Link: https://lkml.kernel.org/r/20220904064028.1305220-1-asmadeus@codewreck.org Reported-by: syzbot+50f7e8d06c3768dd97f3@syzkaller.appspotmail.com Signed-off-by: Dominique Martinet Tested-by: Schspa Shi Signed-off-by: Greg Kroah-Hartman commit d76f46f47dfde220712d1420ee5dbc546c8fc674 Author: Eiichi Tsukata Date: Fri Oct 28 09:26:31 2022 +0000 KVM: x86/xen: Fix eventfd error handling in kvm_xen_eventfd_assign() commit 7353633814f6e5b4899fb9ee1483709d6bb0e1cd upstream. Should not call eventfd_ctx_put() in case of error. Fixes: 2fd6df2f2b47 ("KVM: x86/xen: intercept EVTCHNOP_send from guests") Reported-by: syzbot+6f0c896c5a9449a10ded@syzkaller.appspotmail.com Signed-off-by: Eiichi Tsukata Message-Id: <20221028092631.117438-1-eiichi.tsukata@nutanix.com> [Introduce new goto target instead. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 2526ac6b0f5a9b38e7e9073e37141cf78408078d Author: Eric Dumazet Date: Wed Oct 12 13:34:12 2022 +0000 kcm: avoid potential race in kcm_tx_work commit ec7eede369fe5b0d085ac51fdbb95184f87bfc6c upstream. syzbot found that kcm_tx_work() could crash [1] in: /* Primarily for SOCK_SEQPACKET sockets */ if (likely(sk->sk_socket) && test_bit(SOCK_NOSPACE, &sk->sk_socket->flags)) { <<*>> clear_bit(SOCK_NOSPACE, &sk->sk_socket->flags); sk->sk_write_space(sk); } I think the reason is that another thread might concurrently run in kcm_release() and call sock_orphan(sk) while sk is not locked. kcm_tx_work() find sk->sk_socket being NULL. [1] BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:86 [inline] BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] BUG: KASAN: null-ptr-deref in kcm_tx_work+0xff/0x160 net/kcm/kcmsock.c:742 Write of size 8 at addr 0000000000000008 by task kworker/u4:3/53 CPU: 0 PID: 53 Comm: kworker/u4:3 Not tainted 5.19.0-rc3-next-20220621-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: kkcmd kcm_tx_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 kasan_report+0xbe/0x1f0 mm/kasan/report.c:495 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189 instrument_atomic_write include/linux/instrumented.h:86 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] kcm_tx_work+0xff/0x160 net/kcm/kcmsock.c:742 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Reported-by: syzbot Signed-off-by: Eric Dumazet Cc: Tom Herbert Link: https://lore.kernel.org/r/20221012133412.519394-1-edumazet@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1b639be27cbf428a5ca01dcf8b5d654194c956f8 Author: Eric Dumazet Date: Tue Oct 11 15:07:48 2022 -0700 tcp: cdg: allow tcp_cdg_release() to be called multiple times commit 72e560cb8c6f80fc2b4afc5d3634a32465e13a51 upstream. Apparently, mptcp is able to call tcp_disconnect() on an already disconnected flow. This is generally fine, unless current congestion control is CDG, because it might trigger a double-free [1] Instead of fixing MPTCP, and future bugs, we can make tcp_disconnect() more resilient. [1] BUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline] BUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567 CPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: events mptcp_worker Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:317 [inline] print_report.cold+0x2ba/0x719 mm/kasan/report.c:433 kasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462 ____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145 __mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327 mptcp_do_fastclose net/mptcp/protocol.c:2592 [inline] mptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627 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 Allocated by task 3671: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track mm/kasan/common.c:45 [inline] set_alloc_info mm/kasan/common.c:437 [inline] ____kasan_kmalloc mm/kasan/common.c:516 [inline] ____kasan_kmalloc mm/kasan/common.c:475 [inline] __kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525 kmalloc_array include/linux/slab.h:640 [inline] kcalloc include/linux/slab.h:671 [inline] tcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380 tcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193 tcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline] tcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391 do_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513 tcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801 mptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844 __sys_setsockopt+0x2d6/0x690 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 [inline] __se_sys_setsockopt net/socket.c:2260 [inline] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 16: kasan_save_stack+0x1e/0x40 mm/kasan/common.c:38 kasan_set_track+0x21/0x30 mm/kasan/common.c:45 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370 ____kasan_slab_free mm/kasan/common.c:367 [inline] ____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329 kasan_slab_free include/linux/kasan.h:200 [inline] slab_free_hook mm/slub.c:1759 [inline] slab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785 slab_free mm/slub.c:3539 [inline] kfree+0xe2/0x580 mm/slub.c:4567 tcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226 tcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254 tcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969 inet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157 tcp_done+0x23b/0x340 net/ipv4/tcp.c:4649 tcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624 tcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525 tcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759 ip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439 ip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] ip6_input+0x9c/0xd0 net/ipv6/ip6_input.c:493 dst_input include/net/dst.h:455 [inline] ip6_rcv_finish+0x193/0x2c0 net/ipv6/ip6_input.c:79 ip_sabotage_in net/bridge/br_netfilter_hooks.c:874 [inline] ip_sabotage_in+0x1fa/0x260 net/bridge/br_netfilter_hooks.c:865 nf_hook_entry_hookfn include/linux/netfilter.h:142 [inline] nf_hook_slow+0xc5/0x1f0 net/netfilter/core.c:614 nf_hook.constprop.0+0x3ac/0x650 include/linux/netfilter.h:257 NF_HOOK include/linux/netfilter.h:300 [inline] ipv6_rcv+0x9e/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5485 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599 netif_receive_skb_internal net/core/dev.c:5685 [inline] netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744 NF_HOOK include/linux/netfilter.h:302 [inline] NF_HOOK include/linux/netfilter.h:296 [inline] br_pass_frame_up+0x303/0x410 net/bridge/br_input.c:68 br_handle_frame_finish+0x909/0x1aa0 net/bridge/br_input.c:199 br_nf_hook_thresh+0x2f8/0x3d0 net/bridge/br_netfilter_hooks.c:1041 br_nf_pre_routing_finish_ipv6+0x695/0xef0 net/bridge/br_netfilter_ipv6.c:207 NF_HOOK include/linux/netfilter.h:302 [inline] br_nf_pre_routing_ipv6+0x417/0x7c0 net/bridge/br_netfilter_ipv6.c:237 br_nf_pre_routing+0x1496/0x1fe0 net/bridge/br_netfilter_hooks.c:507 nf_hook_entry_hookfn include/linux/netfilter.h:142 [inline] nf_hook_bridge_pre net/bridge/br_input.c:255 [inline] br_handle_frame+0x9c9/0x12d0 net/bridge/br_input.c:399 __netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379 __netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599 process_backlog+0x3a0/0x7c0 net/core/dev.c:5927 __napi_poll+0xb3/0x6d0 net/core/dev.c:6494 napi_poll net/core/dev.c:6561 [inline] net_rx_action+0x9c1/0xd90 net/core/dev.c:6672 __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 Fixes: 2b0a8c9eee81 ("tcp: add CDG congestion control") Reported-by: syzbot Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2b055c719d8f94c15ec9b7659978133030c6a353 Author: Eric Dumazet Date: Fri Oct 7 15:57:43 2022 -0700 macvlan: enforce a consistent minimal mtu commit b64085b00044bdf3cd1c9825e9ef5b2e0feae91a upstream. macvlan should enforce a minimal mtu of 68, even at link creation. This patch avoids the current behavior (which could lead to crashes in ipv6 stack if the link is brought up) $ ip link add macvlan1 link eno1 mtu 8 type macvlan # This should fail ! $ ip link sh dev macvlan1 5: macvlan1@eno1: mtu 8 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 02:47:6c:24:74:82 brd ff:ff:ff:ff:ff:ff $ ip link set macvlan1 mtu 67 Error: mtu less than device minimum. $ ip link set macvlan1 mtu 68 $ ip link set macvlan1 mtu 8 Error: mtu less than device minimum. Fixes: 91572088e3fd ("net: use core MTU range checking in core net infra") Reported-by: syzbot Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a32cd7feb0127bf629a82686b6e2c128139a86e5 Author: Chen Jun Date: Fri Nov 18 15:40:03 2022 -0800 Input: i8042 - fix leaking of platform device on module removal [ Upstream commit 81cd7e8489278d28794e7b272950c3e00c344e44 ] Avoid resetting the module-wide i8042_platform_device pointer in i8042_probe() or i8042_remove(), so that the device can be properly destroyed by i8042_exit() on module unload. Fixes: 9222ba68c3f4 ("Input: i8042 - add deferred probe support") Signed-off-by: Chen Jun Link: https://lore.kernel.org/r/20221109034148.23821-1-chenjun102@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 2d458046df634088611d44fd77f45465e833ef78 Author: Liu Shixin Date: Thu Nov 17 15:56:01 2022 +0800 arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud [ Upstream commit 5b47348fc0b18a78c96f8474cc90b7525ad1bbfe ] The page table check trigger BUG_ON() unexpectedly when collapse hugepage: ------------[ cut here ]------------ kernel BUG at mm/page_table_check.c:82! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 6 PID: 68 Comm: khugepaged Not tainted 6.1.0-rc3+ #750 Hardware name: linux,dummy-virt (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : page_table_check_clear.isra.0+0x258/0x3f0 lr : page_table_check_clear.isra.0+0x240/0x3f0 [...] Call trace: page_table_check_clear.isra.0+0x258/0x3f0 __page_table_check_pmd_clear+0xbc/0x108 pmdp_collapse_flush+0xb0/0x160 collapse_huge_page+0xa08/0x1080 hpage_collapse_scan_pmd+0xf30/0x1590 khugepaged_scan_mm_slot.constprop.0+0x52c/0xac8 khugepaged+0x338/0x518 kthread+0x278/0x2f8 ret_from_fork+0x10/0x20 [...] Since pmd_user_accessible_page() doesn't check if a pmd is leaf, it decrease file_map_count for a non-leaf pmd comes from collapse_huge_page(). and so trigger BUG_ON() unexpectedly. Fix this problem by using pmd_leaf() insteal of pmd_present() in pmd_user_accessible_page(). Moreover, use pud_leaf() for pud_user_accessible_page() too. Fixes: 42b2547137f5 ("arm64/mm: enable ARCH_SUPPORTS_PAGE_TABLE_CHECK") Reported-by: Denys Vlasenko Signed-off-by: Liu Shixin Reviewed-by: David Hildenbrand Acked-by: Pasha Tatashin Reviewed-by: Kefeng Wang Acked-by: Will Deacon Link: https://lore.kernel.org/r/20221117075602.2904324-2-liushixin2@huawei.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 76f9434d2faa56c8458b2432361760407fdab3b8 Author: Zheng Yejian Date: Mon Nov 14 18:46:32 2022 +0800 tracing: Fix potential null-pointer-access of entry in list 'tr->err_log' [ Upstream commit 067df9e0ad48a97382ab2179bbe773a13a846028 ] Entries in list 'tr->err_log' will be reused after entry number exceed TRACING_LOG_ERRS_MAX. The cmd string of the to be reused entry will be freed first then allocated a new one. If the allocation failed, then the entry will still be in list 'tr->err_log' but its 'cmd' field is set to be NULL, later access of 'cmd' is risky. Currently above problem can cause the loss of 'cmd' information of first entry in 'tr->err_log'. When execute `cat /sys/kernel/tracing/error_log`, reproduce logs like: [ 37.495100] trace_kprobe: error: Maxactive is not for kprobe(null) ^ [ 38.412517] trace_kprobe: error: Maxactive is not for kprobe Command: p4:myprobe2 do_sys_openat2 ^ Link: https://lore.kernel.org/linux-trace-kernel/20221114104632.3547266-1-zhengyejian1@huawei.com Fixes: 1581a884b7ca ("tracing: Remove size restriction on tracing_log_err cmd strings") Signed-off-by: Zheng Yejian Acked-by: Masami Hiramatsu (Google) Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit 55788ebbe8b365b4375bd56b4ba7db79d393a370 Author: Li Huafei Date: Fri Nov 18 10:15:34 2022 +0900 kprobes: Skip clearing aggrprobe's post_handler in kprobe-on-ftrace case [ Upstream commit 5dd7caf0bdc5d0bae7cf9776b4d739fb09bd5ebb ] In __unregister_kprobe_top(), if the currently unregistered probe has post_handler but other child probes of the aggrprobe do not have post_handler, the post_handler of the aggrprobe is cleared. If this is a ftrace-based probe, there is a problem. In later calls to disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is NULL. But we're armed with kprobe_ipmodify_ops. This triggers a WARN in __disarm_kprobe_ftrace() and may even cause use-after-free: Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2) WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0 Modules linked in: testKprobe_007(-) CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18 [...] Call Trace: __disable_kprobe+0xcd/0xe0 __unregister_kprobe_top+0x12/0x150 ? mutex_lock+0xe/0x30 unregister_kprobes.part.23+0x31/0xa0 unregister_kprobe+0x32/0x40 __x64_sys_delete_module+0x15e/0x260 ? do_user_addr_fault+0x2cd/0x6b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] For the kprobe-on-ftrace case, we keep the post_handler setting to identify this aggrprobe armed with kprobe_ipmodify_ops. This way we can disarm it correctly. Link: https://lore.kernel.org/all/20221112070000.35299-1-lihuafei1@huawei.com/ Fixes: 0bc11ed5ab60 ("kprobes: Allow kprobes coexist with livepatch") Reported-by: Zhao Gongyi Suggested-by: Masami Hiramatsu (Google) Signed-off-by: Li Huafei Acked-by: Masami Hiramatsu (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Sasha Levin commit aa5b8170b20e151439f671ea46f873ec3192c17c Author: Yuan Can Date: Thu Nov 17 08:44:21 2022 +0000 scsi: scsi_debug: Fix possible UAF in sdebug_add_host_helper() [ Upstream commit e208a1d795a08d1ac0398c79ad9c58106531bcc5 ] If device_register() fails in sdebug_add_host_helper(), it will goto clean and sdbg_host will be freed, but sdbg_host->host_list will not be removed from sdebug_host_list, then list traversal may cause UAF. Fix it. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yuan Can Link: https://lore.kernel.org/r/20221117084421.58918-1-yuancan@huawei.com Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dce0589a3faec9e2e543e97bca7e62592ec85585 Author: Yang Yingliang Date: Tue Nov 15 09:50:42 2022 +0800 scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus() [ Upstream commit bc68e428d4963af0201e92159629ab96948f0893 ] If device_register() fails in tcm_loop_setup_hba_bus(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't need goto error label in this case. Fixes: 3703b2c5d041 ("[SCSI] tcm_loop: Add multi-fabric Linux/SCSI LLD fabric module") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221115015042.3652261-1-yangyingliang@huawei.com Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c304330250d04bb5c12f300bdc449a465558bf36 Author: Hangbin Liu Date: Tue Nov 15 22:24:00 2022 +0800 net: use struct_group to copy ip/ipv6 header addresses [ Upstream commit 58e0be1ef6118c5352b56a4d06e974c5599993a5 ] kernel test robot reported warnings when build bonding module with make W=1 O=build_dir ARCH=x86_64 SHELL=/bin/bash drivers/net/bonding/: from ../drivers/net/bonding/bond_main.c:35: In function ‘fortify_memcpy_chk’, inlined from ‘iph_to_flow_copy_v4addrs’ at ../include/net/ip.h:566:2, inlined from ‘bond_flow_ip’ at ../drivers/net/bonding/bond_main.c:3984:3: ../include/linux/fortify-string.h:413:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of f ield (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 413 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function ‘fortify_memcpy_chk’, inlined from ‘iph_to_flow_copy_v6addrs’ at ../include/net/ipv6.h:900:2, inlined from ‘bond_flow_ip’ at ../drivers/net/bonding/bond_main.c:3994:3: ../include/linux/fortify-string.h:413:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of f ield (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 413 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is because we try to copy the whole ip/ip6 address to the flow_key, while we only point the to ip/ip6 saddr. Note that since these are UAPI headers, __struct_group() is used to avoid the compiler warnings. Reported-by: kernel test robot Fixes: c3f8324188fa ("net: Add full IPv6 addresses to flow_keys") Signed-off-by: Hangbin Liu Link: https://lore.kernel.org/r/20221115142400.1204786-1-liuhangbin@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 316a762ef364dc7beda530725baf6d7c773081a1 Author: Alexandru Tachici Date: Tue Nov 15 13:44:34 2022 +0200 net: usb: smsc95xx: fix external PHY reset [ Upstream commit 809ff97a677ff85dfb7ce2b63be261d1633dcf29 ] An external PHY needs settling time after power up or reset. In the bind() function an mdio bus is registered. If at this point the external PHY is still initialising, no valid PHY ID will be read and on phy_find_first() the bind() function will fail. If an external PHY is present, wait the maximum time specified in 802.3 45.2.7.1.1. Fixes: 05b35e7eb9a1 ("smsc95xx: add phylib support") Signed-off-by: Alexandru Tachici Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20221115114434.9991-2-alexandru.tachici@analog.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 2aaab8dcf024be0d80507cf5feaf85a7801d1746 Author: Aashish Sharma Date: Mon Nov 7 21:35:56 2022 +0530 tracing: Fix warning on variable 'struct trace_array' [ Upstream commit bedf06833b1f63c2627bd5634602e05592129d7a ] Move the declaration of 'struct trace_array' out of #ifdef CONFIG_TRACING block, to fix the following warning when CONFIG_TRACING is not set: >> include/linux/trace.h:63:45: warning: 'struct trace_array' declared inside parameter list will not be visible outside of this definition or declaration Link: https://lkml.kernel.org/r/20221107160556.2139463-1-shraash@google.com Fixes: 1a77dd1c2bb5 ("scsi: tracing: Fix compile error in trace_array calls when TRACING is disabled") Cc: "Martin K. Petersen" Cc: Arun Easi Acked-by: Masami Hiramatsu (Google) Reviewed-by: Guenter Roeck Signed-off-by: Aashish Sharma Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit d372ea508f9a10819136e20158e50eda7b7aaf70 Author: Steven Rostedt (Google) Date: Fri Oct 21 12:30:13 2022 -0400 ring-buffer: Include dropped pages in counting dirty patches [ Upstream commit 31029a8b2c7e656a0289194ef16415050ae4c4ac ] The function ring_buffer_nr_dirty_pages() was created to find out how many pages are filled in the ring buffer. There's two running counters. One is incremented whenever a new page is touched (pages_touched) and the other is whenever a page is read (pages_read). The dirty count is the number touched minus the number read. This is used to determine if a blocked task should be woken up if the percentage of the ring buffer it is waiting for is hit. The problem is that it does not take into account dropped pages (when the new writes overwrite pages that were not read). And then the dirty pages will always be greater than the percentage. This makes the "buffer_percent" file inaccurate, as the number of dirty pages end up always being larger than the percentage, event when it's not and this causes user space to be woken up more than it wants to be. Add a new counter to keep track of lost pages, and include that in the accounting of dirty pages so that it is actually accurate. Link: https://lkml.kernel.org/r/20221021123013.55fb6055@gandalf.local.home Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Sasha Levin commit fd5e454b856ed86b090336e269695d9908609b71 Author: Ravi Bangoria Date: Mon Nov 14 10:10:29 2022 +0530 perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling [ Upstream commit baa014b9543c8e5e94f5d15b66abfe60750b8284 ] amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu. Fixes: ada543459cab ("perf/x86/amd: Add AMD Fam19h Branch Sampling support") Reported-by: Linux Kernel Functional Testing Signed-off-by: Ravi Bangoria Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20221114044029.373-1-ravi.bangoria@amd.com Signed-off-by: Sasha Levin commit b434476267226143ce4cde135db40c90e53047ef Author: Jason Gunthorpe Date: Thu Sep 22 16:20:25 2022 -0300 vfio: Split the register_device ops call into functions [ Upstream commit 9446162e740aefff95c324ac0887f0b68c739695 ] This is a container item. A following patch will move the vfio_container functions to their own .c file. Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/7-v3-297af71838d2+b9-vfio_container_split_jgg@nvidia.com Signed-off-by: Alex Williamson Stable-dep-of: 7fdba0011157 ("vfio: Fix container device registration life cycle") Signed-off-by: Sasha Levin commit 6f6b753192e3749a8a9e7b5cac6aa29fb3fd56f2 Author: Jason Gunthorpe Date: Thu Sep 22 16:20:24 2022 -0300 vfio: Rename vfio_ioctl_check_extension() [ Upstream commit 1408640d578887d7860737221043d91fc6d5a723 ] To vfio_container_ioctl_check_extension(). A following patch will turn this into a non-static function, make it clear it is related to the container. Reviewed-by: Kevin Tian Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/6-v3-297af71838d2+b9-vfio_container_split_jgg@nvidia.com Signed-off-by: Alex Williamson Stable-dep-of: 7fdba0011157 ("vfio: Fix container device registration life cycle") Signed-off-by: Sasha Levin commit b09221f1b4944d2866d06ac35e59d7a6f8916c9f Author: Marco Elver Date: Mon Oct 31 10:35:13 2022 +0100 perf: Improve missing SIGTRAP checking [ Upstream commit bb88f9695460bec25aa30ba9072595025cf6c8af ] To catch missing SIGTRAP we employ a WARN in __perf_event_overflow(), which fires if pending_sigtrap was already set: returning to user space without consuming pending_sigtrap, and then having the event fire again would re-enter the kernel and trigger the WARN. This, however, seemed to miss the case where some events not associated with progress in the user space task can fire and the interrupt handler runs before the IRQ work meant to consume pending_sigtrap (and generate the SIGTRAP). syzbot gifted us this stack trace: | WARNING: CPU: 0 PID: 3607 at kernel/events/core.c:9313 __perf_event_overflow | Modules linked in: | CPU: 0 PID: 3607 Comm: syz-executor100 Not tainted 6.1.0-rc2-syzkaller-00073-g88619e77b33d #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022 | RIP: 0010:__perf_event_overflow+0x498/0x540 kernel/events/core.c:9313 | <...> | Call Trace: | | perf_swevent_hrtimer+0x34f/0x3c0 kernel/events/core.c:10729 | __run_hrtimer kernel/time/hrtimer.c:1685 [inline] | __hrtimer_run_queues+0x1c6/0xfb0 kernel/time/hrtimer.c:1749 | hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 | local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1096 [inline] | __sysvec_apic_timer_interrupt+0x17c/0x640 arch/x86/kernel/apic/apic.c:1113 | sysvec_apic_timer_interrupt+0x40/0xc0 arch/x86/kernel/apic/apic.c:1107 | asm_sysvec_apic_timer_interrupt+0x16/0x20 arch/x86/include/asm/idtentry.h:649 | <...> | In this case, syzbot produced a program with event type PERF_TYPE_SOFTWARE and config PERF_COUNT_SW_CPU_CLOCK. The hrtimer manages to fire again before the IRQ work got a chance to run, all while never having returned to user space. Improve the WARN to check for real progress in user space: approximate this by storing a 32-bit hash of the current IP into pending_sigtrap, and if an event fires while pending_sigtrap still matches the previous IP, we assume no progress (false negatives are possible given we could return to user space and trigger again on the same IP). Fixes: ca6c21327c6a ("perf: Fix missing SIGTRAPs") Reported-by: syzbot+b8ded3e2e2c6adde4990@syzkaller.appspotmail.com Signed-off-by: Marco Elver Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20221031093513.3032814-1-elver@google.com Signed-off-by: Sasha Levin commit f59a5ffaf9d969ef0b139a94072706c2880724d3 Author: Peter Ujfalusi Date: Mon Nov 7 11:04:33 2022 +0200 ASoC: SOF: topology: No need to assign core ID if token parsing failed [ Upstream commit 3d59eaef49ca2db581156a7b77c9afc0546eefc0 ] Move the return value check before attempting to assign the core ID to the swidget since we are going to fail the sof_widget_ready() and free up swidget anyways. Fixes: 909dadf21aae ("ASoC: SOF: topology: Make DAI widget parsing IPC agnostic") Signed-off-by: Peter Ujfalusi Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20221107090433.5146-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0c2b1c56252bf19d3412137073c2c07e86f40ba1 Author: Keith Busch Date: Thu Sep 22 08:13:47 2022 -0700 nvme: ensure subsystem reset is single threaded commit 1e866afd4bcdd01a70a5eddb4371158d3035ce03 upstream. The subsystem reset writes to a register, so we have to ensure the device state is capable of handling that otherwise the driver may access unmapped registers. Use the state machine to ensure the subsystem reset doesn't try to write registers on a device already undergoing this type of reset. Link: https://bugzilla.kernel.org/show_bug.cgi?id=214771 Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 63ae0fafd396497c18a260fe58d4a5c25a05ad9d Author: Keith Busch Date: Thu Sep 22 07:54:06 2022 -0700 nvme: restrict management ioctls to admin commit 23e085b2dead13b51fe86d27069895b740f749c0 upstream. The passthrough commands already have this restriction, but the other operations do not. Require the same capabilities for all users as all of these operations, which include resets and rescans, can be disruptive. Signed-off-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 531b6fcfb284fbfcc2d9fa2478b180e49fdffd06 Author: Adrian Hunter Date: Sat Nov 12 17:15:08 2022 +0200 perf/x86/intel/pt: Fix sampling using single range output commit ce0d998be9274dd3a3d971cbeaa6fe28fd2c3062 upstream. Deal with errata TGL052, ADL037 and RPL017 "Trace May Contain Incorrect Data When Configured With Single Range Output Larger Than 4KB" by disabling single range output whenever larger than 4KB. Fixes: 670638477aed ("perf/x86/intel/pt: Opportunistically use single range output mode") Signed-off-by: Adrian Hunter Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/20221112151508.13768-1-adrian.hunter@intel.com Signed-off-by: Greg Kroah-Hartman commit f75be9885d49e3717de962345c4572ddab52b178 Author: Sandipan Das Date: Thu Sep 8 10:33:15 2022 +0530 perf/x86/amd/uncore: Fix memory leak for events array commit bdfe34597139cfcecd47a2eb97fea44d77157491 upstream. When a CPU comes online, the per-CPU NB and LLC uncore contexts are freed but not the events array within the context structure. This causes a memory leak as identified by the kmemleak detector. [...] unreferenced object 0xffff8c5944b8e320 (size 32): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 unreferenced object 0xffff8c5944b8dd40 (size 64): comm "swapper/0", pid 1, jiffies 4294670387 (age 151.072s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230 [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470 [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170 [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330 [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110 [<0000000015365e0f>] amd_uncore_init+0x260/0x321 [<00000000089152d2>] do_one_initcall+0x3f/0x1f0 [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212 [<0000000030be8dde>] kernel_init+0x11/0x120 [<0000000059709e59>] ret_from_fork+0x22/0x30 [...] Fix the problem by freeing the events array before freeing the uncore context. Fixes: 39621c5808f5 ("perf/x86/amd/uncore: Use dynamic events array") Reported-by: Ravi Bangoria Signed-off-by: Sandipan Das Signed-off-by: Borislav Petkov Tested-by: Ravi Bangoria Cc: Link: https://lore.kernel.org/r/4fa9e5ac6d6e41fa889101e7af7e6ba372cfea52.1662613255.git.sandipan.das@amd.com Signed-off-by: Greg Kroah-Hartman commit c6e8a7a1780af3da65e78a615f7d0874da6aabb0 Author: Mel Gorman Date: Thu Nov 10 12:44:00 2022 +0000 x86/fpu: Drop fpregs lock before inheriting FPU permissions commit 36b038791e1e2baea892e9276588815fd14894b4 upstream. Mike Galbraith reported the following against an old fork of preempt-rt but the same issue also applies to the current preempt-rt tree. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: systemd preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: fpu_clone CPU: 6 PID: 1 Comm: systemd Tainted: G E (unreleased) Call Trace: dump_stack_lvl ? fpu_clone __might_resched rt_spin_lock fpu_clone ? copy_thread ? copy_process ? shmem_alloc_inode ? kmem_cache_alloc ? kernel_clone ? __do_sys_clone ? do_syscall_64 ? __x64_sys_rt_sigprocmask ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? syscall_exit_to_user_mode ? do_syscall_64 ? exc_page_fault ? entry_SYSCALL_64_after_hwframe Mike says: The splat comes from fpu_inherit_perms() being called under fpregs_lock(), and us reaching the spin_lock_irq() therein due to fpu_state_size_dynamic() returning true despite static key __fpu_state_size_dynamic having never been enabled. Mike's assessment looks correct. fpregs_lock on a PREEMPT_RT kernel disables preemption so calling spin_lock_irq() in fpu_inherit_perms() is unsafe. This problem exists since commit 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features"). Even though the original bug report should not have enabled the paths at all, the bug still exists. fpregs_lock is necessary when editing the FPU registers or a task's FP state but it is not necessary for fpu_inherit_perms(). The only write of any FP state in fpu_inherit_perms() is for the new child which is not running yet and cannot context switch or be borrowed by a kernel thread yet. Hence, fpregs_lock is not protecting anything in the new child until clone() completes and can be dropped earlier. The siglock still needs to be acquired by fpu_inherit_perms() as the read of the parent's permissions has to be serialised. [ bp: Cleanup splat. ] Fixes: 9e798e9aa14c ("x86/fpu: Prepare fpu_clone() for dynamically enabled features") Reported-by: Mike Galbraith Signed-off-by: Mel Gorman Signed-off-by: Borislav Petkov Reviewed-by: Thomas Gleixner Cc: Link: https://lore.kernel.org/r/20221110124400.zgymc2lnwqjukgfh@techsingularity.net Signed-off-by: Greg Kroah-Hartman commit 3b1c10fb754b0b67165e3f055a4208e5ba26dc89 Author: Borys Popławski Date: Wed Oct 5 00:59:03 2022 +0200 x86/sgx: Add overflow check in sgx_validate_offset_length() commit f0861f49bd946ff94fce4f82509c45e167f63690 upstream. sgx_validate_offset_length() function verifies "offset" and "length" arguments provided by userspace, but was missing an overflow check on their addition. Add it. Fixes: c6d26d370767 ("x86/sgx: Add SGX_IOC_ENCLAVE_ADD_PAGES") Signed-off-by: Borys Popławski Signed-off-by: Borislav Petkov Reviewed-by: Jarkko Sakkinen Cc: stable@vger.kernel.org # v5.11+ Link: https://lore.kernel.org/r/0d91ac79-6d84-abed-5821-4dbe59fa1a38@invisiblethingslab.com Signed-off-by: Greg Kroah-Hartman commit d118247e404d6338f7b90636a3c6b95a387ed163 Author: Chris Mason Date: Mon Nov 14 10:19:30 2022 -0800 blk-cgroup: properly pin the parent in blkcg_css_online commit d7dbd43f4a828fa1d9a8614d5b0ac40aee6375fe upstream. blkcg_css_online is supposed to pin the blkcg of the parent, but 397c9f46ee4d refactored things and along the way, changed it to pin the css instead. This results in extra pins, and we end up leaking blkcgs and cgroups. Fixes: 397c9f46ee4d ("blk-cgroup: move blkcg_{pin,unpin}_online out of line") Signed-off-by: Chris Mason Spotted-by: Rik van Riel Cc: # v5.19+ Acked-by: Johannes Weiner Link: https://lore.kernel.org/r/20221114181930.2093706-1-clm@fb.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 76c50d77b928a33e5290aaa9fdc10e88254ff8c7 Author: Alexander Potapenko Date: Fri Nov 4 18:58:49 2022 +0100 misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram() commit e5b0d06d9b10f5f43101bd6598b076c347f9295f upstream. `struct vmci_event_qp` allocated by qp_notify_peer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN: BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121 instrument_copy_to_user ./include/linux/instrumented.h:121 _copy_to_user+0x5f/0xb0 lib/usercopy.c:33 copy_to_user ./include/linux/uaccess.h:169 vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431 vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925 vfs_ioctl fs/ioctl.c:51 ... Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271 vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339 qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940 vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488 vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927 ... Local variable ev created at: qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456 qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662 qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750 Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100 Use memset() to prevent the infoleaks. Also speculatively fix qp_notify_peer_local(), which may suffer from the same problem. Reported-by: syzbot+39be4da489ed2493ba25@syzkaller.appspotmail.com Cc: stable Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Signed-off-by: Alexander Potapenko Reviewed-by: Vishnu Dasa Link: https://lore.kernel.org/r/20221104175849.2782567-1-glider@google.com Signed-off-by: Greg Kroah-Hartman commit 423ae11d70c740efd208ff88099aa1f102db40fa Author: Gerald Schaefer Date: Thu Oct 27 16:19:38 2022 +0200 s390/dcssblk: fix deadlock when adding a DCSS commit a41a11b4009580edb6e2b4c76e5e2ee303f87157 upstream. After the rework from commit 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT"), when calling device_add_disk(), dcssblk will end up in disk_scan_partitions(), and not break out early w/o GENHD_FL_NO_PART. This will trigger implicit open/release via blkdev_get/put_whole() later. dcssblk_release() will then deadlock on dcssblk_devices_sem semaphore, which is already held from dcssblk_add_store() when calling device_add_disk(). dcssblk does not support partitions (DCSSBLK_MINORS_PER_DISK == 1), and never scanned partitions before. Therefore restore the previous behavior, and explicitly disallow partition scanning by setting the GENHD_FL_NO_PART flag. This will also prevent this deadlock scenario. Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT") Cc: # 5.17+ Signed-off-by: Gerald Schaefer Acked-by: Heiko Carstens Signed-off-by: Alexander Gordeev Signed-off-by: Greg Kroah-Hartman commit 358b251a1e63f9a9325e17849ebed7cc99912f31 Author: Akira Yokosawa Date: Wed Nov 2 20:48:01 2022 +0900 docs/driver-api/miscellaneous: Remove kernel-doc of serial_core.c commit 3ec17cb325ac731c2211e13f7eaa4b812694e218 upstream. Since merge of tty-6.0-rc1, "make htmldocs" with Sphinx >=3.1 emits a bunch of warnings indicating duplicate kernel-doc comments from drivers/tty/serial/serial_core.c. This is due to the kernel-doc directive for serial_core.c in serial/drivers.rst added in the merge. It conflicts with an existing kernel-doc directive in miscellaneous.rst. Remove the latter directive and resolve the duplicates. Signed-off-by: Akira Yokosawa Fixes: 607ca0f742b7 ("Merge tag 'tty-6.0-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty") Cc: stable@vger.kernel.org # 6.0 Cc: Jiri Slaby Cc: Greg Kroah-Hartman Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/4e54c76a-138a-07e0-985a-dd83cb622208@gmail.com Signed-off-by: Greg Kroah-Hartman commit b3fe1630184f05e48485ef0abd3015423fdfe89f Author: Shuah Khan Date: Tue Oct 11 11:14:17 2022 -0600 docs: update mediator contact information in CoC doc commit 5fddf8962b429b8303c4a654291ecb6e61a7d747 upstream. Update mediator contact information in CoC interpretation document. Cc: Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20221011171417.34286-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 35bca18092685b488003509fef7055aa2d4f2ebc Author: Xiongfeng Wang Date: Mon Nov 14 16:31:00 2022 +0800 mmc: sdhci-pci: Fix possible memory leak caused by missing pci_dev_put() commit 222cfa0118aa68687ace74aab8fdf77ce8fbd7e6 upstream. pci_get_device() will increase the reference count for the returned pci_dev. We need to use pci_dev_put() to decrease the reference count before amd_probe() returns. There is no problem for the 'smbus_dev == NULL' branch because pci_dev_put() can also handle the NULL input parameter case. Fixes: 659c9bc114a8 ("mmc: sdhci-pci: Build o2micro support in the same module") Signed-off-by: Xiongfeng Wang Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221114083100.149200-1-wangxiongfeng2@huawei.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 4039c60b8f4450759cd7d081341fbaf12a3be747 Author: Chevron Li Date: Fri Nov 4 02:55:12 2022 -0700 mmc: sdhci-pci-o2micro: fix card detect fail issue caused by CD# debounce timeout commit 096cc0cddf58232bded309336961784f1d1c85f8 upstream. The SD card is recognized failed sometimes when resume from suspend. Because CD# debounce time too long then card present report wrong. Finally, card is recognized failed. Signed-off-by: Chevron Li Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221104095512.4068-1-chevron.li@bayhubtech.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 56065bde0f6fffa079044e8c168c7b048899d59b Author: Yann Gautier Date: Fri Oct 28 09:37:40 2022 +0200 mmc: core: properly select voltage range without power cycle commit 39a72dbfe188291b156dd6523511e3d5761ce775 upstream. In mmc_select_voltage(), if there is no full power cycle, the voltage range selected at the end of the function will be on a single range (e.g. 3.3V/3.4V). To keep a range around the selected voltage (3.2V/3.4V), the mask shift should be reduced by 1. This issue was triggered by using a specific SD-card (Verbatim Premium 16GB UHS-1) on an STM32MP157C-DK2 board. This board cannot do UHS modes and there is no power cycle. And the card was failing to switch to high-speed mode. When adding the range 3.2V/3.3V for this card with the proposed shift change, the card can switch to high-speed mode. Fixes: ce69d37b7d8f ("mmc: core: Prevent violation of specs while initializing cards") Signed-off-by: Yann Gautier Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20221028073740.7259-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d3f311d679946c70fe354ff152c863b40bfae551 Author: Brian Norris Date: Wed Oct 19 18:10:53 2022 -0700 firmware: coreboot: Register bus in module init commit 65946690ed8d972fdb91a74ee75ac0f0f0d68321 upstream. The coreboot_table driver registers a coreboot bus while probing a "coreboot_table" device representing the coreboot table memory region. Probing this device (i.e., registering the bus) is a dependency for the module_init() functions of any driver for this bus (e.g., memconsole-coreboot.c / memconsole_driver_init()). With synchronous probe, this dependency works OK, as the link order in the Makefile ensures coreboot_table_driver_init() (and thus, coreboot_table_probe()) completes before a coreboot device driver tries to add itself to the bus. With asynchronous probe, however, coreboot_table_probe() may race with memconsole_driver_init(), and so we're liable to hit one of these two: 1. coreboot_driver_register() eventually hits "[...] the bus was not initialized.", and the memconsole driver fails to register; or 2. coreboot_driver_register() gets past #1, but still races with bus_register() and hits some other undefined/crashing behavior (e.g., in driver_find() [1]) We can resolve this by registering the bus in our initcall, and only deferring "device" work (scanning the coreboot memory region and creating sub-devices) to probe(). [1] Example failure, using 'driver_async_probe=*' kernel command line: [ 0.114217] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... [ 0.114307] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.1.0-rc1 #63 [ 0.114316] Hardware name: Google Scarlet (DT) ... [ 0.114488] Call trace: [ 0.114494] _raw_spin_lock+0x34/0x60 [ 0.114502] kset_find_obj+0x28/0x84 [ 0.114511] driver_find+0x30/0x50 [ 0.114520] driver_register+0x64/0x10c [ 0.114528] coreboot_driver_register+0x30/0x3c [ 0.114540] memconsole_driver_init+0x24/0x30 [ 0.114550] do_one_initcall+0x154/0x2e0 [ 0.114560] do_initcall_level+0x134/0x160 [ 0.114571] do_initcalls+0x60/0xa0 [ 0.114579] do_basic_setup+0x28/0x34 [ 0.114588] kernel_init_freeable+0xf8/0x150 [ 0.114596] kernel_init+0x2c/0x12c [ 0.114607] ret_from_fork+0x10/0x20 [ 0.114624] Code: 5280002b 1100054a b900092a f9800011 (885ffc01) [ 0.114631] ---[ end trace 0000000000000000 ]--- Fixes: b81e3140e412 ("firmware: coreboot: Make bus registration symmetric") Cc: Signed-off-by: Brian Norris Reviewed-by: Guenter Roeck Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20221019180934.1.If29e167d8a4771b0bf4a39c89c6946ed764817b9@changeid Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 6d05d3b62eb0e475b7b3c742d159978ec1bd2659 Author: Tina Zhang Date: Wed Nov 16 13:15:44 2022 +0800 iommu/vt-d: Set SRE bit only when hardware has SRS cap commit 7fc961cf7ffcb130c4e93ee9a5628134f9de700a upstream. SRS cap is the hardware cap telling if the hardware IOMMU can support requests seeking supervisor privilege or not. SRE bit in scalable-mode PASID table entry is treated as Reserved(0) for implementation not supporting SRS cap. Checking SRS cap before setting SRE bit can avoid the non-recoverable fault of "Non-zero reserved field set in PASID Table Entry" caused by setting SRE bit while there is no SRS cap support. The fault messages look like below: DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [00:0d.0] fault addr 0x1154e1000 [fault reason 0x5a] SM: Non-zero reserved field set in PASID Table Entry Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") Cc: stable@vger.kernel.org Signed-off-by: Tina Zhang Link: https://lore.kernel.org/r/20221115070346.1112273-1-tina.zhang@intel.com Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20221116051544.26540-3-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 97f91aa4308202c64f620c1f2a5e3413c470572a Author: Tina Zhang Date: Wed Nov 16 13:15:43 2022 +0800 iommu/vt-d: Preset Access bit for IOVA in FL non-leaf paging entries commit 242b0aaeabbe2efbef1b9d42a8e56627e800964c upstream. The A/D bits are preseted for IOVA over first level(FL) usage for both kernel DMA (i.e, domain typs is IOMMU_DOMAIN_DMA) and user space DMA usage (i.e., domain type is IOMMU_DOMAIN_UNMANAGED). Presetting A bit in FL requires to preset the bit in every related paging entries, including the non-leaf ones. Otherwise, hardware may treat this as an error. For example, in a case of ECAP_REG.SMPWC==0, DMA faults might occur with below DMAR fault messages (wrapped for line length) dumped. DMAR: DRHD: handling fault status reg 2 DMAR: [DMA Read NO_PASID] Request device [aa:00.0] fault addr 0x10c3a6000 [fault reason 0x90] SM: A/D bit update needed in first-level entry when set up in no snoop Fixes: 289b3b005cb9 ("iommu/vt-d: Preset A/D bits for user space DMA usage") Cc: stable@vger.kernel.org Signed-off-by: Tina Zhang Link: https://lore.kernel.org/r/20221113010324.1094483-1-tina.zhang@intel.com Signed-off-by: Lu Baolu Link: https://lore.kernel.org/r/20221116051544.26540-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 90a49a6b015fa439cd62e45121390284c125a91f Author: Benjamin Block Date: Wed Nov 16 11:50:37 2022 +0100 scsi: zfcp: Fix double free of FSF request when qdio send fails commit 0954256e970ecf371b03a6c9af2cf91b9c4085ff upstream. We used to use the wrong type of integer in 'zfcp_fsf_req_send()' to cache the FSF request ID when sending a new FSF request. This is used in case the sending fails and we need to remove the request from our internal hash table again (so we don't keep an invalid reference and use it when we free the request again). In 'zfcp_fsf_req_send()' we used to cache the ID as 'int' (signed and 32 bit wide), but the rest of the zfcp code (and the firmware specification) handles the ID as 'unsigned long'/'u64' (unsigned and 64 bit wide [s390x ELF ABI]). For one this has the obvious problem that when the ID grows past 32 bit (this can happen reasonably fast) it is truncated to 32 bit when storing it in the cache variable and so doesn't match the original ID anymore. The second less obvious problem is that even when the original ID has not yet grown past 32 bit, as soon as the 32nd bit is set in the original ID (0x80000000 = 2'147'483'648) we will have a mismatch when we cast it back to 'unsigned long'. As the cached variable is of a signed type, the compiler will choose a sign-extending instruction to load the 32 bit variable into a 64 bit register (e.g.: 'lgf %r11,188(%r15)'). So once we pass the cached variable into 'zfcp_reqlist_find_rm()' to remove the request again all the leading zeros will be flipped to ones to extend the sign and won't match the original ID anymore (this has been observed in practice). If we can't successfully remove the request from the hash table again after 'zfcp_qdio_send()' fails (this happens regularly when zfcp cannot notify the adapter about new work because the adapter is already gone during e.g. a ChpID toggle) we will end up with a double free. We unconditionally free the request in the calling function when 'zfcp_fsf_req_send()' fails, but because the request is still in the hash table we end up with a stale memory reference, and once the zfcp adapter is either reset during recovery or shutdown we end up freeing the same memory twice. The resulting stack traces vary depending on the kernel and have no direct correlation to the place where the bug occurs. Here are three examples that have been seen in practice: list_del corruption. next->prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00) ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:62! monitor event: 0040 ilc:2 [#1] PREEMPT SMP Modules linked in: ... CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded Hardware name: ... Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70 Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8 #00000003cbeea1f4: af000000 mc 0,0 >00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48 00000003cbeea204: b9040043 lgr %r4,%r3 00000003cbeea208: b9040051 lgr %r5,%r1 00000003cbeea20c: b9040032 lgr %r3,%r2 Call Trace: [<00000003cbeea1f8>] __list_del_entry_valid+0x98/0x140 ([<00000003cbeea1f4>] __list_del_entry_valid+0x94/0x140) [<000003ff7ff502fe>] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp] [<000003ff7ff49cd0>] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp] [<000003ff7ff4a22e>] zfcp_erp_strategy+0x21e/0xca0 [zfcp] [<000003ff7ff4ad34>] zfcp_erp_thread+0x84/0x1a0 [zfcp] [<00000003cb5eece8>] kthread+0x138/0x150 [<00000003cb557f3c>] __ret_from_fork+0x3c/0x60 [<00000003cc4172ea>] ret_from_fork+0xa/0x40 INFO: lockdep is turned off. Last Breaking-Event-Address: [<00000003cc3e9d04>] _printk+0x4c/0x58 Kernel panic - not syncing: Fatal exception: panic_on_oops or: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 6b6b6b6b6b6b6000 TEID: 6b6b6b6b6b6b6803 Fault in home space mode while using kernel ASCE. AS:0000000063b10007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... CPU: 10 PID: 0 Comm: swapper/10 Kdump: loaded Hardware name: ... Krnl PSW : 0404d00180000000 000003ff7febaf8e (zfcp_fsf_reqid_check+0x86/0x158 [zfcp]) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: 5a6f1cfa89c49ac3 00000000aff2c4c8 6b6b6b6b6b6b6b6b 00000000000002a8 0000000000000000 0000000000000055 0000000000000000 00000000a8515800 0700000000000000 00000000a6e14500 00000000aff2c000 000000008003c44c 000000008093c700 0000000000000010 00000380009ebba8 00000380009ebb48 Krnl Code: 000003ff7febaf7e: a7f4003d brc 15,000003ff7febaff8 000003ff7febaf82: e32020000004 lg %r2,0(%r2) #000003ff7febaf88: ec2100388064 cgrj %r2,%r1,8,000003ff7febaff8 >000003ff7febaf8e: e3b020100020 cg %r11,16(%r2) 000003ff7febaf94: a774fff7 brc 7,000003ff7febaf82 000003ff7febaf98: ec280030007c cgij %r2,0,8,000003ff7febaff8 000003ff7febaf9e: e31020080004 lg %r1,8(%r2) 000003ff7febafa4: e33020000004 lg %r3,0(%r2) Call Trace: [<000003ff7febaf8e>] zfcp_fsf_reqid_check+0x86/0x158 [zfcp] [<000003ff7febbdbc>] zfcp_qdio_int_resp+0x6c/0x170 [zfcp] [<000003ff7febbf90>] zfcp_qdio_irq_tasklet+0xd0/0x108 [zfcp] [<0000000061d90a04>] tasklet_action_common.constprop.0+0xdc/0x128 [<000000006292f300>] __do_softirq+0x130/0x3c0 [<0000000061d906c6>] irq_exit_rcu+0xfe/0x118 [<000000006291e818>] do_io_irq+0xc8/0x168 [<000000006292d516>] io_int_handler+0xd6/0x110 [<000000006292d596>] psw_idle_exit+0x0/0xa ([<0000000061d3be50>] arch_cpu_idle+0x40/0xd0) [<000000006292ceea>] default_idle_call+0x52/0xf8 [<0000000061de4fa4>] do_idle+0xd4/0x168 [<0000000061de51fe>] cpu_startup_entry+0x36/0x40 [<0000000061d4faac>] smp_start_secondary+0x12c/0x138 [<000000006292d88e>] restart_int_handler+0x6e/0x90 Last Breaking-Event-Address: [<000003ff7febaf94>] zfcp_fsf_reqid_check+0x8c/0x158 [zfcp] Kernel panic - not syncing: Fatal exception in interrupt or: Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 523b05d3ae76a000 TEID: 523b05d3ae76a803 Fault in home space mode while using kernel ASCE. AS:0000000077c40007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: ... CPU: 3 PID: 453 Comm: kworker/3:1H Kdump: loaded Hardware name: ... Workqueue: kblockd blk_mq_run_work_fn Krnl PSW : 0404d00180000000 0000000076fc0312 (__kmalloc+0xd2/0x398) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3 Krnl GPRS: ffffffffffffffff 523b05d3ae76abf6 0000000000000000 0000000000092a20 0000000000000002 00000007e49b5cc0 00000007eda8f000 0000000000092a20 00000007eda8f000 00000003b02856b9 00000000000000a8 523b05d3ae76abf6 00000007dd662000 00000007eda8f000 0000000076fc02b2 000003e0037637a0 Krnl Code: 0000000076fc0302: c004000000d4 brcl 0,76fc04aa 0000000076fc0308: b904001b lgr %r1,%r11 #0000000076fc030c: e3106020001a algf %r1,32(%r6) >0000000076fc0312: e31010000082 xg %r1,0(%r1) 0000000076fc0318: b9040001 lgr %r0,%r1 0000000076fc031c: e30061700082 xg %r0,368(%r6) 0000000076fc0322: ec59000100d9 aghik %r5,%r9,1 0000000076fc0328: e34003b80004 lg %r4,952 Call Trace: [<0000000076fc0312>] __kmalloc+0xd2/0x398 [<0000000076f318f2>] mempool_alloc+0x72/0x1f8 [<000003ff8027c5f8>] zfcp_fsf_req_create.isra.7+0x40/0x268 [zfcp] [<000003ff8027f1bc>] zfcp_fsf_fcp_cmnd+0xac/0x3f0 [zfcp] [<000003ff80280f1a>] zfcp_scsi_queuecommand+0x122/0x1d0 [zfcp] [<000003ff800b4218>] scsi_queue_rq+0x778/0xa10 [scsi_mod] [<00000000771782a0>] __blk_mq_try_issue_directly+0x130/0x208 [<000000007717a124>] blk_mq_request_issue_directly+0x4c/0xa8 [<000003ff801302e2>] dm_mq_queue_rq+0x2ea/0x468 [dm_mod] [<0000000077178c12>] blk_mq_dispatch_rq_list+0x33a/0x818 [<000000007717f064>] __blk_mq_do_dispatch_sched+0x284/0x2f0 [<000000007717f44c>] __blk_mq_sched_dispatch_requests+0x1c4/0x218 [<000000007717fa7a>] blk_mq_sched_dispatch_requests+0x52/0x90 [<0000000077176d74>] __blk_mq_run_hw_queue+0x9c/0xc0 [<0000000076da6d74>] process_one_work+0x274/0x4d0 [<0000000076da7018>] worker_thread+0x48/0x560 [<0000000076daef18>] kthread+0x140/0x160 [<000000007751d144>] ret_from_fork+0x28/0x30 Last Breaking-Event-Address: [<0000000076fc0474>] __kmalloc+0x234/0x398 Kernel panic - not syncing: Fatal exception: panic_on_oops To fix this, simply change the type of the cache variable to 'unsigned long', like the rest of zfcp and also the argument for 'zfcp_reqlist_find_rm()'. This prevents truncation and wrong sign extension and so can successfully remove the request from the hash table. Fixes: e60a6d69f1f8 ("[SCSI] zfcp: Remove function zfcp_reqlist_find_safe") Cc: #v2.6.34+ Signed-off-by: Benjamin Block Link: https://lore.kernel.org/r/979f6e6019d15f91ba56182f1aaf68d61bf37fc6.1668595505.git.bblock@linux.ibm.com Reviewed-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 98c277dda5552bda985b79f139ac2faec1991ebd Author: Aminuddin Jamaluddin Date: Mon Nov 14 14:53:02 2022 +0800 net: phy: marvell: add sleep time after enabling the loopback bit commit 18c532e44939caa17f1fa380f7ac50dbc0718dbb upstream. Sleep time is added to ensure the phy to be ready after loopback bit was set. This to prevent the phy loopback test from failing. Fixes: 020a45aff119 ("net: phy: marvell: add Marvell specific PHY loopback") Cc: # 5.15.x Signed-off-by: Muhammad Husaini Zulkifli Signed-off-by: Aminuddin Jamaluddin Link: https://lore.kernel.org/r/20221114065302.10625-1-aminuddin.jamaluddin@intel.com Signed-off-by: Paolo Abeni Signed-off-by: Greg Kroah-Hartman commit 47e9fa266a784d279d492eef723e78bdaaada262 Author: Alban Crequy Date: Thu Nov 10 09:56:13 2022 +0100 maccess: Fix writing offset in case of fault in strncpy_from_kernel_nofault() commit 8678ea06852cd1f819b870c773d43df888d15d46 upstream. If a page fault occurs while copying the first byte, this function resets one byte before dst. As a consequence, an address could be modified and leaded to kernel crashes if case the modified address was accessed later. Fixes: b58294ead14c ("maccess: allow architectures to provide kernel probing directly") Signed-off-by: Alban Crequy Signed-off-by: Andrii Nakryiko Tested-by: Francis Laniel Reviewed-by: Andrew Morton Cc: [5.8] Link: https://lore.kernel.org/bpf/20221110085614.111213-2-albancrequy@linux.microsoft.com Signed-off-by: Greg Kroah-Hartman commit 6365569d62a75ddf53fb0c2936c16587a365984c Author: Tetsuo Handa Date: Mon Nov 7 10:21:40 2022 -0800 Input: iforce - invert valid length check when fetching device IDs commit b8ebf250997c5fb253582f42bfe98673801ebebd upstream. syzbot is reporting uninitialized value at iforce_init_device() [1], for commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") is checking that valid length is shorter than bytes to read. Since iforce_get_id_packet() stores valid length when returning 0, the caller needs to check that valid length is longer than or equals to bytes to read. Reported-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer when fetching device IDs") Link: https://lore.kernel.org/r/531fb432-7396-ad37-ecba-3e42e7f56d5c@I-love.SAKURA.ne.jp Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit fd879c83e87735ab8f00ef7755752cf0cbae24b2 Author: Xiubo Li Date: Wed Nov 9 11:00:39 2022 +0800 ceph: avoid putting the realm twice when decoding snaps fails commit 51884d153f7ec85e18d607b2467820a90e0f4359 upstream. When decoding the snaps fails it maybe leaving the 'first_realm' and 'realm' pointing to the same snaprealm memory. And then it'll put it twice and could cause random use-after-free, BUG_ON, etc issues. Cc: stable@vger.kernel.org Link: https://tracker.ceph.com/issues/57686 Signed-off-by: Xiubo Li Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit 067bcd807ee24cc3b8bea5ba67aa9c16049e2c52 Author: Pavel Begunkov Date: Fri Nov 18 15:41:41 2022 +0000 io_uring: disallow self-propelled ring polling commit 7fdbc5f014c3f71bc44673a2d6c5bb2d12d45f25 upstream. When we post a CQE we wake all ring pollers as it normally should be. However, if a CQE was generated by a multishot poll request targeting its own ring, it'll wake that request up, which will make it to post a new CQE, which will wake the request and so on until it exhausts all CQ entries. Don't allow multishot polling io_uring files but downgrade them to oneshots, which was always stated as a correct behaviour that the userspace should check for. Cc: stable@vger.kernel.org Fixes: aa43477b04025 ("io_uring: poll rework") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/3124038c0e7474d427538c2d915335ec28c92d21.1668785722.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 674b9fff8a3b7d9eb64fa28e8131a11561baa11d Author: Pavel Begunkov Date: Thu Nov 17 18:40:17 2022 +0000 io_uring: fix multishot recv request leaks commit 100d6b17c06ee4c2b42fdddf0fe4ab77c86eb77e upstream. Having REQ_F_POLLED set doesn't guarantee that the request is executed as a multishot from the polling path. Fortunately for us, if the code thinks it's multishot issue when it's not, it can only ask to skip completion so leaking the request. Use issue_flags to mark multipoll issues. Cc: stable@vger.kernel.org Fixes: 1300ebb20286b ("io_uring: multishot recv") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/37762040ba9c52b81b92a2f5ebfd4ee484088951.1668710222.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0e4626de856ef8f25ecd9c716e76d4f95ce95639 Author: Pavel Begunkov Date: Thu Nov 17 18:40:16 2022 +0000 io_uring: fix multishot accept request leaks commit 91482864768a874c4290ef93b84a78f4f1dac51b upstream. Having REQ_F_POLLED set doesn't guarantee that the request is executed as a multishot from the polling path. Fortunately for us, if the code thinks it's multishot issue when it's not, it can only ask to skip completion so leaking the request. Use issue_flags to mark multipoll issues. Cc: stable@vger.kernel.org Fixes: 390ed29b5e425 ("io_uring: add IORING_ACCEPT_MULTISHOT for accept") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/7700ac57653f2823e30b34dc74da68678c0c5f13.1668710222.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 1e0767f7b0bf2f726152dfdb3c7114e935bb95c0 Author: Pavel Begunkov Date: Thu Nov 17 18:40:15 2022 +0000 io_uring: fix tw losing poll events commit 539bcb57da2f58886d7d5c17134236b0ec9cd15d upstream. We may never try to process a poll wake and its mask if there was multiple wake ups racing for queueing up a tw. Force io_poll_check_events() to update the mask by vfs_poll(). Cc: stable@vger.kernel.org Fixes: aa43477b04025 ("io_uring: poll rework") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/00344d60f8b18907171178d7cf598de71d127b0b.1668710222.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 387ea14f2a5e805010e8d56374016533efd87b19 Author: Ilpo Järvinen Date: Tue Nov 8 14:19:51 2022 +0200 serial: 8250_lpss: Use 16B DMA burst with Elkhart Lake commit 7090abd6ad0610a144523ce4ffcb8560909bf2a8 upstream. Configure DMA to use 16B burst size with Elkhart Lake. This makes the bus use more efficient and works around an issue which occurs with the previously used 1B. The fix was initially developed by Srikanth Thokala and Aman Kumar. This together with the previous config change is the cleaned up version of the original fix. Fixes: 0a9410b981e9 ("serial: 8250_lpss: Enable DMA on Intel Elkhart Lake") Cc: # serial: 8250_lpss: Configure DMA also w/o DMA filter Reported-by: Wentong Wu Signed-off-by: Ilpo Järvinen Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221108121952.5497-4-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f4b4f284d3d008871351b2818755e266f3635677 Author: Ilpo Järvinen Date: Tue Nov 8 14:19:50 2022 +0200 serial: 8250_lpss: Configure DMA also w/o DMA filter commit 1bfcbe5805d0cfc83c3544dcd01e0a282c1f6790 upstream. If the platform doesn't use DMA device filter (as is the case with Elkhart Lake), whole lpss8250_dma_setup() setup is skipped. This results in skipping also *_maxburst setup which is undesirable. Refactor lpss8250_dma_setup() to configure DMA even if filter is not setup. Cc: stable Signed-off-by: Ilpo Järvinen Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221108121952.5497-3-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d7a77c225730161957f91cecabcf2ff240fd3c71 Author: Ilpo Järvinen Date: Tue Nov 8 14:19:52 2022 +0200 serial: 8250: Flush DMA Rx on RLSI commit 1980860e0c8299316cddaf0992dd9e1258ec9d88 upstream. Returning true from handle_rx_dma() without flushing DMA first creates a data ordering hazard. If DMA Rx has handled any character at the point when RLSI occurs, the non-DMA path handles any pending characters jumping them ahead of those characters that are pending under DMA. Fixes: 75df022b5f89 ("serial: 8250_dma: Fix RX handling") Cc: Signed-off-by: Ilpo Järvinen Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221108121952.5497-5-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 86cff1f1f4d813b9eb34fb16a132510e25d40325 Author: Ilpo Järvinen Date: Tue Nov 8 14:19:49 2022 +0200 serial: 8250: Fall back to non-DMA Rx if IIR_RDI occurs commit a931237cbea256aff13bb403da13a97b2d1605d9 upstream. DW UART sometimes triggers IIR_RDI during DMA Rx when IIR_RX_TIMEOUT should have been triggered instead. Since IIR_RDI has higher priority than IIR_RX_TIMEOUT, this causes the Rx to hang into interrupt loop. The problem seems to occur at least with some combinations of small-sized transfers (I've reproduced the problem on Elkhart Lake PSE UARTs). If there's already an on-going Rx DMA and IIR_RDI triggers, fall graciously back to non-DMA Rx. That is, behave as if IIR_RX_TIMEOUT had occurred. 8250_omap already considers IIR_RDI similar to this change so its nothing unheard of. Fixes: 75df022b5f89 ("serial: 8250_dma: Fix RX handling") Cc: Co-developed-by: Srikanth Thokala Signed-off-by: Srikanth Thokala Co-developed-by: Aman Kumar Signed-off-by: Aman Kumar Signed-off-by: Ilpo Järvinen Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221108121952.5497-2-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 5398b8e275bf81a2517b327d216c0f37ac9ac5ae Author: Mikulas Patocka Date: Tue Nov 1 16:53:35 2022 -0400 dm ioctl: fix misbehavior if list_versions races with module loading commit 4fe1ec995483737f3d2a14c3fe1d8fe634972979 upstream. __list_versions will first estimate the required space using the "dm_target_iterate(list_version_get_needed, &needed)" call and then will fill the space using the "dm_target_iterate(list_version_get_info, &iter_info)" call. Each of these calls locks the targets using the "down_read(&_lock)" and "up_read(&_lock)" calls, however between the first and second "dm_target_iterate" there is no lock held and the target modules can be loaded at this point, so the second "dm_target_iterate" call may need more space than what was the first "dm_target_iterate" returned. The code tries to handle this overflow (see the beginning of list_version_get_info), however this handling is incorrect. The code sets "param->data_size = param->data_start + needed" and "iter_info.end = (char *)vers+len" - "needed" is the size returned by the first dm_target_iterate call; "len" is the size of the buffer allocated by userspace. "len" may be greater than "needed"; in this case, the code will write up to "len" bytes into the buffer, however param->data_size is set to "needed", so it may write data past the param->data_size value. The ioctl interface copies only up to param->data_size into userspace, thus part of the result will be truncated. Fix this bug by setting "iter_info.end = (char *)vers + needed;" - this guarantees that the second "dm_target_iterate" call will write only up to the "needed" buffer and it will exit with "DM_BUFFER_FULL_FLAG" if it overflows the "needed" space - in this case, userspace will allocate a larger buffer and retry. Note that there is also a bug in list_version_get_needed - we need to add "strlen(tt->name) + 1" to the needed size, not "strlen(tt->name)". Cc: stable@vger.kernel.org Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 2b5f8850d35eff450a39aef8a6623d37edbf6e3e Author: Zhihao Cheng Date: Fri Nov 11 20:10:27 2022 +0800 dm bufio: Fix missing decrement of no_sleep_enabled if dm_bufio_client_create failed commit 0dfc1f4ceae86a0d09d880ab87625c86c61ed33c upstream. The 'no_sleep_enabled' should be decreased in error handling path in dm_bufio_client_create() when the DM_BUFIO_CLIENT_NO_SLEEP flag is set, otherwise static_branch_unlikely() will always return true even if no dm_bufio_client instances have DM_BUFIO_CLIENT_NO_SLEEP flag set. Cc: stable@vger.kernel.org Fixes: 3c1c875d0586 ("dm bufio: conditionally enable branching for DM_BUFIO_CLIENT_NO_SLEEP") Signed-off-by: Zhihao Cheng Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit e1108bd80a1d25be947ba30bad108e68316113f5 Author: Mitja Spes Date: Fri Oct 21 15:58:21 2022 +0200 iio: pressure: ms5611: changed hardcoded SPI speed to value limited commit 741cec30cc52058d1c10d415f3b98319887e4f73 upstream. Don't hardcode the ms5611 SPI speed, limit it instead. Signed-off-by: Mitja Spes Fixes: c0644160a8b5 ("iio: pressure: add support for MS5611 pressure and temperature sensor") Link: https://lore.kernel.org/r/20221021135827.1444793-3-mitja@lxnav.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 1000b2253784ef105ad0d87d1f6fbc80bee4385f Author: Mitja Spes Date: Fri Oct 21 15:58:20 2022 +0200 iio: pressure: ms5611: fixed value compensation bug commit 17f442e7e47579d3881fc4d47354eaef09302e6f upstream. When using multiple instances of this driver the compensation PROM was overwritten by the last initialized sensor. Now each sensor has own PROM storage. Signed-off-by: Mitja Spes Fixes: 9690d81a02dc ("iio: pressure: ms5611: add support for MS5607 temperature and pressure sensor") Link: https://lore.kernel.org/r/20221021135827.1444793-2-mitja@lxnav.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 399b2105a2240e730b9f3880bd8f154247539aa7 Author: Saravanan Sekar Date: Sat Oct 29 11:29:55 2022 +0200 iio: adc: mp2629: fix potential array out of bound access commit ca1547ab15f48dc81624183ae17a2fd1bad06dfc upstream. Add sentinel at end of maps to avoid potential array out of bound access in iio core. Fixes: 7abd9fb64682 ("iio: adc: mp2629: Add support for mp2629 ADC driver") Signed-off-by: Saravanan Sekar Link: https://lore.kernel.org/r/20221029093000.45451-4-sravanhome@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 30015a6264bc1f8a47c3d69cf9d442a02a328f30 Author: Saravanan Sekar Date: Sat Oct 29 11:29:53 2022 +0200 iio: adc: mp2629: fix wrong comparison of channel commit 1eb20332a082fa801fb89c347c5e62de916a4001 upstream. Input voltage channel enum is compared against iio address instead of the channel. Fixes: 7abd9fb64682 ("iio: adc: mp2629: Add support for mp2629 ADC driver") Signed-off-by: Saravanan Sekar Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221029093000.45451-2-sravanhome@gmail.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 2c4e65285bdea23fd36d2ff376006ac64db6f42e Author: Yang Yingliang Date: Sat Oct 22 15:42:12 2022 +0800 iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init() commit efa17e90e1711bdb084e3954fa44afb6647331c0 upstream. dev_set_name() allocates memory for name, it need be freed when device_add() fails, call put_device() to give up the reference that hold in device_initialize(), so that it can be freed in kobject_cleanup() when the refcount hit to 0. Fault injection test can trigger this: unreferenced object 0xffff8e8340a7b4c0 (size 32): comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s) hex dump (first 32 bytes): 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............ backtrace: [<0000000074999de8>] __kmem_cache_alloc_node+0x1e9/0x360 [<00000000497fd30b>] __kmalloc_node_track_caller+0x44/0x1a0 [<000000003636c520>] kstrdup+0x2d/0x60 [<0000000032f84da2>] kobject_set_name_vargs+0x1e/0x90 [<0000000092efe493>] dev_set_name+0x4e/0x70 Fixes: 1f785681a870 ("staging:iio:trigger sysfs userspace trigger rework.") Signed-off-by: Yang Yingliang Cc: Link: https://lore.kernel.org/r/20221022074212.1386424-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit c27a3b6ba23350708cf5ab9962337447b51eb76d Author: Yang Yingliang Date: Mon Oct 24 16:45:11 2022 +0800 iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger() commit 65f20301607d07ee279b0804d11a05a62a6c1a1c upstream. If iio_trigger_register() returns error, it should call iio_trigger_free() to give up the reference that hold in iio_trigger_alloc(), so that it can call iio_trig_release() to free memory when the refcount hit to 0. Fixes: 0e589d5fb317 ("ARM: AT91: IIO: Add AT91 ADC driver.") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221024084511.815096-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 73f39196606c65be6f8b8960f944efeee0d8ebe0 Author: Jonathan Cameron Date: Sun Oct 2 15:41:33 2022 +0100 iio: accel: bma400: Ensure VDDIO is enable defore reading the chip ID. commit 57572cacd36e6d4be7722d7770d23f4430219827 upstream. The regulator enables were after the check on the chip variant, which was very unlikely to return a correct value when not powered. Presumably all the device anyone is testing on have a regulator that is already powered up when this code runs for reasons beyond the scope of this driver. Move the read call down a few lines. Fixes: 3cf7ded15e40 ("iio: accel: bma400: basic regulator support") Signed-off-by: Jonathan Cameron Reviewed-by: Dan Robertson Cc: Link: https://lore.kernel.org/r/20221002144133.3771029-1-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman commit 70551a29ccc2f9973e2eae0b14207aa2c05ab825 Author: Sven Peter Date: Wed Nov 2 17:15:42 2022 +0100 usb: typec: tipd: Prevent uninitialized event{1,2} in IRQ handler commit 6d8fc203b28ff8f6115fbe5eaf584de8b824f4fa upstream. If reading TPS_REG_INT_EVENT1/2 fails in the interrupt handler event1 and event2 may be uninitialized when they are used to determine IRQ_HANDLED vs. IRQ_NONE in the error path. Fixes: c7260e29dd20 ("usb: typec: tipd: Add short-circuit for no irqs") Fixes: 45188f27b3d0 ("usb: typec: tipd: Add support for Apple CD321X") Cc: stable Signed-off-by: Sven Peter Reviewed-by: Eric Curtin Reviewed-by: Heikki Krogerus Reviewed-by: Guido Günther Link: https://lore.kernel.org/r/20221102161542.30669-1-sven@svenpeter.dev Signed-off-by: Greg Kroah-Hartman commit 0077ba996b339f01e20c7553c4592566302e8ab0 Author: Rajat Khandelwal Date: Mon Oct 24 22:46:11 2022 +0530 usb: typec: mux: Enter safe mode only when pins need to be reconfigured commit 40bf8f162d0f95e0716e479d7db41443d931765c upstream. There is no point to enter safe mode during DP/TBT configuration if the DP/TBT was already configured in mux. This is because safe mode is only applicable when there is a need to reconfigure the pins in order to avoid damage within/to port partner. In some chrome systems, IOM/mux is already configured before OS comes up. Thus, when driver is probed, it blindly enters safe mode due to PD negotiations but only after gfx driver lowers dp_phy_ownership, will the IOM complete safe mode and send an ack to PMC. Since, that never happens, we see IPC timeout. Hence, allow safe mode only when pin reconfiguration is not required, which makes sense. Fixes: 43d596e32276 ("usb: typec: intel_pmc_mux: Check the port status before connect") Cc: stable Signed-off-by: Rajat Khandelwal Signed-off-by: Lee Shawn C Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20221024171611.181468-1-rajat.khandelwal@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit f89d62a6658e284581571eef232832c1acedbec5 Author: Li Jun Date: Wed Oct 26 15:07:49 2022 -0400 usb: cdns3: host: fix endless superspeed hub port reset commit 9d5333c931347005352d5b8beaa43528c94cfc9c upstream. When usb 3.0 hub connect with one USB 2.0 device and NO USB 3.0 device, some usb hub reports endless port reset message. [ 190.324169] usb 2-1: new SuperSpeed USB device number 88 using xhci-hcd [ 190.352834] hub 2-1:1.0: USB hub found [ 190.356995] hub 2-1:1.0: 4 ports detected [ 190.700056] usb 2-1: USB disconnect, device number 88 [ 192.472139] usb 2-1: new SuperSpeed USB device number 89 using xhci-hcd [ 192.500820] hub 2-1:1.0: USB hub found [ 192.504977] hub 2-1:1.0: 4 ports detected [ 192.852066] usb 2-1: USB disconnect, device number 89 The reason is the runtime pm state of USB2.0 port is active and USB 3.0 port is suspend, so parent device is active state. cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/usb2/power/runtime_status suspended cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/usb1/power/runtime_status active cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/xhci-hcd.1.auto/power/runtime_status active cat /sys/bus/platform/devices/5b110000.usb/5b130000.usb/power/runtime_status active So xhci_cdns3_suspend_quirk() have not called. U3 configure is not applied. move U3 configure into host start. Reinit again in resume function in case controller power lost during suspend. Cc: stable@vger.kernel.org 5.10 Signed-off-by: Li Jun Signed-off-by: Frank Li Reviewed-by: Peter Chen Acked-by: Alexander Stein Link: https://lore.kernel.org/r/20221026190749.2280367-1-Frank.Li@nxp.com Signed-off-by: Greg Kroah-Hartman commit 796006db9a8c0b3a04c57e6dd941da4d40a18c92 Author: Duoming Zhou Date: Sun Sep 18 11:33:12 2022 +0800 usb: chipidea: fix deadlock in ci_otg_del_timer commit 7a58b8d6021426b796eebfae80983374d9a80a75 upstream. There is a deadlock in ci_otg_del_timer(), the process is shown below: (thread 1) | (thread 2) ci_otg_del_timer() | ci_otg_hrtimer_func() ... | spin_lock_irqsave() //(1) | ... ... | hrtimer_cancel() | spin_lock_irqsave() //(2) (block forever) We hold ci->lock in position (1) and use hrtimer_cancel() to wait ci_otg_hrtimer_func() to stop, but ci_otg_hrtimer_func() also need ci->lock in position (2). As a result, the hrtimer_cancel() in ci_otg_del_timer() will be blocked forever. This patch extracts hrtimer_cancel() from the protection of spin_lock_irqsave() in order that the ci_otg_hrtimer_func() could obtain the ci->lock. What`s more, there will be no race happen. Because the "next_timer" is always under the protection of spin_lock_irqsave() and we only check whether "next_timer" equals to NUM_OTG_FSM_TIMERS in the following code. Fixes: 3a316ec4c91c ("usb: chipidea: use hrtimer for otg fsm timers") Cc: stable Signed-off-by: Duoming Zhou Link: https://lore.kernel.org/r/20220918033312.94348-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman commit 617047dbf551e006fc82497400b0ad55513d2782 Author: Nicolas Dumazet Date: Wed Nov 9 13:29:46 2022 +0100 usb: add NO_LPM quirk for Realforce 87U Keyboard commit 181135bb20dcb184edd89817831b888eb8132741 upstream. Before adding this quirk, this (mechanical keyboard) device would not be recognized, logging: new full-speed USB device number 56 using xhci_hcd unable to read config index 0 descriptor/start: -32 chopping to 0 config(s) It would take dozens of plugging/unpuggling cycles for the keyboard to be recognized. Keyboard seems to simply work after applying this quirk. This issue had been reported by users in two places already ([1], [2]) but nobody tried upstreaming a patch yet. After testing I believe their suggested fix (DELAY_INIT + NO_LPM + DEVICE_QUALIFIER) was probably a little overkill. I assume this particular combination was tested because it had been previously suggested in [3], but only NO_LPM seems sufficient for this device. [1]: https://qiita.com/float168/items/fed43d540c8e2201b543 [2]: https://blog.kostic.dev/posts/making-the-realforce-87ub-work-with-usb30-on-Ubuntu/ [3]: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678477 Cc: stable@vger.kernel.org Signed-off-by: Nicolas Dumazet Link: https://lore.kernel.org/r/20221109122946.706036-1-ndumazet@google.com Signed-off-by: Greg Kroah-Hartman commit c3177f46e69fed794115ba929b18ecb1bebfa1b8 Author: Reinhard Speyerer Date: Wed Nov 9 22:24:15 2022 +0100 USB: serial: option: add Fibocom FM160 0x0111 composition commit 148f4b32b4504d8a32cf82049b7b9499a4b299ab upstream. Add support for the following Fibocom FM160 composition: 0x0111: MBIM + MODEM + DIAG + AT T: Bus=01 Lev=02 Prnt=125 Port=01 Cnt=02 Dev#= 93 Spd=480 MxCh= 0 D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=2cb7 ProdID=0111 Rev= 5.04 S: Manufacturer=Fibocom S: Product=Fibocom FM160 Modem_SN:12345678 S: SerialNumber=12345678 C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=0e Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=0e Prot=00 Driver=cdc_mbim E: Ad=81(I) Atr=03(Int.) MxPS= 64 Ivl=32ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I:* If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Reinhard Speyerer Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 9002caa4353f4dd80c5b5cdf57bdc62527a3a7d3 Author: Davide Tronchin Date: Wed Nov 16 16:59:50 2022 +0100 USB: serial: option: add u-blox LARA-L6 modem commit c1547f12df8b8e9ca2686accee43213ecd117efe upstream. Add LARA-L6 PIDs for three different USB compositions. LARA-L6 module can be configured (by AT interface) in three different USB modes: * Default mode (Vendor ID: 0x1546 Product ID: 0x1341) with 4 serial interfaces * RmNet mode (Vendor ID: 0x1546 Product ID: 0x1342) with 4 serial interfaces and 1 RmNet virtual network interface * CDC-ECM mode (Vendor ID: 0x1546 Product ID: 0x1343) with 4 serial interface and 1 CDC-ECM virtual network interface In default mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parser/alternative functions In RmNet mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parset/alternative functions If 4: RMNET interface In CDC-ECM mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parset/alternative functions If 4: CDC-ECM interface Signed-off-by: Davide Tronchin [ johan: drop PID defines in favour of comments ] Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit e254bdc27b3741bcbae82ac71414beab6a131a7e Author: Davide Tronchin Date: Wed Nov 16 16:59:49 2022 +0100 USB: serial: option: add u-blox LARA-R6 00B modem commit d9e37a5c4d80ea25a7171ab8557a449115554e76 upstream. The official LARA-R6 (00B) modem uses 0x908b PID. LARA-R6 00B does not implement a QMI interface on port 4, the reservation (RSVD(4)) has been added to meet other companies that implement QMI on that interface. LARA-R6 00B USB composition exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parser/alternative functions Signed-off-by: Davide Tronchin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 75655cd62bbeb1017a7a87ce1a18074fdd71a146 Author: Davide Tronchin Date: Wed Nov 16 16:59:48 2022 +0100 USB: serial: option: remove old LARA-R6 PID commit 2ec106b96afc19698ff934323b633c0729d4c7f8 upstream. Remove the UBLOX_PRODUCT_R6XX 0x90fa association since LARA-R6 00B final product uses a new USB composition with different PID. 0x90fa PID used only by LARA-R6 internal prototypes. Move 0x90fa PID directly in the option_ids array since used by other Qualcomm based modem vendors as pointed out in: https://lore.kernel.org/all/6572c4e6-d8bc-b8d3-4396-d879e4e76338@gmail.com Signed-off-by: Davide Tronchin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 0d4a3b20c46786fca325a21229298500515b26f2 Author: Benoît Monin Date: Thu Oct 13 16:26:48 2022 +0200 USB: serial: option: add Sierra Wireless EM9191 commit df3414b0a245f43476061fddd78cee7d6cff797f upstream. Add support for the AT and diag ports, similar to other qualcomm SDX55 modems. In QDL mode, the modem uses a different device ID and support is provided by qcserial in commit 11c52d250b34 ("USB: serial: qcserial: add EM9191 QDL support"). T: Bus=08 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0 D: Ver= 3.20 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=1199 ProdID=90d3 Rev=00.06 S: Manufacturer=Sierra Wireless, Incorporated S: Product=Sierra Wireless EM9191 S: SerialNumber=xxxxxxxxxxxxxxxx C: #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=896mA I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim I: If#=0x1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim I: If#=0x3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#=0x4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none) Signed-off-by: Benoît Monin Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 92597992a561a5fed78049a2d2f069c11e3518d9 Author: Linus Walleij Date: Mon Nov 7 10:07:53 2022 +0100 USB: bcma: Make GPIO explicitly optional commit cd136706b4f925aa5d316642543babac90d45910 upstream. What the code does is to not check the return value from devm_gpiod_get() and then avoid using an erroneous GPIO descriptor with IS_ERR_OR_NULL(). This will miss real errors from the GPIO core that should not be ignored, such as probe deferral. Instead request the GPIO as explicitly optional, which means that if it doesn't exist, the descriptor returned will be NULL. Then we can add error handling and also avoid just doing this on the device tree path, and simplify the site where the optional GPIO descriptor is used. There were some problems with cleaning up this GPIO descriptor use in the past, but this is the proper way to deal with it. Cc: Rafał Miłecki Cc: Chuhong Yuan Signed-off-by: Linus Walleij Cc: stable Link: https://lore.kernel.org/r/20221107090753.1404679-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman commit 1c95b57da3814d4c881700021a3f44a7be37d6f5 Author: Đoàn Trần Công Danh Date: Mon Oct 17 15:09:36 2022 +0700 speakup: replace utils' u_char with unsigned char commit 92ca969ff8815f3feef2645199bd39bf594e5eeb upstream. drivers/accessibility/speakup/utils.h will be used to compile host tool to generate metadata. "u_char" is a non-standard type, which is defined to "unsigned char" on glibc but not defined by some libc, e.g. musl. Let's replace "u_char" with "unsigned char" Signed-off-by: Đoàn Trần Công Danh Reviewed-by: Samuel Thibault Cc: stable Link: https://lore.kernel.org/r/b75743026aaee2d81efe3d7f2e8fa47f7d0b8ea7.1665736571.git.congdanhqx@gmail.com Signed-off-by: Greg Kroah-Hartman commit d11e198bcf70a8719a942739e95316590e753ef6 Author: Mushahid Hussain Date: Mon Oct 10 21:57:20 2022 +0500 speakup: fix a segfault caused by switching consoles commit 0fc801f8018000c8e64a275a20cb1da7c54e46df upstream. This patch fixes a segfault by adding a null check on synth in speakup_con_update(). The segfault can be reproduced as follows: - Login into a text console - Load speakup and speakup_soft modules - Remove speakup_soft - Switch to a graphics console This is caused by lack of a null check on `synth` in speakup_con_update(). Here's the sequence that causes the segfault: - When we remove the speakup_soft, synth_release() sets the synth to null. - After that, when we change the virtual console to graphics console, vt_notifier_call() is fired, which then calls speakup_con_update(). - Inside speakup_con_update() there's no null check on synth, so it calls synth_printf(). - Inside synth_printf(), synth_buffer_add() and synth_start(), both access synth, when it is null and causing a segfault. Therefore adding a null check on synth solves the issue. Fixes: 2610df41489f ("staging: speakup: Add pause command used on switching to graphical mode") Cc: stable Signed-off-by: Mushahid Hussain Signed-off-by: Samuel Thibault Link: https://lore.kernel.org/r/20221010165720.397042-1-mushi.shar@gmail.com Signed-off-by: Greg Kroah-Hartman commit 93483ccacce587c7211f17a8c577b560229b6ff3 Author: Krzysztof Kozlowski Date: Thu Sep 29 18:52:02 2022 +0200 slimbus: stream: correct presence rate frequencies commit b9c1939627f8185dec8ba6d741e9573a4c7a5834 upstream. Correct few frequencies in presence rate table - multiplied by 10 (110250 instead of 11025 Hz). Fixes: abb9c9b8b51b ("slimbus: stream: add stream support") Cc: Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20220929165202.410937-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9d2427f36c5c4ebf8294bc48f0c0190f4cdf0485 Author: Zheng Bin Date: Thu Oct 27 17:59:04 2022 +0800 slimbus: qcom-ngd: Fix build error when CONFIG_SLIM_QCOM_NGD_CTRL=y && CONFIG_QCOM_RPROC_COMMON=m commit e54fad8044db18cc400df8d01bfb86cada08b7cb upstream. If CONFIG_SLIM_QCOM_NGD_CTRL=y, CONFIG_QCOM_RPROC_COMMON=m, COMPILE_TEST=y, bulding fails: drivers/slimbus/qcom-ngd-ctrl.o: In function `qcom_slim_ngd_ctrl_probe': qcom-ngd-ctrl.c:(.text+0x330): undefined reference to `qcom_register_ssr_notifier' qcom-ngd-ctrl.c:(.text+0x5fc): undefined reference to `qcom_unregister_ssr_notifier' drivers/slimbus/qcom-ngd-ctrl.o: In function `qcom_slim_ngd_remove': qcom-ngd-ctrl.c:(.text+0x90c): undefined reference to `qcom_unregister_ssr_notifier' Make SLIM_QCOM_NGD_CTRL depends on QCOM_RPROC_COMMON || (COMPILE_TEST && !QCOM_RPROC_COMMON) to fix this. Fixes: e291691c6977 ("slimbus: qcom-ngd-ctrl: allow compile testing without QCOM_RPROC_COMMON") Cc: stable Signed-off-by: Zheng Bin Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20221027095904.3388959-1-zhengbin13@huawei.com Signed-off-by: Greg Kroah-Hartman commit 0930a5b397632a2806886a45182d75f93fd8e18b Author: Tiago Dias Ferreira Date: Wed Nov 16 00:17:56 2022 -0300 nvme-pci: add NVME_QUIRK_BOGUS_NID for Netac NV7000 commit 8d6e38f636ac063e8062a21e7616f7d9bf0df5d8 upstream. Added a quirk to fix the Netac NV7000 SSD reporting duplicate NGUIDs. Cc: Signed-off-by: Tiago Dias Ferreira Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit ec973d8be81e405c3fb47700ffa1b0ef23692d9d Author: Bean Huo Date: Mon Nov 14 14:48:52 2022 +0100 nvme-pci: add NVME_QUIRK_BOGUS_NID for Micron Nitro commit d5ceb4d1c50786d21de3d4b06c3f43109ec56dd8 upstream. Added a quirk to fix Micron Nitro NVMe reporting duplicate NGUIDs. Cc: Signed-off-by: Bean Huo Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 6bb2881939aa21a1bc5d4b9081f854836d07f5aa Author: Pavel Begunkov Date: Thu Nov 17 18:40:14 2022 +0000 io_uring: update res mask in io_poll_check_events commit b98186aee22fa593bc8c6b2c5d839c2ee518bc8c upstream. When io_poll_check_events() collides with someone attempting to queue a task work, it'll spin for one more time. However, it'll continue to use the mask from the first iteration instead of updating it. For example, if the first wake up was a EPOLLIN and the second EPOLLOUT, the userspace will not get EPOLLOUT in time. Clear the mask for all subsequent iterations to force vfs_poll(). Cc: stable@vger.kernel.org Fixes: aa43477b04025 ("io_uring: poll rework") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/2dac97e8f691231049cb259c4ae57e79e40b537c.1668710222.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit b89be1e2f4720721a0ecc438d639f918628416af Author: Janne Grunau Date: Sun Nov 6 22:48:04 2022 +0100 usb: dwc3: Do not get extcon device when usb-role-switch is used commit d68cc25b7c7fb3034c5a5b5f350a0b858c6d5a45 upstream. The change breaks device tree based platforms with PHY device and use usb-role-switch instead of an extcon switch. extcon_find_edev_by_node() will return EPROBE_DEFER if it can not find a device so probing without an extcon device will be deferred indefinitely. Fix this by explicitly checking for usb-role-switch. At least the out-of-tree USB3 support on Apple silicon based platforms using dwc3 with tipd USB Type-C and PD controller is affected by this issue. Fixes: d182c2e1bc92 ("usb: dwc3: Don't switch OTG -> peripheral if extcon is present") Cc: stable@kernel.org Signed-off-by: Janne Grunau Acked-by: Thinh Nguyen Reviewed-by: Sven Peter Link: https://lore.kernel.org/r/20221106214804.2814-1-j@jannau.net Signed-off-by: Greg Kroah-Hartman commit b9afcbe47e1e24488ae647921d92df41bca35f82 Author: Johan Hovold Date: Thu Nov 3 15:46:48 2022 +0100 Revert "usb: dwc3: disable USB core PHY management" commit 5c294de36e7fb3e0cba0c4e1ef9a5f57bc080d0f upstream. This reverts commit 6000b8d900cd5f52fbcd0776d0cc396e88c8c2ea. The offending commit disabled the USB core PHY management as the dwc3 already manages the PHYs in question. Unfortunately some platforms have started relying on having USB core also controlling the PHY and this is specifically currently needed on some Exynos platforms for PHY calibration or connected device may fail to enumerate. The PHY calibration was previously handled in the dwc3 driver, but to work around some issues related to how the dwc3 driver interacts with xhci (e.g. using multiple drivers) this was moved to USB core by commits 34c7ed72f4f0 ("usb: core: phy: add support for PHY calibration") and a0a465569b45 ("usb: dwc3: remove generic PHY calibrate() calls"). The same PHY obviously should not be controlled from two different places, which for example do no agree on the PHY mode or power state during suspend, but as the offending patch was backported to stable, let's revert it for now. Reported-by: Stefan Agner Link: https://lore.kernel.org/lkml/808bdba846bb60456adf10a3016911ee@agner.ch/ Fixes: 6000b8d900cd ("usb: dwc3: disable USB core PHY management") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Tested-by: Marek Szyprowski Acked-by: Thinh Nguyen Link: https://lore.kernel.org/r/20221103144648.14197-1-johan+linaro@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9862a9b36317c769b8c5f869d32c1fb1854be638 Author: Takashi Iwai Date: Tue Nov 15 18:02:35 2022 +0100 ALSA: hda/realtek: Fix the speaker output on Samsung Galaxy Book Pro 360 commit 1abfd71ee8f3ed99c5d0df5d9843a360541d6808 upstream. Samsung Galaxy Book Pro 360 (13" 2021 NP930QBD-ke1US) with codec SSID 144d:c1a6 requires the same workaround for enabling the speaker amp like other Samsung models with ALC298 codec. Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1205100 Cc: Link: https://lore.kernel.org/r/20221115170235.18875-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 25a0c6fc7122f051205d123a9c97b693f937fc03 Author: Emil Flink Date: Tue Nov 15 15:45:01 2022 +0100 ALSA: hda/realtek: fix speakers for Samsung Galaxy Book Pro commit b18a456330e1c1ca207b57b45872f10336741388 upstream. The Samsung Galaxy Book Pro seems to have the same issue as a few other Samsung laptops, detailed in kernel bug report 207423. Sound from headphone jack works, but not the built-in speakers. alsa-info: http://alsa-project.org/db/?f=b40ba609dc6ae28dc84ad404a0d8a4bbcd8bea6d Signed-off-by: Emil Flink Cc: Link: https://lore.kernel.org/r/20221115144500.7782-1-emil.flink@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 00f5f1bbf815a39e9eecb468d12ca55d3360eb10 Author: Takashi Iwai Date: Sat Nov 12 15:12:23 2022 +0100 ALSA: usb-audio: Drop snd_BUG_ON() from snd_usbmidi_output_open() commit ad72c3c3f6eb81d2cb189ec71e888316adada5df upstream. snd_usbmidi_output_open() has a check of the NULL port with snd_BUG_ON(). snd_BUG_ON() was used as this shouldn't have happened, but in reality, the NULL port may be seen when the device gives an invalid endpoint setup at the descriptor, hence the driver skips the allocation. That is, the check itself is valid and snd_BUG_ON() should be dropped from there. Otherwise it's confusing as if it were a real bug, as recently syzbot stumbled on it. Reported-by: syzbot+9abda841d636d86c41da@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/syzbot+9abda841d636d86c41da@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20221112141223.6144-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b89752a70e8a8239ac6dfb001ed9630816efd802 Author: Dillon Varone Date: Thu Nov 3 18:33:38 2022 -0400 drm/amd/display: Fix prefetch calculations for dcn32 commit 246e667079e8d0fc85f842bceca8c5a3c5da5905 upstream. [Description] Prefetch calculation loop was not exiting until utilizing all of vstartup if it failed once. Locals need to be reset on each iteration of the loop. Reviewed-by: Jun Lei Acked-by: Tom Chung Signed-off-by: Dillon Varone Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 8ced891e6980d557b0cea90b30a39bd8b169bb15 Author: Melissa Wen Date: Thu Nov 3 17:45:00 2022 -0100 drm/amd/display: don't enable DRM CRTC degamma property for DCE commit 0e444a4de6b38c4593a07e4cfb5bf54c40cc79b6 upstream. DM maps DRM CRTC degamma to DPP (pre-blending) degamma block, but DCE doesn't support programmable degamma curve anywhere. Currently, a custom degamma is accepted by DM but just ignored by DCE driver and degamma correction isn't actually applied. There is no way to map custom degamma in DCE, therefore, DRM CRTC degamma property shouldn't be enabled for DCE drivers. Reviewed-by: Rodrigo Siqueira Signed-off-by: Melissa Wen Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f67ef5aa88e3db0a13ae3befab2ddf14ac00a91c Author: Roman Li Date: Thu Nov 3 17:33:07 2022 -0400 drm/amd/display: Fix optc2_configure warning on dcn314 commit e7e4f77c991c9abf90924929a9d55f90b0bb78de upstream. [Why] dcn314 uses optc2_configure_crc() that wraps optc1_configure_crc() + set additional registers not applicable to dcn314. It's not critical but when used leads to warning like: WARNING: drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c Call Trace: generic_reg_set_ex+0x6d/0xe0 [amdgpu] optc2_configure_crc+0x60/0x80 [amdgpu] dc_stream_configure_crc+0x129/0x150 [amdgpu] amdgpu_dm_crtc_configure_crc_source+0x5d/0xe0 [amdgpu] [How] Use optc1_configure_crc() directly Reviewed-by: Nicholas Kazlauskas Acked-by: Tom Chung Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 2c323f5a8fb8bee604b827e2b0bfbb1480379a18 Author: George Shen Date: Wed Nov 2 15:06:48 2022 -0400 drm/amd/display: Support parsing VRAM info v3.0 from VBIOS commit 7e952a18eb978a3e51fc1704b752378be66226b2 upstream. [Why] For DCN3.2 and DCN3.21, VBIOS has switch to using v3.0 of the VRAM info struct. We should read and override the VRAM info in driver with values provided by VBIOS to support memory downbin cases. Reviewed-by: Alvin Lee Acked-by: Tom Chung Signed-off-by: George Shen Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 37eaaaf52efb091eb5f1e6aad1015e1a16c1ebb7 Author: Stylon Wang Date: Mon Oct 24 15:36:16 2022 +0800 drm/amd/display: Fix access timeout to DPIA AUX at boot time commit 0d502ef8898b3983eef9e40f50dfe100a0de5d93 upstream. [Why] Since introduction of patch "Query DPIA HPD status.", link detection at boot could be accessing DPIA AUX, which will not succeed until DMUB outbox messaging is enabled and results in below dmesg logs: [ 160.840227] [drm:amdgpu_dm_process_dmub_aux_transfer_sync [amdgpu]] *ERROR* wait_for_completion_timeout timeout! [How] Enable DMUB outbox messaging before link detection at boot time. Reviewed-by: Wayne Lin Acked-by: Tom Chung Signed-off-by: Stylon Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 4fca4ac89715b96934b6660151eaa4841f7a028e Author: Rodrigo Siqueira Date: Mon Oct 31 14:58:12 2022 -0400 drm/amd/display: Add HUBP surface flip interrupt handler commit 7af87fc1ba136143314c870059b8f60180247cbd upstream. On IGT, there is a test named amd_hotplug, and when the subtest basic is executed on DCN31, we get the following error: [drm] *ERROR* [CRTC:71:crtc-0] flip_done timed out [drm] *ERROR* flip_done timed out [drm] *ERROR* [CRTC:71:crtc-0] commit wait timed out [drm] *ERROR* flip_done timed out [drm] *ERROR* [CONNECTOR:88:DP-1] commit wait timed out [drm] *ERROR* flip_done timed out [drm] *ERROR* [PLANE:59:plane-3] commit wait timed out After enable the page flip log with the below command: echo -n 'format "[PFLIP]" +p' > /sys/kernel/debug/dynamic_debug/control It is possible to see that the flip was submitted, but DC never replied back, which generates time-out issues. This is an indication that the HUBP surface flip is missing. This commit fixes this issue by adding hubp1_set_flip_int to DCN31. Reviewed-by: Nicholas Kazlauskas Acked-by: Tom Chung Signed-off-by: Rodrigo Siqueira Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 09b55677d33363b9b65c0b91875a07427f01dab8 Author: Stylon Wang Date: Wed Oct 26 21:00:40 2022 +0800 drm/amd/display: Fix invalid DPIA AUX reply causing system hang commit 8d8494c3467d366eb0f7c8198dab80be8bdc47d2 upstream. [Why] Some DPIA AUX replies have incorrect data length from original request. This could lead to overwriting of destination buffer if reply length is larger, which could cause invalid access to stack since many destination buffers are declared as local variables. [How] Check for invalid length from DPIA AUX replies and trigger a retry if reply length is not the same as original request. A DRM_WARN() dmesg log is also produced. Reviewed-by: Roman Li Acked-by: Tom Chung Signed-off-by: Stylon Wang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 2f341d774089d2fe3fffeec8d3d512f49bed12e4 Author: Simon Rettberg Date: Thu Oct 6 11:33:14 2022 +0200 drm/display: Don't assume dual mode adaptors support i2c sub-addressing commit 5954acbacbd1946b96ce8ee799d309cb0cd3cb9d upstream. Current dual mode adaptor ("DP++") detection code assumes that all adaptors support i2c sub-addressing for read operations from the DP-HDMI adaptor ID buffer. It has been observed that multiple adaptors do not in fact support this, and always return data starting at register 0. On affected adaptors, the code fails to read the proper registers that would identify the device as a type 2 adaptor, and handles those as type 1, limiting the TMDS clock to 165MHz, even if the according register would announce a higher TMDS clock. Fix this by always reading the ID buffer starting from offset 0, and discarding any bytes before the actual offset of interest. We tried finding authoritative documentation on whether or not this is allowed behaviour, but since all the official VESA docs are paywalled, the best we could come up with was the spec sheet for Texas Instruments' SNx5DP149 chip family.[1] It explicitly mentions that sub-addressing is supported for register writes, but *not* for reads (See NOTE in section 8.5.3). Unless TI openly decided to violate the VESA spec, one could take that as a hint that sub-addressing is in fact not mandated by VESA. The other two adaptors affected used the PS8409(A) and the LT8611, according to the data returned from their ID buffers. [1] https://www.ti.com/lit/ds/symlink/sn75dp149.pdf Cc: stable@vger.kernel.org Signed-off-by: Simon Rettberg Reviewed-by: Rafael Gieschke Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20221006113314.41101987@computer Acked-by: Jani Nikula Signed-off-by: Greg Kroah-Hartman commit 6aa4b780ad8b2cc5f4459240750c10f7fb3b1a95 Author: Evan Quan Date: Tue Nov 8 15:52:20 2022 +0800 drm/amd/pm: fix SMU13 runpm hang due to unintentional workaround commit 4b14841c9a820e484bc8c4c3f5a6fed1bc528cbc upstream. The workaround designed for some specific ASICs is wrongly applied to SMU13 ASICs. That leads to some runpm hang. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 188dc70d10443245069a1238a81f08f16318de43 Author: Evan Quan Date: Tue Nov 8 15:44:46 2022 +0800 drm/amd/pm: enable runpm support over BACO for SMU13.0.0 commit 8652da45d09abe1b3174dbb80dc5176b8c3fa08e upstream. Enable SMU13.0.0 runpm support. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 22ac85bd14783c4933f545edc5f5a98f6df1346a Author: Evan Quan Date: Tue Nov 8 16:07:39 2022 +0800 drm/amd/pm: enable runpm support over BACO for SMU13.0.7 commit df7c013efc1a0da8861099802b2d6ab2aacaeb1b upstream. Enable SMU13.0.7 runpm support. Signed-off-by: Evan Quan Reviewed-by: Hawking Zhang Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 6.0.x Signed-off-by: Greg Kroah-Hartman commit 1f0950a0414dbfab773952b1c586f7afce4eb535 Author: Shyam Sundar S K Date: Wed Nov 9 14:03:46 2022 +0530 platform/x86/amd: pmc: Add new ACPI ID AMDI0009 commit 6412518f5cb953cbd84b6746db9741bfc92be40a upstream. Add new a new ACPI ID AMDI0009 used by upcoming AMD platform to the pmc supported list of devices. Cc: stable@vger.kernel.org # 6.0 Signed-off-by: Shyam Sundar S K Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/20221109083346.361603-1-Shyam-sundar.S-k@amd.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 1bc1eaf5afab4e352e9ec6cc4a7fac9600b4e7f2 Author: Mario Limonciello Date: Mon Nov 7 20:33:23 2022 -0600 platform/x86/amd: pmc: Remove more CONFIG_DEBUG_FS checks commit a5b5fb0fc47ddc7d1ed6a0365197639a01bc1f3a upstream. commit b37fe34c8309 ("platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks") removed most CONFIG_DEBUG_FS checks, but there were some left that were reported to cause compile test failures. Remove the remaining checks, and also the unnecessary CONFIG_SUSPEND used in the same place. Reported-by: liyupeng@zbhlos.com Fixes: b37fe34c8309 ("platform/x86/amd: pmc: remove CONFIG_DEBUG_FS checks") Signed-off-by: Mario Limonciello Link: https://bugzilla.kernel.org/show_bug.cgi?id=216679 Link: https://lore.kernel.org/r/20221108023323.19304-1-mario.limonciello@amd.com Cc: stable@vger.kernel.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit cbc5d1f9a8cc40ba2bc6779b36d2ea1f65bc027c Author: Yi Yang Date: Fri Nov 18 10:15:34 2022 +0900 rethook: fix a potential memleak in rethook_alloc() commit 0a1ebe35cb3b7aa1f4b26b37e2a0b9ae68dc4ffb upstream. In rethook_alloc(), the variable rh is not freed or passed out if handler is NULL, which could lead to a memleak, fix it. Link: https://lore.kernel.org/all/20221110104438.88099-1-yiyang13@huawei.com/ [Masami: Add "rethook:" tag to the title.] Fixes: 54ecbe6f1ed5 ("rethook: Add a generic return hook") Cc: stable@vger.kernel.org Signed-off-by: Yi Yang Acke-by: Masami Hiramatsu (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 510c12f93674ea0a1423b24f36c67357168a262a Author: Shang XiaoJing Date: Fri Nov 18 10:15:34 2022 +0900 tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit() commit 22ea4ca9631eb137e64e5ab899e9c89cb6670959 upstream. When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it will goto delete, which will call kprobe_event_delete() and release the corresponding resource. However, the trace_array in gen_kretprobe_test will point to the invalid resource. Set gen_kretprobe_test to NULL after called kprobe_event_delete() to prevent null-ptr-deref. BUG: kernel NULL pointer dereference, address: 0000000000000070 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 246 Comm: modprobe Tainted: G W 6.1.0-rc1-00174-g9522dc5c87da-dirty #248 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0 Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 <44> 8b 65 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000 RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001 R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064 R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000 FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __ftrace_set_clr_event+0x3e/0x60 trace_array_set_clr_event+0x35/0x50 ? 0xffffffffa0000000 kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test] __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f89eeb061b7 Link: https://lore.kernel.org/all/20221108015130.28326-3-shangxiaojing@huawei.com/ Fixes: 64836248dda2 ("tracing: Add kprobe event command generation test module") Signed-off-by: Shang XiaoJing Cc: stable@vger.kernel.org Acked-by: Masami Hiramatsu (Google) Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit fd0efd4f7bfe611a8339ba01bc2ac3c33e79159d Author: Shang XiaoJing Date: Fri Nov 18 10:15:33 2022 +0900 tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit() commit e0d75267f59d7084e0468bd68beeb1bf9c71d7c0 upstream. When trace_get_event_file() failed, gen_kretprobe_test will be assigned as the error code. If module kprobe_event_gen_test is removed now, the null pointer dereference will happen in kprobe_event_gen_test_exit(). Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL before dereference them. BUG: kernel NULL pointer dereference, address: 0000000000000012 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 2210 Comm: modprobe Not tainted 6.1.0-rc1-00171-g2159299a3b74-dirty #217 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test] Code: Unable to access opcode bytes at 0xffffffff9ffffff2. RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246 RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000 RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800 R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __x64_sys_delete_module+0x206/0x380 ? lockdep_hardirqs_on_prepare+0xd8/0x190 ? syscall_enter_from_user_mode+0x1c/0x50 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://lore.kernel.org/all/20221108015130.28326-2-shangxiaojing@huawei.com/ Fixes: 64836248dda2 ("tracing: Add kprobe event command generation test module") Signed-off-by: Shang XiaoJing Acked-by: Masami Hiramatsu (Google) Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu (Google) Signed-off-by: Greg Kroah-Hartman commit 73f5191467ffe3af82f27fe0ea6a8c2fac724d3f Author: Steven Rostedt (Google) Date: Thu Nov 17 21:42:49 2022 -0500 tracing: Fix race where eprobes can be called before the event commit 94eedf3dded5fb472ce97bfaf3ac1c6c29c35d26 upstream. The flag that tells the event to call its triggers after reading the event is set for eprobes after the eprobe is enabled. This leads to a race where the eprobe may be triggered at the beginning of the event where the record information is NULL. The eprobe then dereferences the NULL record causing a NULL kernel pointer bug. Test for a NULL record to keep this from happening. Link: https://lore.kernel.org/linux-trace-kernel/20221116192552.1066630-1-rafaelmendsr@gmail.com/ Link: https://lore.kernel.org/linux-trace-kernel/20221117214249.2addbe10@gandalf.local.home Cc: Linux Trace Kernel Cc: Tzvetomir Stoyanov Cc: Tom Zanussi Cc: stable@vger.kernel.org Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events") Acked-by: Masami Hiramatsu (Google) Reported-by: Rafael Mendonca Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit a5bfa53e5036b3e7a80be902dd3719a930accabd Author: Shang XiaoJing Date: Thu Nov 17 09:23:46 2022 +0800 tracing: Fix wild-memory-access in register_synth_event() commit 1b5f1c34d3f5a664a57a5a7557a50e4e3cc2505c upstream. In register_synth_event(), if set_synth_event_print_fmt() failed, then both trace_remove_event_call() and unregister_trace_event() will be called, which means the trace_event_call will call __unregister_trace_event() twice. As the result, the second unregister will causes the wild-memory-access. register_synth_event set_synth_event_print_fmt failed trace_remove_event_call event_remove if call->event.funcs then __unregister_trace_event (first call) unregister_trace_event __unregister_trace_event (second call) Fix the bug by avoiding to call the second __unregister_trace_event() by checking if the first one is called. general protection fault, probably for non-canonical address 0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] CPU: 0 PID: 3807 Comm: modprobe Not tainted 6.1.0-rc1-00186-g76f33a7eedb4 #299 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregister_trace_event+0x6e/0x280 Code: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b RSP: 0018:ffff88810413f370 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000 RDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20 RBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481 R10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122 R13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028 FS: 00007f7823e8d540(0000) GS:ffff888119e00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __create_synth_event+0x1e37/0x1eb0 create_or_delete_synth_event+0x110/0x250 synth_event_run_command+0x2f/0x110 test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test] synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test] do_one_initcall+0xdb/0x480 do_init_module+0x1cf/0x680 load_module+0x6a50/0x70a0 __do_sys_finit_module+0x12f/0x1c0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://lkml.kernel.org/r/20221117012346.22647-3-shangxiaojing@huawei.com Fixes: 4b147936fa50 ("tracing: Add support for 'synthetic' events") Signed-off-by: Shang XiaoJing Cc: stable@vger.kernel.org Cc: Cc: Cc: Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 0e5baaa181a052d968701bb9c5b1d55847f00942 Author: Shang XiaoJing Date: Thu Nov 17 09:23:45 2022 +0800 tracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event() commit a4527fef9afe5c903c718d0cd24609fe9c754250 upstream. test_gen_synth_cmd() only free buf in fail path, hence buf will leak when there is no failure. Add kfree(buf) to prevent the memleak. The same reason and solution in test_empty_synth_event(). unreferenced object 0xffff8881127de000 (size 2048): comm "modprobe", pid 247, jiffies 4294972316 (age 78.756s) hex dump (first 32 bytes): 20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20 gen_synth_test 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f pid_t next_pid_ backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<0000000039eb1cf5>] 0xffffffffa00083cd [<000000000e8c3bc8>] 0xffffffffa00086ba [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd unreferenced object 0xffff8881127df000 (size 2048): comm "modprobe", pid 247, jiffies 4294972324 (age 78.728s) hex dump (first 32 bytes): 20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73 empty_synth_tes 74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 t pid_t next_pi backtrace: [<000000004254801a>] kmalloc_trace+0x26/0x100 [<00000000d4db9a3d>] 0xffffffffa0008071 [<00000000c31354a5>] 0xffffffffa00086ce [<00000000c293d1ea>] do_one_initcall+0xdb/0x480 [<00000000aa189e6d>] do_init_module+0x1cf/0x680 [<00000000d513222b>] load_module+0x6a50/0x70a0 [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0 [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90 [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Link: https://lkml.kernel.org/r/20221117012346.22647-2-shangxiaojing@huawei.com Cc: Cc: Cc: Cc: stable@vger.kernel.org Fixes: 9fe41efaca08 ("tracing: Add synth event generation test module") Signed-off-by: Shang XiaoJing Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit d2d1499f68449cbe8a9d093bb3a14efade0e8d03 Author: Steven Rostedt (Google) Date: Thu Oct 20 23:14:27 2022 -0400 tracing/ring-buffer: Have polling block on watermark commit 42fb0a1e84ff525ebe560e2baf9451ab69127e2b upstream. Currently the way polling works on the ring buffer is broken. It will return immediately if there's any data in the ring buffer whereas a read will block until the watermark (defined by the tracefs buffer_percent file) is hit. That is, a select() or poll() will return as if there's data available, but then the following read will block. This is broken for the way select()s and poll()s are supposed to work. Have the polling on the ring buffer also block the same way reads and splice does on the ring buffer. Link: https://lkml.kernel.org/r/20221020231427.41be3f26@gandalf.local.home Cc: Linux Trace Kernel Cc: Masami Hiramatsu Cc: Mathieu Desnoyers Cc: Primiano Tucci Cc: stable@vger.kernel.org Fixes: 1e0d6714aceb7 ("ring-buffer: Do not wake up a splice waiter when page is not full") Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit a7d3f8f33c113478737bc61bb32ec5f9a987da7d Author: Wang Yufen Date: Mon Nov 7 19:04:50 2022 +0800 tracing: Fix memory leak in tracing_read_pipe() commit 649e72070cbbb8600eb823833e4748f5a0815116 upstream. kmemleak reports this issue: unreferenced object 0xffff888105a18900 (size 128): comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150 [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0 [<0000000065629d9d>] trace_event_printf+0xb6/0xf0 [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0 [<00000000d22db172>] print_trace_line+0x73c/0x1480 [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0 [<0000000015b58459>] vfs_read+0x17b/0x7c0 [<000000004aeee8ed>] ksys_read+0xed/0x1c0 [<0000000063d3d898>] do_syscall_64+0x3b/0x90 [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd iter->fmt alloced in tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not freed, to fix, add free in tracing_release_pipe() Link: https://lkml.kernel.org/r/1667819090-4643-1-git-send-email-wangyufen@huawei.com Cc: stable@vger.kernel.org Fixes: efbbdaa22bb7 ("tracing: Show real address for trace event arguments") Acked-by: Masami Hiramatsu (Google) Signed-off-by: Wang Yufen Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit a3f83ccc548cdd057888512d7fab8b555bca9a40 Author: Daniil Tatianin Date: Mon Nov 14 17:31:29 2022 +0300 ring_buffer: Do not deactivate non-existant pages commit 56f4ca0a79a9f1af98f26c54b9b89ba1f9bcc6bd upstream. rb_head_page_deactivate() expects cpu_buffer to contain a valid list of ->pages, so verify that the list is actually present before calling it. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Link: https://lkml.kernel.org/r/20221114143129.3534443-1-d-tatianin@yandex-team.ru Cc: stable@vger.kernel.org Fixes: 77ae365eca895 ("ring-buffer: make lockless") Signed-off-by: Daniil Tatianin Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit 6e50eb4b1807017f6c2d5089064256ce2de8aef1 Author: Xiu Jianfeng Date: Wed Nov 16 09:52:07 2022 +0800 ftrace: Fix null pointer dereference in ftrace_add_mod() commit 19ba6c8af9382c4c05dc6a0a79af3013b9a35cd0 upstream. The @ftrace_mod is allocated by kzalloc(), so both the members {prev,next} of @ftrace_mode->list are NULL, it's not a valid state to call list_del(). If kstrdup() for @ftrace_mod->{func|module} fails, it goes to @out_free tag and calls free_ftrace_mod() to destroy @ftrace_mod, then list_del() will write prev->next and next->prev, where null pointer dereference happens. BUG: kernel NULL pointer dereference, address: 0000000000000008 Oops: 0002 [#1] PREEMPT SMP NOPTI Call Trace: ftrace_mod_callback+0x20d/0x220 ? do_filp_open+0xd9/0x140 ftrace_process_regex.isra.51+0xbf/0x130 ftrace_regex_write.isra.52.part.53+0x6e/0x90 vfs_write+0xee/0x3a0 ? __audit_filter_op+0xb1/0x100 ? auditd_test_task+0x38/0x50 ksys_write+0xa5/0xe0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Kernel panic - not syncing: Fatal exception So call INIT_LIST_HEAD() to initialize the list member to fix this issue. Link: https://lkml.kernel.org/r/20221116015207.30858-1-xiujianfeng@huawei.com Cc: stable@vger.kernel.org Fixes: 673feb9d76ab ("ftrace: Add :mod: caching infrastructure to trace_array") Signed-off-by: Xiu Jianfeng Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit ca7b545fe31182127d1b10522541575c59d15095 Author: Wang Wensheng Date: Wed Nov 9 09:44:33 2022 +0000 ftrace: Optimize the allocation for mcount entries commit bcea02b096333dc74af987cb9685a4dbdd820840 upstream. If we can't allocate this size, try something smaller with half of the size. Its order should be decreased by one instead of divided by two. Link: https://lkml.kernel.org/r/20221109094434.84046-3-wangwensheng4@huawei.com Cc: Cc: Cc: stable@vger.kernel.org Fixes: a79008755497d ("ftrace: Allocate the mcount record pages as groups") Signed-off-by: Wang Wensheng Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit dbaba88c19374227da0a5abc619ae430295cc43c Author: Wang Wensheng Date: Wed Nov 9 09:44:32 2022 +0000 ftrace: Fix the possible incorrect kernel message commit 08948caebe93482db1adfd2154eba124f66d161d upstream. If the number of mcount entries is an integer multiple of ENTRIES_PER_PAGE, the page count showing on the console would be wrong. Link: https://lkml.kernel.org/r/20221109094434.84046-2-wangwensheng4@huawei.com Cc: Cc: Cc: stable@vger.kernel.org Fixes: 5821e1b74f0d0 ("function tracing: fix wrong pos computing when read buffer has been fulfilled") Signed-off-by: Wang Wensheng Signed-off-by: Steven Rostedt (Google) Signed-off-by: Greg Kroah-Hartman commit a72216f25fbbb61bcdec88a861c01ab4ffac2a4b Author: Keith Busch Date: Thu Nov 10 10:44:58 2022 -0800 dm-crypt: provide dma_alignment limit in io_hints [ Upstream commit 86e4d3e8d1838ca88fb9267e669c36f6c8f7c6cd ] This device mapper needs bio vectors to be sized and memory aligned to the logical block size. Set the minimum required queue limit accordingly. Link: https://lore.kernel.org/linux-block/20221101001558.648ee024@xps.demsh.org/ Fixes: b1a000d3b8ec5 ("block: relax direct io memory alignment") Reportred-by: Eric Biggers Reported-by: Dmitrii Tcvetkov Signed-off-by: Keith Busch Reviewed-by: Mike Snitzer Link: https://lore.kernel.org/r/20221110184501.2451620-3-kbusch@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7bcb1a45b85cdec9666deb032696a128c2d55190 Author: Keith Busch Date: Thu Nov 10 10:44:57 2022 -0800 block: make dma_alignment a stacking queue_limit [ Upstream commit c964d62f5cab7b43dd0534f22a96eab386c6ec5d ] Device mappers had always been getting the default 511 dma mask, but the underlying device might have a larger alignment requirement. Since this value is used to determine alloweable direct-io alignment, this needs to be a stackable limit. Signed-off-by: Keith Busch Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20221110184501.2451620-2-kbusch@meta.com Signed-off-by: Jens Axboe Stable-dep-of: 86e4d3e8d183 ("dm-crypt: provide dma_alignment limit in io_hints") Signed-off-by: Sasha Levin commit 207edad5717e0a5709ce8467f0eff41c607835c9 Author: Wang Yufen Date: Tue Nov 15 17:30:25 2022 +0800 netdevsim: Fix memory leak of nsim_dev->fa_cookie [ Upstream commit 064bc7312bd09a48798418663090be0c776183db ] kmemleak reports this issue: unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The issue occurs in the following scenarios: nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie .. nsim_drv_remove() The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. To fix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove(). Fixes: d3cbb907ae57 ("netdevsim: add ACL trap reporting cookie as a metadata") Signed-off-by: Wang Yufen Cc: Jiri Pirko Link: https://lore.kernel.org/r/1668504625-14698-1-git-send-email-wangyufen@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5cf69a3772074c60721ae36a8761e8314897644a Author: Anastasia Belova Date: Wed Nov 16 17:10:27 2022 +0300 cifs: add check for returning value of SMB2_set_info_init [ Upstream commit a51e5d293dd1c2e7bf6f7be788466cd9b5d280fb ] If the returning value of SMB2_set_info_init is an error-value, exit the function. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 0967e5457954 ("cifs: use a compound for setting an xattr") Signed-off-by: Anastasia Belova Signed-off-by: Steve French Signed-off-by: Sasha Levin commit a478952a8ac44e32316dc046a063a7dc34825aa6 Author: Vasily Gorbik Date: Fri Nov 4 12:06:47 2022 +0100 s390: avoid using global register for current_stack_pointer [ Upstream commit e3c11025bcd2142a61abe5806b2f86a0e78118df ] Commit 30de14b1884b ("s390: current_stack_pointer shouldn't be a function") made current_stack_pointer a global register variable like on many other architectures. Unfortunately on s390 it uncovers old gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87 ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior to 8.4 generate broken code which leads to stack corruptions. Current minimal gcc version required to build the kernel is declared as 5.1. It is not possible to fix all old gcc versions, so work around this problem by avoiding using global register variable for current_stack_pointer. Fixes: 30de14b1884b ("s390: current_stack_pointer shouldn't be a function") Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Alexander Gordeev Signed-off-by: Sasha Levin commit d3075aed03a9dddf07121841181eb65fa5f28caa Author: Yuan Can Date: Mon Nov 14 14:22:25 2022 +0000 net: thunderbolt: Fix error handling in tbnet_init() [ Upstream commit f524b7289bbb0c8ffaa2ba3c34c146e43da54fb2 ] A problem about insmod thunderbolt-net failed is triggered with following log given while lsmod does not show thunderbolt_net: insmod: ERROR: could not insert module thunderbolt-net.ko: File exists The reason is that tbnet_init() returns tb_register_service_driver() directly without checking its return value, if tb_register_service_driver() failed, it returns without removing property directory, resulting the property directory can never be created later. tbnet_init() tb_register_property_dir() # register property directory tb_register_service_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without remove property directory Fix by remove property directory when tb_register_service_driver() returns error. Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable") Signed-off-by: Yuan Can Acked-by: Mika Westerberg Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 456327e565dc49d18b2f595f39f47df8a36f1057 Author: Shang XiaoJing Date: Mon Nov 14 21:38:53 2022 +0800 net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start() [ Upstream commit 639f5d006e36bb303f525d9479448c412b720c39 ] sparx_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. So as sparx5_start(). Fixes: af4b11022e2d ("net: sparx5: add ethtool configuration and statistics support") Fixes: b37a1bae742f ("net: sparx5: add mactable support") Signed-off-by: Shang XiaoJing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4a43c1c6040e848e1344c7b16ac696b68fbc439c Author: Shang XiaoJing Date: Mon Nov 14 21:38:52 2022 +0800 net: lan966x: Fix potential null-ptr-deref in lan966x_stats_init() [ Upstream commit ba86af3733aece88dbcee0dfebf7e2dcfefb2be4 ] lan966x_stats_init() calls create_singlethread_workqueue() and not checked the ret value, which may return NULL. And a null-ptr-deref may happen: lan966x_stats_init() create_singlethread_workqueue() # failed, lan966x->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-deref Check the ret value and return -ENOMEM if it is NULL. Fixes: 12c2d0a5b8e2 ("net: lan966x: add ethtool configuration and statistics") Signed-off-by: Shang XiaoJing Reviewed-by: Horatiu Vultur Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b6221dfddda4b3bb5d283d443802cf5351b0703 Author: Zhang Xiaoxu Date: Tue Nov 15 18:39:34 2022 +0800 cifs: Fix wrong return value checking when GETFLAGS [ Upstream commit 92bbd67a55fee50743b42825d1c016e7fd5c79f9 ] The return value of CIFSGetExtAttr is negative, should be checked with -EOPNOTSUPP rather than EOPNOTSUPP. Fixes: 64a5cfa6db94 ("Allow setting per-file compression via SMB2/3") Signed-off-by: Zhang Xiaoxu Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 65710ea51d4a185592c7b14c9e33d0c4a364f074 Author: Sagi Grimberg Date: Mon Nov 14 08:45:02 2022 +0200 nvmet: fix a memory leak in nvmet_auth_set_key [ Upstream commit 0a52566279b4ee65ecd2503d7b7342851f84755c ] When changing dhchap secrets we need to release the old secrets as well. kmemleak complaint: -- unreferenced object 0xffff8c7f44ed8180 (size 64): comm "check", pid 7304, jiffies 4295686133 (age 72034.246s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 4c 64 4c 4f 64 71 DHHC-1:00:LdLOdq 79 56 69 67 77 48 55 32 6d 5a 59 4c 7a 35 59 38 yVigwHU2mZYLz5Y8 backtrace: [<00000000b6fc5071>] kstrdup+0x2e/0x60 [<00000000f0f4633f>] 0xffffffffc0e07ee6 [<0000000053006c05>] 0xffffffffc0dff783 [<00000000419ae922>] configfs_write_iter+0xb1/0x120 [<000000008183c424>] vfs_write+0x2be/0x3c0 [<000000009005a2a5>] ksys_write+0x5f/0xe0 [<00000000cd495c89>] do_syscall_64+0x38/0x90 [<00000000f2a84ac5>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 5809fb03942dbac25144db5bebea84fa003ecaca Author: Vladimir Oltean Date: Mon Nov 14 16:35:51 2022 +0200 net: dsa: don't leak tagger-owned storage on switch driver unbind [ Upstream commit 4e0c19fcb8b5323716140fa82b79aa9f60e60407 ] In the initial commit dc452a471dba ("net: dsa: introduce tagger-owned storage for private and shared data"), we had a call to tag_ops->disconnect(dst) issued from dsa_tree_free(), which is called at tree teardown time. There were problems with connecting to a switch tree as a whole, so this got reworked to connecting to individual switches within the tree. In this process, tag_ops->disconnect(ds) was made to be called only from switch.c (cross-chip notifiers emitted as a result of dynamic tag proto changes), but the normal driver teardown code path wasn't replaced with anything. Solve this problem by adding a function that does the opposite of dsa_switch_setup_tag_protocol(), which is called from the equivalent spot in dsa_switch_teardown(). The positioning here also ensures that we won't have any use-after-free in tagging protocol (*rcv) ops, since the teardown sequence is as follows: dsa_tree_teardown -> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler -> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many() -> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage Fixes: 7f2973149c22 ("net: dsa: make tagging protocols connect to individual switches from a tree") Signed-off-by: Vladimir Oltean Reviewed-by: Saeed Mahameed Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20221114143551.1906361-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2d675be16a461310d738d93f9f1a00da62055c5a Author: Wei Yongjun Date: Mon Nov 14 11:05:19 2022 +0000 net/x25: Fix skb leak in x25_lapb_receive_frame() [ Upstream commit 2929cceb2fcf0ded7182562e4888afafece82cce ] x25_lapb_receive_frame() using skb_copy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak. Fixes: cb101ed2c3c7 ("x25: Handle undersized/fragmented skbs") Signed-off-by: Wei Yongjun Acked-by: Martin Schiller Link: https://lore.kernel.org/r/20221114110519.514538-1-weiyongjun@huaweicloud.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 06b6c4bc72b26d32eb8cf7c2dab192b4ee5ef09f Author: Liu Jian Date: Mon Nov 14 17:55:49 2022 +0800 net: ag71xx: call phylink_disconnect_phy if ag71xx_hw_enable() fail in ag71xx_open() [ Upstream commit c9b895c6878bdb6789dc1d7af60fd10f4a9f1937 ] If ag71xx_hw_enable() fails, call phylink_disconnect_phy() to clean up. And if phylink_of_phy_connect() fails, nothing needs to be done. Compile tested only. Fixes: 892e09153fa3 ("net: ag71xx: port to phylink") Signed-off-by: Liu Jian Reviewed-by: Russell King (Oracle) Link: https://lore.kernel.org/r/20221114095549.40342-1-liujian56@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d615d70ba09408c71d99525ede5d7a410955980b Author: Anastasia Belova Date: Tue Nov 15 17:27:01 2022 +0300 cifs: add check for returning value of SMB2_close_init [ Upstream commit d520de6cb42e88a1d008b54f935caf9fc05951da ] If the returning value of SMB2_close_init is an error-value, exit the function. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 352d96f3acc6 ("cifs: multichannel: move channel selection above transport layer") Signed-off-by: Anastasia Belova Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 58b0f4d1c408f4e3e201f85eec15e9f4442ad39f Author: David Howells Date: Fri Nov 4 15:36:49 2022 +0000 netfs: Fix dodgy maths [ Upstream commit 5e51c627c5acbcf82bb552e17533a79d2a6a2600 ] Fix the dodgy maths in netfs_rreq_unlock_folios(). start_page could be inside the folio, in which case the calculation of pgpos will be come up with a negative number (though for the moment rreq->start is rounded down earlier and folios would have to get merged whilst locked) Alter how this works to just frame the tracking in terms of absolute file positions, rather than offsets from the start of the I/O request. This simplifies the maths and makes it easier to follow. Fix the issue by using folio_pos() and folio_size() to calculate the end position of the page. Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Reported-by: Matthew Wilcox Signed-off-by: David Howells Reviewed-by: Jeff Layton Reviewed-by: Jingbo Xu cc: linux-cachefs@redhat.com cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/Y2SJw7w1IsIik3nb@casper.infradead.org/ Link: https://lore.kernel.org/r/166757988611.950645.7626959069846893164.stgit@warthog.procyon.org.uk/ # v2 Signed-off-by: Sasha Levin commit b2cc07a76f1eb12de3b22caf5fdbf856a7bef16d Author: David Howells Date: Thu Nov 3 16:08:14 2022 +0000 netfs: Fix missing xas_retry() calls in xarray iteration [ Upstream commit 7e043a80b5dae5c2d2cf84031501de7827fd6c00 ] netfslib has a number of places in which it performs iteration of an xarray whilst being under the RCU read lock. It *should* call xas_retry() as the first thing inside of the loop and do "continue" if it returns true in case the xarray walker passed out a special value indicating that the walk needs to be redone from the root[*]. Fix this by adding the missing retry checks. [*] I wonder if this should be done inside xas_find(), xas_next_node() and suchlike, but I'm told that's not an simple change to effect. This can cause an oops like that below. Note the faulting address - this is an internal value (|0x2) returned from xarray. BUG: kernel NULL pointer dereference, address: 0000000000000402 ... RIP: 0010:netfs_rreq_unlock+0xef/0x380 [netfs] ... Call Trace: netfs_rreq_assess+0xa6/0x240 [netfs] netfs_readpage+0x173/0x3b0 [netfs] ? init_wait_var_entry+0x50/0x50 filemap_read_page+0x33/0xf0 filemap_get_pages+0x2f2/0x3f0 filemap_read+0xaa/0x320 ? do_filp_open+0xb2/0x150 ? rmqueue+0x3be/0xe10 ceph_read_iter+0x1fe/0x680 [ceph] ? new_sync_read+0x115/0x1a0 new_sync_read+0x115/0x1a0 vfs_read+0xf3/0x180 ksys_read+0x5f/0xe0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Changes: ======== ver #2) - Changed an unsigned int to a size_t to reduce the likelihood of an overflow as per Willy's suggestion. - Added an additional patch to fix the maths. Fixes: 3d3c95046742 ("netfs: Provide readahead and readpage netfs helpers") Reported-by: George Law Signed-off-by: David Howells Reviewed-by: Jeff Layton Reviewed-by: Jingbo Xu cc: Matthew Wilcox cc: linux-cachefs@redhat.com cc: linux-fsdevel@vger.kernel.org Link: https://lore.kernel.org/r/166749229733.107206.17482609105741691452.stgit@warthog.procyon.org.uk/ # v1 Link: https://lore.kernel.org/r/166757987929.950645.12595273010425381286.stgit@warthog.procyon.org.uk/ # v2 Signed-off-by: Sasha Levin commit 2fac1a7218ef74def406d39d6d572a0a320240ee Author: Maximilian Luz Date: Sun Nov 13 19:59:50 2022 +0100 platform/surface: aggregator: Do not check for repeated unsequenced packets [ Upstream commit d9a477f643eb3de71fbea5ae6103b800ceb8f547 ] Currently, we check any received packet whether we have already seen it previously, regardless of the packet type (sequenced / unsequenced). We do this by checking the sequence number. This assumes that sequence numbers are valid for both sequenced and unsequenced packets. However, this assumption appears to be incorrect. On some devices, the sequence number field of unsequenced packets (in particular HID input events on the Surface Pro 9) is always zero. As a result, the current retransmission check kicks in and discards all but the first unsequenced packet, breaking (among other things) keyboard and touchpad input. Note that we have, so far, only seen packets being retransmitted in sequenced communication. In particular, this happens when there is an ACK timeout, causing the EC (or us) to re-send the packet waiting for an ACK. Arguably, retransmission / duplication of unsequenced packets should not be an issue as there is no logical condition (such as an ACK timeout) to determine when a packet should be sent again. Therefore, remove the retransmission check for unsequenced packets entirely to resolve the issue. Fixes: c167b9c7e3d6 ("platform/surface: Add Surface Aggregator subsystem") Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20221113185951.224759-1-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit e62b14037d9adf7fc8c0813d1891b90964e7831f Author: Roger Pau Monné Date: Thu Nov 10 17:31:44 2022 +0100 platform/x86/intel: pmc: Don't unconditionally attach Intel PMC when virtualized [ Upstream commit 2dbfb3f33350e1e868d3d7ed4c176d8777150878 ] The current logic in the Intel PMC driver will forcefully attach it when detecting any CPU on the intel_pmc_core_platform_ids array, even if the matching ACPI device is not present. There's no checking in pmc_core_probe() to assert that the PMC device is present, and hence on virtualized environments the PMC device probes successfully, even if the underlying registers are not present. Before commit 21ae43570940 ("platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration") the driver would check for the presence of a specific PCI device, and that prevented the driver from attaching when running virtualized. Fix by only forcefully attaching the PMC device when not running virtualized. Note that virtualized platforms can still get the device to load if the appropriate ACPI device is present on the tables provided to the VM. Make an exception for the Xen initial domain, which does have full hardware access, and hence can attach to the PMC if present. Fixes: 21ae43570940 ("platform/x86: intel_pmc_core: Substitute PCI with CPUID enumeration") Signed-off-by: Roger Pau Monné Acked-by: David E. Box Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20221110163145.80374-1-roger.pau@citrix.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit c2a00b149836d60c222930bbea6b2139caf34d4f Author: Dan Carpenter Date: Tue Nov 15 16:16:43 2022 +0300 drbd: use after free in drbd_create_device() [ Upstream commit a7a1598189228b5007369a9622ccdf587be0730f ] The drbd_destroy_connection() frees the "connection" so use the _safe() iterator to prevent a use after free. Fixes: b6f85ef9538b ("drbd: Iterate over all connections") Signed-off-by: Dan Carpenter Reviewed-by: Christoph Böhmwalder Link: https://lore.kernel.org/r/Y3Jd5iZRbNQ9w6gm@kili Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f8926e2d2225eb7b7e11cd3fa266aaad9075b767 Author: Ido Schimmel Date: Mon Nov 14 10:45:09 2022 +0200 bridge: switchdev: Fix memory leaks when changing VLAN protocol [ Upstream commit 9d45921ee4cb364910097e7d1b7558559c2f9fd2 ] The bridge driver can offload VLANs to the underlying hardware either via switchdev or the 8021q driver. When the former is used, the VLAN is marked in the bridge driver with the 'BR_VLFLAG_ADDED_BY_SWITCHDEV' private flag. To avoid the memory leaks mentioned in the cited commit, the bridge driver will try to delete a VLAN via the 8021q driver if the VLAN is not marked with the previously mentioned flag. When the VLAN protocol of the bridge changes, switchdev drivers are notified via the 'SWITCHDEV_ATTR_ID_BRIDGE_VLAN_PROTOCOL' attribute, but the 8021q driver is also called to add the existing VLANs with the new protocol and delete them with the old protocol. In case the VLANs were offloaded via switchdev, the above behavior is both redundant and buggy. Redundant because the VLANs are already programmed in hardware and drivers that support VLAN protocol change (currently only mlx5) change the protocol upon the switchdev attribute notification. Buggy because the 8021q driver is called despite these VLANs being marked with 'BR_VLFLAG_ADDED_BY_SWITCHDEV'. This leads to memory leaks [1] when the VLANs are deleted. Fix by not calling the 8021q driver for VLANs that were already programmed via switchdev. [1] unreferenced object 0xffff8881f6771200 (size 256): comm "ip", pid 446855, jiffies 4298238841 (age 55.240s) hex dump (first 32 bytes): 00 00 7f 0e 83 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000012819ac>] vlan_vid_add+0x437/0x750 [<00000000f2281fad>] __br_vlan_set_proto+0x289/0x920 [<000000000632b56f>] br_changelink+0x3d6/0x13f0 [<0000000089d25f04>] __rtnl_newlink+0x8ae/0x14c0 [<00000000f6276baf>] rtnl_newlink+0x5f/0x90 [<00000000746dc902>] rtnetlink_rcv_msg+0x336/0xa00 [<000000001c2241c0>] netlink_rcv_skb+0x11d/0x340 [<0000000010588814>] netlink_unicast+0x438/0x710 [<00000000e1a4cd5c>] netlink_sendmsg+0x788/0xc40 [<00000000e8992d4e>] sock_sendmsg+0xb0/0xe0 [<00000000621b8f91>] ____sys_sendmsg+0x4ff/0x6d0 [<000000000ea26996>] ___sys_sendmsg+0x12e/0x1b0 [<00000000684f7e25>] __sys_sendmsg+0xab/0x130 [<000000004538b104>] do_syscall_64+0x3d/0x90 [<0000000091ed9678>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fixes: 279737939a81 ("net: bridge: Fix VLANs memory leak") Reported-by: Vlad Buslov Tested-by: Vlad Buslov Signed-off-by: Ido Schimmel Acked-by: Nikolay Aleksandrov Link: https://lore.kernel.org/r/20221114084509.860831-1-idosch@nvidia.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 5ea156de92788e9634897feb6fe55d65a24b7d8c Author: Guangbin Huang Date: Mon Nov 14 16:20:48 2022 +0800 net: hns3: fix setting incorrect phy link ksettings for firmware in resetting process [ Upstream commit 510d7b6ae842e59ee00d57e5f07ac15131b6d899 ] Currently, if driver is in phy-imp(phy controlled by imp firmware) mode, as driver did not update phy link ksettings after initialization process or not update advertising when getting phy link ksettings from firmware, it may set incorrect phy link ksettings for firmware in resetting process. So fix it. Fixes: f5f2b3e4dcc0 ("net: hns3: add support for imp-controlled PHYs") Fixes: c5ef83cbb1e9 ("net: hns3: fix for phy_addr error in hclge_mac_mdio_config") Fixes: 2312e050f42b ("net: hns3: Fix for deadlock problem occurring when unregistering ae_algo") Signed-off-by: Guangbin Huang Signed-off-by: Hao Lan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 1fef5143b7ed5826846ac3b76d1e8e9ed1d44fc7 Author: Jie Wang Date: Mon Nov 14 16:20:47 2022 +0800 net: hns3: fix return value check bug of rx copybreak [ Upstream commit 29df7c695ed67a8fa32bb7805bad8fe2a76c1f88 ] The refactoring of rx copybreak modifies the original return logic, which will make this feature unavailable. So this patch fixes the return logic of rx copybreak. Fixes: e74a726da2c4 ("net: hns3: refactor hns3_nic_reuse_page()") Fixes: 99f6b5fb5f63 ("net: hns3: use bounce buffer when rx page can not be reused") Signed-off-by: Jie Wang Signed-off-by: Hao Lan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit e32440f4fb789fd9dafe67f4a5e08f90df49f015 Author: Jian Shen Date: Mon Nov 14 16:20:46 2022 +0800 net: hns3: fix incorrect hw rss hash type of rx packet [ Upstream commit a56cad694767ebdb7d80f27ffc239db46fff64de ] Currently, the HNS3 driver reports the rss hash type of each packet based on the rss hash tuples set. It always reports PKT_HASH_TYPE_L4, without checking the type of current packet. It's incorrect. Fixes it by reporting it base on the packet type. Fixes: 796640778c26 ("net: hns3: support RXD advanced layout") Fixes: 232fc64b6e62 ("net: hns3: Add HW RSS hash information to RX skb") Fixes: ea4858670717 ("net: hns3: handle the BD info on the last BD of the packet") Signed-off-by: Jian Shen Signed-off-by: Hao Lan Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit 0e2369223b174d198ec42a3ec0a7f06c8727b968 Author: Yuan Can Date: Mon Nov 14 02:56:59 2022 +0000 net: ena: Fix error handling in ena_init() [ Upstream commit d349e9be5a2c2d7588a2c4e4bfa0bb3dc1226769 ] The ena_init() won't destroy workqueue created by create_singlethread_workqueue() when pci_register_driver() failed. Call destroy_workqueue() when pci_register_driver() failed to prevent the resource leak. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Yuan Can Acked-by: Shay Agroskin Link: https://lore.kernel.org/r/20221114025659.124726-1-yuancan@huawei.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit bf92e54597d842da127c59833b365d6faeeaf020 Author: Cong Wang Date: Sun Nov 13 16:51:19 2022 -0800 kcm: close race conditions on sk_receive_queue [ Upstream commit 5121197ecc5db58c07da95eb1ff82b98b121a221 ] sk->sk_receive_queue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rx_lock to protect more than just skb queue. However, kcm_recvmsg() still only grabs the skb queue lock, so race conditions still exist. We can teach kcm_recvmsg() to grab mux->rx_lock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets. So we have to enforce skb queue lock in requeue_rx_msgs() and handle skb peek case carefully in kcm_wait_data(). Fortunately, skb_recv_datagram() already handles it nicely and is widely used by other sockets, we can just switch to skb_recv_datagram() after getting rid of the unnecessary sock lock in kcm_recvmsg() and kcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets, so it is safe to get rid of this check too. I ran the original syzbot reproducer for 30 min without seeing any issue. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Reported-by: syzbot+278279efdd2730dd14bf@syzkaller.appspotmail.com Reported-by: shaozhengchao Cc: Paolo Abeni Cc: Tom Herbert Signed-off-by: Cong Wang Link: https://lore.kernel.org/r/20221114005119.597905-1-xiyou.wangcong@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit c06932e89698e213f568ea9101f03a4f7d998924 Author: Yuan Can Date: Sun Nov 13 09:29:29 2022 +0000 net: ionic: Fix error handling in ionic_init_module() [ Upstream commit 280c0f7cd0aa4d190619b18243110e052a90775c ] A problem about ionic create debugfs failed is triggered with the following log given: [ 415.799514] debugfs: Directory 'ionic' with parent '/' already present! The reason is that ionic_init_module() returns ionic_bus_register_driver() directly without checking its return value, if ionic_bus_register_driver() failed, it returns without destroy the newly created debugfs, resulting the debugfs of ionic can never be created later. ionic_init_module() ionic_debugfs_create() # create debugfs directory ionic_bus_register_driver() pci_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without destroy debugfs directory Fix by removing debugfs when ionic_bus_register_driver() returns error. Fixes: fbfb8031533c ("ionic: Add hardware init and device commands") Signed-off-by: Yuan Can Acked-by: Shannon Nelson Link: https://lore.kernel.org/r/20221113092929.19161-1-yuancan@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8991d5b05ed61d6a72c5e208b06faaf673636627 Author: Amit Cohen Date: Fri Nov 11 18:03:27 2022 +0100 mlxsw: Avoid warnings when not offloaded FDB entry with IPv6 is removed [ Upstream commit 30f5312d2c722107364f266cfa98ef4f0857c1fb ] FDB entries that perform VXLAN encapsulation with an IPv6 underlay hold a reference on a resource - the KVDL entry where the IPv6 underlay destination IP is stored. For that, the driver maintains two hash tables: 1. Maps IPv6 to KVDL index 2. Maps {MAC, FID index} to IPv6 address When a FDB entry is removed, the second table is used to find the relevant IPv6 address and the first table is used to remove the reference count and free the index if is not used anymore. In order for a packet to be forwarded to a single remote VTEP, FDB entries need to be configured at both the bridge and VXLAN devices' FDB tables. Both entries are squashed into one {MAC, VLAN/VNI} -> IP entry in the hardware. Therefore, in case one entry is removed, the entry will be removed from the hardware and the remaining entry will be unmarked with 'offload' flag since it is not offloaded anymore. For example, the two FDB entries should be added to allow packets to be forwarded via vx10: $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff self static dst 2001:db8:5::1 $ bridge fdb add dev vx10 aa:bb:cc:dd:ee:ff master static vlan 10 When one entry will be removed, the second one will not be offloaded anymore. When the first entry (in VXLAN FDB) will be removed / will not be offloaded anymore, the two mappings in IPv6 hash tables will be removed. In case that the second entry is removed before the first one, unexpected warnings[1][2] will be shown in user space as a result of removing the first entry. The issue is that not offloaded entry is removed, the driver tries to search the relevant entries in the hash tables, does not find them and therefore warns. Do not handle removing of not offloaded VXLAN FDB entries, as they were already removed when the offload flag was removed. [1]: WARNING: CPU: 1 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum_nve.c:914 mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum] ... Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015 Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum] RIP: 0010:mlxsw_sp_nve_ipv6_addr_map_del+0x6b/0x80 [mlxsw_spectrum] ... Call Trace: mlxsw_sp_port_fdb_tunnel_uc_op+0x6cf/0x7b0 [mlxsw_spectrum] mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum] ? finish_task_switch.isra.0+0x8c/0x290 process_one_work+0x1cd/0x390 worker_thread+0x48/0x3c0 ? process_one_work+0x390/0x390 kthread+0xe0/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 [2]: WARNING: CPU: 0 PID: 239 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3035 mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum] ... Hardware name: Mellanox Technologies Ltd. Mellanox switch/Mellanox switch, BIOS 4.6.5 05/21/2015 Workqueue: mlxsw_core_ordered mlxsw_sp_switchdev_vxlan_fdb_event_work [mlxsw_spectrum] RIP: 0010:mlxsw_sp_ipv6_addr_put+0x142/0x220 [mlxsw_spectrum] ... Call Trace: ? mlxsw_sp_port_fdb_tun_uc_op6_sfd_write+0x5c1/0x610 [mlxsw_spectrum] mlxsw_sp_port_fdb_tunnel_uc_op+0x6ec/0x7b0 [mlxsw_spectrum] mlxsw_sp_switchdev_vxlan_fdb_event_work+0x17c/0x420 [mlxsw_spectrum] ? finish_task_switch.isra.0+0x8c/0x290 process_one_work+0x1cd/0x390 worker_thread+0x48/0x3c0 ? process_one_work+0x390/0x390 kthread+0xe0/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Fixes: 0860c7641634 ("mlxsw: spectrum_nve: Keep track of IPv6 addresses used by FDB entries") Signed-off-by: Amit Cohen Reviewed-by: Ido Schimmel Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/c186de8cbd28e3eb661e06f31f7f2f2dff30020f.1668184350.git.petrm@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbc98fe99e17ed18f2f272d5fe880d844b1c68c3 Author: Jingbo Xu Date: Mon Nov 14 20:19:43 2022 +0800 erofs: fix missing xas_retry() in fscache mode [ Upstream commit 37020bbb71d911431e16c2c940b97cf86ae4f2f6 ] The xarray iteration only holds the RCU read lock and thus may encounter XA_RETRY_ENTRY if there's process modifying the xarray concurrently. This will cause oops when referring to the invalid entry. Fix this by adding the missing xas_retry(), which will make the iteration wind back to the root node if XA_RETRY_ENTRY is encountered. Fixes: d435d53228dd ("erofs: change to use asynchronous io for fscache readpage/readahead") Suggested-by: David Howells Reviewed-by: Gao Xiang Reviewed-by: Jia Zhu Signed-off-by: Jingbo Xu Link: https://lore.kernel.org/r/20221114121943.29987-1-jefflexu@linux.alibaba.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit e948f3c129d78537ded70bcc99c31f0b45f05dd7 Author: Yang Yingliang Date: Thu Nov 10 23:24:41 2022 +0800 xen/pcpu: fix possible memory leak in register_pcpu() [ Upstream commit da36a2a76b01b210ffaa55cdc2c99bc8783697c5 ] In device_add(), dev_set_name() is called to allocate name, if it returns error, the name need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(). Fixes: f65c9bb3fb72 ("xen/pcpu: Xen physical cpus online/offline sys interface") Signed-off-by: Yang Yingliang Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20221110152441.401630-1-yangyingliang@huawei.com Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 4ea58aede0e339b1b8fde74481dfbc016c9d72ae Author: Vladimir Oltean Date: Fri Nov 11 23:10:20 2022 +0200 net: dsa: make dsa_master_ioctl() see through port_hwtstamp_get() shims [ Upstream commit ed1fe1bebe18884b11e5536b5ac42e3a48960835 ] There are multi-generational drivers like mv88e6xxx which have code like this: int mv88e6xxx_port_hwtstamp_get(struct dsa_switch *ds, int port, struct ifreq *ifr) { if (!chip->info->ptp_support) return -EOPNOTSUPP; ... } DSA wants to deny PTP timestamping on the master if the switch supports timestamping too. However it currently relies on the presence of the port_hwtstamp_get() callback to determine PTP capability, and this clearly does not work in that case (method is present but returns -EOPNOTSUPP). We should not deny PTP on the DSA master for those switches which truly do not support hardware timestamping. Create a dsa_port_supports_hwtstamp() method which actually probes for support by calling port_hwtstamp_get() and seeing whether that returned -EOPNOTSUPP or not. Fixes: f685e609a301 ("net: dsa: Deny PTP on master if switch supports it") Link: https://patchwork.kernel.org/project/netdevbpf/patch/20221110124345.3901389-1-festevam@gmail.com/ Reported-by: Fabio Estevam Reported-by: Steffen Bätz Signed-off-by: Vladimir Oltean Tested-by: Fabio Estevam Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 25a270343b0f16e1f6e65f541a15975a35e238ff Author: Wei Yongjun Date: Fri Nov 11 09:20:44 2022 +0000 net: mhi: Fix memory leak in mhi_net_dellink() [ Upstream commit f7c125bd79f50ec6094761090be81d02726ec6f4 ] MHI driver registers network device without setting the needs_free_netdev flag, and does NOT call free_netdev() when unregisters network device, which causes a memory leak. This patch calls free_netdev() to fix it since netdev_priv is used after unregister. Fixes: 13adac032982 ("net: mhi_net: Register wwan_ops for link creation") Signed-off-by: Wei Yongjun Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c08566d012ff85ec24729b4f83a90b3d95f5094b Author: Erico Nunes Date: Thu Oct 27 09:32:00 2022 +0200 drm/lima: Fix opp clkname setting in case of missing regulator [ Upstream commit e17a025a47c66ca8499ae88d8046c4f0d7c9c057 ] Commit d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()") introduced a regression as it may undo the clk_names setting in case the optional regulator is missing. This resulted in test and performance regressions with lima. Restore the old behavior where clk_names is set separately so it is not undone in case of a missing optional regulator. Fixes: d8c32d3971e4 ("drm/lima: Migrate to dev_pm_opp_set_config()") Acked-by: Viresh Kumar Signed-off-by: Erico Nunes Signed-off-by: Qiang Yu Link: https://patchwork.freedesktop.org/patch/msgid/20221027073200.3885839-1-nunes.erico@gmail.com Signed-off-by: Sasha Levin commit 6ee3a0ace5c63a6d83cbbaea5fdc53855e63a5e5 Author: Ziyang Xuan Date: Fri Nov 11 15:09:35 2022 +0800 octeon_ep: ensure get mac address successfully before eth_hw_addr_set() [ Upstream commit 848ffce2f0c93f3481052340a919123a21f808b6 ] octep_get_mac_addr() can fail because send mbox message failed. If this happens, octep_dev->mac_addr will be zero. It should not continue to initialize. Add exception handling for octep_get_mac_addr() to fix it. Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 67b65a0db8a7fdad43159819f41335497a4bb04f Author: Ziyang Xuan Date: Fri Nov 11 15:09:23 2022 +0800 octeon_ep: fix potential memory leak in octep_device_setup() [ Upstream commit e4041be97b15302ebfffda8bbd45f3b2d096048f ] When occur unsupported_dev and mbox init errors, it did not free oct->conf and iounmap() oct->mmio[i].hw_addr. That would trigger memory leak problem. Add kfree() for oct->conf and iounmap() for oct->mmio[i].hw_addr under unsupported_dev and mbox init errors to fix the problem. Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3564f483aab79327971bfd06a744445f0696f2c3 Author: Ziyang Xuan Date: Fri Nov 11 15:08:47 2022 +0800 octeon_ep: ensure octep_get_link_status() successfully before octep_link_up() [ Upstream commit 9d3ff7131877fb092185c369fbb14b57ac4e7cec ] octep_get_link_status() can fail because send mbox message failed, then octep_get_link_status() will return ret less than 0. Excute octep_link_up() as long as ret is not equal to 0 in octep_open() now. That is not correct. The value type of link.state is enum octep_ctrl_net_state. Positive value represents up. Excute octep_link_up() when ret is bigger than 0. Fixes: 862cd659a6fb ("octeon_ep: Add driver framework and device initialization") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4e740e8baa241c3d7d1dfdb8294d3994d34cd407 Author: Ziyang Xuan Date: Fri Nov 11 15:08:27 2022 +0800 octeon_ep: delete unnecessary napi rollback under set_queues_err in octep_open() [ Upstream commit 298b83e180d53a310f9b47e3bf13b7b583e75e9c ] octep_napi_add() and octep_napi_enable() are all after netif_set_real_num_{tx,rx}_queues() in octep_open(), so it is unnecessary napi rollback under set_queues_err. Delete them to fix it. Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support") Signed-off-by: Ziyang Xuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8f14bb2334dd1e315da596cabfc225c66b855bbc Author: Gaosheng Cui Date: Fri Nov 11 15:04:33 2022 +0800 bnxt_en: Remove debugfs when pci_register_driver failed [ Upstream commit 991aef4ee4f6eb999924f429b943441a32835c8f ] When pci_register_driver failed, we need to remove debugfs, which will caused a resource leak, fix it. Resource leak logs as follows: [ 52.184456] debugfs: Directory 'bnxt_en' with parent '/' already present! Fixes: cabfb09d87bd ("bnxt_en: add debugfs support for DIM") Signed-off-by: Gaosheng Cui Reviewed-by: Leon Romanovsky Reviewed-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f0c13e605beb0f2f101678ef96cdbb0e397dfcc2 Author: Zhengchao Shao Date: Fri Nov 11 09:47:34 2022 +0800 net: caif: fix double disconnect client in chnl_net_open() [ Upstream commit 8fbb53c8bfd8c56ecf1f78dc821778b58f505503 ] When connecting to client timeout, disconnect client for twice in chnl_net_open(). Remove one. Compile tested only. Fixes: 2aa40aef9deb ("caif: Use link layer MTU instead of fixed MTU") Signed-off-by: Zhengchao Shao Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5826fe5bc68a185f94139035943ebaf04d6a8a3c Author: Chuang Wang Date: Fri Nov 11 09:41:30 2022 +0800 net: macvlan: Use built-in RCU list checking [ Upstream commit 5df1341ea822292275c56744aab9c536d75c33be ] hlist_for_each_entry_rcu() has built-in RCU and lock checking. Pass cond argument to hlist_for_each_entry_rcu() to silence false lockdep warning when CONFIG_PROVE_RCU_LIST is enabled. Execute as follow: ip link add link eth0 type macvlan mode source macaddr add The rtnl_lock is held when macvlan_hash_lookup_source() or macvlan_fill_info_macaddr() are called in the non-RCU read side section. So, pass lockdep_rtnl_is_held() to silence false lockdep warning. Fixes: 79cf79abce71 ("macvlan: add source mode") Signed-off-by: Chuang Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 87b336aa158201dc30a318431e63e8c5b26c4156 Author: Wang ShaoBo Date: Thu Nov 10 19:38:23 2022 +0800 mISDN: fix misuse of put_device() in mISDN_register_device() [ Upstream commit 2d25107e111a85c56f601a5470f1780ec054e6ac ] We should not release reference by put_device() before calling device_initialize(). Fixes: e7d1d4d9ac0d ("mISDN: fix possible memory leak in mISDN_register_device()") Signed-off-by: Wang ShaoBo Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 283c9a4772518361eaccfd23b278d46cdb10290b Author: Zhengchao Shao Date: Thu Nov 10 18:30:37 2022 +0800 net: liquidio: release resources when liquidio driver open failed [ Upstream commit 8979f428a4afc215e390006e5ea19fd4e22c7ca9 ] When liquidio driver open failed, it doesn't release resources. Compile tested only. Fixes: 5b07aee11227 ("liquidio: MSIX support for CN23XX") Fixes: dbc97bfd3918 ("net: liquidio: Add missing null pointer checks") Signed-off-by: Zhengchao Shao Reviewed-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 080608a019597847fe658cb357a48b85f34404f3 Author: Xiaolei Wang Date: Fri Oct 28 12:14:18 2022 +0800 soc: imx8m: Enable OCOTP clock before reading the register [ Upstream commit 836fb30949d9edf91d7de696a884ceeae7e426d2 ] Commit 7d981405d0fd ("soc: imx8m: change to use platform driver") ever removed the dependency on bootloader for enabling OCOTP clock. It helped to fix a kexec kernel hang issue. But unfortunately it caused a regression on CAAM driver and got reverted. This is the second try to enable the OCOTP clock by directly calling clock API instead of indirectly enabling the clock via nvmem API. Fixes: ac34de14ac30 ("Revert "soc: imx8m: change to use platform driver"") Signed-off-by: Xiaolei Wang Reviewed-by: Lucas Stach Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a5915a9a3ab4067ef8996a57738d156eabeb3a12 Author: Jeremy Kerr Date: Thu Nov 10 13:31:35 2022 +0800 mctp i2c: don't count unused / invalid keys for flow release [ Upstream commit 9cbd48d5fa14e4c65f8580de16686077f7cea02b ] We're currently hitting the WARN_ON in mctp_i2c_flow_release: if (midev->release_count > midev->i2c_lock_count) { WARN_ONCE(1, "release count overflow"); This may be hit if we expire a flow before sending the first packet it contains - as we will not be pairing the increment of release_count (performed on flow release) with the i2c lock operation (only performed on actual TX). To fix this, only release a flow if we've encountered it previously (ie, dev_flow_state does not indicate NEW), as we will mark the flow as ACTIVE at the same time as accounting for the i2c lock operation. We also need to add an INVALID flow state, to indicate when we've done the release. Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Reported-by: Jian Zhang Tested-by: Jian Zhang Signed-off-by: Jeremy Kerr Link: https://lore.kernel.org/r/20221110053135.329071-1-jk@codeconstruct.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9a23917697f9f8ddeb5a4424eb45df73fdc7e036 Author: Mohd Faizal Abdul Rahim Date: Thu Nov 10 14:45:52 2022 +0800 net: stmmac: ensure tx function is not running in stmmac_xdp_release() [ Upstream commit 77711683a50477de39757d67ab1a3638220d6860 ] When stmmac_xdp_release() is called, there is a possibility that tx function is still running on other queues which will lead to tx queue timed out and reset adapter. This commit ensure that tx function is not running xdp before release flow continue to run. Fixes: ac746c8520d9 ("net: stmmac: enhance XDP ZC driver level switching performance") Signed-off-by: Song Yoong Siang Signed-off-by: Mohd Faizal Abdul Rahim Signed-off-by: Noor Azura Ahmad Tarmizi Link: https://lore.kernel.org/r/20221110064552.22504-1-noor.azura.ahmad.tarmizi@linux.intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 682b94cdd38c1f5a7b3b8571ce85811ef3392232 Author: Michael Sit Wei Hong Date: Thu Nov 10 13:49:38 2022 +0800 net: phy: dp83867: Fix SGMII FIFO depth for non OF devices [ Upstream commit e2a54350dc9642e7dfc07335ca355581caa9dbfe ] Current driver code will read device tree node information, and set default values if there is no info provided. This is not done in non-OF devices leading to SGMII fifo depths being set to the smallest size. This patch sets the value to the default value of the PHY as stated in the PHY datasheet. Fixes: 4dc08dcc9f6f ("net: phy: dp83867: introduce critical chip default init for non-of platform") Signed-off-by: Michael Sit Wei Hong Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20221110054938.925347-1-michael.wei.hong.sit@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dbca20e1bf0cbce93ea04224cf9224d9be7e6eb8 Author: Yuan Can Date: Thu Nov 10 02:16:42 2022 +0000 net: hinic: Fix error handling in hinic_module_init() [ Upstream commit 8eab9be56cc6b702a445d2b6d0256aa0992316b3 ] A problem about hinic create debugfs failed is triggered with the following log given: [ 931.419023] debugfs: Directory 'hinic' with parent '/' already present! The reason is that hinic_module_init() returns pci_register_driver() directly without checking its return value, if pci_register_driver() failed, it returns without destroy the newly created debugfs, resulting the debugfs of hinic can never be created later. hinic_module_init() hinic_dbg_register_debugfs() # create debugfs directory pci_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without destroy debugfs directory Fix by removing debugfs when pci_register_driver() returns error. Fixes: 253ac3a97921 ("hinic: add support to query sq info") Signed-off-by: Yuan Can Reviewed-by: Leon Romanovsky Link: https://lore.kernel.org/r/20221110021642.80378-1-yuancan@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d4b8394725079670be309f9a35ad88a8cbbaaefd Author: Yang Yingliang Date: Wed Nov 9 21:28:32 2022 +0800 mISDN: fix possible memory leak in mISDN_dsp_element_register() [ Upstream commit 98a2ac1ca8fd6eca6867726fe238d06e75eb1acd ] Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, use put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. The 'entry' is going to be freed in mISDN_dsp_dev_release(), so the kfree() is removed. list_del() is called in mISDN_dsp_dev_release(), so it need be initialized. Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221109132832.3270119-1-yangyingliang@huawei.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0130832ff9e5e133abe0efdfe4757e42cd2e572a Author: Wei Yongjun Date: Wed Nov 9 15:01:36 2022 +0000 net: bgmac: Drop free_netdev() from bgmac_enet_remove() [ Upstream commit 6f928ab8ee9bfbcb0e631c47ea8a16c3d5116ff1 ] netdev is allocated in bgmac_alloc() with devm_alloc_etherdev() and will be auto released in ->remove and ->probe failure path. Using free_netdev() in bgmac_enet_remove() leads to double free. Fixes: 34a5102c3235 ("net: bgmac: allocate struct bgmac just once & don't copy it") Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20221109150136.2991171-1-weiyongjun@huaweicloud.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6e75b9847c7fced20fea58418d294a6f08105957 Author: Niklas Cassel Date: Wed Nov 9 00:15:34 2022 +0100 ata: libata-core: do not issue non-internal commands once EH is pending [ Upstream commit e20e81a24a4d58744a29715aac2f795cd1651955 ] While the ATA specification states that a device should return command aborted for all commands queued after the device has entered error state, since ATA only keeps the sense data for the latest command (in non-NCQ case), we really don't want to send block layer commands to the device after it has entered error state. (Only ATA EH commands should be sent, to read the sense data etc.) Currently, scsi_queue_rq() will check if scsi_host_in_recovery() (state is SHOST_RECOVERY), and if so, it will _not_ issue a command via: scsi_dispatch_cmd() -> host->hostt->queuecommand() (ata_scsi_queuecmd()) -> __ata_scsi_queuecmd() -> ata_scsi_translate() -> ata_qc_issue() Before commit e494f6a72839 ("[SCSI] improved eh timeout handler"), when receiving a TFES error IRQ, the call chain looked like this: ahci_error_intr() -> ata_port_abort() -> ata_do_link_abort() -> ata_qc_complete() -> ata_qc_schedule_eh() -> blk_abort_request() -> blk_rq_timed_out() -> q->rq_timed_out_fn() (scsi_times_out()) -> scsi_eh_scmd_add() -> scsi_host_set_state(shost, SHOST_RECOVERY) Which meant that as soon as an error IRQ was serviced, SHOST_RECOVERY would be set. However, after commit e494f6a72839 ("[SCSI] improved eh timeout handler"), scsi_times_out() will instead call scsi_abort_command() which will queue delayed work, and the worker function scmd_eh_abort_handler() will call scsi_eh_scmd_add(), which calls scsi_host_set_state(shost, SHOST_RECOVERY). So now, after the TFES error IRQ has been serviced, we need to wait for the SCSI workqueue to run its work before SHOST_RECOVERY gets set. It is worth noting that, even before commit e494f6a72839 ("[SCSI] improved eh timeout handler"), we could receive an error IRQ from the time when scsi_queue_rq() checks scsi_host_in_recovery(), to the time when ata_scsi_queuecmd() is actually called. In order to handle both the delayed setting of SHOST_RECOVERY and the window where we can receive an error IRQ, add a check against ATA_PFLAG_EH_PENDING (which gets set when servicing the error IRQ), inside ata_scsi_queuecmd() itself, while holding the ap->lock. (Since the ap->lock is held while servicing IRQs.) Fixes: e494f6a72839 ("[SCSI] improved eh timeout handler") Signed-off-by: Niklas Cassel Tested-by: John Garry Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit cc79997366d5c8822dc77714d96a7d7353744814 Author: Xu Kuohai Date: Thu Nov 10 07:21:28 2022 -0500 bpf: Initialize same number of free nodes for each pcpu_freelist [ Upstream commit 4b45cd81f737d79d0fbfc0d320a1e518e7f0bbf0 ] pcpu_freelist_populate() initializes nr_elems / num_possible_cpus() + 1 free nodes for some CPUs, and then possibly one CPU with fewer nodes, followed by remaining cpus with 0 nodes. For example, when nr_elems == 256 and num_possible_cpus() == 32, CPU 0~27 each gets 9 free nodes, CPU 28 gets 4 free nodes, CPU 29~31 get 0 free nodes, while in fact each CPU should get 8 nodes equally. This patch initializes nr_elems / num_possible_cpus() free nodes for each CPU firstly, then allocates the remaining free nodes by one for each CPU until no free nodes left. Fixes: e19494edab82 ("bpf: introduce percpu_freelist") Signed-off-by: Xu Kuohai Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20221110122128.105214-1-xukuohai@huawei.com Signed-off-by: Sasha Levin commit 0a087842d10b5daa123ee5291e386cdd78413705 Author: Zhang Xiaoxu Date: Fri Nov 11 15:12:12 2022 +0800 cifs: Fix connections leak when tlink setup failed [ Upstream commit 1dcdf5f5b2137185cbdd5385f29949ab3da4f00c ] If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit. Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST) Let's check the result of tlink setup, and do some cleanup. Fixes: 56c762eb9bee ("cifs: Refactor out cifs_mount()") Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Zhang Xiaoxu Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 154cdff899f94dccf286cccc17941b2d153a9f83 Author: Pavel Begunkov Date: Fri Nov 11 16:51:29 2022 +0000 io_uring/poll: fix double poll req->flags races [ Upstream commit 30a33669fa21cd3dc7d92a00ba736358059014b7 ] io_poll_double_prepare() | io_poll_wake() | poll->head = NULL smp_load(&poll->head); /* NULL */ | flags = req->flags; | | req->flags &= ~SINGLE_POLL; req->flags = flags | DOUBLE_POLL | The idea behind io_poll_double_prepare() is to serialise with the first poll entry by taking the wq lock. However, it's not safe to assume that io_poll_wake() is not running when we can't grab the lock and so we may race modifying req->flags. Skip double poll setup if that happens. It's ok because the first poll entry will only be removed when it's definitely completing, e.g. pollfree or oneshot with a valid mask. Fixes: 49f1c68e048f1 ("io_uring: optimise submission side poll_refs") Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/b7fab2d502f6121a7d7b199fe4d914a43ca9cdfd.1668184658.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 03285766226646464a8d7a8ead988ae4c29e59e1 Author: Liao Chang Date: Thu Nov 3 09:18:15 2022 +0800 MIPS: Loongson64: Add WARN_ON on kexec related kmalloc failed [ Upstream commit fa706927f4722a2df723b2a28d139b1904a3e7fa ] Add WARN_ON on kexec related kmalloc failed, avoid to pass NULL pointer to following memcpy and loongson_kexec_prepare. Fixes: 6ce48897ce47 ("MIPS: Loongson64: Add kexec/kdump support") Signed-off-by: Liao Chang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit eaf0b5061cfaea2a2c49f1f389e2108d9fb5718b Author: Rongwei Zhang Date: Wed Nov 2 20:27:39 2022 +0800 MIPS: fix duplicate definitions for exported symbols [ Upstream commit 612d80784fdc0c2e2ee2e2d901a55ef2f72ebf4b ] Building with clang-14 fails with: AS arch/mips/kernel/relocate_kernel.o :0: error: symbol 'kexec_args' is already defined :0: error: symbol 'secondary_kexec_args' is already defined :0: error: symbol 'kexec_start_address' is already defined :0: error: symbol 'kexec_indirection_page' is already defined :0: error: symbol 'relocate_new_kernel_size' is already defined It turns out EXPORT defined in asm/asm.h expands to a symbol definition, so there is no need to define these symbols again. Remove duplicated symbol definitions. Fixes: 7aa1c8f47e7e ("MIPS: kdump: Add support") Signed-off-by: Rongwei Zhang Reviewed-by: Nathan Chancellor Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit ab6a433aabb2cfb8de45f28b4274a0468225da83 Author: Jaco Coetzee Date: Wed Nov 9 15:27:57 2022 -0500 nfp: change eeprom length to max length enumerators [ Upstream commit f3a72878a3de720661b7ed0d6b7f7c506ddb8a52 ] Extend the size of QSFP EEPROM for types SSF8436 and SFF8636 from 256 to 640 bytes in order to expose all the EEPROM pages by ethtool. For SFF-8636 and SFF-8436 specifications, the driver exposes 256 bytes of EEPROM data for ethtool's get_module_eeprom() callback, resulting in "netlink error: Invalid argument" when an EEPROM read with an offset larger than 256 bytes is attempted. Changing the length enumerators to the _MAX_LEN variants exposes all 640 bytes of the EEPROM allowing upper pages 1, 2 and 3 to be read. Fixes: 96d971e307cc ("ethtool: Add fallback to get_module_eeprom from netlink command") Signed-off-by: Jaco Coetzee Reviewed-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f54331962883f4fc4bf5e487e6e7cf07c4567fef Author: Yang Yingliang Date: Tue Nov 8 21:40:04 2022 +0800 ata: libata-transport: fix error handling in ata_tdev_add() [ Upstream commit 1ff36351309e3eadcff297480baf4785e726de9b ] In ata_tdev_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 13 PID: 13603 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #36 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x3a0 lr : device_del+0x44/0x3a0 Call trace: device_del+0x48/0x3a0 attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tdev_delete+0x24/0x50 [libata] ata_tlink_delete+0x40/0xa0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tdev_add(). In the error path, device_del() is called to delete the device which was added earlier in this function, and ata_tdev_free() is called to free ata_dev. Fixes: d9027470b886 ("[libata] Add ATA transport class") Signed-off-by: Yang Yingliang Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit d5234480ca822bdcf03fe4d6a590ddcb854558f7 Author: Yang Yingliang Date: Tue Nov 8 21:40:03 2022 +0800 ata: libata-transport: fix error handling in ata_tlink_add() [ Upstream commit cf0816f6322c5c37ee52655f928e91ecf32da103 ] In ata_tlink_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #12 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tlink_delete+0x88/0xb0 [libata] ata_tport_delete+0x2c/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tlink_add(). Fixes: d9027470b886 ("[libata] Add ATA transport class") Signed-off-by: Yang Yingliang Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 52d9bb0adae9359711a0c5271430afd3754069e7 Author: Yang Yingliang Date: Tue Nov 8 21:40:02 2022 +0800 ata: libata-transport: fix error handling in ata_tport_add() [ Upstream commit 3613dbe3909dcc637fe6be00e4dc43b4aa0470ee ] In ata_tport_add(), the return value of transport_add_device() is not checked. As a result, it causes null-ptr-deref while removing the module, because transport_remove_device() is called to remove the device that was not added. Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0 CPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc3+ #8 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x48/0x39c lr : device_del+0x44/0x39c Call trace: device_del+0x48/0x39c attribute_container_class_device_del+0x28/0x40 transport_remove_classdev+0x60/0x7c attribute_container_device_trigger+0x118/0x120 transport_remove_device+0x20/0x30 ata_tport_delete+0x34/0x60 [libata] ata_port_detach+0x148/0x1b0 [libata] ata_pci_remove_one+0x50/0x80 [libata] ahci_remove_one+0x4c/0x8c [ahci] Fix this by checking and handling return value of transport_add_device() in ata_tport_add(). Fixes: d9027470b886 ("[libata] Add ATA transport class") Signed-off-by: Yang Yingliang Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 865a6da40ba092c18292ae5f6194756131293745 Author: Yang Yingliang Date: Tue Nov 8 21:40:01 2022 +0800 ata: libata-transport: fix double ata_host_put() in ata_tport_add() [ Upstream commit 8c76310740807ade5ecdab5888f70ecb6d35732e ] In the error path in ata_tport_add(), when calling put_device(), ata_tport_release() is called, it will put the refcount of 'ap->host'. And then ata_host_put() is called again, the refcount is decreased to 0, ata_host_release() is called, all ports are freed and set to null. When unbinding the device after failure, ata_host_stop() is called to release the resources, it leads a null-ptr-deref(), because all the ports all freed and null. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 CPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G E 6.1.0-rc3+ #8 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ata_host_stop+0x3c/0x84 [libata] lr : release_nodes+0x64/0xd0 Call trace: ata_host_stop+0x3c/0x84 [libata] release_nodes+0x64/0xd0 devres_release_all+0xbc/0x1b0 device_unbind_cleanup+0x20/0x70 really_probe+0x158/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0xb4/0x220 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x40 bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __pci_register_driver+0x4c/0x60 ahci_pci_driver_init+0x30/0x1000 [ahci] Fix this by removing redundant ata_host_put() in the error path. Fixes: 2623c7a5f279 ("libata: add refcounting to ata_host") Signed-off-by: Yang Yingliang Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 27a8616eb548e0ab7ef2502c91128736a1c98e8f Author: Peng Fan Date: Fri Nov 4 13:49:42 2022 +0800 arm64: dts: imx93-pinfunc: drop execution permission [ Upstream commit 2db1fdb25d209a88112fd82eb493976d66057d10 ] Drop the header file execution permission Signed-off-by: Peng Fan Fixes: ec8b5b5058ea ("arm64: dts: freescale: Add i.MX93 dtsi support") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 180451ac657f27546c12680258437bbae00b00cd Author: Marek Vasut Date: Wed Nov 2 20:19:47 2022 +0100 arm64: dts: imx8mn: Fix NAND controller size-cells [ Upstream commit 5468e93b5b1083eaa729f98e59da18c85d9c4126 ] The NAND controller size-cells should be 0 per DT bindings. Fix the following warning produces by DT bindings check: " nand-controller@33002000: #size-cells:0:0: 0 was expected nand-controller@33002000: Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected) " Fixes: 6c3debcbae47a ("arm64: dts: freescale: Add i.MX8MN dtsi support") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 693b5f1eb9bc2faf5aeb355a146fc2d7a60f73d1 Author: Jingbo Xu Date: Fri Nov 4 13:40:27 2022 +0800 erofs: put metabuf in error path in fscache mode [ Upstream commit 75e43355cbe4d5948a79bd592f2ffecb9f75f75d ] For tail packing layout, put metabuf when error is encountered. Fixes: 1ae9470c3e14 ("erofs: clean up .read_folio() and .readahead() in fscache mode") Signed-off-by: Jingbo Xu Reviewed-by: Gao Xiang Reviewed-by: Jia Zhu Reviewed-by: Chao Yu Link: https://lore.kernel.org/r/20221104054028.52208-2-jefflexu@linux.alibaba.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 0be388254c5f280f59bedb911c954c6754a65144 Author: Marek Vasut Date: Wed Nov 2 20:19:46 2022 +0100 arm64: dts: imx8mm: Fix NAND controller size-cells [ Upstream commit 1610233bc2c2cae2dff9e101e6ea5ef69cceb0e9 ] The NAND controller size-cells should be 0 per DT bindings. Fix the following warning produces by DT bindings check: " nand-controller@33002000: #size-cells:0:0: 0 was expected nand-controller@33002000: Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected) " Fix the missing space in node name too. Fixes: a05ea40eb384e ("arm64: dts: imx: Add i.mx8mm dtsi support") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 48f3390b9efc9c78d13adb33108afe3202b7bbcf Author: Marek Vasut Date: Wed Nov 2 20:19:45 2022 +0100 ARM: dts: imx7: Fix NAND controller size-cells [ Upstream commit 753395ea1e45c724150070b5785900b6a44bd5fb ] The NAND controller size-cells should be 0 per DT bindings. Fix the following warning produces by DT bindings check: " nand-controller@33002000: #size-cells:0:0: 0 was expected nand-controller@33002000: Unevaluated properties are not allowed ('#address-cells', '#size-cells' were unexpected) " Fix the missing space in node name too. Fixes: e7495a45a76de ("ARM: dts: imx7: add GPMI NAND and APBH DMA") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 93d3479c32ef63d6b82c583ef63abea85d17e40b Author: Alexander Stein Date: Tue Nov 1 10:30:31 2022 +0100 arm64: dts: imx8mm-tqma8mqml-mba8mx: Fix USB DR [ Upstream commit 63fd9437ec81899fc36bb642d558378bc89aa4f9 ] Using extcon USB host mode works properly on DR interface, e.g. enabling/disabling VBUS. But USB device mode is not working. Fix this by switching to usb-role-switch instead. Fixes: dfcd1b6f7620 ("arm64: dts: freescale: add initial device tree for TQMa8MQML with i.MX8MM") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 3acd2016421b2e628acad65495d15493bf7a3bc3 Author: Shang XiaoJing Date: Tue Nov 1 15:07:16 2022 +0800 drm: Fix potential null-ptr-deref in drm_vblank_destroy_worker() [ Upstream commit 4979524f5a2a8210e87fde2f642b0dc060860821 ] drm_vblank_init() call drmm_add_action_or_reset() with drm_vblank_init_release() as action. If __drmm_add_action() failed, will directly call drm_vblank_init_release() with the vblank whose worker is NULL. As the resule, a null-ptr-deref will happen in kthread_destroy_worker(). Add the NULL check before calling drm_vblank_destroy_worker(). BUG: null-ptr-deref KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] CPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty RIP: 0010:kthread_destroy_worker+0x25/0xb0 Call Trace: drm_vblank_init_release+0x124/0x220 [drm] ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm] __drmm_add_action_or_reset+0x41/0x50 [drm] drm_vblank_init+0x282/0x310 [drm] vkms_init+0x35f/0x1000 [vkms] ? 0xffffffffc4508000 ? lock_is_held_type+0xd7/0x130 ? __kmem_cache_alloc_node+0x1c2/0x2b0 ? lock_is_held_type+0xd7/0x130 ? 0xffffffffc4508000 do_one_initcall+0xd0/0x4f0 ... do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 Fixes: 5e6c2b4f9161 ("drm/vblank: Add vblank works") Signed-off-by: Shang XiaoJing Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20221101070716.9189-3-shangxiaojing@huawei.com Signed-off-by: Sasha Levin commit bd8d1335e6e70a396094ef98913b513140c0b86b Author: Shang XiaoJing Date: Tue Nov 1 15:07:15 2022 +0800 drm/drv: Fix potential memory leak in drm_dev_init() [ Upstream commit ff963634f7b2e0dc011349abb3fb81a0d074f443 ] drm_dev_init() will add drm_dev_init_release() as a callback. When drmm_add_action() failed, the release function won't be added. As the result, the ref cnt added by device_get() in drm_dev_init() won't be put by drm_dev_init_release(), which leads to the memleak. Use drmm_add_action_or_reset() instead of drmm_add_action() to prevent memleak. unreferenced object 0xffff88810bc0c800 (size 2048): comm "modprobe", pid 8322, jiffies 4305809845 (age 15.292s) hex dump (first 32 bytes): e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00 ................ 20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff $<............. backtrace: [<000000007251f72d>] __kmalloc+0x4b/0x1c0 [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0 [<000000004452a479>] platform_device_register_full+0x24/0x1c0 [<0000000089f4ea61>] 0xffffffffa0736051 [<00000000235b2441>] do_one_initcall+0x7a/0x380 [<0000000001a4a177>] do_init_module+0x5c/0x230 [<000000002bf8a8e2>] load_module+0x227d/0x2420 [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140 [<00000000c99fc324>] do_syscall_64+0x3f/0x90 [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: 2cbf7fc6718b ("drm: Use drmm_ for drm_dev_init cleanup") Signed-off-by: Shang XiaoJing Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20221101070716.9189-2-shangxiaojing@huawei.com Signed-off-by: Sasha Levin commit 1983f6c36aa0467e117b9b344445a1e2d092b00e Author: Aishwarya Kothari Date: Wed Aug 31 16:16:22 2022 +0200 drm/panel: simple: set bpc field for logic technologies displays [ Upstream commit 876153ab068b2507a19aa3ef481f5b00a2cc780f ] In case bpc is not set for a panel it then throws a WARN(). Add bpc to the panels logictechno_lt170410_2whc and logictechno_lt161010_2nh. Fixes: 5728fe7fa539 ("drm/panel: simple: add display timings for logic technologies displays") Signed-off-by: Aishwarya Kothari Signed-off-by: Francesco Dolcini Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20220831141622.39605-1-francesco.dolcini@toradex.com Signed-off-by: Sasha Levin commit f0bf751585d30acc52a9d450e85e0d9f1d6b444c Author: Gaosheng Cui Date: Thu Nov 10 17:44:45 2022 +0800 drm/vc4: kms: Fix IS_ERR() vs NULL check for vc4_kms [ Upstream commit dba9e3467425800f9d3a14e8b6a0f85c731c1650 ] The drm_atomic_get_new_private_obj_state() function returns NULL on error path, drm_atomic_get_old_private_obj_state() function returns NULL on error path, too, they does not return error pointers. By the way, vc4_hvs_get_new/old_global_state() should return ERR_PTR(-EINVAL), otherwise there will be null-ptr-defer issue, such as follows: In function vc4_atomic_commit_tail(): |-- old_hvs_state = vc4_hvs_get_old_global_state(state); <-- return NULL |-- if (WARN_ON(IS_ERR(old_hvs_state))) <-- no return |-- unsigned long state_rate = max(old_hvs_state->core_clock_rate, new_hvs_state->core_clock_rate); <-- null-ptr-defer Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Gaosheng Cui Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20221110094445.2930509-6-cuigaosheng1@huawei.com Signed-off-by: Sasha Levin commit 5834a3a98cd266ad35a229923c0adbd0addc8d68 Author: Zeng Heng Date: Thu Nov 10 16:20:56 2022 +0800 pinctrl: devicetree: fix null pointer dereferencing in pinctrl_dt_to_map [ Upstream commit 91d5c5060ee24fe8da88cd585bb43b843d2f0dce ] Here is the BUG report by KASAN about null pointer dereference: BUG: KASAN: null-ptr-deref in strcmp+0x2e/0x50 Read of size 1 at addr 0000000000000000 by task python3/2640 Call Trace: strcmp __of_find_property of_find_property pinctrl_dt_to_map kasprintf() would return NULL pointer when kmalloc() fail to allocate. So directly return ENOMEM, if kasprintf() return NULL pointer. Fixes: 57291ce295c0 ("pinctrl: core device tree mapping table parsing support") Signed-off-by: Zeng Heng Link: https://lore.kernel.org/r/20221110082056.2014898-1-zengheng4@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b9e4d71840ca4e67f4e3454d2820ca5540768903 Author: Yang Jihong Date: Tue Nov 8 09:58:57 2022 +0800 selftests/bpf: Fix test_progs compilation failure in 32-bit arch [ Upstream commit 5704bc7e8991164b14efb748b5afa0715c25fac3 ] test_progs fails to be compiled in the 32-bit arch, log is as follows: test_progs.c:1013:52: error: format '%ld' expects argument of type 'long int', but argument 3 has type 'size_t' {aka 'unsigned int'} [-Werror=format=] 1013 | sprintf(buf, "MSG_TEST_LOG (cnt: %ld, last: %d)", | ~~^ | | | long int | %d 1014 | strlen(msg->test_log.log_buf), | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | size_t {aka unsigned int} Fix it. Fixes: 91b2c0afd00c ("selftests/bpf: Add parallelism to test_progs") Signed-off-by: Yang Jihong Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20221108015857.132457-1-yangjihong1@huawei.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 6e62d44800aaa210af1f217b035b8e4f040d69df Author: Pu Lehui Date: Tue Nov 8 20:19:45 2022 +0800 selftests/bpf: Fix casting error when cross-compiling test_verifier for 32-bit platforms [ Upstream commit 0811664da064c6d7ca64c02f5579f758a007e52d ] When cross-compiling test_verifier for 32-bit platforms, the casting error is shown below: test_verifier.c:1263:27: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 1263 | info.xlated_prog_insns = (__u64)*buf; | ^ cc1: all warnings being treated as errors Fix it by adding zero-extension for it. Fixes: 933ff53191eb ("selftests/bpf: specify expected instructions in test_verifier tests") Signed-off-by: Pu Lehui Acked-by: Yonghong Song Link: https://lore.kernel.org/r/20221108121945.4104644-1-pulehui@huaweicloud.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit 4859314b599aff52297adfc6cab1823a9885f5b3 Author: Maciej W. Rozycki Date: Fri Sep 23 19:52:08 2022 +0100 parport_pc: Avoid FIFO port location truncation [ Upstream commit ab126f51c93a15093df604f661c9480854c005a3 ] Match the data type of a temporary holding a reference to the FIFO port with the type of the original reference coming from `struct parport', avoiding data truncation with LP64 ports such as SPARC64 that refer to PCI port I/O locations via their corresponding MMIO addresses and will therefore have non-zero bits in the high 32-bit part of the reference. And in any case it is cleaner to have the data types matching here. Signed-off-by: Maciej W. Rozycki Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://lore.kernel.org/linux-pci/20220419033752.GA1101844@bhelgaas/ Acked-by: Sudip Mukherjee Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209231912550.29493@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d9c31e728843259209fb530c59995e4fe262699f Author: Yang Yingliang Date: Fri Nov 4 10:13:34 2022 +0800 siox: fix possible memory leak in siox_device_add() [ Upstream commit 6e63153db50059fb78b8a8447b132664887d24e3 ] If device_register() returns error in siox_device_add(), the name allocated by dev_set_name() need be freed. As comment of device_register() says, it should use put_device() to give up the reference in the error path. So fix this by calling put_device(), then the name can be freed in kobject_cleanup(), and sdevice is freed in siox_device_release(), set it to null in error path. Fixes: bbecb07fa0af ("siox: new driver framework for eckelmann SIOX") Signed-off-by: Yang Yingliang Reviewed-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20221104021334.618189-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 117e0c75a3410e744099b96e09763257813ee070 Author: Sagi Grimberg Date: Wed Nov 9 05:29:57 2022 +0200 nvmet: fix a memory leak [ Upstream commit e65fdf530f55c5e387db14470a59a399faa29613 ] We need to also free the dhchap_ctrl_secret when releasing nvmet_host. kmemleak complaint: -- unreferenced object 0xffff99b1cbca5140 (size 64): comm "check", pid 4864, jiffies 4305092436 (age 2913.583s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 65 36 2b 41 63 44 DHHC-1:00:e6+AcD 39 76 47 4d 52 57 59 78 67 54 47 44 51 59 47 78 9vGMRWYxgTGDQYGx backtrace: [<00000000c07d369d>] kstrdup+0x2e/0x60 [<000000001372171c>] 0xffffffffc0cceec6 [<0000000010dbf50b>] 0xffffffffc0cc6783 [<000000007465e93c>] configfs_write_iter+0xb1/0x120 [<0000000039c23f62>] vfs_write+0x2be/0x3c0 [<000000002da4351c>] ksys_write+0x5f/0xe0 [<00000000d5011e32>] do_syscall_64+0x38/0x90 [<00000000503870cf>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: db1312dd9548 ("nvmet: implement basic In-Band Authentication") Signed-off-by: Sagi Grimberg Reviewed-by: Chaitanya Kulkarni Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit b09b539c15509cd7427bb98d8472b240efeefbc3 Author: D Scott Phillips Date: Wed Nov 2 09:01:06 2022 -0700 arm64: Fix bit-shifting UB in the MIDR_CPU_MODEL() macro [ Upstream commit 8ec8490a1950efeccb00967698cf7cb2fcd25ca7 ] CONFIG_UBSAN_SHIFT with gcc-5 complains that the shifting of ARM_CPU_IMP_AMPERE (0xC0) into bits [31:24] by MIDR_CPU_MODEL() is undefined behavior. Well, sort of, it actually spells the error as: arch/arm64/kernel/proton-pack.c: In function 'spectre_bhb_loop_affected': arch/arm64/include/asm/cputype.h:44:2: error: initializer element is not constant (((imp) << MIDR_IMPLEMENTOR_SHIFT) | \ ^ This isn't an issue for other Implementor codes, as all the other codes have zero in the top bit and so are representable as a signed int. Cast the implementor code to unsigned in MIDR_CPU_MODEL to remove the undefined behavior. Fixes: 0e5d5ae837c8 ("arm64: Add AMPERE1 to the Spectre-BHB affected list") Reported-by: Geert Uytterhoeven Signed-off-by: D Scott Phillips Link: https://lore.kernel.org/r/20221102160106.1096948-1-scott@os.amperecomputing.com Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 7255e1fdf08cf833876b41cdc49971df1e7fe0a3 Author: AngeloGioacchino Del Regno Date: Fri Nov 4 11:56:05 2022 +0100 pinctrl: mediatek: common-v2: Fix bias-disable for PULL_PU_PD_RSEL_TYPE [ Upstream commit fed74d75277da865da9ba334d3f5d5e3e327971d ] In pinctrl-paris we're calling the .bias_set_combo() callback when we are asked to set the pin bias to either pull up/down or pull disable. On newer platforms, this callback is mtk_pinconf_bias_set_combo(), located in pinctrl-mtk-common-v2.c: this will check the "pull type" assigned to the requested pin and in case said pin's pull type is MTK_PULL_PU_PD_RSEL_TYPE, this function will set RSEL first, PUPD last, which is fine. The issue comes when we're requesting PIN_CONFIG_BIAS_DISABLE, as this does *not* require setting RSEL but only PU_PD: in this case, the arg is MTK_DISABLE (zero), which is not a supported RSEL, due to which function mtk_pinconf_bias_set_rsel() returns a failure; because of that, mtk_pinconf_bias_set_pu_pd() is never called, hence the pin bias is never set to DISABLE. To fix this issue, add a check to mtk_pinconf_bias_set_rsel(): if we are entering that function with no pullup requested and at the same time the arg is MTK_DISABLE, this means that we're trying to disable pin bias, hence it's safe to return cleanly without ever setting any RSEL register. This makes mtk_pinconf_bias_set_combo() happy, going on with setting the PU_PD registers, which is the only action to actually take to disable bias on a pin/pingroup. Fixes: fb34a9ae383a ("pinctrl: mediatek: support rsel feature") Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221104105605.33720-1-angelogioacchino.delregno@collabora.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 616a725c62e9c42d5073fbd1045832eae64a2ca5 Author: Dylan Yudaken Date: Tue Nov 8 07:30:16 2022 -0800 io_uring: calculate CQEs from the user visible value [ Upstream commit 0fc8c2acbfc789a977a50a4a9812a8e4b37958ce ] io_cqring_wait (and it's wake function io_has_work) used cached_cq_tail in order to calculate the number of CQEs. cached_cq_tail is set strictly before the user visible rings->cq.tail However as far as userspace is concerned, if io_uring_enter(2) is called with a minimum number of events, they will verify by checking rings->cq.tail. It is therefore possible for io_uring_enter(2) to return early with fewer events visible to the user. Instead make the wait functions read from the user visible value, so there will be no discrepency. This is triggered eventually by the following reproducer: struct io_uring_sqe *sqe; struct io_uring_cqe *cqe; unsigned int cqe_ready; struct io_uring ring; int ret, i; ret = io_uring_queue_init(N, &ring, 0); assert(!ret); while(true) { for (i = 0; i < N; i++) { sqe = io_uring_get_sqe(&ring); io_uring_prep_nop(sqe); sqe->flags |= IOSQE_ASYNC; } ret = io_uring_submit(&ring); assert(ret == N); do { ret = io_uring_wait_cqes(&ring, &cqe, N, NULL, NULL); } while(ret == -EINTR); cqe_ready = io_uring_cq_ready(&ring); assert(!ret); assert(cqe_ready == N); io_uring_cq_advance(&ring, N); } Fixes: ad3eb2c89fb2 ("io_uring: split overflow state into SQ and CQ side") Signed-off-by: Dylan Yudaken Link: https://lore.kernel.org/r/20221108153016.1854297-1-dylany@meta.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 83946d772e756734a900ef99dbe0aeda506adf37 Author: Wang Yufen Date: Tue Nov 8 13:11:31 2022 +0800 bpf: Fix memory leaks in __check_func_call [ Upstream commit eb86559a691cea5fa63e57a03ec3dc9c31e97955 ] kmemleak reports this issue: unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd The root case here is: In function prepare_func_exit(), the callee is not released in the abnormal scenario after "state->curframe--;". To fix, move "state->curframe--;" to the very bottom of the function, right when we free callee and reset frame[] pointer to NULL, as Andrii suggested. In addition, function __check_func_call() has a similar problem. In the abnormal scenario before "state->curframe++;", the callee also should be released by free_func_state(). Fixes: 69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper") Fixes: fd978bf7fd31 ("bpf: Add reference tracking to verifier") Signed-off-by: Wang Yufen Link: https://lore.kernel.org/r/1667884291-15666-1-git-send-email-wangyufen@huawei.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin commit cb1876de59ef13e064be183adfc737df39e36ce8 Author: Jeff Layton Date: Tue Nov 8 11:23:11 2022 -0500 nfsd: put the export reference in nfsd4_verify_deleg_dentry [ Upstream commit 50256e4793a5e5ab77703c82a47344ad2e774a59 ] nfsd_lookup_dentry returns an export reference in addition to the dentry ref. Ensure that we put it too. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2138866 Fixes: 876c553cb410 ("NFSD: verify the opened dentry after setting a delegation") Reported-by: Yongcheng Yang Signed-off-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 813cab5147cedf6b3724865df1af065c05b0f597 Author: Serge Semin Date: Mon Nov 7 23:39:44 2022 +0300 block: sed-opal: kmalloc the cmd/resp buffers [ Upstream commit f829230dd51974c1f4478900ed30bb77ba530b40 ] In accordance with [1] the DMA-able memory buffers must be cacheline-aligned otherwise the cache writing-back and invalidation performed during the mapping may cause the adjacent data being lost. It's specifically required for the DMA-noncoherent platforms [2]. Seeing the opal_dev.{cmd,resp} buffers are implicitly used for DMAs in the NVME and SCSI/SD drivers in framework of the nvme_sec_submit() and sd_sec_submit() methods respectively they must be cacheline-aligned to prevent the denoted problem. One of the option to guarantee that is to kmalloc the buffers [2]. Let's explicitly allocate them then instead of embedding into the opal_dev structure instance. Note this fix was inspired by the commit c94b7f9bab22 ("nvme-hwmon: kmalloc the NVME SMART log buffer"). [1] Documentation/core-api/dma-api.rst [2] Documentation/core-api/dma-api-howto.rst Fixes: 455a7b238cd6 ("block: Add Sed-opal library") Signed-off-by: Serge Semin Reviewed-by: Christoph Hellwig Link: https://lore.kernel.org/r/20221107203944.31686-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 73ed0cd9179a18289b94ce9c76c8d2efb5c22bda Author: Jingbo Xu Date: Fri Nov 4 13:40:28 2022 +0800 erofs: get correct count for unmapped range in fscache mode [ Upstream commit e6d9f9ba111b56154f1b1120252aff269cebd49c ] For unmapped range, the returned map.m_llen is zero, and thus the calculated count is unexpected zero. Prior to the refactoring introduced by commit 1ae9470c3e14 ("erofs: clean up .read_folio() and .readahead() in fscache mode"), only the readahead routine suffers from this. With the refactoring of making .read_folio() and .readahead() calling one common routine, both read_folio and readahead have this issue now. Fix this by calculating count separately in unmapped condition. Fixes: c665b394b9e8 ("erofs: implement fscache-based data readahead") Fixes: 1ae9470c3e14 ("erofs: clean up .read_folio() and .readahead() in fscache mode") Signed-off-by: Jingbo Xu Reviewed-by: Gao Xiang Reviewed-by: Chao Yu Link: https://lore.kernel.org/r/20221104054028.52208-3-jefflexu@linux.alibaba.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit f1f28d9b7e5a4832da99e7f94e4f4b76bf7a8628 Author: Jingbo Xu Date: Thu Sep 22 14:24:14 2022 +0800 erofs: clean up .read_folio() and .readahead() in fscache mode [ Upstream commit 1ae9470c3e14624b0f4d8741c22b5a94062c0e33 ] The implementation of these two functions in fscache mode is almost the same. Extract the same part as a generic helper to remove the code duplication. Signed-off-by: Jingbo Xu Reviewed-by: Jia Zhu Link: https://lore.kernel.org/r/20220922062414.20437-1-jefflexu@linux.alibaba.com Signed-off-by: Gao Xiang Stable-dep-of: e6d9f9ba111b ("erofs: get correct count for unmapped range in fscache mode") Signed-off-by: Sasha Levin commit 3eff34e01062ec08fbb45ce2baaaa644550be821 Author: Xin Long Date: Fri Nov 4 17:45:16 2022 -0400 sctp: clear out_curr if all frag chunks of current msg are pruned [ Upstream commit 2f201ae14ae0f91dbf1cffea7bb1e29e81d4d108 ] A crash was reported by Zhen Chen: list_del corruption, ffffa035ddf01c18->next is NULL WARNING: CPU: 1 PID: 250682 at lib/list_debug.c:49 __list_del_entry_valid+0x59/0xe0 RIP: 0010:__list_del_entry_valid+0x59/0xe0 Call Trace: sctp_sched_dequeue_common+0x17/0x70 [sctp] sctp_sched_fcfs_dequeue+0x37/0x50 [sctp] sctp_outq_flush_data+0x85/0x360 [sctp] sctp_outq_uncork+0x77/0xa0 [sctp] sctp_cmd_interpreter.constprop.0+0x164/0x1450 [sctp] sctp_side_effects+0x37/0xe0 [sctp] sctp_do_sm+0xd0/0x230 [sctp] sctp_primitive_SEND+0x2f/0x40 [sctp] sctp_sendmsg_to_asoc+0x3fa/0x5c0 [sctp] sctp_sendmsg+0x3d5/0x440 [sctp] sock_sendmsg+0x5b/0x70 and in sctp_sched_fcfs_dequeue() it dequeued a chunk from stream out_curr outq while this outq was empty. Normally stream->out_curr must be set to NULL once all frag chunks of current msg are dequeued, as we can see in sctp_sched_dequeue_done(). However, in sctp_prsctp_prune_unsent() as it is not a proper dequeue, sctp_sched_dequeue_done() is not called to do this. This patch is to fix it by simply setting out_curr to NULL when the last frag chunk of current msg is dequeued from out_curr stream in sctp_prsctp_prune_unsent(). Fixes: 5bbbbe32a431 ("sctp: introduce stream scheduler foundations") Reported-by: Zhen Chen Tested-by: Caowangbao Signed-off-by: Xin Long Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0c7175b89b06f886df0e8a26d99f2a3f1c750820 Author: Xin Long Date: Fri Nov 4 17:45:15 2022 -0400 sctp: remove the unnecessary sinfo_stream check in sctp_prsctp_prune_unsent [ Upstream commit 9f0b773210c27a8f5d98ddb2fc4ba60a42a3285f ] Since commit 5bbbbe32a431 ("sctp: introduce stream scheduler foundations"), sctp_stream_outq_migrate() has been called in sctp_stream_init/update to removes those chunks to streams higher than the new max. There is no longer need to do such check in sctp_prsctp_prune_unsent(). Signed-off-by: Xin Long Signed-off-by: Jakub Kicinski Stable-dep-of: 2f201ae14ae0 ("sctp: clear out_curr if all frag chunks of current msg are pruned") Signed-off-by: Sasha Levin commit c736876ee294bb4f271d76a25cc7d70c8537bc5d Author: Yang Yingliang Date: Mon Nov 7 20:48:28 2022 +0800 scsi: scsi_transport_sas: Fix error handling in sas_phy_add() [ Upstream commit 5d7bebf2dfb0dc97aac1fbace0910e557ecdb16f ] If transport_add_device() fails in sas_phy_add(), the kernel will crash trying to delete the device in transport_remove_device() called from sas_remove_host(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108 CPU: 61 PID: 42829 Comm: rmmod Kdump: loaded Tainted: G W 6.1.0-rc1+ #173 pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : device_del+0x54/0x3d0 lr : device_del+0x37c/0x3d0 Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_phy_delete+0x30/0x60 [scsi_transport_sas] do_sas_phy_delete+0x6c/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x40/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] hisi_sas_remove+0x40/0x68 [hisi_sas_main] hisi_sas_v2_remove+0x20/0x30 [hisi_sas_v2_hw] platform_remove+0x2c/0x60 Fix this by checking and handling return value of transport_add_device() in sas_phy_add(). Fixes: c7ebbbce366c ("[SCSI] SAS transport class") Suggested-by: John Garry Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20221107124828.115557-1-yangyingliang@huawei.com Reviewed-by: John Garry Reviewed-by: Jason Yan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a2282bd27fc97f8a65898f81d8abf7df41b8e4f7 Author: Krzysztof Kozlowski Date: Mon Nov 7 10:15:20 2022 +0100 mtd: onenand: omap2: add dependency on GPMC [ Upstream commit c717b9b7d6de9e024e47f7cd5bbff49f581d3db9 ] OMAP2 OneNAND driver uses gpmc_omap_onenand_set_timings() provided by OMAP_GPMC driver, so the latter cannot be module if OneNAND driver is built-in: /usr/bin/arm-linux-gnueabi-ld: drivers/mtd/nand/onenand/onenand_omap2.o: in function `omap2_onenand_probe': onenand_omap2.c:(.text+0x520): undefined reference to `gpmc_omap_onenand_set_timings' The OMAP_GPMC is also a runtime dependency. Reported-by: kernel test robot Fixes: 854fd9209b20 ("memory: omap-gpmc: Allow building as a module") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Roger Quadros Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221107091520.127053-1-krzysztof.kozlowski@linaro.org Signed-off-by: Sasha Levin commit f4e5bdf1d26ce24962dc4d9c28059381c5fdd97e Author: Quentin Schulz Date: Tue Oct 18 14:17:23 2022 +0200 pinctrl: rockchip: list all pins in a possible mux route for PX30 [ Upstream commit bee55f2e7a44e7a7676e264b42f026e34bd244d9 ] The mux routes are incomplete for the PX30. This was discovered because we had a HW design using cif-clkoutm1 with the correct pinmux in the Device Tree but the clock would still not work. There are actually two muxing required: the pin muxing (performed by the usual Device Tree pinctrl nodes) and the "function" muxing (m0 vs m1; performed by the mux routing inside the driver). The pin muxing was correct but the function muxing was not. This adds the missing pins and their configuration for the mux routes that are already specified in the driver. Note that there are some "conflicts": it is possible *in Device Tree* to (attempt to) mux the pins for e.g. clkoutm1 and clkinm0 at the same time but this is actually not possible in hardware (because both share the same bit for the function muxing). Since it is an impossible hardware design, it is not deemed necessary to prevent the user from attempting to "misconfigure" the pins/functions. Fixes: 87065ca9b8e5 ("pinctrl: rockchip: Add pinctrl support for PX30") Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20221017-upstream-px30-cif-clkoutm1-v1-0-4ea1389237f7@theobroma-systems.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 8bb5f279bba370e62647568c2246404dd278bab7 Author: Chen Zhongjin Date: Mon Oct 31 21:40:31 2022 +0800 ASoC: soc-utils: Remove __exit for snd_soc_util_exit() [ Upstream commit 314d34fe7f0a5836cb0472950c1f17744b4efde8 ] snd_soc_util_exit() is called in __init snd_soc_init() for cleanup. Remove the __exit annotation for it to fix the build warning: WARNING: modpost: sound/soc/snd-soc-core.o: section mismatch in reference: init_module (section: .init.text) -> snd_soc_util_exit (section: .exit.text) Fixes: 6ec27c53886c ("ASoC: core: Fix use-after-free in snd_soc_exit()") Signed-off-by: Chen Zhongjin Link: https://lore.kernel.org/r/20221031134031.256511-1-chenzhongjin@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c19458760c444e0fc94752b70a45eec3e0ffedfb Author: Vikas Gupta Date: Thu Nov 3 19:33:25 2022 -0400 bnxt_en: fix the handling of PCIE-AER [ Upstream commit 0cf736a18a1e804037839bd8df9e36f0efdb8745 ] Fix the sequence required for PCIE-AER. While slot reset occurs, firmware might not be ready and the driver needs to check for its recovery. We also need to remap the health registers for some chips and clear the resource reservations. The resources will be allocated again during bnxt_io_resume(). Fixes: fb1e6e562b37 ("bnxt_en: Fix AER recovery.") Signed-off-by: Vikas Gupta Signed-off-by: Michael Chan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit f4a3a991f30c52fb810192f1f62b92600bd5806a Author: Vikas Gupta Date: Thu Nov 3 19:33:24 2022 -0400 bnxt_en: refactor bnxt_cancel_reservations() [ Upstream commit b4c66425771ddb910316c7b4cd7fa0614098ec45 ] Introduce bnxt_clear_reservations() to clear the reserved attributes only. This will be used in the next patch to fix PCI AER handling. Signed-off-by: Vikas Gupta Signed-off-by: Michael Chan Signed-off-by: Jakub Kicinski Stable-dep-of: 0cf736a18a1e ("bnxt_en: fix the handling of PCIE-AER") Signed-off-by: Sasha Levin commit 1b597f2d6a55e9f549989913860ad5170da04964 Author: Baisong Zhong Date: Wed Nov 2 16:16:20 2022 +0800 bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb() [ Upstream commit d3fd203f36d46aa29600a72d57a1b61af80e4a25 ] We got a syzkaller problem because of aarch64 alignment fault if KFENCE enabled. When the size from user bpf program is an odd number, like 399, 407, etc, it will cause the struct skb_shared_info's unaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381 To fix the problem, we adjust @size so that (@size + @hearoom) is a multiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_info is aligned to a cache line. Fixes: 1cf1cae963c2 ("bpf: introduce BPF_PROG_TEST_RUN command") Signed-off-by: Baisong Zhong Signed-off-by: Daniel Borkmann Cc: Eric Dumazet Link: https://lore.kernel.org/bpf/20221102081620.1465154-1-zhongbaisong@huawei.com Signed-off-by: Sasha Levin commit 6e7c2c869639eced7236fcb99840c2b83dbab8ec Author: Jason Montleon Date: Thu Nov 3 10:46:12 2022 -0400 ASoC: rt5677: fix legacy dai naming [ Upstream commit a1dca8774faf3f77eb34fa0ac6f3e2b82290b1e4 ] Starting with 6.0-rc1 the CPU DAI is not registered and the sound card is unavailable. Adding legacy_dai_naming causes it to function properly again. Fixes: fc34ece41f71 ("ASoC: Refactor non_legacy_dai_naming flag") Signed-off-by: Jason Montleon Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221103144612.4431-2-jmontleo@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9fdcd64b510ecce8230119ed94d3a16a1b0bf103 Author: Jason Montleon Date: Thu Nov 3 10:46:11 2022 -0400 ASoC: rt5514: fix legacy dai naming [ Upstream commit 392cc13c5ec72ccd6bbfb1bc2339502cc59dd285 ] Starting with 6.0-rc1 these messages are logged and the sound card is unavailable. Adding legacy_dai_naming to the rt5514-spi causes it to function properly again. [ 16.928454] kbl_r5514_5663_max kbl_r5514_5663_max: ASoC: CPU DAI spi-PRP0001:00 not registered [ 16.928561] platform kbl_r5514_5663_max: deferred probe pending Fixes: fc34ece41f71 ("ASoC: Refactor non_legacy_dai_naming flag") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216641 Signed-off-by: Jason Montleon Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221103144612.4431-1-jmontleo@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 280f6891ae1ac0b1ae857a5fd77aea5a4e2dcbdc Author: Duoming Zhou Date: Sun Oct 2 12:07:09 2022 +0800 tty: n_gsm: fix sleep-in-atomic-context bug in gsm_control_send [ Upstream commit 7b7dfe4833c70a11cdfa51b38705103bd31eddaa ] The function gsm_dlci_t1() is a timer handler that runs in an atomic context, but it calls "kzalloc(..., GFP_KERNEL)" that may sleep. As a result, the sleep-in-atomic-context bug will happen. The process is shown below: gsm_dlci_t1() gsm_dlci_open() gsm_modem_update() gsm_modem_upd_via_msc() gsm_control_send() kzalloc(sizeof(.., GFP_KERNEL) //may sleep This patch changes the gfp_t parameter of kzalloc() from GFP_KERNEL to GFP_ATOMIC in order to mitigate the bug. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Duoming Zhou Link: https://lore.kernel.org/r/20221002040709.27849-1-duoming@zju.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e3f9d87d6f0732827c443bd1474df21c2fad704b Author: Shawn Guo Date: Wed Oct 12 20:13:53 2022 +0800 serial: imx: Add missing .thaw_noirq hook [ Upstream commit 4561d8008a467cb05ac632a215391d6b787f40aa ] The following warning is seen with non-console UART instance when system hibernates. [ 37.371969] ------------[ cut here ]------------ [ 37.376599] uart3_root_clk already disabled [ 37.380810] WARNING: CPU: 0 PID: 296 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 ... [ 37.506986] Call trace: [ 37.509432] clk_core_disable+0xa4/0xb0 [ 37.513270] clk_disable+0x34/0x50 [ 37.516672] imx_uart_thaw+0x38/0x5c [ 37.520250] platform_pm_thaw+0x30/0x6c [ 37.524089] dpm_run_callback.constprop.0+0x3c/0xd4 [ 37.528972] device_resume+0x7c/0x160 [ 37.532633] dpm_resume+0xe8/0x230 [ 37.536036] hibernation_snapshot+0x288/0x430 [ 37.540397] hibernate+0x10c/0x2e0 [ 37.543798] state_store+0xc4/0xd0 [ 37.547203] kobj_attr_store+0x1c/0x30 [ 37.550953] sysfs_kf_write+0x48/0x60 [ 37.554619] kernfs_fop_write_iter+0x118/0x1ac [ 37.559063] new_sync_write+0xe8/0x184 [ 37.562812] vfs_write+0x230/0x290 [ 37.566214] ksys_write+0x68/0xf4 [ 37.569529] __arm64_sys_write+0x20/0x2c [ 37.573452] invoke_syscall.constprop.0+0x50/0xf0 [ 37.578156] do_el0_svc+0x11c/0x150 [ 37.581648] el0_svc+0x30/0x140 [ 37.584792] el0t_64_sync_handler+0xe8/0xf0 [ 37.588976] el0t_64_sync+0x1a0/0x1a4 [ 37.592639] ---[ end trace 56e22eec54676d75 ]--- On hibernating, pm core calls into related hooks in sequence like: .freeze .freeze_noirq .thaw_noirq .thaw With .thaw_noirq hook being absent, the clock will be disabled in a unbalanced call which results the warning above. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_thaw clk_disable_unprepare() Adding the missing .thaw_noirq hook as imx_uart_resume_noirq() will have the call sequence corrected as below and thus fix the warning. imx_uart_freeze() clk_prepare_enable() imx_uart_suspend_noirq() clk_disable() imx_uart_resume_noirq() clk_enable() imx_uart_thaw clk_disable_unprepare() Fixes: 09df0b3464e5 ("serial: imx: fix endless loop during suspend") Reviewed-by: Martin Kaiser Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20221012121353.2346280-1-shawn.guo@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 378f1cdfe681f86c61dee66c42166e9b0c832c26 Author: Sherry Sun Date: Mon Oct 24 16:58:44 2022 +0800 tty: serial: fsl_lpuart: don't break the on-going transfer when global reset [ Upstream commit 76bad3f88750f8cc465c489e6846249e0bc3d8f5 ] lpuart_global_reset() shouldn't break the on-going transmit engine, need to recover the on-going data transfer after reset. This can help earlycon here, since commit 60f361722ad2 ("serial: fsl_lpuart: Reset prior to registration") moved lpuart_global_reset() before uart_add_one_port(), earlycon is writing during global reset, as global reset will disable the TX and clear the baud rate register, which caused the earlycon cannot work any more after reset, needs to restore the baud rate and re-enable the transmitter to recover the earlycon write. Also move the lpuart_global_reset() down, then we can reuse the lpuart32_tx_empty() without declaration. Fixes: bd5305dcabbc ("tty: serial: fsl_lpuart: do software reset for imx7ulp and imx8qxp") Signed-off-by: Sherry Sun Link: https://lore.kernel.org/r/20221024085844.22786-1-sherry.sun@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 958da6d0d2b35f5536fbdd273b8935b9be7acfe0 Author: Tony Lindgren Date: Fri Oct 28 14:00:44 2022 +0300 serial: 8250: omap: Flush PM QOS work on remove [ Upstream commit d0b68629bd2fb61e0171a62f2e8da3db322f5cf6 ] Rebinding 8250_omap in a loop will at some point produce a warning for kernel/power/qos.c:296 cpu_latency_qos_update_request() with error "cpu_latency_qos_update_request called for unknown object". Let's flush the possibly pending PM QOS work scheduled from omap8250_runtime_suspend() before we disable runtime PM. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20221028110044.54719-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 02eed6390dbe61115f3e3f63829c95c611aee67b Author: Tony Lindgren Date: Fri Oct 28 13:58:13 2022 +0300 serial: 8250: omap: Fix unpaired pm_runtime_put_sync() in omap8250_remove() [ Upstream commit e3f0c638f428fd66b5871154b62706772045f91a ] On remove, we get an error for "Runtime PM usage count underflow!". I guess this driver is mostly built-in, and this issue has gone unnoticed for a while. Somehow I did not catch this issue with my earlier fix done with commit 4e0f5cc65098 ("serial: 8250_omap: Fix probe and remove for PM runtime"). Fixes: 4e0f5cc65098 ("serial: 8250_omap: Fix probe and remove for PM runtime") Signed-off-by: Tony Lindgren Depends-on: dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Link: https://lore.kernel.org/r/20221028105813.54290-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8a1b54e60fb09fdcded2907e864b02e6c958d5d0 Author: Matthias Schiffer Date: Thu Oct 13 13:23:39 2022 +0200 serial: 8250_omap: remove wait loop from Errata i202 workaround [ Upstream commit e828e56684d61b17317e0cfdef83791fa61cb76b ] We were occasionally seeing the "Errata i202: timedout" on an AM335x board when repeatedly opening and closing a UART connected to an active sender. As new input may arrive at any time, it is possible to miss the "RX FIFO empty" condition, forcing the loop to wait until it times out. Nothing in the i202 Advisory states that such a wait is even necessary; other FIFO clear functions like serial8250_clear_fifos() do not wait either. For this reason, it seems safe to remove the wait, fixing the mentioned issue. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Reviewed-by: Ilpo Järvinen Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/20221013112339.2540767-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6ce79c4dc48ff27b0ad61dc2f9b55dbd4ba86468 Author: Tony Lindgren Date: Mon Oct 24 09:36:13 2022 +0300 serial: 8250: omap: Fix missing PM runtime calls for omap8250_set_mctrl() [ Upstream commit 93810191f5d23652c0b8a1a9b3a4a89d6fd5063e ] There are cases where omap8250_set_mctrl() may get called after the UART has already autoidled causing an asynchronous external abort. This can happen on ttyport_open(): mem_serial_in from omap8250_set_mctrl+0x38/0xa0 omap8250_set_mctrl from uart_update_mctrl+0x4c/0x58 uart_update_mctrl from uart_dtr_rts+0x60/0xa8 uart_dtr_rts from tty_port_block_til_ready+0xd0/0x2a8 tty_port_block_til_ready from uart_open+0x14/0x1c uart_open from ttyport_open+0x64/0x148 And on ttyport_close(): omap8250_set_mctrl from uart_update_mctrl+0x3c/0x48 uart_update_mctrl from uart_dtr_rts+0x54/0x9c uart_dtr_rts from tty_port_shutdown+0x78/0x9c tty_port_shutdown from tty_port_close+0x3c/0x74 tty_port_close from ttyport_close+0x40/0x58 It can also happen on disassociate_ctty() calling uart_shutdown() that ends up calling omap8250_set_mctrl(). Let's fix the issue by adding missing PM runtime calls to omap8250_set_mctrl(). To do this, we need to add __omap8250_set_mctrl() that can be called from both omap8250_set_mctrl(), and from runtime PM resume path when restoring the registers. Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Reported-by: Merlijn Wajer Reported-by: Romain Naour Reported-by: Ivaylo Dimitrov Tested-by: Ivaylo Dimitrov Signed-off-by: Tony Lindgren Depends-on: dd8088d5a896 ("PM: runtime: Add pm_runtime_resume_and_get to deal with usage counter") Link: https://lore.kernel.org/r/20221024063613.25943-1-tony@atomide.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fff8890cbacb8ebb1e3aedb1683eca5bf0543b87 Author: Claudiu Beznea Date: Wed Oct 26 15:41:04 2022 +0300 ARM: at91: pm: avoid soft resetting AC DLL [ Upstream commit cef8cdc0d0e7c701fe4dcfba4ed3fd25d28a6020 ] Do not soft reset AC DLL as controller is buggy and this operation my introduce glitches in the controller leading to undefined behavior. Fixes: f0bbf17958e8 ("ARM: at91: pm: add self-refresh support for sama7g5") Depends-on: a02875c4cbd6 ("ARM: at91: pm: fix self-refresh for sama7g5") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20221026124114.985876-2-claudiu.beznea@microchip.com Signed-off-by: Sasha Levin commit e183378ddd6f0192382f4e3fc135bdeda68edf0a Author: Martin Povišer Date: Thu Oct 27 11:58:00 2022 +0200 ASoC: tas2780: Fix set_tdm_slot in case of single slot [ Upstream commit 6f934afa6a980bb8d3ce73836b1a9922685e50d7 ] There's a special branch in the set_tdm_slot op for the case of nslots being 1, but: (1) That branch can never work (there's a check for tx_mask being non-zero, later there's another check for it *being* zero; one or the other always throws -EINVAL). (2) The intention of the branch seems to be what the general other branch reduces to in case of nslots being 1. For those reasons remove the 'nslots being 1' special case. Fixes: eae9f9ce181b ("ASoC: add tas2780 driver") Suggested-by: Jos Dehaes Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20221027095800.16094-3-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4dc105d299fd3b339be843ead83e49c80f507f09 Author: Martin Povišer Date: Thu Oct 27 11:57:59 2022 +0200 ASoC: tas2764: Fix set_tdm_slot in case of single slot [ Upstream commit faac764ea1ea6898d93e46c403271fb105c0906e ] There's a special branch in the set_tdm_slot op for the case of nslots being 1, but: (1) That branch can never work (there's a check for tx_mask being non-zero, later there's another check for it *being* zero; one or the other always throws -EINVAL). (2) The intention of the branch seems to be what the general other branch reduces to in case of nslots being 1. For those reasons remove the 'nslots being 1' special case. Fixes: 827ed8a0fa50 ("ASoC: tas2764: Add the driver for the TAS2764") Suggested-by: Jos Dehaes Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20221027095800.16094-2-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7b7d4df38cb6de3e9112a00e89efa8fa2b21c9b7 Author: Martin Povišer Date: Thu Oct 27 11:57:58 2022 +0200 ASoC: tas2770: Fix set_tdm_slot in case of single slot [ Upstream commit e59bf547a7dd366f93bfebb7487959580ca6c0ec ] There's a special branch in the set_tdm_slot op for the case of nslots being 1, but: (1) That branch can never work (there's a check for tx_mask being non-zero, later there's another check for it *being* zero; one or the other always throws -EINVAL). (2) The intention of the branch seems to be what the general other branch reduces to in case of nslots being 1. For those reasons remove the 'nslots being 1' special case. Fixes: 1a476abc723e ("tas2770: add tas2770 smart PA kernel driver") Suggested-by: Jos Dehaes Signed-off-by: Martin Povišer Link: https://lore.kernel.org/r/20221027095800.16094-1-povik+lin@cutebit.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 34d4379b6f8064065a0057b57f7f245a94125f69 Author: Ulf Hansson Date: Thu Oct 27 13:57:45 2022 +0200 arm64: dts: qcom: sm8250: Disable the not yet supported cluster idle state [ Upstream commit cadaa773bcf161184fa428180516bae33a7bc667 ] To support the deeper cluster idle state for sm8250 platforms, some additional synchronization is needed between the rpmh-rsc device and the CPU cluster PM domain. Until that is supported, let's disable the cluster idle state. This fixes a problem that has been reported for the Qcom RB5 platform (see below), but most likely other sm8250 platforms suffers from similar issues, so let's make the fix generic for sm8250. vreg_l11c_3p3: failed to enable: -ETIMEDOUT qcom-rpmh-regulator 18200000.rsc:pm8150l-rpmh-regulators: ldo11: devm_regulator_register() failed, ret=-110 qcom-rpmh-regulator: probe of 18200000.rsc:pm8150l-rpmh-regulators failed with error -110 Reported-by: Amit Pundir Fixes: 32bc936d7321 ("arm64: dts: qcom: sm8250: Add cpuidle states") Signed-off-by: Ulf Hansson Tested-by: Amit Pundir Reviewed-by: Sudeep Holla Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221027115745.240516-1-ulf.hansson@linaro.org Signed-off-by: Sasha Levin commit 9c9e91e75b3318d086819accb24c167dd4256ce0 Author: Maarten Zanders Date: Fri Oct 28 16:11:28 2022 +0200 ASoC: fsl_asrc fsl_esai fsl_sai: allow CONFIG_PM=N [ Upstream commit 6a564338a23cefcfc29c4a535b98402d13efdda6 ] When CONFIG_PM=N, pm_runtime_put_sync() returns -ENOSYS which breaks the probe function of these drivers. Other users of pm_runtime_put_sync() typically don't check the return value. In order to keep the program flow as intended, check for -ENOSYS. This commit is similar to commit 0434d3f (omap-mailbox.c). Fixes: cab04ab5900f ("ASoC: fsl_asrc: Don't use devm_regmap_init_mmio_clk") Fixes: 203773e39347 ("ASoC: fsl_esai: Don't use devm_regmap_init_mmio_clk") Fixes: 2277e7e36b4b ("ASoC: fsl_sai: Don't use devm_regmap_init_mmio_clk") Signed-off-by: Maarten Zanders Reviewed-by: Daniel Baluta Link: https://lore.kernel.org/r/20221028141129.100702-1-maarten.zanders@mind.be Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c5674bd073c0fd9f620ca550c5ff08d0d429bdd9 Author: Chen Zhongjin Date: Fri Oct 28 11:16:03 2022 +0800 ASoC: core: Fix use-after-free in snd_soc_exit() [ Upstream commit 6ec27c53886c8963729885bcf2dd996eba2767a7 ] KASAN reports a use-after-free: BUG: KASAN: use-after-free in device_del+0xb5b/0xc60 Read of size 8 at addr ffff888008655050 by task rmmod/387 CPU: 2 PID: 387 Comm: rmmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: dump_stack_lvl+0x79/0x9a print_report+0x17f/0x47b kasan_report+0xbb/0xf0 device_del+0xb5b/0xc60 platform_device_del.part.0+0x24/0x200 platform_device_unregister+0x2e/0x40 snd_soc_exit+0xa/0x22 [snd_soc_core] __do_sys_delete_module.constprop.0+0x34f/0x5b0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... It's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail, but its ret is ignored, which makes soc_dummy_dev unregistered twice. snd_soc_init() snd_soc_util_init() platform_device_register_simple(soc_dummy_dev) platform_driver_register() # fail platform_device_unregister(soc_dummy_dev) platform_driver_register() # success ... snd_soc_exit() snd_soc_util_exit() # soc_dummy_dev will be unregistered for second time To fix it, handle error and stop snd_soc_init() when util_init() fail. Also clean debugfs when util_init() or driver_register() fail. Fixes: fb257897bf20 ("ASoC: Work around allmodconfig failure") Signed-off-by: Chen Zhongjin Link: https://lore.kernel.org/r/20221028031603.59416-1-chenzhongjin@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8f484d2f4f610269618ac19d55fc366ef1d03f06 Author: Mihai Sain Date: Mon Oct 17 11:31:19 2022 +0300 ARM: dts: at91: sama7g5: fix signal name of pin PB2 [ Upstream commit 2b4337c8409b4e9e5aed15c597e4031dd567bdd8 ] The signal name of pin PB2 with function F is FLEXCOM11_IO1 as it is defined in the datasheet. Fixes: 7540629e2fc7 ("ARM: dts: at91: add sama7g5 SoC DT and sama7g5-ek") Signed-off-by: Mihai Sain Reviewed-by: Tudor Ambarus Acked-by: Nicolas Ferre Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20221017083119.1643-1-mihai.sain@microchip.com Signed-off-by: Sasha Levin commit 0efb4f33355bbe4b16b8359774c04e3057755550 Author: Marek Vasut Date: Tue Oct 18 20:35:13 2022 +0200 spi: stm32: Print summary 'callbacks suppressed' message [ Upstream commit 195583504be28df5d608a4677dd796117aea875f ] The original fix "spi: stm32: Rate-limit the 'Communication suspended' message" still leads to "stm32h7_spi_irq_thread: 1696 callbacks suppressed" spew in the kernel log. Since this 'Communication suspended' message is a debug print, add RATELIMIT_MSG_ON_RELEASE flag to inhibit the "callbacks suspended" part during normal operation and only print summary at the end. Fixes: ea8be08cc9358 ("spi: stm32: Rate-limit the 'Communication suspended' message") Signed-off-by: Marek Vasut Link: https://lore.kernel.org/r/20221018183513.206706-1-marex@denx.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8df6b85e4d3e7e532ebf6034df12641dade1a903 Author: Satya Priya Date: Tue Sep 20 17:18:15 2022 +0530 arm64: dts: qcom: sc7280: Add the reset reg for lpass audiocc on SC7280 [ Upstream commit cb1d0aaa674e99957b85af570cb2730145af01df ] Add the reset register offset for clock gating. Fixes: 9499240d15f2 ("arm64: dts: qcom: sc7280: Add lpasscore & lpassaudio clock controllers") Signed-off-by: Satya Priya Reviewed-by: Neil Armstrong Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1663674495-25748-1-git-send-email-quic_c_skakit@quicinc.com Signed-off-by: Sasha Levin commit ece2549c7f172e4bf7ac6f351e6832530365e01a Author: Johan Hovold Date: Thu Sep 15 16:16:01 2022 +0200 arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size [ Upstream commit 8703d55bd5eac642275fe91b34ac62ad0ad312b5 ] The size of the UFS PHY serdes register region is 0x1c8 and the corresponding 'reg' property should specifically not include the adjacent regions that are defined in the child node (e.g. tx and rx). Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Johan Hovold Tested-by: Andrew Halaney #Qdrive3/sa8540p-adp-ride Reviewed-by: Brian Masney Reviewed-by: Bjorn Andersson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220915141601.18435-1-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 1327e5cdce9e87d488274b9cc52be561f8099f34 Author: Johan Hovold Date: Mon Sep 19 11:44:54 2022 +0200 arm64: dts: qcom: sc8280xp: drop broken DP PHY nodes [ Upstream commit 7cdfb7a54ac88f7cb6d830ebb78bdbcbcb44bb4c ] The DP PHY register layout of the current binding do not apply to the newer USB4/USB3/DP PHY which uses a different register layout entirely. Drop the DP PHY subnodes until the binding has been updated to prevent the driver from corrupting unrelated registers. Note that this is also needed in order to not break USB with an upcoming PHY driver change that checks for overlapping register regions. Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220919094454.1574-5-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 7b6ddc227a7b4bbd1c8eb0ed6c24b729fc28f250 Author: Johan Hovold Date: Mon Sep 19 11:44:53 2022 +0200 arm64: dts: qcom: sc8280xp: fix USB PHY PCS registers [ Upstream commit 8723c3f290c7b798c0cbd89998576e6b365bda3a ] With the current binding, the PCS register block (0x1400) needs to include the PCS_USB registers (0x1700). Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220919094454.1574-4-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit cb4604eaca0c8dd4f5575f6bdeeec5fe7d18766f Author: Johan Hovold Date: Mon Sep 19 11:44:52 2022 +0200 arm64: dts: qcom: sc8280xp: fix USB1 PHY RX1 registers [ Upstream commit 81cad26c6c3984d01b0612069c70ffd820f62dfa ] The USB1 SS PHY node had the RX1 register block (0x600) replaced with RX2 (0xc00). Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220919094454.1574-3-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 8ed495ea8ed39aa78c8ef0e30aec31dc362e108e Author: Johan Hovold Date: Mon Sep 19 11:44:51 2022 +0200 arm64: dts: qcom: sc8280xp: fix USB0 PHY PCS_MISC registers [ Upstream commit 31b3b3059791be536e2ec0c6830767b596af340f ] The USB0 SS PHY node had the PCS_MISC register block (0x1200) replaced with PCS_USB (0x1700). Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220919094454.1574-2-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 7c365a49a9b85586b26e5fec5a45034cf440506e Author: Brian Masney Date: Thu Oct 6 10:55:29 2022 -0400 arm64: dts: qcom: sc8280xp: correct ref clock for ufs_mem_phy [ Upstream commit f3aa975e230e060c07dcfdf3fe92b59809422c13 ] The first UFS host controller fails to start on the SA8540P automotive board (QDrive3) due to the following errors: ufshcd-qcom 1d84000.ufs: ufshcd_query_flag: Sending flag query for idn 18 failed, err = 253 ufshcd-qcom 1d84000.ufs: ufshcd_query_flag: Sending flag query for idn 18 failed, err = 253 ufshcd-qcom 1d84000.ufs: ufshcd_query_flag: Sending flag query for idn 18 failed, err = 253 ufshcd-qcom 1d84000.ufs: ufshcd_query_flag_retry: query attribute, opcode 5, idn 18, failed with error 253 after 3 retries The system eventually fails to boot with the warning: gcc_ufs_phy_axi_clk status stuck at 'off' This issue can be worked around by adding clk_ignore_unused to the kernel command line since the system firmware sets up this clock for us. Let's fix this issue by updating the ref clock on ufs_mem_phy. Note that the downstream MSM 5.4 sources list this as ref_clk_parent. With this patch, the SA8540P is able to be booted without clk_ignore_unused. Signed-off-by: Brian Masney Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Tested-by: Johan Hovold Reviewed-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221006145529.755521-1-bmasney@redhat.com Signed-off-by: Sasha Levin commit 90ea36b39ac48e8bda51c55d99c412445d48d3d9 Author: Johan Hovold Date: Wed Oct 5 16:33:05 2022 +0200 arm64: dts: qcom: sc8280xp: fix ufs_card_phy ref clock [ Upstream commit 8d6b458ce6e93286a607e54f787f7a86067f58bd ] The GCC_UFS_REF_CLKREF_CLK must be enabled or the second UFS controller fails to enumerate on sa8295p-adp. Note that the vendor kernel enables both GCC_UFS_REF_CLKREF_CLK and GCC_UFS_1_CARD_CLKREF_CLK and it is possible that the former should be modelled as a parent of the latter. The clock driver also has a GCC_UFS_CARD_CLKREF_CLK clock which the firmware appears to enable on the ADP. The usual lack of documentation for Qualcomm SoCs makes this a highly annoying guessing game, but as the second controller works on the ADP without either card reference clock enabled, only enable GCC_UFS_REF_CLKREF_CLK for now. Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform") Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Reviewed-by: Brian Masney Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20221005143305.388-1-johan+linaro@kernel.org Signed-off-by: Sasha Levin commit 6e3e49a4371303eb6a7839a1b51e7e8072598c05 Author: Douglas Anderson Date: Mon Aug 29 09:49:52 2022 -0700 arm64: dts: qcom: sm8350-hdk: Specify which LDO modes are allowed [ Upstream commit 1ce8aaf6abdc35cde555924418b3d4516b4ec871 ] This board uses RPMH, specifies "regulator-allow-set-load" for LDOs, but doesn't specify any modes with "regulator-allowed-modes". Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") the above meant that we were able to set either LPM or HPM mode. After that commit (and fixes [1]) we'll be stuck at the initial mode. Discussion of this has resulted in the decision that the old dts files were wrong and should be fixed to fully restore old functionality. Let's re-enable the old functionality by fixing the dts. [1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Fixes: 9208c19f2124 ("arm64: dts: qcom: Introduce SM8350 HDK") Signed-off-by: Douglas Anderson Reviewed-by: Andrew Halaney Reviewed-by: Vinod Koul Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220829094903.v2.6.I6799be85cf36d3b494f803cba767a569080624f5@changeid Signed-off-by: Sasha Levin commit b7addcb7e61569ee7d12c0aa8cf7d248298e3cfe Author: Douglas Anderson Date: Mon Aug 29 09:49:51 2022 -0700 arm64: dts: qcom: sm8250-xperia-edo: Specify which LDO modes are allowed [ Upstream commit b7870d460c05ce31e2311036d91de1e2e0b32cea ] This board uses RPMH, specifies "regulator-allow-set-load" for LDOs, but doesn't specify any modes with "regulator-allowed-modes". Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") the above meant that we were able to set either LPM or HPM mode. After that commit (and fixes [1]) we'll be stuck at the initial mode. Discussion of this has resulted in the decision that the old dts files were wrong and should be fixed to fully restore old functionality. Let's re-enable the old functionality by fixing the dts. [1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Fixes: 69cdb97ef652 ("arm64: dts: qcom: sm8250: Add support for SONY Xperia 1 II / 5 II (Edo platform)") Signed-off-by: Douglas Anderson Reviewed-by: Andrew Halaney Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220829094903.v2.5.Ie446d5183d8b1e9ec4e32228ca300e604e3315eb@changeid Signed-off-by: Sasha Levin commit c9c4184b93cc6af1225c880835db6a353e0c26f0 Author: Douglas Anderson Date: Mon Aug 29 09:49:50 2022 -0700 arm64: dts: qcom: sm8150-xperia-kumano: Specify which LDO modes are allowed [ Upstream commit aa30e786202e4ed1df980442d305658441f65859 ] This board uses RPMH, specifies "regulator-allow-set-load" for LDOs, but doesn't specify any modes with "regulator-allowed-modes". Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") the above meant that we were able to set either LPM or HPM mode. After that commit (and fixes [1]) we'll be stuck at the initial mode. Discussion of this has resulted in the decision that the old dts files were wrong and should be fixed to fully restore old functionality. Let's re-enable the old functionality by fixing the dts. [1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Fixes: d0a6ce59ea4e ("arm64: dts: qcom: sm8150: Add support for SONY Xperia 1 / 5 (Kumano platform)") Signed-off-by: Douglas Anderson Reviewed-by: Andrew Halaney Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220829094903.v2.4.I51d60414a42ba9e3008e208d60a04c9ffc425fa7@changeid Signed-off-by: Sasha Levin commit d39ad5983c39ad111a94a4645164bcad918ac5a2 Author: Douglas Anderson Date: Mon Aug 29 09:49:49 2022 -0700 arm64: dts: qcom: sc8280xp-crd: Specify which LDO modes are allowed [ Upstream commit a4543e21ae363f4f094fb3c3503d77029e0c5d90 ] This board uses RPMH, specifies "regulator-allow-set-load" for LDOs, but doesn't specify any modes with "regulator-allowed-modes". Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") the above meant that we were able to set either LPM or HPM mode. After that commit (and fixes [1]) we'll be stuck at the initial mode. Discussion of this has resulted in the decision that the old dts files were wrong and should be fixed to fully restore old functionality. Let's re-enable the old functionality by fixing the dts. [1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Fixes: ccd3517faf18 ("arm64: dts: qcom: sc8280xp: Add reference device") Signed-off-by: Douglas Anderson Reviewed-by: Andrew Halaney Reviewed-by: Konrad Dybcio Reviewed-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220829094903.v2.3.Ie7d2c50d2b42ef2d364f3a0c8e300e5ce1875b79@changeid Signed-off-by: Sasha Levin commit 87a876d45084d605ca5891ac48861fed9f8db1e3 Author: Douglas Anderson Date: Mon Aug 29 09:49:48 2022 -0700 arm64: dts: qcom: sa8295p-adp: Specify which LDO modes are allowed [ Upstream commit 09a1710b3e12e7ac8d871506bc395a9e8a0f63d6 ] This board uses RPMH, specifies "regulator-allow-set-load" for LDOs, but doesn't specify any modes with "regulator-allowed-modes". Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") the above meant that we were able to set either LPM or HPM mode. After that commit (and fixes [1]) we'll be stuck at the initial mode. Discussion of this has resulted in the decision that the old dts files were wrong and should be fixed to fully restore old functionality. Let's re-enable the old functionality by fixing the dts. [1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Fixes: 519183af39b2 ("arm64: dts: qcom: add SA8540P and ADP") Signed-off-by: Douglas Anderson Reviewed-by: Andrew Halaney Reviewed-by: Konrad Dybcio Reviewed-by: Johan Hovold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220829094903.v2.2.I430a56702ab0af65244e62667bb7743107de0c96@changeid Signed-off-by: Sasha Levin commit 8bfe608d788d909a75822305c83f6d722cb9188b Author: Douglas Anderson Date: Mon Aug 29 09:49:47 2022 -0700 arm64: dts: qcom: sa8155p-adp: Specify which LDO modes are allowed [ Upstream commit bd9f3dcf42d943b53190f99bcdbcfe98a56ac4cd ] This board uses RPMH, specifies "regulator-allow-set-load" for LDOs, but doesn't specify any modes with "regulator-allowed-modes". Prior to commit efb0cb50c427 ("regulator: qcom-rpmh: Implement get_optimum_mode(), not set_load()") the above meant that we were able to set either LPM or HPM mode. After that commit (and fixes [1]) we'll be stuck at the initial mode. Discussion of this has resulted in the decision that the old dts files were wrong and should be fixed to fully restore old functionality. Let's re-enable the old functionality by fixing the dts. NOTE: while here, let's also remove the nonsensical "regulator-allow-set-load" on the fixed regulator "vreg_s4a_1p8". [1] https://lore.kernel.org/r/20220824142229.RFT.v2.2.I6f77860e5cd98bf5c67208fa9edda4a08847c304@changeid Fixes: 5b85e8f2225c ("arm64: dts: qcom: sa8155p-adp: Add base dts file") Signed-off-by: Douglas Anderson Reviewed-by: Andrew Halaney Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220829094903.v2.1.Id59c32b560c4662d8b3697de2bd494d08d654806@changeid Signed-off-by: Sasha Levin commit b8e07355dcdc970e95474f2d16e0f6a31f45a83f Author: Robert Marko Date: Fri Aug 19 00:06:27 2022 +0200 arm64: dts: qcom: ipq8074: correct APCS register space size [ Upstream commit 40b21d466a86bd5b10d24f59746ed41283a9b3f6 ] APCS DTS addition that was merged, was not supposed to get merged as it was part of patch series that was superseded by 2 more patch series that resolved issues with this one and greatly simplified things. Since it already got merged, start by correcting the register space size as APCS will not be providing regmap for PLL and it will conflict with the standalone A53 PLL node. Fixes: 50ed9fffec3a ("arm64: dts: qcom: ipq8074: add APCS node") Signed-off-by: Robert Marko Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220818220628.339366-8-robimarko@gmail.com Signed-off-by: Sasha Levin commit b6380fc1d264c2a9f22d0a09fdf624a7fb2be366 Author: Paolo Bonzini Date: Fri Sep 30 14:24:40 2022 -0400 KVM: SVM: move MSR_IA32_SPEC_CTRL save/restore to assembly [ Upstream commit 9f2febf3f04daebdaaa5a43cfa20e3844905c0f9 ] Restoration of the host IA32_SPEC_CTRL value is probably too late with respect to the return thunk training sequence. With respect to the user/kernel boundary, AMD says, "If software chooses to toggle STIBP (e.g., set STIBP on kernel entry, and clear it on kernel exit), software should set STIBP to 1 before executing the return thunk training sequence." I assume the same requirements apply to the guest/host boundary. The return thunk training sequence is in vmenter.S, quite close to the VM-exit. On hosts without V_SPEC_CTRL, however, the host's IA32_SPEC_CTRL value is not restored until much later. To avoid this, move the restoration of host SPEC_CTRL to assembly and, for consistency, move the restoration of the guest SPEC_CTRL as well. This is not particularly difficult, apart from some care to cover both 32- and 64-bit, and to share code between SEV-ES and normal vmentry. Cc: stable@vger.kernel.org Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk") Suggested-by: Jim Mattson Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 54da20433d135c45d0362e543d29b33d72cda38f Author: Paolo Bonzini Date: Mon Nov 7 03:49:59 2022 -0500 KVM: SVM: restore host save area from assembly [ Upstream commit e287bd005ad9d85dd6271dd795d3ecfb6bca46ad ] Allow access to the percpu area via the GS segment base, which is needed in order to access the saved host spec_ctrl value. In linux-next FILL_RETURN_BUFFER also needs to access percpu data. For simplicity, the physical address of the save area is added to struct svm_cpu_data. Cc: stable@vger.kernel.org Fixes: a149180fbcf3 ("x86: Add magic AMD return-thunk") Reported-by: Nathan Chancellor Analyzed-by: Andrew Cooper Tested-by: Nathan Chancellor Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit d7be22f068d7b5f3742e12248ad61a643925daae Author: Paolo Bonzini Date: Wed Nov 9 09:07:55 2022 -0500 KVM: SVM: do not allocate struct svm_cpu_data dynamically [ Upstream commit 73412dfeea724e6bd775ba64d21157ff322eac9a ] The svm_data percpu variable is a pointer, but it is allocated via svm_hardware_setup() when KVM is loaded. Unlike hardware_enable() this means that it is never NULL for the whole lifetime of KVM, and static allocation does not waste any memory compared to the status quo. It is also more efficient and more easily handled from assembly code, so do it and don't look back. Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Stable-dep-of: e287bd005ad9 ("KVM: SVM: restore host save area from assembly") Signed-off-by: Sasha Levin commit 76edc1d07b41c8e2f9797320bac3504b9bb3544a Author: Paolo Bonzini Date: Wed Nov 9 08:54:20 2022 -0500 KVM: SVM: remove dead field from struct svm_cpu_data [ Upstream commit 181d0fb0bb023e8996b1cf7970e3708d72442b0b ] The "cpu" field of struct svm_cpu_data has been write-only since commit 4b656b120249 ("KVM: SVM: force new asid on vcpu migration", 2009-08-05). Remove it. Reviewed-by: Sean Christopherson Signed-off-by: Paolo Bonzini Stable-dep-of: e287bd005ad9 ("KVM: SVM: restore host save area from assembly") Signed-off-by: Sasha Levin commit ec667443b2dbc6cdbbac4073e51a17733158ec6a Author: James Houghton Date: Tue Oct 18 20:01:25 2022 +0000 hugetlbfs: don't delete error page from pagecache [ Upstream commit 8625147cafaa9ba74713d682f5185eb62cb2aedb ] This change is very similar to the change that was made for shmem [1], and it solves the same problem but for HugeTLBFS instead. Currently, when poison is found in a HugeTLB page, the page is removed from the page cache. That means that attempting to map or read that hugepage in the future will result in a new hugepage being allocated instead of notifying the user that the page was poisoned. As [1] states, this is effectively memory corruption. The fix is to leave the page in the page cache. If the user attempts to use a poisoned HugeTLB page with a syscall, the syscall will fail with EIO, the same error code that shmem uses. For attempts to map the page, the thread will get a BUS_MCEERR_AR SIGBUS. [1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens") Link: https://lkml.kernel.org/r/20221018200125.848471-1-jthoughton@google.com Signed-off-by: James Houghton Reviewed-by: Mike Kravetz Reviewed-by: Naoya Horiguchi Tested-by: Naoya Horiguchi Reviewed-by: Yang Shi Cc: Axel Rasmussen Cc: James Houghton Cc: Miaohe Lin Cc: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin commit cf5bf29e9e8bb34e97e089ef4abb519f3fecbaf3 Author: Mike Kravetz Date: Wed Sep 14 15:18:04 2022 -0700 hugetlb: rename remove_huge_page to hugetlb_delete_from_page_cache [ Upstream commit 7e1813d48dd30e6c6f235f6661d1bc108fcab528 ] remove_huge_page removes a hugetlb page from the page cache. Change to hugetlb_delete_from_page_cache as it is a more descriptive name. huge_add_to_page_cache is global in scope, but only deals with hugetlb pages. For consistency and clarity, rename to hugetlb_add_to_page_cache. Link: https://lkml.kernel.org/r/20220914221810.95771-4-mike.kravetz@oracle.com Signed-off-by: Mike Kravetz Reviewed-by: Miaohe Lin Cc: Andrea Arcangeli Cc: "Aneesh Kumar K.V" Cc: Axel Rasmussen Cc: David Hildenbrand Cc: Davidlohr Bueso Cc: James Houghton Cc: "Kirill A. Shutemov" Cc: Michal Hocko Cc: Mina Almasry Cc: Muchun Song Cc: Naoya Horiguchi Cc: Pasha Tatashin Cc: Peter Xu Cc: Prakash Sangappa Cc: Sven Schnelle Signed-off-by: Andrew Morton Stable-dep-of: 8625147cafaa ("hugetlbfs: don't delete error page from pagecache") Signed-off-by: Sasha Levin commit e8171abd002821dbd0010796e56c651040a416b3 Author: Ard Biesheuvel Date: Thu Nov 3 18:00:15 2022 +0100 arm64: fix rodata=full again [ Upstream commit 2081b3bd0c11757725dcab9ba5d38e1bddb03459 ] Commit 2e8cff0a0eee87b2 ("arm64: fix rodata=full") addressed a couple of issues with the rodata= kernel command line option, which is not a simple boolean on arm64, and inadvertently got broken due to changes in the generic bool handling. Unfortunately, the resulting code never clears the rodata_full boolean variable if it defaults to true and rodata=on or rodata=off is passed, as the generic code is not aware of the existence of this variable. Given the way this code is plumbed together, clearing rodata_full when returning false from arch_parse_debug_rodata() may result in inconsistencies if the generic code decides that it cannot parse the right hand side, so the best way to deal with this is to only take rodata_full in account if rodata_enabled is also true. Fixes: 2e8cff0a0eee ("arm64: fix rodata=full") Cc: # 6.0.x Signed-off-by: Ard Biesheuvel Acked-by: Will Deacon Link: https://lore.kernel.org/r/20221103170015.4124426-1-ardb@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit e81e0d3f284799ff405b9415429a131546b1f9e8 Author: Mike Rapoport Date: Wed Sep 21 10:48:41 2022 +0300 arm64/mm: fold check for KFENCE into can_set_direct_map() [ Upstream commit b9dd04a20f81333e4b99662f1bbaf7c9e3a1e137 ] KFENCE requires linear map to be mapped at page granularity, so that it is possible to protect/unprotect single pages, just like with rodata_full and DEBUG_PAGEALLOC. Instead of repating can_set_direct_map() || IS_ENABLED(CONFIG_KFENCE) make can_set_direct_map() handle the KFENCE case. This also prevents potential false positives in kernel_page_present() that may return true for non-present page if CONFIG_KFENCE is enabled. Signed-off-by: Mike Rapoport Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20220921074841.382615-1-rppt@kernel.org Signed-off-by: Catalin Marinas Stable-dep-of: 2081b3bd0c11 ("arm64: fix rodata=full again") Signed-off-by: Sasha Levin commit e320df4534214b282d9bbf07b7f188c8b009ac81 Author: Colin Ian King Date: Wed Oct 19 08:16:39 2022 +0100 ASoC: codecs: jz4725b: Fix spelling mistake "Sourc" -> "Source", "Routee" -> "Route" [ Upstream commit df496157a5afa1b6d1f4c46ad6549c2c346d1e59 ] There are two spelling mistakes in codec routing description. Fix it. Signed-off-by: Colin Ian King Reviewed-by: Philippe Mathieu-Daudé Acked-by: Paul Cercueil Link: https://lore.kernel.org/r/20221019071639.1003730-1-colin.i.king@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 35aab6f5244cc57c154ca807538d1c7c1bb7a00d Author: Shyam Prasad N Date: Fri Oct 28 09:52:26 2022 +0000 cifs: always iterate smb sessions using primary channel [ Upstream commit 8abcaeaed38109e5ccaf40218e0e9e387f07bfe6 ] smb sessions and tcons currently hang off primary channel only. Secondary channels have the lists as empty. Whenever there's a need to iterate sessions or tcons, we should use the list in the corresponding primary channel. Signed-off-by: Shyam Prasad N Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7d73714c68d39a45d9dbcc1a6c0e992402464177 Author: Dan Williams Date: Thu Nov 3 17:30:42 2022 -0700 tools/testing/cxl: Fix some error exits [ Upstream commit 86e86c3cb63325c12ea99fbce2cc5bafba86bb40 ] Fix a few typos where 'goto err_port' was used rather than the object specific cleanup. Reviewed-by: Dave Jiang Reviewed-by: Vishal Verma Link: https://lore.kernel.org/r/166752184255.947915.16163477849330181425.stgit@dwillia2-xfh.jf.intel.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 2fbc8db6f3c474ddf2dfeb0aa208becce7c9b5b9 Author: Tony Luck Date: Thu Nov 3 13:33:10 2022 -0700 x86/cpu: Add several Intel server CPU model numbers [ Upstream commit 7beade0dd41d42d797ccb7791b134a77fcebf35b ] These servers are all on the public versions of the roadmap. The model numbers for Grand Ridge, Granite Rapids, and Sierra Forest were included in the September 2022 edition of the Instruction Set Extensions document. Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Acked-by: Dave Hansen Link: https://lore.kernel.org/r/20221103203310.5058-1-tony.luck@intel.com Signed-off-by: Sasha Levin commit cc63ae7549c17dff976e08b4f8773e5bc1d1ea07 Author: Yu Zhe Date: Tue Sep 27 15:02:47 2022 +0800 cxl/pmem: Use size_add() against integer overflow [ Upstream commit 4f1aa35f1fb7d51b125487c835982af792697ecb ] "struct_size() + n" may cause a integer overflow, use size_add() to handle it. Signed-off-by: Yu Zhe Link: https://lore.kernel.org/r/20220927070247.23148-1-yuzhe@nfschina.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit b15e525ed1cffd7685816677f01ecb11b2f7ac8b Author: Luiz Augusto von Dentz Date: Mon Oct 31 16:10:33 2022 -0700 Bluetooth: L2CAP: Fix l2cap_global_chan_by_psm [ Upstream commit f937b758a188d6fd328a81367087eddbb2fce50f ] l2cap_global_chan_by_psm shall not return fixed channels as they are not meant to be connected by (S)PSM. Signed-off-by: Luiz Augusto von Dentz Reviewed-by: Tedd Ho-Jeong An Signed-off-by: Sasha Levin commit 2df27ec21bd698e770dd3734bb31f37065de2c45 Author: Nevenko Stupar Date: Fri May 6 16:32:38 2022 -0400 drm/amd/display: Investigate tool reported FCLK P-state deviations [ Upstream commit 7461016c5706eb8c477752bf69e5c9f5a38f502b ] [Why] Fix for some of the tool reported modes for FCLK P-state deviations and UCLK P-state deviations that are coming from DSC terms and/or Scaling terms causing MinActiveFCLKChangeLatencySupported and MaxActiveDRAMClockChangeLatencySupported incorrectly calculated in DML for these configurations. Reviewed-by: Chaitanya Dhere Acked-by: Jasdeep Dhillon Acked-by: Alex Hung Signed-off-by: Nevenko Stupar Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ba3ff4fe5dc4f1eaefbf9ff9379fb8a2012acb1c Author: George Shen Date: Fri Oct 14 17:40:08 2022 -0400 drm/amd/display: Round up DST_after_scaler to nearest int [ Upstream commit 8dc323133d74518e3b5b07242e2b2f088799ea6e ] [Why] The DST_after_scaler value that DML spreadsheet outputs is generally the driver value round up to the nearest int. Reviewed-by: Alvin Lee Acked-by: Alex Hung Signed-off-by: George Shen Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 13eac434b2dadbea6e284d1da94ac11652762327 Author: George Shen Date: Fri Oct 14 17:36:32 2022 -0400 drm/amd/display: Use forced DSC bpp in DML [ Upstream commit ab007e5db5d3b8b8975c7eec69992ff38fe2a46c ] [Why] DSC config is calculated separately from DML calculations. DML should use these separately calculated DSC params. The issue is that the calculated bpp is not properly propagated into DML. [How] Correctly used forced_bpp value in DML. Reviewed-by: Alvin Lee Acked-by: Alex Hung Signed-off-by: George Shen Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ead4edd23306868c8374abf11bed696909662d74 Author: George Shen Date: Fri Oct 7 12:43:26 2022 -0400 drm/amd/display: Fix DCN32 DSC delay calculation [ Upstream commit bad610c97c08eef3ed1fa769a8b08b94f95b451e ] [Why] DCN32 DSC delay calculation had an unintentional integer division, resulting in a mismatch against the DML spreadsheet. [How] Cast numerator to double before performing the division. Reviewed-by: Alvin Lee Acked-by: Alex Hung Signed-off-by: George Shen Tested-by: Mark Broadworth Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0f24635c2d239020c8b0223a6911fcec5d02d5cd Author: Mario Limonciello Date: Wed Oct 26 14:03:55 2022 -0500 drm/amd: Fail the suspend if resources can't be evicted [ Upstream commit 8d4de331f1b24a22d18e3c6116aa25228cf54854 ] If a system does not have swap and memory is under 100% usage, amdgpu will fail to evict resources. Currently the suspend carries on proceeding to reset the GPU: ``` [drm] evicting device resources failed [drm:amdgpu_device_ip_suspend_phase2 [amdgpu]] *ERROR* suspend of IP block failed -12 [drm] free PSP TMR buffer [TTM] Failed allocating page table [drm] evicting device resources failed amdgpu 0000:03:00.0: amdgpu: MODE1 reset amdgpu 0000:03:00.0: amdgpu: GPU mode1 reset amdgpu 0000:03:00.0: amdgpu: GPU smu mode1 reset ``` At this point if the suspend actually succeeded I think that amdgpu would have recovered because the GPU would have power cut off and restored. However the kernel fails to continue the suspend from the memory pressure and amdgpu fails to run the "resume" from the aborted suspend. ``` ACPI: PM: Preparing to enter system sleep state S3 SLUB: Unable to allocate memory on node -1, gfp=0xdc0(GFP_KERNEL|__GFP_ZERO) cache: Acpi-State, object size: 80, buffer size: 80, default order: 0, min order: 0 node 0: slabs: 22, objs: 1122, free: 0 ACPI Error: AE_NO_MEMORY, Could not update object reference count (20210730/utdelete-651) [drm:psp_hw_start [amdgpu]] *ERROR* PSP load kdb failed! [drm:psp_resume [amdgpu]] *ERROR* PSP resume failed [drm:amdgpu_device_fw_loading [amdgpu]] *ERROR* resume of IP block failed -62 amdgpu 0000:03:00.0: amdgpu: amdgpu_device_ip_resume failed (-62). PM: dpm_run_callback(): pci_pm_resume+0x0/0x100 returns -62 amdgpu 0000:03:00.0: PM: failed to resume async: error -62 ``` To avoid this series of unfortunate events, fail amdgpu's suspend when the memory eviction fails. This will let the system gracefully recover and the user can try suspend again when the memory pressure is relieved. Reported-by: post@davidak.de Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2223 Signed-off-by: Mario Limonciello Reviewed-by: Alex Deucher Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit aec74d1709d68f0fd4eab17cd003cba76eec7b08 Author: Yifan Zhang Date: Mon Oct 24 12:47:47 2022 +0800 drm/amdgpu: set fb_modifiers_not_supported in vkms [ Upstream commit 89b3554782e6b65894f0551e9e0a82ad02dac94d ] This patch to fix the gdm3 start failure with virual display: /usr/libexec/gdm-x-session[1711]: (II) AMDGPU(0): Setting screen physical size to 270 x 203 /usr/libexec/gdm-x-session[1711]: (EE) AMDGPU(0): Failed to make import prime FD as pixmap: 22 /usr/libexec/gdm-x-session[1711]: (EE) AMDGPU(0): failed to set mode: Invalid argument /usr/libexec/gdm-x-session[1711]: (WW) AMDGPU(0): Failed to set mode on CRTC 0 /usr/libexec/gdm-x-session[1711]: (EE) AMDGPU(0): Failed to enable any CRTC gnome-shell[1840]: Running GNOME Shell (using mutter 42.2) as a X11 window and compositing manager /usr/libexec/gdm-x-session[1711]: (EE) AMDGPU(0): failed to set mode: Invalid argument vkms doesn't have modifiers support, set fb_modifiers_not_supported to bring the gdm back. Signed-off-by: Yifan Zhang Acked-by: Guchun Chen Reviewed-by: Tim Huang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e84b556ec4d0224a7d9cbb7532bad915d0da6b58 Author: Alvin Lee Date: Thu Oct 20 11:46:51 2022 -0400 drm/amd/display: Enable timing sync on DCN32 [ Upstream commit c3d3f35b725bf9c93bec6d3c056f6bb7cfd27403 ] Missed enabling timing sync on DCN32 because DCN32 has a different DML param. Tested-by: Mark Broadworth Reviewed-by: Martin Leung Reviewed-by: Jun Lei Acked-by: Rodrigo Siqueira Signed-off-by: Alvin Lee Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 1ab31dfda04651cf9a1aa1284b4b8b64b4949b8b Author: Fangzhi Zuo Date: Thu Oct 20 11:46:41 2022 -0400 drm/amd/display: Ignore Cable ID Feature [ Upstream commit 14aed119942f6c2f1286022323139f7404db5d2b ] Ignore cable ID for DP2 receivers that does not support the feature. Tested-by: Mark Broadworth Reviewed-by: Roman Li Acked-by: Rodrigo Siqueira Signed-off-by: Fangzhi Zuo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 307f469e83124a31518f71697a342e12ca916360 Author: Filipe Manana Date: Tue Nov 1 16:15:40 2022 +0000 btrfs: remove pointless and double ulist frees in error paths of qgroup tests [ Upstream commit d0ea17aec12ea0f7b9d2ed727d8ef8169d1e7699 ] Several places in the qgroup self tests follow the pattern of freeing the ulist pointer they passed to btrfs_find_all_roots() if the call to that function returned an error. That is pointless because that function always frees the ulist in case it returns an error. Also In some places like at test_multiple_refs(), after a call to btrfs_qgroup_account_extent() we also leave "old_roots" and "new_roots" pointing to ulists that were freed, because btrfs_qgroup_account_extent() has freed those ulists, and if after that the next call to btrfs_find_all_roots() fails, we call ulist_free() on the "old_roots" ulist again, resulting in a double free. So remove those calls to reduce the code size and avoid double ulist free in case of an error. Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 8bef1dd7784c54ade5fe1339a0732f78a04f9e60 Author: Nathan Huckleberry Date: Tue Sep 13 13:55:44 2022 -0700 drm/imx: imx-tve: Fix return type of imx_tve_connector_mode_valid [ Upstream commit fc007fb815ab5395c3962c09b79a1630b0fbed9c ] The mode_valid field in drm_connector_helper_funcs is expected to be of type: enum drm_mode_status (* mode_valid) (struct drm_connector *connector, struct drm_display_mode *mode); The mismatched return type breaks forward edge kCFI since the underlying function definition does not match the function hook definition. The return type of imx_tve_connector_mode_valid should be changed from int to enum drm_mode_status. Reported-by: Dan Carpenter Link: https://github.com/ClangBuiltLinux/linux/issues/1703 Cc: llvm@lists.linux.dev Signed-off-by: Nathan Huckleberry Reviewed-by: Nathan Chancellor Reviewed-by: Fabio Estevam Reviewed-by: Philipp Zabel Signed-off-by: Philipp Zabel Link: https://patchwork.freedesktop.org/patch/msgid/20220913205544.155106-1-nhuck@google.com Signed-off-by: Sasha Levin commit 0147fcbfa3da2acd136b32bc6445eb4b97cf7874 Author: Nam Cao Date: Thu Oct 6 16:54:40 2022 +0200 i2c: i801: add lis3lv02d's I2C address for Vostro 5568 [ Upstream commit d6643d7207c572c1b0305ed505101f15502c6c87 ] Dell Vostro 5568 laptop has lis3lv02d, but its i2c address is not known to the kernel. Add this address. Output of "cat /sys/devices/platform/lis3lv02d/position" on Dell Vostro 5568 laptop: - Horizontal: (-18,0,1044) - Front elevated: (522,-18,1080) - Left elevated: (-18,-360,1080) - Upside down: (36,108,-1134) Signed-off-by: Nam Cao Reviewed-by: Jean Delvare Reviewed-by: Pali Rohár Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit cb899960d0fbcb8de760f136a7551dc11f682864 Author: Thierry Reding Date: Thu Oct 20 16:39:33 2022 +0200 i2c: tegra: Allocate DMA memory for DMA engine [ Upstream commit cdbf26251d3b35c4ccaea0c3a6de4318f727d3d2 ] When the I2C controllers are running in DMA mode, it is the DMA engine that performs the memory accesses rather than the I2C controller. Pass the DMA engine's struct device pointer to the DMA API to make sure the correct DMA operations are used. This fixes an issue where the DMA engine's SMMU stream ID needs to be misleadingly set for the I2C controllers in device tree. Suggested-by: Robin Murphy Signed-off-by: Thierry Reding Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 583cc50f30005df85c9bd3a7eae9967c1ceafc1a Author: Cristian Marussi Date: Fri Oct 28 15:08:28 2022 +0100 firmware: arm_scmi: Make tx_prepare time out eventually [ Upstream commit 59172b212ec0dbb97ceb5671d912e6e61fa802d5 ] SCMI transports based on shared memory, at start of transmissions, have to wait for the shared Tx channel area to be eventually freed by the SCMI platform before accessing the channel. In fact the channel is owned by the SCMI platform until marked as free by the platform itself and, as such, cannot be used by the agent until relinquished. As a consequence a badly misbehaving SCMI platform firmware could lock the channel indefinitely and make the kernel side SCMI stack loop forever waiting for such channel to be freed, possibly hanging the whole boot sequence. Add a timeout to the existent Tx waiting spin-loop so that, when the system ends up in this situation, the SCMI stack can at least bail-out, nosily warn the user, and abort the transmission. Reported-by: YaxiongTian Suggested-by: YaxiongTian Cc: Vincent Guittot Cc: Etienne Carriere Cc: Florian Fainelli Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20221028140833.280091-3-cristian.marussi@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit a0d64b8d5c0cfe24a47c40d8de023e8b5a2bd482 Author: Cristian Marussi Date: Fri Oct 28 15:08:26 2022 +0100 firmware: arm_scmi: Cleanup the core driver removal callback [ Upstream commit 3f4071cbd2063b917486d1047a4da47718215fee ] Platform drivers .remove callbacks are not supposed to fail and report errors. Such errors are indeed ignored by the core platform drivers and the driver unbind process is anyway completed. The SCMI core platform driver as it is now, instead, bails out reporting an error in case of an explicit unbind request. Fix the removal path by adding proper device links between the core SCMI device and the SCMI protocol devices so that a full SCMI stack unbind is triggered when the core driver is removed. The remove process does not bail out anymore on the anomalous conditions triggered by an explicit unbind but the user is still warned. Reported-by: Uwe Kleine-König Signed-off-by: Cristian Marussi Link: https://lore.kernel.org/r/20221028140833.280091-1-cristian.marussi@arm.com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit bcf1fb44389e412fdb800c7637231fdef7a22920 Author: Al Viro Date: Tue Nov 1 00:54:13 2022 +0000 block: blk_add_rq_to_plug(): clear stale 'last' after flush [ Upstream commit 878eb6e48f240d02ed1c9298020a0b6370695f24 ] blk_mq_flush_plug_list() empties ->mq_list and request we'd peeked there before that call is gone; in any case, we are not dealing with a mix of requests for different queues now - there's no requests left in the plug. Signed-off-by: Al Viro Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 24ee9f2263523325eb96eb032fec312692547b53 Author: Michael Ellerman Date: Thu Oct 27 23:56:26 2022 +1100 powerpc/64e: Fix amdgpu build on Book3E w/o AltiVec [ Upstream commit 2153fc9623e5465f503d793d4c94ad65e9ec9b5f ] There's a build failure for Book3E without AltiVec: Error: cc1: error: AltiVec not supported in this target make[6]: *** [/linux/scripts/Makefile.build:250: drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o] Error 1 This happens because the amdgpu build is only gated by PPC_LONG_DOUBLE_128, but that symbol can be enabled even though AltiVec is disabled. The only user of PPC_LONG_DOUBLE_128 is amdgpu, so just add a dependency on AltiVec to that symbol to fix the build. Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20221027125626.1383092-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit bfa4a8690c07ac67f4a2517fc49480dfbc589dde Author: Li Zhijian Date: Thu Sep 1 03:10:07 2022 +0000 ksefltests: pidfd: Fix wait_states: Test terminated by timeout [ Upstream commit 88e1f16ba58665e9edfce437ea487da2fa759af9 ] 0Day/LKP observed that the kselftest blocks forever since one of the pidfd_wait doesn't terminate in 1 of 30 runs. After digging into the source, we found that it blocks at: ASSERT_EQ(sys_waitid(P_PIDFD, pidfd, &info, WCONTINUED, NULL), 0); wait_states has below testing flow: CHILD PARENT ---------------+-------------- 1 STOP itself 2 WAIT for CHILD STOPPED 3 SIGNAL CHILD to CONT 4 CONT 5 STOP itself 5' WAIT for CHILD CONT 6 WAIT for CHILD STOPPED The problem is that the kernel cannot ensure the order of 5 and 5', once 5 goes first, the test will fail. we can reproduce it by: $ while true; do make run_tests -C pidfd; done Introduce a blocking read in child process to make sure the parent can check its WCONTINUED. CC: Philip Li Reported-by: kernel test robot Signed-off-by: Li Zhijian Reviewed-by: Christian Brauner (Microsoft) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c950715855ec16ad4aa1862d3694215df4660c0c Author: Michael Tretter Date: Fri Oct 28 11:52:06 2022 +0200 drm/rockchip: vop2: disable planes when disabling the crtc [ Upstream commit 447fb14bf07905b880c9ed1ea92c53d6dd0649d7 ] The vop2 driver needs to explicitly disable the planes if the crtc is disabled. Unless the planes are explicitly disabled, the address of the last framebuffer is kept in the registers of the VOP2. When re-enabling the encoder after it has been disabled by the driver, the VOP2 will start and read the framebuffer that has been freed but is still pointed to by the register. The iommu will catch these read accesses and print errors. Explicitly disable the planes when the crtc is disabled to reset the registers. Signed-off-by: Michael Tretter Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20221028095206.2136601-3-m.tretter@pengutronix.de Signed-off-by: Sasha Levin commit 6b4809eec3babc13b37c6783c436b29922628df7 Author: Michael Tretter Date: Fri Oct 28 11:52:05 2022 +0200 drm/rockchip: vop2: fix null pointer in plane_atomic_disable [ Upstream commit 471bf2406c043491b1a8288e5f04bc278f7d7ca1 ] If the vop2_plane_atomic_disable function is called with NULL as a state, accessing the old_pstate runs into a null pointer exception. However, the drm_atomic_helper_disable_planes_on_crtc function calls the atomic_disable callback with state NULL. Allow to disable a plane without passing a plane state by checking the old_pstate only if a state is passed. Signed-off-by: Michael Tretter Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20221028095206.2136601-2-m.tretter@pengutronix.de Signed-off-by: Sasha Levin commit a7c9a5e224b525533717e1f034af66dbfe49eee1 Author: Mario Limonciello Date: Fri Oct 14 07:11:36 2022 -0500 ACPI: x86: Add another system to quirk list for forcing StorageD3Enable [ Upstream commit 2124becad797245d49252d2d733aee0322233d7e ] commit 018d6711c26e4 ("ACPI: x86: Add a quirk for Dell Inspiron 14 2-in-1 for StorageD3Enable") introduced a quirk to allow a system with ambiguous use of _ADR 0 to force StorageD3Enable. Julius Brockmann reports that Inspiron 16 5625 suffers that same symptoms. Add this other system to the list as well. Link: https://bugzilla.kernel.org/show_bug.cgi?id=216440 Reported-and-tested-by: Julius Brockmann Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 20e43b70f52e875f7d4630a582f441ed70b8fc97 Author: Chuck Lever Date: Sat Oct 8 14:58:29 2022 -0400 SUNRPC: Fix crasher in gss_unwrap_resp_integ() [ Upstream commit 8a0fa3ff3b606b55c4edc71ad133e61529b64549 ] If a zero length is passed to kmalloc() it returns 0x10, which is not a valid address. gss_unwrap_resp_integ() subsequently crashes when it attempts to dereference that pointer. Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c7277c57d2e63a85602e5bcd7d0f4cf85fd960cd Author: Benjamin Coddington Date: Wed Oct 19 12:09:18 2022 -0400 NFSv4: Retry LOCK on OLD_STATEID during delegation return [ Upstream commit f5ea16137a3fa2858620dc9084466491c128535f ] There's a small window where a LOCK sent during a delegation return can race with another OPEN on client, but the open stateid has not yet been updated. In this case, the client doesn't handle the OLD_STATEID error from the server and will lose this lock, emitting: "NFS: nfs4_handle_delegation_recall_error: unhandled error -10024". Fix this by sending the task through the nfs4 error handling in nfs4_lock_done() when we may have to reconcile our stateid with what the server believes it to be. For this case, the result is a retry of the LOCK operation with the updated stateid. Reported-by: Gonzalo Siero Humet Signed-off-by: Benjamin Coddington Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit e71725112940ffbbe942fbdc1f5c4d0975c5bfa9 Author: Qu Wenruo Date: Mon Oct 10 18:36:06 2022 +0800 btrfs: raid56: properly handle the error when unable to find the missing stripe [ Upstream commit f15fb2cd979a07fbfc666e2f04b8b30ec9233b2a ] In raid56_alloc_missing_rbio(), if we can not determine where the missing device is inside the full stripe, we just BUG_ON(). This is not necessary especially the only caller inside scrub.c is already properly checking the return value, and will treat it as a memory allocation failure. Fix the error handling by: - Add an extra warning for the reason Although personally speaking it may be better to be an ASSERT(). - Properly free the allocated rbio Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 291cc29d444b74a1a041c312579728405bc9251c Author: Michael Margolin Date: Thu Oct 20 18:19:49 2022 +0300 RDMA/efa: Add EFA 0xefa2 PCI ID [ Upstream commit b75927cff13e0b3b652a12da7eb9a012911799e8 ] Add support for 0xefa2 devices. Reviewed-by: Firas Jahjah Reviewed-by: Yossi Leybovich Signed-off-by: Michael Margolin Link: https://lore.kernel.org/r/20221020151949.1768-1-mrgolin@amazon.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin commit 9acff699ff8edf9ddc1b1267661c1ab6d58845af Author: Jonathan Cameron Date: Mon Aug 15 16:40:43 2022 +0100 cxl/mbox: Add a check on input payload size [ Upstream commit cf00b33058b196b4db928419dde68993b15a975b ] A bug in the LSA code resulted in transfers slightly larger than the mailbox size. Let us make it easier to catch similar issues in future by adding a low level check. Signed-off-by: Jonathan Cameron Link: https://lore.kernel.org/r/20220815154044.24733-2-Jonathan.Cameron@huawei.com Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit ffc70e79fb4f238dd0cc846770a32232e01f85e6 Author: Hans de Goede Date: Tue Oct 25 14:12:23 2022 +0200 ACPI: scan: Add LATT2021 to acpi_ignore_dep_ids[] [ Upstream commit fa153b7cddce795662d38f78a87612c166c0f692 ] Some x86/ACPI laptops with MIPI cameras have a LATT2021 ACPI device in the _DEP dependency list of the ACPI devices for the camera-sensors (which have flags.honor_deps set). The _DDN for the LATT2021 device is "Lattice FW Update Client Driver", suggesting that this is used for firmware updates of something. There is no Linux driver for this and if Linux gets support for updates it will likely be in userspace through fwupd. For now add the LATT2021 HID to acpi_ignore_dep_ids[] so that acpi_dev_ready_for_enumeration() will return true once the other _DEP dependencies are met. Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e5f4b38362df93594cb426b04979d8834122f159 Author: Christian König Date: Tue Sep 27 18:43:03 2022 +0200 drm/scheduler: fix fence ref counting [ Upstream commit b3af84383e7abdc5e63435817bb73a268e7c3637 ] We leaked dependency fences when processes were beeing killed. Additional to that grab a reference to the last scheduled fence. Signed-off-by: Christian König Reviewed-by: Andrey Grodzovsky Link: https://patchwork.freedesktop.org/patch/msgid/20220929180151.139751-1-christian.koenig@amd.com Signed-off-by: Sasha Levin commit a3c25f47266e464a4d29b7bbd721f00711a8f192 Author: Alvin Lee Date: Thu Oct 6 17:26:49 2022 -0400 drm/amd/display: Don't return false if no stream [ Upstream commit abe4d9f03fae76c9650b0d942faf6990b35c377b ] pipe_ctx[i] exists even if the pipe is not in use. If the pipe is not in use it will always have a null stream, so don't return false in this case. Tested-by: Daniel Wheeler Reviewed-by: Rodrigo Siqueira Acked-by: Qingqing Zhuo Signed-off-by: Alvin Lee Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 65d3c9275229e7f9df2d615a21e9996242fa24b4 Author: Rodrigo Siqueira Date: Thu Oct 6 17:26:48 2022 -0400 drm/amd/display: Remove wrong pipe control lock [ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ] When using a device based on DCN32/321, we have an issue where a second 4k@60Hz display does not light up, and the system becomes unresponsive for a few minutes. In the debug process, it was possible to see a hang in the function dcn20_post_unlock_program_front_end in this part: for (j = 0; j < TIMEOUT_FOR_PIPE_ENABLE_MS*1000 && hubp->funcs->hubp_is_flip_pending(hubp); j++) mdelay(1); } The hubp_is_flip_pending always returns positive for waiting pending flips which is a symptom of pipe hang. Additionally, the dmesg log shows this message after a few minutes: BUG: soft lockup - CPU#4 stuck for 26s! ... [ +0.000003] dcn20_post_unlock_program_front_end+0x112/0x340 [amdgpu] [ +0.000171] dc_commit_state_no_check+0x63d/0xbf0 [amdgpu] [ +0.000155] ? dc_validate_global_state+0x358/0x3d0 [amdgpu] [ +0.000154] dc_commit_state+0xe2/0xf0 [amdgpu] This confirmed the hypothesis that we had a pipe hanging somewhere. Next, after checking the ftrace entries, we have the below weird sequence: [..] 2) | dcn10_lock_all_pipes [amdgpu]() { 2) 0.120 us | optc1_is_tg_enabled [amdgpu](); 2) | dcn20_pipe_control_lock [amdgpu]() { 2) | dc_dmub_srv_clear_inbox0_ack [amdgpu]() { 2) 0.121 us | amdgpu_dm_dmub_reg_write [amdgpu](); 2) 0.551 us | } 2) | dc_dmub_srv_send_inbox0_cmd [amdgpu]() { 2) 0.110 us | amdgpu_dm_dmub_reg_write [amdgpu](); 2) 0.511 us | } 2) | dc_dmub_srv_wait_for_inbox0_ack [amdgpu]() { 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); 2) 0.110 us | amdgpu_dm_dmub_reg_read [amdgpu](); [..] We are not expected to read from dmub register so many times and for so long. From the trace log, it was possible to identify that the function dcn20_pipe_control_lock was triggering the dmub operation when it was unnecessary and causing the hang issue. This commit drops the unnecessary dmub code and, consequently, fixes the second display not lighting up the issue. Tested-by: Daniel Wheeler Acked-by: Qingqing Zhuo Signed-off-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e10357a55d79263c370762bc88d210b0273ec080 Author: Gayatri Kammela Date: Mon Sep 12 16:33:07 2022 -0700 platform/x86/intel: pmc/core: Add Raptor Lake support to pmc core driver [ Upstream commit 555a68dd681b7437a2708001d465c85f6dfa6955 ] Add Raptor Lake client parts (both RPL and RPL_S) support to pmc core driver. Raptor Lake client parts reuse all the Alder Lake PCH IPs. Cc: Srinivas Pandruvada Cc: Andy Shevchenko Cc: David Box Acked-by: Rajneesh Bhardwaj Signed-off-by: Gayatri Kammela Link: https://lore.kernel.org/r/20220912233307.409954-2-gayatri.kammela@linux.intel.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit f8d00ab09c1446a102ad7a72e13666ce5ab5b076 Author: Jelle van der Waa Date: Wed Oct 19 21:47:51 2022 +0200 platform/x86: thinkpad_acpi: Fix reporting a non present second fan on some models [ Upstream commit a10d50983f7befe85acf95ea7dbf6ba9187c2d70 ] thinkpad_acpi was reporting 2 fans on a ThinkPad T14s gen 1, even though the laptop has only 1 fan. The second, not present fan always reads 65535 (-1 in 16 bit signed), ignore fans which report 65535 to avoid reporting the non present fan. Signed-off-by: Jelle van der Waa Link: https://lore.kernel.org/r/20221019194751.5392-1-jvanderwaa@redhat.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 1ee83fc52044ecd2edada43aaca06496114fde2b Author: Yiqing Yao Date: Tue Oct 18 15:17:59 2022 +0800 drm/amdgpu: Adjust MES polling timeout for sriov [ Upstream commit 226dcfad349f23f7744d02b24f8ec3bc4f6198ac ] [why] MES response time in sriov may be longer than default value due to reset or init in other VF. A timeout value specific to sriov is needed. [how] When in sriov, adjust the timeout value to calculated worst case scenario. Signed-off-by: Yiqing Yao Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8bac7eb03d39c30ac3293c294c0f6cc95cdb0848 Author: Leohearts Date: Fri Oct 21 14:34:32 2022 +0800 ASoC: amd: yc: Add Lenovo Thinkbook 14+ 2022 21D0 to quirks table [ Upstream commit a75481fa00cc06a8763e1795b93140407948c03a ] Lenovo Thinkbook 14+ 2022 (ThinkBook 14 G4+ ARA) uses Ryzen 6000 processor, and has the same microphone problem as other ThinkPads with AMD Ryzen 6000 series CPUs, which has been listed in https://bugzilla.kernel.org/show_bug.cgi?id=216267. Adding 21D0 to quirks table solves this microphone problem for ThinkBook 14 G4+ ARA. Signed-off-by: Taroe Leohearts Link: https://lore.kernel.org/r/26B141B486BEF706+313d1732-e00c-ea41-3123-0d048d40ebb6@leohearts.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ea5c064fa8d30682987dc5a70b702fef8a9f6be0 Author: linkt Date: Tue Oct 11 10:51:36 2022 +0800 ASoC: amd: yc: Adding Lenovo ThinkBook 14 Gen 4+ ARA and Lenovo ThinkBook 16 Gen 4+ ARA to the Quirks List [ Upstream commit a450b5c8739248069e11f72129fca61a56125577 ] Lenovo ThinkBook 14 Gen 4+ ARA and ThinkBook 16 Gen 4+ ARA need to be added to the list of quirks for the microphone to work properly. Signed-off-by: linkt Reviewed-by: Mario Limonciello Link: https://lore.kernel.org/r/MEYPR01MB8397A3C27DE6206FA3EF834DB6239@MEYPR01MB8397.ausprd01.prod.outlook.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0dfd361ebfd61c7efde767d2180aed312fac12dc Author: Shuming Fan Date: Wed Oct 19 17:57:15 2022 +0800 ASoC: rt1308-sdw: add the default value of some registers [ Upstream commit 75d8b1662ca5c20cf8365575222abaef18ff1f50 ] The driver missed the default value of register 0xc070/0xc360. This patch adds that default value to avoid invalid register access when the device doesn't be enumerated yet. BugLink: https://github.com/thesofproject/linux/issues/3924 Signed-off-by: Shuming Fan Link: https://lore.kernel.org/r/20221019095715.31082-1-shumingf@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8a38fba9d512317e1a14ab88d1c8813b3687dff3 Author: Yong Zhi Date: Mon Oct 17 15:57:28 2022 -0500 ASoC: Intel: sof_rt5682: Add quirk for Rex board [ Upstream commit b4dd2e3758709aa8a2abd1ac34c56bd09b980039 ] Add mtl_mx98357_rt5682 driver data for Chrome Rex board support. Reviewed-by: Bard Liao Reviewed-by: Curtis Malainey Signed-off-by: Yong Zhi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20221017205728.210813-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit bb4e591056563ddb6d3baff6592a8ba1878b2d01 Author: Ricardo Cañuelo Date: Mon Oct 10 08:39:27 2022 +0200 selftests/kexec: fix build for ARCH=x86_64 [ Upstream commit 2a8e366b23fea29a5308f71ba49555e3c8c664f1 ] Handle the scenario where the build is launched with the ARCH envvar defined as x86_64. Signed-off-by: Ricardo Cañuelo Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 171afd5f49dcee3316f156c115b26d9a93fcdffd Author: Ricardo Cañuelo Date: Mon Oct 10 08:38:11 2022 +0200 selftests/intel_pstate: fix build for ARCH=x86_64 [ Upstream commit beb7d862ed4ac6aa14625418970f22a7d55b8615 ] Handle the scenario where the build is launched with the ARCH envvar defined as x86_64. Signed-off-by: Ricardo Cañuelo Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 04e5bddff30dfe9a66ade55907a81a85e73730d6 Author: Ricardo Cañuelo Date: Mon Oct 10 08:37:02 2022 +0200 selftests/futex: fix build for clang [ Upstream commit 03cab65a07e083b6c1010fbc8f9b817e9aca75d9 ] Don't use the test-specific header files as source files to force a target dependency, as clang will complain if more than one source file is used for a compile command with a single '-o' flag. Use the proper Makefile variables instead as defined in tools/testing/selftests/lib.mk. Signed-off-by: Ricardo Cañuelo Reviewed-by: André Almeida Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 43b9efa0c0d90e3738eb9a65e615058f0c8607a3 Author: Pierre-Louis Bossart Date: Mon Oct 17 15:40:54 2022 -0500 ASoC: Intel: sof_sdw: add quirk variant for LAPBC710 NUC15 [ Upstream commit 41deb2db64997d01110faaf763bd911d490dfde7 ] Some NUC15 LAPBC710 devices don't expose the same DMI information as the Intel reference, add additional entry in the match table. BugLink: https://github.com/thesofproject/linux/issues/3885 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20221017204054.207512-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1bc81ba12bacec0db2d53dece12932f54b57c1f6 Author: Siarhei Volkau Date: Sun Oct 16 16:26:45 2022 +0300 ASoC: codecs: jz4725b: fix capture selector naming [ Upstream commit 80852f8268769715db335a22305e81a0c4a38a84 ] At the moment Capture source selector appears on Playback tab in the alsamixer and has a senseless name. Let's fix that. Signed-off-by: Siarhei Volkau Link: https://lore.kernel.org/r/20221016132648.3011729-5-lis8215@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 98d27d95cf328a3cafda1909cb8f4a2de96a3167 Author: Siarhei Volkau Date: Sun Oct 16 16:26:44 2022 +0300 ASoC: codecs: jz4725b: use right control for Capture Volume [ Upstream commit 1538e2c8c9b7e7a656effcc6e4e7cfe8c1b405fd ] Line In Bypass control is used as Master Capture at the moment this is completely incorrect. Current control routed to Mixer instead of ADC, thus can't affect Capture path. ADC control shall be used instead. ADC volume control parameters are different, so the patch fixes that as well. Manual says (16.6.3.2 Programmable input attenuation amplifier: PGATM) that gain varies in range 0dB..22.5dB with 1.5dB step. Signed-off-by: Siarhei Volkau Link: https://lore.kernel.org/r/20221016132648.3011729-4-lis8215@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0e58c9d97479f4599308f9f30e5b7320c7c11ed4 Author: Siarhei Volkau Date: Sun Oct 16 16:26:43 2022 +0300 ASoC: codecs: jz4725b: fix reported volume for Master ctl [ Upstream commit 088777bf65b98cfa4b5378119d0a7d49a58ece44 ] DAC volume control is the Master Playback Volume at the moment and it reports wrong levels in alsamixer and other alsa apps. The patch fixes that, as stated in manual on the jz4725b SoC (16.6.3.4 Programmable attenuation: GOD) the ctl range varies from -22.5dB to 0dB with 1.5dB step. Signed-off-by: Siarhei Volkau Link: https://lore.kernel.org/r/20221016132648.3011729-3-lis8215@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9daea6fc42784a182039959327b33c7ca40dbf95 Author: Siarhei Volkau Date: Sun Oct 16 16:26:42 2022 +0300 ASoC: codecs: jz4725b: add missed Line In power control bit [ Upstream commit 1013999b431b4bcdc1f5ae47dd3338122751db31 ] Line In path stayed powered off during capturing or bypass to mixer. Signed-off-by: Siarhei Volkau Link: https://lore.kernel.org/r/20221016132648.3011729-2-lis8215@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3c8412afceb8b69fa58173d2b27d5073438a08b1 Author: Mauro Lima Date: Wed Oct 12 12:21:35 2022 -0300 spi: intel: Fix the offset to get the 64K erase opcode [ Upstream commit 6a43cd02ddbc597dc9a1f82c1e433f871a2f6f06 ] According to documentation, the 64K erase opcode is located in VSCC range [16:23] instead of [8:15]. Use the proper value to shift the mask over the correct range. Signed-off-by: Mauro Lima Reviewed-by: Mika Westerberg Link: https://lore.kernel.org/r/20221012152135.28353-1-mauro.lima@eclypsium.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0d29ba0a167e9cf13ecb26a5a57a5f363c30e4ab Author: Xiaolei Wang Date: Mon Oct 10 17:20:14 2022 +0800 ASoC: wm8962: Add an event handler for TEMP_HP and TEMP_SPK [ Upstream commit ee1aa2ae3eaa96e70229fa61deee87ef4528ffdf ] In wm8962 driver, the WM8962_ADDITIONAL_CONTROL_4 is used as a volatile register, but this register mixes a bunch of volatile status bits and a bunch of non-volatile control bits. The dapm widgets TEMP_HP and TEMP_SPK leverages the control bits in this register. After the wm8962 probe, the regmap will bet set to cache only mode, then a read error like below would be triggered when trying to read the initial power state of the dapm widgets TEMP_HP and TEMP_SPK. wm8962 0-001a: ASoC: error at soc_component_read_no_lock on wm8962.0-001a: -16 In order to fix this issue, we add event handler to actually power up/down these widgets. With this change, we also need to explicitly power off these widgets in the wm8962 probe since they are enabled by default. Signed-off-by: Xiaolei Wang Tested-by: Adam Ford Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221010092014.2229246-1-xiaolei.wang@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ea68c25fb67988a68d63ed7475688538501358bd Author: Derek Fang Date: Wed Oct 12 11:01:02 2022 +0800 ASoC: rt1019: Fix the TDM settings [ Upstream commit f2635d45a750182c6d5de15e2d6b059e0c302d7e ] Complete the missing and correct the TDM settings. Signed-off-by: Derek Fang Link: https://lore.kernel.org/r/20221012030102.4042-1-derek.fang@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1bd3b151bf1369edd2a7f710dbe0b5bd8d6cb232 Author: Derek Fang Date: Wed Oct 12 11:13:20 2022 +0800 ASoC: rt5682s: Fix the TDM Tx settings [ Upstream commit d94bf16e920047c9b4ea2b57f7b53b4ff5039d9f ] Complete the missing and correct the TDM Tx settings. Signed-off-by: Derek Fang Link: https://lore.kernel.org/r/20221012031320.6980-1-derek.fang@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9e8e61b510290dbb113adadc1973f4cd494346ee Author: Zhang Qilong Date: Sat Oct 8 22:05:22 2022 +0800 ASoC: mt6660: Keep the pm_runtime enables before component stuff in mt6660_i2c_probe [ Upstream commit c4ab29b0f3a6f1e167c5a627f7cd036c1d2b7d65 ] It would be better to keep the pm_runtime enables before the IRQ and component stuff. Both of those could start triggering PM runtime events. Signed-off-by: Zhang Qilong Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20221008140522.134912-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e6666aa7c3ce297907f1f6e018979df1e336cb47 Author: Zhang Qilong Date: Mon Oct 10 19:48:52 2022 +0800 ASoC: wm8997: Revert "ASoC: wm8997: Fix PM disable depth imbalance in wm8997_probe" [ Upstream commit 68ce83e3bb26feba0fcdd59667fde942b3a600a1 ] This reverts commit 41a736ac20602f64773e80f0f5b32cde1830a44a. The pm_runtime_disable is redundant when error returns in wm8997_probe, we just revert the old patch to fix it. Signed-off-by: Zhang Qilong Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221010114852.88127-4-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd7e24f94e2e199210b687e34de1d08d675af09a Author: Zhang Qilong Date: Mon Oct 10 19:48:51 2022 +0800 ASoC: wm5110: Revert "ASoC: wm5110: Fix PM disable depth imbalance in wm5110_probe" [ Upstream commit 7d4e966f4cd73ff69bf06934e8e14a33fb7ef447 ] This reverts commit 86b46bf1feb83898d89a2b4a8d08d21e9ea277a7. The pm_runtime_disable is redundant when error returns in wm5110_probe, we just revert the old patch to fix it. Signed-off-by: Zhang Qilong Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221010114852.88127-3-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a10c4a0a2a3b6b5edc9758d56969d99e43d5f862 Author: Zhang Qilong Date: Mon Oct 10 19:48:50 2022 +0800 ASoC: wm5102: Revert "ASoC: wm5102: Fix PM disable depth imbalance in wm5102_probe" [ Upstream commit de71d7567e358effd06dfc3e2a154b25f1331c10 ] This reverts commit fcbb60820cd3008bb44334a0395e5e57ccb77329. The pm_runtime_disable is redundant when error returns in wm5102_probe, we just revert the old patch to fix it. Signed-off-by: Zhang Qilong Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20221010114852.88127-2-zhangqilong3@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 112edc13f0bd333dc8bbba7e97f814102ee6ae99 Author: Krishna Yarlagadda Date: Sat Oct 1 17:51:44 2022 +0530 spi: tegra210-quad: Fix combined sequence [ Upstream commit 8777dd9dff4020bba66654ec92e4b0ab6367ad30 ] Return value should be updated to zero in combined sequence routine if transfer is completed successfully. Currently it holds timeout value resulting in errors. Signed-off-by: Krishna Yarlagadda Link: https://lore.kernel.org/r/20221001122148.9158-1-kyarlagadda@nvidia.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5fea4202b5faccfc6449381a299e8ce4b994d666 Author: Akhil P Oommen Date: Wed Sep 28 12:49:00 2022 +0530 drm/msm/gpu: Fix crash during system suspend after unbind [ Upstream commit 76efc2453d0e8e5d6692ef69981b183ad674edea ] In adreno_unbind, we should clean up gpu device's drvdata to avoid accessing a stale pointer during system suspend. Also, check for NULL ptr in both system suspend/resume callbacks. Signed-off-by: Akhil P Oommen Patchwork: https://patchwork.freedesktop.org/patch/505075/ Link: https://lore.kernel.org/r/20220928124830.2.I5ee0ac073ccdeb81961e5ec0cce5f741a7207a71@changeid Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 21f7625a65a9c675e7c88ccbaa8eafd880d0349c Author: Christian Marangi Date: Fri Oct 21 18:53:04 2022 +0200 mtd: rawnand: qcom: handle ret from parse with codeword_fixup commit 7df140e84a75c89962feef659d686303d3ce75e5 upstream. With use_codeword_fixup enabled, any return from mtd_device_parse_register gets overwritten. Aside from the clear bug, this is also problematic as a parser can EPROBE_DEFER and because this is not correctly handled, the nand is never rescanned later in the bootup process. An example of this problem is when smem requires additional time to be probed and nandc use qcomsmempart as parser. Parser will return EPROBE_DEFER but in the current code this ret gets overwritten by qcom_nand_host_parse_boot_partitions and qcom_nand_host_init_and_register return 0. Correctly handle the return code from mtd_device_parse_register so that any error from this function is not ignored. Fixes: 862bdedd7f4b ("mtd: nand: raw: qcom_nandc: add support for unprotected spare data pages") Cc: stable@vger.kernel.org # v6.0+ Signed-off-by: Christian Marangi Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221021165304.19991-1-ansuelsmth@gmail.com Signed-off-by: Greg Kroah-Hartman