commit 6a7ababc0268063d0798c46d5859a90ee996612f Author: Greg Kroah-Hartman Date: Sat Sep 18 13:44:05 2021 +0200 Linux 5.14.6 Link: https://lore.kernel.org/r/20210916155810.813340753@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Salvatore Bonaccorso Signed-off-by: Greg Kroah-Hartman commit 5ecb17485abe61a4feb62c7dd76d0eb7b8475273 Author: Qiang.Zhang Date: Tue Aug 31 10:29:19 2021 +0800 tracing/osnoise: Fix missed cpus_read_unlock() in start_per_cpu_kthreads() commit 4b6b08f2e45edda4c067ac40833e3c1f84383c0b upstream. When start_kthread() return error, the cpus_read_unlock() need to be called. Link: https://lkml.kernel.org/r/20210831022919.27630-1-qiang.zhang@windriver.com Cc: Fixes: c8895e271f79 ("trace/osnoise: Support hotplug operations") Acked-by: Daniel Bristot de Oliveira Signed-off-by: Qiang.Zhang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 39cd7a4389642ec6526f726e6c33e06052e430dd Author: Alyssa Rosenzweig Date: Tue Aug 24 13:30:27 2021 -0400 drm/panfrost: Clamp lock region to Bifrost minimum commit bd7ffbc3ca12629aeb66fb9e28cf42b7f37e3e3b upstream. When locking a region, we currently clamp to a PAGE_SIZE as the minimum lock region. While this is valid for Midgard, it is invalid for Bifrost, where the minimum locking size is 8x larger than the 4k page size. Add a hardware definition for the minimum lock region size (corresponding to KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it. Signed-off-by: Alyssa Rosenzweig Tested-by: Chris Morgan Reviewed-by: Steven Price Reviewed-by: Rob Herring Cc: Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-4-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman commit 6f5bf4d5493c2c3296442c616aebe115739f474c Author: Alyssa Rosenzweig Date: Tue Aug 24 13:30:26 2021 -0400 drm/panfrost: Use u64 for size in lock_region commit a77b58825d7221d4a45c47881c35a47ba003aa73 upstream. Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure we can express the "lock everything" condition as ~0ULL without overflow. This code was silently broken on any platform where a size_t is less than 48-bits; in particular, it was broken on 32-bit armv7 platforms which remain in use with panfrost. (Mainly RK3288) Signed-off-by: Alyssa Rosenzweig Suggested-by: Rob Herring Tested-by: Chris Morgan Reviewed-by: Steven Price Reviewed-by: Rob Herring Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-3-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman commit e82cb7b9cdac7b480174aff94e9576829bee1855 Author: Alyssa Rosenzweig Date: Tue Aug 24 13:30:25 2021 -0400 drm/panfrost: Simplify lock_region calculation commit b5fab345654c603c07525100d744498f28786929 upstream. In lock_region, simplify the calculation of the region_width parameter. This field is the size, but encoded as ceil(log2(size)) - 1. ceil(log2(size)) may be computed directly as fls(size - 1). However, we want to use the 64-bit versions as the amount to lock can exceed 32-bits. This avoids undefined (and completely wrong) behaviour when locking all memory (size ~0). In this case, the old code would "round up" ~0 to the nearest page, overflowing to 0. Since fls(0) == 0, this would calculate a region width of 10 + 0 = 10. But then the code would shift by (region_width - 11) = -1. As shifting by a negative number is undefined, UBSAN flags the bug. Of course, even if it were defined the behaviour is wrong, instead of locking all memory almost none would get locked. The new form of the calculation corrects this special case and avoids the undefined behaviour. Signed-off-by: Alyssa Rosenzweig Reported-and-tested-by: Chris Morgan Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: Reviewed-by: Steven Price Reviewed-by: Rob Herring Signed-off-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-2-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman commit 988e381d5b2939af535751fcc96972aa39c7099a Author: Thomas Hellström Date: Tue Aug 31 09:15:36 2021 +0200 drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource commit efcefc7127290e7e9fa98dea029163ad8eda8fb3 upstream. The code was making a copy of a struct ttm_resource. However, recently the struct ttm_resources were allowed to be subclassed and also were allowed to be malloced, hence the driver could end up assuming the copy we handed it was subclassed and worse, the original could have been freed at this point. Fix this by using the original struct ttm_resource before it is potentially freed in ttm_bo_move_sync_cleanup() v2: Base on drm-misc-next-fixes rather than drm-tip. Reported-by: Ben Skeggs Reported-by: Dave Airlie Cc: Christian König Cc: Fixes: 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move for page-based iomem") Signed-off-by: Thomas Hellström Reviewed-by: Christian König Reviewed-by: Ben Skeggs Link: https://patchwork.freedesktop.org/patch/msgid/20210831071536.80636-1-thomas.hellstrom@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit d2419adc32e03b96828e865814d4efac09bef960 Author: Kalyan Thota Date: Wed Aug 4 02:40:28 2021 -0700 drm/msm/disp/dpu1: add safe lut config in dpu driver commit 5bccb945f38b2aff334619b23b50bb0a6a9995a5 upstream. Add safe lut configuration for all the targets in dpu driver as per QOS recommendation. Issue reported on SC7280: With wait-for-safe feature in smmu enabled, RT client buffer levels are checked to be safe before smmu invalidation. Since display was always set to unsafe it was delaying the invalidaiton process thus impacting the performance on NRT clients such as eMMC and NVMe. Validated this change on SC7280, With this change eMMC performance has improved significantly. Changes in v2: - Add fixes tag (Sai) - CC stable kernel (Dimtry) Changes in v3: - Correct fixes tag with appropriate hash (stephen) - Resend patch adding reviewed by tag - Resend patch adding correct format for pushing into stable tree (Greg) Fixes: 591e34a091d1 ("drm/msm/disp/dpu1: add support for display for SC7280 target") Cc: stable@vger.kernel.org Signed-off-by: Kalyan Thota Reviewed-by: Dmitry Baryshkov Tested-by: Sai Prakash Ranjan (sc7280, sc7180) Link: https://lore.kernel.org/r/1628070028-2616-1-git-send-email-kalyan_t@codeaurora.org Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit abf7b74d2e87b7dd91ac2c407ebd475b6c4a75e6 Author: Aaron Liu Date: Mon Aug 23 12:26:50 2021 +0800 drm/amd/display: setup system context for APUs commit 3ca001aff0878546494d7f403334c8d987924977 upstream. Scatter/gather is APU feature starting from carrizo. adev->apu_flags is not used for all APUs. adev->flags & AMD_IS_APU can be used for all APUs. Signed-off-by: Aaron Liu Reviewed-by: Huang Rui Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 2dfa48b1014da285c38ad5a7e9347648a9fab765 Author: Alex Sierra Date: Tue Aug 31 21:05:02 2021 -0500 drm/amdkfd: drop process ref count when xnack disable commit d6043581e1d9d0507a8413a302db0e35c8506e0e upstream. During svm restore pages interrupt handler, kfd_process ref count was never dropped when xnack was disabled. Therefore, the object was never released. Fixes: 2383f56bbe4a ("drm/amdkfd: page table restore through svm API") Signed-off-by: Alex Sierra Reviewed-by: Philip Yang Reviewed-by: Jonathan Kim Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9bf93c44e645cb549399aa45f97d6fee7c4a36fc Author: Jerry (Fangzhi) Zuo Date: Wed Jun 17 20:34:33 2020 -0400 drm/amd/display: Update bounding box states (v2) commit a7a9d11e12fcc32160d55e8612e72e5ab51b15dc upstream. [Why] Drop hardcoded dispclk, dppclk, phyclk [How] Read the corresponding values from clock table entries already populated. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Cc: stable@vger.kernel.org Signed-off-by: Jerry (Fangzhi) Zuo Signed-off-by: Aurabindo Pillai Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit a90b503fa8fcda84878a7e1600d3f07c951ad4a7 Author: Aurabindo Pillai Date: Tue Aug 24 15:10:50 2021 -0400 drm/amd/display: Update number of DCN3 clock states commit 0bbf06d888734041e813b916d7821acd4f72005a upstream. [Why & How] The DCN3 SoC parameter num_states was calculated but not saved into the object. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Cc: stable@vger.kernel.org Signed-off-by: Aurabindo Pillai Acked-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 93a74c5f91ef86bc862cf1f5b8b9cb671ee590fe Author: xinhui pan Date: Tue Aug 31 13:49:59 2021 +0800 drm/amdgpu: Fix a deadlock if previous GEM object allocation fails commit 703677d9345d87d7288ed8a2483ca424af7d4b3b upstream. Fall through to handle the error instead of return. Fixes: f8aab60422c37 ("drm/amdgpu: Initialise drm_gem_object_funcs for imported BOs") Cc: stable@vger.kernel.org Signed-off-by: xinhui pan Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit f38e7b5b601792bf545a032cc840a10899c4c853 Author: Nicholas Kazlauskas Date: Thu Jan 14 14:49:27 2021 -0500 drm/amdgpu: Enable S/G for Yellow Carp commit c5d3c9a093d353e7f38183a70df425f92e3c329d upstream. Missing code for Yellow Carp to enable scatter gather - follows how DCN21 support was added. Tested that 8k framebuffer allocation and display can now succeed after applying the patch. v2: Add hookup in DM Reviewed-by: Aaron Liu Acked-by: Huang Rui Signed-off-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c07bddac80872ec08af0803c38defa4e240481fb Author: Andrey Grodzovsky Date: Tue Jun 22 12:23:38 2021 -0400 drm/amdgpu: Fix BUG_ON assert commit ea7acd7c5967542353430947f3faf699e70602e5 upstream. With added CPU domain to placement you can have now 3 placemnts at once. CC: stable@kernel.org Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-5-andrey.grodzovsky@amd.com Signed-off-by: Greg Kroah-Hartman commit cf461fa9250a634e8afc4433d82ae0decea8136e Author: Boris Brezillon Date: Mon Jun 21 15:38:56 2021 +0200 drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_priv commit 7fdc48cc63a30fa3480d18bdd8c5fff2b9b15212 upstream. Jobs can be in-flight when the file descriptor is closed (either because the process did not terminate properly, or because it didn't wait for all GPU jobs to be finished), and apparently panfrost_job_close() does not cancel already running jobs. Let's refcount the MMU context object so it's lifetime is no longer bound to the FD lifetime and running jobs can finish properly without generating spurious page faults. Reported-by: Icecream95 Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210621133907.1683899-2-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman commit 70a6b061bd0207525820ea4a93b3edb32f2f97da Author: Rajkumar Subbiah Date: Tue Jul 6 08:30:34 2021 -0700 drm/dp_mst: Fix return code on sideband message failure commit 92bd92c44d0d9be5dcbcda315b4be4b909ed9740 upstream. Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") added some debug code for sideband message tracing. But it seems to have unintentionally changed the behavior on sideband message failure. It catches and returns failure only if DRM_UT_DP is enabled. Otherwise it ignores the error code and returns success. So on an MST unplug, the caller is unaware that the clear payload message failed and ends up waiting for 4 seconds for the response. Fixes the issue by returning the proper error code. Changes in V2: -- Revise commit text as review comment -- add Fixes text Changes in V3: -- remove "unlikely" optimization Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: # v5.5+ Signed-off-by: Rajkumar Subbiah Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Reviewed-by: Jani Nikula Reviewed-by: Lyude Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/1625585434-9562-1-git-send-email-khsieh@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit 698d11d3b774381cf8d08606559146d8f7250af3 Author: David Heidelberg Date: Wed Aug 11 19:06:31 2021 +0200 drm/msi/mdp4: populate priv->kms in mdp4_kms_init commit cb0927ab80d224c9074f53d1a55b087d12ec5a85 upstream. Without this fix boot throws NULL ptr exception at msm_dsi_manager_setup_encoder on devices like Nexus 7 2013 (MDP4 v4.4). Fixes: 03436e3ec69c ("drm/msm/dsi: Move setup_encoder to modeset_init") Cc: Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210811170631.39296-1-david@ixit.cz Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit b21eb52e3201bc65e7cc5e65d394a5301c758017 Author: Thomas Zimmermann Date: Wed Jul 14 16:22:28 2021 +0200 drm/mgag200: Select clock in PLL update functions commit 147696720eca12ae48d020726208b9a61cdd80bc upstream. Put the clock-selection code into each of the PLL-update functions to make them select the correct pixel clock. Instead of copying the code, introduce a new helper WREG_MISC_MASKED, which does masked writes into . Use it from each individual PLL update function. The pixel clock for video output was not actually set before programming the clock's values. It worked because the device had the correct clock pre-set. v2: * don't duplicate update code (Sam) Signed-off-by: Thomas Zimmermann Fixes: db05f8d3dc87 ("drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O") Acked-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Emil Velikov Cc: Dave Airlie Cc: dri-devel@lists.freedesktop.org Cc: # v5.9+ Link: https://patchwork.freedesktop.org/patch/msgid/20210714142240.21979-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit aca1bf8c362875b2fdcedf64445162d4e59ced31 Author: Song Yoong Siang Date: Fri Sep 3 10:00:26 2021 +0800 net: stmmac: Fix overall budget calculation for rxtx_napi commit 81d0885d68ec427e62044cf46a400c9958ea0092 upstream. tx_done is not used for napi_complete_done(). Thus, NAPI busy polling mechanism by gro_flush_timeout and napi_defer_hard_irqs will not able be triggered after a packet is transmitted when there is no receive packet. Fix this by taking the maximum value between tx_done and rx_done as overall budget completed by the rxtx NAPI poll to ensure XDP Tx ZC operation is continuously polling for next Tx frame. This gives benefit of lower packet submission processing latency and jitter under XDP Tx ZC mode. Performance of tx-only using xdp-sock on Intel ADL-S platform is the same with and without this patch. root@intel-corei7-64:~# ./xdpsock -i enp0s30f4 -t -z -q 1 -n 10 sock0@enp0s30f4:1 txonly xdp-drv pps pkts 10.00 rx 0 0 tx 511630 8659520 sock0@enp0s30f4:1 txonly xdp-drv pps pkts 10.00 rx 0 0 tx 511625 13775808 sock0@enp0s30f4:1 txonly xdp-drv pps pkts 10.00 rx 0 0 tx 511619 18892032 Fixes: 132c32ee5bc0 ("net: stmmac: Add TX via XDP zero-copy socket") Cc: # 5.13.x Co-developed-by: Ong Boon Leong Signed-off-by: Ong Boon Leong Signed-off-by: Song Yoong Siang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 90b940c249e4624b36534572482ec06d4e23c195 Author: Jan Hoffmann Date: Wed Sep 1 20:49:33 2021 +0200 net: dsa: lantiq_gswip: fix maximum frame length commit 552799f8b3b0074d2617f53a63a088f9514a66e3 upstream. Currently, outgoing packets larger than 1496 bytes are dropped when tagged VLAN is used on a switch port. Add the frame check sequence length to the value of the register GSWIP_MAC_FLEN to fix this. This matches the lantiq_ppa vendor driver, which uses a value consisting of 1518 bytes for the MAC frame, plus the lengths of special tag and VLAN tags. Fixes: 14fceff4771e ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Cc: stable@vger.kernel.org Signed-off-by: Jan Hoffmann Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f9cb67a9d07261ed3f346d752af7efd842c4ec8c Author: Kees Cook Date: Fri Jul 23 15:19:31 2021 -0700 lib/test_stackinit: Fix static initializer test commit f9398f15605a50110bf570aaa361163a85113dd1 upstream. The static initializer test got accidentally converted to a dynamic initializer. Fix this and retain the giant padding hole without using an aligned struct member. Fixes: 50ceaa95ea09 ("lib: Introduce test_stackinit module") Cc: Ard Biesheuvel Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210723221933.3431999-2-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman commit e9d9530dc67bea7eea378bef65228c91e7c1ba31 Author: Patryk Duda Date: Tue May 18 16:07:58 2021 +0200 platform/chrome: cros_ec_proto: Send command again when timeout occurs commit 3abc16af57c9939724df92fcbda296b25cc95168 upstream. Sometimes kernel is trying to probe Fingerprint MCU (FPMCU) when it hasn't initialized SPI yet. This can happen because FPMCU is restarted during system boot and kernel can send message in short window eg. between sysjump to RW and SPI initialization. Cc: # 4.4+ Signed-off-by: Patryk Duda Link: https://lore.kernel.org/r/20210518140758.29318-1-pdk@semihalf.com Signed-off-by: Benson Leung Signed-off-by: Greg Kroah-Hartman commit 2abdb539fe9c30e1aac6ac7d3898e4be53dde171 Author: sumiyawang Date: Sun Aug 22 19:49:09 2021 +0800 libnvdimm/pmem: Fix crash triggered when I/O in-flight during unbind commit 32b2397c1e56f33b0b1881def965bb89bd12f448 upstream. There is a use after free crash when the pmem driver tears down its mapping while I/O is still inbound. This is triggered by driver unbind, "ndctl destroy-namespace", while I/O is in flight. Fix the sequence of blk_cleanup_queue() vs memunmap(). The crash signature is of the form: BUG: unable to handle page fault for address: ffffc90080200000 CPU: 36 PID: 9606 Comm: systemd-udevd Call Trace: ? pmem_do_bvec+0xf9/0x3a0 ? xas_alloc+0x55/0xd0 pmem_rw_page+0x4b/0x80 bdev_read_page+0x86/0xb0 do_mpage_readpage+0x5d4/0x7a0 ? lru_cache_add+0xe/0x10 mpage_readpages+0xf9/0x1c0 ? bd_link_disk_holder+0x1a0/0x1a0 blkdev_readpages+0x1d/0x20 read_pages+0x67/0x1a0 ndctl Call Trace in vmcore: PID: 23473 TASK: ffff88c4fbbe8000 CPU: 1 COMMAND: "ndctl" __schedule schedule blk_mq_freeze_queue_wait blk_freeze_queue blk_cleanup_queue pmem_release_queue devm_action_release release_nodes devres_release_all device_release_driver_internal device_driver_detach unbind_store Cc: Signed-off-by: sumiyawang Reviewed-by: yongduan Link: https://lore.kernel.org/r/1629632949-14749-1-git-send-email-sumiyawang@tencent.com Fixes: 50f44ee7248a ("mm/devm_memremap_pages: fix final page put race") Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit 806d4f56570b23350d6b03788b2005c724625a7c Author: Vasily Averin Date: Thu Sep 2 14:54:57 2021 -0700 memcg: enable accounting for pids in nested pid namespaces commit fab827dbee8c2e06ca4ba000fa6c48bcf9054aba upstream. Commit 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") enabled memcg accounting for pids allocated from init_pid_ns.pid_cachep, but forgot to adjust the setting for nested pid namespaces. As a result, pid memory is not accounted exactly where it is really needed, inside memcg-limited containers with their own pid namespaces. Pid was one the first kernel objects enabled for memcg accounting. init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any new pids in the system are memcg-accounted. Though recently I've noticed that it is wrong. nested pid namespaces creates own slab caches for pid objects, nested pids have increased size because contain id both for all parent and for own pid namespaces. The problem is that these slab caches are _NOT_ marked by SLAB_ACCOUNT, as a result any pids allocated in nested pid namespaces are not memcg-accounted. Pid struct in nested pid namespace consumes up to 500 bytes memory, 100000 such objects gives us up to ~50Mb unaccounted memory, this allow container to exceed assigned memcg limits. Link: https://lkml.kernel.org/r/8b6de616-fd1a-02c6-cbdb-976ecdcfa604@virtuozzo.com Fixes: 5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg") Cc: stable@vger.kernel.org Signed-off-by: Vasily Averin Reviewed-by: Michal Koutný Reviewed-by: Shakeel Butt Acked-by: Christian Brauner Acked-by: Roman Gushchin Cc: Michal Hocko Cc: Johannes Weiner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 02cd61fa3e5921bf26da29a74cc9e1ec9de0d286 Author: yanghui Date: Wed Sep 8 18:10:20 2021 -0700 mm/mempolicy: fix a race between offset_il_node and mpol_rebind_task commit 276aeee1c5fc00df700f0782060beae126600472 upstream. Servers happened below panic: Kernel version:5.4.56 BUG: unable to handle page fault for address: 0000000000002c48 RIP: 0010:__next_zones_zonelist+0x1d/0x40 Call Trace: __alloc_pages_nodemask+0x277/0x310 alloc_page_interleave+0x13/0x70 handle_mm_fault+0xf99/0x1390 __do_page_fault+0x288/0x500 do_page_fault+0x30/0x110 page_fault+0x3e/0x50 The reason for the panic is that MAX_NUMNODES is passed in the third parameter in __alloc_pages_nodemask(preferred_nid). So access to zonelist->zoneref->zone_idx in __next_zones_zonelist will cause a panic. In offset_il_node(), first_node() returns nid from pol->v.nodes, after this other threads may chang pol->v.nodes before next_node(). This race condition will let next_node return MAX_NUMNODES. So put pol->nodes in a local variable. The race condition is between offset_il_node and cpuset_change_task_nodemask: CPU0: CPU1: alloc_pages_vma() interleave_nid(pol,) offset_il_node(pol,) first_node(pol->v.nodes) cpuset_change_task_nodemask //nodes==0xc mpol_rebind_task mpol_rebind_policy mpol_rebind_nodemask(pol,nodes) //nodes==0x3 next_node(nid, pol->v.nodes)//return MAX_NUMNODES Link: https://lkml.kernel.org/r/20210906034658.48721-1-yanghui.def@bytedance.com Signed-off-by: yanghui Reviewed-by: Muchun Song Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 40298f33aa3197316e8bce40b5c34882bc01e718 Author: Miaohe Lin Date: Wed Sep 8 18:10:11 2021 -0700 mm/page_alloc.c: avoid accessing uninitialized pcp page migratetype commit 053cfda102306a3394012f9fe2594811c34925e4 upstream. If it's not prepared to free unref page, the pcp page migratetype is unset. Thus we will get rubbish from get_pcppage_migratetype() and might list_del(&page->lru) again after it's already deleted from the list leading to grumble about data corruption. Link: https://lkml.kernel.org/r/20210902115447.57050-1-linmiaohe@huawei.com Fixes: df1acc856923 ("mm/page_alloc: avoid conflating IRQs disabled with zone->lock") Signed-off-by: Miaohe Lin Acked-by: Mel Gorman Acked-by: Vlastimil Babka Reviewed-by: David Hildenbrand Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d8f8f8c8f3692e7529c0386ab7741c17a57e83cd Author: Rik van Riel Date: Wed Sep 8 18:10:08 2021 -0700 mm,vmscan: fix divide by zero in get_scan_count commit 32d4f4b782bb8f0ceb78c6b5dc46eb577ae25bf7 upstream. Commit f56ce412a59d ("mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim") introduced a divide by zero corner case when oomd is being used in combination with cgroup memory.low protection. When oomd decides to kill a cgroup, it will force the cgroup memory to be reclaimed after killing the tasks, by writing to the memory.max file for that cgroup, forcing the remaining page cache and reclaimable slab to be reclaimed down to zero. Previously, on cgroups with some memory.low protection that would result in the memory being reclaimed down to the memory.low limit, or likely not at all, having the page cache reclaimed asynchronously later. With f56ce412a59d the oomd write to memory.max tries to reclaim all the way down to zero, which may race with another reclaimer, to the point of ending up with the divide by zero below. This patch implements the obvious fix. Link: https://lkml.kernel.org/r/20210826220149.058089c6@imladris.surriel.com Fixes: f56ce412a59d ("mm: memcontrol: fix occasional OOMs due to proportional memory.low reclaim") Signed-off-by: Rik van Riel Acked-by: Roman Gushchin Acked-by: Michal Hocko Acked-by: Johannes Weiner Acked-by: Chris Down Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 1b902d30d84d5d35db947872f9e90c0c935bb314 Author: Liu Zixian Date: Wed Sep 8 18:10:05 2021 -0700 mm/hugetlb: initialize hugetlb_usage in mm_init commit 13db8c50477d83ad3e3b9b0ae247e5cd833a7ae4 upstream. After fork, the child process will get incorrect (2x) hugetlb_usage. If a process uses 5 2MB hugetlb pages in an anonymous mapping, HugetlbPages: 10240 kB and then forks, the child will show, HugetlbPages: 20480 kB The reason for double the amount is because hugetlb_usage will be copied from the parent and then increased when we copy page tables from parent to child. Child will have 2x actual usage. Fix this by adding hugetlb_count_init in mm_init. Link: https://lkml.kernel.org/r/20210826071742.877-1-liuzixian4@huawei.com Fixes: 5d317b2b6536 ("mm: hugetlb: proc: add HugetlbPages field to /proc/PID/status") Signed-off-by: Liu Zixian Reviewed-by: Naoya Horiguchi Reviewed-by: Mike Kravetz Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9f8a2ed8875fe7b60bf18eaf11a78191d8659d54 Author: Li Zhijian Date: Wed Sep 8 18:10:02 2021 -0700 mm/hmm: bypass devmap pte when all pfn requested flags are fulfilled commit 4b42fb213678d2b6a9eeea92a9be200f23e49583 upstream. Previously, we noticed the one rpma example was failed[1] since commit 36f30e486dce ("IB/core: Improve ODP to use hmm_range_fault()"), where it will use ODP feature to do RDMA WRITE between fsdax files. After digging into the code, we found hmm_vma_handle_pte() will still return EFAULT even though all the its requesting flags has been fulfilled. That's because a DAX page will be marked as (_PAGE_SPECIAL | PAGE_DEVMAP) by pte_mkdevmap(). Link: https://github.com/pmem/rpma/issues/1142 [1] Link: https://lkml.kernel.org/r/20210830094232.203029-1-lizhijian@cn.fujitsu.com Fixes: 405506274922 ("mm/hmm: add missing call to hmm_pte_need_fault in HMM_PFN_SPECIAL handling") Signed-off-by: Li Zhijian Reviewed-by: Christoph Hellwig Reviewed-by: Jason Gunthorpe Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 65c7cdc921b8eb13300b8c722f8c4096cced68ef Author: David Hildenbrand Date: Tue Sep 7 19:54:59 2021 -0700 mm/memory_hotplug: use "unsigned long" for PFN in zone_for_pfn_range() commit 7cf209ba8a86410939a24cb1aeb279479a7e0ca6 upstream. Patch series "mm/memory_hotplug: preparatory patches for new online policy and memory" These are all cleanups and one fix previously sent as part of [1]: [PATCH v1 00/12] mm/memory_hotplug: "auto-movable" online policy and memory groups. These patches make sense even without the other series, therefore I pulled them out to make the other series easier to digest. [1] https://lkml.kernel.org/r/20210607195430.48228-1-david@redhat.com This patch (of 4): Checkpatch complained on a follow-up patch that we are using "unsigned" here, which defaults to "unsigned int" and checkpatch is correct. As we will search for a fitting zone using the wrong pfn, we might end up onlining memory to one of the special kernel zones, such as ZONE_DMA, which can end badly as the onlined memory does not satisfy properties of these zones. Use "unsigned long" instead, just as we do in other places when handling PFNs. This can bite us once we have physical addresses in the range of multiple TB. Link: https://lkml.kernel.org/r/20210712124052.26491-2-david@redhat.com Fixes: e5e689302633 ("mm, memory_hotplug: display allowed zones in the preferred ordering") Signed-off-by: David Hildenbrand Reviewed-by: Pankaj Gupta Reviewed-by: Muchun Song Reviewed-by: Oscar Salvador Cc: David Hildenbrand Cc: Vitaly Kuznetsov Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Pankaj Gupta Cc: Wei Yang Cc: Michal Hocko Cc: Dan Williams Cc: Anshuman Khandual Cc: Dave Hansen Cc: Vlastimil Babka Cc: Mike Rapoport Cc: "Rafael J. Wysocki" Cc: Len Brown Cc: Pavel Tatashin Cc: Heiko Carstens Cc: Michael Ellerman Cc: Catalin Marinas Cc: virtualization@lists.linux-foundation.org Cc: Andy Lutomirski Cc: "Aneesh Kumar K.V" Cc: Anton Blanchard Cc: Ard Biesheuvel Cc: Baoquan He Cc: Benjamin Herrenschmidt Cc: Borislav Petkov Cc: Christian Borntraeger Cc: Christophe Leroy Cc: Dave Jiang Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jia He Cc: Joe Perches Cc: Kefeng Wang Cc: Laurent Dufour Cc: Michel Lespinasse Cc: Nathan Lynch Cc: Nicholas Piggin Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Pierre Morel Cc: "Rafael J. Wysocki" Cc: Rich Felker Cc: Scott Cheloha Cc: Sergei Trofimovich Cc: Thiago Jung Bauermann Cc: Thomas Gleixner Cc: Vasily Gorbik Cc: Vishal Verma Cc: Will Deacon Cc: Yoshinori Sato Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit e25b227e947498c6d51d1ed08470752a8a1a7783 Author: Mike Kravetz Date: Thu Sep 2 14:58:53 2021 -0700 hugetlb: fix hugetlb cgroup refcounting during vma split commit 09a26e832705fdb7a9484495b71a05e0bbc65207 upstream. Guillaume Morin reported hitting the following WARNING followed by GPF or NULL pointer deference either in cgroups_destroy or in the kill_css path.: percpu ref (css_release) <= 0 (-1) after switching to atomic WARNING: CPU: 23 PID: 130 at lib/percpu-refcount.c:196 percpu_ref_switch_to_atomic_rcu+0x127/0x130 CPU: 23 PID: 130 Comm: ksoftirqd/23 Kdump: loaded Tainted: G O 5.10.60 #1 RIP: 0010:percpu_ref_switch_to_atomic_rcu+0x127/0x130 Call Trace: rcu_core+0x30f/0x530 rcu_core_si+0xe/0x10 __do_softirq+0x103/0x2a2 run_ksoftirqd+0x2b/0x40 smpboot_thread_fn+0x11a/0x170 kthread+0x10a/0x140 ret_from_fork+0x22/0x30 Upon further examination, it was discovered that the css structure was associated with hugetlb reservations. For private hugetlb mappings the vma points to a reserve map that contains a pointer to the css. At mmap time, reservations are set up and a reference to the css is taken. This reference is dropped in the vma close operation; hugetlb_vm_op_close. However, if a vma is split no additional reference to the css is taken yet hugetlb_vm_op_close will be called twice for the split vma resulting in an underflow. Fix by taking another reference in hugetlb_vm_op_open. Note that the reference is only taken for the owner of the reserve map. In the more common fork case, the pointer to the reserve map is cleared for non-owning vmas. Link: https://lkml.kernel.org/r/20210830215015.155224-1-mike.kravetz@oracle.com Fixes: e9fe92ae0cd2 ("hugetlb_cgroup: add reservation accounting for private mappings") Signed-off-by: Mike Kravetz Reported-by: Guillaume Morin Suggested-by: Guillaume Morin Tested-by: Guillaume Morin Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dba814c680f832aeabb24b71c2b4d20bb60c093d Author: Michael Wang Date: Thu Sep 2 14:58:40 2021 -0700 mm: fix panic caused by __page_handle_poison() commit f87060d345232c7d855167a43faf006e24afa999 upstream. In commit 510d25c92ec4 ("mm/hwpoison: disable pcp for page_handle_poison()"), __page_handle_poison() was introduced, and if we mark: RET_A = dissolve_free_huge_page(); RET_B = take_page_off_buddy(); then __page_handle_poison was supposed to return TRUE When RET_A == 0 && RET_B == TRUE But since it failed to take care the case when RET_A is -EBUSY or -ENOMEM, and just return the ret as a bool which actually become TRUE, it break the original logic. The following result is a huge page in freelist but was referenced as poisoned, and lead into the final panic: kernel BUG at mm/internal.h:95! invalid opcode: 0000 [#1] SMP PTI skip... RIP: 0010:set_page_refcounted mm/internal.h:95 [inline] RIP: 0010:remove_hugetlb_page+0x23c/0x240 mm/hugetlb.c:1371 skip... Call Trace: remove_pool_huge_page+0xe4/0x110 mm/hugetlb.c:1892 return_unused_surplus_pages+0x8d/0x150 mm/hugetlb.c:2272 hugetlb_acct_memory.part.91+0x524/0x690 mm/hugetlb.c:4017 This patch replaces 'bool' with 'int' to handle RET_A correctly. Link: https://lkml.kernel.org/r/61782ac6-1e8a-4f6f-35e6-e94fce3b37f5@linux.alibaba.com Fixes: 510d25c92ec4 ("mm/hwpoison: disable pcp for page_handle_poison()") Signed-off-by: Michael Wang Acked-by: Naoya Horiguchi Reported-by: Abaci Cc: [5.14+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 61dcf4761bc3ba9ba2952b2dad07dfe3165fb7a3 Author: Sven Schnelle Date: Fri Aug 27 20:21:05 2021 +0200 s390/topology: fix topology information when calling cpu hotplug notifiers commit a052096bdd6809eeab809202726634d1ac975aa1 upstream. The cpu hotplug notifiers are called without updating the core/thread masks when a new CPU is added. This causes problems with code setting up data structures in a cpu hotplug notifier, and relying on that later in normal code. This caused a crash in the new core scheduling code (SCHED_CORE), where rq->core was set up in a notifier depending on cpu masks. To fix this, add a cpu_setup_mask which is used in update_cpu_masks() instead of the cpu_online_mask to determine whether the cpu masks should be set for a certain cpu. Also move update_cpu_masks() to update the masks before calling notify_cpu_starting() so that the notifiers are seeing the updated masks. Signed-off-by: Sven Schnelle Cc: [hca@linux.ibm.com: get rid of cpu_online_mask handling] Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit e3f3cde1b40c794c48cb2a91b00f7dc262e66d00 Author: Halil Pasic Date: Sat Jul 24 01:17:46 2021 +0200 s390/pv: fix the forcing of the swiotlb commit 93ebb6828723b8aef114415c4dc3518342f7dcad upstream. Since commit 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing") if code sets swiotlb_force it needs to do so before the swiotlb is initialised. Otherwise io_tlb_default_mem->force_bounce will not get set to true, and devices that use (the default) swiotlb will not bounce despite switolb_force having the value of SWIOTLB_FORCE. Let us restore swiotlb functionality for PV by fulfilling this new requirement. This change addresses what turned out to be a fragility in commit 64e1f0c531d1 ("s390/mm: force swiotlb for protected virtualization"), which ain't exactly broken in its original context, but could give us some more headache if people backport the broken change and forget this fix. Signed-off-by: Halil Pasic Tested-by: Christian Borntraeger Reviewed-by: Christian Borntraeger Fixes: 903cd0f315fe ("swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing") Fixes: 64e1f0c531d1 ("s390/mm: force swiotlb for protected virtualization") Cc: stable@vger.kernel.org #5.3+ Signed-off-by: Konrad Rzeszutek Wilk Signed-off-by: Greg Kroah-Hartman commit e396c5dd27c02599c45461dbff5f1cbb4004b74f Author: Pratik R. Sampat Date: Wed Jul 28 17:35:00 2021 +0530 cpufreq: powernv: Fix init_chip_info initialization in numa=off commit f34ee9cb2c5ac5af426fee6fa4591a34d187e696 upstream. In the numa=off kernel command-line configuration init_chip_info() loops around the number of chips and attempts to copy the cpumask of that node which is NULL for all iterations after the first chip. Hence, store the cpu mask for each chip instead of derving cpumask from node while populating the "chips" struct array and copy that to the chips[i].mask Fixes: 053819e0bf84 ("cpufreq: powernv: Handle throttling due to Pmax capping at chip level") Cc: stable@vger.kernel.org # v4.3+ Reported-by: Shirisha Ganta Signed-off-by: Pratik R. Sampat Reviewed-by: Gautham R. Shenoy [mpe: Rename goto label to out_free_chip_cpu_mask] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210728120500.87549-2-psampat@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 5be8cf14460c3716fe087630d0a68871077d032b Author: Evgeny Novikov Date: Tue Aug 17 12:29:30 2021 +0300 mtd: rawnand: intel: Fix error handling in probe commit 0792ec82175ec45a0f45af6e0f2d3cb49c527cd4 upstream. ebu_nand_probe() did not invoke ebu_dma_cleanup() and clk_disable_unprepare() on some error handling paths. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Fixes: 0b1039f016e8 ("mtd: rawnand: Add NAND controller support on Intel LGM SoC") Signed-off-by: Evgeny Novikov Co-developed-by: Kirill Shilimanov Signed-off-by: Kirill Shilimanov Co-developed-by: Anton Vasilyev Signed-off-by: Anton Vasilyev Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210817092930.23040-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman commit 2c5528d5b246888751951559896065e1703eb6e4 Author: Saurav Kashyap Date: Mon Aug 9 21:37:19 2021 -0700 scsi: qla2xxx: Sync queue idx with queue_pair_map idx commit c8fadf019964d0eb1da410ba8b629494d3339db9 upstream. The first invocation of function find_first_zero_bit will return 0 and queue_id gets set to 0. An index of queue_pair_map also gets set to 0. qpair_id = find_first_zero_bit(ha->qpair_qid_map, ha->max_qpairs); set_bit(qpair_id, ha->qpair_qid_map); ha->queue_pair_map[qpair_id] = qpair; In the alloc_queue callback driver checks the map, if queue is already allocated: ha->queue_pair_map[qidx] This works fine as long as max_qpairs is greater than nvme_max_hw_queues(8) since the size of the queue_pair_map is equal to max_qpair. In case nr_cpus is less than 8, max_qpairs is less than 8. This creates wrong value returned as qpair. [ 1572.353669] qla2xxx [0000:24:00.3]-2121:6: Returning existing qpair of 4e00000000000000 for idx=2 [ 1572.354458] general protection fault: 0000 [#1] SMP PTI [ 1572.354461] CPU: 1 PID: 44 Comm: kworker/1:1H Kdump: loaded Tainted: G IOE --------- - - 4.18.0-304.el8.x86_64 #1 [ 1572.354462] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 03/01/2013 [ 1572.354467] Workqueue: kblockd blk_mq_run_work_fn [ 1572.354485] RIP: 0010:qla_nvme_post_cmd+0x92/0x760 [qla2xxx] [ 1572.354486] Code: 84 24 5c 01 00 00 00 00 b8 0a 74 1e 66 83 79 48 00 0f 85 a8 03 00 00 48 8b 44 24 08 48 89 ee 4c 89 e7 8b 50 24 e8 5e 8e 00 00 41 ff 47 04 0f ae f0 41 f6 47 24 04 74 19 f0 41 ff 4f 04 b8 f0 [ 1572.354487] RSP: 0018:ffff9c81c645fc90 EFLAGS: 00010246 [ 1572.354489] RAX: 0000000000000001 RBX: ffff8ea3e5070138 RCX: 0000000000000001 [ 1572.354490] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff8ea4c866b800 [ 1572.354491] RBP: ffff8ea4c866b800 R08: 0000000000005010 R09: ffff8ea4c866b800 [ 1572.354492] R10: 0000000000000001 R11: 000000069d1ca3ff R12: ffff8ea4bc460000 [ 1572.354493] R13: ffff8ea3e50702b0 R14: ffff8ea4c4c16a58 R15: 4e00000000000000 [ 1572.354494] FS: 0000000000000000(0000) GS:ffff8ea4dfd00000(0000) knlGS:0000000000000000 [ 1572.354495] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1572.354496] CR2: 000055884504fa58 CR3: 00000005a1410001 CR4: 00000000000606e0 [ 1572.354497] Call Trace: [ 1572.354503] ? check_preempt_curr+0x62/0x90 [ 1572.354506] ? dma_direct_map_sg+0x72/0x1f0 [ 1572.354509] ? nvme_fc_start_fcp_op.part.32+0x175/0x460 [nvme_fc] [ 1572.354511] ? blk_mq_dispatch_rq_list+0x11c/0x730 [ 1572.354515] ? __switch_to_asm+0x35/0x70 [ 1572.354516] ? __switch_to_asm+0x41/0x70 [ 1572.354518] ? __switch_to_asm+0x35/0x70 [ 1572.354519] ? __switch_to_asm+0x41/0x70 [ 1572.354521] ? __switch_to_asm+0x35/0x70 [ 1572.354522] ? __switch_to_asm+0x41/0x70 [ 1572.354523] ? __switch_to_asm+0x35/0x70 [ 1572.354525] ? entry_SYSCALL_64_after_hwframe+0xb9/0xca [ 1572.354527] ? __switch_to_asm+0x41/0x70 [ 1572.354529] ? __blk_mq_sched_dispatch_requests+0xc6/0x170 [ 1572.354531] ? blk_mq_sched_dispatch_requests+0x30/0x60 [ 1572.354532] ? __blk_mq_run_hw_queue+0x51/0xd0 [ 1572.354535] ? process_one_work+0x1a7/0x360 [ 1572.354537] ? create_worker+0x1a0/0x1a0 [ 1572.354538] ? worker_thread+0x30/0x390 [ 1572.354540] ? create_worker+0x1a0/0x1a0 [ 1572.354541] ? kthread+0x116/0x130 [ 1572.354543] ? kthread_flush_work_fn+0x10/0x10 [ 1572.354545] ? ret_from_fork+0x35/0x40 Fix is to use index 0 for admin and first IO queue. Link: https://lore.kernel.org/r/20210810043720.1137-14-njavali@marvell.com Fixes: e84067d74301 ("scsi: qla2xxx: Add FC-NVMe F/W initialization and transport registration") Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5e5a55a25297e0c1d5382432897157f82271c392 Author: Saurav Kashyap Date: Mon Aug 9 21:37:17 2021 -0700 scsi: qla2xxx: Changes to support kdump kernel commit 62e0dec59c1e139dab55aff5aa442adc97804271 upstream. Avoid allocating firmware dump and only allocate a single queue for a kexec kernel. Link: https://lore.kernel.org/r/20210810043720.1137-12-njavali@marvell.com Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Saurav Kashyap Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 23f16034bef0bfe5b707faaa3e4762b671893135 Author: Maciej W. Rozycki Date: Tue Apr 20 20:01:47 2021 +0200 scsi: BusLogic: Fix missing pr_cont() use commit 44d01fc86d952f5a8b8b32bdb4841504d5833d95 upstream. Update BusLogic driver's messaging system to use pr_cont() for continuation lines, bringing messy output: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic , Untagged Queue Depth: 3 scsi0: SCSI Bus Termination: Both Enabled , SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi host0: BusLogic BT-958 back to order: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter scsi0: Firmware Version: 5.07B, I/O Address: 0x7000, IRQ Channel: 17/Level scsi0: PCI Bus: 0, Device: 19, Address: 0xE0012000, Host Adapter SCSI ID: 7 scsi0: Parity Checking: Enabled, Extended Translation: Enabled scsi0: Synchronous Negotiation: Ultra, Wide Negotiation: Enabled scsi0: Disconnect/Reconnect: Enabled, Tagged Queuing: Enabled scsi0: Scatter/Gather Limit: 128 of 8192 segments, Mailboxes: 211 scsi0: Driver Queue Depth: 211, Host Adapter Queue Depth: 192 scsi0: Tagged Queue Depth: Automatic, Untagged Queue Depth: 3 scsi0: SCSI Bus Termination: Both Enabled, SCAM: Disabled scsi0: *** BusLogic BT-958 Initialized Successfully *** scsi host0: BusLogic BT-958 Also diagnostic output such as with the BusLogic=TraceConfiguration parameter is affected and becomes vertical and therefore hard to read. This has now been corrected, e.g.: pci 0000:00:13.0: PCI->APIC IRQ transform: INT A -> IRQ 17 blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00 blogic_cmd(95) Status = 28: (Modify I/O Address) blogic_cmd(91) Status = 30: 1 ==> 1: 01 blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30 blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D scsi: ***** BusLogic SCSI Driver Version 2.1.17 of 12 September 2013 ***** scsi: Copyright 1995-1998 by Leonard N. Zubkoff blogic_cmd(04) Status = 30: 4 ==> 4: 41 41 35 30 blogic_cmd(0B) Status = 30: 3 ==> 3: 00 08 07 blogic_cmd(0D) Status = 30: 34 ==> 34: 03 01 07 04 00 00 00 00 00 00 00 00 00 00 00 00 FF 42 44 46 FF 00 00 00 00 00 00 00 00 00 FF 00 FF 00 blogic_cmd(8D) Status = 30: 14 ==> 14: 45 DC 00 20 00 00 00 00 00 40 30 37 42 1D blogic_cmd(84) Status = 30: 1 ==> 1: 37 blogic_cmd(8B) Status = 30: 5 ==> 5: 39 35 38 20 20 blogic_cmd(85) Status = 30: 1 ==> 1: 42 blogic_cmd(86) Status = 30: 4 ==> 4: FF 05 93 00 blogic_cmd(91) Status = 30: 64 ==> 64: 41 46 3E 20 39 35 38 20 20 00 C4 00 04 01 07 2F 07 04 35 FF FF FF FF FF FF FF FF FF FF 01 00 FE FF 08 FF FF 00 00 00 00 00 00 00 01 00 01 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 FC scsi0: Configuring BusLogic Model BT-958 PCI Wide Ultra SCSI Host Adapter etc. Link: https://lore.kernel.org/r/alpine.DEB.2.21.2104201940430.44318@angie.orcam.me.uk Fixes: 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing continuation lines") Cc: stable@vger.kernel.org # v4.9+ Acked-by: Khalid Aziz Signed-off-by: Maciej W. Rozycki Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 665209a2fc0f908d729fdcb00fdce1efdd21a841 Author: chenying Date: Mon Aug 16 18:02:56 2021 +0800 ovl: fix BUG_ON() in may_delete() when called from ovl_cleanup() commit 52d5a0c6bd8a89f460243ed937856354f8f253a3 upstream. If function ovl_instantiate() returns an error, ovl_cleanup will be called and try to remove newdentry from wdir, but the newdentry has been moved to udir at this time. This will causes BUG_ON(victim->d_parent->d_inode != dir) in fs/namei.c:may_delete. Signed-off-by: chenying Fixes: 01b39dcc9568 ("ovl: use inode_insert5() to hash a newly created inode") Link: https://lore.kernel.org/linux-unionfs/e6496a94-a161-dc04-c38a-d2544633acb4@bytedance.com/ Cc: # v4.18 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit b40317da6f4aa58f1c9aae2f8589e26f509cac42 Author: Petr Mladek Date: Fri Jul 2 17:06:57 2021 +0200 printk/console: Check consistent sequence number when handling race in console_unlock() commit 11e4b63abbe23872b45f325a7c6c8b7f9ff42cad upstream. The standard printk() tries to flush the message to the console immediately. It tries to take the console lock. If the lock is already taken then the current owner is responsible for flushing even the new message. There is a small race window between checking whether a new message is available and releasing the console lock. It is solved by re-checking the state after releasing the console lock. If the check is positive then console_unlock() tries to take the lock again and process the new message as well. The commit 996e966640ddea7b535c ("printk: remove logbuf_lock") causes that console_seq is not longer read atomically. As a result, the re-check might be done with an inconsistent 64-bit index. Solve it by using the last sequence number that has been checked under the console lock. In the worst case, it will take the lock again only to realized that the new message has already been proceed. But it was possible even before. The variable next_seq is marked as __maybe_unused to call down compiler warning when CONFIG_PRINTK is not defined. Fixes: commit 996e966640ddea7b535c ("printk: remove logbuf_lock") Reported-by: kernel test robot # unused next_seq warning Cc: stable@vger.kernel.org # 5.13 Signed-off-by: Petr Mladek Acked-by: Sergey Senozhatsky Reviewed-by: John Ogness Link: https://lore.kernel.org/r/20210702150657.26760-1-pmladek@suse.com Signed-off-by: Greg Kroah-Hartman commit 4b5b4fd3ad27623a2661cfe4cea9715226c446ce Author: Masahiro Yamada Date: Thu Jun 10 11:03:31 2021 +0900 parisc: Fix compile failure when building 64-bit kernel natively commit 5f6e0fe01b6b33894cf6f61b359ab5a6d2b7674e upstream. Commit 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") broke 64-bit parisc builds on 32-bit parisc systems. Helge mentioned: - 64-bit parisc userspace is not supported yet [1] - hppa gcc does not support "-m64" flag [2] That means, parisc developers working on a 32-bit parisc machine need to use hppa64-linux-gnu-gcc (cross compiler) for building the 64-bit parisc kernel. After the offending commit, gcc is used in such a case because both $(SRCARCH) and $(SUBARCH) are 'parisc', hence cross_compiling is unset. A correct way is to introduce ARCH=parisc64 because building the 64-bit parisc kernel on a 32-bit parisc system is not exactly a native build, but rather a semi-cross build. [1]: https://lore.kernel.org/linux-parisc/5dfd81eb-c8ca-b7f5-e80e-8632767c022d@gmx.de/#t [2]: https://lore.kernel.org/linux-parisc/89515325-fc21-31da-d238-6f7a9abbf9a0@gmx.de/ Fixes: 23243c1ace9f ("arch: use cross_compiling to check whether it is a cross build or not") Signed-off-by: Masahiro Yamada Reported-by: Meelis Roos Tested-by: Meelis Roos Cc: # v5.13+ Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 39a86000c52b45d04e5cad4c958bb63d79666252 Author: Mikulas Patocka Date: Mon Aug 30 05:42:27 2021 -0400 parisc: fix crash with signals and alloca commit 030f653078316a9cc9ca6bd1b0234dcf858be35d upstream. I was debugging some crashes on parisc and I found out that there is a crash possibility if a function using alloca is interrupted by a signal. The reason for the crash is that the gcc alloca implementation leaves garbage in the upper 32 bits of the sp register. This normally doesn't matter (the upper bits are ignored because the PSW W-bit is clear), however the signal delivery routine in the kernel uses full 64 bits of sp and it fails with -EFAULT if the upper 32 bits are not zero. I created this program that demonstrates the problem: #include #include #include #include static __attribute__((noinline,noclone)) void aa(int *size) { void * volatile p = alloca(-*size); while (1) ; } static void handler(int sig) { write(1, "signal delivered\n", 17); _exit(0); } int main(void) { int size = -0x100; signal(SIGALRM, handler); alarm(1); aa(&size); } If you compile it with optimizations, it will crash. The "aa" function has this disassembly: 000106a0 : 106a0: 08 03 02 41 copy r3,r1 106a4: 08 1e 02 43 copy sp,r3 106a8: 6f c1 00 80 stw,ma r1,40(sp) 106ac: 37 dc 3f c1 ldo -20(sp),ret0 106b0: 0c 7c 12 90 stw ret0,8(r3) 106b4: 0f 40 10 9c ldw 0(r26),ret0 ; ret0 = 0x00000000FFFFFF00 106b8: 97 9c 00 7e subi 3f,ret0,ret0 ; ret0 = 0xFFFFFFFF0000013F 106bc: d7 80 1c 1a depwi 0,31,6,ret0 ; ret0 = 0xFFFFFFFF00000100 106c0: 0b 9e 0a 1e add,l sp,ret0,sp ; sp = 0xFFFFFFFFxxxxxxxx 106c4: e8 1f 1f f7 b,l,n 106c4 ,r0 This patch fixes the bug by truncating the "usp" variable to 32 bits. Signed-off-by: Mikulas Patocka Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 5a129cba88811fdf67a875b2b4bab4fc33104877 Author: Guojia Liao Date: Mon Aug 30 21:51:07 2021 +0800 net: hns3: clean up a type mismatch warning [ Upstream commit e79c0e324b011b0288cd411a5b53870a7730f163 ] abs() returns signed long, which could not convert the type as unsigned, and it may cause a mismatch type warning from static tools. To fix it, this patch uses an variable to save the abs()'s result and does a explicit conversion. Signed-off-by: Guojia Liao Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c9836c4419f374080b893937f92932e8d06de61 Author: Yang Yingliang Date: Tue Aug 31 16:40:18 2021 +0800 net: w5100: check return value after calling platform_get_resource() [ Upstream commit a39ff4a47f3e1da3b036817ef436b1a9be10783a ] It will cause null-ptr-deref if platform_get_resource() returns NULL, we need check the return value. Signed-off-by: Yang Yingliang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 305be1931191006f3bf033502064b5bdc493eda6 Author: Haimin Zhang Date: Mon Aug 30 11:47:01 2021 +0800 fix array-index-out-of-bounds in taprio_change [ Upstream commit efe487fce3061d94222c6501d7be3aa549b3dc78 ] syzbot report an array-index-out-of-bounds in taprio_change index 16 is out of range for type '__u16 [16]' that's because mqprio->num_tc is lager than TC_MAX_QUEUE,so we check the return value of netdev_set_num_tc. Reported-by: syzbot+2b3e5fb6c7ef285a94f6@syzkaller.appspotmail.com Signed-off-by: Haimin Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7b0c4a66979424b70a74277ea2abbd87bf0e5cff Author: 王贇 Date: Mon Aug 30 18:28:01 2021 +0800 net: fix NULL pointer reference in cipso_v4_doi_free [ Upstream commit e842cb60e8ac1d8a15b01e0dd4dad453807a597d ] In netlbl_cipsov4_add_std() when 'doi_def->map.std' alloc failed, we sometime observe panic: BUG: kernel NULL pointer dereference, address: ... RIP: 0010:cipso_v4_doi_free+0x3a/0x80 ... Call Trace: netlbl_cipsov4_add_std+0xf4/0x8c0 netlbl_cipsov4_add+0x13f/0x1b0 genl_family_rcv_msg_doit.isra.15+0x132/0x170 genl_rcv_msg+0x125/0x240 This is because in cipso_v4_doi_free() there is no check on 'doi_def->map.std' when doi_def->type got value 1, which is possibe, since netlbl_cipsov4_add_std() haven't initialize it before alloc 'doi_def->map.std'. This patch just add the check to prevent panic happen in similar cases. Reported-by: Abaci Signed-off-by: Michael Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 92203cad2e7d5786ae358dbc2feaeacae8842c48 Author: Miaoqing Pan Date: Mon Aug 9 12:05:16 2021 +0800 ath9k: fix sleeping in atomic context [ Upstream commit 7c48662b9d56666219f526a71ace8c15e6e12f1f ] The problem is that gpio_free() can sleep and the cfg_soc() can be called with spinlocks held. One problematic call tree is: --> ath_reset_internal() takes &sc->sc_pcu_lock spin lock --> ath9k_hw_reset() --> ath9k_hw_gpio_request_in() --> ath9k_hw_gpio_request() --> ath9k_hw_gpio_cfg_soc() Remove gpio_free(), use error message instead, so we should make sure there is no GPIO conflict. Also remove ath9k_hw_gpio_free() from ath9k_hw_apply_gpio_override(), as gpio_mask will never be set for SOC chips. Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1628481916-15030-1-git-send-email-miaoqing@codeaurora.org Signed-off-by: Sasha Levin commit 047bd61b49cd88e7353d0e3e2b186be38baf1e90 Author: Zekun Shen Date: Sat Jun 19 09:29:14 2021 -0400 ath9k: fix OOB read ar9300_eeprom_restore_internal [ Upstream commit 23151b9ae79e3bc4f6a0c4cd3a7f355f68dad128 ] Bad header can have large length field which can cause OOB. cptr is the last bytes for read, and the eeprom is parsed from high to low address. The OOB, triggered by the condition length > cptr could cause memory error with a read on negative index. There are some sanity check around length, but it is not compared with cptr (the remaining bytes). Here, the corrupted/bad EEPROM can cause panic. I was able to reproduce the crash, but I cannot find the log and the reproducer now. After I applied the patch, the bug is no longer reproducible. Signed-off-by: Zekun Shen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YM3xKsQJ0Hw2hjrc@Zekuns-MBP-16.fios-router.home Signed-off-by: Sasha Levin commit 737e28aceecf621ad74b29b9d5ee1276139c0d66 Author: Loic Poulain Date: Thu Aug 26 17:46:08 2021 +0200 wcn36xx: Fix missing frame timestamp for beacon/probe-resp [ Upstream commit 8678fd31f2d3eb14f2b8b39c9bc266f16fa24b22 ] When receiving a beacon or probe response, we should update the boottime_ns field which is the timestamp the frame was received at. (cf mac80211.h) This fixes a scanning issue with Android since it relies on this timestamp to determine when the AP has been seen for the last time (via the nl80211 BSS_LAST_SEEN_BOOTTIME parameter). Signed-off-by: Loic Poulain Reviewed-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1629992768-23785-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit 2d1209b84e4547cb8de4801a84b0d20b69ad9eaa Author: Chengfeng Ye Date: Fri Aug 27 00:41:40 2021 -0700 selftests/bpf: Fix potential unreleased lock [ Upstream commit 47bb27a20d6ea22cd092c1fc2bb4fcecac374838 ] This lock is not released if the program return at the patched branch. Signed-off-by: Chengfeng Ye Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210827074140.118671-1-cyeaa@connect.ust.hk Signed-off-by: Sasha Levin commit 10e1b6c0129eca0e09fcee84d9b33c8e5ad1d2aa Author: Colin Ian King Date: Fri Jul 30 11:07:10 2021 +0100 parport: remove non-zero check on count [ Upstream commit 0be883a0d795d9146f5325de582584147dd0dcdc ] The check for count appears to be incorrect since a non-zero count check occurs a couple of statements earlier. Currently the check is always false and the dev->port->irq != PARPORT_IRQ_NONE part of the check is never tested and the if statement is dead-code. Fix this by removing the check on count. Note that this code is pre-git history, so I can't find a sha for it. Acked-by: Sudip Mukherjee Signed-off-by: Colin Ian King Addresses-Coverity: ("Logically dead code") Link: https://lore.kernel.org/r/20210730100710.27405-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f57504d023d48efa5158d6de7a1a95e958f16190 Author: Rui Miguel Silva Date: Fri Aug 27 14:11:54 2021 +0100 usb: isp1760: otg control register access [ Upstream commit 9c1587d99f9305aa4f10b47fcf1981012aa5381f ] The set/clear of the otg control values is done writing to two different 16bit registers, however we setup the regmap width for isp1760/61 to 32bit value bits. So, just access the clear register address (0x376)as the high part of the otg control register set (0x374), and write the values in one go to make sure they get clear/set. Reported-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210827131154.4151862-6-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f46ac8d54f169dc0b0babe6165773de1b3e2e9cd Author: Rui Miguel Silva Date: Fri Aug 27 14:11:53 2021 +0100 usb: isp1760: use the right irq status bit [ Upstream commit 955d0fb590f18ec5c3a4085c7d0e39b6abde0dd6 ] Instead of using the fields enum values to check interrupts trigged, use the correct bit values. Reported-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210827131154.4151862-5-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 11228eee79ae78317644b59246cb4de195e00b2c Author: Rui Miguel Silva Date: Fri Aug 27 14:11:52 2021 +0100 usb: isp1760: write to status and address register [ Upstream commit 36815a4a0763bb405ebd776c45553005c1ef7a15 ] We were already writing directly the port status register to trigger changes in isp1763. The same is needed in other IP from the family, including also to setup the read address before reading from device. Reported-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210827131154.4151862-4-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4fa262026f7a98bbcd727230af24518fb35fb55d Author: Rui Miguel Silva Date: Fri Aug 27 14:11:51 2021 +0100 usb: isp1760: fix qtd fill length [ Upstream commit cbfa3effdf5c2d411c9ce9820f3d33d77bc4697d ] When trying to send bulks bigger than the biggest block size we need to split them over several qtd. Fix this limiting the maximum qtd size to largest block size. Reported-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210827131154.4151862-3-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce1ef4720ba547a14fd81454010f5e7dfe5d26d3 Author: Rui Miguel Silva Date: Fri Aug 27 14:11:50 2021 +0100 usb: isp1760: fix memory pool initialization [ Upstream commit f757f9291f920e1da4c6cfd4064c6bf59639983e ] The loops to setup the memory pool were skipping some blocks, that was not visible on the ISP1763 because it has fewer blocks than the ISP1761. But won testing on that IP from the family that would be an issue. Reported-by: Dietmar Eggemann Tested-by: Dietmar Eggemann Signed-off-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20210827131154.4151862-2-rui.silva@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c0b94df1a617b265ecd301feaf58985a0cc7e314 Author: Yevgeny Kliteynik Date: Thu Sep 24 20:58:50 2020 +0300 net/mlx5: DR, Enable QP retransmission [ Upstream commit ec449ed8230cd30769de3cb70ee0fce293047372 ] Under high stress, SW steering might get stuck on polling for completion that never comes. For such cases QP needs to have protocol retransmission mechanism enabled. Currently the retransmission timeout is defined as 0 (unlimited). Fix this by defining a real timeout. Signed-off-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 153979e597b1a6553609590ab196fdd38976aa1e Author: Wentao_Liang Date: Thu Aug 19 22:30:05 2021 +0800 net/mlx5: DR, fix a potential use-after-free bug [ Upstream commit 6cc64770fb386b10a64a1fe09328396de7bb5262 ] In line 849 (#1), "mlx5dr_htbl_put(cur_htbl);" drops the reference to cur_htbl and may cause cur_htbl to be freed. However, cur_htbl is subsequently used in the next line, which may result in an use-after-free bug. Fix this by calling mlx5dr_err() before the cur_htbl is put. Signed-off-by: Wentao_Liang Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit fbcfaf2aa98c7ec18155763a5403aeaf0dbd6612 Author: Ilan Peer Date: Thu Aug 26 22:47:42 2021 +0300 iwlwifi: mvm: Fix scan channel flags settings [ Upstream commit 090f1be3abf3069ef856b29761f181808bf55917 ] The iwl_mvm_scan_ch_n_aps_flag() is called with a variable before the value of the variable is set. Fix it. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210826224715.f6f188980a5e.Ie7331a8b94004d308f6cbde44e519155a5be91dd@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 81f63f2cb43e61af47856535d8ff7350a8ca9fa6 Author: Avraham Stern Date: Thu Aug 19 18:40:34 2021 +0300 iwlwifi: mvm: don't schedule the roc_done_wk if it is already running [ Upstream commit a76b57311b1a247e31b055872d021c38707dc3a8 ] When P2P roc is removed, the IWL_MVM_STATUS_NEED_FLUSH_P2P bit is set to indicate to iwl_mvm_roc_done_wk() that the removed roc is a P2P one, so it will flush the broadcast station and not the aux station. However, since setting this bit and scheduling the worker is done in roc ended flow as well as in case the roc is removed, there is a race where the worker has already started running (but did not test this bit yet) and then it is scheduled again. In this case, the first run of the worker will clear this bit, and thus the second run will find it already cleared and will try to flush and remove the aux station by mistake. Fix it by scheduling the worker only if this bit is not yet set. In case this bit is already set, the worker is either running or scheduled, so there is no need to re-schedule it. Signed-off-by: Avraham Stern Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210819183728.8c147659b331.If5924375e9bfd46214ab8ab81cb9d0f5c82fbcbc@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 536c99fb2d83521384723fbd88aaca272e201551 Author: Johannes Berg Date: Thu Aug 5 14:21:54 2021 +0300 iwlwifi: fw: correctly limit to monitor dump [ Upstream commit e6344c060209ef4e970cac18adeac1676a2a73cd ] In commit 79f033f6f229 ("iwlwifi: dbg: don't limit dump decisions to all or monitor") we changed the code to pass around a bitmap, but in the monitor_only case, one place accidentally used the bit number, not the bit mask, resulting in CSR and FW_INFO getting dumped instead of monitor data. Fix that. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210805141826.774fd8729a33.Ic985a787071d1c0b127ef0ba8367da896ee11f57@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 269c660786cb268a31f5b0c29c48f386fea1fd8a Author: Johannes Berg Date: Thu Aug 5 13:19:31 2021 +0300 iwlwifi: mvm: fix access to BSS elements [ Upstream commit 6c608cd6962ebdf84fd3de6d42f88ed64d2f4e1b ] BSS elements are protected using RCU, so we need to use RCU properly to access them, fix that. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210805130823.fd8b5791ab44.Iba26800a6301078d3782fb249c476dd8ac2bf3c6@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 39fc75bdad90ff53c929017a66f44e7ef799573c Author: Ilan Peer Date: Mon Aug 2 21:58:54 2021 +0300 iwlwifi: mvm: Fix umac scan request probe parameters [ Upstream commit 35fc5feca7b24b97e828e6e6a4243b4b9b0131f8 ] Both 'iwl_scan_probe_params_v3' and 'iwl_scan_probe_params_v4' wrongly addressed the 'bssid_array' field which should supposed to be any array of BSSIDs each of size ETH_ALEN and not the opposite. Fix it. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802215208.04146f24794f.I90726440ddff75013e9fecbe9fa1a05c69e3f17b@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 66017f11d475edaee60360f6ad1920220b5bf59a Author: Johannes Berg Date: Mon Aug 2 17:28:27 2021 +0300 iwlwifi: mvm: avoid static queue number aliasing [ Upstream commit c6ce1c74ef2923b8ffd85f7f8b486f804f343b39 ] When TVQM is enabled (iwl_mvm_has_new_tx_api() is true), then queue numbers are just sequentially assigned 0, 1, 2, ... Prior to TVQM, in DQA, there were some statically allocated queue numbers: * IWL_MVM_DQA_AUX_QUEUE == 1, * both IWL_MVM_DQA_INJECT_MONITOR_QUEUE and IWL_MVM_DQA_P2P_DEVICE_QUEUE == 2, and * IWL_MVM_DQA_AP_PROBE_RESP_QUEUE == 9. Now, these values are assigned to the members mvm->aux_queue, mvm->snif_queue, mvm->probe_queue and mvm->p2p_dev_queue by default. Normally, this doesn't really matter, and if TVQM is in fact available we override them to the real values after allocating a queue for use there. However, this allocation doesn't always happen. For example, for mvm->p2p_dev_queue (== 2) it only happens when the P2P Device interface is started, if any. If it's not started, the value in mvm->p2p_dev_queue remains 2. This wouldn't really matter all that much if it weren't for iwl_mvm_is_static_queue() which checks a queue number against one of those four static numbers. Now, if no P2P Device or monitor interface is added then queue 2 may be dynamically allocated, yet alias mvm->p2p_dev_queue or mvm->snif_queue, and thus iwl_mvm_is_static_queue() erroneously returns true for it. If it then gets full, all interface queues are stopped, instead of just backpressuring against the one TXQ that's really the only affected one. This clearly can lead to issues, as everything is stopped even if just a single TXQ filled its corresponding HW queue, if it happens to have an appropriate number (2 or 9, AUX is always reassigned.) Due to a mac80211 bug, this also led to a situation in which the queues remained stopped across a deauthentication and then attempts to connect to a new AP started failing, but that's fixed separately. Fix all of this by simply initializing the queue numbers to the invalid value until they're used, if TVQM is enabled, and also setting them back to that value when the queues are later freed again. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802172232.2e47e623f9e2.I9b0830dafbb68ef35b7b8f0f46160abec02ac7d0@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit c87815c18ad53537262606558335cf8198a97744 Author: Zhang Qilong Date: Mon Aug 2 17:28:24 2021 +0300 iwlwifi: mvm: fix a memory leak in iwl_mvm_mac_ctxt_beacon_changed [ Upstream commit 0f5d44ac6e55551798dd3da0ff847c8df5990822 ] If beacon_inject_active is true, we will return without freeing beacon. Fid that by freeing it before returning. Signed-off-by: Zhang Qilong [reworded the commit message] Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802172232.d16206ca60fc.I9984a9b442c84814c307cee3213044e24d26f38a@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 65faf06e4c541edd0500a0bac0b9ceec8c5dbf79 Author: Ilan Peer Date: Mon Aug 2 17:09:42 2021 +0300 iwlwifi: mvm: Do not use full SSIDs in 6GHz scan [ Upstream commit deedf9b97cd4ef45da476c9bdd2a5f3276053956 ] The scan request processing populated the direct SSIDs in the FW scan request command also for 6GHz scan, which is not needed and might result in unexpected behavior. Fix the code to add the direct SSIDs only in case the scan is not a 6GHz scan. Signed-off-by: Ilan Peer Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802170640.f465937c7bbf.Ic11a1659ddda850c3ec1b1afbe9e2b9577ac1800@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit ea30f0e3ceaf618a6cb3893f662c7eb2878315a6 Author: Johannes Berg Date: Mon Aug 2 17:09:38 2021 +0300 iwlwifi: pcie: free RBs during configure [ Upstream commit 6ac5720086c8b176794eb74c5cc09f8b79017f38 ] When switching op-modes, or more generally when reconfiguring, we might switch the RB size. In _iwl_pcie_rx_init() we have a comment saying we must free all RBs since we might switch the size, but this is actually too late: the switch has been done and we'll free the buffers with the wrong size. Fix this by always freeing the buffers, if any, at the start of configure, instead of only after the size may have changed. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20210802170640.42d7c93279c4.I07f74e65aab0e3d965a81206fcb289dc92d74878@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 2d23385df5f8c25d09c6d78b2a9042ff881d9f89 Author: J. Bruce Fields Date: Tue Aug 24 22:36:03 2021 -0400 nfsd: fix crash on LOCKT on reexported NFSv3 [ Upstream commit 0bcc7ca40bd823193224e9f38bafbd8325aaf566 ] Unlike other filesystems, NFSv3 tries to use fl_file in the GETLK case. Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit e97d534f3e32a69ae0e88334244ebfa6d8ae0620 Author: J. Bruce Fields Date: Fri Aug 20 17:02:04 2021 -0400 nfs: don't atempt blocking locks on nfs reexports [ Upstream commit f657f8eef3ff870552c9fd2839e0061046f44618 ] NFS implements blocking locks by blocking inside its lock method. In the reexport case, this blocks the nfs server thread, which could lead to deadlocks since an nfs server thread might be required to unlock the conflicting lock. It also causes a crash, since the nfs server thread assumes it can free the lock when its lm_notify lock callback is called. Ideal would be to make the nfs lock method return without blocking in this case, but for now it works just not to attempt blocking locks. The difference is just that the original client will have to poll (as it does in the v4.0 case) instead of getting a callback when the lock's available. Signed-off-by: J. Bruce Fields Acked-by: Anna Schumaker Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 6681aed438fa32d034b2e2f51a3453bb763b521f Author: Sean Keely Date: Thu Aug 19 21:26:14 2021 -0500 drm/amdkfd: Account for SH/SE count when setting up cu masks. [ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ] On systems with multiple SH per SE compute_static_thread_mgmt_se# is split into independent masks, one for each SH, in the upper and lower 16 bits. We need to detect this and apply cu masking to each SH. The cu mask bits are assigned first to each SE, then to alternate SHs, then finally to higher CU id. This ensures that the maximum number of SPIs are engaged as early as possible while balancing CU assignment to each SH. v2: Use max SH/SE rather than max SH in cu_per_sh. v3: Fix comment blocks, ensure se_mask is initially zero filled, and correctly assign se.sh.cu positions to unset bits in cu_mask. Signed-off-by: Sean Keely Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit acc8abff37288d92c671f05eab004147296abb13 Author: Pierre-Louis Bossart Date: Tue Aug 17 11:40:53 2021 -0500 ASoC: soc-pcm: protect BE dailink state changes in trigger [ Upstream commit 0c75fc7193387776c10f7c7b440d93496e3d5e21 ] When more than one FE is connected to a BE, e.g. in a mixing use case, the BE can be triggered multiple times when the FE are opened/started concurrently. This race condition is problematic in the case of SoundWire BE dailinks, and this is not desirable in a general case. The code carefully checks when the BE can be stopped or hw_free'ed, but the trigger code does not use any mutual exclusion. Fix by using the same spinlock already used to check FE states, and set the state before the trigger. In case of errors, the initial state will be restored. This patch does not change how the triggers are handled, it only makes sure the states are handled in critical sections. Signed-off-by: Pierre-Louis Bossart Message-Id: <20210817164054.250028-2-pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 46e8be79c91062b98ab253442b2d504c64c7d0b5 Author: Xiaotan Luo Date: Thu Aug 26 12:02:36 2021 +0800 ASoC: rockchip: i2s: Fixup config for DAIFMT_DSP_A/B [ Upstream commit 1bf56843e664eef2525bdbfae6a561e98910f676 ] - DSP_A: PCM delay 1 bit mode, L data MSB after FRM LRC - DSP_B: PCM no delay mode, L data MSB during FRM LRC Signed-off-by: Xiaotan Luo Signed-off-by: Sugar Zhang Link: https://lore.kernel.org/r/1629950562-14281-3-git-send-email-sugar.zhang@rock-chips.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 892844b73d94c15d7338bc9c63b4e0697cf89185 Author: Sugar Zhang Date: Thu Aug 26 12:01:50 2021 +0800 ASoC: rockchip: i2s: Fix regmap_ops hang [ Upstream commit 53ca9b9777b95cdd689181d7c547e38dc79adad0 ] API 'set_fmt' maybe called when PD is off, in the situation, any register access will hang the system. so, enable PD before r/w register. Signed-off-by: Sugar Zhang Link: https://lore.kernel.org/r/1629950520-14190-4-git-send-email-sugar.zhang@rock-chips.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7dfd0e3c8b40dd810c4341e17e8b39a7d3d2f298 Author: Chunfeng Yun Date: Thu Aug 26 10:51:43 2021 +0800 usb: xhci-mtk: Do not use xhci's virt_dev in drop_endpoint [ Upstream commit b8731209958a1dffccc2888121f4c0280c990550 ] xhci-mtk depends on xhci's internal virt_dev when it retrieves its internal data from usb_host_endpoint both in add_endpoint and drop_endpoint callbacks. But when setup packet was retired by transaction errors in xhci_setup_device() path, a virt_dev for the slot is newly created with real_port 0. This leads to xhci-mtks's NULL pointer dereference from drop_endpoint callback as xhci-mtk assumes that virt_dev's real_port is always started from one. The similar problems were addressed by [1] but that can't cover the failure cases from setup_device. This patch drops the usages of xhci's virt_dev in xhci-mtk's drop_endpoint callback by adopting rhashtable for searching mtk's schedule entity from a given usb_host_endpoint pointer instead of searching a linked list. So mtk's drop_endpoint callback doesn't have to rely on virt_dev at all. [1] https://lore.kernel.org/r/1617179142-2681-2-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Ikjoon Jang Link: https://lore.kernel.org/r/20210805133731.1.Icc0f080e75b1312692d4c7c7d25e7df9fe1a05c2@changeid Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8382463047e6901f02a900a16b52030c593922f3 Author: Chunfeng Yun Date: Tue Aug 17 16:36:23 2021 +0800 usb: xhci-mtk: fix use-after-free of mtk->hcd [ Upstream commit 7f85c16f40d8be5656fb3476909db5c3a5a9c6ea ] BUG: KASAN: use-after-free in usb_hcd_is_primary_hcd+0x38/0x60 Call trace: dump_backtrace+0x0/0x3dc show_stack+0x20/0x2c dump_stack+0x15c/0x1d4 print_address_description+0x7c/0x510 kasan_report+0x164/0x1ac __asan_report_load8_noabort+0x44/0x50 usb_hcd_is_primary_hcd+0x38/0x60 xhci_mtk_runtime_suspend+0x68/0x148 pm_generic_runtime_suspend+0x90/0xac __rpm_callback+0xb8/0x1f4 rpm_callback+0x54/0x1d0 rpm_suspend+0x4e0/0xc84 __pm_runtime_suspend+0xc4/0x114 xhci_mtk_probe+0xa58/0xd00 This may happen when probe fails, needn't suspend it synchronously, fix it by using pm_runtime_put_noidle(). Reported-by: Pi Hsun Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1629189389-18779-3-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6cd9365b0285525d8cd4ec3c54fbdd91bf41a1a Author: Shuah Khan Date: Thu Aug 19 16:59:37 2021 -0600 usbip:vhci_hcd USB port can get stuck in the disabled state [ Upstream commit 66cce9e73ec61967ed1f97f30cee79bd9a2bb7ee ] When a remote usb device is attached to the local Virtual USB Host Controller Root Hub port, the bound device driver may send a port reset command. vhci_hcd accepts port resets only when the device doesn't have port address assigned to it. When reset happens device is in assigned/used state and vhci_hcd rejects it leaving the port in a stuck state. This problem was found when a blue-tooth or xbox wireless dongle was passed through using usbip. A few drivers reset the port during probe including mt76 driver specific to this bug report. Fix the problem with a change to honor reset requests when device is in used state (VDEV_ST_USED). Reported-and-tested-by: Michael Suggested-by: Michael Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20210819225937.41037-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 08fa3391ffee67b4f3822a5b506c397f1ec6b6e0 Author: Anirudh Rayabharam Date: Sat Aug 21 00:31:21 2021 +0530 usbip: give back URBs for unsent unlink requests during cleanup [ Upstream commit 258c81b341c8025d79073ce2d6ce19dcdc7d10d2 ] In vhci_device_unlink_cleanup(), the URBs for unsent unlink requests are not given back. This sometimes causes usb_kill_urb to wait indefinitely for that urb to be given back. syzbot has reported a hung task issue [1] for this. To fix this, give back the urbs corresponding to unsent unlink requests (unlink_tx list) similar to how urbs corresponding to unanswered unlink requests (unlink_rx list) are given back. [1]: https://syzkaller.appspot.com/bug?id=08f12df95ae7da69814e64eb5515d5a85ed06b76 Reported-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Tested-by: syzbot+74d6ef051d3d2eacf428@syzkaller.appspotmail.com Reviewed-by: Shuah Khan Signed-off-by: Anirudh Rayabharam Link: https://lore.kernel.org/r/20210820190122.16379-2-mail@anirudhrb.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 72bb3eafcfdd156713a3ea0c9c95d536bd6e6e55 Author: Nadezda Lutovinova Date: Thu Aug 19 19:33:23 2021 +0300 usb: musb: musb_dsps: request_irq() after initializing musb [ Upstream commit 7c75bde329d7e2a93cf86a5c15c61f96f1446cdc ] If IRQ occurs between calling dsps_setup_optional_vbus_irq() and dsps_create_musb_pdev(), then null pointer dereference occurs since glue->musb wasn't initialized yet. The patch puts initializing of neccesery data before registration of the interrupt handler. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210819163323.17714-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6832c01e315f631e7a2564514f26ef7a9c06ab25 Author: Nadezda Lutovinova Date: Thu Aug 19 18:48:18 2021 +0300 usb: dwc3: imx8mp: request irq after initializing dwc3 [ Upstream commit 6a48d0ae01a6ab05ae5e78328546a2f5f6d3054a ] If IRQ occurs between calling devm_request_threaded_irq() and initializing dwc3_imx->dwc3, then null pointer dereference occurs since dwc3_imx->dwc3 is used in dwc3_imx8mp_interrupt(). The patch puts registration of the interrupt handler after initializing of neccesery data. Found by Linux Driver Verification project (linuxtesting.org). Reviewed-by: Fabio Estevam Acked-by: Felipe Balbi Signed-off-by: Nadezda Lutovinova Link: https://lore.kernel.org/r/20210819154818.18334-1-lutovinova@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e6e9a43b47035484bae8c1c3903e675fb35e0936 Author: Mathias Nyman Date: Fri Aug 20 15:35:01 2021 +0300 Revert "USB: xhci: fix U1/U2 handling for hardware with XHCI_INTEL_HOST quirk set" [ Upstream commit 2847c46c61486fd8bca9136a6e27177212e78c69 ] This reverts commit 5d5323a6f3625f101dbfa94ba3ef7706cce38760. That commit effectively disabled Intel host initiated U1/U2 lpm for devices with periodic endpoints. Before that commit we disabled host initiated U1/U2 lpm if the exit latency was larger than any periodic endpoint service interval, this is according to xhci spec xhci 1.1 specification section 4.23.5.2 After that commit we incorrectly checked that service interval was smaller than U1/U2 inactivity timeout. This is not relevant, and can't happen for Intel hosts as previously set U1/U2 timeout = 105% * service interval. Patch claimed it solved cases where devices can't be enumerated because of bandwidth issues. This might be true but it's a side effect of accidentally turning off lpm. exit latency calculations have been revised since then Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210820123503.2605901-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6ac2dc897e0a7ed2a297e2aaef759fd2e6113c45 Author: Ding Hui Date: Tue Aug 17 22:55:10 2021 +0800 cifs: fix wrong release in sess_alloc_buffer() failed path [ Upstream commit d72c74197b70bc3c95152f351a568007bffa3e11 ] smb_buf is allocated by small_smb_init_no_tc(), and buf type is CIFS_SMALL_BUFFER, so we should use cifs_small_buf_release() to release it in failed path. Signed-off-by: Ding Hui Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 706060c70a9fd0720cfff410c2892213ed475905 Author: Juhee Kang Date: Wed Aug 25 19:57:15 2021 +0900 samples: pktgen: fix to print when terminated normally [ Upstream commit c0e9422c4e6ca9abd4bd6e1598400c7231eb600b ] Currently, most pktgen samples print the execution result when the program is terminated normally. However, sample03 doesn't work appropriately. This is results of samples: # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample04_many_flows.sh -n 1 Running... ctrl^C to stop Device: eth0@0 Result: OK: 19(c5+d13) usec, 1 (60byte,0frags) 51762pps 24Mb/sec (24845760bps) errors: 0 # DEV=eth0 DEST_IP=10.1.0.1 DST_MAC=00:11:22:33:44:55 ./pktgen_sample03_burst_single_flow.sh -n 1 Running... ctrl^C to stop The reason why it doesn't print the execution result when the program is terminated usually is that sample03 doesn't call the function which prints the result, unlike other samples. So, this commit solves this issue by calling the function before termination. Also, this commit changes control_c function to print_result to maintain consistency with other samples. Signed-off-by: Juhee Kang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fe944e647277c2eb1bce9c2caf8bc38c7a0c0414 Author: Subbaraya Sundeep Date: Wed Aug 25 17:48:40 2021 +0530 octeontx2-pf: cleanup transmit link deriving logic [ Upstream commit 039190bb353a16657b44c5833bcad57e029c6934 ] Unlike OcteonTx2, the channel numbers used by CGX/RPM and LBK on CN10K silicons aren't fixed in HW. They are SW programmable, hence we cannot derive transmit link from static channel numbers anymore. Get the same from admin function via mailbox. Signed-off-by: Subbaraya Sundeep Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b22037f711395760023280d2dbdc99891e86084d Author: Nishad Kamdar Date: Wed Aug 25 00:47:26 2021 +0530 mmc: core: Return correct emmc response in case of ioctl error [ Upstream commit e72a55f2e5ddcfb3dce0701caf925ce435b87682 ] When a read/write command is sent via ioctl to the kernel, and the command fails, the actual error response of the emmc is not sent to the user. IOCTL read/write tests are carried out using commands 17 (Single BLock Read), 24 (Single Block Write), 18 (Multi Block Read), 25 (Multi Block Write) The tests are carried out on a 64Gb emmc device. All of these tests try to access an "out of range" sector address (0x09B2FFFF). It is seen that without the patch the response received by the user is not OUT_OF_RANGE error (R1 response 31st bit is not set) as per JEDEC specification. After applying the patch proper response is seen. This is because the function returns without copying the response to the user in case of failure. This patch fixes the issue. Hence, this memcpy is required whether we get an error response or not. Therefor it is moved up from the current position up to immediately after we have called mmc_wait_for_req(). The test code and the output of only the CMD17 is included in the commit to limit the message length. CMD17 (Test Code Snippet): ========================== printf("Forming CMD%d\n", opt_idx); /* single block read */ cmd.blksz = 512; cmd.blocks = 1; cmd.write_flag = 0; cmd.opcode = 17; //cmd.arg = atoi(argv[3]); cmd.arg = 0x09B2FFFF; /* Expecting response R1B */ cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC; memset(data, 0, sizeof(__u8) * 512); mmc_ioc_cmd_set_data(cmd, data); printf("Sending CMD%d: ARG[0x%08x]\n", opt_idx, cmd.arg); if(ioctl(fd, MMC_IOC_CMD, &cmd)) perror("Error"); printf("\nResponse: %08x\n", cmd.response[0]); CMD17 (Output without patch): ============================= test@test-LIVA-Z:~$ sudo ./mmc cmd_test /dev/mmcblk0 17 Entering the do_mmc_commands:Device: /dev/mmcblk0 nargs:4 Entering the do_mmc_commands:Device: /dev/mmcblk0 options[17, 0x09B2FFF] Forming CMD17 Sending CMD17: ARG[0x09b2ffff] Error: Connection timed out Response: 00000000 (Incorrect response) CMD17 (Output with patch): ========================== test@test-LIVA-Z:~$ sudo ./mmc cmd_test /dev/mmcblk0 17 [sudo] password for test: Entering the do_mmc_commands:Device: /dev/mmcblk0 nargs:4 Entering the do_mmc_commands:Device: /dev/mmcblk0 options[17, 09B2FFFF] Forming CMD17 Sending CMD17: ARG[0x09b2ffff] Error: Connection timed out Response: 80000900 (Correct OUT_OF_ERROR response as per JEDEC specification) Signed-off-by: Nishad Kamdar Reviewed-by: Avri Altman Link: https://lore.kernel.org/r/20210824191726.8296-1-nishadkamdar@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit fc21193ca7d9a6b4fb359b1e55051b6886472322 Author: Li Zhijian Date: Fri Aug 20 09:55:53 2021 +0800 selftests/bpf: Enlarge select() timeout for test_maps [ Upstream commit 2d82d73da35b72b53fe0d96350a2b8d929d07e42 ] 0Day robot observed that it's easily timeout on a heavy load host. ------------------- # selftests: bpf: test_maps # Fork 1024 tasks to 'test_update_delete' # Fork 1024 tasks to 'test_update_delete' # Fork 100 tasks to 'test_hashmap' # Fork 100 tasks to 'test_hashmap_percpu' # Fork 100 tasks to 'test_hashmap_sizes' # Fork 100 tasks to 'test_hashmap_walk' # Fork 100 tasks to 'test_arraymap' # Fork 100 tasks to 'test_arraymap_percpu' # Failed sockmap unexpected timeout not ok 3 selftests: bpf: test_maps # exit=1 # selftests: bpf: test_lru_map # nr_cpus:8 ------------------- Since this test will be scheduled by 0Day to a random host that could have only a few cpus(2-8), enlarge the timeout to avoid a false NG report. In practice, i tried to pin it to only one cpu by 'taskset 0x01 ./test_maps', and knew 10S is likely enough, but i still perfer to a larger value 30. Reported-by: kernel test robot Signed-off-by: Li Zhijian Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20210820015556.23276-2-lizhijian@cn.fujitsu.com Signed-off-by: Sasha Levin commit 4d3b34ec95aa57ff3cfca17d03365e3854ac9725 Author: Thomas Hebb Date: Sun Aug 1 04:46:14 2021 -0700 mmc: rtsx_pci: Fix long reads when clock is prescaled [ Upstream commit 3ac5e45291f3f0d699a721357380d4593bc2dcb3 ] For unexplained reasons, the prescaler register for this device needs to be cleared (set to 1) while performing a data read or else the command will hang. This does not appear to affect the real clock rate sent out on the bus, so I assume it's purely to work around a hardware bug. During normal operation, the prescaler is already set to 1, so nothing needs to be done. However, in "initial mode" (which is used for sub-MHz clock speeds, like the core sets while enumerating cards), it's set to 128 and so we need to reset it during data reads. We currently fail to do this for long reads. This has no functional affect on the driver's operation currently written, as the MMC core always sets a clock above 1MHz before attempting any long reads. However, the core could conceivably set any clock speed at any time and the driver should still work, so I think this fix is worthwhile. I personally encountered this issue while performing data recovery on an external chip. My connections had poor signal integrity, so I modified the core code to reduce the clock speed. Without this change, I saw the card enumerate but was unable to actually read any data. Writes don't seem to work in the situation described above even with this change (and even if the workaround is extended to encompass data write commands). I was not able to find a way to get them working. Signed-off-by: Thomas Hebb Link: https://lore.kernel.org/r/2fef280d8409ab0100c26c6ac7050227defd098d.1627818365.git.tommyhebb@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit c0598b6cf628db52a15548508f1afdebdb8c90b3 Author: Ulf Hansson Date: Fri Jul 2 15:42:29 2021 +0200 mmc: core: Avoid hogging the CPU while polling for busy after I/O writes [ Upstream commit 6966e6094c6d594044ef1b740dd827e05881331c ] When mmc_blk_card_busy() calls card_busy_detect() to poll for the card's state with CMD13, this is done without any delays in between the commands being sent. Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common __mmc_poll_for_busy(), which also helps us to avoid open-coding. Signed-off-by: Ulf Hansson Reviewed-by: Shawn Lin Link: https://lore.kernel.org/r/20210702134229.357717-4-ulf.hansson@linaro.org Signed-off-by: Sasha Levin commit 00d27b468e1b75a7f048656a78846ff961a87ff7 Author: Ulf Hansson Date: Fri Jul 2 15:42:28 2021 +0200 mmc: core: Avoid hogging the CPU while polling for busy for mmc ioctls [ Upstream commit 468108155b0f89cc08189cc33f9bacfe9da8a125 ] When __mmc_blk_ioctl_cmd() calls card_busy_detect() to verify that the card's states moves back into transfer state, the polling with CMD13 is done without any delays in between the commands being sent. Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common mmc_poll_for_busy(), which also helps us to avoid open-coding. Signed-off-by: Ulf Hansson Reviewed-by: Shawn Lin Link: https://lore.kernel.org/r/20210702134229.357717-3-ulf.hansson@linaro.org Signed-off-by: Sasha Levin commit 0c8b583b276f24edb744ae3fdf98db2dca8f768d Author: Ulf Hansson Date: Fri Jul 2 15:42:27 2021 +0200 mmc: core: Avoid hogging the CPU while polling for busy in the I/O err path [ Upstream commit 972d5084831dc9ae30f1a4b66cb4a19fb7ba6f09 ] When mmc_blk_fix_state() sends a CMD12 to try to move the card into the transfer state, it calls card_busy_detect() to poll for the card's state with CMD13. This is done without any delays in between the commands being sent. Rather than fixing card_busy_detect() in this regards, let's instead convert into using the common mmc_poll_for_busy(), which also helps us to avoid open-coding. Signed-off-by: Ulf Hansson Reviewed-by: Shawn Lin Link: https://lore.kernel.org/r/20210702134229.357717-2-ulf.hansson@linaro.org Signed-off-by: Sasha Levin commit 4165a4df77230da2c28387cd572b6e5f9ddbbdca Author: Manish Narani Date: Tue Jun 15 16:13:54 2021 +0530 mmc: sdhci-of-arasan: Check return value of non-void funtions [ Upstream commit 66bad6ed2204fdb78a0a8fb89d824397106a5471 ] At a couple of places, the return values of the non-void functions were not getting checked. This was reported by the coverity tool. Modify the code to check the return values of the same. Addresses-Coverity: ("check_return") Signed-off-by: Manish Narani Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/1623753837-21035-5-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 48ebcf76f74659407d46fc33f2f9dce174fb61ce Author: Manish Narani Date: Tue Jun 15 16:13:51 2021 +0530 mmc: sdhci-of-arasan: Modified SD default speed to 19MHz for ZynqMP [ Upstream commit c0b4e411a9b09748466ee06d2ae6772effa64dfb ] SD standard speed timing was met only at 19MHz and not 25 MHz, that's why changing driver to 19MHz. The reason for this is when a level shifter is used on the board, timing was met for standard speed only at 19MHz. Since this level shifter is commonly required for high speed modes, the driver is modified to use standard speed of 19Mhz. Signed-off-by: Manish Narani Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/1623753837-21035-2-git-send-email-manish.narani@xilinx.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 12b53b80d2686ee9e2aab9e92cc8df56a78c84dc Author: Marc Zyngier Date: Fri Aug 20 15:47:22 2021 +0100 of: Don't allow __of_attached_node_sysfs() without CONFIG_SYSFS [ Upstream commit 6211e9cb2f8faf7faae0b6caf844bfe9527cc607 ] Trying to boot without SYSFS, but with OF_DYNAMIC quickly results in a crash: [ 0.088460] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 [...] [ 0.103927] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc3 #4179 [ 0.105810] Hardware name: linux,dummy-virt (DT) [ 0.107147] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--) [ 0.108876] pc : kernfs_find_and_get_ns+0x3c/0x7c [ 0.110244] lr : kernfs_find_and_get_ns+0x3c/0x7c [...] [ 0.134087] Call trace: [ 0.134800] kernfs_find_and_get_ns+0x3c/0x7c [ 0.136054] safe_name+0x4c/0xd0 [ 0.136994] __of_attach_node_sysfs+0xf8/0x124 [ 0.138287] of_core_init+0x90/0xfc [ 0.139296] driver_init+0x30/0x4c [ 0.140283] kernel_init_freeable+0x160/0x1b8 [ 0.141543] kernel_init+0x30/0x140 [ 0.142561] ret_from_fork+0x10/0x18 While not having sysfs isn't a very common option these days, it is still expected that such configuration would work. Paper over it by bailing out from __of_attach_node_sysfs() if CONFIG_SYSFS isn't enabled. Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210820144722.169226-1-maz@kernel.org Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 43e8f17b32679139b458ad6e5125fbada2132b9c Author: Gustaw Lewandowski Date: Wed Aug 18 09:57:37 2021 +0200 ASoC: Intel: Skylake: Fix passing loadable flag for module [ Upstream commit c5ed9c547cba1dc1238c6e8a0c290fd62ee6e127 ] skl_get_module_info() tries to set mconfig->module->loadable before mconfig->module has been assigned thus flag was always set to false and driver did not try to load module binaries. Signed-off-by: Gustaw Lewandowski Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-7-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 16a5850a85123cb71fecd4dc4d2c300972354b7a Author: Cezary Rojewski Date: Wed Aug 18 09:57:36 2021 +0200 ASoC: Intel: Skylake: Fix module configuration for KPB and MIXER [ Upstream commit e4e0633bcadc950b4b4af06c7f1bb7f7e3e86321 ] KeyPhrasebuffer, Mixin and Mixout modules configuration is described by firmware's basic module configuration structure. There are no extended parameters required. Update functions taking part in building INIT_INSTANCE IPC payload to reflect that. Signed-off-by: Cezary Rojewski Tested-by: Lukasz Majczak Link: https://lore.kernel.org/r/20210818075742.1515155-6-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b9fc9a30bf2d51a9ec84ac6c6b3a5c5f61621c8d Author: Pierre-Louis Bossart Date: Wed Aug 18 10:49:52 2021 +0800 soundwire: intel: fix potential race condition during power down [ Upstream commit ea6942dad4b2a7e1735aa0f10f3d0b04b847750f ] The power down sequence sets the link_up flag as false outside of the mutex_lock. This is potentially unsafe. In additional the flow in that sequence can be improved by first testing if the link was powered, setting the link_up flag as false and proceeding with the power down. In case the CPA bits cannot be cleared, we only flag an error since we cannot deal with interrupts any longer. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210818024954.16873-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7f5de035dcee5d2adc868efee9647fb9989744b1 Author: Marcos Paulo de Souza Date: Mon Aug 2 09:34:00 2021 -0300 btrfs: tree-log: check btrfs_lookup_data_extent return value [ Upstream commit 3736127a3aa805602b7a2ad60ec9cfce68065fbb ] Function btrfs_lookup_data_extent calls btrfs_search_slot to verify if the EXTENT_ITEM exists in the extent tree. btrfs_search_slot can return values bellow zero if an error happened. Function replay_one_extent currently checks if the search found something (0 returned) and increments the reference, and if not, it seems to evaluate as 'not found'. Fix the condition by checking if the value was bellow zero and return early. Reviewed-by: Filipe Manana Signed-off-by: Marcos Paulo de Souza Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit ebfb366cbabd50682be45ecae7d48d08e6654153 Author: Filipe Manana Date: Tue Jul 20 16:03:40 2021 +0100 btrfs: remove racy and unnecessary inode transaction update when using no-holes [ Upstream commit cceaa89f02f15f232391ae4be214137b0a0285c0 ] When using the NO_HOLES feature and expanding the size of an inode, we update the inode's last_trans, last_sub_trans and last_log_commit fields at maybe_insert_hole() so that a fsync does know that the inode needs to be logged (by making sure that btrfs_inode_in_log() returns false). This happens for expanding truncate operations, buffered writes, direct IO writes and when cloning extents to an offset greater than the inode's i_size. However the way we do it is racy, because in between setting the inode's last_sub_trans and last_log_commit fields, the log transaction ID that was assigned to last_sub_trans might be committed before we read the root's last_log_commit and assign that value to last_log_commit. If that happens it would make a future call to btrfs_inode_in_log() return true. This is a race that should be extremely unlikely to be hit in practice, and it is the same that was described by commit bc0939fcfab0d7 ("btrfs: fix race between marking inode needs to be logged and log syncing"). The fix would simply be to set last_log_commit to the value we assigned to last_sub_trans minus 1, like it was done in that commit. However updating these two fields plus the last_trans field is pointless here because all the callers of btrfs_cont_expand() (which is the only caller of maybe_insert_hole()) always call btrfs_set_inode_last_trans() or btrfs_update_inode() after calling btrfs_cont_expand(). Calling either btrfs_set_inode_last_trans() or btrfs_update_inode() guarantees that the next fsync will log the inode, as it makes btrfs_inode_in_log() return false. So just remove the code that explicitly sets the inode's last_trans, last_sub_trans and last_log_commit fields. Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 3afd2af53a59327caf21aaadbf5c9b6f3fc0117b Author: Arnd Bergmann Date: Mon Aug 9 18:01:31 2021 +1000 m68knommu: only set CONFIG_ISA_DMA_API for ColdFire sub-arch [ Upstream commit db87db65c1059f3be04506d122f8ec9b2fa3b05e ] > Hi Arnd, > > First bad commit (maybe != root cause): > > tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > head: 2f73937c9aa561e2082839bc1a8efaac75d6e244 > commit: 47fd22f2b84765a2f7e3f150282497b902624547 [4771/5318] cs89x0: rework driver configuration > config: m68k-randconfig-c003-20210804 (attached as .config) > compiler: m68k-linux-gcc (GCC) 10.3.0 > reproduce (this is a W=1 build): > wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=47fd22f2b84765a2f7e3f150282497b902624547 > git remote add linux-next https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git > git fetch --no-tags linux-next master > git checkout 47fd22f2b84765a2f7e3f150282497b902624547 > # save the attached .config to linux build tree > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-10.3.0 make.cross ARCH=m68k > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kernel test robot > > All errors (new ones prefixed by >>): > > In file included from include/linux/kernel.h:19, > from include/linux/list.h:9, > from include/linux/module.h:12, > from drivers/net/ethernet/cirrus/cs89x0.c:51: > drivers/net/ethernet/cirrus/cs89x0.c: In function 'net_open': > drivers/net/ethernet/cirrus/cs89x0.c:897:20: error: implicit declaration of function 'isa_virt_to_bus'; did you mean 'virt_to_bus'? [-Werror=implicit-function-declaration] > 897 | (unsigned long)isa_virt_to_bus(lp->dma_buff)); > | ^~~~~~~~~~~~~~~ > include/linux/printk.h:141:17: note: in definition of macro 'no_printk' > 141 | printk(fmt, ##__VA_ARGS__); \ > | ^~~~~~~~~~~ > drivers/net/ethernet/cirrus/cs89x0.c:86:3: note: in expansion of macro 'pr_debug' > 86 | pr_##level(fmt, ##__VA_ARGS__); \ > | ^~~ > drivers/net/ethernet/cirrus/cs89x0.c:894:3: note: in expansion of macro 'cs89_dbg' > 894 | cs89_dbg(1, debug, "%s: dma %lx %lx\n", > | ^~~~~~~~ > >> drivers/net/ethernet/cirrus/cs89x0.c:914:3: error: implicit declaration of function 'disable_dma'; did you mean 'disable_irq'? [-Werror=implicit-function-declaration] As far as I can tell, this is a bug with the m68kmmu architecture, not with my driver: The CONFIG_ISA_DMA_API option is provided for coldfire, which implements it, but dragonball also sets the option as a side-effect, without actually implementing the interfaces. The patch below should fix it. Signed-off-by: Arnd Bergmann Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 18a6845fec2f1e10d3fef212dbec01088f87c49a Author: Subbaraya Sundeep Date: Sun Aug 22 17:32:18 2021 +0530 octeontx2-pf: Fix NIX1_RX interface backpressure [ Upstream commit e8fb4df1f5d84bc08dd4f4827821a851d2eab241 ] 'bp_ena' in Aura context is NIX block index, setting it zero will always backpressure NIX0 block, even if NIXLF belongs to NIX1. Hence fix this by setting it appropriately based on NIX block address. Signed-off-by: Subbaraya Sundeep Signed-off-by: Hariprasad Kelam Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 595004acdb6818357144513a26d790b82546d7ff Author: Chin-Yen Lee Date: Wed Jul 28 09:43:35 2021 +0800 rtw88: wow: fix size access error of probe request [ Upstream commit 69c7044526d984df672b8d9b6d6998c34617cde4 ] Current flow will lead to null ptr access because of trying to get the size of freed probe-request packets. We store the information of packet size into rsvd page instead and also fix the size error issue, which will cause unstable behavoir of sending probe request by wow firmware. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210728014335.8785-6-pkshih@realtek.com Signed-off-by: Sasha Levin commit 2943988424cceafae9a96c47aae20cc253645dae Author: Ping-Ke Shih Date: Wed Jul 28 09:43:33 2021 +0800 rtw88: wow: build wow function only if CONFIG_PM is on [ Upstream commit 05e45887382c4c0f9522515759b34991aa17e69d ] The kernel test robot reports undefined reference after we report wakeup reason to mac80211. This is because CONFIG_PM is not defined in the testing configuration file. In fact, functions within wow.c are used if CONFIG_PM is defined, so use CONFIG_PM to decide whether we build this file or not. The reported messages are: hppa-linux-ld: drivers/net/wireless/realtek/rtw88/wow.o: in function `rtw_wow_show_wakeup_reason': >> (.text+0x6c4): undefined reference to `ieee80211_report_wowlan_wakeup' >> hppa-linux-ld: (.text+0x6e0): undefined reference to `ieee80211_report_wowlan_wakeup' Reported-by: kernel test robot Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210728014335.8785-4-pkshih@realtek.com Signed-off-by: Sasha Levin commit f5527ae5b7bae2fd30c937094c58c7b6c606a0f0 Author: Chin-Yen Lee Date: Wed Jul 28 09:43:31 2021 +0800 rtw88: use read_poll_timeout instead of fixed sleep [ Upstream commit 02a55c0009a55b204e1e5c17295431f0a9e7d3b6 ] In current wow flow, driver calls rtw_wow_fw_start and sleep for 100ms, to wait firmware finish preliminary work and then update the value of WOWLAN_WAKE_REASON register to zero. But later firmware will start wow function with power-saving mode, in which mode the value of WOWLAN_WAKE_REASON register is 0xea. So driver may get 0xea value and return fail. We use read_poll_timeout instead to check the value to avoid this issue. Signed-off-by: Chin-Yen Lee Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210728014335.8785-2-pkshih@realtek.com Signed-off-by: Sasha Levin commit 1a89bb2cec93bc7a4e384387b382d08ce14cc354 Author: Chris Chiu Date: Wed Aug 4 23:13:25 2021 +0800 rtl8xxxu: Fix the handling of TX A-MPDU aggregation [ Upstream commit 95a581ab3592082c60a08090aabe09ac7d0bd650 ] The TX A-MPDU aggregation is not handled in the driver since the ieee80211_start_tx_ba_session has never been started properly. Start and stop the TX BA session by tracking the TX aggregation status of each TID. Fix the ampdu_action and the tx descriptor accordingly with the given TID. Signed-off-by: Chris Chiu Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210804151325.86600-1-chris.chiu@canonical.com Signed-off-by: Sasha Levin commit 502501ed6a8b0bc117ec4a1255f672deb9eb7f3c Author: Nathan Chancellor Date: Tue Jul 27 16:36:56 2021 -0700 drm/exynos: Always initialize mapping in exynos_drm_register_dma() [ Upstream commit c626f3864bbbb28bbe06476b0b497c1330aa4463 ] In certain randconfigs, clang warns: drivers/gpu/drm/exynos/exynos_drm_dma.c:121:19: warning: variable 'mapping' is uninitialized when used here [-Wuninitialized] priv->mapping = mapping; ^~~~~~~ drivers/gpu/drm/exynos/exynos_drm_dma.c:111:16: note: initialize the variable 'mapping' to silence this warning void *mapping; ^ = NULL 1 warning generated. This occurs when CONFIG_EXYNOS_IOMMU is enabled and both CONFIG_ARM_DMA_USE_IOMMU and CONFIG_IOMMU_DMA are disabled, which makes the code look like void *mapping; if (0) mapping = arm_iommu_create_mapping() else if (0) mapping = iommu_get_domain_for_dev() ... priv->mapping = mapping; Add an else branch that initializes mapping to the -ENODEV error pointer so that there is no more warning and the driver does not change during runtime. Reported-by: kernel test robot Signed-off-by: Nathan Chancellor Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 6debafc0d0133ceeebd4c31c3c7a5830318cfa44 Author: J. Bruce Fields Date: Fri Aug 20 17:01:59 2021 -0400 lockd: lockd server-side shouldn't set fl_ops [ Upstream commit 7de875b231edb807387a81cde288aa9e1015ef9e ] Locks have two sets of op arrays, fl_lmops for the lock manager (lockd or nfsd), fl_ops for the filesystem. The server-side lockd code has been setting its own fl_ops, which leads to confusion (and crashes) in the reexport case, where the filesystem expects to be the only one setting fl_ops. And there's no reason for it that I can see-the lm_get/put_owner ops do the same job. Reported-by: Daire Byrne Tested-by: Daire Byrne Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit b15cc0ef7d2dbad9a3ce86159a18fb5264194fca Author: Li Jun Date: Fri Jun 18 16:28:58 2021 +0800 usb: chipidea: host: fix port index underflow and UBSAN complains [ Upstream commit e5d6a7c6cfae9e714a0e8ff64facd1ac68a784c6 ] If wIndex is 0 (and it often is), these calculations underflow and UBSAN complains, here resolve this by not decrementing the index when it is equal to 0, this copies the solution from commit 85e3990bea49 ("USB: EHCI: avoid undefined pointer arithmetic and placate UBSAN") Reported-by: Zhipeng Wang Signed-off-by: Li Jun Link: https://lore.kernel.org/r/1624004938-2399-1-git-send-email-jun.li@nxp.com Signed-off-by: Peter Chen Signed-off-by: Sasha Levin commit 01eb3106f43335fdc02111358dae80a5c3fd324d Author: Bob Peterson Date: Fri Jul 30 12:41:49 2021 -0500 gfs2: Don't call dlm after protocol is unmounted [ Upstream commit d1340f80f0b8066321b499a376780da00560e857 ] In the gfs2 withdraw sequence, the dlm protocol is unmounted with a call to lm_unmount. After a withdraw, users are allowed to unmount the withdrawn file system. But at that point we may still have glocks left over that we need to free via unmount's call to gfs2_gl_hash_clear. These glocks may have never been completed because of whatever problem caused the withdraw (IO errors or whatever). Before this patch, function gdlm_put_lock would still try to call into dlm to unlock these leftover glocks, which resulted in dlm returning -EINVAL because the lock space was abandoned. These glocks were never freed because there was no mechanism after that to free them. This patch adds a check to gdlm_put_lock to see if the locking protocol was inactive (DFL_UNMOUNT flag) and if so, free the glock and not make the invalid call into dlm. I could have combined this "if" with the one that follows, related to leftover glock LVBs, but I felt the code was more readable with its own if clause. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit 939e67445347a6b3a73a753b6f3b6d5711325180 Author: Kuninori Morimoto Date: Fri Aug 20 13:08:26 2021 +0900 ASoC: rsnd: adg: clearly handle clock error / NULL case [ Upstream commit cc64c390b215b404524725a94857d6fb58d9a62a ] This driver is assuming that all adg->clk[i] is not NULL. Because of this prerequisites, for_each_rsnd_clk() is possible to work for all clk without checking NULL. In other words, all adg->clk[i] should not NULL. Some SoC might doesn't have clk_a/b/c/i. devm_clk_get() returns error in such case. This driver calls rsnd_adg_null_clk_get() and use null_clk instead of NULL in such cases. But devm_clk_get() might returns NULL even though such clocks exist, but it doesn't mean error (user deliberately chose to disable the feature). NULL clk itself is not error from clk point of view, but is error from this driver point of view because it is not assuming such case. But current code is using IS_ERR() which doesn't care NULL. This driver uses IS_ERR_OR_NULL() instead of IS_ERR() for clk check. And it uses ERR_CAST() to clarify null_clk error. One concern here is that it unconditionally uses null_clk if clk_a/b/c/i was error. It is correct if it doesn't exist, but is not correct if it returns error even though it exist. It needs to check "clock-names" from DT before calling devm_clk_get() to handling such case. But let's assume it is overkill so far. Link: https://lore.kernel.org/r/YMCmhfQUimHCSH/n@mwanda Reported-by: Dan Carpenter Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87v940wyf9.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 080bbbbcab18c8cb8c148afb90e9de8cd2faf24c Author: Mark Brown Date: Thu Aug 19 17:57:23 2021 +0100 kselftest/arm64: pac: Fix skipping of tests on systems without PAC [ Upstream commit 0c69bd2ca6ee20064dde7853cd749284e053a874 ] The PAC tests check to see if the system supports the relevant PAC features but instead of skipping the tests if they can't be executed they fail the tests which makes things look like they're not working when they are. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210819165723.43903-1-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 41733fa1e1e2ab84d317e5ce4bfafcb7665ad3be Author: Mark Brown Date: Thu Aug 19 18:29:02 2021 +0100 kselftest/arm64: mte: Fix misleading output when skipping tests [ Upstream commit 83e5dcbece4ea67ec3ad94b897e2844184802fd7 ] When skipping the tests due to a lack of system support for MTE we currently print a message saying FAIL which makes it look like the test failed even though the test did actually report KSFT_SKIP, creating some confusion. Change the error message to say SKIP instead so things are clearer. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210819172902.56211-1-broonie@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit f64c7c47012e3bc2ed71fb76f307c17bb1d43f77 Author: Eli Cohen Date: Tue Aug 17 20:05:18 2021 +0300 net: Fix offloading indirect devices dependency on qdisc order creation [ Upstream commit 74fc4f828769cca1c3be89ea92cb88feaa27ef52 ] Currently, when creating an ingress qdisc on an indirect device before the driver registered for callbacks, the driver will not have a chance to register its filter configuration callbacks. To fix that, modify the code such that it keeps track of all the ingress qdiscs that call flow_indr_dev_setup_offload(). When a driver calls flow_indr_dev_register(), go through the list of tracked ingress qdiscs and call the driver callback entry point so as to give it a chance to register its callback. Reviewed-by: Jiri Pirko Signed-off-by: Eli Cohen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c47a71a9d4b1cd353b081c5e7a65bebff2d9c4ed Author: Bongsu Jeon Date: Tue Aug 17 06:28:15 2021 -0700 selftests: nci: Fix the wrong condition [ Upstream commit 1d5b8d01db98abb8c176838fad73287366874582 ] memcpy should be executed only in case nla_len's value is greater than 0. Signed-off-by: Bongsu Jeon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0fa02e06059ea6c74ff991655589c7c607798798 Author: Bongsu Jeon Date: Tue Aug 17 06:28:14 2021 -0700 selftests: nci: Fix the code for next nlattr offset [ Upstream commit 78a7b2a8a0fa31f63ac16ac13601db6ed8259dfc ] nlattr could have a padding for 4 bytes alignment. So next nla's offset should be calculated with a padding. Signed-off-by: Bongsu Jeon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5196716ab948cd3b49638ceb776f530ddf16d945 Author: Kees Cook Date: Tue Aug 17 21:42:52 2021 -0700 staging: rts5208: Fix get_ms_information() heap buffer size [ Upstream commit cbe34165cc1b7d1110b268ba8b9f30843c941639 ] Fix buf allocation size (it needs to be 2 bytes larger). Found when __alloc_size() annotations were added to kmalloc() interfaces. In file included from ./include/linux/string.h:253, from ./include/linux/bitmap.h:10, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/paravirt.h:17, from ./arch/x86/include/asm/irqflags.h:63, from ./include/linux/irqflags.h:16, from ./include/linux/rcupdate.h:26, from ./include/linux/rculist.h:11, from ./include/linux/pid.h:5, from ./include/linux/sched.h:14, from ./include/linux/blkdev.h:5, from drivers/staging/rts5208/rtsx_scsi.c:12: In function 'get_ms_information', inlined from 'ms_sp_cmnd' at drivers/staging/rts5208/rtsx_scsi.c:2877:12, inlined from 'rtsx_scsi_handler' at drivers/staging/rts5208/rtsx_scsi.c:3247:12: ./include/linux/fortify-string.h:54:29: warning: '__builtin_memcpy' forming offset [106, 107] is out of the bounds [0, 106] [-Warray-bounds] 54 | #define __underlying_memcpy __builtin_memcpy | ^ ./include/linux/fortify-string.h:417:2: note: in expansion of macro '__underlying_memcpy' 417 | __underlying_##op(p, q, __fortify_size); \ | ^~~~~~~~~~~~~ ./include/linux/fortify-string.h:463:26: note: in expansion of macro '__fortify_memcpy_chk' 463 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ | ^~~~~~~~~~~~~~~~~~~~ drivers/staging/rts5208/rtsx_scsi.c:2851:3: note: in expansion of macro 'memcpy' 2851 | memcpy(buf + i, ms_card->raw_sys_info, 96); | ^~~~~~ Cc: Greg Kroah-Hartman Cc: linux-staging@lists.linux.dev Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210818044252.1533634-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1ac7a04f4505bee0d54a81d34aea88d2f9604ec3 Author: Brandon Wyman Date: Fri Aug 6 22:51:31 2021 +0000 hwmon: (pmbus/ibm-cffps) Fix write bits for LED control [ Upstream commit 76b72736f574ec38b3e94603ea5f74b1853f26b0 ] When doing a PMBus write for the LED control on the IBM Common Form Factor Power Supplies (ibm-cffps), the DAh command requires that bit 7 be low and bit 6 be high in order to indicate that you are truly attempting to do a write. Signed-off-by: Brandon Wyman Link: https://lore.kernel.org/r/20210806225131.1808759-1-bjwyman@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit af12cb42db0585dd2df152ae2e08e70e5f05e4ee Author: Yonghong Song Date: Tue Aug 17 12:09:23 2021 -0700 selftests/bpf: Fix flaky send_signal test [ Upstream commit b16ac5bf732a5e23d164cf908ec7742d6a6120d3 ] libbpf CI has reported send_signal test is flaky although I am not able to reproduce it in my local environment. But I am able to reproduce with on-demand libbpf CI ([1]). Through code analysis, the following is possible reason. The failed subtest runs bpf program in softirq environment. Since bpf_send_signal() only sends to a fork of "test_progs" process. If the underlying current task is not "test_progs", bpf_send_signal() will not be triggered and the subtest will fail. To reduce the chances where the underlying process is not the intended one, this patch boosted scheduling priority to -20 (highest allowed by setpriority() call). And I did 10 runs with on-demand libbpf CI with this patch and I didn't observe any failures. [1] https://github.com/libbpf/libbpf/actions/workflows/ondemand.yml Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210817190923.3186725-1-yhs@fb.com Signed-off-by: Sasha Levin commit 1fe8b97cd0e0c6ba3869e329ed6c2c725e862a6f Author: Yucong Sun Date: Mon Aug 16 21:47:30 2021 -0700 selftests/bpf: Correctly display subtest skip status [ Upstream commit f667d1d66760fcb27aee6c9964eefde39a464afe ] In skip_account(), test->skip_cnt is set to 0 at the end, this makes next print statement never display SKIP status for the subtest. This patch moves the accounting logic after the print statement, fixing the issue. This patch also added SKIP status display for normal tests. Signed-off-by: Yucong Sun Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210817044732.3263066-3-fallentree@fb.com Signed-off-by: Sasha Levin commit 1652cf211f0c5931cd0a95d9f6c49fed64c7dcd3 Author: Stefan Assmann Date: Wed Aug 4 10:22:24 2021 +0200 iavf: use mutexes for locking of critical sections [ Upstream commit 5ac49f3c2702f269d31cc37eb9308bc557953c4d ] As follow-up to the discussion with Jakub Kicinski about iavf locking being insufficient [1] convert iavf to use mutexes instead of bitops. The locking logic is kept as is, just a drop-in replacement of enum iavf_critical_section_t with separate mutexes. The only difference is that the mutexes will be destroyed before the module is unloaded. [1] https://lwn.net/ml/netdev/20210316150210.00007249%40intel.com/ Signed-off-by: Stefan Assmann Tested-by: Marek Szlosek Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit eedb179733851f8dfd49d99f9dec971d581dda7f Author: J. Bruce Fields Date: Thu Aug 12 16:41:42 2021 -0400 rpc: fix gss_svc_init cleanup on failure [ Upstream commit 5a4753446253a427c0ff1e433b9c4933e5af207c ] The failure case here should be rare, but it's obviously wrong. Signed-off-by: J. Bruce Fields Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 26249d9392d32c2dc56a85160727c05af3150a58 Author: Thomas Gleixner Date: Sun Aug 15 23:27:38 2021 +0200 locking/rtmutex: Set proper wait context for lockdep [ Upstream commit b41cda03765580caf7723b8c1b672d191c71013f ] RT mutexes belong to the LD_WAIT_SLEEP class. Make them so. Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20210815211302.031014562@linutronix.de Signed-off-by: Sasha Levin commit fad83993185be5a14a8deeb8cb62aa2cefea2167 Author: Luke Hsiao Date: Mon Aug 16 20:51:06 2021 +0000 tcp: enable data-less, empty-cookie SYN with TFO_SERVER_COOKIE_NOT_REQD [ Upstream commit e3faa49bcecdfcc80e94dd75709d6acb1a5d89f6 ] Since the original TFO server code was implemented in commit 168a8f58059a22feb9e9a2dcc1b8053dbbbc12ef ("tcp: TCP Fast Open Server - main code path") the TFO server code has supported the sysctl bit flag TFO_SERVER_COOKIE_NOT_REQD. Currently, when the TFO_SERVER_ENABLE and TFO_SERVER_COOKIE_NOT_REQD sysctl bit flags are set, a server connection will accept a SYN with N bytes of data (N > 0) that has no TFO cookie, create a new fast open connection, process the incoming data in the SYN, and make the connection ready for accepting. After accepting, the connection is ready for read()/recvmsg() to read the N bytes of data in the SYN, ready for write()/sendmsg() calls and data transmissions to transmit data. This commit changes an edge case in this feature by changing this behavior to apply to (N >= 0) bytes of data in the SYN rather than only (N > 0) bytes of data in the SYN. Now, a server will accept a data-less SYN without a TFO cookie if TFO_SERVER_COOKIE_NOT_REQD is set. Caveat! While this enables a new kind of TFO (data-less empty-cookie SYN), some firewall rules setup may not work if they assume such packets are not legit TFOs and will filter them. Signed-off-by: Luke Hsiao Acked-by: Neal Cardwell Acked-by: Yuchung Cheng Signed-off-by: Eric Dumazet Link: https://lore.kernel.org/r/20210816205105.2533289-1-luke.w.hsiao@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2c3f49b614e82ae37b0d9e8704e16c4a8c3b7fee Author: Darrick J. Wong Date: Tue Aug 10 18:32:55 2021 -0700 iomap: pass writeback errors to the mapping [ Upstream commit b69eea82d37d9ee7cfb3bf05103549dd4ed5ffc3 ] Modern-day mapping_set_error has the ability to squash the usual negative error code into something appropriate for long-term storage in a struct address_space -- ENOSPC becomes AS_ENOSPC, and everything else becomes EIO. iomap squashes /everything/ to EIO, just as XFS did before that, but this doesn't make sense. Fix this by making it so that we can pass ENOSPC to userspace when writeback fails due to space problems. Signed-off-by: Darrick J. Wong Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Sasha Levin commit 8b17ad9a63935204811afa606a511748f96a2e02 Author: Ulrich Hecht Date: Mon Aug 16 18:22:01 2021 +0200 serial: sh-sci: fix break handling for sysrq [ Upstream commit 87b8061bad9bd4b549b2daf36ffbaa57be2789a2 ] This fixes two issues that cause the sysrq sequence to be inadvertently aborted on SCIF serial consoles: - a NUL character remains in the RX queue after a break has been detected, which is then passed on to uart_handle_sysrq_char() - the break interrupt is handled twice on controllers with multiplexed ERI and BRI interrupts Signed-off-by: Ulrich Hecht Link: https://lore.kernel.org/r/20210816162201.28801-1-uli+renesas@fpond.eu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit edbebb478a7a8b2d226ef84d9e8f68df6c05b3dc Author: Rajendra Nayak Date: Thu Aug 12 16:57:20 2021 +0530 opp: Don't print an error if required-opps is missing [ Upstream commit 020d86fc0df8b865f6dc168d88a7c2dccabd0a9e ] The 'required-opps' property is considered optional, hence remove the pr_err() in of_parse_required_opp() when we find the property is missing. While at it, also fix the return value of of_get_required_opp_performance_state() when of_parse_required_opp() fails, return a -ENODEV instead of the -EINVAL. Signed-off-by: Rajendra Nayak Reviewed-by: Ulf Hansson Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit acc5edd99968b2aea2626b975b726d45d9b7df8c Author: Kiran K Date: Mon Aug 16 05:07:47 2021 +0530 Bluetooth: Fix race condition in handling NOP command [ Upstream commit ecb71f2566673553bc067e5b0036756871d0b9d3 ] For NOP command, need to cancel work scheduled on cmd_timer, on receiving command status or commmand complete event. Below use case might lead to race condition multiple when NOP commands are queued sequentially: hci_cmd_work() { if (atomic_read(&hdev->cmd_cnt) { . . . atomic_dec(&hdev->cmd_cnt); hci_send_frame(hdev,...); schedule_delayed_work(&hdev->cmd_timer,...); } } On receiving event for first NOP, the work scheduled on hdev->cmd_timer is not cancelled and second NOP is dequeued and sent to controller. While waiting for an event for second NOP command, work scheduled on cmd_timer for the first NOP can get scheduled, resulting in sending third NOP command (sending back to back NOP commands). This might cause issues at controller side (like memory overrun, controller going unresponsive) resulting in hci tx timeouts, hardware errors etc. The fix to this issue is to cancel the delayed work scheduled on cmd_timer on receiving command status or command complete event for NOP command (this patch handles NOP command same as any other SIG command). Signed-off-by: Kiran K Reviewed-by: Chethan T N Reviewed-by: Srivatsa Ravishankar Acked-by: Manish Mandlik Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit fab277f8ca005e198a4e6a824daf93915f586aee Author: Luiz Augusto von Dentz Date: Wed Aug 11 16:20:15 2021 -0700 Bluetooth: Fix handling of LE Enhanced Connection Complete [ Upstream commit cafae4cd625502f65d1798659c1aa9b62d38cc56 ] LE Enhanced Connection Complete contains the Local RPA used in the connection which must be used when set otherwise there could problems when pairing since the address used by the remote stack could be the Local RPA: BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 4, Part E page 2396 'Resolvable Private Address being used by the local device for this connection. This is only valid when the Own_Address_Type (from the HCI_LE_Create_Connection, HCI_LE_Set_Advertising_Parameters, HCI_LE_Set_Extended_Advertising_Parameters, or HCI_LE_Extended_Create_Connection commands) is set to 0x02 or 0x03, and the Controller generated a resolvable private address for the local device using a non-zero local IRK. For other Own_Address_Type values, the Controller shall return all zeros.' Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 5c08d027f13644aa32588cc6b242833fa0989a95 Author: Sagi Grimberg Date: Wed Jun 16 14:19:36 2021 -0700 nvme: code command_id with a genctr for use-after-free validation [ Upstream commit e7006de6c23803799be000a5dcce4d916a36541a ] We cannot detect a (perhaps buggy) controller that is sending us a completion for a request that was already completed (for example sending a completion twice), this phenomenon was seen in the wild a few times. So to protect against this, we use the upper 4 msbits of the nvme sqe command_id to use as a 4-bit generation counter and verify it matches the existing request generation that is incrementing on every execution. The 16-bit command_id structure now is constructed by: | xxxx | xxxxxxxxxxxx | gen request tag This means that we are giving up some possible queue depth as 12 bits allow for a maximum queue depth of 4095 instead of 65536, however we never create such long queues anyways so no real harm done. Suggested-by: Keith Busch Signed-off-by: Sagi Grimberg Acked-by: Keith Busch Reviewed-by: Hannes Reinecke Reviewed-by: Daniel Wagner Tested-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 18b373b1a3d11a69ae3364bde34d36c4dda00ccc Author: Sagi Grimberg Date: Wed Jun 16 14:19:35 2021 -0700 nvme-tcp: don't check blk_mq_tag_to_rq when receiving pdu data [ Upstream commit 3b01a9d0caa8276d9ce314e09610f7fb70f49a00 ] We already validate it when receiving the c2hdata pdu header and this is not changing so this is a redundant check. Reviewed-by: Hannes Reinecke Signed-off-by: Sagi Grimberg Reviewed-by: Daniel Wagner Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 36c20ce3c73dc591d1d89dd2ba9cb1866ef13b15 Author: Raag Jadav Date: Thu Aug 5 00:54:45 2021 +0530 arm64: dts: ls1046a: fix eeprom entries [ Upstream commit c1a6018d1839c9cb8f807dc863a50102a1a5c412 ] ls1046afrwy and ls1046ardb boards have CAT24C04[1] and CAT24C05[2] eeproms respectively. Both are 4Kb (512 bytes) in size, and compatible with AT24C04[3]. Remove multi-address entries, as both the boards have a single chip each. [1] https://www.onsemi.com/pdf/datasheet/cat24c01-d.pdf [2] https://www.onsemi.com/pdf/datasheet/cat24c03-d.pdf [3] https://ww1.microchip.com/downloads/en/DeviceDoc/doc0180.pdf Signed-off-by: Raag Jadav Acked-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 628b2989239a7d7873cc0982f29e69d17d86cad1 Author: Tim Harvey Date: Tue Jul 27 09:10:59 2021 -0700 arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS [ Upstream commit bd306fdb4e60bcb1d7ea5431a74092803d3784a6 ] The GW71xx has a USB Type-C connector with USB 2.0 signaling. GPIO1_12 is the power-enable to the TPS25821 Source controller and power switch responsible for monitoring the CC pins and enabling VBUS. Therefore GPIO1_12 must always be enabled and the vbus output enable from the IMX8MM can be ignored. To fix USB OTG VBUS enable a pull-up on GPIO1_12 to always power the TPS25821 and change the regulator output to GPIO1_10 which is unconnected. Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 66e37b54a4935d95bc436b012161eb2644090226 Author: Tim Harvey Date: Tue Jul 27 09:10:58 2021 -0700 arm64: dts: imx8mm-venice-gw700x: fix invalid pmic pin config [ Upstream commit 500659f3b401fe6ffd1d63f2449d16d8a4204db7 ] The GW700x PMIC does not have an interrupt. Remove the invalid pin config. Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 32cfe0468f331f947637d5a42d460dcca6dd90ca Author: Tim Harvey Date: Tue Jul 27 09:10:57 2021 -0700 arm64: dts: imx8mm-venice-gw700x: fix mp5416 pmic config [ Upstream commit 092cd75e527044050ea76bf774e7d730709b7e8b ] Fix various MP5416 PMIC configurations: - Update regulator names per dt-bindings - ensure values fit among valid register values - add required regulator-max-microamp property - add regulator-always-on prop Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit cbe2c3dc69c779b41eee67be3a1a0e537a2323a1 Author: Thierry Reding Date: Tue Jun 22 15:44:22 2021 +0200 arm64: tegra: Fix compatible string for Tegra132 CPUs [ Upstream commit f865d0292ff3c0ca09414436510eb4c815815509 ] The documented compatible string for the CPUs found on Tegra132 is "nvidia,tegra132-denver", rather than the previously used compatible string "nvidia,denver". Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 2a5128e017e94b247056251d64f6cfbbed95cf13 Author: Andreas Obergschwandtner Date: Thu Jul 29 16:42:26 2021 +0200 ARM: tegra: tamonten: Fix UART pad setting [ Upstream commit 2270ad2f4e123336af685ecedd1618701cb4ca1e ] This patch fixes the tristate and pullup configuration for UART 1 to 3 on the Tamonten SOM. Signed-off-by: Andreas Obergschwandtner Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit f660a75009157d4b4a3eebc1139d56b60bfa481c Author: Dmitry Osipenko Date: Tue Aug 3 00:19:43 2021 +0300 ARM: tegra: acer-a500: Remove bogus USB VBUS regulators [ Upstream commit 70e740ad55e5f93a19493720f4105555fade4a73 ] The configuration of USB VBUS regulators was borrowed from downstream kernel, which is incorrect because the corresponding GPIOs are connected to PROX_EN (A501 3G model) and LED_EN pins in accordance to the board schematics. USB works fine with both GPIOs being disabled, so remove the bogus USB VBUS regulators. The USB VBUS of USB3 is supplied from the fixed 5v system regulator and device-mode USB1 doesn't have VBUS switches. Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit df5d18f75fbca521ce40652c18c63b86cea356f5 Author: Johan Almbladh Date: Mon Jun 28 14:32:46 2021 +0200 mac80211: Fix monitor MTU limit so that A-MSDUs get through [ Upstream commit 79f5962baea74ce1cd4e5949598944bff854b166 ] The maximum MTU was set to 2304, which is the maximum MSDU size. While this is valid for normal WLAN interfaces, it is too low for monitor interfaces. A monitor interface may receive and inject MPDU frames, and the maximum MPDU frame size is larger than 2304. The MPDU may also contain an A-MSDU frame, in which case the size may be much larger than the MTU limit. Since the maximum size of an A-MSDU depends on the PHY mode of the transmitting STA, it is not possible to set an exact MTU limit for a monitor interface. Now the maximum MTU for a monitor interface is unrestricted. Signed-off-by: Johan Almbladh Link: https://lore.kernel.org/r/20210628123246.2070558-1-johan.almbladh@anyfinetworks.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit ffbbadf0b86ee5e23ec92aa203c101da3155b25b Author: Tuo Li Date: Tue Aug 10 21:07:03 2021 -0700 drm/display: fix possible null-pointer dereference in dcn10_set_clock() [ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ] The variable dc->clk_mgr is checked in: if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock) This indicates dc->clk_mgr can be NULL. However, it is dereferenced in: if (!dc->clk_mgr->funcs->get_clock) To fix this null-pointer dereference, check dc->clk_mgr and the function pointer dc->clk_mgr->funcs->get_clock earlier, and return if one of them is NULL. Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5b3aac0aaf5ee029ea3caa38265f89992ddfa0d5 Author: Tuo Li Date: Wed Aug 11 04:34:58 2021 -0700 gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable access in amdgpu_i2c_router_select_ddc_port() [ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ] The variable val is declared without initialization, and its address is passed to amdgpu_i2c_get_byte(). In this function, the value of val is accessed in: DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n", addr, *val); Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized, but it is accessed in: val &= ~amdgpu_connector->router.ddc_mux_control_pin; To fix this possible uninitialized-variable access, initialize val to 0 in amdgpu_i2c_router_select_ddc_port(). Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 77ed8fb4971309b774a7c9ea451f275c5a9047d5 Author: Eran Ben Elisha Date: Tue Aug 10 21:15:05 2021 +0300 net/mlx5: Fix variable type to match 64bit [ Upstream commit 979aa51967add26b37f9d77e01729d44a2da8e5f ] Fix the following smatch warning: wait_func_handle_exec_timeout() warn: should '1 << ent->idx' be a 64 bit type? Use 1ULL, to have a 64 bit type variable. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Eran Ben Elisha Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit c63b6a594ee07152b9fcacdc9edadcc8471fa465 Author: Kuogee Hsieh Date: Thu Aug 5 13:44:55 2021 -0700 drm/msm/dp: do not end dp link training until video is ready [ Upstream commit 2e0adc765d884cc080baa501e250bfad97035b09 ] Initialize both pre-emphasis and voltage swing level to 0 before start link training and do not end link training until video is ready to reduce the period between end of link training and video start to meet Link Layer CTS requirement. Some dongle main link symbol may become unlocked again if host did not end link training soon enough after completion of link training 2. Host have to re train main link if loss of symbol locked detected before end link training so that the coming video stream can be transmitted to sink properly. This fixes Link Layer CTS cases 4.3.2.1, 4.3.2.2, 4.3.2.3 and 4.3.2.4. Changes in v3: -- merge retrain link if loss of symbol locked happen into this patch -- replace dp_ctrl_loss_symbol_lock() with dp_ctrl_channel_eq_ok() Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1628196295-7382-7-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 08a96864a45b65ee406a344c78dd761b2fd66887 Author: Kuogee Hsieh Date: Thu Aug 5 13:44:54 2021 -0700 drm/msm/dp: return correct edid checksum after corrupted edid checksum read [ Upstream commit 7948fe12d47a946fb8025a0534c900e3dd4b5839 ] Response with correct edid checksum saved at connector after corrupted edid checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1628196295-7382-6-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 21498aaa1f40ccbc5127ff59e1f7517eb65fba16 Author: Kuogee Hsieh Date: Thu Aug 5 13:44:52 2021 -0700 drm/msm/dp: reset aux controller after dp_aux_cmd_fifo_tx() failed. [ Upstream commit 0b324564ff74fa0556002be8fbbace556b9b2ad0 ] Aux hardware calibration sequence requires resetting the aux controller in order for the new setting to take effect. However resetting the AUX controller will also clear HPD interrupt status which may accidentally cause pending unplug interrupt to get lost. Therefore reset aux controller only when link is in connection state when dp_aux_cmd_fifo_tx() fail. This fixes Link Layer CTS cases 4.2.1.1 and 4.2.1.2. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1628196295-7382-4-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a6cf7dc5ccde5c4be4755a7fa3c16260014497d4 Author: Kuogee Hsieh Date: Thu Aug 5 13:44:51 2021 -0700 drm/msm/dp: reduce link rate if failed at link training 1 [ Upstream commit 4b85d405cfe938ae7ad61656484ae88dee289e3b ] Reduce link rate and re start link training if link training 1 failed due to loss of clock recovery done to fix Link Layer CTS case 4.3.1.7. Also only update voltage and pre-emphasis swing level after link training started to fix Link Layer CTS case 4.3.1.6. Changes in V2: -- replaced cr_status with link_status[DP_LINK_STATUS_SIZE] -- replaced dp_ctrl_any_lane_cr_done() with dp_ctrl_colco_recovery_any_ok() -- replaced dp_ctrl_any_ane_cr_lose() with !drm_dp_clock_recovery_ok() Changes in V3: -- return failed if lane_count <= 1 Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/1628196295-7382-3-git-send-email-khsieh@codeaurora.org [remove unused cr_status variable] Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 9ebb5a7757073da64d10a12621d0cedaca3aa215 Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:06 2021 +0800 Bluetooth: avoid circular locks in sco_sock_connect [ Upstream commit 734bc5ff783115aa3164f4e9dd5967ae78e0a8ab ] In a future patch, calls to bh_lock_sock in sco.c should be replaced by lock_sock now that none of the functions are run in IRQ context. However, doing so results in a circular locking dependency: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc4-syzkaller #0 Not tainted ------------------------------------------------------ syz-executor.2/14867 is trying to acquire lock: ffff88803e3c1120 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1613 [inline] ffff88803e3c1120 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}, at: sco_conn_del+0x12a/0x2a0 net/bluetooth/sco.c:191 but task is already holding lock: ffffffff8d2dc7c8 (hci_cb_list_lock){+.+.}-{3:3}, at: hci_disconn_cfm include/net/bluetooth/hci_core.h:1497 [inline] ffffffff8d2dc7c8 (hci_cb_list_lock){+.+.}-{3:3}, at: hci_conn_hash_flush+0xda/0x260 net/bluetooth/hci_conn.c:1608 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (hci_cb_list_lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:959 [inline] __mutex_lock+0x12a/0x10a0 kernel/locking/mutex.c:1104 hci_connect_cfm include/net/bluetooth/hci_core.h:1482 [inline] hci_remote_features_evt net/bluetooth/hci_event.c:3263 [inline] hci_event_packet+0x2f4d/0x7c50 net/bluetooth/hci_event.c:6240 hci_rx_work+0x4f8/0xd30 net/bluetooth/hci_core.c:5122 process_one_work+0x98d/0x1630 kernel/workqueue.c:2276 worker_thread+0x658/0x11f0 kernel/workqueue.c:2422 kthread+0x3e5/0x4d0 kernel/kthread.c:319 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 -> #1 (&hdev->lock){+.+.}-{3:3}: __mutex_lock_common kernel/locking/mutex.c:959 [inline] __mutex_lock+0x12a/0x10a0 kernel/locking/mutex.c:1104 sco_connect net/bluetooth/sco.c:245 [inline] sco_sock_connect+0x227/0xa10 net/bluetooth/sco.c:601 __sys_connect_file+0x155/0x1a0 net/socket.c:1879 __sys_connect+0x161/0x190 net/socket.c:1896 __do_sys_connect net/socket.c:1906 [inline] __se_sys_connect net/socket.c:1903 [inline] __x64_sys_connect+0x6f/0xb0 net/socket.c:1903 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 -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_SCO){+.+.}-{0:0}: check_prev_add kernel/locking/lockdep.c:3051 [inline] check_prevs_add kernel/locking/lockdep.c:3174 [inline] validate_chain kernel/locking/lockdep.c:3789 [inline] __lock_acquire+0x2a07/0x54a0 kernel/locking/lockdep.c:5015 lock_acquire kernel/locking/lockdep.c:5625 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5590 lock_sock_nested+0xca/0x120 net/core/sock.c:3170 lock_sock include/net/sock.h:1613 [inline] sco_conn_del+0x12a/0x2a0 net/bluetooth/sco.c:191 sco_disconn_cfm+0x71/0xb0 net/bluetooth/sco.c:1202 hci_disconn_cfm include/net/bluetooth/hci_core.h:1500 [inline] hci_conn_hash_flush+0x127/0x260 net/bluetooth/hci_conn.c:1608 hci_dev_do_close+0x528/0x1130 net/bluetooth/hci_core.c:1778 hci_unregister_dev+0x1c0/0x5a0 net/bluetooth/hci_core.c:4015 vhci_release+0x70/0xe0 drivers/bluetooth/hci_vhci.c:340 __fput+0x288/0x920 fs/file_table.c:280 task_work_run+0xdd/0x1a0 kernel/task_work.c:164 exit_task_work include/linux/task_work.h:32 [inline] do_exit+0xbd4/0x2a60 kernel/exit.c:825 do_group_exit+0x125/0x310 kernel/exit.c:922 get_signal+0x47f/0x2160 kernel/signal.c:2808 arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:865 handle_signal_work kernel/entry/common.c:148 [inline] exit_to_user_mode_loop kernel/entry/common.c:172 [inline] exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:209 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline] syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:302 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:288 other info that might help us debug this: Chain exists of: sk_lock-AF_BLUETOOTH-BTPROTO_SCO --> &hdev->lock --> hci_cb_list_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(hci_cb_list_lock); lock(&hdev->lock); lock(hci_cb_list_lock); lock(sk_lock-AF_BLUETOOTH-BTPROTO_SCO); *** DEADLOCK *** The issue is that the lock hierarchy should go from &hdev->lock --> hci_cb_list_lock --> sk_lock-AF_BLUETOOTH-BTPROTO_SCO. For example, one such call trace is: hci_dev_do_close(): hci_dev_lock(); hci_conn_hash_flush(): hci_disconn_cfm(): mutex_lock(&hci_cb_list_lock); sco_disconn_cfm(): sco_conn_del(): lock_sock(sk); However, in sco_sock_connect, we call lock_sock before calling hci_dev_lock inside sco_connect, thus inverting the lock hierarchy. We fix this by pulling the call to hci_dev_lock out from sco_connect. Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit b657bba82ff6a007d84fd076bd73b11131726a2b Author: Desmond Cheong Zhi Xi Date: Tue Aug 10 12:14:05 2021 +0800 Bluetooth: schedule SCO timeouts with delayed_work [ Upstream commit ba316be1b6a00db7126ed9a39f9bee434a508043 ] struct sock.sk_timer should be used as a sock cleanup timer. However, SCO uses it to implement sock timeouts. This causes issues because struct sock.sk_timer's callback is run in an IRQ context, and the timer callback function sco_sock_timeout takes a spin lock on the socket. However, other functions such as sco_conn_del and sco_conn_ready take the spin lock with interrupts enabled. This inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} lock usage could lead to deadlocks as reported by Syzbot [1]: CPU0 ---- lock(slock-AF_BLUETOOTH-BTPROTO_SCO); lock(slock-AF_BLUETOOTH-BTPROTO_SCO); To fix this, we use delayed work to implement SCO sock timouts instead. This allows us to avoid taking the spin lock on the socket in an IRQ context, and corrects the misuse of struct sock.sk_timer. As a note, cancel_delayed_work is used instead of cancel_delayed_work_sync in sco_sock_set_timer and sco_sock_clear_timer to avoid a deadlock. In the future, the call to bh_lock_sock inside sco_sock_timeout should be changed to lock_sock to synchronize with other functions using lock_sock. However, since sco_sock_set_timer and sco_sock_clear_timer are sometimes called under the locked socket (in sco_connect and __sco_sock_close), cancel_delayed_work_sync might cause them to sleep until an sco_sock_timeout that has started finishes running. But sco_sock_timeout would also sleep until it can grab the lock_sock. Using cancel_delayed_work is fine because sco_sock_timeout does not change from run to run, hence there is no functional difference between: 1. waiting for a timeout to finish running before scheduling another timeout 2. scheduling another timeout while a timeout is running. Link: https://syzkaller.appspot.com/bug?id=9089d89de0502e120f234ca0fc8a703f7368b31e [1] Reported-by: syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Tested-by: syzbot+2f6d7c28bb4bf7e82060@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 5b909c8118f4770e3e76f5fc5f54040a5df31e02 Author: Fabio Aiuto Date: Sat Aug 7 11:48:00 2021 +0200 staging: rtl8723bs: fix right side of condition [ Upstream commit e3678dc1ea40425b7218c20e2fe7b00a72f23a41 ] TxNum value is compared against ODM_RF_PATH_D, which is inconsistent. Compare it against RF_MAX_TX_NUM, as in other places in the same file. Signed-off-by: Fabio Aiuto Link: https://lore.kernel.org/r/147631fe6f4f5de84cc54a62ba71d739b92697be.1628329348.git.fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 55d64a9332f1dc248a83f6f1fa19f8d565b5fb47 Author: Desmond Cheong Zhi Xi Date: Sat Jul 24 19:18:24 2021 +0800 drm/vmwgfx: fix potential UAF in vmwgfx_surface.c [ Upstream commit 2bc5da528dd570c5ecabc107e6fbdbc55974276f ] drm_file.master should be protected by either drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, drm_master_get is called on unprotected file_priv->master pointers in vmw_surface_define_ioctl and vmw_gb_surface_define_internal. This is fixed by replacing drm_master_get with drm_file_get_master. Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Daniel Vetter Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20210724111824.59266-4-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit 9805ba303524c6164d14157613a7797722e09072 Author: Jussi Maki Date: Sat Jul 31 05:57:37 2021 +0000 selftests/bpf: Fix xdp_tx.c prog section name [ Upstream commit 95413846cca37f20000dd095cf6d91f8777129d7 ] The program type cannot be deduced from 'tx' which causes an invalid argument error when trying to load xdp_tx.o using the skeleton. Rename the section name to "xdp" so that libbpf can deduce the type. Signed-off-by: Jussi Maki Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210731055738.16820-7-joamaki@gmail.com Signed-off-by: Sasha Levin commit d5e688b6be272d6b3999d2463e39a77dc52bc411 Author: Roy Chan Date: Mon Jul 19 19:00:22 2021 -0400 drm/amd/display: fix incorrect CM/TF programming sequence in dwb [ Upstream commit 781e1e23131cce56fb557e6ec2260480a6bd08cc ] [How] the programming sequeune was for old asic. the correct programming sequeunce should be similar to the one used in mpc. the fix is copied from the mpc programming sequeunce. Reviewed-by: Anthony Koo Acked-by: Anson Jacob Signed-off-by: Roy Chan Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 240de7d5c6aaa06a95c521e15420af549d3e1fb1 Author: Roy Chan Date: Wed Jul 21 19:33:26 2021 -0400 drm/amd/display: fix missing writeback disablement if plane is removed [ Upstream commit 82367e7f22d085092728f45fd5fbb15e3fb997c0 ] [Why] If the plane has been removed, the writeback disablement logic doesn't run [How] fix the logic order Acked-by: Anson Jacob Signed-off-by: Roy Chan Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 55d743501185db196686ef90ea0570e6caf0bdb8 Author: Sanjay R Mehta Date: Tue Aug 3 07:34:56 2021 -0500 thunderbolt: Fix port linking by checking all adapters [ Upstream commit 42716425ad7e1b6529ec61c260c11176841f4b5f ] In tb_switch_default_link_ports(), while linking of ports, only odd-numbered ports (1,3,5..) are considered and even-numbered ports are not considered. AMD host router has lane adapters at 2 and 3 and link ports at adapter 2 is not considered due to which lane bonding gets disabled. Hence added a fix such that all ports are considered during linking of ports. Signed-off-by: Basavaraj Natikar Signed-off-by: Sanjay R Mehta Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin commit 6b7b49da95c4ea85337a02b3bdf897e2d622fbd6 Author: Linus Walleij Date: Wed Jul 28 10:39:34 2021 +0200 ARM: dts: ixp4xx: Fix up bad interrupt flags [ Upstream commit f775d2150cb48bece63270fdefc2a0c69cf17f0f ] The PCI hosts had bad IRQ semantics, these are all active low. Use the proper define and fix all in-tree users. Suggested-by: Marc Zyngier Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 641b3b86a3b28fd8e2f8a4eba6371f550018ce2c Author: Quanyang Wang Date: Tue Mar 23 10:55:01 2021 +0800 drm: xlnx: zynqmp: release reset to DP controller before accessing DP registers [ Upstream commit a338619bd76011035d462f0f9e8b2f24d7fe5a1e ] When insmod zynqmp-dpsub.ko after rmmod it, system will hang with the error log as below: root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko [ 88.391289] [drm] Initialized zynqmp-dpsub 1.0.0 20130509 for fd4a0000.display on minor 0 [ 88.529906] Console: switching to colour frame buffer device 128x48 [ 88.549402] zynqmp-dpsub fd4a0000.display: [drm] fb0: zynqmp-dpsubdrm frame buffer device [ 88.571624] zynqmp-dpsub fd4a0000.display: ZynqMP DisplayPort Subsystem driver probed root@xilinx-zynqmp:~# rmmod zynqmp_dpsub [ 94.023404] Console: switching to colour dummy device 80x25 root@xilinx-zynqmp:~# insmod zynqmp-dpsub.ko This is because that in zynqmp_dp_probe it tries to access some DP registers while the DP controller is still in the reset state. When running "rmmod zynqmp_dpsub", zynqmp_dp_reset(dp, true) in zynqmp_dp_phy_exit is called to force the DP controller into the reset state. Then insmod will call zynqmp_dp_probe to program the DP registers, but at this moment the DP controller hasn't been brought out of the reset state yet since the function zynqmp_dp_reset(dp, false) is called later and this will result the system hang. Releasing the reset to DP controller before any read/write operation to it will fix this issue. And for symmetry, move zynqmp_dp_reset() call from zynqmp_dp_phy_exit() to zynqmp_dp_remove(). Signed-off-by: Quanyang Wang Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit 99629ea392a1809052124e23aba6f0aed908aec8 Author: Quanyang Wang Date: Wed Mar 10 12:59:45 2021 +0800 drm: xlnx: zynqmp_dpsub: Call pm_runtime_get_sync before setting pixel clock [ Upstream commit a19effb6dbe5bd1be77a6d68eba04dba8993ffeb ] The Runtime PM subsystem will force the device "fd4a0000.zynqmp-display" to enter suspend state while booting if the following conditions are met: - the usage counter is zero (pm_runtime_get_sync hasn't been called yet) - no 'active' children (no zynqmp-dp-snd-xx node under dpsub node) - no other device in the same power domain (dpdma node has no "power-domains = <&zynqmp_firmware PD_DP>" property) So there is a scenario as below: 1) DP device enters suspend state <- call zynqmp_gpd_power_off 2) zynqmp_disp_crtc_setup_clock <- configurate register VPLL_FRAC_CFG 3) pm_runtime_get_sync <- call zynqmp_gpd_power_on and clear previous VPLL_FRAC_CFG configuration 4) clk_prepare_enable(disp->pclk) <- enable failed since VPLL_FRAC_CFG configuration is corrupted From above, we can see that pm_runtime_get_sync may clear register VPLL_FRAC_CFG configuration and result the failure of clk enabling. Putting pm_runtime_get_sync at the very beginning of the function zynqmp_disp_crtc_atomic_enable can resolve this issue. Signed-off-by: Quanyang Wang Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin commit b02ab9c0625e2a74be14fa1d8973e590e877e142 Author: Konrad Dybcio Date: Thu Jul 29 00:20:54 2021 +0200 drm/msm/dsi: Fix DSI and DSI PHY regulator config from SDM660 [ Upstream commit 462f7017a6918d152870bfb8852f3c70fd74b296 ] VDDA is not present and the specified load value is wrong. Fix it. Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222057.52641-1-konrad.dybcio@somainline.org Reviewed-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit a4d604d85d214afb9e5d822e2f8c233db1f0cc0c Author: David Heidelberg Date: Thu Jul 15 08:09:25 2021 +0200 drm/msm: mdp4: drop vblank get/put from prepare/complete_commit [ Upstream commit 56bd931ae506730c9ab1e4cc4bfefa43fc2d18fa ] msm_atomic is doing vblank get/put's already, currently there no need to duplicate the effort in MDP4 Fix warning: ... WARNING: CPU: 3 PID: 79 at drivers/gpu/drm/drm_vblank.c:1194 drm_vblank_put+0x1cc/0x1d4 ... and multiple vblank time-outs: ... msm 5100000.mdp: vblank time out, crtc=1 ... Tested on Nexus 7 2013 (deb), LTS 5.10.50. Introduced by: 119ecb7fd3b5 ("drm/msm/mdp4: request vblank during modeset") Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210715060925.7880-1-david@ixit.cz Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6a2668fd50691ca8c2ebe443fcec2d0c6c97cbaf Author: Nathan Chancellor Date: Fri Aug 6 12:13:40 2021 -0700 net: ethernet: stmmac: Do not use unreachable() in ipq806x_gmac_probe() [ Upstream commit 4367355dd90942a71641c98c40c74589c9bddf90 ] When compiling with clang in certain configurations, an objtool warning appears: drivers/net/ethernet/stmicro/stmmac/dwmac-ipq806x.o: warning: objtool: ipq806x_gmac_probe() falls through to next function phy_modes() This happens because the unreachable annotation in the third switch statement is not eliminated. The compiler should know that the first default case would prevent the second and third from being reached as the comment notes but sanitizer options can make it harder for the compiler to reason this out. Help the compiler out by eliminating the unreachable() annotation and unifying the default case error handling so that there is no objtool warning, the meaning of the code stays the same, and there is less duplication. Reported-by: Sami Tolvanen Tested-by: Sami Tolvanen Signed-off-by: Nathan Chancellor Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5644c0a5f033e0e2fb659560f1b28de9d805035c Author: Rajendra Nayak Date: Fri Aug 6 09:59:45 2021 +0100 nvmem: qfprom: Fix up qfprom_disable_fuse_blowing() ordering [ Upstream commit 11c4b3e264d68ba6dcd52d12dbcfd3f564f2f137 ] qfprom_disable_fuse_blowing() disables a bunch of resources, and then does a few register writes in the 'conf' address space. It works perhaps because the resources are needed only for the 'raw' register space writes, and that the 'conf' space allows read/writes regardless. However that makes the code look confusing, so just move the register writes before turning off the resources in the function. Reviewed-by: Douglas Anderson Signed-off-by: Rajendra Nayak Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210806085947.22682-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a2fab0a570bc487f5fe9cf78a0996148585c2598 Author: Georgi Djakov Date: Thu Feb 11 21:36:37 2021 +0200 arm64: dts: qcom: sm8250: Fix epss_l3 unit address [ Upstream commit 77b53d65dc1e54321ec841912f06bcb558a079c0 ] The unit address of the epss_l3 node is incorrect and does not match the address of its "reg" property. Let's fix it. Signed-off-by: Georgi Djakov Reviewed-by: Dmitry Baryshkov Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210211193637.9737-1-georgi.djakov@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c35f98b5be6a34e9d08b6a9fc00b524a88c1211e Author: Vinod Koul Date: Mon Mar 8 11:38:17 2021 +0530 arm64: dts: qcom: msm8996: don't use underscore in node name [ Upstream commit 84f3efbe5b4654077608bc2fc027177fe4592321 ] We have underscore (_) in node name leading to warning: arch/arm64/boot/dts/qcom/apq8096-db820c.dt.yaml: clocks: $nodename:0: 'clocks' does not match '^([a-z][a-z0-9\\-]+-bus|bus|soc|axi|ahb|apb)(@[0-9a-f]+)?$' arch/arm64/boot/dts/qcom/apq8096-db820c.dt.yaml: clocks: xo_board: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[19200000]], 'clock-output-names': ['xo_board'], 'phandle': [[115]]} Fix this by changing node name to use dash (-) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-10-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit a8ab2e5e943c86c019ccd4ba3f56d4722c393b3e Author: Vinod Koul Date: Mon Mar 8 11:38:16 2021 +0530 arm64: dts: qcom: msm8994: don't use underscore in node name [ Upstream commit 8c678beca7ed3fa8a2c6d86f6603bc23400f9ad8 ] We have underscore (_) in node name leading to warning: arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dt.yaml: clocks: xo_board: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[19200000]], 'phandle': [[26]]} arch/arm64/boot/dts/qcom/msm8994-msft-lumia-octagon-cityman.dt.yaml: clocks: sleep_clk: {'type': 'object'} is not allowed for {'compatible': ['fixed-clock'], '#clock-cells': [[0]], 'clock-frequency': [[32768]]} Fix this by changing node name to use dash (-) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-9-vkoul@kernel.org [bjorn: Added clock-output-names to satisfy parent_names] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 734b25e1b5e30864b2db9ca7803d362949abb5b4 Author: Vinod Koul Date: Mon Mar 8 11:38:18 2021 +0530 arm64: dts: qcom: sdm630: don't use underscore in node name [ Upstream commit 639dfdbecd88ec05bda87b1d5d419afad50af21c ] We have underscore (_) in node name so fix that up as well. Fix this by changing node name to use dash (-) Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-11-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bb4d913e00b8ccfdcf40c46930548ec14687d4cb Author: Vinod Koul Date: Mon Mar 8 11:38:26 2021 +0530 arm64: dts: qcom: ipq6018: drop '0x' from unit address [ Upstream commit 1b91b8ef60e9a67141e66af3cca532c00f4605fe ] Nodes need not contain '0x' for the unit address. Drop it to fix the below warning: arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml: reserved-memory: 'memory@0x60000' does not match any of the regexes Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-19-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit c5816f20e63e6b538c759cc70795986bb500ccc3 Author: Vinod Koul Date: Mon Mar 8 11:38:25 2021 +0530 arm64: dts: qcom: sdm660: use reg value for memory node [ Upstream commit c81210e38966cfa1c784364e4035081c3227cf5b ] memory node like other node should be node@reg, which is missing in this case, so fix it up arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 1073741824, 0, 536870912]]} Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-18-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit f440894c55e4fd8668a6ac60cabaf0a8c1ca7671 Author: Vinod Koul Date: Mon Mar 8 11:38:24 2021 +0530 arm64: dts: qcom: ipq8074: fix pci node reg property [ Upstream commit 52c9887fba71fc8f12d343833fc595c762aac8c7 ] reg property should be array of values, here it is a single array, leading to below warning: arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@10000000:reg:0: [268435456, 3869, 268439328, 168, 557056, 8192, 269484032, 4096] is too long arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@10000000:ranges: 'oneOf' conditional failed, one must be fixed: arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@10000000:ranges: 'oneOf' conditional failed, one must be fixed: [[2164260864, 0, 270532608, 270532608, 0, 1048576, 2181038080, 0, 271581184, 271581184, 0, 13631488]] is not of type 'null' [2164260864, 0, 270532608, 270532608, 0, 1048576, 2181038080, 0, 271581184, 271581184, 0, 13631488] is too long arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@20000000:reg:0: [536870912, 3869, 536874784, 168, 524288, 8192, 537919488, 4096] is too long arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@20000000:ranges: 'oneOf' conditional failed, one must be fixed: arch/arm64/boot/dts/qcom/ipq8074-hk01.dt.yaml: soc: pci@20000000:ranges: 'oneOf' conditional failed, one must be fixed: [[2164260864, 0, 538968064, 538968064, 0, 1048576, 2181038080, 0, 540016640, 540016640, 0, 13631488]] is not of type 'null' [2164260864, 0, 538968064, 538968064, 0, 1048576, 2181038080, 0, 540016640, 540016640, 0, 13631488] is too long Signed-off-by: Vinod Koul Link: https://lore.kernel.org/r/20210308060826.3074234-17-vkoul@kernel.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6c9be25d4051c9a720d1ad573f3e8080f9321403 Author: Sebastian Reichel Date: Mon Aug 2 19:23:08 2021 +0200 ARM: dts: imx53-ppd: Fix ACHC entry [ Upstream commit cd7cd5b716d594e27a933c12f026d4f2426d7bf4 ] PPD has only one ACHC device, which effectively is a Kinetis microcontroller. It has one SPI interface used for normal communication. Additionally it's possible to flash the device firmware using NXP's EzPort protocol by correctly driving a second chip select pin and the device reset pin. Signed-off-by: Sebastian Reichel Link: https://lore.kernel.org/r/20210802172309.164365-3-sebastian.reichel@collabora.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cee064a25d2842573530c32f7de282c616b338a8 Author: Mikko Perttunen Date: Thu Jul 15 13:34:23 2021 +0300 misc: sram: Only map reserved areas in Tegra SYSRAM [ Upstream commit fec29bf04994b478a43a7e60e6dd5ac1f7cb53ae ] On Tegra186 and later, a portion of the SYSRAM may be reserved for use by TZ. Non-TZ memory accesses to this portion, including speculative accesses, trigger SErrors that bring down the system. This does also happen in practice occasionally (due to speculative accesses). To fix the issue, add a flag to the SRAM driver to only map the device tree-specified reserved areas depending on a flag set based on the compatibility string. This would not affect non-Tegra systems that rely on the entire thing being memory mapped. If 64K pages are being used, we cannot exactly map the 4K regions that are placed in SYSRAM - ioremap code instead aligns to closest 64K pages. However, since in practice the non-accessible memory area is 64K aligned, these mappings do not overlap with the non-accessible memory area and things work out. Reviewed-by: Mian Yousaf Kaukab Signed-off-by: Mikko Perttunen Link: https://lore.kernel.org/r/20210715103423.1811101-1-mperttunen@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9a1de9db921a0f39445e92e8f4a1a84ea85b43c1 Author: Tony Lindgren Date: Tue Jul 27 13:35:33 2021 +0300 serial: 8250_omap: Handle optional overrun-throttle-ms property [ Upstream commit 1fe0e1fa3209ad8e9124147775bd27b1d9f04bd4 ] Handle optional overrun-throttle-ms property as done for 8250_fsl in commit 6d7f677a2afa ("serial: 8250: Rate limit serial port rx interrupts during input overruns"). This can be used to rate limit the UART interrupts on noisy lines that end up producing messages like the following: ttyS ttyS2: 4 input overrun(s) At least on droid4, the multiplexed USB and UART port is left to UART mode by the bootloader for a debug console, and if a USB charger is connected on boot, we get noise on the UART until the PMIC related drivers for PHY and charger are loaded. With this patch and overrun-throttle-ms = <500> we avoid the extra rx interrupts. Cc: Carl Philipp Klemm Cc: Merlijn Wajer Cc: Pavel Machek Cc: Sebastian Reichel Cc: Vignesh Raghavendra Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210727103533.51547-2-tony@atomide.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9e9d59f7e83ea054e9a68e038bb27defd16ade6a Author: Alex Elder Date: Wed Aug 4 08:54:07 2021 -0500 net: ipa: fix IPA v4.9 interconnects [ Upstream commit 0fd75f5760b6a7a7f35dff46a6cdc4f6d1a86ee8 ] Three interconnects are defined for IPA version 4.9, but there should only be two. They should also use names that match what's used for other platforms (and specified in the Device Tree binding). Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d491b7b41a708a4221896702debd44b6c220d483 Author: AngeloGioacchino Del Regno Date: Thu Jul 29 00:25:11 2021 +0200 arm64: dts: qcom: sdm630: Fix TLMM node and pinctrl configuration [ Upstream commit 36a0d47aee6a8cfd3c6cf4274732d8ef994a25b4 ] Previous pinctrl configuration was wrong. Fix it and clean up how multi-pin states are described. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222542.54269-9-konrad.dybcio@somainline.org [bjorn: Polished the commit message] Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit da59af86180052e9c0e0caaa0afa540f93432357 Author: AngeloGioacchino Del Regno Date: Thu Jul 29 00:25:04 2021 +0200 arm64: dts: qcom: sdm630: Rewrite memory map [ Upstream commit 26e02c98a9ad63eb21b9be4ac92002f555130d3b ] The memory map was wrong. Fix it. Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20210728222542.54269-2-konrad.dybcio@somainline.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit ccdeb0110a977d1256196f3bffaf180b0c09c2c5 Author: Bob Peterson Date: Tue Jun 1 09:41:40 2021 -0500 gfs2: Fix glock recursion in freeze_go_xmote_bh [ Upstream commit 9d9b16054b7d357afde69a027514c695092b0d22 ] We must not call gfs2_consist (which does a file system withdraw) from the freeze glock's freeze_go_xmote_bh function because the withdraw will try to use the freeze glock, thus causing a glock recursion error. This patch changes freeze_go_xmote_bh to call function gfs2_assert_withdraw_delayed instead of gfs2_consist to avoid recursion. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit 522e057d79ced7f90508671cc5ff171519cc556a Author: Evgeny Novikov Date: Wed Jul 28 16:44:32 2021 +0200 media: tegra-cec: Handle errors of clk_prepare_enable() [ Upstream commit 38367073c796a37a61549b1f66a71b3adb03802d ] tegra_cec_probe() and tegra_cec_resume() ignored possible errors of clk_prepare_enable(). The patch fixes this. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8c3ab2d193ef04caaa57ded117ca09c2cc0e970d Author: Krzysztof Hałasa Date: Mon Jul 26 12:46:28 2021 +0200 media: TDA1997x: fix tda1997x_query_dv_timings() return value [ Upstream commit 7dee1030871a48d4f3c5a74227a4b4188463479a ] Correctly propagate the tda1997x_detect_std error value. Signed-off-by: Krzysztof Hałasa Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4fd18883967f3fb922de767280508647b85d6e4f Author: Hans Verkuil Date: Fri Jul 23 10:22:59 2021 +0200 media: v4l2-dv-timings.c: fix wrong condition in two for-loops [ Upstream commit 4108b3e6db31acc4c68133290bbcc87d4db905c9 ] These for-loops should test against v4l2_dv_timings_presets[i].bt.width, not if i < v4l2_dv_timings_presets[i].bt.width. Luckily nothing ever broke, since the smallest width is still a lot higher than the total number of presets, but it is wrong. The last item in the presets array is all 0, so the for-loop must stop when it reaches that sentinel. Signed-off-by: Hans Verkuil Reported-by: Krzysztof Hałasa Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3ed161da6e52464723b27d51f3eab8cb536e2bde Author: Laurent Pinchart Date: Wed May 12 01:44:40 2021 +0200 media: imx: imx7-media-csi: Fix buffer return upon stream start failure [ Upstream commit 0ada1697ed4256b38225319c9896661142a3572d ] When the stream fails to start, the first two buffers in the queue have been moved to the active_vb2_buf array and are returned to vb2 by imx7_csi_dma_unsetup_vb2_buf(). The function is called with the buffer state set to VB2_BUF_STATE_ERROR unconditionally, which is correct when stopping the stream, but not when the start operation fails. In that case, the state should be set to VB2_BUF_STATE_QUEUED. Fix it. Signed-off-by: Laurent Pinchart Tested-by: Martin Kepplinger Reviewed-by: Rui Miguel Silva Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f3d1566d8c978fed1f6261b00af2a02aeba31676 Author: Umang Jain Date: Fri Jul 23 13:22:33 2021 +0200 media: imx258: Limit the max analogue gain to 480 [ Upstream commit f809665ee75fff3f4ea8907f406a66d380aeb184 ] The range for analog gain mentioned in the datasheet is [0, 480]. The real gain formula mentioned in the datasheet is: Gain = 512 / (512 – X) Hence, values larger than 511 clearly makes no sense. The gain register field is also documented to be of 9-bits in the datasheet. Certainly, it is enough to infer that, the kernel driver currently advertises an arbitrary analog gain max. Fix it by rectifying the value as per the data sheet i.e. 480. Signed-off-by: Umang Jain Reviewed-by: Laurent Pinchart Reviewed-by: Dave Stevenson Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit baf065470594589b49ea860baa1de118ef752f75 Author: Laurent Pinchart Date: Fri Jul 23 13:22:32 2021 +0200 media: imx258: Rectify mismatch of VTS value [ Upstream commit 51f93add3669f1b1f540de1cf397815afbd4c756 ] The frame_length_lines (0x0340) registers are hard-coded as follows: - 4208x3118 frame_length_lines = 0x0c50 - 2104x1560 frame_length_lines = 0x0638 - 1048x780 frame_length_lines = 0x034c The driver exposes the V4L2_CID_VBLANK control in read-only mode and sets its value to vts_def - height, where vts_def is a mode-dependent value coming from the supported_modes array. It is set using one of the following macros defined in the driver: #define IMX258_VTS_30FPS 0x0c98 #define IMX258_VTS_30FPS_2K 0x0638 #define IMX258_VTS_30FPS_VGA 0x034c There's a clear mismatch in the value for the full resolution mode i.e. IMX258_VTS_30FPS. Fix it by rectifying the macro with the value set for the frame_length_lines register as stated above. Signed-off-by: Laurent Pinchart Signed-off-by: Umang Jain Reviewed-by: Bingbu Cao Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d060cc23e9bfcda89ac3278d982744a980cf7ebb Author: Ioana Ciornei Date: Tue Aug 3 19:57:40 2021 +0300 dpaa2-switch: do not enable the DPSW at probe time [ Upstream commit 042ad90ca7ce70f35dc5efd5b2043d2f8aceb12a ] We should not enable the switch interfaces at probe time since this is trigged by the open callback. Remove the call dpsw_enable() which does exactly this. Signed-off-by: Ioana Ciornei Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 653acdd0ba38a3ce240d5f16bcc5aff4aaa1d9a9 Author: Luiz Augusto von Dentz Date: Mon Aug 2 16:56:19 2021 -0700 Bluetooth: Fix not generating RPA when required [ Upstream commit c45074d68a9b1e893d86520af71fab37693c3d7e ] Code was checking if random_addr and hdev->rpa match without first checking if the RPA has not been set (BDADDR_ANY), furthermore it was clearing HCI_RPA_EXPIRED before the command completes and the RPA is actually programmed which in case of failure would leave the expired RPA still set. Since advertising instance have a similar problem the clearing of HCI_RPA_EXPIRED has been moved to hci_event.c after checking the random address is in fact the hdev->rap and then proceed to set the expire timeout. Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit cd86be47849b4031fabe61221a26faf4ed4f4006 Author: Pierre-Louis Bossart Date: Mon Aug 2 10:21:50 2021 -0500 ASoC: Intel: update sof_pcm512x quirks [ Upstream commit 22414cade8dfec25ab94df52b3a4f7aa8edb6120 ] The default SOF topology enables SSP capture and DMICs, even though both of these hardware capabilities are not always available in hardware (specific versions of HiFiberry and DMIC kit needed). For the SSP capture, this leads to annoying "SP5-Codec: ASoC: no backend capture" and "streamSSP5-Codec: ASoC: no users capture at close - state 0" errors. Update the quirks to match what the topology needs, which also allows for the ability to remove SSP capture and DMIC support. BugLink: https://github.com/thesofproject/linux/issues/3061 Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20210802152151.15832-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 216c05073e21d824bb14015f5aa11a528823d9ad Author: Hans de Goede Date: Mon Aug 2 16:24:56 2021 +0200 ASoC: Intel: bytcr_rt5640: Move "Platform Clock" routes to the maps for the matching in-/output [ Upstream commit dccd1dfd0770bfd494b68d1135b4547b2c602c42 ] Move the "Platform Clock" routes for the "Internal Mic" and "Speaker" routes to the intmic_*_map[] / *_spk_map[] arrays. This ensures that these "Platform Clock" routes do not get added when the BYT_RT5640_NO_INTERNAL_MIC_MAP / BYT_RT5640_NO_SPEAKERS quirks are used. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210802142501.991985-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 26f7e72650285ada54c390bf2515835162e97fd5 Author: Vidya Sagar Date: Wed Jul 28 00:20:55 2021 +0530 arm64: tegra: Fix Tegra194 PCIe EP compatible string [ Upstream commit bf2942a8b7c38e8cc2d5157b4f0323d7f4e5ec71 ] The initialization sequence performed by the generic platform driver pcie-designware-plat.c for a DWC based implementation doesn't work for Tegra194. Tegra194 has a different initialization sequence requirement which can only be satisfied by the Tegra194 specific platform driver pcie-tegra194.c. So, remove the generic compatible string "snps,dw-pcie-ep" from Tegra194's endpoint controller nodes. Signed-off-by: Vidya Sagar Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit b6409157449bff341a163e31722fd26876b50de3 Author: Nicolas Ferre Date: Thu Jul 29 16:28:27 2021 +0200 ARM: dts: at91: use the right property for shutdown controller [ Upstream commit 818c4593434e81c9971b8fc278215121622c755e ] The wrong property "atmel,shdwc-debouncer" was used to specify the debounce delay for the shutdown controler. Replace it with the documented and implemented property "debounce-delay-us", as mentioned in v4 driver submission. See: https://lore.kernel.org/r/1458134390-23847-3-git-send-email-nicolas.ferre@atmel.com/ Signed-off-by: Nicolas Ferre Reported-by: Clément Léger Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/20210730172729.28093-1-nicolas.ferre@microchip.com/ Signed-off-by: Sasha Levin commit baf4e91f709ceca40347f8b0784a1e76ad50bf91 Author: Yufeng Mo Date: Fri Jul 30 10:19:11 2021 +0800 bonding: 3ad: fix the concurrency between __bond_release_one() and bond_3ad_state_machine_handler() [ Upstream commit 220ade77452c15ecb1ab94c3f8aaeb6d033c3582 ] Some time ago, I reported a calltrace issue "did not find a suitable aggregator", please see[1]. After a period of analysis and reproduction, I find that this problem is caused by concurrency. Before the problem occurs, the bond structure is like follows: bond0 - slaver0(eth0) - agg0.lag_ports -> port0 - port1 \ port0 \ slaver1(eth1) - agg1.lag_ports -> NULL \ port1 If we run 'ifenslave bond0 -d eth1', the process is like below: excuting __bond_release_one() | bond_upper_dev_unlink()[step1] | | | | | bond_3ad_lacpdu_recv() | | ->bond_3ad_rx_indication() | | spin_lock_bh() | | ->ad_rx_machine() | | ->__record_pdu()[step2] | | spin_unlock_bh() | | | | bond_3ad_state_machine_handler() | spin_lock_bh() | ->ad_port_selection_logic() | ->try to find free aggregator[step3] | ->try to find suitable aggregator[step4] | ->did not find a suitable aggregator[step5] | spin_unlock_bh() | | | | bond_3ad_unbind_slave() | spin_lock_bh() spin_unlock_bh() step1: already removed slaver1(eth1) from list, but port1 remains step2: receive a lacpdu and update port0 step3: port0 will be removed from agg0.lag_ports. The struct is "agg0.lag_ports -> port1" now, and agg0 is not free. At the same time, slaver1/agg1 has been removed from the list by step1. So we can't find a free aggregator now. step4: can't find suitable aggregator because of step2 step5: cause a calltrace since port->aggregator is NULL To solve this concurrency problem, put bond_upper_dev_unlink() after bond_3ad_unbind_slave(). In this way, we can invalid the port first and skip this port in bond_3ad_state_machine_handler(). This eliminates the situation that the slaver has been removed from the list but the port is still valid. [1]https://lore.kernel.org/netdev/10374.1611947473@famine/ Signed-off-by: Yufeng Mo Acked-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bef27fe6d43f769bd1d7b82b89d549cd5cc14cc3 Author: Pablo Neira Ayuso Date: Thu Jul 15 11:11:26 2021 +0200 netfilter: nft_compat: use nfnetlink_unicast() [ Upstream commit 241d1af4c11a75d4c17ecc0193a6ab60553efbfc ] Use nfnetlink_unicast() which already translates EAGAIN to ENOBUFS, since EAGAIN is reserved to report missing module dependencies to the nfnetlink core. e0241ae6ac59 ("netfilter: use nfnetlink_unicast() forgot to update this spot. Reported-by: Yajun Deng Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2e9fad2fa7414c197bac031875ed0a23cae6b678 Author: Akhil P Oommen Date: Fri Jul 30 01:21:23 2021 +0530 drm/msm/a6xx: Fix llcc configuration for a660 gpu [ Upstream commit a6f24383f6c0a8d64d1f6afa10733ae4e8f236e0 ] Add the missing scache_cntl0 register programing which is required for a660 gpu. Signed-off-by: Akhil P Oommen Link: https://lore.kernel.org/r/20210730011945.v4.1.I110b87677ef16d97397fb7c81c07a16e1f5d211e@changeid Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit c32ba4de30f9873775569caf90528007bb48261e Author: Marek Vasut Date: Sun Jun 20 23:24:31 2021 +0200 ARM: dts: stm32: Update AV96 adv7513 node per dtbs_check [ Upstream commit 1e6bc5987a5252948e3411e5a2dbb434fd1ea107 ] Swap reg and reg-names order and drop adi,input-justification and adi,input-style to fix the following dtbs_check warnings: arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: adi,input-justification: False schema does not allow ['evenly'] arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: adi,input-style: False schema does not allow [[1]] arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: reg-names:1: 'edid' was expected arch/arm/boot/dts/stm32mp157a-dhcor-avenger96.dt.yaml: hdmi-transmitter@3d: reg-names:2: 'cec' was expected Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 6af7fc020646fd8491539015efc063930c55f0d1 Author: Marek Vasut Date: Thu Jun 10 17:03:06 2021 +0200 ARM: dts: stm32: Set {bitclock,frame}-master phandles on ST DKx [ Upstream commit 8aec45d7884f16cc21d668693c5b88bff8df0f02 ] Fix the following dtbs_check warning: cs42l51@4a: port:endpoint@0:frame-master: True is not of type 'array' cs42l51@4a: port:endpoint@0:bitclock-master: True is not of type 'array' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit adcce1952a9c1b55519994a90c55d7671687fc82 Author: Marek Vasut Date: Thu Jun 10 17:02:41 2021 +0200 ARM: dts: stm32: Set {bitclock,frame}-master phandles on DHCOM SoM [ Upstream commit a79e78c391dc074742c855dc0108a88f781d56a3 ] Fix the following dtbs_check warning: arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: codec@a: port:endpoint@0:frame-master: True is not of type 'array' arch/arm/boot/dts/stm32mp157c-dhcom-pdk2.dt.yaml: codec@a: port:endpoint@0:bitclock-master: True is not of type 'array' Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Patrice Chotard Cc: Patrick Delaunay Cc: kernel@dh-electronics.com Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit eae08fd62e287600bf44c37af89569d6bb829a17 Author: Zhen Lei Date: Thu Jul 22 11:03:52 2021 +0800 workqueue: Fix possible memory leaks in wq_numa_init() [ Upstream commit f728c4a9e8405caae69d4bc1232c54ff57b5d20f ] In error handling branch "if (WARN_ON(node == NUMA_NO_NODE))", the previously allocated memories are not released. Doing this before allocating memory eliminates memory leaks. tj: Note that the condition only occurs when the arch code is pretty broken and the WARN_ON might as well be BUG_ON(). Signed-off-by: Zhen Lei Reviewed-by: Lai Jiangshan Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 015bd32cf6fb3562756e22cceec12f818ee0eead Author: Desmond Cheong Zhi Xi Date: Wed Jul 28 15:51:04 2021 +0800 Bluetooth: skip invalid hci_sync_conn_complete_evt [ Upstream commit 92fe24a7db751b80925214ede43f8d2be792ea7b ] Syzbot reported a corrupted list in kobject_add_internal [1]. This happens when multiple HCI_EV_SYNC_CONN_COMPLETE event packets with status 0 are sent for the same HCI connection. This causes us to register the device more than once which corrupts the kset list. As this is forbidden behavior, we add a check for whether we're trying to process the same HCI_EV_SYNC_CONN_COMPLETE event multiple times for one connection. If that's the case, the event is invalid, so we report an error that the device is misbehaving, and ignore the packet. Link: https://syzkaller.appspot.com/bug?extid=66264bf2fd0476be7e6c [1] Reported-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Tested-by: syzbot+66264bf2fd0476be7e6c@syzkaller.appspotmail.com Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit fb6593a0617734375cebd626296461a509e902e2 Author: Laurent Pinchart Date: Tue Mar 23 02:09:53 2021 +0200 drm: rcar-du: Shutdown the display on system shutdown [ Upstream commit 015f2ebb93767d40c442e749642fffaf10316d78 ] When the system shuts down or warm reboots, the display may be active, with the hardware accessing system memory. Upon reboot, the DDR will not be accessible, which may cause issues. Implement the platform_driver .shutdown() operation and shut down the display to fix this. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham Signed-off-by: Sasha Levin commit 08e42d1a386d2e969bb548329a7bfd1a6428fc53 Author: Andy Shevchenko Date: Tue Jul 27 15:51:30 2021 +0300 ata: sata_dwc_460ex: No need to call phy_exit() befre phy_init() [ Upstream commit 3ad4a31620355358316fa08fcfab37b9d6c33347 ] Last change to device managed APIs cleaned up error path to simple phy_exit() call, which in some cases has been executed with NULL parameter. This per se is not a problem, but rather logical misconception: no need to free resource when it's for sure has not been allocated yet. Fix the driver accordingly. Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210727125130.19977-1-andriy.shevchenko@linux.intel.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 19192189e8d8d37074b3dcf83f6aef6406fed4cd Author: Martynas Pumputis Date: Mon Jul 26 17:20:01 2021 +0200 libbpf: Fix race when pinning maps in parallel [ Upstream commit 043c5bb3c4f43670ab4fea0b847373ab42d25f3e ] When loading in parallel multiple programs which use the same to-be pinned map, it is possible that two instances of the loader will call bpf_object__create_maps() at the same time. If the map doesn't exist when both instances call bpf_object__reuse_map(), then one of the instances will fail with EEXIST when calling bpf_map__pin(). Fix the race by retrying reusing a map if bpf_map__pin() returns EEXIST. The fix is similar to the one in iproute2: e4c4685fd6e4 ("bpf: Fix race condition with map pinning"). Before retrying the pinning, we don't do any special cleaning of an internal map state. The closer code inspection revealed that it's not required: - bpf_object__create_map(): map->inner_map is destroyed after a successful call, map->fd is closed if pinning fails. - bpf_object__populate_internal_map(): created map elements is destroyed upon close(map->fd). - init_map_slots(): slots are freed after their initialization. Signed-off-by: Martynas Pumputis Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210726152001.34845-1-m@lambda.lt Signed-off-by: Sasha Levin commit c08b1c123ffa0ab3a739020827ebb4265f2031ea Author: Juhee Kang Date: Tue Jul 27 04:10:55 2021 +0000 samples: bpf: Fix tracex7 error raised on the missing argument [ Upstream commit 7d07006f05922b95518be403f08ef8437b67aa32 ] The current behavior of 'tracex7' doesn't consist with other bpf samples tracex{1..6}. Other samples do not require any argument to run with, but tracex7 should be run with btrfs device argument. (it should be executed with test_override_return.sh) Currently, tracex7 doesn't have any description about how to run this program and raises an unexpected error. And this result might be confusing since users might not have a hunch about how to run this program. // Current behavior # ./tracex7 sh: 1: Syntax error: word unexpected (expecting ")") // Fixed behavior # ./tracex7 ERROR: Run with the btrfs device argument! In order to fix this error, this commit adds logic to report a message and exit when running this program with a missing argument. Additionally in test_override_return.sh, there is a problem with multiple directory(tmpmnt) creation. So in this commit adds a line with removing the directory with every execution. Signed-off-by: Juhee Kang Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210727041056.23455-1-claudiajkang@gmail.com Signed-off-by: Sasha Levin commit 153bc060ea9bc7651a8aa8c7e8e01bb375281f9d Author: Mikita Lipski Date: Wed Jul 14 06:41:13 2021 -0400 drm/amd/display: Fix PSR command version [ Upstream commit af1f2b19fd7d404d299355cc95930efee5b3ed8b ] [why] For dual eDP when setting the new settings we need to set command version to DMUB_CMD_PSR_CONTROL_VERSION_1, otherwise DMUB will not read panel_inst parameter. [how] Instead of PSR_VERSION_1 pass DMUB_CMD_PSR_CONTROL_VERSION_1 Reviewed-by: Wood Wyatt Acked-by: Solomon Chiu Signed-off-by: Mikita Lipski Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d0914e6fd3709fd5f3cef4875033a60998e232d3 Author: Christophe JAILLET Date: Wed Jul 21 10:45:11 2021 +0200 staging: ks7010: Fix the initialization of the 'sleep_status' structure [ Upstream commit 56315e55119c0ea57e142b6efb7c31208628ad86 ] 'sleep_status' has 3 atomic_t members. Initialize the 3 of them instead of initializing only 2 of them and setting 0 twice to the same variable. Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/d2e52a33a9beab41879551d0ae2fdfc99970adab.1626856991.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 789abe56f61b3d9dc5323907900215ec57afa31a Author: Greg Kroah-Hartman Date: Mon Jul 26 15:43:22 2021 +0200 vt: keyboard.c: make console an unsigned int [ Upstream commit 3df15d6f37246d2f12f53d915c41d806289d3d46 ] The console variable is used everywhere in some fun pointer path and array indexes and for some reason isn't always declared as unsigned. This plays havoc with some static analysis tools so mark the variable as unsigned so we "know" we can not wrap the arrays backwards here. Cc: Jiri Slaby Cc: Andy Shevchenko Reported-by: Jordy Zomer Link: https://lore.kernel.org/r/20210726134322.2274919-2-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 76832832d00d37677185b0d2beef6e2e0fa43ff2 Author: Greg Kroah-Hartman Date: Mon Jul 26 15:07:17 2021 +0200 serial: 8250_pci: make setup_port() parameters explicitly unsigned [ Upstream commit 3a96e97ab4e835078e6f27b7e1c0947814df3841 ] The bar and offset parameters to setup_port() are used in pointer math, and while it would be very difficult to get them to wrap as a negative number, just be "safe" and make them unsigned so that static checkers do not trip over them unintentionally. Cc: Jiri Slaby Reported-by: Jordy Zomer Link: https://lore.kernel.org/r/20210726130717.2052096-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e925c63c63df4ef3d29fede35a3490d96a5058d1 Author: Jiri Slaby Date: Fri Jul 23 09:43:11 2021 +0200 hvsi: don't panic on tty_register_driver failure [ Upstream commit 7ccbdcc4d08a6d7041e4849219bbb12ffa45db4c ] The alloc_tty_driver failure is handled gracefully in hvsi_init. But tty_register_driver is not. panic is called if that one fails. So handle the failure of tty_register_driver gracefully too. This will keep at least the console functional as it was enabled earlier by console_initcall in hvsi_console_init. Instead of shooting down the whole system. This means, we disable interrupts and restore hvsi_wait back to poll_for_state(). Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210723074317.32690-3-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9306f7fcc68e4ddfb439fbd2d327eee9f2902161 Author: Jiri Slaby Date: Fri Jul 23 09:43:10 2021 +0200 xtensa: ISS: don't panic in rs_init [ Upstream commit 23411c720052ad860b3e579ee4873511e367130a ] While alloc_tty_driver failure in rs_init would mean we have much bigger problem, there is no reason to panic when tty_register_driver fails there. It can fail for various reasons. So handle the failure gracefully. Actually handle them both while at it. This will make at least the console functional as it was enabled earlier by console_initcall in iss_console_init. Instead of shooting down the whole system. We move tty_port_init() after alloc_tty_driver(), so that we don't need to destroy the port in case the latter function fails. Cc: Chris Zankel Cc: Max Filippov Cc: linux-xtensa@linux-xtensa.org Acked-by: Max Filippov Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20210723074317.32690-2-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 422a2940a0b04fd5bfcf7e29cc9d5941b1ed5e6b Author: Andy Shevchenko Date: Fri Jul 23 15:59:43 2021 +0300 serial: max310x: Use clock-names property matching to recognize EXTCLK [ Upstream commit 3d1fa055ea7298345795b982de7a5b9ec6ae238d ] Dennis reported that on ACPI-based systems the clock frequency isn't enough to configure device properly. We have to respect the clock source as well. To achieve this match the clock-names property against "osc" to recognize external clock connection. On DT-based system this doesn't change anything. Reported-and-tested-by: Dennis Giaya Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210723125943.22039-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 84f8b1a65627337720675a7c82064fa05ff5afc9 Author: Maciej W. Rozycki Date: Sat Jun 26 06:11:51 2021 +0200 serial: 8250: Define RX trigger levels for OxSemi 950 devices [ Upstream commit d7aff291d069c4418285f3c8ee27b0ff67ce5998 ] Oxford Semiconductor 950 serial port devices have a 128-byte FIFO and in the enhanced (650) mode, which we select in `autoconfig_has_efr' with the ECB bit set in the EFR register, they support the receive interrupt trigger level selectable with FCR bits 7:6 from the set of 16, 32, 112, 120. This applies to the original OX16C950 discrete UART[1] as well as 950 cores embedded into more complex devices. For these devices we set the default to 112, which sets an excessively high level of 112 or 7/8 of the FIFO capacity, unlike with other port types where we choose at most 1/2 of their respective FIFO capacities. Additionally we don't make the trigger level configurable. Consequently frequent input overruns happen with high bit rates where hardware flow control cannot be used (e.g. terminal applications) even with otherwise highly-performant systems. Lower the default receive interrupt trigger level to 32 then, and make it configurable. Document the trigger levels along with other port types, including the set of 16, 32, 64, 112 for the transmit interrupt as well[2]. References: [1] "OX16C950 rev B High Performance UART with 128 byte FIFOs", Oxford Semiconductor, Inc., DS-0031, Sep 05, Table 10: "Receiver Trigger Levels", p. 22 [2] same, Table 9: "Transmit Interrupt Trigger Levels", p. 22 Signed-off-by: Maciej W. Rozycki Link: https://lore.kernel.org/r/alpine.DEB.2.21.2106260608480.37803@angie.orcam.me.uk Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c838aa01e3b14ee177ad1c4dd38ce8b45b0575f2 Author: Niklas Schnelle Date: Thu Jul 8 14:55:42 2021 +0200 s390: make PCI mio support a machine flag [ Upstream commit 3322ba0d7bea1e24ae464418626f6a15b69533ab ] Kernel support for the newer PCI mio instructions can be toggled off with the pci=nomio command line option which needs to integrate with common code PCI option parsing. However this option then toggles static branches which can't be toggled yet in an early_param() call. Thus commit 9964f396f1d0 ("s390: fix setting of mio addressing control") moved toggling the static branches to the PCI init routine. With this setup however we can't check for mio support outside the PCI code during early boot, i.e. before switching the static branches, which we need to be able to export this as an ELF HWCAP. Improve on this by turning mio availability into a machine flag that gets initially set based on CONFIG_PCI and the facility bit and gets toggled off if pci=nomio is found during PCI option parsing allowing simple access to this machine flag after early init. Reviewed-by: Heiko Carstens Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit ba260e069fef89eb260dc0cf19321b64b0f05ea5 Author: Heiko Carstens Date: Mon Jul 12 19:26:01 2021 +0200 s390/jump_label: print real address in a case of a jump label bug [ Upstream commit 5492886c14744d239e87f1b0b774b5a341e755cc ] In case of a jump label print the real address of the piece of code where a mismatch was detected. This is right before the system panics, so there is nothing revealed. Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit eb4cb29d48059551933fd65318c8c396f942045e Author: Gustavo A. R. Silva Date: Mon Jul 26 14:25:11 2021 -0500 flow_dissector: Fix out-of-bounds warnings [ Upstream commit 323e0cb473e2a8706ff162b6b4f4fa16023c9ba7 ] Fix the following out-of-bounds warnings: net/core/flow_dissector.c: In function '__skb_flow_dissect': >> net/core/flow_dissector.c:1104:4: warning: 'memcpy' offset [24, 39] from the object at '' is out of the bounds of referenced subobject 'saddr' with type 'struct in6_addr' at offset 8 [-Warray-bounds] 1104 | memcpy(&key_addrs->v6addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1105 | sizeof(key_addrs->v6addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ipv6.h:5, from net/core/flow_dissector.c:6: include/uapi/linux/ipv6.h:133:18: note: subobject 'saddr' declared here 133 | struct in6_addr saddr; | ^~~~~ >> net/core/flow_dissector.c:1059:4: warning: 'memcpy' offset [16, 19] from the object at '' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 12 [-Warray-bounds] 1059 | memcpy(&key_addrs->v4addrs, &iph->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1060 | sizeof(key_addrs->v4addrs)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from include/linux/ip.h:17, from net/core/flow_dissector.c:5: include/uapi/linux/ip.h:103:9: note: subobject 'saddr' declared here 103 | __be32 saddr; | ^~~~~ The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). So, the compiler legitimately complains about it. As these are just a couple of members, fix this by copying each one of them in separate calls to memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 801500ada7a4525dc0423d8123d5c95b924ed634 Author: Gustavo A. R. Silva Date: Mon Jul 26 14:52:51 2021 -0500 ipv4: ip_output.c: Fix out-of-bounds warning in ip_copy_addrs() [ Upstream commit 6321c7acb82872ef6576c520b0e178eaad3a25c0 ] Fix the following out-of-bounds warning: In function 'ip_copy_addrs', inlined from '__ip_queue_xmit' at net/ipv4/ip_output.c:517:2: net/ipv4/ip_output.c:449:2: warning: 'memcpy' offset [40, 43] from the object at 'fl' is out of the bounds of referenced subobject 'saddr' with type 'unsigned int' at offset 36 [-Warray-bounds] 449 | memcpy(&iph->saddr, &fl4->saddr, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 450 | sizeof(fl4->saddr) + sizeof(fl4->daddr)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The problem is that the original code is trying to copy data into a couple of struct members adjacent to each other in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &iph->saddr and &fl4->saddr. As these are just a couple of struct members, fix this by using direct assignments, instead of memcpy(). This helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy(). Link: https://github.com/KSPP/linux/issues/109 Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/d5ae2e65-1f18-2577-246f-bada7eee6ccd@intel.com/ Signed-off-by: Gustavo A. R. Silva Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bc802329fdfe0439ddadbed76cfae61a9726f1dc Author: Alex Elder Date: Mon Jul 26 12:40:08 2021 -0500 net: ipa: always validate filter and route tables [ Upstream commit 546948bf362541857d4f500705efe08a2fe0bb95 ] All checks in ipa_table_validate_build() are computed at build time, so build that unconditionally. In ipa_table_valid() calls to ipa_table_valid_one() are missing the IPA pointer parameter is missing in (a bug that shows up only when IPA_VALIDATE is defined). Don't bother checking whether hashed table memory regions are valid if hashed tables are not supported. With those things fixed, have these table validation functions built unconditionally (not dependent on IPA_VALIDATE). Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c093850e2762c4bebec75bd0482c63e433fb526 Author: Alex Elder Date: Mon Jul 26 12:40:07 2021 -0500 net: ipa: fix ipa_cmd_table_valid() [ Upstream commit f2c1dac0abcfa93e8b20065b8d6b4b2b6f9990aa ] Stop supporting different sizes for hashed and non-hashed filter or route tables. Add BUILD_BUG_ON() calls to verify the sizes of the fields in the filter/route table initialization immediate command are the same. Add a check to ipa_cmd_table_valid() to ensure the size of the memory region being checked fits within the immediate command field that must hold it. Remove two Boolean parameters used only for error reporting. This actually fixes a bug that would only show up if IPA_VALIDATE were defined. Define ipa_cmd_table_valid() unconditionally (no longer dependent on IPA_VALIDATE). Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit aba16e2c8931e5b6bc3cad185b436a38dc4726c1 Author: Zheyu Ma Date: Mon Jul 26 10:03:55 2021 +0000 video: fbdev: riva: Error out if 'pixclock' equals zero [ Upstream commit f92763cb0feba247e0939ed137b495601fd072a5 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 33.396850] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 33.396864] CPU: 5 PID: 11754 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #222 [ 33.396883] RIP: 0010:riva_load_video_mode+0x417/0xf70 [ 33.396969] Call Trace: [ 33.396973] ? debug_smp_processor_id+0x1c/0x20 [ 33.396984] ? tick_nohz_tick_stopped+0x1a/0x90 [ 33.396996] ? rivafb_copyarea+0x3c0/0x3c0 [ 33.397003] ? wake_up_klogd.part.0+0x99/0xd0 [ 33.397014] ? vprintk_emit+0x110/0x4b0 [ 33.397024] ? vprintk_default+0x26/0x30 [ 33.397033] ? vprintk+0x9c/0x1f0 [ 33.397041] ? printk+0xba/0xed [ 33.397054] ? record_print_text.cold+0x16/0x16 [ 33.397063] ? __kasan_check_read+0x11/0x20 [ 33.397074] ? profile_tick+0xc0/0x100 [ 33.397084] ? __sanitizer_cov_trace_const_cmp4+0x24/0x80 [ 33.397094] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397102] rivafb_set_par+0xbe/0x610 [ 33.397111] ? riva_set_rop_solid+0x2a0/0x2a0 [ 33.397119] fb_set_var+0x5bf/0xeb0 [ 33.397127] ? fb_blank+0x1a0/0x1a0 [ 33.397134] ? lock_acquire+0x1ef/0x530 [ 33.397143] ? lock_release+0x810/0x810 [ 33.397151] ? lock_is_held_type+0x100/0x140 [ 33.397159] ? ___might_sleep+0x1ee/0x2d0 [ 33.397170] ? __mutex_lock+0x620/0x1190 [ 33.397180] ? trace_hardirqs_on+0x6a/0x1c0 [ 33.397190] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-4-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 825712b09b1658be88d3fab38180bb9dbe6f43f5 Author: Zheyu Ma Date: Mon Jul 26 10:03:54 2021 +0000 video: fbdev: kyro: Error out if 'pixclock' equals zero [ Upstream commit 1520b4b7ba964f8eec2e7dd14c571d50de3e5191 ] The userspace program could pass any values to the driver through ioctl() interface. if the driver doesn't check the value of 'pixclock', it may cause divide error because the value of 'lineclock' and 'frameclock' will be zero. Fix this by checking whether 'pixclock' is zero in kyrofb_check_var(). The following log reveals it: [ 103.073930] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 103.073942] CPU: 4 PID: 12483 Comm: syz-executor Not tainted 5.14.0-rc2-00478-g2734d6c1b1a0-dirty #118 [ 103.073959] RIP: 0010:kyrofb_set_par+0x316/0xc80 [ 103.074045] Call Trace: [ 103.074048] ? ___might_sleep+0x1ee/0x2d0 [ 103.074060] ? kyrofb_ioctl+0x330/0x330 [ 103.074069] fb_set_var+0x5bf/0xeb0 [ 103.074078] ? fb_blank+0x1a0/0x1a0 [ 103.074085] ? lock_acquire+0x3bd/0x530 [ 103.074094] ? lock_release+0x810/0x810 [ 103.074103] ? ___might_sleep+0x1ee/0x2d0 [ 103.074114] ? __mutex_lock+0x620/0x1190 [ 103.074126] ? trace_hardirqs_on+0x6a/0x1c0 [ 103.074137] do_fb_ioctl+0x31e/0x700 [ 103.074144] ? fb_getput_cmap+0x280/0x280 [ 103.074152] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074162] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074171] ? __sanitizer_cov_trace_switch+0x67/0xf0 [ 103.074181] ? __sanitizer_cov_trace_const_cmp2+0x20/0x80 [ 103.074191] ? do_vfs_ioctl+0x14b/0x16c0 [ 103.074199] ? vfs_fileattr_set+0xb60/0xb60 [ 103.074207] ? rcu_read_lock_sched_held+0x11/0x80 [ 103.074216] ? lock_release+0x483/0x810 [ 103.074224] ? __fget_files+0x217/0x3d0 [ 103.074234] ? __fget_files+0x239/0x3d0 [ 103.074243] ? do_fb_ioctl+0x700/0x700 [ 103.074250] fb_ioctl+0xe6/0x130 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-3-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 2a70ab783de5af73c7c6f6270bbfc51844210b3b Author: Zheyu Ma Date: Mon Jul 26 10:03:53 2021 +0000 video: fbdev: asiliantfb: Error out if 'pixclock' equals zero [ Upstream commit b36b242d4b8ea178f7fd038965e3cac7f30c3f09 ] The userspace program could pass any values to the driver through ioctl() interface. If the driver doesn't check the value of 'pixclock', it may cause divide error. Fix this by checking whether 'pixclock' is zero first. The following log reveals it: [ 43.861711] divide error: 0000 [#1] PREEMPT SMP KASAN PTI [ 43.861737] CPU: 2 PID: 11764 Comm: i740 Not tainted 5.14.0-rc2-00513-gac532c9bbcfb-dirty #224 [ 43.861756] RIP: 0010:asiliantfb_check_var+0x4e/0x730 [ 43.861843] Call Trace: [ 43.861848] ? asiliantfb_remove+0x190/0x190 [ 43.861858] fb_set_var+0x2e4/0xeb0 [ 43.861866] ? fb_blank+0x1a0/0x1a0 [ 43.861873] ? lock_acquire+0x1ef/0x530 [ 43.861884] ? lock_release+0x810/0x810 [ 43.861892] ? lock_is_held_type+0x100/0x140 [ 43.861903] ? ___might_sleep+0x1ee/0x2d0 [ 43.861914] ? __mutex_lock+0x620/0x1190 [ 43.861921] ? do_fb_ioctl+0x313/0x700 [ 43.861929] ? mutex_lock_io_nested+0xfa0/0xfa0 [ 43.861936] ? __this_cpu_preempt_check+0x1d/0x30 [ 43.861944] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861952] ? lockdep_hardirqs_on+0x59/0x100 [ 43.861959] ? _raw_spin_unlock_irqrestore+0x46/0x60 [ 43.861967] ? trace_hardirqs_on+0x6a/0x1c0 [ 43.861978] do_fb_ioctl+0x31e/0x700 Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1627293835-17441-2-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 3ef99f2c58f9ece8b646aa3c3d83a9395ce96540 Author: Jernej Skrabec Date: Thu Jul 22 18:12:18 2021 +0200 arm64: dts: allwinner: h6: tanix-tx6: Fix regulator node names [ Upstream commit 7ab1f6539762946de06ca14d7401ae123821bc40 ] Regulator node names don't reflect class of the device. Fix that by prefixing names with "regulator-". Signed-off-by: Jernej Skrabec Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210722161220.51181-2-jernej.skrabec@gmail.com Signed-off-by: Sasha Levin commit 7e892a18c368e8d41fe662ef452c44b97b3edae3 Author: Geert Uytterhoeven Date: Wed Jul 14 11:48:06 2021 +0200 drm/bridge: nwl-dsi: Avoid potential multiplication overflow on 32-bit [ Upstream commit 47956bc86ee4e8530cac386a04f62a6095f7afbe ] As nwl_dsi.lanes is u32, and NSEC_PER_SEC is 1000000000L, the second multiplication in dsi->lanes * 8 * NSEC_PER_SEC will overflow on a 32-bit platform. Fix this by making the constant unsigned long long, forcing 64-bit arithmetic. As iMX8 is arm64, this driver is currently used on 64-bit platforms only, where long is 64-bit, so this cannot happen. But the issue will start to happen when the driver is reused for a 32-bit SoC (e.g. i.MX7ULP), or when code is copied for a new driver. Signed-off-by: Geert Uytterhoeven Reviewed-by: Fabio Estevam Reviewed-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/ebb82941a86b4e35c4fcfb1ef5a5cfad7c1fceab.1626255956.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 55bd26b7fec9346f6b58c0f9faa35ec4d044a1dd Author: Johan Almbladh Date: Wed Jul 21 12:38:22 2021 +0200 bpf/tests: Do not PASS tests without actually testing the result [ Upstream commit 2b7e9f25e590726cca76700ebdb10e92a7a72ca1 ] Each test case can have a set of sub-tests, where each sub-test can run the cBPF/eBPF test snippet with its own data_size and expected result. Before, the end of the sub-test array was indicated by both data_size and result being zero. However, most or all of the internal eBPF tests has a data_size of zero already. When such a test also had an expected value of zero, the test was never run but reported as PASS anyway. Now the test runner always runs the first sub-test, regardless of the data_size and result values. The sub-test array zero-termination only applies for any additional sub-tests. There are other ways fix it of course, but this solution at least removes the surprise of eBPF tests with a zero result always succeeding. Signed-off-by: Johan Almbladh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721103822.3755111-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 620a0d0b97bdf16338fb2bf56cad9486b2a41b40 Author: Johan Almbladh Date: Wed Jul 21 12:40:58 2021 +0200 bpf/tests: Fix copy-and-paste error in double word test [ Upstream commit ae7f47041d928b1a2f28717d095b4153c63cbf6a ] This test now operates on DW as stated instead of W, which was already covered by another test. Signed-off-by: Johan Almbladh Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210721104058.3755254-1-johan.almbladh@anyfinetworks.com Signed-off-by: Sasha Levin commit 45a01dd4eef144d30a4f3540f6c584ff5f5e43c3 Author: Anson Jacob Date: Tue Jul 20 11:00:44 2021 -0400 drm/amd/amdgpu: Update debugfs link_settings output link_rate field in hex [ Upstream commit 1a394b3c3de2577f200cb623c52a5c2b82805cec ] link_rate is updated via debugfs using hex values, set it to output in hex as well. eg: Resolution: 1920x1080@144Hz cat /sys/kernel/debug/dri/0/DP-1/link_settings Current: 4 0x14 0 Verified: 4 0x1e 0 Reported: 4 0x1e 16 Preferred: 0 0x0 0 echo "4 0x1e" > /sys/kernel/debug/dri/0/DP-1/link_settings cat /sys/kernel/debug/dri/0/DP-1/link_settings Current: 4 0x1e 0 Verified: 4 0x1e 0 Reported: 4 0x1e 16 Preferred: 4 0x1e 0 Signed-off-by: Anson Jacob Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f69c81f170e2f3bd0764b8b3a60fb529d7c5a4bf Author: Oak Zeng Date: Wed Jul 14 09:50:37 2021 -0500 drm/amdgpu: Fix a printing message [ Upstream commit 95f71f12aa45d65b7f2ccab95569795edffd379a ] The printing message "PSP loading VCN firmware" is mis-leading because people might think driver is loading VCN firmware. Actually when this message is printed, driver is just preparing some VCN ucode, not loading VCN firmware yet. The actual VCN firmware loading will be in the PSP block hw_init. Fix the printing message Signed-off-by: Oak Zeng Reviewed-by: Christian Konig Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 32f08048ce460fef2d8b1d12a14a9bdb6e12929c Author: Jake Wang Date: Wed Jun 30 13:55:50 2021 -0400 drm/amd/display: Fixed hardware power down bypass during headless boot [ Upstream commit 3addbde269f21ffc735f6d3d0c2237664923824e ] [Why] During headless boot, DIG may be on which causes HW/SW discrepancies. To avoid this we power down hardware on boot if DIG is turned on. With introduction of multiple eDP, hardware power down is being bypassed under certain conditions. [How] Fixed hardware power down bypass, and ensured hardware will power down if DIG is on and seamless boot is not enabled. Reviewed-by: Nicholas Kazlauskas Acked-by: Rodrigo Siqueira Signed-off-by: Jake Wang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6890f27361c1d218adf7859d74178a6a0eba69c5 Author: Arnd Bergmann Date: Thu Jul 22 16:28:59 2021 +0200 ethtool: improve compat ioctl handling [ Upstream commit dd98d2895de6485c884a9cb42de69fed02826fa4 ] The ethtool compat ioctl handling is hidden away in net/socket.c, which introduces a couple of minor oddities: - The implementation may end up diverging, as seen in the RXNFC extension in commit 84a1d9c48200 ("net: ethtool: extend RXNFC API to support RSS spreading of filter matches") that does not work in compat mode. - Most architectures do not need the compat handling at all because u64 and compat_u64 have the same alignment. - On x86, the conversion is done for both x32 and i386 user space, but it's actually wrong to do it for x32 and cannot work there. - On 32-bit Arm, it never worked for compat oabi user space, since that needs to do the same conversion but does not. - It would be nice to get rid of both compat_alloc_user_space() and copy_in_user() throughout the kernel. None of these actually seems to be a serious problem that real users are likely to encounter, but fixing all of them actually leads to code that is both shorter and more readable. Signed-off-by: Arnd Bergmann Reviewed-by: Christoph Hellwig Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 28178b95a764754c647cb53a0c920af0ef316e8f Author: Niklas Söderlund Date: Thu Jul 22 13:25:02 2021 +0200 nfp: fix return statement in nfp_net_parse_meta() [ Upstream commit 4431531c482a2c05126caaa9fcc5053a4a5c495b ] The return type of the function is bool and while NULL do evaluate to false it's not very nice, fix this by explicitly returning false. There is no functional change. Signed-off-by: Niklas Söderlund Signed-off-by: Louis Peens Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8142129a9276b52525a9ae33e98b280c400a3bce Author: Yang Yingliang Date: Thu Jun 17 09:23:29 2021 +0200 media: atomisp: pci: fix error return code in atomisp_pci_probe() [ Upstream commit d14e272958bdfdc40dcafb827d24ba6fdafa9d52 ] If init_atomisp_wdts() fails, atomisp_pci_probe() need return error code. Link: https://lore.kernel.org/linux-media/20210617072329.1233662-1-yangyingliang@huawei.com Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5b3e68e1d1cba2638e4edf30345797c316ac47be Author: Dinghao Liu Date: Thu Apr 8 10:18:43 2021 +0200 media: atomisp: Fix runtime PM imbalance in atomisp_pci_probe [ Upstream commit 672fe1cf145ab9978c62eb827d6a16aa6b63994b ] When hmm_pool_register() fails, a pairing PM usage counter increment is needed to keep the counter balanced. It's the same for the following error paths. Link: https://lore.kernel.org/linux-media/20210408081850.24278-1-dinghao.liu@zju.edu.cn Signed-off-by: Dinghao Liu Acked-by: Andy Shevchenko Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bac4ffd51c92f93140e769d111f784a7c04c1695 Author: Evgeny Novikov Date: Sat Jul 10 14:04:32 2021 +0200 media: platform: stm32: unprepare clocks at handling errors in probe [ Upstream commit 055d2db28ec2fa3ab5c527c5604f1b32b89fa13a ] stm32_cec_probe() did not unprepare clocks on error handling paths. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cfe753720e211f3946556bd647a2fb933ce4ef2b Author: Ezequiel Garcia Date: Mon Jul 19 22:52:33 2021 +0200 media: hantro: vp8: Move noisy WARN_ON to vpu_debug [ Upstream commit 6ad61a7847da09b6261824accb539d05bcdfef65 ] When the VP8 decoders can't find a reference frame, the driver falls back to the current output frame. This will probably produce some undesirable results, leading to frame corruption, but shouldn't cause noisy warnings. Signed-off-by: Ezequiel Garcia Acked-by: Nicolas Dufresne Tested-by: Alex Bee Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ee11d66ed19c578d35b381fd4cf62eb8e73ff886 Author: Oliver Logush Date: Wed Jun 23 15:04:04 2021 -0400 drm/amd/display: Fix timer_per_pixel unit error [ Upstream commit 23e55639b87fb16a9f0f66032ecb57060df6c46c ] [why] The units of the time_per_pixel variable were incorrect, this had to be changed for the code to properly function. [how] The change was very straightforward, only required one line of code to be changed where the calculation was done. Acked-by: Rodrigo Siqueira Signed-off-by: Oliver Logush Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2bafef9619fdf18b9e1a7a1030af0b019a208607 Author: Shuah Khan Date: Wed Jul 7 21:18:27 2021 -0600 selftests: firmware: Fix ignored return val of asprintf() warn [ Upstream commit fe968ca2cac91888310b143a483123c84906e3fc ] Fix the following ingonred return val of asprintf() warn during build: cc -Wall -O2 fw_namespace.c -o ../tools/testing/selftests/firmware/fw_namespace fw_namespace.c: In function ‘main’: fw_namespace.c:132:2: warning: ignoring return value of ‘asprintf’ declared with attribute ‘warn_unused_result’ [-Wunused-result] 132 | asprintf(&fw_path, "/lib/firmware/%s", fw_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20210708031827.51293-1-skhan@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4dbcbea2bf3920170d9317b1429576586da6cd9f Author: Eric Auger Date: Tue Jun 29 09:22:14 2021 +0200 misc/pvpanic-pci: Allow automatic loading [ Upstream commit 28b6a003bcdfa1fc4603b9185b247ecca7af9bef ] The virtual machine monitor (QEMU) exposes the pvpanic-pci device to the guest. On guest side the module exists but currently isn't loaded automatically. So the driver fails to be probed and does not its job of handling guest panic events. Instead of requiring manual modprobe, let's include a device database using the MODULE_DEVICE_TABLE macro and let the module auto-load when the guest gets exposed with such a pvpanic-pci device. Signed-off-by: Eric Auger Link: https://lore.kernel.org/r/20210629072214.901004-1-eric.auger@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3533c194f2301f55366eb84271404353dd53a5d4 Author: Laurentiu Tudor Date: Thu Jul 15 17:07:18 2021 +0300 bus: fsl-mc: fix mmio base address for child DPRCs [ Upstream commit 8990f96a012f42543005b07d9e482694192e9309 ] Some versions of the MC firmware wrongly report 0 for register base address of the DPMCP associated with child DPRC objects thus rendering them unusable. This is particularly troublesome in ACPI boot scenarios where the legacy way of extracting this base address from the device tree does not apply. Given that DPMCPs share the same base address, workaround this by using the base address extracted from the root DPRC container. Signed-off-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20210715140718.8513-8-laurentiu.tudor@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0ee03113e481f7c44647fcb8e2c1e33157be86e3 Author: Laurentiu Tudor Date: Thu Jul 15 17:07:11 2021 +0300 bus: fsl-mc: fix arg in call to dprc_scan_objects() [ Upstream commit aa0a1ae020e2d24749e9f8085f12ca6d46899c94 ] Second parameter of dprc_scan_objects() is a bool not a pointer so change from NULL to false. Signed-off-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20210715140718.8513-1-laurentiu.tudor@nxp.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8eac68de04735616e39698b998cff6d5da2d2517 Author: Zheyu Ma Date: Wed Jul 14 05:53:23 2021 +0000 tty: serial: jsm: hold port lock when reporting modem line changes [ Upstream commit 240e126c28df084222f0b661321e8e3ecb0d232e ] uart_handle_dcd_change() requires a port lock to be held and will emit a warning when lockdep is enabled. Held corresponding lock to fix the following warnings. [ 132.528648] WARNING: CPU: 5 PID: 11600 at drivers/tty/serial/serial_core.c:3046 uart_handle_dcd_change+0xf4/0x120 [ 132.530482] Modules linked in: [ 132.531050] CPU: 5 PID: 11600 Comm: jsm Not tainted 5.14.0-rc1-00003-g7fef2edf7cc7-dirty #31 [ 132.535268] RIP: 0010:uart_handle_dcd_change+0xf4/0x120 [ 132.557100] Call Trace: [ 132.557562] ? __free_pages+0x83/0xb0 [ 132.558213] neo_parse_modem+0x156/0x220 [ 132.558897] neo_param+0x399/0x840 [ 132.559495] jsm_tty_open+0x12f/0x2d0 [ 132.560131] uart_startup.part.18+0x153/0x340 [ 132.560888] ? lock_is_held_type+0xe9/0x140 [ 132.561660] uart_port_activate+0x7f/0xe0 [ 132.562351] ? uart_startup.part.18+0x340/0x340 [ 132.563003] tty_port_open+0x8d/0xf0 [ 132.563523] ? uart_set_options+0x1e0/0x1e0 [ 132.564125] uart_open+0x24/0x40 [ 132.564604] tty_open+0x15c/0x630 Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/1626242003-3809-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 85a2f4dc003827648394691fa3709cb56b936d09 Author: Mauro Carvalho Chehab Date: Sat Jul 17 11:58:17 2021 +0200 staging: hisilicon,hi6421-spmi-pmic.yaml: fix patternProperties [ Upstream commit 334201d503d5903f38f6e804263fc291ce8f451a ] The regex at the patternProperties is wrong, although this was not reported as the DT schema was not enforcing properties. Fix it. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/46b2f30df235481cb1404913380e45706dfd8253.1626515862.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c98d9dda8c9f81e7a495245081480b2940017e8d Author: Geert Uytterhoeven Date: Wed Jul 14 12:13:46 2021 +0200 staging: board: Fix uninitialized spinlock when attaching genpd [ Upstream commit df00609821bf17f50a75a446266d19adb8339d84 ] On Armadillo-800-EVA with CONFIG_DEBUG_SPINLOCK=y: BUG: spinlock bad magic on CPU#0, swapper/1 lock: lcdc0_device+0x10c/0x308, .magic: 00000000, .owner: /-1, .owner_cpu: 0 CPU: 0 PID: 1 Comm: swapper Not tainted 5.11.0-rc5-armadillo-00036-gbbca04be7a80-dirty #287 Hardware name: Generic R8A7740 (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (do_raw_spin_lock+0x20/0x94) [] (do_raw_spin_lock) from [] (dev_pm_get_subsys_data+0x8c/0x11c) [] (dev_pm_get_subsys_data) from [] (genpd_add_device+0x78/0x2b8) [] (genpd_add_device) from [] (of_genpd_add_device+0x34/0x4c) [] (of_genpd_add_device) from [] (board_staging_register_device+0x11c/0x148) [] (board_staging_register_device) from [] (board_staging_register_devices+0x24/0x28) of_genpd_add_device() is called before platform_device_register(), as it needs to attach the genpd before the device is probed. But the spinlock is only initialized when the device is registered. Fix this by open-coding the spinlock initialization, cfr. device_pm_init_common() in the internal drivers/base code, and in the SuperH early platform code. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/57783ece7ddae55f2bda2f59f452180bff744ea0.1626257398.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a1f7a9569023af539cb3523ecef88accf9240ccf Author: Jack Pham Date: Tue Jul 20 01:09:07 2021 -0700 usb: gadget: composite: Allow bMaxPower=0 if self-powered [ Upstream commit bcacbf06c891374e7fdd7b72d11cda03b0269b43 ] Currently the composite driver encodes the MaxPower field of the configuration descriptor by reading the c->MaxPower of the usb_configuration only if it is non-zero, otherwise it falls back to using the value hard-coded in CONFIG_USB_GADGET_VBUS_DRAW. However, there are cases when a configuration must explicitly set bMaxPower to 0, particularly if its bmAttributes also has the Self-Powered bit set, which is a valid combination. This is specifically called out in the USB PD specification section 9.1, in which a PDUSB device "shall report zero in the bMaxPower field after negotiating a mutually agreeable Contract", and also verified by the USB Type-C Functional Test TD.4.10.2 Sink Power Precedence Test. The fix allows the c->MaxPower to be used for encoding the bMaxPower even if it is 0, if the self-powered bit is also set. An example usage of this would be for a ConfigFS gadget to be dynamically updated by userspace when the Type-C connection is determined to be operating in Power Delivery mode. Co-developed-by: Ronak Vijay Raheja Acked-by: Felipe Balbi Signed-off-by: Ronak Vijay Raheja Signed-off-by: Jack Pham Link: https://lore.kernel.org/r/20210720080907.30292-1-jackp@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6c63606c29e129396e5978b36bcbdd7f2502afd0 Author: Evgeny Novikov Date: Thu Jul 8 11:30:56 2021 +0300 USB: EHCI: ehci-mv: improve error handling in mv_ehci_enable() [ Upstream commit 61136a12cbed234374ec6f588af57c580b20b772 ] mv_ehci_enable() did not disable and unprepare clocks in case of failures of phy_init(). Besides, it did not take into account failures of ehci_clock_enable() (in effect, failures of clk_prepare_enable()). The patch fixes both issues and gets rid of redundant wrappers around clk_prepare_enable() and clk_disable_unprepare() to simplify this a bit. Found by Linux Driver Verification project (linuxtesting.org). Acked-by: Alan Stern Signed-off-by: Evgeny Novikov Link: https://lore.kernel.org/r/20210708083056.21543-1-novikov@ispras.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 693a0d4f9412d831466d56607f8db2b1b5cf43ea Author: Maciej Żenczykowski Date: Thu Jul 1 04:48:34 2021 -0700 usb: gadget: u_ether: fix a potential null pointer dereference [ Upstream commit 8ae01239609b29ec2eff55967c8e0fe3650cfa09 ] f_ncm tx timeout can call us with null skb to flush a pending frame. In this case skb is NULL to begin with but ceases to be null after dev->wrap() completes. In such a case in->maxpacket will be read, even though we've failed to check that 'in' is not NULL. Though I've never observed this fail in practice, however the 'flush operation' simply does not make sense with a null usb IN endpoint - there's nowhere to flush to... (note that we're the gadget/device, and IN is from the point of view of the host, so here IN actually means outbound...) Cc: Brooke Basile Cc: "Bryan O'Donoghue" Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: Lorenzo Colitti Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20210701114834.884597-6-zenczykowski@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e98b79370eb361a4ae8864f896348a17e9e01c48 Author: Kelly Devilliv Date: Sun Jun 27 20:57:47 2021 +0800 usb: host: fotg210: fix the actual_length of an iso packet [ Upstream commit 091cb2f782f32ab68c6f5f326d7868683d3d4875 ] We should acquire the actual_length of an iso packet from the iTD directly using FOTG210_ITD_LENGTH() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-4-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 326a86a4b4feb1fb56cd6b3e2b0a3c4f2c7f12d0 Author: Kelly Devilliv Date: Sun Jun 27 20:57:46 2021 +0800 usb: host: fotg210: fix the endpoint's transactional opportunities calculation [ Upstream commit c2e898764245c852bc8ee4857613ba4f3a6d761d ] Now that usb_endpoint_maxp() only returns the lowest 11 bits from wMaxPacketSize, we should make use of the usb_endpoint_* helpers instead and remove the unnecessary max_packet()/hb_mult() macro. Signed-off-by: Kelly Devilliv Link: https://lore.kernel.org/r/20210627125747.127646-3-kelly.devilliv@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 980dee03d03c28fc6112a9bac23d7e6538738d1b Author: Sasha Neftin Date: Mon Jun 14 15:19:39 2021 +0300 igc: Check if num of q_vectors is smaller than max before array access [ Upstream commit 373e2829e7c2e1e606503cdb5c97749f512a4be9 ] Ensure that the adapter->q_vector[MAX_Q_VECTORS] array isn't accessed beyond its size. It was fixed by using a local variable num_q_vectors as a limit for loop index, and ensure that num_q_vectors is not bigger than MAX_Q_VECTORS. Suggested-by: Aleksandr Loktionov Signed-off-by: Sasha Neftin Tested-by: Dvora Fuxbrumer Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 9769853764aef37f8801345321507e45acbd4a38 Author: Zhouyi Zhou Date: Tue Jul 13 08:56:45 2021 +0800 rcu: Fix macro name CONFIG_TASKS_RCU_TRACE [ Upstream commit fed31a4dd3adb5455df7c704de2abb639a1dc1c0 ] This commit fixes several typos where CONFIG_TASKS_RCU_TRACE should instead be CONFIG_TASKS_TRACE_RCU. Among other things, these typos could cause CONFIG_TASKS_TRACE_RCU_READ_MB=y kernels to suffer from memory-ordering bugs that could result in false-positive quiescent states and too-short grace periods. Signed-off-by: Zhouyi Zhou Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 121ca0abd9001c2ef527808b77f282590faf145d Author: Desmond Cheong Zhi Xi Date: Mon Jul 12 12:35:08 2021 +0800 drm: protect drm_master pointers in drm_lease.c [ Upstream commit 56f0729a510f92151682ff6c89f69724d5595d6e ] drm_file->master pointers should be protected by drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, in drm_lease.c, there are multiple instances where drm_file->master is accessed and dereferenced while neither lock is held. This makes drm_lease.c vulnerable to use-after-free bugs. We address this issue in 2 ways: 1. Add a new drm_file_get_master() function that calls drm_master_get on drm_file->master while holding on to drm_file.master_lookup_lock. Since drm_master_get increments the reference count of master, this prevents master from being freed until we unreference it with drm_master_put. 2. In each case where drm_file->master is directly accessed and eventually dereferenced in drm_lease.c, we wrap the access in a call to the new drm_file_get_master function, then unreference the master pointer once we are done using it. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: Emil Velikov Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-6-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit fa8634b165bba1a256c6d8b0d6e4382e8861830b Author: Desmond Cheong Zhi Xi Date: Mon Jul 12 12:35:07 2021 +0800 drm: serialize drm_file.master with a new spinlock [ Upstream commit 0b0860a3cf5eccf183760b1177a1dcdb821b0b66 ] Currently, drm_file.master pointers should be protected by drm_device.master_mutex when being dereferenced. This is because drm_file.master is not invariant for the lifetime of drm_file. If drm_file is not the creator of master, then drm_file.is_master is false, and a call to drm_setmaster_ioctl will invoke drm_new_set_master, which then allocates a new master for drm_file and puts the old master. Thus, without holding drm_device.master_mutex, the old value of drm_file.master could be freed while it is being used by another concurrent process. However, it is not always possible to lock drm_device.master_mutex to dereference drm_file.master. Through the fbdev emulation code, this might occur in a deep nest of other locks. But drm_device.master_mutex is also the outermost lock in the nesting hierarchy, so this leads to potential deadlocks. To address this, we introduce a new spin lock at the bottom of the lock hierarchy that only serializes drm_file.master. With this change, the value of drm_file.master changes only when both drm_device.master_mutex and drm_file.master_lookup_lock are held. Hence, any process holding either of those locks can ensure that the value of drm_file.master will not change concurrently. Since no lock depends on the new drm_file.master_lookup_lock, when drm_file.master is dereferenced, but drm_device.master_mutex cannot be held, we can safely protect the master pointer with drm_file.master_lookup_lock. Reported-by: Daniel Vetter Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-5-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit cb3a175a90ce48afabf67add0ef47c1a289b0731 Author: Desmond Cheong Zhi Xi Date: Mon Jul 12 12:35:05 2021 +0800 drm: avoid blocking in drm_clients_info's rcu section [ Upstream commit 5eff9585de220cdd131237f5665db5e6c6bdf590 ] Inside drm_clients_info, the rcu_read_lock is held to lock pid_task()->comm. However, within this protected section, a call to drm_is_current_master is made, which involves a mutex lock in a future patch. However, this is illegal because the mutex lock might block while in the RCU read-side critical section. Since drm_is_current_master isn't protected by rcu_read_lock, we avoid this by moving it out of the RCU critical section. The following report came from intel-gfx ci's igt@debugfs_test@read_all_entries testcase: ============================= [ BUG: Invalid wait context ] 5.13.0-CI-Patchwork_20515+ #1 Tainted: G W ----------------------------- debugfs_test/1101 is trying to lock: ffff888132d901a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1e/0x50 other info that might help us debug this: context-{4:4} 3 locks held by debugfs_test/1101: #0: ffff88810fdffc90 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x53/0x3b0 #1: ffff888132d90240 (&dev->filelist_mutex){+.+.}-{3:3}, at: drm_clients_info+0x63/0x2a0 #2: ffffffff82734220 (rcu_read_lock){....}-{1:2}, at: drm_clients_info+0x1b1/0x2a0 stack backtrace: CPU: 8 PID: 1101 Comm: debugfs_test Tainted: G W 5.13.0-CI-Patchwork_20515+ #1 Hardware name: Intel Corporation CometLake Client Platform/CometLake S UDIMM (ERB/CRB), BIOS CMLSFWR1.R00.1263.D00.1906260926 06/26/2019 Call Trace: dump_stack+0x7f/0xad __lock_acquire.cold.78+0x2af/0x2ca lock_acquire+0xd3/0x300 ? drm_is_current_master+0x1e/0x50 ? __mutex_lock+0x76/0x970 ? lockdep_hardirqs_on+0xbf/0x130 __mutex_lock+0xab/0x970 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 drm_is_current_master+0x1e/0x50 drm_clients_info+0x107/0x2a0 seq_read_iter+0x178/0x3b0 seq_read+0x104/0x150 full_proxy_read+0x4e/0x80 vfs_read+0xa5/0x1b0 ksys_read+0x5a/0xd0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-3-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin commit 01b3c2329fd0978be1677cb2a2065a009b104b80 Author: Tianjia Zhang Date: Thu Jul 15 17:17:24 2021 +0800 Smack: Fix wrong semantics in smk_access_entry() [ Upstream commit 6d14f5c7028eea70760df284057fe198ce7778dd ] In the smk_access_entry() function, if no matching rule is found in the rust_list, a negative error code will be used to perform bit operations with the MAY_ enumeration value. This is semantically wrong. This patch fixes this issue. Signed-off-by: Tianjia Zhang Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 60a064f012eabe6c3648511f605587c6930db5fe Author: Alex Elder Date: Mon Jul 19 15:23:33 2021 -0500 net: ipa: fix IPA v4.11 interconnect data [ Upstream commit 0ac26271344478ff718329fa9d4ef81d4bcbc43b ] Currently three interconnects are defined for the Qualcomm SC7280 SoC, but this was based on a misunderstanding. There should only be two interconnects defined: one between the IPA and system memory; and another between the AP and IPA config space. The bandwidths defined for the memory and config interconnects do not match what I understand to be proper values, so update these. Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 465f4890c04af67bc9634775dc7351d0ce3b4a60 Author: Bhupesh Sharma Date: Sun Jun 27 17:16:16 2021 +0530 arm64: dts: qcom: Fix usb entries for SA8155p adp board [ Upstream commit 12dd4ebda47abd5e3907da386b6fe1d8181ad179 ] SA8155p adp board has two USB A-type receptacles called USB-portB and USB-portC respectively. While USB-portB is a USB High-Speed connector/interface, the USB-portC one is a USB 3.1 Super-Speed connector/interface. Also the USB-portB is used as the USB emergency download port (for image download purposes). Enable both the ports on the board in USB Host mode (since all the USB interfaces are brought out to USB Type A connectors). Cc: Bjorn Andersson Signed-off-by: Bhupesh Sharma Link: https://lore.kernel.org/r/20210627114616.717101-4-bhupesh.sharma@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 65a9532212b5b454cd6a0bde8fdd9745aabf0cf4 Author: Yajun Deng Date: Mon Jul 19 13:18:16 2021 +0800 netlink: Deal with ESRCH error in nlmsg_notify() [ Upstream commit fef773fc8110d8124c73a5e6610f89e52814637d ] Yonghong Song report: The bpf selftest tc_bpf failed with latest bpf-next. The following is the command to run and the result: $ ./test_progs -n 132 [ 40.947571] bpf_testmod: loading out-of-tree module taints kernel. test_tc_bpf:PASS:test_tc_bpf__open_and_load 0 nsec test_tc_bpf:PASS:bpf_tc_hook_create(BPF_TC_INGRESS) 0 nsec test_tc_bpf:PASS:bpf_tc_hook_create invalid hook.attach_point 0 nsec test_tc_bpf_basic:PASS:bpf_obj_get_info_by_fd 0 nsec test_tc_bpf_basic:PASS:bpf_tc_attach 0 nsec test_tc_bpf_basic:PASS:handle set 0 nsec test_tc_bpf_basic:PASS:priority set 0 nsec test_tc_bpf_basic:PASS:prog_id set 0 nsec test_tc_bpf_basic:PASS:bpf_tc_attach replace mode 0 nsec test_tc_bpf_basic:PASS:bpf_tc_query 0 nsec test_tc_bpf_basic:PASS:handle set 0 nsec test_tc_bpf_basic:PASS:priority set 0 nsec test_tc_bpf_basic:PASS:prog_id set 0 nsec libbpf: Kernel error message: Failed to send filter delete notification test_tc_bpf_basic:FAIL:bpf_tc_detach unexpected error: -3 (errno 3) test_tc_bpf:FAIL:test_tc_internal ingress unexpected error: -3 (errno 3) The failure seems due to the commit cfdf0d9ae75b ("rtnetlink: use nlmsg_notify() in rtnetlink_send()") Deal with ESRCH error in nlmsg_notify() even the report variable is zero. Reported-by: Yonghong Song Signed-off-by: Yajun Deng Link: https://lore.kernel.org/r/20210719051816.11762-1-yajun.deng@linux.dev Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7a3aeb7e0905e0fb0792e2f0c77893b8955fab06 Author: KuoHsiang Chou Date: Fri Jul 9 16:09:00 2021 +0800 drm/ast: Disable fast reset after DRAM initial [ Upstream commit f34bf652d680cf65783e7c57d61c94ee87f092bd ] [Bug][AST2500] V1: When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization have to be achieved by VGA driver with P2A (PCI to AHB) enabling. However, HW suggests disable Fast reset mode after DRAM initializaton, because fast reset mode is mainly designed for ARM ICE debugger. Once Fast reset is checked as enabling, WDT (Watch Dog Timer) should be first enabled to avoid system deadlock before disable fast reset mode. V2: Use to_pci_dev() to get revision of PCI configuration. V3: If SCU00 is not unlocked, just enter its password again. It is unnecessary to clear AHB lock condition and restore WDT default setting again, before Fast-reset clearing. V4: repatch after "error : could not build fake ancestor" resolved. V5: Since CVE_2019_6260 item3, Most of AST2500 have disabled P2A(PCIe to AMBA). However, for backward compatibility, some patches about P2A, such as items of v5.2 and v5.3, are considered to be upstreamed with comments. 1. Add define macro to improve source readability. ast_drv.h, ast_main.c, ast_post.c 2. Add comment about "Fast restet" is enabled for ARM-ICE debugger ast_post.c 3. Add comment about Reset USB port to patch USB unknown device issue ast_post.c Signed-off-by: KuoHsiang Chou Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210709080900.4056-1-kuohsiang_chou@aspeedtech.com Signed-off-by: Sasha Levin commit ecaaee8ea681796604716a4df6e4a72b56b9e374 Author: Zheyu Ma Date: Wed Jul 14 04:09:22 2021 +0000 video: fbdev: kyro: fix a DoS bug by restricting user input [ Upstream commit 98a65439172dc69cb16834e62e852afc2adb83ed ] The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1626235762-2590-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 2cf3e0627c4f986a424bbd901573e90887eb165a Author: David Heidelberg Date: Wed Jul 7 15:14:53 2021 +0200 ARM: dts: qcom: apq8064: correct clock names [ Upstream commit 0dc6c59892ead17a9febd11202c9f6794aac1895 ] Since new code doesn't take old clk names in account, it does fixes error: msm_dsi 4700000.mdss_dsi: dev_pm_opp_set_clkname: Couldn't find clock: -2 and following kernel oops introduced by b0530eb1191 ("drm/msm/dpu: Use OPP API to set clk/perf state"). Also removes warning about deprecated clock names. Tested against linux-5.10.y LTS on Nexus 7 2013. Reviewed-by: Brian Masney Signed-off-by: David Heidelberg Link: https://lore.kernel.org/r/20210707131453.24041-1-david@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit db149a8d6996fca50748f66f4efdc7245f93af74 Author: Stefan Assmann Date: Tue Mar 16 11:01:41 2021 +0100 iavf: fix locking of critical sections [ Upstream commit 226d528512cfac890a1619aea4301f3dd314fe60 ] To avoid races between iavf_init_task(), iavf_reset_task(), iavf_watchdog_task(), iavf_adminq_task() as well as the shutdown and remove functions more locking is required. The current protection by __IAVF_IN_CRITICAL_TASK is needed in additional places. - The reset task performs state transitions, therefore needs locking. - The adminq task acts on replies from the PF in iavf_virtchnl_completion() which may alter the states. - The init task is not only run during probe but also if a VF gets stuck to reinitialize it. - The shutdown function performs a state transition. - The remove function performs a state transition and also free's resources. iavf_lock_timeout() is introduced to avoid waiting infinitely and cause a deadlock. Rather unlock and print a warning. Signed-off-by: Stefan Assmann Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 1cea40543748f852fb0b32b7e462895eea7c6edf Author: Stefan Assmann Date: Fri Mar 5 13:38:56 2021 +0100 iavf: do not override the adapter state in the watchdog task [ Upstream commit 22c8fd71d3a5e6fe584ccc2c1e8760e5baefd5aa ] The iavf watchdog task overrides adapter->state to __IAVF_RESETTING when it detects a pending reset. Then schedules iavf_reset_task() which takes care of the reset. The reset task is capable of handling the reset without changing adapter->state. In fact we lose the state information when the watchdog task prematurely changes the adapter state. This may lead to a crash if instead of the reset task the iavf_remove() function gets called before the reset task. In that case (if we were in state __IAVF_RUNNING previously) the iavf_remove() function triggers iavf_close() which fails to close the device because of the incorrect state information. This may result in a crash due to pending interrupts. kernel BUG at drivers/pci/msi.c:357! [...] Call Trace: [] pci_disable_msix+0x3d/0x50 [] iavf_reset_interrupt_capability+0x23/0x40 [iavf] [] iavf_remove+0x10a/0x350 [iavf] [] pci_device_remove+0x39/0xc0 [] __device_release_driver+0x7f/0xf0 [] device_release_driver+0x23/0x30 [] pci_stop_bus_device+0x84/0xa0 [] pci_stop_and_remove_bus_device+0x12/0x20 [] pci_iov_remove_virtfn+0xaf/0x160 [] sriov_disable+0x3c/0xf0 [] pci_disable_sriov+0x23/0x30 [] i40e_free_vfs+0x265/0x2d0 [i40e] [] i40e_pci_sriov_configure+0x144/0x1f0 [i40e] [] sriov_numvfs_store+0x177/0x1d0 Code: 00 00 e8 3c 25 e3 ff 49 c7 86 88 08 00 00 00 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 8b 7b 28 e8 0d 44 RIP [] free_msi_irqs+0x188/0x190 The solution is to not touch the adapter->state in iavf_watchdog_task() and let the reset task handle the state transition. Signed-off-by: Stefan Assmann Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit c8b1999ee0912bce9d89e77b478632a6eeee439c Author: Jonathan Cameron Date: Sun Jun 27 17:32:37 2021 +0100 iio: dac: ad5624r: Fix incorrect handling of an optional regulator. [ Upstream commit 97683c851f9cdbd3ea55697cbe2dcb6af4287bbd ] The naming of the regulator is problematic. VCC is usually a supply voltage whereas these devices have a separate VREF pin. Secondly, the regulator core might have provided a stub regulator if a real regulator wasn't provided. That would in turn have failed to provide a voltage when queried. So reality was that there was no way to use the internal reference. In order to avoid breaking any dts out in the wild, make sure to fallback to the original vcc naming if vref is not available. Signed-off-by: Jonathan Cameron Reported-by: kernel test robot Acked-by: Nuno Sá Link: https://lore.kernel.org/r/20210627163244.1090296-9-jic23@kernel.org Signed-off-by: Sasha Levin commit 8d258c10135cb728c03bb44ee7f81d447a5e7092 Author: Marek Vasut Date: Sat Jul 17 14:32:49 2021 +0200 net: phy: Fix data type in DP83822 dp8382x_disable_wol() [ Upstream commit 0d6835ffe50c9c1f098b5704394331710b67af48 ] The last argument of phy_clear_bits_mmd(..., u16 val); is u16 and not int, just inline the value into the function call arguments. No functional change. Signed-off-by: Marek Vasut Cc: Andrew Lunn Cc: Florian Fainelli Cc: David S. Miller Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 24c75df12b9522fb9d880abb549234b1173157fb Author: Xin Long Date: Fri Jul 16 17:44:07 2021 -0400 tipc: keep the skb in rcv queue until the whole data is read [ Upstream commit f4919ff59c2828064b4156e3c3600a169909bcf4 ] Currently, when userspace reads a datagram with a buffer that is smaller than this datagram, the data will be truncated and only part of it can be received by users. It doesn't seem right that users don't know the datagram size and have to use a huge buffer to read it to avoid the truncation. This patch to fix it by keeping the skb in rcv queue until the whole data is read by users. Only the last msg of the datagram will be marked with MSG_EOR, just as TCP/SCTP does. Note that this will work as above only when MSG_EOR is set in the flags parameter of recvmsg(), so that it won't break any old user applications. Signed-off-by: Xin Long Acked-by: Jon Maloy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5411f1f0e73b2ee3b2f97999cd456903344cd36b Author: Rafael J. Wysocki Date: Thu Jul 8 15:25:06 2021 +0200 PCI: Use pci_update_current_state() in pci_enable_device_flags() [ Upstream commit 14858dcc3b3587f4bb5c48e130ee7d68fc2b0a29 ] Updating the current_state field of struct pci_dev the way it is done in pci_enable_device_flags() before calling do_pci_enable_device() may not work. For example, if the given PCI device depends on an ACPI power resource whose _STA method initially returns 0 ("off"), but the config space of the PCI device is accessible and the power state retrieved from the PCI_PM_CTRL register is D0, the current_state field in the struct pci_dev representing that device will get out of sync with the power.state of its ACPI companion object and that will lead to power management issues going forward. To avoid such issues, make pci_enable_device_flags() call pci_update_current_state() which takes ACPI device power management into account, if present, to retrieve the current power state of the device. Link: https://lore.kernel.org/lkml/20210314000439.3138941-1-luzmaximilian@gmail.com/ Reported-by: Maximilian Luz Signed-off-by: Rafael J. Wysocki Tested-by: Maximilian Luz Signed-off-by: Sasha Levin commit eced456a5bc69806a04a2ee668b9b8707719bedc Author: Sean Anderson Date: Thu Jul 1 14:56:38 2021 -0400 crypto: mxs-dcp - Use sg_mapping_iter to copy data [ Upstream commit 2e6d793e1bf07fe5e20cfbbdcec9e1af7e5097eb ] This uses the sg_pcopy_from_buffer to copy data, instead of doing it ourselves. In addition to reducing code size, this fixes the following oops resulting from failing to kmap the page: [ 68.896381] Unable to handle kernel NULL pointer dereference at virtual address 00000ab8 [ 68.904539] pgd = 3561adb3 [ 68.907475] [00000ab8] *pgd=00000000 [ 68.911153] Internal error: Oops: 805 [#1] ARM [ 68.915618] Modules linked in: cfg80211 rfkill des_generic libdes arc4 libarc4 cbc ecb algif_skcipher sha256_generic libsha256 sha1_generic hmac aes_generic libaes cmac sha512_generic md5 md4 algif_hash af_alg i2c_imx i2c_core ci_hdrc_imx ci_hdrc mxs_dcp ulpi roles udc_core imx_sdma usbmisc_imx usb_common firmware_class virt_dma phy_mxs_usb nf_tables nfnetlink ip_tables x_tables ipv6 autofs4 [ 68.950741] CPU: 0 PID: 139 Comm: mxs_dcp_chan/ae Not tainted 5.10.34 #296 [ 68.958501] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 68.964710] PC is at memcpy+0xa8/0x330 [ 68.968479] LR is at 0xd7b2bc9d [ 68.971638] pc : [] lr : [] psr: 000f0013 [ 68.977920] sp : c2cbbee4 ip : 00000010 fp : 00000010 [ 68.983159] r10: 00000000 r9 : c3283a40 r8 : 1a5a6f08 [ 68.988402] r7 : 4bfe0ecc r6 : 76d8a220 r5 : c32f9050 r4 : 00000001 [ 68.994945] r3 : 00000ab8 r2 : fffffff0 r1 : c32f9050 r0 : 00000ab8 [ 69.001492] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 69.008646] Control: 10c53c7d Table: 83664059 DAC: 00000051 [ 69.014414] Process mxs_dcp_chan/ae (pid: 139, stack limit = 0x667b57ab) [ 69.021133] Stack: (0xc2cbbee4 to 0xc2cbc000) [ 69.025519] bee0: c32f9050 c3235408 00000010 00000010 00000ab8 00000001 bf10406c [ 69.033720] bf00: 00000000 00000000 00000010 00000000 c32355d0 832fb080 00000000 c13de2fc [ 69.041921] bf20: c3628010 00000010 c33d5780 00000ab8 bf1067e8 00000002 c21e5010 c2cba000 [ 69.050125] bf40: c32f8040 00000000 bf106a40 c32f9040 c3283a80 00000001 bf105240 c3234040 [ 69.058327] bf60: ffffe000 c3204100 c2c69800 c2cba000 00000000 bf103b84 00000000 c2eddc54 [ 69.066530] bf80: c3204144 c0140d1c c2cba000 c2c69800 c0140be8 00000000 00000000 00000000 [ 69.074730] bfa0: 00000000 00000000 00000000 c0100114 00000000 00000000 00000000 00000000 [ 69.082932] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 69.091131] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000 [ 69.099364] [] (memcpy) from [] (dcp_chan_thread_aes+0x4e8/0x840 [mxs_dcp]) [ 69.108117] [] (dcp_chan_thread_aes [mxs_dcp]) from [] (kthread+0x134/0x160) [ 69.116941] [] (kthread) from [] (ret_from_fork+0x14/0x20) [ 69.124178] Exception stack(0xc2cbbfb0 to 0xc2cbbff8) [ 69.129250] bfa0: 00000000 00000000 00000000 00000000 [ 69.137450] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 69.145648] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 69.152289] Code: e320f000 e4803004 e4804004 e4805004 (e4806004) Signed-off-by: Sean Anderson Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 108b1867e387ff938847dd661ad46913b84177bb Author: Ani Sinha Date: Tue Jul 13 08:35:21 2021 +0530 x86/hyperv: fix for unwanted manipulation of sched_clock when TSC marked unstable [ Upstream commit c445535c3efbfb8cb42d098e624d46ab149664b7 ] Marking TSC as unstable has a side effect of marking sched_clock as unstable when TSC is still being used as the sched_clock. This is not desirable. Hyper-V ultimately uses a paravirtualized clock source that provides a stable scheduler clock even on systems without TscInvariant CPU capability. Hence, mark_tsc_unstable() call should be called _after_ scheduler clock has been changed to the paravirtualized clocksource. This will prevent any unwanted manipulation of the sched_clock. Only TSC will be correctly marked as unstable. Signed-off-by: Ani Sinha Reviewed-by: Michael Kelley Tested-by: Michael Kelley Link: https://lore.kernel.org/r/20210713030522.1714803-1-ani@anisinha.ca Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 9e864d474d113321252a33adc8633dff0cbe5e40 Author: Thomas Zimmermann Date: Mon Jul 5 09:46:32 2021 +0200 drm/vkms: Let shadow-plane helpers prepare the plane's FB [ Upstream commit b43e2ec03b0de040d536591713ea9c875ff34ba9 ] Replace vkms' prepare_fb and cleanup_fb functions with the generic code for shadow-buffered planes. No functional changes. This change also fixes a problem where IGT kms_flip tests would create a segmentation fault within vkms. The driver's prepare_fb function did not report an error if a BO's vmap operation failed. The kernel later tried to operate on the non-mapped memory areas. The shared shadow-plane helpers handle errors correctly, so that the driver now avoids the segmantation fault. v2: * include paragraph about IGT tests in commit message (Melissa) Signed-off-by: Thomas Zimmermann Reviewed-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-4-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 532e8bda62732bca5082b01bff4ffaaec728e81c Author: Martynas Pumputis Date: Mon Jul 12 14:55:51 2021 +0200 libbpf: Fix reuse of pinned map on older kernel [ Upstream commit 97eb31384af943d6b97eb5947262cee4ef25cb87 ] When loading a BPF program with a pinned map, the loader checks whether the pinned map can be reused, i.e. their properties match. To derive such of the pinned map, the loader invokes BPF_OBJ_GET_INFO_BY_FD and then does the comparison. Unfortunately, on < 4.12 kernels the BPF_OBJ_GET_INFO_BY_FD is not available, so loading the program fails with the following error: libbpf: failed to get map info for map FD 5: Invalid argument libbpf: couldn't reuse pinned map at '/sys/fs/bpf/tc/globals/cilium_call_policy': parameter mismatch" libbpf: map 'cilium_call_policy': error reusing pinned map libbpf: map 'cilium_call_policy': failed to create: Invalid argument(-22) libbpf: failed to load object 'bpf_overlay.o' To fix this, fallback to derivation of the map properties via /proc/$PID/fdinfo/$MAP_FD if BPF_OBJ_GET_INFO_BY_FD fails with EINVAL, which can be used as an indicator that the kernel doesn't support the latter. Signed-off-by: Martynas Pumputis Signed-off-by: Andrii Nakryiko Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20210712125552.58705-1-m@lambda.lt Signed-off-by: Sasha Levin commit 088698537b30a8dfebf5b164da466424f856ccb0 Author: Tomi Valkeinen Date: Mon Jun 14 13:23:41 2021 +0200 media: ti-vpe: cal: fix queuing of the initial buffer [ Upstream commit 892c37f8a3d673b945e951a8754695c119a2b1b0 ] When starting streaming the driver currently programs the buffer address to the CAL base-address register and assigns the buffer pointer to ctx->dma.pending. This is not correct, as the buffer is not "pending", but active, and causes the first buffer to be needlessly written twice. Fix this by assigning the buffer pointer to ctx->dma.active. Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ef690545e6a8cd7a28bab0e47c03eadf0a7a5abf Author: Tomi Valkeinen Date: Mon Jun 14 13:23:12 2021 +0200 media: ti-vpe: cal: fix error handling in cal_camerarx_create [ Upstream commit 918d6d120a60c2640263396308eeb2b6afeb0cd6 ] cal_camerarx_create() doesn't handle error returned from cal_camerarx_sd_init_cfg(). Fix this. Signed-off-by: Tomi Valkeinen Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 94bf4cd1475c0ca9e0eb9b4e823362af7839b645 Author: Mauro Carvalho Chehab Date: Thu Jun 17 13:28:57 2021 +0200 media: dib8000: rewrite the init prbs logic [ Upstream commit 8db11aebdb8f93f46a8513c22c9bd52fa23263aa ] The logic at dib8000_get_init_prbs() has a few issues: 1. the tables used there has an extra unused value at the beginning; 2. the dprintk() message doesn't write the right value when transmission mode is not 8K; 3. the array overflow validation is done by the callers. Rewrite the code to fix such issues. This should also shut up those smatch warnings: drivers/media/dvb-frontends/dib8000.c:2125 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_8k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2129 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_2k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2131 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_4k' 14 <= 14 drivers/media/dvb-frontends/dib8000.c:2134 dib8000_get_init_prbs() error: buffer overflow 'lut_prbs_8k' 14 <= 14 Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9cfd0da89e81254302463a0da67c88e961aca151 Author: Randy Dunlap Date: Wed Jul 7 14:47:52 2021 -0700 ASoC: atmel: ATMEL drivers don't need HAS_DMA [ Upstream commit 6c5c659dfe3f02e08054a6c20019e3886618b512 ] On a config (such as arch/sh/) which does not set HAS_DMA when MMU is not set, several ATMEL ASoC drivers select symbols that cause kconfig warnings. There is one "depends on HAS_DMA" which is no longer needed. Dropping it eliminates the kconfig warnings and still builds with no problems reported. Fix the following kconfig warnings: WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_PDC Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && HAS_DMA [=n] Selected by [m]: - SND_ATMEL_SOC_SSC [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] - SND_ATMEL_SOC_SSC_PDC [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC_PDC Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] && HAS_DMA [=n] Selected by [m]: - SND_AT91_SOC_SAM9G20_WM8731 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && SND_SOC_I2C_AND_SPI [=m] WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && HAS_DMA [=n] Selected by [m]: - SND_ATMEL_SOC_SSC_DMA [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] WARNING: unmet direct dependencies detected for SND_ATMEL_SOC_SSC_DMA Depends on [n]: SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && ATMEL_SSC [=m] && HAS_DMA [=n] Selected by [m]: - SND_ATMEL_SOC_WM8904 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && I2C [=m] - SND_AT91_SOC_SAM9X5_WM8731 [=m] && SOUND [=m] && !UML && SND [=m] && SND_SOC [=m] && SND_ATMEL_SOC [=m] && (ARCH_AT91 || COMPILE_TEST [=y]) && ATMEL_SSC [=m] && SND_SOC_I2C_AND_SPI [=m] Signed-off-by: Randy Dunlap Reviewed-by: Codrin Ciubotariu Acked-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210707214752.3831-1-rdunlap@infradead.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a022ed48d1deac5dcc139cfaa71e4a26738b9c65 Author: Peter Ujfalusi Date: Mon Jul 5 22:42:45 2021 +0300 ASoC: ti: davinci-mcasp: Fix DIT mode support [ Upstream commit bbdd3f4dbe81e19b9123bc54e23ed54517615524 ] The DIT mode support has not been tested due to lack of platform where it can be tested. To be able to use the McASP on OMAP4/5 (only supporting DIT mode) we need to have DIT mode working in the McASP driver on a know platform. After hacking around (on BBW, mcasp1.axr1 can be routed out for this) it appeared that DIT mode is broken. This patch fixes it up and 16/24 bit audio works along with passthrough, but I have only tested with DTS example and test files. Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20210705194249.2385-2-peter.ujfalusi@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 47a098257a997558f01c8b56a2eaded5dae6a800 Author: Linus Walleij Date: Thu Jul 1 23:36:18 2021 +0200 drm/panel: Fix up DT bindings for Samsung lms397kf04 [ Upstream commit 710fa9aa16321f2ffdd8383f6f780c9cc1e5a197 ] Improve the bindings and make them more usable: - Pick in spi-cpha and spi-cpol from the SPI node parent, this will specify that we are "type 3" in the device tree rather than hardcoding it in the operating system. - Drop the u32 ref from the SPI frequency: comes in from the SPI host bindings. - Make spi-cpha, spi-cpol and port compulsory. - Update the example with a real-world SPI controller, spi-gpio. Cc: Noralf Trønnes Cc: devicetree@vger.kernel.org Signed-off-by: Linus Walleij Reviewed-by: Sam Ravnborg Reviewed-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20210701213618.3818821-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin commit 042c88eefe1c55cda2db86c7fc9fbf1d4563cd31 Author: Christian König Date: Sun Jun 6 11:46:33 2021 +0200 dma-buf: fix dma_resv_test_signaled test_all handling v2 [ Upstream commit 9d38814d1e346ea37a51cbf31f4424c9d059459e ] As the name implies if testing all fences is requested we should indeed test all fences and not skip the exclusive one because we see shared ones. v2: fix logic once more Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210702111642.17259-3-christian.koenig@amd.com Signed-off-by: Sasha Levin commit ea21817885538598b1e0dd65383a03f0703f2025 Author: Tim Gover Date: Mon Jun 28 15:05:33 2021 +0200 drm: vc4: Fix pixel-wrap issue with DVP teardown [ Upstream commit 0b066a6809d0f8fd9868e383add36aa5a2fa409d ] Adjust the DVP enable/disable sequence to avoid a pixel getting stuck in an internal, non resettable FIFO within PixelValve when changing HDMI resolution. The blank pixels features of the DVP can prevent signals back to pixelvalve causing it to not clear the FIFO. Adjust the ordering and timing of operations to ensure the clear signal makes it through to pixelvalve. Signed-off-by: Tim Gover Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210628130533.144617-1-maxime@cerno.tech Signed-off-by: Sasha Levin commit e01e3ed40f7542440790fc7e76ce66c85748c328 Author: Luben Tuikov Date: Thu Apr 29 20:15:42 2021 -0400 drm/amdgpu: Fix koops when accessing RAS EEPROM [ Upstream commit 1d9d2ca85b32605ac9c74c8fa42d0c1cfbe019d4 ] Debugfs RAS EEPROM files are available when the ASIC supports RAS, and when the debugfs is enabled, an also when "ras_enable" module parameter is set to 0. However in this case, we get a kernel oops when accessing some of the "ras_..." controls in debugfs. The reason for this is that struct amdgpu_ras::adev is unset. This commit sets it, thus enabling access to those facilities. Note that this facilitates EEPROM access and not necessarily RAS features or functionality. Cc: Alexander Deucher Cc: John Clements Cc: Hawking Zhang Signed-off-by: Luben Tuikov Acked-by: Alexander Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 648434f3d43c6a3dc748f2de58707dc82765bad9 Author: Luben Tuikov Date: Fri Mar 26 16:40:22 2021 -0400 drm/amdgpu: Fix amdgpu_ras_eeprom_init() [ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ] No need to account for the 2 bytes of EEPROM address--this is now well abstracted away by the fixes the the lower layers. Cc: Andrey Grodzovsky Cc: Alexander Deucher Signed-off-by: Luben Tuikov Acked-by: Alexander Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 87a832eb532a9436280a2b6f9572175ba544a4fb Author: Daniel Vetter Date: Tue Jun 22 18:55:07 2021 +0200 drm/omap: Follow implicit fencing in prepare_fb [ Upstream commit 942d8344d5f14b9ea2ae43756f319b9f44216ba4 ] I guess no one ever tried running omap together with lima or panfrost, not even sure that's possible. Anyway for consistency, fix this. Reviewed-by: Tomi Valkeinen Signed-off-by: Daniel Vetter Cc: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20210622165511.3169559-12-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 6c68fbafb9cd13e13476043fd9f6e10f792f685a Author: Andrey Grodzovsky Date: Tue Jun 22 12:23:39 2021 -0400 drm/ttm: Fix multihop assert on eviction. [ Upstream commit 403797925768d9fa870f5b1ebcd20016b397083b ] Problem: Under memory pressure when GTT domain is almost full multihop assert will come up when trying to evict LRU BO from VRAM to SYSTEM. Fix: Don't assert on multihop error in evict code but rather do a retry as we do in ttm_bo_move_buffer Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-6-andrey.grodzovsky@amd.com Signed-off-by: Sasha Levin commit 20c538cff7257069f46898ffa667483aeb9329f4 Author: Dom Cobley Date: Tue May 25 15:23:48 2021 +0200 drm/vc4: hdmi: Set HD_CTL_WHOLSMP and HD_CTL_CHALIGN_SET [ Upstream commit 1698ecb218eb82587dbfc71a2e26ded66e5ecf59 ] Symptom is random switching of speakers when using multichannel. Repeatedly running speakertest -c8 occasionally starts with channels jumbled. This is fixed with HD_CTL_WHOLSMP. The other bit looks beneficial and apears harmless in testing so I'd suggest adding it too. Documentation says: HD_CTL_WHILSMP_SET Wait for whole sample. When this bit is set MAI transmit will start only when there is at least one whole sample available in the fifo. Documentation says: HD_CTL_CHALIGN_SET Channel Align When Overflow. This bit is used to realign the audio channels in case of an overflow. If this bit is set, after the detection of an overflow, equal amount of dummy words to the missing words will be written to fifo, filling up the broken sample and maintaining alignment. Signed-off-by: Dom Cobley Signed-off-by: Maxime Ripard Reviewed-by: Nicolas Saenz Julienne Link: https://patchwork.freedesktop.org/patch/msgid/20210525132354.297468-7-maxime@cerno.tech Signed-off-by: Sasha Levin commit e280851d96cef0d5db5470b24d5fc8a3095b5e07 Author: Zack Rusin Date: Wed Jun 9 13:23:02 2021 -0400 drm/vmwgfx: Fix some static checker warnings [ Upstream commit 74231041d14030f1ae6582b9233bfe782ac23e33 ] Fix some minor issues that Coverity spotted in the code. None of that are serious but they're all valid concerns so fixing them makes sense. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20210609172307.131929-5-zackr@vmware.com Signed-off-by: Sasha Levin commit 6d49bbd76a233a82e24d569b0188b8fc35273dc4 Author: Zack Rusin Date: Wed Jun 9 13:23:01 2021 -0400 drm/vmwgfx: Fix subresource updates with new contexts [ Upstream commit a12be0277316ed923411c9c80b2899ee74d2b033 ] The has_dx variable was only set during the initialization which meant that UPDATE_SUBRESOURCE was never used. We were emulating it with UPDATE_GB_IMAGE but that's always been a stop-gap. Instead of has_dx which has been deprecated a long time ago we need to check for whether shader model 4.0 or newer is available to the device. Signed-off-by: Zack Rusin Reviewed-by: Roland Scheidegger Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20210609172307.131929-4-zackr@vmware.com Signed-off-by: Sasha Levin commit e65ab811af2a40e4326dd7c8c678bb07abe7f87d Author: Nadav Amit Date: Thu Sep 2 14:58:59 2021 -0700 userfaultfd: prevent concurrent API initialization [ Upstream commit 22e5fe2a2a279d9a6fcbdfb4dffe73821bef1c90 ] userfaultfd assumes that the enabled features are set once and never changed after UFFDIO_API ioctl succeeded. However, currently, UFFDIO_API can be called concurrently from two different threads, succeed on both threads and leave userfaultfd's features in non-deterministic state. Theoretically, other uffd operations (ioctl's and page-faults) can be dispatched while adversely affected by such changes of features. Moreover, the writes to ctx->state and ctx->features are not ordered, which can - theoretically, again - let userfaultfd_ioctl() think that userfaultfd API completed, while the features are still not initialized. To avoid races, it is arguably best to get rid of ctx->state. Since there are only 2 states, record the API initialization in ctx->features as the uppermost bit and remove ctx->state. Link: https://lkml.kernel.org/r/20210808020724.1022515-3-namit@vmware.com Fixes: 9cd75c3cd4c3d ("userfaultfd: non-cooperative: add ability to report non-PF events from uffd descriptor") Signed-off-by: Nadav Amit Cc: Alexander Viro Cc: Andrea Arcangeli Cc: Axel Rasmussen Cc: Jens Axboe Cc: Mike Rapoport Cc: Peter Xu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8ea6563fcb17bf67e73d6d9e70a75c22aec0fc54 Author: Masahiro Yamada Date: Thu Aug 19 09:01:14 2021 +0900 kbuild: Fix 'no symbols' warning when CONFIG_TRIM_UNUSD_KSYMS=y [ Upstream commit 52d83df682c82055961531853c066f4f16e234ea ] When CONFIG_TRIM_UNUSED_KSYMS is enabled, I see some warnings like this: nm: arch/x86/entry/vdso/vdso32/note.o: no symbols $NM (both GNU nm and llvm-nm) warns when no symbol is found in the object. Suppress the stderr. Fangrui Song mentioned binutils>=2.37 `nm -q` can be used to suppress "no symbols" [1], and llvm-nm>=13.0.0 supports -q as well. We cannot use it for now, but note it as a TODO. [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=27408 Fixes: bbda5ec671d3 ("kbuild: simplify dependency generation for CONFIG_TRIM_UNUSED_KSYMS") Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Signed-off-by: Sasha Levin commit 994902da1ab91f515de63328351a9c0ec62dab5c Author: Oleksij Rempel Date: Thu Sep 2 09:19:51 2021 +0200 MIPS: Malta: fix alignment of the devicetree buffer [ Upstream commit bea6a94a279bcbe6b2cde348782b28baf12255a5 ] Starting with following patch MIPS Malta is not able to boot: | commit 79edff12060fe7772af08607eff50c0e2486c5ba | Author: Rob Herring | scripts/dtc: Update to upstream version v1.6.0-51-g183df9e9c2b9 The reason is the alignment test added to the fdt_ro_probe_(). To fix this issue, we need to make sure that fdt_buf is aligned. Since the dtc patch was designed to uncover potential issue, I handle initial MIPS Malta patch as initial bug. Fixes: e81a8c7dabac ("MIPS: Malta: Setup RAM regions via DT") Signed-off-by: Oleksij Rempel Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 8c66f86b421c36b6d031b5261939ca3ee94b89a0 Author: Jaegeuk Kim Date: Mon Aug 30 13:30:45 2021 -0700 f2fs: should put a page beyond EOF when preparing a write [ Upstream commit 9605f75cf36e0bcc0f4ada07b5be712d30107607 ] The prepare_compress_overwrite() gets/locks a page to prepare a read, and calls f2fs_read_multi_pages() which checks EOF first. If there's any page beyond EOF, we unlock the page and set cc->rpages[i] = NULL, which we can't put the page anymore. This makes page leak, so let's fix by putting that page. Fixes: a949dc5f2c5c ("f2fs: compress: fix race condition of overwrite vs truncate") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 957c40ec56c83df1e92c29e516eb6f8823bb1cb7 Author: Jaegeuk Kim Date: Mon Aug 30 11:37:32 2021 -0700 f2fs: deallocate compressed pages when error happens [ Upstream commit 827f02842e40ea2e00f401e8f4cb1bccf3b8cd86 ] In f2fs_write_multi_pages(), f2fs_compress_pages() allocates pages for compression work in cc->cpages[]. Then, f2fs_write_compressed_pages() initiates bio submission. But, if there's any error before submitting the IOs like early f2fs_cp_error(), previously it didn't free cpages by f2fs_compress_free_page(). Let's fix memory leak by putting that just before deallocating cc->cpages. Fixes: 4c8ff7095bef ("f2fs: support data compression") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fb3e61f921b6b01b7aec9a8a60c93bd7efbbbd35 Author: Chao Yu Date: Wed Aug 25 19:34:19 2021 +0800 f2fs: fix to unmap pages from userspace process in punch_hole() [ Upstream commit c8dc3047c48540183744f959412d44b08c5435e1 ] We need to unmap pages from userspace process before removing pagecache in punch_hole() like we did in f2fs_setattr(). Similar change: commit 5e44f8c374dc ("ext4: hole-punch use truncate_pagecache_range") Fixes: fbfa2cc58d53 ("f2fs: add file operations") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 1dfcf666ae29c075da5b3693d2c290c9ee919dbf Author: Chao Yu Date: Thu Aug 26 10:03:15 2021 +0800 f2fs: fix unexpected ENOENT comes from f2fs_map_blocks() [ Upstream commit adf9ea89c719c1d23794e363f631e376b3ff8cbc ] In below path, it will return ENOENT if filesystem is shutdown: - f2fs_map_blocks - f2fs_get_dnode_of_data - f2fs_get_node_page - __get_node_page - read_node_page - is_sbi_flag_set(sbi, SBI_IS_SHUTDOWN) return -ENOENT - force return value from ENOENT to 0 It should be fine for read case, since it indicates a hole condition, and caller could use .m_next_pgofs to skip the hole and continue the lookup. However it may cause confusing for write case, since leaving a hole there, and said nothing was wrong doesn't help. There is at least one case from dax_iomap_actor() will complain that, so fix this in prior to supporting dax in f2fs. xfstest generic/388 reports below warning: ubuntu godown: xfstests-induced forced shutdown of /mnt/scratch_f2fs: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 485833 at fs/dax.c:1127 dax_iomap_actor+0x339/0x370 Call Trace: iomap_apply+0x1c4/0x7b0 ? dax_iomap_rw+0x1c0/0x1c0 dax_iomap_rw+0xad/0x1c0 ? dax_iomap_rw+0x1c0/0x1c0 f2fs_file_write_iter+0x5ab/0x970 [f2fs] do_iter_readv_writev+0x273/0x2e0 do_iter_write+0xab/0x1f0 vfs_iter_write+0x21/0x40 iter_file_splice_write+0x287/0x540 do_splice+0x37c/0xa60 __x64_sys_splice+0x15f/0x3a0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae ubuntu godown: xfstests-induced forced shutdown of /mnt/scratch_f2fs: ------------[ cut here ]------------ RIP: 0010:dax_iomap_pte_fault.isra.0+0x72e/0x14a0 Call Trace: dax_iomap_fault+0x44/0x70 f2fs_dax_huge_fault+0x155/0x400 [f2fs] f2fs_dax_fault+0x18/0x30 [f2fs] __do_fault+0x4e/0x120 do_fault+0x3cf/0x7a0 __handle_mm_fault+0xa8c/0xf20 ? find_held_lock+0x39/0xd0 handle_mm_fault+0x1b6/0x480 do_user_addr_fault+0x320/0xcd0 ? rcu_read_lock_sched_held+0x67/0xc0 exc_page_fault+0x77/0x3f0 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 Fixes: 83a3bfdb5a8a ("f2fs: indicate shutdown f2fs to allow unmount successfully") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0366fa86cac0d5b08f6437b55c80f77c9bc603ec Author: Chao Yu Date: Tue Aug 24 08:12:08 2021 +0800 f2fs: fix to account missing .skipped_gc_rwsem [ Upstream commit ad126ebddecbf696e0cf214ff56c7b170fa9f0f7 ] There is a missing place we forgot to account .skipped_gc_rwsem, fix it. Fixes: 6f8d4455060d ("f2fs: avoid fi->i_gc_rwsem[WRITE] lock in f2fs_gc") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 4e6712d66e337c2d07d0aadd71ae61da97571732 Author: Yongqiang Niu Date: Mon Aug 2 15:52:26 2021 +0800 soc: mediatek: cmdq: add address shift in jump [ Upstream commit 8b60ed2b1674b78ebc433a11efa7d48821229037 ] Add address shift when compose jump instruction to compatible with 35bit format. Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform") Signed-off-by: Yongqiang Niu Reviewed-by: Nicolas Boichat Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 6f5a0687fcff51d533f6ac47e319376a1485d64a Author: Alexey Kardashevskiy Date: Fri Aug 27 14:07:06 2021 +1000 KVM: PPC: Fix clearing never mapped TCEs in realmode [ Upstream commit 1d78dfde33a02da1d816279c2e3452978b7abd39 ] Since commit e1a1ef84cd07 ("KVM: PPC: Book3S: Allocate guest TCEs on demand too"), pages for TCE tables for KVM guests are allocated only when needed. This allows skipping any update when clearing TCEs. This works mostly fine as TCE updates are handled when the MMU is enabled. The realmode handlers fail with H_TOO_HARD when pages are not yet allocated, except when clearing a TCE in which case KVM prints a warning and proceeds to dereference a NULL pointer, which crashes the host OS. This has not been caught so far as the change in commit e1a1ef84cd07 is reasonably new, and POWER9 runs mostly radix which does not use realmode handlers. With hash, the default TCE table is memset() by QEMU when the machine is reset which triggers page faults and the KVM TCE device's kvm_spapr_tce_fault() handles those with MMU on. And the huge DMA windows are not cleared by VMs which instead successfully create a DMA window big enough to map the VM memory 1:1 and then VMs just map everything without clearing. This started crashing now as commit 381ceda88c4c ("powerpc/pseries/iommu: Make use of DDW for indirect mapping") added a mode when a dymanic DMA window not big enough to map the VM memory 1:1 but it is used anyway, and the VM now is the first (i.e. not QEMU) to clear a just created table. Note that upstream QEMU needs to be modified to trigger the VM to trigger the host OS crash. This replaces WARN_ON_ONCE_RM() with a check and return, and adds another warning if TCE is not being cleared. Fixes: e1a1ef84cd07 ("KVM: PPC: Book3S: Allocate guest TCEs on demand too") Signed-off-by: Alexey Kardashevskiy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210827040706.517652-1-aik@ozlabs.ru Signed-off-by: Sasha Levin commit fd165f976331c5fb41e1d1024358981fb05072af Author: Codrin Ciubotariu Date: Wed Jul 7 16:12:13 2021 +0300 clk: at91: clk-generated: Limit the requested rate to our range [ Upstream commit af7651e67b9d5f7e63ea23b118e3672ac662244a ] On clk_generated_determine_rate(), the requested rate could be outside of clk's range. Limit the rate to the clock's range to not return an error. Fixes: df70aeef6083 ("clk: at91: add generated clock driver") Signed-off-by: Codrin Ciubotariu Link: https://lore.kernel.org/r/20210707131213.3283509-1-codrin.ciubotariu@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 0e1f2ad1e1fd7d182913983def4a17c7f3a10acf Author: Sergio Paracuellos Date: Tue Jul 27 07:55:37 2021 +0200 clk: ralink: avoid to set 'CLK_IS_CRITICAL' flag for gates [ Upstream commit c16edf5ff8ece9c4135175da4103cee1bec360be ] 'clk_init_data' for gates is setting up 'CLK_IS_CRITICAL' flag for all of them. This was being doing because some drivers of this SoC might not be ready to use the clock and we don't wanted the kernel to disable them since default behaviour without clock driver was to set all gate bits to enabled state. After a bit more testing and checking driver code it is safe to remove this flag and just let the kernel to disable those gates that are not in use. No regressions seems to appear. Fixes: 48df7a26f470 ("clk: ralink: add clock driver for mt7621 SoC") Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20210727055537.11785-1-sergio.paracuellos@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b5e7b7d65a11d66baf4626309608e0899019d37e Author: David Howells Date: Thu Jun 17 14:21:00 2021 +0100 fscache: Fix cookie key hashing [ Upstream commit 35b72573e977ed6b18b094136a4fa3e0ffb13603 ] The current hash algorithm used for hashing cookie keys is really bad, producing almost no dispersion (after a test kernel build, ~30000 files were split over just 18 out of the 32768 hash buckets). Borrow the full_name_hash() hash function into fscache to do the hashing for cookie keys and, in the future, volume keys. I don't want to use full_name_hash() as-is because I want the hash value to be consistent across arches and over time as the hash value produced may get used on disk. I can also optimise parts of it away as the key will always be a padded array of aligned 32-bit words. Fixes: ec0328e46d6e ("fscache: Maintain a catalogue of allocated cookies") Signed-off-by: David Howells Reviewed-by: Jeff Layton cc: linux-cachefs@redhat.com Link: https://lore.kernel.org/r/162431201844.2908479.8293647220901514696.stgit@warthog.procyon.org.uk/ Signed-off-by: Sasha Levin commit 70a0003ba1d68fff42fc315790e827f7b32300ec Author: Wenpeng Liang Date: Thu Aug 26 21:37:31 2021 +0800 RDMA/hns: Fix QP's resp incomplete assignment [ Upstream commit d2e0ccffcdd7209fc9881c8970d2a7e28dcb43b9 ] The resp passed to the user space represents the enable flag of qp, incomplete assignment will cause some features of the user space to be disabled. Fixes: 90ae0b57e4a5 ("RDMA/hns: Combine enable flags of qp") Fixes: aba457ca890c ("RDMA/hns: Support owner mode doorbell") Link: https://lore.kernel.org/r/1629985056-57004-3-git-send-email-liangwenpeng@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e72f84891b2b592370522826f8f989286f76c82d Author: Wenpeng Liang Date: Thu Aug 26 21:37:30 2021 +0800 RDMA/hns: Fix query destination qpn [ Upstream commit e788a3cd5787aca74e0ee00202d4dca64b43f043 ] The bit width of dqpn is 24 bits, using u8 will cause truncation error. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1629985056-57004-2-git-send-email-liangwenpeng@huawei.com Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3c137080a8561cc964cc50438c5fef5a8b81eab2 Author: Srikar Dronamraju Date: Thu Aug 26 15:34:00 2021 +0530 powerpc/smp: Update cpu_core_map on all PowerPc systems [ Upstream commit b8b928030332a0ca16d42433eb2c3085600d8704 ] lscpu() uses core_siblings to list the number of sockets in the system. core_siblings is set using topology_core_cpumask. While optimizing the powerpc bootup path, Commit 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask"). it was found that updating cpu_core_mask() ended up taking a lot of time. It was thought that on Powerpc, cpu_core_mask() would always be same as cpu_cpu_mask() i.e number of sockets will always be equal to number of nodes. As an optimization, cpu_core_mask() was made a snapshot of cpu_cpu_mask(). However that was found to be false with PowerPc KVM guests, where each node could have more than one socket. So with Commit c47f892d7aa6 ("powerpc/smp: Reintroduce cpu_core_mask"), cpu_core_mask was updated based on chip_id but in an optimized way using some mask manipulations and chip_id caching. However on non-PowerNV and non-pseries KVM guests (i.e not implementing cpu_to_chip_id(), continued to use a copy of cpu_cpu_mask(). There are two issues that were noticed on such systems 1. lscpu would report one extra socket. On a IBM,9009-42A (aka zz system) which has only 2 chips/ sockets/ nodes, lscpu would report Architecture: ppc64le Byte Order: Little Endian CPU(s): 160 On-line CPU(s) list: 0-159 Thread(s) per core: 8 Core(s) per socket: 6 Socket(s): 3 <-------------- NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-79 NUMA node1 CPU(s): 80-159 2. Currently cpu_cpu_mask is updated when a core is added/removed. However its not updated when smt mode switching or on CPUs are explicitly offlined. However all other percpu masks are updated to ensure only active/online CPUs are in the masks. This results in build_sched_domain traces since there will be CPUs in cpu_cpu_mask() but those CPUs are not present in SMT / CACHE / MC / NUMA domains. A loop of threads running smt mode switching and core add/remove will soon show this trace. Hence cpu_cpu_mask has to be update at smt mode switch. This will have impact on cpu_core_mask(). cpu_core_mask() is a snapshot of cpu_cpu_mask. Different CPUs within the same socket will end up having different cpu_core_masks since they are snapshots at different points of time. This means when lscpu will start reporting many more sockets than the actual number of sockets/ nodes / chips. Different ways to handle this problem: A. Update the snapshot aka cpu_core_mask for all CPUs whenever cpu_cpu_mask is updated. This would a non-optimal solution. B. Instead of a cpumask_var_t, make cpu_core_map a cpumask pointer pointing to cpu_cpu_mask. However percpu cpumask pointer is frowned upon and we need a clean way to handle PowerPc KVM guest which is not a snapshot. C. Update cpu_core_masks all PowerPc systems like in PowerPc KVM guests using mask manipulations. This approach is relatively simple and unifies with the existing code. D. On top of 3, we could also resurrect get_physical_package_id which could return a nid for the said CPU. However this is not needed at this time. Option C is the preferred approach for now. While this is somewhat a revert of Commit 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask"). 1. Plain revert has some conflicts 2. For chip_id == -1, the cpu_core_mask is made identical to cpu_cpu_mask, unlike previously where cpu_core_mask was set to a core if chip_id doesn't exist. This goes by the principle that if chip_id is not exposed, then sockets / chip / node share the same set of CPUs. With the fix, lscpu o/p would be Architecture: ppc64le Byte Order: Little Endian CPU(s): 160 On-line CPU(s) list: 0-159 Thread(s) per core: 8 Core(s) per socket: 6 Socket(s): 2 <-------------- NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-79 NUMA node1 CPU(s): 80-159 Fixes: 4ca234a9cbd7 ("powerpc/smp: Stop updating cpu_core_mask") Signed-off-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210826100401.412519-3-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit cee5cd01d45fa4bf5c3318ddbe18966a0d496e03 Author: Srikar Dronamraju Date: Thu Aug 26 15:33:59 2021 +0530 powerpc/smp: Fix a crash while booting kvm guest with nr_cpus=2 [ Upstream commit 8efd249babea2fec268cff90b9f5ca723dbb7499 ] Aneesh reported a crash with a fairly recent upstream kernel when booting kernel whose commandline was appended with nr_cpus=2 1:mon> e cpu 0x1: Vector: 300 (Data Access) at [c000000008a67bd0] pc: c00000000002557c: cpu_to_chip_id+0x3c/0x100 lr: c000000000058380: start_secondary+0x460/0xb00 sp: c000000008a67e70 msr: 8000000000001033 dar: 10 dsisr: 80000 current = 0xc00000000891bb00 paca = 0xc0000018ff981f80 irqmask: 0x03 irq_happened: 0x01 pid = 0, comm = swapper/1 Linux version 5.13.0-rc3-15704-ga050a6d2b7e8 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #433 SMP Tue May 25 02:38:49 CDT 2021 1:mon> t [link register ] c000000000058380 start_secondary+0x460/0xb00 [c000000008a67e70] c000000008a67eb0 (unreliable) [c000000008a67eb0] c0000000000589d4 start_secondary+0xab4/0xb00 [c000000008a67f90] c00000000000c654 start_secondary_prolog+0x10/0x14 Current code assumes that num_possible_cpus() is always greater than threads_per_core. However this may not be true when using nr_cpus=2 or similar options. Handle the case where num_possible_cpus() is not an exact multiple of threads_per_core. Fixes: c1e53367dab1 ("powerpc/smp: Cache CPU to chip lookup") Reported-by: Aneesh Kumar K.V Signed-off-by: Srikar Dronamraju Debugged-by: Michael Ellerman Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210826100401.412519-2-srikar@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 45d69a44c1e3079ca01dbc2f33fe8a0ca287f2fc Author: Hans de Goede Date: Thu Aug 26 16:08:22 2021 +0200 platform/x86: dell-smbios-wmi: Add missing kfree in error-exit from run_smbios_call [ Upstream commit 0487d4fc42d7f31a56cfd9e2237f9ebd889e6112 ] As pointed out be Kees Cook if we return -EIO because the obj->type != ACPI_TYPE_BUFFER, then we must kfree the output buffer before the return. Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Reported-by: Kees Cook Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20210826140822.71198-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 93aa16e83dbad6cdc582f8e4835739e1de7d8014 Author: Junxian Huang Date: Wed Aug 25 17:43:12 2021 +0800 RDMA/hns: Bugfix for incorrect association between dip_idx and dgid [ Upstream commit eb653eda1e91dd3e7d1d2448d528d033dbfbe78f ] dip_idx and dgid should be a one-to-one mapping relationship, but when qp_num loops back to the start number, it may happen that two different dgid are assiociated to the same dip_idx incorrectly. One solution is to store the qp_num that is not assigned to dip_idx in an array. When a dip_idx needs to be allocated to a new dgid, an spare qp_num is extracted and assigned to dip_idx. Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW") Link: https://lore.kernel.org/r/1629884592-23424-4-git-send-email-liangwenpeng@huawei.com Signed-off-by: Junxian Huang Signed-off-by: Yangyang Li Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit c0ff8bcb9a7eb0877a5e78a5d3a75a5fd0be7d4e Author: Junxian Huang Date: Wed Aug 25 17:43:11 2021 +0800 RDMA/hns: Bugfix for the missing assignment for dip_idx [ Upstream commit 074f315fc54a9ce45559a44ca36d9fa1ee1ea2cd ] When the dgid-dip_idx mapping relationship exists, dip should be assigned. Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW") Link: https://lore.kernel.org/r/1629884592-23424-3-git-send-email-liangwenpeng@huawei.com Signed-off-by: Junxian Huang Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit cdda0778baa74f95e7c3032be60513e08993c5c5 Author: Junxian Huang Date: Wed Aug 25 17:43:10 2021 +0800 RDMA/hns: Bugfix for data type of dip_idx [ Upstream commit 4303e61264c45cb535255c5b76400f5c4ab1305d ] dip_idx is associated with qp_num whose data type is u32. However, dip_idx is incorrectly defined as u8 data in the hns_roce_dip struct, which leads to data truncation during value assignment. Fixes: f91696f2f053 ("RDMA/hns: Support congestion control type selection according to the FW") Link: https://lore.kernel.org/r/1629884592-23424-2-git-send-email-liangwenpeng@huawei.com Signed-off-by: Junxian Huang Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 10436af984dad7081048bb535bc08cbeee67f46a Author: Yixing Liu Date: Wed Aug 25 17:19:29 2021 +0800 RDMA/hns: Fix incorrect lsn field [ Upstream commit 9bed8a70716ba65d300b9cc30eb7e0276353f7bf ] In RNR NAK screnario, according to the specification, when no credit is available, only the first fragment of the send request can be sent. The LSN(Limit Sequence Number) field should be 0 or the entire packet will be resent. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1629883169-2306-1-git-send-email-liangwenpeng@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5d2246972e54329dac3a36839989dd42d1a6e9bc Author: Kajol Jain Date: Wed Aug 18 22:45:56 2021 +0530 powerpc/perf: Fix the check for SIAR value [ Upstream commit 3c69a5f22223fa3e312689ec218b5059784d49d7 ] Incase of random sampling, there can be scenarios where Sample Instruction Address Register(SIAR) may not latch to the sampled instruction and could result in the value of 0. In these scenarios it is preferred to return regs->nip. These corner cases are seen in the previous generation (p9) also. Patch adds the check for SIAR value along with regs_use_siar and siar_valid checks so that the function will return regs->nip incase SIAR is zero. Patch drops the code under PPMU_P10_DD1 flag check which handles SIAR 0 case only for Power10 DD1. Fixes: 2ca13a4cc56c9 ("powerpc/perf: Use regs->nip when SIAR is zero") Signed-off-by: Kajol Jain Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210818171556.36912-3-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit d05b4290c1f5019a80022078162c8a2aa02139a0 Author: Nicholas Piggin Date: Thu Aug 12 02:00:43 2021 +1000 KVM: PPC: Book3S HV Nested: Reflect guest PMU in-use to L0 when guest SPRs are live [ Upstream commit 1782663897945a5cf28e564ba5eed730098e9aa4 ] After the L1 saves its PMU SPRs but before loading the L2's PMU SPRs, switch the pmcregs_in_use field in the L1 lppaca to the value advertised by the L2 in its VPA. On the way out of the L2, set it back after saving the L2 PMU registers (if they were in-use). This transfers the PMU liveness indication between the L1 and L2 at the points where the registers are not live. This fixes the nested HV bug for which a workaround was added to the L0 HV by commit 63279eeb7f93a ("KVM: PPC: Book3S HV: Always save guest pmu for guest capable of nesting"), which explains the problem in detail. That workaround is no longer required for guests that include this bug fix. Fixes: 360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Reviewed-by: Fabiano Rosas Link: https://lore.kernel.org/r/20210811160134.904987-10-npiggin@gmail.com Signed-off-by: Sasha Levin commit d9520fa1efc6996e6ca84c4aad003eea01189de3 Author: Alim Akhtar Date: Thu Aug 19 22:41:31 2021 +0530 scsi: ufs: ufs-exynos: Fix static checker warning [ Upstream commit 313bf281f2091552f509fd05a74172c70ce7572f ] clk_get_rate() returns unsigned long and currently this driver stores the return value in u32 type, resulting the below warning: Fixed smatch warnings: drivers/scsi/ufs/ufs-exynos.c:286 exynos_ufs_get_clk_info() warn: wrong type for 'ufs->mclk_rate' (should be 'ulong') drivers/scsi/ufs/ufs-exynos.c:287 exynos_ufs_get_clk_info() warn: wrong type for 'pclk_rate' (should be 'ulong') Link: https://lore.kernel.org/r/20210819171131.55912-1-alim.akhtar@samsung.com Fixes: 55f4b1f73631 ("scsi: ufs: ufs-exynos: Add UFS host support for Exynos SoCs") Reported-by: Dan Carpenter Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a756dd06fe9ea1d1e74e655f234b82b9a9cec3ba Author: Fabiano Rosas Date: Thu Aug 5 18:26:14 2021 -0300 KVM: PPC: Book3S HV: Fix copy_tofrom_guest routines [ Upstream commit 5d7d6dac8fe99ed59eee2300e4a03370f94d5222 ] The __kvmhv_copy_tofrom_guest_radix function was introduced along with nested HV guest support. It uses the platform's Radix MMU quadrants to provide a nested hypervisor with fast access to its nested guests memory (H_COPY_TOFROM_GUEST hypercall). It has also since been added as a fast path for the kvmppc_ld/st routines which are used during instruction emulation. The commit def0bfdbd603 ("powerpc: use probe_user_read() and probe_user_write()") changed the low level copy function from raw_copy_from_user to probe_user_read, which adds a check to access_ok. In powerpc that is: static inline bool __access_ok(unsigned long addr, unsigned long size) { return addr < TASK_SIZE_MAX && size <= TASK_SIZE_MAX - addr; } and TASK_SIZE_MAX is 0x0010000000000000UL for 64-bit, which means that setting the two MSBs of the effective address (which correspond to the quadrant) now cause access_ok to reject the access. This was not caught earlier because the most common code path via kvmppc_ld/st contains a fallback (kvm_read_guest) that is likely to succeed for L1 guests. For nested guests there is no fallback. Another issue is that probe_user_read (now __copy_from_user_nofault) does not return the number of bytes not copied in case of failure, so the destination memory is not being cleared anymore in kvmhv_copy_from_guest_radix: ret = kvmhv_copy_tofrom_guest_radix(vcpu, eaddr, to, NULL, n); if (ret > 0) <-- always false! memset(to + (n - ret), 0, ret); This patch fixes both issues by skipping access_ok and open-coding the low level __copy_to/from_user_inatomic. Fixes: def0bfdbd603 ("powerpc: use probe_user_read() and probe_user_write()") Signed-off-by: Fabiano Rosas Reviewed-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210805212616.2641017-2-farosas@linux.ibm.com Signed-off-by: Sasha Levin commit 61cfe495959e2919da7d468c223ca12b5a05ef56 Author: Ahmad Fatoum Date: Tue Aug 10 17:14:33 2021 +0200 clk: imx8m: fix clock tree update of TF-A managed clocks [ Upstream commit d36207b848a6490e14664e2197a1c8ab51d8148e ] On the i.MX8M*, the TF-A exposes a SiP (Silicon Provider) service for DDR frequency scaling. The imx8m-ddrc-devfreq driver calls the SiP and then does clk_set_parent on the DDR muxes to synchronize the clock tree. Since 936c383673b9 ("clk: imx: fix composite peripheral flags"), these TF-A managed muxes have SET_PARENT_GATE set, which results in imx8m-ddrc-devfreq's clk_set_parent after SiP failing with -EBUSY: echo 25000000 > userspace/set_freq imx8m-ddrc-devfreq 3d400000.memory-controller: failed to set dram_apb parent: -16 Fix this by adding a new i.MX composite flag for firmware managed clocks, which clears SET_PARENT_GATE. This is safe to do, because updating the Linux clock tree to reflect reality will always be glitch-free. Fixes: 936c383673b9 ("clk: imx: fix composite peripheral flags") Signed-off-by: Ahmad Fatoum Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20210810151432.9228-1-a.fatoum@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit 3903efab38517ac07c7a6bc08d13ecff6863b2c4 Author: Lucas Stach Date: Mon Jun 28 23:15:53 2021 +0200 clk: imx8mm: use correct mux type for clkout path [ Upstream commit 1822b4dedc4d8cab96fd1d87bf8ff98194e29d9b ] The mux in the clkout path needs the current selected parent to be enabled for the switch to work. Use the correct mux type to have the clk framework take care of this requirement. Fixes: c1ae5c6f789a ("clk: imx8mm: add clkout1/2 support") Signed-off-by: Lucas Stach Reviewed-by: Abel Vesa Link: https://lore.kernel.org/r/20210628211554.2510238-1-l.stach@pengutronix.de Signed-off-by: Abel Vesa Signed-off-by: Sasha Levin commit ac999a9e44cd337db556ec5bb754abdedd566e6d Author: Lang Cheng Date: Sat Aug 21 17:53:27 2021 +0800 RDMA/hns: Ownerbit mode add control field [ Upstream commit f8c549afd1e76ad78b1d044a307783c9b94ae3ab ] The ownerbit mode is for external card mode. Make it controlled by the firmware. Fixes: aba457ca890c ("RDMA/hns: Support owner mode doorbell") Link: https://lore.kernel.org/r/1629539607-33217-4-git-send-email-liangwenpeng@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 94cf0f3b3a9fdc1873c06ac177665ba5f80feb98 Author: Lukas Bulwahn Date: Tue Aug 10 12:21:48 2021 +0200 HID: thrustmaster: clean up Makefile and adapt quirks [ Upstream commit 462ba66198a4a8ea996028915af10a698086e302 ] Commit c49c33637802 ("HID: support for initialization of some Thrustmaster wheels") messed up the Makefile and quirks during the refactoring of this commit. Luckily, ./scripts/checkkconfigsymbols.py warns on non-existing configs: HID_TMINIT Referencing files: drivers/hid/Makefile, drivers/hid/hid-quirks.c Following the discussion (see Link), CONFIG_HID_THRUSTMASTER is the intended config for CONFIG_HID_TMINIT and the file hid-tminit.c was actually added as hid-thrustmaster.c. So, clean up Makefile and adapt quirks to that refactoring. Fixes: c49c33637802 ("HID: support for initialization of some Thrustmaster wheels") Link: https://lore.kernel.org/linux-input/CAKXUXMx6dByO03f3dX0X5zjvQp0j2AhJBg0vQFDmhZUhtKxRxw@mail.gmail.com/ Signed-off-by: Lukas Bulwahn Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit e36c92fa9482ebf2c1bed3065cf8e1ae107a125e Author: Jim Broadus Date: Sun Aug 8 23:55:05 2021 -0700 HID: i2c-hid: Fix Elan touchpad regression [ Upstream commit 786537063bbfb3a7ebc6fc21b2baf37fb91df401 ] A quirk was recently added for Elan devices that has same device match as an entry earlier in the list. The i2c_hid_lookup_quirk function will always return the last match in the list, so the new entry shadows the old entry. The quirk in the previous entry, I2C_HID_QUIRK_BOGUS_IRQ, silenced a flood of messages which have reappeared in the 5.13 kernel. This change moves the two quirk flags into the same entry. Fixes: ca66a6770bd9 (HID: i2c-hid: Skip ELAN power-on command after reset) Signed-off-by: Jim Broadus Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit dbd53e75f3a42a4e37ddbbfbc5458b7b827e5966 Author: Basavaraj Natikar Date: Mon Aug 2 19:33:37 2021 +0530 HID: amd_sfh: Fix period data field to enable sensor [ Upstream commit 3978f54817559b28535c58a00d3d31bbd5d0b65a ] Existing amd-sfh driver is programming the MP2 firmware period field in units of jiffies, but the MP2 firmware expects in milliseconds unit. Changing it to milliseconds. Fixes: 4b2c53d93a4b ("SFH:Transport Driver to add support of AMD Sensor Fusion Hub (SFH)") Reviewed-by: Shyam Sundar S K Signed-off-by: Basavaraj Natikar Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 40083e3423f24a97276da4efadcf05c7f15d7af5 Author: YueHaibing Date: Wed Aug 4 20:59:39 2021 +0800 RDMA/hns: Fix return in hns_roce_rereg_user_mr() [ Upstream commit c4c7d7a43246a42b0355692c3ed53dff7cbb29bb ] If re-registering an MR in hns_roce_rereg_user_mr(), we should return NULL instead of passing 0 to ERR_PTR for clarity. Fixes: 4e9fc1dae2a9 ("RDMA/hns: Optimize the MR registration process") Link: https://lore.kernel.org/r/20210804125939.20516-1-yuehaibing@huawei.com Signed-off-by: YueHaibing Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b09b790e4e423dd446d7f99c6becd5fd4dde887b Author: Lu Baolu Date: Wed Aug 18 21:48:44 2021 +0800 iommu/vt-d: Update the virtual command related registers [ Upstream commit 4d99efb229e63928c6b03a756a2e38cd4777fbe8 ] The VT-d spec Revision 3.3 updated the virtual command registers, virtual command opcode B register, virtual command response register and virtual command capability register (Section 10.4.43, 10.4.44, 10.4.45, 10.4.46). This updates the virtual command interface implementation in the Intel IOMMU driver accordingly. Fixes: 24f27d32ab6b7 ("iommu/vt-d: Enlightened PASID allocation") Signed-off-by: Lu Baolu Cc: Ashok Raj Cc: Sanjay Kumar Cc: Kevin Tian Link: https://lore.kernel.org/r/20210713042649.3547403-1-baolu.lu@linux.intel.com Link: https://lore.kernel.org/r/20210818134852.1847070-2-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit f7dca6f4fcb9c501e050d5a586c25f716d7a4999 Author: Chao Yu Date: Fri Aug 6 10:45:20 2021 +0800 f2fs: fix to keep compatibility of fault injection interface [ Upstream commit b96d9b3b09f0427b289332c6f6bfbf747a19b654 ] The value of FAULT_* macros and its description in f2fs.rst became inconsistent, fix this to keep compatibility of fault injection interface. Fixes: 67883ade7a98 ("f2fs: remove FAULT_ALLOC_BIO") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit e26497f137557388686b42bdccf5213d82195052 Author: Joel Stanley Date: Tue Aug 17 14:24:06 2021 +0930 powerpc/config: Renable MTD_PHYSMAP_OF [ Upstream commit d0e28a6145c3455b69991245e7f6147eb914b34a ] CONFIG_MTD_PHYSMAP_OF is not longer enabled as it depends on MTD_PHYSMAP which is not enabled. This is a regression from commit 642b1e8dbed7 ("mtd: maps: Merge physmap_of.c into physmap-core.c"), which added the extra dependency. Add CONFIG_MTD_PHYSMAP=y so this stays in the config, as Christophe said it is useful for build coverage. Fixes: 642b1e8dbed7 ("mtd: maps: Merge physmap_of.c into physmap-core.c") Signed-off-by: Joel Stanley Acked-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210817045407.2445664-3-joel@jms.id.au Signed-off-by: Sasha Levin commit dc5f90be0aa76bf5ee584453f9b4886d8030cf8a Author: Joel Stanley Date: Tue Aug 17 14:24:05 2021 +0930 powerpc/config: Fix IPV6 warning in mpc855_ads [ Upstream commit c5ac55b6cbc604ad4144c380feae20f69453df91 ] When building this config there's a warning: 79:warning: override: reassigning to symbol IPV6 Commit 9a1762a4a4ff ("powerpc/8xx: Update mpc885_ads_defconfig to improve CI") added CONFIG_IPV6=y, but left '# CONFIG_IPV6 is not set' in. IPV6 is default y, so remove both to clean up the build. Fixes: 9a1762a4a4ff ("powerpc/8xx: Update mpc885_ads_defconfig to improve CI") Signed-off-by: Joel Stanley Acked-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210817045407.2445664-2-joel@jms.id.au Signed-off-by: Sasha Levin commit 9b79fe95ed4de8d1ce991658c62d111f19d7d26c Author: Dan Carpenter Date: Tue Aug 10 11:51:49 2021 +0300 scsi: qedf: Fix error codes in qedf_alloc_global_queues() [ Upstream commit ccc89737aa6b9f248cf1623014038beb6c2b7f56 ] This driver has some left over "return 1" on failure style code mixed with "return negative error codes" style code. The caller doesn't care so we should just convert everything to return negative error codes. Then there was a problem that there were two variables used to store error codes which just resulted in confusion. If qedf_alloc_bdq() returned a negative error code, we accidentally returned success instead of propagating the error code. So get rid of the "rc" variable and use "status" every where. Also remove the "status = 0" initialization so that these sorts of bugs will be detected by the compiler in the future. Link: https://lore.kernel.org/r/20210810085023.GA23998@kili Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c9e69913093cdeb70f2c35935368da79b70898c7 Author: Dan Carpenter Date: Tue Aug 10 11:47:53 2021 +0300 scsi: qedi: Fix error codes in qedi_alloc_global_queues() [ Upstream commit 4dbe57d46d54a847875fa33e7d05877bb341585e ] This function had some left over code that returned 1 on error instead negative error codes. Convert everything to use negative error codes. The caller treats all non-zero returns the same so this does not affect run time. A couple places set "rc" instead of "status" so those error paths ended up returning success by mistake. Get rid of the "rc" variable and use "status" everywhere. Remove the bogus "status = 0" initialization, as a future proofing measure so the compiler will warn about uninitialized error codes. Link: https://lore.kernel.org/r/20210810084753.GD23810@kili Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 059a1256d394f62ddd40f638b713fc666c140ecf Author: Dan Carpenter Date: Tue Aug 10 11:46:13 2021 +0300 scsi: smartpqi: Fix an error code in pqi_get_raid_map() [ Upstream commit d1f6581a6796c4e9fd8a4a24e8b77463d18f0df1 ] Return -EINVAL on failure instead of success. Link: https://lore.kernel.org/r/20210810084613.GB23810@kili Fixes: a91aaae0243b ("scsi: smartpqi: allow for larger raid maps") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f989596e573c4280c7035c21deb082fb02202621 Author: Srinivas Pandruvada Date: Tue Jul 27 09:50:52 2021 -0700 platform/x86: ISST: Fix optimization with use of numa [ Upstream commit d36d4a1d75d2a8bd14ec00d5cb0ce166f6886146 ] When numa is used to map CPU to PCI device, the optimized path to read from cached data is not working and still calls _isst_if_get_pci_dev(). The reason is that when caching the mapping, numa information is not available as it is read later. So move the assignment of isst_cpu_info[cpu].numa_node before calling _isst_if_get_pci_dev(). Fixes: aa2ddd242572 ("platform/x86: ISST: Use numa node id for cpu pci dev mapping") Signed-off-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20210727165052.427238-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 983add470d43d68fa3712a4b46da3245428b0425 Author: Jason Gunthorpe Date: Thu Aug 5 22:18:58 2021 -0300 vfio/mbochs: Fix missing error unwind of mbochs_used_mbytes [ Upstream commit de5494af4815a4c9328536c72741229b7de88e7f ] Convert mbochs to use an atomic scheme for this like mtty was changed into. The atomic fixes various race conditions with probing. Add the missing error unwind. Also add the missing kfree of mdev_state->pages. Fixes: 681c1615f891 ("vfio/mbochs: Convert to use vfio_register_group_dev()") Reported-by: Cornelia Huck Co-developed-by: Alex Williamson Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/2-v4-9ea22c5e6afb+1adf-vfio_reflck_jgg@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 1a18fcbfc78bedd18d0958f09d9913bce756aebb Author: Laurent Dufour Date: Tue May 11 09:31:36 2021 +0200 powerpc/numa: Consider the max NUMA node for migratable LPAR [ Upstream commit 9c7248bb8de31f51c693bfa6a6ea53b1c07e0fa8 ] When a LPAR is migratable, we should consider the maximum possible NUMA node instead of the number of NUMA nodes from the actual system. The DT property 'ibm,current-associativity-domains' defines the maximum number of nodes the LPAR can see when running on that box. But if the LPAR is being migrated on another box, it may see up to the nodes defined by 'ibm,max-associativity-domains'. So if a LPAR is migratable, that value should be used. Unfortunately, there is no easy way to know if an LPAR is migratable or not. The hypervisor exports the property 'ibm,migratable-partition' in the case it set to migrate partition, but that would not mean that the current partition is migratable. Without this patch, when a LPAR is started on a 2 node box and then migrated to a 3 node box, the hypervisor may spread the LPAR's CPUs on the 3rd node. In that case if a CPU from that 3rd node is added to the LPAR, it will be wrongly assigned to the node because the kernel has been set to use up to 2 nodes (the configuration of the departure node). With this patch applies, the CPU is correctly added to the 3rd node. Fixes: f9f130ff2ec9 ("powerpc/numa: Detect support for coregroup") Signed-off-by: Laurent Dufour Reviewed-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210511073136.17795-1-ldufour@linux.ibm.com Signed-off-by: Sasha Levin commit aa3a9481e9a7c1ff49455e638aa9c8a6d555bbe7 Author: Zhen Lei Date: Thu Jul 22 11:39:29 2021 +0800 pinctrl: single: Fix error return code in pcs_parse_bits_in_pinctrl_entry() [ Upstream commit d789a490d32fdf0465275e3607f8a3bc87d3f3ba ] Fix to return -ENOTSUPP instead of 0 when PCS_HAS_PINCONF is true, which is the same as that returned in pcs_parse_pinconf(). Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Reported-by: Hulk Robot Signed-off-by: Zhen Lei Link: https://lore.kernel.org/r/20210722033930.4034-2-thunder.leizhen@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2bacac582e30453ec16e7c3923209f897c37958e Author: Wei Li Date: Thu Jul 15 11:26:25 2021 +0800 scsi: fdomain: Fix error return code in fdomain_probe() [ Upstream commit 632c4ae6da1d629eddf9da1e692d7617c568c256 ] If request_region() fails the return value is not set. Return -EBUSY on error. Link: https://lore.kernel.org/r/20210715032625.1395495-1-liwei391@huawei.com Fixes: 8674a8aa2c39 ("scsi: fdomain: Add PCMCIA support") Reported-by: Hulk Robot Signed-off-by: Wei Li Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0605632f395bdbec902b8e046ef641a6b1f9b980 Author: Adrian Hunter Date: Fri Aug 6 16:04:41 2021 +0300 scsi: ufshcd: Fix device links when BOOT WLUN fails to probe [ Upstream commit bf25967ac54129ffb676ee0dbe3b8b34af6c6232 ] Managed device links are deleted by device_del(). However it is possible to add a device link to a consumer before device_add(), and then discovering an error prevents the device from being used. In that case normally references to the device would be dropped and the device would be deleted. However the device link holds a reference to the device, so the device link and device remain indefinitely (unless the supplier is deleted). For UFSHCD, if a LUN fails to probe (e.g. absent BOOT WLUN), the device will not have been registered but can still have a device link holding a reference to the device. The unwanted device link will prevent runtime suspend indefinitely. Amend device link removal to accept removal of a link with an unregistered consumer device (suggested by Rafael), and fix UFSHCD by explicitly deleting the device link when SCSI destroys the SCSI device. Link: https://lore.kernel.org/r/a1c9bac8-b560-b662-f0aa-58c7e000cbbd@intel.com Fixes: b294ff3e3449 ("scsi: ufs: core: Enable power management for wlun") Reviewed-by: Rafael J. Wysocki Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9a756f6fc27278a7c45b2c3335f7e1d096df3b74 Author: Colin Ian King Date: Fri Aug 6 15:43:01 2021 +0100 scsi: ufs: Fix unsigned int compared with less than zero [ Upstream commit a5402cdcc2a925835db89ea336909b2b724189df ] Variable 'tag' is currently an unsigned int and is being compared to less than zero, this check is always false. Fix this by making 'tag' an int. Link: https://lore.kernel.org/r/20210806144301.19864-1-colin.king@canonical.com Fixes: 4728ab4a8e64 ("scsi: ufs: Remove ufshcd_valid_tag()") Reviewed-by: Bart Van Assche Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Addresses-Coverity: ("Macro compares unsigned to 0") Signed-off-by: Sasha Levin commit c13449c61f6ab0f8bb8e96c4bea66eb79909fd20 Author: Anna Schumaker Date: Tue Jul 20 16:04:42 2021 -0400 sunrpc: Fix return value of get_srcport() [ Upstream commit 5d46dd04cb68771f77ba66dbf6fd323a4a2ce00d ] Since bc1c56e9bbe9 transport->srcport may by unset, causing get_srcport() to return 0 when called. Fix this by querying the port from the underlying socket instead of the transport. Fixes: bc1c56e9bbe9 (SUNRPC: prevent port reuse on transports which don't request it) Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2d0538a8cbf992915e967b337957453b9f2b4433 Author: Trond Myklebust Date: Mon Jul 26 08:03:12 2021 -0400 SUNRPC/xprtrdma: Fix reconnection locking [ Upstream commit f99fa50880f5300fbbb3c0754ddc7f8738d24fe7 ] The xprtrdma client code currently relies on the task that initiated the connect to hold the XPRT_LOCK for the duration of the connection attempt. If the task is woken early, due to some other event, then that lock could get released early. Avoid races by using the same mechanism that the socket code uses of transferring lock ownership to the RDMA connect worker itself. That frees us to call rpcrdma_xprt_disconnect() directly since we're now guaranteed exclusion w.r.t. other callers. Fixes: 4cf44be6f1e8 ("xprtrdma: Fix recursion into rpcrdma_xprt_disconnect()") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit d88b41ba577a55c7735388a70794f539753cbfd7 Author: Trond Myklebust Date: Mon Jul 26 07:59:23 2021 -0400 SUNRPC: Fix potential memory corruption [ Upstream commit c2dc3e5fad13aca5d7bdf4bcb52b1a1d707c8555 ] We really should not call rpc_wake_up_queued_task_set_status() with xprt->snd_task as an argument unless we are certain that is actually an rpc_task. Fixes: 0445f92c5d53 ("SUNRPC: Fix disconnection races") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 2473a6afdcc7303aefeb7a81dc48ef5eda959286 Author: Trond Myklebust Date: Fri Jul 23 08:57:21 2021 -0400 NFSv4/pnfs: The layout barrier indicate a minimal value for the seqid [ Upstream commit d6236a98b3bab07c0a1455fd1ab46f79c3978cdc ] The intention of the layout barrier is to ensure that we do not update the layout to match an older value than the current expectation. Fix the test in pnfs_layout_stateid_blocked() to reflect that it is legal for the seqid of the stateid to match that of the barrier. Fixes: aa95edf309ef ("NFSv4/pnfs: Fix the layout barrier update") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit ffd9b424236aa86ce85942b93bbbc39d0e9d59bb Author: Trond Myklebust Date: Fri Jul 23 08:57:20 2021 -0400 NFSv4/pNFS: Always allow update of a zero valued layout barrier [ Upstream commit 45baadaad7bf9183651fb74f4ed1200da48505a5 ] A zero value for the layout barrier indicates that it has been cleared (since seqid '0' is an illegal value), so we should always allow it to be updated. Fixes: d29b468da4f9 ("pNFS/NFSv4: Improve rejection of out-of-order layouts") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 4df77d4eee49858fa6da8a9e59cca0e5dac34aa2 Author: Trond Myklebust Date: Mon Jul 26 07:58:49 2021 -0400 NFSv4/pNFS: Fix a layoutget livelock loop [ Upstream commit e20772cbdf463c12088837e5a08bde1b876bfd25 ] If NFS_LAYOUT_RETURN_REQUESTED is set, but there is no value set for the layout plh_return_seq, we can end up in a livelock loop in which every layout segment retrieved by a new call to layoutget is immediately invalidated by pnfs_layout_need_return(). To get around this, we should just set plh_return_seq to the current value of the layout stateid's seqid. Fixes: d474f96104bd ("NFS: Don't return layout segments that are in use") Signed-off-by: Trond Myklebust Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit f437f449efb8227314c9bb93f423699feec34686 Author: Chuck Lever Date: Mon Aug 2 14:44:24 2021 -0400 xprtrdma: Put rpcrdma_reps before waking the tear-down completion [ Upstream commit 97480cae13ca3a9c1de3eb6fd66cf9650a60db42 ] Ensure the tear-down completion is awoken only /after/ we've stopped fiddling with rpcrdma_rep objects in rpcrdma_post_recvs(). Fixes: 15788d1d1077 ("xprtrdma: Do not refresh Receive Queue while it is draining") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 7c0c5add1387dba745f12e61ced39d5a585e2ec0 Author: Anthony Iliopoulos Date: Thu Jul 22 16:10:55 2021 +0200 dma-debug: fix debugfs initialization order [ Upstream commit 173735c346c412d9f084825ecb04f24ada0e2986 ] Due to link order, dma_debug_init is called before debugfs has a chance to initialize (via debugfs_init which also happens in the core initcall stage), so the directories for dma-debug are never created. Decouple dma_debug_fs_init from dma_debug_init and defer its init until core_initcall_sync (after debugfs has been initialized) while letting dma-debug initialization occur as soon as possible to catch any early mappings, as suggested in [1]. [1] https://lore.kernel.org/linux-iommu/YIgGa6yF%2Fadg8OSN@kroah.com/ Fixes: 15b28bbcd567 ("dma-debug: move initialization to common code") Signed-off-by: Anthony Iliopoulos Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2ae478863098c13b5ad6aeac4b7ff7ddc258532c Author: Randy Dunlap Date: Sun Jul 18 19:33:09 2021 -0700 openrisc: don't printk() unconditionally [ Upstream commit 946e1052cdcc7e585ee5d1e72528ca49fb295243 ] Don't call printk() when CONFIG_PRINTK is not set. Fixes the following build errors: or1k-linux-ld: arch/openrisc/kernel/entry.o: in function `_external_irq_handler': (.text+0x804): undefined reference to `printk' (.text+0x804): relocation truncated to fit: R_OR1K_INSN_REL_26 against undefined symbol `printk' Fixes: 9d02a4283e9c ("OpenRISC: Boot code") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Cc: Jonas Bonn Cc: Stefan Kristiansson Cc: Stafford Horne Cc: openrisc@lists.librecores.org Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit df5b8687276a3b539911347e46438cdf8cf43787 Author: Yangtao Li Date: Wed Aug 4 11:29:46 2021 +0800 f2fs: reduce the scope of setting fsck tag when de->name_len is zero [ Upstream commit d4bf15a7ce172d186d400d606adf4f34a59130d6 ] I recently found a case where de->name_len is 0 in f2fs_fill_dentries() easily reproduced, and finally set the fsck flag. Thread A Thread B - f2fs_readdir - f2fs_read_inline_dir - ctx->pos = d.max - f2fs_add_dentry - f2fs_add_inline_entry - do_convert_inline_dir - f2fs_add_regular_entry - f2fs_readdir - f2fs_fill_dentries - set_sbi_flag(sbi, SBI_NEED_FSCK) Process A opens the folder, and has been reading without closing it. During this period, Process B created a file under the folder (occupying multiple f2fs_dir_entry, exceeding the d.max of the inline dir). After creation, process A uses the d.max of inline dir to read it again, and it will read that de->name_len is 0. And Chao pointed out that w/o inline conversion, the race condition still can happen as below: dir_entry1: A dir_entry2: B dir_entry3: C free slot: _ ctx->pos: ^ Thread A is traversing directory, ctx-pos moves to below position after readdir() by thread A: AAAABBBB___ ^ Then thread B delete dir_entry2, and create dir_entry3. Thread A calls readdir() to lookup dirents starting from middle of new dirent slots as below: AAAACCCCCC_ ^ In these scenarios, the file system is not damaged, and it's hard to avoid it. But we can bypass tagging FSCK flag if: a) bit_pos (:= ctx->pos % d->max) is non-zero and b) before bit_pos moves to first valid dir_entry. Fixes: ddf06b753a85 ("f2fs: fix to trigger fsck if dirent.name_len is zero") Signed-off-by: Yangtao Li [Chao: clean up description] Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 83c33419fd6ead40bea1b89f7ea4501e67b91b87 Author: Nathan Chancellor Date: Tue Aug 3 14:15:47 2021 -0700 cpuidle: pseries: Mark pseries_idle_proble() as __init [ Upstream commit d04691d373e75c83424b85c0e68e4a3f9370c10d ] After commit 7cbd631d4dec ("cpuidle: pseries: Fixup CEDE0 latency only for POWER10 onwards"), pseries_idle_probe() is no longer inlined when compiling with clang, which causes a modpost warning: WARNING: modpost: vmlinux.o(.text+0xc86a54): Section mismatch in reference from the function pseries_idle_probe() to the function .init.text:fixup_cede0_latency() The function pseries_idle_probe() references the function __init fixup_cede0_latency(). This is often because pseries_idle_probe lacks a __init annotation or the annotation of fixup_cede0_latency is wrong. pseries_idle_probe() is a non-init function, which calls fixup_cede0_latency(), which is an init function, explaining the mismatch. pseries_idle_probe() is only called from pseries_processor_idle_init(), which is an init function, so mark pseries_idle_probe() as __init so there is no more warning. Fixes: 054e44ba99ae ("cpuidle: pseries: Add function to parse extended CEDE records") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210803211547.1093820-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 8b45ec3afd12aaf167b6f1cd2ee5c42c882bcbee Author: Leon Romanovsky Date: Tue Aug 3 21:20:32 2021 +0300 RDMA/mlx5: Delete not-available udata check [ Upstream commit 5f6bb7e32283b8e3339b7adc00638234ac199cc4 ] XRC_TGT QPs are created through kernel verbs and don't have udata at all. Fixes: 6eefa839c4dd ("RDMA/mlx5: Protect from kernel crash if XRC_TGT doesn't have udata") Fixes: e383085c2425 ("RDMA/mlx5: Set ECE options during QP create") Link: https://lore.kernel.org/r/b68228597e730675020aa5162745390a2d39d3a2.1628014762.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a5d988387f4085d3bdbe18a9c5944bda91b043fd Author: Leon Romanovsky Date: Fri Jul 23 14:39:45 2021 +0300 RDMA/efa: Remove double QP type assignment [ Upstream commit f9193d266347fe9bed5c173e7a1bf96268142a79 ] The QP type is set by the IB/core and shouldn't be set in the driver. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Link: https://lore.kernel.org/r/838c40134c1590167b888ca06ad51071139ff2ae.1627040189.git.leonro@nvidia.com Acked-by: Gal Pressman Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 94de8d77901acc8b70595c4feb51e3b2cd34796a Author: Leon Romanovsky Date: Fri Jul 23 14:39:44 2021 +0300 RDMA/hns: Don't overwrite supplied QP attributes [ Upstream commit e66e49592b690d6abd537cc207b07a3db2f413d0 ] QP attributes that were supplied by IB/core already have all parameters set when they are passed to the driver. The drivers are not supposed to change anything in struct ib_qp_init_attr. Fixes: 66d86e529dd5 ("RDMA/hns: Add UD support for HIP09") Link: https://lore.kernel.org/r/5987138875e8ade9aa339d4db6e1bd9694ed4591.1627040189.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 97bd7d7101c8b7d937a26c3ac176bcd6028e4f0b Author: Michal Suchanek Date: Thu Jul 29 20:01:03 2021 +0200 powerpc/stacktrace: Include linux/delay.h [ Upstream commit a6cae77f1bc89368a4e2822afcddc45c3062d499 ] commit 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi()") introduces udelay() call without including the linux/delay.h header. This may happen to work on master but the header that declares the functionshould be included nonetheless. Fixes: 7c6986ade69e ("powerpc/stacktrace: Fix spurious "stale" traces in raise_backtrace_ipi()") Signed-off-by: Michal Suchanek Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210729180103.15578-1-msuchanek@suse.de Signed-off-by: Sasha Levin commit cd4e22a6e532328b6d1003d153c1c1a918b23755 Author: Gautham R. Shenoy Date: Mon Jul 19 12:03:18 2021 +0530 cpuidle: pseries: Fixup CEDE0 latency only for POWER10 onwards [ Upstream commit 50741b70b0cbbafbd9199f5180e66c0c53783a4a ] Commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for CEDE(0)") sets the exit latency of CEDE(0) based on the latency values of the Extended CEDE states advertised by the platform On POWER9 LPARs, the firmwares advertise a very low value of 2us for CEDE1 exit latency on a Dedicated LPAR. The latency advertized by the PHYP hypervisor corresponds to the latency required to wakeup from the underlying hardware idle state. However the wakeup latency from the LPAR perspective should include 1. The time taken to transition the CPU from the Hypervisor into the LPAR post wakeup from platform idle state 2. Time taken to send the IPI from the source CPU (waker) to the idle target CPU (wakee). 1. can be measured via timer idle test, where we queue a timer, say for 1ms, and enter the CEDE state. When the timer fires, in the timer handler we compute how much extra timer over the expected 1ms have we consumed. On a a POWER9 LPAR the numbers are CEDE latency measured using a timer (numbers in ns) N Min Median Avg 90%ile 99%ile Max Stddev 400 2601 5677 5668.74 5917 6413 9299 455.01 1. and 2. combined can be determined by an IPI latency test where we send an IPI to an idle CPU and in the handler compute the time difference between when the IPI was sent and when the handler ran. We see the following numbers on POWER9 LPAR. CEDE latency measured using an IPI (numbers in ns) N Min Median Avg 90%ile 99%ile Max Stddev 400 711 7564 7369.43 8559 9514 9698 1200.01 Suppose, we consider the 99th percentile latency value measured using the IPI to be the wakeup latency, the value would be 9.5us This is in the ballpark of the default value of 10us. Hence, use the exit latency of CEDE(0) based on the latency values advertized by platform only from POWER10 onwards. The values advertized on POWER10 platforms is more realistic and informed by the latency measurements. For earlier platforms stick to the default value of 10us. The fix was suggested by Michael Ellerman. Fixes: d947fb4c965c ("cpuidle: pseries: Fixup exit latency for CEDE(0)") Reported-by: Enrico Joedecke Signed-off-by: Gautham R. Shenoy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1626676399-15975-2-git-send-email-ego@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit a8e79dddb034808a0a63bbc7a6d4f6a129d73469 Author: Bart Van Assche Date: Wed Jul 21 20:34:35 2021 -0700 scsi: ufs: Fix the SCSI abort handler [ Upstream commit 64180742605f772d511903c9e50262afb13726c6 ] Make the following changes in ufshcd_abort(): - Return FAILED instead of SUCCESS if the abort handler notices that a SCSI command has already been completed. Returning SUCCESS in this case triggers a use-after-free and may trigger a kernel crash. - Fix the code for aborting SCSI commands submitted to a WLUN. The current approach for aborting SCSI commands that have been submitted to a WLUN and that timed out is as follows: - Report to the SCSI core that the command has completed successfully. Let the block layer free any data buffers associated with the command. - Mark the command as outstanding in 'outstanding_reqs'. - If the block layer tries to reuse the tag associated with the aborted command, busy-wait until the tag is freed. This approach can result in: - Memory corruption if the controller accesses the data buffer after the block layer has freed the associated data buffers. - A race condition if ufshcd_queuecommand() or ufshcd_exec_dev_cmd() checks the bit that corresponds to an aborted command in 'outstanding_reqs' after it has been cleared and before it is reset. - High energy consumption if ufshcd_queuecommand() repeatedly returns SCSI_MLQUEUE_HOST_BUSY. Fix this by reporting to the SCSI error handler that aborting a SCSI command failed if the SCSI command was submitted to a WLUN. Link: https://lore.kernel.org/r/20210722033439.26550-15-bvanassche@acm.org Fixes: 7a7e66c65d41 ("scsi: ufs: Fix a race condition between ufshcd_abort() and eh_work()") Cc: Adrian Hunter Cc: Stanley Chu Cc: Can Guo Cc: Asutosh Das Cc: Avri Altman Reviewed-by: Bean Huo Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fea7b28761cba0c637aab7a58a4f020dd3310c22 Author: Bart Van Assche Date: Wed Jul 21 20:34:26 2021 -0700 scsi: ufs: Use DECLARE_COMPLETION_ONSTACK() where appropriate [ Upstream commit 8a686f26eaa4b8a5c494b6b69e8a97815e3ffb82 ] From Documentation/scheduler/completion.rst: "When a completion is declared as a local variable within a function, then the initialization should always use DECLARE_COMPLETION_ONSTACK() explicitly, not just to make lockdep happy, but also to make it clear that limited scope had been considered and is intentional." Link: https://lore.kernel.org/r/20210722033439.26550-6-bvanassche@acm.org Cc: Adrian Hunter Cc: Stanley Chu Cc: Can Guo Cc: Asutosh Das Cc: Avri Altman Reviewed-by: Avri Altman Reviewed-by: Bean Huo Reviewed-by: Daejun Park Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 16a8236f884b2f134aad3889b0cb32ce54a19dfd Author: Bart Van Assche Date: Wed Jul 21 20:34:22 2021 -0700 scsi: ufs: Fix memory corruption by ufshcd_read_desc_param() [ Upstream commit d3d9c4570285090b533b00946b72647361f0345b ] If param_offset > buff_len then the memcpy() statement in ufshcd_read_desc_param() corrupts memory since it copies 256 + buff_len - param_offset bytes into a buffer with size buff_len. Since param_offset < 256 this results in writing past the bound of the output buffer. Link: https://lore.kernel.org/r/20210722033439.26550-2-bvanassche@acm.org Fixes: cbe193f6f093 ("scsi: ufs: Fix potential NULL pointer access during memcpy") Reviewed-by: Avri Altman Reviewed-by: Daejun Park Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 917123ad5149ec78b7cf195ca66ca24b5ad66961 Author: Jason Gunthorpe Date: Fri Jul 16 15:39:12 2021 -0300 vfio: Use config not menuconfig for VFIO_NOIOMMU [ Upstream commit 26c22cfde5dd6e63f25c48458b0185dcb0fbb2fd ] VFIO_NOIOMMU is supposed to be an element in the VFIO menu, not start a new menu. Correct this copy-paste mistake. Fixes: 03a76b60f8ba ("vfio: Include No-IOMMU mode") Signed-off-by: Jason Gunthorpe Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/0-v1-3f0b685c3679+478-vfio_menuconfig_jgg@nvidia.com Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit cb51b19afc8199bcbeddfe49887047a1bf2b94fd Author: Chao Yu Date: Thu Jul 29 09:22:17 2021 +0800 f2fs: fix wrong checkpoint_changed value in f2fs_remount() [ Upstream commit 277afbde6ca2b38729683fc17c031b4bc942068d ] In f2fs_remount(), return value of test_opt() is an unsigned int type variable, however when we compare it to a bool type variable, it cause wrong result, fix it. Fixes: 4354994f097d ("f2fs: checkpoint disabling") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0bf10835d94d5578b5e666819332a577b77b93db Author: Daeho Jeong Date: Wed Jul 28 12:38:11 2021 -0700 f2fs: turn back remapped address in compressed page endio [ Upstream commit 4931e0c93e124357308893a3e5e224cbeeabc721 ] Turned back the remmaped sector address to the address in the partition, when ending io, for compress cache to work properly. Fixes: 6ce19aff0b8c ("f2fs: compress: add compress_inode to cache compressed blocks") Signed-off-by: Daeho Jeong Signed-off-by: Youngjin Gil Signed-off-by: Hyeong Jun Kim Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 296bb8c3314b9de714ad0056ed1b9445f450cb83 Author: Jaegeuk Kim Date: Mon Jul 26 09:12:15 2021 -0700 f2fs: do not submit NEW_ADDR to read node block [ Upstream commit b7ec2061737f12c33e45beeb967d17f31abc1ada ] After the below patch, give cp is errored, we drop dirty node pages. This can give NEW_ADDR to read node pages. Don't do WARN_ON() which gives generic/475 failure. Fixes: 28607bf3aa6f ("f2fs: drop dirty node pages when cp is in error status") Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 2fb576caf06a23aa45299ee028cca856b4a0b25d Author: Jaehyoung Choi Date: Fri Jul 30 22:29:05 2021 +0300 pinctrl: samsung: Fix pinctrl bank pin count [ Upstream commit 70115558ab02fe8d28a6634350b3491a542aaa02 ] Commit 1abd18d1a51a ("pinctrl: samsung: Register pinctrl before GPIO") changes the order of GPIO and pinctrl registration: now pinctrl is registered before GPIO. That means gpio_chip->ngpio is not set when samsung_pinctrl_register() called, and one cannot rely on that value anymore. Use `pin_bank->nr_pins' instead of `pin_bank->gpio_chip.ngpio' to fix mentioned inconsistency. Fixes: 1abd18d1a51a ("pinctrl: samsung: Register pinctrl before GPIO") Signed-off-by: Jaehyoung Choi Signed-off-by: Sam Protsenko Link: https://lore.kernel.org/r/20210730192905.7173-1-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 2a99ea4c5bd76b30356cd9f578459e5f8da155ee Author: Colin Ian King Date: Fri Jul 30 10:50:31 2021 +0100 scsi: BusLogic: Use %X for u32 sized integer rather than %lX [ Upstream commit 2127cd21fb78c6e22d92944253afd967b0ff774d ] An earlier fix changed the print format specifier for adapter->bios_addr to use %lX. However, the integer is a u32 so the fix was wrong. Fix this by using the correct %X format specifier. Link: https://lore.kernel.org/r/20210730095031.26981-1-colin.king@canonical.com Fixes: 43622697117c ("scsi: BusLogic: use %lX for unsigned long rather than %X") Acked-by: Khalid Aziz Signed-off-by: Colin Ian King Signed-off-by: Martin K. Petersen Addresses-Coverity: ("Invalid type in argument") Signed-off-by: Sasha Levin commit fe2d5dde16e252fed7c6ae0d07fc2c80fcd9ff75 Author: Leon Romanovsky Date: Wed Jul 28 16:04:12 2021 +0300 docs: Fix infiniband uverbs minor number [ Upstream commit 8d7e415d55610d503fdb8815344846b72d194a40 ] Starting from the beginning of infiniband subsystem, the uverbs char devices start from 192 as a minor number, see commit bc38a6abdd5a ("[PATCH] IB uverbs: core implementation"). This patch updates the admin guide documentation to reflect it. Fixes: 9d85025b0418 ("docs-rst: create an user's manual book") Link: https://lore.kernel.org/r/bad03e6bcde45550c01e12908a6fe7dfa4770703.1627477347.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 3f03099476ae9f5ebfb3de32b31fe7b55fe9e525 Author: Leon Romanovsky Date: Fri Jul 23 17:08:55 2021 +0300 RDMA/iwcm: Release resources if iw_cm module initialization fails [ Upstream commit e677b72a0647249370f2635862bf0241c86f66ad ] The failure during iw_cm module initialization partially left the system with unreleased memory and other resources. Rewrite the module init/exit routines in such way that netlink commands will be opened only after successful initialization. Fixes: b493d91d333e ("iwcm: common code for port mapper") Link: https://lore.kernel.org/r/b01239f99cb1a3e6d2b0694c242d89e6410bcd93.1627048781.git.leonro@nvidia.com Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit da66440315869a6cf2df6057919078af14709f07 Author: Mike Marciniszyn Date: Thu Jul 15 12:04:45 2021 -0400 IB/hfi1: Adjust pkey entry in index 0 [ Upstream commit 62004871e1fa7f9a60797595c03477af5b5ec36f ] It is possible for the primary IPoIB network device associated with any RDMA device to fail to join certain multicast groups preventing IPv6 neighbor discovery and possibly other network ULPs from working correctly. The IPv4 broadcast group is not affected as the IPoIB network device handles joining that multicast group directly. This is because the primary IPoIB network device uses the pkey at ndex 0 in the associated RDMA device's pkey table. Anytime the pkey value of index 0 changes, the primary IPoIB network device automatically modifies it's broadcast address (i.e. /sys/class/net/[ib0]/broadcast), since the broadcast address includes the pkey value, and then bounces carrier. This includes initial pkey assignment, such as when the pkey at index 0 transitions from the opa default of invalid (0x0000) to some value such as the OPA default pkey for Virtual Fabric 0: 0x8001 or when the fabric manager is restarted with a configuration change causing the pkey at index 0 to change. Many network ULPs are not sensitive to the carrier bounce and are not expecting the broadcast address to change including the linux IPv6 stack. This problem does not affect IPoIB child network devices as their pkey value is constant for all time. To mitigate this issue, change the default pkey in at index 0 to 0x8001 to cover the predominant case and avoid issues as ipoib comes up and the FM sweeps. At some point, ipoib multicast support should automatically fix non-broadcast addresses as it does with the primary broadcast address. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210715160445.142451.47651.stgit@awfm-01.cornelisnetworks.com Suggested-by: Josh Collier Signed-off-by: Mike Marciniszyn Signed-off-by: Dennis Dalessandro Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f6ef418b5a1ace8b7396cd2503f89521f9fd2fca Author: Peter Geis Date: Wed Jul 28 14:00:28 2021 -0400 clk: rockchip: drop GRF dependency for rk3328/rk3036 pll types [ Upstream commit 6fffe52fb336ec2063270a7305652a93ea677ca1 ] The rk3036/rk3328 pll types were converted to checking the lock status via the internal register in january 2020, so don't need the grf reference since then. But it was forgotten to remove grf check when deciding between the pll rate ops (read-only vs. read-write), so a clock driver without the needed grf reference might've been put into the read-only mode just because the grf reference was missing. This affected the rk356x that needs to reclock certain plls at boot. Fix this by removing the check for the grf for selecting the utilized operations. Suggested-by: Heiko Stuebner Fixes: 7f6ffbb885d1 ("clk: rockchip: convert rk3036 pll type to use internal lock status") Signed-off-by: Peter Geis [adjusted the commit message, adjusted the fixes tag] Link: https://lore.kernel.org/r/20210728180034.717953-3-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 3239479ed420eb67538c8411342ae973df56e857 Author: Christoph Hellwig Date: Sat Jul 24 09:20:10 2021 +0200 scsi: bsg: Remove support for SCSI_IOCTL_SEND_COMMAND [ Upstream commit beec64d0c9749afedf51c3c10cf52de1d9a89cc0 ] SCSI_IOCTL_SEND_COMMAND has been deprecated longer than bsg exists and has been warning for just as long. More importantly it harcodes SCSI CDBs and thus will do the wrong thing on non-SCSI bsg nodes. Link: https://lore.kernel.org/r/20210724072033.1284840-2-hch@lst.de Fixes: aa387cc89567 ("block: add bsg helper library") Reviewed-by: Bart Van Assche Acked-by: Jens Axboe Signed-off-by: Christoph Hellwig Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 69b2123cc48e132c034c43849127435b0d9b7309 Author: Marek Behún Date: Mon Jul 19 13:29:38 2021 +0200 pinctrl: armada-37xx: Correct PWM pins definitions [ Upstream commit baf8d6899b1e8906dc076ef26cc633e96a8bb0c3 ] The PWM pins on North Bridge on Armada 37xx can be configured into PWM or GPIO functions. When in PWM function, each pin can also be configured to drive low on 0 and tri-state on 1 (LED mode). The current definitions handle this by declaring two pin groups for each pin: - group "pwmN" with functions "pwm" and "gpio" - group "ledN_od" ("od" for open drain) with functions "led" and "gpio" This is semantically incorrect. The correct definition for each pin should be one group with three functions: "pwm", "led" and "gpio". Change the "pwmN" groups to support "led" function. Remove "ledN_od" groups. This cannot break backwards compatibility with older device trees: no device tree uses it since there is no PWM driver for this SOC yet. Also "ledN_od" groups are not even documented. Fixes: b835d6953009 ("pinctrl: armada-37xx: swap polarity on LED group") Signed-off-by: Marek Behún Acked-by: Rob Herring Link: https://lore.kernel.org/r/20210719112938.27594-1-kabel@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 699a077aa087c17cf29c7170db71a34141e2effe Author: Chao Yu Date: Mon Jul 19 16:46:47 2021 +0800 f2fs: quota: fix potential deadlock [ Upstream commit 9de71ede81e6d1a111fdd868b2d78d459fa77f80 ] xfstest generic/587 reports a deadlock issue as below: ====================================================== WARNING: possible circular locking dependency detected 5.14.0-rc1 #69 Not tainted ------------------------------------------------------ repquota/8606 is trying to acquire lock: ffff888022ac9320 (&sb->s_type->i_mutex_key#18){+.+.}-{3:3}, at: f2fs_quota_sync+0x207/0x300 [f2fs] but task is already holding lock: ffff8880084bcde8 (&sbi->quota_sem){.+.+}-{3:3}, at: f2fs_quota_sync+0x59/0x300 [f2fs] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&sbi->quota_sem){.+.+}-{3:3}: __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_read+0x3b/0x2a0 f2fs_quota_sync+0x59/0x300 [f2fs] f2fs_quota_on+0x48/0x100 [f2fs] do_quotactl+0x5e3/0xb30 __x64_sys_quotactl+0x23a/0x4e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&sbi->cp_rwsem){++++}-{3:3}: __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_read+0x3b/0x2a0 f2fs_unlink+0x353/0x670 [f2fs] vfs_unlink+0x1c7/0x380 do_unlinkat+0x413/0x4b0 __x64_sys_unlinkat+0x50/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&sb->s_type->i_mutex_key#18){+.+.}-{3:3}: check_prev_add+0xdc/0xb30 validate_chain+0xa67/0xb20 __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_write+0x39/0xc0 f2fs_quota_sync+0x207/0x300 [f2fs] do_quotactl+0xaff/0xb30 __x64_sys_quotactl+0x23a/0x4e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &sb->s_type->i_mutex_key#18 --> &sbi->cp_rwsem --> &sbi->quota_sem Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sbi->quota_sem); lock(&sbi->cp_rwsem); lock(&sbi->quota_sem); lock(&sb->s_type->i_mutex_key#18); *** DEADLOCK *** 3 locks held by repquota/8606: #0: ffff88801efac0e0 (&type->s_umount_key#53){++++}-{3:3}, at: user_get_super+0xd9/0x190 #1: ffff8880084bc380 (&sbi->cp_rwsem){++++}-{3:3}, at: f2fs_quota_sync+0x3e/0x300 [f2fs] #2: ffff8880084bcde8 (&sbi->quota_sem){.+.+}-{3:3}, at: f2fs_quota_sync+0x59/0x300 [f2fs] stack backtrace: CPU: 6 PID: 8606 Comm: repquota Not tainted 5.14.0-rc1 #69 Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 Call Trace: dump_stack_lvl+0xce/0x134 dump_stack+0x17/0x20 print_circular_bug.isra.0.cold+0x239/0x253 check_noncircular+0x1be/0x1f0 check_prev_add+0xdc/0xb30 validate_chain+0xa67/0xb20 __lock_acquire+0x648/0x10b0 lock_acquire+0x128/0x470 down_write+0x39/0xc0 f2fs_quota_sync+0x207/0x300 [f2fs] do_quotactl+0xaff/0xb30 __x64_sys_quotactl+0x23a/0x4e0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f883b0b4efe The root cause is ABBA deadlock of inode lock and cp_rwsem, reorder locks in f2fs_quota_sync() as below to fix this issue: - lock inode - lock cp_rwsem - lock quota_sem Fixes: db6ec53b7e03 ("f2fs: add a rw_sem to cover quota flag changes") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ccb34d8dd6f42e0896605ff78934bda5067b093d Author: Lad Prabhakar Date: Thu Jun 17 16:54:32 2021 +0100 clk: renesas: rzg2l: Fix off-by-one check in rzg2l_cpg_clk_src_twocell_get() [ Upstream commit 1606e81543f80fc3b1912957cf6d8fa62e40b8e5 ] Fix clock index out of range check for module clocks in rzg2l_cpg_clk_src_twocell_get(). Fixes: ef3c613ccd68 ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Reported-by: Dan Carpenter Signed-off-by: Lad Prabhakar Link: https://lore.kernel.org/r/20210617155432.18827-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 73d06a2836f834b8ae64a30796a372dbbd111e5c Author: Dmitry Torokhov Date: Tue Jun 29 11:25:50 2021 -0700 HID: input: do not report stylus battery state as "full" [ Upstream commit f4abaa9eebde334045ed6ac4e564d050f1df3013 ] The power supply states of discharging, charging, full, etc, represent state of charging, not the capacity level of the battery (for which we have a separate property). Current HID usage tables to not allow for expressing charging state of the batteries found in generic styli, so we should simply assume that the battery is discharging even if current capacity is at 100% when battery strength reporting is done via HID interface. In fact, we were doing just that before commit 581c4484769e. This change helps UIs to not mis-represent fully charged batteries in styli as being charging/topping-off. Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Reported-by: Kenneth Albanowski Signed-off-by: Dmitry Torokhov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 3ab9e90b41554951de626012f72d2b6ed30e233d Author: Jack Wang Date: Mon Jul 12 08:07:50 2021 +0200 RDMA/rtrs: Move sq_wr_avail to rtrs_con [ Upstream commit cfcdbd9dd7632a9bb1e308a029f5fa65008333af ] In order to account HB for sq_wr_avail properly, move sq_wr_avail from rtrs_srv_con to rtrs_con. Although rtrs-clt do not care sq_wr_avail, but still init it to max_send_wr. Fixes: b38041d50add ("RDMA/rtrs: Do not signal for heatbeat") Link: https://lore.kernel.org/r/20210712060750.16494-7-jinpu.wang@ionos.com Signed-off-by: Jack Wang Reviewed-by: Aleksei Marov Reviewed-by: Gioh Kim Reviewed-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 35970e3f8a9f6e947ac4904ba4979b4cbbf98b34 Author: Jack Wang Date: Mon Jul 12 08:07:47 2021 +0200 RDMA/rtrs: Enable the same selective signal for heartbeat and IO [ Upstream commit e2d98504c697f9c8e45b815062f8893b10808d8e ] On idle session, because we do not do signal for heartbeat, it will overflow the send queue after sometime. To avoid that, we need to enable the signal for heartbeat. To do that, add a new member signal_interval in rtrs_path, which will set min of queue_depth and SERVICE_CON_QUEUE_DEPTH, and track it for both heartbeat and IO, so the sq queue full accounting is correct. Fixes: b38041d50add ("RDMA/rtrs: Do not signal for heatbeat") Link: https://lore.kernel.org/r/20210712060750.16494-4-jinpu.wang@ionos.com Signed-off-by: Jack Wang Reviewed-by: Aleksei Marov Reviewed-by: Gioh Kim Reviewed-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 33563b097c50ed87dc3aef157597d30b38df096b Author: Jack Wang Date: Mon Jul 12 08:07:46 2021 +0200 RDMA/rtrs: move wr_cnt from rtrs_srv_con to rtrs_con [ Upstream commit a10431eff136ef15e1f9955efe369744b1294db1 ] We need to track also the wr used for heatbeat. This is a preparation for that, will be used in later patch. The io_cnt in rtrs_clt is removed, use wr_cnt instead. Link: https://lore.kernel.org/r/20210712060750.16494-3-jinpu.wang@ionos.com Signed-off-by: Jack Wang Reviewed-by: Aleksei Marov Reviewed-by: Gioh Kim Reviewed-by: Md Haris Iqbal Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 723322cc59e60a419e58e97bdf413abd4d2f2500 Author: Chao Yu Date: Sat Jul 10 08:21:41 2021 +0800 f2fs: compress: fix to set zstd compress level correctly [ Upstream commit 01f6afd0f3ccaa2d5f7fb87e7bd910dc17eef06b ] As 5kft reported in [1]: set_compress_context() should set compress level into .i_compress_flag for zstd as well as lz4hc, otherwise, zstd compressor will still use default zstd compress level during compression, fix it. [1] https://lore.kernel.org/linux-f2fs-devel/8e29f52b-6b0d-45ec-9520-e63eb254287a@www.fastmail.com/T/#u Fixes: 3fde13f817e2 ("f2fs: compress: support compress level") Reported-by: 5kft <5kft@5kft.org> Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a8e88f238eb7017885ab9485fb70ba06e54d1070 Author: Pali Rohár Date: Fri Aug 20 17:50:20 2021 +0200 PCI: aardvark: Fix masking and unmasking legacy INTx interrupts commit d212dcee27c1f89517181047e5485fcbba4a25c2 upstream. irq_mask and irq_unmask callbacks need to be properly guarded by raw spin locks as masking/unmasking procedure needs atomic read-modify-write operation on hardware register. Link: https://lore.kernel.org/r/20210820155020.3000-1-pali@kernel.org Reported-by: Marc Zyngier Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Marc Zyngier Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit c9a1bf3d8f8b631b3042ae853d03ada590fbaee3 Author: Pali Rohár Date: Thu Jul 22 16:40:39 2021 +0200 PCI: aardvark: Increase polling delay to 1.5s while waiting for PIO response commit 02bcec3ea5591720114f586960490b04b093a09e upstream. Measurements in different conditions showed that aardvark hardware PIO response can take up to 1.44s. Increase wait timeout from 1ms to 1.5s to ensure that we do not miss responses from hardware. After 1.44s hardware returns errors (e.g. Completer abort). The previous two patches fixed checking for PIO status, so now we can use it to also catch errors which are reported by hardware after 1.44s. After applying this patch, kernel can detect and print PIO errors to dmesg: [ 6.879999] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100004 [ 6.896436] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 [ 6.913049] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100010 [ 6.929663] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100010 [ 6.953558] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100014 [ 6.970170] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100014 [ 6.994328] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 Without this patch kernel prints only a generic error to dmesg: [ 5.246847] advk-pcie d0070000.pcie: config read/write timed out Link: https://lore.kernel.org/r/20210722144041.12661-3-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock") Signed-off-by: Greg Kroah-Hartman commit 5d591df8b9d32ba6040aeefbd99a5b0d9f1436e0 Author: Evan Wang Date: Thu Jul 22 16:40:38 2021 +0200 PCI: aardvark: Fix checking for PIO status commit fcb461e2bc8b83b7eaca20cb2221e8b940f2189c upstream. There is an issue that when PCIe switch is connected to an Armada 3700 board, there will be lots of warnings about PIO errors when reading the config space. According to Aardvark PIO read and write sequence in HW specification, the current way to check PIO status has the following issues: 1) For PIO read operation, it reports the error message, which should be avoided according to HW specification. 2) For PIO read and write operations, it only checks PIO operation complete status, which is not enough, and error status should also be checked. This patch aligns the code with Aardvark PIO read and write sequence in HW specification on PIO status check and fix the warnings when reading config space. [pali: Fix CRS handling when CRSSVE is not enabled] Link: https://lore.kernel.org/r/20210722144041.12661-2-pali@kernel.org Tested-by: Victor Gu Signed-off-by: Evan Wang Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Reviewed-by: Victor Gu Reviewed-by: Marek Behún Cc: stable@vger.kernel.org # b1bd5714472c ("PCI: aardvark: Indicate error in 'val' when config read fails") Signed-off-by: Greg Kroah-Hartman commit b0ac1a8ebb8a7fa9be3c7d89266c039766688db5 Author: Pali Rohár Date: Thu Jun 24 23:55:45 2021 +0200 PCI: aardvark: Configure PCIe resources from 'ranges' DT property commit 64f160e19e9264a7f6d89c516baae1473b6f8359 upstream. In commit 6df6ba974a55 ("PCI: aardvark: Remove PCIe outbound window configuration") was removed aardvark PCIe outbound window configuration and commit description said that was recommended solution by HW designers. But that commit completely removed support for configuring PCIe IO resources without removing PCIe IO 'ranges' from DTS files. After that commit PCIe IO space started to be treated as PCIe MEM space and accessing it just caused kernel crash. Moreover implementation of PCIe outbound windows prior that commit was incorrect. It completely ignored offset between CPU address and PCIe bus address and expected that in DTS is CPU address always same as PCIe bus address without doing any checks. Also it completely ignored size of every PCIe resource specified in 'ranges' DTS property and expected that every PCIe resource has size 128 MB (also for PCIe IO range). Again without any check. Apparently none of PCIe resource has in DTS specified size of 128 MB. So it was completely broken and thanks to how aardvark mask works, configuration was completely ignored. This patch reverts back support for PCIe outbound window configuration but implementation is a new without issues mentioned above. PCIe outbound window is required when DTS specify in 'ranges' property non-zero offset between CPU and PCIe address space. To address recommendation by HW designers as specified in commit description of 6df6ba974a55, set default outbound parameters as PCIe MEM access without translation and therefore for this PCIe 'ranges' it is not needed to configure PCIe outbound window. For PCIe IO space is needed to configure aardvark PCIe outbound window. This patch fixes kernel crash when trying to access PCIe IO space. Link: https://lore.kernel.org/r/20210624215546.4015-2-pali@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # 6df6ba974a55 ("PCI: aardvark: Remove PCIe outbound window configuration") Signed-off-by: Greg Kroah-Hartman commit f66a07d2a6a112ba56d98684586cf7429a51cb14 Author: Hyun Kwon Date: Fri Jun 25 12:48:23 2021 +0200 PCI: xilinx-nwl: Enable the clock through CCF commit de0a01f5296651d3a539f2d23d0db8f359483696 upstream. Enable PCIe reference clock. There is no remove function that's why this should be enough for simple operation. Normally this clock is enabled by default by firmware but there are usecases where this clock should be enabled by driver itself. It is also good that PCIe clock is recorded in a clock framework. Link: https://lore.kernel.org/r/ee6997a08fab582b1c6de05f8be184f3fe8d5357.1624618100.git.michal.simek@xilinx.com Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") Signed-off-by: Hyun Kwon Signed-off-by: Bharat Kumar Gogada Signed-off-by: Michal Simek Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 84890308d1a082ff27dccc447a0650610140f01b Author: Krzysztof Wilczyński Date: Thu Jul 29 23:37:54 2021 +0000 PCI: Return ~0 data on pciconfig_read() CAP_SYS_ADMIN failure commit a8bd29bd49c4156ea0ec5a97812333e2aeef44e7 upstream. The pciconfig_read() syscall reads PCI configuration space using hardware-dependent config accessors. If the read fails on PCI, most accessors don't return an error; they pretend the read was successful and got ~0 data from the device, so the syscall returns success with ~0 data in the buffer. When the accessor does return an error, pciconfig_read() normally fills the user's buffer with ~0 and returns an error in errno. But after e4585da22ad0 ("pci syscall.c: Switch to refcounting API"), we don't fill the buffer with ~0 for the EPERM "user lacks CAP_SYS_ADMIN" error. Userspace may rely on the ~0 data to detect errors, but after e4585da22ad0, that would not detect CAP_SYS_ADMIN errors. Restore the original behaviour of filling the buffer with ~0 when the CAP_SYS_ADMIN check fails. [bhelgaas: commit log, fold in Nathan's fix https://lore.kernel.org/r/20210803200836.500658-1-nathan@kernel.org] Fixes: e4585da22ad0 ("pci syscall.c: Switch to refcounting API") Link: https://lore.kernel.org/r/20210729233755.1509616-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit d8922d605445456956dd642d90cb2b72a99551f7 Author: Marek Behún Date: Thu Jun 24 19:14:18 2021 +0200 PCI: Restrict ASMedia ASM1062 SATA Max Payload Size Supported commit b12d93e9958e028856cbcb061b6e64728ca07755 upstream. The ASMedia ASM1062 SATA controller advertises Max_Payload_Size_Supported of 512, but in fact it cannot handle incoming TLPs with payload size of 512. We discovered this issue on PCIe controllers capable of MPS = 512 (Aardvark and DesignWare), where the issue presents itself as an External Abort. Bjorn Helgaas says: Probably ASM1062 reports a Malformed TLP error when it receives a data payload of 512 bytes, and Aardvark, DesignWare, etc convert this to an arm64 External Abort. [1] To avoid this problem, limit the ASM1062 Max Payload Size Supported to 256 bytes, so we set the Max Payload Size of devices that may send TLPs to the ASM1062 to 256 or less. [1] https://lore.kernel.org/linux-pci/20210601170907.GA1949035@bjorn-Precision-5520/ BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212695 Link: https://lore.kernel.org/r/20210624171418.27194-2-kabel@kernel.org Reported-by: Rötti Signed-off-by: Marek Behún Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński Reviewed-by: Pali Rohár Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 027b66c1fc368d9c62f60632d1162c77548c8078 Author: Stuart Hayes Date: Thu May 13 03:03:14 2021 +0530 PCI/portdrv: Enable Bandwidth Notification only if port supports it commit 00823dcbdd415c868390feaca16f0265101efab4 upstream. Previously we assumed that all Root Ports and Switch Downstream Ports supported Link Bandwidth Notification. Per spec, this is only required for Ports supporting Links wider than x1 and/or multiple Link speeds (PCIe r5.0, sec 7.5.3.6). Because we assumed all Ports supported it, we tried to set up a Bandwidth Notification IRQ, which failed for devices that don't support IRQs at all, which meant pcieport didn't attach to the Port at all. Check the Link Bandwidth Notification Capability bit and enable the service only when the Port supports it. [bhelgaas: commit log] Fixes: e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") Link: https://lore.kernel.org/r/20210512213314.7778-1-stuart.w.hayes@gmail.com Signed-off-by: Stuart Hayes Signed-off-by: Bjorn Helgaas Reviewed-by: Lukas Wunner Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 99d73db77c6788eaff924e6817e6057830c782e7 Author: Chao Yu Date: Fri Aug 6 08:04:37 2021 +0800 f2fs: fix to do sanity check for sb/cp fields correctly commit 65ddf6564843890a58ee3b18bb46ce67d96333fb upstream. This patch fixes below problems of sb/cp sanity check: - in sanity_check_raw_superi(), it missed to consider log header blocks while cp_payload check. - in f2fs_sanity_check_ckpt(), it missed to check nat_bits_blocks. Cc: Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit be4c4ebb212b7098da1fe8bad675714b4d2ac35a Author: Jaegeuk Kim Date: Wed Jul 14 16:14:02 2021 -0700 f2fs: let's keep writing IOs on SBI_NEED_FSCK commit 1ffc8f5f7751f91fe6af527d426a723231b741a6 upstream. SBI_NEED_FSCK is an indicator that fsck.f2fs needs to be triggered, so it is not fully critical to stop any IO writes. So, let's allow to write data instead of reporting EIO forever given SBI_NEED_FSCK, but do keep OPU. Fixes: 955772787667 ("f2fs: drop inplace IO if fs status is abnormal") Cc: # v5.13+ Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 5b7992c06c54f76f71ff5fa0135a80bc41153689 Author: Thomas Gleixner Date: Sat Aug 28 15:55:52 2021 +0200 sched: Prevent balance_push() on remote runqueues commit 868ad33bfa3bf39960982682ad3a0f8ebda1656e upstream. sched_setscheduler() and rt_mutex_setprio() invoke the run-queue balance callback after changing priorities or the scheduling class of a task. The run-queue for which the callback is invoked can be local or remote. That's not a problem for the regular rq::push_work which is serialized with a busy flag in the run-queue struct, but for the balance_push() work which is only valid to be invoked on the outgoing CPU that's wrong. It not only triggers the debug warning, but also leaves the per CPU variable push_work unprotected, which can result in double enqueues on the stop machine list. Remove the warning and validate that the function is invoked on the outgoing CPU. Fixes: ae7927023243 ("sched: Optimize finish_lock_switch()") Reported-by: Sebastian Siewior Signed-off-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/87zgt1hdw7.ffs@tglx Signed-off-by: Greg Kroah-Hartman commit c541a5ef20aa9352c6d7cd9863bfb650293a5192 Author: David Heidelberg Date: Mon Aug 9 19:07:30 2021 +0100 ARM: 9105/1: atags_to_fdt: don't warn about stack size commit b30d0289de72c62516df03fdad8d53f552c69839 upstream. The merge_fdt_bootargs() function by definition consumes more than 1024 bytes of stack because it has a 1024 byte command line on the stack, meaning that we always get a warning when building this file: arch/arm/boot/compressed/atags_to_fdt.c: In function 'merge_fdt_bootargs': arch/arm/boot/compressed/atags_to_fdt.c:98:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=] However, as this is the decompressor and we know that it has a very shallow call chain, and we do not actually risk overflowing the kernel stack at runtime here. This just shuts up the warning by disabling the warning flag for this file. Tested on Nexus 7 2012 builds. Acked-by: Nicolas Pitre Signed-off-by: David Heidelberg Signed-off-by: Arnd Bergmann Cc: Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit 8197b03c757dc5ae7a7ce138926a599e9599b1e8 Author: Hans de Goede Date: Mon Aug 23 11:52:20 2021 +0200 libata: add ATA_HORKAGE_NO_NCQ_TRIM for Samsung 860 and 870 SSDs commit 8a6430ab9c9c87cb64c512e505e8690bbaee190b upstream. Commit ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860") limited the existing ATA_HORKAGE_NO_NCQ_TRIM quirk from "Samsung SSD 8*", covering all Samsung 800 series SSDs, to only apply to "Samsung SSD 840*" and "Samsung SSD 850*" series based on information from Samsung. But there is a large number of users which is still reporting issues with the Samsung 860 and 870 SSDs combined with Intel, ASmedia or Marvell SATA controllers and all reporters also report these problems going away when disabling queued trims. Note that with AMD SATA controllers users are reporting even worse issues and only completely disabling NCQ helps there, this will be addressed in a separate patch. Fixes: ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203475 Cc: stable@vger.kernel.org Cc: Kate Hsuan Signed-off-by: Hans de Goede Reviewed-by: Damien Le Moal Reviewed-by: Martin K. Petersen Link: https://lore.kernel.org/r/20210823095220.30157-1-hdegoede@redhat.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit c7dcbbd5d308ca7458e364fec5375e5d847299b4 Author: Jan Kiszka Date: Mon Jul 26 13:46:13 2021 +0200 watchdog: iTCO_wdt: Fix detection of SMI-off case commit aec42642d91fc86ddc03e97f0139c6c34ee6b6b1 upstream. Obviously, the test needs to run against the register content, not its address. Fixes: cb011044e34c ("watchdog: iTCO_wdt: Account for rebooting on second timeout") Cc: stable@vger.kernel.org Reported-by: Mantas Mikulėnas Signed-off-by: Jan Kiszka Reviewed-by: Paolo Bonzini Reviewed-by: Guenter Roeck Tested-by: Mantas Mikulėnas Link: https://lore.kernel.org/r/d84f8e06-f646-8b43-d063-fb11f4827044@siemens.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Greg Kroah-Hartman commit 6fd8bf64d8110c24e3fc6ae9c06ec4c519ed59d4 Author: Robin Gong Date: Wed Jul 14 18:20:44 2021 +0800 dmaengine: imx-sdma: remove duplicated sdma_load_context commit e555a03b112838883fdd8185d613c35d043732f2 upstream. Since sdma_transfer_init() will do sdma_load_context before any sdma transfer, no need once more in sdma_config_channel(). Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") Cc: Signed-off-by: Robin Gong Acked-by: Vinod Koul Tested-by: Richard Leitner Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit d08b80efc708fbdb1c8a39a218d4ec1e256e3eda Author: Robin Gong Date: Wed Jul 14 18:20:43 2021 +0800 Revert "dmaengine: imx-sdma: refine to load context only once" commit 8592f02464d52776c5cfae4627c6413b0ae7602d upstream. This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because in spi-imx case, burst length may be changed dynamically. Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") Cc: Signed-off-by: Robin Gong Acked-by: Sascha Hauer Tested-by: Richard Leitner Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 9e2b4385668d3b511bb0606ac97a741f29bc615f Author: Julian Wiedmann Date: Mon May 31 18:33:02 2021 +0300 s390/qdio: cancel the ESTABLISH ccw after timeout commit 1c1dc8bda3a05c60877a6649775894db5343bdea upstream. When the ESTABLISH ccw does not complete within the specified timeout, try our best to cancel the ccw program that is still active on the device. Otherwise the IO subsystem might be accessing it even after the driver eg. called qdio_free(). Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Cc: # 2.6.27 Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 693080b0d8e6337a08e4fcebb0674ea06a10f86b Author: Julian Wiedmann Date: Mon May 31 18:40:06 2021 +0300 s390/qdio: fix roll-back after timeout on ESTABLISH ccw commit 2c197870e4701610ec3b1143808d4e31152caf30 upstream. When qdio_establish() times out while waiting for the ESTABLISH ccw to complete, it calls qdio_shutdown() to roll back all of its previous actions. But at this point the qdio_irq's state is still QDIO_IRQ_STATE_INACTIVE, so qdio_shutdown() will exit immediately without doing any actual work. Which means that eg. the qdio_irq's thinint-indicator stays registered, and cdev->handler isn't restored to its old value. And since commit 954d6235be41 ("s390/qdio: make thinint registration symmetric") the qdio_irq also stays on the tiq_list, so on the next qdio_establish() we might get a helpful BUG from the list-debugging code: ... [ 4633.512591] list_add double add: new=00000000005a4110, prev=00000001b357db78, next=00000000005a4110. [ 4633.512621] ------------[ cut here ]------------ [ 4633.512623] kernel BUG at lib/list_debug.c:29! ... [ 4633.512796] [<00000001b2c6ee9a>] __list_add_valid+0x82/0xa0 [ 4633.512798] ([<00000001b2c6ee96>] __list_add_valid+0x7e/0xa0) [ 4633.512800] [<00000001b2fcecce>] qdio_establish_thinint+0x116/0x190 [ 4633.512805] [<00000001b2fcbe58>] qdio_establish+0x128/0x498 ... Fix this by extracting a goto-chain from the existing error exits in qdio_establish(), and check the return value of the wait_event_...() to detect the timeout condition. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Root-caused-by: Benjamin Block Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Cc: # 2.6.27 Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 63c2b13ba0428b8f477e4adb1d40a50eb4493c09 Author: Srinivas Kandagatla Date: Fri Aug 6 09:59:47 2021 +0100 nvmem: core: fix error handling while validating keepout regions commit de0534df93474f268486c486ea7e01b44a478026 upstream. Current error path on failure of validating keepout regions is calling put_device, eventhough the device is not even registered at that point. Fix this by adding proper error handling of freeing ida and nvmem. Fixes: fd3bb8f54a88 ("nvmem: core: Add support for keepout regions") Cc: Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210806085947.22682-5-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit d1562b7812d3253f2b252f20772240bf327cc97b Author: Sean Young Date: Sat Jul 3 15:37:17 2021 +0200 media: rc-loopback: return number of emitters rather than error commit 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 upstream. The LIRC_SET_TRANSMITTER_MASK ioctl should return the number of emitters if an invalid list was set. Cc: stable@vger.kernel.org Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 755e1f562bf78b62be3901ab9f23a101341469ba Author: Mauro Carvalho Chehab Date: Thu Jun 17 14:33:29 2021 +0200 media: uvc: don't do DMA on stack commit 1a10d7fdb6d0e235e9d230916244cc2769d3f170 upstream. As warned by smatch: drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i) drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i) those two functions call uvc_query_ctrl passing a pointer to a data at the DMA stack. those are used to send URBs via usb_control_msg(). Using DMA stack is not supported and should not work anymore on modern Linux versions. So, use a kmalloc'ed buffer. Cc: stable@vger.kernel.org # Kernel 4.9 and upper Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 46b096d6556769f9f4f1a127c53d01e75dc252fb Author: Wang Hai Date: Wed Aug 18 20:48:45 2021 +0800 VMCI: fix NULL pointer dereference when unmapping queue pair commit a30dc6cf0dc51419021550152e435736aaef8799 upstream. I got a NULL pointer dereference report when doing fuzz test: Call Trace: qp_release_pages+0xae/0x130 qp_host_unregister_user_memory.isra.25+0x2d/0x80 vmci_qp_broker_unmap+0x191/0x320 ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 vmci_host_unlocked_ioctl+0x59f/0xd50 ? do_vfs_ioctl+0x14b/0xa10 ? tomoyo_file_ioctl+0x28/0x30 ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 __x64_sys_ioctl+0xea/0x120 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae When a queue pair is created by the following call, it will not register the user memory if the page_store is NULL, and the entry->state will be set to VMCIQPB_CREATED_NO_MEM. vmci_host_unlocked_ioctl vmci_host_do_alloc_queuepair vmci_qp_broker_alloc qp_broker_alloc qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM; When unmapping this queue pair, qp_host_unregister_user_memory() will be called to unregister the non-existent user memory, which will result in a null pointer reference. It will also change VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be present in this operation. Only when the qp broker has mem, it can unregister the user memory when unmapping the qp broker. Only when the qp broker has no mem, it can register the user memory when mapping the qp broker. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Cc: stable Reported-by: Hulk Robot Reviewed-by: Jorgen Hansen Signed-off-by: Wang Hai Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com Signed-off-by: Greg Kroah-Hartman commit 15a4957f1ffb7a17d9c42007466757bc5888823f Author: Eddie James Date: Fri Jul 16 08:39:14 2021 -0500 spi: fsi: Reduce max transfer size to 8 bytes commit 34d34a56a5ea1e54a5af4f34c6ac9df724129351 upstream. Security changes have forced the SPI controllers to be limited to 8 byte reads. Refactor the sequencing to just handle 8 bytes at a time. Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20210716133915.14697-2-eajames@linux.ibm.com Signed-off-by: Mark Brown Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 9130f1733b16c3a9fcb63950298471fbce03cb3d Author: Brijesh Singh Date: Wed Jul 28 10:15:21 2021 -0500 crypto: ccp - shutdown SEV firmware on kexec commit 5441a07a127f106c9936e4f9fa1a8a93e3f31828 upstream. The commit 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the PSP driver") added support to allocate Trusted Memory Region (TMR) used during the SEV-ES firmware initialization. The TMR gets locked during the firmware initialization and unlocked during the shutdown. While the TMR is locked, access to it is disallowed. Currently, the CCP driver does not shutdown the firmware during the kexec reboot, leaving the TMR memory locked. Register a callback to shutdown the SEV firmware on the kexec boot. Fixes: 97f9ac3db6612 ("crypto: ccp - Add support for SEV-ES to the PSP driver") Reported-by: Lucas Nussbaum Tested-by: Lucas Nussbaum Cc: Cc: Tom Lendacky Cc: Joerg Roedel Cc: Herbert Xu Cc: David Rientjes Signed-off-by: Brijesh Singh Acked-by: Tom Lendacky Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit d09494a54240741ed62766a6b5919499e23c1067 Author: Arne Welzel Date: Sat Aug 14 00:40:38 2021 +0200 dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc() commit 528b16bfc3ae5f11638e71b3b63a81f9999df727 upstream. On systems with many cores using dm-crypt, heavy spinlock contention in percpu_counter_compare() can be observed when the page allocation limit for a given device is reached or close to be reached. This is due to percpu_counter_compare() taking a spinlock to compute an exact result on potentially many CPUs at the same time. Switch to non-exact comparison of allocated and allowed pages by using the value returned by percpu_counter_read_positive() to avoid taking the percpu_counter spinlock. This may over/under estimate the actual number of allocated pages by at most (batch-1) * num_online_cpus(). Currently, batch is bounded by 32. The system on which this issue was first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt allocations, this seems an acceptable error. Certainly preferred over running into the spinlock contention. This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs and 192GB RAM as follows, but can be provoked on systems with less CPUs as well. * Disable swap * Tune vm settings to promote regular writeback $ echo 50 > /proc/sys/vm/dirty_expire_centisecs $ echo 25 > /proc/sys/vm/dirty_writeback_centisecs $ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes * Create 8 dmcrypt devices based on files on a tmpfs * Create and mount an ext4 filesystem on each crypt devices * Run stress-ng --hdd 8 within one of above filesystems Total %system usage collected from sysstat goes to ~35%. Write throughput on the underlying loop device is ~2GB/s. perf profiling an individual kworker kcryptd thread shows the following profile, indicating spinlock contention in percpu_counter_compare(): 99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork | --ret_from_fork kthread worker_thread | --99.92%--process_one_work | |--80.52%--kcryptd_crypt | | | |--62.58%--mempool_alloc | | | | | --62.24%--crypt_page_alloc | | | | | --61.51%--__percpu_counter_compare | | | | | --61.34%--__percpu_counter_sum | | | | | |--58.68%--_raw_spin_lock_irqsave | | | | | | | --58.30%--native_queued_spin_lock_slowpath | | | | | --0.69%--cpumask_next | | | | | --0.51%--_find_next_bit | | | |--10.61%--crypt_convert | | | | | |--6.05%--xts_crypt ... After applying this patch and running the same test, %system usage is lowered to ~7% and write throughput on the loop device increases to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62% in the profile and not hitting the percpu_counter() spinlock anymore. |--8.15%--mempool_alloc | | | |--3.93%--crypt_page_alloc | | | | | --3.75%--__alloc_pages | | | | | --3.62%--get_page_from_freelist | | | | | --3.22%--rmqueue_bulk | | | | | --2.59%--_raw_spin_lock | | | | | --2.57%--native_queued_spin_lock_slowpath | | | --3.05%--_raw_spin_lock_irqsave | | | --2.49%--native_queued_spin_lock_slowpath Suggested-by: DJ Gregor Reviewed-by: Mikulas Patocka Signed-off-by: Arne Welzel Fixes: 5059353df86e ("dm crypt: limit the number of allocated pages") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit dad8da57294e1dce5eb24873968f8931ec77ab16 Author: Krzysztof Kozlowski Date: Mon Aug 16 10:27:14 2021 +0200 power: supply: max17042: handle fails of reading status register commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream. Reading status register can fail in the interrupt handler. In such case, the regmap_read() will not store anything useful under passed 'val' variable and random stack value will be used to determine type of interrupt. Handle the regmap_read() failure to avoid handling interrupt type and triggering changed power supply event based on random stack value. Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") Cc: Signed-off-by: Krzysztof Kozlowski Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit af7233fc7adf9b5e472ef63ca71e3e09c15811c7 Author: Damien Le Moal Date: Wed Aug 11 12:36:57 2021 +0900 block: bfq: fix bfq_set_next_ioprio_data() commit a680dd72ec336b81511e3bff48efac6dbfa563e7 upstream. For a request that has a priority level equal to or larger than IOPRIO_BE_NR, bfq_set_next_ioprio_data() prints a critical warning but defaults to setting the request new_ioprio field to IOPRIO_BE_NR. This is not consistent with the warning and the allowed values for priority levels. Fix this by setting the request new_ioprio field to IOPRIO_BE_NR - 1, the lowest priority level allowed. Cc: Fixes: aee69d78dec0 ("block, bfq: introduce the BFQ-v0 I/O scheduler as an extra scheduler") Signed-off-by: Damien Le Moal Reviewed-by: Hannes Reinecke Link: https://lore.kernel.org/r/20210811033702.368488-2-damien.lemoal@wdc.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9f211615a4a8c04c0d200eb6ad05d2c5d2518518 Author: zhenwei pi Date: Thu Aug 19 20:37:10 2021 +0800 crypto: public_key: fix overflow during implicit conversion commit f985911b7bc75d5c98ed24d8aaa8b94c590f7c6a upstream. Hit kernel warning like this, it can be reproduced by verifying 256 bytes datafile by keyctl command, run script: RAWDATA=rawdata SIGDATA=sigdata modprobe pkcs8_key_parser rm -rf *.der *.pem *.pfx rm -rf $RAWDATA dd if=/dev/random of=$RAWDATA bs=256 count=1 openssl req -nodes -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem \ -subj "/C=CN/ST=GD/L=SZ/O=vihoo/OU=dev/CN=xx.com/emailAddress=yy@xx.com" KEY_ID=`openssl pkcs8 -in key.pem -topk8 -nocrypt -outform DER | keyctl \ padd asymmetric 123 @s` keyctl pkey_sign $KEY_ID 0 $RAWDATA enc=pkcs1 hash=sha1 > $SIGDATA keyctl pkey_verify $KEY_ID 0 $RAWDATA $SIGDATA enc=pkcs1 hash=sha1 Then the kernel reports: WARNING: CPU: 5 PID: 344556 at crypto/rsa-pkcs1pad.c:540 pkcs1pad_verify+0x160/0x190 ... Call Trace: public_key_verify_signature+0x282/0x380 ? software_key_query+0x12d/0x180 ? keyctl_pkey_params_get+0xd6/0x130 asymmetric_key_verify_signature+0x66/0x80 keyctl_pkey_verify+0xa5/0x100 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae The reason of this issue, in function 'asymmetric_key_verify_signature': '.digest_size(u8) = params->in_len(u32)' leads overflow of an u8 value, so use u32 instead of u8 for digest_size field. And reorder struct public_key_signature, it saves 8 bytes on a 64-bit machine. Cc: stable@vger.kernel.org Signed-off-by: zhenwei pi Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit bcae38804b121204b5d3b3e710710de63238aa8e Author: Joseph Gates Date: Wed Aug 18 13:31:43 2021 +0200 wcn36xx: Ensure finish scan is not requested before start scan commit d195d7aac09bddabc2c8326fb02fcec2b0a2de02 upstream. If the operating channel is the first in the scan list, it was seen that a finish scan request would be sent before a start scan request was sent, causing the firmware to fail all future scans. Track the current channel being scanned to avoid requesting the scan finish before it starts. Cc: Fixes: 5973a2947430 ("wcn36xx: Fix software-driven scan") Signed-off-by: Joseph Gates Signed-off-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1629286303-13179-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman commit 9c1887c01642f2ff9eafdc61bf9ceb459567f4ed Author: Nuno Sá Date: Wed Aug 11 15:32:20 2021 +0200 iio: ltc2983: fix device probe commit b76d26d69ecc97ebb24aaf40427a13c808a4f488 upstream. There is no reason to assume that the IRQ rising edge (indicating that the device start up phase is done) will happen after we request the IRQ. If the device is already up by the time we request it, the call to 'wait_for_completion_timeout()' will timeout and we will fail the device probe even though there's nothing wrong. Fix it by just polling the status register until we get the indication that the device is up and running. As a side effect of this fix, requesting the IRQ is also moved to after the setup function. Fixes: f110f3188e563 ("iio: temperature: Add support for LTC2983") Reported-and-tested-by: Drew Fustini Reviewed-by: Drew Fustini Signed-off-by: Nuno Sá Reviewed-by: Andy Shevchenko Cc: Link: https://lore.kernel.org/r/20210811133220.190264-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e10e3a4b559fc5d8be88982d21d7f36c5feb144c Author: Alexandru Elisei Date: Tue Aug 24 16:45:23 2021 +0100 arm64: Do not trap PMSNEVFR_EL1 commit 50cb99fa89aa2bec2cab2f9917010bbd7769bfa3 upstream. Commit 31c00d2aeaa2 ("arm64: Disable fine grained traps on boot") zeroed the fine grained trap registers to prevent unwanted register traps from occuring. However, for the PMSNEVFR_EL1 register, the corresponding HDFG{R,W}TR_EL2.nPMSNEVFR_EL1 fields must be 1 to disable trapping. Set both fields to 1 if FEAT_SPEv1p2 is detected to disable read and write traps. Fixes: 31c00d2aeaa2 ("arm64: Disable fine grained traps on boot") Cc: # 5.13.x Signed-off-by: Alexandru Elisei Reviewed-by: Mark Brown Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20210824154523.906270-1-alexandru.elisei@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 842c949b1dad614b873569b968c115ef1137b4c7 Author: Mark Rutland Date: Mon Aug 23 11:12:53 2021 +0100 arm64: head: avoid over-mapping in map_memory commit 90268574a3e8a6b883bd802d702a2738577e1006 upstream. The `compute_indices` and `populate_entries` macros operate on inclusive bounds, and thus the `map_memory` macro which uses them also operates on inclusive bounds. We pass `_end` and `_idmap_text_end` to `map_memory`, but these are exclusive bounds, and if one of these is sufficiently aligned (as a result of kernel configuration, physical placement, and KASLR), then: * In `compute_indices`, the computed `iend` will be in the page/block *after* the final byte of the intended mapping. * In `populate_entries`, an unnecessary entry will be created at the end of each level of table. At the leaf level, this entry will map up to SWAPPER_BLOCK_SIZE bytes of physical addresses that we did not intend to map. As we may map up to SWAPPER_BLOCK_SIZE bytes more than intended, we may violate the boot protocol and map physical address past the 2MiB-aligned end address we are permitted to map. As we map these with Normal memory attributes, this may result in further problems depending on what these physical addresses correspond to. The final entry at each level may require an additional table at that level. As EARLY_ENTRIES() calculates an inclusive bound, we allocate enough memory for this. Avoid the extraneous mapping by having map_memory convert the exclusive end address to an inclusive end address by subtracting one, and do likewise in EARLY_ENTRIES() when calculating the number of required tables. For clarity, comments are updated to more clearly document which boundaries the macros operate on. For consistency with the other macros, the comments in map_memory are also updated to describe `vstart` and `vend` as virtual addresses. Fixes: 0370b31e4845 ("arm64: Extend early page table code to allow for larger kernels") Cc: # 4.16.x Signed-off-by: Mark Rutland Cc: Anshuman Khandual Cc: Ard Biesheuvel Cc: Steve Capper Cc: Will Deacon Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210823101253.55567-1-mark.rutland@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 68b085dfd90aa1c5562fb7b030546a7339b637c3 Author: Will Deacon Date: Fri Aug 6 12:31:04 2021 +0100 arm64: mm: Fix TLBI vs ASID rollover commit 5e10f9887ed85d4f59266d5c60dd09be96b5dbd4 upstream. When switching to an 'mm_struct' for the first time following an ASID rollover, a new ASID may be allocated and assigned to 'mm->context.id'. This reassignment can happen concurrently with other operations on the mm, such as unmapping pages and subsequently issuing TLB invalidation. Consequently, we need to ensure that (a) accesses to 'mm->context.id' are atomic and (b) all page-table updates made prior to a TLBI using the old ASID are guaranteed to be visible to CPUs running with the new ASID. This was found by inspection after reviewing the VMID changes from Shameer but it looks like a real (yet hard to hit) bug. Cc: Cc: Marc Zyngier Cc: Jade Alglave Cc: Shameer Kolothum Signed-off-by: Will Deacon Reviewed-by: Catalin Marinas Link: https://lore.kernel.org/r/20210806113109.2475-2-will@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 60b28d5fef35af5bbed556397483f03289818272 Author: Marc Zyngier Date: Mon Aug 2 13:38:29 2021 +0100 arm64: Move .hyp.rodata outside of the _sdata.._edata range commit eb48d154cd0dade56a0e244f0cfa198ea2925ed3 upstream. The HYP rodata section is currently lumped together with the BSS, which isn't exactly what is expected (it gets registered with kmemleak, for example). Move it away so that it is actually marked RO. As an added benefit, it isn't registered with kmemleak anymore. Fixes: 380e18ade4a5 ("KVM: arm64: Introduce a BSS section for use at Hyp") Suggested-by: Catalin Marinas Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org #5.13 Acked-by: Catalin Marinas Link: https://lore.kernel.org/r/20210802123830.2195174-2-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit f1d3bf0a3be7436122a825eb97491799ad949cb3 Author: Iwona Winiarska Date: Wed Aug 4 01:48:19 2021 +0200 soc: aspeed: p2a-ctrl: Fix boundary check for mmap commit 8b07e990fb254fcbaa919616ac77f981cb48c73d upstream. The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one side of the comparison, and uses resource address (rather than just the resource size) on the other side of the comparison. This can allow malicious userspace to easily bypass the boundary check and map pages that are located outside memory-region reserved by the driver. Fixes: 01c60dcea9f7 ("drivers/misc: Add Aspeed P2A control driver") Cc: stable@vger.kernel.org Signed-off-by: Iwona Winiarska Reviewed-by: Andrew Jeffery Tested-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman commit 865f5ba9fdfc3ac6acabcac9630056ce99db600d Author: Iwona Winiarska Date: Wed Aug 4 01:48:18 2021 +0200 soc: aspeed: lpc-ctrl: Fix boundary check for mmap commit b49a0e69a7b1a68c8d3f64097d06dabb770fec96 upstream. The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one side of the comparison, and uses resource address (rather than just the resource size) on the other side of the comparison. This can allow malicious userspace to easily bypass the boundary check and map pages that are located outside memory-region reserved by the driver. Fixes: 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver") Cc: stable@vger.kernel.org Signed-off-by: Iwona Winiarska Reviewed-by: Andrew Jeffery Tested-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Signed-off-by: Greg Kroah-Hartman commit 0279ca586636660bf4f728c4d4a1f187cdf68061 Author: Manivannan Sadhasivam Date: Tue Jun 29 21:02:49 2021 +0530 soc: qcom: aoss: Fix the out of bound usage of cooling_devs commit a89f355e469dcda129c2522be4fdba00c1c74c83 upstream. In "qmp_cooling_devices_register", the count value is initially QMP_NUM_COOLING_RESOURCES, which is 2. Based on the initial count value, the memory for cooling_devs is allocated. Then while calling the "qmp_cooling_device_add" function, count value is post-incremented for each child node. This makes the out of bound access to the cooling_dev array. Fix it by passing the QMP_NUM_COOLING_RESOURCES definition to devm_kzalloc() and initializing the count to 0. While at it, let's also free the memory allocated to cooling_dev if no cooling device is found in DT and during unroll phase. Cc: stable@vger.kernel.org # 5.4 Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210629153249.73428-1-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit ded5a35504367c1bdbd1d210ca0ba227352cec3d Author: Enric Balletbo i Serra Date: Fri Jun 25 08:24:48 2021 +0200 soc: mediatek: mmsys: Fix missing UFOE component in mt8173 table routing commit 25423731956b3d72bc35d336227c88ada49148e8 upstream. The UFOE (data compression engine) component needs to be enabled to have the imgtec gpu driver working. If we don't enable it we see a black screen. Looks like when we switched to use and array for setting the routing registers in commit 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") we missed to add this component in the new routing table, it was present before that commit, so fix it by adding this component in the mt8173 routing table. Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers") Signed-off-by: Enric Balletbo i Serra Tested-by: Eizan Miyamoto Cc: Link: https://lore.kernel.org/r/20210625062448.3462177-1-enric.balletbo@collabora.com [mb: taking into account mask value] Signed-off-by: Matthias Brugger Signed-off-by: Greg Kroah-Hartman commit bed22af765bdc9a0ce3e017fc5117ad25f944a31 Author: Paul Cercueil Date: Sat Jul 17 18:48:35 2021 +0100 pinctrl: ingenic: Fix bias config for X2000(E) commit 7261851e938f4b0fe8c0f5a8e627ae90e1ba9875 upstream. The ingenic_set_bias() function's "bias" argument is not a "enum pin_config_param", so its value should not be compared against values of that enum. This should fix the bias config not working on the X2000(E) SoCs. Fixes: 943e0da15370 ("pinctrl: Ingenic: Add pinctrl driver for X2000.") Cc: # v5.12 Signed-off-by: Paul Cercueil Tested-by: 周琰杰 (Zhou Yanjie) Link: https://lore.kernel.org/r/20210717174836.14776-2-paul@crapouillou.net Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit e6245d67fe2a4dfffb37f8d9cdd96ff3dc70db71 Author: Paul Cercueil Date: Sat Jul 17 18:48:34 2021 +0100 pinctrl: ingenic: Fix incorrect pull up/down info commit d5e931403942b3af39212960c2592b5ba741b2bf upstream. Fix the pull up/down info for both the JZ4760 and JZ4770 SoCs, as the previous values sometimes contradicted what's written in the programming manual. Fixes: b5c23aa46537 ("pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs") Cc: # v4.12 Signed-off-by: Paul Cercueil Tested-by: 周琰杰 (Zhou Yanjie) Link: https://lore.kernel.org/r/20210717174836.14776-1-paul@crapouillou.net Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 974ad30026fe6241c2d1f842627e0db8f8edb229 Author: Marc Zyngier Date: Sun Jul 25 19:08:30 2021 +0100 pinctrl: stmfx: Fix hazardous u8[] to unsigned long cast commit 1b73e588f47397dee6e4bdfd953e0306c60b5fe5 upstream. Casting a small array of u8 to an unsigned long is *never* OK: - it does funny thing when the array size is less than that of a long, as it accesses random places in the stack - it makes everything even more fun with a BE kernel Fix this by building the unsigned long used as a bitmap byte by byte, in a way that works across endianess and has no undefined behaviours. An extra BUILD_BUG_ON() catches the unlikely case where the array would be larger than a single unsigned long. Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver") Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Cc: Amelie Delaunay Cc: Linus Walleij Cc: Maxime Coquelin Cc: Alexandre Torgue Link: https://lore.kernel.org/r/20210725180830.250218-1-maz@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit bd9b334b730027b1fbedf2592c4c864ec9592104 Author: Dinh Nguyen Date: Tue Jul 13 09:46:21 2021 -0500 clk: socfpga: agilex: add the bypass register for s2f_usr0 clock commit d17929eb1066d1c1653aae9bb4396a9f1d6602ac upstream. Add the bypass register for the s2f_user0_clk. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Kris Chaplin Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210713144621.605140-3-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 421dc510a4f3b44b6a3168fbd56099174fc74b76 Author: Dinh Nguyen Date: Tue Jul 13 09:46:20 2021 -0500 clk: socfpga: agilex: fix up s2f_user0_clk representation commit f817c132db679d492d96c60993fa2f2c67ab18d0 upstream. Correct the s2f_user0_mux clock representation. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Kris Chaplin Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210713144621.605140-2-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 0e04782dbf989030784ca5c46a2225b09bffed7a Author: Dinh Nguyen Date: Tue Jul 13 09:46:19 2021 -0500 clk: socfpga: agilex: fix the parents of the psi_ref_clk commit 9d563236cca43fc4fe190b3be173444bd48e2a3b upstream. The psi_ref_clk comes from the C2 node of the main_pll and periph_pll, not the C3. Fixes: 80c6b7a0894f ("clk: socfpga: agilex: add clock driver for the Agilex platform") Cc: stable@vger.kernel.org Signed-off-by: Kris Chaplin Signed-off-by: Dinh Nguyen Link: https://lore.kernel.org/r/20210713144621.605140-1-dinguyen@kernel.org Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman commit 04221348d22daf072e1b7f86d59bcac88a6404df Author: Rolf Eike Beer Date: Fri Jul 30 13:51:54 2021 +0200 tools/thermal/tmon: Add cross compiling support commit b5f7912bb604b47a0fe024560488a7556dce8ee7 upstream. Default to prefixed pkg-config when crosscompiling, this matches what other parts of the tools/ directory already do. [dlezcano] : Reworked description Signed-off-by: Rolf Eike Beer Cc: stable@vger.kernel.org Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/31302992.qZodDJZGDc@devpool47 Signed-off-by: Greg Kroah-Hartman commit 7ad68ccdecabc1fd00289070ecce54366ed1df85 Author: Steven Rostedt (VMware) Date: Fri Aug 20 16:46:47 2021 -0400 selftests/ftrace: Fix requirement check of README file commit 210f9df02611cbe641ced3239122b270fd907d86 upstream. The selftest for ftrace checks some features by checking if the README has text that states the feature is supported by that kernel. Unfortunately, this check gives false positives because it many not be checked if there's spaces in the string to check. This is due to the compare between the required variable with the ":README" string stripped, because neither has quotes around them. Link: https://lkml.kernel.org/r/20210820204742.087177341@goodmis.org Cc: "Tzvetomir Stoyanov" Cc: Tom Zanussi Cc: Shuah Khan Cc: Shuah Khan Cc: linux-kselftest@vger.kernel.org Cc: stable@vger.kernel.org Fixes: 1b8eec510ba64 ("selftests/ftrace: Support ":README" suffix for requires") Acked-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit a9607572b0a2e1eec1a841d1a83fd7791c28ad2f Author: jingle.wu Date: Mon Sep 6 21:52:05 2021 -0700 Input: elan_i2c - reduce the resume time for controller in Whitebox commit d198b8273e3006818ea287a93eb4d8fd2543e512 upstream. Similar to controllers found Voxel, Delbin, Magpie and Bobba, the one found in Whitebox does not need to be reset after issuing power-on command, and skipping reset saves resume time. Signed-off-by: Jingle Wu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210907012924.11391-1-jingle.wu@emc.com.tw Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit bf3f35dd1db664d3ebd6d23786051c315b13e85b Author: Colin Ian King Date: Sun Aug 29 19:18:24 2021 +0100 ceph: fix dereference of null pointer cf commit 05a444d3f90a3c3e6362e88a1bf13e1a60f8cace upstream. Currently in the case where kmem_cache_alloc fails the null pointer cf is dereferenced when assigning cf->is_capsnap = false. Fix this by adding a null pointer check and return path. Cc: stable@vger.kernel.org Addresses-Coverity: ("Dereference null return") Fixes: b2f9fa1f3bd8 ("ceph: correctly handle releasing an embedded cap flush") Signed-off-by: Colin Ian King Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Greg Kroah-Hartman commit b867838e927232fc37f35b753f03ba888ef14fc5 Author: Harshvardhan Jha Date: Tue Jul 27 05:37:10 2021 +0530 9p/xen: Fix end of loop tests for list_for_each_entry commit 732b33d0dbf17e9483f0b50385bf606f724f50a2 upstream. This patch addresses the following problems: - priv can never be NULL, so this part of the check is useless - if the loop ran through the whole list, priv->client is invalid and it is more appropriate and sufficient to check for the end of list_for_each_entry loop condition. Link: http://lkml.kernel.org/r/20210727000709.225032-1-harshvardhan.jha@oracle.com Signed-off-by: Harshvardhan Jha Reviewed-by: Stefano Stabellini Tested-by: Stefano Stabellini Cc: Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit a7eaeb8530840dba4f955cd92ddb4400ff7bc5af Author: Juergen Gross Date: Fri Jul 30 11:26:21 2021 +0200 xen: fix setting of max_pfn in shared_info commit 4b511d5bfa74b1926daefd1694205c7f1bcf677f upstream. Xen PV guests are specifying the highest used PFN via the max_pfn field in shared_info. This value is used by the Xen tools when saving or migrating the guest. Unfortunately this field is misnamed, as in reality it is specifying the number of pages (including any memory holes) of the guest, so it is the highest used PFN + 1. Renaming isn't possible, as this is a public Xen hypervisor interface which needs to be kept stable. The kernel will set the value correctly initially at boot time, but when adding more pages (e.g. due to memory hotplug or ballooning) a real PFN number is stored in max_pfn. This is done when expanding the p2m array, and the PFN stored there is even possibly wrong, as it should be the last possible PFN of the just added P2M frame, and not one which led to the P2M expansion. Fix that by setting shared_info->max_pfn to the last possible PFN + 1. Fixes: 98dd166ea3a3c3 ("x86/xen/p2m: hint at the last populated P2M entry") Cc: stable@vger.kernel.org Signed-off-by: Juergen Gross Reviewed-by: Jan Beulich Link: https://lore.kernel.org/r/20210730092622.9973-2-jgross@suse.com Signed-off-by: Juergen Gross Signed-off-by: Greg Kroah-Hartman commit d79cb9f57f5713c100e6ff1b6e94292ebbc41b2d Author: Kajol Jain Date: Fri Aug 13 13:51:58 2021 +0530 powerpc/perf/hv-gpci: Fix counter value parsing commit f9addd85fbfacf0d155e83dbee8696d6df5ed0c7 upstream. H_GetPerformanceCounterInfo (0xF080) hcall returns the counter data in the result buffer. Result buffer has specific format defined in the PAPR specification. One of the fields is counter offset and width of the counter data returned. Counter data are returned in a unsigned char array in big endian byte order. To get the final counter data, the values must be left shifted byte at a time. But commit 220a0c609ad17 ("powerpc/perf: Add support for the hv gpci (get performance counter info) interface") made the shifting bitwise and also assumed little endian order. Because of that, hcall counters values are reported incorrectly. In particular this can lead to counters go backwards which messes up the counter prev vs now calculation and leads to huge counter value reporting: #: perf stat -e hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ -C 0 -I 1000 time counts unit events 1.000078854 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 2.000213293 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 3.000320107 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 4.000428392 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 5.000537864 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 6.000649087 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 7.000760312 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 8.000865218 16,448 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 9.000978985 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 10.001088891 16,384 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 11.001201435 0 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ 12.001307937 18,446,744,073,709,535,232 hv_gpci/system_tlbie_count_and_time_tlbie_instructions_issued/ Fix the shifting logic to correct match the format, ie. read bytes in big endian order. Fixes: e4f226b1580b ("powerpc/perf/hv-gpci: Increase request buffer size") Cc: stable@vger.kernel.org # v4.6+ Reported-by: Nageswara R Sastry Signed-off-by: Kajol Jain Tested-by: Nageswara R Sastry Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210813082158.429023-1-kjain@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit f54840dc953973250a716cb49c63c18884670929 Author: Niklas Cassel Date: Wed Aug 11 11:05:19 2021 +0000 blk-zoned: allow BLKREPORTZONE without CAP_SYS_ADMIN commit 4d643b66089591b4769bcdb6fd1bfeff2fe301b8 upstream. A user space process should not need the CAP_SYS_ADMIN capability set in order to perform a BLKREPORTZONE ioctl. Getting the zone report is required in order to get the write pointer. Neither read() nor write() requires CAP_SYS_ADMIN, so it is reasonable that a user space process that can read/write from/to the device, also can get the write pointer. (Since e.g. writes have to be at the write pointer.) Fixes: 3ed05a987e0f ("blk-zoned: implement ioctls") Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Reviewed-by: Aravind Ramesh Reviewed-by: Adam Manzanares Reviewed-by: Himanshu Madhani Reviewed-by: Johannes Thumshirn Cc: stable@vger.kernel.org # v4.10+ Link: https://lore.kernel.org/r/20210811110505.29649-3-Niklas.Cassel@wdc.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 51c12f18ccfc56732345c218bfdf72e4b60a4272 Author: Niklas Cassel Date: Wed Aug 11 11:05:18 2021 +0000 blk-zoned: allow zone management send operations without CAP_SYS_ADMIN commit ead3b768bb51259e3a5f2287ff5fc9041eb6f450 upstream. Zone management send operations (BLKRESETZONE, BLKOPENZONE, BLKCLOSEZONE and BLKFINISHZONE) should be allowed under the same permissions as write(). (write() does not require CAP_SYS_ADMIN). Additionally, other ioctls like BLKSECDISCARD and BLKZEROOUT only check if the fd was successfully opened with FMODE_WRITE. (They do not require CAP_SYS_ADMIN). Currently, zone management send operations require both CAP_SYS_ADMIN and that the fd was successfully opened with FMODE_WRITE. Remove the CAP_SYS_ADMIN requirement, so that zone management send operations match the access control requirement of write(), BLKSECDISCARD and BLKZEROOUT. Fixes: 3ed05a987e0f ("blk-zoned: implement ioctls") Signed-off-by: Niklas Cassel Reviewed-by: Damien Le Moal Reviewed-by: Aravind Ramesh Reviewed-by: Adam Manzanares Reviewed-by: Himanshu Madhani Reviewed-by: Johannes Thumshirn Cc: stable@vger.kernel.org # v4.10+ Link: https://lore.kernel.org/r/20210811110505.29649-2-Niklas.Cassel@wdc.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0ec2a3e951c7088723075a31c1bbbadc96b1b80d Author: Naohiro Aota Date: Tue Sep 7 00:04:28 2021 +0900 btrfs: zoned: fix double counting of split ordered extent commit f79645df806565a03abb2847a1d20e6930b25e7e upstream. btrfs_add_ordered_extent_*() add num_bytes to fs_info->ordered_bytes. Then, splitting an ordered extent will call btrfs_add_ordered_extent_*() again for split extents, leading to double counting of the region of a split extent. These leaked bytes are finally reported at unmount time as follow: BTRFS info (device dm-1): at unmount dio bytes count 364544 Fix the double counting by subtracting split extent's size from fs_info->ordered_bytes. Fixes: d22002fd37bd ("btrfs: zoned: split ordered extent when bio is sent") CC: stable@vger.kernel.org # 5.12+ Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 7c27e0edc902cddad496af1fb4f7ec979d447060 Author: Desmond Cheong Zhi Xi Date: Sat Aug 21 01:50:40 2021 +0800 btrfs: reset replace target device to allocation state on close commit 0d977e0eba234e01a60bdde27314dc21374201b3 upstream. This crash was observed with a failed assertion on device close: BTRFS: Transaction aborted (error -28) WARNING: CPU: 1 PID: 3902 at fs/btrfs/extent-tree.c:2150 btrfs_run_delayed_refs+0x1d2/0x1e0 [btrfs] Modules linked in: btrfs blake2b_generic libcrc32c crc32c_intel xor zstd_decompress zstd_compress xxhash lzo_compress lzo_decompress raid6_pq loop CPU: 1 PID: 3902 Comm: kworker/u8:4 Not tainted 5.14.0-rc5-default+ #1532 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs] RIP: 0010:btrfs_run_delayed_refs+0x1d2/0x1e0 [btrfs] RSP: 0018:ffffb7a5452d7d80 EFLAGS: 00010282 RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffffabee13c4 RDI: 00000000ffffffff RBP: ffff97834176a378 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: ffff97835195d388 R13: 0000000005b08000 R14: ffff978385484000 R15: 000000000000016c FS: 0000000000000000(0000) GS:ffff9783bd800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056190d003fe8 CR3: 000000002a81e005 CR4: 0000000000170ea0 Call Trace: flush_space+0x197/0x2f0 [btrfs] btrfs_async_reclaim_metadata_space+0x139/0x300 [btrfs] process_one_work+0x262/0x5e0 worker_thread+0x4c/0x320 ? process_one_work+0x5e0/0x5e0 kthread+0x144/0x170 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x1f/0x30 irq event stamp: 19334989 hardirqs last enabled at (19334997): [] console_unlock+0x2b7/0x400 hardirqs last disabled at (19335006): [] console_unlock+0x33d/0x400 softirqs last enabled at (19334900): [] __do_softirq+0x30d/0x574 softirqs last disabled at (19334893): [] irq_exit_rcu+0x12c/0x140 ---[ end trace 45939e308e0dd3c7 ]--- BTRFS: error (device vdd) in btrfs_run_delayed_refs:2150: errno=-28 No space left BTRFS info (device vdd): forced readonly BTRFS warning (device vdd): failed setting block group ro: -30 BTRFS info (device vdd): suspending dev_replace for unmount assertion failed: !test_bit(BTRFS_DEV_STATE_REPLACE_TGT, &device->dev_state), in fs/btrfs/volumes.c:1150 ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.h:3431! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 3982 Comm: umount Tainted: G W 5.14.0-rc5-default+ #1532 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba527-rebuilt.opensuse.org 04/01/2014 RIP: 0010:assertfail.constprop.0+0x18/0x1a [btrfs] RSP: 0018:ffffb7a5454c7db8 EFLAGS: 00010246 RAX: 0000000000000068 RBX: ffff978364b91c00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffffabee13c4 RDI: 00000000ffffffff RBP: ffff9783523a4c00 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: ffff9783523a4d18 R13: 0000000000000000 R14: 0000000000000004 R15: 0000000000000003 FS: 00007f61c8f42800(0000) GS:ffff9783bd800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000056190cffa810 CR3: 0000000030b96002 CR4: 0000000000170ea0 Call Trace: btrfs_close_one_device.cold+0x11/0x55 [btrfs] close_fs_devices+0x44/0xb0 [btrfs] btrfs_close_devices+0x48/0x160 [btrfs] generic_shutdown_super+0x69/0x100 kill_anon_super+0x14/0x30 btrfs_kill_super+0x12/0x20 [btrfs] deactivate_locked_super+0x2c/0xa0 cleanup_mnt+0x144/0x1b0 task_work_run+0x59/0xa0 exit_to_user_mode_loop+0xe7/0xf0 exit_to_user_mode_prepare+0xaf/0xf0 syscall_exit_to_user_mode+0x19/0x50 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae This happens when close_ctree is called while a dev_replace hasn't completed. In close_ctree, we suspend the dev_replace, but keep the replace target around so that we can resume the dev_replace procedure when we mount the root again. This is the call trace: close_ctree(): btrfs_dev_replace_suspend_for_unmount(); btrfs_close_devices(): btrfs_close_fs_devices(): btrfs_close_one_device(): ASSERT(!test_bit(BTRFS_DEV_STATE_REPLACE_TGT, &device->dev_state)); However, since the replace target sticks around, there is a device with BTRFS_DEV_STATE_REPLACE_TGT set on close, and we fail the assertion in btrfs_close_one_device. To fix this, if we come across the replace target device when closing, we should properly reset it back to allocation state. This fix also ensures that if a non-target device has a corrupted state and has the BTRFS_DEV_STATE_REPLACE_TGT bit set, the assertion will still catch the error. Reported-by: David Sterba Fixes: b2a616676839 ("btrfs: fix rw device counting in __btrfs_free_extra_devids") CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Anand Jain Signed-off-by: Desmond Cheong Zhi Xi Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c1016cdf532253fe51c716c567b3fbcae3d46df2 Author: Anand Jain Date: Tue Aug 10 23:23:44 2021 +0800 btrfs: fix upper limit for max_inline for page size 64K commit 6f93e834fa7c5faa0372e46828b4b2a966ac61d7 upstream. The mount option max_inline ranges from 0 to the sectorsize (which is now equal to page size). But we parse the mount options too early and before the actual sectorsize is read from the superblock. So the upper limit of max_inline is unaware of the actual sectorsize and is limited by the temporary sectorsize 4096, even on a system where the default sectorsize is 64K. Fix this by reading the superblock sectorsize before the mount option parse. Reported-by: Alexander Tsvetkov CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 12f098466a08bd5f28ad38b7f947f3049fcfad2a Author: Naohiro Aota Date: Mon Aug 9 13:32:30 2021 +0900 btrfs: zoned: suppress reclaim error message on EAGAIN commit ba86dd9fe60e5853fbff96f2658212908b83f271 upstream. btrfs_relocate_chunk() can fail with -EAGAIN when e.g. send operations are running. The message can fail btrfs/187 and it's unnecessary because we anyway add it back to the reclaim list. btrfs_reclaim_bgs_work() `-> btrfs_relocate_chunk() `-> btrfs_relocate_block_group() `-> reloc_chunk_start() `-> if (fs_info->send_in_progress) `-> return -EAGAIN CC: stable@vger.kernel.org # 5.13+ Fixes: 18bb8bbf13c1 ("btrfs: zoned: automatically reclaim zones") Reviewed-by: Johannes Thumshirn Signed-off-by: Naohiro Aota Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 2a9f99a28716ee71dbfafe20aa1f09df12622810 Author: Naohiro Aota Date: Mon Aug 9 13:13:44 2021 +0900 btrfs: zoned: fix block group alloc_offset calculation commit 0ae79c6fe70d5c5c645733b7ed39d5e6021d8c9a upstream. alloc_offset is offset from the start of a block group and @offset is actually an address in logical space. Thus, we need to consider block_group->start when calculating them. Fixes: 011b41bffa3d ("btrfs: zoned: advance allocation pointer after tree log node") CC: stable@vger.kernel.org # 5.12+ Signed-off-by: Naohiro Aota Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 802a090d51531daee9f4367f5864787c788829fa Author: Josef Bacik Date: Wed Aug 11 14:37:16 2021 -0400 btrfs: do not do preemptive flushing if the majority is global rsv commit 114623979405abf0b143f9c6688b3ff00ee48338 upstream. A common characteristic of the bug report where preemptive flushing was going full tilt was the fact that the vast majority of the free metadata space was used up by the global reserve. The hard 90% threshold would cover the majority of these cases, but to be even smarter we should take into account how much of the outstanding reservations are covered by the global block reserve. If the global block reserve accounts for the vast majority of outstanding reservations, skip preemptive flushing, as it will likely just cause churn and pain. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212185 Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit d441fe45f1197d23fb399b84563728269ccdaee5 Author: Josef Bacik Date: Wed Aug 11 14:37:15 2021 -0400 btrfs: reduce the preemptive flushing threshold to 90% commit 93c60b17f2b5fca2c5931d7944788d1ef5f25528 upstream. The preemptive flushing code was added in order to avoid needing to synchronously wait for ENOSPC flushing to recover space. Once we're almost full however we can essentially flush constantly. We were using 98% as a threshold to determine if we were simply full, however in practice this is a really high bar to hit. For example reports of systems running into this problem had around 94% usage and thus continued to flush. Fix this by lowering the threshold to 90%, which is a more sane value, especially for smaller file systems. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212185 CC: stable@vger.kernel.org # 5.12+ Fixes: 576fa34830af ("btrfs: improve preemptive background space flushing") Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 7293e4381e70cb1506ede610b619d98bd9c5fa42 Author: Josef Bacik Date: Wed Jul 14 14:47:21 2021 -0400 btrfs: wait on async extents when flushing delalloc commit e16460707e94c3d4c1b5418cb68b28b8efa903b2 upstream. I've been debugging an early ENOSPC problem in production and finally root caused it to this problem. When we switched to the per-inode in 38d715f494f2 ("btrfs: use btrfs_start_delalloc_roots in shrink_delalloc") I pulled out the async extent handling, because we were doing the correct thing by calling filemap_flush() if we had async extents set. This would properly wait on any async extents by locking the page in the second flush, thus making sure our ordered extents were properly set up. However when I switched us back to page based flushing, I used sync_inode(), which allows us to pass in our own wbc. The problem here is that sync_inode() is smarter than the filemap_* helpers, it tries to avoid calling writepages at all. This means that our second call could skip calling do_writepages altogether, and thus not wait on the pagelock for the async helpers. This means we could come back before any ordered extents were created and then simply continue on in our flushing mechanisms and ENOSPC out when we have plenty of space to use. Fix this by putting back the async pages logic in shrink_delalloc. This allows us to bulk write out everything that we need to, and then we can wait in one place for the async helpers to catch up, and then wait on any ordered extents that are created. Fixes: e076ab2a2ca7 ("btrfs: shrink delalloc pages instead of full inodes") CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 31175cfbc4771aa24b216ba1517a10837aa263b0 Author: Josef Bacik Date: Wed Jul 14 14:47:17 2021 -0400 btrfs: wake up async_delalloc_pages waiters after submit commit ac98141d140444fe93e26471d3074c603b70e2ca upstream. We use the async_delalloc_pages mechanism to make sure that we've completed our async work before trying to continue our delalloc flushing. The reason for this is we need to see any ordered extents that were created by our delalloc flushing. However we're waking up before we do the submit work, which is before we create the ordered extents. This is a pretty wide race window where we could potentially think there are no ordered extents and thus exit shrink_delalloc prematurely. Fix this by waking us up after we've done the work to create ordered extents. CC: stable@vger.kernel.org # 5.4+ Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 5fe46590d0152bee5164c3603b90b61ee674b31e Author: Josef Bacik Date: Wed Jul 14 14:47:20 2021 -0400 btrfs: use delalloc_bytes to determine flush amount for shrink_delalloc commit 03fe78cc2942c55cc13be5ca42578750f17204a1 upstream. We have been hitting some early ENOSPC issues in production with more recent kernels, and I tracked it down to us simply not flushing delalloc as aggressively as we should be. With tracing I was seeing us failing all tickets with all of the block rsvs at or around 0, with very little pinned space, but still around 120MiB of outstanding bytes_may_used. Upon further investigation I saw that we were flushing around 14 pages per shrink call for delalloc, despite having around 2GiB of delalloc outstanding. Consider the example of a 8 way machine, all CPUs trying to create a file in parallel, which at the time of this commit requires 5 items to do. Assuming a 16k leaf size, we have 10MiB of total metadata reclaim size waiting on reservations. Now assume we have 128MiB of delalloc outstanding. With our current math we would set items to 20, and then set to_reclaim to 20 * 256k, or 5MiB. Assuming that we went through this loop all 3 times, for both FLUSH_DELALLOC and FLUSH_DELALLOC_WAIT, and then did the full loop twice, we'd only flush 60MiB of the 128MiB delalloc space. This could leave a fair bit of delalloc reservations still hanging around by the time we go to ENOSPC out all the remaining tickets. Fix this two ways. First, change the calculations to be a fraction of the total delalloc bytes on the system. Prior to this change we were calculating based on dirty inodes so our math made more sense, now it's just completely unrelated to what we're actually doing. Second add a FLUSH_DELALLOC_FULL state, that we hold off until we've gone through the flush states at least once. This will empty the system of all delalloc so we're sure to be truly out of space when we start failing tickets. I'm tagging stable 5.10 and forward, because this is where we started using the page stuff heavily again. This affects earlier kernel versions as well, but would be a pain to backport to them as the flushing mechanisms aren't the same. CC: stable@vger.kernel.org # 5.10+ Reviewed-by: Nikolay Borisov Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 51da2df5cb3b52ddc094404bce55a363db291db2 Author: Jens Axboe Date: Mon Sep 13 09:24:07 2021 -0600 io-wq: fix race between adding work and activating a free worker commit 94ffb0a282872c2f4b14f757fa1aef2302aeaabb upstream. The attempt to find and activate a free worker for new work is currently combined with creating a new one if we don't find one, but that opens io-wq up to a race where the worker that is found and activated can put itself to sleep without knowing that it has been selected to perform this new work. Fix this by moving the activation into where we add the new work item, then we can retain it within the wqe->lock scope and elimiate the race with the worker itself checking inside the lock, but sleeping outside of it. Cc: stable@vger.kernel.org Reported-by: Andres Freund Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a06577ea675a19ddcc8914831313ec3ec2ced26c Author: Jens Axboe Date: Mon Sep 13 09:20:44 2021 -0600 io-wq: fix wakeup race when adding new work commit 87df7fb922d18e96992aa5e824aa34b2065fef59 upstream. When new work is added, io_wqe_enqueue() checks if we need to wake or create a new worker. But that check is done outside the lock that otherwise synchronizes us with a worker going to sleep, so we can end up in the following situation: CPU0 CPU1 lock insert work unlock atomic_read(nr_running) != 0 lock atomic_dec(nr_running) no wakeup needed Hold the wqe lock around the "need to wakeup" check. Then we can also get rid of the temporary work_flags variable, as we know the work will remain valid as long as we hold the lock. Cc: stable@vger.kernel.org Reported-by: Andres Freund Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 701d5faec2b8a69c4697d4d64a57828a6adb04a3 Author: Pavel Begunkov Date: Mon Sep 13 09:18:44 2021 -0600 io_uring: fix io_try_cancel_userdata race for iowq commit dadebc350da2bef62593b1df007a6e0b90baf42a upstream. WARNING: CPU: 1 PID: 5870 at fs/io_uring.c:5975 io_try_cancel_userdata+0x30f/0x540 fs/io_uring.c:5975 CPU: 0 PID: 5870 Comm: iou-wrk-5860 Not tainted 5.14.0-rc6-next-20210820-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:io_try_cancel_userdata+0x30f/0x540 fs/io_uring.c:5975 Call Trace: io_async_cancel fs/io_uring.c:6014 [inline] io_issue_sqe+0x22d5/0x65a0 fs/io_uring.c:6407 io_wq_submit_work+0x1dc/0x300 fs/io_uring.c:6511 io_worker_handle_work+0xa45/0x1840 fs/io-wq.c:533 io_wqe_worker+0x2cc/0xbb0 fs/io-wq.c:582 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 io_try_cancel_userdata() can be called from io_async_cancel() executing in the io-wq context, so the warning fires, which is there to alert anyone accessing task->io_uring->io_wq in a racy way. However, io_wq_put_and_exit() always first waits for all threads to complete, so the only detail left is to zero tctx->io_wq after the context is removed. note: one little assumption is that when IO_WQ_WORK_CANCEL, the executor won't touch ->io_wq, because io_wq_destroy() might cancel left pending requests in such a way. Cc: stable@vger.kernel.org Reported-by: syzbot+b0c9d1588ae92866515f@syzkaller.appspotmail.com Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/dfdd37a80cfa9ffd3e59538929c99cdd55d8699e.1629721757.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 87ed36bed9d78002ab61db250ffe9efc30d0d6a1 Author: Pavel Begunkov Date: Mon Sep 13 09:17:19 2021 -0600 io_uring: add ->splice_fd_in checks commit 26578cda3db983b17cabe4e577af26306beb9987 upstream. ->splice_fd_in is used only by splice/tee, but no other request checks it for validity. Add the check for most of request types excluding reads/writes/sends/recvs, we don't want overhead for them and can leave them be as is until the field is actually used. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/f44bc2acd6777d932de3d71a5692235b5b2b7397.1629451684.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3e433e671e17fe32b6fbc4fe0d836636efc03e80 Author: Pavel Begunkov Date: Mon Sep 13 09:31:43 2021 -0600 io_uring: place fixed tables under memcg limits commit 0bea96f59ba40e63c0ae93ad6a02417b95f22f4d upstream. Fixed tables may be large enough, place all of them together with allocated tags under memcg limits. Cc: stable@vger.kernel.org Signed-off-by: Pavel Begunkov Link: https://lore.kernel.org/r/b3ac9f5da9821bb59837b5fe25e8ef4be982218c.1629451684.git.asml.silence@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a71001a193dd69347d4e5b05ea52602fe3b0d893 Author: Dmitry Osipenko Date: Sun Aug 8 19:00:30 2021 +0300 rtc: tps65910: Correct driver module alias commit 8d448fa0a8bb1c8d94eef7647edffe9ac81a281e upstream. The TPS65910 RTC driver module doesn't auto-load because of the wrong module alias that doesn't match the device name, fix it. Cc: stable@vger.kernel.org Reported-by: Anton Bambura Tested-by: Anton Bambura Signed-off-by: Dmitry Osipenko Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210808160030.8556-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman commit 598ce306f2757cbf3d003de8e244b48863f917be Author: Randy Dunlap Date: Tue Sep 7 15:42:02 2021 -0700 Makefile: use -Wno-main in the full kernel tree commit 49832c819ab85b33b7a2a1429c8d067e82be2977 upstream. When using gcc (SUSE Linux) 7.5.0 (on openSUSE 15.3), I see a build warning: kernel/trace/trace_osnoise.c: In function 'start_kthread': kernel/trace/trace_osnoise.c:1461:8: warning: 'main' is usually a function [-Wmain] void *main = osnoise_main; ^~~~ Quieten that warning by using "-Wno-main". It's OK to use "main" as a declaration name in the kernel. Build-tested on most ARCHes. [ v2: only do it for gcc, since clang doesn't have that particular warning ] Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/lkml/20210813224131.25803-1-rdunlap@infradead.org/ Suggested-by: Steven Rostedt Suggested-by: Linus Torvalds Cc: Daniel Bristot de Oliveira Cc: Masahiro Yamada Cc: Michal Marek Cc: linux-kbuild@vger.kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman