commit 8d6b541290cb9293bd2a7bb00c1d58d01abe183b Author: Greg Kroah-Hartman Date: Fri Jul 31 16:44:08 2020 +0200 Linux 4.9.232 Signed-off-by: Greg Kroah-Hartman commit eef50fa1f4dbaf3686290769e8e6cbbc358a6eaa Author: Changbin Du Date: Tue Jun 30 23:46:07 2020 +0900 perf: Make perf able to build with latest libbfd commit 0ada120c883d4f1f6aafd01cf0fbb10d8bbba015 upstream. libbfd has changed the bfd_section_* macros to inline functions bfd_section_ since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: Changbin Du Acked-by: Jiri Olsa Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit f578600eba26b94388968fa8cb2144606ca58b41 Author: Jiri Olsa Date: Tue Jun 30 23:45:58 2020 +0900 perf tools: Fix snprint warnings for gcc 8 commit 77f18153c080855e1c3fb520ca31a4e61530121d upstream. [Add an additional sprintf replacement in tools/perf/builtin-script.c] With gcc 8 we get new set of snprintf() warnings that breaks the compilation, one example: tests/mem.c: In function ‘check’: tests/mem.c:19:48: error: ‘%s’ directive output may be truncated writing \ up to 99 bytes into a region of size 89 [-Werror=format-truncation=] snprintf(failure, sizeof failure, "unexpected %s", out); The gcc docs says: To avoid the warning either use a bigger buffer or handle the function's return value which indicates whether or not its output has been truncated. Given that all these warnings are harmless, because the code either properly fails due to uncomplete file path or we don't care for truncated output at all, I'm changing all those snprintf() calls to scnprintf(), which actually 'checks' for the snprint return value so the gcc stays silent. Signed-off-by: Jiri Olsa Cc: Alexander Shishkin Cc: David Ahern Cc: Josh Poimboeuf Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Sergey Senozhatsky Link: http://lkml.kernel.org/r/20180319082902.4518-1-jolsa@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 666fe39b0e7d0242f3fd3eac2af7e8b901a0db53 Author: Arnaldo Carvalho de Melo Date: Tue Jun 30 23:45:49 2020 +0900 perf annotate: Use asprintf when formatting objdump command line commit 6810158d526e483868e519befff407b91e76b3db upstream. We were using a local buffer with an arbitrary size, that would have to get increased to avoid truncation as warned by gcc 8: util/annotate.c: In function 'symbol__disassemble': util/annotate.c:1488:4: error: '%s' directive output may be truncated writing up to 4095 bytes into a region of size between 3966 and 8086 [-Werror=format-truncation=] "%s %s%s --start-address=0x%016" PRIx64 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ util/annotate.c:1498:20: symfs_filename, symfs_filename); ~~~~~~~~~~~~~~ util/annotate.c:1490:50: note: format string is defined here " -l -d %s %s -C \"%s\" 2>/dev/null|grep -v \"%s:\"|expand", ^~ In file included from /usr/include/stdio.h:861, from util/color.h:5, from util/sort.h:8, from util/annotate.c:14: /usr/include/bits/stdio2.h:67:10: note: '__builtin___snprintf_chk' output 116 or more bytes (assuming 8331) into a destination of size 8192 return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ __bos (__s), __fmt, __va_arg_pack ()); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ So switch to asprintf, that will make sure enough space is available. Cc: Adrian Hunter Cc: David Ahern Cc: Jin Yao Cc: Jiri Olsa Cc: Namhyung Kim Cc: Wang Nan Link: https://lkml.kernel.org/n/tip-qagoy2dmbjpc9gdnaj0r3mml@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 045c228b26f57376160d30458fb84b565420d247 Author: Masami Hiramatsu Date: Tue Jun 30 23:45:40 2020 +0900 perf probe: Fix to check blacklist address correctly commit 80526491c2ca6abc028c0f0dbb0707a1f35fb18a upstream. Fix to check kprobe blacklist address correctly with relocated address by adjusting debuginfo address. Since the address in the debuginfo is same as objdump, it is different from relocated kernel address with KASLR. Thus, 'perf probe' always misses to catch the blacklisted addresses. Without this patch, 'perf probe' can not detect the blacklist addresses on a KASLR enabled kernel. # perf probe kprobe_dispatcher Failed to write event: Invalid argument Error: Failed to add events. # With this patch, it correctly shows the error message. # perf probe kprobe_dispatcher kprobe_dispatcher is blacklisted function, skip it. Probe point 'kprobe_dispatcher' not found. Error: Failed to add events. # Fixes: 9aaf5a5f479b ("perf probe: Check kprobes blacklist when adding new events") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Cc: stable@vger.kernel.org Link: http://lore.kernel.org/lkml/158763966411.30755.5882376357738273695.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Greg Kroah-Hartman commit 8e5f820e14e93ebfc7fcf2a099817eb9c7c3be04 Author: Eric Sandeen Date: Mon Apr 16 23:07:27 2018 -0700 xfs: set format back to extents if xfs_bmap_extents_to_btree commit 2c4306f719b083d17df2963bc761777576b8ad1b upstream. If xfs_bmap_extents_to_btree fails in a mode where we call xfs_iroot_realloc(-1) to de-allocate the root, set the format back to extents. Otherwise we can assume we can dereference ifp->if_broot based on the XFS_DINODE_FMT_BTREE format, and crash. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199423 Signed-off-by: Eric Sandeen Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Nobuhiro Iwamatsu (CIP) Signed-off-by: Greg Kroah-Hartman commit 65cddd579e3ce9d5a060a693722e964c4ce33b31 Author: Peng Fan Date: Fri Mar 13 09:58:07 2020 +0800 regmap: debugfs: check count when read regmap file commit 74edd08a4fbf51d65fd8f4c7d8289cd0f392bd91 upstream. When executing the following command, we met kernel dump. dmesg -c > /dev/null; cd /sys; for i in `ls /sys/kernel/debug/regmap/* -d`; do echo "Checking regmap in $i"; cat $i/registers; done && grep -ri "0x02d0" *; It is because the count value is too big, and kmalloc fails. So add an upper bound check to allow max size `PAGE_SIZE << (MAX_ORDER - 1)`. Signed-off-by: Peng Fan Link: https://lore.kernel.org/r/1584064687-12964-1-git-send-email-peng.fan@nxp.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4effbbdc8cf07cba01ca3eacea2a86ae19b4fc73 Author: Xie He Date: Thu Jul 16 16:44:33 2020 -0700 drivers/net/wan/x25_asy: Fix to make it work [ Upstream commit 8fdcabeac39824fe67480fd9508d80161c541854 ] This driver is not working because of problems of its receiving code. This patch fixes it to make it work. When the driver receives an LAPB frame, it should first pass the frame to the LAPB module to process. After processing, the LAPB module passes the data (the packet) back to the driver, the driver should then add a one-byte pseudo header and pass the data to upper layers. The changes to the "x25_asy_bump" function and the "x25_asy_data_indication" function are to correctly implement this procedure. Also, the "x25_asy_unesc" function ignores any frame that is shorter than 3 bytes. However the shortest frames are 2-byte long. So we need to change it to allow 2-byte frames to pass. Cc: Eric Dumazet Cc: Martin Schiller Signed-off-by: Xie He Reviewed-by: Martin Schiller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 479be5229bd8da5489aef7fcfad50fcd417bc58f Author: Wei Yongjun Date: Mon Jul 13 23:59:50 2020 +0800 ip6_gre: fix null-ptr-deref in ip6gre_init_net() [ Upstream commit 46ef5b89ec0ecf290d74c4aee844f063933c4da4 ] KASAN report null-ptr-deref error when register_netdev() failed: KASAN: null-ptr-deref in range [0x00000000000003c0-0x00000000000003c7] CPU: 2 PID: 422 Comm: ip Not tainted 5.8.0-rc4+ #12 Call Trace: ip6gre_init_net+0x4ab/0x580 ? ip6gre_tunnel_uninit+0x3f0/0x3f0 ops_init+0xa8/0x3c0 setup_net+0x2de/0x7e0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? ops_init+0x3c0/0x3c0 ? kasan_unpoison_shadow+0x33/0x40 ? __kasan_kmalloc.constprop.0+0xc2/0xd0 copy_net_ns+0x27d/0x530 create_new_namespaces+0x382/0xa30 unshare_nsproxy_namespaces+0xa1/0x1d0 ksys_unshare+0x39c/0x780 ? walk_process_tree+0x2a0/0x2a0 ? trace_hardirqs_on+0x4a/0x1b0 ? _raw_spin_unlock_irq+0x1f/0x30 ? syscall_trace_enter+0x1a7/0x330 ? do_syscall_64+0x1c/0xa0 __x64_sys_unshare+0x2d/0x40 do_syscall_64+0x56/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 ip6gre_tunnel_uninit() has set 'ign->fb_tunnel_dev' to NULL, later access to ign->fb_tunnel_dev cause null-ptr-deref. Fix it by saving 'ign->fb_tunnel_dev' to local variable ndev. Fixes: dafabb6590cb ("ip6_gre: fix use-after-free in ip6gre_tunnel_lookup()") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 35c3c8f01ca0d7cbff4199100c322ea886d026b7 Author: Yuchung Cheng Date: Thu Jul 23 12:00:06 2020 -0700 tcp: allow at most one TLP probe per flight [ Upstream commit 76be93fc0702322179bb0ea87295d820ee46ad14 ] Previously TLP may send multiple probes of new data in one flight. This happens when the sender is cwnd limited. After the initial TLP containing new data is sent, the sender receives another ACK that acks partial inflight. It may re-arm another TLP timer to send more, if no further ACK returns before the next TLP timeout (PTO) expires. The sender may send in theory a large amount of TLP until send queue is depleted. This only happens if the sender sees such irregular uncommon ACK pattern. But it is generally undesirable behavior during congestion especially. The original TLP design restrict only one TLP probe per inflight as published in "Reducing Web Latency: the Virtue of Gentle Aggression", SIGCOMM 2013. This patch changes TLP to send at most one probe per inflight. Note that if the sender is app-limited, TLP retransmits old data and did not have this issue. Signed-off-by: Yuchung Cheng Signed-off-by: Neal Cardwell Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 15a9765cf8dd9373913af7663fd51df6e7151d5e Author: Dan Carpenter Date: Thu Jul 23 17:49:57 2020 +0300 AX.25: Prevent integer overflows in connect and sendmsg [ Upstream commit 17ad73e941b71f3bec7523ea4e9cbc3752461c2d ] We recently added some bounds checking in ax25_connect() and ax25_sendmsg() and we so we removed the AX25_MAX_DIGIS checks because they were no longer required. Unfortunately, I believe they are required to prevent integer overflows so I have added them back. Fixes: 8885bb0621f0 ("AX.25: Prevent out-of-bounds read in ax25_sendmsg()") Fixes: 2f2a7ffad5c6 ("AX.25: Fix out-of-bounds read in ax25_connect()") Signed-off-by: Dan Carpenter Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3a74e2808eba19e42249f183e6a12450d3f00d54 Author: David Howells Date: Mon Jul 20 12:41:46 2020 +0100 rxrpc: Fix sendmsg() returning EPIPE due to recvmsg() returning ENODATA [ Upstream commit 639f181f0ee20d3249dbc55f740f0167267180f0 ] rxrpc_sendmsg() returns EPIPE if there's an outstanding error, such as if rxrpc_recvmsg() indicating ENODATA if there's nothing for it to read. Change rxrpc_recvmsg() to return EAGAIN instead if there's nothing to read as this particular error doesn't get stored in ->sk_err by the networking core. Also change rxrpc_sendmsg() so that it doesn't fail with delayed receive errors (there's no way for it to report which call, if any, the error was caused by). Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both") Signed-off-by: David Howells Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit feed32a3a405a1616f0e31a1b165757ccce8d565 Author: Miaohe Lin Date: Tue Jul 21 17:11:44 2020 +0800 net: udp: Fix wrong clean up for IS_UDPLITE macro [ Upstream commit b0a422772fec29811e293c7c0e6f991c0fd9241d ] We can't use IS_UDPLITE to replace udp_sk->pcflag when UDPLITE_RECV_CC is checked. Fixes: b2bf1e2659b1 ("[UDP]: Clean up for IS_UDPLITE macro") Signed-off-by: Miaohe Lin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c0e3a9a4c4c96b4b2ebaaa198404a601f201ee5b Author: Xiongfeng Wang Date: Tue Jul 21 15:02:57 2020 +0800 net-sysfs: add a newline when printing 'tx_timeout' by sysfs [ Upstream commit 9bb5fbea59f36a589ef886292549ca4052fe676c ] When I cat 'tx_timeout' by sysfs, it displays as follows. It's better to add a newline for easy reading. root@syzkaller:~# cat /sys/devices/virtual/net/lo/queues/tx-0/tx_timeout 0root@syzkaller:~# Signed-off-by: Xiongfeng Wang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b7441315b8d2b25a2bdcc71957148b8ad843955a Author: Subash Abhinov Kasiviswanathan Date: Thu Jul 23 11:31:48 2020 -0600 dev: Defer free of skbs in flush_backlog [ Upstream commit 7df5cb75cfb8acf96c7f2342530eb41e0c11f4c3 ] IRQs are disabled when freeing skbs in input queue. Use the IRQ safe variant to free skbs here. Fixes: 145dd5f9c88f ("net: flush the softnet backlog in process context") Signed-off-by: Subash Abhinov Kasiviswanathan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8b097fc4484fc169e333ede5310ee4e9aed89e2e Author: Peilin Ye Date: Wed Jul 22 12:05:12 2020 -0400 AX.25: Prevent out-of-bounds read in ax25_sendmsg() [ Upstream commit 8885bb0621f01a6c82be60a91e5fc0f6e2f71186 ] Checks on `addr_len` and `usax->sax25_ndigis` are insufficient. ax25_sendmsg() can go out of bounds when `usax->sax25_ndigis` equals to 7 or 8. Fix it. It is safe to remove `usax->sax25_ndigis > AX25_MAX_DIGIS`, since `addr_len` is guaranteed to be less than or equal to `sizeof(struct full_sockaddr_ax25)` Signed-off-by: Peilin Ye Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9aaa5f94050e7cddb4f19bb3d8f25a7589c974dd Author: Peilin Ye Date: Wed Jul 22 11:19:01 2020 -0400 AX.25: Fix out-of-bounds read in ax25_connect() [ Upstream commit 2f2a7ffad5c6cbf3d438e813cfdc88230e185ba6 ] Checks on `addr_len` and `fsa->fsa_ax25.sax25_ndigis` are insufficient. ax25_connect() can go out of bounds when `fsa->fsa_ax25.sax25_ndigis` equals to 7 or 8. Fix it. This issue has been reported as a KMSAN uninit-value bug, because in such a case, ax25_connect() reaches into the uninitialized portion of the `struct sockaddr_storage` statically allocated in __sys_connect(). It is safe to remove `fsa->fsa_ax25.sax25_ndigis > AX25_MAX_DIGIS` because `addr_len` is guaranteed to be less than or equal to `sizeof(struct full_sockaddr_ax25)`. Reported-by: syzbot+c82752228ed975b0a623@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?id=55ef9d629f3b3d7d70b69558015b63b48d01af66 Signed-off-by: Peilin Ye Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6f02463c52d5f431043d63d3c541ca0780735465 Author: Mark O'Donovan Date: Sat Jul 11 05:33:24 2020 +0100 ath9k: Fix regression with Atheros 9271 commit 92f53e2fda8bb9a559ad61d57bfb397ce67ed0ab upstream. This fix allows ath9k_htc modules to connect to WLAN once again. Fixes: 2bbcaaee1fcb ("ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb") Link: https://bugzilla.kernel.org/show_bug.cgi?id=208251 Signed-off-by: Mark O'Donovan Reported-by: Roman Mamedov Tested-by: Viktor Jägersküpper Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200711043324.8079-1-shiftee@posteo.net Signed-off-by: Greg Kroah-Hartman commit a70c4a2f2512313c8f7fe4bd1156318338477a7f Author: Qiujun Huang Date: Sat Apr 4 12:18:38 2020 +0800 ath9k: Fix general protection fault in ath9k_hif_usb_rx_cb commit 2bbcaaee1fcbd83272e29f31e2bb7e70d8c49e05 upstream. In ath9k_hif_usb_rx_cb interface number is assumed to be 0. usb_ifnum_to_if(urb->dev, 0) But it isn't always true. The case reported by syzbot: https://lore.kernel.org/linux-usb/000000000000666c9c05a1c05d12@google.com usb 2-1: new high-speed USB device number 2 using dummy_hcd usb 2-1: config 1 has an invalid interface number: 2 but max is 0 usb 2-1: config 1 has no interface number 0 usb 2-1: New USB device found, idVendor=0cf3, idProduct=9271, bcdDevice= 1.08 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 general protection fault, probably for non-canonical address 0xdffffc0000000015: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000a8-0x00000000000000af] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.6.0-rc5-syzkaller #0 Call Trace __usb_hcd_giveback_urb+0x29a/0x550 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x368/0x420 drivers/usb/core/hcd.c:1716 dummy_timer+0x1258/0x32ae drivers/usb/gadget/udc/dummy_hcd.c:1966 call_timer_fn+0x195/0x6f0 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers kernel/time/timer.c:1773 [inline] __run_timers kernel/time/timer.c:1740 [inline] run_timer_softirq+0x5f9/0x1500 kernel/time/timer.c:1786 __do_softirq+0x21e/0x950 kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x178/0x1a0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:546 [inline] smp_apic_timer_interrupt+0x141/0x540 arch/x86/kernel/apic/apic.c:1146 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829 Reported-and-tested-by: syzbot+40d5d2e8a4680952f042@syzkaller.appspotmail.com Signed-off-by: Qiujun Huang Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20200404041838.10426-6-hqjagain@gmail.com Cc: Viktor Jägersküpper Signed-off-by: Greg Kroah-Hartman commit 518d1af92be83193a44ff279ea10734ffc3b3895 Author: John David Anglin Date: Tue Jul 21 07:36:59 2020 -0400 parisc: Add atomic64_set_release() define to avoid CPU soft lockups commit be6577af0cef934ccb036445314072e8cb9217b9 upstream. Stalls are quite frequent with recent kernels. I enabled CONFIG_SOFTLOCKUP_DETECTOR and I caught the following stall: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [cc1:22803] CPU: 0 PID: 22803 Comm: cc1 Not tainted 5.6.17+ #3 Hardware name: 9000/800/rp3440 IAOQ[0]: d_alloc_parallel+0x384/0x688 IAOQ[1]: d_alloc_parallel+0x388/0x688 RP(r2): d_alloc_parallel+0x134/0x688 Backtrace: [<000000004036974c>] __lookup_slow+0xa4/0x200 [<0000000040369fc8>] walk_component+0x288/0x458 [<000000004036a9a0>] path_lookupat+0x88/0x198 [<000000004036e748>] filename_lookup+0xa0/0x168 [<000000004036e95c>] user_path_at_empty+0x64/0x80 [<000000004035d93c>] vfs_statx+0x104/0x158 [<000000004035dfcc>] __do_sys_lstat64+0x44/0x80 [<000000004035e5a0>] sys_lstat64+0x20/0x38 [<0000000040180054>] syscall_exit+0x0/0x14 The code was stuck in this loop in d_alloc_parallel: 4037d414: 0e 00 10 dc ldd 0(r16),ret0 4037d418: c7 fc 5f ed bb,< ret0,1f,4037d414 4037d41c: 08 00 02 40 nop This is the inner loop of bit_spin_lock which is called by hlist_bl_unlock in d_alloc_parallel: static inline void bit_spin_lock(int bitnum, unsigned long *addr) { /* * Assuming the lock is uncontended, this never enters * the body of the outer loop. If it is contended, then * within the inner loop a non-atomic test is used to * busywait with less bus contention for a good time to * attempt to acquire the lock bit. */ preempt_disable(); #if defined(CONFIG_SMP) || defined(CONFIG_DEBUG_SPINLOCK) while (unlikely(test_and_set_bit_lock(bitnum, addr))) { preempt_enable(); do { cpu_relax(); } while (test_bit(bitnum, addr)); preempt_disable(); } #endif __acquire(bitlock); } After consideration, I realized that we must be losing bit unlocks. Then, I noticed that we missed defining atomic64_set_release(). Adding this define fixes the stalls in bit operations. Signed-off-by: Dave Anglin Cc: stable@vger.kernel.org Signed-off-by: Helge Deller Signed-off-by: Greg Kroah-Hartman commit 77f6d9368c072d89e5ec830152d7e83a1e03df3c Author: Michael J. Ruhl Date: Thu Jul 23 21:15:46 2020 -0700 io-mapping: indicate mapping failure commit e0b3e0b1a04367fc15c07f44e78361545b55357c upstream. The !ATOMIC_IOMAP version of io_maping_init_wc will always return success, even when the ioremap fails. Since the ATOMIC_IOMAP version returns NULL when the init fails, and callers check for a NULL return on error this is unexpected. During a device probe, where the ioremap failed, a crash can look like this: BUG: unable to handle page fault for address: 0000000000210000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 177 Comm: RIP: 0010:fill_page_dma [i915] gen8_ppgtt_create [i915] i915_ppgtt_create [i915] intel_gt_init [i915] i915_gem_init [i915] i915_driver_probe [i915] pci_device_probe really_probe driver_probe_device The remap failure occurred much earlier in the probe. If it had been propagated, the driver would have exited with an error. Return NULL on ioremap failure. [akpm@linux-foundation.org: detect ioremap_wc() errors earlier] Fixes: cafaf14a5d8f ("io-mapping: Always create a struct to hold metadata about the io-mapping") Signed-off-by: Michael J. Ruhl Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Mike Rapoport Cc: Andy Shevchenko Cc: Chris Wilson Cc: Daniel Vetter Cc: Link: http://lkml.kernel.org/r/20200721171936.81563-1-michael.j.ruhl@intel.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit bcd79c5d5887b895046fb7f6527a490985ce4121 Author: Hugh Dickins Date: Thu Jul 23 21:15:24 2020 -0700 mm/memcg: fix refcount error while moving and swapping commit 8d22a9351035ef2ff12ef163a1091b8b8cf1e49c upstream. It was hard to keep a test running, moving tasks between memcgs with move_charge_at_immigrate, while swapping: mem_cgroup_id_get_many()'s refcount is discovered to be 0 (supposedly impossible), so it is then forced to REFCOUNT_SATURATED, and after thousands of warnings in quick succession, the test is at last put out of misery by being OOM killed. This is because of the way moved_swap accounting was saved up until the task move gets completed in __mem_cgroup_clear_mc(), deferred from when mem_cgroup_move_swap_account() actually exchanged old and new ids. Concurrent activity can free up swap quicker than the task is scanned, bringing id refcount down 0 (which should only be possible when offlining). Just skip that optimization: do that part of the accounting immediately. Fixes: 615d66c37c75 ("mm: memcontrol: fix memcg id ref counter on swap charge move") Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Reviewed-by: Alex Shi Cc: Johannes Weiner Cc: Alex Shi Cc: Shakeel Butt Cc: Michal Hocko Cc: Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2007071431050.4726@eggly.anvils Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit d98d958276c73db039a4c47499cd9f085bcec6bb Author: Fangrui Song Date: Tue Jul 21 10:31:23 2020 -0700 Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation commit ca9b31f6bb9c6aa9b4e5f0792f39a97bbffb8c51 upstream. When CROSS_COMPILE is set (e.g. aarch64-linux-gnu-), if $(CROSS_COMPILE)elfedit is found at /usr/bin/aarch64-linux-gnu-elfedit, GCC_TOOLCHAIN_DIR will be set to /usr/bin/. --prefix= will be set to /usr/bin/ and Clang as of 11 will search for both $(prefix)aarch64-linux-gnu-$needle and $(prefix)$needle. GCC searchs for $(prefix)aarch64-linux-gnu/$version/$needle, $(prefix)aarch64-linux-gnu/$needle and $(prefix)$needle. In practice, $(prefix)aarch64-linux-gnu/$needle rarely contains executables. To better model how GCC's -B/--prefix takes in effect in practice, newer Clang (since https://github.com/llvm/llvm-project/commit/3452a0d8c17f7166f479706b293caf6ac76ffd90) only searches for $(prefix)$needle. Currently it will find /usr/bin/as instead of /usr/bin/aarch64-linux-gnu-as. Set --prefix= to $(GCC_TOOLCHAIN_DIR)$(notdir $(CROSS_COMPILE)) (/usr/bin/aarch64-linux-gnu-) so that newer Clang can find the appropriate cross compiling GNU as (when -no-integrated-as is in effect). Cc: stable@vger.kernel.org Reported-by: Nathan Chancellor Signed-off-by: Fangrui Song Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Tested-by: Nick Desaulniers Link: https://github.com/ClangBuiltLinux/linux/issues/1099 Reviewed-by: Nick Desaulniers Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman commit 3307b4ec6d22dd47a07d390085a88a671204e2f2 Author: Tetsuo Handa Date: Sun Jul 12 20:10:12 2020 +0900 vt: Reject zero-sized screen buffer size. commit ce684552a266cb1c7cc2f7e623f38567adec6653 upstream. syzbot is reporting general protection fault in do_con_write() [1] caused by vc->vc_screenbuf == ZERO_SIZE_PTR caused by vc->vc_screenbuf_size == 0 caused by vc->vc_cols == vc->vc_rows == vc->vc_size_row == 0 caused by fb_set_var() from ioctl(FBIOPUT_VSCREENINFO) on /dev/fb0 , for gotoxy(vc, 0, 0) from reset_terminal() from vc_init() from vc_allocate() from con_install() from tty_init_dev() from tty_open() on such console causes vc->vc_pos == 0x10000000e due to ((unsigned long) ZERO_SIZE_PTR) + -1U * 0 + (-1U << 1). I don't think that a console with 0 column or 0 row makes sense. And it seems that vc_do_resize() does not intend to allow resizing a console to 0 column or 0 row due to new_cols = (cols ? cols : vc->vc_cols); new_rows = (lines ? lines : vc->vc_rows); exception. Theoretically, cols and rows can be any range as long as 0 < cols * rows * 2 <= KMALLOC_MAX_SIZE is satisfied (e.g. cols == 1048576 && rows == 2 is possible) because of vc->vc_size_row = vc->vc_cols << 1; vc->vc_screenbuf_size = vc->vc_rows * vc->vc_size_row; in visual_init() and kzalloc(vc->vc_screenbuf_size) in vc_allocate(). Since we can detect cols == 0 or rows == 0 via screenbuf_size = 0 in visual_init(), we can reject kzalloc(0). Then, vc_allocate() will return an error, and con_write() will not be called on a console with 0 column or 0 row. We need to make sure that integer overflow in visual_init() won't happen. Since vc_do_resize() restricts cols <= 32767 and rows <= 32767, applying 1 <= cols <= 32767 and 1 <= rows <= 32767 restrictions to vc_allocate() will be practically fine. This patch does not touch con_init(), for returning -EINVAL there does not help when we are not returning -ENOMEM. [1] https://syzkaller.appspot.com/bug?extid=017265e8553724e514e8 Reported-and-tested-by: syzbot Signed-off-by: Tetsuo Handa Cc: stable Link: https://lore.kernel.org/r/20200712111013.11881-1-penguin-kernel@I-love.SAKURA.ne.jp Signed-off-by: Greg Kroah-Hartman commit bce9a1f2550146bbf43822b37472328d1bf5a260 Author: Serge Semin Date: Tue Jul 14 15:41:12 2020 +0300 serial: 8250_mtk: Fix high-speed baud rates clamping commit 551e553f0d4ab623e2a6f424ab5834f9c7b5229c upstream. Commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") fixed limits of a baud rate setting for a generic 8250 port. In other words since that commit the baud rate has been permitted to be within [uartclk / 16 / UART_DIV_MAX; uartclk / 16], which is absolutely normal for a standard 8250 UART port. But there are custom 8250 ports, which provide extended baud rate limits. In particular the Mediatek 8250 port can work with baud rates up to "uartclk" speed. Normally that and any other peculiarity is supposed to be handled in a custom set_termios() callback implemented in the vendor-specific 8250-port glue-driver. Currently that is how it's done for the most of the vendor-specific 8250 ports, but for some reason for Mediatek a solution has been spread out to both the glue-driver and to the generic 8250-port code. Due to that a bug has been introduced, which permitted the extended baud rate limit for all even for standard 8250-ports. The bug has been fixed by the commit 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") by narrowing the baud rates limit back down to the normal bounds. Unfortunately by doing so we also broke the Mediatek-specific extended bauds feature. A fix of the problem described above is twofold. First since we can't get back the extended baud rate limits feature to the generic set_termios() function and that method supports only a standard baud rates range, the requested baud rate must be locally stored before calling it and then restored back to the new termios structure after the generic set_termios() finished its magic business. By doing so we still use the serial8250_do_set_termios() method to set the LCR/MCR/FCR/etc. registers, while the extended baud rate setting procedure will be performed later in the custom Mediatek-specific set_termios() callback. Second since a true baud rate is now fully calculated in the custom set_termios() method we need to locally update the port timeout by calling the uart_update_timeout() function. After the fixes described above are implemented in the 8250_mtk.c driver, the Mediatek 8250-port should get back to normally working with extended baud rates. Link: https://lore.kernel.org/linux-serial/20200701211337.3027448-1-danielwinkler@google.com Fixes: 7b668c064ec3 ("serial: 8250: Fix max baud limit in generic 8250 port") Reported-by: Daniel Winkler Signed-off-by: Serge Semin Cc: stable Tested-by: Claire Chang Link: https://lore.kernel.org/r/20200714124113.20918-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman commit 81e57039ebbc2c0867f2c04bb3cb205b4edd0141 Author: Yang Yingliang Date: Tue Jul 21 14:38:52 2020 +0000 serial: 8250: fix null-ptr-deref in serial8250_start_tx() commit f4c23a140d80ef5e6d3d1f8f57007649014b60fa upstream. I got null-ptr-deref in serial8250_start_tx(): [ 78.114630] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 78.123778] Mem abort info: [ 78.126560] ESR = 0x86000007 [ 78.129603] EC = 0x21: IABT (current EL), IL = 32 bits [ 78.134891] SET = 0, FnV = 0 [ 78.137933] EA = 0, S1PTW = 0 [ 78.141064] user pgtable: 64k pages, 48-bit VAs, pgdp=00000027d41a8600 [ 78.147562] [0000000000000000] pgd=00000027893f0003, p4d=00000027893f0003, pud=00000027893f0003, pmd=00000027c9a20003, pte=0000000000000000 [ 78.160029] Internal error: Oops: 86000007 [#1] SMP [ 78.164886] Modules linked in: sunrpc vfat fat aes_ce_blk crypto_simd cryptd aes_ce_cipher crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce ses enclosure sg sbsa_gwdt ipmi_ssif spi_dw_mmio sch_fq_codel vhost_net tun vhost vhost_iotlb tap ip_tables ext4 mbcache jbd2 ahci hisi_sas_v3_hw libahci hisi_sas_main libsas hns3 scsi_transport_sas hclge libata megaraid_sas ipmi_si hnae3 ipmi_devintf ipmi_msghandler br_netfilter bridge stp llc nvme nvme_core xt_sctp sctp libcrc32c dm_mod nbd [ 78.207383] CPU: 11 PID: 23258 Comm: null-ptr Not tainted 5.8.0-rc6+ #48 [ 78.214056] Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V3.B210.01 03/12/2020 [ 78.222888] pstate: 80400089 (Nzcv daIf +PAN -UAO BTYPE=--) [ 78.228435] pc : 0x0 [ 78.230618] lr : serial8250_start_tx+0x160/0x260 [ 78.235215] sp : ffff800062eefb80 [ 78.238517] x29: ffff800062eefb80 x28: 0000000000000fff [ 78.243807] x27: ffff800062eefd80 x26: ffff202fd83b3000 [ 78.249098] x25: ffff800062eefd80 x24: ffff202fd83b3000 [ 78.254388] x23: ffff002fc5e50be8 x22: 0000000000000002 [ 78.259679] x21: 0000000000000001 x20: 0000000000000000 [ 78.264969] x19: ffffa688827eecc8 x18: 0000000000000000 [ 78.270259] x17: 0000000000000000 x16: 0000000000000000 [ 78.275550] x15: ffffa68881bc67a8 x14: 00000000000002e6 [ 78.280841] x13: ffffa68881bc67a8 x12: 000000000000c539 [ 78.286131] x11: d37a6f4de9bd37a7 x10: ffffa68881cccff0 [ 78.291421] x9 : ffffa68881bc6000 x8 : ffffa688819daa88 [ 78.296711] x7 : ffffa688822a0f20 x6 : ffffa688819e0000 [ 78.302002] x5 : ffff800062eef9d0 x4 : ffffa68881e707a8 [ 78.307292] x3 : 0000000000000000 x2 : 0000000000000002 [ 78.312582] x1 : 0000000000000001 x0 : ffffa688827eecc8 [ 78.317873] Call trace: [ 78.320312] 0x0 [ 78.322147] __uart_start.isra.9+0x64/0x78 [ 78.326229] uart_start+0xb8/0x1c8 [ 78.329620] uart_flush_chars+0x24/0x30 [ 78.333442] n_tty_receive_buf_common+0x7b0/0xc30 [ 78.338128] n_tty_receive_buf+0x44/0x2c8 [ 78.342122] tty_ioctl+0x348/0x11f8 [ 78.345599] ksys_ioctl+0xd8/0xf8 [ 78.348903] __arm64_sys_ioctl+0x2c/0xc8 [ 78.352812] el0_svc_common.constprop.2+0x88/0x1b0 [ 78.357583] do_el0_svc+0x44/0xd0 [ 78.360887] el0_sync_handler+0x14c/0x1d0 [ 78.364880] el0_sync+0x140/0x180 [ 78.368185] Code: bad PC value SERIAL_PORT_DFNS is not defined on each arch, if it's not defined, serial8250_set_defaults() won't be called in serial8250_isa_init_ports(), so the p->serial_in pointer won't be initialized, and it leads a null-ptr-deref. Fix this problem by calling serial8250_set_defaults() after init uart port. Signed-off-by: Yang Yingliang Cc: stable Link: https://lore.kernel.org/r/20200721143852.4058352-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman commit 75a0cbaaee3501aaa48a8dda42f6a1afc6ca395e Author: Ian Abbott Date: Fri Jul 17 15:52:56 2020 +0100 staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift commit 926234f1b8434c4409aa4c53637aa3362ca07cea upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions") Cc: #3.17+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit ecceea19a19370184671a70ce454b2efccae69c1 Author: Ian Abbott Date: Fri Jul 17 15:52:57 2020 +0100 staging: comedi: addi_apci_1500: check INSN_CONFIG_DIGITAL_TRIG shift commit fc846e9db67c7e808d77bf9e2ef3d49e3820ce5d upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this, adjusting the checks for invalid channels so that enabled channel bits that would have been lost by shifting are also checked for validity. Only channels 0 to 15 are valid. Fixes: a8c66b684efaf ("staging: comedi: addi_apci_1500: rewrite the subdevice support functions") Cc: #4.0+: ef75e14a6c93: staging: comedi: verify array index is correct before using it Cc: #4.0+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20200717145257.112660-5-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 63fe8c960844202bfa95219a07a21358c2d8c163 Author: Ian Abbott Date: Fri Jul 17 15:52:54 2020 +0100 staging: comedi: ni_6527: fix INSN_CONFIG_DIGITAL_TRIG support commit f07804ec77d77f8a9dcf570a24154e17747bc82f upstream. `ni6527_intr_insn_config()` processes `INSN_CONFIG` comedi instructions for the "interrupt" subdevice. When `data[0]` is `INSN_CONFIG_DIGITAL_TRIG` it is configuring the digital trigger. When `data[2]` is `COMEDI_DIGITAL_TRIG_ENABLE_EDGES` it is configuring rising and falling edge detection for the digital trigger, using a base channel number (or shift amount) in `data[3]`, a rising edge bitmask in `data[4]` and falling edge bitmask in `data[5]`. If the base channel number (shift amount) is greater than or equal to the number of channels (24) of the digital input subdevice, there are no changes to the rising and falling edges, so the mask of channels to be changed can be set to 0, otherwise the mask of channels to be changed, and the rising and falling edge bitmasks are shifted by the base channel number before calling `ni6527_set_edge_detection()` to change the appropriate registers. Unfortunately, the code is comparing the base channel (shift amount) to the interrupt subdevice's number of channels (1) instead of the digital input subdevice's number of channels (24). Fix it by comparing to 32 because all shift amounts for an `unsigned int` must be less than that and everything from bit 24 upwards is ignored by `ni6527_set_edge_detection()` anyway. Fixes: 110f9e687c1a8 ("staging: comedi: ni_6527: support INSN_CONFIG_DIGITAL_TRIG") Cc: # 3.17+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20200717145257.112660-2-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit bfe0aac5e4fa18b0a1b7cefb70330282fda9308c Author: Ian Abbott Date: Fri Jul 17 15:52:55 2020 +0100 staging: comedi: addi_apci_1032: check INSN_CONFIG_DIGITAL_TRIG shift commit 0bd0db42a030b75c20028c7ba6e327b9cb554116 upstream. The `INSN_CONFIG` comedi instruction with sub-instruction code `INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is used as a right shift amount for other bitmask values without being checked. Shift amounts greater than or equal to 32 will result in undefined behavior. Add code to deal with this. Fixes: 33cdce6293dcc ("staging: comedi: addi_apci_1032: conform to new INSN_CONFIG_DIGITAL_TRIG") Cc: #3.8+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20200717145257.112660-3-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit c2646b964beee190376fe4cba6473bcad087437f Author: Rustam Kovhaev Date: Wed Jul 22 09:10:52 2020 -0700 staging: wlan-ng: properly check endpoint types commit faaff9765664009c1c7c65551d32e9ed3b1dda8f upstream. As syzkaller detected, wlan-ng driver does not do sanity check of endpoints in prism2sta_probe_usb(), add check for xfer direction and type Reported-and-tested-by: syzbot+c2a1fa67c02faa0de723@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=c2a1fa67c02faa0de723 Signed-off-by: Rustam Kovhaev Cc: stable Link: https://lore.kernel.org/r/20200722161052.999754-1-rkovhaev@gmail.com Signed-off-by: Greg Kroah-Hartman commit 13b502bbee22d4828b8bdcc6e7d77f94617f0bd5 Author: Steve French Date: Thu Jul 23 14:41:29 2020 -0500 Revert "cifs: Fix the target file was deleted when rename failed." commit 0e6705182d4e1b77248a93470d6d7b3013d59b30 upstream. This reverts commit 9ffad9263b467efd8f8dc7ae1941a0a655a2bab2. Upon additional testing with older servers, it was found that the original commit introduced a regression when using the old SMB1 dialect and rsyncing over an existing file. The patch will need to be respun to address this, likely including a larger refactoring of the SMB1 and SMB3 rename code paths to make it less confusing and also to address some additional rename error cases that SMB3 may be able to workaround. Signed-off-by: Steve French Reported-by: Patrick Fernie CC: Stable Acked-by: Ronnie Sahlberg Acked-by: Pavel Shilovsky Acked-by: Zhang Xiaoxu Signed-off-by: Greg Kroah-Hartman commit 41f5f86a7105f6d6e657894f245d4cd9c34655ed Author: Forest Crossman Date: Fri Jul 17 06:27:34 2020 -0500 usb: xhci: Fix ASM2142/ASM3142 DMA addressing commit dbb0897e805f2ab1b8bc358f6c3d878a376b8897 upstream. The ASM2142/ASM3142 (same PCI IDs) does not support full 64-bit DMA addresses, which can cause silent memory corruption or IOMMU errors on platforms that use the upper bits. Add the XHCI_NO_64BIT_SUPPORT quirk to fix this issue. Signed-off-by: Forest Crossman Cc: stable Link: https://lore.kernel.org/r/20200717112734.328432-1-cyrozap@gmail.com Signed-off-by: Greg Kroah-Hartman commit a9423d50bb5841656cc8af8225ec385c1781fbc8 Author: Chunfeng Yun Date: Fri Jul 10 13:57:52 2020 +0800 usb: xhci-mtk: fix the failure of bandwidth allocation commit 5ce1a24dd98c00a57a8fa13660648abf7e08e3ef upstream. The wMaxPacketSize field of endpoint descriptor may be zero as default value in alternate interface, and they are not actually selected when start stream, so skip them when try to allocate bandwidth. Cc: stable Fixes: 0cbd4b34cda9 ("xhci: mediatek: support MTK xHCI host controller") Signed-off-by: Chunfeng Yun Link: https://lore.kernel.org/r/1594360672-2076-1-git-send-email-chunfeng.yun@mediatek.com Signed-off-by: Greg Kroah-Hartman commit 8844e1707f2d0eea489f515fb90f46e490c34503 Author: Arnd Bergmann Date: Wed May 27 15:53:46 2020 +0200 x86: math-emu: Fix up 'cmp' insn for clang ias [ Upstream commit 81e96851ea32deb2c921c870eecabf335f598aeb ] The clang integrated assembler requires the 'cmp' instruction to have a length prefix here: arch/x86/math-emu/wm_sqrt.S:212:2: error: ambiguous instructions require an explicit suffix (could be 'cmpb', 'cmpw', or 'cmpl') cmp $0xffffffff,-24(%ebp) ^ Make this a 32-bit comparison, which it was clearly meant to be. Signed-off-by: Arnd Bergmann Signed-off-by: Thomas Gleixner Reviewed-by: Nick Desaulniers Link: https://lkml.kernel.org/r/20200527135352.1198078-1-arnd@arndb.de Signed-off-by: Sasha Levin commit 998c0852c5285e2e3259c52d79b8d9da05f2781d Author: Will Deacon Date: Thu Feb 13 12:12:26 2020 +0000 arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP [ Upstream commit 5afc78551bf5d53279036e0bf63314e35631d79f ] Rather than open-code test_tsk_thread_flag() at each callsite, simply replace the couple of offenders with calls to test_tsk_thread_flag() directly. Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit f038d105d093c596f390798436c0478bd7479614 Author: Evgeny Novikov Date: Fri Jun 26 16:17:47 2020 +0300 usb: gadget: udc: gr_udc: fix memleak on error handling path in gr_ep_init() [ Upstream commit c8f8529e2c4141afa2ebb487ad48e8a6ec3e8c99 ] gr_ep_init() does not assign the allocated request anywhere if allocation of memory for the buffer fails. This is a memory leak fixed by the given patch. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9ef026214f70de1ce50559421d54ad9741d14e52 Author: Leonid Ravich Date: Wed Jul 1 21:48:12 2020 +0300 dmaengine: ioat setting ioat timeout as module parameter [ Upstream commit 87730ccbddcb48478b1b88e88b14e73424130764 ] DMA transaction time to completion is a function of PCI bandwidth, transaction size and a queue depth. So hard coded value for timeouts might be wrong for some scenarios. Signed-off-by: Leonid Ravich Reviewed-by: Dave Jiang Link: https://lore.kernel.org/r/20200701184816.29138-1-leonid.ravich@dell.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 05f479dce24e94c57b1e28ffa12f149fd3b8f31d Author: Marc Kleine-Budde Date: Fri Jul 3 12:33:15 2020 +0200 regmap: dev_get_regmap_match(): fix string comparison [ Upstream commit e84861fec32dee8a2e62bbaa52cded6b05a2a456 ] This function is used by dev_get_regmap() to retrieve a regmap for the specified device. If the device has more than one regmap, the name parameter can be used to specify one. The code here uses a pointer comparison to check for equal strings. This however will probably always fail, as the regmap->name is allocated via kstrdup_const() from the regmap's config->name. Fix this by using strcmp() instead. Signed-off-by: Marc Kleine-Budde Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8830292dcf402efb9953aae1a14ff3815c038b05 Author: Dinghao Liu Date: Wed Jun 24 14:46:26 2020 +0800 dmaengine: tegra210-adma: Fix runtime PM imbalance on error [ Upstream commit 5b78fac4b1ba731cf4177fdbc1e3a4661521bcd0 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Signed-off-by: Dinghao Liu Reviewed-by: Jon Hunter Link: https://lore.kernel.org/r/20200624064626.19855-1-dinghao.liu@zju.edu.cn Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d1893610f6c7632282d904a9eecec695a0254800 Author: Hans de Goede Date: Sat Jun 20 14:32:29 2020 +0200 HID: apple: Disable Fn-key key-re-mapping on clone keyboards [ Upstream commit a5d81646fa294eed57786a9310b06ca48902adf8 ] The Maxxter KB-BT-001 Bluetooth keyboard, which looks somewhat like the Apple Wireless Keyboard, is using the vendor and product IDs (05AC:0239) of the Apple Wireless Keyboard (2009 ANSI version) . But its F1 - F10 keys are marked as sending F1 - F10, not the special functions hid-apple.c maps them too; and since its descriptors do not contain the HID_UP_CUSTOM | 0x0003 usage apple-hid looks for for the Fn-key, apple_setup_input() never gets called, so F1 - F6 are mapped to key-codes which have not been set in the keybit array causing them to not send any events at all. The lack of a usage code matching the Fn key in the clone is actually useful as this allows solving this problem in a generic way. This commits adds a fn_found flag and it adds a input_configured callback which checks if this flag is set once all usages have been mapped. If it is not set, then assume this is a clone and clear the quirks bitmap so that the hid-apple code does not add any special handling to this keyboard. This fixes F1 - F6 not sending anything at all and F7 - F12 sending the wrong codes on the Maxxter KB-BT-001 Bluetooth keyboard and on similar clones. Cc: Joao Moreno Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 95c0fa1eca9c81ba0e6507bca79f6ea42de6cb52 Author: Federico Ricchiuto Date: Mon Jun 15 22:49:11 2020 +0200 HID: i2c-hid: add Mediacom FlexBook edge13 to descriptor override [ Upstream commit 43e666acb79f3d355dd89bf20f4d25d3b15da13e ] The Mediacom FlexBook edge13 uses the SIPODEV SP1064 touchpad, which does not supply descriptors, so it has to be added to the override list. Signed-off-by: Federico Ricchiuto Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 5e085f2f1536d7dd5d1f96d7e7a255f81cd86541 Author: Pi-Hsun Shih Date: Thu Jul 23 21:15:43 2020 -0700 scripts/decode_stacktrace: strip basepath from all paths [ Upstream commit d178770d8d21489abf5bafefcbb6d5243b482e9a ] Currently the basepath is removed only from the beginning of the string. When the symbol is inlined and there's multiple line outputs of addr2line, only the first line would have basepath removed. Change to remove the basepath prefix from all lines. Fixes: 31013836a71e ("scripts/decode_stacktrace: match basepath using shell prefix operator, not regex") Co-developed-by: Shik Chen Signed-off-by: Pi-Hsun Shih Signed-off-by: Shik Chen Signed-off-by: Andrew Morton Reviewed-by: Stephen Boyd Cc: Sasha Levin Cc: Nicolas Boichat Cc: Jiri Slaby Link: http://lkml.kernel.org/r/20200720082709.252805-1-pihsun@chromium.org Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 49c4d85072aa53241a0567bf7ec2e2f0619c586f Author: Wang Hai Date: Thu Jul 16 11:50:38 2020 +0800 net: smc91x: Fix possible memory leak in smc_drv_probe() [ Upstream commit bca9749b1aa23d964d3ab930938af66dbf887f15 ] If try_toggle_control_gpio() failed in smc_drv_probe(), free_netdev(ndev) should be called to free the ndev created earlier. Otherwise, a memleak will occur. Fixes: 7d2911c43815 ("net: smc91x: Fix gpios for device tree based booting") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 059e2392bf819c6fb884397addd5cb0ef53aed4d Author: Sergey Organov Date: Wed Jul 15 19:10:00 2020 +0300 net: dp83640: fix SIOCSHWTSTAMP to update the struct with actual configuration [ Upstream commit 473309fb8372365ad211f425bca760af800e10a7 ] From Documentation/networking/timestamping.txt: A driver which supports hardware time stamping shall update the struct with the actual, possibly more permissive configuration. Do update the struct passed when we upscale the requested time stamping mode. Fixes: cb646e2b02b2 ("ptp: Added a clock driver for the National Semiconductor PHYTER.") Signed-off-by: Sergey Organov Acked-by: Richard Cochran Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 041aff4ad9470c328b50c5be10e49270913d5041 Author: George Kennedy Date: Wed Jul 15 09:59:31 2020 -0400 ax88172a: fix ax88172a_unbind() failures [ Upstream commit c28d9a285668c799eeae2f7f93e929a6028a4d6d ] If ax88172a_unbind() fails, make sure that the return code is less than zero so that cleanup is done properly and avoid UAF. Fixes: a9a51bd727d1 ("ax88172a: fix information leak on short answers") Signed-off-by: George Kennedy Reported-by: syzbot+4cd84f527bf4a10fc9c1@syzkaller.appspotmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 7a1d03dead97e35a2e2fb25d0d5c35dd1324e818 Author: Christophe JAILLET Date: Tue Jul 14 13:00:27 2020 +0200 hippi: Fix a size used in a 'pci_free_consistent()' in an error handling path [ Upstream commit 3195c4706b00106aa82c73acd28340fa8fc2bfc1 ] The size used when calling 'pci_alloc_consistent()' and 'pci_free_consistent()' should match. Fix it and have it consistent with the corresponding call in 'rr_close()'. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Christophe JAILLET Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 1ff463b64f611f1e3aa0d533d488e610aa979817 Author: Vasundhara Volam Date: Sat Jul 11 20:48:23 2020 -0400 bnxt_en: Fix race when modifying pause settings. [ Upstream commit 163e9ef63641a02de4c95cd921577265c52e1ce2 ] The driver was modified to not rely on rtnl lock to protect link settings about 2 years ago. The pause setting was missed when making that change. Fix it by acquiring link_lock mutex before calling bnxt_hwrm_set_pause(). Fixes: e2dc9b6e38fa ("bnxt_en: Don't use rtnl lock to protect link change logic in workqueue.") Signed-off-by: Vasundhara Volam Reviewed-by: Edwin Peer Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 59b6d2218da82562e5f4b0053ed2904b0842c80f Author: Boris Burkov Date: Thu Jul 16 13:29:46 2020 -0700 btrfs: fix mount failure caused by race with umount [ Upstream commit 48cfa61b58a1fee0bc49eef04f8ccf31493b7cdd ] It is possible to cause a btrfs mount to fail by racing it with a slow umount. The crux of the sequence is generic_shutdown_super not yet calling sop->put_super before btrfs_mount_root calls btrfs_open_devices. If that occurs, btrfs_open_devices will decide the opened counter is non-zero, increment it, and skip resetting fs_devices->total_rw_bytes to 0. From here, mount will call sget which will result in grab_super trying to take the super block umount semaphore. That semaphore will be held by the slow umount, so mount will block. Before up-ing the semaphore, umount will delete the super block, resulting in mount's sget reliably allocating a new one, which causes the mount path to dutifully fill it out, and increment total_rw_bytes a second time, which causes the mount to fail, as we see double the expected bytes. Here is the sequence laid out in greater detail: CPU0 CPU1 down_write sb->s_umount btrfs_kill_super kill_anon_super(sb) generic_shutdown_super(sb); shrink_dcache_for_umount(sb); sync_filesystem(sb); evict_inodes(sb); // SLOW btrfs_mount_root btrfs_scan_one_device fs_devices = device->fs_devices fs_info->fs_devices = fs_devices // fs_devices-opened makes this a no-op btrfs_open_devices(fs_devices, mode, fs_type) s = sget(fs_type, test, set, flags, fs_info); find sb in s_instances grab_super(sb); down_write(&s->s_umount); // blocks sop->put_super(sb) // sb->fs_devices->opened == 2; no-op spin_lock(&sb_lock); hlist_del_init(&sb->s_instances); spin_unlock(&sb_lock); up_write(&sb->s_umount); return 0; retry lookup don't find sb in s_instances (deleted by CPU0) s = alloc_super return s; btrfs_fill_super(s, fs_devices, data) open_ctree // fs_devices total_rw_bytes improperly set! btrfs_read_chunk_tree read_one_dev // increment total_rw_bytes again!! super_total_bytes < fs_devices->total_rw_bytes // ERROR!!! To fix this, we clear total_rw_bytes from within btrfs_read_chunk_tree before the calls to read_one_dev, while holding the sb umount semaphore and the uuid mutex. To reproduce, it is sufficient to dirty a decent number of inodes, then quickly umount and mount. for i in $(seq 0 500) do dd if=/dev/zero of="/mnt/foo/$i" bs=1M count=1 done umount /mnt/foo& mount /mnt/foo does the trick for me. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Boris Burkov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit c6ff26b1d0e593c51951b9df2ece5cf629a55085 Author: Filipe Manana Date: Mon Jul 13 15:11:56 2020 +0100 btrfs: fix double free on ulist after backref resolution failure commit 580c079b5766ac706f56eec5c79aee4bf929fef6 upstream. At btrfs_find_all_roots_safe() we allocate a ulist and set the **roots argument to point to it. However if later we fail due to an error returned by find_parent_nodes(), we free that ulist but leave a dangling pointer in the **roots argument. Upon receiving the error, a caller of this function can attempt to free the same ulist again, resulting in an invalid memory access. One such scenario is during qgroup accounting: btrfs_qgroup_account_extents() --> calls btrfs_find_all_roots() passes &new_roots (a stack allocated pointer) to btrfs_find_all_roots() --> btrfs_find_all_roots() just calls btrfs_find_all_roots_safe() passing &new_roots to it --> allocates ulist and assigns its address to **roots (which points to new_roots from btrfs_qgroup_account_extents()) --> find_parent_nodes() returns an error, so we free the ulist and leave **roots pointing to it after returning --> btrfs_qgroup_account_extents() sees btrfs_find_all_roots() returned an error and jumps to the label 'cleanup', which just tries to free again the same ulist Stack trace example: ------------[ cut here ]------------ BTRFS: tree first key check failed WARNING: CPU: 1 PID: 1763215 at fs/btrfs/disk-io.c:422 btrfs_verify_level_key+0xe0/0x180 [btrfs] Modules linked in: dm_snapshot dm_thin_pool (...) CPU: 1 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:btrfs_verify_level_key+0xe0/0x180 [btrfs] Code: 28 5b 5d (...) RSP: 0018:ffffb89b473779a0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff90397759bf08 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000027 RDI: 00000000ffffffff RBP: ffff9039a419c000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: ffffb89b43301000 R12: 000000000000005e R13: ffffb89b47377a2e R14: ffffb89b473779af R15: 0000000000000000 FS: 00007fc47e1e1000(0000) GS:ffff9039ac200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc47e1df000 CR3: 00000003d9e4e001 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: read_block_for_search+0xf6/0x350 [btrfs] btrfs_next_old_leaf+0x242/0x650 [btrfs] resolve_indirect_refs+0x7cf/0x9e0 [btrfs] find_parent_nodes+0x4ea/0x12c0 [btrfs] btrfs_find_all_roots_safe+0xbf/0x130 [btrfs] btrfs_qgroup_account_extents+0x9d/0x390 [btrfs] btrfs_commit_transaction+0x4f7/0xb20 [btrfs] btrfs_sync_file+0x3d4/0x4d0 [btrfs] do_fsync+0x38/0x70 __x64_sys_fdatasync+0x13/0x20 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc47e2d72e3 Code: Bad RIP value. RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3 RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003 RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8 R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50 irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0x755/0x1eb0 softirqs last enabled at (0): [] copy_process+0x755/0x1eb0 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 8639237550317b48 ]--- BTRFS error (device sdc): tree first key mismatch detected, bytenr=62324736 parent_transid=94 key expected=(262,108,1351680) has=(259,108,1921024) general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 1763215 Comm: fsstress Tainted: G W 5.8.0-rc3-btrfs-next-64 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ulist_release+0x14/0x60 [btrfs] Code: c7 07 00 (...) RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282 RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840 RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840 R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840 FS: 00007fc47e1e1000(0000) GS:ffff9039ac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8c1c0a51c8 CR3: 00000003d9e4e004 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ulist_free+0x13/0x20 [btrfs] btrfs_qgroup_account_extents+0xf3/0x390 [btrfs] btrfs_commit_transaction+0x4f7/0xb20 [btrfs] btrfs_sync_file+0x3d4/0x4d0 [btrfs] do_fsync+0x38/0x70 __x64_sys_fdatasync+0x13/0x20 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc47e2d72e3 Code: Bad RIP value. RSP: 002b:00007fffa32098c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004b RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fc47e2d72e3 RDX: 00007fffa3209830 RSI: 00007fffa3209830 RDI: 0000000000000003 RBP: 000000000000072e R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000003e8 R13: 0000000051eb851f R14: 00007fffa3209970 R15: 00005607c4ac8b50 Modules linked in: dm_snapshot dm_thin_pool (...) ---[ end trace 8639237550317b49 ]--- RIP: 0010:ulist_release+0x14/0x60 [btrfs] Code: c7 07 00 (...) RSP: 0018:ffffb89b47377d60 EFLAGS: 00010282 RAX: 6b6b6b6b6b6b6b6b RBX: ffff903959b56b90 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000270024 RDI: ffff9036e2adc840 RBP: ffff9036e2adc848 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff9036e2adc840 R13: 0000000000000015 R14: ffff9039a419ccf8 R15: ffff90395d605840 FS: 00007fc47e1e1000(0000) GS:ffff9039ad200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6a776f7d40 CR3: 00000003d9e4e002 CR4: 00000000003606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Fix this by making btrfs_find_all_roots_safe() set *roots to NULL after it frees the ulist. Fixes: 8da6d5815c592b ("Btrfs: added btrfs_find_all_roots()") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f91620544707e105f74bb71dc72a8ab27b55fddf Author: Hans de Goede Date: Sun Jun 28 17:52:27 2020 +0200 ASoC: rt5670: Correct RT5670_LDO_SEL_MASK commit 5cacc6f5764e94fa753b2c1f5f7f1f3f74286e82 upstream. The RT5670_PWR_ANLG1 register has 3 bits to select the LDO voltage, so the correct mask is 0x7 not 0x3. Because of this wrong mask we were programming the ldo bits to a setting of binary 001 (0x05 & 0x03) instead of binary 101 when moving to SND_SOC_BIAS_PREPARE. According to the datasheet 001 is a reserved value, so no idea what it did, since the driver was working fine before I guess we got lucky and it does something which is ok. Fixes: 5e8351de740d ("ASoC: add RT5670 CODEC driver") Signed-off-by: Hans de Goede Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200628155231.71089-3-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 4881d9b6cc9acf2da39d48f4dff7157ed75f6cd0 Author: Takashi Iwai Date: Fri Jul 17 10:40:23 2020 +0200 ALSA: info: Drop WARN_ON() from buffer NULL sanity check commit 60379ba08532eca861e933b389526a4dc89e0c42 upstream. snd_info_get_line() has a sanity check of NULL buffer -- both buffer itself being NULL and buffer->buffer being NULL. Basically both checks are valid and necessary, but the problem is that it's with snd_BUG_ON() macro that triggers WARN_ON(). The latter condition (NULL buffer->buffer) can be met arbitrarily by user since the buffer is allocated at the first write, so it means that user can trigger WARN_ON() at will. This patch addresses it by simply moving buffer->buffer NULL check out of snd_BUG_ON() so that spurious WARNING is no longer triggered. Reported-by: syzbot+e42d0746c3c3699b6061@syzkaller.appspotmail.com Cc: Link: https://lore.kernel.org/r/20200717084023.5928-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit fe6ba50d43547abee54886161115c0a601d3092c Author: Oleg Nesterov Date: Thu Jul 23 17:44:20 2020 +0200 uprobes: Change handle_swbp() to send SIGTRAP with si_code=SI_KERNEL, to fix GDB regression commit fe5ed7ab99c656bd2f5b79b49df0e9ebf2cead8a upstream. If a tracee is uprobed and it hits int3 inserted by debugger, handle_swbp() does send_sig(SIGTRAP, current, 0) which means si_code == SI_USER. This used to work when this code was written, but then GDB started to validate si_code and now it simply can't use breakpoints if the tracee has an active uprobe: # cat test.c void unused_func(void) { } int main(void) { return 0; } # gcc -g test.c -o test # perf probe -x ./test -a unused_func # perf record -e probe_test:unused_func gdb ./test -ex run GNU gdb (GDB) 10.0.50.20200714-git ... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00007ffff7ddf909 in dl_main () from /lib64/ld-linux-x86-64.so.2 (gdb) The tracee hits the internal breakpoint inserted by GDB to monitor shared library events but GDB misinterprets this SIGTRAP and reports a signal. Change handle_swbp() to use force_sig(SIGTRAP), this matches do_int3_user() and fixes the problem. This is the minimal fix for -stable, arch/x86/kernel/uprobes.c is equally wrong; it should use send_sigtrap(TRAP_TRACE) instead of send_sig(SIGTRAP), but this doesn't confuse GDB and needs another x86-specific patch. Reported-by: Aaron Merey Signed-off-by: Oleg Nesterov Signed-off-by: Ingo Molnar Reviewed-by: Srikar Dronamraju Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200723154420.GA32043@redhat.com Signed-off-by: Greg Kroah-Hartman commit 968bef603af109124d418e0cc7669aa97fc562a4 Author: Olga Kornievskaia Date: Wed Jul 15 13:04:15 2020 -0400 SUNRPC reverting d03727b248d0 ("NFSv4 fix CLOSE not waiting for direct IO compeletion") commit 65caafd0d2145d1dd02072c4ced540624daeab40 upstream. Reverting commit d03727b248d0 "NFSv4 fix CLOSE not waiting for direct IO compeletion". This patch made it so that fput() by calling inode_dio_done() in nfs_file_release() would wait uninterruptably for any outstanding directIO to the file (but that wait on IO should be killable). The problem the patch was also trying to address was REMOVE returning ERR_ACCESS because the file is still opened, is supposed to be resolved by server returning ERR_FILE_OPEN and not ERR_ACCESS. Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Greg Kroah-Hartman commit 237169c0b9a365b2e8cbe14ecdd9e657a51a1111 Author: Ben Skeggs Date: Tue Jun 23 16:39:13 2020 +1000 drm/nouveau/i2c/g94-: increase NV_PMGR_DP_AUXCTL_TRANSACTREQ timeout [ Upstream commit 0156e76d388310a490aeb0f2fbb5b284ded3aecc ] Tegra TRM says worst-case reply time is 1216us, and this should fix some spurious timeouts that have been popping up. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 31b10f2c3541488aec4b4c50c01e992550f58e16 Author: Tom Rix Date: Fri Jul 3 06:33:59 2020 -0700 net: sky2: initialize return of gm_phy_read [ Upstream commit 28b18e4eb515af7c6661c3995c6e3c34412c2874 ] clang static analysis flags this garbage return drivers/net/ethernet/marvell/sky2.c:208:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return v; ^~~~~~~~ static inline u16 gm_phy_read( ... { u16 v; __gm_phy_read(hw, port, reg, &v); return v; } __gm_phy_read can return without setting v. So handle similar to skge.c's gm_phy_read, initialize v. Signed-off-by: Tom Rix Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4d565f464cc5b8b55677bc189ca8a4100feb3400 Author: Xie He Date: Sun Jul 5 17:45:21 2020 -0700 drivers/net/wan/lapbether: Fixed the value of hard_header_len [ Upstream commit 9dc829a135fb5927f1519de11286e2bbb79f5b66 ] When this driver transmits data, first this driver will remove a pseudo header of 1 byte, then the lapb module will prepend the LAPB header of 2 or 3 bytes, then this driver will prepend a length field of 2 bytes, then the underlying Ethernet device will prepend its own header. So, the header length required should be: -1 + 3 + 2 + "the header length needed by the underlying device". This patch fixes kernel panic when this driver is used with AF_PACKET SOCK_DGRAM sockets. Signed-off-by: Xie He Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 55ba6c928c366d801bf682183033a6863746ab7a Author: Max Filippov Date: Thu Jul 2 08:32:25 2020 -0700 xtensa: update *pos in cpuinfo_op.next [ Upstream commit 0d5ab144429e8bd80889b856a44d56ab4a5cd59b ] Increment *pos in the cpuinfo_op.next to fix the following warning triggered by cat /proc/cpuinfo: seq_file: buggy .next function c_next did not update position index Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit 068dae90d4710ddf04c58febc31feabb61374b73 Author: Max Filippov Date: Thu Jun 4 13:37:10 2020 -0700 xtensa: fix __sync_fetch_and_{and,or}_4 declarations [ Upstream commit 73f9941306d5ce030f3ffc7db425c7b2a798cf8e ] Building xtensa kernel with gcc-10 produces the following warnings: arch/xtensa/kernel/xtensa_ksyms.c:90:15: warning: conflicting types for built-in function ‘__sync_fetch_and_and_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] arch/xtensa/kernel/xtensa_ksyms.c:96:15: warning: conflicting types for built-in function ‘__sync_fetch_and_or_4’; expected ‘unsigned int(volatile void *, unsigned int)’ [-Wbuiltin-declaration-mismatch] Fix declarations of these functions to avoid the warning. Signed-off-by: Max Filippov Signed-off-by: Sasha Levin commit f7a447122fedddc0af3f4e6680f82c32647593e1 Author: Tom Rix Date: Sat Jun 27 06:32:42 2020 -0700 scsi: scsi_transport_spi: Fix function pointer check [ Upstream commit 5aee52c44d9170591df65fafa1cd408acc1225ce ] clang static analysis flags several null function pointer problems. drivers/scsi/scsi_transport_spi.c:374:1: warning: Called function pointer is null (null dereference) [core.CallAndMessage] spi_transport_max_attr(offset, "%d\n"); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Reviewing the store_spi_store_max macro if (i->f->set_##field) return -EINVAL; should be if (!i->f->set_##field) return -EINVAL; Link: https://lore.kernel.org/r/20200627133242.21618-1-trix@redhat.com Reviewed-by: James Bottomley Signed-off-by: Tom Rix Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 12b513804a7692205de0d104e60bbf5eb47d024e Author: Markus Theil Date: Thu Jun 25 12:42:14 2020 +0200 mac80211: allow rx of mesh eapol frames with default rx key [ Upstream commit 0b467b63870d9c05c81456aa9bfee894ab2db3b6 ] Without this patch, eapol frames cannot be received in mesh mode, when 802.1X should be used. Initially only a MGTK is defined, which is found and set as rx->key, when there are no other keys set. ieee80211_drop_unencrypted would then drop these eapol frames, as they are data frames without encryption and there exists some rx->key. Fix this by differentiating between mesh eapol frames and other data frames with existing rx->key. Allow mesh mesh eapol frames only if they are for our vif address. With this patch in-place, ieee80211_rx_h_mesh_fwding continues after the ieee80211_drop_unencrypted check and notices, that these eapol frames have to be delivered locally, as they should. Signed-off-by: Markus Theil Link: https://lore.kernel.org/r/20200625104214.50319-1-markus.theil@tu-ilmenau.de [small code cleanups] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 309767dbe8ba8fca998d0ba30b40b1a086e63185 Author: Jacky Hu Date: Tue Jun 16 09:50:24 2020 +0800 pinctrl: amd: fix npins for uart0 in kerncz_groups [ Upstream commit 69339d083dfb7786b0e0b3fc19eaddcf11fabdfb ] uart0_pins is defined as: static const unsigned uart0_pins[] = {135, 136, 137, 138, 139}; which npins is wronly specified as 9 later { .name = "uart0", .pins = uart0_pins, .npins = 9, }, npins should be 5 instead of 9 according to the definition. Signed-off-by: Jacky Hu Link: https://lore.kernel.org/r/20200616015024.287683-1-hengqing.hu@gmail.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin