commit 81d8d30c35edf29c5c70186ccb14dac4a5ca38a8 Author: Greg Kroah-Hartman Date: Wed Apr 20 09:34:22 2022 +0200 Linux 5.15.35 Link: https://lore.kernel.org/r/20220418121200.312988959@linuxfoundation.org Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20220419073048.315594917@linuxfoundation.org Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit 85f25bb9a0051198af48ac2f3afc9f16f2277114 Author: Duoming Zhou Date: Fri Apr 15 19:14:22 2022 +0300 ax25: Fix UAF bugs in ax25 timers commit 82e31755e55fbcea6a9dfaae5fe4860ade17cbc0 upstream. There are race conditions that may lead to UAF bugs in ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(), ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we call ax25_release() to deallocate ax25_dev. One of the UAF bugs caused by ax25_release() is shown below: (Thread 1) | (Thread 2) ax25_dev_device_up() //(1) | ... | ax25_kill_by_device() ax25_bind() //(2) | ax25_connect() | ... ax25_std_establish_data_link() | ax25_start_t1timer() | ax25_dev_device_down() //(3) mod_timer(&ax25->t1timer,..) | | ax25_release() (wait a time) | ... | ax25_dev_put(ax25_dev) //(4)FREE ax25_t1timer_expiry() | ax25->ax25_dev->values[..] //USE| ... ... | We increase the refcount of ax25_dev in position (1) and (2), and decrease the refcount of ax25_dev in position (3) and (4). The ax25_dev will be freed in position (4) and be used in ax25_t1timer_expiry(). The fail log is shown below: ============================================================== [ 106.116942] BUG: KASAN: use-after-free in ax25_t1timer_expiry+0x1c/0x60 [ 106.116942] Read of size 8 at addr ffff88800bda9028 by task swapper/0/0 [ 106.116942] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-06123-g0905eec574 [ 106.116942] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-14 [ 106.116942] Call Trace: ... [ 106.116942] ax25_t1timer_expiry+0x1c/0x60 [ 106.116942] call_timer_fn+0x122/0x3d0 [ 106.116942] __run_timers.part.0+0x3f6/0x520 [ 106.116942] run_timer_softirq+0x4f/0xb0 [ 106.116942] __do_softirq+0x1c2/0x651 ... This patch adds del_timer_sync() in ax25_release(), which could ensure that all timers stop before we deallocate ax25_dev. Signed-off-by: Duoming Zhou Signed-off-by: Paolo Abeni [OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 43c107021d9160f6a1610bafba6dadc0323ae548 Author: Duoming Zhou Date: Fri Apr 15 19:14:21 2022 +0300 ax25: Fix NULL pointer dereferences in ax25 timers commit fc6d01ff9ef03b66d4a3a23b46fc3c3d8cf92009 upstream. The previous commit 7ec02f5ac8a5 ("ax25: fix NPD bug in ax25_disconnect") move ax25_disconnect into lock_sock() in order to prevent NPD bugs. But there are race conditions that may lead to null pointer dereferences in ax25_heartbeat_expiry(), ax25_t1timer_expiry(), ax25_t2timer_expiry(), ax25_t3timer_expiry() and ax25_idletimer_expiry(), when we use ax25_kill_by_device() to detach the ax25 device. One of the race conditions that cause null pointer dereferences can be shown as below: (Thread 1) | (Thread 2) ax25_connect() | ax25_std_establish_data_link() | ax25_start_t1timer() | mod_timer(&ax25->t1timer,..) | | ax25_kill_by_device() (wait a time) | ... | s->ax25_dev = NULL; //(1) ax25_t1timer_expiry() | ax25->ax25_dev->values[..] //(2)| ... ... | We set null to ax25_cb->ax25_dev in position (1) and dereference the null pointer in position (2). The corresponding fail log is shown below: =============================================================== BUG: kernel NULL pointer dereference, address: 0000000000000050 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.17.0-rc6-00794-g45690b7d0 RIP: 0010:ax25_t1timer_expiry+0x12/0x40 ... Call Trace: call_timer_fn+0x21/0x120 __run_timers.part.0+0x1ca/0x250 run_timer_softirq+0x2c/0x60 __do_softirq+0xef/0x2f3 irq_exit_rcu+0xb6/0x100 sysvec_apic_timer_interrupt+0xa2/0xd0 ... This patch moves ax25_disconnect() before s->ax25_dev = NULL and uses del_timer_sync() to delete timers in ax25_disconnect(). If ax25_disconnect() is called by ax25_kill_by_device() or ax25->ax25_dev is NULL, the reason in ax25_disconnect() will be equal to ENETUNREACH, it will wait all timers to stop before we set null to s->ax25_dev in ax25_kill_by_device(). Fixes: 7ec02f5ac8a5 ("ax25: fix NPD bug in ax25_disconnect") Signed-off-by: Duoming Zhou Signed-off-by: David S. Miller [OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit da6509fba636f7f8b2e902b1e4742fdbf1bf059f Author: Duoming Zhou Date: Fri Apr 15 19:14:20 2022 +0300 ax25: fix NPD bug in ax25_disconnect commit 7ec02f5ac8a5be5a3f20611731243dc5e1d9ba10 upstream. The ax25_disconnect() in ax25_kill_by_device() is not protected by any locks, thus there is a race condition between ax25_disconnect() and ax25_destroy_socket(). when ax25->sk is assigned as NULL by ax25_destroy_socket(), a NULL pointer dereference bug will occur if site (1) or (2) dereferences ax25->sk. ax25_kill_by_device() | ax25_release() ax25_disconnect() | ax25_destroy_socket() ... | if(ax25->sk != NULL) | ... ... | ax25->sk = NULL; bh_lock_sock(ax25->sk); //(1) | ... ... | bh_unlock_sock(ax25->sk); //(2)| This patch moves ax25_disconnect() into lock_sock(), which can synchronize with ax25_destroy_socket() in ax25_release(). Fail log: =============================================================== BUG: kernel NULL pointer dereference, address: 0000000000000088 ... RIP: 0010:_raw_spin_lock+0x7e/0xd0 ... Call Trace: ax25_disconnect+0xf6/0x220 ax25_device_event+0x187/0x250 raw_notifier_call_chain+0x5e/0x70 dev_close_many+0x17d/0x230 rollback_registered_many+0x1f1/0x950 unregister_netdevice_queue+0x133/0x200 unregister_netdev+0x13/0x20 ... Signed-off-by: Duoming Zhou Signed-off-by: David S. Miller [OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 1bf8946d5826788c82971977245bcd3313678eac Author: Duoming Zhou Date: Fri Apr 15 19:14:19 2022 +0300 ax25: fix UAF bug in ax25_send_control() commit 5352a761308397a0e6250fdc629bb3f615b94747 upstream. There are UAF bugs in ax25_send_control(), when we call ax25_release() to deallocate ax25_dev. The possible race condition is shown below: (Thread 1) | (Thread 2) ax25_dev_device_up() //(1) | | ax25_kill_by_device() ax25_bind() //(2) | ax25_connect() | ... ax25->state = AX25_STATE_1 | ... | ax25_dev_device_down() //(3) (Thread 3) ax25_release() | ax25_dev_put() //(4) FREE | case AX25_STATE_1: | ax25_send_control() | alloc_skb() //USE | The refcount of ax25_dev increases in position (1) and (2), and decreases in position (3) and (4). The ax25_dev will be freed before dereference sites in ax25_send_control(). The following is part of the report: [ 102.297448] BUG: KASAN: use-after-free in ax25_send_control+0x33/0x210 [ 102.297448] Read of size 8 at addr ffff888009e6e408 by task ax25_close/602 [ 102.297448] Call Trace: [ 102.303751] ax25_send_control+0x33/0x210 [ 102.303751] ax25_release+0x356/0x450 [ 102.305431] __sock_release+0x6d/0x120 [ 102.305431] sock_close+0xf/0x20 [ 102.305431] __fput+0x11f/0x420 [ 102.305431] task_work_run+0x86/0xd0 [ 102.307130] get_signal+0x1075/0x1220 [ 102.308253] arch_do_signal_or_restart+0x1df/0xc00 [ 102.308253] exit_to_user_mode_prepare+0x150/0x1e0 [ 102.308253] syscall_exit_to_user_mode+0x19/0x50 [ 102.308253] do_syscall_64+0x48/0x90 [ 102.308253] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 102.308253] RIP: 0033:0x405ae7 This patch defers the free operation of ax25_dev and net_device after all corresponding dereference sites in ax25_release() to avoid UAF. Fixes: 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()") Signed-off-by: Duoming Zhou Signed-off-by: Paolo Abeni [OP: backport to 5.15: adjust dev_put_track()->dev_put()] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 452ae92b99062d2f6a34324eaf705a3b7eac9f8b Author: Duoming Zhou Date: Fri Apr 15 19:14:18 2022 +0300 ax25: Fix refcount leaks caused by ax25_cb_del() commit 9fd75b66b8f68498454d685dc4ba13192ae069b0 upstream. The previous commit d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") and commit feef318c855a ("ax25: fix UAF bugs of net_device caused by rebinding operation") increase the refcounts of ax25_dev and net_device in ax25_bind() and decrease the matching refcounts in ax25_kill_by_device() in order to prevent UAF bugs, but there are reference count leaks. The root cause of refcount leaks is shown below: (Thread 1) | (Thread 2) ax25_bind() | ... | ax25_addr_ax25dev() | ax25_dev_hold() //(1) | ... | dev_hold_track() //(2) | ... | ax25_destroy_socket() | ax25_cb_del() | ... | hlist_del_init() //(3) | | (Thread 3) | ax25_kill_by_device() | ... | ax25_for_each(s, &ax25_list) { | if (s->ax25_dev == ax25_dev) //(4) | ... | Firstly, we use ax25_bind() to increase the refcount of ax25_dev in position (1) and increase the refcount of net_device in position (2). Then, we use ax25_cb_del() invoked by ax25_destroy_socket() to delete ax25_cb in hlist in position (3) before calling ax25_kill_by_device(). Finally, the decrements of refcounts in ax25_kill_by_device() will not be executed, because no s->ax25_dev equals to ax25_dev in position (4). This patch adds decrements of refcounts in ax25_release() and use lock_sock() to do synchronization. If refcounts decrease in ax25_release(), the decrements of refcounts in ax25_kill_by_device() will not be executed and vice versa. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Fixes: 87563a043cef ("ax25: fix reference count leaks of ax25_dev") Fixes: feef318c855a ("ax25: fix UAF bugs of net_device caused by rebinding operation") Reported-by: Thomas Osterried Signed-off-by: Duoming Zhou Signed-off-by: David S. Miller [OP: backport to 5.15: adjust dev_put_track()->dev_put()] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit b982492ec3a115e0a136856a1b2dbe32f2d21a0e Author: Duoming Zhou Date: Fri Apr 15 19:14:17 2022 +0300 ax25: fix UAF bugs of net_device caused by rebinding operation commit feef318c855a361a1eccd880f33e88c460eb63b4 upstream. The ax25_kill_by_device() will set s->ax25_dev = NULL and call ax25_disconnect() to change states of ax25_cb and sock, if we call ax25_bind() before ax25_kill_by_device(). However, if we call ax25_bind() again between the window of ax25_kill_by_device() and ax25_dev_device_down(), the values and states changed by ax25_kill_by_device() will be reassigned. Finally, ax25_dev_device_down() will deallocate net_device. If we dereference net_device in syscall functions such as ax25_release(), ax25_sendmsg(), ax25_getsockopt(), ax25_getname() and ax25_info_show(), a UAF bug will occur. One of the possible race conditions is shown below: (USE) | (FREE) ax25_bind() | | ax25_kill_by_device() ax25_bind() | ax25_connect() | ... | ax25_dev_device_down() | ... | dev_put_track(dev, ...) //FREE ax25_release() | ... ax25_send_control() | alloc_skb() //USE | the corresponding fail log is shown below: =============================================================== BUG: KASAN: use-after-free in ax25_send_control+0x43/0x210 ... Call Trace: ... ax25_send_control+0x43/0x210 ax25_release+0x2db/0x3b0 __sock_release+0x6d/0x120 sock_close+0xf/0x20 __fput+0x11f/0x420 ... Allocated by task 1283: ... __kasan_kmalloc+0x81/0xa0 alloc_netdev_mqs+0x5a/0x680 mkiss_open+0x6c/0x380 tty_ldisc_open+0x55/0x90 ... Freed by task 1969: ... kfree+0xa3/0x2c0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 tty_ldisc_kill+0x3e/0x80 ... In order to fix these UAF bugs caused by rebinding operation, this patch adds dev_hold_track() into ax25_bind() and corresponding dev_put_track() into ax25_kill_by_device(). Signed-off-by: Duoming Zhou Signed-off-by: David S. Miller [OP: backport to 5.15: adjust dev_put_track()->dev_put() and dev_hold_track()->dev_hold()] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit bc706d89199b0d8ee5e2229e18fdb9c0720f6ba8 Author: Duoming Zhou Date: Fri Apr 15 19:14:16 2022 +0300 ax25: fix reference count leaks of ax25_dev commit 87563a043cef044fed5db7967a75741cc16ad2b1 upstream. The previous commit d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") introduces refcount into ax25_dev, but there are reference leak paths in ax25_ctl_ioctl(), ax25_fwd_ioctl(), ax25_rt_add(), ax25_rt_del() and ax25_rt_opt(). This patch uses ax25_dev_put() and adjusts the position of ax25_addr_ax25dev() to fix reference cout leaks of ax25_dev. Fixes: d01ffb9eee4a ("ax25: add refcount in ax25_dev to avoid UAF bugs") Signed-off-by: Duoming Zhou Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20220203150811.42256-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski [OP: backport to 5.15: adjust context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit 9af0fd5c4453a44c692be0cbb3724859b75d739b Author: Duoming Zhou Date: Fri Apr 15 19:14:15 2022 +0300 ax25: add refcount in ax25_dev to avoid UAF bugs commit d01ffb9eee4af165d83b08dd73ebdf9fe94a519b upstream. If we dereference ax25_dev after we call kfree(ax25_dev) in ax25_dev_device_down(), it will lead to concurrency UAF bugs. There are eight syscall functions suffer from UAF bugs, include ax25_bind(), ax25_release(), ax25_connect(), ax25_ioctl(), ax25_getname(), ax25_sendmsg(), ax25_getsockopt() and ax25_info_show(). One of the concurrency UAF can be shown as below: (USE) | (FREE) | ax25_device_event | ax25_dev_device_down ax25_bind | ... ... | kfree(ax25_dev) ax25_fillin_cb() | ... ax25_fillin_cb_from_dev() | ... | The root cause of UAF bugs is that kfree(ax25_dev) in ax25_dev_device_down() is not protected by any locks. When ax25_dev, which there are still pointers point to, is released, the concurrency UAF bug will happen. This patch introduces refcount into ax25_dev in order to guarantee that there are no pointers point to it when ax25_dev is released. Signed-off-by: Duoming Zhou Signed-off-by: David S. Miller [OP: backport to 5.15: adjusted context] Signed-off-by: Ovidiu Panait Signed-off-by: Greg Kroah-Hartman commit de6a76eea645f7311730b8284ee309bc94e82118 Author: Srinivas Pandruvada Date: Thu Nov 18 21:18:01 2021 -0800 cpufreq: intel_pstate: ITMT support for overclocked system commit 03c83982a0278207709143ba78c5a470179febee upstream. On systems with overclocking enabled, CPPC Highest Performance can be hard coded to 0xff. In this case even if we have cores with different highest performance, ITMT can't be enabled as the current implementation depends on CPPC Highest Performance. On such systems we can use MSR_HWP_CAPABILITIES maximum performance field when CPPC.Highest Performance is 0xff. Due to legacy reasons, we can't solely depend on MSR_HWP_CAPABILITIES as in some older systems CPPC Highest Performance is the only way to identify different performing cores. Reported-by: Michael Larabel Signed-off-by: Srinivas Pandruvada Tested-by: Michael Larabel Signed-off-by: Rafael J. Wysocki Signed-off-by: Dimitri John Ledkov Signed-off-by: Greg Kroah-Hartman commit 74d23d422556040a9848323ee48c6e73880a2ba2 Author: Alex Elder Date: Fri Feb 25 14:15:30 2022 -0600 net: ipa: fix a build dependency commit caef14b7530c065fb85d54492768fa48fdb5093e upstream. An IPA build problem arose in the linux-next tree the other day. The problem is that a recent commit adds a new dependency on some code, and the Kconfig file for IPA doesn't reflect that dependency. As a result, some configurations can fail to build (particularly when COMPILE_TEST is enabled). The recent patch adds calls to qmp_get(), qmp_put(), and qmp_send(), and those are built based on the QCOM_AOSS_QMP config option. If that symbol is not defined, stubs are defined, so we just need to ensure QCOM_AOSS_QMP is compatible with QCOM_IPA, or it's not defined. Reported-by: Randy Dunlap Fixes: 34a081761e4e3 ("net: ipa: request IPA register values be retained") Signed-off-by: Alex Elder Tested-by: Randy Dunlap Acked-by: Randy Dunlap Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1648c7b450d8f19367f32dfb452d4a854ddf5561 Author: Miaoqian Lin Date: Sat Jan 8 09:59:31 2022 +0000 soc: qcom: aoss: Fix missing put_device call in qmp_get commit 4b41a9d0fe3db5f91078a380f62f0572c3ecf2dd upstream. The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling paths. Fixes: 8c75d585b931 ("soc: qcom: aoss: Expose send for generic usecase") Signed-off-by: Miaoqian Lin Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20220108095931.21527-1-linmq006@gmail.com Signed-off-by: Greg Kroah-Hartman commit d712aea3cd81f0a42b266c765cc312b03fb55e6e Author: Steven Price Date: Mon Apr 11 16:22:32 2022 +0100 cpu/hotplug: Remove the 'cpu' member of cpuhp_cpu_state commit b7ba6d8dc3569e49800ef0136799f26f43e237e8 upstream. Currently the setting of the 'cpu' member of struct cpuhp_cpu_state in cpuhp_create() is too late as it is used earlier in _cpu_up(). If kzalloc_node() in __smpboot_create_thread() fails then the rollback will be done with st->cpu==0 causing CPU0 to be erroneously set to be dying, causing the scheduler to get mightily confused and throw its toys out of the pram. However the cpu number is actually available directly, so simply remove the 'cpu' member and avoid the problem in the first place. Fixes: 2ea46c6fc945 ("cpumask/hotplug: Fix cpu_dying() state tracking") Signed-off-by: Steven Price Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220411152233.474129-2-steven.price@arm.com Signed-off-by: Greg Kroah-Hartman commit 14785927a1d46817b1648806ed5124be049bea75 Author: Matt Roper Date: Thu Apr 7 09:18:39 2022 -0700 drm/i915: Sunset igpu legacy mmap support based on GRAPHICS_VER_FULL commit 1acb34e7dd7720a1fff00cbd4d000ec3219dc9d6 upstream. The intent of the version check in the mmap ioctl was to maintain support for existing platforms (i.e., ADL/RPL and earlier), but drop support on all future igpu platforms. As we've seen on the dgpu side, the hardware teams are using a more fine-grained numbering system for IP version numbers these days, so it's possible the version number associated with our next igpu could be some form of "12.xx" rather than 13 or higher. Comparing against the full ver.release number will ensure the intent of the check is maintained no matter what numbering the hardware teams settle on. Fixes: d3f3baa3562a ("drm/i915: Reinstate the mmap ioctl for some platforms") Cc: Thomas Hellström Cc: Lucas De Marchi Signed-off-by: Matt Roper Reviewed-by: Lucas De Marchi Link: https://patchwork.freedesktop.org/patch/msgid/20220407161839.1073443-1-matthew.d.roper@intel.com (cherry picked from commit 8e7e5c077cd57ee9a36d58c65f07257dc49a88d5) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 4ef9951d0252cba5f652806b82837ba27da4e217 Author: Chao Gao Date: Wed Apr 13 08:32:22 2022 +0200 dma-direct: avoid redundant memory sync for swiotlb commit 9e02977bfad006af328add9434c8bffa40e053bb upstream. When we looked into FIO performance with swiotlb enabled in VM, we found swiotlb_bounce() is always called one more time than expected for each DMA read request. It turns out that the bounce buffer is copied to original DMA buffer twice after the completion of a DMA request (one is done by in dma_direct_sync_single_for_cpu(), the other by swiotlb_tbl_unmap_single()). But the content in bounce buffer actually doesn't change between the two rounds of copy. So, one round of copy is redundant. Pass DMA_ATTR_SKIP_CPU_SYNC flag to swiotlb_tbl_unmap_single() to skip the memory copy in it. This fix increases FIO 64KB sequential read throughput in a guest with swiotlb=force by 5.6%. Fixes: 55897af63091 ("dma-direct: merge swiotlb_dma_ops into the dma_direct code") Reported-by: Wang Zhaoyang1 Reported-by: Gao Liang Signed-off-by: Chao Gao Reviewed-by: Kevin Tian Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 111becd63e37139fb5c3f45bf887607e2df70c2c Author: Anna-Maria Behnsen Date: Tue Apr 5 21:17:32 2022 +0200 timers: Fix warning condition in __run_timers() commit c54bc0fc84214b203f7a0ebfd1bd308ce2abe920 upstream. When the timer base is empty, base::next_expiry is set to base::clk + NEXT_TIMER_MAX_DELTA and base::next_expiry_recalc is false. When no timer is queued until jiffies reaches base::next_expiry value, the warning for not finding any expired timer and base::next_expiry_recalc is false in __run_timers() triggers. To prevent triggering the warning in this valid scenario base::timers_pending needs to be added to the warning condition. Fixes: 31cd0e119d50 ("timers: Recalculate next timer interrupt only when necessary") Reported-by: Johannes Berg Signed-off-by: Anna-Maria Behnsen Signed-off-by: Thomas Gleixner Reviewed-by: Frederic Weisbecker Link: https://lore.kernel.org/r/20220405191732.7438-3-anna-maria@linutronix.de Signed-off-by: Greg Kroah-Hartman commit cbdd7a33c533e03404d51071af1e056ce3716caf Author: Dongjin Yang Date: Mon Apr 4 11:28:57 2022 +0900 dt-bindings: net: snps: remove duplicate name commit ce8b3ad1071b764e963d9b08ac34ffddddf12da6 upstream. snps,dwmac has duplicated name for loongson,ls2k-dwmac and loongson,ls7a-dwmac. Signed-off-by: Dongjin Yang Fixes: 68277749a013 ("dt-bindings: dwmac: Add bindings for new Loongson SoC and bridge chip") Reviewed-by: Krzysztof Kozlowski Signed-off-by: Rob Herring Link: https://lore.kernel.org/r/20220404022857epcms1p6e6af1a6a86569f339e50c318abde7d3c@epcms1p6 Signed-off-by: Greg Kroah-Hartman commit 83a4c1080e09d2b3ffec81dfd1abd0d9b277a77a Author: Martin Povišer Date: Tue Mar 29 20:38:17 2022 +0200 i2c: pasemi: Wait for write xfers to finish commit bd8963e602c77adc76dbbbfc3417c3cf14fed76b upstream. Wait for completion of write transfers before returning from the driver. At first sight it may seem advantageous to leave write transfers queued for the controller to carry out on its own time, but there's a couple of issues with it: * Driver doesn't check for FIFO space. * The queued writes can complete while the driver is in its I2C read transfer path which means it will get confused by the raising of XEN (the 'transaction ended' signal). This can cause a spurious ENODATA error due to premature reading of the MRXFIFO register. Adding the wait fixes some unreliability issues with the driver. There's some efficiency cost to it (especially with pasemi_smb_waitready doing its polling), but that will be alleviated once the driver receives interrupt support. Fixes: beb58aa39e6e ("i2c: PA Semi SMBus driver") Signed-off-by: Martin Povišer Reviewed-by: Sven Peter Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 44981e4cde6867167f0997e0bdcc76e61e2c9229 Author: Nadav Amit Date: Sat Mar 19 00:20:15 2022 -0700 smp: Fix offline cpu check in flush_smp_call_function_queue() commit 9e949a3886356fe9112c6f6f34a6e23d1d35407f upstream. The check in flush_smp_call_function_queue() for callbacks that are sent to offline CPUs currently checks whether the queue is empty. However, flush_smp_call_function_queue() has just deleted all the callbacks from the queue and moved all the entries into a local list. This checks would only be positive if some callbacks were added in the short time after llist_del_all() was called. This does not seem to be the intention of this check. Change the check to look at the local list to which the entries were moved instead of the queue from which all the callbacks were just removed. Fixes: 8d056c48e4862 ("CPU hotplug, smp: flush any pending IPI callbacks before CPU offline") Signed-off-by: Nadav Amit Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20220319072015.1495036-1-namit@vmware.com Signed-off-by: Greg Kroah-Hartman commit 2f345bb14ad4744950499ff222e2899209297afa Author: Andy Shevchenko Date: Mon Apr 11 21:07:51 2022 +0300 i2c: dev: check return value when calling dev_set_name() commit 993eb48fa199b5f476df8204e652eff63dd19361 upstream. If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Fixes: 1413ef638aba ("i2c: dev: Fix the race between the release of i2c_dev and cdev") Signed-off-by: Andy Shevchenko Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman commit 6b4bf97587ef6c1927a78934b700204920655123 Author: Mikulas Patocka Date: Sun Apr 3 14:38:22 2022 -0400 dm integrity: fix memory corruption when tag_size is less than digest size commit 08c1af8f1c13bbf210f1760132f4df24d0ed46d6 upstream. It is possible to set up dm-integrity in such a way that the "tag_size" parameter is less than the actual digest size. In this situation, a part of the digest beyond tag_size is ignored. In this case, dm-integrity would write beyond the end of the ic->recalc_tags array and corrupt memory. The corruption happened in integrity_recalc->integrity_sector_checksum->crypto_shash_final. Fix this corruption by increasing the tags array so that it has enough padding at the end to accomodate the loop in integrity_recalc() being able to write a full digest size for the last member of the tags array. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit 0940795c6834fbe7705acc5c3d4b2f7a5f67527a Author: Nathan Chancellor Date: Thu Dec 23 15:21:41 2021 -0700 ARM: davinci: da850-evm: Avoid NULL pointer dereference commit 83a1cde5c74bfb44b49cb2a940d044bb2380f4ea upstream. With newer versions of GCC, there is a panic in da850_evm_config_emac() when booting multi_v5_defconfig in QEMU under the palmetto-bmc machine: Unable to handle kernel NULL pointer dereference at virtual address 00000020 pgd = (ptrval) [00000020] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 5.15.0 #1 Hardware name: Generic DT based system PC is at da850_evm_config_emac+0x1c/0x120 LR is at do_one_initcall+0x50/0x1e0 The emac_pdata pointer in soc_info is NULL because davinci_soc_info only gets populated on davinci machines but da850_evm_config_emac() is called on all machines via device_initcall(). Move the rmii_en assignment below the machine check so that it is only dereferenced when running on a supported SoC. Fixes: bae105879f2f ("davinci: DA850/OMAP-L138 EVM: implement autodetect of RMII PHY") Signed-off-by: Nathan Chancellor Reviewed-by: Arnd Bergmann Reviewed-by: Bartosz Golaszewski Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/YcS4xVWs6bQlQSPC@archlinux-ax161/ Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 68a38b07f1259ec90cf34e7102e63fb1447acef2 Author: Paul Gortmaker Date: Mon Dec 6 09:59:50 2021 -0500 tick/nohz: Use WARN_ON_ONCE() to prevent console saturation commit 40e97e42961f8c6cc7bd5fe67cc18417e02d78f1 upstream. While running some testing on code that happened to allow the variable tick_nohz_full_running to get set but with no "possible" NOHZ cores to back up that setting, this warning triggered: if (unlikely(tick_do_timer_cpu == TICK_DO_TIMER_NONE)) WARN_ON(tick_nohz_full_running); The console was overwhemled with an endless stream of one WARN per tick per core and there was no way to even see what was going on w/o using a serial console to capture it and then trace it back to this. Change it to WARN_ON_ONCE(). Fixes: 08ae95f4fd3b ("nohz_full: Allow the boot CPU to be nohz_full") Signed-off-by: Paul Gortmaker Signed-off-by: Thomas Gleixner Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211206145950.10927-3-paul.gortmaker@windriver.com Signed-off-by: Greg Kroah-Hartman commit c11ef9ded22eb40498af77f5d2517dd4690bb5ed Author: Rei Yamamoto Date: Thu Mar 31 09:33:09 2022 +0900 genirq/affinity: Consider that CPUs on nodes can be unbalanced commit 08d835dff916bfe8f45acc7b92c7af6c4081c8a7 upstream. If CPUs on a node are offline at boot time, the number of nodes is different when building affinity masks for present cpus and when building affinity masks for possible cpus. This causes the following problem: In the case that the number of vectors is less than the number of nodes there are cases where bits of masks for present cpus are overwritten when building masks for possible cpus. Fix this by excluding CPUs, which are not part of the current build mask (present/possible). [ tglx: Massaged changelog and added comment ] Fixes: b82592199032 ("genirq/affinity: Spread IRQs to all available NUMA nodes") Signed-off-by: Rei Yamamoto Signed-off-by: Thomas Gleixner Reviewed-by: Ming Lei Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220331003309.10891-1-yamamoto.rei@jp.fujitsu.com Signed-off-by: Greg Kroah-Hartman commit c61d929944c9e9df3cd03b8df9e248fe5962b23e Author: Pawan Gupta Date: Thu Mar 10 14:02:09 2022 -0800 x86/tsx: Disable TSX development mode at boot commit 400331f8ffa3bec5c561417e5eec6848464e9160 upstream. A microcode update on some Intel processors causes all TSX transactions to always abort by default[*]. Microcode also added functionality to re-enable TSX for development purposes. With this microcode loaded, if tsx=on was passed on the cmdline, and TSX development mode was already enabled before the kernel boot, it may make the system vulnerable to TSX Asynchronous Abort (TAA). To be on safer side, unconditionally disable TSX development mode during boot. If a viable use case appears, this can be revisited later. [*]: Intel TSX Disable Update for Selected Processors, doc ID: 643557 [ bp: Drop unstable web link, massage heavily. ] Suggested-by: Andrew Cooper Suggested-by: Borislav Petkov Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Tested-by: Neelima Krishnan Cc: Link: https://lore.kernel.org/r/347bd844da3a333a9793c6687d4e4eb3b2419a3e.1646943780.git.pawan.kumar.gupta@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit aaf27fcaefc15ea51bb2fef550f17c5b71032041 Author: Pawan Gupta Date: Thu Mar 10 14:00:59 2022 -0800 x86/tsx: Use MSR_TSX_CTRL to clear CPUID bits commit 258f3b8c3210b03386e4ad92b4bd8652b5c1beb3 upstream. tsx_clear_cpuid() uses MSR_TSX_FORCE_ABORT to clear CPUID.RTM and CPUID.HLE. Not all CPUs support MSR_TSX_FORCE_ABORT, alternatively use MSR_IA32_TSX_CTRL when supported. [ bp: Document how and why TSX gets disabled. ] Fixes: 293649307ef9 ("x86/tsx: Clear CPUID bits when TSX always force aborts") Reported-by: kernel test robot Signed-off-by: Pawan Gupta Signed-off-by: Borislav Petkov Tested-by: Neelima Krishnan Cc: Link: https://lore.kernel.org/r/5b323e77e251a9c8bcdda498c5cc0095be1e1d3c.1646943780.git.pawan.kumar.gupta@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2dd7d2eddf8e1ff3556e333979af99e4c167a7b5 Author: Tomasz Moń Date: Wed Apr 6 21:49:21 2022 +0200 drm/amdgpu: Enable gfxoff quirk on MacBook Pro commit 4593c1b6d159f1e5c35c07a7f125e79e5a864302 upstream. Enabling gfxoff quirk results in perfectly usable graphical user interface on MacBook Pro (15-inch, 2019) with Radeon Pro Vega 20 4 GB. Without the quirk, X server is completely unusable as every few seconds there is gpu reset due to ring gfx timeout. Signed-off-by: Tomasz Moń Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 804c096d640ece718d6505c5252eb66544bbc2c9 Author: Melissa Wen Date: Tue Mar 29 19:18:35 2022 -0100 drm/amd/display: don't ignore alpha property on pre-multiplied mode commit e4f1541caf60fcbe5a59e9d25805c0b5865e546a upstream. "Pre-multiplied" is the default pixel blend mode for KMS/DRM, as documented in supported_modes of drm_plane_create_blend_mode_property(): https://cgit.freedesktop.org/drm/drm-misc/tree/drivers/gpu/drm/drm_blend.c In this mode, both 'pixel alpha' and 'plane alpha' participate in the calculation, as described by the pixel blend mode formula in KMS/DRM documentation: out.rgb = plane_alpha * fg.rgb + (1 - (plane_alpha * fg.alpha)) * bg.rgb Considering the blend config mechanisms we have in the driver so far, the alpha mode that better fits this blend mode is the _PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN, where the value for global_gain is the plane alpha (global_alpha). With this change, alpha property stops to be ignored. It also addresses Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1734 v2: * keep the 8-bit value for global_alpha_value (Nicholas) * correct the logical ordering for combined global gain (Nicholas) * apply to dcn10 too (Nicholas) Signed-off-by: Melissa Wen Tested-by: Rodrigo Siqueira Reviewed-by: Harry Wentland Tested-by: Simon Ser Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit adee01bbf6cb5b3e4ed08be8ff866aac90f13836 Author: Nicolas Dichtel Date: Fri Apr 8 16:03:42 2022 +0200 ipv6: fix panic when forwarding a pkt with no in6 dev commit e3fa461d8b0e185b7da8a101fe94dfe6dd500ac0 upstream. kongweibin reported a kernel panic in ip6_forward() when input interface has no in6 dev associated. The following tc commands were used to reproduce this panic: tc qdisc del dev vxlan100 root tc qdisc add dev vxlan100 root netem corrupt 5% CC: stable@vger.kernel.org Fixes: ccd27f05ae7b ("ipv6: fix 'disable_policy' for fwd packets") Reported-by: kongweibin Signed-off-by: Nicolas Dichtel Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cab64cb82fe1a2436bb7991cb628d76de3c44751 Author: Johannes Berg Date: Mon Apr 11 11:42:03 2022 +0200 nl80211: correctly check NL80211_ATTR_REG_ALPHA2 size commit 6624bb34b4eb19f715db9908cca00122748765d7 upstream. We need this to be at least two bytes, so we can access alpha2[0] and alpha2[1]. It may be three in case some userspace used NUL-termination since it was NLA_STRING (and we also push it out with NUL-termination). Cc: stable@vger.kernel.org Reported-by: Lee Jones Link: https://lore.kernel.org/r/20220411114201.fd4a31f06541.Ie7ff4be2cf348d8cc28ed0d626fc54becf7ea799@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 63038f6e96a77a0abf8083649c53e6a72c1a0124 Author: Fabio M. De Francesco Date: Sat Apr 9 03:26:55 2022 +0200 ALSA: pcm: Test for "silence" field in struct "pcm_format_data" commit 2f7a26abb8241a0208c68d22815aa247c5ddacab upstream. Syzbot reports "KASAN: null-ptr-deref Write in snd_pcm_format_set_silence".[1] It is due to missing validation of the "silence" field of struct "pcm_format_data" in "pcm_formats" array. Add a test for valid "pat" and, if it is not so, return -EINVAL. [1] https://lore.kernel.org/lkml/000000000000d188ef05dc2c7279@google.com/ Reported-and-tested-by: syzbot+205eb15961852c2c5974@syzkaller.appspotmail.com Signed-off-by: Fabio M. De Francesco Cc: Link: https://lore.kernel.org/r/20220409012655.9399-1-fmdefrancesco@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a53062c94b8c7878850eef46c7022c362bc5ab7f Author: Tao Jin Date: Sat Apr 9 18:44:24 2022 -0400 ALSA: hda/realtek: add quirk for Lenovo Thinkpad X12 speakers commit 264fb03497ec1c7841bba872571bcd11beed57a7 upstream. For this specific device on Lenovo Thinkpad X12 tablet, the verbs were dumped by qemu running a guest OS that init this codec properly. After studying the dump, it turns out that the same quirk used by the other Lenovo devices can be reused. The patch was tested working against the mainline kernel. Cc: Signed-off-by: Tao Jin Link: https://lore.kernel.org/r/CO6PR03MB6241CD73310B37858FE64C85E1E89@CO6PR03MB6241.namprd03.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0349df521528e6b9dce8c3330233ff3b9587c7f5 Author: Tim Crawford Date: Tue Apr 5 12:20:29 2022 -0600 ALSA: hda/realtek: Add quirk for Clevo PD50PNT commit 9eb6f5c388060d8cef3c8b616cc31b765e022359 upstream. Fixes speaker output and headset detection on Clevo PD50PNT. Signed-off-by: Tim Crawford Cc: Link: https://lore.kernel.org/r/20220405182029.27431-1-tcrawford@system76.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3680b48533aec77fd21875c0c11398e1c2774f1e Author: Naohiro Aota Date: Tue Mar 29 15:55:58 2022 +0900 btrfs: mark resumed async balance as writing commit a690e5f2db4d1dca742ce734aaff9f3112d63764 upstream. When btrfs balance is interrupted with umount, the background balance resumes on the next mount. There is a potential deadlock with FS freezing here like as described in commit 26559780b953 ("btrfs: zoned: mark relocation as writing"). Mark the process as sb_writing to avoid it. Reviewed-by: Filipe Manana CC: stable@vger.kernel.org # 4.9+ Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 252db93fd0bd5ca07c9b933ed94e93a4a43e8901 Author: Jia-Ju Bai Date: Thu Mar 24 06:44:54 2022 -0700 btrfs: fix root ref counts in error handling in btrfs_get_root_ref commit 168a2f776b9762f4021421008512dd7ab7474df1 upstream. In btrfs_get_root_ref(), when btrfs_insert_fs_root() fails, btrfs_put_root() can happen for two reasons: - the root already exists in the tree, in that case it returns the reference obtained in btrfs_lookup_fs_root() - another error so the cleanup is done in the fail label Calling btrfs_put_root() unconditionally would lead to double decrement of the root reference possibly freeing it in the second case. Reported-by: TOTE Robot Fixes: bc44d7c4b2b1 ("btrfs: push btrfs_grab_fs_root into btrfs_get_fs_root") CC: stable@vger.kernel.org # 5.10+ Signed-off-by: Jia-Ju Bai Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 9b81c2c147e14abf6181271758c4c29353e20367 Author: Toke Høiland-Jørgensen Date: Mon Apr 4 22:48:00 2022 +0200 ath9k: Fix usage of driver-private space in tx_info commit 5a6b06f5927c940fa44026695779c30b7536474c upstream. The ieee80211_tx_info_clear_status() helper also clears the rate counts and the driver-private part of struct ieee80211_tx_info, so using it breaks quite a few other things. So back out of using it, and instead define a ath-internal helper that only clears the area between the status_driver_data and the rates info. Combined with moving the ath_frame_info struct to status_driver_data, this avoids clearing anything we shouldn't be, and so we can keep the existing code for handling the rate information. While fixing this I also noticed that the setting of tx_info->status.rates[tx_rateindex].count on hardware underrun errors was always immediately overridden by the normal setting of the same fields, so rearrange the code so that the underrun detection actually takes effect. The new helper could be generalised to a 'memset_between()' helper, but leave it as a driver-internal helper for now since this needs to go to stable. Cc: stable@vger.kernel.org Reported-by: Peter Seiderer Fixes: 037250f0a45c ("ath9k: Properly clear TX status area before reporting to mac80211") Signed-off-by: Toke Høiland-Jørgensen Reviewed-by: Peter Seiderer Tested-by: Peter Seiderer Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220404204800.2681133-1-toke@toke.dk Signed-off-by: Greg Kroah-Hartman commit 3386927f436e6c513a885c2b9adc85bcec8fdf2c Author: Toke Høiland-Jørgensen Date: Wed Mar 30 18:44:09 2022 +0200 ath9k: Properly clear TX status area before reporting to mac80211 commit 037250f0a45cf9ecf5b52d4b9ff8eadeb609c800 upstream. The ath9k driver was not properly clearing the status area in the ieee80211_tx_info struct before reporting TX status to mac80211. Instead, it was manually filling in fields, which meant that fields introduced later were left as-is. Conveniently, mac80211 actually provides a helper to zero out the status area, so use that to make sure we zero everything. The last commit touching the driver function writing the status information seems to have actually been fixing an issue that was also caused by the area being uninitialised; but it only added clearing of a single field instead of the whole struct. That is now redundant, though, so revert that commit and use it as a convenient Fixes tag. Fixes: cc591d77aba1 ("ath9k: Make sure to zero status.tx_time before reporting TX status") Reported-by: Bagas Sanjaya Cc: Signed-off-by: Toke Høiland-Jørgensen Tested-by: Bagas Sanjaya Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20220330164409.16645-1-toke@toke.dk Signed-off-by: Greg Kroah-Hartman commit 7a509a9f2bb7b7edce6e26242fceaf0d212369f9 Author: Ronnie Sahlberg Date: Wed Apr 13 10:02:17 2022 +1000 cifs: verify that tcon is valid before dereference in cifs_kill_sb commit 8b6c58458ee3206dde345fce327a4cb83e69caf9 upstream. On umount, cifs_sb->tlink_tree might contain entries that do not represent a valid tcon. Check the tcon for error before we dereference it. Signed-off-by: Ronnie Sahlberg Cc: stable@vger.kernel.org Reviewed-by: Shyam Prasad N Reported-by: Xiaoli Feng Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit bd17422b9b675414d0f1a5e070d42fe85b785cd6 Author: Jason A. Donenfeld Date: Wed Apr 6 00:28:15 2022 +0200 gcc-plugins: latent_entropy: use /dev/urandom commit c40160f2998c897231f8454bf797558d30a20375 upstream. While the latent entropy plugin mostly doesn't derive entropy from get_random_const() for measuring the call graph, when __latent_entropy is applied to a constant, then it's initialized statically to output from get_random_const(). In that case, this data is derived from a 64-bit seed, which means a buffer of 512 bits doesn't really have that amount of compile-time entropy. This patch fixes that shortcoming by just buffering chunks of /dev/urandom output and doling it out as requested. At the same time, it's important that we don't break the use of -frandom-seed, for people who want the runtime benefits of the latent entropy plugin, while still having compile-time determinism. In that case, we detect whether gcc's set_random_seed() has been called by making a call to get_random_seed(noinit=true) in the plugin init function, which is called after set_random_seed() is called but before anything that calls get_random_seed(noinit=false), and seeing if it's zero or not. If it's not zero, we're in deterministic mode, and so we just generate numbers with a basic xorshift prng. Note that we don't detect if -frandom-seed is being used using the documented local_tick variable, because it's assigned via: local_tick = (unsigned) tv.tv_sec * 1000 + tv.tv_usec / 1000; which may well overflow and become -1 on its own, and so isn't reliable: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171 [kees: The 256 byte rnd_buf size was chosen based on average (250), median (64), and std deviation (575) bytes of used entropy for a defconfig x86_64 build] Fixes: 38addce8b600 ("gcc-plugins: Add latent_entropy plugin") Cc: stable@vger.kernel.org Cc: PaX Team Signed-off-by: Jason A. Donenfeld Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220405222815.21155-1-Jason@zx2c4.com Signed-off-by: Greg Kroah-Hartman commit 05d1824a7fb43ab9adb1eb82404954af81d8c984 Author: Johan Hovold Date: Thu Mar 3 19:06:32 2022 +0100 memory: renesas-rpc-if: fix platform-device leak in error path commit b452dbf24d7d9a990d70118462925f6ee287d135 upstream. Make sure to free the flash platform device in the event that registration fails during probe. Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Cc: stable@vger.kernel.org # 5.8 Cc: Sergei Shtylyov Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20220303180632.3194-1-johan@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit f5e13d700a4d40ccde3d36e383f9247dcb3c1d2d Author: Chuck Lever Date: Fri Apr 1 17:08:21 2022 -0400 SUNRPC: Fix NFSD's request deferral on RDMA transports commit 773f91b2cf3f52df0d7508fdbf60f37567cdaee4 upstream. Trond Myklebust reports an NFSD crash in svc_rdma_sendto(). Further investigation shows that the crash occurred while NFSD was handling a deferred request. This patch addresses two inter-related issues that prevent request deferral from working correctly for RPC/RDMA requests: 1. Prevent the crash by ensuring that the original svc_rqst::rq_xprt_ctxt value is available when the request is revisited. Otherwise svc_rdma_sendto() does not have a Receive context available with which to construct its reply. 2. Possibly since before commit 71641d99ce03 ("svcrdma: Properly compute .len and .buflen for received RPC Calls"), svc_rdma_recvfrom() did not include the transport header in the returned xdr_buf. There should have been no need for svc_defer() and friends to save and restore that header, as of that commit. This issue is addressed in a backport-friendly way by simply having svc_rdma_recvfrom() set rq_xprt_hlen to zero unconditionally, just as svc_tcp_recvfrom() does. This enables svc_deferred_recv() to correctly reconstruct an RPC message received via RPC/RDMA. Reported-by: Trond Myklebust Link: https://lore.kernel.org/linux-nfs/82662b7190f26fb304eb0ab1bb04279072439d4e.camel@hammerspace.com/ Signed-off-by: Chuck Lever Cc: Signed-off-by: Greg Kroah-Hartman commit 00715427ea778b45a6d2bf2c20bbdff33b44d3f6 Author: Sean Christopherson Date: Thu Mar 31 22:13:59 2022 +0000 KVM: x86/mmu: Resolve nx_huge_pages when kvm.ko is loaded commit 1d0e84806047f38027d7572adb4702ef7c09b317 upstream. Resolve nx_huge_pages to true/false when kvm.ko is loaded, leaving it as -1 is technically undefined behavior when its value is read out by param_get_bool(), as boolean values are supposed to be '0' or '1'. Alternatively, KVM could define a custom getter for the param, but the auto value doesn't depend on the vendor module in any way, and printing "auto" would be unnecessarily unfriendly to the user. In addition to fixing the undefined behavior, resolving the auto value also fixes the scenario where the auto value resolves to N and no vendor module is loaded. Previously, -1 would result in Y being printed even though KVM would ultimately disable the mitigation. Rename the existing MMU module init/exit helpers to clarify that they're invoked with respect to the vendor module, and add comments to document why KVM has two separate "module init" flows. ========================================================================= UBSAN: invalid-load in kernel/params.c:320:33 load of value 255 is not a valid value for type '_Bool' CPU: 6 PID: 892 Comm: tail Not tainted 5.17.0-rc3+ #799 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x34/0x44 ubsan_epilogue+0x5/0x40 __ubsan_handle_load_invalid_value.cold+0x43/0x48 param_get_bool.cold+0xf/0x14 param_attr_show+0x55/0x80 module_attr_show+0x1c/0x30 sysfs_kf_seq_show+0x93/0xc0 seq_read_iter+0x11c/0x450 new_sync_read+0x11b/0x1a0 vfs_read+0xf0/0x190 ksys_read+0x5f/0xe0 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae ========================================================================= Fixes: b8e8c8303ff2 ("kvm: mmu: ITLB_MULTIHIT mitigation") Cc: stable@vger.kernel.org Reported-by: Bruno Goncalves Reported-by: Jan Stancek Signed-off-by: Sean Christopherson Message-Id: <20220331221359.3912754-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 70ea5e7b38c30b60821e432abde6f3c359224139 Author: Patrick Wang Date: Thu Apr 14 19:14:04 2022 -0700 mm: kmemleak: take a full lowmem check in kmemleak_*_phys() commit 23c2d497de21f25898fbea70aeb292ab8acc8c94 upstream. The kmemleak_*_phys() apis do not check the address for lowmem's min boundary, while the caller may pass an address below lowmem, which will trigger an oops: # echo scan > /sys/kernel/debug/kmemleak Unable to handle kernel paging request at virtual address ff5fffffffe00000 Oops [#1] Modules linked in: CPU: 2 PID: 134 Comm: bash Not tainted 5.18.0-rc1-next-20220407 #33 Hardware name: riscv-virtio,qemu (DT) epc : scan_block+0x74/0x15c ra : scan_block+0x72/0x15c epc : ffffffff801e5806 ra : ffffffff801e5804 sp : ff200000104abc30 gp : ffffffff815cd4e8 tp : ff60000004cfa340 t0 : 0000000000000200 t1 : 00aaaaaac23954cc t2 : 00000000000003ff s0 : ff200000104abc90 s1 : ffffffff81b0ff28 a0 : 0000000000000000 a1 : ff5fffffffe01000 a2 : ffffffff81b0ff28 a3 : 0000000000000002 a4 : 0000000000000001 a5 : 0000000000000000 a6 : ff200000104abd7c a7 : 0000000000000005 s2 : ff5fffffffe00ff9 s3 : ffffffff815cd998 s4 : ffffffff815d0e90 s5 : ffffffff81b0ff28 s6 : 0000000000000020 s7 : ffffffff815d0eb0 s8 : ffffffffffffffff s9 : ff5fffffffe00000 s10: ff5fffffffe01000 s11: 0000000000000022 t3 : 00ffffffaa17db4c t4 : 000000000000000f t5 : 0000000000000001 t6 : 0000000000000000 status: 0000000000000100 badaddr: ff5fffffffe00000 cause: 000000000000000d scan_gray_list+0x12e/0x1a6 kmemleak_scan+0x2aa/0x57e kmemleak_write+0x32a/0x40c full_proxy_write+0x56/0x82 vfs_write+0xa6/0x2a6 ksys_write+0x6c/0xe2 sys_write+0x22/0x2a ret_from_syscall+0x0/0x2 The callers may not quite know the actual address they pass(e.g. from devicetree). So the kmemleak_*_phys() apis should guarantee the address they finally use is in lowmem range, so check the address for lowmem's min boundary. Link: https://lkml.kernel.org/r/20220413122925.33856-1-patrick.wang.shcn@gmail.com Signed-off-by: Patrick Wang Acked-by: Catalin Marinas Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 12ba1d38115a101c45d8e0ca3aa1181fd148e57f Author: Minchan Kim Date: Thu Apr 14 19:13:46 2022 -0700 mm: fix unexpected zeroed page mapping with zram swap commit e914d8f00391520ecc4495dd0ca0124538ab7119 upstream. Two processes under CLONE_VM cloning, user process can be corrupted by seeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed data The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't increase the refcount of swap slot at copy_mm so it couldn't catch up whether it's safe or not to discard data from backing device. In the case, only the lock it could rely on to synchronize swap slot freeing is page table lock. Thus, this patch gets rid of the swap_slot_free_notify function. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU B The concern of the patch would increase memory consumption since it could keep wasted memory with compressed form in zram as well as uncompressed form in address space. However, most of cases of zram uses no readahead and do_swap_page is followed by swap_free so it will free the compressed form from in zram quickly. Link: https://lkml.kernel.org/r/YjTVVxIAsnKAXjTd@google.com Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device") Reported-by: Ivan Babrou Tested-by: Ivan Babrou Signed-off-by: Minchan Kim Cc: Nitin Gupta Cc: Sergey Senozhatsky Cc: Jens Axboe Cc: David Hildenbrand Cc: [4.14+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bb7645c33869b20c5fdeed481a915ffa5b0e033a Author: Juergen Gross Date: Thu Apr 14 19:13:43 2022 -0700 mm, page_alloc: fix build_zonerefs_node() commit e553f62f10d93551eb883eca227ac54d1a4fad84 upstream. Since commit 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") only zones with free memory are included in a built zonelist. This is problematic when e.g. all memory of a zone has been ballooned out when zonelists are being rebuilt. The decision whether to rebuild the zonelists when onlining new memory is done based on populated_zone() returning 0 for the zone the memory will be added to. The new zone is added to the zonelists only, if it has free memory pages (managed_zone() returns a non-zero value) after the memory has been onlined. This implies, that onlining memory will always free the added pages to the allocator immediately, but this is not true in all cases: when e.g. running as a Xen guest the onlined new memory will be added only to the ballooned memory list, it will be freed only when the guest is being ballooned up afterwards. Another problem with using managed_zone() for the decision whether a zone is being added to the zonelists is, that a zone with all memory used will in fact be removed from all zonelists in case the zonelists happen to be rebuilt. Use populated_zone() when building a zonelist as it has been done before that commit. There was a report that QubesOS (based on Xen) is hitting this problem. Xen has switched to use the zone device functionality in kernel 5.9 and QubesOS wants to use memory hotplugging for guests in order to be able to start a guest with minimal memory and expand it as needed. This was the report leading to the patch. Link: https://lkml.kernel.org/r/20220407120637.9035-1-jgross@suse.com Fixes: 6aa303defb74 ("mm, vmscan: only allocate and reclaim from zones with pages managed by the buddy allocator") Signed-off-by: Juergen Gross Reported-by: Marek Marczykowski-Górecki Acked-by: Michal Hocko Acked-by: David Hildenbrand Cc: Marek Marczykowski-Górecki Reviewed-by: Wei Yang Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b6d17c67885a5624e96eb30c4178c65eea8374bf Author: Axel Rasmussen Date: Thu Apr 14 19:13:31 2022 -0700 mm/secretmem: fix panic when growing a memfd_secret commit f9b141f93659e09a52e28791ccbaf69c273b8e92 upstream. When one tries to grow an existing memfd_secret with ftruncate, one gets a panic [1]. For example, doing the following reliably induces the panic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20); The basic reason for this is, when we grow with ftruncate, we call down into simple_setattr, and then truncate_inode_pages_range, and eventually we try to zero part of the memory. The normal truncation code does this via the direct map (i.e., it calls page_address() and hands that to memset()). For memfd_secret though, we specifically don't map our pages via the direct map (i.e. we call set_direct_map_invalid_noflush() on every fault). So the address returned by page_address() isn't useful, and when we try to memset() with it we panic. This patch avoids the panic by implementing a custom setattr for memfd_secret, which detects resizes specifically (setting the size for the first time works just fine, since there are no existing pages to try to zero), and rejects them with EINVAL. One could argue growing should be supported, but I think that will require a significantly more lengthy change. So, I propose a minimal fix for the benefit of stable kernels, and then perhaps to extend memfd_secret to support growing in a separate patch. [1]: BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028 [lkp@intel.com: secretmem_iops can be static] Signed-off-by: kernel test robot [axelrasmussen@google.com: return EINVAL] Link: https://lkml.kernel.org/r/20220324210909.1843814-1-axelrasmussen@google.com Link: https://lkml.kernel.org/r/20220412193023.279320-1-axelrasmussen@google.com Signed-off-by: Axel Rasmussen Cc: Mike Rapoport Cc: Matthew Wilcox Cc: Cc: kernel test robot Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4cdf0e7a5be8fb50fb7d46a9ff1f8bdf2aa0f0f0 Author: Borislav Petkov Date: Tue Apr 5 17:15:15 2022 +0200 perf/imx_ddr: Fix undefined behavior due to shift overflowing the constant [ Upstream commit d02b4dd84e1a90f7f1444d027c0289bf355b0d5a ] Fix: In file included from :0:0: In function ‘ddr_perf_counter_enable’, inlined from ‘ddr_perf_irq_handler’ at drivers/perf/fsl_imx8_ddr_perf.c:651:2: ././include/linux/compiler_types.h:352:38: error: call to ‘__compiletime_assert_729’ \ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ... See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory details as to why it triggers with older gccs only. Signed-off-by: Borislav Petkov Cc: Frank Li Cc: Will Deacon Cc: Mark Rutland Cc: Shawn Guo Cc: Sascha Hauer Cc: Pengutronix Kernel Team Cc: Fabio Estevam Cc: NXP Linux Team Cc: linux-arm-kernel@lists.infradead.org Acked-by: Will Deacon Link: https://lore.kernel.org/r/20220405151517.29753-10-bp@alien8.de Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit b8ed0f7531f30c7ab5ee5e83b704fecb86acf3dc Author: Pavel Begunkov Date: Thu Apr 7 14:05:05 2022 +0100 io_uring: use nospec annotation for more indexes [ Upstream commit 4cdd158be9d09223737df83136a1fb65269d809a ] There are still several places that using pre array_index_nospec() indexes, fix them up. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/b01ef5ee83f72ed35ad525912370b729f5d145f4.1649336342.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5218d5cc02833e9495bba401d6af7d7801fb22cc Author: Pavel Begunkov Date: Thu Apr 7 14:05:04 2022 +0100 io_uring: zero tag on rsrc removal [ Upstream commit 8f0a24801bb44aa58496945aabb904c729176772 ] Automatically default rsrc tag in io_queue_rsrc_removal(), it's safer than leaving it there and relying on the rest of the code to behave and not use it. Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/1cf262a50df17478ea25b22494dcc19f3a80301f.1649336342.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit efb020924a71391fc12e6f204eaf25694cc116a1 Author: Duoming Zhou Date: Tue Apr 5 21:22:06 2022 +0800 drivers: net: slip: fix NPD bug in sl_tx_timeout() [ Upstream commit ec4eb8a86ade4d22633e1da2a7d85a846b7d1798 ] When a slip driver is detaching, the slip_close() will act to cleanup necessary resources and sl->tty is set to NULL in slip_close(). Meanwhile, the packet we transmit is blocked, sl_tx_timeout() will be called. Although slip_close() and sl_tx_timeout() use sl->lock to synchronize, we don`t judge whether sl->tty equals to NULL in sl_tx_timeout() and the null pointer dereference bug will happen. (Thread 1) | (Thread 2) | slip_close() | spin_lock_bh(&sl->lock) | ... ... | sl->tty = NULL //(1) sl_tx_timeout() | spin_unlock_bh(&sl->lock) spin_lock(&sl->lock); | ... | ... tty_chars_in_buffer(sl->tty)| if (tty->ops->..) //(2) | ... | synchronize_rcu() We set NULL to sl->tty in position (1) and dereference sl->tty in position (2). This patch adds check in sl_tx_timeout(). If sl->tty equals to NULL, sl_tx_timeout() will goto out. Signed-off-by: Duoming Zhou Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20220405132206.55291-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e455d7510db70c25e70d86279d107aa3a9273bd6 Author: Chandrakanth patil Date: Thu Mar 24 02:47:11 2022 -0700 scsi: megaraid_sas: Target with invalid LUN ID is deleted during scan [ Upstream commit 56495f295d8e021f77d065b890fc0100e3f9f6d8 ] The megaraid_sas driver supports single LUN for RAID devices. That is LUN 0. All other LUNs are unsupported. When a device scan on a logical target with invalid LUN number is invoked through sysfs, that target ends up getting removed. Add LUN ID validation in the slave destroy function to avoid the target deletion. Link: https://lore.kernel.org/r/20220324094711.48833-1-chandrakanth.patil@broadcom.com Signed-off-by: Chandrakanth patil Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f1933d9ee745c53cb795a2caeb97ef0e1be7837b Author: Alexey Galakhov Date: Wed Mar 9 22:25:35 2022 +0100 scsi: mvsas: Add PCI ID of RocketRaid 2640 [ Upstream commit 5f2bce1e222028dc1c15f130109a17aa654ae6e8 ] The HighPoint RocketRaid 2640 is a low-cost SAS controller based on Marvell chip. The chip in question was already supported by the kernel, just the PCI ID of this particular board was missing. Link: https://lore.kernel.org/r/20220309212535.402987-1-agalakhov@gmail.com Signed-off-by: Alexey Galakhov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 389f37e46bddbcba6d2b1d0b542f382e4eca1acf Author: Sreekanth Reddy Date: Tue Apr 5 17:36:37 2022 +0530 scsi: mpt3sas: Fail reset operation if config request timed out [ Upstream commit f61eb1216c959f93ffabd3b8781fa5b2b22f8907 ] As part of controller reset operation the driver issues a config request command. If this command gets times out, then fail the controller reset operation instead of retrying it. Link: https://lore.kernel.org/r/20220405120637.20528-1-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 184b4fad0872ee5b41716ffcd26f1f64d20f9fc2 Author: Christoph Böhmwalder Date: Wed Apr 6 21:04:45 2022 +0200 drbd: set QUEUE_FLAG_STABLE_WRITES [ Upstream commit 286901941fd18a52b2138fddbbf589ad3639eb00 ] We want our pages not to change while they are being written. Signed-off-by: Christoph Böhmwalder Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6a03581ccffa571bfa1a9f3a097e1a4d7164fd2d Author: Roman Li Date: Thu Mar 17 19:55:05 2022 -0400 drm/amd/display: Fix allocate_mst_payload assert on resume [ Upstream commit f4346fb3edf7720db3f7f5e1cab1f667cd024280 ] [Why] On resume we do link detection for all non-MST connectors. MST is handled separately. However the condition for telling if connector is on mst branch is not enough for mst hub case. Link detection for mst branch link leads to mst topology reset. That causes assert in dc_link_allocate_mst_payload() [How] Use link type as indicator for mst link. Reviewed-by: Wayne Lin Acked-by: Alex Hung Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ac2eb310af0582428400186173d070320a8bfd6f Author: Martin Leung Date: Fri Mar 18 11:12:36 2022 -0400 drm/amd/display: Revert FEC check in validation [ Upstream commit b2075fce104b88b789c15ef1ed2b91dc94198e26 ] why and how: causes failure on install on certain machines Reviewed-by: George Shen Acked-by: Alex Hung Signed-off-by: Martin Leung Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit eab8e585840f84c6a352eaab70e5495eda7ebb6f Author: Roman Li Date: Tue Mar 15 16:31:14 2022 -0400 drm/amd/display: Enable power gating before init_pipes [ Upstream commit 58e16c752e9540b28a873c44c3bee83e022007c1 ] [Why] In init_hw() we call init_pipes() before enabling power gating. init_pipes() tries to power gate dsc but it may fail because required force-ons are not released yet. As a result with dsc config the following errors observed on resume: "REG_WAIT timeout 1us * 1000 tries - dcn20_dsc_pg_control" "REG_WAIT timeout 1us * 1000 tries - dcn20_dpp_pg_control" "REG_WAIT timeout 1us * 1000 tries - dcn20_hubp_pg_control" [How] Move enable_power_gating_plane() before init_pipes() in init_hw() Reviewed-by: Anthony Koo Reviewed-by: Eric Yang Acked-by: Alex Hung Signed-off-by: Roman Li Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d8860f1f9e41e7072ed4fae5316dd43ed83beb64 Author: Matthias Schiffer Date: Thu Mar 31 13:08:19 2022 +0200 spi: cadence-quadspi: fix protocol setup for non-1-1-X operations [ Upstream commit 97e4827d775faa9a32b5e1a97959c69dd77d17a3 ] cqspi_set_protocol() only set the data width, but ignored the command and address width (except for 8-8-8 DTR ops), leading to corruption of all transfers using 1-X-X or X-X-X ops. Fix by setting the other two widths as well. While we're at it, simplify the code a bit by replacing the CQSPI_INST_TYPE_* constants with ilog2(). Tested on a TI AM64x with a Macronix MX25U51245G QSPI flash with 1-4-4 read and write operations. Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/20220331110819.133392-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6d48df73827239235c0d52d39d82c19df90b6eb9 Author: Xiaomeng Tong Date: Wed Apr 6 11:55:56 2022 +0800 myri10ge: fix an incorrect free for skb in myri10ge_sw_tso [ Upstream commit b423e54ba965b4469b48e46fd16941f1e1701697 ] All remaining skbs should be released when myri10ge_xmit fails to transmit a packet. Fix it within another skb_list_walk_safe. Signed-off-by: Xiaomeng Tong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b416898442f2b6aa9f1b2f2968ce07e3abaa05f7 Author: Marcin Kozlowski Date: Wed Apr 6 10:05:37 2022 +0200 net: usb: aqc111: Fix out-of-bounds accesses in RX fixup [ Upstream commit afb8e246527536848b9b4025b40e613edf776a9d ] aqc111_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, causing OOB reads and (on big-endian systems) OOB endianness flips. - A packet can overlap the metadata array, causing a later OOB endianness flip to corrupt data used by a cloned SKB that has already been handed off into the network stack. - A packet SKB can be constructed whose tail is far beyond its end, causing out-of-bounds heap data to be considered part of the SKB's data. Found doing variant analysis. Tested it with another driver (ax88179_178a), since I don't have a aqc111 device to test it, but the code looks very similar. Signed-off-by: Marcin Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c3f86aef97cf2671d65ce67f02190efc2adc71ae Author: Boqun Feng Date: Fri Mar 25 10:32:12 2022 +0800 Drivers: hv: balloon: Disable balloon and hot-add accordingly [ Upstream commit be5802795cf8d0b881745fa9ba7790293b382280 ] Currently there are known potential issues for balloon and hot-add on ARM64: * Unballoon requests from Hyper-V should only unballoon ranges that are guest page size aligned, otherwise guests cannot handle because it's impossible to partially free a page. This is a problem when guest page size > 4096 bytes. * Memory hot-add requests from Hyper-V should provide the NUMA node id of the added ranges or ARM64 should have a functional memory_add_physaddr_to_nid(), otherwise the node id is missing for add_memory(). These issues require discussions on design and implementation. In the meanwhile, post_status() is working and essential to guest monitoring. Therefore instead of disabling the entire hv_balloon driver, the ballooning (when page size > 4096 bytes) and hot-add are disabled accordingly for now. Once the issues are fixed, they can be re-enable in these cases. Signed-off-by: Boqun Feng Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20220325023212.1570049-3-boqun.feng@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 1c9fdb9587e01b33098172448a62451652d8f58f Author: Andy Chiu Date: Tue Apr 5 17:19:26 2022 +0800 net: axienet: setup mdio unconditionally [ Upstream commit d1c4f93e3f0a023024a6f022a61528c06cf1daa9 ] The call to axienet_mdio_setup should not depend on whether "phy-node" pressents on the DT. Besides, since `lp->phy_node` is used if PHY is in SGMII or 100Base-X modes, move it into the if statement. And the next patch will remove `lp->phy_node` from driver's private structure and do an of_node_put on it right away after use since it is not used elsewhere. Signed-off-by: Andy Chiu Reviewed-by: Greentime Hu Reviewed-by: Robert Hancock Reviewed-by: Radhey Shyam Pandey Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 61dd8bef80c24f8a848d2e4b57e0ded77bf2a1ce Author: Steve Capper Date: Wed Mar 30 12:25:43 2022 +0100 tlb: hugetlb: Add more sizes to tlb_remove_huge_tlb_entry [ Upstream commit 697a1d44af8ba0477ee729e632f4ade37999249a ] tlb_remove_huge_tlb_entry only considers PMD_SIZE and PUD_SIZE when updating the mmu_gather structure. Unfortunately on arm64 there are two additional huge page sizes that need to be covered: CONT_PTE_SIZE and CONT_PMD_SIZE. Where an end-user attempts to employ contiguous huge pages, a VM_BUG_ON can be experienced due to the fact that the tlb structure hasn't been correctly updated by the relevant tlb_flush_p.._range() call from tlb_remove_huge_tlb_entry. This patch adds inequality logic to the generic implementation of tlb_remove_huge_tlb_entry s.t. CONT_PTE_SIZE and CONT_PMD_SIZE are effectively covered on arm64. Also, as well as ptes, pmds and puds; p4ds are now considered too. Reported-by: David Hildenbrand Suggested-by: Peter Zijlstra (Intel) Cc: Anshuman Khandual Cc: Catalin Marinas Cc: Will Deacon Link: https://lore.kernel.org/linux-mm/811c5c8e-b3a2-85d2-049c-717f17c3a03a@redhat.com/ Signed-off-by: Steve Capper Acked-by: David Hildenbrand Reviewed-by: Anshuman Khandual Reviewed-by: Catalin Marinas Acked-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20220330112543.863-1-steve.capper@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit ed2711c696ceb0bad5259bf338044c8a589c798d Author: Joey Gouly Date: Tue Apr 5 11:47:33 2022 +0100 arm64: alternatives: mark patch_alternative() as `noinstr` [ Upstream commit a2c0b0fbe01419f8f5d1c0b9c581631f34ffce8b ] The alternatives code must be `noinstr` such that it does not patch itself, as the cache invalidation is only performed after all the alternatives have been applied. Mark patch_alternative() as `noinstr`. Mark branch_insn_requires_update() and get_alt_insn() with `__always_inline` since they are both only called through patch_alternative(). Booting a kernel in QEMU TCG with KCSAN=y and ARM64_USE_LSE_ATOMICS=y caused a boot hang: [ 0.241121] CPU: All CPU(s) started at EL2 The alternatives code was patching the atomics in __tsan_read4() from LL/SC atomics to LSE atomics. The following fragment is using LL/SC atomics in the .text section: | <__tsan_unaligned_read4+304>: ldxr x6, [x2] | <__tsan_unaligned_read4+308>: add x6, x6, x5 | <__tsan_unaligned_read4+312>: stxr w7, x6, [x2] | <__tsan_unaligned_read4+316>: cbnz w7, <__tsan_unaligned_read4+304> This LL/SC atomic sequence was to be replaced with LSE atomics. However since the alternatives code was instrumentable, __tsan_read4() was being called after only the first instruction was replaced, which led to the following code in memory: | <__tsan_unaligned_read4+304>: ldadd x5, x6, [x2] | <__tsan_unaligned_read4+308>: add x6, x6, x5 | <__tsan_unaligned_read4+312>: stxr w7, x6, [x2] | <__tsan_unaligned_read4+316>: cbnz w7, <__tsan_unaligned_read4+304> This caused an infinite loop as the `stxr` instruction never completed successfully, so `w7` was always 0. Signed-off-by: Joey Gouly Cc: Mark Rutland Cc: Catalin Marinas Cc: Will Deacon Link: https://lore.kernel.org/r/20220405104733.11476-1-joey.gouly@arm.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit cfd24b14eb2d435d4555e9bc15d68d50bd21c105 Author: Jonathan Bakker Date: Sun Mar 27 18:01:54 2022 -0700 regulator: wm8994: Add an off-on delay for WM8994 variant [ Upstream commit 92d96b603738ec4f35cde7198c303ae264dd47cb ] As per Table 130 of the wm8994 datasheet at [1], there is an off-on delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not find any reference to it. I could not find a wm1811 datasheet to double-check there, but as no one has complained presumably it works without it. This solves the issue on Samsung Aries boards with a wm8994 where register writes fail when the device is powered off and back-on quickly. [1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf [2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf Signed-off-by: Jonathan Bakker Acked-by: Charles Keepax Link: https://lore.kernel.org/r/CY4PR04MB056771CFB80DC447C30D5A31CB1D9@CY4PR04MB0567.namprd04.prod.outlook.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 86d1cdf56fc5124875252bb7001d1af264ea582f Author: Leo Ruan Date: Mon Feb 7 16:14:11 2022 +0100 gpu: ipu-v3: Fix dev_dbg frequency output [ Upstream commit 070a88fd4a03f921b73a2059e97d55faaa447dab ] This commit corrects the printing of the IPU clock error percentage if it is between -0.1% to -0.9%. For example, if the pixel clock requested is 27.2 MHz but only 27.0 MHz can be achieved the deviation is -0.8%. But the fixed point math had a flaw and calculated error of 0.2%. Before: Clocks: IPU 270000000Hz DI 24716667Hz Needed 27200000Hz IPU clock can give 27000000 with divider 10, error 0.2% Want 27200000Hz IPU 270000000Hz DI 24716667Hz using IPU, 27000000Hz After: Clocks: IPU 270000000Hz DI 24716667Hz Needed 27200000Hz IPU clock can give 27000000 with divider 10, error -0.8% Want 27200000Hz IPU 270000000Hz DI 24716667Hz using IPU, 27000000Hz Signed-off-by: Leo Ruan Signed-off-by: Mark Jonas Reviewed-by: Philipp Zabel Signed-off-by: Philipp Zabel Link: https://lore.kernel.org/r/20220207151411.5009-1-mark.jonas@de.bosch.com Signed-off-by: Sasha Levin commit 4583205048aefc0e05e46ebb3cd23a0b172744ec Author: Christian Lamparter Date: Sat Mar 19 21:11:03 2022 +0100 ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs [ Upstream commit 5399752299396a3c9df6617f4b3c907d7aa4ded8 ] Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with the a message: "READ LOG DMA EXT failed, trying PIO" during boot. Initially this was discovered because it caused a crash with the sata_dwc_460ex controller on a WD MyBook Live DUO. The reporter "Tice Rex" which has the unique opportunity that he has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q" which booted fine and didn't expose "READ LOG DMA EXT". But the newer/latest firmware "EXT0DB6Q" caused the headaches. BugLink: https://github.com/openwrt/openwrt/issues/9505 Signed-off-by: Christian Lamparter Signed-off-by: Damien Le Moal Signed-off-by: Sasha Levin commit 6eecc4811a478e7ddea6d38ad3f08c24a93c0502 Author: Randy Dunlap Date: Thu Mar 31 22:42:44 2022 -0700 net: micrel: fix KS8851_MLL Kconfig [ Upstream commit c3efcedd272aa6dd5929e20cf902a52ddaa1197a ] KS8851_MLL selects MICREL_PHY, which depends on PTP_1588_CLOCK_OPTIONAL, so make KS8851_MLL also depend on PTP_1588_CLOCK_OPTIONAL since 'select' does not follow any dependency chains. Fixes kconfig warning and build errors: WARNING: unmet direct dependencies detected for MICREL_PHY Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && PTP_1588_CLOCK_OPTIONAL [=m] Selected by [y]: - KS8851_MLL [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_MICREL [=y] && HAS_IOMEM [=y] ld: drivers/net/phy/micrel.o: in function `lan8814_ts_info': micrel.c:(.text+0xb35): undefined reference to `ptp_clock_index' ld: drivers/net/phy/micrel.o: in function `lan8814_probe': micrel.c:(.text+0x2586): undefined reference to `ptp_clock_register' Signed-off-by: Randy Dunlap Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9e60a788a3f78860f776b478ba2aad87ea9dc850 Author: Tyrel Datwyler Date: Tue Mar 22 12:44:43 2022 -0700 scsi: ibmvscsis: Increase INITIAL_SRP_LIMIT to 1024 [ Upstream commit 0bade8e53279157c7cc9dd95d573b7e82223d78a ] The adapter request_limit is hardcoded to be INITIAL_SRP_LIMIT which is currently an arbitrary value of 800. Increase this value to 1024 which better matches the characteristics of the typical IBMi Initiator that supports 32 LUNs and a queue depth of 32. This change also has the secondary benefit of being a power of two as required by the kfifo API. Since, Commit ab9bb6318b09 ("Partially revert "kfifo: fix kfifo_alloc() and kfifo_init()"") the size of IU pool for each target has been rounded down to 512 when attempting to kfifo_init() those pools with the current request_limit size of 800. Link: https://lore.kernel.org/r/20220322194443.678433-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 026083cb43a4b0f501efdce751b25ce1466bde6f Author: James Smart Date: Wed Mar 16 20:27:36 2022 -0700 scsi: lpfc: Fix queue failures when recovering from PCI parity error [ Upstream commit df0101197c4d9596682901631f3ee193ed354873 ] When recovering from a pci-parity error the driver is failing to re-create queues, causing recovery to fail. Looking deeper, it was found that the interrupt vector count allocated on the recovery was fewer than the vectors originally allocated. This disparity resulted in CPU map entries with stale information. When the driver tries to re-create the queues, it attempts to use the stale information which indicates an eq/interrupt vector that was no longer created. Fix by clearng the cpup map array before enabling and requesting the IRQs in the lpfc_sli_reset_slot_s4 routine(). Link: https://lore.kernel.org/r/20220317032737.45308-4-jsmart2021@gmail.com Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b7f3b5d70c834f49f7d87a2f2ed1c6284d9a0322 Author: Xiaoguang Wang Date: Fri Mar 11 21:22:05 2022 +0800 scsi: target: tcmu: Fix possible page UAF [ Upstream commit a6968f7a367f128d120447360734344d5a3d5336 ] tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not take refcount properly and just returns page pointer. When tcmu_try_get_data_page() returns, the returned page may have been freed by tcmu_blocks_release(). We need to get_page() under cmdr_lock to avoid concurrent tcmu_blocks_release(). Link: https://lore.kernel.org/r/20220311132206.24515-1-xiaoguang.wang@linux.alibaba.com Reviewed-by: Bodo Stroesser Signed-off-by: Xiaoguang Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 44f95a5aae99afff298491c057acae4d895c9bdd Author: Michael Kelley Date: Sun Mar 27 08:25:10 2022 -0700 Drivers: hv: vmbus: Prevent load re-ordering when reading ring buffer [ Upstream commit b6cae15b5710c8097aad26a2e5e752c323ee5348 ] When reading a packet from a host-to-guest ring buffer, there is no memory barrier between reading the write index (to see if there is a packet to read) and reading the contents of the packet. The Hyper-V host uses store-release when updating the write index to ensure that writes of the packet data are completed first. On the guest side, the processor can reorder and read the packet data before the write index, and sometimes get stale packet data. Getting such stale packet data has been observed in a reproducible case in a VM on ARM64. Fix this by using virt_load_acquire() to read the write index, ensuring that reads of the packet data cannot be reordered before it. Preventing such reordering is logically correct, and with this change, getting stale data can no longer be reproduced. Signed-off-by: Michael Kelley Reviewed-by: Andrea Parri (Microsoft) Link: https://lore.kernel.org/r/1648394710-33480-1-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 92a3499933c17b25b7c59658183bc7d23a581f5b Author: Michael Kelley Date: Thu Mar 24 09:14:52 2022 -0700 PCI: hv: Propagate coherence from VMbus device to PCI device [ Upstream commit 8d21732475c637c7efcdb91dc927a4c594e97898 ] PCI pass-thru devices in a Hyper-V VM are represented as a VMBus device and as a PCI device. The coherence of the VMbus device is set based on the VMbus node in ACPI, but the PCI device has no ACPI node and defaults to not hardware coherent. This results in extra software coherence management overhead on ARM64 when devices are hardware coherent. Fix this by setting up the PCI host bus so that normal PCI mechanisms will propagate the coherence of the VMbus device to the PCI device. There's no effect on x86/x64 where devices are always hardware coherent. Signed-off-by: Michael Kelley Acked-by: Boqun Feng Acked-by: Robin Murphy Link: https://lore.kernel.org/r/1648138492-2191-3-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 1b576e81d31b56b248316b8ff816b1cc5c4407c7 Author: Andrea Parri (Microsoft) Date: Tue Mar 1 15:11:35 2022 +0100 Drivers: hv: vmbus: Deactivate sysctl_record_panic_msg by default in isolated guests [ Upstream commit 9f8b577f7b43b2170628d6c537252785dcc2dcea ] hv_panic_page might contain guest-sensitive information, do not dump it over to Hyper-V by default in isolated guests. While at it, update some comments in hyperv_{panic,die}_event(). Reported-by: Dexuan Cui Signed-off-by: Andrea Parri (Microsoft) Reviewed-by: Dexuan Cui Link: https://lore.kernel.org/r/20220301141135.2232-1-parri.andrea@gmail.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit f2658d5966bcee8c3eb487875f459756d4f7cdfc Author: QintaoShen Date: Thu Mar 24 16:26:23 2022 +0800 drm/amdkfd: Check for potential null return of kmalloc_array() [ Upstream commit ebbb7bb9e80305820dc2328a371c1b35679f2667 ] As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. Signed-off-by: QintaoShen Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9f0fabf30b486e3d5c9b578073cea369ffc05c43 Author: Tianci Yin Date: Wed Mar 23 23:54:58 2022 +0800 drm/amdgpu/vcn: improve vcn dpg stop procedure [ Upstream commit 6ea239adc2a712eb318f04f5c29b018ba65ea38a ] Prior to disabling dpg, VCN need unpausing dpg mode, or VCN will hang in S3 resuming. Reviewed-by: James Zhu Signed-off-by: Tianci Yin Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 25efb191d86b108f100f82f414229f8269d00b28 Author: Tushar Patel Date: Thu Mar 17 15:31:22 2022 -0400 drm/amdkfd: Fix Incorrect VMIDs passed to HWS [ Upstream commit b7dfbd2e601f3fee545bc158feceba4f340fe7cf ] Compute-only GPUs have more than 8 VMIDs allocated to KFD. Fix this by passing correct number of VMIDs to HWS v2: squash in warning fix (Alex) Signed-off-by: Tushar Patel Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7a3bc11a40346987649018ecd82caa744117c347 Author: Leo (Hanghong) Ma Date: Fri Mar 11 11:35:29 2022 -0500 drm/amd/display: Update VTEM Infopacket definition [ Upstream commit c9fbf6435162ed5fb7201d1d4adf6585c6a8c327 ] [Why & How] The latest HDMI SPEC has updated the VTEM packet structure, so change the VTEM Infopacket defined in the driver side to align with the SPEC. Reviewed-by: Chris Park Acked-by: Alex Hung Signed-off-by: Leo (Hanghong) Ma Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 92951699a5f11043b9d1402ea21787f420b36094 Author: Chiawen Huang Date: Thu Mar 10 00:07:59 2022 +0800 drm/amd/display: FEC check in timing validation [ Upstream commit 7d56a154e22ffb3613fdebf83ec34d5225a22993 ] [Why] disable/enable leads FEC mismatch between hw/sw FEC state. [How] check FEC status to fastboot on/off. Reviewed-by: Anthony Koo Acked-by: Alex Hung Signed-off-by: Chiawen Huang Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b054e8183fbdec15955311956df8a9ce47e0ab6d Author: Charlene Liu Date: Mon Mar 7 18:31:29 2022 -0500 drm/amd/display: fix audio format not updated after edid updated [ Upstream commit 5e8a71cf13bc9184fee915b2220be71b4c6cac74 ] [why] for the case edid change only changed audio format. driver still need to update stream. Reviewed-by: Alvin Lee Reviewed-by: Aric Cyr Acked-by: Alex Hung Signed-off-by: Charlene Liu Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 37bc29a445384f4bdfc734dfe7f763ede604acfe Author: Alex Deucher Date: Wed Mar 9 18:02:11 2022 -0500 drm/amdgpu/gmc: use PCI BARs for APUs in passthrough [ Upstream commit b818a5d374542ccec73dcfe578a081574029820e ] If the GPU is passed through to a guest VM, use the PCI BAR for CPU FB access rather than the physical address of carve out. The physical address is not valid in a guest. v2: Fix HDP handing as suggested by Michel Reviewed-by: Christian König Reviewed-by: Michel Dänzer Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5a3b56a4a1c79111bc4aaa9caba5eb5e9cfaeaeb Author: Guchun Chen Date: Tue Mar 15 14:59:28 2022 +0800 drm/amdgpu: conduct a proper cleanup of PDB bo [ Upstream commit 2d505453f38e18d42ba7d5428aaa17aaa7752c65 ] Use amdgpu_bo_free_kernel instead of amdgpu_bo_unref to perform a proper cleanup of PDB bo. v2: update subject to be more accurate Signed-off-by: Guchun Chen Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 01dcda701fefd8259b8a9518135730be08c2bad5 Author: Josef Bacik Date: Wed Mar 23 11:30:36 2022 -0400 btrfs: do not warn for free space inode in cow_file_range [ Upstream commit a7d16d9a07bbcb7dcd5214a1bea75c808830bc0d ] This is a long time leftover from when I originally added the free space inode, the point was to catch cases where we weren't honoring the NOCOW flag. However there exists a race with relocation, if we allocate our free space inode in a block group that is about to be relocated, we could trigger the COW path before the relocation has the opportunity to find the extents and delete the free space cache. In production where we have auto-relocation enabled we're seeing this WARN_ON_ONCE() around 5k times in a 2 week period, so not super common but enough that it's at the top of our metrics. We're properly handling the error here, and with us phasing out v1 space cache anyway just drop the WARN_ON_ONCE. Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit bb93369f93b568eaa0c2fa56ef1979490372353d Author: Darrick J. Wong Date: Mon Mar 14 10:55:32 2022 -0700 btrfs: fix fallocate to use file_modified to update permissions consistently [ Upstream commit 05fd9564e9faf0f23b4676385e27d9405cef6637 ] Since the initial introduction of (posix) fallocate back at the turn of the century, it has been possible to use this syscall to change the user-visible contents of files. This can happen by extending the file size during a preallocation, or through any of the newer modes (punch, zero range). Because the call can be used to change file contents, we should treat it like we do any other modification to a file -- update the mtime, and drop set[ug]id privileges/capabilities. The VFS function file_modified() does all this for us if pass it a locked inode, so let's make fallocate drop permissions correctly. Reviewed-by: Filipe Manana Signed-off-by: Darrick J. Wong Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 6dded62e5aa6e29f18a1079002109cb6068e9bf6 Author: Aurabindo Pillai Date: Tue Mar 15 14:53:24 2022 -0400 drm/amd: Add USBC connector ID [ Upstream commit c5c948aa894a831f96fccd025e47186b1ee41615 ] [Why&How] Add a dedicated AMDGPU specific ID for use with newer ASICs that support USB-C output Signed-off-by: Aurabindo Pillai Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3e67054c339c9a636d228cb9b0aac5c1c667a99c Author: Ming Lei Date: Thu Apr 14 16:44:43 2022 +0800 block: fix offset/size check in bio_trim() [ Upstream commit 8535c0185d14ea41f0efd6a357961b05daf6687e ] Unit of bio->bi_iter.bi_size is bytes, but unit of offset/size is sector. Fix the above issue in checking offset/size in bio_trim(). Fixes: e83502ca5f1e ("block: fix argument type of bio_trim()") Cc: Chaitanya Kulkarni Signed-off-by: Ming Lei Link: https://lore.kernel.org/r/20220414084443.1736850-1-ming.lei@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 279018a01b086353ad71c039bb7a70e99f2260f0 Author: Jeremy Linton Date: Tue Apr 12 16:04:20 2022 -0500 net: bcmgenet: Revert "Use stronger register read/writes to assure ordering" [ Upstream commit 2df3fc4a84e917a422935cc5bae18f43f9955d31 ] It turns out after digging deeper into this bug, that it was being triggered by GCC12 failing to call the bcmgenet_enable_dma() routine. Given that a gcc12 fix has been merged [1] and the genet driver now works properly when built with gcc12, this commit should be reverted. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105160 https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=aabb9a261ef060cf24fd626713f1d7d9df81aa57 Fixes: 8d3ea3d402db ("net: bcmgenet: Use stronger register read/writes to assure ordering") Signed-off-by: Jeremy Linton Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20220412210420.1129430-1-jeremy.linton@arm.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin commit b8c0f6d1b04cdf07eda31cb643eea1a1410b551f Author: Jason Gunthorpe Date: Wed Apr 13 10:10:36 2022 -0300 vfio/pci: Fix vf_token mechanism when device-specific VF drivers are used [ Upstream commit 1ef3342a934e235aca72b4bcc0d6854d80a65077 ] get_pf_vdev() tries to check if a PF is a VFIO PF by looking at the driver: if (pci_dev_driver(physfn) != pci_dev_driver(vdev->pdev)) { However now that we have multiple VF and PF drivers this is no longer reliable. This means that security tests realted to vf_token can be skipped by mixing and matching different VFIO PCI drivers. Instead of trying to use the driver core to find the PF devices maintain a linked list of all PF vfio_pci_core_device's that we have called pci_enable_sriov() on. When registering a VF just search the list to see if the PF is present and record the match permanently in the struct. PCI core locking prevents a PF from passing pci_disable_sriov() while VF drivers are attached so the VFIO owned PF becomes a static property of the VF. In common cases where vfio does not own the PF the global list remains empty and the VF's pointer is statically NULL. This also fixes a lockdep splat from recursive locking of the vfio_group::device_lock between vfio_device_get_from_name() and vfio_device_get_from_dev(). If the VF and PF share the same group this would deadlock. Fixes: ff53edf6d6ab ("vfio/pci: Split the pci_driver code out of vfio_pci_core.c") Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/0-v3-876570980634+f2e8-vfio_vf_token_jgg@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 5fda973f0eceb71d14fa1fab22027bca9418229f Author: Khazhismel Kumykov Date: Mon Apr 11 15:03:35 2022 -0700 dm mpath: only use ktime_get_ns() in historical selector [ Upstream commit ce40426fdc3c92acdba6b5ca74bc7277ffaa6a3d ] Mixing sched_clock() and ktime_get_ns() usage will give bad results. Switch hst_select_path() from using sched_clock() to ktime_get_ns(). Also rename path_service_time()'s 'sched_now' variable to 'now'. Fixes: 2613eab11996 ("dm mpath: add Historical Service Time Path Selector") Signed-off-by: Khazhismel Kumykov Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 9901b07ba42b39266b34a888e48d7306fd707bee Author: Harshit Mogalapalli Date: Wed Apr 13 04:42:51 2022 -0700 cifs: potential buffer overflow in handling symlinks [ Upstream commit 64c4a37ac04eeb43c42d272f6e6c8c12bfcf4304 ] Smatch printed a warning: arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: __memcpy() 'dctx->buf' too small (16 vs u32max) It's caused because Smatch marks 'link_len' as untrusted since it comes from sscanf(). Add a check to ensure that 'link_len' is not larger than the size of the 'link_str' buffer. Fixes: c69c1b6eaea1 ("cifs: implement CIFSParseMFSymlink()") Signed-off-by: Harshit Mogalapalli Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 9ded5ae40f4fe37fcc28f36d76bf45df20be5432 Author: Lin Ma Date: Wed Apr 13 00:04:30 2022 +0800 nfc: nci: add flush_workqueue to prevent uaf [ Upstream commit ef27324e2cb7bb24542d6cb2571740eefe6b00dc ] Our detector found a concurrent use-after-free bug when detaching an NCI device. The main reason for this bug is the unexpected scheduling between the used delayed mechanism (timer and workqueue). The race can be demonstrated below: Thread-1 Thread-2 | nci_dev_up() | nci_open_device() | __nci_request(nci_reset_req) | nci_send_cmd | queue_work(cmd_work) nci_unregister_device() | nci_close_device() | ... del_timer_sync(cmd_timer)[1] | ... | Worker nci_free_device() | nci_cmd_work() kfree(ndev)[3] | mod_timer(cmd_timer)[2] In short, the cleanup routine thought that the cmd_timer has already been detached by [1] but the mod_timer can re-attach the timer [2], even it is already released [3], resulting in UAF. This UAF is easy to trigger, crash trace by POC is like below [ 66.703713] ================================================================== [ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 [ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 [ 66.703974] [ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 [ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work [ 66.703974] Call Trace: [ 66.703974] [ 66.703974] dump_stack_lvl+0x57/0x7d [ 66.703974] print_report.cold+0x5e/0x5db [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] kasan_report+0xbe/0x1c0 [ 66.703974] ? enqueue_timer+0x448/0x490 [ 66.703974] enqueue_timer+0x448/0x490 [ 66.703974] __mod_timer+0x5e6/0xb80 [ 66.703974] ? mark_held_locks+0x9e/0xe0 [ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 [ 66.703974] ? queue_work_on+0x61/0x80 [ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 [ 66.703974] process_one_work+0x8bb/0x1510 [ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 [ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 [ 66.703974] ? rwlock_bug.part.0+0x90/0x90 [ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 [ 66.703974] worker_thread+0x575/0x1190 [ 66.703974] ? process_one_work+0x1510/0x1510 [ 66.703974] kthread+0x2a0/0x340 [ 66.703974] ? kthread_complete_and_exit+0x20/0x20 [ 66.703974] ret_from_fork+0x22/0x30 [ 66.703974] [ 66.703974] [ 66.703974] Allocated by task 267: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] __kasan_kmalloc+0x81/0xa0 [ 66.703974] nci_allocate_device+0xd3/0x390 [ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 [ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd [ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 [ 66.703974] tty_ioctl+0x764/0x1310 [ 66.703974] __x64_sys_ioctl+0x122/0x190 [ 66.703974] do_syscall_64+0x3b/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 66.703974] [ 66.703974] Freed by task 406: [ 66.703974] kasan_save_stack+0x1e/0x40 [ 66.703974] kasan_set_track+0x21/0x30 [ 66.703974] kasan_set_free_info+0x20/0x30 [ 66.703974] __kasan_slab_free+0x108/0x170 [ 66.703974] kfree+0xb0/0x330 [ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 [ 66.703974] nci_uart_tty_close+0xdf/0x180 [ 66.703974] tty_ldisc_kill+0x73/0x110 [ 66.703974] tty_ldisc_hangup+0x281/0x5b0 [ 66.703974] __tty_hangup.part.0+0x431/0x890 [ 66.703974] tty_release+0x3a8/0xc80 [ 66.703974] __fput+0x1f0/0x8c0 [ 66.703974] task_work_run+0xc9/0x170 [ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 [ 66.703974] syscall_exit_to_user_mode+0x19/0x50 [ 66.703974] do_syscall_64+0x48/0x90 [ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae To fix the UAF, this patch adds flush_workqueue() to ensure the nci_cmd_work is finished before the following del_timer_sync. This combination will promise the timer is actually detached. Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") Signed-off-by: Lin Ma Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 331c99ee8dcb5e7a6dcf9f2edf171d991d14077e Author: Dylan Hung Date: Tue Apr 12 19:48:59 2022 +0800 net: ftgmac100: access hardware register after clock ready [ Upstream commit 3d2504524531990b32a0629cc984db44f399d161 ] AST2600 MAC register 0x58 is writable only when the MAC clock is enabled. Usually, the MAC clock is enabled by the bootloader so register 0x58 is set normally when the bootloader is involved. To make ast2600 ftgmac100 work without the bootloader, postpone the register write until the clock is ready. Fixes: 137d23cea1c0 ("net: ftgmac100: Fix Aspeed ast2600 TX hang issue") Signed-off-by: Dylan Hung Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8f79ce226ad2e9b2ec598de2b9560863b7549d1b Author: Martin Willi Date: Tue Apr 12 11:34:57 2022 +0200 macvlan: Fix leaking skb in source mode with nodst option [ Upstream commit e16b859872b87650bb55b12cca5a5fcdc49c1442 ] The MACVLAN receive handler clones skbs to all matching source MACVLAN interfaces, before it passes the packet along to match on destination based MACVLANs. When using the MACVLAN nodst mode, passing the packet to destination based MACVLANs is omitted and the handler returns with RX_HANDLER_CONSUMED. However, the passed skb is not freed, leaking for any packet processed with the nodst option. Properly free the skb when consuming packets to fix that leak. Fixes: 427f0c8c194b ("macvlan: Add nodst option to macvlan type source") Signed-off-by: Martin Willi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e86fba134792f69315e37b0c122ba6a60ac0c0b Author: Adrian Hunter Date: Mon Apr 11 09:17:58 2022 +0300 perf tools: Fix misleading add event PMU debug message [ Upstream commit f034fc50d3c7d9385c20d505ab4cf56b8fd18ac7 ] Fix incorrect debug message: Attempting to add event pmu 'intel_pt' with '' that may result in non-fatal errors which always appears with perf record -vv and intel_pt e.g. perf record -vv -e intel_pt//u uname The message is incorrect because there will never be non-fatal errors. Suppress the message if the PMU is 'selectable' i.e. meant to be selected directly as an event. Fixes: 4ac22b484d4c79e8 ("perf parse-events: Make add PMU verbose output clearer") Signed-off-by: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20220411061758.2458417-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1665758b4bfdd550dae9f88b86d3a1b00918f3e0 Author: Takashi Iwai Date: Tue Apr 12 15:07:40 2022 +0200 ALSA: usb-audio: Limit max buffer and period sizes per time [ Upstream commit 24d0c9f0e7de95fe3e3e0067cbea1cd5d413244b ] In the previous fix, we increased the max buffer bytes from 1MB to 4MB so that we can use bigger buffers for the modern HiFi devices with higher rates, more channels and wider formats. OTOH, extending this has a concern that too big buffer is allowed for the lower rates, less channels and narrower formats; when an application tries to allocate as big buffer as possible, it'll lead to unexpectedly too huge size. Also, we had a problem about the inconsistent max buffer and period bytes for the implicit feedback mode when both streams have different channels. This was fixed by the (relatively complex) patch to reduce the max buffer and period bytes accordingly. This is an alternative fix for those, a patch to kill two birds with one stone (*): instead of increasing the max buffer bytes blindly and applying the reduction per channels, we simply use the hw constraints for the buffer and period "time". Meanwhile the max buffer and period bytes are set unlimited instead. Since the inconsistency of buffer (and period) bytes comes from the difference of the channels in the tied streams, as long as we care only about the buffer (and period) time, it doesn't matter; the buffer time is same for different channels, although we still allow higher buffer size. Similarly, this will allow more buffer bytes for HiFi devices while it also keeps the reasonable size for the legacy devices, too. As of this patch, the max period and buffer time are set to 1 and 2 seconds, which should be large enough for all possible use cases. (*) No animals were harmed in the making of this patch. Fixes: 98c27add5d96 ("ALSA: usb-audio: Cap upper limits of buffer/period bytes for implicit fb") Fixes: fee2ec8cceb3 ("ALSA: usb-audio: Increase max buffer size") Link: https://lore.kernel.org/r/20220412130740.18933-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6b38c5722610b2a5a891cd372f50e8682fad83e6 Author: Takashi Iwai Date: Thu Apr 7 23:27:40 2022 +0200 ALSA: usb-audio: Increase max buffer size [ Upstream commit fee2ec8cceb33b8886bc5894fb07e0b2e34148af ] The current limit of max buffer size 1MB seems too small for modern devices with lots of channels and high sample rates. Let's make bigger, 4MB. Reviewed-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20220407212740.17920-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7399ed8e6a8d37d75f29b10f4558fa8dc166aa61 Author: Athira Rajeev Date: Fri Apr 8 12:54:31 2022 +0530 testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu set [ Upstream commit ce64763c63854b4079f2e036638aa881a1fb3fbc ] The selftest "mqueue/mq_perf_tests.c" use CPU_ALLOC to allocate CPU set. This cpu set is used further in pthread_attr_setaffinity_np and by pthread_create in the code. But in current code, allocated cpu set is not freed. Fix this issue by adding CPU_FREE in the "shutdown" function which is called in most of the error/exit path for the cleanup. There are few error paths which exit without using shutdown. Add a common goto error path with CPU_FREE for these cases. Fixes: 7820b0715b6f ("tools/selftests: add mq_perf_tests") Signed-off-by: Athira Rajeev Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 9947548d9cef58f6be28b7bb0be53138626ff319 Author: Dylan Yudaken Date: Tue Apr 12 09:30:42 2022 -0700 io_uring: verify pad field is 0 in io_get_ext_arg [ Upstream commit d2347b9695dafe5c388a5f9aeb70e27a7a4d29cf ] Ensure that only 0 is passed for pad here. Fixes: c73ebb685fb6 ("io_uring: add timeout support for io_uring_enter()") Signed-off-by: Dylan Yudaken Link: https://lore.kernel.org/r/20220412163042.2788062-5-dylany@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7a7c9f9de9616af339c0f59ccdcb43b996c0bf5c Author: Dylan Yudaken Date: Tue Apr 12 09:30:40 2022 -0700 io_uring: verify that resv2 is 0 in io_uring_rsrc_update2 [ Upstream commit d8a3ba9c143bf89c032deced8a686ffa53b46098 ] Verify that the user does not pass in anything but 0 for this field. Fixes: 992da01aa932 ("io_uring: change registration/upd/rsrc tagging ABI") Signed-off-by: Dylan Yudaken Link: https://lore.kernel.org/r/20220412163042.2788062-3-dylany@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 22aa1597f462d2a917d1c6124cb33f520949936d Author: Dylan Yudaken Date: Tue Apr 12 09:30:39 2022 -0700 io_uring: move io_uring_rsrc_update2 validation [ Upstream commit 565c5e616e8061b40a2e1d786c418a7ac3503a8d ] Move validation to be more consistently straight after copy_from_user. This is already done in io_register_rsrc_update and so this removes that redundant check. Signed-off-by: Dylan Yudaken Link: https://lore.kernel.org/r/20220412163042.2788062-2-dylany@fb.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit cb981d5c751197b95075e707179aee9cf63a1cac Author: Takashi Iwai Date: Tue Apr 12 12:26:35 2022 +0200 ALSA: mtpav: Don't call card private_free at probe error path [ Upstream commit 4fb27190879b82e48ce89a56e9d6c04437dbc065 ] The card destructor of nm256 driver does merely stopping the running timer, and it's superfluous for the probe error handling. Moreover, calling this via the previous devres change would lead to another problem due to the reverse call order. This patch moves the setup of the private_free callback after the card registration, so that it can be used only after fully set up. Fixes: aa92050f10f0 ("ALSA: mtpav: Allocate resources with device-managed APIs") Link: https://lore.kernel.org/r/20220412102636.16000-39-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 872e5fa0781f926a78c729d682cd0c3a51acf175 Author: Takashi Iwai Date: Tue Apr 12 12:26:00 2022 +0200 ALSA: ad1889: Fix the missing snd_card_free() call at probe error [ Upstream commit a8e84a5da18e6d786540aa4ceb6f969d5f1a441d ] The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 567f58754109 ("ALSA: ad1889: Allocate resources with device-managed APIs") Link: https://lore.kernel.org/r/20220412102636.16000-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 96aceacda8d2102ff40c04bd0dd70901e96558db Author: Antoine Tenart Date: Tue Apr 12 10:14:59 2022 +0200 netfilter: nf_tables: nft_parse_register can return a negative value [ Upstream commit 6c6f9f31ecd47dce1d0dafca4bec8805f9bc97cd ] Since commit 6e1acfa387b9 ("netfilter: nf_tables: validate registers coming from userspace.") nft_parse_register can return a negative value, but the function prototype is still returning an unsigned int. Fixes: 6e1acfa387b9 ("netfilter: nf_tables: validate registers coming from userspace.") Signed-off-by: Antoine Tenart Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 90c153ca45da86342e1b5105bce1a96ab4f603e2 Author: Petr Malat Date: Sat Apr 9 08:36:11 2022 +0200 sctp: Initialize daddr on peeled off socket [ Upstream commit 8467dda0c26583547731e7f3ea73fc3856bae3bf ] Function sctp_do_peeloff() wrongly initializes daddr of the original socket instead of the peeled off socket, which makes getpeername() return zeroes instead of the primary address. Initialize the new socket instead. Fixes: d570ee490fb1 ("[SCTP]: Correctly set daddr for IPv6 sockets during peeloff") Signed-off-by: Petr Malat Acked-by: Marcelo Ricardo Leitner Link: https://lore.kernel.org/r/20220409063611.673193-1-oss@malat.biz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 50d46b5ce004a9621bd2842bc53bff58fb15c26d Author: Mike Christie Date: Thu Apr 7 19:13:10 2022 -0500 scsi: iscsi: Fix unbound endpoint error handling [ Upstream commit 03690d81974535f228e892a14f0d2d44404fe555 ] If a driver raises a connection error before the connection is bound, we can leave a cleanup_work queued that can later run and disconnect/stop a connection that is logged in. The problem is that drivers can call iscsi_conn_error_event for endpoints that are connected but not yet bound when something like the network port they are using is brought down. iscsi_cleanup_conn_work_fn will check for this and exit early, but if the cleanup_work is stuck behind other works, it might not get run until after userspace has done ep_disconnect. Because the endpoint is not yet bound there was no way for ep_disconnect to flush the work. The bug of leaving stop_conns queued was added in: Commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") and: Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") was supposed to fix it, but left this case. This patch moves the conn state check to before we even queue the work so we can avoid queueing. Link: https://lore.kernel.org/r/20220408001314.5014-7-michael.christie@oracle.com Fixes: 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") Tested-by: Manish Rangankar Reviewed-by: Lee Duncan Reviewed-by: Chris Leech Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 578616ac3d87ed5cf32c21ac83263ae2011afbb4 Author: Mike Christie Date: Thu Apr 7 19:13:09 2022 -0500 scsi: iscsi: Fix conn cleanup and stop race during iscsid restart [ Upstream commit 7c6e99c18167ed89729bf167ccb4a7e3ab3115ba ] If iscsid is doing a stop_conn at the same time the kernel is starting error recovery we can hit a race that allows the cleanup work to run on a valid connection. In the race, iscsi_if_stop_conn sees the cleanup bit set, but it calls flush_work on the clean_work before iscsi_conn_error_event has queued it. The flush then returns before the queueing and so the cleanup_work can run later and disconnect/stop a conn while it's in a connected state. The patch: Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") added the late stop_conn call bug originally, and the patch: Commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") attempted to fix it but only fixed the normal EH case and left the above race for the iscsid restart case. For the normal EH case we don't hit the race because we only signal userspace to start recovery after we have done the queueing, so the flush will always catch the queued work or see it completed. For iscsid restart cases like boot, we can hit the race because iscsid will call down to the kernel before the kernel has signaled any error, so both code paths can be running at the same time. This adds a lock around the setting of the cleanup bit and queueing so they happen together. Link: https://lore.kernel.org/r/20220408001314.5014-6-michael.christie@oracle.com Fixes: 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") Tested-by: Manish Rangankar Reviewed-by: Lee Duncan Reviewed-by: Chris Leech Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 485780af7ef1105671b59cba1280c191c67d470f Author: Mike Christie Date: Thu Apr 7 19:13:08 2022 -0500 scsi: iscsi: Fix endpoint reuse regression [ Upstream commit 0aadafb5c34403a7cced1a8d61877048dc059f70 ] This patch fixes a bug where when using iSCSI offload we can free an endpoint while userspace still thinks it's active. That then causes the endpoint ID to be reused for a new connection's endpoint while userspace still thinks the ID is for the original connection. Userspace will then end up disconnecting a running connection's endpoint or trying to bind to another connection's endpoint. This bug is a regression added in: Commit 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") where we added a in kernel ep_disconnect call to fix a bug in: Commit 0ab710458da1 ("scsi: iscsi: Perform connection failure entirely in kernel space") where we would call stop_conn without having done ep_disconnect. This early ep_disconnect call will then free the endpoint and it's ID while userspace still thinks the ID is valid. Fix the early release of the ID by having the in kernel recovery code keep a reference to the endpoint until userspace has called into the kernel to finish cleaning up the endpoint/connection. It requires the previous commit "scsi: iscsi: Release endpoint ID when its freed" which moved the freeing of the ID until when the endpoint is released. Link: https://lore.kernel.org/r/20220408001314.5014-5-michael.christie@oracle.com Fixes: 23d6fefbb3f6 ("scsi: iscsi: Fix in-kernel conn failure handling") Tested-by: Manish Rangankar Reviewed-by: Lee Duncan Reviewed-by: Chris Leech Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cbd4f4e409445a27a7ee03b41ede1cd52250d86b Author: Mike Christie Date: Thu Apr 7 19:13:06 2022 -0500 scsi: iscsi: Fix offload conn cleanup when iscsid restarts [ Upstream commit cbd2283aaf47fef4ded4b29124b1ef3beb515f3a ] When userspace restarts during boot or upgrades it won't know about the offload driver's endpoint and connection mappings. iscsid will start by cleaning up the old session by doing a stop_conn call. Later, if we are able to create a new connection, we clean up the old endpoint during the binding stage. The problem is that if we do stop_conn before doing the ep_disconnect call offload, drivers can still be executing I/O. We then might free tasks from the under the card/driver. This moves the ep_disconnect call to before we do the stop_conn call for this case. It will then work and look like a normal recovery/cleanup procedure from the driver's point of view. Link: https://lore.kernel.org/r/20220408001314.5014-3-michael.christie@oracle.com Tested-by: Manish Rangankar Reviewed-by: Lee Duncan Reviewed-by: Chris Leech Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cc0082d45de10a51836d31ca8ac9f35b9587118f Author: Mike Christie Date: Thu Apr 7 19:13:05 2022 -0500 scsi: iscsi: Move iscsi_ep_disconnect() [ Upstream commit c34f95e98d8fb750eefd4f3fe58b4f8b5e89253b ] This patch moves iscsi_ep_disconnect() so it can be called earlier in the next patch. Link: https://lore.kernel.org/r/20220408001314.5014-2-michael.christie@oracle.com Tested-by: Manish Rangankar Reviewed-by: Lee Duncan Reviewed-by: Chris Leech Signed-off-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d6f6f945e8501e8b6fcfbcc2920a004221a2c473 Author: Ajish Koshy Date: Mon Apr 11 12:16:03 2022 +0530 scsi: pm80xx: Enable upper inbound, outbound queues [ Upstream commit bcd8a45223470e00b5f254018174d64a75db4bbe ] Executing driver on servers with more than 32 CPUs were faced with command timeouts. This is because we were not geting completions for commands submitted on IQ32 - IQ63. Set E64Q bit to enable upper inbound and outbound queues 32 to 63 in the MPI main configuration table. Added 500ms delay after successful MPI initialization as mentioned in controller datasheet. Link: https://lore.kernel.org/r/20220411064603.668448-3-Ajish.Koshy@microchip.com Fixes: 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") Reviewed-by: Damien Le Moal Acked-by: Jack Wang Signed-off-by: Ajish Koshy Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b02c509ceef479e962ccc767425c7460fd5b5d06 Author: Ajish Koshy Date: Mon Apr 11 12:16:02 2022 +0530 scsi: pm80xx: Mask and unmask upper interrupt vectors 32-63 [ Upstream commit 294080eacf92a0781e6d43663448a55001ec8c64 ] When upper inbound and outbound queues 32-63 are enabled, we see upper vectors 32-63 in interrupt service routine. We need corresponding registers to handle masking and unmasking of these upper interrupts. To achieve this, we use registers MSGU_ODMR_U(0x34) to mask and MSGU_ODMR_CLR_U(0x3C) to unmask the interrupts. In these registers bit 0-31 represents interrupt vectors 32-63. Link: https://lore.kernel.org/r/20220411064603.668448-2-Ajish.Koshy@microchip.com Fixes: 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") Reviewed-by: John Garry Acked-by: Jack Wang Signed-off-by: Ajish Koshy Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3a523807f01455fe9a0c1a433f27cd4411ee400f Author: Karsten Graul Date: Fri Apr 8 17:10:34 2022 +0200 net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() [ Upstream commit d22f4f977236f97e01255a80bca2ea93a8094fc8 ] dev_name() was called with dev.parent as argument but without to NULL-check it before. Solve this by checking the pointer before the call to dev_name(). Fixes: af5f60c7e3d5 ("net/smc: allow PCI IDs as ib device names in the pnet table") Reported-by: syzbot+03e3e228510223dabd34@syzkaller.appspotmail.com Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 66b3107a4a0615decc7e9bfc4352a067380d3224 Author: Kuogee Hsieh Date: Fri Apr 8 14:04:54 2022 -0700 drm/msm/dp: add fail safe mode outside of event_mutex context [ Upstream commit 8b2c181e3dcf7562445af6702ee94aaedcbe13c8 ] There is possible circular locking dependency detected on event_mutex (see below logs). This is due to set fail safe mode is done at dp_panel_read_sink_caps() within event_mutex scope. To break this possible circular locking, this patch move setting fail safe mode out of event_mutex scope. [ 23.958078] ====================================================== [ 23.964430] WARNING: possible circular locking dependency detected [ 23.970777] 5.17.0-rc2-lockdep-00088-g05241de1f69e #148 Not tainted [ 23.977219] ------------------------------------------------------ [ 23.983570] DrmThread/1574 is trying to acquire lock: [ 23.988763] ffffff808423aab0 (&dp->event_mutex){+.+.}-{3:3}, at: msm_dp_displ ay_enable+0x58/0x164 [ 23.997895] [ 23.997895] but task is already holding lock: [ 24.003895] ffffff808420b280 (&kms->commit_lock[i]/1){+.+.}-{3:3}, at: lock_c rtcs+0x80/0x8c [ 24.012495] [ 24.012495] which lock already depends on the new lock. [ 24.012495] [ 24.020886] [ 24.020886] the existing dependency chain (in reverse order) is: [ 24.028570] [ 24.028570] -> #5 (&kms->commit_lock[i]/1){+.+.}-{3:3}: [ 24.035472] __mutex_lock+0xc8/0x384 [ 24.039695] mutex_lock_nested+0x54/0x74 [ 24.044272] lock_crtcs+0x80/0x8c [ 24.048222] msm_atomic_commit_tail+0x1e8/0x3d0 [ 24.053413] commit_tail+0x7c/0xfc [ 24.057452] drm_atomic_helper_commit+0x158/0x15c [ 24.062826] drm_atomic_commit+0x60/0x74 [ 24.067403] drm_mode_atomic_ioctl+0x6b0/0x908 [ 24.072508] drm_ioctl_kernel+0xe8/0x168 [ 24.077086] drm_ioctl+0x320/0x370 [ 24.081123] drm_compat_ioctl+0x40/0xdc [ 24.085602] __arm64_compat_sys_ioctl+0xe0/0x150 [ 24.090895] invoke_syscall+0x80/0x114 [ 24.095294] el0_svc_common.constprop.3+0xc4/0xf8 [ 24.100668] do_el0_svc_compat+0x2c/0x54 [ 24.105242] el0_svc_compat+0x4c/0xe4 [ 24.109548] el0t_32_sync_handler+0xc4/0xf4 [ 24.114381] el0t_32_sync+0x178 [ 24.118688] [ 24.118688] -> #4 (&kms->commit_lock[i]){+.+.}-{3:3}: [ 24.125408] __mutex_lock+0xc8/0x384 [ 24.129628] mutex_lock_nested+0x54/0x74 [ 24.134204] lock_crtcs+0x80/0x8c [ 24.138155] msm_atomic_commit_tail+0x1e8/0x3d0 [ 24.143345] commit_tail+0x7c/0xfc [ 24.147382] drm_atomic_helper_commit+0x158/0x15c [ 24.152755] drm_atomic_commit+0x60/0x74 [ 24.157323] drm_atomic_helper_set_config+0x68/0x90 [ 24.162869] drm_mode_setcrtc+0x394/0x648 [ 24.167535] drm_ioctl_kernel+0xe8/0x168 [ 24.172102] drm_ioctl+0x320/0x370 [ 24.176135] drm_compat_ioctl+0x40/0xdc [ 24.180621] __arm64_compat_sys_ioctl+0xe0/0x150 [ 24.185904] invoke_syscall+0x80/0x114 [ 24.190302] el0_svc_common.constprop.3+0xc4/0xf8 [ 24.195673] do_el0_svc_compat+0x2c/0x54 [ 24.200241] el0_svc_compat+0x4c/0xe4 [ 24.204544] el0t_32_sync_handler+0xc4/0xf4 [ 24.209378] el0t_32_sync+0x174/0x178 [ 24.213680] -> #3 (crtc_ww_class_mutex){+.+.}-{3:3}: [ 24.220308] __ww_mutex_lock.constprop.20+0xe8/0x878 [ 24.225951] ww_mutex_lock+0x60/0xd0 [ 24.230166] modeset_lock+0x190/0x19c [ 24.234467] drm_modeset_lock+0x34/0x54 [ 24.238953] drmm_mode_config_init+0x550/0x764 [ 24.244065] msm_drm_bind+0x170/0x59c [ 24.248374] try_to_bring_up_master+0x244/0x294 [ 24.253572] __component_add+0xf4/0x14c [ 24.258057] component_add+0x2c/0x38 [ 24.262273] dsi_dev_attach+0x2c/0x38 [ 24.266575] dsi_host_attach+0xc4/0x120 [ 24.271060] mipi_dsi_attach+0x34/0x48 [ 24.275456] devm_mipi_dsi_attach+0x28/0x68 [ 24.280298] ti_sn_bridge_probe+0x2b4/0x2dc [ 24.285137] auxiliary_bus_probe+0x78/0x90 [ 24.289893] really_probe+0x1e4/0x3d8 [ 24.294194] __driver_probe_device+0x14c/0x164 [ 24.299298] driver_probe_device+0x54/0xf8 [ 24.304043] __device_attach_driver+0xb4/0x118 [ 24.309145] bus_for_each_drv+0xb0/0xd4 [ 24.313628] __device_attach+0xcc/0x158 [ 24.318112] device_initial_probe+0x24/0x30 [ 24.322954] bus_probe_device+0x38/0x9c [ 24.327439] deferred_probe_work_func+0xd4/0xf0 [ 24.332628] process_one_work+0x2f0/0x498 [ 24.337289] process_scheduled_works+0x44/0x48 [ 24.342391] worker_thread+0x1e4/0x26c [ 24.346788] kthread+0xe4/0xf4 [ 24.350470] ret_from_fork+0x10/0x20 [ 24.354683] [ 24.354683] [ 24.354683] -> #2 (crtc_ww_class_acquire){+.+.}-{0:0}: [ 24.361489] drm_modeset_acquire_init+0xe4/0x138 [ 24.366777] drm_helper_probe_detect_ctx+0x44/0x114 [ 24.372327] check_connector_changed+0xbc/0x198 [ 24.377517] drm_helper_hpd_irq_event+0xcc/0x11c [ 24.382804] dsi_hpd_worker+0x24/0x30 [ 24.387104] process_one_work+0x2f0/0x498 [ 24.391762] worker_thread+0x1d0/0x26c [ 24.396158] kthread+0xe4/0xf4 [ 24.399840] ret_from_fork+0x10/0x20 [ 24.404053] [ 24.404053] -> #1 (&dev->mode_config.mutex){+.+.}-{3:3}: [ 24.411032] __mutex_lock+0xc8/0x384 [ 24.415247] mutex_lock_nested+0x54/0x74 [ 24.419819] dp_panel_read_sink_caps+0x23c/0x26c [ 24.425108] dp_display_process_hpd_high+0x34/0xd4 [ 24.430570] dp_display_usbpd_configure_cb+0x30/0x3c [ 24.436205] hpd_event_thread+0x2ac/0x550 [ 24.440864] kthread+0xe4/0xf4 [ 24.444544] ret_from_fork+0x10/0x20 [ 24.448757] [ 24.448757] -> #0 (&dp->event_mutex){+.+.}-{3:3}: [ 24.455116] __lock_acquire+0xe2c/0x10d8 [ 24.459690] lock_acquire+0x1ac/0x2d0 [ 24.463988] __mutex_lock+0xc8/0x384 [ 24.468201] mutex_lock_nested+0x54/0x74 [ 24.472773] msm_dp_display_enable+0x58/0x164 [ 24.477789] dp_bridge_enable+0x24/0x30 [ 24.482273] drm_atomic_bridge_chain_enable+0x78/0x9c [ 24.488006] drm_atomic_helper_commit_modeset_enables+0x1bc/0x244 [ 24.494801] msm_atomic_commit_tail+0x248/0x3d0 [ 24.499992] commit_tail+0x7c/0xfc [ 24.504031] drm_atomic_helper_commit+0x158/0x15c [ 24.509404] drm_atomic_commit+0x60/0x74 [ 24.513976] drm_mode_atomic_ioctl+0x6b0/0x908 [ 24.519079] drm_ioctl_kernel+0xe8/0x168 [ 24.523650] drm_ioctl+0x320/0x370 [ 24.527689] drm_compat_ioctl+0x40/0xdc [ 24.532175] __arm64_compat_sys_ioctl+0xe0/0x150 [ 24.537463] invoke_syscall+0x80/0x114 [ 24.541861] el0_svc_common.constprop.3+0xc4/0xf8 [ 24.547235] do_el0_svc_compat+0x2c/0x54 [ 24.551806] el0_svc_compat+0x4c/0xe4 [ 24.556106] el0t_32_sync_handler+0xc4/0xf4 [ 24.560948] el0t_32_sync+0x174/0x178 Changes in v2: -- add circular lockiing trace Fixes: d4aca422539c ("drm/msm/dp: always add fail-safe mode into connector mode list") Signed-off-by: Kuogee Hsieh Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/481396/ Link: https://lore.kernel.org/r/1649451894-554-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 815006c333914e8119e532017d4da1da91fcb5c7 Author: Stephen Boyd Date: Thu Mar 17 17:07:31 2022 -0700 drm/msm/dsi: Use connector directly in msm_dsi_manager_connector_init() [ Upstream commit 47b7de6b88b962ef339a2427a023d2a23d161654 ] The member 'msm_dsi->connector' isn't assigned until msm_dsi_manager_connector_init() returns (see msm_dsi_modeset_init() and how it assigns the return value). Therefore this pointer is going to be NULL here. Let's use 'connector' which is what was intended. Cc: Dmitry Baryshkov Cc: Sean Paul Fixes: 6d5e78406991 ("drm/msm/dsi: Move dsi panel init into modeset init path") Signed-off-by: Stephen Boyd Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/478693/ Link: https://lore.kernel.org/r/20220318000731.2823718-1-swboyd@chromium.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a6549b364be4cf8ca0bee910dbb89cf807c33afc Author: Rob Clark Date: Thu Apr 7 13:28:33 2022 -0700 drm/msm: Fix range size vs end confusion [ Upstream commit 537fef808be5ea56f6fc06932162550819a3b3c3 ] The fourth param is size, rather than range_end. Note that we could increase the address space size if we had a way to prevent buffers from spanning a 4G split, mostly just to avoid fw bugs with 64b math. Fixes: 84c31ee16f90 ("drm/msm/a6xx: Add support for per-instance pagetables") Signed-off-by: Rob Clark Link: https://lore.kernel.org/r/20220407202836.1211268-1-robdclark@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 1c86b7ea63ff059907fb7b2829fd17feda9740e7 Author: Florian Westphal Date: Sat Apr 9 13:20:19 2022 +0200 netfilter: nft_socket: make cgroup match work in input too [ Upstream commit 05ae2fba821c4d122ab4ba3e52144e21586c4010 ] cgroupv2 helper function ignores the already-looked up sk and uses skb->sk instead. Just pass sk from the calling function instead; this will make cgroup matching work for udp and tcp in input even when edemux did not set skb->sk already. Fixes: e0bb96db96f8 ("netfilter: nft_socket: add support for cgroupsv2") Signed-off-by: Florian Westphal Tested-by: Topi Miettinen Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 5a52384a513462a16335a26b9082b8a0edb24cda Author: Rameshkumar Sundaram Date: Mon Apr 11 14:37:51 2022 +0530 cfg80211: hold bss_lock while updating nontrans_list [ Upstream commit a5199b5626cd6913cf8776a835bc63d40e0686ad ] Synchronize additions to nontrans_list of transmitting BSS with bss_lock to avoid races. Also when cfg80211_add_nontrans_list() fails __cfg80211_unlink_bss() needs bss_lock to be held (has lockdep assert on bss_lock). So protect the whole block with bss_lock to avoid races and warnings. Found during code review. Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") Signed-off-by: Rameshkumar Sundaram Link: https://lore.kernel.org/r/1649668071-9370-1-git-send-email-quic_ramess@quicinc.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit d5be67ecbeff23eb64fd03b557a3df3415725ec5 Author: Benedikt Spranger Date: Fri Apr 8 11:47:45 2022 +0200 net/sched: taprio: Check if socket flags are valid [ Upstream commit e8a64bbaaad1f6548cec5508297bc6d45e8ab69e ] A user may set the SO_TXTIME socket option to ensure a packet is send at a given time. The taprio scheduler has to confirm, that it is allowed to send a packet at that given time, by a check against the packet time schedule. The scheduler drop the packet, if the gates are closed at the given send time. The check, if SO_TXTIME is set, may fail since sk_flags are part of an union and the union is used otherwise. This happen, if a socket is not a full socket, like a request socket for example. Add a check to verify, if the union is used for sk_flags. Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode") Signed-off-by: Benedikt Spranger Reviewed-by: Kurt Kanzenbach Acked-by: Vinicius Costa Gomes Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 62a48383ebe2e159fd68425dd3e16d4c6bd6599a Author: Dinh Nguyen Date: Thu Apr 7 08:25:21 2022 -0500 net: ethernet: stmmac: fix altr_tse_pcs function when using a fixed-link [ Upstream commit a6aaa00324240967272b451bfa772547bd576ee6 ] When using a fixed-link, the altr_tse_pcs driver crashes due to null-pointer dereference as no phy_device is provided to tse_pcs_fix_mac_speed function. Fix this by adding a check for phy_dev before calling the tse_pcs_fix_mac_speed() function. Also clean up the tse_pcs_fix_mac_speed function a bit. There is no need to check for splitter_base and sgmii_adapter_base because the driver will fail if these 2 variables are not derived from the device tree. Fixes: fb3bbdb85989 ("net: ethernet: Add TSE PCS support to dwmac-socfpga") Signed-off-by: Dinh Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 72f9c15854b09d05eae15e140f9cb1172d25b104 Author: Michael Walle Date: Fri Apr 8 12:15:21 2022 +0200 net: dsa: felix: suppress -EPROBE_DEFER errors [ Upstream commit e6934e4048c91502efcb21da92b7ae37cd8fa741 ] The DSA master might not have been probed yet in which case the probe of the felix switch fails with -EPROBE_DEFER: [ 4.435305] mscc_felix 0000:00:00.5: Failed to register DSA switch: -517 It is not an error. Use dev_err_probe() to demote this particular error to a debug message. Fixes: 56051948773e ("net: dsa: ocelot: add driver for Felix switch family") Signed-off-by: Michael Walle Reviewed-by: Vladimir Oltean Link: https://lore.kernel.org/r/20220408101521.281886-1-michael@walle.cc Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 13faa76cf57239e833be3257e9ff42080d1c5bbc Author: Marcelo Ricardo Leitner Date: Thu Apr 7 11:29:23 2022 -0300 net/sched: fix initialization order when updating chain 0 head [ Upstream commit e65812fd22eba32f11abe28cb377cbd64cfb1ba0 ] Currently, when inserting a new filter that needs to sit at the head of chain 0, it will first update the heads pointer on all devices using the (shared) block, and only then complete the initialization of the new element so that it has a "next" element. This can lead to a situation that the chain 0 head is propagated to another CPU before the "next" initialization is done. When this race condition is triggered, packets being matched on that CPU will simply miss all other filters, and will flow through the stack as if there were no other filters installed. If the system is using OVS + TC, such packets will get handled by vswitchd via upcall, which results in much higher latency and reordering. For other applications it may result in packet drops. This is reproducible with a tc only setup, but it varies from system to system. It could be reproduced with a shared block amongst 10 veth tunnels, and an ingress filter mirroring packets to another veth. That's because using the last added veth tunnel to the shared block to do the actual traffic, it makes the race window bigger and easier to trigger. The fix is rather simple, to just initialize the next pointer of the new filter instance (tp) before propagating the head change. The fixes tag is pointing to the original code though this issue should only be observed when using it unlocked. Fixes: 2190d1d0944f ("net: sched: introduce helpers to work with filter chains") Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: Vlad Buslov Reviewed-by: Davide Caratti Link: https://lore.kernel.org/r/b97d5f4eaffeeb9d058155bcab63347527261abf.1649341369.git.marcelo.leitner@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 4c979e6fcec8a7fe6912f49ada27f8725522af9a Author: Vadim Pasternak Date: Thu Apr 7 10:07:03 2022 +0300 mlxsw: i2c: Fix initialization error flow [ Upstream commit d452088cdfd5a4ad9d96d847d2273fe958d6339b ] Add mutex_destroy() call in driver initialization error flow. Fixes: 6882b0aee180f ("mlxsw: Introduce support for I2C bus") Signed-off-by: Vadim Pasternak Signed-off-by: Ido Schimmel Link: https://lore.kernel.org/r/20220407070703.2421076-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 152b813d8ba55d01a27962d30091485d019eed8e Author: Vladimir Oltean Date: Thu Apr 7 19:55:38 2022 +0300 net: mdio: don't defer probe forever if PHY IRQ provider is missing [ Upstream commit 74befa447e6839cdd90ed541159ec783726946f9 ] When a driver for an interrupt controller is missing, of_irq_get() returns -EPROBE_DEFER ad infinitum, causing fwnode_mdiobus_phy_device_register(), and ultimately, the entire of_mdiobus_register() call, to fail. In turn, any phy_connect() call towards a PHY on this MDIO bus will also fail. This is not what is expected to happen, because the PHY library falls back to poll mode when of_irq_get() returns a hard error code, and the MDIO bus, PHY and attached Ethernet controller work fine, albeit suboptimally, when the PHY library polls for link status. However, -EPROBE_DEFER has special handling given the assumption that at some point probe deferral will stop, and the driver for the supplier will kick in and create the IRQ domain. Reasons for which the interrupt controller may be missing: - It is not yet written. This may happen if a more recent DT blob (with an interrupt-parent for the PHY) is used to boot an old kernel where the driver didn't exist, and that kernel worked with the vintage-correct DT blob using poll mode. - It is compiled out. Behavior is the same as above. - It is compiled as a module. The kernel will wait for a number of seconds specified in the "deferred_probe_timeout" boot parameter for user space to load the required module. The current default is 0, which times out at the end of initcalls. It is possible that this might cause regressions unless users adjust this boot parameter. The proposed solution is to use the driver_deferred_probe_check_state() helper function provided by the driver core, which gives up after some -EPROBE_DEFER attempts, taking "deferred_probe_timeout" into consideration. The return code is changed from -EPROBE_DEFER into -ENODEV or -ETIMEDOUT, depending on whether the kernel is compiled with support for modules or not. Fixes: 66bdede495c7 ("of_mdio: Fix broken PHY IRQ in case of probe deferral") Suggested-by: Robin Murphy Signed-off-by: Vladimir Oltean Acked-by: Greg Kroah-Hartman Reviewed-by: Florian Fainelli Link: https://lore.kernel.org/r/20220407165538.4084809-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 675e7d3086d0aa360b6ce856ce55cd003589f9ad Author: Shyam Prasad N Date: Fri Apr 1 06:25:17 2022 +0000 cifs: release cached dentries only if mount is complete [ Upstream commit d788e51636462e61c6883f7d96b07b06bc291650 ] During cifs_kill_sb, we first dput all the dentries that we have cached. However this function can also get called for mount failures. So dput the cached dentries only if the filesystem mount is complete. i.e. cifs_sb->root is populated. Fixes: 5e9c89d43fa6 ("cifs: Grab a reference for the dentry of the cached directory during the lifetime of the cache") Signed-off-by: Shyam Prasad N Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit d40cf3492277d203c1f676cb9df88ab55d0c5d0f Author: Linus Torvalds Date: Sat Mar 19 16:21:09 2022 -0700 gpiolib: acpi: use correct format characters [ Upstream commit 213d266ebfb1621aab79cfe63388facc520a1381 ] When compiling with -Wformat, clang emits the following warning: gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat] pin); ^~~ So warning that '%hhX' is paired with an 'int' is all just completely mindless and wrong. Sadly, I can see a different bogus warning reason why people would want to use '%02hhX'. Again, the *sane* thing from a human perspective is to use '%02X. But if the compiler doesn't do any range analysis at all, it could decide that "Oh, that print format could need up to 8 bytes of space in the result". Using '%02hhX' would cut that down to two. And since we use char ev_name[5]; and currently use "_%c%02hhX" as the format string, even a compiler that doesn't notice that "pin <= 255" test that guards this all will go "OK, that's at most 4 bytes and the final NUL termination, so it's fine". While a compiler - like gcc - that only sees that the original source of the 'pin' value is a 'unsigned short' array, and then doesn't take the "pin <= 255" into account, will warn like this: gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt': gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=] sprintf(ev_name, "_%c%02X", ^~~~ gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535] because gcc isn't being very good at that argument range analysis either. In other words, the original use of 'hhx' was bogus to begin with, and due to *another* compiler warning being bad, and we had that bad code being written back in 2016 to work around _that_ compiler warning (commit e40a3ae1f794: "gpio: acpi: work around false-positive -Wstring-overflow warning"). Sadly, two different bad compiler warnings together does not make for one good one. It just makes for even more pain. End result: I think the simplest and cleanest option is simply the proposed change which undoes that '%hhX' change for gcc, and replaces it with just using a slightly bigger stack allocation. It's not like a 5-byte allocation is in any way likely to have saved any actual stack, since all the other variables in that function are 'int' or bigger. False-positive compiler warnings really do make people write worse code, and that's a problem. But on a scale of bad code, I feel that extending the buffer trivially is better than adding a pointless cast that literally makes no sense. At least in this case the end result isn't unreadable or buggy. We've had several cases of bad compiler warnings that caused changes that were actually horrendously wrong. Fixes: e40a3ae1f794 ("gpio: acpi: work around false-positive -Wstring-overflow warning") Signed-off-by: Linus Torvalds Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 93940fc4cb81840dc0fa202de48cccb949a0261d Author: Guillaume Nault Date: Wed Apr 6 16:18:54 2022 +0200 veth: Ensure eth header is in skb's linear part [ Upstream commit 726e2c5929de841fdcef4e2bf995680688ae1b87 ] After feeding a decapsulated packet to a veth device with act_mirred, skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(), which expects at least ETH_HLEN byte of linear data (as __dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes unconditionally). Use pskb_may_pull() to ensure veth_xmit() respects this constraint. kernel BUG at include/linux/skbuff.h:2328! RIP: 0010:eth_type_trans+0xcf/0x140 Call Trace: __dev_forward_skb2+0xe3/0x160 veth_xmit+0x6e/0x250 [veth] dev_hard_start_xmit+0xc7/0x200 __dev_queue_xmit+0x47f/0x520 ? skb_ensure_writable+0x85/0xa0 ? skb_mpls_pop+0x98/0x1c0 tcf_mirred_act+0x442/0x47e [act_mirred] tcf_action_exec+0x86/0x140 fl_classify+0x1d8/0x1e0 [cls_flower] ? dma_pte_clear_level+0x129/0x1a0 ? dma_pte_clear_level+0x129/0x1a0 ? prb_fill_curr_block+0x2f/0xc0 ? skb_copy_bits+0x11a/0x220 __tcf_classify+0x58/0x110 tcf_classify_ingress+0x6b/0x140 __netif_receive_skb_core.constprop.0+0x47d/0xfd0 ? __iommu_dma_unmap_swiotlb+0x44/0x90 __netif_receive_skb_one_core+0x3d/0xa0 netif_receive_skb+0x116/0x170 be_process_rx+0x22f/0x330 [be2net] be_poll+0x13c/0x370 [be2net] __napi_poll+0x2a/0x170 net_rx_action+0x22f/0x2f0 __do_softirq+0xca/0x2a8 __irq_exit_rcu+0xc1/0xe0 common_interrupt+0x83/0xa0 Fixes: e314dbdc1c0d ("[NET]: Virtual ethernet device driver.") Signed-off-by: Guillaume Nault Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit de8a332c86a784431e1991be053704f2662239c1 Author: Vlad Buslov Date: Wed Apr 6 14:22:41 2022 +0300 net/sched: flower: fix parsing of ethertype following VLAN header [ Upstream commit 2105f700b53c24aa48b65c15652acc386044d26a ] A tc flower filter matching TCA_FLOWER_KEY_VLAN_ETH_TYPE is expected to match the L2 ethertype following the first VLAN header, as confirmed by linked discussion with the maintainer. However, such rule also matches packets that have additional second VLAN header, even though filter has both eth_type and vlan_ethtype set to "ipv4". Looking at the code this seems to be mostly an artifact of the way flower uses flow dissector. First, even though looking at the uAPI eth_type and vlan_ethtype appear like a distinct fields, in flower they are all mapped to the same key->basic.n_proto. Second, flow dissector skips following VLAN header as no keys for FLOW_DISSECTOR_KEY_CVLAN are set and eventually assigns the value of n_proto to last parsed header. With these, such filters ignore any headers present between first VLAN header and first "non magic" header (ipv4 in this case) that doesn't result FLOW_DISSECT_RET_PROTO_AGAIN. Fix the issue by extending flow dissector VLAN key structure with new 'vlan_eth_type' field that matches first ethertype following previously parsed VLAN header. Modify flower classifier to set the new flow_dissector_key_vlan->vlan_eth_type with value obtained from TCA_FLOWER_KEY_VLAN_ETH_TYPE/TCA_FLOWER_KEY_CVLAN_ETH_TYPE uAPIs. Link: https://lore.kernel.org/all/Yjhgi48BpTGh6dig@nanopsycho/ Fixes: 9399ae9a6cb2 ("net_sched: flower: Add vlan support") Fixes: d64efd0926ba ("net/sched: flower: Add supprt for matching on QinQ vlan headers") Signed-off-by: Vlad Buslov Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 726ae7300fcc25fefa46d188cc07eb16dc908f9e Author: Chuck Lever Date: Wed Apr 6 13:51:32 2022 -0400 SUNRPC: Fix the svc_deferred_event trace class [ Upstream commit 4d5004451ab2218eab94a30e1841462c9316ba19 ] Fix a NULL deref crash that occurs when an svc_rqst is deferred while the sunrpc tracing subsystem is enabled. svc_revisit() sets dr->xprt to NULL, so it can't be relied upon in the tracepoint to provide the remote's address. Unfortunately we can't revert the "svc_deferred_class" hunk in commit ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") because there is now a specific check of event format specifiers for unsafe dereferences. The warning that check emits is: event svc_defer_recv has unsafe dereference of argument 1 A "%pISpc" format specifier with a "struct sockaddr *" is indeed flagged by this check. Instead, take the brute-force approach used by the svcrdma_qp_error tracepoint. Convert the dr::addr field into a presentation address in the TP_fast_assign() arm of the trace event, and store that as a string. This fix can be backported to -stable kernels. In the meantime, commit c6ced22997ad ("tracing: Update print fmt check to handle new __get_sockaddr() macro") is now in v5.18, so this wonky fix can be replaced with __sockaddr() and friends properly during the v5.19 merge window. Fixes: ece200ddd54b ("sunrpc: Save remote presentation address in svc_xprt for trace events") Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit ec2ab59b9e66cf3194ef67259babdbab585a7a53 Author: Kyle Copperfield Date: Sat Nov 20 13:23:02 2021 +0100 media: rockchip/rga: do proper error checking in probe [ Upstream commit 6150f276073a1480030242a7e006a89e161d6cd6 ] The latest fix for probe error handling contained a typo that causes probing to fail with the following message: rockchip-rga: probe of ff680000.rga failed with error -12 This patch fixes the typo. Fixes: e58430e1d4fd (media: rockchip/rga: fix error handling in probe) Reviewed-by: Dragan Simic Signed-off-by: Kyle Copperfield Reviewed-by: Kieran Bingham Reviewed-by: Dan Carpenter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b0d8a9eb323972b2632531063ef5972e1c0c73aa Author: Cristian Marussi Date: Fri Mar 18 09:28:13 2022 +0000 firmware: arm_scmi: Fix sorting of retrieved clock rates [ Upstream commit 23274739a5b6166f74d8d9cb5243d7bf6b46aab9 ] During SCMI Clock protocol initialization, after having retrieved from the SCMI platform all the available discrete rates for a specific clock, the clock rates array is sorted, unfortunately using a pointer to its end as a base instead of its start, so that sorting does not work. Fix invocation of sort() passing as base a pointer to the start of the retrieved clock rates array. Link: https://lore.kernel.org/r/20220318092813.49283-1-cristian.marussi@arm.com Fixes: dccec73de91d ("firmware: arm_scmi: Keep the discrete clock rates sorted") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit e2da8f9ce3ea5d458b746b3a166f63d92d38bd36 Author: Anilkumar Kolli Date: Thu Mar 31 10:07:57 2022 +0530 Revert "ath11k: mesh: add support for 256 bitmap in blockack frames in 11ax" [ Upstream commit 10cb21f4ff3f9cb36d1e1c39bf80426f02f4986a ] This reverts commit 743b9065fe6348a5f8f5ce04869ce2d701e5e1bc. The original commit breaks the 256 bitmap in blockack frames in AP mode. After reverting the commit the feature works again in both AP and mesh modes Tested-on: IPQ8074 hw2.0 PCI WLAN.HK.2.6.0.1-00786-QCAHKSWPL_SILICONZ-1 Fixes: 743b9065fe63 ("ath11k: mesh: add support for 256 bitmap in blockack frames in 11ax") Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1648701477-16367-1-git-send-email-quic_akolli@quicinc.com Signed-off-by: Sasha Levin commit 9f029cb2c92ecec2ae899bcef770c15e8f68f973 Author: Miaoqian Lin Date: Wed Mar 9 11:01:43 2022 +0000 memory: atmel-ebi: Fix missing of_node_put in atmel_ebi_probe [ Upstream commit 6f296a9665ba5ac68937bf11f96214eb9de81baa ] The device_node pointer is returned by of_parse_phandle() with refcount incremented. We should use of_node_put() on it when done. Fixes: 87108dc78eb8 ("memory: atmel-ebi: Enable the SMC clock if specified") Signed-off-by: Miaoqian Lin Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20220309110144.22412-1-linmq006@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit e7b1992b07225cedd682f04a12fad28c7dedef2c Author: Cristian Marussi Date: Thu Feb 24 15:24:04 2022 +0000 firmware: arm_scmi: Remove clear channel call on the TX channel [ Upstream commit 98f0d68f94ea21541e0050cc64fa108ade779839 ] On SCMI transports whose channels are based on a shared resource the TX channel area has to be acquired by the agent before placing the desired command into the channel and it will be then relinquished by the platform once the related reply has been made available into the channel. On an RX channel the logic is reversed with the platform acquiring the channel area and the agent reliquishing it once done by calling the scmi_clear_channel() helper. As a consequence, even in case of error, the agent must never try to clear a TX channel from its side: restrict the existing clear channel call on the the reply path only to delayed responses since they are indeed coming from the RX channel. Link: https://lore.kernel.org/r/20220224152404.12877-1-cristian.marussi@arm.com Fixes: e9b21c96181c ("firmware: arm_scmi: Make .clear_channel optional") Signed-off-by: Cristian Marussi Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 77ffc38e577dcf6ff01604a01efd78cb629f36ab Author: Rob Clark Date: Thu Mar 17 11:45:49 2022 -0700 drm/msm: Add missing put_task_struct() in debugfs path [ Upstream commit ac3e4f42d5ec459f701743debd9c1ad2f2247402 ] Fixes: 25faf2f2e065 ("drm/msm: Show process names in gem_describe") Signed-off-by: Rob Clark Link: https://lore.kernel.org/r/20220317184550.227991-1-robdclark@gmail.com Signed-off-by: Sasha Levin commit aa4845194b9dd5fa19b34997619a31cbf9a223fb Author: Takashi Iwai Date: Tue Apr 12 12:26:36 2022 +0200 ALSA: nm256: Don't call card private_free at probe error path commit f20ae5074dfb38f23b0c07c62bdf8e7254a0acf8 upstream. The card destructor of nm256 driver does merely stopping the running streams, and it's superfluous for the probe error handling. Moreover, calling this via the previous devres change would lead to another problem due to the reverse call order. This patch moves the setup of the private_free callback after the card registration, so that it can be used only after fully set up. Fixes: c19935f04784 ("ALSA: nm256: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-40-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 425c83e2898d1304206bd8a580dfc2e6c3e95334 Author: Takashi Iwai Date: Thu Apr 7 23:16:57 2022 +0200 ALSA: usb-audio: Cap upper limits of buffer/period bytes for implicit fb commit 98c27add5d96485db731a92dac31567b0486cae8 upstream. In the implicit feedback mode, some parameters are tied between both playback and capture streams. One of the tied parameters is the period size, and this can be a problem if the device has different number of channels to both streams. Assume that an application opens a playback stream that has an implicit feedback from a capture stream, and it allocates up to the max period and buffer size as much as possible. When the capture device supports only more channels than the playback, the minimum period and buffer sizes become larger than the sizes the playback stream took. That is, the minimum size will be over the max size the driver limits, and PCM core sees as if no available configuration is found, returning -EINVAL mercilessly. For avoiding this problem, we have to look through the counter part of audioformat list for each sync ep, and checks the channels. If more channels are found there, we reduce the max period and buffer sizes accordingly. You may wonder that the patch adds only the evaluation of channels between streams, and what about other parameters? Both the format and the rate are tied in the implicit fb mode, hence they are always identical. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215792 Fixes: 5a6c3e11c9c9 ("ALSA: usb-audio: Add hw constraint for implicit fb sync") Cc: Link: https://lore.kernel.org/r/20220407211657.15087-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3bbd4850d957c9757903c656f25b669eb937d357 Author: Takashi Iwai Date: Tue Apr 12 12:26:22 2022 +0200 ALSA: via82xx: Fix the missing snd_card_free() call at probe error commit 27a0963f9cea5be3c68281f07fe82cdf712ef333 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: afaf99751d0c ("ALSA: via82xx: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-26-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 56e44ff13d841cbb8638e7ec7759240a556752cd Author: Takashi Iwai Date: Tue Apr 12 12:26:21 2022 +0200 ALSA: sonicvibes: Fix the missing snd_card_free() call at probe error commit b087a381d7386ec95803222d0d9b1ac499550713 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 2ca6cbde6ad7 ("ALSA: sonicvibes: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-25-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 73229d7cb836271c3698d2602cd1bfa7c3777f11 Author: Takashi Iwai Date: Tue Apr 12 12:25:59 2022 +0200 ALSA: sc6000: Fix the missing snd_card_free() call at probe error commit d72458071150b802940204950d0d462ea3c913b1 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 111601ff76e9 ("ALSA: sc6000: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit df03ce487e1bfc23d82e68e68f292938d66b87d9 Author: Takashi Iwai Date: Tue Apr 12 12:26:20 2022 +0200 ALSA: rme96: Fix the missing snd_card_free() call at probe error commit 93b884f8d82f08c7af542703a724cc23cd2d5bfc upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: df06df7cc997 ("ALSA: rme96: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-24-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ef4c35339414013039ebda3d5106453767028f35 Author: Takashi Iwai Date: Tue Apr 12 12:26:34 2022 +0200 ALSA: rme9652: Fix the missing snd_card_free() call at probe error commit b2aa4f80693b7841e5ac4eadbd2d8cec56b10a51 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: b1002b2d41c5 ("ALSA: rme9652: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-38-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4efa63663c3607c47d7497547dcd1a47303d7d74 Author: Takashi Iwai Date: Tue Apr 12 12:26:19 2022 +0200 ALSA: rme32: Fix the missing snd_card_free() call at probe error commit 55d2d046b23b9bcb907f6b3e38e52113d55085eb upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 102e6156ded2 ("ALSA: rme32: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-23-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bb94f5d98511a13ef70346cf14ff39776267daa8 Author: Takashi Iwai Date: Tue Apr 12 12:26:18 2022 +0200 ALSA: riptide: Fix the missing snd_card_free() call at probe error commit 348f08de55b149e41a05111d1a713c4484e5a426 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 546c201a891e ("ALSA: riptide: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-22-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4ecd10217df660a0398cadcddbbca297f1e0077a Author: Takashi Iwai Date: Tue Apr 12 12:26:31 2022 +0200 ALSA: oxygen: Fix the missing snd_card_free() call at probe error commit 6ebc16e206aa82ddb0450c907865c55bcb7c0f43 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 596ae97ab0ce ("ALSA: oxygen: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-35-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 30b86477daaa2c074aa4446565db4efb3033561f Author: Takashi Iwai Date: Tue Apr 12 12:26:17 2022 +0200 ALSA: maestro3: Fix the missing snd_card_free() call at probe error commit ae86bf5c2a8d81418eadf1c31dd9253b609e3093 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 5c0939253c3c ("ALSA: maestro3: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-21-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5fbb73cb1208432ae074386f0d969de9c08614e4 Author: Takashi Iwai Date: Tue Apr 12 12:26:30 2022 +0200 ALSA: lx6464es: Fix the missing snd_card_free() call at probe error commit 60797a21dd8360a99ba797f8ca587087c07bb54c upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 6f16c19b115e ("ALSA: lx6464es: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-34-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0651442d22e2b0a00d2c4df58bd05e859df7241f Author: Takashi Iwai Date: Tue Apr 12 12:26:26 2022 +0200 ALSA: lola: Fix the missing snd_card_free() call at probe error commit d04e84b9817c652002f0ee9b42059d41493e9118 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 098fe3d6e775 ("ALSA: lola: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-30-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0bec8b8a57de4777359b1d3166cc73cd7db34ef9 Author: Takashi Iwai Date: Tue Apr 12 12:26:16 2022 +0200 ALSA: korg1212: Fix the missing snd_card_free() call at probe error commit c01b723a56ce18ae66ff18c5803942badc15fbcd upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: b5cde369b618 ("ALSA: korg1212: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-20-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d9ac5256de1f7767504f480efbf7731ead0fe922 Author: Takashi Iwai Date: Tue Apr 12 12:26:23 2022 +0200 ALSA: intel_hdmi: Fix the missing snd_card_free() call at probe error commit 5e154dfb4f9995096aa6d342df75040ae802c17e upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 854577ac2aea ("ALSA: x86: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-27-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e87b8d0ba455b92ef8624d3962d65ebc08c1f868 Author: Takashi Iwai Date: Tue Apr 12 12:26:15 2022 +0200 ALSA: intel8x0: Fix the missing snd_card_free() call at probe error commit 71b21f5f8970a87f034138454ebeff0608d24875 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 7835e0901e24 ("ALSA: intel8x0: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-19-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 547c9af67b4edb6193bf03fa766de3fa14a55629 Author: Takashi Iwai Date: Tue Apr 12 12:26:14 2022 +0200 ALSA: ice1724: Fix the missing snd_card_free() call at probe error commit 4a850a0079ce601c0c4016f4edb7d618e811ed7d upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 314f6dbb1f33 ("ALSA: ice1724: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-18-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 141abcbf902a93a66cd22c2662f6139ff5ee237e Author: Takashi Iwai Date: Tue Apr 12 12:26:33 2022 +0200 ALSA: hdspm: Fix the missing snd_card_free() call at probe error commit eab521aebcdeb1c801009503e3a7f8989e3c6b36 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 0195ca5fd1f4 ("ALSA: hdspm: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-37-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f006a4bcf8bb7096ec37356b09112a1f6bd68393 Author: Takashi Iwai Date: Tue Apr 12 12:26:32 2022 +0200 ALSA: hdsp: Fix the missing snd_card_free() call at probe error commit e2263f0bf7443a200a5c1c418baefd92f1674600 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: d136b8e54f92 ("ALSA: hdsp: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-36-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 85515309293ba59f5767f3894151a76f81771494 Author: Takashi Iwai Date: Tue Apr 12 12:25:58 2022 +0200 ALSA: galaxy: Fix the missing snd_card_free() call at probe error commit 10b1881a97be240126891cb384bd3bc1869f52d8 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 35a245ec0619 ("ALSA: galaxy: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 841e8f8dd21f9ad3a0a6dc9d34eee28cb2ebb1ff Author: Takashi Iwai Date: Tue Apr 12 12:26:13 2022 +0200 ALSA: fm801: Fix the missing snd_card_free() call at probe error commit 7f611274a3d1657a67b3fa8cd0cec1dee00e02b4 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 47c413395376 ("ALSA: fm801: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-17-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3a738f1b3ffd3e8079e677b71f667f425cbddcee Author: Takashi Iwai Date: Tue Apr 12 12:26:12 2022 +0200 ALSA: es1968: Fix the missing snd_card_free() call at probe error commit de9a01bc95a9e5e36d0659521bb04579053d8566 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: a7b4cbfdc701 ("ALSA: es1968: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-16-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d3c6ac7a051c5cd4049ce72e1c6d8856d665d65c Author: Takashi Iwai Date: Tue Apr 12 12:26:11 2022 +0200 ALSA: es1938: Fix the missing snd_card_free() call at probe error commit bc22628591e5913e67edb3c2a89b97849e30a8f8 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 08e9d3ab4cc1 ("ALSA: es1938: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-15-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 20b35ba7aa2f961792f1f1774a6ba8e765c117d8 Author: Takashi Iwai Date: Tue Apr 12 12:26:10 2022 +0200 ALSA: ens137x: Fix the missing snd_card_free() call at probe error commit c2dc46932d117a1505f589ad1db3095aa6789058 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 10ed6eaf9d72 ("ALSA: ens137x: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-14-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0d52c09f0c17516d09b1aee6cd86ecc0a8b567da Author: Takashi Iwai Date: Tue Apr 12 12:26:09 2022 +0200 ALSA: emu10k1x: Fix the missing snd_card_free() call at probe error commit f37019b6bfe2e13cc536af0e6a42ed62005392ae upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 2b377c6b6012 ("ALSA: emu10k1x: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-13-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2a2a75ebdbd4bb7763f075da01f067189a386b03 Author: Takashi Iwai Date: Tue Apr 12 11:31:41 2022 +0200 ALSA: echoaudio: Fix the missing snd_card_free() call at probe error commit 313c7e57035125cb7533b53ddd0bc7aa562b433c upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 9c211bf392bb ("ALSA: echoaudio: Allocate resources with device-managed APIs") Reported-and-tested-by: Zheyu Ma Cc: Link: https://lore.kernel.org/r/CAMhUBjm2AdyEZ_-EgexdNDN7SvY4f89=4=FwAL+c0Mg0O+X50A@mail.gmail.com Link: https://lore.kernel.org/r/20220412093141.8008-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 648e89e9de299dea53345af9e0cca2811e7fee0e Author: Takashi Iwai Date: Tue Apr 12 12:26:08 2022 +0200 ALSA: cs5535audio: Fix the missing snd_card_free() call at probe error commit 2a56314798e0227cf51e3d1d184a419dc07bc173 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). Fixes: 5eba4c646dfe ("ALSA: cs5535audio: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-12-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9decc5bfd173274aea6134cd0cf66c3ccd6f2134 Author: Takashi Iwai Date: Tue Apr 12 12:26:07 2022 +0200 ALSA: cs4281: Fix the missing snd_card_free() call at probe error commit 9bf5ed9a4e623583f15202d99f4521bc39050f61 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 99041fea70d0 ("ALSA: cs4281: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-11-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 2dde476107578e22d31799847a3f50cf1f7278b6 Author: Takashi Iwai Date: Tue Apr 12 12:26:29 2022 +0200 ALSA: cmipci: Fix the missing snd_card_free() call at probe error commit a59396b1c11823c69c31621198c04def17f3a869 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 87e082ad84a7 ("ALSA: cmipci: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-33-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f98476228801fe212e7d6f06ac45e8b38a6f141e Author: Takashi Iwai Date: Tue Apr 12 12:26:06 2022 +0200 ALSA: ca0106: Fix the missing snd_card_free() call at probe error commit c79442cc5a38e46597bc647128c8f1de62d80020 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 1656fa6ea258 ("ALSA: ca0106: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-10-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e5a54e236f701528a0973fd96cf7a9d22f441d18 Author: Takashi Iwai Date: Tue Apr 12 12:26:25 2022 +0200 ALSA: bt87x: Fix the missing snd_card_free() call at probe error commit f0438155273f057fec9818bc9d1b782ba35cf6a1 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 9e80ed64a006 ("ALSA: bt87x: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-29-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 935629ba096ef384d72e39568316a89a36d39231 Author: Takashi Iwai Date: Tue Apr 12 12:26:05 2022 +0200 ALSA: azt3328: Fix the missing snd_card_free() call at probe error commit 49fe36e1c02cb06f66689c888e4e767c31cd259d upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 8c5823ef31e1 ("ALSA: azt3328: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-9-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3a943321c36296f6b5e3b4df6d6cf231e2ba35a8 Author: Takashi Iwai Date: Tue Apr 12 12:26:28 2022 +0200 ALSA: aw2: Fix the missing snd_card_free() call at probe error commit bf4067e8a19eae67c45659a956c361d59251ba57 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 33631012cd06 ("ALSA: aw2: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-32-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 811a92b866a0cabca6bc87e0c9e5e7c086a6d7ee Author: Takashi Iwai Date: Tue Apr 12 12:26:04 2022 +0200 ALSA: au88x0: Fix the missing snd_card_free() call at probe error commit b093de145bc8769c6e9207947afad9efe102f4f6 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: e44b5b440609 ("ALSA: au88x0: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-8-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit ea61c1bd582b1163c54bfbb81f6de5755213e6ba Author: Takashi Iwai Date: Tue Apr 12 12:26:03 2022 +0200 ALSA: atiixp: Fix the missing snd_card_free() call at probe error commit 48e8adde8d1c586c799dab123fc1ebc8b8db620f upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 86bde74dbf09 ("ALSA: atiixp: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-7-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 007a9b5554e17fd240d22c9e9df4800024247c8c Author: Takashi Iwai Date: Tue Apr 12 12:26:02 2022 +0200 ALSA: als4000: Fix the missing snd_card_free() call at probe error commit d616a0246da88d811f9f4c3aa83003c05efd3af0 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 0e175f665960 ("ALSA: als4000: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-6-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 291d9e5e94d0589223b09578c9c47c643c72295a Author: Takashi Iwai Date: Tue Apr 12 12:26:27 2022 +0200 ALSA: als300: Fix the missing snd_card_free() call at probe error commit ab8bce9da6102c575c473c053672547589bc4c59 upstream. The previous cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() manually on the error from the probe callback. Fixes: 21a9314cf93b ("ALSA: als300: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-31-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5bc1564090255177b0fc66e55a80d966d14e14ab Author: Takashi Iwai Date: Tue Apr 12 12:26:01 2022 +0200 ALSA: ali5451: Fix the missing snd_card_free() call at probe error commit 19401a9441236cfbbbeb1bef4ef4c8668db45dfc upstream. The recent cleanup with devres may lead to the incorrect release orders at the probe error handling due to the devres's nature. Until we register the card, snd_card_free() has to be called at first for releasing the stuff properly when the driver tries to manage and release the stuff via card->private_free(). This patch fixes it by calling snd_card_free() on the error from the probe callback using a new helper function. Fixes: 1f0819979248 ("ALSA: ali5451: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-5-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit cfa98d6c41e0aff27a827cf8091dbec43584784e Author: Takashi Iwai Date: Tue Apr 12 12:26:24 2022 +0200 ALSA: sis7019: Fix the missing error handling commit 2236a3243ff8291e97c70097dd11a0fdb8904380 upstream. The previous cleanup with devres forgot to replace the snd_card_free() call with the devm version. Moreover, it still needs the manual call of snd_card_free() at the probe error path, otherwise the reverse order of the releases may happen. This patch addresses those issues. Fixes: 499ddc16394c ("ALSA: sis7019: Allocate resources with device-managed APIs") Cc: Link: https://lore.kernel.org/r/20220412102636.16000-28-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1479bdea76dd83222af1b0b232bd9335db69dce0 Author: Takashi Iwai Date: Tue Apr 12 11:31:40 2022 +0200 ALSA: core: Add snd_card_free_on_error() helper commit fee2b871d8d6389c9b4bdf9346a99ccc1c98c9b8 upstream. This is a small helper function to handle the error path more easily when an error happens during the probe for the device with the device-managed card. Since devres releases in the reverser order of the creations, usually snd_card_free() gets called at the last in the probe error path unless it already reached snd_card_register() calls. Due to this nature, when a driver expects the resource releases in card->private_free, this might be called too lately. As a workaround, one should call the probe like: static int __some_probe(...) { // do real probe.... } static int some_probe(...) { return snd_card_free_on_error(dev, __some_probe(dev, ...)); } so that the snd_card_free() is called explicitly at the beginning of the error path from the probe. This function will be used in the upcoming fixes to address the regressions by devres usages. Fixes: e8ad415b7a55 ("ALSA: core: Add managed card creation") Cc: Link: https://lore.kernel.org/r/20220412093141.8008-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 07cacfd9d9dc134557ac8866c73d570a59b3d1f3 Author: Naohiro Aota Date: Mon Mar 28 21:32:05 2022 +0900 btrfs: release correct delalloc amount in direct IO write path commit 6d82ad13c4110e73c7b0392f00534a1502a1b520 upstream. Running generic/406 causes the following WARNING in btrfs_destroy_inode() which tells there are outstanding extents left. In btrfs_get_blocks_direct_write(), we reserve a temporary outstanding extents with btrfs_delalloc_reserve_metadata() (or indirectly from btrfs_delalloc_reserve_space(()). We then release the outstanding extents with btrfs_delalloc_release_extents(). However, the "len" can be modified in the COW case, which releases fewer outstanding extents than expected. Fix it by calling btrfs_delalloc_release_extents() for the original length. To reproduce the warning, the filesystem should be 1 GiB. It's triggering a short-write, due to not being able to allocate a large extent and instead allocating a smaller one. WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs] Modules linked in: btrfs blake2b_generic xor lzo_compress lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram zsmalloc CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014 RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs] RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206 RAX: 0000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000 RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78 RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8 R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800 R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68 FS: 00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: destroy_inode+0x33/0x70 dispose_list+0x43/0x60 evict_inodes+0x161/0x1b0 generic_shutdown_super+0x2d/0x110 kill_anon_super+0xf/0x20 btrfs_kill_super+0xd/0x20 [btrfs] deactivate_locked_super+0x27/0x90 cleanup_mnt+0x12c/0x180 task_work_run+0x54/0x80 exit_to_user_mode_prepare+0x152/0x160 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x42/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f854a000fb7 Fixes: f0bfa76a11e9 ("btrfs: fix ENOSPC failure when attempting direct IO write into NOCOW range") CC: stable@vger.kernel.org # 5.17 Reviewed-by: Johannes Thumshirn Tested-by: Johannes Thumshirn Reviewed-by: Filipe Manana Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 8ff8bdb8c92d639ea5086db1b2cd76bf7bcbc9c1 Author: Alex Elder Date: Tue Feb 1 09:02:05 2022 -0600 net: ipa: request IPA register values be retained commit 34a081761e4e3c35381cbfad609ebae2962fe2f8 upstream. In some cases, the IPA hardware needs to request the always-on subsystem (AOSS) to coordinate with the IPA microcontroller to retain IPA register values at power collapse. This is done by issuing a QMP request to the AOSS microcontroller. A similar request ondoes that request. We must get and hold the "QMP" handle early, because we might get back EPROBE_DEFER for that. But the actual request should be sent while we know the IPA clock is active, and when we know the microcontroller is operational. Fixes: 1aac309d3207 ("net: ipa: use autosuspend") Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 587ced6b8cf350616728e17cbcde9ae8a333122a Author: Alex Elder Date: Tue Feb 1 09:02:04 2022 -0600 dt-bindings: net: qcom,ipa: add optional qcom,qmp property commit ac62a0174d62ae0f4447c0c8cf35a8e5d793df56 upstream. For some systems, the IPA driver must make a request to ensure that its registers are retained across power collapse of the IPA hardware. On such systems, we'll use the existence of the "qcom,qmp" property as a signal that this request is required. Signed-off-by: Alex Elder Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7883df73fd594757f03e21da7598f4347da0441d Author: Deepak Kumar Singh Date: Tue Aug 31 20:00:27 2021 +0530 soc: qcom: aoss: Expose send for generic usecase commit 8c75d585b931ac874fbe4ee5a8f1811d20c2817f upstream. Not all upcoming usecases will have an interface to allow the aoss driver to hook onto. Expose the send api and create a get function to enable drivers to send their own messages to aoss. Signed-off-by: Chris Lew Signed-off-by: Deepak Kumar Singh Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1630420228-31075-2-git-send-email-deesin@codeaurora.org Signed-off-by: Alex Elder Signed-off-by: Greg Kroah-Hartman commit ec13aa4e0085eba99fab07f9842a27b727cf50cd Author: Nathan Chancellor Date: Thu Mar 24 08:36:45 2022 -0700 btrfs: remove unused variable in btrfs_{start,write}_dirty_block_groups() commit 6d4a6b515c39f1f8763093e0f828959b2fbc2f45 upstream. Clang's version of -Wunused-but-set-variable recently gained support for unary operations, which reveals two unused variables: fs/btrfs/block-group.c:2949:6: error: variable 'num_started' set but not used [-Werror,-Wunused-but-set-variable] int num_started = 0; ^ fs/btrfs/block-group.c:3116:6: error: variable 'num_started' set but not used [-Werror,-Wunused-but-set-variable] int num_started = 0; ^ 2 errors generated. These variables appear to be unused from their introduction, so just remove them to silence the warnings. Fixes: c9dc4c657850 ("Btrfs: two stage dirty block group writeout") Fixes: 1bbc621ef284 ("Btrfs: allow block group cache writeout outside critical section in commit") CC: stable@vger.kernel.org # 5.4+ Link: https://github.com/ClangBuiltLinux/linux/issues/1614 Signed-off-by: Nathan Chancellor Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ed0e951463eaffe9f90bff6c2c69f080e9e0ad0a Author: Filipe Manana Date: Thu Feb 3 15:36:44 2022 +0000 btrfs: remove no longer used counter when reading data page commit ad3fc7946b1829213bbdbb2b9ad0d124b31ae4a7 upstream. After commit 92082d40976ed0 ("btrfs: integrate page status update for data read path into begin/end_page_read"), the 'nr' counter at btrfs_do_readpage() is no longer used, we increment it but we never read from it. So just remove it. Reviewed-by: Johannes Thumshirn Signed-off-by: Filipe Manana Signed-off-by: David Sterba Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 6308ab54c8ecf29c7f6bd5b262ef1511f52bee84 Author: Qu Wenruo Date: Mon Sep 27 15:21:43 2021 +0800 btrfs: remove unused parameter nr_pages in add_ra_bio_pages() commit cd9255be6980012ad54f2d4fd3941bc2586e43e5 upstream. Variable @nr_pages only gets increased but never used. Remove it. Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Cc: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit ff810f85ed3f3c6709d05d2497a8ef0d1cda2cf7 Author: Woody Suwalski Date: Wed Feb 9 16:05:09 2022 -0500 ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40 commit bfe55a1f7fd6bfede16078bf04c6250fbca11588 upstream. Add and ACPI idle power level limit for 32-bit ThinkPad T40. There is a regression on T40 introduced by commit d6b88ce2, starting with kernel 5.16: commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 Author: Richard Gong Date:   Wed Sep 22 08:31:16 2021 -0500 ACPI: processor idle: Allow playing dead in C3 state The above patch is trying to enter C3 state during init, what is causing a T40 system freeze. I have not found a similar issue on any other of my 32-bit machines. The fix is to add another exception to the processor_power_dmi_table[] list. As a result the dmesg shows as expected: [2.155398] ACPI: IBM ThinkPad T40 detected - limiting to C2 max_cstate. Override with "processor.max_cstate=9" [2.155404] ACPI: processor limited to max C-state 2 The fix is trivial and affects only vintage T40 systems. Fixes: d6b88ce2eb9d ("CPI: processor idle: Allow playing dead in C3 state") Signed-off-by: Woody Suwalski Reviewed-by: Hans de Goede Cc: 5.16+ # 5.16+ [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman commit 7cad1c40ef91729ae4183c98f45f1fc93668dbab Author: Richard Gong Date: Wed Sep 22 08:31:16 2021 -0500 ACPI: processor idle: Allow playing dead in C3 state commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 upstream. When some cores are disabled on AMD platforms, the system will no longer be able to enter suspend-to-idle s0ix. Update to allow playing dead in C3 state so that the CPUs can enter the deepest state on AMD platforms. BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1708 Suggested-by: Mario Limonciello Signed-off-by: Richard Gong [ rjw: Fixed coding style ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 631473adaaef3e2e84999b78be5df000f4b9faf0 Author: Mario Limonciello Date: Fri Feb 25 13:06:46 2022 -0600 ACPI: processor idle: Check for architectural support for LPI commit eb087f305919ee8169ad65665610313e74260463 upstream. When `osc_pc_lpi_support_confirmed` is set through `_OSC` and `_LPI` is populated then the cpuidle driver assumes that LPI is fully functional. However currently the kernel only provides architectural support for LPI on ARM. This leads to high power consumption on X86 platforms that otherwise try to enable LPI. So probe whether or not LPI support is implemented before enabling LPI in the kernel. This is done by overloading `acpi_processor_ffh_lpi_probe` to check whether it returns `-EOPNOTSUPP`. It also means that all future implementations of `acpi_processor_ffh_lpi_probe` will need to follow these semantics as well. Reviewed-by: Sudeep Holla Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5b13295ac58416bc8f7db3fd87ef11ca58b5b436 Author: Mario Limonciello Date: Fri Feb 25 13:06:45 2022 -0600 cpuidle: PSCI: Move the `has_lpi` check to the beginning of the function commit 01f6c7338ce267959975da65d86ba34f44d54220 upstream. Currently the first thing checked is whether the PCSI cpu_suspend function has been initialized. Another change will be overloading `acpi_processor_ffh_lpi_probe` and calling it sooner. So make the `has_lpi` check the first thing checked to prepare for that change. Reviewed-by: Sudeep Holla Signed-off-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 9873fe0f3857c500fa21f92fe43b2a177e8de208 Author: Lin Ma Date: Thu Nov 11 22:14:02 2021 +0800 hamradio: remove needs_free_netdev to avoid UAF commit 81b1d548d00bcd028303c4f3150fa753b9b8aa71 upstream. The former patch "defer 6pack kfree after unregister_netdev" reorders the kfree of two buffer after the unregister_netdev to prevent the race condition. It also adds free_netdev() function in sixpack_close(), which is a direct copy from the similar code in mkiss_close(). However, in sixpack driver, the flag needs_free_netdev is set to true in sp_setup(), hence the unregister_netdev() will free the netdev automatically. Therefore, as the sp is netdev_priv, use-after-free occurs. This patch removes the needs_free_netdev = true and just let the free_netdev to finish this deallocation task. Fixes: 0b9111922b1f ("hamradio: defer 6pack kfree after unregister_netdev") Signed-off-by: Lin Ma Link: https://lore.kernel.org/r/20211111141402.7551-1-linma@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Xu Jia Signed-off-by: Greg Kroah-Hartman commit c799c18a287e024e1c885da329aad8f719b255c3 Author: Lin Ma Date: Mon Nov 8 18:37:59 2021 +0800 hamradio: defer 6pack kfree after unregister_netdev commit 0b9111922b1f399aba6ed1e1b8f2079c3da1aed8 upstream. There is a possible race condition (use-after-free) like below (USE) | (FREE) dev_queue_xmit | __dev_queue_xmit | __dev_xmit_skb | sch_direct_xmit | ... xmit_one | netdev_start_xmit | tty_ldisc_kill __netdev_start_xmit | 6pack_close sp_xmit | kfree sp_encaps | | According to the patch "defer ax25 kfree after unregister_netdev", this patch reorder the kfree after the unregister_netdev to avoid the possible UAF as the unregister_netdev() is well synchronized and won't return if there is a running routine. Signed-off-by: Lin Ma Signed-off-by: David S. Miller Signed-off-by: Xu Jia Signed-off-by: Greg Kroah-Hartman commit 8e663865f5284124196bc04e010e7344d8a278f3 Author: Nicholas Kazlauskas Date: Fri Mar 18 11:10:34 2022 -0400 drm/amd/display: Fix p-state allow debug index on dcn31 commit 3107e1a7ae088ee94323fe9ab05dbefd65b3077f upstream. [Why] It changed since dcn30 but the hubbub31 constructor hasn't been modified to reflect this. [How] Update the value in the constructor to 0x6 so we're checking the right bits for p-state allow. It worked before by accident, but can falsely assert 0 depending on HW state transitions. The most frequent of which appears to be when all pipes turn off during IGT tests. Cc: Harry Wentland Fixes: e7031d8258f1b4 ("drm/amd/display: Add pstate verification and recovery for DCN31") Signed-off-by: Nicholas Kazlauskas Reviewed-by: Eric Yang Acked-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 685a19fa6ae99dc7a18a9af2a7626162e1db7aff Author: Nicholas Kazlauskas Date: Fri Dec 17 09:55:54 2021 -0500 drm/amd/display: Add pstate verification and recovery for DCN31 commit e7031d8258f1b4d6d50e5e5b5d92ba16f66eb8b4 upstream. [Why] To debug when p-state is being blocked and avoid PMFW hangs when it does occur. [How] Re-use the DCN10 hardware sequencer by adding a new interface for verifying p-state high on the hubbub. The interface is mostly the same as the DCN10 interface, but the bit definitions have changed for the debug bus. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Eric Yang Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman