commit 0e62c60b3e7e0cb6ef4679e9da31709ac68918e9 Author: Greg Kroah-Hartman Date: Wed Nov 17 11:04:53 2021 +0100 Linux 5.14.19 Link: https://lore.kernel.org/r/20211115165419.961798833@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Fox Chen Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20211116142622.081299270@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Fox Chen Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman commit c6d58e3e55f5e51933a2f7055eb7efb7886e9838 Author: Hans de Goede Date: Mon Nov 1 14:53:55 2021 +0000 media: videobuf2-dma-sg: Fix buf->vb NULL pointer dereference commit d55c3ee6b4c7b76326eb257403762f8bd7cc48c2 upstream. Commit a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API") added a new vb member to struct vb2_dma_sg_buf, but it only added code setting this to the vb2_dma_sg_alloc() function and not to the vb2_dma_sg_get_userptr() and vb2_dma_sg_attach_dmabuf() which also create vb2_dma_sg_buf objects. This is causing a crash due to a NULL pointer deref when using libcamera on devices with an Intel IPU3 (qcam app). Fix these crashes by assigning buf->vb in the other 2 functions too, note libcamera tests the vb2_dma_sg_get_userptr() path, the change to the vb2_dma_sg_attach_dmabuf() path is untested. Fixes: a4b83deb3e76 ("media: videobuf2: rework vb2_mem_ops API") Cc: Sergey Senozhatsky Signed-off-by: Hans de Goede Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 283fd7d9fdea4652f8922404ea152e651a3ac44b Author: Sergey Senozhatsky Date: Tue Sep 28 04:46:34 2021 +0100 media: videobuf2: always set buffer vb2 pointer commit 67f85135c57c8ea20b5417b28ae65e53dc2ec2c3 upstream. We need to always link allocated vb2_dc_buf back to vb2_buffer because we dereference vb2 in prepare() and finish() callbacks. Signed-off-by: Sergey Senozhatsky Tested-by: Chen-Yu Tsai Acked-by: Tomasz Figa Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 6a1968a2f2f6f8555526fccb19530721b5cbc444 Author: Borislav Petkov Date: Fri Oct 1 21:41:20 2021 +0200 x86/sev: Make the #VC exception stacks part of the default stacks storage commit 541ac97186d9ea88491961a46284de3603c914fd upstream. The size of the exception stacks was increased by the commit in Fixes, resulting in stack sizes greater than a page in size. The #VC exception handling was only mapping the first (bottom) page, resulting in an SEV-ES guest failing to boot. Make the #VC exception stacks part of the default exception stacks storage and allocate them with a CONFIG_AMD_MEM_ENCRYPT=y .config. Map them only when a SEV-ES guest has been detected. Rip out the custom VC stacks mapping and storage code. [ bp: Steal and adapt Tom's commit message. ] Fixes: 7fae4c24a2b8 ("x86: Increase exception stack sizes") Signed-off-by: Borislav Petkov Tested-by: Tom Lendacky Tested-by: Brijesh Singh Link: https://lkml.kernel.org/r/YVt1IMjIs7pIZTRR@zn.tnic Signed-off-by: Greg Kroah-Hartman commit 8c57c9ff7e88d6c725d19744afadde9cb5447aa2 Author: Tom Lendacky Date: Wed Sep 8 17:58:34 2021 -0500 x86/sev: Add an x86 version of cc_platform_has() commit aa5a461171f98fde0df78c4f6b5018a1e967cf81 upstream. Introduce an x86 version of the cc_platform_has() function. This will be used to replace vendor specific calls like sme_active(), sev_active(), etc. Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210928191009.32551-4-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 0e1cd02ff0d89793681aabf0bc56f26ebd4273dd Author: Tom Lendacky Date: Wed Sep 8 17:58:33 2021 -0500 arch/cc: Introduce a function to check for confidential computing features commit 46b49b12f3fc5e1347dba37d4639e2165f447871 upstream. In preparation for other confidential computing technologies, introduce a generic helper function, cc_platform_has(), that can be used to check for specific active confidential computing attributes, like memory encryption. This is intended to eliminate having to add multiple technology-specific checks to the code (e.g. if (sev_active() || tdx_active() || ... ). [ bp: s/_CC_PLATFORM_H/_LINUX_CC_PLATFORM_H/g ] Co-developed-by: Andi Kleen Signed-off-by: Andi Kleen Co-developed-by: Kuppuswamy Sathyanarayanan Signed-off-by: Kuppuswamy Sathyanarayanan Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210928191009.32551-3-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 45a47382941d9702ec50608b6e4edd27c2bdd15a Author: THOBY Simon Date: Sun Aug 22 08:55:26 2021 +0000 IMA: reject unknown hash algorithms in ima_get_hash_algo commit cb181da161963eddc9de0000de6ab2c7942be219 upstream. The new function validate_hash_algo() assumed that ima_get_hash_algo() always return a valid 'enum hash_algo', but it returned the user-supplied value present in the digital signature without any bounds checks. Update ima_get_hash_algo() to always return a valid hash algorithm, defaulting on 'ima_hash_algo' when the user-supplied value inside the xattr is invalid. Signed-off-by: THOBY Simon Reported-by: syzbot+e8bafe7b82c739eaf153@syzkaller.appspotmail.com Fixes: 50f742dd9147 ("IMA: block writes of the security.ima xattr with unsupported algorithms") Reviewed-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit a3c6e358fbe42247c347c6b777167e5c4351248d Author: Andrii Nakryiko Date: Mon Nov 1 16:01:18 2021 -0700 selftests/bpf: Fix also no-alu32 strobemeta selftest commit a20eac0af02810669e187cb623bc904908c423af upstream. Previous fix aded bpf_clamp_umax() helper use to re-validate boundaries. While that works correctly, it introduces more branches, which blows up past 1 million instructions in no-alu32 variant of strobemeta selftests. Switching len variable from u32 to u64 also fixes the issue and reduces the number of validated instructions, so use that instead. Fix this patch and bpf_clamp_umax() removed, both alu32 and no-alu32 selftests pass. Fixes: 0133c20480b1 ("selftests/bpf: Fix strobemeta selftest regression") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211101230118.1273019-1-andrii@kernel.org Signed-off-by: Greg Kroah-Hartman commit 49ed44184d0ceb0b04347ebdc050cab5ce905df7 Author: Borislav Petkov Date: Fri Oct 29 19:27:32 2021 +0200 selftests/x86/iopl: Adjust to the faked iopl CLI/STI usage commit a72fdfd21e01c626273ddcf5ab740d4caef4be54 upstream. Commit in Fixes changed the iopl emulation to not #GP on CLI and STI because it would break some insane luserspace tools which would toggle interrupts. The corresponding selftest would rely on the fact that executing CLI/STI would trigger a #GP and thus detect it this way but since that #GP is not happening anymore, the detection is now wrong too. Extend the test to actually look at the IF flag and whether executing those insns had any effect on it. The STI detection needs to have the fact that interrupts were previously disabled, passed in so do that from the previous CLI test, i.e., STI test needs to follow a previous CLI one for it to make sense. Fixes: b968e84b509d ("x86/iopl: Fake iopl(3) CLI/STI usage") Suggested-by: Thomas Gleixner Signed-off-by: Borislav Petkov Acked-by: Thomas Gleixner Link: https://lore.kernel.org/r/20211030083939.13073-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 35207858385e96f775736304e44cad5232417d8f Author: Colin Ian King Date: Wed Oct 13 11:00:52 2021 +0100 mmc: moxart: Fix null pointer dereference on pointer host commit 0eab756f8821d255016c63bb55804c429ff4bdb1 upstream. There are several error return paths that dereference the null pointer host because the pointer has not yet been set to a valid value. Fix this by adding a new out_mmc label and exiting via this label to avoid the host clean up and hence the null pointer dereference. Addresses-Coverity: ("Explicit null dereference") Fixes: 8105c2abbf36 ("mmc: moxart: Fix reference count leaks in moxart_probe") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20211013100052.125461-1-colin.king@canonical.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c254f7893bc17065fc24466758602da9ee6aadaa Author: Arnd Bergmann Date: Wed Oct 20 11:59:07 2021 +0300 ath10k: fix invalid dma_addr_t token assignment commit 937e79c67740d1d84736730d679f3cb2552f990e upstream. Using a kernel pointer in place of a dma_addr_t token can lead to undefined behavior if that makes it into cache management functions. The compiler caught one such attempt in a cast: drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_add_interface': drivers/net/wireless/ath/ath10k/mac.c:5586:47: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 5586 | arvif->beacon_paddr = (dma_addr_t)arvif->beacon_buf; | ^ Looking through how this gets used down the way, I'm fairly sure that beacon_paddr is never accessed again for ATH10K_DEV_TYPE_HL devices, and if it was accessed, that would be a bug. Change the assignment to use a known-invalid address token instead, which avoids the warning and makes it easier to catch bugs if it does end up getting used. Fixes: e263bdab9c0e ("ath10k: high latency fixes for beacon buffer") Signed-off-by: Arnd Bergmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211014075153.3655910-1-arnd@kernel.org Signed-off-by: Greg Kroah-Hartman commit 733aac9beea8b2294f14d6451fe929f2d022cd97 Author: Paulo Alcantara Date: Fri Nov 12 14:53:36 2021 -0300 cifs: fix memory leak of smb3_fs_context_dup::server_hostname commit 869da64d071142d4ed562a3e909deb18e4e72c4e upstream. Fix memory leak of smb3_fs_context_dup::server_hostname when parsing and duplicating fs contexts during mount(2) as reported by kmemleak: unreferenced object 0xffff888125715c90 (size 16): comm "mount.cifs", pid 3832, jiffies 4304535868 (age 190.094s) hex dump (first 16 bytes): 7a 65 6c 64 61 2e 74 65 73 74 00 6b 6b 6b 6b a5 zelda.test.kkkk. backtrace: [] kstrdup+0x2e/0x60 [] smb3_fs_context_dup+0x392/0x8d0 [cifs] [] cifs_smb3_do_mount+0x143/0x1700 [cifs] [] smb3_get_tree+0x2e8/0x520 [cifs] [] vfs_get_tree+0x8a/0x2d0 [] path_mount+0x423/0x1a10 [] __x64_sys_mount+0x1fa/0x270 [] do_syscall_64+0x3b/0x90 [] entry_SYSCALL_64_after_hwframe+0x44/0xae unreferenced object 0xffff888111deed20 (size 32): comm "mount.cifs", pid 3832, jiffies 4304536044 (age 189.918s) hex dump (first 32 bytes): 44 46 53 52 4f 4f 54 31 2e 5a 45 4c 44 41 2e 54 DFSROOT1.ZELDA.T 45 53 54 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 EST.kkkkkkkkkkk. backtrace: [] kstrndup+0x2d/0x90 [] smb3_parse_devname+0x9e/0x360 [cifs] [] cifs_setup_volume_info+0xa8/0x470 [cifs] [] connect_dfs_target+0x309/0xc80 [cifs] [] cifs_mount+0x8eb/0x17f0 [cifs] [] cifs_smb3_do_mount+0x265/0x1700 [cifs] [] smb3_get_tree+0x2e8/0x520 [cifs] [] vfs_get_tree+0x8a/0x2d0 [] path_mount+0x423/0x1a10 [] __x64_sys_mount+0x1fa/0x270 [] do_syscall_64+0x3b/0x90 [] entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 7be3248f3139 ("cifs: To match file servers, make sure the server hostname matches") Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 4f2bf4fe6c0d4100763753fb7bb2635ee96825a6 Author: Hans Verkuil Date: Tue Sep 14 08:21:25 2021 +0100 media: vidtv: move kfree(dvb) to vidtv_bridge_dev_release() commit 112024a3b6dcfc62ec36ea0cf58b897f2ce54c59 upstream. Adding kfree(dvb) to vidtv_bridge_remove() will remove the memory too soon: if an application still has an open filehandle to the device when the driver is unloaded, then when that filehandle is closed, a use-after-free access takes place to the freed memory. Move the kfree(dvb) to vidtv_bridge_dev_release() instead. Signed-off-by: Hans Verkuil Fixes: 76e21bb8be4f ("media: vidtv: Fix memory leak in remove") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit af09862cb5661cfdedd114ae50c7aaed94bd185a Author: Mario Limonciello Date: Tue Nov 2 10:04:37 2021 -0500 drm/amd/display: Look at firmware version to determine using dmub on dcn21 commit 91adec9e07097e538691daed5d934e7886dd1dc3 upstream. commit 652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21 asics") switched over to using dmub on Renoir to fix Gitlab 1735, but this implied a new dependency on newer firmware which might not be met on older kernel versions. Since sw_init runs before hw_init, there is an opportunity to determine whether or not the firmware version is new to adjust the behavior. Cc: Roman.Li@amd.com BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1772 BugLink: https://gitlab.freedesktop.org/drm/amd/-/issues/1735 Fixes: 652de07addd2 ("drm/amd/display: Fully switch to dmub for all dcn21 asics") Signed-off-by: Mario Limonciello Acked-by: Alex Deucher Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 697103ad736a913df3409d55def2801e85d7d971 Author: Basavaraj Natikar Date: Tue Aug 31 17:36:13 2021 +0530 pinctrl: amd: Handle wake-up interrupt commit acd47b9f28e55b505aedb842131b40904e151d7c upstream. Enable/disable power management wakeup mode, which is disabled by default. enable_irq_wake enables wakes the system from sleep. Hence added enable/disable irq_wake to handle wake-up interrupt. Signed-off-by: Basavaraj Natikar Tested-by: Mario Limonciello Acked-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20210831120613.1514899-3-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 03e1b25d4079241d8019e8d801a3fa4a1f7dbd73 Author: Basavaraj Natikar Date: Tue Aug 31 17:36:12 2021 +0530 pinctrl: amd: Add irq field data commit 7e6f8d6f4a42ef9b693ff1b49267c546931d4619 upstream. pinctrl_amd use gpiochip_get_data() to get their local state containers back from the gpiochip passed as amd_gpio chip data. Hence added irq field data to get directly using amd_gpio chip data. Signed-off-by: Basavaraj Natikar Tested-by: Mario Limonciello Acked-by: Shyam Sundar S K Link: https://lore.kernel.org/r/20210831120613.1514899-2-Basavaraj.Natikar@amd.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit f80264b897b2366bfed0fb1af886827f36298986 Author: Trond Myklebust Date: Mon Jul 12 09:52:59 2021 -0400 SUNRPC: Partial revert of commit 6f9f17287e78 commit ea7a1019d8baf8503ecd6e3ec8436dec283569e6 upstream. The premise of commit 6f9f17287e78 ("SUNRPC: Mitigate cond_resched() in xprt_transmit()") was that cond_resched() is expensive and unnecessary when there has been just a single send. The point of cond_resched() is to ensure that tasks that should pre-empt this one get a chance to do so when it is safe to do so. The code prior to commit 6f9f17287e78 failed to take into account that it was keeping a rpc_task pinned for longer than it needed to, and so rather than doing a full revert, let's just move the cond_resched. Signed-off-by: Trond Myklebust Signed-off-by: Greg Kroah-Hartman commit 7a914508ca2feda632c8dca0258cd602083f9389 Author: Pali Rohár Date: Tue Oct 5 20:09:41 2021 +0200 PCI: aardvark: Fix PCIe Max Payload Size setting commit a4e17d65dafdd3513042d8f00404c9b6068a825c upstream. Change PCIe Max Payload Size setting in PCIe Device Control register to 512 bytes to align with PCIe Link Initialization sequence as defined in Marvell Armada 3700 Functional Specification. According to the specification, maximal Max Payload Size supported by this device is 512 bytes. Without this kernel prints suspicious line: pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 16384, max 512) With this change it changes to: pci 0000:01:00.0: Upstream bridge's Max Payload Size set to 256 (was 512, max 512) Link: https://lore.kernel.org/r/20211005180952.6812-3-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit f12fbf40bf63cc18d5731f25a20c6ab847f6cc2f Author: Pali Rohár Date: Tue Oct 5 20:09:40 2021 +0200 PCI: Add PCI_EXP_DEVCTL_PAYLOAD_* macros commit 460275f124fb072dca218a6b43b6370eebbab20d upstream. Define a macro PCI_EXP_DEVCTL_PAYLOAD_* for every possible Max Payload Size in linux/pci_regs.h, in the same style as PCI_EXP_DEVCTL_READRQ_*. Link: https://lore.kernel.org/r/20211005180952.6812-2-kabel@kernel.org Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Reviewed-by: Bjorn Helgaas Signed-off-by: Greg Kroah-Hartman commit 7005ee54fc094060616cf215c8d0406113131f66 Author: Jernej Skrabec Date: Tue Aug 31 20:48:19 2021 +0200 drm/sun4i: Fix macros in sun8i_csc.h commit c302c98da646409d657a473da202f10f417f3ff1 upstream. Macros SUN8I_CSC_CTRL() and SUN8I_CSC_COEFF() don't follow usual recommendation of having arguments enclosed in parenthesis. While that didn't change anything for quite sometime, it actually become important after CSC code rework with commit ea067aee45a8 ("drm/sun4i: de2/de3: Remove redundant CSC matrices"). Without this fix, colours are completely off for supported YVU formats on SoCs with DE2 (A64, H3, R40, etc.). Fix the issue by enclosing macro arguments in parenthesis. Cc: stable@vger.kernel.org # 5.12+ Fixes: 883029390550 ("drm/sun4i: Add DE2 CSC library") Reported-by: Roman Stratiienko Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20210831184819.93670-1-jernej.skrabec@gmail.com Signed-off-by: Greg Kroah-Hartman commit a595cc219051aa84f24452fcb67db63b54a1580a Author: Xiaoming Ni Date: Wed Sep 29 11:36:46 2021 +0800 powerpc/85xx: fix timebase sync issue when CONFIG_HOTPLUG_CPU=n commit c45361abb9185b1e172bd75eff51ad5f601ccae4 upstream. When CONFIG_SMP=y, timebase synchronization is required when the second kernel is started. arch/powerpc/kernel/smp.c: int __cpu_up(unsigned int cpu, struct task_struct *tidle) { ... if (smp_ops->give_timebase) smp_ops->give_timebase(); ... } void start_secondary(void *unused) { ... if (smp_ops->take_timebase) smp_ops->take_timebase(); ... } When CONFIG_HOTPLUG_CPU=n and CONFIG_KEXEC_CORE=n, smp_85xx_ops.give_timebase is NULL, smp_85xx_ops.take_timebase is NULL, As a result, the timebase is not synchronized. Timebase synchronization does not depend on CONFIG_HOTPLUG_CPU. Fixes: 56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Xiaoming Ni Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210929033646.39630-3-nixiaoming@huawei.com Signed-off-by: Greg Kroah-Hartman commit 0a6412029f7ea9835b35a40b8ec3f98ae18eec01 Author: Nathan Lynch Date: Wed Oct 20 14:47:03 2021 -0500 powerpc/pseries/mobility: ignore ibm, platform-facilities updates commit 319fa1a52e438a6e028329187783a25ad498c4e6 upstream. On VMs with NX encryption, compression, and/or RNG offload, these capabilities are described by nodes in the ibm,platform-facilities device tree hierarchy: $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/ /sys/firmware/devicetree/base/ibm,platform-facilities/ ├── ibm,compression-v1 ├── ibm,random-v1 └── ibm,sym-encryption-v1 3 directories The acceleration functions that these nodes describe are not disrupted by live migration, not even temporarily. But the post-migration ibm,update-nodes sequence firmware always sends "delete" messages for this hierarchy, followed by an "add" directive to reconstruct it via ibm,configure-connector (log with debugging statements enabled in mobility.c): mobility: removing node /ibm,platform-facilities/ibm,random-v1:4294967285 mobility: removing node /ibm,platform-facilities/ibm,compression-v1:4294967284 mobility: removing node /ibm,platform-facilities/ibm,sym-encryption-v1:4294967283 mobility: removing node /ibm,platform-facilities:4294967286 ... mobility: added node /ibm,platform-facilities:4294967286 Note we receive a single "add" message for the entire hierarchy, and what we receive from the ibm,configure-connector sequence is the top-level platform-facilities node along with its three children. The debug message simply reports the parent node and not the whole subtree. Also, significantly, the nodes added are almost completely equivalent to the ones removed; even phandles are unchanged. ibm,shared-interrupt-pool in the leaf nodes is the only property I've observed to differ, and Linux does not use that. So in practice, the sum of update messages Linux receives for this hierarchy is equivalent to minor property updates. We succeed in removing the original hierarchy from the device tree. But the vio bus code is ignorant of this, and does not unbind or relinquish its references. The leaf nodes, still reachable through sysfs, of course still refer to the now-freed ibm,platform-facilities parent node, which makes use-after-free possible: refcount_t: addition on 0; use-after-free. WARNING: CPU: 3 PID: 1706 at lib/refcount.c:25 refcount_warn_saturate+0x164/0x1f0 refcount_warn_saturate+0x160/0x1f0 (unreliable) kobject_get+0xf0/0x100 of_node_get+0x30/0x50 of_get_parent+0x50/0xb0 of_fwnode_get_parent+0x54/0x90 fwnode_count_parents+0x50/0x150 fwnode_full_name_string+0x30/0x110 device_node_string+0x49c/0x790 vsnprintf+0x1c0/0x4c0 sprintf+0x44/0x60 devspec_show+0x34/0x50 dev_attr_show+0x40/0xa0 sysfs_kf_seq_show+0xbc/0x200 kernfs_seq_show+0x44/0x60 seq_read_iter+0x2a4/0x740 kernfs_fop_read_iter+0x254/0x2e0 new_sync_read+0x120/0x190 vfs_read+0x1d0/0x240 Moreover, the "new" replacement subtree is not correctly added to the device tree, resulting in ibm,platform-facilities parent node without the appropriate leaf nodes, and broken symlinks in the sysfs device hierarchy: $ tree -d /sys/firmware/devicetree/base/ibm,platform-facilities/ /sys/firmware/devicetree/base/ibm,platform-facilities/ 0 directories $ cd /sys/devices/vio ; find . -xtype l -exec file {} + ./ibm,sym-encryption-v1/of_node: broken symbolic link to ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,sym-encryption-v1 ./ibm,random-v1/of_node: broken symbolic link to ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,random-v1 ./ibm,compression-v1/of_node: broken symbolic link to ../../../firmware/devicetree/base/ibm,platform-facilities/ibm,compression-v1 This is because add_dt_node() -> dlpar_attach_node() attaches only the parent node returned from configure-connector, ignoring any children. This should be corrected for the general case, but fixing that won't help with the stale OF node references, which is the more urgent problem. One way to address that would be to make the drivers respond to node removal notifications, so that node references can be dropped appropriately. But this would likely force the drivers to disrupt active clients for no useful purpose: equivalent nodes are immediately re-added. And recall that the acceleration capabilities described by the nodes remain available throughout the whole process. The solution I believe to be robust for this situation is to convert remove+add of a node with an unchanged phandle to an update of the node's properties in the Linux device tree structure. That would involve changing and adding a fair amount of code, and may take several iterations to land. Until that can be realized we have a confirmed use-after-free and the possibility of memory corruption. So add a limited workaround that discriminates on the node type, ignoring adds and removes. This should be amenable to backporting in the meantime. Fixes: 410bccf97881 ("powerpc/pseries: Partition migration in the kernel") Cc: stable@vger.kernel.org Signed-off-by: Nathan Lynch Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211020194703.2613093-1-nathanl@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit baf19ea102c3f3712fa9c5fef8a6ca3d37a90c1a Author: Nicholas Piggin Date: Tue Oct 26 22:25:31 2021 +1000 powerpc/64s/interrupt: Fix check_return_regs_valid() false positive commit 4a5cb51f3db4be547225a4bce7a43d41b231382b upstream. The check_return_regs_valid() can cause a false positive if the return regs are marked as norestart and they are an HSRR type interrupt, because the low bit in the bottom of regs->trap causes interrupt type matching to fail. This can occcur for example on bare metal with a HV privileged doorbell interrupt that causes a signal, but do_signal returns early because get_signal() fails, and takes the "No signal to deliver" path. In this case no signal was delivered so the return location is not changed so return SRRs are not invalidated, yet set_trap_norestart is called, which messes up the match. Building go-1.16.6 is known to reproduce this. Fix it by using the TRAP() accessor which masks out the low bit. Fixes: 6eaaf9de3599 ("powerpc/64s/interrupt: Check and fix srr_valid without crashing") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211026122531.3599918-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 251959e47018b4696ccbef32f5502f0f810603f4 Author: Russell Currey Date: Wed Oct 27 17:24:10 2021 +1000 powerpc/security: Use a mutex for interrupt exit code patching commit 3c12b4df8d5e026345a19886ae375b3ebc33c0b6 upstream. The mitigation-patching.sh script in the powerpc selftests toggles all mitigations on and off simultaneously, revealing that rfi_flush and stf_barrier cannot safely operate at the same time due to races in updating the static key. On some systems, the static key code throws a warning and the kernel remains functional. On others, the kernel will hang or crash. Fix this by slapping on a mutex. Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Russell Currey Acked-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211027072410.40950-1-ruscur@russell.cc Signed-off-by: Greg Kroah-Hartman commit 0795f5e71d1d7dadafc944a7550d9ac8d57b0ba0 Author: Vasant Hegde Date: Thu Oct 28 22:27:16 2021 +0530 powerpc/powernv/prd: Unregister OPAL_MSG_PRD2 notifier during module unload commit 52862ab33c5d97490f3fa345d6529829e6d6637b upstream. Commit 587164cd, introduced new opal message type (OPAL_MSG_PRD2) and added opal notifier. But I missed to unregister the notifier during module unload path. This results in below call trace if you try to unload and load opal_prd module. Also add new notifier_block for OPAL_MSG_PRD2 message. Sample calltrace (modprobe -r opal_prd; modprobe opal_prd) BUG: Unable to handle kernel data access on read at 0xc0080000192200e0 Faulting instruction address: 0xc00000000018d1cc Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV CPU: 66 PID: 7446 Comm: modprobe Kdump: loaded Tainted: G E 5.14.0prd #759 NIP: c00000000018d1cc LR: c00000000018d2a8 CTR: c0000000000cde10 REGS: c0000003c4c0f0a0 TRAP: 0300 Tainted: G E (5.14.0prd) MSR: 9000000002009033 CR: 24224824 XER: 20040000 CFAR: c00000000018d2a4 DAR: c0080000192200e0 DSISR: 40000000 IRQMASK: 1 ... NIP notifier_chain_register+0x2c/0xc0 LR atomic_notifier_chain_register+0x48/0x80 Call Trace: 0xc000000002090610 (unreliable) atomic_notifier_chain_register+0x58/0x80 opal_message_notifier_register+0x7c/0x1e0 opal_prd_probe+0x84/0x150 [opal_prd] platform_probe+0x78/0x130 really_probe+0x110/0x5d0 __driver_probe_device+0x17c/0x230 driver_probe_device+0x60/0x130 __driver_attach+0xfc/0x220 bus_for_each_dev+0xa8/0x130 driver_attach+0x34/0x50 bus_add_driver+0x1b0/0x300 driver_register+0x98/0x1a0 __platform_driver_register+0x38/0x50 opal_prd_driver_init+0x34/0x50 [opal_prd] do_one_initcall+0x60/0x2d0 do_init_module+0x7c/0x320 load_module+0x3394/0x3650 __do_sys_finit_module+0xd4/0x160 system_call_exception+0x140/0x290 system_call_common+0xf4/0x258 Fixes: 587164cd593c ("powerpc/powernv: Add new opal message type") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Vasant Hegde Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211028165716.41300-1-hegdevasant@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit 36859829b783edab28f9f0eeea6ba1dd76613908 Author: Nicholas Piggin Date: Thu Oct 28 23:30:43 2021 +1000 powerpc/32e: Ignore ESR in instruction storage interrupt handler commit 81291383ffde08b23bce75e7d6b2575ce9d3475c upstream. A e5500 machine running a 32-bit kernel sometimes hangs at boot, seemingly going into an infinite loop of instruction storage interrupts. The ESR (Exception Syndrome Register) has a value of 0x800000 (store) when this happens, which is likely set by a previous store. An instruction TLB miss interrupt would then leave ESR unchanged, and if no PTE exists it calls directly to the instruction storage interrupt handler without changing ESR. access_error() does not cause a segfault due to a store to a read-only vma because is_exec is true. Most subsequent fault handling does not check for a write fault on a read-only vma, and might do strange things like create a writeable PTE or call page_mkwrite on a read only vma or file. It's not clear what happens here to cause the infinite faulting in this case, a fault handler failure or low level PTE or TLB handling. In any case this can be fixed by having the instruction storage interrupt zero regs->dsisr rather than storing the ESR value to it. Fixes: a01a3f2ddbcd ("powerpc: remove arguments from fault handler functions") Cc: stable@vger.kernel.org # v5.12+ Reported-by: Jacques de Laval Signed-off-by: Nicholas Piggin Tested-by: Jacques de Laval Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211028133043.4159501-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit db56efa6173493b8b7d47fcaaff2e481cc2fac04 Author: Hari Bathini Date: Mon Oct 25 11:26:49 2021 +0530 powerpc/bpf: Fix write protecting JIT code commit 44a8214de96bafb5210e43bfa2c97c19bf75af3d upstream. Running program with bpf-to-bpf function calls results in data access exception (0x300) with the below call trace: bpf_int_jit_compile+0x238/0x750 (unreliable) bpf_check+0x2008/0x2710 bpf_prog_load+0xb00/0x13a0 __sys_bpf+0x6f4/0x27c0 sys_bpf+0x2c/0x40 system_call_exception+0x164/0x330 system_call_vectored_common+0xe8/0x278 as bpf_int_jit_compile() tries writing to write protected JIT code location during the extra pass. Fix it by holding off write protection of JIT code until the extra pass, where branch target addresses fixup happens. Fixes: 62e3d4210ac9 ("powerpc/bpf: Write protect JIT code") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Hari Bathini Reviewed-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211025055649.114728-1-hbathini@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit b3e0a9cb6a6799fc13925ae3b90cf9214a96896b Author: Gustavo A. R. Silva Date: Fri Oct 15 00:03:45 2021 -0500 powerpc/vas: Fix potential NULL pointer dereference commit 61cb9ac66b30374c7fd8a8b2a3c4f8f432c72e36 upstream. (!ptr && !ptr->foo) strikes again. :) The expression (!ptr && !ptr->foo) is bogus and in case ptr is NULL, it leads to a NULL pointer dereference: ptr->foo. Fix this by converting && to || This issue was detected with the help of Coccinelle, and audited and fixed manually. Fixes: 1a0d0d5ed5e3 ("powerpc/vas: Add platform specific user window operations") Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211015050345.GA1161918@embeddedor Signed-off-by: Greg Kroah-Hartman commit 0bc921b6db557b496a9902aa3747d04d54006e0f Author: Miquel Raynal Date: Wed Sep 29 00:22:41 2021 +0200 mtd: rawnand: au1550nd: Keep the driver compatible with on-die ECC engines commit 7e3cdba176ba59eaf4d463d273da0718e3626140 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: dbffc8ccdf3a ("mtd: rawnand: au1550: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-3-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit f5a84162f174dfa82113ef358f17fa93674ee312 Author: Miquel Raynal Date: Wed Sep 29 00:22:46 2021 +0200 mtd: rawnand: plat_nand: Keep the driver compatible with on-die ECC engines commit 325fd539fc84f0aaa0ceb9d7d3b8718582473dc5 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 612e048e6aab ("mtd: rawnand: plat_nand: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-8-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 426c3bda49954e0c1dfa2323aadf034e54bc34ae Author: Miquel Raynal Date: Wed Sep 29 00:22:44 2021 +0200 mtd: rawnand: orion: Keep the driver compatible with on-die ECC engines commit 194ac63de6ff56d30c48e3ac19c8a412f9c1408e upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 553508cec2e8 ("mtd: rawnand: orion: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-6-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 26b77361800a7939faa98fcd96f0d3091dc0281c Author: Miquel Raynal Date: Wed Sep 29 00:22:45 2021 +0200 mtd: rawnand: pasemi: Keep the driver compatible with on-die ECC engines commit f16b7d2a5e810fcf4b15d096246d0d445da9cc88 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 8fc6f1f042b2 ("mtd: rawnand: pasemi: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-7-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 8d37b0ee8875f74b8d5f0e4486b7b09b8e3bd1a7 Author: Miquel Raynal Date: Wed Sep 29 00:22:42 2021 +0200 mtd: rawnand: gpio: Keep the driver compatible with on-die ECC engines commit b5b5b4dc6fcd8194b9dd38c8acdc5ab71adf44f8 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: f6341f6448e0 ("mtd: rawnand: gpio: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-4-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 0c82481e30648477f4f216b5d775a758a3ba871c Author: Miquel Raynal Date: Wed Sep 29 00:22:43 2021 +0200 mtd: rawnand: mpc5121: Keep the driver compatible with on-die ECC engines commit f9d8570b7fd6f4f08528ce2f5e39787a8a260cd6 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 6dd09f775b72 ("mtd: rawnand: mpc5121: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-5-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 6ad70604565c8472c8a9bafee6e373953e9b3ee0 Author: Miquel Raynal Date: Wed Sep 29 00:22:48 2021 +0200 mtd: rawnand: xway: Keep the driver compatible with on-die ECC engines commit 6bcd2960af1b7bacb2f1e710ab0c0b802d900501 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: d525914b5bd8 ("mtd: rawnand: xway: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Cc: Jan Hoffmann Cc: Kestrel seventyfour Signed-off-by: Miquel Raynal Tested-by: Jan Hoffmann Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-10-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit e4435dec6149706479c526996274b3dcd3e89836 Author: Miquel Raynal Date: Wed Sep 29 00:22:40 2021 +0200 mtd: rawnand: ams-delta: Keep the driver compatible with on-die ECC engines commit d707bb74daae07879e0fc1b4b960f8f2d0a5fe5d upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: 59d93473323a ("mtd: rawnand: ams-delta: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-2-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit ab5fdf2c5a4180c8bff2ee8cbe8b9e70c2c7c7e0 Author: Miquel Raynal Date: Wed Sep 29 00:15:00 2021 +0200 mtd: rawnand: fsmc: Fix use of SM ORDER commit 9be1446ece291a1f08164bd056bed3d698681f8b upstream. The introduction of the generic ECC engine API lead to a number of changes in various drivers which broke some of them. Here is a typical example: I expected the SM_ORDER option to be handled by the Hamming ECC engine internals. Problem: the fsmc driver does not instantiate (yet) a real ECC engine object so we had to use a 'bare' ECC helper instead of the shiny rawnand functions. However, when not intializing this engine properly and using the bare helpers, we do not get the SM ORDER feature handled automatically. It looks like this was lost in the process so let's ensure we use the right SM ORDER now. Fixes: ad9ffdce4539 ("mtd: rawnand: fsmc: Fix external use of SW Hamming ECC helper") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928221507.199198-2-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 6e7363893639c7d9023b18b4038d4cb2b5b4bf8c Author: Dong Aisheng Date: Fri Sep 10 17:06:20 2021 +0800 remoteproc: imx_rproc: Fix rsc-table name commit e90547d59d4e29e269e22aa6ce590ed0b41207d2 upstream. Usually the dash '-' is preferred in node name. So far, not dts in upstream kernel, so we just update node name in driver. Cc: Bjorn Andersson Cc: Mathieu Poirier Fixes: 5e4c1243071d ("remoteproc: imx_rproc: support remote cores booted before Linux Kernel") Reviewed-and-tested-by: Peng Fan Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-6-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 0f27656d5e263d75c86550e55262ab26feefb281 Author: Dong Aisheng Date: Fri Sep 10 17:06:19 2021 +0800 remoteproc: imx_rproc: Fix ignoring mapping vdev regions commit afe670e23af91d8a74a8d7049f6e0984bbf6ea11 upstream. vdev regions are typically named vdev0buffer, vdev0ring0, vdev0ring1 and etc. Change to strncmp to cover them all. Fixes: 8f2d8961640f ("remoteproc: imx_rproc: ignore mapping vdev regions") Reviewed-and-tested-by: Peng Fan Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-5-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit fce6586cd1d7ba6ebf57dd6f3e38feb89c276752 Author: Dong Aisheng Date: Fri Sep 10 17:06:17 2021 +0800 remoteproc: Fix the wrong default value of is_iomem commit 970675f61bf5761d7e5326f6e4df995ecdba5e11 upstream. Currently the is_iomem is a random value in the stack which may be default to true even on those platforms that not use iomem to store firmware. Cc: Bjorn Andersson Cc: Mathieu Poirier Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va") Reviewed-and-tested-by: Peng Fan Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-3-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 69dbe49b7eac011f0cd5095fafb65196b02ab819 Author: Peng Fan Date: Fri Sep 10 17:06:16 2021 +0800 remoteproc: elf_loader: Fix loading segment when is_iomem true commit 24acbd9dc934f5d9418a736c532d3970a272063e upstream. It seems luckliy work on i.MX platform, but it is wrong. Need use memcpy_toio, not memcpy_fromio. Fixes: 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va") Tested-by: Dong Aisheng (i.MX8MQ) Reported-by: kernel test robot Reported-by: Dong Aisheng Signed-off-by: Peng Fan Cc: stable Link: https://lore.kernel.org/r/20210910090621.3073540-2-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman commit 7d1ece44014bd1b320f19572850c138605a15fb5 Author: Halil Pasic Date: Wed Sep 8 17:36:23 2021 +0200 s390/cio: make ccw_device_dma_* more robust commit ad9a14517263a16af040598c7920c09ca9670a31 upstream. Since commit 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and classic notifiers") we were supposed to make sure that virtio_ccw_release_dev() completes before the ccw device and the attached dma pool are torn down, but unfortunately we did not. Before that commit it used to be OK to delay cleaning up the memory allocated by virtio-ccw indefinitely (which isn't really intuitive for guys used to destruction happens in reverse construction order), but now we trigger a BUG_ON if the genpool is destroyed before all memory allocated from it is deallocated. Which brings down the guest. We can observe this problem, when unregister_virtio_device() does not give up the last reference to the virtio_device (e.g. because a virtio-scsi attached scsi disk got removed without previously unmounting its previously mounted partition). To make sure that the genpool is only destroyed after all the necessary freeing is done let us take a reference on the ccw device on each ccw_device_dma_zalloc() and give it up on each ccw_device_dma_free(). Actually there are multiple approaches to fixing the problem at hand that can work. The upside of this one is that it is the safest one while remaining simple. We don't crash the guest even if the driver does not pair allocations and frees. The downside is the reference counting overhead, that the reference counting for ccw devices becomes more complex, in a sense that we need to pair the calls to the aforementioned functions for it to be correct, and that if we happen to leak, we leak more than necessary (the whole ccw device instead of just the genpool). Some alternatives to this approach are taking a reference in virtio_ccw_online() and giving it up in virtio_ccw_release_dev() or making sure virtio_ccw_release_dev() completes its work before virtio_ccw_remove() returns. The downside of these approaches is that these are less safe against programming errors. Cc: # v5.3 Signed-off-by: Halil Pasic Fixes: 48720ba56891 ("virtio/s390: use DMA memory for ccw I/O and classic notifiers") Reported-by: bfu@redhat.com Reviewed-by: Vineeth Vijayan Acked-by: Cornelia Huck Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 60b9aef7f2eb7619c71f5cb2f22498d87bf54a3c Author: Harald Freudenberger Date: Thu Oct 14 09:58:24 2021 +0200 s390/ap: Fix hanging ioctl caused by orphaned replies commit 3826350e6dd435e244eb6e47abad5a47c169ebc2 upstream. When a queue is switched to soft offline during heavy load and later switched to soft online again and now used, it may be that the caller is blocked forever in the ioctl call. The failure occurs because there is a pending reply after the queue(s) have been switched to offline. This orphaned reply is received when the queue is switched to online and is accidentally counted for the outstanding replies. So when there was a valid outstanding reply and this orphaned reply is received it counts as the outstanding one thus dropping the outstanding counter to 0. Voila, with this counter the receive function is not called any more and the real outstanding reply is never received (until another request comes in...) and the ioctl blocks. The fix is simple. However, instead of readjusting the counter when an orphaned reply is detected, I check the queue status for not empty and compare this to the outstanding counter. So if the queue is not empty then the counter must not drop to 0 but at least have a value of 1. Signed-off-by: Harald Freudenberger Cc: stable@vger.kernel.org Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 9525ecf82f049f0cb1c40dfa07726e4cca771c6f Author: Sven Schnelle Date: Tue Nov 2 10:55:30 2021 +0100 s390/tape: fix timer initialization in tape_std_assign() commit 213fca9e23b59581c573d558aa477556f00b8198 upstream. commit 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()") changed the timer setup from init_timer_on_stack(() to timer_setup(), but missed to change the mod_timer() call. And while at it, use msecs_to_jiffies() instead of the open coded timeout calculation. Cc: stable@vger.kernel.org Fixes: 9c6c273aa424 ("timer: Remove init_timer_on_stack() in favor of timer_setup_on_stack()") Signed-off-by: Sven Schnelle Reviewed-by: Vasily Gorbik Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit efa70f3da72a34b691a78332a325d24529fdd10b Author: Vineeth Vijayan Date: Fri Nov 5 16:44:51 2021 +0100 s390/cio: check the subchannel validity for dev_busid commit a4751f157c194431fae9e9c493f456df8272b871 upstream. Check the validity of subchanel before reading other fields in the schib. Fixes: d3683c055212 ("s390/cio: add dev_busid sysfs entry for each subchannel") CC: Reported-by: Cornelia Huck Signed-off-by: Vineeth Vijayan Reviewed-by: Cornelia Huck Link: https://lore.kernel.org/r/20211105154451.847288-1-vneethv@linux.ibm.com Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 2ea358c095adf2ce63bf2ad3a680a85b725f8bfb Author: Thomas Richter Date: Wed Nov 3 13:13:04 2021 +0100 s390/cpumf: cpum_cf PMU displays invalid value after hotplug remove commit 9d48c7afedf91a02d03295837ec76b2fb5e7d3fe upstream. When a CPU is hotplugged while the perf stat -e cycles command is running, a wrong (very large) value is displayed immediately after the CPU removal: Check the values, shouldn't be too high as in time counts unit events 1.001101919 29261846 cycles 2.002454499 17523405 cycles 3.003659292 24361161 cycles 4.004816983 18446744073638406144 cycles 5.005671647 cycles ... The CPU hotplug off took place after 3 seconds. The issue is the read of the event count value after 4 seconds when the CPU is not available and the read of the counter returns an error. This is treated as a counter value of zero. This results in a very large value (0 - previous_value). Fix this by detecting the hotplugged off CPU and report 0 instead of a very large number. Cc: stable@vger.kernel.org Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility") Reported-by: Sumanth Korikkar Signed-off-by: Thomas Richter Reviewed-by: Sumanth Korikkar Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit e554c13dbe3caaa25558a845816baec77d03da7c Author: Rafael J. Wysocki Date: Thu Nov 4 18:26:26 2021 +0100 PM: sleep: Avoid calling put_device() under dpm_list_mtx commit 2aa36604e8243698ff22bd5fef0dd0c6bb07ba92 upstream. It is generally unsafe to call put_device() with dpm_list_mtx held, because the given device's release routine may carry out an action depending on that lock which then may deadlock, so modify the system-wide suspend and resume of devices to always drop dpm_list_mtx before calling put_device() (and adjust white space somewhat while at it). For instance, this prevents the following splat from showing up in the kernel log after a system resume in certain configurations: [ 3290.969514] ====================================================== [ 3290.969517] WARNING: possible circular locking dependency detected [ 3290.969519] 5.15.0+ #2420 Tainted: G S [ 3290.969523] ------------------------------------------------------ [ 3290.969525] systemd-sleep/4553 is trying to acquire lock: [ 3290.969529] ffff888117ab1138 ((wq_completion)hci0#2){+.+.}-{0:0}, at: flush_workqueue+0x87/0x4a0 [ 3290.969554] but task is already holding lock: [ 3290.969556] ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0 [ 3290.969571] which lock already depends on the new lock. [ 3290.969573] the existing dependency chain (in reverse order) is: [ 3290.969575] -> #3 (dpm_list_mtx){+.+.}-{3:3}: [ 3290.969583] __mutex_lock+0x9d/0xa30 [ 3290.969591] device_pm_add+0x2e/0xe0 [ 3290.969597] device_add+0x4d5/0x8f0 [ 3290.969605] hci_conn_add_sysfs+0x43/0xb0 [bluetooth] [ 3290.969689] hci_conn_complete_evt.isra.71+0x124/0x750 [bluetooth] [ 3290.969747] hci_event_packet+0xd6c/0x28a0 [bluetooth] [ 3290.969798] hci_rx_work+0x213/0x640 [bluetooth] [ 3290.969842] process_one_work+0x2aa/0x650 [ 3290.969851] worker_thread+0x39/0x400 [ 3290.969859] kthread+0x142/0x170 [ 3290.969865] ret_from_fork+0x22/0x30 [ 3290.969872] -> #2 (&hdev->lock){+.+.}-{3:3}: [ 3290.969881] __mutex_lock+0x9d/0xa30 [ 3290.969887] hci_event_packet+0xba/0x28a0 [bluetooth] [ 3290.969935] hci_rx_work+0x213/0x640 [bluetooth] [ 3290.969978] process_one_work+0x2aa/0x650 [ 3290.969985] worker_thread+0x39/0x400 [ 3290.969993] kthread+0x142/0x170 [ 3290.969999] ret_from_fork+0x22/0x30 [ 3290.970004] -> #1 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}: [ 3290.970013] process_one_work+0x27d/0x650 [ 3290.970020] worker_thread+0x39/0x400 [ 3290.970028] kthread+0x142/0x170 [ 3290.970033] ret_from_fork+0x22/0x30 [ 3290.970038] -> #0 ((wq_completion)hci0#2){+.+.}-{0:0}: [ 3290.970047] __lock_acquire+0x15cb/0x1b50 [ 3290.970054] lock_acquire+0x26c/0x300 [ 3290.970059] flush_workqueue+0xae/0x4a0 [ 3290.970066] drain_workqueue+0xa1/0x130 [ 3290.970073] destroy_workqueue+0x34/0x1f0 [ 3290.970081] hci_release_dev+0x49/0x180 [bluetooth] [ 3290.970130] bt_host_release+0x1d/0x30 [bluetooth] [ 3290.970195] device_release+0x33/0x90 [ 3290.970201] kobject_release+0x63/0x160 [ 3290.970211] dpm_resume+0x164/0x3e0 [ 3290.970215] dpm_resume_end+0xd/0x20 [ 3290.970220] suspend_devices_and_enter+0x1a4/0xba0 [ 3290.970229] pm_suspend+0x26b/0x310 [ 3290.970236] state_store+0x42/0x90 [ 3290.970243] kernfs_fop_write_iter+0x135/0x1b0 [ 3290.970251] new_sync_write+0x125/0x1c0 [ 3290.970257] vfs_write+0x360/0x3c0 [ 3290.970263] ksys_write+0xa7/0xe0 [ 3290.970269] do_syscall_64+0x3a/0x80 [ 3290.970276] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3290.970284] other info that might help us debug this: [ 3290.970285] Chain exists of: (wq_completion)hci0#2 --> &hdev->lock --> dpm_list_mtx [ 3290.970297] Possible unsafe locking scenario: [ 3290.970299] CPU0 CPU1 [ 3290.970300] ---- ---- [ 3290.970302] lock(dpm_list_mtx); [ 3290.970306] lock(&hdev->lock); [ 3290.970310] lock(dpm_list_mtx); [ 3290.970314] lock((wq_completion)hci0#2); [ 3290.970319] *** DEADLOCK *** [ 3290.970321] 7 locks held by systemd-sleep/4553: [ 3290.970325] #0: ffff888103bcd448 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xa7/0xe0 [ 3290.970341] #1: ffff888115a14488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x103/0x1b0 [ 3290.970355] #2: ffff888100f719e0 (kn->active#233){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x10c/0x1b0 [ 3290.970369] #3: ffffffff82661048 (autosleep_lock){+.+.}-{3:3}, at: state_store+0x12/0x90 [ 3290.970384] #4: ffffffff82658ac8 (system_transition_mutex){+.+.}-{3:3}, at: pm_suspend+0x9f/0x310 [ 3290.970399] #5: ffffffff827f2a48 (acpi_scan_lock){+.+.}-{3:3}, at: acpi_suspend_begin+0x4c/0x80 [ 3290.970416] #6: ffffffff8280fca8 (dpm_list_mtx){+.+.}-{3:3}, at: dpm_resume+0x12e/0x3e0 [ 3290.970428] stack backtrace: [ 3290.970431] CPU: 3 PID: 4553 Comm: systemd-sleep Tainted: G S 5.15.0+ #2420 [ 3290.970438] Hardware name: Dell Inc. XPS 13 9380/0RYJWW, BIOS 1.5.0 06/03/2019 [ 3290.970441] Call Trace: [ 3290.970446] dump_stack_lvl+0x44/0x57 [ 3290.970454] check_noncircular+0x105/0x120 [ 3290.970468] ? __lock_acquire+0x15cb/0x1b50 [ 3290.970474] __lock_acquire+0x15cb/0x1b50 [ 3290.970487] lock_acquire+0x26c/0x300 [ 3290.970493] ? flush_workqueue+0x87/0x4a0 [ 3290.970503] ? __raw_spin_lock_init+0x3b/0x60 [ 3290.970510] ? lockdep_init_map_type+0x58/0x240 [ 3290.970519] flush_workqueue+0xae/0x4a0 [ 3290.970526] ? flush_workqueue+0x87/0x4a0 [ 3290.970544] ? drain_workqueue+0xa1/0x130 [ 3290.970552] drain_workqueue+0xa1/0x130 [ 3290.970561] destroy_workqueue+0x34/0x1f0 [ 3290.970572] hci_release_dev+0x49/0x180 [bluetooth] [ 3290.970624] bt_host_release+0x1d/0x30 [bluetooth] [ 3290.970687] device_release+0x33/0x90 [ 3290.970695] kobject_release+0x63/0x160 [ 3290.970705] dpm_resume+0x164/0x3e0 [ 3290.970710] ? dpm_resume_early+0x251/0x3b0 [ 3290.970718] dpm_resume_end+0xd/0x20 [ 3290.970723] suspend_devices_and_enter+0x1a4/0xba0 [ 3290.970737] pm_suspend+0x26b/0x310 [ 3290.970746] state_store+0x42/0x90 [ 3290.970755] kernfs_fop_write_iter+0x135/0x1b0 [ 3290.970764] new_sync_write+0x125/0x1c0 [ 3290.970777] vfs_write+0x360/0x3c0 [ 3290.970785] ksys_write+0xa7/0xe0 [ 3290.970794] do_syscall_64+0x3a/0x80 [ 3290.970803] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 3290.970811] RIP: 0033:0x7f41b1328164 [ 3290.970819] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 80 00 00 00 00 8b 05 4a d2 2c 00 48 63 ff 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 55 53 48 89 d5 48 89 f3 48 83 [ 3290.970824] RSP: 002b:00007ffe6ae21b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 3290.970831] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f41b1328164 [ 3290.970836] RDX: 0000000000000004 RSI: 000055965e651070 RDI: 0000000000000004 [ 3290.970839] RBP: 000055965e651070 R08: 000055965e64f390 R09: 00007f41b1e3d1c0 [ 3290.970843] R10: 000000000000000a R11: 0000000000000246 R12: 0000000000000004 [ 3290.970846] R13: 0000000000000001 R14: 000055965e64f2b0 R15: 0000000000000004 Cc: All applicable Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit f36ada9c43dba3196767569b83b88344174eecd1 Author: Marek Vasut Date: Tue Sep 21 19:35:06 2021 +0200 video: backlight: Drop maximum brightness override for brightness zero commit 33a5471f8da976bf271a1ebbd6b9d163cb0cb6aa upstream. The note in c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c") says that gpio-backlight uses brightness as power state. This has been fixed since in ec665b756e6f7 ("backlight: gpio-backlight: Correct initial power state handling") and other backlight drivers do not require this workaround. Drop the workaround. This fixes the case where e.g. pwm-backlight can perfectly well be set to brightness 0 on boot in DT, which without this patch leads to the display brightness to be max instead of off. Fixes: c2adda27d202f ("video: backlight: Add of_find_backlight helper in backlight.c") Cc: # 5.4+ Cc: # 4.19.x: ec665b756e6f7: backlight: gpio-backlight: Correct initial power state handling Signed-off-by: Marek Vasut Acked-by: Noralf Trønnes Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman commit c928e634b49264ec46f67b2df1c180bdd3b977e4 Author: Jack Andersen Date: Mon Oct 18 13:25:41 2021 +0200 mfd: dln2: Add cell for initializing DLN2 ADC commit 313c84b5ae4104e48c661d5d706f9f4c425fd50f upstream. This patch extends the DLN2 driver; adding cell for adc_dln2 module. The original patch[1] fell through the cracks when the driver was added so ADC has never actually been usable. That patch did not have ACPI support which was added in v5.9, so the oldest supported version this current patch can be backported to is 5.10. [1] https://www.spinics.net/lists/linux-iio/msg33975.html Cc: # 5.10+ Signed-off-by: Jack Andersen Signed-off-by: Noralf Trønnes Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211018112541.25466-1-noralf@tronnes.org Signed-off-by: Greg Kroah-Hartman commit 8d55a5f822107de618eb506f36a48a96709e4a68 Author: Michal Hocko Date: Fri Nov 5 13:38:06 2021 -0700 mm, oom: do not trigger out_of_memory from the #PF commit 60e2793d440a3ec95abb5d6d4fc034a4b480472d upstream. Any allocation failure during the #PF path will return with VM_FAULT_OOM which in turn results in pagefault_out_of_memory. This can happen for 2 different reasons. a) Memcg is out of memory and we rely on mem_cgroup_oom_synchronize to perform the memcg OOM handling or b) normal allocation fails. The latter is quite problematic because allocation paths already trigger out_of_memory and the page allocator tries really hard to not fail allocations. Anyway, if the OOM killer has been already invoked there is no reason to invoke it again from the #PF path. Especially when the OOM condition might be gone by that time and we have no way to find out other than allocate. Moreover if the allocation failed and the OOM killer hasn't been invoked then we are unlikely to do the right thing from the #PF context because we have already lost the allocation context and restictions and therefore might oom kill a task from a different NUMA domain. This all suggests that there is no legitimate reason to trigger out_of_memory from pagefault_out_of_memory so drop it. Just to be sure that no #PF path returns with VM_FAULT_OOM without allocation print a warning that this is happening before we restart the #PF. [VvS: #PF allocation can hit into limit of cgroup v1 kmem controller. This is a local problem related to memcg, however, it causes unnecessary global OOM kills that are repeated over and over again and escalate into a real disaster. This has been broken since kmem accounting has been introduced for cgroup v1 (3.8). There was no kmem specific reclaim for the separate limit so the only way to handle kmem hard limit was to return with ENOMEM. In upstream the problem will be fixed by removing the outdated kmem limit, however stable and LTS kernels cannot do it and are still affected. This patch fixes the problem and should be backported into stable/LTS.] Link: https://lkml.kernel.org/r/f5fd8dd8-0ad4-c524-5f65-920b01972a42@virtuozzo.com Signed-off-by: Michal Hocko Signed-off-by: Vasily Averin Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Mel Gorman Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tetsuo Handa Cc: Uladzislau Rezki Cc: Vladimir Davydov Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit dc6b83b8fef9db14bda5034c05cfbb00fb6e1729 Author: Vasily Averin Date: Fri Nov 5 13:38:02 2021 -0700 mm, oom: pagefault_out_of_memory: don't force global OOM for dying tasks commit 0b28179a6138a5edd9d82ad2687c05b3773c387b upstream. Patch series "memcg: prohibit unconditional exceeding the limit of dying tasks", v3. Memory cgroup charging allows killed or exiting tasks to exceed the hard limit. It can be misused and allowed to trigger global OOM from inside a memcg-limited container. On the other hand if memcg fails allocation, called from inside #PF handler it triggers global OOM from inside pagefault_out_of_memory(). To prevent these problems this patchset: (a) removes execution of out_of_memory() from pagefault_out_of_memory(), becasue nobody can explain why it is necessary. (b) allow memcg to fail allocation of dying/killed tasks. This patch (of 3): Any allocation failure during the #PF path will return with VM_FAULT_OOM which in turn results in pagefault_out_of_memory which in turn executes out_out_memory() and can kill a random task. An allocation might fail when the current task is the oom victim and there are no memory reserves left. The OOM killer is already handled at the page allocator level for the global OOM and at the charging level for the memcg one. Both have much more information about the scope of allocation/charge request. This means that either the OOM killer has been invoked properly and didn't lead to the allocation success or it has been skipped because it couldn't have been invoked. In both cases triggering it from here is pointless and even harmful. It makes much more sense to let the killed task die rather than to wake up an eternally hungry oom-killer and send him to choose a fatter victim for breakfast. Link: https://lkml.kernel.org/r/0828a149-786e-7c06-b70a-52d086818ea3@virtuozzo.com Signed-off-by: Vasily Averin Suggested-by: Michal Hocko Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Mel Gorman Cc: Roman Gushchin Cc: Shakeel Butt Cc: Tetsuo Handa Cc: Uladzislau Rezki Cc: Vladimir Davydov Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5741bd42f7c599f4b38246a7c0c267efa72b9eb7 Author: Jens Axboe Date: Sun Nov 14 07:36:47 2021 -0700 io-wq: serialize hash clear with wakeup commit d3e3c102d107bb84251455a298cf475f24bab995 upstream. We need to ensure that we serialize the stalled and hash bits with the wait_queue wait handler, or we could be racing with someone modifying the hashed state after we find it busy, but before we then give up and wait for it to be cleared. This can cause random delays or stalls when handling buffered writes for many files, where some of these files cause hash collisions between the worker threads. Cc: stable@vger.kernel.org Reported-by: Daniel Black Fixes: e941894eae31 ("io-wq: make buffered file write hashed work map per-ctx") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 9f9d088a4b7d0b6451e9cdd5225d7b192608ca38 Author: Jens Axboe Date: Tue Aug 31 13:53:00 2021 -0600 io-wq: fix queue stalling race commit 0242f6426ea78fbe3933b44f8c55ae93ec37f6cc upstream. We need to set the stalled bit early, before we drop the lock for adding us to the stall hash queue. If not, then we can race with new work being queued between adding us to the stall hash and io_worker_handle_work() marking us stalled. Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 92b69466102b456c58ae9725540013f893850b6d Author: Jens Axboe Date: Tue Aug 31 06:57:25 2021 -0600 io-wq: ensure that hash wait lock is IRQ disabling commit 08bdbd39b58474d762242e1fadb7f2eb9ffcca71 upstream. A previous commit removed the IRQ safety of the worker and wqe locks, but that left one spot of the hash wait lock now being done without already having IRQs disabled. Ensure that we use the right locking variant for the hashed waitqueue lock. Fixes: a9a4aa9fbfc5 ("io-wq: wqe and worker locks no longer need to be IRQ safe") Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 31132a895eaaa28439664ea4d70e6cc1b36f130e Author: Vasily Averin Date: Fri Nov 5 13:38:09 2021 -0700 memcg: prohibit unconditional exceeding the limit of dying tasks commit a4ebf1b6ca1e011289677239a2a361fde4a88076 upstream. Memory cgroup charging allows killed or exiting tasks to exceed the hard limit. It is assumed that the amount of the memory charged by those tasks is bound and most of the memory will get released while the task is exiting. This is resembling a heuristic for the global OOM situation when tasks get access to memory reserves. There is no global memory shortage at the memcg level so the memcg heuristic is more relieved. The above assumption is overly optimistic though. E.g. vmalloc can scale to really large requests and the heuristic would allow that. We used to have an early break in the vmalloc allocator for killed tasks but this has been reverted by commit b8c8a338f75e ("Revert "vmalloc: back off when the current task is killed""). There are likely other similar code paths which do not check for fatal signals in an allocation&charge loop. Also there are some kernel objects charged to a memcg which are not bound to a process life time. It has been observed that it is not really hard to trigger these bypasses and cause global OOM situation. One potential way to address these runaways would be to limit the amount of excess (similar to the global OOM with limited oom reserves). This is certainly possible but it is not really clear how much of an excess is desirable and still protects from global OOMs as that would have to consider the overall memcg configuration. This patch is addressing the problem by removing the heuristic altogether. Bypass is only allowed for requests which either cannot fail or where the failure is not desirable while excess should be still limited (e.g. atomic requests). Implementation wise a killed or dying task fails to charge if it has passed the OOM killer stage. That should give all forms of reclaim chance to restore the limit before the failure (ENOMEM) and tell the caller to back off. In addition, this patch renames should_force_charge() helper to task_is_dying() because now its use is not associated witch forced charging. This patch depends on pagefault_out_of_memory() to not trigger out_of_memory(), because then a memcg failure can unwind to VM_FAULT_OOM and cause a global OOM killer. Link: https://lkml.kernel.org/r/8f5cebbb-06da-4902-91f0-6566fc4b4203@virtuozzo.com Signed-off-by: Vasily Averin Suggested-by: Michal Hocko Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Vladimir Davydov Cc: Roman Gushchin Cc: Uladzislau Rezki Cc: Vlastimil Babka Cc: Shakeel Butt Cc: Mel Gorman Cc: Tetsuo Handa Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d3a14035e51b86b637ff7b7a3a8b8ad338d160aa Author: Matthew Wilcox (Oracle) Date: Fri Nov 5 13:37:10 2021 -0700 mm/filemap.c: remove bogus VM_BUG_ON commit d417b49fff3e2f21043c834841e8623a6098741d upstream. It is not safe to check page->index without holding the page lock. It can be changed if the page is moved between the swap cache and the page cache for a shmem file, for example. There is a VM_BUG_ON below which checks page->index is correct after taking the page lock. Link: https://lkml.kernel.org/r/20210818144932.940640-1-willy@infradead.org Fixes: 5c211ba29deb ("mm: add and use find_lock_entries") Signed-off-by: Matthew Wilcox (Oracle) Reported-by: Cc: Hugh Dickins Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4546a8cb993c13b0fafd0eb7f68973675851f3da Author: Dominique Martinet Date: Tue Nov 2 19:47:47 2021 +0900 9p/net: fix missing error check in p9_check_errors commit 27eb4c3144f7a5ebef3c9a261d80cb3e1fa784dc upstream. Link: https://lkml.kernel.org/r/99338965-d36c-886e-cd0e-1d8fff2b4746@gmail.com Reported-by: syzbot+06472778c97ed94af66d@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Dominique Martinet Signed-off-by: Greg Kroah-Hartman commit 2febd1914ddcd5b0dd851e02a5aced08977ff205 Author: Daniel Borkmann Date: Mon Sep 27 14:39:20 2021 +0200 bpf, cgroup: Assign cgroup in cgroup_sk_alloc when called from interrupt [ Upstream commit 78cc316e9583067884eb8bd154301dc1e9ee945c ] If cgroup_sk_alloc() is called from interrupt context, then just assign the root cgroup to skcd->cgroup. Prior to commit 8520e224f547 ("bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode") we would just return, and later on in sock_cgroup_ptr(), we were NULL-testing the cgroup in fast-path, and iff indeed NULL returning the root cgroup (v ?: &cgrp_dfl_root.cgrp). Rather than re-adding the NULL-test to the fast-path we can just assign it once from cgroup_sk_alloc() given v1/v2 handling has been simplified. The migration from NULL test with returning &cgrp_dfl_root.cgrp to assigning &cgrp_dfl_root.cgrp directly does /not/ change behavior for callers of sock_cgroup_ptr(). syzkaller was able to trigger a splat in the legacy netrom code base, where the RX handler in nr_rx_frame() calls nr_make_new() which calls sk_alloc() and therefore cgroup_sk_alloc() with in_interrupt() condition. Thus the NULL skcd->cgroup, where it trips over on cgroup_sk_free() side given it expects a non-NULL object. There are a few other candidates aside from netrom which have similar pattern where in their accept-like implementation, they just call to sk_alloc() and thus cgroup_sk_alloc() instead of sk_clone_lock() with the corresponding cgroup_sk_clone() which then inherits the cgroup from the parent socket. None of them are related to core protocols where BPF cgroup programs are running from. However, in future, they should follow to implement a similar inheritance mechanism. Additionally, with a !CONFIG_CGROUP_NET_PRIO and !CONFIG_CGROUP_NET_CLASSID configuration, the same issue was exposed also prior to 8520e224f547 due to commit e876ecc67db8 ("cgroup: memcg: net: do not associate sock with unrelated cgroup") which added the early in_interrupt() return back then. Fixes: 8520e224f547 ("bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode") Fixes: e876ecc67db8 ("cgroup: memcg: net: do not associate sock with unrelated cgroup") Reported-by: syzbot+df709157a4ecaf192b03@syzkaller.appspotmail.com Reported-by: syzbot+533f389d4026d86a2a95@syzkaller.appspotmail.com Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Tested-by: syzbot+df709157a4ecaf192b03@syzkaller.appspotmail.com Tested-by: syzbot+533f389d4026d86a2a95@syzkaller.appspotmail.com Acked-by: Tejun Heo Link: https://lore.kernel.org/bpf/20210927123921.21535-1-daniel@iogearbox.net Signed-off-by: Sasha Levin commit 72c0c32d9dde19751cf7380c215cd80fb8fcafb6 Author: Daniel Borkmann Date: Tue Sep 14 01:07:57 2021 +0200 bpf, cgroups: Fix cgroup v2 fallback on v1/v2 mixed mode [ Upstream commit 8520e224f547cd070c7c8f97b1fc6d58cff7ccaa ] Fix cgroup v1 interference when non-root cgroup v2 BPF programs are used. Back in the days, commit bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup") embedded per-socket cgroup information into sock->sk_cgrp_data and in order to save 8 bytes in struct sock made both mutually exclusive, that is, when cgroup v1 socket tagging (e.g. net_cls/net_prio) is used, then cgroup v2 falls back to the root cgroup in sock_cgroup_ptr() (&cgrp_dfl_root.cgrp). The assumption made was "there is no reason to mix the two and this is in line with how legacy and v2 compatibility is handled" as stated in bd1060a1d671. However, with Kubernetes more widely supporting cgroups v2 as well nowadays, this assumption no longer holds, and the possibility of the v1/v2 mixed mode with the v2 root fallback being hit becomes a real security issue. Many of the cgroup v2 BPF programs are also used for policy enforcement, just to pick _one_ example, that is, to programmatically deny socket related system calls like connect(2) or bind(2). A v2 root fallback would implicitly cause a policy bypass for the affected Pods. In production environments, we have recently seen this case due to various circumstances: i) a different 3rd party agent and/or ii) a container runtime such as [0] in the user's environment configuring legacy cgroup v1 net_cls tags, which triggered implicitly mentioned root fallback. Another case is Kubernetes projects like kind [1] which create Kubernetes nodes in a container and also add cgroup namespaces to the mix, meaning programs which are attached to the cgroup v2 root of the cgroup namespace get attached to a non-root cgroup v2 path from init namespace point of view. And the latter's root is out of reach for agents on a kind Kubernetes node to configure. Meaning, any entity on the node setting cgroup v1 net_cls tag will trigger the bypass despite cgroup v2 BPF programs attached to the namespace root. Generally, this mutual exclusiveness does not hold anymore in today's user environments and makes cgroup v2 usage from BPF side fragile and unreliable. This fix adds proper struct cgroup pointer for the cgroup v2 case to struct sock_cgroup_data in order to address these issues; this implicitly also fixes the tradeoffs being made back then with regards to races and refcount leaks as stated in bd1060a1d671, and removes the fallback, so that cgroup v2 BPF programs always operate as expected. [0] https://github.com/nestybox/sysbox/ [1] https://kind.sigs.k8s.io/ Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup") Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Acked-by: Stanislav Fomichev Acked-by: Tejun Heo Link: https://lore.kernel.org/bpf/20210913230759.2313-1-daniel@iogearbox.net Signed-off-by: Sasha Levin commit 06cf324a465a9e1ff9535961804ba520d61efb91 Author: Daniel Borkmann Date: Mon Oct 11 14:12:36 2021 +0200 net, neigh: Enable state migration between NUD_PERMANENT and NTF_USE [ Upstream commit 3dc20f4762c62d3b3f0940644881ed818aa7b2f5 ] Currently, it is not possible to migrate a neighbor entry between NUD_PERMANENT state and NTF_USE flag with a dynamic NUD state from a user space control plane. Similarly, it is not possible to add/remove NTF_EXT_LEARNED flag from an existing neighbor entry in combination with NTF_USE flag. This is due to the latter directly calling into neigh_event_send() without any meta data updates as happening in __neigh_update(). Thus, to enable this use case, extend the latter with a NEIGH_UPDATE_F_USE flag where we break the NUD_PERMANENT state in particular so that a latter neigh_event_send() is able to re-resolve a neighbor entry. Before fix, NUD_PERMANENT -> NUD_* & NTF_USE: # ./ip/ip n replace 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT [...] # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT [...] As can be seen, despite the admin-triggered replace, the entry remains in the NUD_PERMANENT state. After fix, NUD_PERMANENT -> NUD_* & NTF_USE: # ./ip/ip n replace 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT [...] # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE [...] # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn STALE [...] # ./ip/ip n replace 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a PERMANENT [...] After the fix, the admin-triggered replace switches to a dynamic state from the NTF_USE flag which triggered a new neighbor resolution. Likewise, we can transition back from there, if needed, into NUD_PERMANENT. Similar before/after behavior can be observed for below transitions: Before fix, NTF_USE -> NTF_USE | NTF_EXT_LEARNED -> NTF_USE: # ./ip/ip n replace 192.168.178.30 dev enp5s0 use # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE [...] # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE [...] After fix, NTF_USE -> NTF_USE | NTF_EXT_LEARNED -> NTF_USE: # ./ip/ip n replace 192.168.178.30 dev enp5s0 use # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE [...] # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE [...] # ./ip/ip n replace 192.168.178.30 dev enp5s0 use # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE [..] Signed-off-by: Daniel Borkmann Acked-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 515cfde2a028487ed7da78ecf73689c336eb67fa Author: Anatolij Gustschin Date: Thu Oct 14 11:40:12 2021 +0200 dmaengine: bestcomm: fix system boot lockups commit adec566b05288f2787a1f88dbaf77ed8b0c644fa upstream. memset() and memcpy() on an MMIO region like here results in a lockup at startup on mpc5200 platform (since this first happens during probing of the ATA and Ethernet drivers). Use memset_io() and memcpy_toio() instead. Fixes: 2f9ea1bde0d1 ("bestcomm: core bestcomm support for Freescale MPC5200") Cc: stable@vger.kernel.org # v5.14+ Signed-off-by: Anatolij Gustschin Link: https://lore.kernel.org/r/20211014094012.21286-1-agust@denx.de Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 3f5e4b70cd7a3a7860575d6065ebe05910798f1f Author: Kishon Vijay Abraham I Date: Sun Oct 31 08:54:11 2021 +0530 dmaengine: ti: k3-udma: Set r/tchan or rflow to NULL if request fail commit eb91224e47ec33a0a32c9be0ec0fcb3433e555fd upstream. udma_get_*() checks if rchan/tchan/rflow is already allocated by checking if it has a NON NULL value. For the error cases, rchan/tchan/rflow will have error value and udma_get_*() considers this as already allocated (PASS) since the error values are NON NULL. This results in NULL pointer dereference error while de-referencing rchan/tchan/rflow. Reset the value of rchan/tchan/rflow to NULL if a channel request fails. CC: stable@vger.kernel.org Acked-by: Peter Ujfalusi Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20211031032411.27235-3-kishon@ti.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 3a127ccaf9a0db788ccd8b2af680eb5ab4f3fdbc Author: Kishon Vijay Abraham I Date: Sun Oct 31 08:54:10 2021 +0530 dmaengine: ti: k3-udma: Set bchan to NULL if a channel request fail commit 5c6c6d60e4b489308ae4da8424c869f7cc53cd12 upstream. bcdma_get_*() checks if bchan is already allocated by checking if it has a NON NULL value. For the error cases, bchan will have error value and bcdma_get_*() considers this as already allocated (PASS) since the error values are NON NULL. This results in NULL pointer dereference error while de-referencing bchan. Reset the value of bchan to NULL if a channel request fails. CC: stable@vger.kernel.org Acked-by: Peter Ujfalusi Signed-off-by: Kishon Vijay Abraham I Link: https://lore.kernel.org/r/20211031032411.27235-2-kishon@ti.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 2f9e6bcab0a16fed151d88b5c6e48ca48280d741 Author: Gao Xiang Date: Thu Nov 4 02:20:06 2021 +0800 erofs: fix unsafe pagevec reuse of hooked pclusters commit 86432a6dca9bed79111990851df5756d3eb5f57c upstream. There are pclusters in runtime marked with Z_EROFS_PCLUSTER_TAIL before actual I/O submission. Thus, the decompression chain can be extended if the following pcluster chain hooks such tail pcluster. As the related comment mentioned, if some page is made of a hooked pcluster and another followed pcluster, it can be reused for in-place I/O (since I/O should be submitted anyway): _______________________________________________________________ | tail (partial) page | head (partial) page | |_____PRIMARY_HOOKED___|____________PRIMARY_FOLLOWED____________| However, it's by no means safe to reuse as pagevec since if such PRIMARY_HOOKED pclusters finally move into bypass chain without I/O submission. It's somewhat hard to reproduce with LZ4 and I just found it (general protection fault) by ro_fsstressing a LZMA image for long time. I'm going to actively clean up related code together with multi-page folio adaption in the next few months. Let's address it directly for easier backporting for now. Call trace for reference: z_erofs_decompress_pcluster+0x10a/0x8a0 [erofs] z_erofs_decompress_queue.isra.36+0x3c/0x60 [erofs] z_erofs_runqueue+0x5f3/0x840 [erofs] z_erofs_readahead+0x1e8/0x320 [erofs] read_pages+0x91/0x270 page_cache_ra_unbounded+0x18b/0x240 filemap_get_pages+0x10a/0x5f0 filemap_read+0xa9/0x330 new_sync_read+0x11b/0x1a0 vfs_read+0xf1/0x190 Link: https://lore.kernel.org/r/20211103182006.4040-1-xiang@kernel.org Fixes: 3883a79abd02 ("staging: erofs: introduce VLE decompression support") Cc: # 4.19+ Reviewed-by: Chao Yu Signed-off-by: Gao Xiang Signed-off-by: Greg Kroah-Hartman commit 5b67adb7425e758655e464bda4eb4174ac88b625 Author: Dongliang Mu Date: Thu Nov 4 16:22:01 2021 +0800 f2fs: fix UAF in f2fs_available_free_memory commit 5429c9dbc9025f9a166f64e22e3a69c94fd5b29b upstream. if2fs_fill_super -> f2fs_build_segment_manager -> create_discard_cmd_control -> f2fs_start_discard_thread It invokes kthread_run to create a thread and run issue_discard_thread. However, if f2fs_build_node_manager fails, the control flow goes to free_nm and calls f2fs_destroy_node_manager. This function will free sbi->nm_info. However, if issue_discard_thread accesses sbi->nm_info after the deallocation, but before the f2fs_stop_discard_thread, it will cause UAF(Use-after-free). -> f2fs_destroy_segment_manager -> destroy_discard_cmd_control -> f2fs_stop_discard_thread Fix this by stopping discard thread before f2fs_destroy_node_manager. Note that, the commit d6d2b491a82e1 introduces the call of f2fs_available_free_memory into issue_discard_thread. Cc: stable@vger.kernel.org Fixes: d6d2b491a82e ("f2fs: allow to change discard policy based on cached discard cmds") Signed-off-by: Dongliang Mu Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 616c1311b0f32d904a05fecd979b9c80351b7c37 Author: Daeho Jeong Date: Wed Oct 6 10:49:10 2021 -0700 f2fs: include non-compressed blocks in compr_written_block commit 09631cf3234d32156e7cae32275f5a4144c683c5 upstream. Need to include non-compressed blocks in compr_written_block to estimate average compression ratio more accurately. Fixes: 5ac443e26a09 ("f2fs: add sysfs nodes to get runtime compression stat") Cc: stable@vger.kernel.org Signed-off-by: Daeho Jeong Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 25b7077e30eed17c05cc73272d7e2e026ee20f34 Author: Jaegeuk Kim Date: Tue Sep 7 10:24:21 2021 -0700 f2fs: should use GFP_NOFS for directory inodes commit 92d602bc7177325e7453189a22e0c8764ed3453e upstream. We use inline_dentry which requires to allocate dentry page when adding a link. If we allow to reclaim memory from filesystem, we do down_read(&sbi->cp_rwsem) twice by f2fs_lock_op(). I think this should be okay, but how about stopping the lockdep complaint [1]? f2fs_create() - f2fs_lock_op() - f2fs_do_add_link() - __f2fs_find_entry - f2fs_get_read_data_page() -> kswapd - shrink_node - f2fs_evict_inode - f2fs_lock_op() [1] fs_reclaim ){+.+.}-{0:0} : kswapd0: lock_acquire+0x114/0x394 kswapd0: __fs_reclaim_acquire+0x40/0x50 kswapd0: prepare_alloc_pages+0x94/0x1ec kswapd0: __alloc_pages_nodemask+0x78/0x1b0 kswapd0: pagecache_get_page+0x2e0/0x57c kswapd0: f2fs_get_read_data_page+0xc0/0x394 kswapd0: f2fs_find_data_page+0xa4/0x23c kswapd0: find_in_level+0x1a8/0x36c kswapd0: __f2fs_find_entry+0x70/0x100 kswapd0: f2fs_do_add_link+0x84/0x1ec kswapd0: f2fs_mkdir+0xe4/0x1e4 kswapd0: vfs_mkdir+0x110/0x1c0 kswapd0: do_mkdirat+0xa4/0x160 kswapd0: __arm64_sys_mkdirat+0x24/0x34 kswapd0: el0_svc_common.llvm.17258447499513131576+0xc4/0x1e8 kswapd0: do_el0_svc+0x28/0xa0 kswapd0: el0_svc+0x24/0x38 kswapd0: el0_sync_handler+0x88/0xec kswapd0: el0_sync+0x1c0/0x200 kswapd0: -> #1 ( &sbi->cp_rwsem ){++++}-{3:3} : kswapd0: lock_acquire+0x114/0x394 kswapd0: down_read+0x7c/0x98 kswapd0: f2fs_do_truncate_blocks+0x78/0x3dc kswapd0: f2fs_truncate+0xc8/0x128 kswapd0: f2fs_evict_inode+0x2b8/0x8b8 kswapd0: evict+0xd4/0x2f8 kswapd0: iput+0x1c0/0x258 kswapd0: do_unlinkat+0x170/0x2a0 kswapd0: __arm64_sys_unlinkat+0x4c/0x68 kswapd0: el0_svc_common.llvm.17258447499513131576+0xc4/0x1e8 kswapd0: do_el0_svc+0x28/0xa0 kswapd0: el0_svc+0x24/0x38 kswapd0: el0_sync_handler+0x88/0xec kswapd0: el0_sync+0x1c0/0x200 Cc: stable@vger.kernel.org Fixes: bdbc90fa55af ("f2fs: don't put dentry page in pagecache into highmem") Reviewed-by: Chao Yu Reviewed-by: Stanley Chu Reviewed-by: Light Hsieh Tested-by: Light Hsieh Signed-off-by: Jaegeuk Kim Signed-off-by: Greg Kroah-Hartman commit 29868ae1478fe18231672da94c4e862a03218a25 Author: Guo Ren Date: Fri Nov 5 17:47:48 2021 +0800 irqchip/sifive-plic: Fixup EOI failed when masked commit 69ea463021be0d159ab30f96195fb0dd18ee2272 upstream. When using "devm_request_threaded_irq(,,,,IRQF_ONESHOT,,)" in a driver, only the first interrupt is handled, and following interrupts are never delivered (initially reported in [1]). That's because the RISC-V PLIC cannot EOI masked interrupts, as explained in the description of Interrupt Completion in the PLIC spec [2]: The PLIC signals it has completed executing an interrupt handler by writing the interrupt ID it received from the claim to the claim/complete register. The PLIC does not check whether the completion ID is the same as the last claim ID for that target. If the completion ID does not match an interrupt source that *is currently enabled* for the target, the completion is silently ignored. Re-enable the interrupt before completion if it has been masked during the handling, and remask it afterwards. [1] http://lists.infradead.org/pipermail/linux-riscv/2021-July/007441.html [2] https://github.com/riscv/riscv-plic-spec/blob/8bc15a35d07c9edf7b5d23fec9728302595ffc4d/riscv-plic.adoc Fixes: bb0fed1c60cc ("irqchip/sifive-plic: Switch to fasteoi flow") Reported-by: Vincent Pelletier Tested-by: Nikita Shubin Signed-off-by: Guo Ren Cc: stable@vger.kernel.org Cc: Thomas Gleixner Cc: Palmer Dabbelt Cc: Atish Patra Reviewed-by: Anup Patel [maz: amended commit message] Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211105094748.3894453-1-guoren@kernel.org Signed-off-by: Greg Kroah-Hartman commit 1bf2fc90b15b3c4fe2db4bc9f1445df9b8aec68e Author: Michael Pratt Date: Mon Nov 1 17:06:15 2021 -0400 posix-cpu-timers: Clear task::posix_cputimers_work in copy_process() commit ca7752caeaa70bd31d1714af566c9809688544af upstream. copy_process currently copies task_struct.posix_cputimers_work as-is. If a timer interrupt arrives while handling clone and before dup_task_struct completes then the child task will have: 1. posix_cputimers_work.scheduled = true 2. posix_cputimers_work.work queued. copy_process clears task_struct.task_works, so (2) will have no effect and posix_cpu_timers_work will never run (not to mention it doesn't make sense for two tasks to share a common linked list). Since posix_cpu_timers_work never runs, posix_cputimers_work.scheduled is never cleared. Since scheduled is set, future timer interrupts will skip scheduling work, with the ultimate result that the task will never receive timer expirations. Together, the complete flow is: 1. Task 1 calls clone(), enters kernel. 2. Timer interrupt fires, schedules task work on Task 1. 2a. task_struct.posix_cputimers_work.scheduled = true 2b. task_struct.posix_cputimers_work.work added to task_struct.task_works. 3. dup_task_struct() copies Task 1 to Task 2. 4. copy_process() clears task_struct.task_works for Task 2. 5. Future timer interrupts on Task 2 see task_struct.posix_cputimers_work.scheduled = true and skip scheduling work. Fix this by explicitly clearing contents of task_struct.posix_cputimers_work in copy_process(). This was never meant to be shared or inherited across tasks in the first place. Fixes: 1fb497dd0030 ("posix-cpu-timers: Provide mechanisms to defer timer handling to task_work") Reported-by: Rhys Hiltner Signed-off-by: Michael Pratt Signed-off-by: Thomas Gleixner Cc: Link: https://lore.kernel.org/r/20211101210615.716522-1-mpratt@google.com Signed-off-by: Greg Kroah-Hartman commit f7ece74d0ab21a2c336abaf2dc4039d633ab17d5 Author: Paolo Bonzini Date: Fri Nov 12 02:53:41 2021 -0500 KVM: x86: move guest_pv_has out of user_access section commit 3e067fd8503d6205aa0c1c8f48f6b209c592d19c upstream. When UBSAN is enabled, the code emitted for the call to guest_pv_has includes a call to __ubsan_handle_load_invalid_value. objtool complains that this call happens with UACCESS enabled; to avoid the warning, pull the calls to user_access_begin into both arms of the "if" statement, after the check for guest_pv_has. Reported-by: Stephen Rothwell Cc: David Woodhouse Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 4c09233d17ceaf6ecb2d6e20aafc6401ce0efcce Author: Dave Jones Date: Fri Oct 29 16:57:59 2021 -0400 x86/mce: Add errata workaround for Skylake SKX37 commit e629fc1407a63dbb748f828f9814463ffc2a0af0 upstream. Errata SKX37 is word-for-word identical to the other errata listed in this workaround. I happened to notice this after investigating a CMCI storm on a Skylake host. While I can't confirm this was the root cause, spurious corrected errors does sound like a likely suspect. Fixes: 2976908e4198 ("x86/mce: Do not log spurious corrected mce errors") Signed-off-by: Dave Jones Signed-off-by: Dave Hansen Reviewed-by: Tony Luck Cc: Link: https://lkml.kernel.org/r/20211029205759.GA7385@codemonkey.org.uk Signed-off-by: Greg Kroah-Hartman commit e95e07bab005682d2bf0e26cd0d009b18837abfe Author: Maciej W. Rozycki Date: Fri Oct 22 00:58:23 2021 +0200 MIPS: Fix assembly error from MIPSr2 code used within MIPS_ISA_ARCH_LEVEL commit a923a2676e60683aee46aa4b93c30aff240ac20d upstream. Fix assembly errors like: {standard input}: Assembler messages: {standard input}:287: Error: opcode not supported on this processor: mips3 (mips3) `dins $10,$7,32,32' {standard input}:680: Error: opcode not supported on this processor: mips3 (mips3) `dins $10,$7,32,32' {standard input}:1274: Error: opcode not supported on this processor: mips3 (mips3) `dins $12,$9,32,32' {standard input}:2175: Error: opcode not supported on this processor: mips3 (mips3) `dins $10,$7,32,32' make[1]: *** [scripts/Makefile.build:277: mm/highmem.o] Error 1 with code produced from `__cmpxchg64' for MIPS64r2 CPU configurations using CONFIG_32BIT and CONFIG_PHYS_ADDR_T_64BIT. This is due to MIPS_ISA_ARCH_LEVEL downgrading the assembly architecture to `r4000' i.e. MIPS III for MIPS64r2 configurations, while there is a block of code containing a DINS MIPS64r2 instruction conditionalized on MIPS_ISA_REV >= 2 within the scope of the downgrade. The assembly architecture override code pattern has been put there for LL/SC instructions, so that code compiles for configurations that select a processor to build for that does not support these instructions while still providing run-time support for processors that do, dynamically switched by non-constant `cpu_has_llsc'. It went in with linux-mips.org commit aac8aa7717a2 ("Enable a suitable ISA for the assembler around ll/sc so that code builds even for processors that don't support the instructions. Plus minor formatting fixes.") back in 2005. Fix the problem by wrapping these instructions along with the adjacent SYNC instructions only, following the practice established with commit cfd54de3b0e4 ("MIPS: Avoid move psuedo-instruction whilst using MIPS_ISA_LEVEL") and commit 378ed6f0e3c5 ("MIPS: Avoid using .set mips0 to restore ISA"). Strictly speaking the SYNC instructions do not have to be wrapped as they are only used as a Loongson3 erratum workaround, so they will be enabled in the assembler by default, but do this so as to keep code consistent with other places. Reported-by: kernel test robot Signed-off-by: Maciej W. Rozycki Fixes: c7e2d71dda7a ("MIPS: Fix set_pte() for Netlogic XLR using cmpxchg64()") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 70eeeb5aa01a8a3982db2b5bd59ffcab7562a4cc Author: Masahiro Yamada Date: Wed Nov 10 00:01:46 2021 +0900 MIPS: fix duplicated slashes for Platform file path commit cca2aac8acf470b01066f559acd7146fc4c32ae8 upstream. platform-y accumulates platform names with a slash appended. The current $(patsubst ...) ends up with doubling slashes. GNU Make still include Platform files, but in case of an error, a clumsy file path is displayed: arch/mips/loongson2ef//Platform:36: *** only binutils >= 2.20.2 have needed option -mfix-loongson2f-nop. Stop. Signed-off-by: Masahiro Yamada Signed-off-by: Thomas Bogendoerfer Signed-off-by: Jason Self Signed-off-by: Greg Kroah-Hartman commit 1eed13f0aba93b6bb9baa53cf9dce4eabbdef2a7 Author: John David Anglin Date: Mon Nov 8 16:48:16 2021 -0500 parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page commit 38860b2c8bb1b92f61396eb06a63adff916fc31d upstream. For years, there have been random segmentation faults in userspace on SMP PA-RISC machines. It occurred to me that this might be a problem in set_pte_at(). MIPS and some other architectures do cache flushes when installing PTEs with the present bit set. Here I have adapted the code in update_mmu_cache() to flush the kernel mapping when the kernel flush is deferred, or when the kernel mapping may alias with the user mapping. This simplifies calls to update_mmu_cache(). I also changed the barrier in set_pte() from a compiler barrier to a full memory barrier. I know this change is not sufficient to fix the problem. It might not be needed. I have had a few days of operation with 5.14.16 to 5.15.1 and haven't seen any random segmentation faults on rp3440 or c8000 so far. Signed-off-by: John David Anglin Signed-off-by: Helge Deller Cc: stable@kernel.org # 5.12+ Signed-off-by: Greg Kroah-Hartman commit 1a396e845df7318514d39e819514112143fbe1bf Author: Helge Deller Date: Thu Nov 4 20:19:00 2021 +0100 parisc: Fix backtrace to always include init funtion names commit 279917e27edc293eb645a25428c6ab3f3bca3f86 upstream. I noticed that sometimes at kernel startup the backtraces did not included the function names of init functions. Their address were not resolved to function names and instead only the address was printed. Debugging shows that the culprit is is_ksym_addr() which is called by the backtrace functions to check if an address belongs to a function in the kernel. The problem occurs only for CONFIG_KALLSYMS_ALL=y. When looking at is_ksym_addr() one can see that for CONFIG_KALLSYMS_ALL=y the function only tries to resolve the address via is_kernel() function, which checks like this: if (addr >= _stext && addr <= _end) return 1; On parisc the init functions are located before _stext, so this check fails. Other platforms seem to have all functions (including init functions) behind _stext. The following patch moves the _stext symbol at the beginning of the kernel and thus includes the init section. This fixes the check and does not seem to have any negative side effects on where the kernel mapping happens in the map_pages() function in arch/parisc/mm/init.c. Signed-off-by: Helge Deller Cc: stable@kernel.org # 5.4+ Signed-off-by: Greg Kroah-Hartman commit b30255c8e2dde0faa7279cf89bcca074862e305a Author: Arnd Bergmann Date: Sat Nov 6 19:42:29 2021 +0100 ARM: 9156/1: drop cc-option fallbacks for architecture selection commit 418ace9992a7647c446ed3186df40cf165b67298 upstream. Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU: cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works. The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'. The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those. This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Reported-by: Antonio Terceiro Reported-by: Naresh Kamboju Reported-by: Sebastian Andrzej Siewior Tested-by: Sebastian Reichel Tested-by: Klaus Kudielka Cc: Matthias Klose Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit a39c9f2ff126a31a73ac46082f3618d47aa67c6e Author: Michał Mirosław Date: Thu Nov 4 17:28:28 2021 +0100 ARM: 9155/1: fix early early_iounmap() commit 0d08e7bf0d0d1a29aff7b16ef516f7415eb1aa05 upstream. Currently __set_fixmap() bails out with a warning when called in early boot from early_iounmap(). Fix it, and while at it, make the comment a bit easier to understand. Cc: Fixes: b089c31c519c ("ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap") Acked-by: Ard Biesheuvel Signed-off-by: Michał Mirosław Signed-off-by: Russell King (Oracle) Signed-off-by: Greg Kroah-Hartman commit a6e210f38fd996ece0f86caeb7bab992c3934b03 Author: Steve French Date: Wed Nov 10 01:47:48 2021 -0600 smb3: do not error on fsync when readonly commit 71e6864eacbef0b2645ca043cdfbac272cb6cea3 upstream. Linux allows doing a flush/fsync on a file open for read-only, but the protocol does not allow that. If the file passed in on the flush is read-only try to find a writeable handle for the same inode, if that is not possible skip sending the fsync call to the server to avoid breaking the apps. Reported-by: Julian Sikorski Tested-by: Julian Sikorski Suggested-by: Jeremy Allison Reviewed-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 05f3204178239aa629edbad650cd21c1e683beae Author: Willem de Bruijn Date: Thu Nov 11 06:57:17 2021 -0500 selftests/net: udpgso_bench_rx: fix port argument [ Upstream commit d336509cb9d03970911878bb77f0497f64fda061 ] The below commit added optional support for passing a bind address. It configures the sockaddr bind arguments before parsing options and reconfigures on options -b and -4. This broke support for passing port (-p) on its own. Configure sockaddr after parsing all arguments. Fixes: 3327a9c46352 ("selftests: add functionals test for UDP GRO") Reported-by: Eric Dumazet Signed-off-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 36810c9fc743c41ca3e5389294c61cf5e5974a04 Author: Rahul Lakkireddy Date: Thu Nov 11 15:55:16 2021 +0530 cxgb4: fix eeprom len when diagnostics not implemented [ Upstream commit 4ca110bf8d9b31a60f8f8ff6706ea147d38ad97c ] Ensure diagnostics monitoring support is implemented for the SFF 8472 compliant port module and set the correct length for ethtool port module eeprom read. Fixes: f56ec6766dcf ("cxgb4: Add support for ethtool i2c dump") Signed-off-by: Manoj Malviya Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f9a2f543823f24fbdf6223a5abd2dcb6a493346e Author: Dust Li Date: Wed Nov 10 15:02:34 2021 +0800 net/smc: fix sk_refcnt underflow on linkdown and fallback [ Upstream commit e5d5aadcf3cd59949316df49c27cb21788d7efe4 ] We got the following WARNING when running ab/nginx test with RDMA link flapping (up-down-up). The reason is when smc_sock fallback and at linkdown happens simultaneously, we may got the following situation: __smc_lgr_terminate() --> smc_conn_kill() --> smc_close_active_abort() smc_sock->sk_state = SMC_CLOSED sock_put(smc_sock) smc_sock was set to SMC_CLOSED and sock_put() been called when terminate the link group. But later application call close() on the socket, then we got: __smc_release(): if (smc_sock->fallback) smc_sock->sk_state = SMC_CLOSED sock_put(smc_sock) Again we set the smc_sock to CLOSED through it's already in CLOSED state, and double put the refcnt, so the following warning happens: refcount_t: underflow; use-after-free. WARNING: CPU: 5 PID: 860 at lib/refcount.c:28 refcount_warn_saturate+0x8d/0xf0 Modules linked in: CPU: 5 PID: 860 Comm: nginx Not tainted 5.10.46+ #403 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014 RIP: 0010:refcount_warn_saturate+0x8d/0xf0 Code: 05 5c 1e b5 01 01 e8 52 25 bc ff 0f 0b c3 80 3d 4f 1e b5 01 00 75 ad 48 RSP: 0018:ffffc90000527e50 EFLAGS: 00010286 RAX: 0000000000000026 RBX: ffff8881300df2c0 RCX: 0000000000000027 RDX: 0000000000000000 RSI: ffff88813bd58040 RDI: ffff88813bd58048 RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000001 R10: ffff8881300df2c0 R11: ffffc90000527c78 R12: ffff8881300df340 R13: ffff8881300df930 R14: ffff88810b3dad80 R15: ffff8881300df4f8 FS: 00007f739de8fb80(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000a01b008 CR3: 0000000111b64003 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: smc_release+0x353/0x3f0 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x93/0x230 task_work_run+0x65/0xa0 exit_to_user_mode_prepare+0xf9/0x100 syscall_exit_to_user_mode+0x27/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This patch adds check in __smc_release() to make sure we won't do an extra sock_put() and set the socket to CLOSED when its already in CLOSED state. Fixes: 51f1de79ad8e (net/smc: replace sock_put worker by socket refcounting) Signed-off-by: Dust Li Reviewed-by: Tony Lu Signed-off-by: Dust Li Acked-by: Karsten Graul Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eedcf3fb5e61aff7072355bf9c43343bb7d6d23a Author: Eiichi Tsukata Date: Tue Nov 9 00:15:02 2021 +0000 vsock: prevent unnecessary refcnt inc for nonblocking connect [ Upstream commit c7cd82b90599fa10915f41e3dd9098a77d0aa7b6 ] Currently vosck_connect() increments sock refcount for nonblocking socket each time it's called, which can lead to memory leak if it's called multiple times because connect timeout function decrements sock refcount only once. Fixes it by making vsock_connect() return -EALREADY immediately when sock state is already SS_CONNECTING. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Reviewed-by: Stefano Garzarella Signed-off-by: Eiichi Tsukata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ed5ac8bf1dbd7099fad837c0813c44fdb485420b Author: Marek Behún Date: Mon Nov 8 22:49:18 2021 +0100 net: marvell: mvpp2: Fix wrong SerDes reconfiguration order [ Upstream commit bb7bbb6e36474933540c24ae1f1ad651b843981f ] Commit bfe301ebbc94 ("net: mvpp2: convert to use mac_prepare()/mac_finish()") introduced a bug wherein it leaves the MAC RESET register asserted after mac_finish(), due to wrong order of function calls. Before it was: .mac_config() mvpp22_mode_reconfigure() assert reset mvpp2_xlg_config() deassert reset Now it is: .mac_prepare() .mac_config() mvpp2_xlg_config() deassert reset .mac_finish() mvpp2_xlg_config() assert reset Obviously this is wrong. This bug is triggered when phylink tries to change the PHY interface mode from a GMAC mode (sgmii, 1000base-x, 2500base-x) to XLG mode (10gbase-r, xaui). The XLG mode does not work since reset is left asserted. Only after ifconfig down && ifconfig up is called will the XLG mode work. Move the call to mvpp22_mode_reconfigure() to .mac_prepare() implementation. Since some of the subsequent functions need to know whether the interface is being changed, we unfortunately also need to pass around the new interface mode before setting port->phy_interface. Fixes: bfe301ebbc94 ("net: mvpp2: convert to use mac_prepare()/mac_finish()") Signed-off-by: Marek Behún Signed-off-by: Russell King (Oracle) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e2abbf7dea22bf2b388771f8e9772a80e405fbb4 Author: Christophe JAILLET Date: Mon Nov 8 22:28:55 2021 +0100 net: ethernet: ti: cpsw_ale: Fix access to un-initialized memory [ Upstream commit 7a166854b4e24c57d56b3eba9fe1594985ee0a2c ] It is spurious to allocate a bitmap without initializing it. So, better safe than sorry, initialize it to 0 at least to have some known values. While at it, switch to the devm_bitmap_ API which is less verbose. Fixes: 4b41d3436796 ("net: ethernet: ti: cpsw: allow untagged traffic on host port") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d2d62615396fa96fc8d520c8fe0ddd29f18b753b Author: Vladimir Oltean Date: Mon Nov 8 22:28:54 2021 +0200 net: stmmac: allow a tc-taprio base-time of zero [ Upstream commit f64ab8e4f368f48afb08ae91928e103d17b235e9 ] Commit fe28c53ed71d ("net: stmmac: fix taprio configuration when base_time is in the past") allowed some base time values in the past, but apparently not all, the base-time value of 0 (Jan 1st 1970) is still explicitly denied by the driver. Remove the bogus check. Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Vladimir Oltean Reviewed-by: Kurt Kanzenbach Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f116f0dad316523d497d2d8217c2a00e6b2b6188 Author: Guangbin Huang Date: Wed Nov 10 21:42:56 2021 +0800 net: hns3: allow configure ETS bandwidth of all TCs [ Upstream commit 688db0c7a4a69ddc8b8143a1cac01eb20082a3aa ] Currently, driver only allow configuring ETS bandwidth of TCs according to the max TC number queried from firmware. However, the hardware actually supports 8 TCs and users may need to configure ETS bandwidth of all TCs, so remove the restriction. Fixes: 330baff5423b ("net: hns3: add ETS TC weight setting in SSU module") Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c7f7dc737f0d76967a23bb477adb4e565fad9d01 Author: Yufeng Mo Date: Wed Nov 10 21:42:53 2021 +0800 net: hns3: fix kernel crash when unload VF while it is being reset [ Upstream commit e140c7983e3054be0652bf914f4454f16c5520b0 ] When fully configure VLANs for a VF, then unload the VF while triggering a reset to PF, will cause a kernel crash because the irq is already uninit. [ 293.177579] ------------[ cut here ]------------ [ 293.183502] kernel BUG at drivers/pci/msi.c:352! [ 293.189547] Internal error: Oops - BUG: 0 [#1] SMP ...... [ 293.390124] Workqueue: hclgevf hclgevf_service_task [hclgevf] [ 293.402627] pstate: 80c00009 (Nzcv daif +PAN +UAO) [ 293.414324] pc : free_msi_irqs+0x19c/0x1b8 [ 293.425429] lr : free_msi_irqs+0x18c/0x1b8 [ 293.436545] sp : ffff00002716fbb0 [ 293.446950] x29: ffff00002716fbb0 x28: 0000000000000000 [ 293.459519] x27: 0000000000000000 x26: ffff45b91ea16b00 [ 293.472183] x25: 0000000000000000 x24: ffffa587b08f4700 [ 293.484717] x23: ffffc591ac30e000 x22: ffffa587b08f8428 [ 293.497190] x21: ffffc591ac30e300 x20: 0000000000000000 [ 293.509594] x19: ffffa58a062a8300 x18: 0000000000000000 [ 293.521949] x17: 0000000000000000 x16: ffff45b91dcc3f48 [ 293.534013] x15: 0000000000000000 x14: 0000000000000000 [ 293.545883] x13: 0000000000000040 x12: 0000000000000228 [ 293.557508] x11: 0000000000000020 x10: 0000000000000040 [ 293.568889] x9 : ffff45b91ea1e190 x8 : ffffc591802d0000 [ 293.580123] x7 : ffffc591802d0148 x6 : 0000000000000120 [ 293.591190] x5 : ffffc591802d0000 x4 : 0000000000000000 [ 293.602015] x3 : 0000000000000000 x2 : 0000000000000000 [ 293.612624] x1 : 00000000000004a4 x0 : ffffa58a1e0c6b80 [ 293.623028] Call trace: [ 293.630340] free_msi_irqs+0x19c/0x1b8 [ 293.638849] pci_disable_msix+0x118/0x140 [ 293.647452] pci_free_irq_vectors+0x20/0x38 [ 293.656081] hclgevf_uninit_msi+0x44/0x58 [hclgevf] [ 293.665309] hclgevf_reset_rebuild+0x1ac/0x2e0 [hclgevf] [ 293.674866] hclgevf_reset+0x358/0x400 [hclgevf] [ 293.683545] hclgevf_reset_service_task+0xd0/0x1b0 [hclgevf] [ 293.693325] hclgevf_service_task+0x4c/0x2e8 [hclgevf] [ 293.702307] process_one_work+0x1b0/0x448 [ 293.710034] worker_thread+0x54/0x468 [ 293.717331] kthread+0x134/0x138 [ 293.724114] ret_from_fork+0x10/0x18 [ 293.731324] Code: f940b000 b4ffff00 a903e7b8 f90017b6 (d4210000) This patch fixes the problem by waiting for the VF reset done while unloading the VF. Fixes: e2cb1dec9779 ("net: hns3: Add HNS3 VF HCL(Hardware Compatibility Layer) Support") Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 214dbb2b404280c986bee61fc7505b93cddfdfb3 Author: Jie Wang Date: Wed Nov 10 21:42:51 2021 +0800 net: hns3: fix pfc packet number incorrect after querying pfc parameters [ Upstream commit 0b653a81a26d66ffe526a54c2177e24fb1400301 ] Currently, driver will send command to firmware to query pfc packet number when user uses dcb tool to get pfc parameters. However, the periodic service task will also periodically query and record MAC statistics, including pfc packet number. As the hardware registers of statistics is cleared after reading, it will cause pfc packet number of MAC statistics are not correct after using dcb tool to get pfc parameters. To fix this problem, when user uses dcb tool to get pfc parameters, driver updates MAC statistics firstly and then get pfc packet number from MAC statistics. Fixes: 64fd2300fcc1 ("net: hns3: add support for querying pfc puase packets statistic") Signed-off-by: Jie Wang Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6fc15f27d462c81efbef6d2e6c196207bf43dbab Author: Jie Wang Date: Wed Nov 10 21:42:50 2021 +0800 net: hns3: fix ROCE base interrupt vector initialization bug [ Upstream commit beb27ca451a57a1c0e52b5268703f3c3173c1f8c ] Currently, NIC init ROCE interrupt vector with MSIX interrupt. But ROCE use pci_irq_vector() to get interrupt vector, which adds the relative interrupt vector again and gets wrong interrupt vector. So fixes it by assign relative interrupt vector to ROCE instead of MSIX interrupt vector and delete the unused struct member base_msi_vector declaration of hclgevf_dev. Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support") Signed-off-by: Jie Wang Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1959c36142270d6345aae972f4f0618a650092d7 Author: Eric Dumazet Date: Mon Nov 8 10:08:15 2021 -0800 net/sched: sch_taprio: fix undefined behavior in ktime_mono_to_any [ Upstream commit 6dc25401cba4d428328eade8ceae717633fdd702 ] 1) if q->tk_offset == TK_OFFS_MAX, then get_tcp_tstamp() calls ktime_mono_to_any() with out-of-bound value. 2) if q->tk_offset is changed in taprio_parse_clockid(), taprio_get_time() might also call ktime_mono_to_any() with out-of-bound value as sysbot found: UBSAN: array-index-out-of-bounds in kernel/time/timekeeping.c:908:27 index 3 is out of range for type 'ktime_t *[3]' CPU: 1 PID: 25668 Comm: kworker/u4:0 Not tainted 5.15.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:291 ktime_mono_to_any+0x1d4/0x1e0 kernel/time/timekeeping.c:908 get_tcp_tstamp net/sched/sch_taprio.c:322 [inline] get_packet_txtime net/sched/sch_taprio.c:353 [inline] taprio_enqueue_one+0x5b0/0x1460 net/sched/sch_taprio.c:420 taprio_enqueue+0x3b1/0x730 net/sched/sch_taprio.c:485 dev_qdisc_enqueue+0x40/0x300 net/core/dev.c:3785 __dev_xmit_skb net/core/dev.c:3869 [inline] __dev_queue_xmit+0x1f6e/0x3630 net/core/dev.c:4194 batadv_send_skb_packet+0x4a9/0x5f0 net/batman-adv/send.c:108 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline] batadv_iv_send_outstanding_bat_ogm_packet+0x6d7/0x8e0 net/batman-adv/bat_iv_ogm.c:1701 process_one_work+0x9b2/0x1690 kernel/workqueue.c:2298 worker_thread+0x658/0x11f0 kernel/workqueue.c:2445 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 Fixes: 7ede7b03484b ("taprio: make clock reference conversions easier") Fixes: 54002066100b ("taprio: Adjust timestamps for TCP packets") Signed-off-by: Eric Dumazet Cc: Vedang Patel Reported-by: syzbot Reviewed-by: Vinicius Costa Gomes Link: https://lore.kernel.org/r/20211108180815.1822479-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 45dea13179811dfa740f4448bd24b5020cb3a6f7 Author: Marek Behún Date: Thu Nov 4 18:17:47 2021 +0100 net: dsa: mv88e6xxx: Don't support >1G speeds on 6191X on ports other than 10 [ Upstream commit dc2fc9f03c5c410d8f01c2206b3d529f80b13733 ] Model 88E6191X only supports >1G speeds on port 10. Port 0 and 9 are only 1G. Fixes: de776d0d316f ("net: dsa: mv88e6xxx: add support for mv88e6393x family") Signed-off-by: Marek Behún Cc: Russell King (Oracle) Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20211104171747.10509-1-kabel@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5862afa33cb1a489ad4c4050e1118ead770e5892 Author: Muchun Song Date: Mon Nov 8 18:35:19 2021 -0800 seq_file: fix passing wrong private data [ Upstream commit 10a6de19cad6efb9b49883513afb810dc265fca2 ] DEFINE_PROC_SHOW_ATTRIBUTE() is supposed to be used to define a series of functions and variables to register proc file easily. And the users can use proc_create_data() to pass their own private data and get it via seq->private in the callback. Unfortunately, the proc file system use PDE_DATA() to get private data instead of inode->i_private. So fix it. Fortunately, there only one user of it which does not pass any private data, so this bug does not break any in-tree codes. Link: https://lkml.kernel.org/r/20211029032638.84884-1-songmuchun@bytedance.com Fixes: 97a32539b956 ("proc: convert everything to "struct proc_ops"") Signed-off-by: Muchun Song Cc: Andy Shevchenko Cc: Stephen Rothwell Cc: Florent Revest Cc: Alexey Dobriyan Cc: Christian Brauner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 17f7aec830f5a0497b333b01ff971f56afd8d650 Author: Imre Deak Date: Wed Oct 27 01:50:59 2021 +0300 drm/i915/fb: Fix rounding error in subsampled plane size calculation [ Upstream commit 90ab96f3872eae816f4e07deaa77322a91237960 ] For NV12 FBs with odd main surface tile-row height the CCS surface height was incorrectly calculated 1 less than the actual value. Fix this by rounding up the result of divison. For consistency do the same for the CCS surface width calculation. Fixes: b3e57bccd68a ("drm/i915/tgl: Gen-12 render decompression") Signed-off-by: Imre Deak Reviewed-by: Juha-Pekka Heikkila Link: https://patchwork.freedesktop.org/patch/msgid/20211026225105.2783797-2-imre.deak@intel.com (cherry picked from commit 2ee5ef9c934ad26376c9282171e731e6c0339815) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin commit e8cf4c96f11ed1fe21f106e0d75b776c2b4cf543 Author: Dan Carpenter Date: Tue Nov 9 14:47:36 2021 +0300 gve: Fix off by one in gve_tx_timeout() [ Upstream commit 1c360cc1cc883fbdf0a258b4df376571fbeac5ee ] The priv->ntfy_blocks[] has "priv->num_ntfy_blks" elements so this > needs to be >= to prevent an off by one bug. The priv->ntfy_blocks[] array is allocated in gve_alloc_notify_blocks(). Fixes: 87a7f321bb6a ("gve: Recover from queue stall due to missed IRQ") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cf427bf68f29d9c71624a4505b5d622a96c95fb4 Author: Arnd Bergmann Date: Wed Nov 3 16:33:12 2021 +0100 dmaengine: stm32-dma: avoid 64-bit division in stm32_dma_get_max_width [ Upstream commit 2498363310e9b5e5de0e104709adc35c9f3ff7d9 ] Using the % operator on a 64-bit variable is expensive and can cause a link failure: arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_get_max_width': stm32-dma.c:(.text+0x170): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_set_xfer_param': stm32-dma.c:(.text+0x1cd4): undefined reference to `__aeabi_uldivmod' As we know that we just want to check the alignment in stm32_dma_get_max_width(), there is no need for a full division, and using a simple mask is a faster replacement. Same in stm32_dma_set_xfer_param(), change this to only allow burst transfers if the address is a multiple of the length. stm32_dma_get_best_burst just after will take buf_len into account to fix burst in case of misalignment. Fixes: b20fd5fa310c ("dmaengine: stm32-dma: fix stm32_dma_get_max_width") Reported-by: kernel test robot Signed-off-by: Arnd Bergmann Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211103153312.41483-1-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit b3ce1fc8100afb5f859f35f9566fba3047fa57e0 Author: Amelie Delaunay Date: Mon Oct 11 11:42:59 2021 +0200 dmaengine: stm32-dma: fix burst in case of unaligned memory address [ Upstream commit af229d2c2557b5cf2a3b1eb39847ec1de7446873 ] Theorically, address pointers used by STM32 DMA must be chosen so as to ensure that all transfers within a burst block are aligned on the address boundary equal to the size of the transfer. If this is always the case for peripheral addresses on STM32, it is not for memory addresses if the user doesn't respect this alignment constraint. To avoid a weird behavior of the DMA controller in this case (no error triggered but data are not transferred as expected), force no burst. Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211011094259.315023-4-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit af400d2469ae653f2565af0cf5728fa8586b0b25 Author: Jussi Maki Date: Wed Nov 3 13:47:36 2021 -0700 bpf, sockmap: sk_skb data_end access incorrect when src_reg = dst_reg [ Upstream commit b2c4618162ec615a15883a804cce7e27afecfa58 ] The current conversion of skb->data_end reads like this: ; data_end = (void*)(long)skb->data_end; 559: (79) r1 = *(u64 *)(r2 +200) ; r1 = skb->data 560: (61) r11 = *(u32 *)(r2 +112) ; r11 = skb->len 561: (0f) r1 += r11 562: (61) r11 = *(u32 *)(r2 +116) 563: (1f) r1 -= r11 But similar to the case in 84f44df664e9 ("bpf: sock_ops sk access may stomp registers when dst_reg = src_reg"), the code will read an incorrect skb->len when src == dst. In this case we end up generating this xlated code: ; data_end = (void*)(long)skb->data_end; 559: (79) r1 = *(u64 *)(r1 +200) ; r1 = skb->data 560: (61) r11 = *(u32 *)(r1 +112) ; r11 = (skb->data)->len 561: (0f) r1 += r11 562: (61) r11 = *(u32 *)(r1 +116) 563: (1f) r1 -= r11 ... where line 560 is the reading 4B of (skb->data + 112) instead of the intended skb->len Here the skb pointer in r1 gets set to skb->data and the later deref for skb->len ends up following skb->data instead of skb. This fixes the issue similarly to the patch mentioned above by creating an additional temporary variable and using to store the register when dst_reg = src_reg. We name the variable bpf_temp_reg and place it in the cb context for sk_skb. Then we restore from the temp to ensure nothing is lost. Fixes: 16137b09a66f2 ("bpf: Compute data_end dynamically with JIT code") Signed-off-by: Jussi Maki Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20211103204736.248403-6-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit 6b0db2a36f9a5879d6c14d1ba6ca43e439925653 Author: John Fastabend Date: Wed Nov 3 13:47:35 2021 -0700 bpf: sockmap, strparser, and tls are reusing qdisc_skb_cb and colliding [ Upstream commit e0dc3b93bd7bcff8c3813d1df43e0908499c7cf0 ] Strparser is reusing the qdisc_skb_cb struct to stash the skb message handling progress, e.g. offset and length of the skb. First this is poorly named and inherits a struct from qdisc that doesn't reflect the actual usage of cb[] at this layer. But, more importantly strparser is using the following to access its metadata. (struct _strp_msg *)((void *)skb->cb + offsetof(struct qdisc_skb_cb, data)) Where _strp_msg is defined as: struct _strp_msg { struct strp_msg strp; /* 0 8 */ int accum_len; /* 8 4 */ /* size: 12, cachelines: 1, members: 2 */ /* last cacheline: 12 bytes */ }; So we use 12 bytes of ->data[] in struct. However in BPF code running parser and verdict the user has read capabilities into the data[] array as well. Its not too problematic, but we should not be exposing internal state to BPF program. If its really needed then we can use the probe_read() APIs which allow reading kernel memory. And I don't believe cb[] layer poses any API breakage by moving this around because programs can't depend on cb[] across layers. In order to fix another issue with a ctx rewrite we need to stash a temp variable somewhere. To make this work cleanly this patch builds a cb struct for sk_skb types called sk_skb_cb struct. Then we can use this consistently in the strparser, sockmap space. Additionally we can start allowing ->cb[] write access after this. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Tested-by: Jussi Maki Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20211103204736.248403-5-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit 0580e47c8895a4d61ee095f086cba1ded7ca5e7f Author: John Fastabend Date: Wed Nov 3 13:47:34 2021 -0700 bpf, sockmap: Fix race in ingress receive verdict with redirect to self [ Upstream commit c5d2177a72a1659554922728fc407f59950aa929 ] A socket in a sockmap may have different combinations of programs attached depending on configuration. There can be no programs in which case the socket acts as a sink only. There can be a TX program in this case a BPF program is attached to sending side, but no RX program is attached. There can be an RX program only where sends have no BPF program attached, but receives are hooked with BPF. And finally, both TX and RX programs may be attached. Giving us the permutations: None, Tx, Rx, and TxRx To date most of our use cases have been TX case being used as a fast datapath to directly copy between local application and a userspace proxy. Or Rx cases and TxRX applications that are operating an in kernel based proxy. The traffic in the first case where we hook applications into a userspace application looks like this: AppA redirect AppB Tx <-----------> Rx | | + + TCP <--> lo <--> TCP In this case all traffic from AppA (after 3whs) is copied into the AppB ingress queue and no traffic is ever on the TCP recieive_queue. In the second case the application never receives, except in some rare error cases, traffic on the actual user space socket. Instead the send happens in the kernel. AppProxy socket pool sk0 ------------->{sk1,sk2, skn} ^ | | | | v ingress lb egress TCP TCP Here because traffic is never read off the socket with userspace recv() APIs there is only ever one reader on the sk receive_queue. Namely the BPF programs. However, we've started to introduce a third configuration where the BPF program on receive should process the data, but then the normal case is to push the data into the receive queue of AppB. AppB recv() (userspace) ----------------------- tcp_bpf_recvmsg() (kernel) | | | | | | ingress_msgQ | | | RX_BPF | | | v v sk->receive_queue This is different from the App{A,B} redirect because traffic is first received on the sk->receive_queue. Now for the issue. The tcp_bpf_recvmsg() handler first checks the ingress_msg queue for any data handled by the BPF rx program and returned with PASS code so that it was enqueued on the ingress msg queue. Then if no data exists on that queue it checks the socket receive queue. Unfortunately, this is the same receive_queue the BPF program is reading data off of. So we get a race. Its possible for the recvmsg() hook to pull data off the receive_queue before the BPF hook has a chance to read it. It typically happens when an application is banging on recv() and getting EAGAINs. Until they manage to race with the RX BPF program. To fix this we note that before this patch at attach time when the socket is loaded into the map we check if it needs a TX program or just the base set of proto bpf hooks. Then it uses the above general RX hook regardless of if we have a BPF program attached at rx or not. This patch now extends this check to handle all cases enumerated above, TX, RX, TXRX, and none. And to fix above race when an RX program is attached we use a new hook that is nearly identical to the old one except now we do not let the recv() call skip the RX BPF program. Now only the BPF program pulls data from sk->receive_queue and recv() only pulls data from the ingress msgQ post BPF program handling. With this resolved our AppB from above has been up and running for many hours without detecting any errors. We do this by correlating counters in RX BPF events and the AppB to ensure data is never skipping the BPF program. Selftests, was not able to detect this because we only run them for a short period of time on well ordered send/recvs so we don't get any of the noise we see in real application environments. Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Tested-by: Jussi Maki Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20211103204736.248403-4-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit 778aec90440f242439ee5f5bdc377b455a139c96 Author: John Fastabend Date: Wed Nov 3 13:47:33 2021 -0700 bpf, sockmap: Remove unhash handler for BPF sockmap usage [ Upstream commit b8b8315e39ffaca82e79d86dde26e9144addf66b ] We do not need to handle unhash from BPF side we can simply wait for the close to happen. The original concern was a socket could transition from ESTABLISHED state to a new state while the BPF hook was still attached. But, we convinced ourself this is no longer possible and we also improved BPF sockmap to handle listen sockets so this is no longer a problem. More importantly though there are cases where unhash is called when data is in the receive queue. The BPF unhash logic will flush this data which is wrong. To be correct it should keep the data in the receive queue and allow a receiving application to continue reading the data. This may happen when tcp_abort() is received for example. Instead of complicating the logic in unhash simply moving all this to tcp_close() hook solves this. Fixes: 51199405f9672 ("bpf: skb_verdict, support SK_PASS on RX BPF path") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Tested-by: Jussi Maki Reviewed-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20211103204736.248403-3-john.fastabend@gmail.com Signed-off-by: Sasha Levin commit 1ad5169dbb1cf9e171b048696b32d6bf74408243 Author: Arnd Bergmann Date: Fri Nov 5 08:54:03 2021 +0100 arm64: pgtable: make __pte_to_phys/__phys_to_pte_val inline functions [ Upstream commit c7c386fbc20262c1d911c615c65db6a58667d92c ] gcc warns about undefined behavior the vmalloc code when building with CONFIG_ARM64_PA_BITS_52, when the 'idx++' in the argument to __phys_to_pte_val() is evaluated twice: mm/vmalloc.c: In function 'vmap_pfn_apply': mm/vmalloc.c:2800:58: error: operation on 'data->idx' may be undefined [-Werror=sequence-point] 2800 | *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); | ~~~~~~~~~^~ arch/arm64/include/asm/pgtable-types.h:25:37: note: in definition of macro '__pte' 25 | #define __pte(x) ((pte_t) { (x) } ) | ^ arch/arm64/include/asm/pgtable.h:80:15: note: in expansion of macro '__phys_to_pte_val' 80 | __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | pgprot_val(prot)) | ^~~~~~~~~~~~~~~~~ mm/vmalloc.c:2800:30: note: in expansion of macro 'pfn_pte' 2800 | *pte = pte_mkspecial(pfn_pte(data->pfns[data->idx++], data->prot)); | ^~~~~~~ I have no idea why this never showed up earlier, but the safest workaround appears to be changing those macros into inline functions so the arguments get evaluated only once. Cc: Matthew Wilcox Fixes: 75387b92635e ("arm64: handle 52-bit physical addresses in page table entries") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20211105075414.2553155-1-arnd@kernel.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit cdc29bc2748f4e8ff74eced17cae25ef5939804e Author: Reiji Watanabe Date: Sun Oct 31 21:54:21 2021 -0700 arm64: arm64_ftr_reg->name may not be a human-readable string [ Upstream commit 9dc232a8ab18bb20f1dcb03c8e049e3607f3ed15 ] The id argument of ARM64_FTR_REG_OVERRIDE() is used for two purposes: one as the system register encoding (used for the sys_id field of __ftr_reg_entry), and the other as the register name (stringified and used for the name field of arm64_ftr_reg), which is debug information. The id argument is supposed to be a macro that indicates an encoding of the register (eg. SYS_ID_AA64PFR0_EL1, etc). ARM64_FTR_REG(), which also has the same id argument, uses ARM64_FTR_REG_OVERRIDE() and passes the id to the macro. Since the id argument is completely macro-expanded before it is substituted into a macro body of ARM64_FTR_REG_OVERRIDE(), the stringified id in the body of ARM64_FTR_REG_OVERRIDE is not a human-readable register name, but a string of numeric bitwise operations. Fix this so that human-readable register names are available as debug information. Fixes: 8f266a5d878a ("arm64: cpufeature: Add global feature override facility") Signed-off-by: Reiji Watanabe Reviewed-by: Oliver Upton Acked-by: Marc Zyngier Link: https://lore.kernel.org/r/20211101045421.2215822-1-reijiw@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 8fbaf7b79caa7e01dc879e9867ff82a78832c2c9 Author: Chengfeng Ye Date: Fri Nov 5 06:36:36 2021 -0700 nfc: pn533: Fix double free when pn533_fill_fragment_skbs() fails [ Upstream commit 9fec40f850658e00a14a7dd9e06f7fbc7e59cc4a ] skb is already freed by dev_kfree_skb in pn533_fill_fragment_skbs, but follow error handler branch when pn533_fill_fragment_skbs() fails, skb is freed again, results in double free issue. Fix this by not free skb in error path of pn533_fill_fragment_skbs. Fixes: 963a82e07d4e ("NFC: pn533: Split large Tx frames in chunks") Fixes: 93ad42020c2d ("NFC: pn533: Target mode Tx fragmentation support") Signed-off-by: Chengfeng Ye Reviewed-by: Dan Carpenter Reviewed-by: Krzysztof Kozlowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5dedc3a392e30a9ab97ab1e319c7590e272c9e18 Author: Eric Dumazet Date: Fri Nov 5 14:42:14 2021 -0700 llc: fix out-of-bound array index in llc_sk_dev_hash() [ Upstream commit 8ac9dfd58b138f7e82098a4e0a0d46858b12215b ] Both ifindex and LLC_SK_DEV_HASH_ENTRIES are signed. This means that (ifindex % LLC_SK_DEV_HASH_ENTRIES) is negative if @ifindex is negative. We could simply make LLC_SK_DEV_HASH_ENTRIES unsigned. In this patch I chose to use hash_32() to get more entropy from @ifindex, like llc_sk_laddr_hashfn(). UBSAN: array-index-out-of-bounds in ./include/net/llc.h:75:26 index -43 is out of range for type 'hlist_head [64]' CPU: 1 PID: 20999 Comm: syz-executor.3 Not tainted 5.15.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:291 llc_sk_dev_hash include/net/llc.h:75 [inline] llc_sap_add_socket+0x49c/0x520 net/llc/llc_conn.c:697 llc_ui_bind+0x680/0xd70 net/llc/af_llc.c:404 __sys_bind+0x1e9/0x250 net/socket.c:1693 __do_sys_bind net/socket.c:1704 [inline] __se_sys_bind net/socket.c:1702 [inline] __x64_sys_bind+0x6f/0xb0 net/socket.c:1702 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa503407ae9 Fixes: 6d2e3ea28446 ("llc: use a device based hash table to speed up multicast delivery") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 78455257102e26b5ef8292973d69574c1f91984f Author: Ian Rogers Date: Fri Nov 5 22:37:33 2021 -0700 perf bpf: Add missing free to bpf_event__print_bpf_prog_info() [ Upstream commit 88c42f4d6cb249eb68524282f8d4cc32f9059984 ] If btf__new() is called then there needs to be a corresponding btf__free(). Fixes: f8dfeae009effc0b ("perf bpf: Show more BPF program info in print_bpf_prog_info()") Signed-off-by: Ian Rogers Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andrii Nakryiko Cc: Daniel Borkmann Cc: Jiri Olsa Cc: John Fastabend Cc: KP Singh Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Tiezhu Yang Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20211106053733.3580931-2-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 700f183edb05b738eea38de50f67256f8ce1ee1e Author: Dan Carpenter Date: Fri Nov 5 13:45:12 2021 -0700 zram: off by one in read_block_state() [ Upstream commit a88e03cf3d190cf46bc4063a9b7efe87590de5f4 ] snprintf() returns the number of bytes it would have printed if there were space. But it does not count the NUL terminator. So that means that if "count == copied" then this has already overflowed by one character. This bug likely isn't super harmful in real life. Link: https://lkml.kernel.org/r/20210916130404.GA25094@kili Fixes: c0265342bff4 ("zram: introduce zram memory tracking") Signed-off-by: Dan Carpenter Cc: Minchan Kim Cc: Sergey Senozhatsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ec82306f4509e2462713eabce36b2727107ca5b6 Author: Miaohe Lin Date: Fri Nov 5 13:45:03 2021 -0700 mm/zsmalloc.c: close race window between zs_pool_dec_isolated() and zs_unregister_migration() [ Upstream commit afe8605ca45424629fdddfd85984b442c763dc47 ] There is one possible race window between zs_pool_dec_isolated() and zs_unregister_migration() because wait_for_isolated_drain() checks the isolated count without holding class->lock and there is no order inside zs_pool_dec_isolated(). Thus the below race window could be possible: zs_pool_dec_isolated zs_unregister_migration check pool->destroying != 0 pool->destroying = true; smp_mb(); wait_for_isolated_drain() wait for pool->isolated_pages == 0 atomic_long_dec(&pool->isolated_pages); atomic_long_read(&pool->isolated_pages) == 0 Since we observe the pool->destroying (false) before atomic_long_dec() for pool->isolated_pages, waking pool->migration_wait up is missed. Fix this by ensure checking pool->destroying happens after the atomic_long_dec(&pool->isolated_pages). Link: https://lkml.kernel.org/r/20210708115027.7557-1-linmiaohe@huawei.com Fixes: 701d678599d0 ("mm/zsmalloc.c: fix race condition in zs_destroy_pool") Signed-off-by: Miaohe Lin Cc: Minchan Kim Cc: Sergey Senozhatsky Cc: Henry Burns Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 8f04fdb4229867a85fbead04616db33b11efc5ba Author: Marc Kleine-Budde Date: Tue Oct 19 17:00:04 2021 +0200 can: mcp251xfd: mcp251xfd_chip_start(): fix error handling for mcp251xfd_chip_rx_int_enable() [ Upstream commit 69c55f6e7669d46bb40e41f6e2b218428178368a ] This patch fixes the error handling for mcp251xfd_chip_rx_int_enable(). Instead just returning the error, properly shut down the chip. Link: https://lore.kernel.org/all/20211106201526.44292-2-mkl@pengutronix.de Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 4f389e1276a5389c92cef860c9fde8e1c802a871 Author: Vincent Mailhol Date: Wed Oct 27 03:07:40 2021 +0900 can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path [ Upstream commit d9447f768bc8c60623e4bb3ce65b8f4654d33a50 ] In es58x_rx_err_msg(), if can->do_set_mode() fails, the function directly returns without calling netif_rx(skb). This means that the skb previously allocated by alloc_can_err_skb() is not freed. In other terms, this is a memory leak. This patch simply removes the return statement in the error branch and let the function continue. Issue was found with GCC -fanalyzer, please follow the link below for details. Fixes: 8537257874e9 ("can: etas_es58x: add core support for ETAS ES58X CAN USB interfaces") Link: https://lore.kernel.org/all/20211026180740.1953265-1-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 7a3210be9964f2587798d323b5f8f442907af4cb Author: Fabio Estevam Date: Wed Nov 3 21:11:12 2021 -0300 Revert "drm/imx: Annotate dma-fence critical section in commit path" [ Upstream commit 14d9a37c952588930d7226953359fea3ab956d39 ] This reverts commit f4b34faa08428d813fc3629f882c503487f94a12. Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit path") the following possible circular dependency is detected: [ 5.001811] ====================================================== [ 5.001817] WARNING: possible circular locking dependency detected [ 5.001824] 5.14.9-01225-g45da36cc6fcc-dirty #1 Tainted: G W [ 5.001833] ------------------------------------------------------ [ 5.001838] kworker/u8:0/7 is trying to acquire lock: [ 5.001848] c1752080 (regulator_list_mutex){+.+.}-{3:3}, at: regulator_lock_dependent+0x40/0x294 [ 5.001903] [ 5.001903] but task is already holding lock: [ 5.001909] c176df78 (dma_fence_map){++++}-{0:0}, at: imx_drm_atomic_commit_tail+0x10/0x160 [ 5.001957] [ 5.001957] which lock already depends on the new lock. ... Revert it for now. Tested on a imx6q-sabresd. Fixes: f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in commit path") Signed-off-by: Fabio Estevam Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20211104001112.4035691-1-festevam@gmail.com Signed-off-by: Sasha Levin commit cd5d00738d62e5499496f435142ee76a6b78c4c5 Author: Arnd Bergmann Date: Fri Oct 29 14:02:38 2021 +0200 drm: fb_helper: improve CONFIG_FB dependency [ Upstream commit 9d6366e743f37d36ef69347924ead7bcc596076e ] My previous patch correctly addressed the possible link failure, but as Jani points out, the dependency is now stricter than it needs to be. Change it again, to allow DRM_FBDEV_EMULATION to be used when DRM_KMS_HELPER and FB are both loadable modules and DRM is linked into the kernel. As a side-effect, the option is now only visible when at least one DRM driver makes use of DRM_KMS_HELPER. This is better, because the option has no effect otherwise. Fixes: 606b102876e3 ("drm: fb_helper: fix CONFIG_FB dependency") Suggested-by: Acked-by: Jani Nikula Reviewed-by: Javier Martinez Canillas Signed-off-by: Arnd Bergmann Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20211029120307.1407047-1-arnd@kernel.org Signed-off-by: Sasha Levin commit 748dc40f15529f545a944e71b81f716bd3d60ef6 Author: Hangbin Liu Date: Wed Oct 27 11:35:53 2021 +0800 selftests/bpf/xdp_redirect_multi: Limit the tests in netns [ Upstream commit 8955c1a329873385775081e029d9a7c6aa9037e1 ] As I want to test both DEVMAP and DEVMAP_HASH in XDP multicast redirect, I limited DEVMAP max entries to a small value for performace. When the test runs after amount of interface creating/deleting tests. The interface index will exceed the map max entries and xdp_redirect_multi will error out with "Get interfacesInterface index to large". Fix this issue by limit the tests in netns and specify the ifindex when creating interfaces. Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test") Reported-by: Jiri Benc Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20211027033553.962413-5-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit 67ebdf08154e3fadf71239b465beedfbc7a04819 Author: Hangbin Liu Date: Wed Oct 27 11:35:52 2021 +0800 selftests/bpf/xdp_redirect_multi: Give tcpdump a chance to terminate cleanly [ Upstream commit 648c3677062fbd14d754b853daebb295426771e8 ] No need to kill tcpdump with -9. Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test") Suggested-by: Jiri Benc Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20211027033553.962413-4-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit 63d52d3f722b2eba066c16457f3ab6fb5f346dfd Author: Hangbin Liu Date: Wed Oct 27 11:35:51 2021 +0800 selftests/bpf/xdp_redirect_multi: Use arping to accurate the arp number [ Upstream commit f53ea9dbf78d42a10e2392b5c59362ccc224fd1d ] The arp request number triggered by ping none exist address is not accurate, which may lead the test false negative/positive. Change to use arping to accurate the arp number. Also do not use grep pattern match for dot. Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test") Suggested-by: Jiri Benc Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20211027033553.962413-3-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit 52058c2e55162a5a573609d5b3ea50f347983df0 Author: Hangbin Liu Date: Wed Oct 27 11:35:50 2021 +0800 selftests/bpf/xdp_redirect_multi: Put the logs to tmp folder [ Upstream commit 8b4ac13abe7d82da0e0d22a9ba2e27301559a93e ] The xdp_redirect_multi test logs are created in selftest folder and not cleaned after test. Let's creat a tmp dir and remove the logs after testing. Fixes: d23292476297 ("selftests/bpf: Add xdp_redirect_multi test") Suggested-by: Jiri Benc Signed-off-by: Hangbin Liu Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20211027033553.962413-2-liuhangbin@gmail.com Signed-off-by: Sasha Levin commit 5ad1157af560a2844121571d459cfbe727d44fd5 Author: Mehrdad Arshad Rad Date: Thu Nov 4 10:13:54 2021 -0700 libbpf: Fix lookup_and_delete_elem_flags error reporting [ Upstream commit 64165ddf8ea184631c65e3bbc8d59f6d940590ca ] Fix bpf_map_lookup_and_delete_elem_flags() to pass the return code through libbpf_err_errno() as we do similarly in bpf_map_lookup_and_delete_elem(). Fixes: f12b65432728 ("libbpf: Streamline error reporting for low-level APIs") Signed-off-by: Mehrdad Arshad Rad Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20211104171354.11072-1-arshad.rad@gmail.com Signed-off-by: Sasha Levin commit 006b5af213cd83ee4af286ef333d107a5e91a1e9 Author: Rafael J. Wysocki Date: Thu Nov 4 22:54:17 2021 +0100 ACPI: PM: Fix device wakeup power reference counting error [ Upstream commit 452a3e723f75880757acf87b053935c43aa89f89 ] Fix a device wakeup power reference counting error introduced by commit a2d7b2e004af ("ACPI: PM: Fix sharing of wakeup power resources") because of a coding mistake. Fixes: a2d7b2e004af ("ACPI: PM: Fix sharing of wakeup power resources") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c6d718f67eff8a4af0e33fd4b08512a5c008798e Author: Kai Song Date: Wed Oct 6 22:19:26 2021 +0800 mfd: altera-sysmgr: Fix a mistake caused by resource_size conversion [ Upstream commit fae2570d629cdd72f0611d015fc4ba705ae5422b ] The resource_size defines that: res->end - res->start + 1; The origin original code is: sysmgr_config.max_register = res->end - res->start - 3; So, the correct fix is that: sysmgr_config.max_register = resource_size(res) - 4; Fixes: d12edf9661a4 ("mfd: altera-sysmgr: Use resource_size function on resource object") Signed-off-by: Kai Song Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20211006141926.6120-1-songkai01@inspur.com Signed-off-by: Sasha Levin commit 051b35b8350894180d90242e88deaaf1b6619183 Author: Mark Brown Date: Fri Sep 24 15:33:47 2021 +0100 mfd: sprd: Add SPI device ID table [ Upstream commit c5c7f0677107052060037583b9c8c15d818afb04 ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Reviewed-by: Baolin Wang Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20210924143347.14721-4-broonie@kernel.org Signed-off-by: Sasha Levin commit fa6a7b427e3e6938ed858e913d7b32eb77048e33 Author: Mark Brown Date: Fri Sep 24 15:33:46 2021 +0100 mfd: cpcap: Add SPI device ID table [ Upstream commit d5fa8592b773f4da2b04e7333cd37efec5e4ca43 ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20210924143347.14721-3-broonie@kernel.org Signed-off-by: Sasha Levin commit b862c9d1aa0db0ade9ad81d7b5964b261a4d15c0 Author: Krzysztof Kozlowski Date: Fri May 28 07:51:26 2021 -0400 mfd: core: Add missing of_node_put for loop iteration [ Upstream commit 002be81140075e17a1ebd5c3c55e356fbab0ddad ] Early exits from for_each_child_of_node() should decrement the node reference counter. Reported by Coccinelle: drivers/mfd/mfd-core.c:197:2-24: WARNING: Function "for_each_child_of_node" should have of_node_put() before goto around lines 209. Fixes: c94bb233a9fe ("mfd: Make MFD core code Device Tree and IRQ domain aware") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20210528115126.18370-1-krzysztof.kozlowski@canonical.com Signed-off-by: Sasha Levin commit c85582ef7d42d0e756b9289e259980f55a68cc66 Author: Takashi Iwai Date: Fri Nov 5 11:21:03 2021 +0100 ALSA: memalloc: Catch call with NULL snd_dma_buffer pointer [ Upstream commit dce9446192439eaac81c21f517325fb473735e53 ] Although we've covered all calls with NULL dma buffer pointer, so far, there may be still some else in the wild. For catching such a case more easily, add a WARN_ON_ONCE() in snd_dma_get_ops(). Fixes: 37af81c5998f ("ALSA: core: Abstract memory alloc helpers") Link: https://lore.kernel.org/r/20211105102103.28148-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 61ef4e2f3fbf1b3e36202424264b8f20de620501 Author: Huang Guobin Date: Tue Nov 2 17:37:33 2021 +0800 bonding: Fix a use-after-free problem when bond_sysfs_slave_add() failed [ Upstream commit b93c6a911a3fe926b00add28f3b932007827c4ca ] When I do fuzz test for bonding device interface, I got the following use-after-free Calltrace: ================================================================== BUG: KASAN: use-after-free in bond_enslave+0x1521/0x24f0 Read of size 8 at addr ffff88825bc11c00 by task ifenslave/7365 CPU: 5 PID: 7365 Comm: ifenslave Tainted: G E 5.15.0-rc1+ #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 Call Trace: dump_stack_lvl+0x6c/0x8b print_address_description.constprop.0+0x48/0x70 kasan_report.cold+0x82/0xdb __asan_load8+0x69/0x90 bond_enslave+0x1521/0x24f0 bond_do_ioctl+0x3e0/0x450 dev_ifsioc+0x2ba/0x970 dev_ioctl+0x112/0x710 sock_do_ioctl+0x118/0x1b0 sock_ioctl+0x2e0/0x490 __x64_sys_ioctl+0x118/0x150 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f19159cf577 Code: b3 66 90 48 8b 05 11 89 2c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 78 RSP: 002b:00007ffeb3083c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffeb3084bca RCX: 00007f19159cf577 RDX: 00007ffeb3083ce0 RSI: 0000000000008990 RDI: 0000000000000003 RBP: 00007ffeb3084bc4 R08: 0000000000000040 R09: 0000000000000000 R10: 00007ffeb3084bc0 R11: 0000000000000246 R12: 00007ffeb3083ce0 R13: 0000000000000000 R14: 0000000000000000 R15: 00007ffeb3083cb0 Allocated by task 7365: kasan_save_stack+0x23/0x50 __kasan_kmalloc+0x83/0xa0 kmem_cache_alloc_trace+0x22e/0x470 bond_enslave+0x2e1/0x24f0 bond_do_ioctl+0x3e0/0x450 dev_ifsioc+0x2ba/0x970 dev_ioctl+0x112/0x710 sock_do_ioctl+0x118/0x1b0 sock_ioctl+0x2e0/0x490 __x64_sys_ioctl+0x118/0x150 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Freed by task 7365: kasan_save_stack+0x23/0x50 kasan_set_track+0x20/0x30 kasan_set_free_info+0x24/0x40 __kasan_slab_free+0xf2/0x130 kfree+0xd1/0x5c0 slave_kobj_release+0x61/0x90 kobject_put+0x102/0x180 bond_sysfs_slave_add+0x7a/0xa0 bond_enslave+0x11b6/0x24f0 bond_do_ioctl+0x3e0/0x450 dev_ifsioc+0x2ba/0x970 dev_ioctl+0x112/0x710 sock_do_ioctl+0x118/0x1b0 sock_ioctl+0x2e0/0x490 __x64_sys_ioctl+0x118/0x150 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Last potentially related work creation: kasan_save_stack+0x23/0x50 kasan_record_aux_stack+0xb7/0xd0 insert_work+0x43/0x190 __queue_work+0x2e3/0x970 delayed_work_timer_fn+0x3e/0x50 call_timer_fn+0x148/0x470 run_timer_softirq+0x8a8/0xc50 __do_softirq+0x107/0x55f Second to last potentially related work creation: kasan_save_stack+0x23/0x50 kasan_record_aux_stack+0xb7/0xd0 insert_work+0x43/0x190 __queue_work+0x2e3/0x970 __queue_delayed_work+0x130/0x180 queue_delayed_work_on+0xa7/0xb0 bond_enslave+0xe25/0x24f0 bond_do_ioctl+0x3e0/0x450 dev_ifsioc+0x2ba/0x970 dev_ioctl+0x112/0x710 sock_do_ioctl+0x118/0x1b0 sock_ioctl+0x2e0/0x490 __x64_sys_ioctl+0x118/0x150 do_syscall_64+0x35/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae The buggy address belongs to the object at ffff88825bc11c00 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes inside of 1024-byte region [ffff88825bc11c00, ffff88825bc12000) The buggy address belongs to the page: page:ffffea00096f0400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x25bc10 head:ffffea00096f0400 order:3 compound_mapcount:0 compound_pincount:0 flags: 0x57ff00000010200(slab|head|node=1|zone=2|lastcpupid=0x7ff) raw: 057ff00000010200 ffffea0009a71c08 ffff888240001968 ffff88810004dbc0 raw: 0000000000000000 00000000000a000a 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88825bc11b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88825bc11b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff88825bc11c00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88825bc11c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88825bc11d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Put new_slave in bond_sysfs_slave_add() will cause use-after-free problems when new_slave is accessed in the subsequent error handling process. Since new_slave will be put in the subsequent error handling process, remove the unnecessary put to fix it. In addition, when sysfs_create_file() fails, if some files have been crea- ted successfully, we need to call sysfs_remove_file() to remove them. Since there are sysfs_create_files() & sysfs_remove_files() can be used, use these two functions instead. Fixes: 7afcaec49696 (bonding: use kobject_put instead of _del after kobject_add) Signed-off-by: Huang Guobin Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51f230381aee3d13df654de628fbce66332d3fb1 Author: Jason Gunthorpe Date: Tue Oct 19 20:27:31 2021 -0300 drm/ttm: remove ttm_bo_vm_insert_huge() [ Upstream commit 0d979509539ed1df883a30d442177ca7be609565 ] The huge page functionality in TTM does not work safely because PUD and PMD entries do not have a special bit. get_user_pages_fast() considers any page that passed pmd_huge() as usable: if (unlikely(pmd_trans_huge(pmd) || pmd_huge(pmd) || pmd_devmap(pmd))) { And vmf_insert_pfn_pmd_prot() unconditionally sets entry = pmd_mkhuge(pfn_t_pmd(pfn, prot)); eg on x86 the page will be _PAGE_PRESENT | PAGE_PSE. As such gup_huge_pmd() will try to deref a struct page: head = try_grab_compound_head(pmd_page(orig), refs, flags); and thus crash. Thomas further notices that the drivers are not expecting the struct page to be used by anything - in particular the refcount incr above will cause them to malfunction. Thus everything about this is not able to fully work correctly considering GUP_fast. Delete it entirely. It can return someday along with a proper PMD/PUD_SPECIAL bit in the page table itself to gate GUP_fast. Fixes: 314b6580adc5 ("drm/ttm, drm/vmwgfx: Support huge TTM pagefaults") Signed-off-by: Jason Gunthorpe Reviewed-by: Thomas Hellström Reviewed-by: Christian König [danvet: Update subject per Thomas' &Christian's review] Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/0-v2-a44694790652+4ac-ttm_pmd_jgg@nvidia.com Signed-off-by: Sasha Levin commit 1e520022ebb70af9c86bd745e6aa0c891cdf1bca Author: Heiner Kallweit Date: Wed Nov 3 22:08:28 2021 +0100 net: phy: fix duplex out of sync problem while changing settings [ Upstream commit a4db9055fdb9cf607775c66d39796caf6439ec92 ] As reported by Zhang there's a small issue if in forced mode the duplex mode changes with the link staying up [0]. In this case the MAC isn't notified about the change. The proposed patch relies on the phylib state machine and ignores the fact that there are drivers that uses phylib but not the phylib state machine. So let's don't change the behavior for such drivers and fix it w/o re-adding state PHY_FORCING for the case that phylib state machine is used. [0] https://lore.kernel.org/netdev/a5c26ffd-4ee4-a5e6-4103-873208ce0dc5@huawei.com/T/ Fixes: 2bd229df5e2e ("net: phy: remove state PHY_FORCING") Reported-by: Zhang Changzhong Tested-by: Zhang Changzhong Signed-off-by: Heiner Kallweit Link: https://lore.kernel.org/r/7b8b9456-a93f-abbc-1dc5-a2c2542f932c@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a3a5d0e13066fd93f4fdc9f337291ad6df0708a1 Author: Rafael J. Wysocki Date: Wed Nov 3 19:43:47 2021 +0100 cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline [ Upstream commit dbea75fe18f60e364de6d994fc938a24ba249d81 ] Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") caused intel_pstate to use nonzero HWP desired values in certain usage scenarios, but it did not prevent them from being leaked into the confugirations in which HWP desired is expected to be 0. The failing scenarios are switching the driver from the passive mode to the active mode and starting a new kernel via kexec() while intel_pstate is running in the passive mode. To address this issue, ensure that HWP desired will be cleared on offline and suspend/shutdown. Fixes: a365ab6b9dfb ("cpufreq: intel_pstate: Implement the ->adjust_perf() callback") Reported-by: Julia Lawall Tested-by: Julia Lawall Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit d79404b45c1082c946d22437368447e5e81528d9 Author: Selvin Xavier Date: Sat Sep 11 03:03:05 2021 -0700 PCI: Do not enable AtomicOps on VFs [ Upstream commit 5ec0a6fcb60ea430f8ee7e0bec22db9b22f856d3 ] Host crashes when pci_enable_atomic_ops_to_root() is called for VFs with virtual buses. The virtual buses added to SR-IOV have bus->self set to NULL and host crashes due to this. PID: 4481 TASK: ffff89c6941b0000 CPU: 53 COMMAND: "bash" ... #3 [ffff9a9481713808] oops_end at ffffffffb9025cd6 #4 [ffff9a9481713828] page_fault_oops at ffffffffb906e417 #5 [ffff9a9481713888] exc_page_fault at ffffffffb9a0ad14 #6 [ffff9a94817138b0] asm_exc_page_fault at ffffffffb9c00ace [exception RIP: pcie_capability_read_dword+28] RIP: ffffffffb952fd5c RSP: ffff9a9481713960 RFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff89c6b1096000 RCX: 0000000000000000 RDX: ffff9a9481713990 RSI: 0000000000000024 RDI: 0000000000000000 RBP: 0000000000000080 R8: 0000000000000008 R9: ffff89c64341a2f8 R10: 0000000000000002 R11: 0000000000000000 R12: ffff89c648bab000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff89c648bab0c8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9a9481713988] pci_enable_atomic_ops_to_root at ffffffffb95359a6 #8 [ffff9a94817139c0] bnxt_qplib_determine_atomics at ffffffffc08c1a33 [bnxt_re] #9 [ffff9a94817139d0] bnxt_re_dev_init at ffffffffc08ba2d1 [bnxt_re] Per PCIe r5.0, sec 9.3.5.10, the AtomicOp Requester Enable bit in Device Control 2 is reserved for VFs. The PF value applies to all associated VFs. Return -EINVAL if pci_enable_atomic_ops_to_root() is called for a VF. Link: https://lore.kernel.org/r/1631354585-16597-1-git-send-email-selvin.xavier@broadcom.com Fixes: 35f5ace5dea4 ("RDMA/bnxt_re: Enable global atomic ops if platform supports") Fixes: 430a23689dea ("PCI: Add pci_enable_atomic_ops_to_root()") Signed-off-by: Selvin Xavier Signed-off-by: Bjorn Helgaas Reviewed-by: Andy Gospodarek Signed-off-by: Sasha Levin commit 267a022590e3754481df650e4c616281d113651f Author: Tetsuo Handa Date: Wed Nov 3 16:04:33 2021 -0700 ataflop: remove ataflop_probe_lock mutex [ Upstream commit 4ddb85d36613c45bde00d368bf9f357bd0708a0c ] Commit bf9c0538e485b591 ("ataflop: use a separate gendisk for each media format") introduced ataflop_probe_lock mutex, but forgot to unlock the mutex when atari_floppy_init() (i.e. module loading) succeeded. This will result in double lock deadlock if ataflop_probe() is called. Also, unregister_blkdev() must not be called from atari_floppy_init() with ataflop_probe_lock held when atari_floppy_init() failed, for ataflop_probe() waits for ataflop_probe_lock with major_names_lock held (i.e. AB-BA deadlock). __register_blkdev() needs to be called last in order to avoid calling ataflop_probe() when atari_floppy_init() is about to fail, for memory for completing already-started ataflop_probe() safely will be released as soon as atari_floppy_init() released ataflop_probe_lock mutex. As with commit 8b52d8be86d72308 ("loop: reorder loop_exit"), unregister_blkdev() needs to be called first in order to avoid calling ataflop_alloc_disk() from ataflop_probe() after del_gendisk() from atari_floppy_exit(). By relocating __register_blkdev() / unregister_blkdev() as explained above, we can remove ataflop_probe_lock mutex, for probe function and __exit function are serialized by major_names_lock mutex. Signed-off-by: Tetsuo Handa Fixes: bf9c0538e485b591 ("ataflop: use a separate gendisk for each media format") Reviewed-by: Luis Chamberlain Tested-by: Michael Schmitz Link: https://lore.kernel.org/r/20211103230437.1639990-11-mcgrof@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4972bb9f92668c27a28e2a14f24e32d67c325b69 Author: Luis Chamberlain Date: Mon Sep 27 15:03:01 2021 -0700 block/ataflop: provide a helper for cleanup up an atari disk [ Upstream commit deae1138d04758c7f8939fcb8aee330bc37e3015 ] Instead of using two separate code paths for cleaning up an atari disk, use one. We take the more careful approach to check for *all* disk types, as is done on exit. The init path didn't have that check as the alternative disk types are only probed for later, they are not initialized by default. Yes, there is a shared tag for all disks. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210927220302.1073499-14-mcgrof@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4f6264ed34b69da329d0c681701e6ebe12c381b1 Author: Luis Chamberlain Date: Mon Sep 27 15:03:00 2021 -0700 block/ataflop: add registration bool before calling del_gendisk() [ Upstream commit 573effb298011d3fcabc9b12025cf637f8a07911 ] The ataflop assumes del_gendisk() is safe to call, this is only true because add_disk() does not return a failure, but that will change soon. And so, before we get to adding error handling for that case, let's make sure we keep track of which disks actually get registered. Then we use this to only call del_gendisk for them. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210927220302.1073499-13-mcgrof@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ff8f1a821132067b0798fecfb6d67329be3948ad Author: Luis Chamberlain Date: Mon Sep 27 15:02:59 2021 -0700 block/ataflop: use the blk_cleanup_disk() helper [ Upstream commit 44a469b6acae6ad05c4acca8429467d1d50a8b8d ] Use the helper to replace two lines with one. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210927220302.1073499-12-mcgrof@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5921ada07f55a4b02939c9667211ae2568a72d62 Author: Chenyuan Mi Date: Tue Sep 7 20:26:33 2021 +0800 drm/nouveau/svm: Fix refcount leak bug and missing check against null bug [ Upstream commit 6bb8c2d51811eb5e6504f49efe3b089d026009d2 ] The reference counting issue happens in one exception handling path of nouveau_svmm_bind(). When cli->svm.svmm is null, the function forgets to decrease the refcount of mm increased by get_task_mm(), causing a refcount leak. Fix this issue by using mmput() to decrease the refcount in the exception handling path. Also, the function forgets to do check against null when get mm by get_task_mm(). Fix this issue by adding null check after get mm by get_task_mm(). Signed-off-by: Chenyuan Mi Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Fixes: 822cab6150d3 ("drm/nouveau/svm: check for SVM initialized before migrating") Reviewed-by: Lyude Paul Reviewed-by: Ben Skeggs Reviewed-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20210907122633.16665-1-cymi20@fudan.edu.cn Link: https://gitlab.freedesktop.org/drm/nouveau/-/merge_requests/14 Signed-off-by: Sasha Levin commit 86b53a83c55b983009d220523e398a3e5292cfb1 Author: Luis Chamberlain Date: Wed Nov 3 09:58:43 2021 -0700 nvdimm/btt: do not call del_gendisk() if not needed [ Upstream commit 3aefb5ee843fbe4789d03bb181e190d462df95e4 ] del_gendisk() should not called if the disk has not been added. Fix this. Fixes: 41cd8b70c37a ("libnvdimm, btt: add support for blk integrity") Reviewed-by: Dan Williams Reviewed-by: Christoph Hellwig Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20211103165843.1402142-1-mcgrof@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 02dea719283f6bb6759425c553b2a9279f41fb3e Author: Christophe JAILLET Date: Sun Jun 27 13:46:24 2021 +0200 PCI: j721e: Fix j721e_pcie_probe() error path [ Upstream commit 496bb18483cc0474913e81e18a6b313aaea4c120 ] If an error occurs after a successful cdns_pcie_init_phy() call, it must be undone by a cdns_pcie_disable_phy() call, as already done above and below. Update the goto to branch at the correct place of the error handling path. Link: https://lore.kernel.org/r/db477b0cb444891a17c4bb424467667dc30d0bab.1624794264.git.christophe.jaillet@wanadoo.fr Fixes: 49e0efdce791 ("PCI: j721e: Add support to provide refclk to PCIe connector") Signed-off-by: Christophe JAILLET Signed-off-by: Lorenzo Pieralisi Signed-off-by: Bjorn Helgaas Reviewed-by: Krzysztof Wilczyński Signed-off-by: Sasha Levin commit 01b47659d9d1090dc8f941e093bae46f29aa82b4 Author: Hans de Goede Date: Sun Oct 31 16:31:35 2021 +0100 ACPI: PMIC: Fix intel_pmic_regs_handler() read accesses [ Upstream commit 009a789443fe4c8e6b1ecb7c16b4865c026184cd ] The handling of PMIC register reads through writing 0 to address 4 of the OpRegion is wrong. Instead of returning the read value through the value64, which is a no-op for function == ACPI_WRITE calls, store the value and then on a subsequent function == ACPI_READ with address == 3 (the address for the value field of the OpRegion) return the stored value. This has been tested on a Xiaomi Mi Pad 2 and makes the ACPI battery dev there mostly functional (unfortunately there are still other issues). Here are the SET() / GET() functions of the PMIC ACPI device, which use this OpRegion, which clearly show the new behavior to be correct: OperationRegion (REGS, 0x8F, Zero, 0x50) Field (REGS, ByteAcc, NoLock, Preserve) { CLNT, 8, SA, 8, OFF, 8, VAL, 8, RWM, 8 } Method (GET, 3, Serialized) { If ((AVBE == One)) { CLNT = Arg0 SA = Arg1 OFF = Arg2 RWM = Zero If ((AVBG == One)) { GPRW = Zero } } Return (VAL) /* \_SB_.PCI0.I2C7.PMI5.VAL_ */ } Method (SET, 4, Serialized) { If ((AVBE == One)) { CLNT = Arg0 SA = Arg1 OFF = Arg2 VAL = Arg3 RWM = One If ((AVBG == One)) { GPRW = One } } } Fixes: 0afa877a5650 ("ACPI / PMIC: intel: add REGS operation region support") Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit bbe42d65433a87a30ae0b6b0b18b54ecaf9f9e0d Author: Brett Creeley Date: Thu Sep 9 14:38:08 2021 -0700 ice: Fix not stopping Tx queues for VFs [ Upstream commit b385cca47363316c6d9a74ae9db407bbc281f815 ] When a VF is removed and/or reset its Tx queues need to be stopped from the PF. This is done by calling the ice_dis_vf_qs() function, which calls ice_vsi_stop_lan_tx_rings(). Currently ice_dis_vf_qs() is protected by the VF state bit ICE_VF_STATE_QS_ENA. Unfortunately, this is causing the Tx queues to not be disabled in some cases and when the VF tries to re-enable/reconfigure its Tx queues over virtchnl the op is failing. This is because a VF can be reset and/or removed before the ICE_VF_STATE_QS_ENA bit is set, but the Tx queues were already configured via ice_vsi_cfg_single_txq() in the VIRTCHNL_OP_CONFIG_VSI_QUEUES op. However, the ICE_VF_STATE_QS_ENA bit is set on a successful VIRTCHNL_OP_ENABLE_QUEUES, which will always happen after the VIRTCHNL_OP_CONFIG_VSI_QUEUES op. This was causing the following error message when loading the ice driver, creating VFs, and modifying VF trust in an endless loop: [35274.192484] ice 0000:88:00.0: Failed to set LAN Tx queue context, error: ICE_ERR_PARAM [35274.193074] ice 0000:88:00.0: VF 0 failed opcode 6, retval: -5 [35274.193640] iavf 0000:88:01.0: PF returned error -5 (IAVF_ERR_PARAM) to our request 6 Fix this by always calling ice_dis_vf_qs() and silencing the error message in ice_vsi_stop_tx_ring() since the calling code ignores the return anyway. Also, all other places that call ice_vsi_stop_tx_ring() catch the error, so this doesn't affect those flows since there was no change to the values the function returns. Other solutions were considered (i.e. tracking which VF queues had been "started/configured" in VIRTCHNL_OP_CONFIG_VSI_QUEUES, but it seemed more complicated than it was worth. This solution also brings in the chance for other unexpected conditions due to invalid state bit checks. So, the proposed solution seemed like the best option since there is no harm in failing to stop Tx queues that were never started. This issue can be seen using the following commands: for i in {0..50}; do rmmod ice modprobe ice sleep 1 echo 1 > /sys/class/net/ens785f0/device/sriov_numvfs echo 1 > /sys/class/net/ens785f1/device/sriov_numvfs ip link set ens785f1 vf 0 trust on ip link set ens785f0 vf 0 trust on sleep 2 echo 0 > /sys/class/net/ens785f0/device/sriov_numvfs echo 0 > /sys/class/net/ens785f1/device/sriov_numvfs sleep 1 echo 1 > /sys/class/net/ens785f0/device/sriov_numvfs echo 1 > /sys/class/net/ens785f1/device/sriov_numvfs ip link set ens785f1 vf 0 trust on ip link set ens785f0 vf 0 trust on done Fixes: 77ca27c41705 ("ice: add support for virtchnl_queue_select.[tx|rx]_queues bitmap") Signed-off-by: Brett Creeley Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit b15d8035cdb78444228994c42ff324e1272c99d2 Author: Sylwester Dziedziuch Date: Thu May 6 08:40:03 2021 -0700 ice: Fix replacing VF hardware MAC to existing MAC filter [ Upstream commit ce572a5b88d5ca6737b5e23da9892792fd708ad3 ] VF was not able to change its hardware MAC address in case the new address was already present in the MAC filter list. Change the handling of VF add mac request to not return if requested MAC address is already present on the list and check if its hardware MAC needs to be updated in this case. Fixes: ed4c068d46f6 ("ice: Enable ip link show on the PF to display VF unicast MAC(s)") Signed-off-by: Sylwester Dziedziuch Tested-by: Tony Brelinski Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit ff5b62b0decbcd3222106ecaf37ab53170de74ef Author: Vladimir Oltean Date: Tue Nov 2 21:31:22 2021 +0200 net: dsa: felix: fix broken VLAN-tagged PTP under VLAN-aware bridge [ Upstream commit 92f62485b3715882cd397b0cbd80a96d179b86d6 ] Normally it is expected that the dsa_device_ops :: rcv() method finishes parsing the DSA tag and consumes it, then never looks at it again. But commit c0bcf537667c ("net: dsa: ocelot: add hardware timestamping support for Felix") added support for RX timestamping in a very unconventional way. On this switch, a partial timestamp is available in the DSA header, but the driver got away with not parsing that timestamp right away, but instead delayed that parsing for a little longer: dsa_switch_rcv(): nskb = cpu_dp->rcv(skb, dev); <------------- not here -> ocelot_rcv() ... skb = nskb; skb_push(skb, ETH_HLEN); skb->pkt_type = PACKET_HOST; skb->protocol = eth_type_trans(skb, skb->dev); ... if (dsa_skb_defer_rx_timestamp(p, skb)) <--- but here -> felix_rxtstamp() return 0; When in felix_rxtstamp(), this driver accounted for the fact that eth_type_trans() happened in the meanwhile, so it got a hold of the extraction header again by subtracting (ETH_HLEN + OCELOT_TAG_LEN) bytes from the current skb->data. This worked for quite some time but was quite fragile from the very beginning. Not to mention that having DSA tag parsing split in two different files, under different folders (net/dsa/tag_ocelot.c vs drivers/net/dsa/ocelot/felix.c) made it quite non-obvious for patches to come that they might break this. Finally, the blamed commit does the following: at the end of ocelot_rcv(), it checks whether the skb payload contains a VLAN header. If it does, and this port is under a VLAN-aware bridge, that VLAN ID might not be correct in the sense that the packet might have suffered VLAN rewriting due to TCAM rules (VCAP IS1). So we consume the VLAN ID from the skb payload using __skb_vlan_pop(), and take the classified VLAN ID from the DSA tag, and construct a hwaccel VLAN tag with the classified VLAN, and the skb payload is VLAN-untagged. The big problem is that __skb_vlan_pop() does: memmove(skb->data + VLAN_HLEN, skb->data, 2 * ETH_ALEN); __skb_pull(skb, VLAN_HLEN); aka it moves the Ethernet header 4 bytes to the right, and pulls 4 bytes from the skb headroom (effectively also moving skb->data, by definition). So for felix_rxtstamp()'s fragile logic, all bets are off now. Instead of having the "extraction" pointer point to the DSA header, it actually points to 4 bytes _inside_ the extraction header. Corollary, the last 4 bytes of the "extraction" header are in fact 4 stale bytes of the destination MAC address from the Ethernet header, from prior to the __skb_vlan_pop() movement. So of course, RX timestamps are completely bogus when the system is configured in this way. The fix is actually very simple: just don't structure the code like that. For better or worse, the DSA PTP timestamping API does not offer a straightforward way for drivers to present their RX timestamps, but other drivers (sja1105) have established a simple mechanism to carry their RX timestamp from dsa_device_ops :: rcv() all the way to dsa_switch_ops :: port_rxtstamp() and even later. That mechanism is to simply save the partial timestamp to the skb->cb, and complete it later. Question: why don't we simply populate the skb's struct skb_shared_hwtstamps from ocelot_rcv(), and bother with this complication of propagating the timestamp to felix_rxtstamp()? Answer: dsa_switch_ops :: port_rxtstamp() answers the question whether PTP packets need sleepable context to retrieve the full RX timestamp. Currently felix_rxtstamp() answers "no, thanks" to that question, and calls ocelot_ptp_gettime64() from softirq atomic context. This is understandable, since Felix VSC9959 is a PCIe memory-mapped switch, so hardware access does not require sleeping. But the felix driver is preparing for the introduction of other switches where hardware access is over a slow bus like SPI or MDIO: https://lore.kernel.org/lkml/20210814025003.2449143-1-colin.foster@in-advantage.com/ So I would like to keep this code structure, so the rework needed when that driver will need PTP support will be minimal (answer "yes, I need deferred context for this skb's RX timestamp", then the partial timestamp will still be found in the skb->cb. Fixes: ea440cd2d9b2 ("net: dsa: tag_ocelot: use VLAN information from tagging header when available") Reported-by: Po Liu Cc: Yangbo Lu Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1554b63d8751bdf5f6f3121034a5e4cfe362bb9c Author: Vladimir Oltean Date: Tue Oct 12 14:40:40 2021 +0300 net: dsa: tag_ocelot: break circular dependency with ocelot switch lib driver [ Upstream commit deab6b1cd9789bb9bd466d5e76aecb8b336259b4 ] As explained here: https://lore.kernel.org/netdev/20210908220834.d7gmtnwrorhharna@skbuf/ DSA tagging protocol drivers cannot depend on symbols exported by switch drivers, because this creates a circular dependency that breaks module autoloading. The tag_ocelot.c file depends on the ocelot_ptp_rew_op() function exported by the common ocelot switch lib. This function looks at OCELOT_SKB_CB(skb) and computes how to populate the REW_OP field of the DSA tag, for PTP timestamping (the command: one-step/two-step, and the TX timestamp identifier). None of that requires deep insight into the driver, it is quite stateless, as it only depends upon the skb->cb. So let's make it a static inline function and put it in include/linux/dsa/ocelot.h, a file that despite its name is used by the ocelot switch driver for populating the injection header too - since commit 40d3f295b5fe ("net: mscc: ocelot: use common tag parsing code with DSA"). With that function declared as static inline, its body is expanded inside each call site, so the dependency is broken and the DSA tagger can be built without the switch library, upon which the felix driver depends. Fixes: 39e5308b3250 ("net: mscc: ocelot: support PTP Sync one-step timestamping") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fca96b3f852a1b369b7b2844ce357cd689879934 Author: Ziyang Xuan Date: Tue Nov 2 10:12:18 2021 +0800 net: vlan: fix a UAF in vlan_dev_real_dev() [ Upstream commit 563bcbae3ba233c275c244bfce2efe12938f5363 ] The real_dev of a vlan net_device may be freed after unregister_vlan_dev(). Access the real_dev continually by vlan_dev_real_dev() will trigger the UAF problem for the real_dev like following: ================================================================== BUG: KASAN: use-after-free in vlan_dev_real_dev+0xf9/0x120 Call Trace: kasan_report.cold+0x83/0xdf vlan_dev_real_dev+0xf9/0x120 is_eth_port_of_netdev_filter.part.0+0xb1/0x2c0 is_eth_port_of_netdev_filter+0x28/0x40 ib_enum_roce_netdev+0x1a3/0x300 ib_enum_all_roce_netdevs+0xc7/0x140 netdevice_event_work_handler+0x9d/0x210 ... Freed by task 9288: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0xfc/0x130 slab_free_freelist_hook+0xdd/0x240 kfree+0xe4/0x690 kvfree+0x42/0x50 device_release+0x9f/0x240 kobject_put+0x1c8/0x530 put_device+0x1b/0x30 free_netdev+0x370/0x540 ppp_destroy_interface+0x313/0x3d0 ... Move the put_device(real_dev) to vlan_dev_free(). Ensure real_dev not be freed before vlan_dev unregistered. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: syzbot+e4df4e1389e28972e955@syzkaller.appspotmail.com Signed-off-by: Ziyang Xuan Reviewed-by: Jason Gunthorpe Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7f639a03e4ab6b611b7d32fffd4ebde6bb5378fa Author: Stafford Horne Date: Wed Nov 3 20:19:33 2021 +0900 openrisc: fix SMP tlb flush NULL pointer dereference [ Upstream commit 27dff9a9c247d4e38d82c2e7234914cfe8499294 ] Throughout the OpenRISC kernel port VMA is passed as NULL when flushing kernel tlb entries. Somehow this was missed when I was testing c28b27416da9 ("openrisc: Implement proper SMP tlb flushing") and now the SMP kernel fails to completely boot. In OpenRISC VMA is used only to determine which cores need to have their TLB entries flushed. This patch updates the logic to flush tlbs on all cores when the VMA is passed as NULL. Also, we update places VMA is passed as NULL to use flush_tlb_kernel_range instead. Now, the only place VMA is passed as NULL is in the implementation of flush_tlb_kernel_range. Fixes: c28b27416da9 ("openrisc: Implement proper SMP tlb flushing") Reported-by: Jan Henrik Weinstock Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit e75b136530ce8bade0b925bbfca5d8c2f8c61695 Author: Jakub Kicinski Date: Tue Nov 2 15:02:36 2021 -0700 ethtool: fix ethtool msg len calculation for pause stats [ Upstream commit 1aabe578dd86e9f2867c4db4fba9a15f4ba1825d ] ETHTOOL_A_PAUSE_STAT_MAX is the MAX attribute id, so we need to subtract non-stats and add one to get a count (IOW -2+1 == -1). Otherwise we'll see: ethnl cmd 21: calculated reply length 40, but consumed 52 Fixes: 9a27a33027f2 ("ethtool: add standard pause stats") Signed-off-by: Jakub Kicinski Reviewed-by: Saeed Mahameed Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f776103499bf0e850f6334b6d6d0b8d02893d941 Author: Hangbin Liu Date: Wed Nov 3 10:44:55 2021 +0800 kselftests/net: add missed icmp.sh test to Makefile [ Upstream commit ca3676f94b8f40f52d285f9aef36dfd6725bfc14 ] When generating the selftests to another folder, the icmp.sh test will miss as it is not in Makefile, e.g. make -C tools/testing/selftests/ install \ TARGETS="net" INSTALL_PATH=/tmp/kselftests Fixes: 7e9838b7915e ("selftests/net: Add icmp.sh for testing ICMP dummy address responses") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d2afb868adc954ee17859d109e1bfb9084e2e2ee Author: Maxim Kiselev Date: Mon Nov 1 18:23:41 2021 +0300 net: davinci_emac: Fix interrupt pacing disable [ Upstream commit d52bcb47bdf971a59a2467975d2405fcfcb2fa19 ] This patch allows to use 0 for `coal->rx_coalesce_usecs` param to disable rx irq coalescing. Previously we could enable rx irq coalescing via ethtool (For ex: `ethtool -C eth0 rx-usecs 2000`) but we couldn't disable it because this part rejects 0 value: if (!coal->rx_coalesce_usecs) return -EINVAL; Fixes: 84da2658a619 ("TI DaVinci EMAC : Implement interrupt pacing functionality.") Signed-off-by: Maxim Kiselev Reviewed-by: Grygorii Strashko Link: https://lore.kernel.org/r/20211101152343.4193233-1-bigunclemax@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 5ed0d8c6af5346d543e36f79e3220d19a25c0583 Author: Yu Kuai Date: Tue Nov 2 09:52:35 2021 +0800 nbd: fix possible overflow for 'first_minor' in nbd_dev_add() [ Upstream commit 940c264984fd1457918393c49674f6b39ee16506 ] If 'part_shift' is not zero, then 'index << part_shift' might overflow to a value that is not greater than '0xfffff', then sysfs might complains about duplicate creation. Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices") Signed-off-by: Yu Kuai Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20211102015237.2309763-3-yebin10@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 69f35664ee1ff4d53855221d4ca52be45d737a34 Author: Yu Kuai Date: Tue Nov 2 09:52:34 2021 +0800 nbd: fix max value for 'first_minor' [ Upstream commit e4c4871a73944353ea23e319de27ef73ce546623 ] commit b1a811633f73 ("block: nbd: add sanity check for first_minor") checks that 'first_minor' should not be greater than 0xff, which is wrong. Whitout the commit, the details that when user pass 0x100000, it ends up create sysfs dir "/sys/block/43:0" are as follows: nbd_dev_add disk->first_minor = index << part_shift -> default part_shift is 5, first_minor is 0x2000000 device_add_disk ddev->devt = MKDEV(disk->major, disk->first_minor) -> (0x2b << 20) | (0x2000000) = 0x2b00000 device_add device_create_sys_dev_entry format_dev_t sprintf(buffer, "%u:%u", MAJOR(dev), MINOR(dev)); -> got 43:0 sysfs_create_link -> /sys/block/43:0 By the way, with the wrong fix, when part_shift is the default value, only 8 ndb devices can be created since 8 << 5 is greater than 0xff. Since the max bits for 'first_minor' should be the same as what MKDEV() does, which is 20. Change the upper bound of 'first_minor' from 0xff to 0xfffff. Fixes: b1a811633f73 ("block: nbd: add sanity check for first_minor") Signed-off-by: Yu Kuai Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20211102015237.2309763-2-yebin10@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 40804b6959fa3cac218e7961997ba8c3d5263697 Author: YueHaibing Date: Fri Oct 8 15:44:17 2021 +0800 xen-pciback: Fix return in pm_ctrl_init() [ Upstream commit 4745ea2628bb43a7ec34b71763b5a56407b33990 ] Return NULL instead of passing to ERR_PTR while err is zero, this fix smatch warnings: drivers/xen/xen-pciback/conf_space_capability.c:163 pm_ctrl_init() warn: passing zero to 'ERR_PTR' Fixes: a92336a1176b ("xen/pciback: Drop two backends, squash and cleanup some code.") Signed-off-by: YueHaibing Reviewed-by: Juergen Gross Link: https://lore.kernel.org/r/20211008074417.8260-1-yuehaibing@huawei.com Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 3612fdf488d5130e716aaab87b2cfdd0d2d4f89a Author: Sander Vanheule Date: Thu Oct 28 10:52:43 2021 +0200 gpio: realtek-otto: fix GPIO line IRQ offset [ Upstream commit 585a07079909ba9061ddd88214c36653e1aef71a ] The irqchip uses one domain for all GPIO lines, so the line offset should be determined w.r.t. the first line of the first port, not the first line of the triggered port. Fixes: 0d82fb1127fb ("gpio: Add Realtek Otto GPIO support") Signed-off-by: Sander Vanheule Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit c64b55c85fb2aaa0da1c42b667cadd47be9fda90 Author: Christophe JAILLET Date: Thu Aug 19 22:48:08 2021 +0200 i2c: xlr: Fix a resource leak in the error handling path of 'xlr_i2c_probe()' [ Upstream commit 7f98960c046ee1136e7096aee168eda03aef8a5d ] A successful 'clk_prepare()' call should be balanced by a corresponding 'clk_unprepare()' call in the error handling path of the probe, as already done in the remove function. More specifically, 'clk_prepare_enable()' is used, but 'clk_disable()' is also already called. So just the unprepare step has still to be done. Update the error handling path accordingly. Fixes: 75d31c2372e4 ("i2c: xlr: add support for Sigma Designs controller variant") Signed-off-by: Christophe JAILLET Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 60e8a9733d824648d1c7c124125f415903597c76 Author: Trond Myklebust Date: Tue Oct 26 21:56:40 2021 -0400 NFSv4: Fix a regression in nfs_set_open_stateid_locked() [ Upstream commit 01d29f87fcfef38d51ce2b473981a5c1e861ac0a ] If we already hold open state on the client, yet the server gives us a completely different stateid to the one we already hold, then we currently treat it as if it were an out-of-sequence update, and wait for 5 seconds for other updates to come in. This commit fixes the behaviour so that we immediately start processing of the new stateid, and then leave it to the call to nfs4_test_and_free_stateid() to decide what to do with the old stateid. Fixes: b4868b44c562 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 288be49e2e2e28ff369e700b67f9067e2b4733c7 Author: Quinn Tran Date: Tue Oct 26 04:54:02 2021 -0700 scsi: qla2xxx: Turn off target reset during issue_lip [ Upstream commit 0b7a9fd934a68ebfc1019811b7bdc1742072ad7b ] When user uses issue_lip to do link bounce, driver sends additional target reset to remote device before resetting the link. The target reset would affect other paths with active I/Os. This patch will remove the unnecessary target reset. Link: https://lore.kernel.org/r/20211026115412.27691-4-njavali@marvell.com Fixes: 5854771e314e ("[SCSI] qla2xxx: Add ISPFX00 specific bus reset routine") Reviewed-by: Himanshu Madhani Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 66adfc54bd79def5b2e8dc40dba2d6b41e53c8a6 Author: Quinn Tran Date: Tue Oct 26 04:54:01 2021 -0700 scsi: qla2xxx: Fix gnl list corruption [ Upstream commit c98c5daaa24b583cba1369b7d167f93c6ae7299c ] Current code does list element deletion and addition in and out of lock protection. This patch moves deletion behind lock. list_add double add: new=ffff9130b5eb89f8, prev=ffff9130b5eb89f8, next=ffff9130c6a715f0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:31! invalid opcode: 0000 [#1] SMP PTI CPU: 1 PID: 182395 Comm: kworker/1:37 Kdump: loaded Tainted: G W OE --------- - - 4.18.0-193.el8.x86_64 #1 Hardware name: HP ProLiant DL160 Gen8, BIOS J03 02/10/2014 Workqueue: qla2xxx_wq qla2x00_iocb_work_fn [qla2xxx] RIP: 0010:__list_add_valid+0x41/0x50 Code: 85 94 00 00 00 48 39 c7 74 0b 48 39 d7 74 06 b8 01 00 00 00 c3 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 60 83 ad 97 e8 4d bd ce ff <0f> 0b 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 48 8b 07 48 8b 57 08 RSP: 0018:ffffaba306f47d68 EFLAGS: 00010046 RAX: 0000000000000058 RBX: ffff9130b5eb8800 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff9130b7456a00 RBP: ffff9130c6a70a58 R08: 000000000008d7be R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: ffff9130c6a715f0 R13: ffff9130b5eb8824 R14: ffff9130b5eb89f8 R15: ffff9130b5eb89f8 FS: 0000000000000000(0000) GS:ffff9130b7440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007efcaaef11a0 CR3: 000000005200a002 CR4: 00000000000606e0 Call Trace: qla24xx_async_gnl+0x113/0x3c0 [qla2xxx] ? qla2x00_iocb_work_fn+0x53/0x80 [qla2xxx] ? process_one_work+0x1a7/0x3b0 ? worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 ? kthread+0x112/0x130 Link: https://lore.kernel.org/r/20211026115412.27691-3-njavali@marvell.com Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery") Reviewed-by: Himanshu Madhani Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7c32b407ef0ab23d996d666f32fb9b3d795f33f5 Author: Dmitry Bogdanov Date: Mon Oct 18 16:57:53 2021 +0300 scsi: target: core: Remove from tmr_list during LUN unlink [ Upstream commit 12b6fcd0ea7f3cb7c3b34668fc678779924123ae ] Currently TMF commands are removed from de_device.dev_tmf_list at the very end of se_cmd lifecycle. However, se_lun unlinks from se_cmd upon a command status (response) being queued in transport layer. This means that LUN and backend device can be deleted in the meantime and a panic will occur: target_tmr_work() cmd->se_tfo->queue_tm_rsp(cmd); // send abort_rsp to a wire transport_lun_remove_cmd(cmd) // unlink se_cmd from se_lun - // - // - // - <<<--- lun remove <<<--- core backend device remove - // - // - // - qlt_handle_abts_completion() tfo->free_mcmd() transport_generic_free_cmd() target_put_sess_cmd() core_tmr_release_req() { if (dev) { // backend device, can not be null spin_lock_irqsave(&dev->se_tmr_lock, flags); //<<<--- CRASH Call Trace: NIP [c000000000e1683c] _raw_spin_lock_irqsave+0x2c/0xc0 LR [c00800000e433338] core_tmr_release_req+0x40/0xa0 [target_core_mod] Call Trace: (unreliable) 0x0 target_put_sess_cmd+0x2a0/0x370 [target_core_mod] transport_generic_free_cmd+0x6c/0x1b0 [target_core_mod] tcm_qla2xxx_complete_mcmd+0x28/0x50 [tcm_qla2xxx] process_one_work+0x2c4/0x5c0 worker_thread+0x88/0x690 For the iSCSI protocol this is easily reproduced: - Send some SCSI sommand - Send Abort of that command over iSCSI - Remove LUN on target - Send next iSCSI command to acknowledge the Abort_Response - Target panics There is no need to keep the command in tmr_list until response completion, so move the removal from tmr_list from the response completion to the response queueing when the LUN is unlinked. Move the removal from state list too as it is a subject to the same race condition. Link: https://lore.kernel.org/r/20211018135753.15297-1-d.bogdanov@yadro.com Fixes: c66ac9db8d4a ("[SCSI] target: Add LIO target core v4.0.0-rc6") Reviewed-by: Roman Bolshakov Reviewed-by: Mike Christie Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bac37c7433c5d88c669d29427f393d1489dd7af8 Author: Jackie Liu Date: Tue Sep 7 10:49:04 2021 +0800 ar7: fix kernel builds for compiler test [ Upstream commit 28b7ee33a2122569ac065cad578bf23f50cc65c3 ] TI AR7 Watchdog Timer is only build for 32bit. Avoid error like: In file included from drivers/watchdog/ar7_wdt.c:29: ./arch/mips/include/asm/mach-ar7/ar7.h: In function ‘ar7_is_titan’: ./arch/mips/include/asm/mach-ar7/ar7.h:111:24: error: implicit declaration of function ‘KSEG1ADDR’; did you mean ‘CKSEG1ADDR’? [-Werror=implicit-function-declaration] 111 | return (readl((void *)KSEG1ADDR(AR7_REGS_GPIO + 0x24)) & 0xffff) == | ^~~~~~~~~ | CKSEG1ADDR Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Jackie Liu Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20210907024904.4127611-1-liu.yun@linux.dev Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 85b7c9ef119b1c11bc8ceb16485f1ef2120dfb1c Author: Ahmad Fatoum Date: Mon Aug 9 18:20:31 2021 +0200 watchdog: f71808e_wdt: fix inaccurate report in WDIOC_GETTIMEOUT [ Upstream commit 164483c735190775f29d0dcbac0363adc51a068d ] The fintek watchdog timer can configure timeouts of second granularity only up to 255 seconds. Beyond that, the timeout needs to be configured with minute granularity. WDIOC_GETTIMEOUT should report the actual timeout configured, not just echo back the timeout configured by the user. Do so. Fixes: 96cb4eb019ce ("watchdog: f71808e_wdt: new watchdog driver for Fintek F71808E and F71882FG") Suggested-by: Guenter Roeck Reviewed-by: Guenter Roeck Signed-off-by: Ahmad Fatoum Link: https://lore.kernel.org/r/5e17960fe8cc0e3cb2ba53de4730b75d9a0f33d5.1628525954.git-series.a.fatoum@pengutronix.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit bae8c19f3063489378b7837717ffdee546b0275f Author: Randy Dunlap Date: Sat Oct 2 17:02:23 2021 -0700 m68k: set a default value for MEMORY_RESERVE [ Upstream commit 1aaa557b2db95c9506ed0981bc34505c32d6b62b ] 'make randconfig' can produce a .config file with "CONFIG_MEMORY_RESERVE=" (no value) since it has no default. When a subsequent 'make all' is done, kconfig restarts the config and prompts for a value for MEMORY_RESERVE. This breaks scripting/automation where there is no interactive user input. Add a default value for MEMORY_RESERVE. (Any integer value will work here for kconfig.) Fixes a kconfig warning: .config:214:warning: symbol value '' invalid for MEMORY_RESERVE * Restart config... Memory reservation (MiB) (MEMORY_RESERVE) [] (NEW) Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") # from beginning of git history Signed-off-by: Randy Dunlap Reviewed-by: Geert Uytterhoeven Cc: Greg Ungerer Cc: linux-m68k@lists.linux-m68k.org Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 9c30504d85d2714052eb0b6c1709cdb0a53e3b66 Author: Eric W. Biederman Date: Wed Oct 20 12:43:52 2021 -0500 signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL) [ Upstream commit ce0ee4e6ac99606f3945f4d47775544edc3f7985 ] Today the sh code allocates memory the first time a process uses the fpu. If that memory allocation fails, kill the affected task with force_sig(SIGKILL) rather than do_group_exit(SIGKILL). Calling do_group_exit from an exception handler can potentially lead to dead locks as do_group_exit is not designed to be called from interrupt context. Instead use force_sig(SIGKILL) to kill the userspace process. Sending signals in general and force_sig in particular has been tested from interrupt context so there should be no problems. Cc: Yoshinori Sato Cc: Rich Felker Cc: linux-sh@vger.kernel.org Fixes: 0ea820cf9bf5 ("sh: Move over to dynamically allocated FPU context.") Link: https://lkml.kernel.org/r/20211020174406.17889-6-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Signed-off-by: Sasha Levin commit ab91e1ea48db7777a2d70f61e8485952771c4181 Author: Lars-Peter Clausen Date: Sat Oct 23 15:41:01 2021 +0200 dmaengine: dmaengine_desc_callback_valid(): Check for `callback_result` [ Upstream commit e7e1e880b114ca640a2f280b0d5d38aed98f98c6 ] Before the `callback_result` callback was introduced drivers coded their invocation to the callback in a similar way to: if (cb->callback) { spin_unlock(&dma->lock); cb->callback(cb->callback_param); spin_lock(&dma->lock); } With the introduction of `callback_result` two helpers where introduced to transparently handle both types of callbacks. And drivers where updated to look like this: if (dmaengine_desc_callback_valid(cb)) { spin_unlock(&dma->lock); dmaengine_desc_callback_invoke(cb, ...); spin_lock(&dma->lock); } dmaengine_desc_callback_invoke() correctly handles both `callback_result` and `callback`. But we forgot to update the dmaengine_desc_callback_valid() function to check for `callback_result`. As a result DMA descriptors that use the `callback_result` rather than `callback` don't have their callback invoked by drivers that follow the pattern above. Fix this by checking for both `callback` and `callback_result` in dmaengine_desc_callback_valid(). Fixes: f067025bc676 ("dmaengine: add support to provide error result from a DMA transation") Signed-off-by: Lars-Peter Clausen Acked-by: Dave Jiang Link: https://lore.kernel.org/r/20211023134101.28042-1-lars@metafoo.de Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ea52aeeb0da1befa683878c21793fe171f7c7b1e Author: Florian Westphal Date: Wed Oct 20 18:08:10 2021 +0200 netfilter: nfnetlink_queue: fix OOB when mac header was cleared [ Upstream commit 5648b5e1169ff1d6d6a46c35c0b5fbebd2a5cbb2 ] On 64bit platforms the MAC header is set to 0xffff on allocation and also when a helper like skb_unset_mac_header() is called. dev_parse_header may call skb_mac_header() which assumes valid mac offset: BUG: KASAN: use-after-free in eth_header_parse+0x75/0x90 Read of size 6 at addr ffff8881075a5c05 by task nf-queue/1364 Call Trace: memcpy+0x20/0x60 eth_header_parse+0x75/0x90 __nfqnl_enqueue_packet+0x1a61/0x3380 __nf_queue+0x597/0x1300 nf_queue+0xf/0x40 nf_hook_slow+0xed/0x190 nf_hook+0x184/0x440 ip_output+0x1c0/0x2a0 nf_reinject+0x26f/0x700 nfqnl_recv_verdict+0xa16/0x18b0 nfnetlink_rcv_msg+0x506/0xe70 The existing code only works if the skb has a mac header. Fixes: 2c38de4c1f8da7 ("netfilter: fix looped (broad|multi)cast's MAC handling") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit fa46546d0871b3c8462777e2e6fa8c3961ea1bee Author: Robert-Ionut Alexa Date: Fri Apr 23 12:01:51 2021 +0300 soc: fsl: dpaa2-console: free buffer before returning from dpaa2_console_read [ Upstream commit 8120bd469f5525da229953c1197f2b826c0109f4 ] Free the kbuf buffer before returning from the dpaa2_console_read() function. The variable no longer goes out of scope, leaking the storage it points to. Fixes: c93349d8c170 ("soc: fsl: add DPAA2 console support") Signed-off-by: Robert-Ionut Alexa Signed-off-by: Ioana Ciornei Signed-off-by: Li Yang Signed-off-by: Sasha Levin commit a4a5ee9741eaf2a10814a25512aedb36fd4255a7 Author: Geert Uytterhoeven Date: Tue Oct 19 16:45:09 2021 +0200 auxdisplay: ht16k33: Fix frame buffer device blanking [ Upstream commit 840fe258332544aa7321921e1723d37b772af7a9 ] As the ht16k33 frame buffer sub-driver does not register an fb_ops.fb_blank() handler, blanking does not work: $ echo 1 > /sys/class/graphics/fb0/blank sh: write error: Invalid argument Fix this by providing a handler that always returns zero, to make sure blank events will be sent to the actual device handling the backlight. Reported-by: Robin van der Gracht Suggested-by: Robin van der Gracht Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller") Signed-off-by: Geert Uytterhoeven Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit 32d349f3e4eedeca0197480c83ffe230a2ec7d22 Author: Geert Uytterhoeven Date: Tue Oct 19 16:45:08 2021 +0200 auxdisplay: ht16k33: Connect backlight to fbdev [ Upstream commit 80f9eb70fd9276938f0a131f76d438021bfd8b34 ] Currently /sys/class/graphics/fb0/bl_curve is not accessible (-ENODEV), as the driver does not connect the backlight to the frame buffer device. Fix this moving backlight initialization up, and filling in fb_info.bl_dev. Fixes: 8992da44c6805d53 ("auxdisplay: ht16k33: Driver for LED controller") Signed-off-by: Geert Uytterhoeven Reviewed-by: Robin van der Gracht Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit be51f4ed87ede4a14b904febab8bf282c1e20d72 Author: Geert Uytterhoeven Date: Tue Oct 19 16:45:02 2021 +0200 auxdisplay: img-ascii-lcd: Fix lock-up when displaying empty string [ Upstream commit afcb5a811ff3ab3969f09666535eb6018a160358 ] While writing an empty string to a device attribute is a no-op, and thus does not need explicit safeguards, the user can still write a single newline to an attribute file: echo > .../message If that happens, img_ascii_lcd_display() trims the newline, yielding an empty string, and causing an infinite loop in img_ascii_lcd_scroll(). Fix this by adding a check for empty strings. Clear the display in case one is encountered. Fixes: 0cad855fbd083ee5 ("auxdisplay: img-ascii-lcd: driver for simple ASCII LCD displays") Signed-off-by: Geert Uytterhoeven Signed-off-by: Miguel Ojeda Signed-off-by: Sasha Levin commit cee0757bca0de94d6337908adc251b9880236df1 Author: Alexey Gladkov Date: Thu Oct 14 18:02:30 2021 +0200 Fix user namespace leak [ Upstream commit d5f458a979650e5ed37212f6134e4ee2b28cb6ed ] Fixes: 61ca2c4afd9d ("NFS: Only reference user namespace from nfs4idmap struct instead of cred") Signed-off-by: Alexey Gladkov Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 2892327b226cc53a1a93460e8abef16c0ccdd903 Author: Trond Myklebust Date: Tue Oct 5 14:05:02 2021 -0400 NFS: Fix an Oops in pnfs_mark_request_commit() [ Upstream commit f0caea8882a7412a2ad4d8274f0280cdf849c9e2 ] Olga reports seeing the following Oops when doing O_DIRECT writes to a pNFS flexfiles server: Oops: 0000 [#1] SMP PTI CPU: 1 PID: 234186 Comm: kworker/u8:1 Not tainted 5.15.0-rc4+ #4 Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.13.0-2.module+el8.3.0+7353+9de0a3cc 04/01/2014 Workqueue: nfsiod rpc_async_release [sunrpc] RIP: 0010:nfs_mark_request_commit+0x12/0x30 [nfs] Code: ff ff be 03 00 00 00 e8 ac 34 83 eb e9 29 ff ff ff e8 22 bc d7 eb 66 90 0f 1f 44 00 00 48 85 f6 74 16 48 8b 42 10 48 8b 40 18 <48> 8b 40 18 48 85 c0 74 05 e9 70 fc 15 ec 48 89 d6 e9 68 ed ff ff RSP: 0018:ffffa82f0159fe00 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8f3393141880 RCX: 0000000000000000 RDX: ffffa82f0159fe08 RSI: ffff8f3381252500 RDI: ffff8f3393141880 RBP: ffff8f33ac317c00 R08: 0000000000000000 R09: ffff8f3487724cb0 R10: 0000000000000008 R11: 0000000000000001 R12: 0000000000000001 R13: ffff8f3485bccee0 R14: ffff8f33ac317c10 R15: ffff8f33ac317cd8 FS: 0000000000000000(0000) GS:ffff8f34fbc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 0000000122120006 CR4: 0000000000770ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: nfs_direct_write_completion+0x13b/0x250 [nfs] rpc_free_task+0x39/0x60 [sunrpc] rpc_async_release+0x29/0x40 [sunrpc] process_one_work+0x1ce/0x370 worker_thread+0x30/0x380 ? process_one_work+0x370/0x370 kthread+0x11a/0x140 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Reported-by: Olga Kornievskaia Fixes: 9c455a8c1e14 ("NFS/pNFS: Clean up pNFS commit operations") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit f97d474f1b78e8b0697dee8532632fa68bf4f2b0 Author: Trond Myklebust Date: Mon Oct 4 15:37:42 2021 -0400 NFS: Fix up commit deadlocks [ Upstream commit 133a48abf6ecc535d7eddc6da1c3e4c972445882 ] If O_DIRECT bumps the commit_info rpcs_out field, then that could lead to fsync() hangs. The fix is to ensure that O_DIRECT calls nfs_commit_end(). Fixes: 723c921e7dfc ("sched/wait, fs/nfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0adbe4155e0b2d80fb36385b8b5a771b6bfad2e0 Author: Amelie Delaunay Date: Mon Oct 11 11:42:58 2021 +0200 dmaengine: stm32-dma: fix stm32_dma_get_max_width [ Upstream commit b20fd5fa310cbf7ec367f263a34382a24c4cee73 ] buf_addr parameter of stm32_dma_set_xfer_param function is a dma_addr_t. We only need to check the remainder of buf_addr/max_width, so, no need to use do_div and extra u64 addr. Use '%' instead. Fixes: e0ebdbdcb42a ("dmaengine: stm32-dma: take address into account when computing max width") Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211011094259.315023-3-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ca3b5c9765408eda971a52ef9d0b38e7fb276dbc Author: Claudiu Beznea Date: Thu Oct 7 14:12:28 2021 +0300 dmaengine: at_xdmac: fix AT_XDMAC_CC_PERID() macro [ Upstream commit 320c88a3104dc955f928a1eecebd551ff89530c0 ] AT_XDMAC_CC_PERID() should be used to setup bits 24..30 of XDMAC_CC register. Using it without parenthesis around 0x7f & (i) will lead to setting all the time zero for bits 24..30 of XDMAC_CC as the << operator has higher precedence over bitwise &. Thus, add paranthesis around 0x7f & (i). Fixes: 15a03850ab8f ("dmaengine: at_xdmac: fix macro typo") Signed-off-by: Claudiu Beznea Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20211007111230.2331837-3-claudiu.beznea@microchip.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit e8886cff93f03b2fa2823af70b0b75b98425fcc5 Author: Claudiu Beznea Date: Thu Oct 7 14:12:27 2021 +0300 dmaengine: at_xdmac: call at_xdmac_axi_config() on resume path [ Upstream commit fa5270ec2f2688d98a82895be7039b81c87d856c ] at_xdmac could be used on SoCs which supports backup mode (where most of the SoC power, including power to DMA controller, is closed at suspend time). Thus, on resume, the settings which were previously done need to be restored. Do the same for axi configuration. Fixes: f40566f220a1 ("dmaengine: at_xdmac: add AXI priority support and recommended settings") Signed-off-by: Claudiu Beznea Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20211007111230.2331837-2-claudiu.beznea@microchip.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d08efac1f61e1fa5b7e25b49eb1864f78813b696 Author: Dan Carpenter Date: Tue Oct 12 13:10:28 2021 +0300 rtc: rv3032: fix error handling in rv3032_clkout_set_rate() [ Upstream commit c3336b8ac6091df60a5c1049a8c685d0b947cc61 ] Do not call rv3032_exit_eerd() if the enter function fails but don't forget to call the exit when the enter succeeds. Fixes: 2eeaa532acca ("rtc: rv3032: Add a driver for Microcrystal RV-3032") Signed-off-by: Dan Carpenter Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20211012101028.GT2083@kadam Signed-off-by: Sasha Levin commit 32fe246e33c6c2467039d8b928338df3ddc7c5c6 Author: Christophe JAILLET Date: Sat Sep 4 13:37:32 2021 +0200 remoteproc: Fix a memory leak in an error handling path in 'rproc_handle_vdev()' [ Upstream commit 0374a4ea7269645c46c3eb288526ea072fa19e79 ] If 'copy_dma_range_map() fails, the memory allocated for 'rvdev' will leak. Move the 'copy_dma_range_map()' call after the device registration so that 'rproc_rvdev_release()' can be called to free some resources. Also, branch to the error handling path if 'copy_dma_range_map()' instead of a direct return to avoid some other leaks. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Christophe JAILLET Reviewed-by: Jim Quinlan Reviewed-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/e6d0dad6620da4fdf847faa903f79b735d35f262.1630755377.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin commit c0bd86c72dc0fc6ab44872f9e1a07e3ca0cfab73 Author: Zev Weiss Date: Thu Oct 14 13:39:52 2021 -0700 mtd: core: don't remove debugfs directory if device is in use [ Upstream commit c13de2386c78e890d4ae6f01a85eefd0b293fb08 ] Previously, if del_mtd_device() failed with -EBUSY due to a non-zero usecount, a subsequent call to attempt the deletion again would try to remove a debugfs directory that had already been removed and panic. With this change the second call can instead proceed safely. Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") Signed-off-by: Zev Weiss Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20211014203953.5424-1-zev@bewilderbeest.net Signed-off-by: Sasha Levin commit f3ecfa903c2fff44006e59fd4e04bbe4c2b86fed Author: Miquel Raynal Date: Fri Oct 8 18:36:40 2021 +0200 mtd: rawnand: arasan: Prevent an unsupported configuration [ Upstream commit fc9e18f9e987ad46722dad53adab1c12148c213c ] Under the following conditions: * after rounding up by 4 the number of bytes to transfer (this is related to the controller's internal constraints), * if this (rounded) amount of data is situated beyond the end of the device, * and only in NV-DDR mode, the Arasan NAND controller timeouts. This currently can happen in a particular helper used when picking software ECC algorithms. Let's prevent this situation by refusing to use the NV-DDR interface with software engines. Fixes: 4edde6031458 ("mtd: rawnand: arasan: Support NV-DDR interface") Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20211008163640.1753821-1-miquel.raynal@bootlin.com Signed-off-by: Sasha Levin commit e5744356f335f67912c2023a8d8275601b3044fe Author: Kunihiko Hayashi Date: Sat Sep 18 09:22:59 2021 +0900 PCI: uniphier: Serialize INTx masking/unmasking and fix the bit operation [ Upstream commit 4caab28a6215da5f3c1b505ff08810bc6acfe365 ] The condition register PCI_RCV_INTX is used in irq_mask() and irq_unmask() callbacks. Accesses to register can occur at the same time without a lock. Add a lock into each callback to prevent the issue. And INTX mask and unmask fields in PCL_RCV_INTX register should only be set/reset for each bit. Clearing by PCL_RCV_INTX_ALL_MASK should be removed. INTX status fields in PCL_RCV_INTX register only indicates each INTX interrupt status, so the handler can't clear by writing 1 to the field. The status is expected to be cleared by the interrupt origin. The ack function has no meaning, so should remove it. Suggested-by: Pali Rohár Link: https://lore.kernel.org/r/1631924579-24567-1-git-send-email-hayashi.kunihiko@socionext.com Fixes: 7e6d5cd88a6f ("PCI: uniphier: Add UniPhier PCIe host controller support") Signed-off-by: Kunihiko Hayashi Signed-off-by: Lorenzo Pieralisi Acked-by: Pali Rohár Acked-by: Marc Zyngier Signed-off-by: Sasha Levin commit 9254b2c16ba305c6c17ef232a550503a74309205 Author: Evgeny Novikov Date: Fri Jul 9 17:45:29 2021 +0300 mtd: spi-nor: hisi-sfc: Remove excessive clk_disable_unprepare() [ Upstream commit 78e4d342187625585932bb437ec26e1060f7fc6f ] hisi_spi_nor_probe() invokes clk_disable_unprepare() on all paths after successful call of clk_prepare_enable(). Besides, the clock is enabled by hispi_spi_nor_prep() and disabled by hispi_spi_nor_unprep(). So at remove time it is not possible to have the clock enabled. The patch removes excessive clk_disable_unprepare() from hisi_spi_nor_remove(). Found by Linux Driver Verification project (linuxtesting.org). Fixes: e523f11141bd ("mtd: spi-nor: add hisilicon spi-nor flash controller driver") Signed-off-by: Evgeny Novikov Signed-off-by: Tudor Ambarus Reviewed-by: Pratyush Yadav Link: https://lore.kernel.org/r/20210709144529.31379-1-novikov@ispras.ru Signed-off-by: Sasha Levin commit 3189e1420b295fef39943806fcfb7579153910a8 Author: John Keeping Date: Wed Oct 6 11:06:03 2021 -0700 Input: st1232 - increase "wait ready" timeout [ Upstream commit 2667f6b7af99e81958fa97c03bb519fcb09d0055 ] I have a ST1633 touch controller which fails to probe due to a timeout waiting for the controller to become ready. Increasing the minimum delay to 100ms ensures that the probe sequence completes successfully. The ST1633 datasheet says nothing about the maximum delay here and the ST1232 I2C protocol document says "wait until" with no notion of a timeout. Since this only runs once during probe, being generous with the timout seems reasonable and most likely the device will become ready eventually. (It may be worth noting that I saw this issue with a PREEMPT_RT patched kernel which probably has tighter wakeups from usleep_range() than other preemption models.) Fixes: f605be6a57b4 ("Input: st1232 - wait until device is ready before reading resolution") Signed-off-by: John Keeping Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210929152609.2421483-1-john@metanate.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit bef23befe1cd3428f99dbbc6908c8881fcd5ae80 Author: Jia-Ju Bai Date: Tue Mar 9 00:00:20 2021 -0800 fs: orangefs: fix error return code of orangefs_revalidate_lookup() [ Upstream commit 4c2b46c824a78fc8190d8eafaaea5a9078fe7479 ] When op_alloc() returns NULL to new_op, no error return code of orangefs_revalidate_lookup() is assigned. To fix this bug, ret is assigned with -ENOMEM in this case. Fixes: 8bb8aefd5afb ("OrangeFS: Change almost all instances of the string PVFS2 to OrangeFS.") Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Mike Marshall Signed-off-by: Sasha Levin commit f2deeaf169b88684474d61448ff568264247872d Author: Trond Myklebust Date: Mon Oct 4 15:44:16 2021 -0400 NFS: Fix deadlocks in nfs_scan_commit_list() [ Upstream commit 64a93dbf25d3a1368bb58ddf0f61d0a92d7479e3 ] Partially revert commit 2ce209c42c01 ("NFS: Wait for requests that are locked on the commit list"), since it can lead to deadlocks between commit requests and nfs_join_page_group(). For now we should assume that any locked requests on the commit list are either about to be removed and committed by another task, or the writes they describe are about to be retransmitted. In either case, we should not need to worry. Fixes: 2ce209c42c01 ("NFS: Wait for requests that are locked on the commit list") Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit 0776aa4efe0571b21620f1e5e158e98f6fcca734 Author: YueHaibing Date: Fri Oct 8 15:46:52 2021 +0800 opp: Fix return in _opp_add_static_v2() [ Upstream commit 27ff8187f13ecfec8a26fb1928e906f46f326cc5 ] Fix sparse warning: drivers/opp/of.c:924 _opp_add_static_v2() warn: passing zero to 'ERR_PTR' For duplicate OPPs 'ret' be set to zero. Fixes: deac8703da5f ("PM / OPP: _of_add_opp_table_v2(): increment count only if OPP is added") Signed-off-by: YueHaibing Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit d192572a43b68bdcd4e5716cd70638107f73a3e3 Author: Pali Rohár Date: Tue Oct 5 20:09:43 2021 +0200 PCI: aardvark: Fix preserving PCI_EXP_RTCTL_CRSSVE flag on emulated bridge [ Upstream commit d419052bc6c60fa4ab2b5a51d5f1e55a66e2b4ff ] Commit 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") started using CRSSVE flag for handling CRS responses. PCI_EXP_RTCTL_CRSSVE flag is stored only in emulated config space buffer and there is handler for PCI_EXP_RTCTL register. So every read operation from config space automatically clears CRSSVE flag as it is not defined in PCI_EXP_RTCTL read handler. Fix this by reading current CRSSVE bit flag from emulated space buffer and appending it to PCI_EXP_RTCTL read response. Link: https://lore.kernel.org/r/20211005180952.6812-5-kabel@kernel.org Fixes: 43f5c77bcbd2 ("PCI: aardvark: Fix reporting CRS value") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Signed-off-by: Sasha Levin commit b262b5fb60b48010120a970d3f36774e24751823 Author: Marek Behún Date: Tue Oct 5 20:09:42 2021 +0200 PCI: aardvark: Don't spam about PIO Response Status [ Upstream commit 464de7e7fff767e87429cd7be09c4f2cb50a6ccb ] Use dev_dbg() instead of dev_err() in advk_pcie_check_pio_status(). For example CRS is not an error status, it just says that the request should be retried. Link: https://lore.kernel.org/r/20211005180952.6812-4-kabel@kernel.org Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 8d76b46f58107ac4d18aeac783ae4c7e7435616b Author: Alex Xu (Hello71) Date: Thu Oct 7 02:37:06 2021 -0400 drm/plane-helper: fix uninitialized variable reference [ Upstream commit 7be28bd73f23e53d6e7f5fe891ba9503fc0c7210 ] drivers/gpu/drm/drm_plane_helper.c: In function 'drm_primary_helper_update': drivers/gpu/drm/drm_plane_helper.c:113:32: error: 'visible' is used uninitialized [-Werror=uninitialized] 113 | struct drm_plane_state plane_state = { | ^~~~~~~~~~~ drivers/gpu/drm/drm_plane_helper.c:178:14: note: 'visible' was declared here 178 | bool visible; | ^~~~~~~ cc1: all warnings being treated as errors visible is an output, not an input. in practice this use might turn out OK but it's still UB. Fixes: df86af9133b4 ("drm/plane-helper: Add drm_plane_helper_check_state()") Reviewed-by: Simon Ser Signed-off-by: Alex Xu (Hello71) Signed-off-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20211007063706.305984-1-alex_y_xu@yahoo.ca Signed-off-by: Sasha Levin commit 0bb7a9c31e4e9ac1cabca395f878475c6955e327 Author: Dmitry Baryshkov Date: Fri Jul 9 02:03:29 2021 +0300 drm/bridge/lontium-lt9611uxc: fix provided connector suport [ Upstream commit 15184965783aab3ca7ee4f939e2598943b3f40f9 ] - set DRM_CONNECTOR_POLL_HPD as the connector will generate hotplug events on its own - do not call drm_kms_helper_hotplug_event() unless mode_config.funcs pointer is not NULL to remove possible kernel oops. Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Dmitry Baryshkov Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210708230329.395976-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 9c8d416d7a52809897325496d7a5a1431e19591e Author: Baptiste Lepers Date: Mon Sep 6 11:59:24 2021 +1000 pnfs/flexfiles: Fix misplaced barrier in nfs4_ff_layout_prepare_ds [ Upstream commit a2915fa06227b056a8f9b0d79b61dca08ad5cfc6 ] _nfs4_pnfs_v3/v4_ds_connect do some work smp_wmb ds->ds_clp = clp; And nfs4_ff_layout_prepare_ds currently does smp_rmb if(ds->ds_clp) ... This patch places the smp_rmb after the if. This ensures that following reads only happen once nfs4_ff_layout_prepare_ds has checked that data has been properly initialized. Fixes: d67ae825a59d6 ("pnfs/flexfiles: Add the FlexFile Layout Driver") Signed-off-by: Baptiste Lepers Signed-off-by: Trond Myklebust Signed-off-by: Sasha Levin commit be46326d9c6556a79e33e87be67410da8e5e3598 Author: Trond Myklebust Date: Wed Sep 29 08:12:53 2021 -0400 NFS: Fix dentry verifier races [ Upstream commit cec08f452a687fce9dfdf47946d00a1d12a8bec5 ] If the directory changed while we were revalidating the dentry, then don't update the dentry verifier. There is no value in setting the verifier to an older value, and we could end up overwriting a more up to date verifier from a parallel revalidation. Fixes: efeda80da38d ("NFSv4: Fix revalidation of dentries with delegations") Signed-off-by: Trond Myklebust Tested-by: Benjamin Coddington Reviewed-by: Benjamin Coddington Signed-off-by: Sasha Levin commit 527b6ec3e979b8d46b88f74422bdb7055f76fcd9 Author: Trond Myklebust Date: Tue Sep 28 11:24:57 2021 -0400 NFS: Ignore the directory size when marking for revalidation [ Upstream commit a6a361c4ca3cc3e6f3b39d1b6bca1de90f5f4b11 ] If we want to revalidate the directory, then just mark the change attribute as invalid. Fixes: 13c0b082b6a9 ("NFS: Replace use of NFS_INO_REVAL_PAGECACHE when checking cache validity") Signed-off-by: Trond Myklebust Tested-by: Benjamin Coddington Reviewed-by: Benjamin Coddington Signed-off-by: Sasha Levin commit 255fc6efacf25d954a986ff058fd9899f322e7d1 Author: Trond Myklebust Date: Tue Sep 28 11:15:53 2021 -0400 NFS: Don't set NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA [ Upstream commit 488796ec1e39fb9194cc8175f770823d40fbf0ed ] NFS_INO_DATA_INVAL_DEFER and NFS_INO_INVALID_DATA should be considered mutually exclusive. Fixes: 1c341b777501 ("NFS: Add deferred cache invalidation for close-to-open consistency violations") Signed-off-by: Trond Myklebust Tested-by: Benjamin Coddington Reviewed-by: Benjamin Coddington Signed-off-by: Sasha Levin commit cbe0ef0063e50406f4e83189eb9bf370e9dcca91 Author: Trond Myklebust Date: Sun Sep 26 14:05:04 2021 -0400 NFS: Default change_attr_type to NFS4_CHANGE_TYPE_IS_UNDEFINED [ Upstream commit eea413308f2e6deb00f061f18081a53f3ecc8cc6 ] Both NFSv3 and NFSv2 generate their change attribute from the ctime value that was supplied by the server. However the problem is that there are plenty of servers out there with ctime resolutions of 1ms or worse. In a modern performance system, this is insufficient when trying to decide which is the most recent set of attributes when, for instance, a READ or GETATTR call races with a WRITE or SETATTR. For this reason, let's revert to labelling the NFSv2/v3 change attributes as NFS4_CHANGE_TYPE_IS_UNDEFINED. This will ensure we protect against such races. Fixes: 7b24dacf0840 ("NFS: Another inode revalidation improvement") Signed-off-by: Trond Myklebust Tested-by: Chuck Lever Signed-off-by: Sasha Levin commit 6033546caa09af2a6be4236d3ddfb9971317e0c3 Author: Kewei Xu Date: Fri Sep 17 18:14:10 2021 +0800 i2c: mediatek: fixing the incorrect register offset [ Upstream commit b8228aea5a19d5111a7bf44f7de6749d1f5d487a ] The reason for the modification here is that the previous offset information is incorrect, OFFSET_DEBUGSTAT = 0xE4 is the correct value. Fixes: 25708278f810 ("i2c: mediatek: Add i2c support for MediaTek MT8183") Signed-off-by: Kewei Xu Reviewed-by: Chen-Yu Tsai Reviewed-by: Qii Wang Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit a58fb2098608efe143cfad94ffa02ff17fb2e4e4 Author: Mark Brown Date: Fri Oct 1 21:20:49 2021 -0700 Input: ariel-pwrbutton - add SPI device ID table [ Upstream commit 5c4c2c8e6fac26fa0b80c234d6e9f75d637193af ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding a SPI device ID table. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210927134104.38648-1-broonie@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 135c6ab095b0d6cfedb781b034dcf1f956752949 Author: Mark Brown Date: Mon Sep 27 14:02:40 2021 +0100 rtc: mcp795: Add SPI ID table [ Upstream commit 3109151c47343c80300177ec7704e0757064efdc ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210927130240.33693-1-broonie@kernel.org Signed-off-by: Sasha Levin commit f6136953df6ed15815a6f5fad49f3fa507737e1d Author: Dong Aisheng Date: Fri Sep 10 17:06:18 2021 +0800 remoteproc: imx_rproc: Fix TCM io memory type [ Upstream commit 91bb26637353f35241f5472eedf3202ebe13e2e5 ] is_iomem was introduced in the commit 40df0a91b2a5 ("remoteproc: add is_iomem to da_to_va"), but the driver seemed missed to provide the io type correctly. This patch updates remoteproc driver to indicate the TCM on IMX are io memories. Without the change, remoteproc kick will fail. Cc: Bjorn Andersson Cc: Mathieu Poirier Cc: Peng Fan Reviewed-and-tested-by: Peng Fan Fixes: 79806d32d5aa ("remoteproc: imx_rproc: support i.MX8MN/P") Signed-off-by: Dong Aisheng Signed-off-by: Peng Fan stable Link: https://lore.kernel.org/r/20210910090621.3073540-4-peng.fan@oss.nxp.com Signed-off-by: Mathieu Poirier Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 511a35aa44001671b4ce946d594b9147095a1acb Author: Mark Brown Date: Thu Sep 23 20:49:22 2021 +0100 rtc: pcf2123: Add SPI ID table [ Upstream commit 5f84478e14aa8b43a4ea85d2e091931741947749 ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210923194922.53386-4-broonie@kernel.org Signed-off-by: Sasha Levin commit e0fc7ea848f461f4e5dc8c34da0ba1bf5688e74b Author: Mark Brown Date: Thu Sep 23 20:49:21 2021 +0100 rtc: ds1390: Add SPI ID table [ Upstream commit da87639d6312afb8855717c791768bf2d4ca8ac8 ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210923194922.53386-3-broonie@kernel.org Signed-off-by: Sasha Levin commit 5c83c670e11376b4493ff1507662e4493835eb1c Author: Mark Brown Date: Thu Sep 23 20:49:20 2021 +0100 rtc: ds1302: Add SPI ID table [ Upstream commit 8719a17613e0233d707eb22e1645d217594631ef ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding an id_table listing the SPI IDs for everything. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210923194922.53386-2-broonie@kernel.org Signed-off-by: Sasha Levin commit aeb40af85292d2a711238c4977af44b02262c525 Author: J. Bruce Fields Date: Tue Sep 14 12:30:32 2021 -0400 nfsd: don't alloc under spinlock in rpc_parse_scope_id [ Upstream commit 9b6e27d01adcec58e046c624874f8a124e8b07ec ] Dan Carpenter says: The patch d20c11d86d8f: "nfsd: Protect session creation and client confirm using client_lock" from Jul 30, 2014, leads to the following Smatch static checker warning: net/sunrpc/addr.c:178 rpc_parse_scope_id() warn: sleeping in atomic context Reported-by: Dan Carpenter Fixes: d20c11d86d8f ("nfsd: Protect session creation and client...") Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit b33831877a0e8520968dba8dfbb399e0890f3d51 Author: Evgeny Novikov Date: Fri Sep 3 11:26:53 2021 +0300 mtd: rawnand: intel: Fix potential buffer overflow in probe [ Upstream commit 46a0dc10fb32bec3e765e51bf71fbc070dc77ca3 ] ebu_nand_probe() read the value of u32 variable "cs" from the device firmware description and used it as the index for array ebu_host->cs that can contain MAX_CS (2) elements at most. That could result in a buffer overflow and various bad consequences later. Fix the potential buffer overflow by restricting values of "cs" with MAX_CS in probe. 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 Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210903082653.16441-1-novikov@ispras.ru Signed-off-by: Sasha Levin commit 2c3a8b1701dcc9a3c47b21d153c880d90c251239 Author: Arnaud Pouliquen Date: Mon Jul 12 14:39:12 2021 +0200 rpmsg: Fix rpmsg_create_ept return when RPMSG config is not defined [ Upstream commit 537d3af1bee8ad1415fda9b622d1ea6d1ae76dfa ] According to the description of the rpmsg_create_ept in rpmsg_core.c the function should return NULL on error. Fixes: 2c8a57088045 ("rpmsg: Provide function stubs for API") Signed-off-by: Arnaud Pouliquen Reviewed-by: Mathieu Poirier Link: https://lore.kernel.org/r/20210712123912.10672-1-arnaud.pouliquen@foss.st.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 1f6483f7c0d43407c4520187865b289800456370 Author: Tom Rix Date: Sun Oct 4 07:24:22 2020 -0700 apparmor: fix error check [ Upstream commit d108370c644b153382632b3e5511ade575c91c86 ] clang static analysis reports this representative problem: label.c:1463:16: warning: Assigned value is garbage or undefined label->hname = name; ^ ~~~~ In aa_update_label_name(), this the problem block of code if (aa_label_acntsxprint(&name, ...) == -1) return res; On failure, aa_label_acntsxprint() has a more complicated return that just -1. So check for a negative return. It was also noted that the aa_label_acntsxprint() main comment refers to a nonexistent parameter, so clean up the comment. Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: Tom Rix Reviewed-by: Nick Desaulniers Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 12af444fb18be3fa7c66d86cf978cd3dcab54306 Author: Aharon Landau Date: Thu Oct 28 08:55:22 2021 +0300 RDMA/core: Require the driver to set the IOVA correctly during rereg_mr [ Upstream commit f1a090f09f42be5a5542009f0be310fdb3e768fc ] If the driver returns a new MR during rereg it has to fill it with the IOVA from the proper source. If IB_MR_REREG_TRANS is set then the IOVA is cmd.hca_va, otherwise the IOVA comes from the old MR. mlx5 for example has two calls inside rereg_mr: return create_real_mr(new_pd, umem, mr->ibmr.iova, new_access_flags); and return create_real_mr(new_pd, new_umem, iova, new_access_flags); Unconditionally overwriting the iova in the newly allocated MR will corrupt the iova if the first path is used. Remove the redundant initializations from ib_uverbs_rereg_mr(). Fixes: 6e0954b11c05 ("RDMA/uverbs: Allow drivers to create a new HW object during rereg_mr") Link: https://lore.kernel.org/r/4b0a31bbc372842613286a10d7a8cbb0ee6069c7.1635400472.git.leonro@nvidia.com Signed-off-by: Aharon Landau Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit db35ff6ff095c3a4eb7c58f6701384539ee81663 Author: Hans de Goede Date: Sun Oct 31 16:25:22 2021 +0100 power: supply: bq27xxx: Fix kernel crash on IRQ handler register error [ Upstream commit cdf10ffe8f626d8a2edc354abf063df0078b2d71 ] When registering the IRQ handler fails, do not just return the error code, this will free the devm_kzalloc()-ed data struct while leaving the queued work queued and the registered power_supply registered with both of them now pointing to free-ed memory, resulting in various kernel crashes soon afterwards. Instead properly tear-down things on IRQ handler register errors. Fixes: 703df6c09795 ("power: bq27xxx_battery: Reorganize I2C into a module") Cc: Andrew F. Davis Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 17d0a494465f069ff7d91601533fc7d933926390 Author: Geert Uytterhoeven Date: Fri Oct 29 11:58:16 2021 +0200 mips: cm: Convert to bitfield API to fix out-of-bounds access [ Upstream commit 18b8f5b6fc53d097cadb94a93d8d6566ba88e389 ] mips_cm_error_report() extracts the cause and other cause from the error register using shifts. This works fine for the former, as it is stored in the top bits, and the shift will thus remove all non-related bits. However, the latter is stored in the bottom bits, hence thus needs masking to get rid of non-related bits. Without such masking, using it as an index into the cm2_causes[] array will lead to an out-of-bounds access, probably causing a crash. Fix this by using FIELD_GET() instead. Bite the bullet and convert all MIPS CM handling to the bitfield API, to improve readability and safety. Fixes: 3885c2b463f6a236 ("MIPS: CM: Add support for reporting CM cache errors") Signed-off-by: Geert Uytterhoeven Reviewed-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e941eb7523e68b80a684f311cb0eca90140df426 Author: Xuan Zhuo Date: Wed Oct 20 19:23:23 2021 +0800 virtio_ring: check desc == NULL when using indirect with packed [ Upstream commit fc6d70f40b3d0b3219e2026d05be0409695f620d ] When using indirect with packed, we don't check for allocation failures. This patch checks that and fall back on direct. Fixes: 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") Signed-off-by: Xuan Zhuo Link: https://lore.kernel.org/r/20211020112323.67466-3-xuanzhuo@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Signed-off-by: Sasha Levin commit 8a1bf46732bfe8054e34cf6e885e96cbb3c33e0a Author: Geert Uytterhoeven Date: Wed Oct 27 09:53:26 2021 +0200 serial: cpm_uart: Protect udbg definitions by CONFIG_SERIAL_CPM_CONSOLE [ Upstream commit d142585bceb3218ad432ed0fcd5be9d6e3cd9052 ] If CONFIG_CONSOLE_POLL=y, and CONFIG_SERIAL_CPM=m (hence CONFIG_SERIAL_CPM_CONSOLE=n): drivers/tty/serial/cpm_uart/cpm_uart_core.c:1109:12: warning: ‘udbg_cpm_getc’ defined but not used [-Wunused-function] 1109 | static int udbg_cpm_getc(void) | ^~~~~~~~~~~~~ drivers/tty/serial/cpm_uart/cpm_uart_core.c:1095:13: warning: ‘udbg_cpm_putc’ defined but not used [-Wunused-function] 1095 | static void udbg_cpm_putc(char c) | ^~~~~~~~~~~~~ Fix this by making the udbg definitions depend on CONFIG_SERIAL_CPM_CONSOLE, in addition to CONFIG_CONSOLE_POLL. Fixes: a60526097f42eb98 ("tty: serial: cpm_uart: Add udbg support for enabling xmon") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20211027075326.3270785-1-geert@linux-m68k.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cceb856eb7f31686164448922c0bb68a23229c4a Author: Christophe JAILLET Date: Mon Oct 18 21:44:16 2021 +0200 ASoC: rsnd: Fix an error handling path in 'rsnd_node_count()' [ Upstream commit 173632358fde7a567f28e07c4549b959ee857986 ] If we return before the end of the 'for_each_child_of_node()' iterator, the reference taken on 'np' must be released. Add the missing 'of_node_put()' call. Fixes: c413983eb66a ("ASoC: rsnd: adjust disabled module") Signed-off-by: Christophe JAILLET Reviewed-by: Kuninori Morimoto Link: https://lore.kernel.org/r/4c0e893cbfa21dc76c1ede0b6f4f8cff42209299.1634586167.git.christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5e0210787cfa4b4422c2987a4c99e603f0f97f5b Author: Yixing Liu Date: Fri Oct 29 18:05:37 2021 +0800 RDMA/hns: Modify the value of MAX_LP_MSG_LEN to meet hardware compatibility [ Upstream commit 0e60778efb072d47efc7100c4009b5bd97273b0b ] The upper limit of MAX_LP_MSG_LEN on HIP08 is 64K, and the upper limit on HIP09 is 16K. Regardless of whether it is HIP08 or HIP09, only 16K will be used. In order to ensure compatibility, it is unified to 16K. Setting MAX_LP_MSG_LEN to 16K will not cause performance loss on HIP08. Fixes: fbed9d2be292 ("RDMA/hns: Fix configuration of ack_req_freq in QPC") Link: https://lore.kernel.org/r/20211029100537.27299-1-liangwenpeng@huawei.com Signed-off-by: Yixing Liu Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 45107b861a80116d7ca8eb8df6835ccea074d3d2 Author: Haoyue Xu Date: Fri Oct 29 17:58:46 2021 +0800 RDMA/hns: Fix initial arm_st of CQ [ Upstream commit 571fb4fb78a3bf0fcadbe65eca9ca4ccee885af4 ] We set the init CQ status to ARMED before. As a result, an unexpected CEQE would be reported. Therefore, the init CQ status should be set to no_armed rather than REG_NXT_CEQE. Fixes: a5073d6054f7 ("RDMA/hns: Add eq support of hip08") Link: https://lore.kernel.org/r/20211029095846.26732-1-liangwenpeng@huawei.com Signed-off-by: Haoyue Xu Signed-off-by: Wenpeng Liang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f3de2499242cce544371b8998196ed70dfcc66ac Author: Richard Fitzgerald Date: Thu Oct 28 15:09:01 2021 +0100 ASoC: cs42l42: Correct configuring of switch inversion from ts-inv [ Upstream commit 778a0cbef5fb76bf506f84938517bb77e7a1c478 ] The setting from the cirrus,ts-inv property should be applied to the TIP_SENSE_INV bit, as this is the one that actually affects the jack detect block. The TS_INV bit only swaps the meaning of the PLUG and UNPLUG interrupts and should always be 1 for the interrupts to have the normal meaning. Due to some misunderstanding the driver had been implemented to configure the TS_INV bit based on the jack switch polarity. This made the interrupts behave the correct way around, but left the jack detect block, button detect and analogue circuits always interpreting an open switch as unplugged. The signal chain inside the codec is: SENSE pin -> TIP_SENSE_INV -> TS_INV -> (invert) -> interrupts | v Jack detect, button detect and analog control As the TIP_SENSE_INV already performs the necessary inversion the TS_INV bit never needs to change. It must always be 1 to yield the expected interrupt behaviour. Some extra confusion has arisen because of the additional invert in the interrupt path, meaning that a value applied to the TS_INV bit produces the opposite effect of applying it to the TIP_SENSE_INV bit. The ts-inv property has therefore always had the opposite effect to what might be expected (0 = inverted, 1 = not inverted). To maintain the meaning of the ts-inv property it must be inverted when applied to TIP_SENSE_INV. Signed-off-by: Richard Fitzgerald Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec") Link: https://lore.kernel.org/r/20211028140902.11786-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 03e45fb778c51ec90f0466e906ab08b9df5e511f Author: Christophe Leroy Date: Thu Oct 28 14:59:15 2021 +0200 powerpc: Don't provide __kernel_map_pages() without ARCH_SUPPORTS_DEBUG_PAGEALLOC [ Upstream commit f8c0e36b48e32b14bb83332d24e0646acd31d9e9 ] When ARCH_SUPPORTS_DEBUG_PAGEALLOC is not selected, the user can still select CONFIG_DEBUG_PAGEALLOC in which case __kernel_map_pages() is provided by mm/page_poison.c So only define __kernel_map_pages() when both CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC and CONFIG_DEBUG_PAGEALLOC are defined. Fixes: 68b44f94d637 ("powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE") Reported-by: kernel test robot Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/971b69739ff4746252e711a9845210465c023a9e.1635425947.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 14b05b63bfbbfea4be3df7f445116ea808fc503a Author: Takashi Sakamoto Date: Thu Oct 28 22:03:25 2021 +0900 ALSA: oxfw: fix functional regression for Mackie Onyx 1640i in v5.14 or later [ Upstream commit cddcd5472abb7b8a9c37ccbcf0908b79740a01b5 ] A user reports functional regression for Mackie Onyx 1640i that the device generates slow sound with ALSA oxfw driver which supports media clock recovery. Although the device is based on OXFW971 ASIC, it does not transfer isochronous packet with own event frequency as expected. The device seems to adjust event frequency according to events in received isochronous packets in the beginning of packet streaming. This is unknown quirk. This commit fixes the regression to turn the recovery off in driver side. As a result, nominal frequency is used in duplex packet streaming between device and driver. For stability of sampling rate in events of transferred isochronous packet, 4,000 isochronous packets are skipped in the beginning of packet streaming. Reference: https://github.com/takaswie/snd-firewire-improve/issues/38 Fixes: 029ffc429440 ("ALSA: oxfw: perform sequence replay for media clock recovery") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8af7e2b8d96fd78eb3269331668f4377c5f55cc1 Author: Denis Kirjanov Date: Tue Oct 26 16:31:08 2021 +0300 powerpc/xmon: fix task state output [ Upstream commit b1f896ce3542eb2eede5949ee2e481526fae1108 ] p_state is unsigned since the commit 2f064a59a11f The patch also uses TASK_RUNNING instead of null. Fixes: 2f064a59a11f ("sched: Change task_struct::state") Signed-off-by: Denis Kirjanov Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211026133108.7113-1-kda@linux-powerpc.org Signed-off-by: Sasha Levin commit 8557ce3ddb0e94ff48b6c10d7c4b3a9728d9725a Author: Bixuan Cui Date: Thu Oct 28 15:28:22 2021 +0800 powerpc/44x/fsp2: add missing of_node_put [ Upstream commit 290fe8aa69ef5c51c778c0bb33f8ef0181c769f5 ] Early exits from for_each_compatible_node() should decrement the node reference counter. Reported by Coccinelle: ./arch/powerpc/platforms/44x/fsp2.c:206:1-25: WARNING: Function "for_each_compatible_node" should have of_node_put() before return around line 218. Fixes: 7813043e1bbc ("powerpc/44x/fsp2: Add irq error handlers") Signed-off-by: Bixuan Cui Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1635406102-88719-1-git-send-email-cuibixuan@linux.alibaba.com Signed-off-by: Sasha Levin commit 694756f543b0c422fe904f4da673f7cdc2e841fa Author: Christophe Leroy Date: Tue Oct 26 07:39:25 2021 +0200 powerpc/book3e: Fix set_memory_x() and set_memory_nx() [ Upstream commit b6cb20fdc2735f8b2e082937066c33fe376c2ee2 ] set_memory_x() calls pte_mkexec() which sets _PAGE_EXEC. set_memory_nx() calls pte_exprotec() which clears _PAGE_EXEC. Book3e has 2 bits, UX and SX, which defines the exec rights resp. for user (PR=1) and for kernel (PR=0). _PAGE_EXEC is defined as UX only. An executable kernel page is set with either _PAGE_KERNEL_RWX or _PAGE_KERNEL_ROX, which both have SX set and UX cleared. So set_memory_nx() call for an executable kernel page does nothing because UX is already cleared. And set_memory_x() on a non-executable kernel page makes it executable for the user and keeps it non-executable for kernel. Also, pte_exec() always returns 'false' on kernel pages, because it checks _PAGE_EXEC which doesn't include SX, so for instance the W+X check doesn't work. To fix this: - change tlb_low_64e.S to use _PAGE_BAP_UX instead of _PAGE_USER - sets both UX and SX in _PAGE_EXEC so that pte_exec() returns true whenever one of the two bits is set and pte_exprotect() clears both bits. - Define a book3e specific version of pte_mkexec() which sets either SX or UX based on UR. Fixes: 1f9ad21c3b38 ("powerpc/mm: Implement set_memory() routines") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/c41100f9c144dc5b62e5a751b810190c6b5d42fd.1635226743.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit f0a8154f6c66b9d7367b213f83457e22077036be Author: Christophe Leroy Date: Tue Oct 26 07:39:24 2021 +0200 powerpc/nohash: Fix __ptep_set_access_flags() and ptep_set_wrprotect() [ Upstream commit b1b93cb7e794e914787bf7d9936b57a149cdee4f ] Commit 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code") changed those two functions to use pte helpers to determine which bits to clear and which bits to set. This change was based on the assumption that bits to be set/cleared are always the same and can be determined by applying the pte manipulation helpers on __pte(0). But on platforms like book3e, the bits depend on whether the page is a user page or not. For the time being it more or less works because of _PAGE_EXEC being used for user pages only and exec right being set at all time on kernel page. But following patch will clean that and output of pte_mkexec() will depend on the page being a user or kernel page. Instead of trying to make an even more complicated helper where bits would become dependent on the final pte value, come back to a more static situation like before commit 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code"), by introducing an 8xx specific version of __ptep_set_access_flags() and ptep_set_wrprotect(). Fixes: 26973fa5ac0e ("powerpc/mm: use pte helpers in generic code") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/922bdab3a220781bae2360ff3dd5adb7fe4d34f1.1635226743.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 15ccc53df3a4b403c5644bb7b873852765aa9e01 Author: Andrej Shadura Date: Tue Oct 19 17:29:17 2021 +0200 HID: u2fzero: properly handle timeouts in usb_submit_urb [ Upstream commit 43775e62c4b784f44a159e13ba80e6146a42d502 ] The wait_for_completion_timeout function returns 0 if timed out or a positive value if completed. Hence, "less than zero" comparison always misses timeouts and doesn't kill the URB as it should, leading to re-sending it while it is active. Fixes: 42337b9d4d95 ("HID: add driver for U2F Zero built-in LED and RNG") Signed-off-by: Andrej Shadura Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cc68082a3f76a023eff5431914659abadee75fa0 Author: Andrej Shadura Date: Tue Oct 19 17:29:16 2021 +0200 HID: u2fzero: clarify error check and length calculations [ Upstream commit b7abf78b7a6c4a29a6e0ba0bb883fe44a2f3d693 ] The previous commit fixed handling of incomplete packets but broke error handling: offsetof returns an unsigned value (size_t), but when compared against the signed return value, the return value is interpreted as if it were unsigned, so negative return values are never less than the offset. To make the code easier to read, calculate the minimal packet length once and separately, and assign it to a signed int variable to eliminate unsigned math and the need for type casts. It then becomes immediately obvious how the actual data length is calculated and why the return value cannot be less than the minimal length. Fixes: 22d65765f211 ("HID: u2fzero: ignore incomplete packets without data") Fixes: 42337b9d4d95 ("HID: add driver for U2F Zero built-in LED and RNG") Signed-off-by: Andrej Shadura Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 463e138a67cb031f4007f4053ec1cbd975da0d16 Author: Claudiu Beznea Date: Mon Oct 11 14:27:14 2021 +0300 clk: at91: clk-master: fix prescaler logic [ Upstream commit 0ef99f8202c5078a72c05af76bfaed2ea4daab19 ] When prescaler value read from register is MASTER_PRES_MAX it means that the input clock will be divided by 3. Fix the code to reflect this. Fixes: 7a110b9107ed8 ("clk: at91: clk-master: re-factor master clock") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20211011112719.3951784-11-claudiu.beznea@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit a4978a6cfd9ea5aa9acefacf246aebc5f9f4b9ab Author: Claudiu Beznea Date: Mon Oct 11 14:27:12 2021 +0300 clk: at91: clk-master: check if div or pres is zero [ Upstream commit c2910c00fee4cbb7b222d6e02846adef9ae4135a ] Check if div or pres is zero before using it as argument for ffs(). In case div is zero ffs() will return 0 and thus substracting from zero will lead to invalid values to be setup in registers. Fixes: 7a110b9107ed8 ("clk: at91: clk-master: re-factor master clock") Fixes: 75c88143f3b87 ("clk: at91: clk-master: add master clock support for SAMA7G5") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20211011112719.3951784-9-claudiu.beznea@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b42bf5de6bef5c812ca65ba906670a1c8d61cd7e Author: Claudiu Beznea Date: Mon Oct 11 14:27:11 2021 +0300 clk: at91: sam9x60-pll: use DIV_ROUND_CLOSEST_ULL [ Upstream commit f12d028b743bb6136da60b17228a1b6162886444 ] Use DIV_ROUND_CLOSEST_ULL() to avoid any inconsistency b/w the rate computed in sam9x60_frac_pll_recalc_rate() and the one computed in sam9x60_frac_pll_compute_mul_frac(). Fixes: 43b1bb4a9b3e1 ("clk: at91: clk-sam9x60-pll: re-factor to support plls with multiple outputs") Signed-off-by: Claudiu Beznea Link: https://lore.kernel.org/r/20211011112719.3951784-8-claudiu.beznea@microchip.com Acked-by: Nicolas Ferre Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e40f88ca6e5bc1ff60e5e220fe7c91d230d7ba03 Author: Anssi Hannula Date: Tue Oct 26 13:27:41 2021 +0300 serial: xilinx_uartps: Fix race condition causing stuck TX [ Upstream commit 88b20f84f0fe47409342669caf3e58a3fc64c316 ] xilinx_uartps .start_tx() clears TXEMPTY when enabling TXEMPTY to avoid any previous TXEVENT event asserting the UART interrupt. This clear operation is done immediately after filling the TX FIFO. However, if the bytes inserted by cdns_uart_handle_tx() are consumed by the UART before the TXEMPTY is cleared, the clear operation eats the new TXEMPTY event as well, causing cdns_uart_isr() to never receive the TXEMPTY event. If there are bytes still queued in circbuf, TX will get stuck as they will never get transferred to FIFO (unless new bytes are queued to circbuf in which case .start_tx() is called again). While the racy missed TXEMPTY occurs fairly often with short data sequences (e.g. write 1 byte), in those cases circbuf is usually empty so no action on TXEMPTY would have been needed anyway. On the other hand, longer data sequences make the race much more unlikely as UART takes longer to consume the TX FIFO. Therefore it is rare for this race to cause visible issues in general. Fix the race by clearing the TXEMPTY bit in ISR *before* filling the FIFO. The TXEMPTY bit in ISR will only get asserted at the exact moment the TX FIFO *becomes* empty, so clearing the bit before filling FIFO does not cause an extra immediate assertion even if the FIFO is initially empty. This is hard to reproduce directly on a normal system, but inserting e.g. udelay(200) after cdns_uart_handle_tx(port), setting 4000000 baud, and then running "dd if=/dev/zero bs=128 of=/dev/ttyPS0 count=50" reliably reproduces the issue on my ZynqMP test system unless this fix is applied. Fixes: 85baf542d54e ("tty: xuartps: support 64 byte FIFO size") Signed-off-by: Anssi Hannula Link: https://lore.kernel.org/r/20211026102741.2910441-1-anssi.hannula@bitwise.fi Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b135a66c3410ad407edcb1e2d9f0cb19d439d04f Author: Yang Yingliang Date: Thu Sep 9 15:21:49 2021 +0800 phy: Sparx5 Eth SerDes: Fix return value check in sparx5_serdes_probe() [ Upstream commit b4dc97ab0a629eda8bda20d96ef47dac08a505d9 ] In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Fixes: 2ff8a1eeb5aa ("phy: Add Sparx5 ethernet serdes PHY driver") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210909072149.2934047-1-yangyingliang@huawei.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 16db43fc056848b43fd74bc82f5a36e89296ee1a Author: Sandeep Maheswaram Date: Mon Oct 25 09:49:35 2021 +0530 phy: qcom-snps: Correct the FSEL_MASK [ Upstream commit b475bf0ec40a2b13fb32ef62f5706576d5858460 ] The FSEL_MASK which selects the refclock is defined incorrectly. It should be [4:6] not [5:7]. Due to this incorrect definition, the BIT(7) in USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON0 is reset which keeps PHY analog blocks ON during suspend. Fix this issue by correctly defining the FSEL_MASK. Fixes: 51e8114f80d0 ("phy: qcom-snps: Add SNPS USB PHY driver for QCOM based SOCs") Signed-off-by: Sandeep Maheswaram Link: https://lore.kernel.org/r/1635135575-5668-1-git-send-email-quic_c_sanm@quicinc.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit f639952d70c6ebe506ebbec9d27e081e7100c142 Author: Dan Carpenter Date: Tue Sep 14 14:00:38 2021 +0300 phy: ti: gmii-sel: check of_get_address() for failure [ Upstream commit 8d55027f4e2c04146a75fb63371ab96ccc887f2c ] Smatch complains that if of_get_address() returns NULL, then "size" isn't initialized. Also it would lead to an Oops. Fixes: 7f78322cdd67 ("phy: ti: gmii-sel: retrieve ports number and base offset from dt") Signed-off-by: Dan Carpenter Reviewed-by: Grygorii Strashko Link: https://lore.kernel.org/r/20210914110038.GB11657@kili Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 02058ab1dcec7d2592fdb37ce0c171ee8e827e76 Author: Vladimir Zapolskiy Date: Thu Sep 23 02:35:48 2021 +0300 phy: qcom-qusb2: Fix a memory leak on probe [ Upstream commit bf7ffcd0069d30e2e7ba2b827f08c89f471cd1f3 ] On success nvmem_cell_read() returns a pointer to a dynamically allocated buffer, and therefore it shall be freed after usage. The issue is reported by kmemleak: # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff3b3803e4b280 (size 128): comm "kworker/u16:1", pid 107, jiffies 4294892861 (age 94.120s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007739afdc>] __kmalloc+0x27c/0x41c [<0000000071c0fbf8>] nvmem_cell_read+0x40/0xe0 [<00000000e803ef1f>] qusb2_phy_init+0x258/0x5bc [<00000000fc81fcfa>] phy_init+0x70/0x110 [<00000000e3d48a57>] dwc3_core_soft_reset+0x4c/0x234 [<0000000027d1dbd4>] dwc3_core_init+0x68/0x990 [<000000001965faf9>] dwc3_probe+0x4f4/0x730 [<000000002f7617ca>] platform_probe+0x74/0xf0 [<00000000a2576cac>] really_probe+0xc4/0x470 [<00000000bc77f2c5>] __driver_probe_device+0x11c/0x190 [<00000000130db71f>] driver_probe_device+0x48/0x110 [<0000000019f36c2b>] __device_attach_driver+0xa4/0x140 [<00000000e5812ff7>] bus_for_each_drv+0x84/0xe0 [<00000000f4bac574>] __device_attach+0xe4/0x1c0 [<00000000d3beb631>] device_initial_probe+0x20/0x30 [<000000008019b9db>] bus_probe_device+0xa4/0xb0 Fixes: ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210922233548.2150244-1-vladimir.zapolskiy@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 05d2c884bbb065928ea57bba34f23b10d63c919a Author: Mark Brown Date: Mon Oct 25 16:48:44 2021 +0100 ASoC: topology: Fix stub for snd_soc_tplg_component_remove() [ Upstream commit 1198ff12cbdd5f42c032cba1d96ebc7af8024cf9 ] When removing the index argument from snd_soc_topology_component_remove() commit a5b8f71c5477f (ASoC: topology: Remove multistep topology loading) forgot to update the stub for !SND_SOC_TOPOLOGY use, causing build failures for anything that tries to make use of it. Fixes: a5b8f71c5477f (ASoC: topology: Remove multistep topology loading) Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20211025154844.2342120-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 20cef4273de05abba14092fc0ca7648ba9fb794d Author: Rahul Tanwar Date: Wed Oct 20 17:38:15 2021 +0800 pinctrl: equilibrium: Fix function addition in multiple groups [ Upstream commit 53b3947ddb7f309d1f611f8dc9bfd6ea9d699907 ] Ignore the same function with multiple groups. Fix a typo in error print. Fixes: 1948d5c51dba ("pinctrl: Add pinmux & GPIO controller driver for a new SoC") Signed-off-by: Rahul Tanwar Link: https://lore.kernel.org/r/20211020093815.20870-1-rtanwar@maxlinear.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit fbf843c5fde5a0b70b96aea943974e7d0d43895c Author: Vladimir Zapolskiy Date: Mon Oct 11 12:55:34 2021 +0300 arm64: dts: qcom: sdm845: Fix Qualcomm crypto engine bus clock [ Upstream commit d5240f8e23641c70bc70892d7999398b081ccb7e ] The change corrects the described bus clock of the QCE. Fixes: 3e482859f1ef ("dts: qcom: sdm845: Add dt entries to support crypto engine.") Signed-off-by: Vladimir Zapolskiy Reviewed-by: Thara Gopinath Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211011095534.1580406-1-vladimir.zapolskiy@linaro.org Signed-off-by: Sasha Levin commit 24231d918e46b9030c8e41f97479d5955b73b920 Author: Bhupesh Sharma Date: Wed May 19 20:06:50 2021 +0530 arm64: dts: qcom: sdm845: Use RPMH_CE_CLK macro directly [ Upstream commit eed1d9b6e36b06faa53c6dc74134ec21b1336d94 ] In commit 3e482859f1ef ("dts: qcom: sdm845: Add dt entries to support crypto engine."), we decided to use the value indicated by constant RPMH_CE_CLK rather than using it directly. Now that the same RPMH clock value might be used for other SoCs (in addition to sdm845), let's use the constant RPMH_CE_CLK to make sure that this dtsi is compatible with the other qcom ones. Signed-off-by: Bhupesh Sharma Reviewed-by: Thara Gopinath Link: https://lore.kernel.org/r/20210519143700.27392-8-bhupesh.sharma@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cd068f71c2453a0c9b831e04e4ebf9c9dc31537c Author: Marijn Suijten Date: Thu Oct 7 23:33:57 2021 +0200 arm64: dts: qcom: pmi8994: Fix "eternal"->"external" typo in WLED node [ Upstream commit b110dfa5ad42be93ebf73540d16430878dfb26bb ] The property is named "qcom,external-pfet", as found by dt_binding_check: 'qcom,eternal-pfet' does not match any of the regexes Fixes: 37aa540cbd30 ("arm64: dts: qcom: pmi8994: Add WLED node") Signed-off-by: Marijn Suijten Reviewed-By: AngeloGioacchino Del Regno Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211007213400.258371-11-marijn.suijten@somainline.org Signed-off-by: Sasha Levin commit 0f2768e7aaa4f46e47a2d4ba3fef8dcd2c47e577 Author: Wan Jiabing Date: Thu Oct 14 04:30:17 2021 -0400 soc: qcom: apr: Add of_node_put() before return [ Upstream commit 72f1aa6205d84337b90b065f602a8fe190821781 ] Fix following coccicheck warning: ./drivers/soc/qcom/apr.c:485:1-23: WARNING: Function for_each_child_of_node should have of_node_put() before return Early exits from for_each_child_of_node should decrement the node reference counter. Fixes: 834735662602 ("soc: qcom: apr: Add avs/audio tracking functionality") Signed-off-by: Wan Jiabing Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211014083017.19714-1-wanjiabing@vivo.com Signed-off-by: Sasha Levin commit 5e313f56a004d5b0c253c1708518a7202de6c3ea Author: Dmitry Baryshkov Date: Wed Oct 20 04:26:39 2021 +0300 soc: qcom: rpmhpd: fix sm8350_mxc's peer domain [ Upstream commit 086f52fdc8f7bd273d06a3de2adf65a063eb5392 ] The sm8350_mxc's domain description incorrectly references sm8150_mmcx_ao as a peer instead of sm8350_mxc_ao. Correct this typo. Fixes: 639c85628757 ("soc: qcom: rpmhpd: Add SM8350 power domains") Cc: Vinod Koul Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211020012639.1183806-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit fae72275217d6c2c4d64dfb4cde47c24c4eba38a Author: Guru Das Srinagesh Date: Mon Oct 11 13:00:14 2021 -0700 firmware: qcom_scm: Fix error retval in __qcom_scm_is_call_available() [ Upstream commit 38212b2a8a6fc4c3a6fa99d7445b833bedc9a67c ] Since __qcom_scm_is_call_available() returns bool, have it return false instead of -EINVAL if an invalid SMC convention is detected. This fixes the Smatch static checker warning: drivers/firmware/qcom_scm.c:255 __qcom_scm_is_call_available() warn: signedness bug returning '(-22)' Fixes: 9d11af8b06a8 ("firmware: qcom_scm: Make __qcom_scm_is_call_available() return bool") Reported-by: Dan Carpenter Signed-off-by: Guru Das Srinagesh Reviewed-by: Stephen Boyd Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/1633982414-28347-1-git-send-email-quic_gurus@quicinc.com Signed-off-by: Sasha Levin commit 61bb3fac7a56c9d43422a8af39a681e39f5ef936 Author: Christophe Leroy Date: Fri Oct 15 12:02:42 2021 +0200 powerpc/booke: Disable STRICT_KERNEL_RWX, DEBUG_PAGEALLOC and KFENCE [ Upstream commit 68b44f94d6370e2c6c790fedd28e637fa9964a93 ] fsl_booke and 44x are not able to map kernel linear memory with pages, so they can't support DEBUG_PAGEALLOC and KFENCE, and STRICT_KERNEL_RWX is also a problem for now. Enable those only on book3s (both 32 and 64 except KFENCE), 8xx and 40x. Fixes: 88df6e90fa97 ("[POWERPC] DEBUG_PAGEALLOC for 32-bit") Fixes: 95902e6c8864 ("powerpc/mm: Implement STRICT_KERNEL_RWX on PPC32") Fixes: 90cbac0e995d ("powerpc: Enable KFENCE for PPC32") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/d1ad9fdd9b27da3fdfa16510bb542ed51fa6e134.1634292136.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit d58dbd7c9765930b4064a44568ddd228b681a0e6 Author: Amelie Delaunay Date: Tue Oct 5 11:53:05 2021 +0200 usb: dwc2: drd: reset current session before setting the new one [ Upstream commit 1ad707f559f7cb12c64f3d7cb37f0b1ea27c1058 ] If role is changed without the "none" step, A- and B- valid session could be set at the same time. It is an issue. This patch resets A-session if role switch sets B-session, and resets B-session if role switch sets A-session. Then, it is possible to change the role without the "none" step. Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support") Acked-by: Minas Harutyunyan Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211005095305.66397-4-amelie.delaunay@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c6a6138fd3d0771f014e5b53017934503d2552d4 Author: Amelie Delaunay Date: Tue Oct 5 11:53:04 2021 +0200 usb: dwc2: drd: fix dwc2_drd_role_sw_set when clock could be disabled [ Upstream commit 8d387f61b0240854e81450c261beb775065bad5d ] In case of USB_DR_MODE_PERIPHERAL, the OTG clock is disabled at the end of the probe (it is not the case if USB_DR_MODE_HOST or USB_DR_MODE_OTG). The clock is then enabled on udc_start. If dwc2_drd_role_sw_set is called before udc_start (it is the case if the usb cable is plugged at boot), GOTGCTL and GUSBCFG registers cannot be read/written, so session cannot be overridden. To avoid this case, check the ll_hw_enabled value and enable the clock if it is available, and disable it after the override. Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support") Acked-by: Minas Harutyunyan Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211005095305.66397-3-amelie.delaunay@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8d4801295664f693c6b5cee33bf29ba640179416 Author: Amelie Delaunay Date: Tue Oct 5 11:53:03 2021 +0200 usb: dwc2: drd: fix dwc2_force_mode call in dwc2_ovr_init [ Upstream commit b2cab2a24fb5d13ce1d384ecfb6de827fa08a048 ] Instead of forcing the role to Device, check the dr_mode configuration. If the core is Host only, force the mode to Host, this to avoid the dwc2_force_mode warning: WARNING: CPU: 1 PID: 21 at drivers/usb/dwc2/core.c:615 dwc2_drd_init+0x104/0x17c When forcing mode to Host, dwc2_force_mode may sleep the time the host role is applied. To avoid sleeping while atomic context, move the call to dwc2_force_mode after spin_unlock_irqrestore. It is safe, as interrupts are not yet unmasked here. Fixes: 17f934024e84 ("usb: dwc2: override PHY input signals with usb role switch support") Acked-by: Minas Harutyunyan Signed-off-by: Amelie Delaunay Link: https://lore.kernel.org/r/20211005095305.66397-2-amelie.delaunay@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 97714002eb5c55cb69742f00a136d2c0128b7e95 Author: Stefan Agner Date: Wed Oct 20 21:26:42 2021 +0200 serial: imx: fix detach/attach of serial console [ Upstream commit 6d0d1b5a1b4870911beb89544ec1a9751c42fec7 ] If the device used as a serial console gets detached/attached at runtime, register_console() will try to call imx_uart_setup_console(), but this is not possible since it is marked as __init. For instance # cat /sys/devices/virtual/tty/console/active tty1 ttymxc0 # echo -n N > /sys/devices/virtual/tty/console/subsystem/ttymxc0/console # echo -n Y > /sys/devices/virtual/tty/console/subsystem/ttymxc0/console [ 73.166649] 8<--- cut here --- [ 73.167005] Unable to handle kernel paging request at virtual address c154d928 [ 73.167601] pgd = 55433e84 [ 73.167875] [c154d928] *pgd=8141941e(bad) [ 73.168304] Internal error: Oops: 8000000d [#1] SMP ARM [ 73.168429] Modules linked in: [ 73.168522] CPU: 0 PID: 536 Comm: sh Not tainted 5.15.0-rc6-00056-g3968ddcf05fb #3 [ 73.168675] Hardware name: Freescale i.MX6 Ultralite (Device Tree) [ 73.168791] PC is at imx_uart_console_setup+0x0/0x238 [ 73.168927] LR is at try_enable_new_console+0x98/0x124 [ 73.169056] pc : [] lr : [] psr: a0000013 [ 73.169178] sp : c2ef5e70 ip : 00000000 fp : 00000000 [ 73.169281] r10: 00000000 r9 : c02cf970 r8 : 00000000 [ 73.169389] r7 : 00000001 r6 : 00000001 r5 : c1760164 r4 : c1e0fb08 [ 73.169512] r3 : c154d928 r2 : 00000000 r1 : efffcbd1 r0 : c1760164 [ 73.169641] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 73.169782] Control: 10c5387d Table: 8345406a DAC: 00000051 [ 73.169895] Register r0 information: non-slab/vmalloc memory [ 73.170032] Register r1 information: non-slab/vmalloc memory [ 73.170158] Register r2 information: NULL pointer [ 73.170273] Register r3 information: non-slab/vmalloc memory [ 73.170397] Register r4 information: non-slab/vmalloc memory [ 73.170521] Register r5 information: non-slab/vmalloc memory [ 73.170647] Register r6 information: non-paged memory [ 73.170771] Register r7 information: non-paged memory [ 73.170892] Register r8 information: NULL pointer [ 73.171009] Register r9 information: non-slab/vmalloc memory [ 73.171142] Register r10 information: NULL pointer [ 73.171259] Register r11 information: NULL pointer [ 73.171375] Register r12 information: NULL pointer [ 73.171494] Process sh (pid: 536, stack limit = 0xcd1ba82f) [ 73.171621] Stack: (0xc2ef5e70 to 0xc2ef6000) [ 73.171731] 5e60: ???????? ???????? ???????? ???????? [ 73.171899] 5e80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.172059] 5ea0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.172217] 5ec0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.172377] 5ee0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.172537] 5f00: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.172698] 5f20: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.172856] 5f40: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.173016] 5f60: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.173177] 5f80: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.173336] 5fa0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.173496] 5fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.173654] 5fe0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.173826] [] (try_enable_new_console) from [] (register_console+0x10c/0x2ec) [ 73.174053] [] (register_console) from [] (console_store+0x14c/0x168) [ 73.174262] [] (console_store) from [] (kernfs_fop_write_iter+0x110/0x1cc) [ 73.174470] [] (kernfs_fop_write_iter) from [] (vfs_write+0x31c/0x548) [ 73.174679] [] (vfs_write) from [] (ksys_write+0x60/0xec) [ 73.174863] [] (ksys_write) from [] (ret_fast_syscall+0x0/0x1c) [ 73.175052] Exception stack(0xc2ef5fa8 to 0xc2ef5ff0) [ 73.175167] 5fa0: ???????? ???????? ???????? ???????? ???????? ???????? [ 73.175327] 5fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? [ 73.175486] 5fe0: ???????? ???????? ???????? ???????? [ 73.175608] Code: 00000000 00000000 00000000 00000000 (00000000) [ 73.175744] ---[ end trace 9b75121265109bf1 ]--- A similar issue could be triggered by unbinding/binding the serial console device [*]. Drop __init so that imx_uart_setup_console() can be safely called at runtime. [*] https://lore.kernel.org/all/20181114174940.7865-3-stefan@agner.ch/ Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Reviewed-by: Andy Shevchenko Acked-by: Uwe Kleine-König Signed-off-by: Stefan Agner Signed-off-by: Francesco Dolcini Link: https://lore.kernel.org/r/20211020192643.476895-2-francesco.dolcini@toradex.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f265551f304a80c8c7e602f6efa253fc85c6244d Author: James Smart Date: Wed Oct 20 14:14:11 2021 -0700 scsi: lpfc: Wait for successful restart of SLI3 adapter during host sg_reset [ Upstream commit d305c253af693e69a36cedec880aca6d0c6d789d ] A prior patch introduced HBA_NEEDS_CFG_PORT flag logic, but in lpfc_sli_brdrestart_s3() code path, right after HBA_NEEDS_CFG_PORT is set, the phba->hba_flag is cleared in lpfc_sli_brdreset(). Fix by calling lpfc_sli_chipset_init() to wait for successful restart of the HBA in lpfc_host_reset_handler() after lpfc_sli_brdrestart(). lpfc_sli_chipset_init() sets the HBA_NEEDS_CFG_PORT flag so that the lpfc_sli_hba_setup() routine from lpfc_online() will execute lpfc_sli_config_port() initialization step when the brdrestart is successful. Link: https://lore.kernel.org/r/20211020211417.88754-3-jsmart2021@gmail.com Fixes: d2f2547efd39 ("scsi: lpfc: Fix auto sli_mode and its effect on CONFIG_PORT for SLI3") Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9c9321f3af65482d066b96ddc91076b77d61365c Author: Srinivas Kandagatla Date: Tue Sep 14 10:22:14 2021 +0100 scsi: ufs: ufshcd-pltfrm: Fix memory leak due to probe defer [ Upstream commit b6ca770ae7f2c560a29bbd02c4e3d734fafaf804 ] UFS drivers that probe defer will end up leaking memory allocated for clk and regulator names via kstrdup() because the structure that is holding this memory is allocated via devm_* variants which will be freed during probe defer but the names are never freed. Use same devm_* variant of kstrdup to free the memory allocated to name when driver probe defers. Kmemleak found around 11 leaks on Qualcomm Dragon Board RB5: unreferenced object 0xffff66f243fb2c00 (size 128): comm "kworker/u16:0", pid 7, jiffies 4294893319 (age 94.848s) hex dump (first 32 bytes): 63 6f 72 65 5f 63 6c 6b 00 76 69 72 74 75 61 6c core_clk.virtual 2f 77 6f 72 6b 71 75 65 75 65 2f 73 63 73 69 5f /workqueue/scsi_ backtrace: [<000000006f788cd1>] slab_post_alloc_hook+0x88/0x410 [<00000000cfd1372b>] __kmalloc_track_caller+0x138/0x230 [<00000000a92ab17b>] kstrdup+0xb0/0x110 [<0000000037263ab6>] ufshcd_pltfrm_init+0x1a8/0x500 [<00000000a20a5caa>] ufs_qcom_probe+0x20/0x58 [<00000000a5e43067>] platform_probe+0x6c/0x118 [<00000000ef686e3f>] really_probe+0xc4/0x330 [<000000005b18792c>] __driver_probe_device+0x88/0x118 [<00000000a5d295e8>] driver_probe_device+0x44/0x158 [<000000007e83f58d>] __device_attach_driver+0xb4/0x128 [<000000004bfa4470>] bus_for_each_drv+0x68/0xd0 [<00000000b89a83bc>] __device_attach+0xec/0x170 [<00000000ada2beea>] device_initial_probe+0x14/0x20 [<0000000079921612>] bus_probe_device+0x9c/0xa8 [<00000000d268bf7c>] deferred_probe_work_func+0x90/0xd0 [<000000009ef64bfa>] process_one_work+0x29c/0x788 unreferenced object 0xffff66f243fb2c80 (size 128): comm "kworker/u16:0", pid 7, jiffies 4294893319 (age 94.848s) hex dump (first 32 bytes): 62 75 73 5f 61 67 67 72 5f 63 6c 6b 00 00 00 00 bus_aggr_clk.... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ With this patch no memory leaks are reported. Link: https://lore.kernel.org/r/20210914092214.6468-1-srinivas.kandagatla@linaro.org Fixes: aa4976130934 ("ufs: Add regulator enable support") Fixes: c6e79dacd86f ("ufs: Add clock initialization support") Reviewed-by: Bart Van Assche Signed-off-by: Srinivas Kandagatla Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8104d165fe8c39f7afba419251d3369e3c119c4c Author: Srinivas Kandagatla Date: Tue Oct 12 11:15:21 2021 +0100 soundwire: bus: stop dereferencing invalid slave pointer [ Upstream commit 4cbbe74d906be0bcffbe1e74b43a00f99626a69c ] Slave pointer is invalid after end of list iteration, using this would result in below Memory abort. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 ... Call trace: __dev_printk+0x34/0x7c _dev_warn+0x6c/0x90 sdw_bus_exit_clk_stop+0x194/0x1d0 swrm_runtime_resume+0x13c/0x238 pm_generic_runtime_resume+0x2c/0x48 __rpm_callback+0x44/0x150 rpm_callback+0x6c/0x78 rpm_resume+0x314/0x558 rpm_resume+0x378/0x558 rpm_resume+0x378/0x558 __pm_runtime_resume+0x3c/0x88 Use bus->dev instead to print this error message. Fixes: b50bb8ba369cd ("soundwire: bus: handle -ENODATA errors in clock stop/start sequences") Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20211012101521.32087-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4e599aa437f8263bd2ee3d6a1928106233a233db Author: Nuno Sá Date: Fri Sep 3 16:14:19 2021 +0200 iio: adis: do not disabe IRQs in 'adis_init()' [ Upstream commit b600bd7eb333554518b4dd36b882b2ae58a5149e ] With commit ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup") we are doing a HW or SW reset to the device which means that we'll get the default state of the data ready pin (which is enabled). Hence there's no point in disabling the IRQ in the init function. Moreover, this function is intended to initialize internal data structures and not really do anything on the device. As a result of this, some devices were left with the data ready pin enabled after probe which was not the desired behavior. Thus, we move the call to 'adis_enable_irq()' to the initial startup function where it makes more sense for it to be. Note that for devices that cannot mask/unmask the pin, it makes no sense to call the function at this point since the IRQ should not have been yet requested. This will be improved in a follow up change. Fixes: ecb010d441088 ("iio: imu: adis: Refactor adis_initial_startup") Signed-off-by: Nuno Sá Link: https://lore.kernel.org/r/20210903141423.517028-2-nuno.sa@analog.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1cc004bb7e1d8ba512e40f0049c7feae2fa3f0b4 Author: Randy Dunlap Date: Thu Oct 14 18:36:09 2021 -0700 usb: typec: STUSB160X should select REGMAP_I2C [ Upstream commit 8ef1e58783b9f55daa4a865c7801dc75cbeb8260 ] REGMAP_I2C is not a user visible kconfig symbol so driver configs should not "depend on" it. They should depend on I2C and then select REGMAP_I2C. If this worked, it was only because some other driver had set/enabled REGMAP_I2C. Fixes: da0cb6310094 ("usb: typec: add support for STUSB160x Type-C controller family") Cc: Heikki Krogerus Cc: Amelie Delaunay Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Reviewed-by: Amelie Delaunay Reviewed-by: Heikki Krogerus Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20211015013609.7300-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2c05b78785ae1688c1f2e3285c9416f8c5df7621 Author: Yang Yingliang Date: Wed Oct 13 12:49:22 2021 +0300 iio: buffer: Fix double-free in iio_buffers_alloc_sysfs_and_mask() [ Upstream commit 09776d9374e635b1580b3736c19b95b788fbaa85 ] When __iio_buffer_alloc_sysfs_and_mask() failed, 'unwind_idx' should be set to 'i - 1' to prevent double-free when cleanup resources. BUG: KASAN: double-free or invalid-free in __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio] Call Trace: kfree+0x117/0x4c0 __iio_buffer_free_sysfs_and_mask+0x32/0xb0 [industrialio] iio_buffers_alloc_sysfs_and_mask+0x60d/0x1570 [industrialio] __iio_device_register+0x483/0x1a30 [industrialio] ina2xx_probe+0x625/0x980 [ina2xx_adc] Reported-by: Hulk Robot Fixes: ee708e6baacd ("iio: buffer: introduce support for attaching more IIO buffers") Signed-off-by: Yang Yingliang Reviewed-by: Alexandru Ardelean Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20211013094923.2473-2-andriy.shevchenko@linux.intel.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit ddcdf294b31bb22335281f33af5129426aa3a19a Author: Dmitry Baryshkov Date: Sat Oct 16 22:06:07 2021 +0300 soc: qcom: socinfo: add two missing PMIC IDs [ Upstream commit 2fae3ecc70405b72ea6c923b216d34547559d6a9 ] Add IDs for PMK8001 and PMI8996. They also fall in the list of 'duplicated' IDs, where the same index was used for multiple chips. Fixes: 7fda2b0bfbd9 ("soc: qcom: socinfo: import PMIC IDs from pmic-spmi") Signed-off-by: Dmitry Baryshkov Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211016190607.49866-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin commit 4be134c2caf06c8fdf907997966b87fe30bb8409 Author: Bjorn Andersson Date: Mon Oct 4 20:37:32 2021 -0700 soc: qcom: rpmhpd: Make power_on actually enable the domain [ Upstream commit e3e56c050ab6e3f1bd811f0787f50709017543e4 ] The general expectation is that powering on a power-domain should make the power domain deliver some power, and if a specific performance state is needed further requests has to be made. But in contrast with other power-domain implementations (e.g. rpmpd) the RPMh does not have an interface to enable the power, so the driver has to vote for a particular corner (performance level) in rpmh_power_on(). But the corner is never initialized, so a typical request to simply enable the power domain would not actually turn on the hardware. Further more, when no more clients vote for a performance state (i.e. the aggregated vote is 0) the power domain would be turned off. Fix both of these issues by always voting for a corner with non-zero value, when the power domain is enabled. The tracking of the lowest non-zero corner is performed to handle the corner case if there's ever a domain with a non-zero lowest corner, in which case both rpmh_power_on() and rpmh_rpmhpd_set_performance_state() would be allowed to use this lowest corner. Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver") Signed-off-by: Bjorn Andersson Reviewed-by: Stephen Boyd Link: https://lore.kernel.org/r/20211005033732.2284447-1-bjorn.andersson@linaro.org Signed-off-by: Sasha Levin commit c4607253ded64d93ddae0a40da195b1bff34643d Author: Richard Fitzgerald Date: Fri Oct 15 14:36:08 2021 +0100 ASoC: cs42l42: Defer probe if request_threaded_irq() returns EPROBE_DEFER [ Upstream commit 0306988789d9d91a18ff70bd2bf165d3ae0ef1dd ] The driver can run without an interrupt so if devm_request_threaded_irq() failed, the probe() just carried on. But if this was EPROBE_DEFER the driver would continue without an interrupt instead of deferring to wait for the interrupt to become available. Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec") Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20211015133619.4698-6-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 24d49d9f0dc6d7f33512d8d7dfd28a04559670d0 Author: Richard Fitzgerald Date: Fri Oct 15 14:36:06 2021 +0100 ASoC: cs42l42: Correct some register default values [ Upstream commit d591d4b32aa9552af14a0c7c586a2d3fe9ecc6e0 ] Some registers had wrong default values in cs42l42_reg_defaults[]. Signed-off-by: Richard Fitzgerald Fixes: 2c394ca79604 ("ASoC: Add support for CS42L42 codec") Link: https://lore.kernel.org/r/20211015133619.4698-4-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 066f6d94e87bc2eb4d3f89024be62d561b2d3bc9 Author: Richard Fitzgerald Date: Fri Oct 15 14:36:05 2021 +0100 ASoC: cs42l42: Always configure both ASP TX channels [ Upstream commit 6e6825801ab926360f7f4f2dbcfd107d5ab8f025 ] An I2S frame always has two slots (left and right) even when sending mono. The right channel (channel 2) of ASP TX will always have the same bit width as the left channel and will always be on the high phase of LRCLK. The previous implementation always passed the field masks for both channels to snd_soc_component_update_bits() but for mono the written value only contained the settings for channel 1. The result was that for mono channel 2 was set to 8-bit (which is an invalid configuration) with both channels on the low phase of LRCLK. Signed-off-by: Richard Fitzgerald Fixes: 585e7079de0e ("ASoC: cs42l42: Add Capture Support") Link: https://lore.kernel.org/r/20211015133619.4698-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a9e0fed5c3111feece190e37526ffc7773cad510 Author: Olivier Moysan Date: Mon Oct 4 11:03:04 2021 +0200 ARM: dts: stm32: fix AV96 board SAI2 pin muxing on stm32mp15 [ Upstream commit 1a9a9d226f0f0ef5d9bf588ab432e0d679bb1954 ] Fix SAI2A and SAI2B pin muxings for AV96 board on STM32MP15. Change sai2a-4 & sai2a-5 to sai2a-2 & sai2a-2. Change sai2a-4 & sai2a-sleep-5 to sai2b-2 & sai2b-sleep-2 Fixes: dcf185ca8175 ("ARM: dts: stm32: Add alternate pinmux for SAI2 pins on stm32mp15") Signed-off-by: Olivier Moysan Reviewed-by: Marek Vasut Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit de4c998f9634f01c05c68761f35658c1ca53952c Author: Olivier Moysan Date: Fri Sep 24 18:02:21 2021 +0200 ARM: dts: stm32: fix SAI sub nodes register range [ Upstream commit 6f87a74d31277f0896dcf8c0850ec14bde03c423 ] The STM32 SAI subblocks registers offsets are in the range 0x0004 (SAIx_CR1) to 0x0020 (SAIx_DR). The corresponding range length is 0x20 instead of 0x1c. Change reg property accordingly. Fixes: 5afd65c3a060 ("ARM: dts: stm32: add sai support on stm32mp157c") Signed-off-by: Olivier Moysan Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit d39348632e9e94c010f5d8ae8506515322af520b Author: Fabrice Gasnier Date: Tue Sep 21 15:34:49 2021 +0200 ARM: dts: stm32: fix STUSB1600 Type-C irq level on stm32mp15xx-dkx [ Upstream commit 3d4fb3d4c431f45272bf8c308d3cbe030817f046 ] STUSB1600 IRQ (Alert pin) is active low (open drain). Interrupts may get lost currently, so fix the IRQ type. Fixes: 83686162c0eb ("ARM: dts: stm32: add STUSB1600 Type-C using I2C4 on stm32mp15xx-dkx") Signed-off-by: Fabrice Gasnier Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit 74447d38de5e645c55c186c5ca87e079242b56b6 Author: Marek Vasut Date: Mon Aug 9 14:13:24 2021 +0200 ARM: dts: stm32: Reduce DHCOR SPI NOR frequency to 50 MHz [ Upstream commit 2012579b31293d0a8cf2024e9dab66810bf1a15e ] The SPI NOR is a bit further away from the SoC on DHCOR than on DHCOM, which causes additional signal delay. At 108 MHz, this delay triggers a sporadic issue where the first bit of RX data is not received by the QSPI controller. There are two options of addressing this problem, either by using the DLYB block to compensate the extra delay, or by reducing the QSPI bus clock frequency. The former requires calibration and that is overly complex, so opt for the second option. Fixes: 76045bc457104 ("ARM: dts: stm32: Add QSPI NOR on AV96") 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 d34d4f395674545d1131890d4f3068fb68fd9ba9 Author: Geert Uytterhoeven Date: Thu Oct 7 16:38:47 2021 +0200 pinctrl: renesas: checker: Fix off-by-one bug in drive register check [ Upstream commit 28e7f8ff90583791a034d43b5d2e3fe394142e13 ] The GENMASK(h, l) macro creates a contiguous bitmask starting at bit position @l and ending at position @h, inclusive. This did not trigger any error checks, as the individual register fields cover at most 3 of the 4 available bits. Fixes: 08df16e07ad0a1ec ("pinctrl: sh-pfc: checker: Add drive strength register checks") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/8f82d6147fbe3367d4c83962480e97f58d9c96a2.1633615652.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 03f7759f90036990800edecfb65b85b8fffaccca Author: Athira Rajeev Date: Thu Oct 7 13:21:21 2021 +0530 powerpc/perf: Fix cycles/instructions as PM_CYC/PM_INST_CMPL in power10 [ Upstream commit 8f6aca0e0f26eaaee670cd27896993a45cdc8f9e ] On power9 and earlier platforms, the default event used for cyles and instructions is PM_CYC (0x0001e) and PM_INST_CMPL (0x00002) respectively. These events use two programmable PMCs and by default will count irrespective of the run latch state (idle state). But since they use programmable PMCs, these events can lead to multiplexing with other events, because there are only 4 programmable PMCs. Hence in power10, performance monitoring unit (PMU) driver uses performance monitor counter 5 (PMC5) and performance monitor counter6 (PMC6) for counting instructions and cycles. Currently on power10, the event used for cycles is PM_RUN_CYC (0x600F4) and instructions uses PM_RUN_INST_CMPL (0x500fa). But counting of these events in idle state is controlled by the CC56RUN bit setting in Monitor Mode Control Register0 (MMCR0). If the CC56RUN bit is zero, PMC5/6 will not count when CTRL[RUN] (run latch) is zero. This could lead to missing some counts if a thread is in idle state during system wide profiling. To fix it, set the CC56RUN bit in MMCR0 for power10, which makes PMC5 and PMC6 count instructions and cycles regardless of the run latch state. Since this change make PMC5/6 count as PM_INST_CMPL/PM_CYC, rename the event code 0x600f4 as PM_CYC instead of PM_RUN_CYC and event code 0x500fa as PM_INST_CMPL instead of PM_RUN_INST_CMPL. The changes are only for PMC5/6 event codes and will not affect the behaviour of PM_RUN_CYC/PM_RUN_INST_CMPL if progammed in other PMC's. Fixes: a64e697cef23 ("powerpc/perf: power10 Performance Monitoring support") Signed-off-by: Athira Rajeev Reviewed-by: Madhavan Srinivasan [mpe: Tweak change log wording for style and consistency] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211007075121.28497-1-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit ae59bf22496549f988a077c66d3e70b0680b8226 Author: Andrew Halaney Date: Wed Oct 13 11:40:20 2021 -0400 dyndbg: make dyndbg a known cli param [ Upstream commit 5ca173974888368fecfb17ae6fe455df5fd2a9d2 ] Right now dyndbg shows up as an unknown parameter if used on boot: Unknown command line parameters: dyndbg=+p That's because it is unknown, it doesn't sit in the __param section, so the processing done to warn users supplying an unknown parameter doesn't think it is legitimate. Install a dummy handler to register it. dynamic debug needs to search the whole command line for modules listed that are currently builtin, so there's no real work to be done in this callback. Fixes: 86d1919a4fb0 ("init: print out unknown kernel parameters") Tested-by: Jim Cromie Signed-off-by: Andrew Halaney Signed-off-by: Jason Baron Link: https://lore.kernel.org/r/1634139622-20667-2-git-send-email-jbaron@akamai.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4d3bee930ce9e57bb897c6667b9aabccaceea0bd Author: Vegard Nossum Date: Mon Oct 11 17:29:41 2021 +0200 staging: ks7010: select CRYPTO_HASH/CRYPTO_MICHAEL_MIC [ Upstream commit 9ca0e55e52c7b2a99f3c2051fc4bd1c63a061519 ] Fix the following build/link errors: ld: drivers/staging/ks7010/ks_hostif.o: in function `michael_mic.constprop.0': ks_hostif.c:(.text+0x95b): undefined reference to `crypto_alloc_shash' ld: ks_hostif.c:(.text+0x97a): undefined reference to `crypto_shash_setkey' ld: ks_hostif.c:(.text+0xa13): undefined reference to `crypto_shash_update' ld: ks_hostif.c:(.text+0xa28): undefined reference to `crypto_shash_update' ld: ks_hostif.c:(.text+0xa48): undefined reference to `crypto_shash_finup' ld: ks_hostif.c:(.text+0xa6d): undefined reference to `crypto_destroy_tfm' Fixes: 8b523f20417d ("staging: ks7010: removed custom Michael MIC implementation.") Fixes: 3e5bc68fa5968 ("staging: ks7010: Fix build error") Fixes: a4961427e7494 ("Revert "staging: ks7010: Fix build error"") Signed-off-by: Vegard Nossum Link: https://lore.kernel.org/r/20211011152941.12847-1-vegard.nossum@oracle.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d9d5778013503c2bdad0b608708964753e339292 Author: Nikita Yushchenko Date: Mon Oct 11 09:11:18 2021 +0300 staging: most: dim2: do not double-register the same device [ Upstream commit 2ab189164056b05474275bb40caa038a37713061 ] Commit 723de0f9171e ("staging: most: remove device from interface structure") moved registration of driver-provided struct device to the most subsystem. Dim2 used to register the same struct device to provide a custom device attribute. This causes double-registration of the same struct device. Fix that by moving the custom attribute to driver's dev_groups. This moves attribute to the platform_device object, which is a better location for platform-specific attributes anyway. Fixes: 723de0f9171e ("staging: most: remove device from interface structure") Acked-by: Christian Gromm Signed-off-by: Nikita Yushchenko Link: https://lore.kernel.org/r/20211011061117.21435-1-nikita.yoush@cogentembedded.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 65f101a4bb562c331388e626369de1e1e5ea8d91 Author: Randy Dunlap Date: Tue Oct 5 16:57:47 2021 -0700 usb: musb: select GENERIC_PHY instead of depending on it [ Upstream commit fde1fbedbaed4e76cef4600d775b185f59b9b568 ] The kconfig symbol GENERIC_PHY says: All the users of this framework should select this config. and around 136 out of 138 drivers do so, so change USB_MUSB_MEDIATEK to do so also. This (also) fixes a long circular dependency problem for an upcoming patch. Fixes: 0990366bab3c ("usb: musb: Add support for MediaTek musb controller") Cc: Bin Liu Cc: Min Guo Cc: Yonglong Wu Cc: Greg Kroah-Hartman Cc: linux-mediatek@lists.infradead.org Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20211005235747.5588-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 04ec60e77ef29c1fa17afd549890fb8ce3cadb03 Author: Leon Romanovsky Date: Tue Oct 12 10:28:43 2021 +0300 RDMA/mlx4: Return missed an error if device doesn't support steering [ Upstream commit f4e56ec4452f48b8292dcf0e1c4bdac83506fb8b ] The error flow fixed in this patch is not possible because all kernel users of create QP interface check that device supports steering before set IB_QP_CREATE_NETIF_QP flag. Fixes: c1c98501121e ("IB/mlx4: Add support for steerable IB UD QPs") Link: https://lore.kernel.org/r/91c61f6e60eb0240f8bbc321fda7a1d2986dd03c.1634023677.git.leonro@nvidia.com Reported-by: Dan Carpenter Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 96e9a4068a2a0c9749ae0a24acb21546e52433a2 Author: Dan Carpenter Date: Wed Oct 6 10:32:43 2021 +0300 scsi: csiostor: Uninitialized data in csio_ln_vnp_read_cbfn() [ Upstream commit f4875d509a0a78ad294a1a538d534b5ba94e685a ] This variable is just a temporary variable, used to do an endian conversion. The problem is that the last byte is not initialized. After the conversion is completely done, the last byte is discarded so it doesn't cause a problem. But static checkers and the KMSan runtime checker can detect the uninitialized read and will complain about it. Link: https://lore.kernel.org/r/20211006073242.GA8404@kili Fixes: 5036f0a0ecd3 ("[SCSI] csiostor: Fix sparse warnings.") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f0d4f0cd9442e45fe0e65b1bb5e4b5c6b252fb29 Author: Yang Yingliang Date: Fri Oct 8 14:31:50 2021 +0800 power: supply: max17040: fix null-ptr-deref in max17040_probe() [ Upstream commit 1d422ecfc48ee683ae1ccc9217764f6310c0ffce ] Add check the return value of devm_regmap_init_i2c(), otherwise later access may cause null-ptr-deref as follows: KASAN: null-ptr-deref in range [0x0000000000000360-0x0000000000000367] RIP: 0010:regmap_read+0x33/0x170 Call Trace: max17040_probe+0x61b/0xff0 [max17040_battery] ? write_comp_data+0x2a/0x90 ? max17040_set_property+0x1d0/0x1d0 [max17040_battery] ? tracer_hardirqs_on+0x33/0x520 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? _raw_spin_unlock_irqrestore+0x4b/0x60 ? trace_hardirqs_on+0x63/0x2d0 ? write_comp_data+0x2a/0x90 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? max17040_set_property+0x1d0/0x1d0 [max17040_battery] i2c_device_probe+0xa31/0xbe0 Fixes: 6455a8a84bdf ("power: supply: max17040: Use regmap i2c") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 71ad44224a78a4958e8d7c49e58564909a975b9b Author: Jakob Hauser Date: Fri Oct 8 10:32:45 2021 +0200 power: supply: rt5033_battery: Change voltage values to µV [ Upstream commit bf895295e9a73411889816f1a0c1f4f1a2d9c678 ] Currently the rt5033_battery driver provides voltage values in mV. It should be µV as stated in Documentation/power/power_supply_class.rst. Fixes: b847dd96e659 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver") Cc: Beomho Seo Cc: Chanwoo Choi Signed-off-by: Jakob Hauser Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 4848d094da0ec8178281c0c88e97fcf8997cf982 Author: Dan Carpenter Date: Mon Oct 11 15:37:39 2021 +0300 usb: gadget: hid: fix error code in do_config() [ Upstream commit 68e7c510fdf4f6167404609da52e1979165649f6 ] Return an error code if usb_get_function() fails. Don't return success. Fixes: 4bc8a33f2407 ("usb: gadget: hid: convert to new interface of f_hid") Acked-by: Felipe Balbi Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211011123739.GC15188@kili Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ff22ff487e5aa6580598d47364a5c9dde3559f59 Author: Andy Shevchenko Date: Tue Oct 5 16:45:16 2021 +0300 serial: 8250_dw: Drop wrong use of ACPI_PTR() [ Upstream commit ebabb77a2a115b6c5e68f7364b598310b5f61fb2 ] ACPI_PTR() is more harmful than helpful. For example, in this case if CONFIG_ACPI=n, the ID table left unused which is not what we want. Instead of adding ifdeffery here and there, drop ACPI_PTR(). Fixes: 6a7320c4669f ("serial: 8250_dw: Add ACPI 5.0 support") Reported-by: Daniel Palmer Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20211005134516.23218-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1e405bd00949d37c11a4e31b7ea2cab3c0f77c6c Author: Nathan Lynch Date: Tue Sep 28 16:41:47 2021 -0500 powerpc/paravirt: correct preempt debug splat in vcpu_is_preempted() [ Upstream commit fda0eb220021a97c1d656434b9340ebf3fc4704a ] vcpu_is_preempted() can be used outside of preempt-disabled critical sections, yielding warnings such as: BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/185 caller is rwsem_spin_on_owner+0x1cc/0x2d0 CPU: 1 PID: 185 Comm: systemd-udevd Not tainted 5.15.0-rc2+ #33 Call Trace: [c000000012907ac0] [c000000000aa30a8] dump_stack_lvl+0xac/0x108 (unreliable) [c000000012907b00] [c000000001371f70] check_preemption_disabled+0x150/0x160 [c000000012907b90] [c0000000001e0e8c] rwsem_spin_on_owner+0x1cc/0x2d0 [c000000012907be0] [c0000000001e1408] rwsem_down_write_slowpath+0x478/0x9a0 [c000000012907ca0] [c000000000576cf4] filename_create+0x94/0x1e0 [c000000012907d10] [c00000000057ac08] do_symlinkat+0x68/0x1a0 [c000000012907d70] [c00000000057ae18] sys_symlink+0x58/0x70 [c000000012907da0] [c00000000002e448] system_call_exception+0x198/0x3c0 [c000000012907e10] [c00000000000c54c] system_call_common+0xec/0x250 The result of vcpu_is_preempted() is always used speculatively, and the function does not access per-cpu resources in a (Linux) preempt-unsafe way. Use raw_smp_processor_id() to avoid such warnings, adding explanatory comments. Fixes: ca3f969dcb11 ("powerpc/paravirt: Use is_kvm_guest() in vcpu_is_preempted()") Signed-off-by: Nathan Lynch Reviewed-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210928214147.312412-3-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit e093b8b68af7c04d4dee770d3adf1d135643e395 Author: Nathan Lynch Date: Tue Sep 28 07:45:50 2021 -0500 powerpc: fix unbalanced node refcount in check_kvm_guest() [ Upstream commit 56537faf8821e361d739fc5ff58c9c40f54a1d4c ] When check_kvm_guest() succeeds in looking up a /hypervisor OF node, it returns without performing a matching put for the lookup, leaving the node's reference count elevated. Add the necessary call to of_node_put(), rearranging the code slightly to avoid repetition or goto. Fixes: 107c55005fbd ("powerpc/pseries: Add KVM guest doorbell restrictions") Signed-off-by: Nathan Lynch Reviewed-by: Srikar Dronamraju Reviewed-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210928124550.132020-1-nathanl@linux.ibm.com Signed-off-by: Sasha Levin commit 87557023bcf06d3d515f720d21bb456bca07df36 Author: Christophe Leroy Date: Wed Sep 15 15:34:35 2021 +0200 video: fbdev: chipsfb: use memset_io() instead of memset() [ Upstream commit f2719b26ae27282c145202ffd656d5ff1fe737cc ] While investigating a lockup at startup on Powerbook 3400C, it was identified that the fbdev driver generates alignment exception at startup: --- interrupt: 600 at memset+0x60/0xc0 NIP: c0021414 LR: c03fc49c CTR: 00007fff REGS: ca021c10 TRAP: 0600 Tainted: G W (5.14.2-pmac-00727-g12a41fa69492) MSR: 00009032 CR: 44008442 XER: 20000100 DAR: cab80020 DSISR: 00017c07 GPR00: 00000007 ca021cd0 c14412e0 cab80000 00000000 00100000 cab8001c 00000004 GPR08: 00100000 00007fff 00000000 00000000 84008442 00000000 c0006fb4 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00100000 GPR24: 00000000 81800000 00000320 c15fa400 c14d1878 00000000 c14d1800 c094e19c NIP [c0021414] memset+0x60/0xc0 LR [c03fc49c] chipsfb_pci_init+0x160/0x580 --- interrupt: 600 [ca021cd0] [c03fc46c] chipsfb_pci_init+0x130/0x580 (unreliable) [ca021d20] [c03a3a70] pci_device_probe+0xf8/0x1b8 [ca021d50] [c043d584] really_probe.part.0+0xac/0x388 [ca021d70] [c043d914] __driver_probe_device+0xb4/0x170 [ca021d90] [c043da18] driver_probe_device+0x48/0x144 [ca021dc0] [c043e318] __driver_attach+0x11c/0x1c4 [ca021de0] [c043ad30] bus_for_each_dev+0x88/0xf0 [ca021e10] [c043c724] bus_add_driver+0x190/0x22c [ca021e40] [c043ee94] driver_register+0x9c/0x170 [ca021e60] [c0006c28] do_one_initcall+0x54/0x1ec [ca021ed0] [c08246e4] kernel_init_freeable+0x1c0/0x270 [ca021f10] [c0006fdc] kernel_init+0x28/0x11c [ca021f30] [c0017148] ret_from_kernel_thread+0x14/0x1c Instruction dump: 7d4601a4 39490777 7d4701a4 39490888 7d4801a4 39490999 7d4901a4 39290aaa 7d2a01a4 4c00012c 4bfffe88 0fe00000 <4bfffe80> 9421fff0 38210010 48001970 This is due to 'dcbz' instruction being used on non-cached memory. 'dcbz' instruction is used by memset() to zeroize a complete cacheline at once, and memset() is not expected to be used on non cached memory. When performing a 'sparse' check on fbdev driver, it also appears that the use of memset() is unexpected: drivers/video/fbdev/chipsfb.c:334:17: warning: incorrect type in argument 1 (different address spaces) drivers/video/fbdev/chipsfb.c:334:17: expected void * drivers/video/fbdev/chipsfb.c:334:17: got char [noderef] __iomem *screen_base drivers/video/fbdev/chipsfb.c:334:15: warning: memset with byte count of 1048576 Use fb_memset() instead of memset(). fb_memset() is defined as memset_io() for powerpc. Fixes: 8c8709334cec ("[PATCH] ppc32: Remove CONFIG_PMAC_PBOOK") Reported-by: Stan Johnson Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/884a54f1e5cb774c1d9b4db780209bee5d4f6718.1631712563.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 327788eb627c1db3e4d49c8160bed06a174eb11b Author: Christophe Leroy Date: Mon Sep 13 17:17:26 2021 +0200 powerpc/mem: Fix arch/powerpc/mm/mem.c:53:12: error: no previous prototype for 'create_section_mapping' [ Upstream commit 7eff9bc00ddf1e2281dff575884b7f676c85b006 ] Commit 8e11d62e2e87 ("powerpc/mem: Add back missing header to fix 'no previous prototype' error") was supposed to fix the problem, but in the meantime commit a927bd6ba952 ("mm: fix phys_to_target_node() and* memory_add_physaddr_to_nid() exports") moved create_section_mapping() prototype from asm/sparsemem.h to asm/mmzone.h Fixes: 8e11d62e2e87 ("powerpc/mem: Add back missing header to fix 'no previous prototype' error") Reported-by: kernel test robot Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/025754fde3d027904ae9d0191f395890bec93369.1631541649.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 5ec603fc4c1f3224924a177b62fe339577256c89 Author: Clément Léger Date: Mon Sep 13 10:26:33 2021 +0200 clk: at91: check pmc node status before registering syscore ops [ Upstream commit c405f5c15e9f6094f2fa1658e73e56f3058e2122 ] Currently, at91 pmc driver always register the syscore_ops whatever the status of the pmc node that has been found. When set as secure and disabled, the pmc should not be accessed or this will generate abort exceptions. To avoid this, add a check on node availability before registering the syscore operations. Signed-off-by: Clément Léger Link: https://lore.kernel.org/r/20210913082633.110168-1-clement.leger@bootlin.com Acked-by: Nicolas Ferre Reviewed-by: Claudiu Beznea Fixes: b3b02eac33ed ("clk: at91: Add sama5d2 suspend/resume") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b885c49c77331fd2e8a8fa29e41717e8d18d2328 Author: Dongliang Mu Date: Sat Sep 25 23:14:32 2021 +0800 memory: fsl_ifc: fix leak of irq and nand_irq in fsl_ifc_ctrl_probe [ Upstream commit 4ed2f3545c2e5acfbccd7f85fea5b1a82e9862d7 ] The error handling code of fsl_ifc_ctrl_probe is problematic. When fsl_ifc_ctrl_init fails or request_irq of fsl_ifc_ctrl_dev->irq fails, it forgets to free the irq and nand_irq. Meanwhile, if request_irq of fsl_ifc_ctrl_dev->nand_irq fails, it will still free nand_irq even if the request_irq is not successful. Fix this by refactoring the error handling code. Fixes: d2ae2e20fbdd ("driver/memory:Move Freescale IFC driver to a common driver") Signed-off-by: Dongliang Mu Link: https://lore.kernel.org/r/20210925151434.8170-1-mudongliangabcd@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 677ee2d1634ab0f155699dee8428450a8dd0c487 Author: Christophe JAILLET Date: Sun Jun 27 17:54:31 2021 +0200 soc/tegra: Fix an error handling path in tegra_powergate_power_up() [ Upstream commit 986b5094708e508baa452a23ffe809870934a7df ] If an error occurs after a successful tegra_powergate_enable_clocks() call, it must be undone by a tegra_powergate_disable_clocks() call, as already done in the below and above error handling paths of this function. Update the 'goto' to branch at the correct place of the error handling path. Fixes: a38045121bf4 ("soc/tegra: pmc: Add generic PM domain support") Signed-off-by: Christophe JAILLET Reviewed-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 3a39364557c3b07c5db6ffc26345391bf75d3efa Author: Mark Brown Date: Mon Sep 27 14:41:53 2021 +0100 iio: st_pressure_spi: Add missing entries SPI to device ID table [ Upstream commit 03748d4e003c9f2ad3cd00e3e46f054dcad6b96d ] Currently autoloading for SPI devices does not use the DT ID table, it uses SPI modalises. Supporting OF modalises is going to be difficult if not impractical, an attempt was made but has been reverted, so ensure that module autoloading works for this driver by adding SPI IDs for parts that only have a compatible listed. Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210927134153.12739-1-broonie@kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit c23d6902073eb407e0917089ca4ab9872dba1b90 Author: Ranjani Sridharan Date: Wed Oct 6 13:40:41 2021 +0300 ASoC: SOF: topology: do not power down primary core during topology removal [ Upstream commit ec626334eaffe101df9ed79e161eba95124e64ad ] When removing the topology components, do not power down the primary core. Doing so will result in an IPC timeout when the SOF PCI device runtime suspends. Fixes: 0dcdf84289fb ("ASoC: SOF: add a "core" parameter to widget loading functions") Signed-off-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Reviewed-by: Kai Vehmanen Signed-off-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20211006104041.27183-1-peter.ujfalusi@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b810bd3db9efc24e4890cb47ac70e6861b0ed59d Author: Andreas Kemnade Date: Fri Oct 1 09:34:15 2021 +0200 arm: dts: omap3-gta04a4: accelerometer irq fix [ Upstream commit 884ea75d79a36faf3731ad9d6b9c29f58697638d ] Fix typo in pinctrl. It did only work because the bootloader seems to have initialized it. Fixes: ee327111953b ("ARM: dts: omap3-gta04: Define and use bma180 irq pin") Signed-off-by: Andreas Kemnade Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit c8542e40a77918c30fdbd1df9253f2b4c400ea50 Author: Yang Yingliang Date: Thu Sep 30 16:57:14 2021 +0800 driver core: Fix possible memory leak in device_link_add() [ Upstream commit df0a18149474c7e6b21f6367fbc6bc8d0f192444 ] I got memory leak as follows: unreferenced object 0xffff88801f0b2200 (size 64): comm "i2c-lis2hh12-21", pid 5455, jiffies 4294944606 (age 15.224s) hex dump (first 32 bytes): 72 65 67 75 6c 61 74 6f 72 3a 72 65 67 75 6c 61 regulator:regula 74 6f 72 2e 30 2d 2d 69 32 63 3a 31 2d 30 30 31 tor.0--i2c:1-001 backtrace: [<00000000bf5b0c3b>] __kmalloc_track_caller+0x19f/0x3a0 [<0000000050da42d9>] kvasprintf+0xb5/0x150 [<000000004bbbed13>] kvasprintf_const+0x60/0x190 [<00000000cdac7480>] kobject_set_name_vargs+0x56/0x150 [<00000000bf83f8e8>] dev_set_name+0xc0/0x100 [<00000000cc1cf7e3>] device_link_add+0x6b4/0x17c0 [<000000009db9faed>] _regulator_get+0x297/0x680 [<00000000845e7f2b>] _devm_regulator_get+0x5b/0xe0 [<000000003958ee25>] st_sensors_power_enable+0x71/0x1b0 [st_sensors] [<000000005f450f52>] st_accel_i2c_probe+0xd9/0x150 [st_accel_i2c] [<00000000b5f2ab33>] i2c_device_probe+0x4d8/0xbe0 [<0000000070fb977b>] really_probe+0x299/0xc30 [<0000000088e226ce>] __driver_probe_device+0x357/0x500 [<00000000c21dda32>] driver_probe_device+0x4e/0x140 [<000000004e650441>] __device_attach_driver+0x257/0x340 [<00000000cf1891b8>] bus_for_each_drv+0x166/0x1e0 When device_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used instead of kfree() to give up the device reference, then the name will be freed in kobject_cleanup() and the references of consumer and supplier will be decreased in device_link_release_fn(). Fixes: 287905e68dd2 ("driver core: Expose device link details in sysfs") Reported-by: Hulk Robot Reviewed-by: Saravana Kannan Reviewed-by: Rafael J. Wysocki Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210930085714.2057460-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 13f731ac9b17f75b4e4c9da312bcee9d241e7bff Author: Igor Pylypiv Date: Tue Sep 28 19:58:47 2021 -0700 scsi: pm80xx: Fix misleading log statement in pm8001_mpi_get_nvmd_resp() [ Upstream commit 4084a7235d38311a77c86ba69ba849bd787db87b ] pm8001_mpi_get_nvmd_resp() handles a GET_NVMD_DATA response, not a SET_NVMD_DATA response, as the log statement implies. Fixes: 1f889b58716a ("scsi: pm80xx: Fix pm8001_mpi_get_nvmd_resp() race condition") Link: https://lore.kernel.org/r/20210929025847.646999-1-ipylypiv@google.com Reviewed-by: Changyuan Lyu Acked-by: Jack Wang Signed-off-by: Igor Pylypiv Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 945070ab3d912f7609e9c296a0a7f594755678af Author: Sumit Saxena Date: Wed Sep 29 18:10:20 2021 +0530 scsi: megaraid_sas: Fix concurrent access to ISR between IRQ polling and real interrupt [ Upstream commit e7dcc514a49e74051b869697d5ab0370f6301d57 ] IRQ polling thread calls ISR after enable_irq() to handle any missed I/O completion. The atomic flag "in_used" was added to have the synchronization between the IRQ polling thread and the interrupt context. There is a bug around it leading to a race condition. Below is the sequence: - IRQ polling thread accesses ISR, fetches the reply descriptor. - Real interrupt arrives and pre-empts polling thread (enable_irq() is already called). - Interrupt context picks the same reply descriptor as fetched by polling thread, processes it, and exits. - Polling thread resumes and processes the descriptor which is already processed by interrupt thread leads to kernel crash. Setting the "in_used" flag before fetching the reply descriptor ensures synchronized access to ISR. Link: https://www.spinics.net/lists/linux-scsi/msg159440.html Link: https://lore.kernel.org/r/20210929124022.24605-2-sumit.saxena@broadcom.com Fixes: 9bedd36e9146 ("scsi: megaraid_sas: Handle missing interrupts while re-enabling IRQs") Signed-off-by: Sumit Saxena Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e850922067ec90406ef4e98678360e03dfc03caf Author: Claudiu Beznea Date: Thu Sep 30 13:09:28 2021 +0300 power: reset: at91-reset: check properly the return value of devm_of_iomap [ Upstream commit f558c8072c3461b65c12c0068b108f78cebc8246 ] devm_of_iomap() returns error code or valid pointer. Check its return value with IS_ERR(). Fixes: bd3127733f2c ("power: reset: at91-reset: use devm_of_iomap") Reported-by: Cristian Birsan Signed-off-by: Claudiu Beznea Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 60b15e314825295d942bdfa17053f997a5105cd4 Author: Srinivas Kandagatla Date: Tue Sep 7 11:53:32 2021 +0100 soundwire: debugfs: use controller id and link_id for debugfs [ Upstream commit 75eac387a2539aa6c6bbee3affa23435f2096396 ] link_id can be zero and if we have multiple controller instances in a system like Qualcomm debugfs will end-up with duplicate namespace resulting in incorrect debugfs entries. Using bus-id and link-id combination should give a unique debugfs directory entry and should fix below warning too. "debugfs: Directory 'master-0' with parent 'soundwire' already present!" Fixes: bf03473d5bcc ("soundwire: add debugfs support") Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210907105332.1257-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit ee6e999f3f3dfdca9f5a86268f12220bdc1285eb Author: Takashi Iwai Date: Wed Sep 29 09:29:34 2021 +0200 ALSA: hda: Use position buffer for SKL+ again [ Upstream commit c4ca3871e21fa085096316f5f8d9975cf3dfde1d ] The commit f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+") changed the PCM position report for SKL+ chips to use DPIB, but according to Pierre, DPIB is no best choice for the accurate position reports and it often reports too early. The recommended method is rather the classical position buffer. This patch makes the PCM position reporting on SKL+ back to the position buffer again. Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+") Suggested-by: Pierre-Louis Bossart Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210929072934.6809-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 51ebfe87c0a8237b54bbef4d89f802bf6e3eb365 Author: Takashi Iwai Date: Wed Sep 29 09:29:33 2021 +0200 ALSA: hda: Reduce udelay() at SKL+ position reporting [ Upstream commit 46243b85b0ec5d2cee7545e5ce18c015ce91957e ] The position reporting on Intel Skylake and later chips via azx_get_pos_skl() contains a udelay(20) call for the capture streams. A call for this alone doesn't sound too harmful. However, as the pointer PCM ops is one of the hottest path in the PCM operations -- especially for the timer-scheduled operations like PulseAudio -- such a delay hogs CPU usage significantly in the total performance. The code there was taken from the original code in ASoC SST Skylake driver blindly. The udelay() is a workaround for the case where the reported position is behind the period boundary at the timing triggered from interrupts; applications often expect that the full data is available for the whole period when returned (and also that's the definition of the ALSA PCM period). OTOH, HD-audio (legacy) driver has already some workarounds for the delayed position reporting due to its relatively large FIFO, such as the BDL position adjustment and the delayed period-elapsed call in the work. That said, the udelay() is almost superfluous for HD-audio driver unlike SST, and we can drop the udelay(). Though, the current code doesn't guarantee the full period readiness as mentioned in the above, but rather it checks the wallclock and detects the unexpected jump. That's one missing piece, and the drop of udelay() needs a bit more sanity checks for the delayed handling. This patch implements those: the drop of udelay() call in azx_get_pos_skl() and the more proper check of hwptr in azx_position_ok(). The latter change is applied only for the case where the stream is running in the normal mode without no_period_wakeup flag. When no_period_wakeup is set, it essentially ignores the period handling and rather concentrates only on the current position; which implies that we don't need to care about the period boundary at all. Fixes: f87e7f25893d ("ALSA: hda - Improved position reporting on SKL+") Reported-by: Jens Axboe Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210929072934.6809-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 9c738280085aeb407a7f78d553e1cd14563e9a98 Author: David Stevens Date: Wed Sep 29 11:32:55 2021 +0900 iommu/dma: Fix arch_sync_dma for map [ Upstream commit 06e620345d544e559b2961cb5a676ec9c80c8950 ] When calling arch_sync_dma, we need to pass it the memory that's actually being used for dma. When using swiotlb bounce buffers, this is the bounce buffer. Move arch_sync_dma into the __iommu_dma_map_swiotlb helper, so it can use the bounce buffer address if necessary. Now that iommu_dma_map_sg delegates to a function which takes care of architectural syncing in the untrusted device case, the call to iommu_dma_sync_sg_for_device can be moved so it only occurs for trusted devices. Doing the sync for untrusted devices before mapping never really worked, since it needs to be able to target swiotlb buffers. This also moves the architectural sync to before the call to __iommu_dma_map, to guarantee that untrusted devices can't see stale data they shouldn't see. Fixes: 82612d66d51d ("iommu: Allow the iommu/dma api to use bounce buffers") Signed-off-by: David Stevens Reviewed-by: Christoph Hellwig Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20210929023300.335969-3-stevensd@google.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 09339ff9e671695c742f8db902db2d3119990c2b Author: Stephan Gerhold Date: Tue Sep 28 13:29:43 2021 +0200 arm64: dts: qcom: pm8916: Remove wrong reg-names for rtc@6000 [ Upstream commit 483de2b44cd3a168458f8f9ff237e78a434729bc ] While removing the size from the "reg" properties in pm8916.dtsi, commit bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties") mistakenly also removed the second register address for the rtc@6000 device. That one did not represent the size of the register region but actually the address of the second "alarm" register region of the rtc@6000 device. Now there are "reg-names" for two "reg" elements, but there is actually only one "reg" listed. Since the DT schema for "qcom,pm8941-rtc" only expects one "reg" element anyway, just drop the "reg-names" entirely to fix this. Fixes: bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties") Signed-off-by: Stephan Gerhold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210928112945.25310-1-stephan@gerhold.net Signed-off-by: Sasha Levin commit 20997b9aca4c529786e84502a537f3333ca95770 Author: Arnd Bergmann Date: Mon Sep 27 14:18:44 2021 +0200 iommu/mediatek: Fix out-of-range warning with clang [ Upstream commit f13efafc1a2cf30d4a74c00f40210d6de36db2d0 ] clang-14 notices that a comparison is never true when CONFIG_PHYS_ADDR_T_64BIT is disabled: drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant 5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE) ~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add an explicit check for the type of the variable to skip the check and the warning in that case. Fixes: b4dad40e4f35 ("iommu/mediatek: Adjust the PA for the 4GB Mode") Signed-off-by: Arnd Bergmann Reviewed-by: Yong Wu Link: https://lore.kernel.org/r/20210927121857.941160-1-arnd@kernel.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit c1b5c72d4d5991ee8f898ba1a71c5ce0d970990a Author: Geert Uytterhoeven Date: Fri Sep 24 08:50:23 2021 +0200 arm64: dts: renesas: beacon: Fix Ethernet PHY mode [ Upstream commit 59a8bda062f8646d99ff8c4956adf37dee1cb75e ] While networking works fine in RGMII mode when using the Linux generic PHY driver, it fails when using the Atheros PHY driver. Fix this by correcting the Ethernet PHY mode to RGMII-RXID, which works fine with both drivers. Fixes: a5200e63af57d05e ("arm64: dts: renesas: rzg2: Convert EtherAVB to explicit delay handling") Reported-by: Adam Ford Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/2a4c15b2df23bb63f15abf9dfb88860477f4f523.1632465965.git.geert+renesas@glider.be Signed-off-by: Sasha Levin commit 44bd0cd11f10e3b79e23c7af977fba18d414f9f4 Author: Stephan Gerhold Date: Mon Aug 16 20:18:10 2021 +0200 arm64: dts: qcom: msm8916: Fix Secondary MI2S bit clock [ Upstream commit 8199a0b31e76d158ac14841e7119890461f8c595 ] At the moment, playing audio on Secondary MI2S will just end up getting stuck, without actually playing any audio. This happens because the wrong bit clock is configured when playing audio on Secondary MI2S. The PRI_I2S_CLK (better name: SPKR_I2S_CLK) is used by the SPKR audio mux block that provides both Primary and Secondary MI2S. The SEC_I2S_CLK (better name: MIC_I2S_CLK) is used by the MIC audio mux block that provides Tertiary MI2S. Quaternary MI2S is also part of the MIC audio mux but has its own clock (AUX_I2S_CLK). This means that (quite confusingly) the SEC_I2S_CLK is not actually used for Secondary MI2S as the name would suggest. Secondary MI2S needs to have the same clock as Primary MI2S configured. Fix the clock list for the lpass node in the device tree and add a comment to clarify this confusing naming. With these changes, audio can be played correctly on Secondary MI2S. Cc: Srinivas Kandagatla Fixes: 3761a3618f55 ("arm64: dts: qcom: add lpass node") Tested-by: Vincent Knecht Signed-off-by: Stephan Gerhold Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210816181810.2242-1-stephan@gerhold.net Signed-off-by: Sasha Levin commit 75988ebce563b0e7c8018893926f4a931fc3022f Author: Yassine Oudjana Date: Sat Sep 25 02:24:19 2021 +0000 ASoC: wcd9335: Use correct version to initialize Class H [ Upstream commit a270bd9abdc3cd04ec194f1f3164823cbb5a905c ] The versioning scheme was changed in an earlier patch, which caused the version being used to initialize WCD9335 to be interpreted as if it was WCD937X, which changed code paths causing broken headphones output. Pass WCD9335 instead of WCD9335_VERSION_2_0 to wcd_clsh_ctrl_alloc to fix it. Fixes: 19c5d1f6a0c3 ("ASoC: codecs: wcd-clsh: add new version support") Signed-off-by: Yassine Oudjana Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20210925022339.786296-1-y.oudjana@protonmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit fd4bc9383153646ec9a4314810c664f313c25af6 Author: Dongliang Mu Date: Sat Sep 4 10:37:41 2021 +0800 JFS: fix memleak in jfs_mount [ Upstream commit c48a14dca2cb57527dde6b960adbe69953935f10 ] In jfs_mount, when diMount(ipaimap2) fails, it goes to errout35. However, the following code does not free ipaimap2 allocated by diReadSpecial. Fix this by refactoring the error handling code of jfs_mount. To be specific, modify the lable name and free ipaimap2 when the above error ocurrs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Dongliang Mu Signed-off-by: Dave Kleikamp Signed-off-by: Sasha Levin commit 08276a9bb6db91026512841c57a73d407ee65692 Author: Jackie Liu Date: Mon Sep 13 14:19:08 2021 +0800 MIPS: loongson64: make CPU_LOONGSON64 depends on MIPS_FP_SUPPORT [ Upstream commit 7f3b3c2bfa9c93ab9b5595543496f570983dc330 ] mach/loongson64 fails to build when the FPU support is disabled: arch/mips/loongson64/cop2-ex.c:45:15: error: implicit declaration of function ‘__is_fpu_owner’; did you mean ‘is_fpu_owner’? [-Werror=implicit-function-declaration] arch/mips/loongson64/cop2-ex.c:98:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:99:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:131:43: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:137:38: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:203:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:219:30: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:283:38: error: ‘struct thread_struct’ has no member named ‘fpu’ arch/mips/loongson64/cop2-ex.c:301:38: error: ‘struct thread_struct’ has no member named ‘fpu’ Fixes: ef2f826c8f2f ("MIPS: Loongson-3: Enable the COP2 usage") Suggested-by: Huacai Chen Reviewed-by: Huacai Chen Reported-by: k2ci robot Signed-off-by: Jackie Liu Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit e0d09ee78793624528c6050f9314bf752d6c6edc Author: Tong Zhang Date: Mon Sep 6 21:07:02 2021 -0700 scsi: dc395: Fix error case unwinding [ Upstream commit cbd9a3347c757383f3d2b50cf7cfd03eb479c481 ] dc395x_init_one()->adapter_init() might fail. In this case, the acb is already cleaned up by adapter_init(), no need to do that in adapter_uninit(acb) again. [ 1.252251] dc395x: adapter init failed [ 1.254900] RIP: 0010:adapter_uninit+0x94/0x170 [dc395x] [ 1.260307] Call Trace: [ 1.260442] dc395x_init_one.cold+0x72a/0x9bb [dc395x] Link: https://lore.kernel.org/r/20210907040702.1846409-1-ztong0001@gmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Finn Thain Signed-off-by: Tong Zhang Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 231b0e5b20cdf5ff5d4297c4a036e5672fc76ddd Author: Naina Mehta Date: Tue Sep 21 11:29:42 2021 +0530 soc: qcom: llcc: Disable MMUHWT retention [ Upstream commit 3a461009e195c3c17f6af73da310b886991309fd ] Disable MMUHWT retention for SC7280 as done for other platforms to avoid more power burn. Fixes: f6a07be63301 ("soc: qcom: llcc: Add configuration data for SC7280") Signed-off-by: Naina Mehta Signed-off-by: Sai Prakash Ranjan Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210921055942.30600-1-saiprakash.ranjan@codeaurora.org Signed-off-by: Sasha Levin commit 1ba41a69c0799b4d7b57e959c0a76e39e5b1bdbb Author: Douglas Anderson Date: Thu Sep 2 14:51:37 2021 -0700 arm64: dts: qcom: sc7180: Base dynamic CPU power coefficients in reality [ Upstream commit 82ea7d411d43f60dce878252558e926f957109f0 ] The sc7180's dynamic-power-coefficient violates the device tree bindings. The bindings (arm/cpus.yaml) say that the units for the dynamic-power-coefficient are supposed to be "uW/MHz/V^2". The ones for sc7180 aren't this. Qualcomm arbitrarily picked 100 for the "little" CPUs and then picked a number for the big CPU based on this. At the time, there was a giant dicussion about this. Apparently Qualcomm Engineers were instructed not to share the actual numbers here. As part of the discussion, I pointed out [1] that these numbers shouldn't really be secret since once a device is shipping anyone can just run a script and produce them. This patch is the result of running the script I posted in that discussion on sc7180-trogdor-coachz, which is currently available for purchase by consumers. [1] https://lore.kernel.org/r/CAD=FV=U1FP0e3_AVHpauUUZtD-5X3XCwh5aT9fH_8S_FFML2Uw@mail.gmail.com/ I ran the script four times, measuring little, big, little, big. I used the 64-bit version of dhrystone 2.2 in my test. I got these results: 576 kHz, 596 mV, 20 mW, 88 Cx 768 kHz, 596 mV, 32 mW, 122 Cx 1017 kHz, 660 mV, 45 mW, 97 Cx 1248 kHz, 720 mV, 87 mW, 139 Cx 1324 kHz, 756 mV, 109 mW, 148 Cx 1516 kHz, 828 mV, 150 mW, 148 Cx 1612 kHz, 884 mV, 182 mW, 147 Cx 1708 kHz, 884 mV, 192 mW, 146 Cx 1804 kHz, 884 mV, 207 mW, 149 Cx Your dynamic-power-coefficient for cpu 0: 132 825 kHz, 596 mV, 142 mW, 401 Cx 979 kHz, 628 mV, 183 mW, 427 Cx 1113 kHz, 656 mV, 224 mW, 433 Cx 1267 kHz, 688 mV, 282 mW, 449 Cx 1555 kHz, 812 mV, 475 mW, 450 Cx 1708 kHz, 828 mV, 566 mW, 478 Cx 1843 kHz, 884 mV, 692 mW, 476 Cx 1900 kHz, 884 mV, 722 mW, 482 Cx 1996 kHz, 916 mV, 814 mW, 482 Cx 2112 kHz, 916 mV, 862 mW, 483 Cx 2208 kHz, 916 mV, 962 mW, 521 Cx 2323 kHz, 940 mV, 1060 mW, 517 Cx 2400 kHz, 956 mV, 1133 mW, 518 Cx Your dynamic-power-coefficient for cpu 6: 471 576 kHz, 596 mV, 26 mW, 103 Cx 768 kHz, 596 mV, 40 mW, 147 Cx 1017 kHz, 660 mV, 54 mW, 114 Cx 1248 kHz, 720 mV, 97 mW, 151 Cx 1324 kHz, 756 mV, 113 mW, 150 Cx 1516 kHz, 828 mV, 154 mW, 148 Cx 1612 kHz, 884 mV, 194 mW, 155 Cx 1708 kHz, 884 mV, 203 mW, 152 Cx 1804 kHz, 884 mV, 219 mW, 155 Cx Your dynamic-power-coefficient for cpu 0: 142 825 kHz, 596 mV, 148 mW, 530 Cx 979 kHz, 628 mV, 189 mW, 475 Cx 1113 kHz, 656 mV, 230 mW, 461 Cx 1267 kHz, 688 mV, 287 mW, 466 Cx 1555 kHz, 812 mV, 469 mW, 445 Cx 1708 kHz, 828 mV, 567 mW, 480 Cx 1843 kHz, 884 mV, 699 mW, 482 Cx 1900 kHz, 884 mV, 719 mW, 480 Cx 1996 kHz, 916 mV, 814 mW, 484 Cx 2112 kHz, 916 mV, 861 mW, 483 Cx 2208 kHz, 916 mV, 963 mW, 522 Cx 2323 kHz, 940 mV, 1063 mW, 520 Cx 2400 kHz, 956 mV, 1135 mW, 519 Cx Your dynamic-power-coefficient for cpu 6: 489 As you can see, the calculations aren't perfectly consistent but roughly you could say about 480 for big and 137 for little. The ratio between these numbers isn't quite the same as the ratio between the two numbers that Qualcomm used. Perhaps this is because Qualcomm measured something slightly different than the 64-bit version of dhrystone 2.2 or perhaps it's because they fudged these numbers a bit (and fudged the capacity-dmips-mhz). As per discussion [2], let's use the numbers I came up with and also un-fudge capacity-dmips-mhz. While unfudging capacity-dmips-mhz, let's scale it so that bigs are 1024 which seems to be the common practice. In general these numbers don't need to be perfectly exact. In fact, they can't be since the CPU power depends a lot on what's being run on the CPU and the big/little CPUs are each more or less efficient in different operations. Historically running the 32-bit vs. 64-bit versions of dhrystone produced notably different numbers, though I didn't test this time. We also need to scale all of the sustainable-power numbers by the same amount. I scale ones related to the big CPUs by the adjustment I made to the big dynamic-power-coefficient and the ones related to the little CPUs by the adjustment I made to the little dynamic-power-coefficient. [2] https://lore.kernel.org/r/0a865b6e-be34-6371-f9f2-9913ee1c5608@codeaurora.org/ Fixes: 71f873169a80 ("arm64: dts: qcom: sc7180: Add dynamic CPU power coefficients") Signed-off-by: Douglas Anderson Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210902145127.v2.1.I049b30065f3c715234b6303f55d72c059c8625eb@changeid Signed-off-by: Sasha Levin commit 39413a92656f5a1b2d551a7a5a9b0d2901c86551 Author: Peter Rosin Date: Mon Sep 20 22:37:38 2021 +0200 ARM: dts: at91: tse850: the emac<->phy interface is rmii [ Upstream commit dcdbc335a91a26e022a803e1a6b837266989c032 ] This went unnoticed until commit 7897b071ac3b ("net: macb: convert to phylink") which tickled the problem. The sama5d3 emac has never been capable of rgmii, and it all just happened to work before that commit. Fixes: 21dd0ece34c2 ("ARM: dts: at91: add devicetree for the Axentia TSE-850") Signed-off-by: Peter Rosin Signed-off-by: Nicolas Ferre Link: https://lore.kernel.org/r/ea781f5e-422f-6cbf-3cf4-d5a7bac9392d@axentia.se Signed-off-by: Sasha Levin commit 87b20cedac641eb82e80852cada7d1e984b4266a Author: Tony Lindgren Date: Tue Sep 21 12:42:25 2021 +0300 bus: ti-sysc: Fix timekeeping_suspended warning on resume [ Upstream commit b3e9431854e8f305385d5de225441c0477b936cb ] On resume we can get a warning at kernel/time/timekeeping.c:824 for timekeeping_suspended. Let's fix this by adding separate functions for sysc_poll_reset_sysstatus() and sysc_poll_reset_sysconfig() and have the new functions handle also timekeeping_suspended. If iopoll at some point supports timekeeping_suspended, we can just drop the custom handling from these functions. Fixes: d46f9fbec719 ("bus: ti-sysc: Use optional clocks on for enable and wait for softreset bit") Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit b8f0891620801cf4acd9628837447907cf4b868f Author: Anand Moon Date: Sun Sep 19 20:29:11 2021 +0000 arm64: dts: meson-sm1: Fix the pwm regulator supply properties [ Upstream commit 0b26fa8a02c2834f1fa8a206a285b9f84c4ad764 ] After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi") Fixes: 700ab8d83927 ("arm64: dts: khadas-vim3: add support for the SM1 based VIM3L") Fixes: 3d9e76483049 ("arm64: dts: meson-sm1-sei610: enable DVFS") Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts") Cc: Neil Armstrong Signed-off-by: Anand Moon Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210919202918.3556-4-linux.amoon@gmail.com Signed-off-by: Sasha Levin commit ec2a1df6cb102b23c4eda190da88d32e6063611e Author: Anand Moon Date: Sun Sep 19 20:29:10 2021 +0000 arm64: dts: meson-g12b: Fix the pwm regulator supply properties [ Upstream commit 62183863f708c2464769e0d477c8ce9f3d326feb ] After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs. Changes help link VDDCP_A and VDDCPU_B pwm regulator to 12V regulator supply instead of dummy regulator. [ 4.147196] VDDCPU_A: will resolve supply early: pwm [ 4.147216] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply from device tree [ 4.147227] pwm-regulator regulator-vddcpu-a: Looking up pwm-supply property in node /regulator-vddcpu-a failed [ 4.147258] VDDCPU_A: supplied by regulator-dummy [ 4.147288] regulator-dummy: could not add device link regulator.12: -ENOENT [ 4.147353] VDDCPU_A: 721 <--> 1022 mV at 871 mV, enabled [ 4.152014] VDDCPU_B: will resolve supply early: pwm [ 4.152035] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply from device tree [ 4.152047] pwm-regulator regulator-vddcpu-b: Looking up pwm-supply property in node /regulator-vddcpu-b failed [ 4.152079] VDDCPU_B: supplied by regulator-dummy [ 4.152108] regulator-dummy: could not add device link regulator.13: -ENOENT Fixes: c6d29c66e582 ("arm64: dts: meson-g12b-khadas-vim3: add initial device-tree") Fixes: d14734a04a8a ("arm64: dts: meson-g12b-odroid-n2: enable DVFS") Fixes: 3cb74db9b256 ("arm64: dts: meson: convert ugoos-am6 to common w400 dtsi") Cc: Neil Armstrong Signed-off-by: Anand Moon Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210919202918.3556-3-linux.amoon@gmail.com Signed-off-by: Sasha Levin commit fe4b9c0806c139ff45d62eb01c32f57fbeef18dc Author: Anand Moon Date: Sun Sep 19 20:29:09 2021 +0000 arm64: dts: meson-g12a: Fix the pwm regulator supply properties [ Upstream commit 085675117ecf5e02c4220698fd549024ec64ad2c ] After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs. Changes help link VDDCPU pwm regulator to 12V regulator supply instead of dummy regulator. [ 11.602281] pwm-regulator regulator-vddcpu: Looking up pwm-supply property in node /regulator-vddcpu failed [ 11.602344] VDDCPU: supplied by regulator-dummy [ 11.602365] regulator-dummy: could not add device link regulator.11: -ENOENT [ 11.602548] VDDCPU: 721 <--> 1022 mV at 1022 mV, enabled Fixes: e9bc0765cc12 ("arm64: dts: meson-g12a: enable DVFS on G12A boards") Cc: Neil Armstrong Signed-off-by: Anand Moon Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/20210919202918.3556-2-linux.amoon@gmail.com Signed-off-by: Sasha Levin commit b6a3e5310a239f9844ace1e1deffb68d3ca1d26b Author: Kishon Vijay Abraham I Date: Wed Sep 15 11:23:56 2021 +0530 arm64: dts: ti: j7200-main: Fix "bus-range" upto 256 bus number for PCIe [ Upstream commit 8bb8429290c0043a78804ae48294b53f781ee426 ] commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added PCIe bus numbers from 0 to 15 (copy-paste from J721E node). Enable all the supported bus numbers from 0 to 255 defined in PCIe spec here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Aswath Govindraju Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210915055358.19997-5-kishon@ti.com Signed-off-by: Sasha Levin commit 82b4981ce328d4e8ecc403b1e5c2dc009a79e504 Author: Kishon Vijay Abraham I Date: Wed Sep 15 11:23:55 2021 +0530 arm64: dts: ti: j7200-main: Fix "vendor-id"/"device-id" properties of pcie node [ Upstream commit 0d553792726a61ced760422e74ea67552ac69cdb ] commit 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") incorrectly added "vendor-id" and "device-id" as 16-bit properties though both of them are 32-bit properties. Fix it here. Fixes: 3276d9f53cf6 ("arm64: dts: ti: k3-j7200-main: Add PCIe device tree node") Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Aswath Govindraju Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210915055358.19997-4-kishon@ti.com Signed-off-by: Sasha Levin commit 4cfacb5443c76d2443966213f6a3c3eb6ffe875c Author: Kishon Vijay Abraham I Date: Wed Sep 15 11:23:54 2021 +0530 arm64: dts: ti: k3-j721e-main: Fix "bus-range" upto 256 bus number for PCIe [ Upstream commit 5f46633565b1c1e1840a927676065d72b442dac4 ] commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") restricted PCIe bus numbers from 0 to 15 (due to SMMU restriction in J721E). However since SMMU is not enabled, allow the full supported bus numbers from 0 to 255. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Aswath Govindraju Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210915055358.19997-3-kishon@ti.com Signed-off-by: Sasha Levin commit 01d704aa590e9e4e975a3724b06ba5b39ce0c216 Author: Kishon Vijay Abraham I Date: Wed Sep 15 11:23:53 2021 +0530 arm64: dts: ti: k3-j721e-main: Fix "max-virtual-functions" in PCIe EP nodes [ Upstream commit 9af3ef954975c383eeb667aee207d9ce6fbef8c4 ] commit 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") added "max-virtual-functions" to have 16 bit values. Fix "max-virtual-functions" in PCIe endpoint (EP) nodes to have 8 bit values instead of 16. Fixes: 4e5833884f66 ("arm64: dts: ti: k3-j721e-main: Add PCIe device tree nodes") Signed-off-by: Kishon Vijay Abraham I Reviewed-by: Aswath Govindraju Signed-off-by: Nishanth Menon Link: https://lore.kernel.org/r/20210915055358.19997-2-kishon@ti.com Signed-off-by: Sasha Levin commit 0bc01ceba81677f2b6cf8c8ffddd2ad7f808e416 Author: Selvin Xavier Date: Wed Sep 15 05:32:38 2021 -0700 RDMA/bnxt_re: Fix query SRQ failure [ Upstream commit 598d16fa1bf93431ad35bbab3ed1affe4fb7b562 ] Fill the missing parameters for the FW command while querying SRQ. Fixes: 37cb11acf1f7 ("RDMA/bnxt_re: Add SRQ support for Broadcom adapters") Link: https://lore.kernel.org/r/1631709163-2287-8-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9c177b1c70eb19ce17cc3b36fd4a45b7c997e145 Author: Marijn Suijten Date: Mon Aug 30 19:57:39 2021 +0200 ARM: dts: qcom: msm8974: Add xo_board reference clock to DSI0 PHY [ Upstream commit 8ccecf6c710b8c048eecc65709640642e5357d6e ] According to YAML validation, and for a future patchset putting this xo_board reference clock to use as VCO reference parent, add the missing clock to dsi_phy0. Fixes: 5a9fc531f6ec ("ARM: dts: msm8974: add display support") Signed-off-by: Marijn Suijten Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20210830175739.143401-1-marijn.suijten@somainline.org Signed-off-by: Sasha Levin commit 9e2601ac84b47e280800bc5065866366d4a116ec Author: Alex Bee Date: Wed Jun 23 13:59:26 2021 +0200 arm64: dts: rockchip: Fix GPU register width for RK3328 [ Upstream commit 932b4610f55b49f3a158b0db451137bab7ed0e1f ] As can be seen in RK3328's TRM the register range for the GPU is 0xff300000 to 0xff330000. It would (and does in vendor kernel) overlap with the registers of the HEVC encoder (node/driver do not exist yet in upstream kernel). See already existing h265e_mmu node. Fixes: 752fbc0c8da7 ("arm64: dts: rockchip: add rk3328 mali gpu node") Signed-off-by: Alex Bee Link: https://lore.kernel.org/r/20210623115926.164861-1-knaerzche@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 1d292cf27d8995e36e2142d2d1561a5314199291 Author: Peter Geis Date: Wed Jul 28 14:00:27 2021 -0400 arm64: dts: rockchip: fix rk3568 mbi-alias [ Upstream commit b6c1a590148c63f822091912b4c09c79fbb13971 ] The mbi-alias incorrectly points to 0xfd100000 when it should point to 0xfd410000. This fixes MSIs on rk3568. Fixes: a3adc0b9071d ("arm64: dts: rockchip: add core dtsi for RK3568 SoC") Signed-off-by: Peter Geis Link: https://lore.kernel.org/r/20210728180034.717953-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 18d83fc611a8eb4a5ef157108cb0fd06a4d21678 Author: Jackie Liu Date: Wed Sep 1 20:35:57 2021 +0800 ARM: s3c: irq-s3c24xx: Fix return value check for s3c24xx_init_intc() [ Upstream commit 2aa717473ce96c93ae43a5dc8c23cedc8ce7dd9f ] The s3c24xx_init_intc() returns an error pointer upon failure, not NULL. let's add an error pointer check in s3c24xx_handle_irq. s3c_intc[0] is not NULL or ERR, we can simplify the code. Fixes: 1f629b7a3ced ("ARM: S3C24XX: transform irq handling into a declarative form") Signed-off-by: Jackie Liu Link: https://lore.kernel.org/r/20210901123557.1043953-1-liu.yun@linux.dev Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 295bdd05ba50e3497ca5a49b039610872b4cd165 Author: Ajish Koshy Date: Mon Sep 6 22:34:02 2021 +0530 scsi: pm80xx: Fix lockup in outbound queue management [ Upstream commit b27a40534ef76a22628a5c12f98ea489823a8ba5 ] Commit 1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue processing") introduced a lock per outbound queue. Prior to that change the driver was using a global lock for all outbound queues. While processing the I/O responses and events the driver takes the outbound queue spinlock and is supposed to release it in pm8001_ccb_task_free_done() before calling command done(). Since the older code was using a global lock, pm8001_ccb_task_free_done() was releasing the global spin lock. The change that split the lock per outbound queue did not consider this and pm8001_ccb_task_free_done() was still releasing the global lock. Link: https://lore.kernel.org/r/20210906170404.5682-3-Ajish.Koshy@microchip.com Fixes: 1f02beff224e ("scsi: pm80xx: Remove global lock from outbound queue processing") Acked-by: Jack Wang Signed-off-by: Ajish Koshy Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b74b57b738bac63bcab38dac1bda707ee3dea8fb Author: Christophe JAILLET Date: Fri Apr 23 09:02:26 2021 +0200 clk: mvebu: ap-cpu-clk: Fix a memory leak in error handling paths [ Upstream commit af9617b419f77cf0b99702a7b2b0519da0d27715 ] If we exit the for_each_of_cpu_node loop early, the reference on the current node must be decremented, otherwise there is a leak. Fixes: f756e362d938 ("clk: mvebu: add CPU clock driver for Armada 7K/8K") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/545df946044fc1fc05a4217cdf0054be7a79e49e.1619161112.git.christophe.jaillet@wanadoo.fr Reviewed-by: Dan Carpenter Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 465c4e9b718dce5c3e5f336c3ef59e261aeb8b31 Author: Rafał Miłecki Date: Thu Aug 19 17:37:02 2021 +0200 arm64: dts: broadcom: bcm4908: Fix UART clock name [ Upstream commit 6c38c39ab2141f53786d73e706675e8819a3f2cb ] According to the binding the correct clock name is "refclk". Fixes: 2961f69f151c ("arm64: dts: broadcom: add BCM4908 and Asus GT-AC5300 early DTS files") Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 042ee2a50f892e25f9c616006d1605dcc424a6e5 Author: Rafał Miłecki Date: Thu Aug 19 08:57:02 2021 +0200 ARM: dts: BCM5301X: Fix memory nodes names [ Upstream commit c5e1df3276d7a500678da9453be31a66ad115150 ] Thix fixes: arch/arm/boot/dts/bcm4708-netgear-r6250.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-asus-rt-ac87u.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-buffalo-wxr-1900dhp.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 402653184]]} arch/arm/boot/dts/bcm4709-linksys-ea9200.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-netgear-r7000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-netgear-r8000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 134217728]]} arch/arm/boot/dts/bcm4709-tplink-archer-c9-v1.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} arch/arm/boot/dts/bcm47094-luxul-xwc-2000.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728], [2281701376, 402653184]]} arch/arm/boot/dts/bcm53016-meraki-mr32.dt.yaml: /: memory: False schema does not allow {'reg': [[0, 134217728]], 'device_type': ['memory']} arch/arm/boot/dts/bcm94708.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} arch/arm/boot/dts/bcm94709.dt.yaml: /: memory: False schema does not allow {'device_type': ['memory'], 'reg': [[0, 134217728]]} Signed-off-by: Rafał Miłecki Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit ce412216fbfc28321630e64fa370f1d8c8b53c96 Author: Junji Wei Date: Tue Aug 31 16:32:23 2021 +0800 RDMA/rxe: Fix wrong port_cap_flags [ Upstream commit dcd3f985b20ffcc375f82ca0ca9f241c7025eb5e ] The port->attr.port_cap_flags should be set to enum ib_port_capability_mask_bits in ib_mad.h, not RDMA_CORE_CAP_PROT_ROCE_UDP_ENCAP. Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20210831083223.65797-1-weijunji@bytedance.com Signed-off-by: Junji Wei Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 2427a4c9e4e7bf19bdfc813f261715ef07477f0e Author: Alexandru Ardelean Date: Mon Aug 23 14:22:00 2021 +0300 iio: st_sensors: disable regulators after device unregistration [ Upstream commit 9f0b3e0cc0c88618aa9e5cecef747b1337ae0a5d ] Up until commit ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") only the ST pressure driver seems to have had any regulator disable. After that commit, the regulator handling was moved into the common st_sensors logic. In all instances of this regulator handling, the regulators were disabled before unregistering the IIO device. This can cause issues where the device would be powered down and still be available to userspace, allowing it to send invalid/garbage data. This change moves the st_sensors_power_disable() after the common probe functions. These common probe functions also handle unregistering the IIO device. Fixes: 774487611c949 ("iio: pressure-core: st: Provide support for the Vdd power supply") Fixes: ea7e586bdd331 ("iio: st_sensors: move regulator retrieveal to core") Cc: Lee Jones Cc: Denis CIOCCA Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210823112204.243255-2-aardelean@deviqon.com Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a61cb0ecc9138ea4621f9f5d85162a83ec810c56 Author: Dongjin Kim Date: Thu Aug 26 12:28:32 2021 +0900 arm64: dts: meson: sm1: add Ethernet PHY reset line for ODROID-C4/HC4 [ Upstream commit 9d02214f8332d5dbbcce3d6c5c915e54d43a0c46 ] This patch is to fix an issue that the ethernet link doesn't come up when using ip link set down/up: [ 11.428114] meson8b-dwmac ff3f0000.ethernet eth0: Link is Down [ 14.428595] meson8b-dwmac ff3f0000.ethernet eth0: PHY [0.0:00] driver [RTL8211F Gigabit Ethernet] (irq=31) [ 14.428610] meson8b-dwmac ff3f0000.ethernet: Failed to reset the dma [ 14.428974] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_hw_setup: DMA engine initialization failed [ 14.711185] meson8b-dwmac ff3f0000.ethernet eth0: stmmac_open: Hw setup failed This fix refers to two commits applied for ODROID-N2 (G12B). commit 658e4129bb81 ("arm64: dts: meson: g12b: odroid-n2: add the Ethernet PHY reset line") commit 1c7412530d5d0 ("arm64: dts: meson: g12b: odroid-n2: fix PHY deassert timing requirements") Fixes: 88d537bc92ca ("arm64: dts: meson: convert meson-sm1-odroid-c4 to dtsi") Signed-off-by: Dongjin Kim Reviewed-by: Martin Blumenstingl [narmstrong: added fixes tag and typo in commit log] Signed-off-by: Neil Armstrong Link: https://lore.kernel.org/r/YScKYFWlYymgGw3l@anyang-linuxfactory-or-kr Signed-off-by: Sasha Levin commit 3260de8b35af56f86de72df6b7a11b39c0e3f381 Author: Frank Rowand Date: Thu Oct 28 20:32:25 2021 -0500 of: unittest: fix EXPECT text for gpio hog errors [ Upstream commit e85860e5bc077865a04f0a88d0b0335d3200484a ] The console message text for gpio hog errors does not match what unittest expects. Fixes: f4056e705b2ef ("of: unittest: add overlay gpio test to catch gpio hog problem") Signed-off-by: Frank Rowand Link: https://lore.kernel.org/r/20211029013225.2048695-1-frowand.list@gmail.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 8426a23213dc6519282372eba0cc1b3099b1b03d Author: Alexei Starovoitov Date: Mon Nov 1 15:21:52 2021 -0700 bpf: Fix propagation of signed bounds from 64-bit min/max into 32-bit. [ Upstream commit 388e2c0b978339dee9b0a81a2e546f8979e021e2 ] Similar to unsigned bounds propagation fix signed bounds. The 'Fixes' tag is a hint. There is no security bug here. The verifier was too conservative. Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20211101222153.78759-2-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 32df0ac1c97b4d025c1212337f26e364074bf00d Author: Alexei Starovoitov Date: Mon Nov 1 15:21:51 2021 -0700 bpf: Fix propagation of bounds from 64-bit min/max into 32-bit and var_off. [ Upstream commit b9979db8340154526d9ab38a1883d6f6ba9b6d47 ] Before this fix: 166: (b5) if r2 <= 0x1 goto pc+22 from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0xffffffff)) After this fix: 166: (b5) if r2 <= 0x1 goto pc+22 from 166 to 189: R2=invP(id=1,umax_value=1,var_off=(0x0; 0x1)) While processing BPF_JLE the reg_set_min_max() would set true_reg->umax_value = 1 and call __reg_combine_64_into_32(true_reg). Without the fix it would not pass the condition: if (__reg64_bound_u32(reg->umin_value) && __reg64_bound_u32(reg->umax_value)) since umin_value == 0 at this point. Before commit 10bf4e83167c the umin was incorrectly ingored. The commit 10bf4e83167c fixed the correctness issue, but pessimized propagation of 64-bit min max into 32-bit min max and corresponding var_off. Fixes: 10bf4e83167c ("bpf: Fix propagation of 32 bit unsigned bounds from 64 bit bounds") Signed-off-by: Alexei Starovoitov Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20211101222153.78759-1-alexei.starovoitov@gmail.com Signed-off-by: Sasha Levin commit 4c4491e856a0eba4e8f889a17a20d57c80f7a219 Author: Dan Schatzberg Date: Thu Oct 28 15:15:27 2021 -0700 cgroup: Fix rootcg cpu.stat guest double counting [ Upstream commit 81c49d39aea8a10e6d05d3aa1cb65ceb721e19b0 ] In account_guest_time in kernel/sched/cputime.c guest time is attributed to both CPUTIME_NICE and CPUTIME_USER in addition to CPUTIME_GUEST_NICE and CPUTIME_GUEST respectively. Therefore, adding both to calculate usage results in double counting any guest time at the rootcg. Fixes: 936f2a70f207 ("cgroup: add cpu.stat file to root cgroup") Signed-off-by: Dan Schatzberg Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 2e510c2625230d9502c69dd771dc58397f6ba7cd Author: Liu Jian Date: Fri Oct 29 22:12:14 2021 +0800 skmsg: Lose offset info in sk_psock_skb_ingress [ Upstream commit 7303524e04af49a47991e19f895c3b8cdc3796c7 ] If sockmap enable strparser, there are lose offset info in sk_psock_skb_ingress(). If the length determined by parse_msg function is not skb->len, the skb will be converted to sk_msg multiple times, and userspace app will get the data multiple times. Fix this by get the offset and length from strp_msg. And as Cong suggested, add one bit in skb->_sk_redir to distinguish enable or disable strparser. Fixes: 604326b41a6fb ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Liu Jian Signed-off-by: Daniel Borkmann Reviewed-by: Cong Wang Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20211029141216.211899-1-liujian56@huawei.com Signed-off-by: Sasha Levin commit 8777d613b23fc9e80c7e26dcf9dbfd51d8aae0fe Author: Sukadev Bhattiprolu Date: Fri Oct 29 15:03:16 2021 -0700 ibmvnic: delay complete() [ Upstream commit 6b278c0cb378079f3c0c61ae4a369c09ff1a4188 ] If we get CRQ_INIT, we set errno to -EIO and first call complete() to notify the waiter. Then we try to schedule a FAILOVER reset. If this occurs while adapter is in PROBING state, ibmvnic_reset() changes the error code to EAGAIN and returns without scheduling the FAILOVER. The purpose of setting error code to EAGAIN is to ask the waiter to retry. But due to the earlier complete() call, the waiter may already have seen the -EIO response and decided not to retry. This can cause intermittent failures when bringing up ibmvnic adapters during boot, specially in in kexec/kdump kernels. Defer the complete() call until after scheduling the reset. Also streamline the error code to EAGAIN. Don't see why we need EIO sometimes. All 3 callers of ibmvnic_reset_init() can handle EAGAIN. Fixes: 17c8705838a5 ("ibmvnic: Return error code if init interrupted by transport event") Reported-by: Vaishnavi Bhat Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 93d1d1bd0d58bd7c2ee62bdb55a806b9cee938be Author: Sukadev Bhattiprolu Date: Fri Oct 29 15:03:15 2021 -0700 ibmvnic: Process crqs after enabling interrupts [ Upstream commit 6e20d00158f31f7631d68b86996b7e951c4451c8 ] Soon after registering a CRQ it is possible that we get a fail over or maybe a CRQ_INIT from the VIOS while interrupts were disabled. Look for any such CRQs after enabling interrupts. Otherwise we can intermittently fail to bring up ibmvnic adapters during boot, specially in kexec/kdump kernels. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Reported-by: Vaishnavi Bhat Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 611e758769074cbb59cb6717ddd963c4cbc2de5d Author: Sukadev Bhattiprolu Date: Fri Oct 29 15:03:14 2021 -0700 ibmvnic: don't stop queue in xmit [ Upstream commit 8878e46fcfd46b19964bd90e13b25dd94cbfc9be ] If adapter's resetting bit is on, discard the packet but don't stop the transmit queue - instead leave that to the reset code. With this change, it is possible that we may get several calls to ibmvnic_xmit() that simply discard packets and return. But if we stop the queue here, we might end up doing so just after __ibmvnic_open() started the queues (during a hard/soft reset) and before the ->resetting bit was cleared. If that happens, there will be no one to restart queue and transmissions will be blocked indefinitely. This can cause a TIMEOUT reset and with auto priority failover enabled, an unnecessary FAILOVER reset to less favored backing device and then a FAILOVER back to the most favored backing device. If we hit the window repeatedly, we can get stuck in a loop of TIMEOUT, FAILOVER, FAILOVER resets leaving the adapter unusable for extended periods of time. Fixes: 7f5b030830fe ("ibmvnic: Free skb's in cases of failure in transmit") Reported-by: Abdul Haleem Reported-by: Vaishnavi Bhat Signed-off-by: Sukadev Bhattiprolu Reviewed-by: Dany Madden Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b7bf97fc562156edb774e31bf2906bfdc83b2717 Author: Jakub Kicinski Date: Fri Oct 29 08:51:34 2021 -0700 udp6: allow SO_MARK ctrl msg to affect routing [ Upstream commit 42dcfd850e514b229d616a53dec06d0f2533217c ] Commit c6af0c227a22 ("ip: support SO_MARK cmsg") added propagation of SO_MARK from cmsg to skb->mark. For IPv4 and raw sockets the mark also affects route lookup, but in case of IPv6 the flow info is initialized before cmsg is parsed. Fixes: c6af0c227a22 ("ip: support SO_MARK cmsg") Reported-and-tested-by: Xintong Hu Signed-off-by: Jakub Kicinski Reviewed-by: David Ahern Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e39668a15aa25a27aa81e2f0d6304f0085eeec3f Author: Andrea Righi Date: Tue Oct 26 16:34:09 2021 +0200 selftests/bpf: Fix fclose/pclose mismatch in test_progs [ Upstream commit f48ad69097fe79d1de13c4d8fef556d4c11c5e68 ] Make sure to use pclose() to properly close the pipe opened by popen(). Fixes: 81f77fd0deeb ("bpf: add selftest for stackmap with BPF_F_STACK_BUILD_ID") Signed-off-by: Andrea Righi Signed-off-by: Daniel Borkmann Reviewed-by: Shuah Khan Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20211026143409.42666-1-andrea.righi@canonical.com Signed-off-by: Sasha Levin commit 8cf265bafd334d943db50b32d2170df73343d26c Author: Daniel Jordan Date: Thu Oct 21 14:30:28 2021 -0400 crypto: pcrypt - Delay write to padata->info [ Upstream commit 68b6dea802cea0dbdd8bd7ccc60716b5a32a5d8a ] These three events can race when pcrypt is used multiple times in a template ("pcrypt(pcrypt(...))"): 1. [taskA] The caller makes the crypto request via crypto_aead_encrypt() 2. [kworkerB] padata serializes the inner pcrypt request 3. [kworkerC] padata serializes the outer pcrypt request 3 might finish before the call to crypto_aead_encrypt() returns in 1, resulting in two possible issues. First, a use-after-free of the crypto request's memory when, for example, taskA writes to the outer pcrypt request's padata->info in pcrypt_aead_enc() after kworkerC completes the request. Second, the outer pcrypt request overwrites the inner pcrypt request's return code with -EINPROGRESS, making a successful request appear to fail. For instance, kworkerB writes the outer pcrypt request's padata->info in pcrypt_aead_done() and then taskA overwrites it in pcrypt_aead_enc(). Avoid both situations by delaying the write of padata->info until after the inner crypto request's return code is checked. This prevents the use-after-free by not touching the crypto request's memory after the next-inner crypto request is made, and stops padata->info from being overwritten. Fixes: 5068c7a883d16 ("crypto: pcrypt - Add pcrypt crypto parallelization wrapper") Reported-by: syzbot+b187b77c8474f9648fae@syzkaller.appspotmail.com Signed-off-by: Daniel Jordan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 1d070939821304cf47070f9d53e9288084b0b0a8 Author: Nikolay Aleksandrov Date: Fri Oct 29 15:05:27 2021 +0300 selftests: net: bridge: update IGMP/MLD membership interval value [ Upstream commit 34d7ecb3d4f772eb00ce1f7195ae30886ddf4d2e ] When I fixed IGMPv3/MLDv2 to use the bridge's multicast_membership_interval value which is chosen by user-space instead of calculating it based on multicast_query_interval and multicast_query_response_interval I forgot to update the selftests relying on that behaviour. Now we have to manually set the expected GMI value to perform the tests correctly and get proper results (similar to IGMPv2 behaviour). Fixes: fac3cb82a54a ("net: bridge: mcast: use multicast_membership_interval for IGMPv3") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit fe5bffbf621440412aeb9e8d34d8d6881f72cd84 Author: Ivan Vecera Date: Thu Oct 28 17:58:35 2021 +0200 net: bridge: fix uninitialized variables when BRIDGE_CFM is disabled [ Upstream commit 829e050eea69c7442441b714b6f5b339b5b8c367 ] Function br_get_link_af_size_filtered() calls br_cfm_{,peer}_mep_count() that return a count. When BRIDGE_CFM is not enabled these functions simply return -EOPNOTSUPP but do not modify count parameter and calling function then works with uninitialized variables. Modify these inline functions to return zero in count parameter. Fixes: b6d0425b816e ("bridge: cfm: Netlink Notifications.") Cc: Henrik Bjoernlund Signed-off-by: Ivan Vecera Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d4fe67943ae4642b1fcec209a549ea4a74a75aa7 Author: Russell King (Oracle) Date: Thu Oct 28 15:55:34 2021 +0100 net: phylink: avoid mvneta warning when setting pause parameters [ Upstream commit fd8d9731bcdfb22d28e45bce789bcb211c868c78 ] mvneta does not support asymetric pause modes, and it flags this by the lack of AsymPause in the supported field. When setting pause modes, we check that pause->rx_pause == pause->tx_pause, but only when pause autoneg is enabled. When pause autoneg is disabled, we still allow pause->rx_pause != pause->tx_pause, which is incorrect when the MAC does not support asymetric pause, and causes mvneta to issue a warning. Fix this by removing the test for pause->autoneg, so we always check that pause->rx_pause == pause->tx_pause for network devices that do not support AsymPause. Fixes: 9525ae83959b ("phylink: add phylink infrastructure") Signed-off-by: Russell King (Oracle) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 148557b62d51a3f73f1198b4a10369762ca38e0f Author: Christophe JAILLET Date: Tue Sep 7 23:06:32 2021 +0200 ipmi: kcs_bmc: Fix a memory leak in the error handling path of 'kcs_bmc_serio_add_device()' [ Upstream commit f281d010b87454e72475b668ad66e34961f744e0 ] In the unlikely event where 'devm_kzalloc()' fails and 'kzalloc()' succeeds, 'port' would be leaking. Test each allocation separately to avoid the leak. Fixes: 3a3d2f6a4c64 ("ipmi: kcs_bmc: Add serio adaptor") Signed-off-by: Christophe JAILLET Message-Id: Reviewed-by: Andrew Jeffery Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 5139ace7231d800a34f4bf5993e8fb66ec80a7cb Author: Shyam Sundar S K Date: Wed Oct 27 15:27:27 2021 +0530 net: amd-xgbe: Toggle PLL settings during rate change [ Upstream commit daf182d360e509a494db18666799f4e85d83dda0 ] For each rate change command submission, the FW has to do a phy power off sequence internally. For this to happen correctly, the PLL re-initialization control setting has to be turned off before sending mailbox commands and re-enabled once the command submission is complete. Without the PLL control setting, the link up takes longer time in a fixed phy configuration. Fixes: 47f164deab22 ("amd-xgbe: Add PCI device support") Co-developed-by: Sudheesh Mavila Signed-off-by: Sudheesh Mavila Signed-off-by: Shyam Sundar S K Acked-by: Tom Lendacky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c329460af68ea733926a7cde460ea74ae8fd5c77 Author: Xin Long Date: Thu Oct 28 05:36:04 2021 -0400 sctp: return true only for pathmtu update in sctp_transport_pl_toobig [ Upstream commit 75cf662c64dd8543f56c329c69eba18141c8fd9f ] sctp_transport_pl_toobig() supposes to return true only if there's pathmtu update, so that in sctp_icmp_frag_needed() it would call sctp_assoc_sync_pmtu() and sctp_retransmit(). This patch is to fix these return places in sctp_transport_pl_toobig(). Fixes: 836964083177 ("sctp: do state transition when receiving an icmp TOOBIG packet") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8880eccbc789e2f59e954197693567fe7a640b33 Author: Xin Long Date: Thu Oct 28 05:36:03 2021 -0400 sctp: subtract sctphdr len in sctp_transport_pl_hlen [ Upstream commit cc4665ca646c96181a7c00198aa72c59e0c576e8 ] sctp_transport_pl_hlen() is called to calculate the outer header length for PL. However, as the Figure in rfc8899#section-4.4: Any additional headers .--- MPS -----. | | | v v v +------------------------------+ | IP | ** | PL | protocol data | +------------------------------+ <----- PLPMTU -----> <---------- PMTU --------------> Outer header are IP + Any additional headers, which doesn't include Packetization Layer itself header, namely sctphdr, whereas sctphdr is counted by __sctp_mtu_payload(). The incorrect calculation caused the link pathmtu to be set larger than expected by t->pl.pmtu + sctp_transport_pl_hlen(). This patch is to fix it by subtracting sctphdr len in sctp_transport_pl_hlen(). Fixes: d9e2e410ae30 ("sctp: add the constants/variables and states and some APIs for transport") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 777591117cd90d64dcffb6fa525c9075df430026 Author: Xin Long Date: Thu Oct 28 05:36:02 2021 -0400 sctp: reset probe_timer in sctp_transport_pl_update [ Upstream commit c6ea04ea692fa0d8e7faeb133fcd28e3acf470a0 ] sctp_transport_pl_update() is called when transport update its dst and pathmtu, instead of stopping the PLPMTUD probe timer, PLPMTUD should start over and reset the probe timer. Otherwise, the PLPMTUD service would stop. Fixes: 92548ec2f1f9 ("sctp: add the probe timer in transport for PLPMTUD") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 269b14dd6e1037ff5b2cf2936b8f511f5d24cb3d Author: Xin Long Date: Thu Oct 28 05:36:01 2021 -0400 sctp: allow IP fragmentation when PLPMTUD enters Error state [ Upstream commit 40171248bb8934537fec8fbaf718e57c8add187c ] Currently when PLPMTUD enters Error state, transport pathmtu will be set to MIN_PLPMTU(512) while probe is continuing with BASE_PLPMTU(1200). It will cause pathmtu to stay in a very small value, even if the real pmtu is some value like 1000. RFC8899 doesn't clearly say how to set the value in Error state. But one possibility could be keep using BASE_PLPMTU for the real pmtu, but allow to do IP fragmentation when it's in Error state. As it says in rfc8899#section-5.4: Some paths could be unable to sustain packets of the BASE_PLPMTU size. The Error State could be implemented to provide robustness to such paths. This allows fallback to a smaller than desired PLPMTU rather than suffer connectivity failure. This could utilize methods such as endpoint IP fragmentation to enable the PL sender to communicate using packets smaller than the BASE_PLPMTU. This patch is to set pmtu to BASE_PLPMTU instead of MIN_PLPMTU for Error state in sctp_transport_pl_send/toobig(), and set packet ipfragok for non-probe packets when it's in Error state. Fixes: 1dc68c194571 ("sctp: do state transition when PROBE_COUNT == MAX_PROBES on HB send path") Reported-by: Ying Xu Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af1d4c7c44a9dd80c2bb5a5e0199551d4209f5e6 Author: Kumar Kartikeya Dwivedi Date: Thu Oct 28 12:05:01 2021 +0530 selftests/bpf: Fix memory leak in test_ima [ Upstream commit efadf2ad17a2d5dc90bda4e6e8b2f96af4c62dae ] The allocated ring buffer is never freed, do so in the cleanup path. Fixes: f446b570ac7e ("bpf/selftests: Update the IMA test to use BPF ring buffer") Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20211028063501.2239335-9-memxor@gmail.com Signed-off-by: Sasha Levin commit a75f4f978babbdc3550fb28e9b20a823fdf73356 Author: Kumar Kartikeya Dwivedi Date: Thu Oct 28 12:05:00 2021 +0530 selftests/bpf: Fix fd cleanup in sk_lookup test [ Upstream commit c3fc706e94f5653def2783ffcd809a38676b7551 ] Similar to the fix in commit: e31eec77e4ab ("bpf: selftests: Fix fd cleanup in get_branch_snapshot") We use designated initializer to set fds to -1 without breaking on future changes to MAX_SERVER constant denoting the array size. The particular close(0) occurs on non-reuseport tests, so it can be seen with -n 115/{2,3} but not 115/4. This can cause problems with future tests if they depend on BTF fd never being acquired as fd 0, breaking internal libbpf assumptions. Fixes: 0ab5539f8584 ("selftests/bpf: Tests for BPF_SK_LOOKUP attach point") Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Sitnicki Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20211028063501.2239335-8-memxor@gmail.com Signed-off-by: Sasha Levin commit 317a0c71ba61643c6b33e853bc409a1fe06d25a3 Author: Alex Deucher Date: Wed Oct 27 13:26:19 2021 -0400 drm/amdgpu/gmc6: fix DMA mask from 44 to 40 bits [ Upstream commit 403475be6d8b122c3e6b8a47e075926d7299e5ef ] The DMA mask on SI parts is 40 bits not 44. Copy paste typo. Fixes: 244511f386ccb9 ("drm/amdgpu: simplify and cleanup setting the dma mask") Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1762 Acked-by: Christian König Tested-by: Paul Menzel Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 7f71a6a3bc4a35a429bbf6871f23eabfd669e485 Author: Lang Yu Date: Thu Oct 21 14:36:36 2021 +0800 drm/amdgpu: fix a potential memory leak in amdgpu_device_fini_sw() [ Upstream commit a5c5d8d50ecf5874be90a76e1557279ff8a30c9e ] amdgpu_fence_driver_sw_fini() should be executed before amdgpu_device_ip_fini(), otherwise fence driver resource won't be properly freed as adev->rings have been tore down. Fixes: 72c8c97b1522 ("drm/amdgpu: Split amdgpu_device_fini into early and late") Signed-off-by: Lang Yu Reviewed-by: Andrey Grodzovsky Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a05760ad9460cbdc5986a1b9fcfd5cd79192b53e Author: Loic Poulain Date: Mon Oct 25 17:22:08 2021 +0200 wcn36xx: Channel list update before hardware scan [ Upstream commit d707f812bb0513ea0030d0c9fe2a456bae5a4583 ] The channel scan list must be updated before triggering a hardware scan so that firmware takes into account the regulatory info for each single channel such as active/passive config, power, DFS, etc... Without this the firmware uses its own internal default channel configuration, which is not aligned with mac80211 regulatory rules, and misses several channels (e.g. 144). Fixes: 2f3bef4b247e ("wcn36xx: Add hardware scan offload support") Signed-off-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1635175328-25642-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit 00da55838d50faf1856db7bfc423a5292ac7476a Author: Eric Dumazet Date: Tue Oct 26 14:41:32 2021 -0700 bpf: Fixes possible race in update_prog_stats() for 32bit arches [ Upstream commit d979617aa84d96acca44c2f5778892b4565e322f ] It seems update_prog_stats() suffers from same issue fixed in the prior patch: As it can run while interrupts are enabled, it could be re-entered and the u64_stats syncp could be mangled. Fixes: fec56f5890d9 ("bpf: Introduce BPF trampoline") Signed-off-by: Eric Dumazet Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211026214133.3114279-3-eric.dumazet@gmail.com Signed-off-by: Sasha Levin commit 81fe843efb4cfe88e9610ae4cf5742ccda6d4482 Author: Loic Poulain Date: Mon Oct 25 10:25:36 2021 +0200 wcn36xx: Fix discarded frames due to wrong sequence number [ Upstream commit 113f304dbc1627c6ec9d5329d839964095768980 ] The firmware is offering features such as ARP offload, for which firmware crafts its own (QoS)packets without waking up the host. Point is that the sequence numbers generated by the firmware are not in sync with the host mac80211 layer and can cause packets such as firmware ARP reponses to be dropped by the AP (too old SN). To fix this we need to let the firmware manages the sequence numbers by its own (except for QoS null frames). There is a SN counter for each QoS queue and one global/baseline counter for Non-QoS. Fixes: 84aff52e4f57 ("wcn36xx: Use sequence number allocated by mac80211") Signed-off-by: Loic Poulain Tested-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1635150336-18736-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit ff3948bc3d2a418394f35e7e2a1806013f9686ad Author: Benjamin Li Date: Fri Oct 22 17:15:28 2021 -0700 wcn36xx: add proper DMA memory barriers in rx path [ Upstream commit 9bfe38e064af5decba2ffce66a2958ab8b10eaa4 ] This is essentially exactly following the dma_wmb()/dma_rmb() usage instructions in Documentation/memory-barriers.txt. The theoretical races here are: 1. DXE (the DMA Transfer Engine in the Wi-Fi subsystem) seeing the dxe->ctrl & WCN36xx_DXE_CTRL_VLD write before the dxe->dst_addr_l write, thus performing DMA into the wrong address. 2. CPU reading dxe->dst_addr_l before DXE unsets dxe->ctrl & WCN36xx_DXE_CTRL_VLD. This should generally be harmless since DXE doesn't write dxe->dst_addr_l (no risk of freeing the wrong skb). Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Benjamin Li Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211023001528.3077822-1-benl@squareup.com Signed-off-by: Sasha Levin commit 65980896b216e70106215eabb610c1d2d3dc8071 Author: Wang Hai Date: Wed Oct 20 20:03:45 2021 +0800 libertas: Fix possible memory leak in probe and disconnect [ Upstream commit 9692151e2fe7a326bafe99836fd1f20a2cc3a049 ] I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88812c7d7400 (size 512): comm "kworker/6:1", pid 176, jiffies 4295003332 (age 822.830s) hex dump (first 32 bytes): 00 68 1e 04 81 88 ff ff 01 00 00 00 00 00 00 00 .h.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] slab_post_alloc_hook+0x9c/0x490 [] kmem_cache_alloc_trace+0x1f7/0x470 [] if_usb_probe+0x63/0x446 [usb8xxx] [] usb_probe_interface+0x1aa/0x3c0 [usbcore] [] really_probe+0x190/0x480 [] __driver_probe_device+0xf9/0x180 [] driver_probe_device+0x53/0x130 [] __device_attach_driver+0x105/0x130 [] bus_for_each_drv+0x129/0x190 [] __device_attach+0x1c9/0x270 [] device_initial_probe+0x20/0x30 [] bus_probe_device+0x142/0x160 [] device_add+0x829/0x1300 [] usb_set_configuration+0xb01/0xcc0 [usbcore] [] usb_generic_driver_probe+0x6e/0x90 [usbcore] [] usb_probe_device+0x6f/0x130 [usbcore] cardp is missing being freed in the error handling path of the probe and the path of the disconnect, which will cause memory leak. This patch adds the missing kfree(). Fixes: 876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211020120345.2016045-3-wanghai38@huawei.com Signed-off-by: Sasha Levin commit e44f7a7cba460e32f280c1e11dcc1dd58b5999a9 Author: Wang Hai Date: Wed Oct 20 20:03:44 2021 +0800 libertas_tf: Fix possible memory leak in probe and disconnect [ Upstream commit d549107305b4634c81223a853701c06bcf657bc3 ] I got memory leak as follows when doing fault injection test: unreferenced object 0xffff88810a2ddc00 (size 512): comm "kworker/6:1", pid 176, jiffies 4295009893 (age 757.220s) hex dump (first 32 bytes): 00 50 05 18 81 88 ff ff 00 00 00 00 00 00 00 00 .P.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] slab_post_alloc_hook+0x9c/0x490 [] kmem_cache_alloc_trace+0x1f7/0x470 [] if_usb_probe+0x60/0x37c [libertas_tf_usb] [] usb_probe_interface+0x1aa/0x3c0 [usbcore] [] really_probe+0x190/0x480 [] __driver_probe_device+0xf9/0x180 [] driver_probe_device+0x53/0x130 [] __device_attach_driver+0x105/0x130 [] bus_for_each_drv+0x129/0x190 [] __device_attach+0x1c9/0x270 [] device_initial_probe+0x20/0x30 [] bus_probe_device+0x142/0x160 [] device_add+0x829/0x1300 [] usb_set_configuration+0xb01/0xcc0 [usbcore] [] usb_generic_driver_probe+0x6e/0x90 [usbcore] [] usb_probe_device+0x6f/0x130 [usbcore] cardp is missing being freed in the error handling path of the probe and the path of the disconnect, which will cause memory leak. This patch adds the missing kfree(). Fixes: c305a19a0d0a ("libertas_tf: usb specific functions") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211020120345.2016045-2-wanghai38@huawei.com Signed-off-by: Sasha Levin commit dd49c41472de0fee1f629c1a6af97362546b7364 Author: Janis Schoetterl-Glausch Date: Fri Oct 22 17:26:48 2021 +0200 KVM: s390: Fix handle_sske page fault handling [ Upstream commit 85f517b29418158d3e6e90c3f0fc01b306d2f1a1 ] If handle_sske cannot set the storage key, because there is no page table entry or no present large page entry, it calls fixup_user_fault. However, currently, if the call succeeds, handle_sske returns -EAGAIN, without having set the storage key. Instead, retry by continue'ing the loop without incrementing the address. The same issue in handle_pfmf was fixed by a11bdb1a6b78 ("KVM: s390: Fix pfmf and conditional skey emulation"). Fixes: bd096f644319 ("KVM: s390: Add skey emulation fault handling") Signed-off-by: Janis Schoetterl-Glausch Reviewed-by: Christian Borntraeger Reviewed-by: Claudio Imbrenda Link: https://lore.kernel.org/r/20211022152648.26536-1-scgl@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 239e87d9f6468c280c2deac2897f2a01347c808b Author: Tiezhu Yang Date: Tue Oct 26 09:51:28 2021 +0800 samples/kretprobes: Fix return value if register_kretprobe() failed [ Upstream commit f76fbbbb5061fe14824ba5807c44bd7400a6b4e1 ] Use the actual return value instead of always -1 if register_kretprobe() failed. E.g. without this patch: # insmod samples/kprobes/kretprobe_example.ko func=no_such_func insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Operation not permitted With this patch: # insmod samples/kprobes/kretprobe_example.ko func=no_such_func insmod: ERROR: could not insert module samples/kprobes/kretprobe_example.ko: Unknown symbol in module Link: https://lkml.kernel.org/r/1635213091-24387-2-git-send-email-yangtiezhu@loongson.cn Fixes: 804defea1c02 ("Kprobes: move kprobe examples to samples/") Signed-off-by: Tiezhu Yang Acked-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit e1ff40b6194f09c1dd0f45b94fdf30c0374b5823 Author: Peter Zijlstra Date: Fri Oct 22 16:53:02 2021 +0200 x86: Fix __get_wchan() for !STACKTRACE [ Upstream commit 5d1ceb3969b6b2e47e2df6d17790a7c5a20fcbb4 ] Use asm/unwind.h to implement wchan, since we cannot always rely on STACKTRACE=y. Fixes: bc9bbb81730e ("x86: Fix get_wchan() to support the ORC unwinder") Reported-by: Stephen Rothwell Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Kees Cook Link: https://lkml.kernel.org/r/20211022152104.137058575@infradead.org Signed-off-by: Sasha Levin commit e9ede14c116f1a6246eee89d320d60a90a86b5d5 Author: Kees Cook Date: Wed Sep 29 15:02:14 2021 -0700 sched: Add wrapper for get_wchan() to keep task blocked [ Upstream commit 42a20f86dc19f9282d974df0ba4d226c865ab9dd ] Having a stable wchan means the process must be blocked and for it to stay that way while performing stack unwinding. Suggested-by: Peter Zijlstra Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Acked-by: Geert Uytterhoeven Acked-by: Russell King (Oracle) [arm] Tested-by: Mark Rutland [arm64] Link: https://lkml.kernel.org/r/20211008111626.332092234@infradead.org Signed-off-by: Sasha Levin commit 38bdcbf9828f11f6ae8b55a9431b4349655f2c09 Author: Lad Prabhakar Date: Mon Oct 25 21:56:27 2021 +0100 spi: spi-rpc-if: Check return value of rpcif_sw_init() [ Upstream commit 0b0a281ed7001d4c4f4c47bdc84680c4997761ca ] rpcif_sw_init() can fail so make sure we check the return value of it and on error exit rpcif_spi_probe() callback with error code. Fixes: eb8d6d464a27 ("spi: add Renesas RPC-IF driver") Signed-off-by: Lad Prabhakar Reviewed-by: Biju Das Reviewed-by: Wolfram Sang Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20211025205631.21151-4-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e0eb459df7b25c6dc0dbca9a5c80000bf025472a Author: Zhang Rui Date: Tue Oct 26 16:32:42 2021 +0800 cpufreq: intel_pstate: Fix cpu->pstate.turbo_freq initialization [ Upstream commit c72bcf0ab87a92634e58af62e89af0f40dfd0b88 ] Fix a problem in active mode that cpu->pstate.turbo_freq is initialized only if HWP-to-frequency scaling factor is refined. In passive mode, this problem is not exposed, because cpu->pstate.turbo_freq is set again, later in intel_cpufreq_cpu_init()->intel_pstate_get_hwp_cap(). Fixes: eb3693f0521e ("cpufreq: intel_pstate: hybrid: CPU-specific scaling factor") Signed-off-by: Zhang Rui Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit ea3c5c9eabc2c4caa6bb18dd6767a37d95e2f545 Author: Jon Maxwell Date: Mon Oct 25 10:59:03 2021 +1100 tcp: don't free a FIN sk_buff in tcp_remove_empty_skb() [ Upstream commit cf12e6f9124629b18a6182deefc0315f0a73a199 ] v1: Implement a more general statement as recommended by Eric Dumazet. The sequence number will be advanced, so this check will fix the FIN case and other cases. A customer reported sockets stuck in the CLOSING state. A Vmcore revealed that the write_queue was not empty as determined by tcp_write_queue_empty() but the sk_buff containing the FIN flag had been freed and the socket was zombied in that state. Corresponding pcaps show no FIN from the Linux kernel on the wire. Some instrumentation was added to the kernel and it was found that there is a timing window where tcp_sendmsg() can run after tcp_send_fin(). tcp_sendmsg() will hit an error, for example: 1269 ▹ if (sk->sk_err || (sk->sk_shutdown & SEND_SHUTDOWN))↩ 1270 ▹ ▹ goto do_error;↩ tcp_remove_empty_skb() will then free the FIN sk_buff as "skb->len == 0". The TCP socket is now wedged in the FIN-WAIT-1 state because the FIN is never sent. If the other side sends a FIN packet the socket will transition to CLOSING and remain that way until the system is rebooted. Fix this by checking for the FIN flag in the sk_buff and don't free it if that is the case. Testing confirmed that fixed the issue. Fixes: fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases") Signed-off-by: Jon Maxwell Reported-by: Monir Zouaoui Reported-by: Simon Stier Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e6b885849667863391902ab490b0644ebd9c5aa1 Author: Ilya Leoshkevich Date: Tue Oct 26 03:08:26 2021 +0200 libbpf: Fix endianness detection in BPF_CORE_READ_BITFIELD_PROBED() [ Upstream commit 45f2bebc8079788f62f22d9e8b2819afb1789d7b ] __BYTE_ORDER is supposed to be defined by a libc, and __BYTE_ORDER__ - by a compiler. bpf_core_read.h checks __BYTE_ORDER == __LITTLE_ENDIAN, which is true if neither are defined, leading to incorrect behavior on big-endian hosts if libc headers are not included, which is often the case. Fixes: ee26dade0e3b ("libbpf: Add support for relocatable bitfields") Signed-off-by: Ilya Leoshkevich Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211026010831.748682-2-iii@linux.ibm.com Signed-off-by: Sasha Levin commit a003933e5579aad289d06fee898dbade3614f9fb Author: Mark Brown Date: Fri Sep 24 15:41:11 2021 +0100 tpm_tis_spi: Add missing SPI ID [ Upstream commit 7eba41fe8c7bb01ff3d4b757bd622375792bc720 ] In commit c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries") we added SPI IDs for all the DT aliases to handle the fact that we always use SPI modaliases to load modules even when probed via DT however the mentioned commit missed that the SPI and OF device ID entries did not match and were different and so DT nodes with compatible "tcg,tpm_tis-spi" will not match. Add an extra ID for tpm_tis-spi rather than just fix the existing one since what's currently there is going to be better for anyone actually using SPI IDs to instantiate. Fixes: c46ed2281bbe ("tpm_tis_spi: add missing SPI device ID entries") Fixes: 96c8395e2166 ("spi: Revert modalias changes") Signed-off-by: Mark Brown Reviewed-by: Jarkko Sakkinen Reviewed-by: Javier Martinez Canillas Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 8d43e218d53eb3d71ccf4aed1813aa68c78d2cd3 Author: Hao Wu Date: Wed Sep 8 02:26:06 2021 -0700 tpm: fix Atmel TPM crash caused by too frequent queries [ Upstream commit 79ca6f74dae067681a779fd573c2eb59649989bc ] The Atmel TPM 1.2 chips crash with error `tpm_try_transmit: send(): error -62` since kernel 4.14. It is observed from the kernel log after running `tpm_sealdata -z`. The error thrown from the command is as follows ``` $ tpm_sealdata -z Tspi_Key_LoadKey failed: 0x00001087 - layer=tddl, code=0087 (135), I/O error ``` The issue was reproduced with the following Atmel TPM chip: ``` $ tpm_version T0 TPM 1.2 Version Info: Chip Version: 1.2.66.1 Spec Level: 2 Errata Revision: 3 TPM Vendor ID: ATML TPM Version: 01010000 Manufacturer Info: 41544d4c ``` The root cause of the issue is due to the TPM calls to msleep() were replaced with usleep_range() [1], which reduces the actual timeout. Via experiments, it is observed that the original msleep(5) actually sleeps for 15ms. Because of a known timeout issue in Atmel TPM 1.2 chip, the shorter timeout than 15ms can cause the error described above. A few further changes in kernel 4.16 [2] and 4.18 [3, 4] further reduced the timeout to less than 1ms. With experiments, the problematic timeout in the latest kernel is the one for `wait_for_tpm_stat`. To fix it, the patch reverts the timeout of `wait_for_tpm_stat` to 15ms for all Atmel TPM 1.2 chips, but leave it untouched for Ateml TPM 2.0 chip, and chips from other vendors. As explained above, the chosen 15ms timeout is the actual timeout before this issue introduced, thus the old value is used here. Particularly, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 14700us, TPM_ATML_TIMEOUT_WAIT_STAT_MIN is set to 15000us according to the existing TPM_TIMEOUT_RANGE_US (300us). The fixed has been tested in the system with the affected Atmel chip with no issues observed after boot up. References: [1] 9f3fc7bcddcb tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers [2] cf151a9a44d5 tpm: reduce tpm polling delay in tpm_tis_core [3] 59f5a6b07f64 tpm: reduce poll sleep time in tpm_transmit() [4] 424eaf910c32 tpm: reduce polling time to usecs for even finer granularity Fixes: 9f3fc7bcddcb ("tpm: replace msleep() with usleep_range() in TPM 1.2/2.0 generic drivers") Link: https://patchwork.kernel.org/project/linux-integrity/patch/20200926223150.109645-1-hao.wu@rubrik.com/ Signed-off-by: Hao Wu Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 71e3f2ea776544de3a9826860ab6b8ae5b1fdafb Author: Yu Kuai Date: Wed Oct 20 09:40:36 2021 +0800 blk-cgroup: synchronize blkg creation against policy deactivation [ Upstream commit 0c9d338c8443b06da8e8d3bfce824c5ea6d3488f ] Our test reports a null pointer dereference: [ 168.534653] ================================================================== [ 168.535614] Disabling lock debugging due to kernel taint [ 168.536346] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 168.537274] #PF: supervisor read access in kernel mode [ 168.537964] #PF: error_code(0x0000) - not-present page [ 168.538667] PGD 0 P4D 0 [ 168.539025] Oops: 0000 [#1] PREEMPT SMP KASAN [ 168.539656] CPU: 13 PID: 759 Comm: bash Tainted: G B 5.15.0-rc2-next-202100 [ 168.540954] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_0738364 [ 168.542736] RIP: 0010:bfq_pd_init+0x88/0x1e0 [ 168.543318] Code: 98 00 00 00 e8 c9 e4 5b ff 4c 8b 65 00 49 8d 7c 24 08 e8 bb e4 5b ff 4d0 [ 168.545803] RSP: 0018:ffff88817095f9c0 EFLAGS: 00010002 [ 168.546497] RAX: 0000000000000001 RBX: ffff888101a1c000 RCX: 0000000000000000 [ 168.547438] RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff888106553428 [ 168.548402] RBP: ffff888106553400 R08: ffffffff961bcaf4 R09: 0000000000000001 [ 168.549365] R10: ffffffffa2e16c27 R11: fffffbfff45c2d84 R12: 0000000000000000 [ 168.550291] R13: ffff888101a1c098 R14: ffff88810c7a08c8 R15: ffffffffa55541a0 [ 168.551221] FS: 00007fac75227700(0000) GS:ffff88839ba80000(0000) knlGS:0000000000000000 [ 168.552278] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 168.553040] CR2: 0000000000000008 CR3: 0000000165ce7000 CR4: 00000000000006e0 [ 168.554000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 168.554929] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 168.555888] Call Trace: [ 168.556221] [ 168.556510] blkg_create+0x1c0/0x8c0 [ 168.556989] blkg_conf_prep+0x574/0x650 [ 168.557502] ? stack_trace_save+0x99/0xd0 [ 168.558033] ? blkcg_conf_open_bdev+0x1b0/0x1b0 [ 168.558629] tg_set_conf.constprop.0+0xb9/0x280 [ 168.559231] ? kasan_set_track+0x29/0x40 [ 168.559758] ? kasan_set_free_info+0x30/0x60 [ 168.560344] ? tg_set_limit+0xae0/0xae0 [ 168.560853] ? do_sys_openat2+0x33b/0x640 [ 168.561383] ? do_sys_open+0xa2/0x100 [ 168.561877] ? __x64_sys_open+0x4e/0x60 [ 168.562383] ? __kasan_check_write+0x20/0x30 [ 168.562951] ? copyin+0x48/0x70 [ 168.563390] ? _copy_from_iter+0x234/0x9e0 [ 168.563948] tg_set_conf_u64+0x17/0x20 [ 168.564467] cgroup_file_write+0x1ad/0x380 [ 168.565014] ? cgroup_file_poll+0x80/0x80 [ 168.565568] ? __mutex_lock_slowpath+0x30/0x30 [ 168.566165] ? pgd_free+0x100/0x160 [ 168.566649] kernfs_fop_write_iter+0x21d/0x340 [ 168.567246] ? cgroup_file_poll+0x80/0x80 [ 168.567796] new_sync_write+0x29f/0x3c0 [ 168.568314] ? new_sync_read+0x410/0x410 [ 168.568840] ? __handle_mm_fault+0x1c97/0x2d80 [ 168.569425] ? copy_page_range+0x2b10/0x2b10 [ 168.570007] ? _raw_read_lock_bh+0xa0/0xa0 [ 168.570622] vfs_write+0x46e/0x630 [ 168.571091] ksys_write+0xcd/0x1e0 [ 168.571563] ? __x64_sys_read+0x60/0x60 [ 168.572081] ? __kasan_check_write+0x20/0x30 [ 168.572659] ? do_user_addr_fault+0x446/0xff0 [ 168.573264] __x64_sys_write+0x46/0x60 [ 168.573774] do_syscall_64+0x35/0x80 [ 168.574264] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 168.574960] RIP: 0033:0x7fac74915130 [ 168.575456] Code: 73 01 c3 48 8b 0d 58 ed 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 444 [ 168.577969] RSP: 002b:00007ffc3080e288 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 168.578986] RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007fac74915130 [ 168.579937] RDX: 0000000000000009 RSI: 000056007669f080 RDI: 0000000000000001 [ 168.580884] RBP: 000056007669f080 R08: 000000000000000a R09: 00007fac75227700 [ 168.581841] R10: 000056007655c8f0 R11: 0000000000000246 R12: 0000000000000009 [ 168.582796] R13: 0000000000000001 R14: 00007fac74be55e0 R15: 00007fac74be08c0 [ 168.583757] [ 168.584063] Modules linked in: [ 168.584494] CR2: 0000000000000008 [ 168.584964] ---[ end trace 2475611ad0f77a1a ]--- This is because blkg_alloc() is called from blkg_conf_prep() without holding 'q->queue_lock', and elevator is exited before blkg_create(): thread 1 thread 2 blkg_conf_prep spin_lock_irq(&q->queue_lock); blkg_lookup_check -> return NULL spin_unlock_irq(&q->queue_lock); blkg_alloc blkcg_policy_enabled -> true pd = ->pd_alloc_fn blkg->pd[i] = pd blk_mq_exit_sched bfq_exit_queue blkcg_deactivate_policy spin_lock_irq(&q->queue_lock); __clear_bit(pol->plid, q->blkcg_pols); spin_unlock_irq(&q->queue_lock); q->elevator = NULL; spin_lock_irq(&q->queue_lock); blkg_create if (blkg->pd[i]) ->pd_init_fn -> q->elevator is NULL spin_unlock_irq(&q->queue_lock); Because blkcg_deactivate_policy() requires queue to be frozen, we can grab q_usage_counter to synchoronize blkg_conf_prep() against blkcg_deactivate_policy(). Fixes: e21b7a0b9887 ("block, bfq: add full hierarchical scheduling and cgroups support") Signed-off-by: Yu Kuai Acked-by: Tejun Heo Link: https://lore.kernel.org/r/20211020014036.2141723-1-yukuai3@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 71711bee74a4761d12de328383263efbeac39702 Author: Michael Schmitz Date: Sun Oct 24 13:20:13 2021 +1300 block: ataflop: more blk-mq refactoring fixes [ Upstream commit d28e4dff085c5a87025c9a0a85fb798bd8e9ca17 ] As it turns out, my earlier patch in commit 86d46fdaa12a (block: ataflop: fix breakage introduced at blk-mq refactoring) was incomplete. This patch fixes any remaining issues found during more testing and code review. Requests exceeding 4 k are handled in 4k segments but __blk_mq_end_request() is never called on these (still sectors outstanding on the request). With redo_fd_request() removed, there is no provision to kick off processing of the next segment, causing requests exceeding 4k to hang. (By setting /sys/block/fd0/queue/max_sectors_k <= 4 as workaround, this behaviour can be avoided). Instead of reintroducing redo_fd_request(), requeue the remainder of the request by calling blk_mq_requeue_request() on incomplete requests (i.e. when blk_update_request() still returns true), and rely on the block layer to queue the residual as new request. Both error handling and formatting needs to release the ST-DMA lock, so call finish_fdc() on these (this was previously handled by redo_fd_request()). finish_fdc() may be called legitimately without the ST-DMA lock held - make sure we only release the lock if we actually held it. In a similar way, early exit due to errors in ataflop_queue_rq() must release the lock. After minor errors, fd_error sets up to recalibrate the drive but never re-runs the current operation (another task handled by redo_fd_request() before). Call do_fd_action() to get the next steps (seek, retry read/write) underway. Signed-off-by: Michael Schmitz Fixes: 6ec3938cff95f (ataflop: convert to blk-mq) CC: linux-block@vger.kernel.org Link: https://lore.kernel.org/r/20211024002013.9332-1-schmitzmic@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8b19699ff6718a26d460137ba3c0d8b4f5db35c2 Author: Abinaya Kalaiselvan Date: Wed Oct 20 11:59:07 2021 +0300 ath10k: fix module load regression with iram-recovery feature [ Upstream commit 6f8c8bf4c7c9be1c42088689fd4370e06b46608a ] Commit 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support") introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit was not enabled in the ath10k coredump_mask module parameter: [ 2209.328190] ath10k_pci 0000:02:00.0: qca9984/qca9994 hw1.0 target 0x01000000 chip_id 0x00000000 sub 168c:cafe [ 2209.434414] ath10k_pci 0000:02:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 1 testmode 1 [ 2209.547191] ath10k_pci 0000:02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery crc32 cbade90a [ 2210.896485] ath10k_pci 0000:02:00.0: board_file api 1 bmi_id 0:1 crc32 a040efc2 [ 2213.603339] ath10k_pci 0000:02:00.0: failed to copy target iram contents: -12 [ 2213.839027] ath10k_pci 0000:02:00.0: could not init core (-12) [ 2213.933910] ath10k_pci 0000:02:00.0: could not probe fw (-12) And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA enabled so anyone using a firmware with iram-recovery feature would fail. To my knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099 enabled the feature. The reason for regression was that ath10k_core_copy_target_iram() used ath10k_coredump_get_mem_layout() to get the memory layout, but when ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out with an error. While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is disabled but the firmware has iram-recovery enabled the module load fails with similar error messages. I fixed that by returning 0 from ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns NULL. Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139 Fixes: 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support") Signed-off-by: Abinaya Kalaiselvan Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211020075054.23061-1-kvalo@codeaurora.org Signed-off-by: Sasha Levin commit 1ac33d3510a61b0e261f18332931243222b2bdc3 Author: Arnd Bergmann Date: Mon Oct 18 15:30:38 2021 +0100 ARM: 9142/1: kasan: work around LPAE build warning [ Upstream commit c2e6df3eaaf120cde5e7c3a70590dd82e427458a ] pgd_page_vaddr() returns an 'unsigned long' address, causing a warning with the memcpy() call in kasan_init(): arch/arm/mm/kasan_init.c: In function 'kasan_init': include/asm-generic/pgtable-nop4d.h:44:50: error: passing argument 2 of '__memcpy' makes pointer from integer without a cast [-Werror=int-conversion] 44 | #define pgd_page_vaddr(pgd) ((unsigned long)(p4d_pgtable((p4d_t){ pgd }))) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | long unsigned int arch/arm/include/asm/string.h:58:45: note: in definition of macro 'memcpy' 58 | #define memcpy(dst, src, len) __memcpy(dst, src, len) | ^~~ arch/arm/mm/kasan_init.c:229:16: note: in expansion of macro 'pgd_page_vaddr' 229 | pgd_page_vaddr(*pgd_offset_k(KASAN_SHADOW_START)), | ^~~~~~~~~~~~~~ arch/arm/include/asm/string.h:21:47: note: expected 'const void *' but argument is of type 'long unsigned int' 21 | extern void *__memcpy(void *dest, const void *src, __kernel_size_t n); | ~~~~~~~~~~~~^~~ Avoid this by adding an explicit typecast. Link: https://lore.kernel.org/all/CACRpkdb3DMvof3-xdtss0Pc6KM36pJA-iy=WhvtNVnsDpeJ24Q@mail.gmail.com/ Fixes: 5615f69bc209 ("ARM: 9016/2: Initialize the mapping of KASan shadow memory") Reviewed-by: Linus Walleij Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 5b01c24de28235e7913b61f1fac9c76f82cc9b60 Author: Vladimir Oltean Date: Sun Oct 24 20:17:48 2021 +0300 net: dsa: avoid refcount warnings when ->port_{fdb,mdb}_del returns error [ Upstream commit 232deb3f9567ce37d99b8616a6c07c1fc0436abf ] At present, when either of ds->ops->port_fdb_del() or ds->ops->port_mdb_del() return a non-zero error code, we attempt to save the day and keep the data structure associated with that switchdev object, as the deletion procedure did not complete. However, the way in which we do this is suspicious to the checker in lib/refcount.c, who thinks it is buggy to increment a refcount that became zero, and that this is indicative of a use-after-free. Fixes: 161ca59d39e9 ("net: dsa: reference count the MDB entries at the cross-chip notifier level") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3fb2e953a38b8302d63f319bf087cbdf411aed47 Author: Mark Rutland Date: Wed Oct 20 17:25:22 2021 +0100 irq: mips: avoid nested irq_enter() [ Upstream commit c65b52d02f6c1a06ddb20cba175ad49eccd6410d ] As bcm6345_l1_irq_handle() is a chained irqchip handler, it will be invoked within the context of the root irqchip handler, which must have entered IRQ context already. When bcm6345_l1_irq_handle() calls arch/mips's do_IRQ() , this will nest another call to irq_enter(), and the resulting nested increment to `rcu_data.dynticks_nmi_nesting` will cause rcu_is_cpu_rrupt_from_idle() to fail to identify wakeups from idle, resulting in failure to preempt, and RCU stalls. Chained irqchip handlers must invoke IRQ handlers by way of thee core irqchip code, i.e. generic_handle_irq() or generic_handle_domain_irq() and should not call do_IRQ(), which is intended only for root irqchip handlers. Fix bcm6345_l1_irq_handle() by calling generic_handle_irq() directly. Fixes: c7c42ec2baa1de7a ("irqchips/bmips: Add bcm6345-l1 interrupt controller") Signed-off-by: Mark Rutland Reviewed-by: Marc Zyngier Acked-by: Thomas Bogendoerfer Cc: Thomas Gleixner Signed-off-by: Sasha Levin commit 0238de13d5ef7f09afab37de96790ee821923429 Author: Claudio Imbrenda Date: Mon Sep 20 15:24:51 2021 +0200 KVM: s390: pv: avoid stalls for kvm_s390_pv_init_vm [ Upstream commit 1e2aa46de526a5adafe580bca4c25856bb06f09e ] When the system is heavily overcommitted, kvm_s390_pv_init_vm might generate stall notifications. Fix this by using uv_call_sched instead of just uv_call. This is ok because we are not holding spinlocks. Signed-off-by: Claudio Imbrenda Fixes: 214d9bbcd3a672 ("s390/mm: provide memory management functions for protected KVM guests") Reviewed-by: Christian Borntraeger Reviewed-by: Janosch Frank Message-Id: <20210920132502.36111-4-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 848686bc72d6fee4eaf1efe6612f63ff85395999 Author: Claudio Imbrenda Date: Mon Sep 20 15:24:50 2021 +0200 KVM: s390: pv: avoid double free of sida page [ Upstream commit d4074324b07a94a1fca476d452dfbb3a4e7bf656 ] If kvm_s390_pv_destroy_cpu is called more than once, we risk calling free_page on a random page, since the sidad field is aliased with the gbea, which is not guaranteed to be zero. This can happen, for example, if userspace calls the KVM_PV_DISABLE IOCTL, and it fails, and then userspace calls the same IOCTL again. This scenario is only possible if KVM has some serious bug or if the hardware is broken. The solution is to simply return successfully immediately if the vCPU was already non secure. Signed-off-by: Claudio Imbrenda Fixes: 19e1227768863a1469797c13ef8fea1af7beac2c ("KVM: S390: protvirt: Introduce instruction data area bounce buffer") Reviewed-by: Janosch Frank Reviewed-by: Christian Borntraeger Message-Id: <20210920132502.36111-3-imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 679a612a0d6aa3db7206af4e617a68527c7e8350 Author: David Hildenbrand Date: Thu Sep 9 18:22:44 2021 +0200 s390/uv: fully validate the VMA before calling follow_page() [ Upstream commit 46c22ffd2772201662350bc7b94b9ea9d3ee5ac2 ] We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). find_vma() does not check if the address is >= the VMA start address; use vma_lookup() instead. Fixes: 214d9bbcd3a6 ("s390/mm: provide memory management functions for protected KVM guests") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Acked-by: Heiko Carstens Reviewed-by: Liam R. Howlett Link: https://lore.kernel.org/r/20210909162248.14969-6-david@redhat.com Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit dcc9648cd192228bdd6a41c4c0163b11360bb744 Author: David Hildenbrand Date: Thu Sep 9 18:22:43 2021 +0200 s390/mm: fix VMA and page table handling code in storage key handling functions [ Upstream commit 949f5c1244ee6c36d2e81c588d1200eaa83a3df6 ] There are multiple things broken about our storage key handling functions: 1. We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). gfn_to_hva() will only translate using KVM memory regions, but won't validate the VMA. 2. We should not allocate page tables outside of VMA boundaries: if evil user space decides to map hugetlbfs to these ranges, bad things will happen because we suddenly have PTE or PMD page tables where we shouldn't have them. 3. We don't handle large PUDs that might suddenly appeared inside our page table hierarchy. Don't manually allocate page tables, properly validate that we have VMA and bail out on pud_large(). All callers of page table handling functions, except get_guest_storage_key(), call fixup_user_fault() in case they receive an -EFAULT and retry; this will allocate the necessary page tables if required. To keep get_guest_storage_key() working as expected and not requiring kvm_s390_get_skeys() to call fixup_user_fault() distinguish between "there is simply no page table or huge page yet and the key is assumed to be 0" and "this is a fault to be reported". Although commit 637ff9efe5ea ("s390/mm: Add huge pmd storage key handling") introduced most of the affected code, it was actually already broken before when using get_locked_pte() without any VMA checks. Note: Ever since commit 637ff9efe5ea ("s390/mm: Add huge pmd storage key handling") we can no longer set a guest storage key (for example from QEMU during VM live migration) without actually resolving a fault. Although we would have created most page tables, we would choke on the !pmd_present(), requiring a call to fixup_user_fault(). I would have thought that this is problematic in combination with postcopy life migration ... but nobody noticed and this patch doesn't change the situation. So maybe it's just fine. Fixes: 9fcf93b5de06 ("KVM: S390: Create helper function get_guest_storage_key") Fixes: 24d5dd0208ed ("s390/kvm: Provide function for setting the guest storage key") Fixes: a7e19ab55ffd ("KVM: s390: handle missing storage-key facility") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20210909162248.14969-5-david@redhat.com Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 783d5c1c009e27c249f86753a2ede862a5335f96 Author: David Hildenbrand Date: Thu Sep 9 18:22:42 2021 +0200 s390/mm: validate VMA in PGSTE manipulation functions [ Upstream commit fe3d10024073f06f04c74b9674bd71ccc1d787cf ] We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). gfn_to_hva() will only translate using KVM memory regions, but won't validate the VMA. Further, we should not allocate page tables outside of VMA boundaries: if evil user space decides to map hugetlbfs to these ranges, bad things will happen because we suddenly have PTE or PMD page tables where we shouldn't have them. Similarly, we have to check if we suddenly find a hugetlbfs VMA, before calling get_locked_pte(). Fixes: 2d42f9477320 ("s390/kvm: Add PGSTE manipulation functions") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20210909162248.14969-4-david@redhat.com Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 591aa785c1a97492ed21917330f5d5c45b8ffa6b Author: David Hildenbrand Date: Thu Sep 9 18:22:41 2021 +0200 s390/gmap: don't unconditionally call pte_unmap_unlock() in __gmap_zap() [ Upstream commit b159f94c86b43cf7e73e654bc527255b1f4eafc4 ] ... otherwise we will try unlocking a spinlock that was never locked via a garbage pointer. At the time we reach this code path, we usually successfully looked up a PGSTE already; however, evil user space could have manipulated the VMA layout in the meantime and triggered removal of the page table. Fixes: 1e133ab296f3 ("s390/mm: split arch/s390/mm/pgtable.c") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20210909162248.14969-3-david@redhat.com Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit 4fe9c6d097daee56cc8b963ab6b26a971b046c83 Author: David Hildenbrand Date: Thu Sep 9 18:22:40 2021 +0200 s390/gmap: validate VMA in __gmap_zap() [ Upstream commit 2d8fb8f3914b40e3cc12f8cbb74daefd5245349d ] We should not walk/touch page tables outside of VMA boundaries when holding only the mmap sem in read mode. Evil user space can modify the VMA layout just before this function runs and e.g., trigger races with page table removal code since commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in munmap"). The pure prescence in our guest_to_host radix tree does not imply that there is a VMA. Further, we should not allocate page tables (via get_locked_pte()) outside of VMA boundaries: if evil user space decides to map hugetlbfs to these ranges, bad things will happen because we suddenly have PTE or PMD page tables where we shouldn't have them. Similarly, we have to check if we suddenly find a hugetlbfs VMA, before calling get_locked_pte(). Note that gmap_discard() is different: zap_page_range()->unmap_single_vma() makes sure to stay within VMA boundaries. Fixes: b31288fa83b2 ("s390/kvm: support collaborative memory management") Signed-off-by: David Hildenbrand Reviewed-by: Claudio Imbrenda Acked-by: Heiko Carstens Link: https://lore.kernel.org/r/20210909162248.14969-2-david@redhat.com Signed-off-by: Christian Borntraeger Signed-off-by: Sasha Levin commit d3601801b0285657b4f8ad8a4e944e81ca3a2a24 Author: Nick Hainke Date: Fri Oct 8 00:57:25 2021 +0200 mt76: mt7615: mt7622: fix ibss and meshpoint [ Upstream commit 753453afacc0243bd45de45e34218a8d17493e8f ] commit 7f4b7920318b ("mt76: mt7615: add ibss support") introduced IBSS and commit f4ec7fdf7f83 ("mt76: mt7615: enable support for mesh") meshpoint support. Both used in the "get_omac_idx"-function: if (~mask & BIT(HW_BSSID_0)) return HW_BSSID_0; With commit d8d59f66d136 ("mt76: mt7615: support 16 interfaces") the ibss and meshpoint mode should "prefer hw bssid slot 1-3". However, with that change the ibss or meshpoint mode will not send any beacon on the mt7622 wifi anymore. Devices were still able to exchange data but only if a bssid already existed. Two mt7622 devices will never be able to communicate. This commits reverts the preferation of slot 1-3 for ibss and meshpoint. Only NL80211_IFTYPE_STATION will still prefer slot 1-3. Tested on Banana Pi R64. Fixes: d8d59f66d136 ("mt76: mt7615: support 16 interfaces") Signed-off-by: Nick Hainke Acked-by: Felix Fietkau Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211007225725.2615-1-vincent@systemli.org Signed-off-by: Sasha Levin commit 7462b70c2cb95d68d0fd42f1c265fad7239768fe Author: Andrii Nakryiko Date: Fri Oct 22 17:31:57 2021 -0700 libbpf: Fix BTF header parsing checks [ Upstream commit c825f5fee19caf301d9821cd79abaa734322de26 ] Original code assumed fixed and correct BTF header length. That's not always the case, though, so fix this bug with a proper additional check. And use actual header length instead of sizeof(struct btf_header) in sanity checks. Fixes: 8a138aed4a80 ("bpf: btf: Add BTF support to libbpf") Reported-by: Evgeny Vereshchagin Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211023003157.726961-2-andrii@kernel.org Signed-off-by: Sasha Levin commit 6eefcdb58847773519f3b605becda6ea6798791c Author: Andrii Nakryiko Date: Fri Oct 22 17:31:56 2021 -0700 libbpf: Fix overflow in BTF sanity checks [ Upstream commit 5245dafe3d49efba4d3285cf27ee1cc1eeafafc6 ] btf_header's str_off+str_len or type_off+type_len can overflow as they are u32s. This will lead to bypassing the sanity checks during BTF parsing, resulting in crashes afterwards. Fix by using 64-bit signed integers for comparison. Fixes: d8123624506c ("libbpf: Fix BTF data layout checks and allow empty BTF") Reported-by: Evgeny Vereshchagin Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211023003157.726961-1-andrii@kernel.org Signed-off-by: Sasha Levin commit a526d92e239cc1162f8a176735ccae8d28b85cd0 Author: Quentin Monnet Date: Fri Oct 22 10:47:43 2021 +0100 bpftool: Avoid leaking the JSON writer prepared for program metadata [ Upstream commit e89ef634f81c9d90e1824ab183721f3b361472e6 ] Bpftool creates a new JSON object for writing program metadata in plain text mode, regardless of metadata being present or not. Then this writer is freed if any metadata has been found and printed, but it leaks otherwise. We cannot destroy the object unconditionally, because the destructor prints an undesirable line break. Instead, make sure the writer is created only after we have found program metadata to print. Found with valgrind. Fixes: aff52e685eb3 ("bpftool: Support dumping metadata") Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211022094743.11052-1-quentin@isovalent.com Signed-off-by: Sasha Levin commit f1890b3e95ae4cdf79fe0e257e202fc259288421 Author: Mauricio Vásquez Date: Fri Oct 22 15:20:35 2021 -0500 libbpf: Fix memory leak in btf__dedup() [ Upstream commit 1000298c76830bc291358e98e8fa5baa3baa9b3a ] Free btf_dedup if btf_ensure_modifiable() returns error. Fixes: 919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API") Signed-off-by: Mauricio Vásquez Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20211022202035.48868-1-mauricio@kinvolk.io Signed-off-by: Sasha Levin commit f0c9660943860a295adba5958f3469ac6e1f0a38 Author: Jim Mattson Date: Wed Sep 29 17:36:49 2021 -0700 KVM: selftests: Fix nested SVM tests when built with clang [ Upstream commit ed290e1c20da19fa100a3e0f421aa31b65984960 ] Though gcc conveniently compiles a simple memset to "rep stos," clang prefers to call the libc version of memset. If a test is dynamically linked, the libc memset isn't available in L1 (nor is the PLT or the GOT, for that matter). Even if the test is statically linked, the libc memset may choose to use some CPU features, like AVX, which may not be enabled in L1. Note that __builtin_memset doesn't solve the problem, because (a) the compiler is free to call memset anyway, and (b) __builtin_memset may also choose to use features like AVX, which may not be available in L1. To avoid a myriad of problems, use an explicit "rep stos" to clear the VMCB in generic_svm_setup(), which is called both from L0 and L1. Reported-by: Ricardo Koller Signed-off-by: Jim Mattson Fixes: 20ba262f8631a ("selftests: KVM: AMD Nested test infrastructure") Message-Id: <20210930003649.4026553-1-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 3c26214f511490999339aad6bb991da86699f2ed Author: Tetsuo Handa Date: Tue Oct 19 20:27:26 2021 +0900 smackfs: use netlbl_cfg_cipsov4_del() for deleting cipso_v4_doi [ Upstream commit 0934ad42bb2c5df90a1b9de690f93de735b622fe ] syzbot is reporting UAF at cipso_v4_doi_search() [1], for smk_cipso_doi() is calling kfree() without removing from the cipso_v4_doi_list list after netlbl_cfg_cipsov4_map_add() returned an error. We need to use netlbl_cfg_cipsov4_del() in order to remove from the list and wait for RCU grace period before kfree(). Link: https://syzkaller.appspot.com/bug?extid=93dba5b91f0fed312cbd [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 6c2e8ac0953fccdd ("netlabel: Update kernel configuration API") Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 951f277ddeffab68b2f73ea7630960fae17d8543 Author: Horia Geantă Date: Fri Oct 15 10:39:18 2021 +0300 crypto: tcrypt - fix skcipher multi-buffer tests for 1420B blocks [ Upstream commit 3ae88f676aa63366ffa9eebb8ae787c7e19f0c57 ] Commit ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks") mentions: > power-of-2 block size. So let's add 1420 bytes explicitly, and round > it up to the next blocksize multiple of the algo in question if it > does not support 1420 byte blocks. but misses updating skcipher multi-buffer tests. Fix this by using the proper (rounded) input size. Fixes: ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks") Signed-off-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 161b7ee0ab6292374555e68c9a4061e804a1ec2a Author: Jessica Zhang Date: Wed Oct 20 10:57:33 2021 -0700 drm/msm: Fix potential NULL dereference in DPU SSPP [ Upstream commit 8bf71a5719b6cc5b6ba358096081e5d50ea23ab6 ] Move initialization of sblk in _sspp_subblk_offset() after NULL check to avoid potential NULL pointer dereference. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Reported-by: Dan Carpenter Signed-off-by: Jessica Zhang Link: https://lore.kernel.org/r/20211020175733.3379-1-jesszhan@codeaurora.org Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 958d4b4dce1f2efe99ea12e57d7fb93314505631 Author: Joerg Roedel Date: Thu Oct 21 10:08:32 2021 +0200 x86/sev: Fix stack type check in vc_switch_off_ist() [ Upstream commit 5681981fb788281b09a4ea14d310d30b2bd89132 ] The value of STACK_TYPE_EXCEPTION_LAST points to the last _valid_ exception stack. Reflect that in the check done in the vc_switch_off_ist() function. Fixes: a13644f3a53de ("x86/entry/64: Add entry code for #VC handler") Reported-by: Tom Lendacky Signed-off-by: Joerg Roedel Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20211021080833.30875-2-joro@8bytes.org Signed-off-by: Sasha Levin commit eb82db5a1cb8031c4e439df41e0ebafae4ed5149 Author: Kees Cook Date: Sat Aug 28 10:57:47 2021 -0700 clocksource/drivers/timer-ti-dm: Select TIMER_OF [ Upstream commit eda9a4f7af6ee47e9e131f20e4f8a41a97379293 ] When building OMAP_DM_TIMER without TIMER_OF, there are orphan sections due to the use of TIMER_OF_DELCARE() without CONFIG_TIMER_OF. Select CONFIG_TIMER_OF when enaling OMAP_DM_TIMER: arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section `__timer_of_table' Reported-by: kernel test robot Link: https://lore.kernel.org/lkml/202108282255.tkdt4ani-lkp@intel.com/ Cc: Tony Lindgren Cc: Daniel Lezcano Cc: Keerthy Cc: Sebastian Reichel Cc: Ladislav Michl Cc: Grygorii Strashko Cc: linux-omap@vger.kernel.org Fixes: 52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support") Signed-off-by: Kees Cook Acked-by: Tony Lindgren Link: https://lore.kernel.org/r/20210828175747.3777891-1-keescook@chromium.org Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit d2a0b63348ee8a4d8a37b77e8f6e3c42eea23157 Author: Anders Roxell Date: Thu Oct 7 21:13:37 2021 +0200 PM: hibernate: fix sparse warnings [ Upstream commit 01de5fcd8b1ac0ca28d2bb0921226a54fdd62684 ] When building the kernel with sparse enabled 'C=1' the following warnings shows up: kernel/power/swap.c:390:29: warning: incorrect type in assignment (different base types) kernel/power/swap.c:390:29: expected int ret kernel/power/swap.c:390:29: got restricted blk_status_t This is due to function hib_wait_io() returns a 'blk_status_t' which is a bitwise u8. Commit 5416da01ff6e ("PM: hibernate: Remove blk_status_to_errno in hib_wait_io") seemed to have mixed up the return type. However, the 4e4cbee93d56 ("block: switch bios to blk_status_t") actually broke the behaviour by returning the wrong type. Rework so function hib_wait_io() returns a 'int' instead of 'blk_status_t' and make sure to call function blk_status_to_errno(hb->error)' when returning from function hib_wait_io() a int gets returned. Fixes: 4e4cbee93d56 ("block: switch bios to blk_status_t") Fixes: 5416da01ff6e ("PM: hibernate: Remove blk_status_to_errno in hib_wait_io") Signed-off-by: Anders Roxell Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 78a3123bafca7204497284370da46a10eefdd0e5 Author: Max Gurtovoy Date: Sun Oct 17 11:58:16 2021 +0300 nvme-rdma: fix error code in nvme_rdma_setup_ctrl [ Upstream commit 09748122009aed7bfaa7acc33c10c083a4758322 ] In case that icdoff is not zero or mandatory keyed sgls are not supported by the NVMe/RDMA target, we'll go to error flow but we'll return 0 to the caller. Fix it by returning an appropriate error code. Fixes: c66e2998c8ca ("nvme-rdma: centralize controller setup sequence") Signed-off-by: Max Gurtovoy Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 846394ea4227405dfaabd9034349cd8677d94dcd Author: Ye Bin Date: Wed Oct 20 15:39:59 2021 +0800 nbd: Fix use-after-free in pid_show [ Upstream commit 0c98057be9efa32de78dbc4685fc73da9d71faa1 ] I got issue as follows: [ 263.886511] BUG: KASAN: use-after-free in pid_show+0x11f/0x13f [ 263.888359] Read of size 4 at addr ffff8880bf0648c0 by task cat/746 [ 263.890479] CPU: 0 PID: 746 Comm: cat Not tainted 4.19.90-dirty #140 [ 263.893162] Call Trace: [ 263.893509] dump_stack+0x108/0x15f [ 263.893999] print_address_description+0xa5/0x372 [ 263.894641] kasan_report.cold+0x236/0x2a8 [ 263.895696] __asan_report_load4_noabort+0x25/0x30 [ 263.896365] pid_show+0x11f/0x13f [ 263.897422] dev_attr_show+0x48/0x90 [ 263.898361] sysfs_kf_seq_show+0x24d/0x4b0 [ 263.899479] kernfs_seq_show+0x14e/0x1b0 [ 263.900029] seq_read+0x43f/0x1150 [ 263.900499] kernfs_fop_read+0xc7/0x5a0 [ 263.903764] vfs_read+0x113/0x350 [ 263.904231] ksys_read+0x103/0x270 [ 263.905230] __x64_sys_read+0x77/0xc0 [ 263.906284] do_syscall_64+0x106/0x360 [ 263.906797] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reproduce this issue as follows: 1. nbd-server 8000 /tmp/disk 2. nbd-client localhost 8000 /dev/nbd1 3. cat /sys/block/nbd1/pid Then trigger use-after-free in pid_show. Reason is after do step '2', nbd-client progress is already exit. So it's task_struct already freed. To solve this issue, revert part of 6521d39a64b3's modify and remove useless 'recv_task' member of nbd_device. Fixes: 6521d39a64b3 ("nbd: Remove variable 'pid'") Signed-off-by: Ye Bin Reviewed-by: Josef Bacik Link: https://lore.kernel.org/r/20211020073959.2679255-1-yebin10@huawei.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 3218ca577dc07287055365dae9ba7fa3964a3dde Author: Stefan Agner Date: Tue Oct 19 21:16:47 2021 +0200 phy: micrel: ksz8041nl: do not use power down mode [ Upstream commit 2641b62d2fab52648e34cdc6994b2eacde2d27c1 ] Some Micrel KSZ8041NL PHY chips exhibit continuous RX errors after using the power down mode bit (0.11). If the PHY is taken out of power down mode in a certain temperature range, the PHY enters a weird state which leads to continuously reporting RX errors. In that state, the MAC is not able to receive or send any Ethernet frames and the activity LED is constantly blinking. Since Linux is using the suspend callback when the interface is taken down, ending up in that state can easily happen during a normal startup. Micrel confirmed the issue in errata DS80000700A [*], caused by abnormal clock recovery when using power down mode. Even the latest revision (A4, Revision ID 0x1513) seems to suffer that problem, and according to the errata is not going to be fixed. Remove the suspend/resume callback to avoid using the power down mode completely. [*] https://ww1.microchip.com/downloads/en/DeviceDoc/80000700A.pdf Fixes: 1a5465f5d6a2 ("phy/micrel: Add suspend/resume support to Micrel PHYs") Signed-off-by: Stefan Agner Acked-by: Marcel Ziswiler Signed-off-by: Francesco Dolcini Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6565d4b252296a63d8c40b93ff76db71243c52a1 Author: Tim Gardner Date: Tue Oct 19 12:19:50 2021 -0600 net: enetc: unmap DMA in enetc_send_cmd() [ Upstream commit cd4bc63de774eee95e9bac26a565cd80e0fca421 ] Coverity complains of a possible dereference of a null return value. 5. returned_null: kzalloc returns NULL. [show details] 6. var_assigned: Assigning: si_data = NULL return value from kzalloc. 488 si_data = kzalloc(data_size, __GFP_DMA | GFP_KERNEL); 489 cbd.length = cpu_to_le16(data_size); 490 491 dma = dma_map_single(&priv->si->pdev->dev, si_data, 492 data_size, DMA_FROM_DEVICE); While this kzalloc() is unlikely to fail, I did notice that the function returned without unmapping si_data. Fix this by refactoring the error paths and checking for kzalloc() failure. Fixes: 888ae5a3952ba ("net: enetc: add tc flower psfp offload driver") Cc: Claudiu Manoil Cc: "David S. Miller" Cc: Jakub Kicinski Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org (open list) Signed-off-by: Tim Gardner Acked-by: Claudiu Manoil Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f3b6b7f2124b71b21ffb6f0c76f2749edccc0d44 Author: Johannes Berg Date: Sat Oct 16 11:43:58 2021 +0300 iwlwifi: pnvm: read EFI data only if long enough [ Upstream commit e864a77f51d0d8113b49cf7d030bc9dc911c8176 ] If the data we get from EFI is not even long enough for the package struct we expect then ignore it entirely. Signed-off-by: Johannes Berg Fixes: a1a6a4cf49ec ("iwlwifi: pnvm: implement reading PNVM from UEFI") Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20211016114029.33feba783518.I54a5cf33975d0330792b3d208b225d479e168f32@changeid Signed-off-by: Sasha Levin commit c0ee10049f0f3568f3ba99a3402cff956fcb7a63 Author: Johannes Berg Date: Sat Oct 16 11:43:57 2021 +0300 iwlwifi: pnvm: don't kmemdup() more than we have [ Upstream commit 0f892441d8c353144e3669b7991fa5fe0bd353e9 ] We shouldn't kmemdup() more data than we have, that might cause the code to crash. Fix that by updating the length before the kmemdup. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ab0e64c3fba9.Ic6a3295fc384750b51b4270bf0b7d94984a139f2@changeid Signed-off-by: Sasha Levin commit 4925a9dc91cad4c72ce60716c29504fde60b001c Author: Johannes Berg Date: Sat Oct 16 11:43:55 2021 +0300 iwlwifi: mvm: reset PM state on unsuccessful resume [ Upstream commit 2f629a7772e2a7bdaff25178917a40073f79702c ] If resume fails for some reason, we need to set the PM state back to normal so we're able to send commands during firmware reset, rather than failing all of them because we're in D3. Signed-off-by: Johannes Berg Fixes: 708a39aaca22 ("iwlwifi: mvm: don't send commands during suspend\resume transition") Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20211016114029.7ceb9eaca9f6.If0cbef38c6d07ec1ddce125878a4bdadcb35d2c9@changeid Signed-off-by: Sasha Levin commit 150eeb5ecbb8682c9f2909298f55dc0d01803eae Author: Jonas Dreßler Date: Sat Oct 16 17:32:43 2021 +0200 mwifiex: Send DELBA requests according to spec [ Upstream commit cc8a8bc37466f79b24d972555237f3d591150602 ] While looking at on-air packets using Wireshark, I noticed we're never setting the initiator bit when sending DELBA requests to the AP: While we set the bit on our del_ba_param_set bitmask, we forget to actually copy that bitmask over to the command struct, which means we never actually set the initiator bit. Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command struct. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by: Jonas Dreßler Acked-by: Pali Rohár Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl Signed-off-by: Sasha Levin commit b1aa768ec157e7d0a36bccb2296adbcf11a07d5b Author: Ziyang Xuan Date: Fri Oct 15 12:03:35 2021 +0800 rsi: stop thread firstly in rsi_91x_init() error handling [ Upstream commit 515e7184bdf0a3ebf1757cc77fb046b4fe282189 ] When fail to init coex module, free 'common' and 'adapter' directly, but common->tx_thread which will access 'common' and 'adapter' is running at the same time. That will trigger the UAF bug. ================================================================== BUG: KASAN: use-after-free in rsi_tx_scheduler_thread+0x50f/0x520 [rsi_91x] Read of size 8 at addr ffff8880076dc000 by task Tx-Thread/124777 CPU: 0 PID: 124777 Comm: Tx-Thread Not tainted 5.15.0-rc5+ #19 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? rsi_tx_scheduler_thread+0x50f/0x520 kasan_report.cold+0x7f/0x11b ? rsi_tx_scheduler_thread+0x50f/0x520 rsi_tx_scheduler_thread+0x50f/0x520 ... Freed by task 111873: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 rsi_91x_init+0x741/0x8a0 [rsi_91x] rsi_probe+0x9f/0x1750 [rsi_usb] Stop thread before free 'common' and 'adapter' to fix it. Fixes: 2108df3c4b18 ("rsi: add coex support") Signed-off-by: Ziyang Xuan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211015040335.1021546-1-william.xuanziyang@huawei.com Signed-off-by: Sasha Levin commit 3ccaadc5bd576794589f42028c5069d1357ce0e9 Author: Shayne Chen Date: Mon Oct 18 16:07:04 2021 +0800 mt76: mt7915: fix muar_idx in mt7915_mcu_alloc_sta_req() [ Upstream commit 161cc13912d3c3e8857001988dfba39be842454a ] For broadcast/multicast wcid, the muar_idx should be 0xe. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3a94ccdd929c2ddca0d3d33d326203134a826998 Author: Shayne Chen Date: Mon Oct 18 16:07:02 2021 +0800 mt76: mt7915: fix sta_rec_wtbl tag len [ Upstream commit afa0370f3a3a64af6d368da0bedd72ab2a026cd0 ] Fix tag len error for sta_rec_wtbl, which causes fw parsing error for the tags placed behind it. Fixes: e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 97d6c316e1aad5eb17ddbe0aba37a63d00fdd01a Author: Lorenzo Bianconi Date: Thu Oct 14 17:19:53 2021 +0200 mt76: connac: fix possible NULL pointer dereference in mt76_connac_get_phy_mode_v2 [ Upstream commit b5f2ba8a4c794e8349c0e30036352b9f685164c4 ] Fix the following NULL pointer dereference in mt76_connac_get_phy_mode_v2 routine triggered on mt7663s device when sta is NULL [ 5.490700] mt7663s mmc0:0001:1: N9 Firmware Version: 3.1.1, Build Time: 20200604161656 [ 5.490815] mt7663s mmc0:0001:1: Region number: 0x4 [ 5.490868] mt7663s mmc0:0001:1: Parsing tailer Region: 0 [ 5.496251] mt7663s mmc0:0001:1: Region 0, override_addr = 0x00118000 [ 5.496419] mt7663s mmc0:0001:1: Parsing tailer Region: 1 [ 5.624027] mt7663s mmc0:0001:1: Parsing tailer Region: 2 [ 5.656999] mt7663s mmc0:0001:1: Parsing tailer Region: 3 [ 5.671876] mt7663s mmc0:0001:1: override_addr = 0x00118000, option = 3 [ 9.358658] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 9.358775] #PF: supervisor read access in kernel mode [ 9.358831] #PF: error_code(0x0000) - not-present page [ 9.358886] PGD 0 P4D 0 [ 9.358917] Oops: 0000 [#1] SMP [ 9.358960] CPU: 0 PID: 235 Comm: NetworkManager Not tainted 5.15.0-rc4-kvm-02151-g39e333d657f4-dirty #769 [ 9.359057] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014 [ 9.359150] RIP: 0010:mt76_connac_get_phy_mode_v2+0xc9/0x11c [ 9.359473] RAX: 0000000000000013 RBX: 0000000000000000 RCX: 0000000000000027 [ 9.359546] RDX: ffff8881f9c17358 RSI: 0000000000000001 RDI: ffff8881f9c17350 [ 9.359624] RBP: ffff88810bac1ed4 R08: ffffffff822a4a48 R09: 0000000000000003 [ 9.359697] R10: ffffffff82234a60 R11: ffffffff82234a60 R12: ffff88810bac1eec [ 9.359779] R13: 0000000000000000 R14: ffff88810bad1648 R15: ffff88810bac1eb8 [ 9.359859] FS: 00007f5f1e45bbc0(0000) GS:ffff8881f9c00000(0000) knlGS:0000000000000000 [ 9.359939] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 9.360003] CR2: 0000000000000000 CR3: 0000000105d5d000 CR4: 00000000000006b0 [ 9.360083] Call Trace: [ 9.360116] mt76_connac_mcu_uni_add_bss.cold+0x21/0x250 [ 9.360175] ? schedule_preempt_disabled+0xa/0x10 [ 9.360232] ? __mutex_lock.constprop.0+0x2ab/0x460 [ 9.360286] mt7615_remove_interface+0x63/0x1d0 [ 9.360342] drv_remove_interface+0x32/0xe0 [ 9.360385] ieee80211_do_stop+0x5da/0x800 [ 9.360428] ? dev_reset_queue+0x30/0x90 [ 9.360472] ieee80211_stop+0x3b/0xb0 [ 9.360516] __dev_close_many+0x7a/0xd0 [ 9.360559] __dev_change_flags+0xd6/0x1f0 [ 9.360604] dev_change_flags+0x21/0x60 [ 9.360648] do_setlink+0x259/0xfb0 [ 9.360686] ? __nla_validate_parse+0x51/0xb80 [ 9.360742] __rtnl_newlink+0x5b3/0x960 [ 9.360785] ? inet6_fill_ifla6_attrs+0x41d/0x470 [ 9.360841] ? __kmalloc_track_caller+0x57/0x3c0 [ 9.360905] ? netlink_trim+0x8a/0xb0 [ 9.360949] ? skb_queue_tail+0x1b/0x50 Fixes: 67aa27431c7f8 ("mt76: mt7921: rely on mt76_connac_mcu common library") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit e1b1873523e48d95cf739f3665073ad5e4546c14 Author: Ryder Lee Date: Mon Sep 27 12:59:49 2021 +0800 mt76: mt7615: fix monitor mode tear down crash [ Upstream commit a6fdbdd1ac2996a58a84672ef37efb5cbb98fadf ] [ 103.451600] CPU 3 Unable to handle kernel paging request at virtual address 00000003, epc == 8576591c, ra == 857659f0 [ 103.462226] Oops[#1]: [ 103.464499] CPU: 3 PID: 9247 Comm: ifconfig Tainted: G W 5.4.143 #0 [ 103.472031] $ 0 : 00000000 00000001 83be3854 00000000 [ 103.477239] $ 4 : 8102a374 8102a374 8102f0b0 00000200 [ 103.482444] $ 8 : 0000002d 000001e4 64373765 5d206337 [ 103.487647] $12 : 00000000 00000005 00000000 0006d1df [ 103.492853] $16 : 83be3848 853838a8 8743d600 00010000 [ 103.498059] $20 : 00000000 00000000 8553dec0 0000007f [ 103.503266] $24 : 00000003 80382084 [ 103.508472] $28 : 831d4000 831d5bc0 00000001 857659f0 [ 103.513678] Hi : 00000122 [ 103.516543] Lo : d1768000 [ 103.519452] epc : 8576591c mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common] [ 103.526306] ra : 857659f0 mt7615_mcu_add_bss+0x1a4/0x3c0 [mt7615_common] [ 103.533232] Status: 11007c03 KERNEL EXL IE [ 103.537402] Cause : 40800008 (ExcCode 02) [ 103.541389] BadVA : 00000003 [ 103.544253] PrId : 0001992f (MIPS 1004Kc) [ 103.797086] Call Trace: [ 103.799562] [<8576591c>] mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common] [ 103.806082] [<85760a14>] mt7615_remove_interface+0x74/0x1e0 [mt7615_common] [ 103.813280] [<85603fcc>] drv_remove_interface+0x2c/0xa0 [mac80211] [ 103.819612] [<8561a8e4>] ieee80211_del_virtual_monitor.part.22+0x74/0xe8 [mac80211] [ 103.827410] [<8561b7f0>] ieee80211_do_stop+0x4a4/0x8a0 [mac80211] [ 103.833671] [<8561bc00>] ieee80211_stop+0x14/0x24 [mac80211] [ 103.839405] [<8045a328>] __dev_close_many+0x9c/0x10c [ 103.844364] [<80463de4>] __dev_change_flags+0x16c/0x1e4 [ 103.849569] [<80463e84>] dev_change_flags+0x28/0x70 [ 103.854440] [<80521e54>] devinet_ioctl+0x280/0x774 [ 103.859222] [<80526248>] inet_ioctl+0xa4/0x1c8 [ 103.863674] [<80436830>] sock_ioctl+0x2d8/0x4bc [ 103.868201] [<801adbb4>] do_vfs_ioctl+0xb8/0x7c0 [ 103.872804] [<801ae30c>] ksys_ioctl+0x50/0xb4 [ 103.877156] [<80014598>] syscall_common+0x34/0x58 Fixes: 04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 754ce9d4062ff5a349d449b78e041fca937980b9 Author: Sean Wang Date: Tue Sep 14 23:50:22 2021 +0800 mt76: mt7921: fix retrying release semaphore without end [ Upstream commit 02d1c7d494d8052288bc175e4ff54b56d08a3c5f ] We should pass the error code to the caller immediately to avoid the possible infinite retry to release the semaphore. Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support") Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5c6abb9533969fa88abcf22a956be49f5e972a9f Author: Lorenzo Bianconi Date: Tue Sep 14 18:42:51 2021 +0200 mt76: mt7915: fix possible infinite loop release semaphore [ Upstream commit e500c9470e26be66eb2bc6de773ae9091149118a ] Fix possible infinite loop in mt7915_load_patch if mt7915_mcu_patch_sem_ctrl always returns an error. Fixes: e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3ff001be2c2964e0295978a27ffac20457abc546 Author: Ryder Lee Date: Thu Sep 2 13:52:04 2021 +0800 mt76: mt7615: fix hwmon temp sensor mem use-after-free [ Upstream commit 0bb4e9187ea4a59dc6658a62978deda0c0dc4b28 ] Without this change, garbage is seen in the hwmon name and sensors output for mt7615 is garbled. Fixes: 109e505ad944 ("mt76: mt7615: add thermal sensor device support") Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit dd879ab927a3714092600e41690afb90592483cc Author: Ben Greear Date: Thu Sep 2 13:52:03 2021 +0800 mt76: mt7915: fix hwmon temp sensor mem use-after-free [ Upstream commit 0ae3ff5684514d72357240f1033a7494c51f93ed ] Without this change, garbage is seen in the hwmon name and sensors output for mt7915 is garbled. It appears that the hwmon logic does not make a copy of the incoming string, but instead just copies a char* and expects it to never go away. Fixes: 33fe9c639c13 ("mt76: mt7915: add thermal sensor device support") Signed-off-by: Ben Greear Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3fe59d13aba05425cb830eb841feb39dc2330c4c Author: Lorenzo Bianconi Date: Wed Aug 18 10:20:57 2021 +0200 mt76: mt7921: always wake device if necessary in debugfs [ Upstream commit 569008744178b672ea3ad9047fa3098f1b73ca55 ] Add missing device wakeup in debugfs code if we are accessing chip registers. Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 98967931f70f9799afdcb2f9e705f2ce7d38ea88 Author: Sean Wang Date: Sat Aug 14 02:09:18 2021 +0800 mt76: mt7921: fix kernel warning from cfg80211_calculate_bitrate [ Upstream commit 8e695328a1006b7bab2d972e7d0111fa6e6faf51 ] Fix the kernel warning from cfg80211_calculate_bitrate due to the legacy rate is not parsed well in the current driver. Also, zeros struct rate_info before we fill it out to avoid the old value is kept such as rate->legacy. [ 790.921560] WARNING: CPU: 7 PID: 970 at net/wireless/util.c:1298 cfg80211_calculate_bitrate+0x354/0x35c [cfg80211] [ 790.987738] Hardware name: MediaTek Asurada rev1 board (DT) [ 790.993298] pstate: a0400009 (NzCv daif +PAN -UAO) [ 790.998104] pc : cfg80211_calculate_bitrate+0x354/0x35c [cfg80211] [ 791.004295] lr : cfg80211_calculate_bitrate+0x180/0x35c [cfg80211] [ 791.010462] sp : ffffffc0129c3880 [ 791.013765] x29: ffffffc0129c3880 x28: ffffffd38305bea8 [ 791.019065] x27: ffffffc0129c3970 x26: 0000000000000013 [ 791.024364] x25: 00000000000003ca x24: 000000000000002f [ 791.029664] x23: 00000000000000d0 x22: ffffff8d108bc000 [ 791.034964] x21: ffffff8d108bc0d0 x20: ffffffc0129c39a8 [ 791.040264] x19: ffffffc0129c39a8 x18: 00000000ffff0a10 [ 791.045563] x17: 0000000000000050 x16: 00000000000000ec [ 791.050910] x15: ffffffd3f9ebed9c x14: 0000000000000006 [ 791.056211] x13: 00000000000b2eea x12: 0000000000000000 [ 791.061511] x11: 00000000ffffffff x10: 0000000000000000 [ 791.066811] x9 : 0000000000000000 x8 : 0000000000000000 [ 791.072110] x7 : 0000000000000000 x6 : ffffffd3fafa5a7b [ 791.077409] x5 : 0000000000000000 x4 : 0000000000000000 [ 791.082708] x3 : 0000000000000000 x2 : 0000000000000000 [ 791.088008] x1 : ffffff8d3f79c918 x0 : 0000000000000000 [ 791.093308] Call trace: [ 791.095770] cfg80211_calculate_bitrate+0x354/0x35c [cfg80211] [ 791.101615] nl80211_put_sta_rate+0x6c/0x2c0 [cfg80211] [ 791.106853] nl80211_send_station+0x980/0xaa4 [cfg80211] [ 791.112178] nl80211_get_station+0xb4/0x134 [cfg80211] [ 791.117308] genl_rcv_msg+0x3a0/0x440 [ 791.120960] netlink_rcv_skb+0xcc/0x118 [ 791.124785] genl_rcv+0x34/0x48 [ 791.127916] netlink_unicast+0x144/0x1dc Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3ca3a4255e4ed3749583b10bb2a0b5d26bdeb253 Author: Sean Wang Date: Wed Aug 11 13:58:24 2021 +0800 mt76: mt7921: fix firmware usage of RA info using legacy rates [ Upstream commit 99b8e195994d9d77de3bfe0cb403c44a57c2cf79 ] According to the firmware usage, OFDM rates should fill out bit 6 - 13 while CCK rates should fill out bit 0 - 3 in legacy field of RA info to make the rate adaption runs propertly. Otherwise, a unicast frame might be picking up the unsupported rate to send out. Fixes: 1c099ab44727 ("mt76: mt7921: add MCU support") Reported-by: Joshua Emele Co-developed-by: YN Chen Signed-off-by: YN Chen Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a71eba425307fb636786e6ae5d82c1aced5bf83f Author: Sean Wang Date: Fri Aug 13 06:48:24 2021 +0800 mt76: mt7921: report HE MU radiotap [ Upstream commit 4fee32153ab62356aeea9d152d8f33a5fd3a0086 ] Report HE MU/BF radiotap. That fixed HE MU packets dropped by mac80211 because they are missing the ieee80211_radiotap_he_mu header. Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support") Co-developed-by: Ryder Lee Signed-off-by: Ryder Lee Co-developed-by: Eric-SY Chang Signed-off-by: Eric-SY Chang Tested-by: Eric-SY Chang Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit f75989a2a4dd2f54e2d520349206827ea5f03c25 Author: Lorenzo Bianconi Date: Sun Aug 8 21:11:49 2021 +0200 mt76: overwrite default reg_ops if necessary [ Upstream commit f6e1f59885dae5a2553f8bbd328be2cb1c80ccb2 ] Introduce mt76_register_debugfs_fops routine in order to define per-driver regs file operations and make sure the device is up before reading or writing its registers Fixes: 1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support") Fixes: de5ff3c9d1a2 ("mt76: mt7615: introduce pm_power_save delayed work") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 1b2e3a89897fd9df5495ef5f6e9054413116741e Author: Leon Yen Date: Wed Jul 28 06:59:16 2021 +0800 mt76: connac: fix GTK rekey offload failure on WPA mixed mode [ Upstream commit 781f62960c635cfed55a8f8c0f909bdaf8268257 ] Update the proper firmware programming sequence to fix GTK rekey offload failure on WPA mixed mode. In the mt76_connac_mcu_key_iter, gtk_tlv->proto should be only set up on pairwise key and gtk_tlk->group_cipher should be only set up on the group key. Otherwise, those parameters required by firmware would be set incorrectly to cause GTK rekey offload failure on WPA mixed mode and then disconnection follows. Fixes: b47e21e75c80 ("mt76: mt7615: add gtk rekey offload support") Co-developed-by: Sean Wang Signed-off-by: Sean Wang Signed-off-by: Leon Yen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit c29855c0c1edc88bfcbe1297bd064a341af15ad0 Author: Deren Wu Date: Tue Jul 27 17:47:09 2021 +0800 mt76: mt7921: fix dma hang in rmmod [ Upstream commit a23f80aa9c5e6ad4ec8df88037b7ffd4162b1ec4 ] The dma would be broken after rmmod flow. There are two different cases causing this issue. 1. dma access without privilege. 2. hw access sequence borken by another context. This patch handle both cases to avoid hw crash. Fixes: 2b9ea5a8cf1bd ("mt76: mt7921: add mt7921_dma_cleanup in mt7921_unregister_device") Signed-off-by: Deren Wu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d2697e6d812951a3da67bff930a853129665570b Author: Shayne Chen Date: Tue Jul 20 21:00:14 2021 +0800 mt76: mt7915: fix bit fields for HT rate idx [ Upstream commit 47f1c08db7f3aaa2d13f8e56209375462ace7b8a ] The bit fields of tx rate idx should be 6 bits, otherwise it might be incorrect in HT mode. For VHT/HE rates, only 4 bits are actually used by rate idx, the other 2 bits are used for other functions. Fixes: c31d94af1843 ("mt76: mt7915: fix tx rate related fields in tx descriptor") Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b7282c7d0dc853600044a0ef1082326b259974b7 Author: Shayne Chen Date: Tue Jul 20 10:48:32 2021 +0800 mt76: mt7915: fix potential overflow of eeprom page index [ Upstream commit 82a980f82a511ce74ab57eb9f692d02225eb32f4 ] If total eeprom size is divisible by per-page size, the i in for loop will exceed max page index, which happens in our newer chipset. Fixes: 26f18380e6ca ("mt76: mt7915: add support for flash mode") Signed-off-by: Bo Jiao Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit a95ec17c67a480923db57a61933b78c94a125929 Author: Deren Wu Date: Wed Jul 14 23:50:52 2021 +0800 mt76: mt7921: Fix out of order process by invalid event pkt [ Upstream commit cd3f387371e941e6806b455b4ba5b9f4ca4b77c6 ] The acceptable event report should inlcude original CMD-ID. Otherwise, drop unexpected result from fw. Fixes: 1c099ab44727c ("mt76: mt7921: add MCU support") Signed-off-by: Jimmy Hu Signed-off-by: Deren Wu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 37af03f35908de68cf096548453fe031b92eca33 Author: Lorenzo Bianconi Date: Tue Jun 22 09:48:30 2021 +0200 mt76: mt76x02: fix endianness warnings in mt76x02_mac.c [ Upstream commit c33edef520213feccebc22c9474c685b9fb60611 ] Fix the following sparse warning in mt76x02_mac_write_txwi and mt76x02_mac_tx_rate_val routines: drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:237:19: warning: restricted __le16 degrades to intege warning: cast from restricted __le16 drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:383:28: warning: incorrect type in assignment (different base types) expected restricted __le16 [usertype] rate got unsigned long Fixes: db9f11d3433f7 ("mt76: store wcid tx rate info in one u32 reduce locking") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 02c06f2be95b05775c86206deae69e0248846056 Author: Lorenzo Bianconi Date: Wed Jun 23 15:19:19 2021 +0200 mt76: mt7921: fix survey-dump reporting [ Upstream commit 64ed76d118c656907ec1155f2cdd24de778470a2 ] Fix MIB tx-rx MIB counters for survey-dump reporting. Fixes: 163f4d22c118d ("mt76: mt7921: add MAC support") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit d0e327a1646eaa51f0399ceb3add54395f296890 Author: Sean Wang Date: Sun Jun 20 15:48:07 2021 +0800 mt76: fix build error implicit enumeration conversion [ Upstream commit adedbc643f02f5a3193b8dcc5cfca97b4c988667 ] drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:114:10: error: implicit conversion from enumeration type 'enum mt76_cipher_type' to different enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion] return MT_CIPHER_NONE; ~~~~~~ ^~~~~~~~~~~~~~ drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:114:10: error: implicit conversion from enumeration type 'enum mt76_cipher_type' to different enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion] return MT_CIPHER_NONE; ~~~~~~ ^~~~~~~~~~~~~~ Fixes: c368362c36d3 ("mt76: fix iv and CCMP header insertion") Signed-off-by: Sean Wang Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 3a41d47d19eeafc58622576a4135fcdecf53dbc5 Author: Leon Yen Date: Thu Jul 8 12:29:06 2021 +0800 mt76: connac: fix mt76_connac_gtk_rekey_tlv usage [ Upstream commit d741abeafa47a7331cd4fe526e44db4ad3da0f62 ] The mistaken structure is introduced since we added the GTK rekey offload to mt7663. The patch fixes mt76_connac_gtk_rekey_tlv structure according to the MT7663 and MT7921 firmware we have submitted into linux-firmware.git. Fixes: b47e21e75c80 ("mt76: mt7615: add gtk rekey offload support") Signed-off-by: Sean Wang Signed-off-by: Leon Yen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 93b3fa91782c7df56aea291f5385ae041625e385 Author: Dan Carpenter Date: Fri Jun 25 17:58:54 2021 +0300 mt76: mt7915: fix info leak in mt7915_mcu_set_pre_cal() [ Upstream commit 3924715ffe5e064a85f56490f77b7b2084230800 ] Zero out all the unused members of "req" so that we don't disclose stack information. Fixes: 495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data") Signed-off-by: Dan Carpenter Acked-by: Felix Fietkau Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 31a67f6c7c932efee5607541714dd4eb344a7626 Author: Lorenzo Bianconi Date: Mon Jun 21 23:53:22 2021 +0200 mt76: mt7615: fix endianness warning in mt7615_mac_write_txwi [ Upstream commit d81bfb41e30c42531536c5d2baa4d275a8309715 ] Fix the following sparse warning in mt7615_mac_write_txwi routine: drivers/net/wireless/mediatek/mt76/mt7615/mac.c:758:17: warning: incorrect type in assignment expected restricted __le32 [usertype] got unsigned long Fixes: 04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets") Fixes: d4bf77bd74930 ("mt76: mt7615: introduce mt7663u support to mt7615_write_txwi") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit b442c8a72323ece31302ea4a3c2ec8977e1cef94 Author: Lorenzo Bianconi Date: Mon Jun 21 11:18:58 2021 +0200 mt76: mt7921: fix endianness warning in mt7921_update_txs [ Upstream commit 7fc167bbc9296e6aeaaa4063db3639e8a3db75f6 ] Fix the following sparse warning in mt7921_update_txs routine: drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31: warning: restricted __le32 degrades to integer Fixes: e5bca8c5d2cd3 ("mt76: mt7921: improve code readability for mt7921_update_txs") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 07b8ee848c285bb1a3466ce51dd3b4c0d04db9f0 Author: Lorenzo Bianconi Date: Mon Jun 21 10:21:31 2021 +0200 mt76: mt7915: fix endianness warning in mt7915_mac_add_txs_skb [ Upstream commit 08b3c8da87aed4200dab00906f149d675ca90f23 ] Fix the following sparse warning in mt7915_mac_add_txs_skb routine: drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:29: warning: cast to restricted __le32 drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:23: warning: restricted __le32 degrades to integer Fixes: 3de4cb1756565 ("mt76: mt7915: add support for tx status reporting") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 5d1a084a476c9c1b1a3af8fd2fc9e1d74df21de5 Author: Lorenzo Bianconi Date: Sat Jun 19 20:18:19 2021 +0200 mt76: mt7921: fix endianness in mt7921_mcu_tx_done_event [ Upstream commit df040215c077de0c13aab12c222bd0360a0d3988 ] Fix endianness in mt7921_mcu_tx_done_event event reported by the firmware. Fixes: 3cce2b98e0241 ("mt76: mt7921: introduce mac tx done handling") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 07b20f34a9656083b164681f927de4c6861d58c1 Author: Lang Yu Date: Mon Oct 11 13:57:25 2021 +0800 drm/amdkfd: Fix an inappropriate error handling in allloc memory of gpu [ Upstream commit 5aeeac6fa38fca450faed9770f75b1470c0e2073 ] We should unreference a gem object instead of an amdgpu bo here. Fixes: fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs") Signed-off-by: Lang Yu Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2c57dbc453d3f7b2208ace69803820a27131ba28 Author: Rafael J. Wysocki Date: Sat Oct 16 12:11:08 2021 +0200 ACPI: PM: Fix sharing of wakeup power resources [ Upstream commit a2d7b2e004af6b09f21ac3d10f8f4456c16a8ddf ] If an ACPI wakeup power resource is shared between multiple devices, it may not be managed correctly. Suppose, for example, that two devices, A and B, share a wakeup power resource P whose wakeup_enabled flag is 0 initially. Next, suppose that wakeup power is enabled for A and B, in this order, and disabled for B. When wakeup power is enabled for A, P will be turned on and its wakeup_enabled flag will be set. Next, when wakeup power is enabled for B, P will not be touched, because its wakeup_enabled flag is set. Now, when wakeup power is disabled for B, P will be turned off which is incorrect, because A will still need P in order to signal wakeup. Moreover, if wakeup power is enabled for A and then disabled for B, the latter will cause P to be turned off incorrectly (it will be still needed by A), because acpi_disable_wakeup_device_power() is allowed to manipulate power resources when the wakeup.prepare_count counter of the given device is 0. While the first issue could be addressed by changing the wakeup_enabled power resource flag into a counter, addressing the second one requires modifying acpi_disable_wakeup_device_power() to do nothing when the target device's wakeup.prepare_count reference counter is zero and that would cause the new counter to be redundant. Namely, if acpi_disable_wakeup_device_power() is modified as per the above, every change of the new counter following a wakeup.prepare_count change would be reflected by the analogous change of the main reference counter of the given power resource. Accordingly, modify acpi_disable_wakeup_device_power() to do nothing when the target device's wakeup.prepare_count reference counter is zero and drop the power resource wakeup_enabled flag altogether. While at it, ensure that all of the power resources that can be turned off will be turned off when disabling device wakeup due to a power resource manipulation error, to prevent energy from being wasted. Fixes: b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit f04fab5d90fa5d923fc252e3785d57232ec23557 Author: Rafael J. Wysocki Date: Fri Oct 15 19:01:28 2021 +0200 ACPI: PM: Turn off unused wakeup power resources [ Upstream commit 7a63296d6f579a02b2675b4b0fe5b1cd3235e8d3 ] If an ACPI power resource is found to be "on" during the initialization of the list of wakeup power resources of a device, it is reference counted and its wakeup_enabled flag is set, which is problematic if the deivce in question is the only user of the given power resource, it is never runtime-suspended and it is not allowed to wake up the system from sleep, because in that case the given power resource will stay "on" until the system reboots and energy will be wasted. It is better to simply turn off wakeup power resources that are "on" during the initialization unless their reference counters are not zero, because that may be the only opportunity to prevent them from staying in the "on" state all the time. Fixes: b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account") Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit bc568fe55a17695169905c6f371f8f5d407b9967 Author: Nathan Chancellor Date: Mon Oct 18 11:25:37 2021 -0700 platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning [ Upstream commit fd96e35ea7b95f1e216277805be89d66e4ae962d ] A new warning in clang points out a use of bitwise OR with boolean expressions in this driver: drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] else if ((strlencmp(cmd, "level disengaged") == 0) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning 1 error generated. This should clearly be a logical OR so change it to fix the warning. Fixes: fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver") Link: https://github.com/ClangBuiltLinux/linux/issues/1476 Reported-by: Tor Vic Signed-off-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Link: https://lore.kernel.org/r/20211018182537.2316800-1-nathan@kernel.org Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 77de203d9a4f408348127af0e3d29818f6207948 Author: Michael Schmitz Date: Tue Oct 19 19:13:21 2021 +1300 block: ataflop: fix breakage introduced at blk-mq refactoring [ Upstream commit 86d46fdaa12ae5befc16b8d73fc85a3ca0399ea6 ] Refactoring of the Atari floppy driver when converting to blk-mq has broken the state machine in not-so-subtle ways: finish_fdc() must be called when operations on the floppy device have completed. This is crucial in order to relase the ST-DMA lock, which protects against concurrent access to the ST-DMA controller by other drivers (some DMA related, most just related to device register access - broken beyond compare, I know). When rewriting the driver's old do_request() function, the fact that finish_fdc() was called only when all queued requests had completed appears to have been overlooked. Instead, the new request function calls finish_fdc() immediately after the last request has been queued. finish_fdc() executes a dummy seek after most requests, and this overwrites the state machine's interrupt hander that was set up to wait for completion of the read/write request just prior. To make matters worse, finish_fdc() is called before device interrupts are re-enabled, making certain that the read/write interupt is missed. Shifting the finish_fdc() call into the read/write request completion handler ensures the driver waits for the request to actually complete. With a queue depth of 2, we won't see long request sequences, so calling finish_fdc() unconditionally just adds a little overhead for the dummy seeks, and keeps the code simple. While we're at it, kill ataflop_commit_rqs() which does nothing but run finish_fdc() unconditionally, again likely wiping out an in-flight request. Signed-off-by: Michael Schmitz Fixes: 6ec3938cff95 ("ataflop: convert to blk-mq") CC: linux-block@vger.kernel.org CC: Tetsuo Handa Link: https://lore.kernel.org/r/20211019061321.26425-1-schmitzmic@gmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit d43d31346658ba5084782bc1a28b1497facc1c17 Author: Christophe JAILLET Date: Sat Oct 16 08:21:44 2021 +0200 mmc: mxs-mmc: disable regulator on error and in the remove function [ Upstream commit ce5f6c2c9b0fcb4094f8e162cfd37fb4294204f7 ] The 'reg_vmmc' regulator is enabled in the probe. It is never disabled. Neither in the error handling path of the probe nor in the remove function. Register a devm_action to disable it when needed. Fixes: 4dc5a79f1350 ("mmc: mxs-mmc: enable regulator for mmc slot") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/4aadb3c97835f7b80f00819c3d549e6130384e67.1634365151.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 8901914cdbd47e7238748dc380f9455ebf750175 Author: Sean Young Date: Wed Oct 13 09:14:10 2021 +0100 media: ir_toy: assignment to be16 should be of correct type [ Upstream commit febfe985fc2ea052a363f6525ff624b8efd5273c ] commit f0c15b360fb6 ("media: ir_toy: prevent device from hanging during transmit") removed a cpu_to_be16() cast, which causes a sparse warning. Fixes: f0c15b360fb6 ("media: ir_toy: prevent device from hanging during transmit") Reported-by: Hans Verkuil Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 146e4bf44d61c164c194a4e749afff521a0cdd2d Author: Randy Dunlap Date: Sun Oct 10 20:38:36 2021 +0100 media: ivtv: fix build for UML [ Upstream commit 6cb67bea945bdf0ad40e633cd2d9fbeb0855675b ] Prevent the use of page table macros and types from 2 conflicting places. This fixes multiple build errors and warnings, e.g.: ../arch/x86/include/asm/pgtable_64_types.h:21:34: error: conflicting types for ‘pte_t’ typedef struct { pteval_t pte; } pte_t; ^~~~~ In file included from ../include/linux/mm_types_task.h:16:0, from ../include/linux/mm_types.h:5, from ../include/linux/buildid.h:5, from ../include/linux/module.h:14, from ../drivers/media/pci/ivtv/ivtv-driver.h:40, from ../drivers/media/pci/ivtv/ivtvfb.c:29: ../arch/um/include/asm/page.h:57:39: note: previous declaration of ‘pte_t’ was here typedef struct { unsigned long pte; } pte_t; ../arch/x86/include/asm/pgtable_types.h:284:43: error: expected ‘)’ before ‘prot’ static inline pgprot_t pgprot_nx(pgprot_t prot) ^ ../include/linux/pgtable.h:914:26: note: in definition of macro ‘pgprot_nx’ #define pgprot_nx(prot) (prot) ^~~~ In file included from ../arch/x86/include/asm/memtype.h:6:0, from ../drivers/media/pci/ivtv/ivtvfb.c:40: ../arch/x86/include/asm/pgtable_types.h:288:0: warning: "pgprot_nx" redefined #define pgprot_nx pgprot_nx ../arch/x86/include/asm/page_types.h:11:0: warning: "PAGE_SIZE" redefined #define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT) In file included from ../include/linux/mm_types_task.h:16:0, from ../include/linux/mm_types.h:5, from ../include/linux/buildid.h:5, from ../include/linux/module.h:14, from ../drivers/media/pci/ivtv/ivtv-driver.h:40, from ../drivers/media/pci/ivtv/ivtvfb.c:29: ../arch/um/include/asm/page.h:14:0: note: this is the location of the previous definition #define PAGE_SIZE (_AC(1, UL) << PAGE_SHIFT) Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap Cc: Johannes Berg Cc: Andy Walls Cc: linux-um@lists.infradead.org Cc: Richard Weinberger Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 471ed2202bd3d42ab817d77140ef163c3f13ced1 Author: jason-jh.lin Date: Wed Sep 29 15:08:07 2021 +0800 mailbox: Remove WARN_ON for async_cb.cb in cmdq_exec_done [ Upstream commit ce1537fe288469bf68ee0aabdb860a790b4755ef ] Because mtk_drm_crtc_update_config is not using cmdq_pkt_flush_async, it won't have pkt->async_cb.cb anymore. So remove the WARN_ON check of pkt->async_cb.cb at cmdq_exec_done. Fixes: 1b6b0ce2240e ("mailbox: mtk-cmdq: Use mailbox rx_callback") Signed-off-by: jason-jh.lin Reviewed-by: Chun-Kuang Hu Tested-by: Enric Balletbo i Serra Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 4437f3ead9e85c35fe0e3adfb98c0b97eaa267eb Author: Jakub Kicinski Date: Fri Oct 15 06:37:39 2021 -0700 net: stream: don't purge sk_error_queue in sk_stream_kill_queues() [ Upstream commit 24bcbe1cc69fa52dc4f7b5b2456678ed464724d8 ] sk_stream_kill_queues() can be called on close when there are still outstanding skbs to transmit. Those skbs may try to queue notifications to the error queue (e.g. timestamps). If sk_stream_kill_queues() purges the queue without taking its lock the queue may get corrupted, and skbs leaked. This shows up as a warning about an rmem leak: WARNING: CPU: 24 PID: 0 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x... The leak is always a multiple of 0x300 bytes (the value is in %rax on my builds, so RAX: 0000000000000300). 0x300 is truesize of an empty sk_buff. Indeed if we dump the socket state at the time of the warning the sk_error_queue is often (but not always) corrupted. The ->next pointer points back at the list head, but not the ->prev pointer. Indeed we can find the leaked skb by scanning the kernel memory for something that looks like an skb with ->sk = socket in question, and ->truesize = 0x300. The contents of ->cb[] of the skb confirms the suspicion that it is indeed a timestamp notification (as generated in __skb_complete_tx_timestamp()). Removing purging of sk_error_queue should be okay, since inet_sock_destruct() does it again once all socket refs are gone. Eric suggests this may cause sockets that go thru disconnect() to maintain notifications from the previous incarnations of the socket, but that should be okay since the race was there anyway, and disconnect() is not exactly dependable. Thanks to Jonathan Lemon and Omar Sandoval for help at various stages of tracing the issue. Fixes: cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets") Signed-off-by: Jakub Kicinski Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit eed8766a99412d4abbdd5035a48f78eb940effa0 Author: Dan Carpenter Date: Wed Oct 13 11:13:15 2021 +0300 drm/msm: uninitialized variable in msm_gem_import() [ Upstream commit 2203bd0e5c12ffc53ffdd4fbd7b12d6ba27e0424 ] The msm_gem_new_impl() function cleans up after itself so there is no need to call drm_gem_object_put(). Conceptually, it does not make sense to call a kref_put() function until after the reference counting has been initialized which happens immediately after this call in the drm_gem_(private_)object_init() functions. In the msm_gem_import() function the "obj" pointer is uninitialized, so it will lead to a crash. Fixes: 05b849111c07 ("drm/msm: prime support") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211013081315.GG6010@kili Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit fe7dcde39db765db1344083dc2c870077ae3527d Author: Dan Carpenter Date: Wed Oct 13 11:11:33 2021 +0300 drm/msm: fix potential NULL dereference in cleanup [ Upstream commit 027d052a36e56789a2134772bacb4fd0860f03a3 ] The "msm_obj->node" list needs to be initialized earlier so that the list_del() in msm_gem_free_object() doesn't experience a NULL pointer dereference. Fixes: 6ed0897cd800 ("drm/msm: Fix debugfs deadlock") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211013081133.GF6010@kili Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 5c13d4be499c4d97e09f21c7a5a9dea00d930d2b Author: Dan Carpenter Date: Mon Oct 4 13:38:06 2021 +0300 drm/msm: potential error pointer dereference in init() [ Upstream commit b6816441a14bbe356ba8590de79cfea2de6a085c ] The msm_iommu_new() returns error pointers on failure so check for that to avoid an Oops. Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization") Signed-off-by: Dan Carpenter Reviewed-by: Abhinav Kumar Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211004103806.GD25015@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 723d2914d817551cb72971646fef4ecc5371624f Author: Dan Carpenter Date: Mon Oct 4 16:45:30 2021 +0300 drm/msm: Fix potential Oops in a6xx_gmu_rpmh_init() [ Upstream commit 3d91e50ff58364f6572ad268b508175d27800e51 ] There are two problems here: 1) The "seqptr" is used uninitalized when we free it at the end. 2) The a6xx_gmu_get_mmio() function returns error pointers. It never returns true. Fixes: 64245fc55172 ("drm/msm/a6xx: use AOP-initialized PDC for a650") Fixes: f8fc924e088e ("drm/msm/a6xx: Fix PDC register overlap") Signed-off-by: Dan Carpenter Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20211004134530.GB11689@kili Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit bc4555ffd158eda51518e96ab7492078a00b9a96 Author: Ziyang Xuan Date: Fri Oct 15 10:45:04 2021 +0800 thermal/core: fix a UAF bug in __thermal_cooling_device_register() [ Upstream commit 0a5c26712f963f0500161a23e0ffff8d29f742ab ] When device_register() return failed, program will goto out_kfree_type to release 'cdev->device' by put_device(). That will call thermal_release() to free 'cdev'. But the follow-up processes access 'cdev' continually. That trggers the UAF bug. ==================================================================== BUG: KASAN: use-after-free in __thermal_cooling_device_register+0x75b/0xa90 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? __thermal_cooling_device_register+0x75b/0xa90 kasan_report.cold+0x7f/0x11b ? __thermal_cooling_device_register+0x75b/0xa90 __thermal_cooling_device_register+0x75b/0xa90 ? memset+0x20/0x40 ? __sanitizer_cov_trace_pc+0x1d/0x50 ? __devres_alloc_node+0x130/0x180 devm_thermal_of_cooling_device_register+0x67/0xf0 max6650_probe.cold+0x557/0x6aa ...... Freed by task 258: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 thermal_release+0xa0/0x110 device_release+0xa7/0x240 kobject_put+0x1ce/0x540 put_device+0x20/0x30 __thermal_cooling_device_register+0x731/0xa90 devm_thermal_of_cooling_device_register+0x67/0xf0 max6650_probe.cold+0x557/0x6aa [max6650] Do not use 'cdev' again after put_device() to fix the problem like doing in thermal_zone_device_register(). [dlezcano]: as requested by Rafael, change the affectation into two statements. Fixes: 584837618100 ("thermal/drivers/core: Use a char pointer for the cooling device name") Signed-off-by: Ziyang Xuan Reported-by: kernel test robot Link: https://lore.kernel.org/r/20211015024504.947520-1-william.xuanziyang@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 650d1a2865e44417d074149cb2cb0e49750b7531 Author: Ovidiu Panait Date: Sun Oct 10 19:36:42 2021 +0300 crypto: octeontx2 - set assoclen in aead_do_fallback() [ Upstream commit 06f6e365e2ecf799c249bb464aa9d5f055e88b56 ] Currently, in case of aead fallback, no associated data info is set in the fallback request. To fix this, call aead_request_set_ad() to pass the assoclen. Fixes: 6f03f0e8b6c8 ("crypto: octeontx2 - register with linux crypto framework") Signed-off-by: Ovidiu Panait Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 24dfa642985f4c4a324928003781dbf7724dec6f Author: Eric Dumazet Date: Thu Oct 14 06:41:26 2021 -0700 tcp: switch orphan_count to bare per-cpu counters [ Upstream commit 19757cebf0c5016a1f36f7fe9810a9f0b33c0832 ] Use of percpu_counter structure to track count of orphaned sockets is causing problems on modern hosts with 256 cpus or more. Stefan Bach reported a serious spinlock contention in real workloads, that I was able to reproduce with a netfilter rule dropping incoming FIN packets. 53.56% server [kernel.kallsyms] [k] queued_spin_lock_slowpath | ---queued_spin_lock_slowpath | --53.51%--_raw_spin_lock_irqsave | --53.51%--__percpu_counter_sum tcp_check_oom | |--39.03%--__tcp_close | tcp_close | inet_release | inet6_release | sock_close | __fput | ____fput | task_work_run | exit_to_usermode_loop | do_syscall_64 | entry_SYSCALL_64_after_hwframe | __GI___libc_close | --14.48%--tcp_out_of_resources tcp_write_timeout tcp_retransmit_timer tcp_write_timer_handler tcp_write_timer call_timer_fn expire_timers __run_timers run_timer_softirq __softirqentry_text_start As explained in commit cf86a086a180 ("net/dst: use a smaller percpu_counter batch for dst entries accounting"), default batch size is too big for the default value of tcp_max_orphans (262144). But even if we reduce batch sizes, there would still be cases where the estimated count of orphans is beyond the limit, and where tcp_too_many_orphans() has to call the expensive percpu_counter_sum_positive(). One solution is to use plain per-cpu counters, and have a timer to periodically refresh this cache. Updating this cache every 100ms seems about right, tcp pressure state is not radically changing over shorter periods. percpu_counter was nice 15 years ago while hosts had less than 16 cpus, not anymore by current standards. v2: Fix the build issue for CONFIG_CRYPTO_DEV_CHELSIO_TLS=m, reported by kernel test robot Remove unused socket argument from tcp_too_many_orphans() Fixes: dd24c00191d5 ("net: Use a percpu_counter for orphan_count") Signed-off-by: Eric Dumazet Reported-by: Stefan Bach Cc: Neal Cardwell Acked-by: Neal Cardwell Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f270511247a5b6257b84db17883e0b1189bf5e16 Author: Qi Zheng Date: Wed Sep 29 15:02:17 2021 -0700 x86: Fix get_wchan() to support the ORC unwinder [ Upstream commit bc9bbb81730ea667c31c5b284f95ee312bab466f ] Currently, the kernel CONFIG_UNWINDER_ORC option is enabled by default on x86, but the implementation of get_wchan() is still based on the frame pointer unwinder, so the /proc//wchan usually returned 0 regardless of whether the task is running. Reimplement get_wchan() by calling stack_trace_save_tsk(), which is adapted to the ORC and frame pointer unwinders. Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder") Signed-off-by: Qi Zheng Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211008111626.271115116@infradead.org Signed-off-by: Sasha Levin commit 5652137ef6536d3f5c154e38682bebafe2454048 Author: Randy Dunlap Date: Wed Oct 13 22:06:06 2021 -0700 net: tulip: winbond-840: fix build for UML [ Upstream commit a3d708925fcca1a2f7219bc9ce93e6341f85c1e0 ] On i386, when builtin (not a loadable module), the winbond-840 driver inspects boot_cpu_data to see what CPU family it is running on, and then acts on that data. The "family" struct member (x86) does not exist when running on UML, so prevent that test and do the default action. Prevents this build error on UML + i386: ../drivers/net/ethernet/dec/tulip/winbond-840.c: In function ‘init_registers’: ../drivers/net/ethernet/dec/tulip/winbond-840.c:882:19: error: ‘struct cpuinfo_um’ has no member named ‘x86’ if (boot_cpu_data.x86 <= 4) { Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap Cc: linux-um@lists.infradead.org Cc: Jeff Dike Cc: Richard Weinberger Cc: Anton Ivanov Link: https://lore.kernel.org/r/20211014050606.7288-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 638d1283bbfcfaa6ecb31a0114bd276c6c599a3e Author: Randy Dunlap Date: Wed Oct 13 22:05:00 2021 -0700 net: fealnx: fix build for UML [ Upstream commit cd2621d07d517473611b170c69beb6524c677740 ] On i386, when builtin (not a loadable module), the fealnx driver inspects boot_cpu_data to see what CPU family it is running on, and then acts on that data. The "family" struct member (x86) does not exist when running on UML, so prevent that test and do the default action. Prevents this build error on UML + i386: ../drivers/net/ethernet/fealnx.c: In function ‘netdev_open’: ../drivers/net/ethernet/fealnx.c:861:19: error: ‘struct cpuinfo_um’ has no member named ‘x86’ Fixes: 68f5d3f3b654 ("um: add PCI over virtio emulation driver") Signed-off-by: Randy Dunlap Cc: linux-um@lists.infradead.org Cc: Jeff Dike Cc: Richard Weinberger Cc: Anton Ivanov Link: https://lore.kernel.org/r/20211014050500.5620-1-rdunlap@infradead.org Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 25d40b828fb855ee62e1039c65a666c9afd60786 Author: Zhang Qiao Date: Wed Sep 15 14:40:30 2021 +0800 kernel/sched: Fix sched_fork() access an invalid sched_task_group [ Upstream commit 4ef0c5c6b5ba1f38f0ea1cedad0cad722f00c14a ] There is a small race between copy_process() and sched_fork() where child->sched_task_group point to an already freed pointer. parent doing fork() | someone moving the parent | to another cgroup -------------------------------+------------------------------- copy_process() + dup_task_struct()<1> parent move to another cgroup, and free the old cgroup. <2> + sched_fork() + __set_task_cpu()<3> + task_fork_fair() + sched_slice()<4> In the worst case, this bug can lead to "use-after-free" and cause panic as shown above: (1) parent copy its sched_task_group to child at <1>; (2) someone move the parent to another cgroup and free the old cgroup at <2>; (3) the sched_task_group and cfs_rq that belong to the old cgroup will be accessed at <3> and <4>, which cause a panic: [] BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 [] PGD 8000001fa0a86067 P4D 8000001fa0a86067 PUD 2029955067 PMD 0 [] Oops: 0000 [#1] SMP PTI [] CPU: 7 PID: 648398 Comm: ebizzy Kdump: loaded Tainted: G OE --------- - - 4.18.0.x86_64+ #1 [] RIP: 0010:sched_slice+0x84/0xc0 [] Call Trace: [] task_fork_fair+0x81/0x120 [] sched_fork+0x132/0x240 [] copy_process.part.5+0x675/0x20e0 [] ? __handle_mm_fault+0x63f/0x690 [] _do_fork+0xcd/0x3b0 [] do_syscall_64+0x5d/0x1d0 [] entry_SYSCALL_64_after_hwframe+0x65/0xca [] RIP: 0033:0x7f04418cd7e1 Between cgroup_can_fork() and cgroup_post_fork(), the cgroup membership and thus sched_task_group can't change. So update child's sched_task_group at sched_post_fork() and move task_fork() and __set_task_cpu() (where accees the sched_task_group) from sched_fork() to sched_post_fork(). Fixes: 8323f26ce342 ("sched: Fix race in task_group") Signed-off-by: Zhang Qiao Signed-off-by: Peter Zijlstra (Intel) Acked-by: Tejun Heo Link: https://lkml.kernel.org/r/20210915064030.2231-1-zhangqiao22@huawei.com Signed-off-by: Sasha Levin commit 27d16d8ec1a80373ebbc1a5dd153e878941f6dcb Author: Sven Eckelmann Date: Tue Jun 11 19:21:31 2019 +0200 ath10k: fix max antenna gain unit [ Upstream commit 0a491167fe0cf9f26062462de2a8688b96125d48 ] Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB steps). This isn't the case for max_antenna_gain - which is still expected by the firmware as dB. The firmware is converting it from dB to the internal (twicepower) representation when it calculates the limits of a channel. This can be seen in tpc_stats when configuring "12" as max_antenna_gain. Instead of the expected 12 (6 dB), the tpc_stats shows 24 (12 dB). Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057. Fixes: 02256930d9b8 ("ath10k: use proper tx power unit") Signed-off-by: Sven Eckelmann Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20190611172131.6064-1-sven@narfation.org Signed-off-by: Sasha Levin commit a57627b2ea67ed9731692a8ea018d2f5b94e52d8 Author: Zev Weiss Date: Tue Sep 28 02:22:38 2021 -0700 hwmon: (pmbus/lm25066) Let compiler determine outer dimension of lm25066_coeff [ Upstream commit b7931a7b0e0df4d2a25fedd895ad32c746b77bc1 ] Maintaining this manually is error prone (there are currently only five chips supported, not six); gcc can do it for us automatically. Signed-off-by: Zev Weiss Fixes: 666c14906b49 ("hwmon: (pmbus/lm25066) Drop support for LM25063") Link: https://lore.kernel.org/r/20210928092242.30036-5-zev@bewilderbeest.net Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 4b898aa013d87e4157683ac177eaa58c44fb579d Author: Yang Yingliang Date: Tue Oct 12 19:27:58 2021 +0800 hwmon: Fix possible memleak in __hwmon_device_register() [ Upstream commit ada61aa0b1184a8fda1a89a340c7d6cc4e59aee5 ] I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888102740438 (size 8): comm "27", pid 859, jiffies 4295031351 (age 143.992s) hex dump (first 8 bytes): 68 77 6d 6f 6e 30 00 00 hwmon0.. backtrace: [<00000000544b5996>] __kmalloc_track_caller+0x1a6/0x300 [<00000000df0d62b9>] kvasprintf+0xad/0x140 [<00000000d3d2a3da>] kvasprintf_const+0x62/0x190 [<000000005f8f0f29>] kobject_set_name_vargs+0x56/0x140 [<00000000b739e4b9>] dev_set_name+0xb0/0xe0 [<0000000095b69c25>] __hwmon_device_register+0xf19/0x1e50 [hwmon] [<00000000a7e65b52>] hwmon_device_register_with_info+0xcb/0x110 [hwmon] [<000000006f181e86>] devm_hwmon_device_register_with_info+0x85/0x100 [hwmon] [<0000000081bdc567>] tmp421_probe+0x2d2/0x465 [tmp421] [<00000000502cc3f8>] i2c_device_probe+0x4e1/0xbb0 [<00000000f90bda3b>] really_probe+0x285/0xc30 [<000000007eac7b77>] __driver_probe_device+0x35f/0x4f0 [<000000004953d43d>] driver_probe_device+0x4f/0x140 [<000000002ada2d41>] __device_attach_driver+0x24c/0x330 [<00000000b3977977>] bus_for_each_drv+0x15d/0x1e0 [<000000005bf2a8e3>] __device_attach+0x267/0x410 When device_register() returns an error, the name allocated in dev_set_name() will be leaked, the put_device() should be used instead of calling hwmon_dev_release() to give up the device reference, then the name will be freed in kobject_cleanup(). Reported-by: Hulk Robot Fixes: bab2243ce189 ("hwmon: Introduce hwmon_device_register_with_groups") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211012112758.2681084-1-yangyingliang@huawei.com Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit b9e2477e4de48c59560be4ffa3d3da74d08f12f7 Author: Daniel Borkmann Date: Mon Oct 11 14:12:35 2021 +0200 net, neigh: Fix NTF_EXT_LEARNED in combination with NTF_USE [ Upstream commit e4400bbf5b15750e1b59bf4722d18d99be60c69f ] The NTF_EXT_LEARNED neigh flag is usually propagated back to user space upon dump of the neighbor table. However, when used in combination with NTF_USE flag this is not the case despite exempting the entry from the garbage collector. This results in inconsistent state since entries are typically marked in neigh->flags with NTF_EXT_LEARNED, but here they are not. Fix it by propagating the creation flag to ___neigh_create(). Before fix: # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE [...] After fix: # ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn # ./ip/ip n 192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE [...] Fixes: 9ce33e46531d ("neighbour: support for NTF_EXT_LEARNED flag") Signed-off-by: Daniel Borkmann Acked-by: Roopa Prabhu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 646dabb85ef7f11ce8fe8139e66dec61ff67cc07 Author: Dan Carpenter Date: Mon Oct 11 15:39:12 2021 +0300 memstick: jmb38x_ms: use appropriate free function in jmb38x_ms_alloc_host() [ Upstream commit beae4a6258e64af609ad5995cc6b6056eb0d898e ] The "msh" pointer is device managed, meaning that memstick_alloc_host() calls device_initialize() on it. That means that it can't be free using kfree() but must instead be freed with memstick_free_host(). Otherwise it leads to a tiny memory leak of device resources. Fixes: 60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20211011123912.GD15188@kili Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit d288021988e0c3028a223d18c5dd462744b21e0e Author: Arnd Bergmann Date: Mon Sep 27 11:44:47 2021 +0200 memstick: avoid out-of-range warning [ Upstream commit 4853396f03c3019eccf5cd113e464231e9ddf0b3 ] clang-14 complains about a sanity check that always passes when the page size is 64KB or larger: drivers/memstick/core/ms_block.c:1739:21: error: result of comparison of constant 65536 with expression of type 'unsigned short' is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (msb->page_size > PAGE_SIZE) { ~~~~~~~~~~~~~~ ^ ~~~~~~~~~ This is fine, it will still work on all architectures, so just shut up that warning with a cast. Fixes: 0ab30494bc4f ("memstick: add support for legacy memorysticks") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20210927094520.696665-1-arnd@kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit a5b536f042a46bdbf81dd8bb40803e51858fec2a Author: Tony Lindgren Date: Tue Sep 21 14:00:26 2021 +0300 mmc: sdhci-omap: Fix context restore [ Upstream commit d806e334d0390502cd2a820ad33d65d7f9bba618 ] We need to restore context in a specified order with HCTL set in two phases. This is similar to what omap_hsmmc_context_restore() is doing. Otherwise SDIO can stop working on resume. And for PM runtime and SDIO cards, we need to also save SYSCTL, IE and ISE. This should not be a problem currently, and these patches can be applied whenever suitable. Fixes: ee0f309263a6 ("mmc: sdhci-omap: Add Support for Suspend/Resume") Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210921110029.21944-3-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit eab2681ca5bb4e0ce8e63e995ba9b41ce7d5abe5 Author: Tony Lindgren Date: Tue Sep 21 14:00:25 2021 +0300 mmc: sdhci-omap: Fix NULL pointer exception if regulator is not configured [ Upstream commit 8e0e7bd38b1ec7f9e5d18725ad41828be4e09859 ] If sdhci-omap is configured for an unused device instance and the device is not set as disabled, we can get a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 00000045 ... (regulator_set_voltage) from [] (mmc_regulator_set_ocr+0x44/0xd0) (mmc_regulator_set_ocr) from [] (sdhci_set_ios+0xa4/0x490) (sdhci_set_ios) from [] (sdhci_omap_set_ios+0x124/0x160) (sdhci_omap_set_ios) from [] (mmc_power_up.part.0+0x3c/0x154) (mmc_power_up.part.0) from [] (mmc_start_host+0x88/0x9c) (mmc_start_host) from [] (mmc_add_host+0x58/0x7c) (mmc_add_host) from [] (__sdhci_add_host+0xf0/0x22c) (__sdhci_add_host) from [] (sdhci_omap_probe+0x318/0x72c) (sdhci_omap_probe) from [] (platform_probe+0x58/0xb8) AFAIK we are not seeing this with the devices configured in the mainline kernel but this can cause issues for folks bringing up their boards. Fixes: 7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver") Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20210921110029.21944-2-tony@atomide.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit e1628b6b6b7d21bf41a2dab11470668ff02bab65 Author: Catherine Sullivan Date: Mon Oct 11 08:36:50 2021 -0700 gve: Track RX buffer allocation failures [ Upstream commit 1b4d1c9bab091ac6e20a3ff80c30c5cefe192bf4 ] The rx_buf_alloc_fail counter wasn't getting updated. Fixes: 433e274b8f7b0 ("gve: Add stats for gve.") Signed-off-by: Catherine Sullivan Signed-off-by: Jeroen de Borst Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 89dda8da289e7ea7c2ec0c496269018bde1015c9 Author: John Fraker Date: Mon Oct 11 08:36:47 2021 -0700 gve: Recover from queue stall due to missed IRQ [ Upstream commit 87a7f321bb6a45e54b7d6c90d032ee5636a6ad97 ] Don't always reset the driver on a TX timeout. Attempt to recover by kicking the queue in case an IRQ was missed. Fixes: 9e5f7d26a4c08 ("gve: Add workqueue and reset support") Signed-off-by: John Fraker Signed-off-by: David Awogbemila Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b8ba47d732d1084e71056d15add93ef11115a31e Author: Dan Carpenter Date: Wed Oct 6 10:36:22 2021 +0300 b43: fix a lower bounds test [ Upstream commit 9b793db5fca44d01f72d3564a168171acf7c4076 ] The problem is that "channel" is an unsigned int, when it's less 5 the value of "channel - 5" is not a negative number as one would expect but is very high positive value instead. This means that "start" becomes a very high positive value. The result of that is that we never enter the "for (i = start; i <= end; i++) {" loop. Instead of storing the result from b43legacy_radio_aci_detect() it just uses zero. Fixes: ef1a628d83fc ("b43: Implement dynamic PHY API") Signed-off-by: Dan Carpenter Acked-by: Michael Büsch Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211006073621.GE8404@kili Signed-off-by: Sasha Levin commit 7d14ae503c2420c377afa31923b9af657bb6fac9 Author: Dan Carpenter Date: Wed Oct 6 10:35:42 2021 +0300 b43legacy: fix a lower bounds test [ Upstream commit c1c8380b0320ab757e60ed90efc8b1992a943256 ] The problem is that "channel" is an unsigned int, when it's less 5 the value of "channel - 5" is not a negative number as one would expect but is very high positive value instead. This means that "start" becomes a very high positive value. The result of that is that we never enter the "for (i = start; i <= end; i++) {" loop. Instead of storing the result from b43legacy_radio_aci_detect() it just uses zero. Fixes: 75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices") Signed-off-by: Dan Carpenter Acked-by: Michael Büsch Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211006073542.GD8404@kili Signed-off-by: Sasha Levin commit 84328828d834d174e2818702a16f4671e907e750 Author: THOBY Simon Date: Mon Aug 16 08:10:59 2021 +0000 IMA: block writes of the security.ima xattr with unsupported algorithms [ Upstream commit 50f742dd91474e7f4954bf88d094eede59783883 ] By default, writes to the extended attributes security.ima will be allowed even if the hash algorithm used for the xattr is not compiled in the kernel (which does not make sense because the kernel would not be able to appraise that file as it lacks support for validating the hash). Prevent and audit writes to the security.ima xattr if the hash algorithm used in the new value is not available in the current kernel. Signed-off-by: THOBY Simon Reviewed-by: Lakshmi Ramasubramanian Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit db75642768d258cf8385b2c1379238ebdcc2240b Author: Markus Schneider-Pargmann Date: Thu Sep 30 21:12:42 2021 +0200 hwrng: mtk - Force runtime pm ops for sleep ops [ Upstream commit b6f5f0c8f72d348b2d07b20d7b680ef13a7ffe98 ] Currently mtk_rng_runtime_suspend/resume is called for both runtime pm and system sleep operations. This is wrong as these should only be runtime ops as the name already suggests. Currently freezing the system will lead to a call to mtk_rng_runtime_suspend even if the device currently isn't active. This leads to a clock warning because it is disabled/unprepared although it isn't enabled/prepared currently. This patch fixes this by only setting the runtime pm ops and forces to call the runtime pm ops from the system sleep ops as well if active but not otherwise. Fixes: 81d2b34508c6 ("hwrng: mtk - add runtime PM support") Signed-off-by: Markus Schneider-Pargmann Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 64bf6a3431445f0688a273c6a1186a04be56fc4d Author: Giovanni Cabiddu Date: Tue Sep 28 12:44:30 2021 +0100 crypto: qat - disregard spurious PFVF interrupts [ Upstream commit 18fcba469ba5359c1de7e3fb16f7b9e8cd1b8e02 ] Upon receiving a PFVF message, check if the interrupt bit is set in the message. If it is not, that means that the interrupt was probably triggered by a collision. In this case, disregard the message and re-enable the interrupts. Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV") Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit db60c3b02f4c05090cb31858340b0d995ab102da Author: Giovanni Cabiddu Date: Tue Sep 28 12:44:29 2021 +0100 crypto: qat - detect PFVF collision after ACK [ Upstream commit 9b768e8a3909ac1ab39ed44a3933716da7761a6f ] Detect a PFVF collision between the local and the remote function by checking if the message on the PFVF CSR has been overwritten. This is done after the remote function confirms that the message has been received, by clearing the interrupt bit, or the maximum number of attempts (ADF_IOV_MSG_ACK_MAX_RETRY) to check the CSR has been exceeded. Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV") Signed-off-by: Giovanni Cabiddu Co-developed-by: Marco Chiappero Signed-off-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 693fc7e84bedf12c6e40108a70d327bf8c94dca9 Author: Arnd Bergmann Date: Mon Sep 27 14:18:03 2021 +0200 crypto: ccree - avoid out-of-range warnings from clang [ Upstream commit cfd6fb45cfaf46fa9547421d8da387dc9c7997d4 ] clang points out inconsistencies in the FIELD_PREP() invocation in this driver that result from the 'mask' being a 32-bit value: drivers/crypto/ccree/cc_driver.c:117:18: error: result of comparison of constant 18446744073709551615 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] cache_params |= FIELD_PREP(mask, val); ^~~~~~~~~~~~~~~~~~~~~ include/linux/bitfield.h:94:3: note: expanded from macro 'FIELD_PREP' __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/bitfield.h:52:28: note: expanded from macro '__BF_FIELD_CHECK' BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \ ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This does not happen in other places that just pass a constant here. Work around the warnings by widening the type of the temporary variable. Fixes: 05c2a705917b ("crypto: ccree - rework cache parameters handling") Signed-off-by: Arnd Bergmann Acked-by: Gilad ben-Yossef Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit a0de5d1b841ccf2d4a6cf2824603b6708c49a2d7 Author: Evgeny Novikov Date: Sun Aug 22 11:48:03 2021 +0200 media: dvb-frontends: mn88443x: Handle errors of clk_prepare_enable() [ Upstream commit 69a10678e2fba3d182e78ea041f2d1b1a6058764 ] mn88443x_cmn_power_on() did not handle possible errors of clk_prepare_enable() and always finished successfully so that its caller mn88443x_probe() did not care about failed preparing/enabling of clocks as well. Add missed error handling in both mn88443x_cmn_power_on() and mn88443x_probe(). This required to change the return value of the former from "void" to "int". Found by Linux Driver Verification project (linuxtesting.org). Fixes: 0f408ce8941f ("media: dvb-frontends: add Socionext MN88443x ISDB-S/T demodulator driver") Signed-off-by: Evgeny Novikov Co-developed-by: Kirill Shilimanov Signed-off-by: Kirill Shilimanov Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d16af0011cef6ea1d77551badd21d40a98f78254 Author: Mansur Alisha Shaik Date: Tue Sep 14 05:57:07 2021 +0200 media: venus: fix vpp frequency calculation for decoder [ Upstream commit 1444232152ea33f5ae41fc14bade3e74d642b634 ] In existing video driver implementation vpp frequency calculation in calculate_inst_freq() is always zero because the value of vpp_freq_per_mb is always zero for decoder. Fixed this by correcting the calculating the vpp frequency calculation for decoder. Fixes: 3cfe5815ce0e ("media: venus: Enable low power setting for encoder") Signed-off-by: Mansur Alisha Shaik Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit da821525882fe51c48eb056a9088accd4352adee Author: Pablo Neira Ayuso Date: Sat Sep 25 22:40:26 2021 +0200 netfilter: nft_dynset: relax superfluous check on set updates [ Upstream commit 7b1394892de8d95748d05e3ee41e85edb4abbfa1 ] Relax this condition to make add and update commands idempotent for sets with no timeout. The eval function already checks if the set element timeout is available and updates it if the update command is used. Fixes: 22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 05f2a14a2e4f6e28e0ae81f3263ca2b004bccb90 Author: Peter Zijlstra Date: Tue Sep 28 10:40:21 2021 +0200 rcu: Always inline rcu_dynticks_task*_{enter,exit}() [ Upstream commit 7663ad9a5dbcc27f3090e6bfd192c7e59222709f ] RCU managed to grow a few noinstr violations: vmlinux.o: warning: objtool: rcu_dynticks_eqs_enter()+0x0: call to rcu_dynticks_task_trace_enter() leaves .noinstr.text section vmlinux.o: warning: objtool: rcu_dynticks_eqs_exit()+0xe: call to rcu_dynticks_task_trace_exit() leaves .noinstr.text section Fix them by adding __always_inline to the relevant trivial functions. Also replace the noinstr with __always_inline for the existing rcu_dynticks_task_*() functions since noinstr would force noinline them, even when empty, which seems silly. Fixes: 7d0c9c50c5a1 ("rcu-tasks: Avoid IPIing userspace/idle tasks if kernel is so built") Reported-by: Stephen Rothwell Reviewed-by: Thomas Gleixner Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 8dd1a500b7d898f041935143f4ef0d0504acd922 Author: Yazen Ghannam Date: Tue Oct 5 15:44:19 2021 +0000 EDAC/amd64: Handle three rank interleaving mode [ Upstream commit 9f4873fb6af7966de8fcbd95c36b61351c1c4b1f ] AMD Rome systems and later support interleaving between three identical ranks within a channel. Check for this mode by counting the number of enabled chip selects and comparing their masks. If there are exactly three enabled chip selects and their masks are identical, then three rank interleaving is enabled. The size of a rank is determined from its mask value. However, three rank interleaving doesn't follow the method of swapping an interleave bit with the most significant bit. Rather, the interleave bit is flipped and the most significant bit remains the same. There is only a single interleave bit in this case. Account for this when determining the chip select size by keeping the most significant bit at its original value and ignoring any zero bits. This will return a full bitmask in [MSB:1]. Fixes: e53a3b267fb0 ("EDAC/amd64: Find Chip Select memory size using Address Mask") Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20211005154419.2060504-1-yazen.ghannam@amd.com Signed-off-by: Sasha Levin commit dea84d9cfac21d59b7956c4b8cc0717c1fc2c27b Author: Borislav Petkov Date: Wed Sep 29 16:37:53 2021 +0200 x86/insn: Use get_unaligned() instead of memcpy() [ Upstream commit f96b4675839b66168f5a07bf964dde6c2f1c4885 ] Use get_unaligned() instead of memcpy() to access potentially unaligned memory, which, when accessed through a pointer, leads to undefined behavior. get_unaligned() describes much better what is happening there anyway even if memcpy() does the job. In addition, since perf tool builds with -Werror, it would fire with: util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix': tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed] 10 | const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \ because -Werror=packed would complain if the packed attribute would have no effect on the layout of the structure. In this case, that is intentional so disable the warning only for that compilation unit. That part is Reported-by: Stephen Rothwell No functional changes. Fixes: 5ba1071f7554 ("x86/insn, tools/x86: Fix undefined behavior due to potential unaligned accesses") Suggested-by: Linus Torvalds Signed-off-by: Borislav Petkov Acked-by: Masami Hiramatsu Tested-by: Stephen Rothwell Link: https://lkml.kernel.org/r/YVSsIkj9Z29TyUjE@zn.tnic Signed-off-by: Sasha Levin commit 4a1a695bee9ea469a4cdf0363d33ad652ccdd779 Author: Vincent Donnefort Date: Wed Sep 8 15:05:22 2021 +0100 PM: EM: Fix inefficient states detection [ Upstream commit aa1a43262ad5df010768f69530fa179ff81651d3 ] Currently, a debug message is printed if an inefficient state is detected in the Energy Model. Unfortunately, it won't detect if the first state is inefficient or if two successive states are. Fix this behavior. Fixes: 27871f7a8a34 (PM: Introduce an Energy Model management framework) Signed-off-by: Vincent Donnefort Reviewed-by: Quentin Perret Reviewed-by: Lukasz Luba Reviewed-by: Matthias Kaehlcke Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit e6335aef8b0fe0c2523c201c491dd7453f44554f Author: Linus Lüssing Date: Tue Oct 5 16:55:53 2021 +0300 ath9k: Fix potential interrupt storm on queue reset [ Upstream commit 4925642d541278575ad1948c5924d71ffd57ef14 ] In tests with two Lima boards from 8devices (QCA4531 based) on OpenWrt 19.07 we could force a silent restart of a device with no serial output when we were sending a high amount of UDP traffic (iperf3 at 80 MBit/s in both directions from external hosts, saturating the wifi and causing a load of about 4.5 to 6) and were then triggering an ath9k_queue_reset(). Further debugging showed that the restart was caused by the ath79 watchdog. With disabled watchdog we could observe that the device was constantly going into ath_isr() interrupt handler and was returning early after the ATH_OP_HW_RESET flag test, without clearing any interrupts. Even though ath9k_queue_reset() calls ath9k_hw_kill_interrupts(). With JTAG we could observe the following race condition: 1) ath9k_queue_reset() ... -> ath9k_hw_kill_interrupts() -> set_bit(ATH_OP_HW_RESET, &common->op_flags); ... <- returns 2) ath9k_tasklet() ... -> ath9k_hw_resume_interrupts() ... <- returns 3) loops around: ... handle_int() -> ath_isr() ... -> if (test_bit(ATH_OP_HW_RESET, &common->op_flags)) return IRQ_HANDLED; x) ath_reset_internal(): => never reached <= And in ath_isr() we would typically see the following interrupts / interrupt causes: * status: 0x00111030 or 0x00110030 * async_cause: 2 (AR_INTR_MAC_IPQ) * sync_cause: 0 So the ath9k_tasklet() reenables the ath9k interrupts through ath9k_hw_resume_interrupts() which ath9k_queue_reset() had just disabled. And ath_isr() then keeps firing because it returns IRQ_HANDLED without actually clearing the interrupt. To fix this IRQ storm also clear/disable the interrupts again when we are in reset state. Cc: Sven Eckelmann Cc: Simon Wunderlich Cc: Linus Lüssing Fixes: 872b5d814f99 ("ath9k: do not access hardware on IRQs during reset") Signed-off-by: Linus Lüssing Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210914192515.9273-3-linus.luessing@c0d3.blue Signed-off-by: Sasha Levin commit fe0c577b43e39447a697af9009ed333c82754025 Author: Stephen Boyd Date: Tue Oct 5 16:55:53 2021 +0300 ath10k: Don't always treat modem stop events as crashes [ Upstream commit 747ff7d3d7424876111b7559b7f6704762f89796 ] When rebooting on sc7180 Trogdor devices I see the following crash from the wifi driver. ath10k_snoc 18800000.wifi: firmware crashed! (guid 83493570-29a2-4e98-a83e-70048c47669c) This is because a modem stop event looks just like a firmware crash to the driver, the qmi connection is closed in both cases. Use the qcom ssr notifier block to stop treating the qmi connection close event as a firmware crash signal when the modem hasn't actually crashed. See ath10k_qmi_event_server_exit() for more details. This silences the crash message seen during every reboot. Fixes: 3f14b73c3843 ("ath10k: Enable MSA region dump support for WCN3990") Cc: Youghandhar Chintala Cc: Abhishek Kumar Cc: Steev Klimaszewski Cc: Matthias Kaehlcke Cc: Rakesh Pillai Signed-off-by: Stephen Boyd Reviewed-by: Rakesh Pillai Tested-By: Youghandhar Chintala Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210922233341.182624-1-swboyd@chromium.org Signed-off-by: Sasha Levin commit ee85728ec044ef270645806898bad27b1dd3a1d7 Author: Colin Ian King Date: Fri Sep 17 18:07:02 2021 +0200 media: em28xx: Don't use ops->suspend if it is NULL [ Upstream commit 51fa3b70d27342baf1ea8aaab3e96e5f4f26d5b2 ] The call to ops->suspend for the dev->dev_next case can currently trigger a call on a null function pointer if ops->suspend is null. Skip over the use of function ops->suspend if it is null. Addresses-Coverity: ("Dereference after null check") Fixes: be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner functionality") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2b942c364b7759d8422d163786cd40d3834b17c8 Author: Anel Orazgaliyeva Date: Mon Sep 6 18:34:40 2021 +0000 cpuidle: Fix kobject memory leaks in error paths [ Upstream commit e5f5a66c9aa9c331da5527c2e3fd9394e7091e01 ] Commit c343bf1ba5ef ("cpuidle: Fix three reference count leaks") fixes the cleanup of kobjects; however, it removes kfree() calls altogether, leading to memory leaks. Fix those and also defer the initialization of dev->kobj_dev until after the error check, so that we do not end up with a dangling pointer. Fixes: c343bf1ba5ef ("cpuidle: Fix three reference count leaks") Signed-off-by: Anel Orazgaliyeva Suggested-by: Aman Priyadarshi [ rjw: Subject edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 94b69104840290fc2d6236d82cd8495b2a5f3c07 Author: Arnd Bergmann Date: Mon Sep 27 16:28:02 2021 +0200 drm: fb_helper: fix CONFIG_FB dependency [ Upstream commit 606b102876e3741851dfb09d53f3ee57f650a52c ] With CONFIG_FB=m and CONFIG_DRM=y, we get a link error in the fb helper: aarch64-linux-ld: drivers/gpu/drm/drm_fb_helper.o: in function `drm_fb_helper_alloc_fbi': (.text+0x10cc): undefined reference to `framebuffer_alloc' Tighten the dependency so it is only allowed in the case that DRM can link against FB. Fixes: f611b1e7624c ("drm: Avoid circular dependencies for CONFIG_FB") Link: https://lore.kernel.org/all/20210721152211.2706171-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Reviewed-by: Kees Cook Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210927142816.2069269-1-arnd@kernel.org Signed-off-by: Sasha Levin commit f28f2b20d05ff6d250371c1a2dcf89f67b898ad2 Author: Arnd Bergmann Date: Mon Sep 20 12:05:35 2021 +0200 crypto: ecc - fix CRYPTO_DEFAULT_RNG dependency [ Upstream commit 38aa192a05f22f9778f9420e630f0322525ef12e ] The ecc.c file started out as part of the ECDH algorithm but got moved out into a standalone module later. It does not build without CRYPTO_DEFAULT_RNG, so now that other modules are using it as well we can run into this link error: aarch64-linux-ld: ecc.c:(.text+0xfc8): undefined reference to `crypto_default_rng' aarch64-linux-ld: ecc.c:(.text+0xff4): undefined reference to `crypto_put_default_rng' Move the 'select CRYPTO_DEFAULT_RNG' statement into the correct symbol. Fixes: 0d7a78643f69 ("crypto: ecrdsa - add EC-RDSA (GOST 34.10) algorithm") Fixes: 4e6602916bc6 ("crypto: ecdsa - Add support for ECDSA signature verification") Signed-off-by: Arnd Bergmann Reviewed-by: Stefan Berger Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 056e9bf9b4df8dca9d66a370f3d02dadde83d360 Author: Punit Agrawal Date: Tue Sep 14 23:38:37 2021 +0900 kprobes: Do not use local variable when creating debugfs file [ Upstream commit 8f7262cd66699a4b02eb7549b35c81b2116aad95 ] debugfs_create_file() takes a pointer argument that can be used during file operation callbacks (accessible via i_private in the inode structure). An obvious requirement is for the pointer to refer to valid memory when used. When creating the debugfs file to dynamically enable / disable kprobes, a pointer to local variable is passed to debugfs_create_file(); which will go out of scope when the init function returns. The reason this hasn't triggered random memory corruption is because the pointer is not accessed during the debugfs file callbacks. Since the enabled state is managed by the kprobes_all_disabled global variable, the local variable is not needed. Fix the incorrect (and unnecessary) usage of local variable during debugfs_file_create() by passing NULL instead. Link: https://lkml.kernel.org/r/163163031686.489837.4476867635937014973.stgit@devnote2 Fixes: bf8f6e5b3e51 ("Kprobes: The ON/OFF knob thru debugfs") Signed-off-by: Punit Agrawal Acked-by: Masami Hiramatsu Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 0706df90bcbf85410c43615e1095083423141f22 Author: Yee Lee Date: Thu Sep 30 16:16:13 2021 +0800 scs: Release kasan vmalloc poison in scs_free process [ Upstream commit 528a4ab45300fa6283556d9b48e26b45a8aa15c4 ] Since scs allocation is moved to vmalloc region, the shadow stack is protected by kasan_posion_vmalloc. However, the vfree_atomic operation needs to access its context for scs_free process and causes kasan error as the dump info below. This patch Adds kasan_unpoison_vmalloc() before vfree_atomic, which aligns to the prior flow as using kmem_cache. The vmalloc region will go back posioned in the following vumap() operations. ================================================================== BUG: KASAN: vmalloc-out-of-bounds in llist_add_batch+0x60/0xd4 Write of size 8 at addr ffff8000100b9000 by task kthreadd/2 CPU: 0 PID: 2 Comm: kthreadd Not tainted 5.15.0-rc2-11681-g92477dd1faa6-dirty #1 Hardware name: linux,dummy-virt (DT) Call trace: dump_backtrace+0x0/0x43c show_stack+0x1c/0x2c dump_stack_lvl+0x68/0x84 print_address_description+0x80/0x394 kasan_report+0x180/0x1dc __asan_report_store8_noabort+0x48/0x58 llist_add_batch+0x60/0xd4 vfree_atomic+0x60/0xe0 scs_free+0x1dc/0x1fc scs_release+0xa4/0xd4 free_task+0x30/0xe4 __put_task_struct+0x1ec/0x2e0 delayed_put_task_struct+0x5c/0xa0 rcu_do_batch+0x62c/0x8a0 rcu_core+0x60c/0xc14 rcu_core_si+0x14/0x24 __do_softirq+0x19c/0x68c irq_exit+0x118/0x2dc handle_domain_irq+0xcc/0x134 gic_handle_irq+0x7c/0x1bc call_on_irq_stack+0x40/0x70 do_interrupt_handler+0x78/0x9c el1_interrupt+0x34/0x60 el1h_64_irq_handler+0x1c/0x2c el1h_64_irq+0x78/0x7c _raw_spin_unlock_irqrestore+0x40/0xcc sched_fork+0x4f0/0xb00 copy_process+0xacc/0x3648 kernel_clone+0x168/0x534 kernel_thread+0x13c/0x1b0 kthreadd+0x2bc/0x400 ret_from_fork+0x10/0x20 Memory state around the buggy address: ffff8000100b8f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff8000100b8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffff8000100b9000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffff8000100b9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffff8000100b9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ================================================================== Suggested-by: Kuan-Ying Lee Acked-by: Will Deacon Tested-by: Will Deacon Reviewed-by: Sami Tolvanen Signed-off-by: Yee Lee Fixes: a2abe7cbd8fe ("scs: switch to vmapped shadow stacks") Link: https://lore.kernel.org/r/20210930081619.30091-1-yee.lee@mediatek.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit e3e9d565039b41a8e1efd7366767e898c0bdc186 Author: Eugen Hristev Date: Mon Sep 13 12:22:54 2021 +0200 media: atmel: fix the ispck initialization [ Upstream commit d7f26849ed7cc875d0ff7480c2efebeeccea2bad ] The runtime enabling of the ISPCK (internally clocks the pipeline inside the ISC) has to be done after the pm_runtime for the ISC dev has been started. After the commit by Mauro: the ISC failed to probe with the error: atmel-sama5d2-isc f0008000.isc: failed to enable ispck: -13 atmel-sama5d2-isc: probe of f0008000.isc failed with error -13 This is because the enabling of the ispck is done too early in the probe, and the PM runtime returns invalid request. Thus, moved this clock enabling after pm_runtime_idle is called. The ISPCK is required only for sama5d2 type of ISC. Thus, add a bool inside the isc struct that is platform dependent. For the sama7g5-isc, the enabling of the ISPCK is wrong and does not make sense. Removed it from the sama7g5 probe. In sama7g5-isc, there is only one clock, the MCK, which also clocks the internal pipeline of the ISC. Adapted the clk_prepare and clk_unprepare to request the runtime PM for both clocks (MCK and ISPCK) in case of sama5d2-isc, and the single clock (MCK) in case of sama7g5-isc. Fixes: dd97908ee350 ("media: atmel: properly get pm_runtime") Signed-off-by: Eugen Hristev Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b3aa49fa18831012b1d4b1de541bdff953a0b8fe Author: Colin Ian King Date: Wed Aug 4 10:50:10 2021 +0200 media: cx23885: Fix snd_card_free call on null card pointer [ Upstream commit 7266dda2f1dfe151b12ef0c14eb4d4e622fb211c ] Currently a call to snd_card_new that fails will set card with a NULL pointer, this causes a null pointer dereference on the error cleanup path when card it passed to snd_card_free. Fix this by adding a new error exit path that does not call snd_card_free and exiting via this new path. Addresses-Coverity: ("Explicit null dereference") Fixes: 9e44d63246a9 ("[media] cx23885: Add ALSA support") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c6ac1541718422179fdefc0700c7d015f9d2ad8a Author: Kees Cook Date: Tue Aug 3 21:46:10 2021 +0200 media: tm6000: Avoid card name truncation [ Upstream commit 42bb98e420d454fef3614b70ea11cc59068395f6 ] The "card" string only holds 31 characters (and the terminating NUL). In order to avoid truncation, use a shorter card description instead of the current result, "Trident TVMaster TM5600/6000/60". Suggested-by: Hans Verkuil Fixes: e28f49b0b2a8 ("V4L/DVB: tm6000: fix some info messages") Signed-off-by: Kees Cook Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7d87109753ddbef0a09de4e25c8a6ce4c60fee41 Author: Kees Cook Date: Tue Aug 3 21:46:09 2021 +0200 media: si470x: Avoid card name truncation [ Upstream commit 2908249f3878a591f7918368fdf0b7b0a6c3158c ] The "card" string only holds 31 characters (and the terminating NUL). In order to avoid truncation, use a shorter card description instead of the current result, "Silicon Labs Si470x FM Radio Re". Suggested-by: Hans Verkuil Fixes: 78656acdcf48 ("V4L/DVB (7038): USB radio driver for Silicon Labs Si470x FM Radio Receivers") Fixes: cc35bbddfe10 ("V4L/DVB (12416): radio-si470x: add i2c driver for si470x") Signed-off-by: Kees Cook Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 861532494e53d3151531801625989f0076b24be1 Author: Kees Cook Date: Tue Aug 3 21:46:08 2021 +0200 media: radio-wl1273: Avoid card name truncation [ Upstream commit dfadec236aa99f6086141949c9dc3ec50f3ff20d ] The "card" string only holds 31 characters (and the terminating NUL). In order to avoid truncation, use a shorter card description instead of the current result, "Texas Instruments Wl1273 FM Rad". Suggested-by: Hans Verkuil Fixes: 87d1a50ce451 ("[media] V4L2: WL1273 FM Radio: TI WL1273 FM radio driver") Signed-off-by: Kees Cook Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 9e6a5f20278a4a6c9005f6291fa34f140200161b Author: Ondrej Jirman Date: Wed Sep 8 12:56:09 2021 +0200 media: sun6i-csi: Allow the video device to be open multiple times [ Upstream commit 8ed852834683ebe064157e069af8dfb41cad6403 ] Previously it was possible, but a recent fix for uninitialized `ret` variable broke this behavior. v4l2_fh_is_singular_file() check is there just to determine whether the power needs to be enabled, and it's not a failure if it returns false. Fixes: ba9139116bc0 ("media: sun6i-csi: add a missing return code") Signed-off-by: Ondrej Jirman Reviewed-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 80ef29aee4fe7d923d63a52931a9fb1063637462 Author: Randy Dunlap Date: Sun Sep 5 01:28:08 2021 +0200 media: i2c: ths8200 needs V4L2_ASYNC [ Upstream commit e4625044d656f3c33ece0cc9da22577bc10ca5d3 ] Fix the build errors reported by the kernel test robot by selecting V4L2_ASYNC: mips-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_remove': ths8200.c:(.text+0x1ec): undefined reference to `v4l2_async_unregister_subdev' mips-linux-ld: drivers/media/i2c/ths8200.o: in function `ths8200_probe': ths8200.c:(.text+0x404): undefined reference to `v4l2_async_register_subdev' Fixes: ed29f89497006 ("media: i2c: ths8200: support asynchronous probing") Signed-off-by: Randy Dunlap Reported-by: kernel test robot Reviewed-by: Lad Prabhakar Acked-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 36c37105730661cf0bf6a16bc6d6668591cd3887 Author: Christophe JAILLET Date: Sat Aug 21 13:12:53 2021 +0200 media: imx-jpeg: Fix the error handling path of 'mxc_jpeg_probe()' [ Upstream commit 5c47dc6657543b3c4dffcbe741fb693b9b96796d ] A successful 'mxc_jpeg_attach_pm_domains()' call should be balanced by a corresponding 'mxc_jpeg_detach_pm_domains()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 2db16c6ed72c ("media: imx-jpeg: Add V4L2 driver for i.MX8 JPEG Encoder/Decoder") Signed-off-by: Christophe JAILLET Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0dd8fc82fa0454d30cc2b1fe3ce9a17c78880c77 Author: Christophe JAILLET Date: Thu Aug 19 22:21:25 2021 +0200 media: mtk-vpu: Fix a resource leak in the error handling path of 'mtk_vpu_probe()' [ Upstream commit 2143ad413c05c7be24c3a92760e367b7f6aaac92 ] A successful 'clk_prepare()' call should be balanced by a corresponding 'clk_unprepare()' call in the error handling path of the probe, as already done in the remove function. Update the error handling path accordingly. Fixes: 3003a180ef6b ("[media] VPU: mediatek: support Mediatek VPU") Signed-off-by: Christophe JAILLET Reviewed-by: Houlong Wei Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e3a8abdb8f342db08b278b8c3500e666a3de0398 Author: Tom Rix Date: Thu Aug 12 19:00:43 2021 +0200 media: TDA1997x: handle short reads of hdmi info frame. [ Upstream commit 48d219f9cc667bc6fbc3e3af0b1bfd75db94fce4 ] Static analysis reports this representative problem tda1997x.c:1939: warning: 7th function call argument is an uninitialized value The 7th argument is buffer[0], which is set in the earlier call to io_readn(). When io_readn() call to io_read() fails with the first read, buffer[0] is not set and 0 is returned and stored in len. The later call to hdmi_infoframe_unpack()'s size parameter is the static size of buffer, always 40, so a short read is not caught in hdmi_infoframe_unpacks()'s checking. The variable len should be used instead. Zero initialize buffer to 0 so it is in a known start state. Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver") Signed-off-by: Tom Rix Reviewed-by: Tim Harvey Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0d25488ab9a8f6ff85e6fad8dfc66a1aab4f18e8 Author: Dafna Hirschfeld Date: Fri May 28 10:36:41 2021 +0200 media: mtk-vcodec: venc: fix return value when start_streaming fails [ Upstream commit 065a7c66bd8b21db212fa86187ff12f0cac6ea6d ] In case vb2ops_venc_start_streaming fails, the error value is overwritten by the ret value of pm_runtime_put which might be 0. Fix it. Fixes: 985c73693fe5a (" media: mtk-vcodec: Separating mtk encoder driver") Signed-off-by: Dafna Hirschfeld Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit a1120f37dfc45c0bb6996613bf11e6db6534c0a2 Author: Ricardo Ribalda Date: Fri Jun 18 14:29:06 2021 +0200 media: v4l2-ioctl: S_CTRL output the right value [ Upstream commit c87ed93574e3cd8346c05bd934c617596c12541b ] If the driver does not implement s_ctrl, but it does implement s_ext_ctrls, we convert the call. When that happens we have also to convert back the response from s_ext_ctrls. Fixes v4l2_compliance: Control ioctls (Input 0): fail: v4l2-test-controls.cpp(411): returned control value out of range fail: v4l2-test-controls.cpp(507): invalid control 00980900 test VIDIOC_G/S_CTRL: FAIL Fixes: 35ea11ff8471 ("V4L/DVB (8430): videodev: move some functions from v4l2-dev.h to v4l2-common.h or v4l2-ioctl.h") Reviewed-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7d4317208c32ef18cf9f9e9adc1afddf86145209 Author: Sakari Ailus Date: Mon Aug 16 15:08:59 2021 +0200 media: imx258: Fix getting clock frequency [ Upstream commit d170b0ea1760989fe8ac053bef83e61f3bf87992 ] Obtain the clock frequency by reading the clock-frequency property if there's no clock. Fixes: 9fda25332c4b ("media: i2c: imx258: get clock from device properties and enable it via runtime PM") Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f7baee6e0dd918c9b098aa5cf2c1feeebd037f67 Author: Pavel Skripkin Date: Fri Aug 13 16:34:20 2021 +0200 media: dvb-usb: fix ununit-value in az6027_rc_query [ Upstream commit afae4ef7d5ad913cab1316137854a36bea6268a5 ] Syzbot reported ununit-value bug in az6027_rc_query(). The problem was in missing state pointer initialization. Since this function does nothing we can simply initialize state to REMOTE_NO_KEY_PRESSED. Reported-and-tested-by: syzbot+2cd8c5db4a85f0a04142@syzkaller.appspotmail.com Fixes: 76f9a820c867 ("V4L/DVB: AZ6027: Initial import of the driver") Signed-off-by: Pavel Skripkin Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1505c575893274e43bf642babd87b3ef75bfd7ab Author: Evgeny Novikov Date: Tue Jul 20 11:28:27 2021 +0200 media: ttusb-dec: avoid release of non-acquired mutex [ Upstream commit 36b9d695aa6fb8e9a312db21af41f90824d16ab4 ] ttusb_dec_send_command() invokes mutex_lock_interruptible() that can fail but then it releases the non-acquired mutex. The patch fixes that. Found by Linux Driver Verification project (linuxtesting.org). Fixes: dba328bab4c6 ("media: ttusb-dec: cleanup an error handling logic") Signed-off-by: Evgeny Novikov Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ae0abe0db3f6600a435da0ede878fa9ab2a50f7b Author: Colin Ian King Date: Tue Jul 20 18:07:49 2021 +0200 media: cxd2880-spi: Fix a null pointer dereference on error handling path [ Upstream commit 11b982e950d2138e90bd120501df10a439006ff8 ] Currently the null pointer check on dvb_spi->vcc_supply is inverted and this leads to only null values of the dvb_spi->vcc_supply being passed to the call of regulator_disable causing null pointer dereferences. Fix this by only calling regulator_disable if dvb_spi->vcc_supply is not null. Addresses-Coverity: ("Dereference after null check") Fixes: dcb014582101 ("media: cxd2880-spi: Fix an error handling path") Signed-off-by: Colin Ian King Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 195ba4c00fd0cb9183325b82c244cc1a05b32361 Author: Christophe JAILLET Date: Fri Jul 30 21:35:05 2021 +0200 media: meson-ge2d: Fix rotation parameter changes detection in 'ge2d_s_ctrl()' [ Upstream commit 4b9e3e8af4b336eefca1f1ee535bc4b6734ed6aa ] There is likely a typo here. To be consistent, we should compare 'fmt.height' with 'ctx->out.pix_fmt.height', not 'ctx->out.pix_fmt.width'. Instead of fixing the test, just remove it and copy 'fmt' unconditionally. Fixes: 59a635327ca7 ("media: meson: Add M2M driver for the Amlogic GE2D Accelerator Unit") Signed-off-by: Christophe JAILLET Acked-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d3accf5edd7cf4a6a2fa72437097db9c35981add Author: Pavel Skripkin Date: Thu Jul 29 22:23:33 2021 +0200 media: em28xx: add missing em28xx_close_extension [ Upstream commit 2c98b8a3458df03abdc6945bbef67ef91d181938 ] If em28xx dev has ->dev_next pointer, we need to delete ->dev_next list node from em28xx_extension_devlist on disconnect to avoid UAF bugs and corrupted list bugs, since driver frees this pointer on disconnect. Reported-and-tested-by: syzbot+a6969ef522a36d3344c9@syzkaller.appspotmail.com Fixes: 1a23f81b7dc3 ("V4L/DVB (9979): em28xx: move usb probe code to a proper place") Signed-off-by: Pavel Skripkin Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 051b36e399db12d41cb6696c88722fce6231d5ec Author: Kumar Kartikeya Dwivedi Date: Mon Sep 27 20:29:39 2021 +0530 libbpf: Fix skel_internal.h to set errno on loader retval < 0 [ Upstream commit e68ac0082787f4e8ee6ae5b19076ec7709ce715b ] When the loader indicates an internal error (result of a checked bpf system call), it returns the result in attr.test.retval. However, tests that rely on ASSERT_OK_PTR on NULL (returned from light skeleton) may miss that NULL denotes an error if errno is set to 0. This would result in skel pointer being NULL, while ASSERT_OK_PTR returning 1, leading to a SEGV on dereference of skel, because libbpf_get_error relies on the assumption that errno is always set in case of error for ptr == NULL. In particular, this was observed for the ksyms_module test. When executed using `./test_progs -t ksyms`, prior tests manipulated errno and the test didn't crash when it failed at ksyms_module load, while using `./test_progs -t ksyms_module` crashed due to errno being untouched. Fixes: 67234743736a (libbpf: Generate loader program out of BPF ELF file.) Signed-off-by: Kumar Kartikeya Dwivedi Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20210927145941.1383001-11-memxor@gmail.com Signed-off-by: Sasha Levin commit 5019c6127eb1c4c998768d67fd4c7b1e127eabab Author: Arnd Bergmann Date: Mon Sep 27 14:58:10 2021 +0200 drm/amdgpu: fix warning for overflow check [ Upstream commit 335aea75b0d95518951cad7c4c676e6f1c02c150 ] The overflow check in amdgpu_bo_list_create() causes a warning with clang-14 on 64-bit architectures, since the limit can never be exceeded. drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:74:18: error: result of comparison of constant 256204778801521549 with expression of type 'unsigned int' is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (num_entries > (SIZE_MAX - sizeof(struct amdgpu_bo_list)) ~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The check remains useful for 32-bit architectures, so just avoid the warning by using size_t as the type for the count. Fixes: 920990cb080a ("drm/amdgpu: allocate the bo_list array after the list") Reviewed-by: Christian König Signed-off-by: Arnd Bergmann Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 75bf90feb4a635a656bca743833caeaa764f7d2b Author: Sudarshan Rajagopalan Date: Tue Sep 28 11:51:49 2021 -0700 arm64: mm: update max_pfn after memory hotplug [ Upstream commit 8fac67ca236b961b573355e203dbaf62a706a2e5 ] After new memory blocks have been hotplugged, max_pfn and max_low_pfn needs updating to reflect on new PFNs being hot added to system. Without this patch, debug-related functions that use max_pfn such as get_max_dump_pfn() or read_page_owner() will not work with any page in memory that is hot-added after boot. Fixes: 4ab215061554 ("arm64: Add memory hotplug support") Signed-off-by: Sudarshan Rajagopalan Signed-off-by: Chris Goldsworthy Acked-by: David Hildenbrand Cc: Florian Fainelli Cc: Georgi Djakov Tested-by: Georgi Djakov Link: https://lore.kernel.org/r/a51a27ee7be66024b5ce626310d673f24107bcb8.1632853776.git.quic_cgoldswo@quicinc.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 59f0c96b3f7a68aa5042c6741605f9f6404b4327 Author: Matthew Auld Date: Mon Sep 27 12:41:02 2021 +0100 drm/ttm: stop calling tt_swapin in vm_access [ Upstream commit f5d28856b89baab4232a9f841e565763fcebcdf9 ] In commit: commit 09ac4fcb3f255e9225967c75f5893325c116cdbe Author: Felix Kuehling Date: Thu Jul 13 17:01:16 2017 -0400 drm/ttm: Implement vm_operations_struct.access v2 we added the vm_access hook, where we also directly call tt_swapin for some reason. If something is swapped-out then the ttm_tt must also be unpopulated, and since access_kmap should also call tt_populate, if needed, then swapping-in will already be handled there. If anything, calling tt_swapin directly here would likely always fail since the tt->pages won't yet be populated, or worse since the tt->pages array is never actually cleared in unpopulate this might lead to a nasty uaf. Fixes: 09ac4fcb3f25 ("drm/ttm: Implement vm_operations_struct.access v2") Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Christian König Reviewed-by: Thomas Hellström Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20210927114114.152310-1-matthew.auld@intel.com Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 61104f1c0083700be5b00642cba7a3e76cf174ff Author: Fabio Estevam Date: Tue Sep 28 14:00:47 2021 +0300 ath10k: sdio: Add missing BH locking around napi_schdule() [ Upstream commit 019edd01d174ce4bb2e517dd332922514d176601 ] On a i.MX-based board with a QCA9377 Wifi chip, the following errors are seen after launching the 'hostapd' application: hostapd /etc/wifi.conf Configuration file: /etc/wifi.conf wlan0: interface state UNINITIALIZED->COUNTRY_UPDATE NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! Using interface wlan0 with hwaddr 00:1f:7b:31:04:a0 and ssid "thessid" IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready wlan0: interface state COUNTRY_UPDATE->ENABLED wlan0: AP-ENABLED NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! ... Fix this problem by adding the BH locking around napi-schedule(), in the same way it was done in commit e63052a5dd3c ("mlx5e: add add missing BH locking around napi_schdule()"). Its commit log provides the following explanation: "It's not correct to call napi_schedule() in pure process context. Because we use __raise_softirq_irqoff() we require callers to be in a context which will eventually lead to softirq handling (hardirq, bh disabled, etc.). With code as is users will see: NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! " Fixes: cfee8793a74d ("ath10k: enable napi on RX path for sdio") Signed-off-by: Fabio Estevam Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210824144339.2796122-1-festevam@denx.de Signed-off-by: Sasha Levin commit bdf3ddbf83f0294b55f982971f47c4893d8def17 Author: Loic Poulain Date: Tue Sep 28 14:00:47 2021 +0300 ath10k: Fix missing frame timestamp for beacon/probe-resp [ Upstream commit e6dfbc3ba90cc2b619229be56b485f085a0a8e1c ] 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). Fixes: 5e3dd157d7e7 ("ath10k: mac80211 driver for Qualcomm Atheros 802.11ac CQA98xx devices") Signed-off-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1629811733-7927-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit 5e1f85a23ae09edc7537a50c148226aafa38fd72 Author: Arnd Bergmann Date: Tue Sep 28 16:15:13 2021 +0200 gve: DQO: avoid unused variable warnings [ Upstream commit 1e0083bd0777e4a418a6710d9ee04b979cdbe5cc ] The use of dma_unmap_addr()/dma_unmap_len() in the driver causes multiple warnings when these macros are defined as empty, e.g. in an ARCH=i386 allmodconfig build: drivers/net/ethernet/google/gve/gve_tx_dqo.c: In function 'gve_tx_add_skb_no_copy_dqo': drivers/net/ethernet/google/gve/gve_tx_dqo.c:494:40: error: unused variable 'buf' [-Werror=unused-variable] 494 | struct gve_tx_dma_buf *buf = This is not how the NEED_DMA_MAP_STATE macros are meant to work, as they rely on never using local variables or a temporary structure like gve_tx_dma_buf. Remote the gve_tx_dma_buf definition and open-code the contents in all places to avoid the warning. This causes some rather long lines but otherwise ends up making the driver slightly smaller. Fixes: a57e5de476be ("gve: DQO: Add TX path") Link: https://lore.kernel.org/netdev/20210723231957.1113800-1-bcf@google.com/ Link: https://lore.kernel.org/netdev/20210721151100.2042139-1-arnd@kernel.org/ Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b35a9d47203bb58b0f9021dbc202c748174ae653 Author: Baochen Qiang Date: Tue Sep 28 14:00:44 2021 +0300 ath11k: Fix memory leak in ath11k_qmi_driver_event_work [ Upstream commit 72de799aa9e3e064b35238ef053d2f0a49db055a ] The buffer pointed to by event is not freed in case ATH11K_FLAG_UNREGISTERING bit is set, resulting in memory leak, so fix it. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Baochen Qiang Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210913180246.193388-4-jouni@codeaurora.org Signed-off-by: Sasha Levin commit 9b404c64784d01531f1c7cb699ae83ddc0516f32 Author: Pradeep Kumar Chitrapu Date: Tue Sep 28 14:00:43 2021 +0300 ath11k: fix packet drops due to incorrect 6 GHz freq value in rx status [ Upstream commit 9d6ae1f5cf733c0e8d7f904c501fd015c4b9f0f4 ] Frequency in rx status is being filled incorrectly in the 6 GHz band as channel number received is invalid in this case which is causing packet drops. So fix that. Fixes: 5dcf42f8b79d ("ath11k: Use freq instead of channel number in rx path") Signed-off-by: Pradeep Kumar Chitrapu Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210722102054.43419-2-jouni@codeaurora.org Signed-off-by: Sasha Levin commit afc36b6469bb553a2fc906cd525e5e992480481e Author: Sriram R Date: Tue Sep 28 12:05:40 2021 +0300 ath11k: Avoid race during regd updates [ Upstream commit 1db2b0d0a39102238fcbf9092cefa65a710642e9 ] Whenever ath11k is bootup with a user country already set, cfg80211 notifies this country info to ath11k soon after registration, where the notification is sent to the firmware for fetching the rules of this user country input. Multiple race conditions could be seen in this scenario where a new request is either lost as pointed in [1] or a new regd overwrites the default regd provided by the firmware during bootup. Note that, the default regd is used for intersection purpose and hence it should not be overwritten. The main reason as pointed by [1] is the usage of ATH11K_FLAG_REGISTERED flag which is updated after completion of core registration, whereas the reg notification from cfg80211 and wmi events for the corresponding request can happen much before that. Since the ATH11K_FLAG_REGISTERED is currently used to determine if the event containing reg rules belong to default regd or for user request, there is a possibility of the default regd getting overwritten. Since the default reg rules will be received only once per pdev on firmware load, the above flag based check can be replaced with a check to see if default_regd is already set, so that we can now always update the new_regd. Also if the new_regd is set, this will be always used to update the reg rules for the registered phy. [1] https://patchwork.kernel.org/project/linux-wireless/patch/1829665.1PRlr7bOQj@ripper/ Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01460-QCAHKSWPL_SILICONZ-1 Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices") Signed-off-by: Sriram R Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210721212029.142388-4-jouni@codeaurora.org Signed-off-by: Sasha Levin commit aad8db659de25ed8117d63d7650a52ae81ee15c7 Author: Dan Carpenter Date: Tue Sep 28 12:05:43 2021 +0300 ath11k: fix some sleeping in atomic bugs [ Upstream commit aadf7c81a0771b8f1c97dabca6a48bae1b387779 ] The ath11k_dbring_bufs_replenish() and ath11k_dbring_fill_bufs() take a "gfp" parameter but they since they take spinlocks, the allocations they do have to be atomic. This causes a bug because ath11k_dbring_buf_setup passes GFP_KERNEL for the gfp flags. The fix is to use GFP_ATOMIC and remove the unused parameters. Fixes: bd6478559e27 ("ath11k: Add direct buffer ring support") Signed-off-by: Dan Carpenter Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210812070434.GE31863@kili Signed-off-by: Sasha Levin commit 24615ed29c06a5274f59b626fa655d4bfe267f96 Author: Linus Walleij Date: Sun Sep 26 00:59:28 2021 +0200 net: dsa: rtl8366: Fix a bug in deleting VLANs [ Upstream commit d8251b9db34a2cbc5619b610e7e8aad1d165c531 ] We were checking that the MC (member config) was != 0 for some reason, all we need to check is that the config has no ports, i.e. no members. Then it can be recycled. This must be some misunderstanding. Fixes: 4ddcaf1ebb5e ("net: dsa: rtl8366: Properly clear member config") Cc: Mauri Sandberg Cc: DENG Qingfang Reviewed-by: Alvin Šipraga Reviewed-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 356b67db7834c4a1f2c5e3caad8c18e71f046c24 Author: Linus Walleij Date: Sun Sep 26 00:59:27 2021 +0200 net: dsa: rtl8366rb: Fix off-by-one bug [ Upstream commit 5f5f12f5d4b108399130bb5c11f07765851d9cdb ] The max VLAN number with non-4K VLAN activated is 15, and the range is 0..15. Not 16. The impact should be low since we by default have 4K VLAN and thus have 4095 VLANs to play with in this switch. There will not be a problem unless the code is rewritten to only use 16 VLANs. Fixes: d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") Cc: Mauri Sandberg Cc: DENG Qingfang Cc: Florian Fainelli Reviewed-by: Alvin Šipraga Reviewed-by: Vladimir Oltean Signed-off-by: Linus Walleij Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d759e6c0c090ba6643b2f4373af24283f3b4cce6 Author: Johannes Berg Date: Mon Sep 27 13:11:06 2021 +0200 cfg80211: always free wiphy specific regdomain [ Upstream commit e53e9828a8d2c6545e01ff9711f1221f2fd199ce ] In the (somewhat unlikely) event that we allocate a wiphy, then add a regdomain to it, and then fail registration, we leak the regdomain. Fix this by just always freeing it at the end, in the normal cases we'll free (and NULL) it during wiphy_unregister(). This happened when the wiphy settings were bad, and since they can be controlled by userspace with hwsim, syzbot was able to find this issue. Reported-by: syzbot+1638e7c770eef6b6c0d0@syzkaller.appspotmail.com Fixes: 3e0c3ff36c4c ("cfg80211: allow multiple driver regulatory_hints()") Signed-off-by: Johannes Berg Link: https://lore.kernel.org/r/20210927131105.68b70cef4674.I4b9f0aa08c2af28555963b9fe3d34395bb72e0cc@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 76ef0d62e488e0df7435e715d1c130b42925bb1c Author: Kees Cook Date: Mon Aug 2 10:25:01 2021 -0700 fortify: Fix dropped strcpy() compile-time write overflow check [ Upstream commit 072af0c638dc8a5c7db2edc4dddbd6d44bee3bdb ] The implementation for intra-object overflow in str*-family functions accidentally dropped compile-time write overflow checking in strcpy(), leaving it entirely to run-time. Add back the intended check. Fixes: 6a39e62abbaf ("lib: string.h: detect intra-object overflow in fortified string functions") Cc: Daniel Axtens Cc: Francis Laniel Signed-off-by: Kees Cook Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin commit b17b52fe984dabde0f5bf36582a756748336e020 Author: Jiasheng Jiang Date: Fri Sep 24 03:18:37 2021 +0000 rxrpc: Fix _usecs_to_jiffies() by using usecs_to_jiffies() [ Upstream commit acde891c243c1ed85b19d4d5042bdf00914f5739 ] Directly using _usecs_to_jiffies() might be unsafe, so it's better to use usecs_to_jiffies() instead. Because we can see that the result of _usecs_to_jiffies() could be larger than MAX_JIFFY_OFFSET values without the check of the input. Fixes: c410bf01933e ("Fix the excessive initial retransmission timeout") Signed-off-by: Jiasheng Jiang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 188e62c48a53716e4125c267ecf562d59f300ef0 Author: Leon Romanovsky Date: Thu Sep 23 21:12:53 2021 +0300 qed: Don't ignore devlink allocation failures [ Upstream commit e6a54d6f221301347aaf9d83bb1f23129325c1c5 ] devlink is a software interface that doesn't depend on any hardware capabilities. The failure in SW means memory issues, wrong parameters, programmer error e.t.c. Like any other such interface in the kernel, the returned status of devlink APIs should be checked and propagated further and not ignored. Fixes: 755f982bb1ff ("qed/qede: make devlink survive recovery") Signed-off-by: Leon Romanovsky Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b402ea43f6d1938eb21d1d0b87d580b1446d9372 Author: Leon Romanovsky Date: Thu Sep 23 21:12:48 2021 +0300 bnxt_en: Check devlink allocation and registration status [ Upstream commit e624c70e1131e145bd0510b8a700b5e2d112e377 ] devlink is a software interface that doesn't depend on any hardware capabilities. The failure in SW means memory issues, wrong parameters, programmer error e.t.c. Like any other such interface in the kernel, the returned status of devlink APIs should be checked and propagated further and not ignored. Fixes: 4ab0c6a8ffd7 ("bnxt_en: add support to enable VF-representors") Signed-off-by: Leon Romanovsky Reviewed-by: Edwin Peer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 30f53d14efb191bc2a5d3ae35281d059a256de12 Author: Michael Walle Date: Thu Sep 16 00:03:07 2021 +0200 crypto: caam - disable pkc for non-E SoCs [ Upstream commit f20311cc9c58052e0b215013046cbf390937910c ] On newer CAAM versions, not all accelerators are disabled if the SoC is a non-E variant. While the driver checks most of the modules for availability, there is one - PKHA - which sticks out. On non-E variants it is still reported as available, that is the number of instances is non-zero, but it has limited functionality. In particular it doesn't support encryption and decryption, but just signing and verifying. This is indicated by a bit in the PKHA_MISC field. Take this bit into account if we are checking for availability. This will the following error: [ 8.167817] caam_jr 8020000.jr: 20000b0f: CCB: desc idx 11: : Invalid CHA selected. Tested on an NXP LS1028A (non-E) SoC. Fixes: d239b10d4ceb ("crypto: caam - add register map changes cf. Era 10") Signed-off-by: Michael Walle Reviewed-by: Horia Geantă Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit d2891d4b5a2e74244a020c0328c842e8d11a0338 Author: Guchun Chen Date: Sat Sep 18 13:43:41 2021 +0800 drm/amdgpu: move amdgpu_virt_release_full_gpu to fini_early stage [ Upstream commit 6effad8abe0ba4db3d9c58ed585127858a990f35 ] adev->rmmio is set to be NULL in amdgpu_device_unmap_mmio to prevent access after pci_remove, however, in SRIOV case, amdgpu_virt_release_full_gpu will still use adev->rmmio for access after amdgpu_device_unmap_mmio. The patch is to move such SRIOV calling earlier to fini_early stage. Fixes: 07775fc13878 ("drm/amdgpu: Unmap all MMIO mappings") Cc: Andrey Grodzovsky Signed-off-by: Leslie Shi Signed-off-by: Guchun Chen Reviewed-by: Andrey Grodzovsky Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9777ecdce80db4cff876c516cd14e5893749833c Author: Dinghao Liu Date: Wed Sep 22 21:49:45 2021 +0800 Bluetooth: btmtkuart: fix a memleak in mtk_hci_wmt_sync [ Upstream commit 3e5f2d90c28f9454e421108554707620bc23269d ] bdev->evt_skb will get freed in the normal path and one error path of mtk_hci_wmt_sync, while the other error paths do not free it, which may cause a memleak. This bug is suggested by a static analysis tool, please advise. Fixes: e0b67035a90b ("Bluetooth: mediatek: update the common setup between MT7622 and other devices") Signed-off-by: Dinghao Liu Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 5c4f876eb2c666824317b206540dc806df76343d Author: Ajay Singh Date: Thu Sep 16 16:49:18 2021 +0000 wilc1000: fix possible memory leak in cfg_scan_result() [ Upstream commit 3c719fed0f3a5e95b1d164609ecc81c4191ade70 ] When the BSS reference holds a valid reference, it is not freed. The 'if' condition is wrong. Instead of the 'if (bss)' check, the 'if (!bss)' check is used. The issue is solved by removing the unnecessary 'if' check because cfg80211_put_bss() already performs the NULL validation. Fixes: 6cd4fa5ab691 ("staging: wilc1000: make use of cfg80211_inform_bss_frame()") Signed-off-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210916164902.74629-3-ajay.kathat@microchip.com Signed-off-by: Sasha Levin commit aa5324ab2f0129419ff21c71cd218fad69abbadb Author: Bryan O'Donoghue Date: Thu Sep 9 15:44:27 2021 +0100 wcn36xx: Fix Antenna Diversity Switching [ Upstream commit 701668d3bfa03dabc5095fc383d5315544ee5b31 ] We have been tracking a strange bug with Antenna Diversity Switching (ADS) on wcn3680b for a while. ADS is configured like this: A. Via a firmware configuration table baked into the NV area. 1. Defines if ADS is enabled. 2. Defines which GPIOs are connected to which antenna enable pin. 3. Defines which antenna/GPIO is primary and which is secondary. B. WCN36XX_CFG_VAL(ANTENNA_DIVERSITY, N) N is a bitmask of available antenna. Setting N to 3 indicates a bitmask of enabled antenna (1 | 2). Obviously then we can set N to 1 or N to 2 to fix to a particular antenna and disable antenna diversity. C. WCN36XX_CFG_VAL(ASD_PROBE_INTERVAL, XX) XX is the number of beacons between each antenna RSSI check. Setting this value to 50 means, every 50 received beacons, run the ADS algorithm. D. WCN36XX_CFG_VAL(ASD_TRIGGER_THRESHOLD, YY) YY is a two's complement integer which specifies the RSSI decibel threshold below which ADS will run. We default to -60db here, meaning a measured RSSI <= -60db will trigger an ADS probe. E. WCN36XX_CFG_VAL(ASD_RTT_RSSI_HYST_THRESHOLD, Z) Z is a hysteresis value, indicating a delta which the RSSI must exceed for the antenna switch to be valid. For example if HYST_THRESHOLD == 3 AntennaId1-RSSI == -60db and AntennaId-2-RSSI == -58db then firmware will not switch antenna. The threshold needs to be -57db or better to satisfy the criteria. F. A firmware feature bit also exists ANTENNA_DIVERSITY_SELECTION. This feature bit is used by the firmware to report if ANTENNA_DIVERSITY_SELECTION is supported. The host is not required to toggle this bit to enable or disable ADS. ADS works like this: A. Every XX beacons the firmware switches to or remains on the primary antenna. B. The firmware then sends a Request-To-Send (RTS) packet to the AP. C. The firmware waits for a Clear-To-Send (CTS) response from the AP. D. The firmware then notes the received RSSI on the CTS packet. E. The firmware then repeats steps A-D on the secondary antenna. F. Subsequently if the RSSI on the measured antenna is better than ASD_TRIGGER_THRESHOLD + the active antenna's RSSI then the measured antenna becomes the active antenna. G. If RSSI rises past ASD_TRIGGER_THRESHOLD then ADS doesn't run at all even if there is a substantially better RSSI on the alternative antenna. What we have been observing is that the RTS packet is being sent but the MAC address is a byte-swapped version of the target MAC. The ADS/RTS MAC is corrupted only when the link is encrypted, if the AP is open the RTS MAC is correct. Similarly if we configure the firmware to an RTS/CTS sequence for regular data - the transmitted RTS MAC is correctly formatted. Internally the wcn36xx firmware uses the indexes in the SMD commands to populate and extract data from specific entries in an STA lookup table. The AP's MAC appears a number of times in different indexes within this lookup table, so the MAC address extracted for the data-transmit RTS and the MAC address extracted for the ADS/RTS packet are not the same STA table index. Our analysis indicates the relevant firmware STA table index is "bssSelfStaIdx". There is an STA populate function responsible for formatting the MAC address of the bssSelfStaIdx including byte-swapping the MAC address. Its clear then that the required STA populate command did not run for bssSelfStaIdx. So taking a look at the sequence of SMD commands sent to the firmware we see the following downstream when moving from an unencrypted to encrypted BSS setup. - WLAN_HAL_CONFIG_BSS_REQ - WLAN_HAL_CONFIG_STA_REQ - WLAN_HAL_SET_STAKEY_REQ Upstream in wcn36xx we have - WLAN_HAL_CONFIG_BSS_REQ - WLAN_HAL_SET_STAKEY_REQ The solution then is to add the missing WLAN_HAL_CONFIG_STA_REQ between WLAN_HAL_CONFIG_BSS_REQ and WLAN_HAL_SET_STAKEY_REQ. No surprise WLAN_HAL_CONFIG_STA_REQ is the routine responsible for populating the STA lookup table in the firmware and once done the MAC sent by the ADS routine is in the correct byte-order. This bug is apparent with ADS but it is also the case that any other firmware routine that depends on the "bssSelfStaIdx" would retrieve malformed data on an encrypted link. Fixes: 3e977c5c523d ("wcn36xx: Define wcn3680 specific firmware parameters") Signed-off-by: Bryan O'Donoghue Tested-by: Benjamin Li Reviewed-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210909144428.2564650-2-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin commit fa6aafb2411d2b35e48fab65107066e654a65592 Author: Waiman Long Date: Sat Sep 18 18:53:08 2021 -0400 cgroup: Make rebind_subsystems() disable v2 controllers all at once [ Upstream commit 7ee285395b211cad474b2b989db52666e0430daf ] It was found that the following warning was displayed when remounting controllers from cgroup v2 to v1: [ 8042.997778] WARNING: CPU: 88 PID: 80682 at kernel/cgroup/cgroup.c:3130 cgroup_apply_control_disable+0x158/0x190 : [ 8043.091109] RIP: 0010:cgroup_apply_control_disable+0x158/0x190 [ 8043.096946] Code: ff f6 45 54 01 74 39 48 8d 7d 10 48 c7 c6 e0 46 5a a4 e8 7b 67 33 00 e9 41 ff ff ff 49 8b 84 24 e8 01 00 00 0f b7 40 08 eb 95 <0f> 0b e9 5f ff ff ff 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 [ 8043.115692] RSP: 0018:ffffba8a47c23d28 EFLAGS: 00010202 [ 8043.120916] RAX: 0000000000000036 RBX: ffffffffa624ce40 RCX: 000000000000181a [ 8043.128047] RDX: ffffffffa63c43e0 RSI: ffffffffa63c43e0 RDI: ffff9d7284ee1000 [ 8043.135180] RBP: ffff9d72874c5800 R08: ffffffffa624b090 R09: 0000000000000004 [ 8043.142314] R10: ffffffffa624b080 R11: 0000000000002000 R12: ffff9d7284ee1000 [ 8043.149447] R13: ffff9d7284ee1000 R14: ffffffffa624ce70 R15: ffffffffa6269e20 [ 8043.156576] FS: 00007f7747cff740(0000) GS:ffff9d7a5fc00000(0000) knlGS:0000000000000000 [ 8043.164663] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8043.170409] CR2: 00007f7747e96680 CR3: 0000000887d60001 CR4: 00000000007706e0 [ 8043.177539] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 8043.184673] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 8043.191804] PKRU: 55555554 [ 8043.194517] Call Trace: [ 8043.196970] rebind_subsystems+0x18c/0x470 [ 8043.201070] cgroup_setup_root+0x16c/0x2f0 [ 8043.205177] cgroup1_root_to_use+0x204/0x2a0 [ 8043.209456] cgroup1_get_tree+0x3e/0x120 [ 8043.213384] vfs_get_tree+0x22/0xb0 [ 8043.216883] do_new_mount+0x176/0x2d0 [ 8043.220550] __x64_sys_mount+0x103/0x140 [ 8043.224474] do_syscall_64+0x38/0x90 [ 8043.228063] entry_SYSCALL_64_after_hwframe+0x44/0xae It was caused by the fact that rebind_subsystem() disables controllers to be rebound one by one. If more than one disabled controllers are originally from the default hierarchy, it means that cgroup_apply_control_disable() will be called multiple times for the same default hierarchy. A controller may be killed by css_kill() in the first round. In the second round, the killed controller may not be completely dead yet leading to the warning. To avoid this problem, we collect all the ssid's of controllers that needed to be disabled from the default hierarchy and then disable them in one go instead of one by one. Fixes: 334c3679ec4b ("cgroup: reimplement rebind_subsystems() using cgroup_apply_control() and friends") Signed-off-by: Waiman Long Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 9a7121cc818907f88e6a6df20a7ef90806258ada Author: Yoshitaka Ikeda Date: Wed Sep 8 05:29:12 2021 +0000 spi: Fixed division by zero warning [ Upstream commit 09134c5322df9f105d9ed324051872d5d0e162aa ] The reason for dividing by zero is because the dummy bus width is zero, but if the dummy n bytes is zero, it indicates that there is no data transfer, so there is no need for calculation. Fixes: 7512eaf54190 ("spi: cadence-quadspi: Fix dummy cycle calculation when buswidth > 1") Signed-off-by: Yoshitaka Ikeda Acked-by: Pratyush Yadav Link: https://lore.kernel.org/r/OSZPR01MB70049C8F56ED8902852DF97B8BD49@OSZPR01MB7004.jpnprd01.prod.outlook.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a69330b102baf37c2624f1e02ed70532dbf92cf9 Author: Alex Bee Date: Sat Sep 18 16:04:20 2021 +0200 drm: bridge: it66121: Fix return value it66121_probe [ Upstream commit f3bc07eba481942a246926c5b934199e7ccd567b ] Currently it66121_probe returns -EPROBE_DEFER if the there is no remote endpoint found in the device tree which doesn't seem helpful, since this is not going to change later and it is never checked if the next bridge has been initialized yet. It will fail in that case later while doing drm_bridge_attach for the next bridge in it66121_bridge_attach. Since the bindings documentation for it66121 bridge driver states there has to be a remote endpoint defined, its safe to return -EINVAL in that case. This additonally adds a check, if the remote endpoint is enabled and returns -EPROBE_DEFER, if the remote bridge hasn't been initialized (yet). Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Signed-off-by: Alex Bee Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210918140420.231346-1-knaerzche@gmail.com Signed-off-by: Sasha Levin commit 83285fa94ee4fb151358313fc944f2dde2c479cb Author: Russell King (Oracle) Date: Fri Sep 17 14:36:31 2021 +0100 net: phylink: don't call netif_carrier_off() with NULL netdev [ Upstream commit cbcca2e3961eac736566ac13ef0d0bf6f0b764ec ] Dan Carpenter points out that we have a code path that permits a NULL netdev pointer to be passed to netif_carrier_off(), which will cause a kernel oops. In any case, we need to set pl->old_link_state to false to have the desired effect when there is no netdev present. Fixes: f97493657c63 ("net: phylink: add suspend/resume support") Reported-by: Dan Carpenter Signed-off-by: Russell King (Oracle) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 246ea42a7b4e9840d023877a39bb3d559452ede8 Author: Yajun Deng Date: Sat Sep 18 17:04:10 2021 +0800 net: net_namespace: Fix undefined member in key_remove_domain() [ Upstream commit aed0826b0cf2e488900ab92193893e803d65c070 ] The key_domain member in struct net only exists if we define CONFIG_KEYS. So we should add the define when we used key_domain. Fixes: 9b242610514f ("keys: Network namespace domain tag") Signed-off-by: Yajun Deng Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 391cdce61e3d9810e7ff7e263ea0ead999f5ff3e Author: Sebastian Andrzej Siewior Date: Fri Sep 3 10:40:01 2021 +0200 lockdep: Let lock_is_held_type() detect recursive read as read [ Upstream commit 2507003a1d10917c9158077bf6030719d02c941e ] lock_is_held_type(, 1) detects acquired read locks. It only recognized locks acquired with lock_acquire_shared(). Read locks acquired with lock_acquire_shared_recursive() are not recognized because a `2' is stored as the read value. Rework the check to additionally recognise lock's read value one and two as a read held lock. Fixes: e918188611f07 ("locking: More accurate annotations for read_lock()") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Peter Zijlstra (Intel) Acked-by: Boqun Feng Acked-by: Waiman Long Link: https://lkml.kernel.org/r/20210903084001.lblecrvz4esl4mrr@linutronix.de Signed-off-by: Sasha Levin commit 4adc275eba8ae817e8b999b7de51e18b1588d82e Author: liuyuntao Date: Sat Aug 28 18:43:21 2021 +0800 virtio-gpu: fix possible memory allocation failure [ Upstream commit 5bd4f20de8acad37dbb3154feb34dbc36d506c02 ] When kmem_cache_zalloc in virtio_gpu_get_vbuf fails, it will return an error code. But none of its callers checks this error code, and a core dump will take place. Considering many of its callers can't handle such error, I add a __GFP_NOFAIL flag when calling kmem_cache_zalloc to make sure it won't fail, and delete those unused error handlings. Fixes: dc5698e80cf724 ("Add virtio gpu driver.") Signed-off-by: Yuntao Liu Link: http://patchwork.freedesktop.org/patch/msgid/20210828104321.3410312-1-liuyuntao10@huawei.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 376bd99969e559f7aa3ac503c97756fec5f97bc6 Author: Iago Toral Quiroga Date: Wed Sep 15 12:05:07 2021 +0200 drm/v3d: fix wait for TMU write combiner flush [ Upstream commit e4f868191138975f2fdf2f37c11318b47db4acc9 ] The hardware sets the TMUWCF bit back to 0 when the TMU write combiner flush completes so we should be checking for that instead of the L2TFLS bit. v2 (Melissa Wen): - Add Signed-off-by and Fixes tags. - Change the error message for the timeout to be more clear. Fixes spurious Vulkan CTS failures in: dEQP-VK.binding_model.descriptorset_random.* Fixes: d223f98f02099 ("drm/v3d: Add support for compute shader dispatch.") Signed-off-by: Iago Toral Quiroga Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20210915100507.3945-1-itoral@igalia.com Signed-off-by: Sasha Levin commit 35d945ef6ac87c23c2f6ef45827511c6218e4695 Author: Peter Zijlstra Date: Thu Jun 24 11:41:02 2021 +0200 objtool: Handle __sanitize_cov*() tail calls [ Upstream commit f56dae88a81fded66adf2bea9922d1d98d1da14f ] Turns out the compilers also generate tail calls to __sanitize_cov*(), make sure to also patch those out in noinstr code. Fixes: 0f1441b44e82 ("objtool: Fix noinstr vs KCOV") Signed-off-by: Peter Zijlstra (Intel) Acked-by: Marco Elver Link: https://lore.kernel.org/r/20210624095147.818783799@infradead.org Signed-off-by: Sasha Levin commit a9f61b66edc8cc07e53a51f2bc3b1251fc0e9713 Author: Peter Zijlstra Date: Thu Jun 24 11:41:00 2021 +0200 x86/xen: Mark cpu_bringup_and_idle() as dead_end_function [ Upstream commit 9af9dcf11bda3e2c0e24c1acaacb8685ad974e93 ] The asm_cpu_bringup_and_idle() function is required to push the return value on the stack in order to make ORC happy, but the only reason objtool doesn't complain is because of a happy accident. The thing is that asm_cpu_bringup_and_idle() doesn't return, so validate_branch() never terminates and falls through to the next function, which in the normal case is the hypercall_page. And that, as it happens, is 4095 NOPs and a RET. Make asm_cpu_bringup_and_idle() terminate on it's own, by making the function it calls as a dead-end. This way we no longer rely on what code happens to come after. Fixes: c3881eb58d56 ("x86/xen: Make the secondary CPU idle tasks reliable") Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Juergen Gross Reviewed-by: Miroslav Benes Link: https://lore.kernel.org/r/20210624095147.693801717@infradead.org Signed-off-by: Sasha Levin commit 8d5eda2398109488d4857b6d8fc87fde5dcd96ca Author: Aleksander Jan Bajkowski Date: Tue Sep 14 23:21:00 2021 +0200 MIPS: lantiq: dma: fix burst length for DEU [ Upstream commit 5ad74d39c51dd41b3c819f4f5396655f0629b4fd ] The current definition of 2W burst length is invalid. This patch fixes it. Current downstream DEU driver doesn't use DMA. An incorrect burst length value doesn't cause any errors. This patch also adds other burst length values. Fixes: dfec1a827d2b ("MIPS: Lantiq: Add DMA support") Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 67761195ad8326f3a026c4d042456619855dca00 Author: Neeraj Upadhyay Date: Wed Aug 18 13:34:00 2021 +0530 rcu: Fix existing exp request check in sync_sched_exp_online_cleanup() [ Upstream commit f0b2b2df5423fb369ac762c77900bc7765496d58 ] The sync_sched_exp_online_cleanup() checks to see if RCU needs an expedited quiescent state from the incoming CPU, sending it an IPI if so. Before sending IPI, it checks whether expedited qs need has been already requested for the incoming CPU, by checking rcu_data.cpu_no_qs.b.exp for the current cpu, on which sync_sched_exp_online_cleanup() is running. This works for the case where incoming CPU is same as self. However, for the case where incoming CPU is different from self, expedited request won't get marked, which can potentially delay reporting of expedited quiescent state for the incoming CPU. Fixes: e015a3411220 ("rcu: Avoid self-IPI in sync_sched_exp_online_cleanup()") Signed-off-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 47a4b733e8ff5820a2b9bccf20cb4811ac0ca410 Author: Toke Høiland-Jørgensen Date: Wed Sep 1 13:48:12 2021 +0200 libbpf: Don't crash on object files with no symbol tables [ Upstream commit 03e601f48b2da6fb44d0f7b86957a8f6bacfb347 ] If libbpf encounters an ELF file that has been stripped of its symbol table, it will crash in bpf_object__add_programs() when trying to dereference the obj->efile.symbols pointer. Fix this by erroring out of bpf_object__elf_collect() if it is not able able to find the symbol table. v2: - Move check into bpf_object__elf_collect() and add nice error message Fixes: 6245947c1b3c ("libbpf: Allow gaps in BPF program sections to support overriden weak functions") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20210901114812.204720-1-toke@redhat.com Signed-off-by: Sasha Levin commit db63399389bc3f6b0d146f8020ca243a6b700d9d Author: Desmond Cheong Zhi Xi Date: Thu Sep 2 23:13:06 2021 -0400 Bluetooth: fix init and cleanup of sco_conn.timeout_work [ Upstream commit 49d8a5606428ca0962d09050a5af81461ff90fbb ] Before freeing struct sco_conn, all delayed timeout work should be cancelled. Otherwise, sco_sock_timeout could potentially use the sco_conn after it has been freed. Additionally, sco_conn.timeout_work should be initialized when the connection is allocated, not when the channel is added. This is because an sco_conn can create channels with multiple sockets over its lifetime, which happens if sockets are released but the connection isn't deleted. Fixes: ba316be1b6a0 ("Bluetooth: schedule SCO timeouts with delayed_work") Signed-off-by: Desmond Cheong Zhi Xi Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin commit 061fb293a9dcd3308a7368821fd5899ebf6dd8a8 Author: Paul Cercueil Date: Fri Aug 27 17:39:56 2021 +0100 drm/bridge: it66121: Wait for next bridge to be probed [ Upstream commit 8b03e3fc79189b17d31a82f5e175698802a11e87 ] If run before the next bridge is initialized, of_drm_find_bridge() will give us a NULL pointer. If that's the case, return -EPROBE_DEFER; we may have more luck next time. Signed-off-by: Paul Cercueil Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Reviewed-by: Neil Armstrong Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210827163956.27517-2-paul@crapouillou.net Signed-off-by: Sasha Levin commit 0bf7139300d0b299eac813877135e4295ca9e2cc Author: Paul Cercueil Date: Fri Aug 27 17:39:55 2021 +0100 drm/bridge: it66121: Initialize {device,vendor}_ids [ Upstream commit 3a5f3d61de657bc1c2b53b77d065c5526f982e10 ] These two arrays are populated with data read from the I2C device through regmap_read(), and the data is then compared with hardcoded vendor/product ID values of supported chips. However, the return value of regmap_read() was never checked. This is fine, as long as the two arrays are zero-initialized, so that we don't compare the vendor/product IDs against whatever garbage is left on the stack. Address this issue by zero-initializing these two arrays. Signed-off-by: Paul Cercueil Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver") Reviewed-by: Neil Armstrong Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210827163956.27517-1-paul@crapouillou.net Signed-off-by: Sasha Levin commit 18919d23f7aa2098caeeec62e37348013b3560ef Author: Robert Foss Date: Wed Aug 18 19:13:17 2021 +0200 drm/bridge: anx7625: Propagate errors from sp_tx_rst_aux() [ Upstream commit 7f16d0f3b8e2d13f940e944cd17044ca8eeb8b32 ] The return value of sp_tx_rst_aux() is not propagated, which means both compiler warnings and potential errors not being handled. Fixes: 8bdfc5dae4e3 ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP") Reviewed-by: Sam Ravnborg Reported-by: kernel test robot Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20210818171318.1848272-1-robert.foss@linaro.org Signed-off-by: Sasha Levin commit f53dc812a258e1312922789133154a08810f71bd Author: Imre Deak Date: Mon Aug 9 16:31:46 2021 +0300 fbdev/efifb: Release PCI device's runtime PM ref during FB destroy [ Upstream commit 55285e21f04517939480966164a33898c34b2af2 ] Atm the EFI FB platform driver gets a runtime PM reference for the associated GFX PCI device during probing the EFI FB platform device and releases it only when the platform device gets unbound. When fbcon switches to the FB provided by the PCI device's driver (for instance i915/drmfb), the EFI FB will get only unregistered without the EFI FB platform device getting unbound, keeping the runtime PM reference acquired during the platform device probing. This reference will prevent the PCI driver from runtime suspending the device. Fix this by releasing the RPM reference from the EFI FB's destroy hook, called when the FB gets unregistered. While at it assert that pm_runtime_get_sync() didn't fail. v2: - Move pm_runtime_get_sync() before register_framebuffer() to avoid its race wrt. efifb_destroy()->pm_runtime_put(). (Daniel) - Assert that pm_runtime_get_sync() didn't fail. - Clarify commit message wrt. platform/PCI device/driver and driver removal vs. device unbinding. Fixes: a6c0fd3d5a8b ("efifb: Ensure graphics device for efifb stays at PCI D0") Cc: Kai-Heng Feng Cc: Daniel Vetter Reviewed-by: Daniel Vetter (v1) Acked-by: Alex Deucher Acked-by: Kai-Heng Feng Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20210809133146.2478382-1-imre.deak@intel.com Signed-off-by: Sasha Levin commit f0d5bf1ecb13f6a5e4467549209554a7dd3c6a69 Author: Andrii Nakryiko Date: Fri Oct 29 11:29:07 2021 -0700 selftests/bpf: Fix strobemeta selftest regression [ Upstream commit 0133c20480b14820d43c37c0e9502da4bffcad3a ] After most recent nightly Clang update strobemeta selftests started failing with the following error (relevant portion of assembly included): 1624: (85) call bpf_probe_read_user_str#114 1625: (bf) r1 = r0 1626: (18) r2 = 0xfffffffe 1628: (5f) r1 &= r2 1629: (55) if r1 != 0x0 goto pc+7 1630: (07) r9 += 104 1631: (6b) *(u16 *)(r9 +0) = r0 1632: (67) r0 <<= 32 1633: (77) r0 >>= 32 1634: (79) r1 = *(u64 *)(r10 -456) 1635: (0f) r1 += r0 1636: (7b) *(u64 *)(r10 -456) = r1 1637: (79) r1 = *(u64 *)(r10 -368) 1638: (c5) if r1 s< 0x1 goto pc+778 1639: (bf) r6 = r8 1640: (0f) r6 += r7 1641: (b4) w1 = 0 1642: (6b) *(u16 *)(r6 +108) = r1 1643: (79) r3 = *(u64 *)(r10 -352) 1644: (79) r9 = *(u64 *)(r10 -456) 1645: (bf) r1 = r9 1646: (b4) w2 = 1 1647: (85) call bpf_probe_read_user_str#114 R1 unbounded memory access, make sure to bounds check any such access In the above code r0 and r1 are implicitly related. Clang knows that, but verifier isn't able to infer this relationship. Yonghong Song narrowed down this "regression" in code generation to a recent Clang optimization change ([0]), which for BPF target generates code pattern that BPF verifier can't handle and loses track of register boundaries. This patch works around the issue by adding an BPF assembly-based helper that helps to prove to the verifier that upper bound of the register is a given constant by controlling the exact share of generated BPF instruction sequence. This fixes the immediate issue for strobemeta selftest. [0] https://github.com/llvm/llvm-project/commit/acabad9ff6bf13e00305d9d8621ee8eafc1f8b08 Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20211029182907.166910-1-andrii@kernel.org Signed-off-by: Sasha Levin commit d6a0aa933c86a31ec67ab8a36c01c7052d914691 Author: Pablo Neira Ayuso Date: Mon Oct 25 11:26:49 2021 +0200 netfilter: conntrack: set on IPS_ASSURED if flows enters internal stream state [ Upstream commit b7b1d02fc43925a4d569ec221715db2dfa1ce4f5 ] The internal stream state sets the timeout to 120 seconds 2 seconds after the creation of the flow, attach this internal stream state to the IPS_ASSURED flag for consistent event reporting. Before this patch: [NEW] udp 17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 [UNREPLIED] src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [UPDATE] udp 17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [UPDATE] udp 17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED] [DESTROY] udp 17 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED] Note IPS_ASSURED for the flow not yet in the internal stream state. after this update: [NEW] udp 17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 [UNREPLIED] src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [UPDATE] udp 17 30 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [UPDATE] udp 17 120 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED] [DESTROY] udp 17 src=10.246.11.13 dst=216.239.35.0 sport=37282 dport=123 src=216.239.35.0 dst=10.246.11.13 sport=123 dport=37282 [ASSURED] Before this patch, short-lived UDP flows never entered IPS_ASSURED, so they were already candidate flow to be deleted by early_drop under stress. Before this patch, IPS_ASSURED is set on regardless the internal stream state, attach this internal stream state to IPS_ASSURED. packet #1 (original direction) enters NEW state packet #2 (reply direction) enters ESTABLISHED state, sets on IPS_SEEN_REPLY paclet #3 (any direction) sets on IPS_ASSURED (if 2 seconds since the creation has passed by). Reported-by: Maciej Żenczykowski Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 68af9d200661f4cd6219b3b9854809376d696009 Author: Sven Schnelle Date: Fri Oct 15 21:49:23 2021 +0200 parisc/kgdb: add kgdb_roundup() to make kgdb work with idle polling [ Upstream commit 66e29fcda1824f0427966fbee2bd2c85bf362c82 ] With idle polling, IPIs are not sent when a CPU idle, but queued and run later from do_idle(). The default kgdb_call_nmi_hook() implementation gets the pointer to struct pt_regs from get_irq_reqs(), which doesn't work in that case because it was not called from the IPI interrupt handler. Fix it by defining our own kgdb_roundup() function which sents an IPI_ENTER_KGDB. When that IPI is received on the target CPU kgdb_nmicallback() is called. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit db209b320754d46d4fb6bbd11472f2f90e0a550b Author: Sven Schnelle Date: Sat Oct 9 23:15:17 2021 +0200 parisc/unwind: fix unwinder when CONFIG_64BIT is enabled [ Upstream commit 8e0ba125c2bf1030af3267058019ba86da96863f ] With 64 bit kernels unwind_special() is not working because it compares the pc to the address of the function descriptor. Add a helper function that compares pc with the dereferenced address. This fixes all of the backtraces on my c8000. Without this changes, a lot of backtraces are missing in kdb or the show-all-tasks command from /proc/sysrq-trigger. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 2ce1c884ad0b3f8316425553724fec6be1754fe1 Author: Gao Xiang Date: Mon Oct 25 15:43:11 2021 +0800 erofs: don't trigger WARN() when decompression fails [ Upstream commit a0961f351d82d43ab0b845304caa235dfe249ae9 ] syzbot reported a WARNING [1] due to corrupted compressed data. As Dmitry said, "If this is not a kernel bug, then the code should not use WARN. WARN if for kernel bugs and is recognized as such by all testing systems and humans." [1] https://lore.kernel.org/r/000000000000b3586105cf0ff45e@google.com Link: https://lore.kernel.org/r/20211025074311.130395-1-hsiangkao@linux.alibaba.com Cc: Dmitry Vyukov Reviewed-by: Chao Yu Reported-by: syzbot+d8aaffc3719597e8cfb4@syzkaller.appspotmail.com Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit a55c2f265b80994553fb8a7d14ff97fa8b347db4 Author: Helge Deller Date: Tue Oct 5 00:05:43 2021 +0200 task_stack: Fix end_of_stack() for architectures with upwards-growing stack [ Upstream commit 9cc2fa4f4a92ccc6760d764e7341be46ee8aaaa1 ] The function end_of_stack() returns a pointer to the last entry of a stack. For architectures like parisc where the stack grows upwards return the pointer to the highest address in the stack. Without this change I faced a crash on parisc, because the stackleak functionality wrote STACKLEAK_POISON to the lowest address and thus overwrote the first 4 bytes of the task_struct which included the TIF_FLAGS. Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 3129c659e256880d2c50347fdbb569df8aa32022 Author: Sven Schnelle Date: Sat Oct 9 20:24:39 2021 +0200 parisc: fix warning in flush_tlb_all [ Upstream commit 1030d681319b43869e0d5b568b9d0226652d1a6f ] I've got the following splat after enabling preemption: [ 3.724721] BUG: using __this_cpu_add() in preemptible [00000000] code: swapper/0/1 [ 3.734630] caller is __this_cpu_preempt_check+0x38/0x50 [ 3.740635] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.15.0-rc4-64bit+ #324 [ 3.744605] Hardware name: 9000/785/C8000 [ 3.744605] Backtrace: [ 3.744605] [<00000000401d9d58>] show_stack+0x74/0xb0 [ 3.744605] [<0000000040c27bd4>] dump_stack_lvl+0x10c/0x188 [ 3.744605] [<0000000040c27c84>] dump_stack+0x34/0x48 [ 3.744605] [<0000000040c33438>] check_preemption_disabled+0x178/0x1b0 [ 3.744605] [<0000000040c334f8>] __this_cpu_preempt_check+0x38/0x50 [ 3.744605] [<00000000401d632c>] flush_tlb_all+0x58/0x2e0 [ 3.744605] [<00000000401075c0>] 0x401075c0 [ 3.744605] [<000000004010b8fc>] 0x4010b8fc [ 3.744605] [<00000000401080fc>] 0x401080fc [ 3.744605] [<00000000401d5224>] do_one_initcall+0x128/0x378 [ 3.744605] [<0000000040102de8>] 0x40102de8 [ 3.744605] [<0000000040c33864>] kernel_init+0x60/0x3a8 [ 3.744605] [<00000000401d1020>] ret_from_kernel_thread+0x20/0x28 [ 3.744605] Fix this by moving the __inc_irq_stat() into the locked section. Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 65fadad6022d0bf08f1792ae6e9cc3aeda3cadce Author: Stephane Eranian Date: Wed Oct 13 17:12:14 2021 -0700 perf/x86/intel: Fix ICL/SPR INST_RETIRED.PREC_DIST encodings [ Upstream commit 2de71ee153efa93099d2ab864acffeec70a8dcd5 ] This patch fixes the encoding for INST_RETIRED.PREC_DIST as published by Intel (download.01.org/perfmon/) for Icelake. The official encoding is event code 0x00 umask 0x1, a change from Skylake where it was code 0xc0 umask 0x1. With this patch applied it is possible to run: $ perf record -a -e cpu/event=0x00,umask=0x1/pp ..... Whereas before this would fail. To avoid problems with tools which may use the old code, we maintain the old encoding for Icelake. Signed-off-by: Stephane Eranian Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211014001214.2680534-1-eranian@google.com Signed-off-by: Sasha Levin commit f206bd751daa274fc2998cde6ea3c7f43631e637 Author: Shuah Khan Date: Wed Oct 27 13:26:19 2021 -0600 selftests/core: fix conflicting types compile error for close_range() [ Upstream commit f35dcaa0a8a29188ed61083d153df1454cf89d08 ] close_range() test type conflicts with close_range() library call in x86_64-linux-gnu/bits/unistd_ext.h. Fix it by changing the name to core_close_range(). gcc -g -I../../../../usr/include/ close_range_test.c -o ../tools/testing/selftests/core/close_range_test In file included from close_range_test.c:16: close_range_test.c:57:6: error: conflicting types for ‘close_range’; have ‘void(struct __test_metadata *)’ 57 | TEST(close_range) | ^~~~~~~~~~~ ../kselftest_harness.h:181:21: note: in definition of macro ‘__TEST_IMPL’ 181 | static void test_name(struct __test_metadata *_metadata); \ | ^~~~~~~~~ close_range_test.c:57:1: note: in expansion of macro ‘TEST’ 57 | TEST(close_range) | ^~~~ In file included from /usr/include/unistd.h:1204, from close_range_test.c:13: /usr/include/x86_64-linux-gnu/bits/unistd_ext.h:56:12: note: previous declaration of ‘close_range’ with type ‘int(unsigned int, unsigned int, int)’ 56 | extern int close_range (unsigned int __fd, unsigned int __max_fd, | ^~~~~~~~~~~ Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 9be249debf4d5f1d20fc4bb775b2fb159f538b1c Author: Anson Jacob Date: Fri Sep 17 18:29:36 2021 -0400 drm/amd/display: dcn20_resource_construct reduce scope of FPU enabled [ Upstream commit bc39a69a2ac484e6575a958567c162ef56c9f278 ] Limit when FPU is enabled to only functions that does FPU operations for dcn20_resource_construct, which gets called during driver initialization. Enabling FPU operation disables preemption. Sleeping functions(mutex (un)lock, memory allocation using GFP_KERNEL, etc.) should not be called when preemption is disabled. Fixes the following case caught by enabling CONFIG_DEBUG_ATOMIC_SLEEP in kernel config [ 1.338434] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281 [ 1.347395] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 197, name: systemd-udevd [ 1.356356] CPU: 7 PID: 197 Comm: systemd-udevd Not tainted 5.13.0+ #3 [ 1.356358] Hardware name: System manufacturer System Product Name/PRIME X570-PRO, BIOS 3405 02/01/2021 [ 1.356360] Call Trace: [ 1.356361] dump_stack+0x6b/0x86 [ 1.356366] ___might_sleep.cold+0x87/0x98 [ 1.356370] __might_sleep+0x4b/0x80 [ 1.356372] mutex_lock+0x21/0x50 [ 1.356376] smu_get_uclk_dpm_states+0x3f/0x80 [amdgpu] [ 1.356538] pp_nv_get_uclk_dpm_states+0x35/0x50 [amdgpu] [ 1.356711] init_soc_bounding_box+0xf9/0x210 [amdgpu] [ 1.356892] ? create_object+0x20d/0x340 [ 1.356897] ? dcn20_resource_construct+0x46f/0xd30 [amdgpu] [ 1.357077] dcn20_resource_construct+0x4b1/0xd30 [amdgpu] ... Tested on: 5700XT (NAVI10 0x1002:0x731F 0x1DA2:0xE410 0xC1) Cc: Christian König Cc: Hersen Wu Cc: Anson Jacob Cc: Harry Wentland Reviewed-by: Rodrigo Siqueira Tested-by: Daniel Wheeler Acked-by: Agustin Gutierrez Signed-off-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2acb2cdcfc832a18ca71ec58ecc0fa03a388545a Author: Vitaly Kuznetsov Date: Tue Oct 12 17:50:05 2021 +0200 x86/hyperv: Protect set_hv_tscchange_cb() against getting preempted [ Upstream commit 285f68afa8b20f752b0b7194d54980b5e0e27b75 ] The following issue is observed with CONFIG_DEBUG_PREEMPT when KVM loads: KVM: vmx: using Hyper-V Enlightened VMCS BUG: using smp_processor_id() in preemptible [00000000] code: systemd-udevd/488 caller is set_hv_tscchange_cb+0x16/0x80 CPU: 1 PID: 488 Comm: systemd-udevd Not tainted 5.15.0-rc5+ #396 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019 Call Trace: dump_stack_lvl+0x6a/0x9a check_preemption_disabled+0xde/0xe0 ? kvm_gen_update_masterclock+0xd0/0xd0 [kvm] set_hv_tscchange_cb+0x16/0x80 kvm_arch_init+0x23f/0x290 [kvm] kvm_init+0x30/0x310 [kvm] vmx_init+0xaf/0x134 [kvm_intel] ... set_hv_tscchange_cb() can get preempted in between acquiring smp_processor_id() and writing to HV_X64_MSR_REENLIGHTENMENT_CONTROL. This is not an issue by itself: HV_X64_MSR_REENLIGHTENMENT_CONTROL is a partition-wide MSR and it doesn't matter which particular CPU will be used to receive reenlightenment notifications. The only real problem can (in theory) be observed if the CPU whose id was acquired with smp_processor_id() goes offline before we manage to write to the MSR, the logic in hv_cpu_die() won't be able to reassign it correctly. Reported-by: Michael Kelley Signed-off-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/20211012155005.1613352-1-vkuznets@redhat.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 19f1aba96f858f1e99d845487b7f2d688550801a Author: 王贇 Date: Wed Oct 27 11:15:11 2021 +0800 ftrace: do CPU checking after preemption disabled [ Upstream commit d33cc657372366a8959f099c619a208b4c5dc664 ] With CONFIG_DEBUG_PREEMPT we observed reports like: BUG: using smp_processor_id() in preemptible caller is perf_ftrace_function_call+0x6f/0x2e0 CPU: 1 PID: 680 Comm: a.out Not tainted Call Trace: dump_stack_lvl+0x8d/0xcf check_preemption_disabled+0x104/0x110 ? optimize_nops.isra.7+0x230/0x230 ? text_poke_bp_batch+0x9f/0x310 perf_ftrace_function_call+0x6f/0x2e0 ... __text_poke+0x5/0x620 text_poke_bp_batch+0x9f/0x310 This telling us the CPU could be changed after task is preempted, and the checking on CPU before preemption will be invalid. Since now ftrace_test_recursion_trylock() will help to disable the preemption, this patch just do the checking after trylock() to address the issue. Link: https://lkml.kernel.org/r/54880691-5fe2-33e7-d12f-1fa6136f5183@linux.alibaba.com CC: Steven Rostedt Cc: Guo Ren Cc: Ingo Molnar Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Thomas Gleixner Cc: Borislav Petkov Cc: "H. Peter Anvin" Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr Mladek Cc: Joe Lawrence Cc: Masami Hiramatsu Cc: "Peter Zijlstra (Intel)" Cc: Nicholas Piggin Cc: Jisheng Zhang Reported-by: Abaci Signed-off-by: Michael Wang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit a48bd49ee8710ee3cc1ac44ac71209f5b21a4226 Author: Bryan O'Donoghue Date: Mon Oct 25 10:30:37 2021 +0100 Revert "wcn36xx: Enable firmware link monitoring" [ Upstream commit 43ea9bd84f27d06482cc823d9749cc9dd2993bc8 ] Firmware link offload monitoring can be made to work in 3/4 cases by switching on firmware feature bit WLANACTIVE_OFFLOAD - Secure power-save on - Secure power-save off - Open power-save on However, with an open AP if we switch off power-saving - thus never entering Beacon Mode Power Save - BMPS, firmware never forwards loss of beacon upwards. We had hoped that WLANACTIVE_OFFLOAD and some fixes for sequence numbers would unblock this but, it hasn't and further investigation is required. Its possible to have a complete set of Secure power-save on/off and Open power-save on/off provided we use Linux' link monitoring mechanism. While we debug the Open AP failure we need to fix upstream. This reverts commit c973fdad79f6eaf247d48b5fc77733e989eb01e1. Signed-off-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211025093037.3966022-2-bryan.odonoghue@linaro.org Signed-off-by: Sasha Levin commit 944285a0395631a3a87d2fe51a3429d1a400fb9c Author: Loic Poulain Date: Mon Oct 25 10:28:16 2021 +0200 wcn36xx: Fix packet drop on resume [ Upstream commit df0697801d8aa2eebfe7f0b7388879639f8fe7cc ] If the system is resumed because of an incoming packet, the wcn36xx RX interrupts is fired before actual resuming of the wireless/mac80211 stack, causing any received packets to be simply dropped. E.g. a ping request causes a system resume, but is dropped and so never forwarded to the IP stack. This change fixes that, disabling DMA interrupts on suspend to no pass packets until mac80211 is resumed and ready to handle them. Note that it's not incompatible with RX irq wake. Signed-off-by: Loic Poulain Reviewed-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1635150496-19290-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit 478d239fea122292f3196a304289213d44d93a20 Author: Loic Poulain Date: Mon Oct 18 12:57:57 2021 +0200 wcn36xx: Correct band/freq reporting on RX [ Upstream commit 8a27ca39478270e07baf9c09aa0c99709769ba03 ] For packets originating from hardware scan, the channel and band is included in the buffer descriptor (bd->rf_band & bd->rx_ch). For 2Ghz band the channel value is directly reported in the 4-bit rx_ch field. For 5Ghz band, the rx_ch field contains a mapping index (given the 4-bit limitation). The reserved0 value field is also used to extend 4-bit mapping to 5-bit mapping to support more than 16 5Ghz channels. This change adds correct reporting of the frequency/band, that is used in scan mechanism. And is required for 5Ghz hardware scan support. Signed-off-by: Loic Poulain Tested-by: Bryan O'Donoghue Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1634554678-7993-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Sasha Levin commit 3874ef316cfe105089b32774c442031a9bd6b82c Author: Yang Yingliang Date: Mon Oct 18 15:34:13 2021 +0800 spi: bcm-qspi: Fix missing clk_disable_unprepare() on error in bcm_qspi_probe() [ Upstream commit ca9b8f56ec089d3a436050afefd17b7237301f47 ] Fix the missing clk_disable_unprepare() before return from bcm_qspi_probe() in the error handling case. Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211018073413.2029081-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9124f94eeeb1e10da4dbf277a65341c18bc3acac Author: Josef Bacik Date: Tue Jul 27 17:01:14 2021 -0400 btrfs: do not take the uuid_mutex in btrfs_rm_device [ Upstream commit 8ef9dc0f14ba6124c62547a4fdc59b163d8b864e ] We got the following lockdep splat while running fstests (specifically btrfs/003 and btrfs/020 in a row) with the new rc. This was uncovered by 87579e9b7d8d ("loop: use worker per cgroup instead of kworker") which converted loop to using workqueues, which comes with lockdep annotations that don't exist with kworkers. The lockdep splat is as follows: WARNING: possible circular locking dependency detected 5.14.0-rc2-custom+ #34 Not tainted ------------------------------------------------------ losetup/156417 is trying to acquire lock: ffff9c7645b02d38 ((wq_completion)loop0){+.+.}-{0:0}, at: flush_workqueue+0x84/0x600 but task is already holding lock: ffff9c7647395468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x650 [loop] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #5 (&lo->lo_mutex){+.+.}-{3:3}: __mutex_lock+0xba/0x7c0 lo_open+0x28/0x60 [loop] blkdev_get_whole+0x28/0xf0 blkdev_get_by_dev.part.0+0x168/0x3c0 blkdev_open+0xd2/0xe0 do_dentry_open+0x163/0x3a0 path_openat+0x74d/0xa40 do_filp_open+0x9c/0x140 do_sys_openat2+0xb1/0x170 __x64_sys_openat+0x54/0x90 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #4 (&disk->open_mutex){+.+.}-{3:3}: __mutex_lock+0xba/0x7c0 blkdev_get_by_dev.part.0+0xd1/0x3c0 blkdev_get_by_path+0xc0/0xd0 btrfs_scan_one_device+0x52/0x1f0 [btrfs] btrfs_control_ioctl+0xac/0x170 [btrfs] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #3 (uuid_mutex){+.+.}-{3:3}: __mutex_lock+0xba/0x7c0 btrfs_rm_device+0x48/0x6a0 [btrfs] btrfs_ioctl+0x2d1c/0x3110 [btrfs] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #2 (sb_writers#11){.+.+}-{0:0}: lo_write_bvec+0x112/0x290 [loop] loop_process_work+0x25f/0xcb0 [loop] process_one_work+0x28f/0x5d0 worker_thread+0x55/0x3c0 kthread+0x140/0x170 ret_from_fork+0x22/0x30 -> #1 ((work_completion)(&lo->rootcg_work)){+.+.}-{0:0}: process_one_work+0x266/0x5d0 worker_thread+0x55/0x3c0 kthread+0x140/0x170 ret_from_fork+0x22/0x30 -> #0 ((wq_completion)loop0){+.+.}-{0:0}: __lock_acquire+0x1130/0x1dc0 lock_acquire+0xf5/0x320 flush_workqueue+0xae/0x600 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x650 [loop] lo_ioctl+0x29d/0x780 [loop] block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: (wq_completion)loop0 --> &disk->open_mutex --> &lo->lo_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&lo->lo_mutex); lock(&disk->open_mutex); lock(&lo->lo_mutex); lock((wq_completion)loop0); *** DEADLOCK *** 1 lock held by losetup/156417: #0: ffff9c7647395468 (&lo->lo_mutex){+.+.}-{3:3}, at: __loop_clr_fd+0x41/0x650 [loop] stack backtrace: CPU: 8 PID: 156417 Comm: losetup Not tainted 5.14.0-rc2-custom+ #34 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x57/0x72 check_noncircular+0x10a/0x120 __lock_acquire+0x1130/0x1dc0 lock_acquire+0xf5/0x320 ? flush_workqueue+0x84/0x600 flush_workqueue+0xae/0x600 ? flush_workqueue+0x84/0x600 drain_workqueue+0xa0/0x110 destroy_workqueue+0x36/0x250 __loop_clr_fd+0x9a/0x650 [loop] lo_ioctl+0x29d/0x780 [loop] ? __lock_acquire+0x3a0/0x1dc0 ? update_dl_rq_load_avg+0x152/0x360 ? lock_is_held_type+0xa5/0x120 ? find_held_lock.constprop.0+0x2b/0x80 block_ioctl+0x3f/0x50 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f645884de6b Usually the uuid_mutex exists to protect the fs_devices that map together all of the devices that match a specific uuid. In rm_device we're messing with the uuid of a device, so it makes sense to protect that here. However in doing that it pulls in a whole host of lockdep dependencies, as we call mnt_may_write() on the sb before we grab the uuid_mutex, thus we end up with the dependency chain under the uuid_mutex being added under the normal sb write dependency chain, which causes problems with loop devices. We don't need the uuid mutex here however. If we call btrfs_scan_one_device() before we scratch the super block we will find the fs_devices and not find the device itself and return EBUSY because the fs_devices is open. If we call it after the scratch happens it will not appear to be a valid btrfs file system. We do not need to worry about other fs_devices modifying operations here because we're protected by the exclusive operations locking. So drop the uuid_mutex here in order to fix the lockdep splat. A more detailed explanation from the discussion: We are worried about rm and scan racing with each other, before this change we'll zero the device out under the UUID mutex so when scan does run it'll make sure that it can go through the whole device scan thing without rm messing with us. We aren't worried if the scratch happens first, because the result is we don't think this is a btrfs device and we bail out. The only case we are concerned with is we scratch _after_ scan is able to read the superblock and gets a seemingly valid super block, so lets consider this case. Scan will call device_list_add() with the device we're removing. We'll call find_fsid_with_metadata_uuid() and get our fs_devices for this UUID. At this point we lock the fs_devices->device_list_mutex. This is what protects us in this case, but we have two cases here. 1. We aren't to the device removal part of the RM. We found our device, and device name matches our path, we go down and we set total_devices to our super number of devices, which doesn't affect anything because we haven't done the remove yet. 2. We are past the device removal part, which is protected by the device_list_mutex. Scan doesn't find the device, it goes down and does the if (fs_devices->opened) return -EBUSY; check and we bail out. Nothing about this situation is ideal, but the lockdep splat is real, and the fix is safe, tho admittedly a bit scary looking. Reviewed-by: Anand Jain Signed-off-by: Josef Bacik Reviewed-by: David Sterba [ copy more from the discussion ] Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 55c9fca5f56d3d3242b4c1035479d8311f3b2e2a Author: Sidong Yang Date: Thu Aug 26 14:44:36 2021 +0000 btrfs: reflink: initialize return value to 0 in btrfs_extent_same() [ Upstream commit 44bee215f72f13874c0e734a0712c2e3264c0108 ] Fix a warning reported by smatch that ret could be returned without initialized. The dedupe operations are supposed to to return 0 for a 0 length range but the caller does not pass olen == 0. To keep this behaviour and also fix the warning initialize ret to 0. Reviewed-by: Filipe Manana Signed-off-by: Sidong Yang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit e9941a010249492751dc4bf8b61d6a9838352e82 Author: Hui Wang Date: Mon Oct 25 14:16:01 2021 +0800 ACPI: resources: Add one more Medion model in IRQ override quirk [ Upstream commit 1b26ae40092b43bb6e9c5df376227382b390b953 ] The Medion s17 series laptops have the same issue on the keyboard as the s15 series, if skipping to call acpi_get_override_irq(), the keyboard could work well. So put the DMI info of s17 series in the IRQ override quirk table as well. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213031 Tested-by: dirksche Signed-off-by: Hui Wang Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit efa7308f7821793788e5d553f7a92bf0fb4d0aac Author: Stefan Schaeckeler Date: Sun Oct 24 15:04:45 2021 -0700 ACPI: AC: Quirk GK45 to skip reading _PSR [ Upstream commit 3d730ee686800d71ecc5c3cb8460dcdcdeaf38a3 ] Let GK45 not go into BIOS for determining the AC power state. The BIOS wrongly returns 0, so hardcode the power state to 1. The mini PC GK45 by Besstar Tech Lld. (aka Kodlix) just runs off AC. It does not include any batteries. Nevertheless BIOS reports AC off: root@kodlix:/usr/src/linux# cat /sys/class/power_supply/ADP1/online 0 root@kodlix:/usr/src/linux# modprobe acpi_dbg root@kodlix:/usr/src/linux# tools/power/acpi/acpidbg - find _PSR \_SB.PCI0.SBRG.H_EC.ADP1._PSR Method 000000009283cee8 001 Args 0 Len 001C Aml 00000000f54e5f67 - execute \_SB.PCI0.SBRG.H_EC.ADP1._PSR Evaluating \_SB.PCI0.SBRG.H_EC.ADP1._PSR Evaluation of \_SB.PCI0.SBRG.H_EC.ADP1._PSR returned object 00000000dc08c187, external buffer length 18 [Integer] = 0000000000000000 that should be [Integer] = 0000000000000001 Signed-off-by: Stefan Schaeckeler Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 6cbda510dc1ba43a030f2c7bdb84c3bf77b07348 Author: Eric Dumazet Date: Mon Oct 25 11:15:55 2021 -0700 net: annotate data-race in neigh_output() [ Upstream commit d18785e213866935b4c3dc0c33c3e18801ce0ce8 ] neigh_output() reads n->nud_state and hh->hh_len locklessly. This is fine, but we need to add annotations and document this. We evaluate skip_cache first to avoid reading these fields if the cache has to by bypassed. syzbot report: BUG: KCSAN: data-race in __neigh_event_send / ip_finish_output2 write to 0xffff88810798a885 of 1 bytes by interrupt on cpu 1: __neigh_event_send+0x40d/0xac0 net/core/neighbour.c:1128 neigh_event_send include/net/neighbour.h:444 [inline] neigh_resolve_output+0x104/0x410 net/core/neighbour.c:1476 neigh_output include/net/neighbour.h:510 [inline] ip_finish_output2+0x80a/0xaa0 net/ipv4/ip_output.c:221 ip_finish_output+0x3b5/0x510 net/ipv4/ip_output.c:309 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip_output+0xf3/0x1a0 net/ipv4/ip_output.c:423 dst_output include/net/dst.h:450 [inline] ip_local_out+0x164/0x220 net/ipv4/ip_output.c:126 __ip_queue_xmit+0x9d3/0xa20 net/ipv4/ip_output.c:525 ip_queue_xmit+0x34/0x40 net/ipv4/ip_output.c:539 __tcp_transmit_skb+0x142a/0x1a00 net/ipv4/tcp_output.c:1405 tcp_transmit_skb net/ipv4/tcp_output.c:1423 [inline] tcp_xmit_probe_skb net/ipv4/tcp_output.c:4011 [inline] tcp_write_wakeup+0x4a9/0x810 net/ipv4/tcp_output.c:4064 tcp_send_probe0+0x2c/0x2b0 net/ipv4/tcp_output.c:4079 tcp_probe_timer net/ipv4/tcp_timer.c:398 [inline] tcp_write_timer_handler+0x394/0x520 net/ipv4/tcp_timer.c:626 tcp_write_timer+0xb9/0x180 net/ipv4/tcp_timer.c:642 call_timer_fn+0x2e/0x1d0 kernel/time/timer.c:1421 expire_timers+0x135/0x240 kernel/time/timer.c:1466 __run_timers+0x368/0x430 kernel/time/timer.c:1734 run_timer_softirq+0x19/0x30 kernel/time/timer.c:1747 __do_softirq+0x12c/0x26e kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu kernel/softirq.c:636 [inline] irq_exit_rcu+0x4e/0xa0 kernel/softirq.c:648 sysvec_apic_timer_interrupt+0x69/0x80 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] acpi_safe_halt drivers/acpi/processor_idle.c:109 [inline] acpi_idle_do_entry drivers/acpi/processor_idle.c:553 [inline] acpi_idle_enter+0x258/0x2e0 drivers/acpi/processor_idle.c:688 cpuidle_enter_state+0x2b4/0x760 drivers/cpuidle/cpuidle.c:237 cpuidle_enter+0x3c/0x60 drivers/cpuidle/cpuidle.c:351 call_cpuidle kernel/sched/idle.c:158 [inline] cpuidle_idle_call kernel/sched/idle.c:239 [inline] do_idle+0x1a3/0x250 kernel/sched/idle.c:306 cpu_startup_entry+0x15/0x20 kernel/sched/idle.c:403 secondary_startup_64_no_verify+0xb1/0xbb read to 0xffff88810798a885 of 1 bytes by interrupt on cpu 0: neigh_output include/net/neighbour.h:507 [inline] ip_finish_output2+0x79a/0xaa0 net/ipv4/ip_output.c:221 ip_finish_output+0x3b5/0x510 net/ipv4/ip_output.c:309 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip_output+0xf3/0x1a0 net/ipv4/ip_output.c:423 dst_output include/net/dst.h:450 [inline] ip_local_out+0x164/0x220 net/ipv4/ip_output.c:126 __ip_queue_xmit+0x9d3/0xa20 net/ipv4/ip_output.c:525 ip_queue_xmit+0x34/0x40 net/ipv4/ip_output.c:539 __tcp_transmit_skb+0x142a/0x1a00 net/ipv4/tcp_output.c:1405 tcp_transmit_skb net/ipv4/tcp_output.c:1423 [inline] tcp_xmit_probe_skb net/ipv4/tcp_output.c:4011 [inline] tcp_write_wakeup+0x4a9/0x810 net/ipv4/tcp_output.c:4064 tcp_send_probe0+0x2c/0x2b0 net/ipv4/tcp_output.c:4079 tcp_probe_timer net/ipv4/tcp_timer.c:398 [inline] tcp_write_timer_handler+0x394/0x520 net/ipv4/tcp_timer.c:626 tcp_write_timer+0xb9/0x180 net/ipv4/tcp_timer.c:642 call_timer_fn+0x2e/0x1d0 kernel/time/timer.c:1421 expire_timers+0x135/0x240 kernel/time/timer.c:1466 __run_timers+0x368/0x430 kernel/time/timer.c:1734 run_timer_softirq+0x19/0x30 kernel/time/timer.c:1747 __do_softirq+0x12c/0x26e kernel/softirq.c:558 invoke_softirq kernel/softirq.c:432 [inline] __irq_exit_rcu kernel/softirq.c:636 [inline] irq_exit_rcu+0x4e/0xa0 kernel/softirq.c:648 sysvec_apic_timer_interrupt+0x69/0x80 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 native_safe_halt arch/x86/include/asm/irqflags.h:51 [inline] arch_safe_halt arch/x86/include/asm/irqflags.h:89 [inline] acpi_safe_halt drivers/acpi/processor_idle.c:109 [inline] acpi_idle_do_entry drivers/acpi/processor_idle.c:553 [inline] acpi_idle_enter+0x258/0x2e0 drivers/acpi/processor_idle.c:688 cpuidle_enter_state+0x2b4/0x760 drivers/cpuidle/cpuidle.c:237 cpuidle_enter+0x3c/0x60 drivers/cpuidle/cpuidle.c:351 call_cpuidle kernel/sched/idle.c:158 [inline] cpuidle_idle_call kernel/sched/idle.c:239 [inline] do_idle+0x1a3/0x250 kernel/sched/idle.c:306 cpu_startup_entry+0x15/0x20 kernel/sched/idle.c:403 rest_init+0xee/0x100 init/main.c:734 arch_call_rest_init+0xa/0xb start_kernel+0x5e4/0x669 init/main.c:1142 secondary_startup_64_no_verify+0xb1/0xbb value changed: 0x20 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.15.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5b37f3fa42b403397700860cce9520ed8d3ebebb Author: Florian Westphal Date: Mon Oct 25 16:14:00 2021 +0200 vrf: run conntrack only in context of lower/physdev for locally generated packets [ Upstream commit 8c9c296adfae9ea05f655d69e9f6e13daa86fb4a ] The VRF driver invokes netfilter for output+postrouting hooks so that users can create rules that check for 'oif $vrf' rather than lower device name. This is a problem when NAT rules are configured. To avoid any conntrack involvement in round 1, tag skbs as 'untracked' to prevent conntrack from picking them up. This gets cleared before the packet gets handed to the ip stack so conntrack will be active on the second iteration. One remaining issue is that a rule like output ... oif $vrfname notrack won't propagate to the second round because we can't tell 'notrack set via ruleset' and 'notrack set by vrf driver' apart. However, this isn't a regression: the 'notrack' removal happens instead of unconditional nf_reset_ct(). I'd also like to avoid leaking more vrf specific conditionals into the netfilter infra. For ingress, conntrack has already been done before the packet makes it to the vrf driver, with this patch egress does connection tracking with lower/physical device as well. Signed-off-by: Florian Westphal Acked-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e43cb595915c49b65cf352753d76086c9e149e43 Author: Viktor Rosendahl Date: Tue Oct 19 18:07:01 2021 +0200 tools/latency-collector: Use correct size when writing queue_full_warning [ Upstream commit f604de20c0a47e0e9518940a1810193678c92fa8 ] queue_full_warning is a pointer, so it is wrong to use sizeof to calculate the number of characters of the string it points to. The effect is that we only print out the first few characters of the warning string. The correct way is to use strlen(). We don't need to add 1 to the strlen() because we don't want to write the terminating null character to stdout. Link: https://lkml.kernel.org/r/20211019160701.15587-1-Viktor.Rosendahl@bmw.de Link: https://lore.kernel.org/r/8fd4bb65ef3da67feac9ce3258cdbe9824752cf1.1629198502.git.jing.yangyang@zte.com.cn Link: https://lore.kernel.org/r/20211012025424.180781-1-davidcomponentone@gmail.com Reported-by: Zeal Robot Signed-off-by: Viktor Rosendahl Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 56d7461776e05d815d72db869ff15af0b7b79efb Author: Arnd Bergmann Date: Mon Oct 18 15:30:06 2021 +0100 ARM: 9136/1: ARMv7-M uses BE-8, not BE-32 [ Upstream commit 345dac33f58894a56d17b92a41be10e16585ceff ] When configuring the kernel for big-endian, we set either BE-8 or BE-32 based on the CPU architecture level. Until linux-4.4, we did not have any ARMv7-M platform allowing big-endian builds, but now i.MX/Vybrid is in that category, adn we get a build error because of this: arch/arm/kernel/module-plts.c: In function 'get_module_plt': arch/arm/kernel/module-plts.c:60:46: error: implicit declaration of function '__opcode_to_mem_thumb32' [-Werror=implicit-function-declaration] This comes down to picking the wrong default, ARMv7-M uses BE8 like ARMv7-A does. Changing the default gets the kernel to compile and presumably works. https://lore.kernel.org/all/1455804123-2526139-2-git-send-email-arnd@arndb.de/ Tested-by: Vladimir Murzin Signed-off-by: Arnd Bergmann Signed-off-by: Russell King (Oracle) Signed-off-by: Sasha Levin commit 7da4447dbbec84f23c2ce4a8ae3b063da8c8178e Author: Andreas Gruenbacher Date: Thu Oct 7 15:57:44 2021 +0200 gfs2: Fix glock_hash_walk bugs [ Upstream commit 7427f3bb49d81525b7dd1d0f7c5f6bbc752e6f0e ] So far, glock_hash_walk took a reference on each glock it iterated over, and it was the examiner's responsibility to drop those references. Dropping the final reference to a glock can sleep and the examiners are called in a RCU critical section with spin locks held, so examiners that didn't need the extra reference had to drop it asynchronously via gfs2_glock_queue_put or similar. This wasn't done correctly in thaw_glock which did call gfs2_glock_put, and not at all in dump_glock_func. Change glock_hash_walk to not take glock references at all. That way, the examiners that don't need them won't have to bother with slow asynchronous puts, and the examiners that do need references can take them themselves. Reported-by: Alexander Aring Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 9b6a3985dc137800511d9e61d2b204592553cf68 Author: Andreas Gruenbacher Date: Mon Oct 11 20:53:02 2021 +0200 gfs2: Cancel remote delete work asynchronously [ Upstream commit 486408d690e130c3adacf816754b97558d715f46 ] In gfs2_inode_lookup and gfs2_create_inode, we're calling gfs2_cancel_delete_work which currently cancels any remote delete work (delete_work_func) synchronously. This means that if the work is currently running, it will wait for it to finish. We're doing this to pevent a previous instance of an inode from having any influence on the next instance. However, delete_work_func uses gfs2_inode_lookup internally, and we can end up in a deadlock when delete_work_func gets interrupted at the wrong time. For example, (1) An inode's iopen glock has delete work queued, but the inode itself has been evicted from the inode cache. (2) The delete work is preempted before reaching gfs2_inode_lookup. (3) Another process recreates the inode (gfs2_create_inode). It tries to cancel any outstanding delete work, which blocks waiting for the ongoing delete work to finish. (4) The delete work calls gfs2_inode_lookup, which blocks waiting for gfs2_create_inode to instantiate and unlock the new inode => deadlock. It turns out that when the delete work notices that its inode has been re-instantiated, it will do nothing. This means that it's safe to cancel the delete work asynchronously. This prevents the kind of deadlock described above. Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit b108a79345c388f167f131b9a80f24dc4f7d27ae Author: Marc Kleine-Budde Date: Wed Oct 13 15:00:10 2021 +0200 can: bittiming: can_fixup_bittiming(): change type of tseg1 and alltseg to unsigned int [ Upstream commit e346290439609a8ac67122418ca2efbad8d0a7e7 ] All timing calculation is done with unsigned integers, so change type of tseg1 and alltseg to unsigned int, too. Link: https://lore.kernel.org/all/20211013130653.1513627-1-mkl@pengutronix.de Link: https://github.com/linux-can/can-utils/pull/314 Reported-by: Gary Bisson Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 3d9d9a77cdbe2a772763f1a4da68871ffe1550f8 Author: Stephen Suryaputra Date: Wed Oct 20 16:06:18 2021 -0400 gre/sit: Don't generate link-local addr if addr_gen_mode is IN6_ADDR_GEN_MODE_NONE [ Upstream commit 61e18ce7348bfefb5688a8bcd4b4d6b37c0f9b2a ] When addr_gen_mode is set to IN6_ADDR_GEN_MODE_NONE, the link-local addr should not be generated. But it isn't the case for GRE (as well as GRE6) and SIT tunnels. Make it so that tunnels consider the addr_gen_mode, especially for IN6_ADDR_GEN_MODE_NONE. Do this in add_v4_addrs() to cover both GRE and SIT only if the addr scope is link. Signed-off-by: Stephen Suryaputra Acked-by: Antonio Quartulli Link: https://lore.kernel.org/r/20211020200618.467342-1-ssuryaextr@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 69bfb5d7122e899a3f57a4ee1d0d0f452e365892 Author: Masami Hiramatsu Date: Thu Oct 21 09:55:17 2021 +0900 ARM: clang: Do not rely on lr register for stacktrace [ Upstream commit b3ea5d56f212ad81328c82454829a736197ebccc ] Currently the stacktrace on clang compiled arm kernel uses the 'lr' register to find the first frame address from pt_regs. However, that is wrong after calling another function, because the 'lr' register is used by 'bl' instruction and never be recovered. As same as gcc arm kernel, directly use the frame pointer (r11) of the pt_regs to find the first frame address. Note that this fixes kretprobe stacktrace issue only with CONFIG_UNWINDER_FRAME_POINTER=y. For the CONFIG_UNWINDER_ARM, we need another fix. Signed-off-by: Masami Hiramatsu Reviewed-by: Nick Desaulniers Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 002f1d6c77581b681cdf5e8b5dfe2ca76ed4e433 Author: Tetsuo Handa Date: Tue Oct 19 20:54:31 2021 +0900 smackfs: use __GFP_NOFAIL for smk_cipso_doi() [ Upstream commit f91488ee15bd3cac467e2d6a361fc2d34d1052ae ] syzbot is reporting kernel panic at smk_cipso_doi() due to memory allocation fault injection [1]. The reason for need to use panic() was not explained. But since no fix was proposed for 18 months, for now let's use __GFP_NOFAIL for utilizing syzbot resource on other bugs. Link: https://syzkaller.appspot.com/bug?extid=89731ccb6fec15ce1c22 [1] Reported-by: syzbot Signed-off-by: Tetsuo Handa Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 6dbc76b0a53d7fca0377e0c1c7dde146d40d835d Author: Johannes Berg Date: Sun Oct 17 11:43:40 2021 +0300 iwlwifi: mvm: disable RX-diversity in powersave [ Upstream commit e5322b9ab5f63536c41301150b7ce64605ce52cc ] Just like we have default SMPS mode as dynamic in powersave, we should not enable RX-diversity in powersave, to reduce power consumption when connected to a non-MIMO AP. Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Link: https://lore.kernel.org/r/iwlwifi.20211017113927.fc896bc5cdaa.I1d11da71b8a5cbe921a37058d5f578f1b14a2023@changeid Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 6cf3abbda5747eaa127664a6879e8eadeee62478 Author: Jiri Olsa Date: Thu Oct 21 13:41:30 2021 +0200 selftests/bpf: Fix perf_buffer test on system with offline cpus [ Upstream commit d4121376ac7a9c81a696d7558789b2f29ef3574e ] The perf_buffer fails on system with offline cpus: # test_progs -t perf_buffer test_perf_buffer:PASS:nr_cpus 0 nsec test_perf_buffer:PASS:nr_on_cpus 0 nsec test_perf_buffer:PASS:skel_load 0 nsec test_perf_buffer:PASS:attach_kprobe 0 nsec test_perf_buffer:PASS:perf_buf__new 0 nsec test_perf_buffer:PASS:epoll_fd 0 nsec skipping offline CPU #24 skipping offline CPU #25 skipping offline CPU #26 skipping offline CPU #27 skipping offline CPU #28 skipping offline CPU #29 skipping offline CPU #30 skipping offline CPU #31 test_perf_buffer:PASS:perf_buffer__poll 0 nsec test_perf_buffer:PASS:seen_cpu_cnt 0 nsec test_perf_buffer:FAIL:buf_cnt got 24, expected 32 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Changing the test to check online cpus instead of possible. Signed-off-by: Jiri Olsa Signed-off-by: Andrii Nakryiko Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20211021114132.8196-2-jolsa@kernel.org Signed-off-by: Sasha Levin commit 65b5763eef821dd570667c8b20f5a2b972aace38 Author: Shuah Khan Date: Thu Oct 21 11:56:03 2021 -0600 selftests: kvm: fix mismatched fclose() after popen() [ Upstream commit c3867ab5924b7a9a0b4a117902a08669d8be7c21 ] get_warnings_count() does fclose() using File * returned from popen(). Fix it to call pclose() as it should. tools/testing/selftests/kvm/x86_64/mmio_warning_test x86_64/mmio_warning_test.c: In function ‘get_warnings_count’: x86_64/mmio_warning_test.c:87:9: warning: ‘fclose’ called on pointer returned from a mismatched allocation function [-Wmismatched-dealloc] 87 | fclose(f); | ^~~~~~~~~ x86_64/mmio_warning_test.c:84:13: note: returned from ‘popen’ 84 | f = popen("dmesg | grep \"WARNING:\" | wc -l", "r"); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Shuah Khan Acked-by: Paolo Bonzini Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 2093b1cdbdbfc2a7a3e6ac299f007f0e4647142d Author: Ye Bin Date: Wed Oct 13 20:19:14 2021 +0800 PM: hibernate: Get block device exclusively in swsusp_check() [ Upstream commit 39fbef4b0f77f9c89c8f014749ca533643a37c9f ] The following kernel crash can be triggered: [ 89.266592] ------------[ cut here ]------------ [ 89.267427] kernel BUG at fs/buffer.c:3020! [ 89.268264] invalid opcode: 0000 [#1] SMP KASAN PTI [ 89.269116] CPU: 7 PID: 1750 Comm: kmmpd-loop0 Not tainted 5.10.0-862.14.0.6.x86_64-08610-gc932cda3cef4-dirty #20 [ 89.273169] RIP: 0010:submit_bh_wbc.isra.0+0x538/0x6d0 [ 89.277157] RSP: 0018:ffff888105ddfd08 EFLAGS: 00010246 [ 89.278093] RAX: 0000000000000005 RBX: ffff888124231498 RCX: ffffffffb2772612 [ 89.279332] RDX: 1ffff11024846293 RSI: 0000000000000008 RDI: ffff888124231498 [ 89.280591] RBP: ffff8881248cc000 R08: 0000000000000001 R09: ffffed1024846294 [ 89.281851] R10: ffff88812423149f R11: ffffed1024846293 R12: 0000000000003800 [ 89.283095] R13: 0000000000000001 R14: 0000000000000000 R15: ffff8881161f7000 [ 89.284342] FS: 0000000000000000(0000) GS:ffff88839b5c0000(0000) knlGS:0000000000000000 [ 89.285711] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 89.286701] CR2: 00007f166ebc01a0 CR3: 0000000435c0e000 CR4: 00000000000006e0 [ 89.287919] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 89.289138] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 89.290368] Call Trace: [ 89.290842] write_mmp_block+0x2ca/0x510 [ 89.292218] kmmpd+0x433/0x9a0 [ 89.294902] kthread+0x2dd/0x3e0 [ 89.296268] ret_from_fork+0x22/0x30 [ 89.296906] Modules linked in: by running the following commands: 1. mkfs.ext4 -O mmp /dev/sda -b 1024 2. mount /dev/sda /home/test 3. echo "/dev/sda" > /sys/power/resume That happens because swsusp_check() calls set_blocksize() on the target partition which confuses the file system: Thread1 Thread2 mount /dev/sda /home/test get s_mmp_bh --> has mapped flag start kmmpd thread echo "/dev/sda" > /sys/power/resume resume_store software_resume swsusp_check set_blocksize truncate_inode_pages_range truncate_cleanup_page block_invalidatepage discard_buffer --> clean mapped flag write_mmp_block submit_bh submit_bh_wbc BUG_ON(!buffer_mapped(bh)) To address this issue, modify swsusp_check() to open the target block device with exclusive access. Signed-off-by: Ye Bin [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit cff152d77d9bd12de1adcdbe0b1320941d6003dd Author: Nick Desaulniers Date: Tue Oct 19 15:36:45 2021 -0700 arm64: vdso32: suppress error message for 'make mrproper' [ Upstream commit 14831fad73f5ac30ac61760487d95a538e6ab3cb ] When running the following command without arm-linux-gnueabi-gcc in one's $PATH, the following warning is observed: $ ARCH=arm64 CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make -j72 LLVM=1 mrproper make[1]: arm-linux-gnueabi-gcc: No such file or directory This is because KCONFIG is not run for mrproper, so CONFIG_CC_IS_CLANG is not set, and we end up eagerly evaluating various variables that try to invoke CC_COMPAT. This is a similar problem to what was observed in commit dc960bfeedb0 ("h8300: suppress error messages for 'make clean'") Reported-by: Lucas Henneman Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Reviewed-by: Vincenzo Frascino Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20211019223646.1146945-4-ndesaulniers@google.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit c6065239b7cbb41cf584b017b4befd6dd9968d63 Author: Hannes Reinecke Date: Wed Oct 20 07:59:10 2021 +0200 nvme: drop scan_lock and always kick requeue list when removing namespaces [ Upstream commit 2b81a5f015199f3d585ce710190a9e87714d3c1e ] When reading the partition table on initial scan hits an I/O error the I/O will hang with the scan_mutex held: [<0>] do_read_cache_page+0x49b/0x790 [<0>] read_part_sector+0x39/0xe0 [<0>] read_lba+0xf9/0x1d0 [<0>] efi_partition+0xf1/0x7f0 [<0>] bdev_disk_changed+0x1ee/0x550 [<0>] blkdev_get_whole+0x81/0x90 [<0>] blkdev_get_by_dev+0x128/0x2e0 [<0>] device_add_disk+0x377/0x3c0 [<0>] nvme_mpath_set_live+0x130/0x1b0 [nvme_core] [<0>] nvme_mpath_add_disk+0x150/0x160 [nvme_core] [<0>] nvme_alloc_ns+0x417/0x950 [nvme_core] [<0>] nvme_validate_or_alloc_ns+0xe9/0x1e0 [nvme_core] [<0>] nvme_scan_work+0x168/0x310 [nvme_core] [<0>] process_one_work+0x231/0x420 and trying to delete the controller will deadlock as it tries to grab the scan mutex: [<0>] nvme_mpath_clear_ctrl_paths+0x25/0x80 [nvme_core] [<0>] nvme_remove_namespaces+0x31/0xf0 [nvme_core] [<0>] nvme_do_delete_ctrl+0x4b/0x80 [nvme_core] As we're now properly ordering the namespace list there is no need to hold the scan_mutex in nvme_mpath_clear_ctrl_paths() anymore. And we always need to kick the requeue list as the path will be marked as unusable and I/O will be requeued _without_ a current path. Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 1e757b23aabe4d8085f0a538f6bcbaed459554d3 Author: Israel Rukshin Date: Wed Oct 6 08:09:45 2021 +0000 nvmet-tcp: fix use-after-free when a port is removed [ Upstream commit 2351ead99ce9164fb42555aee3f96af84c4839e9 ] When removing a port, all its controllers are being removed, but there are queues on the port that doesn't belong to any controller (during connection time). This causes a use-after-free bug for any command that dereferences req->port (like in nvmet_alloc_ctrl). Those queues should be destroyed before freeing the port via configfs. Destroy the remaining queues after the accept_work was cancelled guarantees that no new queue will be created. Signed-off-by: Israel Rukshin Reviewed-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 844bbc958d8eb709413335050441dfcbd4f679b2 Author: Israel Rukshin Date: Wed Oct 6 08:09:44 2021 +0000 nvmet-rdma: fix use-after-free when a port is removed [ Upstream commit fcf73a804c7d6bbf0ea63531c6122aa363852e04 ] When removing a port, all its controllers are being removed, but there are queues on the port that doesn't belong to any controller (during connection time). This causes a use-after-free bug for any command that dereferences req->port (like in nvmet_alloc_ctrl). Those queues should be destroyed before freeing the port via configfs. Destroy the remaining queues after the RDMA-CM was destroyed guarantees that no new queue will be created. Signed-off-by: Israel Rukshin Reviewed-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit f252a62a2507cf8e8c15e2c35003b7c3d5867099 Author: Israel Rukshin Date: Wed Oct 6 08:09:43 2021 +0000 nvmet: fix use-after-free when a port is removed [ Upstream commit e3e19dcc4c416d65f99f13d55be2b787f8d0050e ] When a port is removed through configfs, any connected controllers are starting teardown flow asynchronously and can still send commands. This causes a use-after-free bug for any command that dereferences req->port (like in nvmet_parse_io_cmd). To fix this, wait for all the teardown scheduled works to complete (like release_work at rdma/tcp drivers). This ensures there are no active controllers when the port is eventually removed. Signed-off-by: Israel Rukshin Reviewed-by: Max Gurtovoy Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 9adc2bcdc812e7cad1b376e9b1ab2845b3b8b7c7 Author: Alex Deucher Date: Mon Oct 4 11:33:00 2021 -0400 drm/amdgpu/pm: properly handle sclk for profiling modes on vangogh [ Upstream commit 68e3871dcd6e547f6c47454492bc452356cb9eac ] When selecting between levels in the force performance levels interface sclk (gfxclk) was not set correctly for all levels. Select the proper sclk settings for all levels. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1726 Reviewed-by: Evan Quan Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 163ecd64c8160c8f69dc5dbcd24936f18893f961 Author: Michael Tretter Date: Wed Sep 8 14:03:10 2021 +0100 media: allegro: ignore interrupt if mailbox is not initialized [ Upstream commit 1ecda6393db4be44aba27a243e648dc98c9b92e3 ] The mailbox is initialized after the interrupt handler is installed. As the firmware is loaded and started even later, it should not happen that the interrupt occurs without the mailbox being initialized. As the Linux Driver Verification project (linuxtesting.org) keeps reporting this as an error, add a check to ignore interrupts before the mailbox is initialized to fix this potential null pointer dereference. Reported-by: Yuri Savinykh Reported-by: Nadezda Lutovinova Signed-off-by: Michael Tretter Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f63b9287375c7f757fdd96c708ba49b28d2ef3f8 Author: Jens Axboe Date: Wed Oct 20 08:21:40 2021 -0600 block: remove inaccurate requeue check [ Upstream commit 037057a5a979c7eeb2ee5d12cf4c24b805192c75 ] This check is meant to catch cases where a requeue is attempted on a request that is still inserted. It's never really been useful to catch any misuse, and now it's actively wrong. Outside of that, this should not be a BUG_ON() to begin with. Remove the check as it's now causing active harm, as requeue off the plug path will trigger it even though the request state is just fine. Reported-by: Yi Zhang Link: https://lore.kernel.org/linux-block/CAHj4cs80zAUc2grnCZ015-2Rvd-=gXRfB_dFKy=RTm+wRo09HQ@mail.gmail.com/ Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bd45e6f3c0e90c1a220e63d46aa48378a4eacb19 Author: Yaara Baruch Date: Sat Oct 16 11:43:56 2021 +0300 iwlwifi: change all JnP to NO-160 configuration [ Upstream commit 70382b0897eeecfcd35ba5f6161dbceeb556ea1e ] JnP should not have the 160 MHz. Signed-off-by: Yaara Baruch Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ee163f4a7513.I7f87bd969a0b038c7f3a1a962d9695ffd18c5da1@changeid Signed-off-by: Sasha Levin commit 8393c0806cc491d0f10a11baf8760d3f8ff9b614 Author: Zheyu Ma Date: Sat Oct 16 04:02:59 2021 +0000 mwl8k: Fix use-after-free in mwl8k_fw_state_machine() [ Upstream commit 257051a235c17e33782b6e24a4b17f2d7915aaec ] When the driver fails to request the firmware, it calls its error handler. In the error handler, the driver detaches device from driver first before releasing the firmware, which can cause a use-after-free bug. Fix this by releasing firmware first. The following log reveals it: [ 9.007301 ] BUG: KASAN: use-after-free in mwl8k_fw_state_machine+0x320/0xba0 [ 9.010143 ] Workqueue: events request_firmware_work_func [ 9.010830 ] Call Trace: [ 9.010830 ] dump_stack_lvl+0xa8/0xd1 [ 9.010830 ] print_address_description+0x87/0x3b0 [ 9.010830 ] kasan_report+0x172/0x1c0 [ 9.010830 ] ? mutex_unlock+0xd/0x10 [ 9.010830 ] ? mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] ? mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] __asan_report_load8_noabort+0x14/0x20 [ 9.010830 ] mwl8k_fw_state_machine+0x320/0xba0 [ 9.010830 ] ? mwl8k_load_firmware+0x5f0/0x5f0 [ 9.010830 ] request_firmware_work_func+0x172/0x250 [ 9.010830 ] ? read_lock_is_recursive+0x20/0x20 [ 9.010830 ] ? process_one_work+0x7a1/0x1100 [ 9.010830 ] ? request_firmware_nowait+0x460/0x460 [ 9.010830 ] ? __this_cpu_preempt_check+0x13/0x20 [ 9.010830 ] process_one_work+0x9bb/0x1100 Signed-off-by: Zheyu Ma Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1634356979-6211-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Sasha Levin commit 0ca511d52a2838e1ecead6489823caad808be332 Author: Ryder Lee Date: Wed Jul 14 15:56:10 2021 +0800 mt76: mt7915: fix an off-by-one bound check [ Upstream commit d45dac0732a287fc371a23f257cce04e65627947 ] The bounds check on datalen is off-by-one, so fix it. Signed-off-by: Ryder Lee Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 91dc3f6ea7c8f47d956a3ff158765df67a939807 Author: Kalesh Singh Date: Wed Oct 13 21:52:17 2021 -0700 tracing/cfi: Fix cmp_entries_* functions signature mismatch [ Upstream commit 7ce1bb83a14019f8c396d57ec704d19478747716 ] If CONFIG_CFI_CLANG=y, attempting to read an event histogram will cause the kernel to panic due to failed CFI check. 1. echo 'hist:keys=common_pid' >> events/sched/sched_switch/trigger 2. cat events/sched/sched_switch/hist 3. kernel panics on attempting to read hist This happens because the sort() function expects a generic int (*)(const void *, const void *) pointer for the compare function. To prevent this CFI failure, change tracing map cmp_entries_* function signatures to match this. Also, fix the build error reported by the kernel test robot [1]. [1] https://lore.kernel.org/r/202110141140.zzi4dRh4-lkp@intel.com/ Link: https://lkml.kernel.org/r/20211014045217.3265162-1-kaleshsingh@google.com Signed-off-by: Kalesh Singh Reported-by: kernel test robot Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit ab816ffa09d5cf2bc4f1d96dccea12fa4836d2ca Author: Menglong Dong Date: Sun Oct 17 20:04:02 2021 +0800 workqueue: make sysfs of unbound kworker cpumask more clever [ Upstream commit d25302e46592c97d29f70ccb1be558df31a9a360 ] Some unfriendly component, such as dpdk, write the same mask to unbound kworker cpumask again and again. Every time it write to this interface some work is queue to cpu, even though the mask is same with the original mask. So, fix it by return success and do nothing if the cpumask is equal with the old one. Signed-off-by: Mengen Sun Signed-off-by: Menglong Dong Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 75bbf9642bd1c57979c93bfeab9c8669e519b072 Author: Lasse Collin Date: Mon Oct 11 05:31:40 2021 +0800 lib/xz: Validate the value before assigning it to an enum variable [ Upstream commit 4f8d7abaa413c34da9d751289849dbfb7c977d05 ] This might matter, for example, if the underlying type of enum xz_check was a signed char. In such a case the validation wouldn't have caught an unsupported header. I don't know if this problem can occur in the kernel on any arch but it's still good to fix it because some people might copy the XZ code to their own projects from Linux instead of the upstream XZ Embedded repository. This change may increase the code size by a few bytes. An alternative would have been to use an unsigned int instead of enum xz_check but using an enumeration looks cleaner. Link: https://lore.kernel.org/r/20211010213145.17462-3-xiang@kernel.org Signed-off-by: Lasse Collin Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 93cc20fa51e8f53a59a3c0662ce9cdd6c9d81c81 Author: Lasse Collin Date: Mon Oct 11 05:31:39 2021 +0800 lib/xz: Avoid overlapping memcpy() with invalid input with in-place decompression [ Upstream commit 83d3c4f22a36d005b55f44628f46cc0d319a75e8 ] With valid files, the safety margin described in lib/decompress_unxz.c ensures that these buffers cannot overlap. But if the uncompressed size of the input is larger than the caller thought, which is possible when the input file is invalid/corrupt, the buffers can overlap. Obviously the result will then be garbage (and usually the decoder will return an error too) but no other harm will happen when such an over-run occurs. This change only affects uncompressed LZMA2 chunks and so this should have no effect on performance. Link: https://lore.kernel.org/r/20211010213145.17462-2-xiang@kernel.org Signed-off-by: Lasse Collin Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin commit 419ebe6636717b3ac833c1c7eb7d40b8ba3daf21 Author: Yanfei Xu Date: Wed Oct 13 21:41:53 2021 +0800 locking/rwsem: Disable preemption for spinning region [ Upstream commit 7cdacc5f52d68a9370f182c844b5b3e6cc975cc1 ] The spinning region rwsem_spin_on_owner() should not be preempted, however the rwsem_down_write_slowpath() invokes it and don't disable preemption. Fix it by adding a pair of preempt_disable/enable(). Signed-off-by: Yanfei Xu [peterz: Fix CONFIG_RWSEM_SPIN_ON_OWNER=n build] Signed-off-by: Peter Zijlstra (Intel) Acked-by: Waiman Long Link: https://lore.kernel.org/r/20211013134154.1085649-3-yanfei.xu@windriver.com Signed-off-by: Sasha Levin commit 38d7055de41a4a08935f65ebd749cc7c5b771229 Author: Zheyu Ma Date: Sat Oct 16 11:26:21 2021 +0000 memstick: r592: Fix a UAF bug when removing the driver [ Upstream commit 738216c1953e802aa9f930c5d15b8f9092c847ff ] In r592_remove(), the driver will free dma after freeing the host, which may cause a UAF bug. The following log reveals it: [ 45.361796 ] BUG: KASAN: use-after-free in r592_remove+0x269/0x350 [r592] [ 45.364286 ] Call Trace: [ 45.364472 ] dump_stack_lvl+0xa8/0xd1 [ 45.364751 ] print_address_description+0x87/0x3b0 [ 45.365137 ] kasan_report+0x172/0x1c0 [ 45.365415 ] ? r592_remove+0x269/0x350 [r592] [ 45.365834 ] ? r592_remove+0x269/0x350 [r592] [ 45.366168 ] __asan_report_load8_noabort+0x14/0x20 [ 45.366531 ] r592_remove+0x269/0x350 [r592] [ 45.378785 ] [ 45.378903 ] Allocated by task 4674: [ 45.379162 ] ____kasan_kmalloc+0xb5/0xe0 [ 45.379455 ] __kasan_kmalloc+0x9/0x10 [ 45.379730 ] __kmalloc+0x150/0x280 [ 45.379984 ] memstick_alloc_host+0x2a/0x190 [ 45.380664 ] [ 45.380781 ] Freed by task 5509: [ 45.381014 ] kasan_set_track+0x3d/0x70 [ 45.381293 ] kasan_set_free_info+0x23/0x40 [ 45.381635 ] ____kasan_slab_free+0x10b/0x140 [ 45.381950 ] __kasan_slab_free+0x11/0x20 [ 45.382241 ] slab_free_freelist_hook+0x81/0x150 [ 45.382575 ] kfree+0x13e/0x290 [ 45.382805 ] memstick_free+0x1c/0x20 [ 45.383070 ] device_release+0x9c/0x1d0 [ 45.383349 ] kobject_put+0x2ef/0x4c0 [ 45.383616 ] put_device+0x1f/0x30 [ 45.383865 ] memstick_free_host+0x24/0x30 [ 45.384162 ] r592_remove+0x242/0x350 [r592] [ 45.384473 ] pci_device_remove+0xa9/0x250 Signed-off-by: Zheyu Ma Link: https://lore.kernel.org/r/1634383581-11055-1-git-send-email-zheyuma97@gmail.com Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit ac14b0b119a43339e6d6d045cfeb603fb055636b Author: Xiao Ni Date: Wed Oct 13 22:59:33 2021 +0800 md: update superblock after changing rdev flags in state_store [ Upstream commit 8b9e2291e355a0eafdd5b1e21a94a6659f24b351 ] When the in memory flag is changed, we need to persist the change in the rdev superblock flags. This is needed for "writemostly" and "failfast". Reviewed-by: Li Feng Signed-off-by: Xiao Ni Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ca9ae3fb33154b8c6e679dbb7be047c545d0d8e3 Author: Luis Chamberlain Date: Mon Sep 27 15:02:52 2021 -0700 floppy: fix calling platform_device_unregister() on invalid drives [ Upstream commit 662167e59d2f3c15a44a88088fc6c1a67c8a3650 ] platform_device_unregister() should only be called when a respective platform_device_register() is called. However the floppy driver currently allows failures when registring a drive and a bail out could easily cause an invalid call to platform_device_unregister() where it was not intended. Fix this by adding a bool to keep track of when the platform device was registered for a drive. This does not fix any known panic / bug. This issue was found through code inspection while preparing the driver to use the up and coming support for device_add_disk() error handling. From what I can tell from code inspection, chances of this ever happening should be insanely small, perhaps OOM. Signed-off-by: Luis Chamberlain Link: https://lore.kernel.org/r/20210927220302.1073499-5-mcgrof@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 8a6e8aa372073ea644ac7ffc9e5a428d6717c57e Author: Jens Axboe Date: Wed Oct 6 12:01:07 2021 -0600 block: bump max plugged deferred size from 16 to 32 [ Upstream commit ba0ffdd8ce48ad7f7e85191cd29f9674caca3745 ] Particularly for NVMe with efficient deferred submission for many requests, there are nice benefits to be seen by bumping the default max plug count from 16 to 32. This is especially true for virtualized setups, where the submit part is more expensive. But can be noticed even on native hardware. Reduce the multiple queue factor from 4 to 2, since we're changing the default size. While changing it, move the defines into the block layer private header. These aren't values that anyone outside of the block layer uses, or should use. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f5ec8022cf54cb029e408bdcdd4693df8c9d02ce Author: Ansuel Smith Date: Thu Oct 7 19:28:59 2021 +0200 thermal/drivers/tsens: Add timeout to get_temp_tsens_valid [ Upstream commit d012f9189fda0f3a1b303780ba0bbc7298d0d349 ] The function can loop and lock the system if for whatever reason the bit for the target sensor is NEVER valid. This is the case if a sensor is disabled by the factory and the valid bit is never reported as actually valid. Add a timeout check and exit if a timeout occurs. As this is a very rare condition, handle the timeout only if the first read fails. While at it also rework the function to improve readability and convert to poll_timeout generic macro. Signed-off-by: Ansuel Smith Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20211007172859.583-1-ansuelsmth@gmail.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit cdcfcd25f40ba9a27e700158882f10a3a63e3633 Author: Tim Gardner Date: Wed Sep 29 10:25:54 2021 -0600 drm/msm: prevent NULL dereference in msm_gpu_crashstate_capture() [ Upstream commit b220c154832c5cd0df34cbcbcc19d7135c16e823 ] Coverity complains of a possible NULL dereference: CID 120718 (#1 of 1): Dereference null return value (NULL_RETURNS) 23. dereference: Dereferencing a pointer that might be NULL state->bos when calling msm_gpu_crashstate_get_bo. [show details] 301 msm_gpu_crashstate_get_bo(state, submit->bos[i].obj, 302 submit->bos[i].iova, submit->bos[i].flags); Fix this by employing the same state->bos NULL check as is used in the next for loop. Cc: Rob Clark Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Tim Gardner Reviewed-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20210929162554.14295-1-tim.gardner@canonical.com Signed-off-by: Dmitry Baryshkov Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 6154aa2ab2e0c81575a844173b19eeaaed551d23 Author: Yuanzheng Song Date: Fri Oct 15 08:32:30 2021 +0000 thermal/core: Fix null pointer dereference in thermal_release() [ Upstream commit 1dd7128b839f631b31a9e9dce3aaf639bef74e9d ] If both dev_set_name() and device_register() failed, then null pointer dereference occurs in thermal_release() which will use strncmp() to compare the name. So fix it by adding dev_set_name() return value check. Signed-off-by: Yuanzheng Song Link: https://lore.kernel.org/r/20211015083230.67658-1-songyuanzheng@huawei.com Signed-off-by: Daniel Lezcano Signed-off-by: Sasha Levin commit 2fba88c1705d06e681e8208c3e07bccc8fdb2b46 Author: Kees Cook Date: Wed Sep 29 15:02:18 2021 -0700 leaking_addresses: Always print a trailing newline [ Upstream commit cf2a85efdade117e2169d6e26641016cbbf03ef0 ] For files that lack trailing newlines and match a leaking address (e.g. wchan[1]), the leaking_addresses.pl report would run together with the next line, making things look corrupted. Unconditionally remove the newline on input, and write it back out on output. [1] https://lore.kernel.org/all/20210103142726.GC30643@xsang-OptiPlex-9020/ Signed-off-by: Kees Cook Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20211008111626.151570317@infradead.org Signed-off-by: Sasha Levin commit 57cdc39776d323381f3df0e3dea528952c9d4f5a Author: Matthias Schiffer Date: Tue Oct 12 12:34:02 2021 +0200 net: phy: micrel: make *-skew-ps check more lenient [ Upstream commit 67ca5159dbe2edb5dae7544447b8677d2596933a ] It seems reasonable to fine-tune only some of the skew values when using one of the rgmii-*id PHY modes, and even when all skew values are specified, using the correct ID PHY mode makes sense for documentation purposes. Such a configuration also appears in the binding docs in Documentation/devicetree/bindings/net/micrel-ksz90x1.txt, so the driver should not warn about it. Signed-off-by: Matthias Schiffer Link: https://lore.kernel.org/r/20211012103402.21438-1-matthias.schiffer@ew.tq-group.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7e4804d1aa822b6ff1569a9302736940e7a36208 Author: Yifan Zhang Date: Mon Oct 11 20:42:31 2021 +0800 drm/amdkfd: fix resume error when iommu disabled in Picasso [ Upstream commit 6f4b590aae217da16cfa44039a2abcfb209137ab ] When IOMMU disabled in sbios and kfd in iommuv2 path, IOMMU resume failure blocks system resume. Don't allow kfd to use iommu v2 when iommu is disabled. Reported-by: youling Tested-by: youling Signed-off-by: Yifan Zhang Reviewed-by: James Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 082ed61dabbc3540e0dc4180fc547b23e6cc637d Author: Aurabindo Pillai Date: Fri Oct 8 16:07:45 2021 -0400 drm/amd/display: fix null pointer deref when plugging in display [ Upstream commit 1f3b22e4eb162e0b1d423106a47484943a22a309 ] [Why&How] When system boots in headless mode, connecting a 4k display creates a null pointer dereference due to hubp for a certain plane being null. Add a condition to check for null hubp before dereferencing it. Signed-off-by: Aurabindo Pillai Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit c40061dab6b1ec4d781de697c4c23e82c8c10d73 Author: Rafael J. Wysocki Date: Sat Oct 9 16:22:09 2021 +0200 ACPI: scan: Release PM resources blocked by unused objects [ Upstream commit c10383e8ddf4810b9a5c1595404c2724d925a0a6 ] On some systems the ACPI namespace contains device objects that are not used in certain configurations of the system. If they start off in the D0 power state configuration, they will stay in it until the system reboots, because of the lack of any mechanism possibly causing their configuration to change. If that happens, they may prevent some power resources from being turned off or generally they may prevent the platform from getting into the deepest low-power states thus causing some energy to be wasted. Address this issue by changing the configuration of unused ACPI device objects to the D3cold power state one after carrying out the ACPI-based enumeration of devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214091 Link: https://lore.kernel.org/linux-acpi/20211007205126.11769-1-mario.limonciello@amd.com/ Reported-by: Mario Limonciello Signed-off-by: Rafael J. Wysocki Tested-by: Mario Limonciello Signed-off-by: Sasha Levin commit afdc107129b59e25e40fb75a8c90d7abd5561503 Author: André Almeida Date: Fri Oct 8 00:05:29 2021 -0300 ACPI: battery: Accept charges over the design capacity as full [ Upstream commit 2835f327bd1240508db2c89fe94a056faa53c49a ] Some buggy firmware and/or brand new batteries can support a charge that's slightly over the reported design capacity. In such cases, the kernel will report to userspace that the charging state of the battery is "Unknown", when in reality the battery charge is "Full", at least from the design capacity point of view. Make the fallback condition accepts capacities over the designed capacity so userspace knows that is full. Signed-off-by: André Almeida Reviewed-by: Hans de Goede Reviewed-by: Sebastian Reichel Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8fa361b1b3e3154efb86b955fd318dd3b08f7d72 Author: Andreas Gruenbacher Date: Wed Jul 21 19:03:47 2021 +0200 iov_iter: Fix iov_iter_get_pages{,_alloc} page fault return value [ Upstream commit 814a66741b9ffb5e1ba119e368b178edb0b7322d ] Both iov_iter_get_pages and iov_iter_get_pages_alloc return the number of bytes of the iovec they could get the pages for. When they cannot get any pages, they're supposed to return 0, but when the start of the iovec isn't page aligned, the calculation goes wrong and they return a negative value. Fix both functions. In addition, change iov_iter_get_pages_alloc to return NULL in that case to prevent resource leaks. Signed-off-by: Andreas Gruenbacher Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit af2af71fd12b0e95977789ab00c56deaf88c4adf Author: Xin Xiong Date: Sat Oct 9 12:19:18 2021 +0800 mmc: moxart: Fix reference count leaks in moxart_probe [ Upstream commit 8105c2abbf36296bf38ca44f55ee45d160db476a ] The issue happens in several error handling paths on two refcounted object related to the object "host" (dma_chan_rx, dma_chan_tx). In these paths, the function forgets to decrement one or both objects' reference count increased earlier by dma_request_chan(), causing reference count leaks. Fix it by balancing the refcounts of both objects in some error handling paths. In correspondence with the changes in moxart_probe(), IS_ERR() is replaced with IS_ERR_OR_NULL() in moxart_remove() as well. Signed-off-by: Xin Xiong Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/20211009041918.28419-1-xiongx18@fudan.edu.cn Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 07a47bb0fba3f39c87e881bc77c400cb653f3a38 Author: Tuo Li Date: Thu Aug 5 08:38:53 2021 -0700 ath: dfs_pattern_detector: Fix possible null-pointer dereference in channel_detector_create() [ Upstream commit 4b6012a7830b813799a7faf40daa02a837e0fd5b ] kzalloc() is used to allocate memory for cd->detectors, and if it fails, channel_detector_exit() behind the label fail will be called: channel_detector_exit(dpd, cd); In channel_detector_exit(), cd->detectors is dereferenced through: struct pri_detector *de = cd->detectors[i]; To fix this possible null-pointer dereference, check cd->detectors before the for loop to dereference cd->detectors. Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210805153854.154066-1-islituo@gmail.com Signed-off-by: Sasha Levin commit b40f43fcd011675acf6b13f1316af6af835a696f Author: Steven Rostedt (VMware) Date: Wed Aug 18 11:24:51 2021 -0400 tracing: Disable "other" permission bits in the tracefs files [ Upstream commit 21ccc9cd72116289469e5519b6159c675a2fa58f ] When building the files in the tracefs file system, do not by default set any permissions for OTH (other). This will make it easier for admins who want to define a group for accessing tracefs and not having to first disable all the permission bits for "other" in the file system. As tracing can leak sensitive information, it should never by default allowing all users access. An admin can still set the permission bits for others to have access, which may be useful for creating a honeypot and seeing who takes advantage of it and roots the machine. Link: https://lkml.kernel.org/r/20210818153038.864149276@goodmis.org Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 3d2f0cd9dcb9db41df5c1f30db9e1b7c81c1ab69 Author: Steven Rostedt (VMware) Date: Wed Aug 18 11:24:50 2021 -0400 tracefs: Have tracefs directories not set OTH permission bits by default [ Upstream commit 49d67e445742bbcb03106b735b2ab39f6e5c56bc ] The tracefs file system is by default mounted such that only root user can access it. But there are legitimate reasons to create a group and allow those added to the group to have access to tracing. By changing the permissions of the tracefs mount point to allow access, it will allow group access to the tracefs directory. There should not be any real reason to allow all access to the tracefs directory as it contains sensitive information. Have the default permission of directories being created not have any OTH (other) bits set, such that an admin that wants to give permission to a group has to first disable all OTH bits in the file system. Link: https://lkml.kernel.org/r/20210818153038.664127804@goodmis.org Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 2a3c1044fc0d909d1c783774f015a93c72c3d29e Author: Alex Sierra Date: Thu Oct 7 12:04:09 2021 -0500 drm/amdkfd: rm BO resv on validation to avoid deadlock [ Upstream commit ec6abe831a843208e99a59adf108adba22166b3f ] This fix the deadlock with the BO reservations during SVM_BO evictions while allocations in VRAM are concurrently performed. More specific, while the ttm waits for the fence to be signaled (ttm_bo_wait), it already has the BO reserved. In parallel, the restore worker might be running, prefetching memory to VRAM. This also requires to reserve the BO, but blocks the mmap semaphore first. The deadlock happens when the SVM_BO eviction worker kicks in and waits for the mmap semaphore held in restore worker. Preventing signal the fence back, causing the deadlock until the ttm times out. We don't need to hold the BO reservation anymore during validation and mapping. Now the physical addresses are taken from hmm_range_fault. We also take migrate_mutex to prevent range migration while validate_and_map update GPU page table. Signed-off-by: Alex Sierra Signed-off-by: Felix Kuehling Reviewed-by: Philip Yang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 84aa6d0e076764c475b7f1e7e3ddc39898e470b2 Author: Antoine Tenart Date: Thu Oct 7 16:00:51 2021 +0200 net-sysfs: try not to restart the syscall if it will fail eventually [ Upstream commit 146e5e733310379f51924111068f08a3af0db830 ] Due to deadlocks in the networking subsystem spotted 12 years ago[1], a workaround was put in place[2] to avoid taking the rtnl lock when it was not available and restarting the syscall (back to VFS, letting userspace spin). The following construction is found a lot in the net sysfs and sysctl code: if (!rtnl_trylock()) return restart_syscall(); This can be problematic when multiple userspace threads use such interfaces in a short period, making them to spin a lot. This happens for example when adding and moving virtual interfaces: userspace programs listening on events, such as systemd-udevd and NetworkManager, do trigger actions reading files in sysfs. It gets worse when a lot of virtual interfaces are created concurrently, say when creating containers at boot time. Returning early without hitting the above pattern when the syscall will fail eventually does make things better. While it is not a fix for the issue, it does ease things. [1] https://lore.kernel.org/netdev/49A4D5D5.5090602@trash.net/ https://lore.kernel.org/netdev/m14oyhis31.fsf@fess.ebiederm.org/ and https://lore.kernel.org/netdev/20090226084924.16cb3e08@nehalam/ [2] Rightfully, those deadlocks are *hard* to solve. Signed-off-by: Antoine Tenart Reviewed-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8e538cacf9be8499e06720cdd33ea5a500505fdc Author: Anant Thazhemadam Date: Mon Dec 7 07:16:06 2020 +0100 media: usb: dvd-usb: fix uninit-value bug in dibusb_read_eeprom_byte() [ Upstream commit 899a61a3305d49e8a712e9ab20d0db94bde5929f ] In dibusb_read_eeprom_byte(), if dibusb_i2c_msg() fails, val gets assigned an value that's not properly initialized. Using kzalloc() in place of kmalloc() for the buffer fixes this issue, as the val can now be set to 0 in the event dibusb_i2c_msg() fails. Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com Tested-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 35f16d8e61538ba9a550c937f421d9e5d1bb75c5 Author: Ricardo Ribalda Date: Thu Oct 7 00:26:22 2021 +0200 media: ipu3-imgu: VIDIOC_QUERYCAP: Fix bus_info [ Upstream commit ea2b9a33711604e91f8c826f4dcb3c12baa1990a ] bus_info field had a different value for the media entity and the video device. Fixes v4l2-compliance: v4l2-compliance.cpp(637): media bus_info 'PCI:0000:00:05.0' differs from V4L2 bus_info 'PCI:viewfinder' Reviewed-by: Bingbu Cao Signed-off-by: Ricardo Ribalda Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d43da0118953ac097765859e32961447722d610e Author: Ricardo Ribalda Date: Thu Oct 7 00:26:21 2021 +0200 media: ipu3-imgu: imgu_fmt: Handle properly try [ Upstream commit 553481e38045f349bb9aa596d03bebd020020c9c ] For a try_fmt call, the node noes not need to be enabled. Fixes v4l2-compliance fail: v4l2-test-formats.cpp(717): Video Output Multiplanar is valid, but no TRY_FMT was implemented test VIDIOC_TRY_FMT: FAIL Signed-off-by: Ricardo Ribalda Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 986b39450c480dd0c3c797cf65a32fac7fc2b823 Author: Mirela Rabulea Date: Mon Sep 27 20:56:32 2021 +0200 media: imx-jpeg: Fix possible null pointer dereference [ Upstream commit 83f5f0633b156c636f5249d3c10f2a9423dd4c96 ] Found by Coverity scan. Signed-off-by: Mirela Rabulea Reviewed-by: Laurentiu Palcu Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 86d9d52d685685b046d99ab00643d31f10cc5c7e Author: Wojciech Drewek Date: Thu Aug 19 17:08:49 2021 -0700 ice: Move devlink port to PF/VF struct [ Upstream commit 2ae0aa4758b0f4a247d45cb3bf01548a7f396751 ] Keeping devlink port inside VSI data structure causes some issues. Since VF VSI is released during reset that means that we have to unregister devlink port and register it again every time reset is triggered. With the new changes in devlink API it might cause deadlock issues. After calling devlink_port_register/devlink_port_unregister devlink API is going to lock rtnl_mutex. It's an issue when VF reset is triggered in netlink operation context (like setting VF MAC address or VLAN), because rtnl_lock is already taken by netlink. Another call of rtnl_lock from devlink API results in dead-lock. By moving devlink port to PF/VF we avoid creating/destroying it during reset. Since this patch, devlink ports are created during ice_probe, destroyed during ice_remove for PF and created during ice_repr_add, destroyed during ice_repr_rem for VF. Signed-off-by: Wojciech Drewek Tested-by: Sandeep Penigalapati Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit f6afa36d653f4edf8863f5270691f827751a419c Author: Vincent Donnefort Date: Wed Sep 8 15:05:26 2021 +0100 cpufreq: Make policy min/max hard requirements [ Upstream commit 15171769069408789a72f9aa9a52cc931b839b56 ] When applying the policy min/max limits, the requested frequency is simply clamped to not be out of range. It means, however, if one of the boundaries isn't an available frequency, the frequency resolution can return a value out of those limits, depending on the relation used. e.g. freq{0,1,2} being available frequencies. freq0 policy->min freq1 policy->max freq2 | | | | | 17kHz 18kHz 19kHz 20kHz 21kHz __resolve_freq(21kHz, CPUFREQ_RELATION_L) -> 21kHz (out of bounds) __resolve_freq(17kHz, CPUFREQ_RELATION_H) -> 17kHz (out of bounds) If, during the policy init, we resolve the requested min/max to existing frequencies, we ensure that any CPUFREQ_RELATION_* would resolve to a frequency which is inside the policy min/max range. Making the policy limits rigid helps to introduce the inefficient frequencies support. Resolving an inefficient frequency to an efficient one should not transgress policy->max (which can be set for thermal reason) and having a value we can trust simplify this comparison. Signed-off-by: Vincent Donnefort Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 86a6e4f9815a2455a9877788e215fe51a6e2e074 Author: Rafael J. Wysocki Date: Wed Sep 29 18:31:25 2021 +0200 ACPICA: Avoid evaluating methods too early during system resume [ Upstream commit d3c4b6f64ad356c0d9ddbcf73fa471e6a841cc5c ] ACPICA commit 0762982923f95eb652cf7ded27356b247c9774de During wakeup from system-wide sleep states, acpi_get_sleep_type_data() is called and it tries to get memory from the slab allocator in order to evaluate a control method, but if KFENCE is enabled in the kernel, the memory allocation attempt causes an IRQ work to be queued and a self-IPI to be sent to the CPU running the code which requires the memory controller to be ready, so if that happens too early in the wakeup path, it doesn't work. Prevent that from taking place by calling acpi_get_sleep_type_data() for S0 upfront, when preparing to enter a given sleep state, and saving the data obtained by it for later use during system wakeup. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214271 Reported-by: Reik Keutterling Tested-by: Reik Keutterling Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 72742ae5e049d03216f0dfc7d7cf28f6f8d7748b Author: Li Zhijian Date: Thu Sep 2 10:43:33 2021 +0800 kselftests/sched: cleanup the child processes [ Upstream commit 1c36432b278cecf1499f21fae19836e614954309 ] Previously, 'make -C sched run_tests' will block forever when it occurs something wrong where the *selftests framework* is waiting for its child processes to exit. [root@iaas-rpma sched]# ./cs_prctl_test ## Create a thread/process/process group hiearchy Not a core sched system tid=74985, / tgid=74985 / pgid=74985: ffffffffffffffff Not a core sched system tid=74986, / tgid=74986 / pgid=74985: ffffffffffffffff Not a core sched system tid=74988, / tgid=74986 / pgid=74985: ffffffffffffffff Not a core sched system tid=74989, / tgid=74986 / pgid=74985: ffffffffffffffff Not a core sched system tid=74990, / tgid=74986 / pgid=74985: ffffffffffffffff Not a core sched system tid=74987, / tgid=74987 / pgid=74985: ffffffffffffffff Not a core sched system tid=74991, / tgid=74987 / pgid=74985: ffffffffffffffff Not a core sched system tid=74992, / tgid=74987 / pgid=74985: ffffffffffffffff Not a core sched system tid=74993, / tgid=74987 / pgid=74985: ffffffffffffffff Not a core sched system (268) FAILED: get_cs_cookie(0) == 0 ## Set a cookie on entire process group -1 = prctl(62, 1, 0, 2, 0) core_sched create failed -- PGID: Invalid argument (cs_prctl_test.c:272) - [root@iaas-rpma sched]# ps PID TTY TIME CMD 4605 pts/2 00:00:00 bash 74986 pts/2 00:00:00 cs_prctl_test 74987 pts/2 00:00:00 cs_prctl_test 74999 pts/2 00:00:00 ps Reported-by: kernel test robot Signed-off-by: Li Zhijian Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Chris Hyser Link: https://lore.kernel.org/r/20210902024333.75983-1-lizhijian@cn.fujitsu.com Signed-off-by: Sasha Levin commit aa171d3e8556655bb4036e347510b60574b5740f Author: Josh Don Date: Fri Aug 27 09:54:38 2021 -0700 fs/proc/uptime.c: Fix idle time reporting in /proc/uptime [ Upstream commit a130e8fbc7de796eb6e680724d87f4737a26d0ac ] /proc/uptime reports idle time by reading the CPUTIME_IDLE field from the per-cpu kcpustats. However, on NO_HZ systems, idle time is not continually updated on idle cpus, leading this value to appear incorrectly small. /proc/stat performs an accounting update when reading idle time; we can use the same approach for uptime. With this patch, /proc/stat and /proc/uptime now agree on idle time. Additionally, the following shows idle time tick up consistently on an idle machine: (while true; do cat /proc/uptime; sleep 1; done) | awk '{print $2-prev; prev=$2}' Reported-by: Luigi Rizzo Signed-off-by: Josh Don Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Eric Dumazet Link: https://lkml.kernel.org/r/20210827165438.3280779-1-joshdon@google.com Signed-off-by: Sasha Levin commit 09bdbbc622e33d7bfb3475b695254e562cfdba48 Author: Corey Minyard Date: Thu Sep 16 11:36:20 2021 -0500 ipmi: Disable some operations during a panic [ Upstream commit b36eb5e7b75a756baa64909a176dd4269ee05a8b ] Don't do kfree or other risky things when oops_in_progress is set. It's easy enough to avoid doing them Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit d051a3867bea13be051325b0f37e422e948ef792 Author: Nadezda Lutovinova Date: Wed Aug 11 19:18:16 2021 +0200 media: rcar-csi2: Add checking to rcsi2_start_receiver() [ Upstream commit fc41665498332ad394b7db37f23e9394096ddc71 ] If rcsi2_code_to_fmt() return NULL, then null pointer dereference occurs in the next cycle. That should not be possible now but adding checking protects from future bugs. The patch adds checking if format is NULL. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova Reviewed-by: Jacopo Mondi Reviewed-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f31b7caedd50b58f7d05ce331cbb9e2a1849ef97 Author: Hans de Goede Date: Tue Sep 28 18:06:33 2021 +0200 brcmfmac: Add DMI nvram filename quirk for Cyberbook T116 tablet [ Upstream commit 49c3eb3036e6359c5c20fe76c611a2c0e0d4710e ] The Cyberbook T116 tablet contains quite generic names in the sys_vendor and product_name DMI strings, without this patch brcmfmac will try to load: "brcmfmac43455-sdio.Default string-Default string.txt" as nvram file which is way too generic. The nvram file shipped on the factory Android image contains the exact same settings as those used on the AcePC T8 mini PC, so point the new DMI nvram filename quirk to the acepc-t8 nvram file. Signed-off-by: Hans de Goede Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210928160633.96928-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 39e14b269e27684f1e9e843fa5ea273229b833dc Author: Zong-Zhe Yang Date: Mon Sep 27 19:18:30 2021 +0800 rtw88: fix RX clock gate setting while fifo dump [ Upstream commit c5a8e90730a322f236731fc347dd3afa5db5550e ] When fw fifo dumps, RX clock gating should be disabled to avoid something unexpected. However, the register operation ran into a mistake. So, we fix it. Signed-off-by: Zong-Zhe Yang Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210927111830.5354-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit f431d9923a6953470c4920f9ec5c63278b58f1f3 Author: Randy Dunlap Date: Sun Sep 26 10:12:24 2021 -0700 ia64: don't do IA64_CMPXCHG_DEBUG without CONFIG_PRINTK [ Upstream commit c15b5fc054c3d6c97e953617605235c5cb8ce979 ] When CONFIG_PRINTK is not set, the CMPXCHG_BUGCHECK() macro calls _printk(), but _printk() is a static inline function, not available as an extern. Since the purpose of the macro is to print the BUGCHECK info, make this config option depend on PRINTK. Fixes multiple occurrences of this build error: ../include/linux/printk.h:208:5: error: static declaration of '_printk' follows non-static declaration 208 | int _printk(const char *s, ...) | ^~~~~~~ In file included from ../arch/ia64/include/asm/cmpxchg.h:5, ../arch/ia64/include/uapi/asm/cmpxchg.h:146:28: note: previous declaration of '_printk' with type 'int(const char *, ...)' 146 | extern int _printk(const char *fmt, ...); Cc: linux-ia64@vger.kernel.org Cc: Andrew Morton Cc: Tony Luck Cc: Chris Down Cc: Paul Gortmaker Cc: John Paul Adrian Glaubitz Signed-off-by: Randy Dunlap Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin commit 1f7d5294d2a721589fb1fe7e883cd5b517452d3e Author: Rajat Asthana Date: Wed Aug 18 22:31:10 2021 +0200 media: mceusb: return without resubmitting URB in case of -EPROTO error. [ Upstream commit 476db72e521983ecb847e4013b263072bb1110fc ] Syzkaller reported a warning called "rcu detected stall in dummy_timer". The error seems to be an error in mceusb_dev_recv(). In the case of -EPROTO error, the routine immediately resubmits the URB. Instead it should return without resubmitting URB. Reported-by: syzbot+4d3749e9612c2cfab956@syzkaller.appspotmail.com Signed-off-by: Rajat Asthana Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6e0202ddccfb90ddcbf42df8ef738d91166d6736 Author: Niklas Söderlund Date: Sat Sep 11 21:19:58 2021 +0200 media: rcar-vin: Use user provided buffers when starting [ Upstream commit a5991c4e947153418f71f4689614b87ca0551b81 ] When adding an internal scratch buffer to improve buffer handling when stopping it was also erroneously used when syncing at capture start. This led to that the first three buffers captured were always dropped as they were captured in the scratch buffer instead of in a buffer provided by the user. Allow the hardware to be given user provided buffers when preparing for capture in the stopped state. This still allows the driver to sync with the hardware and always completes the buffers to user-space in the correct order as no buffers are completed before the sync is complete. This change improves the driver as buffers are completed and given to the user three frames earlier than before. The change also fixes a warning produced by v4l2-compliance, warn: v4l2-test-buffers.cpp(448): got sequence number 3, expected 0 [hverkuil: fixed some typos in the Subject and the log message] Signed-off-by: Niklas Söderlund Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 352c818df0952553bdbe4cacd37c3deae5511ce1 Author: Martin Kepplinger Date: Wed Sep 8 10:47:46 2021 +0200 media: imx: set a media_device bus_info string [ Upstream commit 6d0d779b212c27293d9ccb4da092ff0ccb6efa39 ] Some tools like v4l2-compliance let users select a media device based on the bus_info string which can be quite convenient. Use a unique string for that. This also fixes the following v4l2-compliance warning: warn: v4l2-test-media.cpp(52): empty bus_info Signed-off-by: Martin Kepplinger Reviewed-by: Laurent Pinchart Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8636c37018c3f7e719aa54d8d245d04bb412a8c5 Author: Sergey Senozhatsky Date: Thu Sep 9 13:24:23 2021 +0200 media: videobuf2: rework vb2_mem_ops API [ Upstream commit a4b83deb3e76fb9385ca58e2c072a145b3a320d6 ] With the new DMA API we need an extension of the videobuf2 API. Previously, videobuf2 core would set the non-coherent DMA bit in the vb2_queue dma_attr field (if user-space would pass a corresponding memory hint); the vb2 core then would pass the vb2_queue dma_attrs to the vb2 allocators. The vb2 allocator would use the queue's dma_attr and the DMA API would allocate either coherent or non-coherent memory. But we cannot do this anymore, since there is no corresponding DMA attr flag and, hence, there is no way for the allocator to become aware of what type of allocation user-space has requested. So we need to pass more context from videobuf2 core to the allocators. Fix this by changing the call_ptr_memop() macro to pass the vb2 pointer to the corresponding op callbacks. Signed-off-by: Sergey Senozhatsky Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ee347b739d51b82e37cad1385085ab4c451a9b20 Author: Nadezda Lutovinova Date: Wed Aug 11 15:32:28 2021 +0200 media: s5p-mfc: Add checking to s5p_mfc_probe(). [ Upstream commit cdfaf4752e6915a4b455ad4400133e540e4dc965 ] If of_device_get_match_data() return NULL, then null pointer dereference occurs in s5p_mfc_init_pm(). The patch adds checking if dev->variant is NULL. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Nadezda Lutovinova Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6980d237fd4c8c03da57b40de9cbec476f46a45f Author: Tuo Li Date: Thu Aug 5 09:55:35 2021 +0200 media: s5p-mfc: fix possible null-pointer dereference in s5p_mfc_probe() [ Upstream commit 8515965e5e33f4feb56134348c95953f3eadfb26 ] The variable pdev is assigned to dev->plat_dev, and dev->plat_dev is checked in: if (!dev->plat_dev) This indicates both dev->plat_dev and pdev can be NULL. If so, the function dev_err() is called to print error information. dev_err(&pdev->dev, "No platform data specified\n"); However, &pdev->dev is an illegal address, and it is dereferenced in dev_err(). To fix this possible null-pointer dereference, replace dev_err() with mfc_err(). Reported-by: TOTE Robot Signed-off-by: Tuo Li Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit eb7da28fd1664f86a4e4759915f8f12881fa4186 Author: Evgeny Novikov Date: Thu May 27 11:26:24 2021 +0200 media: vidtv: Fix memory leak in remove [ Upstream commit 76e21bb8be4f5f987f3006d197196fe6af63f656 ] vidtv_bridge_remove() releases and cleans up everything except for dvb itself. The patch adds this missed release. 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 2529c6a1557945e615959207e351eafba709581f Author: Ricardo Ribalda Date: Fri Jun 18 14:29:13 2021 +0200 media: uvcvideo: Set unique vdev name based in type [ Upstream commit e3f60e7e1a2b451f538f9926763432249bcf39c4 ] All the entities must have a unique name. We can have a descriptive and unique name by appending the function and the entity->id. This is even resilent to multi chain devices. Fixes v4l2-compliance: Media Controller ioctls: fail: v4l2-test-media.cpp(205): v2_entity_names_set.find(key) != v2_entity_names_set.end() test MEDIA_IOC_G_TOPOLOGY: FAIL fail: v4l2-test-media.cpp(394): num_data_links != num_links test MEDIA_IOC_ENUM_ENTITIES/LINKS: FAIL Signed-off-by: Ricardo Ribalda Reviewed-by: Hans Verkuil Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c115bfec8193a51fe547ae30f926476bdc1ba738 Author: Ricardo Ribalda Date: Fri Jun 18 14:29:09 2021 +0200 media: uvcvideo: Return -EIO for control errors [ Upstream commit ffccdde5f0e17d2f0d788a9d831a027187890eaa ] The device is doing something unexpected with the control. Either because the protocol is not properly implemented or there has been a HW error. Fixes v4l2-compliance: Control ioctls (Input 0): fail: v4l2-test-controls.cpp(448): s_ctrl returned an error (22) test VIDIOC_G/S_CTRL: FAIL fail: v4l2-test-controls.cpp(698): s_ext_ctrls returned an error (22) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Reviewed-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c0890fb5f4211ba49581b46ceb2411dc2aa73490 Author: Ricardo Ribalda Date: Fri Jun 18 14:29:08 2021 +0200 media: uvcvideo: Set capability in s_param [ Upstream commit 97a2777a96070afb7da5d587834086c0b586c8cc ] Fixes v4l2-compliance: Format ioctls (Input 0): warn: v4l2-test-formats.cpp(1339): S_PARM is supported but doesn't report V4L2_CAP_TIMEPERFRAME fail: v4l2-test-formats.cpp(1241): node->has_frmintervals && !cap->capability Reviewed-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7426dad05aaa5ee8a90921fbe06b440439fe2ee7 Author: Dmitriy Ulitin Date: Thu May 27 17:06:26 2021 +0200 media: stm32: Potential NULL pointer dereference in dcmi_irq_thread() [ Upstream commit 548fa43a58696450c15b8f5564e99589c5144664 ] At the moment of enabling irq handling: 1922 ret = devm_request_threaded_irq(&pdev->dev, irq, dcmi_irq_callback, 1923 dcmi_irq_thread, IRQF_ONESHOT, 1924 dev_name(&pdev->dev), dcmi); there is still uninitialized field sd_format of struct stm32_dcmi *dcmi. If an interrupt occurs in the interval between the installation of the interrupt handler and the initialization of this field, NULL pointer dereference happens. This field is dereferenced in the handler function without any check: 457 if (dcmi->sd_format->fourcc == V4L2_PIX_FMT_JPEG && 458 dcmi->misr & IT_FRAME) { The patch moves interrupt handler installation after initialization of the sd_format field that happens in dcmi_graph_notify_complete() via dcmi_set_default_fmt(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Dmitriy Ulitin Signed-off-by: Alexey Khoroshilov Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8277ec5aa8c537bc2f0e42c487a192de403f88cd Author: Evgeny Novikov Date: Tue Aug 10 18:29:43 2021 +0200 media: atomisp: Fix error handling in probe [ Upstream commit e16f5e39acd6d10cc63ae39bc0a77188ed828f22 ] There were several issues with handling errors in lm3554_probe(): - Probe did not set the error code when v4l2_ctrl_handler_init() failed. - It intermixed gotos for handling errors of v4l2_ctrl_handler_init() and media_entity_pads_init(). - It did not set the error code for failures of v4l2_ctrl_new_custom(). - Probe did not free resources in case of failures of atomisp_register_i2c_module(). The patch fixes all these issues. Found by Linux Driver Verification project (linuxtesting.org). Link: https://lore.kernel.org/linux-media/20210810162943.19852-1-novikov@ispras.ru Signed-off-by: Evgeny Novikov Reviewed-by: Dan Carpenter Acked-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2ba21729c2080d69cbf915ea430253599bbc7c84 Author: Zheyu Ma Date: Wed Jun 23 08:01:05 2021 +0200 media: netup_unidvb: handle interrupt properly according to the firmware [ Upstream commit dbb4cfea6efe979ed153bd59a6a527a90d3d0ab3 ] The interrupt handling should be related to the firmware version. If the driver matches an old firmware, then the driver should not handle interrupt such as i2c or dma, otherwise it will cause some errors. This log reveals it: [ 27.708641] INFO: trying to register non-static key. [ 27.710851] The code is fine but needs lockdep annotation, or maybe [ 27.712010] you didn't initialize this object before use? [ 27.712396] turning off the locking correctness validator. [ 27.712787] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4-g70e7f0549188-dirty #169 [ 27.713349] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 27.714149] Call Trace: [ 27.714329] [ 27.714480] dump_stack+0xba/0xf5 [ 27.714737] register_lock_class+0x873/0x8f0 [ 27.715052] ? __lock_acquire+0x323/0x1930 [ 27.715353] __lock_acquire+0x75/0x1930 [ 27.715636] lock_acquire+0x1dd/0x3e0 [ 27.715905] ? netup_i2c_interrupt+0x19/0x310 [ 27.716226] _raw_spin_lock_irqsave+0x4b/0x60 [ 27.716544] ? netup_i2c_interrupt+0x19/0x310 [ 27.716863] netup_i2c_interrupt+0x19/0x310 [ 27.717178] netup_unidvb_isr+0xd3/0x160 [ 27.717467] __handle_irq_event_percpu+0x53/0x3e0 [ 27.717808] handle_irq_event_percpu+0x35/0x90 [ 27.718129] handle_irq_event+0x39/0x60 [ 27.718409] handle_fasteoi_irq+0xc2/0x1d0 [ 27.718707] __common_interrupt+0x7f/0x150 [ 27.719008] common_interrupt+0xb4/0xd0 [ 27.719289] [ 27.719446] asm_common_interrupt+0x1e/0x40 [ 27.719747] RIP: 0010:native_safe_halt+0x17/0x20 [ 27.720084] Code: 07 0f 00 2d 8b ee 4c 00 f4 5d c3 0f 1f 84 00 00 00 00 00 8b 05 72 95 17 02 55 48 89 e5 85 c0 7e 07 0f 00 2d 6b ee 4c 00 fb f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d 29 f6 [ 27.721386] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246 [ 27.721758] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 [ 27.722262] RDX: 0000000000000000 RSI: ffffffff85f7c054 RDI: ffffffff85ded4e6 [ 27.722770] RBP: ffffc9000008fe90 R08: 0000000000000001 R09: 0000000000000001 [ 27.723277] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86a75408 [ 27.723781] R13: 0000000000000000 R14: 0000000000000000 R15: ffff888100260000 [ 27.724289] default_idle+0x9/0x10 [ 27.724537] arch_cpu_idle+0xa/0x10 [ 27.724791] default_idle_call+0x6e/0x250 [ 27.725082] do_idle+0x1f0/0x2d0 [ 27.725326] cpu_startup_entry+0x18/0x20 [ 27.725613] start_secondary+0x11f/0x160 [ 27.725902] secondary_startup_64_no_verify+0xb0/0xbb [ 27.726272] BUG: kernel NULL pointer dereference, address: 0000000000000002 [ 27.726768] #PF: supervisor read access in kernel mode [ 27.727138] #PF: error_code(0x0000) - not-present page [ 27.727507] PGD 8000000118688067 P4D 8000000118688067 PUD 10feab067 PMD 0 [ 27.727999] Oops: 0000 [#1] PREEMPT SMP PTI [ 27.728302] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 5.12.4-g70e7f0549188-dirty #169 [ 27.728861] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 [ 27.729660] RIP: 0010:netup_i2c_interrupt+0x23/0x310 [ 27.730019] Code: 0f 1f 80 00 00 00 00 55 48 89 e5 41 55 41 54 53 48 89 fb e8 af 6e 95 fd 48 89 df e8 e7 9f 1c 01 49 89 c5 48 8b 83 48 08 00 00 <66> 44 8b 60 02 44 89 e0 48 8b 93 48 08 00 00 83 e0 f8 66 89 42 02 [ 27.731339] RSP: 0018:ffffc90000118e90 EFLAGS: 00010046 [ 27.731716] RAX: 0000000000000000 RBX: ffff88810803c4d8 RCX: 0000000000000000 [ 27.732223] RDX: 0000000000000001 RSI: ffffffff85d37b94 RDI: ffff88810803c4d8 [ 27.732727] RBP: ffffc90000118ea8 R08: 0000000000000000 R09: 0000000000000001 [ 27.733239] R10: ffff88810803c4f0 R11: 61646e6f63657320 R12: 0000000000000000 [ 27.733745] R13: 0000000000000046 R14: ffff888101041000 R15: ffff8881081b2400 [ 27.734251] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000 [ 27.734821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.735228] CR2: 0000000000000002 CR3: 0000000108194000 CR4: 00000000000006e0 [ 27.735735] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 27.736241] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 27.736744] Call Trace: [ 27.736924] [ 27.737074] netup_unidvb_isr+0xd3/0x160 [ 27.737363] __handle_irq_event_percpu+0x53/0x3e0 [ 27.737706] handle_irq_event_percpu+0x35/0x90 [ 27.738028] handle_irq_event+0x39/0x60 [ 27.738306] handle_fasteoi_irq+0xc2/0x1d0 [ 27.738602] __common_interrupt+0x7f/0x150 [ 27.738899] common_interrupt+0xb4/0xd0 [ 27.739176] [ 27.739331] asm_common_interrupt+0x1e/0x40 [ 27.739633] RIP: 0010:native_safe_halt+0x17/0x20 [ 27.739967] Code: 07 0f 00 2d 8b ee 4c 00 f4 5d c3 0f 1f 84 00 00 00 00 00 8b 05 72 95 17 02 55 48 89 e5 85 c0 7e 07 0f 00 2d 6b ee 4c 00 fb f4 <5d> c3 cc cc cc cc cc cc cc 55 48 89 e5 e8 67 53 ff ff 8b 0d 29 f6 [ 27.741275] RSP: 0018:ffffc9000008fe90 EFLAGS: 00000246 [ 27.741647] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000 [ 27.742148] RDX: 0000000000000000 RSI: ffffffff85f7c054 RDI: ffffffff85ded4e6 [ 27.742652] RBP: ffffc9000008fe90 R08: 0000000000000001 R09: 0000000000000001 [ 27.743154] R10: 0000000000000000 R11: 0000000000000001 R12: ffffffff86a75408 [ 27.743652] R13: 0000000000000000 R14: 0000000000000000 R15: ffff888100260000 [ 27.744157] default_idle+0x9/0x10 [ 27.744405] arch_cpu_idle+0xa/0x10 [ 27.744658] default_idle_call+0x6e/0x250 [ 27.744948] do_idle+0x1f0/0x2d0 [ 27.745190] cpu_startup_entry+0x18/0x20 [ 27.745475] start_secondary+0x11f/0x160 [ 27.745761] secondary_startup_64_no_verify+0xb0/0xbb [ 27.746123] Modules linked in: [ 27.746348] Dumping ftrace buffer: [ 27.746596] (ftrace buffer empty) [ 27.746852] CR2: 0000000000000002 [ 27.747094] ---[ end trace ebafd46f83ab946d ]--- [ 27.747424] RIP: 0010:netup_i2c_interrupt+0x23/0x310 [ 27.747778] Code: 0f 1f 80 00 00 00 00 55 48 89 e5 41 55 41 54 53 48 89 fb e8 af 6e 95 fd 48 89 df e8 e7 9f 1c 01 49 89 c5 48 8b 83 48 08 00 00 <66> 44 8b 60 02 44 89 e0 48 8b 93 48 08 00 00 83 e0 f8 66 89 42 02 [ 27.749082] RSP: 0018:ffffc90000118e90 EFLAGS: 00010046 [ 27.749461] RAX: 0000000000000000 RBX: ffff88810803c4d8 RCX: 0000000000000000 [ 27.749966] RDX: 0000000000000001 RSI: ffffffff85d37b94 RDI: ffff88810803c4d8 [ 27.750471] RBP: ffffc90000118ea8 R08: 0000000000000000 R09: 0000000000000001 [ 27.750976] R10: ffff88810803c4f0 R11: 61646e6f63657320 R12: 0000000000000000 [ 27.751480] R13: 0000000000000046 R14: ffff888101041000 R15: ffff8881081b2400 [ 27.751986] FS: 0000000000000000(0000) GS:ffff88817bc80000(0000) knlGS:0000000000000000 [ 27.752560] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 27.752970] CR2: 0000000000000002 CR3: 0000000108194000 CR4: 00000000000006e0 [ 27.753481] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 27.753984] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 27.754487] Kernel panic - not syncing: Fatal exception in interrupt [ 27.755033] Dumping ftrace buffer: [ 27.755279] (ftrace buffer empty) [ 27.755534] Kernel Offset: disabled [ 27.755785] Rebooting in 1 seconds.. Signed-off-by: Zheyu Ma Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2a1061af333ef2d62972cf33d5880e9b18a1cc8b Author: Dirk Bender Date: Mon Jul 26 09:35:15 2021 +0200 media: mt9p031: Fix corrupted frame after restarting stream [ Upstream commit 0961ba6dd211a4a52d1dd4c2d59be60ac2dc08c7 ] To prevent corrupted frames after starting and stopping the sensor its datasheet specifies a specific pause sequence to follow: Stopping: Set Pause_Restart Bit -> Set Restart Bit -> Set Chip_Enable Off Restarting: Set Chip_Enable On -> Clear Pause_Restart Bit The Restart Bit is cleared automatically and must not be cleared manually as this would cause undefined behavior. Signed-off-by: Dirk Bender Signed-off-by: Stefan Riedmueller Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d808c6ee0c608ff5e191877e88bea2f30e817459 Author: Rakesh Babu Date: Tue Sep 28 23:13:45 2021 +0530 octeontx2-pf: Enable promisc/allmulti match MCAM entries. [ Upstream commit ffd2f89ad05cd620d822112a07b0c5669fa9e333 ] Whenever the interface is brought up/down then set_rx_mode function is called by the stack which enables promisc/allmulti MCAM entries. But there are cases when driver brings interface down and then up such as while changing number of channels. In these cases promisc/allmulti MCAM entries are left disabled as set_rx_mode callback is not called. This patch enables these MCAM entries in all such cases. Signed-off-by: Rakesh Babu Signed-off-by: Subbaraya Sundeep Signed-off-by: Sunil Goutham Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2a27405cfaa541966f169fc63ce2d6374ea43c1f Author: Alagu Sankar Date: Tue Sep 28 14:00:47 2021 +0300 ath10k: high latency fixes for beacon buffer [ Upstream commit e263bdab9c0e8025fb7f41f153709a9cda51f6b6 ] Beacon buffer for high latency devices does not use DMA. other similar buffer allocation methods in the driver have already been modified for high latency path. Fix the beacon buffer allocation left out in the earlier high latency changes. Signed-off-by: Alagu Sankar Signed-off-by: Erik Stromdahl [fabio: adapt it to use ar->bus_param.dev_type ] Signed-off-by: Fabio Estevam Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210818232627.2040121-1-festevam@denx.de Signed-off-by: Sasha Levin commit fb34da024434db312564ea4fdfbcf71b5035b0d3 Author: Baochen Qiang Date: Tue Sep 28 14:00:46 2021 +0300 ath11k: Change DMA_FROM_DEVICE to DMA_TO_DEVICE when map reinjected packets [ Upstream commit 86a03dad0f5ad8182ed5fcf7bf3eec71cd96577c ] For fragmented packets, ath11k reassembles each fragment as a normal packet and then reinjects it into HW ring. In this case, the DMA direction should be DMA_TO_DEVICE, not DMA_FROM_DEVICE, otherwise invalid payload will be reinjected to HW and then delivered to host. What is more, since arbitrary memory could be allocated to the frame, we don't know what kind of data is contained in the buffer reinjected. Thus, as a bad result, private info may be leaked. Note that this issue is only found on Intel platform. Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1 Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210916064617.20006-1-bqiang@codeaurora.org Signed-off-by: Sasha Levin commit d08b51d94747519f78239034b1f4d0b1d2c29c42 Author: Wen Gong Date: Tue Sep 28 14:00:45 2021 +0300 ath11k: add handler for scan event WMI_SCAN_EVENT_DEQUEUED [ Upstream commit 441b3b5911f8ead7f2fe2336587b340a33044d58 ] When wlan interface is up, 11d scan is sent to the firmware, and the firmware needs to spend couple of seconds to complete the 11d scan. If immediately a normal scan from user space arrives to ath11k, then the normal scan request is also sent to the firmware, but the scan started event will be reported to ath11k until the 11d scan complete. When timed out for the scan started in ath11k, ath11k stops the normal scan and the firmware reports WMI_SCAN_EVENT_DEQUEUED to ath11k for the normal scan. ath11k has no handler for the event and then timed out for the scan completed in ath11k_scan_stop(), and ath11k prints the following error message. [ 1491.604750] ath11k_pci 0000:02:00.0: failed to receive scan abort comple: timed out [ 1491.604756] ath11k_pci 0000:02:00.0: failed to stop scan: -110 [ 1491.604758] ath11k_pci 0000:02:00.0: failed to start hw scan: -110 Add a handler for WMI_SCAN_EVENT_DEQUEUED and then complete the scan to get rid of the above error message. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-01720.1-QCAHSPSWPL_V1_V2_SILICONZ_LITE-1 Signed-off-by: Wen Gong Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210914164226.38843-1-jouni@codeaurora.org Signed-off-by: Sasha Levin commit 08de8bf704a5a59f8ff1a017efc54b7571e702c8 Author: Sriram R Date: Tue Sep 28 12:05:40 2021 +0300 ath11k: Avoid reg rules update during firmware recovery [ Upstream commit 69a0fcf8a9f2273040d03e5ee77c9689c09e9d3a ] During firmware recovery, the default reg rules which are received via WMI_REG_CHAN_LIST_CC_EVENT can overwrite the currently configured user regd. See below snap for example, root@OpenWrt:/# iw reg get | grep country country FR: DFS-ETSI country FR: DFS-ETSI country FR: DFS-ETSI country FR: DFS-ETSI root@OpenWrt:/# echo assert > /sys/kernel/debug/ath11k/ipq8074\ hw2.0/simulate_f w_crash [ 5290.471696] ath11k c000000.wifi1: pdev 1 successfully recovered root@OpenWrt:/# iw reg get | grep country country FR: DFS-ETSI country US: DFS-FCC country US: DFS-FCC country US: DFS-FCC In the above, the user configured country 'FR' is overwritten when the rules of default country 'US' are received and updated during recovery. Hence avoid processing of these rules in general during firmware recovery as they have been already applied during driver registration or after last set user country is configured. This scenario applies for both AP and STA devices basically because cfg80211 is not aware of the recovery and only the driver recovers, but changing or resetting of the reg domain during recovery is not needed so as to continue with the configured regdomain currently in use. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.4.0.1-01460-QCAHKSWPL_SILICONZ-1 Signed-off-by: Sriram R Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210721212029.142388-3-jouni@codeaurora.org Signed-off-by: Sasha Levin commit b584bd22861403f1106148f9a68589efd9abfe5a Author: Petr Machata Date: Fri Sep 24 12:04:27 2021 +0200 selftests: net: fib_nexthops: Wait before checking reported idle time [ Upstream commit b69c99463d414cc263411462d52f25205657e9af ] The purpose of this test is to verify that after a short activity passes, the reported time is reasonable: not zero (which could be reported by mistake), and not something outrageous (which would be indicative of an issue in used units). However, the idle time is reported in units of clock_t, or hundredths of second. If the initial sequence of commands is very quick, it is possible that the idle time is reported as just flat-out zero. When this test was recently enabled in our nightly regression, we started seeing spurious failures for exactly this reason. Therefore buffer the delay leading up to the test with a sleep, to make sure there is no legitimate way of reporting 0. Signed-off-by: Petr Machata Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 9ea7c08eb6344bf46b272e999830b7617e1c3b5a Author: Jimmy Kizito Date: Sun Sep 12 11:21:52 2021 -0400 drm/amd/display: Fix null pointer dereference for encoders [ Upstream commit 60f39edd897ea134a4ddb789a6795681691c3183 ] [Why] Links which are dynamically assigned link encoders have their link encoder set to NULL. [How] Check that a pointer to a link_encoder object is non-NULL before using it. Reviewed-by: Aric Cyr Reviewed-by: Meenakshikumar Somasundaram Acked-by: Rodrigo Siqueira Signed-off-by: Jimmy Kizito Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit adb3b9b2a55056b028eed940437bee1c6ce476a0 Author: Andrey Grodzovsky Date: Thu Sep 16 12:54:07 2021 -0400 drm/amdgpu: Fix MMIO access page fault [ Upstream commit c03509cbc01559549700e14c4a6239f2572ab4ba ] Add more guards to MMIO access post device unbind/unplug Bug: https://bugs.archlinux.org/task/72092?project=1&order=dateopened&sort=desc&pagenum=1 Signed-off-by: Andrey Grodzovsky Reviewed-by: James Zhu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 40cfb8e68aa073f03c25bc33022a8dbb29fdc777 Author: Eric Biggers Date: Mon Sep 20 20:03:03 2021 -0700 fscrypt: allow 256-bit master keys with AES-256-XTS [ Upstream commit 7f595d6a6cdc336834552069a2e0a4f6d4756ddf ] fscrypt currently requires a 512-bit master key when AES-256-XTS is used, since AES-256-XTS keys are 512-bit and fscrypt requires that the master key be at least as long any key that will be derived from it. However, this is overly strict because AES-256-XTS doesn't actually have a 512-bit security strength, but rather 256-bit. The fact that XTS takes twice the expected key size is a quirk of the XTS mode. It is sufficient to use 256 bits of entropy for AES-256-XTS, provided that it is first properly expanded into a 512-bit key, which HKDF-SHA512 does. Therefore, relax the check of the master key size to use the security strength of the derived key rather than the size of the derived key (except for v1 encryption policies, which don't use HKDF). Besides making things more flexible for userspace, this is needed in order for the use of a KDF which only takes a 256-bit key to be introduced into the fscrypt key hierarchy. This will happen with hardware-wrapped keys support, as all known hardware which supports that feature uses an SP800-108 KDF using AES-256-CMAC, so the wrapped keys are wrapped 256-bit AES keys. Moreover, there is interest in fscrypt supporting the same type of AES-256-CMAC based KDF in software as an alternative to HKDF-SHA512. There is no security problem with such features, so fix the key length check to work properly with them. Reviewed-by: Paul Crowley Link: https://lore.kernel.org/r/20210921030303.5598-1-ebiggers@kernel.org Signed-off-by: Eric Biggers Signed-off-by: Sasha Levin commit 53283ee464c329b0dec60b55cffb1e78cd860289 Author: Mark Brown Date: Tue Sep 21 20:21:49 2021 +0100 spi: Check we have a spi_device_id for each DT compatible [ Upstream commit 5fa6863ba69265cb7e45567d12614790ff26bd56 ] Currently for SPI devices we use the spi_device_id for module autoloading even on systems using device tree, meaning that listing a compatible string in the of_match_table isn't enough to have the module for a SPI driver autoloaded. We attempted to fix this by generating OF based modaliases for devices instantiated from DT in 3ce6c9e2617e ("spi: add of_device_uevent_modalias support") but this meant we no longer reported spi_device_id based aliases which broke drivers such as spi-nor which don't list all the compatible strings they support directly for DT, and in at least that case it's not super practical to do so given the very large number of compatibles needed, much larger than the number spi_device_ids due to vendor strings. As a result fell back to using spi_device_id based modalises. Try to close the gap by printing a warning when a SPI driver has a DT compatible that won't be matched as a SPI device ID with the goal of having drivers provide both. Given fallback compatibles this check is going to be excessive but it should be robust which is probably more important here. Signed-off-by: Mark Brown Link: https://lore.kernel.org/r/20210921192149.50740-1-broonie@kernel.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6cd93f39dd2bfb1512556d451c4c0faf3e85f7d6 Author: Jonas Dreßler Date: Tue Sep 14 21:59:08 2021 +0200 mwifiex: Properly initialize private structure on interface type changes [ Upstream commit c606008b70627a2fc485732a53cc22f0f66d0981 ] When creating a new virtual interface in mwifiex_add_virtual_intf(), we update our internal driver states like bss_type, bss_priority, bss_role and bss_mode to reflect the mode the firmware will be set to. When switching virtual interface mode using mwifiex_init_new_priv_params() though, we currently only update bss_mode and bss_role. In order for the interface mode switch to actually work, we also need to update bss_type to its proper value, so do that. This fixes a crash of the firmware (because the driver tries to execute commands that are invalid in AP mode) when switching from station mode to AP mode. Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210914195909.36035-9-verdre@v0yd.nl Signed-off-by: Sasha Levin commit 7871a1156efd34bf782339c1977e1c100621e44f Author: Jonas Dreßler Date: Tue Sep 14 21:59:03 2021 +0200 mwifiex: Run SET_BSS_MODE when changing from P2P to STATION vif-type [ Upstream commit c2e9666cdffd347460a2b17988db4cfaf2a68fb9 ] We currently handle changing from the P2P to the STATION virtual interface type slightly different than changing from P2P to ADHOC: When changing to STATION, we don't send the SET_BSS_MODE command. We do send that command on all other type-changes though, and it probably makes sense to send the command since after all we just changed our BSS_MODE. Looking at prior changes to this part of the code, it seems that this is simply a leftover from old refactorings. Since sending the SET_BSS_MODE command is the only difference between mwifiex_change_vif_to_sta_adhoc() and the current code, we can now use mwifiex_change_vif_to_sta_adhoc() for both switching to ADHOC and STATION interface type. This does not fix any particular bug and just "looked right", so there's a small chance it might be a regression. Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210914195909.36035-4-verdre@v0yd.nl Signed-off-by: Sasha Levin commit 41592079230a41c9e09b91d5c285cd82e73a3cb1 Author: Peter Zijlstra Date: Wed Sep 15 16:19:46 2021 +0200 x86: Increase exception stack sizes [ Upstream commit 7fae4c24a2b84a66c7be399727aca11e7a888462 ] It turns out that a single page of stack is trivial to overflow with all the tracing gunk enabled. Raise the exception stacks to 2 pages, which is still half the interrupt stacks, which are at 4 pages. Reported-by: Michael Wang Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/YUIO9Ye98S5Eb68w@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit bb3cc292e1a2aad1d596abbc5533321d07ce7881 Author: Peter Zijlstra Date: Wed Sep 15 17:12:59 2021 +0200 x86/mm/64: Improve stack overflow warnings [ Upstream commit 44b979fa302cab91bdd2cc982823e5c13202cd4e ] Current code has an explicit check for hitting the task stack guard; but overflowing any of the other stacks will get you a non-descript general #DF warning. Improve matters by using get_stack_info_noinstr() to detetrmine if and which stack guard page got hit, enabling a better stack warning. In specific, Michael Wang reported what turned out to be an NMI exception stack overflow, which is now clearly reported as such: [] BUG: NMI stack guard page was hit at 0000000085fd977b (stack is 000000003a55b09e..00000000d8cce1a5) Reported-by: Michael Wang Signed-off-by: Peter Zijlstra (Intel) Tested-by: Michael Wang Link: https://lkml.kernel.org/r/YUTE/NuqnaWbST8n@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 35512e50669068e2782c5975ea7fd71921dcda1a Author: Shreyansh Chouhan Date: Sat Sep 11 16:37:59 2021 +0530 crypto: aesni - check walk.nbytes instead of err [ Upstream commit a2d3cbc80d2527b435154ff0f89b56ef4b84370f ] In the code for xts_crypt(), we check for the err value returned by skcipher_walk_virt() and return from the function if it is non zero. However, skcipher_walk_virt() can set walk.nbytes to 0, which would cause us to call kernel_fpu_begin(), and then skip the kernel_fpu_end() call. This patch checks for the walk.nbytes value instead, and returns if walk.nbytes is 0. This prevents us from calling kernel_fpu_begin() in the first place and also covers the case of having a non zero err value returned from skcipher_walk_virt(). Reported-by: Dan Carpenter Signed-off-by: Shreyansh Chouhan Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit b1b32bcc221aec6481b2aea782bef8fcc830010e Author: Seevalamuthu Mariappan Date: Wed Jul 21 00:49:22 2021 +0300 ath11k: Align bss_chan_info structure with firmware [ Upstream commit feab5bb8f1d4621025dceae7eef62d5f92de34ac ] pdev_id in structure 'wmi_pdev_bss_chan_info_event' is wrongly placed at the beginning. This causes invalid values in survey dump. Hence, align the structure with the firmware. Note: The firmware releases follow this order since the feature was implemented. Also, it is not changing across the branches including QCA6390. Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.1.0.1-01228-QCAHKSWPL_SILICONZ-1 Signed-off-by: Ritesh Singh Signed-off-by: Seevalamuthu Mariappan Signed-off-by: Jouni Malinen Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210720214922.118078-3-jouni@codeaurora.org Signed-off-by: Sasha Levin commit 8ed576395f6a9dbf8ce39351d00cc83e093b4598 Author: Pawan Gupta Date: Sat Aug 28 23:41:40 2021 -0700 smackfs: Fix use-after-free in netlbl_catmap_walk() [ Upstream commit 0817534ff9ea809fac1322c5c8c574be8483ea57 ] Syzkaller reported use-after-free bug as described in [1]. The bug is triggered when smk_set_cipso() tries to free stale category bitmaps while there are concurrent reader(s) using the same bitmaps. Wait for RCU grace period to finish before freeing the category bitmaps in smk_set_cipso(). This makes sure that there are no more readers using the stale bitmaps and freeing them should be safe. [1] https://lore.kernel.org/netdev/000000000000a814c505ca657a4e@google.com/ Reported-by: syzbot+3f91de0b813cc3d19a80@syzkaller.appspotmail.com Signed-off-by: Pawan Gupta Signed-off-by: Casey Schaufler Signed-off-by: Sasha Levin commit 3f55b610b488dae0d7f831af14d4968d32cdf47c Author: Paul E. McKenney Date: Wed Aug 11 09:07:44 2021 -0700 rcu-tasks: Move RTGS_WAIT_CBS to beginning of rcu_tasks_kthread() loop [ Upstream commit 0db7c32ad3160ae06f497d48a74bd46a2a35e6bf ] Early in debugging, it made some sense to differentiate the first iteration from subsequent iterations, but now this just causes confusion. This commit therefore moves the "set_tasks_gp_state(rtp, RTGS_WAIT_CBS)" statement to the beginning of the "for" loop in rcu_tasks_kthread(). Reported-by: Neeraj Upadhyay Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 0fcd85c7f3a122d8de0fa96617341bc315e2f6ad Author: Hui Wang Date: Wed Sep 15 21:09:05 2021 +0800 ACPI: resources: Add DMI-based legacy IRQ override quirk [ Upstream commit 892a012699fc0b91a2ed6309078936191447f480 ] After the commit 0ec4e55e9f57 ("ACPI: resources: Add checks for ACPI IRQ override") is reverted, the keyboard on Medion laptops can't work again. To fix the keyboard issue, add a DMI-based override check that will not affect other machines along the lines of prt_quirks[] in drivers/acpi/pci_irq.c. If similar issues are seen on other platforms, the quirk table could be expanded in the future. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213031 BugLink: http://bugs.launchpad.net/bugs/1909814 Suggested-by: Rafael J. Wysocki Reported-by: Manuel Krause Tested-by: Manuel Krause Signed-off-by: Hui Wang [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 8a6214e36ff2364ed1d6cb4116c02deccfa7ca5c Author: Jakub Kicinski Date: Mon Sep 13 15:53:30 2021 -0700 net: sched: update default qdisc visibility after Tx queue cnt changes [ Upstream commit 1e080f17750d1083e8a32f7b350584ae1cd7ff20 ] mq / mqprio make the default child qdiscs visible. They only do so for the qdiscs which are within real_num_tx_queues when the device is registered. Depending on order of calls in the driver, or if user space changes config via ethtool -L the number of qdiscs visible under tc qdisc show will differ from the number of queues. This is confusing to users and potentially to system configuration scripts which try to make sure qdiscs have the right parameters. Add a new Qdisc_ops callback and make relevant qdiscs TTRT. Note that this uncovers the "shortcut" created by commit 1f27cde313d7 ("net: sched: use pfifo_fast for non real queues") The default child qdiscs beyond initial real_num_tx are always pfifo_fast, no matter what the sysfs setting is. Fixing this gets a little tricky because we'd need to keep a reference on whatever the default qdisc was at the time of creation. In practice this is likely an non-issue the qdiscs likely have to be configured to non-default settings, so whatever user space is doing such configuration can replace the pfifos... now that it will see them. Reported-by: Matthew Massey Reviewed-by: Dave Taht Signed-off-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f0ca9344d9e2d957a4f23efc73ddf9e24ee789f Author: Peter Zijlstra Date: Thu Jun 24 11:41:10 2021 +0200 locking/lockdep: Avoid RCU-induced noinstr fail [ Upstream commit ce0b9c805dd66d5e49fd53ec5415ae398f4c56e6 ] vmlinux.o: warning: objtool: look_up_lock_class()+0xc7: call to rcu_read_lock_any_held() leaves .noinstr.text section Signed-off-by: Peter Zijlstra (Intel) Link: https://lore.kernel.org/r/20210624095148.311980536@infradead.org Signed-off-by: Sasha Levin commit 134cef7b69740915759a6af9e3ab765428c00bb7 Author: Aleksander Jan Bajkowski Date: Tue Sep 14 23:20:59 2021 +0200 MIPS: lantiq: dma: reset correct number of channel [ Upstream commit 5ca9ce2ba4d5884cd94d1a856c675ab1242cd242 ] Different SoCs have a different number of channels, e.g .: * amazon-se has 10 channels, * danube+ar9 have 20 channels, * vr9 has 28 channels, * ar10 has 24 channels. We can read the ID register and, depending on the reported number of channels, reset the appropriate number of channels. Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1415242fd96bf51eccfa0b9fdf109a48aaa58fc5 Author: Aleksander Jan Bajkowski Date: Tue Sep 14 23:20:58 2021 +0200 MIPS: lantiq: dma: add small delay after reset [ Upstream commit c12aa581f6d5e80c3c3675ab26a52c2b3b62f76e ] Reading the DMA registers immediately after the reset causes Data Bus Error. Adding a small delay fixes this issue. Signed-off-by: Aleksander Jan Bajkowski Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f3b5ecab2735efc9b48a5288e4e68244ef645493 Author: Barnabás Pőcze Date: Sat Sep 4 17:56:26 2021 +0000 platform/x86: wmi: do not fail if disabling fails [ Upstream commit 1975718c488a39128f1f515b23ae61a5a214cc3d ] Previously, `__query_block()` would fail if the second WCxx method call failed. However, the WQxx method might have succeeded, and potentially allocated memory for the result. Instead of throwing away the result and potentially leaking memory, ignore the result of the second WCxx call. Signed-off-by: Barnabás Pőcze Link: https://lore.kernel.org/r/20210904175450.156801-25-pobrn@protonmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit d50100c17038d5448dcf959ba6853f0d61a4c65d Author: Scott Wood Date: Fri Aug 20 09:42:36 2021 +0200 rcutorture: Avoid problematic critical section nesting on PREEMPT_RT [ Upstream commit 71921a9606ddbcc1d98c00eca7ae82c373d1fecd ] rcutorture is generating some nesting scenarios that are not compatible on PREEMPT_RT. For example: preempt_disable(); rcu_read_lock_bh(); preempt_enable(); rcu_read_unlock_bh(); The problem here is that on PREEMPT_RT the bottom halves have to be disabled and enabled in preemptible context. Reorder locking: start with BH locking and continue with then with disabling preemption or interrupts. In the unlocking do it reverse by first enabling interrupts and preemption and BH at the very end. Ensure that on PREEMPT_RT BH locking remains unchanged if in non-preemptible context. Link: https://lkml.kernel.org/r/20190911165729.11178-6-swood@redhat.com Link: https://lkml.kernel.org/r/20210819182035.GF4126399@paulmck-ThinkPad-P17-Gen-1 Signed-off-by: Scott Wood [bigeasy: Drop ATOM_BH, make it only about changing BH in atomic context. Allow enabling RCU in IRQ-off section. Reword commit message.] Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 5aad1e68ff1e0e7bf267196a0d0c8a1dc929a443 Author: Simon Ser Date: Sat Sep 11 10:24:40 2021 +0000 drm/panel-orientation-quirks: add Valve Steam Deck [ Upstream commit 9eeb7b4e40bfd69d8aaa920c7e9df751c9e11dce ] Valve's Steam Deck has a 800x1280 LCD screen. Signed-off-by: Simon Ser Cc: Jared Baldridge Cc: Emil Velikov Cc: Daniel Vetter Cc: Hans de Goede Acked-by: Sam Ravnborg Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20210911102430.253986-1-contact@emersion.fr Signed-off-by: Sasha Levin commit b87da982da1b4787e23316e3eedc6bba52cfba64 Author: Wang ShaoBo Date: Tue Aug 31 17:35:37 2021 -0700 Bluetooth: fix use-after-free error in lock_sock_nested() [ Upstream commit 1bff51ea59a9afb67d2dd78518ab0582a54a472c ] use-after-free error in lock_sock_nested is reported: [ 179.140137][ T3731] ===================================================== [ 179.142675][ T3731] BUG: KMSAN: use-after-free in lock_sock_nested+0x280/0x2c0 [ 179.145494][ T3731] CPU: 4 PID: 3731 Comm: kworker/4:2 Not tainted 5.12.0-rc6+ #54 [ 179.148432][ T3731] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 [ 179.151806][ T3731] Workqueue: events l2cap_chan_timeout [ 179.152730][ T3731] Call Trace: [ 179.153301][ T3731] dump_stack+0x24c/0x2e0 [ 179.154063][ T3731] kmsan_report+0xfb/0x1e0 [ 179.154855][ T3731] __msan_warning+0x5c/0xa0 [ 179.155579][ T3731] lock_sock_nested+0x280/0x2c0 [ 179.156436][ T3731] ? kmsan_get_metadata+0x116/0x180 [ 179.157257][ T3731] l2cap_sock_teardown_cb+0xb8/0x890 [ 179.158154][ T3731] ? __msan_metadata_ptr_for_load_8+0x10/0x20 [ 179.159141][ T3731] ? kmsan_get_metadata+0x116/0x180 [ 179.159994][ T3731] ? kmsan_get_shadow_origin_ptr+0x84/0xb0 [ 179.160959][ T3731] ? l2cap_sock_recv_cb+0x420/0x420 [ 179.161834][ T3731] l2cap_chan_del+0x3e1/0x1d50 [ 179.162608][ T3731] ? kmsan_get_metadata+0x116/0x180 [ 179.163435][ T3731] ? kmsan_get_shadow_origin_ptr+0x84/0xb0 [ 179.164406][ T3731] l2cap_chan_close+0xeea/0x1050 [ 179.165189][ T3731] ? kmsan_internal_unpoison_shadow+0x42/0x70 [ 179.166180][ T3731] l2cap_chan_timeout+0x1da/0x590 [ 179.167066][ T3731] ? __msan_metadata_ptr_for_load_8+0x10/0x20 [ 179.168023][ T3731] ? l2cap_chan_create+0x560/0x560 [ 179.168818][ T3731] process_one_work+0x121d/0x1ff0 [ 179.169598][ T3731] worker_thread+0x121b/0x2370 [ 179.170346][ T3731] kthread+0x4ef/0x610 [ 179.171010][ T3731] ? process_one_work+0x1ff0/0x1ff0 [ 179.171828][ T3731] ? kthread_blkcg+0x110/0x110 [ 179.172587][ T3731] ret_from_fork+0x1f/0x30 [ 179.173348][ T3731] [ 179.173752][ T3731] Uninit was created at: [ 179.174409][ T3731] kmsan_internal_poison_shadow+0x5c/0xf0 [ 179.175373][ T3731] kmsan_slab_free+0x76/0xc0 [ 179.176060][ T3731] kfree+0x3a5/0x1180 [ 179.176664][ T3731] __sk_destruct+0x8af/0xb80 [ 179.177375][ T3731] __sk_free+0x812/0x8c0 [ 179.178032][ T3731] sk_free+0x97/0x130 [ 179.178686][ T3731] l2cap_sock_release+0x3d5/0x4d0 [ 179.179457][ T3731] sock_close+0x150/0x450 [ 179.180117][ T3731] __fput+0x6bd/0xf00 [ 179.180787][ T3731] ____fput+0x37/0x40 [ 179.181481][ T3731] task_work_run+0x140/0x280 [ 179.182219][ T3731] do_exit+0xe51/0x3e60 [ 179.182930][ T3731] do_group_exit+0x20e/0x450 [ 179.183656][ T3731] get_signal+0x2dfb/0x38f0 [ 179.184344][ T3731] arch_do_signal_or_restart+0xaa/0xe10 [ 179.185266][ T3731] exit_to_user_mode_prepare+0x2d2/0x560 [ 179.186136][ T3731] syscall_exit_to_user_mode+0x35/0x60 [ 179.186984][ T3731] do_syscall_64+0xc5/0x140 [ 179.187681][ T3731] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 179.188604][ T3731] ===================================================== In our case, there are two Thread A and B: Context: Thread A: Context: Thread B: l2cap_chan_timeout() __se_sys_shutdown() l2cap_chan_close() l2cap_sock_shutdown() l2cap_chan_del() l2cap_chan_close() l2cap_sock_teardown_cb() l2cap_sock_teardown_cb() Once l2cap_sock_teardown_cb() excuted, this sock will be marked as SOCK_ZAPPED, and can be treated as killable in l2cap_sock_kill() if sock_orphan() has excuted, at this time we close sock through sock_close() which end to call l2cap_sock_kill() like Thread C: Context: Thread C: sock_close() l2cap_sock_release() sock_orphan() l2cap_sock_kill() #free sock if refcnt is 1 If C completed, Once A or B reaches l2cap_sock_teardown_cb() again, use-after-free happened. We should set chan->data to NULL if sock is destructed, for telling teardown operation is not allowed in l2cap_sock_teardown_cb(), and also we should avoid killing an already killed socket in l2cap_sock_close_cb(). Signed-off-by: Wang ShaoBo Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 2c2b295af72e4e30d17556375e100ae65ac0b896 Author: Takashi Iwai Date: Sat Aug 28 18:18:18 2021 +0200 Bluetooth: sco: Fix lock_sock() blockage by memcpy_from_msg() [ Upstream commit 99c23da0eed4fd20cae8243f2b51e10e66aa0951 ] The sco_send_frame() also takes lock_sock() during memcpy_from_msg() call that may be endlessly blocked by a task with userfaultd technique, and this will result in a hung task watchdog trigger. Just like the similar fix for hci_sock_sendmsg() in commit 92c685dc5de0 ("Bluetooth: reorganize functions..."), this patch moves the memcpy_from_msg() out of lock_sock() for addressing the hang. This should be the last piece for fixing CVE-2021-3640 after a few already queued fixes. Signed-off-by: Takashi Iwai Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 9314415aaed7cef531020674a0cd87b7c9b79f7e Author: Hans de Goede Date: Sun May 30 13:04:27 2021 +0200 drm: panel-orientation-quirks: Add quirk for the Samsung Galaxy Book 10.6 [ Upstream commit 88fa1fde918951c175ae5ea0f31efc4bb1736ab9 ] The Samsung Galaxy Book 10.6 uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede Acked-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-4-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 491defc1c9d6a245260fb49dcd3429cd6d46e428 Author: Hans de Goede Date: Sun May 30 13:04:26 2021 +0200 drm: panel-orientation-quirks: Add quirk for KD Kurio Smart C15200 2-in-1 [ Upstream commit a53f1dd3ab9fec715c6c2e8e01bf4d3c07eef8e5 ] The KD Kurio Smart C15200 2-in-1 uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede Acked-by: Simon Ser Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-3-hdegoede@redhat.com Signed-off-by: Sasha Levin commit b7a63c785ae6d5860b9cd009eb9923956ace6905 Author: Hans de Goede Date: Sun May 30 13:04:25 2021 +0200 drm: panel-orientation-quirks: Update the Lenovo Ideapad D330 quirk (v2) [ Upstream commit 820a2ab23d5eab4ccfb82581eda8ad4acf18458f ] 2 improvements to the Lenovo Ideapad D330 panel-orientation quirks: 1. Some versions of the Lenovo Ideapad D330 have a DMI_PRODUCT_NAME of "81H3" and others have "81MD". Testing has shown that the "81MD" also has a 90 degree mounted panel. Drop the DMI_PRODUCT_NAME from the existing quirk so that the existing quirk matches both variants. 2. Some of the Lenovo Ideapad D330 models have a HD (800x1280) screen instead of a FHD (1200x1920) screen (both are mounted right-side-up) add a second Lenovo Ideapad D330 quirk for the HD version. Changes in v2: - Add a new quirk for Lenovo Ideapad D330 models with a HD screen instead of a FHD screen Link: https://github.com/systemd/systemd/pull/18884 Acked-by: Simon Ser Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20210530110428.12994-2-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e158f9b7feeaebc345f8f06870e2bdfdbd3ad931 Author: Charan Teja Reddy Date: Fri Jul 23 18:01:08 2021 +0530 dma-buf: WARN on dmabuf release with pending attachments [ Upstream commit f492283b157053e9555787262f058ae33096f568 ] It is expected from the clients to follow the below steps on an imported dmabuf fd: a) dmabuf = dma_buf_get(fd) // Get the dmabuf from fd b) dma_buf_attach(dmabuf); // Clients attach to the dmabuf o Here the kernel does some slab allocations, say for dma_buf_attachment and may be some other slab allocation in the dmabuf->ops->attach(). c) Client may need to do dma_buf_map_attachment(). d) Accordingly dma_buf_unmap_attachment() should be called. e) dma_buf_detach () // Clients detach to the dmabuf. o Here the slab allocations made in b) are freed. f) dma_buf_put(dmabuf) // Can free the dmabuf if it is the last reference. Now say an erroneous client failed at step c) above thus it directly called dma_buf_put(), step f) above. Considering that it may be the last reference to the dmabuf, buffer will be freed with pending attachments left to the dmabuf which can show up as the 'memory leak'. This should at least be reported as the WARN(). Signed-off-by: Charan Teja Reddy Reviewed-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/1627043468-16381-1-git-send-email-charante@codeaurora.org Signed-off-by: Christian König Signed-off-by: Sasha Levin commit 5493d7e67ec708baff82b6d55ec8f76a5f6ea3c1 Author: Kai Vehmanen Date: Wed Oct 13 19:13:45 2021 +0300 component: do not leave master devres group open after bind commit c87761db2100677a69be551365105125d872af5b upstream. In current code, the devres group for aggregate master is left open after call to component_master_add_*(). This leads to problems when the master does further managed allocations on its own. When any participating driver calls component_del(), this leads to immediate release of resources. This came up when investigating a page fault occurring with i915 DRM driver unbind with 5.15-rc1 kernel. The following sequence occurs: i915_pci_remove() -> intel_display_driver_unregister() -> i915_audio_component_cleanup() -> component_del() -> component.c:take_down_master() -> hdac_component_master_unbind() [via master->ops->unbind()] -> devres_release_group(master->parent, NULL) With older kernels this has not caused issues, but with audio driver moving to use managed interfaces for more of its allocations, this no longer works. Devres log shows following to occur: component_master_add_with_match() [ 126.886032] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000323ccdc5 devm_component_match_release (24 bytes) [ 126.886045] snd_hda_intel 0000:00:1f.3: DEVRES ADD 00000000865cdb29 grp< (0 bytes) [ 126.886049] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 grp< (0 bytes) audio driver completes its PCI probe() [ 126.892238] snd_hda_intel 0000:00:1f.3: DEVRES ADD 000000001b480725 pcim_iomap_release (48 bytes) component_del() called() at DRM/i915 unbind() [ 137.579422] i915 0000:00:02.0: DEVRES REL 00000000ef44c293 grp< (0 bytes) [ 137.579445] snd_hda_intel 0000:00:1f.3: DEVRES REL 00000000865cdb29 grp< (0 bytes) [ 137.579458] snd_hda_intel 0000:00:1f.3: DEVRES REL 000000001b480725 pcim_iomap_release (48 bytes) So the "devres_release_group(master->parent, NULL)" ends up freeing the pcim_iomap allocation. Upon next runtime resume, the audio driver will cause a page fault as the iomap alloc was released without the driver knowing about it. Fix this issue by using the "struct master" pointer as identifier for the devres group, and by closing the devres group after the master->ops->bind() call is done. This allows devres allocations done by the driver acting as master to be isolated from the binding state of the aggregate driver. This modifies the logic originally introduced in commit 9e1ccb4a7700 ("drivers/base: fix devres handling for master device") Fixes: 9e1ccb4a7700 ("drivers/base: fix devres handling for master device") Cc: stable@vger.kernel.org Acked-by: Imre Deak Acked-by: Russell King (Oracle) Signed-off-by: Kai Vehmanen BugLink: https://gitlab.freedesktop.org/drm/intel/-/issues/4136 Link: https://lore.kernel.org/r/20211013161345.3755341-1-kai.vehmanen@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 10f54634341de2a3bad51beefb285d8513f19ad9 Author: Sebastian Krzyszkowiak Date: Tue Sep 14 14:18:05 2021 +0200 power: supply: max17042_battery: Clear status bits in interrupt handler commit 0cf48167b87e388fa1268c9fe6d2443ae7f43d8a upstream. The gauge requires us to clear the status bits manually for some alerts to be properly dismissed. Previously the IRQ was configured to react only on falling edge, which wasn't technically correct (the ALRT line is active low), but it had a happy side-effect of preventing interrupt storms on uncleared alerts from happening. Fixes: 7fbf6b731bca ("power: supply: max17042: Do not enforce (incorrect) interrupt trigger type") Cc: Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit ad80b75ab97f014ccd18b563291b95cd69c6e459 Author: Johan Hovold Date: Thu Oct 21 10:34:47 2021 +0200 USB: chipidea: fix interrupt deadlock commit 9aaa81c3366e8393a62374e3a1c67c69edc07b8a upstream. Chipidea core was calling the interrupt handler from non-IRQ context with interrupts enabled, something which can lead to a deadlock if there's an actual interrupt trying to take a lock that's already held (e.g. the controller lock in udc_irq()). Add a wrapper that can be used to fake interrupts instead of calling the handler directly. Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID detect") Fixes: 876d4e1e8298 ("usb: chipidea: core: add wakeup support for extcon") Cc: Peter Chen Cc: stable@vger.kernel.org # 4.4 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211021083447.20078-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b4b4c4b1499fe6fdf458db0bb8b7026bac5b94de Author: Johan Hovold Date: Mon Oct 25 13:51:59 2021 +0200 USB: iowarrior: fix control-message timeouts commit 79a4479a17b83310deb0b1a2a274fe5be12d2318 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Use the common control-message timeout define for the five-second timeout and drop the driver-specific one. Fixes: 946b960d13c1 ("USB: add driver for iowarrior devices.") Cc: stable@vger.kernel.org # 2.6.21 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211025115159.4954-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c852092e569261841a0bf7eaec0ab1db5cee805b Author: Johan Hovold Date: Mon Oct 25 13:58:11 2021 +0200 most: fix control-message timeouts commit 63b3e810eff65fb8587fcb26fa0b56802be12dcf upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Use the common control-message timeout defines for the five-second timeouts. Fixes: 97a6f772f36b ("drivers: most: add USB adapter driver") Cc: stable@vger.kernel.org # 5.9 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211025115811.5410-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2685d8b506da3dc3f28f92f4229a6442b72c668f Author: Johan Hovold Date: Fri Oct 15 13:14:20 2021 +0200 serial: 8250: fix racy uartclk update commit 211cde4f5817dc88ef7f8f2fa286e57fbf14c8ee upstream. Commit 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") added a hack to support SoCs where the UART reference clock can change behind the back of the driver but failed to add the proper locking. First, make sure to take a reference to the tty struct to avoid dereferencing a NULL pointer if the clock change races with a hangup. Second, the termios semaphore must be held during the update to prevent a racing termios change. Fixes: 868f3ee6e452 ("serial: 8250: Add 8250 port clock update method") Fixes: c8dff3aa8241 ("serial: 8250: Skip uninitialized TTY port baud rate update") Cc: stable@vger.kernel.org # 5.9 Cc: Serge Semin Tested-by: Serge Semin Reviewed-by: Serge Semin Acked-by: Andy Shevchenko Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211015111422.1027-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit bd7ac40cbfe87a7369a7275fca40cab1b7094f68 Author: Wang Hai Date: Fri Oct 15 16:55:43 2021 +0800 USB: serial: keyspan: fix memleak on probe errors commit 910c996335c37552ee30fcb837375b808bb4f33b upstream. I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888258228440 (size 64): comm "kworker/7:2", pid 2005, jiffies 4294989509 (age 824.540s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] slab_post_alloc_hook+0x9c/0x490 [] kmem_cache_alloc_trace+0x1f7/0x470 [] keyspan_port_probe+0xa4/0x5d0 [keyspan] [] usb_serial_device_probe+0x97/0x1d0 [usbserial] [] really_probe+0x167/0x460 [] __driver_probe_device+0xf9/0x180 [] driver_probe_device+0x53/0x130 [] __device_attach_driver+0x105/0x130 [] bus_for_each_drv+0x129/0x190 [] __device_attach+0x1c9/0x270 [] device_initial_probe+0x20/0x30 [] bus_probe_device+0x142/0x160 [] device_add+0x829/0x1300 [] usb_serial_probe.cold+0xc9b/0x14ac [usbserial] [] usb_probe_interface+0x1aa/0x3c0 [usbcore] [] really_probe+0x167/0x460 If keyspan_port_probe() fails to allocate memory for an out_buffer[i] or in_buffer[i], the previously allocated memory for out_buffer or in_buffer needs to be freed on the error handling path, otherwise a memory leak will result. Fixes: bad41a5bf177 ("USB: keyspan: fix port DMA-buffer allocations") Reported-by: Hulk Robot Signed-off-by: Wang Hai Link: https://lore.kernel.org/r/20211015085543.1203011-1-wanghai38@huawei.com Cc: stable@vger.kernel.org # 3.12 Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 93198e6da9eb946345fa2a7d4ee8a32e406c4cfc Author: Mihail Chindris Date: Thu Oct 7 08:00:36 2021 +0000 Documentation:devicetree:bindings:iio:dac: Fix val commit 8fc4f038fa832ec3543907fdcbe1334e1b0a8950 upstream. A correct value for output-range-microvolts is -5 to 5 Volts not -5 to 5 milivolts Fixes: e904cc899293f ("dt-bindings: iio: dac: AD5766 yaml documentation") Signed-off-by: Mihail Chindris Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20211007080035.2531-6-mihail.chindris@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 8bc3eac174aa97efa09241a6b01875f43f0427e6 Author: Nuno Sá Date: Wed Aug 18 10:05:25 2021 +0200 iio: ad5770r: make devicetree property reading consistent commit 26df977a909f818b7d346b3990735513e7e0bf93 upstream. The bindings file for this driver is defining the property as 'reg' but the driver was reading it with the 'num' name. The bindings actually had the 'num' property when added in commit ea52c21268e6 ("dt-bindings: iio: dac: Add docs for AD5770R DAC") and then changed it to 'reg' in commit 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors"). However, both these commits landed in v5.7 so the assumption is that either 'num' is not being used or if it is, the validations were not done. Anyways, if someone comes back yelling about this, we might just support both of the properties in the future. Not ideal, but that's life... Fixes: 2cf3818f18b2 ("dt-bindings: iio: dac: AD5570R fix bindings errors") Signed-off-by: Nuno Sá Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210818080525.62790-1-nuno.sa@analog.com Cc: Stable@vger.kernel.org Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a664d4a75c07a918e2b671f882ee91f480821b6d Author: Pekka Korpinen Date: Wed Sep 29 21:57:55 2021 +0300 iio: dac: ad5446: Fix ad5622_write() return value commit 558df982d4ead9cac628153d0d7b60feae05ddc8 upstream. On success i2c_master_send() returns the number of bytes written. The call from iio_write_channel_info(), however, expects the return value to be zero on success. This bug causes incorrect consumption of the sysfs buffer in iio_write_channel_info(). When writing more than two characters to out_voltage0_raw, the ad5446 write handler is called multiple times causing unexpected behavior. Fixes: 3ec36a2cf0d5 ("iio:ad5446: Add support for I2C based DACs") Signed-off-by: Pekka Korpinen Link: https://lore.kernel.org/r/20210929185755.2384-1-pekka.korpinen@iki.fi Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit e99fa2a9f9d72fe88352a9c59fcf6360dad08c6f Author: Mihail Chindris Date: Thu Oct 7 08:00:34 2021 +0000 drivers: iio: dac: ad5766: Fix dt property name commit d9de0fbdeb0103a204055efb69cb5cc8f5f12a6a upstream. In the documentation the name for the property is output-range-microvolts which is a standard name, therefore this name must be used. Fixes: fd9373e41b9ba ("iio: dac: ad5766: add driver support for AD5766") Signed-off-by: Mihail Chindris Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20211007080035.2531-5-mihail.chindris@analog.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit a9501b2bfc91cb1131df17bed313db307c9917be Author: Yang Yingliang Date: Wed Oct 13 22:42:42 2021 +0800 iio: buffer: Fix memory leak in iio_buffer_register_legacy_sysfs_groups() commit 604faf9a2ecd1addcc0c10a47e5aaef3c4d4fd6b upstream. If the second iio_device_register_sysfs_group() fails, 'legacy_buffer_group.attrs' need be freed too or it will cause memory leak: unreferenced object 0xffff888003618280 (size 64): comm "xrun", pid 357, jiffies 4294907259 (age 22.296s) hex dump (first 32 bytes): 80 f6 8c 03 80 88 ff ff 80 fb 8c 03 80 88 ff ff ................ 00 f9 8c 03 80 88 ff ff 80 fc 8c 03 80 88 ff ff ................ backtrace: [<00000000076bfd43>] __kmalloc+0x1a3/0x2f0 [<00000000c32e4886>] iio_buffers_alloc_sysfs_and_mask+0xc31/0x1290 [industrialio] Reported-by: Hulk Robot Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211013144242.1685060-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 46bb49301f46460010706ead4f7137403147e8b4 Author: Yang Yingliang Date: Wed Oct 13 17:43:43 2021 +0800 iio: buffer: Fix memory leak in __iio_buffer_alloc_sysfs_and_mask() commit 9a2ff8009e53296e47de72d5af0bc31cd53274ff upstream. When iio_buffer_wrap_attr() returns NULL or buffer->buffer_group.name alloc fails, the 'attr' which is allocated in __iio_buffer_alloc_sysfs_and_mask() is not freed, and cause memory leak. unreferenced object 0xffff888014882a00 (size 64): comm "i2c-adjd_s311-8", pid 424, jiffies 4294907737 (age 44.396s) hex dump (first 32 bytes): 00 0f 8a 15 80 88 ff ff 00 0e 8a 15 80 88 ff ff ................ 80 04 8a 15 80 88 ff ff 80 05 8a 15 80 88 ff ff ................ backtrace: [<0000000021752e67>] __kmalloc+0x1af/0x3c0 [<0000000043e8305c>] iio_buffers_alloc_sysfs_and_mask+0xe73/0x1570 [industrialio] [<00000000b7aa5a17>] __iio_device_register+0x483/0x1a30 [industrialio] [<000000003fa0fb2f>] __devm_iio_device_register+0x23/0x90 [industrialio] [<000000003ab040cf>] adjd_s311_probe+0x19c/0x200 [adjd_s311] [<0000000080458969>] i2c_device_probe+0xa31/0xbe0 [<00000000e20678ad>] really_probe+0x299/0xc30 [<000000006bea9b27>] __driver_probe_device+0x357/0x500 [<00000000e1df10d4>] driver_probe_device+0x4e/0x140 [<0000000003661beb>] __device_attach_driver+0x257/0x340 [<000000005bb4aa26>] bus_for_each_drv+0x166/0x1e0 [<00000000272c5236>] __device_attach+0x272/0x420 [<00000000d52a96ae>] bus_probe_device+0x1eb/0x2a0 [<00000000129f7737>] device_add+0xbf0/0x1f90 [<000000005eed4e52>] i2c_new_client_device+0x622/0xb20 [<00000000b85a9c43>] new_device_store+0x1fa/0x420 This patch fix to free it before the error return. Reported-by: Hulk Robot Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211013094343.315275-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 3827d12e1a804d3da68b0a8d443b6ff2ca44b69d Author: Yang Yingliang Date: Mon Oct 18 14:37:18 2021 +0800 iio: buffer: Fix memory leak in iio_buffers_alloc_sysfs_and_mask() commit 486a25084155bf633768c26f022201c051d6fd95 upstream. When 'iio_dev_opaque->buffer_ioctl_handler' alloc fails in iio_buffers_alloc_sysfs_and_mask(), the 'attrs' allocated in iio_buffer_register_legacy_sysfs_groups() will be leaked: unreferenced object 0xffff888108568d00 (size 128): comm "88", pid 2014, jiffies 4294963294 (age 26.920s) hex dump (first 32 bytes): 80 3e da 02 80 88 ff ff 00 3a da 02 80 88 ff ff .>.......:...... 00 35 da 02 80 88 ff ff 00 38 da 02 80 88 ff ff .5.......8...... backtrace: [<0000000095a9e51e>] __kmalloc+0x1a3/0x2f0 [<00000000faa3735e>] iio_buffers_alloc_sysfs_and_mask+0xfa3/0x1480 [industrialio] [<00000000a46384dc>] __iio_device_register+0x52e/0x1b40 [industrialio] [<00000000210af05e>] __devm_iio_device_register+0x22/0x80 [industrialio] [<00000000730d7b41>] adjd_s311_probe+0x195/0x200 [adjd_s311] [<00000000c0f70eb9>] i2c_device_probe+0xa07/0xbb0 The iio_buffer_register_legacy_sysfs_groups() is called in __iio_buffer_alloc_sysfs_and_mask(), so move the iio_buffer_unregister_legacy_sysfs_groups() into __iio_buffer_free_sysfs_and_mask(), then the memory will be freed. Reported-by: Hulk Robot Fixes: d9a625744ed0 ("iio: core: merge buffer/ & scan_elements/ attributes") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211018063718.1971240-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 364ee3057abdf946195451e1aad3019cf48159b9 Author: Yang Yingliang Date: Wed Oct 13 12:04:38 2021 +0800 iio: buffer: check return value of kstrdup_const() commit 2c0ad3f0cc04dec489552a21b80cd6d708bea96d upstream. Check return value of kstrdup_const() in iio_buffer_wrap_attr(), or it will cause null-ptr-deref in kernfs_name_hash() when calling device_add() as follows: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: kernfs_name_hash+0x22/0x110 kernfs_find_ns+0x11d/0x390 kernfs_remove_by_name_ns+0x3b/0xb0 remove_files.isra.1+0x7b/0x190 internal_create_group+0x7f1/0xbb0 internal_create_groups+0xa3/0x150 device_add+0x8f0/0x2020 cdev_device_add+0xc3/0x160 __iio_device_register+0x1427/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] adjd_s311_probe+0x195/0x200 [adjd_s311] i2c_device_probe+0xa07/0xbb0 Reported-by: Hulk Robot Fixes: 15097c7a1adc ("iio: buffer: wrap all buffer attributes into iio_dev_attr") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211013040438.1689277-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit fdd9d3e268cffab9313aba39ca04df246999530a Author: Suzuki K Poulose Date: Thu Oct 14 15:22:38 2021 +0100 coresight: trbe: Defer the probe on offline CPUs commit a08025b3fe56185290a1ea476581f03ca733f967 upstream. If a CPU is offline during the driver init, we could end up causing a kernel crash trying to register the coresight device for the TRBE instance. The trbe_cpudata for the TRBE instance is initialized only when it is probed. Otherwise, we could end up dereferencing a NULL cpudata->drvdata. e.g: [ 0.149999] coresight ete0: CPU0: ete v1.1 initialized [ 0.149999] coresight-etm4x ete_1: ETM arch init failed [ 0.149999] coresight-etm4x: probe of ete_1 failed with error -22 [ 0.150085] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 [ 0.150085] Mem abort info: [ 0.150085] ESR = 0x96000005 [ 0.150085] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.150085] SET = 0, FnV = 0 [ 0.150085] EA = 0, S1PTW = 0 [ 0.150085] Data abort info: [ 0.150085] ISV = 0, ISS = 0x00000005 [ 0.150085] CM = 0, WnR = 0 [ 0.150085] [0000000000000050] user address but active_mm is swapper [ 0.150085] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 0.150085] Modules linked in: [ 0.150085] Hardware name: FVP Base RevC (DT) [ 0.150085] pstate: 00800009 (nzcv daif -PAN +UAO -TCO BTYPE=--) [ 0.150155] pc : arm_trbe_register_coresight_cpu+0x74/0x144 [ 0.150155] lr : arm_trbe_register_coresight_cpu+0x48/0x144 ... [ 0.150237] Call trace: [ 0.150237] arm_trbe_register_coresight_cpu+0x74/0x144 [ 0.150237] arm_trbe_device_probe+0x1c0/0x2d8 [ 0.150259] platform_drv_probe+0x94/0xbc [ 0.150259] really_probe+0x1bc/0x4a8 [ 0.150266] driver_probe_device+0x7c/0xb8 [ 0.150266] device_driver_attach+0x6c/0xac [ 0.150266] __driver_attach+0xc4/0x148 [ 0.150266] bus_for_each_dev+0x7c/0xc8 [ 0.150266] driver_attach+0x24/0x30 [ 0.150266] bus_add_driver+0x100/0x1e0 [ 0.150266] driver_register+0x78/0x110 [ 0.150266] __platform_driver_register+0x44/0x50 [ 0.150266] arm_trbe_init+0x28/0x84 [ 0.150266] do_one_initcall+0x94/0x2bc [ 0.150266] do_initcall_level+0xa4/0x158 [ 0.150266] do_initcalls+0x54/0x94 [ 0.150319] do_basic_setup+0x24/0x30 [ 0.150319] kernel_init_freeable+0xe8/0x14c [ 0.150319] kernel_init+0x14/0x18c [ 0.150319] ret_from_fork+0x10/0x30 [ 0.150319] Code: f94012c8 b0004ce2 9134a442 52819801 (f9402917) [ 0.150319] ---[ end trace d23e0cfe5098535e ]--- [ 0.150346] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b Fix this by skipping the step, if we are unable to probe the CPU. Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Reported-by: Bransilav Rankov Cc: Anshuman Khandual Cc: Mathieu Poirier Cc: Mike Leach Cc: Leo Yan Cc: stable Tested-by: Branislav Rankov Signed-off-by: Suzuki K Poulose Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20211014142238.2221248-1-suzuki.poulose@arm.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit ddffd384d44c531192d1a9c9a1813597a0f555fb Author: Suzuki K Poulose Date: Tue Sep 21 14:41:05 2021 +0100 coresight: trbe: Fix incorrect access of the sink specific data commit bb5293e334af51b19b62d8bef1852ea13e935e9b upstream. The TRBE driver wrongly treats the aux private data as the TRBE driver specific buffer for a given perf handle, while it is the ETM PMU's event specific data. Fix this by correcting the instance to use appropriate helper. Cc: stable Fixes: 3fbf7f011f24 ("coresight: sink: Add TRBE driver") Signed-off-by: Suzuki K Poulose Reviewed-by: Anshuman Khandual Link: https://lore.kernel.org/r/20210921134121.2423546-2-suzuki.poulose@arm.com [Fixed 13 character SHA down to 12] Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 13de015c782df21e8cf8b2b87cc612bc3a103909 Author: Tao Zhang Date: Thu Aug 19 17:29:37 2021 +0800 coresight: cti: Correct the parameter for pm_runtime_put commit 692c9a499b286ea478f41b23a91fe3873b9e1326 upstream. The input parameter of the function pm_runtime_put should be the same in the function cti_enable_hw and cti_disable_hw. The correct parameter to use here should be dev->parent. Signed-off-by: Tao Zhang Reviewed-by: Leo Yan Fixes: 835d722ba10a ("coresight: cti: Initial CoreSight CTI Driver") Cc: stable Link: https://lore.kernel.org/r/1629365377-5937-1-git-send-email-quic_taozha@quicinc.com Signed-off-by: Mathieu Poirier Signed-off-by: Greg Kroah-Hartman commit 7a0a1d45b31853096c387067bfe3402c398747b4 Author: Yang Yingliang Date: Fri Oct 22 09:43:23 2021 +0800 pinctrl: core: fix possible memory leak in pinctrl_enable() commit c7892ae13e461ed20154321eb792e07ebe38f5b3 upstream. I got memory leak as follows when doing fault injection test: unreferenced object 0xffff888020a7a680 (size 64): comm "i2c-mcp23018-41", pid 23090, jiffies 4295160544 (age 8.680s) hex dump (first 32 bytes): 00 48 d3 1e 80 88 ff ff 00 1a 56 c1 ff ff ff ff .H........V..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000083c79b35>] kmem_cache_alloc_trace+0x16d/0x360 [<0000000051803c95>] pinctrl_init_controller+0x6ed/0xb70 [<0000000064346707>] pinctrl_register+0x27/0x80 [<0000000029b0e186>] devm_pinctrl_register+0x5b/0xe0 [<00000000391f5a3e>] mcp23s08_probe_one+0x968/0x118a [pinctrl_mcp23s08] [<000000006112c039>] mcp230xx_probe+0x266/0x560 [pinctrl_mcp23s08_i2c] If pinctrl_claim_hogs() fails, the 'pindesc' allocated in pinctrl_register_one_pin() need be freed. Cc: stable@vger.kernel.org Reported-by: Hulk Robot Fixes: 950b0d91dc10 ("pinctrl: core: Fix regression caused by delayed work for hogs") Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211022014323.1156924-1-yangyingliang@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 217ece6c45a8a1e0c5910024bb1f02da84484a16 Author: Paulo Alcantara Date: Thu Nov 4 13:13:28 2021 -0300 cifs: set a minimum of 120s for next dns resolution commit 4ac0536f8874a903a72bddc57eb88db774261e3a upstream. With commit 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution") and after triggering the first reconnect, the next async dns resolution of tcp server's hostname would be scheduled based on dns_resolver's key expiry default, which happens to default to 5s on most systems that use key.dns_resolver for upcall. As per key.dns_resolver.conf(5): default_ttl= The number of seconds to set as the expiration on a cached record. This will be overridden if the program manages to re- trieve TTL information along with the addresses (if, for exam- ple, it accesses the DNS directly). The default is 5 seconds. The value must be in the range 1 to INT_MAX. Make the next async dns resolution no shorter than 120s as we do not want to be upcalling too often. Cc: stable@vger.kernel.org Fixes: 506c1da44fee ("cifs: use the expiry output of dns_query to schedule next resolution") Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 49f933bb3016269dc50074eac5f6033d127644f1 Author: Shyam Prasad N Date: Thu Oct 14 11:52:39 2021 +0000 cifs: To match file servers, make sure the server hostname matches commit 7be3248f313930ff3d3436d4e9ddbe9fccc1f541 upstream. We generally rely on a bunch of factors to differentiate between servers. For example, IP address, port etc. For certain server types (like Azure), it is important to make sure that the server hostname matches too, even if the both hostnames currently resolve to the same IP address. Signed-off-by: Shyam Prasad N Cc: stable@vger.kernel.org Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 5d0714e7d9792487345bccd4eae03fba503c016e Author: Zhang Yi Date: Fri Oct 8 17:38:21 2021 +0800 quota: correct error number in free_dqentry() commit d0e36a62bd4c60c09acc40e06ba4831a4d0bc75b upstream. Fix the error path in free_dqentry(), pass out the error number if the block to free is not correct. Fixes: 1ccd14b9c271 ("quota: Split off quota tree handling into a separate file") Link: https://lore.kernel.org/r/20211008093821.1001186-3-yi.zhang@huawei.com Signed-off-by: Zhang Yi Cc: stable@kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit b2d7d18457990ad15ee9f9f40da538fa58dae6b5 Author: Zhang Yi Date: Fri Oct 8 17:38:20 2021 +0800 quota: check block number when reading the block in quota file commit 9bf3d20331295b1ecb81f4ed9ef358c51699a050 upstream. The block number in the quota tree on disk should be smaller than the v2_disk_dqinfo.dqi_blocks. If the quota file was corrupted, we may be allocating an 'allocated' block and that would lead to a loop in a tree, which will probably trigger oops later. This patch adds a check for the block number in the quota tree to prevent such potential issue. Link: https://lore.kernel.org/r/20211008093821.1001186-2-yi.zhang@huawei.com Signed-off-by: Zhang Yi Cc: stable@kernel.org Signed-off-by: Jan Kara Signed-off-by: Greg Kroah-Hartman commit 2830878daf165fea9f5918eac70c62a79bd74a91 Author: Pali Rohár Date: Thu Oct 28 20:56:59 2021 +0200 PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge commit 239edf686c14a9ff926dec2f350289ed7adfefe2 upstream. This register is exported at address offset 0x30. Link: https://lore.kernel.org/r/20211028185659.20329-8-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a298da0df0438e11604d034f86b6c6a509e6aeb4 Author: Pali Rohár Date: Thu Oct 28 20:56:57 2021 +0200 PCI: aardvark: Set PCI Bridge Class Code to PCI Bridge commit 84e1b4045dc887b78bdc87d92927093dc3a465aa upstream. Aardvark controller has something like config space of a Root Port available at offset 0x0 of internal registers - these registers are used for implementation of the emulated bridge. The default value of Class Code of this bridge corresponds to a RAID Mass storage controller, though. (This is probably intended for when the controller is used as Endpoint.) Change the Class Code to correspond to a PCI Bridge. Add comment explaining this change. Link: https://lore.kernel.org/r/20211028185659.20329-6-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 17099eb5978bb49acd1812943b5f51d14d62eb8f Author: Pali Rohár Date: Thu Oct 28 20:56:58 2021 +0200 PCI: aardvark: Fix support for PCI_BRIDGE_CTL_BUS_RESET on emulated bridge commit bc4fac42e5f8460af09c0a7f2f1915be09e20c71 upstream. Aardvark supports PCIe Hot Reset via PCIE_CORE_CTRL1_REG. Use it for implementing PCI_BRIDGE_CTL_BUS_RESET bit of PCI_BRIDGE_CONTROL register on emulated bridge. With this, the function pci_reset_secondary_bus() starts working and can reset connected PCIe card. Custom userspace script [1] which uses setpci can trigger PCIe Hot Reset and reset the card manually. [1] https://alexforencich.com/wiki/en/pcie/hot-reset-linux Link: https://lore.kernel.org/r/20211028185659.20329-7-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 137f450a17a0f0e5d34de6c2515494f1e9291fa3 Author: Pali Rohár Date: Thu Oct 28 20:56:56 2021 +0200 PCI: aardvark: Fix support for bus mastering and PCI_COMMAND on emulated bridge commit 771153fc884f566a89af2d30033b7f3bc6e24e84 upstream. From very vague, ambiguous and incomplete information from Marvell we deduced that the 32-bit Aardvark register at address 0x4 (PCIE_CORE_CMD_STATUS_REG), which is not documented for Root Complex mode in the Functional Specification (only for Endpoint mode), controls two 16-bit PCIe registers: Command Register and Status Registers of PCIe Root Port. This means that bit 2 controls bus mastering and forwarding of memory and I/O requests in the upstream direction. According to PCI specifications bits [0:2] of Command Register, this should be by default disabled on reset. So explicitly disable these bits at early setup of the Aardvark driver. Remove code which unconditionally enables all 3 bits and let kernel code (via pci_set_master() function) to handle bus mastering of Root PCIe Bridge via emulated PCI_COMMAND on emulated bridge. Link: https://lore.kernel.org/r/20211028185659.20329-5-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org # b2a56469d550 ("PCI: aardvark: Add FIXME comment for PCIE_CORE_CMD_STATUS_REG access") Signed-off-by: Greg Kroah-Hartman commit dba8de2c8771f0e96349c379c84eb429f8fdaaec Author: Marek Behún Date: Thu Oct 28 20:56:55 2021 +0200 PCI: aardvark: Read all 16-bits from PCIE_MSI_PAYLOAD_REG commit 95997723b6402cd6c53e0f9e7ac640ec64eaaff8 upstream. The PCIE_MSI_PAYLOAD_REG contains 16-bit MSI number, not only lower 8 bits. Fix reading content of this register and add a comment describing the access to this register. Link: https://lore.kernel.org/r/20211028185659.20329-4-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 937f91f8f621e3608933799935b7e543bd43c8b0 Author: Marek Behún Date: Thu Oct 28 20:56:54 2021 +0200 PCI: aardvark: Fix return value of MSI domain .alloc() method commit e4313be1599d397625c14fb7826996813622decf upstream. MSI domain callback .alloc() (implemented by advk_msi_irq_domain_alloc() function) should return zero on success, since non-zero value indicates failure. When the driver was converted to generic MSI API in commit f21a8b1b6837 ("PCI: aardvark: Move to MSI handling using generic MSI support"), it was converted so that it returns hwirq number. Fix this. Link: https://lore.kernel.org/r/20211028185659.20329-3-kabel@kernel.org Fixes: f21a8b1b6837 ("PCI: aardvark: Move to MSI handling using generic MSI support") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit b775cd868cf37f6a8501ec62b88794f9824018b6 Author: Pali Rohár Date: Tue Oct 5 20:09:44 2021 +0200 PCI: aardvark: Fix configuring Reference clock commit 46ef6090dbf590711cb12680b6eafde5fa21fe87 upstream. Commit 366697018c9a ("PCI: aardvark: Add PHY support") introduced configuration of PCIe Reference clock via PCIE_CORE_REF_CLK_REG register, but did it incorrectly. PCIe Reference clock differential pair is routed from system board to endpoint card, so on CPU side it has output direction. Therefore it is required to enable transmitting and disable receiving. Default configuration according to Armada 3700 Functional Specifications is enabled receiver part and disabled transmitter. We need this change because otherwise PCIe Reference clock is configured to some undefined state when differential pair is used for both transmitting and receiving. Fix this by disabling receiver part. Link: https://lore.kernel.org/r/20211005180952.6812-6-kabel@kernel.org Fixes: 366697018c9a ("PCI: aardvark: Add PHY support") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 7083088eb99f47612169c36b0566aeb715812fa9 Author: Pali Rohár Date: Tue Oct 5 20:09:52 2021 +0200 PCI: aardvark: Fix reporting Data Link Layer Link Active commit 2b650b7ff20eb7ea8ef9031d20fb657286ab90cc upstream. Add support for reporting PCI_EXP_LNKSTA_DLLLA bit in Link Control register on emulated bridge via current LTSSM state. Also correctly indicate DLLLA capability via PCI_EXP_LNKCAP_DLLLARC bit in Link Control Capability register. Link: https://lore.kernel.org/r/20211005180952.6812-14-kabel@kernel.org Fixes: 8a3ebd8de328 ("PCI: aardvark: Implement emulated root PCI bridge config space") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 8b74250f05fbcdda622f116a7d1dda3d69a272fc Author: Pali Rohár Date: Tue Oct 5 20:09:46 2021 +0200 PCI: aardvark: Do not unmask unused interrupts commit 1fb95d7d3c7a926b002fe8a6bd27a1cb428b46dc upstream. There are lot of undocumented interrupt bits. To prevent unwanted spurious interrupts, fix all *_ALL_MASK macros to define all interrupt bits, so that driver can properly mask all interrupts, including those which are undocumented. Link: https://lore.kernel.org/r/20211005180952.6812-8-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ca41077ee0828873498ae450e83f0594b41da81f Author: Pali Rohár Date: Tue Oct 5 20:09:51 2021 +0200 PCI: aardvark: Fix checking for link up via LTSSM state commit 661c399a651c11aaf83c45cbfe0b4a1fb7bc3179 upstream. Current implementation of advk_pcie_link_up() is wrong as it marks also link disabled or hot reset states as link up. Fix it by marking link up only to those states which are defined in PCIe Base specification 3.0, Table 4-14: Link Status Mapped to the LTSSM. To simplify implementation, Define macros for every LTSSM state which aardvark hardware can return in CFG_REG register. Fix also checking for link training according to the same Table 4-14. Define a new function advk_pcie_link_training() for this purpose. Link: https://lore.kernel.org/r/20211005180952.6812-13-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Cc: Remi Pommarel Signed-off-by: Greg Kroah-Hartman commit b05c2e6638df1371c3a3f5194fa9cf768388e50b Author: Pali Rohár Date: Tue Oct 5 20:09:45 2021 +0200 PCI: aardvark: Do not clear status bits of masked interrupts commit a7ca6d7fa3c02c032db5440ff392d96c04684c21 upstream. The PCIE_ISR1_REG says which interrupts are currently set / active, including those which are masked. The driver currently reads this register and looks if some unmasked interrupts are active, and if not, it clears status bits of _all_ interrupts, including the masked ones. This is incorrect, since, for example, some drivers may poll these bits. Remove this clearing, and also remove this early return statement completely, since it does not change functionality in any way. Link: https://lore.kernel.org/r/20211005180952.6812-7-kabel@kernel.org Fixes: 8c39d710363c ("PCI: aardvark: Add Aardvark PCI host controller driver") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Behún Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1110d1921cd36bad9ca1cb7173f0288a6d26dcf2 Author: Dan Williams Date: Fri Oct 15 14:29:58 2021 -0700 cxl/pci: Fix NULL vs ERR_PTR confusion commit ca76a3a8052b71c0334d5c094859cfa340c290a8 upstream. cxl_pci_map_regblock() may return an ERR_PTR(), but cxl_pci_setup_regs() is only prepared for NULL as the error case. Pick the minimal fix for -stable backport purposes and just have cxl_pci_map_regblock() return NULL for errors. Fixes: f8a7e8c29be8 ("cxl/pci: Reserve all device regions at once") Cc: Reviewed-by: Ira Weiny Reviewed-by: Jonathan Cameron Link: https://lore.kernel.org/r/163433325724.834522.17809774578178224149.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Dan Williams Signed-off-by: Greg Kroah-Hartman commit f6c83346fbe5bd92277541677ade2a72fcdab892 Author: Li Chen Date: Thu Oct 21 02:50:19 2021 +0000 PCI: cadence: Add cdns_plat_pcie_probe() missing return commit 27cd7e3c9bb1ae13bc16f08138edd6e4df3cd211 upstream. When cdns_plat_pcie_probe() succeeds, return success instead of falling into the error handling code. Fixes: bd22885aa188 ("PCI: cadence: Refactor driver to use as a core library") Link: https://lore.kernel.org/r/DM6PR19MB40271B93057D949310F0B0EDA0BF9@DM6PR19MB4027.namprd19.prod.outlook.com Signed-off-by: Xuliang Zhang Signed-off-by: Li Chen Signed-off-by: Bjorn Helgaas Reviewed-by: Bjorn Helgaas Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit a4935eef58d213a6209f06571a455b301f9beeac Author: Marek Behún Date: Thu Oct 28 20:56:53 2021 +0200 PCI: pci-bridge-emul: Fix emulation of W1C bits commit 7a41ae80bdcb17e14dd7d83239b8a0cf368f18be upstream. The pci_bridge_emul_conf_write() function correctly clears W1C bits in cfgspace cache, but it does not inform the underlying implementation about the clear request: the .write_op() method is given the value with these bits cleared. This is wrong if the .write_op() needs to know which bits were requested to be cleared. Fix the value to be passed into the .write_op() method to have requested W1C bits set, so that it can clear them. Both pci-bridge-emul users (mvebu and aardvark) are compatible with this change. Link: https://lore.kernel.org/r/20211028185659.20329-2-kabel@kernel.org Fixes: 23a5fba4d941 ("PCI: Introduce PCI bridge emulated config space common logic") Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Cc: stable@vger.kernel.org Cc: Russell King Signed-off-by: Greg Kroah-Hartman commit 500a1bac743cf7505726ee491efb89772677fc72 Author: yangerkun Date: Thu Sep 30 11:22:28 2021 +0800 ovl: fix use after free in struct ovl_aio_req commit 9a254403760041528bc8f69fe2f5e1ef86950991 upstream. Example for triggering use after free in a overlay on ext4 setup: aio_read ovl_read_iter vfs_iter_read ext4_file_read_iter ext4_dio_read_iter iomap_dio_rw -> -EIOCBQUEUED /* * Here IO is completed in a separate thread, * ovl_aio_cleanup_handler() frees aio_req which has iocb embedded */ file_accessed(iocb->ki_filp); /**BOOM**/ Fix by introducing a refcount in ovl_aio_req similarly to aio_kiocb. This guarantees that iocb is only freed after vfs_read/write_iter() returns on underlying fs. Fixes: 2406a307ac7d ("ovl: implement async IO routines") Signed-off-by: yangerkun Link: https://lore.kernel.org/r/20210930032228.3199690-3-yangerkun@huawei.com/ Cc: # v5.6 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 88e9929b632eed6755642ecfcbc78d1e4896cf5d Author: Juergen Gross Date: Tue Nov 2 10:19:44 2021 +0100 xen/balloon: add late_initcall_sync() for initial ballooning done commit 40fdea0284bb20814399da0484a658a96c735d90 upstream. When running as PVH or HVM guest with actual memory < max memory the hypervisor is using "populate on demand" in order to allow the guest to balloon down from its maximum memory size. For this to work correctly the guest must not touch more memory pages than its target memory size as otherwise the PoD cache will be exhausted and the guest is crashed as a result of that. In extreme cases ballooning down might not be finished today before the init process is started, which can consume lots of memory. In order to avoid random boot crashes in such cases, add a late init call to wait for ballooning down having finished for PVH/HVM guests. Warn on console if initial ballooning fails, panic() after stalling for more than 3 minutes per default. Add a module parameter for changing this timeout. [boris: replaced pr_info() with pr_notice()] Cc: Reported-by: Marek Marczykowski-Górecki Signed-off-by: Juergen Gross Link: https://lore.kernel.org/r/20211102091944.17487-1-jgross@suse.com Reviewed-by: Boris Ostrovsky Signed-off-by: Boris Ostrovsky Signed-off-by: Greg Kroah-Hartman commit 7373f03ae79c5be00940990b45b9badd9d83dd85 Author: Arnd Bergmann Date: Fri Oct 29 13:30:51 2021 +0200 ifb: fix building without CONFIG_NET_CLS_ACT commit 7444d706be31753f65052c7f6325fc8470cc1789 upstream. The driver no longer depends on this option, but it fails to build if it's disabled because the skb->tc_skip_classify is hidden behind an #ifdef: drivers/net/ifb.c:81:8: error: no member named 'tc_skip_classify' in 'struct sk_buff' skb->tc_skip_classify = 1; Use the same #ifdef around the assignment. Fixes: 046178e726c2 ("ifb: Depend on netfilter alternatively to tc") Signed-off-by: Arnd Bergmann Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0d546e9fc83b6edccc73439cc00bafcf09ce8e8a Author: Pali Rohár Date: Sat Oct 2 15:09:00 2021 +0200 serial: core: Fix initializing and restoring termios speed commit 027b57170bf8bb6999a28e4a5f3d78bf1db0f90c upstream. Since commit edc6afc54968 ("tty: switch to ktermios and new framework") termios speed is no longer stored only in c_cflag member but also in new additional c_ispeed and c_ospeed members. If BOTHER flag is set in c_cflag then termios speed is stored only in these new members. Therefore to correctly restore termios speed it is required to store also ispeed and ospeed members, not only cflag member. In case only cflag member with BOTHER flag is restored then functions tty_termios_baud_rate() and tty_termios_input_baud_rate() returns baudrate stored in c_ospeed / c_ispeed member, which is zero as it was not restored too. If reported baudrate is invalid (e.g. zero) then serial core functions report fallback baudrate value 9600. So it means that in this case original baudrate is lost and kernel changes it to value 9600. Simple reproducer of this issue is to boot kernel with following command line argument: "console=ttyXXX,86400" (where ttyXXX is the device name). For speed 86400 there is no Bnnn constant and therefore kernel has to represent this speed via BOTHER c_cflag. Which means that speed is stored only in c_ospeed and c_ispeed members, not in c_cflag anymore. If bootloader correctly configures serial device to speed 86400 then kernel prints boot log to early console at speed speed 86400 without any issue. But after kernel starts initializing real console device ttyXXX then speed is changed to fallback value 9600 because information about speed was lost. This patch fixes above issue by storing and restoring also ispeed and ospeed members, which are required for BOTHER flag. Fixes: edc6afc54968 ("[PATCH] tty: switch to ktermios and new framework") Cc: stable@vger.kernel.org Signed-off-by: Pali Rohár Link: https://lore.kernel.org/r/20211002130900.9518-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2348cadfddfdfc655011cbcd70d41019340a601f Author: Steven Rostedt (VMware) Date: Mon Nov 8 10:58:10 2021 -0500 ring-buffer: Protect ring_buffer_reset() from reentrancy commit 51d157946666382e779f94c39891e8e9a020da78 upstream. The resetting of the entire ring buffer use to simply go through and reset each individual CPU buffer that had its own protection and synchronization. But this was very slow, due to performing a synchronization for each CPU. The code was reshuffled to do one disabling of all CPU buffers, followed by a single RCU synchronization, and then the resetting of each of the CPU buffers. But unfortunately, the mutex that prevented multiple occurrences of resetting the buffer was not moved to the upper function, and there is nothing to protect from it. Take the ring buffer mutex around the global reset. Cc: stable@vger.kernel.org Fixes: b23d7a5f4a07a ("ring-buffer: speed up buffer resets by avoiding synchronize_rcu for each CPU") Reported-by: "Tzvetomir Stoyanov (VMware)" Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 6f67cf08fef0c1b7041f995320dc1d2134db6f03 Author: Xiaoming Ni Date: Wed Sep 29 11:36:45 2021 +0800 powerpc/85xx: Fix oops when mpc85xx_smp_guts_ids node cannot be found commit 3c2172c1c47b4079c29f0e6637d764a99355ebcd upstream. When the field described in mpc85xx_smp_guts_ids[] is not configured in dtb, the mpc85xx_setup_pmc() does not assign a value to the "guts" variable. As a result, the oops is triggered when mpc85xx_freeze_time_base() is executed. Fixes: 56f1ba280719 ("powerpc/mpc85xx: refactor the PM operations") Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Xiaoming Ni Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210929033646.39630-2-nixiaoming@huawei.com Signed-off-by: Greg Kroah-Hartman commit 9028e051345bfb5cfabdcb047d5d19a0cb7bda32 Author: Oleksij Rempel Date: Thu Oct 7 11:30:06 2021 +0200 iio: adc: tsc2046: fix scan interval warning commit 69b31fd7a61784692db6433c05d46915b1b1a680 upstream. Sync if statement with the actual warning. Fixes: 9504db5765e8 ("iio: adc: tsc2046: fix a warning message in tsc2046_adc_update_scan_mode()") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20211007093007.1466-2-o.rempel@pengutronix.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 299623b1b0883c5894af608866172ec27befb90b Author: Zhang Changzhong Date: Thu Oct 28 22:38:26 2021 +0800 can: j1939: j1939_can_recv(): ignore messages with invalid source address commit a79305e156db3d24fcd8eb649cdb3c3b2350e5c2 upstream. According to SAE-J1939-82 2015 (A.3.6 Row 2), a receiver should never send TP.CM_CTS to the global address, so we can add a check in j1939_can_recv() to drop messages with invalid source address. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/all/1635431907-15617-3-git-send-email-zhangchangzhong@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Zhang Changzhong Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a6591eb3c58bfade31012703211ce104972bd45e Author: Zhang Changzhong Date: Thu Oct 28 22:38:25 2021 +0800 can: j1939: j1939_tp_cmd_recv(): ignore abort message in the BAM transport commit c0f49d98006f2db3333b917caac65bce2af9865c upstream. This patch prevents BAM transport from being closed by receiving abort message, as specified in SAE-J1939-82 2015 (A.3.3 Row 4). Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Link: https://lore.kernel.org/all/1635431907-15617-2-git-send-email-zhangchangzhong@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Zhang Changzhong Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 22237bb988c16e88d53907fe6aab2a80ef89000a Author: Sean Christopherson Date: Tue Nov 9 01:30:45 2021 +0000 KVM: nVMX: Handle dynamic MSR intercept toggling commit 67f4b9969c305be515e47f809ecacfd86bd20a9c upstream. Always check vmcs01's MSR bitmap when merging L0 and L1 bitmaps for L2, and always update the relevant bits in vmcs02. This fixes two distinct, but intertwined bugs related to dynamic MSR bitmap modifications. The first issue is that KVM fails to enable MSR interception in vmcs02 for the FS/GS base MSRs if L1 first runs L2 with interception disabled, and later enables interception. The second issue is that KVM fails to honor userspace MSR filtering when preparing vmcs02. Fix both issues simultaneous as fixing only one of the issues (doesn't matter which) would create a mess that no one should have to bisect. Fixing only the first bug would exacerbate the MSR filtering issue as userspace would see inconsistent behavior depending on the whims of L1. Fixing only the second bug (MSR filtering) effectively requires fixing the first, as the nVMX code only knows how to transition vmcs02's bitmap from 1->0. Move the various accessor/mutators that are currently buried in vmx.c into vmx.h so that they can be shared by the nested code. Fixes: 1a155254ff93 ("KVM: x86: Introduce MSR filtering") Fixes: d69129b4e46a ("KVM: nVMX: Disable intercept for FS/GS base MSRs in vmcs02 when possible") Cc: stable@vger.kernel.org Cc: Alexander Graf Signed-off-by: Sean Christopherson Message-Id: <20211109013047.2041518-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 8a5180ecdcb66ba43a8028516c83da41792508a3 Author: Sean Christopherson Date: Tue Nov 9 01:30:44 2021 +0000 KVM: nVMX: Query current VMCS when determining if MSR bitmaps are in use commit 7dfbc624eb5726367900c8d86deff50836240361 upstream. Check the current VMCS controls to determine if an MSR write will be intercepted due to MSR bitmaps being disabled. In the nested VMX case, KVM will disable MSR bitmaps in vmcs02 if they're disabled in vmcs12 or if KVM can't map L1's bitmaps for whatever reason. Note, the bad behavior is relatively benign in the current code base as KVM sets all bits in vmcs02's MSR bitmap by default, clears bits if and only if L0 KVM also disables interception of an MSR, and only uses the buggy helper for MSR_IA32_SPEC_CTRL. Because KVM explicitly tests WRMSR before disabling interception of MSR_IA32_SPEC_CTRL, the flawed check will only result in KVM reading MSR_IA32_SPEC_CTRL from hardware when it isn't strictly necessary. Tag the fix for stable in case a future fix wants to use msr_write_intercepted(), in which case a buggy implementation in older kernels could prove subtly problematic. Fixes: d28b387fb74d ("KVM/VMX: Allow direct access to MSR_IA32_SPEC_CTRL") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20211109013047.2041518-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit ab71116b1f07891ab7a20e5ed16a7e0342160e53 Author: Sean Christopherson Date: Fri Nov 5 09:51:00 2021 +0000 KVM: x86: Add helper to consolidate core logic of SET_CPUID{2} flows commit 8b44b174f6aca815fc84c2038e4523ef8e32fabb upstream. Move the core logic of SET_CPUID and SET_CPUID2 to a common helper, the only difference between the two ioctls() is the format of the userspace struct. A future fix will add yet more code to the core logic. No functional change intended. Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20211105095101.5384-2-pdurrant@amazon.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit da10e2d30634697078f82360586ff719fd4db64b Author: David Woodhouse Date: Tue Nov 2 17:36:39 2021 +0000 KVM: x86: Fix recording of guest steal time / preempted status commit 7e2175ebd695f17860c5bd4ad7616cce12ed4591 upstream. In commit b043138246a4 ("x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is not missed") we switched to using a gfn_to_pfn_cache for accessing the guest steal time structure in order to allow for an atomic xchg of the preempted field. This has a couple of problems. Firstly, kvm_map_gfn() doesn't work at all for IOMEM pages when the atomic flag is set, which it is in kvm_steal_time_set_preempted(). So a guest vCPU using an IOMEM page for its steal time would never have its preempted field set. Secondly, the gfn_to_pfn_cache is not invalidated in all cases where it should have been. There are two stages to the GFN->PFN conversion; first the GFN is converted to a userspace HVA, and then that HVA is looked up in the process page tables to find the underlying host PFN. Correct invalidation of the latter would require being hooked up to the MMU notifiers, but that doesn't happen---so it just keeps mapping and unmapping the *wrong* PFN after the userspace page tables change. In the !IOMEM case at least the stale page *is* pinned all the time it's cached, so it won't be freed and reused by anyone else while still receiving the steal time updates. The map/unmap dance only takes care of the KVM administrivia such as marking the page dirty. Until the gfn_to_pfn cache handles the remapping automatically by integrating with the MMU notifiers, we might as well not get a kernel mapping of it, and use the perfectly serviceable userspace HVA that we already have. We just need to implement the atomic xchg on the userspace address with appropriate exception handling, which is fairly trivial. Cc: stable@vger.kernel.org Fixes: b043138246a4 ("x86/KVM: Make sure KVM_VCPU_FLUSH_TLB flag is not missed") Signed-off-by: David Woodhouse Message-Id: <3645b9b889dac6438394194bb5586a46b68d581f.camel@infradead.org> [I didn't entirely agree with David's assessment of the usefulness of the gfn_to_pfn cache, and integrated the outcome of the discussion in the above commit message. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit b83f9cdc80667f45bbf28b888b2688c729b9f850 Author: Mark Rutland Date: Wed Nov 3 11:05:45 2021 +0000 KVM: arm64: Extract ESR_ELx.EC only commit 8bb084119f1acc2ec55ea085a97231e3ddb30782 upstream. Since ARMv8.0 the upper 32 bits of ESR_ELx have been RES0, and recently some of the upper bits gained a meaning and can be non-zero. For example, when FEAT_LS64 is implemented, ESR_ELx[36:32] contain ISS2, which for an ST64BV or ST64BV0 can be non-zero. This can be seen in ARM DDI 0487G.b, page D13-3145, section D13.2.37. Generally, we must not rely on RES0 bit remaining zero in future, and when extracting ESR_ELx.EC we must mask out all other bits. All C code uses the ESR_ELx_EC() macro, which masks out the irrelevant bits, and therefore no alterations are required to C code to avoid consuming irrelevant bits. In a couple of places the KVM assembly extracts ESR_ELx.EC using LSR on an X register, and so could in theory consume previously RES0 bits. In both cases this is for comparison with EC values ESR_ELx_EC_HVC32 and ESR_ELx_EC_HVC64, for which the upper bits of ESR_ELx must currently be zero, but this could change in future. This patch adjusts the KVM vectors to use UBFX rather than LSR to extract ESR_ELx.EC, ensuring these are robust to future additions to ESR_ELx. Cc: stable@vger.kernel.org Signed-off-by: Mark Rutland Cc: Alexandru Elisei Cc: Catalin Marinas Cc: James Morse Cc: Marc Zyngier Cc: Suzuki K Poulose Cc: Will Deacon Acked-by: Will Deacon Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211103110545.4613-1-mark.rutland@arm.com Signed-off-by: Greg Kroah-Hartman commit b594bf02dc6f9e763b49c7aaf11fd76f5f943646 Author: Yang Yingliang Date: Tue Oct 12 14:36:24 2021 +0800 iio: core: check return value when calling dev_set_name() commit fe6f45f6ba22d625a8500cbad0237c60dd3117ee upstream. I got a null-ptr-deref report when doing fault injection test: BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:strlen+0x0/0x20 Call Trace: start_creating+0x199/0x2f0 debugfs_create_dir+0x25/0x430 __iio_device_register+0x4da/0x1b40 [industrialio] __devm_iio_device_register+0x22/0x80 [industrialio] max1027_probe+0x639/0x860 [max1027] spi_probe+0x183/0x210 really_probe+0x285/0xc30 If dev_set_name() fails, the dev_name() is null, check the return value of dev_set_name() to avoid the null-ptr-deref. Reported-by: Hulk Robot Fixes: e553f182d55b ("staging: iio: core: Introduce debugfs support...") Signed-off-by: Yang Yingliang Cc: Link: https://lore.kernel.org/r/20211012063624.3167460-1-yangyingliang@huawei.com Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 76289ff637ec2c522b3c346e2889581e49cf15dc Author: Yang Yingliang Date: Wed Oct 13 11:05:32 2021 +0800 iio: core: fix double free in iio_device_unregister_sysfs() commit 19833c40d0415d6fe4340b5b9c46239abbf718f6 upstream. I got the double free report: BUG: KASAN: double-free or invalid-free in kfree+0xce/0x390 iio_device_unregister_sysfs+0x108/0x13b [industrialio] iio_dev_release+0x9e/0x10e [industrialio] device_release+0xa5/0x240 If __iio_device_register() fails, iio_dev_opaque->groups will be freed in error path in iio_device_unregister_sysfs(), then iio_dev_release() will call iio_device_unregister_sysfs() again, it causes double free. Set iio_dev_opaque->groups to NULL when it's freed to fix this double free. Not this is a local work around for a more general mess around life time management that will get cleaned up and should make this handling unnecesarry. Fixes: 32f171724e5c ("iio: core: rework iio device group creation") Reported-by: Hulk Robot Reviewed-by: Alexandru Ardelean Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211013030532.956133-1-yangyingliang@huawei.com Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 7c0f37ace71593c58020ed24ff7f14c32de951ce Author: Henrik Grimler Date: Wed Sep 29 20:14:17 2021 +0200 power: supply: max17042_battery: use VFSOC for capacity when no rsns commit 223a3b82834f036a62aa831f67cbf1f1d644c6e2 upstream. On Galaxy S3 (i9300/i9305), which has the max17047 fuel gauge and no current sense resistor (rsns), the RepSOC register does not provide an accurate state of charge value. The reported value is wrong, and does not change over time. VFSOC however, which uses the voltage fuel gauge to determine the state of charge, always shows an accurate value. For devices without current sense, VFSOC is already used for the soc-alert (0x0003 is written to MiscCFG register), so with this change the source of the alert and the PROP_CAPACITY value match. Fixes: 359ab9f5b154 ("power_supply: Add MAX17042 Fuel Gauge Driver") Cc: Reviewed-by: Krzysztof Kozlowski Suggested-by: Wolfgang Wiedmeyer Signed-off-by: Henrik Grimler Reviewed-by: Hans de Goede Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit 6edf86431107d98cad5393e2450461a13d8c9283 Author: Sebastian Krzyszkowiak Date: Tue Sep 14 14:18:06 2021 +0200 power: supply: max17042_battery: Prevent int underflow in set_soc_threshold commit e660dbb68c6b3f7b9eb8b9775846a44f9798b719 upstream. max17042_set_soc_threshold gets called with offset set to 1, which means that minimum threshold value would underflow once SOC got down to 0, causing invalid alerts from the gauge. Fixes: e5f3872d2044 ("max17042: Add support for signalling change in SOC") Cc: Signed-off-by: Sebastian Krzyszkowiak Reviewed-by: Krzysztof Kozlowski Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman commit cb178acf8764fba33e6adbb3994c1daf51aaafa0 Author: Miquel Raynal Date: Wed Sep 29 00:22:47 2021 +0200 mtd: rawnand: socrates: Keep the driver compatible with on-die ECC engines commit b4ebddd6540d78a7f977b3fea0261bd575c6ffe2 upstream. Following the introduction of the generic ECC engine infrastructure, it was necessary to reorganize the code and move the ECC configuration in the ->attach_chip() hook. Failing to do that properly lead to a first series of fixes supposed to stabilize the situation. Unfortunately, this only fixed the use of software ECC engines, preventing any other kind of engine to be used, including on-die ones. It is now time to (finally) fix the situation by ensuring that we still provide a default (eg. software ECC) but will still support different ECC engines such as on-die ECC engines if properly described in the device tree. There are no changes needed on the core side in order to do this, but we just need to leverage the logic there which allows: 1- a subsystem default (set to Host engines in the raw NAND world) 2- a driver specific default (here set to software ECC engines) 3- any type of engine requested by the user (ie. described in the DT) As the raw NAND subsystem has not yet been fully converted to the ECC engine infrastructure, in order to provide a default ECC engine for this driver we need to set chip->ecc.engine_type *before* calling nand_scan(). During the initialization step, the core will consider this entry as the default engine for this driver. This value may of course be overloaded by the user if the usual DT properties are provided. Fixes: b36bf0a0fe5d ("mtd: rawnand: socrates: Move the ECC initialization to ->attach_chip()") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210928222258.199726-9-miquel.raynal@bootlin.com Signed-off-by: Greg Kroah-Hartman commit 3c6ffb9bb1ea068689303a2658c0db52de597c12 Author: Meng Li Date: Tue Oct 19 11:05:55 2021 +0800 soc: fsl: dpio: use the combined functions to protect critical zone commit dc7e5940aad6641bd5ab33ea8b21c4b3904d989f upstream. In orininal code, use 2 function spin_lock() and local_irq_save() to protect the critical zone. But when enable the kernel debug config, there are below inconsistent lock state detected. ================================ WARNING: inconsistent lock state 5.10.63-yocto-standard #1 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. lock_torture_wr/226 [HC0[0]:SC1[5]:HE1:SE0] takes: ffff002005b2dd80 (&p->access_spinlock){+.?.}-{3:3}, at: qbman_swp_enqueue_multiple_mem_back+0x44/0x270 {SOFTIRQ-ON-W} state was registered at: lock_acquire.part.0+0xf8/0x250 lock_acquire+0x68/0x84 _raw_spin_lock+0x68/0x90 qbman_swp_enqueue_multiple_mem_back+0x44/0x270 ...... cryptomgr_test+0x38/0x60 kthread+0x158/0x164 ret_from_fork+0x10/0x38 irq event stamp: 4498 hardirqs last enabled at (4498): [] _raw_spin_unlock_irqrestore+0x90/0xb0 hardirqs last disabled at (4497): [] _raw_spin_lock_irqsave+0xd4/0xe0 softirqs last enabled at (4458): [] __do_softirq+0x674/0x724 softirqs last disabled at (4465): [] __irq_exit_rcu+0x190/0x19c other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&p->access_spinlock); lock(&p->access_spinlock); *** DEADLOCK *** So, in order to avoid deadlock, use the combined functions spin_lock_irqsave/spin_unlock_irqrestore() to protect critical zone. Fixes: 3b2abda7d28c ("soc: fsl: dpio: Replace QMAN array mode with ring mode enqueue") Cc: stable@vger.kernel.org Signed-off-by: Meng Li Signed-off-by: Li Yang Signed-off-by: Greg Kroah-Hartman commit 54be06958eb466a05773c5ac9b4ee5e14f93e7ff Author: Meng Li Date: Tue Oct 19 10:32:41 2021 +0800 soc: fsl: dpio: replace smp_processor_id with raw_smp_processor_id commit e775eb9fc2a4107f03222fa48bc95c2c82427e64 upstream. When enable debug kernel configs,there will be calltrace as below: BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1 caller is debug_smp_processor_id+0x20/0x30 CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.10.63-yocto-standard #1 Hardware name: NXP Layerscape LX2160ARDB (DT) Call trace: dump_backtrace+0x0/0x1a0 show_stack+0x24/0x30 dump_stack+0xf0/0x13c check_preemption_disabled+0x100/0x110 debug_smp_processor_id+0x20/0x30 dpaa2_io_query_fq_count+0xdc/0x154 dpaa2_eth_stop+0x144/0x314 __dev_close_many+0xdc/0x160 __dev_change_flags+0xe8/0x220 dev_change_flags+0x30/0x70 ic_close_devs+0x50/0x78 ip_auto_config+0xed0/0xf10 do_one_initcall+0xac/0x460 kernel_init_freeable+0x30c/0x378 kernel_init+0x20/0x128 ret_from_fork+0x10/0x38 Based on comment in the context, it doesn't matter whether preemption is disable or not. So, replace smp_processor_id() with raw_smp_processor_id() to avoid above call trace. Fixes: c89105c9b390 ("staging: fsl-mc: Move DPIO from staging to drivers/soc/fsl") Cc: stable@vger.kernel.org Signed-off-by: Meng Li Signed-off-by: Li Yang Signed-off-by: Greg Kroah-Hartman commit 38ae173cb7cfeefab01ce4c3a4188347a4734b13 Author: David Virag Date: Fri Sep 10 00:28:12 2021 +0200 soc: samsung: exynos-pmu: Fix compilation when nothing selects CONFIG_MFD_CORE commit e37ef6dcdb1f4738b01cec7fb7be46af07816af9 upstream. Commit 93618e344a5e ("soc: samsung: exynos-pmu: instantiate clkout driver as MFD") adds a "devm_mfd_add_devices" call in the exynos-pmu driver which depends on CONFIG_MFD_CORE. If no driver selects that config, the build will fail if CONFIG_EXYNOS_PMU is enabled with the following error: drivers/soc/samsung/exynos-pmu.c:137: undefined reference to `devm_mfd_add_devices' Fix this by making CONFIG_EXYNOS_PMU select CONFIG_MFD_CORE. Fixes: 93618e344a5e ("soc: samsung: exynos-pmu: instantiate clkout driver as MFD") Cc: Signed-off-by: David Virag Link: https://lore.kernel.org/r/20210909222812.108614-1-virag.david003@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit d3586ddc9889e70ce1040d9c39433286a122a82f Author: Eric W. Biederman Date: Wed Oct 20 12:43:51 2021 -0500 signal/mips: Update (_save|_restore)_fp_context to fail with -EFAULT commit 95bf9d646c3c3f95cb0be7e703b371db8da5be68 upstream. When an instruction to save or restore a register from the stack fails in _save_fp_context or _restore_fp_context return with -EFAULT. This change was made to r2300_fpu.S[1] but it looks like it got lost with the introduction of EX2[2]. This is also what the other implementation of _save_fp_context and _restore_fp_context in r4k_fpu.S does, and what is needed for the callers to be able to handle the error. Furthermore calling do_exit(SIGSEGV) from bad_stack is wrong because it does not terminate the entire process it just terminates a single thread. As the changed code was the only caller of arch/mips/kernel/syscall.c:bad_stack remove the problematic and now unused helper function. Cc: Thomas Bogendoerfer Cc: Maciej Rozycki Cc: linux-mips@vger.kernel.org [1] 35938a00ba86 ("MIPS: Fix ISA I FP sigcontext access violation handling") [2] f92722dc4545 ("MIPS: Correct MIPS I FP sigcontext layout") Cc: stable@vger.kernel.org Fixes: f92722dc4545 ("MIPS: Correct MIPS I FP sigcontext layout") Acked-by: Maciej W. Rozycki Acked-by: Thomas Bogendoerfer Link: https://lkml.kernel.org/r/20211020174406.17889-5-ebiederm@xmission.com Signed-off-by: Eric W. Biederman Signed-off-by: Greg Kroah-Hartman commit 9f3e024e6483929cc9cf513e6f473712af7af7ef Author: Wolfram Sang Date: Wed Sep 22 11:10:06 2021 +0200 memory: renesas-rpc-if: Correct QSPI data transfer in Manual mode commit fff53a551db50f5edecaa0b29a64056ab8d2bbca upstream. This patch fixes 2 problems: [1] The output warning logs and data loss when performing mount/umount then remount the device with jffs2 format. [2] The access width of SMWDR[0:1]/SMRDR[0:1] register is wrong. This is the sample warning logs when performing mount/umount then remount the device with jffs2 format: jffs2: jffs2_scan_inode_node(): CRC failed on node at 0x031c51d4: Read 0x00034e00, calculated 0xadb272a7 The reason for issue [1] is that the writing data seems to get messed up. Data is only completed when the number of bytes is divisible by 4. If you only have 3 bytes of data left to write, 1 garbage byte is inserted after the end of the write stream. If you only have 2 bytes of data left to write, 2 bytes of '00' are added into the write stream. If you only have 1 byte of data left to write, 2 bytes of '00' are added into the write stream. 1 garbage byte is inserted after the end of the write stream. To solve problem [1], data must be written continuously in serial and the write stream ends when data is out. Following HW manual 62.2.15, access to SMWDR0 register should be in the same size as the transfer size specified in the SPIDE[3:0] bits in the manual mode enable setting register (SMENR). Be sure to access from address 0. So, in 16-bit transfer (SPIDE[3:0]=b'1100), SMWDR0 should be accessed by 16-bit width. Similar to SMWDR1, SMDDR0/1 registers. In current code, SMWDR0 register is accessed by regmap_write() that only set up to do 32-bit width. To solve problem [2], data must be written 16-bit or 8-bit when transferring 1-byte or 2-byte. Fixes: ca7d8b980b67 ("memory: add Renesas RPC-IF driver") Cc: Signed-off-by: Duc Nguyen [wsa: refactored to use regmap only via reg_read/reg_write] Signed-off-by: Wolfram Sang Tested-by: Lad Prabhakar Link: https://lore.kernel.org/r/20210922091007.5516-1-wsa+renesas@sang-engineering.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman commit b70a29116278ba9b5f065f87a20f160d76611b58 Author: Eric W. Biederman Date: Wed Sep 1 13:21:34 2021 -0500 signal: Remove the bogus sigkill_pending in ptrace_stop commit 7d613f9f72ec8f90ddefcae038fdae5adb8404b3 upstream. The existence of sigkill_pending is a little silly as it is functionally a duplicate of fatal_signal_pending that is used in exactly one place. Checking for pending fatal signals and returning early in ptrace_stop is actively harmful. It casues the ptrace_stop called by ptrace_signal to return early before setting current->exit_code. Later when ptrace_signal reads the signal number from current->exit_code is undefined, making it unpredictable what will happen. Instead rely on the fact that schedule will not sleep if there is a pending signal that can awaken a task. Removing the explict sigkill_pending test fixes fixes ptrace_signal when ptrace_stop does not stop because current->exit_code is always set to to signr. Cc: stable@vger.kernel.org Fixes: 3d749b9e676b ("ptrace: simplify ptrace_stop()->sigkill_pending() path") Fixes: 1a669c2f16d4 ("Add arch_ptrace_stop") Link: https://lkml.kernel.org/r/87pmsyx29t.fsf@disp2133 Reviewed-by: Kees Cook Signed-off-by: "Eric W. Biederman" Signed-off-by: Greg Kroah-Hartman commit 0509d911b94eb5008b0f4617e2d2714f4f4db888 Author: Dmitry Osipenko Date: Sun Oct 24 22:28:52 2021 +0300 ASoC: tegra: Restore AC97 support commit de8fc2b0a3f9930f3cbe801d40758bb1d80b0ad8 upstream. The device-tree of AC97 codecs need to be parsed differently from I2S codecs, plus codec device may need to be created. This was missed by the patch that unified machine drivers into a single driver, fix it. It should restore audio on Toradex Colibri board. Cc: Fixes: cc8f70f56039 ("ASoC: tegra: Unify ASoC machine drivers") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20211024192853.21957-1-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 64c65655758bd62bbbbedcc8e5ae247b360a0ebc Author: Dmitry Osipenko Date: Sun Oct 24 22:28:53 2021 +0300 ASoC: tegra: Set default card name for Trimslice commit 824edd866a13db7dbb0d8e26d2142f10271b6460 upstream. The default card name for Trimslice device should be "tegra-trimslice". It got lost by accident during unification of machine sound drivers, fix it. Cc: Fixes: cc8f70f56039 ("ASoC: tegra: Unify ASoC machine drivers") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20211024192853.21957-2-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 0aef11438832f22a17d3dde72ad2d115b9539af0 Author: Alok Prasad Date: Wed Oct 27 18:43:29 2021 +0000 RDMA/qedr: Fix NULL deref for query_qp on the GSI QP commit 4f960393a0ee9a39469ceb7c8077ae8db665cc12 upstream. This patch fixes a crash caused by querying the QP via netlink, and corrects the state of GSI qp. GSI qp's have a NULL qed_qp. The call trace is generated by: $ rdma res show BUG: kernel NULL pointer dereference, address: 0000000000000034 Hardware name: Dell Inc. PowerEdge R720/0M1GCR, BIOS 1.2.6 05/10/2012 RIP: 0010:qed_rdma_query_qp+0x33/0x1a0 [qed] RSP: 0018:ffffba560a08f580 EFLAGS: 00010206 RAX: 0000000200000000 RBX: ffffba560a08f5b8 RCX: 0000000000000000 RDX: ffffba560a08f5b8 RSI: 0000000000000000 RDI: ffff9807ee458090 RBP: ffffba560a08f5a0 R08: 0000000000000000 R09: ffff9807890e7048 R10: ffffba560a08f658 R11: 0000000000000000 R12: 0000000000000000 R13: ffff9807ee458090 R14: ffff9807f0afb000 R15: ffffba560a08f7ec FS: 00007fbbf8bfe740(0000) GS:ffff980aafa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000034 CR3: 00000001720ba001 CR4: 00000000000606f0 Call Trace: qedr_query_qp+0x82/0x360 [qedr] ib_query_qp+0x34/0x40 [ib_core] ? ib_query_qp+0x34/0x40 [ib_core] fill_res_qp_entry_query.isra.26+0x47/0x1d0 [ib_core] ? __nla_put+0x20/0x30 ? nla_put+0x33/0x40 fill_res_qp_entry+0xe3/0x120 [ib_core] res_get_common_dumpit+0x3f8/0x5d0 [ib_core] ? fill_res_cm_id_entry+0x1f0/0x1f0 [ib_core] nldev_res_get_qp_dumpit+0x1a/0x20 [ib_core] netlink_dump+0x156/0x2f0 __netlink_dump_start+0x1ab/0x260 rdma_nl_rcv+0x1de/0x330 [ib_core] ? nldev_res_get_cm_id_dumpit+0x20/0x20 [ib_core] netlink_unicast+0x1b8/0x270 netlink_sendmsg+0x33e/0x470 sock_sendmsg+0x63/0x70 __sys_sendto+0x13f/0x180 ? setup_sgl.isra.12+0x70/0xc0 __x64_sys_sendto+0x28/0x30 do_syscall_64+0x3a/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Cc: stable@vger.kernel.org Fixes: cecbcddf6461 ("qedr: Add support for QP verbs") Link: https://lore.kernel.org/r/20211027184329.18454-1-palok@marvell.com Signed-off-by: Ariel Elior Signed-off-by: Shai Malin Signed-off-by: Prabhakar Kushwaha Signed-off-by: Alok Prasad Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit 7ed060a0ea3855b7bd3a4540e1926e25c478cae8 Author: Kan Liang Date: Thu Aug 26 08:32:39 2021 -0700 perf/x86/intel/uncore: Fix Intel ICX IIO event constraints commit f42e8a603c88f72bf047a710b9fc1d3579f31e71 upstream. According to the latest uncore document, both NUM_OUTSTANDING_REQ_OF_CPU (0x88) event and COMP_BUF_OCCUPANCY(0xd5) event also have constraints. Add them into the event constraints table. Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1629991963-102621-4-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 2e11d51006acc292950f05d71ea5048a77130f46 Author: Kan Liang Date: Thu Aug 26 08:32:38 2021 -0700 perf/x86/intel/uncore: Fix invalid unit check commit e2bb9fab08cbcc7922050c7eb0bd650807abfa4e upstream. The uncore unit with the type ID 0 and the unit ID 0 is missed. The table3 of the uncore unit maybe 0. The uncore_discovery_invalid_unit() mistakenly treated it as an invalid value. Remove the !unit.table3 check. Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1629991963-102621-3-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 425e486c72d61461221e8a1debb6846e28da7b6c Author: Kan Liang Date: Thu Aug 26 08:32:37 2021 -0700 perf/x86/intel/uncore: Support extra IMC channel on Ice Lake server commit 496a18f09374ad89b3ab4366019bc3975db90234 upstream. There are three channels on a Ice Lake server, but only two channels will ever be active. Current perf only enables two channels. Support the extra IMC channel, which may be activated on some Ice Lake machines. For a non-activated channel, the SW can still access it. The write will be ignored by the HW. 0 is always returned for the reading. Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support") Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Andi Kleen Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/1629991963-102621-2-git-send-email-kan.liang@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a3d5adaee5ace8674fea892f42d438a344c4f490 Author: Marek Vasut Date: Thu Sep 16 16:42:45 2021 +0200 rsi: Fix module dev_oper_mode parameter description commit 31f97cf9f0c31143a2a6fcc89c4a1286ce20157e upstream. The module parameters are missing dev_oper_mode 12, BT classic alone, add it. Moreover, the parameters encode newlines, which ends up being printed malformed e.g. by modinfo, so fix that too. However, the module parameter string is duplicated in both USB and SDIO modules and the dev_oper_mode mode enumeration in those module parameters is a duplicate of macros used by the driver. Furthermore, the enumeration is confusing. So, deduplicate the module parameter string and use __stringify() to encode the correct mode enumeration values into the module parameter string. Finally, replace 'Wi-Fi' with 'Wi-Fi alone' and 'BT' with 'BT classic alone' to clarify what those modes really mean. Fixes: 898b255339310 ("rsi: add module parameter operating mode") Signed-off-by: Marek Vasut Cc: Amitkumar Karwar Cc: Angus Ainslie Cc: David S. Miller Cc: Jakub Kicinski Cc: Kalle Valo Cc: Karun Eagalapati Cc: Martin Fuzzey Cc: Martin Kepplinger Cc: Prameela Rani Garnepudi Cc: Sebastian Krzyszkowiak Cc: Siva Rebbagondla Cc: netdev@vger.kernel.org Cc: # 4.17+ Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210916144245.10181-1-marex@denx.de Signed-off-by: Greg Kroah-Hartman commit c76421bd155f6c862c39ed669b5a0daf0d99a3ef Author: Martin Fuzzey Date: Mon Aug 30 17:26:46 2021 +0200 rsi: fix rate mask set leading to P2P failure commit b515d097053a71d624e0c5840b42cd4caa653941 upstream. P2P client mode was only working the first time. On subsequent connection attempts the group was successfully created but no data was sent (no transmitted data packets were seen with a sniffer). The reason for this was that the hardware was being configured in fixed rate mode with rate RSI_RATE_1 (1Mbps) which is not valid in the 5GHz band. In P2P mode wpa_supplicant uses NL80211_CMD_SET_TX_BITRATE_MASK to disallow the 11b rates in the 2.4GHz band which updated common->fixedrate_mask. rsi_set_min_rate() then used the fixedrate_mask to calculate the minimum allowed rate, or 0xffff = auto if none was found. However that calculation did not account for the different rate sets allowed in the different bands leading to the error. Fixing set_min_rate() would result in 6Mb/s being used all the time which is not what we want either. The reason the problem did not occur on the first connection is that rsi_mac80211_set_rate_mask() only updated the fixedrate_mask for the *current* band. When it was called that was still 2.4GHz as the switch is done later. So the when set_min_rate() was subsequently called after the switch to 5GHz it still had a mask of zero, leading to defaulting to auto mode. Fix this by differentiating the case of a single rate being requested, in which case the hardware will be used in fixed rate mode with just that rate, and multiple rates being requested, in which case we remain in auto mode but the firmware rate selection algorithm is configured with a restricted set of rates. Fixes: dad0d04fa7ba ("rsi: Add RS9113 wireless driver") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-4-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman commit 437ce21d2076117ef61a48fcd00764cca966e1b6 Author: Martin Fuzzey Date: Mon Aug 30 17:26:45 2021 +0200 rsi: fix key enabled check causing unwanted encryption for vap_id > 0 commit 99ac6018821253ec67f466086afb63fc18ea48e2 upstream. My previous patch checked if encryption should be enabled by directly checking info->control.hw_key (like the downstream driver). However that missed that the control and driver_info members of struct ieee80211_tx_info are union fields. Due to this when rsi_core_xmit() updates fields in "tx_params" (driver_info) it can overwrite the control.hw_key, causing the result of the later test to be incorrect. With the current structure layout the first byte of control.hw_key is overlayed with the vap_id so, since we only test if control.hw_key is NULL / non NULL, a non zero vap_id will incorrectly enable encryption. In basic STA and AP modes the vap_id is always zero so it works but in P2P client mode a second VIF is created causing vap_id to be non zero and hence encryption to be enabled before keys have been set. Fix this by extracting the key presence flag to a new field in the driver private tx_params structure and populating it first. Fixes: 314538041b56 ("rsi: fix AP mode with WPA failure due to encrypted EAPOL") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-3-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman commit 3945a7308f0d585b1780d00f8d14f10d63ab11cb Author: Martin Fuzzey Date: Mon Aug 30 17:26:44 2021 +0200 rsi: fix occasional initialisation failure with BT coex commit 9b14ed6e11b72dd4806535449ca6c6962cb2369d upstream. When BT coexistence is enabled (eg oper mode 13, which is the default) the initialisation on startup sometimes silently fails. In a normal initialisation we see usb 1-1.3: Product: Wireless USB Network Module usb 1-1.3: Manufacturer: Redpine Signals, Inc. usb 1-1.3: SerialNumber: 000000000001 rsi_91x: rsi_probe: Initialized os intf ops rsi_91x: rsi_load_9116_firmware: Loading chunk 0 rsi_91x: rsi_load_9116_firmware: Loading chunk 1 rsi_91x: rsi_load_9116_firmware: Loading chunk 2 rsi_91x: Max Stations Allowed = 1 But sometimes the last log is missing and the wlan net device is not created. Running a userspace loop that resets the hardware via a GPIO shows the problem occurring ~5/100 resets. The problem does not occur in oper mode 1 (wifi only). Adding logs shows that the initialisation state machine requests a MAC reset via rsi_send_reset_mac() but the firmware does not reply, leading to the initialisation sequence being incomplete. Fix this by delaying attaching the BT adapter until the wifi initialisation has completed. With this applied I have done > 300 reset loops with no errors. Fixes: 716b840c7641 ("rsi: handle BT traffic in driver") Signed-off-by: Martin Fuzzey CC: stable@vger.kernel.org Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1630337206-12410-2-git-send-email-martin.fuzzey@flowbird.group Signed-off-by: Greg Kroah-Hartman commit 471e28ecee8c6783576deba72b198f0694093d98 Author: Benjamin Li Date: Wed Sep 1 11:06:05 2021 -0700 wcn36xx: handle connection loss indication commit d6dbce453b19c64b96f3e927b10230f9a704b504 upstream. Firmware sends delete_sta_context_ind when it detects the AP has gone away in STA mode. Right now the handler for that indication only handles AP mode; fix it to also handle STA mode. Cc: stable@vger.kernel.org Signed-off-by: Benjamin Li Reviewed-by: Bryan O'Donoghue Reviewed-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210901180606.11686-1-benl@squareup.com Signed-off-by: Greg Kroah-Hartman commit 4c13483e1fa4e8ebfdbebf9f4257bca4d26b3834 Author: Reimar Döffinger Date: Tue Oct 12 08:27:44 2021 +0200 libata: fix checking of DMA state commit f971a85439bd25dc7b4d597cf5e4e8dc7ffc884b upstream. Checking if DMA is enabled should be done via the ata_dma_enabled helper function, since the init state 0xff indicates disabled. This meant that ATA_CMD_READ_LOG_DMA_EXT was used and probed for before DMA was enabled, which caused hangs for some combinations of controllers and devices. It might also have caused it to be incorrectly disabled as broken, but there have been no reports of that. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195895 Signed-off-by: Reimar Döffinger Tested-by: Paul Menzel Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 1a0963d1d4489b00b1445e42ceefde831104cb2b Author: Jonas Dreßler Date: Mon Oct 11 15:32:24 2021 +0200 mwifiex: Try waking the firmware until we get an interrupt commit 8e3e59c31fea5de95ffc52c46f0c562c39f20c59 upstream. It seems that the PCIe+USB firmware (latest version 15.68.19.p21) of the 88W8897 card sometimes ignores or misses when we try to wake it up by writing to the firmware status register. This leads to the firmware wakeup timeout expiring and the driver resetting the card because we assume the firmware has hung up or crashed. Turns out that the firmware actually didn't hang up, but simply "missed" our wakeup request and didn't send us an interrupt with an AWAKE event. Trying again to read the firmware status register after a short timeout usually makes the firmware wake up as expected, so add a small retry loop to mwifiex_pm_wakeup_card() that looks at the interrupt status to check whether the card woke up. The number of tries and timeout lengths for this were determined experimentally: The firmware usually takes about 500 us to wake up after we attempt to read the status register. In some cases where the firmware is very busy (for example while doing a bluetooth scan) it might even miss our requests for multiple milliseconds, which is why after 15 tries the waiting time gets increased to 10 ms. The maximum number of tries it took to wake the firmware when testing this was around 20, so a maximum number of 50 tries should give us plenty of safety margin. Here's a reproducer for those firmware wakeup failures I've found: 1) Make sure wifi powersaving is enabled (iw dev wlp1s0 set power_save on) 2) Connect to any wifi network (makes firmware go into wifi powersaving mode, not deep sleep) 3) Make sure bluetooth is turned off (to ensure the firmware actually enters powersave mode and doesn't keep the radio active doing bluetooth stuff) 4) To confirm that wifi powersaving is entered ping a device on the LAN, pings should be a few ms higher than without powersaving 5) Run "while true; do iwconfig; sleep 0.0001; done", this wakes and suspends the firmware extremely often 6) Wait until things explode, for me it consistently takes <5 minutes BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211011133224.15561-3-verdre@v0yd.nl Signed-off-by: Greg Kroah-Hartman commit e5fbcd97b4be8a4ecbfaa2fbb4861249cc73b547 Author: Jonas Dreßler Date: Mon Oct 11 15:32:23 2021 +0200 mwifiex: Read a PCI register after writing the TX ring write pointer commit e5f4eb8223aa740237cd463246a7debcddf4eda1 upstream. On the 88W8897 PCIe+USB card the firmware randomly crashes after setting the TX ring write pointer. The issue is present in the latest firmware version 15.68.19.p21 of the PCIe+USB card. Those firmware crashes can be worked around by reading any PCI register of the card after setting that register, so read the PCI_VENDOR_ID register here. The reason this works is probably because we keep the bus from entering an ASPM state for a bit longer, because that's what causes the cards firmware to crash. This fixes a bug where during RX/TX traffic and with ASPM L1 substates enabled (the specific substates where the issue happens appear to be platform dependent), the firmware crashes and eventually a command timeout appears in the logs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109681 Cc: stable@vger.kernel.org Signed-off-by: Jonas Dreßler Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211011133224.15561-2-verdre@v0yd.nl Signed-off-by: Greg Kroah-Hartman commit ad34c5f90c2cd1a2ee5c8764e03fc99f4a5851e9 Author: Rafael J. Wysocki Date: Fri Oct 22 14:58:23 2021 +0200 PM: sleep: Do not let "syscore" devices runtime-suspend during system transitions commit 928265e3601cde78c7e0a3e518a93b27defed3b1 upstream. There is no reason to allow "syscore" devices to runtime-suspend during system-wide PM transitions, because they are subject to the same possible failure modes as any other devices in that respect. Accordingly, change device_prepare() and device_complete() to call pm_runtime_get_noresume() and pm_runtime_put(), respectively, for "syscore" devices too. Fixes: 057d51a1268f ("Merge branch 'pm-sleep'") Signed-off-by: Rafael J. Wysocki Cc: 3.10+ # 3.10+ Reviewed-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 0f2d037e8ae992656b23ccff29092ba88ba402cc Author: Loic Poulain Date: Mon Oct 25 16:12:18 2021 +0300 wcn36xx: Fix (QoS) null data frame bitrate/modulation commit d3fd2c95c1c13ec217d43ebef3c61cfa00a6cd37 upstream. We observe unexpected connection drops with some APs due to non-acked mac80211 generated null data frames (keep-alive). After debugging and capture, we noticed that null frames are submitted at standard data bitrate and that the given APs are in trouble with that. After setting the null frame bitrate to control bitrate, all null frames are acked as expected and connection is maintained. Not sure if it's a requirement of the specification, but it seems the right thing to do anyway, null frames are mostly used for control purpose (power-saving, keep-alive...), and submitting them with a slower/simpler bitrate/modulation is more robust. Cc: stable@vger.kernel.org Fixes: 512b191d9652 ("wcn36xx: Fix TX data path") Signed-off-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1634560399-15290-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman commit ec82bede563b8e1732840d5d23acdd4715ce5b41 Author: Loic Poulain Date: Mon Oct 25 16:12:18 2021 +0300 wcn36xx: Fix tx_status mechanism commit a9e79b116cc4d0057e912be8f40b2c2e5bdc7c43 upstream. This change fix the TX ack mechanism in various ways: - For NO_ACK tagged packets, we don't need to wait for TX_ACK indication and so are not subject to the single packet ack limitation. So we don't have to stop the tx queue, and can call the tx status callback as soon as DMA transfer has completed. - Fix skb ownership/reference. Only start status indication timeout once the DMA transfer has been completed. This avoids the skb to be both referenced in the DMA tx ring and by the tx_ack_skb pointer, preventing any use-after-free or double-free. - This adds a sanity (paranoia?) check on the skb tx ack pointer. - Resume TX queue if TX status tagged packet TX fails. Cc: stable@vger.kernel.org Fixes: fdf21cc37149 ("wcn36xx: Add TX ack support") Signed-off-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1634567281-28997-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman commit 52da1f9c5e9cbfb7129cfe45f3cfd9c918322a81 Author: Loic Poulain Date: Wed Oct 20 15:38:53 2021 +0200 wcn36xx: Fix HT40 capability for 2Ghz band commit 960ae77f25631bbe4e3aafefe209b52e044baf31 upstream. All wcn36xx controllers are supposed to support HT40 (and SGI40), This doubles the maximum bitrate/throughput with compatible APs. Tested with wcn3620 & wcn3680B. Cc: stable@vger.kernel.org Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Loic Poulain Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/1634737133-22336-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Greg Kroah-Hartman commit 91fa7ec38256d8ac8435a1038ef6eddbbd4ff645 Author: Maximilian Luz Date: Thu Oct 21 15:09:04 2021 +0200 HID: surface-hid: Allow driver matching for target ID 1 devices commit ab5fe33925c6b03f646a1153771dab047548e4d8 upstream. Until now we have only ever seen HID devices with target ID 2. The new Surface Laptop Studio however uses HID devices with target ID 1. Allow matching this driver to those as well. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20211021130904.862610-4-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 4d55b85a1598acd532e6217f529d2b18105f5979 Author: Maximilian Luz Date: Thu Oct 21 15:09:03 2021 +0200 HID: surface-hid: Use correct event registry for managing HID events commit dc0fd0acb6e0e8025a0a43ada54513b216254fac upstream. Until now, we have only ever seen the REG-category registry being used on devices addressed with target ID 2. In fact, we have only ever seen Surface Aggregator Module (SAM) HID devices with target ID 2. For those devices, the registry also has to be addressed with target ID 2. Some devices, like the new Surface Laptop Studio, however, address their HID devices on target ID 1. As a result of this, any target ID 2 commands time out. This includes event management commands addressed to the target ID 2 REG-category registry. For these devices, the registry has to be addressed via target ID 1 instead. We therefore assume that the target ID of the registry to be used depends on the target ID of the respective device. Implement this accordingly. Note that we currently allow the surface HID driver to only load against devices with target ID 2, so these timeouts are not happening (yet). This is just a preparation step before we allow the driver to load against all target IDs. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz Acked-by: Benjamin Tissoires Link: https://lore.kernel.org/r/20211021130904.862610-3-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 6979b6f294c0706a37dc41d488e49577eee04a56 Author: Felix Fietkau Date: Wed Jul 21 07:23:46 2021 +0200 mt76: mt7615: fix skb use-after-free on mac reset commit b5cd1fd6043bbb7c5810067b5f93f3016bfd8a6f upstream. When clearing all existing pending tx slots, mt76_tx_complete_skb needs to be used to free the skbs, to ensure that they are cleared from the status list as well. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau Signed-off-by: Greg Kroah-Hartman commit 7761ffec11da3c4c0a22db649399c00f7ec1592b Author: Maximilian Luz Date: Thu Oct 21 15:09:02 2021 +0200 platform/surface: aggregator_registry: Add support for Surface Laptop Studio commit 4f042e40199ce8bac6bc2b853e81744ee4ea759c upstream. Add support for the Surface Laptop Studio. In contrast to previous Surface Laptop models, this one has its HID devices attached to target ID 1 (instead of 2). It also has a couple more of them, including a new notifier for when the pen is stashed / taken out of its place, a "Sys Control" device, and two other unidentified HID devices with unknown usages. Battery and performance profile interfaces remain the same. Cc: stable@vger.kernel.org # 5.14+ Signed-off-by: Maximilian Luz Link: https://lore.kernel.org/r/20211021130904.862610-2-luzmaximilian@gmail.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit dd6c06c4538c05c3be7f63e496f79c96f71bc2f2 Author: Lukas Wunner Date: Tue Oct 26 07:15:32 2021 +0200 ifb: Depend on netfilter alternatively to tc commit 046178e726c2977d686ba5e07105d5a6685c830e upstream. IFB originally depended on NET_CLS_ACT for traffic redirection. But since v4.5, that may be achieved with NFT_FWD_NETDEV as well. Fixes: 39e6dea28adc ("netfilter: nf_tables: add forward expression to the netdev family") Signed-off-by: Lukas Wunner Cc: # v4.5+: bcfabee1afd9: netfilter: nft_fwd_netdev: allow to redirect to ifb via ingress Cc: # v4.5+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2cd65a22a478c6a8f461933978660dc64d56d0b1 Author: Austin Kim Date: Thu Oct 28 12:26:42 2021 +0100 evm: mark evm_fixmode as __ro_after_init commit 32ba540f3c2a7ef61ed5a577ce25069a3d714fc9 upstream. The evm_fixmode is only configurable by command-line option and it is never modified outside initcalls, so declaring it with __ro_after_init is better. Signed-off-by: Austin Kim Cc: stable@vger.kernel.org Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman commit e426e7842ee38284f23dbcd068a11ed317e3416a Author: Johan Hovold Date: Mon Oct 25 14:05:21 2021 +0200 rtl8187: fix control-message timeouts commit 2e9be536a213e838daed6ba42024dd68954ac061 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 605bebe23bf6 ("[PATCH] Add rtl8187 wireless driver") Cc: stable@vger.kernel.org # 2.6.23 Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211025120522.6045-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit bab67ca269f9819f02939995194a1567cedc03be Author: Ingmar Klein Date: Fri Apr 9 11:26:33 2021 +0200 PCI: Mark Atheros QCA6174 to avoid bus reset commit e3f4bd3462f6f796594ecc0dda7144ed2d1e5a26 upstream. When passing the Atheros QCA6174 through to a virtual machine, the VM hangs at the point where the ath10k driver loads. Add a quirk to avoid bus resets on this device, which avoids the hang. [bhelgaas: commit log] Link: https://lore.kernel.org/r/08982e05-b6e8-5a8d-24ab-da1488ee50a8@web.de Signed-off-by: Ingmar Klein Signed-off-by: Bjorn Helgaas Reviewed-by: Pali Rohár Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 0d74280d5dd96987817cdf97bcf2c83b8e391d99 Author: Johan Hovold Date: Wed Oct 27 10:08:17 2021 +0200 ath10k: fix division by zero in send path commit a006acb931317aad3a8dd41333ebb0453caf49b8 upstream. Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in ath10k_usb_hif_tx_sg() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 4db66499df91 ("ath10k: add initial USB support") Cc: stable@vger.kernel.org # 4.14 Cc: Erik Stromdahl Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211027080819.6675-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit b5b911da1b168c8523f7002a2c061983ccb221d5 Author: Johan Hovold Date: Mon Oct 25 14:05:19 2021 +0200 ath10k: fix control-message timeout commit 5286132324230168d3fab6ffc16bfd7de85bdfb4 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 4db66499df91 ("ath10k: add initial USB support") Cc: stable@vger.kernel.org # 4.14 Cc: Erik Stromdahl Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211025120522.6045-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit abd6b17ca36f6adb7ac59bf71c9e97480acab6cd Author: Johan Hovold Date: Mon Oct 25 14:05:20 2021 +0200 ath6kl: fix control-message timeout commit a066d28a7e729f808a3e6eff22e70c003091544e upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 241b128b6b69 ("ath6kl: add back beginnings of USB support") Cc: stable@vger.kernel.org # 3.4 Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211025120522.6045-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit dbe62858b49fe9c1e7a5d591fabd4571c0364d54 Author: Johan Hovold Date: Wed Oct 27 10:08:18 2021 +0200 ath6kl: fix division by zero in send path commit c1b9ca365deae667192be9fe24db244919971234 upstream. Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in ath10k_usb_hif_tx_sg() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 9cbee358687e ("ath6kl: add full USB support") Cc: stable@vger.kernel.org # 3.5 Signed-off-by: Johan Hovold Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211027080819.6675-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 96d108642240432f272815ad8bdcb1ef75b09b24 Author: Johan Hovold Date: Wed Oct 27 10:08:19 2021 +0200 mwifiex: fix division by zero in fw download path commit 89f8765a11d8df49296d92c404067f9b5c58ee26 upstream. Add the missing endpoint sanity checks to probe() to avoid division by zero in mwifiex_write_data_sync() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Only add checks for the firmware-download boot stage, which require both command endpoints, for now. The driver looks like it will handle a missing endpoint during normal operation without oopsing, albeit not very gracefully as it will try to submit URBs to the default pipe and fail. Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 4daffe354366 ("mwifiex: add support for Marvell USB8797 chipset") Cc: stable@vger.kernel.org # 3.5 Cc: Amitkumar Karwar Signed-off-by: Johan Hovold Reviewed-by: Brian Norris Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20211027080819.6675-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 2bbb56b7c305c69982cccdb0ba1f9dcc3c1b58e1 Author: Eric Badger Date: Sun Oct 10 10:06:56 2021 -0700 EDAC/sb_edac: Fix top-of-high-memory value for Broadwell/Haswell commit 537bddd069c743759addf422d0b8f028ff0f8dbc upstream. The computation of TOHM is off by one bit. This missed bit results in too low a value for TOHM, which can cause errors in regular memory to incorrectly report: EDAC MC0: 1 CE Error at MMIOH area, on addr 0x000000207fffa680 on any memory Fixes: 50d1bb93672f ("sb_edac: add support for Haswell based systems") Cc: stable@vger.kernel.org Reported-by: Meeta Saggi Signed-off-by: Eric Badger Signed-off-by: Tony Luck Link: https://lore.kernel.org/r/20211010170127.848113-1-ebadger@purestorage.com Signed-off-by: Greg Kroah-Hartman commit 8f3420977c98019c2399e55ba4b6cdbe71fdc49c Author: Krzysztof Kozlowski Date: Fri Oct 8 13:37:14 2021 +0200 regulator: dt-bindings: samsung,s5m8767: correct s5m8767,pmic-buck-default-dvs-idx property commit a7fda04bc9b6ad9da8e19c9e6e3b1dab773d068a upstream. The driver was always parsing "s5m8767,pmic-buck-default-dvs-idx", not "s5m8767,pmic-buck234-default-dvs-idx". Cc: Fixes: 26aec009f6b6 ("regulator: add device tree support for s5m8767") Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Message-Id: <20211008113723.134648-3-krzysztof.kozlowski@canonical.com> Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 79814094ec44f111f6a19180570d3668c20bd2e4 Author: Krzysztof Kozlowski Date: Fri Oct 8 13:37:13 2021 +0200 regulator: s5m8767: do not use reset value as DVS voltage if GPIO DVS is disabled commit b16bef60a9112b1e6daf3afd16484eb06e7ce792 upstream. The driver and its bindings, before commit 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4") were requiring to provide at least one safe/default voltage for DVS registers if DVS GPIO is not being enabled. IOW, if s5m8767,pmic-buck2-uses-gpio-dvs is missing, the s5m8767,pmic-buck2-dvs-voltage should still be present and contain one voltage. This requirement was coming from driver behavior matching this condition (none of DVS GPIO is enabled): it was always initializing the DVS selector pins to 0 and keeping the DVS enable setting at reset value (enabled). Therefore if none of DVS GPIO is enabled in devicetree, driver was configuring the first DVS voltage for buck[234]. Mentioned commit 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4") broke it because DVS voltage won't be parsed from devicetree if DVS GPIO is not enabled. After the change, driver will configure bucks to use the register reset value as voltage which might have unpleasant effects. Fix this by relaxing the bindings constrain: if DVS GPIO is not enabled in devicetree (therefore DVS voltage is also not parsed), explicitly disable it. Cc: Fixes: 04f9f068a619 ("regulator: s5m8767: Modify parsing method of the voltage table of buck2/3/4") Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Message-Id: <20211008113723.134648-2-krzysztof.kozlowski@canonical.com> Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5f31bc9bc695e22be29290dc81621d25de4bc2ed Author: Zev Weiss Date: Tue Sep 28 02:22:35 2021 -0700 hwmon: (pmbus/lm25066) Add offset coefficients commit ae59dc455a78fb73034dd1fbb337d7e59c27cbd8 upstream. With the exception of the lm5066i, all the devices handled by this driver had been missing their offset ('b') coefficients for direct format readings. Cc: stable@vger.kernel.org Fixes: 58615a94f6a1 ("hwmon: (pmbus/lm25066) Add support for LM25056") Fixes: e53e6497fc9f ("hwmon: (pmbus/lm25066) Refactor device specific coefficients") Signed-off-by: Zev Weiss Link: https://lore.kernel.org/r/20210928092242.30036-2-zev@bewilderbeest.net Signed-off-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit b3ebc3edaf92b2a1c15f4d267f7161739d8eae17 Author: Guoqing Jiang Date: Mon Oct 4 23:34:48 2021 +0800 md/raid1: only allocate write behind bio for WriteMostly device commit fd3b6975e9c11c4fa00965f82a0bfbb3b7b44101 upstream. Commit 6607cd319b6b91bff94e90f798a61c031650b514 ("raid1: ensure write behind bio has less than BIO_MAX_VECS sectors") tried to guarantee the size of behind bio is not bigger than BIO_MAX_VECS sectors. Unfortunately the same calltrace still could happen since an array could enable write-behind without write mostly device. To match the manpage of mdadm (which says "write-behind is only attempted on drives marked as write-mostly"), we need to check WriteMostly flag to avoid such unexpected behavior. [1]. https://bugzilla.kernel.org/show_bug.cgi?id=213181#c25 Cc: stable@vger.kernel.org # v5.12+ Cc: Jens Stutte Reported-by: Jens Stutte Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit dde0b4bd579f2fe4e52f9352e8b30cfb5da99d37 Author: Corey Minyard Date: Mon Sep 20 06:25:37 2021 -0500 ipmi:watchdog: Set panic count to proper value on a panic commit db05ddf7f321634c5659a0cf7ea56594e22365f7 upstream. You will get two decrements when the messages on a panic are sent, not one, since commit 2033f6858970 ("ipmi: Free receive messages when in an oops") was added, but the watchdog code had a bug where it didn't set the value properly. Reported-by: Anton Lundin Cc: # v5.4+ Fixes: 2033f6858970 ("ipmi: Free receive messages when in an oops") Signed-off-by: Corey Minyard Signed-off-by: Greg Kroah-Hartman commit 035d39cd5d3649814f99d8e49e22d1a290db8c00 Author: Ondrej Mosnacek Date: Wed Jul 28 16:03:13 2021 +0200 selinux: fix race condition when computing ocontext SIDs commit cbfcd13be5cb2a07868afe67520ed181956579a7 upstream. Current code contains a lot of racy patterns when converting an ocontext's context structure to an SID. This is being done in a "lazy" fashion, such that the SID is looked up in the SID table only when it's first needed and then cached in the "sid" field of the ocontext structure. However, this is done without any locking or memory barriers and is thus unsafe. Between commits 24ed7fdae669 ("selinux: use separate table for initial SID lookup") and 66f8e2f03c02 ("selinux: sidtab reverse lookup hash table"), this race condition lead to an actual observable bug, because a pointer to the shared sid field was passed directly to sidtab_context_to_sid(), which was using this location to also store an intermediate value, which could have been read by other threads and interpreted as an SID. In practice this caused e.g. new mounts to get a wrong (seemingly random) filesystem context, leading to strange denials. This bug has been spotted in the wild at least twice, see [1] and [2]. Fix the race condition by making all the racy functions use a common helper that ensures the ocontext::sid accesses are made safely using the appropriate SMP constructs. Note that security_netif_sid() was populating the sid field of both contexts stored in the ocontext, but only the first one was actually used. The SELinux wiki's documentation on the "netifcon" policy statement [3] suggests that using only the first context is intentional. I kept only the handling of the first context here, as there is really no point in doing the SID lookup for the unused one. I wasn't able to reproduce the bug mentioned above on any kernel that includes commit 66f8e2f03c02, even though it has been reported that the issue occurs with that commit, too, just less frequently. Thus, I wasn't able to verify that this patch fixes the issue, but it makes sense to avoid the race condition regardless. [1] https://github.com/containers/container-selinux/issues/89 [2] https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.org/thread/6DMTAMHIOAOEMUAVTULJD45JZU7IBAFM/ [3] https://selinuxproject.org/page/NetworkStatements#netifcon Cc: stable@vger.kernel.org Cc: Xinjie Zheng Reported-by: Sujithra Periasamy Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Ondrej Mosnacek Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit a2973f00755fac830f3526ff8cda31442b480c52 Author: Masami Hiramatsu Date: Tue Sep 14 23:40:27 2021 +0900 ia64: kprobes: Fix to pass correct trampoline address to the handler commit a7fe2378454cf46cd5e2776d05e72bbe8f0a468c upstream. The following commit: Commit e792ff804f49 ("ia64: kprobes: Use generic kretprobe trampoline handler") Passed the wrong trampoline address to __kretprobe_trampoline_handler(): it passes the descriptor address instead of function entry address. Pass the right parameter. Also use correct symbol dereference function to get the function address from 'kretprobe_trampoline' - an IA64 special. Link: https://lkml.kernel.org/r/163163042696.489837.12551102356265354730.stgit@devnote2 Fixes: e792ff804f49 ("ia64: kprobes: Use generic kretprobe trampoline handler") Cc: Josh Poimboeuf Cc: Ingo Molnar Cc: X86 ML Cc: Daniel Xu Cc: Thomas Gleixner Cc: Borislav Petkov Cc: Peter Zijlstra Cc: Abhishek Sagar Cc: Andrii Nakryiko Cc: Paul McKenney Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 9a32b765fba36cafaf4f02d6fe20805a02bbad19 Author: Laurent Vivier Date: Thu Oct 28 00:21:50 2021 +1000 KVM: PPC: Tick accounting should defer vtime accounting 'til after IRQ handling commit 235cee162459d96153d63651ce7ff51752528c96 upstream. Commit 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest context before enabling irqs") moved guest_exit() into the interrupt protected area to avoid wrong context warning (or worse). The problem is that tick-based time accounting has not yet been updated at this point (because it depends on the timer interrupt firing), so the guest time gets incorrectly accounted to system time. To fix the problem, follow the x86 fix in commit 160457140187 ("Defer vtime accounting 'til after IRQ handling"), and allow host IRQs to run before accounting the guest exit time. In the case vtime accounting is enabled, this is not required because TB is used directly for accounting. Before this patch, with CONFIG_TICK_CPU_ACCOUNTING=y in the host and a guest running a kernel compile, the 'guest' fields of /proc/stat are stuck at zero. With the patch they can be observed increasing roughly as expected. Fixes: e233d54d4d97 ("KVM: booke: use __kvm_guest_exit") Fixes: 112665286d08 ("KVM: PPC: Book3S HV: Context tracking exit guest context before enabling irqs") Cc: stable@vger.kernel.org # 5.12+ Signed-off-by: Laurent Vivier [np: only required for tick accounting, add Book3E fix, tweak changelog] Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20211027142150.3711582-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit fe2a3d975e2700d14c8f6e693c7e08781f2ed80b Author: Sean Christopherson Date: Fri Oct 8 17:11:05 2021 -0700 KVM: VMX: Unregister posted interrupt wakeup handler on hardware unsetup commit ec5a4919fa7b7d8c7a2af1c7e799b1fe4be84343 upstream. Unregister KVM's posted interrupt wakeup handler during unsetup so that a spurious interrupt that arrives after kvm_intel.ko is unloaded doesn't call into freed memory. Fixes: bf9f6ac8d749 ("KVM: Update Posted-Interrupts Descriptor when vCPU is blocked") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20211009001107.3936588-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit fe5827e78a1fa342464bf62f5f038f7c5941b9ac Author: Anand Jain Date: Tue Oct 19 18:43:38 2021 +0800 btrfs: call btrfs_check_rw_degradable only if there is a missing device commit 5c78a5e7aa835c4f08a7c90fe02d19f95a776f29 upstream. In open_ctree() in btrfs_check_rw_degradable() [1], we check each block group individually if at least the minimum number of devices is available for that profile. If all the devices are available, then we don't have to check degradable. [1] open_ctree() :: 3559 if (!sb_rdonly(sb) && !btrfs_check_rw_degradable(fs_info, NULL)) { Also before calling btrfs_check_rw_degradable() in open_ctee() at the line number shown below [2] we call btrfs_read_chunk_tree() and down to add_missing_dev() to record number of missing devices. [2] open_ctree() :: 3454 ret = btrfs_read_chunk_tree(fs_info); btrfs_read_chunk_tree() read_one_chunk() / read_one_dev() add_missing_dev() So, check if there is any missing device before btrfs_check_rw_degradable() in open_ctree(). Also, with this the mount command could save ~16ms.[3] in the most common case, that is no device is missing. [3] 1) * 16934.96 us | btrfs_check_rw_degradable [btrfs](); CC: stable@vger.kernel.org # 4.19+ Reviewed-by: Josef Bacik Signed-off-by: Anand Jain Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 12707e6406b5a9d0bbbf2f7dc3b5ae13a9a6abcb Author: Filipe Manana Date: Thu Oct 14 17:26:04 2021 +0100 btrfs: fix lost error handling when replaying directory deletes commit 10adb1152d957a4d570ad630f93a88bb961616c1 upstream. At replay_dir_deletes(), if find_dir_range() returns an error we break out of the main while loop and then assign a value of 0 (success) to the 'ret' variable, resulting in completely ignoring that an error happened. Fix that by jumping to the 'out' label when find_dir_range() returns an error (negative value). CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit a32bd15ddf382eddd03c4ea4d3f0fa0aa9eab392 Author: Li Zhang Date: Tue Oct 5 01:15:33 2021 +0800 btrfs: clear MISSING device status bit in btrfs_close_one_device commit 5d03dbebba2594d2e6fbf3b5dd9060c5a835de3b upstream. Reported bug: https://github.com/kdave/btrfs-progs/issues/389 There's a problem with scrub reporting aborted status but returning error code 0, on a filesystem with missing and readded device. Roughly these steps: - mkfs -d raid1 dev1 dev2 - fill with data - unmount - make dev1 disappear - mount -o degraded - copy more data - make dev1 appear again Running scrub afterwards reports that the command was aborted, but the system log message says the exit code was 0. It seems that the cause of the error is decrementing fs_devices->missing_devices but not clearing device->dev_state. Every time we umount filesystem, it would call close_ctree, And it would eventually involve btrfs_close_one_device to close the device, but it only decrements fs_devices->missing_devices but does not clear the device BTRFS_DEV_STATE_MISSING bit. Worse, this bug will cause Integer Overflow, because every time umount, fs_devices->missing_devices will decrease. If fs_devices->missing_devices value hit 0, it would overflow. With added debugging: loop1: detected capacity change from 0 to 20971520 BTRFS: device fsid 56ad51f1-5523-463b-8547-c19486c51ebb devid 1 transid 21 /dev/loop1 scanned by systemd-udevd (2311) loop2: detected capacity change from 0 to 20971520 BTRFS: device fsid 56ad51f1-5523-463b-8547-c19486c51ebb devid 2 transid 17 /dev/loop2 scanned by systemd-udevd (2313) BTRFS info (device loop1): flagging fs with big metadata feature BTRFS info (device loop1): allowing degraded mounts BTRFS info (device loop1): using free space tree BTRFS info (device loop1): has skinny extents BTRFS info (device loop1): before clear_missing.00000000f706684d /dev/loop1 0 BTRFS warning (device loop1): devid 2 uuid 6635ac31-56dd-4852-873b-c60f5e2d53d2 is missing BTRFS info (device loop1): before clear_missing.0000000000000000 /dev/loop2 1 BTRFS info (device loop1): flagging fs with big metadata feature BTRFS info (device loop1): allowing degraded mounts BTRFS info (device loop1): using free space tree BTRFS info (device loop1): has skinny extents BTRFS info (device loop1): before clear_missing.00000000f706684d /dev/loop1 0 BTRFS warning (device loop1): devid 2 uuid 6635ac31-56dd-4852-873b-c60f5e2d53d2 is missing BTRFS info (device loop1): before clear_missing.0000000000000000 /dev/loop2 0 BTRFS info (device loop1): flagging fs with big metadata feature BTRFS info (device loop1): allowing degraded mounts BTRFS info (device loop1): using free space tree BTRFS info (device loop1): has skinny extents BTRFS info (device loop1): before clear_missing.00000000f706684d /dev/loop1 18446744073709551615 BTRFS warning (device loop1): devid 2 uuid 6635ac31-56dd-4852-873b-c60f5e2d53d2 is missing BTRFS info (device loop1): before clear_missing.0000000000000000 /dev/loop2 18446744073709551615 If fs_devices->missing_devices is 0, next time it would be 18446744073709551615 After apply this patch, the fs_devices->missing_devices seems to be right: $ truncate -s 10g test1 $ truncate -s 10g test2 $ losetup /dev/loop1 test1 $ losetup /dev/loop2 test2 $ mkfs.btrfs -draid1 -mraid1 /dev/loop1 /dev/loop2 -f $ losetup -d /dev/loop2 $ mount -o degraded /dev/loop1 /mnt/1 $ umount /mnt/1 $ mount -o degraded /dev/loop1 /mnt/1 $ umount /mnt/1 $ mount -o degraded /dev/loop1 /mnt/1 $ umount /mnt/1 $ dmesg loop1: detected capacity change from 0 to 20971520 loop2: detected capacity change from 0 to 20971520 BTRFS: device fsid 15aa1203-98d3-4a66-bcae-ca82f629c2cd devid 1 transid 5 /dev/loop1 scanned by mkfs.btrfs (1863) BTRFS: device fsid 15aa1203-98d3-4a66-bcae-ca82f629c2cd devid 2 transid 5 /dev/loop2 scanned by mkfs.btrfs (1863) BTRFS info (device loop1): flagging fs with big metadata feature BTRFS info (device loop1): allowing degraded mounts BTRFS info (device loop1): disk space caching is enabled BTRFS info (device loop1): has skinny extents BTRFS info (device loop1): before clear_missing.00000000975bd577 /dev/loop1 0 BTRFS warning (device loop1): devid 2 uuid 8b333791-0b3f-4f57-b449-1c1ab6b51f38 is missing BTRFS info (device loop1): before clear_missing.0000000000000000 /dev/loop2 1 BTRFS info (device loop1): checking UUID tree BTRFS info (device loop1): flagging fs with big metadata feature BTRFS info (device loop1): allowing degraded mounts BTRFS info (device loop1): disk space caching is enabled BTRFS info (device loop1): has skinny extents BTRFS info (device loop1): before clear_missing.00000000975bd577 /dev/loop1 0 BTRFS warning (device loop1): devid 2 uuid 8b333791-0b3f-4f57-b449-1c1ab6b51f38 is missing BTRFS info (device loop1): before clear_missing.0000000000000000 /dev/loop2 1 BTRFS info (device loop1): flagging fs with big metadata feature BTRFS info (device loop1): allowing degraded mounts BTRFS info (device loop1): disk space caching is enabled BTRFS info (device loop1): has skinny extents BTRFS info (device loop1): before clear_missing.00000000975bd577 /dev/loop1 0 BTRFS warning (device loop1): devid 2 uuid 8b333791-0b3f-4f57-b449-1c1ab6b51f38 is missing BTRFS info (device loop1): before clear_missing.0000000000000000 /dev/loop2 1 CC: stable@vger.kernel.org # 4.19+ Signed-off-by: Li Zhang Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f73ba2e80142a1575d0ec6985ccaffa1425f9896 Author: David Yang Date: Thu Oct 28 14:36:36 2021 -0700 tools/testing/selftests/vm/split_huge_page_test.c: fix application of sizeof to pointer [ Upstream commit 9c7516d669e68e94e17203469a873ff5d1d3a41a ] The coccinelle check report: ./tools/testing/selftests/vm/split_huge_page_test.c:344:36-42: ERROR: application of sizeof to pointer Use "strlen" to fix it. Link: https://lkml.kernel.org/r/20211012030116.184027-1-davidcomponentone@gmail.com Signed-off-by: David Yang Reported-by: Zeal Robot Cc: Zi Yan Cc: Shuah Khan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 4bc152c6cd237ede87e7467eb8f3990e05e1ca53 Author: Wen Gu Date: Thu Oct 28 15:13:47 2021 +0800 net/smc: Correct spelling mistake to TCPF_SYN_RECV [ Upstream commit f3a3a0fe0b644582fa5d83dd94b398f99fc57914 ] There should use TCPF_SYN_RECV instead of TCP_SYN_RECV. Signed-off-by: Wen Gu Reviewed-by: Tony Lu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c5f3e2b44a3a9aec8e846114ca9ffdeaf7c31fb5 Author: Tony Lu Date: Thu Oct 28 15:13:45 2021 +0800 net/smc: Fix smc_link->llc_testlink_time overflow [ Upstream commit c4a146c7cf5e8ad76231523b174d161bf152c6e7 ] The value of llc_testlink_time is set to the value stored in net->ipv4.sysctl_tcp_keepalive_time when linkgroup init. The value of sysctl_tcp_keepalive_time is already jiffies, so we don't need to multiply by HZ, which would cause smc_link->llc_testlink_time overflow, and test_link send flood. Signed-off-by: Tony Lu Reviewed-by: Xuan Zhuo Reviewed-by: Wen Gu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0019c6dc00d1d26ac2507fd397c7b6a17de31ae5 Author: Yu Xiao Date: Thu Oct 28 12:00:36 2021 +0200 nfp: bpf: relax prog rejection for mtu check through max_pkt_offset [ Upstream commit 90a881fc352a953f1c8beb61977a2db0818157d4 ] MTU change is refused whenever the value of new MTU is bigger than the max packet bytes that fits in NFP Cluster Target Memory (CTM). However, an eBPF program doesn't always need to access the whole packet data. The maximum direct packet access (DPA) offset has always been caculated by verifier and stored in the max_pkt_offset field of prog aux data. Signed-off-by: Yu Xiao Reviewed-by: Yinjun Zhang Reviewed-by: Niklas Soderlund Signed-off-by: Simon Horman Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f108635d6d2fddbd9dbf22e77473311c36fe3a2d Author: Dongli Zhang Date: Tue Oct 26 14:50:31 2021 -0700 vmxnet3: do not stop tx queues after netif_device_detach() [ Upstream commit 9159f102402a64ac85e676b75cc1f9c62c5b4b73 ] The netif_device_detach() conditionally stops all tx queues if the queues are running. There is no need to call netif_tx_stop_all_queues() again. Signed-off-by: Dongli Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2c8c7971019eff7b31048bc8ce7e518462d8d699 Author: Janghyub Seo Date: Tue Oct 26 07:12:42 2021 +0000 r8169: Add device 10ec:8162 to driver r8169 [ Upstream commit 72f898ca0ab85fde6facf78b14d9f67a4a7b32d1 ] This patch makes the driver r8169 pick up device Realtek Semiconductor Co. , Ltd. Device [10ec:8162]. Signed-off-by: Janghyub Seo Suggested-by: Rushab Shah Link: https://lore.kernel.org/r/1635231849296.1489250046.441294000@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 0fb585017f75c90bc0cf38f718e3fa729a638be8 Author: Guangbin Huang Date: Wed Oct 27 20:11:45 2021 +0800 net: hns3: ignore reset event before initialization process is done [ Upstream commit 0251d196b0e1a19c870be882e5d4f496de8ab758 ] Currently, if there is a reset event triggered by RAS during device in initialization process, driver may run reset process concurrently with initialization process. In this case, it may cause problem. For example, the RSS indirection table may has not been alloc memory in initialization process yet, but it is used in reset process, it will cause a call trace like this: [61228.744836] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 ... [61228.897677] Workqueue: hclgevf hclgevf_service_task [hclgevf] [61228.911390] pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) [61228.918670] pc : hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf] [61228.927812] lr : hclgevf_set_rss_indir_table+0x90/0x190 [hclgevf] [61228.937248] sp : ffff8000162ebb50 [61228.941087] x29: ffff8000162ebb50 x28: ffffb77add72dbc0 x27: ffff0820c7dc8080 [61228.949516] x26: 0000000000000000 x25: ffff0820ad4fc880 x24: ffff0820c7dc8080 [61228.958220] x23: ffff0820c7dc8090 x22: 00000000ffffffff x21: 0000000000000040 [61228.966360] x20: ffffb77add72b9c0 x19: 0000000000000000 x18: 0000000000000030 [61228.974646] x17: 0000000000000000 x16: ffffb77ae713feb0 x15: ffff0820ad4fcce8 [61228.982808] x14: ffffffffffffffff x13: ffff8000962eb7f7 x12: 00003834ec70c960 [61228.991990] x11: 00e0fafa8c206982 x10: 9670facc78a8f9a8 x9 : ffffb77add717530 [61229.001123] x8 : ffff0820ad4fd6b8 x7 : 0000000000000000 x6 : 0000000000000011 [61229.010249] x5 : 00000000000cb1b0 x4 : 0000000000002adb x3 : 0000000000000049 [61229.018662] x2 : ffff8000162ebbb8 x1 : 0000000000000000 x0 : 0000000000000480 [61229.027002] Call trace: [61229.030177] hclgevf_set_rss_indir_table+0xb4/0x190 [hclgevf] [61229.039009] hclgevf_rss_init_hw+0x128/0x1b4 [hclgevf] [61229.046809] hclgevf_reset_rebuild+0x17c/0x69c [hclgevf] [61229.053862] hclgevf_reset_service_task+0x4cc/0xa80 [hclgevf] [61229.061306] hclgevf_service_task+0x6c/0x630 [hclgevf] [61229.068491] process_one_work+0x1dc/0x48c [61229.074121] worker_thread+0x15c/0x464 [61229.078562] kthread+0x168/0x16c [61229.082873] ret_from_fork+0x10/0x18 [61229.088221] Code: 7900e7f6 f904a683 d503201f 9101a3e2 (38616b43) [61229.095357] ---[ end trace 153661a538f6768c ]--- To fix this problem, don't schedule reset task before initialization process is done. Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4294c96432c3238eb4287dea197e320291d77cf5 Author: Yufeng Mo Date: Wed Oct 27 20:11:44 2021 +0800 net: hns3: change hclge/hclgevf workqueue to WQ_UNBOUND mode [ Upstream commit f29da4088fb4eeba457219a931327d1d5f45196a ] Currently, the workqueue of hclge/hclgevf is executed on the CPU that initiates scheduling requests by default. In stress scenarios, the CPU may be busy and workqueue scheduling is completed after a long period of time. To avoid this situation and implement proper scheduling, use the WQ_UNBOUND mode instead. In this way, the workqueue can be performed on a relatively idle CPU. Signed-off-by: Yufeng Mo Signed-off-by: Guangbin Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a61294791f264efccc15ee82898cfafd45d1dc7b Author: Amit Engel Date: Wed Oct 27 09:49:27 2021 +0300 nvmet-tcp: fix header digest verification [ Upstream commit 86aeda32b887cdaeb0f4b7bfc9971e36377181c7 ] Pass the correct length to nvmet_tcp_verify_hdgst, which is the pdu header length. This fixes a wrong behaviour where header digest verification passes although the digest is wrong. Signed-off-by: Amit Engel Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a09a649a767754cff9975844c3d02d1b9c95b88a Author: Naohiro Aota Date: Wed Oct 27 01:51:27 2021 +0900 block: schedule queue restart after BLK_STS_ZONE_RESOURCE [ Upstream commit 9586e67b911c95ba158fcc247b230e9c2d718623 ] When dispatching a zone append write request to a SCSI zoned block device, if the target zone of the request is already locked, the device driver will return BLK_STS_ZONE_RESOURCE and the request will be pushed back to the hctx dipatch queue. The queue will be marked as RESTART in dd_finish_request() and restarted in __blk_mq_free_request(). However, this restart applies to the hctx of the completed request. If the requeued request is on a different hctx, dispatch will no be retried until another request is submitted or the next periodic queue run triggers, leading to up to 30 seconds latency for the requeued request. Fix this problem by scheduling a queue restart similarly to the BLK_STS_RESOURCE case or when we cannot get the budget. Also, consolidate the checks into the "need_resource" variable to simplify the condition. Signed-off-by: Naohiro Aota Reviewed-by: Christoph Hellwig Cc: Niklas Cassel Link: https://lore.kernel.org/r/20211026165127.4151055-1-naohiro.aota@wdc.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 36d8544a88241a3dadcf2a035742c4de790ce6f8 Author: Mario Date: Tue Oct 26 13:27:37 2021 +0200 drm: panel-orientation-quirks: Add quirk for GPD Win3 [ Upstream commit 61b1d445f3bfe4c3ba4335ceeb7e8ba688fd31e2 ] Fixes screen orientation for GPD Win 3 handheld gaming console. Signed-off-by: Mario Risoldi Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211026112737.9181-1-awxkrnl@gmail.com Signed-off-by: Sasha Levin commit c0c99f6c2c2dc8e4bc2038acc66e565a6190e52d Author: Walter Stoll Date: Thu Oct 14 12:22:29 2021 +0200 watchdog: Fix OMAP watchdog early handling [ Upstream commit cd004d8299f1dc6cfa6a4eea8f94cb45eaedf070 ] TI's implementation does not service the watchdog even if the kernel command line parameter omap_wdt.early_enable is set to 1. This patch fixes the issue. Signed-off-by: Walter Stoll Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/88a8fe5229cd68fa0f1fd22f5d66666c1b7057a0.camel@duagon.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 9498f85e5cac8fa3264cd219c783d3dfbb6b34f6 Author: Cyril Strejc Date: Sun Oct 24 22:14:25 2021 +0200 net: multicast: calculate csum of looped-back and forwarded packets [ Upstream commit 9122a70a6333705c0c35614ddc51c274ed1d3637 ] During a testing of an user-space application which transmits UDP multicast datagrams and utilizes multicast routing to send the UDP datagrams out of defined network interfaces, I've found a multicast router does not fill-in UDP checksum into locally produced, looped-back and forwarded UDP datagrams, if an original output NIC the datagrams are sent to has UDP TX checksum offload enabled. The datagrams are sent malformed out of the NIC the datagrams have been forwarded to. It is because: 1. If TX checksum offload is enabled on the output NIC, UDP checksum is not calculated by kernel and is not filled into skb data. 2. dev_loopback_xmit(), which is called solely by ip_mc_finish_output(), sets skb->ip_summed = CHECKSUM_UNNECESSARY unconditionally. 3. Since 35fc92a9 ("[NET]: Allow forwarding of ip_summed except CHECKSUM_COMPLETE"), the ip_summed value is preserved during forwarding. 4. If ip_summed != CHECKSUM_PARTIAL, checksum is not calculated during a packet egress. The minimum fix in dev_loopback_xmit(): 1. Preserves skb->ip_summed CHECKSUM_PARTIAL. This is the case when the original output NIC has TX checksum offload enabled. The effects are: a) If the forwarding destination interface supports TX checksum offloading, the NIC driver is responsible to fill-in the checksum. b) If the forwarding destination interface does NOT support TX checksum offloading, checksums are filled-in by kernel before skb is submitted to the NIC driver. c) For local delivery, checksum validation is skipped as in the case of CHECKSUM_UNNECESSARY, thanks to skb_csum_unnecessary(). 2. Translates ip_summed CHECKSUM_NONE to CHECKSUM_UNNECESSARY. It means, for CHECKSUM_NONE, the behavior is unmodified and is there to skip a looped-back packet local delivery checksum validation. Signed-off-by: Cyril Strejc Reviewed-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 492ee5c41ad0d118d8c3ee11228fd05767459181 Author: Thomas Perrot Date: Fri Oct 22 16:21:04 2021 +0200 spi: spl022: fix Microwire full duplex mode [ Upstream commit d81d0e41ed5fe7229a2c9a29d13bad288c7cf2d2 ] There are missing braces in the function that verify controller parameters, then an error is always returned when the parameter to select Microwire frames operation is used on devices allowing it. Signed-off-by: Thomas Perrot Link: https://lore.kernel.org/r/20211022142104.1386379-1-thomas.perrot@bootlin.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4b133d1b1f485f50edd4aeeaaf2d3054a1c8b818 Author: Maurizio Lombardi Date: Fri Oct 15 10:26:34 2021 +0200 nvmet-tcp: fix a memory leak when releasing a queue [ Upstream commit 926245c7d22271307606c88b1fbb2539a8550e94 ] page_frag_free() won't completely release the memory allocated for the commands, the cache page must be explicitly freed by calling __page_frag_cache_drain(). This bug can be easily reproduced by repeatedly executing the following command on the initiator: $echo 1 > /sys/devices/virtual/nvme-fabrics/ctl/nvme0/reset_controller Signed-off-by: Maurizio Lombardi Reviewed-by: Sagi Grimberg Reviewed-by: John Meneghini Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit c1a4e29fbd7a64c9b042c497bdbd1f6ac94fd85b Author: Dongli Zhang Date: Fri Oct 22 16:31:39 2021 -0700 xen/netfront: stop tx queues during live migration [ Upstream commit 042b2046d0f05cf8124c26ff65dbb6148a4404fb ] The tx queues are not stopped during the live migration. As a result, the ndo_start_xmit() may access netfront_info->queues which is freed by talk_to_netback()->xennet_destroy_queues(). This patch is to netif_device_detach() at the beginning of xen-netfront resuming, and netif_device_attach() at the end of resuming. CPU A CPU B talk_to_netback() -> if (info->queues) xennet_destroy_queues(info); to free netfront_info->queues xennet_start_xmit() to access netfront_info->queues -> err = xennet_create_queues(info, &num_queues); The idea is borrowed from virtio-net. Cc: Joe Jin Signed-off-by: Dongli Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7b0e2228b45b5e34e7efa9d8c52017e0ba3b149b Author: Asmaa Mnebhi Date: Fri Oct 22 09:44:38 2021 -0400 gpio: mlxbf2.c: Add check for bgpio_init failure [ Upstream commit c0eee6fbfa2b3377f1efed10dad539abeb7312aa ] Add a check if bgpio_init fails. Signed-off-by: Asmaa Mnebhi Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 045e201e846dfff6f174da3b70981221e3d1d682 Author: Lorenz Bauer Date: Thu Oct 14 15:25:53 2021 +0100 bpf: Prevent increasing bpf_jit_limit above max [ Upstream commit fadb7ff1a6c2c565af56b4aacdd086b067eed440 ] Restrict bpf_jit_limit to the maximum supported by the arch's JIT. Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211014142554.53120-4-lmb@cloudflare.com Signed-off-by: Sasha Levin commit 1f889b6bb36d22475dbe50d2085978e79ece921a Author: Lorenz Bauer Date: Thu Oct 14 15:25:52 2021 +0100 bpf: Define bpf_jit_alloc_exec_limit for arm64 JIT [ Upstream commit 5d63ae908242f028bd10860cba98450d11c079b8 ] Expose the maximum amount of useable memory from the arm64 JIT. Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211014142554.53120-3-lmb@cloudflare.com Signed-off-by: Sasha Levin commit 589d0c47b3b6e4b24400a7bfc1c199421f581c37 Author: Lorenz Bauer Date: Thu Oct 14 15:25:51 2021 +0100 bpf: Define bpf_jit_alloc_exec_limit for riscv JIT [ Upstream commit 8f04db78e4e36a5d4858ce841a3e9cc3d69bde36 ] Expose the maximum amount of useable memory from the riscv JIT. Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Luke Nelson Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/20211014142554.53120-2-lmb@cloudflare.com Signed-off-by: Sasha Levin commit 24864d828c73982e73c6a57778f96676906a1367 Author: Florian Westphal Date: Thu Oct 21 16:02:47 2021 +0200 fcnal-test: kill hanging ping/nettest binaries on cleanup [ Upstream commit 1f83b835a3eaa5ae4bd825fb07182698bfc243ba ] On my box I see a bunch of ping/nettest processes hanging around after fcntal-test.sh is done. Clean those up before netns deletion. Signed-off-by: Florian Westphal Acked-by: David Ahern Link: https://lore.kernel.org/r/20211021140247.29691-1-fw@strlen.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit a4754c6f2c025806c6b1bcaf17e26cb36b97fc6e Author: Bryant Mairs Date: Tue Oct 19 09:24:33 2021 -0500 drm: panel-orientation-quirks: Add quirk for Aya Neo 2021 [ Upstream commit def0c3697287f6e85d5ac68b21302966c95474f9 ] Fixes screen orientation for the Aya Neo 2021 handheld gaming console. Signed-off-by: Bryant Mairs Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20211019142433.4295-1-bryant@mai.rs Signed-off-by: Sasha Levin commit dc93fe4bcffb58041140bbdc5fdebaf4af34a000 Author: Russ Weight Date: Mon Oct 18 17:24:01 2021 -0700 spi: altera: Change to dynamic allocation of spi id [ Upstream commit f09f6dfef8ce7b70a240cf83811e2b1909c3e47b ] The spi-altera driver has two flavors: platform and dfl. I'm seeing a case where I have both device types in the same machine, and they are conflicting on the SPI ID: ... kernel: couldn't get idr ... kernel: WARNING: CPU: 28 PID: 912 at drivers/spi/spi.c:2920 spi_register_controller.cold+0x84/0xc0a Both the platform and dfl drivers use the parent's driver ID as the SPI ID. In the error case, the parent devices are dfl_dev.4 and subdev_spi_altera.4.auto. When the second spi-master is created, the failure occurs because the SPI ID of 4 has already been allocated. Change the ID allocation to dynamic (by initializing bus_num to -1) to avoid duplicate SPI IDs. Signed-off-by: Russ Weight Link: https://lore.kernel.org/r/20211019002401.24041-1-russell.h.weight@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4916836b835e2059eed4caaa22087f3f469a2b3e Author: Randy Dunlap Date: Sun Oct 17 10:59:49 2021 -0700 mmc: winbond: don't build on M68K [ Upstream commit 162079f2dccd02cb4b6654defd32ca387dd6d4d4 ] The Winbond MMC driver fails to build on ARCH=m68k so prevent that build config. Silences these build errors: ../drivers/mmc/host/wbsd.c: In function 'wbsd_request_end': ../drivers/mmc/host/wbsd.c:212:28: error: implicit declaration of function 'claim_dma_lock' [-Werror=implicit-function-declaration] 212 | dmaflags = claim_dma_lock(); ../drivers/mmc/host/wbsd.c:215:17: error: implicit declaration of function 'release_dma_lock'; did you mean 'release_task'? [-Werror=implicit-function-declaration] 215 | release_dma_lock(dmaflags); Signed-off-by: Randy Dunlap Cc: Pierre Ossman Cc: Geert Uytterhoeven Cc: Arnd Bergmann Link: https://lore.kernel.org/r/20211017175949.23838-1-rdunlap@infradead.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 315f06005ed7a23f2ce5051b1e936def54bbb818 Author: Paweł Anikiel Date: Mon Sep 20 14:41:41 2021 +0200 reset: socfpga: add empty driver allowing consumers to probe [ Upstream commit 3ad60b4b3570937f3278509fe6797a5093ce53f8 ] The early reset driver doesn't ever probe, which causes consuming devices to be unable to probe. Add an empty driver to set this device as available, allowing consumers to probe. Signed-off-by: Paweł Anikiel Link: https://lore.kernel.org/r/20210920124141.1166544-4-pan@semihalf.com Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit 6010e9d34c8957b0ef12025acff48521f2d870de Author: Bastien Roucariès Date: Thu Sep 16 08:17:21 2021 +0000 ARM: dts: sun7i: A20-olinuxino-lime2: Fix ethernet phy-mode [ Upstream commit 55dd7e059098ce4bd0a55c251cb78e74604abb57 ] Commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config") sets the RX/TX delay according to the phy-mode property in the device tree. For the A20-olinuxino-lime2 board this is "rgmii", which is the wrong setting. Following the example of a900cac3750b ("ARM: dts: sun7i: a20: bananapro: Fix ethernet phy-mode") the phy-mode is changed to "rgmii-id" which gets the Ethernet working again on this board. Signed-off-by: Bastien Roucariès Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210916081721.237137-1-rouca@debian.org Signed-off-by: Sasha Levin commit 9068b17616de9a88e90ba286b074b0bd8c5831dd Author: Arnd Bergmann Date: Mon Oct 18 15:19:08 2021 +0200 hyperv/vmbus: include linux/bitops.h [ Upstream commit 8017c99680fa65e1e8d999df1583de476a187830 ] On arm64 randconfig builds, hyperv sometimes fails with this error: In file included from drivers/hv/hv_trace.c:3: In file included from drivers/hv/hyperv_vmbus.h:16: In file included from arch/arm64/include/asm/sync_bitops.h:5: arch/arm64/include/asm/bitops.h:11:2: error: only can be included directly In file included from include/asm-generic/bitops/hweight.h:5: include/asm-generic/bitops/arch_hweight.h:9:9: error: implicit declaration of function '__sw_hweight32' [-Werror,-Wimplicit-function-declaration] include/asm-generic/bitops/atomic.h:17:7: error: implicit declaration of function 'BIT_WORD' [-Werror,-Wimplicit-function-declaration] Include the correct header first. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20211018131929.2260087-1-arnd@kernel.org Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit b84379371620bdc5237fae5189df1e8ae10efd92 Author: Erik Ekman Date: Wed Oct 20 00:40:16 2021 +0200 sfc: Don't use netif_info before net_device setup [ Upstream commit bf6abf345dfa77786aca554bc58c64bd428ecb1d ] Use pci_info instead to avoid unnamed/uninitialized noise: [197088.688729] sfc 0000:01:00.0: Solarflare NIC detected [197088.690333] sfc 0000:01:00.0: Part Number : SFN5122F [197088.729061] sfc 0000:01:00.0 (unnamed net_device) (uninitialized): no SR-IOV VFs probed [197088.729071] sfc 0000:01:00.0 (unnamed net_device) (uninitialized): no PTP support Inspired by fa44821a4ddd ("sfc: don't use netif_info et al before net_device is registered") from Heiner Kallweit. Signed-off-by: Erik Ekman Acked-by: Martin Habets Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c25ad465426705c4f979fbb1bebaeacac6a5c2c Author: Erik Ekman Date: Tue Oct 19 23:13:32 2021 +0200 sfc: Export fibre-specific supported link modes [ Upstream commit c62041c5baa9ded3bc6fd38d3f724de70683b489 ] The 1/10GbaseT modes were set up for cards with SFP+ cages in 3497ed8c852a5 ("sfc: report supported link speeds on SFP connections"). 10GbaseT was likely used since no 10G fibre mode existed. The missing fibre modes for 1/10G were added to ethtool.h in 5711a9822144 ("net: ethtool: add support for 1000BaseX and missing 10G link modes") shortly thereafter. The user guide available at https://support-nic.xilinx.com/wp/drivers lists support for the following cable and transceiver types in section 2.9: - QSFP28 100G Direct Attach Cables - QSFP28 100G SR Optical Transceivers (with SR4 modules listed) - SFP28 25G Direct Attach Cables - SFP28 25G SR Optical Transceivers - QSFP+ 40G Direct Attach Cables - QSFP+ 40G Active Optical Cables - QSFP+ 40G SR4 Optical Transceivers - QSFP+ to SFP+ Breakout Direct Attach Cables - QSFP+ to SFP+ Breakout Active Optical Cables - SFP+ 10G Direct Attach Cables - SFP+ 10G SR Optical Transceivers - SFP+ 10G LR Optical Transceivers - SFP 1000BASE‐T Transceivers - 1G Optical Transceivers (From user guide issue 28. Issue 16 which also includes older cards like SFN5xxx/SFN6xxx has matching lists for 1/10/40G transceiver types.) Regarding SFP+ 10GBASE‐T transceivers the latest guide says: "Solarflare adapters do not support 10GBASE‐T transceiver modules." Tested using SFN5122F-R7 (with 2 SFP+ ports). Supported link modes do not change depending on module used (tested with 1000BASE-T, 1000BASE-BX10, 10GBASE-LR). Before: $ ethtool ext Settings for ext: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 10000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Link partner advertised link modes: Not reported Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: off Port: FIBRE PHYAD: 255 Transceiver: internal Current message level: 0x000020f7 (8439) drv probe link ifdown ifup rx_err tx_err hw Link detected: yes After: $ ethtool ext Settings for ext: Supported ports: [ FIBRE ] Supported link modes: 1000baseT/Full 1000baseX/Full 10000baseCR/Full 10000baseSR/Full 10000baseLR/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: Not reported Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Link partner advertised link modes: Not reported Link partner advertised pause frame use: No Link partner advertised auto-negotiation: No Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: off Port: FIBRE PHYAD: 255 Transceiver: internal Supports Wake-on: g Wake-on: d Current message level: 0x000020f7 (8439) drv probe link ifdown ifup rx_err tx_err hw Link detected: yes Signed-off-by: Erik Ekman Acked-by: Martin Habets Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 83cc3d21cbcd777d93fdbed83b9a57d192266d67 Author: Zheyu Ma Date: Mon Oct 18 14:32:57 2021 +0000 cavium: Fix return values of the probe function [ Upstream commit c69b2f46876825c726bd8a97c7fa852d8932bc32 ] During the process of driver probing, the probe function should return < 0 for failure, otherwise, the kernel will treat value > 0 as success. Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ee25673d8fae7184b6a8701b6c2b42e1b4469f55 Author: Zheyu Ma Date: Mon Oct 18 14:20:38 2021 +0000 mISDN: Fix return values of the probe function [ Upstream commit e211210098cb7490db2183d725f5c0f10463a704 ] During the process of driver probing, the probe function should return < 0 for failure, otherwise, the kernel will treat value > 0 as success. Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 77fe2d67962bd4286a4faedac1682038cbfe2a92 Author: Dmitry Bogdanov Date: Mon Oct 18 15:26:50 2021 +0300 scsi: qla2xxx: Fix unmap of already freed sgl [ Upstream commit 4a8f71014b4d56c4fb287607e844c0a9f68f46d9 ] The sgl is freed in the target stack in target_release_cmd_kref() before calling qlt_free_cmd() but there is an unmap of sgl in qlt_free_cmd() that causes a panic if sgl is not yet DMA unmapped: NIP dma_direct_unmap_sg+0xdc/0x180 LR dma_direct_unmap_sg+0xc8/0x180 Call Trace: ql_dbg_prefix+0x68/0xc0 [qla2xxx] (unreliable) dma_unmap_sg_attrs+0x54/0xf0 qlt_unmap_sg.part.19+0x54/0x1c0 [qla2xxx] qlt_free_cmd+0x124/0x1d0 [qla2xxx] tcm_qla2xxx_release_cmd+0x4c/0xa0 [tcm_qla2xxx] target_put_sess_cmd+0x198/0x370 [target_core_mod] transport_generic_free_cmd+0x6c/0x1b0 [target_core_mod] tcm_qla2xxx_complete_free+0x6c/0x90 [tcm_qla2xxx] The sgl may be left unmapped in error cases of response sending. For instance, qlt_rdy_to_xfer() maps sgl and exits when session is being deleted keeping the sgl mapped. This patch removes use-after-free of the sgl and ensures that the sgl is unmapped for any command that was not sent to firmware. Link: https://lore.kernel.org/r/20211018122650.11846-1-d.bogdanov@yadro.com Reviewed-by: Himanshu Madhani Signed-off-by: Dmitry Bogdanov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 54aaf0fddfcdc6a8023170fe050012f09d1a89aa Author: Zheyu Ma Date: Mon Oct 18 01:56:21 2021 +0000 scsi: qla2xxx: Return -ENOMEM if kzalloc() fails [ Upstream commit 06634d5b6e923ed0d4772aba8def5a618f44c7fe ] The driver probing function should return < 0 for failure, otherwise kernel will treat value > 0 as success. Link: https://lore.kernel.org/r/1634522181-31166-1-git-send-email-zheyuma97@gmail.com Reviewed-by: Himanshu Madhani Signed-off-by: Zheyu Ma Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7cc5b87e86a1e084f859cb2114d288e66b1e92ed Author: Zheyu Ma Date: Mon Oct 18 02:16:22 2021 +0000 cavium: Return negative value when pci_alloc_irq_vectors() fails [ Upstream commit b2cddb44bddc1a9c5949a978bb454bba863264db ] During the process of driver probing, the probe function should return < 0 for failure, otherwise, the kernel will treat value > 0 as success. Signed-off-by: Zheyu Ma Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7958b5d479b050be87e20dcb244e7d4e3a71aa6f Author: Wan Jiabing Date: Sun Oct 17 21:32:32 2021 -0400 net: mscc: ocelot: Add of_node_put() before goto [ Upstream commit d1a7b9e4696584ce05c12567762c18a866837a85 ] Fix following coccicheck warning: ./drivers/net/ethernet/mscc/ocelot_vsc7514.c:946:1-33: WARNING: Function for_each_available_child_of_node should have of_node_put() before goto. Early exits from for_each_available_child_of_node should decrement the node reference counter. Signed-off-by: Wan Jiabing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3f7c0466d4dc5417211f29353059f6188d65c0c8 Author: Wan Jiabing Date: Sun Oct 17 21:31:30 2021 -0400 net: sparx5: Add of_node_put() before goto [ Upstream commit d9fd7e9fccfac466fb528a783f2fc76f2982604c ] Fix following coccicheck warning: ./drivers/net/ethernet/microchip/sparx5/s4parx5_main.c:723:1-33: WARNING: Function for_each_available_child_of_node should have of_node_put() before goto Early exits from for_each_available_child_of_node should decrement the node reference counter. Signed-off-by: Wan Jiabing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5586508b6c21eee1669836dbb5513f1e2401641b Author: Kele Huang Date: Thu Oct 14 11:19:52 2021 +0800 ptp: fix error print of ptp_kvm on X86_64 platform [ Upstream commit c2402d43d183b11445aed921e7bebcd47ef222f1 ] Commit a86ed2cfa13c5 ("ptp: Don't print an error if ptp_kvm is not supported") fixes the error message print on ARM platform by only concerning about the case that the error returned from kvm_arch_ptp_init() is not -EOPNOTSUPP. Although the ARM platform returns -EOPNOTSUPP if ptp_kvm is not supported while X86_64 platform returns -KVM_EOPNOTSUPP, both error codes share the same value 95. Actually kvm_arch_ptp_init() on X86_64 platform can return three kinds of errors (-KVM_ENOSYS, -KVM_EOPNOTSUPP and -KVM_EFAULT). The problem is that -KVM_EOPNOTSUPP is masked out and -KVM_EFAULT is ignored among them. This patch fixes this by returning them to ptp_kvm_init() respectively. Signed-off-by: Kele Huang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b1d56535789939115d42781b0adcf471dcebe93b Author: Davide Baldo Date: Fri Oct 15 09:21:22 2021 +0200 ALSA: hda/realtek: Fixes HP Spectre x360 15-eb1xxx speakers [ Upstream commit d94befbb5ae379f6dfd4fa6d460eacc09fa7b9c3 ] In laptop 'HP Spectre x360 Convertible 15-eb1xxx/8811' both front and rear speakers are silent, this patch fixes that by overriding the pin layout and by initializing the amplifier which needs a GPIO pin to be set to 1 then 0, similar to the existing HP Spectre x360 14 model. In order to have volume control, both front and rear speakers were forced to use the DAC1. This patch also correctly map the mute LED but since there is no microphone on/off switch exposed by the alsa subsystem it never turns on by itself. There are still known audio issues in this laptop: headset microphone doesn't work, the button to mute/unmute microphone is not yet mapped, the LED of the mute/unmute speakers doesn't seems to be exposed via GPIO and never turns on. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=213953 Signed-off-by: Davide Baldo Link: https://lore.kernel.org/r/20211015072121.5287-1-davide@baldo.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0529cf90b489dbe0ddcf95de584aec086170b761 Author: Stefan Binding Date: Mon Oct 11 15:49:03 2021 +0100 ASoC: cs42l42: Ensure 0dB full scale volume is used for headsets [ Upstream commit aa18457c4af7a9dad1f2b150b11beae1d8ab57aa ] Ensure the default 0dB playback path is always used. The code that set FULL_SCALE_VOL based on LOAD_DET_RCSTAT was spurious, and resulted in a -6dB attenuation being accidentally inserted into the playback path. Signed-off-by: Stefan Binding Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/20211011144903.28915-1-rf@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a1cd1d08acb42577e8460c26c4b96a913a994533 Author: Yang Yingliang Date: Sat Oct 9 14:58:40 2021 +0800 ASoC: soc-core: fix null-ptr-deref in snd_soc_del_component_unlocked() [ Upstream commit c448b7aa3e66042fc0f849d9a0fb90d1af82e948 ] 'component' is allocated in snd_soc_register_component(), but component->list is not initalized, this may cause snd_soc_del_component_unlocked() deref null ptr in the error handing case. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:__list_del_entry_valid+0x81/0xf0 Call Trace: snd_soc_del_component_unlocked+0x69/0x1b0 [snd_soc_core] snd_soc_add_component.cold+0x54/0x6c [snd_soc_core] snd_soc_register_component+0x70/0x90 [snd_soc_core] devm_snd_soc_register_component+0x5e/0xd0 [snd_soc_core] tas2552_probe+0x265/0x320 [snd_soc_tas2552] ? tas2552_component_probe+0x1e0/0x1e0 [snd_soc_tas2552] i2c_device_probe+0xa31/0xbe0 Fix by adding INIT_LIST_HEAD() to snd_soc_component_initialize(). Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20211009065840.3196239-1-yangyingliang@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 093801ba8fe699233e13ca5db65c9dc7fcc0b5ba Author: Quentin Perret Date: Tue Oct 5 10:01:42 2021 +0100 KVM: arm64: Report corrupted refcount at EL2 [ Upstream commit 7615c2a514788559c6684234b8fc27f3a843c2c6 ] Some of the refcount manipulation helpers used at EL2 are instrumented to catch a corrupted state, but not all of them are treated equally. Let's make things more consistent by instrumenting hyp_page_ref_dec_and_test() as well. Acked-by: Will Deacon Suggested-by: Will Deacon Signed-off-by: Quentin Perret Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20211005090155.734578-6-qperret@google.com Signed-off-by: Sasha Levin commit b466d8ef1233ced66d168452c9ae8b8b94fc4460 Author: Peter Zijlstra Date: Fri Sep 17 11:20:04 2021 +0200 x86/iopl: Fake iopl(3) CLI/STI usage commit b968e84b509da593c50dc3db679e1d33de701f78 upstream. Since commit c8137ace5638 ("x86/iopl: Restrict iopl() permission scope") it's possible to emulate iopl(3) using ioperm(), except for the CLI/STI usage. Userspace CLI/STI usage is very dubious (read broken), since any exception taken during that window can lead to rescheduling anyway (or worse). The IOPL(2) manpage even states that usage of CLI/STI is highly discouraged and might even crash the system. Of course, that won't stop people and HP has the dubious honour of being the first vendor to be found using this in their hp-health package. In order to enable this 'software' to still 'work', have the #GP treat the CLI/STI instructions as NOPs when iopl(3). Warn the user that their program is doing dubious things. Fixes: a24ca9976843 ("x86/iopl: Remove legacy IOPL option") Reported-by: Ondrej Zary Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Thomas Gleixner Cc: stable@kernel.org # v5.5+ Link: https://lkml.kernel.org/r/20210918090641.GD5106@worktop.programming.kicks-ass.net Signed-off-by: Greg Kroah-Hartman commit bfa448e241cd6e37fd54ec1c24b0ca33a2ba18dd Author: Sean Christopherson Date: Fri Oct 8 17:11:04 2021 -0700 x86/irq: Ensure PI wakeup handler is unregistered before module unload commit 6ff53f6a438f72998f56e82e76694a1df9d1ea2c upstream. Add a synchronize_rcu() after clearing the posted interrupt wakeup handler to ensure all readers, i.e. in-flight IRQ handlers, see the new handler before returning to the caller. If the caller is an exiting module and is unregistering its handler, failure to wait could result in the IRQ handler jumping into an unloaded module. The registration path doesn't require synchronization, as it's the caller's responsibility to not generate interrupts it cares about until after its handler is registered. Fixes: f6b3c72c2366 ("x86/irq: Define a global vector for VT-d Posted-Interrupts") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20211009001107.3936588-2-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 38ce12ffb27f52116deb6b95a367413e11689073 Author: Jane Malalane Date: Thu Oct 21 11:47:44 2021 +0100 x86/cpu: Fix migration safety with X86_BUG_NULL_SEL commit 415de44076640483648d6c0f6d645a9ee61328ad upstream. Currently, Linux probes for X86_BUG_NULL_SEL unconditionally which makes it unsafe to migrate in a virtualised environment as the properties across the migration pool might differ. To be specific, the case which goes wrong is: 1. Zen1 (or earlier) and Zen2 (or later) in a migration pool 2. Linux boots on Zen2, probes and finds the absence of X86_BUG_NULL_SEL 3. Linux is then migrated to Zen1 Linux is now running on a X86_BUG_NULL_SEL-impacted CPU while believing that the bug is fixed. The only way to address the problem is to fully trust the "no longer affected" CPUID bit when virtualised, because in the above case it would be clear deliberately to indicate the fact "you might migrate to somewhere which has this behaviour". Zen3 adds the NullSelectorClearsBase CPUID bit to indicate that loading a NULL segment selector zeroes the base and limit fields, as well as just attributes. Zen2 also has this behaviour but doesn't have the NSCB bit. [ bp: Minor touchups. ] Signed-off-by: Jane Malalane Signed-off-by: Borislav Petkov CC: Link: https://lkml.kernel.org/r/20211021104744.24126-1-jane.malalane@citrix.com Signed-off-by: Greg Kroah-Hartman commit d61cc6067d08b0c5fd7b2bc1ba3d54347a98f0ea Author: Tom Lendacky Date: Fri Oct 15 12:24:16 2021 -0500 x86/sme: Use #define USE_EARLY_PGTABLE_L5 in mem_encrypt_identity.c commit e7d445ab26db833d6640d4c9a08bee176777cc82 upstream. When runtime support for converting between 4-level and 5-level pagetables was added to the kernel, the SME code that built pagetables was updated to use the pagetable functions, e.g. p4d_offset(), etc., in order to simplify the code. However, the use of the pagetable functions in early boot code requires the use of the USE_EARLY_PGTABLE_L5 #define in order to ensure that the proper definition of pgtable_l5_enabled() is used. Without the #define, pgtable_l5_enabled() is #defined as cpu_feature_enabled(X86_FEATURE_LA57). In early boot, the CPU features have not yet been discovered and populated, so pgtable_l5_enabled() will return false even when 5-level paging is enabled. This causes the SME code to always build 4-level pagetables to perform the in-place encryption. If 5-level paging is enabled, switching to the SME pagetables results in a page-fault that kills the boot. Adding the #define results in pgtable_l5_enabled() using the __pgtable_l5_enabled variable set in early boot and the SME code building pagetables for the proper paging level. Fixes: aad983913d77 ("x86/mm/encrypt: Simplify sme_populate_pgd() and sme_populate_pgd_large()") Signed-off-by: Tom Lendacky Signed-off-by: Borislav Petkov Acked-by: Kirill A. Shutemov Cc: # 4.18.x Link: https://lkml.kernel.org/r/2cb8329655f5c753905812d951e212022a480475.1634318656.git.thomas.lendacky@amd.com Signed-off-by: Greg Kroah-Hartman commit 78f5cc4a32610509fce9ed89ac05c2c25fcd6fd4 Author: Miklos Szeredi Date: Tue Nov 2 11:10:37 2021 +0100 fuse: fix page stealing commit 712a951025c0667ff00b25afc360f74e639dfabe upstream. It is possible to trigger a crash by splicing anon pipe bufs to the fuse device. The reason for this is that anon_pipe_buf_release() will reuse buf->page if the refcount is 1, but that page might have already been stolen and its flags modified (e.g. PG_lru added). This happens in the unlikely case of fuse_dev_splice_write() getting around to calling pipe_buf_release() after a page has been stolen, added to the page cache and removed from the page cache. Fix by calling pipe_buf_release() right after the page was inserted into the page cache. In this case the page has an elevated refcount so any release function will know that the page isn't reusable. Reported-by: Frank Dinoff Link: https://lore.kernel.org/r/CAAmZXrsGg2xsP1CK+cbuEMumtrqdvD-NKnWzhNcvn71RV3c1yw@mail.gmail.com/ Fixes: dd3bb14f44a6 ("fuse: support splice() writing to fuse device") Cc: # v2.6.35 Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit 521423148dfe26ebe8ee832d9e956e48c4ed0897 Author: yangerkun Date: Fri Sep 3 14:27:48 2021 +0800 ext4: refresh the ext4_ext_path struct after dropping i_data_sem. commit 1811bc401aa58c7bdb0df3205aa6613b49d32127 upstream. After we drop i_data sem, we need to reload the ext4_ext_path structure since the extent tree can change once i_data_sem is released. This addresses the BUG: [52117.465187] ------------[ cut here ]------------ [52117.465686] kernel BUG at fs/ext4/extents.c:1756! ... [52117.478306] Call Trace: [52117.478565] ext4_ext_shift_extents+0x3ee/0x710 [52117.479020] ext4_fallocate+0x139c/0x1b40 [52117.479405] ? __do_sys_newfstat+0x6b/0x80 [52117.479805] vfs_fallocate+0x151/0x4b0 [52117.480177] ksys_fallocate+0x4a/0xa0 [52117.480533] __x64_sys_fallocate+0x22/0x30 [52117.480930] do_syscall_64+0x35/0x80 [52117.481277] entry_SYSCALL_64_after_hwframe+0x44/0xae [52117.481769] RIP: 0033:0x7fa062f855ca Cc: stable@kernel.org Link: https://lore.kernel.org/r/20210903062748.4118886-4-yangerkun@huawei.com Signed-off-by: yangerkun Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 54939d4ce87cd278ddcd5525e65c2f5008e0c0ff Author: yangerkun Date: Fri Sep 3 14:27:47 2021 +0800 ext4: ensure enough credits in ext4_ext_shift_path_extents commit 4268496e48dc681cfa53b92357314b5d7221e625 upstream. Like ext4_ext_rm_leaf, we can ensure that there are enough credits before every call that will consume credits. As part of this fix we fold the functionality of ext4_access_path() into ext4_ext_shift_path_extents(). This change is needed as a preparation for the next bugfix patch. Cc: stable@kernel.org Link: https://lore.kernel.org/r/20210903062748.4118886-3-yangerkun@huawei.com Signed-off-by: yangerkun Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 11768f7391bab2a32729a355abfb8de6b1209f9c Author: Shaoying Xu Date: Thu Sep 2 16:44:12 2021 +0000 ext4: fix lazy initialization next schedule time computation in more granular unit commit 39fec6889d15a658c3a3ebb06fd69d3584ddffd3 upstream. Ext4 file system has default lazy inode table initialization setup once it is mounted. However, it has issue on computing the next schedule time that makes the timeout same amount in jiffies but different real time in secs if with various HZ values. Therefore, fix by measuring the current time in a more granular unit nanoseconds and make the next schedule time independent of the HZ value. Fixes: bfff68738f1c ("ext4: add support for lazy inode table initialization") Signed-off-by: Shaoying Xu Cc: stable@vger.kernel.org Signed-off-by: Theodore Ts'o Link: https://lore.kernel.org/r/20210902164412.9994-2-shaoyi@amazon.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 3d96ccb1ef2a74ddf7440469eaebb1dc33972fd5 Author: Takashi Iwai Date: Fri Nov 5 10:15:17 2021 +0100 ALSA: timer: Unconditionally unlink slave instances, too commit ffdd98277f0a1d15a67a74ae09bee713df4c0dbc upstream. Like the previous fix (commit c0317c0e8709 "ALSA: timer: Fix use-after-free problem"), we have to unlink slave timer instances immediately at snd_timer_stop(), too. Otherwise it may leave a stale entry in the list if the slave instance is freed before actually running. Cc: Link: https://lore.kernel.org/r/20211105091517.21733-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 147405da05f59aa9c2b97ba4b70d10f3aa81d6b3 Author: Wang Wensheng Date: Wed Nov 3 03:35:17 2021 +0000 ALSA: timer: Fix use-after-free problem commit c0317c0e87094f5b5782b6fdef5ae0a4b150496c upstream. When the timer instance was add into ack_list but was not currently in process, the user could stop it via snd_timer_stop1() without delete it from the ack_list. Then the user could free the timer instance and when it was actually processed UAF occurred. This issue could be reproduced via testcase snd_timer01 in ltp - running several instances of that testcase at the same time. What I actually met was that the ack_list of the timer broken and the kernel went into deadloop with irqoff. That could be detected by hardlockup detector on board or when we run it on qemu, we could use gdb to dump the ack_list when the console has no response. To fix this issue, we delete the timer instance from ack_list and active_list unconditionally in snd_timer_stop1(). Signed-off-by: Wang Wensheng Suggested-by: Takashi Iwai Cc: Link: https://lore.kernel.org/r/20211103033517.80531-1-wangwensheng4@huawei.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a493519fd98d14da8847c0361ee3d64b5a81e270 Author: Takashi Iwai Date: Sun Nov 7 17:39:11 2021 +0100 ALSA: PCM: Fix NULL dereference at mmap checks commit 8e537d5dec34cac746dd6abf6a83e5de3aa471fc upstream. The recent refactoring of mmap handling caused Oops on some devices that don't use the standard memory allocations. This patch addresses it by allowing snd_dma_buffer_mmap() helper to receive the NULL pointer dmab argument (and return an error appropriately). Fixes: a202bd1ad86d ("ALSA: core: Move mmap handler into memalloc ops") Cc: Link: https://lore.kernel.org/r/20211107163911.13534-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 975cc931416235acedb6cb232a15a4de7338e5d7 Author: Austin Kim Date: Tue Nov 9 00:37:42 2021 +0000 ALSA: synth: missing check for possible NULL after the call to kstrdup commit d159037abbe3412285c271bdfb9cdf19e62678ff upstream. If kcalloc() return NULL due to memory starvation, it is possible for kstrdup() to return NULL in similar case. So add null check after the call to kstrdup() is made. [ minor coding-style fix by tiwai ] Signed-off-by: Austin Kim Cc: Link: https://lore.kernel.org/r/20211109003742.GA5423@raspberrypi Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b6cb248aaa9acc6ac603331b05289bc04ef1530f Author: Takashi Iwai Date: Wed Nov 10 20:46:33 2021 +0100 ALSA: hda: Free card instance properly at probe errors commit 39173303c83859723dab32c2abfb97296d6af3bf upstream. The recent change in hda-intel driver to allow repeated probes surfaced a problem that has been hidden until; the probe process in the work calls azx_free() at the error path, and this skips the card free process that eventually releases codec instances. As a result, we get a kernel WARNING like: snd_hda_intel 0000:00:1f.3: Cannot probe codecs, giving up ------------[ cut here ]------------ WARNING: CPU: 14 PID: 186 at sound/hda/hdac_bus.c:73 .... For fixing this, we need to call snd_card_free() instead of azx_free(). Additionally, the device drvdata has to be cleared, as the driver binding itself is still active. Then the PM and other driver callbacks will ignore the procedure. Fixes: c0f1886de7e1 ("ALSA: hda: intel: Allow repeatedly probing on codec configuration errors") Reported-and-tested-by: Scott Branden Cc: Link: https://lore.kernel.org/r/063e2397-7edb-5f48-7b0d-618b938d9dd8@broadcom.com Link: https://lore.kernel.org/r/20211110194633.19098-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e266789d812259692c9ee5be2ab7a76c0fadd8ec Author: Alexander Tsoy Date: Sat Oct 30 20:43:08 2021 +0300 ALSA: usb-audio: Add registration quirk for JBL Quantum 400 commit 763d92ed5dece7d439fc28a88b2d2728d525ffd9 upstream. Add another device ID for JBL Quantum 400. It requires the same quirk as other JBL Quantum devices. Signed-off-by: Alexander Tsoy Cc: Link: https://lore.kernel.org/r/20211030174308.1011825-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3c71ff248ac6fe7b9d28d4999898dc61b4fd48bb Author: Jason Ormes Date: Sat Oct 30 15:04:05 2021 -0500 ALSA: usb-audio: Line6 HX-Stomp XL USB_ID for 48k-fixed quirk commit 8f27b689066113a3e579d4df171c980c54368c4e upstream. Adding the Line6 HX-Stomp XL USB_ID as it needs this fixed frequency quirk as well. The device is basically just the HX-Stomp with some more buttons on the face. I've done some recording with it after adding it, and it seems to function properly with this fix. The Midi features appear to be working as well. [ a coding style fix and patch reformat by tiwai ] Signed-off-by: Jason Ormes Cc: Link: https://lore.kernel.org/r/20211030200405.1358678-1-skryking@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 4b2f167789cdf004f69a8505c68278e1f1ae4f66 Author: Pavel Skripkin Date: Sun Oct 24 17:03:15 2021 +0300 ALSA: mixer: fix deadlock in snd_mixer_oss_set_volume commit 3ab7992018455ac63c33e9b3eaa7264e293e40f4 upstream. In commit 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots") added mutex protection in snd_mixer_oss_set_volume(). Second mutex_lock() in same function looks like typo, fix it. Reported-by: syzbot+ace149a75a9a0a399ac7@syzkaller.appspotmail.com Fixes: 411cef6adfb3 ("ALSA: mixer: oss: Fix racy access to slots") Cc: Signed-off-by: Pavel Skripkin Link: https://lore.kernel.org/r/20211024140315.16704-1-paskripkin@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0b879c816c0deafb3323e6f9093841c0440be2b9 Author: Takashi Iwai Date: Wed Oct 20 18:48:46 2021 +0200 ALSA: mixer: oss: Fix racy access to slots commit 411cef6adfb38a5bb6bd9af3941b28198e7fb680 upstream. The OSS mixer can reassign the mapping slots dynamically via proc file. Although the addition and deletion of those slots are protected by mixer->reg_mutex, the access to slots aren't, hence this may cause UAF when the slots in use are deleted concurrently. This patch applies the mixer->reg_mutex in all appropriate code paths (i.e. the ioctl functions) that may access slots. Reported-by: syzbot+9988f17cf72a1045a189@syzkaller.appspotmail.com Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/00000000000036adc005ceca9175@google.com Link: https://lore.kernel.org/r/20211020164846.922-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 3ab56cd15d22f0b4309424d9482f98e3c67100b9 Author: Johan Hovold Date: Mon Oct 25 14:11:42 2021 +0200 ALSA: line6: fix control and interrupt message timeouts commit f4000b58b64344871d7b27c05e73932f137cfef6 upstream. USB control and interrupt message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 705ececd1c60 ("Staging: add line6 usb driver") Cc: stable@vger.kernel.org # 2.6.30 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211025121142.6531-3-johan@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c725f34ab9822d3bef51219155c779eb585d0dcb Author: Johan Hovold Date: Mon Oct 25 14:11:41 2021 +0200 ALSA: 6fire: fix control and bulk message timeouts commit 9b371c6cc37f954360989eec41c2ddc5a6b83917 upstream. USB control and bulk message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: c6d43ba816d1 ("ALSA: usb/6fire - Driver for TerraTec DMX 6Fire USB") Cc: stable@vger.kernel.org # 2.6.39 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211025121142.6531-2-johan@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9bdf3120931f114fedb0b3ea25362df302d08018 Author: Johan Hovold Date: Tue Oct 26 11:54:01 2021 +0200 ALSA: ua101: fix division by zero at probe commit 55f261b73a7e1cb254577c3536cef8f415de220a upstream. Add the missing endpoint max-packet sanity check to probe() to avoid division by zero in alloc_stream_buffers() in case a malicious device has broken descriptors (or when doing descriptor fuzz testing). Note that USB core will reject URBs submitted for endpoints with zero wMaxPacketSize but that drivers doing packet-size calculations still need to handle this (cf. commit 2548288b4fb0 ("USB: Fix: Don't skip endpoint descriptors with maxpacket=0")). Fixes: 63978ab3e3e9 ("sound: add Edirol UA-101 support") Cc: stable@vger.kernel.org # 2.6.34 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20211026095401.26522-1-johan@kernel.org Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 733de916ec6b6cc598017465c6f06d53c206b72b Author: Kai-Heng Feng Date: Wed Nov 10 22:40:32 2021 +0800 ALSA: hda/realtek: Add quirk for HP EliteBook 840 G7 mute LED commit c058493df7edcef8f48c1494d9a84218519f966b upstream. The mute and micmute LEDs don't work on HP EliteBook 840 G7. The same quirk for other HP laptops can let LEDs work, so apply it. Signed-off-by: Kai-Heng Feng Cc: Link: https://lore.kernel.org/r/20211110144033.118451-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 0a6fef615cd95b528d3a75f809d3664986df64a3 Author: Takashi Iwai Date: Sun Nov 7 09:33:39 2021 +0100 ALSA: hda/realtek: Add quirk for ASUS UX550VE commit 4fad4fb9871b43389e4f4bead18ec693064697bb upstream. ASUS UX550VE (SSID 1043:1970) requires a similar workaround for managing the routing of the 4 speakers like some other ASUS models. Add a corresponding quirk entry for fixing it. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212641 Cc: Link: https://lore.kernel.org/r/20211107083339.18013-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 139ea889a60cb11ae7b3232920b0ab121234ea72 Author: Jaroslav Kysela Date: Thu Nov 4 16:57:26 2021 +0100 ALSA: hda/realtek: Add a quirk for Acer Spin SP513-54N commit 2a5bb694488bb6593066d46881bfd9d07edd1628 upstream. Another model requires ALC255_FIXUP_ACER_MIC_NO_PRESENCE fixup. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211853 Signed-off-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/20211104155726.2090997-1-perex@perex.cz Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1b0ca1a942a7b178727ea1f5e0e3f9b0b8cd5965 Author: Jeremy Soller Date: Tue Nov 2 11:21:04 2021 -0600 ALSA: hda/realtek: Headset fixup for Clevo NH77HJQ commit 1278cc5ac2f96bab50dd55c8c05e0a6a77ce323e upstream. On Clevo NH77HJ, NH77HP, and their 15" variants, there is a headset microphone input attached to 0x19 that does not have a jack detect. In order to get it working, the pin configuration needs to be set correctly, and a new ALC256_FIXUP_SYSTEM76_MIC_NO_PRESENCE fixup is applied. This is similar to the existing System76 quirk for ALC293, but for ALC256. Signed-off-by: Jeremy Soller Signed-off-by: Tim Crawford Cc: Link: https://lore.kernel.org/r/20211102172104.10610-1-tcrawford@system76.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 09a84058016c9e10b2a9396dc5b28feac89580b1 Author: Tim Crawford Date: Mon Nov 1 10:21:34 2021 -0600 ALSA: hda/realtek: Add quirk for Clevo PC70HS commit dbfe83507cf4ea66ce4efee2ac14c5ad420e31d3 upstream. Apply the PB51ED PCI quirk to the Clevo PC70HS. Fixes audio output from the internal speakers. Signed-off-by: Tim Crawford Cc: Link: https://lore.kernel.org/r/20211101162134.5336-1-tcrawford@system76.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d7d34eed508bba52dc5e01954a8ccedea0ee40e1 Author: Takashi Iwai Date: Thu Oct 28 09:09:11 2021 +0200 ALSA: hda/realtek: Add a quirk for HP OMEN 15 mute LED commit 375f8426ed994addd2be4d76febc946a6fdd8280 upstream. HP OMEN 15 laptop requires the quirk to fiddle with COEF 0x0b bit 2 for toggling the mute LED. It's already implemented for other HP laptops, and we just need to add a proper fixup entry. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214735 Cc: Link: https://lore.kernel.org/r/20211028070911.18891-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit f35d48489cb7819ee18baec4f3904e9fbac6bc97 Author: Johnathon Clark Date: Wed Oct 20 14:12:51 2021 +0100 ALSA: hda/realtek: Fix mic mute LED for the HP Spectre x360 14 commit 5fc462c3aaad601d5089fd5588a5799896a6937d upstream. On the 'HP Spectre x360 Convertible 14-ea0xx' the microphone mute led is controlled by GPIO 0x04. The speaker mute LED does not seem to be exposed by GPIO and is there not set. [ a slight coding-style fix by tiwai ] Fixes: c3bb2b521944 ("ALSA: hda/realtek: Quirk for HP Spectre x360 14 amp setup") Signed-off-by: Johnathon Clark Cc: Link: https://lore.kernel.org/r/20211020131253.35894-1-john.clark@cantab.net Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 47331981d71dfa19cc9ae7cc2c2c8e89d0fa6841 Author: Ricardo Ribalda Date: Fri Jun 18 14:29:03 2021 +0200 media: v4l2-ioctl: Fix check_ext_ctrls commit 861f92cb9160b14beef0ada047384c2340701ee2 upstream. Drivers that do not use the ctrl-framework use this function instead. Fix the following issues: - Do not check for multiple classes when getting the DEF_VAL. - Return -EINVAL for request_api calls - Default value cannot be changed, return EINVAL as soon as possible. - Return the right error_idx [If an error is found when validating the list of controls passed with VIDIOC_G_EXT_CTRLS, then error_idx shall be set to ctrls->count to indicate to userspace that no actual hardware was touched. It would have been much nicer of course if error_idx could point to the control index that failed the validation, but sadly that's not how the API was designed.] Fixes v4l2-compliance: Control ioctls (Input 0): warn: v4l2-test-controls.cpp(834): error_idx should be equal to count warn: v4l2-test-controls.cpp(855): error_idx should be equal to count fail: v4l2-test-controls.cpp(813): doioctl(node, VIDIOC_G_EXT_CTRLS, &ctrls) test VIDIOC_G/S/TRY_EXT_CTRLS: FAIL Buffer ioctls (Input 0): fail: v4l2-test-buffers.cpp(1994): ret != EINVAL && ret != EBADR && ret != ENOTTY test Requests: FAIL Cc: stable@vger.kernel.org Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support") Suggested-by: Hans Verkuil Reviewed-by: Hans Verkuil Signed-off-by: Ricardo Ribalda Signed-off-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 9d496fff4dfc7c4e950c7a40f4a0a1b56ae33a2a Author: Sean Young Date: Wed Sep 15 18:14:07 2021 +0200 media: ir-kbd-i2c: improve responsiveness of hauppauge zilog receivers commit c73ba202a851c0b611ef2c25e568fadeff5e667f upstream. The IR receiver has two issues: - Sometimes there is no response to a button press - Sometimes a button press is repeated when it should not have been Hanging the polling interval fixes this behaviour. Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994050 Cc: stable@vger.kernel.org Suggested-by: Joaquín Alberto Calderón Pozo Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 7577c6c1321ad3fa61d25478af2de4cec641f702 Author: Chen-Yu Tsai Date: Fri Oct 8 11:04:23 2021 +0100 media: rkvdec: Support dynamic resolution changes commit 0887e9e152efbd3601d6c907e90033d25067277d upstream. The mem-to-mem stateless decoder API specifies support for dynamic resolution changes. In particular, the decoder should accept format changes on the OUTPUT queue even when buffers have been allocated, as long as it is not streaming. Relax restrictions for S_FMT as described in the previous paragraph, and as long as the codec format remains the same. This aligns it with the Hantro and Cedrus decoders. This change was mostly based on commit ae02d49493b5 ("media: hantro: Fix s_fmt for dynamic resolution changes"). Since rkvdec_s_fmt() is now just a wrapper around the output/capture variants without any additional shared functionality, drop the wrapper and call the respective functions directly. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Cc: Signed-off-by: Chen-Yu Tsai Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit 1c83764a8385cd706417c61c05035e5a7507baa7 Author: Sean Young Date: Sun Oct 17 13:01:15 2021 +0100 media: ite-cir: IR receiver stop working after receive overflow commit fdc881783099c6343921ff017450831c8766d12a upstream. On an Intel NUC6iSYK, no IR is reported after a receive overflow. When a receiver overflow occurs, this condition is only cleared by reading the fifo. Make sure we read anything in the fifo. Fixes: 28c7afb07ccf ("media: ite-cir: check for receive overflow") Suggested-by: Bryan Pass Tested-by: Bryan Pass Cc: stable@vger.kernel.org> Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit ac698bd66a5cd22f14a6e59ce7fd2f598e66d829 Author: Chen-Yu Tsai Date: Fri Oct 8 11:04:22 2021 +0100 media: rkvdec: Do not override sizeimage for output format commit 298d8e8f7bcf023aceb60232d59b983255fec0df upstream. The rkvdec H.264 decoder currently overrides sizeimage for the output format. This causes issues when userspace requires and requests a larger buffer, but ends up with one of insufficient size. Instead, only provide a default size if none was requested. This fixes the video_decode_accelerator_tests from Chromium failing on the first frame due to insufficient buffer space. It also aligns the behavior of the rkvdec driver with the Hantro and Cedrus drivers. Fixes: cd33c830448b ("media: rkvdec: Add the rkvdec driver") Cc: Signed-off-by: Chen-Yu Tsai Reviewed-by: Nicolas Dufresne Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Greg Kroah-Hartman commit cfb1311f92e1cf30abd691caa39b3dabb2ce4949 Author: Tang Bin Date: Thu Oct 21 09:34:22 2021 +0800 crypto: s5p-sss - Add error handling in s5p_aes_probe() commit a472cc0dde3eb057db71c80f102556eeced03805 upstream. The function s5p_aes_probe() does not perform sufficient error checking after executing platform_get_resource(), thus fix it. Fixes: c2afad6c6105 ("crypto: s5p-sss - Add HASH support for Exynos") Cc: Signed-off-by: Tang Bin Reviewed-by: Krzysztof Kozlowski Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit ea5654a13b2e3d0ea3767925275b7a208a651f9c Author: jing yangyang Date: Thu Aug 19 19:30:16 2021 -0700 firmware/psci: fix application of sizeof to pointer commit 2ac5fb35cd520ab1851c9a4816c523b65276052f upstream. sizeof when applied to a pointer typed expression gives the size of the pointer. ./drivers/firmware/psci/psci_checker.c:158:41-47: ERROR application of sizeof to pointer This issue was detected with the help of Coccinelle. Fixes: 7401056de5f8 ("drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests") Cc: stable@vger.kernel.org Reported-by: Zeal Robot Acked-by: Mark Rutland Reviewed-by: Gustavo A. R. Silva Signed-off-by: jing yangyang Signed-off-by: Gustavo A. R. Silva Signed-off-by: Greg Kroah-Hartman commit e06c0c6b038b25849a125a8478beaf6243076fa8 Author: Dan Carpenter Date: Wed Sep 8 08:33:57 2021 +0300 tpm: Check for integer overflow in tpm2_map_response_body() commit a0bcce2b2a169e10eb265c8f0ebdd5ae4c875670 upstream. The "4 * be32_to_cpu(data->count)" multiplication can potentially overflow which would lead to memory corruption. Add a check for that. Cc: stable@vger.kernel.org Fixes: 745b361e989a ("tpm: infrastructure for TPM spaces") Signed-off-by: Dan Carpenter Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit d0775031766fff06943340187197b86846eebcd1 Author: Helge Deller Date: Tue Oct 5 00:27:49 2021 +0200 parisc: Fix ptrace check on syscall return commit 8779e05ba8aaffec1829872ef9774a71f44f6580 upstream. The TIF_XXX flags are stored in the flags field in the thread_info struct (TI_FLAGS), not in the flags field of the task_struct structure (TASK_FLAGS). It seems this bug didn't generate any important side-effects, otherwise it wouldn't have went unnoticed for 12 years (since v2.6.32). Signed-off-by: Helge Deller Fixes: ecd3d4bc06e48 ("parisc: stop using task->ptrace for {single,block}step flags") Cc: Kyle McMartin Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 1af62b51aa5eba394118c3ecbb214686fb75becd Author: Helge Deller Date: Sun Oct 31 21:58:12 2021 +0100 parisc: Fix set_fixmap() on PA1.x CPUs commit 6e866a462867b60841202e900f10936a0478608c upstream. Fix a kernel crash which happens on PA1.x CPUs while initializing the FTRACE/KPROBE breakpoints. The PTE table entries for the fixmap area were not created correctly. Signed-off-by: Helge Deller Fixes: ccfbc68d41c2 ("parisc: add set_fixmap()/clear_fixmap()") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Greg Kroah-Hartman commit d4c5e024d73f76752fd309c0fd69194c44642840 Author: Sungjong Seo Date: Tue Oct 19 15:14:21 2021 +0900 exfat: fix incorrect loading of i_blocks for large files commit 0c336d6e33f4bedc443404c89f43c91c8bd9ee11 upstream. When calculating i_blocks, there was a mistake that was masked with a 32-bit variable. So i_blocks for files larger than 4 GiB had incorrect values. Mask with a 64-bit variable instead of 32-bit one. Fixes: 5f2aa075070c ("exfat: add inode operations") Cc: stable@vger.kernel.org # v5.7+ Reported-by: Ganapathi Kamath Signed-off-by: Sungjong Seo Signed-off-by: Namjae Jeon Signed-off-by: Greg Kroah-Hartman commit de6acc5e6a95cea060f337e03d1ffa0c457e467d Author: Christian Löhle Date: Thu Sep 16 05:59:19 2021 +0000 mmc: dw_mmc: Dont wait for DRTO on Write RSP error commit 43592c8736e84025d7a45e61a46c3fa40536a364 upstream. Only wait for DRTO on reads, otherwise the driver hangs. The driver prevents sending CMD12 on response errors like CRCs. According to the comment this is because some cards have problems with this during the UHS tuning sequence. Unfortunately this workaround currently also applies for any command with data. On reads this will set the drto timer, which then triggers after a while. On writes this will not set any timer and the tasklet will not be scheduled again. I cannot test for the UHS workarounds need, but even if so, it should at most apply to reads. I have observed many hangs when CMD25 response contained a CRC error. This patch fixes this without touching the actual UHS tuning workaround. Signed-off-by: Christian Loehle Reviewed-by: Jaehoon Chung Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/af8f8b8674ba4fcc9a781019e4aeb72c@hyperstone.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 088a27043b2b76b8b80914b3fb01742452d79e86 Author: Derong Liu Date: Fri Aug 27 15:15:37 2021 +0800 mmc: mtk-sd: Add wait dma stop done flow commit 43e5fee317f4b0a48992b8b07935b1a3ac20ce84 upstream. We found this issue on a 5G platform, during CMDQ error handling, if DMA status is active when it call msdc_reset_hw(), it means mmc host hw reset and DMA transfer will be parallel, mmc host may access sram region unexpectedly. According to the programming guide of mtk-sd host, it needs to wait for dma stop done after set dma stop. This change should be applied to all SoCs. Signed-off-by: Derong Liu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210827071537.1034-1-derong.liu@mediatek.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7038cb714d121b377df9819f3c9a70cb95570ffa Author: Ziyang Xuan Date: Sat Oct 16 13:20:47 2021 +0800 char: xillybus: fix msg_ep UAF in xillyusb_probe() commit 15c9a359094ec6251578b02387436bc64f11a477 upstream. When endpoint_alloc() return failed in xillyusb_setup_base_eps(), 'xdev->msg_ep' will be freed but not set to NULL. That lets program enter fail handling to cleanup_dev() in xillyusb_probe(). Check for 'xdev->msg_ep' is invalid in cleanup_dev() because 'xdev->msg_ep' did not set to NULL when was freed. So the UAF problem for 'xdev->msg_ep' is triggered. ================================================================== BUG: KASAN: use-after-free in fifo_mem_release+0x1f4/0x210 CPU: 0 PID: 166 Comm: kworker/0:2 Not tainted 5.15.0-rc5+ #19 Call Trace: dump_stack_lvl+0xe2/0x152 print_address_description.constprop.0+0x21/0x140 ? fifo_mem_release+0x1f4/0x210 kasan_report.cold+0x7f/0x11b ? xillyusb_probe+0x530/0x700 ? fifo_mem_release+0x1f4/0x210 fifo_mem_release+0x1f4/0x210 ? __sanitizer_cov_trace_pc+0x1d/0x50 endpoint_dealloc+0x35/0x2b0 cleanup_dev+0x90/0x120 xillyusb_probe+0x59a/0x700 ... Freed by task 166: kasan_save_stack+0x1b/0x40 kasan_set_track+0x1c/0x30 kasan_set_free_info+0x20/0x30 __kasan_slab_free+0x109/0x140 kfree+0x117/0x4c0 xillyusb_probe+0x606/0x700 Set 'xdev->msg_ep' to NULL after being freed in xillyusb_setup_base_eps() to fix the UAF problem. Fixes: a53d1202aef1 ("char: xillybus: Add driver for XillyUSB (Xillybus variant for USB)") Cc: stable Acked-by: Eli Billauer Signed-off-by: Ziyang Xuan Link: https://lore.kernel.org/r/20211016052047.1611983-1-william.xuanziyang@huawei.com Signed-off-by: Greg Kroah-Hartman commit e1d2af3c9164ae56b62d0e32f6072028726badf8 Author: Ben Skeggs Date: Wed Nov 3 11:10:57 2021 +1000 ce/gf100: fix incorrect CE0 address calculation on some GPUs commit 93f43ed81abec8c805e1b77eb1d20dbc51a24dc4 upstream. The code which constructs the modules for each engine present on the GPU passes -1 for 'instance' on non-instanced engines, which affects how the name for a sub-device is generated. This is then stored as 'instance 0' in nvkm_subdev.inst, so code can potentially be shared with earlier GPUs that only had a single instance of an engine. However, GF100's CE constructor uses this value to calculate the address of its falcon before it's translated, resulting in CE0 getting the wrong address. This slightly modifies the approach, always passing a valid instance for engines that *can* have multiple copies, and having the code for earlier GPUs explicitly ask for non-instanced name generation. Bug: https://gitlab.freedesktop.org/drm/nouveau/-/issues/91 Fixes: 50551b15c760 ("drm/nouveau/ce: switch to instanced constructor") Cc: # v5.12+ Signed-off-by: Ben Skeggs Reviewed-by: Karol Herbst Tested-by: Karol Herbst Signed-off-by: Karol Herbst Link: https://patchwork.freedesktop.org/patch/msgid/20211103011057.15344-1-skeggsb@gmail.com Signed-off-by: Greg Kroah-Hartman commit 69e269a766b46d917141b98cca7ab40adda7553e Author: Quinn Tran Date: Wed Sep 8 09:46:21 2021 -0700 scsi: qla2xxx: Fix use after free in eh_abort path commit 3d33b303d4f3b74a71bede5639ebba3cfd2a2b4d upstream. In eh_abort path driver prematurely exits the call to upper layer. Check whether command is aborted / completed by firmware before exiting the call. 9 [ffff8b1ebf803c00] page_fault at ffffffffb0389778 [exception RIP: qla2x00_status_entry+0x48d] RIP: ffffffffc04fa62d RSP: ffff8b1ebf803cb0 RFLAGS: 00010082 RAX: 00000000ffffffff RBX: 00000000000e0000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000000013d8 RDI: fffff3253db78440 RBP: ffff8b1ebf803dd0 R8: ffff8b1ebcd9b0c0 R9: 0000000000000000 R10: ffff8b1e38a30808 R11: 0000000000001000 R12: 00000000000003e9 R13: 0000000000000000 R14: ffff8b1ebcd9d740 R15: 0000000000000028 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 10 [ffff8b1ebf803cb0] enqueue_entity at ffffffffafce708f 11 [ffff8b1ebf803d00] enqueue_task_fair at ffffffffafce7b88 12 [ffff8b1ebf803dd8] qla24xx_process_response_queue at ffffffffc04fc9a6 [qla2xxx] 13 [ffff8b1ebf803e78] qla24xx_msix_rsp_q at ffffffffc04ff01b [qla2xxx] 14 [ffff8b1ebf803eb0] __handle_irq_event_percpu at ffffffffafd50714 Link: https://lore.kernel.org/r/20210908164622.19240-10-njavali@marvell.com Fixes: f45bca8c5052 ("scsi: qla2xxx: Fix double scsi_done for abort path") Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Co-developed-by: David Jeffery Signed-off-by: David Jeffery Co-developed-by: Laurence Oberman Signed-off-by: Laurence Oberman Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5282d10eeaf0876aff0684a6c097086ab02bedfe Author: Arun Easi Date: Wed Sep 8 09:46:18 2021 -0700 scsi: qla2xxx: Fix kernel crash when accessing port_speed sysfs file commit 3ef68d4f0c9e7cb589ae8b70f07d77f528105331 upstream. Kernel crashes when accessing port_speed sysfs file. The issue happens on a CNA when the local array was accessed beyond bounds. Fix this by changing the lookup. BUG: unable to handle kernel paging request at 0000000000004000 PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 15 PID: 455213 Comm: sosreport Kdump: loaded Not tainted 4.18.0-305.7.1.el8_4.x86_64 #1 RIP: 0010:string_nocheck+0x12/0x70 Code: 00 00 4c 89 e2 be 20 00 00 00 48 89 ef e8 86 9a 00 00 4c 01 e3 eb 81 90 49 89 f2 48 89 ce 48 89 f8 48 c1 fe 30 66 85 f6 74 4f <44> 0f b6 0a 45 84 c9 74 46 83 ee 01 41 b8 01 00 00 00 48 8d 7c 37 RSP: 0018:ffffb5141c1afcf0 EFLAGS: 00010286 RAX: ffff8bf4009f8000 RBX: ffff8bf4009f9000 RCX: ffff0a00ffffff04 RDX: 0000000000004000 RSI: ffffffffffffffff RDI: ffff8bf4009f8000 RBP: 0000000000004000 R08: 0000000000000001 R09: ffffb5141c1afb84 R10: ffff8bf4009f9000 R11: ffffb5141c1afce6 R12: ffff0a00ffffff04 R13: ffffffffc08e21aa R14: 0000000000001000 R15: ffffffffc08e21aa FS: 00007fc4ebfff700(0000) GS:ffff8c717f7c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000004000 CR3: 000000edfdee6006 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: string+0x40/0x50 vsnprintf+0x33c/0x520 scnprintf+0x4d/0x90 qla2x00_port_speed_show+0xb5/0x100 [qla2xxx] dev_attr_show+0x1c/0x40 sysfs_kf_seq_show+0x9b/0x100 seq_read+0x153/0x410 vfs_read+0x91/0x140 ksys_read+0x4f/0xb0 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca Link: https://lore.kernel.org/r/20210908164622.19240-7-njavali@marvell.com Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed") Cc: stable@vger.kernel.org Reviewed-by: Himanshu Madhani Signed-off-by: Arun Easi Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 5fc7e0e194ff4b2bf6f24dbf8aa31a37f6d36a2e Author: James Smart Date: Fri Sep 10 16:31:53 2021 -0700 scsi: lpfc: Fix FCP I/O flush functionality for TMF routines commit cd8a36a90babf958082b87bc6b4df5dd70901eba upstream. A prior patch inadvertently caused lpfc_sli_sum_iocb() to exclude counting of outstanding aborted I/Os and ABORT IOCBs. Thus, lpfc_reset_flush_io_context() called from any TMF routine does not properly wait to flush all outstanding FCP IOCBs leading to a block layer crash on an invalid scsi_cmnd->request pointer. kernel BUG at ../block/blk-core.c:1489! RIP: 0010:blk_requeue_request+0xaf/0xc0 ... Call Trace: __scsi_queue_insert+0x90/0xe0 [scsi_mod] blk_done_softirq+0x7e/0x90 __do_softirq+0xd2/0x280 irq_exit+0xd5/0xe0 do_IRQ+0x4c/0xd0 common_interrupt+0x87/0x87 Fix by separating out the LPFC_IO_FCP, LPFC_IO_ON_TXCMPLQ, LPFC_DRIVER_ABORTED, and CMD_ABORT_XRI_CN || CMD_CLOSE_XRI_CN checks into a new lpfc_sli_validate_fcp_iocb_for_abort() routine when determining to build an ABORT iocb. Restore lpfc_reset_flush_io_context() functionality by including counting of outstanding aborted IOCBs and ABORT IOCBs in lpfc_sli_sum_iocb(). Link: https://lore.kernel.org/r/20210910233159.115896-9-jsmart2021@gmail.com Fixes: e1364711359f ("scsi: lpfc: Fix illegal memory access on Abort IOCBs") Cc: # v5.12+ Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 2080931c7849cede6baecda4f09593e8b455c8bb Author: James Smart Date: Fri Sep 10 16:31:47 2021 -0700 scsi: lpfc: Don't release final kref on Fport node while ABTS outstanding commit 982fc3965d1350d3332e04046b0e101006184ba9 upstream. In a rarely executed path, FLOGI failure, there is a refcounting error. If FLOGI completed with an error, typically a timeout, the initial completion handler would remove the job reference. However, the job completion isn't the actual end of the job/exchange as the timeout usually initiates an ABTS, and upon that ABTS completion, a final completion is sent. The driver removes the reference again in the final completion. Thus the imbalance. In the buggy cases, if there was a link bounce while the delayed response is outstanding, the fport node may be referenced again but there was no additional reference as it is already present. The delayed completion then occurs and removes the last reference freeing the node and causing issues in the link up processed that is using the node. Fix this scenario by removing the snippet that removed the reference in the initial FLOGI completion. The bad snippet was poorly trying to identify the FLOGI as OK to do so by realizing the node was not registered with either SCSI or NVMe transport. Link: https://lore.kernel.org/r/20210910233159.115896-3-jsmart2021@gmail.com Fixes: 618e2ee146d4 ("scsi: lpfc: Fix FLOGI failure due to accessing a freed node") Cc: # v5.13+ Co-developed-by: Justin Tee Signed-off-by: Justin Tee Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9bfe4b77333d9f4503fbebd0fb3c0959476f8092 Author: Tadeusz Struk Date: Wed Nov 3 10:06:59 2021 -0700 scsi: core: Remove command size deduction from scsi_setup_scsi_cmnd() commit 703535e6ae1e94c89a9c1396b4c7b6b41160ef0c upstream. No need to deduce command size in scsi_setup_scsi_cmnd() anymore as appropriate checks have been added to scsi_fill_sghdr_rq() function and the cmd_len should never be zero here. The code to do that wasn't correct anyway, as it used uninitialized cmd->cmnd, which caused a null-ptr-deref if the command size was zero as in the trace below. Fix this by removing the unneeded code. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 1822 Comm: repro Not tainted 5.15.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 Call Trace: blk_mq_dispatch_rq_list+0x7c7/0x12d0 __blk_mq_sched_dispatch_requests+0x244/0x380 blk_mq_sched_dispatch_requests+0xf0/0x160 __blk_mq_run_hw_queue+0xe8/0x160 __blk_mq_delay_run_hw_queue+0x252/0x5d0 blk_mq_run_hw_queue+0x1dd/0x3b0 blk_mq_sched_insert_request+0x1ff/0x3e0 blk_execute_rq_nowait+0x173/0x1e0 blk_execute_rq+0x15c/0x540 sg_io+0x97c/0x1370 scsi_ioctl+0xe16/0x28e0 sd_ioctl+0x134/0x170 blkdev_ioctl+0x362/0x6e0 block_ioctl+0xb0/0xf0 vfs_ioctl+0xa7/0xf0 do_syscall_64+0x3d/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae ---[ end trace 8b086e334adef6d2 ]--- Kernel panic - not syncing: Fatal exception Link: https://lore.kernel.org/r/20211103170659.22151-2-tadeusz.struk@linaro.org Fixes: 2ceda20f0a99 ("scsi: core: Move command size detection out of the fast path") Cc: Bart Van Assche Cc: Christoph Hellwig Cc: James E.J. Bottomley Cc: Martin K. Petersen Cc: Cc: Cc: # 5.15, 5.14, 5.10 Reported-by: syzbot+5516b30f5401d4dcbcae@syzkaller.appspotmail.com Reviewed-by: Bart Van Assche Reviewed-by: Christoph Hellwig Signed-off-by: Tadeusz Struk Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 0806efcadf8ed2ab1ed3b327271df33cd3bc68f1 Author: Ewan D. Milne Date: Fri Oct 29 15:43:10 2021 -0400 scsi: core: Avoid leaving shost->last_reset with stale value if EH does not run commit 5ae17501bc62a49b0b193dcce003f16375f16654 upstream. The changes to issue the abort from the scmd->abort_work instead of the EH thread introduced a problem if eh_deadline is used. If aborting the command(s) is successful, and there are never any scmds added to the shost->eh_cmd_q, there is no code path which will reset the ->last_reset value back to zero. The effect of this is that after a successful abort with no EH thread activity, a subsequent timeout, perhaps a long time later, might immediately be considered past a user-set eh_deadline time, and the host will be reset with no attempt at recovery. Fix this by resetting ->last_reset back to zero in scmd_eh_abort_handler() if it is determined that the EH thread will not run to do this. Thanks to Gopinath Marappan for investigating this problem. Link: https://lore.kernel.org/r/20211029194311.17504-2-emilne@redhat.com Fixes: e494f6a72839 ("[SCSI] improved eh timeout handler") Cc: stable@vger.kernel.org Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 9020b4adf3a6f809545fa77947f338f10a48ea74 Author: Jan Kara Date: Fri Nov 5 13:34:55 2021 -0700 ocfs2: fix data corruption on truncate commit 839b63860eb3835da165642923120d305925561d upstream. Patch series "ocfs2: Truncate data corruption fix". As further testing has shown, commit 5314454ea3f ("ocfs2: fix data corruption after conversion from inline format") didn't fix all the data corruption issues the customer started observing after 6dbf7bb55598 ("fs: Don't invalidate page buffers in block_write_full_page()") This time I have tracked them down to two bugs in ocfs2 truncation code. One bug (truncating page cache before clearing tail cluster and setting i_size) could cause data corruption even before 6dbf7bb55598, but before that commit it needed a race with page fault, after 6dbf7bb55598 it started to be pretty deterministic. Another bug (zeroing pages beyond old i_size) used to be harmless inefficiency before commit 6dbf7bb55598. But after commit 6dbf7bb55598 in combination with the first bug it resulted in deterministic data corruption. Although fixing only the first problem is needed to stop data corruption, I've fixed both issues to make the code more robust. This patch (of 2): ocfs2_truncate_file() did unmap invalidate page cache pages before zeroing partial tail cluster and setting i_size. Thus some pages could be left (and likely have left if the cluster zeroing happened) in the page cache beyond i_size after truncate finished letting user possibly see stale data once the file was extended again. Also the tail cluster zeroing was not guaranteed to finish before truncate finished causing possible stale data exposure. The problem started to be particularly easy to hit after commit 6dbf7bb55598 "fs: Don't invalidate page buffers in block_write_full_page()" stopped invalidation of pages beyond i_size from page writeback path. Fix these problems by unmapping and invalidating pages in the page cache after the i_size is reduced and tail cluster is zeroed out. Link: https://lkml.kernel.org/r/20211025150008.29002-1-jack@suse.cz Link: https://lkml.kernel.org/r/20211025151332.11301-1-jack@suse.cz Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem") Signed-off-by: Jan Kara Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 762722cfd0a043c5850e146be104776476efbda1 Author: Damien Le Moal Date: Thu Nov 4 17:31:58 2021 +0900 libata: fix read log timeout value commit 68dbbe7d5b4fde736d104cbbc9a2fce875562012 upstream. Some ATA drives are very slow to respond to READ_LOG_EXT and READ_LOG_DMA_EXT commands issued from ata_dev_configure() when the device is revalidated right after resuming a system or inserting the ATA adapter driver (e.g. ahci). The default 5s timeout (ATA_EH_CMD_DFL_TIMEOUT) used for these commands is too short, causing errors during the device configuration. Ex: ... ata9: SATA max UDMA/133 abar m524288@0x9d200000 port 0x9d200400 irq 209 ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata9.00: ATA-9: XXX XXXXXXXXXXXXXXX, XXXXXXXX, max UDMA/133 ata9.00: qc timeout (cmd 0x2f) ata9.00: Read log page 0x00 failed, Emask 0x4 ata9.00: Read log page 0x00 failed, Emask 0x40 ata9.00: NCQ Send/Recv Log not supported ata9.00: Read log page 0x08 failed, Emask 0x40 ata9.00: 27344764928 sectors, multi 16: LBA48 NCQ (depth 32), AA ata9.00: Read log page 0x00 failed, Emask 0x40 ata9.00: ATA Identify Device Log not supported ata9.00: failed to set xfermode (err_mask=0x40) ata9: SATA link up 6.0 Gbps (SStatus 133 SControl 300) ata9.00: configured for UDMA/133 ... The timeout error causes a soft reset of the drive link, followed in most cases by a successful revalidation as that give enough time to the drive to become fully ready to quickly process the read log commands. However, in some cases, this also fails resulting in the device being dropped. Fix this by using adding the ata_eh_revalidate_timeouts entries for the READ_LOG_EXT and READ_LOG_DMA_EXT commands. This defines a timeout increased to 15s, retriable one time. Reported-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal Signed-off-by: Greg Kroah-Hartman commit 7f94e05338f5d52eef23e6ee98d9b499cafb4ced Author: Takashi Iwai Date: Wed Nov 3 08:00:19 2021 +0100 Input: i8042 - Add quirk for Fujitsu Lifebook T725 commit 16e28abb7290c4ca3b3a0f333ba067f34bb18c86 upstream. Fujitsu Lifebook T725 laptop requires, like a few other similar models, the nomux and notimeout options to probe the touchpad properly. This patch adds the corresponding quirk entries. BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1191980 Tested-by: Neal Gompa Cc: Signed-off-by: Takashi Iwai Link: https://lore.kernel.org/r/20211103070019.13374-1-tiwai@suse.de Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit 94e0a6bc4130aad78840ceb427916c1be993d722 Author: Phoenix Huang Date: Sun Nov 7 22:00:03 2021 -0800 Input: elantench - fix misreporting trackpoint coordinates commit be896bd3b72b44126c55768f14c22a8729b0992e upstream. Some firmwares occasionally report bogus data from trackpoint, with X or Y displacement being too large (outside of [-127, 127] range). Let's drop such packets so that we do not generate jumps. Signed-off-by: Phoenix Huang Tested-by: Yufei Du Link: https://lore.kernel.org/r/20210729010940.5752-1-phoenix@emc.com.tw Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit f9ccab9a050dda2861438e90def9537f80f281a8 Author: Johan Hovold Date: Tue Nov 9 22:58:01 2021 -0800 Input: iforce - fix control-message timeout commit 744d0090a5f6dfa4c81b53402ccdf08313100429 upstream. USB control-message timeouts are specified in milliseconds and should specifically not vary with CONFIG_HZ. Fixes: 487358627825 ("Input: iforce - use DMA-safe buffer when getting IDs from USB") Signed-off-by: Johan Hovold Cc: stable@vger.kernel.org # 5.3 Link: https://lore.kernel.org/r/20211025115501.5190-1-johan@kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman commit d725957f46309a37a5372a1da11df6eb3bc9c4ab Author: Nehal Bakulchandra Shah Date: Thu Oct 14 15:12:00 2021 +0300 usb: xhci: Enable runtime-pm by default on AMD Yellow Carp platform commit 660a92a59b9e831a0407e41ff62875656d30006e upstream. AMD's Yellow Carp platform supports runtime power management for XHCI Controllers, so enable the same by default for all XHCI Controllers. [ regrouped and aligned the PCI_DEVICE_ID definitions -Mathias] Cc: stable Reviewed-by: Shyam Sundar S K Reviewed-by: Mario Limonciello Reviewed-by: Basavaraj Natikar Signed-off-by: Nehal Bakulchandra Shah Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20211014121200.75433-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 8eb1d2c82122cd9f9d4862b7622de992e17d0cdb Author: Mathias Nyman Date: Fri Nov 5 18:00:36 2021 +0200 xhci: Fix USB 3.1 enumeration issues by increasing roothub power-on-good delay commit e1959faf085b004e6c3afaaaa743381f00e7c015 upstream. Some USB 3.1 enumeration issues were reported after the hub driver removed the minimum 100ms limit for the power-on-good delay. Since commit 90d28fb53d4a ("usb: core: reduce power-on-good delay time of root hub") the hub driver sets the power-on-delay based on the bPwrOn2PwrGood value in the hub descriptor. xhci driver has a 20ms bPwrOn2PwrGood value for both roothubs based on xhci spec section 5.4.8, but it's clearly not enough for the USB 3.1 devices, causing enumeration issues. Tests indicate full 100ms delay is needed. Reported-by: Walt Jr. Brake Signed-off-by: Mathias Nyman Fixes: 90d28fb53d4a ("usb: core: reduce power-on-good delay time of root hub") Cc: stable Link: https://lore.kernel.org/r/20211105160036.549516-1-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman