commit 131f8d8a889a5ca66a835eea82bba043ac91a7cf Author: Greg Kroah-Hartman Date: Wed Jan 27 11:47:55 2021 +0100 Linux 5.4.93 Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210126111748.320806573@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit f7020c437e138507d50c3f167342870f24d2432f Author: Enke Chen Date: Fri Jan 15 14:30:58 2021 -0800 tcp: fix TCP_USER_TIMEOUT with zero window commit 9d9b1ee0b2d1c9e02b2338c4a4b0a062d2d3edac upstream. The TCP session does not terminate with TCP_USER_TIMEOUT when data remain untransmitted due to zero window. The number of unanswered zero-window probes (tcp_probes_out) is reset to zero with incoming acks irrespective of the window size, as described in tcp_probe_timer(): RFC 1122 4.2.2.17 requires the sender to stay open indefinitely as long as the receiver continues to respond probes. We support this by default and reset icsk_probes_out with incoming ACKs. This counter, however, is the wrong one to be used in calculating the duration that the window remains closed and data remain untransmitted. Thanks to Jonathan Maxwell for diagnosing the actual issue. In this patch a new timestamp is introduced for the socket in order to track the elapsed time for the zero-window probes that have not been answered with any non-zero window ack. Fixes: 9721e709fa68 ("tcp: simplify window probe aborting on USER_TIMEOUT") Reported-by: William McCall Co-developed-by: Neal Cardwell Signed-off-by: Neal Cardwell Signed-off-by: Enke Chen Reviewed-by: Yuchung Cheng Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/r/20210115223058.GA39267@localhost.localdomain Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 945d182a046f66cfebf09cdcbfc537cbfbacd1cd Author: Eric Dumazet Date: Tue Jan 19 08:49:00 2021 -0800 tcp: do not mess with cloned skbs in tcp_add_backlog() commit b160c28548bc0a87cbd16d5af6d3edcfd70b8c9a upstream. Heiner Kallweit reported that some skbs were sent with the following invalid GSO properties : - gso_size > 0 - gso_type == 0 This was triggerring a WARN_ON_ONCE() in rtl8169_tso_csum_v2. Juerg Haefliger was able to reproduce a similar issue using a lan78xx NIC and a workload mixing TCP incoming traffic and forwarded packets. The problem is that tcp_add_backlog() is writing over gso_segs and gso_size even if the incoming packet will not be coalesced to the backlog tail packet. While skb_try_coalesce() would bail out if tail packet is cloned, this overwriting would lead to corruptions of other packets cooked by lan78xx, sharing a common super-packet. The strategy used by lan78xx is to use a big skb, and split it into all received packets using skb_clone() to avoid copies. The drawback of this strategy is that all the small skb share a common struct skb_shared_info. This patch rewrites TCP gso_size/gso_segs handling to only happen on the tail skb, since skb_try_coalesce() made sure it was not cloned. Fixes: 4f693b55c3d2 ("tcp: implement coalescing on backlog queue") Signed-off-by: Eric Dumazet Bisected-by: Juerg Haefliger Tested-by: Juerg Haefliger Reported-by: Heiner Kallweit Link: https://bugzilla.kernel.org/show_bug.cgi?id=209423 Link: https://lore.kernel.org/r/20210119164900.766957-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ccc248b6444aa4867c85ba1de9d0c907855e414c Author: Dan Carpenter Date: Tue Jan 19 17:48:03 2021 +0300 net: dsa: b53: fix an off by one in checking "vlan->vid" commit 8e4052c32d6b4b39c1e13c652c7e33748d447409 upstream. The > comparison should be >= to prevent accessing one element beyond the end of the dev->vlans[] array in the caller function, b53_vlan_add(). The "dev->vlans" array is allocated in the b53_switch_init() function and it has "dev->num_vlans" elements. Fixes: a2482d2ce349 ("net: dsa: b53: Plug in VLAN support") Signed-off-by: Dan Carpenter Acked-by: Florian Fainelli Link: https://lore.kernel.org/r/YAbxI97Dl/pmBy5V@mwanda Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ff64094dc71823938acb595cab27a4b07d6a6cd1 Author: Tariq Toukan Date: Sun Jan 17 17:15:38 2021 +0200 net: Disable NETIF_F_HW_TLS_RX when RXCSUM is disabled commit a3eb4e9d4c9218476d05c52dfd2be3d6fdce6b91 upstream. With NETIF_F_HW_TLS_RX packets are decrypted in HW. This cannot be logically done when RXCSUM offload is off. Fixes: 14136564c8ee ("net: Add TLS RX offload feature") Signed-off-by: Tariq Toukan Reviewed-by: Boris Pismenny Link: https://lore.kernel.org/r/20210117151538.9411-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3e5b335a55e95b9203cfb0f58ce36fdfa449f818 Author: Vladimir Oltean Date: Mon Jan 18 15:52:10 2021 +0200 net: mscc: ocelot: allow offloading of bridge on top of LAG commit 79267ae22615496655feee2db0848f6786bcf67a upstream. The blamed commit was too aggressive, and it made ocelot_netdevice_event react only to network interface events emitted for the ocelot switch ports. In fact, only the PRECHANGEUPPER should have had that check. When we ignore all events that are not for us, we miss the fact that the upper of the LAG changes, and the bonding interface gets enslaved to a bridge. This is an operation we could offload under certain conditions. Fixes: 7afb3e575e5a ("net: mscc: ocelot: don't handle netdev events for other netdevs") Signed-off-by: Vladimir Oltean Reviewed-by: Alexandre Belloni Link: https://lore.kernel.org/r/20210118135210.2666246-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b47a3c32c4c24df681d6e106d9fb4b3cc46dbefa Author: Matteo Croce Date: Fri Jan 15 19:42:09 2021 +0100 ipv6: set multicast flag on the multicast route commit ceed9038b2783d14e0422bdc6fd04f70580efb4c upstream. The multicast route ff00::/8 is created with type RTN_UNICAST: $ ip -6 -d route unicast ::1 dev lo proto kernel scope global metric 256 pref medium unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium unicast ff00::/8 dev eth0 proto kernel scope global metric 256 pref medium Set the type to RTN_MULTICAST which is more appropriate. Fixes: e8478e80e5a7 ("net/ipv6: Save route type in rt6_info") Signed-off-by: Matteo Croce Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b778940f2ab98852ce3d2cabbb3c9197420879c8 Author: Eric Dumazet Date: Thu Jan 14 08:06:37 2021 -0800 net_sched: reject silly cell_log in qdisc_get_rtab() commit e4bedf48aaa5552bc1f49703abd17606e7e6e82a upstream. iproute2 probably never goes beyond 8 for the cell exponent, but stick to the max shift exponent for signed 32bit. UBSAN reported: UBSAN: shift-out-of-bounds in net/sched/sch_api.c:389:22 shift exponent 130 is too large for 32-bit type 'int' CPU: 1 PID: 8450 Comm: syz-executor586 Not tainted 5.11.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x183/0x22e lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:148 [inline] __ubsan_handle_shift_out_of_bounds+0x432/0x4d0 lib/ubsan.c:395 __detect_linklayer+0x2a9/0x330 net/sched/sch_api.c:389 qdisc_get_rtab+0x2b5/0x410 net/sched/sch_api.c:435 cbq_init+0x28f/0x12c0 net/sched/sch_cbq.c:1180 qdisc_create+0x801/0x1470 net/sched/sch_api.c:1246 tc_modify_qdisc+0x9e3/0x1fc0 net/sched/sch_api.c:1662 rtnetlink_rcv_msg+0xb1d/0xe60 net/core/rtnetlink.c:5564 netlink_rcv_skb+0x1f0/0x460 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x7de/0x9b0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0xaa6/0xe90 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg net/socket.c:672 [inline] ____sys_sendmsg+0x5a2/0x900 net/socket.c:2345 ___sys_sendmsg net/socket.c:2399 [inline] __sys_sendmsg+0x319/0x400 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Acked-by: Cong Wang Link: https://lore.kernel.org/r/20210114160637.1660597-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4ed347901f08cab438fb0501ffa520a7b80cdf70 Author: Eric Dumazet Date: Thu Jan 14 10:52:29 2021 -0800 net_sched: avoid shift-out-of-bounds in tcindex_set_parms() commit bcd0cf19ef8258ac31b9a20248b05c15a1f4b4b0 upstream. tc_index being 16bit wide, we need to check that TCA_TCINDEX_SHIFT attribute is not silly. UBSAN: shift-out-of-bounds in net/sched/cls_tcindex.c:260:29 shift exponent 255 is too large for 32-bit type 'int' CPU: 0 PID: 8516 Comm: syz-executor228 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 valid_perfect_hash net/sched/cls_tcindex.c:260 [inline] tcindex_set_parms.cold+0x1b/0x215 net/sched/cls_tcindex.c:425 tcindex_change+0x232/0x340 net/sched/cls_tcindex.c:546 tc_new_tfilter+0x13fb/0x21b0 net/sched/cls_api.c:2127 rtnetlink_rcv_msg+0x8b6/0xb80 net/core/rtnetlink.c:5555 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2336 ___sys_sendmsg+0xf3/0x170 net/socket.c:2390 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2423 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Link: https://lore.kernel.org/r/20210114185229.1742255-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bc757ba6dc75e80b5307bef0f1a42c13a0a43b88 Author: Matteo Croce Date: Fri Jan 15 19:42:08 2021 +0100 ipv6: create multicast route with RTPROT_KERNEL commit a826b04303a40d52439aa141035fca5654ccaccd upstream. The ff00::/8 multicast route is created without specifying the fc_protocol field, so the default RTPROT_BOOT value is used: $ ip -6 -d route unicast ::1 dev lo proto kernel scope global metric 256 pref medium unicast fe80::/64 dev eth0 proto kernel scope global metric 256 pref medium unicast ff00::/8 dev eth0 proto boot scope global metric 256 pref medium As the documentation says, this value identifies routes installed during boot, but the route is created when interface is set up. Change the value to RTPROT_KERNEL which is a better value. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Matteo Croce Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 60fb547a3d5d676c6631be81746617ab0756b0e4 Author: Guillaume Nault Date: Sat Jan 16 11:44:22 2021 +0100 udp: mask TOS bits in udp_v4_early_demux() commit 8d2b51b008c25240914984208b2ced57d1dd25a5 upstream. udp_v4_early_demux() is the only function that calls ip_mc_validate_source() with a TOS that hasn't been masked with IPTOS_RT_MASK. This results in different behaviours for incoming multicast UDPv4 packets, depending on if ip_mc_validate_source() is called from the early-demux path (udp_v4_early_demux) or from the regular input path (ip_route_input_noref). ECN would normally not be used with UDP multicast packets, so the practical consequences should be limited on that side. However, IPTOS_RT_MASK is used to also masks the TOS' high order bits, to align with the non-early-demux path behaviour. Reproducer: Setup two netns, connected with veth: $ ip netns add ns0 $ ip netns add ns1 $ ip -netns ns0 link set dev lo up $ ip -netns ns1 link set dev lo up $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10 peer 192.0.2.11/32 dev veth01 $ ip -netns ns1 address add 192.0.2.11 peer 192.0.2.10/32 dev veth10 In ns0, add route to multicast address 224.0.2.0/24 using source address 198.51.100.10: $ ip -netns ns0 address add 198.51.100.10/32 dev lo $ ip -netns ns0 route add 224.0.2.0/24 dev veth01 src 198.51.100.10 In ns1, define route to 198.51.100.10, only for packets with TOS 4: $ ip -netns ns1 route add 198.51.100.10/32 tos 4 dev veth10 Also activate rp_filter in ns1, so that incoming packets not matching the above route get dropped: $ ip netns exec ns1 sysctl -wq net.ipv4.conf.veth10.rp_filter=1 Now try to receive packets on 224.0.2.11: $ ip netns exec ns1 socat UDP-RECVFROM:1111,ip-add-membership=224.0.2.11:veth10,ignoreeof - In ns0, send packet to 224.0.2.11 with TOS 4 and ECT(0) (that is, tos 6 for socat): $ echo test0 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6 The "test0" message is properly received by socat in ns1, because early-demux has no cached dst to use, so source address validation is done by ip_route_input_mc(), which receives a TOS that has the ECN bits masked. Now send another packet to 224.0.2.11, still with TOS 4 and ECT(0): $ echo test1 | ip netns exec ns0 socat - UDP-DATAGRAM:224.0.2.11:1111,bind=:1111,tos=6 The "test1" message isn't received by socat in ns1, because, now, early-demux has a cached dst to use and calls ip_mc_validate_source() immediately, without masking the ECN bits. Fixes: bc044e8db796 ("udp: perform source validation for mcast early demux") Signed-off-by: Guillaume Nault Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit da3711f42c68326faf20ce3ce07c4c4709fa530a Author: Lecopzer Chen Date: Sat Jan 23 21:01:29 2021 -0800 kasan: fix incorrect arguments passing in kasan_add_zero_shadow commit 5dabd1712cd056814f9ab15f1d68157ceb04e741 upstream. kasan_remove_zero_shadow() shall use original virtual address, start and size, instead of shadow address. Link: https://lkml.kernel.org/r/20210103063847.5963-1-lecopzer@gmail.com Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by: Lecopzer Chen Reviewed-by: Andrey Konovalov Cc: Andrey Ryabinin Cc: Dan Williams Cc: Dmitry Vyukov Cc: Alexander Potapenko Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0d190f53fa2f37d46f840e95c0c6ac44003259de Author: Lecopzer Chen Date: Sat Jan 23 21:01:25 2021 -0800 kasan: fix unaligned address is unhandled in kasan_remove_zero_shadow commit a11a496ee6e2ab6ed850233c96b94caf042af0b9 upstream. During testing kasan_populate_early_shadow and kasan_remove_zero_shadow, if the shadow start and end address in kasan_remove_zero_shadow() is not aligned to PMD_SIZE, the remain unaligned PTE won't be removed. In the test case for kasan_remove_zero_shadow(): shadow_start: 0xffffffb802000000, shadow end: 0xffffffbfbe000000 3-level page table: PUD_SIZE: 0x40000000 PMD_SIZE: 0x200000 PAGE_SIZE: 4K 0xffffffbf80000000 ~ 0xffffffbfbdf80000 will not be removed because in kasan_remove_pud_table(), kasan_pmd_table(*pud) is true but the next address is 0xffffffbfbdf80000 which is not aligned to PUD_SIZE. In the correct condition, this should fallback to the next level kasan_remove_pmd_table() but the condition flow always continue to skip the unaligned part. Fix by correcting the condition when next and addr are neither aligned. Link: https://lkml.kernel.org/r/20210103135621.83129-1-lecopzer@gmail.com Fixes: 0207df4fa1a86 ("kernel/memremap, kasan: make ZONE_DEVICE with work with KASAN") Signed-off-by: Lecopzer Chen Cc: Andrey Ryabinin Cc: Dan Williams Cc: Dmitry Vyukov Cc: Alexander Potapenko Cc: YJ Chiang Cc: Andrey Konovalov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5a3890bad3a4e10af5a2076eca23f848f89445ce Author: Alexander Lobakin Date: Fri Jan 15 15:04:40 2021 +0000 skbuff: back tiny skbs with kmalloc() in __netdev_alloc_skb() too commit 66c556025d687dbdd0f748c5e1df89c977b6c02a upstream. Commit 3226b158e67c ("net: avoid 32 x truesize under-estimation for tiny skbs") ensured that skbs with data size lower than 1025 bytes will be kmalloc'ed to avoid excessive page cache fragmentation and memory consumption. However, the fix adressed only __napi_alloc_skb() (primarily for virtio_net and napi_get_frags()), but the issue can still be achieved through __netdev_alloc_skb(), which is still used by several drivers. Drivers often allocate a tiny skb for headers and place the rest of the frame to frags (so-called copybreak). Mirror the condition to __netdev_alloc_skb() to handle this case too. Since v1 [0]: - fix "Fixes:" tag; - refine commit message (mention copybreak usecase). [0] https://lore.kernel.org/netdev/20210114235423.232737-1-alobakin@pm.me Fixes: a1c7fff7e18f ("net: netdev_alloc_skb() use build_skb()") Signed-off-by: Alexander Lobakin Link: https://lore.kernel.org/r/20210115150354.85967-1-alobakin@pm.me Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 49aaf012c4785f8f33ab0ca7dcf2560915d0f5ca Author: Pan Bian Date: Wed Jan 20 23:22:02 2021 -0800 lightnvm: fix memory leak when submit fails commit 97784481757fba7570121a70dd37ca74a29f50a8 upstream. The allocated page is not released if error occurs in nvm_submit_io_sync_raw(). __free_page() is moved ealier to avoid possible memory leak issue. Fixes: aff3fb18f957 ("lightnvm: move bad block and chunk state logic to core") Signed-off-by: Pan Bian Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0ff55fc4d6a1155607c3da8fb36eadb3a93fdb3c Author: Geert Uytterhoeven Date: Mon Jan 18 16:08:12 2021 +0100 sh_eth: Fix power down vs. is_opened flag ordering commit f6a2e94b3f9d89cb40771ff746b16b5687650cbb upstream. sh_eth_close() does a synchronous power down of the device before marking it closed. Revert the order, to make sure the device is never marked opened while suspended. While at it, use pm_runtime_put() instead of pm_runtime_put_sync(), as there is no reason to do a synchronous power down. Fixes: 7fa2955ff70ce453 ("sh_eth: Fix sleeping function called from invalid context") Signed-off-by: Geert Uytterhoeven Reviewed-by: Sergei Shtylyov Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/20210118150812.796791-1-geert+renesas@glider.be Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fd2f5130ae987dfda9e77ecc25666e7b913bde9c Author: Rasmus Villemoes Date: Sat Jan 16 03:39:35 2021 +0100 net: dsa: mv88e6xxx: also read STU state in mv88e6250_g1_vtu_getnext commit 87fe04367d842c4d97a77303242d4dd4ac351e46 upstream. mv88e6xxx_port_vlan_join checks whether the VTU already contains an entry for the given vid (via mv88e6xxx_vtu_getnext), and if so, merely changes the relevant .member[] element and loads the updated entry into the VTU. However, at least for the mv88e6250, the on-stack struct mv88e6xxx_vtu_entry vlan never has its .state[] array explicitly initialized, neither in mv88e6xxx_port_vlan_join() nor inside the getnext implementation. So the new entry has random garbage for the STU bits, breaking VLAN filtering. When the VTU entry is initially created, those bits are all zero, and we should make sure to keep them that way when the entry is updated. Fixes: 92307069a96c (net: dsa: mv88e6xxx: Avoid VTU corruption on 6097) Signed-off-by: Rasmus Villemoes Reviewed-by: Florian Fainelli Reviewed-by: Tobias Waldekranz Tested-by: Tobias Waldekranz Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4e1d17a1f73b8a18abd32c8a67f43fdbf65ac6de Author: Necip Fazil Yildiran Date: Thu Sep 17 18:45:48 2020 +0300 sh: dma: fix kconfig dependency for G2_DMA commit f477a538c14d07f8c45e554c8c5208d588514e98 upstream. When G2_DMA is enabled and SH_DMA is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for SH_DMA_API Depends on [n]: SH_DMA [=n] Selected by [y]: - G2_DMA [=y] && SH_DREAMCAST [=y] The reason is that G2_DMA selects SH_DMA_API without depending on or selecting SH_DMA while SH_DMA_API depends on SH_DMA. When G2_DMA was first introduced with commit 40f49e7ed77f ("sh: dma: Make G2 DMA configurable."), this wasn't an issue since SH_DMA_API didn't have such dependency, and this way was the only way to enable it since SH_DMA_API was non-visible. However, later SH_DMA_API was made visible and dependent on SH_DMA with commit d8902adcc1a9 ("dmaengine: sh: Add Support SuperH DMA Engine driver"). Let G2_DMA depend on SH_DMA_API instead to avoid Kbuild issues. Fixes: d8902adcc1a9 ("dmaengine: sh: Add Support SuperH DMA Engine driver") Signed-off-by: Necip Fazil Yildiran Signed-off-by: Rich Felker Signed-off-by: Greg Kroah-Hartman commit 8a0b8e26f79f8cad30cbfe660ee23a3f315e1ab7 Author: Guillaume Nault Date: Sat Jan 16 11:44:26 2021 +0100 netfilter: rpfilter: mask ecn bits before fib lookup commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream. RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt() treats Not-ECT or ECT(1) packets in a different way than those with ECT(0) or CE. Reproducer: Create two netns, connected with a veth: $ ip netns add ns0 $ ip netns add ns1 $ ip link add name veth01 netns ns0 type veth peer name veth10 netns ns1 $ ip -netns ns0 link set dev veth01 up $ ip -netns ns1 link set dev veth10 up $ ip -netns ns0 address add 192.0.2.10/32 dev veth01 $ ip -netns ns1 address add 192.0.2.11/32 dev veth10 Add a route to ns1 in ns0: $ ip -netns ns0 route add 192.0.2.11/32 dev veth01 In ns1, only packets with TOS 4 can be routed to ns0: $ ip -netns ns1 route add 192.0.2.10/32 tos 4 dev veth10 Ping from ns0 to ns1 works regardless of the ECN bits, as long as TOS is 4: $ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT ... 0% packet loss ... $ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1) ... 0% packet loss ... $ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0) ... 0% packet loss ... $ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE ... 0% packet loss ... Now use iptable's rpfilter module in ns1: $ ip netns exec ns1 iptables-legacy -t raw -A PREROUTING -m rpfilter --invert -j DROP Not-ECT and ECT(1) packets still pass: $ ip netns exec ns0 ping -Q 4 192.0.2.11 # TOS 4, Not-ECT ... 0% packet loss ... $ ip netns exec ns0 ping -Q 5 192.0.2.11 # TOS 4, ECT(1) ... 0% packet loss ... But ECT(0) and ECN packets are dropped: $ ip netns exec ns0 ping -Q 6 192.0.2.11 # TOS 4, ECT(0) ... 100% packet loss ... $ ip netns exec ns0 ping -Q 7 192.0.2.11 # TOS 4, CE ... 100% packet loss ... After this patch, rpfilter doesn't drop ECT(0) and CE packets anymore. Fixes: 8f97339d3feb ("netfilter: add ipv4 reverse path filter match") Signed-off-by: Guillaume Nault Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 99328b4b44082891aae86232ab59cf755477fa04 Author: Yazen Ghannam Date: Mon Jan 11 11:04:29 2021 +0100 x86/cpu/amd: Set __max_die_per_package on AMD commit 76e2fc63ca40977af893b724b00cc2f8e9ce47a4 upstream. Set the maximum DIE per package variable on AMD using the NodesPerProcessor topology value. This will be used by RAPL, among others, to determine the maximum number of DIEs on the system in order to do per-DIE manipulations. [ bp: Productize into a proper patch. ] Fixes: 028c221ed190 ("x86/CPU/AMD: Save AMD NodeId as cpu_die_id") Reported-by: Johnathan Smithinovic Reported-by: Rafael Kitover Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Tested-by: Johnathan Smithinovic Tested-by: Rafael Kitover Link: https://bugzilla.kernel.org/show_bug.cgi?id=210939 Link: https://lkml.kernel.org/r/20210106112106.GE5729@zn.tnic Link: https://lkml.kernel.org/r/20210111101455.1194-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit 6f8ba0ada13936edea229baa4460e39e72ca1d69 Author: Paul Cercueil Date: Fri Dec 11 23:28:09 2020 +0000 pinctrl: ingenic: Fix JZ4760 support commit 9a85c09a3f507b925d75cb0c7c8f364467038052 upstream. - JZ4760 and JZ4760B have a similar register layout as the JZ4740, and don't use the new register layout, which was introduced with the JZ4770 SoC and not the JZ4760 or JZ4760B SoCs. - The JZ4740 code path only expected two function modes to be configurable for each pin, and wouldn't work with more than two. Fix it for the JZ4760, which has four configurable function modes. Fixes: 0257595a5cf4 ("pinctrl: Ingenic: Add pinctrl driver for JZ4760 and JZ4760B.") Cc: # 5.3 Signed-off-by: Paul Cercueil Link: https://lore.kernel.org/r/20201211232810.261565-1-paul@crapouillou.net Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman commit 382ffe7866473b985e7fb6fd742bda7b15d2d1f8 Author: Rafael J. Wysocki Date: Fri Jan 15 19:30:51 2021 +0100 driver core: Extend device_is_dependent() commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream. If the device passed as the target (second argument) to device_is_dependent() is not completely registered (that is, it has been initialized, but not added yet), but the parent pointer of it is set, it may be missing from the list of the parent's children and device_for_each_child() called by device_is_dependent() cannot be relied on to catch that dependency. For this reason, modify device_is_dependent() to check the ancestors of the target device by following its parent pointer in addition to the device_for_each_child() walk. Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking support") Reported-by: Stephan Gerhold Tested-by: Stephan Gerhold Reviewed-by: Saravana Kannan Signed-off-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher Cc: stable Signed-off-by: Greg Kroah-Hartman commit 4e749a28c909348feb1128107a18faa0bc3cb499 Author: JC Kuo Date: Fri Jan 15 18:19:07 2021 +0200 xhci: tegra: Delay for disabling LFPS detector commit da7e0c3c2909a3d9bf8acfe1db3cb213bd7febfb upstream. Occasionally, we are seeing some SuperSpeed devices resumes right after being directed to U3. This commits add 500us delay to ensure LFPS detector is disabled before sending ACK to firmware. [ 16.099363] tegra-xusb 70090000.usb: entering ELPG [ 16.104343] tegra-xusb 70090000.usb: 2-1 isn't suspended: 0x0c001203 [ 16.114576] tegra-xusb 70090000.usb: not all ports suspended: -16 [ 16.120789] tegra-xusb 70090000.usb: entering ELPG failed The register write passes through a few flop stages of 32KHz clock domain. NVIDIA ASIC designer reviewed RTL and suggests 500us delay. Cc: stable@vger.kernel.org Signed-off-by: JC Kuo Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210115161907.2875631-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit a6a5d08170c24ac7f382328c562d4eddcb423819 Author: Mathias Nyman Date: Fri Jan 15 18:19:06 2021 +0200 xhci: make sure TRB is fully written before giving it to the controller commit 576667bad341516edc4e18eb85acb0a2b4c9c9d9 upstream. Once the command ring doorbell is rung the xHC controller will parse all command TRBs on the command ring that have the cycle bit set properly. If the driver just started writing the next command TRB to the ring when hardware finished the previous TRB, then HW might fetch an incomplete TRB as long as its cycle bit set correctly. A command TRB is 16 bytes (128 bits) long. Driver writes the command TRB in four 32 bit chunks, with the chunk containing the cycle bit last. This does however not guarantee that chunks actually get written in that order. This was detected in stress testing when canceling URBs with several connected USB devices. Two consecutive "Set TR Dequeue pointer" commands got queued right after each other, and the second one was only partially written when the controller parsed it, causing the dequeue pointer to be set to bogus values. This was seen as error messages: "Mismatch between completed Set TR Deq Ptr command & xHCI internal state" Solution is to add a write memory barrier before writing the cycle bit. Cc: Tested-by: Ross Zwisler Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20210115161907.2875631-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 7f3cfc7e378da7d7f38f9125f8d93ab537f689b7 Author: Patrik Jakobsson Date: Mon Jan 18 21:36:15 2021 +0100 usb: bdc: Make bdc pci driver depend on BROKEN commit ef02684c4e67d8c35ac83083564135bc7b1d3445 upstream. The bdc pci driver is going to be removed due to it not existing in the wild. This patch turns off compilation of the driver so that stable kernels can also pick up the change. This helps the out-of-tree facetimehd webcam driver as the pci id conflicts with bdc. Cc: Al Cooper Cc: Acked-by: Felipe Balbi Signed-off-by: Patrik Jakobsson Link: https://lore.kernel.org/r/20210118203615.13995-1-patrik.r.jakobsson@gmail.com Signed-off-by: Greg Kroah-Hartman commit f764f90b0c77aa1d63c061f16b95a18842a45f29 Author: Thinh Nguyen Date: Thu Jan 14 00:09:51 2021 -0800 usb: udc: core: Use lock when write to soft_connect commit c28095bc99073ddda65e4f31f6ae0d908d4d5cd8 upstream. Use lock to guard against concurrent access for soft-connect/disconnect operations when writing to soft_connect sysfs. Fixes: 2ccea03a8f7e ("usb: gadget: introduce UDC Class") Cc: stable@vger.kernel.org Acked-by: Felipe Balbi Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/338ea01fbd69b1985ef58f0f59af02c805ddf189.1610611437.git.Thinh.Nguyen@synopsys.com Signed-off-by: Greg Kroah-Hartman commit 564f3c53264241424feace9ffc0df5538402fc98 Author: Ryan Chen Date: Fri Jan 8 16:12:38 2021 +0800 usb: gadget: aspeed: fix stop dma register setting. commit 4e0dcf62ab4cf917d0cbe751b8bf229a065248d4 upstream. The vhub engine has two dma mode, one is descriptor list, another is single stage DMA. Each mode has different stop register setting. Descriptor list operation (bit2) : 0 disable reset, 1: enable reset Single mode operation (bit0) : 0 : disable, 1: enable Fixes: 7ecca2a4080c ("usb/gadget: Add driver for Aspeed SoC virtual hub") Cc: stable Acked-by: Felipe Balbi Acked-by: Joel Stanley Signed-off-by: Ryan Chen Link: https://lore.kernel.org/r/20210108081238.10199-2-ryan_chen@aspeedtech.com Signed-off-by: Greg Kroah-Hartman commit f89a193fd9d37d9b9a07764c31e969111756b02a Author: Longfang Liu Date: Tue Jan 12 09:57:27 2021 +0800 USB: ehci: fix an interrupt calltrace error commit 643a4df7fe3f6831d14536fd692be85f92670a52 upstream. The system that use Synopsys USB host controllers goes to suspend when using USB audio player. This causes the USB host controller continuous send interrupt signal to system, When the number of interrupts exceeds 100000, the system will forcibly close the interrupts and output a calltrace error. When the system goes to suspend, the last interrupt is reported to the driver. At this time, the system has set the state to suspend. This causes the last interrupt to not be processed by the system and not clear the interrupt flag. This uncleared interrupt flag constantly triggers new interrupt event. This causing the driver to receive more than 100,000 interrupts, which causes the system to forcibly close the interrupt report and report the calltrace error. so, when the driver goes to sleep and changes the system state to suspend, the interrupt flag needs to be cleared. Signed-off-by: Longfang Liu Acked-by: Alan Stern Link: https://lore.kernel.org/r/1610416647-45774-1-git-send-email-liulongfang@huawei.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 9a660760299bf9eac88ec6a13014c9f3b28b2553 Author: Eugene Korenevsky Date: Sun Jan 10 20:36:09 2021 +0300 ehci: fix EHCI host controller initialization sequence commit 280a9045bb18833db921b316a5527d2b565e9f2e upstream. According to EHCI spec, EHCI HC clears USBSTS.HCHalted whenever USBCMD.RS=1. However, it is a good practice to wait some time after setting USBCMD.RS (approximately 100ms) until USBSTS.HCHalted become zero. Without this waiting, VirtualBox's EHCI virtual HC accidentally hangs (see BugLink). BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=211095 Acked-by: Alan Stern Signed-off-by: Eugene Korenevsky Cc: stable Link: https://lore.kernel.org/r/20210110173609.GA17313@himera.home Signed-off-by: Greg Kroah-Hartman commit 5eda5db39e2815f9424decaf904d8ddc42ab7f62 Author: Pali Rohár Date: Wed Dec 23 20:19:31 2020 +0100 serial: mvebu-uart: fix tx lost characters at power off commit 54ca955b5a4024e2ce0f206b03adb7109bc4da26 upstream. Commit c685af1108d7 ("serial: mvebu-uart: fix tx lost characters") fixed tx lost characters at low baud rates but started causing tx lost characters when kernel is going to power off or reboot. TX_EMP tells us when transmit queue is empty therefore all characters were transmitted. TX_RDY tells us when CPU can send a new character. Therefore we need to use different check prior transmitting new character and different check after all characters were sent. This patch splits polling code into two functions: wait_for_xmitr() which waits for TX_RDY and wait_for_xmite() which waits for TX_EMP. When rebooting A3720 platform without this patch on UART is print only: [ 42.699� And with this patch on UART is full output: [ 39.530216] reboot: Restarting system Fixes: c685af1108d7 ("serial: mvebu-uart: fix tx lost characters") Signed-off-by: Pali Rohár Cc: stable Link: https://lore.kernel.org/r/20201223191931.18343-1-pali@kernel.org Signed-off-by: Greg Kroah-Hartman commit a8fade59466c358df3ca33232aa193d4eadf40ee Author: Wang Hui Date: Fri Jan 15 22:59:16 2021 +0300 stm class: Fix module init return on allocation failure commit 927633a6d20af319d986f3e42c3ef9f6d7835008 upstream. In stm_heartbeat_init(): return value gets reset after the first iteration by stm_source_register_device(), so allocation failures after that will, after a clean up, return success. Fix that. Fixes: 119291853038 ("stm class: Add heartbeat stm source device") Reported-by: Hulk Robot Signed-off-by: Wang Hui Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/r/20210115195917.3184-2-alexander.shishkin@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit 5e4bacea58ca25785453677eab170e587e00a191 Author: Alexander Shishkin Date: Fri Jan 15 22:59:17 2021 +0300 intel_th: pci: Add Alder Lake-P support commit cb5c681ab9037e25fcca20689c82cf034566d610 upstream. This adds support for the Trace Hub in Alder Lake-P. Signed-off-by: Alexander Shishkin Link: https://lore.kernel.org/r/20210115195917.3184-3-alexander.shishkin@linux.intel.com Cc: stable Signed-off-by: Greg Kroah-Hartman commit c5885886c72c4fcb283bd8f5066ddf2e44afc094 Author: Andy Lutomirski Date: Wed Jan 20 21:09:49 2021 -0800 x86/mmx: Use KFPU_387 for MMX string operations commit 67de8dca50c027ca0fa3b62a488ee5035036a0da upstream. The default kernel_fpu_begin() doesn't work on systems that support XMM but haven't yet enabled CR4.OSFXSR. This causes crashes when _mmx_memcpy() is called too early because LDMXCSR generates #UD when the aforementioned bit is clear. Fix it by using kernel_fpu_begin_mask(KFPU_387) explicitly. Fixes: 7ad816762f9b ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()") Reported-by: Krzysztof Mazur Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Tested-by: Krzysztof Piotr Olędzki Tested-by: Krzysztof Mazur Cc: Link: https://lkml.kernel.org/r/e7bf21855fe99e5f3baa27446e32623358f69e8d.1611205691.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit d1a9cd1dc53c6ff3126e627b80ebf324ef4b8ee9 Author: Borislav Petkov Date: Thu Jan 14 10:36:59 2021 +0100 x86/topology: Make __max_die_per_package available unconditionally commit 1eb8f690bcb565a6600f8b6dcc78f7b239ceba17 upstream. Move it outside of CONFIG_SMP in order to avoid ifdeffery at the usage sites. Fixes: 76e2fc63ca40 ("x86/cpu/amd: Set __max_die_per_package on AMD") Reported-by: Stephen Rothwell Reported-by: kernel test robot Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210114111814.5346-1-bp@alien8.de Signed-off-by: Greg Kroah-Hartman commit cdb4ce96fdd2a659a244c711ad244d2fb5b97675 Author: Andy Lutomirski Date: Wed Jan 20 21:09:48 2021 -0800 x86/fpu: Add kernel_fpu_begin_mask() to selectively initialize state commit e45122893a9870813f9bd7b4add4f613e6f29008 upstream. Currently, requesting kernel FPU access doesn't distinguish which parts of the extended ("FPU") state are needed. This is nice for simplicity, but there are a few cases in which it's suboptimal: - The vast majority of in-kernel FPU users want XMM/YMM/ZMM state but do not use legacy 387 state. These users want MXCSR initialized but don't care about the FPU control word. Skipping FNINIT would save time. (Empirically, FNINIT is several times slower than LDMXCSR.) - Code that wants MMX doesn't want or need MXCSR initialized. _mmx_memcpy(), for example, can run before CR4.OSFXSR gets set, and initializing MXCSR will fail because LDMXCSR generates an #UD when the aforementioned CR4 bit is not set. - Any future in-kernel users of XFD (eXtended Feature Disable)-capable dynamic states will need special handling. Add a more specific API that allows callers to specify exactly what they want. Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Tested-by: Krzysztof Piotr Olędzki Link: https://lkml.kernel.org/r/aff1cac8b8fc7ee900cf73e8f2369966621b053f.1611205691.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit cd1c4882ab43514af1c11e9ff4229139a303851b Author: Mathias Kresin Date: Thu Jan 7 22:36:03 2021 +0100 irqchip/mips-cpu: Set IPI domain parent chip commit 599b3063adf4bf041a87a69244ee36aded0d878f upstream. Since commit 55567976629e ("genirq/irqdomain: Allow partial trimming of irq_data hierarchy") the irq_data chain is valided. The irq_domain_trim_hierarchy() function doesn't consider the irq + ipi domain hierarchy as valid, since the ipi domain has the irq domain set as parent, but the parent domain has no chip set. Hence the boot ends in a kernel panic. Set the chip for the parent domain as it is done in the mips gic irq driver, to have a valid irq_data chain. Fixes: 3838a547fda2 ("irqchip: mips-cpu: Introduce IPI IRQ domain support") Cc: # v5.10+ Signed-off-by: Mathias Kresin Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20210107213603.1637781-1-dev@kresin.me Signed-off-by: Greg Kroah-Hartman commit 9a2f6007a228290da343e31881853d43e2dd6543 Author: Ronnie Sahlberg Date: Thu Jan 21 08:22:48 2021 +1000 cifs: do not fail __smb_send_rqst if non-fatal signals are pending commit 214a5ea081e77346e4963dd6d20c5539ff8b6ae6 upstream. RHBZ 1848178 The original intent of returning an error in this function in the patch: "CIFS: Mask off signals when sending SMB packets" was to avoid interrupting packet send in the middle of sending the data (and thus breaking an SMB connection), but we also don't want to fail the request for non-fatal signals even before we have had a chance to try to send it (the reported problem could be reproduced e.g. by exiting a child process when the parent process was in the midst of calling futimens to update a file's timestamps). In addition, since the signal may remain pending when we enter the sending loop, we may end up not sending the whole packet before TCP buffers become full. In this case the code returns -EINTR but what we need here is to return -ERESTARTSYS instead to allow system calls to be restarted. Fixes: b30c74c73c78 ("CIFS: Mask off signals when sending SMB packets") Cc: stable@vger.kernel.org # v5.1+ Signed-off-by: Ronnie Sahlberg Reviewed-by: Pavel Shilovsky Signed-off-by: Steve French Signed-off-by: Greg Kroah-Hartman commit 745229c903015d19af68bb848e08544aff8133be Author: Lars-Peter Clausen Date: Wed Dec 9 11:46:49 2020 +0100 iio: ad5504: Fix setting power-down state commit efd597b2839a9895e8a98fcb0b76d2f545802cd4 upstream. The power-down mask of the ad5504 is actually a power-up mask. Meaning if a bit is set the corresponding channel is powered up and if it is not set the channel is powered down. The driver currently has this the wrong way around, resulting in the channel being powered up when requested to be powered down and vice versa. Fixes: 3bbbf150ffde ("staging:iio:dac:ad5504: Use strtobool for boolean values") Signed-off-by: Lars-Peter Clausen Acked-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20201209104649.5794-1-lars@metafoo.de Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit ddd1416f44130377798c1430b76503513b7497c2 Author: Vincent Mailhol Date: Wed Jan 20 20:41:37 2021 +0900 can: peak_usb: fix use after free bugs [ Upstream commit 50aca891d7a554db0901b245167cd653d73aaa71 ] After calling peak_usb_netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the peak_usb_netif_rx_ni(). Reordering the lines solves the issue. Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Link: https://lore.kernel.org/r/20210120114137.200019-4-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit a24476b37167816e6352ca1a2cf3769847774f70 Author: Vincent Mailhol Date: Wed Jan 20 20:41:36 2021 +0900 can: vxcan: vxcan_xmit: fix use after free bug [ Upstream commit 75854cad5d80976f6ea0f0431f8cedd3bcc475cb ] After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the canfd_frame cfd which aliases skb memory is accessed after the netif_rx_ni(). Fixes: a8f820a380a2 ("can: add Virtual CAN Tunnel driver (vxcan)") Link: https://lore.kernel.org/r/20210120114137.200019-3-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit ac48ef15826e83f4206c47add61072e8fc76d328 Author: Vincent Mailhol Date: Wed Jan 20 20:41:35 2021 +0900 can: dev: can_restart: fix use after free bug [ Upstream commit 03f16c5075b22c8902d2af739969e878b0879c94 ] After calling netif_rx_ni(skb), dereferencing skb is unsafe. Especially, the can_frame cf which aliases skb memory is accessed after the netif_rx_ni() in: stats->rx_bytes += cf->len; Reordering the lines solves the issue. Fixes: 39549eef3587 ("can: CAN Network device driver and Netlink interface") Link: https://lore.kernel.org/r/20210120114137.200019-2-mailhol.vincent@wanadoo.fr Signed-off-by: Vincent Mailhol Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 391187744436ec5bf00bab9952d145fc9fb652d1 Author: Hangbin Liu Date: Tue Jan 19 10:59:30 2021 +0800 selftests: net: fib_tests: remove duplicate log test [ Upstream commit fd23d2dc180fccfad4b27a8e52ba1bc415d18509 ] The previous test added an address with a specified metric and check if correspond route was created. I somehow added two logs for the same test. Remove the duplicated one. Reported-by: Antoine Tenart Fixes: 0d29169a708b ("selftests/net/fib_tests: update addr_metric_test for peer route testing") Signed-off-by: Hangbin Liu Reviewed-by: David Ahern Link: https://lore.kernel.org/r/20210119025930.2810532-1-liuhangbin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 237375005739202b3d05ed9cd69d03c1ee7130b5 Author: Hans de Goede Date: Thu Jan 14 15:34:32 2021 +0100 platform/x86: intel-vbtn: Drop HP Stream x360 Convertible PC 11 from allow-list [ Upstream commit 070222731be52d741e55d8967b1764482b81e54c ] THe HP Stream x360 Convertible PC 11 DSDT has the following VGBS function: Method (VGBS, 0, Serialized) { If ((^^PCI0.LPCB.EC0.ROLS == Zero)) { VBDS = Zero } Else { VBDS = Zero } Return (VBDS) /* \_SB_.VGBI.VBDS */ } Which is obviously wrong, because it always returns 0 independent of the 2-in-1 being in laptop or tablet mode. This causes the intel-vbtn driver to initially report SW_TABLET_MODE = 1 to userspace, which is known to cause problems when the 2-in-1 is actually in laptop mode. During earlier testing this turned out to not be a problem because the 2-in-1 would do a Notify(..., 0xCC) or Notify(..., 0xCD) soon after the intel-vbtn driver loaded, correcting the SW_TABLET_MODE state. Further testing however has shown that this Notify() soon after the intel-vbtn driver loads, does not always happen. When the Notify does not happen, then intel-vbtn reports SW_TABLET_MODE = 1 resulting in a non-working touchpad. IOW the tablet-mode reporting is not reliable on this device, so it should be dropped from the allow-list, fixing the touchpad sometimes not working. Fixes: 8169bd3e6e19 ("platform/x86: intel-vbtn: Switch to an allow-list for SW_TABLET_MODE reporting") Link: https://lore.kernel.org/r/20210114143432.31750-1-hdegoede@redhat.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 57f0f0ddf9e4cd73fe98fbc35ca3438f8939bf64 Author: Wolfram Sang Date: Sat Jan 9 13:43:08 2021 +0100 i2c: octeon: check correct size of maximum RECV_LEN packet [ Upstream commit 1b2cfa2d1dbdcc3b6dba1ecb7026a537a1d7277f ] I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the SMBus 2.0 specs. No reason to add one to it. Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN") Signed-off-by: Wolfram Sang Reviewed-by: Robert Richter Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 485e0255c19e8135084f0fa86bc6ec3ffebd6b97 Author: Ariel Marcovitch Date: Sat Jan 2 22:11:56 2021 +0200 powerpc: Fix alignment bug within the init sections [ Upstream commit 2225a8dda263edc35a0e8b858fe2945cf6240fde ] This is a bug that causes early crashes in builds with an .exit.text section smaller than a page and an .init.text section that ends in the beginning of a physical page (this is kinda random, which might explain why this wasn't really encountered before). The init sections are ordered like this: .init.text .exit.text .init.data Currently, these sections aren't page aligned. Because the init code might become read-only at runtime and because the .init.text section can potentially reside on the same physical page as .init.data, the beginning of .init.data might be mapped read-only along with .init.text. Then when the kernel tries to modify a variable in .init.data (like kthreadd_done, used in kernel_init()) the kernel panics. To avoid this, make _einittext page aligned and also align .exit.text to make sure .init.data is always seperated from the text segments. Fixes: 060ef9d89d18 ("powerpc32: PAGE_EXEC required for inittext") Signed-off-by: Ariel Marcovitch Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20210102201156.10805-1-ariel.marcovitch@gmail.com Signed-off-by: Sasha Levin commit cfea5cddeb71cbb07c400e0fed50461a15ee5315 Author: Arnd Bergmann Date: Tue Jan 5 00:41:04 2021 +0100 scsi: megaraid_sas: Fix MEGASAS_IOC_FIRMWARE regression [ Upstream commit b112036535eda34460677ea883eaecc3a45a435d ] Phil Oester reported that a fix for a possible buffer overrun that I sent caused a regression that manifests in this output: Event Message: A PCI parity error was detected on a component at bus 0 device 5 function 0. Severity: Critical Message ID: PCI1308 The original code tried to handle the sense data pointer differently when using 32-bit 64-bit DMA addressing, which would lead to a 32-bit dma_addr_t value of 0x11223344 to get stored 32-bit kernel: 44 33 22 11 ?? ?? ?? ?? 64-bit LE kernel: 44 33 22 11 00 00 00 00 64-bit BE kernel: 00 00 00 00 44 33 22 11 or a 64-bit dma_addr_t value of 0x1122334455667788 to get stored as 32-bit kernel: 88 77 66 55 ?? ?? ?? ?? 64-bit kernel: 88 77 66 55 44 33 22 11 In my patch, I tried to ensure that the same value is used on both 32-bit and 64-bit kernels, and picked what seemed to be the most sensible combination, storing 32-bit addresses in the first four bytes (as 32-bit kernels already did), and 64-bit addresses in eight consecutive bytes (as 64-bit kernels already did), but evidently this was incorrect. Always storing the dma_addr_t pointer as 64-bit little-endian, i.e. initializing the second four bytes to zero in case of 32-bit addressing, apparently solved the problem for Phil, and is consistent with what all 64-bit little-endian machines did before. I also checked in the history that in previous versions of the code, the pointer was always in the first four bytes without padding, and that previous attempts to fix 64-bit user space, big-endian architectures and 64-bit DMA were clearly flawed and seem to have introduced made this worse. Link: https://lore.kernel.org/r/20210104234137.438275-1-arnd@kernel.org Fixes: 381d34e376e3 ("scsi: megaraid_sas: Check user-provided offsets") Fixes: 107a60dd71b5 ("scsi: megaraid_sas: Add support for 64bit consistent DMA") Fixes: 94cd65ddf4d7 ("[SCSI] megaraid_sas: addded support for big endian architecture") Fixes: 7b2519afa1ab ("[SCSI] megaraid_sas: fix 64 bit sense pointer truncation") Reported-by: Phil Oester Tested-by: Phil Oester Signed-off-by: Arnd Bergmann Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit da3324ec5497a9157b1d1095053f062c56761457 Author: Billy Tsai Date: Thu Dec 17 10:49:12 2020 +0800 pinctrl: aspeed: g6: Fix PWMG0 pinctrl setting [ Upstream commit 92ff62a7bcc17d47c0ce8dddfb7a6e1a2e55ebf4 ] The SCU offset for signal PWM8 in group PWM8G0 is wrong, fix it from SCU414 to SCU4B4. Signed-off-by: Billy Tsai Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support") Reviewed-by: Joel Stanley Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20201217024912.3198-1-billy_tsai@aspeedtech.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5625c3da7167314d54c2bb91b3f82debcdfe04df Author: Youling Tang Date: Wed Nov 4 18:59:10 2020 +0800 powerpc: Use the common INIT_DATA_SECTION macro in vmlinux.lds.S [ Upstream commit fdcfeaba38e5b183045f5b079af94f97658eabe6 ] Use the common INIT_DATA_SECTION rule for the linker script in an effort to regularize the linker script. Signed-off-by: Youling Tang Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1604487550-20040-1-git-send-email-tangyouling@loongson.cn Signed-off-by: Sasha Levin commit 73a229119983bc0bedd17604ef0b94c292230870 Author: Ben Skeggs Date: Wed Jan 13 17:12:52 2021 +1000 drm/nouveau/kms/nv50-: fix case where notifier buffer is at offset 0 [ Upstream commit caeb6ab899c3d36a74cda6e299c6e1c9c4e2a22e ] VRAM offset 0 is a valid address, triggered on GA102. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit af91a2e7fb5e03401dbddfa6f9f91998616b1995 Author: Ben Skeggs Date: Wed Jan 13 17:12:52 2021 +1000 drm/nouveau/mmu: fix vram heap sizing [ Upstream commit add42781ad76c5ae65127bf13852a4c6b2f08849 ] Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit ee2c9e58f430ff60ab77df6ce29320e6231b348f Author: Ben Skeggs Date: Wed Jan 13 17:12:52 2021 +1000 drm/nouveau/i2c/gm200: increase width of aux semaphore owner fields [ Upstream commit ba6e9ab0fcf3d76e3952deb12b5f993991621d9c ] Noticed while debugging GA102. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 38f35023fd301abeb01cfd81e73caa2e4e7ec0b1 Author: Ben Skeggs Date: Wed Jan 13 17:12:52 2021 +1000 drm/nouveau/privring: ack interrupts the same way as RM [ Upstream commit e05e06cd34f5311f677294a08b609acfbc315236 ] Whatever it is that we were doing before doesn't work on Ampere. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 8c3d3b385ed868660c7dff0336da1bd5a9fb134d Author: Ben Skeggs Date: Wed Jan 13 17:12:52 2021 +1000 drm/nouveau/bios: fix issue shadowing expansion ROMs [ Upstream commit 402a89660e9dc880710b12773076a336c9dab3d7 ] This issue has generally been covered up by the presence of additional expansion ROMs after the ones we're interested in, with header fetches of subsequent images loading enough of the ROM to hide the issue. Noticed on GA102, which lacks a type 0x70 image compared to TU102,. [ 906.364197] nouveau 0000:09:00.0: bios: 00000000: type 00, 65024 bytes [ 906.381205] nouveau 0000:09:00.0: bios: 0000fe00: type 03, 91648 bytes [ 906.405213] nouveau 0000:09:00.0: bios: 00026400: type e0, 22016 bytes [ 906.410984] nouveau 0000:09:00.0: bios: 0002ba00: type e0, 366080 bytes vs [ 22.961901] nouveau 0000:09:00.0: bios: 00000000: type 00, 60416 bytes [ 22.984174] nouveau 0000:09:00.0: bios: 0000ec00: type 03, 71168 bytes [ 23.010446] nouveau 0000:09:00.0: bios: 00020200: type e0, 48128 bytes [ 23.028220] nouveau 0000:09:00.0: bios: 0002be00: type e0, 140800 bytes [ 23.080196] nouveau 0000:09:00.0: bios: 0004e400: type 70, 7168 bytes Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit f5dc9627ac04a98afefcf05035239e0001d6c393 Author: Wayne Lin Date: Tue Nov 24 19:57:03 2020 +0800 drm/amd/display: Fix to be able to stop crc calculation [ Upstream commit 02ce73b01e09e388614b22b7ebc71debf4a588f0 ] [Why] Find out when we try to disable CRC calculation, crc generation is still enabled. Main reason is that dc_stream_configure_crc() will never get called when the source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE. [How] Add checking condition that when source is AMDGPU_DM_PIPE_CRC_SOURCE_NONE, we should also call dc_stream_configure_crc() to disable crc calculation. Also, clean up crc window when disable crc calculation. Signed-off-by: Wayne Lin Reviewed-by: Nicholas Kazlauskas Acked-by: Qingqing Zhuo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 9f6d85e20125ff88137653673e1dd7b55726612b Author: Victor Zhao Date: Tue Jan 5 15:04:01 2021 +0800 drm/amdgpu/psp: fix psp gfx ctrl cmds [ Upstream commit f14a5c34d143f6627f0be70c0de1d962f3a6ff1c ] psp GFX_CTRL_CMD_ID_CONSUME_CMD different for windows and linux, according to psp, linux cmds are not correct. v2: only correct GFX_CTRL_CMD_ID_CONSUME_CMD. Signed-off-by: Victor Zhao Reviewed-by: Emily.Deng Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5b2266d62b5437cf83ef01d1a2d32b45c693b93e Author: Sagar Shrikant Kadam Date: Tue Nov 10 07:22:12 2020 -0800 riscv: defconfig: enable gpio support for HiFive Unleashed [ Upstream commit 0983834a83931606a647c275e5d4165ce4e7b49f ] Ethernet phy VSC8541-01 on HiFive Unleashed has its reset line connected to a gpio, so enable GPIO driver's required to reset the phy. Signed-off-by: Sagar Shrikant Kadam Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 7eef736858712ab65afea3908f49eb4e7775fa93 Author: Sagar Shrikant Kadam Date: Tue Nov 10 07:22:10 2020 -0800 dts: phy: fix missing mdio device and probe failure of vsc8541-01 device [ Upstream commit be969b7cfbcfa8a835a528f1dc467f0975c6d883 ] HiFive unleashed A00 board has VSC8541-01 ethernet phy, this device is identified as a Revision B device as described in device identification registers. In order to use this phy in the unmanaged mode, it requires a specific reset sequence of logical 0-1-0-1 transition on the NRESET pin as documented here [1]. Currently, the bootloader (fsbl or u-boot-spl) takes care of the phy reset. If due to some reason the phy device hasn't received the reset by the prior stages before the linux macb driver comes into the picture, the MACB mii bus gets probed but the mdio scan fails and is not even able to read the phy ID registers. It gives an error message: "libphy: MACB_mii_bus: probed mdio_bus 10090000.ethernet-ffffffff: MDIO device at address 0 is missing." Thus adding the device OUI (Organizationally Unique Identifier) to the phy device node helps to probe the phy device. [1]: VSC8541-01 datasheet: https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf Signed-off-by: Sagar Shrikant Kadam Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 5fa6987258a757a9fae70ff28188dff07f01bf50 Author: David Woodhouse Date: Wed Jan 6 15:39:56 2021 +0000 x86/xen: Add xen_no_vector_callback option to test PCI INTX delivery [ Upstream commit b36b0fe96af13460278bf9b173beced1bd15f85d ] It's useful to be able to test non-vector event channel delivery, to make sure Linux will work properly on older Xen which doesn't have it. It's also useful for those working on Xen and Xen-compatible hypervisors, because there are guest kernels still in active use which use PCI INTX even when vector delivery is available. Signed-off-by: David Woodhouse Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210106153958.584169-4-dwmw2@infradead.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit a09d4e7acdbf276b2096661ee82454ae3dd24d2b Author: David Woodhouse Date: Wed Jan 13 13:26:02 2021 +0000 xen: Fix event channel callback via INTX/GSI [ Upstream commit 3499ba8198cad47b731792e5e56b9ec2a78a83a2 ] For a while, event channel notification via the PCI platform device has been broken, because we attempt to communicate with xenstore before we even have notifications working, with the xs_reset_watches() call in xs_init(). We tend to get away with this on Xen versions below 4.0 because we avoid calling xs_reset_watches() anyway, because xenstore might not cope with reading a non-existent key. And newer Xen *does* have the vector callback support, so we rarely fall back to INTX/GSI delivery. To fix it, clean up a bit of the mess of xs_init() and xenbus_probe() startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM case, deferring it to be called from xenbus_probe() in the XS_HVM case instead. Then fix up the invocation of xenbus_probe() to happen either from its device_initcall if the callback is available early enough, or when the callback is finally set up. This means that the hack of calling xenbus_probe() from a workqueue after the first interrupt, or directly from the PCI platform device setup, is no longer needed. Signed-off-by: David Woodhouse Reviewed-by: Boris Ostrovsky Link: https://lore.kernel.org/r/20210113132606.422794-2-dwmw2@infradead.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit acc402fa5bf502d471d50e3d495379f093a7f9e4 Author: Arnd Bergmann Date: Fri Jan 8 10:19:56 2021 +0100 arm64: make atomic helpers __always_inline [ Upstream commit c35a824c31834d947fb99b0c608c1b9f922b4ba0 ] With UBSAN enabled and building with clang, there are occasionally warnings like WARNING: modpost: vmlinux.o(.text+0xc533ec): Section mismatch in reference from the function arch_atomic64_or() to the variable .init.data:numa_nodes_parsed The function arch_atomic64_or() references the variable __initdata numa_nodes_parsed. This is often because arch_atomic64_or lacks a __initdata annotation or the annotation of numa_nodes_parsed is wrong. for functions that end up not being inlined as intended but operating on __initdata variables. Mark these as __always_inline, along with the corresponding asm-generic wrappers. Signed-off-by: Arnd Bergmann Acked-by: Will Deacon Link: https://lore.kernel.org/r/20210108092024.4034860-1-arnd@kernel.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 8ab3478335ad8fc08f14ec73251b084fe02b3ebb Author: Peter Geis Date: Fri Jan 8 13:59:12 2021 +0000 clk: tegra30: Add hda clock default rates to clock driver [ Upstream commit f4eccc7fea203cfb35205891eced1ab51836f362 ] Current implementation defaults the hda clocks to clk_m. This causes hda to run too slow to operate correctly. Fix this by defaulting to pll_p and setting the frequency to the correct rate. This matches upstream t124 and downstream t30. Acked-by: Jon Hunter Tested-by: Ion Agorria Acked-by: Sameer Pujar Acked-by: Thierry Reding Signed-off-by: Peter Geis Link: https://lore.kernel.org/r/20210108135913.2421585-2-pgwipeout@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c074680653e27f19eb584522df06758607277f77 Author: Seth Miller Date: Mon Jan 4 22:58:12 2021 -0600 HID: Ignore battery for Elan touchscreen on ASUS UX550 [ Upstream commit 7c38e769d5c508939ce5dc26df72602f3c902342 ] Battery status is being reported for the Elan touchscreen on ASUS UX550 laptops despite not having a batter. It always shows either 0 or 1%. Signed-off-by: Seth Miller Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 9cec63a3aacbcaee8d09aecac2ca2f8820efcc70 Author: Filipe Laíns Date: Mon Jan 4 20:47:17 2021 +0000 HID: logitech-dj: add the G602 receiver [ Upstream commit e400071a805d6229223a98899e9da8c6233704a1 ] Tested. The device gets correctly exported to userspace and I can see mouse and keyboard events. Signed-off-by: Filipe Laíns Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit b1b943f5b65e374df982d9d37bfdddcb4870372f Author: Damien Le Moal Date: Sun Dec 13 22:50:35 2020 +0900 riscv: Fix sifive serial driver [ Upstream commit 1f1496a923b6ba16679074fe77100e1b53cdb880 ] Setup the port uartclk in sifive_serial_probe() so that the base baud rate is correctly printed during device probe instead of always showing "0". I.e. the probe message is changed from 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 0) is a SiFive UART v0 to the correct: 38000000.serial: ttySIF0 at MMIO 0x38000000 (irq = 1, base_baud = 115200) is a SiFive UART v0 Signed-off-by: Damien Le Moal Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit cd0c46821aa5bbc3f2f2a09a68b9adc647fb4167 Author: Damien Le Moal Date: Sun Dec 13 22:50:34 2020 +0900 riscv: Fix kernel time_init() [ Upstream commit 11f4c2e940e2f317c9d8fb5a79702f2a4a02ff98 ] If of_clk_init() is not called in time_init(), clock providers defined in the system device tree are not initialized, resulting in failures for other devices to initialize due to missing clocks. Similarly to other architectures and to the default kernel time_init() implementation, call of_clk_init() before executing timer_probe() in time_init(). Signed-off-by: Damien Le Moal Acked-by: Stephen Boyd Reviewed-by: Palmer Dabbelt Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 5a1d7bb7d333849eb7d3ab5ebfbf9805b2cd46c9 Author: Ewan D. Milne Date: Mon Dec 7 17:10:21 2020 -0500 scsi: sd: Suppress spurious errors when WRITE SAME is being disabled [ Upstream commit e5cc9002caafacbaa8dab878d17a313192c3b03b ] The block layer code will split a large zeroout request into multiple bios and if WRITE SAME is disabled because the storage device reports that it does not support it (or support the length used), we can get an error message from the block layer despite the setting of RQF_QUIET on the first request. This is because more than one request may have already been submitted. Fix this by setting RQF_QUIET when BLK_STS_TARGET is returned to fail the request early, we don't need to log a message because we did not actually submit the command to the device, and the block layer code will handle the error by submitting individual write bios. Link: https://lore.kernel.org/r/20201207221021.28243-1-emilne@redhat.com Reviewed-by: Christoph Hellwig Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 68f99105752d132d411231bfc60cf78eceaac5e0 Author: Nilesh Javali Date: Thu Dec 17 02:51:44 2020 -0800 scsi: qedi: Correct max length of CHAP secret [ Upstream commit d50c7986fbf0e2167279e110a2ed5bd8e811c660 ] The CHAP secret displayed garbage characters causing iSCSI login authentication failure. Correct the CHAP password max length. Link: https://lore.kernel.org/r/20201217105144.8055-1-njavali@marvell.com Reviewed-by: Lee Duncan Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 97853a7eae80a695a18ce432524eaa7432199a41 Author: Can Guo Date: Mon Dec 28 04:04:36 2020 -0800 scsi: ufs: Correct the LUN used in eh_device_reset_handler() callback [ Upstream commit 35fc4cd34426c242ab015ef280853b7bff101f48 ] Users can initiate resets to specific SCSI device/target/host through IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host _reset_handler() callbacks is initialized with a request whose tag is -1. In this case it is not right for eh_device_reset_handler() callback to count on the LUN get from hba->lrb[-1]. Fix it by getting LUN from the SCSI device associated with the SCSI cmd. Link: https://lore.kernel.org/r/1609157080-26283-1-git-send-email-cang@codeaurora.org Reviewed-by: Avri Altman Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b477f4371045d9e863adbaf2cc4e7ec3b165130a Author: Anthony Iliopoulos Date: Mon Dec 14 18:18:11 2020 +0100 dm integrity: select CRYPTO_SKCIPHER [ Upstream commit f7b347acb5f6c29d9229bb64893d8b6a2c7949fb ] The integrity target relies on skcipher for encryption/decryption, but certain kernel configurations may not enable CRYPTO_SKCIPHER, leading to compilation errors due to unresolved symbols. Explicitly select CRYPTO_SKCIPHER for DM_INTEGRITY, since it is unconditionally dependent on it. Signed-off-by: Anthony Iliopoulos Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 8ebe26a1e236a39c199100eeb07ba0a6fbe945ed Author: Kai-Heng Feng Date: Wed Dec 30 20:44:07 2020 +0800 HID: multitouch: Enable multi-input for Synaptics pointstick/touchpad device [ Upstream commit c3d6eb6e54373f297313b65c1f2319d36914d579 ] Pointstick and its left/right buttons on HP EliteBook 850 G7 need multi-input quirk to work correctly. Signed-off-by: Kai-Heng Feng Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 6af49167440ade228bb78539084f1748296eedb0 Author: Cezary Rojewski Date: Thu Dec 17 11:54:01 2020 +0100 ASoC: Intel: haswell: Add missing pm_ops [ Upstream commit bb224c3e3e41d940612d4cc9573289cdbd5cb8f5 ] haswell machine board is missing pm_ops what prevents it from undergoing suspend-resume procedure successfully. Assign default snd_soc_pm_ops so this is no longer the case. Signed-off-by: Cezary Rojewski Link: https://lore.kernel.org/r/20201217105401.27865-1-cezary.rojewski@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad1df24b37d9ac5afcbc333ae4a35d30ce936bf8 Author: Chris Wilson Date: Mon Jan 18 09:53:32 2021 +0000 drm/i915/gt: Prevent use of engine->wa_ctx after error commit 488751a0ef9b5ce572c47301ce62d54fc6b5a74d upstream. On error we unpin and free the wa_ctx.vma, but do not clear any of the derived flags. During lrc_init, we look at the flags and attempt to dereference the wa_ctx.vma if they are set. To protect the error path where we try to limp along without the wa_ctx, make sure we clear those flags! Reported-by: Matt Roper Fixes: 604a8f6f1e33 ("drm/i915/lrc: Only enable per-context and per-bb buffers if set") Signed-off-by: Chris Wilson Cc: Matt Roper Cc: Tvrtko Ursulin Cc: Mika Kuoppala Cc: # v4.15+ Reviewed-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20210108204026.20682-1-chris@chris-wilson.co.uk (cherry-picked from 5b4dc95cf7f573e927fbbd406ebe54225d41b9b2) Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20210118095332.458813-1-chris@chris-wilson.co.uk Signed-off-by: Greg Kroah-Hartman commit 6b59bd9eea08dea84df61bfa847579f14213684c Author: Daniel Vetter Date: Tue Jan 19 14:03:18 2021 +0100 drm/syncobj: Fix use-after-free commit a37eef63bc9e16e06361b539e528058146af80ab upstream. While reviewing Christian's annotation patch I noticed that we have a user-after-free for the WAIT_FOR_SUBMIT case: We drop the syncobj reference before we've completed the waiting. Of course usually there's nothing bad happening here since userspace keeps the reference, but we can't rely on userspace to play nice here! Signed-off-by: Daniel Vetter Fixes: bc9c80fe01a2 ("drm/syncobj: use the timeline point in drm_syncobj_find_fence v4") Reviewed-by: Christian König Cc: Christian König Cc: Lionel Landwerlin Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Cc: # v5.2+ Link: https://patchwork.freedesktop.org/patch/msgid/20210119130318.615145-1-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman commit 559c0ffedbe0b1dfd5c7e8c7c4e2761239a18293 Author: Pan Bian Date: Tue Jan 19 04:11:27 2021 -0800 drm/atomic: put state on error path commit 43b67309b6b2a3c08396cc9b3f83f21aa529d273 upstream. Put the state before returning error code. Fixes: 44596b8c4750 ("drm/atomic: Unify conflicting encoder handling.") Signed-off-by: Pan Bian Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20210119121127.84127-1-bianpan2016@163.com Signed-off-by: Greg Kroah-Hartman commit 42d855f06d128fa4841df01f9017a9bbfe3ab074 Author: Mikulas Patocka Date: Wed Jan 20 06:02:31 2021 -0500 dm integrity: fix a crash if "recalculate" used without "internal_hash" commit 2d06dfecb132a1cc2e374a44eae83b5c4356b8b4 upstream. Recalculate can only be specified with internal_hash. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit a03ce9cc4bb880a27a42987b378b044a6d207b8b Author: Hannes Reinecke Date: Thu Jan 21 18:50:56 2021 +0100 dm: avoid filesystem lookup in dm_get_dev_t() commit 809b1e4945774c9ec5619a8f4e2189b7b3833c0c upstream. This reverts commit 644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()") dm_get_dev_t() is just used to convert an arbitrary 'path' string into a dev_t. It doesn't presume that the device is present; that check will be done later, as the only caller is dm_get_device(), which does a dm_get_table_device() later on, which will properly open the device. So if the path string already _is_ in major:minor representation we can convert it directly, avoiding a recursion into the filesystem to lookup the block device. This avoids a hang in multipath_message() when the filesystem is inaccessible. Fixes: 644bda6f3460 ("dm table: fall back to getting device using name_to_dev_t()") Cc: stable@vger.kernel.org Signed-off-by: Hannes Reinecke Signed-off-by: Martin Wilck Reviewed-by: Christoph Hellwig Signed-off-by: Mike Snitzer Signed-off-by: Greg Kroah-Hartman commit cd3aa1495d8a6ca237449f3c6c0609d3e4122112 Author: Alex Leibovich Date: Fri Dec 11 15:16:56 2020 +0100 mmc: sdhci-xenon: fix 1.8v regulator stabilization commit 1a3ed0dc3594d99ff341ec63865a40519ea24b8d upstream. Automatic Clock Gating is a feature used for the power consumption optimisation. It turned out that during early init phase it may prevent the stable voltage switch to 1.8V - due to that on some platforms an endless printout in dmesg can be observed: "mmc1: 1.8V regulator output did not became stable" Fix the problem by disabling the ACG at very beginning of the sdhci_init and let that be enabled later. Fixes: 3a3748dba881 ("mmc: sdhci-xenon: Add Marvell Xenon SDHC core functionality") Signed-off-by: Alex Leibovich Signed-off-by: Marcin Wojtas Cc: stable@vger.kernel.org Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20201211141656.24915-1-mw@semihalf.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 6acdefd0bd34390abf2cc2ec4390673b0093f812 Author: Peter Collingbourne Date: Thu Jan 14 12:14:05 2021 -0800 mmc: core: don't initialize block size from ext_csd if not present commit b503087445ce7e45fabdee87ca9e460d5b5b5168 upstream. If extended CSD was not available, the eMMC driver would incorrectly set the block size to 0, as the data_sector_size field of ext_csd was never initialized. This issue was exposed by commit 817046ecddbc ("block: Align max_hw_sectors to logical blocksize") which caused max_sectors and max_hw_sectors to be set to 0 after setting the block size to 0, resulting in a kernel panic in bio_split when attempting to read from the device. Fix it by only reading the block size from ext_csd if it is available. Fixes: a5075eb94837 ("mmc: block: Allow disabling 512B sector size emulation") Signed-off-by: Peter Collingbourne Reviewed-by: Damien Le Moal Link: https://linux-review.googlesource.com/id/If244d178da4d86b52034459438fec295b02d6e60 Acked-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210114201405.2934886-1-pcc@google.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d8a487e673abf46c69c901bb25da54e9bc7ba45e Author: Filipe Manana Date: Mon Jan 11 11:41:42 2021 +0000 btrfs: send: fix invalid clone operations when cloning from the same file and root commit 518837e65068c385dddc0a87b3e577c8be7c13b1 upstream. When an incremental send finds an extent that is shared, it checks which file extent items in the range refer to that extent, and for those it emits clone operations, while for others it emits regular write operations to avoid corruption at the destination (as described and fixed by commit d906d49fc5f4 ("Btrfs: send, fix file corruption due to incorrect cloning operations")). However when the root we are cloning from is the send root, we are cloning from the inode currently being processed and the source file range has several extent items that partially point to the desired extent, with an offset smaller than the offset in the file extent item for the range we want to clone into, it can cause the algorithm to issue a clone operation that starts at the current eof of the file being processed in the receiver side, in which case the receiver will fail, with EINVAL, when attempting to execute the clone operation. Example reproducer: $ cat test-send-clone.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi mkfs.btrfs -f $DEV >/dev/null mount $DEV $MNT # Create our test file with a single and large extent (1M) and with # different content for different file ranges that will be reflinked # later. xfs_io -f \ -c "pwrite -S 0xab 0 128K" \ -c "pwrite -S 0xcd 128K 128K" \ -c "pwrite -S 0xef 256K 256K" \ -c "pwrite -S 0x1a 512K 512K" \ $MNT/foobar btrfs subvolume snapshot -r $MNT $MNT/snap1 btrfs send -f /tmp/snap1.send $MNT/snap1 # Now do a series of changes to our file such that we end up with # different parts of the extent reflinked into different file offsets # and we overwrite a large part of the extent too, so no file extent # items refer to that part that was overwritten. This used to confuse # the algorithm used by the kernel to figure out which file ranges to # clone, making it attempt to clone from a source range starting at # the current eof of the file, resulting in the receiver to fail since # it is an invalid clone operation. # xfs_io -c "reflink $MNT/foobar 64K 1M 960K" \ -c "reflink $MNT/foobar 0K 512K 256K" \ -c "reflink $MNT/foobar 512K 128K 256K" \ -c "pwrite -S 0x73 384K 640K" \ $MNT/foobar btrfs subvolume snapshot -r $MNT $MNT/snap2 btrfs send -f /tmp/snap2.send -p $MNT/snap1 $MNT/snap2 echo -e "\nFile digest in the original filesystem:" md5sum $MNT/snap2/foobar # Now unmount the filesystem, create a new one, mount it and try to # apply both send streams to recreate both snapshots. umount $DEV mkfs.btrfs -f $DEV >/dev/null mount $DEV $MNT btrfs receive -f /tmp/snap1.send $MNT btrfs receive -f /tmp/snap2.send $MNT # Must match what we got in the original filesystem of course. echo -e "\nFile digest in the new filesystem:" md5sum $MNT/snap2/foobar umount $MNT When running the reproducer, the incremental send operation fails due to an invalid clone operation: $ ./test-send-clone.sh wrote 131072/131072 bytes at offset 0 128 KiB, 32 ops; 0.0015 sec (80.906 MiB/sec and 20711.9741 ops/sec) wrote 131072/131072 bytes at offset 131072 128 KiB, 32 ops; 0.0013 sec (90.514 MiB/sec and 23171.6148 ops/sec) wrote 262144/262144 bytes at offset 262144 256 KiB, 64 ops; 0.0025 sec (98.270 MiB/sec and 25157.2327 ops/sec) wrote 524288/524288 bytes at offset 524288 512 KiB, 128 ops; 0.0052 sec (95.730 MiB/sec and 24506.9883 ops/sec) Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap1' At subvol /mnt/sdi/snap1 linked 983040/983040 bytes at offset 1048576 960 KiB, 1 ops; 0.0006 sec (1.419 GiB/sec and 1550.3876 ops/sec) linked 262144/262144 bytes at offset 524288 256 KiB, 1 ops; 0.0020 sec (120.192 MiB/sec and 480.7692 ops/sec) linked 262144/262144 bytes at offset 131072 256 KiB, 1 ops; 0.0018 sec (133.833 MiB/sec and 535.3319 ops/sec) wrote 655360/655360 bytes at offset 393216 640 KiB, 160 ops; 0.0093 sec (66.781 MiB/sec and 17095.8436 ops/sec) Create a readonly snapshot of '/mnt/sdi' in '/mnt/sdi/snap2' At subvol /mnt/sdi/snap2 File digest in the original filesystem: 9c13c61cb0b9f5abf45344375cb04dfa /mnt/sdi/snap2/foobar At subvol snap1 At snapshot snap2 ERROR: failed to clone extents to foobar: Invalid argument File digest in the new filesystem: 132f0396da8f48d2e667196bff882cfc /mnt/sdi/snap2/foobar The clone operation is invalid because its source range starts at the current eof of the file in the receiver, causing the receiver to get an EINVAL error from the clone operation when attempting it. For the example above, what happens is the following: 1) When processing the extent at file offset 1M, the algorithm checks that the extent is shared and can be (fully or partially) found at file offset 0. At this point the file has a size (and eof) of 1M at the receiver; 2) It finds that our extent item at file offset 1M has a data offset of 64K and, since the file extent item at file offset 0 has a data offset of 0, it issues a clone operation, from the same file and root, that has a source range offset of 64K, destination offset of 1M and a length of 64K, since the extent item at file offset 0 refers only to the first 128K of the shared extent. After this clone operation, the file size (and eof) at the receiver is increased from 1M to 1088K (1M + 64K); 3) Now there's still 896K (960K - 64K) of data left to clone or write, so it checks for the next file extent item, which starts at file offset 128K. This file extent item has a data offset of 0 and a length of 256K, so a clone operation with a source range offset of 256K, a destination offset of 1088K (1M + 64K) and length of 128K is issued. After this operation the file size (and eof) at the receiver increases from 1088K to 1216K (1088K + 128K); 4) Now there's still 768K (896K - 128K) of data left to clone or write, so it checks for the next file extent item, located at file offset 384K. This file extent item points to a different extent, not the one we want to clone, with a length of 640K. So we issue a write operation into the file range 1216K (1088K + 128K, end of the last clone operation), with a length of 640K and with a data matching the one we can find for that range in send root. After this operation, the file size (and eof) at the receiver increases from 1216K to 1856K (1216K + 640K); 5) Now there's still 128K (768K - 640K) of data left to clone or write, so we look into the file extent item, which is for file offset 1M and it points to the extent we want to clone, with a data offset of 64K and a length of 960K. However this matches the file offset we started with, the start of the range to clone into. So we can't for sure find any file extent item from here onwards with the rest of the data we want to clone, yet we proceed and since the file extent item points to the shared extent, with a data offset of 64K, we issue a clone operation with a source range starting at file offset 1856K, which matches the file extent item's offset, 1M, plus the amount of data cloned and written so far, which is 64K (step 2) + 128K (step 3) + 640K (step 4). This clone operation is invalid since the source range offset matches the current eof of the file in the receiver. We should have stopped looking for extents to clone at this point and instead fallback to write, which would simply the contain the data in the file range from 1856K to 1856K + 128K. So fix this by stopping the loop that looks for file ranges to clone at clone_range() when we reach the current eof of the file being processed, if we are cloning from the same file and using the send root as the clone root. This ensures any data not yet cloned will be sent to the receiver through a write operation. A test case for fstests will follow soon. Reported-by: Massimo B. Link: https://lore.kernel.org/linux-btrfs/6ae34776e85912960a253a8327068a892998e685.camel@gmx.net/ Fixes: 11f2069c113e ("Btrfs: send, allow clone operations within the same file") CC: stable@vger.kernel.org # 5.5+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 4d1cf8eeda5b3f411440d9910a484b1d06484aa7 Author: Josef Bacik Date: Wed Dec 16 11:22:17 2020 -0500 btrfs: don't clear ret in btrfs_start_dirty_block_groups commit 34d1eb0e599875064955a74712f08ff14c8e3d5f upstream. If we fail to update a block group item in the loop we'll break, however we'll do btrfs_run_delayed_refs and lose our error value in ret, and thus not clean up properly. Fix this by only running the delayed refs if there was no failure. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit e1065331b730864b4cee6fbb60e6a1d2f44482c8 Author: Josef Bacik Date: Wed Dec 16 11:22:14 2020 -0500 btrfs: fix lockdep splat in btrfs_recover_relocation commit fb286100974e7239af243bc2255a52f29442f9c8 upstream. While testing the error paths of relocation I hit the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.10.0-rc6+ #217 Not tainted ------------------------------------------------------ mount/779 is trying to acquire lock: ffffa0e676945418 (&fs_info->balance_mutex){+.+.}-{3:3}, at: btrfs_recover_balance+0x2f0/0x340 but task is already holding lock: ffffa0e60ee31da8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x100 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (btrfs-root-00){++++}-{3:3}: down_read_nested+0x43/0x130 __btrfs_tree_read_lock+0x27/0x100 btrfs_read_lock_root_node+0x31/0x40 btrfs_search_slot+0x462/0x8f0 btrfs_update_root+0x55/0x2b0 btrfs_drop_snapshot+0x398/0x750 clean_dirty_subvols+0xdf/0x120 btrfs_recover_relocation+0x534/0x5a0 btrfs_start_pre_rw_mount+0xcb/0x170 open_ctree+0x151f/0x1726 btrfs_mount_root.cold+0x12/0xea legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 path_mount+0x433/0xc10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #1 (sb_internal#2){.+.+}-{0:0}: start_transaction+0x444/0x700 insert_balance_item.isra.0+0x37/0x320 btrfs_balance+0x354/0xf40 btrfs_ioctl_balance+0x2cf/0x380 __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 -> #0 (&fs_info->balance_mutex){+.+.}-{3:3}: __lock_acquire+0x1120/0x1e10 lock_acquire+0x116/0x370 __mutex_lock+0x7e/0x7b0 btrfs_recover_balance+0x2f0/0x340 open_ctree+0x1095/0x1726 btrfs_mount_root.cold+0x12/0xea legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 path_mount+0x433/0xc10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 other info that might help us debug this: Chain exists of: &fs_info->balance_mutex --> sb_internal#2 --> btrfs-root-00 Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(btrfs-root-00); lock(sb_internal#2); lock(btrfs-root-00); lock(&fs_info->balance_mutex); *** DEADLOCK *** 2 locks held by mount/779: #0: ffffa0e60dc040e0 (&type->s_umount_key#47/1){+.+.}-{3:3}, at: alloc_super+0xb5/0x380 #1: ffffa0e60ee31da8 (btrfs-root-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x27/0x100 stack backtrace: CPU: 0 PID: 779 Comm: mount Not tainted 5.10.0-rc6+ #217 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x8b/0xb0 check_noncircular+0xcf/0xf0 ? trace_call_bpf+0x139/0x260 __lock_acquire+0x1120/0x1e10 lock_acquire+0x116/0x370 ? btrfs_recover_balance+0x2f0/0x340 __mutex_lock+0x7e/0x7b0 ? btrfs_recover_balance+0x2f0/0x340 ? btrfs_recover_balance+0x2f0/0x340 ? rcu_read_lock_sched_held+0x3f/0x80 ? kmem_cache_alloc_trace+0x2c4/0x2f0 ? btrfs_get_64+0x5e/0x100 btrfs_recover_balance+0x2f0/0x340 open_ctree+0x1095/0x1726 btrfs_mount_root.cold+0x12/0xea ? rcu_read_lock_sched_held+0x3f/0x80 legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 vfs_kern_mount.part.0+0x71/0xb0 btrfs_mount+0x10d/0x380 ? __kmalloc_track_caller+0x2f2/0x320 legacy_get_tree+0x30/0x50 vfs_get_tree+0x28/0xc0 ? capable+0x3a/0x60 path_mount+0x433/0xc10 __x64_sys_mount+0xe3/0x120 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This is straightforward to fix, simply release the path before we setup the balance_ctl. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Qu Wenruo Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 68718453159ef860c067c7e326282a23379c0a45 Author: Josef Bacik Date: Wed Dec 16 11:22:05 2020 -0500 btrfs: don't get an EINTR during drop_snapshot for reloc commit 18d3bff411c8d46d40537483bdc0b61b33ce0371 upstream. This was partially fixed by f3e3d9cc3525 ("btrfs: avoid possible signal interruption of btrfs_drop_snapshot() on relocation tree"), however it missed a spot when we restart a trans handle because we need to end the transaction. The fix is the same, simply use btrfs_join_transaction() instead of btrfs_start_transaction() when deleting reloc roots. Fixes: f3e3d9cc3525 ("btrfs: avoid possible signal interruption of btrfs_drop_snapshot() on relocation tree") CC: stable@vger.kernel.org # 5.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit a826af1dea4ab8963ef8b909c1f7f24130b0819e Author: Hans de Goede Date: Fri Jan 15 22:57:52 2021 +0100 ACPI: scan: Make acpi_bus_get_device() clear return pointer on error commit 78a18fec5258c8df9435399a1ea022d73d3eceb9 upstream. Set the acpi_device pointer which acpi_bus_get_device() returns-by- reference to NULL on errors. We've recently had 2 cases where callers of acpi_bus_get_device() did not properly error check the return value, so set the returned- by-reference acpi_device pointer to NULL, because at least some callers of acpi_bus_get_device() expect that to be done on errors. [ rjw: This issue was exposed by commit 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists") which caused it to be much more likely to occur on some systems, but the real defect had been introduced by an earlier commit. ] Fixes: 40e7fcb19293 ("ACPI: Add _DEP support to fix battery issue on Asus T100TA") Fixes: bcfcd409d4db ("usb: split code locating ACPI companion into port and device") Reported-by: Pierre-Louis Bossart Tested-by: Pierre-Louis Bossart Diagnosed-by: Rafael J. Wysocki Signed-off-by: Hans de Goede Cc: All applicable [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 08fa4ae93e95ec920dcf7f0b5c6ab2d7cb2b5167 Author: Takashi Iwai Date: Thu Jan 14 08:24:53 2021 +0100 ALSA: hda/via: Add minimum mute flag commit 67ea698c3950d10925be33c21ca49ffb64e21842 upstream. It turned out that VIA codecs also mute the sound in the lowest mixer level. Turn on the dac_min_mute flag to indicate the mute-as-minimum in TLV like already done in Conexant and IDT codecs. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=210559 Cc: Link: https://lore.kernel.org/r/20210114072453.11379-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1607adf1ac413927b6fe19963ebdb52cf9664d9f Author: Takashi Iwai Date: Fri Jan 15 10:34:28 2021 +0100 ALSA: seq: oss: Fix missing error check in snd_seq_oss_synth_make_info() commit 217bfbb8b0bfa24619b11ab75c135fec99b99b20 upstream. snd_seq_oss_synth_make_info() didn't check the error code from snd_seq_oss_midi_make_info(), and this leads to the call of strlcpy() with the uninitialized string as the source, which may lead to the access over the limit. Add the proper error check for avoiding the failure. Reported-by: syzbot+e42504ff21cff05a595f@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20210115093428.15882-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 9c301133bedaf79997c4baf822baa27616250fb5 Author: Jiaxun Yang Date: Thu Jan 7 22:44:38 2021 +0800 platform/x86: ideapad-laptop: Disable touchpad_switch for ELAN0634 commit f419e5940f1d9892ea6f45acdaca572b9e73ff39 upstream. Newer ideapads (e.g.: Yoga 14s, 720S 14) come with ELAN0634 touchpad do not use EC to switch touchpad. Reading VPCCMD_R_TOUCHPAD will return zero thus touchpad may be blocked unexpectedly. Writing VPCCMD_W_TOUCHPAD may cause a spurious key press. Add has_touchpad_switch to workaround these machines. Signed-off-by: Jiaxun Yang Cc: stable@vger.kernel.org # 5.4+ -- v2: Specify touchpad to ELAN0634 v3: Stupid missing ! in v2 v4: Correct acpi_dev_present usage (Hans) Link: https://lore.kernel.org/r/20210107144438.12605-1-jiaxun.yang@flygoat.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit ea8d3c71313f35d62ae86dcbe2ec6b499f15a418 Author: Heikki Krogerus Date: Wed Dec 23 17:36:44 2020 +0300 platform/x86: i2c-multi-instantiate: Don't create platform device for INT3515 ACPI nodes commit 9bba96275576da0cf78ede62aeb2fc975ed8a32d upstream. There are several reports about the tps6598x causing interrupt flood on boards with the INT3515 ACPI node, which then causes instability. There appears to be several problems with the interrupt. One problem is that the I2CSerialBus resources do not always map to the Interrupt resource with the same index, but that is not the only problem. We have not been able to come up with a solution for all the issues, and because of that disabling the device for now. The PD controller on these platforms is autonomous, and the purpose for the driver is primarily to supply status to the userspace, so this will not affect any functionality. Reported-by: Moody Salem Fixes: a3dd034a1707 ("ACPI / scan: Create platform device for INT3515 ACPI nodes") Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1883511 Signed-off-by: Heikki Krogerus Link: https://lore.kernel.org/r/20201223143644.33341-1-heikki.krogerus@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Greg Kroah-Hartman commit 60066d5181be6448def7e97b9ad0fc2741f6c1bb Author: Mikko Perttunen Date: Tue Jan 12 12:22:25 2021 +0200 i2c: bpmp-tegra: Ignore unknown I2C_M flags commit bc1c2048abbe3c3074b4de91d213595c57741a6b upstream. In order to not to start returning errors when new I2C_M flags are added, change behavior to just ignore all flags that we don't know about. This includes the I2C_M_DMA_SAFE flag that already exists but causes -EINVAL to be returned for valid transactions. Cc: stable@vger.kernel.org # v4.19+ Signed-off-by: Mikko Perttunen Signed-off-by: Wolfram Sang Signed-off-by: Greg Kroah-Hartman