CVE-2022-26966

commit 528cecfa5af09631f0589efe9eacbd543c8c9db1 Author: Greg Kroah-Hartman Date: Wed Feb 16 12:58:51 2022 +0100 Linux 5.16.10 Link: https://lore.kernel.org/r/[email protected] Tested-by: Jeffrin Jose T Tested-by: Jon Hunter Tested-by: Ronald Warsow Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Tested-by: Rudi Heitbaum Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Slade Watkins Tested-by: Guenter Roeck Tested-by: Zan Aziz Tested-by: Ron Economos Tested-by: Bagas Sanjaya Tested-by: Scott Bruce Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman commit f74fc4b5bd533ea3d30ce47cccb8ef8d21fda85a 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/[email protected] Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 37654be7d705734c08d35cd64554c5273e04580f Author: Chia-Wei Wang Date: Tue Feb 1 17:30:27 2022 +1030 docs/ABI: testing: aspeed-uart-routing: Escape asterisk commit 088400521e421a1df7d0128dc0f9246db4ef1c7c upstream. Escape asterisk symbols to fix the following warning: “WARNING: Inline emphasis start-string without end-string” Fixes: c6807970c3bc (“soc: aspeed: Add UART routing support”) Reported-by: Stephen Rothwell Signed-off-by: Chia-Wei Wang Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]’ Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit ebadf974485ca45eaf001a12193e32b5663a859c Author: Masahiro Yamada Date: Tue Feb 8 15:26:18 2022 +0900 kconfig: fix missing fclose() on error paths commit d23a0c3718222a42430fd56359478a6fc7675070 upstream. The file is not closed when ferror() fails. Fixes: 00d674cb3536 ("kconfig: refactor conf_write_dep()") Fixes: 57ddd07c4560 ("kconfig: refactor conf_write_autoconf()") Reported-by: Ryan Cai Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 2142bc1469a316fddd10012d76428f7265258f81 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit f033f8638686b887cfa0aecb2bf1641343cadfd1 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 96d87adafdc546b2b2eb13caf39d05b90830a937 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 baea9b393f7ed7f018bfbb45b5b6a23a9b259e36 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/[email protected] Reviewed-by: Ewan D. Milne Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 863ee54f6a4290ef1fe19835aa68b957b5885ae9 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/[email protected] Reviewed-by: Ewan D. Milne Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d095f84b5c031dbe02a14a70d3db498aa88e25c0 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: [email protected] 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 3f8f00d5159bfcdeafc6c51b8630331dfb3d879a 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: [email protected] 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 d4813c2a76feb7ba0551d82a6415e1ca30f9f108 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/[email protected] [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: [email protected] # v5.14 + Reviewed-by: Manivannan Sadhasivam Signed-off-by: Slark Xiao Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 9d683ef323793db65944afb9332e1dc28efbdf5b 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/[email protected] [mani: Added pci_generic prefix to subject and CCed stable] Fixes: aac426562f56 (“bus: mhi: pci_generic: Introduce Foxconn T99W175 support”) Cc: [email protected] # v5.12+ Reviewed-by: Manivannan Sadhasivam Signed-off-by: Slark Xiao Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit a0619027f11590b2070624297530c34dc7f91bcd 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: [email protected] 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 65191c5a013e2743004227c54d429bca560e60fa 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: [email protected] Signed-off-by: Kees Cook Reviewed-by: “Eric W. Biederman” Link: https://lore.kernel.org/lkml/[email protected] Signed-off-by: Greg Kroah-Hartman commit 235c960e9d80e973356edcb9dd551fc5d5363d29 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: [email protected] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman commit babfa07e9594373e10b9c01ada6278d0248665e1 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/[email protected] 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 3980cff6349687f73d5109f156f23cb261c24164 Author: Mel Gorman Date: Fri Feb 11 16:32:29 2022 -0800 mm: vmscan: remove deadlock due to throttling failing to make progress commit b485c6f1f9f54b81443efda5f3d8a5036ba2cd91 upstream. A soft lockup bug in kcompactd was reported in a private bugzilla with the following visible in dmesg; watchdog: BUG: soft lockup - CPU#33 stuck for 26s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 52s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 78s! [kcompactd0:479] watchdog: BUG: soft lockup - CPU#33 stuck for 104s! [kcompactd0:479] The machine had 256G of RAM with no swap and an earlier failed allocation indicated that node 0 where kcompactd was run was potentially unreclaimable; Node 0 active_anon:29355112kB inactive_anon:2913528kB active_file:0kB inactive_file:0kB unevictable:64kB isolated(anon):0kB isolated(file):0kB mapped:8kB dirty:0kB writeback:0kB shmem:26780kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 23480320kB writeback_tmp:0kB kernel_stack:2272kB pagetables:24500kB all_unreclaimable? yes Vlastimil Babka investigated a crash dump and found that a task migrating pages was trying to drain PCP lists; PID: 52922 TASK: ffff969f820e5000 CPU: 19 COMMAND: “kworker/u128:3” Call Trace: __schedule schedule schedule_timeout wait_for_completion __flush_work __drain_all_pages __alloc_pages_slowpath.constprop.114 __alloc_pages alloc_migration_target migrate_pages migrate_to_node do_migrate_pages cpuset_migrate_mm_workfn process_one_work worker_thread kthread ret_from_fork This failure is specific to CONFIG_PREEMPT=n builds. The root of the problem is that kcompact0 is not rescheduling on a CPU while a task that has isolated a large number of the pages from the LRU is waiting on kcompact0 to reschedule so the pages can be released. While shrink_inactive_list() only loops once around too_many_isolated, reclaim can continue without rescheduling if sc->skipped_deactivate == 1 which could happen if there was no file LRU and the inactive anon list was not low. Link: https://lkml.kernel.org/r/[email protected] Fixes: d818fca1cac3 (“mm/vmscan: throttle reclaim and compaction when too may pages are isolated”) Signed-off-by: Mel Gorman Debugged-by: Vlastimil Babka Reviewed-by: Vlastimil Babka Acked-by: Michal Hocko Acked-by: David Rientjes Cc: Hugh Dickins Cc: Michal Hocko Cc: Rik van Riel Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 05d3f8045efa59457b323caf00bdb9273b7962fa Author: Yang Shi Date: Fri Feb 11 16:32:26 2022 -0800 fs/proc: task_mmu.c: don’t read mapcount for migration entry commit 24d7275ce2791829953ed4e72f68277ceb2571c6 upstream. The syzbot reported the below BUG: kernel BUG at include/linux/page-flags.h:785! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline] RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744 Call Trace: page_mapcount include/linux/mm.h:837 [inline] smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466 smaps_pte_entry fs/proc/task_mmu.c:538 [inline] smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601 walk_pmd_range mm/pagewalk.c:128 [inline] walk_pud_range mm/pagewalk.c:205 [inline] walk_p4d_range mm/pagewalk.c:240 [inline] walk_pgd_range mm/pagewalk.c:277 [inline] __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379 walk_page_vma+0x277/0x350 mm/pagewalk.c:530 smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768 smap_gather_stats fs/proc/task_mmu.c:741 [inline] show_smap+0xc6/0x440 fs/proc/task_mmu.c:822 seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272 seq_read+0x3e0/0x5b0 fs/seq_file.c:162 vfs_read+0x1b5/0x600 fs/read_write.c:479 ksys_read+0x12d/0x250 fs/read_write.c:619 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 The reproducer was trying to read /proc/$PID/smaps when calling MADV_FREE at the mean time. MADV_FREE may split THPs if it is called for partial THP. It may trigger the below race: CPU A CPU B ----- ----- smaps walk: MADV_FREE: page_mapcount() PageCompound() split_huge_page() page = compound_head(page) PageDoubleMap(page) When calling PageDoubleMap() this page is not a tail page of THP anymore so the BUG is triggered. This could be fixed by elevated refcount of the page before calling mapcount, but that would prevent it from counting migration entries, and it seems overkilling because the race just could happen when PMD is split so all PTE entries of tail pages are actually migration entries, and smaps_account() does treat migration entries as mapcount == 1 as Kirill pointed out. Add a new parameter for smaps_account() to tell this entry is migration entry then skip calling page_mapcount(). Don’t skip getting mapcount for device private entries since they do track references with mapcount. Pagemap also has the similar issue although it was not reported. Fixed it as well. [[email protected]: v4] Link: https://lkml.kernel.org/r/[email protected] [[email protected]: avoid unused variable warning in pagemap_pmd_range()] Link: https://lkml.kernel.org/r/[email protected] Link: https://lkml.kernel.org/r/[email protected] Fixes: e9b61f19858a ("thp: reintroduce split_huge_page()") Signed-off-by: Yang Shi Signed-off-by: Nathan Chancellor Reported-by: [email protected] Acked-by: David Hildenbrand Cc: “Kirill A. Shutemov” Cc: Jann Horn Cc: Matthew Wilcox Cc: Alexey Dobriyan Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 202071d2518537866d291aa7cf26af54e674f4d4 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: [email protected] 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 5b0c9569135a37348c1267c81e8b0274b21a86ed 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: [email protected] # v5.10+ Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit c0c5c59ebe229a3bbf54b6b04c3c196de01d59ae 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: [email protected] 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 8692bd4b81c877e4648f1fae66fe9c5bb06dda89 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: [email protected] Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 5250f93fa0407f63436423fccf46b070a15a2e5f 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: [email protected] Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit c5a3f8123205ee1eb6e82e0ab4a8049e6ba0600b 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/[email protected] Cc: [email protected] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f27ba2932e05219290a70f2cba044ca512d2c4e2 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: [email protected] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 2f992ec70910d711c5aa6ebcbc1246d8c7eb3c9d 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: [email protected] Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f24f243c43aa4f0265f8767f1a16b610292fec62 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit 44e1c58b031d2e28ee1d17570b28297e0b8101c3 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit 2724ebafda0a8df08a9cb91557d33226bee80f7b 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: [email protected] Tested-by: Szymon Heidrich Signed-off-by: Greg Kroah-Hartman commit 8895017abfc76bbc223499b179919dd205047197 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: [email protected] Signed-off-by: Greg Kroah-Hartman commit cac3b4288cf7997c812fafcef16b85c8f79a3e45 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit 230aff54d7ba4c860071007eef20c5179adc151e 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit e0b2f29bc78f9165707807cb153085123ad47274 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit 5751b4a1efe2c2b6b34adfe7b25636eddda00f10 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/[email protected] Signed-off-by: Greg Kroah-Hartman commit 9681823f96a811268265f35307072ad80713c274 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: [email protected] Signed-off-by: Jann Horn Signed-off-by: Greg Kroah-Hartman commit 2a8839e8ad002c9d0f76bc024babc05563600c07 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/[email protected] Reported-by: kernel test robot Fixes: 269cbcf7b72d (“usb: dwc2: drd: fix soft connect when gadget is unconfigured”) Cc: [email protected] Cc: Amelie Delaunay Cc: Minas Harutyunyan Cc: Fabrice Gasnier Signed-off-by: Greg Kroah-Hartman commit 5c77c68f92d34164c9c163a9e89ca01b931f45f1 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: [email protected] Reviewed-by: Amelie Delaunay Acked-by: Minas Harutyunyan Signed-off-by: Fabrice Gasnier Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 9443ddeb3754e9e382a396b50adc1961301713ce 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: [email protected] Reviewed-by: Heiner Kallweit Signed-off-by: Jonas Malaco Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman commit 7509105d950c3e3519b498be09b74a5811f2f502 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: [email protected] Signed-off-by: Kosuke Tatsukawa Link: https://lore.kernel.org/r/TYCPR01MB81901C0F932203D30E452B3EA5209@TYCPR01MB8190.jpnprd01.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit 3e1172470291be94df624b77cf6e0fea10cee0e2 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/[email protected] Cc: stable Signed-off-by: Greg Kroah-Hartman commit 6550bdf52846f85a2a3726a5aa0c7c4399f2fc02 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/[email protected] Cc: stable Signed-off-by: Greg Kroah-Hartman commit 402888280890bceb19e96733dc44792ebfdcd62d 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/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 03ae6e0ffd6342dc8f0db0cf0432d3dac07fd343 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/[email protected]/ Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 6d26421f742345acb6158780dd1e61f945615f06 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 faa9bcf700ca1a0d09f92502a6b65d3ce313fb46 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 a71758d9bf226c1e14f715d974d3b768f8a9cf55 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 a5031f2e2abc4af93d5d44cdd7ecf20ac220b5ec 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 f026534490616abf5254e2ae4b02beb6c4ed5561 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 dd88e8fc6b0ffde0c60efc34737cfbcef0b4ac6c 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 2c625f41acb09a1247ab0027207733501b404c5a 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 89b60402d43cdab4387dbbf24afebda5cf092ae7 Author: Vladimir Oltean Date: Wed Feb 9 14:04:33 2022 +0200 net: dsa: fix panic when DSA master device unbinds on shutdown [ Upstream commit ee534378f00561207656663d93907583958339ae ] Rafael reports that on a system with LX2160A and Marvell DSA switches, if a reboot occurs while the DSA master (dpaa2-eth) is up, the following panic can be seen: systemd-shutdown[1]: Rebooting. Unable to handle kernel paging request at virtual address 00a0000800000041 [00a0000800000041] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32 pc : dsa_slave_netdevice_event+0x130/0x3e4 lr : raw_notifier_call_chain+0x50/0x6c Call trace: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/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 __do_sys_reboot+0x1cc/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 It can be seen from the stack trace that the problem is that the deregistration of the master causes a dev_close(), which gets notified as NETDEV_GOING_DOWN to dsa_slave_netdevice_event(). But dsa_switch_shutdown() has already run, and this has unregistered the DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to call dev_close_many() on those slave interfaces, leading to the problem. The previous attempt to avoid the NETDEV_GOING_DOWN on the master after dsa_switch_shutdown() was called seems improper. Unregistering the slave interfaces is unnecessary and unhelpful. Instead, after the slaves have stopped being uppers of the DSA master, we can now reset to NULL the master->dsa_ptr pointer, which will make DSA start ignoring all future notifier events on the master. Fixes: 0650bf52b31f (“net: dsa: be compatible with masters which unregister on shutdown”) Reported-by: Rafael Richter Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aa35588817c50ef1bde3bbbd035810a4f681aa5d 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 7377bdeb324da76bc678b5ccc96bc5b1f9780240 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 baaf77203ae6267a7d961b082f785aa0aef91d2f 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 fd45628d2fec2bf7085d856ef448959d6e7effe9 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 8b1087b998e273f07be13dcb5f3ca4c309c7f108 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 ff6962c6c9570856f32306859eb92e8b3ea78cc1 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 a191e10ee2e17a97cfd6f6b90ee7b6131d918596 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/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit feb9597e22755dce782aae26ac0590c06737e049 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/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 73844cfa960c3dd7badda9e59ac1f9a6871ff54b Author: Cai Huoqing Date: Tue Feb 8 09:33:08 2022 +0800 net: ethernet: litex: Add the dependency on HAS_IOMEM [ Upstream commit 2427f03fb42f9dc14c53108f2c9b5563eb37e770 ] The LiteX driver uses devm io function API which needs HAS_IOMEM enabled, so add the dependency on HAS_IOMEM. Fixes: ee7da21ac4c3 (“net: Add driver for LiteX’s LiteETH network interface”) Signed-off-by: Cai Huoqing Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit e08cb9056fb2564d1f6bad789bdf79ab09bf2f81 Author: Sukadev Bhattiprolu Date: Mon Feb 7 16:19:18 2022 -0800 ibmvnic: don’t release napi in __ibmvnic_open() [ Upstream commit 61772b0908c640d0309c40f7d41d062ca4e979fa ] If __ibmvnic_open() encounters an error such as when setting link state, it calls release_resources() which frees the napi structures needlessly. Instead, have __ibmvnic_open() only clean up the work it did so far (i.e. disable napi and irqs) and leave the rest to the callers. If caller of __ibmvnic_open() is ibmvnic_open(), it should release the resources immediately. If the caller is do_reset() or do_hard_reset(), they will release the resources on the next reset. This fixes following crash that occurred when running the drmgr command several times to add/remove a vnic interface: [102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq [102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq [102056] ibmvnic 30000003 env3: Replenished 8 pools Kernel attempted to read user page (10) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000010 Faulting instruction address: 0xc000000000a3c840 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries … CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1 Workqueue: events_long __ibmvnic_reset [ibmvnic] NIP: c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820 REGS: c0000000548e37e0 TRAP: 0300 Not tainted (5.16.0-rc5-autotest-g6441998e2e37) MSR: 8000000000009033 CR: 28248484 XER: 00000004 CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0 GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000 … NIP [c000000000a3c840] napi_enable+0x20/0xc0 LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic] Call Trace: [c0000000548e3a80] [0000000000000006] 0x6 (unreliable) [c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic] [c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic] [c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570 [c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660 [c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0 [c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010 38a0fff6 e92d1100 f9210028 39200000 f9010020 60420000 e9210020 —[ end trace 5f8033b08fd27706 ]— Fixes: ed651a10875f (“ibmvnic: Updated reset handling”) Reported-by: Abdul Haleem Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2443ba2fe396bdde187a2fdfa6a57375643ae93c 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 6cccab29bf67e3fa2ebeeec529bd08cf9511afe2 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 0e816362d823cd46c666e64d8bffe329ee22f4cc Author: Vladimir Oltean Date: Mon Feb 7 18:15:51 2022 +0200 net: dsa: seville: register the mdiobus under devres [ Upstream commit bd488afc3b39e045ba71aab472233f2a78726e7b ] 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 Seville VSC9959 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 seville 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 seville driver has a code structure that could accommodate both the mdiobus_unregister and mdiobus_free calls, but it has an external dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls devm_mdiobus_alloc_size() on its behalf. So rather than restructuring that, and exporting yet one more symbol mscc_miim_teardown(), let’s work with devres and replace of_mdiobus_register with the devres variant. When we use all-devres, we can ensure that devres doesn’t free a still-registered bus (it either runs both callbacks, or none). 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 b167753770500d36999aaac1268a880877f540d7 Author: Colin Foster Date: Sun Nov 28 17:57:36 2021 -0800 net: dsa: ocelot: seville: utilize of_mdiobus_register [ Upstream commit 5186c4a05b9713138b762a49467a8ab9753cdb36 ] Switch seville to use of_mdiobus_register(bus, NULL) instead of just mdiobus_register. This code is about to be pulled into a separate module that can optionally define ports by the device_node. Signed-off-by: Colin Foster Reviewed-by: Florian Fainelli Reviewed-by: Vladimir Oltean Tested-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9db6f056efd089e80d81c774c01b639adf30c097 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 08e1a3554e99a1a5bd2835907381e2383ee85cae 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 f1842a8cb71de4d7eb75a86f76e88c7ee739218c 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 1b451c3994a2d322f8e55032c62c8b47b7d95900 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 3767e6d0194ed387b3e60daa72f3f6c8bce6a10c 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/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2592d6734cb0b99f8ea9c4198ae1efb723457f7b Author: Tao Liu Date: Mon Feb 7 09:59:01 2022 -0800 gve: Recording rx queue before sending to napi [ Upstream commit 084cbb2ec3af2d23be9de65fcc9493e21e265859 ] This caused a significant performance degredation when using generic XDP with multiple queues. Fixes: f5cedc84a30d2 (“gve: Add transmit and receive support”) Signed-off-by: Tao Liu Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9482ab4540f5bcc869b44c067ae99b5fca16bd07 Author: NeilBrown Date: Mon Jan 17 16:36:53 2022 +1100 SUNRPC: lock against ->sock changing during sysfs read [ Upstream commit b49ea673e119f59c71645e2f65b3ccad857c90ee ] ->sock can be set to NULL asynchronously unless ->recv_mutex is held. So it is important to hold that mutex. Otherwise a sysfs read can trigger an oops. Commit 17f09d3f619a (“SUNRPC: Check if the xprt is connected before handling sysfs reads”) appears to attempt to fix this problem, but it only narrows the race window. Fixes: 17f09d3f619a (“SUNRPC: Check if the xprt is connected before handling sysfs reads”) Fixes: a8482488a7d6 (“SUNRPC query transport’s source port”) Signed-off-by: NeilBrown Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit b532c42150d027d731632f7508d71e3a194dda61 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 db3b2912e93fd1dc260108ac957a11e6bc29da96 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 a01aba10ca7977e02b718a97be4240e34ca16d6f 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 4287509b4d21e34dc49266c6239920811e189e40 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 5ccd87faca6bc1a4981550321541beab57e63199 Author: Ilya Leoshkevich Date: Mon Jan 31 14:17:11 2022 +0100 s390/module: fix building test_modules_helpers.o with clang [ Upstream commit e286f231eab410793f3e91c924e6dbd23edee05a ] Move test_modules_return_* prototypes into a header file in order to placate -Wmissing-prototypes. Fixes: 90c5318795ee (“s390/module: test loading modules with a lot of relocations”) Reported-by: kernel test robot Reviewed-by: Heiko Carstens Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 0ae0a3bdc92b8b2e6aefe283761a48b1276a62c3 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: [email protected] Reviewed-by: Sam Ravnborg Signed-off-by: Marek Vasut Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Sasha Levin commit 401838b22606409ece8a8eeedc18273632d1f4a1 Author: Vladimir Oltean Date: Sat Feb 5 01:03:21 2022 +0200 net: mscc: ocelot: fix all IP traffic getting trapped to CPU with PTP over IP [ Upstream commit 59085208e4a2183998964844f8684fea0378128d ] The filters for the PTP trap keys are incorrectly configured, in the sense that is2_entry_set() only looks at trap->key.ipv4.dport or trap->key.ipv6.dport if trap->key.ipv4.proto or trap->key.ipv6.proto is set to IPPROTO_TCP or IPPROTO_UDP. But we don’t do that, so is2_entry_set() goes through the “else” branch of the IP protocol check, and ends up installing a rule for “Any IP protocol match” (because msk is also 0). The UDP port is ignored. This means that when we run "ptp4l -i swp0 -4", all IP traffic is trapped to the CPU, which hinders bridging. Fix this by specifying the IP protocol in the VCAP IS2 filters for PTP over UDP. Fixes: 96ca08c05838 (“net: mscc: ocelot: set up traps for PTP packets”) Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 47f3860c4931175f112f28dcac66eacca9b1040f Author: Eric Dumazet Date: Thu Feb 3 14:55:47 2022 -0800 tcp: take care of mixed splice()/sendmsg(MSG_ZEROCOPY) case [ Upstream commit f8d9d938514f46c4892aff6bfe32f425e84d81cc ] syzbot found that mixing sendpage() and sendmsg(MSG_ZEROCOPY) calls over the same TCP socket would again trigger the infamous warning in inet_sock_destruct() WARN_ON(sk_forward_alloc_get(sk)); While Talal took into account a mix of regular copied data and MSG_ZEROCOPY one in the same skb, the sendpage() path has been forgotten. We want the charging to happen for sendpage(), because pages could be coming from a pipe. What is missing is the downgrading of pure zerocopy status to make sure sk_forward_alloc will stay synced. Add tcp_downgrade_zcopy_pure() helper so that we can use it from the two callers. Fixes: 9b65b17db723 (“net: avoid double accounting for pure zerocopy skbs”) Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Talal Ahmad Cc: Arjun Roy Cc: Willem de Bruijn Acked-by: Soheil Hassas Yeganeh Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a8b50be3db83ecb0f5acec2a5c6f600669572c0e 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 1315f759859cc1fe1698971b0eef3c5e5a96df9f 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 769c7dbcfc4e81c3a31134f19476b7caf87adc6c 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 0a0a0be9ed6144ffb1698487d7c7bff3543cfe9c 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 223dc5adb983c742eb505efa482cdced82f97c76 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 54e302cf55b6f782bd1b85a0e4e0a4f483c40d4c 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 c3cef1b1fe34a9ee705a364217bc326c169968a9 Author: Florian Westphal Date: Sat Jan 29 17:13:23 2022 +0100 netfilter: nft_payload: don’t allow th access for fragments [ Upstream commit a9e8503def0fd4ed89ade1f61c315f904581d439 ] Loads relative to ->thoff naturally expect that this points to the transport header, but this is only true if pkt->fragoff == 0. This has little effect for rulesets with connection tracking/nat because these enable ip defra. For other rulesets this prevents false matches. Fixes: 96518518cc41 (“netfilter: add nftables”) Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2005bd45c7e5dd1d2d0d4ff1e28c85767e6381e9 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/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 76f85c307ef9f10aa2cef1b1d5ee654c1f3345fc 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/[email protected] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7707833af7a94890523ce2b69bcb500a9ae56a85 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/[email protected] Signed-off-by: Sasha Levin commit e3a141f26734694812292b1ec949006e84b41ead Author: Trond Myklebust Date: Tue Jan 18 22:10:52 2022 -0500 NFS: Avoid duplicate uncached readdir calls on eof [ Upstream commit e1d2699b96793d19388e302fa095e0da2c145701 ] If we’ve reached the end of the directory, then cache that information in the context so that we don’t need to do an uncached readdir in order to rediscover that fact. Fixes: 794092c57f89 (“NFS: Do uncached readdir when we’re seeking a cookie in an empty page cache”) Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 77bfe650e59d77ae2ec096a466f68a531ce09fde Author: [email protected] 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 98512f35a20028f4793e1b97db96dc75e2ef1cdb Author: [email protected] 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 d038dc10afe771949836c67c82387e6f205a933a 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 301cebd1d51e27e171520d417fd6a2313a86cbca 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/[email protected] Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 2daa702590e3aa9545b24459cac2e253e5740081 Author: Mark Brown Date: Tue Feb 1 14:48:38 2022 +0000 arm64: Enable Cortex-A510 erratum 2051678 by default [ Upstream commit a4b92cebc31d49b7e6ef0ce584c7f2a2e112877d ] The recently added configuration option for Cortex A510 erratum 2051678 does not have a “default y” unlike other errata fixes. This appears to simply be an oversight since the help text suggests enabling the option if unsure and there’s nothing in the commit log to suggest it is intentional. Fixes: 297ae1eb23b0 (“arm64: cpufeature: List early Cortex-A510 parts as having broken dbm”) Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 3e078b18753669615301d946297bafd69294ad2c 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/[email protected] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9a9be9f3f7b9bdee2f60355c984154d3b4420398 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 e67ae5a9bb78c1b87229584820d14c7a8621accc 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 0ad1a88fa3eb0ded7798f52b79bc33f75fc9a6d2 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 6a3eb02fa3a83db98cf3e1952978bb9e12db784d 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/[email protected] Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 91fc147e23d01d526384784e3fbec32360864254 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 805df0ab1c80a773c82a03625807775233ba12af 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/[email protected] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7e246eb9c1519666e1330bb1b58c23b6a721498a Author: Jens Wiklander Date: Tue Dec 28 21:25:57 2021 +0100 optee: add error checks in optee_ffa_do_call_with_arg() [ Upstream commit 4064c461148ab129dfe5eaeea129b4af6cf4b9b7 ] Adds error checking in optee_ffa_do_call_with_arg() for correctness. Fixes: 4615e5a34b95 (“optee: add FF-A support”) Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 306eb7325a386f8b37d6b477a2a11290c0359cd1 Author: Jerome Forissier Date: Thu Jan 13 16:27:13 2022 +0100 tee: optee: do not check memref size on return from Secure World [ Upstream commit abc8dc34d1f6e34ed346c6e3fc554127e421b769 ] Commit c650b8dc7a79 (“tee: optee: do not check memref size on return from Secure World”) was mistakenly lost in commit 4602c5842f64 (“optee: refactor driver with internal callbacks”). Remove the unwanted code again. Fixes: 4602c5842f64 (“optee: refactor driver with internal callbacks”) Signed-off-by: Jerome Forissier Reviewed-by: Sumit Garg Signed-off-by: Jens Wiklander Signed-off-by: Sasha Levin commit 25d7fdb27d20cc71b57dd41aa7dc8e81e9b76ee9 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/[email protected] Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 05348bfe144f2885384f8aef17c74b4c3232149a 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/[email protected] Signed-off-by: Sasha Levin commit 3282e05464e2c4ad82bcbd9fd5d6c0c9c29f8a63 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/[email protected] Signed-off-by: Sasha Levin commit c32cfccb366eb41f0d0ee74056ca4316bc91c705 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/[email protected] Signed-off-by: Sasha Levin commit 586f5ad06625bb84095ee42905f0542b560fe60c 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: [email protected] 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 2521b0a43db2046f3b975dbe44cf1ac2472f6206 Author: Ville Syrjälä Date: Fri Feb 4 16:18:18 2022 +0200 drm/i915: Workaround broken BIOS DBUF configuration on TGL/RKL commit 4e6f55120c7eccf6f9323bb681632e23cbcb3f3c upstream. On TGL/RKL the BIOS likes to use some kind of bogus DBUF layout that doesn’t match what the spec recommends. With a single active pipe that is not going to be a problem, but with multiple pipes active skl_commit_modeset_enables() goes into an infinite loop since it can’t figure out any order in which it can commit the pipes without causing DBUF overlaps between the planes. We’d need some kind of extra DBUF defrag stage in between to make the transition possible. But that is clearly way too complex a solution, so in the name of simplicity let’s just sanitize the DBUF state by simply turning off all planes when we detect a pipe encroaching on its neighbours’ DBUF slices. We only have to disable the primary planes as all other planes should have already been disabled (if they somehow were enabled) by earlier sanitization steps. And for good measure let’s also sanitize in case the DBUF allocations of the pipes already seem to overlap each other. Cc: # v5.14+ Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4762 Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Stanislav Lisovskiy (cherry picked from commit 15512021eb3975a8c2366e3883337e252bb0eee5) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 327e245fc70a72d2c6ae43e3f5a9d3f75e1848a1 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/[email protected] Reviewed-by: Stanislav Lisovskiy (cherry picked from commit b3dcc6dc0f32612d04839c2fb32e94d0ebf92c98) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit f6983748cdba10b480617ac008150ea04fea2746 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/[email protected] Reviewed-by: Stanislav Lisovskiy (cherry picked from commit eef173954432fe0612acb63421a95deb41155cdc) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit 30b737b53a84cfcb5339790c6b140457e6a35094 Author: Ville Syrjälä Date: Fri Jan 28 12:37:50 2022 +0200 drm/i915: Disable DRRS on IVB/HSW port != A commit ee59792c97176f12c1da31f29fc4c2aab187f06e upstream. Currently we allow DRRS on IVB PCH ports, but we’re missing a few programming steps meaning it is guaranteed to not work. And on HSW DRRS is not supported on anything but port A ever as only transcoder EDP has the M2/N2 registers (though I’m not sure if HSW ever has eDP on any other port). Starting from BDW all transcoders have the dynamically reprogrammable M/N registers so DRRS could work on any port. Stop initializing DRRS on ports where it cannot possibly work. Cc: [email protected] Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Jani Nikula (cherry picked from commit f0d4ce59f4d48622044933054a0e0cefa91ba15e) Signed-off-by: Tvrtko Ursulin Signed-off-by: Greg Kroah-Hartman commit bb3ff8d02c4514eb79ef1cfe6e567d45ec72dd53 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 a2837c4302b916ed282156addc4aa9a766a4d252 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: [email protected] Signed-off-by: Greg Kroah-Hartman commit 9d30d7fad27e23f76738a4c8df18ba7eb74d2896 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 e575cb9e1409f6e37fa39ab46aeec6f335bd531d 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 73299da3017d3113f1a16a03895b2ab9892998df 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: [email protected] Signed-off-by: Sagi Grimberg Reviewed-by: Hannes Reinecke Signed-off-by: Christoph Hellwig Signed-off-by: Greg Kroah-Hartman commit 39c89238289ee8a37e55420133b3343ba2ebd4ec 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 c606b83ae91b8d8eefeeb233785e45830ed863e8 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: [email protected] Cc: Stefan Hansson Link: https://lore.kernel.org/r/[email protected]’ Signed-off-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman commit b197f11a5d4779004fed081f7fb59e4f212ea620 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 2d88a0f49d4dea292891b9a4a29a9acb54f9ee82 Author: Bjorn Helgaas Date: Mon Feb 7 16:33:30 2022 -0600 Revert “PCI/portdrv: Do not setup up IRQs if there are no users” commit 075b7d363c675ef7fa03918881caeca3458e2a96 upstream. This reverts commit 0e8ae5a6ff5952253cd7cc0260df838ab4c21009. 0e8ae5a6ff59 (“PCI/portdrv: Do not setup up IRQs if there are no users”) reduced usage of IRQs when we don’t think we need them. But Joey, Sergiu, and David reported choppy GUI rendering, systems that became unresponsive every few seconds, incorrect values reported by cpufreq, and high IRQ 16 CPU usage. Joey bisected the issues to 0e8ae5a6ff59, so revert it until we figure out a better solution. Link: https://lore.kernel.org/r/20220210222717.GA658201@bhelgaas Link: https://bugzilla.kernel.org/show_bug.cgi?id=215533 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215546 Reported-by: Joey Corleone Reported-by: Sergiu Deitsch Reported-by: David Spencer Signed-off-by: Bjorn Helgaas Cc: [email protected] # v5.16+ Cc: Jan Kiszka Signed-off-by: Greg Kroah-Hartman commit 4ad70fad65d7faf7d3d3126218eba48651d0674a Author: Andreas Gruenbacher Date: Thu Feb 3 14:06:56 2022 +0100 Revert “gfs2: check context in gfs2_glock_put” commit 356b8103d4c495d5440e3e687db9026ec2b76043 upstream. It turns out that the might_sleep() call that commit 660a6126f8c3 adds is triggering occasional data corruption in testing. We’re not sure about the root cause yet, but since this commit was added as a debugging aid only, revert it for now. This reverts commit 660a6126f8c3208f6df8d552039cda078a8426d1. Fixes: 660a6126f8c3 (“gfs2: check context in gfs2_glock_put”) Cc: [email protected] # v5.16+ Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit fdd3bc76b8ad13dab4a692912ec03883fd4a80a8 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: [email protected] # v5.12+ Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Greg Kroah-Hartman commit 7324a299fa544bdce6bced422a0923dbed513266 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: [email protected] Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit e1d176461bb80846ea37d1af4237b176d493af51 Author: Palmer Dabbelt Date: Fri Feb 4 13:13:37 2022 -0800 riscv/mm: Add XIP_FIXUP for phys_ram_base commit 4b1c70aa8ed8249608bb991380cb8ff423edf49e upstream. This manifests as a crash early in boot on VexRiscv. Signed-off-by: Myrtle Shah [Palmer: split commit] Fixes: 6d7f91d914bc (“riscv: Get rid of CONFIG_PHYS_RAM_BASE in kernel physical address conversion”) Cc: [email protected] Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 03fdd1adcac67e38b78a83a5f26979d5efe1279f 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: [email protected] [Palmer: Add missing NUMA include] Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit 56f81a1d8e6c4d39d77d159397c99baccea9bfcd Author: Myrtle Shah Date: Thu Jan 20 15:33:37 2022 +0000 riscv: Fix XIP_FIXUP_FLASH_OFFSET commit 3c04d84508b54fcf524093b0d4a718680ed67f0f upstream. There were several problems with the calculation. Not only was an ‘and’ being computed into t1 but thrown away; but the ‘and’ itself would cause problems if the granularity of the XIP physical address was less than XIP_OFFSET - in my case I had the kernel image at 2MB in SPI flash. Fixes: f9ace4ede49b (“riscv: remove .text section size limitation for XIP”) Cc: [email protected] Signed-off-by: Myrtle Shah Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit fa8b369129b0706d400e1dfe150c946e64f56df5 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: [email protected] Signed-off-by: Palmer Dabbelt Signed-off-by: Greg Kroah-Hartman commit dafd92c0dd5653823c639d02c9d7dc109f23e5a9 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: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 1c524f83c86d7918afc78c8a621260bcafb53bb0 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: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 29fad213db69ee3935534a0ae688e36443291e15 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: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit f283aa272854800756a2fd32c863e7bc84274bd7 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: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 07ee12244001e7d81d47673e1fab87daa2944dc4 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: [email protected] Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit d851051d25c26f204b1b93c3722471d8efb53227 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 4d4710b7dfea13e7e2793824bf38c36129594ad8 Author: Marco Elver Date: Sat Jan 29 13:41:11 2022 -0800 kasan: test: fix compatibility with FORTIFY_SOURCE [ Upstream commit 09c6304e38e440b93a9ebf3f3cf75cd6cb529f91 ] With CONFIG_FORTIFY_SOURCE enabled, string functions will also perform dynamic checks using __builtin_object_size(ptr), which when failed will panic the kernel. Because the KASAN test deliberately performs out-of-bounds operations, the kernel panics with FORTIFY_SOURCE, for example: | kernel BUG at lib/string_helpers.c:910! | invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI | CPU: 1 PID: 137 Comm: kunit_try_catch Tainted: G B 5.16.0-rc3+ #3 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 | RIP: 0010:fortify_panic+0x19/0x1b | … | Call Trace: | kmalloc_oob_in_memset.cold+0x16/0x16 | … Fix it by also hiding `ptr` from the optimizer, which will ensure that __builtin_object_size() does not return a valid size, preventing fortified string functions from panicking. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Marco Elver Reported-by: Nico Pache Reviewed-by: Nico Pache Reviewed-by: Andrey Konovalov Reviewed-by: Kees Cook Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: Brendan Higgins Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4e3e5ef6f83816ebadac4157ec5b28cba97d2378 Author: James Morse Date: Tue Jan 25 15:40:40 2022 +0000 arm64: cpufeature: List early Cortex-A510 parts as having broken dbm [ Upstream commit 297ae1eb23b04c5a46111ab53c8d0f69af43f402 ] Versions of Cortex-A510 before r0p3 are affected by a hardware erratum where the hardware update of the dirty bit is not correctly ordered. Add these cpus to the cpu_has_broken_dbm list. Signed-off-by: James Morse Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit aff260ffbaa3c45df62e56ec7e543698039ae237 Author: Anshuman Khandual Date: Tue Jan 25 19:50:34 2022 +0530 arm64: errata: Add detection for TRBE trace data corruption [ Upstream commit 708e8af4924ec2fdd5b81fe09192c6bac2f86935 ] TRBE implementations affected by Arm erratum #1902691 might corrupt trace data or deadlock, when it’s being written into the memory. So effectively TRBE is broken and hence cannot be used to capture trace data. This adds a new errata ARM64_ERRATUM_1902691 in arm64 errata framework. Cc: Catalin Marinas Cc: Will Deacon Cc: Mathieu Poirier Cc: Suzuki Poulose Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: Suzuki K Poulose Acked-by: Catalin Marinas Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 12c7ff193e5716296898a5a63d4aaeed5ab3bd0e Author: Anshuman Khandual Date: Tue Jan 25 19:50:33 2022 +0530 arm64: errata: Add detection for TRBE invalid prohibited states [ Upstream commit 3bd94a8759de9b724b83a80942b0354acd7701eb ] TRBE implementations affected by Arm erratum #2038923 might get TRBE into an inconsistent view on whether trace is prohibited within the CPU. As a result, the trace buffer or trace buffer state might be corrupted. This happens after TRBE buffer has been enabled by setting TRBLIMITR_EL1.E, followed by just a single context synchronization event before execution changes from a context, in which trace is prohibited to one where it isn’t, or vice versa. In these mentioned conditions, the view of whether trace is prohibited is inconsistent between parts of the CPU, and the trace buffer or the trace buffer state might be corrupted. This adds a new errata ARM64_ERRATUM_2038923 in arm64 errata framework. Cc: Catalin Marinas Cc: Will Deacon Cc: Mathieu Poirier Cc: Suzuki Poulose Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: Suzuki K Poulose Acked-by: Catalin Marinas Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit def426ff5b0e3bf92890ecc2fbb40c049b839304 Author: Anshuman Khandual Date: Tue Jan 25 19:50:32 2022 +0530 arm64: errata: Add detection for TRBE ignored system register writes [ Upstream commit 607a9afaae09cde21ece458a8f10cb99d3f94f14 ] TRBE implementations affected by Arm erratum #2064142 might fail to write into certain system registers after the TRBE has been disabled. Under some conditions after TRBE has been disabled, writes into certain TRBE registers TRBLIMITR_EL1, TRBPTR_EL1, TRBBASER_EL1, TRBSR_EL1 and TRBTRG_EL1 will be ignored and not be effected. This adds a new errata ARM64_ERRATUM_2064142 in arm64 errata framework. Cc: Catalin Marinas Cc: Will Deacon Cc: Mathieu Poirier Cc: Suzuki Poulose Cc: [email protected] Cc: [email protected] Cc: [email protected] Cc: [email protected] Reviewed-by: Suzuki K Poulose Acked-by: Catalin Marinas Signed-off-by: Anshuman Khandual Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Mathieu Poirier Signed-off-by: Sasha Levin commit 5b2c7b48b6f42f012068cd87709096fd44b8429b 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 749ff1b50d93496ddaf704e9005dfe82342026a2 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 fb54db87b137ad2b35b95eaf028c00d7e103f78b 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 4aa9e58ada921ce1f542edf2abde7a26d7469b68 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/[email protected] Signed-off-by: Sasha Levin commit 612b99a3480dd495e7b53d220f936c9281f0bc0d 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/[email protected] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6a97718cd8263c10add484b117f3cd593ef151cd Author: Alex Deucher Date: Thu Jan 20 12:57:33 2022 -0500 drm/amdgpu/display: use msleep rather than udelay for long delays [ Upstream commit 98fdcacb45f7cd2092151d6af2e60152811eb79c ] Some architectures (e.g., ARM) throw an compilation error if the udelay is too long. In general udelays of longer than 2000us are not recommended on any architecture. Switch to msleep in these cases. Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b556287b7af049e7802cfa630f8b50f0875e6455 Author: Alex Deucher Date: Thu Jan 20 12:52:13 2022 -0500 drm/amdgpu/display: adjust msleep limit in dp_wait_for_training_aux_rd_interval [ Upstream commit dc919d670c6fd1ac81ebf31625cd19579f7b3d4c ] Some architectures (e.g., ARM) have relatively low udelay limits. On most architectures, anything longer than 2000us is not recommended. Change the check to align with other similar checks in DC. Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit b3b650949bf6933192fc93eaf6f96df5680f0aa2 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 e6085b30d43e07251f42d43b744b36c01ed9d6d8 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 bd1d47894589f2675218157f06bf446a6f03c0ab 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 1d6cd26605b4d662063a83c15c776b5299a1cb23 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/[email protected] Reviewed-by: Hannes Reinecke Signed-off-by: Tong Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0398436e39b219cc26f44f9a301779e82f1684f7 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/[email protected] Signed-off-by: Kiwoong Kim Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b51cd22338d092524307e75fbf4974ce572001c1 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/[email protected] Reviewed-by: Bart Van Assche Signed-off-by: Kiwoong Kim Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ee0961879903586ecf4f8fff84451edb87873ec9 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/[email protected] 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 10eeed3f28af12c5ed9d01a931d7a10242154fc3 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/[email protected] Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7fcbed38503bb34c6e6538b6a9482d1c6bead1e8 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/[email protected] Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0be556512cd0dfcf5ec1a140d9f42d88221a5d4e 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/[email protected] Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c9463ecdeae5fb7f795f5dacea82cbc1f53bdc52 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/[email protected] Reviewed-by: Bean Huo Signed-off-by: Xiaoke Wang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fe4de5330c774e2e0c1621e6a72d60391568b94d 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/[email protected] Signed-off-by: ZouMingzhe Reviewed-by: Mike Christie Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bba18ebcb9e931f4096e449b45b6ed66814e00a6 Author: Anshuman Khandual Date: Mon Jan 24 08:45:38 2022 +0530 arm64: errata: Update ARM64_ERRATUM_[2119858|2224489] with Cortex-X2 ranges [ Upstream commit eb30d838a44c9e59a2a106884f536119859c7257 ] Errata ARM64_ERRATUM_[2119858|2224489] also affect some Cortex-X2 ranges as well. Lets update these errata definition and detection to accommodate all new Cortex-X2 based cpu MIDR ranges. Cc: Will Deacon Cc: Mathieu Poirier Cc: Suzuki Poulose Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual Reviewed-by: Suzuki K Poulose Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit d6c23c072dd13e9a8ae34e00d4b7c41ef0bc15d2 Author: Anshuman Khandual Date: Mon Jan 24 08:45:37 2022 +0530 arm64: Add Cortex-X2 CPU part definition [ Upstream commit 72bb9dcb6c33cfac80282713c2b4f2b254cd24d1 ] Add the CPU Partnumbers for the new Arm designs. Cc: Will Deacon Cc: Suzuki Poulose Cc: [email protected] Cc: [email protected] Signed-off-by: Anshuman Khandual Reviewed-by: Suzuki K Poulose Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 0415a1faf5667584c3b3418006fc26c1e6506919 Author: Ilya Leoshkevich Date: Wed Jan 19 19:26:38 2022 +0100 s390/module: test loading modules with a lot of relocations [ Upstream commit 90c5318795eefa09a9f9aef8d18a904e24962b5c ] Add a test in order to prevent regressions. Signed-off-by: Ilya Leoshkevich Reviewed-by: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 033fd42c18d9b2121595b6f1e8419a115f9ac5b7 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 5f155a692805d266e0af666f8e04f9b4f6781a58 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 a28169b2028059bcf94190e269d2bc202ea90391 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/[email protected] Signed-off-by: Sasha Levin commit dddd832f35096fbc5004e3a7e58fb4d2cefb8deb 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/[email protected] Signed-off-by: Sasha Levin commit f07660619137d1044018cbdd832147d379327f7f 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/[email protected] Signed-off-by: Sasha Levin commit 413f2ed88cf87f9a2a3937d6cbf1aa3021c93401 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/[email protected] Signed-off-by: Sasha Levin commit d541954a11eb21cb308f1ca5cafcbe9fe77005b9 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/[email protected] Signed-off-by: Sasha Levin commit adb3af62a4ef8a0099d19531fa3af432487b52f9 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 bd1a71fb5ff205c8547d23d5247c4fcd45c78d53 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 5f6024c05a2c0fdd180b29395aaf686d25af3a0f 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 101ab9e4a437751df15ba02c4c27853ad3c45b33 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 9059dfdcffd4b85f1de3cbaeed4e9563e4ea266e 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 f41906e7a9654c3b987cac59332f82795222a060 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 cc61c7bc31a46d08a96fa668e65be9731528635f 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 6fcba13c409e0cbf52444345eec608d5d4a9d0a3 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 66b528b3a53d710d047ea32688572edec930b15d 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 93d3ba70f80ee7f106b5af440168abd28c7e84ad 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 0ce79f2fd06512469f66a66b9ff7e8e77c8ade49 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 b9ecb66d89bae4baa72e7d3eb9ea2fe3bf06c1ce 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 4d8a71c9ed50468a67e9123a854305078821bd84 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 44502aca8e02ab32d6b0eb52e006a5ec9402719b 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: [email protected] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 24c24ddfe26511837bc1a429bafdbb0d4977bfdc 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 6642b8debe5858919a73e2e4a814eb752733733c 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: [email protected] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit da22ca1ad548429d7822011c54cfe210718e0aa7 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: [email protected] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit aa9051ddb4b378bd22e72a67bc77b9fc1482c5f0 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: [email protected] Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 69ce87d6fb9b3863a3091f6f2929db78a1bf6064 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: [email protected] # 4.8.x Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 965818167ce0e82a364ed00a8f18e9889092f7a4 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: [email protected] Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 804939211e361af4a3004dbb88642400734f1e41 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: [email protected] 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/[email protected] Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fb47eaa10db259fb8245961726bbc9e7c413376c 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/[email protected] Cc: [email protected] Cc: Ziyang Xuan Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 5b068f33bc8acfcfd5ea7992a2dafb30d89bad30 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/[email protected]/T/ Link: https://lore.kernel.org/all/[email protected] Cc: [email protected] Reported-by: [email protected] Reported-by: Ziyang Xuan Signed-off-by: Oliver Hartkopp Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 3c74f4d3ba182950dbe2ad8cef54900fbe604f02 Author: Jiasheng Jiang Date: Wed Jan 19 20:00:06 2022 +0800 mmc: sh_mmcif: Check for null res pointer commit 4d315357b3d6c315a7260420c6c6fc076e58d14b upstream. If there is no suitable resource, platform_get_resource() will return NULL. Therefore in order to avoid the dereference of the NULL pointer, it should be better to check the 'res’. Signed-off-by: Jiasheng Jiang Cc: [email protected] # v5.16+ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0690e2814367376fa44f5b250750a8e606146abe 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: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 56742f1ca462de43f04c0efd31a8404612be884b 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: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 74ff20ee157e7e76cb82abc7890baecf67c495fe 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 [[email protected]: Updated “Fixes” tag] Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit d38a03a82f873afaf9273e6b1c9fb8d2dacd78eb 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: [email protected] 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 09bef807c7630efd4d4be9dcf59467137ff782df 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 89f586d3398f4cc0432ed870949dffb702940754 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 310c9ddfdf1f8d3c9834f02175eae79c8b254b6c Author: Paul Moore Date: Wed Feb 9 14:49:38 2022 -0500 audit: don’t deref the syscall args when checking the openat2 open_how::flags commit 7a82f89de92aac5a244d3735b2bd162c1147620c upstream. As reported by Jeff, dereferencing the openat2 syscall argument in audit_match_perm() to obtain the open_how::flags can result in an oops/page-fault. This patch fixes this by using the open_how struct that we store in the audit_context with audit_openat2_how(). Independent of this patch, Richard Guy Briggs posted a similar patch to the audit mailing list roughly 40 minutes after this patch was posted. Cc: [email protected] Fixes: 1c30e3af8a79 (“audit: add support for the openat2 syscall”) Reported-by: Jeff Mahoney Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 19b067142db920796a60e21bc64f4921b78757b1 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