commit 65efbed1df4afdf73585c8531f1f21c01ec39147 Author: Alexandre Frade Date: Thu Aug 27 11:19:55 2020 +0000 Linux 5.8.5-xanmod1 Signed-off-by: Alexandre Frade commit d6443b285c992b9bc7f1b5a42f2d22531a49951c Merge: 0cc47e2495d8 9ece50d8a470 Author: Alexandre Frade Date: Thu Aug 27 11:19:10 2020 +0000 Merge tag 'v5.8.5' into 5.8 This is the 5.8.5 stable release commit 0cc47e2495d886d2705aaa980cd2f4db55d38be8 Author: Vinod Koul Date: Tue Aug 18 12:47:39 2020 +0530 usb: renesas-xhci: remove version check Some devices in wild are reporting bunch of firmware versions, so remove the check for versions in driver Reported by: Anastasios Vacharakis Reported by: Glen Journeay Fixes: 2478be82de44 ("usb: renesas-xhci: Add ROM loader for uPD720201") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=208911 Signed-off-by: Vinod Koul commit 9ece50d8a470ca7235ffd6ac0f9c5f0f201fe2c8 Author: Greg Kroah-Hartman Date: Thu Aug 27 09:31:49 2020 +0200 Linux 5.8.5 Tested-by: Jon Hunter Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit c05dea7c0f3ff1a8d63b41542c4161406093dc2f Author: Max Filippov Date: Sat Aug 8 11:37:13 2020 -0700 binfmt_flat: revert "binfmt_flat: don't offset the data start" commit 2217b982624680d19a80ebb4600d05c8586c4f96 upstream. binfmt_flat loader uses the gap between text and data to store data segment pointers for the libraries. Even in the absence of shared libraries it stores at least one pointer to the executable's own data segment. Text and data can go back to back in the flat binary image and without offsetting data segment last few instructions in the text segment may get corrupted by the data segment pointer. Fix it by reverting commit a2357223c50a ("binfmt_flat: don't offset the data start"). Cc: stable@vger.kernel.org Fixes: a2357223c50a ("binfmt_flat: don't offset the data start") Signed-off-by: Max Filippov Signed-off-by: Greg Ungerer Signed-off-by: Greg Kroah-Hartman commit 44f639d5aeda30318fc86aec2fe99581fc24a134 Author: Pavel Begunkov Date: Mon Aug 24 16:42:35 2020 -0600 io_uring: fix missing ->mm on exit Upstream commits: 8eb06d7e8dd85 ("io_uring: fix missing ->mm on exit") cbcf72148da4a ("io_uring: return locked and pinned page accounting") do_exit() first drops current->mm and then runs task_work, from where io_sq_thread_acquire_mm() would try to set mm for a user dying process. [ 208.004249] WARNING: CPU: 2 PID: 1854 at kernel/kthread.c:1238 kthread_use_mm+0x244/0x270 [ 208.004287] kthread_use_mm+0x244/0x270 [ 208.004288] io_sq_thread_acquire_mm.part.0+0x54/0x80 [ 208.004290] io_async_task_func+0x258/0x2ac [ 208.004291] task_work_run+0xc8/0x210 [ 208.004294] do_exit+0x1b8/0x430 [ 208.004295] do_group_exit+0x44/0xac [ 208.004296] get_signal+0x164/0x69c [ 208.004298] do_signal+0x94/0x1d0 [ 208.004299] do_notify_resume+0x18c/0x340 [ 208.004300] work_pending+0x8/0x3d4 Reported-by: Roman Gershman Tested-by: Roman Gershman Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman commit 3f4be7a7db9fa51929ea22f0cdcfa0abdbf1573f Author: Johannes Berg Date: Wed Aug 19 21:52:38 2020 +0200 netlink: fix state reallocation in policy export [ Upstream commit d1fb55592909ea249af70170c7a52e637009564d ] Evidently, when I did this previously, we didn't have more than 10 policies and didn't run into the reallocation path, because it's missing a memset() for the unused policies. Fix that. Fixes: d07dcf9aadd6 ("netlink: add infrastructure to expose policies to userspace") Signed-off-by: Johannes Berg Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1c0be9a99c9cf32a026d5a01e0e39e8c5d816ff3 Author: Maxim Mikityanskiy Date: Mon Aug 17 16:34:07 2020 +0300 ethtool: Don't omit the netlink reply if no features were changed [ Upstream commit f01204ec8be7ea5e8f0230a7d4200e338d563bde ] The legacy ethtool userspace tool shows an error when no features could be changed. It's useful to have a netlink reply to be able to show this error when __netdev_update_features wasn't called, for example: 1. ethtool -k eth0 large-receive-offload: off 2. ethtool -K eth0 rx-fcs on 3. ethtool -K eth0 lro on Could not change any device features rx-lro: off [requested on] 4. ethtool -K eth0 lro on # The output should be the same, but without this patch the kernel # doesn't send the reply, and ethtool is unable to detect the error. This commit makes ethtool-netlink always return a reply when requested, and it still avoids unnecessary calls to __netdev_update_features if the wanted features haven't changed. Fixes: 0980bfcd6954 ("ethtool: set netdev features with FEATURES_SET request") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 507d7ac63fad384a74dd5ce462aa001df4bc2353 Author: Maxim Mikityanskiy Date: Mon Aug 17 16:34:06 2020 +0300 ethtool: Account for hw_features in netlink interface [ Upstream commit 2847bfed888fbb8bf4c8e8067fd6127538c2c700 ] ethtool-netlink ignores dev->hw_features and may confuse the drivers by asking them to enable features not in the hw_features bitmask. For example: 1. ethtool -k eth0 tls-hw-tx-offload: off [fixed] 2. ethtool -K eth0 tls-hw-tx-offload on tls-hw-tx-offload: on 3. ethtool -k eth0 tls-hw-tx-offload: on [fixed] Fitler out dev->hw_features from req_wanted to fix it and to resemble the legacy ethtool behavior. Fixes: 0980bfcd6954 ("ethtool: set netdev features with FEATURES_SET request") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e53140320193d7520195934d7e004de4567393f9 Author: Maxim Mikityanskiy Date: Mon Aug 17 16:34:05 2020 +0300 ethtool: Fix preserving of wanted feature bits in netlink interface [ Upstream commit 840110a4eae190dcbb9907d68216d5d1d9f25839 ] Currently, ethtool-netlink calculates new wanted bits as: (req_wanted & req_mask) | (old_active & ~req_mask) It completely discards the old wanted bits, so they are forgotten with the next ethtool command. Sample steps to reproduce: 1. ethtool -k eth0 tx-tcp-segmentation: on # TSO is on from the beginning 2. ethtool -K eth0 tx off tx-tcp-segmentation: off [not requested] 3. ethtool -k eth0 tx-tcp-segmentation: off [requested on] 4. ethtool -K eth0 rx off # Some change unrelated to TSO 5. ethtool -k eth0 tx-tcp-segmentation: off # "Wanted on" is forgotten This commit fixes it by changing the formula to: (req_wanted & req_mask) | (old_wanted & ~req_mask), where old_active was replaced by old_wanted to account for the wanted bits. The shortcut condition for the case where nothing was changed now compares wanted bitmasks, instead of wanted to active. Fixes: 0980bfcd6954 ("ethtool: set netdev features with FEATURES_SET request") Signed-off-by: Maxim Mikityanskiy Reviewed-by: Michal Kubecek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit da995e0a6dacf5ce59c27ea4302f94232ec8b797 Author: Shay Agroskin Date: Wed Aug 19 20:28:38 2020 +0300 net: ena: Make missed_tx stat incremental [ Upstream commit ccd143e5150f24b9ba15145c7221b61dd9e41021 ] Most statistics in ena driver are incremented, meaning that a stat's value is a sum of all increases done to it since driver/queue initialization. This patch makes all statistics this way, effectively making missed_tx statistic incremental. Also added a comment regarding rx_drops and tx_drops to make it clearer how these counters are calculated. Fixes: 11095fdb712b ("net: ena: add statistics for missed tx packets") Signed-off-by: Shay Agroskin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3942262b7499405223dcc219bc58cc540eb7651b Author: Cong Wang Date: Sat Aug 15 16:29:15 2020 -0700 tipc: fix uninit skb->data in tipc_nl_compat_dumpit() [ Upstream commit 47733f9daf4fe4f7e0eb9e273f21ad3a19130487 ] __tipc_nl_compat_dumpit() has two callers, and it expects them to pass a valid nlmsghdr via arg->data. This header is artificial and crafted just for __tipc_nl_compat_dumpit(). tipc_nl_compat_publ_dump() does so by putting a genlmsghdr as well as some nested attribute, TIPC_NLA_SOCK. But the other caller tipc_nl_compat_dumpit() does not, this leaves arg->data uninitialized on this call path. Fix this by just adding a similar nlmsghdr without any payload in tipc_nl_compat_dumpit(). This bug exists since day 1, but the recent commit 6ea67769ff33 ("net: tipc: prepare attrs in __tipc_nl_compat_dumpit()") makes it easier to appear. Reported-and-tested-by: syzbot+0e7181deafa7e0b79923@syzkaller.appspotmail.com Fixes: d0796d1ef63d ("tipc: convert legacy nl bearer dump to nl compat") Cc: Jon Maloy Cc: Ying Xue Cc: Richard Alpe Signed-off-by: Cong Wang Acked-by: Ying Xue Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 828fd2e892b03d05e9f573839e7b2d27835703bd Author: Xin Long Date: Thu Aug 20 15:34:47 2020 +0800 tipc: call rcu_read_lock() in tipc_aead_encrypt_done() [ Upstream commit f6db9096416209474090d64d8284e7c16c3d8873 ] b->media->send_msg() requires rcu_read_lock(), as we can see elsewhere in tipc, tipc_bearer_xmit, tipc_bearer_xmit_skb and tipc_bearer_bc_xmit(). Syzbot has reported this issue as: net/tipc/bearer.c:466 suspicious rcu_dereference_check() usage! Workqueue: cryptd cryptd_queue_worker Call Trace: tipc_l2_send_msg+0x354/0x420 net/tipc/bearer.c:466 tipc_aead_encrypt_done+0x204/0x3a0 net/tipc/crypto.c:761 cryptd_aead_crypt+0xe8/0x1d0 crypto/cryptd.c:739 cryptd_queue_worker+0x118/0x1b0 crypto/cryptd.c:181 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415 kthread+0x3b5/0x4a0 kernel/kthread.c:291 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 So fix it by calling rcu_read_lock() in tipc_aead_encrypt_done() for b->media->send_msg(). Fixes: fc1b6d6de220 ("tipc: introduce TIPC encryption & authentication") Reported-by: syzbot+47bbc6b678d317cccbe0@syzkaller.appspotmail.com Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 22f2be57784e95210a2b4e732fac586f1c08abbe Author: Peilin Ye Date: Thu Aug 20 16:30:52 2020 +0200 net/smc: Prevent kernel-infoleak in __smc_diag_dump() [ Upstream commit ce51f63e63c52a4e1eee4dd040fb0ba0af3b43ab ] __smc_diag_dump() is potentially copying uninitialized kernel stack memory into socket buffers, since the compiler may leave a 4-byte hole near the beginning of `struct smcd_diag_dmbinfo`. Fix it by initializing `dinfo` with memset(). Fixes: 4b1b7d3b30a6 ("net/smc: add SMC-D diag support") Suggested-by: Dan Carpenter Signed-off-by: Peilin Ye Signed-off-by: Ursula Braun Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit df805b956877bc1741467c4164c3f75d2e76982d Author: David Laight Date: Wed Aug 19 14:40:52 2020 +0000 net: sctp: Fix negotiation of the number of data streams. [ Upstream commit ab921f3cdbec01c68705a7ade8bec628d541fc2b ] The number of output and input streams was never being reduced, eg when processing received INIT or INIT_ACK chunks. The effect is that DATA chunks can be sent with invalid stream ids and then discarded by the remote system. Fixes: 2075e50caf5ea ("sctp: convert to genradix") Signed-off-by: David Laight Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4c1fc05e5d6ab0af2c481721d6f2ca53d53c44ec Author: Alaa Hleihel Date: Wed Aug 19 18:24:10 2020 +0300 net/sched: act_ct: Fix skb double-free in tcf_ct_handle_fragments() error flow [ Upstream commit eda814b97dfb8d9f4808eb2f65af9bd3705c4cae ] tcf_ct_handle_fragments() shouldn't free the skb when ip_defrag() call fails. Otherwise, we will cause a double-free bug. In such cases, just return the error to the caller. Fixes: b57dc7c13ea9 ("net/sched: Introduce action ct") Signed-off-by: Alaa Hleihel Reviewed-by: Roi Dayan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 351366ffef2c85e089039a76f45f196c5904acfa Author: Necip Fazil Yildiran Date: Mon Aug 17 15:54:48 2020 +0000 net: qrtr: fix usage of idr in port assignment to socket [ Upstream commit 8dfddfb79653df7c38a9c8c4c034f242a36acee9 ] Passing large uint32 sockaddr_qrtr.port numbers for port allocation triggers a warning within idr_alloc() since the port number is cast to int, and thus interpreted as a negative number. This leads to the rejection of such valid port numbers in qrtr_port_assign() as idr_alloc() fails. To avoid the problem, switch to idr_alloc_u32() instead. Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Reported-by: syzbot+f31428628ef672716ea8@syzkaller.appspotmail.com Signed-off-by: Necip Fazil Yildiran Reviewed-by: Dmitry Vyukov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c4c76ec584a749283eeb5df606498290c08cee65 Author: Nikolay Aleksandrov Date: Sat Aug 22 15:06:36 2020 +0300 net: nexthop: don't allow empty NHA_GROUP [ Upstream commit eeaac3634ee0e3f35548be35275efeca888e9b23 ] Currently the nexthop code will use an empty NHA_GROUP attribute, but it requires at least 1 entry in order to function properly. Otherwise we end up derefencing null or random pointers all over the place due to not having any nh_grp_entry members allocated, nexthop code relies on having at least the first member present. Empty NHA_GROUP doesn't make any sense so just disallow it. Also add a WARN_ON for any future users of nexthop_create_group(). BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 0 PID: 558 Comm: ip Not tainted 5.9.0-rc1+ #93 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 RIP: 0010:fib_check_nexthop+0x4a/0xaa Code: 0f 84 83 00 00 00 48 c7 02 80 03 f7 81 c3 40 80 fe fe 75 12 b8 ea ff ff ff 48 85 d2 74 6b 48 c7 02 40 03 f7 81 c3 48 8b 40 10 <48> 8b 80 80 00 00 00 eb 36 80 78 1a 00 74 12 b8 ea ff ff ff 48 85 RSP: 0018:ffff88807983ba00 EFLAGS: 00010213 RAX: 0000000000000000 RBX: ffff88807983bc00 RCX: 0000000000000000 RDX: ffff88807983bc00 RSI: 0000000000000000 RDI: ffff88807bdd0a80 RBP: ffff88807983baf8 R08: 0000000000000dc0 R09: 000000000000040a R10: 0000000000000000 R11: ffff88807bdd0ae8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff88807bea3100 R15: 0000000000000001 FS: 00007f10db393700(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000080 CR3: 000000007bd0f004 CR4: 00000000003706f0 Call Trace: fib_create_info+0x64d/0xaf7 fib_table_insert+0xf6/0x581 ? __vma_adjust+0x3b6/0x4d4 inet_rtm_newroute+0x56/0x70 rtnetlink_rcv_msg+0x1e3/0x20d ? rtnl_calcit.isra.0+0xb8/0xb8 netlink_rcv_skb+0x5b/0xac netlink_unicast+0xfa/0x17b netlink_sendmsg+0x334/0x353 sock_sendmsg_nosec+0xf/0x3f ____sys_sendmsg+0x1a0/0x1fc ? copy_msghdr_from_user+0x4c/0x61 ___sys_sendmsg+0x63/0x84 ? handle_mm_fault+0xa39/0x11b5 ? sockfd_lookup_light+0x72/0x9a __sys_sendmsg+0x50/0x6e do_syscall_64+0x54/0xbe entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f10dacc0bb7 Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb cd 66 0f 1f 44 00 00 8b 05 9a 4b 2b 00 85 c0 75 2e 48 63 ff 48 63 d2 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 b1 f2 2a 00 f7 d8 64 89 02 48 RSP: 002b:00007ffcbe628bf8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007ffcbe628f80 RCX: 00007f10dacc0bb7 RDX: 0000000000000000 RSI: 00007ffcbe628c60 RDI: 0000000000000003 RBP: 000000005f41099c R08: 0000000000000001 R09: 0000000000000008 R10: 00000000000005e9 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007ffcbe628d70 R15: 0000563a86c6e440 Modules linked in: CR2: 0000000000000080 CC: David Ahern Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Reported-by: syzbot+a61aa19b0c14c8770bd9@syzkaller.appspotmail.com Signed-off-by: Nikolay Aleksandrov Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a75f8a60c415325c7ce3df90bfe1b782f84b78cf Author: Miaohe Lin Date: Sat Aug 15 04:44:31 2020 -0400 net: Fix potential wrong skb->protocol in skb_vlan_untag() [ Upstream commit 55eff0eb7460c3d50716ed9eccf22257b046ca92 ] We may access the two bytes after vlan_hdr in vlan_set_encap_proto(). So we should pull VLAN_HLEN + sizeof(unsigned short) in skb_vlan_untag() or we may access the wrong data. Fixes: 0d5501c1c828 ("net: Always untag vlan-tagged traffic on input.") Signed-off-by: Miaohe Lin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f13223bb0b19e978348e38be453ffa810017742 Author: Mark Tomlinson Date: Wed Aug 19 13:53:58 2020 +1200 gre6: Fix reception with IP6_TNL_F_RCV_DSCP_COPY [ Upstream commit 272502fcb7cda01ab07fc2fcff82d1d2f73d43cc ] When receiving an IPv4 packet inside an IPv6 GRE packet, and the IP6_TNL_F_RCV_DSCP_COPY flag is set on the tunnel, the IPv4 header would get corrupted. This is due to the common ip6_tnl_rcv() function assuming that the inner header is always IPv6. This patch checks the tunnel protocol for IPv4 inner packets, but still defaults to IPv6. Fixes: 308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions") Signed-off-by: Mark Tomlinson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 47dcb7fcad1d6dc6942769ec9b0b9b22c7a65f8d Author: Greg Kroah-Hartman Date: Wed Aug 26 11:49:20 2020 +0200 Linux 5.8.4 Tested-by: Jon Hunter Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman commit 920ebff48be39827e6c8c9da6ec6aafc4e507e61 Author: Alex Deucher Date: Mon Aug 24 12:10:29 2020 -0400 Revert "drm/amd/display: Improve DisplayPort monitor interop" This reverts commit 1adb2ff1f6b170cdbc3925a359c8f39d2215dc20. This breaks display wake up in stable kernels (5.7.x and 5.8.x). Note that there is no upstream equivalent to this revert. This patch was targeted for stable by Sasha's stable patch process. Presumably there are some other changes necessary for this patch to work properly on stable kernels. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1266 Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org # 5.7.x, 5.8.x Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d0a3a0136337853fa977e20ddb110104f6804871 Author: Will Deacon Date: Tue Aug 11 11:27:25 2020 +0100 KVM: arm64: Only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is not set commit b5331379bc62611d1026173a09c73573384201d9 upstream. When an MMU notifier call results in unmapping a range that spans multiple PGDs, we end up calling into cond_resched_lock() when crossing a PGD boundary, since this avoids running into RCU stalls during VM teardown. Unfortunately, if the VM is destroyed as a result of OOM, then blocking is not permitted and the call to the scheduler triggers the following BUG(): | BUG: sleeping function called from invalid context at arch/arm64/kvm/mmu.c:394 | in_atomic(): 1, irqs_disabled(): 0, non_block: 1, pid: 36, name: oom_reaper | INFO: lockdep is turned off. | CPU: 3 PID: 36 Comm: oom_reaper Not tainted 5.8.0 #1 | Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 | Call trace: | dump_backtrace+0x0/0x284 | show_stack+0x1c/0x28 | dump_stack+0xf0/0x1a4 | ___might_sleep+0x2bc/0x2cc | unmap_stage2_range+0x160/0x1ac | kvm_unmap_hva_range+0x1a0/0x1c8 | kvm_mmu_notifier_invalidate_range_start+0x8c/0xf8 | __mmu_notifier_invalidate_range_start+0x218/0x31c | mmu_notifier_invalidate_range_start_nonblock+0x78/0xb0 | __oom_reap_task_mm+0x128/0x268 | oom_reap_task+0xac/0x298 | oom_reaper+0x178/0x17c | kthread+0x1e4/0x1fc | ret_from_fork+0x10/0x30 Use the new 'flags' argument to kvm_unmap_hva_range() to ensure that we only reschedule if MMU_NOTIFIER_RANGE_BLOCKABLE is set in the notifier flags. Cc: Fixes: 8b3405e345b5 ("kvm: arm/arm64: Fix locking for kvm_free_stage2_pgd") Cc: Marc Zyngier Cc: Suzuki K Poulose Cc: James Morse Signed-off-by: Will Deacon Message-Id: <20200811102725.7121-3-will@kernel.org> Signed-off-by: Paolo Bonzini Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit af3093319fced456e1271a0f7645440dc6142f0a Author: Will Deacon Date: Tue Aug 11 11:27:24 2020 +0100 KVM: Pass MMU notifier range flags to kvm_unmap_hva_range() commit fdfe7cbd58806522e799e2a50a15aee7f2cbb7b6 upstream. The 'flags' field of 'struct mmu_notifier_range' is used to indicate whether invalidate_range_{start,end}() are permitted to block. In the case of kvm_mmu_notifier_invalidate_range_start(), this field is not forwarded on to the architecture-specific implementation of kvm_unmap_hva_range() and therefore the backend cannot sensibly decide whether or not to block. Add an extra 'flags' parameter to kvm_unmap_hva_range() so that architectures are aware as to whether or not they are permitted to block. Cc: Cc: Marc Zyngier Cc: Suzuki K Poulose Cc: James Morse Signed-off-by: Will Deacon Message-Id: <20200811102725.7121-2-will@kernel.org> Signed-off-by: Paolo Bonzini Signed-off-by: Will Deacon Signed-off-by: Greg Kroah-Hartman commit d9903e8c2576d9c933ae55fc4bab1f55e85f66e0 Author: Al Viro Date: Sat Aug 22 18:25:52 2020 -0400 do_epoll_ctl(): clean the failure exits up a bit commit 52c479697c9b73f628140dcdfcd39ea302d05482 upstream. Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 1f802ace4bd5a2762a2e8637f2ea1e3aa31fb0d5 Author: Arvind Sankar Date: Thu Aug 13 14:58:11 2020 -0400 efi/libstub: Handle unterminated cmdline commit 8a8a3237a78cbc0557f0eb16a89f16d616323e99 upstream. Make the command line parsing more robust, by handling the case it is not NUL-terminated. Use strnlen instead of strlen, and make sure that the temporary copy is NUL-terminated before parsing. Cc: Signed-off-by: Arvind Sankar Link: https://lore.kernel.org/r/20200813185811.554051-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit ca60a5eb83720d0eb425e6192723afa77ac86a73 Author: Arvind Sankar Date: Wed Jul 29 15:33:00 2020 -0400 efi/libstub: Handle NULL cmdline commit a37ca6a2af9df2972372b918f09390c9303acfbd upstream. Treat a NULL cmdline the same as empty. Although this is unlikely to happen in practice, the x86 kernel entry does check for NULL cmdline and handles it, so do it here as well. Cc: Signed-off-by: Arvind Sankar Link: https://lore.kernel.org/r/20200729193300.598448-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 3bff856ba44d73cf6b17a8232d7ce444a7f21907 Author: Arvind Sankar Date: Sat Jul 25 11:59:16 2020 -0400 efi/libstub: Stop parsing arguments at "--" commit 1fd9717d75df68e3c3509b8e7b1138ca63472f88 upstream. Arguments after "--" are arguments for init, not for the kernel. Cc: Signed-off-by: Arvind Sankar Link: https://lore.kernel.org/r/20200725155916.1376773-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit e6584124b9823151ef586d10dedf565ade50cea6 Author: Li Heng Date: Mon Jul 20 15:22:18 2020 +0800 efi: add missed destroy_workqueue when efisubsys_init fails commit 98086df8b70c06234a8f4290c46064e44dafa0ed upstream. destroy_workqueue() should be called to destroy efi_rts_wq when efisubsys_init() init resources fails. Cc: Reported-by: Hulk Robot Signed-off-by: Li Heng Link: https://lore.kernel.org/r/1595229738-10087-1-git-send-email-liheng40@huawei.com Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 09a30705079804acfe7d29ba0618db466fc0df25 Author: Arvind Sankar Date: Fri Jul 17 15:45:26 2020 -0400 efi/x86: Mark kernel rodata non-executable for mixed mode commit c8502eb2d43b6b9b1dc382299a4d37031be63876 upstream. When remapping the kernel rodata section RO in the EFI pagetables, the protection flags that were used for the text section are being reused, but the rodata section should not be marked executable. Cc: Signed-off-by: Arvind Sankar Link: https://lore.kernel.org/r/20200717194526.3452089-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 3d9ed544ec9b8410414a3dfd27e9e89f95044c61 Author: Tony Luck Date: Tue Jul 7 12:43:24 2020 -0700 EDAC/{i7core,sb,pnd2,skx}: Fix error event severity commit 45bc6098a3e279d8e391d22428396687562797e2 upstream. IA32_MCG_STATUS.RIPV indicates whether the return RIP value pushed onto the stack as part of machine check delivery is valid or not. Various drivers copied a code fragment that uses the RIPV bit to determine the severity of the error as either HW_EVENT_ERR_UNCORRECTED or HW_EVENT_ERR_FATAL, but this check is reversed (marking errors where RIPV is set as "FATAL"). Reverse the tests so that the error is marked fatal when RIPV is not set. Reported-by: Gabriele Paoloni Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Cc: Link: https://lkml.kernel.org/r/20200707194324.14884-1-tony.luck@intel.com Signed-off-by: Greg Kroah-Hartman commit 979a9c0058f9162fe8e3b5b77d963dbe2950b816 Author: Vasant Hegde Date: Thu Aug 20 11:48:44 2020 +0530 powerpc/pseries: Do not initiate shutdown when system is running on UPS commit 90a9b102eddf6a3f987d15f4454e26a2532c1c98 upstream. As per PAPR we have to look for both EPOW sensor value and event modifier to identify the type of event and take appropriate action. In LoPAPR v1.1 section 10.2.2 includes table 136 "EPOW Action Codes": SYSTEM_SHUTDOWN 3 The system must be shut down. An EPOW-aware OS logs the EPOW error log information, then schedules the system to be shut down to begin after an OS defined delay internal (default is 10 minutes.) Then in section 10.3.2.2.8 there is table 146 "Platform Event Log Format, Version 6, EPOW Section", which includes the "EPOW Event Modifier": For EPOW sensor value = 3 0x01 = Normal system shutdown with no additional delay 0x02 = Loss of utility power, system is running on UPS/Battery 0x03 = Loss of system critical functions, system should be shutdown 0x04 = Ambient temperature too high All other values = reserved We have a user space tool (rtas_errd) on LPAR to monitor for EPOW_SHUTDOWN_ON_UPS. Once it gets an event it initiates shutdown after predefined time. It also starts monitoring for any new EPOW events. If it receives "Power restored" event before predefined time it will cancel the shutdown. Otherwise after predefined time it will shutdown the system. Commit 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown") changed our handling of the "on UPS/Battery" case, to immediately shutdown the system. This breaks existing setups that rely on the userspace tool to delay shutdown and let the system run on the UPS. Fixes: 79872e35469b ("powerpc/pseries: All events of EPOW_SYSTEM_SHUTDOWN must initiate shutdown") Cc: stable@vger.kernel.org # v4.0+ Signed-off-by: Vasant Hegde [mpe: Massage change log and add PAPR references] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200820061844.306460-1-hegdevasant@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman commit d9b227a03e9ae967c39f3fe07cfe87cabcfe5b95 Author: Michael Neuling Date: Mon Aug 3 13:56:00 2020 +1000 powerpc: Fix P10 PVR revision in /proc/cpuinfo for SMT4 cores commit 030a2c689fb46e1690f7ded8b194bab7678efb28 upstream. On POWER10 bit 12 in the PVR indicates if the core is SMT4 or SMT8. Bit 12 is set for SMT4. Without this patch, /proc/cpuinfo on a SMT4 DD1 POWER10 looks like this: cpu : POWER10, altivec supported revision : 17.0 (pvr 0080 1100) Fixes: a3ea40d5c736 ("powerpc: Add POWER10 architected mode") Cc: stable@vger.kernel.org # v5.8 Signed-off-by: Michael Neuling Reviewed-by: Vaidyanathan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200803035600.1820371-1-mikey@neuling.org Signed-off-by: Greg Kroah-Hartman commit c09886c19233e1cdadb921d1f40566769b1e2037 Author: Marc Zyngier Date: Wed Aug 19 17:12:17 2020 +0100 epoll: Keep a reference on files added to the check list commit a9ed4a6560b8562b7e2e2bed9527e88001f7b682 upstream. When adding a new fd to an epoll, and that this new fd is an epoll fd itself, we recursively scan the fds attached to it to detect cycles, and add non-epool files to a "check list" that gets subsequently parsed. However, this check list isn't completely safe when deletions can happen concurrently. To sidestep the issue, make sure that a struct file placed on the check list sees its f_count increased, ensuring that a concurrent deletion won't result in the file disapearing from under our feet. Cc: stable@vger.kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 3489cea04a4bf0632dddd34424d0fe07d6d02f5b Author: Tom Rix Date: Fri Aug 21 06:56:00 2020 -0700 net: dsa: b53: check for timeout [ Upstream commit 774d977abfd024e6f73484544b9abe5a5cd62de7 ] clang static analysis reports this problem b53_common.c:1583:13: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage ent.port &= ~BIT(port); ~~~~~~~~ ^ ent is set by a successful call to b53_arl_read(). Unsuccessful calls are caught by an switch statement handling specific returns. b32_arl_read() calls b53_arl_op_wait() which fails with the unhandled -ETIMEDOUT. So add -ETIMEDOUT to the switch statement. Because b53_arl_op_wait() already prints out a message, do not add another one. Fixes: 1da6df85c6fb ("net: dsa: b53: Implement ARL add/del/dump operations") Signed-off-by: Tom Rix Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0c831e9dad9defeb4129369e2ddc53af8bc8c33a Author: Haiyang Zhang Date: Thu Aug 20 14:53:15 2020 -0700 hv_netvsc: Fix the queue_mapping in netvsc_vf_xmit() [ Upstream commit c3d897e01aef8ddc43149e4d661b86f823e3aae7 ] netvsc_vf_xmit() / dev_queue_xmit() will call VF NIC’s ndo_select_queue or netdev_pick_tx() again. They will use skb_get_rx_queue() to get the queue number, so the “skb->queue_mapping - 1” will be used. This may cause the last queue of VF not been used. Use skb_record_rx_queue() here, so that the skb_get_rx_queue() called later will get the correct queue number, and VF will be able to use all queues. Fixes: b3bf5666a510 ("hv_netvsc: defer queue selection to VF") Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d446604e432c4dde97bbb0dba5d6c73892344d75 Author: Veronika Kabatova Date: Wed Aug 19 18:07:10 2020 +0200 selftests/bpf: Remove test_align leftovers [ Upstream commit 5597432dde62befd3ab92e6ef9e073564e277ea8 ] Calling generic selftests "make install" fails as rsync expects all files from TEST_GEN_PROGS to be present. The binary is not generated anymore (commit 3b09d27cc93d) so we can safely remove it from there and also from gitignore. Fixes: 3b09d27cc93d ("selftests/bpf: Move test_align under test_progs") Signed-off-by: Veronika Kabatova Signed-off-by: Alexei Starovoitov Acked-by: Jesper Dangaard Brouer Link: https://lore.kernel.org/bpf/20200819160710.1345956-1-vkabatov@redhat.com Signed-off-by: Sasha Levin commit 9500db5480f80d76e3aa77c2099f8db283ec2462 Author: Wang Hai Date: Wed Aug 19 10:33:09 2020 +0800 net: gemini: Fix missing free_netdev() in error path of gemini_ethernet_port_probe() [ Upstream commit cf96d977381d4a23957bade2ddf1c420b74a26b6 ] Replace alloc_etherdev_mq with devm_alloc_etherdev_mqs. In this way, when probe fails, netdev can be freed automatically. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit af4a56476ddd64e807623140c92b7ed23051dda0 Author: Shay Agroskin Date: Wed Aug 19 20:28:37 2020 +0300 net: ena: Change WARN_ON expression in ena_del_napi_in_range() [ Upstream commit 8b147f6f3e7de4e51113e3e9ec44aa2debc02c58 ] The ena_del_napi_in_range() function unregisters the napi handler for rings in a given range. This function had the following WARN_ON macro: WARN_ON(ENA_IS_XDP_INDEX(adapter, i) && adapter->ena_napi[i].xdp_ring); This macro prints the call stack if the expression inside of it is true [1], but the expression inside of it is the wanted situation. The expression checks whether the ring has an XDP queue and its index corresponds to a XDP one. This patch changes the expression to !ENA_IS_XDP_INDEX(adapter, i) && adapter->ena_napi[i].xdp_ring which indicates an unwanted situation. Also, change the structure of the function. The napi handler is unregistered for all rings, and so there's no need to check whether the index is an XDP index or not. By removing this check the code becomes much more readable. Fixes: 548c4940b9f1 ("net: ena: Implement XDP_TX action") Signed-off-by: Shay Agroskin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8c01a77d28bf95bd89591ef7a0ef3ff0db5e537d Author: Shay Agroskin Date: Wed Aug 19 20:28:36 2020 +0300 net: ena: Prevent reset after device destruction [ Upstream commit 63d4a4c145cca2e84dc6e62d2ef5cb990c9723c2 ] The reset work is scheduled by the timer routine whenever it detects that a device reset is required (e.g. when a keep_alive signal is missing). When releasing device resources in ena_destroy_device() the driver cancels the scheduling of the timer routine without destroying the reset work explicitly. This creates the following bug: The driver is suspended and the ena_suspend() function is called -> This function calls ena_destroy_device() to free the net device resources -> The driver waits for the timer routine to finish its execution and then cancels it, thus preventing from it to be called again. If, in its final execution, the timer routine schedules a reset, the reset routine might be called afterwards,and a redundant call to ena_restore_device() would be made. By changing the reset routine we allow it to read the device's state accurately. This is achieved by checking whether ENA_FLAG_TRIGGER_RESET flag is set before resetting the device and making both the destruction function and the flag check are under rtnl lock. The ENA_FLAG_TRIGGER_RESET is cleared at the end of the destruction routine. Also surround the flag check with 'likely' because we expect that the reset routine would be called only when ENA_FLAG_TRIGGER_RESET flag is set. The destruction of the timer and reset services in __ena_shutoff() have to stay, even though the timer routine is destroyed in ena_destroy_device(). This is to avoid a case in which the reset routine is scheduled after free_netdev() in __ena_shutoff(), which would create an access to freed memory in adapter->flags. Fixes: 8c5c7abdeb2d ("net: ena: add power management ops to the ENA driver") Signed-off-by: Shay Agroskin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3c1d705f29c6e98eb6981469962180ad6639c70f Author: Jiri Wiesner Date: Sun Aug 16 20:52:44 2020 +0200 bonding: fix active-backup failover for current ARP slave [ Upstream commit 0410d07190961ac526f05085765a8d04d926545b ] When the ARP monitor is used for link detection, ARP replies are validated for all slaves (arp_validate=3) and fail_over_mac is set to active, two slaves of an active-backup bond may get stuck in a state where both of them are active and pass packets that they receive to the bond. This state makes IPv6 duplicate address detection fail. The state is reached thus: 1. The current active slave goes down because the ARP target is not reachable. 2. The current ARP slave is chosen and made active. 3. A new slave is enslaved. This new slave becomes the current active slave and can reach the ARP target. As a result, the current ARP slave stays active after the enslave action has finished and the log is littered with "PROBE BAD" messages: > bond0: PROBE: c_arp ens10 && cas ens11 BAD The workaround is to remove the slave with "going back" status from the bond and re-enslave it. This issue was encountered when DPDK PMD interfaces were being enslaved to an active-backup bond. I would be possible to fix the issue in bond_enslave() or bond_change_active_slave() but the ARP monitor was fixed instead to keep most of the actions changing the current ARP slave in the ARP monitor code. The current ARP slave is set as inactive and backup during the commit phase. A new state, BOND_LINK_FAIL, has been introduced for slaves in the context of the ARP monitor. This allows administrators to see how slaves are rotated for sending ARP requests and attempts are made to find a new active slave. Fixes: b2220cad583c9 ("bonding: refactor ARP active-backup monitor") Signed-off-by: Jiri Wiesner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f6c6b312efef93f9e6889ebd2a88902fad071c94 Author: Michael Roth Date: Tue Aug 11 11:15:44 2020 -0500 powerpc/pseries/hotplug-cpu: wait indefinitely for vCPU death [ Upstream commit 801980f6497946048709b9b09771a1729551d705 ] For a power9 KVM guest with XIVE enabled, running a test loop where we hotplug 384 vcpus and then unplug them, the following traces can be seen (generally within a few loops) either from the unplugged vcpu: cpu 65 (hwid 65) Ready to die... Querying DEAD? cpu 66 (66) shows 2 list_del corruption. next->prev should be c00a000002470208, but was c00a000002470048 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! Oops: Exception in kernel mode, sig: 5 [#1] LE SMP NR_CPUS=2048 NUMA pSeries Modules linked in: fuse nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 ... CPU: 66 PID: 0 Comm: swapper/66 Kdump: loaded Not tainted 4.18.0-221.el8.ppc64le #1 NIP: c0000000007ab50c LR: c0000000007ab508 CTR: 00000000000003ac REGS: c0000009e5a17840 TRAP: 0700 Not tainted (4.18.0-221.el8.ppc64le) MSR: 800000000282b033 CR: 28000842 XER: 20040000 ... NIP __list_del_entry_valid+0xac/0x100 LR __list_del_entry_valid+0xa8/0x100 Call Trace: __list_del_entry_valid+0xa8/0x100 (unreliable) free_pcppages_bulk+0x1f8/0x940 free_unref_page+0xd0/0x100 xive_spapr_cleanup_queue+0x148/0x1b0 xive_teardown_cpu+0x1bc/0x240 pseries_mach_cpu_die+0x78/0x2f0 cpu_die+0x48/0x70 arch_cpu_idle_dead+0x20/0x40 do_idle+0x2f4/0x4c0 cpu_startup_entry+0x38/0x40 start_secondary+0x7bc/0x8f0 start_secondary_prolog+0x10/0x14 or on the worker thread handling the unplug: pseries-hotplug-cpu: Attempting to remove CPU , drc index: 1000013a Querying DEAD? cpu 314 (314) shows 2 BUG: Bad page state in process kworker/u768:3 pfn:95de1 cpu 314 (hwid 314) Ready to die... page:c00a000002577840 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 flags: 0x5ffffc00000000() raw: 005ffffc00000000 5deadbeef0000100 5deadbeef0000200 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount Modules linked in: kvm xt_CHECKSUM ipt_MASQUERADE xt_conntrack ... CPU: 0 PID: 548 Comm: kworker/u768:3 Kdump: loaded Not tainted 4.18.0-224.el8.bz1856588.ppc64le #1 Workqueue: pseries hotplug workque pseries_hp_work_fn Call Trace: dump_stack+0xb0/0xf4 (unreliable) bad_page+0x12c/0x1b0 free_pcppages_bulk+0x5bc/0x940 page_alloc_cpu_dead+0x118/0x120 cpuhp_invoke_callback.constprop.5+0xb8/0x760 _cpu_down+0x188/0x340 cpu_down+0x5c/0xa0 cpu_subsys_offline+0x24/0x40 device_offline+0xf0/0x130 dlpar_offline_cpu+0x1c4/0x2a0 dlpar_cpu_remove+0xb8/0x190 dlpar_cpu_remove_by_index+0x12c/0x150 dlpar_cpu+0x94/0x800 pseries_hp_work_fn+0x128/0x1e0 process_one_work+0x304/0x5d0 worker_thread+0xcc/0x7a0 kthread+0x1ac/0x1c0 ret_from_kernel_thread+0x5c/0x80 The latter trace is due to the following sequence: page_alloc_cpu_dead drain_pages drain_pages_zone free_pcppages_bulk where drain_pages() in this case is called under the assumption that the unplugged cpu is no longer executing. To ensure that is the case, and early call is made to __cpu_die()->pseries_cpu_die(), which runs a loop that waits for the cpu to reach a halted state by polling its status via query-cpu-stopped-state RTAS calls. It only polls for 25 iterations before giving up, however, and in the trace above this results in the following being printed only .1 seconds after the hotplug worker thread begins processing the unplug request: pseries-hotplug-cpu: Attempting to remove CPU , drc index: 1000013a Querying DEAD? cpu 314 (314) shows 2 At that point the worker thread assumes the unplugged CPU is in some unknown/dead state and procedes with the cleanup, causing the race with the XIVE cleanup code executed by the unplugged CPU. Fix this by waiting indefinitely, but also making an effort to avoid spurious lockup messages by allowing for rescheduling after polling the CPU status and printing a warning if we wait for longer than 120s. Fixes: eac1e731b59ee ("powerpc/xive: guest exploitation of the XIVE interrupt controller") Suggested-by: Michael Ellerman Signed-off-by: Michael Roth Tested-by: Greg Kurz Reviewed-by: Thiago Jung Bauermann Reviewed-by: Greg Kurz [mpe: Trim oopses in change log slightly for readability] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200811161544.10513-1-mdroth@linux.vnet.ibm.com Signed-off-by: Sasha Levin commit 63f10205a215f9cdb527102ce394da03fa635ab3 Author: Yonghong Song Date: Mon Aug 17 10:42:14 2020 -0700 bpf: Use get_file_rcu() instead of get_file() for task_file iterator [ Upstream commit cf28f3bbfca097d956f9021cb710dfad56adcc62 ] With latest `bpftool prog` command, we observed the following kernel panic. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD dfe894067 P4D dfe894067 PUD deb663067 PMD 0 Oops: 0010 [#1] SMP CPU: 9 PID: 6023 ... RIP: 0010:0x0 Code: Bad RIP value. RSP: 0000:ffffc900002b8f18 EFLAGS: 00010286 RAX: ffff8883a405f400 RBX: ffff888e46a6bf00 RCX: 000000008020000c RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8883a405f400 RBP: ffff888e46a6bf50 R08: 0000000000000000 R09: ffffffff81129600 R10: ffff8883a405f300 R11: 0000160000000000 R12: 0000000000002710 R13: 000000e9494b690c R14: 0000000000000202 R15: 0000000000000009 FS: 00007fd9187fe700(0000) GS:ffff888e46a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000de5d33002 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rcu_core+0x1a4/0x440 __do_softirq+0xd3/0x2c8 irq_exit+0x9d/0xa0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 RIP: 0033:0x47ce80 Code: Bad RIP value. RSP: 002b:00007fd9187fba40 EFLAGS: 00000206 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000002 RBX: 00007fd931789160 RCX: 000000000000010c RDX: 00007fd9308cdfb4 RSI: 00007fd9308cdfb4 RDI: 00007ffedd1ea0a8 RBP: 00007fd9187fbab0 R08: 000000000000000e R09: 000000000000002a R10: 0000000000480210 R11: 00007fd9187fc570 R12: 00007fd9316cc400 R13: 0000000000000118 R14: 00007fd9308cdfb4 R15: 00007fd9317a9380 After further analysis, the bug is triggered by Commit eaaacd23910f ("bpf: Add task and task/file iterator targets") which introduced task_file bpf iterator, which traverses all open file descriptors for all tasks in the current namespace. The latest `bpftool prog` calls a task_file bpf program to traverse all files in the system in order to associate processes with progs/maps, etc. When traversing files for a given task, rcu read_lock is taken to access all files in a file_struct. But it used get_file() to grab a file, which is not right. It is possible file->f_count is 0 and get_file() will unconditionally increase it. Later put_file() may cause all kind of issues with the above as one of sympotoms. The failure can be reproduced with the following steps in a few seconds: $ cat t.c #include #include #include #include #include #define N 10000 int fd[N]; int main() { int i; for (i = 0; i < N; i++) { fd[i] = open("./note.txt", 'r'); if (fd[i] < 0) { fprintf(stderr, "failed\n"); return -1; } } for (i = 0; i < N; i++) close(fd[i]); return 0; } $ gcc -O2 t.c $ cat run.sh #/bin/bash for i in {1..100} do while true; do ./a.out; done & done $ ./run.sh $ while true; do bpftool prog >& /dev/null; done This patch used get_file_rcu() which only grabs a file if the file->f_count is not zero. This is to ensure the file pointer is always valid. The above reproducer did not fail for more than 30 minutes. Fixes: eaaacd23910f ("bpf: Add task and task/file iterator targets") Suggested-by: Josef Bacik Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Reviewed-by: Josef Bacik Link: https://lore.kernel.org/bpf/20200817174214.252601-1-yhs@fb.com Signed-off-by: Sasha Levin commit 2fe8be1a33d505a9d370c8c95a223615ec32776e Author: Christophe Leroy Date: Mon Aug 17 06:03:26 2020 +0000 powerpc/fixmap: Fix the size of the early debug area [ Upstream commit fdc6edbb31fba76fd25d7bd016b675a92908d81e ] Commit ("03fd42d458fb powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k") reworked the setup of the early debug area and mistakenly replaced 128 * 1024 by SZ_128. Change to SZ_128K to restore the original 128 kbytes size of the area. Fixes: 03fd42d458fb ("powerpc/fixmap: Fix FIX_EARLY_DEBUG_BASE when page size is 256k") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/996184974d674ff984643778cf1cdd7fe58cc065.1597644194.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 6f1d3ac25b59af156ec6e1059be52aa96cbd1e5f Author: Stephen Boyd Date: Mon Aug 17 18:49:50 2020 -0700 ARM64: vdso32: Install vdso32 from vdso_install [ Upstream commit 8d75785a814241587802655cc33e384230744f0c ] Add the 32-bit vdso Makefile to the vdso_install rule so that 'make vdso_install' installs the 32-bit compat vdso when it is compiled. Fixes: a7f71a2c8903 ("arm64: compat: Add vDSO") Signed-off-by: Stephen Boyd Reviewed-by: Vincenzo Frascino Acked-by: Will Deacon Cc: Vincenzo Frascino Link: https://lore.kernel.org/r/20200818014950.42492-1-swboyd@chromium.org Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 88d78fa3426fb1f23a5901dcd3b2523b3a0a685e Author: David Howells Date: Fri Aug 21 10:15:12 2020 +0100 afs: Fix NULL deref in afs_dynroot_depopulate() [ Upstream commit 5e0b17b026eb7c6de9baa9b0d45a51b05f05abe1 ] If an error occurs during the construction of an afs superblock, it's possible that an error occurs after a superblock is created, but before we've created the root dentry. If the superblock has a dynamic root (ie. what's normally mounted on /afs), the afs_kill_super() will call afs_dynroot_depopulate() to unpin any created dentries - but this will oops if the root hasn't been created yet. Fix this by skipping that bit of code if there is no root dentry. This leads to an oops looking like: general protection fault, ... KASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f] ... RIP: 0010:afs_dynroot_depopulate+0x25f/0x529 fs/afs/dynroot.c:385 ... Call Trace: afs_kill_super+0x13b/0x180 fs/afs/super.c:535 deactivate_locked_super+0x94/0x160 fs/super.c:335 afs_get_tree+0x1124/0x1460 fs/afs/super.c:598 vfs_get_tree+0x89/0x2f0 fs/super.c:1547 do_new_mount fs/namespace.c:2875 [inline] path_mount+0x1387/0x2070 fs/namespace.c:3192 do_mount fs/namespace.c:3205 [inline] __do_sys_mount fs/namespace.c:3413 [inline] __se_sys_mount fs/namespace.c:3390 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3390 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 which is oopsing on this line: inode_lock(root->d_inode); presumably because sb->s_root was NULL. Fixes: 0da0b7fd73e4 ("afs: Display manually added cells in dynamic root mount") Reported-by: syzbot+c1eff8205244ae7e11a6@syzkaller.appspotmail.com Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f09a790a6e463b1bdd3d76f77111a11637d65a3e Author: Masahiro Yamada Date: Fri Aug 21 00:16:46 2020 +0900 kconfig: qconf: remove qInfo() to get back Qt4 support [ Upstream commit 53efe2e76ca2bfad7f35e0b5330e2ccd44a643e3 ] qconf is supposed to work with Qt4 and Qt5, but since commit c4f7398bee9c ("kconfig: qconf: make debug links work again"), building with Qt4 fails as follows: HOSTCXX scripts/kconfig/qconf.o scripts/kconfig/qconf.cc: In member function ‘void ConfigInfoView::clicked(const QUrl&)’: scripts/kconfig/qconf.cc:1241:3: error: ‘qInfo’ was not declared in this scope; did you mean ‘setInfo’? 1241 | qInfo() << "Clicked link is empty"; | ^~~~~ | setInfo scripts/kconfig/qconf.cc:1254:3: error: ‘qInfo’ was not declared in this scope; did you mean ‘setInfo’? 1254 | qInfo() << "Clicked symbol is invalid:" << data; | ^~~~~ | setInfo make[1]: *** [scripts/Makefile.host:129: scripts/kconfig/qconf.o] Error 1 make: *** [Makefile:606: xconfig] Error 2 qInfo() does not exist in Qt4. In my understanding, these call-sites should be unreachable. Perhaps, qWarning(), assertion, or something is better, but qInfo() is not the right one to use here, I think. Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Reported-by: Ronald Warsow Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 19881ebab34ff8e0f75006df385a87d8c9e84a79 Author: David Howells Date: Thu Aug 20 14:37:12 2020 +0100 afs: Fix key ref leak in afs_put_operation() [ Upstream commit ba8e42077bbe046a09bdb965dbfbf8c27594fe8f ] The afs_put_operation() function needs to put the reference to the key that's authenticating the operation. Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept") Reported-by: Dave Botsch Signed-off-by: David Howells Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f35bb8426115fca030a3b81fc8b32608a9fe904a Author: Weihang Li Date: Wed Aug 19 17:39:44 2020 +0800 Revert "RDMA/hns: Reserve one sge in order to avoid local length error" [ Upstream commit 6da06c6291f38be4df6df2efb76ba925096d2691 ] This patch caused some issues on SEND operation, and it should be reverted to make the drivers work correctly. There will be a better solution that has been tested carefully to solve the original problem. This reverts commit 711195e57d341e58133d92cf8aaab1db24e4768d. Fixes: 711195e57d34 ("RDMA/hns: Reserve one sge in order to avoid local length error") Link: https://lore.kernel.org/r/1597829984-20223-1-git-send-email-liweihang@huawei.com Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8facd0c47293d125029a344b0872cdec5340f2f9 Author: Selvin Xavier Date: Wed Aug 5 21:45:48 2020 -0700 RDMA/bnxt_re: Do not add user qps to flushlist [ Upstream commit a812f2d60a9fb7818f9c81f967180317b52545c0 ] Driver shall add only the kernel qps to the flush list for clean up. During async error events from the HW, driver is adding qps to this list without checking if the qp is kernel qp or not. Add a check to avoid user qp addition to the flush list. Fixes: 942c9b6ca8de ("RDMA/bnxt_re: Avoid Hard lockup during error CQE processing") Fixes: c50866e2853a ("bnxt_re: fix the regression due to changes in alloc_pbl") Link: https://lore.kernel.org/r/1596689148-4023-1-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Selvin Xavier Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1f43cb1c6f5635384b5419e4b371aa8b1ae46dcc Author: Randy Dunlap Date: Thu Aug 20 06:30:47 2020 +0200 Fix build error when CONFIG_ACPI is not set/enabled: [ Upstream commit ee87e1557c42dc9c2da11c38e11b87c311569853 ] ../arch/x86/pci/xen.c: In function ‘pci_xen_init’: ../arch/x86/pci/xen.c:410:2: error: implicit declaration of function ‘acpi_noirq_set’; did you mean ‘acpi_irq_get’? [-Werror=implicit-function-declaration] acpi_noirq_set(); Fixes: 88e9ca161c13 ("xen/pci: Use acpi_noirq_set() helper to avoid #ifdef") Signed-off-by: Randy Dunlap Reviewed-by: Juergen Gross Cc: Andy Shevchenko Cc: Bjorn Helgaas Cc: Konrad Rzeszutek Wilk Cc: xen-devel@lists.xenproject.org Cc: linux-pci@vger.kernel.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 15f8decf24ed0f07ffada1e6a457082cd788c293 Author: Juergen Gross Date: Fri Jul 10 16:16:51 2020 +0200 efi: avoid error message when booting under Xen [ Upstream commit 6163a985e50cb19d5bdf73f98e45b8af91a77658 ] efifb_probe() will issue an error message in case the kernel is booted as Xen dom0 from UEFI as EFI_MEMMAP won't be set in this case. Avoid that message by calling efi_mem_desc_lookup() only if EFI_MEMMAP is set. Fixes: 38ac0287b7f4 ("fbdev/efifb: Honour UEFI memory map attributes when mapping the FB") Signed-off-by: Juergen Gross Acked-by: Ard Biesheuvel Acked-by: Bartlomiej Zolnierkiewicz Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 80876bf7962d9948996098969a3129ba7c0bacb4 Author: Masahiro Yamada Date: Tue Aug 18 01:36:29 2020 +0900 kconfig: qconf: fix signal connection to invalid slots [ Upstream commit d85de3399f97467baa2026fbbbe587850d01ba8a ] If you right-click in the ConfigList window, you will see the following messages in the console: QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:888 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:897 QObject::connect: (sender name: 'config') QObject::connect: No such slot QAction::setOn(bool) in scripts/kconfig/qconf.cc:906 QObject::connect: (sender name: 'config') Right, there is no such slot in QAction. I think this is a typo of setChecked. Due to this bug, when you toggled the menu "Option->Show Name/Range/Data" the state of the context menu was not previously updated. Fix this. Fixes: d5d973c3f8a9 ("Port xconfig to Qt5 - Put back some of the old implementation(part 2)") Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit a00ac43450bf1308b6f2d478f6f9d2e5c2ad5096 Author: Masahiro Yamada Date: Fri Aug 7 18:19:08 2020 +0900 kconfig: qconf: do not limit the pop-up menu to the first row [ Upstream commit fa8de0a3bf3c02e6f00b7746e7e934db522cdda9 ] If you right-click the first row in the option tree, the pop-up menu shows up, but if you right-click the second row or below, the event is ignored due to the following check: if (e->y() <= header()->geometry().bottom()) { Perhaps, the intention was to show the pop-menu only when the tree header was right-clicked, but this handler is not called in that case. Since the origin of e->y() starts from the bottom of the header, this check is odd. Going forward, you can right-click anywhere in the tree to get the pop-up menu. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit a4d533969b91ea341173ee4c3a0847001dbfc4c0 Author: Quinn Tran Date: Thu Aug 6 04:10:14 2020 -0700 Revert "scsi: qla2xxx: Disable T10-DIF feature with FC-NVMe during probe" [ Upstream commit dca93232b361d260413933903cd4bdbd92ebcc7f ] FCP T10-PI and NVMe features are independent of each other. This patch allows both features to co-exist. This reverts commit 5da05a26b8305a625bc9d537671b981795b46dab. Link: https://lore.kernel.org/r/20200806111014.28434-12-njavali@marvell.com Fixes: 5da05a26b830 ("scsi: qla2xxx: Disable T10-DIF feature with FC-NVMe during probe") Reviewed-by: Himanshu Madhani Signed-off-by: Quinn Tran Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 06e5e83d1fa5ccf26a136ad18447d3fd99f713d4 Author: Adrian Hunter Date: Tue Aug 11 16:39:35 2020 +0300 scsi: ufs: Fix interrupt error message for shared interrupts [ Upstream commit 6337f58cec030b34ced435b3d9d7d29d63c96e36 ] The interrupt might be shared, in which case it is not an error for the interrupt handler to be called when the interrupt status is zero, so don't print the message unless there was enabled interrupt status. Link: https://lore.kernel.org/r/20200811133936.19171-1-adrian.hunter@intel.com Fixes: 9333d7757348 ("scsi: ufs: Fix irq return code") Reviewed-by: Avri Altman Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a3ef038de59aa7cd428892f5a2b154a668673fd5 Author: Adrian Hunter Date: Mon Aug 10 17:10:24 2020 +0300 scsi: ufs-pci: Add quirk for broken auto-hibernate for Intel EHL [ Upstream commit 8da76f71fef7d8a1a72af09d48899573feb60065 ] Intel EHL UFS host controller advertises auto-hibernate capability but it does not work correctly. Add a quirk for that. [mkp: checkpatch fix] Link: https://lore.kernel.org/r/20200810141024.28859-1-adrian.hunter@intel.com Fixes: 8c09d7527697 ("scsi: ufshdc-pci: Add Intel PCI IDs for EHL") Acked-by: Stanley Chu Signed-off-by: Adrian Hunter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 88a3da2e55b020d958110a281b94042ac5a1cf2a Author: Kiwoong Kim Date: Thu May 28 06:46:53 2020 +0530 scsi: ufs: Add quirk to fix abnormal ocs fatal error [ Upstream commit d779a6e90e189f4883ce6f900da02995fb000df5 ] Some controller like Exynos determines if FATAL ERROR (0x7) in OCS field in UTRD occurs for values other than GOOD (0x0) in STATUS field in response upiu as well as errors that a host controller can't cover. This patch is to prevent from reporting command results in those cases. Link: https://lore.kernel.org/r/20200528011658.71590-6-alim.akhtar@samsung.com Reviewed-by: Avri Altman Signed-off-by: Kiwoong Kim Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 65fa4a6ee3b80471aada0cc5a35c9b65791c6024 Author: Alim Akhtar Date: Thu May 28 06:46:52 2020 +0530 scsi: ufs: Introduce UFSHCD_QUIRK_PRDT_BYTE_GRAN quirk [ Upstream commit 26f968d7de823ba4974a8f25c8bd8ee2df6ab74b ] Some UFS host controllers like Exynos uses granularities of PRDT length and offset as bytes, whereas others use actual segment count. Link: https://lore.kernel.org/r/20200528011658.71590-5-alim.akhtar@samsung.com Reviewed-by: Avri Altman Signed-off-by: Kiwoong Kim Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2a0b7adc5d0d3093cc9a71279f1e7028f4b73871 Author: Alim Akhtar Date: Thu May 28 06:46:51 2020 +0530 scsi: ufs: Add quirk to enable host controller without hce [ Upstream commit 39bf2d83b54e900675cd7b52737ded695bb60bf1 ] Some host controllers don't support host controller enable via HCE. Link: https://lore.kernel.org/r/20200528011658.71590-4-alim.akhtar@samsung.com Reviewed-by: Can Guo Reviewed-by: Avri Altman Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 81929755f92e310ccbc25b1b1bd5cea71850a40c Author: Alim Akhtar Date: Thu May 28 06:46:50 2020 +0530 scsi: ufs: Add quirk to disallow reset of interrupt aggregation [ Upstream commit b638b5eb624bd5d0766683b6181d578f414585e9 ] Some host controllers support interrupt aggregation but don't allow resetting counter and timer in software. Link: https://lore.kernel.org/r/20200528011658.71590-3-alim.akhtar@samsung.com Reviewed-by: Avri Altman Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8ab0b065d8bd45756e356d06fec21960be9ce630 Author: Alim Akhtar Date: Thu May 28 06:46:49 2020 +0530 scsi: ufs: Add quirk to fix mishandling utrlclr/utmrlclr [ Upstream commit 871838412adf533ffda0b4a0ede0c2984e3511e7 ] With the correct behavior, setting the bit to '0' indicates clear and '1' indicates no change. If host controller handles this the other way around, UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used. Link: https://lore.kernel.org/r/20200528011658.71590-2-alim.akhtar@samsung.com Reviewed-by: Can Guo Reviewed-by: Avri Altman Signed-off-by: Seungwon Jeon Signed-off-by: Alim Akhtar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c3e9f5c75ebae83562a0e502ac52db91b09ba37e Author: Jing Xiangfeng Date: Thu Aug 6 15:01:35 2020 +0800 scsi: ufs: ti-j721e-ufs: Fix error return in ti_j721e_ufs_probe() [ Upstream commit 2138d1c918246e3d8193c3cb8b6d22d0bb888061 ] Fix to return error code PTR_ERR() from the error handling case instead of 0. Link: https://lore.kernel.org/r/20200806070135.67797-1-jingxiangfeng@huawei.com Fixes: 22617e216331 ("scsi: ufs: ti-j721e-ufs: Fix unwinding of pm_runtime changes") Reviewed-by: Avri Altman Signed-off-by: Jing Xiangfeng Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 3d1bc8c7b20f989721ee471f7d09714d21bdc52e Author: Colin Ian King Date: Mon Aug 17 12:32:08 2020 +0100 of/address: check for invalid range.cpu_addr [ Upstream commit f49c7faf776f16607c948d852a03b04a88c3b583 ] Currently invalid CPU addresses are not being sanity checked resulting in SATA setup failure on a SynQuacer SC2A11 development machine. The original check was removed by and earlier commit, so add a sanity check back in to avoid this regression. Fixes: 7a8b64d17e35 ("of/address: use range parser for of_dma_get_range") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20200817113208.523805-1-colin.king@canonical.com Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit e10e99e4872b3c73e847d0843149af6145cba0d3 Author: Jim Mattson Date: Mon Aug 17 11:16:54 2020 -0700 kvm: x86: Toggling CR4.PKE does not load PDPTEs in PAE mode [ Upstream commit cb957adb4ea422bd758568df5b2478ea3bb34f35 ] See the SDM, volume 3, section 4.4.1: If PAE paging would be in use following an execution of MOV to CR0 or MOV to CR4 (see Section 4.1.1) and the instruction is modifying any of CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP; then the PDPTEs are loaded from the address in CR3. Fixes: b9baba8614890 ("KVM, pkeys: expose CPUID/CR4 to guest") Cc: Huaitong Han Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Reviewed-by: Oliver Upton Message-Id: <20200817181655.3716509-1-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit cfc52749f05049a9973f686d4643d0f4345cde53 Author: Jim Mattson Date: Mon Aug 17 11:16:55 2020 -0700 kvm: x86: Toggling CR4.SMAP does not load PDPTEs in PAE mode [ Upstream commit 427890aff8558eb4326e723835e0eae0e6fe3102 ] See the SDM, volume 3, section 4.4.1: If PAE paging would be in use following an execution of MOV to CR0 or MOV to CR4 (see Section 4.1.1) and the instruction is modifying any of CR0.CD, CR0.NW, CR0.PG, CR4.PAE, CR4.PGE, CR4.PSE, or CR4.SMEP; then the PDPTEs are loaded from the address in CR3. Fixes: 0be0226f07d14 ("KVM: MMU: fix SMAP virtualization") Cc: Xiao Guangrong Signed-off-by: Jim Mattson Reviewed-by: Peter Shier Reviewed-by: Oliver Upton Message-Id: <20200817181655.3716509-2-jmattson@google.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 753d60c620038f0546484cea73e7ba784e9c5a3a Author: Jessica Clarke Date: Tue Aug 11 19:24:57 2020 +0100 arch/ia64: Restore arch-specific pgd_offset_k implementation [ Upstream commit bd05220c7be3356046861c317d9c287ca50445ba ] IA-64 is special and treats pgd_offset_k() differently to pgd_offset(), using different formulae to calculate the indices into the kernel and user PGDs. The index into the user PGDs takes into account the region number, but the index into the kernel (init_mm) PGD always assumes a predefined kernel region number. Commit 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*() definitions") made IA-64 use a generic pgd_offset_k() which incorrectly used pgd_index() for kernel page tables. As a result, the index into the kernel PGD was going out of bounds and the kernel hung during early boot. Allow overrides of pgd_offset_k() and override it on IA-64 with the old implementation that will correctly index the kernel PGD. Fixes: 974b9b2c68f3 ("mm: consolidate pte_index() and pte_offset_*() definitions") Reported-by: John Paul Adrian Glaubitz Signed-off-by: Jessica Clarke Tested-by: John Paul Adrian Glaubitz Acked-by: Tony Luck Signed-off-by: Mike Rapoport Signed-off-by: Sasha Levin commit c9486fc5f69bd2e41ca3747f4c30054f9266ca3f Author: Alex Williamson Date: Mon Aug 17 11:09:13 2020 -0600 vfio/type1: Add proper error unwind for vfio_iommu_replay() [ Upstream commit aae7a75a821a793ed6b8ad502a5890fb8e8f172d ] The vfio_iommu_replay() function does not currently unwind on error, yet it does pin pages, perform IOMMU mapping, and modify the vfio_dma structure to indicate IOMMU mapping. The IOMMU mappings are torn down when the domain is destroyed, but the other actions go on to cause trouble later. For example, the iommu->domain_list can be empty if we only have a non-IOMMU backed mdev attached. We don't currently check if the list is empty before getting the first entry in the list, which leads to a bogus domain pointer. If a vfio_dma entry is erroneously marked as iommu_mapped, we'll attempt to use that bogus pointer to retrieve the existing physical page addresses. This is the scenario that uncovered this issue, attempting to hot-add a vfio-pci device to a container with an existing mdev device and DMA mappings, one of which could not be pinned, causing a failure adding the new group to the existing container and setting the conditions for a subsequent attempt to explode. To resolve this, we can first check if the domain_list is empty so that we can reject replay of a bogus domain, should we ever encounter this inconsistent state again in the future. The real fix though is to add the necessary unwind support, which means cleaning up the current pinning if an IOMMU mapping fails, then walking back through the r-b tree of DMA entries, reading from the IOMMU which ranges are mapped, and unmapping and unpinning those ranges. To be able to do this, we also defer marking the DMA entry as IOMMU mapped until all entries are processed, in order to allow the unwind to know the disposition of each entry. Fixes: a54eb55045ae ("vfio iommu type1: Add support for mediated devices") Reported-by: Zhiyi Guo Tested-by: Zhiyi Guo Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit c49fa6397b6d29ce10c0ae5b2528bb004a14691f Author: Alex Williamson Date: Mon Aug 17 11:08:18 2020 -0600 vfio-pci: Avoid recursive read-lock usage [ Upstream commit bc93b9ae0151ae5ad5b8504cdc598428ea99570b ] A down_read on memory_lock is held when performing read/write accesses to MMIO BAR space, including across the copy_to/from_user() callouts which may fault. If the user buffer for these copies resides in an mmap of device MMIO space, the mmap fault handler will acquire a recursive read-lock on memory_lock. Avoid this by reducing the lock granularity. Sequential accesses requiring multiple ioread/iowrite cycles are expected to be rare, therefore typical accesses should not see additional overhead. VGA MMIO accesses are expected to be non-fatal regardless of the PCI memory enable bit to allow legacy probing, this behavior remains with a comment added. ioeventfds are now included in memory access testing, with writes dropped while memory space is disabled. Fixes: abafbc551fdd ("vfio-pci: Invalidate mmaps and block MMIO access on disabled memory") Reported-by: Zhiyi Guo Tested-by: Zhiyi Guo Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit ba9c27ba11756dd1b00d4d31e4665ea9151083c9 Author: David Howells Date: Mon Aug 17 11:07:28 2020 +0100 watch_queue: Limit the number of watches a user can hold [ Upstream commit 29e44f4535faa71a70827af3639b5e6762d8f02a ] Impose a limit on the number of watches that a user can hold so that they can't use this mechanism to fill up all the available memory. This is done by putting a counter in user_struct that's incremented when a watch is allocated and decreased when it is released. If the number exceeds the RLIMIT_NOFILE limit, the watch is rejected with EAGAIN. This can be tested by the following means: (1) Create a watch queue and attach it to fd 5 in the program given - in this case, bash: keyctl watch_session /tmp/nlog /tmp/gclog 5 bash (2) In the shell, set the maximum number of files to, say, 99: ulimit -n 99 (3) Add 200 keyrings: for ((i=0; i<200; i++)); do keyctl newring a$i @s || break; done (4) Try to watch all of the keyrings: for ((i=0; i<200; i++)); do echo $i; keyctl watch_add 5 %:a$i || break; done This should fail when the number of watches belonging to the user hits 99. (5) Remove all the keyrings and all of those watches should go away: for ((i=0; i<200; i++)); do keyctl unlink %:a$i; done (6) Kill off the watch queue by exiting the shell spawned by watch_session. Fixes: c73be61cede5 ("pipe: Add general notification queue support") Reported-by: Linus Torvalds Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 7505eeadc5a7a4c4b8e1bdfee25b47069ff2d9f3 Author: Dinghao Liu Date: Thu Aug 13 16:41:10 2020 +0800 ASoC: intel: Fix memleak in sst_media_open [ Upstream commit 062fa09f44f4fb3776a23184d5d296b0c8872eb9 ] When power_up_sst() fails, stream needs to be freed just like when try_module_get() fails. However, current code is returning directly and ends up leaking memory. Fixes: 0121327c1a68b ("ASoC: Intel: mfld-pcm: add control for powering up/down dsp") Signed-off-by: Dinghao Liu Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200813084112.26205-1-dinghao.liu@zju.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2586fcb08f85dfd8adeeb4103359132459e1ba4e Author: Srinivas Kandagatla Date: Tue Aug 11 11:34:52 2020 +0100 ASoC: msm8916-wcd-analog: fix register Interrupt offset [ Upstream commit ff69c97ef84c9f7795adb49e9f07c9adcdd0c288 ] For some reason interrupt set and clear register offsets are not set correctly. This patch corrects them! Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec") Signed-off-by: Srinivas Kandagatla Tested-by: Stephan Gerhold Reviewed-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200811103452.20448-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca79907768d37193ce7353a1cf2a9ac38c9c6ab1 Author: Heiko Carstens Date: Wed Aug 12 18:56:28 2020 +0200 s390/ptrace: fix storage key handling [ Upstream commit fd78c59446b8d050ecf3e0897c5a486c7de7c595 ] The key member of the runtime instrumentation control block contains only the access key, not the complete storage key. Therefore the value must be shifted by four bits. Since existing user space does not necessarily query and set the access key correctly, just ignore the user space provided key and use the correct one. Note: this is only relevant for debugging purposes in case somebody compiles a kernel with a default storage access key set to a value not equal to zero. Fixes: 262832bc5acd ("s390/ptrace: add runtime instrumention register get/set") Reported-by: Claudio Imbrenda Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 87a297a5a835d63eba67ce8c1884d6e4f69a6731 Author: Heiko Carstens Date: Wed Aug 12 18:55:41 2020 +0200 s390/runtime_instrumentation: fix storage key handling [ Upstream commit 9eaba29c7985236e16468f4e6a49cc18cf01443e ] The key member of the runtime instrumentation control block contains only the access key, not the complete storage key. Therefore the value must be shifted by four bits. Note: this is only relevant for debugging purposes in case somebody compiles a kernel with a default storage access key set to a value not equal to zero. Fixes: e4b8b3f33fca ("s390: add support for runtime instrumentation") Reported-by: Claudio Imbrenda Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 3bd77efc033f7d2ced7ebb500e23f6078ad11d80 Author: Mahesh Bandewar Date: Fri Aug 14 22:53:24 2020 -0700 ipvlan: fix device features [ Upstream commit d0f5c7076e01fef6fcb86988d9508bf3ce258bd4 ] Processing NETDEV_FEAT_CHANGE causes IPvlan links to lose NETIF_F_LLTX feature because of the incorrect handling of features in ipvlan_fix_features(). --before-- lpaa10:~# ethtool -k ipvl0 | grep tx-lockless tx-lockless: on [fixed] lpaa10:~# ethtool -K ipvl0 tso off Cannot change tcp-segmentation-offload Actual changes: vlan-challenged: off [fixed] tx-lockless: off [fixed] lpaa10:~# ethtool -k ipvl0 | grep tx-lockless tx-lockless: off [fixed] lpaa10:~# --after-- lpaa10:~# ethtool -k ipvl0 | grep tx-lockless tx-lockless: on [fixed] lpaa10:~# ethtool -K ipvl0 tso off Cannot change tcp-segmentation-offload Could not change any device features lpaa10:~# ethtool -k ipvl0 | grep tx-lockless tx-lockless: on [fixed] lpaa10:~# Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.") Signed-off-by: Mahesh Bandewar Cc: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 39560b31450bbe023aa09f4049ba02598803516a Author: Cong Wang Date: Fri Aug 14 20:05:58 2020 -0700 bonding: fix a potential double-unregister [ Upstream commit 832707021666411d04795c564a4adea5d6b94f17 ] When we tear down a network namespace, we unregister all the netdevices within it. So we may queue a slave device and a bonding device together in the same unregister queue. If the only slave device is non-ethernet, it would automatically unregister the bonding device as well. Thus, we may end up unregistering the bonding device twice. Workaround this special case by checking reg_state. Fixes: 9b5e383c11b0 ("net: Introduce unregister_netdevice_many()") Reported-by: syzbot+af23e7f3e0a7e10c8b67@syzkaller.appspotmail.com Cc: Eric Dumazet Cc: Andy Gospodarek Cc: Jay Vosburgh Signed-off-by: Cong Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dfdc8eaf69a63ed5af9f67c7d3d1a58fcc71ade1 Author: Zhang Changzhong Date: Wed Aug 5 11:50:25 2020 +0800 can: j1939: add rxtimer for multipacket broadcast session [ Upstream commit 0ae18a82686f9b9965a8ce0dd81371871b306ffe ] According to SAE J1939/21 (Chapter 5.12.3 and APPENDIX C), for transmit side the required time interval between packets of a multipacket broadcast message is 50 to 200 ms, the responder shall use a timeout of 250ms (provides margin allowing for the maximumm spacing of 200ms). For receive side a timeout will occur when a time of greater than 750 ms elapsed between two message packets when more packets were expected. So this patch fix and add rxtimer for multipacket broadcast session. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1596599425-5534-5-git-send-email-zhangchangzhong@huawei.com Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 638e26b82db36720885a4d357d7222aa8bfc4440 Author: Zhang Changzhong Date: Wed Aug 5 11:50:24 2020 +0800 can: j1939: abort multipacket broadcast session when timeout occurs [ Upstream commit 2b8b2e31555cf55ba3680fb28e2b382e168d7ea1 ] If timeout occurs, j1939_tp_rxtimer() first calls hrtimer_start() to restart rxtimer, and then calls __j1939_session_cancel() to set session->state = J1939_SESSION_WAITING_ABORT. At next timeout expiration, because of the J1939_SESSION_WAITING_ABORT session state j1939_tp_rxtimer() will call j1939_session_deactivate_activate_next() to deactivate current session, and rxtimer won't be set. But for multipacket broadcast session, __j1939_session_cancel() don't set session->state = J1939_SESSION_WAITING_ABORT, thus current session won't be deactivate and hrtimer_start() is called to start new rxtimer again and again. So fix it by moving session->state = J1939_SESSION_WAITING_ABORT out of if (!j1939_cb_is_broadcast(&session->skcb)) statement. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1596599425-5534-4-git-send-email-zhangchangzhong@huawei.com Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit f7653e4b8fa909b6900b1cb6f925b1f449998d34 Author: Zhang Changzhong Date: Wed Aug 5 11:50:23 2020 +0800 can: j1939: cancel rxtimer on multipacket broadcast session complete [ Upstream commit e8b17653088f28a87c81845fa41a2d295a3b458c ] If j1939_xtp_rx_dat_one() receive last frame of multipacket broadcast message, j1939_session_timers_cancel() should be called to cancel rxtimer. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1596599425-5534-3-git-send-email-zhangchangzhong@huawei.com Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 6cc1cc005e97f4a2f0f593ff54a4fb00bd8cd4dd Author: Zhang Changzhong Date: Wed Aug 5 11:50:22 2020 +0800 can: j1939: fix support for multipacket broadcast message [ Upstream commit f4fd77fd87e9b214c26bb2ebd4f90055eaea5ade ] Currently j1939_tp_im_involved_anydir() in j1939_tp_recv() check the previously set flags J1939_ECU_LOCAL_DST and J1939_ECU_LOCAL_SRC of incoming skb, thus multipacket broadcast message was aborted by receive side because it may come from remote ECUs and have no exact dst address. Similarly, j1939_tp_cmd_recv() and j1939_xtp_rx_dat() didn't process broadcast message. So fix it by checking and process broadcast message in j1939_tp_recv(), j1939_tp_cmd_recv() and j1939_xtp_rx_dat(). Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1596599425-5534-2-git-send-email-zhangchangzhong@huawei.com Acked-by: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit f9c6097aeb30cc3631ccb8684572061104350d25 Author: Jarod Wilson Date: Thu Aug 13 10:09:00 2020 -0400 bonding: show saner speed for broadcast mode [ Upstream commit 4ca0d9ac3fd8f9f90b72a15d8da2aca3ffb58418 ] Broadcast mode bonds transmit a copy of all traffic simultaneously out of all interfaces, so the "speed" of the bond isn't really the aggregate of all interfaces, but rather, the speed of the slowest active interface. Also, the type of the speed field is u32, not unsigned long, so adjust that accordingly, as required to make min() function here without complaining about mismatching types. Fixes: bb5b052f751b ("bond: add support to read speed and duplex via ethtool") CC: Jay Vosburgh CC: Veaceslav Falico CC: Andy Gospodarek CC: "David S. Miller" CC: netdev@vger.kernel.org Acked-by: Jay Vosburgh Signed-off-by: Jarod Wilson Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b9ca7a24e64a1346b74f692484f69ab09f8483ce Author: Fugang Duan Date: Thu Aug 13 15:13:14 2020 +0800 net: fec: correct the error path for regulator disable in probe [ Upstream commit c6165cf0dbb82ded90163dce3ac183fc7a913dc4 ] Correct the error path for regulator disable. Fixes: 9269e5560b26 ("net: fec: add phy-reset-gpios PROBE_DEFER check") Signed-off-by: Fugang Duan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 22da47f7c872b1709085aa8978f6707b7e1a8ba5 Author: Grzegorz Szczurek Date: Tue Aug 11 10:56:49 2020 +0000 i40e: Fix crash during removing i40e driver [ Upstream commit 5b6d4a7f20b09c47ca598760f6dafd554af8b6d5 ] Fix the reason of crashing system by add waiting time to finish reset recovery process before starting remove driver procedure. Now VSI is releasing if VSI is not in reset recovery mode. Without this fix it was possible to start remove driver if other processing command need reset recovery procedure which resulted in null pointer dereference. VSI used by the ethtool process has been cleared by remove driver process. [ 6731.508665] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 6731.508668] #PF: supervisor read access in kernel mode [ 6731.508670] #PF: error_code(0x0000) - not-present page [ 6731.508671] PGD 0 P4D 0 [ 6731.508674] Oops: 0000 [#1] SMP PTI [ 6731.508679] Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS SE5C610.86B.01.01.0021.032120170601 03/21/2017 [ 6731.508694] RIP: 0010:i40e_down+0x252/0x310 [i40e] [ 6731.508696] Code: c7 78 de fa c0 e8 61 02 3a c1 66 83 bb f6 0c 00 00 00 0f 84 bf 00 00 00 45 31 e4 45 31 ff eb 03 41 89 c7 48 8b 83 98 0c 00 00 <4a> 8b 3c 20 e8 a5 79 02 00 48 83 bb d0 0c 00 00 00 74 10 48 8b 83 [ 6731.508698] RSP: 0018:ffffb75ac7b3faf0 EFLAGS: 00010246 [ 6731.508700] RAX: 0000000000000000 RBX: ffff9c9874bd5000 RCX: 0000000000000007 [ 6731.508701] RDX: 0000000000000000 RSI: 0000000000000096 RDI: ffff9c987f4d9780 [ 6731.508703] RBP: ffffb75ac7b3fb30 R08: 0000000000005b60 R09: 0000000000000004 [ 6731.508704] R10: ffffb75ac64fbd90 R11: 0000000000000001 R12: 0000000000000000 [ 6731.508706] R13: ffff9c97a08e0000 R14: ffff9c97a08e0a68 R15: 0000000000000000 [ 6731.508708] FS: 00007f2617cd2740(0000) GS:ffff9c987f4c0000(0000) knlGS:0000000000000000 [ 6731.508710] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6731.508711] CR2: 0000000000000000 CR3: 0000001e765c4006 CR4: 00000000003606e0 [ 6731.508713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 6731.508714] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 6731.508715] Call Trace: [ 6731.508734] i40e_vsi_close+0x84/0x90 [i40e] [ 6731.508742] i40e_quiesce_vsi.part.98+0x3c/0x40 [i40e] [ 6731.508749] i40e_pf_quiesce_all_vsi+0x55/0x60 [i40e] [ 6731.508757] i40e_prep_for_reset+0x59/0x130 [i40e] [ 6731.508765] i40e_reconfig_rss_queues+0x5a/0x120 [i40e] [ 6731.508774] i40e_set_channels+0xda/0x170 [i40e] [ 6731.508778] ethtool_set_channels+0xe9/0x150 [ 6731.508781] dev_ethtool+0x1b94/0x2920 [ 6731.508805] dev_ioctl+0xc2/0x590 [ 6731.508811] sock_do_ioctl+0xae/0x150 [ 6731.508813] sock_ioctl+0x34f/0x3c0 [ 6731.508821] ksys_ioctl+0x98/0xb0 [ 6731.508828] __x64_sys_ioctl+0x1a/0x20 [ 6731.508831] do_syscall_64+0x57/0x1c0 [ 6731.508835] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 4b8164467b85 ("i40e: Add common function for finding VSI by type") Signed-off-by: Grzegorz Szczurek Signed-off-by: Arkadiusz Kubalewski Tested-by: Aaron Brown Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit fb95a28d7daf8f8544daee7d1993a178ef7953dc Author: Przemyslaw Patynowski Date: Thu Aug 6 13:40:59 2020 +0000 i40e: Set RX_ONLY mode for unicast promiscuous on VLAN [ Upstream commit 4bd5e02a2ed1575c2f65bd3c557a077dd399f0e8 ] Trusted VF with unicast promiscuous mode set, could listen to TX traffic of other VFs. Set unicast promiscuous mode to RX traffic, if VSI has port VLAN configured. Rename misleading I40E_AQC_SET_VSI_PROMISC_TX bit to I40E_AQC_SET_VSI_PROMISC_RX_ONLY. Aligned unicast promiscuous with VLAN to the one without VLAN. Fixes: 6c41a7606967 ("i40e: Add promiscuous on VLAN support") Fixes: 3b1200891b7f ("i40e: When in promisc mode apply promisc mode to Tx Traffic as well") Signed-off-by: Przemyslaw Patynowski Signed-off-by: Aleksandr Loktionov Signed-off-by: Arkadiusz Kubalewski Tested-by: Andrew Bowers Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit d302358881c4836135f3739c7518a1b2e3b57161 Author: Vinicius Costa Gomes Date: Mon Aug 3 11:32:07 2020 -0700 igc: Fix PTP initialization [ Upstream commit 3cda505a679ced78d69c889cfb418d1728bb2707 ] Right now, igc_ptp_reset() is called from igc_reset(), which is called from igc_probe() before igc_ptp_init() has a chance to run. It is detected as an attempt to use an spinlock without registering its key first. See log below. To avoid this problem, simplify the initialization: igc_ptp_init() is only called from igc_probe(), and igc_ptp_reset() is only called from igc_reset(). [ 2.736332] INFO: trying to register non-static key. [ 2.736902] input: HDA Intel PCH Front Headphone as /devices/pci0000:00/0000:00:1f.3/sound/card0/input10 [ 2.737513] the code is fine but needs lockdep annotation. [ 2.737513] turning off the locking correctness validator. [ 2.737515] CPU: 8 PID: 239 Comm: systemd-udevd Tainted: G E 5.8.0-rc7+ #13 [ 2.737515] Hardware name: Gigabyte Technology Co., Ltd. Z390 AORUS ULTRA/Z390 AORUS ULTRA-CF, BIOS F7 03/14/2019 [ 2.737516] Call Trace: [ 2.737521] dump_stack+0x78/0xa0 [ 2.737524] register_lock_class+0x6b1/0x6f0 [ 2.737526] ? lockdep_hardirqs_on_prepare+0xca/0x160 [ 2.739177] ? _raw_spin_unlock_irq+0x24/0x50 [ 2.739179] ? trace_hardirqs_on+0x1c/0xf0 [ 2.740820] __lock_acquire+0x56/0x1ff0 [ 2.740823] ? __schedule+0x30c/0x970 [ 2.740825] lock_acquire+0x97/0x3e0 [ 2.740830] ? igc_ptp_reset+0x35/0xf0 [igc] [ 2.740833] ? schedule_hrtimeout_range_clock+0xb7/0x120 [ 2.742507] _raw_spin_lock_irqsave+0x3a/0x50 [ 2.742512] ? igc_ptp_reset+0x35/0xf0 [igc] [ 2.742515] igc_ptp_reset+0x35/0xf0 [igc] [ 2.742519] igc_reset+0x96/0xd0 [igc] [ 2.744148] igc_probe+0x68f/0x7d0 [igc] [ 2.745796] local_pci_probe+0x3d/0x70 [ 2.745799] pci_device_probe+0xd1/0x190 [ 2.745802] really_probe+0x15a/0x3f0 [ 2.759936] driver_probe_device+0xe1/0x150 [ 2.759937] device_driver_attach+0xa8/0xb0 [ 2.761786] __driver_attach+0x89/0x150 [ 2.761786] ? device_driver_attach+0xb0/0xb0 [ 2.761787] ? device_driver_attach+0xb0/0xb0 [ 2.761788] bus_for_each_dev+0x66/0x90 [ 2.765012] bus_add_driver+0x12e/0x1f0 [ 2.765716] driver_register+0x8b/0xe0 [ 2.766418] ? 0xffffffffc0230000 [ 2.767119] do_one_initcall+0x5a/0x310 [ 2.767826] ? kmem_cache_alloc_trace+0xe9/0x200 [ 2.768528] do_init_module+0x5c/0x260 [ 2.769206] __do_sys_finit_module+0x93/0xe0 [ 2.770048] do_syscall_64+0x46/0xa0 [ 2.770716] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.771396] RIP: 0033:0x7f83534589e0 [ 2.772073] Code: 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 2e 2e 2e 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 80 24 0d 00 f7 d8 64 89 01 48 [ 2.772074] RSP: 002b:00007ffd31d0ed18 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.774854] RAX: ffffffffffffffda RBX: 000055d52816aba0 RCX: 00007f83534589e0 [ 2.774855] RDX: 0000000000000000 RSI: 00007f83535b982f RDI: 0000000000000006 [ 2.774855] RBP: 00007ffd31d0ed60 R08: 0000000000000000 R09: 00007ffd31d0ed30 [ 2.774856] R10: 0000000000000006 R11: 0000000000000246 R12: 0000000000000000 [ 2.774856] R13: 0000000000020000 R14: 00007f83535b982f R15: 000055d527f5e120 Fixes: 5f2958052c58 ("igc: Add basic skeleton for PTP") Signed-off-by: Vinicius Costa Gomes Reviewed-by: Andre Guedes Tested-by: Aaron Brown Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin commit 16c3d947c69bd87dce3673959b274c0a492432d0 Author: Oleksij Rempel Date: Fri Aug 7 12:51:59 2020 +0200 can: j1939: transport: add j1939_session_skb_find_by_offset() function [ Upstream commit 840835c9281215341d84966a8855f267a971e6a3 ] Sometimes it makes no sense to search the skb by pkt.dpo, since we need next the skb within the transaction block. This may happen if we have an ETP session with CTS set to less than 255 packets. After this patch, we will be able to work with ETP sessions where the block size (ETP.CM_CTS byte 2) is less than 255 packets. Reported-by: Henrique Figueira Reported-by: https://github.com/linux-can/can-utils/issues/228 Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20200807105200.26441-5-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit f0c778597a5a9b36e0d728a141368138c4236383 Author: Oleksij Rempel Date: Fri Aug 7 12:51:56 2020 +0200 can: j1939: transport: j1939_simple_recv(): ignore local J1939 messages send not by J1939 stack [ Upstream commit b43e3a82bc432c1caaed8950e7662c143470c54c ] In current J1939 stack implementation, we process all locally send messages as own messages. Even if it was send by CAN_RAW socket. To reproduce it use following commands: testj1939 -P -r can0:0x80 & cansend can0 18238040#0123 This step will trigger false positive not critical warning: j1939_simple_recv: Received already invalidated message With this patch we add additional check to make sure, related skb is own echo message. Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20200807105200.26441-2-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 089dd91ec99bb34b8159cbfb1cc6846b64f808fe Author: Eric Dumazet Date: Thu Aug 13 09:18:34 2020 -0700 can: j1939: fix kernel-infoleak in j1939_sk_sock2sockaddr_can() [ Upstream commit 38ba8b9241f5848a49b80fddac9ab5f4692e434e ] syzbot found that at least 2 bytes of kernel information were leaked during getsockname() on AF_CAN CAN_J1939 socket. Since struct sockaddr_can has in fact two holes, simply clear the whole area before filling it with useful data. BUG: KMSAN: kernel-infoleak in kmsan_copy_to_user+0x81/0x90 mm/kmsan/kmsan_hooks.c:253 CPU: 0 PID: 8466 Comm: syz-executor511 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 kmsan_internal_check_memory+0x238/0x3d0 mm/kmsan/kmsan.c:423 kmsan_copy_to_user+0x81/0x90 mm/kmsan/kmsan_hooks.c:253 instrument_copy_to_user include/linux/instrumented.h:91 [inline] _copy_to_user+0x18e/0x260 lib/usercopy.c:39 copy_to_user include/linux/uaccess.h:186 [inline] move_addr_to_user+0x3de/0x670 net/socket.c:237 __sys_getsockname+0x407/0x5e0 net/socket.c:1909 __do_sys_getsockname net/socket.c:1920 [inline] __se_sys_getsockname+0x91/0xb0 net/socket.c:1917 __x64_sys_getsockname+0x4a/0x70 net/socket.c:1917 do_syscall_64+0xad/0x160 arch/x86/entry/common.c:386 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x440219 Code: Bad RIP value. RSP: 002b:00007ffe5ee150c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000033 RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000440219 RDX: 0000000020000240 RSI: 0000000020000100 RDI: 0000000000000003 RBP: 00000000006ca018 R08: 0000000000000000 R09: 00000000004002c8 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000401a20 R13: 0000000000401ab0 R14: 0000000000000000 R15: 0000000000000000 Local variable ----address@__sys_getsockname created at: __sys_getsockname+0x91/0x5e0 net/socket.c:1894 __sys_getsockname+0x91/0x5e0 net/socket.c:1894 Bytes 2-3 of 24 are uninitialized Memory access of size 24 starts at ffff8880ba2c7de8 Data copied to user address 0000000020000100 Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Robin van der Gracht Cc: Oleksij Rempel Cc: Pengutronix Kernel Team Cc: linux-can@vger.kernel.org Acked-by: Oleksij Rempel Link: https://lore.kernel.org/r/20200813161834.4021638-1-edumazet@google.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 93c39ebb5d44cb05b59e0b8504b4c8da057c5f05 Author: Andrii Nakryiko Date: Thu Aug 13 13:49:39 2020 -0700 libbpf: Fix BTF-defined map-in-map initialization on 32-bit host arches [ Upstream commit 15728ad3e71c120278105f20fa65b3735e715e0f ] Libbpf built in 32-bit mode should be careful about not conflating 64-bit BPF pointers in BPF ELF file and host architecture pointers. This patch fixes issue of incorrect initializating of map-in-map inner map slots due to such difference. Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200813204945.1020225-4-andriin@fb.com Signed-off-by: Sasha Levin commit db7f8c57dbdd31f7e59f8dc8d1e1b38607a320ef Author: John Fastabend Date: Tue Aug 11 15:04:56 2020 -0700 bpf: sock_ops sk access may stomp registers when dst_reg = src_reg [ Upstream commit 84f44df664e9f0e261157e16ee1acd77cc1bb78d ] Similar to patch ("bpf: sock_ops ctx access may stomp registers") if the src_reg = dst_reg when reading the sk field of a sock_ops struct we generate xlated code, 53: (61) r9 = *(u32 *)(r9 +28) 54: (15) if r9 == 0x0 goto pc+3 56: (79) r9 = *(u64 *)(r9 +0) This stomps on the r9 reg to do the sk_fullsock check and then when reading the skops->sk field instead of the sk pointer we get the sk_fullsock. To fix use similar pattern noted in the previous fix and use the temp field to save/restore a register used to do sk_fullsock check. After the fix the generated xlated code reads, 52: (7b) *(u64 *)(r9 +32) = r8 53: (61) r8 = *(u32 *)(r9 +28) 54: (15) if r9 == 0x0 goto pc+3 55: (79) r8 = *(u64 *)(r9 +32) 56: (79) r9 = *(u64 *)(r9 +0) 57: (05) goto pc+1 58: (79) r8 = *(u64 *)(r9 +32) Here r9 register was in-use so r8 is chosen as the temporary register. In line 52 r8 is saved in temp variable and at line 54 restored in case fullsock != 0. Finally we handle fullsock == 0 case by restoring at line 58. This adds a new macro SOCK_OPS_GET_SK it is almost possible to merge this with SOCK_OPS_GET_FIELD, but I found the extra branch logic a bit more confusing than just adding a new macro despite a bit of duplicating code. Fixes: 1314ef561102e ("bpf: export bpf_sock for BPF_PROG_TYPE_SOCK_OPS prog type") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/159718349653.4728.6559437186853473612.stgit@john-Precision-5820-Tower Signed-off-by: Sasha Levin commit cd4644d904e1d153d516e73e2e127e7a2fe687e1 Author: John Fastabend Date: Tue Aug 11 15:04:37 2020 -0700 bpf: sock_ops ctx access may stomp registers in corner case [ Upstream commit fd09af010788a884de1c39537c288830c3d305db ] I had a sockmap program that after doing some refactoring started spewing this splat at me: [18610.807284] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 [...] [18610.807359] Call Trace: [18610.807370] ? 0xffffffffc114d0d5 [18610.807382] __cgroup_bpf_run_filter_sock_ops+0x7d/0xb0 [18610.807391] tcp_connect+0x895/0xd50 [18610.807400] tcp_v4_connect+0x465/0x4e0 [18610.807407] __inet_stream_connect+0xd6/0x3a0 [18610.807412] ? __inet_stream_connect+0x5/0x3a0 [18610.807417] inet_stream_connect+0x3b/0x60 [18610.807425] __sys_connect+0xed/0x120 After some debugging I was able to build this simple reproducer, __section("sockops/reproducer_bad") int bpf_reproducer_bad(struct bpf_sock_ops *skops) { volatile __maybe_unused __u32 i = skops->snd_ssthresh; return 0; } And along the way noticed that below program ran without splat, __section("sockops/reproducer_good") int bpf_reproducer_good(struct bpf_sock_ops *skops) { volatile __maybe_unused __u32 i = skops->snd_ssthresh; volatile __maybe_unused __u32 family; compiler_barrier(); family = skops->family; return 0; } So I decided to check out the code we generate for the above two programs and noticed each generates the BPF code you would expect, 0000000000000000 : ; volatile __maybe_unused __u32 i = skops->snd_ssthresh; 0: r1 = *(u32 *)(r1 + 96) 1: *(u32 *)(r10 - 4) = r1 ; return 0; 2: r0 = 0 3: exit 0000000000000000 : ; volatile __maybe_unused __u32 i = skops->snd_ssthresh; 0: r2 = *(u32 *)(r1 + 96) 1: *(u32 *)(r10 - 4) = r2 ; family = skops->family; 2: r1 = *(u32 *)(r1 + 20) 3: *(u32 *)(r10 - 8) = r1 ; return 0; 4: r0 = 0 5: exit So we get reasonable assembly, but still something was causing the null pointer dereference. So, we load the programs and dump the xlated version observing that line 0 above 'r* = *(u32 *)(r1 +96)' is going to be translated by the skops access helpers. int bpf_reproducer_bad(struct bpf_sock_ops * skops): ; volatile __maybe_unused __u32 i = skops->snd_ssthresh; 0: (61) r1 = *(u32 *)(r1 +28) 1: (15) if r1 == 0x0 goto pc+2 2: (79) r1 = *(u64 *)(r1 +0) 3: (61) r1 = *(u32 *)(r1 +2340) ; volatile __maybe_unused __u32 i = skops->snd_ssthresh; 4: (63) *(u32 *)(r10 -4) = r1 ; return 0; 5: (b7) r0 = 0 6: (95) exit int bpf_reproducer_good(struct bpf_sock_ops * skops): ; volatile __maybe_unused __u32 i = skops->snd_ssthresh; 0: (61) r2 = *(u32 *)(r1 +28) 1: (15) if r2 == 0x0 goto pc+2 2: (79) r2 = *(u64 *)(r1 +0) 3: (61) r2 = *(u32 *)(r2 +2340) ; volatile __maybe_unused __u32 i = skops->snd_ssthresh; 4: (63) *(u32 *)(r10 -4) = r2 ; family = skops->family; 5: (79) r1 = *(u64 *)(r1 +0) 6: (69) r1 = *(u16 *)(r1 +16) ; family = skops->family; 7: (63) *(u32 *)(r10 -8) = r1 ; return 0; 8: (b7) r0 = 0 9: (95) exit Then we look at lines 0 and 2 above. In the good case we do the zero check in r2 and then load 'r1 + 0' at line 2. Do a quick cross-check into the bpf_sock_ops check and we can confirm that is the 'struct sock *sk' pointer field. But, in the bad case, 0: (61) r1 = *(u32 *)(r1 +28) 1: (15) if r1 == 0x0 goto pc+2 2: (79) r1 = *(u64 *)(r1 +0) Oh no, we read 'r1 +28' into r1, this is skops->fullsock and then in line 2 we read the 'r1 +0' as a pointer. Now jumping back to our spat, [18610.807284] BUG: unable to handle kernel NULL pointer dereference at 0000000000000001 The 0x01 makes sense because that is exactly the fullsock value. And its not a valid dereference so we splat. To fix we need to guard the case when a program is doing a sock_ops field access with src_reg == dst_reg. This is already handled in the load case where the ctx_access handler uses a tmp register being careful to store the old value and restore it. To fix the get case test if src_reg == dst_reg and in this case do the is_fullsock test in the temporary register. Remembering to restore the temporary register before writing to either dst_reg or src_reg to avoid smashing the pointer into the struct holding the tmp variable. Adding this inline code to test_tcpbpf_kern will now be generated correctly from, 9: r2 = *(u32 *)(r2 + 96) to xlated code, 12: (7b) *(u64 *)(r2 +32) = r9 13: (61) r9 = *(u32 *)(r2 +28) 14: (15) if r9 == 0x0 goto pc+4 15: (79) r9 = *(u64 *)(r2 +32) 16: (79) r2 = *(u64 *)(r2 +0) 17: (61) r2 = *(u32 *)(r2 +2348) 18: (05) goto pc+1 19: (79) r9 = *(u64 *)(r2 +32) And in the normal case we keep the original code, because really this is an edge case. From this, 9: r2 = *(u32 *)(r6 + 96) to xlated code, 22: (61) r2 = *(u32 *)(r6 +28) 23: (15) if r2 == 0x0 goto pc+2 24: (79) r2 = *(u64 *)(r6 +0) 25: (61) r2 = *(u32 *)(r2 +2348) So three additional instructions if dst == src register, but I scanned my current code base and did not see this pattern anywhere so should not be a big deal. Further, it seems no one else has hit this or at least reported it so it must a fairly rare pattern. Fixes: 9b1f3d6e5af29 ("bpf: Refactor sock_ops_convert_ctx_access") Signed-off-by: John Fastabend Signed-off-by: Daniel Borkmann Acked-by: Song Liu Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/159718347772.4728.2781381670567919577.stgit@john-Precision-5820-Tower Signed-off-by: Sasha Levin commit 5d9c020bd8e3f7604795a45f60323d8b6edd9846 Author: Andrii Nakryiko Date: Tue Aug 11 19:59:07 2020 -0700 tools/bpftool: Make skeleton code C++17-friendly by dropping typeof() [ Upstream commit 8faf7fc597d59b142af41ddd4a2d59485f75f88a ] Seems like C++17 standard mode doesn't recognize typeof() anymore. This can be tested by compiling test_cpp test with -std=c++17 or -std=c++1z options. The use of typeof in skeleton generated code is unnecessary, all types are well-known at the time of code generation, so remove all typeof()'s to make skeleton code more future-proof when interacting with C++ compilers. Fixes: 985ead416df3 ("bpftool: Add skeleton codegen command") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200812025907.1371956-1-andriin@fb.com Signed-off-by: Sasha Levin commit c2bbf3cbcf788e1ca95f4de7900b7967fb2fc563 Author: Srinivas Kandagatla Date: Tue Aug 11 13:02:05 2020 +0100 ASoC: q6routing: add dummy register read/write function [ Upstream commit 796a58fe2b8c9b6668db00d92512ec84be663027 ] Most of the DAPM widgets for DSP ASoC components reuse reg field of the widgets for its internal calculations, however these are not real registers. So read/writes to these numbers are not really valid. However ASoC core will read these registers to get default state during startup. With recent changes to ASoC core, every register read/write failures are reported very verbosely. Prior to this fails to reads are totally ignored, so we never saw any error messages. To fix this add dummy read/write function to return default value. Fixes: e3a33673e845 ("ASoC: qdsp6: q6routing: Add q6routing driver") Reported-by: John Stultz Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200811120205.21805-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 60df9abd84896ac5ba7bdfd711d8838bf6ba91ff Author: Srinivas Kandagatla Date: Tue Aug 11 13:02:04 2020 +0100 ASoC: q6afe-dai: mark all widgets registers as SND_SOC_NOPM [ Upstream commit 56235e4bc5ae58cb8fcd9314dba4e9ab077ddda8 ] Looks like the q6afe-dai dapm widget registers are set as "0", which is a not correct. As this registers will be read by ASoC core during startup which will throw up errors, Fix this by making the registers as SND_SOC_NOPM as these should be never used. With recent changes to ASoC core, every register read/write failures are reported very verbosely. Prior to this fails to reads are totally ignored, so we never saw any error messages. Fixes: 24c4cbcfac09 ("ASoC: qdsp6: q6afe: Add q6afe dai driver") Reported-by: John Stultz Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200811120205.21805-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4c3f6739fe0576e91450f455ec354a2c8e0f092e Author: Amelie Delaunay Date: Mon Aug 10 09:12:37 2020 +0200 spi: stm32: fixes suspend/resume management [ Upstream commit db96bf976a4fc65439be0b4524c0d41427d98814 ] This patch adds pinctrl power management, and reconfigure spi controller in case of resume. Fixes: 038ac869c9d2 ("spi: stm32: add runtime PM support") Signed-off-by: Amelie Delaunay Signed-off-by: Alain Volmat Link: https://lore.kernel.org/r/1597043558-29668-5-git-send-email-alain.volmat@st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 4707dba95055dd981829656164ea79df12ab2fcd Author: Stephen Suryaputra Date: Tue Aug 4 17:44:09 2020 -0400 netfilter: nf_tables: nft_exthdr: the presence return value should be little-endian [ Upstream commit b428336676dbca363262cc134b6218205df4f530 ] On big-endian machine, the returned register data when the exthdr is present is not being compared correctly because little-endian is assumed. The function nft_cmp_fast_mask(), called by nft_cmp_fast_eval() and nft_cmp_fast_init(), calls cpu_to_le32(). The following dump also shows that little endian is assumed: $ nft --debug=netlink add rule ip recordroute forward ip option rr exists counter ip [ exthdr load ipv4 1b @ 7 + 0 present => reg 1 ] [ cmp eq reg 1 0x01000000 ] [ counter pkts 0 bytes 0 ] Lastly, debug print in nft_cmp_fast_init() and nft_cmp_fast_eval() when RR option exists in the packet shows that the comparison fails because the assumption: nft_cmp_fast_init:189 priv->sreg=4 desc.len=8 mask=0xff000000 data.data[0]=0x10003e0 nft_cmp_fast_eval:57 regs->data[priv->sreg=4]=0x1 mask=0xff000000 priv->data=0x1000000 v2: use nft_reg_store8() instead (Florian Westphal). Also to avoid the warnings reported by kernel test robot. Fixes: dbb5281a1f84 ("netfilter: nf_tables: add support for matching IPv4 options") Fixes: c078ca3b0c5b ("netfilter: nft_exthdr: Add support for existence check") Signed-off-by: Stephen Suryaputra Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit cfa678021a1bb6b5ce4aa45c865f2d3167646f89 Author: Jan Kara Date: Tue Jul 28 15:04:34 2020 +0200 ext4: check journal inode extents more carefully [ Upstream commit ce9f24cccdc019229b70a5c15e2b09ad9c0ab5d1 ] Currently, system zones just track ranges of block, that are "important" fs metadata (bitmaps, group descriptors, journal blocks, etc.). This however complicates how extent tree (or indirect blocks) can be checked for inodes that actually track such metadata - currently the journal inode but arguably we should be treating quota files or resize inode similarly. We cannot run __ext4_ext_check() on such metadata inodes when loading their extents as that would immediately trigger the validity checks and so we just hack around that and special-case the journal inode. This however leads to a situation that a journal inode which has extent tree of depth at least one can have invalid extent tree that gets unnoticed until ext4_cache_extents() crashes. To overcome this limitation, track inode number each system zone belongs to (0 is used for zones not belonging to any inode). We can then verify inode number matches the expected one when verifying extent tree and thus avoid the false errors. With this there's no need to to special-case journal inode during extent tree checking anymore so remove it. Fixes: 0a944e8a6c66 ("ext4: don't perform block validity checks on the journal inode") Reported-by: Wolfgang Frisch Reviewed-by: Lukas Czerner Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20200728130437.7804-4-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 20070b188bf4df681f86707c8b631cf744118f1e Author: Jan Kara Date: Tue Jul 28 15:04:33 2020 +0200 ext4: don't allow overlapping system zones [ Upstream commit bf9a379d0980e7413d94cb18dac73db2bfc5f470 ] Currently, add_system_zone() just silently merges two added system zones that overlap. However the overlap should not happen and it generally suggests that some unrelated metadata overlap which indicates the fs is corrupted. We should have caught such problems earlier (e.g. in ext4_check_descriptors()) but add this check as another line of defense. In later patch we also use this for stricter checking of journal inode extent tree. Reviewed-by: Lukas Czerner Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20200728130437.7804-3-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 480a5124cd0e0c7aa794056401f66ce1dbb4269b Author: Qi Liu Date: Tue Jul 21 18:16:47 2020 +0800 drm/virtio: fix missing dma_fence_put() in virtio_gpu_execbuffer_ioctl() [ Upstream commit 8b6ec999b198b59ae61e86e70f5e9df73fe4754f ] We should put the reference count of the fence after calling virtio_gpu_cmd_submit(). So add the missing dma_fence_put(). Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization") Co-developed-by: Xin He Signed-off-by: Xin He Signed-off-by: Qi Liu Reviewed-by: Muchun Song Link: http://patchwork.freedesktop.org/patch/msgid/20200721101647.42653-1-hexin.op@bytedance.com Signed-off-by: Gerd Hoffmann Signed-off-by: Sasha Levin commit 88e79f7a9841278fa8ff7ff6178bad12da002ffc Author: Eric Sandeen Date: Wed Jun 17 14:19:04 2020 -0500 ext4: fix potential negative array index in do_split() [ Upstream commit 5872331b3d91820e14716632ebb56b1399b34fe1 ] If for any reason a directory passed to do_split() does not have enough active entries to exceed half the size of the block, we can end up iterating over all "count" entries without finding a split point. In this case, count == move, and split will be zero, and we will attempt a negative index into map[]. Guard against this by detecting this case, and falling back to split-to-half-of-count instead; in this case we will still have plenty of space (> half blocksize) in each split block. Fixes: ef2b02d3e617 ("ext34: ensure do_split leaves enough free space in both blocks") Signed-off-by: Eric Sandeen Reviewed-by: Andreas Dilger Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/f53e246b-647c-64bb-16ec-135383c70ad7@redhat.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 95e11707684236ef17af32b8fe99fa1d5ee5973e Author: Helge Deller Date: Tue Aug 11 18:36:04 2020 -0700 fs/signalfd.c: fix inconsistent return codes for signalfd4 [ Upstream commit a089e3fd5a82aea20f3d9ec4caa5f4c65cc2cfcc ] The kernel signalfd4() syscall returns different error codes when called either in compat or native mode. This behaviour makes correct emulation in qemu and testing programs like LTP more complicated. Fix the code to always return -in both modes- EFAULT for unaccessible user memory, and EINVAL when called with an invalid signal mask. Signed-off-by: Helge Deller Signed-off-by: Andrew Morton Cc: Alexander Viro Cc: Laurent Vivier Link: http://lkml.kernel.org/r/20200530100707.GA10159@ls3530.fritz.box Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 796f99a7b77a79087b5654715082088c57de8d46 Author: OGAWA Hirofumi Date: Tue Aug 11 18:36:01 2020 -0700 fat: fix fat_ra_init() for data clusters == 0 [ Upstream commit a090a5a7d73f79a9ae2dcc6e60d89bfc6864a65a ] If data clusters == 0, fat_ra_init() calls the ->ent_blocknr() for the cluster beyond ->max_clusters. This checks the limit before initialization to suppress the warning. Reported-by: syzbot+756199124937b31a9b7e@syzkaller.appspotmail.com Signed-off-by: OGAWA Hirofumi Signed-off-by: Andrew Morton Link: http://lkml.kernel.org/r/87mu462sv4.fsf@mail.parknet.co.jp Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit f358706be43a2cb7f4a188dbb30d5272588a1f86 Author: Luc Van Oostenryck Date: Tue Aug 11 18:33:54 2020 -0700 alpha: fix annotation of io{read,write}{16,32}be() [ Upstream commit bd72866b8da499e60633ff28f8a4f6e09ca78efe ] These accessors must be used to read/write a big-endian bus. The value returned or written is native-endian. However, these accessors are defined using be{16,32}_to_cpu() or cpu_to_be{16,32}() to make the endian conversion but these expect a __be{16,32} when none is present. Keeping them would need a force cast that would solve nothing at all. So, do the conversion using swab{16,32}, like done in asm-generic for similar situations. Reported-by: kernel test robot Signed-off-by: Luc Van Oostenryck Signed-off-by: Andrew Morton Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: Stephen Boyd Cc: Arnd Bergmann Link: http://lkml.kernel.org/r/20200622114232.80039-1-luc.vanoostenryck@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 5461d5e84ed35175c41bbc635187d0d28e48ff53 Author: Eiichi Tsukata Date: Thu Aug 6 15:18:48 2020 -0700 xfs: Fix UBSAN null-ptr-deref in xfs_sysfs_init [ Upstream commit 96cf2a2c75567ff56195fe3126d497a2e7e4379f ] If xfs_sysfs_init is called with parent_kobj == NULL, UBSAN shows the following warning: UBSAN: null-ptr-deref in ./fs/xfs/xfs_sysfs.h:37:23 member access within null pointer of type 'struct xfs_kobj' Call Trace: dump_stack+0x10e/0x195 ubsan_type_mismatch_common+0x241/0x280 __ubsan_handle_type_mismatch_v1+0x32/0x40 init_xfs_fs+0x12b/0x28f do_one_initcall+0xdd/0x1d0 do_initcall_level+0x151/0x1b6 do_initcalls+0x50/0x8f do_basic_setup+0x29/0x2b kernel_init_freeable+0x19f/0x20b kernel_init+0x11/0x1e0 ret_from_fork+0x22/0x30 Fix it by checking parent_kobj before the code accesses its member. Signed-off-by: Eiichi Tsukata Reviewed-by: Darrick J. Wong [darrick: minor whitespace edits] Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 99b3f3bd1fa9e2b2f2130c3432ba85994445b135 Author: Gaurav Singh Date: Thu Aug 6 23:17:25 2020 -0700 tools/testing/selftests/cgroup/cgroup_util.c: cg_read_strcmp: fix null pointer dereference [ Upstream commit d830020656c5b68ced962ed3cb51a90e0a89d4c4 ] Haven't reproduced this issue. This PR is does a minor code cleanup. Signed-off-by: Gaurav Singh Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Shuah Khan Cc: Tejun Heo Cc: Michal Koutn Cc: Roman Gushchin Cc: Christian Brauner Cc: Chris Down Link: http://lkml.kernel.org/r/20200726013808.22242-1-gaurav1086@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2dc74b9a9a9f4a569f4486e1e093a769cdd4f7d7 Author: Evgeny Novikov Date: Thu Jul 23 19:46:51 2020 +0200 media: camss: fix memory leaks on error handling paths in probe [ Upstream commit f45882cfb152f5d3a421fd58f177f227e44843b9 ] camss_probe() does not free camss on error handling paths. The patch introduces an additional error label for this purpose. Besides, it removes call of v4l2_async_notifier_cleanup() from camss_of_parse_ports() since its caller, camss_probe(), cleans up all its resources itself. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Co-developed-by: Anton Vasilyev Signed-off-by: Anton Vasilyev Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 630170dfc73ae79a8d7cb623b0b06a92f29e22d8 Author: Mao Wenan Date: Sun Aug 2 15:44:09 2020 +0800 virtio_ring: Avoid loop when vq is broken in virtqueue_poll [ Upstream commit 481a0d7422db26fb63e2d64f0652667a5c6d0f3e ] The loop may exist if vq->broken is true, virtqueue_get_buf_ctx_packed or virtqueue_get_buf_ctx_split will return NULL, so virtnet_poll will reschedule napi to receive packet, it will lead cpu usage(si) to 100%. call trace as below: virtnet_poll virtnet_receive virtqueue_get_buf_ctx virtqueue_get_buf_ctx_packed virtqueue_get_buf_ctx_split virtqueue_napi_complete virtqueue_poll //return true virtqueue_napi_schedule //it will reschedule napi to fix this, return false if vq is broken in virtqueue_poll. Signed-off-by: Mao Wenan Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/1596354249-96204-1-git-send-email-wenan.mao@linux.alibaba.com Signed-off-by: Michael S. Tsirkin Acked-by: Jason Wang Signed-off-by: Sasha Levin commit 55bd4074ce6b5ca9e58174e9375e2eec2a6b4d1b Author: Javed Hasan Date: Wed Jul 29 01:18:23 2020 -0700 scsi: libfc: Free skb in fc_disc_gpn_id_resp() for valid cases [ Upstream commit ec007ef40abb6a164d148b0dc19789a7a2de2cc8 ] In fc_disc_gpn_id_resp(), skb is supposed to get freed in all cases except for PTR_ERR. However, in some cases it didn't. This fix is to call fc_frame_free(fp) before function returns. Link: https://lore.kernel.org/r/20200729081824.30996-2-jhasan@marvell.com Reviewed-by: Girish Basrur Reviewed-by: Santosh Vernekar Reviewed-by: Saurav Kashyap Reviewed-by: Shyam Sundar Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit caceaea09891856d97941cc19de7f31f0cd72137 Author: Srinivas Pandruvada Date: Mon Aug 3 11:37:20 2020 -0700 cpufreq: intel_pstate: Fix cpuinfo_max_freq when MSR_TURBO_RATIO_LIMIT is 0 [ Upstream commit 4daca379c703ff55edc065e8e5173dcfeecf0148 ] The MSR_TURBO_RATIO_LIMIT can be 0. This is not an error. User can update this MSR via BIOS settings on some systems or can use msr tools to update. Also some systems boot with value = 0. This results in display of cpufreq/cpuinfo_max_freq wrong. This value will be equal to cpufreq/base_frequency, even though turbo is enabled. But platform will still function normally in HWP mode as we get max 1-core frequency from the MSR_HWP_CAPABILITIES. This MSR is already used to calculate cpu->pstate.turbo_freq, which is used for to set policy->cpuinfo.max_freq. But some other places cpu->pstate.turbo_pstate is used. For example to set policy->max. To fix this, also update cpu->pstate.turbo_pstate when updating cpu->pstate.turbo_freq. Signed-off-by: Srinivas Pandruvada Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 3f6735308fdfbb672c3287d3ab064f0c056d8396 Author: Boris Ostrovsky Date: Fri Jul 10 15:34:17 2020 -0700 swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses [ Upstream commit 8b1e868f66076490189a36d984fcce286cdd6295 ] xen_alloc_coherent_pages might return pages for which virt_to_phys and virt_to_page don't work, e.g. ioremap'ed pages. So in xen_swiotlb_free_coherent we can't assume that virt_to_page works. Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc virt addresses. This patch fixes the following crash at boot on RPi4 (the underlying issue is not RPi4 specific): https://marc.info/?l=xen-devel&m=158862573216800 Signed-off-by: Boris Ostrovsky Signed-off-by: Stefano Stabellini Reviewed-by: Boris Ostrovsky Tested-by: Corey Minyard Tested-by: Roman Shaposhnik Link: https://lore.kernel.org/r/20200710223427.6897-1-sstabellini@kernel.org Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit 8d5b9bb9a58a0b3b3f421aafe0478ff0141cf4dc Author: Xiubo Li Date: Thu Jul 23 15:32:25 2020 +0800 ceph: fix use-after-free for fsc->mdsc [ Upstream commit a7caa88f8b72c136f9a401f498471b8a8e35370d ] If the ceph_mdsc_init() fails, it will free the mdsc already. Reported-by: syzbot+b57f46d8d6ea51960b8c@syzkaller.appspotmail.com Signed-off-by: Xiubo Li Reviewed-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 17754f71db7b4d466ef5a19056b9b04d6b080683 Author: Zhe Li Date: Fri Jun 19 17:06:35 2020 +0800 jffs2: fix UAF problem [ Upstream commit 798b7347e4f29553db4b996393caf12f5b233daf ] The log of UAF problem is listed below. BUG: KASAN: use-after-free in jffs2_rmdir+0xa4/0x1cc [jffs2] at addr c1f165fc Read of size 4 by task rm/8283 ============================================================================= BUG kmalloc-32 (Tainted: P B O ): kasan: bad access detected ----------------------------------------------------------------------------- INFO: Allocated in 0xbbbbbbbb age=3054364 cpu=0 pid=0 0xb0bba6ef jffs2_write_dirent+0x11c/0x9c8 [jffs2] __slab_alloc.isra.21.constprop.25+0x2c/0x44 __kmalloc+0x1dc/0x370 jffs2_write_dirent+0x11c/0x9c8 [jffs2] jffs2_do_unlink+0x328/0x5fc [jffs2] jffs2_rmdir+0x110/0x1cc [jffs2] vfs_rmdir+0x180/0x268 do_rmdir+0x2cc/0x300 ret_from_syscall+0x0/0x3c INFO: Freed in 0x205b age=3054364 cpu=0 pid=0 0x2e9173 jffs2_add_fd_to_list+0x138/0x1dc [jffs2] jffs2_add_fd_to_list+0x138/0x1dc [jffs2] jffs2_garbage_collect_dirent.isra.3+0x21c/0x288 [jffs2] jffs2_garbage_collect_live+0x16bc/0x1800 [jffs2] jffs2_garbage_collect_pass+0x678/0x11d4 [jffs2] jffs2_garbage_collect_thread+0x1e8/0x3b0 [jffs2] kthread+0x1a8/0x1b0 ret_from_kernel_thread+0x5c/0x64 Call Trace: [c17ddd20] [c02452d4] kasan_report.part.0+0x298/0x72c (unreliable) [c17ddda0] [d2509680] jffs2_rmdir+0xa4/0x1cc [jffs2] [c17dddd0] [c026da04] vfs_rmdir+0x180/0x268 [c17dde00] [c026f4e4] do_rmdir+0x2cc/0x300 [c17ddf40] [c001a658] ret_from_syscall+0x0/0x3c The root cause is that we don't get "jffs2_inode_info.sem" before we scan list "jffs2_inode_info.dents" in function jffs2_rmdir. This patch add codes to get "jffs2_inode_info.sem" before we scan "jffs2_inode_info.dents" to slove the UAF problem. Signed-off-by: Zhe Li Reviewed-by: Hou Tao Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 7beedf14a639058c7d737b1ccd8fcdaa6cf973ae Author: Guo Ren Date: Sat Jun 27 13:57:06 2020 +0000 riscv: Fixup static_obj() fail [ Upstream commit 6184358da0004c8fd940afda6c0a0fa4027dc911 ] When enable LOCKDEP, static_obj() will cause error. Because some __initdata static variables is before _stext: static int static_obj(const void *obj) { unsigned long start = (unsigned long) &_stext, end = (unsigned long) &_end, addr = (unsigned long) obj; /* * static variable? */ if ((addr >= start) && (addr < end)) return 1; [ 0.067192] INFO: trying to register non-static key. [ 0.067325] the code is fine but needs lockdep annotation. [ 0.067449] turning off the locking correctness validator. [ 0.067718] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc7-dirty #44 [ 0.067945] Call Trace: [ 0.068369] [] walk_stackframe+0x0/0xa4 [ 0.068506] [] show_stack+0x2a/0x34 [ 0.068631] [] dump_stack+0x94/0xca [ 0.068757] [] register_lock_class+0x5b8/0x5bc [ 0.068969] [] __lock_acquire+0x6c/0x1d5c [ 0.069101] [] lock_acquire+0xae/0x312 [ 0.069228] [] _raw_spin_lock_irqsave+0x40/0x5a [ 0.069357] [] complete+0x1e/0x50 [ 0.069479] [] rest_init+0x1b0/0x28a [ 0.069660] [] 0xffffffe0000016a2 [ 0.069779] [] 0xffffffe000001b84 [ 0.069953] [] 0xffffffe000001092 static __initdata DECLARE_COMPLETION(kthreadd_done); noinline void __ref rest_init(void) { ... complete(&kthreadd_done); Signed-off-by: Guo Ren Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit 106f319212e5ff1c11e926bc3e0d4b59eadcc704 Author: Felix Kuehling Date: Tue Jul 28 14:27:04 2020 -0400 drm/ttm: fix offset in VMAs with a pg_offs in ttm_bo_vm_access [ Upstream commit c0001213d195d1bac83e0744c06ff06dd5a8ba53 ] VMAs with a pg_offs that's offset from the start of the vma_node need to adjust the offset within the BO accordingly. This matches the offset calculation in ttm_bo_vm_fault_reserved. Signed-off-by: Felix Kuehling Tested-by: Laurent Morichetti Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/381169/ Signed-off-by: Sasha Levin commit 8da93b0539514f20501080e7af45e6103dea90d4 Author: Darrick J. Wong Date: Tue Jul 14 10:36:09 2020 -0700 xfs: fix inode quota reservation checks [ Upstream commit f959b5d037e71a4d69b5bf71faffa065d9269b4a ] xfs_trans_dqresv is the function that we use to make reservations against resource quotas. Each resource contains two counters: the q_core counter, which tracks resources allocated on disk; and the dquot reservation counter, which tracks how much of that resource has either been allocated or reserved by threads that are working on metadata updates. For disk blocks, we compare the proposed reservation counter against the hard and soft limits to decide if we're going to fail the operation. However, for inodes we inexplicably compare against the q_core counter, not the incore reservation count. Since the q_core counter is always lower than the reservation count and we unlock the dquot between reservation and transaction commit, this means that multiple threads can reserve the last inode count before we hit the hard limit, and when they commit, we'll be well over the hard limit. Fix this by checking against the incore inode reservation counter, since we would appear to maintain that correctly (and that's what we report in GETQUOTA). Signed-off-by: Darrick J. Wong Reviewed-by: Allison Collins Reviewed-by: Chandan Babu R Reviewed-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a8c8ad128e19ce31b3b4ff26642f8ba4fb3674e9 Author: Chuck Lever Date: Tue Jun 30 15:55:45 2020 -0400 svcrdma: Fix another Receive buffer leak [ Upstream commit 64d26422516b2e347b32e6d9b1d40b3c19a62aae ] During a connection tear down, the Receive queue is flushed before the device resources are freed. Typically, all the Receives flush with IB_WR_FLUSH_ERR. However, any pending successful Receives flush with IB_WR_SUCCESS, and the server automatically posts a fresh Receive to replace the completing one. This happens even after the connection has closed and the RQ is drained. Receives that are posted after the RQ is drained appear never to complete, causing a Receive resource leak. The leaked Receive buffer is left DMA-mapped. To prevent these late-posted recv_ctxt's from leaking, block new Receive posting after XPT_CLOSE is set. Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 2a9eccbe614edbb6960040d3940e1ece16a2679a Author: Greg Ungerer Date: Sat Jun 13 17:17:52 2020 +1000 m68knommu: fix overwriting of bits in ColdFire V3 cache control [ Upstream commit bdee0e793cea10c516ff48bf3ebb4ef1820a116b ] The Cache Control Register (CACR) of the ColdFire V3 has bits that control high level caching functions, and also enable/disable the use of the alternate stack pointer register (the EUSP bit) to provide separate supervisor and user stack pointer registers. The code as it is today will blindly clear the EUSP bit on cache actions like invalidation. So it is broken for this case - and that will result in failed booting (interrupt entry and exit processing will be completely hosed). This only affects ColdFire V3 parts that support the alternate stack register (like the 5329 for example) - generally speaking new parts do, older parts don't. It has no impact on ColdFire V3 parts with the single stack pointer, like the 5307 for example. Fix the cache bit defines used, so they maintain the EUSP bit when carrying out cache actions through the CACR register. Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 4accb5af385b80d2cb68aa56fcbe818bcd6ee7b9 Author: Jinyang He Date: Sat Jul 25 13:56:38 2020 +0800 MIPS: Fix unable to reserve memory for Crash kernel [ Upstream commit b1ce9716f3b5ed3b49badf1f003b9e34b7ead0f9 ] Use 0 as the align parameter in memblock_find_in_range() is incorrect when we reserve memory for Crash kernel. The environment as follows: [ 0.000000] MIPS: machine is loongson,loongson64c-4core-rs780e ... [ 1.951016] crashkernel=64M@128M The warning as follows: [ 0.000000] Invalid memory region reserved for crash kernel And the iomem as follows: 00200000-0effffff : System RAM 04000000-0484009f : Kernel code 048400a0-04ad7fff : Kernel data 04b40000-05c4c6bf : Kernel bss 1a000000-1bffffff : pci@1a000000 ... The align parameter may be finally used by round_down() or round_up(). Like the following call tree: mips-next: mm/memblock.c memblock_find_in_range └── memblock_find_in_range_node ├── __memblock_find_range_bottom_up │ └── round_up └── __memblock_find_range_top_down └── round_down \#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1) \#define round_down(x, y) ((x) & ~__round_mask(x, y)) \#define __round_mask(x, y) ((__typeof__(x))((y)-1)) The round_down(or round_up)'s second parameter must be a power of 2. If the second parameter is 0, it both will return 0. Use 1 as the parameter to fix the bug and the iomem as follows: 00200000-0effffff : System RAM 04000000-0484009f : Kernel code 048400a0-04ad7fff : Kernel data 04b40000-05c4c6bf : Kernel bss 08000000-0bffffff : Crash kernel 1a000000-1bffffff : pci@1a000000 ... Signed-off-by: Jinyang He Reviewed-by: Jiaxun Yang Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin commit 689bee9eb02a20bc1746ef43b6e76bbb3bc1e7ee Author: Xiongfeng Wang Date: Tue Jul 21 22:24:07 2020 -0700 Input: psmouse - add a newline when printing 'proto' by sysfs [ Upstream commit 4aec14de3a15cf9789a0e19c847f164776f49473 ] When I cat parameter 'proto' by sysfs, it displays as follows. It's better to add a newline for easy reading. root@syzkaller:~# cat /sys/module/psmouse/parameters/proto autoroot@syzkaller:~# Signed-off-by: Xiongfeng Wang Link: https://lore.kernel.org/r/20200720073846.120724-1-wangxiongfeng2@huawei.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit f6b2fb80ffdc1509686eec9914a7a7d212bf1069 Author: Jaegeuk Kim Date: Thu Jul 16 09:57:03 2020 -0700 f2fs: should avoid inode eviction in synchronous path [ Upstream commit b0f3b87fb3abc42c81d76c6c5795f26dbdb2f04b ] https://bugzilla.kernel.org/show_bug.cgi?id=208565 PID: 257 TASK: ecdd0000 CPU: 0 COMMAND: "init" #0 [] (__schedule) from [] #1 [] (schedule) from [] #2 [] (rwsem_down_read_failed) from [] #3 [] (down_read) from [] #4 [] (f2fs_truncate_blocks) from [] #5 [] (f2fs_truncate) from [] #6 [] (f2fs_evict_inode) from [] #7 [] (evict) from [] #8 [] (iput) from [] #9 [] (f2fs_sync_node_pages) from [] #10 [] (f2fs_write_checkpoint) from [] #11 [] (f2fs_sync_fs) from [] #12 [] (f2fs_do_sync_file) from [] #13 [] (f2fs_sync_file) from [] #14 [] (vfs_fsync_range) from [] #15 [] (do_fsync) from [] #16 [] (sys_fsync) from [] This can be caused by flush_dirty_inode() in f2fs_sync_node_pages() where iput() requires f2fs_lock_op() again resulting in livelock. Reported-by: Zhiguo Niu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit a692a28626e205ecd5dc5de8580bfe362ff0e54c Author: Evgeny Novikov Date: Fri Jul 10 11:02:23 2020 +0200 media: vpss: clean up resources in init [ Upstream commit 9c487b0b0ea7ff22127fe99a7f67657d8730ff94 ] If platform_driver_register() fails within vpss_init() resources are not cleaned up. The patch fixes this issue by introducing the corresponding error handling. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Evgeny Novikov Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b0eecd0e3c05ac0b7d9d7ca420beeea30126b68d Author: Huacai Chen Date: Sat Jun 20 20:04:43 2020 +0800 rtc: goldfish: Enable interrupt in set_alarm() when necessary [ Upstream commit 22f8d5a1bf230cf8567a4121fc3789babb46336d ] When use goldfish rtc, the "hwclock" command fails with "select() to /dev/rtc to wait for clock tick timed out". This is because "hwclock" need the set_alarm() hook to enable interrupt when alrm->enabled is true. This operation is missing in goldfish rtc (but other rtc drivers, such as cmos rtc, enable interrupt here), so add it. Signed-off-by: Huacai Chen Signed-off-by: Jiaxun Yang Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/1592654683-31314-1-git-send-email-chenhc@lemote.com Signed-off-by: Sasha Levin commit e055ffe8d48a344228bea0e5a4d725671f50a429 Author: Chao Yu Date: Fri Jun 19 17:14:19 2020 +0800 f2fs: fix to check page dirty status before writeback [ Upstream commit eb1353cfa9c1e9415b03dc117f8399969fa02102 ] In f2fs_write_raw_pages(), we need to check page dirty status before writeback, because there could be a racer (e.g. reclaimer) helps writebacking the dirty page. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 527b13f612dfb2a8dd5034d5bffb16381fff5562 Author: Chen Zhou Date: Sat May 9 04:07:11 2020 +0200 media: coda: jpeg: add NULL check after kmalloc [ Upstream commit 20171723144ca0d057b72e852536992fd371369a ] Fixes coccicheck warning: ./drivers/media/platform/coda/coda-jpeg.c:331:3-31: alloc with no test, possible model on line 354 Add NULL check after kmalloc. Signed-off-by: Chen Zhou Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit cd67c599233f45bf6ddd522b833700b545b2f019 Author: Chuhong Yuan Date: Fri Jun 5 18:17:28 2020 +0200 media: budget-core: Improve exception handling in budget_register() [ Upstream commit fc0456458df8b3421dba2a5508cd817fbc20ea71 ] budget_register() has no error handling after its failure. Add the missed undo functions for error handling to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f05c0e45e0b751e949a02f5d11979776a034cebf Author: Bodo Stroesser Date: Thu Jun 18 15:16:32 2020 +0200 scsi: target: tcmu: Fix crash in tcmu_flush_dcache_range on ARM [ Upstream commit 3145550a7f8b08356c8ff29feaa6c56aca12901d ] This patch fixes the following crash (see https://bugzilla.kernel.org/show_bug.cgi?id=208045) Process iscsi_trx (pid: 7496, stack limit = 0x0000000010dd111a) CPU: 0 PID: 7496 Comm: iscsi_trx Not tainted 4.19.118-0419118-generic #202004230533 Hardware name: Greatwall QingTian DF720/F601, BIOS 601FBE20 Sep 26 2019 pstate: 80400005 (Nzcv daif +PAN -UAO) pc : flush_dcache_page+0x18/0x40 lr : is_ring_space_avail+0x68/0x2f8 [target_core_user] sp : ffff000015123a80 x29: ffff000015123a80 x28: 0000000000000000 x27: 0000000000001000 x26: ffff000023ea5000 x25: ffffcfa25bbe08b8 x24: 0000000000000078 x23: ffff7e0000000000 x22: ffff000023ea5001 x21: ffffcfa24b79c000 x20: 0000000000000fff x19: ffff7e00008fa940 x18: 0000000000000000 x17: 0000000000000000 x16: ffff2d047e709138 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: ffff2d047fbd0a40 x11: 0000000000000000 x10: 0000000000000030 x9 : 0000000000000000 x8 : ffffc9a254820a00 x7 : 00000000000013b0 x6 : 000000000000003f x5 : 0000000000000040 x4 : ffffcfa25bbe08e8 x3 : 0000000000001000 x2 : 0000000000000078 x1 : ffffcfa25bbe08b8 x0 : ffff2d040bc88a18 Call trace: flush_dcache_page+0x18/0x40 is_ring_space_avail+0x68/0x2f8 [target_core_user] queue_cmd_ring+0x1f8/0x680 [target_core_user] tcmu_queue_cmd+0xe4/0x158 [target_core_user] __target_execute_cmd+0x30/0xf0 [target_core_mod] target_execute_cmd+0x294/0x390 [target_core_mod] transport_generic_new_cmd+0x1e8/0x358 [target_core_mod] transport_handle_cdb_direct+0x50/0xb0 [target_core_mod] iscsit_execute_cmd+0x2b4/0x350 [iscsi_target_mod] iscsit_sequence_cmd+0xd8/0x1d8 [iscsi_target_mod] iscsit_process_scsi_cmd+0xac/0xf8 [iscsi_target_mod] iscsit_get_rx_pdu+0x404/0xd00 [iscsi_target_mod] iscsi_target_rx_thread+0xb8/0x130 [iscsi_target_mod] kthread+0x130/0x138 ret_from_fork+0x10/0x18 Code: f9000bf3 aa0003f3 aa1e03e0 d503201f (f9400260) ---[ end trace 1e451c73f4266776 ]--- The solution is based on patch: "scsi: target: tcmu: Optimize use of flush_dcache_page" which restricts the use of tcmu_flush_dcache_range() to addresses from vmalloc'ed areas only. This patch now replaces the virt_to_page() call in tcmu_flush_dcache_range() - which is wrong for vmalloced addrs - by vmalloc_to_page(). The patch was tested on ARM with kernel 4.19.118 and 5.7.2 Link: https://lore.kernel.org/r/20200618131632.32748-3-bstroesser@ts.fujitsu.com Tested-by: JiangYu Tested-by: Daniel Meyerholt Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b84142b25caeced087b858723128dd20ff2fbf2a Author: Stanley Chu Date: Fri Jun 12 09:26:24 2020 +0800 scsi: ufs: Add DELAY_BEFORE_LPM quirk for Micron devices [ Upstream commit c0a18ee0ce78d7957ec1a53be35b1b3beba80668 ] It is confirmed that Micron device needs DELAY_BEFORE_LPM quirk to have a delay before VCC is powered off. Sdd Micron vendor ID and this quirk for Micron devices. Link: https://lore.kernel.org/r/20200612012625.6615-2-stanley.chu@mediatek.com Reviewed-by: Bean Huo Reviewed-by: Alim Akhtar Signed-off-by: Stanley Chu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c68589be55fdf3085bdc3c8f0f3dc5fb5579ea95 Author: Chris Wilson Date: Thu Jul 16 10:46:43 2020 +0100 drm/i915: Provide the perf pmu.module [ Upstream commit df3ab3cb7eae63c6eb7c9aebcc196a75d59f65dd ] Rather than manually implement our own module reference counting for perf pmu events, finally realise that there is a module parameter to struct pmu for this very purpose. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20200716094643.31410-1-chris@chris-wilson.co.uk Signed-off-by: Rodrigo Vivi (cherry picked from commit 27e897beec1c59861f15d4d3562c39ad1143620f) Signed-off-by: Jani Nikula Signed-off-by: Sasha Levin commit 3a07e556aa59d4db1274758bee286ee81447a8c6 Author: Pankaj Bharadiya Date: Mon May 4 23:45:58 2020 +0530 drm/i915/pmu: Prefer drm_WARN_ON over WARN_ON [ Upstream commit bf07f6ebffefce2bbf3c318f9ce2f987774ea983 ] struct drm_device specific drm_WARN* macros include device information in the backtrace, so we know what device the warnings originate from. Prefer drm_WARN_ON over WARN_ON. Signed-off-by: Pankaj Bharadiya Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20200504181600.18503-8-pankaj.laxminarayan.bharadiya@intel.com Signed-off-by: Sasha Levin commit 33eb147ff02ff91431a0cdac481ed9b898fb78fd Author: Krunoslav Kovac Date: Thu Aug 6 17:54:47 2020 -0400 drm/amd/display: fix pow() crashing when given base 0 commit d2e59d0ff4c44d1f6f8ed884a5bea7d1bb7fd98c upstream. [Why&How] pow(a,x) is implemented as exp(x*log(a)). log(0) will crash. So return 0^x = 0, unless x=0, convention seems to be 0^0 = 1. Cc: stable@vger.kernel.org Signed-off-by: Krunoslav Kovac Reviewed-by: Anthony Koo Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e0a7a29fb37fae0d775b7178e96e56a6e362b929 Author: Paul Hsieh Date: Wed Aug 5 17:28:37 2020 +0800 drm/amd/display: Fix DFPstate hang due to view port changed commit 8e80d482608a4e6a97c75272ef8b4bcfc5d0c490 upstream. [Why] Place the cursor in the center of screen between two pipes then adjusting the viewport but cursour doesn't update cause DFPstate hang. [How] If viewport changed, update cursor as well. Cc: stable@vger.kernel.org Signed-off-by: Paul Hsieh Reviewed-by: Aric Cyr Acked-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 9cb01ea4fab5524e8290a53717831013fda7c279 Author: Jaehyun Chung Date: Thu Jul 30 16:31:29 2020 -0400 drm/amd/display: Blank stream before destroying HDCP session commit 79940e4d10df9c737a394630968471c632246ee0 upstream. [Why] Stream disable sequence incorretly destroys HDCP session while stream is not blanked and while audio is not muted. This sequence causes a flash of corruption during mode change and an audio click. [How] Change sequence to blank stream before destroying HDCP session. Audio will also be muted by blanking the stream. Cc: stable@vger.kernel.org Signed-off-by: Jaehyun Chung Reviewed-by: Alvin Lee Acked-by: Qingqing Zhuo Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 115e2a7226c084dd3e86bb0fb509f7e03d089e18 Author: Stylon Wang Date: Tue Jul 28 15:10:35 2020 +0800 drm/amd/display: Fix EDID parsing after resume from suspend commit b24bdc37d03a0478189e20a50286092840f414fa upstream. [Why] Resuming from suspend, CEA blocks from EDID are not parsed and no video modes can support YUV420. When this happens, output bpc cannot go over 8-bit with 4K modes on HDMI. [How] In amdgpu_dm_update_connector_after_detect(), drm_add_edid_modes() is called after drm_connector_update_edid_property() to fully parse EDID and update display info. Cc: stable@vger.kernel.org Signed-off-by: Stylon Wang Reviewed-by: Nicholas Kazlauskas Acked-by: Qingqing Zhuo Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit e06fe5e678fee51b3d26021622321f1b23645b80 Author: Aric Cyr Date: Mon Jul 27 21:21:16 2020 -0400 drm/amd/display: Fix incorrect backlight register offset for DCN commit a49f6727e14caff32419cc3002b9ae9cafb750d7 upstream. [Why] Typo in backlight refactor inctroduced wrong register offset. [How] Change DCE to DCN register map for PWRSEQ_REF_DIV Cc: stable@vger.kernel.org Signed-off-by: Aric Cyr Reviewed-by: Ashley Thomas Acked-by: Qingqing Zhuo Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit c20d9803acc25f7fa9c4af674d403c9f09732ef3 Author: Daniel Kolesa Date: Sat Aug 8 22:42:35 2020 +0200 drm/amdgpu/display: use GFP_ATOMIC in dcn20_validate_bandwidth_internal commit f41ed88cbd6f025f7a683a11a74f901555fba11c upstream. GFP_KERNEL may and will sleep, and this is being executed in a non-preemptible context; this will mess things up since it's called inbetween DC_FP_START/END, and rescheduling will result in the DC_FP_END later being called in a different context (or just crashing if any floating point/vector registers/instructions are used after the call is resumed in a different context). Signed-off-by: Daniel Kolesa Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit bdc689905befb91a81fcaae29ac70e2203704012 Author: Christophe JAILLET Date: Sun Aug 9 22:34:06 2020 +0200 drm: amdgpu: Use the correct size when allocating memory commit 78484d7c747e30468b35bd5f19edf602f50162a7 upstream. When '*sgt' is allocated, we must allocated 'sizeof(**sgt)' bytes instead of 'sizeof(*sg)'. The sizeof(*sg) is bigger than sizeof(**sgt) so this wastes memory but it won't lead to corruption. Fixes: f44ffd677fb3 ("drm/amdgpu: add support for exporting VRAM using DMA-buf v3") Reviewed-by: Christian König Signed-off-by: Christophe JAILLET Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 144fa0580fbe72a611e5106e75941436946048fc Author: Yang Shi Date: Fri Aug 14 21:30:41 2020 -0700 mm/memory.c: skip spurious TLB flush for retried page fault commit b7333b58f358f38d90d78e00c1ee5dec82df10ad upstream. Recently we found regression when running will_it_scale/page_fault3 test on ARM64. Over 70% down for the multi processes cases and over 20% down for the multi threads cases. It turns out the regression is caused by commit 89b15332af7c ("mm: drop mmap_sem before calling balance_dirty_pages() in write fault"). The test mmaps a memory size file then write to the mapping, this would make all memory dirty and trigger dirty pages throttle, that upstream commit would release mmap_sem then retry the page fault. The retried page fault would see correct PTEs installed then just fall through to spurious TLB flush. The regression is caused by the excessive spurious TLB flush. It is fine on x86 since x86's spurious TLB flush is no-op. We could just skip the spurious TLB flush to mitigate the regression. Suggested-by: Linus Torvalds Reported-by: Xu Yu Debugged-by: Xu Yu Tested-by: Xu Yu Cc: Johannes Weiner Cc: Catalin Marinas Cc: Will Deacon Cc: Signed-off-by: Yang Shi Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 6f2950ebcd883f315fb537516a7c543a9a553bfc Author: Niklas Schnelle Date: Tue Aug 4 13:01:26 2020 +0200 s390/pci: ignore stale configuration request event commit b76fee1bc56c31a9d2a49592810eba30cc06d61a upstream. A configuration request event may be stale, that is the event may reference a zdev which was already configured. This can happen when a hotplug happens during boot such that the device is discovered and configured in the initial clp_list_pci(), then after initialization we enable events and process the original configuration request which additionally still contains the old disabled function handle leading to a failure during device enablement and subsequent I/O lockout. Fix this by restoring the check that the device to be configured is in standby which was removed in commit f606b3ef47c9 ("s390/pci: adapt events for zbus"). This check does not need serialization as we only enable the events after zPCI has fully initialized, which includes the initial clp_list_pci(), rescan only does updates and events are serialized with respect to each other. Fixes: f606b3ef47c9 ("s390/pci: adapt events for zbus") Cc: # 5.8 Reported-by: Shalini Chellathurai Saroja Tested-by: Shalini Chellathurai Saroja Acked-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 4c86de3bff2983fc561eced719c0c2a14f7fad69 Author: Niklas Schnelle Date: Mon Aug 3 17:58:10 2020 +0200 s390/pci: fix PF/VF linking on hot plug commit b97bf44f99155e57088e16974afb1f2d7b5287aa upstream. Currently there are four places in which a PCI function is scanned and made available to drivers: 1. In pci_scan_root_bus() as part of the initial zbus creation. 2. In zpci_bus_add_devices() when registering a device in configured state on a zbus that has already been scanned. 3. When a function is already known to zPCI (in reserved/standby state) and configuration is triggered through firmware by PEC 0x301. 4. When a device is already known to zPCI (in standby/reserved state) and configuration is triggered from within Linux using enable_slot(). The PF/VF linking step and setting of pdev->is_virtfn introduced with commit e5794cf1a270 ("s390/pci: create links between PFs and VFs") was only triggered for the second case, which is where VFs created through sriov_numvfs usually land. However unlike some other platforms but like POWER VFs can be individually enabled/disabled through /sys/bus/pci/slots. Fix this by doing VF setup as part of pcibios_bus_add_device() which is called in all of the above cases. Finally to remove the PF/VF links call the common code pci_iov_remove_virtfn() function to remove linked VFs. This takes care of the necessary sysfs cleanup. Fixes: e5794cf1a270 ("s390/pci: create links between PFs and VFs") Cc: # 5.8: 2f0230b2f2d5: s390/pci: re-introduce zpci_remove_device() Cc: # 5.8 Acked-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 1d95c4596123b9379d93205f94df2de188913a0a Author: Niklas Schnelle Date: Mon Aug 3 17:46:32 2020 +0200 s390/pci: re-introduce zpci_remove_device() commit 2f0230b2f2d5fd287a85583eefb5aed35b6fe510 upstream. For fixing the PF to VF link removal we need to perform some action on every removal of a zdev from the common PCI subsystem. So in preparation re-introduce zpci_remove_device() and use that instead of directly calling the common code functions. This was actually still declared from earlier code but no longer implemented. Reviewed-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit c77c3fdef0f6179aa2619a3c3c53ebd4648bd66a Author: Niklas Schnelle Date: Mon Aug 3 09:33:29 2020 +0200 s390/pci: fix zpci_bus_link_virtfn() commit 3cddb79afc60bcdb5fd9dd7a1c64a8d03bdd460f upstream. We were missing the pci_dev_put() for candidate PFs. Furhtermore in discussion with upstream it turns out that somewhat counterintuitively some common code, in particular the vfio-pci driver, assumes that pdev->is_virtfn always implies that pdev->physfn is set, i.e. that VFs are always linked. While POWER does seem to set pdev->is_virtfn even for unlinked functions (see comments in arch/powerpc/kernel/eeh.c:eeh_debugfs_break_device()) for now just be safe and only set pdev->is_virtfn on linking. Also make sure that we only search for parent PFs if the zbus is multifunction and we thus know the devfn values supplied by firmware come from the RID. Fixes: e5794cf1a270 ("s390/pci: create links between PFs and VFs") Cc: # 5.8 Reviewed-by: Pierre Morel Signed-off-by: Niklas Schnelle Signed-off-by: Heiko Carstens Signed-off-by: Greg Kroah-Hartman commit 91729fc577b358a73c9d73dd39c21d7581d04629 Author: Yang Weijiang Date: Fri Aug 14 21:21:05 2020 +0800 selftests: kvm: Use a shorter encoding to clear RAX commit 98b0bf02738004829d7e26d6cb47b2e469aaba86 upstream. If debug_regs.c is built with newer binutils, the resulting binary is "optimized" by the assembler: asm volatile("ss_start: " "xor %%rax,%%rax\n\t" "cpuid\n\t" "movl $0x1a0,%%ecx\n\t" "rdmsr\n\t" : : : "rax", "ecx"); is translated to : 000000000040194e : 40194e: 31 c0 xor %eax,%eax <----- rax->eax? 401950: 0f a2 cpuid 401952: b9 a0 01 00 00 mov $0x1a0,%ecx 401957: 0f 32 rdmsr As you can see rax is replaced with eax in target binary code. This causes a difference is the length of xor instruction (2 Byte vs 3 Byte), and makes the hard-coded instruction length check fail: /* Instruction lengths starting at ss_start */ int ss_size[4] = { 3, /* xor */ <-------- 2 or 3? 2, /* cpuid */ 5, /* mov */ 2, /* rdmsr */ }; Encode the shorter version directly and, while at it, fix the "clobbers" of the asm. Cc: stable@vger.kernel.org Signed-off-by: Yang Weijiang Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 171f7e5f7d6a56f4374690dfdcfa9e0c581d5878 Author: Steffen Maier Date: Thu Aug 13 17:28:56 2020 +0200 scsi: zfcp: Fix use-after-free in request timeout handlers commit 2d9a2c5f581be3991ba67fa9e7497c711220ea8e upstream. Before v4.15 commit 75492a51568b ("s390/scsi: Convert timers to use timer_setup()"), we intentionally only passed zfcp_adapter as context argument to zfcp_fsf_request_timeout_handler(). Since we only trigger adapter recovery, it was unnecessary to sync against races between timeout and (late) completion. Likewise, we only passed zfcp_erp_action as context argument to zfcp_erp_timeout_handler(). Since we only wakeup an ERP action, it was unnecessary to sync against races between timeout and (late) completion. Meanwhile the timeout handlers get timer_list as context argument and do a timer-specific container-of to zfcp_fsf_req which can have been freed. Fix it by making sure that any request timeout handlers, that might just have started before del_timer(), are completed by using del_timer_sync() instead. This ensures the request free happens afterwards. Space time diagram of potential use-after-free: Basic idea is to have 2 or more pending requests whose timeouts run out at almost the same time. req 1 timeout ERP thread req 2 timeout ---------------- ---------------- --------------------------------------- zfcp_fsf_request_timeout_handler fsf_req = from_timer(fsf_req, t, timer) adapter = fsf_req->adapter zfcp_qdio_siosl(adapter) zfcp_erp_adapter_reopen(adapter,...) zfcp_erp_strategy ... zfcp_fsf_req_dismiss_all list_for_each_entry_safe zfcp_fsf_req_complete 1 del_timer 1 zfcp_fsf_req_free 1 zfcp_fsf_req_complete 2 zfcp_fsf_request_timeout_handler del_timer 2 fsf_req = from_timer(fsf_req, t, timer) zfcp_fsf_req_free 2 adapter = fsf_req->adapter ^^^^^^^ already freed Link: https://lore.kernel.org/r/20200813152856.50088-1-maier@linux.ibm.com Fixes: 75492a51568b ("s390/scsi: Convert timers to use timer_setup()") Cc: #4.15+ Suggested-by: Julian Wiedmann Reviewed-by: Julian Wiedmann Signed-off-by: Steffen Maier Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 1ae4b74a2302ec46c2cd3ae0ff2a841b7bc69739 Author: zhangyi (F) Date: Sat Jun 20 14:19:48 2020 +0800 jbd2: add the missing unlock_buffer() in the error path of jbd2_write_superblock() commit ef3f5830b859604eda8723c26d90ab23edc027a4 upstream. jbd2_write_superblock() is under the buffer lock of journal superblock before ending that superblock write, so add a missing unlock_buffer() in in the error path before submitting buffer. Fixes: 742b06b5628f ("jbd2: check superblock mapped prior to committing") Signed-off-by: zhangyi (F) Reviewed-by: Ritesh Harjani Cc: stable@kernel.org Link: https://lore.kernel.org/r/20200620061948.2049579-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 38ccb4b484bb5f4d9299fd5cad5e55beb9d614e3 Author: Jan Kara Date: Fri Jul 31 18:21:35 2020 +0200 ext4: fix checking of directory entry validity for inline directories commit 7303cb5bfe845f7d43cd9b2dbd37dbb266efda9b upstream. ext4_search_dir() and ext4_generic_delete_entry() can be called both for standard director blocks and for inline directories stored inside inode or inline xattr space. For the second case we didn't call ext4_check_dir_entry() with proper constraints that could result in accepting corrupted directory entry as well as false positive filesystem errors like: EXT4-fs error (device dm-0): ext4_search_dir:1395: inode #28320400: block 113246792: comm dockerd: bad entry in directory: directory entry too close to block end - offset=0, inode=28320403, rec_len=32, name_len=8, size=4096 Fix the arguments passed to ext4_check_dir_entry(). Fixes: 109ba779d6cc ("ext4: check for directory entries too close to block end") CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20200731162135.8080-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 7535cbdd6cabdadeb95443fe366143c6355bc109 Author: Jan Kara Date: Wed Jul 8 17:35:16 2020 +0200 ext4: do not block RWF_NOWAIT dio write on unallocated space commit 0b3171b6d195637f84ddf8b59bae818ea20bc8ac upstream. Since commit 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") we don't properly bail out of RWF_NOWAIT direct IO write if underlying blocks are not allocated. Also ext4_dio_write_checks() does not honor RWF_NOWAIT when re-acquiring i_rwsem. Fix both issues. Fixes: 378f32bab371 ("ext4: introduce direct I/O write using iomap infrastructure") Cc: stable@kernel.org Reported-by: Filipe Manana Signed-off-by: Jan Kara Reviewed-by: Ritesh Harjani Link: https://lore.kernel.org/r/20200708153516.9507-1-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit e25d2b38fe64f91e853531dfa4ff07e986a9f9de Author: Stephen Boyd Date: Tue Aug 11 14:28:36 2020 -0700 opp: Put opp table in dev_pm_opp_set_rate() if _set_opp_bw() fails commit d4ec88d205583ac4f9482cf3e89128589bd881d2 upstream. We get the opp_table pointer at the top of the function and so we should put the pointer at the end of the function like all other exit paths from this function do. Cc: v5.8+ # v5.8+ Fixes: b00e667a6d8b ("opp: Remove bandwidth votes when target_freq is zero") Reviewed-by: Rajendra Nayak Signed-off-by: Stephen Boyd [ Viresh: Split the patch into two ] Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 9cb98fa067faa4592833552baf76b33d0cc8412b Author: Stephen Boyd Date: Tue Aug 11 14:28:36 2020 -0700 opp: Put opp table in dev_pm_opp_set_rate() for empty tables commit 8979ef70850eb469e1094279259d1ef393ffe85f upstream. We get the opp_table pointer at the top of the function and so we should put the pointer at the end of the function like all other exit paths from this function do. Cc: v5.7+ # v5.7+ Fixes: aca48b61f963 ("opp: Manage empty OPP tables with clk handle") Reviewed-by: Rajendra Nayak Signed-off-by: Stephen Boyd [ Viresh: Split the patch into two ] Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit e8996e480762da98971e29a518596f414c3f2248 Author: Rajendra Nayak Date: Mon Aug 10 12:36:19 2020 +0530 opp: Enable resources again if they were disabled earlier commit a4501bac0e553bed117b7e1b166d49731caf7260 upstream. dev_pm_opp_set_rate() can now be called with freq = 0 in order to either drop performance or bandwidth votes or to disable regulators on platforms which support them. In such cases, a subsequent call to dev_pm_opp_set_rate() with the same frequency ends up returning early because 'old_freq == freq' Instead make it fall through and put back the dropped performance and bandwidth votes and/or enable back the regulators. Cc: v5.3+ # v5.3+ Fixes: cd7ea582866f ("opp: Make dev_pm_opp_set_rate() handle freq = 0 to drop performance votes") Reported-by: Sajida Bhanu Reviewed-by: Sibi Sankar Reported-by: Matthias Kaehlcke Tested-by: Matthias Kaehlcke Reviewed-by: Stephen Boyd Signed-off-by: Rajendra Nayak [ Viresh: Don't skip clk_set_rate() and massaged changelog ] Signed-off-by: Viresh Kumar Signed-off-by: Greg Kroah-Hartman commit 6b5b9fdedd98880c7a8e5c98501c19deb8556ca2 Author: Kaike Wan Date: Tue Aug 11 13:49:31 2020 -0400 RDMA/hfi1: Correct an interlock issue for TID RDMA WRITE request commit b25e8e85e75a61af1ddc88c4798387dd3132dd43 upstream. The following message occurs when running an AI application with TID RDMA enabled: hfi1 0000:7f:00.0: hfi1_0: [QP74] hfi1_tid_timeout 4084 hfi1 0000:7f:00.0: hfi1_0: [QP70] hfi1_tid_timeout 4084 The issue happens when TID RDMA WRITE request is followed by an IB_WR_RDMA_WRITE_WITH_IMM request, the latter could be completed first on the responder side. As a result, no ACK packet for the latter could be sent because the TID RDMA WRITE request is still being processed on the responder side. When the TID RDMA WRITE request is eventually completed, the requester will wait for the IB_WR_RDMA_WRITE_WITH_IMM request to be acknowledged. If the next request is another TID RDMA WRITE request, no TID RDMA WRITE DATA packet could be sent because the preceding IB_WR_RDMA_WRITE_WITH_IMM request is not completed yet. Consequently the IB_WR_RDMA_WRITE_WITH_IMM will be retried but it will be ignored on the responder side because the responder thinks it has already been completed. Eventually the retry will be exhausted and the qp will be put into error state on the requester side. On the responder side, the TID resource timer will eventually expire because no TID RDMA WRITE DATA packets will be received for the second TID RDMA WRITE request. There is also risk of a write-after-write memory corruption due to the issue. Fix by adding a requester side interlock to prevent any potential data corruption and TID RDMA protocol error. Fixes: a0b34f75ec20 ("IB/hfi1: Add interlock between a TID RDMA request and other requests") Link: https://lore.kernel.org/r/20200811174931.191210.84093.stgit@awfm-01.aw.intel.com Cc: # 5.4.x+ Reviewed-by: Mike Marciniszyn Reviewed-by: Dennis Dalessandro Signed-off-by: Kaike Wan Signed-off-by: Mike Marciniszyn Signed-off-by: Jason Gunthorpe Signed-off-by: Greg Kroah-Hartman commit e0d5793a7aa62fbda5a15e0b2fdd14729ec18d0e Author: Hui Wang Date: Thu Jul 30 20:31:38 2020 +0800 ASoC: amd: renoir: restore two more registers during resume commit ccff7bd468d5e0595176656a051ef67c01f01968 upstream. Recently we found an issue about the suspend and resume. If dmic is recording the sound, and we run suspend and resume, after the resume, the dmic can't work well anymore. we need to close the app and reopen the app, then the dmic could record the sound again. For example, we run "arecord -D hw:CARD=acp,DEV=0 -f S32_LE -c 2 -r 48000 test.wav", then suspend and resume, after the system resume back, we speak to the dmic. then stop the arecord, use aplay to play the test.wav, we could hear the sound recorded after resume is weird, it is not what we speak to the dmic. I found two registers are set in the dai_hw_params(), if the two registers are set during the resume, this issue could be fixed. Move the code of the dai_hw_params() into the pdm_dai_trigger(), then these two registers will be set during resume since pdm_dai_trigger() will be called during resume. And delete the empty function dai_hw_params(). Signed-off-by: Hui Wang Reviewed-by: Vijendar Mukunda Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200730123138.5659-1-hui.wang@canonical.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5b21a116b13658392124777dc1b08f3b1ef3f89e Author: Charan Teja Reddy Date: Thu Aug 20 17:42:27 2020 -0700 mm, page_alloc: fix core hung in free_pcppages_bulk() commit 88e8ac11d2ea3acc003cf01bb5a38c8aa76c3cfd upstream. The following race is observed with the repeated online, offline and a delay between two successive online of memory blocks of movable zone. P1 P2 Online the first memory block in the movable zone. The pcp struct values are initialized to default values,i.e., pcp->high = 0 & pcp->batch = 1. Allocate the pages from the movable zone. Try to Online the second memory block in the movable zone thus it entered the online_pages() but yet to call zone_pcp_update(). This process is entered into the exit path thus it tries to release the order-0 pages to pcp lists through free_unref_page_commit(). As pcp->high = 0, pcp->count = 1 proceed to call the function free_pcppages_bulk(). Update the pcp values thus the new pcp values are like, say, pcp->high = 378, pcp->batch = 63. Read the pcp's batch value using READ_ONCE() and pass the same to free_pcppages_bulk(), pcp values passed here are, batch = 63, count = 1. Since num of pages in the pcp lists are less than ->batch, then it will stuck in while(list_empty(list)) loop with interrupts disabled thus a core hung. Avoid this by ensuring free_pcppages_bulk() is called with proper count of pcp list pages. The mentioned race is some what easily reproducible without [1] because pcp's are not updated for the first memory block online and thus there is a enough race window for P2 between alloc+free and pcp struct values update through onlining of second memory block. With [1], the race still exists but it is very narrow as we update the pcp struct values for the first memory block online itself. This is not limited to the movable zone, it could also happen in cases with the normal zone (e.g., hotplug to a node that only has DMA memory, or no other memory yet). [1]: https://patchwork.kernel.org/patch/11696389/ Fixes: 5f8dcc21211a ("page-allocator: split per-cpu list into one-list-per-migrate-type") Signed-off-by: Charan Teja Reddy Signed-off-by: Andrew Morton Acked-by: David Hildenbrand Acked-by: David Rientjes Acked-by: Michal Hocko Cc: Michal Hocko Cc: Vlastimil Babka Cc: Vinayak Menon Cc: [2.6+] Link: http://lkml.kernel.org/r/1597150703-19003-1-git-send-email-charante@codeaurora.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 3d803ebd631e16d05987f68b4aaa198cb9f05d91 Author: Doug Berger Date: Thu Aug 20 17:42:24 2020 -0700 mm: include CMA pages in lowmem_reserve at boot commit e08d3fdfe2dafa0331843f70ce1ff6c1c4900bf4 upstream. The lowmem_reserve arrays provide a means of applying pressure against allocations from lower zones that were targeted at higher zones. Its values are a function of the number of pages managed by higher zones and are assigned by a call to the setup_per_zone_lowmem_reserve() function. The function is initially called at boot time by the function init_per_zone_wmark_min() and may be called later by accesses of the /proc/sys/vm/lowmem_reserve_ratio sysctl file. The function init_per_zone_wmark_min() was moved up from a module_init to a core_initcall to resolve a sequencing issue with khugepaged. Unfortunately this created a sequencing issue with CMA page accounting. The CMA pages are added to the managed page count of a zone when cma_init_reserved_areas() is called at boot also as a core_initcall. This makes it uncertain whether the CMA pages will be added to the managed page counts of their zones before or after the call to init_per_zone_wmark_min() as it becomes dependent on link order. With the current link order the pages are added to the managed count after the lowmem_reserve arrays are initialized at boot. This means the lowmem_reserve values at boot may be lower than the values used later if /proc/sys/vm/lowmem_reserve_ratio is accessed even if the ratio values are unchanged. In many cases the difference is not significant, but for example an ARM platform with 1GB of memory and the following memory layout cma: Reserved 256 MiB at 0x0000000030000000 Zone ranges: DMA [mem 0x0000000000000000-0x000000002fffffff] Normal empty HighMem [mem 0x0000000030000000-0x000000003fffffff] would result in 0 lowmem_reserve for the DMA zone. This would allow userspace to deplete the DMA zone easily. Funnily enough $ cat /proc/sys/vm/lowmem_reserve_ratio would fix up the situation because as a side effect it forces setup_per_zone_lowmem_reserve. This commit breaks the link order dependency by invoking init_per_zone_wmark_min() as a postcore_initcall so that the CMA pages have the chance to be properly accounted in their zone(s) and allowing the lowmem_reserve arrays to receive consistent values. Fixes: bc22af74f271 ("mm: update min_free_kbytes from khugepaged after core initialization") Signed-off-by: Doug Berger Signed-off-by: Andrew Morton Acked-by: Michal Hocko Cc: Jason Baron Cc: David Rientjes Cc: "Kirill A. Shutemov" Cc: Link: http://lkml.kernel.org/r/1597423766-27849-1-git-send-email-opendmb@gmail.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 37d1789de2746c919f37df66d24ece108aa784c7 Author: Phillip Lougher Date: Thu Aug 20 17:42:21 2020 -0700 squashfs: avoid bio_alloc() failure with 1Mbyte blocks commit f26044c83e6e473a61917f5db411d1417327d425 upstream. This is a regression introduced by the patch "migrate from ll_rw_block usage to BIO". Bio_alloc() is limited to 256 pages (1 Mbyte). This can cause a failure when reading 1 Mbyte block filesystems. The problem is a datablock can be fully (or almost uncompressed), requiring 256 pages, but, because blocks are not aligned to page boundaries, it may require 257 pages to read. Bio_kmalloc() can handle 1024 pages, and so use this for the edge condition. Fixes: 93e72b3c612a ("squashfs: migrate from ll_rw_block usage to BIO") Reported-by: Nicolas Prochazka Reported-by: Tomoatsu Shimada Signed-off-by: Phillip Lougher Signed-off-by: Andrew Morton Reviewed-by: Guenter Roeck Cc: Philippe Liard Cc: Christoph Hellwig Cc: Adrien Schildknecht Cc: Daniel Rosenberg Cc: Link: http://lkml.kernel.org/r/20200815035637.15319-1-phillip@squashfs.org.uk Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a1a1ea5981773697f61622557a28c5d70ce81337 Author: Hugh Dickins Date: Thu Aug 20 17:42:17 2020 -0700 uprobes: __replace_page() avoid BUG in munlock_vma_page() commit c17c3dc9d08b9aad9a55a1e53f205187972f448e upstream. syzbot crashed on the VM_BUG_ON_PAGE(PageTail) in munlock_vma_page(), when called from uprobes __replace_page(). Which of many ways to fix it? Settled on not calling when PageCompound (since Head and Tail are equals in this context, PageCompound the usual check in uprobes.c, and the prior use of FOLL_SPLIT_PMD will have cleared PageMlocked already). Fixes: 5a52c9df62b4 ("uprobe: use FOLL_SPLIT_PMD instead of FOLL_SPLIT") Reported-by: syzbot Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Reviewed-by: Srikar Dronamraju Acked-by: Song Liu Acked-by: Oleg Nesterov Cc: "Kirill A. Shutemov" Cc: [5.4+] Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008161338360.20413@eggly.anvils Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 14fb06cc4b3859c3c479fe767d4f1ee10cc7ac64 Author: Wei Yongjun Date: Thu Aug 20 17:42:14 2020 -0700 kernel/relay.c: fix memleak on destroy relay channel commit 71e843295c680898959b22dc877ae3839cc22470 upstream. kmemleak report memory leak as follows: unreferenced object 0x607ee4e5f948 (size 8): comm "syz-executor.1", pid 2098, jiffies 4295031601 (age 288.468s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: relay_open kernel/relay.c:583 [inline] relay_open+0xb6/0x970 kernel/relay.c:563 do_blk_trace_setup+0x4a8/0xb20 kernel/trace/blktrace.c:557 __blk_trace_setup+0xb6/0x150 kernel/trace/blktrace.c:597 blk_trace_ioctl+0x146/0x280 kernel/trace/blktrace.c:738 blkdev_ioctl+0xb2/0x6a0 block/ioctl.c:613 block_ioctl+0xe5/0x120 fs/block_dev.c:1871 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x170/0x1ce fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 'chan->buf' is malloced in relay_open() by alloc_percpu() but not free while destroy the relay channel. Fix it by adding free_percpu() before return from relay_destroy_channel(). Fixes: 017c59c042d0 ("relay: Use per CPU constructs for the relay channel buffer pointers") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Signed-off-by: Andrew Morton Reviewed-by: Chris Wilson Cc: Al Viro Cc: Michael Ellerman Cc: David Rientjes Cc: Michel Lespinasse Cc: Daniel Axtens Cc: Thomas Gleixner Cc: Akash Goel Cc: Link: http://lkml.kernel.org/r/20200817122826.48518-1-weiyongjun1@huawei.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 734a5c3f266c26ff785bc1fcf083b55fcda47ff5 Author: Jann Horn Date: Thu Aug 20 17:42:11 2020 -0700 romfs: fix uninitialized memory leak in romfs_dev_read() commit bcf85fcedfdd17911982a3e3564fcfec7b01eebd upstream. romfs has a superblock field that limits the size of the filesystem; data beyond that limit is never accessed. romfs_dev_read() fetches a caller-supplied number of bytes from the backing device. It returns 0 on success or an error code on failure; therefore, its API can't represent short reads, it's all-or-nothing. However, when romfs_dev_read() detects that the requested operation would cross the filesystem size limit, it currently silently truncates the requested number of bytes. This e.g. means that when the content of a file with size 0x1000 starts one byte before the filesystem size limit, ->readpage() will only fill a single byte of the supplied page while leaving the rest uninitialized, leaking that uninitialized memory to userspace. Fix it by returning an error code instead of truncating the read when the requested read operation would go beyond the end of the filesystem. Fixes: da4458bda237 ("NOMMU: Make it possible for RomFS to use MTD devices directly") Signed-off-by: Jann Horn Signed-off-by: Andrew Morton Reviewed-by: Greg Kroah-Hartman Cc: David Howells Cc: Link: http://lkml.kernel.org/r/20200818013202.2246365-1-jannh@google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 0675a6f26bd8caf5e504f7bfb2d8e388e243f51a Author: Aneesh Kumar K.V Date: Thu Aug 20 17:42:05 2020 -0700 mm/vunmap: add cond_resched() in vunmap_pmd_range commit e47110e90584a22e9980510b00d0dfad3a83354e upstream. Like zap_pte_range add cond_resched so that we can avoid softlockups as reported below. On non-preemptible kernel with large I/O map region (like the one we get when using persistent memory with sector mode), an unmap of the namespace can report below softlockups. 22724.027334] watchdog: BUG: soft lockup - CPU#49 stuck for 23s! [ndctl:50777] NIP [c0000000000dc224] plpar_hcall+0x38/0x58 LR [c0000000000d8898] pSeries_lpar_hpte_invalidate+0x68/0xb0 Call Trace: flush_hash_page+0x114/0x200 hpte_need_flush+0x2dc/0x540 vunmap_page_range+0x538/0x6f0 free_unmap_vmap_area+0x30/0x70 remove_vm_area+0xfc/0x140 __vunmap+0x68/0x270 __iounmap.part.0+0x34/0x60 memunmap+0x54/0x70 release_nodes+0x28c/0x300 device_release_driver_internal+0x16c/0x280 unbind_store+0x124/0x170 drv_attr_store+0x44/0x60 sysfs_kf_write+0x64/0x90 kernfs_fop_write+0x1b0/0x290 __vfs_write+0x3c/0x70 vfs_write+0xd8/0x260 ksys_write+0xdc/0x130 system_call+0x5c/0x70 Reported-by: Harish Sriram Signed-off-by: Aneesh Kumar K.V Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Link: http://lkml.kernel.org/r/20200807075933.310240-1-aneesh.kumar@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 917cdc0d2c53637e3cce1a216bfa4e0477c7851b Author: Jens Axboe Date: Sun Aug 16 08:23:05 2020 -0700 io_uring: find and cancel head link async work on files exit commit b711d4eaf0c408a811311ee3e94d6e9e5a230a9a upstream. Commit f254ac04c874 ("io_uring: enable lookup of links holding inflight files") only handled 2 out of the three head link cases we have, we also need to lookup and cancel work that is blocked in io-wq if that work has a link that's holding a reference to the files structure. Put the "cancel head links that hold this request pending" logic into io_attempt_cancel(), which will to through the motions of finding and canceling head links that hold the current inflight files stable request pending. Cc: stable@vger.kernel.org Reported-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 93366cb8105607a890ecc6d742d75c0d0ab58071 Author: Lukas Wunner Date: Mon Aug 3 13:09:01 2020 +0200 spi: Prevent adding devices below an unregistering controller commit ddf75be47ca748f8b12d28ac64d624354fddf189 upstream. CONFIG_OF_DYNAMIC and CONFIG_ACPI allow adding SPI devices at runtime using a DeviceTree overlay or DSDT patch. CONFIG_SPI_SLAVE allows the same via sysfs. But there are no precautions to prevent adding a device below a controller that's being removed. Such a device is unusable and may not even be able to unbind cleanly as it becomes inaccessible once the controller has been torn down. E.g. it is then impossible to quiesce the device's interrupt. of_spi_notify() and acpi_spi_notify() do hold a ref on the controller, but otherwise run lockless against spi_unregister_controller(). Fix by holding the spi_add_lock in spi_unregister_controller() and bailing out of spi_add_device() if the controller has been unregistered concurrently. Fixes: ce79d54ae447 ("spi/of: Add OF notifier handler") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.19+ Cc: Geert Uytterhoeven Cc: Octavian Purdila Cc: Pantelis Antoniou Link: https://lore.kernel.org/r/a8c3205088a969dc8410eec1eba9aface60f36af.1596451035.git.lukas@wunner.de Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit a14e7ce59232430d582c7d78b4f591d50b69f7ad Author: Oleksij Rempel Date: Fri Aug 7 12:51:58 2020 +0200 can: j1939: socket: j1939_sk_bind(): make sure ml_priv is allocated commit af804b7826350d5af728dca4715e473338fbd7e5 upstream. This patch adds check to ensure that the struct net_device::ml_priv is allocated, as it is used later by the j1939 stack. The allocation is done by all mainline CAN network drivers, but when using bond or team devices this is not the case. Bail out if no ml_priv is allocated. Reported-by: syzbot+f03d384f3455d28833eb@syzkaller.appspotmail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Cc: linux-stable # >= v5.4 Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20200807105200.26441-4-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit cf3b3ffb272c6146da2c6f9afa59980a7aa78ef0 Author: Oleksij Rempel Date: Fri Aug 7 12:51:57 2020 +0200 can: j1939: transport: j1939_session_tx_dat(): fix use-after-free read in j1939_tp_txtimer() commit cd3b3636c99fcac52c598b64061f3fe4413c6a12 upstream. The current stack implementation do not support ECTS requests of not aligned TP sized blocks. If ECTS will request a block with size and offset spanning two TP blocks, this will cause memcpy() to read beyond the queued skb (which does only contain one TP sized block). Sometimes KASAN will detect this read if the memory region beyond the skb was previously allocated and freed. In other situations it will stay undetected. The ETP transfer in any case will be corrupted. This patch adds a sanity check to avoid this kind of read and abort the session with error J1939_XTP_ABORT_ECTS_TOO_BIG. Reported-by: syzbot+5322482fe520b02aea30@syzkaller.appspotmail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Cc: linux-stable # >= v5.4 Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20200807105200.26441-3-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 2d790596d76f32b512c921a4059453097c0fa282 Author: Mike Pozulp Date: Tue Aug 18 09:54:44 2020 -0700 ALSA: hda/realtek: Add quirk for Samsung Galaxy Book Ion commit e17f02d0559c174cf1f6435e45134490111eaa37 upstream. The Galaxy Book Ion uses the same ALC298 codec as other Samsung laptops which have the no headphone sound bug, like my Samsung Notebook. The Galaxy Book owner confirmed that this patch fixes the bug. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423 Signed-off-by: Mike Pozulp Cc: Link: https://lore.kernel.org/r/20200818165446.499821-1-pozulp.kernel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit c20d8d9c04b94f940e6c85900713f08e9a4746aa Author: Mike Pozulp Date: Thu Aug 13 21:53:44 2020 -0700 ALSA: hda/realtek: Add quirk for Samsung Galaxy Flex Book commit f70fff83cda63bbf596f99edc131b9daaba07458 upstream. The Flex Book uses the same ALC298 codec as other Samsung laptops which have the no headphone sound bug, like my Samsung Notebook. The Flex Book owner used Early Patching to confirm that this quirk fixes the bug. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423 Signed-off-by: Mike Pozulp Cc: Link: https://lore.kernel.org/r/20200814045346.645367-1-pozulp.kernel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 44d8f487a7d688c268bf4aa6569d6b249271524d Author: Sameer Pujar Date: Wed Aug 19 21:02:10 2020 +0530 ALSA: hda: avoid reset of sdo_limit commit b90b925fd52c75ee7531df739d850a1f7c58ef06 upstream. By default 'sdo_limit' is initialized with a default value of '8' as per spec. This is overridden in cases where a different value is required. However this is getting reset when snd_hdac_bus_init_chip() is called again, which happens during runtime PM cycle. Avoid this reset by moving 'sdo_limit' setup to 'snd_hdac_bus_init()' function which would be called only once. Fixes: 67ae482a59e9 ("ALSA: hda: add member to store ratio for stripe control") Cc: Signed-off-by: Sameer Pujar Link: https://lore.kernel.org/r/1597851130-6765-1-git-send-email-spujar@nvidia.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6a1624ca6229571cd985df3bd9d4d849fd263074 Author: Hugh Dickins Date: Thu Aug 20 17:42:02 2020 -0700 khugepaged: adjust VM_BUG_ON_MM() in __khugepaged_enter() [ Upstream commit f3f99d63a8156c7a4a6b20aac22b53c5579c7dc1 ] syzbot crashes on the VM_BUG_ON_MM(khugepaged_test_exit(mm), mm) in __khugepaged_enter(): yes, when one thread is about to dump core, has set core_state, and is waiting for others, another might do something calling __khugepaged_enter(), which now crashes because I lumped the core_state test (known as "mmget_still_valid") into khugepaged_test_exit(). I still think it's best to lump them together, so just in this exceptional case, check mm->mm_users directly instead of khugepaged_test_exit(). Fixes: bbe98f9cadff ("khugepaged: khugepaged_test_exit() check mmget_still_valid()") Reported-by: syzbot Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Acked-by: Yang Shi Cc: "Kirill A. Shutemov" Cc: Andrea Arcangeli Cc: Song Liu Cc: Mike Kravetz Cc: Eric Dumazet Cc: [4.8+] Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2008141503370.18085@eggly.anvils Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 801515285db365d0c54137dfc00b4ca00eea93d5 Author: Thomas Zimmermann Date: Thu Jul 16 14:53:52 2020 +0200 drm/ast: Initialize DRAM type before posting GPU [ Upstream commit 244d012801dae30c91983b360457c78d481584b0 ] Posting the GPU requires the correct DRAM type to be stored in struct ast_private. Therefore first initialize the DRAM info and then post the GPU. This restores the original order of instructions in this function. Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Acked-by: Benjamin Herrenschmidt Fixes: bad09da6deab ("drm/ast: Fixed vram size incorrect issue on POWER") Cc: Joel Stanley Cc: Y.C. Chen Cc: Benjamin Herrenschmidt Cc: Dave Airlie Cc: Thomas Zimmermann Cc: Gerd Hoffmann Cc: Daniel Vetter Cc: Sam Ravnborg Cc: Emil Velikov Cc: "Y.C. Chen" Cc: # v4.11+ Link: https://patchwork.freedesktop.org/patch/msgid/20200716125353.31512-6-tzimmermann@suse.de Signed-off-by: Sasha Levin commit 38814f974d34be315990092527f0f17e76fdc3af Author: Thomas Zimmermann Date: Wed Jun 17 10:03:37 2020 +0200 drm/ast: Remove unused code paths for AST 1180 [ Upstream commit 05f13f5b5996d20a9819e0c6fd0cda4956c8aff9 ] The ast driver contains code paths for AST 1180 chips. The chip is not supported and the rsp code has never been tested. Simplify the driver by removing the AST 1180 code. Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Reviewed-by: Emil Velikov Link: https://patchwork.freedesktop.org/patch/msgid/20200617080340.29584-2-tzimmermann@suse.de Signed-off-by: Sasha Levin commit f8be691dbd88f4025087a23eac0e0ab621735fa7 Author: Paul Cercueil Date: Thu Jul 16 14:56:46 2020 +0200 drm/panel-simple: Fix inverted V/H SYNC for Frida FRD350H54004 panel [ Upstream commit bad20a2dbfdfaf01560026909506b6ed69d65ba2 ] The FRD350H54004 panel was marked as having active-high VSYNC and HSYNC signals, which sorts-of worked, but resulted in the picture fading out under certain circumstances. Fix this issue by marking VSYNC and HSYNC signals active-low. v2: Rebase on drm-misc-next Fixes: 7b6bd8433609 ("drm/panel: simple: Add support for the Frida FRD350H54004 panel") Cc: stable@vger.kernel.org # v5.5 Signed-off-by: Paul Cercueil Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200716125647.10964-1-paul@crapouillou.net Signed-off-by: Sasha Levin commit f04844351ce253f5886058ee12e5c23f5e0e8cc3 Author: Chris Wilson Date: Wed Jul 8 16:49:11 2020 +0100 drm/vgem: Replace opencoded version of drm_gem_dumb_map_offset() [ Upstream commit 119c53d2d4044c59c450c4f5a568d80b9d861856 ] drm_gem_dumb_map_offset() now exists and does everything vgem_gem_dump_map does and *ought* to do. In particular, vgem_gem_dumb_map() was trying to reject mmapping an imported dmabuf by checking the existence of obj->filp. Unfortunately, we always allocated an obj->filp, even if unused for an imported dmabuf. Instead, the drm_gem_dumb_map_offset(), since commit 90378e589192 ("drm/gem: drm_gem_dumb_map_offset(): reject dma-buf"), uses the obj->import_attach to reject such invalid mmaps. This prevents vgem from allowing userspace mmapping the dumb handle and attempting to incorrectly fault in remote pages belonging to another device, where there may not even be a struct page. v2: Use the default drm_gem_dumb_map_offset() callback Fixes: af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces") Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter Cc: # v4.13+ Link: https://patchwork.freedesktop.org/patch/msgid/20200708154911.21236-1-chris@chris-wilson.co.uk Signed-off-by: Sasha Levin