commit fa7af1d0db05eb5df1890f678d38c67bdcddf37f Author: Alexandre Frade Date: Wed Jun 3 10:07:03 2020 -0300 Linux 5.4.44-xanmod1 Signed-off-by: Alexandre Frade commit daf66320ce8f470ccace7451de9ce3dbecc4c99e Merge: 724355eaf95b 55852b3fd146 Author: Alexandre Frade Date: Wed Jun 3 10:06:35 2020 -0300 Merge tag 'v5.4.44' into 5.4 This is the 5.4.44 stable release commit 55852b3fd146ce90d4d4306b467261f2c4869293 Author: Greg Kroah-Hartman Date: Wed Jun 3 08:21:39 2020 +0200 Linux 5.4.44 commit f2a9b00a68c5343f28a07ee25827e0143567759c Author: Changbin Du Date: Tue Jan 28 23:29:38 2020 +0800 perf: Make perf able to build with latest libbfd commit 0ada120c883d4f1f6aafd01cf0fbb10d8bbba015 upstream. libbfd has changed the bfd_section_* macros to inline functions bfd_section_ since 2019-09-18. See below two commits: o http://www.sourceware.org/ml/gdb-cvs/2019-09/msg00064.html o https://www.sourceware.org/ml/gdb-cvs/2019-09/msg00072.html This fix make perf able to build with both old and new libbfd. Signed-off-by: Changbin Du Acked-by: Jiri Olsa Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20200128152938.31413-1-changbin.du@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Cc: Marek Vasut Signed-off-by: Greg Kroah-Hartman commit 3f57fa847e276a0f0f9d72e4707f35b9362f815a Author: Pablo Neira Ayuso Date: Wed May 27 12:24:10 2020 +0200 netfilter: nf_conntrack_pptp: fix compilation warning with W=1 build commit 4946ea5c1237036155c3b3a24f049fd5f849f8f6 upstream. >> include/linux/netfilter/nf_conntrack_pptp.h:13:20: warning: 'const' type qualifier on return type has no effect [-Wignored-qualifiers] extern const char *const pptp_msg_name(u_int16_t msg); ^~~~~~ Reported-by: kbuild test robot Fixes: 4c559f15efcc ("netfilter: nf_conntrack_pptp: prevent buffer overflows in debug code") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 7a075390b732d8142958c35a181f8df7b9f33293 Author: Nathan Chancellor Date: Wed May 27 01:10:39 2020 -0700 netfilter: conntrack: Pass value of ctinfo to __nf_conntrack_update commit 46c1e0621a72e0469ec4edfdb6ed4d387ec34f8a upstream. Clang warns: net/netfilter/nf_conntrack_core.c:2068:21: warning: variable 'ctinfo' is uninitialized when used here [-Wuninitialized] nf_ct_set(skb, ct, ctinfo); ^~~~~~ net/netfilter/nf_conntrack_core.c:2024:2: note: variable 'ctinfo' is declared here enum ip_conntrack_info ctinfo; ^ 1 warning generated. nf_conntrack_update was split up into nf_conntrack_update and __nf_conntrack_update, where the assignment of ctinfo is in nf_conntrack_update but it is used in __nf_conntrack_update. Pass the value of ctinfo from nf_conntrack_update to __nf_conntrack_update so that uninitialized memory is not used and everything works properly. Fixes: ee04805ff54a ("netfilter: conntrack: make conntrack userspace helpers work again") Link: https://github.com/ClangBuiltLinux/linux/issues/1039 Signed-off-by: Nathan Chancellor Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 987de40bff33f10c2d3286c49ed1435c709c5ccb Author: Pablo Neira Ayuso Date: Wed May 27 12:17:34 2020 +0200 netfilter: conntrack: comparison of unsigned in cthelper confirmation commit 94945ad2b330207cded0fd8d4abebde43a776dfb upstream. net/netfilter/nf_conntrack_core.c: In function nf_confirm_cthelper: net/netfilter/nf_conntrack_core.c:2117:15: warning: comparison of unsigned expression in < 0 is always false [-Wtype-limits] 2117 | if (protoff < 0 || (frag_off & htons(~0x7)) != 0) | ^ ipv6_skip_exthdr() returns a signed integer. Reported-by: Colin Ian King Fixes: 703acd70f249 ("netfilter: nfnetlink_cthelper: unbreak userspace helper support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a4547f63e05f299a5fbfde5b55654c372e49778e Author: Qiushi Wu Date: Wed May 27 22:10:29 2020 -0500 bonding: Fix reference count leak in bond_sysfs_slave_add. commit a068aab42258e25094bc2c159948d263ed7d7a77 upstream. kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 07699f9a7c8d ("bonding: add sysfs /slave dir for bond slave devices.") Signed-off-by: Qiushi Wu Acked-by: Jay Vosburgh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b668b392cc2c65084982b518c221e37667563a57 Author: Vladimir Oltean Date: Wed May 27 21:08:05 2020 +0300 net: dsa: declare lockless TX feature for slave ports commit 2b86cb8299765688c5119fd18d5f436716c81010 upstream. Be there a platform with the following layout: Regular NIC | +----> DSA master for switch port | +----> DSA master for another switch port After changing DSA back to static lockdep class keys in commit 1a33e10e4a95 ("net: partially revert dynamic lockdep key changes"), this kernel splat can be seen: [ 13.361198] ============================================ [ 13.366524] WARNING: possible recursive locking detected [ 13.371851] 5.7.0-rc4-02121-gc32a05ecd7af-dirty #988 Not tainted [ 13.377874] -------------------------------------------- [ 13.383201] swapper/0/0 is trying to acquire lock: [ 13.388004] ffff0000668ff298 (&dsa_slave_netdev_xmit_lock_key){+.-.}-{2:2}, at: __dev_queue_xmit+0x84c/0xbe0 [ 13.397879] [ 13.397879] but task is already holding lock: [ 13.403727] ffff0000661a1698 (&dsa_slave_netdev_xmit_lock_key){+.-.}-{2:2}, at: __dev_queue_xmit+0x84c/0xbe0 [ 13.413593] [ 13.413593] other info that might help us debug this: [ 13.420140] Possible unsafe locking scenario: [ 13.420140] [ 13.426075] CPU0 [ 13.428523] ---- [ 13.430969] lock(&dsa_slave_netdev_xmit_lock_key); [ 13.435946] lock(&dsa_slave_netdev_xmit_lock_key); [ 13.440924] [ 13.440924] *** DEADLOCK *** [ 13.440924] [ 13.446860] May be due to missing lock nesting notation [ 13.446860] [ 13.453668] 6 locks held by swapper/0/0: [ 13.457598] #0: ffff800010003de0 ((&idev->mc_ifc_timer)){+.-.}-{0:0}, at: call_timer_fn+0x0/0x400 [ 13.466593] #1: ffffd4d3fb478700 (rcu_read_lock){....}-{1:2}, at: mld_sendpack+0x0/0x560 [ 13.474803] #2: ffffd4d3fb478728 (rcu_read_lock_bh){....}-{1:2}, at: ip6_finish_output2+0x64/0xb10 [ 13.483886] #3: ffffd4d3fb478728 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x6c/0xbe0 [ 13.492793] #4: ffff0000661a1698 (&dsa_slave_netdev_xmit_lock_key){+.-.}-{2:2}, at: __dev_queue_xmit+0x84c/0xbe0 [ 13.503094] #5: ffffd4d3fb478728 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x6c/0xbe0 [ 13.512000] [ 13.512000] stack backtrace: [ 13.516369] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc4-02121-gc32a05ecd7af-dirty #988 [ 13.530421] Call trace: [ 13.532871] dump_backtrace+0x0/0x1d8 [ 13.536539] show_stack+0x24/0x30 [ 13.539862] dump_stack+0xe8/0x150 [ 13.543271] __lock_acquire+0x1030/0x1678 [ 13.547290] lock_acquire+0xf8/0x458 [ 13.550873] _raw_spin_lock+0x44/0x58 [ 13.554543] __dev_queue_xmit+0x84c/0xbe0 [ 13.558562] dev_queue_xmit+0x24/0x30 [ 13.562232] dsa_slave_xmit+0xe0/0x128 [ 13.565988] dev_hard_start_xmit+0xf4/0x448 [ 13.570182] __dev_queue_xmit+0x808/0xbe0 [ 13.574200] dev_queue_xmit+0x24/0x30 [ 13.577869] neigh_resolve_output+0x15c/0x220 [ 13.582237] ip6_finish_output2+0x244/0xb10 [ 13.586430] __ip6_finish_output+0x1dc/0x298 [ 13.590709] ip6_output+0x84/0x358 [ 13.594116] mld_sendpack+0x2bc/0x560 [ 13.597786] mld_ifc_timer_expire+0x210/0x390 [ 13.602153] call_timer_fn+0xcc/0x400 [ 13.605822] run_timer_softirq+0x588/0x6e0 [ 13.609927] __do_softirq+0x118/0x590 [ 13.613597] irq_exit+0x13c/0x148 [ 13.616918] __handle_domain_irq+0x6c/0xc0 [ 13.621023] gic_handle_irq+0x6c/0x160 [ 13.624779] el1_irq+0xbc/0x180 [ 13.627927] cpuidle_enter_state+0xb4/0x4d0 [ 13.632120] cpuidle_enter+0x3c/0x50 [ 13.635703] call_cpuidle+0x44/0x78 [ 13.639199] do_idle+0x228/0x2c8 [ 13.642433] cpu_startup_entry+0x2c/0x48 [ 13.646363] rest_init+0x1ac/0x280 [ 13.649773] arch_call_rest_init+0x14/0x1c [ 13.653878] start_kernel+0x490/0x4bc Lockdep keys themselves were added in commit ab92d68fc22f ("net: core: add generic lockdep keys"), and it's very likely that this splat existed since then, but I have no real way to check, since this stacked platform wasn't supported by mainline back then. >From Taehee's own words: This patch was considered that all stackable devices have LLTX flag. But the dsa doesn't have LLTX, so this splat happened. After this patch, dsa shares the same lockdep class key. On the nested dsa interface architecture, which you illustrated, the same lockdep class key will be used in __dev_queue_xmit() because dsa doesn't have LLTX. So that lockdep detects deadlock because the same lockdep class key is used recursively although actually the different locks are used. There are some ways to fix this problem. 1. using NETIF_F_LLTX flag. If possible, using the LLTX flag is a very clear way for it. But I'm so sorry I don't know whether the dsa could have LLTX or not. 2. using dynamic lockdep again. It means that each interface uses a separate lockdep class key. So, lockdep will not detect recursive locking. But this way has a problem that it could consume lockdep class key too many. Currently, lockdep can have 8192 lockdep class keys. - you can see this number with the following command. cat /proc/lockdep_stats lock-classes: 1251 [max: 8192] ... The [max: 8192] means that the maximum number of lockdep class keys. If too many lockdep class keys are registered, lockdep stops to work. So, using a dynamic(separated) lockdep class key should be considered carefully. In addition, updating lockdep class key routine might have to be existing. (lockdep_register_key(), lockdep_set_class(), lockdep_unregister_key()) 3. Using lockdep subclass. A lockdep class key could have 8 subclasses. The different subclass is considered different locks by lockdep infrastructure. But "lock-classes" is not counted by subclasses. So, it could avoid stopping lockdep infrastructure by an overflow of lockdep class keys. This approach should also have an updating lockdep class key routine. (lockdep_set_subclass()) 4. Using nonvalidate lockdep class key. The lockdep infrastructure supports nonvalidate lockdep class key type. It means this lockdep is not validated by lockdep infrastructure. So, the splat will not happen but lockdep couldn't detect real deadlock case because lockdep really doesn't validate it. I think this should be used for really special cases. (lockdep_set_novalidate_class()) Further discussion here: https://patchwork.ozlabs.org/project/netdev/patch/20200503052220.4536-2-xiyou.wangcong@gmail.com/ There appears to be no negative side-effect to declaring lockless TX for the DSA virtual interfaces, which means they handle their own locking. So that's what we do to make the splat go away. Patch tested in a wide variety of cases: unicast, multicast, PTP, etc. Fixes: ab92d68fc22f ("net: core: add generic lockdep keys") Suggested-by: Taehee Yoo Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 35c0a6e7ef5524bd58a66d42d5859ec3ce1baf48 Author: David Ahern Date: Tue May 26 12:56:18 2020 -0600 ipv4: nexthop version of fib_info_nh_uses_dev commit 1fd1c768f3624a5e66766e7b4ddb9b607cd834a5 upstream. Similar to the last path, need to fix fib_info_nh_uses_dev for external nexthops to avoid referencing multiple nh_grp structs. Move the device check in fib_info_nh_uses_dev to a helper and create a nexthop version that is called if the fib_info uses an external nexthop. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 568c159356d1ae93f5273dc511d0fa375305f0e7 Author: David Ahern Date: Tue May 26 12:56:16 2020 -0600 nexthop: Expand nexthop_is_multipath in a few places commit 0b5e2e39739e861fa5fc84ab27a35dbe62a15330 upstream. I got too fancy consolidating checks on multipath type. The result is that path lookups can access 2 different nh_grp structs as exposed by Nik's torture tests. Expand nexthop_is_multipath within nexthop.h to avoid multiple, nh_grp dereferences and make decisions based on the consistent struct. Only 2 places left using nexthop_is_multipath are within IPv6, both only check that the nexthop is a multipath for a branching decision which are acceptable. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 88e81db5509b32a1fb3b1efc82757cd8990ea484 Author: Nikolay Aleksandrov Date: Tue May 26 12:56:15 2020 -0600 nexthops: don't modify published nexthop groups commit 90f33bffa382598a32cc82abfeb20adc92d041b6 upstream. We must avoid modifying published nexthop groups while they might be in use, otherwise we might see NULL ptr dereferences. In order to do that we allocate 2 nexthoup group structures upon nexthop creation and swap between them when we have to delete an entry. The reason is that we can't fail nexthop group removal, so we can't handle allocation failure thus we move the extra allocation on creation where we can safely fail and return ENOMEM. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: Nikolay Aleksandrov Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8398275f7aed243e287f6eaf0c829ade0f2803ba Author: David Ahern Date: Tue May 26 12:56:14 2020 -0600 nexthops: Move code from remove_nexthop_from_groups to remove_nh_grp_entry commit ac21753a5c2c9a6a2019997481a2ac12bbde48c8 upstream. Move nh_grp dereference and check for removing nexthop group due to all members gone into remove_nh_grp_entry. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: David Ahern Acked-by: Nikolay Aleksandrov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2b043affcaea8be75f1a8b08173cf5dc69296a82 Author: Eric Dumazet Date: Tue May 26 17:28:56 2020 -0700 crypto: chelsio/chtls: properly set tp->lsndtime commit a4976a3ef844c510ae9120290b23e9f3f47d6bce upstream. TCP tp->lsndtime unit/base is tcp_jiffies32, not tcp_time_stamp() Fixes: 36bedb3f2e5b ("crypto: chtls - Inline TLS record Tx") Signed-off-by: Eric Dumazet Cc: Ayush Sawal Cc: Vinay Kumar Yadav Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a369e8378b48aa8fc93e574e5df7e198cfb88cd4 Author: Qiushi Wu Date: Mon May 25 03:24:39 2020 -0500 qlcnic: fix missing release in qlcnic_83xx_interrupt_test. commit 15c973858903009e995b2037683de29dfe968621 upstream. In function qlcnic_83xx_interrupt_test(), function qlcnic_83xx_diag_alloc_res() is not handled by function qlcnic_83xx_diag_free_res() after a call of the function qlcnic_alloc_mbx_args() failed. Fix this issue by adding a jump target "fail_mbx_args", and jump to this new target when qlcnic_alloc_mbx_args() failed. Fixes: b6b4316c8b2f ("qlcnic: Handle qlcnic_alloc_mbx_args() failure") Signed-off-by: Qiushi Wu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1c38cfc259a7ff1bea18ef8602db86393c849059 Author: Björn Töpel Date: Mon May 25 10:03:59 2020 +0200 xsk: Add overflow check for u64 division, stored into u32 commit b16a87d0aef7a6be766f6618976dc5ff2c689291 upstream. The npgs member of struct xdp_umem is an u32 entity, and stores the number of pages the UMEM consumes. The calculation of npgs npgs = size / PAGE_SIZE can overflow. To avoid overflow scenarios, the division is now first stored in a u64, and the result is verified to fit into 32b. An alternative would be storing the npgs as a u64, however, this wastes memory and is an unrealisticly large packet area. Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt") Reported-by: "Minh Bùi Quang" Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Acked-by: Jonathan Lemon Link: https://lore.kernel.org/bpf/CACtPs=GGvV-_Yj6rbpzTVnopgi5nhMoCcTkSkYrJHGQHJWFZMQ@mail.gmail.com/ Link: https://lore.kernel.org/bpf/20200525080400.13195-1-bjorn.topel@gmail.com Signed-off-by: Greg Kroah-Hartman commit 73c05545fbb558f40ffc2bc81bcd011a340472cd Author: Pradeep Kumar Chitrapu Date: Wed May 6 03:24:30 2020 -0700 ieee80211: Fix incorrect mask for default PE duration commit d031781bdabe1027858a3220f868866586bf6e7c upstream. Fixes bitmask for HE opration's default PE duration. Fixes: daa5b83513a7 ("mac80211: update HE operation fields to D3.0") Signed-off-by: Pradeep Kumar Chitrapu Link: https://lore.kernel.org/r/20200506102430.5153-1-pradeepc@codeaurora.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2e91cd11bafce1363bd9848cf71de4e2bea28d4e Author: Michael Chan Date: Mon May 25 17:41:17 2020 -0400 bnxt_en: Fix accumulation of bp->net_stats_prev. commit b8056e8434b037fdab08158fea99ed7bc8ef3a74 upstream. We have logic to maintain network counters across resets by storing the counters in bp->net_stats_prev before reset. But not all resets will clear the counters. Certain resets that don't need to change the number of rings do not clear the counters. The current logic accumulates the counters before all resets, causing big jumps in the counters after some resets, such as ethtool -G. Fix it by only accumulating the counters during reset if the irq_re_init parameter is set. The parameter signifies that all rings and interrupts will be reset and that means that the counters will also be reset. Reported-by: Vijayendra Suman Fixes: b8875ca356f1 ("bnxt_en: Save ring statistics before reset.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit dda9d0eb7a961808609d1ce793060834f53bf2b3 Author: Xin Long Date: Fri Apr 10 17:06:56 2020 +0800 esp6: get the right proto for transport mode in esp6_gso_encap commit 3c96ec56828922e3fe5477f75eb3fc02f98f98b5 upstream. For transport mode, when ipv6 nexthdr is set, the packet format might be like: ---------------------------------------------------- | | dest | | | | ESP | ESP | | IP6 hdr| opts.| ESP | TCP | Data | Trailer | ICV | ---------------------------------------------------- What it wants to get for x-proto in esp6_gso_encap() is the proto that will be set in ESP nexthdr. So it should skip all ipv6 nexthdrs and get the real transport protocol. Othersize, the wrong proto number will be set into ESP nexthdr. This patch is to skip all ipv6 nexthdrs by calling ipv6_skip_exthdr() in esp6_gso_encap(). Fixes: 7862b4058b9f ("esp: Add gso handlers for esp4 and esp6") Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 9f57771d09f4e62724144f49e3d40b9485f4ab4f Author: Pablo Neira Ayuso Date: Thu May 14 14:14:23 2020 +0200 netfilter: nf_conntrack_pptp: prevent buffer overflows in debug code commit 4c559f15efcc43b996f4da528cd7f9483aaca36d upstream. Dan Carpenter says: "Smatch complains that the value for "cmd" comes from the network and can't be trusted." Add pptp_msg_name() helper function that checks for the array boundary. Fixes: f09943fefe6b ("[NETFILTER]: nf_conntrack/nf_nat: add PPTP helper port") Reported-by: Dan Carpenter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit b16287f99d31d11bf094cbfb2c92d93ac2801942 Author: Pablo Neira Ayuso Date: Sun May 24 21:04:42 2020 +0200 netfilter: nfnetlink_cthelper: unbreak userspace helper support commit 703acd70f2496537457186211c2f03e792409e68 upstream. Restore helper data size initialization and fix memcopy of the helper data size. Fixes: 157ffffeb5dc ("netfilter: nfnetlink_cthelper: reject too large userspace allocation requests") Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 7140b62802301cee48838cc90f87f18723b63b42 Author: Pablo Neira Ayuso Date: Sun May 24 19:52:10 2020 +0200 netfilter: conntrack: make conntrack userspace helpers work again commit ee04805ff54a63ffd90bc6749ebfe73473734ddb upstream. Florian Westphal says: "Problem is that after the helper hook was merged back into the confirm one, the queueing itself occurs from the confirm hook, i.e. we queue from the last netfilter callback in the hook-list. Therefore, on return, the packet bypasses the confirm action and the connection is never committed to the main conntrack table. To fix this there are several ways: 1. revert the 'Fixes' commit and have a extra helper hook again. Works, but has the drawback of adding another indirect call for everyone. 2. Special case this: split the hooks only when userspace helper gets added, so queueing occurs at a lower priority again, and normal enqueue reinject would eventually call the last hook. 3. Extend the existing nf_queue ct update hook to allow a forced confirmation (plus run the seqadj code). This goes for 3)." Fixes: 827318feb69cb ("netfilter: conntrack: remove helper hook again") Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 17021d1b899d4ccc76a09e1867707b653e04a207 Author: Phil Sutter Date: Thu May 14 13:31:21 2020 +0200 netfilter: ipset: Fix subcounter update skip commit a164b95ad6055c50612795882f35e0efda1f1390 upstream. If IPSET_FLAG_SKIP_SUBCOUNTER_UPDATE is set, user requested to not update counters in sub sets. Therefore IPSET_FLAG_SKIP_COUNTER_UPDATE must be set, not unset. Fixes: 6e01781d1c80e ("netfilter: ipset: set match: add support to match the counters") Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 25f629a70680a2dc32fafc6bd38bbb2eb048e2bd Author: Michael Braun Date: Wed May 6 11:46:25 2020 +0200 netfilter: nft_reject_bridge: enable reject with bridge vlan commit e9c284ec4b41c827f4369973d2792992849e4fa5 upstream. Currently, using the bridge reject target with tagged packets results in untagged packets being sent back. Fix this by mirroring the vlan id as well. Fixes: 85f5b3086a04 ("netfilter: bridge: add reject support") Signed-off-by: Michael Braun Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 26e28c10e72c1ecab8b3782dcdfdcc4c40dac84f Author: Xin Long Date: Tue Apr 21 20:46:11 2020 +0800 ip_vti: receive ipip packet by calling ip_tunnel_rcv commit 976eba8ab596bab94b9714cd46d38d5c6a2c660d upstream. In Commit dd9ee3444014 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel"), it tries to receive IPIP packets in vti by calling xfrm_input(). This case happens when a small packet or frag sent by peer is too small to get compressed. However, xfrm_input() will still get to the IPCOMP path where skb sec_path is set, but never dropped while it should have been done in vti_ipcomp4_protocol.cb_handler(vti_rcv_cb), as it's not an ipcomp4 packet. This will cause that the packet can never pass xfrm4_policy_check() in the upper protocol rcv functions. So this patch is to call ip_tunnel_rcv() to process IPIP packets instead. Fixes: dd9ee3444014 ("vti4: Fix a ipip packet processing bug in 'IPCOMP' virtual tunnel") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 0de9bed087a2f2da16f8550ec6b673b50730a948 Author: Antony Antony Date: Wed Apr 15 21:47:10 2020 +0200 xfrm: fix error in comment commit 29e4276667e24ee6b91d9f91064d8fda9a210ea1 upstream. s/xfrm_state_offload/xfrm_user_offload/ Fixes: d77e38e612a ("xfrm: Add an IPsec hardware offloading API") Signed-off-by: Antony Antony Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit f5dc87e0e3897e2a3608d31bca09a548c242d3af Author: Xin Long Date: Tue May 26 17:41:46 2020 +0800 xfrm: fix a NULL-ptr deref in xfrm_local_error commit f6a23d85d078c2ffde79c66ca81d0a1dde451649 upstream. This patch is to fix a crash: [ ] kasan: GPF could be caused by NULL-ptr deref or user memory access [ ] general protection fault: 0000 [#1] SMP KASAN PTI [ ] RIP: 0010:ipv6_local_error+0xac/0x7a0 [ ] Call Trace: [ ] xfrm6_local_error+0x1eb/0x300 [ ] xfrm_local_error+0x95/0x130 [ ] __xfrm6_output+0x65f/0xb50 [ ] xfrm6_output+0x106/0x46f [ ] udp_tunnel6_xmit_skb+0x618/0xbf0 [ip6_udp_tunnel] [ ] vxlan_xmit_one+0xbc6/0x2c60 [vxlan] [ ] vxlan_xmit+0x6a0/0x4276 [vxlan] [ ] dev_hard_start_xmit+0x165/0x820 [ ] __dev_queue_xmit+0x1ff0/0x2b90 [ ] ip_finish_output2+0xd3e/0x1480 [ ] ip_do_fragment+0x182d/0x2210 [ ] ip_output+0x1d0/0x510 [ ] ip_send_skb+0x37/0xa0 [ ] raw_sendmsg+0x1b4c/0x2b80 [ ] sock_sendmsg+0xc0/0x110 This occurred when sending a v4 skb over vxlan6 over ipsec, in which case skb->protocol == htons(ETH_P_IPV6) while skb->sk->sk_family == AF_INET in xfrm_local_error(). Then it will go to xfrm6_local_error() where it tries to get ipv6 info from a ipv4 sk. This issue was actually fixed by Commit 628e341f319f ("xfrm: make local error reporting more robust"), but brought back by Commit 844d48746e4b ("xfrm: choose protocol family by skb protocol"). So to fix it, we should call xfrm6_local_error() only when skb->protocol is htons(ETH_P_IPV6) and skb->sk->sk_family is AF_INET6. Fixes: 844d48746e4b ("xfrm: choose protocol family by skb protocol") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 25613580a5bc26a583c23646453468b9af60571e Author: Xin Long Date: Mon May 25 13:53:37 2020 +0800 xfrm: fix a warning in xfrm_policy_insert_list commit ed17b8d377eaf6b4a01d46942b4c647378a79bdd upstream. This waring can be triggered simply by: # ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \ priority 1 mark 0 mask 0x10 #[1] # ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \ priority 2 mark 0 mask 0x1 #[2] # ip xfrm policy update src 192.168.1.1/24 dst 192.168.1.2/24 dir in \ priority 2 mark 0 mask 0x10 #[3] Then dmesg shows: [ ] WARNING: CPU: 1 PID: 7265 at net/xfrm/xfrm_policy.c:1548 [ ] RIP: 0010:xfrm_policy_insert_list+0x2f2/0x1030 [ ] Call Trace: [ ] xfrm_policy_inexact_insert+0x85/0xe50 [ ] xfrm_policy_insert+0x4ba/0x680 [ ] xfrm_add_policy+0x246/0x4d0 [ ] xfrm_user_rcv_msg+0x331/0x5c0 [ ] netlink_rcv_skb+0x121/0x350 [ ] xfrm_netlink_rcv+0x66/0x80 [ ] netlink_unicast+0x439/0x630 [ ] netlink_sendmsg+0x714/0xbf0 [ ] sock_sendmsg+0xe2/0x110 The issue was introduced by Commit 7cb8a93968e3 ("xfrm: Allow inserting policies with matching mark and different priorities"). After that, the policies [1] and [2] would be able to be added with different priorities. However, policy [3] will actually match both [1] and [2]. Policy [1] was matched due to the 1st 'return true' in xfrm_policy_mark_match(), and policy [2] was matched due to the 2nd 'return true' in there. It caused WARN_ON() in xfrm_policy_insert_list(). This patch is to fix it by only (the same value and priority) as the same policy in xfrm_policy_mark_match(). Thanks to Yuehaibing, we could make this fix better. v1->v2: - check policy->mark.v == pol->mark.v only without mask. Fixes: 7cb8a93968e3 ("xfrm: Allow inserting policies with matching mark and different priorities") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit d9710d69b89f588f0231eb3277618590651a085a Author: Nicolas Dichtel Date: Thu Apr 23 00:06:45 2020 +0200 xfrm interface: fix oops when deleting a x-netns interface commit c95c5f58b35ef995f66cb55547eee6093ab5fcb8 upstream. Here is the steps to reproduce the problem: ip netns add foo ip netns add bar ip -n foo link add xfrmi0 type xfrm dev lo if_id 42 ip -n foo link set xfrmi0 netns bar ip netns del foo ip netns del bar Which results to: [ 186.686395] general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bd3: 0000 [#1] SMP PTI [ 186.687665] CPU: 7 PID: 232 Comm: kworker/u16:2 Not tainted 5.6.0+ #1 [ 186.688430] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 186.689420] Workqueue: netns cleanup_net [ 186.689903] RIP: 0010:xfrmi_dev_uninit+0x1b/0x4b [xfrm_interface] [ 186.690657] Code: 44 f6 ff ff 31 c0 5b 5d 41 5c 41 5d 41 5e c3 48 8d 8f c0 08 00 00 8b 05 ce 14 00 00 48 8b 97 d0 08 00 00 48 8b 92 c0 0e 00 00 <48> 8b 14 c2 48 8b 02 48 85 c0 74 19 48 39 c1 75 0c 48 8b 87 c0 08 [ 186.692838] RSP: 0018:ffffc900003b7d68 EFLAGS: 00010286 [ 186.693435] RAX: 000000000000000d RBX: ffff8881b0f31000 RCX: ffff8881b0f318c0 [ 186.694334] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000246 RDI: ffff8881b0f31000 [ 186.695190] RBP: ffffc900003b7df0 R08: ffff888236c07740 R09: 0000000000000040 [ 186.696024] R10: ffffffff81fce1b8 R11: 0000000000000002 R12: ffffc900003b7d80 [ 186.696859] R13: ffff8881edcc6a40 R14: ffff8881a1b6e780 R15: ffffffff81ed47c8 [ 186.697738] FS: 0000000000000000(0000) GS:ffff888237dc0000(0000) knlGS:0000000000000000 [ 186.698705] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 186.699408] CR2: 00007f2129e93148 CR3: 0000000001e0a000 CR4: 00000000000006e0 [ 186.700221] Call Trace: [ 186.700508] rollback_registered_many+0x32b/0x3fd [ 186.701058] ? __rtnl_unlock+0x20/0x3d [ 186.701494] ? arch_local_irq_save+0x11/0x17 [ 186.702012] unregister_netdevice_many+0x12/0x55 [ 186.702594] default_device_exit_batch+0x12b/0x150 [ 186.703160] ? prepare_to_wait_exclusive+0x60/0x60 [ 186.703719] cleanup_net+0x17d/0x234 [ 186.704138] process_one_work+0x196/0x2e8 [ 186.704652] worker_thread+0x1a4/0x249 [ 186.705087] ? cancel_delayed_work+0x92/0x92 [ 186.705620] kthread+0x105/0x10f [ 186.706000] ? __kthread_bind_mask+0x57/0x57 [ 186.706501] ret_from_fork+0x35/0x40 [ 186.706978] Modules linked in: xfrm_interface nfsv3 nfs_acl auth_rpcgss nfsv4 nfs lockd grace fscache sunrpc button parport_pc parport serio_raw evdev pcspkr loop ext4 crc16 mbcache jbd2 crc32c_generic 8139too ide_cd_mod cdrom ide_gd_mod ata_generic ata_piix libata scsi_mod piix psmouse i2c_piix4 ide_core 8139cp i2c_core mii floppy [ 186.710423] ---[ end trace 463bba18105537e5 ]--- The problem is that x-netns xfrm interface are not removed when the link netns is removed. This causes later this oops when thoses interfaces are removed. Let's add a handler to remove all interfaces related to a netns when this netns is removed. Fixes: f203b76d7809 ("xfrm: Add virtual xfrm interfaces") Reported-by: Christophe Gouault Signed-off-by: Nicolas Dichtel Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit de4a187389fa725a733cda908dfcb360b8d35004 Author: Xin Long Date: Mon Apr 20 21:51:09 2020 +0800 xfrm: call xfrm_output_gso when inner_protocol is set in xfrm_output commit a204aef9fd77dce1efd9066ca4e44eede99cd858 upstream. An use-after-free crash can be triggered when sending big packets over vxlan over esp with esp offload enabled: [] BUG: KASAN: use-after-free in ipv6_gso_pull_exthdrs.part.8+0x32c/0x4e0 [] Call Trace: [] dump_stack+0x75/0xa0 [] kasan_report+0x37/0x50 [] ipv6_gso_pull_exthdrs.part.8+0x32c/0x4e0 [] ipv6_gso_segment+0x2c8/0x13c0 [] skb_mac_gso_segment+0x1cb/0x420 [] skb_udp_tunnel_segment+0x6b5/0x1c90 [] inet_gso_segment+0x440/0x1380 [] skb_mac_gso_segment+0x1cb/0x420 [] esp4_gso_segment+0xae8/0x1709 [esp4_offload] [] inet_gso_segment+0x440/0x1380 [] skb_mac_gso_segment+0x1cb/0x420 [] __skb_gso_segment+0x2d7/0x5f0 [] validate_xmit_skb+0x527/0xb10 [] __dev_queue_xmit+0x10f8/0x2320 <--- [] ip_finish_output2+0xa2e/0x1b50 [] ip_output+0x1a8/0x2f0 [] xfrm_output_resume+0x110e/0x15f0 [] __xfrm4_output+0xe1/0x1b0 [] xfrm4_output+0xa0/0x200 [] iptunnel_xmit+0x5a7/0x920 [] vxlan_xmit_one+0x1658/0x37a0 [vxlan] [] vxlan_xmit+0x5e4/0x3ec8 [vxlan] [] dev_hard_start_xmit+0x125/0x540 [] __dev_queue_xmit+0x17bd/0x2320 <--- [] ip6_finish_output2+0xb20/0x1b80 [] ip6_output+0x1b3/0x390 [] ip6_xmit+0xb82/0x17e0 [] inet6_csk_xmit+0x225/0x3d0 [] __tcp_transmit_skb+0x1763/0x3520 [] tcp_write_xmit+0xd64/0x5fe0 [] __tcp_push_pending_frames+0x8c/0x320 [] tcp_sendmsg_locked+0x2245/0x3500 [] tcp_sendmsg+0x27/0x40 As on the tx path of vxlan over esp, skb->inner_network_header would be set on vxlan_xmit() and xfrm4_tunnel_encap_add(), and the later one can overwrite the former one. It causes skb_udp_tunnel_segment() to use a wrong skb->inner_network_header, then the issue occurs. This patch is to fix it by calling xfrm_output_gso() instead when the inner_protocol is set, in which gso_segment of inner_protocol will be done first. While at it, also improve some code around. Fixes: 7862b4058b9f ("esp: Add gso handlers for esp4 and esp6") Reported-by: Xiumei Mu Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit edd79cf0cfdf0937674f8fcabb97bce64228784b Author: Xin Long Date: Fri Apr 10 17:08:24 2020 +0800 xfrm: remove the xfrm_state_put call becofe going to out_reset commit db87668ad1e4917cfe04e217307ba6ed9390716e upstream. This xfrm_state_put call in esp4/6_gro_receive() will cause double put for state, as in out_reset path secpath_reset() will put all states set in skb sec_path. So fix it by simply remove the xfrm_state_put call. Fixes: 6ed69184ed9c ("xfrm: Reset secpath in xfrm failure") Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit cd7031ef96833426c9c64dbca0fdbb66dc734d03 Author: Xin Long Date: Fri Apr 10 17:06:31 2020 +0800 xfrm: do pskb_pull properly in __xfrm_transport_prep commit 06a0afcfe2f551ff755849ea2549b0d8409fd9a0 upstream. For transport mode, when ipv6 nexthdr is set, the packet format might be like: ---------------------------------------------------- | | dest | | | | ESP | ESP | | IP6 hdr| opts.| ESP | TCP | Data | Trailer | ICV | ---------------------------------------------------- and in __xfrm_transport_prep(): pskb_pull(skb, skb->mac_len + sizeof(ip6hdr) + x->props.header_len); it will pull the data pointer to the wrong position, as it missed the nexthdrs/dest opts. This patch is to fix it by using: pskb_pull(skb, skb_transport_offset(skb) + x->props.header_len); as we can be sure transport_header points to ESP header at that moment. It also fixes a panic when packets with ipv6 nexthdr are sent over esp6 transport mode: [ 100.473845] kernel BUG at net/core/skbuff.c:4325! [ 100.478517] RIP: 0010:__skb_to_sgvec+0x252/0x260 [ 100.494355] Call Trace: [ 100.494829] skb_to_sgvec+0x11/0x40 [ 100.495492] esp6_output_tail+0x12e/0x550 [esp6] [ 100.496358] esp6_xmit+0x1d5/0x260 [esp6_offload] [ 100.498029] validate_xmit_xfrm+0x22f/0x2e0 [ 100.499604] __dev_queue_xmit+0x589/0x910 [ 100.502928] ip6_finish_output2+0x2a5/0x5a0 [ 100.503718] ip6_output+0x6c/0x120 [ 100.505198] xfrm_output_resume+0x4bf/0x530 [ 100.508683] xfrm6_output+0x3a/0xc0 [ 100.513446] inet6_csk_xmit+0xa1/0xf0 [ 100.517335] tcp_sendmsg+0x27/0x40 [ 100.517977] sock_sendmsg+0x3e/0x60 [ 100.518648] __sys_sendto+0xee/0x160 Fixes: c35fe4106b92 ("xfrm: Add mode handlers for IPsec on layer 2") Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 14a1c1dc56954fad21b57a52ba8fef6b28050524 Author: Xin Long Date: Fri Apr 10 17:06:01 2020 +0800 xfrm: allow to accept packets with ipv6 NEXTHDR_HOP in xfrm_input commit afcaf61be9d1dbdee5ec186d1dcc67b6b692180f upstream. For beet mode, when it's ipv6 inner address with nexthdrs set, the packet format might be: ---------------------------------------------------- | outer | | dest | | | ESP | ESP | | IP hdr | ESP | opts.| TCP | Data | Trailer | ICV | ---------------------------------------------------- The nexthdr from ESP could be NEXTHDR_HOP(0), so it should continue processing the packet when nexthdr returns 0 in xfrm_input(). Otherwise, when ipv6 nexthdr is set, the packet will be dropped. I don't see any error cases that nexthdr may return 0. So fix it by removing the check for nexthdr == 0. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Signed-off-by: Steffen Klassert Signed-off-by: Greg Kroah-Hartman commit 47dc81ce7d841b03f28e092df25082e244d11005 Author: Al Viro Date: Tue May 26 18:39:49 2020 -0400 copy_xstate_to_kernel(): don't leave parts of destination uninitialized commit 9e4636545933131de15e1ecd06733538ae939b2f upstream. copy the corresponding pieces of init_fpstate into the gaps instead. Cc: stable@kernel.org Tested-by: Alexander Potapenko Acked-by: Borislav Petkov Signed-off-by: Al Viro Signed-off-by: Greg Kroah-Hartman commit 94690ca1ae4ce8caeb3ffc1794202e8ab489977f Author: Alexander Dahl Date: Tue May 26 19:57:49 2020 +0200 x86/dma: Fix max PFN arithmetic overflow on 32 bit systems commit 88743470668ef5eb6b7ba9e0f99888e5999bf172 upstream. The intermediate result of the old term (4UL * 1024 * 1024 * 1024) is 4 294 967 296 or 0x100000000 which is no problem on 64 bit systems. The patch does not change the later overall result of 0x100000 for MAX_DMA32_PFN (after it has been shifted by PAGE_SHIFT). The new calculation yields the same result, but does not require 64 bit arithmetic. On 32 bit systems the old calculation suffers from an arithmetic overflow in that intermediate term in braces: 4UL aka unsigned long int is 4 byte wide and an arithmetic overflow happens (the 0x100000000 does not fit in 4 bytes), the in braces result is truncated to zero, the following right shift does not alter that, so MAX_DMA32_PFN evaluates to 0 on 32 bit systems. That wrong value is a problem in a comparision against MAX_DMA32_PFN in the init code for swiotlb in pci_swiotlb_detect_4gb() to decide if swiotlb should be active. That comparison yields the opposite result, when compiling on 32 bit systems. This was not possible before 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") when that MAX_DMA32_PFN was first made visible to x86_32 (and which landed in v3.0). In practice this wasn't a problem, unless CONFIG_SWIOTLB is active on x86-32. However if one has set CONFIG_IOMMU_INTEL, since c5a5dc4cbbf4 ("iommu/vt-d: Don't switch off swiotlb if bounce page is used") there's a dependency on CONFIG_SWIOTLB, which was not necessarily active before. That landed in v5.4, where we noticed it in the fli4l Linux distribution. We have CONFIG_IOMMU_INTEL active on both 32 and 64 bit kernel configs there (I could not find out why, so let's just say historical reasons). The effect is at boot time 64 MiB (default size) were allocated for bounce buffers now, which is a noticeable amount of memory on small systems like pcengines ALIX 2D3 with 256 MiB memory, which are still frequently used as home routers. We noticed this effect when migrating from kernel v4.19 (LTS) to v5.4 (LTS) in fli4l and got that kernel messages for example: Linux version 5.4.22 (buildroot@buildroot) (gcc version 7.3.0 (Buildroot 2018.02.8)) #1 SMP Mon Nov 26 23:40:00 CET 2018 … Memory: 183484K/261756K available (4594K kernel code, 393K rwdata, 1660K rodata, 536K init, 456K bss , 78272K reserved, 0K cma-reserved, 0K highmem) … PCI-DMA: Using software bounce buffering for IO (SWIOTLB) software IO TLB: mapped [mem 0x0bb78000-0x0fb78000] (64MB) The initial analysis and the suggested fix was done by user 'sourcejedi' at stackoverflow and explicitly marked as GPLv2 for inclusion in the Linux kernel: https://unix.stackexchange.com/a/520525/50007 The new calculation, which does not suffer from that overflow, is the same as for arch/mips now as suggested by Robin Murphy. The fix was tested by fli4l users on round about two dozen different systems, including both 32 and 64 bit archs, bare metal and virtualized machines. [ bp: Massage commit message. ] Fixes: 1b7e03ef7570 ("x86, NUMA: Enable emulation on 32bit too") Reported-by: Alan Jenkins Suggested-by: Robin Murphy Signed-off-by: Alexander Dahl Signed-off-by: Borislav Petkov Reviewed-by: Greg Kroah-Hartman Cc: stable@vger.kernel.org Link: https://unix.stackexchange.com/q/520065/50007 Link: https://web.nettworks.org/bugs/browse/FFL-2560 Link: https://lkml.kernel.org/r/20200526175749.20742-1-post@lespocky.de Signed-off-by: Greg Kroah-Hartman commit e980f9cb2f2d51014689e85ae6169bf862b5661d Author: Linus Lüssing Date: Fri May 22 19:04:13 2020 +0200 mac80211: mesh: fix discovery timer re-arming issue / crash commit e2d4a80f93fcfaf72e2e20daf6a28e39c3b90677 upstream. On a non-forwarding 802.11s link between two fairly busy neighboring nodes (iperf with -P 16 at ~850MBit/s TCP; 1733.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 4), so with frequent PREQ retries, usually after around 30-40 seconds the following crash would occur: [ 1110.822428] Unable to handle kernel read from unreadable memory at virtual address 00000000 [ 1110.830786] Mem abort info: [ 1110.833573] Exception class = IABT (current EL), IL = 32 bits [ 1110.839494] SET = 0, FnV = 0 [ 1110.842546] EA = 0, S1PTW = 0 [ 1110.845678] user pgtable: 4k pages, 48-bit VAs, pgd = ffff800076386000 [ 1110.852204] [0000000000000000] *pgd=00000000f6322003, *pud=00000000f62de003, *pmd=0000000000000000 [ 1110.861167] Internal error: Oops: 86000004 [#1] PREEMPT SMP [ 1110.866730] Modules linked in: pppoe ppp_async batman_adv ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 usb_storage xhci_plat_hcd xhci_pci xhci_hcd dwc3 usbcore usb_common [ 1110.932190] Process swapper/3 (pid: 0, stack limit = 0xffff0000090c8000) [ 1110.938884] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.14.162 #0 [ 1110.944965] Hardware name: LS1043A RGW Board (DT) [ 1110.949658] task: ffff8000787a81c0 task.stack: ffff0000090c8000 [ 1110.955568] PC is at 0x0 [ 1110.958097] LR is at call_timer_fn.isra.27+0x24/0x78 [ 1110.963055] pc : [<0000000000000000>] lr : [] pstate: 00400145 [ 1110.970440] sp : ffff00000801be10 [ 1110.973744] x29: ffff00000801be10 x28: ffff000008bf7018 [ 1110.979047] x27: ffff000008bf87c8 x26: ffff000008c160c0 [ 1110.984352] x25: 0000000000000000 x24: 0000000000000000 [ 1110.989657] x23: dead000000000200 x22: 0000000000000000 [ 1110.994959] x21: 0000000000000000 x20: 0000000000000101 [ 1111.000262] x19: ffff8000787a81c0 x18: 0000000000000000 [ 1111.005565] x17: ffff0000089167b0 x16: 0000000000000058 [ 1111.010868] x15: ffff0000089167b0 x14: 0000000000000000 [ 1111.016172] x13: ffff000008916788 x12: 0000000000000040 [ 1111.021475] x11: ffff80007fda9af0 x10: 0000000000000001 [ 1111.026777] x9 : ffff00000801bea0 x8 : 0000000000000004 [ 1111.032080] x7 : 0000000000000000 x6 : ffff80007fda9aa8 [ 1111.037383] x5 : ffff00000801bea0 x4 : 0000000000000010 [ 1111.042685] x3 : ffff00000801be98 x2 : 0000000000000614 [ 1111.047988] x1 : 0000000000000000 x0 : 0000000000000000 [ 1111.053290] Call trace: [ 1111.055728] Exception stack(0xffff00000801bcd0 to 0xffff00000801be10) [ 1111.062158] bcc0: 0000000000000000 0000000000000000 [ 1111.069978] bce0: 0000000000000614 ffff00000801be98 0000000000000010 ffff00000801bea0 [ 1111.077798] bd00: ffff80007fda9aa8 0000000000000000 0000000000000004 ffff00000801bea0 [ 1111.085618] bd20: 0000000000000001 ffff80007fda9af0 0000000000000040 ffff000008916788 [ 1111.093437] bd40: 0000000000000000 ffff0000089167b0 0000000000000058 ffff0000089167b0 [ 1111.101256] bd60: 0000000000000000 ffff8000787a81c0 0000000000000101 0000000000000000 [ 1111.109075] bd80: 0000000000000000 dead000000000200 0000000000000000 0000000000000000 [ 1111.116895] bda0: ffff000008c160c0 ffff000008bf87c8 ffff000008bf7018 ffff00000801be10 [ 1111.124715] bdc0: ffff0000080ff29c ffff00000801be10 0000000000000000 0000000000400145 [ 1111.132534] bde0: ffff8000787a81c0 ffff00000801bde8 0000ffffffffffff 000001029eb19be8 [ 1111.140353] be00: ffff00000801be10 0000000000000000 [ 1111.145220] [< (null)>] (null) [ 1111.149917] [] run_timer_softirq+0x184/0x398 [ 1111.155741] [] __do_softirq+0x100/0x1fc [ 1111.161130] [] irq_exit+0x80/0xd8 [ 1111.166002] [] __handle_domain_irq+0x88/0xb0 [ 1111.171825] [] gic_handle_irq+0x68/0xb0 [ 1111.177213] Exception stack(0xffff0000090cbe30 to 0xffff0000090cbf70) [ 1111.183642] be20: 0000000000000020 0000000000000000 [ 1111.191461] be40: 0000000000000001 0000000000000000 00008000771af000 0000000000000000 [ 1111.199281] be60: ffff000008c95180 0000000000000000 ffff000008c19360 ffff0000090cbef0 [ 1111.207101] be80: 0000000000000810 0000000000000400 0000000000000098 ffff000000000000 [ 1111.214920] bea0: 0000000000000001 ffff0000089167b0 0000000000000000 ffff0000089167b0 [ 1111.222740] bec0: 0000000000000000 ffff000008c198e8 ffff000008bf7018 ffff000008c19000 [ 1111.230559] bee0: 0000000000000000 0000000000000000 ffff8000787a81c0 ffff000008018000 [ 1111.238380] bf00: ffff00000801c000 ffff00000913ba34 ffff8000787a81c0 ffff0000090cbf70 [ 1111.246199] bf20: ffff0000080857cc ffff0000090cbf70 ffff0000080857d0 0000000000400145 [ 1111.254020] bf40: ffff000008018000 ffff00000801c000 ffffffffffffffff ffff0000080fa574 [ 1111.261838] bf60: ffff0000090cbf70 ffff0000080857d0 [ 1111.266706] [] el1_irq+0xe8/0x18c [ 1111.271576] [] arch_cpu_idle+0x10/0x18 [ 1111.276880] [] do_idle+0xec/0x1b8 [ 1111.281748] [] cpu_startup_entry+0x20/0x28 [ 1111.287399] [] secondary_start_kernel+0x104/0x110 [ 1111.293662] Code: bad PC value [ 1111.296710] ---[ end trace 555b6ca4363c3edd ]--- [ 1111.301318] Kernel panic - not syncing: Fatal exception in interrupt [ 1111.307661] SMP: stopping secondary CPUs [ 1111.311574] Kernel Offset: disabled [ 1111.315053] CPU features: 0x0002000 [ 1111.318530] Memory Limit: none [ 1111.321575] Rebooting in 3 seconds.. With some added debug output / delays we were able to push the crash from the timer callback runner into the callback function and by that shedding some light on which object holding the timer gets corrupted: [ 401.720899] Unable to handle kernel read from unreadable memory at virtual address 00000868 [...] [ 402.335836] [] _raw_spin_lock_bh+0x14/0x48 [ 402.341548] [] mesh_path_timer+0x10c/0x248 [mac80211] [ 402.348154] [] call_timer_fn.isra.27+0x24/0x78 [ 402.354150] [] run_timer_softirq+0x184/0x398 [ 402.359974] [] __do_softirq+0x100/0x1fc [ 402.365362] [] irq_exit+0x80/0xd8 [ 402.370231] [] __handle_domain_irq+0x88/0xb0 [ 402.376053] [] gic_handle_irq+0x68/0xb0 The issue happens due to the following sequence of events: 1) mesh_path_start_discovery(): -> spin_unlock_bh(&mpath->state_lock) before mesh_path_sel_frame_tx() 2) mesh_path_free_rcu() -> del_timer_sync(&mpath->timer) [...] -> kfree_rcu(mpath) 3) mesh_path_start_discovery(): -> mod_timer(&mpath->timer, ...) [...] -> rcu_read_unlock() 4) mesh_path_free_rcu()'s kfree_rcu(): -> kfree(mpath) 5) mesh_path_timer() starts after timeout, using freed mpath object So a use-after-free issue due to a timer re-arming bug caused by an early spin-unlocking. This patch fixes this issue by re-checking if mpath is about to be free'd and if so bails out of re-arming the timer. Cc: stable@vger.kernel.org Fixes: 050ac52cbe1f ("mac80211: code for on-demand Hybrid Wireless Mesh Protocol") Cc: Simon Wunderlich Signed-off-by: Linus Lüssing Link: https://lore.kernel.org/r/20200522170413.14973-1-linus.luessing@c0d3.blue Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 2f0851690a0e8e971536be50abc828f9602ae2c8 Author: Andy Lutomirski Date: Fri May 8 17:25:32 2020 -0700 x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long" commit 700d3a5a664df267f01ec8887fd2d8ff98f67e7f upstream. Revert 45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long") and add a comment to discourage someone else from making the same mistake again. It turns out that some user code fails to compile if __X32_SYSCALL_BIT is unsigned long. See, for example [1] below. [ bp: Massage and do the same thing in the respective tools/ header. ] Fixes: 45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long") Reported-by: Thorsten Glaser Signed-off-by: Andy Lutomirski Signed-off-by: Borislav Petkov Cc: stable@kernel.org Link: [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294 Link: https://lkml.kernel.org/r/92e55442b744a5951fdc9cfee10badd0a5f7f828.1588983892.git.luto@kernel.org Signed-off-by: Greg Kroah-Hartman commit 8c1bfa73353ad710195a94fab879a788feb429d1 Author: Johannes Berg Date: Mon May 25 11:38:17 2020 +0200 cfg80211: fix debugfs rename crash commit 0bbab5f0301587cad4e923ccc49bb910db86162c upstream. Removing the "if (IS_ERR(dir)) dir = NULL;" check only works if we adjust the remaining code to not rely on it being NULL. Check IS_ERR_OR_NULL() before attempting to dereference it. I'm not actually entirely sure this fixes the syzbot crash as the kernel config indicates that they do have DEBUG_FS in the kernel, but this is what I found when looking there. Cc: stable@vger.kernel.org Fixes: d82574a8e5a4 ("cfg80211: no need to check return value of debugfs_create functions") Reported-by: syzbot+fd5332e429401bf42d18@syzkaller.appspotmail.com Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200525113816.fc4da3ec3d4b.Ica63a110679819eaa9fb3bc1b7437d96b1fd187d@changeid Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit f9cd0c831806475705be4ea822eb772eb559b8f5 Author: Helge Deller Date: Thu May 28 22:29:25 2020 +0200 parisc: Fix kernel panic in mem_init() [ Upstream commit bf71bc16e02162388808949b179d59d0b571b965 ] The Debian kernel v5.6 triggers this kernel panic: Kernel panic - not syncing: Bad Address (null pointer deref?) Bad Address (null pointer deref?): Code=26 (Data memory access rights trap) at addr 0000000000000000 CPU: 0 PID: 0 Comm: swapper Not tainted 5.6.0-2-parisc64 #1 Debian 5.6.14-1 IAOQ[0]: mem_init+0xb0/0x150 IAOQ[1]: mem_init+0xb4/0x150 RP(r2): start_kernel+0x6c8/0x1190 Backtrace: [<0000000040101ab4>] start_kernel+0x6c8/0x1190 [<0000000040108574>] start_parisc+0x158/0x1b8 on a HP-PARISC rp3440 machine with this memory layout: Memory Ranges: 0) Start 0x0000000000000000 End 0x000000003fffffff Size 1024 MB 1) Start 0x0000004040000000 End 0x00000040ffdfffff Size 3070 MB Fix the crash by avoiding virt_to_page() and similar functions in mem_init() until the memory zones have been fully set up. Signed-off-by: Helge Deller Cc: stable@vger.kernel.org # v5.0+ Signed-off-by: Sasha Levin commit ca788fd797a7f28a83cb1c1047ff31fda7665a56 Author: Qiushi Wu Date: Wed May 27 16:00:19 2020 -0500 iommu: Fix reference count leak in iommu_group_alloc. [ Upstream commit 7cc31613734c4870ae32f5265d576ef296621343 ] kobject_init_and_add() takes reference even when it fails. Thus, when kobject_init_and_add() returns an error, kobject_put() must be called to properly clean up the kobject. Fixes: d72e31c93746 ("iommu: IOMMU Groups") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200527210020.6522-1-wu000273@umn.edu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit b298c314b9d9064f4090af7c10447d15a32fce6c Author: Linus Walleij Date: Wed May 27 16:07:58 2020 +0200 gpio: fix locking open drain IRQ lines [ Upstream commit e9bdf7e655b9ee81ee912fae1d59df48ce7311b6 ] We provided the right semantics on open drain lines being by definition output but incidentally the irq set up function would only allow IRQs on lines that were "not output". Fix the semantics to allow output open drain lines to be used for IRQs. Reported-by: Hans Verkuil Signed-off-by: Linus Walleij Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Cc: Russell King Cc: stable@vger.kernel.org # v5.3+ Link: https://lore.kernel.org/r/20200527140758.162280-1-linus.walleij@linaro.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit bba91cdba612fbce4f8575c5d94d2b146fb83ea3 Author: Jens Axboe Date: Thu May 28 13:19:29 2020 -0600 Revert "block: end bio with BLK_STS_AGAIN in case of non-mq devs and REQ_NOWAIT" [ Upstream commit b0beb28097fa04177b3769f4bb7a0d0d9c4ae76e ] This reverts commit c58c1f83436b501d45d4050fd1296d71a9760bcb. io_uring does do the right thing for this case, and we're still returning -EAGAIN to userspace for the cases we don't support. Revert this change to avoid doing endless spins of resubmits. Cc: stable@vger.kernel.org # v5.6 Reported-by: Bijan Mottahedeh Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 31f0b78bb4781a75f73aa462e4731a9b0eb102a6 Author: Arnd Bergmann Date: Wed May 27 22:20:55 2020 -0700 include/asm-generic/topology.h: guard cpumask_of_node() macro argument [ Upstream commit 4377748c7b5187c3342a60fa2ceb60c8a57a8488 ] drivers/hwmon/amd_energy.c:195:15: error: invalid operands to binary expression ('void' and 'int') (channel - data->nr_cpus)); ~~~~~~~~~^~~~~~~~~~~~~~~~~ include/asm-generic/topology.h:51:42: note: expanded from macro 'cpumask_of_node' #define cpumask_of_node(node) ((void)node, cpu_online_mask) ^~~~ include/linux/cpumask.h:618:72: note: expanded from macro 'cpumask_first_and' #define cpumask_first_and(src1p, src2p) cpumask_next_and(-1, (src1p), (src2p)) ^~~~~ Fixes: f0b848ce6fe9 ("cpumask: Introduce cpumask_of_{node,pcibus} to replace {node,pcibus}_to_cpumask") Fixes: 8abee9566b7e ("hwmon: Add amd_energy driver to report energy counters") Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Acked-by: Guenter Roeck Link: http://lkml.kernel.org/r/20200527134623.930247-1-arnd@arndb.de Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a02c130efbbce91af1e9dd99a5a381dd43494e15 Author: Alexander Potapenko Date: Wed May 27 22:20:52 2020 -0700 fs/binfmt_elf.c: allocate initialized memory in fill_thread_core_info() [ Upstream commit 1d605416fb7175e1adf094251466caa52093b413 ] KMSAN reported uninitialized data being written to disk when dumping core. As a result, several kilobytes of kmalloc memory may be written to the core file and then read by a non-privileged user. Reported-by: sam Signed-off-by: Alexander Potapenko Signed-off-by: Andrew Morton Acked-by: Kees Cook Cc: Al Viro Cc: Alexey Dobriyan Cc: Link: http://lkml.kernel.org/r/20200419100848.63472-1-glider@google.com Link: https://github.com/google/kmsan/issues/76 Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit de482c445b0fa127901f497b4d68f0c9fbf449d5 Author: Konstantin Khlebnikov Date: Wed May 27 22:20:47 2020 -0700 mm: remove VM_BUG_ON(PageSlab()) from page_mapcount() [ Upstream commit 6988f31d558aa8c744464a7f6d91d34ada48ad12 ] Replace superfluous VM_BUG_ON() with comment about correct usage. Technically reverts commit 1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to page_mapcount()"), but context lines have changed. Function isolate_migratepages_block() runs some checks out of lru_lock when choose pages for migration. After checking PageLRU() it checks extra page references by comparing page_count() and page_mapcount(). Between these two checks page could be removed from lru, freed and taken by slab. As a result this race triggers VM_BUG_ON(PageSlab()) in page_mapcount(). Race window is tiny. For certain workload this happens around once a year. page:ffffea0105ca9380 count:1 mapcount:0 mapping:ffff88ff7712c180 index:0x0 compound_mapcount: 0 flags: 0x500000000008100(slab|head) raw: 0500000000008100 dead000000000100 dead000000000200 ffff88ff7712c180 raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(PageSlab(page)) ------------[ cut here ]------------ kernel BUG at ./include/linux/mm.h:628! invalid opcode: 0000 [#1] SMP NOPTI CPU: 77 PID: 504 Comm: kcompactd1 Tainted: G W 4.19.109-27 #1 Hardware name: Yandex T175-N41-Y3N/MY81-EX0-Y3N, BIOS R05 06/20/2019 RIP: 0010:isolate_migratepages_block+0x986/0x9b0 The code in isolate_migratepages_block() was added in commit 119d6d59dcc0 ("mm, compaction: avoid isolating pinned pages") before adding VM_BUG_ON into page_mapcount(). This race has been predicted in 2015 by Vlastimil Babka (see link below). [akpm@linux-foundation.org: comment tweaks, per Hugh] Fixes: 1d148e218a0d ("mm: add VM_BUG_ON_PAGE() to page_mapcount()") Signed-off-by: Konstantin Khlebnikov Signed-off-by: Andrew Morton Acked-by: Hugh Dickins Acked-by: Kirill A. Shutemov Acked-by: Vlastimil Babka Cc: David Rientjes Cc: Link: http://lkml.kernel.org/r/159032779896.957378.7852761411265662220.stgit@buzz Link: https://lore.kernel.org/lkml/557710E1.6060103@suse.cz/ Link: https://lore.kernel.org/linux-mm/158937872515.474360.5066096871639561424.stgit@buzz/T/ (v1) Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit a7ba9f24737b4a994ef1be557aeb6544e415f39d Author: Hugh Dickins Date: Wed May 27 22:20:43 2020 -0700 mm,thp: stop leaking unreleased file pages [ Upstream commit 2f33a706027c94cd4f70fcd3e3f4a17c1ce4ea4b ] When collapse_file() calls try_to_release_page(), it has already isolated the page: so if releasing buffers happens to fail (as it sometimes does), remember to putback_lru_page(): otherwise that page is left unreclaimable and unfreeable, and the file extent uncollapsible. Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non-shmem) FS") Signed-off-by: Hugh Dickins Signed-off-by: Andrew Morton Acked-by: Song Liu Acked-by: Kirill A. Shutemov Acked-by: Johannes Weiner Cc: Rik van Riel Cc: [5.4+] Link: http://lkml.kernel.org/r/alpine.LSU.2.11.2005231837500.1766@eggly.anvils Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 21358b3e77af10df4c7977f3d10d8da6ebbe5396 Author: Valentine Fatiev Date: Wed May 27 16:47:05 2020 +0300 IB/ipoib: Fix double free of skb in case of multicast traffic in CM mode [ Upstream commit 1acba6a817852d4aa7916d5c4f2c82f702ee9224 ] When connected mode is set, and we have connected and datagram traffic in parallel, ipoib might crash with double free of datagram skb. The current mechanism assumes that the order in the completion queue is the same as the order of sent packets for all QPs. Order is kept only for specific QP, in case of mixed UD and CM traffic we have few QPs (one UD and few CM's) in parallel. The problem: ---------------------------------------------------------- Transmit queue: ----------------- UD skb pointer kept in queue itself, CM skb kept in spearate queue and uses transmit queue as a placeholder to count the number of total transmitted packets. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 .........127 ------------------------------------------------------------ NL ud1 UD2 CM1 ud3 cm2 cm3 ud4 cm4 ud5 NL NL NL ........... ------------------------------------------------------------ ^ ^ tail head Completion queue (problematic scenario) - the order not the same as in the transmit queue: 1 2 3 4 5 6 7 8 9 ------------------------------------ ud1 CM1 UD2 ud3 cm2 cm3 ud4 cm4 ud5 ------------------------------------ 1. CM1 'wc' processing - skb freed in cm separate ring. - tx_tail of transmit queue increased although UD2 is not freed. Now driver assumes UD2 index is already freed and it could be used for new transmitted skb. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 .........127 ------------------------------------------------------------ NL NL UD2 CM1 ud3 cm2 cm3 ud4 cm4 ud5 NL NL NL ........... ------------------------------------------------------------ ^ ^ ^ (Bad)tail head (Bad - Could be used for new SKB) In this case (due to heavy load) UD2 skb pointer could be replaced by new transmitted packet UD_NEW, as the driver assumes its free. At this point we will have to process two 'wc' with same index but we have only one pointer to free. During second attempt to free the same skb we will have NULL pointer exception. 2. UD2 'wc' processing - skb freed according the index we got from 'wc', but it was already overwritten by mistake. So actually the skb that was released is the skb of the new transmitted packet and not the original one. 3. UD_NEW 'wc' processing - attempt to free already freed skb. NUll pointer exception. The fix: ----------------------------------------------------------------------- The fix is to stop using the UD ring as a placeholder for CM packets, the cyclic ring variables tx_head and tx_tail will manage the UD tx_ring, a new cyclic variables global_tx_head and global_tx_tail are introduced for managing and counting the overall outstanding sent packets, then the send queue will be stopped and waken based on these variables only. Note that no locking is needed since global_tx_head is updated in the xmit flow and global_tx_tail is updated in the NAPI flow only. A previous attempt tried to use one variable to count the outstanding sent packets, but it did not work since xmit and NAPI flows can run at the same time and the counter will be updated wrongly. Thus, we use the same simple cyclic head and tail scheme that we have today for the UD tx_ring. Fixes: 2c104ea68350 ("IB/ipoib: Get rid of the tx_outstanding variable in all modes") Link: https://lore.kernel.org/r/20200527134705.480068-1-leon@kernel.org Signed-off-by: Valentine Fatiev Signed-off-by: Alaa Hleihel Signed-off-by: Leon Romanovsky Acked-by: Doug Ledford Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 5a1bd1704272358ac416629b8b45a34014bcc472 Author: Simon Ser Date: Sat May 23 11:53:41 2020 +0000 drm/amd/display: drop cursor position check in atomic test [ Upstream commit f7d5991b92ff824798693ddf231cf814c9d5a88b ] get_cursor_position already handles the case where the cursor has negative off-screen coordinates by not setting dc_cursor_position.enabled. Signed-off-by: Simon Ser Fixes: 626bf90fe03f ("drm/amd/display: add basic atomic check for cursor plane") Cc: Alex Deucher Cc: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin commit b5d326a77b7317c731c441fb78292270b98701c9 Author: Jason Gunthorpe Date: Wed May 27 16:55:34 2020 +0300 RDMA/core: Fix double destruction of uobject [ Upstream commit c85f4abe66bea0b5db8d28d55da760c4fe0a0301 ] Fix use after free when user user space request uobject concurrently for the same object, within the RCU grace period. In that case, remove_handle_idr_uobject() is called twice and we will have an extra put on the uobject which cause use after free. Fix it by leaving the uobject write locked after it was removed from the idr. Call to rdma_lookup_put_uobject with UVERBS_LOOKUP_DESTROY instead of UVERBS_LOOKUP_WRITE will do the work. refcount_t: underflow; use-after-free. WARNING: CPU: 0 PID: 1381 at lib/refcount.c:28 refcount_warn_saturate+0xfe/0x1a0 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 1381 Comm: syz-executor.0 Not tainted 5.5.0-rc3 #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack+0x94/0xce panic+0x234/0x56f __warn+0x1cc/0x1e1 report_bug+0x200/0x310 fixup_bug.part.11+0x32/0x80 do_error_trap+0xd3/0x100 do_invalid_op+0x31/0x40 invalid_op+0x1e/0x30 RIP: 0010:refcount_warn_saturate+0xfe/0x1a0 Code: 0f 0b eb 9b e8 23 f6 6d ff 80 3d 6c d4 19 03 00 75 8d e8 15 f6 6d ff 48 c7 c7 c0 02 55 bd c6 05 57 d4 19 03 01 e8 a2 58 49 ff <0f> 0b e9 6e ff ff ff e8 f6 f5 6d ff 80 3d 42 d4 19 03 00 0f 85 5c RSP: 0018:ffffc90002df7b98 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88810f6a193c RCX: ffffffffba649009 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff88811b0283cc RBP: 0000000000000003 R08: ffffed10236060e3 R09: ffffed10236060e3 R10: 0000000000000001 R11: ffffed10236060e2 R12: ffff88810f6a193c R13: ffffc90002df7d60 R14: 0000000000000000 R15: ffff888116ae6a08 uverbs_uobject_put+0xfd/0x140 __uobj_perform_destroy+0x3d/0x60 ib_uverbs_close_xrcd+0x148/0x170 ib_uverbs_write+0xaa5/0xdf0 __vfs_write+0x7c/0x100 vfs_write+0x168/0x4a0 ksys_write+0xc8/0x200 do_syscall_64+0x9c/0x390 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x465b49 Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 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 c7 c1 bc ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f759d122c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000073bfa8 RCX: 0000000000465b49 RDX: 000000000000000c RSI: 0000000020000080 RDI: 0000000000000003 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f759d1236bc R13: 00000000004ca27c R14: 000000000070de40 R15: 00000000ffffffff Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x39400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Fixes: 7452a3c745a2 ("IB/uverbs: Allow RDMA_REMOVE_DESTROY to work concurrently with disassociate") Link: https://lore.kernel.org/r/20200527135534.482279-1-leon@kernel.org Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6b292d7806a19781ea2ece291e92b5ab7b6bb481 Author: Jeff Layton Date: Wed May 20 10:36:07 2020 -0400 ceph: flush release queue when handling caps for unknown inode [ Upstream commit fb33c114d3ed5bdac230716f5b0a93b56b92a90d ] It's possible for the VFS to completely forget about an inode, but for it to still be sitting on the cap release queue. If the MDS sends the client a cap message for such an inode, it just ignores it today, which can lead to a stall of up to 5s until the cap release queue is flushed. If we get a cap message for an inode that can't be located, then go ahead and flush the cap release queue. Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/45532 Fixes: 1e9c2eb6811e ("ceph: delete stale dentry when last reference is dropped") Reported-and-Tested-by: Andrej Filipčič Suggested-by: Yan, Zheng Signed-off-by: Jeff Layton Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit 4d145e482374ada874af1f61592e3b7c201dd0e4 Author: Jerry Lee Date: Mon May 18 16:03:09 2020 +0800 libceph: ignore pool overlay and cache logic on redirects [ Upstream commit 890bd0f8997ae6ac0a367dd5146154a3963306dd ] OSD client should ignore cache/overlay flag if got redirect reply. Otherwise, the client hangs when the cache tier is in forward mode. [ idryomov: Redirects are effectively deprecated and no longer used or tested. The original tiering modes based on redirects are inherently flawed because redirects can race and reorder, potentially resulting in data corruption. The new proxy and readproxy tiering modes should be used instead of forward and readforward. Still marking for stable as obviously correct, though. ] Cc: stable@vger.kernel.org URL: https://tracker.ceph.com/issues/23296 URL: https://tracker.ceph.com/issues/36406 Signed-off-by: Jerry Lee Reviewed-by: Ilya Dryomov Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit d162b9e1b1a9149f4ca219f76d03e6c2dabf94ca Author: Kailang Yang Date: Wed May 27 14:10:26 2020 +0800 ALSA: hda/realtek - Add new codec supported for ALC287 [ Upstream commit 630e36126e420e1756378b3427b42711ce0b9ddd ] Enable new codec supported for ALC287. Signed-off-by: Kailang Yang Cc: Link: https://lore.kernel.org/r/dcf5ce5507104d0589a917cbb71dc3c6@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c33bf209deaefee1ab51989662080e49cd6bc486 Author: Takashi Iwai Date: Tue May 26 10:28:10 2020 +0200 ALSA: usb-audio: Quirks for Gigabyte TRX40 Aorus Master onboard audio [ Upstream commit 7f5ad9c9003425175f46c94df380e8c9e558cfb5 ] Gigabyte TRX40 Aorus Master is equipped with two USB-audio devices, a Realtek ALC1220-VB codec (USB ID 0414:a001) and an ESS SABRE9218 DAC (USB ID 0414:a000). The latter serves solely for the headphone output on the front panel while the former serves for the rest I/Os (mostly for the I/Os in the rear panel but also including the front mic). Both chips do work more or less with the unmodified USB-audio driver, but there are a few glitches. The ALC1220-VB returns an error for an inquiry to some jacks, as already seen on other TRX40-based mobos. However this machine has a slightly incompatible configuration, hence the existing mapping cannot be used as is. Meanwhile the ESS chip seems working without any quirk. But since both audio devices don't provide any specific names, both cards appear as "USB-Audio", and it's quite confusing for users. This patch is an attempt to overcome those issues: - The specific mapping table for ALC1220-VB is provided, reducing the non-working nodes and renaming the badly chosen controls. The connector map isn't needed here unlike other TRX40 quirks. - For both USB IDs (0414:a000 and 0414:a001), provide specific card name strings, so that user-space can identify more easily; and more importantly, UCM profile can be applied to each. Reported-by: Linus Torvalds Cc: Link: https://lore.kernel.org/r/20200526082810.29506-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8fc8674092b2005895dfe419d0912e6d9fe52b29 Author: Vinod Koul Date: Thu May 21 10:57:28 2020 +0530 clk: qcom: gcc: Fix parent for gpll0_out_even [ Upstream commit a76f274182f054481182c81cd62bb8794a5450a6 ] Documentation says that gpll0 is parent of gpll0_out_even, somehow driver coded that as bi_tcxo, so fix it Fixes: 2a1d7eb854bb ("clk: qcom: gcc: Add global clock controller driver for SM8150") Reported-by: Jonathan Marek Signed-off-by: Vinod Koul Link: https://lkml.kernel.org/r/20200521052728.2141377-1-vkoul@kernel.org Reviewed-by: Bjorn Andersson Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 68fe063327aff50a71be606ee421d6205faa83bd Author: Eric W. Biederman Date: Mon May 25 12:56:15 2020 -0500 exec: Always set cap_ambient in cap_bprm_set_creds [ Upstream commit a4ae32c71fe90794127b32d26d7ad795813b502e ] An invariant of cap_bprm_set_creds is that every field in the new cred structure that cap_bprm_set_creds might set, needs to be set every time to ensure the fields does not get a stale value. The field cap_ambient is not set every time cap_bprm_set_creds is called, which means that if there is a suid or sgid script with an interpreter that has neither the suid nor the sgid bits set the interpreter should be able to accept ambient credentials. Unfortuantely because cap_ambient is not reset to it's original value the interpreter can not accept ambient credentials. Given that the ambient capability set is expected to be controlled by the caller, I don't think this is particularly serious. But it is definitely worth fixing so the code works correctly. I have tested to verify my reading of the code is correct and the interpreter of a sgid can receive ambient capabilities with this change and cannot receive ambient capabilities without this change. Cc: stable@vger.kernel.org Cc: Andy Lutomirski Fixes: 58319057b784 ("capabilities: ambient capabilities") Signed-off-by: "Eric W. Biederman" Signed-off-by: Sasha Levin commit 4adcf889e66b4cc0fd609b9764585bf071fb7a0e Author: Chris Chiu Date: Tue May 26 14:26:13 2020 +0800 ALSA: usb-audio: mixer: volume quirk for ESS Technology Asus USB DAC [ Upstream commit 4020d1ccbe55bdf67b31d718d2400506eaf4b43f ] The Asus USB DAC is a USB type-C audio dongle for connecting to the headset and headphone. The volume minimum value -23040 which is 0xa600 in hexadecimal with the resolution value 1 indicates this should be endianness issue caused by the firmware bug. Add a volume quirk to fix the volume control problem. Also fixes this warning: Warning! Unlikely big volume range (=23040), cval->res is probably wrong. [5] FU [Headset Capture Volume] ch = 1, val = -23040/0/1 Warning! Unlikely big volume range (=23040), cval->res is probably wrong. [7] FU [Headset Playback Volume] ch = 1, val = -23040/0/1 Signed-off-by: Chris Chiu Cc: Link: https://lore.kernel.org/r/20200526062613.55401-1-chiu@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 8c71b0bd64dfa87de6308c3069eeb50a61f13537 Author: Takashi Iwai Date: Tue May 26 08:24:06 2020 +0200 ALSA: hda/realtek - Add a model for Thinkpad T570 without DAC workaround [ Upstream commit 399c01aa49e548c82d40f8161915a5941dd3c60e ] We fixed the regression of the speaker volume for some Thinkpad models (e.g. T570) by the commit 54947cd64c1b ("ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570"). Essentially it fixes the DAC / pin pairing by a static table. It was confirmed and merged to stable kernel later. Now, interestingly, we got another regression report for the very same model (T570) about the similar problem, and the commit above was the culprit. That is, by some reason, there are devices that prefer the DAC1, and another device DAC2! Unfortunately those have the same ID and we have no idea what can differentiate, in this patch, a new fixup model "tpt470-dock-fix" is provided, so that users with such a machine can apply it manually. When model=tpt470-dock-fix option is passed to snd-hda-intel module, it avoids the fixed DAC pairing and the DAC1 is assigned to the speaker like the earlier versions. Fixes: 54947cd64c1b ("ALSA: hda/realtek - Fix speaker output regression on Thinkpad T570") BugLink: https://apibugzilla.suse.com/show_bug.cgi?id=1172017 Cc: Link: https://lore.kernel.org/r/20200526062406.9799-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 84b0a4f4258420e1706d6ce6534c850cac251615 Author: Changming Liu Date: Tue May 26 00:39:21 2020 +0000 ALSA: hwdep: fix a left shifting 1 by 31 UB bug [ Upstream commit fb8cd6481ffd126f35e9e146a0dcf0c4e8899f2e ] The "info.index" variable can be 31 in "1 << info.index". This might trigger an undefined behavior since 1 is signed. Fix this by casting 1 to 1u just to be sure "1u << 31" is defined. Signed-off-by: Changming Liu Cc: Link: https://lore.kernel.org/r/BL0PR06MB4548170B842CB055C9AF695DE5B00@BL0PR06MB4548.namprd06.prod.outlook.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit a003e1f653d6a282078bb209cf54619a7013befb Author: Qiushi Wu Date: Fri May 22 22:04:57 2020 -0500 RDMA/pvrdma: Fix missing pci disable in pvrdma_pci_probe() [ Upstream commit db857e6ae548f0f4f4a0f63fffeeedf3cca21f9d ] In function pvrdma_pci_probe(), pdev was not disabled in one error path. Thus replace the jump target “err_free_device” by "err_disable_pdev". Fixes: 29c8d9eba550 ("IB: Add vmw_pvrdma driver") Link: https://lore.kernel.org/r/20200523030457.16160-1-wu000273@umn.edu Signed-off-by: Qiushi Wu Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b191e3ea6dfce81e565b40bfb00ab5e6b80362f1 Author: Tiezhu Yang Date: Fri May 22 12:12:18 2020 +0800 gpio: bcm-kona: Fix return value of bcm_kona_gpio_probe() [ Upstream commit 98f7d1b15e87c84488b30ecc4ec753b0690b9dbf ] Propagate the error code returned by devm_platform_ioremap_resource() out of probe() instead of overwriting it. Fixes: 72d8cb715477 ("drivers: gpio: bcm-kona: use devm_platform_ioremap_resource()") Signed-off-by: Tiezhu Yang [Bartosz: tweaked the commit message] Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit d6d07089dee3d5cf5a3e194dcb03e66ebf4ebb87 Author: Tiezhu Yang Date: Fri May 22 12:12:19 2020 +0800 gpio: pxa: Fix return value of pxa_gpio_probe() [ Upstream commit 558ab2e8155e5f42ca0a6407957cd4173dc166cc ] When call function devm_platform_ioremap_resource(), we should use IS_ERR() to check the return value and return PTR_ERR() if failed. Fixes: 542c25b7a209 ("drivers: gpio: pxa: use devm_platform_ioremap_resource()") Signed-off-by: Tiezhu Yang Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit a971f71e91fb7987b077e36d32fa4d32ff8fa470 Author: Peng Hao Date: Fri May 22 09:29:25 2020 +0000 mmc: block: Fix use-after-free issue for rpmb [ Upstream commit 202500d21654874aa03243e91f96de153ec61860 ] The data structure member “rpmb->md” was passed to a call of the function “mmc_blk_put” after a call of the function “put_device”. Reorder these function calls to keep the data accesses consistent. Fixes: 1c87f7357849 ("mmc: block: Fix bug when removing RPMB chardev ") Signed-off-by: Peng Hao Cc: stable@vger.kernel.org [Uffe: Fixed up mangled patch and updated commit message] Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 2de6df8df9bde3fda53083fa9d06b844ffbd60d5 Author: Hamish Martin Date: Wed May 20 16:30:42 2020 +1200 ARM: dts: bcm: HR2: Fix PPI interrupt types [ Upstream commit be0ec060b54f0481fb95d59086c1484a949c903c ] These error messages are output when booting on a BCM HR2 system: GIC: PPI11 is secure or misconfigured GIC: PPI13 is secure or misconfigured Per ARM documentation these interrupts are triggered on a rising edge. See ARM Cortex A-9 MPCore Technical Reference Manual, Revision r4p1, Section 3.3.8 Interrupt Configuration Registers. The same issue was resolved for NSP systems in commit 5f1aa51c7a1e ("ARM: dts: NSP: Fix PPI interrupt types"). Fixes: b9099ec754b5 ("ARM: dts: Add Broadcom Hurricane 2 DTS include file") Signed-off-by: Hamish Martin Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit f8b161c3f3acafd965ba7f1b8c84886e8b5b9ef0 Author: Vincent Stehlé Date: Sat Apr 18 14:35:22 2020 +0200 ARM: dts: bcm2835-rpi-zero-w: Fix led polarity [ Upstream commit 58bb90ab415562eededb932455046924e65df342 ] The status "ACT" led on the Raspberry Pi Zero W is on when GPIO 47 is low. This has been verified on a board and somewhat confirmed by both the GPIO name ("STATUS_LED_N") and the reduced schematics [1]. [1]: https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/rpi_SCH_ZeroW_1p1_reduced.pdf Fixes: 2c7c040c73e9 ("ARM: dts: bcm2835: Add Raspberry Pi Zero W") Signed-off-by: Vincent Stehlé Cc: Stefan Wahren Cc: Florian Fainelli Tested-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 485bd944e0c6102f1a503754f38fc9ace4daf97d Author: Robert Beckett Date: Thu May 14 19:02:37 2020 +0200 ARM: dts/imx6q-bx50v3: Set display interface clock parents [ Upstream commit 665e7c73a7724a393b4ec92d1ae1e029925ef2b7 ] Avoid LDB and IPU DI clocks both using the same parent. LDB requires pasthrough clock to avoid breaking timing while IPU DI does not. Force IPU DI clocks to use IMX6QDL_CLK_PLL2_PFD0_352M as parent and LDB to use IMX6QDL_CLK_PLL5_VIDEO_DIV. This fixes an issue where attempting atomic modeset while using HDMI and display port at the same time causes LDB clock programming to destroy the programming of HDMI that was done during the same modeset. Cc: stable@vger.kernel.org Signed-off-by: Robert Beckett [Use IMX6QDL_CLK_PLL2_PFD0_352M instead of IMX6QDL_CLK_PLL2_PFD2_396M originally chosen by Robert Beckett to avoid affecting eMMC clock by DRM atomic updates] Signed-off-by: Ian Ray [Squash Robert's and Ian's commits for bisectability, update patch description and add stable tag] Signed-off-by: Sebastian Reichel Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit a38a75c22b9f5398091fd98f235ea4bfd0eb56a4 Author: Kaike Wan Date: Mon May 11 23:13:28 2020 -0400 IB/qib: Call kobject_put() when kobject_init_and_add() fails [ Upstream commit a35cd6447effd5c239b564c80fa109d05ff3d114 ] When kobject_init_and_add() returns an error in the function qib_create_port_files(), the function kobject_put() is not called for the corresponding kobject, which potentially leads to memory leak. This patch fixes the issue by calling kobject_put() even if kobject_init_and_add() fails. In addition, the ppd->diagc_kobj is released along with other kobjects when the sysfs is unregistered. Fixes: f931551bafe1 ("IB/qib: Add new qib driver for QLogic PCIe InfiniBand adapters") Link: https://lore.kernel.org/r/20200512031328.189865.48627.stgit@awfm-01.aw.intel.com Cc: Suggested-by: Lin Yi Reviewed-by: Mike Marciniszyn Signed-off-by: Kaike Wan Signed-off-by: Dennis Dalessandro Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 820be34d0137f180ee878192d406c8017c7cdcb8 Author: Paul Cercueil Date: Sat May 16 23:50:50 2020 +0200 gpu/drm: Ingenic: Fix opaque pointer casted to wrong type [ Upstream commit abf56fadf0e208abfb13ad1ac0094416058da0ad ] The opaque pointer passed to the IRQ handler is a pointer to the drm_device, not a pointer to our ingenic_drm structure. It still worked, because our ingenic_drm structure contains the drm_device as its first field, so the pointer received had the same value, but this was not semantically correct. Cc: stable@vger.kernel.org # v5.3 Fixes: 90b86fcc47b4 ("DRM: Add KMS driver for the Ingenic JZ47xx SoCs") Signed-off-by: Paul Cercueil Link: https://patchwork.freedesktop.org/patch/msgid/20200516215057.392609-5-paul@crapouillou.net Acked-by: Sam Ravnborg Signed-off-by: Sasha Levin commit 707f5075021f0c5989e0706d74ead9dc3f69e86a Author: Dennis YC Hsieh Date: Sun Mar 8 18:52:47 2020 +0800 soc: mediatek: cmdq: return send msg error code [ Upstream commit 34c4e4072603ff5c174df73b973896abb76cbb51 ] Return error code to client if send message fail, so that client has chance to error handling. Fixes: 576f1b4bc802 ("soc: mediatek: Add Mediatek CMDQ helper") Signed-off-by: Dennis YC Hsieh Reviewed-by: CK Hu Link: https://lore.kernel.org/r/1583664775-19382-6-git-send-email-dennis-yc.hsieh@mediatek.com Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 56e7873ed2678dbb23c537d52d48c4629ad6422d Author: Hsin-Yi Wang Date: Mon May 4 20:44:43 2020 +0800 arm64: dts: mt8173: fix vcodec-enc clock [ Upstream commit 3b1f6c5e4dfaf767f6f2f120cd93b347b5a9f1aa ] Fix the assigned-clock-parents to higher frequency clock to avoid h264 encode timeout: [ 134.763465] mtk_vpu 10020000.vpu: vpu ipi 4 ack time out ! [ 134.769008] [MTK_VCODEC][ERROR][18]: vpu_enc_send_msg() vpu_ipi_send msg_id c002 len 32 fail -5 [ 134.777707] [MTK_VCODEC][ERROR][18]: vpu_enc_encode() AP_IPIMSG_ENC_ENCODE 0 fail venc_sel is the clock used by h264 encoder, and venclt_sel is the clock used by vp8 encoder. Assign venc_sel to vcodecpll_ck and venclt_sel to vcodecpll_370p5. vcodecpll 1482000000 vcodecpll_ck 494000000 venc_sel 494000000 ... vcodecpll_370p5 370500000 venclt_sel 370500000 Fixes: fbbad0287cec ("arm64: dts: Using standard CCF interface to set vcodec clk") Signed-off-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20200504124442.208004-1-hsinyi@chromium.org Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit 750f47a6586b3da0ad317adcbaf65a92a66dfa45 Author: Takashi Iwai Date: Wed Apr 29 15:56:54 2020 +0200 gpio: exar: Fix bad handling for ida_simple_get error path [ Upstream commit 333830aa149a87cabeb5d30fbcf12eecc8040d2c ] The commit 7ecced0934e5 ("gpio: exar: add a check for the return value of ida_simple_get fails") added a goto jump to the common error handler for ida_simple_get() error, but this is wrong in two ways: it doesn't set the proper return code and, more badly, it invokes ida_simple_remove() with a negative index that shall lead to a kernel panic via BUG_ON(). This patch addresses those two issues. Fixes: 7ecced0934e5 ("gpio: exar: add a check for the return value of ida_simple_get fails") Cc: Signed-off-by: Takashi Iwai Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 5242e3850b1c4c32e9b313b4d5860958382fa5ab Author: Russell King Date: Sun May 3 13:24:07 2020 +0100 ARM: uaccess: fix DACR mismatch with nested exceptions [ Upstream commit 71f8af1110101facfad68989ff91f88f8e2c3e22 ] Tomas Paukrt reports that his SAM9X60 based system (ARM926, ARMv5TJ) fails to fix up alignment faults, eventually resulting in a kernel oops. The problem occurs when using CONFIG_CPU_USE_DOMAINS with commit e6978e4bf181 ("ARM: save and reset the address limit when entering an exception"). This is because the address limit is set back to TASK_SIZE on exception entry, and, although it is restored on exception exit, the domain register is not. Hence, this sequence can occur: interrupt pt_regs->addr_limit = addr_limit // USER_DS addr_limit = USER_DS alignment exception __probe_kernel_read() old_fs = get_fs() // USER_DS set_fs(KERNEL_DS) addr_limit = KERNEL_DS dacr.kernel = DOMAIN_MANAGER interrupt pt_regs->addr_limit = addr_limit // KERNEL_DS addr_limit = USER_DS alignment exception __probe_kernel_read() old_fs = get_fs() // USER_DS set_fs(KERNEL_DS) addr_limit = KERNEL_DS dacr.kernel = DOMAIN_MANAGER ... set_fs(old_fs) addr_limit = USER_DS dacr.kernel = DOMAIN_CLIENT ... addr_limit = pt_regs->addr_limit // KERNEL_DS interrupt returns At this point, addr_limit is correctly restored to KERNEL_DS for __probe_kernel_read() to continue execution, but dacr.kernel is not, it has been reset by the set_fs(old_fs) to DOMAIN_CLIENT. This would not have happened prior to the mentioned commit, because addr_limit would remain KERNEL_DS, so get_fs() would have returned KERNEL_DS, and so would correctly nest. This commit fixes the problem by also saving the DACR on exception entry if either CONFIG_CPU_SW_DOMAIN_PAN or CONFIG_CPU_USE_DOMAINS are enabled, and resetting the DACR appropriately on exception entry to match addr_limit and PAN settings. Fixes: e6978e4bf181 ("ARM: save and reset the address limit when entering an exception") Reported-by: Tomas Paukrt Signed-off-by: Russell King Signed-off-by: Sasha Levin commit d9c318f0eda3b73ed5f4ea49cd02fa8228dbf229 Author: Russell King Date: Sun May 3 13:14:09 2020 +0100 ARM: uaccess: integrate uaccess_save and uaccess_restore [ Upstream commit 8ede890b0bcebe8c760aacfe20e934d98c3dc6aa ] Integrate uaccess_save / uaccess_restore macros into the new uaccess_entry / uaccess_exit macros respectively. Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 96e2df4c753b8bd383bcaf97e26a9b396029fda9 Author: Russell King Date: Sun May 3 13:03:54 2020 +0100 ARM: uaccess: consolidate uaccess asm to asm/uaccess-asm.h [ Upstream commit 747ffc2fcf969eff9309d7f2d1d61cb8b9e1bb40 ] Consolidate the user access assembly code to asm/uaccess-asm.h. This moves the csdb, check_uaccess, uaccess_mask_range_ptr, uaccess_enable, uaccess_disable, uaccess_save, uaccess_restore macros, and creates two new ones for exception entry and exit - uaccess_entry and uaccess_exit. This makes the uaccess_save and uaccess_restore macros private to asm/uaccess-asm.h. Signed-off-by: Russell King Signed-off-by: Sasha Levin commit f175897a960e4e6763efd96e7fa639fc09b1738b Author: Łukasz Stelmach Date: Mon Apr 27 20:36:11 2020 +0100 ARM: 8970/1: decompressor: increase tag size [ Upstream commit 2c962369d72f286659e6446919f88d69b943cb4d ] The size field of the tag header structure is supposed to be set to the size of a tag structure including the header. Fixes: c772568788b5f0 ("ARM: add additional table to compressed kernel") Signed-off-by: Łukasz Stelmach Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 4aa75ce40b1dc29c70ea16c1fa374be6c14bb1cd Author: Wei Yongjun Date: Tue Apr 28 16:09:53 2020 -0700 Input: synaptics-rmi4 - fix error return code in rmi_driver_probe() [ Upstream commit 5caab2da63207d6d631007f592f5219459e3454d ] Fix to return a negative error code from the input_register_device() error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20200428134948.78343-1-weiyongjun1@huawei.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 176dbb9eeba092ca4b840595fd9615319415e428 Author: Evan Green Date: Mon Apr 27 18:08:58 2020 -0700 Input: synaptics-rmi4 - really fix attn_data use-after-free [ Upstream commit d5a5e5b5fa7b86c05bf073acc0ba98fa280174ec ] Fix a use-after-free noticed by running with KASAN enabled. If rmi_irq_fn() is run twice in a row, then rmi_f11_attention() (among others) will end up reading from drvdata->attn_data.data, which was freed and left dangling in rmi_irq_fn(). Commit 55edde9fff1a ("Input: synaptics-rmi4 - prevent UAF reported by KASAN") correctly identified and analyzed this bug. However the attempted fix only NULLed out a local variable, missing the fact that drvdata->attn_data is a struct, not a pointer. NULL out the correct pointer in the driver data to prevent the attention functions from copying from it. Fixes: 55edde9fff1a ("Input: synaptics-rmi4 - prevent UAF reported by KASAN") Fixes: b908d3cd812a ("Input: synaptics-rmi4 - allow to add attention data") Signed-off-by: Evan Green Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200427145537.1.Ic8f898e0147beeee2c005ee7b20f1aebdef1e7eb@changeid Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 7016d241ca64852f389d7f62f4c3acbdba66f6b2 Author: Kevin Locke Date: Mon Apr 27 18:07:20 2020 -0700 Input: i8042 - add ThinkPad S230u to i8042 reset list [ Upstream commit 2712c91a54a1058d55c284152b4d93c979b67be6 ] On the Lenovo ThinkPad Twist S230u (3347-4HU) with BIOS version "GDETC1WW (1.81 ) 06/27/2019", the keyboard, Synaptics TouchPad, and TrackPoint either do not function or stop functioning a few minutes after boot. This problem has been noted before, perhaps only occurring with BIOS 1.57 and later.[1][2][3][4][5] Odds of a BIOS fix appear to be low: 1.57 was released over 6 years ago and although the [BIOS changelog] notes "Fixed an issue of UEFI touchpad/trackpoint/keyboard/touchscreen" in 1.58, it appears to be insufficient. Setting i8042.reset=1 or adding 33474HU to the reset list avoids the issue on my system from either warm or cold boot. [1]: https://bugs.launchpad.net/bugs/1210748 [2]: https://bbs.archlinux.org/viewtopic.php?pid=1360425 [3]: https://forums.linuxmint.com/viewtopic.php?f=46&t=41200 [4]: https://forums.linuxmint.com/viewtopic.php?f=49&t=157115 [5]: https://forums.lenovo.com/topic/findpost/27/1337119 [BIOS changelog]: https://download.lenovo.com/pccbbs/mobiles/gduj33uc.txt Signed-off-by: Kevin Locke Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/94f384b0f75f90f71425d7dce7ac82c59ddb87a8.1587702636.git.kevin@kevinlocke.name Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit a63a679e1ec7a508c7944b1889baa8c5f8557412 Author: Christophe JAILLET Date: Wed Apr 22 13:58:42 2020 -0700 Input: dlink-dir685-touchkeys - fix a typo in driver name [ Upstream commit 38347374ae3f1ec4df56dd688bd603a64e79a0ed ] According to the file name and Kconfig, a 'k' is missing in this driver name. It should be "dlink-dir685-touchkeys". Fixes: 131b3de7016b ("Input: add D-Link DIR-685 touchkeys driver") Signed-off-by: Christophe JAILLET Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20200412213937.5287-1-christophe.jaillet@wanadoo.fr Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit d9d50cbccc790c93cbec4ba56304a9823a6bd8dc Author: Łukasz Patron Date: Wed Apr 22 14:13:09 2020 -0700 Input: xpad - add custom init packet for Xbox One S controllers [ Upstream commit 764f7f911bf72450c51eb74cbb262ad9933741d8 ] Sending [ 0x05, 0x20, 0x00, 0x0f, 0x06 ] packet for Xbox One S controllers fixes an issue where controller is stuck in Bluetooth mode and not sending any inputs. Signed-off-by: Łukasz Patron Reviewed-by: Cameron Gutman Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200422075206.18229-1-priv.luk@gmail.com Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 9abf0403a70971fcbac1dba1b3d83c34481c761a Author: Brendan Shanks Date: Wed Apr 22 13:45:12 2020 -0700 Input: evdev - call input_flush_device() on release(), not flush() [ Upstream commit 09264098ff153f60866039d60b31d39b66f55a31 ] input_flush_device() should only be called once the struct file is being released and no open descriptors remain, but evdev_flush() was calling it whenever a file descriptor was closed. This caused uploaded force-feedback effects to be erased when a process did a dup()/close() on the event FD, called system(), etc. Call input_flush_device() from evdev_release() instead. Reported-by: Mathieu Maret Signed-off-by: Brendan Shanks Link: https://lore.kernel.org/r/20200421231003.7935-1-bshanks@codeweavers.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 5a273fa5622961cfe89dd1192602f0f6be876bb6 Author: James Hilliard Date: Sat Apr 18 21:17:12 2020 -0700 Input: usbtouchscreen - add support for BonXeon TP [ Upstream commit e3b4f94ef52ae1592cbe199bd38dbdc0d58b2217 ] Based on available information this uses the singletouch irtouch protocol. This is tested and confirmed to be fully functional on the BonXeon TP hardware I have. Signed-off-by: James Hilliard Link: https://lore.kernel.org/r/20200413184217.55700-1-james.hilliard1@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit b66de2d961a68648feb276142045bf3516e89cc1 Author: Madhuparna Bhowmik Date: Thu May 14 19:41:15 2020 +0530 drivers: net: hamradio: Fix suspicious RCU usage warning in bpqether.c [ Upstream commit 95f59bf88bb75281cc626e283ecefdd5d5641427 ] This patch fixes the following warning: ============================= WARNING: suspicious RCU usage 5.7.0-rc5-next-20200514-syzkaller #0 Not tainted ----------------------------- drivers/net/hamradio/bpqether.c:149 RCU-list traversed in non-reader section!! Since rtnl lock is held, pass this cond in list_for_each_entry_rcu(). Reported-by: syzbot+bb82cafc737c002d11ca@syzkaller.appspotmail.com Signed-off-by: Madhuparna Bhowmik Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dfe417b45634ff370adb92718241d56fda7e6814 Author: Matteo Croce Date: Mon May 11 13:32:34 2020 +0200 samples: bpf: Fix build error [ Upstream commit 23ad04669f81f958e9a4121b0266228d2eb3c357 ] GCC 10 is very strict about symbol clash, and lwt_len_hist_user contains a symbol which clashes with libbpf: /usr/bin/ld: samples/bpf/lwt_len_hist_user.o:(.bss+0x0): multiple definition of `bpf_log_buf'; samples/bpf/bpf_load.o:(.bss+0x8c0): first defined here collect2: error: ld returned 1 exit status bpf_log_buf here seems to be a leftover, so removing it. Signed-off-by: Matteo Croce Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20200511113234.80722-1-mcroce@redhat.com Signed-off-by: Sasha Levin commit 70bf0fd60f2ff6c34bfa664a206643608c645894 Author: Al Viro Date: Tue Apr 7 02:40:11 2020 +0100 csky: Fixup raw_copy_from_user() [ Upstream commit 51bb38cb78363fdad1f89e87357b7bc73e39ba88 ] If raw_copy_from_user(to, from, N) returns K, callers expect the first N - K bytes starting at to to have been replaced with the contents of corresponding area starting at from and the last K bytes of destination *left* *unmodified*. What arch/sky/lib/usercopy.c is doing is broken - it can lead to e.g. data corruption on write(2). raw_copy_to_user() is inaccurate about return value, which is a bug, but consequences are less drastic than for raw_copy_from_user(). And just what are those access_ok() doing in there? I mean, look into linux/uaccess.h; that's where we do that check (as well as zero tail on failure in the callers that need zeroing). AFAICS, all of that shouldn't be hard to fix; something like a patch below might make a useful starting point. I would suggest moving these macros into usercopy.c (they are never used anywhere else) and possibly expanding them there; if you leave them alive, please at least rename __copy_user_zeroing(). Again, it must not zero anything on failed read. Said that, I'm not sure we won't be better off simply turning usercopy.c into usercopy.S - all that is left there is a couple of functions, each consisting only of inline asm. Guo Ren reply: Yes, raw_copy_from_user is wrong, it's no need zeroing code. unsigned long _copy_from_user(void *to, const void __user *from, unsigned long n) { unsigned long res = n; might_fault(); if (likely(access_ok(from, n))) { kasan_check_write(to, n); res = raw_copy_from_user(to, from, n); } if (unlikely(res)) memset(to + (n - res), 0, res); return res; } EXPORT_SYMBOL(_copy_from_user); You are right and access_ok() should be removed. but, how about: do { ... "2: stw %3, (%1, 0) \n" \ + " subi %0, 4 \n" \ "9: stw %4, (%1, 4) \n" \ + " subi %0, 4 \n" \ "10: stw %5, (%1, 8) \n" \ + " subi %0, 4 \n" \ "11: stw %6, (%1, 12) \n" \ + " subi %0, 4 \n" \ " addi %2, 16 \n" \ " addi %1, 16 \n" \ Don't expand __ex_table AI Viro reply: Hey, I've no idea about the instruction scheduling on csky - if that doesn't slow the things down, all the better. It's just that copy_to_user() and friends are on fairly hot codepaths, and in quite a few situations they will dominate the speed of e.g. read(2). So I tried to keep the fast path unchanged. Up to the architecture maintainers, obviously. Which would be you... As for the fixups size increase (__ex_table size is unchanged)... You have each of those macros expanded exactly once. So the size is not a serious argument, IMO - useless complexity would be, if it is, in fact, useless; the size... not really, especially since those extra subi will at least offset it. Again, up to you - asm optimizations of (essentially) memcpy()-style loops are tricky and can depend upon the fairly subtle details of architecture. So even on something I know reasonably well I would resort to direct experiments if I can't pass the buck to architecture maintainers. It *is* worth optimizing - this is where read() from a file that is already in page cache spends most of the time, etc. Guo Ren reply: Thx, after fixup some typo “sub %0, 4”, apply the patch. TODO: - user copy/from codes are still need optimizing. Signed-off-by: Al Viro Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit 2fa8032fa78a17115c9f92a2c93de58d8508c76d Author: Steve French Date: Wed May 13 10:27:16 2020 -0500 cifs: Fix null pointer check in cifs_read [ Upstream commit 9bd21d4b1a767c3abebec203342f3820dcb84662 ] Coverity scan noted a redundant null check Coverity-id: 728517 Reported-by: Coverity Signed-off-by: Steve French Reviewed-by: Shyam Prasad N Signed-off-by: Sasha Levin commit ce1ef281e786bcb00eeb227ae07705ae67eda18b Author: Amy Shih Date: Tue May 12 09:38:06 2020 +0000 hwmon: (nct7904) Fix incorrect range of temperature limit registers [ Upstream commit 7b2fd270af27edaf02acb41a7babe805a9441914 ] The format of temperature limitation registers are 8-bit 2's complement and the range is -128~127. Converts the reading value to signed char to fix the incorrect range of temperature limitation registers. Signed-off-by: Amy Shih Signed-off-by: Guenter Roeck Signed-off-by: Sasha Levin commit 68d72327999af2c7d9955ded4c0e9033fd3f477f Author: Liu Yibin Date: Wed May 13 15:54:15 2020 +0800 csky: Fixup remove duplicate irq_disable [ Upstream commit 6633a5aa8eb6bda70eb3a9837efd28a67ccc6e0a ] Interrupt has been disabled in __schedule() with local_irq_disable() and enabled in finish_task_switch->finish_lock_switch() with local_irq_enabled(), So needn't to disable irq here. Signed-off-by: Liu Yibin Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit 99bd434f88930e8212b61827f8b591017835d94b Author: Mao Han Date: Mon Apr 20 12:55:23 2020 +0800 csky: Fixup perf callchain unwind [ Upstream commit 229a0ddee1108a3f82a873e6cbbe35c92c540444 ] [ 5221.974084] Unable to handle kernel paging request at virtual address 0xfffff000, pc: 0x8002c18e [ 5221.985929] Oops: 00000000 [ 5221.989488] [ 5221.989488] CURRENT PROCESS: [ 5221.989488] [ 5221.992877] COMM=callchain_test PID=11962 [ 5221.995213] TEXT=00008000-000087e0 DATA=00009f1c-0000a018 BSS=0000a018-0000b000 [ 5221.999037] USER-STACK=7fc18e20 KERNEL-STACK=be204680 [ 5221.999037] [ 5222.003292] PC: 0x8002c18e (perf_callchain_kernel+0x3e/0xd4) [ 5222.007957] LR: 0x8002c198 (perf_callchain_kernel+0x48/0xd4) [ 5222.074873] Call Trace: [ 5222.074873] [<800a248e>] get_perf_callchain+0x20a/0x29c [ 5222.074873] [<8009d964>] perf_callchain+0x64/0x80 [ 5222.074873] [<8009dc1c>] perf_prepare_sample+0x29c/0x4b8 [ 5222.074873] [<8009de6e>] perf_event_output_forward+0x36/0x98 [ 5222.074873] [<800497e0>] search_exception_tables+0x20/0x44 [ 5222.074873] [<8002cbb6>] do_page_fault+0x92/0x378 [ 5222.074873] [<80098608>] __perf_event_overflow+0x54/0xdc [ 5222.074873] [<80098778>] perf_swevent_hrtimer+0xe8/0x164 [ 5222.074873] [<8002ddd0>] update_mmu_cache+0x0/0xd8 [ 5222.074873] [<8002c014>] user_backtrace+0x58/0xc4 [ 5222.074873] [<8002c0b4>] perf_callchain_user+0x34/0xd0 [ 5222.074873] [<800a2442>] get_perf_callchain+0x1be/0x29c [ 5222.074873] [<8009d964>] perf_callchain+0x64/0x80 [ 5222.074873] [<8009d834>] perf_output_sample+0x78c/0x858 [ 5222.074873] [<8009dc1c>] perf_prepare_sample+0x29c/0x4b8 [ 5222.074873] [<8009de94>] perf_event_output_forward+0x5c/0x98 [ 5222.097846] [ 5222.097846] [<800a0300>] perf_event_exit_task+0x58/0x43c [ 5222.097846] [<8006c874>] hrtimer_interrupt+0x104/0x2ec [ 5222.097846] [<800a0300>] perf_event_exit_task+0x58/0x43c [ 5222.097846] [<80437bb6>] dw_apb_clockevent_irq+0x2a/0x4c [ 5222.097846] [<8006c770>] hrtimer_interrupt+0x0/0x2ec [ 5222.097846] [<8005f2e4>] __handle_irq_event_percpu+0xac/0x19c [ 5222.097846] [<80437bb6>] dw_apb_clockevent_irq+0x2a/0x4c [ 5222.097846] [<8005f408>] handle_irq_event_percpu+0x34/0x88 [ 5222.097846] [<8005f480>] handle_irq_event+0x24/0x64 [ 5222.097846] [<8006218c>] handle_level_irq+0x68/0xdc [ 5222.097846] [<8005ec76>] __handle_domain_irq+0x56/0xa8 [ 5222.097846] [<80450e90>] ck_irq_handler+0xac/0xe4 [ 5222.097846] [<80029012>] csky_do_IRQ+0x12/0x24 [ 5222.097846] [<8002a3a0>] csky_irq+0x70/0x80 [ 5222.097846] [<800ca612>] alloc_set_pte+0xd2/0x238 [ 5222.097846] [<8002ddd0>] update_mmu_cache+0x0/0xd8 [ 5222.097846] [<800a0340>] perf_event_exit_task+0x98/0x43c The original fp check doesn't base on the real kernal stack region. Invalid fp address may cause kernel panic. Signed-off-by: Mao Han Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit f3f23f4c6413bf3c29b092b037b7b4fd3636a95d Author: Liu Yibin Date: Tue Apr 21 15:56:28 2020 +0800 csky: Fixup msa highest 3 bits mask [ Upstream commit 165f2d2858013253042809df082b8df7e34e86d7 ] Just as comment mentioned, the msa format: cr<30/31, 15> MSA register format: 31 - 29 | 28 - 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 BA Reserved SH WA B SO SEC C D V So we should shift 29 bits not 28 bits for mask Signed-off-by: Liu Yibin Signed-off-by: Guo Ren Signed-off-by: Sasha Levin commit e104bd8554541b43738d6f38ffae775266f8f259 Author: Tero Kristo Date: Fri Apr 24 18:23:01 2020 +0300 clk: ti: am33xx: fix RTC clock parent [ Upstream commit dc6dbd51009fc412729c307161f442c0a08618f4 ] Right now, trying to use RTC purely with the ti-sysc / clkctrl framework fails to enable the RTC module properly. Based on experimentation, this appears to be because RTC is sourced from the clkdiv32k optional clock. TRM is not very clear on this topic, but fix the RTC to use the proper source clock nevertheless. Reported-by: Tony Lindgren Signed-off-by: Tero Kristo Link: https://lkml.kernel.org/r/20200424152301.4018-1-t-kristo@ti.com Acked-by: Tony Lindgren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6b8c281e9a487d2443d18de612cf9f8b3c675513 Author: Kefeng Wang Date: Mon May 11 10:19:53 2020 +0800 riscv: stacktrace: Fix undefined reference to `walk_stackframe' [ Upstream commit 0502bee37cdef755d63eee60236562e5605e2480 ] Drop static declaration to fix following build error if FRAME_POINTER disabled, riscv64-linux-ld: arch/riscv/kernel/perf_callchain.o: in function `.L0': perf_callchain.c:(.text+0x2b8): undefined reference to `walk_stackframe' Reported-by: Hulk Robot Signed-off-by: Kefeng Wang Signed-off-by: Palmer Dabbelt Signed-off-by: Sasha Levin commit b84952e88336749bb28fadd100943b179b613bc1 Author: Denis V. Lunev Date: Tue Apr 28 16:15:11 2020 +0300 IB/i40iw: Remove bogus call to netdev_master_upper_dev_get() [ Upstream commit 856ec7f64688387b100b7083cdf480ce3ac41227 ] Local variable netdev is not used in these calls. It should be noted, that this change is required to work in bonded mode. Otherwise we would get the following assert: "RTNL: assertion failed at net/core/dev.c (5665)" With the calltrace as follows: dump_stack+0x19/0x1b netdev_master_upper_dev_get+0x61/0x70 i40iw_addr_resolve_neigh+0x1e8/0x220 i40iw_make_cm_node+0x296/0x700 ? i40iw_find_listener.isra.10+0xcc/0x110 i40iw_receive_ilq+0x3d4/0x810 i40iw_puda_poll_completion+0x341/0x420 i40iw_process_ceq+0xa5/0x280 i40iw_ceq_dpc+0x1e/0x40 tasklet_action+0x83/0x140 __do_softirq+0x125/0x2bb call_softirq+0x1c/0x30 do_softirq+0x65/0xa0 irq_exit+0x105/0x110 do_IRQ+0x56/0xf0 common_interrupt+0x16a/0x16a ? cpuidle_enter_state+0x57/0xd0 cpuidle_idle_call+0xde/0x230 arch_cpu_idle+0xe/0xc0 cpu_startup_entry+0x14a/0x1e0 start_secondary+0x1f7/0x270 start_cpu+0x5/0x14 Link: https://lore.kernel.org/r/20200428131511.11049-1-den@openvz.org Signed-off-by: Denis V. Lunev Acked-by: Shiraz Saleem Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 706fee65d95c8c1e2024af37562ed332eec50655 Author: Arnd Bergmann Date: Sat May 9 14:04:52 2020 +0200 net: freescale: select CONFIG_FIXED_PHY where needed [ Upstream commit 99352c79af3e5f2e4724abf37fa5a2a3299b1c81 ] I ran into a randconfig build failure with CONFIG_FIXED_PHY=m and CONFIG_GIANFAR=y: x86_64-linux-ld: drivers/net/ethernet/freescale/gianfar.o:(.rodata+0x418): undefined reference to `fixed_phy_change_carrier' It seems the same thing can happen with dpaa and ucc_geth, so change all three to do an explicit 'select FIXED_PHY'. The fixed-phy driver actually has an alternative stub function that theoretically allows building network drivers when fixed-phy is disabled, but I don't see how that would help here, as the drivers presumably would not work then. Signed-off-by: Arnd Bergmann Acked-by: Florian Fainelli Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 74037ef26835a948a4ce134ec8a6ea67b0ce52fe Author: Masahiro Yamada Date: Fri Apr 3 22:16:51 2020 +0900 usb: gadget: legacy: fix redundant initialization warnings [ Upstream commit d13cce757954fa663c69845611957396843ed87a ] Fix the following cppcheck warnings: drivers/usb/gadget/legacy/inode.c:1364:8: style: Redundant initialization for 'value'. The initialized value is overwritten$ value = -EOPNOTSUPP; ^ drivers/usb/gadget/legacy/inode.c:1331:15: note: value is initialized int value = -EOPNOTSUPP; ^ drivers/usb/gadget/legacy/inode.c:1364:8: note: value is overwritten value = -EOPNOTSUPP; ^ drivers/usb/gadget/legacy/inode.c:1817:8: style: Redundant initialization for 'value'. The initialized value is overwritten$ value = -EINVAL; ^ drivers/usb/gadget/legacy/inode.c:1787:18: note: value is initialized ssize_t value = len, length = len; ^ drivers/usb/gadget/legacy/inode.c:1817:8: note: value is overwritten value = -EINVAL; ^ Acked-by: Alan Stern Reported-by: kbuild test robot Signed-off-by: Masahiro Yamada Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e8a03e73cd14a2872339c4f51bbd11b798f12427 Author: Christophe JAILLET Date: Mon Apr 27 22:21:16 2020 +0200 usb: phy: twl6030-usb: Fix a resource leak in an error handling path in 'twl6030_usb_probe()' [ Upstream commit f058764d19000d98aef72010468db1f69faf9fa0 ] A call to 'regulator_get()' is hidden in 'twl6030_usb_ldo_init()'. A corresponding put must be performed in the error handling path, as already done in the remove function. While at it, also move a 'free_irq()' call in the error handling path in order to be consistent. Reviewed-by: Dan Carpenter Signed-off-by: Christophe JAILLET Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e02fe520c11b5bdae4e086af94ee421cbc69ed32 Author: Andy Shevchenko Date: Mon May 4 12:33:52 2020 +0300 usb: dwc3: pci: Enable extcon driver for Intel Merrifield [ Upstream commit 066c09593454e89bc605ffdff1c9810061f9b1e1 ] Intel Merrifield provides a DR support via PMIC which has its own extcon driver. Add a property string to link to that driver. Signed-off-by: Andy Shevchenko Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e1dfa986fda68faa063762711d05650a36497c5e Author: Lei Xue Date: Thu May 7 08:50:22 2020 -0400 cachefiles: Fix race between read_waiter and read_copier involving op->to_do [ Upstream commit 7bb0c5338436dae953622470d52689265867f032 ] There is a potential race in fscache operation enqueuing for reading and copying multiple pages from cachefiles to netfs. The problem can be seen easily on a heavy loaded system (for example many processes reading files continually on an NFS share covered by fscache triggered this problem within a few minutes). The race is due to cachefiles_read_waiter() adding the op to the monitor to_do list and then then drop the object->work_lock spinlock before completing fscache_enqueue_operation(). Once the lock is dropped, cachefiles_read_copier() grabs the op, completes processing it, and makes it through fscache_retrieval_complete() which sets the op->state to the final state of FSCACHE_OP_ST_COMPLETE(4). When cachefiles_read_waiter() finally gets through the remainder of fscache_enqueue_operation() it sees the invalid state, and hits the ASSERTCMP and the following oops is seen: [ 2259.612361] FS-Cache: [ 2259.614785] FS-Cache: Assertion failed [ 2259.618639] FS-Cache: 4 == 5 is false [ 2259.622456] ------------[ cut here ]------------ [ 2259.627190] kernel BUG at fs/fscache/operation.c:70! ... [ 2259.791675] RIP: 0010:[] [] fscache_enqueue_operation+0xff/0x170 [fscache] [ 2259.802059] RSP: 0000:ffffa0263d543be0 EFLAGS: 00010046 [ 2259.807521] RAX: 0000000000000019 RBX: ffffa01a4d390480 RCX: 0000000000000006 [ 2259.814847] RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffa0263d553890 [ 2259.822176] RBP: ffffa0263d543be8 R08: 0000000000000000 R09: ffffa0263c2d8708 [ 2259.829502] R10: 0000000000001e7f R11: 0000000000000000 R12: ffffa01a4d390480 [ 2259.844483] R13: ffff9fa9546c5920 R14: ffffa0263d543c80 R15: ffffa0293ff9bf10 [ 2259.859554] FS: 00007f4b6efbd700(0000) GS:ffffa0263d540000(0000) knlGS:0000000000000000 [ 2259.875571] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2259.889117] CR2: 00007f49e1624ff0 CR3: 0000012b38b38000 CR4: 00000000007607e0 [ 2259.904015] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2259.918764] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2259.933449] PKRU: 55555554 [ 2259.943654] Call Trace: [ 2259.953592] [ 2259.955577] [] cachefiles_read_waiter+0x92/0xf0 [cachefiles] [ 2259.978039] [] __wake_up_common+0x82/0x120 [ 2259.991392] [] __wake_up_common_lock+0x83/0xc0 [ 2260.004930] [] ? task_rq_unlock+0x20/0x20 [ 2260.017863] [] __wake_up+0x13/0x20 [ 2260.030230] [] __wake_up_bit+0x50/0x70 [ 2260.042535] [] unlock_page+0x2b/0x30 [ 2260.054495] [] page_endio+0x29/0x90 [ 2260.066184] [] mpage_end_io+0x51/0x80 CPU1 cachefiles_read_waiter() 20 static int cachefiles_read_waiter(wait_queue_entry_t *wait, unsigned mode, 21 int sync, void *_key) 22 { ... 61 spin_lock(&object->work_lock); 62 list_add_tail(&monitor->op_link, &op->to_do); 63 spin_unlock(&object->work_lock); 64 65 fscache_enqueue_retrieval(op); 182 static inline void fscache_enqueue_retrieval(struct fscache_retrieval *op) 183 { 184 fscache_enqueue_operation(&op->op); 185 } 58 void fscache_enqueue_operation(struct fscache_operation *op) 59 { 60 struct fscache_cookie *cookie = op->object->cookie; 61 62 _enter("{OBJ%x OP%x,%u}", 63 op->object->debug_id, op->debug_id, atomic_read(&op->usage)); 64 65 ASSERT(list_empty(&op->pend_link)); 66 ASSERT(op->processor != NULL); 67 ASSERT(fscache_object_is_available(op->object)); 68 ASSERTCMP(atomic_read(&op->usage), >, 0); CPU2 cachefiles_read_copier() 168 while (!list_empty(&op->to_do)) { ... 202 fscache_end_io(op, monitor->netfs_page, error); 203 put_page(monitor->netfs_page); 204 fscache_retrieval_complete(op, 1); CPU1 58 void fscache_enqueue_operation(struct fscache_operation *op) 59 { ... 69 ASSERTIFCMP(op->state != FSCACHE_OP_ST_IN_PROGRESS, 70 op->state, ==, FSCACHE_OP_ST_CANCELLED); Signed-off-by: Lei Xue Signed-off-by: Dave Wysochanski Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 336292c44f622565c4b9815dff975ea565b5e893 Author: Felix Kuehling Date: Tue May 5 14:02:43 2020 -0400 drm/amdgpu: Use GEM obj reference for KFD BOs [ Upstream commit 39b3128d7ffd44e400e581e6f49e88cb42bef9a1 ] Releasing the AMDGPU BO ref directly leads to problems when BOs were exported as DMA bufs. Releasing the GEM reference makes sure that the AMDGPU/TTM BO is not freed too early. Also take a GEM reference when importing BOs from DMABufs to keep references to imported BOs balances properly. Signed-off-by: Felix Kuehling Tested-by: Alex Sierra Acked-by: Christian König Reviewed-by: Alex Sierra Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2dd33d3175ef75b2ae7f3cad15e8e080ac685172 Author: Evan Quan Date: Thu Apr 30 14:38:39 2020 +0800 drm/amd/powerplay: perform PG ungate prior to CG ungate [ Upstream commit f4fcfa4282c1a1bf51475ebb0ffda623eebf1191 ] Since gfxoff should be disabled first before trying to access those GC registers. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4552f27f9d64dcde3bf92673df74e77b2aa78aad Author: Evan Quan Date: Thu Apr 30 11:24:02 2020 +0800 drm/amdgpu: drop unnecessary cancel_delayed_work_sync on PG ungate [ Upstream commit 1fe48ec08d9f2e26d893a6c05bd6c99a3490f9ef ] As this is already properly handled in amdgpu_gfx_off_ctrl(). In fact, this unnecessary cancel_delayed_work_sync may leave a small time window for race condition and is dangerous. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 49388448eda093d319b665a800444924aa14e423 Author: Andreas Gruenbacher Date: Tue May 5 11:56:46 2020 -0500 gfs2: Grab glock reference sooner in gfs2_add_revoke [ Upstream commit f4e2f5e1a527ce58fc9f85145b03704779a3123e ] This patch rearranges gfs2_add_revoke so that the extra glock reference is added earlier on in the function to avoid races in which the glock is freed before the new reference is taken. Signed-off-by: Andreas Gruenbacher Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit fd5516ea823923a70dc1f66c79f0356488d25f2d Author: Bob Peterson Date: Tue May 5 11:53:21 2020 -0500 gfs2: move privileged user check to gfs2_quota_lock_check [ Upstream commit 4ed0c30811cb4d30ef89850b787a53a84d5d2bcb ] Before this patch, function gfs2_quota_lock checked if it was called from a privileged user, and if so, it bypassed the quota check: superuser can operate outside the quotas. That's the wrong place for the check because the lock/unlock functions are separate from the lock_check function, and you can do lock and unlock without actually checking the quotas. This patch moves the check to gfs2_quota_lock_check. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit 02a76cd6bda6ca4b42026289a6dadd801d465763 Author: Chuhong Yuan Date: Thu May 7 23:13:20 2020 +0800 net: microchip: encx24j600: add missed kthread_stop [ Upstream commit ff8ce319e9c25e920d994cc35236f0bb32dfc8f3 ] This driver calls kthread_run() in probe, but forgets to call kthread_stop() in probe failure and remove. Add the missed kthread_stop() to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2578135aa8f08b91d1c80c4906cb22c6f66145e8 Author: Andrew Oakley Date: Sun May 3 15:16:39 2020 +0100 ALSA: usb-audio: add mapping for ASRock TRX40 Creator [ Upstream commit da7a8f1a8fc3e14c6dcc52b4098bddb8f20390be ] This is another TRX40 based motherboard with ALC1220-VB USB-audio that requires a static mapping table. This motherboard also has a PCI device which advertises no codecs. The PCI ID is 1022:1487 and PCI SSID is 1022:d102. As this is using the AMD vendor ID, don't blacklist for now in case other boards have a working audio device with the same ssid. alsa-info.sh report for this board: http://alsa-project.org/db/?f=0a742f89066527497b77ce16bca486daccf8a70c Signed-off-by: Andrew Oakley Link: https://lore.kernel.org/r/20200503141639.35519-1-andrew@adoakley.name Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 3e4e413c93f06f5fcc9a77bc91a0a4aa3c213502 Author: Stephen Warren Date: Mon Apr 27 17:26:05 2020 -0600 gpio: tegra: mask GPIO IRQs during IRQ shutdown [ Upstream commit 0cf253eed5d2bdf7bb3152457b38f39b012955f7 ] The driver currently leaves GPIO IRQs unmasked even when the GPIO IRQ client has released the GPIO IRQ. This allows the HW to raise IRQs, and SW to process them, after shutdown. Fix this by masking the IRQ when it's shut down. This is usually taken care of by the irqchip core, but since this driver has a custom irq_shutdown implementation, it must do this explicitly itself. Signed-off-by: Stephen Warren Link: https://lore.kernel.org/r/20200427232605.11608-1-swarren@wwwdotorg.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 6ff411af068c78daa77951a0a34a3634adf5aa97 Author: Johan Jonker Date: Fri Apr 24 14:39:23 2020 +0200 ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi [ Upstream commit 855bdca1781c79eb661f89c8944c4a719ce720e8 ] A test with the command below gives these errors: arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-0: '#address-cells' is a required property arch/arm/boot/dts/rk3229-evb.dt.yaml: spi-1: '#address-cells' is a required property arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-0: '#address-cells' is a required property arch/arm/boot/dts/rk3229-xms6.dt.yaml: spi-1: '#address-cells' is a required property The $nodename pattern for spi nodes is "^spi(@.*|-[0-9a-f])*$". To prevent warnings rename 'spi-0' and 'spi-1' pinctrl sub nodenames to 'spi0' and 'spi1' in 'rk322x.dtsi'. make ARCH=arm dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/spi/spi-controller.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200424123923.8192-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 881dc2e22fb9896a4c21de11f27b1c78dd80cc51 Author: Johan Jonker Date: Sat Apr 25 21:25:00 2020 +0200 ARM: dts: rockchip: swap clock-names of gpu nodes [ Upstream commit b14f3898d2c25a9b47a61fb879d0b1f3af92c59b ] Dts files with Rockchip 'gpu' nodes were manually verified. In order to automate this process arm,mali-utgard.txt has been converted to yaml. In the new setup dtbs_check with arm,mali-utgard.yaml expects clock-names values in the same order, so fix that. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200425192500.1808-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 96e88e683165227667c6fa0a6538af991a3f3674 Author: Johan Jonker Date: Sat Apr 25 16:38:37 2020 +0200 arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node [ Upstream commit c604fd810bda667bdc20b2c041917baa7803e0fb ] Dts files with Rockchip rk3399 'gpu' nodes were manually verified. In order to automate this process arm,mali-midgard.txt has been converted to yaml. In the new setup dtbs_check with arm,mali-midgard.yaml expects interrupts and interrupt-names values in the same order. Fix this for rk3399. make ARCH=arm64 dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/gpu/ arm,mali-midgard.yaml Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200425143837.18706-1-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit 9dc2e51ea7c135004a93a897acb9b31da015d0cf Author: Johan Jonker Date: Sat Apr 25 14:23:45 2020 +0200 arm64: dts: rockchip: fix status for &gmac2phy in rk3328-evb.dts [ Upstream commit c617ed88502d0b05149e7f32f3b3fd8a0663f7e2 ] The status was removed of the '&gmac2phy' node with the apply of a patch long time ago, so fix status for '&gmac2phy' in 'rk3328-evb.dts'. Signed-off-by: Johan Jonker Link: https://lore.kernel.org/r/20200425122345.12902-2-jbx6244@gmail.com Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin commit dd35a809c1589da1630bb099a26e66ac3c490e41 Author: Johan Jonker Date: Thu Apr 16 19:03:21 2020 +0200 ARM: dts: rockchip: fix phy nodename for rk3229-xms6 [ Upstream commit 621c8d0c233e260232278a4cfd3380caa3c1da29 ] A test with the command below gives for example this error: arch/arm/boot/dts/rk3229-xms6.dt.yaml: phy@0: '#phy-cells' is a required property The phy nodename is normally used by a phy-handle. This node is however compatible with "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22" which is just been added to 'ethernet-phy.yaml'. So change nodename to 'ethernet-phy' for which '#phy-cells' is not a required property make ARCH=arm dtbs_check DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/ phy/phy-provider.yaml Signed-off-by: Johan Jonker Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200416170321.4216-2-jbx6244@gmail.com Signed-off-by: Sasha Levin commit 203a45eb258c0612e027d9a3b0795aa256017e9e Author: Johan Jonker Date: Thu Apr 16 19:03:20 2020 +0200 ARM: dts: rockchip: fix phy nodename for rk3228-evb [ Upstream commit 287e0d538fcec2f6e8eb1e565bf0749f3b90186d ] A test with the command below gives for example this error: arch/arm/boot/dts/rk3228-evb.dt.yaml: phy@0: '#phy-cells' is a required property The phy nodename is normally used by a phy-handle. This node is however compatible with "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22" which is just been added to 'ethernet-phy.yaml'. So change nodename to 'ethernet-phy' for which '#phy-cells' is not a required property make ARCH=arm dtbs_check DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/ phy/phy-provider.yaml Signed-off-by: Johan Jonker Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200416170321.4216-1-jbx6244@gmail.com Signed-off-by: Sasha Levin commit c5b2233ad5f4f150eb7316587c9a306e0ec08d6e Author: Jiri Pirko Date: Thu May 21 15:11:44 2020 +0300 mlxsw: spectrum: Fix use-after-free of split/unsplit/type_set in case reload fails commit 4340f42f207eacb81e7a6b6bb1e3b6afad9a2e26 upstream. In case of reload fail, the mlxsw_sp->ports contains a pointer to a freed memory (either by reload_down() or reload_up() error path). Fix this by initializing the pointer to NULL and checking it before dereferencing in split/unsplit/type_set callpaths. Fixes: 24cc68ad6c46 ("mlxsw: core: Add support for reload") Reported-by: Danielle Ratson Signed-off-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 9aeacb829cad22892a176d6fcaa7ca8da6021b4e Author: Qiushi Wu Date: Fri May 22 14:07:15 2020 -0500 net/mlx4_core: fix a memory leak bug. commit febfd9d3c7f74063e8e630b15413ca91b567f963 upstream. In function mlx4_opreq_action(), pointer "mailbox" is not released, when mlx4_cmd_box() return and error, causing a memory leak bug. Fix this issue by going to "out" label, mlx4_free_cmd_mailbox() can free this pointer. Fixes: fe6f700d6cbb ("net/mlx4_core: Respond to operation request by firmware") Signed-off-by: Qiushi Wu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fcb4d5869e981738c5c3bd38a9a8fcdce8e012b6 Author: Qiushi Wu Date: Fri May 22 16:50:27 2020 -0500 net: sun: fix missing release regions in cas_init_one(). commit 5a730153984dd13f82ffae93d7170d76eba204e9 upstream. In cas_init_one(), "pdev" is requested by "pci_request_regions", but it was not released after a call of the function “pci_write_config_byte” failed. Thus replace the jump target “err_write_cacheline” by "err_out_free_res". Fixes: 1f26dac32057 ("[NET]: Add Sun Cassini driver.") Signed-off-by: Qiushi Wu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d12fc818b0d809893ced78d2aa58548b77a1af81 Author: Vadim Fedorenko Date: Wed May 20 11:41:44 2020 +0300 net/tls: free record only on encryption error commit 635d9398178659d8ddba79dd061f9451cec0b4d1 upstream. We cannot free record on any transient error because it leads to losing previos data. Check socket error to know whether record must be freed or not. Fixes: d10523d0b3d7 ("net/tls: free the record on encryption error") Signed-off-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cff9e73a34a2a4c087966cf781e1e5eba64f55ca Author: Vadim Fedorenko Date: Wed May 20 11:41:43 2020 +0300 net/tls: fix encryption error checking commit a7bff11f6f9afa87c25711db8050c9b5324db0e2 upstream. bpf_exec_tx_verdict() can return negative value for copied variable. In that case this value will be pushed back to caller and the real error code will be lost. Fix it using signed type and checking for positive value. Fixes: d10523d0b3d7 ("net/tls: free the record on encryption error") Fixes: d3b18ad31f93 ("tls: add bpf support to sk_msg handling") Signed-off-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f4f034a8676e366857861e76c3ad11ae059b2fb Author: Roi Dayan Date: Thu May 14 23:44:38 2020 +0300 net/mlx5: Annotate mutex destroy for root ns commit 9ca415399dae133b00273a4283ef31d003a6818d upstream. Invoke mutex_destroy() to catch any errors. Fixes: 2cc43b494a6c ("net/mlx5_core: Managing root flow table") Signed-off-by: Roi Dayan Reviewed-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit f493398fe0f7dff5d29759c90917d05e88cb3059 Author: Shay Drory Date: Wed May 6 14:52:04 2020 +0300 net/mlx5: Fix error flow in case of function_setup failure [ Upstream commit 4f7400d5cbaef676e00cdffb0565bf731c6bb09e ] Currently, if an error occurred during mlx5_function_setup(), we keep dev->state as DEVICE_STATE_UP. Fixing it by adding a goto label. Fixes: e161105e58da ("net/mlx5: Function setup/teardown procedures") Signed-off-by: Shay Drory Reviewed-by: Moshe Shemesh Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 9fe88c9408280db896ebf48ad5f725f68e0ce822 Author: Moshe Shemesh Date: Tue Apr 7 17:38:28 2020 +0300 net/mlx5e: Update netdev txq on completions during closure [ Upstream commit 5e911e2c06bd8c17df29147a5e2d4b17fafda024 ] On sq closure when we free its descriptors, we should also update netdev txq on completions which would not arrive. Otherwise if we reopen sqs and attach them back, for example on fw fatal recovery flow, we may get tx timeout. Fixes: 29429f3300a3 ("net/mlx5e: Timeout if SQ doesn't flush during close") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 02c97e838597d6c1ce5e0ffaa46c83720beaab13 Author: Moshe Shemesh Date: Wed Apr 29 23:56:58 2020 +0300 net/mlx5: Fix memory leak in mlx5_events_init [ Upstream commit df14ad1eccb04a4a28c90389214dbacab085b244 ] Fix memory leak in mlx5_events_init(), in case create_single_thread_workqueue() fails, events struct should be freed. Fixes: 5d3c537f9070 ("net/mlx5: Handle event of power detection in the PCIE slot") Signed-off-by: Moshe Shemesh Reviewed-by: Tariq Toukan Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit e23f88f7e73016a6e022b3b89e34dd1ce05c80c9 Author: Roi Dayan Date: Thu Apr 30 09:16:01 2020 +0300 net/mlx5e: Fix inner tirs handling [ Upstream commit a16b8e0dcf7043bee46174bed0553cc9e36b63a5 ] In the cited commit inner_tirs argument was added to create and destroy inner tirs, and no indication was added to mlx5e_modify_tirs_hash() function. In order to have a consistent handling, use inner_indir_tir[0].tirn in tirs destroy/modify function as an indication to whether inner tirs are created. Inner tirs are not created for representors and before this commit, a call to mlx5e_modify_tirs_hash() was sending HW commands to modify non-existent inner tirs. Fixes: 46dc933cee82 ("net/mlx5e: Provide explicit directive if to create inner indirect tirs") Signed-off-by: Roi Dayan Reviewed-by: Vlad Buslov Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit f9e2700f34ec2c23b4de89cbd09d22d879753d83 Author: Tariq Toukan Date: Mon Apr 27 16:56:59 2020 +0300 net/mlx5e: kTLS, Destroy key object after destroying the TIS [ Upstream commit 16736e11f43b80a38f98f6add54fab3b8c297df3 ] The TLS TIS object contains the dek/key ID. By destroying the key first, the TIS would contain an invalid non-existing key ID. Reverse the destroy order, this also acheives the desired assymetry between the destroy and the create flows. Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support") Signed-off-by: Tariq Toukan Reviewed-by: Boris Pismenny Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 8c9df6ced1f95970254d2e912dc7c678c2d9de02 Author: Eric Dumazet Date: Thu May 21 11:29:58 2020 -0700 tipc: block BH before using dst_cache [ Upstream commit 1378817486d6860f6a927f573491afe65287abf1 ] dst_cache_get() documents it must be used with BH disabled. sysbot reported : BUG: using smp_processor_id() in preemptible [00000000] code: /21697 caller is dst_cache_get+0x3a/0xb0 net/core/dst_cache.c:68 CPU: 0 PID: 21697 Comm: Not tainted 5.7.0-rc6-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+0x188/0x20d lib/dump_stack.c:118 check_preemption_disabled lib/smp_processor_id.c:47 [inline] debug_smp_processor_id.cold+0x88/0x9b lib/smp_processor_id.c:57 dst_cache_get+0x3a/0xb0 net/core/dst_cache.c:68 tipc_udp_xmit.isra.0+0xb9/0xad0 net/tipc/udp_media.c:164 tipc_udp_send_msg+0x3e6/0x490 net/tipc/udp_media.c:244 tipc_bearer_xmit_skb+0x1de/0x3f0 net/tipc/bearer.c:526 tipc_enable_bearer+0xb2f/0xd60 net/tipc/bearer.c:331 __tipc_nl_bearer_enable+0x2bf/0x390 net/tipc/bearer.c:995 tipc_nl_bearer_enable+0x1e/0x30 net/tipc/bearer.c:1003 genl_family_rcv_msg_doit net/netlink/genetlink.c:673 [inline] genl_family_rcv_msg net/netlink/genetlink.c:718 [inline] genl_rcv_msg+0x627/0xdf0 net/netlink/genetlink.c:735 netlink_rcv_skb+0x15a/0x410 net/netlink/af_netlink.c:2469 genl_rcv+0x24/0x40 net/netlink/genetlink.c:746 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline] netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329 netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 ____sys_sendmsg+0x6bf/0x7e0 net/socket.c:2362 ___sys_sendmsg+0x100/0x170 net/socket.c:2416 __sys_sendmsg+0xec/0x1b0 net/socket.c:2449 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295 entry_SYSCALL_64_after_hwframe+0x49/0xb3 RIP: 0033:0x45ca29 Fixes: e9c1a793210f ("tipc: add dst_cache support for udp media") Cc: Xin Long Cc: Jon Maloy Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5398c7ff2347b0a6e5bb0f8804693b1088d3f4bb Author: Jere Leppänen Date: Wed May 20 18:15:31 2020 +0300 sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed [ Upstream commit d3e8e4c11870413789f029a71e72ae6e971fe678 ] Commit bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.") starts shutdown when an association is restarted, if in SHUTDOWN-PENDING state and the socket is closed. However, the rationale stated in that commit applies also when in SHUTDOWN-SENT state - we don't want to move an association to ESTABLISHED state when the socket has been closed, because that results in an association that is unreachable from user space. The problem scenario: 1. Client crashes and/or restarts. 2. Server (using one-to-one socket) calls close(). SHUTDOWN is lost. 3. Client reconnects using the same addresses and ports. 4. Server's association is restarted. The association and the socket move to ESTABLISHED state, even though the server process has closed its descriptor. Also, after step 4 when the server process exits, some resources are leaked in an attempt to release the underlying inet sock structure in ESTABLISHED state: IPv4: Attempt to release TCP socket in state 1 00000000377288c7 Fix by acting the same way as in SHUTDOWN-PENDING state. That is, if an association is restarted in SHUTDOWN-SENT state and the socket is closed, then start shutdown and don't move the association or the socket to ESTABLISHED state. Fixes: bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.") Signed-off-by: Jere Leppänen Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 70989e501fbce502198d82da88358ce453575a05 Author: Neil Horman Date: Tue May 19 16:04:05 2020 -0400 sctp: Don't add the shutdown timer if its already been added [ Upstream commit 20a785aa52c82246055a089e55df9dac47d67da1 ] This BUG halt was reported a while back, but the patch somehow got missed: PID: 2879 TASK: c16adaa0 CPU: 1 COMMAND: "sctpn" #0 [f418dd28] crash_kexec at c04a7d8c #1 [f418dd7c] oops_end at c0863e02 #2 [f418dd90] do_invalid_op at c040aaca #3 [f418de28] error_code (via invalid_op) at c08631a5 EAX: f34baac0 EBX: 00000090 ECX: f418deb0 EDX: f5542950 EBP: 00000000 DS: 007b ESI: f34ba800 ES: 007b EDI: f418dea0 GS: 00e0 CS: 0060 EIP: c046fa5e ERR: ffffffff EFLAGS: 00010286 #4 [f418de5c] add_timer at c046fa5e #5 [f418de68] sctp_do_sm at f8db8c77 [sctp] #6 [f418df30] sctp_primitive_SHUTDOWN at f8dcc1b5 [sctp] #7 [f418df48] inet_shutdown at c080baf9 #8 [f418df5c] sys_shutdown at c079eedf #9 [f418df70] sys_socketcall at c079fe88 EAX: ffffffda EBX: 0000000d ECX: bfceea90 EDX: 0937af98 DS: 007b ESI: 0000000c ES: 007b EDI: b7150ae4 SS: 007b ESP: bfceea7c EBP: bfceeaa8 GS: 0033 CS: 0073 EIP: b775c424 ERR: 00000066 EFLAGS: 00000282 It appears that the side effect that starts the shutdown timer was processed multiple times, which can happen as multiple paths can trigger it. This of course leads to the BUG halt in add_timer getting called. Fix seems pretty straightforward, just check before the timer is added if its already been started. If it has mod the timer instead to min(current expiration, new expiration) Its been tested but not confirmed to fix the problem, as the issue has only occured in production environments where test kernels are enjoined from being installed. It appears to be a sane fix to me though. Also, recentely, Jere found a reproducer posted on list to confirm that this resolves the issues Signed-off-by: Neil Horman CC: Vlad Yasevich CC: "David S. Miller" CC: jere.leppanen@nokia.com CC: marcelo.leitner@gmail.com CC: netdev@vger.kernel.org Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 34036769c84bf5eb479351463d26e77562de3071 Author: Marc Payne Date: Tue May 19 19:01:46 2020 +0100 r8152: support additional Microsoft Surface Ethernet Adapter variant [ Upstream commit c27a204383616efba5a4194075e90819961ff66a ] Device id 0927 is the RTL8153B-based component of the 'Surface USB-C to Ethernet and USB Adapter' and may be used as a component of other devices in future. Tested and working with the r8152 driver. Update the cdc_ether blacklist due to the RTL8153 'network jam on suspend' issue which this device will cause (personally confirmed). Signed-off-by: Marc Payne Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 983fa2e7740f3f2ac1d81c608eefd4e1e3d09c6d Author: David Ahern Date: Sun May 17 11:26:32 2020 -0600 nexthop: Fix attribute checking for groups [ Upstream commit 84be69b869a5a496a6cfde9b3c29509207a1f1fa ] For nexthop groups, attributes after NHA_GROUP_TYPE are invalid, but nh_check_attr_group starts checking at NHA_GROUP. The group type defaults to multipath and the NHA_GROUP_TYPE is currently optional so this has slipped through so far. Fix the attribute checking to handle support of new group types. Fixes: 430a049190de ("nexthop: Add support for nexthop groups") Signed-off-by: ASSOGBA Emery Signed-off-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cf4cc95a15f599560c7abd89095a7973a4b9cec3 Author: Vinay Kumar Yadav Date: Sat May 23 01:40:31 2020 +0530 net/tls: fix race condition causing kernel panic [ Upstream commit 0cada33241d9de205522e3858b18e506ca5cce2c ] tls_sw_recvmsg() and tls_decrypt_done() can be run concurrently. // tls_sw_recvmsg() if (atomic_read(&ctx->decrypt_pending)) crypto_wait_req(-EINPROGRESS, &ctx->async_wait); else reinit_completion(&ctx->async_wait.completion); //tls_decrypt_done() pending = atomic_dec_return(&ctx->decrypt_pending); if (!pending && READ_ONCE(ctx->async_notify)) complete(&ctx->async_wait.completion); Consider the scenario tls_decrypt_done() is about to run complete() if (!pending && READ_ONCE(ctx->async_notify)) and tls_sw_recvmsg() reads decrypt_pending == 0, does reinit_completion(), then tls_decrypt_done() runs complete(). This sequence of execution results in wrong completion. Consequently, for next decrypt request, it will not wait for completion, eventually on connection close, crypto resources freed, there is no way to handle pending decrypt response. This race condition can be avoided by having atomic_read() mutually exclusive with atomic_dec_return(),complete().Intoduced spin lock to ensure the mutual exclution. Addressed similar problem in tx direction. v1->v2: - More readable commit message. - Corrected the lock to fix new race scenario. - Removed barrier which is not needed now. Fixes: a42055e8d2c3 ("net/tls: Add support for async encryption of records for performance") Signed-off-by: Vinay Kumar Yadav Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 587e13469cfd73bc8e0f2b0810cf0cb9e3fe0521 Author: Roman Mashak Date: Sun May 17 08:46:31 2020 -0400 net sched: fix reporting the first-time use timestamp [ Upstream commit b15e62631c5f19fea9895f7632dae9c1b27fe0cd ] When a new action is installed, firstuse field of 'tcf_t' is explicitly set to 0. Value of zero means "new action, not yet used"; as a packet hits the action, 'firstuse' is stamped with the current jiffies value. tcf_tm_dump() should return 0 for firstuse if action has not yet been hit. Fixes: 48d8ee1694dd ("net sched actions: aggregate dumping of actions timeinfo") Cc: Jamal Hadi Salim Signed-off-by: Roman Mashak Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f12398120522d2cddd061d8de12d57e970595b5a Author: Yuqi Jin Date: Sat May 16 11:46:49 2020 +0800 net: revert "net: get rid of an signed integer overflow in ip_idents_reserve()" [ Upstream commit a6211caa634da39d861a47437ffcda8b38ef421b ] Commit adb03115f459 ("net: get rid of an signed integer overflow in ip_idents_reserve()") used atomic_cmpxchg to replace "atomic_add_return" inside the function "ip_idents_reserve". The reason was to avoid UBSAN warning. However, this change has caused performance degrade and in GCC-8, fno-strict-overflow is now mapped to -fwrapv -fwrapv-pointer and signed integer overflow is now undefined by default at all optimization levels[1]. Moreover, it was a bug in UBSAN vs -fwrapv /-fno-strict-overflow, so Let's revert it safely. [1] https://gcc.gnu.org/gcc-8/changes.html Suggested-by: Peter Zijlstra Suggested-by: Eric Dumazet Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: Hideaki YOSHIFUJI Cc: Jakub Kicinski Cc: Jiri Pirko Cc: Arvind Sankar Cc: Peter Zijlstra Cc: Eric Dumazet Cc: Jiong Wang Signed-off-by: Yuqi Jin Signed-off-by: Shaokun Zhang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 83588bf1dd55eb5c21b906cc51ada8a297fdd180 Author: Manivannan Sadhasivam Date: Tue May 19 23:44:16 2020 +0530 net: qrtr: Fix passing invalid reference to qrtr_local_enqueue() [ Upstream commit d28ea1fbbf437054ef339afec241019f2c4e2bb6 ] Once the traversal of the list is completed with list_for_each_entry(), the iterator (node) will point to an invalid object. So passing this to qrtr_local_enqueue() which is outside of the iterator block is erroneous eventhough the object is not used. So fix this by passing NULL to qrtr_local_enqueue(). Fixes: bdabad3e363d ("net: Add Qualcomm IPC router") Reported-by: kbuild test robot Reported-by: Julia Lawall Signed-off-by: Manivannan Sadhasivam Reviewed-by: Bjorn Andersson Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7e0e066df34a11710941115b4f932534bb86bed5 Author: Stephen Worley Date: Tue May 19 21:57:12 2020 -0400 net: nlmsg_cancel() if put fails for nhmsg [ Upstream commit d69100b8eee27c2d60ee52df76e0b80a8d492d34 ] Fixes data remnant seen when we fail to reserve space for a nexthop group during a larger dump. If we fail the reservation, we goto nla_put_failure and cancel the message. Reproduce with the following iproute2 commands: ===================== ip link add dummy1 type dummy ip link add dummy2 type dummy ip link add dummy3 type dummy ip link add dummy4 type dummy ip link add dummy5 type dummy ip link add dummy6 type dummy ip link add dummy7 type dummy ip link add dummy8 type dummy ip link add dummy9 type dummy ip link add dummy10 type dummy ip link add dummy11 type dummy ip link add dummy12 type dummy ip link add dummy13 type dummy ip link add dummy14 type dummy ip link add dummy15 type dummy ip link add dummy16 type dummy ip link add dummy17 type dummy ip link add dummy18 type dummy ip link add dummy19 type dummy ip link add dummy20 type dummy ip link add dummy21 type dummy ip link add dummy22 type dummy ip link add dummy23 type dummy ip link add dummy24 type dummy ip link add dummy25 type dummy ip link add dummy26 type dummy ip link add dummy27 type dummy ip link add dummy28 type dummy ip link add dummy29 type dummy ip link add dummy30 type dummy ip link add dummy31 type dummy ip link add dummy32 type dummy ip link set dummy1 up ip link set dummy2 up ip link set dummy3 up ip link set dummy4 up ip link set dummy5 up ip link set dummy6 up ip link set dummy7 up ip link set dummy8 up ip link set dummy9 up ip link set dummy10 up ip link set dummy11 up ip link set dummy12 up ip link set dummy13 up ip link set dummy14 up ip link set dummy15 up ip link set dummy16 up ip link set dummy17 up ip link set dummy18 up ip link set dummy19 up ip link set dummy20 up ip link set dummy21 up ip link set dummy22 up ip link set dummy23 up ip link set dummy24 up ip link set dummy25 up ip link set dummy26 up ip link set dummy27 up ip link set dummy28 up ip link set dummy29 up ip link set dummy30 up ip link set dummy31 up ip link set dummy32 up ip link set dummy33 up ip link set dummy34 up ip link set vrf-red up ip link set vrf-blue up ip link set dummyVRFred up ip link set dummyVRFblue up ip ro add 1.1.1.1/32 dev dummy1 ip ro add 1.1.1.2/32 dev dummy2 ip ro add 1.1.1.3/32 dev dummy3 ip ro add 1.1.1.4/32 dev dummy4 ip ro add 1.1.1.5/32 dev dummy5 ip ro add 1.1.1.6/32 dev dummy6 ip ro add 1.1.1.7/32 dev dummy7 ip ro add 1.1.1.8/32 dev dummy8 ip ro add 1.1.1.9/32 dev dummy9 ip ro add 1.1.1.10/32 dev dummy10 ip ro add 1.1.1.11/32 dev dummy11 ip ro add 1.1.1.12/32 dev dummy12 ip ro add 1.1.1.13/32 dev dummy13 ip ro add 1.1.1.14/32 dev dummy14 ip ro add 1.1.1.15/32 dev dummy15 ip ro add 1.1.1.16/32 dev dummy16 ip ro add 1.1.1.17/32 dev dummy17 ip ro add 1.1.1.18/32 dev dummy18 ip ro add 1.1.1.19/32 dev dummy19 ip ro add 1.1.1.20/32 dev dummy20 ip ro add 1.1.1.21/32 dev dummy21 ip ro add 1.1.1.22/32 dev dummy22 ip ro add 1.1.1.23/32 dev dummy23 ip ro add 1.1.1.24/32 dev dummy24 ip ro add 1.1.1.25/32 dev dummy25 ip ro add 1.1.1.26/32 dev dummy26 ip ro add 1.1.1.27/32 dev dummy27 ip ro add 1.1.1.28/32 dev dummy28 ip ro add 1.1.1.29/32 dev dummy29 ip ro add 1.1.1.30/32 dev dummy30 ip ro add 1.1.1.31/32 dev dummy31 ip ro add 1.1.1.32/32 dev dummy32 ip next add id 1 via 1.1.1.1 dev dummy1 ip next add id 2 via 1.1.1.2 dev dummy2 ip next add id 3 via 1.1.1.3 dev dummy3 ip next add id 4 via 1.1.1.4 dev dummy4 ip next add id 5 via 1.1.1.5 dev dummy5 ip next add id 6 via 1.1.1.6 dev dummy6 ip next add id 7 via 1.1.1.7 dev dummy7 ip next add id 8 via 1.1.1.8 dev dummy8 ip next add id 9 via 1.1.1.9 dev dummy9 ip next add id 10 via 1.1.1.10 dev dummy10 ip next add id 11 via 1.1.1.11 dev dummy11 ip next add id 12 via 1.1.1.12 dev dummy12 ip next add id 13 via 1.1.1.13 dev dummy13 ip next add id 14 via 1.1.1.14 dev dummy14 ip next add id 15 via 1.1.1.15 dev dummy15 ip next add id 16 via 1.1.1.16 dev dummy16 ip next add id 17 via 1.1.1.17 dev dummy17 ip next add id 18 via 1.1.1.18 dev dummy18 ip next add id 19 via 1.1.1.19 dev dummy19 ip next add id 20 via 1.1.1.20 dev dummy20 ip next add id 21 via 1.1.1.21 dev dummy21 ip next add id 22 via 1.1.1.22 dev dummy22 ip next add id 23 via 1.1.1.23 dev dummy23 ip next add id 24 via 1.1.1.24 dev dummy24 ip next add id 25 via 1.1.1.25 dev dummy25 ip next add id 26 via 1.1.1.26 dev dummy26 ip next add id 27 via 1.1.1.27 dev dummy27 ip next add id 28 via 1.1.1.28 dev dummy28 ip next add id 29 via 1.1.1.29 dev dummy29 ip next add id 30 via 1.1.1.30 dev dummy30 ip next add id 31 via 1.1.1.31 dev dummy31 ip next add id 32 via 1.1.1.32 dev dummy32 i=100 while [ $i -le 200 ] do ip next add id $i group 1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19 echo $i ((i++)) done ip next add id 999 group 1/2/3/4/5/6 ip next ls ======================== Fixes: ab84be7e54fc ("net: Initial nexthop code") Signed-off-by: Stephen Worley Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 84e91312ad9a0e9336ae4a79d17e2cef3dd4465e Author: Russell King Date: Wed May 20 12:26:35 2020 +0100 net: mvpp2: fix RX hashing for non-10G ports [ Upstream commit 3138a07ce219acde4c0d7ea0b6d54ba64153328b ] When rxhash is enabled on any ethernet port except the first in each CP block, traffic flow is prevented. The analysis is below: I've been investigating this afternoon, and what I've found, comparing a kernel without 895586d5dc32 and with 895586d5dc32 applied is: - The table programmed into the hardware via mvpp22_rss_fill_table() appears to be identical with or without the commit. - When rxhash is enabled on eth2, mvpp2_rss_port_c2_enable() reports that c2.attr[0] and c2.attr[2] are written back containing: - with 895586d5dc32, failing: 00200000 40000000 - without 895586d5dc32, working: 04000000 40000000 - When disabling rxhash, c2.attr[0] and c2.attr[2] are written back as: 04000000 00000000 The second value represents the MVPP22_CLS_C2_ATTR2_RSS_EN bit, the first value is the queue number, which comprises two fields. The high 5 bits are 24:29 and the low three are 21:23 inclusive. This comes from: c2.attr[0] = MVPP22_CLS_C2_ATTR0_QHIGH(qh) | MVPP22_CLS_C2_ATTR0_QLOW(ql); So, the working case gives eth2 a queue id of 4.0, or 32 as per port->first_rxq, and the non-working case a queue id of 0.1, or 1. The allocation of queue IDs seems to be in mvpp2_port_probe(): if (priv->hw_version == MVPP21) port->first_rxq = port->id * port->nrxqs; else port->first_rxq = port->id * priv->max_port_rxqs; Where: if (priv->hw_version == MVPP21) priv->max_port_rxqs = 8; else priv->max_port_rxqs = 32; Making the port 0 (eth0 / eth1) have port->first_rxq = 0, and port 1 (eth2) be 32. It seems the idea is that the first 32 queues belong to port 0, the second 32 queues belong to port 1, etc. mvpp2_rss_port_c2_enable() gets the queue number from it's parameter, 'ctx', which comes from mvpp22_rss_ctx(port, 0). This returns port->rss_ctx[0]. mvpp22_rss_context_create() is responsible for allocating that, which it does by looking for an unallocated priv->rss_tables[] pointer. This table is shared amongst all ports on the CP silicon. When we write the tables in mvpp22_rss_fill_table(), the RSS table entry is defined by: u32 sel = MVPP22_RSS_INDEX_TABLE(rss_ctx) | MVPP22_RSS_INDEX_TABLE_ENTRY(i); where rss_ctx is the context ID (queue number) and i is the index in the table. If we look at what is written: - The first table to be written has "sel" values of 00000000..0000001f, containing values 0..3. This appears to be for eth1. This is table 0, RX queue number 0. - The second table has "sel" values of 00000100..0000011f, and appears to be for eth2. These contain values 0x20..0x23. This is table 1, RX queue number 0. - The third table has "sel" values of 00000200..0000021f, and appears to be for eth3. These contain values 0x40..0x43. This is table 2, RX queue number 0. How do queue numbers translate to the RSS table? There is another table - the RXQ2RSS table, indexed by the MVPP22_RSS_INDEX_QUEUE field of MVPP22_RSS_INDEX and accessed through the MVPP22_RXQ2RSS_TABLE register. Before 895586d5dc32, it was: mvpp2_write(priv, MVPP22_RSS_INDEX, MVPP22_RSS_INDEX_QUEUE(port->first_rxq)); mvpp2_write(priv, MVPP22_RXQ2RSS_TABLE, MVPP22_RSS_TABLE_POINTER(port->id)); and after: mvpp2_write(priv, MVPP22_RSS_INDEX, MVPP22_RSS_INDEX_QUEUE(ctx)); mvpp2_write(priv, MVPP22_RXQ2RSS_TABLE, MVPP22_RSS_TABLE_POINTER(ctx)); Before the commit, for eth2, that would've contained '32' for the index and '1' for the table pointer - mapping queue 32 to table 1. Remember that this is queue-high.queue-low of 4.0. After the commit, we appear to map queue 1 to table 1. That again looks fine on the face of it. Section 9.3.1 of the A8040 manual seems indicate the reason that the queue number is separated. queue-low seems to always come from the classifier, whereas queue-high can be from the ingress physical port number or the classifier depending on the MVPP2_CLS_SWFWD_PCTRL_REG. We set the port bit in MVPP2_CLS_SWFWD_PCTRL_REG, meaning that queue-high comes from the MVPP2_CLS_SWFWD_P2HQ_REG() register... and this seems to be where our bug comes from. mvpp2_cls_oversize_rxq_set() sets this up as: mvpp2_write(port->priv, MVPP2_CLS_SWFWD_P2HQ_REG(port->id), (port->first_rxq >> MVPP2_CLS_OVERSIZE_RXQ_LOW_BITS)); val = mvpp2_read(port->priv, MVPP2_CLS_SWFWD_PCTRL_REG); val |= MVPP2_CLS_SWFWD_PCTRL_MASK(port->id); mvpp2_write(port->priv, MVPP2_CLS_SWFWD_PCTRL_REG, val); Setting the MVPP2_CLS_SWFWD_PCTRL_MASK bit means that the queue-high for eth2 is _always_ 4, so only queues 32 through 39 inclusive are available to eth2. Yet, we're trying to tell the classifier to set queue-high, which will be ignored, to zero. Hence, the queue-high field (MVPP22_CLS_C2_ATTR0_QHIGH()) from the classifier will be ignored. This means we end up directing traffic from eth2 not to queue 1, but to queue 33, and then we tell it to look up queue 33 in the RSS table. However, RSS table has not been programmed for queue 33, and so it ends up (presumably) dropping the packets. It seems that mvpp22_rss_context_create() doesn't take account of the fact that the upper 5 bits of the queue ID can't actually be changed due to the settings in mvpp2_cls_oversize_rxq_set(), _or_ it seems that mvpp2_cls_oversize_rxq_set() has been missed in this commit. Either way, these two functions mutually disagree with what queue number should be used. Looking deeper into what mvpp2_cls_oversize_rxq_set() and the MTU validation is doing, it seems that MVPP2_CLS_SWFWD_P2HQ_REG() is used for over-sized packets attempting to egress through this port. With the classifier having had RSS enabled and directing eth2 traffic to queue 1, we may still have packets appearing on queue 32 for this port. However, the only way we may end up with over-sized packets attempting to egress through eth2 - is if the A8040 forwards frames between its ports. From what I can see, we don't support that feature, and the kernel restricts the egress packet size to the MTU. In any case, if we were to attempt to transmit an oversized packet, we have no support in the kernel to deal with that appearing in the port's receive queue. So, this patch attempts to solve the issue by clearing the MVPP2_CLS_SWFWD_PCTRL_MASK() bit, allowing MVPP22_CLS_C2_ATTR0_QHIGH() from the classifier to define the queue-high field of the queue number. My testing seems to confirm my findings above - clearing this bit means that if I enable rxhash on eth2, the interface can then pass traffic, as we are now directing traffic to RX queue 1 rather than queue 33. Traffic still seems to work with rxhash off as well. Reported-by: Matteo Croce Tested-by: Matteo Croce Fixes: 895586d5dc32 ("net: mvpp2: cls: Use RSS contexts to handle RSS tables") Signed-off-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 212bcf1039a95e4d6a0aead7ffff975526fe613a Author: Moshe Shemesh Date: Fri Dec 27 07:01:53 2019 +0200 net/mlx5: Add command entry handling completion [ Upstream commit 17d00e839d3b592da9659c1977d45f85b77f986a ] When FW response to commands is very slow and all command entries in use are waiting for completion we can have a race where commands can get timeout before they get out of the queue and handled. Timeout completion on uninitialized command will cause releasing command's buffers before accessing it for initialization and then we will get NULL pointer exception while trying access it. It may also cause releasing buffers of another command since we may have timeout completion before even allocating entry index for this command. Add entry handling completion to avoid this race. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by: Moshe Shemesh Signed-off-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit a9595d1c60a78a7127b3ba84ec0dbf892cab5fac Author: Vadim Fedorenko Date: Wed May 20 11:50:48 2020 +0300 net: ipip: fix wrong address family in init error path [ Upstream commit 57ebc8f08504f176eb0f25b3e0fde517dec61a4f ] In case of error with MPLS support the code is misusing AF_INET instead of AF_MPLS. Fixes: 1b69e7e6c4da ("ipip: support MPLS over IPv4") Signed-off-by: Vadim Fedorenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4d827edb8f4e39f3edf26f65baf177faef2e8543 Author: Martin KaFai Lau Date: Mon May 18 17:13:34 2020 -0700 net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* [ Upstream commit 88d7fcfa3b1fe670f0412b95be785aafca63352b ] The commit 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk") added a bind-address cache in tb->fast*. The tb->fast* caches the address of a sk which has successfully been binded with SO_REUSEPORT ON. The idea is to avoid the expensive conflict search in inet_csk_bind_conflict(). There is an issue with wildcard matching where sk_reuseport_match() should have returned false but it is currently returning true. It ends up hiding bind conflict. For example, bind("[::1]:443"); /* without SO_REUSEPORT. Succeed. */ bind("[::2]:443"); /* with SO_REUSEPORT. Succeed. */ bind("[::]:443"); /* with SO_REUSEPORT. Still Succeed where it shouldn't */ The last bind("[::]:443") with SO_REUSEPORT on should have failed because it should have a conflict with the very first bind("[::1]:443") which has SO_REUSEPORT off. However, the address "[::2]" is cached in tb->fast* in the second bind. In the last bind, the sk_reuseport_match() returns true because the binding sk's wildcard addr "[::]" matches with the "[::2]" cached in tb->fast*. The correct bind conflict is reported by removing the second bind such that tb->fast* cache is not involved and forces the bind("[::]:443") to go through the inet_csk_bind_conflict(): bind("[::1]:443"); /* without SO_REUSEPORT. Succeed. */ bind("[::]:443"); /* with SO_REUSEPORT. -EADDRINUSE */ The expected behavior for sk_reuseport_match() is, it should only allow the "cached" tb->fast* address to be used as a wildcard match but not the address of the binding sk. To do that, the current "bool match_wildcard" arg is split into "bool match_sk1_wildcard" and "bool match_sk2_wildcard". This change only affects the sk_reuseport_match() which is only used by inet_csk (e.g. TCP). The other use cases are calling inet_rcv_saddr_equal() and this patch makes it pass the same "match_wildcard" arg twice to the "ipv[46]_rcv_saddr_equal(..., match_wildcard, match_wildcard)". Cc: Josef Bacik Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk") Signed-off-by: Martin KaFai Lau Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b51eb49d9a5dc8c6366f34d0fb89e53d8cc5d1a0 Author: Boris Sukholitko Date: Tue May 19 10:32:37 2020 +0300 __netif_receive_skb_core: pass skb by reference [ Upstream commit c0bbbdc32febd4f034ecbf3ea17865785b2c0652 ] __netif_receive_skb_core may change the skb pointer passed into it (e.g. in rx_handler). The original skb may be freed as a result of this operation. The callers of __netif_receive_skb_core may further process original skb by using pt_prev pointer returned by __netif_receive_skb_core thus leading to unpleasant effects. The solution is to pass skb by reference into __netif_receive_skb_core. v2: Added Fixes tag and comment regarding ppt_prev and skb invariant. Fixes: 88eb1944e18c ("net: core: propagate SKB lists through packet_type lookup") Signed-off-by: Boris Sukholitko Acked-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 53cf25df80c734ab323761eae9c36fddab8da362 Author: Grygorii Strashko Date: Fri May 22 20:09:28 2020 +0300 net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during suspend [ Upstream commit 4c64b83d03f4aafcdf710caad994cbc855802e74 ] vlan_for_each() are required to be called with rtnl_lock taken, otherwise ASSERT_RTNL() warning will be triggered - which happens now during System resume from suspend: cpsw_suspend() |- cpsw_ndo_stop() |- __hw_addr_ref_unsync_dev() |- cpsw_purge_all_mc() |- vlan_for_each() |- ASSERT_RTNL(); Hence, fix it by surrounding cpsw_ndo_stop() by rtnl_lock/unlock() calls. Fixes: 15180eca569b ("net: ethernet: ti: cpsw: fix vlan mcast") Signed-off-by: Grygorii Strashko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 557045f771e26e67f245c0b34461326133c4c841 Author: DENG Qingfang Date: Wed May 13 23:10:16 2020 +0800 net: dsa: mt7530: fix roaming from DSA user ports [ Upstream commit 5e5502e012b8129e11be616acb0f9c34bc8f8adb ] When a client moves from a DSA user port to a software port in a bridge, it cannot reach any other clients that connected to the DSA user ports. That is because SA learning on the CPU port is disabled, so the switch ignores the client's frames from the CPU port and still thinks it is at the user port. Fix it by enabling SA learning on the CPU port. To prevent the switch from learning from flooding frames from the CPU port, set skb->offload_fwd_mark to 1 for unicast and broadcast frames, and let the switch flood them instead of trapping to the CPU port. Multicast frames still need to be trapped to the CPU port for snooping, so set the SA_DIS bit of the MTK tag to 1 when transmitting those frames to disable SA learning. Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") Signed-off-by: DENG Qingfang Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b853a13bb224d30850dcafcb828b024a266060fe Author: Sabrina Dubroca Date: Wed May 20 11:15:46 2020 +0200 net: don't return invalid table id error when we fall back to PF_UNSPEC [ Upstream commit 41b4bd986f86331efc599b9a3f5fb86ad92e9af9 ] In case we can't find a ->dumpit callback for the requested (family,type) pair, we fall back to (PF_UNSPEC,type). In effect, we're in the same situation as if userspace had requested a PF_UNSPEC dump. For RTM_GETROUTE, that handler is rtnl_dump_all, which calls all the registered RTM_GETROUTE handlers. The requested table id may or may not exist for all of those families. commit ae677bbb4441 ("net: Don't return invalid table id error when dumping all families") fixed the problem when userspace explicitly requests a PF_UNSPEC dump, but missed the fallback case. For example, when we pass ipv6.disable=1 to a kernel with CONFIG_IP_MROUTE=y and CONFIG_IP_MROUTE_MULTIPLE_TABLES=y, the (PF_INET6, RTM_GETROUTE) handler isn't registered, so we end up in rtnl_dump_all, and listing IPv6 routes will unexpectedly print: # ip -6 r Error: ipv4: MR table does not exist. Dump terminated commit ae677bbb4441 introduced the dump_all_families variable, which gets set when userspace requests a PF_UNSPEC dump. However, we can't simply set the family to PF_UNSPEC in rtnetlink_rcv_msg in the fallback case to get dump_all_families == true, because some messages types (for example RTM_GETRULE and RTM_GETNEIGH) only register the PF_UNSPEC handler and use the family to filter in the kernel what is dumped to userspace. We would then export more entries, that userspace would have to filter. iproute does that, but other programs may not. Instead, this patch removes dump_all_families and updates the RTM_GETROUTE handlers to check if the family that is being dumped is their own. When it's not, which covers both the intentional PF_UNSPEC dumps (as dump_all_families did) and the fallback case, ignore the missing table id error. Fixes: cb167893f41e ("net: Plumb support for filtering ipv4 and ipv6 multicast route dumps") Signed-off-by: Sabrina Dubroca Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 40a904b1c2e57b22dd002dfce73688871cb0bac8 Author: Vladimir Oltean Date: Mon May 25 00:22:51 2020 +0300 dpaa_eth: fix usage as DSA master, try 3 [ Upstream commit 5d14c304bfc14b4fd052dc83d5224376b48f52f0 ] The dpaa-eth driver probes on compatible string for the MAC node, and the fman/mac.c driver allocates a dpaa-ethernet platform device that triggers the probing of the dpaa-eth net device driver. All of this is fine, but the problem is that the struct device of the dpaa_eth net_device is 2 parents away from the MAC which can be referenced via of_node. So of_find_net_device_by_node can't find it, and DSA switches won't be able to probe on top of FMan ports. It would be a bit silly to modify a core function (of_find_net_device_by_node) to look for dev->parent->parent->of_node just for one driver. We're just 1 step away from implementing full recursion. Actually there have already been at least 2 previous attempts to make this work: - Commit a1a50c8e4c24 ("fsl/man: Inherit parent device and of_node") - One or more of the patches in "[v3,0/6] adapt DPAA drivers for DSA": https://patchwork.ozlabs.org/project/netdev/cover/1508178970-28945-1-git-send-email-madalin.bucur@nxp.com/ (I couldn't really figure out which one was supposed to solve the problem and how). Point being, it looks like this is still pretty much a problem today. On T1040, the /sys/class/net/eth0 symlink currently points to ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/dpaa-ethernet.0/net/eth0 which pretty much illustrates the problem. The closest of_node we've got is the "fsl,fman-memac" at /soc@ffe000000/fman@400000/ethernet@e6000, which is what we'd like to be able to reference from DSA as host port. For of_find_net_device_by_node to find the eth0 port, we would need the parent of the eth0 net_device to not be the "dpaa-ethernet" platform device, but to point 1 level higher, aka the "fsl,fman-memac" node directly. The new sysfs path would look like this: ../../devices/platform/ffe000000.soc/ffe400000.fman/ffe4e6000.ethernet/net/eth0 And this is exactly what SET_NETDEV_DEV does. It sets the parent of the net_device. The new parent has an of_node associated with it, and of_dev_node_match already checks for the of_node of the device or of its parent. Fixes: a1a50c8e4c24 ("fsl/man: Inherit parent device and of_node") Fixes: c6e26ea8c893 ("dpaa_eth: change device used") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d9ce4b67dd9f8b834913eb867dabf0cd4dc48897 Author: Eric Dumazet Date: Tue May 19 18:24:43 2020 -0700 ax25: fix setsockopt(SO_BINDTODEVICE) [ Upstream commit 687775cec056b38a4c8f3291e0dd7a9145f7b667 ] syzbot was able to trigger this trace [1], probably by using a zero optlen. While we are at it, cap optlen to IFNAMSIZ - 1 instead of IFNAMSIZ. [1] BUG: KMSAN: uninit-value in strnlen+0xf9/0x170 lib/string.c:569 CPU: 0 PID: 8807 Comm: syz-executor483 Not tainted 5.7.0-rc4-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+0x1c9/0x220 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 strnlen+0xf9/0x170 lib/string.c:569 dev_name_hash net/core/dev.c:207 [inline] netdev_name_node_lookup net/core/dev.c:277 [inline] __dev_get_by_name+0x75/0x2b0 net/core/dev.c:778 ax25_setsockopt+0xfa3/0x1170 net/ax25/af_ax25.c:654 __compat_sys_setsockopt+0x4ed/0x910 net/compat.c:403 __do_compat_sys_setsockopt net/compat.c:413 [inline] __se_compat_sys_setsockopt+0xdd/0x100 net/compat.c:410 __ia32_compat_sys_setsockopt+0x62/0x80 net/compat.c:410 do_syscall_32_irqs_on arch/x86/entry/common.c:339 [inline] do_fast_syscall_32+0x3bf/0x6d0 arch/x86/entry/common.c:398 entry_SYSENTER_compat+0x68/0x77 arch/x86/entry/entry_64_compat.S:139 RIP: 0023:0xf7f57dd9 Code: 90 e8 0b 00 00 00 f3 90 0f ae e8 eb f9 8d 74 26 00 89 3c 24 c3 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90 RSP: 002b:00000000ffae8c1c EFLAGS: 00000217 ORIG_RAX: 000000000000016e RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000000101 RDX: 0000000000000019 RSI: 0000000020000000 RDI: 0000000000000004 RBP: 0000000000000012 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Local variable ----devname@ax25_setsockopt created at: ax25_setsockopt+0xe6/0x1170 net/ax25/af_ax25.c:536 ax25_setsockopt+0xe6/0x1170 net/ax25/af_ax25.c:536 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e0d81ce760044efd3f26004aa32821c34968512a Author: Greg Kroah-Hartman Date: Wed May 27 17:46:53 2020 +0200 Linux 5.4.43 commit b5100186021aff0d388aab48dfbfdb3c06955daf Author: Phil Auld Date: Tue May 12 09:52:22 2020 -0400 sched/fair: Fix enqueue_task_fair() warning some more [ Upstream commit b34cb07dde7c2346dec73d053ce926aeaa087303 ] sched/fair: Fix enqueue_task_fair warning some more The recent patch, fe61468b2cb (sched/fair: Fix enqueue_task_fair warning) did not fully resolve the issues with the rq->tmp_alone_branch != &rq->leaf_cfs_rq_list warning in enqueue_task_fair. There is a case where the first for_each_sched_entity loop exits due to on_rq, having incompletely updated the list. In this case the second for_each_sched_entity loop can further modify se. The later code to fix up the list management fails to do what is needed because se does not point to the sched_entity which broke out of the first loop. The list is not fixed up because the throttled parent was already added back to the list by a task enqueue in a parallel child hierarchy. Address this by calling list_add_leaf_cfs_rq if there are throttled parents while doing the second for_each_sched_entity loop. Fixes: fe61468b2cb ("sched/fair: Fix enqueue_task_fair warning") Suggested-by: Vincent Guittot Signed-off-by: Phil Auld Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Dietmar Eggemann Reviewed-by: Vincent Guittot Link: https://lkml.kernel.org/r/20200512135222.GC2201@lorien.usersys.redhat.com Signed-off-by: Sasha Levin commit 8b13f5657fa836a869cc245e529fd3b36207f59b Author: Vincent Guittot Date: Fri Mar 6 09:42:08 2020 +0100 sched/fair: Fix reordering of enqueue/dequeue_task_fair() [ Upstream commit 5ab297bab984310267734dfbcc8104566658ebef ] Even when a cgroup is throttled, the group se of a child cgroup can still be enqueued and its gse->on_rq stays true. When a task is enqueued on such child, we still have to update the load_avg and increase h_nr_running of the throttled cfs. Nevertheless, the 1st for_each_sched_entity() loop is skipped because of gse->on_rq == true and the 2nd loop because the cfs is throttled whereas we have to update both load_avg with the old h_nr_running and increase h_nr_running in such case. The same sequence can happen during dequeue when se moves to parent before breaking in the 1st loop. Note that the update of load_avg will effectively happen only once in order to sync up to the throttled time. Next call for updating load_avg will stop early because the clock stays unchanged. Signed-off-by: Vincent Guittot Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Ingo Molnar Fixes: 6d4d22468dae ("sched/fair: Reorder enqueue/dequeue_task_fair path") Link: https://lkml.kernel.org/r/20200306084208.12583-1-vincent.guittot@linaro.org Signed-off-by: Sasha Levin commit a2ad232aa6a90a3e106239a1c88cd1e4a1c10f21 Author: Vincent Guittot Date: Mon Feb 24 09:52:14 2020 +0000 sched/fair: Reorder enqueue/dequeue_task_fair path [ Upstream commit 6d4d22468dae3d8757af9f8b81b848a76ef4409d ] The walk through the cgroup hierarchy during the enqueue/dequeue of a task is split in 2 distinct parts for throttled cfs_rq without any added value but making code less readable. Change the code ordering such that everything related to a cfs_rq (throttled or not) will be done in the same loop. In addition, the same steps ordering is used when updating a cfs_rq: - update_load_avg - update_cfs_group - update *h_nr_running This reordering enables the use of h_nr_running in PELT algorithm. No functional and performance changes are expected and have been noticed during tests. Signed-off-by: Vincent Guittot Signed-off-by: Mel Gorman Signed-off-by: Ingo Molnar Reviewed-by: "Dietmar Eggemann " Acked-by: Peter Zijlstra Cc: Juri Lelli Cc: Valentin Schneider Cc: Phil Auld Cc: Hillf Danton Link: https://lore.kernel.org/r/20200224095223.13361-5-mgorman@techsingularity.net Signed-off-by: Sasha Levin commit f4520daa3c5af8954145d18aa06f5711cc948d41 Author: Loïc Yhuel Date: Tue May 12 06:01:13 2020 +0200 tpm: check event log version before reading final events [ Upstream commit b4f1874c62168159fdb419ced4afc77c1b51c475 ] This fixes the boot issues since 5.3 on several Dell models when the TPM is enabled. Depending on the exact grub binary, booting the kernel would freeze early, or just report an error parsing the final events log. We get an event log in the SHA-1 format, which doesn't have a tcg_efi_specid_event_head in the first event, and there is a final events table which doesn't match the crypto agile format. __calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and either fails, or loops long enough for the machine to be appear frozen. So we now only parse the final events table, which is per the spec always supposed to be in the crypto agile format, when we got a event log in this format. Fixes: c46f3405692de ("tpm: Reserve the TPM final events table") Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log in the TCG2 log") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611 Signed-off-by: Loïc Yhuel Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com Reviewed-by: Javier Martinez Canillas Reviewed-by: Jerry Snitselaar Reviewed-by: Matthew Garrett [ardb: warn when final events table is missing or in the wrong format] Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin commit 68b7b8183c123070996fdb556bb813276799c8dc Author: David Howells Date: Wed Apr 29 23:48:43 2020 +0100 rxrpc: Fix ack discard [ Upstream commit 441fdee1eaf050ef0040bde0d7af075c1c6a6d8b ] The Rx protocol has a "previousPacket" field in it that is not handled in the same way by all protocol implementations. Sometimes it contains the serial number of the last DATA packet received, sometimes the sequence number of the last DATA packet received and sometimes the highest sequence number so far received. AF_RXRPC is using this to weed out ACKs that are out of date (it's possible for ACK packets to get reordered on the wire), but this does not work with OpenAFS which will just stick the sequence number of the last packet seen into previousPacket. The issue being seen is that big AFS FS.StoreData RPC (eg. of ~256MiB) are timing out when partly sent. A trace was captured, with an additional tracepoint to show ACKs being discarded in rxrpc_input_ack(). Here's an excerpt showing the problem. 52873.203230: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 0002449c q=00024499 fl=09 A DATA packet with sequence number 00024499 has been transmitted (the "q=" field). ... 52873.243296: rxrpc_rx_ack: c=000004ae 00012a2b DLY r=00024499 f=00024497 p=00024496 n=0 52873.243376: rxrpc_rx_ack: c=000004ae 00012a2c IDL r=0002449b f=00024499 p=00024498 n=0 52873.243383: rxrpc_rx_ack: c=000004ae 00012a2d OOS r=0002449d f=00024499 p=0002449a n=2 The Out-Of-Sequence ACK indicates that the server didn't see DATA sequence number 00024499, but did see seq 0002449a (previousPacket, shown as "p=", skipped the number, but firstPacket, "f=", which shows the bottom of the window is set at that point). 52873.252663: rxrpc_retransmit: c=000004ae q=24499 a=02 xp=14581537 52873.252664: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244bc q=00024499 fl=0b *RETRANS* The packet has been retransmitted. Retransmission recurs until the peer says it got the packet. 52873.271013: rxrpc_rx_ack: c=000004ae 00012a31 OOS r=000244a1 f=00024499 p=0002449e n=6 More OOS ACKs indicate that the other packets that are already in the transmission pipeline are being received. The specific-ACK list is up to 6 ACKs and NAKs. ... 52873.284792: rxrpc_rx_ack: c=000004ae 00012a49 OOS r=000244b9 f=00024499 p=000244b6 n=30 52873.284802: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=63505500 52873.284804: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c2 q=00024499 fl=0b *RETRANS* 52873.287468: rxrpc_rx_ack: c=000004ae 00012a4a OOS r=000244ba f=00024499 p=000244b7 n=31 52873.287478: rxrpc_rx_ack: c=000004ae 00012a4b OOS r=000244bb f=00024499 p=000244b8 n=32 At this point, the server's receive window is full (n=32) with presumably 1 NAK'd packet and 31 ACK'd packets. We can't transmit any more packets. 52873.287488: rxrpc_retransmit: c=000004ae q=24499 a=0a xp=61327980 52873.287489: rxrpc_tx_data: c=000004ae DATA ed1a3584:00000002 000244c3 q=00024499 fl=0b *RETRANS* 52873.293850: rxrpc_rx_ack: c=000004ae 00012a4c DLY r=000244bc f=000244a0 p=00024499 n=25 And now we've received an ACK indicating that a DATA retransmission was received. 7 packets have been processed (the occupied part of the window moved, as indicated by f= and n=). 52873.293853: rxrpc_rx_discard_ack: c=000004ae r=00012a4c 000244a0<00024499 00024499<000244b8 However, the DLY ACK gets discarded because its previousPacket has gone backwards (from p=000244b8, in the ACK at 52873.287478 to p=00024499 in the ACK at 52873.293850). We then end up in a continuous cycle of retransmit/discard. kafs fails to update its window because it's discarding the ACKs and can't transmit an extra packet that would clear the issue because the window is full. OpenAFS doesn't change the previousPacket value in the ACKs because no new DATA packets are received with a different previousPacket number. Fix this by altering the discard check to only discard an ACK based on previousPacket if there was no advance in the firstPacket. This allows us to transmit a new packet which will cause previousPacket to advance in the next ACK. The check, however, needs to allow for the possibility that previousPacket may actually have had the serial number placed in it instead - in which case it will go outside the window and we should ignore it. Fixes: 1a2391c30c0b ("rxrpc: Fix detection of out of order acks") Reported-by: Dave Botsch Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 283eb0016f97083665ef3f19a6c61757fddea671 Author: David Howells Date: Tue Apr 28 22:06:54 2020 +0100 rxrpc: Trace discarded ACKs [ Upstream commit d1f129470e6cb79b8b97fecd12689f6eb49e27fe ] Add a tracepoint to track received ACKs that are discarded due to being outside of the Tx window. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit f2da8c0dfe8173c927d1ee06af3a81bebfe07ee7 Author: Fabrice Gasnier Date: Thu Apr 30 11:28:46 2020 +0200 iio: adc: stm32-dfsdm: fix device used to request dma [ Upstream commit b455d06e6fb3c035711e8aab1ca18082ccb15d87 ] DMA channel request should use device struct from platform device struct. Currently it's using iio device struct. But at this stage when probing, device struct isn't yet registered (e.g. device_register is done in iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves"), a warning message is printed as the links in sysfs can't be created, due to device isn't yet registered: - Cannot create DMA slave symlink - Cannot create DMA dma:rx symlink Fix this by using device struct from platform device to request dma chan. Fixes: eca949800d2d ("IIO: ADC: add stm32 DFSDM support for PDM microphone") Signed-off-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 7b5af65ca246343aee4f06619c0835fa7dedd801 Author: Peter Ujfalusi Date: Tue Jan 7 13:45:32 2020 +0200 iio: adc: stm32-dfsdm: Use dma_request_chan() instead dma_request_slave_channel() [ Upstream commit a9ab624edd9186fbad734cfe5d606a6da3ca34db ] dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by: Peter Ujfalusi Acked-by: Olivier Moysan Acked-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 692001a867b6dbb5712cc77ac1a2a984c2acf467 Author: Fabrice Gasnier Date: Thu Apr 30 11:28:45 2020 +0200 iio: adc: stm32-adc: fix device used to request dma [ Upstream commit 52cd91c27f3908b88e8b25aed4a4d20660abcc45 ] DMA channel request should use device struct from platform device struct. Currently it's using iio device struct. But at this stage when probing, device struct isn't yet registered (e.g. device_register is done in iio_device_register). Since commit 71723a96b8b1 ("dmaengine: Create symlinks between DMA channels and slaves"), a warning message is printed as the links in sysfs can't be created, due to device isn't yet registered: - Cannot create DMA slave symlink - Cannot create DMA dma:rx symlink Fix this by using device struct from platform device to request dma chan. Fixes: 2763ea0585c99 ("iio: adc: stm32: add optional dma support") Signed-off-by: Fabrice Gasnier Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 8e8836b2b7824f21c8418b8b3608e640709e0c79 Author: Peter Ujfalusi Date: Wed Jan 8 10:08:01 2020 +0200 iio: adc: stm32-adc: Use dma_request_chan() instead dma_request_slave_channel() [ Upstream commit 735404b846dffcb320264f62b76e6f70012214dd ] dma_request_slave_channel() is a wrapper on top of dma_request_chan() eating up the error code. By using dma_request_chan() directly the driver can support deferred probing against DMA. Signed-off-by: Peter Ujfalusi Acked-by: Fabrice Gasnier Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 1084eee4dc5df9faf7d159bef04b089bece25fed Author: Josh Poimboeuf Date: Fri May 22 08:54:35 2020 -0500 x86/unwind/orc: Fix unwind_get_return_address_ptr() for inactive tasks commit 187b96db5ca79423618dfa29a05c438c34f9e1f0 upstream. Normally, show_trace_log_lvl() scans the stack, looking for text addresses to print. In parallel, it unwinds the stack with unwind_next_frame(). If the stack address matches the pointer returned by unwind_get_return_address_ptr() for the current frame, the text address is printed normally without a question mark. Otherwise it's considered a breadcrumb (potentially from a previous call path) and it's printed with a question mark to indicate that the address is unreliable and typically can be ignored. Since the following commit: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") ... for inactive tasks, show_trace_log_lvl() prints *only* unreliable addresses (prepended with '?'). That happens because, for the first frame of an inactive task, unwind_get_return_address_ptr() returns the wrong return address pointer: one word *below* the task stack pointer. show_trace_log_lvl() starts scanning at the stack pointer itself, so it never finds the first 'reliable' address, causing only guesses to being printed. The first frame of an inactive task isn't a normal stack frame. It's actually just an instance of 'struct inactive_task_frame' which is left behind by __switch_to_asm(). Now that this inactive frame is actually exposed to callers, fix unwind_get_return_address_ptr() to interpret it properly. Fixes: f1d9a2abff66 ("x86/unwind/orc: Don't skip the first frame for inactive tasks") Reported-by: Tetsuo Handa Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200522135435.vbxs7umku5pyrdbk@treble Signed-off-by: Greg Kroah-Hartman commit 860fe59783a930315e2be6efee43e9a73e950c4d Author: Jakub Sitnicki Date: Thu May 21 10:34:35 2020 +0200 flow_dissector: Drop BPF flow dissector prog ref on netns cleanup commit 5cf65922bb15279402e1e19b5ee8c51d618fa51f upstream. When attaching a flow dissector program to a network namespace with bpf(BPF_PROG_ATTACH, ...) we grab a reference to bpf_prog. If netns gets destroyed while a flow dissector is still attached, and there are no other references to the prog, we leak the reference and the program remains loaded. Leak can be reproduced by running flow dissector tests from selftests/bpf: # bpftool prog list # ./test_flow_dissector.sh ... selftests: test_flow_dissector [PASS] # bpftool prog list 4: flow_dissector name _dissect tag e314084d332a5338 gpl loaded_at 2020-05-20T18:50:53+0200 uid 0 xlated 552B jited 355B memlock 4096B map_ids 3,4 btf_id 4 # Fix it by detaching the flow dissector program when netns is going away. Fixes: d58e468b1112 ("flow_dissector: implements flow dissector BPF hook") Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/20200521083435.560256-1-jakub@cloudflare.com Signed-off-by: Greg Kroah-Hartman commit bd6f0c799f4da6f8518f0409757b02e442588c5e Author: Philipp Rudo Date: Tue May 12 19:39:56 2020 +0200 s390/kexec_file: fix initrd location for kdump kernel commit 70b690547d5ea1a3d135a4cc39cd1e08246d0c3a upstream. initrd_start must not point at the location the initrd is loaded into the crashkernel memory but at the location it will be after the crashkernel memory is swapped with the memory at 0. Fixes: ee337f5469fd ("s390/kexec_file: Add crash support to image loader") Reported-by: Lianbo Jiang Signed-off-by: Philipp Rudo Tested-by: Lianbo Jiang Link: https://lore.kernel.org/r/20200512193956.15ae3f23@laptop2-ibm.local Signed-off-by: Christian Borntraeger Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 834d24ec3a0ab61b0c7e2d010de542e4117c7829 Author: Qiushi Wu Date: Fri May 22 13:45:18 2020 -0500 rxrpc: Fix a memory leak in rxkad_verify_response() commit f45d01f4f30b53c3a0a1c6c1c154acb7ff74ab9f upstream. A ticket was not released after a call of the function "rxkad_decrypt_ticket" failed. Thus replace the jump target "temporary_error_free_resp" by "temporary_error_free_ticket". Fixes: 8c2f826dc3631 ("rxrpc: Don't put crypto buffers on the stack") Signed-off-by: Qiushi Wu Signed-off-by: David Howells cc: Markus Elfring Signed-off-by: Greg Kroah-Hartman commit 23ae6e3e8aeb24f80093eecf8dca7d422a30e407 Author: David Howells Date: Mon May 11 14:54:34 2020 +0100 rxrpc: Fix the excessive initial retransmission timeout commit c410bf01933e5e09d142c66c3df9ad470a7eec13 upstream. rxrpc currently uses a fixed 4s retransmission timeout until the RTT is sufficiently sampled. This can cause problems with some fileservers with calls to the cache manager in the afs filesystem being dropped from the fileserver because a packet goes missing and the retransmission timeout is greater than the call expiry timeout. Fix this by: (1) Copying the RTT/RTO calculation code from Linux's TCP implementation and altering it to fit rxrpc. (2) Altering the various users of the RTT to make use of the new SRTT value. (3) Replacing the use of rxrpc_resend_timeout to use the calculated RTO value instead (which is needed in jiffies), along with a backoff. Notes: (1) rxrpc provides RTT samples by matching the serial numbers on outgoing DATA packets that have the RXRPC_REQUEST_ACK set and PING ACK packets against the reference serial number in incoming REQUESTED ACK and PING-RESPONSE ACK packets. (2) Each packet that is transmitted on an rxrpc connection gets a new per-connection serial number, even for retransmissions, so an ACK can be cross-referenced to a specific trigger packet. This allows RTT information to be drawn from retransmitted DATA packets also. (3) rxrpc maintains the RTT/RTO state on the rxrpc_peer record rather than on an rxrpc_call because many RPC calls won't live long enough to generate more than one sample. (4) The calculated SRTT value is in units of 8ths of a microsecond rather than nanoseconds. The (S)RTT and RTO values are displayed in /proc/net/rxrpc/peers. Fixes: 17926a79320a ([AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both"") Signed-off-by: David Howells Signed-off-by: Greg Kroah-Hartman commit c2a26769b43e9765e728429feaa6a4346597679a Author: Marco Elver Date: Fri May 22 22:22:59 2020 -0700 kasan: disable branch tracing for core runtime commit 33cd65e73abd693c00c4156cf23677c453b41b3b upstream. During early boot, while KASAN is not yet initialized, it is possible to enter reporting code-path and end up in kasan_report(). While uninitialized, the branch there prevents generating any reports, however, under certain circumstances when branches are being traced (TRACE_BRANCH_PROFILING), we may recurse deep enough to cause kernel reboots without warning. To prevent similar issues in future, we should disable branch tracing for the core runtime. [elver@google.com: remove duplicate DISABLE_BRANCH_PROFILING, per Qian Cai] Link: https://lore.kernel.org/lkml/20200517011732.GE24705@shao2-debian/ Link: http://lkml.kernel.org/r/20200522075207.157349-1-elver@google.com Reported-by: kernel test robot Signed-off-by: Marco Elver Signed-off-by: Andrew Morton Reviewed-by: Andrey Konovalov Cc: Dmitry Vyukov Cc: Alexander Potapenko Cc: Andrey Ryabinin Cc: Qian Cai Cc: Link: http://lkml.kernel.org/r//20200517011732.GE24705@shao2-debian/ Link: http://lkml.kernel.org/r/20200519182459.87166-1-elver@google.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 86217fecc4b7f482c15e22ce9984db6bc95405bb Author: John Hubbard Date: Fri May 22 22:22:48 2020 -0700 rapidio: fix an error in get_user_pages_fast() error handling commit ffca476a0a8d26de767cc41d62b8ca7f540ecfdd upstream. In the case of get_user_pages_fast() returning fewer pages than requested, rio_dma_transfer() does not quite do the right thing. It attempts to release all the pages that were requested, rather than just the pages that were pinned. Fix the error handling so that only the pages that were successfully pinned are released. Fixes: e8de370188d0 ("rapidio: add mport char device driver") Signed-off-by: John Hubbard Signed-off-by: Andrew Morton Reviewed-by: Andrew Morton Cc: Matt Porter Cc: Alexandre Bounine Cc: Sumit Semwal Cc: Dan Carpenter Cc: Link: http://lkml.kernel.org/r/20200517235620.205225-2-jhubbard@nvidia.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 689dacb2b09dfa3903e43a7385d4f3071204bac8 Author: David Hildenbrand Date: Fri May 22 22:22:42 2020 -0700 device-dax: don't leak kernel memory to user space after unloading kmem commit 60858c00e5f018eda711a3aa84cf62214ef62d61 upstream. Assume we have kmem configured and loaded: [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory$ 140000000-1481fffff : namespace0.0 150000000-33fffffff : dax0.0 150000000-33fffffff : System RAM Assume we try to unload kmem. This force-unloading will work, even if memory cannot get removed from the system. [root@localhost ~]# rmmod kmem [ 86.380228] removing memory fails, because memory [0x0000000150000000-0x0000000157ffffff] is onlined ... [ 86.431225] kmem dax0.0: DAX region [mem 0x150000000-0x33fffffff] cannot be hotremoved until the next reboot Now, we can reconfigure the namespace: [root@localhost ~]# ndctl create-namespace --force --reconfig=namespace0.0 --mode=devdax [ 131.409351] nd_pmem namespace0.0: could not reserve region [mem 0x140000000-0x33fffffff]dax [ 131.410147] nd_pmem: probe of namespace0.0 failed with error -16namespace0.0 --mode=devdax ... This fails as expected due to the busy memory resource, and the memory cannot be used. However, the dax0.0 device is removed, and along its name. The name of the memory resource now points at freed memory (name of the device): [root@localhost ~]# cat /proc/iomem ... 140000000-33fffffff : Persistent Memory 140000000-1481fffff : namespace0.0 150000000-33fffffff : �_�^7_��/_��wR��WQ���^��� ... 150000000-33fffffff : System RAM We have to make sure to duplicate the string. While at it, remove the superfluous setting of the name and fixup a stale comment. Fixes: 9f960da72b25 ("device-dax: "Hotremove" persistent memory that is used like normal RAM") Signed-off-by: David Hildenbrand Signed-off-by: Andrew Morton Cc: Dan Williams Cc: Vishal Verma Cc: Dave Jiang Cc: Pavel Tatashin Cc: Andrew Morton Cc: [5.3] Link: http://lkml.kernel.org/r/20200508084217.9160-2-david@redhat.com Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9e451933bba9ff554ed1ee09ad9d9cc3f2d06ea1 Author: Gerald Schaefer Date: Wed May 6 13:45:52 2020 +0200 s390/kaslr: add support for R_390_JMP_SLOT relocation type commit 4c1cbcbd6c56c79de2c07159be4f55386bb0bef2 upstream. With certain kernel configurations, the R_390_JMP_SLOT relocation type might be generated, which is not expected by the KASLR relocation code, and the kernel stops with the message "Unknown relocation type". This was found with a zfcpdump kernel config, where CONFIG_MODULES=n and CONFIG_VFIO=n. In that case, symbol_get() is used on undefined __weak symbols in virt/kvm/vfio.c, which results in the generation of R_390_JMP_SLOT relocation types. Fix this by handling R_390_JMP_SLOT similar to R_390_GLOB_DAT. Fixes: 805bc0bc238f ("s390/kernel: build a relocatable kernel") Cc: # v5.2+ Signed-off-by: Gerald Schaefer Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 72f3241508acab07f7e4c646f721eafa16e08389 Author: Niklas Schnelle Date: Thu Mar 26 12:22:50 2020 +0100 s390/pci: Fix s390_mmio_read/write with MIO commit f058599e22d59e594e5aae1dc10560568d8f4a8b upstream. The s390_mmio_read/write syscalls are currently broken when running with MIO. The new pcistb_mio/pcstg_mio/pcilg_mio instructions are executed similiarly to normal load/store instructions and do address translation in the current address space. That means inside the kernel they are aware of mappings into kernel address space while outside the kernel they use user space mappings (usually created through mmap'ing a PCI device file). Now when existing user space applications use the s390_pci_mmio_write and s390_pci_mmio_read syscalls, they pass I/O addresses that are mapped into user space so as to be usable with the new instructions without needing a syscall. Accessing these addresses with the old instructions as done currently leads to a kernel panic. Also, for such a user space mapping there may not exist an equivalent kernel space mapping which means we can't just use the new instructions in kernel space. Instead of replicating user mappings in the kernel which then might collide with other mappings, we can conceptually execute the new instructions as if executed by the user space application using the secondary address space. This even allows us to directly store to the user pointer without the need for copy_to/from_user(). Cc: stable@vger.kernel.org Fixes: 71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") Signed-off-by: Niklas Schnelle Reviewed-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 9c84884cd5dcdf0a55f2dcbf81560a612b3b6719 Author: Wei Yongjun Date: Thu May 7 09:42:37 2020 +0000 ipack: tpci200: fix error return code in tpci200_register() commit 133317479f0324f6faaf797c4f5f3e9b1b36ce35 upstream. Fix to return negative error code -ENOMEM from the ioremap() error handling case instead of 0, as done elsewhere in this function. Fixes: 43986798fd50 ("ipack: add error handling for ioremap_nocache") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Cc: stable Acked-by: Samuel Iglesias Gonsalvez Link: https://lore.kernel.org/r/20200507094237.13599-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman commit 46f47dda27bc43176c018f96b2b14248c10bdc17 Author: Alexander Usyskin Date: Wed May 13 01:31:40 2020 +0300 mei: release me_cl object reference commit fc9c03ce30f79b71807961bfcb42be191af79873 upstream. Allow me_cl object to be freed by releasing the reference that was acquired by one of the search functions: __mei_me_cl_by_uuid_id() or __mei_me_cl_by_uuid() Cc: Reported-by: 亿一 Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Link: https://lore.kernel.org/r/20200512223140.32186-1-tomas.winkler@intel.com Signed-off-by: Greg Kroah-Hartman commit f505a3e24c6a84417f3e9983cc59ccded531459c Author: Sagar Shrikant Kadam Date: Sat May 9 03:24:12 2020 -0700 tty: serial: add missing spin_lock_init for SiFive serial console commit 17b4efdf4e4867079012a48ca10d965fe9d68822 upstream. An uninitialised spin lock for sifive serial console raises a bad magic spin_lock error as reported and discussed here [1]. Initialising the spin lock resolves the issue. The fix is tested on HiFive Unleashed A00 board with Linux 5.7-rc4 and OpenSBI v0.7 [1] https://lore.kernel.org/linux-riscv/b9fe49483a903f404e7acc15a6efbef756db28ae.camel@wdc.com Fixes: 45c054d0815b ("tty: serial: add driver for the SiFive UART") Reported-by: Atish Patra Signed-off-by: Sagar Shrikant Kadam Reviewed-by: Palmer Dabbelt Acked-by: Palmer Dabbelt Cc: stable Link: https://lore.kernel.org/r/1589019852-21505-2-git-send-email-sagar.kadam@sifive.com Signed-off-by: Greg Kroah-Hartman commit a5b4b3f97de7ea4d4957a111aa2dac5ef18e5b5d Author: Klaus Doth Date: Fri May 22 12:56:04 2020 +0200 misc: rtsx: Add short delay after exit from ASPM commit 7a839dbab1be59f5ed3b3b046de29e166784c9b4 upstream. DMA transfers to and from the SD card stall for 10 seconds and run into timeout on RTS5260 card readers after ASPM was enabled. Adding a short msleep after disabling ASPM fixes the issue on several Dell Precision 7530/7540 systems I tested. This function is only called when waking up after the chip went into power-save after not transferring data for a few seconds. The added msleep does therefore not change anything in data transfer speed or induce any excessive waiting while data transfers are running, or the chip is sleeping. Only the transition from sleep to active is affected. Signed-off-by: Klaus Doth Cc: stable Link: https://lore.kernel.org/r/4434eaa7-2ee3-a560-faee-6cee63ebd6d4@doth.eu Signed-off-by: Greg Kroah-Hartman commit e64b205035fbde73ef0b858e7775242f8dd6c62d Author: Gregory CLEMENT Date: Thu Apr 30 15:05:47 2020 +0200 iio: adc: ti-ads8344: Fix channel selection commit bcfa1e253d2e329e1ebab5c89f3c73f6dd17606c upstream. During initial submission the selection of the channel was done using the scan_index member of the iio_chan_spec structure. It was an abuse because this member is supposed to be used with a buffer so it was removed. However there was still the need to be able to known how to select a channel, the correct member to store this information is address. Thanks to this it is possible to select any other channel than the channel 0. Fixes: 8dd2d7c0fed7 ("iio: adc: Add driver for the TI ADS8344 A/DC chips") Signed-off-by: Gregory CLEMENT Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 9af65dc54b9be53bfe3f4112bcab1d27641ce443 Author: Christophe JAILLET Date: Sun Apr 26 21:44:03 2020 +0200 iio: dac: vf610: Fix an error handling path in 'vf610_dac_probe()' commit aad4742fbf0a560c25827adb58695a4497ffc204 upstream. A call to 'vf610_dac_exit()' is missing in an error handling path. Fixes: 1b983bf42fad ("iio: dac: vf610_dac: Add IIO DAC driver for Vybrid SoC") Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit d54e5a4ff04cf65cdb821129bde71a21ceeba362 Author: Christophe JAILLET Date: Wed May 6 05:52:06 2020 +0200 iio: sca3000: Remove an erroneous 'get_device()' commit 928edefbc18cd8433f7df235c6e09a9306e7d580 upstream. This looks really unusual to have a 'get_device()' hidden in a 'dev_err()' call. Remove it. While at it add a missing \n at the end of the message. Fixes: 574fb258d636 ("Staging: IIO: VTI sca3000 series accelerometer driver (spi)") Signed-off-by: Christophe JAILLET Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 56cff2ac7c9d295c1588870450994eec1676e68c Author: Oscar Carter Date: Sun May 10 12:14:26 2020 +0200 staging: greybus: Fix uninitialized scalar variable commit 34625c1931f8204c234c532b446b9f53c69f4b68 upstream. In the "gb_tty_set_termios" function the "newline" variable is declared but not initialized. So the "flow_control" member is not initialized and the OR / AND operations with itself results in an undefined value in this member. The purpose of the code is to set the flow control type, so remove the OR / AND self operator and set the value directly. Addresses-Coverity-ID: 1374016 ("Uninitialized scalar variable") Fixes: e55c25206d5c9 ("greybus: uart: Handle CRTSCTS flag in termios") Signed-off-by: Oscar Carter Cc: stable Link: https://lore.kernel.org/r/20200510101426.23631-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman commit a41e02cb4232a45533ecc0bc9bc81cee94261e05 Author: Wei Yongjun Date: Wed May 6 13:47:35 2020 +0000 staging: kpc2000: fix error return code in kp2000_pcie_probe() commit b17884ccf29e127b16bba6aea1438c851c9f5af1 upstream. Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Also removed var 'rv' since we can use 'err' instead. Fixes: 7dc7967fc39a ("staging: kpc2000: add initial set of Daktronics drivers") Signed-off-by: Wei Yongjun Cc: stable Reviewed-by: Dan Carpenter Link: https://lore.kernel.org/r/20200506134735.102041-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman commit dee81110a4888cf8eb419434c0ad687129c7d0fd Author: Dragos Bogdan Date: Wed Apr 29 10:21:29 2020 +0300 staging: iio: ad2s1210: Fix SPI reading commit 5e4f99a6b788047b0b8a7496c2e0c8f372f6edf2 upstream. If the serial interface is used, the 8-bit address should be latched using the rising edge of the WR/FSYNC signal. This basically means that a CS change is required between the first byte sent, and the second one. This change splits the single-transfer transfer of 2 bytes into 2 transfers with a single byte, and CS change in-between. Note fixes tag is not accurate, but reflects a point beyond which there are too many refactors to make backporting straight forward. Fixes: b19e9ad5e2cb ("staging:iio:resolver:ad2s1210 general driver cleanup.") Signed-off-by: Dragos Bogdan Signed-off-by: Alexandru Ardelean Cc: Signed-off-by: Jonathan Cameron Signed-off-by: Greg Kroah-Hartman commit 76296dc723ef3e723a79c2684c419f8facec6779 Author: Geert Uytterhoeven Date: Thu Oct 24 10:09:16 2019 -0300 media: fdp1: Fix R-Car M3-N naming in debug message [ Upstream commit c05b9d7b9f3ece2831e4e4829f10e904df296df8 ] The official name is "R-Car M3-N", not "R-Car M3N". Fixes: 4e8c120de9268fc2 ("media: fdp1: Support M3N and E3 platforms") Signed-off-by: Geert Uytterhoeven Reviewed-by: Kieran Bingham Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4adb7a2b3161adce329c1fbcfbc6a9d438e6d4f6 Author: Bob Peterson Date: Fri May 8 15:01:25 2020 -0500 Revert "gfs2: Don't demote a glock until its revokes are written" [ Upstream commit b14c94908b1b884276a6608dea3d0b1b510338b7 ] This reverts commit df5db5f9ee112e76b5202fbc331f990a0fc316d6. This patch fixes a regression: patch df5db5f9ee112 allowed function run_queue() to bypass its call to do_xmote() if revokes were queued for the glock. That's wrong because its call to do_xmote() is what is responsible for calling the go_sync() glops functions to sync both the ail list and any revokes queued for it. By bypassing the call, gfs2 could get into a stand-off where the glock could not be demoted until its revokes are written back, but the revokes would not be written back because do_xmote() was never called. It "sort of" works, however, because there are other mechanisms like the log flush daemon (logd) that can sync the ail items and revokes, if it deems it necessary. The problem is: without file system pressure, it might never deem it necessary. Signed-off-by: Bob Peterson Signed-off-by: Sasha Levin commit bb6524537dc2f8b2a2bae63926b02e5e008be0fd Author: Kees Cook Date: Tue Mar 3 18:18:34 2020 -0800 kbuild: Remove debug info from kallsyms linking [ Upstream commit af73d78bd384aa9b8789aa6e7ddbb165f971276f ] When CONFIG_DEBUG_INFO is enabled, the two kallsyms linking steps spend time collecting and writing the dwarf sections to the temporary output files. kallsyms does not need this information, and leaving it off halves their linking time. This is especially noticeable without CONFIG_DEBUG_INFO_REDUCED. The BTF linking stage, however, does still need those details. Refactor the BTF and kallsyms generation stages slightly for more regularized temporary names. Skip debug during kallsyms links. Additionally move "info BTF" to the correct place since commit 8959e39272d6 ("kbuild: Parameterize kallsyms generation and correct reporting"), which added "info LD ..." to vmlinux_link calls. For a full debug info build with BTF, my link time goes from 1m06s to 0m54s, saving about 12 seconds, or 18%. Signed-off-by: Kees Cook Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/202003031814.4AEA3351@keescook Signed-off-by: Sasha Levin commit ee71c590dd8dcfa2afeed51d510c07991fce694a Author: Daniel Borkmann Date: Fri Nov 29 23:29:11 2019 +0100 bpf: Avoid setting bpf insns pages read-only when prog is jited [ Upstream commit e1608f3fa857b600045b6df7f7dadc70eeaa4496 ] For the case where the interpreter is compiled out or when the prog is jited it is completely unnecessary to set the BPF insn pages as read-only. In fact, on frequent churn of BPF programs, it could lead to performance degradation of the system over time since it would break the direct map down to 4k pages when calling set_memory_ro() for the insn buffer on x86-64 / arm64 and there is no reverse operation. Thus, avoid breaking up large pages for data maps, and only limit this to the module range used by the JIT where it is necessary to set the image read-only and executable. Suggested-by: Peter Zijlstra Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191129222911.3710-1-daniel@iogearbox.net Signed-off-by: Sasha Levin commit 4c732e81bd4dc2c2eca34a10d0e4427003e3e800 Author: Michael Ellerman Date: Wed May 20 23:36:05 2020 +1000 powerpc/64s: Disable STRICT_KERNEL_RWX [ Upstream commit 8659a0e0efdd975c73355dbc033f79ba3b31e82c ] Several strange crashes have been eventually traced back to STRICT_KERNEL_RWX and its interaction with code patching. Various paths in our ftrace, kprobes and other patching code need to be hardened against patching failures, otherwise we can end up running with partially/incorrectly patched ftrace paths, kprobes or jump labels, which can then cause strange crashes. Although fixes for those are in development, they're not -rc material. There also seem to be problems with the underlying strict RWX logic, which needs further debugging. So for now disable STRICT_KERNEL_RWX on 64-bit to prevent people from enabling the option and tripping over the bugs. Fixes: 1e0fc9d1eb2b ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some configs") Cc: stable@vger.kernel.org # v4.13+ Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200520133605.972649-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit b67da9dbdb89630453dab53ca3619b53ba77b88a Author: Russell Currey Date: Tue Dec 24 17:41:26 2019 +1100 powerpc: Remove STRICT_KERNEL_RWX incompatibility with RELOCATABLE [ Upstream commit c55d7b5e64265fdca45c85b639013e770bde2d0e ] I have tested this with the Radix MMU and everything seems to work, and the previous patch for Hash seems to fix everything too. STRICT_KERNEL_RWX should still be disabled by default for now. Please test STRICT_KERNEL_RWX + RELOCATABLE! Signed-off-by: Russell Currey Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191224064126.183670-2-ruscur@russell.cc Signed-off-by: Sasha Levin commit 9bcfbd8ba2b57d5198279af8a3fd0c49f86ab60e Author: Chris Wilson Date: Wed May 6 17:21:36 2020 +0100 drm/i915: Propagate error from completed fences commit bc850943486887e3859597a266767f95db90aa72 upstream. We need to preserve fatal errors from fences that are being terminated as we hook them up. Fixes: ef4688497512 ("drm/i915: Propagate fence errors") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Matthew Auld Reviewed-by: Matthew Auld Link: https://patchwork.freedesktop.org/patch/msgid/20200506162136.3325-1-chris@chris-wilson.co.uk (cherry picked from commit 24fe5f2ab2478053d50a3bc629ada895903a5cbc) Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 5e171483e94713e7d7576804098b680dd02ab0f0 Author: Colin Xu Date: Fri May 8 14:05:06 2020 +0800 drm/i915/gvt: Init DPLL/DDI vreg for virtual display instead of inheritance. commit f965b68188ab59a40a421ced1b05a2fea638465c upstream. Init value of some display vregs rea inherited from host pregs. When host display in different status, i.e. all monitors unpluged, different display configurations, etc., GVT virtual display setup don't consistent thus may lead to guest driver consider display goes malfunctional. The added init vreg values are based on PRMs and fixed by calcuation from current configuration (only PIPE_A) and the virtual EDID. Fixes: 04d348ae3f0a ("drm/i915/gvt: vGPU display virtualization") Acked-by: Zhenyu Wang Signed-off-by: Colin Xu Signed-off-by: Zhenyu Wang Link: http://patchwork.freedesktop.org/patch/msgid/20200508060506.216250-1-colin.xu@intel.com Signed-off-by: Greg Kroah-Hartman commit 0e1d5f67253e63a71da7a6a3efdc9536ed2d2539 Author: Ilya Dryomov Date: Tue May 19 13:26:57 2020 +0200 vsprintf: don't obfuscate NULL and error pointers commit 7bd57fbc4a4ddedc664cad0bbced1b469e24e921 upstream. I don't see what security concern is addressed by obfuscating NULL and IS_ERR() error pointers, printed with %p/%pK. Given the number of sites where %p is used (over 10000) and the fact that NULL pointers aren't uncommon, it probably wouldn't take long for an attacker to find the hash that corresponds to 0. Although harder, the same goes for most common error values, such as -1, -2, -11, -14, etc. The NULL part actually fixes a regression: NULL pointers weren't obfuscated until commit 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") which went into 5.2. I'm tacking the IS_ERR() part on here because error pointers won't leak kernel addresses and printing them as pointers shouldn't be any different from e.g. %d with PTR_ERR_OR_ZERO(). Obfuscating them just makes debugging based on existing pr_debug and friends excruciating. Note that the "always print 0's for %pK when kptr_restrict == 2" behaviour which goes way back is left as is. Example output with the patch applied: ptr error-ptr NULL %p: 0000000001f8cc5b fffffffffffffff2 0000000000000000 %pK, kptr = 0: 0000000001f8cc5b fffffffffffffff2 0000000000000000 %px: ffff888048c04020 fffffffffffffff2 0000000000000000 %pK, kptr = 1: ffff888048c04020 fffffffffffffff2 0000000000000000 %pK, kptr = 2: 0000000000000000 0000000000000000 0000000000000000 Fixes: 3e5903eb9cff ("vsprintf: Prevent crash when dereferencing invalid pointers") Signed-off-by: Ilya Dryomov Reviewed-by: Petr Mladek Reviewed-by: Sergey Senozhatsky Reviewed-by: Andy Shevchenko Acked-by: Steven Rostedt (VMware) Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4b1b34621998c4f99d91830175a53ac9a57c07a7 Author: Cristian Ciocaltea Date: Sat May 2 20:15:51 2020 +0300 dmaengine: owl: Use correct lock in owl_dma_get_pchan() commit f8f482deb078389b42768b2193e050a81aae137d upstream. When the kernel is built with lockdep support and the owl-dma driver is used, the following message is shown: [ 2.496939] INFO: trying to register non-static key. [ 2.501889] the code is fine but needs lockdep annotation. [ 2.507357] turning off the locking correctness validator. [ 2.512834] CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.6.3+ #15 [ 2.519084] Hardware name: Generic DT based system [ 2.523878] Workqueue: events_freezable mmc_rescan [ 2.528681] [<801127f0>] (unwind_backtrace) from [<8010da58>] (show_stack+0x10/0x14) [ 2.536420] [<8010da58>] (show_stack) from [<8080fbe8>] (dump_stack+0xb4/0xe0) [ 2.543645] [<8080fbe8>] (dump_stack) from [<8017efa4>] (register_lock_class+0x6f0/0x718) [ 2.551816] [<8017efa4>] (register_lock_class) from [<8017b7d0>] (__lock_acquire+0x78/0x25f0) [ 2.560330] [<8017b7d0>] (__lock_acquire) from [<8017e5e4>] (lock_acquire+0xd8/0x1f4) [ 2.568159] [<8017e5e4>] (lock_acquire) from [<80831fb0>] (_raw_spin_lock_irqsave+0x3c/0x50) [ 2.576589] [<80831fb0>] (_raw_spin_lock_irqsave) from [<8051b5fc>] (owl_dma_issue_pending+0xbc/0x120) [ 2.585884] [<8051b5fc>] (owl_dma_issue_pending) from [<80668cbc>] (owl_mmc_request+0x1b0/0x390) [ 2.594655] [<80668cbc>] (owl_mmc_request) from [<80650ce0>] (mmc_start_request+0x94/0xbc) [ 2.602906] [<80650ce0>] (mmc_start_request) from [<80650ec0>] (mmc_wait_for_req+0x64/0xd0) [ 2.611245] [<80650ec0>] (mmc_wait_for_req) from [<8065aa10>] (mmc_app_send_scr+0x10c/0x144) [ 2.619669] [<8065aa10>] (mmc_app_send_scr) from [<80659b3c>] (mmc_sd_setup_card+0x4c/0x318) [ 2.628092] [<80659b3c>] (mmc_sd_setup_card) from [<80659f0c>] (mmc_sd_init_card+0x104/0x430) [ 2.636601] [<80659f0c>] (mmc_sd_init_card) from [<8065a3e0>] (mmc_attach_sd+0xcc/0x16c) [ 2.644678] [<8065a3e0>] (mmc_attach_sd) from [<8065301c>] (mmc_rescan+0x3ac/0x40c) [ 2.652332] [<8065301c>] (mmc_rescan) from [<80143244>] (process_one_work+0x2d8/0x780) [ 2.660239] [<80143244>] (process_one_work) from [<80143730>] (worker_thread+0x44/0x598) [ 2.668323] [<80143730>] (worker_thread) from [<8014b5f8>] (kthread+0x148/0x150) [ 2.675708] [<8014b5f8>] (kthread) from [<801010b4>] (ret_from_fork+0x14/0x20) [ 2.682912] Exception stack(0xee8fdfb0 to 0xee8fdff8) [ 2.687954] dfa0: 00000000 00000000 00000000 00000000 [ 2.696118] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.704277] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 The obvious fix would be to use 'spin_lock_init()' on 'pchan->lock' before attempting to call 'spin_lock_irqsave()' in 'owl_dma_get_pchan()'. However, according to Manivannan Sadhasivam, 'pchan->lock' was supposed to only protect 'pchan->vchan' while 'od->lock' does a similar job in 'owl_dma_terminate_pchan()'. Therefore, this patch substitutes 'pchan->lock' with 'od->lock' and removes the 'lock' attribute in 'owl_dma_pchan' struct. Fixes: 47e20577c24d ("dmaengine: Add Actions Semi Owl family S900 DMA driver") Signed-off-by: Cristian Ciocaltea Reviewed-by: Manivannan Sadhasivam Acked-by: Andreas Färber Link: https://lore.kernel.org/r/c6e6cdaca252b5364bd294093673951036488cf0.1588439073.git.cristian.ciocaltea@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 0fcbe108b01a82806fd7907490b09709eef4bbac Author: Vladimir Murzin Date: Wed Apr 29 08:15:22 2020 +0100 dmaengine: dmatest: Restore default for channel commit 6b41030fdc79086db5d673c5ed7169f3ee8c13b9 upstream. In case of dmatest is built-in and no channel was configured test doesn't run with: dmatest: Could not start test, no channels configured Even though description to "channel" parameter claims that default is any. Add default channel back as it used to be rather than reject test with no channel configuration. Fixes: d53513d5dc285d9a95a534fc41c5c08af6b60eac ("dmaengine: dmatest: Add support for multi channel testing) Reported-by: Dijil Mohan Signed-off-by: Vladimir Murzin Link: https://lore.kernel.org/r/20200429071522.58148-1-vladimir.murzin@arm.com Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 57c32a52c3fecb17689e268dd9af201920872600 Author: Dan Carpenter Date: Mon May 18 14:29:55 2020 +0300 drm/etnaviv: Fix a leak in submit_pin_objects() commit ad99cb5e783bb03d512092db3387ead9504aad3d upstream. If the mapping address is wrong then we have to release the reference to it before returning -EINVAL. Fixes: 088880ddc0b2 ("drm/etnaviv: implement softpin") Signed-off-by: Dan Carpenter Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 432b103596bd8dd1ca3d4b5b98eb35f45d66c82b Author: Christophe JAILLET Date: Sat May 16 23:42:05 2020 +0200 dmaengine: tegra210-adma: Fix an error handling path in 'tegra_adma_probe()' commit 3a5fd0dbd87853f8bd2ea275a5b3b41d6686e761 upstream. Commit b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe") has moved some code in the probe function and reordered the error handling path accordingly. However, a goto has been missed. Fix it and goto the right label if 'dma_async_device_register()' fails, so that all resources are released. Fixes: b53611fb1ce9 ("dmaengine: tegra210-adma: Fix crash during probe") Signed-off-by: Christophe JAILLET Reviewed-by: Jon Hunter Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20200516214205.276266-1-christophe.jaillet@wanadoo.fr Signed-off-by: Vinod Koul Signed-off-by: Greg Kroah-Hartman commit 870a45e0b5078aeac097fa3242a2b40f6402e479 Author: Xiyu Yang Date: Mon Apr 20 13:35:28 2020 +0800 apparmor: Fix aa_label refcnt leak in policy_update commit c6b39f070722ea9963ffe756bfe94e89218c5e63 upstream. policy_update() invokes begin_current_label_crit_section(), which returns a reference of the updated aa_label object to "label" with increased refcount. When policy_update() returns, "label" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of policy_update(). When aa_may_manage_policy() returns not NULL, the refcnt increased by begin_current_label_crit_section() is not decreased, causing a refcnt leak. Fix this issue by jumping to "end_section" label when aa_may_manage_policy() returns not NULL. Fixes: 5ac8c355ae00 ("apparmor: allow introspecting the loaded policy pre internal transform") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 054934aa9faa480276e360588c7286a9490c2a2e Author: Xiyu Yang Date: Sun Apr 5 13:11:55 2020 +0800 apparmor: fix potential label refcnt leak in aa_change_profile commit a0b845ffa0d91855532b50fc040aeb2d8338dca4 upstream. aa_change_profile() invokes aa_get_current_label(), which returns a reference of the current task's label. According to the comment of aa_get_current_label(), the returned reference must be put with aa_put_label(). However, when the original object pointed by "label" becomes unreachable because aa_change_profile() returns or a new object is assigned to "label", reference count increased by aa_get_current_label() is not decreased, causing a refcnt leak. Fix this by calling aa_put_label() before aa_change_profile() return and dropping unnecessary aa_get_current_label(). Fixes: 9fcf78cca198 ("apparmor: update domain transitions that are subsets of confinement at nnp") Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 97d817b9ef13e2d52a86ea032b0df6a922e0e9df Author: Navid Emamdoost Date: Mon Oct 21 10:23:47 2019 -0500 apparmor: Fix use-after-free in aa_audit_rule_init commit c54d481d71c6849e044690d3960aaebc730224cc upstream. In the implementation of aa_audit_rule_init(), when aa_label_parse() fails the allocated memory for rule is released using aa_audit_rule_free(). But after this release, the return statement tries to access the label field of the rule which results in use-after-free. Before releasing the rule, copy errNo and return it after release. Fixes: 52e8c38001d8 ("apparmor: Fix memory leak of rule on error exit path") Signed-off-by: Navid Emamdoost Signed-off-by: John Johansen Signed-off-by: Greg Kroah-Hartman commit 3b1e38dfbc9f1bcec35cae89b2d9b498e542f7c8 Author: Christian Gmeiner Date: Tue May 19 07:30:15 2020 +0200 drm/etnaviv: fix perfmon domain interation commit 40b697e256ccdb88aaff424b44b4d300eb8460e8 upstream. The GC860 has one GPU device which has a 2d and 3d core. In this case we want to expose perfmon information for both cores. The driver has one array which contains all possible perfmon domains with some meta data - doms_meta. Here we can see that for the GC860 two elements of that array are relevant: doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain The userspace driver wants to get a list of all perfmon domains and their perfmon signals. This is done by iterating over all domains and their signals. If the userspace driver wants to access the domain with id 8 the kernel driver fails and returns invalid data from doms_3d with and invalid offset. This results in: Unable to handle kernel paging request at virtual address 00000000 On such a device it is not possible to use the userspace driver at all. The fix for this off-by-one error is quite simple. Reported-by: Paul Cercueil Tested-by: Paul Cercueil Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure") Cc: stable@vger.kernel.org Signed-off-by: Christian Gmeiner Signed-off-by: Lucas Stach Signed-off-by: Greg Kroah-Hartman commit 53683907ef68fcc3cb8baada7f87749bd5e1a7e1 Author: Keno Fischer Date: Fri May 15 18:22:53 2020 -0400 arm64: Fix PTRACE_SYSEMU semantics commit 1cf6022bd9161081215028203919c33fcfa6debb upstream. Quoth the man page: ``` If the tracee was restarted by PTRACE_SYSCALL or PTRACE_SYSEMU, the tracee enters syscall-enter-stop just prior to entering any system call (which will not be executed if the restart was using PTRACE_SYSEMU, regardless of any change made to registers at this point or how the tracee is restarted after this stop). ``` The parenthetical comment is currently true on x86 and powerpc, but not currently true on arm64. arm64 re-checks the _TIF_SYSCALL_EMU flag after the syscall entry ptrace stop. However, at this point, it reflects which method was used to re-start the syscall at the entry stop, rather than the method that was used to reach it. Fix that by recording the original flag before performing the ptrace stop, bringing the behavior in line with documentation and x86/powerpc. Fixes: f086f67485c5 ("arm64: ptrace: add support for syscall emulation") Cc: # 5.3.x- Signed-off-by: Keno Fischer Acked-by: Will Deacon Tested-by: Sudeep Holla Tested-by: Bin Lu [catalin.marinas@arm.com: moved 'flags' bit masking] [catalin.marinas@arm.com: changed 'flags' type to unsigned long] Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 96e56055a2f0961ac1161c31ba1ef1e6a9f7d6ff Author: Bodo Stroesser Date: Wed May 13 17:34:43 2020 +0200 scsi: target: Put lun_ref at end of tmr processing commit f2e6b75f6ee82308ef7b00f29e71e5f1c6b3d52a upstream. Testing with Loopback I found that, after a Loopback LUN has executed a TMR, I can no longer unlink the LUN. The rm command hangs in transport_clear_lun_ref() at wait_for_completion(&lun->lun_shutdown_comp) The reason is, that transport_lun_remove_cmd() is not called at the end of target_tmr_work(). It seems, that in other fabrics this call happens implicitly when the fabric drivers call transport_generic_free_cmd() during their ->queue_tm_rsp(). Unfortunately Loopback seems to not comply to the common way of calling transport_generic_free_cmd() from ->queue_*(). Instead it calls transport_generic_free_cmd() from its ->check_stop_free() only. But the ->check_stop_free() is called by transport_cmd_check_stop_to_fabric() after it has reset the se_cmd->se_lun pointer. Therefore the following transport_generic_free_cmd() skips the transport_lun_remove_cmd(). So this patch re-adds the transport_lun_remove_cmd() at the end of target_tmr_work(), which was removed during commit 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous"). For fabrics using transport_generic_free_cmd() in the usual way the double call to transport_lun_remove_cmd() doesn't harm, as transport_lun_remove_cmd() checks for this situation and does not release lun_ref twice. Link: https://lore.kernel.org/r/20200513153443.3554-1-bstroesser@ts.fujitsu.com Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous") Cc: stable@vger.kernel.org Tested-by: Bryant G. Ly Reviewed-by: Bart van Assche Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit 818657105a0bfd1ced530c2940d5250d5a2c1d74 Author: Ewan D. Milne Date: Mon May 4 13:54:16 2020 -0400 scsi: qla2xxx: Do not log message when reading port speed via sysfs commit fb9024b0646939e59d8a0b6799b317070619795a upstream. Calling ql_log() inside qla2x00_port_speed_show() is causing messages to be output to the console for no particularly good reason. The sysfs read routine should just return the information to userspace. The only reason to log a message is when the port speed actually changes, and this already occurs elsewhere. Link: https://lore.kernel.org/r/20200504175416.15417-1-emilne@redhat.com Fixes: 4910b524ac9e ("scsi: qla2xxx: Add support for setting port speed") Cc: # v5.1+ Reviewed-by: Lee Duncan Reviewed-by: Laurence Oberman Reviewed-by: Himanshu Madhani Signed-off-by: Ewan D. Milne Signed-off-by: Martin K. Petersen Signed-off-by: Greg Kroah-Hartman commit d54c5eff879551ec493c4f03a29830eb59b52554 Author: PeiSen Hou Date: Tue May 19 08:50:12 2020 +0200 ALSA: hda/realtek - Add more fixup entries for Clevo machines commit 259eb82475316672a5d682a94dc8bdd53cf8d8c3 upstream. A few known Clevo machines (PC50, PC70, X170) with ALC1220 codec need the existing quirk for pins for PB51 and co. Signed-off-by: PeiSen Hou Cc: Link: https://lore.kernel.org/r/20200519065012.13119-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 80f5822c2bf396acf495509a33ad52e0f98a8b36 Author: Christian Lachner Date: Mon May 18 07:38:44 2020 +0200 ALSA: hda/realtek - Fix silent output on Gigabyte X570 Aorus Xtreme commit d9e8fe0cffbfdd18de96fa68ee2a8b667a0b046e upstream. The Gigabyte X570 Aorus Xtreme motherboard with ALC1220 codec requires a similar workaround for Clevo laptops to enforce the DAC/mixer connection path. Set up a quirk entry for that. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205275 Signed-off-by: Christian Lachner Cc: Link: https://lore.kernel.org/r/20200518053844.42743-2-gladiac@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 1b17a0f98ad0c601ece7a92404bb0cf0c114e29e Author: Brent Lu Date: Mon May 18 12:30:38 2020 +0800 ALSA: pcm: fix incorrect hw_base increase commit e7513c5786f8b33f0c107b3759e433bc6cbb2efa upstream. There is a corner case that ALSA keeps increasing the hw_ptr but DMA already stop working/updating the position for a long time. In following log we can see the position returned from DMA driver does not move at all but the hw_ptr got increased at some point of time so snd_pcm_avail() will return a large number which seems to be a buffer underrun event from user space program point of view. The program thinks there is space in the buffer and fill more data. [ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 [ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554 ... [ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362 [ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 [ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368 This is because the hw_base will be increased by runtime->buffer_size frames unconditionally if the hw_ptr is not updated for over half of buffer time. As the hw_base increases, so does the hw_ptr increased by the same number. The avail value returned from snd_pcm_avail() could exceed the limit (buffer_size) easily becase the hw_ptr itself got increased by same buffer_size samples when the corner case happens. In following log, the buffer_size is 16368 samples but the avail is 21810 samples so CRAS server complains about it. [ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442 [ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810 cras_server[1907]: pcm_avail returned frames larger than buf_size: sof-glkda7219max: :0,5: 21810 > 16368 By updating runtime->hw_ptr_jiffies each time the HWSYNC is called, the hw_base will keep the same when buffer stall happens at long as the interval between each HWSYNC call is shorter than half of buffer time. Following is a log captured by a patched kernel. The hw_base/hw_ptr value is fixed in this corner case and user space program should be aware of the buffer stall and handle it. [ 293.525543] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 [ 293.525606] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6880 avail 9584 [ 293.525975] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 10976 avail 5488 [ 293.611178] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15072 avail 1392 [ 293.696429] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 ... [ 381.139517] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 Signed-off-by: Brent Lu Reviewed-by: Jaroslav Kysela Cc: Link: https://lore.kernel.org/r/1589776238-23877-1-git-send-email-brent.lu@intel.com Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit a44cb258171820f66d697187d54d9c4592741e0b Author: Scott Bahling Date: Mon May 18 19:57:28 2020 +0200 ALSA: iec1712: Initialize STDSP24 properly when using the model=staudio option commit b0cb099062b0c18246c3a20caaab4c0afc303255 upstream. The ST Audio ADCIII is an STDSP24 card plus extension box. With commit e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") we enabled the ADCIII ports using the model=staudio option but forgot this part to ensure the STDSP24 card is initialized properly. Fixes: e8a91ae18bdc ("ALSA: ice1712: Add support for STAudio ADCIII") Signed-off-by: Scott Bahling Cc: BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1048934 Link: https://lore.kernel.org/r/20200518175728.28766-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 99e392a4979b97562215596acf7f4eff7ec87ae6 Author: Babu Moger Date: Tue May 12 18:59:06 2020 -0500 KVM: x86: Fix pkru save/restore when guest CR4.PKE=0, move it to x86.c commit 37486135d3a7b03acc7755b63627a130437f066a upstream. Though rdpkru and wrpkru are contingent upon CR4.PKE, the PKRU resource isn't. It can be read with XSAVE and written with XRSTOR. So, if we don't set the guest PKRU value here(kvm_load_guest_xsave_state), the guest can read the host value. In case of kvm_load_host_xsave_state, guest with CR4.PKE clear could potentially use XRSTOR to change the host PKRU value. While at it, move pkru state save/restore to common code and the host_pkru field to kvm_vcpu_arch. This will let SVM support protection keys. Cc: stable@vger.kernel.org Reported-by: Jim Mattson Signed-off-by: Babu Moger Message-Id: <158932794619.44260.14508381096663848853.stgit@naples-babu.amd.com> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 1c3d707d7d12b9f7dc845bcc046451aec25c98ef Author: Jian-Hong Pan Date: Tue May 12 14:15:28 2020 +0800 ALSA: hda/realtek: Enable headset mic of ASUS UX581LV with ALC295 [ Upstream commit 7900e81797613b92f855f9921392a7430cbdf88c ] The ASUS UX581LV laptop's audio (1043:19e1) with ALC295 can't detect the headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. Signed-off-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20200512061525.133985-3-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 26a3a305333291b8f37e85095a65ae059c5a83c4 Author: Jian-Hong Pan Date: Tue May 12 14:15:26 2020 +0800 ALSA: hda/realtek - Enable headset mic of ASUS UX550GE with ALC295 [ Upstream commit ad97d667854c2fbce05a004e107f358ef4b04cf6 ] The ASUS laptop UX550GE with ALC295 can't detect the headset microphone until ALC295_FIXUP_ASUS_MIC_NO_PRESENCE quirk applied. Signed-off-by: Jian-Hong Pan Signed-off-by: Daniel Drake Link: https://lore.kernel.org/r/20200512061525.133985-2-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit c5742497dcd2fbb5c1274af3c048302860cf72a1 Author: Chris Chiu Date: Tue May 12 14:15:24 2020 +0800 ALSA: hda/realtek - Enable headset mic of ASUS GL503VM with ALC295 [ Upstream commit 9e43342b464f1de570a3ad8256ac77645749ef45 ] The ASUS laptop GL503VM with ALC295 can't detect the headset microphone. The headset microphone does not work until pin 0x19 is enabled for it. Signed-off-by: Chris Chiu Signed-off-by: Daniel Drake Signed-off-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20200512061525.133985-1-jian-hong@endlessm.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 2523e9010d2bd0b7694721f83434883be1eea8a1 Author: Mike Pozulp Date: Sat May 9 20:28:37 2020 -0700 ALSA: hda/realtek: Add quirk for Samsung Notebook [ Upstream commit 14425f1f521fdfe274a7bb390637c786432e08b4 ] Some models of the Samsung Notebook 9 have very quiet and distorted headphone output. This quirk changes the VREF value of the ALC298 codec NID 0x1a from default HIZ to new 100. [ adjusted to 5.7-base and rearranged in SSID order -- tiwai ] Signed-off-by: Mike Pozulp BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207423 Link: https://lore.kernel.org/r/20200510032838.1989130-1-pozulp.kernel@gmail.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 6cc4dd44e207b1ebe111c71f014a8c31d614c92c Author: Kailang Yang Date: Tue Apr 7 14:52:42 2020 +0800 ALSA: hda/realtek - Add HP new mute led supported for ALC236 [ Upstream commit 24164f434dc9c23cd34fca1e36acea9d0581bdde ] HP new platform has new mute led feature. COEF index 0x34 bit 5 to control playback mute led. COEF index 0x35 bit 2 and bit 3 to control Mic mute led. [ corrected typos by tiwai ] Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/6741211598ba499687362ff2aa30626b@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 0d189b31c4d7ba317d4efd5f5e8325e4d6524160 Author: Kailang Yang Date: Tue Apr 7 14:40:20 2020 +0800 ALSA: hda/realtek - Add supported new mute Led for HP [ Upstream commit 431e76c3edd76d84a0ed1eb81a286b2ddecc5ee4 ] HP Note Book supported new mute Led. Hardware PIN was not enough to meet old LED rule. JD2 to control playback mute led. GPO3 to control capture mute led. (ALC285 didn't control GPO3 via verb command) This two PIN just could control by COEF registers. [ corrected typos by tiwai ] Signed-off-by: Kailang Yang Link: https://lore.kernel.org/r/6741211598ba499687362ff2aa30626b@realtek.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 69d5dc286d05441ca2f854ae8df11201f6f9b706 Author: Takashi Iwai Date: Thu Jan 9 10:01:04 2020 +0100 ALSA: hda: Manage concurrent reg access more properly [ Upstream commit 1a462be52f4505a2719631fb5aa7bfdbd37bfd8d ] In the commit 8e85def5723e ("ALSA: hda: enable regmap internal locking"), we re-enabled the regmap lock due to the reported regression that showed the possible concurrent accesses. It was a temporary workaround, and there are still a few opened races even after the revert. In this patch, we cover those still opened windows with a proper mutex lock and disable the regmap internal lock again. First off, the patch introduces a new snd_hdac_device.regmap_lock mutex that is applied for each snd_hdac_regmap_*() call, including read, write and update helpers. The mutex is applied carefully so that it won't block the self-power-up procedure in the helper function. Also, this assures the protection for the accesses without regmap, too. The snd_hdac_regmap_update_raw() is refactored to use the standard regmap_update_bits_check() function instead of the open-code. The non-regmap case is still open-coded but it's an easy part. The all read and write operations are in the single mutex protection, so it's now race-free. In addition, a couple of new helper functions are added: snd_hdac_regmap_update_raw_once() and snd_hdac_regmap_sync(). Both are called from HD-audio legacy driver. The former is to initialize the given verb bits but only once when it's not initialized yet. Due to this condition, the function invokes regcache_cache_only(), and it's now performed inside the regmap_lock (formerly it was racy) too. The latter function is for simply invoking regcache_sync() inside the regmap_lock, which is called from the codec resume call path. Along with that, the HD-audio codec driver code is slightly modified / simplified to adapt those new functions. And finally, snd_hdac_regmap_read_raw(), *_write_raw(), etc are rewritten with the helper macro. It's just for simplification because the code logic is identical among all those functions. Tested-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200109090104.26073-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1efaaf74528cebe261da423a22af6f3f3ebe8109 Author: Pierre-Louis Bossart Date: Sat Jan 11 15:47:35 2020 -0600 ALSA: hda: patch_realtek: fix empty macro usage in if block [ Upstream commit 8a71821f12a010d7100f9cc1f7b218aff0313c4a ] GCC reports the following warning with W=1 sound/pci/hda/patch_realtek.c: In function ‘alc269_suspend’: sound/pci/hda/patch_realtek.c:3616:29: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 3616 | alc5505_dsp_suspend(codec); | ^ sound/pci/hda/patch_realtek.c: In function ‘alc269_resume’: sound/pci/hda/patch_realtek.c:3651:28: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body] 3651 | alc5505_dsp_resume(codec); | ^ This is a classic macro problem and can indeed lead to bad program flows. Fix by using the usual "do { } while (0)" pattern Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200111214736.3002-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 749e58bd2b09a0f04c6bbbe312b95dcbe4049f38 Author: Michał Mirosław Date: Fri Jan 3 10:23:48 2020 +0100 ALSA: hda - constify and cleanup static NodeID tables [ Upstream commit caf3c0437aaf2e63624c4aaf94c0dd38d1f897e3 ] Make hda_nid_t tables static const, as they are not intended to be modified by callees. Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/5150c94101c9534f4c8e987324f6912c16d459f6.1578043216.git.mirq-linux@rere.qmqm.pl Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 02ebbd1da3945a9344f498f4418ff9287eecb86b Author: Aymeric Agon-Rambosson Date: Thu May 7 18:36:03 2020 -0700 scripts/gdb: repair rb_first() and rb_last() [ Upstream commit 50e36be1fb9572b2e4f2753340bdce3116bf2ce7 ] The current implementations of the rb_first() and rb_last() gdb functions have a variable that references itself in its instanciation, which causes the function to throw an error if a specific condition on the argument is met. The original author rather intended to reference the argument and made a typo. Referring the argument instead makes the function work as intended. Signed-off-by: Aymeric Agon-Rambosson Signed-off-by: Andrew Morton Reviewed-by: Stephen Boyd Cc: Jan Kiszka Cc: Kieran Bingham Cc: Douglas Anderson Cc: Nikolay Borisov Cc: Jackie Liu Cc: Jason Wessel Link: http://lkml.kernel.org/r/20200427051029.354840-1-aymeric.agon@yandex.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 9eff404a438242afea62ce89973ddf6639df5d80 Author: Thomas Gleixner Date: Tue Apr 14 11:07:22 2020 +0200 ARM: futex: Address build warning [ Upstream commit 8101b5a1531f3390b3a69fa7934c70a8fd6566ad ] Stephen reported the following build warning on a ARM multi_v7_defconfig build with GCC 9.2.1: kernel/futex.c: In function 'do_futex': kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized] 1676 | return oldval == cmparg; | ~~~~~~~^~~~~~~~~ kernel/futex.c:1652:6: note: 'oldval' was declared here 1652 | int oldval, ret; | ^~~~~~ introduced by commit a08971e9488d ("futex: arch_futex_atomic_op_inuser() calling conventions change"). While that change should not make any difference it confuses GCC which fails to work out that oldval is not referenced when the return value is not zero. GCC fails to properly analyze arch_futex_atomic_op_inuser(). It's not the early return, the issue is with the assembly macros. GCC fails to detect that those either set 'ret' to 0 and set oldval or set 'ret' to -EFAULT which makes oldval uninteresting. The store to the callsite supplied oldval pointer is conditional on ret == 0. The straight forward way to solve this is to make the store unconditional. Aside of addressing the build warning this makes sense anyway because it removes the conditional from the fastpath. In the error case the stored value is uninteresting and the extra store does not matter at all. Reported-by: Stephen Rothwell Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/87pncao2ph.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit 67a5c3104d126800bc5a2c155713b0b8706c3a57 Author: Peter Xu Date: Mon May 4 18:06:07 2020 -0400 KVM: selftests: Fix build for evmcs.h [ Upstream commit 8ffdaf9155ebe517cdec5edbcca19ba6e7ee9c3c ] I got this error when building kvm selftests: /usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: multiple definition of `current_evmcs'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:222: first defined here /usr/bin/ld: /home/xz/git/linux/tools/testing/selftests/kvm/libkvm.a(vmx.o):/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: multiple definition of `current_vp_assist'; /tmp/cco1G48P.o:/home/xz/git/linux/tools/testing/selftests/kvm/include/evmcs.h:223: first defined here I think it's because evmcs.h is included both in a test file and a lib file so the structs have multiple declarations when linking. After all it's not a good habit to declare structs in the header files. Cc: Vitaly Kuznetsov Signed-off-by: Peter Xu Message-Id: <20200504220607.99627-1-peterx@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit 4f48af814798891affd8653859eaab0230261c20 Author: Aurabindo Pillai Date: Wed Apr 22 14:37:33 2020 -0400 drm/amd/display: Prevent dpcd reads with passive dongles [ Upstream commit e6142dd511425cb827b5db869f489eb81f5f994d ] [why] During hotplug, a DP port may be connected to the sink through passive adapter which does not support DPCD reads. Issuing reads without checking for this condition will result in errors [how] Ensure the link is in aux_mode before initiating operation that result in a DPCD read. Signed-off-by: Aurabindo Pillai Reviewed-by: Harry Wentland Acked-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e0bb3075f91b0e47b0019ad64e86241e3abcd4f0 Author: Joerg Roedel Date: Mon May 4 14:54:11 2020 +0200 iommu/amd: Call domain_flush_complete() in update_domain() [ Upstream commit f44a4d7e4f1cdef73c90b1dc749c4d8a7372a8eb ] The update_domain() function is expected to also inform the hardware about domain changes. This needs a COMPLETION_WAIT command to be sent to all IOMMUs which use the domain. Signed-off-by: Joerg Roedel Tested-by: Qian Cai Link: https://lore.kernel.org/r/20200504125413.16798-4-joro@8bytes.org Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit e1efb9893bdd007f5791c59ee906df0dfb6c39e3 Author: Hans de Goede Date: Thu Apr 23 00:05:59 2020 +0200 platform/x86: asus-nb-wmi: Do not load on Asus T100TA and T200TA [ Upstream commit 3bd12da7f50b8bc191fcb3bab1f55c582234df59 ] asus-nb-wmi does not add any extra functionality on these Asus Transformer books. They have detachable keyboards, so the hotkeys are send through a HID device (and handled by the hid-asus driver) and also the rfkill functionality is not used on these devices. Besides not adding any extra functionality, initializing the WMI interface on these devices actually has a negative side-effect. For some reason the \_SB.ATKD.INIT() function which asus_wmi_platform_init() calls drives GPO2 (INT33FC:02) pin 8, which is connected to the front facing webcam LED, high and there is no (WMI or other) interface to drive this low again causing the LED to be permanently on, even during suspend. This commit adds a blacklist of DMI system_ids on which not to load the asus-nb-wmi and adds these Transformer books to this list. This fixes the webcam LED being permanently on under Linux. Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit c8d323578e36d3b94b41c1bd2093bcf86dd7d754 Author: Alan Stern Date: Fri May 1 16:07:28 2020 -0400 USB: core: Fix misleading driver bug report [ Upstream commit ac854131d9844f79e2fdcef67a7707227538d78a ] The syzbot fuzzer found a race between URB submission to endpoint 0 and device reset. Namely, during the reset we call usb_ep0_reinit() because the characteristics of ep0 may have changed (if the reset follows a firmware update, for example). While usb_ep0_reinit() is running there is a brief period during which the pointers stored in udev->ep_in[0] and udev->ep_out[0] are set to NULL, and if an URB is submitted to ep0 during that period, usb_urb_ep_type_check() will report it as a driver bug. In the absence of those pointers, the routine thinks that the endpoint doesn't exist. The log message looks like this: ------------[ cut here ]------------ usb 2-1: BOGUS urb xfer, pipe 2 != type 2 WARNING: CPU: 0 PID: 9241 at drivers/usb/core/urb.c:478 usb_submit_urb+0x1188/0x1460 drivers/usb/core/urb.c:478 Now, although submitting an URB while the device is being reset is a questionable thing to do, it shouldn't count as a driver bug as severe as submitting an URB for an endpoint that doesn't exist. Indeed, endpoint 0 always exists, even while the device is in its unconfigured state. To prevent these misleading driver bug reports, this patch updates usb_disable_endpoint() to avoid clearing the ep_in[] and ep_out[] pointers when the endpoint being disabled is ep0. There's no danger of leaving a stale pointer in place, because the usb_host_endpoint structure being pointed to is stored permanently in udev->ep0; it doesn't get deallocated until the entire usb_device structure does. Reported-and-tested-by: syzbot+db339689b2101f6f6071@syzkaller.appspotmail.com Signed-off-by: Alan Stern Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.2005011558590.903-100000@netrider.rowland.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 42b32a43529eb07f1e53ac987a027c3dbb6adb45 Author: Maxim Petrov Date: Mon May 4 09:26:43 2020 +0300 stmmac: fix pointer check after utilization in stmmac_interrupt [ Upstream commit f42234ffd531ca6b13d9da02faa60b72eccf8334 ] The paranoidal pointer check in IRQ handler looks very strange - it really protects us only against bogus drivers which request IRQ line with null pointer dev_id. However, the code fragment is incorrect because the dev pointer is used before the actual check which leads to undefined behavior. Remove the check to avoid confusing people with incorrect code. Signed-off-by: Maxim Petrov Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b68d27c5fffd287d64ecbdc570312d668373f1e7 Author: Wu Bo Date: Thu Apr 30 14:12:49 2020 +0800 ceph: fix double unlock in handle_cap_export() [ Upstream commit 4d8e28ff3106b093d98bfd2eceb9b430c70a8758 ] If the ceph_mdsc_open_export_target_session() return fails, it will do a "goto retry", but the session mutex has already been unlocked. Re-lock the mutex in that case to ensure that we don't unlock it twice. Signed-off-by: Wu Bo Reviewed-by: "Yan, Zheng" Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit df0df8ee2ac72809237b04c94cf83fddf412a2b8 Author: Hans de Goede Date: Sat May 2 20:18:42 2020 +0200 HID: quirks: Add HID_QUIRK_NO_INIT_REPORTS quirk for Dell K12A keyboard-dock [ Upstream commit 1e189f267015a098bdcb82cc652d13fbf2203fa0 ] Add a HID_QUIRK_NO_INIT_REPORTS quirk for the Dell K12A keyboard-dock, which can be used with various Dell Venue 11 models. Without this quirk the keyboard/touchpad combo works fine when connected at boot, but when hotplugged 9 out of 10 times it will not work properly. Adding the quirk fixes this. Cc: Mario Limonciello Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 8a5de4a391e4a50e2475c6dfa4a0ca1edc18088c Author: Yoshiyuki Kurauchi Date: Thu Apr 30 14:01:36 2020 +0900 gtp: set NLM_F_MULTI flag in gtp_genl_dump_pdp() [ Upstream commit 846c68f7f1ac82c797a2f1db3344a2966c0fe2e1 ] In drivers/net/gtp.c, gtp_genl_dump_pdp() should set NLM_F_MULTI flag since it returns multipart message. This patch adds a new arg "flags" in gtp_genl_fill_info() so that flags can be set by the callers. Signed-off-by: Yoshiyuki Kurauchi Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7932168ec08e4d841df4e9cba381ca400aa5f3b3 Author: Thomas Gleixner Date: Mon Apr 27 16:55:57 2020 +0200 x86/apic: Move TSC deadline timer debug printk [ Upstream commit c84cb3735fd53c91101ccdb191f2e3331a9262cb ] Leon reported that the printk_once() in __setup_APIC_LVTT() triggers a lockdep splat due to a lock order violation between hrtimer_base::lock and console_sem, when the 'once' condition is reset via /sys/kernel/debug/clear_warn_once after boot. The initial printk cannot trigger this because that happens during boot when the local APIC timer is set up on the boot CPU. Prevent it by moving the printk to a place which is guaranteed to be only called once during boot. Mark the deadline timer check related functions and data __init while at it. Reported-by: Leon Romanovsky Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/87y2qhoshi.fsf@nanos.tec.linutronix.de Signed-off-by: Sasha Levin commit 1ae9f1a62a5093458ab905e8e3cc1836467440c3 Author: Alan Maguire Date: Wed Feb 19 09:33:30 2020 +0000 ftrace/selftest: make unresolved cases cause failure if --fail-unresolved set [ Upstream commit b730d668138cb3dd9ce78f8003986d1adae5523a ] Currently, ftracetest will return 1 (failure) if any unresolved cases are encountered. The unresolved status results from modules and programs not being available, and as such does not indicate any issues with ftrace itself. As such, change the behaviour of ftracetest in line with unsupported cases; if unsupported cases happen, ftracetest still returns 0 unless --fail-unsupported. Here --fail-unresolved is added and the default is to return 0 if unresolved results occur. Signed-off-by: Alan Maguire Acked-by: Masami Hiramatsu Acked-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 2eac9d3dc23ff5e942e5d685272b74bc436279a2 Author: Juliet Kim Date: Thu Apr 30 13:22:11 2020 -0500 ibmvnic: Skip fatal error reset after passive init [ Upstream commit f9c6cea0b38518741c8dcf26ac056d26ee2fd61d ] During MTU change, the following events may happen. Client-driven CRQ initialization fails due to partner’s CRQ closed, causing client to enqueue a reset task for FATAL_ERROR. Then passive (server-driven) CRQ initialization succeeds, causing client to release CRQ and enqueue a reset task for failover. If the passive CRQ initialization occurs before the FATAL reset task is processed, the FATAL error reset task would try to access a CRQ message queue that was freed, causing an oops. The problem may be most likely to occur during DLPAR add vNIC with a non-default MTU, because the DLPAR process will automatically issue a change MTU request. Fix this by not processing fatal error reset if CRQ is passively initialized after client-driven CRQ initialization fails. Signed-off-by: Juliet Kim Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f82a3013226ebc87a8378fd652ec3d297adfbac9 Author: Rick Edgecombe Date: Wed Apr 22 20:13:55 2020 -0700 x86/mm/cpa: Flush direct map alias during cpa [ Upstream commit ab5130186d7476dcee0d4e787d19a521ca552ce9 ] As an optimization, cpa_flush() was changed to optionally only flush the range in @cpa if it was small enough. However, this range does not include any direct map aliases changed in cpa_process_alias(). So small set_memory_() calls that touch that alias don't get the direct map changes flushed. This situation can happen when the virtual address taking variants are passed an address in vmalloc or modules space. In these cases, force a full TLB flush. Note this issue does not extend to cases where the set_memory_() calls are passed a direct map address, or page array, etc, as the primary target. In those cases the direct map would be flushed. Fixes: 935f5839827e ("x86/mm/cpa: Optimize cpa_flush_array() TLB invalidation") Signed-off-by: Rick Edgecombe Signed-off-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20200424105343.GA20730@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit 632db044ab99215c8de3a0761c5e844504710305 Author: Daniel Playfair Cal Date: Sat Apr 25 20:58:17 2020 +1000 HID: i2c-hid: reset Synaptics SYNA2393 on resume [ Upstream commit 538f67407e2c0e5ed2a46e7d7ffa52f2e30c7ef8 ] On the Dell XPS 9570, the Synaptics SYNA2393 touchpad generates spurious interrupts after resuming from suspend until it receives some input or is reset. Add it to the quirk I2C_HID_QUIRK_RESET_ON_RESUME so that it is reset when resuming from suspend. More information about the bug can be found in this mailing list discussion: https://www.spinics.net/lists/linux-input/msg59530.html Signed-off-by: Daniel Playfair Cal Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit acd3efa17d96d09f90c8afa4c2d326296523df5c Author: Tyrel Datwyler Date: Mon Apr 27 15:49:53 2020 -0700 scsi: ibmvscsi: Fix WARN_ON during event pool release [ Upstream commit b36522150e5b85045f868768d46fbaaa034174b2 ] While removing an ibmvscsi client adapter a WARN_ON like the following is seen in the kernel log: drmgr: drmgr: -r -c slot -s U9080.M9S.783AEC8-V11-C11 -w 5 -d 1 WARNING: CPU: 9 PID: 24062 at ../kernel/dma/mapping.c:311 dma_free_attrs+0x78/0x110 Supported: No, Unreleased kernel CPU: 9 PID: 24062 Comm: drmgr Kdump: loaded Tainted: G X 5.3.18-12-default NIP: c0000000001fa758 LR: c0000000001fa744 CTR: c0000000001fa6e0 REGS: c0000002173375d0 TRAP: 0700 Tainted: G X (5.3.18-12-default) MSR: 8000000000029033 CR: 28088282 XER: 20000000 CFAR: c0000000001fbf0c IRQMASK: 1 GPR00: c0000000001fa744 c000000217337860 c00000000161ab00 0000000000000000 GPR04: 0000000000000000 c000011e12250000 0000000018010000 0000000000000000 GPR08: 0000000000000000 0000000000000001 0000000000000001 c0080000190f4fa8 GPR12: c0000000001fa6e0 c000000007fc2a00 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 000000011420e310 0000000000000000 0000000000000000 0000000018010000 GPR28: c00000000159de50 c000011e12250000 0000000000006600 c000011e5c994848 NIP [c0000000001fa758] dma_free_attrs+0x78/0x110 LR [c0000000001fa744] dma_free_attrs+0x64/0x110 Call Trace: [c000000217337860] [000000011420e310] 0x11420e310 (unreliable) [c0000002173378b0] [c0080000190f0280] release_event_pool+0xd8/0x120 [ibmvscsi] [c000000217337930] [c0080000190f3f74] ibmvscsi_remove+0x6c/0x160 [ibmvscsi] [c000000217337960] [c0000000000f3cac] vio_bus_remove+0x5c/0x100 [c0000002173379a0] [c00000000087a0a4] device_release_driver_internal+0x154/0x280 [c0000002173379e0] [c0000000008777cc] bus_remove_device+0x11c/0x220 [c000000217337a60] [c000000000870fc4] device_del+0x1c4/0x470 [c000000217337b10] [c0000000008712a0] device_unregister+0x30/0xa0 [c000000217337b80] [c0000000000f39ec] vio_unregister_device+0x2c/0x60 [c000000217337bb0] [c00800001a1d0964] dlpar_remove_slot+0x14c/0x250 [rpadlpar_io] [c000000217337c50] [c00800001a1d0bcc] remove_slot_store+0xa4/0x110 [rpadlpar_io] [c000000217337cd0] [c000000000c091a0] kobj_attr_store+0x30/0x50 [c000000217337cf0] [c00000000057c934] sysfs_kf_write+0x64/0x90 [c000000217337d10] [c00000000057be10] kernfs_fop_write+0x1b0/0x290 [c000000217337d60] [c000000000488c4c] __vfs_write+0x3c/0x70 [c000000217337d80] [c00000000048c648] vfs_write+0xd8/0x260 [c000000217337dd0] [c00000000048ca8c] ksys_write+0xdc/0x130 [c000000217337e20] [c00000000000b488] system_call+0x5c/0x70 Instruction dump: 7c840074 f8010010 f821ffb1 20840040 eb830218 7c8407b4 48002019 60000000 2fa30000 409e003c 892d0988 792907e0 <0b090000> 2fbd0000 419e0028 2fbc0000 ---[ end trace 5955b3c0cc079942 ]--- rpadlpar_io: slot U9080.M9S.783AEC8-V11-C11 removed This is tripped as a result of irqs being disabled during the call to dma_free_coherent() by release_event_pool(). At this point in the code path we have quiesced the adapter and it is overly paranoid to be holding the host lock. [mkp: fixed build warning reported by sfr] Link: https://lore.kernel.org/r/1588027793-17952-1-git-send-email-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 6ef21295dc20abab7f317219d580670982d2670f Author: Gavin Shan Date: Tue Apr 28 14:49:45 2020 +1000 net/ena: Fix build warning in ena_xdp_set() [ Upstream commit caec66198d137c26f0d234abc498866a58c64150 ] This fixes the following build warning in ena_xdp_set(), which is observed on aarch64 with 64KB page size. In file included from ./include/net/inet_sock.h:19, from ./include/net/ip.h:27, from drivers/net/ethernet/amazon/ena/ena_netdev.c:46: drivers/net/ethernet/amazon/ena/ena_netdev.c: In function \ ‘ena_xdp_set’: \ drivers/net/ethernet/amazon/ena/ena_netdev.c:557:6: warning: \ format ‘%lu’ \ expects argument of type ‘long unsigned int’, but argument 4 \ has type ‘int’ \ [-Wformat=] "Failed to set xdp program, the current MTU (%d) is \ larger than the maximum allowed MTU (%lu) while xdp is on", Signed-off-by: Gavin Shan Acked-by: Shay Agroskin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d0db69f9d132d513c690134d084f5635ed1068d9 Author: James Hilliard Date: Sat Apr 11 13:02:41 2020 -0600 component: Silence bind error on -EPROBE_DEFER [ Upstream commit 7706b0a76a9697021e2bf395f3f065c18f51043d ] If a component fails to bind due to -EPROBE_DEFER we should not log an error as this is not a real failure. Fixes messages like: vc4-drm soc:gpu: failed to bind 3f902000.hdmi (ops vc4_hdmi_ops): -517 vc4-drm soc:gpu: master bind failed: -517 Signed-off-by: James Hilliard Link: https://lore.kernel.org/r/20200411190241.89404-1-james.hilliard1@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7a5f60dc3a67124038bfecc0f6ba2d09ee7f85f3 Author: Richard Clark Date: Sat Apr 25 08:58:11 2020 +0800 aquantia: Fix the media type of AQC100 ethernet controller in the driver [ Upstream commit 6de556c31061e3b9c36546ffaaac5fdb679a2f14 ] The Aquantia AQC100 controller enables a SFP+ port, so the driver should configure the media type as '_TYPE_FIBRE' instead of '_TYPE_TP'. Signed-off-by: Richard Clark Cc: Igor Russkikh Cc: "David S. Miller" Acked-by: Igor Russkikh Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 445437b417b684a6e8ff49b4a939ca27fd5a48ae Author: Stefano Garzarella Date: Fri Apr 24 17:08:29 2020 +0200 vhost/vsock: fix packet delivery order to monitoring devices [ Upstream commit 107bc0766b9feb5113074c753735a3f115c2141f ] We want to deliver packets to monitoring devices before it is put in the virtqueue, to avoid that replies can appear in the packet capture before the transmitted packet. Signed-off-by: Stefano Garzarella Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dcec6678c3b10ac2c31aaf72ff1d0355ec0aec11 Author: Xiyu Yang Date: Sat Apr 25 20:52:26 2020 +0800 configfs: fix config_item refcnt leak in configfs_rmdir() [ Upstream commit 8aebfffacfa379ba400da573a5bf9e49634e38cb ] configfs_rmdir() invokes configfs_get_config_item(), which returns a reference of the specified config_item object to "parent_item" with increased refcnt. When configfs_rmdir() returns, local variable "parent_item" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of configfs_rmdir(). When down_write_killable() fails, the function forgets to decrease the refcnt increased by configfs_get_config_item(), causing a refcnt leak. Fix this issue by calling config_item_put() when down_write_killable() fails. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 2b52a61adb38539d65af19ebb28ff0dab4be3ade Author: Quinn Tran Date: Tue Mar 31 03:40:15 2020 -0700 scsi: qla2xxx: Delete all sessions before unregister local nvme port [ Upstream commit c48f849d3f7a4ec1025105f446e29d395c4dcc2f ] Delete all sessions before unregistering local nvme port. This allows nvme layer to decrement all active rport count down to zero. Once the count is down to zero, nvme would call qla to continue with the npiv port deletion. PID: 27448 TASK: ffff9e34b777c1c0 CPU: 0 COMMAND: "qaucli" 0 [ffff9e25e84abbd8] __schedule at ffffffff977858ca 1 [ffff9e25e84abc68] schedule at ffffffff97785d79 2 [ffff9e25e84abc78] schedule_timeout at ffffffff97783881 3 [ffff9e25e84abd28] wait_for_completion at ffffffff9778612d 4 [ffff9e25e84abd88] qla_nvme_delete at ffffffffc0e3024e [qla2xxx] 5 [ffff9e25e84abda8] qla24xx_vport_delete at ffffffffc0e024b9 [qla2xxx] 6 [ffff9e25e84abdf0] fc_vport_terminate at ffffffffc011c247 [scsi_transport_fc] 7 [ffff9e25e84abe28] store_fc_host_vport_delete at ffffffffc011cd94 [scsi_transport_fc] 8 [ffff9e25e84abe70] dev_attr_store at ffffffff974b376b 9 [ffff9e25e84abe80] sysfs_kf_write at ffffffff972d9a92 10 [ffff9e25e84abe90] kernfs_fop_write at ffffffff972d907b 11 [ffff9e25e84abec8] vfs_write at ffffffff9724c790 12 [ffff9e25e84abf08] sys_write at ffffffff9724d55f 13 [ffff9e25e84abf50] system_call_fastpath at ffffffff97792ed2 RIP: 00007fc0bd81a6fd RSP: 00007ffff78d9648 RFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000022 RCX: 00007ffff78d96e0 RDX: 0000000000000022 RSI: 00007ffff78d94e0 RDI: 0000000000000008 RBP: 00007ffff78d9440 R8: 0000000000000000 R9: 00007fc0bd48b2cd R10: 0000000000000017 R11: 0000000000000293 R12: 0000000000000000 R13: 00005624e4dac840 R14: 00005624e4da9a10 R15: 0000000000000000 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b Link: https://lore.kernel.org/r/20200331104015.24868-4-njavali@marvell.com 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 d2430cb7f2d4aee3eed78865c4763bfbf4e46cb5 Author: Arun Easi Date: Tue Mar 31 03:40:14 2020 -0700 scsi: qla2xxx: Fix hang when issuing nvme disconnect-all in NPIV [ Upstream commit 45a76264c26fd8cfd0c9746196892d9b7e2657ee ] In NPIV environment, a NPIV host may use a queue pair created by base host or other NPIVs, so the check for a queue pair created by this NPIV is not correct, and can cause an abort to fail, which in turn means the NVME command not returned. This leads to hang in nvme_fc layer in nvme_fc_delete_association() which waits for all I/Os to be returned, which is seen as hang in the application. Link: https://lore.kernel.org/r/20200331104015.24868-3-njavali@marvell.com Reviewed-by: Himanshu Madhani Signed-off-by: Arun Easi Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7b481b802a8f95e0a7b74a97db6896ba351effdc Author: Jiri Kosina Date: Wed Apr 15 14:51:42 2020 +0200 HID: alps: ALPS_1657 is too specific; use U1_UNICORN_LEGACY instead [ Upstream commit 185af3e775b693f773d9a4b5a8c3cda69fc8ca0f ] HID_DEVICE_ID_ALPS_1657 PID is too specific, as there are many other ALPS hardware IDs using this particular touchpad. Rename the identifier to HID_DEVICE_ID_ALPS_U1_UNICORN_LEGACY in order to describe reality better. Fixes: 640e403b1fd24 ("HID: alps: Add AUI1657 device ID") Reported-by: Xiaojian Cao Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a08626f6e982425a9eaf2b6195c3b4c46c69402b Author: Artem Borisov Date: Mon Apr 6 03:55:15 2020 +0400 HID: alps: Add AUI1657 device ID [ Upstream commit 640e403b1fd24e7f31ac6f29f0b6a21d285ed729 ] This device is used on Lenovo V130-15IKB variants and uses the same registers as U1. Signed-off-by: Artem Borisov Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 68988c00b153165f024db57be232c3e3efa52ae6 Author: Sebastian Reichel Date: Mon Apr 13 18:02:37 2020 +0200 HID: multitouch: add eGalaxTouch P80H84 support [ Upstream commit f9e82295eec141a0569649d400d249333d74aa91 ] Add support for P80H84 touchscreen from eGalaxy: idVendor 0x0eef D-WAV Scientific Co., Ltd idProduct 0xc002 iManufacturer 1 eGalax Inc. iProduct 2 eGalaxTouch P80H84 2019 vDIVA_1204_T01 k4.02.146 Signed-off-by: Sebastian Reichel Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit cc6428803d22f63886febb62703ab8a1533681d8 Author: Frédéric Pierret (fepitre) Date: Tue Apr 7 13:32:59 2020 +0200 gcc-common.h: Update for GCC 10 [ Upstream commit c7527373fe28f97d8a196ab562db5589be0d34b9 ] Remove "params.h" include, which has been dropped in GCC 10. Remove is_a_helper() macro, which is now defined in gimple.h, as seen when running './scripts/gcc-plugin.sh g++ g++ gcc': In file included from :1: ./gcc-plugins/gcc-common.h:852:13: error: redefinition of ‘static bool is_a_helper::test(U*) [with U = const gimple; T = const ggoto*]’ 852 | inline bool is_a_helper::test(const_gimple gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./gcc-plugins/gcc-common.h:125, from :1: /usr/lib/gcc/x86_64-redhat-linux/10/plugin/include/gimple.h:1037:1: note: ‘static bool is_a_helper::test(U*) [with U = const gimple; T = const ggoto*]’ previously declared here 1037 | is_a_helper ::test (const gimple *gs) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Add -Wno-format-diag to scripts/gcc-plugins/Makefile to avoid meaningless warnings from error() formats used by plugins: scripts/gcc-plugins/structleak_plugin.c: In function ‘int plugin_init(plugin_name_args*, plugin_gcc_version*)’: scripts/gcc-plugins/structleak_plugin.c:253:12: warning: unquoted sequence of 2 consecutive punctuation characters ‘'-’ in format [-Wformat-diag] 253 | error(G_("unknown option '-fplugin-arg-%s-%s'"), plugin_name, argv[i].key); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Signed-off-by: Frédéric Pierret (fepitre) Link: https://lore.kernel.org/r/20200407113259.270172-1-frederic.pierret@qubes-os.org [kees: include -Wno-format-diag for plugin builds] Signed-off-by: Kees Cook Signed-off-by: Sasha Levin commit 3c140d22e3c2b7992abfd4c8db6411669ecc1ab7 Author: Masahiro Yamada Date: Wed Mar 11 15:29:25 2020 +0900 net: drop_monitor: use IS_REACHABLE() to guard net_dm_hw_report() [ Upstream commit 1cd9b3abf5332102d4d967555e7ed861a75094bf ] In net/Kconfig, NET_DEVLINK implies NET_DROP_MONITOR. The original behavior of the 'imply' keyword prevents NET_DROP_MONITOR from being 'm' when NET_DEVLINK=y. With the planned Kconfig change that relaxes the 'imply', the combination of NET_DEVLINK=y and NET_DROP_MONITOR=m would be allowed. Use IS_REACHABLE() to avoid the vmlinux link error for this case. Reported-by: Stephen Rothwell Signed-off-by: Masahiro Yamada Acked-by: Neil Horman Signed-off-by: Sasha Levin commit 87863a7426b2a5a2a668de30c3c90e49eaf30f1c Author: Masahiro Yamada Date: Wed Mar 4 12:20:36 2020 +0900 kbuild: avoid concurrency issue in parallel building dtbs and dtbs_check [ Upstream commit b5154bf63e5577faaaca1d942df274f7de91dd2a ] 'make dtbs_check' checks the shecma in addition to building *.dtb files, in other words, 'make dtbs_check' is a super-set of 'make dtbs'. So, you do not have to do 'make dtbs dtbs_check', but I want to keep the build system as robust as possible in any use. Currently, 'dtbs' and 'dtbs_check' are independent of each other. In parallel building, two threads descend into arch/*/boot/dts/, one for dtbs and the other for dtbs_check, then end up with building the same DTB simultaneously. This commit fixes the concurrency issue. Otherwise, I see build errors like follows: $ make ARCH=arm64 defconfig $ make -j16 ARCH=arm64 DT_SCHEMA_FILES=Documentation/devicetree/bindings/arm/psci.yaml dtbs dtbs_check DTC arch/arm64/boot/dts/qcom/sdm845-cheza-r2.dtb DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb DTC arch/arm64/boot/dts/freescale/imx8mn-evk.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb DTC arch/arm64/boot/dts/zte/zx296718-pcbox.dtb DTC arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p230.dtb DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1254-revA.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dtb DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-inx.dtb DTC arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb CHECK arch/arm64/boot/dts/altera/socfpga_stratix10_socdk.dt.yaml fixdep: error opening file: arch/arm64/boot/dts/allwinner/.sun50i-h6-orangepi-lite2.dtb.d: No such file or directory make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb] Error 2 make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dtb' make[2]: *** Waiting for unfinished jobs.... DTC arch/arm64/boot/dts/rockchip/rk3399-gru-scarlet-kd.dtb DTC arch/arm64/boot/dts/amlogic/meson-gxl-s905d-p231.dtb DTC arch/arm64/boot/dts/xilinx/zynqmp-zc1275-revA.dtb DTC arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dtb fixdep: parse error; no targets found make[2]: *** [scripts/Makefile.lib:296: arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb] Error 1 make[2]: *** Deleting file 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-one-plus.dtb' make[1]: *** [scripts/Makefile.build:505: arch/arm64/boot/dts/allwinner] Error 2 make[1]: *** Waiting for unfinished jobs.... DTC arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dtb Signed-off-by: Masahiro Yamada Reviewed-by: Rob Herring Signed-off-by: Sasha Levin commit 44fd02a3d7194001bc0676bf27511694072d06ee Author: Ricardo Ribalda Delgado Date: Thu Apr 30 15:17:21 2020 +0200 mtd: Fix mtd not registered due to nvmem name collision [ Upstream commit 7b01b7239d0dc9832e0d0d23605c1ff047422a2c ] When the nvmem framework is enabled, a nvmem device is created per mtd device/partition. It is not uncommon that a device can have multiple mtd devices with partitions that have the same name. Eg, when there DT overlay is allowed and the same device with mtd is attached twice. Under that circumstances, the mtd fails to register due to a name duplication on the nvmem framework. With this patch we use the mtdX name instead of the partition name, which is unique. [ 8.948991] sysfs: cannot create duplicate filename '/bus/nvmem/devices/Production Data' [ 8.948992] CPU: 7 PID: 246 Comm: systemd-udevd Not tainted 5.5.0-qtec-standard #13 [ 8.948993] Hardware name: AMD Dibbler/Dibbler, BIOS 05.22.04.0019 10/26/2019 [ 8.948994] Call Trace: [ 8.948996] dump_stack+0x50/0x70 [ 8.948998] sysfs_warn_dup.cold+0x17/0x2d [ 8.949000] sysfs_do_create_link_sd.isra.0+0xc2/0xd0 [ 8.949002] bus_add_device+0x74/0x140 [ 8.949004] device_add+0x34b/0x850 [ 8.949006] nvmem_register.part.0+0x1bf/0x640 ... [ 8.948926] mtd mtd8: Failed to register NVMEM device Fixes: c4dfa25ab307 ("mtd: add support for reading MTD devices via the nvmem API") Signed-off-by: Ricardo Ribalda Delgado Acked-by: Miquel Raynal Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 496c7c61bd64cd62de048e13c43f02b9b962f9a0 Author: David Howells Date: Sun May 17 21:21:05 2020 +0100 afs: Don't unlock fetched data pages until the op completes successfully [ Upstream commit 9d1be4f4dc5ff1c66c86acfd2c35765d9e3776b3 ] Don't call req->page_done() on each page as we finish filling it with the data coming from the network. Whilst this might speed up the application a bit, it's a problem if there's a network failure and the operation has to be reissued. If this happens, an oops occurs because afs_readpages_page_done() clears the pointer to each page it unlocks and when a retry happens, the pointers to the pages it wants to fill are now NULL (and the pages have been unlocked anyway). Instead, wait till the operation completes successfully and only then release all the pages after clearing any terminal gap (the server can give us less data than we requested as we're allowed to ask for more than is available). KASAN produces a bug like the following, and even without KASAN, it can oops and panic. BUG: KASAN: wild-memory-access in _copy_to_iter+0x323/0x5f4 Write of size 1404 at addr 0005088000000000 by task md5sum/5235 CPU: 0 PID: 5235 Comm: md5sum Not tainted 5.7.0-rc3-fscache+ #250 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: memcpy+0x39/0x58 _copy_to_iter+0x323/0x5f4 __skb_datagram_iter+0x89/0x2a6 skb_copy_datagram_iter+0x129/0x135 rxrpc_recvmsg_data.isra.0+0x615/0xd42 rxrpc_kernel_recv_data+0x1e9/0x3ae afs_extract_data+0x139/0x33a yfs_deliver_fs_fetch_data64+0x47a/0x91b afs_deliver_to_call+0x304/0x709 afs_wait_for_call_to_complete+0x1cc/0x4ad yfs_fs_fetch_data+0x279/0x288 afs_fetch_data+0x1e1/0x38d afs_readpages+0x593/0x72e read_pages+0xf5/0x21e __do_page_cache_readahead+0x128/0x23f ondemand_readahead+0x36e/0x37f generic_file_buffered_read+0x234/0x680 new_sync_read+0x109/0x17e vfs_read+0xe6/0x138 ksys_read+0xd8/0x14d do_syscall_64+0x6e/0x8a entry_SYSCALL_64_after_hwframe+0x49/0xb3 Fixes: 196ee9cd2d04 ("afs: Make afs_fs_fetch_data() take a list of pages") Fixes: 30062bd13e36 ("afs: Implement YFS support in the fs client") Signed-off-by: David Howells Reviewed-by: Matthew Wilcox (Oracle) Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 17c9595cca7177aa748665fbfa0e33b67ea5dc94 Author: Richard Weinberger Date: Sat May 2 14:48:02 2020 +0200 ubi: Fix seq_file usage in detailed_erase_block_info debugfs file [ Upstream commit 0e7572cffe442290c347e779bf8bd4306bb0aa7c ] 3bfa7e141b0b ("fs/seq_file.c: seq_read(): add info message about buggy .next functions") showed that we don't use seq_file correctly. So make sure that our ->next function always updates the position. Fixes: 7bccd12d27b7 ("ubi: Add debugfs file for tracking PEB state") Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 274cd3c7b5d3e11e7dd724e31e8ff7ddf82e5694 Author: Christophe JAILLET Date: Wed May 6 21:21:00 2020 +0200 i2c: mux: demux-pinctrl: Fix an error handling path in 'i2c_demux_pinctrl_probe()' [ Upstream commit e9d1a0a41d4486955e96552293c1fcf1fce61602 ] A call to 'i2c_demux_deactivate_master()' is missing in the error handling path, as already done in the remove function. Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver") Signed-off-by: Christophe JAILLET Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit dd540f2d7c2d7f34b00161fce00f1e05a352f4f3 Author: Dan Carpenter Date: Tue May 12 16:19:17 2020 +0300 evm: Fix a small race in init_desc() [ Upstream commit 8433856947217ebb5697a8ff9c4c9cad4639a2cf ] The IS_ERR_OR_NULL() function has two conditions and if we got really unlucky we could hit a race where "ptr" started as an error pointer and then was set to NULL. Both conditions would be false even though the pointer at the end was NULL. This patch fixes the problem by ensuring that "*tfm" can only be NULL or valid. I have introduced a "tmp_tfm" variable to make that work. I also reversed a condition and pulled the code in one tab. Reported-by: Roberto Sassu Fixes: 53de3b080d5e ("evm: Check also if *tfm is an error pointer in init_desc()") Signed-off-by: Dan Carpenter Acked-by: Roberto Sassu Acked-by: Krzysztof Struczynski Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit f96ab0d1f3ec59f5e608a0869d9169ae0a53971d Author: Alexander Monakov Date: Mon May 11 10:23:52 2020 +0000 iommu/amd: Fix over-read of ACPI UID from IVRS table [ Upstream commit e461b8c991b9202b007ea2059d953e264240b0c9 ] IVRS parsing code always tries to read 255 bytes from memory when retrieving ACPI device path, and makes an assumption that firmware provides a zero-terminated string. Both of those are bugs: the entry is likely to be shorter than 255 bytes, and zero-termination is not guaranteed. With Acer SF314-42 firmware these issues manifest visibly in dmesg: AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR0\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR1\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR2\xf0\xa5, rdevid:160 AMD-Vi: ivrs, add hid:AMDI0020, uid:\_SB.FUR3>\x83e\x8d\x9a\xd1... The first three lines show how the code over-reads adjacent table entries into the UID, and in the last line it even reads garbage data beyond the end of the IVRS table itself. Since each entry has the length of the UID (uidl member of ivhd_entry struct), use that for memcpy, and manually add a zero terminator. Avoid zero-filling hid and uid arrays up front, and instead ensure the uid array is always zero-terminated. No change needed for the hid array, as it was already properly zero-terminated. Fixes: 2a0cb4e2d423c ("iommu/amd: Add new map for storing IVHD dev entry type HID") Signed-off-by: Alexander Monakov Cc: Joerg Roedel Cc: iommu@lists.linux-foundation.org Link: https://lore.kernel.org/r/20200511102352.1831-1-amonakov@ispras.ru Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 33769c19feba67c484350810431db7c62f88923f Author: Alain Volmat Date: Thu Apr 30 17:43:21 2020 +0200 i2c: fix missing pm_runtime_put_sync in i2c_device_probe [ Upstream commit 3c3dd56f760da056e821ac177e3ad0de4209a435 ] In case of the I2C client exposes the flag I2C_CLIENT_HOST_NOTIFY, pm_runtime_get_sync is called in order to always keep active the adapter. However later on, pm_runtime_put_sync is never called within the function in case of an error. This commit add this error handling. Fixes: 72bfcee11cf8 ("i2c: Prevent runtime suspend of adapter when Host Notify is required") Signed-off-by: Alain Volmat Reviewed-by: Jarkko Nikula Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 9f885f17501d57fbb45d5de709adc9bf2223d8c7 Author: Christoph Hellwig Date: Thu Apr 9 13:33:05 2020 +0200 ubifs: remove broken lazytime support [ Upstream commit ecf84096a526f2632ee85c32a3d05de3fa60ce80 ] When "ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs" introduced atime support to ubifs, it also added lazytime support. As far as I can tell the lazytime support is terminally broken, as it causes mark_inode_dirty_sync to be called from __writeback_single_inode, which will then trigger the locking assert in ubifs_dirty_inode. Just remove the broken lazytime support for now, it can be added back later, especially as some infrastructure changes should make that easier soon. Fixes: 8c1c5f263833 ("ubifs: introduce UBIFS_ATIME_SUPPORT to ubifs") Signed-off-by: Christoph Hellwig Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit ac6f94d3be65c88b9e56f8921b8bef40c9b13576 Author: Al Viro Date: Tue May 19 17:48:52 2020 -0400 fix multiplication overflow in copy_fdtable() [ Upstream commit 4e89b7210403fa4a8acafe7c602b6212b7af6c3b ] cpy and set really should be size_t; we won't get an overflow on that, since sysctl_nr_open can't be set above ~(size_t)0 / sizeof(void *), so nr that would've managed to overflow size_t on that multiplication won't get anywhere near copy_fdtable() - we'll fail with EMFILE before that. Cc: stable@kernel.org # v2.6.25+ Fixes: 9cfe015aa424 (get rid of NR_OPEN and introduce a sysctl_nr_open) Reported-by: Thiago Macieira Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 725b0bb0f94d384d4cea2baedcf44b84041ff03e Author: Miquel Raynal Date: Wed May 13 15:10:29 2020 +0200 mtd: spinand: Propagate ECC information to the MTD structure [ Upstream commit 3507273d5a4d3c2e46f9d3f9ed9449805f5dff07 ] This is done by default in the raw NAND core (nand_base.c) but was missing in the SPI-NAND core. Without these two lines the ecc_strength and ecc_step_size values are not exported to the user through sysfs. Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs") Cc: stable@vger.kernel.org Signed-off-by: Miquel Raynal Reviewed-by: Boris Brezillon Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit e3637eb6a35182f5432f6e3c647cc84c86765d18 Author: Rafael J. Wysocki Date: Fri May 15 12:58:19 2020 +0200 ACPI: EC: PM: Avoid flushing EC work when EC GPE is inactive [ Upstream commit 607b9df63057a56f6172d560d5366cca6a030c76 ] Flushing the EC work while suspended to idle when the EC GPE status is not set causes some EC wakeup events (notably power button and lid ones) to be missed after a series of spurious wakeups on the Dell XPS13 9360 in my office. If that happens, the machine cannot be woken up from suspend-to-idle by the power button or lid status change and it needs to be woken up in some other way (eg. by a key press). Flushing the EC work only after successful dispatching the EC GPE, which means that its status has been set, avoids the issue, so change the code in question accordingly. Fixes: 7b301750f7f8 ("ACPI: EC: PM: Avoid premature returns from acpi_s2idle_wake()") Cc: 5.4+ # 5.4+ Signed-off-by: Rafael J. Wysocki Tested-by: Chris Chiu Signed-off-by: Sasha Levin commit 3be8ece11440af5695544abe192ae0d1e251692f Author: Eric Biggers Date: Fri May 1 22:59:45 2020 -0700 ubifs: fix wrong use of crypto_shash_descsize() [ Upstream commit 3c3c32f85b6cc05e5db78693457deff03ac0f434 ] crypto_shash_descsize() returns the size of the shash_desc context needed to compute the hash, not the size of the hash itself. crypto_shash_digestsize() would be correct, or alternatively using c->hash_len and c->hmac_desc_len which already store the correct values. But actually it's simpler to just use stack arrays, so do that instead. Fixes: 49525e5eecca ("ubifs: Add helper functions for authentication support") Fixes: da8ef65f9573 ("ubifs: Authenticate replayed journal") Cc: # v4.20+ Cc: Sascha Hauer Signed-off-by: Eric Biggers Acked-by: Sascha Hauer Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 48bbd44f5fa97bae6926f78d2a8a8287819625a2 Author: Roberto Sassu Date: Mon Apr 27 12:31:28 2020 +0200 ima: Fix return value of ima_write_policy() [ Upstream commit 2e3a34e9f409ebe83d1af7cd2f49fca7af97dfac ] This patch fixes the return value of ima_write_policy() when a new policy is directly passed to IMA and the current policy requires appraisal of the file containing the policy. Currently, if appraisal is not in ENFORCE mode, ima_write_policy() returns 0 and leads user space applications to an endless loop. Fix this issue by denying the operation regardless of the appraisal mode. Cc: stable@vger.kernel.org # 4.10.x Fixes: 19f8a84713edc ("ima: measure and appraise the IMA policy itself") Signed-off-by: Roberto Sassu Reviewed-by: Krzysztof Struczynski Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 1066327bf9369ab046d14807fdaeb7cb5c285bdb Author: Roberto Sassu Date: Mon Apr 27 12:28:56 2020 +0200 evm: Check also if *tfm is an error pointer in init_desc() [ Upstream commit 53de3b080d5eae31d0de219617155dcc34e7d698 ] This patch avoids a kernel panic due to accessing an error pointer set by crypto_alloc_shash(). It occurs especially when there are many files that require an unsupported algorithm, as it would increase the likelihood of the following race condition: Task A: *tfm = crypto_alloc_shash() <= error pointer Task B: if (*tfm == NULL) <= *tfm is not NULL, use it Task B: rc = crypto_shash_init(desc) <= panic Task A: *tfm = NULL This patch uses the IS_ERR_OR_NULL macro to determine whether or not a new crypto context must be created. Cc: stable@vger.kernel.org Fixes: d46eb3699502b ("evm: crypto hash replaced by shash") Co-developed-by: Krzysztof Struczynski Signed-off-by: Krzysztof Struczynski Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit 4aedc534b608167b2d0fc42a09bae101a612a7c7 Author: Roberto Sassu Date: Mon Apr 27 12:28:55 2020 +0200 ima: Set file->f_mode instead of file->f_flags in ima_calc_file_hash() [ Upstream commit 0014cc04e8ec077dc482f00c87dfd949cfe2b98f ] Commit a408e4a86b36 ("ima: open a new file instance if no read permissions") tries to create a new file descriptor to calculate a file digest if the file has not been opened with O_RDONLY flag. However, if a new file descriptor cannot be obtained, it sets the FMODE_READ flag to file->f_flags instead of file->f_mode. This patch fixes this issue by replacing f_flags with f_mode as it was before that commit. Cc: stable@vger.kernel.org # 4.20.x Fixes: a408e4a86b36 ("ima: open a new file instance if no read permissions") Signed-off-by: Roberto Sassu Reviewed-by: Goldwyn Rodrigues Signed-off-by: Mimi Zohar Signed-off-by: Sasha Levin commit ac46cea606d59be18a6afd4560c48bcca836c44c Author: Miaohe Lin Date: Sat Jan 4 16:56:49 2020 +0800 KVM: SVM: Fix potential memory leak in svm_cpu_init() commit d80b64ff297e40c2b6f7d7abc1b3eba70d22a068 upstream. When kmalloc memory for sd->sev_vmcbs failed, we forget to free the page held by sd->save_area. Also get rid of the var r as '-ENOMEM' is actually the only possible outcome here. Reviewed-by: Liran Alon Reviewed-by: Vitaly Kuznetsov Signed-off-by: Miaohe Lin Signed-off-by: Paolo Bonzini Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman commit 1bed86cfe5cb4529d036a14980d379aee8539982 Author: Kevin Hao Date: Fri Oct 11 23:00:14 2019 +0800 i2c: dev: Fix the race between the release of i2c_dev and cdev commit 1413ef638abae4ab5621901cf4d8ef08a4a48ba6 upstream. The struct cdev is embedded in the struct i2c_dev. In the current code, we would free the i2c_dev struct directly in put_i2c_dev(), but the cdev is manged by a kobject, and the release of it is not predictable. So it is very possible that the i2c_dev is freed before the cdev is entirely released. We can easily get the following call trace with CONFIG_DEBUG_KOBJECT_RELEASE and CONFIG_DEBUG_OBJECTS_TIMERS enabled. ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x38 WARNING: CPU: 19 PID: 1 at lib/debugobjects.c:325 debug_print_object+0xb0/0xf0 Modules linked in: CPU: 19 PID: 1 Comm: swapper/0 Tainted: G W 5.2.20-yocto-standard+ #120 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 80c00089 (Nzcv daIf +PAN +UAO) pc : debug_print_object+0xb0/0xf0 lr : debug_print_object+0xb0/0xf0 sp : ffff00001292f7d0 x29: ffff00001292f7d0 x28: ffff800b82151788 x27: 0000000000000001 x26: ffff800b892c0000 x25: ffff0000124a2558 x24: 0000000000000000 x23: ffff00001107a1d8 x22: ffff0000116b5088 x21: ffff800bdc6afca8 x20: ffff000012471ae8 x19: ffff00001168f2c8 x18: 0000000000000010 x17: 00000000fd6f304b x16: 00000000ee79de43 x15: ffff800bc0e80568 x14: 79616c6564203a74 x13: 6e6968207473696c x12: 5f72656d6974203a x11: ffff0000113f0018 x10: 0000000000000000 x9 : 000000000000001f x8 : 0000000000000000 x7 : ffff0000101294cc x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000001 x3 : 00000000ffffffff x2 : 0000000000000000 x1 : 387fc15c8ec0f200 x0 : 0000000000000000 Call trace: debug_print_object+0xb0/0xf0 __debug_check_no_obj_freed+0x19c/0x228 debug_check_no_obj_freed+0x1c/0x28 kfree+0x250/0x440 put_i2c_dev+0x68/0x78 i2cdev_detach_adapter+0x60/0xc8 i2cdev_notifier_call+0x3c/0x70 notifier_call_chain+0x8c/0xe8 blocking_notifier_call_chain+0x64/0x88 device_del+0x74/0x380 device_unregister+0x54/0x78 i2c_del_adapter+0x278/0x2d0 unittest_i2c_bus_remove+0x3c/0x80 platform_drv_remove+0x30/0x50 device_release_driver_internal+0xf4/0x1c0 driver_detach+0x58/0xa0 bus_remove_driver+0x84/0xd8 driver_unregister+0x34/0x60 platform_driver_unregister+0x20/0x30 of_unittest_overlay+0x8d4/0xbe0 of_unittest+0xae8/0xb3c do_one_initcall+0xac/0x450 do_initcall_level+0x208/0x224 kernel_init_freeable+0x2d8/0x36c kernel_init+0x18/0x108 ret_from_fork+0x10/0x1c irq event stamp: 3934661 hardirqs last enabled at (3934661): [] debug_exception_exit+0x4c/0x58 hardirqs last disabled at (3934660): [] debug_exception_enter+0xa4/0xe0 softirqs last enabled at (3934654): [] __do_softirq+0x46c/0x628 softirqs last disabled at (3934649): [] irq_exit+0x104/0x118 This is a common issue when using cdev embedded in a struct. Fortunately, we already have a mechanism to solve this kind of issue. Please see commit 233ed09d7fda ("chardev: add helper function to register char devs with a struct device") for more detail. In this patch, we choose to embed the struct device into the i2c_dev, and use the API provided by the commit 233ed09d7fda to make sure that the release of i2c_dev and cdev are in sequence. Signed-off-by: Kevin Hao Signed-off-by: Wolfram Sang Cc: Ben Hutchings Signed-off-by: Greg Kroah-Hartman