commit b82e5721a17325739adef83a029340a63b53d4ad Author: Greg Kroah-Hartman Date: Fri May 14 09:44:33 2021 +0200 Linux 5.4.119 Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Hulk Robot Tested-by: Jason Self Tested-by: Sudip Mukherjee Reported-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210512144743.039977287@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 6b183fbf18b91bc3c1fd02d5a48f7bc447d900ce Author: Quentin Perret Date: Wed May 12 12:28:53 2021 +0000 Revert "fdt: Properly handle "no-map" field in the memory region" This reverts commit fb326c6ce0dcbb6273202c6e012759754ec8538d. It is not really a fix, and the backport misses dependencies, which breaks existing platforms. Reported-by: Alexandre TORGUE Signed-off-by: Quentin Perret Signed-off-by: Greg Kroah-Hartman commit 66b8853dfa3cfbbe6c3ab643b6989377ad16662a Author: Quentin Perret Date: Wed May 12 12:28:52 2021 +0000 Revert "of/fdt: Make sure no-map does not remove already reserved regions" This reverts commit 3cbd3038c9155038020560729cde50588311105d. It is not really a fix, and the backport misses dependencies, which breaks existing platforms. Reported-by: Alexandre TORGUE Signed-off-by: Quentin Perret Signed-off-by: Greg Kroah-Hartman commit 3fe9ee040fb7332e2b4cc04c85561eced0a7f227 Author: Xin Long Date: Mon May 3 05:11:42 2021 +0800 sctp: delay auto_asconf init until binding the first addr commit 34e5b01186858b36c4d7c87e1a025071e8e2401f upstream. As Or Cohen described: If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock held and sp->do_auto_asconf is true, then an element is removed from the auto_asconf_splist without any proper locking. This can happen in the following functions: 1. In sctp_accept, if sctp_sock_migrate fails. 2. In inet_create or inet6_create, if there is a bpf program attached to BPF_CGROUP_INET_SOCK_CREATE which denies creation of the sctp socket. This patch is to fix it by moving the auto_asconf init out of sctp_init_sock(), by which inet_create()/inet6_create() won't need to operate it in sctp_destroy_sock() when calling sk_common_release(). It also makes more sense to do auto_asconf init while binding the first addr, as auto_asconf actually requires an ANY addr bind, see it in sctp_addr_wq_timeout_handler(). This addresses CVE-2021-23133. Fixes: 610236587600 ("bpf: Add new cgroup attach type to enable sock modifications") Reported-by: Or Cohen Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e1bf000709cc0bb5b40a10a57597be401866acbf Author: Xin Long Date: Mon May 3 05:11:41 2021 +0800 Revert "net/sctp: fix race condition in sctp_destroy_sock" commit 01bfe5e8e428b475982a98a46cca5755726f3f7f upstream. This reverts commit b166a20b07382b8bc1dcee2a448715c9c2c81b5b. This one has to be reverted as it introduced a dead lock, as syzbot reported: CPU0 CPU1 ---- ---- lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1 is that of sctp_close(). The original issue this commit fixed will be fixed in the next patch. Reported-by: syzbot+959223586843e69a2674@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 32e046965fac0bd643574befa765e193c2d29e02 Author: Arnd Bergmann Date: Wed May 5 23:12:42 2021 +0200 smp: Fix smp_call_function_single_async prototype commit 1139aeb1c521eb4a050920ce6c64c36c4f2a3ab7 upstream. As of commit 966a967116e6 ("smp: Avoid using two cache lines for struct call_single_data"), the smp code prefers 32-byte aligned call_single_data objects for performance reasons, but the block layer includes an instance of this structure in the main 'struct request' that is more senstive to size than to performance here, see 4ccafe032005 ("block: unalign call_single_data in struct request"). The result is a violation of the calling conventions that clang correctly points out: block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to 32-byte aligned parameter 2 of 'smp_call_function_single_async' may result in an unaligned pointer access [-Walign-mismatch] smp_call_function_single_async(cpu, &rq->csd); It does seem that the usage of the call_single_data without cache line alignment should still be allowed by the smp code, so just change the function prototype so it accepts both, but leave the default alignment unchanged for the other users. This seems better to me than adding a local hack to shut up an otherwise correct warning in the caller. Signed-off-by: Arnd Bergmann Signed-off-by: Peter Zijlstra (Intel) Acked-by: Jens Axboe Link: https://lkml.kernel.org/r/20210505211300.3174456-1-arnd@kernel.org [nc: Fix conflicts] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman commit 9884f745108f7d25b189bbcd6754e284fb29ab68 Author: Jonathon Reinhart Date: Sat May 1 04:28:22 2021 -0400 net: Only allow init netns to set default tcp cong to a restricted algo commit 8d432592f30fcc34ef5a10aac4887b4897884493 upstream. tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify Fixes: 6670e1524477 ("tcp: Namespace-ify sysctl_tcp_default_congestion_control") Signed-off-by: Jonathon Reinhart Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4a83a9deead990bc8d80097e9b863a803e2f3b88 Author: Jane Chu Date: Thu Apr 29 23:02:19 2021 -0700 mm/memory-failure: unnecessary amount of unmapping [ Upstream commit 4d75136be8bf3ae01b0bc3e725b2cdc921e103bd ] It appears that unmap_mapping_range() actually takes a 'size' as its third argument rather than a location, the current calling fashion causes unnecessary amount of unmapping to occur. Link: https://lkml.kernel.org/r/20210420002821.2749748-1-jane.chu@oracle.com Fixes: 6100e34b2526e ("mm, memory_failure: Teach memory_failure() about dev_pagemap pages") Signed-off-by: Jane Chu Reviewed-by: Dan Williams Reviewed-by: Naoya Horiguchi Cc: Dave Jiang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit de143fb2feacd61dab675f87127697c45dedc97c Author: Wang Wensheng Date: Thu Apr 29 22:57:58 2021 -0700 mm/sparse: add the missing sparse_buffer_fini() in error branch [ Upstream commit 2284f47fe9fe2ed2ef619e5474e155cfeeebd569 ] sparse_buffer_init() and sparse_buffer_fini() should appear in pair, or a WARN issue would be through the next time sparse_buffer_init() runs. Add the missing sparse_buffer_fini() in error branch. Link: https://lkml.kernel.org/r/20210325113155.118574-1-wangwensheng4@huawei.com Fixes: 85c77f791390 ("mm/sparse: add new sparse_init_nid() and sparse_init()") Signed-off-by: Wang Wensheng Reviewed-by: David Hildenbrand Reviewed-by: Oscar Salvador Cc: Pavel Tatashin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ba450bba7115a7a46a8fa1463de829d3a6610b9f Author: Dan Carpenter Date: Thu Apr 29 22:54:15 2021 -0700 kfifo: fix ternary sign extension bugs [ Upstream commit 926ee00ea24320052b46745ef4b00d91c05bd03d ] The intent with this code was to return negative error codes but instead it returns positives. The problem is how type promotion works with ternary operations. These functions return long, "ret" is an int and "copied" is a u32. The negative error code is first cast to u32 so it becomes a high positive and then cast to long where it's still a positive. We could fix this by declaring "ret" as a ssize_t but let's just get rid of the ternaries instead. Link: https://lkml.kernel.org/r/YIE+/cK1tBzSuQPU@mwanda Fixes: 5bf2b19320ec ("kfifo: add example files to the kernel sample directory") Signed-off-by: Dan Carpenter Cc: Stefani Seibold Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 24c54e0a97477ef6146f1deeae435687347a067d Author: Lv Yunlong Date: Tue Apr 27 09:22:58 2021 -0700 net:nfc:digital: Fix a double free in digital_tg_recv_dep_req [ Upstream commit 75258586793efc521e5dd52a5bf6c7a4cf7002be ] In digital_tg_recv_dep_req, it calls nfc_tm_data_received(..,resp). If nfc_tm_data_received() failed, the callee will free the resp via kfree_skb() and return error. But in the exit branch, the resp will be freed again. My patch sets resp to NULL if nfc_tm_data_received() failed, to avoid the double free. Fixes: 1c7a4c24fbfd9 ("NFC Digital: Add target NFC-DEP support") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 07ef3f7bc5c4f9f5250293cfee5202856bc7787c Author: Linus Lüssing Date: Sun Apr 25 17:27:35 2021 +0200 net: bridge: mcast: fix broken length + header check for MRDv6 Adv. [ Upstream commit 99014088156cd78867d19514a0bc771c4b86b93b ] The IPv6 Multicast Router Advertisements parsing has the following two issues: For one thing, ICMPv6 MRD Advertisements are smaller than ICMPv6 MLD messages (ICMPv6 MRD Adv.: 8 bytes vs. ICMPv6 MLDv1/2: >= 24 bytes, assuming MLDv2 Reports with at least one multicast address entry). When ipv6_mc_check_mld_msg() tries to parse an Multicast Router Advertisement its MLD length check will fail - and it will wrongly return -EINVAL, even if we have a valid MRD Advertisement. With the returned -EINVAL the bridge code will assume a broken packet and will wrongly discard it, potentially leading to multicast packet loss towards multicast routers. The second issue is the MRD header parsing in br_ip6_multicast_mrd_rcv(): It wrongly checks for an ICMPv6 header immediately after the IPv6 header (IPv6 next header type). However according to RFC4286, section 2 all MRD messages contain a Router Alert option (just like MLD). So instead there is an IPv6 Hop-by-Hop option for the Router Alert between the IPv6 and ICMPv6 header, again leading to the bridge wrongly discarding Multicast Router Advertisements. To fix these two issues, introduce a new return value -ENODATA to ipv6_mc_check_mld() to indicate a valid ICMPv6 packet with a hop-by-hop option which is not an MLD but potentially an MRD packet. This also simplifies further parsing in the bridge code, as ipv6_mc_check_mld() already fully checks the ICMPv6 header and hop-by-hop option. These issues were found and fixed with the help of the mrdisc tool (https://github.com/troglobit/mrdisc). Fixes: 4b3087c7e37f ("bridge: Snoop Multicast Router Advertisements") Signed-off-by: Linus Lüssing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit da5b49598a11644541b0a7d5d21727b8e94573c1 Author: Lv Yunlong Date: Mon Apr 26 07:06:14 2021 -0700 RDMA/bnxt_re: Fix a double free in bnxt_qplib_alloc_res [ Upstream commit 34b39efa5ae82fc0ad0acc27653c12a56328dbbe ] In bnxt_qplib_alloc_res, it calls bnxt_qplib_alloc_dpi_tbl(). Inside bnxt_qplib_alloc_dpi_tbl, dpit->dbr_bar_reg_iomem is freed via pci_iounmap() in unmap_io error branch. After the callee returns err code, bnxt_qplib_alloc_res calls bnxt_qplib_free_res()->bnxt_qplib_free_dpi_tbl() in the fail branch. Then dpit->dbr_bar_reg_iomem is freed in the second time by pci_iounmap(). My patch set dpit->dbr_bar_reg_iomem to NULL after it is freed by pci_iounmap() in the first time, to avoid the double free. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/20210426140614.6722-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Lv Yunlong Reviewed-by: Leon Romanovsky Acked-by: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 30b9e92d0b5e5d5dc1101ab856c17009537cbca4 Author: Lv Yunlong Date: Sun Apr 25 18:16:47 2021 -0700 RDMA/siw: Fix a use after free in siw_alloc_mr [ Upstream commit 3093ee182f01689b89e9f8797b321603e5de4f63 ] Our code analyzer reported a UAF. In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr). My patch moves "mr->mem = mem" behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf. Fixes: 2251334dcac9 ("rdma/siw: application buffer management") Link: https://lore.kernel.org/r/20210426011647.3561-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Lv Yunlong Reviewed-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 55fcdd1258faaecca74b91b88cc0921f9edd775d Author: Lv Yunlong Date: Mon Apr 26 09:06:25 2021 -0700 net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send [ Upstream commit 6d72e7c767acbbdd44ebc7d89c6690b405b32b57 ] In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven't modified the value of skb->len, thus my patch assigns skb->len to 'len' before the possible free and use 'len' instead of skb->len later. Fixes: b9b17debc69d2 ("net: emac: emac gigabit ethernet controller driver") Signed-off-by: Lv Yunlong Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b1523e4ba293b2a32d9fabaf70c1dcaa6e3e2847 Author: Michael Chan Date: Fri Apr 23 18:13:19 2021 -0400 bnxt_en: Fix RX consumer index logic in the error path. [ Upstream commit bbd6f0a948139970f4a615dff189d9a503681a39 ] In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 Fixes: a1b0e4e684e9 ("bnxt_en: Improve RX consumer index validity check.") Reviewed-by: Pavan Chebbi Reviewed-by: Andy Gospodarek Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d1ad9f2f7e2d47be13bb96cc1a98bc939ca144c7 Author: Petr Machata Date: Fri Apr 23 14:19:43 2021 +0200 selftests: net: mirror_gre_vlan_bridge_1q: Make an FDB entry static [ Upstream commit c8d0260cdd96fdccdef0509c4160e28a1012a5d7 ] The FDB roaming test installs a destination MAC address on the wrong interface of an FDB database and tests whether the mirroring fails, because packets are sent to the wrong port. The test by mistake installs the FDB entry as local. This worked previously, because drivers were notified of local FDB entries in the same way as of static entries. However that has been fixed in the commit 6ab4c3117aec ("net: bridge: don't notify switchdev for local FDB addresses"), and local entries are not notified anymore. As a result, the HW is not reconfigured for the FDB roam, and mirroring keeps working, failing the test. To fix the issue, mark the FDB entry as static. Fixes: 9c7c8a82442c ("selftests: forwarding: mirror_gre_vlan_bridge_1q: Add more tests") Signed-off-by: Petr Machata Reviewed-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6f92124d74419797fadfbcd5b7a72c384a6413ad Author: Phillip Potter Date: Fri Apr 23 00:49:45 2021 +0100 net: geneve: modify IP header check in geneve6_xmit_skb and geneve_xmit_skb [ Upstream commit d13f048dd40e8577260cd43faea8ec9b77520197 ] Modify the header size check in geneve6_xmit_skb and geneve_xmit_skb to use pskb_inet_may_pull rather than pskb_network_may_pull. This fixes two kernel selftest failures introduced by the commit introducing the checks: IPv4 over geneve6: PMTU exceptions IPv4 over geneve6: PMTU exceptions - nexthop objects It does this by correctly accounting for the fact that IPv4 packets may transit over geneve IPv6 tunnels (and vice versa), and still fixes the uninit-value bug fixed by the original commit. Reported-by: kernel test robot Fixes: 6628ddfec758 ("net: geneve: check skb is large enough for IPv4/IPv6 header") Suggested-by: Sabrina Dubroca Signed-off-by: Phillip Potter Acked-by: Sabrina Dubroca Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 06e03b867d96b3c0ef028b94fac99fd864218ccc Author: Kunihiko Hayashi Date: Fri Apr 23 02:31:49 2021 +0900 arm64: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E [ Upstream commit dcabb06bf127b3e0d3fbc94a2b65dd56c2725851 ] UniPhier LD20 and PXs3 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins. After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled. Fixes: c73730ee4c9a ("arm64: dts: uniphier: add AVE ethernet node") Signed-off-by: Kunihiko Hayashi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 978170191d3d3dbd450b2a752d5984e7ab40b431 Author: Kunihiko Hayashi Date: Fri Apr 23 02:31:48 2021 +0900 ARM: dts: uniphier: Change phy-mode to RGMII-ID to enable delay pins for RTL8211E [ Upstream commit 9ba585cc5b56ea14a453ba6be9bdb984ed33471a ] UniPhier PXs2 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins. After the commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled. Fixes: e3cc931921d2 ("ARM: dts: uniphier: add AVE ethernet node") Signed-off-by: Kunihiko Hayashi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4bfea784ea354fb7fa0d16eb6a79839124bb73e1 Author: Dan Carpenter Date: Thu Apr 22 12:10:28 2021 +0300 bnxt_en: fix ternary sign extension bug in bnxt_show_temp() [ Upstream commit 27537929f30d3136a71ef29db56127a33c92dad7 ] The problem is that bnxt_show_temp() returns long but "rc" is an int and "len" is a u32. With ternary operations the type promotion is quite tricky. The negative "rc" is first promoted to u32 and then to long so it ends up being a high positive value instead of a a negative as we intended. Fix this by removing the ternary. Fixes: d69753fa1ecb ("bnxt_en: return proper error codes in bnxt_show_temp") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 10ff6ad91e0d1ef9646c9aeaa018c506e2421d1a Author: Christophe Leroy Date: Wed Apr 21 17:24:03 2021 +0000 powerpc/52xx: Fix an invalid ASM expression ('addi' used instead of 'add') [ Upstream commit 8a87a507714386efc39c3ae6fa24d4f79846b522 ] AS arch/powerpc/platforms/52xx/lite5200_sleep.o arch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages: arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression In the following code, 'addi' is wrong, has to be 'add' /* local udelay in sram is needed */ udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */ mullw r12, r12, r11 mftb r13 /* start */ addi r12, r13, r12 /* end */ Fixes: ee983079ce04 ("[POWERPC] MPC5200 low power mode") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/cb4cec9131c8577803367f1699209a7e104cec2a.1619025821.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit c6af4c1d196e282ff202e95df3fc3bc8ffbb0618 Author: Shuah Khan Date: Tue Apr 6 17:02:28 2021 -0600 ath10k: Fix ath10k_wmi_tlv_op_pull_peer_stats_info() unlock without lock [ Upstream commit eaaf52e4b866f265eb791897d622961293fd48c1 ] ath10k_wmi_tlv_op_pull_peer_stats_info() could try to unlock RCU lock winthout locking it first when peer reason doesn't match the valid cases for this function. Add a default case to return without unlocking. Fixes: 09078368d516 ("ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()") Reported-by: Pavel Machek Signed-off-by: Shuah Khan Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210406230228.31301-1-skhan@linuxfoundation.org Signed-off-by: Sasha Levin commit bf0be675e64664505f0ba9132e382742722310d5 Author: Toke Høiland-Jørgensen Date: Fri Mar 26 19:08:19 2021 +0100 ath9k: Fix error check in ath9k_hw_read_revisions() for PCI devices [ Upstream commit 7dd9a40fd6e0d0f1fd8e1931c007e080801dfdce ] When the error check in ath9k_hw_read_revisions() was added, it checked for -EIO which is what ath9k_regread() in the ath9k_htc driver uses. However, for plain ath9k, the register read function uses ioread32(), which just returns -1 on error. So if such a read fails, it still gets passed through and ends up as a weird mac revision in the log output. Fix this by changing ath9k_regread() to return -1 on error like ioread32() does, and fix the error check to look for that instead of -EIO. Fixes: 2f90c7e5d094 ("ath9k: Check for errors when reading SREV register") Signed-off-by: Toke Høiland-Jørgensen Reviewed-by: Lorenzo Bianconi Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210326180819.142480-1-toke@redhat.com Signed-off-by: Sasha Levin commit 87fc6b2914e52653970ff7630d9b52bd077d10e7 Author: Martin Schiller Date: Wed Apr 21 07:50:47 2021 +0200 net: phy: intel-xway: enable integrated led functions [ Upstream commit 357a07c26697a770d39d28b6b111f978deb4017d ] The Intel xway phys offer the possibility to deactivate the integrated LED function and to control the LEDs manually. If this was set by the bootloader, it must be ensured that the integrated LED function is enabled for all LEDs when loading the driver. Before commit 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") the LEDs were enabled by a soft-reset of the PHY (using genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default value (which is applied during a soft reset) instead of adding back the soft reset. This brings back the default LED configuration while still preventing an excessive amount of soft resets. Fixes: 6e2d85ec0559 ("net: phy: Stop with excessive soft reset") Signed-off-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 57bed78ce64a0aabd46fafb1bbd47f6b3ca05a2d Author: Yoshihiro Shimoda Date: Wed Apr 21 13:52:46 2021 +0900 net: renesas: ravb: Fix a stuck issue when a lot of frames are received [ Upstream commit 5718458b092bf6bf4482c5df32affba3c3259517 ] When a lot of frames were received in the short term, the driver caused a stuck of receiving until a new frame was received. For example, the following command from other device could cause this issue. $ sudo ping -f -l 1000 -c 1000 The previous code always cleared the interrupt flag of RX but checks the interrupt flags in ravb_poll(). So, ravb_poll() could not call ravb_rx() in the next time until a new RX frame was received if ravb_rx() returned true. To fix the issue, always calls ravb_rx() regardless the interrupt flags condition. Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper") Signed-off-by: Yoshihiro Shimoda Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 27a894a9556fc99ad9c81a084225a28d9ac62ee2 Author: Colin Ian King Date: Tue Apr 20 18:16:14 2021 +0100 net: davinci_emac: Fix incorrect masking of tx and rx error channel [ Upstream commit d83b8aa5207d81f9f6daec9888390f079cc5db3f ] The bit-masks used for the TXERRCH and RXERRCH (tx and rx error channels) are incorrect and always lead to a zero result. The mask values are currently the incorrect post-right shifted values, fix this by setting them to the currect values. (I double checked these against the TMS320TCI6482 data sheet, section 5.30, page 127 to ensure I had the correct mask values for the TXERRCH and RXERRCH fields in the MACSTATUS register). Addresses-Coverity: ("Operands don't affect result") Fixes: a6286ee630f6 ("net: Add TI DaVinci EMAC driver") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8d77c9564309808b523f7afafd192f92b1fb9a48 Author: Colin Ian King Date: Tue Apr 20 14:47:19 2021 +0100 ALSA: usb: midi: don't return -ENOMEM when usb_urb_ep_type_check fails [ Upstream commit cfd577acb769301b19c31361d45ae1f145318b7a ] Currently when the call to usb_urb_ep_type_check fails (returning -EINVAL) the error return path returns -ENOMEM via the exit label "error". Other uses of the same error exit label set the err variable to -ENOMEM but this is not being used. I believe the original intent was for the error exit path to return the value in err rather than the hard coded -ENOMEM, so return this rather than the hard coded -ENOMEM. Addresses-Coverity: ("Unused value") Fixes: 738d9edcfd44 ("ALSA: usb-audio: Add sanity checks for invalid EPs") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210420134719.381409-1-colin.king@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 59f965ef61d7f10dcadc8a927e2c1f4881193664 Author: Sindhu Devale Date: Thu Apr 15 19:21:04 2021 -0500 RDMA/i40iw: Fix error unwinding when i40iw_hmc_sd_one fails [ Upstream commit 783a11bf2400e5d5c42a943c3083dc0330751842 ] When i40iw_hmc_sd_one fails, chunk is freed without the deletion of chunk entry in the PBLE info list. Fix it by adding the chunk entry to the PBLE info list only after successful addition of SD in i40iw_hmc_sd_one. This fixes a static checker warning reported here: https://lore.kernel.org/linux-rdma/YHV4CFXzqTm23AOZ@mwanda/ Fixes: 9715830157be ("i40iw: add pble resource files") Link: https://lore.kernel.org/r/20210416002104.323-1-shiraz.saleem@intel.com Reported-by: Dan Carpenter Signed-off-by: Sindhu Devale Signed-off-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d7ba506b00ea7b46c8eb3288ab8fc7437d13b7ad Author: Potnuri Bharat Teja Date: Thu Apr 15 20:44:22 2021 +0530 RDMA/cxgb4: add missing qpid increment [ Upstream commit 3a6684385928d00b29acac7658a5ae1f2a44494c ] missing qpid increment leads to skipping few qpids while allocating QP. This eventually leads to adapter running out of qpids after establishing fewer connections than it actually supports. Current patch increments the qpid correctly. Fixes: cfdda9d76436 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Link: https://lore.kernel.org/r/20210415151422.9139-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f7368865da57ec089a18c113873689e25fcb542c Author: Alexander Lobakin Date: Mon Apr 19 12:53:06 2021 +0000 gro: fix napi_gro_frags() Fast GRO breakage due to IP alignment check [ Upstream commit 7ad18ff6449cbd6beb26b53128ddf56d2685aa93 ] Commit 38ec4944b593 ("gro: ensure frag0 meets IP header alignment") did the right thing, but missed the fact that napi_gro_frags() logics calls for skb_gro_reset_offset() *before* pulling Ethernet header to the skb linear space. That said, the introduced check for frag0 address being aligned to 4 always fails for it as Ethernet header is obviously 14 bytes long, and in case with NET_IP_ALIGN its start is not aligned to 4. Fix this by adding @nhoff argument to skb_gro_reset_offset() which tells if an IP header is placed right at the start of frag0 or not. This restores Fast GRO for napi_gro_frags() that became very slow after the mentioned commit, and preserves the introduced check to avoid silent unaligned accesses. From v1 [0]: - inline tiny skb_gro_reset_offset() to let the code be optimized more efficively (esp. for the !NET_IP_ALIGN case) (Eric); - pull in Reviewed-by from Eric. [0] https://lore.kernel.org/netdev/20210418114200.5839-1-alobakin@pm.me Fixes: 38ec4944b593 ("gro: ensure frag0 meets IP header alignment") Reviewed-by: Eric Dumazet Signed-off-by: Alexander Lobakin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e97aea9f2503063cfad8bebb933276080ec483fb Author: Stefano Garzarella Date: Fri Apr 16 12:44:16 2021 +0200 vsock/vmci: log once the failed queue pair allocation [ Upstream commit e16edc99d658cd41c60a44cc14d170697aa3271f ] VMCI feature is not supported in conjunction with the vSphere Fault Tolerance (FT) feature. VMware Tools can repeatedly try to create a vsock connection. If FT is enabled the kernel logs is flooded with the following messages: qp_alloc_hypercall result = -20 Could not attach to queue pair with -20 "qp_alloc_hypercall result = -20" was hidden by commit e8266c4c3307 ("VMCI: Stop log spew when qp allocation isn't possible"), but "Could not attach to queue pair with -20" is still there flooding the log. Since the error message can be useful in some cases, print it only once. Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: Stefano Garzarella Reviewed-by: Jorgen Hansen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4691351003257d45e2562949a6ed8739992a131d Author: Lv Yunlong Date: Fri Apr 2 11:26:27 2021 -0700 mwl8k: Fix a double Free in mwl8k_probe_hw [ Upstream commit a8e083ee8e2a6c94c29733835adae8bf5b832748 ] In mwl8k_probe_hw, hw->priv->txq is freed at the first time by dma_free_coherent() in the call chain: if(!priv->ap_fw)->mwl8k_init_txqs(hw)->mwl8k_txq_init(hw, i). Then in err_free_queues of mwl8k_probe_hw, hw->priv->txq is freed at the second time by mwl8k_txq_deinit(hw, i)->dma_free_coherent(). My patch set txq->txd to NULL after the first free to avoid the double free. Fixes: a66098daacee2 ("mwl8k: Marvell TOPDOG wireless driver") Signed-off-by: Lv Yunlong Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210402182627.4256-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Sasha Levin commit afb735e764baac10472b3b7e6b54236879db5a57 Author: Sergey Shtylyov Date: Sat Apr 17 22:05:05 2021 +0300 i2c: sh7760: fix IRQ error path [ Upstream commit 92dfb27240fea2776f61c5422472cb6defca7767 ] While adding the invalid IRQ check after calling platform_get_irq(), I managed to overlook that the driver has a complex error path in its probe() method, thus a simple *return* couldn't be used. Use a proper *goto* instead! Fixes: e5b2e3e74201 ("i2c: sh7760: add IRQ check") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit da80b35b6e2613eb9dc83d097bd8131373fa1c81 Author: Ping-Ke Shih Date: Fri Feb 19 13:26:07 2021 +0800 rtlwifi: 8821ae: upgrade PHY and RF parameters [ Upstream commit 18fb0bedb5fc2fddc057dbe48b7360a6ffda34b3 ] The signal strength of 5G is quite low, so user can't connect to an AP far away. New parameters with new format and its parser are updated by the commit 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser."), but some parameters are missing. Use this commit to update to the novel parameters that use new format. Fixes: 84d26fda52e2 ("rtlwifi: Update 8821ae new phy parameters and its parser") Signed-off-by: Ping-Ke Shih Tested-by: Kai-Heng Feng Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210219052607.7323-1-pkshih@realtek.com Signed-off-by: Sasha Levin commit b1b8d90d45508ddc37d07e667f26d1e1c17be597 Author: Tyrel Datwyler Date: Thu Feb 11 12:24:35 2021 -0600 powerpc/pseries: extract host bridge from pci_bus prior to bus removal [ Upstream commit 38d0b1c9cec71e6d0f3bddef0bbce41d05a3e796 ] The pci_bus->bridge reference may no longer be valid after pci_bus_remove() resulting in passing a bad value to device_unregister() for the associated bridge device. Store the host_bridge reference in a separate variable prior to pci_bus_remove(). Fixes: 7340056567e3 ("powerpc/pci: Reorder pci bus/bridge unregistration during PHB removal") Signed-off-by: Tyrel Datwyler Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210211182435.47968-1-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit bdad13dd15e2f87e7cebbfc0e6368c28e4e1647e Author: Ilya Lipnitskiy Date: Tue Apr 13 20:12:37 2021 -0700 MIPS: pci-legacy: stop using of_pci_range_to_resource [ Upstream commit 3ecb9dc1581eebecaee56decac70e35365260866 ] Mirror commit aeba3731b150 ("powerpc/pci: Fix IO space breakage after of_pci_range_to_resource() change"). Most MIPS platforms do not define PCI_IOBASE, nor implement pci_address_to_pio(). Moreover, IO_SPACE_LIMIT is 0xffff for most MIPS platforms. of_pci_range_to_resource passes the _start address_ of the IO range into pci_address_to_pio, which then checks it against IO_SPACE_LIMIT and fails, because for MIPS platforms that use pci-legacy (pci-lantiq, pci-rt3883, pci-mt7620), IO ranges start much higher than 0xffff. In fact, pci-mt7621 in staging already works around this problem, see commit 09dd629eeabb ("staging: mt7621-pci: fix io space and properly set resource limits") So just stop using of_pci_range_to_resource, which does not work for MIPS. Fixes PCI errors like: pci_bus 0000:00: root bus resource [io 0xffffffff] Fixes: 0b0b0893d49b ("of/pci: Fix the conversion of IO ranges into IO resources") Signed-off-by: Ilya Lipnitskiy Cc: Liviu Dudau Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 5950c9d7f9873bd19e686bfc07492a22fadea7a3 Author: Vitaly Chikunov Date: Wed Apr 14 21:27:23 2021 +0300 perf beauty: Fix fsconfig generator [ Upstream commit 2e1daee14e67fbf9b27280b974e2c680a22cabea ] After gnulib update sed stopped matching `[[:space:]]*+' as before, causing the following compilation error: In file included from builtin-trace.c:719: trace/beauty/generated/fsconfig_arrays.c:2:3: error: expected expression before ']' token 2 | [] = "", | ^ trace/beauty/generated/fsconfig_arrays.c:2:3: error: array index in initializer not of integer type trace/beauty/generated/fsconfig_arrays.c:2:3: note: (near initialization for 'fsconfig_cmds') Fix this by correcting the regular expression used in the generator. Also, clean up the script by removing redundant egrep, xargs, and printf invocations. Committer testing: Continues to work: $ cat tools/perf/trace/beauty/fsconfig.sh #!/bin/sh # SPDX-License-Identifier: LGPL-2.1 if [ $# -ne 1 ] ; then linux_header_dir=tools/include/uapi/linux else linux_header_dir=$1 fi linux_mount=${linux_header_dir}/mount.h printf "static const char *fsconfig_cmds[] = {\n" ms='[[:space:]]*' sed -nr "s/^${ms}FSCONFIG_([[:alnum:]_]+)${ms}=${ms}([[:digit:]]+)${ms},.*/\t[\2] = \"\1\",/p" \ ${linux_mount} printf "};\n" $ tools/perf/trace/beauty/fsconfig.sh static const char *fsconfig_cmds[] = { [0] = "SET_FLAG", [1] = "SET_STRING", [2] = "SET_BINARY", [3] = "SET_PATH", [4] = "SET_PATH_EMPTY", [5] = "SET_FD", [6] = "CMD_CREATE", [7] = "CMD_RECONFIGURE", }; $ Fixes: d35293004a5e4 ("perf beauty: Add generator for fsconfig's 'cmd' arg values") Signed-off-by: Vitaly Chikunov Co-authored-by: Dmitry V. Levin Tested-by: Arnaldo Carvalho de Melo Link: http://lore.kernel.org/lkml/20210414182723.1670663-1-vt@altlinux.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0ff76bd07bc44ecb9ed508e362fdf6db3fcda95a Author: Dan Carpenter Date: Wed Apr 14 09:01:38 2021 +0300 drm/i915/gvt: Fix error code in intel_gvt_init_device() [ Upstream commit 329328ec6a87f2c1275f50d979d55513de458409 ] The intel_gvt_init_vgpu_type_groups() function is only called from intel_gvt_init_device(). If it fails then the intel_gvt_init_device() prints the error code and propagates it back again. That's a bug because false is zero/success. The fix is to modify it to return zero or negative error codes and make everything consistent. Fixes: c5d71cb31723 ("drm/i915/gvt: Move vGPU type related code into gvt file") Signed-off-by: Dan Carpenter Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/YHaFQtk/DIVYK1u5@mwanda Reviewed-by: Zhenyu Wang Signed-off-by: Sasha Levin commit ecfbcb8580071e7024ed8d9b25e6b2c7de2cb5f6 Author: Shengjiu Wang Date: Wed Apr 14 14:33:43 2021 +0800 ASoC: ak5558: correct reset polarity [ Upstream commit 0b93bbc977af55fd10687f2c96c807cba95cb927 ] Reset (aka power off) happens when the reset gpio is made active. The reset gpio is GPIO_ACTIVE_LOW Fixes: 920884777480 ("ASoC: ak5558: Add support for AK5558 ADC driver") Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1618382024-31725-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c77bf004717d3f276b4e3eb77d0393d8ca2bf7a8 Author: Cédric Le Goater Date: Wed Mar 31 16:45:12 2021 +0200 powerpc/xive: Fix xmon command "dxi" [ Upstream commit 33e4bc5946432a4ac173fd08e8e30a13ab94d06d ] When under xmon, the "dxi" command dumps the state of the XIVE interrupts. If an interrupt number is specified, only the state of the associated XIVE interrupt is dumped. This form of the command lacks an irq_data parameter which is nevertheless used by xmon_xive_get_irq_config(), leading to an xmon crash. Fix that by doing a lookup in the system IRQ mapping to query the IRQ descriptor data. Invalid interrupt numbers, or not belonging to the XIVE IRQ domain, OPAL event interrupt number for instance, should be caught by the previous query done at the firmware level. Fixes: 97ef27507793 ("powerpc/xive: Fix xmon support on the PowerNV platform") Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Cédric Le Goater Tested-by: Greg Kurz Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210331144514.892250-8-clg@kaod.org Signed-off-by: Sasha Levin commit 65b771660f573bf1f92def70d69768e9593dc4ec Author: Sergey Shtylyov Date: Sat Apr 10 23:25:10 2021 +0300 i2c: sh7760: add IRQ check [ Upstream commit e5b2e3e742015dd2aa6bc7bcef2cb59b2de1221c ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: a26c20b1fa6d ("i2c: Renesas SH7760 I2C master driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit cb834ff29bdb7fa295b90b24f34af403d7f5f8b1 Author: Sergey Shtylyov Date: Sat Apr 10 23:18:31 2021 +0300 i2c: jz4780: add IRQ check [ Upstream commit c5e5f7a8d931fb4beba245bdbc94734175fda9de ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: ba92222ed63a ("i2c: jz4780: Add i2c bus controller driver for Ingenic JZ4780") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit aa90700f953a9dced5064df0a88d3c8a70e5ae5b Author: Sergey Shtylyov Date: Sat Apr 10 23:16:41 2021 +0300 i2c: emev2: add IRQ check [ Upstream commit bb6129c32867baa7988f7fd2066cf18ed662d240 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: 5faf6e1f58b4 ("i2c: emev2: add driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 45f02a0f8ded3b028b80e62930120ffd3d20c76b Author: Sergey Shtylyov Date: Sat Apr 10 23:14:35 2021 +0300 i2c: cadence: add IRQ check [ Upstream commit 5581c2c5d02bc63a0edb53e061c8e97cd490646e ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to devm_request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original error code. Stop calling devm_request_irq() with invalid IRQ #s. Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller") Signed-off-by: Sergey Shtylyov Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 7e1764312440c5df9dfe6b436035a03673b0c1b9 Author: Qinglang Miao Date: Tue Dec 1 17:31:44 2020 +0800 i2c: sprd: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 3a4f326463117cee3adcb72999ca34a9aaafda93 ] The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 5f51ddcbfc78088804f13391991d2d50214d42b5 Author: Qinglang Miao Date: Tue Dec 1 17:31:43 2020 +0800 i2c: omap: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 780f629741257ed6c54bd3eb53b57f648eabf200 ] The PM reference count is not expected to be incremented on return in omap_i2c_probe() and omap_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. I Replace it with pm_runtime_resume_and_get to keep usage counter balanced. What's more, error path 'err_free_mem' seems not like a proper name any more. So I change the name to err_disable_pm and move pm_runtime_disable below, for pm_runtime of 'pdev->dev' should be disabled when pm_runtime_resume_and_get fails. Fixes: 3b0fb97c8dc4 ("I2C: OMAP: Handle error check for pm runtime") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Reviewed-by: Grygorii Strashko Reviewed-by: Vignesh Raghavendra Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 815859cb1d2302e74f11bf6894bceace9ca9eb4a Author: Qinglang Miao Date: Tue Dec 1 17:31:40 2020 +0800 i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 278e5bbdb9a94fa063c0f9bcde2479d0b8042462 ] The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 13d6eb20fc79 ("i2c: imx-lpi2c: add runtime pm support") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 4734c4b1d9573c9d20bbc46cf37dde095ee011b8 Author: Qinglang Miao Date: Tue Dec 1 17:31:39 2020 +0800 i2c: img-scb: fix reference leak when pm_runtime_get_sync fails [ Upstream commit 223125e37af8a641ea4a09747a6a52172fc4b903 ] The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 93222bd9b966 ("i2c: img-scb: Add runtime PM") Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ed016b77012ee53a569c36b1a1d24e5e60f4672a Author: Wang Wensheng Date: Thu Apr 8 11:31:32 2021 +0000 RDMA/srpt: Fix error return code in srpt_cm_req_recv() [ Upstream commit 6bc950beff0c440ac567cdc4e7f4542a9920953d ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race conditions") Link: https://lore.kernel.org/r/20210408113132.87250-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e1d10b2cc79284c82ff882ec418b2ae1dc639db4 Author: Colin Ian King Date: Fri Apr 9 14:07:26 2021 +0100 net: thunderx: Fix unintentional sign extension issue [ Upstream commit e701a25840360706fe4cf5de0015913ca19c274b ] The shifting of the u8 integers rq->caching by 26 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that rq->caching is greater than 0x1f then all then all the upper 32 bits of the u64 end up as also being set because of the int sign-extension. Fix this by casting the u8 values to a u64 before the 26 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b0d8fa3adc9d59e0e0d41a568ce3467739353d93 Author: Colin Ian King Date: Fri Apr 9 12:08:57 2021 +0100 cxgb4: Fix unintentional sign extension issues [ Upstream commit dd2c79677375c37f8f9f8d663eb4708495d595ef ] The shifting of the u8 integers f->fs.nat_lip[] by 24 bits to the left will be promoted to a 32 bit signed int and then sign-extended to a u64. In the event that the top bit of the u8 is set then all then all the upper 32 bits of the u64 end up as also being set because of the sign-extension. Fix this by casting the u8 values to a u64 before the 24 bit left shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 12b276fbf6e0 ("cxgb4: add support to create hash filters") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 05692b9523654ab48174dda83617ea45a3734fd5 Author: Wang Wensheng Date: Thu Apr 8 11:31:40 2021 +0000 IB/hfi1: Fix error return code in parse_platform_config() [ Upstream commit 4c7d9c69adadfc31892c7e8e134deb3546552106 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210408113140.103032-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 53656a2a01834e3d90fb2813ae5c82febcb96218 Author: Wang Wensheng Date: Thu Apr 8 11:31:35 2021 +0000 RDMA/qedr: Fix error return code in qedr_iw_connect() [ Upstream commit 10dd83dbcd157baf7a78a09ddb2f84c627bc7f1d ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 82af6d19d8d9 ("RDMA/qedr: Fix synchronization methods and memory leaks in qedr") Link: https://lore.kernel.org/r/20210408113135.92165-1-wangwensheng4@huawei.com Reported-by: Hulk Robot Signed-off-by: Wang Wensheng Acked-by: Michal Kalderon  Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit bf365066fbe037602c7d0ab8ee369dcdaec5e634 Author: Nicholas Piggin Date: Mon Apr 12 11:48:34 2021 +1000 KVM: PPC: Book3S HV P9: Restore host CTRL SPR after guest exit [ Upstream commit 5088eb4092df12d701af8e0e92860b7186365279 ] The host CTRL (runlatch) value is not restored after guest exit. The host CTRL should always be 1 except in CPU idle code, so this can result in the host running with runlatch clear, and potentially switching to a different vCPU which then runs with runlatch clear as well. This has little effect on P9 machines, CTRL is only responsible for some PMU counter logic in the host and so other than corner cases of software relying on that, or explicitly reading the runlatch value (Linux does not appear to be affected but it's possible non-Linux guests could be), there should be no execution correctness problem, though it could be used as a covert channel between guests. There may be microcontrollers, firmware or monitoring tools that sample the runlatch value out-of-band, however since the register is writable by guests, these values would (should) not be relied upon for correct operation of the host, so suboptimal performance or incorrect reporting should be the worst problem. Fixes: 95a6432ce9038 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210412014845.1517916-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit af5a87a1d41339d8bac1a2fcb3106c3ba11a7f6d Author: Colin Ian King Date: Thu Feb 25 18:32:41 2021 +0000 mt7601u: fix always true expression [ Upstream commit 87fce88658ba047ae62e83497d3f3c5dc22fa6f9 ] Currently the expression ~nic_conf1 is always true because nic_conf1 is a u16 and according to 6.5.3.3 of the C standard the ~ operator promotes the u16 to an integer before flipping all the bits. Thus the top 16 bits of the integer result are all set so the expression is always true. If the intention was to flip all the bits of nic_conf1 then casting the integer result back to a u16 is a suitabel fix. Interestingly static analyzers seem to thing a bitwise ! should be used instead of ~ for this scenario, so I think the original intent of the expression may need some extra consideration. Addresses-Coverity: ("Logical vs. bitwise operator") Fixes: c869f77d6abb ("add mt7601u driver") Signed-off-by: Colin Ian King Acked-by: Jakub Kicinski Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210225183241.1002129-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 53ada35f2ecc125860a7d76bdded6bf336583774 Author: Johannes Berg Date: Thu Apr 8 14:31:50 2021 +0200 mac80211: bail out if cipher schemes are invalid [ Upstream commit db878e27a98106a70315d264cc92230d84009e72 ] If any of the cipher schemes specified by the driver are invalid, bail out and fail the registration rather than just warning. Otherwise, we might later crash when we try to use the invalid cipher scheme, e.g. if the hdr_len is (significantly) less than the pn_offs + pn_len, we'd have an out-of-bounds access in RX validation. Fixes: 2475b1cc0d52 ("mac80211: add generic cipher scheme support") Link: https://lore.kernel.org/r/20210408143149.38a3a13a1b19.I6b7f5790fa0958ed8049cf02ac2a535c61e9bc96@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 22cb8496f290dfe8113c80f29356c212eeeebc9a Author: Randy Dunlap Date: Sun Apr 4 12:26:23 2021 -0700 powerpc: iommu: fix build when neither PCI or IBMVIO is set [ Upstream commit b27dadecdf9102838331b9a0b41ffc1cfe288154 ] When neither CONFIG_PCI nor CONFIG_IBMVIO is set/enabled, iommu.c has a build error. The fault injection code is not useful in that kernel config, so make the FAIL_IOMMU option depend on PCI || IBMVIO. Prevents this build error (warning escalated to error): ../arch/powerpc/kernel/iommu.c:178:30: error: 'fail_iommu_bus_notifier' defined but not used [-Werror=unused-variable] 178 | static struct notifier_block fail_iommu_bus_notifier = { Fixes: d6b9a81b2a45 ("powerpc: IOMMU fault injection") Reported-by: kernel test robot Suggested-by: Michael Ellerman Signed-off-by: Randy Dunlap Acked-by: Randy Dunlap # build-tested Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210404192623.10697-1-rdunlap@infradead.org Signed-off-by: Sasha Levin commit 5aa028a827fede15ac9f71f1b2c2400916001fc7 Author: Athira Rajeev Date: Tue Apr 6 12:16:01 2021 -0400 powerpc/perf: Fix PMU constraint check for EBB events [ Upstream commit 10f8f96179ecc7f69c927f6d231f6d02736cea83 ] The power PMU group constraints includes check for EBB events to make sure all events in a group must agree on EBB. This will prevent scheduling EBB and non-EBB events together. But in the existing check, settings for constraint mask and value is interchanged. Patch fixes the same. Before the patch, PMU selftest "cpu_event_pinned_vs_ebb_test" fails with below in dmesg logs. This happens because EBB event gets enabled along with a non-EBB cpu event. [35600.453346] cpu_event_pinne[41326]: illegal instruction (4) at 10004a18 nip 10004a18 lr 100049f8 code 1 in cpu_event_pinned_vs_ebb_test[10000000+10000] Test results after the patch: $ ./pmu/ebb/cpu_event_pinned_vs_ebb_test test: cpu_event_pinned_vs_ebb tags: git_version:v5.12-rc5-93-gf28c3125acd3-dirty Binding to cpu 8 EBB Handler is at 0x100050c8 read error on event 0x7fffe6bd4040! PM_RUN_INST_CMPL: result 9872 running/enabled 37930432 success: cpu_event_pinned_vs_ebb This bug was hidden by other logic until commit 1908dc911792 (perf: Tweak perf_event_attr::exclusive semantics). Fixes: 4df489991182 ("powerpc/perf: Add power8 EBB support") Reported-by: Thadeu Lima de Souza Cascardo Signed-off-by: Athira Rajeev [mpe: Mention commit 1908dc911792] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1617725761-1464-1-git-send-email-atrajeev@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 73f9dccb29e4f82574bec2765c0090cdb0404301 Author: Jordan Niethe Date: Mon Feb 8 14:29:56 2021 +1100 powerpc/64s: Fix pte update for kernel memory on radix [ Upstream commit b8b2f37cf632434456182e9002d63cbc4cccc50c ] When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured - but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ------------[ ftrace bug ]------------ ftrace failed to modify [] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ------------[ cut here ]------------ WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call Trace: ftrace_bug+0x288/0x2e8 (unreliable) ftrace_modify_all_code+0x168/0x210 arch_ftrace_update_code+0x18/0x30 ftrace_run_update_code+0x44/0xc0 ftrace_startup+0xf8/0x1c0 register_ftrace_function+0x4c/0xc0 function_trace_init+0x80/0xb0 tracing_set_tracer+0x2a4/0x4f0 tracing_set_trace_write+0xd4/0x130 vfs_write+0xf0/0x330 ksys_write+0x84/0x140 system_call_exception+0x14c/0x230 system_call_common+0xf0/0x27c To fix this when updating kernel memory PTEs using ptesync. Fixes: f1cb8f9beba8 ("powerpc/64s/radix: avoid ptesync after set_pte and ptep_set_access_flags") Signed-off-by: Jordan Niethe Reviewed-by: Nicholas Piggin [mpe: Tidy up change log slightly] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210208032957.1232102-1-jniethe5@gmail.com Signed-off-by: Sasha Levin commit 440fead0fc81192d2f893e238378574f6d9fb3c3 Author: Colin Ian King Date: Wed Apr 7 11:12:48 2021 +0100 liquidio: Fix unintented sign extension of a left shift of a u16 [ Upstream commit 298b58f00c0f86868ea717426beb5c1198772f81 ] The macro CN23XX_PEM_BAR1_INDEX_REG is being used to shift oct->pcie_port (a u16) left 24 places. There are two subtle issues here, first the shift gets promoted to an signed int and then sign extended to a u64. If oct->pcie_port is 0x80 or more then the upper bits get sign extended to 1. Secondly shfiting a u16 24 bits will lead to an overflow so it needs to be cast to a u64 for all the bits to not overflow. It is entirely possible that the u16 port value is never large enough for this to fail, but it is useful to fix unintended overflows such as this. Fix this by casting the port parameter to the macro to a u64 before the shift. Addresses-Coverity: ("Unintended sign extension") Fixes: 5bc67f587ba7 ("liquidio: CN23XX register definitions") Signed-off-by: Colin Ian King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 92626cf41b0e8b83bce992609e0d299614b13e8d Author: Krzysztof Kozlowski Date: Wed Apr 7 11:20:27 2021 +0200 ASoC: simple-card: fix possible uninitialized single_cpu local variable [ Upstream commit fa74c223b6fd78a5314b4c61b9abdbed3c2185b4 ] The 'single_cpu' local variable is assigned by asoc_simple_parse_dai() and later used in a asoc_simple_canonicalize_cpu() call, assuming the entire function did not exit on errors. However the first function returns 0 if passed device_node is NULL, thus leaving the variable uninitialized and reporting success. Addresses-Coverity: Uninitialized scalar variable Fixes: 8f7f298a3337 ("ASoC: simple-card-utils: separate asoc_simple_card_parse_dai()") Signed-off-by: Krzysztof Kozlowski Acked-by: Sameer Pujar Link: https://lore.kernel.org/r/20210407092027.60769-1-krzysztof.kozlowski@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e1b01d914c310ce6307d3f4cefe2afdc4d557434 Author: Takashi Iwai Date: Tue Apr 6 13:35:34 2021 +0200 ALSA: usb-audio: Add error checks for usb_driver_claim_interface() calls [ Upstream commit 5fb45414ae03421255593fd5556aa2d1d82303aa ] There are a few calls of usb_driver_claim_interface() but all of those miss the proper error checks, as reported by Coverity. This patch adds those missing checks. Along with it, replace the magic pointer with -1 with a constant USB_AUDIO_IFACE_UNUSED for better readability. Reported-by: coverity-bot Addresses-Coverity-ID: 1475943 ("Error handling issues") Addresses-Coverity-ID: 1475944 ("Error handling issues") Addresses-Coverity-ID: 1475945 ("Error handling issues") Fixes: b1ce7ba619d9 ("ALSA: usb-audio: claim autodetected PCM interfaces all at once") Fixes: e5779998bf8b ("ALSA: usb-audio: refactor code") Link: https://lore.kernel.org/r/202104051059.FB7F3016@keescook Link: https://lore.kernel.org/r/20210406113534.30455-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 11fa9b38e030aa2afb009f2243471590c30a9eef Author: Álvaro Fernández Rojas Date: Sun Mar 14 17:43:46 2021 +0100 mips: bmips: fix syscon-reboot nodes [ Upstream commit cde58b861a1d365568588adda59d42351c0c4ad3 ] Commit a23c4134955e added the clock controller nodes, incorrectly changing the syscon-reboot nodes addresses. Fixes: a23c4134955e ("MIPS: BMIPS: add clock controller nodes") Signed-off-by: Álvaro Fernández Rojas Acked-by: Florian Fainelli Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit c8f7e2e04724c448df7608dcb00ae5a838befd40 Author: Salil Mehta Date: Mon Apr 5 18:28:25 2021 +0100 net: hns3: Limiting the scope of vector_ring_chain variable [ Upstream commit d392ecd1bc29ae15b0e284d5f732c2d36f244271 ] Limiting the scope of the variable vector_ring_chain to the block where it is used. Fixes: 424eb834a9be ("net: hns3: Unified HNS3 {VF|PF} Ethernet Driver for hip08 SoC") Signed-off-by: Salil Mehta Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit cab33b3b6da87df0b7d6def1b87f835c893cde04 Author: Dan Carpenter Date: Fri Apr 2 14:44:42 2021 +0300 nfc: pn533: prevent potential memory corruption [ Upstream commit ca4d4c34ae9aa5c3c0da76662c5e549d2fc0cc86 ] If the "type_a->nfcid_len" is too large then it would lead to memory corruption in pn533_target_found_type_a() when we do: memcpy(nfc_tgt->nfcid1, tgt_type_a->nfcid_data, nfc_tgt->nfcid1_len); Fixes: c3b1e1e8a76f ("NFC: Export NFCID1 from pn533") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit efb0f45b4535dd8ca31ae13528de890b8849965e Author: Andrew Scull Date: Thu Mar 18 14:33:07 2021 +0000 bug: Remove redundant condition check in report_bug [ Upstream commit 3ad1a6cb0abc63d036fc866bd7c2c5983516dec5 ] report_bug() will return early if it cannot find a bug corresponding to the provided address. The subsequent test for the bug will always be true so remove it. Fixes: 1b4cfe3c0a30d ("lib/bug.c: exclude non-BUG/WARN exceptions from report_bug()") Signed-off-by: Andrew Scull Cc: Peter Zijlstra Cc: "Steven Rostedt (VMware)" Reviewed-by: Steven Rostedt (VMware) Acked-by: Will Deacon Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210318143311.839894-2-ascull@google.com Signed-off-by: Sasha Levin commit 7628bc544ba8eff9ce021101c4acdd5ee176151c Author: Jia Zhou Date: Tue Mar 30 13:19:23 2021 +0200 ALSA: core: remove redundant spin_lock pair in snd_card_disconnect [ Upstream commit abc21649b3e5c34b143bf86f0c78e33d5815e250 ] modification in commit 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") resulting in this problem. Fixes: 2a3f7221acdd ("ALSA: core: Fix card races between register and disconnect") Signed-off-by: Jia Zhou Signed-off-by: Yi Wang Link: https://lore.kernel.org/r/1616989007-34429-1-git-send-email-wang.yi59@zte.com.cn Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3733a64d5828e72b46fd670b98435c11d291139e Author: Chen Huang Date: Sat Mar 27 09:49:00 2021 +0000 powerpc: Fix HAVE_HARDLOCKUP_DETECTOR_ARCH build configuration [ Upstream commit 4fe529449d85e78972fa327999961ecc83a0b6db ] When compiling the powerpc with the SMP disabled, it shows the issue: arch/powerpc/kernel/watchdog.c: In function ‘watchdog_smp_panic’: arch/powerpc/kernel/watchdog.c:177:4: error: implicit declaration of function ‘smp_send_nmi_ipi’; did you mean ‘smp_send_stop’? [-Werror=implicit-function-declaration] 177 | smp_send_nmi_ipi(c, wd_lockup_ipi, 1000000); | ^~~~~~~~~~~~~~~~ | smp_send_stop cc1: all warnings being treated as errors make[2]: *** [scripts/Makefile.build:273: arch/powerpc/kernel/watchdog.o] Error 1 make[1]: *** [scripts/Makefile.build:534: arch/powerpc/kernel] Error 2 make: *** [Makefile:1980: arch/powerpc] Error 2 make: *** Waiting for unfinished jobs.... We found that powerpc used ipi to implement hardlockup watchdog, so the HAVE_HARDLOCKUP_DETECTOR_ARCH should depend on the SMP. Fixes: 2104180a5369 ("powerpc/64s: implement arch-specific hardlockup watchdog") Reported-by: Hulk Robot Signed-off-by: Chen Huang Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210327094900.938555-1-chenhuang5@huawei.com Signed-off-by: Sasha Levin commit fee81285bd09ec2080ce2cbb5063aad0e58eb272 Author: Eric Dumazet Date: Wed Mar 24 14:53:37 2021 -0700 inet: use bigger hash table for IP ID generation [ Upstream commit aa6dd211e4b1dde9d5dc25d699d35f789ae7eeba ] In commit 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") I used a very small hash table that could be abused by patient attackers to reveal sensitive information. Switch to a dynamic sizing, depending on RAM size. Typical big hosts will now use 128x more storage (2 MB) to get a similar increase in security and reduction of hash collisions. As a bonus, use of alloc_large_system_hash() spreads allocated memory among all NUMA nodes. Fixes: 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") Reported-by: Amit Klein Signed-off-by: Eric Dumazet Cc: Willy Tarreau Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3189939494236f166a98163f2d396b27b4da6e40 Author: Nathan Chancellor Date: Tue Mar 2 13:08:29 2021 -0700 powerpc/prom: Mark identical_pvr_fixup as __init [ Upstream commit 1ef1dd9c7ed27b080445e1576e8a05957e0e4dfc ] If identical_pvr_fixup() is not inlined, there are two modpost warnings: WARNING: modpost: vmlinux.o(.text+0x54e8): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:of_get_flat_dt_prop() The function identical_pvr_fixup() references the function __init of_get_flat_dt_prop(). This is often because identical_pvr_fixup lacks a __init annotation or the annotation of of_get_flat_dt_prop is wrong. WARNING: modpost: vmlinux.o(.text+0x551c): Section mismatch in reference from the function identical_pvr_fixup() to the function .init.text:identify_cpu() The function identical_pvr_fixup() references the function __init identify_cpu(). This is often because identical_pvr_fixup lacks a __init annotation or the annotation of identify_cpu is wrong. identical_pvr_fixup() calls two functions marked as __init and is only called by a function marked as __init so it should be marked as __init as well. At the same time, remove the inline keywork as it is not necessary to inline this function. The compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely"). Fixes: 14b3d926a22b ("[POWERPC] 4xx: update 440EP(x)/440GR(x) identical PVR issue workaround") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/1316 Link: https://lore.kernel.org/r/20210302200829.2680663-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 4543fcd6835bf8a765648a2a393023dc32bea979 Author: Nathan Chancellor Date: Tue Mar 2 12:50:14 2021 -0700 powerpc/fadump: Mark fadump_calculate_reserve_size as __init [ Upstream commit fbced1546eaaab57a32e56c974ea8acf10c6abd8 ] If fadump_calculate_reserve_size() is not inlined, there is a modpost warning: WARNING: modpost: vmlinux.o(.text+0x5196c): Section mismatch in reference from the function fadump_calculate_reserve_size() to the function .init.text:parse_crashkernel() The function fadump_calculate_reserve_size() references the function __init parse_crashkernel(). This is often because fadump_calculate_reserve_size lacks a __init annotation or the annotation of parse_crashkernel is wrong. fadump_calculate_reserve_size() calls parse_crashkernel(), which is marked as __init and fadump_calculate_reserve_size() is called from within fadump_reserve_mem(), which is also marked as __init. Mark fadump_calculate_reserve_size() as __init to fix the section mismatch. Additionally, remove the inline keyword as it is not necessary to inline this function; the compiler is still free to do so if it feels it is worthwhile since commit 889b3c1245de ("compiler: remove CONFIG_OPTIMIZE_INLINING entirely"). Fixes: 11550dc0a00b ("powerpc/fadump: reuse crashkernel parameter for fadump memory reservation") Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/1300 Link: https://lore.kernel.org/r/20210302195013.2626335-1-nathan@kernel.org Signed-off-by: Sasha Levin commit e00c5b9eebf026a000e5f6d45520b1c4e99c71ac Author: Xie He Date: Wed Mar 10 23:23:09 2021 -0800 net: lapbether: Prevent racing when checking whether the netif is running [ Upstream commit 5acd0cfbfbb5a688da1bfb1a2152b0c855115a35 ] There are two "netif_running" checks in this driver. One is in "lapbeth_xmit" and the other is in "lapbeth_rcv". They serve to make sure that the LAPB APIs called in these functions are called before "lapb_unregister" is called by the "ndo_stop" function. However, these "netif_running" checks are unreliable, because it's possible that immediately after "netif_running" returns true, "ndo_stop" is called (which causes "lapb_unregister" to be called). This patch adds locking to make sure "lapbeth_xmit" and "lapbeth_rcv" can reliably check and ensure the netif is running while doing their work. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xie He Acked-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f937a0f6ada15e0de5e184b4d9de41665c423ec1 Author: Arnaldo Carvalho de Melo Date: Mon Mar 8 11:17:51 2021 -0300 perf symbols: Fix dso__fprintf_symbols_by_name() to return the number of printed chars [ Upstream commit 210e4c89ef61432040c6cd828fefa441f4887186 ] The 'ret' variable was initialized to zero but then it was not updated from the fprintf() return, fix it. Reported-by: Yang Li cc: Alexander Shishkin cc: Ingo Molnar cc: Jiri Olsa cc: Mark Rutland cc: Namhyung Kim Cc: Peter Zijlstra Cc: Srikar Dronamraju Fixes: 90f18e63fbd00513 ("perf symbols: List symbols in a dso in ascending name order") Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1121f5f3d4408c7d78a6f28e81e24a3467633e0f Author: Maxim Mikityanskiy Date: Sun Feb 7 16:47:40 2021 +0200 HID: plantronics: Workaround for double volume key presses [ Upstream commit f567d6ef8606fb427636e824c867229ecb5aefab ] Plantronics Blackwire 3220 Series (047f:c056) sends HID reports twice for each volume key press. This patch adds a quirk to hid-plantronics for this product ID, which will ignore the second volume key press if it happens within 5 ms from the last one that was handled. The patch was tested on the mentioned model only, it shouldn't affect other models, however, this quirk might be needed for them too. Auto-repeat (when a key is held pressed) is not affected, because the rate is about 3 times per second, which is far less frequent than once in 5 ms. Fixes: 81bb773faed7 ("HID: plantronics: Update to map volume up/down controls") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 59021008b317c79b260c94e1b3bfdd4d214d0065 Author: Lv Yunlong Date: Mon Apr 26 07:32:29 2021 -0700 drivers/block/null_blk/main: Fix a double free in null_init. [ Upstream commit 72ce11ddfa4e9e1879103581a60b7e34547eaa0a ] In null_init, null_add_dev(dev) is called. In null_add_dev, it calls null_free_zoned_dev(dev) to free dev->zones via kvfree(dev->zones) in out_cleanup_zone branch and returns err. Then null_init accept the err code and then calls null_free_dev(dev). But in null_free_dev(dev), dev->zones is freed again by null_free_zoned_dev(). My patch set dev->zones to NULL in null_free_zoned_dev() after kvfree(dev->zones) is called, to avoid the double free. Fixes: 2984c8684f962 ("nullb: factor disk parameters") Signed-off-by: Lv Yunlong Link: https://lore.kernel.org/r/20210426143229.7374-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 279749d0d4ef1e63a188d8b83bd71b90eb59b96a Author: Waiman Long Date: Thu Apr 15 15:54:26 2021 -0400 sched/debug: Fix cgroup_path[] serialization [ Upstream commit ad789f84c9a145f8a18744c0387cec22ec51651e ] The handling of sysrq key can be activated by echoing the key to /proc/sysrq-trigger or via the magic key sequence typed into a terminal that is connected to the system in some way (serial, USB or other mean). In the former case, the handling is done in a user context. In the latter case, it is likely to be in an interrupt context. Currently in print_cpu() of kernel/sched/debug.c, sched_debug_lock is taken with interrupt disabled for the whole duration of the calls to print_*_stats() and print_rq() which could last for the quite some time if the information dump happens on the serial console. If the system has many cpus and the sched_debug_lock is somehow busy (e.g. parallel sysrq-t), the system may hit a hard lockup panic depending on the actually serial console implementation of the system. The purpose of sched_debug_lock is to serialize the use of the global cgroup_path[] buffer in print_cpu(). The rests of the printk calls don't need serialization from sched_debug_lock. Calling printk() with interrupt disabled can still be problematic if multiple instances are running. Allocating a stack buffer of PATH_MAX bytes is not feasible because of the limited size of the kernel stack. The solution implemented in this patch is to allow only one caller at a time to use the full size group_path[], while other simultaneous callers will have to use shorter stack buffers with the possibility of path name truncation. A "..." suffix will be printed if truncation may have happened. The cgroup path name is provided for informational purpose only, so occasional path name truncation should not be a big problem. Fixes: efe25c2c7b3a ("sched: Reinstate group names in /proc/sched_debug") Suggested-by: Peter Zijlstra Signed-off-by: Waiman Long Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210415195426.6677-1-longman@redhat.com Signed-off-by: Sasha Levin commit c01fc0adba30c7f9c02709d4d6a476bb6278a7e5 Author: Nathan Chancellor Date: Wed Apr 14 17:11:11 2021 -0700 x86/events/amd/iommu: Fix sysfs type mismatch [ Upstream commit de5bc7b425d4c27ae5faa00ea7eb6b9780b9a355 ] dev_attr_show() calls _iommu_event_show() via an indirect call but _iommu_event_show()'s type does not currently match the type of the show() member in 'struct device_attribute', resulting in a Control Flow Integrity violation. $ cat /sys/devices/amd_iommu_1/events/mem_dte_hit csource=0x0a $ dmesg | grep "CFI failure" [ 3526.735140] CFI failure (target: _iommu_event_show...): Change _iommu_event_show() and 'struct amd_iommu_event_desc' to 'struct device_attribute' so that there is no more CFI violation. Fixes: 7be6296fdd75 ("perf/x86/amd: AMD IOMMU Performance Counter PERF uncore PMU implementation") Signed-off-by: Nathan Chancellor Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20210415001112.3024673-1-nathan@kernel.org Signed-off-by: Sasha Levin commit 8463576094093bca1d3b3ac4db1445c09be8aea5 Author: Dan Carpenter Date: Fri Apr 9 14:08:17 2021 +0300 HSI: core: fix resource leaks in hsi_add_client_from_dt() [ Upstream commit 5c08b0f75575648032f309a6f58294453423ed93 ] If some of the allocations fail between the dev_set_name() and the device_register() then the name will not be freed. Fix this by moving dev_set_name() directly in front of the call to device_register(). Fixes: a2aa24734d9d ("HSI: Add common DT binding for HSI client devices") Signed-off-by: Dan Carpenter Reviewed-by: Jason Gunthorpe Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit ff386ac0509823193d8f80069658d34cd4347c14 Author: Niklas Cassel Date: Fri Apr 9 20:12:55 2021 +0200 nvme-pci: don't simple map sgl when sgls are disabled [ Upstream commit e51183be1fa96dc6d3cd11b3c25a0f595807315e ] According to the module parameter description for sgl_threshold, a value of 0 means that SGLs are disabled. If SGLs are disabled, we should respect that, even for the case where the request is made up of a single physical segment. Fixes: 297910571f08 ("nvme-pci: optimize mapping single segment requests using SGLs") Signed-off-by: Niklas Cassel Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 7e1ab103f63f68a14effeee37dac258582c27533 Author: Fabrice Gasnier Date: Wed Mar 3 18:51:35 2021 +0100 mfd: stm32-timers: Avoid clearing auto reload register [ Upstream commit 4917e498c6894ba077867aff78f82cffd5ffbb5c ] The ARR register is cleared unconditionally upon probing, after the maximum value has been read. This initial condition is rather not intuitive, when considering the counter child driver. It rather expects the maximum value by default: - The counter interface shows a zero value by default for 'ceiling' attribute. - Enabling the counter without any prior configuration makes it doesn't count. The reset value of ARR register is the maximum. So Choice here is to backup it, and restore it then, instead of clearing its value. It also fixes the initial condition seen by the counter driver. Fixes: d0f949e220fd ("mfd: Add STM32 Timers driver") Signed-off-by: Fabrice Gasnier Acked-by: William Breathitt Gray Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit e8fe98f6ec696f390c1f6ad9ba965aa2a1c70b86 Author: Brian King Date: Mon Apr 12 18:10:09 2021 -0600 scsi: ibmvfc: Fix invalid state machine BUG_ON() [ Upstream commit 15cfef8623a449d40d16541687afd58e78033be3 ] This fixes an issue hitting the BUG_ON() in ibmvfc_do_work(). When going through a host action of IBMVFC_HOST_ACTION_RESET, we change the action to IBMVFC_HOST_ACTION_TGT_DEL, then drop the host lock, and reset the CRQ, which changes the host state to IBMVFC_NO_CRQ. If, prior to setting the host state to IBMVFC_NO_CRQ, ibmvfc_init_host() is called, it can then end up changing the host action to IBMVFC_HOST_ACTION_INIT. If we then change the host state to IBMVFC_NO_CRQ, we will then hit the BUG_ON(). Make a couple of changes to avoid this. Leave the host action to be IBMVFC_HOST_ACTION_RESET or IBMVFC_HOST_ACTION_REENABLE until after we drop the host lock and reset or reenable the CRQ. Also harden the host state machine to ensure we cannot leave the reset / reenable state until we've finished processing the reset or reenable. Link: https://lore.kernel.org/r/20210413001009.902400-1-tyreld@linux.ibm.com Fixes: 73ee5d867287 ("[SCSI] ibmvfc: Fix soft lockup on resume") Signed-off-by: Brian King [tyreld: added fixes tag] Signed-off-by: Tyrel Datwyler [mkp: fix comment checkpatch warnings] Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ce8585f979e4ddf46cc46e751903f64bc6f9e9f7 Author: Sergey Shtylyov Date: Tue Mar 30 20:45:12 2021 +0300 scsi: sni_53c710: Add IRQ check [ Upstream commit 1160d61bc51e87e509cfaf9da50a0060f67b6de4 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #s), causing it to fail with -EINVAL (overridden by -ENODEV further below). Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/8f4b8fa5-8251-b977-70a1-9099bcb4bb17@omprussia.ru Fixes: c27d85f3f3c5 ("[SCSI] SNI RM 53c710 driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1ff0b82c66745bc496e467f11c4a2cad1b01ae42 Author: Sergey Shtylyov Date: Tue Mar 30 20:44:08 2021 +0300 scsi: sun3x_esp: Add IRQ check [ Upstream commit 14b321380eb333c82853d7d612d0995f05f88fdc ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/363eb4c8-a3bf-4dc9-2a9e-90f349030a15@omprussia.ru Fixes: 0bb67f181834 ("[SCSI] sun3x_esp: convert to esp_scsi") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 4b94098f0aa72f22a51280694fe3915bb73f37bc Author: Sergey Shtylyov Date: Tue Mar 30 20:43:23 2021 +0300 scsi: jazz_esp: Add IRQ check [ Upstream commit 38fca15c29db6ed06e894ac194502633e2a7d1fb ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/594aa9ae-2215-49f6-f73c-33bd38989912@omprussia.ru Fixes: 352e921f0dd4 ("[SCSI] jazz_esp: converted to use esp_core") Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ae0cadd35daf99159545cc08bf82aac66a535888 Author: Sergey Shtylyov Date: Sat Apr 3 23:43:55 2021 +0300 scsi: hisi_sas: Fix IRQ checks [ Upstream commit 6c11dc060427e07ca144eacaccd696106b361b06 ] Commit df2d8213d9e3 ("hisi_sas: use platform_get_irq()") failed to take into account that irq_of_parse_and_map() and platform_get_irq() have a different way of indicating an error: the former returns 0 and the latter returns a negative error code. Fix up the IRQ checks! Link: https://lore.kernel.org/r/810f26d3-908b-1d6b-dc5c-40019726baca@omprussia.ru Fixes: df2d8213d9e3 ("hisi_sas: use platform_get_irq()") Acked-by: John Garry Signed-off-by: Sergey Shtylyov Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6adac4efe77d103925cf65d94f7a742d6a99294d Author: Colin Ian King Date: Fri Apr 9 10:01:03 2021 +0100 clk: uniphier: Fix potential infinite loop [ Upstream commit f6b1340dc751a6caa2a0567b667d0f4f4172cd58 ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of num_parents that is an int type. There is a potential infinite loop if num_parents is larger than the u8 loop counter. Fix this by making the loop counter the same type as num_parents. Also make num_parents an unsigned int to match the return type of the call to clk_hw_get_num_parents. Addresses-Coverity: ("Infinite loop") Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver") Signed-off-by: Colin Ian King Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210409090104.629722-1-colin.king@canonical.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit e1a5c8594c0ed73b0123b4df97b7d5380b5cfe6e Author: Chen Hui Date: Fri Apr 9 16:23:51 2021 +0800 clk: qcom: a53-pll: Add missing MODULE_DEVICE_TABLE [ Upstream commit 790b516ada10a4dcc0f0a56dc0ced475d86d5820 ] CONFIG_QCOM_A53PLL is tristate option and therefore this driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Fixes: 0c6ab1b8f894 ("clk: qcom: Add A53 PLL support") Signed-off-by: Chen Hui Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210409082352.233810-3-clare.chenhui@huawei.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6c9bbf98b1d897da082ac14ca8e4bb33fcf31f03 Author: Quanyang Wang Date: Tue Apr 6 23:40:15 2021 +0800 clk: zynqmp: move zynqmp_pll_set_mode out of round_rate callback [ Upstream commit d7fd3f9f53df8bb2212dff70f66f12cae0e1a653 ] The round_rate callback should only perform rate calculation and not involve calling zynqmp_pll_set_mode to change the pll mode. So let's move zynqmp_pll_set_mode out of round_rate and to set_rate callback. Fixes: 3fde0e16d016 ("drivers: clk: Add ZynqMP clock driver") Reported-by: Laurent Pinchart Signed-off-by: Quanyang Wang Link: https://lore.kernel.org/r/20210406154015.602779-1-quanyang.wang@windriver.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 3d81ce0cfb31293878ccabf6f5e0bf25d3f1f966 Author: Jason Gunthorpe Date: Tue Apr 6 16:40:25 2021 -0300 vfio/mdev: Do not allow a mdev_type to have a NULL parent pointer [ Upstream commit b5a1f8921d5040bb788492bf33a66758021e4be5 ] There is a small race where the parent is NULL even though the kobj has already been made visible in sysfs. For instance the attribute_group is made visible in sysfs_create_files() and the mdev_type_attr_show() does: ret = attr->show(kobj, type->parent->dev, buf); Which will crash on NULL parent. Move the parent setup to before the type pointer leaves the stack frame. Fixes: 7b96953bc640 ("vfio: Mediated device Core driver") Reviewed-by: Christoph Hellwig Reviewed-by: Kevin Tian Reviewed-by: Max Gurtovoy Reviewed-by: Cornelia Huck Signed-off-by: Jason Gunthorpe Message-Id: <2-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit e6707395c839f22bcb8aabd795f6f65e2d791d78 Author: Hans Verkuil Date: Sat Mar 27 12:27:40 2021 +0100 media: v4l2-ctrls.c: fix race condition in hdl->requests list [ Upstream commit be7e8af98f3af729aa9f08b1053f9533a5cceb91 ] When a request is re-inited it will release all control handler objects that are still in the request. It does that by unbinding and putting all those objects. When the object is unbound the obj->req pointer is set to NULL, and the object's unbind op is called. When the object it put the object's release op is called to free the memory. For a request object that contains a control handler that means that v4l2_ctrl_handler_free() is called in the release op. A control handler used in a request has a pointer to the main control handler that is created by the driver and contains the current state of all controls. If the device is unbound (due to rmmod or a forced unbind), then that main handler is freed, again by calling v4l2_ctrl_handler_free(), and any outstanding request objects that refer to that main handler have to be unbound and put as well. It does that by this test: if (!hdl->req_obj.req && !list_empty(&hdl->requests)) { I.e. the handler has no pointer to a request, so is the main handler, and one or more request objects refer to this main handler. However, this test is wrong since hdl->req_obj.req is actually NULL when re-initing a request (the object unbind will set req to NULL), and the only reason this seemingly worked is that the requests list is typically empty since the request's unbind op will remove the handler from the requests list. But if another thread is at the same time adding a new control to a request, then there is a race condition where one thread is removing a control handler object from the requests list and another thread is adding one. The result is that hdl->requests is no longer empty and the code thinks that a main handler is being freed instead of a control handler that is part of a request. There are two bugs here: first the test for hdl->req_obj.req: this should be hdl->req_obj.ops since only the main control handler will have a NULL pointer there. The second is that adding or deleting request objects from the requests list of the main handler isn't protected by taking the main handler's lock. Signed-off-by: Hans Verkuil Reported-by: John Cox Fixes: 6fa6f831f095 ("media: v4l2-ctrls: add core request support") Tested-by: John Cox Reported-by: John Cox Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b22867aa3d32ee0b94d7a10948ac8fe2f6e509c0 Author: Hannes Reinecke Date: Sat Dec 5 16:29:01 2020 +0100 nvme: retrigger ANA log update if group descriptor isn't found [ Upstream commit dd8f7fa908f66dd44abcd83cbb50410524b9f8ef ] If ANA is enabled but no ANA group descriptor is found when creating a new namespace the ANA log is most likely out of date, so trigger a re-read. The namespace will be tagged with the NS_ANA_PENDING flag to exclude it from path selection until the ANA log has been re-read. Fixes: 32acab3181c7 ("nvme: implement multipath access to nvme subsystems") Reported-by: Martin George Signed-off-by: Hannes Reinecke Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 999d606a820c36ae9b9e9611360c8b3d8d4bb777 Author: Sagi Grimberg Date: Sun Mar 21 00:08:49 2021 -0700 nvmet-tcp: fix incorrect locking in state_change sk callback [ Upstream commit b5332a9f3f3d884a1b646ce155e664cc558c1722 ] We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops+0x170/0x170 inet_shutdown+0x189/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 ? new_sync_read+0x600/0x600 ? lock_acquire+0x1ca/0x480 ? rcu_read_unlock+0x40/0x40 ? lock_is_held_type+0x9a/0x110 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 ? __ia32_sys_read+0xa0/0xa0 ? lockdep_hardirqs_on_prepare.part.0+0x198/0x340 ? syscall_enter_from_user_mode+0x27/0x70 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 872d26a391da ("nvmet-tcp: add NVMe over TCP target driver") Reported-by: Yi Zhang Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit ced0760eb45ad9db08fb09b9ff35e6b441b67db5 Author: Sagi Grimberg Date: Sun Mar 21 00:08:48 2021 -0700 nvme-tcp: block BH in sk state_change sk callback [ Upstream commit 8b73b45d54a14588f86792869bfb23098ea254cb ] The TCP stack can run from process context for a long time so we should disable BH here. Fixes: 3f2304f8c6d6 ("nvme-tcp: add NVMe over TCP host driver") Signed-off-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 4bbae57c7bdef2da0c566a01bfc4afdd21b0840b Author: Sergey Shtylyov Date: Mon Mar 15 23:15:06 2021 +0300 ata: libahci_platform: fix IRQ check [ Upstream commit b30d0040f06159de97ad9c0b1536f47250719d7d ] Iff platform_get_irq() returns 0, ahci_platform_init_host() would return 0 early (as if the call was successful). Override IRQ0 with -EINVAL instead as the 'libata' regards 0 as "no IRQ" (thus polling) anyway... Fixes: c034640a32f8 ("ata: libahci: properly propagate return value of platform_get_irq()") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/4448c8cc-331f-2915-0e17-38ea34e251c8@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit bafcaa01658570c767c54dd5678af80bc6d6de85 Author: Sergey Shtylyov Date: Sun Mar 28 00:13:49 2021 +0300 sata_mv: add IRQ checks [ Upstream commit e6471a65fdd5efbb8dd2732dd0f063f960685ceb ] The function mv_platform_probe() neglects to check the results of the calls to platform_get_irq() and irq_of_parse_and_map() and blithely passes them to ata_host_activate() -- while the latter only checks for IRQ0 (treating it as a polling mode indicattion) and passes the negative values to devm_request_irq() causing it to fail as it takes unsigned values for the IRQ #... Add to mv_platform_probe() the proper IRQ checks to pass the positive IRQ #s to ata_host_activate(), propagate upstream the negative error codes, and override the IRQ0 with -EINVAL (as we don't want the polling mode). Fixes: f351b2d638c3 ("sata_mv: Support SoC controllers") Signed-off-by: Sergey Shtylyov Link: https://lore.kernel.org/r/51436f00-27a1-e20b-c21b-0e817e0a7c86@omprussia.ru Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 782ec39b37bdbdecb3a7f12ba58b21ae232e2873 Author: Sergey Shtylyov Date: Thu Mar 25 23:51:10 2021 +0300 pata_ipx4xx_cf: fix IRQ check [ Upstream commit e379b40cc0f179403ce0b82b7e539f635a568da5 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate errors upstream, and treat IRQ0 as error, returning -EINVAL, as the libata code treats 0 as an indication that polling should be used anyway... Fixes: 0df0d0a0ea9f ("[libata] ARM: add ixp4xx PATA driver") Signed-off-by: Sergey Shtylyov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit af9c0391353dcb6fc75beb6b720c782103b1bfaa Author: Sergey Shtylyov Date: Thu Mar 25 23:50:24 2021 +0300 pata_arasan_cf: fix IRQ check [ Upstream commit c7e8f404d56b99c80990b19a402c3f640d74be05 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate upstream -EPROBE_DEFER, and set up the driver to polling mode on (negative) errors and IRQ0 (libata treats IRQ #0 as a polling mode anyway)... Fixes: a480167b23ef ("pata_arasan_cf: Adding support for arasan compact flash host controller") Signed-off-by: Sergey Shtylyov Acked-by: Viresh Kumar Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit c66229b36fd38ce512f05f21a796a79c4f60a863 Author: Masami Hiramatsu Date: Thu Mar 25 19:08:31 2021 +0900 x86/kprobes: Fix to check non boostable prefixes correctly [ Upstream commit 6dd3b8c9f58816a1354be39559f630cd1bd12159 ] There are 2 bugs in the can_boost() function because of using x86 insn decoder. Since the insn->opcode never has a prefix byte, it can not find CS override prefix in it. And the insn->attr is the attribute of the opcode, thus inat_is_address_size_prefix( insn->attr) always returns false. Fix those by checking each prefix bytes with for_each_insn_prefix loop and getting the correct attribute for each prefix byte. Also, this removes unlikely, because this is a slow path. Fixes: a8d11cd0714f ("kprobes/x86: Consolidate insn decoder users for copying code") Signed-off-by: Masami Hiramatsu Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/161666691162.1120877.2808435205294352583.stgit@devnote2 Signed-off-by: Sasha Levin commit 1cfaa6444a5eabf0ae86d0e25a09914559a92db2 Author: Felix Kuehling Date: Mon Mar 8 22:15:42 2021 -0500 drm/amdkfd: fix build error with AMD_IOMMU_V2=m [ Upstream commit 1e87068570a2cc4db5f95a881686add71729e769 ] Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link against the exported functions. If the GPU driver is built-in but the IOMMU driver is a loadable module, the kfd_iommu.c file is indeed built but does not work: x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_bind_process_to_device': kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_unbind_process': kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_suspend': kfd_iommu.c:(.text+0x966): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to `amd_iommu_free_device' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_resume': kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to `amd_iommu_free_device' Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols are reachable by the amdkfd driver. Output a warning if they are not, because that may not be what the user was expecting. Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional") Reported-by: Arnd Bergmann Signed-off-by: Felix Kuehling Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bfd83cf79b7f029edd180653f5e7daafb61c9a15 Author: Colin Ian King Date: Wed Oct 7 14:16:28 2020 +0200 media: m88rs6000t: avoid potential out-of-bounds reads on arrays [ Upstream commit 9baa3d64e8e2373ddd11c346439e5dfccb2cbb0d ] There a 3 array for-loops that don't check the upper bounds of the index into arrays and this may lead to potential out-of-bounds reads. Fix this by adding array size upper bounds checks to be full safe. Addresses-Coverity: ("Out-of-bounds read") Link: https://lore.kernel.org/linux-media/20201007121628.20676-1-colin.king@canonical.com Fixes: 333829110f1d ("[media] m88rs6000t: add new dvb-s/s2 tuner for integrated chip M88RS6000") Signed-off-by: Colin Ian King Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7db94692631e14f94bbe8b7c73433c8a3c0c4668 Author: Jia-Ju Bai Date: Sat Mar 6 15:15:28 2021 +0100 media: platform: sunxi: sun6i-csi: fix error return code of sun6i_video_start_streaming() [ Upstream commit f3d384e36630e2a552d874e422835606d9cf230a ] When sun6i_video_remote_subdev() returns NULL to subdev, no error return code of sun6i_video_start_streaming() is assigned. To fix this bug, ret is assigned with -EINVAL in this case. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Fixes: 5cc7522d8965 ("media: sun6i: Add support for Allwinner CSI V3s") Acked-by: Chen-Yu Tsai Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1dc1d30ac101bb8335d9852de2107af60c2580e7 Author: Jae Hyun Yoo Date: Mon Dec 21 23:32:25 2020 +0100 media: aspeed: fix clock handling logic [ Upstream commit 3536169f8531c2c5b153921dc7d1ac9fd570cda7 ] Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting. Fixes: d2b4387f3bdf ("media: platform: Add Aspeed Video Engine driver") Signed-off-by: Jae Hyun Yoo Reviewed-by: Joel Stanley Reviewed-by: Eddie James Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC") Reviewed-by: Joel Stanley Acked-by: Stephen Boyd Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d36f9755d1db964c96e045157ddaadd36b4e2d08 Author: Yang Yingliang Date: Tue Nov 17 03:50:41 2020 +0100 media: omap4iss: return error code when omap4iss_get() failed [ Upstream commit 8938c48fa25b491842ece9eb38f0bea0fcbaca44 ] If omap4iss_get() failed, it need return error code in iss_probe(). Fixes: 59f0ad807681 ("[media] v4l: omap4iss: Add support for OMAP4...") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 75c6252e863093f5fbe1794533f6aa69279a6dbb Author: Colin Ian King Date: Thu Feb 25 16:43:27 2021 +0100 media: vivid: fix assignment of dev->fbuf_out_flags [ Upstream commit 5cde22fcc7271812a7944c47b40100df15908358 ] Currently the chroma_flags and alpha_flags are being zero'd with a bit-wise mask and the following statement should be bit-wise or'ing in the new flag bits but instead is making a direct assignment. Fix this by using the |= operator rather than an assignment. Addresses-Coverity: ("Unused value") Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts") Signed-off-by: Colin Ian King Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6b121dc6807cbc1d4ebc608e7c040e2de93ed3b7 Author: Dan Carpenter Date: Fri Apr 23 09:39:19 2021 +0930 soc: aspeed: fix a ternary sign expansion bug [ Upstream commit 5ffa828534036348fa90fb3079ccc0972d202c4a ] The intent here was to return negative error codes but it actually returns positive values. The problem is that type promotion with ternary operations is quite complicated. "ret" is an int. "copied" is a u32. And the snoop_file_read() function returns long. What happens is that "ret" is cast to u32 and becomes positive then it's cast to long and it's still positive. Fix this by removing the ternary so that "ret" is type promoted directly to long. Fixes: 3772e5da4454 ("drivers/misc: Aspeed LPC snoop output using misc chardev") Signed-off-by: Dan Carpenter Signed-off-by: Joel Stanley Reviewed-by: Patrick Venture Link: https://lore.kernel.org/r/YIE90PSXsMTa2Y8n@mwanda Link: https://lore.kernel.org/r/20210423000919.1249474-1-joel@jms.id.au' Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit f276d195ce10856e391b501fba9be9a04af88d64 Author: Paul Durrant Date: Tue Feb 2 17:56:59 2021 +0000 xen-blkback: fix compatibility bug with single page rings [ Upstream commit d75e7f63b7c95c527cde42efb5d410d7f961498f ] Prior to commit 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront"), the behaviour of xen-blkback when connecting to a frontend was: - read 'ring-page-order' - if not present then expect a single page ring specified by 'ring-ref' - else expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order This was correct behaviour, but was broken by the afforementioned commit to become: - read 'ring-page-order' - if not present then expect a single page ring (i.e. ring-page-order = 0) - expect a ring specified by 'ring-refX' where X is between 0 and 1 << ring-page-order - if that didn't work then see if there's a single page ring specified by 'ring-ref' This incorrect behaviour works most of the time but fails when a frontend that sets 'ring-page-order' is unloaded and replaced by one that does not because, instead of reading 'ring-ref', xen-blkback will read the stale 'ring-ref0' left around by the previous frontend will try to map the wrong grant reference. This patch restores the original behaviour. Fixes: 4a8c31a1c6f5 ("xen/blkback: rework connect_ring() to avoid inconsistent xenstore 'ring-page-order' set by malicious blkfront") Signed-off-by: Paul Durrant Reviewed-by: Dongli Zhang Reviewed-by: "Roger Pau Monné" Link: https://lore.kernel.org/r/20210202175659.18452-1-paul@xen.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit aafb5e38e695e00258b60d6d0290a90bb6b4ef88 Author: Tetsuo Handa Date: Thu Apr 15 09:22:22 2021 +0900 ttyprintk: Add TTY hangup callback. [ Upstream commit c0070e1e60270f6a1e09442a9ab2335f3eaeaad2 ] syzbot is reporting hung task due to flood of tty_warn(tty, "%s: tty->count = 1 port count = %d\n", __func__, port->count); message [1], for ioctl(TIOCVHANGUP) prevents tty_port_close() from decrementing port->count due to tty_hung_up_p() == true. ---------- #include #include #include #include #include int main(int argc, char *argv[]) { int i; int fd[10]; for (i = 0; i < 10; i++) fd[i] = open("/dev/ttyprintk", O_WRONLY); ioctl(fd[0], TIOCVHANGUP); for (i = 0; i < 10; i++) close(fd[i]); close(open("/dev/ttyprintk", O_WRONLY)); return 0; } ---------- When TTY hangup happens, port->count needs to be reset via "struct tty_operations"->hangup callback. [1] https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a Reported-by: syzbot Reported-by: syzbot Tested-by: syzbot Signed-off-by: Tetsuo Handa Fixes: 24b4b67d17c308aa ("add ttyprintk driver") Link: https://lore.kernel.org/r/17e0652d-89b7-c8c0-fb53-e7566ac9add4@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit ce7b62d857919e511c6d5171c578c4b7e1bf0e67 Author: Artur Petrosyan Date: Fri Apr 16 16:47:14 2021 +0400 usb: dwc2: Fix hibernation between host and device modes. [ Upstream commit 24d209dba5a3959b2ebde7cf3ad40c8015e814cf ] When core is in hibernation in host mode and a device cable was connected then driver exited from device hibernation. However, registers saved for host mode and when exited from device hibernation register restore would be done for device register which was wrong because there was no device registers stored to restore. - Added dwc_handle_gpwrdn_disc_det() function which handles gpwrdn disconnect detect flow and exits hibernation without restoring the registers. - Updated exiting from hibernation in GPWRDN_STS_CHGINT with calling dwc_handle_gpwrdn_disc_det() function. Here no register is restored which is the solution described above. Fixes: 65c9c4c6b01f ("usb: dwc2: Add dwc2_handle_gpwrdn_intr() handler") Acked-by: Minas Harutyunyan Signed-off-by: Artur Petrosyan Signed-off-by: Minas Harutyunyan Link: https://lore.kernel.org/r/20210416124715.75355A005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6f7ed537ca2d1d53410122def2aad676841b8639 Author: Artur Petrosyan Date: Fri Apr 16 16:47:06 2021 +0400 usb: dwc2: Fix host mode hibernation exit with remote wakeup flow. [ Upstream commit c2db8d7b9568b10e014af83b3c15e39929e3579e ] Added setting "port_connect_status_change" flag to "1" in order to re-enumerate, because after exit from hibernation port connection status is not detected. Fixes: c5c403dc4336 ("usb: dwc2: Add host/device hibernation functions") Acked-by: Minas Harutyunyan Signed-off-by: Artur Petrosyan Link: https://lore.kernel.org/r/20210416124707.5EEC2A005D@mailhost.synopsys.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e83dcf255a136a4c8c454e2271d046f69dd58037 Author: Michael Kelley Date: Mon Apr 19 21:48:09 2021 -0700 Drivers: hv: vmbus: Increase wait time for VMbus unload [ Upstream commit 77db0ec8b7764cb9b09b78066ebfd47b2c0c1909 ] When running in Azure, disks may be connected to a Linux VM with read/write caching enabled. If a VM panics and issues a VMbus UNLOAD request to Hyper-V, the response is delayed until all dirty data in the disk cache is flushed. In extreme cases, this flushing can take 10's of seconds, depending on the disk speed and the amount of dirty data. If kdump is configured for the VM, the current 10 second timeout in vmbus_wait_for_unload() may be exceeded, and the UNLOAD complete message may arrive well after the kdump kernel is already running, causing problems. Note that no problem occurs if kdump is not enabled because Hyper-V waits for the cache flush before doing a reboot through the BIOS/UEFI code. Fix this problem by increasing the timeout in vmbus_wait_for_unload() to 100 seconds. Also output periodic messages so that if anyone is watching the serial console, they won't think the VM is completely hung. Fixes: 911e1987efc8 ("Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload") Signed-off-by: Michael Kelley Reviewed-by: Vitaly Kuznetsov Link: https://lore.kernel.org/r/1618894089-126662-1-git-send-email-mikelley@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 9b47b3a675524b99ee5074f45e26445df2cc7475 Author: Ingo Molnar Date: Tue Apr 20 09:47:42 2021 +0200 x86/platform/uv: Fix !KEXEC build failure [ Upstream commit c2209ea55612efac75de0a58ef5f7394fae7fa0f ] When KEXEC is disabled, the UV build fails: arch/x86/platform/uv/uv_nmi.c:875:14: error: ‘uv_nmi_kexec_failed’ undeclared (first use in this function) Since uv_nmi_kexec_failed is only defined in the KEXEC_CORE #ifdef branch, this code cannot ever have been build tested: if (main) pr_err("UV: NMI kdump: KEXEC not supported in this kernel\n"); atomic_set(&uv_nmi_kexec_failed, 1); Nor is this use possible in uv_handle_nmi(): atomic_set(&uv_nmi_kexec_failed, 0); These bugs were introduced in this commit: d0a9964e9873: ("x86/platform/uv: Implement simple dump failover if kdump fails") Which added the uv_nmi_kexec_failed assignments to !KEXEC code, while making the definition KEXEC-only - apparently without testing the !KEXEC case. Instead of complicating the #ifdef maze, simplify the code by requiring X86_UV to depend on KEXEC_CORE. This pattern is present in other architectures as well. ( We'll remove the untested, 7 years old !KEXEC complications from the file in a separate commit. ) Fixes: d0a9964e9873: ("x86/platform/uv: Implement simple dump failover if kdump fails") Signed-off-by: Ingo Molnar Cc: Mike Travis Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin commit 9a9ce397336ed00c211f5f528d895be74c59624b Author: Steffen Dirkwinkel Date: Mon Apr 12 15:30:06 2021 +0200 platform/x86: pmc_atom: Match all Beckhoff Automation baytrail boards with critclk_systems DMI table [ Upstream commit d21e5abd3a005253eb033090aab2e43bce090d89 ] pmc_plt_clk* clocks are used for ethernet controllers, so need to stay turned on. This adds the affected board family to critclk_systems DMI table, so the clocks are marked as CLK_CRITICAL and not turned off. This replaces the previously listed boards with a match for the whole device family CBxx63. CBxx63 matches only baytrail devices. There are new affected boards that would otherwise need to be listed. There are unaffected boards in the family, but having the clocks turned on is not an issue. Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL") Reviewed-by: Andy Shevchenko Signed-off-by: Steffen Dirkwinkel Link: https://lore.kernel.org/r/20210412133006.397679-1-linux-kernel-dev@beckhoff.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit eec90f4b9575a9d24889935f66d871aa9bd46d33 Author: Ye Bin Date: Thu Apr 8 19:23:05 2021 +0800 usbip: vudc: fix missing unlock on error in usbip_sockfd_store() [ Upstream commit 1d08ed588c6a85a35a24c82eb4cf0807ec2b366a ] Add the missing unlock before return from function usbip_sockfd_store() in the error handling case. Fixes: bd8b82042269 ("usbip: vudc synchronize sysfs code paths") Reported-by: Hulk Robot Acked-by: Shuah Khan Signed-off-by: Ye Bin Link: https://lore.kernel.org/r/20210408112305.1022247-1-yebin10@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit d3b6b252bab0b3d556b96c3be5526319965515bc Author: Dan Carpenter Date: Fri Apr 9 14:01:57 2021 +0300 node: fix device cleanups in error handling code [ Upstream commit 4ce535ec0084f0d712317cb99d383cad3288e713 ] We can't use kfree() to free device managed resources so the kfree(dev) is against the rules. It's easier to write this code if we open code the device_register() as a device_initialize() and device_add(). That way if dev_set_name() set name fails we can call put_device() and it will clean up correctly. Fixes: acc02a109b04 ("node: Add memory-side caching attributes") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/YHA0JUra+F64+NpB@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 3f605558a4f7eadfe0b13964a670ec213d23e9dc Author: He Ying Date: Tue Apr 6 05:42:00 2021 -0400 firmware: qcom-scm: Fix QCOM_SCM configuration [ Upstream commit 2954a6f12f250890ec2433cec03ba92784d613e8 ] When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows: drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk': qcom_scm-smc.c:(.text+0x36): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call': qcom_scm-legacy.c:(.text+0xe2): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call_atomic': qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc' Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y. So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration. Fixes: 916f743da354 ("firmware: qcom: scm: Move the scm driver to drivers/firmware") Reported-by: Hulk Robot Signed-off-by: He Ying Link: https://lore.kernel.org/r/20210406094200.60952-1-heying24@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 77a1c15145c8b3459f3f7361cadd111d6624b349 Author: Johan Hovold Date: Wed Apr 7 11:52:08 2021 +0200 serial: core: return early on unsupported ioctls [ Upstream commit 79c5966cec7b148199386ef9933c31b999379065 ] Drivers can return -ENOIOCTLCMD when an ioctl is not recognised to tell the upper layers to continue looking for a handler. This is not the case for the RS485 and ISO7816 ioctls whose handlers should return -ENOTTY directly in case a serial driver does not implement the corresponding methods. Fixes: a5f276f10ff7 ("serial_core: Handle TIOC[GS]RS485 ioctls.") Fixes: ad8c0eaa0a41 ("tty/serial_core: add ISO7816 infrastructure") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-9-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b6803d57f587f0387ddadd57b27660643340a049 Author: Johan Hovold Date: Wed Apr 7 11:52:02 2021 +0200 tty: fix return value for unsupported ioctls [ Upstream commit 1b8b20868a6d64cfe8174a21b25b74367bdf0560 ] Drivers should return -ENOTTY ("Inappropriate I/O control operation") when an ioctl isn't supported, while -EINVAL is used for invalid arguments. Fix up the TIOCMGET, TIOCMSET and TIOCGICOUNT helpers which returned -EINVAL when a tty driver did not implement the corresponding operations. Note that the TIOCMGET and TIOCMSET helpers predate git and do not get a corresponding Fixes tag below. Fixes: d281da7ff6f7 ("tty: Make tiocgicount a handler") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 932d67b84b4fb949c6bae8dca95d17f4ecbdc275 Author: Johan Hovold Date: Wed Apr 7 11:52:01 2021 +0200 tty: actually undefine superseded ASYNC flags [ Upstream commit d09845e98a05850a8094ea8fd6dd09a8e6824fff ] Some kernel-internal ASYNC flags have been superseded by tty-port flags and should no longer be used by kernel drivers. Fix the misspelled "__KERNEL__" compile guards which failed their sole purpose to break out-of-tree drivers that have not yet been updated. Fixes: 5c0517fefc92 ("tty: core: Undefine ASYNC_* flags superceded by TTY_PORT* flags") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407095208.31838-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a6fb73f4e0091381705938d4a65ab5ed33c28ade Author: Johan Hovold Date: Thu Apr 8 15:16:02 2021 +0200 USB: cdc-acm: fix TIOCGSERIAL implementation [ Upstream commit 496960274153bdeb9d1f904ff1ea875cef8232c1 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. The xmit_fifo_size parameter could be used to set the hardware transmit fifo size of a legacy UART when it could not be detected, but the interface is limited to eight bits and should be left unset when it is not used. Similarly, baud_base could be used to set the UART base clock when it could not be detected, but might as well be left unset when it is not known (which is the case for CDC). Fix the cdc-acm TIOCGSERIAL implementation by dropping its custom interpretation of the unused xmit_fifo_size and baud_base fields, which overflowed the former with the URB buffer size and set the latter to the current line speed. Also return the port line number, which is the only other value used besides the close parameters. Note that the current line speed can still be retrieved through the standard termios interfaces. Fixes: 18c75720e667 ("USB: allow users to run setserial with cdc-acm") Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8abef571fd928a7c413ea216fd447f0ad8a44c83 Author: Johan Hovold Date: Thu Apr 8 15:16:01 2021 +0200 USB: cdc-acm: fix unprivileged TIOCCSERIAL [ Upstream commit dd5619582d60007139f0447382d2839f4f9e339b ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the cdc-acm implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: ba2d8ce9db0a ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9aa1552034278daef8509556d0349d826238c171 Author: Colin Ian King Date: Tue Apr 6 19:45:10 2021 +0100 usb: gadget: r8a66597: Add missing null check on return from platform_get_resource [ Upstream commit 9c2076090c2815fe7c49676df68dde7e60a9b9fc ] The call to platform_get_resource can potentially return a NULL pointer on failure, so add this check and return -EINVAL if it fails. Fixes: c41442474a26 ("usb: gadget: R8A66597 peripheral controller support.") Signed-off-by: Colin Ian King Addresses-Coverity: ("Dereference null return") Link: https://lore.kernel.org/r/20210406184510.433497-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4a01ad002d2e03c399af536562693752af7c81b1 Author: Wang Li Date: Fri Apr 9 09:54:30 2021 +0000 spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() [ Upstream commit a03675497970a93fcf25d81d9d92a59c2d7377a7 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi") Reported-by: Hulk Robot Signed-off-by: Wang Li Link: https://lore.kernel.org/r/20210409095430.29868-1-wangli74@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit eaf03935b8592748b28975fff8bbb70c2009806a Author: Pali Rohár Date: Thu Apr 8 13:42:21 2021 +0200 cpufreq: armada-37xx: Fix determining base CPU frequency [ Upstream commit 8bad3bf23cbc40abe1d24cec08a114df6facf858 ] When current CPU load is not L0 then loading armada-37xx-cpufreq.ko driver fails with following error: # modprobe armada-37xx-cpufreq [ 502.702097] Unsupported CPU frequency 250 MHz This issue was partially fixed by commit 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp"), but only for calculating CPU frequency for opp. Fix this also for determination of base CPU frequency. Signed-off-by: Pali Rohár Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit d33a00f35531054f3722519ef93ee3c2c11bd17f Author: Pali Rohár Date: Thu Apr 8 13:42:20 2021 +0200 cpufreq: armada-37xx: Fix driver cleanup when registration failed [ Upstream commit 92963903a8e11b9576eb7249f8e81eefa93b6f96 ] Commit 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp") changed calculation of frequency passed to the dev_pm_opp_add() function call. But the code for dev_pm_opp_remove() function call was not updated, so the driver cleanup phase does not work when registration fails. This fixes the issue by using the same frequency in both calls. Signed-off-by: Pali Rohár Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 8db82563451f ("cpufreq: armada-37xx: fix frequency calculation for opp") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 4bffea742b6665dcaf9e14549a73b9aefa853792 Author: Pali Rohár Date: Thu Apr 8 13:42:19 2021 +0200 clk: mvebu: armada-37xx-periph: Fix workaround for switching from L1 to L0 [ Upstream commit e93033aff684641f71a436ca7a9d2a742126baaf ] When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1) quickly followed by a call with 1 GHz (L0), the CPU does not necessarily stay in L1 for at least 20ms as is required by Marvell errata. This situation happens frequently with the ondemand cpufreq governor and can be also reproduced with userspace governor. In most cases it causes CPU to crash. This change fixes the above issue and ensures that the CPU always stays in L1 for at least 20ms when switching from any state to L0. Signed-off-by: Marek Behún Signed-off-by: Pali Rohár Acked-by: Stephen Boyd Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 0289edd869ac0d9225adf3def2f9bc6b2ff04680 Author: Pali Rohár Date: Thu Apr 8 13:42:18 2021 +0200 clk: mvebu: armada-37xx-periph: Fix switching CPU freq from 250 Mhz to 1 GHz [ Upstream commit 4decb9187589f61fe9fc2bc4d9b01160b0a610c5 ] It was observed that the workaround introduced by commit 61c40f35f5cd ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to 1.2GHz") when base CPU frequency is 1.2 GHz is also required when base CPU frequency is 1 GHz. Otherwise switching CPU frequency directly from L2 (250 MHz) to L0 (1 GHz) causes a crash. When base CPU frequency is just 800 MHz no crashed were observed during switch from L2 to L0. Signed-off-by: Pali Rohár Acked-by: Stephen Boyd Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 0c793b76066b70276669a0a4da6cbb868c8d2053 Author: Pali Rohár Date: Thu Apr 8 13:42:17 2021 +0200 cpufreq: armada-37xx: Fix the AVS value for load L1 [ Upstream commit d118ac2062b5b8331c8768ac81e016617e0996ee ] The original CPU voltage value for load L1 is too low for Armada 37xx SoC when base CPU frequency is 1000 or 1200 MHz. It leads to instabilities where CPU gets stuck soon after dynamic voltage scaling from load L1 to L0. Update the CPU voltage value for load L1 accordingly when base frequency is 1000 or 1200 MHz. The minimal L1 value for base CPU frequency 1000 MHz is updated from the original 1.05V to 1.108V and for 1200 MHz is updated to 1.155V. This minimal L1 value is used only in the case when it is lower than value for L0. This change fixes CPU instability issues on 1 GHz and 1.2 GHz variants of Espressobin and 1 GHz Turris Mox. Marvell previously for 1 GHz variant of Espressobin provided a patch [1] suitable only for their Marvell Linux kernel 4.4 fork which workarounded this issue. Patch forced CPU voltage value to 1.108V in all loads. But such change does not fix CPU instability issues on 1.2 GHz variants of Armada 3720 SoC. During testing we come to the conclusion that using 1.108V as minimal value for L1 load makes 1 GHz variants of Espressobin and Turris Mox boards stable. And similarly 1.155V for 1.2 GHz variant of Espressobin. These two values 1.108V and 1.155V are documented in Armada 3700 Hardware Specifications as typical initial CPU voltage values. Discussion about this issue is also at the Armbian forum [2]. [1] - https://github.com/MarvellEmbeddedProcessors/linux-marvell/commit/dc33b62c90696afb6adc7dbcc4ebbd48bedec269 [2] - https://forum.armbian.com/topic/10429-how-to-make-espressobin-v7-stable/ Signed-off-by: Pali Rohár Acked-by: Gregory CLEMENT Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 1c3528232f4b ("cpufreq: armada-37xx: Add AVS support") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit b671a3277b7c9ac4b04baa84e5ec2960eae1c112 Author: Marek Behún Date: Thu Apr 8 13:42:16 2021 +0200 clk: mvebu: armada-37xx-periph: remove .set_parent method for CPU PM clock [ Upstream commit 4e435a9dd26c46ac018997cc0562d50b1a96f372 ] Remove the .set_parent method in clk_pm_cpu_ops. This method was supposed to be needed by the armada-37xx-cpufreq driver, but was never actually called due to wrong assumptions in the cpufreq driver. After this was fixed in the cpufreq driver, this method is not needed anymore. Signed-off-by: Marek Behún Acked-by: Stephen Boyd Acked-by: Gregory CLEMENT Tested-by: Pali Rohár Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 2089dc33ea0e ("clk: mvebu: armada-37xx-periph: add DVFS support for cpu clocks") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 3518c6d0178c3d0c2181ba077672ef9421c1fdf9 Author: Marek Behún Date: Thu Apr 8 13:42:15 2021 +0200 cpufreq: armada-37xx: Fix setting TBG parent for load levels [ Upstream commit 22592df194e31baf371906cc720da38fa0ab68f5 ] With CPU frequency determining software [1] we have discovered that after this driver does one CPU frequency change, the base frequency of the CPU is set to the frequency of TBG-A-P clock, instead of the TBG that is parent to the CPU. This can be reproduced on EspressoBIN and Turris MOX: cd /sys/devices/system/cpu/cpufreq/policy0 echo powersave >scaling_governor echo performance >scaling_governor Running the mhz tool before this driver is loaded reports 1000 MHz, and after loading the driver and executing commands above the tool reports 800 MHz. The change of TBG clock selector is supposed to happen in function armada37xx_cpufreq_dvfs_setup. Before the function returns, it does this: parent = clk_get_parent(clk); clk_set_parent(clk, parent); The armada-37xx-periph clock driver has the .set_parent method implemented correctly for this, so if the method was actually called, this would work. But since the introduction of the common clock framework in commit b2476490ef11 ("clk: introduce the common clock..."), the clk_set_parent function checks whether the parent is actually changing, and if the requested new parent is same as the old parent (which is obviously the case for the code above), the .set_parent method is not called at all. This patch fixes this issue by filling the correct TBG clock selector directly in the armada37xx_cpufreq_dvfs_setup during the filling of other registers at the same address. But the determination of CPU TBG index cannot be done via the common clock framework, therefore we need to access the North Bridge Peripheral Clock registers directly in this driver. [1] https://github.com/wtarreau/mhz Signed-off-by: Marek Behún Acked-by: Gregory CLEMENT Tested-by: Pali Rohár Tested-by: Tomasz Maciej Nowak Tested-by: Anders Trier Olesen Tested-by: Philip Soares Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 19d16a6897931b0dc61c1d2ab7c6cefbf809c186 Author: Lv Yunlong Date: Fri Apr 2 10:13:48 2021 -0700 crypto: qat - Fix a double free in adf_create_ring [ Upstream commit f7cae626cabb3350b23722b78fe34dd7a615ca04 ] In adf_create_ring, if the callee adf_init_ring() failed, the callee will free the ring->base_addr by dma_free_coherent() and return -EFAULT. Then adf_create_ring will goto err and the ring->base_addr will be freed again in adf_cleanup_ring(). My patch sets ring->base_addr to NULL after the first freed to avoid the double free. Fixes: a672a9dc872ec ("crypto: qat - Intel(R) QAT transport code") Signed-off-by: Lv Yunlong Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 32f5f51a3703995d6d6ccbbde9a8331cb067665e Author: Nathan Chancellor Date: Wed Apr 7 14:30:48 2021 -0700 ACPI: CPPC: Replace cppc_attr with kobj_attribute [ Upstream commit 2bc6262c6117dd18106d5aa50d53e945b5d99c51 ] All of the CPPC sysfs show functions are called via indirect call in kobj_attr_show(), where they should be of type ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr, char *buf); because that is the type of the ->show() member in 'struct kobj_attribute' but they are actually of type ssize_t (*show)(struct kobject *kobj, struct attribute *attr, char *buf); because of the ->show() member in 'struct cppc_attr', resulting in a Control Flow Integrity violation [1]. $ cat /sys/devices/system/cpu/cpu0/acpi_cppc/highest_perf 3400 $ dmesg | grep "CFI failure" [ 175.970559] CFI failure (target: show_highest_perf+0x0/0x8): As far as I can tell, the only difference between 'struct cppc_attr' and 'struct kobj_attribute' aside from the type of the attr parameter is the type of the count parameter in the ->store() member (ssize_t vs. size_t), which does not actually matter because all of these nodes are read-only. Eliminate 'struct cppc_attr' in favor of 'struct kobj_attribute' to fix the violation. [1]: https://lore.kernel.org/r/20210401233216.2540591-1-samitolvanen@google.com/ Fixes: 158c998ea44b ("ACPI / CPPC: add sysfs support to compute delivered performance") Link: https://github.com/ClangBuiltLinux/linux/issues/1343 Signed-off-by: Nathan Chancellor Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 726837481c9348df570a384f074d145a44742cbf Author: Bjorn Andersson Date: Thu Jan 7 15:25:26 2021 -0800 soc: qcom: mdt_loader: Detect truncated read of segments [ Upstream commit 0648c55e3a21ccd816e99b6600d6199fbf39d23a ] Given that no validation of how much data the firmware loader read in for a given segment truncated segment files would best case result in a hash verification failure, without any indication of what went wrong. Improve this by validating that the firmware loader did return the amount of data requested. Fixes: 445c2410a449 ("soc: qcom: mdt_loader: Use request_firmware_into_buf()") Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210107232526.716989-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 08b601cb7aef23342c4ab1cd8f28449c7a2f7103 Author: Bjorn Andersson Date: Thu Jan 7 15:31:19 2021 -0800 soc: qcom: mdt_loader: Validate that p_filesz < p_memsz [ Upstream commit 84168d1b54e76a1bcb5192991adde5176abe02e3 ] The code validates that segments of p_memsz bytes of a segment will fit in the provided memory region, but does not validate that p_filesz bytes will, which means that an incorrectly crafted ELF header might write beyond the provided memory region. Fixes: 051fb70fd4ea ("remoteproc: qcom: Driver for the self-authenticating Hexagon v5") Reviewed-by: Sibi Sankar Link: https://lore.kernel.org/r/20210107233119.717173-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 001c8e83646ad3b847b18f6ac55a54367d917d74 Author: William A. Kennington III Date: Wed Apr 7 02:55:27 2021 -0700 spi: Fix use-after-free with devm_spi_alloc_* [ Upstream commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 ] We can't rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ------------[ cut here ]------------ WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [] (refcount_warn_saturate) from [] (kobject_put+0x90/0x98) [] (kobject_put) from [] (put_device+0x20/0x24) r4:b6700140 [] (put_device) from [] (devm_spi_release_controller+0x3c/0x40) [] (devm_spi_release_controller) from [] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [] (release_nodes) from [] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [] (devres_release_all) from [] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [] (__device_release_driver) from [] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [] (device_driver_detach) from [] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup. Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation") Signed-off-by: William A. Kennington III Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3b0cd47fe1b72003b4e292073a89e7302a9d8011 Author: Dong Aisheng Date: Tue Mar 23 15:20:08 2021 +0800 PM / devfreq: Use more accurate returned new_freq as resume_freq [ Upstream commit 62453f1ba5d5def9d58e140a50f3f168f028da38 ] Use the more accurate returned new_freq as resume_freq. It's the same as how devfreq->previous_freq was updated. Fixes: 83f8ca45afbf0 ("PM / devfreq: add support for suspend/resume of a devfreq device") Signed-off-by: Dong Aisheng Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 51a5e5e93c014753b01251e0d232d0549295feb7 Author: Johan Hovold Date: Wed Apr 7 12:23:24 2021 +0200 staging: greybus: uart: fix unprivileged TIOCCSERIAL [ Upstream commit 60c6b305c11b5fd167ce5e2ce42f3a9098c388f0 ] TIOCSSERIAL is a horrid, underspecified, legacy interface which for most serial devices is only useful for setting the close_delay and closing_wait parameters. A non-privileged user has only ever been able to set the since long deprecated ASYNC_SPD flags and trying to change any other *supported* feature should result in -EPERM being returned. Setting the current values for any supported features should return success. Fix the greybus implementation which instead indicated that the TIOCSSERIAL ioctl was not even implemented when a non-privileged user set the current values. Fixes: e68453ed28c5 ("greybus: uart-gb: now builds, more framework added") Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-7-johan@kernel.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c751e448b726721651c5944c79aef4105186a4c8 Author: Colin Ian King Date: Wed Apr 7 16:03:08 2021 +0100 staging: rtl8192u: Fix potential infinite loop [ Upstream commit f9b9263a25dc3d2eaaa829e207434db6951ca7bc ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of riv->ieee80211->LinkDetectInfo.SlotNum that is a u16 type. There is a potential infinite loop if SlotNum is larger than the u8 loop counter. Fix this by making the loop counter the same type as SlotNum. Addresses-Coverity: ("Infinite loop") Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210407150308.496623-1-colin.king@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8148375c865fbfc4236b24400c330d6416401915 Author: Arnd Bergmann Date: Tue Mar 23 14:18:35 2021 +0100 irqchip/gic-v3: Fix OF_BAD_ADDR error handling [ Upstream commit 8e13d96670a4c050d4883e6743a9e9858e5cfe10 ] When building with extra warnings enabled, clang points out a mistake in the error handling: drivers/irqchip/irq-gic-v3-mbi.c:306:21: error: result of comparison of constant 18446744073709551615 with expression of type 'phys_addr_t' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare] if (mbi_phys_base == OF_BAD_ADDR) { Truncate the constant to the same type as the variable it gets compared to, to shut make the check work and void the warning. Fixes: 505287525c24 ("irqchip/gic-v3: Add support for Message Based Interrupts as an MSI controller") Signed-off-by: Arnd Bergmann Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210323131842.2773094-1-arnd@kernel.org Signed-off-by: Sasha Levin commit ef8e7bfea99aaeaf2b037cba19945205fe580850 Author: Lv Yunlong Date: Fri Apr 2 23:09:05 2021 -0700 mtd: rawnand: gpmi: Fix a double free in gpmi_nand_init [ Upstream commit 076de75de1e53160e9b099f75872c1f9adf41a0b ] If the callee gpmi_alloc_dma_buffer() failed to alloc memory for this->raw_buffer, gpmi_free_dma_buffer() will be called to free this->auxiliary_virt. But this->auxiliary_virt is still a non-NULL and valid ptr. Then gpmi_alloc_dma_buffer() returns err and gpmi_free_dma_buffer() is called again to free this->auxiliary_virt in err_out. This causes a double free. As gpmi_free_dma_buffer() has already called in gpmi_alloc_dma_buffer's error path, so it should return err directly instead of releasing the dma buffer again. Fixes: 4d02423e9afe6 ("mtd: nand: gpmi: Fix gpmi_nand_init() error path") Signed-off-by: Lv Yunlong Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210403060905.5251-1-lyl2019@mail.ustc.edu.cn Signed-off-by: Sasha Levin commit f6a90818a32058fca62cda3a2027a6a2364e1878 Author: Finn Thain Date: Tue Mar 30 18:37:51 2021 +1100 m68k: mvme147,mvme16x: Don't wipe PCC timer config bits [ Upstream commit 43262178c043032e7c42d00de44c818ba05f9967 ] Don't clear the timer 1 configuration bits when clearing the interrupt flag and counter overflow. As Michael reported, "This results in no timer interrupts being delivered after the first. Initialization then hangs in calibrate_delay as the jiffies counter is not updated." On mvme16x, enable the timer after requesting the irq, consistent with mvme147. Cc: Michael Pavone Fixes: 7529b90d051e ("m68k: mvme147: Handle timer counter overflow") Fixes: 19999a8b8782 ("m68k: mvme16x: Handle timer counter overflow") Reported-and-tested-by: Michael Pavone Signed-off-by: Finn Thain Link: https://lore.kernel.org/r/4fdaa113db089b8fb607f7dd818479f8cdcc4547.1617089871.git.fthain@telegraphics.com.au Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 870533403ffa28ff63e173045fc5369365642002 Author: Rander Wang Date: Wed Mar 31 08:46:10 2021 +0800 soundwire: stream: fix memory leak in stream config error path [ Upstream commit 48f17f96a81763c7c8bf5500460a359b9939359f ] When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak. Fixes: 89e590535f32 ("soundwire: Add support for SoundWire stream management") Signed-off-by: Rander Wang Reviewed-by: Keyon Jie Reviewed-by: Guennadi Liakhovetski Reviewed-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20210331004610.12242-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 7cd10f8a5a9ddcd82180e212c8e168a807ad0cac Author: gexueyuan Date: Wed Mar 31 11:10:56 2021 +0800 memory: pl353: fix mask of ECC page_size config register [ Upstream commit 25dcca7fedcd4e31cb368ad846bfd738c0c6307c ] The mask for page size of ECC Configuration Register should be 0x3, according to the datasheet of PL353 smc. Fixes: fee10bd22678 ("memory: pl353: Add driver for arm pl353 static memory controller") Signed-off-by: gexueyuan Link: https://lore.kernel.org/r/20210331031056.5326-1-gexueyuan@gmail.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 6b18f6ac820e2845a511ea91a5af17b2a2d4e14d Author: Yang Yingliang Date: Tue Mar 30 21:01:59 2021 +0800 USB: gadget: udc: fix wrong pointer passed to IS_ERR() and PTR_ERR() [ Upstream commit 2e3d055bf27d70204cae349335a62a4f9b7c165a ] IS_ERR() and PTR_ERR() use wrong pointer, it should be udc->virt_addr, fix it. Fixes: 1b9f35adb0ff ("usb: gadget: udc: Add Synopsys UDC Platform driver") Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Link: https://lore.kernel.org/r/20210330130159.1051979-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 93615b25c78fd705a74d8a7ab072ff4f2c9f61e9 Author: Tao Ren Date: Tue Mar 30 21:58:31 2021 -0700 usb: gadget: aspeed: fix dma map failure [ Upstream commit bd4d607044b961cecbf8c4c2f3bb5da4fb156993 ] Currently the virtual port_dev device is passed to DMA API, and this is wrong because the device passed to DMA API calls must be the actual hardware device performing the DMA. The patch replaces usb_gadget_map_request/usb_gadget_unmap_request APIs with usb_gadget_map_request_by_dev/usb_gadget_unmap_request_by_dev APIs so the DMA capable platform device can be passed to the DMA APIs. The patch fixes below backtrace detected on Facebook AST2500 OpenBMC platforms: [<80106550>] show_stack+0x20/0x24 [<80106868>] dump_stack+0x28/0x30 [<80823540>] __warn+0xfc/0x110 [<8011ac30>] warn_slowpath_fmt+0xb0/0xc0 [<8011ad44>] dma_map_page_attrs+0x24c/0x314 [<8016a27c>] usb_gadget_map_request_by_dev+0x100/0x1e4 [<805cedd8>] usb_gadget_map_request+0x1c/0x20 [<805cefbc>] ast_vhub_epn_queue+0xa0/0x1d8 [<7f02f710>] usb_ep_queue+0x48/0xc4 [<805cd3e8>] ecm_do_notify+0xf8/0x248 [<7f145920>] ecm_set_alt+0xc8/0x1d0 [<7f145c34>] composite_setup+0x680/0x1d30 [<7f00deb8>] ast_vhub_ep0_handle_setup+0xa4/0x1bc [<7f02ee94>] ast_vhub_dev_irq+0x58/0x84 [<7f0309e0>] ast_vhub_irq+0xb0/0x1c8 [<7f02e118>] __handle_irq_event_percpu+0x50/0x19c [<8015e5bc>] handle_irq_event_percpu+0x38/0x8c [<8015e758>] handle_irq_event+0x38/0x4c Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Reviewed-by: Joel Stanley Signed-off-by: Tao Ren Link: https://lore.kernel.org/r/20210331045831.28700-1-rentao.bupt@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c675ead206b758285555409e934b70bdc48750f0 Author: Giovanni Cabiddu Date: Thu Mar 25 08:34:18 2021 +0000 crypto: qat - fix error path in adf_isr_resource_alloc() [ Upstream commit 83dc1173d73f80cbce2fee4d308f51f87b2f26ae ] The function adf_isr_resource_alloc() is not unwinding correctly in case of error. This patch fixes the error paths and propagate the errors to the caller. Fixes: 7afa232e76ce ("crypto: qat - Intel(R) QAT DH895xcc accelerator") Signed-off-by: Giovanni Cabiddu Reviewed-by: Marco Chiappero Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit f3685a9ef29daa745d9c384d9ac5d600a6a6cee9 Author: Geert Uytterhoeven Date: Mon Feb 8 16:02:52 2021 +0100 phy: marvell: ARMADA375_USBCLUSTER_PHY should not default to y, unconditionally [ Upstream commit 6cb17707aad869de163d7bf42c253caf501be4e2 ] Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ARMADA375_USBCLUSTER_PHY to MACH_ARMADA_375, and ask the user in case of compile-testing. Fixes: eee47538ec1f2619 ("phy: add support for USB cluster on the Armada 375 SoC") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210208150252.424706-1-geert+renesas@glider.be Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 4dc0332faf805afeba56832a57c61e2d776d06c3 Author: Srinivas Kandagatla Date: Tue Mar 9 10:48:16 2021 +0000 soundwire: bus: Fix device found flag correctly [ Upstream commit f03690f4f6992225d05dbd1171212e5be5a370dd ] found flag is used to indicate SoundWire devices that are both enumerated on the bus and available in the device list. However this flag is not reset correctly after one iteration, This could miss some of the devices that are enumerated on the bus but not in device list. So reset this correctly to fix this issue! Fixes: d52d7a1be02c ("soundwire: Add Slave status handling helpers") Signed-off-by: Srinivas Kandagatla Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210309104816.20350-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 3a76ec28824c01b57aa1f0927841d75e4f167cb8 Author: Pan Bian Date: Thu Jan 21 03:49:07 2021 -0800 bus: qcom: Put child node before return [ Upstream commit ac6ad7c2a862d682bb584a4bc904d89fa7721af8 ] Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body. Reviewed-by: Linus Walleij Fixes: 335a12754808 ("bus: qcom: add EBI2 driver") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210121114907.109267-1-bianpan2016@163.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 5880afefe0cb9b2d5e801816acd58bfe91a96981 Author: Michael Walle Date: Wed Mar 3 16:57:35 2021 +0100 mtd: require write permissions for locking and badblock ioctls [ Upstream commit 1e97743fd180981bef5f01402342bb54bf1c6366 ] MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table. Fixes: f7e6b19bc764 ("mtd: properly check all write ioctls for permissions") Signed-off-by: Michael Walle Reviewed-by: Greg Kroah-Hartman Acked-by: Rafał Miłecki Acked-by: Richard Weinberger Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210303155735.25887-1-michael@walle.cc Signed-off-by: Sasha Levin commit ff352d27d4cea44d84262e44549bd486516d02ae Author: Fabian Vogt Date: Wed Mar 24 15:11:15 2021 +0100 fotg210-udc: Complete OUT requests on short packets [ Upstream commit 75bb93be0027123b5db6cbcce89eb62f0f6b3c5b ] A short packet indicates the end of a transfer and marks the request as complete. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-8-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0d19ad0706c25dea1757ea8127ba283f5f729c0f Author: Fabian Vogt Date: Wed Mar 24 15:11:14 2021 +0100 fotg210-udc: Don't DMA more than the buffer can take [ Upstream commit 3e7c2510bdfe89a9ec223dd7acd6bfc8bb1cbeb6 ] Before this, it wrote as much as available into the buffer, even if it didn't fit. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-7-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 88f1100e523c7e073487645deb5bea3bd08c8cd9 Author: Fabian Vogt Date: Wed Mar 24 15:11:12 2021 +0100 fotg210-udc: Mask GRP2 interrupts we don't handle [ Upstream commit 9aee3a23d6455200702f3a57e731fa11e8408667 ] Currently it leaves unhandled interrupts unmasked, but those are never acked. In the case of a "device idle" interrupt, this leads to an effectively frozen system until plugging it in. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-5-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f580a8046acf1f5cb64988ab7e105dd2544b9e28 Author: Fabian Vogt Date: Wed Mar 24 15:11:11 2021 +0100 fotg210-udc: Remove a dubious condition leading to fotg210_done [ Upstream commit c7f755b243494d6043aadcd9a2989cb157958b95 ] When the EP0 IN request was not completed but less than a packet sent, it would complete the request successfully. That doesn't make sense and can't really happen as fotg210_start_dma always sends min(length, maxpkt) bytes. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-4-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 359d1b0ad23942456b0e6d56b66a59508e712cb8 Author: Fabian Vogt Date: Wed Mar 24 15:11:10 2021 +0100 fotg210-udc: Fix EP0 IN requests bigger than two packets [ Upstream commit 078ba935651e149c92c41161e0322e3372cc2705 ] For a 134 Byte packet, it sends the first two 64 Byte packets just fine, but then notice that less than a packet is remaining and call fotg210_done without actually sending the rest. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-3-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9a97aa4bbe0f68a9ce474b196de4a18b29899dfb Author: Fabian Vogt Date: Wed Mar 24 15:11:09 2021 +0100 fotg210-udc: Fix DMA on EP0 for length > max packet size [ Upstream commit 755915fc28edfc608fa89a163014acb2f31c1e19 ] For a 75 Byte request, it would send the first 64 separately, then detect that the remaining 11 Byte fit into a single DMA, but due to this bug set the length to the original 75 Bytes. This leads to a DMA failure (which is ignored...) and the request completes without the remaining bytes having been sent. Fixes: b84a8dee23fd ("usb: gadget: add Faraday fotg210_udc driver") Signed-off-by: Fabian Vogt Link: https://lore.kernel.org/r/20210324141115.9384-2-fabian@ritter-vogt.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 05ec8192ee4bfdf2a8894a68350dac9f1a155fa6 Author: Tong Zhang Date: Thu Mar 18 23:40:00 2021 -0400 crypto: qat - ADF_STATUS_PF_RUNNING should be set after adf_dev_init [ Upstream commit 8609f5cfdc872fc3a462efa6a3eca5cb1e2f6446 ] ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] Signed-off-by: Tong Zhang Reviewed-by: Andy Shevchenko Fixes: 25c6ffb249f6 ("crypto: qat - check if PF is running") Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2a41049a0e2124ad306395ea5c9c3629faa0a701 Author: Tong Zhang Date: Thu Mar 18 23:39:59 2021 -0400 crypto: qat - don't release uninitialized resources [ Upstream commit b66accaab3791e15ac99c92f236d0d3a6d5bd64e ] adf_vf_isr_resource_alloc() is not unwinding correctly when error happens and it want to release uninitialized resources. To fix this, only release initialized resources. [ 1.792845] Trying to free already-free IRQ 11 [ 1.793091] WARNING: CPU: 0 PID: 182 at kernel/irq/manage.c:1821 free_irq+0x202/0x380 [ 1.801340] Call Trace: [ 1.801477] adf_vf_isr_resource_free+0x32/0xb0 [intel_qat] [ 1.801785] adf_vf_isr_resource_alloc+0x14d/0x150 [intel_qat] [ 1.802105] adf_dev_init+0xba/0x140 [intel_qat] Signed-off-by: Tong Zhang Reviewed-by: Andy Shevchenko Fixes: dd0f368398ea ("crypto: qat - Add qat dh895xcc VF driver") Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit cfd99d250cdea557e01e355d631bfebd84489cd1 Author: Andy Shevchenko Date: Tue Mar 23 17:36:22 2021 +0200 usb: gadget: pch_udc: Check for DMA mapping error [ Upstream commit 4a28d77e359009b846951b06f7c0d8eec8dce298 ] DMA mapping might fail, we have to check it with dma_mapping_error(). Otherwise DMA-API is not happy: DMA-API: pch_udc 0000:02:02.4: device driver failed to check map error[device address=0x00000000027ee678] [size=64 bytes] [mapped as single] Fixes: abab0c67c061 ("usb: pch_udc: Fixed issue which does not work with g_serial") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 44452b7bd35dc3b15169e41b5324f20934b126d0 Author: Andy Shevchenko Date: Tue Mar 23 17:36:21 2021 +0200 usb: gadget: pch_udc: Check if driver is present before calling ->setup() [ Upstream commit fbdbbe6d3ee502b3bdeb4f255196bb45003614be ] Since we have a separate routine for VBUS sense, the interrupt may occur before gadget driver is present. Hence, ->setup() call may oops the kernel: [ 55.245843] BUG: kernel NULL pointer dereference, address: 00000010 ... [ 55.245843] EIP: pch_udc_isr.cold+0x162/0x33f ... [ 55.245843] [ 55.245843] ? pch_udc_svc_data_out+0x160/0x160 Check if driver is present before calling ->setup(). Fixes: f646cf94520e ("USB device driver of Topcliff PCH") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 23978eb064dc46aa3a6f14463ec4b7afb9f07055 Author: Andy Shevchenko Date: Tue Mar 23 17:36:20 2021 +0200 usb: gadget: pch_udc: Replace cpu_to_le32() by lower_32_bits() [ Upstream commit 91356fed6afd1c83bf0d3df1fc336d54e38f0458 ] Either way ~0 will be in the correct byte order, hence replace cpu_to_le32() by lower_32_bits(). Moreover, it makes sparse happy, otherwise it complains: .../pch_udc.c:1813:27: warning: incorrect type in assignment (different base types) .../pch_udc.c:1813:27: expected unsigned int [usertype] dataptr .../pch_udc.c:1813:27: got restricted __le32 [usertype] Fixes: f646cf94520e ("USB device driver of Topcliff PCH") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 369428a646b7d43cf413f59e7e2ac5539fe98138 Author: Otavio Pontes Date: Fri Mar 19 09:55:15 2021 -0700 x86/microcode: Check for offline CPUs before requesting new microcode [ Upstream commit 7189b3c11903667808029ec9766a6e96de5012a5 ] Currently, the late microcode loading mechanism checks whether any CPUs are offlined, and, in such a case, aborts the load attempt. However, this must be done before the kernel caches new microcode from the filesystem. Otherwise, when offlined CPUs are onlined later, those cores are going to be updated through the CPU hotplug notifier callback with the new microcode, while CPUs previously onine will continue to run with the older microcode. For example: Turn off one core (2 threads): echo 0 > /sys/devices/system/cpu/cpu3/online echo 0 > /sys/devices/system/cpu/cpu1/online Install the ucode fails because a primary SMT thread is offline: cp intel-ucode/06-8e-09 /lib/firmware/intel-ucode/ echo 1 > /sys/devices/system/cpu/microcode/reload bash: echo: write error: Invalid argument Turn the core back on echo 1 > /sys/devices/system/cpu/cpu3/online echo 1 > /sys/devices/system/cpu/cpu1/online cat /proc/cpuinfo |grep microcode microcode : 0x30 microcode : 0xde microcode : 0x30 microcode : 0xde The rationale for why the update is aborted when at least one primary thread is offline is because even if that thread is soft-offlined and idle, it will still have to participate in broadcasted MCE's synchronization dance or enter SMM, and in both examples it will execute instructions so it better have the same microcode revision as the other cores. [ bp: Heavily edit and extend commit message with the reasoning behind all this. ] Fixes: 30ec26da9967 ("x86/microcode: Do not upload microcode if CPUs are offline") Signed-off-by: Otavio Pontes Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Acked-by: Ashok Raj Link: https://lkml.kernel.org/r/20210319165515.9240-2-otavio.pontes@intel.com Signed-off-by: Sasha Levin commit 6b8ff2a35a749e18374db139cafe33ce693bedcb Author: Vladimir Barinov Date: Fri Mar 12 18:47:35 2021 +0100 arm64: dts: renesas: r8a77980: Fix vin4-7 endpoint binding [ Upstream commit c8aebc1346522d3569690867ce3996642ad52e01 ] This fixes the bindings in media framework: The CSI40 is endpoint number 2 The CSI41 is endpoint number 3 Signed-off-by: Vladimir Barinov Reviewed-by: Niklas Söderlund Signed-off-by: Niklas Söderlund Link: https://lore.kernel.org/r/20210312174735.2118212-1-niklas.soderlund+renesas@ragnatech.se Fixes: 3182aa4e0bf4d0ee ("arm64: dts: renesas: r8a77980: add CSI2/VIN support") Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit cbf784eff5de0588f1042d322d051a5c45d1d45b Author: Antonio Borneo Date: Fri Mar 12 11:34:46 2021 +0100 spi: stm32: drop devres version of spi_register_master [ Upstream commit 8d559a64f00b59af9cc02b803ff52f6e6880a651 ] A call to spi_unregister_master() triggers calling remove() for all the spi devices binded to the spi master. Some spi device driver requires to "talk" with the spi device during the remove(), e.g.: - a LCD panel like drivers/gpu/drm/panel/panel-lg-lg4573.c will turn off the backlighting sending a command over spi. This implies that the spi master must be fully functional when spi_unregister_master() is called, either if it is called explicitly in the master's remove() code or implicitly by the devres framework. Devres calls devres_release_all() to release all the resources "after" the remove() of the spi master driver (check code of __device_release_driver() in drivers/base/dd.c). If the spi master driver has an empty remove() then there would be no issue; the devres_release_all() will release everything in reverse order w.r.t. probe(). But if code in spi master driver remove() disables the spi or makes it not functional (like in this spi-stm32), then devres cannot be used safely for unregistering the spi master and the binded spi devices. Replace devm_spi_register_master() with spi_register_master() and add spi_unregister_master() as first action in remove(). Fixes: dcbe0d84dfa5 ("spi: add driver for STM32 SPI controller") Signed-off-by: Antonio Borneo Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1615545286-5395-1-git-send-email-alain.volmat@foss.st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 15ee35be92869d4f861d29b10efbbae27fc289a6 Author: Shawn Guo Date: Wed Mar 3 11:31:04 2021 +0800 arm64: dts: qcom: sm8150: fix number of pins in 'gpio-ranges' [ Upstream commit de3abdf3d15c6e7f456e2de3f9da78f3a31414cc ] The last cell of 'gpio-ranges' should be number of GPIO pins, and in case of qcom platform it should match msm_pinctrl_soc_data.ngpio rather than msm_pinctrl_soc_data.ngpio - 1. This fixes the problem that when the last GPIO pin in the range is configured with the following call sequence, it always fails with -EPROBE_DEFER. pinctrl_gpio_set_config() pinctrl_get_device_gpio_range() pinctrl_match_gpio_range() Fixes: e13c6d144fa0 ("arm64: dts: qcom: sm8150: Add base dts file") Cc: Vinod Koul Signed-off-by: Shawn Guo Link: https://lore.kernel.org/r/20210303033106.549-3-shawn.guo@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 168877a575a526c1c64b35103f8af395a59d51d4 Author: Manivannan Sadhasivam Date: Tue Mar 2 18:57:57 2021 +0530 mtd: rawnand: qcom: Return actual error code instead of -ENODEV [ Upstream commit 55fbb9ba4f06cb6aff32daca1e1910173c13ec51 ] In qcom_probe_nand_devices() function, the error code returned by qcom_nand_host_init_and_register() is converted to -ENODEV in the case of failure. This poses issue if -EPROBE_DEFER is returned when the dependency is not available for a component like parser. So let's restructure the error handling logic a bit and return the actual error code in case of qcom_nand_host_init_and_register() failure. Fixes: c76b78d8ec05 ("mtd: nand: Qualcomm NAND controller driver") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit 73744fcb4eb06fa1f14e50915814de1912b72b22 Author: Manivannan Sadhasivam Date: Tue Mar 2 18:57:56 2021 +0530 mtd: Handle possible -EPROBE_DEFER from parse_mtd_partitions() [ Upstream commit 08608adb520e51403be7592c2214846fa440a23a ] There are chances that the parse_mtd_partitions() function will return -EPROBE_DEFER in mtd_device_parse_register(). This might happen when the dependency is not available for the parser. For instance, on SDX55 the MTD_QCOMSMEM_PARTS parser depends on the QCOM_SMEM driver to parse the partitions defined in the shared memory region. With the current flow, the error returned from parse_mtd_partitions() will be discarded in favor of trying to add the fallback partition. This will prevent the driver to end up in probe deferred pool and the partitions won't be parsed even after the QCOM_SMEM driver is available. Fix this issue by bailing out of mtd_device_parse_register() when -EPROBE_DEFER error is returned from parse_mtd_partitions() function and propagate the error code to the driver core for probing later. Fixes: 5ac67ce36cfe ("mtd: move code adding (registering) partitions to the parse_mtd_partitions()") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Miquel Raynal Signed-off-by: Sasha Levin commit e5b3e69eb36ac1178a7a2392616fd29afd288c4e Author: Álvaro Fernández Rojas Date: Wed Feb 24 09:02:10 2021 +0100 mtd: rawnand: brcmnand: fix OOB R/W with Hamming ECC [ Upstream commit f5200c14242fb8fa4a9b93f7fd4064d237e58785 ] Hamming ECC doesn't cover the OOB data, so reading or writing OOB shall always be done without ECC enabled. This is a problem when adding JFFS2 cleanmarkers to erased blocks. If JFFS2 clenmarkers are added to the OOB with ECC enabled, OOB bytes will be changed from ff ff ff to 00 00 00, reporting incorrect ECC errors. Fixes: 27c5b17cd1b1 ("mtd: nand: add NAND driver "library" for Broadcom STB NAND controller") Signed-off-by: Álvaro Fernández Rojas Acked-by: Brian Norris Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210224080210.23686-1-noltari@gmail.com Signed-off-by: Sasha Levin commit 9e612890bb87cb2a5c2f5af0c15d40ce7142398d Author: Dan Carpenter Date: Mon Feb 15 18:58:49 2021 +0300 mtd: rawnand: fsmc: Fix error code in fsmc_nand_probe() [ Upstream commit e7a97528e3c787802d8c643d6ab2f428511bb047 ] If dma_request_channel() fails then the probe fails and it should return a negative error code, but currently it returns success. fixes: 4774fb0a48aa ("mtd: nand/fsmc: Add DMA support") Signed-off-by: Dan Carpenter Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/YCqaOZ83OvPOzLwh@mwanda Signed-off-by: Sasha Levin commit d8897f7b2283a500666c85ef06e820df38ed7b52 Author: Meng Li Date: Fri Feb 26 10:17:37 2021 +0800 regmap: set debugfs_name to NULL after it is freed [ Upstream commit e41a962f82e7afb5b1ee644f48ad0b3aee656268 ] There is a upstream commit cffa4b2122f5("regmap:debugfs: Fix a memory leak when calling regmap_attach_dev") that adds a if condition when create name for debugfs_name. With below function invoking logical, debugfs_name is freed in regmap_debugfs_exit(), but it is not created again because of the if condition introduced by above commit. regmap_reinit_cache() regmap_debugfs_exit() ... regmap_debugfs_init() So, set debugfs_name to NULL after it is freed. Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev") Signed-off-by: Meng Li Link: https://lore.kernel.org/r/20210226021737.7690-1-Meng.Li@windriver.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0d2c860768448433940e242826a9e64daf1f519d Author: Badhri Jagan Sridharan Date: Wed Mar 3 23:09:31 2021 -0800 usb: typec: tcpci: Check ROLE_CONTROL while interpreting CC_STATUS [ Upstream commit 19c234a14eafca78e0bc14ffb8be3891096ce147 ] While interpreting CC_STATUS, ROLE_CONTROL has to be read to make sure that CC1/CC2 is not forced presenting Rp/Rd. >From the TCPCI spec: 4.4.5.2 ROLE_CONTROL (Normative): The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes to control the Rp/Rd directly instead of having the TCPC perform DRP toggling autonomously. When controlling Rp/Rd directly, the TCPM writes to B3..0 (CC1/CC2) each time it wishes to change the CC1/CC2 values. This control is used for TCPM-TCPC implementing Source or Sink only as well as when a connection has been detected via DRP toggling but the TCPM wishes to attempt Try.Src or Try.Snk. Table 4-22. CC_STATUS Register Definition: If (ROLE_CONTROL.CC1 = Rd) or ConnectResult=1) 00b: SNK.Open (Below maximum vRa) 01b: SNK.Default (Above minimum vRd-Connect) 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp-1.5A 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp-3.0A If (ROLE_CONTROL.CC2=Rd) or (ConnectResult=1) 00b: SNK.Open (Below maximum vRa) 01b: SNK.Default (Above minimum vRd-Connect) 10b: SNK.Power1.5 (Above minimum vRd-Connect) Detects Rp 1.5A 11b: SNK.Power3.0 (Above minimum vRd-Connect) Detects Rp 3.0A Fixes: 74e656d6b0551 ("staging: typec: Type-C Port Controller Interface driver (tcpci)") Acked-by: Heikki Krogerus Signed-off-by: Badhri Jagan Sridharan Link: https://lore.kernel.org/r/20210304070931.1947316-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6e666a05e5404d1c0e628decc57393039b7849bc Author: Erwan Le Ray Date: Thu Mar 4 17:23:07 2021 +0100 serial: stm32: fix tx_empty condition [ Upstream commit 3db1d52466dc11dca4e47ef12a6e6e97f846af62 ] In "tx_empty", we should poll TC bit in both DMA and PIO modes (instead of TXE) to check transmission data register has been transmitted independently of the FIFO mode. TC indicates that both transmit register and shift register are empty. When shift register is empty, tx_empty should return TIOCSER_TEMT instead of TC value. Cleans the USART_CR_TC TCCF register define (transmission complete clear flag) as it is duplicate of USART_ICR_TCCF. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-13-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 12e423331ec9cb740bdf3d14fd8a3504a2ef7721 Author: Erwan Le Ray Date: Thu Mar 4 17:22:58 2021 +0100 serial: stm32: fix incorrect characters on console [ Upstream commit f264c6f6aece81a9f8fbdf912b20bd3feb476a7a ] Incorrect characters are observed on console during boot. This issue occurs when init/main.c is modifying termios settings to open /dev/console on the rootfs. This patch adds a waiting loop in set_termios to wait for TX shift register empty (and TX FIFO if any) before stopping serial port. Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") Signed-off-by: Erwan Le Ray Link: https://lore.kernel.org/r/20210304162308.8984-4-erwan.leray@foss.st.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6be27923140ac350f51bb94132a9ba1fbf274aab Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:25 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Snow [ Upstream commit 8987efbb17c2522be8615085df9a14da2ab53d34 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: c61248afa819 ("ARM: dts: Add max77686 RTC interrupt to cros5250-common") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-9-krzk@kernel.org Signed-off-by: Sasha Levin commit aacfc3bef07b2de3470991aae06219823cf5c0f4 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:24 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on SMDK5250 [ Upstream commit f6368c60561370e4a92fac22982a3bd656172170 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 47580e8d94c2 ("ARM: dts: Specify MAX77686 pmic interrupt for exynos5250-smdk5250") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-8-krzk@kernel.org Signed-off-by: Sasha Levin commit d788a900f362cbbca9d48014afb8d057b73d6533 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:22 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Odroid X/U3 family [ Upstream commit 6503c568e97a52f8b7a3109718db438e52e59485 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: eea6653aae7b ("ARM: dts: Enable PMIC interrupts for exynos4412-odroid-common") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-6-krzk@kernel.org Signed-off-by: Sasha Levin commit f9b701bc13daf18ded5844ebbbf000cc70cb6e6d Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:21 2020 +0100 ARM: dts: exynos: correct PMIC interrupt trigger level on Midas family [ Upstream commit e52dcd6e70fab51f53292e53336ecb007bb60889 ] The Maxim PMIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 15dfdfad2d4a ("ARM: dts: Add basic dts for Exynos4412-based Trats 2 board") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-5-krzk@kernel.org Signed-off-by: Sasha Levin commit 6cf80f1fc1a97cf64c3877e7c5ed2dcda8f55338 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:20 2020 +0100 ARM: dts: exynos: correct MUIC interrupt trigger level on Midas family [ Upstream commit 15107e443ab8c6cb35eff10438993e4bc944d9ae ] The Maxim MUIC datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. Without specifying the interrupt type in Devicetree, kernel might apply some fixed configuration, not necessarily working for this hardware. Additionally, the interrupt line is shared so using level sensitive interrupt is here especially important to avoid races. Fixes: 7eec1266751b ("ARM: dts: Add Maxim 77693 PMIC to exynos4412-trats2") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-4-krzk@kernel.org Signed-off-by: Sasha Levin commit 73bc2732108c359cbe4640fd465bd22ac7ef5a57 Author: Krzysztof Kozlowski Date: Thu Dec 10 22:25:19 2020 +0100 ARM: dts: exynos: correct fuel gauge interrupt trigger level on Midas family [ Upstream commit 8a45f33bd36efbb624198cfa9fdf1f66fd1c3d26 ] The Maxim fuel gauge datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU. The falling edge interrupt will mostly work but it's not correct. Fixes: e8614292cd41 ("ARM: dts: Add Maxim 77693 fuel gauge node for exynos4412-trats2") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20201210212534.216197-3-krzk@kernel.org Signed-off-by: Sasha Levin commit 12d9d517a2fe816a57852cade62fa9dbe09f3461 Author: Colin Ian King Date: Tue Feb 23 19:38:21 2021 +0000 memory: gpmc: fix out of bounds read and dereference on gpmc_cs[] [ Upstream commit e004c3e67b6459c99285b18366a71af467d869f5 ] Currently the array gpmc_cs is indexed by cs before it cs is range checked and the pointer read from this out-of-index read is dereferenced. Fix this by performing the range check on cs before the read and the following pointer dereference. Addresses-Coverity: ("Negative array index read") Fixes: 9ed7a776eb50 ("ARM: OMAP2+: Fix support for multiple devices on a GPMC chip select") Signed-off-by: Colin Ian King Reviewed-by: Tony Lindgren Link: https://lore.kernel.org/r/20210223193821.17232-1-colin.king@canonical.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 52189bf0b2a244bf574a586319ec5f2d2ccd442f Author: Andy Shevchenko Date: Tue Mar 23 17:36:24 2021 +0200 usb: gadget: pch_udc: Revert d3cb25a12138 completely commit 50a318cc9b54a36f00beadf77e578a50f3620477 upstream. The commit d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") obviously was not thought through and had made the situation even worse than it was before. Two changes after almost reverted it. but a few leftovers have been left as it. With this revert d3cb25a12138 completely. While at it, narrow down the scope of unlocked section to prevent potential race when prot_stall is assigned. Fixes: d3cb25a12138 ("usb: gadget: udc: fix spin_lock in pch_udc") Fixes: 9903b6bedd38 ("usb: gadget: pch-udc: fix lock") Fixes: 1d23d16a88e6 ("usb: gadget: pch_udc: reorder spin_[un]lock to avoid deadlock") Cc: Iago Abal Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210323153626.54908-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit db699975f72d5237436a0ada5a3475958daab821 Author: Dan Carpenter Date: Tue Mar 23 16:19:35 2021 +0300 ovl: fix missing revert_creds() on error path commit 7b279bbfd2b230c7a210ff8f405799c7e46bbf48 upstream. Smatch complains about missing that the ovl_override_creds() doesn't have a matching revert_creds() if the dentry is disconnected. Fix this by moving the ovl_override_creds() until after the disconnected check. Fixes: aa3ff3c152ff ("ovl: copy up of disconnected dentries") Signed-off-by: Dan Carpenter Signed-off-by: Miklos Szeredi Signed-off-by: Greg Kroah-Hartman commit a51050108bed36196f9e8ea047181de240e1abe3 Author: Jae Hyun Yoo Date: Thu Apr 8 10:28:03 2021 -0700 Revert "i3c master: fix missing destroy_workqueue() on error in i3c_master_register" commit 0d95f41ebde40d552bb4fea64b1d618607915fd6 upstream. Adding the destroy_workqueue call in i3c_master_register introduced below kernel warning because it makes duplicate destroy_workqueue calls when i3c_master_register fails after allocating the workqueue. The workqueue will be destroyed by i3c_masterdev_release which is called by put_device at the end of the i3c_master_register function eventually in failure cases so the workqueue doesn't need to be destroyed in i3c_master_register. [ 6.972952] WARNING: CPU: 1 PID: 1 at lib/list_debug.c:48 __list_del_entry_valid+0x9c/0xf4 [ 6.982205] list_del corruption, 8fe03c08->prev is LIST_POISON2 (00000122) [ 6.989910] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W 5.10.23-c12838a-dirty-31dc772 #1 [ 7.000295] Hardware name: Generic DT based system [ 7.005638] Backtrace: [ 7.008369] [<809133f0>] (dump_backtrace) from [<80913644>] (show_stack+0x20/0x24) [ 7.016819] r7:00000030 r6:60000013 r5:00000000 r4:813b5d40 [ 7.023137] [<80913624>] (show_stack) from [<8091e1a0>] (dump_stack+0x9c/0xb0) [ 7.031201] [<8091e104>] (dump_stack) from [<8011fa30>] (__warn+0xf8/0x154) [ 7.038972] r7:00000030 r6:00000009 r5:804fa1c8 r4:80b6eca4 [ 7.045289] [<8011f938>] (__warn) from [<80913d14>] (warn_slowpath_fmt+0x8c/0xc0) [ 7.053641] r7:00000030 r6:80b6eca4 r5:80b6ed74 r4:818cc000 [ 7.059960] [<80913c8c>] (warn_slowpath_fmt) from [<804fa1c8>] (__list_del_entry_valid+0x9c/0xf4) [ 7.069866] r9:96becf8c r8:818cc000 r7:8fe03c10 r6:8fe03c00 r5:8fe03ba0 r4:ff7ead4c [ 7.078513] [<804fa12c>] (__list_del_entry_valid) from [<8013f0b4>] (destroy_workqueue+0x1c4/0x23c) [ 7.088615] [<8013eef0>] (destroy_workqueue) from [<806aa124>] (i3c_masterdev_release+0x40/0xb0) [ 7.098421] r7:00000000 r6:81a43b80 r5:8fe65360 r4:8fe65048 [ 7.104740] [<806aa0e4>] (i3c_masterdev_release) from [<805f3f04>] (device_release+0x40/0xb0) [ 7.114254] r5:00000000 r4:8fe65048 [ 7.118245] [<805f3ec4>] (device_release) from [<808fe754>] (kobject_put+0xc8/0x204) [ 7.126885] r5:813978dc r4:8fe65048 [ 7.130877] [<808fe68c>] (kobject_put) from [<805f5fbc>] (put_device+0x20/0x24) [ 7.139037] r7:8fe65358 r6:8fe65368 r5:8fe65358 r4:8fe65048 [ 7.145355] [<805f5f9c>] (put_device) from [<806abac4>] (i3c_master_register+0x338/0xb00) [ 7.154487] [<806ab78c>] (i3c_master_register) from [<806ae084>] (dw_i3c_probe+0x224/0x24c) [ 7.163811] r10:00000000 r9:8fe7a100 r8:00000032 r7:819fa810 r6:819fa800 r5:8fe65040 [ 7.172547] r4:00000000 [ 7.175376] [<806ade60>] (dw_i3c_probe) from [<805fdc14>] (platform_drv_probe+0x44/0x80) [ 7.184409] r9:813a25c0 r8:00000000 r7:815ec114 r6:00000000 r5:813a25c0 r4:819fa810 [ 7.193053] [<805fdbd0>] (platform_drv_probe) from [<805fb83c>] (really_probe+0x108/0x50c) [ 7.202275] r5:815ec004 r4:819fa810 [ 7.206265] [<805fb734>] (really_probe) from [<805fc180>] (driver_probe_device+0xb4/0x190) [ 7.215492] r10:813dc000 r9:80c4385c r8:000000d9 r7:813a25c0 r6:819fa810 r5:00000000 [ 7.224228] r4:813a25c0 [ 7.227055] [<805fc0cc>] (driver_probe_device) from [<805fc5cc>] (device_driver_attach+0xb8/0xc0) [ 7.236959] r9:80c4385c r8:000000d9 r7:813a25c0 r6:819fa854 r4:819fa810 [ 7.244439] [<805fc514>] (device_driver_attach) from [<805fc65c>] (__driver_attach+0x88/0x16c) [ 7.254051] r7:00000000 r6:819fa810 r5:00000000 r4:813a25c0 [ 7.260369] [<805fc5d4>] (__driver_attach) from [<805f954c>] (bus_for_each_dev+0x88/0xc8) [ 7.269489] r7:00000000 r6:818cc000 r5:805fc5d4 r4:813a25c0 [ 7.275806] [<805f94c4>] (bus_for_each_dev) from [<805fc76c>] (driver_attach+0x2c/0x30) [ 7.284739] r7:81397c98 r6:00000000 r5:8fe7db80 r4:813a25c0 [ 7.291057] [<805fc740>] (driver_attach) from [<805f9eec>] (bus_add_driver+0x120/0x200) [ 7.299984] [<805f9dcc>] (bus_add_driver) from [<805fce44>] (driver_register+0x98/0x128) [ 7.309005] r7:80c4383c r6:00000000 r5:00000000 r4:813a25c0 [ 7.315323] [<805fcdac>] (driver_register) from [<805fedb4>] (__platform_driver_register+0x50/0x58) [ 7.325410] r5:818cc000 r4:81397c98 [ 7.329404] [<805fed64>] (__platform_driver_register) from [<80c23398>] (dw_i3c_driver_init+0x24/0x28) [ 7.339790] r5:818cc000 r4:80c23374 [ 7.343784] [<80c23374>] (dw_i3c_driver_init) from [<80c01300>] (do_one_initcall+0xac/0x1d0) [ 7.353206] [<80c01254>] (do_one_initcall) from [<80c01630>] (kernel_init_freeable+0x1a8/0x204) [ 7.362916] r8:000000d9 r7:80c4383c r6:00000007 r5:819ca2c0 r4:80c67680 [ 7.370398] [<80c01488>] (kernel_init_freeable) from [<8091eb18>] (kernel_init+0x18/0x12c) [ 7.379616] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:8091eb00 [ 7.388343] r4:00000000 [ 7.391170] [<8091eb00>] (kernel_init) from [<80100148>] (ret_from_fork+0x14/0x2c) [ 7.399607] Exception stack(0x818cdfb0 to 0x818cdff8) [ 7.405243] dfa0: 00000000 00000000 00000000 00000000 [ 7.414371] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 7.423499] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 7.430879] r5:8091eb00 r4:00000000 This reverts commit 59165d16c699182b86b5c65181013f1fd88feb62. Fixes: 59165d16c699 ("i3c master: fix missing destroy_workqueue() on error in i3c_master_register") Signed-off-by: Jae Hyun Yoo Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210408172803.24599-1-jae.hyun.yoo@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7d1bc32d6477ff96a32695ea4be8144e4513ab2d Author: Sean Christopherson Date: Mon Apr 12 15:20:49 2021 -0700 KVM: Stop looking for coalesced MMIO zones if the bus is destroyed commit 5d3c4c79384af06e3c8e25b7770b6247496b4417 upstream. Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus. If it can't instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn't tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement. Fixes: f65886606c2d ("KVM: fix memory leak in kvm_io_bus_unregister_dev()") Cc: stable@vger.kernel.org Reported-by: Hao Sun Signed-off-by: Sean Christopherson Message-Id: <20210412222050.876100-3-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit cc6623055f2d9c45c2a977985f3408f426e83c76 Author: Sean Christopherson Date: Wed Apr 21 19:21:24 2021 -0700 KVM: nVMX: Truncate bits 63:32 of VMCS field on nested check in !64-bit commit ee050a577523dfd5fac95e6cc182ebe0293ead59 upstream. Drop bits 63:32 of the VMCS field encoding when checking for a nested VM-Exit on VMREAD/VMWRITE in !64-bit mode. VMREAD and VMWRITE always use 32-bit operands outside of 64-bit mode. The actual emulation of VMREAD/VMWRITE does the right thing, this bug is purely limited to incorrectly causing a nested VM-Exit if a GPR happens to have bits 63:32 set outside of 64-bit mode. Fixes: a7cde481b6e8 ("KVM: nVMX: Do not forward VMREAD/VMWRITE VMExits to L1 if required so by vmcs12 vmread/vmwrite bitmaps") Cc: stable@vger.kernel.org Signed-off-by: Sean Christopherson Message-Id: <20210422022128.3464144-6-seanjc@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 3582644257477000e788155c27c4023bd3d8745a Author: Claudio Imbrenda Date: Mon Mar 22 15:05:58 2021 +0100 KVM: s390: split kvm_s390_real_to_abs commit c5d1f6b531e68888cbe6718b3f77a60115d58b9c upstream. A new function _kvm_s390_real_to_abs will apply prefixing to a real address with a given prefix value. The old kvm_s390_real_to_abs becomes now a wrapper around the new function. This is needed to avoid code duplication in vSIE. Signed-off-by: Claudio Imbrenda Reviewed-by: David Hildenbrand Reviewed-by: Thomas Huth Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210322140559.500716-2-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 45a3ae26fcd9454cdad646e2e42cc3ca432b3300 Author: David Hildenbrand Date: Mon May 3 14:12:44 2021 +0200 s390: fix detection of vector enhancements facility 1 vs. vector packed decimal facility commit b208108638c4bd3215792415944467c36f5dfd97 upstream. The PoP documents: 134: The vector packed decimal facility is installed in the z/Architecture architectural mode. When bit 134 is one, bit 129 is also one. 135: The vector enhancements facility 1 is installed in the z/Architecture architectural mode. When bit 135 is one, bit 129 is also one. Looks like we confuse the vector enhancements facility 1 ("EXT") with the Vector packed decimal facility ("BCD"). Let's fix the facility checks. Detected while working on QEMU/tcg z14 support and only unlocking the vector enhancements facility 1, but not the vector packed decimal facility. Fixes: 2583b848cad0 ("s390: report new vector facilities") Cc: Vasily Gorbik Signed-off-by: David Hildenbrand Reviewed-by: Christian Borntraeger Reviewed-by: Cornelia Huck Reviewed-by: Janosch Frank Link: https://lore.kernel.org/r/20210503121244.25232-1-david@redhat.com Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 9ea2c4fd1a72d743e94de3b80811f28ea7a02cfc Author: Heiko Carstens Date: Thu Apr 15 10:01:27 2021 +0200 KVM: s390: fix guarded storage control register handling commit 44bada28219031f9e8e86b84460606efa57b871e upstream. store_regs_fmt2() has an ordering problem: first the guarded storage facility is enabled on the local cpu, then preemption disabled, and then the STGSC (store guarded storage controls) instruction is executed. If the process gets scheduled away between enabling the guarded storage facility and before preemption is disabled, this might lead to a special operation exception and therefore kernel crash as soon as the process is scheduled back and the STGSC instruction is executed. Fixes: 4e0b1ab72b8a ("KVM: s390: gs support for kvm guests") Signed-off-by: Heiko Carstens Reviewed-by: Christian Borntraeger Reviewed-by: David Hildenbrand Reviewed-by: Janosch Frank Reviewed-by: Cornelia Huck Cc: # 4.12 Link: https://lore.kernel.org/r/20210415080127.1061275-1-hca@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 34a6d1d57c71fc2ff3b411f2f6eeea1b75239cf1 Author: Claudio Imbrenda Date: Tue Mar 2 13:36:44 2021 +0100 KVM: s390: split kvm_s390_logical_to_effective commit f85f1baaa18932a041fd2b1c2ca6cfd9898c7d2b upstream. Split kvm_s390_logical_to_effective to a generic function called _kvm_s390_logical_to_effective. The new function takes a PSW and an address and returns the address with the appropriate bits masked off. The old function now calls the new function with the appropriate PSW from the vCPU. This is needed to avoid code duplication for vSIE. Signed-off-by: Claudio Imbrenda Reviewed-by: Christian Borntraeger Cc: stable@vger.kernel.org # for VSIE: correctly handle MVPG when in VSIE Link: https://lore.kernel.org/r/20210302174443.514363-2-imbrenda@linux.ibm.com Signed-off-by: Christian Borntraeger Signed-off-by: Greg Kroah-Hartman commit 027de80194fb4a61935227966f93f85d57db8a39 Author: Sami Loone Date: Sat May 1 12:07:53 2021 +0200 ALSA: hda/realtek: ALC285 Thinkpad jack pin quirk is unreachable commit 266fd994b2b0ab7ba3e5541868838ce30775964b upstream. In 9bbb94e57df1 ("ALSA: hda/realtek: fix static noise on ALC285 Lenovo laptops") an existing Lenovo quirk was made more generic by removing a 0x12 pin requirement from the entry. This made the second chance table Thinkpad jack entry unreachable as the pin configurations became identical. Revert the 0x12 pin requirement removal and move Thinkpad jack pin quirk back to the primary pin table as they can co-exist when more specific configurations come first. Add a more targeted pin quirk for Lenovo devices that have 0x12 as 0x40000000. Tested on Yoga 6 (AMD) laptop. [ Corrected the commit ID -- tiwai ] Fixes: 9bbb94e57df1 ("ALSA: hda/realtek: fix static noise on ALC285 Lenovo laptops") Signed-off-by: Sami Loone Cc: Link: https://lore.kernel.org/r/YI0oefvTYn8URYDb@yoga Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1bfa051571ac74b91b9292ecd2cdb8f479904eef Author: Takashi Iwai Date: Wed Apr 28 13:27:03 2021 +0200 ALSA: hda/realtek: Remove redundant entry for ALC861 Haier/Uniwill devices commit defce244b01ee12534910a4544e11be5eb927d25 upstream. The quirk entry for Uniwill ECS M31EI is with the PCI SSID device 0, which means matching with all. That is, it's essentially equivalent with SND_PCI_QUIRK_VENDOR(0x1584), which also matches with the previous entry for Haier W18 applying the very same quirk. Let's unify them with the single vendor-quirk entry. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-13-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9337f5ba5090f30da8823ece60be3fedbe6cd90e Author: Takashi Iwai Date: Wed Apr 28 13:27:02 2021 +0200 ALSA: hda/realtek: Re-order ALC662 quirk table entries commit 9edeb1109d05953b2f0e24e5b2341a98c3fa78d5 upstream. Just re-order the alc662_fixup_tbl[] entries for Acer and ASUS devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-12-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 5f68b0ec9882112864b05cab49c72d6cb7745f35 Author: Takashi Iwai Date: Wed Apr 28 13:27:01 2021 +0200 ALSA: hda/realtek: Re-order remaining ALC269 quirk table entries commit c656f747df151a0a89756a5312f4ca2116758ba4 upstream. Just re-order the alc269_fixup_tbl[] entries for FSC, Medion, Samsung and Lemote devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-11-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 15b414029478ff770e826242615dab2e00c59b2e Author: Takashi Iwai Date: Wed Apr 28 13:27:00 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Lenovo quirk table entries commit f552ff54c2a700616a02b038e4bf3cbf859f65b7 upstream. Just re-order the alc269_fixup_tbl[] entries for Lenovo devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-10-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 99aa203c6eb6bdbcac8746cb4e275da10df9b8b6 Author: Takashi Iwai Date: Wed Apr 28 13:26:59 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Sony quirk table entries commit cab561f8d4bc9b196ae20c960aa5da89fd786ab5 upstream. Just re-order the alc269_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-9-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1f1612fc6bea031e441fe9dcc8c8639d490db34d Author: Takashi Iwai Date: Wed Apr 28 13:26:58 2021 +0200 ALSA: hda/realtek: Re-order ALC269 ASUS quirk table entries commit 3cd0ed636dd19e7fbe3ebe8de8476e1718d5a8f1 upstream. Just re-order the alc269_fixup_tbl[] entries for ASUS devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-8-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 65d5b99c1ea9ca260ae88b3565750ed2cb6502e7 Author: Takashi Iwai Date: Wed Apr 28 13:26:57 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Dell quirk table entries commit aa143ad39a52d968ac69e426d329bb74f270e6ca upstream. Just re-order the alc269_fixup_tbl[] entries for Dell devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-7-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit b161e02481d8505a2e970bec111cfa4dbf2e87ce Author: Takashi Iwai Date: Wed Apr 28 13:26:56 2021 +0200 ALSA: hda/realtek: Re-order ALC269 Acer quirk table entries commit 433f894ec7fbd3b4bf1f3187b2ddd566078c4aef upstream. Just re-order the alc269_fixup_tbl[] entries for Acer devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-6-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit bd0e9154100c25cf4bb58dc139c7518c24d215bb Author: Takashi Iwai Date: Wed Apr 28 13:26:55 2021 +0200 ALSA: hda/realtek: Re-order ALC269 HP quirk table entries commit 45461e3b554c75ddff9703539f3711cc3dfb0422 upstream. Just re-order the alc269_fixup_tbl[] entries for HP devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Formerly, some entries were grouped for the actual codec, but this doesn't seem reasonable to keep in that way. So now we simply keep the PCI SSID order for the whole. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-5-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e97cf247ba44105b5640ec0f7371b6e124f4e85c Author: Takashi Iwai Date: Wed Apr 28 13:26:54 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Clevo quirk table entries commit 13e1a4cd490b959a4c72c9f4fb502ef56b190062 upstream. Just re-order the alc882_fixup_tbl[] entries for Clevo devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also, user lower hex letters in the entry. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 02968e62200a2ac07b82f1be8fe22488df4ed963 Author: Takashi Iwai Date: Wed Apr 28 13:26:53 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Sony quirk table entries commit b7529c18feecb1af92f9db08c8e7fe446a82d96d upstream. Just re-order the alc882_fixup_tbl[] entries for Sony devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6d9e8828fa77d5baf8bd91e6bb90dd25d909496c Author: Takashi Iwai Date: Wed Apr 28 13:26:52 2021 +0200 ALSA: hda/realtek: Re-order ALC882 Acer quirk table entries commit b265047ac56bad8c4f3d0c8bf9cb4e828ee0d28e upstream. Just re-order the alc882_fixup_tbl[] entries for Acer devices for avoiding the oversight of the duplicated or unapplied item in future. No functional changes. Also Cc-to-stable for the further patch applications. Cc: Link: https://lore.kernel.org/r/20210428112704.23967-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit e584e52783a465d4dc84e02e686a0ebc3246305b Author: Harry Wentland Date: Thu Apr 22 19:10:52 2021 -0400 drm/amd/display: Reject non-zero src_y and src_x for video planes commit d89f6048bdcb6a56abb396c584747d5eeae650db upstream. [Why] This hasn't been well tested and leads to complete system hangs on DCN1 based systems, possibly others. The system hang can be reproduced by gesturing the video on the YouTube Android app on ChromeOS into full screen. [How] Reject atomic commits with non-zero drm_plane_state.src_x or src_y values. v2: - Add code comment describing the reason we're rejecting non-zero src_x and src_y - Drop gerrit Change-Id - Add stable CC - Based on amd-staging-drm-next v3: removed trailing whitespace Signed-off-by: Harry Wentland Cc: stable@vger.kernel.org Cc: nicholas.kazlauskas@amd.com Cc: amd-gfx@lists.freedesktop.org Cc: alexander.deucher@amd.com Cc: Roman.Li@amd.com Cc: hersenxs.wu@amd.com Cc: danny.wang@amd.com Reviewed-by: Nicholas Kazlauskas Acked-by: Christian König Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 56f2ea0bc2a12d08215b20fe953c0d019baa3b6a Author: Colin Ian King Date: Wed Mar 3 00:27:59 2021 +0000 drm/radeon: fix copy of uninitialized variable back to userspace commit 8dbc2ccac5a65c5b57e3070e36a3dc97c7970d96 upstream. Currently the ioctl command RADEON_INFO_SI_BACKEND_ENABLED_MASK can copy back uninitialised data in value_tmp that pointer *value points to. This can occur when rdev->family is less than CHIP_BONAIRE and less than CHIP_TAHITI. Fix this by adding in a missing -EINVAL so that no invalid value is copied back to userspace. Addresses-Coverity: ("Uninitialized scalar variable) Cc: stable@vger.kernel.org # 3.13+ Fixes: 439a1cfffe2c ("drm/radeon: expose render backend mask to the userspace") Reviewed-by: Christian König Signed-off-by: Colin Ian King Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 4aea3ddac00a5b6f106416ef849af252dca79cd3 Author: Boris Brezillon Date: Fri Feb 5 12:17:56 2021 +0100 drm/panfrost: Don't try to map pages that are already mapped commit f45da8204ff1707c529a8769f5467ff16f504b26 upstream. We allocate 2MB chunks at a time, so it might appear that a page fault has already been handled by a previous page fault when we reach panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the same area twice. Cc: Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-3-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman commit debaae7ac45a0dbcd16936773fe89f08f7e6df64 Author: Boris Brezillon Date: Fri Feb 5 12:17:55 2021 +0100 drm/panfrost: Clear MMU irqs before handling the fault commit 3aa0a80fc692c9959c261f4c5bfe9c23ddd90562 upstream. When a fault is handled it will unblock the GPU which will continue executing its shader and might fault almost immediately on a different page. If we clear interrupts after handling the fault we might miss new faults, so clear them before. Cc: Fixes: 187d2929206e ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by: Boris Brezillon Reviewed-by: Steven Price Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-2-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman commit 6b5aa0cf321c25f41e09a61c83ee4dc7ab9549cb Author: Ping-Ke Shih Date: Thu Apr 1 14:27:17 2021 -0500 rtw88: Fix array overrun in rtw_get_tx_power_params() commit 2ff25985ea9ccc6c9af2c77b0b49045adcc62e0e upstream. Using a kernel with the Undefined Behaviour Sanity Checker (UBSAN) enabled, the following array overrun is logged: ================================================================================ UBSAN: array-index-out-of-bounds in /home/finger/wireless-drivers-next/drivers/net/wireless/realtek/rtw88/phy.c:1789:34 index 5 is out of range for type 'u8 [5]' CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: G O 5.12.0-rc5-00086-gd88bba47038e-dirty #651 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014 Workqueue: phy0 ieee80211_scan_work [mac80211] Call Trace: dump_stack+0x64/0x7c ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold+0x43/0x48 rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core] ? rtw_pci_read16+0x20/0x20 [rtw_pci] ? check_hw_ready+0x50/0x90 [rtw_core] rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core] rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core] rtw_set_channel+0xab/0x110 [rtw_core] rtw_ops_config+0x87/0xc0 [rtw_core] ieee80211_hw_config+0x9d/0x130 [mac80211] ieee80211_scan_state_set_channel+0x81/0x170 [mac80211] ieee80211_scan_work+0x19f/0x2a0 [mac80211] process_one_work+0x1dd/0x3a0 worker_thread+0x49/0x330 ? rescuer_thread+0x3a0/0x3a0 kthread+0x134/0x150 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ================================================================================ The statement where an array is being overrun is shown in the following snippet: if (rate <= DESC_RATE11M) tx_power = pwr_idx_2g->cck_base[group]; else ====> tx_power = pwr_idx_2g->bw40_base[group]; The associated arrays are defined in main.h as follows: struct rtw_2g_txpwr_idx { u8 cck_base[6]; u8 bw40_base[5]; struct rtw_2g_1s_pwr_idx_diff ht_1s_diff; struct rtw_2g_ns_pwr_idx_diff ht_2s_diff; struct rtw_2g_ns_pwr_idx_diff ht_3s_diff; struct rtw_2g_ns_pwr_idx_diff ht_4s_diff; }; The problem arises because the value of group is 5 for channel 14. The trivial increase in the dimension of bw40_base fails as this struct must match the layout of efuse. The fix is to add the rate as an argument to rtw_get_channel_group() and set the group for channel 14 to 4 if rate <= DESC_RATE11M. This patch fixes commit fa6dfe6bff24 ("rtw88: resolve order of tx power setting routines") Fixes: fa6dfe6bff24 ("rtw88: resolve order of tx power setting routines") Reported-by: Богдан Пилипенко Signed-off-by: Larry Finger Signed-off-by: Ping-Ke Shih Cc: Stable Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20210401192717.28927-1-Larry.Finger@lwfinger.net Signed-off-by: Greg Kroah-Hartman commit e5b02c096145c09073dab91c6b359875ddd8ee29 Author: Johannes Berg Date: Fri Apr 16 09:42:14 2021 +0200 cfg80211: scan: drop entry from hidden_list on overflow commit 010bfbe768f7ecc876ffba92db30432de4997e2a upstream. If we overflow the maximum number of BSS entries and free the new entry, drop it from any hidden_list that it may have been added to in the code above or in cfg80211_combine_bsses(). Reported-by: Dan Carpenter Link: https://lore.kernel.org/r/20210416094212.5de7d1676ad7.Ied283b0bc5f504845e7d6ab90626bdfa68bb3dc0@changeid Cc: stable@vger.kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 16b68fb8df43d33558c1777ca39963316632fb1a Author: Dan Carpenter Date: Wed Apr 14 11:29:55 2021 +0300 ipw2x00: potential buffer overflow in libipw_wx_set_encodeext() commit 260a9ad9446723d4063ed802989758852809714d upstream. The "ext->key_len" is a u16 that comes from the user. If it's over SCM_KEY_LEN (32) that could lead to memory corruption. Fixes: e0d369d1d969 ("[PATCH] ieee82011: Added WE-18 support to default wireless extension handler") Cc: stable@vger.kernel.org Signed-off-by: Dan Carpenter Acked-by: Stanislav Yakovlev Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/YHaoA1i+8uT4ir4h@mwanda Signed-off-by: Greg Kroah-Hartman commit af7ea06b3cae9c02e88fcc017b9e51dab047002e Author: Jan Glauber Date: Wed Mar 17 15:04:39 2021 +0100 md: Fix missing unused status line of /proc/mdstat commit 7abfabaf5f805f5171d133ce6af9b65ab766e76a upstream. Reading /proc/mdstat with a read buffer size that would not fit the unused status line in the first read will skip this line from the output. So 'dd if=/proc/mdstat bs=64 2>/dev/null' will not print something like: unused devices: Don't return NULL immediately in start() for v=2 but call show() once to print the status line also for multiple reads. Cc: stable@vger.kernel.org Fixes: 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") Signed-off-by: Jan Glauber Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 79c1bfae668d34db9b946a5de86d90a615cca0b1 Author: Zhao Heming Date: Sat Apr 3 11:01:25 2021 +0800 md: md_open returns -EBUSY when entering racing area commit 6a4db2a60306eb65bfb14ccc9fde035b74a4b4e7 upstream. commit d3374825ce57 ("md: make devices disappear when they are no longer needed.") introduced protection between mddev creating & removing. The md_open shouldn't create mddev when all_mddevs list doesn't contain mddev. With currently code logic, there will be very easy to trigger soft lockup in non-preempt env. This patch changes md_open returning from -ERESTARTSYS to -EBUSY, which will break the infinitely retry when md_open enter racing area. This patch is partly fix soft lockup issue, full fix needs mddev_find is split into two functions: mddev_find & mddev_find_or_alloc. And md_open should call new mddev_find (it only does searching job). For more detail, please refer with Christoph's "split mddev_find" patch in later commits. commit adb9bbf1a28499c6df7c58c09c6f68d8d355d5e5 Author: Christoph Hellwig Date: Sat Apr 3 18:15:28 2021 +0200 md: factor out a mddev_find_locked helper from mddev_find commit 8b57251f9a91f5e5a599de7549915d2d226cc3af upstream. Factor out a self-contained helper to just lookup a mddev by the dev_t "unit". Cc: stable@vger.kernel.org Reviewed-by: Heming Zhao Signed-off-by: Christoph Hellwig Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit afa4de0926635d07a0431a27e5c2f504b9c1490d Author: Christoph Hellwig Date: Sat Apr 3 18:15:29 2021 +0200 md: split mddev_find commit 65aa97c4d2bfd76677c211b9d03ef05a98c6d68e upstream. Split mddev_find into a simple mddev_find that just finds an existing mddev by the unit number, and a more complicated mddev_find that deals with find or allocating a mddev. This turns out to fix this bug reported by Zhao Heming. ----------------------------- snip ------------------------------ commit d3374825ce57 ("md: make devices disappear when they are no longer needed.") introduced protection between mddev creating & removing. The md_open shouldn't create mddev when all_mddevs list doesn't contain mddev. With currently code logic, there will be very easy to trigger soft lockup in non-preempt env. commit acdf531e77f098b807ba1b177dbf167ff0621c70 Author: Heming Zhao Date: Thu Apr 8 15:44:15 2021 +0800 md-cluster: fix use-after-free issue when removing rdev commit f7c7a2f9a23e5b6e0f5251f29648d0238bb7757e upstream. md_kick_rdev_from_array will remove rdev, so we should use rdev_for_each_safe to search list. How to trigger: env: Two nodes on kvm-qemu x86_64 VMs (2C2G with 2 iscsi luns). ``` node2=192.168.0.3 for i in {1..20}; do echo ==== $i `date` ====; mdadm -Ss && ssh ${node2} "mdadm -Ss" wipefs -a /dev/sda /dev/sdb mdadm -CR /dev/md0 -b clustered -e 1.2 -n 2 -l 1 /dev/sda \ /dev/sdb --assume-clean ssh ${node2} "mdadm -A /dev/md0 /dev/sda /dev/sdb" mdadm --wait /dev/md0 ssh ${node2} "mdadm --wait /dev/md0" mdadm --manage /dev/md0 --fail /dev/sda --remove /dev/sda sleep 1 done ``` Crash stack: ``` stack segment: 0000 [#1] SMP ... ... RIP: 0010:md_check_recovery+0x1e8/0x570 [md_mod] ... ... RSP: 0018:ffffb149807a7d68 EFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9d494c180800 RCX: ffff9d490fc01e50 RDX: fffff047c0ed8308 RSI: 0000000000000246 RDI: 0000000000000246 RBP: 6b6b6b6b6b6b6b6b R08: ffff9d490fc01e40 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: ffff9d494c180818 R14: ffff9d493399ef38 R15: ffff9d4933a1d800 FS: 0000000000000000(0000) GS:ffff9d494f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe68cab9010 CR3: 000000004c6be001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: raid1d+0x5c/0xd40 [raid1] ? finish_task_switch+0x75/0x2a0 ? lock_timer_base+0x67/0x80 ? try_to_del_timer_sync+0x4d/0x80 ? del_timer_sync+0x41/0x50 ? schedule_timeout+0x254/0x2d0 ? md_start_sync+0xe0/0xe0 [md_mod] ? md_thread+0x127/0x160 [md_mod] md_thread+0x127/0x160 [md_mod] ? wait_woken+0x80/0x80 kthread+0x10d/0x130 ? kthread_park+0xa0/0xa0 ret_from_fork+0x1f/0x40 ``` Fixes: dbb64f8635f5d ("md-cluster: Fix adding of new disk with new reload code") Fixes: 659b254fa7392 ("md-cluster: remove a disk asynchronously from cluster environment") Cc: stable@vger.kernel.org Reviewed-by: Gang He Signed-off-by: Heming Zhao Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit a72373588ce34ac897b8c23c1e1c09f0b9af9006 Author: Sudhakar Panneerselvam Date: Tue Apr 13 04:08:29 2021 +0000 md/bitmap: wait for external bitmap writes to complete during tear down commit 404a8ef512587b2460107d3272c17a89aef75edf upstream. NULL pointer dereference was observed in super_written() when it tries to access the mddev structure. [The below stack trace is from an older kernel, but the problem described in this patch applies to the mainline kernel.] [ 1194.474861] task: ffff8fdd20858000 task.stack: ffffb99d40790000 [ 1194.488000] RIP: 0010:super_written+0x29/0xe1 [ 1194.499688] RSP: 0018:ffff8ffb7fcc3c78 EFLAGS: 00010046 [ 1194.512477] RAX: 0000000000000000 RBX: ffff8ffb7bf4a000 RCX: ffff8ffb78991048 [ 1194.527325] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8ffb56b8a200 [ 1194.542576] RBP: ffff8ffb7fcc3c90 R08: 000000000000000b R09: 0000000000000000 [ 1194.558001] R10: ffff8ffb56b8a298 R11: 0000000000000000 R12: ffff8ffb56b8a200 [ 1194.573070] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 1194.588117] FS: 0000000000000000(0000) GS:ffff8ffb7fcc0000(0000) knlGS:0000000000000000 [ 1194.604264] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1194.617375] CR2: 00000000000002b8 CR3: 00000021e040a002 CR4: 00000000007606e0 [ 1194.632327] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1194.647865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1194.663316] PKRU: 55555554 [ 1194.674090] Call Trace: [ 1194.683735] [ 1194.692948] bio_endio+0xae/0x135 [ 1194.703580] blk_update_request+0xad/0x2fa [ 1194.714990] blk_update_bidi_request+0x20/0x72 [ 1194.726578] __blk_end_bidi_request+0x2c/0x4d [ 1194.738373] __blk_end_request_all+0x31/0x49 [ 1194.749344] blk_flush_complete_seq+0x377/0x383 [ 1194.761550] flush_end_io+0x1dd/0x2a7 [ 1194.772910] blk_finish_request+0x9f/0x13c [ 1194.784544] scsi_end_request+0x180/0x25c [ 1194.796149] scsi_io_completion+0xc8/0x610 [ 1194.807503] scsi_finish_command+0xdc/0x125 [ 1194.818897] scsi_softirq_done+0x81/0xde [ 1194.830062] blk_done_softirq+0xa4/0xcc [ 1194.841008] __do_softirq+0xd9/0x29f [ 1194.851257] irq_exit+0xe6/0xeb [ 1194.861290] do_IRQ+0x59/0xe3 [ 1194.871060] common_interrupt+0x1c6/0x382 [ 1194.881988] [ 1194.890646] RIP: 0010:cpuidle_enter_state+0xdd/0x2a5 [ 1194.902532] RSP: 0018:ffffb99d40793e68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff43 [ 1194.917317] RAX: ffff8ffb7fce27c0 RBX: ffff8ffb7fced800 RCX: 000000000000001f [ 1194.932056] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000 [ 1194.946428] RBP: ffffb99d40793ea0 R08: 0000000000000004 R09: 0000000000002ed2 [ 1194.960508] R10: 0000000000002664 R11: 0000000000000018 R12: 0000000000000003 [ 1194.974454] R13: 000000000000000b R14: ffffffff925715a0 R15: 0000011610120d5a [ 1194.988607] ? cpuidle_enter_state+0xcc/0x2a5 [ 1194.999077] cpuidle_enter+0x17/0x19 [ 1195.008395] call_cpuidle+0x23/0x3a [ 1195.017718] do_idle+0x172/0x1d5 [ 1195.026358] cpu_startup_entry+0x73/0x75 [ 1195.035769] start_secondary+0x1b9/0x20b [ 1195.044894] secondary_startup_64+0xa5/0xa5 [ 1195.084921] RIP: super_written+0x29/0xe1 RSP: ffff8ffb7fcc3c78 [ 1195.096354] CR2: 00000000000002b8 bio in the above stack is a bitmap write whose completion is invoked after the tear down sequence sets the mddev structure to NULL in rdev. During tear down, there is an attempt to flush the bitmap writes, but for external bitmaps, there is no explicit wait for all the bitmap writes to complete. For instance, md_bitmap_flush() is called to flush the bitmap writes, but the last call to md_bitmap_daemon_work() in md_bitmap_flush() could generate new bitmap writes for which there is no explicit wait to complete those writes. The call to md_bitmap_update_sb() will return simply for external bitmaps and the follow-up call to md_update_sb() is conditional and may not get called for external bitmaps. This results in a kernel panic when the completion routine, super_written() is called which tries to reference mddev in the rdev that has been set to NULL(in unbind_rdev_from_array() by tear down sequence). The solution is to call md_super_wait() for external bitmaps after the last call to md_bitmap_daemon_work() in md_bitmap_flush() to ensure there are no pending bitmap writes before proceeding with the tear down. Cc: stable@vger.kernel.org Signed-off-by: Sudhakar Panneerselvam Reviewed-by: Zhao Heming Signed-off-by: Song Liu Signed-off-by: Greg Kroah-Hartman commit 45bc83f71b22c2617a190c7d8b02ebd2196b0681 Author: Tetsuo Handa Date: Fri Apr 2 21:17:42 2021 +0900 misc: vmw_vmci: explicitly initialize vmci_datagram payload commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream. KMSAN complains that vmci_check_host_caps() left the payload part of check_msg uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x202/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_guest_probe_device+0xf0b/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Uninit was created at: kmsan_internal_poison_shadow+0x5c/0xf0 kmsan_slab_alloc+0x8d/0xe0 kmem_cache_alloc+0x84f/0xe30 vmci_guest_probe_device+0xd11/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Bytes 28-31 of 36 are uninitialized Memory access of size 36 starts at ffff8881675e5f00 ===================================================== Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.") Cc: Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit 0f8f75b92ecccb256ddf086ee7ffd87d458e8b2e Author: Tetsuo Handa Date: Fri Apr 2 21:17:41 2021 +0900 misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream. KMSAN complains that the vmci_use_ppn64() == false path in vmci_dbell_register_notification_bitmap() left upper 32bits of bitmap_set_msg.bitmap_ppn64 member uninitialized. ===================================================== BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 Call Trace: dump_stack+0x21c/0x280 kmsan_report+0xfb/0x1e0 kmsan_internal_check_memory+0x484/0x520 kmsan_check_memory+0xd/0x10 iowrite8_rep+0x86/0x380 vmci_send_datagram+0x150/0x280 vmci_dbell_register_notification_bitmap+0x133/0x1e0 vmci_guest_probe_device+0xcab/0x1e70 pci_device_probe+0xab3/0xe70 really_probe+0xd16/0x24d0 driver_probe_device+0x29d/0x3a0 device_driver_attach+0x25a/0x490 __driver_attach+0x78c/0x840 bus_for_each_dev+0x210/0x340 driver_attach+0x89/0xb0 bus_add_driver+0x677/0xc40 driver_register+0x485/0x8e0 __pci_register_driver+0x1ff/0x350 vmci_guest_init+0x3e/0x41 vmci_drv_init+0x1d6/0x43f do_one_initcall+0x39c/0x9a0 do_initcall_level+0x1d7/0x259 do_initcalls+0x127/0x1cb do_basic_setup+0x33/0x36 kernel_init_freeable+0x29a/0x3ed kernel_init+0x1f/0x840 ret_from_fork+0x1f/0x30 Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at: vmci_dbell_register_notification_bitmap+0x50/0x1e0 vmci_dbell_register_notification_bitmap+0x50/0x1e0 Bytes 28-31 of 32 are uninitialized Memory access of size 32 starts at ffff88810098f570 ===================================================== Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.") Cc: Signed-off-by: Tetsuo Handa Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit 34f6ba8810c30e3517f6cdc568c7664cc0719729 Author: Hans de Goede Date: Wed Feb 17 11:24:59 2021 +0100 misc: lis3lv02d: Fix false-positive WARN on various HP models commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream. Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch a potential divide by 0. WARN macros should only be used to catch internal kernel bugs and that is not the case here. We have been receiving a lot of bug reports about kernel backtraces caused by this WARN. The div value being checked comes from the lis3->odrs[] array. Which is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. The only lis3 model where this array is not entirely filled with non zero values. IOW the only model where we can hit the div == 0 check is the 3dc ("8 bits 3DC sensor") model: int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; Note the 0 value at index 0, according to the datasheet an odr index of 0 means "Power-down mode". HP typically uses a lis3 accelerometer for HDD fall protection. What I believe is happening here is that on newer HP devices, which only contain a SDD, the BIOS is leaving the lis3 device powered-down since it is not used for HDD fall protection. Note that the lis3_3dc_rates array initializer only specifies 10 values, which matches the datasheet. So it also contains 6 zero values at the end. Replace the WARN with a normal check, which treats an odr index of 0 as power-down and uses a normal dev_err() to report the error in case odr index point past the initialized part of the array. Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") Cc: stable@vger.kernel.org Signed-off-by: Hans de Goede BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 BugLink: https://bugs.centos.org/view.php?id=10720 Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit 8809d87cb86f48381d4edee4bce6c5e099931343 Author: Jonathan Cameron Date: Sun Mar 21 18:29:56 2021 +0000 iio:accel:adis16201: Fix wrong axis assignment that prevents loading commit 4e102429f3dc62dce546f6107e34a4284634196d upstream. Whilst running some basic tests as part of writing up the dt-bindings for this driver (to follow), it became clear it doesn't actually load currently. iio iio:device1: tried to double register : in_incli_x_index adis16201 spi0.0: Failed to create buffer sysfs interfaces adis16201: probe of spi0.0 failed with error -16 Looks like a cut and paste / update bug. Fixes tag obviously not accurate but we don't want to bother carry thing back to before the driver moved out of staging. Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging") Signed-off-by: Jonathan Cameron Cc: Cc: Himanshu Jha Cc: Nuno Sá Reviewed-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7cb1f304237ada6f527986a84accba43ef26fa21 Author: Arun Easi Date: Fri Apr 9 14:51:53 2021 -0700 PCI: Allow VPD access for QLogic ISP2722 commit e00dc69b5f17c444a38cd9745a0f76bc989b3af4 upstream. 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") disabled access to VPD of the ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter because reading past the end of the VPD caused NMIs. 104daa71b396 ("PCI: Determine actual VPD size on first access") limits reads to the actual size of VPD, which should prevent these NMIs. 104daa71b396 was merged *before* 0d5370d1d852, but we think the testing that prompted 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") was done with a kernel that lacked 104daa71b396. See [1, 2]. Remove the quirk added by 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") so customers can read the HBA VPD. [1] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/ [2] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com/ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210409215153.16569-2-aeasi@marvell.com Signed-off-by: Arun Easi Signed-off-by: Bjorn Helgaas Cc: stable@vger.kernel.org # v4.6+ Signed-off-by: Greg Kroah-Hartman commit f30ded0ba1b61ebd9d4e19d6588831f78a90f06a Author: Maciej W. Rozycki Date: Wed Mar 10 13:03:09 2021 +0100 FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR commit f626ca682912fab55dff15469ce893ae16b65c7e upstream. Recent versions of the PCI Express specification have deprecated support for I/O transactions and actually some PCIe host bridges, such as Power Systems Host Bridge 4 (PHB4), do not implement them. For those systems the PCI BARs that request a mapping in the I/O space have the length recorded in the corresponding PCI resource set to zero, which makes it unassigned: # lspci -s 0031:02:04.0 -v 0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] I/O ports at [disabled] Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Kernel driver in use: defxx Kernel modules: defxx # Regardless the driver goes ahead and requests it (here observed with a Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: # cat /proc/ioports 00000000-ffffffffffffffff : 0031:02:04.0 # Furthermore, the system gets confused as the driver actually continues and pokes at those locations, causing a flood of messages being output to the system console by the underlying system firmware, like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others defxx 0031:02:04.0: enabling device (0140 -> 0142) LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 IPMI: dropping non severe PEL event and so on and so on (possibly intermixed actually, as there's no locking between the kernel and the firmware in console port access with this particular system, but cleaned up above for clarity), and once some 10k of such pairs of the latter two messages have been produced an interace eventually shows up in a useless state: 0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 This was not expected to happen as resource handling was added to the driver a while ago, because it was not known at that time that a PCI system would be possible that cannot assign port I/O resources, and oddly enough `request_region' does not fail, which would have caught it. Correct the problem then by checking for the length of zero for the CSR resource and bail out gracefully refusing to register an interface if that turns out to be the case, producing messages like: defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 0031:02:04.0: Cannot use I/O, no address set, aborting 0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" Keep the original check for the EISA MMIO resource as implemented, because in that case the length is hardwired to 0x400 as a consequence of how the compare/mask address decoding works in the ESIC chip and it is only the base address that is set to zero if MMIO has been disabled for the adapter in EISA configuration, which in turn could be a valid bus address in a legacy-free system implementing PCI, especially for port I/O. Where the EISA MMIO resource has been disabled for the adapter in EISA configuration this arrangement keeps producing messages like: eisa 00:05: EISA: slot 5: DEC3002 detected defxx: v1.11 2014/07/01 Lawrence V. Stefani and others 00:05: Cannot use MMIO, no address set, aborting 00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" 00:05: Or run ECU and set adapter's MMIO location with the last two lines now swapped for easier handling in the driver. There is no need to check for and catch the case of a port I/O resource not having been assigned for EISA as the adapter uses the slot-specific I/O space, which gets assigned by how EISA has been specified and maps directly to the particular slot an option card has been placed in. And the EISA variant of the adapter has additional registers that are only accessible via the port I/O space anyway. While at it factor out the error message calls into helpers and fix an argument order bug with the `pr_err' call now in `dfx_register_res_err'. Signed-off-by: Maciej W. Rozycki Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") Cc: stable@vger.kernel.org # v3.19+ Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8943172edaf7e2fbd79b0003bceb417dab3d7ca9 Author: Ilya Lipnitskiy Date: Tue Apr 13 20:12:33 2021 -0700 MIPS: pci-rt2880: fix slot 0 configuration commit 8e98b697006d749d745d3b174168a877bb96c500 upstream. pci_fixup_irqs() used to call pcibios_map_irq on every PCI device, which for RT2880 included bus 0 slot 0. After pci_fixup_irqs() got removed, only slots/funcs with devices attached would be called. While arguably the right thing, that left no chance for this driver to ever initialize slot 0, effectively bricking PCI and USB on RT2880 devices such as the Belkin F5D8235-4 v1. Slot 0 configuration needs to happen after PCI bus enumeration, but before any device at slot 0x11 (func 0 or 1) is talked to. That was determined empirically by testing on a Belkin F5D8235-4 v1 device. A minimal BAR 0 config write followed by read, then setting slot 0 PCI_COMMAND to MASTER | IO | MEMORY is all that seems to be required for proper functionality. Tested by ensuring that full- and high-speed USB devices get enumerated on the Belkin F5D8235-4 v1 (with an out of tree DTS file from OpenWrt). Fixes: 04c81c7293df ("MIPS: PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: Ilya Lipnitskiy Cc: Lorenzo Pieralisi Cc: Tobias Wolf Cc: # v4.14+ Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit cd2e53ad366ffe60c4d777c739fe3aa2dccf1dac Author: Ilya Lipnitskiy Date: Sat Mar 6 20:17:24 2021 -0800 MIPS: pci-mt7620: fix PLL lock check commit c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 upstream. Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL lock check. The existing code checks the wrong register bit: PPLL_SW_SET is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved in the MT7620 Programming Guide. The correct bit to check for PLL lock is PPLL_LD (bit 23). Also reword the error message for clarity. Without this change it is unlikely that this driver ever worked with mainline kernel. [0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.html Signed-off-by: Ilya Lipnitskiy Cc: John Crispin Cc: linux-mips@vger.kernel.org Cc: linux-mediatek@lists.infradead.org Cc: linux-kernel@vger.kernel.org Cc: stable@vger.kernel.org Signed-off-by: Thomas Bogendoerfer Signed-off-by: Greg Kroah-Hartman commit 4dce2a19e76b1754feca17d977764913018b4d4d Author: Lukasz Majczak Date: Thu Apr 15 14:43:47 2021 +0200 ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function commit a523ef731ac6674dc07574f31bf44cc5bfa14e4d upstream. kabylake_ssp_fixup function uses snd_soc_dpcm to identify the codecs DAIs. The HW parameters are changed based on the codec DAI of the stream. The earlier approach to get snd_soc_dpcm was using container_of() macro on snd_pcm_hw_params. The structures have been modified over time and snd_soc_dpcm does not have snd_pcm_hw_params as a reference but as a copy. This causes the current driver to crash when used. This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime holds 2 dpcm instances (one for playback and one for capture). 2 codecs on the SSP are dmic (capture) and speakers (playback). Based on the stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime. Tested for all use cases of the driver. Based on similar fix in kbl_rt5663_rt5514_max98927.c from Harsha Priya and Vamshi Krishna Gopal Cc: # 5.4+ Signed-off-by: Lukasz Majczak Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 79cc386696fbdfcb2b85018dbfe8133afc3d8e93 Author: Pierre-Louis Bossart Date: Fri Mar 12 12:02:30 2021 -0600 ASoC: samsung: tm2_wm5110: check of of_parse return value commit d58970da324732686529655c21791cef0ee547c4 upstream. cppcheck warning: sound/soc/samsung/tm2_wm5110.c:605:6: style: Variable 'ret' is reassigned a value before the old one has been used. [redundantAssignment] ret = devm_snd_soc_register_component(dev, &tm2_component, ^ sound/soc/samsung/tm2_wm5110.c:554:7: note: ret is assigned ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", ^ sound/soc/samsung/tm2_wm5110.c:605:6: note: ret is overwritten ret = devm_snd_soc_register_component(dev, &tm2_component, ^ The args is a stack variable, so it could have junk (uninitialized) therefore args.np could have a non-NULL and random value even though property was missing. Later could trigger invalid pointer dereference. There's no need to check for args.np because args.np won't be initialized on errors. Fixes: 8d1513cef51a ("ASoC: samsung: Add support for HDMI audio on TM2 board") Cc: Suggested-by: Krzysztof Kozlowski Reviewed-by: Krzysztof Kozlowski Reviewed-by: Sylwester Nawrocki Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20210312180231.2741-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 2b8b8cc94f4d4a7bb370e77fb910fd18bd42d795 Author: Chunfeng Yun Date: Mon Mar 8 10:51:51 2021 +0800 usb: xhci-mtk: improve bandwidth scheduling with TT commit e19ee44a3d07c232f9241024dab1ebd0748cdf5f upstream. When the USB headset is plug into an external hub, sometimes can't set config due to not enough bandwidth, so need improve LS/FS INT/ISOC bandwidth scheduling with TT. Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") Cc: stable Signed-off-by: Yaqii Wu Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 9f0d3e676a253db02a916e5b1e4e49b32b4026f3 Author: Chunfeng Yun Date: Mon Mar 8 10:51:50 2021 +0800 usb: xhci-mtk: remove or operator for setting schedule parameters commit 5fa5827566e3affa1657ccf9b22706c06a5d021a upstream. Side effect may happen if use or operator to set schedule parameters when the parameters are already set before. Set them directly due to other bits are reserved. Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") Cc: stable Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 230bd196536bdb18cf825479e2deb487a58f36a5 Author: Badhri Jagan Sridharan Date: Wed Apr 7 13:07:20 2021 -0700 usb: typec: tcpm: update power supply once partner accepts commit 4050f2683f2c3151dc3dd1501ac88c57caf810ff upstream. power_supply_changed needs to be called to notify clients after the partner accepts the requested values for the pps case. Also, remove the redundant power_supply_changed at the end of the tcpm_reset_port as power_supply_changed is already called right after usb_type is changed. Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Adam Thomson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210407200723.1914388-3-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 9d7bb10859b9f7bd72c987369e005e633fe86c12 Author: Badhri Jagan Sridharan Date: Wed Apr 7 13:07:19 2021 -0700 usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply commit e3a0720224873587954b55d193d5b4abb14f0443 upstream. tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt, port->pps_data.max_volt, port->pps_data.max_curr even before port partner accepts the requests. This leaves incorrect values in current_limit and supply_voltage that get exported by "tcpm-source-psy-". Solving this problem by caching the request values in req_min_volt, req_max_volt, req_max_curr, req_out_volt, req_op_curr. min_volt, max_volt, max_curr gets updated once the partner accepts the request. current_limit, supply_voltage gets updated once local port's tcpm enters SNK_TRANSITION_SINK when the accepted current_limit and supply_voltage is enforced. Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Adam Thomson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit c87bb48ac5c5942e594c285218cf0af4065d71ec Author: Badhri Jagan Sridharan Date: Wed Apr 7 13:07:18 2021 -0700 usb: typec: tcpm: Address incorrect values of tcpm psy for fixed supply commit f3dedafb8263ca4791a92a23f5230068f5bde008 upstream. tcpm_pd_build_request overwrites current_limit and supply_voltage even before port partner accepts the requests. This leaves stale values in current_limit and supply_voltage that get exported by "tcpm-source-psy-". Solving this problem by caching the request values of current limit/supply voltage in req_current_limit and req_supply_voltage. current_limit/supply_voltage gets updated once the port partner accepts the request. Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") Signed-off-by: Badhri Jagan Sridharan Cc: stable Reviewed-by: Guenter Roeck Reviewed-by: Adam Thomson Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20210407200723.1914388-1-badhri@google.com Signed-off-by: Greg Kroah-Hartman commit 66ca71d28301944069657bf616d60c00f1079960 Author: Johan Hovold Date: Wed Apr 7 12:23:20 2021 +0200 staging: fwserial: fix TIOCSSERIAL permission check commit 2104eb283df66a482b60254299acbe3c68c03412 upstream. Changing the port close-delay parameter is a privileged operation so make sure to return -EPERM if a regular user tries to change it. Fixes: 7355ba3445f2 ("staging: fwserial: Add TTY-over-Firewire serial driver") Cc: stable@vger.kernel.org # 3.8 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit ebb46274e33fa583447f3b9cbcba6f46397042de Author: Johan Hovold Date: Wed Apr 7 12:23:29 2021 +0200 tty: moxa: fix TIOCSSERIAL permission check commit dc8c8437658667be9b11ec25c4b5482ed2becdaa upstream. Changing the port close delay or type are privileged operations so make sure to return -EPERM if a regular user tries to change them. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-12-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit d524fb44c657410535bbc8da17e5adae973c423f Author: Johan Hovold Date: Wed Apr 7 12:23:19 2021 +0200 staging: fwserial: fix TIOCSSERIAL jiffies conversions commit 7a3791afdbd5a951b09a7689bba856bd9f6c6a9f upstream. The port close_delay parameter set by TIOCSSERIAL is specified in jiffies, while the value returned by TIOCGSERIAL is specified in centiseconds. Add the missing conversions so that TIOCGSERIAL works as expected also when HZ is not 100. Fixes: 7355ba3445f2 ("staging: fwserial: Add TTY-over-Firewire serial driver") Cc: stable@vger.kernel.org # 3.8 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit f80f12ee00b8bdef7216bd5db7f46ec7902b2323 Author: Johan Hovold Date: Wed Apr 7 12:39:15 2021 +0200 USB: serial: ti_usb_3410_5052: fix TIOCSSERIAL permission check commit d370c90dcd64e427a79a093a070117a1571d4cd8 upstream. Changing the port closing-wait parameter is a privileged operation so make sure to return -EPERM if a regular user tries to change it. Cc: stable@vger.kernel.org Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit f50cad556c28ea536782e66c3fd6cc93e9958bb3 Author: Johan Hovold Date: Wed Apr 7 12:23:23 2021 +0200 staging: greybus: uart: fix TIOCSSERIAL jiffies conversions commit b71e571adaa58be4fd289abebc8997e05b4c6b40 upstream. The port close_delay and closing_wait parameters set by TIOCSSERIAL are specified in jiffies and not milliseconds. Add the missing conversions so that TIOCSSERIAL works as expected also when HZ is not 1000. Fixes: e68453ed28c5 ("greybus: uart-gb: now builds, more framework added") Cc: stable@vger.kernel.org # 4.9 Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-6-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 3114fedf402035f65adf26625eab0e85640531e6 Author: Johan Hovold Date: Wed Apr 7 12:39:16 2021 +0200 USB: serial: usb_wwan: fix TIOCSSERIAL jiffies conversions commit 3d732690d2267f4d0e19077b178dffbedafdf0c9 upstream. The port close_delay and closing_wait parameters set by TIOCSSERIAL are specified in jiffies and not milliseconds. Add the missing conversions so that the TIOCSSERIAL works as expected also when HZ is not 1000. Fixes: 02303f73373a ("usb-wwan: implement TIOCGSERIAL and TIOCSSERIAL to avoid blocking close(2)") Cc: stable@vger.kernel.org # 2.6.38 Reviewed-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit edce324120965a5bd3e55323fba96140a50c9f55 Author: Johan Hovold Date: Wed Apr 7 12:23:26 2021 +0200 tty: amiserial: fix TIOCSSERIAL permission check commit 1d31a831cc04f5f942de3e7d91edaa52310d3c99 upstream. Changing the port closing_wait parameter is a privileged operation. Add the missing check to TIOCSSERIAL so that -EPERM is returned in case an unprivileged user tries to change the closing-wait setting. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-9-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit e503d7bc7bfeb4d807caba7035e127393ee7e8d4 Author: Johan Hovold Date: Wed Apr 7 12:23:28 2021 +0200 tty: moxa: fix TIOCSSERIAL jiffies conversions commit 6e70b73ca5240c0059a1fbf8ccd4276d6cf71956 upstream. The port close_delay parameter set by TIOCSSERIAL is specified in jiffies, while the value returned by TIOCGSERIAL is specified in centiseconds. Add the missing conversions so that TIOCGSERIAL works as expected also when HZ is not 100. Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210407102334.32361-11-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit c30b11c74cbbf2b57f95d899b73c1c90dd443230 Author: Johan Hovold Date: Thu Apr 8 15:16:00 2021 +0200 Revert "USB: cdc-acm: fix rounding error in TIOCSSERIAL" commit 729f7955cb987c5b7d7e54c87c5ad71c789934f7 upstream. This reverts commit b401f8c4f492cbf74f3f59c9141e5be3071071bb. The offending commit claimed that trying to set the values reported back by TIOCGSERIAL as a regular user could result in an -EPERM error when HZ is 250, but that was never the case. With HZ=250, the default 0.5 second value of close_delay is converted to 125 jiffies when set and is converted back to 50 centiseconds by TIOCGSERIAL as expected (not 12 cs as was claimed, even if that was the case before an earlier fix). Comparing the internal current and new jiffies values is just fine to determine if the value is about to change so drop the bogus workaround (which was also backported to stable). For completeness: With different default values for these parameters or with a HZ value not divisible by two, the lack of rounding when setting the default values in tty_port_init() could result in an -EPERM being returned, but this is hardly something we need to worry about. Cc: Anthony Mallet Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Signed-off-by: Johan Hovold Link: https://lore.kernel.org/r/20210408131602.27956-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit e32352070bcac22be6ed8ab635debc280bb65b8c Author: Or Cohen Date: Tue May 4 10:16:46 2021 +0300 net/nfc: fix use-after-free llcp_sock_bind/connect commit c61760e6940dd4039a7f5e84a6afc9cdbf4d82b6 upstream. Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. Reported-by: Or Cohen Reported-by: Nadav Markus Fixes: c33b1cc62 ("nfc: fix refcount leak in llcp_sock_bind()") Signed-off-by: Or Cohen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eeec325c9944b4427f482018d00b737220c31fd9 Author: Lin Ma Date: Mon Apr 12 19:17:57 2021 +0800 bluetooth: eliminate the potential race condition when removing the HCI controller commit e2cb6b891ad2b8caa9131e3be70f45243df82a80 upstream. There is a possible race condition vulnerability between issuing a HCI command and removing the cont. Specifically, functions hci_req_sync() and hci_dev_do_close() can race each other like below: thread-A in hci_req_sync() | thread-B in hci_dev_do_close() | hci_req_sync_lock(hdev); test_bit(HCI_UP, &hdev->flags); | ... | test_and_clear_bit(HCI_UP, &hdev->flags) hci_req_sync_lock(hdev); | | In this commit we alter the sequence in function hci_req_sync(). Hence, the thread-A cannot issue th. Signed-off-by: Lin Ma Cc: Marcel Holtmann Fixes: 7c6a329e4447 ("[Bluetooth] Fix regression from using default link policy") Signed-off-by: Greg Kroah-Hartman commit 119858caf4004bc189fd5c7a336d5ba426832f7b Author: Taehee Yoo Date: Fri Feb 28 18:01:46 2020 +0000 hsr: use netdev_err() instead of WARN_ONCE() commit 4b793acdca0050739b99ace6a8b9e7f717f57c6b upstream. When HSR interface is sending a frame, it finds a node with the destination ethernet address from the list. If there is no node, it calls WARN_ONCE(). But, using WARN_ONCE() for this situation is a little bit overdoing. So, in this patch, the netdev_err() is used instead. Signed-off-by: Taehee Yoo Signed-off-by: David S. Miller Cc: George Kennedy Signed-off-by: Greg Kroah-Hartman commit 3a826ffa80d5c73ad7338fd98ace9c5b53844968 Author: Archie Pusaka Date: Mon Mar 22 14:03:11 2021 +0800 Bluetooth: verify AMP hci_chan before amp_destroy commit 5c4c8c9544099bb9043a10a5318130a943e32fc3 upstream. hci_chan can be created in 2 places: hci_loglink_complete_evt() if it is an AMP hci_chan, or l2cap_conn_add() otherwise. In theory, Only AMP hci_chan should be removed by a call to hci_disconn_loglink_complete_evt(). However, the controller might mess up, call that function, and destroy an hci_chan which is not initiated by hci_loglink_complete_evt(). This patch adds a verification that the destroyed hci_chan must have been init'd by hci_loglink_complete_evt(). Example crash call trace: Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0xe3/0x144 lib/dump_stack.c:118 print_address_description+0x67/0x22a mm/kasan/report.c:256 kasan_report_error mm/kasan/report.c:354 [inline] kasan_report mm/kasan/report.c:412 [inline] kasan_report+0x251/0x28f mm/kasan/report.c:396 hci_send_acl+0x3b/0x56e net/bluetooth/hci_core.c:4072 l2cap_send_cmd+0x5af/0x5c2 net/bluetooth/l2cap_core.c:877 l2cap_send_move_chan_cfm_icid+0x8e/0xb1 net/bluetooth/l2cap_core.c:4661 l2cap_move_fail net/bluetooth/l2cap_core.c:5146 [inline] l2cap_move_channel_rsp net/bluetooth/l2cap_core.c:5185 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:5464 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5799 [inline] l2cap_recv_frame+0x1d12/0x51aa net/bluetooth/l2cap_core.c:7023 l2cap_recv_acldata+0x2ea/0x693 net/bluetooth/l2cap_core.c:7596 hci_acldata_packet net/bluetooth/hci_core.c:4606 [inline] hci_rx_work+0x2bd/0x45e net/bluetooth/hci_core.c:4796 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Allocated by task 38: set_track mm/kasan/kasan.c:460 [inline] kasan_kmalloc+0x8d/0x9a mm/kasan/kasan.c:553 kmem_cache_alloc_trace+0x102/0x129 mm/slub.c:2787 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] hci_chan_create+0x86/0x26d net/bluetooth/hci_conn.c:1674 l2cap_conn_add.part.0+0x1c/0x814 net/bluetooth/l2cap_core.c:7062 l2cap_conn_add net/bluetooth/l2cap_core.c:7059 [inline] l2cap_connect_cfm+0x134/0x852 net/bluetooth/l2cap_core.c:7381 hci_connect_cfm+0x9d/0x122 include/net/bluetooth/hci_core.h:1404 hci_remote_ext_features_evt net/bluetooth/hci_event.c:4161 [inline] hci_event_packet+0x463f/0x72fa net/bluetooth/hci_event.c:5981 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 Freed by task 1732: set_track mm/kasan/kasan.c:460 [inline] __kasan_slab_free mm/kasan/kasan.c:521 [inline] __kasan_slab_free+0x106/0x128 mm/kasan/kasan.c:493 slab_free_hook mm/slub.c:1409 [inline] slab_free_freelist_hook+0xaa/0xf6 mm/slub.c:1436 slab_free mm/slub.c:3009 [inline] kfree+0x182/0x21e mm/slub.c:3972 hci_disconn_loglink_complete_evt net/bluetooth/hci_event.c:4891 [inline] hci_event_packet+0x6a1c/0x72fa net/bluetooth/hci_event.c:6050 hci_rx_work+0x197/0x45e net/bluetooth/hci_core.c:4791 process_one_work+0x6f8/0xb50 kernel/workqueue.c:2175 worker_thread+0x4fc/0x670 kernel/workqueue.c:2321 kthread+0x2f0/0x304 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:415 The buggy address belongs to the object at ffff8881d7af9180 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 24 bytes inside of 128-byte region [ffff8881d7af9180, ffff8881d7af9200) The buggy address belongs to the page: page:ffffea00075ebe40 count:1 mapcount:0 mapping:ffff8881da403200 index:0x0 flags: 0x8000000000000200(slab) raw: 8000000000000200 dead000000000100 dead000000000200 ffff8881da403200 raw: 0000000000000000 0000000080150015 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881d7af9080: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ffff8881d7af9100: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc >ffff8881d7af9180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881d7af9200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881d7af9280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Signed-off-by: Archie Pusaka Reported-by: syzbot+98228e7407314d2d4ba2@syzkaller.appspotmail.com Reviewed-by: Alain Michaud Reviewed-by: Abhishek Pandit-Subedi Signed-off-by: Marcel Holtmann Cc: George Kennedy Signed-off-by: Greg Kroah-Hartman