commit a0ebea480bb319a3ad408c99db91262dbc696b76 Author: Greg Kroah-Hartman Date: Wed Feb 16 12:56:41 2022 +0100 Linux 5.15.24 Link: https://lore.kernel.org/r/20220214092506.354292783@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Fox Chen Tested-by: Slade Watkins Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 65ab30f6a6952fa9ee13009862736cf8d110e6e5 Author: Vijayanand Jitta Date: Mon Jan 31 12:42:35 2022 +0530 iommu: Fix potential use-after-free during probe commit b54240ad494300ff0994c4539a531727874381f4 upstream. Kasan has reported the following use after free on dev->iommu. when a device probe fails and it is in process of freeing dev->iommu in dev_iommu_free function, a deferred_probe_work_func runs in parallel and tries to access dev->iommu->fwspec in of_iommu_configure path thus causing use after free. BUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4 Read of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153 Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x0/0x33c show_stack+0x18/0x24 dump_stack_lvl+0x16c/0x1e0 print_address_description+0x84/0x39c __kasan_report+0x184/0x308 kasan_report+0x50/0x78 __asan_load8+0xc0/0xc4 of_iommu_configure+0xb4/0x4a4 of_dma_configure_id+0x2fc/0x4d4 platform_dma_configure+0x40/0x5c really_probe+0x1b4/0xb74 driver_probe_device+0x11c/0x228 __device_attach_driver+0x14c/0x304 bus_for_each_drv+0x124/0x1b0 __device_attach+0x25c/0x334 device_initial_probe+0x24/0x34 bus_probe_device+0x78/0x134 deferred_probe_work_func+0x130/0x1a8 process_one_work+0x4c8/0x970 worker_thread+0x5c8/0xaec kthread+0x1f8/0x220 ret_from_fork+0x10/0x18 Allocated by task 1: ____kasan_kmalloc+0xd4/0x114 __kasan_kmalloc+0x10/0x1c kmem_cache_alloc_trace+0xe4/0x3d4 __iommu_probe_device+0x90/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Freed by task 1: kasan_set_track+0x4c/0x84 kasan_set_free_info+0x28/0x4c ____kasan_slab_free+0x120/0x15c __kasan_slab_free+0x18/0x28 slab_free_freelist_hook+0x204/0x2fc kfree+0xfc/0x3a4 __iommu_probe_device+0x284/0x394 probe_iommu_group+0x70/0x9c bus_for_each_dev+0x11c/0x19c bus_iommu_probe+0xb8/0x7d4 bus_set_iommu+0xcc/0x13c arm_smmu_bus_init+0x44/0x130 [arm_smmu] arm_smmu_device_probe+0xb88/0xc54 [arm_smmu] platform_drv_probe+0xe4/0x13c really_probe+0x2c8/0xb74 driver_probe_device+0x11c/0x228 device_driver_attach+0xf0/0x16c __driver_attach+0x80/0x320 bus_for_each_dev+0x11c/0x19c driver_attach+0x38/0x48 bus_add_driver+0x1dc/0x3a4 driver_register+0x18c/0x244 __platform_driver_register+0x88/0x9c init_module+0x64/0xff4 [arm_smmu] do_one_initcall+0x17c/0x2f0 do_init_module+0xe8/0x378 load_module+0x3f80/0x4a40 __se_sys_finit_module+0x1a0/0x1e4 __arm64_sys_finit_module+0x44/0x58 el0_svc_common+0x100/0x264 do_el0_svc+0x38/0xa4 el0_svc+0x20/0x30 el0_sync_handler+0x68/0xac el0_sync+0x160/0x180 Fix this by setting dev->iommu to NULL first and then freeing dev_iommu structure in dev_iommu_free function. Suggested-by: Robin Murphy Signed-off-by: Vijayanand Jitta Link: https://lore.kernel.org/r/1643613155-20215-1-git-send-email-quic_vjitta@quicinc.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 7969fe91c9830e045901970e9d755b7505881d4a Author: Song Liu Date: Thu Feb 3 16:40:57 2022 -0800 perf: Fix list corruption in perf_cgroup_switch() commit 5f4e5ce638e6a490b976ade4a40017b40abb2da0 upstream. There's list corruption on cgrp_cpuctx_list. This happens on the following path: perf_cgroup_switch: list_for_each_entry(cgrp_cpuctx_list) cpu_ctx_sched_in ctx_sched_in ctx_pinned_sched_in merge_sched_in perf_cgroup_event_disable: remove the event from the list Use list_for_each_entry_safe() to allow removing an entry during iteration. Fixes: 058fe1c0440e ("perf/core: Make cgroup switch visit only cpuctxs with cgroup events") Signed-off-by: Song Liu Reviewed-by: Rik van Riel Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220204004057.2961252-1-song@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8ebcd2c680e10eaf0e720a0b037fa9960ab16e21 Author: Alexander Stein Date: Sat Jan 29 14:39:05 2022 +0800 arm64: dts: imx8mq: fix lcdif port node commit 91f6d5f181f6629dd74ab71759fe92d3f4eff966 upstream. The port node does not have a unit-address, remove it. This fixes the warnings: lcd-controller@30320000: 'port' is a required property lcd-controller@30320000: 'port@0' does not match any of the regexes: 'pinctrl-[0-9]+' Fixes: commit d0081bd02a03 ("arm64: dts: imx8mq: Add NWL MIPI DSI controller") Signed-off-by: Alexander Stein Reviewed-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 48f54966f7f7e5018ae503369fa53013919a412f Author: Thomas Bogendoerfer Date: Mon Jan 31 11:07:02 2022 +0100 MIPS: octeon: Fix missed PTR->PTR_WD conversion commit 50317b636e7184d15126e2dfc83db0963a38d31e upstream. Fixes: fa62f39dc7e2 ("MIPS: Fix build error due to PTR used in more places") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit cd4494f8685c64b34fa0bbbf779549d177becb38 Author: James Smart Date: Mon Feb 7 10:04:42 2022 -0800 scsi: lpfc: Reduce log messages seen after firmware download commit 5852ed2a6a39c862c8a3fdf646e1f4e01b91d710 upstream. Messages around firmware download were incorrectly tagged as being related to discovery trace events. Thus, firmware download status ended up dumping the trace log as well as the firmware update message. As there were a couple of log messages in this state, the trace log was dumped multiple times. Resolve this by converting from trace events to SLI events. Link: https://lore.kernel.org/r/20220207180442.72836-1-jsmart2021@gmail.com Reviewed-by: Ewan D. Milne Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 6737f9a95a423f116e048f85d71eef1f070700bb Author: James Smart Date: Mon Feb 7 10:05:16 2022 -0800 scsi: lpfc: Remove NVMe support if kernel has NVME_FC disabled commit c80b27cfd93ba9f5161383f798414609e84729f3 upstream. The driver is initiating NVMe PRLIs to determine device NVMe support. This should not be occurring if CONFIG_NVME_FC support is disabled. Correct this by changing the default value for FC4 support. Currently it defaults to FCP and NVMe. With change, when NVME_FC support is not enabled in the kernel, the default value is just FCP. Link: https://lore.kernel.org/r/20220207180516.73052-1-jsmart2021@gmail.com Reviewed-by: Ewan D. Milne Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit c8e9c2b52c4cf39085a22a0598be5e08d1b5dc37 Author: Nathan Chancellor Date: Wed Feb 2 16:05:16 2022 -0700 Makefile.extrawarn: Move -Wunaligned-access to W=1 commit 1cf5f151d25fcca94689efd91afa0253621fb33a upstream. -Wunaligned-access is a new warning in clang that is default enabled for arm and arm64 under certain circumstances within the clang frontend (see LLVM commit below). On v5.17-rc2, an ARCH=arm allmodconfig build shows 1284 total/70 unique instances of this warning (most of the instances are in header files), which is quite noisy. To keep a normal build green through CONFIG_WERROR, only show this warning with W=1, which will allow automated build systems to catch new instances of the warning so that the total number can be driven down to zero eventually since catching unaligned accesses at compile time would be generally useful. Cc: stable@vger.kernel.org Link: https://github.com/llvm/llvm-project/commit/35737df4dcd28534bd3090157c224c19b501278a Link: https://github.com/ClangBuiltLinux/linux/issues/1569 Link: https://github.com/ClangBuiltLinux/linux/issues/1576 Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 24645c47880b92c2a5b59fcb071d4efb3ddc720c Author: Reinette Chatre Date: Tue Feb 8 10:48:07 2022 -0800 x86/sgx: Silence softlockup detection when releasing large enclaves commit 8795359e35bc33bf86b6d0765aa7f37431db3b9c upstream. Vijay reported that the "unclobbered_vdso_oversubscribed" selftest triggers the softlockup detector. Actual SGX systems have 128GB of enclave memory or more. The "unclobbered_vdso_oversubscribed" selftest creates one enclave which consumes all of the enclave memory on the system. Tearing down such a large enclave takes around a minute, most of it in the loop where the EREMOVE instruction is applied to each individual 4k enclave page. Spending one minute in a loop triggers the softlockup detector. Add a cond_resched() to give other tasks a chance to run and placate the softlockup detector. Cc: stable@vger.kernel.org Fixes: 1728ab54b4be ("x86/sgx: Add a page reclaimer") Reported-by: Vijay Dhanraj Signed-off-by: Reinette Chatre Signed-off-by: Dave Hansen Reviewed-by: Jarkko Sakkinen Acked-by: Dave Hansen Tested-by: Jarkko Sakkinen (kselftest as sanity check) Link: https://lkml.kernel.org/r/ced01cac1e75f900251b0a4ae1150aa8ebd295ec.1644345232.git.reinette.chatre@intel.com Signed-off-by: Greg Kroah-Hartman commit 30de73bebf2b1e53686746e87669ed7ac23d1dc1 Author: Armin Wolf Date: Thu Oct 21 21:05:31 2021 +0200 hwmon: (dell-smm) Speed up setting of fan speed commit c0d79987a0d82671bff374c07f2201f9bdf4aaa2 upstream. When setting the fan speed, i8k_set_fan() calls i8k_get_fan_status(), causing an unnecessary SMM call since from the two users of this function, only i8k_ioctl_unlocked() needs to know the new fan status while dell_smm_write() ignores the new fan status. Since SMM calls can be very slow while also making error reporting difficult for dell_smm_write(), remove the function call from i8k_set_fan() and call it separately in i8k_ioctl_unlocked(). Tested on a Dell Inspiron 3505. Signed-off-by: Armin Wolf Reviewed-by: Pali Rohár Link: https://lore.kernel.org/r/20211021190531.17379-6-W_Armin@gmx.de Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 16cde074b00cb29a023573667cf7f5829d28d2ef Author: Slark Xiao Date: Sat Feb 5 19:27:31 2022 +0530 bus: mhi: pci_generic: Add mru_default for Cinterion MV31-W commit 05daa805a86c831ad9692f6f15e1b877c8f10638 upstream. For default mechanism, product would use default MRU 3500 if they didn't define it. But for Cinterion MV31-W, there is a known issue which MRU 3500 would lead to data connection lost. So we align it with Qualcomm default MRU settings. Link: https://lore.kernel.org/r/20220119102519.5342-1-slark_xiao@163.com [mani: Modified the commit message to reflect Cinterion MV31-W and CCed stable] Fixes: 87693e092bd0 ("bus: mhi: pci_generic: Add Cinterion MV31-W PCIe to MHI") Cc: stable@vger.kernel.org # v5.14 + Reviewed-by: Manivannan Sadhasivam Signed-off-by: Slark Xiao Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20220205135731.157871-3-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit 2c1d20e34669836af45164bcead71ab79ff79f99 Author: Slark Xiao Date: Sat Feb 5 19:27:30 2022 +0530 bus: mhi: pci_generic: Add mru_default for Foxconn SDX55 commit a0572cea8866230ac13da6358c88075f89e99b20 upstream. For default mechanism, product would use default MRU 3500 if they didn't define it. But for Foxconn SDX55, there is a known issue which MRU 3500 would lead to data connection lost. So we align it with Qualcomm default MRU settings. Link: https://lore.kernel.org/r/20220119101213.5008-1-slark_xiao@163.com [mani: Added pci_generic prefix to subject and CCed stable] Fixes: aac426562f56 ("bus: mhi: pci_generic: Introduce Foxconn T99W175 support") Cc: stable@vger.kernel.org # v5.12+ Reviewed-by: Manivannan Sadhasivam Signed-off-by: Slark Xiao Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20220205135731.157871-2-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman commit fe990b7bf6ac93f1d850d076b8f0e758268aa4ab Author: Vineeth Vijayan Date: Wed Feb 2 21:45:56 2022 +0100 s390/cio: verify the driver availability for path_event call commit dd9cb842fa9d90653a9b48aba52f89c069f3bc50 upstream. If no driver is attached to a device or the driver does not provide the path_event function, an FCES path-event on this device could end up in a kernel-panic. Verify the driver availability before the path_event function call. Fixes: 32ef938815c1 ("s390/cio: Add support for FCES status notification") Cc: stable@vger.kernel.org Signed-off-by: Vineeth Vijayan Suggested-by: Peter Oberparleiter Reviewed-by: Jan Hoeppner Reviewed-by: Peter Oberparleiter Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 56ca18dd5483a7056b83f277dd90a5db382191ab Author: Kees Cook Date: Tue Feb 8 00:57:17 2022 -0800 signal: HANDLER_EXIT should clear SIGNAL_UNKILLABLE commit 5c72263ef2fbe99596848f03758ae2dc593adf2c upstream. Fatal SIGSYS signals (i.e. seccomp RET_KILL_* syscall filter actions) were not being delivered to ptraced pid namespace init processes. Make sure the SIGNAL_UNKILLABLE doesn't get set for these cases. Reported-by: Robert Święcki Suggested-by: "Eric W. Biederman" Fixes: 00b06da29cf9 ("signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: "Eric W. Biederman" Link: https://lore.kernel.org/lkml/878rui8u4a.fsf@email.froward.int.ebiederm.org Signed-off-by: Greg Kroah-Hartman commit f7a56fcca2e45917ea40ac2e864bf4e9fb2a51e4 Author: Kees Cook Date: Mon Feb 7 20:21:13 2022 -0800 seccomp: Invalidate seccomp mode to catch death failures commit 495ac3069a6235bfdf516812a2a9b256671bbdf9 upstream. If seccomp tries to kill a process, it should never see that process again. To enforce this proactively, switch the mode to something impossible. If encountered: WARN, reject all syscalls, and attempt to kill the process again even harder. Cc: Andy Lutomirski Cc: Will Drewry Fixes: 8112c4f140fa ("seccomp: remove 2-phase API") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit 956cf21cd1ae1de63dd5850e2e287641cb4cc34a Author: Roman Gushchin Date: Fri Feb 11 16:32:32 2022 -0800 mm: memcg: synchronize objcg lists with a dedicated spinlock commit 0764db9b49c932b89ee4d9e3236dff4bb07b4a66 upstream. Alexander reported a circular lock dependency revealed by the mmap1 ltp test: LOCKDEP_CIRCULAR (suite: ltp, case: mtest06 (mmap1)) WARNING: possible circular locking dependency detected 5.17.0-20220113.rc0.git0.f2211f194038.300.fc35.s390x+debug #1 Not tainted ------------------------------------------------------ mmap1/202299 is trying to acquire lock: 00000001892c0188 (css_set_lock){..-.}-{2:2}, at: obj_cgroup_release+0x4a/0xe0 but task is already holding lock: 00000000ca3b3818 (&sighand->siglock){-.-.}-{2:2}, at: force_sig_info_to_task+0x38/0x180 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sighand->siglock){-.-.}-{2:2}: __lock_acquire+0x604/0xbd8 lock_acquire.part.0+0xe2/0x238 lock_acquire+0xb0/0x200 _raw_spin_lock_irqsave+0x6a/0xd8 __lock_task_sighand+0x90/0x190 cgroup_freeze_task+0x2e/0x90 cgroup_migrate_execute+0x11c/0x608 cgroup_update_dfl_csses+0x246/0x270 cgroup_subtree_control_write+0x238/0x518 kernfs_fop_write_iter+0x13e/0x1e0 new_sync_write+0x100/0x190 vfs_write+0x22c/0x2d8 ksys_write+0x6c/0xf8 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #0 (css_set_lock){..-.}-{2:2}: check_prev_add+0xe0/0xed8 validate_chain+0x736/0xb20 __lock_acquire+0x604/0xbd8 lock_acquire.part.0+0xe2/0x238 lock_acquire+0xb0/0x200 _raw_spin_lock_irqsave+0x6a/0xd8 obj_cgroup_release+0x4a/0xe0 percpu_ref_put_many.constprop.0+0x150/0x168 drain_obj_stock+0x94/0xe8 refill_obj_stock+0x94/0x278 obj_cgroup_charge+0x164/0x1d8 kmem_cache_alloc+0xac/0x528 __sigqueue_alloc+0x150/0x308 __send_signal+0x260/0x550 send_signal+0x7e/0x348 force_sig_info_to_task+0x104/0x180 force_sig_fault+0x48/0x58 __do_pgm_check+0x120/0x1f0 pgm_check_handler+0x11e/0x180 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sighand->siglock); lock(css_set_lock); lock(&sighand->siglock); lock(css_set_lock); *** DEADLOCK *** 2 locks held by mmap1/202299: #0: 00000000ca3b3818 (&sighand->siglock){-.-.}-{2:2}, at: force_sig_info_to_task+0x38/0x180 #1: 00000001892ad560 (rcu_read_lock){....}-{1:2}, at: percpu_ref_put_many.constprop.0+0x0/0x168 stack backtrace: CPU: 15 PID: 202299 Comm: mmap1 Not tainted 5.17.0-20220113.rc0.git0.f2211f194038.300.fc35.s390x+debug #1 Hardware name: IBM 3906 M04 704 (LPAR) Call Trace: dump_stack_lvl+0x76/0x98 check_noncircular+0x136/0x158 check_prev_add+0xe0/0xed8 validate_chain+0x736/0xb20 __lock_acquire+0x604/0xbd8 lock_acquire.part.0+0xe2/0x238 lock_acquire+0xb0/0x200 _raw_spin_lock_irqsave+0x6a/0xd8 obj_cgroup_release+0x4a/0xe0 percpu_ref_put_many.constprop.0+0x150/0x168 drain_obj_stock+0x94/0xe8 refill_obj_stock+0x94/0x278 obj_cgroup_charge+0x164/0x1d8 kmem_cache_alloc+0xac/0x528 __sigqueue_alloc+0x150/0x308 __send_signal+0x260/0x550 send_signal+0x7e/0x348 force_sig_info_to_task+0x104/0x180 force_sig_fault+0x48/0x58 __do_pgm_check+0x120/0x1f0 pgm_check_handler+0x11e/0x180 INFO: lockdep is turned off. In this example a slab allocation from __send_signal() caused a refilling and draining of a percpu objcg stock, resulted in a releasing of another non-related objcg. Objcg release path requires taking the css_set_lock, which is used to synchronize objcg lists. This can create a circular dependency with the sighandler lock, which is taken with the locked css_set_lock by the freezer code (to freeze a task). In general it seems that using css_set_lock to synchronize objcg lists makes any slab allocations and deallocation with the locked css_set_lock and any intervened locks risky. To fix the problem and make the code more robust let's stop using css_set_lock to synchronize objcg lists and use a new dedicated spinlock instead. Link: https://lkml.kernel.org/r/Yfm1IHmoGdyUR81T@carbon.dhcp.thefacebook.com Fixes: bf4f059954dc ("mm: memcg/slab: obj_cgroup API") Signed-off-by: Roman Gushchin Reported-by: Alexander Egorenkov Tested-by: Alexander Egorenkov Reviewed-by: Waiman Long Acked-by: Tejun Heo Reviewed-by: Shakeel Butt Reviewed-by: Jeremy Linton Tested-by: Jeremy Linton Cc: Johannes Weiner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit b7f54894aa7517d2b6c797a499b9f491e9db9083 Author: Mathias Krause Date: Mon Feb 7 16:01:19 2022 +0100 iio: buffer: Fix file related error handling in IIO_BUFFER_GET_FD_IOCTL commit c72ea20503610a4a7ba26c769357d31602769c01 upstream. If we fail to copy the just created file descriptor to userland, we try to clean up by putting back 'fd' and freeing 'ib'. The code uses put_unused_fd() for the former which is wrong, as the file descriptor was already published by fd_install() which gets called internally by anon_inode_getfd(). This makes the error handling code leaving a half cleaned up file descriptor table around and a partially destructed 'file' object, allowing userland to play use-after-free tricks on us, by abusing the still usable fd and making the code operate on a dangling 'file->private_data' pointer. Instead of leaving the kernel in a partially corrupted state, don't attempt to explicitly clean up and leave this to the process exit path that'll release any still valid fds, including the one created by the previous call to anon_inode_getfd(). Simply return -EFAULT to indicate the error. Fixes: f73f7f4da581 ("iio: buffer: add ioctl() to support opening extra buffers for IIO device") Cc: stable@kernel.org Cc: Jonathan Cameron Cc: Alexandru Ardelean Cc: Lars-Peter Clausen Cc: Nuno Sa Reported-by: Dan Carpenter Signed-off-by: Mathias Krause Reviewed-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7a360e546ad9e7c3fd53d6bb60348c660cd28f54 Author: Kishon Vijay Abraham I Date: Mon Jan 17 16:31:08 2022 +0530 phy: ti: Fix missing sentinel for clk_div_table commit 6d1e6bcb31663ee83aaea1f171f3dbfe95dd4a69 upstream. _get_table_maxdiv() tries to access "clk_div_table" array out of bound defined in phy-j721e-wiz.c. Add a sentinel entry to prevent the following global-out-of-bounds error reported by enabling KASAN. [ 9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148 [ 9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38 [ 9.565926] [ 9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360 [ 9.576242] Hardware name: Texas Instruments J721e EVM (DT) [ 9.581832] Workqueue: events_unbound deferred_probe_work_func [ 9.587708] Call trace: [ 9.590174] dump_backtrace+0x20c/0x218 [ 9.594038] show_stack+0x18/0x68 [ 9.597375] dump_stack_lvl+0x9c/0xd8 [ 9.601062] print_address_description.constprop.0+0x78/0x334 [ 9.606830] kasan_report+0x1f0/0x260 [ 9.610517] __asan_load4+0x9c/0xd8 [ 9.614030] _get_maxdiv+0xc0/0x148 [ 9.617540] divider_determine_rate+0x88/0x488 [ 9.622005] divider_round_rate_parent+0xc8/0x124 [ 9.626729] wiz_clk_div_round_rate+0x54/0x68 [ 9.631113] clk_core_determine_round_nolock+0x124/0x158 [ 9.636448] clk_core_round_rate_nolock+0x68/0x138 [ 9.641260] clk_core_set_rate_nolock+0x268/0x3a8 [ 9.645987] clk_set_rate+0x50/0xa8 [ 9.649499] cdns_sierra_phy_init+0x88/0x248 [ 9.653794] phy_init+0x98/0x108 [ 9.657046] cdns_pcie_enable_phy+0xa0/0x170 [ 9.661340] cdns_pcie_init_phy+0x250/0x2b0 [ 9.665546] j721e_pcie_probe+0x4b8/0x798 [ 9.669579] platform_probe+0x8c/0x108 [ 9.673350] really_probe+0x114/0x630 [ 9.677037] __driver_probe_device+0x18c/0x220 [ 9.681505] driver_probe_device+0xac/0x150 [ 9.685712] __device_attach_driver+0xec/0x170 [ 9.690178] bus_for_each_drv+0xf0/0x158 [ 9.694124] __device_attach+0x184/0x210 [ 9.698070] device_initial_probe+0x14/0x20 [ 9.702277] bus_probe_device+0xec/0x100 [ 9.706223] deferred_probe_work_func+0x124/0x180 [ 9.710951] process_one_work+0x4b0/0xbc0 [ 9.714983] worker_thread+0x74/0x5d0 [ 9.718668] kthread+0x214/0x230 [ 9.721919] ret_from_fork+0x10/0x20 [ 9.725520] [ 9.727032] The buggy address belongs to the variable: [ 9.732183] clk_div_table+0x24/0x440 Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC") Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20220117110108.4117-1-kishon@ti.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 12431425c4669ef9c88acaa6e97c96e77f218562 Author: Samuel Thibault Date: Sun Feb 6 02:56:26 2022 +0100 speakup-dectlk: Restore pitch setting commit bca828ccdd6548d24613d0cede04ada4dfb2f89c upstream. d97a9d7aea04 ("staging/speakup: Add inflection synth parameter") introduced the inflection parameter, but happened to drop the pitch parameter from the dectlk driver. This restores it. Cc: stable@vger.kernel.org Fixes: d97a9d7aea04 ("staging/speakup: Add inflection synth parameter") Signed-off-by: Samuel Thibault Link: https://lore.kernel.org/r/20220206015626.aesbhvvdkmqsrbaw@begin Signed-off-by: Greg Kroah-Hartman commit 9ae3dad535a9c6be298cbb223b360066ed6ad225 Author: Johan Hovold Date: Tue Feb 1 11:42:53 2022 +0100 USB: serial: cp210x: add CPI Bulk Coin Recycler id commit 6ca0c6283340d819bf9c7d8e76be33c9fbd903ab upstream. Add the device id for the Crane Payment Innovation / Money Controls Bulk Coin Recycler: https://www.cranepi.com/en/system/files/Support/OM_BCR_EN_V1-04_0.pdf Reported-by: Scott Russell Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 7e5108a22f19972012835f1a5164a26ef42feaf4 Author: Johan Hovold Date: Tue Feb 1 11:42:52 2022 +0100 USB: serial: cp210x: add NCR Retail IO box id commit b50f8f09c622297d3cf46e332e17ba8adedec9af upstream. Add the device id for NCR's Retail IO box (CP2105) used in NCR FastLane SelfServ Checkout - R6C: https://www.ncr.com/product-catalog/ncr-fastlane-selfserv-checkout-r6c Reported-by: Scott Russell Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 8d226d39d052841f869dc95185d88c8c3cc18f36 Author: Stephan Brunner Date: Sat Jan 8 13:00:20 2022 +0100 USB: serial: ch341: add support for GW Instek USB2.0-Serial devices commit fa77ce201f7f2d823b07753575122d1ae5597fbe upstream. Programmable lab power supplies made by GW Instek, such as the GPP-2323, have a USB port exposing a serial port to control the device. Stringing the supplied Windows driver, references to the ch341 chip are found. Binding the existing ch341 driver to the VID/PID of the GPP-2323 ("GW Instek USB2.0-Serial" as per the USB product name) works out of the box, communication and control is now possible. This patch should work with any GPP series power supply due to similarities in the product line. Signed-off-by: Stephan Brunner Link: https://lore.kernel.org/r/4a47b864-0816-6f6a-efee-aa20e74bcdc6@stephan-brunner.net Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2ea4f4612cb9884fa5a870147992409e557e732e Author: Pawel Dembicki Date: Tue Jan 11 23:12:05 2022 +0100 USB: serial: option: add ZTE MF286D modem commit d48384c7ed6c8fe4727eaa0f3048f62afd1cd715 upstream. Modem from ZTE MF286D is an Qualcomm MDM9250 based 3G/4G modem. T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=5000 MxCh= 0 D: Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs= 1 P: Vendor=19d2 ProdID=1485 Rev=52.87 S: Manufacturer=ZTE,Incorporated S: Product=ZTE Technologies MSM S: SerialNumber=MF286DZTED000000 C:* #Ifs= 7 Cfg#= 1 Atr=80 MxPwr=896mA A: FirstIf#= 0 IfCount= 2 Cls=02(comm.) Sub=06 Prot=00 I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=02 Prot=ff Driver=rndis_host E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl=32ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=rndis_host E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 5 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms I:* If#= 6 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs E: Ad=05(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms E: Ad=89(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms Signed-off-by: Pawel Dembicki Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 24311a9fc426b9fcb6e9cc02913eaf8affb4ddb0 Author: Cameron Williams Date: Tue Feb 1 10:12:51 2022 +0000 USB: serial: ftdi_sio: add support for Brainboxes US-159/235/320 commit fbb9b194e15a63c56c5664e76ccd0e85c6100cea upstream. This patch adds support for the Brainboxes US-159, US-235 and US-320 USB-to-Serial devices. Signed-off-by: Cameron Williams Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2330b2ba646582047f9ff12f695e162c8b5a4d6b Author: Jann Horn Date: Wed Jan 26 21:52:14 2022 +0100 usb: raw-gadget: fix handling of dual-direction-capable endpoints commit 292d2c82b105d92082c2120a44a58de9767e44f1 upstream. Under dummy_hcd, every available endpoint is *either* IN or OUT capable. But with some real hardware, there are endpoints that support both IN and OUT. In particular, the PLX 2380 has four available endpoints that each support both IN and OUT. raw-gadget currently gets confused and thinks that any endpoint that is usable as an IN endpoint can never be used as an OUT endpoint. Fix it by looking at the direction in the configured endpoint descriptor instead of looking at the hardware capabilities. With this change, I can use the PLX 2380 with raw-gadget. Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface") Cc: stable Tested-by: Andrey Konovalov Reviewed-by: Andrey Konovalov Signed-off-by: Jann Horn Link: https://lore.kernel.org/r/20220126205214.2149936-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman commit 33d2a0c1ec207ebcfcca6db6da59577e5bee177c Author: Pavel Hofman Date: Mon Jan 31 08:18:13 2022 +0100 usb: gadget: f_uac2: Define specific wTerminalType commit 5432184107cd0013761bdfa6cb6079527ef87b95 upstream. Several users have reported that their Win10 does not enumerate UAC2 gadget with the existing wTerminalType set to UAC_INPUT_TERMINAL_UNDEFINED/UAC_INPUT_TERMINAL_UNDEFINED, e.g. https://github.com/raspberrypi/linux/issues/4587#issuecomment-926567213. While the constant is officially defined by the USB terminal types document, e.g. XMOS firmware for UAC2 (commonly used for Win10) defines no undefined output terminal type in its usbaudio20.h header. Therefore wTerminalType of EP-IN is set to UAC_INPUT_TERMINAL_MICROPHONE and wTerminalType of EP-OUT to UAC_OUTPUT_TERMINAL_SPEAKER for the UAC2 gadget. Signed-off-by: Pavel Hofman Cc: stable Link: https://lore.kernel.org/r/20220131071813.7433-1-pavel.hofman@ivitera.com Signed-off-by: Greg Kroah-Hartman commit 2da3b0ab54fb7f4d7c5a82757246d0ee33a47197 Author: Greg Kroah-Hartman Date: Wed Feb 9 16:37:53 2022 +0100 usb: gadget: rndis: check size of RNDIS_MSG_SET command commit 38ea1eac7d88072bbffb630e2b3db83ca649b826 upstream. Check the size of the RNDIS_MSG_SET command given to us before attempting to respond to an invalid message size. Reported-by: Szymon Heidrich Cc: stable@kernel.org Tested-by: Szymon Heidrich Signed-off-by: Greg Kroah-Hartman commit 3e33e5c67cb9ebd2b791b9a9fb2b71daacebd8d4 Author: Szymon Heidrich Date: Mon Jan 24 12:14:00 2022 +0100 USB: gadget: validate interface OS descriptor requests commit 75e5b4849b81e19e9efe1654b30d7f3151c33c2c upstream. Stall the control endpoint in case provided index exceeds array size of MAX_CONFIG_INTERFACES or when the retrieved function pointer is null. Signed-off-by: Szymon Heidrich Cc: stable@kernel.org Signed-off-by: Greg Kroah-Hartman commit d3d5bfb3a279eaa4f344cb7554b0603641a4ae34 Author: Adam Ford Date: Fri Jan 28 16:36:03 2022 -0600 usb: gadget: udc: renesas_usb3: Fix host to USB_ROLE_NONE transition commit 459702eea6132888b5c5b64c0e9c626da4ec2493 upstream. The support the external role switch a variety of situations were addressed, but the transition from USB_ROLE_HOST to USB_ROLE_NONE leaves the host up which can cause some error messages when switching from host to none, to gadget, to none, and then back to host again. xhci-hcd ee000000.usb: Abort failed to stop command ring: -110 xhci-hcd ee000000.usb: xHCI host controller not responding, assume dead xhci-hcd ee000000.usb: HC died; cleaning up usb 4-1: device not accepting address 6, error -108 usb usb4-port1: couldn't allocate usb_device After this happens it will not act as a host again. Fix this by releasing the host mode when transitioning to USB_ROLE_NONE. Fixes: 0604160d8c0b ("usb: gadget: udc: renesas_usb3: Enhance role switch support") Cc: stable Reviewed-by: Yoshihiro Shimoda Signed-off-by: Adam Ford Link: https://lore.kernel.org/r/20220128223603.2362621-1-aford173@gmail.com Signed-off-by: Greg Kroah-Hartman commit 8d2b04dad380713a3bc2895d3f3e07d87f73336c Author: Udipto Goswami Date: Mon Feb 7 09:55:58 2022 +0530 usb: dwc3: gadget: Prevent core from processing stale TRBs commit 117b4e96c7f362eb6459543883fc07f77662472c upstream. With CPU re-ordering on write instructions, there might be a chance that the HWO is set before the TRB is updated with the new mapped buffer address. And in the case where core is processing a list of TRBs it is possible that it fetched the TRBs when the HWO is set but before the buffer address is updated. Prevent this by adding a memory barrier before the HWO is updated to ensure that the core always process the updated TRBs. Fixes: f6bafc6a1c9d ("usb: dwc3: convert TRBs into bitshifts") Cc: stable Reviewed-by: Pavankumar Kondeti Signed-off-by: Udipto Goswami Link: https://lore.kernel.org/r/1644207958-18287-1-git-send-email-quic_ugoswami@quicinc.com Signed-off-by: Greg Kroah-Hartman commit 93feb2bdf6d4a8aeaae1a0e675bd4f6acfb91171 Author: Sean Anderson Date: Thu Jan 27 14:00:03 2022 -0500 usb: ulpi: Call of_node_put correctly commit 0a907ee9d95e3ac35eb023d71f29eae0aaa52d1b upstream. of_node_put should always be called on device nodes gotten from of_get_*. Additionally, it should only be called after there are no remaining users. To address the first issue, call of_node_put if later steps in ulpi_register fail. To address the latter, call put_device if device_register fails, which will call ulpi_dev_release if necessary. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable Reviewed-by: Heikki Krogerus Signed-off-by: Sean Anderson Link: https://lore.kernel.org/r/20220127190004.1446909-3-sean.anderson@seco.com Signed-off-by: Greg Kroah-Hartman commit fc50f42e46164b7adc5a9402d28d5aa15db30bcb Author: Sean Anderson Date: Thu Jan 27 14:00:02 2022 -0500 usb: ulpi: Move of_node_put to ulpi_dev_release commit 092f45b13e51666fe8ecbf2d6cd247aa7e6c1f74 upstream. Drivers are not unbound from the device when ulpi_unregister_interface is called. Move of_node-freeing code to ulpi_dev_release which is called only after all users are gone. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Cc: stable Reviewed-by: Heikki Krogerus Signed-off-by: Sean Anderson Link: https://lore.kernel.org/r/20220127190004.1446909-2-sean.anderson@seco.com Signed-off-by: Greg Kroah-Hartman commit ffd0393adcdcefab7e131488e10dcfde5e02d6eb Author: Jann Horn Date: Wed Jan 26 14:14:52 2022 +0100 net: usb: ax88179_178a: Fix out-of-bounds accesses in RX fixup commit 57bc3d3ae8c14df3ceb4e17d26ddf9eeab304581 upstream. ax88179_rx_fixup() contains several out-of-bounds accesses that can be triggered by a malicious (or defective) USB device, in particular: - The metadata array (hdr_off..hdr_off+2*pkt_cnt) 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. I have tested that this can be used by a malicious USB device to send a bogus ICMPv6 Echo Request and receive an ICMPv6 Echo Reply in response that contains random kernel heap data. It's probably also possible to get OOB writes from this on a little-endian system somehow - maybe by triggering skb_cow() via IP options processing -, but I haven't tested that. Fixes: e2ca90c276e1 ("ax88179_178a: ASIX AX88179_178A USB 3.0/2.0 to gigabit ethernet adapter driver") Cc: stable@kernel.org Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman commit f4e72ad027b04c80f8632119549fb60f7e6b772f Author: Greg Kroah-Hartman Date: Sat Feb 12 10:08:54 2022 +0100 Revert "usb: dwc2: drd: fix soft connect when gadget is unconfigured" commit 736e8d89044c1c330967fb938fa766cd9e0d8af0 upstream. This reverts commit 269cbcf7b72de6f0016806d4a0cec1d689b55a87. It causes build errors as reported by the kernel test robot. Link: https://lore.kernel.org/r/202202112236.AwoOTtHO-lkp@intel.com Reported-by: kernel test robot Fixes: 269cbcf7b72d ("usb: dwc2: drd: fix soft connect when gadget is unconfigured") Cc: stable@kernel.org Cc: Amelie Delaunay Cc: Minas Harutyunyan Cc: Fabrice Gasnier Signed-off-by: Greg Kroah-Hartman commit a6ef1bda0efd239ed9e37766e85cd63331ce958d Author: Fabrice Gasnier Date: Wed Feb 9 17:15:53 2022 +0100 usb: dwc2: drd: fix soft connect when gadget is unconfigured commit 269cbcf7b72de6f0016806d4a0cec1d689b55a87 upstream. When the gadget driver hasn't been (yet) configured, and the cable is connected to a HOST, the SFTDISCON gets cleared unconditionally, so the HOST tries to enumerate it. At the host side, this can result in a stuck USB port or worse. When getting lucky, some dmesg can be observed at the host side: new high-speed USB device number ... device descriptor read/64, error -110 Fix it in drd, by checking the enabled flag before calling dwc2_hsotg_core_connect(). It will be called later, once configured, by the normal flow: - udc_bind_to_driver - usb_gadget_connect - dwc2_hsotg_pullup - dwc2_hsotg_core_connect Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support") Cc: stable@kernel.org Reviewed-by: Amelie Delaunay Acked-by: Minas Harutyunyan Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/1644423353-17859-1-git-send-email-fabrice.gasnier@foss.st.com Signed-off-by: Greg Kroah-Hartman commit 9a5f471ae380f9fcb9756d453c12ca1f8595a93c Author: Jonas Malaco Date: Thu Feb 3 13:49:52 2022 -0300 eeprom: ee1004: limit i2c reads to I2C_SMBUS_BLOCK_MAX commit c0689e46be23160d925dca95dfc411f1a0462708 upstream. Commit effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size") revealed that ee1004_eeprom_read() did not properly limit how many bytes to read at once. In particular, i2c_smbus_read_i2c_block_data_or_emulated() takes the length to read as an u8. If count == 256 after taking into account the offset and page boundary, the cast to u8 overflows. And this is common when user space tries to read the entire EEPROM at once. To fix it, limit each read to I2C_SMBUS_BLOCK_MAX (32) bytes, already the maximum length i2c_smbus_read_i2c_block_data_or_emulated() allows. Fixes: effa453168a7 ("i2c: i801: Don't silently correct invalid transfer size") Cc: stable@vger.kernel.org Reviewed-by: Heiner Kallweit Signed-off-by: Jonas Malaco Link: https://lore.kernel.org/r/20220203165024.47767-1-jonas@protocubo.io Signed-off-by: Greg Kroah-Hartman commit decb36e9a9f02dc9e1e0ede0a93f968e12d86539 Author: TATSUKAWA KOSUKE (立川 江介) Date: Wed Jan 26 23:35:02 2022 +0000 n_tty: wake up poll(POLLRDNORM) on receiving data commit c816b2e65b0e86b95011418cad334f0524fc33b8 upstream. The poll man page says POLLRDNORM is equivalent to POLLIN when used as an event. $ man poll POLLRDNORM Equivalent to POLLIN. However, in n_tty driver, POLLRDNORM does not return until timeout even if there is terminal input, whereas POLLIN returns. The following test program works until kernel-3.17, but the test stops in poll() after commit 57087d515441 ("tty: Fix spurious poll() wakeups"). [Steps to run test program] $ cc -o test-pollrdnorm test-pollrdnorm.c $ ./test-pollrdnorm foo <-- Type in something from the terminal followed by [RET]. The string should be echoed back. ------------------------< test-pollrdnorm.c >------------------------ #include #include #include #include void main(void) { int n; unsigned char buf[8]; struct pollfd fds[1] = {{ 0, POLLRDNORM, 0 }}; n = poll(fds, 1, -1); if (n < 0) perror("poll"); n = read(0, buf, 8); if (n < 0) perror("read"); if (n > 0) write(1, buf, n); } ------------------------------------------------------------------------ The attached patch fixes this problem. Many calls to wake_up_interruptible_poll() in the kernel source code already specify "POLLIN | POLLRDNORM". Fixes: 57087d515441 ("tty: Fix spurious poll() wakeups") Cc: stable@vger.kernel.org Signed-off-by: Kosuke Tatsukawa Link: https://lore.kernel.org/r/TYCPR01MB81901C0F932203D30E452B3EA5209@TYCPR01MB8190.jpnprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 573321db328bf35d22121b54ad59f916f60a51f8 Author: Jakob Koschel Date: Thu Jan 27 15:44:05 2022 +0100 vt_ioctl: add array_index_nospec to VT_ACTIVATE commit 28cb138f559f8c1a1395f5564f86b8bbee83631b upstream. in vt_setactivate an almost identical code path has been patched with array_index_nospec. In the VT_ACTIVATE path the user input is from a system call argument instead of a usercopy. For consistency both code paths should have the same mitigations applied. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. Co-developed-by: Brian Johannesmeyer Signed-off-by: Brian Johannesmeyer Signed-off-by: Jakob Koschel Link: https://lore.kernel.org/r/20220127144406.3589293-2-jakobkoschel@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit ffe54289b02e9c732d6f04c8ebbe3b2d90d32118 Author: Jakob Koschel Date: Thu Jan 27 15:44:04 2022 +0100 vt_ioctl: fix array_index_nospec in vt_setactivate commit 61cc70d9e8ef5b042d4ed87994d20100ec8896d9 upstream. array_index_nospec ensures that an out-of-bounds value is set to zero on the transient path. Decreasing the value by one afterwards causes a transient integer underflow. vsa.console should be decreased first and then sanitized with array_index_nospec. Kasper Acknowledgements: Jakob Koschel, Brian Johannesmeyer, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida from the VUSec group at VU Amsterdam. Co-developed-by: Brian Johannesmeyer Signed-off-by: Brian Johannesmeyer Signed-off-by: Jakob Koschel Link: https://lore.kernel.org/r/20220127144406.3589293-1-jakobkoschel@gmail.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit f916181692cb5da7050ec0efbf96c915d8ebbbbc Author: Vladimir Oltean Date: Thu Feb 10 19:40:17 2022 +0200 net: dsa: mv88e6xxx: fix use-after-free in mv88e6xxx_mdios_unregister [ Upstream commit 51a04ebf21122d5c76a716ecd9bfc33ea44b2b39 ] Since struct mv88e6xxx_mdio_bus *mdio_bus is the bus->priv of something allocated with mdiobus_alloc_size(), this means that mdiobus_free(bus) will free the memory backing the mdio_bus as well. Therefore, the mdio_bus->list element is freed memory, but we continue to iterate through the list of MDIO buses using that list element. To fix this, use the proper list iterator that handles element deletion by keeping a copy of the list element next pointer. Fixes: f53a2ce893b2 ("net: dsa: mv88e6xxx: don't use devres for mdiobus") Reported-by: Rafael Richter Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20220210174017.3271099-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit d98ba26a4ba9b835887e379193be6cee814c7a52 Author: Colin Foster Date: Thu Feb 10 07:04:51 2022 -0800 net: mscc: ocelot: fix mutex lock error during ethtool stats read [ Upstream commit 7fbf6795d127a3b1bb39b0e42579904cf6db1624 ] An ongoing workqueue populates the stats buffer. At the same time, a user might query the statistics. While writing to the buffer is mutex-locked, reading from the buffer wasn't. This could lead to buggy reads by ethtool. This patch fixes the former blamed commit, but the bug was introduced in the latter. Signed-off-by: Colin Foster Fixes: 1e1caa9735f90 ("ocelot: Clean up stats update deferred work") Fixes: a556c76adc052 ("net: mscc: Add initial Ocelot switch support") Reported-by: Vladimir Oltean Reviewed-by: Vladimir Oltean Link: https://lore.kernel.org/all/20220210150451.416845-2-colin.foster@in-advantage.com/ Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 41a8c548d47bcdbbd5e0fa40fbb7c95cc54bcb34 Author: Dave Ertman Date: Thu Jan 20 16:27:56 2022 -0800 ice: Avoid RTNL lock when re-creating auxiliary device [ Upstream commit 5dbbbd01cbba831233c6ea9a3e6bfa133606d3c0 ] If a call to re-create the auxiliary device happens in a context that has already taken the RTNL lock, then the call flow that recreates auxiliary device can hang if there is another attempt to claim the RTNL lock by the auxiliary driver. To avoid this, any call to re-create auxiliary devices that comes from an source that is holding the RTNL lock (e.g. netdev notifier when interface exits a bond) should execute in a separate thread. To accomplish this, add a flag to the PF that will be evaluated in the service task and dealt with there. Fixes: f9f5301e7e2d ("ice: Register auxiliary device to provide RDMA") Signed-off-by: Dave Ertman Reviewed-by: Jonathan Toppins Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f9daedc3ab8f673e3a9374b91a89fbf1174df469 Author: Dave Ertman Date: Tue Jan 18 13:08:20 2022 -0800 ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler [ Upstream commit bea1898f65b9b7096cb4e73e97c83b94718f1fa1 ] Currently, the same handler is called for both a NETDEV_BONDING_INFO LAG unlink notification as for a NETDEV_UNREGISTER call. This is causing a problem though, since the netdev_notifier_info passed has a different structure depending on which event is passed. The problem manifests as a call trace from a BUG: KASAN stack-out-of-bounds error. Fix this by creating a handler specific to NETDEV_UNREGISTER that only is passed valid elements in the netdev_notifier_info struct for the NETDEV_UNREGISTER event. Also included is the removal of an unbalanced dev_put on the peer_netdev and related braces. Fixes: 6a8b357278f5 ("ice: Respond to a NETDEV_UNREGISTER event for LAG") Signed-off-by: Dave Ertman Acked-by: Jonathan Toppins Tested-by: Sunitha Mekala Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 52eb5c86ede4fd29e12ecbbcf5e0cb91988fc745 Author: Jesse Brandeburg Date: Fri Jan 14 15:38:39 2022 -0800 ice: fix IPIP and SIT TSO offload [ Upstream commit 46b699c50c0304cdbd725d7740073a7f9d5edb10 ] The driver was avoiding offload for IPIP (at least) frames due to parsing the inner header offsets incorrectly when trying to check lengths. This length check works for VXLAN frames but fails on IPIP frames because skb_transport_offset points to the inner header in IPIP frames, which meant the subtraction of transport_header from inner_network_header returns a negative value (-20). With the code before this patch, everything continued to work, but GSO was being used to segment, causing throughputs of 1.5Gb/s per thread. After this patch, throughput is more like 10Gb/s per thread for IPIP traffic. Fixes: e94d44786693 ("ice: Implement filter sync, NDO operations and bump version") Signed-off-by: Jesse Brandeburg Reviewed-by: Paul Menzel Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit efd399e12c1b5271955b594fd40256b445c8785f Author: Dan Carpenter Date: Fri Jan 7 11:02:06 2022 +0300 ice: fix an error code in ice_cfg_phy_fec() [ Upstream commit 21338d58736ef70eaae5fd75d567a358ff7902f9 ] Propagate the error code from ice_get_link_default_override() instead of returning success. Fixes: ea78ce4dab05 ("ice: add link lenient and default override support") Signed-off-by: Dan Carpenter Tested-by: Gurucharan G Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 12e067a4d98f1f74ac4efa632f40b6544b10aed1 Author: Robert-Ionut Alexa Date: Wed Feb 9 17:57:43 2022 +0200 dpaa2-eth: unregister the netdev before disconnecting from the PHY [ Upstream commit 9ccc6e0c8959a019bb40f6b18704b142c04b19a8 ] The netdev should be unregistered before we are disconnecting from the MAC/PHY so that the dev_close callback is called and the PHY and the phylink workqueues are actually stopped before we are disconnecting and destroying the phylink instance. Fixes: 719479230893 ("dpaa2-eth: add MAC/PHY support through phylink") Signed-off-by: Robert-Ionut Alexa Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 29b25d5f8f30810a98861ce1d251dd97ff634753 Author: Kishen Maloor Date: Wed Feb 9 17:25:08 2022 -0800 mptcp: netlink: process IPv6 addrs in creating listening sockets [ Upstream commit 029744cd4bc6e9eb3bd833b4a033348296d34645 ] This change updates mptcp_pm_nl_create_listen_socket() to create listening sockets bound to IPv6 addresses (where IPv6 is supported). Fixes: 1729cf186d8a ("mptcp: create the listening socket for new port") Acked-by: Geliang Tang Signed-off-by: Kishen Maloor Signed-off-by: Mat Martineau Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit dcd1c46634697d200c7012d5047302355dce098f Author: Yang Wang Date: Tue Feb 8 14:23:55 2022 +0800 drm/amd/pm: fix hwmon node of power1_label create issue [ Upstream commit a8b1e8636a3252daa729762b2e3cc9015cc91a5c ] it will cause hwmon node of power1_label is not created. v2: the hwmon node of "power1_label" is always needed for all ASICs. and the patch will remove ASIC type check for "power1_label". Fixes: ae07970a0621d6 ("drm/amd/pm: add support for hwmon control of slow and fast PPT limit on vangogh") Signed-off-by: Yang Wang Reviewed-by: Kenneth Feng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4b24ef1d03cf56008184f458be780da0125fc244 Author: Raju Rangoju Date: Wed Feb 9 10:02:01 2022 +0530 net: amd-xgbe: disable interrupts during pci removal [ Upstream commit 68c2d6af1f1e469544d6cbe9a601d96fb9c00e7f ] Hardware interrupts are enabled during the pci probe, however, they are not disabled during pci removal. Disable all hardware interrupts during pci removal to avoid any issues. Fixes: e75377404726 ("amd-xgbe: Update PCI support to use new IRQ functions") Suggested-by: Selwin Sebastian Signed-off-by: Raju Rangoju Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 489d9fa78e59712b1219b1b7d58906abf2b007fe Author: Jon Maloy Date: Tue Feb 8 22:22:37 2022 -0500 tipc: rate limit warning for received illegal binding update [ Upstream commit c7223d687758462826a20e9735305d55bb874c70 ] It would be easy to craft a message containing an illegal binding table update operation. This is handled correctly by the code, but the corresponding warning printout is not rate limited as is should be. We fix this now. Fixes: b97bf3fd8f6a ("[TIPC] Initial merge") Signed-off-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bb04b5527aff22fceb39d70cabfae28fafa8fe53 Author: Joel Stanley Date: Wed Feb 9 10:33:59 2022 +1030 net: mdio: aspeed: Add missing MODULE_DEVICE_TABLE [ Upstream commit bc1c3c3b10db4f37c41e6107751a8d450d9c431c ] Fix loading of the driver when built as a module. Fixes: f160e99462c6 ("net: phy: Add mdio-aspeed") Signed-off-by: Joel Stanley Reviewed-by: Andrew Lunn Acked-by: Andrew Jeffery Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b8ac37e570441a5636b329a7f248f5606f774ae9 Author: Eric Dumazet Date: Tue Feb 8 15:28:22 2022 -0800 veth: fix races around rq->rx_notify_masked [ Upstream commit 68468d8c4cd4222a4ca1f185ab5a1c14480d078c ] veth being NETIF_F_LLTX enabled, we need to be more careful whenever we read/write rq->rx_notify_masked. BUG: KCSAN: data-race in veth_xmit / veth_xmit write to 0xffff888133d9a9f8 of 1 bytes by task 23552 on cpu 0: __veth_xdp_flush drivers/net/veth.c:269 [inline] veth_xmit+0x307/0x470 drivers/net/veth.c:350 __netdev_start_xmit include/linux/netdevice.h:4683 [inline] netdev_start_xmit include/linux/netdevice.h:4697 [inline] xmit_one+0x105/0x2f0 net/core/dev.c:3473 dev_hard_start_xmit net/core/dev.c:3489 [inline] __dev_queue_xmit+0x86d/0xf90 net/core/dev.c:4116 dev_queue_xmit+0x13/0x20 net/core/dev.c:4149 br_dev_queue_push_xmit+0x3ce/0x430 net/bridge/br_forward.c:53 NF_HOOK include/linux/netfilter.h:307 [inline] br_forward_finish net/bridge/br_forward.c:66 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] __br_forward+0x2e4/0x400 net/bridge/br_forward.c:115 br_flood+0x521/0x5c0 net/bridge/br_forward.c:242 br_dev_xmit+0x8b6/0x960 __netdev_start_xmit include/linux/netdevice.h:4683 [inline] netdev_start_xmit include/linux/netdevice.h:4697 [inline] xmit_one+0x105/0x2f0 net/core/dev.c:3473 dev_hard_start_xmit net/core/dev.c:3489 [inline] __dev_queue_xmit+0x86d/0xf90 net/core/dev.c:4116 dev_queue_xmit+0x13/0x20 net/core/dev.c:4149 neigh_hh_output include/net/neighbour.h:525 [inline] neigh_output include/net/neighbour.h:539 [inline] ip_finish_output2+0x6f8/0xb70 net/ipv4/ip_output.c:228 ip_finish_output+0xfb/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip_output+0xf3/0x1a0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:451 [inline] ip_local_out net/ipv4/ip_output.c:126 [inline] ip_send_skb+0x6e/0xe0 net/ipv4/ip_output.c:1570 udp_send_skb+0x641/0x880 net/ipv4/udp.c:967 udp_sendmsg+0x12ea/0x14c0 net/ipv4/udp.c:1254 inet_sendmsg+0x5f/0x80 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae read to 0xffff888133d9a9f8 of 1 bytes by task 23563 on cpu 1: __veth_xdp_flush drivers/net/veth.c:268 [inline] veth_xmit+0x2d6/0x470 drivers/net/veth.c:350 __netdev_start_xmit include/linux/netdevice.h:4683 [inline] netdev_start_xmit include/linux/netdevice.h:4697 [inline] xmit_one+0x105/0x2f0 net/core/dev.c:3473 dev_hard_start_xmit net/core/dev.c:3489 [inline] __dev_queue_xmit+0x86d/0xf90 net/core/dev.c:4116 dev_queue_xmit+0x13/0x20 net/core/dev.c:4149 br_dev_queue_push_xmit+0x3ce/0x430 net/bridge/br_forward.c:53 NF_HOOK include/linux/netfilter.h:307 [inline] br_forward_finish net/bridge/br_forward.c:66 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] __br_forward+0x2e4/0x400 net/bridge/br_forward.c:115 br_flood+0x521/0x5c0 net/bridge/br_forward.c:242 br_dev_xmit+0x8b6/0x960 __netdev_start_xmit include/linux/netdevice.h:4683 [inline] netdev_start_xmit include/linux/netdevice.h:4697 [inline] xmit_one+0x105/0x2f0 net/core/dev.c:3473 dev_hard_start_xmit net/core/dev.c:3489 [inline] __dev_queue_xmit+0x86d/0xf90 net/core/dev.c:4116 dev_queue_xmit+0x13/0x20 net/core/dev.c:4149 neigh_hh_output include/net/neighbour.h:525 [inline] neigh_output include/net/neighbour.h:539 [inline] ip_finish_output2+0x6f8/0xb70 net/ipv4/ip_output.c:228 ip_finish_output+0xfb/0x240 net/ipv4/ip_output.c:316 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip_output+0xf3/0x1a0 net/ipv4/ip_output.c:430 dst_output include/net/dst.h:451 [inline] ip_local_out net/ipv4/ip_output.c:126 [inline] ip_send_skb+0x6e/0xe0 net/ipv4/ip_output.c:1570 udp_send_skb+0x641/0x880 net/ipv4/udp.c:967 udp_sendmsg+0x12ea/0x14c0 net/ipv4/udp.c:1254 inet_sendmsg+0x5f/0x80 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 23563 Comm: syz-executor.5 Not tainted 5.17.0-rc2-syzkaller-00064-gc36c04c2e132 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 948d4f214fde ("veth: Add driver XDP") Signed-off-by: Eric Dumazet Cc: Toshiaki Makita Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fdcb263fa5cda15b8cb24a641fa2718c47605314 Author: Antoine Tenart Date: Mon Feb 7 18:13:19 2022 +0100 net: fix a memleak when uncloning an skb dst and its metadata [ Upstream commit 9eeabdf17fa0ab75381045c867c370f4cc75a613 ] When uncloning an skb dst and its associated metadata, a new dst+metadata is allocated and later replaces the old one in the skb. This is helpful to have a non-shared dst+metadata attached to a specific skb. The issue is the uncloned dst+metadata is initialized with a refcount of 1, which is increased to 2 before attaching it to the skb. When tun_dst_unclone returns, the dst+metadata is only referenced from a single place (the skb) while its refcount is 2. Its refcount will never drop to 0 (when the skb is consumed), leading to a memory leak. Fix this by removing the call to dst_hold in tun_dst_unclone, as the dst+metadata refcount is already 1. Fixes: fc4099f17240 ("openvswitch: Fix egress tunnel info.") Cc: Pravin B Shelar Reported-by: Vlad Buslov Tested-by: Vlad Buslov Signed-off-by: Antoine Tenart Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f1ab1ba32d36bae06fabe41c0ff2edc5b2ce628d Author: Antoine Tenart Date: Mon Feb 7 18:13:18 2022 +0100 net: do not keep the dst cache when uncloning an skb dst and its metadata [ Upstream commit cfc56f85e72f5b9c5c5be26dc2b16518d36a7868 ] When uncloning an skb dst and its associated metadata a new dst+metadata is allocated and the tunnel information from the old metadata is copied over there. The issue is the tunnel metadata has references to cached dst, which are copied along the way. When a dst+metadata refcount drops to 0 the metadata is freed including the cached dst entries. As they are also referenced in the initial dst+metadata, this ends up in UaFs. In practice the above did not happen because of another issue, the dst+metadata was never freed because its refcount never dropped to 0 (this will be fixed in a subsequent patch). Fix this by initializing the dst cache after copying the tunnel information from the old metadata to also unshare the dst cache. Fixes: d71785ffc7e7 ("net: add dst_cache to ovs vxlan lwtunnel") Cc: Paolo Abeni Reported-by: Vlad Buslov Tested-by: Vlad Buslov Signed-off-by: Antoine Tenart Acked-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6cbe14cc0eb6e445b607619dc4c76e922fd1ee1c Author: Louis Peens Date: Tue Feb 8 11:14:53 2022 +0100 nfp: flower: fix ida_idx not being released [ Upstream commit 7db788ad627aabff2b74d4f1a3b68516d0fee0d7 ] When looking for a global mac index the extra NFP_TUN_PRE_TUN_IDX_BIT that gets set if nfp_flower_is_supported_bridge is true is not taken into account. Consequently the path that should release the ida_index in cleanup is never triggered, causing messages like: nfp 0000:02:00.0: nfp: Failed to offload MAC on br-ex. nfp 0000:02:00.0: nfp: Failed to offload MAC on br-ex. nfp 0000:02:00.0: nfp: Failed to offload MAC on br-ex. after NFP_MAX_MAC_INDEX number of reconfigs. Ultimately this lead to new tunnel flows not being offloaded. Fix this by unsetting the NFP_TUN_PRE_TUN_IDX_BIT before checking if the port is of type OTHER. Fixes: 2e0bc7f3cb55 ("nfp: flower: encode mac indexes with pre-tunnel rule check") Signed-off-by: Louis Peens Signed-off-by: Simon Horman Link: https://lore.kernel.org/r/20220208101453.321949-1-simon.horman@corigine.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3cab045c99dbb9a94eb2d1d405f399916eec698a Author: Eric Dumazet Date: Mon Feb 7 21:34:51 2022 -0800 ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path [ Upstream commit 5611a00697c8ecc5aad04392bea629e9d6a20463 ] ip[6]mr_free_table() can only be called under RTNL lock. RTNL: assertion failed at net/core/dev.c (10367) WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Modules linked in: CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367 Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee RSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4 R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000 FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f4ab89f9059 Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f. RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038 RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059 RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000 RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300 R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000 R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000 Fixes: f243e5a7859a ("ipmr,ip6mr: call ip6mr_free_table() on failure path") Signed-off-by: Eric Dumazet Cc: Cong Wang Reported-by: syzbot Link: https://lore.kernel.org/r/20220208053451.2885398-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit b5652bc50dde7b84e93dfb25479b64b817e377c1 Author: Vladimir Oltean Date: Mon Feb 7 18:15:53 2022 +0200 net: dsa: lantiq_gswip: don't use devres for mdiobus [ Upstream commit 0d120dfb5d67edc5bcd1804e167dba2b30809afd ] As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The GSWIP switch is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the GSWIP switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The gswip driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 46b7472323296329881631da63eb456cb292f788 Author: Vladimir Oltean Date: Mon Feb 7 18:15:52 2022 +0200 net: dsa: mt7530: fix kernel bug in mdiobus_free() when unbinding [ Upstream commit 9ffe3d09e32da45bb5a29cf2e80ec8d7534010c5 ] Nobody in this driver calls mdiobus_unregister(), which is necessary if mdiobus_register() completes successfully. So if the devres callbacks that free the mdiobus get invoked (this is the case when unbinding the driver), mdiobus_free() will BUG if the mdiobus is still registered, which it is. My speculation is that this is due to the fact that prior to commit ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") from June 2020, _devm_mdiobus_free() used to call mdiobus_unregister(). But at the time that the mt7530 support was introduced in May 2021, the API was already changed. It's therefore likely that the blamed patch was developed on an older tree, and incorrectly adapted to net-next. This makes the Fixes: tag correct. Fix the problem by using the devres variant of mdiobus_register. Fixes: ba751e28d442 ("net: dsa: mt7530: add interrupt support") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8cda7577a0b4018572f31e0caadfabd305ea2786 Author: Vladimir Oltean Date: Mon Feb 7 18:15:50 2022 +0200 net: dsa: felix: don't use devres for mdiobus [ Upstream commit 209bdb7ec6a28c7cdf580a0a98afbc9fc3b98932 ] As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Felix VSC9959 switch is a PCI device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the felix switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The felix driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc_size() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit caabb5f64f5c32fceed93356bb688ef1ec6c5783 Author: Vladimir Oltean Date: Mon Feb 7 18:15:49 2022 +0200 net: dsa: bcm_sf2: don't use devres for mdiobus [ Upstream commit 08f1a20822349004bb9cc1b153ecb516e9f2889d ] As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The Starfighter 2 is a platform device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the bcm_sf2 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The bcm_sf2 driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit aae1c6a1d3d696fc33b609fb12fe744a556d1dc5 Author: Vladimir Oltean Date: Mon Feb 7 18:15:48 2022 +0200 net: dsa: ar9331: register the mdiobus under devres [ Upstream commit 50facd86e9fbc4b93fe02e5fe05776047f45dbfb ] As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The ar9331 is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the ar9331 switch driver on shutdown. So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The ar9331 driver doesn't have a complex code structure for mdiobus removal, so just replace of_mdiobus_register with the devres variant in order to be all-devres and ensure that we don't free a still-registered bus. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Tested-by: Oleksij Rempel Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 8b626d45127d6f5ada7d815b83cfdc09e8cb1394 Author: Vladimir Oltean Date: Mon Feb 7 18:15:47 2022 +0200 net: dsa: mv88e6xxx: don't use devres for mdiobus [ Upstream commit f53a2ce893b2c7884ef94471f170839170a4eba0 ] As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres") mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered. The mv88e6xxx is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here. If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the Marvell switch driver on shutdown. systemd-shutdown[1]: Powering off. mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down fsl-mc dpbp.9: Removing from iommu group 7 fsl-mc dpbp.8: Removing from iommu group 7 ------------[ cut here ]------------ kernel BUG at drivers/net/phy/mdio_bus.c:677! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15 pc : mdiobus_free+0x44/0x50 lr : devm_mdiobus_free+0x10/0x20 Call trace: mdiobus_free+0x44/0x50 devm_mdiobus_free+0x10/0x20 devres_release_all+0xa0/0x100 __device_release_driver+0x190/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x4c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 kernel_power_off+0x34/0x6c __do_sys_reboot+0x15c/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17c So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all. The Marvell driver already has a good structure for mdiobus removal, so just plug in mdiobus_free and get rid of devres. Fixes: ac3a68d56651 ("net: phy: don't abuse devres in devm_mdiobus_register()") Reported-by: Rafael Richter Signed-off-by: Vladimir Oltean Tested-by: Daniel Klauer Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 147540cae264922a029cff326c85691e4c705168 Author: Mahesh Bandewar Date: Mon Feb 7 14:29:01 2022 -0800 bonding: pair enable_port with slave_arr_updates [ Upstream commit 23de0d7b6f0e3f9a6283a882594c479949da1120 ] When 803.2ad mode enables a participating port, it should update the slave-array. I have observed that the member links are participating and are part of the active aggregator while the traffic is egressing via only one member link (in a case where two links are participating). Via kprobes I discovered that slave-arr has only one link added while the other participating link wasn't part of the slave-arr. I couldn't see what caused that situation but the simple code-walk through provided me hints that the enable_port wasn't always associated with the slave-array update. Fixes: ee6377147409 ("bonding: Simplify the xmit function for modes that use xmit_hash") Signed-off-by: Mahesh Bandewar Acked-by: Jay Vosburgh Link: https://lore.kernel.org/r/20220207222901.1795287-1-maheshb@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3523167d665852fc5f92971aefea8f3bd4e2f6fd Author: Helge Deller Date: Mon Feb 7 16:59:31 2022 +0100 fbcon: Avoid 'cap' set but not used warning [ Upstream commit 50b10528aad568c95f772039d4b3093b4aea7439 ] Fix this kernel test robot warning: drivers/video/fbdev/core/fbcon.c: In function 'fbcon_init': drivers/video/fbdev/core/fbcon.c:1028:6: warning: variable 'cap' set but not used [-Wunused-but-set-variable] The cap variable is only used when CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION is enabled. Drop the temporary variable and use info->flags instead. Fixes: 87ab9f6b7417 ("Revert "fbcon: Disable accelerated scrolling") Reported-by: kernel test robot Signed-off-by: Helge Deller Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/YgFB4xqI+As196FR@p100 Signed-off-by: Sasha Levin commit ef2cb1fc03659a1ff6a8662be681341c7aaa85e7 Author: Niklas Cassel Date: Fri Feb 4 13:02:25 2022 +0000 gpio: sifive: use the correct register to read output values [ Upstream commit cc38ef936840ac29204d806deb4d1836ec509594 ] Setting the output of a GPIO to 1 using gpiod_set_value(), followed by reading the same GPIO using gpiod_get_value(), will currently yield an incorrect result. This is because the SiFive GPIO device stores the output values in reg_set, not reg_dat. Supply the flag BGPIOF_READ_OUTPUT_REG_SET to bgpio_init() so that the generic driver reads the correct register. Fixes: 96868dce644d ("gpio/sifive: Add GPIO driver for SiFive SoCs") Signed-off-by: Niklas Cassel Reviewed-by: Linus Walleij [Bartosz: added the Fixes tag] Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit d9daa2b76dde725090082d8a3107895a2d6bfc5e Author: Andy Shevchenko Date: Tue Feb 1 17:27:55 2022 +0200 gpiolib: Never return internal error codes to user space [ Upstream commit 95a4eed7dd5b7c1c3664a626174290686ddbee9f ] Currently it's possible that character device interface may return the error codes which are not supposed to be seen by user space. In this case it's EPROBE_DEFER. Wrap it to return -ENODEV instead as sysfs does. Fixes: d7c51b47ac11 ("gpio: userspace ABI for reading/writing GPIO lines") Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events") Fixes: 3c0d9c635ae2 ("gpiolib: cdev: support GPIO_V2_GET_LINE_IOCTL and GPIO_V2_LINE_GET_VALUES_IOCTL") Reported-by: Suresh Balakrishnan Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit e799974e7cbb2e77ec12431512e155574c6ed333 Author: Rafael J. Wysocki Date: Fri Feb 4 18:31:02 2022 +0100 ACPI: PM: s2idle: Cancel wakeup before dispatching EC GPE [ Upstream commit dc0075ba7f387fe4c48a8c674b11ab6f374a6acc ] Commit 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") made acpi_ec_dispatch_gpe() check pm_wakeup_pending(), but that is before canceling the SCI wakeup, so pm_wakeup_pending() is always true. This causes the loop in acpi_ec_dispatch_gpe() to always terminate after one iteration which may not be correct. Address this issue by canceling the SCI wakeup earlier, from acpi_ec_dispatch_gpe() itself. Fixes: 4a9af6cac050 ("ACPI: EC: Rework flushing of EC work while suspended to idle") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ab142ea5d50270f0a4bdb1c7eb4b947bc3ca972b Author: Christoph Niedermaier Date: Tue Feb 1 12:01:53 2022 +0100 drm/panel: simple: Assign data from panel_dpi_probe() correctly [ Upstream commit 6df4432a5eca101b5fd80fbee41d309f3d67928d ] In the function panel_simple_probe() the pointer panel->desc is assigned to the passed pointer desc. If function panel_dpi_probe() is called panel->desc will be updated, but further on only desc will be evaluated. So update the desc pointer to be able to use the data from the function panel_dpi_probe(). Fixes: 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") Signed-off-by: Christoph Niedermaier Cc: Marek Vasut Cc: Thierry Reding Cc: Sam Ravnborg Cc: David Airlie Cc: Daniel Vetter To: dri-devel@lists.freedesktop.org Reviewed-by: Sam Ravnborg Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/20220201110153.3479-1-cniedermaier@dh-electronics.com Signed-off-by: Sasha Levin commit 9e3dd49145f3ff1aaf2eaa5a35f838a64a063e9f Author: Samuel Mendoza-Jonas Date: Thu Feb 3 14:49:16 2022 -0800 ixgbevf: Require large buffers for build_skb on 82599VF [ Upstream commit fe68195daf34d5dddacd3f93dd3eafc4beca3a0e ] From 4.17 onwards the ixgbevf driver uses build_skb() to build an skb around new data in the page buffer shared with the ixgbe PF. This uses either a 2K or 3K buffer, and offsets the DMA mapping by NET_SKB_PAD + NET_IP_ALIGN. When using a smaller buffer RXDCTL is set to ensure the PF does not write a full 2K bytes into the buffer, which is actually 2K minus the offset. However on the 82599 virtual function, the RXDCTL mechanism is not available. The driver attempts to work around this by using the SET_LPE mailbox method to lower the maximm frame size, but the ixgbe PF driver ignores this in order to keep the PF and all VFs in sync[0]. This means the PF will write up to the full 2K set in SRRCTL, causing it to write NET_SKB_PAD + NET_IP_ALIGN bytes past the end of the buffer. With 4K pages split into two buffers, this means it either writes NET_SKB_PAD + NET_IP_ALIGN bytes past the first buffer (and into the second), or NET_SKB_PAD + NET_IP_ALIGN bytes past the end of the DMA mapping. Avoid this by only enabling build_skb when using "large" buffers (3K). These are placed in each half of an order-1 page, preventing the PF from writing past the end of the mapping. [0]: Technically it only ever raises the max frame size, see ixgbe_set_vf_lpe() in ixgbe_sriov.c Fixes: f15c5ba5b6cd ("ixgbevf: add support for using order 1 pages to receive large frames") Signed-off-by: Samuel Mendoza-Jonas Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51eece9f8a1d5a0d5d2ca59eb21aab015950abe5 Author: Lutz Koschorreck Date: Fri Jan 28 20:31:50 2022 +0100 arm64: dts: meson-sm1-odroid: fix boot loop after reboot [ Upstream commit e6b03375132fefddc55cf700418cf794b3884e0c ] Since the correct gpio pin is used for enabling tf-io regulator the system did not boot correctly after calling reboot. [ 36.862443] reboot: Restarting system bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:B;RCY:0;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:0;READ:0;0.0;CHK:0; bl2_stage_init 0x01 bl2_stage_init 0x81 hw id: SM1:BL:511f6b:81ca2f;FEAT:A0F83180:20282000;POC:B;RCY:0;SPINOR:0;CHK:1F;EMMC:800;NAND:81;SD?:0;SD:400;USB:8;LOOP:1;... Setting the gpio to open drain solves the issue. Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator") Signed-off-by: Lutz Koschorreck Reviewed-by: Neil Armstrong [narmstrong: reduced serial log & removed invalid character in commit message] Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220128193150.GA1304381@odroid-VirtualBox Signed-off-by: Sasha Levin commit 57154c07ed62f17b33800a5ccb27333b69e87366 Author: Dongjin Kim Date: Fri Jan 28 00:16:56 2022 +0900 arm64: dts: meson-sm1-bananapi-m5: fix wrong GPIO domain for GPIOE_2 [ Upstream commit a5be3e5d46f373fe1d2ee835c7ede31769c241cd ] GPIOE_2 is in AO domain and "<&gpio GPIOE_2 ...>" changes the state of TF_PWR_EN of 'FC8731' on BPI-M5 Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts") Signed-off-by: Dongjin Kim Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20220127151656.GA2419733@paju Signed-off-by: Sasha Levin commit 162f8057192c247096c1ba4d39c8450f14b86e40 Author: Lutz Koschorreck Date: Thu Jan 27 14:05:37 2022 +0100 arm64: dts: meson-sm1-odroid: use correct enable-gpio pin for tf-io regulator [ Upstream commit 323ca765bfe9d637fa774373baec0bc41e51fcfa ] The interrupt pin of the external ethernet phy is used, instead of the enable-gpio pin of the tf-io regulator. The GPIOE_2 pin is located in the gpio_ao bank. This causes phy interrupt problems at system startup. [ 76.645190] irq 36: nobody cared (try booting with the "irqpoll" option) [ 76.649617] CPU: 0 PID: 1416 Comm: irq/36-0.0:00 Not tainted 5.16.0 #2 [ 76.649629] Hardware name: Hardkernel ODROID-HC4 (DT) [ 76.649635] Call trace: [ 76.649638] dump_backtrace+0x0/0x1c8 [ 76.649658] show_stack+0x14/0x60 [ 76.649667] dump_stack_lvl+0x64/0x7c [ 76.649676] dump_stack+0x14/0x2c [ 76.649683] __report_bad_irq+0x38/0xe8 [ 76.649695] note_interrupt+0x220/0x3a0 [ 76.649704] handle_irq_event_percpu+0x58/0x88 [ 76.649713] handle_irq_event+0x44/0xd8 [ 76.649721] handle_fasteoi_irq+0xa8/0x130 [ 76.649730] generic_handle_domain_irq+0x38/0x58 [ 76.649738] gic_handle_irq+0x9c/0xb8 [ 76.649747] call_on_irq_stack+0x28/0x38 [ 76.649755] do_interrupt_handler+0x7c/0x80 [ 76.649763] el1_interrupt+0x34/0x80 [ 76.649772] el1h_64_irq_handler+0x14/0x20 [ 76.649781] el1h_64_irq+0x74/0x78 [ 76.649788] irq_finalize_oneshot.part.56+0x68/0xf8 [ 76.649796] irq_thread_fn+0x5c/0x98 [ 76.649804] irq_thread+0x13c/0x260 [ 76.649812] kthread+0x144/0x178 [ 76.649822] ret_from_fork+0x10/0x20 [ 76.649830] handlers: [ 76.653170] [<0000000025a6cd31>] irq_default_primary_handler threaded [<0000000093580eb7>] phy_interrupt [ 76.661256] Disabling IRQ #36 Fixes: 1f80a5cf74a6 ("arm64: dts: meson-sm1-odroid: add missing enable gpio and supply for tf_io regulator") Signed-off-by: Lutz Koschorreck Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong [narmstrong: removed spurious invalid & blank lines from commit message] Link: https://lore.kernel.org/r/20220127130537.GA187347@odroid-VirtualBox Signed-off-by: Sasha Levin commit 006dc5815bb32b4536ebbb0a55a68e5f12568da6 Author: Dongjin Kim Date: Thu Jan 27 21:29:25 2022 +0900 arm64: dts: meson-g12b-odroid-n2: fix typo 'dio2133' [ Upstream commit bc41099f060ea74ac8d02c51bd0f5f46d969bedf ] Typo in audio amplifier node, dioo2133 -> dio2133 Signed-off-by: Dongjin Kim Fixes: ef599f5f3e10 ("arm64: dts: meson: convert ODROID-N2 to dtsi") Fixes: 67d141c1f8e6 ("arm64: dts: meson: odroid-n2: add jack audio output support") Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/YfKQJejh0bfGYvof@anyang Signed-off-by: Sasha Levin commit c5ee4cbd0f1bd729bc417ba72bc29c835f9b0e08 Author: Florian Westphal Date: Wed Feb 2 12:00:56 2022 +0100 netfilter: ctnetlink: disable helper autoassign [ Upstream commit d1ca60efc53d665cf89ed847a14a510a81770b81 ] When userspace, e.g. conntrackd, inserts an entry with a specified helper, its possible that the helper is lost immediately after its added: ctnetlink_create_conntrack -> nf_ct_helper_ext_add + assign helper -> ctnetlink_setup_nat -> ctnetlink_parse_nat_setup -> parse_nat_setup -> nfnetlink_parse_nat_setup -> nf_nat_setup_info -> nf_conntrack_alter_reply -> __nf_ct_try_assign_helper ... and __nf_ct_try_assign_helper will zero the helper again. Set IPS_HELPER bit to bypass auto-assign logic, its unwanted, just like when helper is assigned via ruleset. Dropped old 'not strictly necessary' comment, it referred to use of rcu_assign_pointer() before it got replaced by RCU_INIT_POINTER(). NB: Fixes tag intentionally incorrect, this extends the referenced commit, but this change won't build without IPS_HELPER introduced there. Fixes: 6714cf5465d280 ("netfilter: nf_conntrack: fix explicit helper attachment and NAT") Reported-by: Pham Thanh Tuyen Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7f486bed5ec09c7549879a9f817a723b732abf1c Author: Steen Hegelund Date: Thu Feb 3 11:29:00 2022 +0100 net: sparx5: Fix get_stat64 crash in tcpdump [ Upstream commit ed14fc7a79ab43e9f2cb1fa9c1733fdc133bba30 ] This problem was found with Sparx5 when the tcpdump tool requests the do_get_stats64 (sparx5_get_stats64) statistic. The portstats pointer was incorrectly incremented when fetching priority based statistics. Fixes: af4b11022e2d (net: sparx5: add ethtool configuration and statistics support) Signed-off-by: Steen Hegelund Link: https://lore.kernel.org/r/20220203102900.528987-1-steen.hegelund@microchip.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e4382d0a39f9a1e260d62fdc079ddae5293c037d Author: Mathias Krause Date: Thu Jan 27 14:02:18 2022 +0100 misc: fastrpc: avoid double fput() on failed usercopy [ Upstream commit 46963e2e0629cb31c96b1d47ddd89dc3d8990b34 ] If the copy back to userland fails for the FASTRPC_IOCTL_ALLOC_DMA_BUFF ioctl(), we shouldn't assume that 'buf->dmabuf' is still valid. In fact, dma_buf_fd() called fd_install() before, i.e. "consumed" one reference, leaving us with none. Calling dma_buf_put() will therefore put a reference we no longer own, leading to a valid file descritor table entry for an already released 'file' object which is a straight use-after-free. Simply avoid calling dma_buf_put() and rely on the process exit code to do the necessary cleanup, if needed, i.e. if the file descriptor is still valid. Fixes: 6cffd79504ce ("misc: fastrpc: Add support for dmabuf exporter") Acked-by: Christian König Signed-off-by: Mathias Krause Link: https://lore.kernel.org/r/20220127130218.809261-1-minipli@grsecurity.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f5e8733d93cf968060413d85530fbf2012f61037 Author: Dave Stevenson Date: Thu Jan 27 14:51:16 2022 +0100 drm/vc4: hdmi: Allow DBLCLK modes even if horz timing is odd. [ Upstream commit 1d118965965f89948236ebe23072bb1fca5e7832 ] The 2711 pixel valve can't produce odd horizontal timings, and checks were added to vc4_hdmi_encoder_atomic_check and vc4_hdmi_encoder_mode_valid to filter out/block selection of such modes. Modes with DRM_MODE_FLAG_DBLCLK double all the horizontal timing values before programming them into the PV. The PV values, therefore, can not be odd, and so the modes can be supported. Amend the filtering appropriately. Fixes: 57fb32e632be ("drm/vc4: hdmi: Block odd horizontal timings") Signed-off-by: Dave Stevenson Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220127135116.298278-1-maxime@cerno.tech Signed-off-by: Sasha Levin commit 3d2bc21a67681855e6a5906a20d4a09bd9b196cb Author: trondmy@kernel.org Date: Tue Jan 18 19:52:16 2022 -0500 NFS: Don't skip directory entries when doing uncached readdir [ Upstream commit ce292d8faf41f62e0fb0c78476c6fce5d629235a ] Ensure that we initialise desc->cache_entry_index correctly in uncached_readdir(). Fixes: d1bacf9eb2fd ("NFS: add readdir cache array") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 557302faea9c8859ddbbc6cac2f17dcab75f44ab Author: trondmy@kernel.org Date: Tue Jan 18 19:25:42 2022 -0500 NFS: Don't overfill uncached readdir pages [ Upstream commit d9c4e39c1f8f8a8ebaccf00b8f22c14364b2d27e ] If we're doing an uncached read of the directory, then we ideally want to read only the exact set of entries that will fit in the buffer supplied by the getdents() system call. So unlike the case where we're reading into the page cache, let's send only one READDIR call, before trying to fill up the buffer. Fixes: 35df59d3ef69 ("NFS: Reduce number of RPC calls when doing uncached readdir") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 00181d6c966549b470b09dda8c26445abe62614c Author: Geert Uytterhoeven Date: Mon Jan 31 11:35:53 2022 +0100 gpio: aggregator: Fix calling into sleeping GPIO controllers [ Upstream commit 2cba05451a6d0c703bb74f1a250691404f27c4f1 ] If the parent GPIO controller is a sleeping controller (e.g. a GPIO controller connected to I2C), getting or setting a GPIO triggers a might_sleep() warning. This happens because the GPIO Aggregator takes the can_sleep flag into account only for its internal locking, not for calling into the parent GPIO controller. Fix this by using the gpiod_[gs]et*_cansleep() APIs when calling into a sleeping GPIO controller. Reported-by: Mikko Salomäki Fixes: 828546e24280f721 ("gpio: Add GPIO Aggregator") Signed-off-by: Geert Uytterhoeven Reviewed-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit ddcb149ce10a31e3d9bcba38033b39d3c29dee74 Author: Liu Ying Date: Mon Jan 24 10:40:07 2022 +0800 phy: dphy: Correct clk_pre parameter [ Upstream commit 9a8406ba1a9a2965c27e0db1d7753471d12ee9ff ] The D-PHY specification (v1.2) explicitly mentions that the T-CLK-PRE parameter's unit is Unit Interval(UI) and the minimum value is 8. Also, kernel doc of the 'clk_pre' member of struct phy_configure_opts_mipi_dphy mentions that it should be in UI. However, the dphy core driver wrongly sets 'clk_pre' to 8000, which seems to hint that it's in picoseconds. So, let's fix the dphy core driver to correctly reflect the T-CLK-PRE parameter's minimum value according to the D-PHY specification. I'm assuming that all impacted custom drivers shall program values in TxByteClkHS cycles into hardware for the T-CLK-PRE parameter. The D-PHY specification mentions that the frequency of TxByteClkHS is exactly 1/8 the High-Speed(HS) bit rate(each HS bit consumes one UI). So, relevant custom driver code is changed to program those values as DIV_ROUND_UP(cfg->clk_pre, BITS_PER_BYTE), then. Note that I've only tested the patch with RM67191 DSI panel on i.MX8mq EVK. Help is needed to test with other i.MX8mq, Meson and Rockchip platforms, as I don't have the hardwares. Fixes: 2ed869990e14 ("phy: Add MIPI D-PHY configuration options") Tested-by: Liu Ying # RM67191 DSI panel on i.MX8mq EVK Reviewed-by: Andrzej Hajda Reviewed-by: Neil Armstrong # for phy-meson-axg-mipi-dphy.c Tested-by: Neil Armstrong # for phy-meson-axg-mipi-dphy.c Tested-by: Guido Günther # Librem 5 (imx8mq) with it's rather picky panel Reviewed-by: Laurent Pinchart Signed-off-by: Liu Ying Link: https://lore.kernel.org/r/20220124024007.1465018-1-victor.liu@nxp.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 72a8aee863af099d4434314c4536d6c9a61dcf3c Author: Udipto Goswami Date: Thu Jan 27 09:39:55 2022 +0530 usb: f_fs: Fix use-after-free for epfile [ Upstream commit ebe2b1add1055b903e2acd86b290a85297edc0b3 ] Consider a case where ffs_func_eps_disable is called from ffs_func_disable as part of composition switch and at the same time ffs_epfile_release get called from userspace. ffs_epfile_release will free up the read buffer and call ffs_data_closed which in turn destroys ffs->epfiles and mark it as NULL. While this was happening the driver has already initialized the local epfile in ffs_func_eps_disable which is now freed and waiting to acquire the spinlock. Once spinlock is acquired the driver proceeds with the stale value of epfile and tries to free the already freed read buffer causing use-after-free. Following is the illustration of the race: CPU1 CPU2 ffs_func_eps_disable epfiles (local copy) ffs_epfile_release ffs_data_closed if (last file closed) ffs_data_reset ffs_data_clear ffs_epfiles_destroy spin_lock dereference epfiles Fix this races by taking epfiles local copy & assigning it under spinlock and if epfiles(local) is null then update it in ffs->epfiles then finally destroy it. Extending the scope further from the race, protecting the ep related structures, and concurrent accesses. Fixes: a9e6f83c2df1 ("usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable") Co-developed-by: Udipto Goswami Reviewed-by: John Keeping Signed-off-by: Pratham Pratap Signed-off-by: Udipto Goswami Link: https://lore.kernel.org/r/1643256595-10797-1-git-send-email-quic_ugoswami@quicinc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ed2f9a97a92559c28435d7fb229aac3ac88a224 Author: Martin Kepplinger Date: Fri Jan 21 10:33:25 2022 +0100 arm64: dts: imx8mq: fix mipi_csi bidirectional port numbers [ Upstream commit 283d45145fbf460dbaf0229cacd7ed60ec52f364 ] The port numbers for the imx8mq mipi csi controller are wrong and the mipi driver can't find any media devices as port@1 is connected to the CSI bridge, not port@0. And port@0 is connected to the source - the sensor. Fix this. Fixes: bcadd5f66c2a ("arm64: dts: imx8mq: add mipi csi phy and csi bridge descriptions") Signed-off-by: Martin Kepplinger Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit af6a1d60a13cbfd4dc56320eb55249cf1e3750a0 Author: Rob Herring Date: Thu Jan 20 11:23:55 2022 -0600 ARM: dts: imx7ulp: Fix 'assigned-clocks-parents' typo [ Upstream commit 6d58c5e21a3fe355ce6d1808e96d02a610265218 ] The correct property name is 'assigned-clock-parents', not 'assigned-clocks-parents'. Though if the platform works with the typo, one has to wonder if the property is even needed. Signed-off-by: Rob Herring Fixes: 8b8c7d97e2c7 ("ARM: dts: imx7ulp: Add wdog1 node") Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 94b16ca86ab688ed6fad4548f70137f93cf1f0a9 Author: Dan Carpenter Date: Wed Jan 12 14:17:24 2022 +0300 phy: stm32: fix a refcount leak in stm32_usbphyc_pll_enable() [ Upstream commit cfc826c88a79e22ba5d8001556eb2c7efd8a01b6 ] This error path needs to decrement "usbphyc->n_pll_cons.counter" before returning. Fixes: 5b1af71280ab ("phy: stm32: rework PLL Lock detection") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20220112111724.GB3019@kili Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 541ec7bfeed36a74b47ea8b440da0591ea05d555 Author: Robert Hancock Date: Tue Jan 25 18:16:00 2022 -0600 phy: xilinx: zynqmp: Fix bus width setting for SGMII [ Upstream commit 37291f60d0822f191748c2a54ce63b0bc669020f ] TX_PROT_BUS_WIDTH and RX_PROT_BUS_WIDTH are single registers with separate bit fields for each lane. The code in xpsgtr_phy_init_sgmii was not preserving the existing register value for other lanes, so enabling the PHY in SGMII mode on one lane zeroed out the settings for all other lanes, causing other PS-GTR peripherals such as USB3 to malfunction. Use xpsgtr_clr_set to only manipulate the desired bits in the register. Fixes: 4a33bea00314 ("phy: zynqmp: Add PHY driver for the Xilinx ZynqMP Gigabit Transceiver") Signed-off-by: Robert Hancock Acked-by: Michal Simek Reviewed-by: Laurent Pinchart Link: https://lore.kernel.org/r/20220126001600.1592218-1-robert.hancock@calian.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 58c42f415b81832db9991b3a133eeebbc050fb36 Author: Fabio Estevam Date: Sun Dec 19 19:42:15 2021 -0300 ARM: dts: imx6qdl-udoo: Properly describe the SD card detect [ Upstream commit 993d66140f8d1c1853a3b58b77b43b681eb64dee ] GPIO7_IO00 is used as SD card detect. Properly describe this in the devicetree. Fixes: 40cdaa542cf0 ("ARM: dts: imx6q-udoo: Add initial board support") Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 025c6eef14904d35a7aa52a557e7e330360780a4 Author: Uwe Kleine-König Date: Tue Jan 18 19:13:37 2022 +0100 staging: fbtft: Fix error path in fbtft_driver_module_init() [ Upstream commit 426aca16e903b387a0b0001d62207a745c67cfd3 ] If registering the platform driver fails, the function must not return without undoing the spi driver registration first. Fixes: c296d5f9957c ("staging: fbtft: core support") Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20220118181338.207943-1-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c0ad2c2cac1b092a5f01fcfecac20ff5ed0a3a93 Author: Al Cooper Date: Wed Dec 1 13:06:53 2021 -0500 phy: broadcom: Kconfig: Fix PHY_BRCM_USB config option [ Upstream commit 5070ce86246a8a4ebacd0c15b121e6b6325bc167 ] The previous commit 4b402fa8e0b7 ("phy: phy-brcm-usb: support PHY on the BCM4908") added a second "default" line for ARCH_BCM_4908 above the original "default" line for ARCH_BRCMSTB. When two "default" lines are used, only the first is used and this change stopped the PHY_BRCM_USB option for being enabled for ARCH_BRCMSTB. The fix is to use one "default line with "||". Fixes: 4b402fa8e0b7 ("phy: phy-brcm-usb: support PHY on the BCM4908") Signed-off-by: Al Cooper Acked-by: Rafał Miłecki Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/20211201180653.35097-4-alcooperx@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 86cdc3060d41343cd3e863d731388e04cb5630de Author: Martin Blumenstingl Date: Mon Dec 27 19:00:26 2021 +0100 ARM: dts: meson8b: Fix the UART device-tree schema validation [ Upstream commit 3375aa77135f6aeb1107ed839a2050a4118444bc ] The dt-bindings for the UART controller only allow the following values for Meson8 SoCs: - "amlogic,meson8b-uart", "amlogic,meson-ao-uart" - "amlogic,meson8b-uart" Use the correct fallback compatible string "amlogic,meson-ao-uart" for AO UART. Drop the "amlogic,meson-uart" compatible string from the EE domain UART controllers. Also update the order of the clocks to match the order defined in the yaml bindings. Fixes: b02d6e73f5fc96 ("ARM: dts: meson8b: use stable UART bindings with correct gate clock") Signed-off-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20211227180026.4068352-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 5253b083f0a8c357b5d5bfc79b9ff8891623332d Author: Martin Blumenstingl Date: Mon Dec 27 19:00:25 2021 +0100 ARM: dts: meson8: Fix the UART device-tree schema validation [ Upstream commit 57007bfb5469ba31cacf69d52195e8b75f43e32d ] The dt-bindings for the UART controller only allow the following values for Meson8 SoCs: - "amlogic,meson8-uart", "amlogic,meson-ao-uart" - "amlogic,meson8-uart" Use the correct fallback compatible string "amlogic,meson-ao-uart" for AO UART. Drop the "amlogic,meson-uart" compatible string from the EE domain UART controllers. Also update the order of the clocks to match the order defined in the yaml schema. Fixes: 6ca77502050eff ("ARM: dts: meson8: use stable UART bindings with correct gate clock") Signed-off-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20211227180026.4068352-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 00d135070efa7c1df1aec1d864a13cb0e20ec279 Author: Martin Blumenstingl Date: Mon Dec 27 19:00:24 2021 +0100 ARM: dts: meson: Fix the UART compatible strings [ Upstream commit 5225e1b87432dcf0d0fc3440824b91d04c1d6cc1 ] The dt-bindings for the UART controller only allow the following values for Meson6 SoCs: - "amlogic,meson6-uart", "amlogic,meson-ao-uart" - "amlogic,meson6-uart" Use the correct fallback compatible string "amlogic,meson-ao-uart" for AO UART. Drop the "amlogic,meson-uart" compatible string from the EE domain UART controllers. Fixes: ec9b59162fd831 ("ARM: dts: meson6: use stable UART bindings") Signed-off-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20211227180026.4068352-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit c22bddf61db0914936c52d28fc1bb329fef6b71b Author: Tony Lindgren Date: Thu Nov 25 16:48:34 2021 +0200 ARM: dts: Fix timer regression for beagleboard revision c [ Upstream commit 23885389dbbbbc698986e77a45c1fc44a6e3632e ] Commit e428e250fde6 ("ARM: dts: Configure system timers for omap3") caused a timer regression for beagleboard revision c where the system clockevent stops working if omap3isp module is unloaded. Turns out we still have beagleboard revisions a-b4 capacitor c70 quirks applied that limit the usable timers for no good reason. This also affects the power management as we use the system clock instead of the 32k clock source. Let's fix the issue by adding a new omap3-beagle-ab4.dts for the old timer quirks. This allows us to remove the timer quirks for later beagleboard revisions. We also need to update the related timer quirk check for the correct compatible property. Fixes: e428e250fde6 ("ARM: dts: Configure system timers for omap3") Cc: linux-kernel@vger.kernel.org Cc: Daniel Lezcano Cc: Thomas Gleixner Cc: Rob Herring Reported-by: Jarkko Nikula Tested-by: Jarkko Nikula Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit ac14a51c31693e11947f9b4e36c84558368fe089 Author: Ville Syrjälä Date: Fri Feb 4 16:18:17 2022 +0200 drm/i915: Populate pipe dbuf slices more accurately during readout commit 85bb289215cf37e05e9581b39b114db1293f9ecd upstream. During readout we cannot assume the planes are actually using the slices they are supposed to use. The BIOS may have misprogrammed things and put the planes onto the wrong dbuf slices. So let's do the readout more carefully to make sure we really know which dbuf slices are actually in use by the pipe at the time. Cc: # v5.14+ Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy (cherry picked from commit b3dcc6dc0f32612d04839c2fb32e94d0ebf92c98) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 8d6a31b83cddd5c3429def795ba7ec8fdaf4541d Author: Ville Syrjälä Date: Fri Feb 4 16:18:16 2022 +0200 drm/i915: Allow !join_mbus cases for adlp+ dbuf configuration commit 8fd5a26e43859547790a7995494c952b708ab3b5 upstream. Reintroduce the !join_mbus single pipe cases for adlp+. Due to the mbus relative dbuf offsets in PLANE_BUF_CFG we need to know the actual slices used by the pipe when doing readout, even when mbus joining isn't enabled. Accurate readout will be needed to properly sanitize invalid BIOS dbuf configurations. This will also make it much easier to play around with the !join_mbus configs for testin/workaround purposes. Cc: # v5.14+ Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20220204141818.1900-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy (cherry picked from commit eef173954432fe0612acb63421a95deb41155cdc) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 05ffa30c99f7cbf914dd5f76a6246042c5239d3a Author: Brian Norris Date: Wed Jan 19 16:11:22 2022 -0800 drm/rockchip: vop: Correct RK3399 VOP register fields commit 9da1e9ab82c92d0e89fe44cad2cd7c2d18d64070 upstream. Commit 7707f7227f09 ("drm/rockchip: Add support for afbc") switched up the rk3399_vop_big[] register windows, but it did so incorrectly. The biggest problem is in rk3288_win23_data[] vs. rk3368_win23_data[] .format field: RK3288's format: VOP_REG(RK3288_WIN2_CTRL0, 0x7, 1) RK3368's format: VOP_REG(RK3368_WIN2_CTRL0, 0x3, 5) Bits 5:6 (i.e., shift 5, mask 0x3) are correct for RK3399, according to the TRM. There are a few other small differences between the 3288 and 3368 definitions that were swapped in commit 7707f7227f09. I reviewed them to the best of my ability according to the RK3399 TRM and fixed them up. This fixes IOMMU issues (and display errors) when testing with BG24 color formats. Fixes: 7707f7227f09 ("drm/rockchip: Add support for afbc") Cc: Andrzej Pietrasiewicz Cc: Signed-off-by: Brian Norris Tested-by: Andrzej Pietrasiewicz Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20220119161104.1.I1d01436bef35165a8cdfe9308789c0badb5ff46a@changeid Signed-off-by: Greg Kroah-Hartman commit c1af59449d80a4f642dbe64fd8be7c1ce86fc2cf Author: Alex Deucher Date: Thu Feb 3 10:04:58 2022 -0500 drm/amdgpu/display: change pipe policy for DCN 2.0 commit 6e7545ddb13416fd200e0b91c0acfd0404e2e27b upstream. Fixes hangs on driver load with multiple displays on DCN 2.0 parts. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=215511 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1877 Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1886 Fixes: ee2698cf79cc ("drm/amd/display: Changed pipe split policy to allow for multi-display pipe split") Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0e546bb1324eb7805b96642be16fc34edce41fbd Author: Rafael J. Wysocki Date: Fri Feb 4 18:35:22 2022 +0100 PM: s2idle: ACPI: Fix wakeup interrupts handling commit cb1f65c1e1424a4b5e4a86da8aa3b8fd8459c8ec upstream. After commit e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") wakeup interrupts occurring immediately after the one discarded by acpi_s2idle_wake() may be missed. Moreover, if the SCI triggers again immediately after the rearming in acpi_s2idle_wake(), that wakeup may be missed too. The problem is that pm_system_irq_wakeup() only calls pm_system_wakeup() when pm_wakeup_irq is 0, but that's not the case any more after the interrupt causing acpi_s2idle_wake() to run until pm_wakeup_irq is cleared by the pm_wakeup_clear() call in s2idle_loop(). However, there may be wakeup interrupts occurring in that time frame and if that happens, they will be missed. To address that issue first move the clearing of pm_wakeup_irq to the point at which it is known that the interrupt causing acpi_s2idle_wake() to tun will be discarded, before rearming the SCI for wakeup. Moreover, because that only reduces the size of the time window in which the issue may manifest itself, allow pm_system_irq_wakeup() to register two second wakeup interrupts in a row and, when discarding the first one, replace it with the second one. [Of course, this assumes that only one wakeup interrupt can be discarded in one go, but currently that is the case and I am not aware of any plans to change that.] Fixes: e3728b50cd9b ("ACPI: PM: s2idle: Avoid possible race related to the EC GPE") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 65aabd296665f853d9d2805a0c479f99c27a2448 Author: Robin Murphy Date: Thu Feb 3 19:31:24 2022 +0000 ACPI/IORT: Check node revision for PMCG resources commit da5fb9e1ad3fbf632dce735f1bdad257ca528499 upstream. The original version of the IORT PMCG definition had an oversight wherein there was no way to describe the second register page for an implementation using the recommended RELOC_CTRS feature. Although the spec was fixed, and the final patches merged to ACPICA and Linux written against the new version, it seems that some old firmware based on the original revision has survived and turned up in the wild. Add a check for the original PMCG definition, and avoid filling in the second memory resource with nonsense if so. Otherwise it is likely that something horrible will happen when the PMCG driver attempts to probe. Reported-by: Michael Petlan Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG") Cc: # 5.2.x Signed-off-by: Robin Murphy Acked-by: Lorenzo Pieralisi Link: https://lore.kernel.org/r/75628ae41c257fb73588f7bf1c4459160e04be2b.1643916258.git.robin.murphy@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 64c37c05f7ad71f13faae1a45800ac4ebfb579cf Author: Sagi Grimberg Date: Mon Feb 7 00:40:13 2022 +0200 nvme-tcp: fix bogus request completion when failing to send AER commit 63573807b27e0faf8065a28b1bbe1cbfb23c0130 upstream. AER is not backed by a real request, hence we should not incorrectly assume that when failing to send a nvme command, it is a normal request but rather check if this is an aer and if so complete the aer (similar to the normal completion path). Cc: stable@vger.kernel.org Signed-off-by: Sagi Grimberg Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 7740eb27c38ee801a3f52eaa1e61888a7bca965d Author: Krzysztof Kozlowski Date: Mon Feb 7 09:44:04 2022 +0100 ARM: socfpga: fix missing RESET_CONTROLLER commit 3037b174b1876aae6b2d1a27a878c681c78ccadc upstream. The SocFPGA machine since commit b3ca9888f35f ("reset: socfpga: add an early reset driver for SoCFPGA") uses reset controller, so it should select RESET_CONTROLLER explicitly. Selecting ARCH_HAS_RESET_CONTROLLER is not enough because it affects only default choice still allowing a non-buildable configuration: /usr/bin/arm-linux-gnueabi-ld: arch/arm/mach-socfpga/socfpga.o: in function `socfpga_init_irq': arch/arm/mach-socfpga/socfpga.c:56: undefined reference to `socfpga_reset_init' Reported-by: kernel test robot Cc: Fixes: b3ca9888f35f ("reset: socfpga: add an early reset driver for SoCFPGA") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Dinh Nguyen Signed-off-by: Greg Kroah-Hartman commit ccdd7956cd28b577484e387ed7ab0671b262c17e Author: Linus Walleij Date: Sun Feb 6 00:53:12 2022 +0100 ARM: dts: Fix boot regression on Skomer commit d9058d6a0e92d8e4a00855f8fe204792f42794db upstream. The signal routing on the Skomer board was incorrect making it impossible to mount root from the SD card. Fix this up. Signed-off-by: Linus Walleij Cc: stable@vger.kernel.org Cc: Stefan Hansson Link: https://lore.kernel.org/r/20220205235312.446730-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit 14917a884f70c48b82b497308180e4e426531c58 Author: Fabio Estevam Date: Mon Dec 27 13:14:02 2021 -0300 ARM: dts: imx23-evk: Remove MX23_PAD_SSP1_DETECT from hog group commit 42c9b28e6862d16db82a56f5667cf4d1f6658cf6 upstream. Currently, SD card fails to mount due to the following pinctrl error: [ 11.170000] imx23-pinctrl 80018000.pinctrl: pin SSP1_DETECT already requested by 80018000.pinctrl; cannot claim for 80010000.spi [ 11.180000] imx23-pinctrl 80018000.pinctrl: pin-65 (80010000.spi) status -22 [ 11.190000] imx23-pinctrl 80018000.pinctrl: could not request pin 65 (SSP1_DETECT) from group mmc0-pins-fixup.0 on device 80018000.pinctrl [ 11.200000] mxs-mmc 80010000.spi: Error applying setting, reverse things back Fix it by removing the MX23_PAD_SSP1_DETECT pin from the hog group as it is already been used by the mmc0-pins-fixup pinctrl group. With this change the rootfs can be mounted and the imx23-evk board can boot successfully. Cc: Fixes: bc3875f1a61e ("ARM: dts: mxs: modify mx23/mx28 dts files to use pinctrl headers") Signed-off-by: Fabio Estevam Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 4134396f99d25fa0b718cf9be1c9957fcf15ceb6 Author: Bob Peterson Date: Tue Jan 18 09:30:18 2022 -0500 gfs2: Fix gfs2_release for non-writers regression commit d3add1a9519dcacd6e644ecac741c56cf18b67f5 upstream. When a file is opened for writing, the vfs code (do_dentry_open) calls get_write_access for the inode, thus incrementing the inode's write count. That writer normally then creates a multi-block reservation for the inode (i_res) that can be re-used by other writers, which speeds up writes for applications that stupidly loop on open/write/close. When the writes are all done, the multi-block reservation should be deleted when the file is closed by the last "writer." Commit 0ec9b9ea4f83 broke that concept when it moved the call to gfs2_rs_delete before the check for FMODE_WRITE. Non-writers have no business removing the multi-block reservations of writers. In fact, if someone opens and closes the file for RO while a writer has a multi-block reservation, the RO closer will delete the reservation midway through the write, and this results in: kernel BUG at fs/gfs2/rgrp.c:677! (or thereabouts) which is: BUG_ON(rs->rs_requested); from function gfs2_rs_deltree. This patch moves the check back inside the check for FMODE_WRITE. Fixes: 0ec9b9ea4f83 ("gfs2: Check for active reservation in gfs2_release") Cc: stable@vger.kernel.org # v5.12+ Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 71f46f3d1bf29ee5b0a53dc21462125f754491dd Author: Changbin Du Date: Mon Jan 17 23:44:33 2022 +0800 riscv: eliminate unreliable __builtin_frame_address(1) commit 6a00ef4493706a23120057fafbc62379bcde11ec upstream. I tried different pieces of code which uses __builtin_frame_address(1) (with both gcc version 7.5.0 and 10.3.0) to verify whether it works as expected on riscv64. The result is negative. What the compiler had generated is as below: 31 fp = (unsigned long)__builtin_frame_address(1); 0xffffffff80006024 <+200>: ld s1,0(s0) It takes '0(s0)' as the address of frame 1 (caller), but the actual address should be '-16(s0)'. | ... | <-+ +-----------------+ | | return address | | | previous fp | | | saved registers | | | local variables | | $fp --> | ... | | +-----------------+ | | return address | | | previous fp --------+ | saved registers | $sp --> | local variables | +-----------------+ This leads the kernel can not dump the full stack trace on riscv. [ 7.222126][ T1] Call Trace: [ 7.222804][ T1] [] dump_backtrace+0x2c/0x3a This problem is not exposed on most riscv builds just because the '0(s0)' occasionally is the address frame 2 (caller's caller), if only ra and fp are stored in frame 1 (caller). | ... | <-+ +-----------------+ | | return address | | $fp --> | previous fp | | +-----------------+ | | return address | | | previous fp --------+ | saved registers | $sp --> | local variables | +-----------------+ This could be a *bug* of gcc that should be fixed. But as noted in gcc manual "Calling this function with a nonzero argument can have unpredictable effects, including crashing the calling program.", let's remove the '__builtin_frame_address(1)' in backtrace code. With this fix now it can show full stack trace: [ 10.444838][ T1] Call Trace: [ 10.446199][ T1] [] dump_backtrace+0x2c/0x3a [ 10.447711][ T1] [] show_stack+0x32/0x3e [ 10.448710][ T1] [] dump_stack_lvl+0x58/0x7a [ 10.449941][ T1] [] dump_stack+0x14/0x1c [ 10.450929][ T1] [] ubsan_epilogue+0x10/0x5a [ 10.451869][ T1] [] __ubsan_handle_load_invalid_value+0x6c/0x78 [ 10.453049][ T1] [] __pagevec_release+0x62/0x64 [ 10.455476][ T1] [] truncate_inode_pages_range+0x132/0x5be [ 10.456798][ T1] [] truncate_inode_pages+0x24/0x30 [ 10.457853][ T1] [] kill_bdev+0x32/0x3c ... Signed-off-by: Changbin Du Fixes: eac2f3059e02 ("riscv: stacktrace: fix the riscv stacktrace when CONFIG_FRAME_POINTER enabled") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit efe220337181dabf0b6b852cb7f6d01c5313468e Author: Pingfan Liu Date: Sun Jan 23 20:13:52 2022 +0800 riscv: cpu-hotplug: clear cpu from numa map when teardown commit f40fe31c01445f31253b15bef2412b33ae31093b upstream. There is numa_add_cpu() when cpus online, accordingly, there should be numa_remove_cpu() when cpus offline. Signed-off-by: Pingfan Liu Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform") Cc: stable@vger.kernel.org [Palmer: Add missing NUMA include] Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 7486227fa47aa84b102be18fd9985f6e8e11e756 Author: Aurelien Jarno Date: Wed Jan 26 18:14:42 2022 +0100 riscv: fix build with binutils 2.38 commit 6df2a016c0c8a3d0933ef33dd192ea6606b115e3 upstream. From version 2.38, binutils default to ISA spec version 20191213. This means that the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the `I` extension, become two standalone extensions: Zicsr and Zifencei. As the kernel uses those instruction, this causes the following build failure: CC arch/riscv/kernel/vdso/vgettimeofday.o <>/arch/riscv/include/asm/vdso/gettimeofday.h: Assembler messages: <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' <>/arch/riscv/include/asm/vdso/gettimeofday.h:71: Error: unrecognized opcode `csrr a5,0xc01' The fix is to specify those extensions explicitely in -march. However as older binutils version do not support this, we first need to detect that. Signed-off-by: Aurelien Jarno Tested-by: Alexandre Ghiti Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 67398d2c7b8cd59583625b4f6d0c3a5163c25e8e Author: Jim Mattson Date: Thu Feb 3 16:13:48 2022 -0800 KVM: x86: Report deprecated x87 features in supported CPUID [ Upstream commit e3bcfda012edd3564e12551b212afbd2521a1f68 ] CPUID.(EAX=7,ECX=0):EBX.FDP_EXCPTN_ONLY[bit 6] and CPUID.(EAX=7,ECX=0):EBX.ZERO_FCS_FDS[bit 13] are "defeature" bits. Unlike most of the other CPUID feature bits, these bits are clear if the features are present and set if the features are not present. These bits should be reported in KVM_GET_SUPPORTED_CPUID, because if these bits are set on hardware, they cannot be cleared in the guest CPUID. Doing so would claim guest support for a feature that the hardware doesn't support and that can't be efficiently emulated. Of course, any software (e.g WIN87EM.DLL) expecting these features to be present likely predates these CPUID feature bits and therefore doesn't know to check for them anyway. Aaron Lewis added the corresponding X86_FEATURE macros in commit cbb99c0f5887 ("x86/cpufeatures: Add FDP_EXCPTN_ONLY and ZERO_FCS_FDS"), with the intention of reporting these bits in KVM_GET_SUPPORTED_CPUID, but I was unable to find a proposed patch on the kvm list. Opportunistically reordered the CPUID_7_0_EBX capability bits from least to most significant. Cc: Aaron Lewis Signed-off-by: Jim Mattson Message-Id: <20220204001348.2844660-1-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit c09a83ae3b2eb3fbcc36a1bc0a5ae9339df8afea Author: Sean Christopherson Date: Thu Jan 20 00:06:24 2022 +0000 KVM: VMX: Set vmcs.PENDING_DBG.BS on #DB in STI/MOVSS blocking shadow [ Upstream commit b9bed78e2fa9571b7c983b20666efa0009030c71 ] Set vmcs.GUEST_PENDING_DBG_EXCEPTIONS.BS, a.k.a. the pending single-step breakpoint flag, when re-injecting a #DB with RFLAGS.TF=1, and STI or MOVSS blocking is active. Setting the flag is necessary to make VM-Entry consistency checks happy, as VMX has an invariant that if RFLAGS.TF is set and STI/MOVSS blocking is true, then the previous instruction must have been STI or MOV/POP, and therefore a single-step #DB must be pending since the RFLAGS.TF cannot have been set by the previous instruction, i.e. the one instruction delay after setting RFLAGS.TF must have already expired. Normally, the CPU sets vmcs.GUEST_PENDING_DBG_EXCEPTIONS.BS appropriately when recording guest state as part of a VM-Exit, but #DB VM-Exits intentionally do not treat the #DB as "guest state" as interception of the #DB effectively makes the #DB host-owned, thus KVM needs to manually set PENDING_DBG.BS when forwarding/re-injecting the #DB to the guest. Note, although this bug can be triggered by guest userspace, doing so requires IOPL=3, and guest userspace running with IOPL=3 has full access to all I/O ports (from the guest's perspective) and can crash/reboot the guest any number of ways. IOPL=3 is required because STI blocking kicks in if and only if RFLAGS.IF is toggled 0=>1, and if CPL>IOPL, STI either takes a #GP or modifies RFLAGS.VIF, not RFLAGS.IF. MOVSS blocking can be initiated by userspace, but can be coincident with a #DB if and only if DR7.GD=1 (General Detect enabled) and a MOV DR is executed in the MOVSS shadow. MOV DR #GPs at CPL>0, thus MOVSS blocking is problematic only for CPL0 (and only if the guest is crazy enough to access a DR in a MOVSS shadow). All other sources of #DBs are either suppressed by MOVSS blocking (single-step, code fetch, data, and I/O), are mutually exclusive with MOVSS blocking (T-bit task switch), or are already handled by KVM (ICEBP, a.k.a. INT1). This bug was originally found by running tests[1] created for XSA-308[2]. Note that Xen's userspace test emits ICEBP in the MOVSS shadow, which is presumably why the Xen bug was deemed to be an exploitable DOS from guest userspace. KVM already handles ICEBP by skipping the ICEBP instruction and thus clears MOVSS blocking as a side effect of its "emulation". [1] http://xenbits.xenproject.org/docs/xtf/xsa-308_2main_8c_source.html [2] https://xenbits.xen.org/xsa/advisory-308.html Reported-by: David Woodhouse Reported-by: Alexander Graf Signed-off-by: Sean Christopherson Message-Id: <20220120000624.655815-1-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f7da3276e087461effafb6d701a1583dfae9a83e Author: Sean Christopherson Date: Thu Jan 20 01:07:19 2022 +0000 KVM: SVM: Don't kill SEV guest if SMAP erratum triggers in usermode [ Upstream commit cdf85e0c5dc766fc7fc779466280e454a6d04f87 ] Inject a #GP instead of synthesizing triple fault to try to avoid killing the guest if emulation of an SEV guest fails due to encountering the SMAP erratum. The injected #GP may still be fatal to the guest, e.g. if the userspace process is providing critical functionality, but KVM should make every attempt to keep the guest alive. Signed-off-by: Sean Christopherson Reviewed-by: Liam Merwick Message-Id: <20220120010719.711476-10-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 11f9427d01a3b0f2e03c28f1413374eab7dd5a7b Author: Vitaly Kuznetsov Date: Wed Jan 12 18:01:30 2022 +0100 KVM: nVMX: Also filter MSR_IA32_VMX_TRUE_PINBASED_CTLS when eVMCS [ Upstream commit f80ae0ef089a09e8c18da43a382c3caac9a424a7 ] Similar to MSR_IA32_VMX_EXIT_CTLS/MSR_IA32_VMX_TRUE_EXIT_CTLS, MSR_IA32_VMX_ENTRY_CTLS/MSR_IA32_VMX_TRUE_ENTRY_CTLS pair, MSR_IA32_VMX_TRUE_PINBASED_CTLS needs to be filtered the same way MSR_IA32_VMX_PINBASED_CTLS is currently filtered as guests may solely rely on 'true' MSR data. Note, none of the currently existing Windows/Hyper-V versions are known to stumble upon the unfiltered MSR_IA32_VMX_TRUE_PINBASED_CTLS, the change is aimed at making the filtering future proof. Signed-off-by: Vitaly Kuznetsov Message-Id: <20220112170134.1904308-2-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a3c43649600bdbe075597247c4b5017c3d3563b7 Author: Vitaly Kuznetsov Date: Wed Jan 12 18:01:31 2022 +0100 KVM: nVMX: eVMCS: Filter out VM_EXIT_SAVE_VMX_PREEMPTION_TIMER [ Upstream commit 7a601e2cf61558dfd534a9ecaad09f5853ad8204 ] Enlightened VMCS v1 doesn't have VMX_PREEMPTION_TIMER_VALUE field, PIN_BASED_VMX_PREEMPTION_TIMER is also filtered out already so it makes sense to filter out VM_EXIT_SAVE_VMX_PREEMPTION_TIMER too. Note, none of the currently existing Windows/Hyper-V versions are known to enable 'save VMX-preemption timer value' when eVMCS is in use, the change is aimed at making the filtering future proof. Signed-off-by: Vitaly Kuznetsov Message-Id: <20220112170134.1904308-3-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit d44af3ad2a2148582839b556d0ff5b5e3787dfc0 Author: Hou Wenlong Date: Thu Jan 27 14:54:49 2022 +0800 KVM: eventfd: Fix false positive RCU usage warning [ Upstream commit 6a0c61703e3a5d67845a4b275e1d9d7bc1b5aad7 ] Fix the following false positive warning: ============================= WARNING: suspicious RCU usage 5.16.0-rc4+ #57 Not tainted ----------------------------- arch/x86/kvm/../../../virt/kvm/eventfd.c:484 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by fc_vcpu 0/330: #0: ffff8884835fc0b0 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0x88/0x6f0 [kvm] #1: ffffc90004c0bb68 (&kvm->srcu){....}-{0:0}, at: vcpu_enter_guest+0x600/0x1860 [kvm] #2: ffffc90004c0c1d0 (&kvm->irq_srcu){....}-{0:0}, at: kvm_notify_acked_irq+0x36/0x180 [kvm] stack backtrace: CPU: 26 PID: 330 Comm: fc_vcpu 0 Not tainted 5.16.0-rc4+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x44/0x57 kvm_notify_acked_gsi+0x6b/0x70 [kvm] kvm_notify_acked_irq+0x8d/0x180 [kvm] kvm_ioapic_update_eoi+0x92/0x240 [kvm] kvm_apic_set_eoi_accelerated+0x2a/0xe0 [kvm] handle_apic_eoi_induced+0x3d/0x60 [kvm_intel] vmx_handle_exit+0x19c/0x6a0 [kvm_intel] vcpu_enter_guest+0x66e/0x1860 [kvm] kvm_arch_vcpu_ioctl_run+0x438/0x7f0 [kvm] kvm_vcpu_ioctl+0x38a/0x6f0 [kvm] __x64_sys_ioctl+0x89/0xc0 do_syscall_64+0x3a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Since kvm_unregister_irq_ack_notifier() does synchronize_srcu(&kvm->irq_srcu), kvm->irq_ack_notifier_list is protected by kvm->irq_srcu. In fact, kvm->irq_srcu SRCU read lock is held in kvm_notify_acked_irq(), making it a false positive warning. So use hlist_for_each_entry_srcu() instead of hlist_for_each_entry_rcu(). Reviewed-by: Sean Christopherson Signed-off-by: Hou Wenlong Message-Id: Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit a85f3ea1407f39f209bf030e3feef389db172da1 Author: Jisheng Zhang Date: Thu Jan 27 00:52:15 2022 +0800 net: stmmac: dwmac-sun8i: use return val of readl_poll_timeout() [ Upstream commit 9e0db41e7a0b6f1271cbcfb16dbf5b8641b4e440 ] When readl_poll_timeout() timeout, we'd better directly use its return value. Before this patch: [ 2.145528] dwmac-sun8i: probe of 4500000.ethernet failed with error -14 After this patch: [ 2.138520] dwmac-sun8i: probe of 4500000.ethernet failed with error -110 Signed-off-by: Jisheng Zhang Acked-by: Jernej Skrabec Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a3ba49c129ed293ba6291f91aa6ffd796a8b12c1 Author: Thomas Bogendoerfer Date: Tue Jan 25 15:19:44 2022 +0100 MIPS: Fix build error due to PTR used in more places [ Upstream commit fa62f39dc7e25fc16371b958ac59b9a6fd260bea ] Use PTR_WD instead of PTR to avoid clashes with other parts. Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 96f91a877a5c73a28502009b36dc08d265bb2f1f Author: Wu Zheng Date: Mon Jun 21 19:07:01 2021 -0400 nvme-pci: add the IGNORE_DEV_SUBNQN quirk for Intel P4500/P4600 SSDs [ Upstream commit 25e58af4be412d59e056da65cc1cefbd89185bd2 ] The Intel P4500/P4600 SSDs do not report a subsystem NQN despite claiming compliance to a standards version where reporting one is required. Add the IGNORE_DEV_SUBNQN quirk to not fail the initialization of a second such SSDs in a system. Signed-off-by: Zheng Wu Signed-off-by: Ye Jinhe Reviewed-by: Keith Busch Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a3486ef99a3bd198ef8fca4ff7bc68e97ddea9d9 Author: James Clark Date: Mon Dec 6 11:38:40 2021 +0000 perf: Always wake the parent event [ Upstream commit 961c39121759ad09a89598ec4ccdd34ae0468a19 ] When using per-process mode and event inheritance is set to true, forked processes will create a new perf events via inherit_event() -> perf_event_alloc(). But these events will not have ring buffers assigned to them. Any call to wakeup will be dropped if it's called on an event with no ring buffer assigned because that's the object that holds the wakeup list. If the child event is disabled due to a call to perf_aux_output_begin() or perf_aux_output_end(), the wakeup is dropped leaving userspace hanging forever on the poll. Normally the event is explicitly re-enabled by userspace after it wakes up to read the aux data, but in this case it does not get woken up so the event remains disabled. This can be reproduced when using Arm SPE and 'stress' which forks once before running the workload. By looking at the list of aux buffers read, it's apparent that they stop after the fork: perf record -e arm_spe// -vvv -- stress -c 1 With this patch applied they continue to be printed. This behaviour doesn't happen when using systemwide or per-cpu mode. Reported-by: Ruben Ayrapetyan Signed-off-by: James Clark Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211206113840.130802-2-james.clark@arm.com Signed-off-by: Sasha Levin commit 8981a8fd900e124a04819e6415c1de9473ec284d Author: Amelie Delaunay Date: Tue Dec 7 14:01:01 2021 +0100 usb: dwc2: gadget: don't try to disable ep0 in dwc2_hsotg_suspend [ Upstream commit ac55d163855924aa5af9f1560977da8f346963c8 ] Calling dwc2_hsotg_ep_disable on ep0 (in/out) will lead to the following logs before returning -EINVAL: dwc2 49000000.usb-otg: dwc2_hsotg_ep_disable: called for ep0 dwc2 49000000.usb-otg: dwc2_hsotg_ep_disable: called for ep0 To avoid these two logs while suspending, start disabling the endpoint from the index 1, as done in dwc2_hsotg_udc_stop: /* all endpoints should be shutdown */ for (ep = 1; ep < hsotg->num_of_eps; ep++) { if (hsotg->eps_in[ep]) dwc2_hsotg_ep_disable_lock(&hsotg->eps_in[ep]->ep); if (hsotg->eps_out[ep]) dwc2_hsotg_ep_disable_lock(&hsotg->eps_out[ep]->ep); } Acked-by: Minas Harutyunyan Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211207130101.270314-1-amelie.delaunay@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a277422a8d975966de1bd3351cc6cfd8718a166d Author: Zhan Liu Date: Wed Jan 19 16:55:16 2022 -0500 drm/amd/display: Correct MPC split policy for DCN301 [ Upstream commit ac46d93235074a6c5d280d35771c23fd8620e7d9 ] [Why] DCN301 has seamless boot enabled. With MPC split enabled at the same time, system will hang. [How] Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have ODM combine enabled on DCN301, pipe split is not necessary here. Signed-off-by: Zhan Liu Reviewed-by: Charlene Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit dc5769c7b063ac844a7001584fd50da03619c464 Author: Amadeusz Sławiński Date: Wed Jan 19 11:47:51 2022 +0100 PM: hibernate: Remove register_nosave_region_late() [ Upstream commit 33569ef3c754a82010f266b7b938a66a3ccf90a4 ] It is an unused wrapper forcing kmalloc allocation for registering nosave regions. Also, rename __register_nosave_region() to register_nosave_region() now that there is no need for disambiguation. Signed-off-by: Amadeusz Sławiński Reviewed-by: Cezary Rojewski Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 50fe79589c149979c6223c0ff1a646b5102fefa8 Author: Jisheng Zhang Date: Sun Jan 23 23:54:58 2022 +0800 net: stmmac: reduce unnecessary wakeups from eee sw timer [ Upstream commit c74ead223deb88bdf18af8c772d7ca5a9b6c3c2b ] Currently, on EEE capable platforms, if EEE SW timer is used, the SW timer cause 1 wakeup/s even if the TX has successfully entered EEE. Remove this unnecessary wakeup by only calling mod_timer() if we haven't successfully entered EEE. Signed-off-by: Jisheng Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6207f35c213f6cb2fc3f13b5e77f08c710e1de19 Author: Tong Zhang Date: Sun Jan 23 14:57:17 2022 -0800 scsi: myrs: Fix crash in error case [ Upstream commit 4db09593af0b0b4d7d4805ebb3273df51d7cc30d ] In myrs_detect(), cs->disable_intr is NULL when privdata->hw_init() fails with non-zero. In this case, myrs_cleanup(cs) will call a NULL ptr and crash the kernel. [ 1.105606] myrs 0000:00:03.0: Unknown Initialization Error 5A [ 1.105872] myrs 0000:00:03.0: Failed to initialize Controller [ 1.106082] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 1.110774] Call Trace: [ 1.110950] myrs_cleanup+0xe4/0x150 [myrs] [ 1.111135] myrs_probe.cold+0x91/0x56a [myrs] [ 1.111302] ? DAC960_GEM_intr_handler+0x1f0/0x1f0 [myrs] [ 1.111500] local_pci_probe+0x48/0x90 Link: https://lore.kernel.org/r/20220123225717.1069538-1-ztong0001@gmail.com Reviewed-by: Hannes Reinecke Signed-off-by: Tong Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0c8d27c2aae53aee190535db7659f37afc39d846 Author: Kiwoong Kim Date: Fri Jan 21 14:37:55 2022 +0900 scsi: ufs: Treat link loss as fatal error [ Upstream commit c99b9b2301492b665b6e51ba6c06ec362eddcd10 ] This event is raised when link is lost as specified in UFSHCI spec and that means communication is not possible. Thus initializing UFS interface needs to be done. Make UFS driver considers Link Lost as fatal in the INT_FATAL_ERRORS mask. This will trigger a host reset whenever a link lost interrupt occurs. Link: https://lore.kernel.org/r/1642743475-54275-1-git-send-email-kwmad.kim@samsung.com Signed-off-by: Kiwoong Kim Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f0a91d89231052d11e19b0f99a7b7ebdb0f6de4a Author: Kiwoong Kim Date: Fri Jan 21 14:33:02 2022 +0900 scsi: ufs: Use generic error code in ufshcd_set_dev_pwr_mode() [ Upstream commit ad6c8a426446873febc98140d81d5353f8c0825b ] The return value of ufshcd_set_dev_pwr_mode() is passed to device PM core. However, the function currently returns a SCSI result which the PM core doesn't understand. This might lead to unexpected behaviors in userland; a platform reset was observed in Android. Use a generic error code for SSU failures. Link: https://lore.kernel.org/r/1642743182-54098-1-git-send-email-kwmad.kim@samsung.com Reviewed-by: Bart Van Assche Signed-off-by: Kiwoong Kim Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cb26e94204d7abedcff123e478bb7bd97f4351b0 Author: John Garry Date: Tue Jan 18 20:15:05 2022 +0800 scsi: pm8001: Fix bogus FW crash for maxcpus=1 [ Upstream commit 62afb379a0fee7e9c2f9f68e1abeb85ceddf51b9 ] According to the comment in check_fw_ready() we should not check the IOP1_READY field in register SCRATCH_PAD_1 for 8008 or 8009 controllers. However we check this very field in process_oq() for processing the highest index interrupt vector. The highest interrupt vector is checked as the FW is programmed to signal fatal errors through this irq. Change that function to not check IOP1_READY for those mentioned controllers, but do check ILA_READY in both cases. The reason I assume that this was not hit earlier was because we always allocated 64 MSI(X), and just did not pass the vector index check in process_oq(), i.e. the handler never ran for vector index 63. Link: https://lore.kernel.org/r/1642508105-95432-1-git-send-email-john.garry@huawei.com Tested-by: Damien Le Moal Reviewed-by: Damien Le Moal Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1c22df15cf402850fc9ba435f73f57f65c117d35 Author: Saurav Kashyap Date: Mon Jan 17 05:53:11 2022 -0800 scsi: qedf: Change context reset messages to ratelimited [ Upstream commit 64fd4af6274eb0f49d29772c228fffcf6bde1635 ] If FCoE is not configured, libfc/libfcoe keeps on retrying FLOGI and after 3 retries driver does a context reset and tries fipvlan again. This leads to context reset message flooding the logs. Hence ratelimit the message to prevent flooding the logs. Link: https://lore.kernel.org/r/20220117135311.6256-4-njavali@marvell.com Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6be8eaad75ca73131e2a697f0270dc8ee73814a8 Author: Saurav Kashyap Date: Mon Jan 17 05:53:10 2022 -0800 scsi: qedf: Fix refcount issue when LOGO is received during TMF [ Upstream commit 5239ab63f17cee643bd4bf6addfedebaa7d4f41e ] Hung task call trace was seen during LOGO processing. [ 974.309060] [0000:00:00.0]:[qedf_eh_device_reset:868]: 1:0:2:0: LUN RESET Issued... [ 974.309065] [0000:00:00.0]:[qedf_initiate_tmf:2422]: tm_flags 0x10 sc_cmd 00000000c16b930f op = 0x2a target_id = 0x2 lun=0 [ 974.309178] [0000:00:00.0]:[qedf_initiate_tmf:2431]: portid=016900 tm_flags =LUN RESET [ 974.309222] [0000:00:00.0]:[qedf_initiate_tmf:2438]: orig io_req = 00000000ec78df8f xid = 0x180 ref_cnt = 1. [ 974.309625] host1: rport 016900: Received LOGO request while in state Ready [ 974.309627] host1: rport 016900: Delete port [ 974.309642] host1: rport 016900: work event 3 [ 974.309644] host1: rport 016900: lld callback ev 3 [ 974.313243] [0000:61:00.2]:[qedf_execute_tmf:2383]:1: fcport is uploading, not executing flush. [ 974.313295] [0000:61:00.2]:[qedf_execute_tmf:2400]:1: task mgmt command success... [ 984.031088] INFO: task jbd2/dm-15-8:7645 blocked for more than 120 seconds. [ 984.031136] Not tainted 4.18.0-305.el8.x86_64 #1 [ 984.031166] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 984.031209] jbd2/dm-15-8 D 0 7645 2 0x80004080 [ 984.031212] Call Trace: [ 984.031222] __schedule+0x2c4/0x700 [ 984.031230] ? unfreeze_partials.isra.83+0x16e/0x1a0 [ 984.031233] ? bit_wait_timeout+0x90/0x90 [ 984.031235] schedule+0x38/0xa0 [ 984.031238] io_schedule+0x12/0x40 [ 984.031240] bit_wait_io+0xd/0x50 [ 984.031243] __wait_on_bit+0x6c/0x80 [ 984.031248] ? free_buffer_head+0x21/0x50 [ 984.031251] out_of_line_wait_on_bit+0x91/0xb0 [ 984.031257] ? init_wait_var_entry+0x50/0x50 [ 984.031268] jbd2_journal_commit_transaction+0x112e/0x19f0 [jbd2] [ 984.031280] kjournald2+0xbd/0x270 [jbd2] [ 984.031284] ? finish_wait+0x80/0x80 [ 984.031291] ? commit_timeout+0x10/0x10 [jbd2] [ 984.031294] kthread+0x116/0x130 [ 984.031300] ? kthread_flush_work_fn+0x10/0x10 [ 984.031305] ret_from_fork+0x1f/0x40 There was a ref count issue when LOGO is received during TMF. This leads to one of the I/Os hanging with the driver. Fix the ref count. Link: https://lore.kernel.org/r/20220117135311.6256-3-njavali@marvell.com Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1f53bbf27a876f7e61262bd74c18680ac11d4c31 Author: Saurav Kashyap Date: Mon Jan 17 05:53:09 2022 -0800 scsi: qedf: Add stag_work to all the vports [ Upstream commit b70a99fd13282d7885f69bf1372e28b7506a1613 ] Call trace seen when creating NPIV ports, only 32 out of 64 show online. stag work was not initialized for vport, hence initialize the stag work. WARNING: CPU: 8 PID: 645 at kernel/workqueue.c:1635 __queue_delayed_work+0x68/0x80 CPU: 8 PID: 645 Comm: kworker/8:1 Kdump: loaded Tainted: G IOE --------- -- 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge MX740c/0177V9, BIOS 2.12.2 07/09/2021 Workqueue: events fc_lport_timeout [libfc] RIP: 0010:__queue_delayed_work+0x68/0x80 Code: 89 b2 88 00 00 00 44 89 82 90 00 00 00 48 01 c8 48 89 42 50 41 81 f8 00 20 00 00 75 1d e9 60 24 07 00 44 89 c7 e9 98 f6 ff ff <0f> 0b eb c5 0f 0b eb a1 0f 0b eb a7 0f 0b eb ac 44 89 c6 e9 40 23 RSP: 0018:ffffae514bc3be40 EFLAGS: 00010006 RAX: ffff8d25d6143750 RBX: 0000000000000202 RCX: 0000000000000002 RDX: ffff8d2e31383748 RSI: ffff8d25c000d600 RDI: ffff8d2e31383788 RBP: ffff8d2e31380de0 R08: 0000000000002000 R09: ffff8d2e31383750 R10: ffffffffc0c957e0 R11: ffff8d2624800000 R12: ffff8d2e31380a58 R13: ffff8d2d915eb000 R14: ffff8d25c499b5c0 R15: ffff8d2e31380e18 FS: 0000000000000000(0000) GS:ffff8d2d1fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055fd0484b8b8 CR3: 00000008ffc10006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: queue_delayed_work_on+0x36/0x40 qedf_elsct_send+0x57/0x60 [qedf] fc_lport_enter_flogi+0x90/0xc0 [libfc] fc_lport_timeout+0xb7/0x140 [libfc] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 008f00f722f2c2ff ]-- Initialize stag work for all the vports. Link: https://lore.kernel.org/r/20220117135311.6256-2-njavali@marvell.com Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 83f31dab46b20afdaf9840af631370d15d3e8a0e Author: Xiaoke Wang Date: Sun Jan 16 11:06:49 2022 +0800 scsi: ufs: ufshcd-pltfrm: Check the return value of devm_kstrdup() [ Upstream commit a65b32748f4566f986ba2495a8236c141fa42a26 ] devm_kstrdup() returns pointer to allocated string on success, NULL on failure. So it is better to check the return value of it. Link: https://lore.kernel.org/r/tencent_4257E15D4A94FF9020DDCC4BB9B21C041408@qq.com Reviewed-by: Bean Huo Signed-off-by: Xiaoke Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4f786e8f18c3e80a168aac3e4f9da99310b8fcdd Author: ZouMingzhe Date: Tue Jan 11 13:47:42 2022 +0800 scsi: target: iscsi: Make sure the np under each tpg is unique [ Upstream commit a861790afaa8b6369eee8a88c5d5d73f5799c0c6 ] iscsit_tpg_check_network_portal() has nested for_each loops and is supposed to return true when a match is found. However, the tpg loop will still continue after existing the tpg_np loop. If this tpg_np is not the last the match value will be changed. Break the outer loop after finding a match and make sure the np under each tpg is unique. Link: https://lore.kernel.org/r/20220111054742.19582-1-mingzhe.zou@easystack.cn Signed-off-by: ZouMingzhe Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 43ae0ccc4d2722b833fb59b905af129428e06d03 Author: Christophe Leroy Date: Mon Dec 6 11:11:51 2021 +0000 powerpc/fixmap: Fix VM debug warning on unmap [ Upstream commit aec982603aa8cc0a21143681feb5f60ecc69d718 ] Unmapping a fixmap entry is done by calling __set_fixmap() with FIXMAP_PAGE_CLEAR as flags. Today, powerpc __set_fixmap() calls map_kernel_page(). map_kernel_page() is not happy when called a second time for the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 NIP [c0017cd4] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Call Trace: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable) [e1011e30] [c0165fec] __set_fixmap+0x30/0x44 [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030 Implement unmap_kernel_page() which clears an existing pte. Reported-by: Maxime Bizon Signed-off-by: Christophe Leroy Tested-by: Maxime Bizon Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/b0b752f6f6ecc60653e873f385c6f0dce4e9ab6a.1638789098.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit fa693cfd8fe442216a73799135cc65ade943bca6 Author: Victor Nogueira Date: Tue Jan 18 14:19:09 2022 -0300 net: sched: Clarify error message when qdisc kind is unknown [ Upstream commit 973bf8fdd12f0e70ea351c018e68edd377a836d1 ] When adding a tc rule with a qdisc kind that is not supported or not compiled into the kernel, the kernel emits the following error: "Error: Specified qdisc not found.". Found via tdc testing when ETS qdisc was not compiled in and it was not obvious right away what the message meant without looking at the kernel code. Change the error message to be more explicit and say the qdisc kind is unknown. Signed-off-by: Victor Nogueira Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9696125fb3ca1660d28a0aef53bcaa1a20a02bdb Author: Raymond Jay Golo Date: Thu Jan 13 08:06:20 2022 +0800 drm: panel-orientation-quirks: Add quirk for the 1Netbook OneXPlayer [ Upstream commit d3cbc6e323c9299d10c8d2e4127c77c7d05d07b1 ] The 1Netbook OneXPlayer uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Raymond Jay Golo Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220113000619.90988-1-rjgolo@gmail.com Signed-off-by: Sasha Levin commit 770d1ba9a8201ce9bee0946eb03746449b6f3b80 Author: Padmanabha Srinivasaiah Date: Tue Jan 18 01:51:26 2022 +0100 drm/vc4: Fix deadlock on DSI device attach error [ Upstream commit 0a3d12ab5097b1d045e693412e6b366b7e82031b ] DSI device attach to DSI host will be done with host device's lock held. Un-registering host in "device attach" error path (ex: probe retry) will result in deadlock with below call trace and non operational DSI display. Startup Call trace: [ 35.043036] rt_mutex_slowlock.constprop.21+0x184/0x1b8 [ 35.043048] mutex_lock_nested+0x7c/0xc8 [ 35.043060] device_del+0x4c/0x3e8 [ 35.043075] device_unregister+0x20/0x40 [ 35.043082] mipi_dsi_remove_device_fn+0x18/0x28 [ 35.043093] device_for_each_child+0x68/0xb0 [ 35.043105] mipi_dsi_host_unregister+0x40/0x90 [ 35.043115] vc4_dsi_host_attach+0xf0/0x120 [vc4] [ 35.043199] mipi_dsi_attach+0x30/0x48 [ 35.043209] tc358762_probe+0x128/0x164 [tc358762] [ 35.043225] mipi_dsi_drv_probe+0x28/0x38 [ 35.043234] really_probe+0xc0/0x318 [ 35.043244] __driver_probe_device+0x80/0xe8 [ 35.043254] driver_probe_device+0xb8/0x118 [ 35.043263] __device_attach_driver+0x98/0xe8 [ 35.043273] bus_for_each_drv+0x84/0xd8 [ 35.043281] __device_attach+0xf0/0x150 [ 35.043290] device_initial_probe+0x1c/0x28 [ 35.043300] bus_probe_device+0xa4/0xb0 [ 35.043308] deferred_probe_work_func+0xa0/0xe0 [ 35.043318] process_one_work+0x254/0x700 [ 35.043330] worker_thread+0x4c/0x448 [ 35.043339] kthread+0x19c/0x1a8 [ 35.043348] ret_from_fork+0x10/0x20 Shutdown Call trace: [ 365.565417] Call trace: [ 365.565423] __switch_to+0x148/0x200 [ 365.565452] __schedule+0x340/0x9c8 [ 365.565467] schedule+0x48/0x110 [ 365.565479] schedule_timeout+0x3b0/0x448 [ 365.565496] wait_for_completion+0xac/0x138 [ 365.565509] __flush_work+0x218/0x4e0 [ 365.565523] flush_work+0x1c/0x28 [ 365.565536] wait_for_device_probe+0x68/0x158 [ 365.565550] device_shutdown+0x24/0x348 [ 365.565561] kernel_restart_prepare+0x40/0x50 [ 365.565578] kernel_restart+0x20/0x70 [ 365.565591] __do_sys_reboot+0x10c/0x220 [ 365.565605] __arm64_sys_reboot+0x2c/0x38 [ 365.565619] invoke_syscall+0x4c/0x110 [ 365.565634] el0_svc_common.constprop.3+0xfc/0x120 [ 365.565648] do_el0_svc+0x2c/0x90 [ 365.565661] el0_svc+0x4c/0xf0 [ 365.565671] el0t_64_sync_handler+0x90/0xb8 [ 365.565682] el0t_64_sync+0x180/0x184 Signed-off-by: Padmanabha Srinivasaiah Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20220118005127.29015-1-treasure4paddy@gmail.com Signed-off-by: Sasha Levin commit 85008bde411d5be480d3926ec3fb26b93d46001f Author: Peter Zijlstra Date: Sat Dec 25 01:04:57 2021 +0100 sched: Avoid double preemption in __cond_resched_*lock*() [ Upstream commit 7e406d1ff39b8ee574036418a5043c86723170cf ] For PREEMPT/DYNAMIC_PREEMPT the *_unlock() will already trigger a preemption, no point in then calling preempt_schedule_common() *again*. Use _cond_resched() instead, since this is a NOP for the preemptible configs while it provide a preemption point for the others. Reported-by: xuhaifeng Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/YcGnvDEYBwOiV0cR@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit ec903b6daa586dedff31c27d6b7d8d84cbd11131 Author: Andi Kleen Date: Wed Dec 15 12:40:29 2021 -0800 x86/perf: Avoid warning for Arch LBR without XSAVE [ Upstream commit 8c16dc047b5dd8f7b3bf4584fa75733ea0dde7dc ] Some hypervisors support Arch LBR, but without the LBR XSAVE support. The current Arch LBR init code prints a warning when the xsave size (0) is unexpected. Avoid printing the warning for the "no LBR XSAVE" case. Signed-off-by: Andi Kleen Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211215204029.150686-1-ak@linux.intel.com Signed-off-by: Sasha Levin commit ef5685971abde1a8f84d6cf1efaf45a216c48d5a Author: Stephane Eranian Date: Wed Jan 5 10:56:59 2022 -0800 perf/x86/rapl: fix AMD event handling [ Upstream commit 0036fb00a756a2f6e360d44e2e3d2200a8afbc9b ] The RAPL events exposed under /sys/devices/power/events should only reflect what the underlying hardware actually support. This is how it works on Intel RAPL and Intel core/uncore PMUs in general. But on AMD, this was not the case. All possible RAPL events were advertised. This is what it showed on an AMD Fam17h: $ ls /sys/devices/power/events/ energy-cores energy-gpu energy-pkg energy-psys energy-ram energy-cores.scale energy-gpu.scale energy-pkg.scale energy-psys.scale energy-ram.scale energy-cores.unit energy-gpu.unit energy-pkg.unit energy-psys.unit energy-ram.unit Yet, on AMD Fam17h, only energy-pkg is supported. This patch fixes the problem. Given the way perf_msr_probe() works, the amd_rapl_msrs[] table has to have all entries filled out and in particular the group field, otherwise perf_msr_probe() defaults to making the event visible. With the patch applied, the kernel now only shows was is actually supported: $ ls /sys/devices/power/events/ energy-pkg energy-pkg.scale energy-pkg.unit The patch also uses the RAPL_MSR_MASK because only the 32-bits LSB of the RAPL counters are relevant when reading power consumption. Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20220105185659.643355-1-eranian@google.com Signed-off-by: Sasha Levin commit 3f4e05eb46ae32082347ddcf91da0f611d320270 Author: Sander Vanheule Date: Sun Jan 9 15:54:34 2022 +0100 irqchip/realtek-rtl: Service all pending interrupts [ Upstream commit 960dd884ddf5621ae6284cd3a42724500a97ae4c ] Instead of only servicing the lowest pending interrupt line, make sure all pending SoC interrupts are serviced before exiting the chained handler. This adds a small overhead if only one interrupt is pending, but should prevent rapid re-triggering of the handler. Signed-off-by: Sander Vanheule Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/5082ad3cb8b4eedf55075561b93eff6570299fe1.1641739718.git.sander@svanheule.net Signed-off-by: Sasha Levin commit 4403233b87758d9d50fc764c16f85ab14b68439f Author: Anna Schumaker Date: Mon Nov 15 11:54:25 2021 -0500 sunrpc: Fix potential race conditions in rpc_sysfs_xprt_state_change() [ Upstream commit 1a48db3fef499f615b56093947ec4b0d3d8e3021 ] We need to use test_and_set_bit() when changing xprt state flags to avoid potentially getting xps->xps_nactive out of sync. Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 4b22aa42bd4d2d630ef1854c139275c3532937cb Author: Xiyu Yang Date: Thu Sep 9 12:32:38 2021 +0800 net/sunrpc: fix reference count leaks in rpc_sysfs_xprt_state_change [ Upstream commit 776d794f28c95051bc70405a7b1fa40115658a18 ] The refcount leak issues take place in an error handling path. When the 3rd argument buf doesn't match with "offline", "online" or "remove", the function simply returns -EINVAL and forgets to decrease the reference count of a rpc_xprt object and a rpc_xprt_switch object increased by rpc_sysfs_xprt_kobj_get_xprt() and rpc_sysfs_xprt_kobj_get_xprt_switch(), causing reference count leaks of both unused objects. Fix this issue by jumping to the error handling path labelled with out_put when buf matches none of "offline", "online" or "remove". Signed-off-by: Xiyu Yang Signed-off-by: Xin Xiong Signed-off-by: Xin Tan Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 5ca123c91a64a85230272136b756c78d632d21c5 Author: Olga Kornievskaia Date: Thu Dec 9 14:53:34 2021 -0500 SUNRPC allow for unspecified transport time in rpc_clnt_add_xprt [ Upstream commit b8a09619a56334414cbd7f935a0796240d0cc07e ] If the supplied argument doesn't specify the transport type, use the type of the existing rpc clnt and its existing transport. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit c5ae18fa8d71c79684a3c3398d037287ce453413 Author: Olga Kornievskaia Date: Thu Dec 9 14:53:33 2021 -0500 NFSv4 handle port presence in fs_location server string [ Upstream commit a8d54baba7c65db2d3278873def61f8d3753d766 ] An fs_location attribute returns a string that can be ipv4, ipv6, or DNS name. An ip location can have a port appended to it and if no port is present a default port needs to be set. If rpc_pton() fails to parse, try calling rpc_uaddr2socaddr() that can convert an universal address. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit be67be6a1a8f7a3c69fc757b237028a22368c5b9 Author: Olga Kornievskaia Date: Thu Dec 9 14:53:32 2021 -0500 NFSv4 expose nfs_parse_server_name function [ Upstream commit f5b27cc6761e27ee6387a24df1a99ca77b360fea ] Make nfs_parse_server_name available outside of nfs4namespace.c. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 6f2836341d8a39e1e000572b10959347d7e61fd9 Author: Olga Kornievskaia Date: Wed Jan 12 10:27:38 2022 -0500 NFSv4.1 query for fs_location attr on a new file system [ Upstream commit 1976b2b31462151403c9fc110204fcc2a77bdfd1 ] Query the server for other possible trunkable locations for a given file system on a 4.1+ mount. v2: -- added missing static to nfs4_discover_trunking, reported by the kernel test robot Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2df6a47a131ae73c39b5b3736543223004cd807e Author: Olga Kornievskaia Date: Thu Dec 9 14:53:30 2021 -0500 NFSv4 store server support for fs_location attribute [ Upstream commit 8a59bb93b7e3cca389af44781a429ac12ac49be6 ] Define and store if server returns it supports fs_locations attribute as a capability. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 0c5d3bfb296785d21feabc7cc972a5f704f6f3e6 Author: Olga Kornievskaia Date: Thu Dec 9 14:53:29 2021 -0500 NFSv4 remove zero number of fs_locations entries error check [ Upstream commit 90e12a3191040bd3854d3e236c35921e4e92a044 ] Remove the check for the zero length fs_locations reply in the xdr decoding, and instead check for that in the migration code. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 3cb5b317901e769e4d465e1db2ddff0e1230563c Author: Trond Myklebust Date: Mon Jan 3 14:50:16 2022 -0500 NFSv4.1: Fix uninitialised variable in devicenotify [ Upstream commit b05bf5c63b326ce1da84ef42498d8e0e292e694c ] When decode_devicenotify_args() exits with no entries, we need to ensure that the struct cb_devicenotifyargs is initialised to { 0, NULL } in order to avoid problems in nfs4_callback_devicenotify(). Reported-by: Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 58967a232ab3bba3386177e1029ad9794aa514d2 Author: Xiaoke Wang Date: Fri Dec 17 01:01:33 2021 +0800 nfs: nfs4clinet: check the return value of kstrdup() [ Upstream commit fbd2057e5329d3502a27491190237b6be52a1cb6 ] kstrdup() returns NULL when some internal memory errors happen, it is better to check the return value of it so to catch the memory error in time. Signed-off-by: Xiaoke Wang Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit bbf647ecebc0bfbcf2e182391e54c80ddff5a067 Author: Olga Kornievskaia Date: Mon Nov 29 15:33:56 2021 -0500 NFSv4 only print the label when its queried [ Upstream commit 2c52c8376db7160a1dd8a681c61c9258405ef143 ] When the bitmask of the attributes doesn't include the security label, don't bother printing it. Since the label might not be null terminated, adjust the printing format accordingly. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 38ae938701e7b224d6f68338d3f0ea14821cbd28 Author: NeilBrown Date: Tue Sep 28 09:47:57 2021 +1000 NFS: change nfs_access_get_cached to only report the mask [ Upstream commit b5e7b59c3480f355910f9d2c6ece5857922a5e54 ] Currently the nfs_access_get_cached family of functions report a 'struct nfs_access_entry' as the result, with both .mask and .cred set. However the .cred is never used. This is probably good and there is no guarantee that it won't be freed before use. Change to only report the 'mask' - as this is all that is used or needed. Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 78c28fdf1685e5884963018fd3692b0ff6820805 Author: Tom Zanussi Date: Thu Jan 27 15:44:17 2022 -0600 tracing: Propagate is_signed to expression commit 097f1eefedeab528cecbd35586dfe293853ffb17 upstream. During expression parsing, a new expression field is created which should inherit the properties of the operands, such as size and is_signed. is_signed propagation was missing, causing spurious errors with signed operands. Add it in parse_expr() and parse_unary() to fix the problem. Link: https://lkml.kernel.org/r/f4dac08742fd7a0920bf80a73c6c44042f5eaa40.1643319703.git.zanussi@kernel.org Cc: stable@vger.kernel.org Fixes: 100719dcef447 ("tracing: Add simple expression support to hist triggers") Reported-by: Yordan Karadzhov BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215513 Signed-off-by: Tom Zanussi Signed-off-by: Steven Rostedt (Google) [sudip: adjust context] Signed-off-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman commit 8fdaa9a6ace20a226793069da3e495dd0408ed1f Author: Sumeet Pawnikar Date: Thu Dec 23 15:12:36 2021 +0530 thermal/drivers/int340x: Fix RFIM mailbox write commands commit 2685c77b80a80c57e2a25a726b82fb31e6e212ab upstream. The existing mail mechanism only supports writing of workload types. However, mailbox command for RFIM (cmd = 0x08) also requires write operation which is ignored. This results in failing to store RFI restriction. Fixint this requires enhancing mailbox writes for non workload commands too, so remove the check for MBOX_CMD_WORKLOAD_TYPE_WRITE in mailbox write to allow this other write commands to be supoorted. At the same time, however, we have to make sure that there is no impact on read commands, by avoiding to write anything into the mailbox data register. To properly implement that, add two separate functions for mbox read and write commands for the processor thermal workload command type. This helps to distinguish the read and write workload command types from each other while sending mbox commands. Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes") Signed-off-by: Sumeet Pawnikar Cc: 5.14+ # 5.14+ Acked-by: Srinivas Pandruvada [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5abd95ff5d6a0b65af0430fbde4edb4f1ae23b85 Author: Arnd Bergmann Date: Mon Nov 8 12:13:41 2021 +0100 thermal: int340x: Limit Kconfig to 64-bit commit 994a04a20b03128838ec0250a0e266aab24d23f1 upstream. 32-bit processors cannot generally access 64-bit MMIO registers atomically, and it is unknown in which order the two halves of this registers would need to be read: drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c: In function 'send_mbox_cmd': drivers/thermal/intel/int340x_thermal/processor_thermal_mbox.c:79:37: error: implicit declaration of function 'readq'; did you mean 'readl'? [-Werror=implicit-function-declaration] 79 | *cmd_resp = readq((void __iomem *) (proc_priv->mmio_base + MBOX_OFFSET_DATA)); | ^~~~~ | readl The driver already does not build for anything other than x86, so limit it further to x86-64. Fixes: aeb58c860dc5 ("thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses") Signed-off-by: Arnd Bergmann Reviewed-by: Srinivas Pandruvada Reviewed-by: Randy Dunlap Signed-off-by: Rafael J. Wysocki Signed-off-by: Sumeet Pawnikar Signed-off-by: Greg Kroah-Hartman commit 786293f61b4bbff174f8ec6038371ba8aaed9b74 Author: Srinivas Pandruvada Date: Tue Nov 2 03:52:36 2021 -0700 thermal/drivers/int340x: processor_thermal: Suppot 64 bit RFIM responses commit aeb58c860dc516794fdf7ff89d96ead2644d5889 upstream. Some of the RFIM mail box command returns 64 bit values. So enhance mailbox interface to return 64 bit values and use them for RFIM commands. Signed-off-by: Srinivas Pandruvada Fixes: 5d6fbc96bd36 ("thermal/drivers/int340x: processor_thermal: Export additional attributes") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sumeet Pawnikar Signed-off-by: Greg Kroah-Hartman commit e9b0301939d16ecc42aabaca4252b646f37f04af Author: Antoine Tenart Date: Thu Sep 9 10:56:13 2021 +0200 thermal/drivers/int340x: Improve the tcc offset saving for suspend/resume commit c4fcf1ada4ae63e0aab6afd19ca2e7d16833302c upstream. When the driver resumes, the tcc offset is set back to its previous value. But this only works if the value was user defined as otherwise the offset isn't saved. This asymmetric logic is harder to maintain and introduced some issues. Improve the logic by saving the tcc offset in a suspend op, so the right value is always restored after a resume. Signed-off-by: Antoine Tenart Reviewed-by: Srinivas Pandruvada Tested-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210909085613.5577-3-atenart@kernel.org Signed-off-by: Daniel Lezcano Signed-off-by: Sumeet Pawnikar Signed-off-by: Greg Kroah-Hartman commit c6eff5c4277146a78b4fb8c9b668dd64542c41b0 Author: Chuck Lever Date: Fri Feb 4 15:19:34 2022 -0500 NFSD: Fix the behavior of READ near OFFSET_MAX commit 0cb4d23ae08c48f6bf3c29a8e5c4a74b8388b960 upstream. Dan Aloni reports: > Due to commit 8cfb9015280d ("NFS: Always provide aligned buffers to > the RPC read layers") on the client, a read of 0xfff is aligned up > to server rsize of 0x1000. > > As a result, in a test where the server has a file of size > 0x7fffffffffffffff, and the client tries to read from the offset > 0x7ffffffffffff000, the read causes loff_t overflow in the server > and it returns an NFS code of EINVAL to the client. The client as > a result indefinitely retries the request. The Linux NFS client does not handle NFS?ERR_INVAL, even though all NFS specifications permit servers to return that status code for a READ. Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed and return a short result. Set the EOF flag in the result to prevent the client from retrying the READ request. This behavior appears to be consistent with Solaris NFS servers. Note that NFSv3 and NFSv4 use u64 offset values on the wire. These must be converted to loff_t internally before use -- an implicit type cast is not adequate for this purpose. Otherwise VFS checks against sb->s_maxbytes do not work properly. Reported-by: Dan Aloni Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit c9a8571dd8938176a6a707c5a1a06738ae5e2fff Author: Chuck Lever Date: Fri Feb 4 17:05:24 2022 -0500 NFSD: Fix offset type in I/O trace points commit 6a4d333d540041d244b2fca29b8417bfde20af81 upstream. NFSv3 and NFSv4 use u64 offset values on the wire. Record these values verbatim without the implicit type case to loff_t. Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 01c3ae81eef4d4f718bd946c11451c9f12bff68d Author: Chuck Lever Date: Tue Jan 25 16:36:22 2022 -0500 NFSD: Clamp WRITE offsets commit 6260d9a56ab352b54891ec66ab0eced57d55abc6 upstream. Ensure that a client cannot specify a WRITE range that falls in a byte range outside what the kernel's internal types (such as loff_t, which is signed) can represent. The kiocb iterators, invoked in nfsd_vfs_write(), should properly limit write operations to within the underlying file system's s_maxbytes. Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 8e0ecaf7a7e57b30284d6b3289cc436100fadc48 Author: Chuck Lever Date: Mon Jan 31 13:01:53 2022 -0500 NFSD: Fix ia_size underflow commit e6faac3f58c7c4176b66f63def17a34232a17b0e upstream. iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and NFSv4 both define file size as an unsigned 64-bit type. Thus there is a range of valid file size values an NFS client can send that is already larger than Linux can handle. Currently decode_fattr4() dumps a full u64 value into ia_size. If that value happens to be larger than S64_MAX, then ia_size underflows. I'm about to fix up the NFSv3 behavior as well, so let's catch the underflow in the common code path: nfsd_setattr(). Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 37f2d2cd8eadddbbd9c7bda327a9393399b2f89b Author: Chuck Lever Date: Tue Jan 25 15:59:57 2022 -0500 NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes commit a648fdeb7c0e17177a2280344d015dba3fbe3314 upstream. iattr::ia_size is a loff_t, so these NFSv3 procedures must be careful to deal with incoming client size values that are larger than s64_max without corrupting the value. Silently capping the value results in storing a different value than the client passed in which is unexpected behavior, so remove the min_t() check in decode_sattr3(). Note that RFC 1813 permits only the WRITE procedure to return NFS3ERR_FBIG. We believe that NFSv3 reference implementations also return NFS3ERR_FBIG when ia_size is too large. Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 535e301ea677a37459577466f25cda2a7e8d3af1 Author: Trond Myklebust Date: Wed Feb 2 18:52:01 2022 -0500 NFS: Fix initialisation of nfs_client cl_flags field commit 468d126dab45718feeb728319be20bd869a5eaa7 upstream. For some long forgotten reason, the nfs_client cl_flags field is initialised in nfs_get_client() instead of being initialised at allocation time. This quirk was harmless until we moved the call to nfs_create_rpc_client(). Fixes: dd99e9f98fbf ("NFSv4: Initialise connection to the server in nfs4_alloc_client()") Cc: stable@vger.kernel.org # 4.8.x Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 6b42352bea5674778ebf3b0a31585df9a2f4267b Author: Pavel Parkhomenko Date: Sun Feb 6 00:49:51 2022 +0300 net: phy: marvell: Fix MDI-x polarity setting in 88e1118-compatible PHYs commit aec12836e7196e4d360b2cbf20cf7aa5139ad2ec upstream. When setting up autonegotiation for 88E1118R and compatible PHYs, a software reset of PHY is issued before setting up polarity. This is incorrect as changes of MDI Crossover Mode bits are disruptive to the normal operation and must be followed by a software reset to take effect. Let's patch m88e1118_config_aneg() to fix the issue mentioned before by invoking software reset of the PHY just after setting up MDI-x polarity. Fixes: 605f196efbf8 ("phy: Add support for Marvell 88E1118 PHY") Signed-off-by: Pavel Parkhomenko Reviewed-by: Serge Semin Suggested-by: Andrew Lunn Cc: stable@vger.kernel.org Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9338c17e2c632997e96075e4f452862ed95869bd Author: Pavel Parkhomenko Date: Sat Feb 5 23:39:32 2022 +0300 net: phy: marvell: Fix RGMII Tx/Rx delays setting in 88e1121-compatible PHYs commit fe4f57bf7b585dca58f1496c4e2481ecbae18126 upstream. It is mandatory for a software to issue a reset upon modifying RGMII Receive Timing Control and RGMII Transmit Timing Control bit fields of MAC Specific Control register 2 (page 2, register 21) otherwise the changes won't be perceived by the PHY (the same is applicable for a lot of other registers). Not setting the RGMII delays on the platforms that imply it' being done on the PHY side will consequently cause the traffic loss. We discovered that the denoted soft-reset is missing in the m88e1121_config_aneg() method for the case if the RGMII delays are modified but the MDIx polarity isn't changed or the auto-negotiation is left enabled, thus causing the traffic loss on our platform with Marvell Alaska 88E1510 installed. Let's fix that by issuing the soft-reset if the delays have been actually set in the m88e1121_config_aneg_rgmii_delays() method. Cc: stable@vger.kernel.org Fixes: d6ab93364734 ("net: phy: marvell: Avoid unnecessary soft reset") Signed-off-by: Pavel Parkhomenko Reviewed-by: Russell King (Oracle) Reviewed-by: Serge Semin Link: https://lore.kernel.org/r/20220205203932.26899-1-Pavel.Parkhomenko@baikalelectronics.ru Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 540dff311c9aa7cefd35d59b4bf738f7829c1ec5 Author: Oliver Hartkopp Date: Wed Feb 9 08:36:01 2022 +0100 can: isotp: fix error path in isotp_sendmsg() to unlock wait queue commit 8375dfac4f683e1b2c5956d919d36aeedad46699 upstream. Commit 43a08c3bdac4 ("can: isotp: isotp_sendmsg(): fix TX buffer concurrent access in isotp_sendmsg()") introduced a new locking scheme that may render the userspace application in a locking state when an error is detected. This issue shows up under high load on simultaneously running isotp channels with identical configuration which is against the ISO specification and therefore breaks any reasonable PDU communication anyway. Fixes: 43a08c3bdac4 ("can: isotp: isotp_sendmsg(): fix TX buffer concurrent access in isotp_sendmsg()") Link: https://lore.kernel.org/all/20220209073601.25728-1-socketcan@hartkopp.net Cc: stable@vger.kernel.org Cc: Ziyang Xuan Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f90cc68f9f4b5d8585ad5d0a206a9d37ac299ef3 Author: Oliver Hartkopp Date: Tue Feb 8 21:00:26 2022 +0100 can: isotp: fix potential CAN frame reception race in isotp_rcv() commit 7c759040c1dd03954f650f147ae7175476d51314 upstream. When receiving a CAN frame the current code logic does not consider concurrently receiving processes which do not show up in real world usage. Ziyang Xuan writes: The following syz problem is one of the scenarios. so->rx.len is changed by isotp_rcv_ff() during isotp_rcv_cf(), so->rx.len equals 0 before alloc_skb() and equals 4096 after alloc_skb(). That will trigger skb_over_panic() in skb_put(). ======================================================= CPU: 1 PID: 19 Comm: ksoftirqd/1 Not tainted 5.16.0-rc8-syzkaller #0 RIP: 0010:skb_panic+0x16c/0x16e net/core/skbuff.c:113 Call Trace: skb_over_panic net/core/skbuff.c:118 [inline] skb_put.cold+0x24/0x24 net/core/skbuff.c:1990 isotp_rcv_cf net/can/isotp.c:570 [inline] isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 deliver net/can/af_can.c:574 [inline] can_rcv_filter+0x445/0x8d0 net/can/af_can.c:635 can_receive+0x31d/0x580 net/can/af_can.c:665 can_rcv+0x120/0x1c0 net/can/af_can.c:696 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5465 __netif_receive_skb+0x24/0x1b0 net/core/dev.c:5579 Therefore we make sure the state changes and data structures stay consistent at CAN frame reception time by adding a spin_lock in isotp_rcv(). This fixes the issue reported by syzkaller but does not affect real world operation. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Link: https://lore.kernel.org/linux-can/d7e69278-d741-c706-65e1-e87623d9a8e8@huawei.com/T/ Link: https://lore.kernel.org/all/20220208200026.13783-1-socketcan@hartkopp.net Cc: stable@vger.kernel.org Reported-by: syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com Reported-by: Ziyang Xuan Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit dbe7bf9b6fc8fefbbbc207c1a07fe890605fe07c Author: Andrey Skvortsov Date: Sat Jan 15 15:14:46 2022 +0300 mmc: core: Wait for command setting 'Power Off Notification' bit to complete commit 379f56c24e698f14242f532b1d0a0f1747725e08 upstream. SD card is allowed to signal busy on DAT0 up to 1s after the CMD49. According to SD spec (version 6.0 section 5.8.1.3) first host waits until busy of CMD49 is released and only then polls Power Management Status register up to 1s until the card indicates ready to power off. Without waiting for busy before polling status register sometimes card becomes unresponsive and system fails to suspend: [ 205.907459] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. [ 206.421274] sunxi-mmc 1c0f000.mmc: data error, sending stop command [ 206.421321] sunxi-mmc 1c0f000.mmc: send stop command failed [ 206.421347] mmc0: error -110 reading status reg of PM func [ 206.421366] PM: dpm_run_callback(): mmc_bus_suspend+0x0/0x74 returns -110 [ 206.421402] mmcblk mmc0:aaaa: PM: failed to suspend async: error -110 [ 206.437064] PM: Some devices failed to suspend, or early wake event detected Tested with Sandisk Extreme PRO A2 64GB on Allwinner A64 system. Signed-off-by: Andrey Skvortsov Fixes: 2c5d42769038 ("mmc: core: Add support for Power Off Notification for SD cards") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220115121447.641524-1-andrej.skvortzov@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 222c071fadd611222ac294bb96627ee92afcfeba Author: Jiasheng Jiang Date: Wed Jan 12 16:31:56 2022 +0800 mmc: sdhci-of-esdhc: Check for error num after setting mask commit 40c67c291a93f8846c4a972c9ef1b7ba4544c8d0 upstream. Because of the possible failure of the dma_supported(), the dma_set_mask_and_coherent() may return error num. Therefore, it should be better to check it and return the error if fails. And since the sdhci_setup_host() has already checked the return value of the enable_dma, we need not check it in sdhci_resume_host() again. Fixes: 5552d7ad596c ("mmc: sdhci-of-esdhc: set proper dma mask for ls104x chips") Signed-off-by: Jiasheng Jiang Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220112083156.1124782-1-jiasheng@iscas.ac.cn Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit cf4570ca8ed624841f8dc2be8c4939c9f61239d3 Author: Stefan Berger Date: Tue Feb 1 15:37:10 2022 -0500 ima: Do not print policy rule with inactive LSM labels commit 89677197ae709eb1ab3646952c44f6a171c9e74c upstream. Before printing a policy rule scan for inactive LSM labels in the policy rule. Inactive LSM labels are identified by args_p != NULL and rule == NULL. Fixes: 483ec26eed42 ("ima: ima/lsm policy rule loading logic bug fixes") Signed-off-by: Stefan Berger Cc: # v5.6+ Acked-by: Christian Brauner [zohar@linux.ibm.com: Updated "Fixes" tag] Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 5389ea64af1ea4069f25c564556b37d470976e31 Author: Roberto Sassu Date: Mon Jan 31 18:11:39 2022 +0100 ima: Allow template selection with ima_template[_fmt]= after ima_hash= commit bb8e52e4906f148c2faf6656b5106cf7233e9301 upstream. Commit c2426d2ad5027 ("ima: added support for new kernel cmdline parameter ima_template_fmt") introduced an additional check on the ima_template variable to avoid multiple template selection. Unfortunately, ima_template could be also set by the setup function of the ima_hash= parameter, when it calls ima_template_desc_current(). This causes attempts to choose a new template with ima_template= or with ima_template_fmt=, after ima_hash=, to be ignored. Achieve the goal of the commit mentioned with the new static variable template_setup_done, so that template selection requests after ima_hash= are not ignored. Finally, call ima_init_template_list(), if not already done, to initialize the list of templates before lookup_template_desc() is called. Reported-by: Guo Zihua Signed-off-by: Roberto Sassu Cc: stable@vger.kernel.org Fixes: c2426d2ad5027 ("ima: added support for new kernel cmdline parameter ima_template_fmt") Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 20805cdf95af0c64e428ee4b7e2cefa27abbe375 Author: Stefan Berger Date: Tue Jan 25 17:46:23 2022 -0500 ima: Remove ima_policy file before directory commit f7333b9572d0559e00352a926c92f29f061b4569 upstream. The removal of ima_dir currently fails since ima_policy still exists, so remove the ima_policy file before removing the directory. Fixes: 4af4662fa4a9 ("integrity: IMA policy") Signed-off-by: Stefan Berger Cc: Acked-by: Christian Brauner Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 0838d6d68182f0b28a5434bc6d50727c4757e35b Author: Eric Biggers Date: Thu Jan 13 11:44:38 2022 -0800 ima: fix reference leak in asymmetric_verify() commit 926fd9f23b27ca6587492c3f58f4c7f4cd01dad5 upstream. Don't leak a reference to the key if its algorithm is unknown. Fixes: 947d70597236 ("ima: Support EC keys for signature verification") Cc: # v5.13+ Signed-off-by: Eric Biggers Reviewed-by: Stefan Berger Reviewed-by: Tianjia Zhang Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit 739b7bb886b5ffa40a9492398aa04b01438e598b Author: Xiaoke Wang Date: Sat Jan 15 09:11:11 2022 +0800 integrity: check the return value of audit_log_start() commit 83230351c523b04ff8a029a4bdf97d881ecb96fc upstream. audit_log_start() returns audit_buffer pointer on success or NULL on error, so it is better to check the return value of it. Fixes: 3323eec921ef ("integrity: IMA as an integrity service provider") Signed-off-by: Xiaoke Wang Cc: Reviewed-by: Paul Moore Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman