commit db9c9abbbc1da05c7894b47f9943a2e8038151c0 Author: Alexandre Frade Date: Sun Jan 5 10:23:47 2020 -0300 5.4.8-xanmod5 Signed-off-by: Alexandre Frade commit 7ac27b84e88bb3abad2e473fd52511c12ceb622d Merge: c7efd7e5d687 5825c88e9651 Author: Alexandre Frade Date: Sun Jan 5 10:13:38 2020 -0300 Merge tag 'v5.4.8' into 5.4 This is the 5.4.8 stable release commit c7efd7e5d687f2cea431b8080fa98180323d3f6e Author: Alexandre Frade Date: Sun Jan 5 10:01:50 2020 -0300 sched/core: Increase nr_migrate to 256 tasks to iterate in a single balance run Signed-off-by: Alexandre Frade commit 4e309d847989d1aa4cfbb0f4a8e791b75435823d Author: Gabriel Krisman Bertazi Date: Sun Jan 5 09:54:19 2020 -0300 futex: Add support for multiple keys at the same time Split the futex key setup from the queue locking and key reading. This is useful to support the setup of multiple keys at the same time, like what is done in futex_requeue() and what will be done for the FUTEX_WAIT_MULTIPLE command. Signed-off-by: Gabriel Krisman Bertazi commit 050223869257b87e22636158a80da38d877248ed Author: Arjan van de Ven Date: Sun Feb 18 23:35:41 2018 +0000 locking: rwsem: spin faster tweak rwsem owner spinning a bit commit c2417a85bd30e3c4b5f25b1fe65d0ebfea9178f1 Author: J. R. Okajima Date: Sun Jan 5 09:43:52 2020 -0300 fs: Introduce the Advanced Multi Layered Unification Filesystem version aufs5.4 20191223 commit 5825c88e96518d8793f99e8c70aa0b0396642b45 Author: Greg Kroah-Hartman Date: Sat Jan 4 19:19:19 2020 +0100 Linux 5.4.8 commit 1cab43eb6137928106364340a5287b29ce3552f1 Author: Jan Stancek Date: Fri Jan 3 18:37:18 2020 +0100 mm/hugetlbfs: fix for_each_hstate() loop in init_hugetlbfs_fs() commit 15f0ec941f4f908fefa23a30ded8358977cc1cc0 upstream. LTP memfd_create04 started failing for some huge page sizes after v5.4-10135-gc3bfc5dd73c6. The problem is the check introduced to for_each_hstate() loop that should skip default_hstate_idx. Since it doesn't update 'i' counter, all subsequent huge page sizes are skipped as well. Fixes: 8fc312b32b25 ("mm/hugetlbfs: fix error handling when setting up mounts") Signed-off-by: Jan Stancek Reviewed-by: Mike Kravetz Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 596180c2110c1848fe2ccf885245745658d98079 Author: Yangbo Lu Date: Thu Dec 19 11:23:35 2019 +0800 mmc: sdhci-of-esdhc: re-implement erratum A-009204 workaround [ Upstream commit f667216c5c7c967c3e568cdddefb51fe606bfe26 ] The erratum A-009204 workaround patch was reverted because of incorrect implementation. 8b6dc6b mmc: sdhci-of-esdhc: Revert "mmc: sdhci-of-esdhc: add erratum A-009204 support" This patch is to re-implement the workaround (add a 5 ms delay before setting SYSCTL[RSTD] to make sure all the DMA transfers are finished). Signed-off-by: Yangbo Lu Link: https://lore.kernel.org/r/20191219032335.26528-1-yangbo.lu@nxp.com Fixes: 5dd195522562 ("mmc: sdhci-of-esdhc: add erratum A-009204 support") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit 79bd72bd2f97099265eacbc248a44b60d1072dbd Author: Yangbo Lu Date: Wed Oct 9 15:41:40 2019 +0800 mmc: sdhci-of-esdhc: fix up erratum A-008171 workaround [ Upstream commit 22dc132d5448db1b1c021de0c34aa8033ca7d98f ] A previous patch implemented an incomplete workaround of erratum A-008171. The complete workaround is as below. This patch is to implement the complete workaround which uses SW tuning if HW tuning fails, and retries both HW/SW tuning once with reduced clock if workaround fails. This is suggested by hardware team, and the patch had been verified on LS1046A eSDHC + Phison 32G eMMC which could trigger the erratum. Workaround: /* For T1040, T2080, LS1021A, T1023 Rev 1: */ 1. Program TBPTR[TB_WNDW_END_PTR] = 3*DIV_RATIO. 2. Program TBPTR[TB_WNDW_START_PTR] = 5*DIV_RATIO. 3. Program the software tuning mode by setting TBCTL[TB_MODE] = 2'h3. 4. Set SYSCTL2[EXTN] and SYSCTL2[SAMPCLKSEL]. 5. Issue SEND_TUNING_BLK Command (CMD19 for SD, CMD21 for MMC). 6. Wait for IRQSTAT[BRR], buffer read ready, to be set. 7. Clear IRQSTAT[BRR]. 8. Check SYSCTL2[EXTN] to be cleared. 9. Check SYSCTL2[SAMPCLKSEL], Sampling Clock Select. It's set value indicate tuning procedure success, and clear indicate failure. In case of tuning failure, fixed sampling scheme could be used by clearing TBCTL[TB_EN]. /* For LS1080A Rev 1, LS2088A Rev 1.0, LA1575A Rev 1.0: */ 1. Read the TBCTL[31:0] register. Write TBCTL[11:8]=4'h8 and wait for 1ms. 2. Read the TBCTL[31:0] register and rewrite again. Wait for 1ms second. 3. Read the TBSTAT[31:0] register twice. 3.1 Reset data lines by setting ESDHCCTL[RSTD] bit. 3.2 Check ESDHCCTL[RSTD] bit. 3.3 If ESDHCCTL[RSTD] is 0, go to step 3.4 else go to step 3.2. 3.4 Write 32'hFFFF_FFFF to IRQSTAT register. 4. if TBSTAT[15:8]-TBSTAT[7:0] > 4*DIV_RATIO or TBSTAT[7:0]-TBSTAT[15:8] > 4*DIV_RATIO , then program TBPTR[TB_WNDW_END_PTR] = 4*DIV_RATIO and program TBPTR[TB_WNDW_START_PTR] = 8*DIV_RATIO. /* For LS1012A Rev1, LS1043A Rev 1.x, LS1046A 1.0: */ 1. Read the TBCTL[0:31] register. Write TBCTL[20:23]=4'h8 and wait for 1ms. 2. Read the TBCTL[0:31] register and rewrite again. Wait for 1ms second. 3. Read the TBSTAT[0:31] register twice. 3.1 Reset data lines by setting ESDHCCTL[RSTD] bit. 3.2 Check ESDHCCTL[RSTD] bit. 3.3 If ESDHCCTL[RSTD] is 0, go to step 3.4 else go to step 3.2. 3.4 Write 32'hFFFF_FFFF to IRQSTAT register. 4. if TBSTAT[16:23]-TBSTAT[24:31] > 4*DIV_RATIO or TBSTAT[24:31]- TBSTAT[16:23] > 4* DIV_RATIO , then program TBPTR[TB_WNDW_END_PTR] = 4*DIV_RATIO and program TBPTR[TB_WNDW_START_PTR] = 8*DIV_RATIO. /* For LS1080A Rev 1, LS2088A Rev 1.0, LA1575A Rev 1.0 LS1012A Rev1, * LS1043A Rev 1.x, LS1046A 1.0: */ 5. else program TBPTR[TB_WNDW_END_PTR] = 3*DIV_RATIO and program TBPTR[TB_WNDW_START_PTR] = 5*DIV_RATIO. 6. Program the software tuning mode by setting TBCTL[TB_MODE] = 2'h3. 7. Set SYSCTL2[EXTN], wait 1us and SYSCTL2[SAMPCLKSEL]. 8. Issue SEND_TUNING_BLK Command (CMD19 for SD, CMD21 for MMC). 9. Wait for IRQSTAT[BRR], buffer read ready, to be set. 10. Clear IRQSTAT[BRR]. 11. Check SYSCTL2[EXTN] to be cleared. 12. Check SYSCTL2[SAMPCLKSEL], Sampling Clock Select. It's set value indicate tuning procedure success, and clear indicate failure. In case of tuning failure, fixed sampling scheme could be used by clearing TBCTL[TB_EN]. Fixes: b1f378ab5334 ("mmc: sdhci-of-esdhc: add erratum A008171 support") Signed-off-by: Yinbo Zhu Signed-off-by: Yangbo Lu Acked-by: Adrian Hunter Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit bb9aab7844fc59d6ec6ebcc9ca9362946f36a095 Author: Stefano Garzarella Date: Fri Dec 6 15:39:12 2019 +0100 vhost/vsock: accept only packets with the right dst_cid [ Upstream commit 8a3cc29c316c17de590e3ff8b59f3d6cbfd37b0a ] When we receive a new packet from the guest, we check if the src_cid is correct, but we forgot to check the dst_cid. The host should accept only packets where dst_cid is equal to the host CID. Signed-off-by: Stefano Garzarella Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 252ac779a46de92f0e695267feca35443d566594 Author: Netanel Belgazal Date: Tue Dec 10 11:27:44 2019 +0000 net: ena: fix napi handler misbehavior when the napi budget is zero [ Upstream commit 24dee0c7478d1a1e00abdf5625b7f921467325dc ] In netpoll the napi handler could be called with budget equal to zero. Current ENA napi handler doesn't take that into consideration. The napi handler handles Rx packets in a do-while loop. Currently, the budget check happens only after decrementing the budget, therefore the napi handler, in rare cases, could run over MAX_INT packets. In addition to that, this moves all budget related variables to int calculation and stop mixing u32 to avoid ambiguity Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Netanel Belgazal Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 06067fd5a24b01957d5ca67192280f9e80b4bd6f Author: Russell King Date: Fri Dec 13 10:06:30 2019 +0000 net: phylink: fix interface passed to mac_link_up [ Upstream commit 9b2079c046a9d6c9c73a4ec33816678565ee01f3 ] A mismerge between the following two commits: c678726305b9 ("net: phylink: ensure consistent phy interface mode") 27755ff88c0e ("net: phylink: Add phylink_mac_link_{up, down} wrapper functions") resulted in the wrong interface being passed to the mac_link_up() function. Fix this up. Fixes: b4b12b0d2f02 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net") Signed-off-by: Russell King Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 8fa4ec03512d603efdd22d7a9bc45a22a99d122f Author: Hangbin Liu Date: Wed Dec 11 22:20:16 2019 +0800 ipv6/addrconf: only check invalid header values when NETLINK_F_STRICT_CHK is set [ Upstream commit 2beb6d2901a3f73106485d560c49981144aeacb1 ] In commit 4b1373de73a3 ("net: ipv6: addr: perform strict checks also for doit handlers") we add strict check for inet6_rtm_getaddr(). But we did the invalid header values check before checking if NETLINK_F_STRICT_CHK is set. This may break backwards compatibility if user already set the ifm->ifa_prefixlen, ifm->ifa_flags, ifm->ifa_scope in their netlink code. I didn't move the nlmsg_len check because I thought it's a valid check. Reported-by: Jianlin Shi Fixes: 4b1373de73a3 ("net: ipv6: addr: perform strict checks also for doit handlers") Signed-off-by: Hangbin Liu Reviewed-by: David Ahern Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3f54d3349a21d0942531ff0f87001086fe31e731 Author: Jonathan Lemon Date: Tue Dec 10 08:39:46 2019 -0800 bnxt: apply computed clamp value for coalece parameter [ Upstream commit 6adc4601c2a1ac87b4ab8ed0cb55db6efd0264e8 ] After executing "ethtool -C eth0 rx-usecs-irq 0", the box becomes unresponsive, likely due to interrupt livelock. It appears that a minimum clamp value for the irq timer is computed, but is never applied. Fix by applying the corrected clamp value. Fixes: 74706afa712d ("bnxt_en: Update interrupt coalescing logic.") Signed-off-by: Jonathan Lemon Signed-off-by: Michael Chan Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit de2dd4bc5e665fdbd2d5dde24b33938093cb81f5 Author: Taehee Yoo Date: Wed Dec 11 08:23:00 2019 +0000 gtp: do not allow adding duplicate tid and ms_addr pdp context [ Upstream commit 6b01b1d9b2d38dc84ac398bfe9f00baff06a31e5 ] GTP RX packet path lookups pdp context with TID. If duplicate TID pdp contexts are existing in the list, it couldn't select correct pdp context. So, TID value should be unique. GTP TX packet path lookups pdp context with ms_addr. If duplicate ms_addr pdp contexts are existing in the list, it couldn't select correct pdp context. So, ms_addr value should be unique. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c185e1d6e2752a4b656c3ca878c525fa11f55757 Author: Taehee Yoo Date: Wed Dec 11 08:23:34 2019 +0000 gtp: fix an use-after-free in ipv4_pdp_find() [ Upstream commit 94dc550a5062030569d4aa76e10e50c8fc001930 ] ipv4_pdp_find() is called in TX packet path of GTP. ipv4_pdp_find() internally uses gtp->tid_hash to lookup pdp context. In the current code, gtp->tid_hash and gtp->addr_hash are freed by ->dellink(), which is gtp_dellink(). But gtp_dellink() would be called while packets are processing. So, gtp_dellink() should not free gtp->tid_hash and gtp->addr_hash. Instead, dev->priv_destructor() would be used because this callback is called after all packet processing safely. Test commands: ip link add veth1 type veth peer name veth2 ip a a 172.0.0.1/24 dev veth1 ip link set veth1 up ip a a 172.99.0.1/32 dev lo gtp-link add gtp1 & gtp-tunnel add gtp1 v1 200 100 172.99.0.2 172.0.0.2 ip r a 172.99.0.2/32 dev gtp1 ip link set gtp1 mtu 1500 ip netns add ns2 ip link set veth2 netns ns2 ip netns exec ns2 ip a a 172.0.0.2/24 dev veth2 ip netns exec ns2 ip link set veth2 up ip netns exec ns2 ip a a 172.99.0.2/32 dev lo ip netns exec ns2 ip link set lo up ip netns exec ns2 gtp-link add gtp2 & ip netns exec ns2 gtp-tunnel add gtp2 v1 100 200 172.99.0.1 172.0.0.1 ip netns exec ns2 ip r a 172.99.0.1/32 dev gtp2 ip netns exec ns2 ip link set gtp2 mtu 1500 hping3 172.99.0.2 -2 --flood & ip link del gtp1 Splat looks like: [ 72.568081][ T1195] BUG: KASAN: use-after-free in ipv4_pdp_find.isra.12+0x130/0x170 [gtp] [ 72.568916][ T1195] Read of size 8 at addr ffff8880b9a35d28 by task hping3/1195 [ 72.569631][ T1195] [ 72.569861][ T1195] CPU: 2 PID: 1195 Comm: hping3 Not tainted 5.5.0-rc1 #199 [ 72.570547][ T1195] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 72.571438][ T1195] Call Trace: [ 72.571764][ T1195] dump_stack+0x96/0xdb [ 72.572171][ T1195] ? ipv4_pdp_find.isra.12+0x130/0x170 [gtp] [ 72.572761][ T1195] print_address_description.constprop.5+0x1be/0x360 [ 72.573400][ T1195] ? ipv4_pdp_find.isra.12+0x130/0x170 [gtp] [ 72.573971][ T1195] ? ipv4_pdp_find.isra.12+0x130/0x170 [gtp] [ 72.574544][ T1195] __kasan_report+0x12a/0x16f [ 72.575014][ T1195] ? ipv4_pdp_find.isra.12+0x130/0x170 [gtp] [ 72.575593][ T1195] kasan_report+0xe/0x20 [ 72.576004][ T1195] ipv4_pdp_find.isra.12+0x130/0x170 [gtp] [ 72.576577][ T1195] gtp_build_skb_ip4+0x199/0x1420 [gtp] [ ... ] [ 72.647671][ T1195] BUG: unable to handle page fault for address: ffff8880b9a35d28 [ 72.648512][ T1195] #PF: supervisor read access in kernel mode [ 72.649158][ T1195] #PF: error_code(0x0000) - not-present page [ 72.649849][ T1195] PGD a6c01067 P4D a6c01067 PUD 11fb07067 PMD 11f939067 PTE 800fffff465ca060 [ 72.652958][ T1195] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 72.653834][ T1195] CPU: 2 PID: 1195 Comm: hping3 Tainted: G B 5.5.0-rc1 #199 [ 72.668062][ T1195] RIP: 0010:ipv4_pdp_find.isra.12+0x86/0x170 [gtp] [ ... ] [ 72.679168][ T1195] Call Trace: [ 72.679603][ T1195] gtp_build_skb_ip4+0x199/0x1420 [gtp] [ 72.681915][ T1195] ? ipv4_pdp_find.isra.12+0x170/0x170 [gtp] [ 72.682513][ T1195] ? lock_acquire+0x164/0x3b0 [ 72.682966][ T1195] ? gtp_dev_xmit+0x35e/0x890 [gtp] [ 72.683481][ T1195] gtp_dev_xmit+0x3c2/0x890 [gtp] [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2a3aa30ec4287e3e2c0113f0d58192a8832950cc Author: Haiyang Zhang Date: Wed Dec 11 14:26:27 2019 -0800 hv_netvsc: Fix tx_table init in rndis_set_subchannel() [ Upstream commit c39ea5cba5a2e97fc01b78c85208bf31383b399c ] Host can provide send indirection table messages anytime after RSS is enabled by calling rndis_filter_set_rss_param(). So the host provided table values may be overwritten by the initialization in rndis_set_subchannel(). To prevent this problem, move the tx_table initialization before calling rndis_filter_set_rss_param(). Fixes: a6fb6aa3cfa9 ("hv_netvsc: Set tx_table to equal weight after subchannels open") Signed-off-by: Haiyang Zhang Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 0a0ee9f2d5c0076e6d45d40a1b50c0411edef40a Author: Eric Dumazet Date: Fri Dec 13 18:20:41 2019 -0800 tcp/dccp: fix possible race __inet_lookup_established() [ Upstream commit 8dbd76e79a16b45b2ccb01d2f2e08dbf64e71e40 ] Michal Kubecek and Firo Yang did a very nice analysis of crashes happening in __inet_lookup_established(). Since a TCP socket can go from TCP_ESTABLISH to TCP_LISTEN (via a close()/socket()/listen() cycle) without a RCU grace period, I should not have changed listeners linkage in their hash table. They must use the nulls protocol (Documentation/RCU/rculist_nulls.txt), so that a lookup can detect a socket in a hash list was moved in another one. Since we added code in commit d296ba60d8e2 ("soreuseport: Resolve merge conflict for v4/v6 ordering fix"), we have to add hlist_nulls_add_tail_rcu() helper. Fixes: 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood") Signed-off-by: Eric Dumazet Reported-by: Michal Kubecek Reported-by: Firo Yang Reviewed-by: Michal Kubecek Link: https://lore.kernel.org/netdev/20191120083919.GH27852@unicorn.suse.cz/ Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 703761d85193e0c31d57941790a27a7ac4ba7214 Author: Eric Dumazet Date: Thu Dec 12 12:55:29 2019 -0800 tcp: do not send empty skb from tcp_write_xmit() [ Upstream commit 1f85e6267caca44b30c54711652b0726fadbb131 ] Backport of commit fdfc5c8594c2 ("tcp: remove empty skb from write queue in error cases") in linux-4.14 stable triggered various bugs. One of them has been fixed in commit ba2ddb43f270 ("tcp: Don't dequeue SYN/FIN-segments from write-queue"), but we still have crashes in some occasions. Root-cause is that when tcp_sendmsg() has allocated a fresh skb and could not append a fragment before being blocked in sk_stream_wait_memory(), tcp_write_xmit() might be called and decide to send this fresh and empty skb. Sending an empty packet is not only silly, it might have caused many issues we had in the past with tp->packets_out being out of sync. Fixes: c65f7f00c587 ("[TCP]: Simplify SKB data portion allocation with NETIF_F_SG.") Signed-off-by: Eric Dumazet Cc: Christoph Paasch Acked-by: Neal Cardwell Cc: Jason Baron Acked-by: Soheil Hassas Yeganeh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e2610008fb5b0c6effac244b7bfb7d0bf82c8b9f Author: Mahesh Bandewar Date: Fri Dec 6 15:44:55 2019 -0800 bonding: fix active-backup transition after link failure [ Upstream commit 5d485ed88d48f8101a2067348e267c0aaf4ed486 ] After the recent fix in commit 1899bb325149 ("bonding: fix state transition issue in link monitoring"), the active-backup mode with miimon initially come-up fine but after a link-failure, both members transition into backup state. Following steps to reproduce the scenario (eth1 and eth2 are the slaves of the bond): ip link set eth1 up ip link set eth2 down sleep 1 ip link set eth2 up ip link set eth1 down cat /sys/class/net/eth1/bonding_slave/state cat /sys/class/net/eth2/bonding_slave/state Fixes: 1899bb325149 ("bonding: fix state transition issue in link monitoring") CC: Jay Vosburgh Signed-off-by: Mahesh Bandewar Acked-by: Jay Vosburgh Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 85ee5098dd03873ff98e9f4b3cd55c9a302a4c21 Author: Taehee Yoo Date: Wed Dec 11 08:23:48 2019 +0000 gtp: avoid zero size hashtable [ Upstream commit 6a902c0f31993ab02e1b6ea7085002b9c9083b6a ] GTP default hashtable size is 1024 and userspace could set specific hashtable size with IFLA_GTP_PDP_HASHSIZE. If hashtable size is set to 0 from userspace, hashtable will not work and panic will occur. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b040f61ef66970f2c1f7c174d3c5a111e7c969e5 Author: Taehee Yoo Date: Wed Dec 11 08:23:17 2019 +0000 gtp: fix wrong condition in gtp_genl_dump_pdp() [ Upstream commit 94a6d9fb88df43f92d943c32b84ce398d50bf49f ] gtp_genl_dump_pdp() is ->dumpit() callback of GTP module and it is used to dump pdp contexts. it would be re-executed because of dump packet size. If dump packet size is too big, it saves current dump pointer (gtp interface pointer, bucket, TID value) then it restarts dump from last pointer. Current GTP code allows adding zero TID pdp context but dump code ignores zero TID value. So, last dump pointer will not be found. In addition, this patch adds missing rcu_read_lock() in gtp_genl_dump_pdp(). Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b5b17e9d835d8d1d291b947dcab347c799efe668 Author: Russell King Date: Tue Dec 10 22:33:05 2019 +0000 net: marvell: mvpp2: phylink requires the link interrupt [ Upstream commit f3f2364ea14d1cf6bf966542f31eadcf178f1577 ] phylink requires the MAC to report when its link status changes when operating in inband modes. Failure to report link status changes means that phylink has no idea when the link events happen, which results in either the network interface's carrier remaining up or remaining permanently down. For example, with a fiber module, if the interface is brought up and link is initially established, taking the link down at the far end will cut the optical power. The SFP module's LOS asserts, we deactivate the link, and the network interface reports no carrier. When the far end is brought back up, the SFP module's LOS deasserts, but the MAC may be slower to establish link. If this happens (which in my tests is a certainty) then phylink never hears that the MAC has established link with the far end, and the network interface is stuck reporting no carrier. This means the interface is non-functional. Avoiding the link interrupt when we have phylink is basically not an option, so remove the !port->phylink from the test. Fixes: 4bb043262878 ("net: mvpp2: phylink support") Tested-by: Sven Auhagen Tested-by: Antoine Tenart Signed-off-by: Russell King Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 24a7f6f1aed31441e07fce105e306671b92a6de2 Author: Vladimir Oltean Date: Fri Dec 27 03:11:13 2019 +0200 net: dsa: sja1105: Reconcile the meaning of TPID and TPID2 for E/T and P/Q/R/S [ Upstream commit 54fa49ee88138756df0fcf867cb1849904710a8c ] For first-generation switches (SJA1105E and SJA1105T): - TPID means C-Tag (typically 0x8100) - TPID2 means S-Tag (typically 0x88A8) While for the second generation switches (SJA1105P, SJA1105Q, SJA1105R, SJA1105S) it is the other way around: - TPID means S-Tag (typically 0x88A8) - TPID2 means C-Tag (typically 0x8100) In other words, E/T tags untagged traffic with TPID, and P/Q/R/S with TPID2. So the patch mentioned below fixed VLAN filtering for P/Q/R/S, but broke it for E/T. We strive for a common code path for all switches in the family, so just lie in the static config packing functions that TPID and TPID2 are at swapped bit offsets than they actually are, for P/Q/R/S. This will make both switches understand TPID to be ETH_P_8021Q and TPID2 to be ETH_P_8021AD. The meaning from the original E/T was chosen over P/Q/R/S because E/T is actually the one with public documentation available (UM10944.pdf). Fixes: f9a1a7646c0d ("net: dsa: sja1105: Reverse TPID and TPID2") Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 82cb396aeefac27c2e946b8aaaf1cb4d46b65447 Author: Hangbin Liu Date: Sun Dec 22 10:51:16 2019 +0800 net/dst: do not confirm neighbor for vxlan and geneve pmtu update [ Upstream commit f081042d128a0c7acbd67611def62e1b52e2d294 ] When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end, we should not call dst_confirm_neigh() as there is no two-way communication. So disable the neigh confirm for vxlan and geneve pmtu update. v5: No change. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Fixes: a93bf0ff4490 ("vxlan: update skb dst pmtu on tx path") Fixes: 52a589d51f10 ("geneve: update skb dst pmtu on tx path") Reviewed-by: Guillaume Nault Tested-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 57a5af98a28531402172d63137cda2e62073026a Author: Hangbin Liu Date: Sun Dec 22 10:51:15 2019 +0800 sit: do not confirm neighbor when do pmtu update [ Upstream commit 4d42df46d6372ece4cb4279870b46c2ea7304a47 ] When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end, we should not call dst_confirm_neigh() as there is no two-way communication. v5: No change. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Reviewed-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bcf4fe619c778bf055ef0e2c91ee65cc7b028e5f Author: Hangbin Liu Date: Sun Dec 22 10:51:14 2019 +0800 vti: do not confirm neighbor when do pmtu update [ Upstream commit 8247a79efa2f28b44329f363272550c1738377de ] When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end, we should not call dst_confirm_neigh() as there is no two-way communication. Although vti and vti6 are immune to this problem because they are IFF_NOARP interfaces, as Guillaume pointed. There is still no sense to confirm neighbour here. v5: Update commit description. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Reviewed-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 020546ec66665c4c80edb847bbcd5b4937bdddff Author: Hangbin Liu Date: Sun Dec 22 10:51:13 2019 +0800 tunnel: do not confirm neighbor when do pmtu update [ Upstream commit 7a1592bcb15d71400a98632727791d1e68ea0ee8 ] When do tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end, we should not call dst_confirm_neigh() as there is no two-way communication. v5: No Change. v4: Update commit description v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Fixes: 0dec879f636f ("net: use dst_confirm_neigh for UDP, RAW, ICMP, L2TP") Reviewed-by: Guillaume Nault Tested-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 70f10ed21e29b75fe4f152856cc4597db07e2595 Author: Hangbin Liu Date: Sun Dec 22 10:51:12 2019 +0800 net/dst: add new function skb_dst_update_pmtu_no_confirm [ Upstream commit 07dc35c6e3cc3c001915d05f5bf21f80a39a0970 ] Add a new function skb_dst_update_pmtu_no_confirm() for callers who need update pmtu but should not do neighbor confirm. v5: No change. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Reviewed-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 048478ddec29dfe8fe72e01b49d2200bd87f5cc5 Author: Hangbin Liu Date: Sun Dec 22 10:51:11 2019 +0800 gtp: do not confirm neighbor when do pmtu update [ Upstream commit 6e9105c73f8d2163d12d5dfd762fd75483ed30f5 ] When do IPv6 tunnel PMTU update and calls __ip6_rt_update_pmtu() in the end, we should not call dst_confirm_neigh() as there is no two-way communication. Although GTP only support ipv4 right now, and __ip_rt_update_pmtu() does not call dst_confirm_neigh(), we still set it to false to keep consistency with IPv6 code. v5: No change. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Reviewed-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 871d063728649733c3d6fac2fe210f07b186f0a7 Author: Hangbin Liu Date: Sun Dec 22 10:51:10 2019 +0800 ip6_gre: do not confirm neighbor when do pmtu update [ Upstream commit 675d76ad0ad5bf41c9a129772ef0aba8f57ea9a7 ] When we do ipv6 gre pmtu update, we will also do neigh confirm currently. This will cause the neigh cache be refreshed and set to REACHABLE before xmit. But if the remote mac address changed, e.g. device is deleted and recreated, we will not able to notice this and still use the old mac address as the neigh cache is REACHABLE. Fix this by disable neigh confirm when do pmtu update v5: No change. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Reported-by: Jianlin Shi Reviewed-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d49ce85cad06d00455f80030333131cb93cf1619 Author: Hangbin Liu Date: Sun Dec 22 10:51:09 2019 +0800 net: add bool confirm_neigh parameter for dst_ops.update_pmtu [ Upstream commit bd085ef678b2cc8c38c105673dfe8ff8f5ec0c57 ] The MTU update code is supposed to be invoked in response to real networking events that update the PMTU. In IPv6 PMTU update function __ip6_rt_update_pmtu() we called dst_confirm_neigh() to update neighbor confirmed time. But for tunnel code, it will call pmtu before xmit, like: - tnl_update_pmtu() - skb_dst_update_pmtu() - ip6_rt_update_pmtu() - __ip6_rt_update_pmtu() - dst_confirm_neigh() If the tunnel remote dst mac address changed and we still do the neigh confirm, we will not be able to update neigh cache and ping6 remote will failed. So for this ip_tunnel_xmit() case, _EVEN_ if the MTU is changed, we should not be invoking dst_confirm_neigh() as we have no evidence of successful two-way communication at this point. On the other hand it is also important to keep the neigh reachability fresh for TCP flows, so we cannot remove this dst_confirm_neigh() call. To fix the issue, we have to add a new bool parameter for dst_ops.update_pmtu to choose whether we should do neigh update or not. I will add the parameter in this patch and set all the callers to true to comply with the previous way, and fix the tunnel code one by one on later patches. v5: No change. v4: No change. v3: Do not remove dst_confirm_neigh, but add a new bool parameter in dst_ops.update_pmtu to control whether we should do neighbor confirm. Also split the big patch to small ones for each area. v2: Remove dst_confirm_neigh in __ip6_rt_update_pmtu. Suggested-by: David Miller Reviewed-by: Guillaume Nault Acked-by: David Ahern Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 29e92a154df20a1199a3e0737699b797511eb6ba Author: Ido Schimmel Date: Sun Dec 29 13:40:23 2019 +0200 mlxsw: spectrum: Use dedicated policer for VRRP packets [ Upstream commit acca789a358cc960be3937851d7de6591c79d6c2 ] Currently, VRRP packets and packets that hit exceptions during routing (e.g., MTU error) are policed using the same policer towards the CPU. This means, for example, that misconfiguration of the MTU on a routed interface can prevent VRRP packets from reaching the CPU, which in turn can cause the VRRP daemon to assume it is the Master router. Fix this by using a dedicated policer for VRRP packets. Fixes: 11566d34f895 ("mlxsw: spectrum: Add VRRP traps") Signed-off-by: Ido Schimmel Reported-by: Alex Veber Tested-by: Alex Veber Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1a54f9b5729dd88d356c57e2e957fa9533a2dbb5 Author: Amit Cohen Date: Sun Dec 29 13:40:22 2019 +0200 mlxsw: spectrum_router: Skip loopback RIFs during MAC validation [ Upstream commit 314bd842d98e1035cc40b671a71e07f48420e58f ] When a router interface (RIF) is created the MAC address of the backing netdev is verified to have the same MSBs as existing RIFs. This is required in order to avoid changing existing RIF MAC addresses that all share the same MSBs. Loopback RIFs are special in this regard as they do not have a MAC address, given they are only used to loop packets from the overlay to the underlay. Without this change, an error is returned when trying to create a RIF after the creation of a GRE tunnel that is represented by a loopback RIF. 'rif->dev->dev_addr' points to the GRE device's local IP, which does not share the same MSBs as physical interfaces. Adding an IP address to any physical interface results in: Error: mlxsw_spectrum: All router interface MAC addresses must have the same prefix. Fix this by skipping loopback RIFs during MAC validation. Fixes: 74bc99397438 ("mlxsw: spectrum_router: Veto unsupported RIF MAC addresses") Signed-off-by: Amit Cohen Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1d96309527c83d6d5fe4f429b675c70ca0f33829 Author: Vasundhara Volam Date: Tue Dec 10 02:49:13 2019 -0500 bnxt_en: Add missing devlink health reporters for VFs. [ Upstream commit 7e334fc8003c7a38372cc98e7be6082670a47d29 ] The VF driver also needs to create the health reporters since VFs are also involved in firmware reset and recovery. Modify bnxt_dl_register() and bnxt_dl_unregister() so that they can be called by the VFs to register/unregister devlink. Only the PF will register the devlink parameters. With devlink registered, we can now create the health reporters on the VFs. Fixes: 6763c779c2d8 ("bnxt_en: Add new FW devlink_health_reporter") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5575705b998e7bd47acfbfa9271ee946b2876ec8 Author: Vasundhara Volam Date: Tue Dec 10 02:49:12 2019 -0500 bnxt_en: Fix the logic that creates the health reporters. [ Upstream commit 937f188c1f4f89b3fa93ba31fc8587dc1fb14a22 ] Fix the logic to properly check the fw capabilities and create the devlink health reporters only when needed. The current code creates the reporters unconditionally as long as bp->fw_health is valid, and that's not correct. Call bnxt_dl_fw_reporters_create() directly from the init and reset code path instead of from bnxt_dl_register(). This allows the reporters to be adjusted when capabilities change. The same applies to bnxt_dl_fw_reporters_destroy(). Fixes: 6763c779c2d8 ("bnxt_en: Add new FW devlink_health_reporter") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 02aa518984e9879643aeefec95a7d09fba811179 Author: Vasundhara Volam Date: Tue Dec 10 02:49:11 2019 -0500 bnxt_en: Remove unnecessary NULL checks for fw_health [ Upstream commit 0797c10d2d1fa0d6f14612404781b348fc757c3e ] After fixing the allocation of bp->fw_health in the previous patch, the driver will not go through the fw reset and recovery code paths if bp->fw_health allocation fails. So we can now remove the unnecessary NULL checks. Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3f750698a0a8e3b559a4519edf7ec9e1ac2205aa Author: Vasundhara Volam Date: Tue Dec 10 02:49:10 2019 -0500 bnxt_en: Fix bp->fw_health allocation and free logic. [ Upstream commit 8280b38e01f71e0f89389ccad3fa43b79e57c604 ] bp->fw_health needs to be allocated for either the firmware initiated reset feature or the driver initiated error recovery feature. The current code is not allocating bp->fw_health for all the necessary cases. This patch corrects the logic to allocate bp->fw_health correctly when needed. If allocation fails, we clear the feature flags. We also add the the missing kfree(bp->fw_health) when the driver is unloaded. If we get an async reset message from the firmware, we also need to make sure that we have a valid bp->fw_health before proceeding. Fixes: 07f83d72d238 ("bnxt_en: Discover firmware error recovery capabilities.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a76837dd731b68cc3b5690470bc9efa2a8e3801a Author: Vasundhara Volam Date: Tue Dec 10 02:49:09 2019 -0500 bnxt_en: Return error if FW returns more data than dump length [ Upstream commit c74751f4c39232c31214ec6a3bc1c7e62f5c728b ] If any change happened in the configuration of VF in VM while collecting live dump, there could be a race and firmware can return more data than allocated dump length. Fix it by keeping track of the accumulated core dump length copied so far and abort the copy with error code if the next chunk of core dump will exceed the original dump length. Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit afc13aa9400b5d3d54efa4b4183168a9a3e03c12 Author: Michael Chan Date: Tue Dec 10 02:49:08 2019 -0500 bnxt_en: Free context memory in the open path if firmware has been reset. [ Upstream commit 325f85f37e5b35807d86185bdf2c64d2980c44ba ] This will trigger new context memory to be rediscovered and allocated during the re-probe process after a firmware reset. Without this, the newly reset firmware does not have valid context memory and the driver will eventually fail to allocate some resources. Fixes: ec5d31e3c15d ("bnxt_en: Handle firmware reset status during IF_UP.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 972d2ca72c8cca730e0ce349e935acf7cea48b9a Author: Michael Chan Date: Tue Dec 10 02:49:07 2019 -0500 bnxt_en: Fix MSIX request logic for RDMA driver. [ Upstream commit 0c722ec0a289c7f6b53f89bad1cfb7c4db3f7a62 ] The logic needs to check both bp->total_irqs and the reserved IRQs in hw_resc->resv_irqs if applicable and see if both are enough to cover the L2 and RDMA requested vectors. The current code is only checking bp->total_irqs and can fail in some code paths, such as the TX timeout code path with the RDMA driver requesting vectors after recovery. In this code path, we have not reserved enough MSIX resources for the RDMA driver yet. Fixes: 75720e6323a1 ("bnxt_en: Keep track of reserved IRQs.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ff4839120cbe24c2cbf4339b17771c7140e81720 Author: Antonio Messina Date: Thu Dec 19 15:08:03 2019 +0100 udp: fix integer overflow while computing available space in sk_rcvbuf [ Upstream commit feed8a4fc9d46c3126fb9fcae0e9248270c6321a ] When the size of the receive buffer for a socket is close to 2^31 when computing if we have enough space in the buffer to copy a packet from the queue to the buffer we might hit an integer overflow. When an user set net.core.rmem_default to a value close to 2^31 UDP packets are dropped because of this overflow. This can be visible, for instance, with failure to resolve hostnames. This can be fixed by casting sk_rcvbuf (which is an int) to unsigned int, similarly to how it is done in TCP. Signed-off-by: Antonio Messina Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4c5fa9d3c87497e5f753ae48f692e84e8a732e9b Author: Cambda Zhu Date: Fri Dec 27 16:52:37 2019 +0800 tcp: Fix highest_sack and highest_sack_seq [ Upstream commit 853697504de043ff0bfd815bd3a64de1dce73dc7 ] >From commit 50895b9de1d3 ("tcp: highest_sack fix"), the logic about setting tp->highest_sack to the head of the send queue was removed. Of course the logic is error prone, but it is logical. Before we remove the pointer to the highest sack skb and use the seq instead, we need to set tp->highest_sack to NULL when there is no skb after the last sack, and then replace NULL with the real skb when new skb inserted into the rtx queue, because the NULL means the highest sack seq is tp->snd_nxt. If tp->highest_sack is NULL and new data sent, the next ACK with sack option will increase tp->reordering unexpectedly. This patch sets tp->highest_sack to the tail of the rtx queue if it's NULL and new data is sent. The patch keeps the rule that the highest_sack can only be maintained by sack processing, except for this only case. Fixes: 50895b9de1d3 ("tcp: highest_sack fix") Signed-off-by: Cambda Zhu Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bfa2e0cd3dfda64fde43c3dca3aeba298d2fe7ad Author: Vladis Dronov Date: Fri Dec 27 03:26:27 2019 +0100 ptp: fix the race between the release of ptp_clock and cdev [ Upstream commit a33121e5487b424339636b25c35d3a180eaa5f5e ] In a case when a ptp chardev (like /dev/ptp0) is open but an underlying device is removed, closing this file leads to a race. This reproduces easily in a kvm virtual machine: ts# cat openptp0.c int main() { ... fp = fopen("/dev/ptp0", "r"); ... sleep(10); } ts# uname -r 5.5.0-rc3-46cf053e ts# cat /proc/cmdline ... slub_debug=FZP ts# modprobe ptp_kvm ts# ./openptp0 & [1] 670 opened /dev/ptp0, sleeping 10s... ts# rmmod ptp_kvm ts# ls /dev/ptp* ls: cannot access '/dev/ptp*': No such file or directory ts# ...woken up [ 48.010809] general protection fault: 0000 [#1] SMP [ 48.012502] CPU: 6 PID: 658 Comm: openptp0 Not tainted 5.5.0-rc3-46cf053e #25 [ 48.014624] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... [ 48.016270] RIP: 0010:module_put.part.0+0x7/0x80 [ 48.017939] RSP: 0018:ffffb3850073be00 EFLAGS: 00010202 [ 48.018339] RAX: 000000006b6b6b6b RBX: 6b6b6b6b6b6b6b6b RCX: ffff89a476c00ad0 [ 48.018936] RDX: fffff65a08d3ea08 RSI: 0000000000000247 RDI: 6b6b6b6b6b6b6b6b [ 48.019470] ... ^^^ a slub poison [ 48.023854] Call Trace: [ 48.024050] __fput+0x21f/0x240 [ 48.024288] task_work_run+0x79/0x90 [ 48.024555] do_exit+0x2af/0xab0 [ 48.024799] ? vfs_write+0x16a/0x190 [ 48.025082] do_group_exit+0x35/0x90 [ 48.025387] __x64_sys_exit_group+0xf/0x10 [ 48.025737] do_syscall_64+0x3d/0x130 [ 48.026056] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 48.026479] RIP: 0033:0x7f53b12082f6 [ 48.026792] ... [ 48.030945] Modules linked in: ptp i6300esb watchdog [last unloaded: ptp_kvm] [ 48.045001] Fixing recursive fault but reboot is needed! This happens in: static void __fput(struct file *file) { ... if (file->f_op->release) file->f_op->release(inode, file); <<< cdev is kfree'd here if (unlikely(S_ISCHR(inode->i_mode) && inode->i_cdev != NULL && !(mode & FMODE_PATH))) { cdev_put(inode->i_cdev); <<< cdev fields are accessed here Namely: __fput() posix_clock_release() kref_put(&clk->kref, delete_clock) <<< the last reference delete_clock() delete_ptp_clock() kfree(ptp) <<< cdev is embedded in ptp cdev_put module_put(p->owner) <<< *p is kfree'd, bang! Here cdev is embedded in posix_clock which is embedded in ptp_clock. The race happens because ptp_clock's lifetime is controlled by two refcounts: kref and cdev.kobj in posix_clock. This is wrong. Make ptp_clock's sysfs device a parent of cdev with cdev_device_add() created especially for such cases. This way the parent device with its ptp_clock is not released until all references to the cdev are released. This adds a requirement that an initialized but not exposed struct device should be provided to posix_clock_register() by a caller instead of a simple dev_t. This approach was adopted from the commit 72139dfa2464 ("watchdog: Fix the race between the release of watchdog_core_data and cdev"). See details of the implementation in the commit 233ed09d7fda ("chardev: add helper function to register char devs with a struct device"). Link: https://lore.kernel.org/linux-fsdevel/20191125125342.6189-1-vdronov@redhat.com/T/#u Analyzed-by: Stephen Johnston Analyzed-by: Vern Lovejoy Signed-off-by: Vladis Dronov Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 80cd0b9748adab4ee142ee72d06d5270c67fd32a Author: Martin Blumenstingl Date: Thu Dec 26 20:01:01 2019 +0100 net: stmmac: dwmac-meson8b: Fix the RGMII TX delay on Meson8b/8m2 SoCs [ Upstream commit bd6f48546b9cb7a785344fc78058c420923d7ed8 ] GXBB and newer SoCs use the fixed FCLK_DIV2 (1GHz) clock as input for the m250_sel clock. Meson8b and Meson8m2 use MPLL2 instead, whose rate can be adjusted at runtime. So far we have been running MPLL2 with ~250MHz (and the internal m250_div with value 1), which worked enough that we could transfer data with an TX delay of 4ns. Unfortunately there is high packet loss with an RGMII PHY when transferring data (receiving data works fine though). Odroid-C1's u-boot is running with a TX delay of only 2ns as well as the internal m250_div set to 2 - no lost (TX) packets can be observed with that setting in u-boot. Manual testing has shown that the TX packet loss goes away when using the following settings in Linux (the vendor kernel uses the same settings): - MPLL2 clock set to ~500MHz - m250_div set to 2 - TX delay set to 2ns on the MAC side Update the m250_div divider settings to only accept dividers greater or equal 2 to fix the TX delay generated by the MAC. iperf3 results before the change: [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 182 MBytes 153 Mbits/sec 514 sender [ 5] 0.00-10.00 sec 182 MBytes 152 Mbits/sec receiver iperf3 results after the change (including an updated TX delay of 2ns): [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-10.00 sec 927 MBytes 778 Mbits/sec 0 sender [ 5] 0.00-10.01 sec 927 MBytes 777 Mbits/sec receiver Fixes: 4f6a71b84e1afd ("net: stmmac: dwmac-meson8b: fix internal RGMII clock configuration") Signed-off-by: Martin Blumenstingl Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ebbadeab4460889fca9198f74273ae65a38971ad Author: Eric Dumazet Date: Mon Dec 23 11:13:24 2019 -0800 net_sched: sch_fq: properly set sk->sk_pacing_status [ Upstream commit bb3d0b8bf5be61ab1d6f472c43cbf34de17e796b ] If fq_classify() recycles a struct fq_flow because a socket structure has been reallocated, we do not set sk->sk_pacing_status immediately, but later if the flow becomes detached. This means that any flow requiring pacing (BBR, or SO_MAX_PACING_RATE) might fallback to TCP internal pacing, which requires a per-socket high resolution timer, and therefore more cpu cycles. Fixes: 218af599fa63 ("tcp: internal implementation for pacing") Signed-off-by: Eric Dumazet Cc: Soheil Hassas Yeganeh Cc: Neal Cardwell Acked-by: Soheil Hassas Yeganeh Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c40e059513e4846ddf807f07f381ac54b979a6c8 Author: Davide Caratti Date: Sat Dec 28 16:36:58 2019 +0100 net/sched: add delete_empty() to filters and use it in cls_flower [ Upstream commit a5b72a083da197b493c7ed1e5730d62d3199f7d6 ] Revert "net/sched: cls_u32: fix refcount leak in the error path of u32_change()", and fix the u32 refcount leak in a more generic way that preserves the semantic of rule dumping. On tc filters that don't support lockless insertion/removal, there is no need to guard against concurrent insertion when a removal is in progress. Therefore, for most of them we can avoid a full walk() when deleting, and just decrease the refcount, like it was done on older Linux kernels. This fixes situations where walk() was wrongly detecting a non-empty filter, like it happened with cls_u32 in the error path of change(), thus leading to failures in the following tdc selftests: 6aa7: (filter, u32) Add/Replace u32 with source match and invalid indev 6658: (filter, u32) Add/Replace u32 with custom hash table and invalid handle 74c2: (filter, u32) Add/Replace u32 filter with invalid hash table id On cls_flower, and on (future) lockless filters, this check is necessary: move all the check_empty() logic in a callback so that each filter can have its own implementation. For cls_flower, it's sufficient to check if no IDRs have been allocated. This reverts commit 275c44aa194b7159d1191817b20e076f55f0e620. Changes since v1: - document the need for delete_empty() when TCF_PROTO_OPS_DOIT_UNLOCKED is used, thanks to Vlad Buslov - implement delete_empty() without doing fl_walk(), thanks to Vlad Buslov - squash revert and new fix in a single patch, to be nice with bisect tests that run tdc on u32 filter, thanks to Dave Miller Fixes: 275c44aa194b ("net/sched: cls_u32: fix refcount leak in the error path of u32_change()") Fixes: 6676d5e416ee ("net: sched: set dedicated tcf_walker flag when tp is empty") Suggested-by: Jamal Hadi Salim Suggested-by: Vlad Buslov Signed-off-by: Davide Caratti Reviewed-by: Vlad Buslov Tested-by: Jamal Hadi Salim Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1f754ad07751771b4e85f2e821d5a0618a6b861d Author: Shmulik Ladkani Date: Wed Dec 25 10:51:01 2019 +0200 net/sched: act_mirred: Pull mac prior redir to non mac_header_xmit device [ Upstream commit 70cf3dc7313207816255b9acb0dffb19dae78144 ] There's no skb_pull performed when a mirred action is set at egress of a mac device, with a target device/action that expects skb->data to point at the network header. As a result, either the target device is errornously given an skb with data pointing to the mac (egress case), or the net stack receives the skb with data pointing to the mac (ingress case). E.g: # tc qdisc add dev eth9 root handle 1: prio # tc filter add dev eth9 parent 1: prio 9 protocol ip handle 9 basic \ action mirred egress redirect dev tun0 (tun0 is a tun device. result: tun0 errornously gets the eth header instead of the iph) Revise the push/pull logic of tcf_mirred_act() to not rely on the skb_at_tc_ingress() vs tcf_mirred_act_wants_ingress() comparison, as it does not cover all "pull" cases. Instead, calculate whether the required action on the target device requires the data to point at the network header, and compare this to whether skb->data points to network header - and make the push/pull adjustments as necessary. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Shmulik Ladkani Tested-by: Jamal Hadi Salim Acked-by: Jamal Hadi Salim Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fbeec8f00b01644d094bf883b963fb6790b02666 Author: Madalin Bucur Date: Mon Dec 23 10:06:10 2019 +0200 net: phy: aquantia: add suspend / resume ops for AQR105 [ Upstream commit 1c93fb45761e79b3c00080e71523886cefaf351c ] The suspend/resume code for AQR107 works on AQR105 too. This patch fixes issues with the partner not seeing the link down when the interface using AQR105 is brought down. Fixes: bee8259dd31f ("net: phy: add driver for aquantia phy") Signed-off-by: Madalin Bucur Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 6c75efb9e5b6a8c06105a011562939acaeeea48b Author: Vladyslav Tarasiuk Date: Thu Dec 26 10:41:56 2019 +0200 net/mlxfw: Fix out-of-memory error in mfa2 flash burning [ Upstream commit a5bcd72e054aabb93ddc51ed8cde36a5bfc50271 ] The burning process requires to perform internal allocations of large chunks of memory. This memory doesn't need to be contiguous and can be safely allocated by vzalloc() instead of kzalloc(). This patch changes such allocation to avoid possible out-of-memory failure. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Signed-off-by: Vladyslav Tarasiuk Reviewed-by: Aya Levin Signed-off-by: Leon Romanovsky Tested-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 770247f2b26419303a2a574ddce96e7d45c646b7 Author: Florian Fainelli Date: Fri Dec 20 11:24:21 2019 -0800 net: dsa: bcm_sf2: Fix IP fragment location and behavior [ Upstream commit 7c3125f0a6ebc17846c5908ad7d6056d66c1c426 ] The IP fragment is specified through user-defined field as the first bit of the first user-defined word. We were previously trying to extract it from the user-defined mask which could not possibly work. The ip_frag is also supposed to be a boolean, if we do not cast it as such, we risk overwriting the next fields in CFP_DATA(6) which would render the rule inoperative. Fixes: 7318166cacad ("net: dsa: bcm_sf2: Add support for ethtool::rxnfc") Signed-off-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 49ba803590429e6c82a7c4b78cf0a456b5f270ca Author: Rahul Lakkireddy Date: Mon Dec 30 18:14:08 2019 +0530 cxgb4/cxgb4vf: fix flow control display for auto negotiation [ Upstream commit 0caeaf6ad532f9be5a768a158627cb31921cc8b7 ] As per 802.3-2005, Section Two, Annex 28B, Table 28B-2 [1], when _only_ Rx pause is enabled, both symmetric and asymmetric pause towards local device must be enabled. Also, firmware returns the local device's flow control pause params as part of advertised capabilities and negotiated params as part of current link attributes. So, fix up ethtool's flow control pause params fetch logic to read from acaps, instead of linkattr. [1] https://standards.ieee.org/standard/802_3-2005.html Fixes: c3168cabe1af ("cxgb4/cxgbvf: Handle 32-bit fw port capabilities") Signed-off-by: Surendra Mobiya Signed-off-by: Rahul Lakkireddy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 03c074b26ff95d715c2f48798ac2c03d9d9b80c8 Author: Brian Foster Date: Tue Dec 3 07:53:15 2019 -0800 xfs: fix mount failure crash on invalid iclog memory access commit 798a9cada4694ca8d970259f216cec47e675bfd5 upstream. syzbot (via KASAN) reports a use-after-free in the error path of xlog_alloc_log(). Specifically, the iclog freeing loop doesn't handle the case of a fully initialized ->l_iclog linked list. Instead, it assumes that the list is partially constructed and NULL terminated. This bug manifested because there was no possible error scenario after iclog list setup when the original code was added. Subsequent code and associated error conditions were added some time later, while the original error handling code was never updated. Fix up the error loop to terminate either on a NULL iclog or reaching the end of the list. Reported-by: syzbot+c732f8644185de340492@syzkaller.appspotmail.com Signed-off-by: Brian Foster Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Greg Kroah-Hartman commit cfd653e839b2b26b68368d2bb2491ecc0200d83a Author: Daniel Vetter Date: Wed Dec 4 16:52:37 2019 -0800 drm: limit to INT_MAX in create_blob ioctl commit 5bf8bec3f4ce044a223c40cbce92590d938f0e9c upstream. The hardened usercpy code is too paranoid ever since commit 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes") Code itself should have been fine as-is. Link: http://lkml.kernel.org/r/20191106164755.31478-1-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter Reported-by: syzbot+fb77e97ebf0612ee6914@syzkaller.appspotmail.com Fixes: 6a30afa8c1fb ("uaccess: disallow > INT_MAX copy sizes") Cc: Kees Cook Cc: Alexander Viro Cc: Stephen Rothwell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 24c792fb7cbc08e5c4b1f3fc4b926d665e64ce4d Author: Kees Cook Date: Wed Dec 4 16:52:40 2019 -0800 uaccess: disallow > INT_MAX copy sizes commit 6d13de1489b6bf539695f96d945de3860e6d5e17 upstream. As we've done with VFS, string operations, etc, reject usercopy sizes larger than INT_MAX, which would be nice to have for catching bugs related to size calculation overflows[1]. This adds 10 bytes to x86_64 defconfig text and 1980 bytes to the data section: text data bss dec hex filename 19691167 5134320 1646664 26472151 193eed7 vmlinux.before 19691177 5136300 1646664 26474141 193f69d vmlinux.after [1] https://marc.info/?l=linux-s390&m=156631939010493&w=2 Link: http://lkml.kernel.org/r/201908251612.F9902D7A@keescook Signed-off-by: Kees Cook Suggested-by: Dan Carpenter Cc: Alexander Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 9c24cc6a9d9570d1312af1b379ab1764face8cd8 Author: Tetsuo Handa Date: Mon Nov 25 10:46:51 2019 +0900 tomoyo: Don't use nifty names on sockets. commit 6f7c41374b62fd80bbd8aae3536c43688c54d95e upstream. syzbot is reporting that use of SOCKET_I()->sk from open() can result in use after free problem [1], for socket's inode is still reachable via /proc/pid/fd/n despite destruction of SOCKET_I()->sk already completed. At first I thought that this race condition applies to only open/getattr permission checks. But James Morris has pointed out that there are more permission checks where this race condition applies to. Thus, get rid of tomoyo_get_socket_name() instead of conditionally bypassing permission checks on sockets. As a side effect of this patch, "socket:[family=\$:type=\$:protocol=\$]" in the policy files has to be rewritten to "socket:[\$]". [1] https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74 Signed-off-by: Tetsuo Handa Reported-by: syzbot Reported-by: James Morris Signed-off-by: Greg Kroah-Hartman commit 2cd7c5f23ff1b2ce5d15720334861cb902519e8b Author: Eric Dumazet Date: Wed Nov 6 09:48:04 2019 -0800 hrtimer: Annotate lockless access to timer->state commit 56144737e67329c9aaed15f942d46a6302e2e3d8 upstream. syzbot reported various data-race caused by hrtimer_is_queued() reading timer->state. A READ_ONCE() is required there to silence the warning. Also add the corresponding WRITE_ONCE() when timer->state is set. In remove_hrtimer() the hrtimer_is_queued() helper is open coded to avoid loading timer->state twice. KCSAN reported these cases: BUG: KCSAN: data-race in __remove_hrtimer / tcp_pacing_check write to 0xffff8880b2a7d388 of 1 bytes by interrupt on cpu 0: __remove_hrtimer+0x52/0x130 kernel/time/hrtimer.c:991 __run_hrtimer kernel/time/hrtimer.c:1496 [inline] __hrtimer_run_queues+0x250/0x600 kernel/time/hrtimer.c:1576 hrtimer_run_softirq+0x10e/0x150 kernel/time/hrtimer.c:1593 __do_softirq+0x115/0x33f kernel/softirq.c:292 run_ksoftirqd+0x46/0x60 kernel/softirq.c:603 smpboot_thread_fn+0x37d/0x4a0 kernel/smpboot.c:165 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 read to 0xffff8880b2a7d388 of 1 bytes by task 24652 on cpu 1: tcp_pacing_check net/ipv4/tcp_output.c:2235 [inline] tcp_pacing_check+0xba/0x130 net/ipv4/tcp_output.c:2225 tcp_xmit_retransmit_queue+0x32c/0x5a0 net/ipv4/tcp_output.c:3044 tcp_xmit_recovery+0x7c/0x120 net/ipv4/tcp_input.c:3558 tcp_ack+0x17b6/0x3170 net/ipv4/tcp_input.c:3717 tcp_rcv_established+0x37e/0xf50 net/ipv4/tcp_input.c:5696 tcp_v4_do_rcv+0x381/0x4e0 net/ipv4/tcp_ipv4.c:1561 sk_backlog_rcv include/net/sock.h:945 [inline] __release_sock+0x135/0x1e0 net/core/sock.c:2435 release_sock+0x61/0x160 net/core/sock.c:2951 sk_stream_wait_memory+0x3d7/0x7c0 net/core/stream.c:145 tcp_sendmsg_locked+0xb47/0x1f30 net/ipv4/tcp.c:1393 tcp_sendmsg+0x39/0x60 net/ipv4/tcp.c:1434 inet_sendmsg+0x6d/0x90 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0x9f/0xc0 net/socket.c:657 BUG: KCSAN: data-race in __remove_hrtimer / __tcp_ack_snd_check write to 0xffff8880a3a65588 of 1 bytes by interrupt on cpu 0: __remove_hrtimer+0x52/0x130 kernel/time/hrtimer.c:991 __run_hrtimer kernel/time/hrtimer.c:1496 [inline] __hrtimer_run_queues+0x250/0x600 kernel/time/hrtimer.c:1576 hrtimer_run_softirq+0x10e/0x150 kernel/time/hrtimer.c:1593 __do_softirq+0x115/0x33f kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0xbb/0xe0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 read to 0xffff8880a3a65588 of 1 bytes by task 22891 on cpu 1: __tcp_ack_snd_check+0x415/0x4f0 net/ipv4/tcp_input.c:5265 tcp_ack_snd_check net/ipv4/tcp_input.c:5287 [inline] tcp_rcv_established+0x750/0xf50 net/ipv4/tcp_input.c:5708 tcp_v4_do_rcv+0x381/0x4e0 net/ipv4/tcp_ipv4.c:1561 sk_backlog_rcv include/net/sock.h:945 [inline] __release_sock+0x135/0x1e0 net/core/sock.c:2435 release_sock+0x61/0x160 net/core/sock.c:2951 sk_stream_wait_memory+0x3d7/0x7c0 net/core/stream.c:145 tcp_sendmsg_locked+0xb47/0x1f30 net/ipv4/tcp.c:1393 tcp_sendmsg+0x39/0x60 net/ipv4/tcp.c:1434 inet_sendmsg+0x6d/0x90 net/ipv4/af_inet.c:807 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg+0x9f/0xc0 net/socket.c:657 __sys_sendto+0x21f/0x320 net/socket.c:1952 __do_sys_sendto net/socket.c:1964 [inline] __se_sys_sendto net/socket.c:1960 [inline] __x64_sys_sendto+0x89/0xb0 net/socket.c:1960 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 24652 Comm: syz-executor.3 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 [ tglx: Added comments ] Reported-by: syzbot Signed-off-by: Eric Dumazet Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20191106174804.74723-1-edumazet@google.com Signed-off-by: Greg Kroah-Hartman commit 3fe9be220c67262e23ddd9219505d29ef9577f4b Author: Eric Dumazet Date: Fri Nov 8 10:34:47 2019 -0800 net: icmp: fix data-race in cmp_global_allow() commit bbab7ef235031f6733b5429ae7877bfa22339712 upstream. This code reads two global variables without protection of a lock. We need READ_ONCE()/WRITE_ONCE() pairs to avoid load/store-tearing and better document the intent. KCSAN reported : BUG: KCSAN: data-race in icmp_global_allow / icmp_global_allow read to 0xffffffff861a8014 of 4 bytes by task 11201 on cpu 0: icmp_global_allow+0x36/0x1b0 net/ipv4/icmp.c:254 icmpv6_global_allow net/ipv6/icmp.c:184 [inline] icmpv6_global_allow net/ipv6/icmp.c:179 [inline] icmp6_send+0x493/0x1140 net/ipv6/icmp.c:514 icmpv6_send+0x71/0xb0 net/ipv6/ip6_icmp.c:43 ip6_link_failure+0x43/0x180 net/ipv6/route.c:2640 dst_link_failure include/net/dst.h:419 [inline] vti_xmit net/ipv4/ip_vti.c:243 [inline] vti_tunnel_xmit+0x27f/0xa50 net/ipv4/ip_vti.c:279 __netdev_start_xmit include/linux/netdevice.h:4420 [inline] netdev_start_xmit include/linux/netdevice.h:4434 [inline] xmit_one net/core/dev.c:3280 [inline] dev_hard_start_xmit+0xef/0x430 net/core/dev.c:3296 __dev_queue_xmit+0x14c9/0x1b60 net/core/dev.c:3873 dev_queue_xmit+0x21/0x30 net/core/dev.c:3906 neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a6/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] ip6_local_out+0x74/0x90 net/ipv6/output_core.c:179 write to 0xffffffff861a8014 of 4 bytes by task 11183 on cpu 1: icmp_global_allow+0x174/0x1b0 net/ipv4/icmp.c:272 icmpv6_global_allow net/ipv6/icmp.c:184 [inline] icmpv6_global_allow net/ipv6/icmp.c:179 [inline] icmp6_send+0x493/0x1140 net/ipv6/icmp.c:514 icmpv6_send+0x71/0xb0 net/ipv6/ip6_icmp.c:43 ip6_link_failure+0x43/0x180 net/ipv6/route.c:2640 dst_link_failure include/net/dst.h:419 [inline] vti_xmit net/ipv4/ip_vti.c:243 [inline] vti_tunnel_xmit+0x27f/0xa50 net/ipv4/ip_vti.c:279 __netdev_start_xmit include/linux/netdevice.h:4420 [inline] netdev_start_xmit include/linux/netdevice.h:4434 [inline] xmit_one net/core/dev.c:3280 [inline] dev_hard_start_xmit+0xef/0x430 net/core/dev.c:3296 __dev_queue_xmit+0x14c9/0x1b60 net/core/dev.c:3873 dev_queue_xmit+0x21/0x30 net/core/dev.c:3906 neigh_direct_output+0x1f/0x30 net/core/neighbour.c:1530 neigh_output include/net/neighbour.h:511 [inline] ip6_finish_output2+0x7a6/0xec0 net/ipv6/ip6_output.c:116 __ip6_finish_output net/ipv6/ip6_output.c:142 [inline] __ip6_finish_output+0x2d7/0x330 net/ipv6/ip6_output.c:127 ip6_finish_output+0x41/0x160 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0xf2/0x280 net/ipv6/ip6_output.c:175 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 11183 Comm: syz-executor.2 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 4cdf507d5452 ("icmp: add a global rate limitation") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cf0bcc99582cd148e94b651d677054622a252abd Author: Eric Dumazet Date: Thu Nov 7 18:49:43 2019 -0800 net: add a READ_ONCE() in skb_peek_tail() commit f8cc62ca3e660ae3fdaee533b1d554297cd2ae82 upstream. skb_peek_tail() can be used without protection of a lock, as spotted by KCSAN [1] In order to avoid load-stearing, add a READ_ONCE() Note that the corresponding WRITE_ONCE() are already there. [1] BUG: KCSAN: data-race in sk_wait_data / skb_queue_tail read to 0xffff8880b36a4118 of 8 bytes by task 20426 on cpu 1: skb_peek_tail include/linux/skbuff.h:1784 [inline] sk_wait_data+0x15b/0x250 net/core/sock.c:2477 kcm_wait_data+0x112/0x1f0 net/kcm/kcmsock.c:1103 kcm_recvmsg+0xac/0x320 net/kcm/kcmsock.c:1130 sock_recvmsg_nosec net/socket.c:871 [inline] sock_recvmsg net/socket.c:889 [inline] sock_recvmsg+0x92/0xb0 net/socket.c:885 ___sys_recvmsg+0x1a0/0x3e0 net/socket.c:2480 do_recvmmsg+0x19a/0x5c0 net/socket.c:2601 __sys_recvmmsg+0x1ef/0x200 net/socket.c:2680 __do_sys_recvmmsg net/socket.c:2703 [inline] __se_sys_recvmmsg net/socket.c:2696 [inline] __x64_sys_recvmmsg+0x89/0xb0 net/socket.c:2696 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 write to 0xffff8880b36a4118 of 8 bytes by task 451 on cpu 0: __skb_insert include/linux/skbuff.h:1852 [inline] __skb_queue_before include/linux/skbuff.h:1958 [inline] __skb_queue_tail include/linux/skbuff.h:1991 [inline] skb_queue_tail+0x7e/0xc0 net/core/skbuff.c:3145 kcm_queue_rcv_skb+0x202/0x310 net/kcm/kcmsock.c:206 kcm_rcv_strparser+0x74/0x4b0 net/kcm/kcmsock.c:370 __strp_recv+0x348/0xf50 net/strparser/strparser.c:309 strp_recv+0x84/0xa0 net/strparser/strparser.c:343 tcp_read_sock+0x174/0x5c0 net/ipv4/tcp.c:1639 strp_read_sock+0xd4/0x140 net/strparser/strparser.c:366 do_strp_work net/strparser/strparser.c:414 [inline] strp_work+0x9a/0xe0 net/strparser/strparser.c:423 process_one_work+0x3d4/0x890 kernel/workqueue.c:2269 worker_thread+0xa0/0x800 kernel/workqueue.c:2415 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 451 Comm: kworker/u4:3 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: kstrp strp_work Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a196cde2d4ba322b935254c75ec1bbc734abcc08 Author: Eric Dumazet Date: Thu Nov 7 10:30:42 2019 -0800 inetpeer: fix data-race in inet_putpeer / inet_putpeer commit 71685eb4ce80ae9c49eff82ca4dd15acab215de9 upstream. We need to explicitely forbid read/store tearing in inet_peer_gc() and inet_putpeer(). The following syzbot report reminds us about inet_putpeer() running without a lock held. BUG: KCSAN: data-race in inet_putpeer / inet_putpeer write to 0xffff888121fb2ed0 of 4 bytes by interrupt on cpu 0: inet_putpeer+0x37/0xa0 net/ipv4/inetpeer.c:240 ip4_frag_free+0x3d/0x50 net/ipv4/ip_fragment.c:102 inet_frag_destroy_rcu+0x58/0x80 net/ipv4/inet_fragment.c:228 __rcu_reclaim kernel/rcu/rcu.h:222 [inline] rcu_do_batch+0x256/0x5b0 kernel/rcu/tree.c:2157 rcu_core+0x369/0x4d0 kernel/rcu/tree.c:2377 rcu_core_si+0x12/0x20 kernel/rcu/tree.c:2386 __do_softirq+0x115/0x33f kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0xbb/0xe0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830 native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71 arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571 default_idle_call+0x1e/0x40 kernel/sched/idle.c:94 cpuidle_idle_call kernel/sched/idle.c:154 [inline] do_idle+0x1af/0x280 kernel/sched/idle.c:263 write to 0xffff888121fb2ed0 of 4 bytes by interrupt on cpu 1: inet_putpeer+0x37/0xa0 net/ipv4/inetpeer.c:240 ip4_frag_free+0x3d/0x50 net/ipv4/ip_fragment.c:102 inet_frag_destroy_rcu+0x58/0x80 net/ipv4/inet_fragment.c:228 __rcu_reclaim kernel/rcu/rcu.h:222 [inline] rcu_do_batch+0x256/0x5b0 kernel/rcu/tree.c:2157 rcu_core+0x369/0x4d0 kernel/rcu/tree.c:2377 rcu_core_si+0x12/0x20 kernel/rcu/tree.c:2386 __do_softirq+0x115/0x33f kernel/softirq.c:292 run_ksoftirqd+0x46/0x60 kernel/softirq.c:603 smpboot_thread_fn+0x37d/0x4a0 kernel/smpboot.c:165 kthread+0x1d4/0x200 drivers/block/aoe/aoecmd.c:1253 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.4.0-rc3+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 4b9d9be839fd ("inetpeer: remove unused list") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b0fc9cf57ff3fdcdc96748673aa88d7b93938e2d Author: Eric Dumazet Date: Sat Dec 7 14:43:39 2019 -0800 netfilter: bridge: make sure to pull arp header in br_nf_forward_arp() commit 5604285839aaedfb23ebe297799c6e558939334d upstream. syzbot is kind enough to remind us we need to call skb_may_pull() BUG: KMSAN: uninit-value in br_nf_forward_arp+0xe61/0x1230 net/bridge/br_netfilter_hooks.c:665 CPU: 1 PID: 11631 Comm: syz-executor.1 Not tainted 5.4.0-rc8-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+0x128/0x220 mm/kmsan/kmsan_report.c:108 __msan_warning+0x64/0xc0 mm/kmsan/kmsan_instr.c:245 br_nf_forward_arp+0xe61/0x1230 net/bridge/br_netfilter_hooks.c:665 nf_hook_entry_hookfn include/linux/netfilter.h:135 [inline] nf_hook_slow+0x18b/0x3f0 net/netfilter/core.c:512 nf_hook include/linux/netfilter.h:260 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] __br_forward+0x78f/0xe30 net/bridge/br_forward.c:109 br_flood+0xef0/0xfe0 net/bridge/br_forward.c:234 br_handle_frame_finish+0x1a77/0x1c20 net/bridge/br_input.c:162 nf_hook_bridge_pre net/bridge/br_input.c:245 [inline] br_handle_frame+0xfb6/0x1eb0 net/bridge/br_input.c:348 __netif_receive_skb_core+0x20b9/0x51a0 net/core/dev.c:4830 __netif_receive_skb_one_core net/core/dev.c:4927 [inline] __netif_receive_skb net/core/dev.c:5043 [inline] process_backlog+0x610/0x13c0 net/core/dev.c:5874 napi_poll net/core/dev.c:6311 [inline] net_rx_action+0x7a6/0x1aa0 net/core/dev.c:6379 __do_softirq+0x4a1/0x83a kernel/softirq.c:293 do_softirq_own_stack+0x49/0x80 arch/x86/entry/entry_64.S:1091 do_softirq kernel/softirq.c:338 [inline] __local_bh_enable_ip+0x184/0x1d0 kernel/softirq.c:190 local_bh_enable+0x36/0x40 include/linux/bottom_half.h:32 rcu_read_unlock_bh include/linux/rcupdate.h:688 [inline] __dev_queue_xmit+0x38e8/0x4200 net/core/dev.c:3819 dev_queue_xmit+0x4b/0x60 net/core/dev.c:3825 packet_snd net/packet/af_packet.c:2959 [inline] packet_sendmsg+0x8234/0x9100 net/packet/af_packet.c:2984 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] __sys_sendto+0xc44/0xc70 net/socket.c:1952 __do_sys_sendto net/socket.c:1964 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:1960 __x64_sys_sendto+0x6e/0x90 net/socket.c:1960 do_syscall_64+0xb6/0x160 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45a679 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f0a3c9e5c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000006 RCX: 000000000045a679 RDX: 000000000000000e RSI: 0000000020000200 RDI: 0000000000000003 RBP: 000000000075bf20 R08: 00000000200000c0 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f0a3c9e66d4 R13: 00000000004c8ec1 R14: 00000000004dfe28 R15: 00000000ffffffff Uninit was created at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:149 [inline] kmsan_internal_poison_shadow+0x5c/0x110 mm/kmsan/kmsan.c:132 kmsan_slab_alloc+0x97/0x100 mm/kmsan/kmsan_hooks.c:86 slab_alloc_node mm/slub.c:2773 [inline] __kmalloc_node_track_caller+0xe27/0x11a0 mm/slub.c:4381 __kmalloc_reserve net/core/skbuff.c:141 [inline] __alloc_skb+0x306/0xa10 net/core/skbuff.c:209 alloc_skb include/linux/skbuff.h:1049 [inline] alloc_skb_with_frags+0x18c/0xa80 net/core/skbuff.c:5662 sock_alloc_send_pskb+0xafd/0x10a0 net/core/sock.c:2244 packet_alloc_skb net/packet/af_packet.c:2807 [inline] packet_snd net/packet/af_packet.c:2902 [inline] packet_sendmsg+0x63a6/0x9100 net/packet/af_packet.c:2984 sock_sendmsg_nosec net/socket.c:637 [inline] sock_sendmsg net/socket.c:657 [inline] __sys_sendto+0xc44/0xc70 net/socket.c:1952 __do_sys_sendto net/socket.c:1964 [inline] __se_sys_sendto+0x107/0x130 net/socket.c:1960 __x64_sys_sendto+0x6e/0x90 net/socket.c:1960 do_syscall_64+0xb6/0x160 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: c4e70a87d975 ("netfilter: bridge: rename br_netfilter.c to br_netfilter_hooks.c") Signed-off-by: Eric Dumazet Reported-by: syzbot Reviewed-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 90e0e78bfa061997534993e57af389194bca9bd4 Author: Ursula Braun Date: Thu Dec 12 22:35:58 2019 +0100 net/smc: add fallback check to connect() commit 86434744fedf0cfe07a9eee3f4632c0e25c1d136 upstream. FASTOPEN setsockopt() or sendmsg() may switch the SMC socket to fallback mode. Once fallback mode is active, the native TCP socket functions are called. Nevertheless there is a small race window, when FASTOPEN setsockopt/sendmsg runs in parallel to a connect(), and switch the socket into fallback mode before connect() takes the sock lock. Make sure the SMC-specific connect setup is omitted in this case. This way a syzbot-reported refcount problem is fixed, triggered by different threads running non-blocking connect() and FASTOPEN_KEY setsockopt. Reported-by: syzbot+96d3f9ff6a86d37e44c8@syzkaller.appspotmail.com Fixes: 6d6dd528d5af ("net/smc: fix refcount non-blocking connect() -part 2") Signed-off-by: Ursula Braun Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit e83c40f7bb108f0466b47ab27d210a8239e72076 Author: Andrew Donnellan Date: Tue Dec 10 00:22:21 2019 +1100 powerpc: Fix __clear_user() with KUAP enabled commit 61e3acd8c693a14fc69b824cb5b08d02cb90a6e7 upstream. The KUAP implementation adds calls in clear_user() to enable and disable access to userspace memory. However, it doesn't add these to __clear_user(), which is used in the ptrace regset code. As there's only one direct user of __clear_user() (the regset code), and the time taken to set the AMR for KUAP purposes is going to dominate the cost of a quick access_ok(), there's not much point having a separate path. Rename __clear_user() to __arch_clear_user(), and make __clear_user() just call clear_user(). Reported-by: syzbot+f25ecf4b2982d8c7a640@syzkaller-ppc64.appspotmail.com Reported-by: Daniel Axtens Suggested-by: Michael Ellerman Fixes: de78a9c42a79 ("powerpc: Add a framework for Kernel Userspace Access Protection") Signed-off-by: Andrew Donnellan [mpe: Use __arch_clear_user() for the asm version like arm64 & nds32] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191209132221.15328-1-ajd@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit f0a1380de70a88f63ebfc2e3756d7f1543d2d68f Author: Eric Dumazet Date: Thu Dec 12 10:32:13 2019 -0800 6pack,mkiss: fix possible deadlock commit 5c9934b6767b16ba60be22ec3cbd4379ad64170d upstream. We got another syzbot report [1] that tells us we must use write_lock_irq()/write_unlock_irq() to avoid possible deadlock. [1] WARNING: inconsistent lock state 5.5.0-rc1-syzkaller #0 Not tainted -------------------------------- inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-R} usage. syz-executor826/9605 [HC1[1]:SC0[0]:HE0:SE1] takes: ffffffff8a128718 (disc_data_lock){+-..}, at: sp_get.isra.0+0x1d/0xf0 drivers/net/ppp/ppp_synctty.c:138 {HARDIRQ-ON-W} state was registered at: lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4485 __raw_write_lock_bh include/linux/rwlock_api_smp.h:203 [inline] _raw_write_lock_bh+0x33/0x50 kernel/locking/spinlock.c:319 sixpack_close+0x1d/0x250 drivers/net/hamradio/6pack.c:657 tty_ldisc_close.isra.0+0x119/0x1a0 drivers/tty/tty_ldisc.c:489 tty_set_ldisc+0x230/0x6b0 drivers/tty/tty_ldisc.c:585 tiocsetd drivers/tty/tty_io.c:2337 [inline] tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2597 vfs_ioctl fs/ioctl.c:47 [inline] file_ioctl fs/ioctl.c:545 [inline] do_vfs_ioctl+0x977/0x14e0 fs/ioctl.c:732 ksys_ioctl+0xab/0xd0 fs/ioctl.c:749 __do_sys_ioctl fs/ioctl.c:756 [inline] __se_sys_ioctl fs/ioctl.c:754 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:754 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe irq event stamp: 3946 hardirqs last enabled at (3945): [] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:168 [inline] hardirqs last enabled at (3945): [] _raw_spin_unlock_irq+0x23/0x80 kernel/locking/spinlock.c:199 hardirqs last disabled at (3946): [] trace_hardirqs_off_thunk+0x1a/0x1c arch/x86/entry/thunk_64.S:42 softirqs last enabled at (2658): [] spin_unlock_bh include/linux/spinlock.h:383 [inline] softirqs last enabled at (2658): [] clusterip_netdev_event+0x46f/0x670 net/ipv4/netfilter/ipt_CLUSTERIP.c:222 softirqs last disabled at (2656): [] spin_lock_bh include/linux/spinlock.h:343 [inline] softirqs last disabled at (2656): [] clusterip_netdev_event+0x1bb/0x670 net/ipv4/netfilter/ipt_CLUSTERIP.c:196 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(disc_data_lock); lock(disc_data_lock); *** DEADLOCK *** 5 locks held by syz-executor826/9605: #0: ffff8880a905e198 (&tty->legacy_mutex){+.+.}, at: tty_lock+0xc7/0x130 drivers/tty/tty_mutex.c:19 #1: ffffffff899a56c0 (rcu_read_lock){....}, at: mutex_spin_on_owner+0x0/0x330 kernel/locking/mutex.c:413 #2: ffff8880a496a2b0 (&(&i->lock)->rlock){-.-.}, at: spin_lock include/linux/spinlock.h:338 [inline] #2: ffff8880a496a2b0 (&(&i->lock)->rlock){-.-.}, at: serial8250_interrupt+0x2d/0x1a0 drivers/tty/serial/8250/8250_core.c:116 #3: ffffffff8c104048 (&port_lock_key){-.-.}, at: serial8250_handle_irq.part.0+0x24/0x330 drivers/tty/serial/8250/8250_port.c:1823 #4: ffff8880a905e090 (&tty->ldisc_sem){++++}, at: tty_ldisc_ref+0x22/0x90 drivers/tty/tty_ldisc.c:288 stack backtrace: CPU: 1 PID: 9605 Comm: syz-executor826 Not tainted 5.5.0-rc1-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+0x197/0x210 lib/dump_stack.c:118 print_usage_bug.cold+0x327/0x378 kernel/locking/lockdep.c:3101 valid_state kernel/locking/lockdep.c:3112 [inline] mark_lock_irq kernel/locking/lockdep.c:3309 [inline] mark_lock+0xbb4/0x1220 kernel/locking/lockdep.c:3666 mark_usage kernel/locking/lockdep.c:3554 [inline] __lock_acquire+0x1e55/0x4a00 kernel/locking/lockdep.c:3909 lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4485 __raw_read_lock include/linux/rwlock_api_smp.h:149 [inline] _raw_read_lock+0x32/0x50 kernel/locking/spinlock.c:223 sp_get.isra.0+0x1d/0xf0 drivers/net/ppp/ppp_synctty.c:138 sixpack_write_wakeup+0x25/0x340 drivers/net/hamradio/6pack.c:402 tty_wakeup+0xe9/0x120 drivers/tty/tty_io.c:536 tty_port_default_wakeup+0x2b/0x40 drivers/tty/tty_port.c:50 tty_port_tty_wakeup+0x57/0x70 drivers/tty/tty_port.c:387 uart_write_wakeup+0x46/0x70 drivers/tty/serial/serial_core.c:104 serial8250_tx_chars+0x495/0xaf0 drivers/tty/serial/8250/8250_port.c:1761 serial8250_handle_irq.part.0+0x2a2/0x330 drivers/tty/serial/8250/8250_port.c:1834 serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1820 [inline] serial8250_default_handle_irq+0xc0/0x150 drivers/tty/serial/8250/8250_port.c:1850 serial8250_interrupt+0xf1/0x1a0 drivers/tty/serial/8250/8250_core.c:126 __handle_irq_event_percpu+0x15d/0x970 kernel/irq/handle.c:149 handle_irq_event_percpu+0x74/0x160 kernel/irq/handle.c:189 handle_irq_event+0xa7/0x134 kernel/irq/handle.c:206 handle_edge_irq+0x25e/0x8d0 kernel/irq/chip.c:830 generic_handle_irq_desc include/linux/irqdesc.h:156 [inline] do_IRQ+0xde/0x280 arch/x86/kernel/irq.c:250 common_interrupt+0xf/0xf arch/x86/entry/entry_64.S:607 RIP: 0010:cpu_relax arch/x86/include/asm/processor.h:685 [inline] RIP: 0010:mutex_spin_on_owner+0x247/0x330 kernel/locking/mutex.c:579 Code: c3 be 08 00 00 00 4c 89 e7 e8 e5 06 59 00 4c 89 e0 48 c1 e8 03 42 80 3c 38 00 0f 85 e1 00 00 00 49 8b 04 24 a8 01 75 96 f3 90 2f fe ff ff 0f 0b e8 0d 19 09 00 84 c0 0f 85 ff fd ff ff 48 c7 RSP: 0018:ffffc90001eafa20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffd7 RAX: 0000000000000000 RBX: ffff88809fd9e0c0 RCX: 1ffffffff13266dd RDX: 0000000000000000 RSI: 0000000000000008 RDI: 0000000000000000 RBP: ffffc90001eafa60 R08: 1ffff11013d22898 R09: ffffed1013d22899 R10: ffffed1013d22898 R11: ffff88809e9144c7 R12: ffff8880a905e138 R13: ffff88809e9144c0 R14: 0000000000000000 R15: dffffc0000000000 mutex_optimistic_spin kernel/locking/mutex.c:673 [inline] __mutex_lock_common kernel/locking/mutex.c:962 [inline] __mutex_lock+0x32b/0x13c0 kernel/locking/mutex.c:1106 mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1121 tty_lock+0xc7/0x130 drivers/tty/tty_mutex.c:19 tty_release+0xb5/0xe90 drivers/tty/tty_io.c:1665 __fput+0x2ff/0x890 fs/file_table.c:280 ____fput+0x16/0x20 fs/file_table.c:313 task_work_run+0x145/0x1c0 kernel/task_work.c:113 exit_task_work include/linux/task_work.h:22 [inline] do_exit+0x8e7/0x2ef0 kernel/exit.c:797 do_group_exit+0x135/0x360 kernel/exit.c:895 __do_sys_exit_group kernel/exit.c:906 [inline] __se_sys_exit_group kernel/exit.c:904 [inline] __x64_sys_exit_group+0x44/0x50 kernel/exit.c:904 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x43fef8 Code: Bad RIP value. RSP: 002b:00007ffdb07d2338 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000000000043fef8 RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 RBP: 00000000004bf730 R08: 00000000000000e7 R09: ffffffffffffffd0 R10: 00000000004002c8 R11: 0000000000000246 R12: 0000000000000001 R13: 00000000006d1180 R14: 0000000000000000 R15: 0000000000000000 Fixes: 6e4e2f811bad ("6pack,mkiss: fix lock inconsistency") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Arnd Bergmann Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit b54ba0dc0d2f0829510797f5128d0ceb0a6c4f7d Author: Florian Westphal Date: Sun Dec 15 03:49:25 2019 +0100 netfilter: ebtables: compat: reject all padding in matches/watchers commit e608f631f0ba5f1fc5ee2e260a3a35d13107cbfe upstream. syzbot reported following splat: BUG: KASAN: vmalloc-out-of-bounds in size_entry_mwt net/bridge/netfilter/ebtables.c:2063 [inline] BUG: KASAN: vmalloc-out-of-bounds in compat_copy_entries+0x128b/0x1380 net/bridge/netfilter/ebtables.c:2155 Read of size 4 at addr ffffc900004461f4 by task syz-executor267/7937 CPU: 1 PID: 7937 Comm: syz-executor267 Not tainted 5.5.0-rc1-syzkaller #0 size_entry_mwt net/bridge/netfilter/ebtables.c:2063 [inline] compat_copy_entries+0x128b/0x1380 net/bridge/netfilter/ebtables.c:2155 compat_do_replace+0x344/0x720 net/bridge/netfilter/ebtables.c:2249 compat_do_ebt_set_ctl+0x22f/0x27e net/bridge/netfilter/ebtables.c:2333 [..] Because padding isn't considered during computation of ->buf_user_offset, "total" is decremented by fewer bytes than it should. Therefore, the first part of if (*total < sizeof(*entry) || entry->next_offset < sizeof(*entry)) will pass, -- it should not have. This causes oob access: entry->next_offset is past the vmalloced size. Reject padding and check that computed user offset (sum of ebt_entry structure plus all individual matches/watchers/targets) is same value that userspace gave us as the offset of the next entry. Reported-by: syzbot+f68108fed972453a0ad4@syzkaller.appspotmail.com Fixes: 81e675c227ec ("netfilter: ebtables: add CONFIG_COMPAT support") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit e1d93f13f647dfe133b4626612fa1ee1bd31b230 Author: Anders Kaseorg Date: Mon Dec 2 17:09:20 2019 -0500 Revert "iwlwifi: assign directly to iwl_trans->cfg in QuZ detection" commit db5cce1afc8d2475d2c1c37c2a8267dd0e151526 upstream. This reverts commit 968dcfb4905245dc64d65312c0d17692fa087b99. Both that commit and commit 809805a820c6445f7a701ded24fdc6bbc841d1e4 attempted to fix the same bug (dead assignments to the local variable cfg), but they did so in incompatible ways. When they were both merged, independently of each other, the combination actually caused the bug to reappear, leading to a firmware crash on boot for some cards. https://bugzilla.kernel.org/show_bug.cgi?id=205719 Signed-off-by: Anders Kaseorg Acked-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit 33ecb96148d61defc779bf4df47ba0d6e02129a4 Author: Yufen Yu Date: Tue Dec 10 15:01:29 2019 +0800 md: make sure desc_nr less than MD_SB_DISKS [ Upstream commit 3b7436cc9449d5ff7fa1c1fd5bc3edb6402ff5b8 ] For super_90_load, we need to make sure 'desc_nr' less than MD_SB_DISKS, avoiding invalid memory access of 'sb->disks'. Fixes: 228fc7d76db6 ("md: avoid invalid memory access for array sb->dev_roles") Signed-off-by: Yufen Yu Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 09bc029f759996193b36e46321bc305fc3a284d6 Author: Marcelo Ricardo Leitner Date: Fri Dec 20 15:03:44 2019 -0300 sctp: fix err handling of stream initialization [ Upstream commit 61d5d4062876e21331c3d0ba4b02dbd50c06a658 ] The fix on 951c6db954a1 fixed the issued reported there but introduced another. When the allocation fails within sctp_stream_init() it is okay/necessary to free the genradix. But it is also called when adding new streams, from sctp_send_add_streams() and sctp_process_strreset_addstrm_in() and in those situations it cannot just free the genradix because by then it is a fully operational association. The fix here then is to only free the genradix in sctp_stream_init() and on those other call sites move on with what it already had and let the subsequent error handling to handle it. Tested with the reproducers from this report and the previous one, with lksctp-tools and sctp-tests. Reported-by: syzbot+9a1bc632e78a1a98488b@syzkaller.appspotmail.com Fixes: 951c6db954a1 ("sctp: fix memleak on err handling of stream initialization") Signed-off-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f36b4556e544a09de899054d3cdffa8daa26191b Author: Greg Kroah-Hartman Date: Wed Jan 1 17:24:32 2020 +0100 Revert "powerpc/vcpu: Assume dedicated processors as non-preempt" This reverts commit 8332dbe5157a0056d8ab409957dfa89930066d87 which is commit 14c73bd344da60abaf7da3ea2e7733ddda35bbac upstream. It breaks the build. Cc: Guenter Roeck Cc: Parth Shah Cc: Ihor Pasichnyk Cc: Juri Lelli Cc: Waiman Long Cc: Gautham R. Shenoy Cc: Srikar Dronamraju Cc: Phil Auld Cc: Vaidyanathan Srinivasan Cc: Parth Shah Cc: Michael Ellerman Signed-off-by: Greg Kroah-Hartman commit 2176441fdd00bdeba970ec5c382723d9d1448b3d Author: Mike Rapoport Date: Sat Nov 30 17:58:01 2019 -0800 userfaultfd: require CAP_SYS_PTRACE for UFFD_FEATURE_EVENT_FORK [ Upstream commit 3c1c24d91ffd536de0a64688a9df7f49e58fadbc ] A while ago Andy noticed (http://lkml.kernel.org/r/CALCETrWY+5ynDct7eU_nDUqx=okQvjm=Y5wJvA4ahBja=CQXGw@mail.gmail.com) that UFFD_FEATURE_EVENT_FORK used by an unprivileged user may have security implications. As the first step of the solution the following patch limits the availably of UFFD_FEATURE_EVENT_FORK only for those having CAP_SYS_PTRACE. The usage of CAP_SYS_PTRACE ensures compatibility with CRIU. Yet, if there are other users of non-cooperative userfaultfd that run without CAP_SYS_PTRACE, they would be broken :( Current implementation of UFFD_FEATURE_EVENT_FORK modifies the file descriptor table from the read() implementation of uffd, which may have security implications for unprivileged use of the userfaultfd. Limit availability of UFFD_FEATURE_EVENT_FORK only for callers that have CAP_SYS_PTRACE. Link: http://lkml.kernel.org/r/1572967777-8812-2-git-send-email-rppt@linux.ibm.com Signed-off-by: Mike Rapoport Reviewed-by: Andrea Arcangeli Cc: Daniel Colascione Cc: Jann Horn Cc: Lokesh Gidra Cc: Nick Kralevich Cc: Nosh Minwalla Cc: Pavel Emelyanov Cc: Tim Murray Cc: Aleksa Sarai Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ead87f1165cc1ff5fb809ec11f82866f02bca810 Author: Johannes Weiner Date: Sat Nov 30 17:56:08 2019 -0800 kernel: sysctl: make drop_caches write-only [ Upstream commit 204cb79ad42f015312a5bbd7012d09c93d9b46fb ] Currently, the drop_caches proc file and sysctl read back the last value written, suggesting this is somehow a stateful setting instead of a one-time command. Make it write-only, like e.g. compact_memory. While mitigating a VM problem at scale in our fleet, there was confusion about whether writing to this file will permanently switch the kernel into a non-caching mode. This influences the decision making in a tense situation, where tens of people are trying to fix tens of thousands of affected machines: Do we need a rollback strategy? What are the performance implications of operating in a non-caching state for several days? It also caused confusion when the kernel team said we may need to write the file several times to make sure it's effective ("But it already reads back 3?"). Link: http://lkml.kernel.org/r/20191031221602.9375-1-hannes@cmpxchg.org Signed-off-by: Johannes Weiner Acked-by: Chris Down Acked-by: Vlastimil Babka Acked-by: David Hildenbrand Acked-by: Michal Hocko Acked-by: Alexey Dobriyan Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 865e3fd60eaa6bc3f5271708b520bd55e98f1a48 Author: Mike Kravetz Date: Sat Nov 30 17:56:34 2019 -0800 mm/hugetlbfs: fix error handling when setting up mounts [ Upstream commit 8fc312b32b25c6b0a8b46fab4df8c68df5af1223 ] It is assumed that the hugetlbfs_vfsmount[] array will contain either a valid vfsmount pointer or NULL for each hstate after initialization. Changes made while converting to use fs_context broke this assumption. While fixing the hugetlbfs_vfsmount issue, it was discovered that init_hugetlbfs_fs never did correctly clean up when encountering a vfs mount error. It was found during code inspection. A small memory allocation failure would be the most likely cause of taking a error path with the bug. This is unlikely to happen as this is early init code. Link: http://lkml.kernel.org/r/94b6244d-2c24-e269-b12c-e3ba694b242d@oracle.com Reported-by: Chengguang Xu Fixes: 32021982a324 ("hugetlbfs: Convert to fs_context") Signed-off-by: Mike Kravetz Cc: David Howells Cc: Al Viro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 623309a6e6c840e0e84b36ac40058c0e7be2307b Author: Anders Roxell Date: Sat Nov 30 17:54:43 2019 -0800 selftests: vm: add fragment CONFIG_TEST_VMALLOC [ Upstream commit 746dd4012d215b53152f0001a48856e41ea31730 ] When running test_vmalloc.sh smoke the following print out states that the fragment is missing. # ./test_vmalloc.sh: You must have the following enabled in your kernel: # CONFIG_TEST_VMALLOC=m Rework to add the fragment 'CONFIG_TEST_VMALLOC=m' to the config file. Link: http://lkml.kernel.org/r/20190916095217.19665-1-anders.roxell@linaro.org Fixes: a05ef00c9790 ("selftests/vm: add script helper for CONFIG_TEST_VMALLOC_MODULE") Signed-off-by: Anders Roxell Cc: Shuah Khan Cc: "Uladzislau Rezki (Sony)" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit e0ca1ec34d7f3888003130b22e312db99dad6387 Author: Vasily Gorbik Date: Fri Nov 22 12:19:16 2019 +0100 s390: disable preemption when switching to nodat stack with CALL_ON_STACK [ Upstream commit 7f28dad395243c5026d649136823bbc40029a828 ] Make sure preemption is disabled when temporary switching to nodat stack with CALL_ON_STACK helper, because nodat stack is per cpu. Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 99472d43f4ef93c293bc4a4b364608889b7d3139 Author: Daniel Baluta Date: Wed Oct 9 16:07:18 2019 +0800 mailbox: imx: Fix Tx doorbell shutdown path [ Upstream commit bf159d151a0b844be28882f39e316b5800acaa2b ] Tx doorbell is handled by txdb_tasklet and doesn't have an associated IRQ. Anyhow, imx_mu_shutdown ignores this and tries to free an IRQ that wasn't requested for Tx DB resulting in the following warning: [ 1.967644] Trying to free already-free IRQ 26 [ 1.972108] WARNING: CPU: 2 PID: 157 at kernel/irq/manage.c:1708 __free_irq+0xc0/0x358 [ 1.980024] Modules linked in: [ 1.983088] CPU: 2 PID: 157 Comm: kworker/2:1 Tainted: G [ 1.993524] Hardware name: Freescale i.MX8QXP MEK (DT) [ 1.998668] Workqueue: events deferred_probe_work_func [ 2.003812] pstate: 60000085 (nZCv daIf -PAN -UAO) [ 2.008607] pc : __free_irq+0xc0/0x358 [ 2.012364] lr : __free_irq+0xc0/0x358 [ 2.016111] sp : ffff00001179b7e0 [ 2.019422] x29: ffff00001179b7e0 x28: 0000000000000018 [ 2.024736] x27: ffff000011233000 x26: 0000000000000004 [ 2.030053] x25: 000000000000001a x24: ffff80083bec74d4 [ 2.035369] x23: 0000000000000000 x22: ffff80083bec7588 [ 2.040686] x21: ffff80083b1fe8d8 x20: ffff80083bec7400 [ 2.046003] x19: 0000000000000000 x18: ffffffffffffffff [ 2.051320] x17: 0000000000000000 x16: 0000000000000000 [ 2.056637] x15: ffff0000111296c8 x14: ffff00009179b517 [ 2.061953] x13: ffff00001179b525 x12: ffff000011142000 [ 2.067270] x11: ffff000011129f20 x10: ffff0000105da970 [ 2.072587] x9 : 00000000ffffffd0 x8 : 0000000000000194 [ 2.077903] x7 : 612065657266206f x6 : ffff0000111e7b09 [ 2.083220] x5 : 0000000000000003 x4 : 0000000000000000 [ 2.088537] x3 : 0000000000000000 x2 : 00000000ffffffff [ 2.093854] x1 : 28b70f0a2b60a500 x0 : 0000000000000000 [ 2.099173] Call trace: [ 2.101618] __free_irq+0xc0/0x358 [ 2.105021] free_irq+0x38/0x98 [ 2.108170] imx_mu_shutdown+0x90/0xb0 [ 2.111921] mbox_free_channel.part.2+0x24/0xb8 [ 2.116453] mbox_free_channel+0x18/0x28 This bug is present from the beginning of times. Cc: Oleksij Rempel Signed-off-by: Daniel Baluta Signed-off-by: Richard Zhu Reviewed-by: Dong Aisheng Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 496cec79449b6beee9d67f227c8d4de02be76ccc Author: Ding Xiang Date: Sat Nov 30 17:49:12 2019 -0800 ocfs2: fix passing zero to 'PTR_ERR' warning [ Upstream commit 188c523e1c271d537f3c9f55b6b65bf4476de32f ] Fix a static code checker warning: fs/ocfs2/acl.c:331 ocfs2_acl_chmod() warn: passing zero to 'PTR_ERR' Link: http://lkml.kernel.org/r/1dee278b-6c96-eec2-ce76-fe6e07c6e20f@linux.alibaba.com Fixes: 5ee0fbd50fd ("ocfs2: revert using ocfs2_acl_chmod to avoid inode cluster lock hang") Signed-off-by: Ding Xiang Reviewed-by: Joseph Qi Cc: Mark Fasheh Cc: Joel Becker Cc: Junxiao Bi Cc: Changwei Ge Cc: Gang He Cc: Jun Piao Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit ef6f6e717de77caf0dc4b93cb2fac93e1b4e7f7c Author: Thomas Richter Date: Fri Nov 22 16:43:15 2019 +0100 s390/cpum_sf: Check for SDBT and SDB consistency [ Upstream commit 247f265fa502e7b17a0cb0cc330e055a36aafce4 ] Each SBDT is located at a 4KB page and contains 512 entries. Each entry of a SDBT points to a SDB, a 4KB page containing sampled data. The last entry is a link to another SDBT page. When an event is created the function sequence executed is: __hw_perf_event_init() +--> allocate_buffers() +--> realloc_sampling_buffers() +---> alloc_sample_data_block() Both functions realloc_sampling_buffers() and alloc_sample_data_block() allocate pages and the allocation can fail. This is handled correctly and all allocated pages are freed and error -ENOMEM is returned to the top calling function. Finally the event is not created. Once the event has been created, the amount of initially allocated SDBT and SDB can be too low. This is detected during measurement interrupt handling, where the amount of lost samples is calculated. If the number of lost samples is too high considering sampling frequency and already allocated SBDs, the number of SDBs is enlarged during the next execution of cpumsf_pmu_enable(). If more SBDs need to be allocated, functions realloc_sampling_buffers() +---> alloc-sample_data_block() are called to allocate more pages. Page allocation may fail and the returned error is ignored. A SDBT and SDB setup already exists. However the modified SDBTs and SDBs might end up in a situation where the first entry of an SDBT does not point to an SDB, but another SDBT, basicly an SBDT without payload. This can not be handled by the interrupt handler, where an SDBT must have at least one entry pointing to an SBD. Add a check to avoid SDBTs with out payload (SDBs) when enlarging the buffer setup. Signed-off-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit cff542509ec302ea63b9cc19ae2226740883ba63 Author: Vasily Gorbik Date: Wed Nov 27 18:12:04 2019 +0100 s390/unwind: filter out unreliable bogus %r14 [ Upstream commit bf018ee644897d7982e1b8dd8b15e97db6e1a4da ] Currently unwinder unconditionally returns %r14 from the first frame pointed by %r15 from pt_regs. A task could be interrupted when a function already allocated this frame (if it needs it) for its callees or to store local variables. In that case this frame would contain random values from stack or values stored there by a callee. As we are only interested in %r14 to get potential return address, skip bogus return addresses which doesn't belong to kernel text. This helps to avoid duplicating filtering logic in unwider users, most of which use unwind_get_return_address() and would choke on bogus 0 address returned by it otherwise. Reviewed-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit ebd75fea2cda2a1ecfe2a63ed2316665ed193f97 Author: Masahiro Yamada Date: Wed Nov 13 16:12:02 2019 +0900 libfdt: define INT32_MAX and UINT32_MAX in libfdt_env.h [ Upstream commit a8de1304b7df30e3a14f2a8b9709bb4ff31a0385 ] The DTC v1.5.1 added references to (U)INT32_MAX. This is no problem for user-space programs since defines (U)INT32_MAX along with (u)int32_t. For the kernel space, libfdt_env.h needs to be adjusted before we pull in the changes. In the kernel, we usually use s/u32 instead of (u)int32_t for the fixed-width types. Accordingly, we already have S/U32_MAX for their max values. So, we should not add (U)INT32_MAX to any more. Instead, add them to the in-kernel libfdt_env.h to compile the latest libfdt. Signed-off-by: Masahiro Yamada Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit c1a6e48c0c74fa3d939adc5eef727df2648df485 Author: Daniel Baluta Date: Wed Oct 9 16:07:19 2019 +0800 mailbox: imx: Clear the right interrupts at shutdown [ Upstream commit 5f0af07e89199ac51cdd4f25bc303bdc703f4e9c ] Make sure to only clear enabled interrupts keeping count of the connection type. Suggested-by: Oleksij Rempel Signed-off-by: Daniel Baluta Signed-off-by: Richard Zhu Reviewed-by: Dong Aisheng Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit e3ef5071a5d9c2417ad1a5f2ecac32a31ae7876a Author: Harald Freudenberger Date: Wed Nov 20 11:44:31 2019 +0100 s390/zcrypt: handle new reply code FILTERED_BY_HYPERVISOR [ Upstream commit 6733775a92eacd612ac88afa0fd922e4ffeb2bc7 ] This patch introduces support for a new architectured reply code 0x8B indicating that a hypervisor layer (if any) has rejected an ap message. Linux may run as a guest on top of a hypervisor like zVM or KVM. So the crypto hardware seen by the ap bus may be restricted by the hypervisor for example only a subset like only clear key crypto requests may be supported. Other requests will be filtered out - rejected by the hypervisor. The new reply code 0x8B will appear in such cases and needs to get recognized by the ap bus and zcrypt device driver zoo. Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 4992f88dfe93376b3364a1675182b3b094c6abb1 Author: Arnaldo Carvalho de Melo Date: Wed Nov 27 10:13:34 2019 -0300 perf regs: Make perf_reg_name() return "unknown" instead of NULL [ Upstream commit 5b596e0ff0e1852197d4c82d3314db5e43126bf7 ] To avoid breaking the build on arches where this is not wired up, at least all the other features should be made available and when using this specific routine, the "unknown" should point the user/developer to the need to wire this up on this particular hardware architecture. Detected in a container mipsel debian cross build environment, where it shows up as: In file included from /usr/mipsel-linux-gnu/include/stdio.h:867, from /git/linux/tools/perf/lib/include/perf/cpumap.h:6, from util/session.c:13: In function 'printf', inlined from 'regs_dump__printf' at util/session.c:1103:3, inlined from 'regs__printf' at util/session.c:1131:2: /usr/mipsel-linux-gnu/include/bits/stdio2.h:107:10: error: '%-5s' directive argument is null [-Werror=format-overflow=] 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cross compiler details: mipsel-linux-gnu-gcc (Debian 9.2.1-8) 9.2.1 20190909 Also on mips64: In file included from /usr/mips64-linux-gnuabi64/include/stdio.h:867, from /git/linux/tools/perf/lib/include/perf/cpumap.h:6, from util/session.c:13: In function 'printf', inlined from 'regs_dump__printf' at util/session.c:1103:3, inlined from 'regs__printf' at util/session.c:1131:2, inlined from 'regs_user__printf' at util/session.c:1139:3, inlined from 'dump_sample' at util/session.c:1246:3, inlined from 'machines__deliver_event' at util/session.c:1421:3: /usr/mips64-linux-gnuabi64/include/bits/stdio2.h:107:10: error: '%-5s' directive argument is null [-Werror=format-overflow=] 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'printf', inlined from 'regs_dump__printf' at util/session.c:1103:3, inlined from 'regs__printf' at util/session.c:1131:2, inlined from 'regs_intr__printf' at util/session.c:1147:3, inlined from 'dump_sample' at util/session.c:1249:3, inlined from 'machines__deliver_event' at util/session.c:1421:3: /usr/mips64-linux-gnuabi64/include/bits/stdio2.h:107:10: error: '%-5s' directive argument is null [-Werror=format-overflow=] 107 | return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cross compiler details: mips64-linux-gnuabi64-gcc (Debian 9.2.1-8) 9.2.1 20190909 Fixes: 2bcd355b71da ("perf tools: Add interface to arch registers sets") Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-95wjyv4o65nuaeweq31t7l1s@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4c61219f6d204849446e3b20737310d6b1a4f70d Author: Adrian Hunter Date: Wed Nov 27 11:53:21 2019 +0200 perf script: Fix brstackinsn for AUXTRACE [ Upstream commit 0cd032d3b5fcebf5454315400ab310746a81ca53 ] brstackinsn must be allowed to be set by the user when AUX area data has been captured because, in that case, the branch stack might be synthesized on the fly. This fixes the following error: Before: $ perf record -e '{intel_pt//,cpu/mem_inst_retired.all_loads,aux-sample-size=8192/pp}:u' grep -rqs jhgjhg /boot [ perf record: Woken up 19 times to write data ] [ perf record: Captured and wrote 2.274 MB perf.data ] $ perf script -F +brstackinsn --xed --itrace=i1usl100 | head Display of branch stack assembler requested, but non all-branch filter set Hint: run 'perf record -b ...' After: $ perf record -e '{intel_pt//,cpu/mem_inst_retired.all_loads,aux-sample-size=8192/pp}:u' grep -rqs jhgjhg /boot [ perf record: Woken up 19 times to write data ] [ perf record: Captured and wrote 2.274 MB perf.data ] $ perf script -F +brstackinsn --xed --itrace=i1usl100 | head grep 13759 [002] 8091.310257: 1862 instructions:uH: 5641d58069eb bmexec+0x86b (/bin/grep) bmexec+2485: 00005641d5806b35 jnz 0x5641d5806bd0 # MISPRED 00005641d5806bd0 movzxb (%r13,%rdx,1), %eax 00005641d5806bd6 add %rdi, %rax 00005641d5806bd9 movzxb -0x1(%rax), %edx 00005641d5806bdd cmp %rax, %r14 00005641d5806be0 jnb 0x5641d58069c0 # MISPRED mismatch of LBR data and executable 00005641d58069c0 movzxb (%r13,%rdx,1), %edi Fixes: 48d02a1d5c13 ("perf script: Add 'brstackinsn' for branch stacks") Reported-by: Andi Kleen Signed-off-by: Adrian Hunter Cc: Jiri Olsa Link: http://lore.kernel.org/lkml/20191127095322.15417-1-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 734e4a8cd43d275c59218d6408cc354277954828 Author: Arnaldo Carvalho de Melo Date: Wed Nov 27 09:58:22 2019 -0300 perf diff: Use llabs() with 64-bit values [ Upstream commit 98e93245113d0f5c279ef77f4a9e7d097323ad71 ] To fix these build errors on a debian mipsel cross build environment: builtin-diff.c: In function 'block_cycles_diff_cmp': builtin-diff.c:550:6: error: absolute value function 'labs' given an argument of type 's64' {aka 'long long int'} but has parameter of type 'long int' which may cause truncation of value [-Werror=absolute-value] 550 | l = labs(left->diff.cycles); | ^~~~ builtin-diff.c:551:6: error: absolute value function 'labs' given an argument of type 's64' {aka 'long long int'} but has parameter of type 'long int' which may cause truncation of value [-Werror=absolute-value] 551 | r = labs(right->diff.cycles); | ^~~~ Fixes: 99150a1faab2 ("perf diff: Use hists to manage basic blocks per symbol") Cc: Jin Yao Cc: Adrian Hunter Cc: Jiri Olsa Cc: Namhyung Kim Link: https://lkml.kernel.org/n/tip-pn7szy5uw384ntjgk6zckh6a@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 2685410d1e3c7b184d09b07f5473e7d5b33c4d34 Author: Ronnie Sahlberg Date: Sun Nov 3 13:06:37 2019 +1000 cifs: move cifsFileInfo_put logic into a work-queue [ Upstream commit 32546a9586aa4565035bb557e191648e022b29e8 ] This patch moves the final part of the cifsFileInfo_put() logic where we need a write lock on lock_sem to be processed in a separate thread that holds no other locks. This is to prevent deadlocks like the one below: > there are 6 processes looping to while trying to down_write > cinode->lock_sem, 5 of them from _cifsFileInfo_put, and one from > cifs_new_fileinfo > > and there are 5 other processes which are blocked, several of them > waiting on either PG_writeback or PG_locked (which are both set), all > for the same page of the file > > 2 inode_lock() (inode->i_rwsem) for the file > 1 wait_on_page_writeback() for the page > 1 down_read(inode->i_rwsem) for the inode of the directory > 1 inode_lock()(inode->i_rwsem) for the inode of the directory > 1 __lock_page > > > so processes are blocked waiting on: > page flags PG_locked and PG_writeback for one specific page > inode->i_rwsem for the directory > inode->i_rwsem for the file > cifsInodeInflock_sem > > > > here are the more gory details (let me know if I need to provide > anything more/better): > > [0 00:48:22.765] [UN] PID: 8863 TASK: ffff8c691547c5c0 CPU: 3 > COMMAND: "reopen_file" > #0 [ffff9965007e3ba8] __schedule at ffffffff9b6e6095 > #1 [ffff9965007e3c38] schedule at ffffffff9b6e64df > #2 [ffff9965007e3c48] rwsem_down_write_slowpath at ffffffff9af283d7 > #3 [ffff9965007e3cb8] legitimize_path at ffffffff9b0f975d > #4 [ffff9965007e3d08] path_openat at ffffffff9b0fe55d > #5 [ffff9965007e3dd8] do_filp_open at ffffffff9b100a33 > #6 [ffff9965007e3ee0] do_sys_open at ffffffff9b0eb2d6 > #7 [ffff9965007e3f38] do_syscall_64 at ffffffff9ae04315 > * (I think legitimize_path is bogus) > > in path_openat > } else { > const char *s = path_init(nd, flags); > while (!(error = link_path_walk(s, nd)) && > (error = do_last(nd, file, op)) > 0) { <<<< > > do_last: > if (open_flag & O_CREAT) > inode_lock(dir->d_inode); <<<< > else > so it's trying to take inode->i_rwsem for the directory > > DENTRY INODE SUPERBLK TYPE PATH > ffff8c68bb8e79c0 ffff8c691158ef20 ffff8c6915bf9000 DIR /mnt/vm1_smb/ > inode.i_rwsem is ffff8c691158efc0 > > : > owner: (UN - 8856 - > reopen_file), counter: 0x0000000000000003 > waitlist: 2 > 0xffff9965007e3c90 8863 reopen_file UN 0 1:29:22.926 > RWSEM_WAITING_FOR_WRITE > 0xffff996500393e00 9802 ls UN 0 1:17:26.700 > RWSEM_WAITING_FOR_READ > > > the owner of the inode.i_rwsem of the directory is: > > [0 00:00:00.109] [UN] PID: 8856 TASK: ffff8c6914275d00 CPU: 3 > COMMAND: "reopen_file" > #0 [ffff99650065b828] __schedule at ffffffff9b6e6095 > #1 [ffff99650065b8b8] schedule at ffffffff9b6e64df > #2 [ffff99650065b8c8] schedule_timeout at ffffffff9b6e9f89 > #3 [ffff99650065b940] msleep at ffffffff9af573a9 > #4 [ffff99650065b948] _cifsFileInfo_put.cold.63 at ffffffffc0a42dd6 [cifs] > #5 [ffff99650065ba38] cifs_writepage_locked at ffffffffc0a0b8f3 [cifs] > #6 [ffff99650065bab0] cifs_launder_page at ffffffffc0a0bb72 [cifs] > #7 [ffff99650065bb30] invalidate_inode_pages2_range at ffffffff9b04d4bd > #8 [ffff99650065bcb8] cifs_invalidate_mapping at ffffffffc0a11339 [cifs] > #9 [ffff99650065bcd0] cifs_revalidate_mapping at ffffffffc0a1139a [cifs] > #10 [ffff99650065bcf0] cifs_d_revalidate at ffffffffc0a014f6 [cifs] > #11 [ffff99650065bd08] path_openat at ffffffff9b0fe7f7 > #12 [ffff99650065bdd8] do_filp_open at ffffffff9b100a33 > #13 [ffff99650065bee0] do_sys_open at ffffffff9b0eb2d6 > #14 [ffff99650065bf38] do_syscall_64 at ffffffff9ae04315 > > cifs_launder_page is for page 0xffffd1e2c07d2480 > > crash> page.index,mapping,flags 0xffffd1e2c07d2480 > index = 0x8 > mapping = 0xffff8c68f3cd0db0 > flags = 0xfffffc0008095 > > PAGE-FLAG BIT VALUE > PG_locked 0 0000001 > PG_uptodate 2 0000004 > PG_lru 4 0000010 > PG_waiters 7 0000080 > PG_writeback 15 0008000 > > > inode is ffff8c68f3cd0c40 > inode.i_rwsem is ffff8c68f3cd0ce0 > DENTRY INODE SUPERBLK TYPE PATH > ffff8c68a1f1b480 ffff8c68f3cd0c40 ffff8c6915bf9000 REG > /mnt/vm1_smb/testfile.8853 > > > this process holds the inode->i_rwsem for the parent directory, is > laundering a page attached to the inode of the file it's opening, and in > _cifsFileInfo_put is trying to down_write the cifsInodeInflock_sem > for the file itself. > > > : > owner: (UN - 8854 - > reopen_file), counter: 0x0000000000000003 > waitlist: 1 > 0xffff9965005dfd80 8855 reopen_file UN 0 1:29:22.912 > RWSEM_WAITING_FOR_WRITE > > this is the inode.i_rwsem for the file > > the owner: > > [0 00:48:22.739] [UN] PID: 8854 TASK: ffff8c6914272e80 CPU: 2 > COMMAND: "reopen_file" > #0 [ffff99650054fb38] __schedule at ffffffff9b6e6095 > #1 [ffff99650054fbc8] schedule at ffffffff9b6e64df > #2 [ffff99650054fbd8] io_schedule at ffffffff9b6e68e2 > #3 [ffff99650054fbe8] __lock_page at ffffffff9b03c56f > #4 [ffff99650054fc80] pagecache_get_page at ffffffff9b03dcdf > #5 [ffff99650054fcc0] grab_cache_page_write_begin at ffffffff9b03ef4c > #6 [ffff99650054fcd0] cifs_write_begin at ffffffffc0a064ec [cifs] > #7 [ffff99650054fd30] generic_perform_write at ffffffff9b03bba4 > #8 [ffff99650054fda8] __generic_file_write_iter at ffffffff9b04060a > #9 [ffff99650054fdf0] cifs_strict_writev.cold.70 at ffffffffc0a4469b [cifs] > #10 [ffff99650054fe48] new_sync_write at ffffffff9b0ec1dd > #11 [ffff99650054fed0] vfs_write at ffffffff9b0eed35 > #12 [ffff99650054ff00] ksys_write at ffffffff9b0eefd9 > #13 [ffff99650054ff38] do_syscall_64 at ffffffff9ae04315 > > the process holds the inode->i_rwsem for the file to which it's writing, > and is trying to __lock_page for the same page as in the other processes > > > the other tasks: > [0 00:00:00.028] [UN] PID: 8859 TASK: ffff8c6915479740 CPU: 2 > COMMAND: "reopen_file" > #0 [ffff9965007b39d8] __schedule at ffffffff9b6e6095 > #1 [ffff9965007b3a68] schedule at ffffffff9b6e64df > #2 [ffff9965007b3a78] schedule_timeout at ffffffff9b6e9f89 > #3 [ffff9965007b3af0] msleep at ffffffff9af573a9 > #4 [ffff9965007b3af8] cifs_new_fileinfo.cold.61 at ffffffffc0a42a07 [cifs] > #5 [ffff9965007b3b78] cifs_open at ffffffffc0a0709d [cifs] > #6 [ffff9965007b3cd8] do_dentry_open at ffffffff9b0e9b7a > #7 [ffff9965007b3d08] path_openat at ffffffff9b0fe34f > #8 [ffff9965007b3dd8] do_filp_open at ffffffff9b100a33 > #9 [ffff9965007b3ee0] do_sys_open at ffffffff9b0eb2d6 > #10 [ffff9965007b3f38] do_syscall_64 at ffffffff9ae04315 > > this is opening the file, and is trying to down_write cinode->lock_sem > > > [0 00:00:00.041] [UN] PID: 8860 TASK: ffff8c691547ae80 CPU: 2 > COMMAND: "reopen_file" > [0 00:00:00.057] [UN] PID: 8861 TASK: ffff8c6915478000 CPU: 3 > COMMAND: "reopen_file" > [0 00:00:00.059] [UN] PID: 8858 TASK: ffff8c6914271740 CPU: 2 > COMMAND: "reopen_file" > [0 00:00:00.109] [UN] PID: 8862 TASK: ffff8c691547dd00 CPU: 6 > COMMAND: "reopen_file" > #0 [ffff9965007c3c78] __schedule at ffffffff9b6e6095 > #1 [ffff9965007c3d08] schedule at ffffffff9b6e64df > #2 [ffff9965007c3d18] schedule_timeout at ffffffff9b6e9f89 > #3 [ffff9965007c3d90] msleep at ffffffff9af573a9 > #4 [ffff9965007c3d98] _cifsFileInfo_put.cold.63 at ffffffffc0a42dd6 [cifs] > #5 [ffff9965007c3e88] cifs_close at ffffffffc0a07aaf [cifs] > #6 [ffff9965007c3ea0] __fput at ffffffff9b0efa6e > #7 [ffff9965007c3ee8] task_work_run at ffffffff9aef1614 > #8 [ffff9965007c3f20] exit_to_usermode_loop at ffffffff9ae03d6f > #9 [ffff9965007c3f38] do_syscall_64 at ffffffff9ae0444c > > closing the file, and trying to down_write cifsi->lock_sem > > > [0 00:48:22.839] [UN] PID: 8857 TASK: ffff8c6914270000 CPU: 7 > COMMAND: "reopen_file" > #0 [ffff9965006a7cc8] __schedule at ffffffff9b6e6095 > #1 [ffff9965006a7d58] schedule at ffffffff9b6e64df > #2 [ffff9965006a7d68] io_schedule at ffffffff9b6e68e2 > #3 [ffff9965006a7d78] wait_on_page_bit at ffffffff9b03cac6 > #4 [ffff9965006a7e10] __filemap_fdatawait_range at ffffffff9b03b028 > #5 [ffff9965006a7ed8] filemap_write_and_wait at ffffffff9b040165 > #6 [ffff9965006a7ef0] cifs_flush at ffffffffc0a0c2fa [cifs] > #7 [ffff9965006a7f10] filp_close at ffffffff9b0e93f1 > #8 [ffff9965006a7f30] __x64_sys_close at ffffffff9b0e9a0e > #9 [ffff9965006a7f38] do_syscall_64 at ffffffff9ae04315 > > in __filemap_fdatawait_range > wait_on_page_writeback(page); > for the same page of the file > > > > [0 00:48:22.718] [UN] PID: 8855 TASK: ffff8c69142745c0 CPU: 7 > COMMAND: "reopen_file" > #0 [ffff9965005dfc98] __schedule at ffffffff9b6e6095 > #1 [ffff9965005dfd28] schedule at ffffffff9b6e64df > #2 [ffff9965005dfd38] rwsem_down_write_slowpath at ffffffff9af283d7 > #3 [ffff9965005dfdf0] cifs_strict_writev at ffffffffc0a0c40a [cifs] > #4 [ffff9965005dfe48] new_sync_write at ffffffff9b0ec1dd > #5 [ffff9965005dfed0] vfs_write at ffffffff9b0eed35 > #6 [ffff9965005dff00] ksys_write at ffffffff9b0eefd9 > #7 [ffff9965005dff38] do_syscall_64 at ffffffff9ae04315 > > inode_lock(inode); > > > and one 'ls' later on, to see whether the rest of the mount is available > (the test file is in the root, so we get blocked up on the directory > ->i_rwsem), so the entire mount is unavailable > > [0 00:36:26.473] [UN] PID: 9802 TASK: ffff8c691436ae80 CPU: 4 > COMMAND: "ls" > #0 [ffff996500393d28] __schedule at ffffffff9b6e6095 > #1 [ffff996500393db8] schedule at ffffffff9b6e64df > #2 [ffff996500393dc8] rwsem_down_read_slowpath at ffffffff9b6e9421 > #3 [ffff996500393e78] down_read_killable at ffffffff9b6e95e2 > #4 [ffff996500393e88] iterate_dir at ffffffff9b103c56 > #5 [ffff996500393ec8] ksys_getdents64 at ffffffff9b104b0c > #6 [ffff996500393f30] __x64_sys_getdents64 at ffffffff9b104bb6 > #7 [ffff996500393f38] do_syscall_64 at ffffffff9ae04315 > > in iterate_dir: > if (shared) > res = down_read_killable(&inode->i_rwsem); <<<< > else > res = down_write_killable(&inode->i_rwsem); > Reported-by: Frank Sorenson Reviewed-by: Pavel Shilovsky Signed-off-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 7739bc1e0e65e9a64793abbef2342d1dda35cc26 Author: Diego Elio Pettenò Date: Tue Nov 19 21:37:08 2019 +0000 cdrom: respect device capabilities during opening action [ Upstream commit 366ba7c71ef77c08d06b18ad61b26e2df7352338 ] Reading the TOC only works if the device can play audio, otherwise these commands fail (and possibly bring the device to an unhealthy state.) Similarly, cdrom_mmc3_profile() should only be called if the device supports generic packet commands. To: Jens Axboe Cc: linux-kernel@vger.kernel.org Cc: linux-scsi@vger.kernel.org Signed-off-by: Diego Elio Pettenò Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4c45e9ed2457606b4d0bd5744538a1d81289391f Author: Erhard Furtner Date: Tue Nov 26 02:48:04 2019 +0100 of: unittest: fix memory leak in attach_node_and_children [ Upstream commit 2aacace6dbbb6b6ce4e177e6c7ea901f389c0472 ] In attach_node_and_children memory is allocated for full_name via kasprintf. If the condition of the 1st if is not met the function returns early without freeing the memory. Add a kfree() to fix that. This has been detected with kmemleak: Link: https://bugzilla.kernel.org/show_bug.cgi?id=205327 It looks like the leak was introduced by this commit: Fixes: 5babefb7f7ab ("of: unittest: allow base devicetree to have symbol metadata") Signed-off-by: Erhard Furtner Reviewed-by: Michael Ellerman Reviewed-by: Tyrel Datwyler Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 1768acaa6d8a0a0ef6b6ac3d3c0467e4ab404840 Author: Jens Axboe Date: Wed Nov 20 09:26:29 2019 -0700 io_uring: io_allocate_scq_urings() should return a sane state [ Upstream commit eb065d301e8c83643367bdb0898becc364046bda ] We currently rely on the ring destroy on cleaning things up in case of failure, but io_allocate_scq_urings() can leave things half initialized if only parts of it fails. Be nice and return with either everything setup in success, or return an error with things nicely cleaned up. Reported-by: syzbot+0d818c0d39399188f393@syzkaller.appspotmail.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b36482417730be1a73657ca2aa77c0e12f4cd3d9 Author: Johannes Berg Date: Tue Sep 24 09:21:17 2019 +0200 um: virtio: Keep reading on -EAGAIN [ Upstream commit 7e60746005573a06149cdee7acedf428906f3a59 ] When we get an interrupt from the socket getting readable, and start reading, there's a possibility for a race. This depends on the implementation of the device, but e.g. with qemu's libvhost-user, we can see: device virtio_uml --------------------------------------- write header get interrupt read header read body -> returns -EAGAIN write body The -EAGAIN return is because the socket is non-blocking, and then this leads us to abandon this message. In fact, we've already read the header, so when the get another signal/interrupt for the body, we again read it as though it's a new message header, and also abandon it for the same reason (wrong size etc.) This essentially breaks things, and if that message was one that required a response, it leads to a deadlock as the device is waiting for the response but we'll never reply. Fix this by spinning on -EAGAIN as well when we read the message body. We need to handle -EAGAIN as "no message" while reading the header, since we share an interrupt. Note that this situation is highly unlikely to occur in normal usage, since there will be very few messages and only in the startup phase. With the inband call feature this does tend to happen (eventually) though. Signed-off-by: Johannes Berg Signed-off-by: Richard Weinberger Signed-off-by: Sasha Levin commit 42e8507bf2dcd39b4eddc318d63a1b494ffd098a Author: Paulo Alcantara (SUSE) Date: Fri Nov 22 12:30:51 2019 -0300 cifs: Fix use-after-free bug in cifs_reconnect() [ Upstream commit 8354d88efdab72b4da32fc4f032448fcef22dab4 ] Ensure we grab an active reference in cifs superblock while doing failover to prevent automounts (DFS links) of expiring and then destroying the superblock pointer. This patch fixes the following KASAN report: [ 464.301462] BUG: KASAN: use-after-free in cifs_reconnect+0x6ab/0x1350 [ 464.303052] Read of size 8 at addr ffff888155e580d0 by task cifsd/1107 [ 464.304682] CPU: 3 PID: 1107 Comm: cifsd Not tainted 5.4.0-rc4+ #13 [ 464.305552] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.1-0-ga5cab58-rebuilt.opensuse.org 04/01/2014 [ 464.307146] Call Trace: [ 464.307875] dump_stack+0x5b/0x90 [ 464.308631] print_address_description.constprop.0+0x16/0x200 [ 464.309478] ? cifs_reconnect+0x6ab/0x1350 [ 464.310253] ? cifs_reconnect+0x6ab/0x1350 [ 464.311040] __kasan_report.cold+0x1a/0x41 [ 464.311811] ? cifs_reconnect+0x6ab/0x1350 [ 464.312563] kasan_report+0xe/0x20 [ 464.313300] cifs_reconnect+0x6ab/0x1350 [ 464.314062] ? extract_hostname.part.0+0x90/0x90 [ 464.314829] ? printk+0xad/0xde [ 464.315525] ? _raw_spin_lock+0x7c/0xd0 [ 464.316252] ? _raw_read_lock_irq+0x40/0x40 [ 464.316961] ? ___ratelimit+0xed/0x182 [ 464.317655] cifs_readv_from_socket+0x289/0x3b0 [ 464.318386] cifs_read_from_socket+0x98/0xd0 [ 464.319078] ? cifs_readv_from_socket+0x3b0/0x3b0 [ 464.319782] ? try_to_wake_up+0x43c/0xa90 [ 464.320463] ? cifs_small_buf_get+0x4b/0x60 [ 464.321173] ? allocate_buffers+0x98/0x1a0 [ 464.321856] cifs_demultiplex_thread+0x218/0x14a0 [ 464.322558] ? cifs_handle_standard+0x270/0x270 [ 464.323237] ? __switch_to_asm+0x40/0x70 [ 464.323893] ? __switch_to_asm+0x34/0x70 [ 464.324554] ? __switch_to_asm+0x40/0x70 [ 464.325226] ? __switch_to_asm+0x40/0x70 [ 464.325863] ? __switch_to_asm+0x34/0x70 [ 464.326505] ? __switch_to_asm+0x40/0x70 [ 464.327161] ? __switch_to_asm+0x34/0x70 [ 464.327784] ? finish_task_switch+0xa1/0x330 [ 464.328414] ? __switch_to+0x363/0x640 [ 464.329044] ? __schedule+0x575/0xaf0 [ 464.329655] ? _raw_spin_lock_irqsave+0x82/0xe0 [ 464.330301] kthread+0x1a3/0x1f0 [ 464.330884] ? cifs_handle_standard+0x270/0x270 [ 464.331624] ? kthread_create_on_node+0xd0/0xd0 [ 464.332347] ret_from_fork+0x35/0x40 [ 464.333577] Allocated by task 1110: [ 464.334381] save_stack+0x1b/0x80 [ 464.335123] __kasan_kmalloc.constprop.0+0xc2/0xd0 [ 464.335848] cifs_smb3_do_mount+0xd4/0xb00 [ 464.336619] legacy_get_tree+0x6b/0xa0 [ 464.337235] vfs_get_tree+0x41/0x110 [ 464.337975] fc_mount+0xa/0x40 [ 464.338557] vfs_kern_mount.part.0+0x6c/0x80 [ 464.339227] cifs_dfs_d_automount+0x336/0xd29 [ 464.339846] follow_managed+0x1b1/0x450 [ 464.340449] lookup_fast+0x231/0x4a0 [ 464.341039] path_openat+0x240/0x1fd0 [ 464.341634] do_filp_open+0x126/0x1c0 [ 464.342277] do_sys_open+0x1eb/0x2c0 [ 464.342957] do_syscall_64+0x5e/0x190 [ 464.343555] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 464.344772] Freed by task 0: [ 464.345347] save_stack+0x1b/0x80 [ 464.345966] __kasan_slab_free+0x12c/0x170 [ 464.346576] kfree+0xa6/0x270 [ 464.347211] rcu_core+0x39c/0xc80 [ 464.347800] __do_softirq+0x10d/0x3da [ 464.348919] The buggy address belongs to the object at ffff888155e58000 which belongs to the cache kmalloc-256 of size 256 [ 464.350222] The buggy address is located 208 bytes inside of 256-byte region [ffff888155e58000, ffff888155e58100) [ 464.351575] The buggy address belongs to the page: [ 464.352333] page:ffffea0005579600 refcount:1 mapcount:0 mapping:ffff88815a803400 index:0x0 compound_mapcount: 0 [ 464.353583] flags: 0x200000000010200(slab|head) [ 464.354209] raw: 0200000000010200 ffffea0005576200 0000000400000004 ffff88815a803400 [ 464.355353] raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 [ 464.356458] page dumped because: kasan: bad access detected [ 464.367005] Memory state around the buggy address: [ 464.367787] ffff888155e57f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 464.368877] ffff888155e58000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 464.369967] >ffff888155e58080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 464.371111] ^ [ 464.371775] ffff888155e58100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 464.372893] ffff888155e58180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 464.373983] ================================================================== Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin commit afd954170f96d5cd41debc28937b8f72f5afbf06 Author: Nathan Chancellor Date: Mon Nov 18 21:57:10 2019 -0700 powerpc: Don't add -mabi= flags when building with Clang [ Upstream commit 465bfd9c44dea6b55962b5788a23ac87a467c923 ] When building pseries_defconfig, building vdso32 errors out: error: unknown target ABI 'elfv1' This happens because -m32 in clang changes the target to 32-bit, which does not allow the ABI to be changed. Commit 4dc831aa8813 ("powerpc: Fix compiling a BE kernel with a powerpc64le toolchain") added these flags to fix building big endian kernels with a little endian GCC. Clang doesn't need -mabi because the target triple controls the default value. -mlittle-endian and -mbig-endian manipulate the triple into either powerpc64-* or powerpc64le-*, which properly sets the default ABI. Adding a debug print out in the PPC64TargetInfo constructor after line 383 above shows this: $ echo | ./clang -E --target=powerpc64-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 $ echo | ./clang -E --target=powerpc64le-linux -mbig-endian -o /dev/null - Default ABI: elfv1 $ echo | ./clang -E --target=powerpc64le-linux -mlittle-endian -o /dev/null - Default ABI: elfv2 Don't specify -mabi when building with clang to avoid the build error with -m32 and not change any code generation. -mcall-aixdesc is not an implemented flag in clang so it can be safely excluded as well, see commit 238abecde8ad ("powerpc: Don't use gcc specific options on clang"). pseries_defconfig successfully builds after this patch and powernv_defconfig and ppc44x_defconfig don't regress. Reviewed-by: Daniel Axtens Signed-off-by: Nathan Chancellor [mpe: Trim clang links in change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191119045712.39633-2-natechancellor@gmail.com Signed-off-by: Sasha Levin commit 70958af3e2f9f2770eb5653dcf4904ee7d696963 Author: Masahiro Yamada Date: Sun Nov 24 01:04:30 2019 +0900 scripts/kallsyms: fix definitely-lost memory leak [ Upstream commit 21915eca088dc271c970e8351290e83d938114ac ] build_initial_tok_table() overwrites unused sym_entry to shrink the table size. Before the entry is overwritten, table[i].sym must be freed since it is malloc'ed data. This fixes the 'definitely lost' report from valgrind. I ran valgrind against x86_64_defconfig of v5.4-rc8 kernel, and here is the summary: [Before the fix] LEAK SUMMARY: definitely lost: 53,184 bytes in 2,874 blocks [After the fix] LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 7da0d7a575434fb82472a894960152c8c6b30347 Author: Jason Gunthorpe Date: Tue Nov 12 16:22:27 2019 -0400 drm/amdgpu: Call find_vma under mmap_sem [ Upstream commit a9ae8731e6e52829a935d81a65d7f925cb95dbac ] find_vma() must be called under the mmap_sem, reorganize this code to do the vma check after entering the lock. Further, fix the unlocked use of struct task_struct's mm, instead use the mm from hmm_mirror which has an active mm_grab. Also the mm_grab must be converted to a mm_get before acquiring mmap_sem or calling find_vma(). Fixes: 66c45500bfdc ("drm/amdgpu: use new HMM APIs and helpers") Fixes: 0919195f2b0d ("drm/amdgpu: Enable amdgpu_ttm_tt_get_user_pages in worker threads") Link: https://lore.kernel.org/r/20191112202231.3856-11-jgg@ziepe.ca Acked-by: Christian König Reviewed-by: Felix Kuehling Reviewed-by: Philip Yang Tested-by: Philip Yang Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 4f13232aa6370e09616563514ed7ef9d81c69f0e Author: Colin Ian King Date: Thu Jun 27 14:09:04 2019 +0100 apparmor: fix unsigned len comparison with less than zero [ Upstream commit 00e0590dbaec6f1bcaa36a85467d7e3497ced522 ] The sanity check in macro update_for_len checks to see if len is less than zero, however, len is a size_t so it can never be less than zero, so this sanity check is a no-op. Fix this by making len a ssize_t so the comparison will work and add ulen that is a size_t copy of len so that the min() macro won't throw warnings about comparing different types. Addresses-Coverity: ("Macro compares unsigned to 0") Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: Colin Ian King Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit adeec3de92221e6f32935b95e96b7418f14ea457 Author: Michael Kelley Date: Thu Nov 14 06:32:01 2019 +0000 Drivers: hv: vmbus: Fix crash handler reset of Hyper-V synic [ Upstream commit 7a1323b5dfe44a9013a2cc56ef2973034a00bf88 ] The crash handler calls hv_synic_cleanup() to shutdown the Hyper-V synthetic interrupt controller. But if the CPU that calls hv_synic_cleanup() has a VMbus channel interrupt assigned to it (which is likely the case in smaller VM sizes), hv_synic_cleanup() returns an error and the synthetic interrupt controller isn't shutdown. While the lack of being shutdown hasn't caused a known problem, it still should be fixed for highest reliability. So directly call hv_synic_disable_regs() instead of hv_synic_cleanup(), which ensures that the synic is always shutdown. Signed-off-by: Michael Kelley Reviewed-by: Vitaly Kuznetsov Reviewed-by: Dexuan Cui Signed-off-by: Sasha Levin commit f7dad7c353ba94d200e2a3b33895eb4a56fdf628 Author: Srinivas Pandruvada Date: Fri Nov 15 12:35:22 2019 -0800 tools/power/x86/intel-speed-select: Ignore missing config level [ Upstream commit 20183ccd3e4d01d23b0a01fe9f3ee73fbae312fa ] It is possible that certain config levels are not available, even if the max level includes the level. There can be missing levels in some platforms. So ignore the level when called for information dump for all levels and fail if specifically ask for the missing level. Here the changes is to continue reading information about other levels even if we fail to get information for the current level. But use the "processed" flag to indicate the failure. When the "processed" flag is not set, don't dump information about that level. Signed-off-by: Srinivas Pandruvada Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 3a2d6bc5aa9e163b67786310c7b5c8ed669e8f74 Author: Andy Shevchenko Date: Mon Nov 18 20:02:51 2019 +0200 gpio: lynxpoint: Setup correct IRQ handlers [ Upstream commit e272f7ec070d212b9301d5a465bc8952f8dcf908 ] When commit 75e99bf5ed8f ("gpio: lynxpoint: set default handler to be handle_bad_irq()") switched default handler to be handle_bad_irq() the lp_irq_type() function remained untouched. It means that even request_irq() can't change the handler and we are not able to handle IRQs properly anymore. Fix it by setting correct handlers in the lp_irq_type() callback. Fixes: 75e99bf5ed8f ("gpio: lynxpoint: set default handler to be handle_bad_irq()") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20191118180251.31439-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 00ae1761fab3b3fdeb703e5aa85aca0bbeda8e5c Author: Vladimir Oltean Date: Fri Nov 15 14:55:51 2019 +0200 gpio: mpc8xxx: Don't overwrite default irq_set_type callback [ Upstream commit 4e50573f39229d5e9c985fa3b4923a8b29619ade ] The per-SoC devtype structures can contain their own callbacks that overwrite mpc8xxx_gpio_devtype_default. The clear intention is that mpc8xxx_irq_set_type is used in case the SoC does not specify a more specific callback. But what happens is that if the SoC doesn't specify one, its .irq_set_type is de-facto NULL, and this overwrites mpc8xxx_irq_set_type to a no-op. This means that the following SoCs are affected: - fsl,mpc8572-gpio - fsl,ls1028a-gpio - fsl,ls1088a-gpio On these boards, the irq_set_type does exactly nothing, and the GPIO controller keeps its GPICR register in the hardware-default state. On the LS1028A, that is ACTIVE_BOTH, which means 2 interrupts are raised even if the IRQ client requests LEVEL_HIGH. Another implication is that the IRQs are not checked (e.g. level-triggered interrupts are not rejected, although they are not supported). Fixes: 82e39b0d8566 ("gpio: mpc8xxx: handle differences between incarnations at a single place") Signed-off-by: Vladimir Oltean Link: https://lore.kernel.org/r/20191115125551.31061-1-olteanv@gmail.com Tested-by: Michael Walle Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b22d3a4b7b55d64c3983bd62f468345e37a5f9fe Author: Gayatri Kammela Date: Mon Nov 18 11:05:41 2019 -0800 platform/x86: intel_pmc_core: Add Comet Lake (CML) platform support to intel_pmc_core driver [ Upstream commit 5406327d43edd9a171bd260f49c752d148727eaf ] Add Comet Lake to the list of the platforms that intel_pmc_core driver supports for pmc_core device. Just like Ice Lake, Comet Lake can also reuse all the Cannon Lake PCH IPs. No additional effort is needed to enable but to simply reuse them. Cc: Mario Limonciello Cc: Peter Zijlstra Cc: Srinivas Pandruvada Cc: Andy Shevchenko Cc: Kan Liang Cc: David E. Box Cc: Rajneesh Bhardwaj Cc: Tony Luck Signed-off-by: Gayatri Kammela Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit b889648cb7eb62d14a5d8cf03da60a403d509aac Author: Gayatri Kammela Date: Mon Nov 18 11:05:40 2019 -0800 platform/x86: intel_pmc_core: Fix the SoC naming inconsistency [ Upstream commit 43e82d8aa92503d264309fb648b251b2d85caf1a ] Intel's SoCs follow a naming convention which spells out the SoC name as two words instead of one word (E.g: Cannon Lake vs Cannonlake). Thus fix the naming inconsistency across the intel_pmc_core driver, so future SoCs can follow the naming consistency as below. Cometlake -> Comet Lake Tigerlake -> Tiger Lake Elkhartlake -> Elkhart Lake Cc: Mario Limonciello Cc: Peter Zijlstra Cc: Srinivas Pandruvada Cc: Andy Shevchenko Cc: Kan Liang Cc: David E. Box Cc: Rajneesh Bhardwaj Cc: Tony Luck Suggested-by: Andy Shevchenko Signed-off-by: Gayatri Kammela Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 3fd185ba5688fbb5191213ab849f03940f3012c6 Author: Russell King Date: Tue Nov 19 13:10:38 2019 +0000 gpio/mpc8xxx: fix qoriq GPIO reading [ Upstream commit 787b64a43f7acacf8099329ea08872e663f1e74f ] Qoriq requires the IBE register to be set to enable GPIO inputs to be read. Set it. Signed-off-by: Russell King Link: https://lore.kernel.org/r/E1iX3HC-00069N-0T@rmk-PC.armlinux.org.uk Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 02270fc85b51a514b55ae6f6b3050de34e159e34 Author: Omer Shpigelman Date: Thu Nov 14 18:23:57 2019 +0000 habanalabs: skip VA block list update in reset flow [ Upstream commit 71c5e55e7c077fa17c42fbda91a8d14322825c44 ] Reduce context close time by skipping the VA block free list update in order to avoid hard reset with open contexts. Reset with open contexts can potentially lead to a kernel crash as the generic pool of the MMU hops is destroyed while it is not empty because some unmap operations are not done. The commit affect mainly when running on simulator. Signed-off-by: Omer Shpigelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit ce7269497052f463cb3c74f1388d352c37d24b80 Author: Sahitya Tummala Date: Wed Nov 13 16:01:03 2019 +0530 f2fs: Fix deadlock in f2fs_gc() context during atomic files handling [ Upstream commit 677017d196ba2a4cfff13626b951cc9a206b8c7c ] The FS got stuck in the below stack when the storage is almost full/dirty condition (when FG_GC is being done). schedule_timeout io_schedule_timeout congestion_wait f2fs_drop_inmem_pages_all f2fs_gc f2fs_balance_fs __write_node_page f2fs_fsync_node_pages f2fs_do_sync_file f2fs_ioctl The root cause for this issue is there is a potential infinite loop in f2fs_drop_inmem_pages_all() for the case where gc_failure is true and when there an inode whose i_gc_failures[GC_FAILURE_ATOMIC] is not set. Fix this by keeping track of the total atomic files currently opened and using that to exit from this condition. Fix-suggested-by: Chao Yu Signed-off-by: Chao Yu Signed-off-by: Sahitya Tummala Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit ddf426dbe3162d61d35497dc5ac8034778009481 Author: Bart Van Assche Date: Wed Nov 13 14:05:08 2019 -0800 scsi: target: iscsi: Wait for all commands to finish before freeing a session [ Upstream commit e9d3009cb936bd0faf0719f68d98ad8afb1e613b ] The iSCSI target driver is the only target driver that does not wait for ongoing commands to finish before freeing a session. Make the iSCSI target driver wait for ongoing commands to finish before freeing a session. This patch fixes the following KASAN complaint: BUG: KASAN: use-after-free in __lock_acquire+0xb1a/0x2710 Read of size 8 at addr ffff8881154eca70 by task kworker/0:2/247 CPU: 0 PID: 247 Comm: kworker/0:2 Not tainted 5.4.0-rc1-dbg+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 Workqueue: target_completion target_complete_ok_work [target_core_mod] Call Trace: dump_stack+0x8a/0xd6 print_address_description.constprop.0+0x40/0x60 __kasan_report.cold+0x1b/0x33 kasan_report+0x16/0x20 __asan_load8+0x58/0x90 __lock_acquire+0xb1a/0x2710 lock_acquire+0xd3/0x200 _raw_spin_lock_irqsave+0x43/0x60 target_release_cmd_kref+0x162/0x7f0 [target_core_mod] target_put_sess_cmd+0x2e/0x40 [target_core_mod] lio_check_stop_free+0x12/0x20 [iscsi_target_mod] transport_cmd_check_stop_to_fabric+0xd8/0xe0 [target_core_mod] target_complete_ok_work+0x1b0/0x790 [target_core_mod] process_one_work+0x549/0xa40 worker_thread+0x7a/0x5d0 kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Allocated by task 889: save_stack+0x23/0x90 __kasan_kmalloc.constprop.0+0xcf/0xe0 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xf6/0x360 transport_alloc_session+0x29/0x80 [target_core_mod] iscsi_target_login_thread+0xcd6/0x18f0 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Freed by task 1025: save_stack+0x23/0x90 __kasan_slab_free+0x13a/0x190 kasan_slab_free+0x12/0x20 kmem_cache_free+0x146/0x400 transport_free_session+0x179/0x2f0 [target_core_mod] transport_deregister_session+0x130/0x180 [target_core_mod] iscsit_close_session+0x12c/0x350 [iscsi_target_mod] iscsit_logout_post_handler+0x136/0x380 [iscsi_target_mod] iscsit_response_queue+0x8de/0xbe0 [iscsi_target_mod] iscsi_target_tx_thread+0x27f/0x370 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 The buggy address belongs to the object at ffff8881154ec9c0 which belongs to the cache se_sess_cache of size 352 The buggy address is located 176 bytes inside of 352-byte region [ffff8881154ec9c0, ffff8881154ecb20) The buggy address belongs to the page: page:ffffea0004553b00 refcount:1 mapcount:0 mapping:ffff888101755400 index:0x0 compound_mapcount: 0 flags: 0x2fff000000010200(slab|head) raw: 2fff000000010200 dead000000000100 dead000000000122 ffff888101755400 raw: 0000000000000000 0000000080130013 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881154ec900: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8881154ec980: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb >ffff8881154eca00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881154eca80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881154ecb00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc Cc: Mike Christie Link: https://lore.kernel.org/r/20191113220508.198257-3-bvanassche@acm.org Reviewed-by: Roman Bolshakov Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 692b104e36fe1623786760740afb984d19de016d Author: Anatol Pomazau Date: Fri Nov 15 19:47:35 2019 -0500 scsi: iscsi: Don't send data to unbound connection [ Upstream commit 238191d65d7217982d69e21c1d623616da34b281 ] If a faulty initiator fails to bind the socket to the iSCSI connection before emitting a command, for instance, a subsequent send_pdu, it will crash the kernel due to a null pointer dereference in sock_sendmsg(), as shown in the log below. This patch makes sure the bind succeeded before trying to use the socket. BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 3 PID: 7 Comm: kworker/u8:0 Not tainted 5.4.0-rc2.iscsi+ #13 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 24.158246] Workqueue: iscsi_q_0 iscsi_xmitworker [ 24.158883] RIP: 0010:apparmor_socket_sendmsg+0x5/0x20 [...] [ 24.161739] RSP: 0018:ffffab6440043ca0 EFLAGS: 00010282 [ 24.162400] RAX: ffffffff891c1c00 RBX: ffffffff89d53968 RCX: 0000000000000001 [ 24.163253] RDX: 0000000000000030 RSI: ffffab6440043d00 RDI: 0000000000000000 [ 24.164104] RBP: 0000000000000030 R08: 0000000000000030 R09: 0000000000000030 [ 24.165166] R10: ffffffff893e66a0 R11: 0000000000000018 R12: ffffab6440043d00 [ 24.166038] R13: 0000000000000000 R14: 0000000000000000 R15: ffff9d5575a62e90 [ 24.166919] FS: 0000000000000000(0000) GS:ffff9d557db80000(0000) knlGS:0000000000000000 [ 24.167890] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 24.168587] CR2: 0000000000000018 CR3: 000000007a838000 CR4: 00000000000006e0 [ 24.169451] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 24.170320] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 24.171214] Call Trace: [ 24.171537] security_socket_sendmsg+0x3a/0x50 [ 24.172079] sock_sendmsg+0x16/0x60 [ 24.172506] iscsi_sw_tcp_xmit_segment+0x77/0x120 [ 24.173076] iscsi_sw_tcp_pdu_xmit+0x58/0x170 [ 24.173604] ? iscsi_dbg_trace+0x63/0x80 [ 24.174087] iscsi_tcp_task_xmit+0x101/0x280 [ 24.174666] iscsi_xmit_task+0x83/0x110 [ 24.175206] iscsi_xmitworker+0x57/0x380 [ 24.175757] ? __schedule+0x2a2/0x700 [ 24.176273] process_one_work+0x1b5/0x360 [ 24.176837] worker_thread+0x50/0x3c0 [ 24.177353] kthread+0xf9/0x130 [ 24.177799] ? process_one_work+0x360/0x360 [ 24.178401] ? kthread_park+0x90/0x90 [ 24.178915] ret_from_fork+0x35/0x40 [ 24.179421] Modules linked in: [ 24.179856] CR2: 0000000000000018 [ 24.180327] ---[ end trace b4b7674b6df5f480 ]--- Signed-off-by: Anatol Pomazau Co-developed-by: Frank Mayhar Signed-off-by: Frank Mayhar Co-developed-by: Bharath Ravi Signed-off-by: Bharath Ravi Co-developed-by: Khazhimsel Kumykov Signed-off-by: Khazhimsel Kumykov Co-developed-by: Gabriel Krisman Bertazi Signed-off-by: Gabriel Krisman Bertazi Reviewed-by: Lee Duncan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit affadd78b17a6c7e79d921b71cf4d77b4b32a24a Author: Can Guo Date: Thu Nov 14 22:09:26 2019 -0800 scsi: ufs: Fix up auto hibern8 enablement [ Upstream commit 71d848b8d97ec0f8e993d63cf9de6ac8b3f7c43d ] Fix up possible unclocked register access to auto hibern8 register in resume path and through sysfs entry. Meanwhile, enable auto hibern8 only after device is fully initialized in probe path. Link: https://lore.kernel.org/r/1573798172-20534-4-git-send-email-cang@codeaurora.org Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c2852d1dc224255db42a3d358730537d81635131 Author: Bart Van Assche Date: Wed Nov 13 14:05:07 2019 -0800 scsi: target: core: Release SPC-2 reservations when closing a session [ Upstream commit 80647a89eaf3f2549741648f3230cd6ff68c23b4 ] The SCSI specs require releasing SPC-2 reservations when a session is closed. Make sure that the target core does this. Running the libiscsi tests triggers the KASAN complaint shown below. This patch fixes that use-after-free. BUG: KASAN: use-after-free in target_check_reservation+0x171/0x980 [target_core_mod] Read of size 8 at addr ffff88802ecd1878 by task iscsi_trx/17200 CPU: 0 PID: 17200 Comm: iscsi_trx Not tainted 5.4.0-rc1-dbg+ #1 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x8a/0xd6 print_address_description.constprop.0+0x40/0x60 __kasan_report.cold+0x1b/0x34 kasan_report+0x16/0x20 __asan_load8+0x58/0x90 target_check_reservation+0x171/0x980 [target_core_mod] __target_execute_cmd+0xb1/0xf0 [target_core_mod] target_execute_cmd+0x22d/0x4d0 [target_core_mod] transport_generic_new_cmd+0x31f/0x5b0 [target_core_mod] transport_handle_cdb_direct+0x6f/0x90 [target_core_mod] iscsit_execute_cmd+0x381/0x3f0 [iscsi_target_mod] iscsit_sequence_cmd+0x13b/0x1f0 [iscsi_target_mod] iscsit_process_scsi_cmd+0x4c/0x130 [iscsi_target_mod] iscsit_get_rx_pdu+0x8e8/0x15f0 [iscsi_target_mod] iscsi_target_rx_thread+0x105/0x1b0 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Allocated by task 1079: save_stack+0x23/0x90 __kasan_kmalloc.constprop.0+0xcf/0xe0 kasan_slab_alloc+0x12/0x20 kmem_cache_alloc+0xfe/0x3a0 transport_alloc_session+0x29/0x80 [target_core_mod] iscsi_target_login_thread+0xceb/0x1920 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 Freed by task 17193: save_stack+0x23/0x90 __kasan_slab_free+0x13a/0x190 kasan_slab_free+0x12/0x20 kmem_cache_free+0xc8/0x3e0 transport_free_session+0x179/0x2f0 [target_core_mod] transport_deregister_session+0x121/0x170 [target_core_mod] iscsit_close_session+0x12c/0x350 [iscsi_target_mod] iscsit_logout_post_handler+0x136/0x380 [iscsi_target_mod] iscsit_response_queue+0x8fa/0xc00 [iscsi_target_mod] iscsi_target_tx_thread+0x28e/0x390 [iscsi_target_mod] kthread+0x1bc/0x210 ret_from_fork+0x24/0x30 The buggy address belongs to the object at ffff88802ecd1860 which belongs to the cache se_sess_cache of size 352 The buggy address is located 24 bytes inside of 352-byte region [ffff88802ecd1860, ffff88802ecd19c0) The buggy address belongs to the page: page:ffffea0000bb3400 refcount:1 mapcount:0 mapping:ffff8880bef2ed00 index:0x0 compound_mapcount: 0 flags: 0x1000000000010200(slab|head) raw: 1000000000010200 dead000000000100 dead000000000122 ffff8880bef2ed00 raw: 0000000000000000 0000000080270027 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88802ecd1700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88802ecd1780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88802ecd1800: fb fb fb fb fc fc fc fc fc fc fc fc fb fb fb fb ^ ffff88802ecd1880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88802ecd1900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Cc: Mike Christie Link: https://lore.kernel.org/r/20191113220508.198257-2-bvanassche@acm.org Reviewed-by: Roman Bolshakov Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 026401a5942a99e7aaa3f94c3ef4d204138b9fb9 Author: Finn Thain Date: Sat Nov 16 14:36:57 2019 +1100 scsi: NCR5380: Add disconnect_mask module parameter [ Upstream commit 0b7a223552d455bcfba6fb9cfc5eef2b5fce1491 ] Add a module parameter to inhibit disconnect/reselect for individual targets. This gains compatibility with Aztec PowerMonster SCSI/SATA adapters with buggy firmware. (No fix is available from the vendor.) Apparently these adapters pass-through the product/vendor of the attached SATA device. Since they can't be identified from the response to an INQUIRY command, a device blacklist flag won't work. Cc: Michael Schmitz Link: https://lore.kernel.org/r/993b17545990f31f9fa5a98202b51102a68e7594.1573875417.git.fthain@telegraphics.com.au Reviewed-and-tested-by: Michael Schmitz Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9d411fa766a87315ceecd2a098531e0e322835a1 Author: Maurizio Lombardi Date: Fri Nov 15 17:37:27 2019 +0100 scsi: scsi_debug: num_tgts must be >= 0 [ Upstream commit aa5334c4f3014940f11bf876e919c956abef4089 ] Passing the parameter "num_tgts=-1" will start an infinite loop that exhausts the system memory Link: https://lore.kernel.org/r/20191115163727.24626-1-mlombard@redhat.com Signed-off-by: Maurizio Lombardi Acked-by: Douglas Gilbert Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 17e6ff3d46add0e8618d0791dbd2adddc8b09b65 Author: Subhash Jadavani Date: Thu Nov 14 22:09:30 2019 -0800 scsi: ufs: Fix error handing during hibern8 enter [ Upstream commit 6d303e4b19d694cdbebf76bcdb51ada664ee953d ] During clock gating (ufshcd_gate_work()), we first put the link hibern8 by calling ufshcd_uic_hibern8_enter() and if ufshcd_uic_hibern8_enter() returns success (0) then we gate all the clocks. Now let’s zoom in to what ufshcd_uic_hibern8_enter() does internally: It calls __ufshcd_uic_hibern8_enter() and if failure is encountered, link recovery shall put the link back to the highest HS gear and returns success (0) to ufshcd_uic_hibern8_enter() which is the issue as link is still in active state due to recovery! Now ufshcd_uic_hibern8_enter() returns success to ufshcd_gate_work() and hence it goes ahead with gating the UFS clock while link is still in active state hence I believe controller would raise UIC error interrupts. But when we service the interrupt, clocks might have already been disabled! This change fixes for this by returning failure from __ufshcd_uic_hibern8_enter() if recovery succeeds as link is still not in hibern8, upon receiving the error ufshcd_hibern8_enter() would initiate retry to put the link state back into hibern8. Link: https://lore.kernel.org/r/1573798172-20534-8-git-send-email-cang@codeaurora.org Reviewed-by: Avri Altman Reviewed-by: Bean Huo Signed-off-by: Subhash Jadavani Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ed1e1d67313ac9e8bf36974410524f553d91549d Author: peter chang Date: Thu Nov 14 15:38:58 2019 +0530 scsi: pm80xx: Fix for SATA device discovery [ Upstream commit ce21c63ee995b7a8b7b81245f2cee521f8c3c220 ] Driver was missing complete() call in mpi_sata_completion which result in SATA abort error handling timing out. That causes the device to be left in the in_recovery state so subsequent commands sent to the device fail and the OS removes access to it. Link: https://lore.kernel.org/r/20191114100910.6153-2-deepak.ukey@microchip.com Acked-by: Jack Wang Signed-off-by: peter chang Signed-off-by: Deepak Ukey Signed-off-by: Viswas G Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a4ef8f2e3cc6b833539ca07160140f5df87875a2 Author: Christophe Leroy Date: Thu Sep 12 13:49:42 2019 +0000 powerpc/fixmap: Use __fix_to_virt() instead of fix_to_virt() [ Upstream commit 77693a5fb57be4606a6024ec8e3076f9499b906b ] Modify back __set_fixmap() to using __fix_to_virt() instead of fix_to_virt() otherwise the following happens because it seems GCC doesn't see idx as a builtin const. CC mm/early_ioremap.o In file included from ./include/linux/kernel.h:11:0, from mm/early_ioremap.c:11: In function ‘fix_to_virt’, inlined from ‘__set_fixmap’ at ./arch/powerpc/include/asm/fixmap.h:87:2, inlined from ‘__early_ioremap’ at mm/early_ioremap.c:156:4: ./include/linux/compiler.h:350:38: error: call to ‘__compiletime_assert_32’ declared with attribute error: BUILD_BUG_ON failed: idx >= __end_of_fixed_addresses _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ ./include/linux/compiler.h:331:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^ ./include/linux/compiler.h:350:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ ./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^ ./include/asm-generic/fixmap.h:32:2: note: in expansion of macro ‘BUILD_BUG_ON’ BUILD_BUG_ON(idx >= __end_of_fixed_addresses); ^ Signed-off-by: Christophe Leroy Fixes: 4cfac2f9c7f1 ("powerpc/mm: Simplify __set_fixmap()") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/f4984c615f90caa3277775a68849afeea846850d.1568295907.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin commit ca7851d46de8a8d69022c4e5feed0820483b5f46 Author: Kevin Hao Date: Tue Oct 8 19:29:34 2019 +0800 watchdog: Fix the race between the release of watchdog_core_data and cdev [ Upstream commit 72139dfa2464e43957d330266994740bb7be2535 ] The struct cdev is embedded in the struct watchdog_core_data. In the current code, we manage the watchdog_core_data with a kref, but the cdev is manged by a kobject. There is no any relationship between this kref and kobject. So it is possible that the watchdog_core_data 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: 23 PID: 1028 at lib/debugobjects.c:481 debug_print_object+0xb0/0xf0 Modules linked in: softdog(-) deflate ctr twofish_generic twofish_common camellia_generic serpent_generic blowfish_generic blowfish_common cast5_generic cast_common cmac xcbc af_key sch_fq_codel openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 CPU: 23 PID: 1028 Comm: modprobe Not tainted 5.3.0-next-20190924-yoctodev-standard+ #180 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 00400009 (nzcv daif +PAN -UAO) pc : debug_print_object+0xb0/0xf0 lr : debug_print_object+0xb0/0xf0 sp : ffff80001cbcfc70 x29: ffff80001cbcfc70 x28: ffff800010ea2128 x27: ffff800010bad000 x26: 0000000000000000 x25: ffff80001103c640 x24: ffff80001107b268 x23: ffff800010bad9e8 x22: ffff800010ea2128 x21: ffff000bc2c62af8 x20: ffff80001103c600 x19: ffff800010e867d8 x18: 0000000000000060 x17: 0000000000000000 x16: 0000000000000000 x15: ffff000bd7240470 x14: 6e6968207473696c x13: 5f72656d6974203a x12: 6570797420746365 x11: 6a626f2029302065 x10: 7461747320657669 x9 : 7463612820657669 x8 : 3378302f3078302b x7 : 0000000000001d7a x6 : ffff800010fd5889 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff000bff948548 x1 : 276a1c9e1edc2300 x0 : 0000000000000000 Call trace: debug_print_object+0xb0/0xf0 debug_check_no_obj_freed+0x1e8/0x210 kfree+0x1b8/0x368 watchdog_cdev_unregister+0x88/0xc8 watchdog_dev_unregister+0x38/0x48 watchdog_unregister_device+0xa8/0x100 softdog_exit+0x18/0xfec4 [softdog] __arm64_sys_delete_module+0x174/0x200 el0_svc_handler+0xd0/0x1c8 el0_svc+0x8/0xc 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 watchdog_core_data, and use the API provided by the commit 233ed09d7fda to make sure that the release of watchdog_core_data and cdev are in sequence. Signed-off-by: Kevin Hao Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20191008112934.29669-1-haokexin@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit ce4d6fff7a962727c29a5d34e26945ac0df133ff Author: Julia Cartwright Date: Tue Nov 5 15:45:06 2019 +0100 watchdog: prevent deferral of watchdogd wakeup on RT [ Upstream commit a19f89335f4bda3d77d991c96583e3e51856acbb ] When PREEMPT_RT is enabled, all hrtimer expiry functions are deferred for execution into the context of ksoftirqd unless otherwise annotated. Deferring the expiry of the hrtimer used by the watchdog core, however, is a waste, as the callback does nothing but queue a kthread work item and wakeup watchdogd. It's worst then that, too: the deferral through ksoftirqd also means that for correct behavior a user must adjust the scheduling parameters of both watchdogd _and_ ksoftirqd, which is unnecessary and has other side effects (like causing unrelated expiry functions to execute at potentially elevated priority). Instead, mark the hrtimer used by the watchdog core as being _HARD to allow it's execution directly from hardirq context. The work done in this expiry function is well-bounded and minimal. A user still must adjust the scheduling parameters of the watchdogd to be correct w.r.t. their application needs. Link: https://lkml.kernel.org/r/0e02d8327aeca344096c246713033887bc490dd7.1538089180.git.julia@ni.com Cc: Guenter Roeck Reported-and-tested-by: Steffen Trumtrar Reported-by: Tim Sander Signed-off-by: Julia Cartwright Acked-by: Guenter Roeck [bigeasy: use only HRTIMER_MODE_REL_HARD] Signed-off-by: Sebastian Andrzej Siewior Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20191105144506.clyadjbvnn7b7b2m@linutronix.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 2c0dcde4844407845bb29bcc7b02561c3b1230b4 Author: Fabio Estevam Date: Tue Oct 29 14:40:33 2019 -0300 watchdog: imx7ulp: Fix reboot hang [ Upstream commit 6083ab7b2f3f25022e2e8f4c42f14a8521f47873 ] The following hang is observed when a 'reboot' command is issued: # reboot # Stopping network: OK Stopping klogd: OK Stopping syslogd: OK umount: devtmpfs busy - remounted read-only [ 8.612079] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null) The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 10.694753] reboot: Restarting system [ 11.699008] Reboot failed -- System halted Fix this problem by adding a .restart ops member. Fixes: 41b630f41bf7 ("watchdog: Add i.MX7ULP watchdog support") Signed-off-by: Fabio Estevam Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/20191029174037.25381-1-festevam@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit 7f1d82ac0c72a1bc913252ec2e5848f473c6763b Author: Andrew Duggan Date: Wed Oct 23 01:24:03 2019 +0000 HID: rmi: Check that the RMI_STARTED bit is set before unregistering the RMI transport device [ Upstream commit 8725aa4fa7ded30211ebd28bb1c9bae806eb3841 ] In the event that the RMI device is unreachable, the calls to rmi_set_mode() or rmi_set_page() will fail before registering the RMI transport device. When the device is removed, rmi_remove() will call rmi_unregister_transport_device() which will attempt to access the rmi_dev pointer which was not set. This patch adds a check of the RMI_STARTED bit before calling rmi_unregister_transport_device(). The RMI_STARTED bit is only set after rmi_register_transport_device() completes successfully. The kernel oops was reported in this message: https://www.spinics.net/lists/linux-input/msg58433.html [jkosina@suse.cz: reworded changelog as agreed with Andrew] Signed-off-by: Andrew Duggan Reported-by: Federico Cerutti Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 65889bba7be12410fdc346420e4e49e693d92de1 Author: Blaž Hrastnik Date: Wed Nov 6 20:02:46 2019 +0900 HID: Improve Windows Precision Touchpad detection. [ Upstream commit 2dbc6f113acd74c66b04bf49fb027efd830b1c5a ] Per Microsoft spec, usage 0xC5 (page 0xFF) returns a blob containing data used to verify the touchpad as a Windows Precision Touchpad. 0x85, REPORTID_PTPHQA, // REPORT_ID (PTPHQA) 0x09, 0xC5, // USAGE (Vendor Usage 0xC5) 0x15, 0x00, // LOGICAL_MINIMUM (0) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (0xff) 0x75, 0x08, // REPORT_SIZE (8) 0x96, 0x00, 0x01, // REPORT_COUNT (0x100 (256)) 0xb1, 0x02, // FEATURE (Data,Var,Abs) However, some devices, namely Microsoft's Surface line of products instead implement a "segmented device certification report" (usage 0xC6) which returns the same report, but in smaller chunks. 0x06, 0x00, 0xff, // USAGE_PAGE (Vendor Defined) 0x85, REPORTID_PTPHQA, // REPORT_ID (PTPHQA) 0x09, 0xC6, // USAGE (Vendor usage for segment #) 0x25, 0x08, // LOGICAL_MAXIMUM (8) 0x75, 0x08, // REPORT_SIZE (8) 0x95, 0x01, // REPORT_COUNT (1) 0xb1, 0x02, // FEATURE (Data,Var,Abs) 0x09, 0xC7, // USAGE (Vendor Usage) 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (0xff) 0x95, 0x20, // REPORT_COUNT (32) 0xb1, 0x02, // FEATURE (Data,Var,Abs) By expanding Win8 touchpad detection to also look for the segmented report, all Surface touchpads are now properly recognized by hid-multitouch. Signed-off-by: Blaž Hrastnik Signed-off-by: Benjamin Tissoires Signed-off-by: Sasha Levin commit 689b2c656f3f6a05c09fd9b6dd8d459de6d9fbd6 Author: Qian Cai Date: Thu Oct 31 10:05:19 2019 -0400 libnvdimm/btt: fix variable 'rc' set but not used [ Upstream commit 4e24e37d5313edca8b4ab86f240c046c731e28d6 ] drivers/nvdimm/btt.c: In function 'btt_read_pg': drivers/nvdimm/btt.c:1264:8: warning: variable 'rc' set but not used [-Wunused-but-set-variable] int rc; ^~ Add a ratelimited message in case a storm of errors is encountered. Fixes: d9b83c756953 ("libnvdimm, btt: rework error clearing") Signed-off-by: Qian Cai Reviewed-by: Vishal Verma Link: https://lore.kernel.org/r/1572530719-32161-1-git-send-email-cai@lca.pw Signed-off-by: Dan Williams Signed-off-by: Sasha Levin commit 87d9d4cdb1975efb5852f25eb63498549bc57a32 Author: Doug Berger Date: Mon Nov 11 04:32:04 2019 +0100 ARM: 8937/1: spectre-v2: remove Brahma-B53 from hardening [ Upstream commit 4ae5061a19b550dfe25397843427ed2ebab16b16 ] When the default processor handling was added to the function cpu_v7_spectre_init() it only excluded other ARM implemented processor cores. The Broadcom Brahma B53 core is not implemented by ARM so it ended up falling through into the set of processors that attempt to use the ARM_SMCCC_ARCH_WORKAROUND_1 service to harden the branch predictor. Since this workaround is not necessary for the Brahma-B53 this commit explicitly checks for it and prevents it from applying a branch predictor hardening workaround. Fixes: 10115105cb3a ("ARM: spectre-v2: add firmware based hardening") Signed-off-by: Doug Berger Signed-off-by: Florian Fainelli Signed-off-by: Russell King Signed-off-by: Sasha Levin commit 0822e4dc6a38a2d1ce972a7b5c66c98ac2bb7713 Author: Aaron Ma Date: Thu Nov 14 03:12:47 2019 +0800 HID: i2c-hid: fix no irq after reset on raydium 3118 [ Upstream commit 0c8432236dea20a95f68fa17989ea3f8af0186a5 ] On some ThinkPad L390 some raydium 3118 touchscreen devices doesn't response any data after reset, but some does. Add this ID to no irq quirk, then don't wait for any response alike on these touchscreens. All kinds of raydium 3118 devices work fine. BugLink: https://bugs.launchpad.net/bugs/1849721 Signed-off-by: Aaron Ma Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2d608857e1e09990bb1a71f90a73af712df42f96 Author: Hans de Goede Date: Thu Nov 14 15:30:46 2019 +0100 HID: logitech-hidpp: Silence intermittent get_battery_capacity errors [ Upstream commit 61005d65b6c7dcf61c19516e6ebe5acc02d2cdda ] My Logitech M185 (PID:4038) 2.4 GHz wireless HID++ mouse is causing intermittent errors like these in the log: [11091.034857] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 [12388.031260] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 [16613.718543] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 [23529.938728] logitech-hidpp-device 0003:046D:4038.0006: hidpp20_batterylevel_get_battery_capacity: received protocol error 0x09 We are already silencing error-code 0x09 (HIDPP_ERROR_RESOURCE_ERROR) errors in other places, lets do the same in hidpp20_batterylevel_get_battery_capacity to remove these harmless, but scary looking errors from the dmesg output. Signed-off-by: Hans de Goede Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit c3f76584cafe0e7d26923db3277f3f506841da7a Author: Rob Herring Date: Wed Nov 13 09:46:19 2019 -0600 dt-bindings: Improve validation build error handling [ Upstream commit 93512dad334deb444619505f1fbb761156f7471b ] Schema errors can cause make to exit before useful information is printed. This leaves developers wondering what's wrong. It can be overcome passing '-k' to make, but that's not an obvious solution. There's 2 scenarios where this happens. When using DT_SCHEMA_FILES to validate with a single schema, any error in the schema results in processed-schema.yaml being empty causing a make error. The result is the specific errors in the schema are never shown because processed-schema.yaml is the first target built. Simply making processed-schema.yaml last in extra-y ensures the full schema validation with detailed error messages happen first. The 2nd problem is while schema errors are ignored for processed-schema.yaml, full validation of the schema still runs in parallel and any schema validation errors will still stop the build when running validation of dts files. The fix is to not add the schema examples to extra-y in this case. This means 'dtbs_check' is no longer a superset of 'dt_binding_check'. Update the documentation to make this clear. Cc: Masahiro Yamada Tested-by: Jeffrey Hugo Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 9ed04c8d92c6db874b62d87592389042d06d96d8 Author: Jinke Fan Date: Wed Nov 13 11:38:41 2019 +0800 HID: quirks: Add quirk for HP MSU1465 PIXART OEM mouse [ Upstream commit f1a0094cbbe97a5f8aca7bdc64bfe43ac9dc6879 ] The PixArt OEM mouse disconnets/reconnects every minute on Linux. All contents of dmesg are repetitive: [ 1465.810014] usb 1-2.2: USB disconnect, device number 20 [ 1467.431509] usb 1-2.2: new low-speed USB device number 21 using xhci_hcd [ 1467.654982] usb 1-2.2: New USB device found, idVendor=03f0,idProduct=1f4a, bcdDevice= 1.00 [ 1467.654985] usb 1-2.2: New USB device strings: Mfr=1, Product=2,SerialNumber=0 [ 1467.654987] usb 1-2.2: Product: HP USB Optical Mouse [ 1467.654988] usb 1-2.2: Manufacturer: PixArt [ 1467.699722] input: PixArt HP USB Optical Mouse as /devices/pci0000:00/0000:00:07.1/0000:05:00.3/usb1/1-2/1-2.2/1-2.2:1.0/0003:03F0:1F4A.0012/input/input19 [ 1467.700124] hid-generic 0003:03F0:1F4A.0012: input,hidraw0: USB HID v1.11 Mouse [PixArt HP USB Optical Mouse] on usb-0000:05:00.3-2.2/input0 So add HID_QUIRK_ALWAYS_POLL for this one as well. Test the patch, the mouse is no longer disconnected and there are no duplicate logs in dmesg. Reference: https://github.com/sriemer/fix-linux-mouse Signed-off-by: Jinke Fan Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 91204059738e532c4e73e4d43bf10cd66029bf93 Author: Coly Li Date: Wed Nov 13 16:03:24 2019 +0800 bcache: at least try to shrink 1 node in bch_mca_scan() [ Upstream commit 9fcc34b1a6dd4b8e5337e2b6ef45e428897eca6b ] In bch_mca_scan(), the number of shrinking btree node is calculated by code like this, unsigned long nr = sc->nr_to_scan; nr /= c->btree_pages; nr = min_t(unsigned long, nr, mca_can_free(c)); variable sc->nr_to_scan is number of objects (here is bcache B+tree nodes' number) to shrink, and pointer variable sc is sent from memory management code as parametr of a callback. If sc->nr_to_scan is smaller than c->btree_pages, after the above calculation, variable 'nr' will be 0 and nothing will be shrunk. It is frequeently observed that only 1 or 2 is set to sc->nr_to_scan and make nr to be zero. Then bch_mca_scan() will do nothing more then acquiring and releasing mutex c->bucket_lock. This patch checkes whether nr is 0 after the above calculation, if 0 is the result then set 1 to variable 'n'. Then at least bch_mca_scan() will try to shrink a single B+tree node. Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 7b77d61dbdb41f1dfdf0b76c8f10fb5955c6d318 Author: Robert Jarzmik Date: Sat Oct 26 21:44:20 2019 +0200 clk: pxa: fix one of the pxa RTC clocks [ Upstream commit 46acbcb4849b2ca2e6e975e7c8130c1d61c8fd0c ] The pxa27x platforms have a single IP with 2 drivers, sa1100-rtc and rtc-pxa drivers. A previous patch fixed the sa1100-rtc case, but the pxa-rtc wasn't fixed. This patch completes the previous one. Fixes: 8b6d10345e16 ("clk: pxa: add missing pxa27x clocks for Irda and sa1100-rtc") Signed-off-by: Robert Jarzmik Link: https://lkml.kernel.org/r/20191026194420.11918-1-robert.jarzmik@free.fr Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit f2ead371071acc3ac8fa2154a4039bf8d42182e3 Author: Finn Thain Date: Sat Nov 2 12:06:54 2019 +1100 scsi: atari_scsi: sun3_scsi: Set sg_tablesize to 1 instead of SG_NONE [ Upstream commit 79172ab20bfd8437b277254028efdb68484e2c21 ] Since the scsi subsystem adopted the blk-mq API, a host with zero sg_tablesize crashes with a NULL pointer dereference. blk_queue_max_segments: set to minimum 1 scsi 0:0:0:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 scsi target0:0:0: Beginning Domain Validation scsi target0:0:0: Domain Validation skipping write tests scsi target0:0:0: Ending Domain Validation blk_queue_max_segments: set to minimum 1 scsi 0:0:1:0: Direct-Access QEMU QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 scsi target0:0:1: Beginning Domain Validation scsi target0:0:1: Domain Validation skipping write tests scsi target0:0:1: Ending Domain Validation blk_queue_max_segments: set to minimum 1 scsi 0:0:2:0: CD-ROM QEMU QEMU CD-ROM 2.5+ PQ: 0 ANSI: 5 scsi target0:0:2: Beginning Domain Validation scsi target0:0:2: Domain Validation skipping write tests scsi target0:0:2: Ending Domain Validation blk_queue_max_segments: set to minimum 1 blk_queue_max_segments: set to minimum 1 blk_queue_max_segments: set to minimum 1 blk_queue_max_segments: set to minimum 1 sr 0:0:2:0: Power-on or device reset occurred sd 0:0:0:0: Power-on or device reset occurred sd 0:0:1:0: Power-on or device reset occurred sd 0:0:0:0: [sda] 10485762 512-byte logical blocks: (5.37 GB/5.00 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Unable to handle kernel NULL pointer dereference at virtual address (ptrval) Oops: 00000000 Modules linked in: PC: [<001cd874>] blk_mq_free_request+0x66/0xe2 SR: 2004 SP: (ptrval) a2: 00874520 d0: 00000000 d1: 00000000 d2: 009ba800 d3: 00000000 d4: 00000000 d5: 08000002 a0: 0087be68 a1: 009a81e0 Process kworker/u2:2 (pid: 15, task=(ptrval)) Frame format=7 eff addr=0000007a ssw=0505 faddr=0000007a wb 1 stat/addr/data: 0000 00000000 00000000 wb 2 stat/addr/data: 0000 00000000 00000000 wb 3 stat/addr/data: 0000 0000007a 00000000 push data: 00000000 00000000 00000000 00000000 Stack from 0087bd98: 00000002 00000000 0087be72 009a7820 0087bdb4 001c4f6c 009a7820 0087bdd4 0024d200 009a7820 0024d0dc 0087be72 009baa00 0087be68 009a5000 0087be7c 00265d10 009a5000 0087be72 00000003 00000000 00000000 00000000 0087be68 00000bb8 00000005 00000000 00000000 00000000 00000000 00265c56 00000000 009ba60c 0036ddf4 00000002 ffffffff 009baa00 009ba600 009a50d6 0087be74 00227ba0 009baa08 00000001 009baa08 009ba60c 0036ddf4 00000000 00000000 Call Trace: [<001c4f6c>] blk_put_request+0xe/0x14 [<0024d200>] __scsi_execute+0x124/0x174 [<0024d0dc>] __scsi_execute+0x0/0x174 [<00265d10>] sd_revalidate_disk+0xba/0x1f02 [<00265c56>] sd_revalidate_disk+0x0/0x1f02 [<0036ddf4>] strlen+0x0/0x22 [<00227ba0>] device_add+0x3da/0x604 [<0036ddf4>] strlen+0x0/0x22 [<00267e64>] sd_probe+0x30c/0x4b4 [<0002da44>] process_one_work+0x0/0x402 [<0022b978>] really_probe+0x226/0x354 [<0022bc34>] driver_probe_device+0xa4/0xf0 [<0002da44>] process_one_work+0x0/0x402 [<0022bcd0>] __driver_attach_async_helper+0x50/0x70 [<00035dae>] async_run_entry_fn+0x36/0x130 [<0002db88>] process_one_work+0x144/0x402 [<0002e1aa>] worker_thread+0x0/0x570 [<0002e29a>] worker_thread+0xf0/0x570 [<0002e1aa>] worker_thread+0x0/0x570 [<003768d8>] schedule+0x0/0xb8 [<0003f58c>] __init_waitqueue_head+0x0/0x12 [<00033e92>] kthread+0xc2/0xf6 [<000331e8>] kthread_parkme+0x0/0x4e [<003768d8>] schedule+0x0/0xb8 [<00033dd0>] kthread+0x0/0xf6 [<00002c10>] ret_from_kernel_thread+0xc/0x14 Code: 0280 0006 0800 56c0 4400 0280 0000 00ff <52b4> 0c3a 082b 0006 0013 6706 2042 53a8 00c4 4ab9 0047 3374 6640 202d 000c 670c Disabling lock debugging due to kernel taint Avoid this by setting sg_tablesize = 1. Link: https://lore.kernel.org/r/4567bcae94523b47d6f3b77450ba305823bca479.1572656814.git.fthain@telegraphics.com.au Reported-and-tested-by: Michael Schmitz Reviewed-by: Michael Schmitz References: commit 68ab2d76e4be ("scsi: cxlflash: Set sg_tablesize to 1 instead of SG_NONE") Signed-off-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 25579c7999462fbbaee7009037ae5675e294a7b6 Author: Aneesh Kumar K.V Date: Thu Jul 11 20:28:14 2019 +0530 powerpc/book3s/mm: Update Oops message to print the correct translation in use [ Upstream commit d7e02f7b7991dbe14a2acfb0e53d675cd149001c ] Avoids confusion when printing Oops message like below Faulting instruction address: 0xc00000000008bdb4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix MMU=Hash SMP NR_CPUS=2048 NUMA PowerNV This was because we never clear the MMU_FTR_HPTE_TABLE feature flag even if we run with radix translation. It was discussed that we should look at this feature flag as an indication of the capability to run hash translation and we should not clear the flag even if we run in radix translation. All the code paths check for radix_enabled() check and if found true consider we are running with radix translation. Follow the same sequence for finding the MMU translation string to be used in Oops message. Signed-off-by: Aneesh Kumar K.V Acked-by: Nicholas Piggin Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190711145814.17970-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit 2a99c17ab271460595eaad34c363917f98fb07b1 Author: Sam Bobroff Date: Thu Oct 17 15:59:37 2019 +1100 powerpc/eeh: differentiate duplicate detection message [ Upstream commit de84ffc3ccbeec3678f95a3d898fc188efa0d9c5 ] Currently when an EEH error is detected, the system log receives the same (or almost the same) message twice: EEH: PHB#0 failure detected, location: N/A EEH: PHB#0 failure detected, location: N/A or EEH: eeh_dev_check_failure: Frozen PHB#0-PE#0 detected EEH: Frozen PHB#0-PE#0 detected This looks like a bug, but in fact the messages are from different functions and mean slightly different things. So keep both but change one of the messages slightly, so that it's clear they are different: EEH: PHB#0 failure detected, location: N/A EEH: Recovering PHB#0, location: N/A or EEH: eeh_dev_check_failure: Frozen PHB#0-PE#0 detected EEH: Recovering PHB#0-PE#0 Signed-off-by: Sam Bobroff Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/43817cb6e6631b0828b9a6e266f60d1f8ca8eb22.1571288375.git.sbobroff@linux.ibm.com Signed-off-by: Sasha Levin commit e25a8e8d0c14be7786160ae12c0998e22e39392b Author: Gustavo L. F. Walbon Date: Thu May 2 18:09:07 2019 -0300 powerpc/security: Fix wrong message when RFI Flush is disable [ Upstream commit 4e706af3cd8e1d0503c25332b30cad33c97ed442 ] The issue was showing "Mitigation" message via sysfs whatever the state of "RFI Flush", but it should show "Vulnerable" when it is disabled. If you have "L1D private" feature enabled and not "RFI Flush" you are vulnerable to meltdown attacks. "RFI Flush" is the key feature to mitigate the meltdown whatever the "L1D private" state. SEC_FTR_L1D_THREAD_PRIV is a feature for Power9 only. So the message should be as the truth table shows: CPU | L1D private | RFI Flush | sysfs ----|-------------|-----------|------------------------------------- P9 | False | False | Vulnerable P9 | False | True | Mitigation: RFI Flush P9 | True | False | Vulnerable: L1D private per thread P9 | True | True | Mitigation: RFI Flush, L1D private per thread P8 | False | False | Vulnerable P8 | False | True | Mitigation: RFI Flush Output before this fix: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: RFI Flush, L1D private per thread # echo 0 > /sys/kernel/debug/powerpc/rfi_flush # cat /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: L1D private per thread Output after fix: # cat /sys/devices/system/cpu/vulnerabilities/meltdown Mitigation: RFI Flush, L1D private per thread # echo 0 > /sys/kernel/debug/powerpc/rfi_flush # cat /sys/devices/system/cpu/vulnerabilities/meltdown Vulnerable: L1D private per thread Signed-off-by: Gustavo L. F. Walbon Signed-off-by: Mauro S. M. Rodrigues Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190502210907.42375-1-gwalbon@linux.ibm.com Signed-off-by: Sasha Levin commit 03c90248c574b002a588a97187000179db6aef7d Author: Tyrel Datwyler Date: Sun Nov 10 23:21:36 2019 -0600 PCI: rpaphp: Correctly match ibm, my-drc-index to drc-name when using drc-info [ Upstream commit 4f9f2d3d7a434b7f882b72550194c9278f4a3925 ] The newer ibm,drc-info property is a condensed description of the old ibm,drc-* properties (ie. names, types, indexes, and power-domains). When matching a drc-index to a drc-name we need to verify that the index is within the start and last drc-index range and map it to a drc-name using the drc-name-prefix and logical index. Fix the mapping by checking that the index is within the range of the current drc-info entry, and build the name from the drc-name-prefix concatenated with the starting drc-name-suffix value and the sequential index obtained by subtracting ibm,my-drc-index from this entries drc-start-index. Signed-off-by: Tyrel Datwyler Acked-by: Bjorn Helgaas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1573449697-5448-10-git-send-email-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit 1b49ded4448ac0153656c44d1165e9f970714bb8 Author: Tyrel Datwyler Date: Sun Nov 10 23:21:35 2019 -0600 PCI: rpaphp: Annotate and correctly byte swap DRC properties [ Upstream commit 0737686778c6dbe0908d684dd5b9c05b127526ba ] The device tree is in big endian format and any properties directly retrieved using OF helpers that don't explicitly byte swap should be annotated. In particular there are several places where we grab the opaque property value for the old ibm,drc-* properties and the ibm,my-drc-index property. Fix this for better static checking by annotating values we know to explicitly big endian, and byte swap where appropriate. Signed-off-by: Tyrel Datwyler Acked-by: Bjorn Helgaas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1573449697-5448-9-git-send-email-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit 7aae44bbc91b90ae2b9fba573e51469ea4e1c7e4 Author: Tyrel Datwyler Date: Sun Nov 10 23:21:32 2019 -0600 PCI: rpaphp: Don't rely on firmware feature to imply drc-info support [ Upstream commit 52e2b0f16574afd082cff0f0e8567b2d9f68c033 ] In the event that the partition is migrated to a platform with older firmware that doesn't support the ibm,drc-info property the device tree is modified to remove the ibm,drc-info property and replace it with the older style ibm,drc-* properties for types, names, indexes, and power-domains. One of the requirements of the drc-info firmware feature is that the client is able to handle both the new property, and old style properties at runtime. Therefore we can't rely on the firmware feature alone to dictate which property is currently present in the device tree. Fix this short coming by checking explicitly for the ibm,drc-info property, and falling back to the older ibm,drc-* properties if it doesn't exist. Signed-off-by: Tyrel Datwyler Acked-by: Bjorn Helgaas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1573449697-5448-6-git-send-email-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit 1bc418d6a90bdf2b39f362bfb92881582573fcc4 Author: David Hildenbrand Date: Thu Oct 31 15:29:22 2019 +0100 powerpc/pseries/cmm: Implement release() function for sysfs device [ Upstream commit 7d8212747435c534c8d564fbef4541a463c976ff ] When unloading the module, one gets ------------[ cut here ]------------ Device 'cmm0' does not have a release() function, it is broken and must be fixed. See Documentation/kobject.txt. WARNING: CPU: 0 PID: 19308 at drivers/base/core.c:1244 .device_release+0xcc/0xf0 ... We only have one static fake device. There is nothing to do when releasing the device (via cmm_exit()). Signed-off-by: David Hildenbrand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191031142933.10779-2-david@redhat.com Signed-off-by: Sasha Levin commit e02c150d9bcd2bc3122c90fa15883078c260dafd Author: Bean Huo Date: Tue Nov 12 23:34:36 2019 +0100 scsi: ufs: fix potential bug which ends in system hang [ Upstream commit cfcbae3895b86c390ede57b2a8f601dd5972b47b ] In function __ufshcd_query_descriptor(), in the event of an error happening, we directly goto out_unlock and forget to invaliate hba->dev_cmd.query.descriptor pointer. This results in this pointer still valid in ufshcd_copy_query_response() for other query requests which go through ufshcd_exec_raw_upiu_cmd(). This will cause __memcpy() crash and system hangs. Log as shown below: Unable to handle kernel paging request at virtual address ffff000012233c40 Mem abort info: ESR = 0x96000047 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000047 CM = 0, WnR = 1 swapper pgtable: 4k pages, 48-bit VAs, pgdp = 0000000028cc735c [ffff000012233c40] pgd=00000000bffff003, pud=00000000bfffe003, pmd=00000000ba8b8003, pte=0000000000000000 Internal error: Oops: 96000047 [#2] PREEMPT SMP ... Call trace: __memcpy+0x74/0x180 ufshcd_issue_devman_upiu_cmd+0x250/0x3c0 ufshcd_exec_raw_upiu_cmd+0xfc/0x1a8 ufs_bsg_request+0x178/0x3b0 bsg_queue_rq+0xc0/0x118 blk_mq_dispatch_rq_list+0xb0/0x538 blk_mq_sched_dispatch_requests+0x18c/0x1d8 __blk_mq_run_hw_queue+0xb4/0x118 blk_mq_run_work_fn+0x28/0x38 process_one_work+0x1ec/0x470 worker_thread+0x48/0x458 kthread+0x130/0x138 ret_from_fork+0x10/0x1c Code: 540000ab a8c12027 a88120c7 a8c12027 (a88120c7) ---[ end trace 793e1eb5dff69f2d ]--- note: kworker/0:2H[2054] exited with preempt_count 1 This patch is to move "descriptor = NULL" down to below the label "out_unlock". Fixes: d44a5f98bb49b2(ufs: query descriptor API) Link: https://lore.kernel.org/r/20191112223436.27449-3-huobean@gmail.com Reviewed-by: Alim Akhtar Reviewed-by: Bart Van Assche Signed-off-by: Bean Huo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit b8361f9a864d954e563528f27769fae66f1881db Author: Tyrel Datwyler Date: Sun Nov 10 23:21:31 2019 -0600 PCI: rpaphp: Fix up pointer to first drc-info entry [ Upstream commit 9723c25f99aff0451cfe6392e1b9fdd99d0bf9f0 ] The first entry of the ibm,drc-info property is an int encoded count of the number of drc-info entries that follow. The "value" pointer returned by of_prop_next_u32() is still pointing at the this value when we call of_read_drc_info_cell(), but the helper function expects that value to be pointing at the first element of an entry. Fix up by incrementing the "value" pointer to point at the first element of the first drc-info entry prior. Signed-off-by: Tyrel Datwyler Acked-by: Bjorn Helgaas Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1573449697-5448-5-git-send-email-tyreld@linux.ibm.com Signed-off-by: Sasha Levin commit b0a72e78fc23aec95d043563aa2811f84a0e992a Author: Kars de Jong Date: Tue Nov 12 18:55:23 2019 +0100 scsi: zorro_esp: Limit DMA transfers to 65536 bytes (except on Fastlane) [ Upstream commit 02f7e9f351a9de95577eafdc3bd413ed1c3b589f ] When using this driver on a Blizzard 1260, there were failures whenever DMA transfers from the SCSI bus to memory of 65535 bytes were followed by a DMA transfer of 1 byte. This caused the byte at offset 65535 to be overwritten with 0xff. The Blizzard hardware can't handle single byte DMA transfers. Besides this issue, limiting the DMA length to something that is not a multiple of the page size is very inefficient on most file systems. It seems this limit was chosen because the DMA transfer counter of the ESP by default is 16 bits wide, thus limiting the length to 65535 bytes. However, the value 0 means 65536 bytes, which is handled by the ESP and the Blizzard just fine. It is also the default maximum used by esp_scsi when drivers don't provide their own dma_length_limit() function. The limit of 65536 bytes can be used by all boards except the Fastlane. The old driver used a limit of 65532 bytes (0xfffc), which is reintroduced in this patch. Fixes: b7ded0e8b0d1 ("scsi: zorro_esp: Limit DMA transfers to 65535 bytes") Link: https://lore.kernel.org/r/20191112175523.23145-1-jongk@linux-m68k.org Signed-off-by: Kars de Jong Reviewed-by: Finn Thain Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cd53b26c1b2ad130c3b63e0ec71da1a04affaa23 Author: James Smart Date: Mon Nov 11 15:03:57 2019 -0800 scsi: lpfc: fix: Coverity: lpfc_cmpl_els_rsp(): Null pointer dereferences [ Upstream commit 6c6d59e0fe5b86cf273d6d744a6a9768c4ecc756 ] Coverity reported the following: *** CID 101747: Null pointer dereferences (FORWARD_NULL) /drivers/scsi/lpfc/lpfc_els.c: 4439 in lpfc_cmpl_els_rsp() 4433 kfree(mp); 4434 } 4435 mempool_free(mbox, phba->mbox_mem_pool); 4436 } 4437 out: 4438 if (ndlp && NLP_CHK_NODE_ACT(ndlp)) { vvv CID 101747: Null pointer dereferences (FORWARD_NULL) vvv Dereferencing null pointer "shost". 4439 spin_lock_irq(shost->host_lock); 4440 ndlp->nlp_flag &= ~(NLP_ACC_REGLOGIN | NLP_RM_DFLT_RPI); 4441 spin_unlock_irq(shost->host_lock); 4442 4443 /* If the node is not being used by another discovery thread, 4444 * and we are sending a reject, we are done with it. Fix by adding a check for non-null shost in line 4438. The scenario when shost is set to null is when ndlp is null. As such, the ndlp check present was sufficient. But better safe than sorry so add the shost check. Reported-by: coverity-bot Addresses-Coverity-ID: 101747 ("Null pointer dereferences") Fixes: 2e0fef85e098 ("[SCSI] lpfc: NPIV: split ports") CC: James Bottomley CC: "Gustavo A. R. Silva" CC: linux-next@vger.kernel.org Link: https://lore.kernel.org/r/20191111230401.12958-3-jsmart2021@gmail.com Reviewed-by: Ewan D. Milne Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a4bf016b32ffd341ef2d62325d0f7963ec6a9dfc Author: Dmitry Torokhov Date: Mon Nov 4 10:39:41 2019 -0800 Input: ili210x - handle errors from input_mt_init_slots() [ Upstream commit 43f06a4c639de8ee89fc348a9a3ecd70320a04dd ] input_mt_init_slots() may fail and we need to handle such failures. Tested-by: Adam Ford #imx6q-logicpd Tested-by: Sven Van Asbroeck # ILI2118A variant Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 185563ec11956ec1237d62fae80eab593ee63ca9 Author: Jan Stancek Date: Mon Nov 11 12:58:24 2019 -0800 iomap: fix return value of iomap_dio_bio_actor on 32bit systems [ Upstream commit e9f930ac88a8936ccc2d021110c98810cf5aa810 ] Naresh reported LTP diotest4 failing for 32bit x86 and arm -next kernels on ext4. Same problem exists in 5.4-rc7 on xfs. The failure comes down to: openat(AT_FDCWD, "testdata-4.5918", O_RDWR|O_DIRECT) = 4 mmap2(NULL, 4096, PROT_READ, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f7b000 read(4, 0xb7f7b000, 4096) = 0 // expects -EFAULT Problem is conversion at iomap_dio_bio_actor() return. Ternary operator has a return type and an attempt is made to convert each of operands to the type of the other. In this case "ret" (int) is converted to type of "copied" (unsigned long). Both have size of 4 bytes: size_t copied = 0; int ret = -14; long long actor_ret = copied ? copied : ret; On x86_64: actor_ret == -14; On x86 : actor_ret == 4294967282 Replace ternary operator with 2 return statements to avoid this unwanted conversion. Fixes: 4721a6010990 ("iomap: dio data corruption and spurious errors when pipes fill") Reported-by: Naresh Kamboju Signed-off-by: Jan Stancek Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 1558fadfca30c82751cda70315c768ebabaaf260 Author: Alain Volmat Date: Fri Oct 25 16:04:24 2019 +0200 i2c: stm32f7: fix & reorder remove & probe error handling [ Upstream commit 53aaaa5d9b1e95eb40e877fbffa6f964a8394bb7 ] Add missing dma channels free calls in case of error during probe and reorder the remove function so that dma channels are freed after the i2c adapter is deleted. Overall, reorder the remove function so that probe error handling order and remove function order are same. Fixes: 7ecc8cfde553 ("i2c: i2c-stm32f7: Add DMA support") Signed-off-by: Alain Volmat Reviewed-by: Pierre-Yves MORDRET Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6b1400f260df61fd6921a098fc00f7b647421b40 Author: Jean-Philippe Brucker Date: Mon Nov 11 12:17:20 2019 +0100 iommu/arm-smmu-v3: Don't display an error when IRQ lines are missing [ Upstream commit f7aff1a93f52047739af31072de0ad8d149641f3 ] Since commit 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()"), platform_get_irq_byname() displays an error when the IRQ isn't found. Since the SMMUv3 driver uses that function to query which interrupt method is available, the message is now displayed during boot for any SMMUv3 that doesn't implement the combined interrupt, or that implements MSIs. [ 20.700337] arm-smmu-v3 arm-smmu-v3.7.auto: IRQ combined not found [ 20.706508] arm-smmu-v3 arm-smmu-v3.7.auto: IRQ eventq not found [ 20.712503] arm-smmu-v3 arm-smmu-v3.7.auto: IRQ priq not found [ 20.718325] arm-smmu-v3 arm-smmu-v3.7.auto: IRQ gerror not found Use platform_get_irq_byname_optional() to avoid displaying a spurious error. Fixes: 7723f4c5ecdb ("driver core: platform: Add an error message to platform_get_irq*()") Signed-off-by: Jean-Philippe Brucker Acked-by: Will Deacon Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 19f612e6ccd727d7efc958c992f332c4e8901eee Author: Konstantin Khlebnikov Date: Sun Nov 10 12:49:06 2019 +0300 fs/quota: handle overflows of sysctl fs.quota.* and report as unsigned long [ Upstream commit 6fcbcec9cfc7b3c6a2c1f1a23ebacedff7073e0a ] Quota statistics counted as 64-bit per-cpu counter. Reading sums per-cpu fractions as signed 64-bit int, filters negative values and then reports lower half as signed 32-bit int. Result may looks like: fs.quota.allocated_dquots = 22327 fs.quota.cache_hits = -489852115 fs.quota.drops = -487288718 fs.quota.free_dquots = 22083 fs.quota.lookups = -486883485 fs.quota.reads = 22327 fs.quota.syncs = 335064 fs.quota.writes = 3088689 Values bigger than 2^31-1 reported as negative. All counters except "allocated_dquots" and "free_dquots" are monotonic, thus they should be reported as is without filtering negative values. Kernel doesn't have generic helper for 64-bit sysctl yet, let's use at least unsigned long. Link: https://lore.kernel.org/r/157337934693.2078.9842146413181153727.stgit@buzz Signed-off-by: Konstantin Khlebnikov Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit e44850bd4205a8cf17f23c44668c0f8d28ad40b1 Author: Nicolas Saenz Julienne Date: Thu Nov 7 16:06:44 2019 +0100 dma-direct: check for overflows on 32 bit DMA addresses [ Upstream commit b12d66278dd627cbe1ea7c000aa4715aaf8830c8 ] As seen on the new Raspberry Pi 4 and sta2x11's DMA implementation it is possible for a device configured with 32 bit DMA addresses and a partial DMA mapping located at the end of the address space to overflow. It happens when a higher physical address, not DMAable, is translated to it's DMA counterpart. For example the Raspberry Pi 4, configurable up to 4 GB of memory, has an interconnect capable of addressing the lower 1 GB of physical memory with a DMA offset of 0xc0000000. It transpires that, any attempt to translate physical addresses higher than the first GB will result in an overflow which dma_capable() can't detect as it only checks for addresses bigger then the maximum allowed DMA address. Fix this by verifying in dma_capable() if the DMA address range provided is at any point lower than the minimum possible DMA address on the bus. Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 44d9a1428d87293149562d643758e793221611a5 Author: Paul Cercueil Date: Wed Oct 2 19:25:22 2019 +0800 irqchip: ingenic: Error out if IRQ domain creation failed [ Upstream commit 52ecc87642f273a599c9913b29fd179c13de457b ] If we cannot create the IRQ domain, the driver should fail to probe instead of succeeding with just a warning message. Signed-off-by: Paul Cercueil Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/1570015525-27018-3-git-send-email-zhouyanjie@zoho.com Signed-off-by: Sasha Levin commit c14a155609ae66321c0280d24a9cccbf210f924a Author: Florian Fainelli Date: Thu Oct 24 13:14:13 2019 -0700 irqchip/irq-bcm7038-l1: Enable parent IRQ if necessary [ Upstream commit 27eebb60357ed5aa6659442f92907c0f7368d6ae ] If the 'brcm,irq-can-wake' property is specified, make sure we also enable the corresponding parent interrupt we are attached to. Signed-off-by: Florian Fainelli Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20191024201415.23454-4-f.fainelli@gmail.com Signed-off-by: Sasha Levin commit 3d9b0a683e22cb53286386dc4b7625de210f185a Author: Michael Hennerich Date: Fri Nov 8 09:17:18 2019 +0200 clk: clk-gpio: propagate rate change to parent [ Upstream commit fc59462c5ce60da119568fac325c92fc6b7c6175 ] For an external clock source, which is gated via a GPIO, the rate change should typically be propagated to the parent clock. The situation where we are requiring this propagation, is when an external clock is connected to override an internal clock (which typically has a fixed rate). The external clock can have a different rate than the internal one, and may also be variable, thus requiring the rate propagation. This rate change wasn't propagated until now, and it's unclear about cases where this shouldn't be propagated. Thus, it's unclear whether this is fixing a bug, or extending the current driver behavior. Also, it's unsure about whether this may break any existing setups; in the case that it does, a device-tree property may be added to disable this flag. Signed-off-by: Michael Hennerich Signed-off-by: Alexandru Ardelean Link: https://lkml.kernel.org/r/20191108071718.17985-1-alexandru.ardelean@analog.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 0e219dae7ce725825f055d572fed6752a395eb72 Author: Jeffrey Hugo Date: Thu Oct 31 11:57:15 2019 -0700 clk: qcom: Allow constant ratio freq tables for rcg [ Upstream commit efd164b5520afd6fb2883b68e0d408a7de29c491 ] Some RCGs (the gfx_3d_src_clk in msm8998 for example) are basically just some constant ratio from the input across the entire frequency range. It would be great if we could specify the frequency table as a single entry constant ratio instead of a long list, ie: { .src = P_GPUPLL0_OUT_EVEN, .pre_div = 3 }, { } So, lets support that. We need to fix a corner case in qcom_find_freq() where if the freq table is non-null, but has no frequencies, we end up returning an "entry" before the table array, which is bad. Then, we need ignore the freq from the table, and instead base everything on the requested freq. Suggested-by: Stephen Boyd Signed-off-by: Jeffrey Hugo Link: https://lkml.kernel.org/r/20191031185715.15504-1-jeffrey.l.hugo@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6ed60d7f2a54d675f0627719dcfc0ad31fdae0a3 Author: Jeffrey Hugo Date: Thu Nov 7 11:06:15 2019 -0800 clk: qcom: smd: Add missing pnoc clock [ Upstream commit ba1d366de261981c0dd04fac44d2ce3a5eba2eaa ] When MSM8998 support was added, and analysis was done to determine what clocks would be consumed. That analysis had a flaw, which caused the pnoc to be skipped. The pnoc clock needs to be on to access the uart for the console. The clock is on from boot, but has no consumer votes in the RPM. When we attempt to boot the modem, it causes the RPM to turn off pnoc, which kills our access to the console and causes CPU hangs. We need pnoc to be defined, so that clk_smd_rpm_handoff() will put in an implicit vote for linux and prevent issues when booting modem. Hopefully pnoc can be consumed by the interconnect framework in future so that Linux can rely on explicit votes. Fixes: 6131dc81211c ("clk: qcom: smd: Add support for MSM8998 rpm clocks") Signed-off-by: Jeffrey Hugo Link: https://lkml.kernel.org/r/20191107190615.5656-1-jeffrey.l.hugo@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit bc5de89f679b06a7bc9c2e2f83c0f4c438ea8f56 Author: Chao Yu Date: Thu Nov 7 14:12:05 2019 +0800 f2fs: fix to update dir's i_pino during cross_rename [ Upstream commit 2a60637f06ac94869b2e630eaf837110d39bf291 ] As Eric reported: RENAME_EXCHANGE support was just added to fsstress in xfstests: commit 65dfd40a97b6bbbd2a22538977bab355c5bc0f06 Author: kaixuxia Date: Thu Oct 31 14:41:48 2019 +0800 fsstress: add EXCHANGE renameat2 support This is causing xfstest generic/579 to fail due to fsck.f2fs reporting errors. I'm not sure what the problem is, but it still happens even with all the fs-verity stuff in the test commented out, so that the test just runs fsstress. generic/579 23s ... [10:02:25] [ 7.745370] run fstests generic/579 at 2019-11-04 10:02:25 _check_generic_filesystem: filesystem on /dev/vdc is inconsistent (see /results/f2fs/results-default/generic/579.full for details) [10:02:47] Ran: generic/579 Failures: generic/579 Failed 1 of 1 tests Xunit report: /results/f2fs/results-default/result.xml Here's the contents of 579.full: _check_generic_filesystem: filesystem on /dev/vdc is inconsistent *** fsck.f2fs output *** [ASSERT] (__chk_dots_dentries:1378) --> Bad inode number[0x24] for '..', parent parent ino is [0xd10] The root cause is that we forgot to update directory's i_pino during cross_rename, fix it. Fixes: 32f9bc25cbda0 ("f2fs: support ->rename2()") Signed-off-by: Chao Yu Tested-by: Eric Biggers Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 11ff350c9bd39258eec186600c931515e18d447f Author: James Smart Date: Mon Nov 4 16:56:58 2019 -0800 scsi: lpfc: Fix duplicate unreg_rpi error in port offline flow [ Upstream commit 7cfd5639d99bec0d27af089d0c8c114330e43a72 ] If the driver receives a login that is later then LOGO'd by the remote port (aka ndlp), the driver, upon the completion of the LOGO ACC transmission, will logout the node and unregister the rpi that is being used for the node. As part of the unreg, the node's rpi value is replaced by the LPFC_RPI_ALLOC_ERROR value. If the port is subsequently offlined, the offline walks the nodes and ensures they are logged out, which possibly entails unreg'ing their rpi values. This path does not validate the node's rpi value, thus doesn't detect that it has been unreg'd already. The replaced rpi value is then used when accessing the rpi bitmask array which tracks active rpi values. As the LPFC_RPI_ALLOC_ERROR value is not a valid index for the bitmask, it may fault the system. Revise the rpi release code to detect when the rpi value is the replaced RPI_ALLOC_ERROR value and ignore further release steps. Link: https://lore.kernel.org/r/20191105005708.7399-2-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 358b37c6c67663f56891c3464d9e2c8e470842da Author: James Smart Date: Mon Nov 4 16:57:01 2019 -0800 scsi: lpfc: Fix unexpected error messages during RSCN handling [ Upstream commit 2332e6e475b016e2026763f51333f84e2e6c57a3 ] During heavy RCN activity and log_verbose = 0 we see these messages: 2754 PRLI failure DID:521245 Status:x9/xb2c00, data: x0 0231 RSCN timeout Data: x0 x3 0230 Unexpected timeout, hba link state x5 This is due to delayed RSCN activity. Correct by avoiding the timeout thus the messages by restarting the discovery timeout whenever an rscn is received. Filter PRLI responses such that severity depends on whether expected for the configuration or not. For example, PRLI errors on a fabric will be informational (they are expected), but Point-to-Point errors are not necessarily expected so they are raised to an error level. Link: https://lore.kernel.org/r/20191105005708.7399-5-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 872f8013136e6775b648eb5ba0469deb7e40d86d Author: Bart Van Assche Date: Tue Nov 5 13:55:53 2019 -0800 scsi: tracing: Fix handling of TRANSFER LENGTH == 0 for READ(6) and WRITE(6) [ Upstream commit f6b8540f40201bff91062dd64db8e29e4ddaaa9d ] According to SBC-2 a TRANSFER LENGTH field of zero means that 256 logical blocks must be transferred. Make the SCSI tracing code follow SBC-2. Fixes: bf8162354233 ("[SCSI] add scsi trace core functions and put trace points") Cc: Christoph Hellwig Cc: Hannes Reinecke Cc: Douglas Gilbert Link: https://lore.kernel.org/r/20191105215553.185018-1-bvanassche@acm.org Signed-off-by: Bart Van Assche Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 9e2946bdddf136c90ac06b717856fa7d83830af7 Author: Jan Kara Date: Tue Nov 5 17:44:19 2019 +0100 jbd2: Fix statistics for the number of logged blocks [ Upstream commit 015c6033068208d6227612c878877919f3fcf6b6 ] jbd2 statistics counting number of blocks logged in a transaction was wrong. It didn't count the commit block and more importantly it didn't count revoke descriptor blocks. Make sure these get properly counted. Reviewed-by: Theodore Ts'o Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191105164437.32602-13-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit e48a6034482babeccdd6a2aac6f3b10beda35f26 Author: Matthew Bobrowski Date: Tue Nov 5 22:59:37 2019 +1100 ext4: iomap that extends beyond EOF should be marked dirty [ Upstream commit 2e9b51d78229d5145725a481bb5464ebc0a3f9b2 ] This patch addresses what Dave Chinner had discovered and fixed within commit: 7684e2c4384d. This changes does not have any user visible impact for ext4 as none of the current users of ext4_iomap_begin() that extend files depend on IOMAP_F_DIRTY. When doing a direct IO that spans the current EOF, and there are written blocks beyond EOF that extend beyond the current write, the only metadata update that needs to be done is a file size extension. However, we don't mark such iomaps as IOMAP_F_DIRTY to indicate that there is IO completion metadata updates required, and hence we may fail to correctly sync file size extensions made in IO completion when O_DSYNC writes are being used and the hardware supports FUA. Hence when setting IOMAP_F_DIRTY, we need to also take into account whether the iomap spans the current EOF. If it does, then we need to mark it dirty so that IO completion will call generic_write_sync() to flush the inode size update to stable storage correctly. Signed-off-by: Matthew Bobrowski Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani Link: https://lore.kernel.org/r/8b43ee9ee94bee5328da56ba0909b7d2229ef150.1572949325.git.mbobrowski@mbobrowski.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 339a860cdd0726477131c67e1d618844f2b64610 Author: Matthew Bobrowski Date: Tue Nov 5 22:59:22 2019 +1100 ext4: update direct I/O read lock pattern for IOCB_NOWAIT [ Upstream commit 548feebec7e93e58b647dba70b3303dcb569c914 ] This patch updates the lock pattern in ext4_direct_IO_read() to not block on inode lock in cases of IOCB_NOWAIT direct I/O reads. The locking condition implemented here is similar to that of 942491c9e6d6 ("xfs: fix AIM7 regression"). Fixes: 16c54688592c ("ext4: Allow parallel DIO reads") Signed-off-by: Matthew Bobrowski Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani Link: https://lore.kernel.org/r/c5d5e759f91747359fbd2c6f9a36240cf75ad79f.1572949325.git.mbobrowski@mbobrowski.org Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 99db9e0fec6bc5b8f2d3e9def3c3ed9e2a302d5b Author: Aneesh Kumar K.V Date: Tue Oct 1 14:16:56 2019 +0530 powerpc/book3s64/hash: Add cond_resched to avoid soft lockup warning [ Upstream commit 16f6b67cf03cb43db7104acb2ca877bdc2606c92 ] With large memory (8TB and more) hotplug, we can get soft lockup warnings as below. These were caused by a long loop without any explicit cond_resched which is a problem for !PREEMPT kernels. Avoid this using cond_resched() while inserting hash page table entries. We already do similar cond_resched() in __add_pages(), see commit f64ac5e6e306 ("mm, memory_hotplug: add scheduling point to __add_pages"). rcu: 3-....: (24002 ticks this GP) idle=13e/1/0x4000000000000002 softirq=722/722 fqs=12001 (t=24003 jiffies g=4285 q=2002) NMI backtrace for cpu 3 CPU: 3 PID: 3870 Comm: ndctl Not tainted 5.3.0-197.18-default+ #2 Call Trace: dump_stack+0xb0/0xf4 (unreliable) nmi_cpu_backtrace+0x124/0x130 nmi_trigger_cpumask_backtrace+0x1ac/0x1f0 arch_trigger_cpumask_backtrace+0x28/0x3c rcu_dump_cpu_stacks+0xf8/0x154 rcu_sched_clock_irq+0x878/0xb40 update_process_times+0x48/0x90 tick_sched_handle.isra.16+0x4c/0x80 tick_sched_timer+0x68/0xe0 __hrtimer_run_queues+0x180/0x430 hrtimer_interrupt+0x110/0x300 timer_interrupt+0x108/0x2f0 decrementer_common+0x114/0x120 --- interrupt: 901 at arch_add_memory+0xc0/0x130 LR = arch_add_memory+0x74/0x130 memremap_pages+0x494/0x650 devm_memremap_pages+0x3c/0xa0 pmem_attach_disk+0x188/0x750 nvdimm_bus_probe+0xac/0x2c0 really_probe+0x148/0x570 driver_probe_device+0x19c/0x1d0 device_driver_attach+0xcc/0x100 bind_store+0x134/0x1c0 drv_attr_store+0x44/0x60 sysfs_kf_write+0x64/0x90 kernfs_fop_write+0x1a0/0x270 __vfs_write+0x3c/0x70 vfs_write+0xd0/0x260 ksys_write+0xdc/0x130 system_call+0x5c/0x68 Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191001084656.31277-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit f68c0f32944544bb8e7c6fb411713e3fd855a753 Author: Anthony Steinhauser Date: Tue Oct 29 12:07:59 2019 -0700 powerpc/security/book3s64: Report L1TF status in sysfs [ Upstream commit 8e6b6da91ac9b9ec5a925b6cb13f287a54bd547d ] Some PowerPC CPUs are vulnerable to L1TF to the same extent as to Meltdown. It is also mitigated by flushing the L1D on privilege transition. Currently the sysfs gives a false negative on L1TF on CPUs that I verified to be vulnerable, a Power9 Talos II Boston 004e 1202, PowerNV T2P9D01. Signed-off-by: Anthony Steinhauser Signed-off-by: Michael Ellerman [mpe: Just have cpu_show_l1tf() call cpu_show_meltdown() directly] Link: https://lore.kernel.org/r/20191029190759.84821-1-asteinhauser@google.com Signed-off-by: Sasha Levin commit 0090266e05da3c1d56a1e584741cd5f593624779 Author: Michael Ellerman Date: Tue Nov 5 10:15:56 2019 +1100 selftests/powerpc: Skip tm-signal-sigreturn-nt if TM not available [ Upstream commit 505127068d9b705a6cf335143239db91bfe7bbe2 ] On systems where TM (Transactional Memory) is disabled the tm-signal-sigreturn-nt test causes a SIGILL: test: tm_signal_sigreturn_nt tags: git_version:7c202575ef63 !! child died by signal 4 failure: tm_signal_sigreturn_nt We should skip the test if TM is not available. Fixes: 34642d70ac7e ("selftests/powerpc: Add checks for transactional sigreturn") Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191104233524.24348-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 1332e29038a35c81200f1677ef760d3919a1ddf1 Author: Pavel Modilaynen Date: Fri Jul 12 13:52:19 2019 +0200 dtc: Use pkg-config to locate libyaml [ Upstream commit 067c650c456e758f933aaf87a202f841d34be269 ] Using Makefile's wildcard with absolute path to detect the presence of libyaml results in false-positive detection when cross-compiling e.g. in yocto environment. The latter results in build error: | scripts/dtc/yamltree.o: In function `yaml_propval_int': | yamltree.c: undefined reference to `yaml_sequence_start_event_initialize' | yamltree.c: undefined reference to `yaml_emitter_emit' | yamltree.c: undefined reference to `yaml_scalar_event_initialize' ... Use pkg-config to locate libyaml to address this scenario. Signed-off-by: Pavel Modilaynen [robh: silence stderr] Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 139ca605c35eb3cc3dbee53803b89ea37b01367b Author: Geert Uytterhoeven Date: Wed Oct 16 16:47:45 2019 +0200 clocksource/drivers/timer-of: Use unique device name instead of timer [ Upstream commit 4411464d6f8b5e5759637235a6f2b2a85c2be0f1 ] If a hardware-specific driver does not provide a name, the timer-of core falls back to device_node.name. Due to generic DT node naming policies, that name is almost always "timer", and thus doesn't identify the actual timer used. Fix this by using device_node.full_name instead, which includes the unit addrees. Example impact on /proc/timer_list: -Clock Event Device: timer +Clock Event Device: timer@fcfec400 Signed-off-by: Geert Uytterhoeven Reviewed-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20191016144747.29538-3-geert+renesas@glider.be Signed-off-by: Sasha Levin commit f9e1fc5b6f0cebeca4f7b19145e8d63187419d51 Author: Chuhong Yuan Date: Wed Oct 16 20:43:30 2019 +0800 clocksource/drivers/asm9260: Add a check for of_clk_get [ Upstream commit 6e001f6a4cc73cd06fc7b8c633bc4906c33dd8ad ] asm9260_timer_init misses a check for of_clk_get. Add a check for it and print errors like other clocksource drivers. Signed-off-by: Chuhong Yuan Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20191016124330.22211-1-hslester96@gmail.com Signed-off-by: Sasha Levin commit b6b7636ac42855d70150e8e804f2e142204eae8b Author: Martin Schiller Date: Fri Oct 25 09:01:42 2019 +0200 leds: trigger: netdev: fix handling on interface rename [ Upstream commit 5f820ed52371b4f5d8c43c93f03408d0dbc01e5b ] The NETDEV_CHANGENAME code is not "unneeded" like it is stated in commit 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename"). The event was accidentally misinterpreted equivalent to NETDEV_UNREGISTER, but should be equivalent to NETDEV_REGISTER. This was the case in the original code from the openwrt project. Otherwise, you are unable to set netdev led triggers for (non-existent) netdevices, which has to be renamed. This is the case, for example, for ppp interfaces in openwrt. Fixes: 06f502f57d0d ("leds: trigger: Introduce a NETDEV trigger") Fixes: 4cb6560514fa ("leds: trigger: netdev: fix refcnt leak on interface rename") Signed-off-by: Martin Schiller Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit fd2f1bc5b673328f3b14ecd1da8d7389c862bea9 Author: Chuhong Yuan Date: Wed Oct 16 20:54:03 2019 +0800 leds: an30259a: add a check for devm_regmap_init_i2c [ Upstream commit fc7b5028f2627133c7c18734715a08829eab4d1f ] an30259a_probe misses a check for devm_regmap_init_i2c and may cause problems. Add a check and print errors like other leds drivers. Signed-off-by: Chuhong Yuan Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit af4eac2a2871a97f6284f816930ab612bbd6c01c Author: Guido Günther Date: Sat Sep 21 14:12:10 2019 -0700 leds: lm3692x: Handle failure to probe the regulator [ Upstream commit 396128d2ffcba6e1954cfdc9a89293ff79cbfd7c ] Instead use devm_regulator_get_optional since the regulator is optional and check for errors. Signed-off-by: Guido Günther Acked-by: Pavel Machek Reviewed-by: Dan Murphy Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin commit 37958001e11d592114c3e02e296065c670803ced Author: Krzysztof Kozlowski Date: Fri Oct 4 17:08:26 2019 +0200 dmaengine: fsl-qdma: Handle invalid qdma-queue0 IRQ [ Upstream commit 41814c4eadf8a791b6d07114f96e7e120e59555c ] platform_get_irq_byname() might return -errno which later would be cast to an unsigned int and used in IRQ handling code leading to usage of wrong ID and errors about wrong irq_base. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Peng Ma Tested-by: Peng Ma Link: https://lore.kernel.org/r/20191004150826.6656-1-krzk@kernel.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit fee76d84ba258022865d00c1817281fbdc494bf9 Author: Vladimir Murzin Date: Wed Oct 30 10:13:13 2019 +0000 dma-mapping: fix handling of dma-ranges for reserved memory (again) [ Upstream commit a445e940ea686fc60475564009821010eb213be3 ] Daniele reported that issue previously fixed in c41f9ea998f3 ("drivers: dma-coherent: Account dma_pfn_offset when used with device tree") reappear shortly after 43fc509c3efb ("dma-coherent: introduce interface for default DMA pool") where fix was accidentally dropped. Lets put fix back in place and respect dma-ranges for reserved memory. Fixes: 43fc509c3efb ("dma-coherent: introduce interface for default DMA pool") Reported-by: Daniele Alessandrelli Tested-by: Daniele Alessandrelli Tested-by: Alexandre Torgue Signed-off-by: Vladimir Murzin Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 686dd313a2caaa374f21087cce768d44b534a170 Author: Kees Cook Date: Tue Oct 29 14:34:22 2019 -0700 dma-mapping: Add vmap checks to dma_map_single() [ Upstream commit 4544b9f25e70eae9f70a243de0cc802aa5c8cb69 ] As we've seen from USB and other areas[1], we need to always do runtime checks for DMA operating on memory regions that might be remapped. This adds vmap checks (similar to those already in USB but missing in other places) into dma_map_single() so all callers benefit from the checking. [1] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb Suggested-by: Laura Abbott Signed-off-by: Kees Cook [hch: fixed the printk message] Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 34205ed59e98a3ce6bab5b2085dcb33c8c0ca98e Author: Eric Dumazet Date: Mon Oct 28 14:56:46 2019 -0700 dma-debug: add a schedule point in debug_dma_dump_mappings() [ Upstream commit 9ff6aa027dbb98755f0265695354f2dd07c0d1ce ] debug_dma_dump_mappings() can take a lot of cpu cycles : lpk43:/# time wc -l /sys/kernel/debug/dma-api/dump 163435 /sys/kernel/debug/dma-api/dump real 0m0.463s user 0m0.003s sys 0m0.459s Let's add a cond_resched() to avoid holding cpu for too long. Signed-off-by: Eric Dumazet Cc: Corentin Labbe Cc: Christoph Hellwig Cc: Marek Szyprowski Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit d26bf75e06f72bea4f7cbaed2170cb9b9e0b7c2e Author: Michael Ellerman Date: Thu Oct 24 11:47:30 2019 +1100 powerpc/tools: Don't quote $objdump in scripts [ Upstream commit e44ff9ea8f4c8a90c82f7b85bd4f5e497c841960 ] Some of our scripts are passed $objdump and then call it as "$objdump". This doesn't work if it contains spaces because we're using ccache, for example you get errors such as: ./arch/powerpc/tools/relocs_check.sh: line 48: ccache ppc64le-objdump: No such file or directory ./arch/powerpc/tools/unrel_branch_check.sh: line 26: ccache ppc64le-objdump: No such file or directory Fix it by not quoting the string when we expand it, allowing the shell to do the right thing for us. Fixes: a71aa05e1416 ("powerpc: Convert relocs_check to a shell script using grep") Fixes: 4ea80652dc75 ("powerpc/64s: Tool to flag direct branches from unrelocated interrupt vectors") Signed-off-by: Michael Ellerman Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191024004730.32135-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 89c7e99b391134cc3264b38ea2cea4705b45d4ad Author: Michael Ellerman Date: Mon Oct 14 13:30:43 2019 +1100 selftests/powerpc: Fixup clobbers for TM tests [ Upstream commit a02cbc7ffe529ed58b6bbe54652104fc2c88bd77 ] Some of our TM (Transactional Memory) tests, list "r1" (the stack pointer) as a clobbered register. GCC >= 9 doesn't accept this, and the build breaks: ptrace-tm-spd-tar.c: In function 'tm_spd_tar': ptrace-tm-spd-tar.c:31:2: error: listing the stack pointer register 'r1' in a clobber list is deprecated [-Werror=deprecated] 31 | asm __volatile__( | ^~~ ptrace-tm-spd-tar.c:31:2: note: the value of the stack pointer after an 'asm' statement must be the same as it was before the statement We do have some fairly large inline asm blocks in these tests, and some of them do change the value of r1. However they should all return to C with the value in r1 restored, so I think it's legitimate to say r1 is not clobbered. As Segher points out, the r1 clobbers may have been added because of the use of `or 1,1,1`, however that doesn't actually clobber r1. Segher also points out that some of these tests do clobber LR, because they call functions, and that is not listed in the clobbers, so add that where appropriate. Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191029095324.14669-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 1720bdd8e6ec695083bb56c50fbd216ba1c24830 Author: Dmitry Torokhov Date: Mon Oct 21 11:02:33 2019 -0700 Input: st1232 - do not reset the chip too early [ Upstream commit efd7bb08a762d4f6322054c6824bd942971ac563 ] We should not be putting the chip into reset while interrupts are enabled and ISR may be running. Fix this by installing a custom devm action and powering off the device/resetting GPIO line from there. This ensures proper ordering. Tested-by: Matthias Fend Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 779c0ee4f459846e038b2f981157c9bc7429342c Author: Aneesh Kumar K.V Date: Thu Oct 24 15:05:41 2019 +0530 powerpc/pseries: Don't fail hash page table insert for bolted mapping [ Upstream commit 75838a3290cd4ebbd1f567f310ba04b6ef017ce4 ] If the hypervisor returned H_PTEG_FULL for H_ENTER hcall, retry a hash page table insert by removing a random entry from the group. After some runtime, it is very well possible to find all the 8 hash page table entry slot in the hpte group used for mapping. Don't fail a bolted entry insert in that case. With Storage class memory a user can find this error easily since a namespace enable/disable is equivalent to memory add/remove. This results in failures as reported below: $ ndctl create-namespace -r region1 -t pmem -m devdax -a 65536 -s 100M libndctl: ndctl_dax_enable: dax1.3: failed to enable Error: namespace1.2: failed to enable failed to create namespace: No such device or address In kernel log we find the details as below: Unable to create mapping for hot added memory 0xc000042006000000..0xc00004200d000000: -1 dax_pmem: probe of dax1.3 failed with error -14 This indicates that we failed to create a bolted hash table entry for direct-map address backing the namespace. We also observe failures such that not all namespaces will be enabled with ndctl enable-namespace all command. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191024093542.29777-2-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit 3655538ba83ad3f5adc9f85b871a8c86d01c6e5d Author: Michael Ellerman Date: Sun Oct 13 21:23:51 2019 +1100 powerpc/pseries: Mark accumulate_stolen_time() as notrace [ Upstream commit eb8e20f89093b64f48975c74ccb114e6775cee22 ] accumulate_stolen_time() is called prior to interrupt state being reconciled, which can trip the warning in arch_local_irq_restore(): WARNING: CPU: 5 PID: 1017 at arch/powerpc/kernel/irq.c:258 .arch_local_irq_restore+0x9c/0x130 ... NIP .arch_local_irq_restore+0x9c/0x130 LR .rb_start_commit+0x38/0x80 Call Trace: .ring_buffer_lock_reserve+0xe4/0x620 .trace_function+0x44/0x210 .function_trace_call+0x148/0x170 .ftrace_ops_no_ops+0x180/0x1d0 ftrace_call+0x4/0x8 .accumulate_stolen_time+0x1c/0xb0 decrementer_common+0x124/0x160 For now just mark it as notrace. We may change the ordering to call it after interrupt state has been reconciled, but that is a larger change. Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191024055932.27940-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 266bde856cbd31429b77791f93948cd9899b9da1 Author: Luo Jiaxing Date: Thu Oct 24 22:08:24 2019 +0800 scsi: hisi_sas: Delete the debugfs folder of hisi_sas when the probe fails [ Upstream commit cabe7c10c97a0857a9fb14b6c772ab784947995d ] Although if the debugfs initialization fails, we will delete the debugfs folder of hisi_sas, but we did not consider the scenario where debugfs was successfully initialized, but the probe failed for other reasons. We found out that hisi_sas folder is still remain after the probe failed. When probe fail, we should delete debugfs folder to avoid the above issue. Link: https://lore.kernel.org/r/1571926105-74636-18-git-send-email-john.garry@huawei.com Signed-off-by: Luo Jiaxing Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e9eb98caa072a8bdad33b9fc6799e386fe8ee33f Author: Xiang Chen Date: Thu Oct 24 22:08:11 2019 +0800 scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec() [ Upstream commit 550c0d89d52d3bec5c299f69b4ed5d2ee6b8a9a6 ] For IOs from upper layer, preemption may be disabled as it may be called by function __blk_mq_delay_run_hw_queue which will call get_cpu() (it disables preemption). So if flags HISI_SAS_REJECT_CMD_BIT is set in function hisi_sas_task_exec(), it may disable preempt twice after down() and up() which will cause following call trace: BUG: scheduling while atomic: fio/60373/0x00000002 Call trace: dump_backtrace+0x0/0x150 show_stack+0x24/0x30 dump_stack+0xa0/0xc4 __schedule_bug+0x68/0x88 __schedule+0x4b8/0x548 schedule+0x40/0xd0 schedule_timeout+0x200/0x378 __down+0x78/0xc8 down+0x54/0x70 hisi_sas_task_exec.isra.10+0x598/0x8d8 [hisi_sas_main] hisi_sas_queue_command+0x28/0x38 [hisi_sas_main] sas_queuecommand+0x168/0x1b0 [libsas] scsi_queue_rq+0x2ac/0x980 blk_mq_dispatch_rq_list+0xb0/0x550 blk_mq_do_dispatch_sched+0x6c/0x110 blk_mq_sched_dispatch_requests+0x114/0x1d8 __blk_mq_run_hw_queue+0xb8/0x130 __blk_mq_delay_run_hw_queue+0x1c0/0x220 blk_mq_run_hw_queue+0xb0/0x128 blk_mq_sched_insert_requests+0xdc/0x208 blk_mq_flush_plug_list+0x1b4/0x3a0 blk_flush_plug_list+0xdc/0x110 blk_finish_plug+0x3c/0x50 blkdev_direct_IO+0x404/0x550 generic_file_read_iter+0x9c/0x848 blkdev_read_iter+0x50/0x78 aio_read+0xc8/0x170 io_submit_one+0x1fc/0x8d8 __arm64_sys_io_submit+0xdc/0x280 el0_svc_common.constprop.0+0xe0/0x1e0 el0_svc_handler+0x34/0x90 el0_svc+0x10/0x14 ... To solve the issue, check preemptible() to avoid disabling preempt multiple when flag HISI_SAS_REJECT_CMD_BIT is set. Link: https://lore.kernel.org/r/1571926105-74636-5-git-send-email-john.garry@huawei.com Signed-off-by: Xiang Chen Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e98014e8d3be09470f270e69dc38e3dcb55752e4 Author: Dan Carpenter Date: Sat Oct 19 11:59:13 2019 +0300 scsi: csiostor: Don't enable IRQs too early [ Upstream commit d6c9b31ac3064fbedf8961f120a4c117daa59932 ] These are called with IRQs disabled from csio_mgmt_tmo_handler() so we can't call spin_unlock_irq() or it will enable IRQs prematurely. Fixes: a3667aaed569 ("[SCSI] csiostor: Chelsio FCoE offload driver") Link: https://lore.kernel.org/r/20191019085913.GA14245@mwanda Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 00b111173ee81c9ffc6e9871a4adb5a047cefeb1 Author: James Smart Date: Fri Oct 18 14:18:20 2019 -0700 scsi: lpfc: Fix SLI3 hba in loop mode not discovering devices [ Upstream commit feff8b3d84d3d9570f893b4d83e5eab6693d6a52 ] When operating in private loop mode, PLOGI exchanges are racing and the driver tries to abort it's PLOGI. But the PLOGI abort ends up terminating the login with the other end causing the other end to abort its PLOGI as well. Discovery never fully completes. Fix by disabling the PLOGI abort when private loop and letting the state machine play out. Link: https://lore.kernel.org/r/20191018211832.7917-5-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 41f66da6d49941c331b26fa49dc83342149eac9e Author: James Smart Date: Fri Oct 18 14:18:22 2019 -0700 scsi: lpfc: Fix hardlockup in lpfc_abort_handler [ Upstream commit 91a52b617cdb8bf6d298892101c061d438b84a19 ] In lpfc_abort_handler, the lock acquire order is hbalock (irqsave), buf_lock (irq) and ring_lock (irq). The issue is that in two places the locks are released out of order - the buf_lock and the hbalock - resulting in the cpu preemption/lock flags getting restored out of order and deadlocking the cpu. Fix the unlock order by fully releasing the hbalocks as well. CC: Zhangguanghui Link: https://lore.kernel.org/r/20191018211832.7917-7-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ebe87052a72c3c09a09ace2b3f078319fa147d8e Author: David Disseldorp Date: Thu Sep 12 11:55:45 2019 +0200 scsi: target: compare full CHAP_A Algorithm strings [ Upstream commit 9cef2a7955f2754257a7cddedec16edae7b587d0 ] RFC 2307 states: For CHAP [RFC1994], in the first step, the initiator MUST send: CHAP_A= Where A1,A2... are proposed algorithms, in order of preference. ... For the Algorithm, as stated in [RFC1994], one value is required to be implemented: 5 (CHAP with MD5) LIO currently checks for this value by only comparing a single byte in the tokenized Algorithm string, which means that any value starting with a '5' (e.g. "55") is interpreted as "CHAP with MD5". Fix this by comparing the entire tokenized string. Reviewed-by: Lee Duncan Reviewed-by: Mike Christie Signed-off-by: David Disseldorp Link: https://lore.kernel.org/r/20190912095547.22427-2-ddiss@suse.de Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 2456880b7a89bcd3a9369134c6fdeef9942bc1cb Author: Nicholas Graumann Date: Tue Oct 15 20:18:24 2019 +0530 dmaengine: xilinx_dma: Clear desc_pendingcount in xilinx_dma_reset [ Upstream commit 8a631a5a0f7d4a4a24dba8587d5d9152be0871cc ] Whenever we reset the channel, we need to clear desc_pendingcount along with desc_submitcount. Otherwise when a new transaction is submitted, the irq coalesce level could be programmed to an incorrect value in the axidma case. This behavior can be observed when terminating pending transactions with xilinx_dma_terminate_all() and then submitting new transactions without releasing and requesting the channel. Signed-off-by: Nicholas Graumann Signed-off-by: Radhey Shyam Pandey Link: https://lore.kernel.org/r/1571150904-3988-8-git-send-email-radhey.shyam.pandey@xilinx.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit d23e93e7fe1cbbec070c891dc9020a7dc909820c Author: Thierry Reding Date: Wed Oct 16 13:50:26 2019 +0200 iommu/tegra-smmu: Fix page tables in > 4 GiB memory [ Upstream commit 96d3ab802e4930a29a33934373157d6dff1b2c7e ] Page tables that reside in physical memory beyond the 4 GiB boundary are currently not working properly. The reason is that when the physical address for page directory entries is read, it gets truncated at 32 bits and can cause crashes when passing that address to the DMA API. Fix this by first casting the PDE value to a dma_addr_t and then using the page frame number mask for the SMMU instance to mask out the invalid bits, which are typically used for mapping attributes, etc. Signed-off-by: Thierry Reding Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 4f43e37b582dfeb118e09790e49d07d86e379d37 Author: Ezequiel Garcia Date: Wed Oct 2 14:29:23 2019 -0300 iommu: rockchip: Free domain on .domain_free [ Upstream commit 42bb97b80f2e3bf592e3e99d109b67309aa1b30e ] IOMMU domain resource life is well-defined, managed by .domain_alloc and .domain_free. Therefore, domain-specific resources shouldn't be tied to the device life, but instead to its domain. Signed-off-by: Ezequiel Garcia Reviewed-by: Robin Murphy Acked-by: Heiko Stuebner Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 28b491943c61cff2f3c11dd669b1b09a38ca3b2d Author: Dmitry Torokhov Date: Tue Oct 1 11:58:22 2019 -0700 platform/x86: peaq-wmi: switch to using polled mode of input devices [ Upstream commit 60d15095336cfb56dce5c7767ed3b8c6c1cf79a3 ] We have added polled mode to the normal input devices with the intent of retiring input_polled_dev. This converts peaq-wmi driver to use the polling mode of standard input devices and removes dependency on INPUT_POLLDEV. Because the new polling coded does not allow peeking inside the poller structure to get the poll interval, we change the "debounce" process to operate on the time basis, instead of counting events. We also fix error handling during initialization, as previously we leaked input device structure when we failed to register it. Signed-off-by: Dmitry Torokhov Reviewed-by: Hans de Goede Tested-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 9595fb752cdb3c3b007f6c0f2ec9c542c02f9032 Author: Srinivas Pandruvada Date: Thu Oct 10 13:29:36 2019 -0700 tools/power/x86/intel-speed-select: Remove warning for unused result [ Upstream commit abd120e3bdf3dd72ba1ed9ac077a861e0e3dc43a ] Fix warning for: isst-config.c: In function ‘set_cpu_online_offline’: isst-config.c:221:3: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused-result] write(fd, "1\n", 2); Signed-off-by: Srinivas Pandruvada Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit f42248ded31da34136098e713145bc41203c9b2b Author: Vaibhav Jain Date: Fri Sep 27 11:50:02 2019 +0530 powerpc/papr_scm: Fix an off-by-one check in papr_scm_meta_{get, set} [ Upstream commit 612ee81b9461475b5a5612c2e8d71559dd3c7920 ] A validation check to prevent out of bounds read/write inside functions papr_scm_meta_{get,set}() is off-by-one that prevent reads and writes to the last byte of the label area. This bug manifests as a failure to probe a dimm when libnvdimm is unable to read the entire config-area as advertised by ND_CMD_GET_CONFIG_SIZE. This usually happens when there are large number of namespaces created in the region backed by the dimm and the label-index spans max possible config-area. An error of the form below usually reported in the kernel logs: [ 255.293912] nvdimm: probe of nmem0 failed with error -22 The patch fixes these validation checks there by letting libnvdimm access the entire config-area. Fixes: 53e80bd042773('powerpc/nvdimm: Add support for multibyte read/write for metadata') Signed-off-by: Vaibhav Jain Reviewed-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190927062002.3169-1-vaibhav@linux.ibm.com Signed-off-by: Sasha Levin commit 0d4e226f662aa73fa38d6f6025aaa6edd7e4ed61 Author: Chao Yu Date: Fri Sep 27 18:01:35 2019 +0800 f2fs: fix to update time in lazytime mode [ Upstream commit fe1897eaa6646f5a64a4cee0e6473ed9887d324b ] generic/018 reports an inconsistent status of atime, the testcase is as below: - open file with O_SYNC - write file to construct fraged space - calc md5 of file - record {a,c,m}time - defrag file --- do nothing - umount & mount - check {a,c,m}time The root cause is, as f2fs enables lazytime by default, atime update will dirty vfs inode, rather than dirtying f2fs inode (by set with FI_DIRTY_INODE), so later f2fs_write_inode() called from VFS will fail to update inode page due to our skip: f2fs_write_inode() if (is_inode_flag_set(inode, FI_DIRTY_INODE)) return 0; So eventually, after evict(), we lose last atime for ever. To fix this issue, we need to check whether {a,c,m,cr}time is consistent in between inode cache and inode page, and only skip f2fs_update_inode() if f2fs inode is not dirty and time is consistent as well. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit fac68e77e87e56f679be6d60acc8494fc7662116 Author: Evan Green Date: Wed Oct 2 14:00:21 2019 -0700 Input: atmel_mxt_ts - disable IRQ across suspend [ Upstream commit 463fa44eec2fef50d111ed0199cf593235065c04 ] Across suspend and resume, we are seeing error messages like the following: atmel_mxt_ts i2c-PRP0001:00: __mxt_read_reg: i2c transfer failed (-121) atmel_mxt_ts i2c-PRP0001:00: Failed to read T44 and T5 (-121) This occurs because the driver leaves its IRQ enabled. Upon resume, there is an IRQ pending, but the interrupt is serviced before both the driver and the underlying I2C bus have been resumed. This causes EREMOTEIO errors. Disable the IRQ in suspend, and re-enable it on resume. If there are cases where the driver enters suspend with interrupts disabled, that's a bug we should fix separately. Signed-off-by: Evan Green Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit 03d0de2da8806a801c7f1d3e1f113f2a5aeec745 Author: James Smart Date: Sat Sep 21 20:58:59 2019 -0700 scsi: lpfc: Fix list corruption in lpfc_sli_get_iocbq [ Upstream commit 15498dc1a55b7aaea4b51ff03e3ff0f662e73f44 ] After study, it was determined there was a double free of a CT iocb during execution of lpfc_offline_prep and lpfc_offline. The prep routine issued an abort for some CT iocbs, but the aborts did not complete fast enough for a subsequent routine that waits for completion. Thus the driver proceeded to lpfc_offline, which releases any pending iocbs. Unfortunately, the completions for the aborts were then received which re-released the ct iocbs. Turns out the issue for why the aborts didn't complete fast enough was not their time on the wire/in the adapter. It was the lpfc_work_done routine, which requires the adapter state to be UP before it calls lpfc_sli_handle_slow_ring_event() to process the completions. The issue is the prep routine takes the link down as part of it's processing. To fix, the following was performed: - Prevent the offline routine from releasing iocbs that have had aborts issued on them. Defer to the abort completions. Also means the driver fully waits for the completions. Given this change, the recognition of "driver-generated" status which then releases the iocb is no longer valid. As such, the change made in the commit 296012285c90 is reverted. As recognition of "driver-generated" status is no longer valid, this patch reverts the changes made in commit 296012285c90 ("scsi: lpfc: Fix leak of ELS completions on adapter reset") - Modify lpfc_work_done to allow slow path completions so that the abort completions aren't ignored. - Updated the fdmi path to recognize a CT request that fails due to the port being unusable. This stops FDMI retries. FDMI will be restarted on next link up. Link: https://lore.kernel.org/r/20190922035906.10977-14-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 1c85192b4b0a1b8a5f53752e4a60a3b384dc871c Author: Anson Huang Date: Thu Sep 19 17:39:17 2019 +0800 gpio: mxc: Only get the second IRQ when there is more than one IRQ [ Upstream commit c8f3d144004dd3f471ffd414690d15a005e4acd6 ] On some of i.MX SoCs like i.MX8QXP, there is ONLY one IRQ for each GPIO bank, so it is better to check the IRQ count before getting second IRQ to avoid below error message during probe: [ 1.070908] gpio-mxc 5d080000.gpio: IRQ index 1 not found [ 1.077420] gpio-mxc 5d090000.gpio: IRQ index 1 not found [ 1.083766] gpio-mxc 5d0a0000.gpio: IRQ index 1 not found [ 1.090122] gpio-mxc 5d0b0000.gpio: IRQ index 1 not found [ 1.096470] gpio-mxc 5d0c0000.gpio: IRQ index 1 not found [ 1.102804] gpio-mxc 5d0d0000.gpio: IRQ index 1 not found [ 1.109144] gpio-mxc 5d0e0000.gpio: IRQ index 1 not found [ 1.115475] gpio-mxc 5d0f0000.gpio: IRQ index 1 not found Signed-off-by: Anson Huang Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 08f9773f3db4d07e6eb3cac5eae2591bef062cfe Author: Sreekanth Reddy Date: Fri Sep 13 09:04:48 2019 -0400 scsi: mpt3sas: Reject NVMe Encap cmnds to unsupported HBA [ Upstream commit 77fd4f2c88bf83205a21f9ca49fdcc0c7868dba9 ] If any faulty application issues an NVMe Encapsulated commands to HBA which doesn't support NVMe protocol then driver should return the command as invalid with the following message. "HBA doesn't support NVMe. Rejecting NVMe Encapsulated request." Otherwise below page fault kernel panic will be observed while building the PRPs as there is no PRP pools allocated for the HBA which doesn't support NVMe drives. RIP: 0010:_base_build_nvme_prp+0x3b/0xf0 [mpt3sas] Call Trace: _ctl_do_mpt_command+0x931/0x1120 [mpt3sas] _ctl_ioctl_main.isra.11+0xa28/0x11e0 [mpt3sas] ? prepare_to_wait+0xb0/0xb0 ? tty_ldisc_deref+0x16/0x20 _ctl_ioctl+0x1a/0x20 [mpt3sas] do_vfs_ioctl+0xaa/0x620 ? vfs_read+0x117/0x140 ksys_ioctl+0x67/0x90 __x64_sys_ioctl+0x1a/0x20 do_syscall_64+0x60/0x190 entry_SYSCALL_64_after_hwframe+0x44/0xa9 [mkp: tweaked error string] Link: https://lore.kernel.org/r/1568379890-18347-12-git-send-email-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit a51f92387fdbd11930ec4cedcfd442d6ab301288 Author: James Smart Date: Sat Sep 21 20:58:53 2019 -0700 scsi: lpfc: Fix locking on mailbox command completion [ Upstream commit 07b8582430370097238b589f4e24da7613ca6dd3 ] Symptoms were seen of the driver not having valid data for mailbox commands. After debugging, the following sequence was found: The driver maintains a port-wide pointer of the mailbox command that is currently in execution. Once finished, the port-wide pointer is cleared (done in lpfc_sli4_mq_release()). The next mailbox command issued will set the next pointer and so on. The mailbox response data is only copied if there is a valid port-wide pointer. In the failing case, it was seen that a new mailbox command was being attempted in parallel with the completion. The parallel path was seeing the mailbox no long in use (flag check under lock) and thus set the port pointer. The completion path had cleared the active flag under lock, but had not touched the port pointer. The port pointer is cleared after the lock is released. In this case, the completion path cleared the just-set value by the parallel path. Fix by making the calls that clear mbox state/port pointer while under lock. Also slightly cleaned up the error path. Link: https://lore.kernel.org/r/20190922035906.10977-8-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit dc1f1460545c52fc61ded21ef5f736149f5601e1 Author: Sreekanth Reddy Date: Fri Sep 13 09:04:40 2019 -0400 scsi: mpt3sas: Fix clear pending bit in ioctl status [ Upstream commit 782b281883caf70289ba6a186af29441a117d23e ] When user issues diag register command from application with required size, and if driver unable to allocate the memory, then it will fail the register command. While failing the register command, driver is not currently clearing MPT3_CMD_PENDING bit in ctl_cmds.status variable which was set before trying to allocate the memory. As this bit is set, subsequent register command will be failed with BUSY status even when user wants to register the trace buffer will less memory. Clear MPT3_CMD_PENDING bit in ctl_cmds.status before returning the diag register command with no memory status. Link: https://lore.kernel.org/r/1568379890-18347-4-git-send-email-sreekanth.reddy@broadcom.com Signed-off-by: Sreekanth Reddy Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fe35d5a4fad9d379d93a019923e0ebac1968c65a Author: James Smart Date: Sat Sep 21 20:58:55 2019 -0700 scsi: lpfc: Fix discovery failures when target device connectivity bounces [ Upstream commit 3f97aed6117c7677eb16756c4ec8b86000fd5822 ] An issue was seen discovering all SCSI Luns when a target device undergoes link bounce. The driver currently does not qualify the FC4 support on the target. Therefore it will send a SCSI PRLI and an NVMe PRLI. The expectation is that the target will reject the PRLI if it is not supported. If a PRLI times out, the driver will retry. The driver will not proceed with the device until both SCSI and NVMe PRLIs are resolved. In the failure case, the device is FCP only and does not respond to the NVMe PRLI, thus initiating the wait/retry loop in the driver. During that time, a RSCN is received (device bounced) causing the driver to issue a GID_FT. The GID_FT response comes back before the PRLI mess is resolved and it prematurely cancels the PRLI retry logic and leaves the device in a STE_PRLI_ISSUE state. Discovery with the target never completes or resets. Fix by resetting the node state back to STE_NPR_NODE when GID_FT completes, thereby restarting the discovery process for the node. Link: https://lore.kernel.org/r/20190922035906.10977-10-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 45331ad46993af173244628517986ddf3ebdbe38 Author: James Smart Date: Sat Sep 21 20:59:00 2019 -0700 scsi: lpfc: Fix spinlock_irq issues in lpfc_els_flush_cmd() [ Upstream commit d38b4a527fe898f859f74a3a43d4308f48ac7855 ] While reviewing the CT behavior, issues with spinlock_irq were seen. The driver should be using spinlock_irqsave/irqrestore in the els flush routine. Changed to spinlock_irqsave/irqrestore. Link: https://lore.kernel.org/r/20190922035906.10977-15-jsmart2021@gmail.com Signed-off-by: Dick Kennedy Signed-off-by: James Smart Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit ffe485232df06b3cbb933d02aeb8965fd1ddca61 Author: Greg Kroah-Hartman Date: Tue Dec 31 18:08:46 2019 +0100 Revert "MIPS: futex: Emit Loongson3 sync workarounds within asm" This reverts commit d754a529a8be55f009c6679d772c472c1632cd5b which was commit 3c1d3f0979721a39dd2980c97466127ce65aa130 upstream. This breaks the build and should be reverted. Cc: Guenter Roeck Cc: Paul Burton Cc: linux-mips@vger.kernel.org Cc: Huacai Chen Cc: Jiaxun Yang Cc: linux-kernel@vger.kernel.org Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 03ad5d55bea1fb58735eff1a9a0aaa34c230f357 Author: Greg Kroah-Hartman Date: Tue Dec 31 18:04:17 2019 +0100 Revert "MIPS: futex: Restore \n after sync instructions" This reverts commit dc9d0a75ce9af74612d6a4d052e4df2bddfe8ed4 which is commit fd7710cb491f900eb63d2ce5aac0e682003e84e9 upstream. This, and the follow-on patch, breaks the mips build so it needs to be reverted. Reported-by: Guenter Roeck Cc: Paul Burton Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 122179cb7d648a6f36b20dd6bf34f953cb384c30 Author: Greg Kroah-Hartman Date: Tue Dec 31 16:46:36 2019 +0100 Linux 5.4.7 commit f5d43e9ec18de582351f1d239d3e88465fd6d009 Author: Luca Coelho Date: Thu Dec 5 09:03:54 2019 +0200 iwlwifi: pcie: move power gating workaround earlier in the flow commit 0df36b90c47d93295b7e393da2d961b2f3b6cde4 upstream. We need to reset the NIC after setting the bits to enable power gating and that cannot be done too late in the flow otherwise it cleans other registers and things that were already configured, causing initialization to fail. In order to fix this, move the function to the common code in trans.c so it can be called directly from there at an earlier point, just after the reset we already do during initialization. Fixes: 9a47cb988338 ("iwlwifi: pcie: add workaround for power gating in integrated 22000") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=205719 Cc: stable@ver.kernel.org # 5.4+ Reported-by: Anders Kaseorg Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Greg Kroah-Hartman commit b3ead320dce6c7d7206103deca766b317591c286 Author: Mike Christie Date: Sun Dec 8 16:51:50 2019 -0600 nbd: fix shutdown and recv work deadlock v2 commit 1c05839aa973cfae8c3db964a21f9c0eef8fcc21 upstream. This fixes a regression added with: commit e9e006f5fcf2bab59149cb38a48a4817c1b538b4 Author: Mike Christie Date: Sun Aug 4 14:10:06 2019 -0500 nbd: fix max number of supported devs where we can deadlock during device shutdown. The problem occurs if the recv_work's nbd_config_put occurs after nbd_start_device_ioctl has returned and the userspace app has droppped its reference via closing the device and running nbd_release. The recv_work nbd_config_put call would then drop the refcount to zero and try to destroy the config which would try to do destroy_workqueue from the recv work. This patch just has nbd_start_device_ioctl do a flush_workqueue when it wakes so we know after the ioctl returns running works have exited. This also fixes a possible race where we could try to reuse the device while old recv_works are still running. Cc: stable@vger.kernel.org Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs") Signed-off-by: Mike Christie Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 10448fb57940c939ac609778e664243882258573 Author: Adrian Hunter Date: Tue Dec 17 11:53:49 2019 +0200 mmc: sdhci: Add a quirk for broken command queuing commit 75d27ea1abf7af3cc2cdec3513e74f52191605c8 upstream. Command queuing has been reported broken on some systems based on Intel GLK. A separate patch disables command queuing in some cases. This patch adds a quirk for broken command queuing, which enables users with problems to disable command queuing using sdhci module parameters for quirks. Fixes: 8ee82bda230f ("mmc: sdhci-pci: Add CQHCI support for Intel GLK") Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191217095349.14592-2-adrian.hunter@intel.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 79a466d43b595571f223fbd0cd95585d5c9ad7a2 Author: Adrian Hunter Date: Tue Dec 17 11:53:48 2019 +0200 mmc: sdhci: Workaround broken command queuing on Intel GLK commit bedf9fc01ff1f40cfd1a79ccacedd9f3cd8e652a upstream. Command queuing has been reported broken on some Lenovo systems based on Intel GLK. This is likely a BIOS issue, so disable command queuing for Intel GLK if the BIOS vendor string is "LENOVO". Fixes: 8ee82bda230f ("mmc: sdhci-pci: Add CQHCI support for Intel GLK") Signed-off-by: Adrian Hunter Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191217095349.14592-1-adrian.hunter@intel.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit d5c5ce6b2fa928ac3a3814bd751c07179132b90b Author: Yangbo Lu Date: Mon Dec 16 11:18:42 2019 +0800 mmc: sdhci-of-esdhc: fix P2020 errata handling commit fe0acab448f68c3146235afe03fb932e242ec94c upstream. Two previous patches introduced below quirks for P2020 platforms. - SDHCI_QUIRK_RESET_AFTER_REQUEST - SDHCI_QUIRK_BROKEN_TIMEOUT_VAL The patches made a mistake to add them in quirks2 of sdhci_host structure, while they were defined for quirks. host->quirks2 |= SDHCI_QUIRK_RESET_AFTER_REQUEST; host->quirks2 |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; This patch is to fix them. host->quirks |= SDHCI_QUIRK_RESET_AFTER_REQUEST; host->quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL; Fixes: 05cb6b2a66fa ("mmc: sdhci-of-esdhc: add erratum eSDHC-A001 and A-008358 support") Fixes: a46e42712596 ("mmc: sdhci-of-esdhc: add erratum eSDHC5 support") Signed-off-by: Yangbo Lu Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191216031842.40068-1-yangbo.lu@nxp.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit ecfcddc0f1101fcab3debba2829e306d1466cd48 Author: Faiz Abbas Date: Fri Dec 6 17:13:26 2019 +0530 mmc: sdhci: Update the tuning failed messages to pr_debug level commit 2c92dd20304f505b6ef43d206fff21bda8f1f0ae upstream. Tuning support in DDR50 speed mode was added in SD Specifications Part1 Physical Layer Specification v3.01. Its not possible to distinguish between v3.00 and v3.01 from the SCR and that is why since commit 4324f6de6d2e ("mmc: core: enable CMD19 tuning for DDR50 mode") tuning failures are ignored in DDR50 speed mode. Cards compatible with v3.00 don't respond to CMD19 in DDR50 and this error gets printed during enumeration and also if retune is triggered at any time during operation. Update the printk level to pr_debug so that these errors don't lead to false error reports. Signed-off-by: Faiz Abbas Cc: stable@vger.kernel.org # v4.4+ Link: https://lore.kernel.org/r/20191206114326.15856-1-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 7f41c3f3346a60e76f0ccafff9d73d50ed175aa9 Author: Rasmus Villemoes Date: Wed Dec 4 09:54:46 2019 +0100 mmc: sdhci-of-esdhc: Revert "mmc: sdhci-of-esdhc: add erratum A-009204 support" commit 8b6dc6b2d60221e90703babbc141f063b8a07e72 upstream. This reverts commit 5dd195522562542bc6ebe6e7bd47890d8b7ca93c. First, the fix seems to be plain wrong, since the erratum suggests waiting 5ms before setting setting SYSCTL[RSTD], but this msleep() happens after the call of sdhci_reset() which is where that bit gets set (if SDHCI_RESET_DATA is in mask). Second, walking the whole device tree to figure out if some node has a "fsl,p2020-esdhc" compatible string is hugely expensive - about 70 to 100 us on our mpc8309 board. Walking the device tree is done under a raw_spin_lock, so this is obviously really bad on an -rt system, and a waste of time on all. In fact, since esdhc_reset() seems to get called around 100 times per second, that mpc8309 now spends 0.8% of its time determining that it is not a p2020. Whether those 100 calls/s are normal or due to some other bug or misconfiguration, regularly hitting a 100 us non-preemptible window is unacceptable. Signed-off-by: Rasmus Villemoes Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191204085447.27491-1-linux@rasmusvillemoes.dk Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit c1956990740cb51f805e8048d8b4084c1aacefa5 Author: Veerabhadrarao Badiganti Date: Tue Nov 26 10:19:16 2019 +0000 mmc: sdhci-msm: Correct the offset and value for DDR_CONFIG register commit fa56ac9792265354b565f28def7164e7d7db2b1e upstream. The DDR_CONFIG register offset got updated after a specific minor version of sdcc V4. This offset change has not been properly taken care of while updating register changes for sdcc V5. Correcting proper offset for this register. Also updating this register value to reflect the recommended RCLK delay. Signed-off-by: Veerabhadrarao Badiganti Link: https://lore.kernel.org/r/0101016ea738ec72-fa0f852d-20f8-474a-80b2-4b0ef63b132c-000000@us-west-2.amazonses.com Fixes: f15358885dda ("mmc: sdhci-msm: Define new Register address map") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit bd0b65dbb1b58a4eb0ea0b8ce6a330b3bc9376ed Author: Frederic Barrat Date: Mon Jun 24 16:41:48 2019 +0200 ocxl: Fix concurrent AFU open and device removal commit a58d37bce0d21cf7fbd589384c619e465ef2f927 upstream. If an ocxl device is unbound through sysfs at the same time its AFU is being opened by a user process, the open code may dereference freed stuctures, which can lead to kernel oops messages. You'd have to hit a tiny time window, but it's possible. It's fairly easy to test by making the time window bigger artificially. Fix it with a combination of 2 changes: - when an AFU device is found in the IDR by looking for the device minor number, we should hold a reference on the device until after the context is allocated. A reference on the AFU structure is kept when the context is allocated, so we can release the reference on the device after the context allocation. - with the fix above, there's still another even tinier window, between the time the AFU device is found in the IDR and the reference on the device is taken. We can fix this one by removing the IDR entry earlier, when the device setup is removed, instead of waiting for the 'release' device callback. With proper locking around the IDR. Fixes: 75ca758adbaf ("ocxl: Create a clear delineation between ocxl backend & frontend") Cc: stable@vger.kernel.org # v5.2+ Signed-off-by: Frederic Barrat Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20190624144148.32022-1-fbarrat@linux.ibm.com Signed-off-by: Greg Kroah-Hartman commit 1eda17449e6c85cad0cd1bad995623a65a060057 Author: Christophe Leroy Date: Mon Dec 9 06:19:08 2019 +0000 powerpc/irq: fix stack overflow verification commit 099bc4812f09155da77eeb960a983470249c9ce1 upstream. Before commit 0366a1c70b89 ("powerpc/irq: Run softirqs off the top of the irq stack"), check_stack_overflow() was called by do_IRQ(), before switching to the irq stack. In that commit, do_IRQ() was renamed __do_irq(), and is now executing on the irq stack, so check_stack_overflow() has just become almost useless. Move check_stack_overflow() call in do_IRQ() to do the check while still on the current stack. Fixes: 0366a1c70b89 ("powerpc/irq: Run softirqs off the top of the irq stack") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/e033aa8116ab12b7ca9a9c75189ad0741e3b9b5f.1575872340.git.christophe.leroy@c-s.fr Signed-off-by: Greg Kroah-Hartman commit 8332dbe5157a0056d8ab409957dfa89930066d87 Author: Srikar Dronamraju Date: Thu Dec 5 14:02:17 2019 +0530 powerpc/vcpu: Assume dedicated processors as non-preempt commit 14c73bd344da60abaf7da3ea2e7733ddda35bbac upstream. With commit 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs"), the scheduler avoids preempted vCPUs to schedule tasks on wakeup. This leads to wrong choice of CPU, which in-turn leads to larger wakeup latencies. Eventually, it leads to performance regression in latency sensitive benchmarks like soltp, schbench etc. On Powerpc, vcpu_is_preempted() only looks at yield_count. If the yield_count is odd, the vCPU is assumed to be preempted. However yield_count is increased whenever the LPAR enters CEDE state (idle). So any CPU that has entered CEDE state is assumed to be preempted. Even if vCPU of dedicated LPAR is preempted/donated, it should have right of first-use since they are supposed to own the vCPU. On a Power9 System with 32 cores: # lscpu Architecture: ppc64le Byte Order: Little Endian CPU(s): 128 On-line CPU(s) list: 0-127 Thread(s) per core: 8 Core(s) per socket: 1 Socket(s): 16 NUMA node(s): 2 Model: 2.2 (pvr 004e 0202) Model name: POWER9 (architected), altivec supported Hypervisor vendor: pHyp Virtualization type: para L1d cache: 32K L1i cache: 32K L2 cache: 512K L3 cache: 10240K NUMA node0 CPU(s): 0-63 NUMA node1 CPU(s): 64-127 # perf stat -a -r 5 ./schbench v5.4 v5.4 + patch Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 45 75.0000th: 62 75.0th: 63 90.0000th: 71 90.0th: 74 95.0000th: 77 95.0th: 78 *99.0000th: 91 *99.0th: 82 99.5000th: 707 99.5th: 83 99.9000th: 6920 99.9th: 86 min=0, max=10048 min=0, max=96 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 46 75.0000th: 61 75.0th: 64 90.0000th: 72 90.0th: 75 95.0000th: 79 95.0th: 79 *99.0000th: 691 *99.0th: 83 99.5000th: 3972 99.5th: 85 99.9000th: 8368 99.9th: 91 min=0, max=16606 min=0, max=117 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 46 75.0000th: 61 75.0th: 64 90.0000th: 71 90.0th: 75 95.0000th: 77 95.0th: 79 *99.0000th: 106 *99.0th: 83 99.5000th: 2364 99.5th: 84 99.9000th: 7480 99.9th: 90 min=0, max=10001 min=0, max=95 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 45 50.0th: 47 75.0000th: 62 75.0th: 65 90.0000th: 72 90.0th: 75 95.0000th: 78 95.0th: 79 *99.0000th: 93 *99.0th: 84 99.5000th: 108 99.5th: 85 99.9000th: 6792 99.9th: 90 min=0, max=17681 min=0, max=117 Latency percentiles (usec) Latency percentiles (usec) 50.0000th: 46 50.0th: 45 75.0000th: 62 75.0th: 64 90.0000th: 73 90.0th: 75 95.0000th: 79 95.0th: 79 *99.0000th: 113 *99.0th: 82 99.5000th: 2724 99.5th: 83 99.9000th: 6184 99.9th: 93 min=0, max=9887 min=0, max=111 Performance counter stats for 'system wide' (5 runs): context-switches 43,373 ( +- 0.40% ) 44,597 ( +- 0.55% ) cpu-migrations 1,211 ( +- 5.04% ) 220 ( +- 6.23% ) page-faults 15,983 ( +- 5.21% ) 15,360 ( +- 3.38% ) Waiman Long suggested using static_keys. Fixes: 247f2f6f3c70 ("sched/core: Don't schedule threads on pre-empted vCPUs") Cc: stable@vger.kernel.org # v4.18+ Reported-by: Parth Shah Reported-by: Ihor Pasichnyk Tested-by: Juri Lelli Acked-by: Waiman Long Reviewed-by: Gautham R. Shenoy Signed-off-by: Srikar Dronamraju Acked-by: Phil Auld Reviewed-by: Vaidyanathan Srinivasan Tested-by: Parth Shah [mpe: Move the key and setting of the key to pseries/setup.c] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191213035036.6913-1-mpe@ellerman.id.au Signed-off-by: Greg Kroah-Hartman commit 931300aac9adbebeedd50cb6ab879133c2e988f9 Author: Jan H. Schönherr Date: Tue Dec 10 01:07:30 2019 +0100 x86/mce: Fix possibly incorrect severity calculation on AMD commit a3a57ddad061acc90bef39635caf2b2330ce8f21 upstream. The function mce_severity_amd_smca() requires m->bank to be initialized for correct operation. Fix the one case, where mce_severity() is called without doing so. Fixes: 6bda529ec42e ("x86/mce: Grade uncorrected errors for SMCA-enabled systems") Fixes: d28af26faa0b ("x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out()") Signed-off-by: Jan H. Schönherr Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-edac Cc: Cc: Thomas Gleixner Cc: x86-ml Cc: Yazen Ghannam Link: https://lkml.kernel.org/r/20191210000733.17979-4-jschoenh@amazon.de Signed-off-by: Greg Kroah-Hartman commit 86287a1f65ab827859ea1106379efdb43eb7080d Author: Yazen Ghannam Date: Thu Nov 21 08:15:08 2019 -0600 x86/MCE/AMD: Allow Reserved types to be overwritten in smca_banks[] commit 966af20929ac24360ba3fac5533eb2ab003747da upstream. Each logical CPU in Scalable MCA systems controls a unique set of MCA banks in the system. These banks are not shared between CPUs. The bank types and ordering will be the same across CPUs on currently available systems. However, some CPUs may see a bank as Reserved/Read-as-Zero (RAZ) while other CPUs do not. In this case, the bank seen as Reserved on one CPU is assumed to be the same type as the bank seen as a known type on another CPU. In general, this occurs when the hardware represented by the MCA bank is disabled, e.g. disabled memory controllers on certain models, etc. The MCA bank is disabled in the hardware, so there is no possibility of getting an MCA/MCE from it even if it is assumed to have a known type. For example: Full system: Bank | Type seen on CPU0 | Type seen on CPU1 ------------------------------------------------ 0 | LS | LS 1 | UMC | UMC 2 | CS | CS System with hardware disabled: Bank | Type seen on CPU0 | Type seen on CPU1 ------------------------------------------------ 0 | LS | LS 1 | UMC | RAZ 2 | CS | CS For this reason, there is a single, global struct smca_banks[] that is initialized at boot time. This array is initialized on each CPU as it comes online. However, the array will not be updated if an entry already exists. This works as expected when the first CPU (usually CPU0) has all possible MCA banks enabled. But if the first CPU has a subset, then it will save a "Reserved" type in smca_banks[]. Successive CPUs will then not be able to update smca_banks[] even if they encounter a known bank type. This may result in unexpected behavior. Depending on the system configuration, a user may observe issues enumerating the MCA thresholding sysfs interface. The issues may be as trivial as sysfs entries not being available, or as severe as system hangs. For example: Bank | Type seen on CPU0 | Type seen on CPU1 ------------------------------------------------ 0 | LS | LS 1 | RAZ | UMC 2 | CS | CS Extend the smca_banks[] entry check to return if the entry is a non-reserved type. Otherwise, continue so that CPUs that encounter a known bank type can update smca_banks[]. Fixes: 68627a697c19 ("x86/mce/AMD, EDAC/mce_amd: Enumerate Reserved SMCA bank type") Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-edac Cc: Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20191121141508.141273-1-Yazen.Ghannam@amd.com Signed-off-by: Greg Kroah-Hartman commit 9bea3539a2ea429f8cd6fac64dde026d7e3173a8 Author: Konstantin Khlebnikov Date: Thu Oct 31 16:04:48 2019 +0300 x86/MCE/AMD: Do not use rdmsr_safe_on_cpu() in smca_configure() commit 246ff09f89e54fdf740a8d496176c86743db3ec7 upstream. ... because interrupts are disabled that early and sending IPIs can deadlock: BUG: sleeping function called from invalid context at kernel/sched/completion.c:99 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1 no locks held by swapper/1/0. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0x8b9/0x1ca0 softirqs last enabled at (0): [] copy_process+0x8b9/0x1ca0 softirqs last disabled at (0): [<0000000000000000>] 0x0 Preemption disabled at: [] start_secondary+0x3b/0x190 CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.5.0-rc2+ #1 Hardware name: GIGABYTE MZ01-CE1-00/MZ01-CE1-00, BIOS F02 08/29/2018 Call Trace: dump_stack ___might_sleep.cold.92 wait_for_completion ? generic_exec_single rdmsr_safe_on_cpu ? wrmsr_on_cpus mce_amd_feature_init mcheck_cpu_init identify_cpu identify_secondary_cpu smp_store_cpu_info start_secondary secondary_startup_64 The function smca_configure() is called only on the current CPU anyway, therefore replace rdmsr_safe_on_cpu() with atomic rdmsr_safe() and avoid the IPI. [ bp: Update commit message. ] Signed-off-by: Konstantin Khlebnikov Signed-off-by: Borislav Petkov Reviewed-by: Yazen Ghannam Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-edac Cc: Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/157252708836.3876.4604398213417262402.stgit@buzz Signed-off-by: Greg Kroah-Hartman commit 619799ebce0fdf18ecc084ed74f9d206018948d6 Author: Kai-Heng Feng Date: Fri Nov 29 14:23:02 2019 +0800 x86/intel: Disable HPET on Intel Coffee Lake H platforms commit f8edbde885bbcab6a2b4a1b5ca614e6ccb807577 upstream. Coffee Lake H SoC has similar behavior as Coffee Lake, skewed HPET timer once the SoCs entered PC10. So let's disable HPET on CFL-H platforms. Signed-off-by: Kai-Heng Feng Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: bp@alien8.de Cc: feng.tang@intel.com Cc: harry.pan@intel.com Cc: hpa@zytor.com Link: https://lkml.kernel.org/r/20191129062303.18982-1-kai.heng.feng@canonical.com Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 1767f1ec121640d56f6aeecd607719563b575ead Author: Will Deacon Date: Thu Dec 12 09:40:49 2019 +0000 KVM: arm64: Ensure 'params' is initialised when looking up sys register commit 1ce74e96c2407df2b5867e5d45a70aacb8923c14 upstream. Commit 4b927b94d5df ("KVM: arm/arm64: vgic: Introduce find_reg_by_id()") introduced 'find_reg_by_id()', which looks up a system register only if the 'id' index parameter identifies a valid system register. As part of the patch, existing callers of 'find_reg()' were ported over to the new interface, but this breaks 'index_to_sys_reg_desc()' in the case that the initial lookup in the vCPU target table fails because we will then call into 'find_reg()' for the system register table with an uninitialised 'param' as the key to the lookup. GCC 10 is bright enough to spot this (amongst a tonne of false positives, but hey!): | arch/arm64/kvm/sys_regs.c: In function ‘index_to_sys_reg_desc.part.0.isra’: | arch/arm64/kvm/sys_regs.c:983:33: warning: ‘params.Op2’ may be used uninitialized in this function [-Wmaybe-uninitialized] | 983 | (u32)(x)->CRn, (u32)(x)->CRm, (u32)(x)->Op2); | [...] Revert the hunk of 4b927b94d5df which breaks 'index_to_sys_reg_desc()' so that the old behaviour of checking the index upfront is restored. Fixes: 4b927b94d5df ("KVM: arm/arm64: vgic: Introduce find_reg_by_id()") Signed-off-by: Will Deacon Signed-off-by: Marc Zyngier Cc: Link: https://lore.kernel.org/r/20191212094049.12437-1-will@kernel.org Signed-off-by: Greg Kroah-Hartman commit 9408013caae6de84a2b137c7dab627a4bd4b8b7b Author: Marc Zyngier Date: Wed Dec 11 16:56:48 2019 +0000 KVM: arm/arm64: Properly handle faulting of device mappings commit 6d674e28f642e3ff676fbae2d8d1b872814d32b6 upstream. A device mapping is normally always mapped at Stage-2, since there is very little gain in having it faulted in. Nonetheless, it is possible to end-up in a situation where the device mapping has been removed from Stage-2 (userspace munmaped the VFIO region, and the MMU notifier did its job), but present in a userspace mapping (userpace has mapped it back at the same address). In such a situation, the device mapping will be demand-paged as the guest performs memory accesses. This requires to be careful when dealing with mapping size, cache management, and to handle potential execution of a device mapping. Reported-by: Alexandru Elisei Signed-off-by: Marc Zyngier Tested-by: Alexandru Elisei Reviewed-by: James Morse Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191211165651.7889-2-maz@kernel.org Signed-off-by: Greg Kroah-Hartman commit 7ea735683adcc53bb12f7a13dee07e31f751a2ef Author: Jim Mattson Date: Fri Dec 13 16:15:16 2019 -0800 kvm: x86: Host feature SSBD doesn't imply guest feature AMD_SSBD commit 8715f05269bfbc6453e25e80825d781a82902f8e upstream. The host reports support for the synthetic feature X86_FEATURE_SSBD when any of the three following hardware features are set: CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] CPUID.80000008H:EBX.AMD_SSBD[bit 24] CPUID.80000008H:EBX.VIRT_SSBD[bit 25] Either of the first two hardware features implies the existence of the IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does not. Therefore, CPUID.80000008H:EBX.AMD_SSBD[bit 24] should only be set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host. Fixes: 4c6903a0f9d76 ("KVM: x86: fix reporting of AMD speculation bug CPUID leaf") Signed-off-by: Jim Mattson Reviewed-by: Jacob Xu Reviewed-by: Peter Shier Cc: Paolo Bonzini Cc: stable@vger.kernel.org Reported-by: Eric Biggers Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit edaeb1133785d59ecaed273fa70217fb3dc74c28 Author: Jim Mattson Date: Fri Dec 13 16:15:15 2019 -0800 kvm: x86: Host feature SSBD doesn't imply guest feature SPEC_CTRL_SSBD commit 396d2e878f92ec108e4293f1c77ea3bc90b414ff upstream. The host reports support for the synthetic feature X86_FEATURE_SSBD when any of the three following hardware features are set: CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] CPUID.80000008H:EBX.AMD_SSBD[bit 24] CPUID.80000008H:EBX.VIRT_SSBD[bit 25] Either of the first two hardware features implies the existence of the IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does not. Therefore, CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] should only be set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host. Fixes: 0c54914d0c52a ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code") Signed-off-by: Jim Mattson Reviewed-by: Jacob Xu Reviewed-by: Peter Shier Cc: Paolo Bonzini Cc: stable@vger.kernel.org Reported-by: Eric Biggers Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit 0c304e536838d4bbe252f1bab7bec94bb4de509b Author: Marcus Comstedt Date: Sun Dec 15 10:49:00 2019 +0100 KVM: PPC: Book3S HV: Fix regression on big endian hosts commit 228b607d8ea1b7d4561945058d5692709099d432 upstream. VCPU_CR is the offset of arch.regs.ccr in kvm_vcpu. arch/powerpc/include/asm/kvm_host.h defines arch.regs as a struct pt_regs, and arch/powerpc/include/asm/ptrace.h defines the ccr field of pt_regs as "unsigned long ccr". Since unsigned long is 64 bits, a 64-bit load needs to be used to load it, unless an endianness specific correction offset is added to access the desired subpart. In this case there is no reason to _not_ use a 64 bit load though. Fixes: 6c85b7bc637b ("powerpc/kvm: Use UV_RETURN ucall to return to ultravisor") Cc: stable@vger.kernel.org # v5.4+ Signed-off-by: Marcus Comstedt Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191215094900.46740-1-marcus@mc.pp.se Signed-off-by: Greg Kroah-Hartman commit 377a8744c32fcf66c22b3a3dc7cfd0d4644d5bb4 Author: Tejun Heo Date: Mon Dec 16 13:34:00 2019 -0800 iocost: over-budget forced IOs should schedule async delay commit d7bd15a138aef3be227818aad9c501e43c89c8c5 upstream. When over-budget IOs are force-issued through root cgroup, iocg_kick_delay() adjusts the async delay accordingly but doesn't actually schedule async throttle for the issuing task. This bug is pretty well masked because sooner or later the offending threads are gonna get directly throttled on regular IOs or have async delay scheduled by mem_cgroup_throttle_swaprate(). However, it can affect control quality on filesystem metadata heavy operations. Let's fix it by invoking blkcg_schedule_throttle() when iocg_kick_delay() says async delay is needed. Signed-off-by: Tejun Heo Fixes: 7caa47151ab2 ("blkcg: implement blk-iocost") Cc: stable@vger.kernel.org Reported-by: Josef Bacik Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 6d71f73d93830dd2ce00ad067a66726cc6213259 Author: Theodore Ts'o Date: Sun Dec 15 01:09:03 2019 -0500 ext4: validate the debug_want_extra_isize mount option at parse time commit 9803387c55f7d2ce69aa64340c5fdc6b3027dbc8 upstream. Instead of setting s_want_extra_size and then making sure that it is a valid value afterwards, validate the field before we set it. This avoids races and other problems when remounting the file system. Link: https://lore.kernel.org/r/20191215063020.GA11512@mit.edu Cc: stable@kernel.org Signed-off-by: Theodore Ts'o Reported-and-tested-by: syzbot+4a39a025912b265cacef@syzkaller.appspotmail.com Signed-off-by: Greg Kroah-Hartman commit bf5624352dace3bf8733de29ee71cd1bf1b9e519 Author: Dan Carpenter Date: Fri Dec 13 21:50:11 2019 +0300 ext4: unlock on error in ext4_expand_extra_isize() commit 7f420d64a08c1dcd65b27be82a27cf2bdb2e7847 upstream. We need to unlock the xattr before returning on this error path. Cc: stable@kernel.org # 4.13 Fixes: c03b45b853f5 ("ext4, project: expand inode extra size if possible") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20191213185010.6k7yl2tck3wlsdkt@kili.mountain Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6f63704838ff4958e91af089ab15fd688eeda190 Author: Jan Kara Date: Mon Dec 2 18:02:13 2019 +0100 ext4: check for directory entries too close to block end commit 109ba779d6cca2d519c5dd624a3276d03e21948e upstream. ext4_check_dir_entry() currently does not catch a case when a directory entry ends so close to the block end that the header of the next directory entry would not fit in the remaining space. This can lead to directory iteration code trying to access address beyond end of current buffer head leading to oops. CC: stable@vger.kernel.org Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191202170213.4761-3-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 6cc4ccdd0b975f5f4c334fac71fee47e564472bf Author: Jan Kara Date: Mon Dec 2 18:02:12 2019 +0100 ext4: fix ext4_empty_dir() for directories with holes commit 64d4ce892383b2ad6d782e080d25502f91bf2a38 upstream. Function ext4_empty_dir() doesn't correctly handle directories with holes and crashes on bh->b_data dereference when bh is NULL. Reorganize the loop to use 'offset' variable all the times instead of comparing pointers to current direntry with bh->b_data pointer. Also add more strict checking of '.' and '..' directory entries to avoid entering loop in possibly invalid state on corrupted filesystems. References: CVE-2019-19037 CC: stable@vger.kernel.org Fixes: 4e19d6b65fb4 ("ext4: allow directory holes") Signed-off-by: Jan Kara Link: https://lore.kernel.org/r/20191202170213.4761-2-jack@suse.cz Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit bc8ccc0d4f5dabc82b0fef2c471d164d80b048dd Author: Peng Fan Date: Mon Dec 9 08:19:55 2019 +0000 clk: imx: pll14xx: fix clk_pll14xx_wait_lock commit c3a5fd15ed0c1494435e4e35fbee734ae46b5073 upstream. The usage of readl_poll_timeout is wrong, the 3rd parameter(cond) should be "val & LOCK_STATUS" not "val & LOCK_TIMEOUT_US", It is not check whether the pll locked, LOCK_STATUS reflects the mask, not LOCK_TIMEOUT_US. Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc") Cc: Reviewed-by: Abel Vesa Signed-off-by: Peng Fan Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit ee66712ed388df028243dbd9403596a326165613 Author: Peng Fan Date: Fri Nov 1 10:16:19 2019 +0000 clk: imx: clk-composite-8m: add lock to gate/mux commit 073a01e8d7c23b3efb59a3d4c20aa546f9ec29a9 upstream. There is a lock to divider in the composite driver, but that's not enough. lock to gate/mux are also needed to provide exclusive access to the register. Fixes: d3ff9728134e ("clk: imx: Add imx composite clock") Signed-off-by: Peng Fan Cc: Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit 9a5b1c2f5a1548fd117135b86d8fe9b8e49466e4 Author: Peng Fan Date: Fri Nov 22 06:11:42 2019 +0000 clk: imx: clk-imx7ulp: Add missing sentinel of ulp_div_table commit ed11e31709d7ddb19d4dc451d5bbfb15129f4cad upstream. There should be a sentinel of ulp_div_table, otherwise _get_table_div may access data out of the array. Fixes: b1260067ac3d ("clk: imx: add imx7ulp clk driver") Signed-off-by: Peng Fan Cc: Signed-off-by: Shawn Guo Signed-off-by: Greg Kroah-Hartman commit be591d666fe08a544a8b7e67a58d11247400f11e Author: Hans de Goede Date: Tue Nov 19 16:46:41 2019 +0100 pinctrl: baytrail: Really serialize all register accesses commit 40ecab551232972a39cdd8b6f17ede54a3fdb296 upstream. Commit 39ce8150a079 ("pinctrl: baytrail: Serialize all register access") added a spinlock around all register accesses because: "There is a hardware issue in Intel Baytrail where concurrent GPIO register access might result reads of 0xffffffff and writes might get dropped completely." Testing has shown that this does not catch all cases, there are still 2 problems remaining 1) The original fix uses a spinlock per byt_gpio device / struct, additional testing has shown that this is not sufficient concurent accesses to 2 different GPIO banks also suffer from the same problem. This commit fixes this by moving to a single global lock. 2) The original fix did not add a lock around the register accesses in the suspend/resume handling. Since pinctrl-baytrail.c is using normal suspend/resume handlers, interrupts are still enabled during suspend/resume handling. Nothing should be using the GPIOs when they are being taken down, _but_ the GPIOs themselves may still cause interrupts, which are likely to use (read) the triggering GPIO. So we need to protect against concurrent GPIO register accesses in the suspend/resume handlers too. This commit fixes this by adding the missing spin_lock / unlock calls. The 2 fixes together fix the Acer Switch 10 SW5-012 getting completely confused after a suspend resume. The DSDT for this device has a bug in its _LID method which reprograms the home and power button trigger- flags requesting both high and low _level_ interrupts so the IRQs for these 2 GPIOs continuously fire. This combined with the saving of registers during suspend, triggers concurrent GPIO register accesses resulting in saving 0xffffffff as pconf0 value during suspend and then when restoring this on resume the pinmux settings get all messed up, resulting in various I2C busses being stuck, the wifi no longer working and often the tablet simply not coming out of suspend at all. Cc: stable@vger.kernel.org Fixes: 39ce8150a079 ("pinctrl: baytrail: Serialize all register access") Signed-off-by: Hans de Goede Acked-by: Mika Westerberg Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit f960c6dafcb1998d5c2e2f2c1c88f6474fe0075e Author: Yonghan Ye Date: Wed Dec 4 20:00:07 2019 +0800 serial: sprd: Add clearing break interrupt operation commit abeb2e9414d7e3a0d8417bc3b13d7172513ea8a0 upstream. A break interrupt will be generated if the RX line was pulled low, which means some abnomal behaviors occurred of the UART. In this case, we still need to clear this break interrupt status, otherwise it will cause irq storm to crash the whole system. Fixes: b7396a38fb28 ("tty/serial: Add Spreadtrum sc9836-uart driver support") Signed-off-by: Yonghan Ye Cc: stable Signed-off-by: Baolin Wang Link: https://lore.kernel.org/r/925e51b73099c90158e080b8f5bed9b3b38c4548.1575460601.git.baolin.wang7@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3a2f322a2bf1b03be20f3b972bb1fe464dfb3eb7 Author: David Engraf Date: Mon Dec 16 09:54:03 2019 +0100 tty/serial: atmel: fix out of range clock divider handling commit cb47b9f8630ae3fa3f5fbd0c7003faba7abdf711 upstream. Use MCK_DIV8 when the clock divider is > 65535. Unfortunately the mode register was already written thus the clock selection is ignored. Fix by doing the baud rate calulation before setting the mode. Fixes: 5bf5635ac170 ("tty/serial: atmel: add fractional baud rate support") Signed-off-by: David Engraf Acked-by: Ludovic Desroches Acked-by: Richard Genoud Cc: stable Link: https://lore.kernel.org/r/20191216085403.17050-1-david.engraf@sysgo.com Signed-off-by: Greg Kroah-Hartman commit 385fc1fb7545ea99a8aa1094cf527d909b43a705 Author: Ian Abbott Date: Mon Dec 16 11:08:23 2019 +0000 staging: comedi: gsc_hpdi: check dma_alloc_coherent() return value commit ab42b48f32d4c766420c3499ee9c0289b7028182 upstream. The "auto-attach" handler function `gsc_hpdi_auto_attach()` calls `dma_alloc_coherent()` in a loop to allocate some DMA data buffers, and also calls it to allocate a buffer for a DMA descriptor chain. However, it does not check the return value of any of these calls. Change `gsc_hpdi_auto_attach()` to return `-ENOMEM` if any of these `dma_alloc_coherent()` calls fail. This will result in the comedi core calling the "detach" handler `gsc_hpdi_detach()` as part of the clean-up, which will call `gsc_hpdi_free_dma()` to free any allocated DMA coherent memory buffers. Cc: #4.6+ Signed-off-by: Ian Abbott Link: https://lore.kernel.org/r/20191216110823.216237-1-abbotti@mev.co.uk Signed-off-by: Greg Kroah-Hartman commit 78796f74a93e4c5d70e7da3ac952ccfaabd91492 Author: Hans de Goede Date: Tue Dec 17 20:06:04 2019 +0100 platform/x86: hp-wmi: Make buffer for HPWMI_FEATURE2_QUERY 128 bytes commit 133b2acee3871ae6bf123b8fe34be14464aa3d2c upstream. At least on the HP Envy x360 15-cp0xxx model the WMI interface for HPWMI_FEATURE2_QUERY requires an outsize of at least 128 bytes, otherwise it fails with an error code 5 (HPWMI_RET_INVALID_PARAMETERS): Dec 06 00:59:38 kernel: hp_wmi: query 0xd returned error 0x5 We do not care about the contents of the buffer, we just want to know if the HPWMI_FEATURE2_QUERY command is supported. This commits bumps the buffer size, fixing the error. Fixes: 8a1513b4932 ("hp-wmi: limit hotkey enable") Cc: stable@vger.kernel.org BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703 Signed-off-by: Hans de Goede Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 0cef149aa52e88e7b5a5ddffaffc4ed719c0356b Author: Alexander Shishkin Date: Tue Dec 17 13:55:27 2019 +0200 intel_th: msu: Fix window switching without windows commit 05b686b573cfb35a227c30787083a6631ff0f0c9 upstream. Commit 6cac7866c2741 ("intel_th: msu: Add a sysfs attribute to trigger window switch") adds a NULL pointer dereference in the case when there are no windows allocated: > BUG: kernel NULL pointer dereference, address: 0000000000000000 > #PF: supervisor read access in kernel mode > #PF: error_code(0x0000) - not-present page > PGD 0 P4D 0 > Oops: 0000 1 SMP > CPU: 5 PID: 1110 Comm: bash Not tainted 5.5.0-rc1+ #1 > RIP: 0010:msc_win_switch+0xa/0x80 [intel_th_msu] > Call Trace: > ? win_switch_store+0x9b/0xc0 [intel_th_msu] > dev_attr_store+0x17/0x30 > sysfs_kf_write+0x3e/0x50 > kernfs_fop_write+0xda/0x1b0 > __vfs_write+0x1b/0x40 > vfs_write+0xb9/0x1a0 > ksys_write+0x67/0xe0 > __x64_sys_write+0x1a/0x20 > do_syscall_64+0x57/0x1d0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix that by disallowing window switching with multiwindow buffers without windows. Signed-off-by: Alexander Shishkin Fixes: 6cac7866c274 ("intel_th: msu: Add a sysfs attribute to trigger window switch") Reviewed-by: Andy Shevchenko Reported-by: Ammy Yi Tested-by: Ammy Yi Cc: stable@vger.kernel.org # v5.2+ Link: https://lore.kernel.org/r/20191217115527.74383-5-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 6e5e603e7e9085d4850a66805c178aab41fc68af Author: Alexander Shishkin Date: Tue Dec 17 13:55:26 2019 +0200 intel_th: Fix freeing IRQs commit ab832e38e4f0f45b16c3633714d868b7ec6b33b4 upstream. Commit aac8da65174a ("intel_th: msu: Start handling IRQs") implicitly relies on the use of devm_request_irq() to subsequently free the irqs on device removal, but in case of the pci_free_irq_vectors() API, the handlers need to be freed before it is called. Therefore, at the moment the driver's remove path trips a BUG_ON(irq_has_action()): > kernel BUG at drivers/pci/msi.c:375! > invalid opcode: 0000 1 SMP > CPU: 2 PID: 818 Comm: rmmod Not tainted 5.5.0-rc1+ #1 > RIP: 0010:free_msi_irqs+0x67/0x1c0 > pci_disable_msi+0x116/0x150 > pci_free_irq_vectors+0x1b/0x20 > intel_th_pci_remove+0x22/0x30 [intel_th_pci] > pci_device_remove+0x3e/0xb0 > device_release_driver_internal+0xf0/0x1c0 > driver_detach+0x4c/0x8f > bus_remove_driver+0x5c/0xd0 > driver_unregister+0x31/0x50 > pci_unregister_driver+0x40/0x90 > intel_th_pci_driver_exit+0x10/0xad6 [intel_th_pci] > __x64_sys_delete_module+0x147/0x290 > ? exit_to_usermode_loop+0xd7/0x120 > do_syscall_64+0x57/0x1b0 > entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fix this by explicitly freeing irqs before freeing the vectors. We keep using the devm_* variants because they are still useful in early error paths. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Fixes: aac8da65174a ("intel_th: msu: Start handling IRQs") Reported-by: Ammy Yi Tested-by: Ammy Yi Cc: stable@vger.kernel.org # v5.2+ Link: https://lore.kernel.org/r/20191217115527.74383-4-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 1bccecaf0ea28009f2c531107fd249b93a7a72f4 Author: Alexander Shishkin Date: Tue Dec 17 13:55:25 2019 +0200 intel_th: pci: Add Elkhart Lake SOC support commit 88385866bab8d5e18c7f45d1023052c783572e03 upstream. This adds support for Intel Trace Hub in Elkhart Lake. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20191217115527.74383-3-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit 36fb373601339db27f362259023d2e3e3d99d354 Author: Alexander Shishkin Date: Tue Dec 17 13:55:24 2019 +0200 intel_th: pci: Add Comet Lake PCH-V support commit e4de2a5d51f97a6e720a1c0911f93e2d8c2f1c08 upstream. This adds Intel(R) Trace Hub PCI ID for Comet Lake PCH-V. Signed-off-by: Alexander Shishkin Reviewed-by: Andy Shevchenko Cc: Link: https://lore.kernel.org/r/20191217115527.74383-2-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman commit fc7a1502c5396ef288b24ed45a2ad328bfad012d Author: Erkka Talvitie Date: Wed Dec 11 10:08:39 2019 +0200 USB: EHCI: Do not return -EPIPE when hub is disconnected commit 64cc3f12d1c7dd054a215bc1ff9cc2abcfe35832 upstream. When disconnecting a USB hub that has some child device(s) connected to it (such as a USB mouse), then the stack tries to clear halt and reset device(s) which are _already_ physically disconnected. The issue has been reproduced with: CPU: IMX6D5EYM10AD or MCIMX6D5EYM10AE. SW: U-Boot 2019.07 and kernel 4.19.40. CPU: HP Proliant Microserver Gen8. SW: Linux version 4.2.3-300.fc23.x86_64 In this situation there will be error bit for MMF active yet the CERR equals EHCI_TUNE_CERR + halt. Existing implementation interprets this as a stall [1] (chapter 8.4.5). The possible conditions when the MMF will be active + halt can be found from [2] (Table 4-13). Fix for the issue is to check whether MMF is active and PID Code is IN before checking for the stall. If these conditions are true then it is not a stall. What happens after the fix is that when disconnecting a hub with attached device(s) the situation is not interpret as a stall. [1] [https://www.usb.org/document-library/usb-20-specification, usb_20.pdf] [2] [https://www.intel.com/content/dam/www/public/us/en/documents/ technical-specifications/ehci-specification-for-usb.pdf] Signed-off-by: Erkka Talvitie Reviewed-by: Alan Stern Cc: stable Link: https://lore.kernel.org/r/ef70941d5f349767f19c0ed26b0dd9eed8ad81bb.1576050523.git.erkka.talvitie@vincit.fi Signed-off-by: Greg Kroah-Hartman commit b58b8e93313affee10dbebb7f033a28b89555bb4 Author: Yang Shi Date: Tue Dec 17 20:51:52 2019 -0800 mm: vmscan: protect shrinker idr replace with CONFIG_MEMCG commit 42a9a53bb394a1de2247ef78f0b802ae86798122 upstream. Since commit 0a432dcbeb32 ("mm: shrinker: make shrinker not depend on memcg kmem"), shrinkers' idr is protected by CONFIG_MEMCG instead of CONFIG_MEMCG_KMEM, so it makes no sense to protect shrinker idr replace with CONFIG_MEMCG_KMEM. And in the CONFIG_MEMCG && CONFIG_SLOB case, shrinker_idr contains only shrinker, and it is deferred_split_shrinker. But it is never actually called, since idr_replace() is never compiled due to the wrong #ifdef. The deferred_split_shrinker all the time is staying in half-registered state, and it's never called for subordinate mem cgroups. Link: http://lkml.kernel.org/r/1575486978-45249-1-git-send-email-yang.shi@linux.alibaba.com Fixes: 0a432dcbeb32 ("mm: shrinker: make shrinker not depend on memcg kmem") Signed-off-by: Yang Shi Reviewed-by: Kirill Tkhai Acked-by: Michal Hocko Cc: Johannes Weiner Cc: Shakeel Butt Cc: Roman Gushchin Cc: [5.4+] Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 36cd99cf68b4482cd5ed8f0ea72c6cf109fa6245 Author: Eric Biggers Date: Wed Oct 9 16:03:49 2019 -0700 KEYS: asymmetric: return ENOMEM if akcipher_request_alloc() fails commit bea37414453eb08d4ceffeb60a9d490dbc930cea upstream. No error code was being set on this error path. Cc: stable@vger.kernel.org Fixes: ad4b1eb5fb33 ("KEYS: asym_tpm: Implement encryption operation [ver #2]") Fixes: c08fed737126 ("KEYS: Implement encrypt, decrypt and sign for software asymmetric key [ver #2]") Reviewed-by: James Morris Signed-off-by: Eric Biggers Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit da06508bcb1acf643f86055a2af65b80baa01b3b Author: Rafael J. Wysocki Date: Wed Dec 11 11:28:41 2019 +0100 cpufreq: Avoid leaving stale IRQ work items during CPU offline commit 85572c2c4a45a541e880e087b5b17a48198b2416 upstream. The scheduler code calling cpufreq_update_util() may run during CPU offline on the target CPU after the IRQ work lists have been flushed for it, so the target CPU should be prevented from running code that may queue up an IRQ work item on it at that point. Unfortunately, that may not be the case if dvfs_possible_from_any_cpu is set for at least one cpufreq policy in the system, because that allows the CPU going offline to run the utilization update callback of the cpufreq governor on behalf of another (online) CPU in some cases. If that happens, the cpufreq governor callback may queue up an IRQ work on the CPU running it, which is going offline, and the IRQ work may not be flushed after that point. Moreover, that IRQ work cannot be flushed until the "offlining" CPU goes back online, so if any other CPU calls irq_work_sync() to wait for the completion of that IRQ work, it will have to wait until the "offlining" CPU is back online and that may not happen forever. In particular, a system-wide deadlock may occur during CPU online as a result of that. The failing scenario is as follows. CPU0 is the boot CPU, so it creates a cpufreq policy and becomes the "leader" of it (policy->cpu). It cannot go offline, because it is the boot CPU. Next, other CPUs join the cpufreq policy as they go online and they leave it when they go offline. The last CPU to go offline, say CPU3, may queue up an IRQ work while running the governor callback on behalf of CPU0 after leaving the cpufreq policy because of the dvfs_possible_from_any_cpu effect described above. Then, CPU0 is the only online CPU in the system and the stale IRQ work is still queued on CPU3. When, say, CPU1 goes back online, it will run irq_work_sync() to wait for that IRQ work to complete and so it will wait for CPU3 to go back online (which may never happen even in principle), but (worse yet) CPU0 is waiting for CPU1 at that point too and a system-wide deadlock occurs. To address this problem notice that CPUs which cannot run cpufreq utilization update code for themselves (for example, because they have left the cpufreq policies that they belonged to), should also be prevented from running that code on behalf of the other CPUs that belong to a cpufreq policy with dvfs_possible_from_any_cpu set and so in that case the cpufreq_update_util_data pointer of the CPU running the code must not be NULL as well as for the CPU which is the target of the cpufreq utilization update in progress. Accordingly, change cpufreq_this_cpu_can_update() into a regular function in kernel/sched/cpufreq.c (instead of a static inline in a header file) and make it check the cpufreq_update_util_data pointer of the local CPU if dvfs_possible_from_any_cpu is set for the target cpufreq policy. Also update the schedutil governor to do the cpufreq_this_cpu_can_update() check in the non-fast-switch case too to avoid the stale IRQ work issues. Fixes: 99d14d0e16fa ("cpufreq: Process remote callbacks from any CPU if the platform permits") Link: https://lore.kernel.org/linux-pm/20191121093557.bycvdo4xyinbc5cb@vireshk-i7/ Reported-by: Anson Huang Tested-by: Anson Huang Cc: 4.14+ # 4.14+ Signed-off-by: Rafael J. Wysocki Acked-by: Viresh Kumar Tested-by: Peng Fan (i.MX8QXP-MEK) Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit 5049468ba1a845ef2ef6d73ec655242ee9ef14e5 Author: Ard Biesheuvel Date: Fri Dec 6 16:55:37 2019 +0000 efi/memreserve: Register reservations as 'reserved' in /proc/iomem commit ab0eb16205b43ece4c78e2259e681ff3d645ea66 upstream. Memory regions that are reserved using efi_mem_reserve_persistent() are recorded in a special EFI config table which survives kexec, allowing the incoming kernel to honour them as well. However, such reservations are not visible in /proc/iomem, and so the kexec tools that load the incoming kernel and its initrd into memory may overwrite these reserved regions before the incoming kernel has a chance to reserve them from further use. Address this problem by adding these reservations to /proc/iomem as they are created. Note that reservations that are inherited from a previous kernel are memblock_reserve()'d early on, so they are already visible in /proc/iomem. Tested-by: Masayoshi Mizuma Tested-by: Bhupesh Sharma Signed-off-by: Ard Biesheuvel Reviewed-by: Bhupesh Sharma Cc: # v5.4+ Cc: Andy Shevchenko Cc: Arvind Sankar Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-2-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman commit 2ff988de621ac896d5dd9a0139b0da3027891249 Author: Christophe Leroy Date: Thu Dec 12 17:47:24 2019 +0000 spi: fsl: use platform_get_irq() instead of of_irq_to_resource() commit 63aa6a692595d47a0785297b481072086b9272d2 upstream. Unlike irq_of_parse_and_map() which has a dummy definition on SPARC, of_irq_to_resource() hasn't. But as platform_get_irq() can be used instead and is generic, use it. Reported-by: kbuild test robot Suggested-by: Mark Brown Fixes: 3194d2533eff ("spi: fsl: don't map irq during probe") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/091a277fd0b3356dca1e29858c1c96983fc9cb25.1576172743.git.christophe.leroy@c-s.fr Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit dac29ae0df4c53e18a61898014e6a1ec553fc13b Author: Christophe Leroy Date: Mon Dec 9 15:27:27 2019 +0000 spi: fsl: don't map irq during probe commit 3194d2533efffae8b815d84729ecc58b6a9000ab upstream. With lastest kernel, the following warning is observed at startup: [ 1.500609] ------------[ cut here ]------------ [ 1.505225] remove_proc_entry: removing non-empty directory 'irq/22', leaking at least 'fsl_spi' [ 1.514234] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:682 remove_proc_entry+0x198/0x1c0 [ 1.522403] CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.0-s3k-dev-02248-g93532430a4ff #2564 [ 1.530724] NIP: c0197694 LR: c0197694 CTR: c0050d80 [ 1.535762] REGS: df4a5af0 TRAP: 0700 Not tainted (5.4.0-02248-g93532430a4ff) [ 1.543818] MSR: 00029032 CR: 22028222 XER: 00000000 [ 1.550524] [ 1.550524] GPR00: c0197694 df4a5ba8 df4a0000 00000054 00000000 00000000 00004a38 00000010 [ 1.550524] GPR08: c07c5a30 00000800 00000000 00001032 22000208 00000000 c0004b14 00000000 [ 1.550524] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0830000 c07fc078 [ 1.550524] GPR24: c08e8ca0 df665d10 df60ea98 c07c9db8 00000001 df5d5ae3 df5d5a80 df43f8e3 [ 1.585327] NIP [c0197694] remove_proc_entry+0x198/0x1c0 [ 1.590628] LR [c0197694] remove_proc_entry+0x198/0x1c0 [ 1.595829] Call Trace: [ 1.598280] [df4a5ba8] [c0197694] remove_proc_entry+0x198/0x1c0 (unreliable) [ 1.605321] [df4a5bd8] [c0067acc] unregister_irq_proc+0x5c/0x70 [ 1.611238] [df4a5bf8] [c005fbc4] free_desc+0x3c/0x80 [ 1.616286] [df4a5c18] [c005fe2c] irq_free_descs+0x70/0xa8 [ 1.621778] [df4a5c38] [c033d3fc] of_fsl_spi_probe+0xdc/0x3cc [ 1.627525] [df4a5c88] [c02f0f64] platform_drv_probe+0x44/0xa4 [ 1.633350] [df4a5c98] [c02eee44] really_probe+0x1ac/0x418 [ 1.638829] [df4a5cc8] [c02ed3e8] bus_for_each_drv+0x64/0xb0 [ 1.644481] [df4a5cf8] [c02ef950] __device_attach+0xd4/0x128 [ 1.650132] [df4a5d28] [c02ed61c] bus_probe_device+0xa0/0xbc [ 1.655783] [df4a5d48] [c02ebbe8] device_add+0x544/0x74c [ 1.661096] [df4a5d88] [c0382b78] of_platform_device_create_pdata+0xa4/0x100 [ 1.668131] [df4a5da8] [c0382cf4] of_platform_bus_create+0x120/0x20c [ 1.674474] [df4a5df8] [c0382d50] of_platform_bus_create+0x17c/0x20c [ 1.680818] [df4a5e48] [c0382e88] of_platform_bus_probe+0x9c/0xf0 [ 1.686907] [df4a5e68] [c0751404] __machine_initcall_cmpcpro_cmpcpro_declare_of_platform_devices+0x74/0x1a4 [ 1.696629] [df4a5e98] [c072a4cc] do_one_initcall+0x8c/0x1d4 [ 1.702282] [df4a5ef8] [c072a768] kernel_init_freeable+0x154/0x204 [ 1.708455] [df4a5f28] [c0004b2c] kernel_init+0x18/0x110 [ 1.713769] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c [ 1.719926] Instruction dump: [ 1.722889] 2c030000 4182004c 3863ffb0 3c80c05f 80e3005c 388436a0 3c60c06d 7fa6eb78 [ 1.730630] 7fe5fb78 38840280 38634178 4be8c611 <0fe00000> 4bffff6c 3c60c071 7fe4fb78 [ 1.738556] ---[ end trace 05d0720bf2e352e2 ]--- The problem comes from the error path which calls irq_dispose_mapping() while the IRQ has been requested with devm_request_irq(). IRQ doesn't need to be mapped with irq_of_parse_and_map(). The only need is to get the IRQ virtual number. For that, use of_irq_to_resource() instead of the irq_of_parse_and_map()/irq_dispose_mapping() pair. Fixes: 500a32abaf81 ("spi: fsl: Call irq_dispose_mapping in err path") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/518cfb83347d5372748e7fe72f94e2e9443d0d4a.1575905123.git.christophe.leroy@c-s.fr Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 8bbc1a734eca60dccc7b1f2292d9753111a7a978 Author: Suwan Kim Date: Fri Dec 13 11:30:55 2019 +0900 usbip: Fix error path of vhci_recv_ret_submit() commit aabb5b833872524eaf28f52187e5987984982264 upstream. If a transaction error happens in vhci_recv_ret_submit(), event handler closes connection and changes port status to kick hub_event. Then hub tries to flush the endpoint URBs, but that causes infinite loop between usb_hub_flush_endpoint() and vhci_urb_dequeue() because "vhci_priv" in vhci_urb_dequeue() was already released by vhci_recv_ret_submit() before a transmission error occurred. Thus, vhci_urb_dequeue() terminates early and usb_hub_flush_endpoint() continuously calls vhci_urb_dequeue(). The root cause of this issue is that vhci_recv_ret_submit() terminates early without giving back URB when transaction error occurs in vhci_recv_ret_submit(). That causes the error URB to still be linked at endpoint list without “vhci_priv". So, in the case of transaction error in vhci_recv_ret_submit(), unlink URB from the endpoint, insert proper error code in urb->status and give back URB. Reported-by: Marek Marczykowski-Górecki Tested-by: Marek Marczykowski-Górecki Signed-off-by: Suwan Kim Cc: stable Acked-by: Shuah Khan Link: https://lore.kernel.org/r/20191213023055.19933-3-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman commit dbfc29c2c70e855beedaff9f60ec1fd6aae16781 Author: Suwan Kim Date: Fri Dec 13 11:30:54 2019 +0900 usbip: Fix receive error in vhci-hcd when using scatter-gather commit d986294ee55d719562b20aabe15a39bf8f863415 upstream. When vhci uses SG and receives data whose size is smaller than SG buffer size, it tries to receive more data even if it acutally receives all the data from the server. If then, it erroneously adds error event and triggers connection shutdown. vhci-hcd should check if it received all the data even if there are more SG entries left. So, check if it receivces all the data from the server in for_each_sg() loop. Fixes: ea44d190764b ("usbip: Implement SG support to vhci-hcd and stub driver") Reported-by: Marek Marczykowski-Górecki Tested-by: Marek Marczykowski-Górecki Signed-off-by: Suwan Kim Acked-by: Shuah Khan Cc: stable Link: https://lore.kernel.org/r/20191213023055.19933-2-suwan.kim027@gmail.com Signed-off-by: Greg Kroah-Hartman commit 2617753cbc80e75f6e663a6af7457391259ef6a4 Author: Joakim Zhang Date: Wed Dec 4 11:36:11 2019 +0000 can: flexcan: add low power enter/exit acknowledgment helper [ Upstream commit b7603d080ffcf8689ec91ca300caf84d8dbed317 ] The MCR[LPMACK] read-only bit indicates that FlexCAN is in a lower-power mode (Disabled mode, Doze mode, Stop mode). The CPU can poll this bit to know when FlexCAN has actually entered low power mode. The low power enter/exit acknowledgment helper will reduce code duplication for disabled mode, doze mode and stop mode. Tested-by: Sean Nyekjaer Signed-off-by: Joakim Zhang Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin commit 44d0657e5679a9b5a0a81bbf99aba4b6a863da46 Author: Tony Lindgren Date: Tue Nov 19 19:50:30 2019 -0800 ARM: dts: Fix vcsi regulator to be always-on for droid4 to prevent hangs [ Upstream commit ddb52945999dcf35787bf221b62108806182578d ] In addition to using vcsi regulator for the display, looks like droid4 is using vcsi regulator to trigger off mode internally with the PMIC firmware when the SoC enters deeper idle states. This is configured in the Motorola Mapphone Linux kernel sources as "zerov_regulator". As we currently don't support off mode during idle for omap4, we must prevent vcsi from being disabled when the display is blanked to prevent the PMIC change to off mode. Otherwise the device will hang on entering idle when the display is blanked. Before commit 089b3f61ecfc ("regulator: core: Let boot-on regulators be powered off"), the boot-on regulators never got disabled like they should and vcsi did not get turned off on idle. Let's fix the issue by setting vcsi to always-on for now. Later on we may want to claim the vcsi regulator also in the PM code if needed. Fixes: 089b3f61ecfc ("regulator: core: Let boot-on regulators be powered off") Cc: Merlijn Wajer Cc: Pavel Machek Cc: Sebastian Reichel Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 19f8631f2b02c25c699e99d283a8b8f97a28e794 Author: Sven Schnelle Date: Mon Dec 9 09:03:12 2019 +0100 s390/ftrace: fix endless recursion in function_graph tracer [ Upstream commit 6feeee8efc53035c3195b02068b58ae947538aa4 ] The following sequence triggers a kernel stack overflow on s390x: mount -t tracefs tracefs /sys/kernel/tracing cd /sys/kernel/tracing echo function_graph > current_tracer [crash] This is because preempt_count_{add,sub} are in the list of traced functions, which can be demonstrated by: echo preempt_count_add >set_ftrace_filter echo function_graph > current_tracer [crash] The stack overflow happens because get_tod_clock_monotonic() gets called by ftrace but itself calls preempt_{disable,enable}(), which leads to a endless recursion. Fix this by using preempt_{disable,enable}_notrace(). Fixes: 011620688a71 ("s390/time: ensure get_clock_monotonic() returns monotonic values") Signed-off-by: Sven Schnelle Reviewed-by: Vasily Gorbik Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 9e3175ea2303dfa425d29b7ed3395f8aa490f7c8 Author: Yufen Yu Date: Wed Oct 30 18:47:02 2019 +0800 md: avoid invalid memory access for array sb->dev_roles [ Upstream commit 228fc7d76db68732677230a3c64337908fd298e3 ] we need to gurantee 'desc_nr' valid before access array of sb->dev_roles. In addition, we should avoid .load_super always return '0' when level is LEVEL_MULTIPATH, which is not expected. Reported-by: coverity-bot Addresses-Coverity-ID: 1487373 ("Memory - illegal accesses") Fixes: 6a5cb53aaa4e ("md: no longer compare spare disk superblock events in super_load") Signed-off-by: Yufen Yu Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 869aeb9a7063f22c1a0ef4df1805e5c965ee89fd Author: Bernard Metzler Date: Fri Oct 25 16:29:03 2019 +0200 RDMA/siw: Fix post_recv QP state locking [ Upstream commit 0edefddbae396e50eb7887d279d0c4bb4d7a6384 ] Do not release qp state lock if not previously acquired. Fixes: cf049bb31f71 ("RDMA/siw: Fix SQ/RQ drain logic") Link: https://lore.kernel.org/r/20191025142903.20625-1-bmt@zurich.ibm.com Reported-by: Dan Carpenter Signed-off-by: Bernard Metzler Reviewed-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 1648dcd12745042975521c76e4964f0332b902b9 Author: Bjorn Andersson Date: Wed Nov 13 12:26:44 2019 -0800 ath10k: Revert "ath10k: add cleanup in ath10k_sta_state()" [ Upstream commit f4fe2e53349f1072d33c69f484dbf9d77bb8f45a ] This reverts commit 334f5b61a6f29834e881923b98d1e27e5ce9620d. This caused ath10k_snoc on Qualcomm MSM8998, SDM845 and QCS404 platforms to trigger an assert in the firmware: err_qdi.c:456:EF:wlan_process:1:cmnos_thread.c:3900:Asserted in wlan_vdev.c:_wlan_vdev_up:3219 Revert the offending commit for now. Signed-off-by: Bjorn Andersson Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 1c0a591d14ac588fe5f1c4ec309c0547e7608917 Author: Colin Ian King Date: Thu Oct 3 22:52:27 2019 +0100 drm/amdgpu: fix uninitialized variable pasid_mapping_needed [ Upstream commit 17cf678a33c6196a3df4531fe5aec91384c9eeb5 ] The boolean variable pasid_mapping_needed is not initialized and there are code paths that do not assign it any value before it is is read later. Fix this by initializing pasid_mapping_needed to false. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: 6817bf283b2b ("drm/amdgpu: grab the id mgr lock while accessing passid_mapping") Reviewed-by: Christian König Signed-off-by: Colin Ian King Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0d1716fb4fc0504323bc9cbcef0adcc604bcf332 Author: Guenter Roeck Date: Tue Dec 17 17:19:11 2019 -0800 usb: xhci: Fix build warning seen with CONFIG_PM=n [ Upstream commit 6056a0f8ede27b296d10ef46f7f677cc9d715371 ] The following build warning is seen if CONFIG_PM is disabled. drivers/usb/host/xhci-pci.c:498:13: warning: unused function 'xhci_pci_shutdown' Fixes: f2c710f7dca8 ("usb: xhci: only set D3hot for pci device") Cc: Henry Lin Cc: stable@vger.kernel.org # all stable releases with f2c710f7dca8 Signed-off-by: Guenter Roeck Acked-by: Mathias Nyman Link: https://lore.kernel.org/r/20191218011911.6907-1-linux@roeck-us.net Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit dba56969cc9dcf51a60e910d0b8a5cf488585783 Author: Charles Keepax Date: Tue Nov 26 16:41:40 2019 +0000 spi: cadence: Correct handling of native chipselect [ Upstream commit 61acd19f9c56fa0809285346bd0bd4a926ab0da0 ] To fix a regression on the Cadence SPI driver, this patch reverts commit 6046f5407ff0 ("spi: cadence: Fix default polarity of native chipselect"). This patch was not the correct fix for the issue. The SPI framework calls the set_cs line with the logic level it desires on the chip select line, as such the old is_high handling was correct. However, this was broken by the fact that before commit 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") all controllers that offered the use of a GPIO chip select had SPI_CS_HIGH applied, even for hardware chip selects. This caused the value passed into the driver to be inverted. Which unfortunately makes it look like a logical enable the chip select value. Since the core was corrected to not unconditionally apply SPI_CS_HIGH, the Cadence driver, whilst using the hardware chip select, will deselect the chip select every time we attempt to communicate with the device, which results in failed communications. Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Signed-off-by: Charles Keepax Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20191126164140.6240-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 68b0cbb1ad503faa0266a8bbe33f0b0af9db1c70 Author: Charles Keepax Date: Wed Nov 27 15:39:36 2019 +0000 spi: dw: Correct handling of native chipselect [ Upstream commit ada9e3fcc175db4538f5b5e05abf5dedf626e550 ] This patch reverts commit 6e0a32d6f376 ("spi: dw: Fix default polarity of native chipselect"). The SPI framework always called the set_cs callback with the logic level it desired on the chip select line, which is what the drivers original handling supported. commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") changed these symantics, but only in the case of drivers that also support GPIO chip selects, to true meaning apply slave select rather than logic high. This left things in an odd state where a driver that only supports hardware chip selects, the core would handle polarity but if the driver supported GPIOs as well the driver should handle polarity. At this point the reverted change was applied to change the logic in the driver to match new system. This was then broken by commit 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") which reverted the core back to consistently calling set_cs with a logic level. This fix reverts the driver code back to its original state to match the current core code. This is probably a better fix as a) the set_cs callback is always called with consistent symantics and b) the inversion for SPI_CS_HIGH can be handled in the core and doesn't need to be coded in each driver supporting it. Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Signed-off-by: Charles Keepax Acked-by: Linus Walleij Link: https://lore.kernel.org/r/20191127153936.29719-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1ceb30424faf284019a07ae0a73d4692753133c0 Author: Thadeu Lima de Souza Cascardo Date: Fri Dec 13 07:39:02 2019 -0300 selftests: net: tls: remove recv_rcvbuf test [ Upstream commit 6dd504b0fd1039c6e5d391e97cf5c4ee592aefcb ] This test only works when [1] is applied, which was rejected. Basically, the errors are reported and cleared. In this particular case of tls sockets, following reads will block. The test case was originally submitted with the rejected patch, but, then, was included as part of a different patchset, possibly by mistake. [1] https://lore.kernel.org/netdev/20191007035323.4360-2-jakub.kicinski@netronome.com/#t Thanks Paolo Pisati for pointing out the original patchset where this appeared. Fixes: 65190f77424d (selftests/tls: add a test for fragmented messages) Reported-by: Paolo Pisati Signed-off-by: Thadeu Lima de Souza Cascardo Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9562cdb0af47c4040c4e7e842b87a43f86845c7a Author: Xiaolong Huang Date: Sat Dec 7 22:40:24 2019 +0800 can: kvaser_usb: kvaser_usb_leaf: Fix some info-leaks to USB devices commit da2311a6385c3b499da2ed5d9be59ce331fa93e9 upstream. Uninitialized Kernel memory can leak to USB devices. Fix this by using kzalloc() instead of kmalloc(). Signed-off-by: Xiaolong Huang Fixes: 7259124eac7d ("can: kvaser_usb: Split driver into kvaser_usb_core.c and kvaser_usb_leaf.c") Cc: linux-stable # >= v4.19 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 6c1fe4e01cb97bb745d861bca085ae4a35a018c5 Author: Joakim Zhang Date: Wed Dec 4 11:36:14 2019 +0000 can: flexcan: poll MCR_LPM_ACK instead of GPR ACK for stop mode acknowledgment commit 048e3a34a2e7669bf475eb56c7345ad9d8d2b8e3 upstream. Stop Mode is entered when Stop Mode is requested at chip level and MCR[LPM_ACK] is asserted by the FlexCAN. Double check with IP owner, the MCR[LPM_ACK] bit should be polled for stop mode acknowledgment, not the acknowledgment from chip level which is used to gate flexcan clocks. This patch depends on: b7603d080ffc ("can: flexcan: add low power enter/exit acknowledgment helper") Fixes: 5f186c257fa4 (can: flexcan: fix stop mode acknowledgment) Tested-by: Sean Nyekjaer Signed-off-by: Joakim Zhang Cc: linux-stable # >= v5.0 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 37026f90ff7cb83ea819c9de881024099bcc54ae Author: Sean Nyekjaer Date: Wed Dec 4 11:36:06 2019 +0000 can: flexcan: fix possible deadlock and out-of-order reception after wakeup commit e707180ae2df1c87e26ec7a6fd70d07483bde7fd upstream. When suspending, and there is still CAN traffic on the interfaces the flexcan immediately wakes the platform again. As it should :-). But it throws this error msg: [ 3169.378661] PM: noirq suspend of devices failed On the way down to suspend the interface that throws the error message calls flexcan_suspend() but fails to call flexcan_noirq_suspend(). That means flexcan_enter_stop_mode() is called, but on the way out of suspend the driver only calls flexcan_resume() and skips flexcan_noirq_resume(), thus it doesn't call flexcan_exit_stop_mode(). This leaves the flexcan in stop mode, and with the current driver it can't recover from this even with a soft reboot, it requires a hard reboot. This patch fixes the deadlock when using self wakeup, by calling flexcan_exit_stop_mode() from flexcan_resume() instead of flexcan_noirq_resume(). This also fixes another issue: CAN frames are received out-of-order in first IRQ handler run after wakeup. The problem is that the wakeup latency from frame reception to the IRQ handler (where the CAN frames are sorted by timestamp) is much bigger than the time stamp counter wrap around time. This means it's impossible to sort the CAN frames by timestamp. The reason is that the controller exits stop mode during noirq resume, which means it receives frames immediately, but interrupt handling is still not possible. So exit stop mode during resume stage instead of noirq resume fixes this issue. Fixes: de3578c198c6 ("can: flexcan: add self wakeup support") Signed-off-by: Sean Nyekjaer Tested-by: Sean Nyekjaer Signed-off-by: Joakim Zhang Cc: linux-stable # >= v5.0 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit f83b3ca2269e2fbb34c4e768923199b22291a909 Author: Oleksij Rempel Date: Fri Dec 6 15:18:35 2019 +0100 can: j1939: j1939_sk_bind(): take priv after lock is held commit 00d4e14d2e4caf5f7254a505fee5eeca8cd37bd4 upstream. syzbot reproduced following crash: =============================================================================== kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 0 PID: 9844 Comm: syz-executor.0 Not tainted 5.4.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__lock_acquire+0x1254/0x4a00 kernel/locking/lockdep.c:3828 Code: 00 0f 85 96 24 00 00 48 81 c4 f0 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <80> 3c 02 00 0f 85 0b 28 00 00 49 81 3e 20 19 78 8a 0f 84 5f ee ff RSP: 0018:ffff888099c3fb48 EFLAGS: 00010006 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000218 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff888099c3fc60 R08: 0000000000000001 R09: 0000000000000001 R10: fffffbfff146e1d0 R11: ffff888098720400 R12: 00000000000010c0 R13: 0000000000000000 R14: 00000000000010c0 R15: 0000000000000000 FS: 00007f0559e98700(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe4d89e0000 CR3: 0000000099606000 CR4: 00000000001406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4485 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x33/0x50 kernel/locking/spinlock.c:175 spin_lock_bh include/linux/spinlock.h:343 [inline] j1939_jsk_del+0x32/0x210 net/can/j1939/socket.c:89 j1939_sk_bind+0x2ea/0x8f0 net/can/j1939/socket.c:448 __sys_bind+0x239/0x290 net/socket.c:1648 __do_sys_bind net/socket.c:1659 [inline] __se_sys_bind net/socket.c:1657 [inline] __x64_sys_bind+0x73/0xb0 net/socket.c:1657 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x45a679 Code: ad b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 0f 83 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f0559e97c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 000000000045a679 RDX: 0000000000000018 RSI: 0000000020000240 RDI: 0000000000000003 RBP: 000000000075bf20 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f0559e986d4 R13: 00000000004c09e9 R14: 00000000004d37d0 R15: 00000000ffffffff Modules linked in: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 9844 at kernel/locking/mutex.c:1419 mutex_trylock+0x279/0x2f0 kernel/locking/mutex.c:1427 =============================================================================== This issues was caused by null pointer deference. Where j1939_sk_bind() was using currently not existing priv. Possible scenario may look as following: cpu0 cpu1 bind() bind() j1939_sk_bind() j1939_sk_bind() priv = jsk->priv; priv = jsk->priv; lock_sock(sock->sk); priv = j1939_netdev_start(ndev); j1939_jsk_add(priv, jsk); jsk->priv = priv; relase_sock(sock->sk); lock_sock(sock->sk); j1939_jsk_del(priv, jsk); ..... ooops ...... With this patch we move "priv = jsk->priv;" after the lock, to avoid assigning of wrong priv pointer. Reported-by: syzbot+99e9e1b200a1e363237d@syzkaller.appspotmail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Oleksij Rempel Cc: linux-stable # >= v5.4 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit d7f6a5729a12fd6de2eb95a408be0ac1e01d6160 Author: Sean Nyekjaer Date: Fri Dec 6 16:29:22 2019 +0100 can: m_can: tcan4x5x: add required delay after reset commit 60552253e29c8860ee5bf1e6064591b0917c0394 upstream. According to section "8.3.8 RST Pin" in the datasheet we are required to wait >700us after the device is reset. Signed-off-by: Sean Nyekjaer Acked-by: Dan Murphy Cc: linux-stable # >= v5.4 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit a73cf89ae5c67a1ab5009f0acffb37c69efefdf4 Author: Srinivas Neeli Date: Tue Dec 3 17:46:36 2019 +0530 can: xilinx_can: Fix missing Rx can packets on CANFD2.0 commit 9ab79b06ddf3cdf6484d60b3e5fe113e733145c8 upstream. CANFD2.0 core uses BRAM for storing acceptance filter ID(AFID) and MASK (AFMASK)registers. So by default AFID and AFMASK registers contain random data. Due to random data, we are not able to receive all CAN ids. Initializing AFID and AFMASK registers with Zero before enabling acceptance filter to receive all packets irrespective of ID and Mask. Fixes: 0db9071353a0 ("can: xilinx: add can 2.0 support") Signed-off-by: Michal Simek Signed-off-by: Srinivas Neeli Reviewed-by: Naga Sureshkumar Relli Cc: linux-stable # >= v5.0 Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 90a7ae8add6076dcbf8aba7bbfdaf2cac28a8a22 Author: Jerry Snitselaar Date: Thu Dec 12 22:36:42 2019 -0700 iommu/vt-d: Allocate reserved region for ISA with correct permission commit cde9319e884eb6267a0df446f3c131fe1108defb upstream. Currently the reserved region for ISA is allocated with no permissions. If a dma domain is being used, mapping this region will fail. Set the permissions to DMA_PTE_READ|DMA_PTE_WRITE. Cc: Joerg Roedel Cc: Lu Baolu Cc: iommu@lists.linux-foundation.org Cc: stable@vger.kernel.org # v5.3+ Fixes: d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") Signed-off-by: Jerry Snitselaar Acked-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit e04f7db2bcb692e5eab64580dfae0038e23d8ede Author: Alex Williamson Date: Wed Dec 11 13:28:29 2019 -0700 iommu/vt-d: Set ISA bridge reserved region as relaxable commit d8018a0e9195ba9f0fb9cf0fd3843807c8b952d5 upstream. Commit d850c2ee5fe2 ("iommu/vt-d: Expose ISA direct mapping region via iommu_get_resv_regions") created a direct-mapped reserved memory region in order to replace the static identity mapping of the ISA address space, where the latter was then removed in commit df4f3c603aeb ("iommu/vt-d: Remove static identity map code"). According to the history of this code and the Kconfig option surrounding it, this direct mapping exists for the benefit of legacy ISA drivers that are not compatible with the DMA API. In conjuntion with commit 9b77e5c79840 ("vfio/type1: check dma map request is within a valid iova range") this change introduced a regression where the vfio IOMMU backend enforces reserved memory regions per IOMMU group, preventing userspace from creating IOMMU mappings conflicting with prescribed reserved regions. A necessary prerequisite for the vfio change was the introduction of "relaxable" direct mappings introduced by commit adfd37382090 ("iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions"). These relaxable direct mappings provide the same identity mapping support in the default domain, but also indicate that the reservation is software imposed and may be relaxed under some conditions, such as device assignment. Convert the ISA bridge direct-mapped reserved region to relaxable to reflect that the restriction is self imposed and need not be enforced by drivers such as vfio. Fixes: 1c5c59fbad20 ("iommu/vt-d: Differentiate relaxable and non relaxable RMRRs") Cc: stable@vger.kernel.org # v5.3+ Link: https://lore.kernel.org/linux-iommu/20191211082304.2d4fab45@x1.home Reported-by: cprt Tested-by: cprt Signed-off-by: Alex Williamson Acked-by: Lu Baolu Reviewed-by: Eric Auger Tested-by: Jerry Snitselaar Reviewed-by: Jerry Snitselaar Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 8a9661847790ad2c0cf16100554f4fac28874ad7 Author: Lu Baolu Date: Wed Dec 11 09:40:15 2019 +0800 iommu/vt-d: Fix dmar pte read access not set error commit 75d18385394f56db76845d91a192532aba421875 upstream. If the default DMA domain of a group doesn't fit a device, it will still sit in the group but use a private identity domain. When map/unmap/iova_to_phys come through iommu API, the driver should still serve them, otherwise, other devices in the same group will be impacted. Since identity domain has been mapped with the whole available memory space and RMRRs, we don't need to worry about the impact on it. Link: https://www.spinics.net/lists/iommu/msg40416.html Cc: Jerry Snitselaar Reported-by: Jerry Snitselaar Fixes: 942067f1b6b97 ("iommu/vt-d: Identify default domains replaced with private") Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: Lu Baolu Reviewed-by: Jerry Snitselaar Tested-by: Jerry Snitselaar Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit 71730ba7914ea2bb8ba311e1423a5c8475178912 Author: Jerry Snitselaar Date: Tue Dec 10 11:56:06 2019 -0700 iommu: set group default domain before creating direct mappings commit d360211524bece6db9920f32c91808235290b51c upstream. iommu_group_create_direct_mappings uses group->default_domain, but right after it is called, request_default_domain_for_dev calls iommu_domain_free for the default domain, and sets the group default domain to a different domain. Move the iommu_group_create_direct_mappings call to after the group default domain is set, so the direct mappings get associated with that domain. Cc: Joerg Roedel Cc: Lu Baolu Cc: iommu@lists.linux-foundation.org Cc: stable@vger.kernel.org Fixes: 7423e01741dd ("iommu: Add API to request DMA domain for device") Signed-off-by: Jerry Snitselaar Reviewed-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit fe3bcc2e236c21854a499ca6f06e88ecc1e4e1ea Author: Eric Auger Date: Tue Nov 26 18:54:13 2019 +0100 iommu: fix KASAN use-after-free in iommu_insert_resv_region commit 4c80ba392bf603d468ea827d902f8e7b2505fbf4 upstream. In case the new region gets merged into another one, the nr list node is freed. Checking its type while completing the merge algorithm leads to a use-after-free. Use new->type instead. Fixes: 4dbd258ff63e ("iommu: Revisit iommu_insert_resv_region() implementation") Signed-off-by: Eric Auger Reported-by: Qian Cai Reviewed-by: Jerry Snitselaar Cc: Stable #v5.3+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 4d6ebc4c4950595414722dfadd0b361f5a05d37e Author: Tadeusz Struk Date: Thu Dec 12 09:48:47 2019 -0800 tpm: fix invalid locking in NONBLOCKING mode commit d23d12484307b40eea549b8a858f5fffad913897 upstream. When an application sends TPM commands in NONBLOCKING mode the driver holds chip->tpm_mutex returning from write(), which triggers: "WARNING: lock held when returning to user space". To fix this issue the driver needs to release the mutex before returning and acquire it again in tpm_dev_async_work() before sending the command. Cc: stable@vger.kernel.org Fixes: 9e1b74a63f776 (tpm: add support for nonblocking operation) Reported-by: Jeffrin Jose T Tested-by: Jeffrin Jose T Signed-off-by: Tadeusz Struk Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit fed4697a04ad49a9caa10bee91380d05f7000603 Author: Jerry Snitselaar Date: Wed Dec 11 16:54:55 2019 -0700 tpm_tis: reserve chip for duration of tpm_tis_core_init commit 21df4a8b6018b842d4db181a8b24166006bad3cd upstream. Instead of repeatedly calling tpm_chip_start/tpm_chip_stop when issuing commands to the tpm during initialization, just reserve the chip after wait_startup, and release it when we are ready to call tpm_chip_register. Cc: Christian Bundy Cc: Dan Williams Cc: Peter Huewe Cc: Jarkko Sakkinen Cc: Jason Gunthorpe Cc: Stefan Berger Cc: stable@vger.kernel.org Cc: linux-integrity@vger.kernel.org Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()") Fixes: 5b359c7c4372 ("tpm_tis_core: Turn on the TPM before probing IRQ's") Suggested-by: Jarkko Sakkinen Reviewed-by: Jarkko Sakkinen Signed-off-by: Jerry Snitselaar Signed-off-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman commit 20fc615306d0cc4124487856b48ce4d8d4fcabed Author: Chaotian Jing Date: Wed Dec 4 15:19:58 2019 +0800 mmc: mediatek: fix CMD_TA to 2 for MT8173 HS200/HS400 mode commit 8f34e5bd7024d1ffebddd82d7318b1be17be9e9a upstream. there is a chance that always get response CRC error after HS200 tuning, the reason is that need set CMD_TA to 2. this modification is only for MT8173. Signed-off-by: Chaotian Jing Tested-by: Hsin-Yi Wang Cc: stable@vger.kernel.org Fixes: 1ede5cb88a29 ("mmc: mediatek: Use data tune for CMD line tune") Link: https://lore.kernel.org/r/20191204071958.18553-1-chaotian.jing@mediatek.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit e4425c477aceb70ebf9cff06f003f32b02cad3cd Author: Faiz Abbas Date: Thu Nov 28 16:34:22 2019 +0530 Revert "mmc: sdhci: Fix incorrect switch to HS mode" commit 07bcc411567cb96f9d1fc84fff8d387118a2920d upstream. This reverts commit c894e33ddc1910e14d6f2a2016f60ab613fd8b37. This commit aims to treat SD High speed and SDR25 as the same while setting UHS Timings in HOST_CONTROL2 which leads to failures with some SD cards in AM65x. Revert this commit. The issue this commit was trying to fix can be implemented in a platform specific callback instead of common sdhci code. Cc: Signed-off-by: Faiz Abbas Acked-by: Adrian Hunter Link: https://lore.kernel.org/r/20191128110422.25917-1-faiz_abbas@ti.com Signed-off-by: Ulf Hansson Signed-off-by: Greg Kroah-Hartman commit 60c7663ac640513e90b99f42583164691abe4aa9 Author: Omar Sandoval Date: Mon Sep 16 11:30:56 2019 -0700 btrfs: don't prematurely free work in scrub_missing_raid56_worker() [ Upstream commit 57d4f0b863272ba04ba85f86bfdc0f976f0af91c ] Currently, scrub_missing_raid56_worker() puts and potentially frees sblock (which embeds the work item) and then submits a bio through scrub_wr_submit(). This is another potential instance of the bug in "btrfs: don't prematurely free work in run_ordered_work()". Fix it by dropping the reference after we submit the bio. Reviewed-by: Johannes Thumshirn Signed-off-by: Omar Sandoval Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 736d28c70489e1ff2600dff2211d2b4597d8d45c Author: Omar Sandoval Date: Mon Sep 16 11:30:55 2019 -0700 btrfs: don't prematurely free work in reada_start_machine_worker() [ Upstream commit e732fe95e4cad35fc1df278c23a32903341b08b3 ] Currently, reada_start_machine_worker() frees the reada_machine_work and then calls __reada_start_machine() to do readahead. This is another potential instance of the bug in "btrfs: don't prematurely free work in run_ordered_work()". There _might_ already be a deadlock here: reada_start_machine_worker() can depend on itself through stacked filesystems (__read_start_machine() -> reada_start_machine_dev() -> reada_tree_block_flagged() -> read_extent_buffer_pages() -> submit_one_bio() -> btree_submit_bio_hook() -> btrfs_map_bio() -> submit_stripe_bio() -> submit_bio() onto a loop device can trigger readahead on the lower filesystem). Either way, let's fix it by freeing the work at the end. Reviewed-by: Johannes Thumshirn Signed-off-by: Omar Sandoval Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit dc9d0a75ce9af74612d6a4d052e4df2bddfe8ed4 Author: Paul Burton Date: Mon Oct 7 12:58:44 2019 -0700 MIPS: futex: Restore \n after sync instructions [ Upstream commit fd7710cb491f900eb63d2ce5aac0e682003e84e9 ] Commit 3c1d3f097972 ("MIPS: futex: Emit Loongson3 sync workarounds within asm") inadvertently removed the newlines following __WEAK_LLSC_MB, which causes build failures for configurations in which __WEAK_LLSC_MB expands to a sync instruction: {standard input}: Assembler messages: {standard input}:9346: Error: symbol `sync3' is already defined {standard input}:9380: Error: symbol `sync3' is already defined ... Fix this by restoring the newlines to separate the sync instruction from anything following it (such as the 3: label), preventing inadvertent concatenation. Signed-off-by: Paul Burton Fixes: 3c1d3f097972 ("MIPS: futex: Emit Loongson3 sync workarounds within asm") Signed-off-by: Sasha Levin commit a18a0a5a50e59ec12d1fddabbd699e25b0e43d59 Author: Alexander Lobakin Date: Wed Nov 27 12:41:23 2019 +0300 net: wireless: intel: iwlwifi: fix GRO_NORMAL packet stalling [ Upstream commit b167191e2a851cb2e4c6ef8b91c83ff73ef41872 ] Commit 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()") has applied batched GRO_NORMAL packets processing to all napi_gro_receive() users, including mac80211-based drivers. However, this change has led to a regression in iwlwifi driver [1][2] as it is required for NAPI users to call napi_complete_done() or napi_complete() and the end of every polling iteration, whilst iwlwifi doesn't use NAPI scheduling at all and just calls napi_gro_flush(). In that particular case, packets which have not been already flushed from napi->rx_list stall in it until at least next Rx cycle. Fix this by adding a manual flushing of the list to iwlwifi driver right before napi_gro_flush() call to mimic napi_complete() logics. I prefer to open-code gro_normal_list() rather than exporting it for 2 reasons: * to prevent from using it and napi_gro_flush() in any new drivers, as it is the *really* bad way to use NAPI that should be avoided; * to keep gro_normal_list() static and don't lose any CC optimizations. I also don't add the "Fixes:" tag as the mentioned commit was only a trigger that only exposed an improper usage of NAPI in this particular driver. [1] https://lore.kernel.org/netdev/PSXP216MB04388962C411CD0B17A86F47804A0@PSXP216MB0438.KORP216.PROD.OUTLOOK.COM [2] https://bugzilla.kernel.org/show_bug.cgi?id=205647 Signed-off-by: Alexander Lobakin Acked-by: Luca Coelho Reported-by: Nicholas Johnson Tested-by: Nicholas Johnson Reviewed-by: Edward Cree Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ce190475a8187121196cfe51e95b3b22d5e8a2b2 Author: Thomas Falcon Date: Mon Nov 25 17:12:53 2019 -0600 ibmvnic: Fix completion structure initialization [ Upstream commit 070eca955c4af1248cb78a216463ff757a5dc511 ] Fix multiple calls to init_completion for device completion structures. Instead, initialize them during device probe and reinitialize them later as needed. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5a8ca605178f40409aa05205a79293ef33b8bd52 Author: Luke Starrett Date: Thu Nov 21 01:22:21 2019 -0500 RDMA/bnxt_re: Fix chip number validation Broadcom's Gen P5 series [ Upstream commit e284b159c6881c8bec9713daba2653268f4c4948 ] In the first version of Gen P5 ASIC, chip-id was always set to 0x1750 for all adaptor port configurations. This has been fixed in the new chip rev. Due to this missing fix users are not able to use adaptors based on latest chip rev of Broadcom's Gen P5 adaptors. Fixes: ae8637e13185 ("RDMA/bnxt_re: Add chip context to identify 57500 series") Link: https://lore.kernel.org/r/1574317343-23300-2-git-send-email-devesh.sharma@broadcom.com Signed-off-by: Naresh Kumar PBS Signed-off-by: Selvin Xavier Signed-off-by: Luke Starrett Signed-off-by: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit b4de258dede528f88f401259aab3147fb6da1ddf Author: Yonghong Song Date: Thu Nov 21 09:06:50 2019 -0800 bpf: Provide better register bounds after jmp32 instructions [ Upstream commit 581738a681b6faae5725c2555439189ca81c0f1f ] With latest llvm (trunk https://github.com/llvm/llvm-project), test_progs, which has +alu32 enabled, failed for strobemeta.o. The verifier output looks like below with edit to replace large decimal numbers with hex ones. 193: (85) call bpf_probe_read_user_str#114 R0=inv(id=0) 194: (26) if w0 > 0x1 goto pc+4 R0_w=inv(id=0,umax_value=0xffffffff00000001) 195: (6b) *(u16 *)(r7 +80) = r0 196: (bc) w6 = w0 R6_w=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) 197: (67) r6 <<= 32 R6_w=inv(id=0,smax_value=0x7fffffff00000000,umax_value=0xffffffff00000000, var_off=(0x0; 0xffffffff00000000)) 198: (77) r6 >>= 32 R6=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 201: (79) r8 = *(u64 *)(r10 -416) R8_w=map_value(id=0,off=40,ks=4,vs=13872,imm=0) 202: (0f) r8 += r6 R8_w=map_value(id=0,off=40,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) 203: (07) r8 += 9696 R8_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 255: (bf) r1 = r8 R1_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=0xffffffff,var_off=(0x0; 0xffffffff)) ... 257: (85) call bpf_probe_read_user_str#114 R1 unbounded memory access, make sure to bounds check any array access into a map The value range for register r6 at insn 198 should be really just 0/1. The umax_value=0xffffffff caused later verification failure. After jmp instructions, the current verifier already tried to use just obtained information to get better register range. The current mechanism is for 64bit register only. This patch implemented to tighten the range for 32bit sub-registers after jmp32 instructions. With the patch, we have the below range ranges for the above code sequence: 193: (85) call bpf_probe_read_user_str#114 R0=inv(id=0) 194: (26) if w0 > 0x1 goto pc+4 R0_w=inv(id=0,smax_value=0x7fffffff00000001,umax_value=0xffffffff00000001, var_off=(0x0; 0xffffffff00000001)) 195: (6b) *(u16 *)(r7 +80) = r0 196: (bc) w6 = w0 R6_w=inv(id=0,umax_value=0xffffffff,var_off=(0x0; 0x1)) 197: (67) r6 <<= 32 R6_w=inv(id=0,umax_value=0x100000000,var_off=(0x0; 0x100000000)) 198: (77) r6 >>= 32 R6=inv(id=0,umax_value=1,var_off=(0x0; 0x1)) ... 201: (79) r8 = *(u64 *)(r10 -416) R8_w=map_value(id=0,off=40,ks=4,vs=13872,imm=0) 202: (0f) r8 += r6 R8_w=map_value(id=0,off=40,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) 203: (07) r8 += 9696 R8_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) ... 255: (bf) r1 = r8 R1_w=map_value(id=0,off=9736,ks=4,vs=13872,umax_value=1,var_off=(0x0; 0x1)) ... 257: (85) call bpf_probe_read_user_str#114 ... At insn 194, the register R0 has better var_off.mask and smax_value. Especially, the var_off.mask ensures later lshift and rshift maintains proper value range. Suggested-by: Alexei Starovoitov Signed-off-by: Yonghong Song Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191121170650.449030-1-yhs@fb.com Signed-off-by: Sasha Levin commit 742ba7a94ad29302c6f835d948c0130cdfb08ff0 Author: Devesh Sharma Date: Thu Nov 21 01:22:22 2019 -0500 RDMA/bnxt_re: Fix stat push into dma buffer on gen p5 devices [ Upstream commit 98998ffe5216c7fa2c0225bb5b049ca5cdf8d195 ] Due to recent advances in the firmware for Broadcom's gen p5 series of adaptors the driver code to report hardware counters has been broken w.r.t. roce devices. The new firmware command expects dma length to be specified during stat dma buffer allocation. Fixes: 2792b5b95ed5 ("bnxt_en: Update firmware interface spec. to 1.10.0.89.") Link: https://lore.kernel.org/r/1574317343-23300-3-git-send-email-devesh.sharma@broadcom.com Signed-off-by: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 026ecd6afd8b54236e79345fe412cf3610ad4c65 Author: Devesh Sharma Date: Thu Nov 21 01:22:23 2019 -0500 RDMA/bnxt_re: Fix missing le16_to_cpu [ Upstream commit fca5b9dc0986aa49b3f0a7cfe24b6c82422ac1d7 ] From sparse: drivers/infiniband/hw/bnxt_re/main.c:1274:18: warning: cast from restricted __le16 drivers/infiniband/hw/bnxt_re/main.c:1275:18: warning: cast from restricted __le16 drivers/infiniband/hw/bnxt_re/main.c:1276:18: warning: cast from restricted __le16 drivers/infiniband/hw/bnxt_re/main.c:1277:21: warning: restricted __le16 degrades to integer Fixes: 2b827ea1926b ("RDMA/bnxt_re: Query HWRM Interface version from FW") Link: https://lore.kernel.org/r/1574317343-23300-4-git-send-email-devesh.sharma@broadcom.com Signed-off-by: Devesh Sharma Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 94a351034345abcb6b3c13b5e4100af93a9201e6 Author: Quentin Monnet Date: Tue Nov 19 10:56:26 2019 +0000 tools, bpf: Fix build for 'make -s tools/bpf O=' [ Upstream commit a89b2cbf71d64b61e79bbe5cb7ff4664797eeaaf ] Building selftests with 'make TARGETS=bpf kselftest' was fixed in commit 55d554f5d140 ("tools: bpf: Use !building_out_of_srctree to determine srctree"). However, by updating $(srctree) in tools/bpf/Makefile for in-tree builds only, we leave out the case where we pass an output directory to build BPF tools, but $(srctree) is not set. This typically happens for: $ make -s tools/bpf O=/tmp/foo Makefile:40: /tools/build/Makefile.feature: No such file or directory Fix it by updating $(srctree) in the Makefile not only for out-of-tree builds, but also if $(srctree) is empty. Detected with test_bpftool_build.sh. Fixes: 55d554f5d140 ("tools: bpf: Use !building_out_of_srctree to determine srctree") Signed-off-by: Quentin Monnet Signed-off-by: Daniel Borkmann Acked-by: Jakub Kicinski Link: https://lore.kernel.org/bpf/20191119105626.21453-1-quentin.monnet@netronome.com Signed-off-by: Sasha Levin commit 217dcccc8dc27400187a1569a1b0f653727fe285 Author: Russell King Date: Fri Nov 22 15:23:23 2019 +0000 net: phy: initialise phydev speed and duplex sanely [ Upstream commit a5d66f810061e2dd70fb7a108dcd14e535bc639f ] When a phydev is created, the speed and duplex are set to zero and -1 respectively, rather than using the predefined SPEED_UNKNOWN and DUPLEX_UNKNOWN constants. There is a window at initialisation time where we may report link down using the 0/-1 values. Tidy this up and use the predefined constants, so debug doesn't complain with: "Unsupported (update phy-core.c)/Unsupported (update phy-core.c)" when the speed and duplex settings are printed. Signed-off-by: Russell King Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 3e3e341d1f4584beffbf276d00adf6e2c35bda92 Author: Brett Creeley Date: Fri Nov 8 06:23:23 2019 -0800 ice: Fix setting coalesce to handle DCB configuration [ Upstream commit e25f9152bc07de534b2b590ce6c052ea25dd8900 ] Currently there can be a case where a DCB map is applied and there are more interrupt vectors (vsi->num_q_vectors) than Rx queues (vsi->num_rxq) and Tx queues (vsi->num_txq). If we try to set coalesce settings in this case it will report a false failure. Fix this by checking if vector index is valid with respect to the number of Tx and Rx queues configured. Signed-off-by: Brett Creeley Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit b533200b40334bd86caa737b0ff033ecc391d071 Author: Akeem G Abodunrin Date: Fri Nov 8 06:23:22 2019 -0800 ice: Only disable VF state when freeing each VF resources [ Upstream commit 1f9639d2fb9188a59acafae9dea626391c442a8d ] It is wrong to set PF disable state flag for all VFs when freeing VF resources - Instead, we should set VF disable state flag for each VF with its resources being returned to the device. Right now, all VF opcodes, mailbox communication to clear its resources as well fails - since we already indicate that PF is in disable state, with all VFs not active. In addition, we don't need to notify VF that PF is intending to reset it, if it is already in disabled state. Signed-off-by: Akeem G Abodunrin Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 44d40114eecb7b3269258bed65d50bd4d2ce2aef Author: Sam Bobroff Date: Mon Nov 18 10:53:54 2019 +1100 drm/amdgpu: fix bad DMA from INTERRUPT_CNTL2 [ Upstream commit 3d0e3ce52ce3eb4b9de3caf9c38dbb5a4d3e13c3 ] The INTERRUPT_CNTL2 register expects a valid DMA address, but is currently set with a GPU MC address. This can cause problems on systems that detect the resulting DMA read from an invalid address (found on a Power8 guest). Instead, use the DMA address of the dummy page because it will always be safe. Fixes: 27ae10641e9c ("drm/amdgpu: add interupt handler implementation for si v3") Signed-off-by: Sam Bobroff Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 6d98463304f4a23ee6e63e3a7a07f88762f6eaf6 Author: Mike Rapoport Date: Thu Nov 21 18:21:31 2019 +0200 mips: fix build when "48 bits virtual memory" is enabled [ Upstream commit 3ed6751bb8fa89c3014399bb0414348499ee202a ] With CONFIG_MIPS_VA_BITS_48=y the build fails miserably: CC arch/mips/kernel/asm-offsets.s In file included from arch/mips/include/asm/pgtable.h:644, from include/linux/mm.h:99, from arch/mips/kernel/asm-offsets.c:15: include/asm-generic/pgtable.h:16:2: error: #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED ^~~~~ include/asm-generic/pgtable.h:390:28: error: unknown type name 'p4d_t'; did you mean 'pmd_t'? static inline int p4d_same(p4d_t p4d_a, p4d_t p4d_b) ^~~~~ pmd_t [ ... more such errors ... ] scripts/Makefile.build:99: recipe for target 'arch/mips/kernel/asm-offsets.s' failed make[2]: *** [arch/mips/kernel/asm-offsets.s] Error 1 This happens because when CONFIG_MIPS_VA_BITS_48 enables 4th level of the page tables, but neither pgtable-nop4d.h nor 5level-fixup.h are included to cope with the 5th level. Replace #ifdef conditions around includes of the pgtable-nop{m,u}d.h with explicit CONFIG_PGTABLE_LEVELS and add include of 5level-fixup.h for the case when CONFIG_PGTABLE_LEVELS==4 Signed-off-by: Mike Rapoport Signed-off-by: Paul Burton Cc: Ralf Baechle Cc: James Hogan Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org Cc: Mike Rapoport Signed-off-by: Sasha Levin commit aa62f850b53d85da701d67ecc22e55d720b84042 Author: Hewenliang Date: Mon Nov 18 20:44:15 2019 -0500 libtraceevent: Fix memory leakage in copy_filter_type [ Upstream commit 10992af6bf46a2048ad964985a5b77464e5563b1 ] It is necessary to free the memory that we have allocated when error occurs. Fixes: ef3072cd1d5c ("tools lib traceevent: Get rid of die in add_filter_type()") Signed-off-by: Hewenliang Reviewed-by: Steven Rostedt (VMware) Cc: Tzvetomir Stoyanov Link: http://lore.kernel.org/lkml/20191119014415.57210-1-hewenliang4@huawei.com Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ef88bd1fdb871b39d38f4d23accdf7a26b2acb21 Author: Michael Ellerman Date: Wed Nov 20 22:27:38 2019 +1100 crypto: vmx - Avoid weird build failures [ Upstream commit 4ee812f6143d78d8ba1399671d78c8d78bf2817c ] In the vmx crypto Makefile we assign to a variable called TARGET and pass that to the aesp8-ppc.pl and ghashp8-ppc.pl scripts. The variable is meant to describe what flavour of powerpc we're building for, eg. either 32 or 64-bit, and big or little endian. Unfortunately TARGET is a fairly common name for a make variable, and if it happens that TARGET is specified as a command line parameter to make, the value specified on the command line will override our value. In particular this can happen if the kernel Makefile is driven by an external Makefile that uses TARGET for something. This leads to weird build failures, eg: nonsense at /build/linux/drivers/crypto/vmx/ghashp8-ppc.pl line 45. /linux/drivers/crypto/vmx/Makefile:20: recipe for target 'drivers/crypto/vmx/ghashp8-ppc.S' failed Which shows that we passed an empty value for $(TARGET) to the perl script, confirmed with make V=1: perl /linux/drivers/crypto/vmx/ghashp8-ppc.pl > drivers/crypto/vmx/ghashp8-ppc.S We can avoid this confusion by using override, to tell make that we don't want anything to override our variable, even a value specified on the command line. We can also use a less common name, given the script calls it "flavour", let's use that. Signed-off-by: Michael Ellerman Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e160bb158da57e254b226e608ba209e8734c5f5f Author: Thomas Pedersen Date: Mon Nov 18 21:35:38 2019 -0800 mac80211: consider QoS Null frames for STA_NULLFUNC_ACKED [ Upstream commit 08a5bdde3812993cb8eb7aa9124703df0de28e4b ] Commit 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing") let STAs send QoS Null frames as PS triggers if the AP was a QoS STA. However, the mac80211 PS stack relies on an interface flag IEEE80211_STA_NULLFUNC_ACKED for determining trigger frame ACK, which was not being set for acked non-QoS Null frames. The effect is an inability to trigger hardware sleep via IEEE80211_CONF_PS since the QoS Null frame was seemingly never acked. This bug only applies to drivers which set both IEEE80211_HW_REPORTS_TX_ACK_STATUS and IEEE80211_HW_PS_NULLFUNC_STACK. Detect the acked QoS Null frame to restore STA power save. Fixes: 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing") Signed-off-by: Thomas Pedersen Link: https://lore.kernel.org/r/20191119053538.25979-4-thomas@adapt-ip.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 39dda3d4651cd16c3555fb618542f77044e15532 Author: Corentin Labbe Date: Thu Nov 14 11:49:06 2019 +0100 crypto: sun4i-ss - Fix 64-bit size_t warnings on sun4i-ss-hash.c [ Upstream commit a7126603d46fe8f01aeedf589e071c6aaa6c6c39 ] If you try to compile this driver on a 64-bit platform then you will get warnings because it mixes size_t with unsigned int which only works on 32-bit. This patch fixes all of the warnings on sun4i-ss-hash.c. Signed-off-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit e4f65f5ea7f4f7100fe8174ea91c4030fe4adff0 Author: Herbert Xu Date: Tue Nov 12 10:38:34 2019 +0800 crypto: sun4i-ss - Fix 64-bit size_t warnings [ Upstream commit d6e9da21ee8246b5e556b3b153401ab045adb986 ] If you try to compile this driver on a 64-bit platform then you will get warnings because it mixes size_t with unsigned int which only works on 32-bit. This patch fixes all of the warnings. Signed-off-by: Herbert Xu Acked-by: Corentin Labbe Tested-by: Corentin Labbe Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 6549e9ccf3442b17e061960c0ca83a7d3d9d8fd0 Author: Thomas Richter Date: Fri Nov 15 12:50:46 2019 +0100 s390/cpumf: Adjust registration of s390 PMU device drivers [ Upstream commit 6a82e23f45fe0aa821e7a935e39d0acb20c275c0 ] Linux-next commit titled "perf/core: Optimize perf_init_event()" changed the semantics of PMU device driver registration. It was done to speed up the lookup/handling of PMU device driver specific events. It also enforces that only one PMU device driver will be registered of type PERF_EVENT_RAW. This change added these line in function perf_pmu_register(): ... + ret = idr_alloc(&pmu_idr, pmu, max, 0, GFP_KERNEL); + if (ret < 0) goto free_pdc; + + WARN_ON(type >= 0 && ret != type); The warn_on generates a message. We have 3 PMU device drivers, each registered as type PERF_TYPE_RAW. The cf_diag device driver (arch/s390/kernel/perf_cpumf_cf_diag.c) always hits the WARN_ON because it is the second PMU device driver (after sampling device driver arch/s390/kernel/perf_cpumf_sf.c) which is registered as type 4 (PERF_TYPE_RAW). So when the sampling device driver is registered, ret has value 4. When cf_diag device driver is registered with type 4, ret has value of 5 and WARN_ON fires. Adjust the PMU device drivers for s390 to support the new semantics required by perf_pmu_register(). Signed-off-by: Thomas Richter Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 44a9b673a779ed8aa3bdbb1e9b655e78f22ff322 Author: Lorenzo Bianconi Date: Thu Nov 7 01:01:58 2019 +0200 mt76: fix possible out-of-bound access in mt7615_fill_txs/mt7603_fill_txs [ Upstream commit e8b970c8e367e85fab9b8ac4f36080e5d653c38e ] Fix possible out-of-bound access of status rates array in mt7615_fill_txs/mt7603_fill_txs routines Fixes: c5211e997eca ("mt76: mt7603: rework and fix tx status reporting") Fixes: 4af81f02b49c ("mt76: mt7615: sync with mt7603 rate control changes") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin commit 328e10566b2421a0e18b08b67b96fbc5e2ec89d6 Author: Grygorii Strashko Date: Wed Nov 20 00:19:13 2019 +0200 net: ethernet: ti: ale: clean ale tbl on init and intf restart [ Upstream commit 7fe579dfb90fcdf0c7722f33c772d5f0d1bc7cb6 ] Clean CPSW ALE on init and intf restart (up/down) to avoid reading obsolete or garbage entries from ALE table. Signed-off-by: Grygorii Strashko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit bc155e25a062dc18272a9d18622d1940c4f2ac58 Author: Shengjiu Wang Date: Tue Nov 12 18:46:42 2019 +0800 ASoC: soc-pcm: check symmetry before hw_params [ Upstream commit 5cca59516de5df9de6bdecb328dd55fb5bcccb41 ] This reverts commit 957ce0c6b8a1f (ASoC: soc-pcm: check symmetry after hw_params). That commit cause soc_pcm_params_symmetry can't take effect. cpu_dai->rate, cpu_dai->channels and cpu_dai->sample_bits are updated in the middle of soc_pcm_hw_params, so move soc_pcm_params_symmetry to the end of soc_pcm_hw_params is not a good solution, for judgement of symmetry in the function is always true. FIXME: According to the comments of that commit, I think the case described in the commit should disable symmetric_rates in Back-End, rather than changing the position of soc_pcm_params_symmetry. Signed-off-by: Shengjiu Wang Link: https://lore.kernel.org/r/1573555602-5403-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 88540bc176e9e572e5482aef94727aed2b2c2cfe Author: Andy Shevchenko Date: Wed Nov 20 11:57:12 2019 +0200 fbtft: Make sure string is NULL terminated [ Upstream commit 21f585480deb4bcf0d92b08879c35d066dfee030 ] New GCC warns about inappropriate use of strncpy(): drivers/staging/fbtft/fbtft-core.c: In function ‘fbtft_framebuffer_alloc’: drivers/staging/fbtft/fbtft-core.c:665:2: warning: ‘strncpy’ specified bound 16 equals destination size [-Wstringop-truncation] 665 | strncpy(info->fix.id, dev->driver->name, 16); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Later on the copy is being used with the assumption to be NULL terminated. Make sure string is NULL terminated by switching to snprintf(). Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20191120095716.26628-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a1c90bd0de88b2934f2aa14cd350e6da11d7a3ed Author: Johannes Berg Date: Tue Nov 5 14:50:32 2019 +0100 iwlwifi: check kasprintf() return value [ Upstream commit 5974fbb5e10b018fdbe3c3b81cb4cc54e1105ab9 ] kasprintf() can fail, we should check the return value. Fixes: 5ed540aecc2a ("iwlwifi: use mac80211 throughput trigger") Fixes: 8ca151b568b6 ("iwlwifi: add the MVM driver") Signed-off-by: Johannes Berg Signed-off-by: Luca Coelho Signed-off-by: Sasha Levin commit 70d3d1aa96f9b5ef9352259f8add983393f81c41 Author: Michael Chan Date: Mon Nov 18 03:56:36 2019 -0500 bnxt_en: Improve RX buffer error handling. [ Upstream commit 19b3751ffa713d04290effb26fe01009010f2206 ] When hardware reports RX buffer errors, the latest 57500 chips do not require reset. The packet is discarded by the hardware and the ring will continue to operate. Also, add an rx_buf_errors counter for this type of error. It can help the user to identify if the aggregation ring is too small. Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 135d2d65f2f53a926dc35627cb964448ee6f155c Author: Vasily Gorbik Date: Tue Nov 5 17:33:20 2019 +0100 s390/kasan: support memcpy_real with TRACE_IRQFLAGS [ Upstream commit 13f9bae579c6bd051e58f326913dd09af1291208 ] Currently if the kernel is built with CONFIG_TRACE_IRQFLAGS and KASAN and used as crash kernel it crashes itself due to trace_hardirqs_off/trace_hardirqs_on being called with DAT off. This happens because trace_hardirqs_off/trace_hardirqs_on are instrumented and kasan code tries to perform access to shadow memory to validate memory accesses. Kasan shadow memory is populated with vmemmap, so all accesses require DAT on. memcpy_real could be called with DAT on or off (with kasan enabled DAT is set even before early code is executed). Make sure that trace_hardirqs_off/trace_hardirqs_on are called with DAT on and only actual __memcpy_real is called with DAT off. Also annotate __memcpy_real and _memcpy_real with __no_sanitize_address to avoid further problems due to switching DAT off. Reviewed-by: Philipp Rudo Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 0cb1eb800adeaf2503dcd1534392d3f8b4c5065c Author: YueHaibing Date: Thu Nov 14 15:30:05 2019 +0800 s390/crypto: Fix unsigned variable compared with zero [ Upstream commit 0398d4ab1677f7d8cd43aac2aa29a93dfcf9e2e3 ] s390_crypto_shash_parmsize() return type is int, it should not be stored in a unsigned variable, which compared with zero. Reported-by: Hulk Robot Fixes: 3c2eb6b76cab ("s390/crypto: Support for SHA3 via CPACF (MSA6)") Signed-off-by: YueHaibing Signed-off-by: Joerg Schmidbauer Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 0a12ce14c667e27b4e6219aa4a01377f5574fda6 Author: Masami Hiramatsu Date: Thu Oct 24 18:12:54 2019 +0900 perf probe: Fix to show function entry line as probe-able commit 91e2f539eeda26ab00bd03fae8dc434c128c85ed upstream. Fix die_walk_lines() to list the function entry line correctly. Since the dwarf_entrypc() does not return the entry pc if the DIE has only range attribute, __die_walk_funclines() fails to list the declaration line (entry line) in that case. To solve this issue, this introduces die_entrypc() which correctly returns the entry PC (the first address range) even if the DIE has only range attribute. With this fix die_walk_lines() shows the function entry line is able to probe correctly. Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface") Signed-off-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157190837419.1859.4619125803596816752.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman commit 4091afe8063bd00e10b391a62c04dfe01e2fd710 Author: Alexey Budankov Date: Mon Nov 18 17:21:03 2019 +0300 perf session: Fix decompression of PERF_RECORD_COMPRESSED records [ Upstream commit bb1835a3b86c73aa534ef6430ad40223728dfbc0 ] Avoid termination of trace loading in case the last record in the decompressed buffer partly resides in the following mmaped PERF_RECORD_COMPRESSED record. In this case NULL value returned by fetch_mmaped_event() means to proceed to the next mmaped record then decompress it and load compressed events. The issue can be reproduced like this: $ perf record -z -- some_long_running_workload $ perf report --stdio -vv decomp (B): 44519 to 163000 decomp (B): 48119 to 174800 decomp (B): 65527 to 131072 fetch_mmaped_event: head=0x1ffe0 event->header_size=0x28, mmap_size=0x20000: fuzzed perf.data? Error: failed to process sample ... Testing: 71: Zstd perf.data compression/decompression : Ok $ tools/perf/perf report -vv --stdio decomp (B): 59593 to 262160 decomp (B): 4438 to 16512 decomp (B): 285 to 880 Looking at the vmlinux_path (8 entries long) Using vmlinux for symbols decomp (B): 57474 to 261248 prefetch_event: head=0x3fc78 event->header_size=0x28, mmap_size=0x3fc80: fuzzed or compressed perf.data? decomp (B): 25 to 32 decomp (B): 52 to 120 ... Fixes: 57fc032ad643 ("perf session: Avoid infinite loop when seeing invalid header.size") Link: https://marc.info/?l=linux-kernel&m=156580812427554&w=2 Co-developed-by: Jiri Olsa Acked-by: Jiri Olsa Signed-off-by: Alexey Budankov Cc: Alexander Shishkin Cc: Andi Kleen Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/cf782c34-f3f8-2f9f-d6ab-145cee0d5322@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 0c39cad81df18549c0252a3e99304b84a2514219 Author: Rafał Miłecki Date: Mon Nov 18 13:38:55 2019 +0100 brcmfmac: remove monitor interface when detaching [ Upstream commit 4f61563da075bc8faefddfd5f8fc0cc14c49650a ] This fixes a minor WARNING in the cfg80211: [ 130.658034] ------------[ cut here ]------------ [ 130.662805] WARNING: CPU: 1 PID: 610 at net/wireless/core.c:954 wiphy_unregister+0xb4/0x198 [cfg80211] Signed-off-by: Rafał Miłecki Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d5225f32477756fbba5457d037aacfc62ecc0d86 Author: Luigi Rizzo Date: Mon Nov 18 16:19:51 2019 -0800 net-af_xdp: Use correct number of channels from ethtool [ Upstream commit 3de88c9113f88c04abda339f1aa629397bf89e02 ] Drivers use different fields to report the number of channels, so take the maximum of all data channels (rx, tx, combined) when determining the size of the xsk map. The current code used only 'combined' which was set to 0 in some drivers e.g. mlx4. Tested: compiled and run xdpsock -q 3 -r -S on mlx4 Signed-off-by: Luigi Rizzo Signed-off-by: Alexei Starovoitov Reviewed-by: Jakub Kicinski Acked-by: Magnus Karlsson Link: https://lore.kernel.org/bpf/20191119001951.92930-1-lrizzo@google.com Signed-off-by: Sasha Levin commit c1efcafe887ccc242c58d0d9a7292e81205b10e2 Author: Adrian Hunter Date: Fri Nov 15 15:54:47 2019 +0200 x86/insn: Add some Intel instructions to the opcode map [ Upstream commit b980be189c9badba50634671e2303e92bf28e35a ] Add to the opcode map the following instructions: cldemote tpause umonitor umwait movdiri movdir64b enqcmd enqcmds encls enclu enclv pconfig wbnoinvd For information about the instructions, refer Intel SDM May 2019 (325462-070US) and Intel Architecture Instruction Set Extensions May 2019 (319433-037). The instruction decoding can be tested using the perf tools' "x86 instruction decoder - new instructions" test as folllows: $ perf test -v "new " 2>&1 | grep -i cldemote Decoded ok: 0f 1c 00 cldemote (%eax) Decoded ok: 0f 1c 05 78 56 34 12 cldemote 0x12345678 Decoded ok: 0f 1c 84 c8 78 56 34 12 cldemote 0x12345678(%eax,%ecx,8) Decoded ok: 0f 1c 00 cldemote (%rax) Decoded ok: 41 0f 1c 00 cldemote (%r8) Decoded ok: 0f 1c 04 25 78 56 34 12 cldemote 0x12345678 Decoded ok: 0f 1c 84 c8 78 56 34 12 cldemote 0x12345678(%rax,%rcx,8) Decoded ok: 41 0f 1c 84 c8 78 56 34 12 cldemote 0x12345678(%r8,%rcx,8) $ perf test -v "new " 2>&1 | grep -i tpause Decoded ok: 66 0f ae f3 tpause %ebx Decoded ok: 66 0f ae f3 tpause %ebx Decoded ok: 66 41 0f ae f0 tpause %r8d $ perf test -v "new " 2>&1 | grep -i umonitor Decoded ok: 67 f3 0f ae f0 umonitor %ax Decoded ok: f3 0f ae f0 umonitor %eax Decoded ok: 67 f3 0f ae f0 umonitor %eax Decoded ok: f3 0f ae f0 umonitor %rax Decoded ok: 67 f3 41 0f ae f0 umonitor %r8d $ perf test -v "new " 2>&1 | grep -i umwait Decoded ok: f2 0f ae f0 umwait %eax Decoded ok: f2 0f ae f0 umwait %eax Decoded ok: f2 41 0f ae f0 umwait %r8d $ perf test -v "new " 2>&1 | grep -i movdiri Decoded ok: 0f 38 f9 03 movdiri %eax,(%ebx) Decoded ok: 0f 38 f9 88 78 56 34 12 movdiri %ecx,0x12345678(%eax) Decoded ok: 48 0f 38 f9 03 movdiri %rax,(%rbx) Decoded ok: 48 0f 38 f9 88 78 56 34 12 movdiri %rcx,0x12345678(%rax) $ perf test -v "new " 2>&1 | grep -i movdir64b Decoded ok: 66 0f 38 f8 18 movdir64b (%eax),%ebx Decoded ok: 66 0f 38 f8 88 78 56 34 12 movdir64b 0x12345678(%eax),%ecx Decoded ok: 67 66 0f 38 f8 1c movdir64b (%si),%bx Decoded ok: 67 66 0f 38 f8 8c 34 12 movdir64b 0x1234(%si),%cx Decoded ok: 66 0f 38 f8 18 movdir64b (%rax),%rbx Decoded ok: 66 0f 38 f8 88 78 56 34 12 movdir64b 0x12345678(%rax),%rcx Decoded ok: 67 66 0f 38 f8 18 movdir64b (%eax),%ebx Decoded ok: 67 66 0f 38 f8 88 78 56 34 12 movdir64b 0x12345678(%eax),%ecx $ perf test -v "new " 2>&1 | grep -i enqcmd Decoded ok: f2 0f 38 f8 18 enqcmd (%eax),%ebx Decoded ok: f2 0f 38 f8 88 78 56 34 12 enqcmd 0x12345678(%eax),%ecx Decoded ok: 67 f2 0f 38 f8 1c enqcmd (%si),%bx Decoded ok: 67 f2 0f 38 f8 8c 34 12 enqcmd 0x1234(%si),%cx Decoded ok: f3 0f 38 f8 18 enqcmds (%eax),%ebx Decoded ok: f3 0f 38 f8 88 78 56 34 12 enqcmds 0x12345678(%eax),%ecx Decoded ok: 67 f3 0f 38 f8 1c enqcmds (%si),%bx Decoded ok: 67 f3 0f 38 f8 8c 34 12 enqcmds 0x1234(%si),%cx Decoded ok: f2 0f 38 f8 18 enqcmd (%rax),%rbx Decoded ok: f2 0f 38 f8 88 78 56 34 12 enqcmd 0x12345678(%rax),%rcx Decoded ok: 67 f2 0f 38 f8 18 enqcmd (%eax),%ebx Decoded ok: 67 f2 0f 38 f8 88 78 56 34 12 enqcmd 0x12345678(%eax),%ecx Decoded ok: f3 0f 38 f8 18 enqcmds (%rax),%rbx Decoded ok: f3 0f 38 f8 88 78 56 34 12 enqcmds 0x12345678(%rax),%rcx Decoded ok: 67 f3 0f 38 f8 18 enqcmds (%eax),%ebx Decoded ok: 67 f3 0f 38 f8 88 78 56 34 12 enqcmds 0x12345678(%eax),%ecx $ perf test -v "new " 2>&1 | grep -i enqcmds Decoded ok: f3 0f 38 f8 18 enqcmds (%eax),%ebx Decoded ok: f3 0f 38 f8 88 78 56 34 12 enqcmds 0x12345678(%eax),%ecx Decoded ok: 67 f3 0f 38 f8 1c enqcmds (%si),%bx Decoded ok: 67 f3 0f 38 f8 8c 34 12 enqcmds 0x1234(%si),%cx Decoded ok: f3 0f 38 f8 18 enqcmds (%rax),%rbx Decoded ok: f3 0f 38 f8 88 78 56 34 12 enqcmds 0x12345678(%rax),%rcx Decoded ok: 67 f3 0f 38 f8 18 enqcmds (%eax),%ebx Decoded ok: 67 f3 0f 38 f8 88 78 56 34 12 enqcmds 0x12345678(%eax),%ecx $ perf test -v "new " 2>&1 | grep -i encls Decoded ok: 0f 01 cf encls Decoded ok: 0f 01 cf encls $ perf test -v "new " 2>&1 | grep -i enclu Decoded ok: 0f 01 d7 enclu Decoded ok: 0f 01 d7 enclu $ perf test -v "new " 2>&1 | grep -i enclv Decoded ok: 0f 01 c0 enclv Decoded ok: 0f 01 c0 enclv $ perf test -v "new " 2>&1 | grep -i pconfig Decoded ok: 0f 01 c5 pconfig Decoded ok: 0f 01 c5 pconfig $ perf test -v "new " 2>&1 | grep -i wbnoinvd Decoded ok: f3 0f 09 wbnoinvd Decoded ok: f3 0f 09 wbnoinvd Signed-off-by: Adrian Hunter Reviewed-by: Andi Kleen Acked-by: Masami Hiramatsu Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Jiri Olsa Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: x86@kernel.org Link: http://lore.kernel.org/lkml/20191115135447.6519-3-adrian.hunter@intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit cfadd487aefa4044b46ed97ed10edab6512ce395 Author: Hans de Goede Date: Tue Nov 19 15:51:38 2019 +0100 ASoC: Intel: bytcr_rt5640: Update quirk for Acer Switch 10 SW5-012 2-in-1 [ Upstream commit 0bb887709eb16bdc4b5baddd8337abf3de72917f ] When the Acer Switch 10 SW5-012 quirk was added we did not have jack-detection support yet; and the builtin microphone selection of the original quirk is wrong too. Fix the microphone-input quirk and add jack-detection info so that the internal-microphone and headphone/set jack on the Switch 10 work properly. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191119145138.59162-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ca1a814df742c034d0c6841f0a07dc860440875e Author: Linus Walleij Date: Fri Nov 15 23:59:11 2019 +0100 firmware_loader: Fix labels with comma for builtin firmware [ Upstream commit 553671b7685972ca671da5f71cf6414b54376e13 ] Some firmware images contain a comma, such as: EXTRA_FIRMWARE "brcm/brcmfmac4334-sdio.samsung,gt-s7710.txt" as Broadcom firmware simply tags the device tree compatible string at the end of the firmware parameter file. And the compatible string contains a comma. This doesn't play well with gas: drivers/base/firmware_loader/builtin/brcm/brcmfmac4334-sdio.samsung,gt-s7710.txt.gen.S: Assembler messages: drivers/base/firmware_loader/builtin/brcm/brcmfmac4334-sdio.samsung,gt-s7710.txt.gen.S:4: Error: bad instruction `_fw_brcm_brcmfmac4334_sdio_samsung,gt_s7710_txt_bin:' drivers/base/firmware_loader/builtin/brcm/brcmfmac4334-sdio.samsung,gt-s7710.txt.gen.S:9: Error: bad instruction `_fw_brcm_brcmfmac4334_sdio_samsung,gt_s7710_txt_name:' drivers/base/firmware_loader/builtin/brcm/brcmfmac4334-sdio.samsung,gt-s7710.txt.gen.S:15: Error: can't resolve `.rodata' {.rodata section} - `_fw_brcm_brcmfmac4334_sdio_samsung' {*UND* section} make[6]: *** [../scripts/Makefile.build:357: drivers/base/firmware_loader/builtin/brcm/brcmfmac4334-sdio.samsung,gt-s7710.txt.gen.o] Error 1 We need to get rid of the comma from the labels used by the assembly stub generator. Replacing a comma using GNU Make subst requires a helper variable. Cc: Stephan Gerhold Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20191115225911.3260-1-linus.walleij@linaro.org Acked-by: Luis Chamberlain Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 097b9a11c90c7a37e7777a74bfa1ffd4c59bcbd0 Author: Russell King Date: Fri Nov 15 20:08:37 2019 +0000 net: phy: avoid matching all-ones clause 45 PHY IDs [ Upstream commit b95e86d846b63b02ecdc94802ddbeaf9005fb6d9 ] We currently match clause 45 PHYs using any ID read from a MMD marked as present in the "Devices in package" registers 5 and 6. However, this is incorrect. 45.2 says: "The definition of the term package is vendor specific and could be a chip, module, or other similar entity." so a package could be more or less than the whole PHY - a PHY could be made up of several modules instantiated onto a single chip such as the Marvell 88x3310, or some of the MMDs could be disabled according to chip configuration, such as the Broadcom 84881. In the case of Broadcom 84881, the "Devices in package" registers contain 0xc000009b, meaning that there is a PHYXS present in the package, but all registers in MMD 4 return 0xffff. This leads to our matching code incorrectly binding this PHY to one of our generic PHY drivers. This patch changes the way we determine whether to attempt to match a MMD identifier, or use it to request a module - if the identifier is all-ones, then we skip over it. When reading the identifiers, we initialise phydev->c45_ids.device_ids to all-ones, only reading the device ID if the "Devices in package" registers indicates we should. This avoids the generic drivers incorrectly matching on a PHY ID of 0xffffffff. Signed-off-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f462c417ceba361ddc691526c49e2d0920253369 Author: Vasundhara Volam Date: Mon Nov 18 03:56:41 2019 -0500 bnxt_en: Return proper error code for non-existent NVM variable [ Upstream commit 05069dd4c577f9b143dfd243d55834333c4470c5 ] For NVM params that are not supported in the current NVM configuration, return the error as -EOPNOTSUPP. Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 65e6134a488ce7d611c46ee1455deeb213e86770 Author: Yonghong Song Date: Sun Nov 17 13:40:36 2019 -0800 selftests, bpf: Workaround an alu32 sub-register spilling issue [ Upstream commit 2ea2612b987ad703235c92be21d4e98ee9c2c67c ] Currently, with latest llvm trunk, selftest test_progs failed obj file test_seg6_loop.o with the following error in verifier: infinite loop detected at insn 76 The byte code sequence looks like below, and noted that alu32 has been turned off by default for better generated codes in general: 48: w3 = 100 49: *(u32 *)(r10 - 68) = r3 ... ; if (tlv.type == SR6_TLV_PADDING) { 76: if w3 == 5 goto -18 ... 85: r1 = *(u32 *)(r10 - 68) ; for (int i = 0; i < 100; i++) { 86: w1 += -1 87: if w1 == 0 goto +5 88: *(u32 *)(r10 - 68) = r1 The main reason for verification failure is due to partial spills at r10 - 68 for induction variable "i". Current verifier only handles spills with 8-byte values. The above 4-byte value spill to stack is treated to STACK_MISC and its content is not saved. For the above example: w3 = 100 R3_w=inv100 fp-64_w=inv1086626730498 *(u32 *)(r10 - 68) = r3 R3_w=inv100 fp-64_w=inv1086626730498 ... r1 = *(u32 *)(r10 - 68) R1_w=inv(id=0,umax_value=4294967295,var_off=(0x0; 0xffffffff)) fp-64=inv1086626730498 To resolve this issue, verifier needs to be extended to track sub-registers in spilling, or llvm needs to enhanced to prevent sub-register spilling in register allocation phase. The former will increase verifier complexity and the latter will need some llvm "hacking". Let us workaround this issue by declaring the induction variable as "long" type so spilling will happen at non sub-register level. We can revisit this later if sub-register spilling causes similar or other verification issues. Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191117214036.1309510-1-yhs@fb.com Signed-off-by: Sasha Levin commit 38078e9c92ce7fc93e45ea7debb7881a4ba4c8a2 Author: Jiri Benc Date: Fri Nov 15 13:43:23 2019 +0100 selftests, bpf: Fix test_tc_tunnel hanging [ Upstream commit 3b054b7133b4ad93671c82e8d6185258e3f1a7a5 ] When run_kselftests.sh is run, it hangs after test_tc_tunnel.sh. The reason is test_tc_tunnel.sh ensures the server ('nc -l') is run all the time, starting it again every time it is expected to terminate. The exception is the final client_connect: the server is not started anymore, which ensures no process is kept running after the test is finished. For a sit test, though, the script is terminated prematurely without the final client_connect and the 'nc' process keeps running. This in turn causes the run_one function in kselftest/runner.sh to hang forever, waiting for the runaway process to finish. Ensure a remaining server is terminated on cleanup. Fixes: f6ad6accaa99 ("selftests/bpf: expand test_tc_tunnel with SIT encap") Signed-off-by: Jiri Benc Signed-off-by: Daniel Borkmann Acked-by: Willem de Bruijn Link: https://lore.kernel.org/bpf/60919291657a9ee89c708d8aababc28ebe1420be.1573821780.git.jbenc@redhat.com Signed-off-by: Sasha Levin commit 83e561d6ccff9e523104185beed79f8b924fa230 Author: Alexander Shishkin Date: Fri Nov 15 18:08:18 2019 +0200 perf/core: Fix the mlock accounting, again [ Upstream commit 36b3db03b4741b8935b68fffc7e69951d8d70a89 ] Commit: 5e6c3c7b1ec2 ("perf/aux: Fix tracking of auxiliary trace buffer allocation") tried to guess the correct combination of arithmetic operations that would undo the AUX buffer's mlock accounting, and failed, leaking the bottom part when an allocation needs to be charged partially to both user->locked_vm and mm->pinned_vm, eventually leaving the user with no locked bonus: $ perf record -e intel_pt//u -m1,128 uname [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.061 MB perf.data ] $ perf record -e intel_pt//u -m1,128 uname Permission error mapping pages. Consider increasing /proc/sys/kernel/perf_event_mlock_kb, or try again with a smaller value of -m/--mmap_pages. (current value: 1,128) Fix this by subtracting both locked and pinned counts when AUX buffer is unmapped. Reported-by: Thomas Richter Tested-by: Thomas Richter Signed-off-by: Alexander Shishkin Acked-by: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Linus Torvalds Cc: Mark Rutland Cc: Namhyung Kim Cc: Stephane Eranian Cc: Thomas Gleixner Cc: Vince Weaver Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 13215269eda768285de4530057e82567b2a19968 Author: Chuhong Yuan Date: Mon Nov 18 15:37:07 2019 +0800 ASoC: wm5100: add missed pm_runtime_disable [ Upstream commit b1176bbb70866f24099cd2720283c7219fb4a81c ] The driver forgets to call pm_runtime_disable in remove and probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20191118073707.28298-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e83943268d0da0cc26bf13bddce864aa74ff402e Author: Chuhong Yuan Date: Mon Nov 18 10:48:48 2019 +0800 spi: st-ssc4: add missed pm_runtime_disable [ Upstream commit cd050abeba2a95fe5374eec28ad2244617bcbab6 ] The driver forgets to call pm_runtime_disable in probe failure and remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191118024848.21645-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dc7a825622d5ebfe52b219f8ea4b3e461644b269 Author: Chuhong Yuan Date: Mon Nov 18 15:36:33 2019 +0800 ASoC: wm2200: add missed operations in remove and probe failure [ Upstream commit 2dab09be49a1e7a4dd13cb47d3a1441a2ef33a87 ] This driver misses calls to pm_runtime_disable and regulator_bulk_disable in remove and a call to free_irq in probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191118073633.28237-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c598c8a46d01723d6445b26313717a7f315e44dd Author: Valentin Schneider Date: Fri Nov 15 10:39:08 2019 +0000 sched/uclamp: Fix overzealous type replacement [ Upstream commit 7763baace1b738d65efa46d68326c9406311c6bf ] Some uclamp helpers had their return type changed from 'unsigned int' to 'enum uclamp_id' by commit 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values") but it happens that some do return a value in the [0, SCHED_CAPACITY_SCALE] range, which should really be unsigned int. The affected helpers are uclamp_none(), uclamp_rq_max_value() and uclamp_eff_value(). Fix those up. Note that this doesn't lead to any obj diff using a relatively recent aarch64 compiler (8.3-2019.03). The current code of e.g. uclamp_eff_value() properly returns an 11 bit value (bits_per(1024)) and doesn't seem to do anything funny. I'm still marking this as fixing the above commit to be on the safe side. Signed-off-by: Valentin Schneider Reviewed-by: Qais Yousef Acked-by: Vincent Guittot Cc: Dietmar.Eggemann@arm.com Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: patrick.bellasi@matbug.net Cc: qperret@google.com Cc: surenb@google.com Cc: tj@kernel.org Fixes: 0413d7f33e60 ("sched/uclamp: Always use 'enum uclamp_id' for clamp_id values") Link: https://lkml.kernel.org/r/20191115103908.27610-1-valentin.schneider@arm.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 545bd24924cccb27574d29f9c7d5a7bfd3b2b7eb Author: Omar Sandoval Date: Mon Sep 16 11:30:53 2019 -0700 btrfs: don't prematurely free work in run_ordered_work() [ Upstream commit c495dcd6fbe1dce51811a76bb85b4675f6494938 ] We hit the following very strange deadlock on a system with Btrfs on a loop device backed by another Btrfs filesystem: 1. The top (loop device) filesystem queues an async_cow work item from cow_file_range_async(). We'll call this work X. 2. Worker thread A starts work X (normal_work_helper()). 3. Worker thread A executes the ordered work for the top filesystem (run_ordered_work()). 4. Worker thread A finishes the ordered work for work X and frees X (work->ordered_free()). 5. Worker thread A executes another ordered work and gets blocked on I/O to the bottom filesystem (still in run_ordered_work()). 6. Meanwhile, the bottom filesystem allocates and queues an async_cow work item which happens to be the recently-freed X. 7. The workqueue code sees that X is already being executed by worker thread A, so it schedules X to be executed _after_ worker thread A finishes (see the find_worker_executing_work() call in process_one_work()). Now, the top filesystem is waiting for I/O on the bottom filesystem, but the bottom filesystem is waiting for the top filesystem to finish, so we deadlock. This happens because we are breaking the workqueue assumption that a work item cannot be recycled while it still depends on other work. Fix it by waiting to free the work item until we are done with all of the related ordered work. P.S.: One might ask why the workqueue code doesn't try to detect a recycled work item. It actually does try by checking whether the work item has the same work function (find_worker_executing_work()), but in our case the function is the same. This is the only key that the workqueue code has available to compare, short of adding an additional, layer-violating "custom key". Considering that we're the only ones that have ever hit this, we should just play by the rules. Unfortunately, we haven't been able to create a minimal reproducer other than our full container setup using a compress-force=zstd filesystem on top of another compress-force=zstd filesystem. Suggested-by: Tejun Heo Reviewed-by: Johannes Thumshirn Signed-off-by: Omar Sandoval Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 4b3bd1615e2098dfdf4002b6b1dc8e8a170d9e64 Author: Omar Sandoval Date: Mon Sep 16 11:30:54 2019 -0700 btrfs: don't prematurely free work in end_workqueue_fn() [ Upstream commit 9be490f1e15c34193b1aae17da58e14dd9f55a95 ] Currently, end_workqueue_fn() frees the end_io_wq entry (which embeds the work item) and then calls bio_endio(). This is another potential instance of the bug in "btrfs: don't prematurely free work in run_ordered_work()". In particular, the endio call may depend on other work items. For example, btrfs_end_dio_bio() can call btrfs_subio_endio_read() -> __btrfs_correct_data_nocsum() -> dio_read_error() -> submit_dio_repair_bio(), which submits a bio that is also completed through a end_workqueue_fn() work item. However, __btrfs_correct_data_nocsum() waits for the newly submitted bio to complete, thus it depends on another work item. This example currently usually works because we use different workqueue helper functions for BTRFS_WQ_ENDIO_DATA and BTRFS_WQ_ENDIO_DIO_REPAIR. However, it may deadlock with stacked filesystems and is fragile overall. The proper fix is to free the work item at the very end of the work function, so let's do that. Reviewed-by: Johannes Thumshirn Signed-off-by: Omar Sandoval Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a2b817d24ebcf98195ffea3a53a76b4414d68c16 Author: Eugeniu Rosca Date: Fri Nov 15 14:44:30 2019 +0100 mmc: tmio: Add MMC_CAP_ERASE to allow erase/discard/trim requests [ Upstream commit c91843463e9e821dc3b48fe37e3155fa38299f6e ] Isolated initially to renesas_sdhi_internal_dmac [1], Ulf suggested adding MMC_CAP_ERASE to the TMIO mmc core: On Fri, Nov 15, 2019 at 10:27:25AM +0100, Ulf Hansson wrote: -- snip -- This test and due to the discussions with Wolfram and you in this thread, I would actually suggest that you enable MMC_CAP_ERASE for all tmio variants, rather than just for this particular one. In other words, set the cap in tmio_mmc_host_probe() should be fine, as it seems none of the tmio variants supports HW busy detection at this point. -- snip -- Testing on R-Car H3ULCB-KF doesn't reveal any issues (v5.4-rc7): root@rcar-gen3:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0 179:0 0 59.2G 0 disk <--- eMMC mmcblk0boot0 179:8 0 4M 1 disk mmcblk0boot1 179:16 0 4M 1 disk mmcblk1 179:24 0 30G 0 disk <--- SD card root@rcar-gen3:~# time blkdiscard /dev/mmcblk0 real 0m8.659s user 0m0.001s sys 0m1.920s root@rcar-gen3:~# time blkdiscard /dev/mmcblk1 real 0m1.176s user 0m0.001s sys 0m0.124s [1] https://lore.kernel.org/linux-renesas-soc/20191112134808.23546-1-erosca@de.adit-jv.com/ Cc: Wolfram Sang Cc: Masahiro Yamada Cc: Andrew Gabbasov Originally-by: Harish Jenny K N Suggested-by: Ulf Hansson Signed-off-by: Eugeniu Rosca Reviewed-by: Wolfram Sang Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin commit f4a645928c9f60bd659cda276c37b53bd3636f1a Author: Ard Biesheuvel Date: Sat Nov 9 18:09:27 2019 +0100 crypto: virtio - deal with unsupported input sizes [ Upstream commit 19c5da7d4a2662e85ea67d2d81df57e038fde3ab ] Return -EINVAL for input sizes that are not a multiple of the AES block size, since they are not supported by our CBC chaining mode. While at it, remove the pr_err() that reports unsupported key sizes being used: we shouldn't spam the kernel log with that. Fixes: dbaf0624ffa5 ("crypto: add virtio-crypto driver") Cc: "Michael S. Tsirkin" Cc: Jason Wang Cc: Gonglei Cc: virtualization@lists.linux-foundation.org Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 7d9098d4c988b33c4e7ad0b2bf57489cb4158f57 Author: Mika Westerberg Date: Fri Nov 15 18:50:03 2019 +0200 xhci-pci: Allow host runtime PM as default also for Intel Ice Lake xHCI [ Upstream commit 07a594f353655b1628f598add352e7e754f44869 ] Intel Ice Lake has two xHCI controllers one on PCH and the other as part of the CPU itself. The latter is also part of the so called Type C Subsystem (TCSS) sharing ACPI power resources with the PCIe root ports and the Thunderbolt controllers. In order to put the whole TCSS block into D3cold the xHCI needs to be runtime suspended as well when idle. For this reason allow runtime PM as default for Ice Lake TCSS xHCI controller. Signed-off-by: Mika Westerberg Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/1573836603-10871-5-git-send-email-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a1a4c3cc2b06539146fd58f2a01b2979b82ed091 Author: Petar Penkov Date: Thu Nov 14 09:52:09 2019 -0800 tun: fix data-race in gro_normal_list() [ Upstream commit c39e342a050a4425348e6fe7f75827c0a1a7ebc5 ] There is a race in the TUN driver between napi_busy_loop and napi_gro_frags. This commit resolves the race by adding the NAPI struct via netif_tx_napi_add, instead of netif_napi_add, which disables polling for the NAPI struct. KCSAN reported: BUG: KCSAN: data-race in gro_normal_list.part.0 / napi_busy_loop write to 0xffff8880b5d474b0 of 4 bytes by task 11205 on cpu 0: gro_normal_list.part.0+0x77/0xb0 net/core/dev.c:5682 gro_normal_list net/core/dev.c:5678 [inline] gro_normal_one net/core/dev.c:5692 [inline] napi_frags_finish net/core/dev.c:5705 [inline] napi_gro_frags+0x625/0x770 net/core/dev.c:5778 tun_get_user+0x2150/0x26a0 drivers/net/tun.c:1976 tun_chr_write_iter+0x79/0xd0 drivers/net/tun.c:2022 call_write_iter include/linux/fs.h:1895 [inline] do_iter_readv_writev+0x487/0x5b0 fs/read_write.c:693 do_iter_write fs/read_write.c:970 [inline] do_iter_write+0x13b/0x3c0 fs/read_write.c:951 vfs_writev+0x118/0x1c0 fs/read_write.c:1015 do_writev+0xe3/0x250 fs/read_write.c:1058 __do_sys_writev fs/read_write.c:1131 [inline] __se_sys_writev fs/read_write.c:1128 [inline] __x64_sys_writev+0x4e/0x60 fs/read_write.c:1128 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 read to 0xffff8880b5d474b0 of 4 bytes by task 11168 on cpu 1: gro_normal_list net/core/dev.c:5678 [inline] napi_busy_loop+0xda/0x4f0 net/core/dev.c:6126 sk_busy_loop include/net/busy_poll.h:108 [inline] __skb_recv_udp+0x4ad/0x560 net/ipv4/udp.c:1689 udpv6_recvmsg+0x29e/0xe90 net/ipv6/udp.c:288 inet6_recvmsg+0xbb/0x240 net/ipv6/af_inet6.c:592 sock_recvmsg_nosec net/socket.c:871 [inline] sock_recvmsg net/socket.c:889 [inline] sock_recvmsg+0x92/0xb0 net/socket.c:885 sock_read_iter+0x15f/0x1e0 net/socket.c:967 call_read_iter include/linux/fs.h:1889 [inline] new_sync_read+0x389/0x4f0 fs/read_write.c:414 __vfs_read+0xb1/0xc0 fs/read_write.c:427 vfs_read fs/read_write.c:461 [inline] vfs_read+0x143/0x2c0 fs/read_write.c:446 ksys_read+0xd5/0x1b0 fs/read_write.c:587 __do_sys_read fs/read_write.c:597 [inline] __se_sys_read fs/read_write.c:595 [inline] __x64_sys_read+0x4c/0x60 fs/read_write.c:595 do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 11168 Comm: syz-executor.0 Not tainted 5.4.0-rc6+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 943170998b20 ("tun: enable NAPI for TUN/TAP driver") Signed-off-by: Petar Penkov Reported-by: syzbot Reviewed-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit e2a8323cfc688e8e086df395721b562691256e9f Author: Chuhong Yuan Date: Fri Nov 15 16:31:22 2019 +0800 spi: tegra20-slink: add missed clk_unprepare [ Upstream commit 04358e40ba96d687c0811c21d9dede73f5244a98 ] The driver misses calling clk_unprepare in probe failure and remove. Add the calls to fix it. Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191115083122.12278-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f44b07472f29ae313ce875dc7b9c75b100c608b8 Author: Pascal Paillet Date: Wed Nov 13 11:27:37 2019 +0100 regulator: core: Let boot-on regulators be powered off [ Upstream commit 089b3f61ecfc43ca4ea26d595e1d31ead6de3f7b ] Boot-on regulators are always kept on because their use_count value is now incremented at boot time and never cleaned. Only increment count value for alway-on regulators. regulator_late_cleanup() is now able to power off boot-on regulators when unused. Fixes: 05f224ca6693 ("regulator: core: Clean enabling always-on regulators + their supplies") Signed-off-by: Pascal Paillet Link: https://lore.kernel.org/r/20191113102737.27831-1-p.paillet@st.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1abc16758bb7a10b08bff5ae0656d7ef1480a802 Author: Michael Walle Date: Tue Nov 12 23:36:29 2019 +0100 ASoC: wm8904: fix regcache handling [ Upstream commit e9149b8c00d25dbaef1aa174fc604bed207e576d ] The current code assumes that the power is turned off in SND_SOC_BIAS_OFF. If there are no actual regulator the codec isn't turned off and the registers are not reset to their default values but the regcache is still marked as dirty. Thus a value might not be written to the hardware if it is set to the default value. Do a software reset before turning off the power to make sure the registers are always reset to their default states. Signed-off-by: Michael Walle Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20191112223629.21867-1-michael@walle.cc Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f8ce363e5aac9f5cac11ffd522a1d1556cb6e938 Author: Wang Xuerui Date: Fri Nov 15 09:28:02 2019 +0200 iwlwifi: mvm: fix unaligned read of rx_pkt_status [ Upstream commit c5aaa8be29b25dfe1731e9a8b19fd91b7b789ee3 ] This is present since the introduction of iwlmvm. Example stack trace on MIPS: [] iwl_mvm_rx_rx_mpdu+0xa8/0xb88 [iwlmvm] [] iwl_pcie_rx_handle+0x420/0xc48 [iwlwifi] Tested with a Wireless AC 7265 for ~6 months, confirmed to fix the problem. No other unaligned accesses are spotted yet. Signed-off-by: Wang Xuerui Signed-off-by: Luca Coelho Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 47a417e7cf63ecc8f6b9e851bd49e9cd295285d2 Author: Andrea Righi Date: Wed Nov 13 16:03:21 2019 +0800 bcache: fix deadlock in bcache_allocator [ Upstream commit 84c529aea182939e68f618ed9813740c9165c7eb ] bcache_allocator can call the following: bch_allocator_thread() -> bch_prio_write() -> bch_bucket_alloc() -> wait on &ca->set->bucket_wait But the wake up event on bucket_wait is supposed to come from bch_allocator_thread() itself => deadlock: [ 1158.490744] INFO: task bcache_allocato:15861 blocked for more than 10 seconds. [ 1158.495929] Not tainted 5.3.0-050300rc3-generic #201908042232 [ 1158.500653] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 1158.504413] bcache_allocato D 0 15861 2 0x80004000 [ 1158.504419] Call Trace: [ 1158.504429] __schedule+0x2a8/0x670 [ 1158.504432] schedule+0x2d/0x90 [ 1158.504448] bch_bucket_alloc+0xe5/0x370 [bcache] [ 1158.504453] ? wait_woken+0x80/0x80 [ 1158.504466] bch_prio_write+0x1dc/0x390 [bcache] [ 1158.504476] bch_allocator_thread+0x233/0x490 [bcache] [ 1158.504491] kthread+0x121/0x140 [ 1158.504503] ? invalidate_buckets+0x890/0x890 [bcache] [ 1158.504506] ? kthread_park+0xb0/0xb0 [ 1158.504510] ret_from_fork+0x35/0x40 Fix by making the call to bch_prio_write() non-blocking, so that bch_allocator_thread() never waits on itself. Moreover, make sure to wake up the garbage collector thread when bch_prio_write() is failing to allocate buckets. BugLink: https://bugs.launchpad.net/bugs/1784665 BugLink: https://bugs.launchpad.net/bugs/1796292 Signed-off-by: Andrea Righi Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4ff039ca442d1df960ff8894275af1df96bb800a Author: Masami Hiramatsu Date: Tue Oct 29 17:31:44 2019 +0900 tracing/kprobe: Check whether the non-suffixed symbol is notrace [ Upstream commit c7411a1a126f649be71526a36d4afac9e5aefa13 ] Check whether the non-suffixed symbol is notrace, since suffixed symbols are generated by the compilers for optimization. Based on these suffixed symbols, notrace check might not work because some of them are just a partial code of the original function. (e.g. cold-cache (unlikely) code is separated from original function as FUNCTION.cold.XX) For example, without this fix, # echo p device_add.cold.67 > /sys/kernel/debug/tracing/kprobe_events sh: write error: Invalid argument # cat /sys/kernel/debug/tracing/error_log [ 135.491035] trace_kprobe: error: Failed to register probe event Command: p device_add.cold.67 ^ # dmesg | tail -n 1 [ 135.488599] trace_kprobe: Could not probe notrace function device_add.cold.67 With this, # echo p device_add.cold.66 > /sys/kernel/debug/tracing/kprobe_events # cat /sys/kernel/debug/kprobes/list ffffffff81599de9 k device_add.cold.66+0x0 [DISABLED] Actually, kprobe blacklist already did similar thing, see within_kprobe_blacklist(). Link: http://lkml.kernel.org/r/157233790394.6706.18243942030937189679.stgit@devnote2 Fixes: 45408c4f9250 ("tracing: kprobes: Prohibit probing on notrace function") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 114a9b2c0cb6a45c95b8f392faa7f11540f86b02 Author: Sergio Paracuellos Date: Sat Oct 19 10:12:33 2019 +0200 MIPS: ralink: enable PCI support only if driver for mt7621 SoC is selected [ Upstream commit 3b2fa0c92686562ac0b8cf00c0326a45814f8e18 ] Some versions of SoC MT7621 have three PCI express hosts. Some boards make use of those PCI through the staging driver mt7621-pci. Recently PCI support has been removed from MT7621 Soc kernel configuration due to a build error. This makes imposible to compile staging driver and produces a regression for gnubee based boards. Enable support for PCI again but enable it only if staging mt7621-pci driver is selected. Fixes: c4d48cf5e2f0 ("MIPS: ralink: deactivate PCI support for SOC_MT7621") Cc: Hauke Mehrtens Cc: ralf@linux-mips.org Cc: jhogan@kernel.org Cc: john@phrozen.org Cc: NeilBrown Cc: linux-mips@vger.kernel.org Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20191019081233.7337-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 519a27989423aa3658d706ce4671a5fed09ade55 Author: Yuming Han Date: Thu Oct 24 11:34:30 2019 +0800 tracing: use kvcalloc for tgid_map array allocation [ Upstream commit 6ee40511cb838f9ced002dff7131bca87e3ccbdd ] Fail to allocate memory for tgid_map, because it requires order-6 page. detail as: c3 sh: page allocation failure: order:6, mode:0x140c0c0(GFP_KERNEL), nodemask=(null) c3 sh cpuset=/ mems_allowed=0 c3 CPU: 3 PID: 5632 Comm: sh Tainted: G W O 4.14.133+ #10 c3 Hardware name: Generic DT based system c3 Backtrace: c3 [] (dump_backtrace) from [](show_stack+0x18/0x1c) c3 [] (show_stack) from [](dump_stack+0x84/0xa4) c3 [] (dump_stack) from [](warn_alloc+0xc4/0x19c) c3 [] (warn_alloc) from [](__alloc_pages_nodemask+0xd18/0xf28) c3 [] (__alloc_pages_nodemask) from [](kmalloc_order+0x20/0x38) c3 [] (kmalloc_order) from [](kmalloc_order_trace+0x24/0x108) c3 [] (kmalloc_order_trace) from [](set_tracer_flag+0xb0/0x158) c3 [] (set_tracer_flag) from [](trace_options_core_write+0x7c/0xcc) c3 [] (trace_options_core_write) from [](__vfs_write+0x40/0x14c) c3 [] (__vfs_write) from [](vfs_write+0xc4/0x198) c3 [] (vfs_write) from [](SyS_write+0x6c/0xd0) c3 [] (SyS_write) from [](ret_fast_syscall+0x0/0x54) Switch to use kvcalloc to avoid unexpected allocation failures. Link: http://lkml.kernel.org/r/1571888070-24425-1-git-send-email-chunyan.zhang@unisoc.com Signed-off-by: Yuming Han Signed-off-by: Chunyan Zhang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit a672f38f5fb67e70408453e5918aa51883959694 Author: Gal Pressman Date: Tue Nov 12 11:26:08 2019 +0200 RDMA/efa: Clear the admin command buffer prior to its submission [ Upstream commit 64c264872b8879e2ab9017eefe9514d4c045c60e ] We cannot rely on the entry memcpy as we only copy the actual size of the command, the rest of the bytes must be memset to zero. Currently providing non-zero memory will not have any user visible impact. However, since admin commands are extendable (in a backwards compatible way) everything beyond the size of the command must be cleared to prevent issues in the future. Fixes: 0420e542569b ("RDMA/efa: Implement functions that submit and complete admin commands") Link: https://lore.kernel.org/r/20191112092608.46964-1-galpress@amazon.com Reviewed-by: Daniel Kranzdorf Reviewed-by: Firas JahJah Signed-off-by: Gal Pressman Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a9f6525550644a29306facdfa23b4ee4bc05cc89 Author: Sergey Matyukevich Date: Wed Nov 13 11:06:47 2019 +0000 qtnfmac: fix using skb after free [ Upstream commit 4a33f21cef84b1b933958c99ed5dac1726214b35 ] KASAN reported use-after-free error: [ 995.220767] BUG: KASAN: use-after-free in qtnf_cmd_send_with_reply+0x169/0x3e0 [qtnfmac] [ 995.221098] Read of size 2 at addr ffff888213d1ded0 by task kworker/1:1/71 The issue in qtnf_cmd_send_with_reply impacts all the commands that do not need response other then return code. For such commands, consume_skb is used for response skb and right after that return code in response skb is accessed. Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 95d6206eb551dfeabe688ad6f928fe3493d88d06 Author: Lianbo Jiang Date: Fri Nov 8 17:00:27 2019 +0800 x86/crash: Add a forward declaration of struct kimage [ Upstream commit 112eee5d06007dae561f14458bde7f2a4879ef4e ] Add a forward declaration of struct kimage to the crash.h header because future changes will invoke a crash-specific function from the realmode init path and the compiler will complain otherwise like this: In file included from arch/x86/realmode/init.c:11: ./arch/x86/include/asm/crash.h:5:32: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 5 | int crash_load_segments(struct kimage *image); | ^~~~~~ ./arch/x86/include/asm/crash.h:6:37: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 6 | int crash_copy_backup_region(struct kimage *image); | ^~~~~~ ./arch/x86/include/asm/crash.h:7:39: warning: ‘struct kimage’ declared inside\ parameter list will not be visible outside of this definition or declaration 7 | int crash_setup_memmap_entries(struct kimage *image, | [ bp: Rewrite the commit message. ] Reported-by: kbuild test robot Signed-off-by: Lianbo Jiang Signed-off-by: Borislav Petkov Cc: bhe@redhat.com Cc: d.hatayama@fujitsu.com Cc: dhowells@redhat.com Cc: dyoung@redhat.com Cc: ebiederm@xmission.com Cc: horms@verge.net.au Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jürgen Gross Cc: kexec@lists.infradead.org Cc: Thomas Gleixner Cc: Tom Lendacky Cc: vgoyal@redhat.com Cc: x86-ml Link: https://lkml.kernel.org/r/20191108090027.11082-4-lijiang@redhat.com Link: https://lkml.kernel.org/r/201910310233.EJRtTMWP%25lkp@intel.com Signed-off-by: Sasha Levin commit a9a6a4e3708d1d167fb868783a5a16dc7268817f Author: Sergey Matyukevich Date: Wed Nov 13 11:06:51 2019 +0000 qtnfmac: fix invalid channel information output [ Upstream commit 24227a9e956a7c9913a7e6e7199a9ae3f540fe88 ] Do not attempt to print frequency for an invalid channel provided by firmware. That channel may simply not exist. Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 9348d03492f5602b9d139c9a01ba87f17826caad Author: Sergey Matyukevich Date: Wed Nov 13 11:06:49 2019 +0000 qtnfmac: fix debugfs support for multiple cards [ Upstream commit dd4c2260dab04f5ae7bdb79b9470e7da56f48145 ] Fix merge artifact for commit 0b68fe10b8e8 ("qtnfmac: modify debugfs to support multiple cards") and finally add debugfs support for multiple qtnfmac wireless cards. Signed-off-by: Sergey Matyukevich Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 32e1ac30b613eb00d9ed78039cb7d866222b11ed Author: Viresh Kumar Date: Thu Nov 14 09:06:17 2019 +0530 cpufreq: Register drivers only after CPU devices have been registered [ Upstream commit 46770be0cf94149ca48be87719bda1d951066644 ] The cpufreq core heavily depends on the availability of the struct device for CPUs and if they aren't available at the time cpufreq driver is registered, we will never succeed in making cpufreq work. This happens due to following sequence of events: - cpufreq_register_driver() - subsys_interface_register() - return 0; //successful registration of driver ... at a later point of time - register_cpu(); - device_register(); - bus_probe_device(); - sif->add_dev(); - cpufreq_add_dev(); - get_cpu_device(); //FAILS - per_cpu(cpu_sys_devices, num) = &cpu->dev; //used by get_cpu_device() - return 0; //CPU registered successfully Because the per-cpu variable cpu_sys_devices is set only after the CPU device is regsitered, cpufreq will never be able to get it when cpufreq_add_dev() is called. This patch avoids this failure by making sure device structure of at least CPU0 is available when the cpufreq driver is registered, else return -EPROBE_DEFER. Reported-by: Bjorn Andersson Co-developed-by: Amit Kucheria Signed-off-by: Viresh Kumar Tested-by: Amit Kucheria Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit c17480cb33e71dfc6fc672ade62e2b7bdcdf3161 Author: Coly Li Date: Wed Nov 13 16:03:17 2019 +0800 bcache: fix static checker warning in bcache_device_free() [ Upstream commit 2d8869518a525c9bce5f5268419df9dfbe3dfdeb ] Commit cafe56359144 ("bcache: A block layer cache") leads to the following static checker warning: ./drivers/md/bcache/super.c:770 bcache_device_free() warn: variable dereferenced before check 'd->disk' (see line 766) drivers/md/bcache/super.c 762 static void bcache_device_free(struct bcache_device *d) 763 { 764 lockdep_assert_held(&bch_register_lock); 765 766 pr_info("%s stopped", d->disk->disk_name); ^^^^^^^^^ Unchecked dereference. 767 768 if (d->c) 769 bcache_device_detach(d); 770 if (d->disk && d->disk->flags & GENHD_FL_UP) ^^^^^^^ Check too late. 771 del_gendisk(d->disk); 772 if (d->disk && d->disk->queue) 773 blk_cleanup_queue(d->disk->queue); 774 if (d->disk) { 775 ida_simple_remove(&bcache_device_idx, 776 first_minor_to_idx(d->disk->first_minor)); 777 put_disk(d->disk); 778 } 779 It is not 100% sure that the gendisk struct of bcache device will always be there, the warning makes sense when there is problem in block core. This patch tries to remove the static checking warning by checking d->disk to avoid NULL pointer deferences. Reported-by: Dan Carpenter Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit b6fbb6ded9a0369a20a928a1ca5157f0a7d69cdd Author: Sudip Mukherjee Date: Wed Oct 16 15:45:39 2019 +0100 parport: load lowlevel driver if ports not found [ Upstream commit 231ec2f24dad18d021b361045bbd618ba62a274e ] Usually all the distro will load the parport low level driver as part of their initialization. But we can get into a situation where all the parallel port drivers are built as module and we unload all the modules at a later time. Then if we just do "modprobe parport" it will only load the parport module and will not load the low level driver which will actually register the ports. So, check the bus if there is any parport registered, if not, load the low level driver. We can get into the above situation with all distro but only Suse has setup the alias for "parport_lowlevel" and so it only works in Suse. Users of Debian based distro will need to load the lowlevel module manually. Signed-off-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20191016144540.18810-3-sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8b0acb768a06083b0d28bace1481c1f6679e76f4 Author: Eduard Hasenleithner Date: Tue Nov 12 21:55:01 2019 +0100 nvme: Discard workaround for non-conformant devices [ Upstream commit 530436c45ef2e446c12538a400e465929a0b3ade ] Users observe IOMMU related errors when performing discard on nvme from non-compliant nvme devices reading beyond the end of the DMA mapped ranges to discard. Two different variants of this behavior have been observed: SM22XX controllers round up the read size to a multiple of 512 bytes, and Phison E12 unconditionally reads the maximum discard size allowed by the spec (256 segments or 4kB). Make nvme_setup_discard unconditionally allocate the maximum DSM buffer so the driver DMA maps a memory range that will always succeed. Link: https://bugzilla.kernel.org/show_bug.cgi?id=202665 many Signed-off-by: Eduard Hasenleithner [changelog, use existing define, kernel coding style] Signed-off-by: Keith Busch Signed-off-by: Sasha Levin commit a09579b0c2e882f49e2a4d7ae40dbd5c1a4eb4bb Author: Mao Wenan Date: Tue Nov 12 14:33:58 2019 +0800 net: ethernet: ti: Add dependency for TI_DAVINCI_EMAC [ Upstream commit b2ef81dcdf3835bd55e5f97ff30131bb327be7fa ] If TI_DAVINCI_EMAC=y and GENERIC_ALLOCATOR is not set, below erros can be seen: drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_desc_pool_destroy.isra.14': davinci_cpdma.c:(.text+0x359): undefined reference to `gen_pool_size' davinci_cpdma.c:(.text+0x365): undefined reference to `gen_pool_avail' davinci_cpdma.c:(.text+0x373): undefined reference to `gen_pool_avail' davinci_cpdma.c:(.text+0x37f): undefined reference to `gen_pool_size' drivers/net/ethernet/ti/davinci_cpdma.o: In function `__cpdma_chan_free': davinci_cpdma.c:(.text+0x4a2): undefined reference to `gen_pool_free_owner' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_chan_submit_si': davinci_cpdma.c:(.text+0x66c): undefined reference to `gen_pool_alloc_algo_owner' davinci_cpdma.c:(.text+0x805): undefined reference to `gen_pool_free_owner' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_ctlr_create': davinci_cpdma.c:(.text+0xabd): undefined reference to `devm_gen_pool_create' davinci_cpdma.c:(.text+0xb79): undefined reference to `gen_pool_add_owner' drivers/net/ethernet/ti/davinci_cpdma.o: In function `cpdma_check_free_tx_desc': davinci_cpdma.c:(.text+0x16c6): undefined reference to `gen_pool_avail' This patch mades TI_DAVINCI_EMAC select GENERIC_ALLOCATOR. Fixes: 99f629718272 ("net: ethernet: ti: cpsw: drop TI_DAVINCI_CPDMA config option") Signed-off-by: Mao Wenan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5da9740078cdb98a9d46f49429420001d3067e87 Author: Ilya Leoshkevich Date: Thu Oct 31 18:25:16 2019 +0100 s390/disassembler: don't hide instruction addresses [ Upstream commit 544f1d62e3e6c6e6d17a5e56f6139208acb5ff46 ] Due to kptr_restrict, JITted BPF code is now displayed like this: 000000000b6ed1b2: ebdff0800024 stmg %r13,%r15,128(%r15) 000000004cde2ba0: 41d0f040 la %r13,64(%r15) 00000000fbad41b0: a7fbffa0 aghi %r15,-96 Leaking kernel addresses to dmesg is not a concern in this case, because this happens only when JIT debugging is explicitly activated, which only root can do. Use %px in this particular instance, and also to print an instruction address in show_code and PCREL (e.g. brasl) arguments in print_insn. While at present functionally equivalent to %016lx, %px is recommended by Documentation/core-api/printk-formats.rst for such cases. Signed-off-by: Ilya Leoshkevich Reviewed-by: Vasily Gorbik Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 0ed50cdcb5059bc61131fc0c2bcd90d5ca80acbd Author: Heiner Kallweit Date: Sun Nov 10 14:44:54 2019 +0100 r8169: respect EEE user setting when restarting network [ Upstream commit 7ec3f872bc85ada93db34448d73bb399d6b82c2c ] Currently, if network is re-started, we advertise all supported EEE modes, thus potentially overriding a manual adjustment the user made e.g. via ethtool. Be friendly to the user and preserve a manual setting on network re-start. Signed-off-by: Heiner Kallweit Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4eab6c4e07b7c71522d5818c80d746c603c5d69d Author: Vladimir Oltean Date: Sat Nov 9 13:32:24 2019 +0200 net: dsa: sja1105: Disallow management xmit during switch reset [ Upstream commit af580ae2dcb250719857b4b7024bd4bb0c2e05fb ] The purpose here is to avoid ptp4l fail due to this condition: timed out while polling for tx timestamp increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug port 1: send peer delay request failed So either reset the switch before the management frame was sent, or after it was timestamped as well, but not in the middle. The condition may arise either due to a true timeout (i.e. because re-uploading the static config takes time), or due to the TX timestamp actually getting lost due to reset. For the former we can increase tx_timestamp_timeout in userspace, for the latter we need this patch. Locking all traffic during switch reset does not make sense at all, though. Forcing all CPU-originated traffic to potentially block waiting for a sleepable context to send > 800 bytes over SPI is not a good idea. Flows that are autonomously forwarded by the switch will get dropped anyway during switch reset no matter what. So just let all other CPU-originated traffic be dropped as well. Signed-off-by: Vladimir Oltean Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 187fb0e947d8ae89ca4ee96661acc54c94eba4f8 Author: Yu-Hsuan Hsu Date: Tue Sep 24 00:29:40 2019 +0800 ASoC: Intel: kbl_rt5663_rt5514_max98927: Add dmic format constraint [ Upstream commit e2db787bdcb4f2722ecf410168f0583764634e45 ] On KBL platform, the microphone is attached to external codec(rt5514) instead of PCH. However, TDM slot between PCH and codec is 16 bits only. In order to avoid setting wrong format, we should add a constraint to force to use 16 bits format forever. Signed-off-by: Yu-Hsuan Hsu Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20190923162940.199580-1-yuhsuan@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 82846628c2c9923102804d056c5b103f6efcdad6 Author: Yonghong Song Date: Thu Nov 7 09:00:45 2019 -0800 bpf, testing: Workaround a verifier failure for test_progs [ Upstream commit b7a0d65d80a0c5034b366392624397a0915b7556 ] With latest llvm compiler, running test_progs will have the following verifier failure for test_sysctl_loop1.o: libbpf: load bpf program failed: Permission denied libbpf: -- BEGIN DUMP LOG --- libbpf: invalid indirect read from stack var_off (0x0; 0xff)+196 size 7 ... libbpf: -- END LOG -- libbpf: failed to load program 'cgroup/sysctl' libbpf: failed to load object 'test_sysctl_loop1.o' The related bytecode looks as below: 0000000000000308 LBB0_8: 97: r4 = r10 98: r4 += -288 99: r4 += r7 100: w8 &= 255 101: r1 = r10 102: r1 += -488 103: r1 += r8 104: r2 = 7 105: r3 = 0 106: call 106 107: w1 = w0 108: w1 += -1 109: if w1 > 6 goto -24 110: w0 += w8 111: r7 += 8 112: w8 = w0 113: if r7 != 224 goto -17 And source code: for (i = 0; i < ARRAY_SIZE(tcp_mem); ++i) { ret = bpf_strtoul(value + off, MAX_ULONG_STR_LEN, 0, tcp_mem + i); if (ret <= 0 || ret > MAX_ULONG_STR_LEN) return 0; off += ret & MAX_ULONG_STR_LEN; } Current verifier is not able to conclude that register w0 before '+' at insn 110 has a range of 1 to 7 and thinks it is from 0 - 255. This leads to more conservative range for w8 at insn 112, and later verifier complaint. Let us workaround this issue until we found a compiler and/or verifier solution. The workaround in this patch is to make variable 'ret' volatile, which will force a reload and then '&' operation to ensure better value range. With this patch, I got the below byte code for the loop: 0000000000000328 LBB0_9: 101: r4 = r10 102: r4 += -288 103: r4 += r7 104: w8 &= 255 105: r1 = r10 106: r1 += -488 107: r1 += r8 108: r2 = 7 109: r3 = 0 110: call 106 111: *(u32 *)(r10 - 64) = r0 112: r1 = *(u32 *)(r10 - 64) 113: if w1 s< 1 goto -28 114: r1 = *(u32 *)(r10 - 64) 115: if w1 s> 7 goto -30 116: r1 = *(u32 *)(r10 - 64) 117: w1 &= 7 118: w1 += w8 119: r7 += 8 120: w8 = w1 121: if r7 != 224 goto -21 Insn 117 did the '&' operation and we got more precise value range for 'w8' at insn 120. The test is happy then: #3/17 test_sysctl_loop1.o:OK Signed-off-by: Yonghong Song Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20191107170045.2503480-1-yhs@fb.com Signed-off-by: Sasha Levin commit 8714dfa4362df67cbaa2781f35dd43e1860392e0 Author: Stefan Popa Date: Wed Nov 6 11:47:21 2019 +0200 iio: dac: ad5446: Add support for new AD5600 DAC [ Upstream commit 6376cbe549fffb378403cee78efd26b8a2c8e450 ] The AD5600 is a single channel, 16-bit resolution, voltage output digital to analog converter (DAC). The AD5600 uses a 3-wire SPI interface. It is part of the AD5541 family of DACs. The ad5446 IIO driver implements support for some of these DACs (in the AD5441 family), so the change is a simple entry in this driver. Link: https://www.analog.com/media/en/technical-documentation/data-sheets/AD5600.pdf Signed-off-by: Stefan Popa Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5e0775af48782bb82b56a08d7d680a1a91c9cecd Author: Ben Zhang Date: Tue Nov 5 17:13:30 2019 -0800 ASoC: rt5677: Mark reg RT5677_PWR_ANLG2 as volatile [ Upstream commit eabf424f7b60246c76dcb0ea6f1e83ef9abbeaa6 ] The codec dies when RT5677_PWR_ANLG2(MX-64h) is set to 0xACE1 while it's streaming audio over SPI. The DSP firmware turns on PLL2 (MX-64 bit 8) when SPI streaming starts. However regmap does not believe that register can change by itself. When BST1 (bit 15) is turned on with regmap_update_bits(), it doesn't read the register first before write, so PLL2 power bit is cleared by accident. Marking MX-64h as volatile in regmap solved the issue. Signed-off-by: Ben Zhang Signed-off-by: Curtis Malainey Link: https://lore.kernel.org/r/20191106011335.223061-6-cujomalainey@chromium.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 98339b1498e62d1fa72fba96e83422d558988749 Author: Chuhong Yuan Date: Sat Nov 9 16:09:43 2019 +0800 spi: pxa2xx: Add missed security checks [ Upstream commit 5eb263ef08b5014cfc2539a838f39d2fd3531423 ] pxa2xx_spi_init_pdata misses checks for devm_clk_get and platform_get_irq. Add checks for them to fix the bugs. Since ssp->clk and ssp->irq are used in probe, they are mandatory here. So we cannot use _optional() for devm_clk_get and platform_get_irq. Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191109080943.30428-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 129c37017392a8bcd7e5005a9d185f7bc103cb59 Author: Hans Verkuil Date: Sat Nov 9 14:03:08 2019 +0100 media: vim2m: media_device_cleanup was called too early [ Upstream commit 9f22e88a4bba270d3427684cee84dfbf67489e86 ] Running the contrib/test/test-media script in v4l-utils with the vim2m argument will cause this kernel warning: [ 554.430157] ------------[ cut here ]------------ [ 554.433034] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 554.433064] WARNING: CPU: 0 PID: 616 at kernel/locking/mutex.c:938 __mutex_lock+0xd7a/0x1380 [ 554.439736] Modules linked in: vim2m v4l2_mem2mem vivid rc_cec videobuf2_dma_contig v4l2_dv_timings cec videobuf2_vmalloc videobuf2_memops v4l2_tpg videobuf2_v4l2 videobuf2_common videodev mc rc_core [last unloaded: vivid] [ 554.445794] CPU: 0 PID: 616 Comm: sleep Not tainted 5.4.0-rc1-virtme #1 [ 554.448481] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [ 554.453088] RIP: 0010:__mutex_lock+0xd7a/0x1380 [ 554.454955] Code: d2 0f 85 de 05 00 00 44 8b 05 82 d9 f7 00 45 85 c0 0f 85 bf f3 ff ff 48 c7 c6 e0 30 a6 b7 48 c7 c7 e0 2e a6 b7 e8 5c 76 36 fe <0f> 0b e9 a5 f3 ff ff 65 48 8b 1c 25 80 ef 01 00 be 08 00 00 00 48 [ 554.462836] RSP: 0018:ffff88803a4cfad0 EFLAGS: 00010282 [ 554.465129] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb5a3d24f [ 554.468143] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffffb85273f4 [ 554.471000] RBP: ffff88803a4cfc50 R08: fffffbfff701e681 R09: fffffbfff701e681 [ 554.473990] R10: fffffbfff701e680 R11: ffffffffb80f3403 R12: 0000000000000000 [ 554.476831] R13: dffffc0000000000 R14: ffffffffb9714f00 R15: ffff888053103fc8 [ 554.479622] FS: 00007fac6358a540(0000) GS:ffff88805d000000(0000) knlGS:0000000000000000 [ 554.482673] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 554.484949] CR2: 00007fac6343faf0 CR3: 0000000036c22000 CR4: 00000000003406f0 [ 554.487811] Call Trace: [ 554.488860] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.490818] ? do_exit+0x946/0x2980 [ 554.492269] ? mutex_lock_io_nested+0x1250/0x1250 [ 554.494128] ? __lock_acquire+0xe90/0x3c30 [ 554.495774] ? fsnotify_first_mark+0x120/0x120 [ 554.497487] ? vim2m_device_release+0x50/0x50 [vim2m] [ 554.499469] ? v4l2_release+0x1b8/0x390 [videodev] [ 554.501493] v4l2_release+0x1b8/0x390 [videodev] [ 554.503430] __fput+0x256/0x790 [ 554.504711] task_work_run+0x109/0x190 [ 554.506145] do_exit+0x95e/0x2980 [ 554.507421] ? vfs_lock_file+0x21/0xf0 [ 554.509013] ? find_held_lock+0x33/0x1c0 [ 554.510382] ? __close_fd+0xee/0x190 [ 554.511862] ? release_task.part.21+0x1310/0x1310 [ 554.513701] ? lock_downgrade+0x6d0/0x6d0 [ 554.515299] do_group_exit+0xeb/0x2d0 [ 554.516862] __x64_sys_exit_group+0x35/0x40 [ 554.518610] do_syscall_64+0x90/0x450 [ 554.520142] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 554.522289] RIP: 0033:0x7fac6348ecf6 [ 554.523876] Code: Bad RIP value. [ 554.525294] RSP: 002b:00007ffe6373dc58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 554.528555] RAX: ffffffffffffffda RBX: 00007fac6357f760 RCX: 00007fac6348ecf6 [ 554.531537] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 554.534709] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 554.536752] R10: 00007ffe6373db24 R11: 0000000000000246 R12: 00007fac6357f760 [ 554.538643] R13: 0000000000000002 R14: 00007fac63588428 R15: 0000000000000000 [ 554.540634] irq event stamp: 21731 [ 554.541618] hardirqs last enabled at (21731): [] _raw_spin_unlock_irq+0x24/0x30 [ 554.544145] hardirqs last disabled at (21730): [] _raw_spin_lock_irq+0xa/0x40 [ 554.547027] softirqs last enabled at (20148): [] __do_softirq+0x64d/0x906 [ 554.550385] softirqs last disabled at (19857): [] irq_exit+0x175/0x1a0 [ 554.553668] ---[ end trace a389c80c2ca84244 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the video_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f5f842069a911605ede770ef70118b5baaf97892 Author: Hans Verkuil Date: Sat Nov 9 15:06:18 2019 +0100 media: vicodec: media_device_cleanup was called too early [ Upstream commit 693c5f144aeb9636ae161a3c61a838c50b2ae41c ] Running the contrib/test/test-media script in v4l-utils with the vicodec argument will cause this kernel warning: [ 372.298824] ------------[ cut here ]------------ [ 372.298848] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 372.298896] WARNING: CPU: 11 PID: 2220 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10 [ 372.298907] Modules linked in: vicodec v4l2_mem2mem vivid rc_cec v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [last unloaded: vimc] [ 372.298961] CPU: 11 PID: 2220 Comm: sleep Not tainted 5.4.0-rc1-test-no #150 [ 372.298970] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 372.298983] RIP: 0010:__mutex_lock+0x919/0xc10 [ 372.298995] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7 [ 372.299004] RSP: 0018:ffff8881b400fb80 EFLAGS: 00010286 [ 372.299014] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 372.299022] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed1036801f62 [ 372.299030] RBP: ffff8881b400fcf0 R08: ffffffff81217c91 R09: fffffbfff061c271 [ 372.299038] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff88814761dc80 [ 372.299046] R13: 0000000000000000 R14: ffff88814761cbf0 R15: ffff88814761d030 [ 372.299055] FS: 0000000000000000(0000) GS:ffff8881b68c0000(0000) knlGS:0000000000000000 [ 372.299063] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 372.299071] CR2: 00007f606d78aa20 CR3: 0000000003013002 CR4: 00000000001606e0 [ 372.299153] Call Trace: [ 372.299176] ? __kasan_slab_free+0x12f/0x180 [ 372.299187] ? kmem_cache_free+0x9b/0x250 [ 372.299200] ? do_exit+0xcdf/0x1200 [ 372.299210] ? do_group_exit+0x85/0x130 [ 372.299220] ? __x64_sys_exit_group+0x23/0x30 [ 372.299231] ? do_syscall_64+0x5e/0x1c0 [ 372.299241] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 372.299295] ? v4l2_release+0xed/0x190 [videodev] [ 372.299309] ? mutex_lock_io_nested+0xb80/0xb80 [ 372.299323] ? find_held_lock+0x85/0xa0 [ 372.299335] ? fsnotify+0x5b0/0x600 [ 372.299351] ? locks_remove_file+0x78/0x2b0 [ 372.299363] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170 [ 372.299383] ? vidioc_querycap+0x50/0x50 [vicodec] [ 372.299426] ? v4l2_release+0xed/0x190 [videodev] [ 372.299467] v4l2_release+0xed/0x190 [videodev] [ 372.299484] __fput+0x15a/0x390 [ 372.299499] task_work_run+0xb2/0xe0 [ 372.299512] do_exit+0x4d0/0x1200 [ 372.299528] ? do_user_addr_fault+0x367/0x610 [ 372.299538] ? release_task+0x990/0x990 [ 372.299552] ? rwsem_spin_on_owner+0x170/0x170 [ 372.299567] ? vmacache_find+0xb2/0x100 [ 372.299580] do_group_exit+0x85/0x130 [ 372.299592] __x64_sys_exit_group+0x23/0x30 [ 372.299602] do_syscall_64+0x5e/0x1c0 [ 372.299614] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 372.299624] RIP: 0033:0x7f606d74a9d6 [ 372.299640] Code: Bad RIP value. [ 372.299648] RSP: 002b:00007fff65364468 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 372.299658] RAX: ffffffffffffffda RBX: 00007f606d83b760 RCX: 00007f606d74a9d6 [ 372.299666] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 372.299673] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 372.299681] R10: 00007fff65364334 R11: 0000000000000246 R12: 00007f606d83b760 [ 372.299689] R13: 0000000000000002 R14: 00007f606d844428 R15: 0000000000000000 [ 372.299704] ---[ end trace add7d62ca4bc65e3 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the v4l2_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit f90edcff1e097f034c9d695c3ef90750adce7045 Author: Robert Richter Date: Wed Nov 6 09:33:23 2019 +0000 EDAC/ghes: Fix grain calculation [ Upstream commit 7088e29e0423d3195e09079b4f849ec4837e5a75 ] The current code to convert a physical address mask to a grain (defined as granularity in bytes) is: e->grain = ~(mem_err->physical_addr_mask & ~PAGE_MASK); This is broken in several ways: 1) It calculates to wrong grain values. E.g., a physical address mask of ~0xfff should give a grain of 0x1000. Without considering PAGE_MASK, there is an off-by-one. Things are worse when also filtering it with ~PAGE_MASK. This will calculate to a grain with the upper bits set. In the example it even calculates to ~0. 2) The grain does not depend on and is unrelated to the kernel's page-size. The page-size only matters when unmapping memory in memory_failure(). Smaller grains are wrongly rounded up to the page-size, on architectures with a configurable page-size (e.g. arm64) this could round up to the even bigger page-size of the hypervisor. Fix this with: e->grain = ~mem_err->physical_addr_mask + 1; The grain_bits are defined as: grain = 1 << grain_bits; Change also the grain_bits calculation accordingly, it is the same formula as in edac_mc.c now and the code can be unified. The value in ->physical_addr_mask coming from firmware is assumed to be contiguous, but this is not sanity-checked. However, in case the mask is non-contiguous, a conversion to grain_bits effectively converts the grain bit mask to a power of 2 by rounding it up. Suggested-by: James Morse Signed-off-by: Robert Richter Signed-off-by: Borislav Petkov Reviewed-by: Mauro Carvalho Chehab Cc: "linux-edac@vger.kernel.org" Cc: Tony Luck Link: https://lkml.kernel.org/r/20191106093239.25517-11-rrichter@marvell.com Signed-off-by: Sasha Levin commit dd20c1122e248fbafcb4049c50f9bdb3fb808726 Author: Gwendal Grignou Date: Wed Nov 6 09:55:33 2019 -0800 iio: cros_ec_baro: set info_mask_shared_by_all_available field [ Upstream commit e9a4cbcaaa391ef44d623d548ee715e77265030c ] Field was already set for light/proximity and accelerometer/gyroscope/magnetometer sensors. Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs") Signed-off-by: Gwendal Grignou Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit aa32eb1a1043400c112586953d5e6ec94ea659cd Author: Pi-Hsun Shih Date: Sun Nov 10 07:29:10 2019 +0100 media: v4l2-ctrl: Lock main_hdl on operations of requests_queued. [ Upstream commit df4a3e7f88e3b0d7ae46d70b9ff8e3c0ea730785 ] There's a race condition between the list_del_init in the v4l2_ctrl_request_complete, and the list_add_tail in the v4l2_ctrl_request_queue, since they can be called in different thread and the requests_queued list is not protected by a lock. This can lead to that the v4l2_ctrl_handler is still in the requests_queued list while the request_is_queued is already set to false, which would cause use-after-free if the v4l2_ctrl_handler is later released. Fix this by locking the ->lock of main_hdl (which is the owner of the requests_queued list) when doing list operations on the ->requests_queued list. Signed-off-by: Pi-Hsun Shih Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4fde1d03c8914b567dc83287271c00e7e47b8883 Author: Jernej Skrabec Date: Sat Oct 26 09:27:52 2019 +0200 media: cedrus: Use helpers to access capture queue [ Upstream commit 1fd50a2c294457508f06b8b631d01a58de81cdd2 ] Accessing capture queue structue directly is not safe. Use helpers for that. Acked-by: Paul Kocialkowski Signed-off-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c1d3b5cdb5bf1b6151fef96ef487f0e170a64247 Author: Chuhong Yuan Date: Sun Nov 10 07:28:15 2019 +0100 media: si470x-i2c: add missed operations in remove [ Upstream commit 2df200ab234a86836a8879a05a8007d6b884eb14 ] The driver misses calling v4l2_ctrl_handler_free and v4l2_device_unregister in remove like what is done in probe failure. Add the calls to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 50786d47f2b1d3d697dd8dd2f67105a6d752bd3a Author: Mitch Williams Date: Wed Nov 6 02:05:36 2019 -0800 ice: delay less [ Upstream commit 88bb432a55de8ae62106305083a8bfbb23b01ad2 ] Shorten the delay for SQ responses, but increase the number of loops. Max delay time is unchanged, but some operations complete much more quickly. In the process, add a new define to make the delay count and delay time more explicit. Add comments to make things more explicit. This fixes a problem with VF resets failing on with many VFs. Signed-off-by: Mitch Williams Signed-off-by: Tony Nguyen Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 571f8b20d234ecf8844e2a7237ca7d89991d9a22 Author: Herbert Xu Date: Mon Oct 28 15:39:07 2019 +0800 crypto: atmel - Fix authenc support when it is set to m [ Upstream commit 1520c72596dde7f22b8bd6bed3ef7df2b8b7ef39 ] As it is if CONFIG_CRYPTO_DEV_ATMEL_AUTHENC is set to m it is in effect disabled. This patch fixes it by using IS_ENABLED instead of ifdef. Fixes: 89a82ef87e01 ("crypto: atmel-authenc - add support to...") Signed-off-by: Herbert Xu Reviewed-by: Tudor Ambarus Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8e0ffeee41e5cba5ae434cf8d01720bc4de2a405 Author: Pierre-Louis Bossart Date: Tue Oct 22 18:29:48 2019 -0500 soundwire: intel: fix PDI/stream mapping for Bulk [ Upstream commit c134f914e9f55b7817e2bae625ec0e5f1379f7cd ] The previous formula is incorrect for PDI0/1, the mapping is not linear but has a discontinuity between PDI1 and PDI2. This change has no effect on PCM PDIs (same mapping). Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191022232948.17156-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 570cacc74e2216be7631617022238fa482c55885 Author: Mike Isely Date: Wed Nov 6 12:11:14 2019 +0100 media: pvrusb2: Fix oops on tear-down when radio support is not present [ Upstream commit 7f404ae9cf2a285f73b3c18ab9303d54b7a3d8e1 ] In some device configurations there's no radio or radio support in the driver. That's OK, as the driver sets itself up accordingly. However on tear-down in these caes it's still trying to tear down radio related context when there isn't anything there, leading to dereferences through a null pointer and chaos follows. How this bug survived unfixed for 11 years in the pvrusb2 driver is a mystery to me. [hverkuil: fix two checkpatch warnings] Signed-off-by: Mike Isely Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 347d4a868c1a583ba3ed9a8c76b892b7fdf28a17 Author: Masami Hiramatsu Date: Wed Oct 23 13:58:07 2019 +0900 selftests: net: Fix printf format warnings on arm [ Upstream commit 670cd6849ea36ea4df2f2941cf4717dff8755abe ] Fix printf format warnings on arm (and other 32bit arch). - udpgso.c and udpgso_bench_tx use %lu for size_t but it should be unsigned long long on 32bit arch. - so_txtime.c uses %ld for int64_t, but it should be unsigned long long on 32bit arch. Signed-off-by: Masami Hiramatsu Cc: Willem de Bruijn Cc: David S. Miller Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 9b5fcb15befc74252db8ab6eb86659b3d4356ff5 Author: Andrew Jeffery Date: Fri Nov 8 15:49:39 2019 +1030 fsi: core: Fix small accesses and unaligned offsets via sysfs [ Upstream commit 9f4c2b516b4f031e3cd0e45957f4150b3c1a083d ] Subtracting the offset delta from four-byte alignment lead to wrapping of the requested length where `count` is less than `off`. Generalise the length handling to enable and optimise aligned access sizes for all offset and size combinations. The new formula produces the following results for given offset and count values: offset count | length --------------+------- 0 1 | 1 0 2 | 2 0 3 | 2 0 4 | 4 0 5 | 4 1 1 | 1 1 2 | 1 1 3 | 1 1 4 | 1 1 5 | 1 2 1 | 1 2 2 | 2 2 3 | 2 2 4 | 2 2 5 | 2 3 1 | 1 3 2 | 1 3 3 | 1 3 4 | 1 3 5 | 1 We might need something like this for the cfam chardevs as well, for example we don't currently implement any alignment restrictions / handling in the hardware master driver. Signed-off-by: Andrew Jeffery Signed-off-by: Joel Stanley Link: https://lore.kernel.org/r/20191108051945.7109-6-joel@jms.id.au Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 7cddbe4a99d152d17dac8f5f602cfa0bf9d2c2dc Author: Miaoqing Pan Date: Wed Nov 6 20:04:37 2019 +0200 ath10k: fix get invalid tx rate for Mesh metric [ Upstream commit 05a11003a56507023f18d3249a4d4d119c0a3e9c ] ath10k does not provide transmit rate info per MSDU in tx completion, mark that as -1 so mac80211 will ignore the rates. This fixes mac80211 update Mesh link metric with invalid transmit rate info. Tested HW: QCA9984 Tested FW: 10.4-3.9.0.2-00035 Signed-off-by: Hou Bao Hou Signed-off-by: Anilkumar Kolli Signed-off-by: Miaoqing Pan Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 1f724fcdb5151a222d9a96bce18f3317e8746c1f Author: Seung-Woo Kim Date: Mon Nov 4 10:46:32 2019 +0100 media: exynos4-is: fix wrong mdev and v4l2 dev order in error path [ Upstream commit 4d741cbd58bf889c8a68cf6e592a7892b5c2802e ] When driver is built as module and probe during insmod is deferred because of sensor subdevs, there is NULL pointer deference because mdev is cleaned up and then access it from v4l2_device_unregister(). Fix the wrong mdev and v4l2 dev order in error path of probe. This fixes below null pointer deference: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ca026f68 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM [...] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at ida_free+0x7c/0x160 LR is at xas_start+0x44/0x204 [...] [] (ida_free) from [] (__media_device_unregister_entity+0x18/0xc0) [] (__media_device_unregister_entity) from [] (media_device_unregister_entity+0x2c/0x38) [] (media_device_unregister_entity) from [] (v4l2_device_release+0xd0/0x104) [] (v4l2_device_release) from [] (device_release+0x28/0x98) [] (device_release) from [] (kobject_put+0xa4/0x208) [] (kct_put) from [] (fimc_capture_subdev_unregistered+0x58/0x6c [s5p_fimc]) [] (fimc_capture_subdev_unregistered [s5p_fimc]) from [] (v4l2_device_unregister_subdev+0x6c/0xa8) [] (v4l2_device_unregister_subdev) from [] (v4l2_device_unregister+0x64/0x94) [] (v4l2_device_unregister) from [] (fimc_md_probe+0x4ec/0xaf8 [s5p_fimc]) [...] Signed-off-by: Seung-Woo Kim Reviewed-by: Sylwester Nawrocki Fixes: 9832e155f1ed ("[media] media-device: split media initialization and registration") Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit c1e8f4a937ecc3e338657577ea7677b39e04f375 Author: Andrey Grodzovsky Date: Wed Nov 6 12:36:29 2019 -0500 drm/amdgpu: Avoid accidental thread reactivation. [ Upstream commit a28fda312a9fabdf0e5f5652449d6197c9fb0a90 ] Problem: During GPU reset we call the GPU scheduler to suspend it's thread, those two functions in amdgpu also suspend and resume the sceduler for their needs but this can collide with GPU reset in progress and accidently restart a suspended thread before time. Fix: Serialize with GPU reset. Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a58f4afe22354a080cc099f5edcde15b8805c410 Author: Masami Hiramatsu Date: Wed Oct 23 13:57:40 2019 +0900 selftests: proc: Make va_max 1MB [ Upstream commit 2f3571ea71311bbb2cbb9c3bbefc9c1969a3e889 ] Currently proc-self-map-files-002.c sets va_max (max test address of user virtual address) to 4GB, but it is too big for 32bit arch and 1UL << 32 is overflow on 32bit long. Also since this value should be enough bigger than vm.mmap_min_addr (64KB or 32KB by default), 1MB should be enough. Make va_max 1MB unconditionally. Signed-off-by: Masami Hiramatsu Cc: Alexey Dobriyan Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 20832ebf91a654579c029ae627b961137ad47b1a Author: Honglei Wang Date: Wed Oct 30 16:18:10 2019 +0800 cgroup: freezer: don't change task and cgroups status unnecessarily [ Upstream commit 742e8cd3e1ba6f19cad6d912f8d469df5557d0fd ] It's not necessary to adjust the task state and revisit the state of source and destination cgroups if the cgroups are not in freeze state and the task itself is not frozen. And in this scenario, it wakes up the task who's not supposed to be ready to run. Don't do the unnecessary task state adjustment can help stop waking up the task without a reason. Signed-off-by: Honglei Wang Acked-by: Roman Gushchin Signed-off-by: Tejun Heo Signed-off-by: Sasha Levin commit 2170f9d296c87f702391fb5614e08f67632a4cd6 Author: Ilya Leoshkevich Date: Thu Nov 7 15:18:38 2019 +0100 s390/bpf: Use kvcalloc for addrs array [ Upstream commit 166f11d11f6f70439830d09bfa5552ec1b368494 ] A BPF program may consist of 1m instructions, which means JIT instruction-address mapping can be as large as 4m. s390 has FORCE_MAX_ZONEORDER=9 (for memory hotplug reasons), which means maximum kmalloc size is 1m. This makes it impossible to JIT programs with more than 256k instructions. Fix by using kvcalloc, which falls back to vmalloc for larger allocations. An alternative would be to use a radix tree, but that is not supported by bpf_prog_fill_jited_linfo. Signed-off-by: Ilya Leoshkevich Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191107141838.92202-1-iii@linux.ibm.com Signed-off-by: Sasha Levin commit fe3a9c40723235f1c649a1c161011e57a785689d Author: Andrii Nakryiko Date: Wed Nov 6 21:40:59 2019 -0800 libbpf: Fix negative FD close() in xsk_setup_xdp_prog() [ Upstream commit 9656b346b280c3e49c8a116c3a715f966633b161 ] Fix issue reported by static analysis (Coverity). If bpf_prog_get_fd_by_id() fails, xsk_lookup_bpf_maps() will fail as well and clean-up code will attempt close() with fd=-1. Fix by checking bpf_prog_get_fd_by_id() return result and exiting early. Fixes: 10a13bb40e54 ("libbpf: remove qidconf and better support external bpf programs.") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191107054059.313884-1-andriin@fb.com Signed-off-by: Sasha Levin commit 72e7909be5f927f374527382f0334c7e53d2ba69 Author: Masami Hiramatsu Date: Wed Oct 30 16:09:30 2019 +0900 perf probe: Filter out instances except for inlined subroutine and subprogram [ Upstream commit da6cb952a89efe24bb76c4971370d485737a2d85 ] Filter out instances except for inlined_subroutine and subprogram DIE in die_walk_instances() and die_is_func_instance(). This fixes an issue that perf probe sets some probes on calling address instead of a target function itself. When perf probe walks on instances of an abstruct origin (a kind of function prototype of inlined function), die_walk_instances() can also pass a GNU_call_site (a GNU extension for call site) to callback. Since it is not an inlined instance of target function, we have to filter out when searching a probe point. Without this patch, perf probe sets probes on call site address too.This can happen on some function which is marked "inlined", but has actual symbol. (I'm not sure why GCC mark it "inlined"): # perf probe -D vfs_read p:probe/vfs_read _text+2500017 p:probe/vfs_read_1 _text+2499468 p:probe/vfs_read_2 _text+2499563 p:probe/vfs_read_3 _text+2498876 p:probe/vfs_read_4 _text+2498512 p:probe/vfs_read_5 _text+2498627 With this patch: Slightly different results, similar tho: # perf probe -D vfs_read p:probe/vfs_read _text+2498512 Committer testing: # uname -a Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Before: # perf probe -D vfs_read p:probe/vfs_read _text+3131557 p:probe/vfs_read_1 _text+3130975 p:probe/vfs_read_2 _text+3131047 p:probe/vfs_read_3 _text+3130380 p:probe/vfs_read_4 _text+3130000 # uname -a Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # After: # perf probe -D vfs_read p:probe/vfs_read _text+3130000 # Fixes: db0d2c6420ee ("perf probe: Search concrete out-of-line instances") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157241937063.32002.11024544873990816590.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit d7edba63427e7b88f6793fc6427d3e765760cb84 Author: Masami Hiramatsu Date: Wed Oct 30 16:09:21 2019 +0900 perf probe: Skip end-of-sequence and non statement lines [ Upstream commit f4d99bdfd124823a81878b44b5e8750b97f73902 ] Skip end-of-sequence and non-statement lines while walking through lines list. The "end-of-sequence" line information means: "the current address is that of the first byte after the end of a sequence of target machine instructions." (DWARF version 4 spec 6.2.2) This actually means out of scope and we can not probe on it. On the other hand, the statement lines (is_stmt) means: "the current instruction is a recommended breakpoint location. A recommended breakpoint location is intended to “represent” a line, a statement and/or a semantically distinct subpart of a statement." (DWARF version 4 spec 6.2.2) So, non-statement line info also should be skipped. These can reduce unneeded probe points and also avoid an error. E.g. without this patch: # perf probe -a "clear_tasks_mm_cpumask:1" Added new events: probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1) probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:1) probe:clear_tasks_mm_cpumask_2 (on clear_tasks_mm_cpumask:1) probe:clear_tasks_mm_cpumask_3 (on clear_tasks_mm_cpumask:1) probe:clear_tasks_mm_cpumask_4 (on clear_tasks_mm_cpumask:1) You can now use it in all perf tools, such as: perf record -e probe:clear_tasks_mm_cpumask_4 -aR sleep 1 # This puts 5 probes on one line, but acutally it's not inlined function. This is because there are many non statement instructions at the function prologue. With this patch: # perf probe -a "clear_tasks_mm_cpumask:1" Added new event: probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1) You can now use it in all perf tools, such as: perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1 # Now perf-probe skips unneeded addresses. Committer testing: Slightly different results, but similar: Before: # uname -a Linux quaco 5.3.8-200.fc30.x86_64 #1 SMP Tue Oct 29 14:46:22 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # # perf probe -a "clear_tasks_mm_cpumask:1" Added new events: probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1) probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:1) probe:clear_tasks_mm_cpumask_2 (on clear_tasks_mm_cpumask:1) You can now use it in all perf tools, such as: perf record -e probe:clear_tasks_mm_cpumask_2 -aR sleep 1 # After: # perf probe -a "clear_tasks_mm_cpumask:1" Added new event: probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask:1) You can now use it in all perf tools, such as: perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1 # perf probe -l probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c) # Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157241936090.32002.12156347518596111660.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 62152adb3e71756f0968ed6a9b666dc8abec8046 Author: Masami Hiramatsu Date: Wed Oct 30 16:09:40 2019 +0900 perf probe: Fix to show calling lines of inlined functions [ Upstream commit 86c0bf8539e7f46d91bd105e55eda96e0064caef ] Fix to show calling lines of inlined functions (where an inline function is called). die_walk_lines() filtered out the lines inside inlined functions based on the address. However this also filtered out the lines which call those inlined functions from the target function. To solve this issue, check the call_file and call_line attributes and do not filter out if it matches to the line information. Without this fix, perf probe -L doesn't show some lines correctly. (don't see the lines after 17) # perf probe -L vfs_read 0 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos) 1 { 2 ssize_t ret; 4 if (!(file->f_mode & FMODE_READ)) return -EBADF; 6 if (!(file->f_mode & FMODE_CAN_READ)) return -EINVAL; 8 if (unlikely(!access_ok(buf, count))) return -EFAULT; 11 ret = rw_verify_area(READ, file, pos, count); 12 if (!ret) { 13 if (count > MAX_RW_COUNT) count = MAX_RW_COUNT; 15 ret = __vfs_read(file, buf, count, pos); 16 if (ret > 0) { fsnotify_access(file); add_rchar(current, ret); } With this fix: # perf probe -L vfs_read 0 ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos) 1 { 2 ssize_t ret; 4 if (!(file->f_mode & FMODE_READ)) return -EBADF; 6 if (!(file->f_mode & FMODE_CAN_READ)) return -EINVAL; 8 if (unlikely(!access_ok(buf, count))) return -EFAULT; 11 ret = rw_verify_area(READ, file, pos, count); 12 if (!ret) { 13 if (count > MAX_RW_COUNT) count = MAX_RW_COUNT; 15 ret = __vfs_read(file, buf, count, pos); 16 if (ret > 0) { 17 fsnotify_access(file); 18 add_rchar(current, ret); } 20 inc_syscr(current); } Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157241937995.32002.17899884017011512577.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit cdc499b62b6efc0785b5a5f889885916c500983d Author: Masami Hiramatsu Date: Tue Nov 5 09:16:49 2019 +0900 perf probe: Return a better scope DIE if there is no best scope [ Upstream commit c701636aeec4c173208697d68da6e4271125564b ] Make find_best_scope() returns innermost DIE at given address if there is no best matched scope DIE. Since Gcc sometimes generates intuitively strange line info which is out of inlined function address range, we need this fixup. Without this, sometimes perf probe failed to probe on a line inside an inlined function: # perf probe -D ksys_open:3 Failed to find scope of probe point. Error: Failed to add events. With this fix, 'perf probe' can probe it: # perf probe -D ksys_open:3 p:probe/ksys_open _text+25707308 p:probe/ksys_open_1 _text+25710596 p:probe/ksys_open_2 _text+25711114 p:probe/ksys_open_3 _text+25711343 p:probe/ksys_open_4 _text+25714058 p:probe/ksys_open_5 _text+2819653 p:probe/ksys_open_6 _text+2819701 Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Namhyung Kim Cc: Ravi Bangoria Cc: Steven Rostedt (VMware) Cc: Tom Zanussi Link: http://lore.kernel.org/lkml/157291300887.19771.14936015360963292236.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 074b5c1221953ff1e8b101831f847cab32e32fe9 Author: Eric Dumazet Date: Tue Nov 5 14:11:51 2019 -0800 net: avoid potential false sharing in neighbor related code [ Upstream commit 25c7a6d1f90e208ec27ca854b1381ed39842ec57 ] There are common instances of the following construct : if (n->confirmed != now) n->confirmed = now; A C compiler could legally remove the conditional. Use READ_ONCE()/WRITE_ONCE() to avoid this problem. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit ba4c792cae769d2db21d8cc0ff78bf23b6a672c6 Author: Masami Hiramatsu Date: Wed Oct 30 16:09:49 2019 +0900 perf probe: Skip overlapped location on searching variables [ Upstream commit dee36a2abb67c175265d49b9a8c7dfa564463d9a ] Since debuginfo__find_probes() callback function can be called with the location which already passed, the callback function must filter out such overlapped locations. add_probe_trace_event() has already done it by commit 1a375ae7659a ("perf probe: Skip same probe address for a given line"), but add_available_vars() doesn't. Thus perf probe -v shows same address repeatedly as below: # perf probe -V vfs_read:18 Available variables at vfs_read:18 @ char* buf loff_t* pos ssize_t ret struct file* file @ char* buf loff_t* pos ssize_t ret struct file* file @ char* buf loff_t* pos ssize_t ret struct file* file With this fix, perf probe -V shows it correctly: # perf probe -V vfs_read:18 Available variables at vfs_read:18 @ char* buf loff_t* pos ssize_t ret struct file* file @ char* buf loff_t* pos ssize_t ret struct file* file Fixes: cf6eb489e5c0 ("perf probe: Show accessible local variables") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157241938927.32002.4026859017790562751.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7a463116a0a37605c260b2015ed3d1857bc63a3d Author: Ian Rogers Date: Wed Oct 30 15:34:46 2019 -0700 perf parse: If pmu configuration fails free terms [ Upstream commit 38f2c4226e6bc3e8c41c318242821ba5dc825aba ] Avoid a memory leak when the configuration fails. Signed-off-by: Ian Rogers Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andi Kleen Cc: Daniel Borkmann Cc: Jin Yao Cc: John Garry Cc: Kan Liang Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: clang-built-linux@googlegroups.com Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191030223448.12930-9-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b98f7e0c14f7fb6a5e37a0214b49eed2d895f06d Author: Jason Gunthorpe Date: Mon Oct 28 17:10:25 2019 -0300 xen/gntdev: Use select for DMA_SHARED_BUFFER [ Upstream commit fa6614d8ef13c63aac52ad7c07c5e69ce4aba3dd ] DMA_SHARED_BUFFER can not be enabled by the user (it represents a library set in the kernel). The kconfig convention is to use select for such symbols so they are turned on implicitly when the user enables a kconfig that needs them. Otherwise the XEN_GNTDEV_DMABUF kconfig is overly difficult to enable. Fixes: 932d6562179e ("xen/gntdev: Add initial support for dma-buf UAPI") Cc: Oleksandr Andrushchenko Cc: Boris Ostrovsky Cc: xen-devel@lists.xenproject.org Cc: Juergen Gross Cc: Stefano Stabellini Reviewed-by: Juergen Gross Reviewed-by: Oleksandr Andrushchenko Signed-off-by: Jason Gunthorpe Signed-off-by: Juergen Gross Signed-off-by: Sasha Levin commit d8b9bab307926f6fcc829063c7e30c59d21e92ab Author: Michal Swiatkowski Date: Wed Oct 9 07:09:47 2019 -0700 ice: Check for null pointer dereference when setting rings [ Upstream commit eb0ee8abfeb9ff4b98e8e40217b8667bfb08587a ] Without this check rebuild vsi can lead to kernel panic. Signed-off-by: Michal Swiatkowski Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 7f4402438463b25b3fd754e0c9d5f92d408ab127 Author: Pan Bian Date: Wed Nov 6 17:14:45 2019 +0800 drm/amdgpu: fix potential double drop fence reference [ Upstream commit 946ab8db6953535a3a88c957db8328beacdfed9d ] The object fence is not set to NULL after its reference is dropped. As a result, its reference may be dropped again if error occurs after that, which may lead to a use after free bug. To avoid the issue, fence is explicitly set to NULL after dropping its reference. Acked-by: Christian König Signed-off-by: Pan Bian Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0e8aeefb97c00a50921d95d49a48d8395ffdb5b8 Author: Raul E Rangel Date: Tue Nov 5 15:58:02 2019 -0700 drm/amd/powerplay: fix struct init in renoir_print_clk_levels [ Upstream commit d942070575910fdb687b9c8fd5467704b2f77c24 ] drivers/gpu/drm/amd/powerplay/renoir_ppt.c:186:2: error: missing braces around initializer [-Werror=missing-braces] SmuMetrics_t metrics = {0}; ^ Fixes: 8b8031703bd7 ("drm/amd/powerplay: implement sysfs for getting dpm clock") Signed-off-by: Raul E Rangel Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 16cee216caa1bebc30f2cfde50d7a587e279d438 Author: Hawking Zhang Date: Mon Nov 4 16:20:06 2019 +0800 drm/amdgpu: disallow direct upload save restore list from gfx driver [ Upstream commit 58f46d4b65021083ef4b4d49c6e2c58e5783f626 ] Direct uploading save/restore list via mmio register writes breaks the security policy. Instead, the driver should pass s&r list to psp. For all the ASICs that use rlc v2_1 headers, the driver actually upload s&r list twice, in non-psp ucode front door loading phase and gfx pg initialization phase. The latter is not allowed. VG12 is the only exception where the driver still keeps legacy approach for S&R list uploading. In theory, this can be elimnated if we have valid srcntl ucode for VG12. Signed-off-by: Hawking Zhang Reviewed-by: Candice Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 07e9503a23913439124fc056ffe12538a1311b65 Author: Ian Rogers Date: Fri Oct 25 11:08:22 2019 -0700 perf tools: Splice events onto evlist even on error [ Upstream commit 8e8714c3d157568b7a769917a5e05573bbaf5af0 ] If event parsing fails the event list is leaked, instead splice the list onto the out result and let the caller cleanup. An example input for parse_events found by libFuzzer that reproduces this memory leak is 'm{'. Signed-off-by: Ian Rogers Acked-by: Jiri Olsa Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Alexei Starovoitov Cc: Andi Kleen Cc: Daniel Borkmann Cc: Jin Yao Cc: John Garry Cc: Kan Liang Cc: Mark Rutland Cc: Martin KaFai Lau Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Stephane Eranian Cc: Yonghong Song Cc: bpf@vger.kernel.org Cc: clang-built-linux@googlegroups.com Cc: netdev@vger.kernel.org Link: http://lore.kernel.org/lkml/20191025180827.191916-5-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1302caaef52ab9401d080d6a31eab9166be560cd Author: John Garry Date: Wed Nov 6 21:00:54 2019 +0800 perf tools: Fix cross compile for ARM64 [ Upstream commit 71f699078b154fcb1c9162fd0208ada9ce532ffc ] Currently when cross compiling perf tool for ARM64 on my x86 machine I get this error: arch/arm64/util/sym-handling.c:9:10: fatal error: gelf.h: No such file or directory #include For the build, libelf is reported off: Auto-detecting system features: ... ... libelf: [ OFF ] Indeed, test-libelf is not built successfully: more ./build/feature/test-libelf.make.output test-libelf.c:2:10: fatal error: libelf.h: No such file or directory #include ^~~~~~~~~~ compilation terminated. I have no such problems natively compiling on ARM64, and I did not previously have this issue for cross compiling. Fix by relocating the gelf.h include. Signed-off-by: John Garry Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Link: http://lore.kernel.org/lkml/1573045254-39833-1-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit e9532d3261c7b6eec4b82649b1b60e1b3852045d Author: Masami Hiramatsu Date: Fri Oct 25 17:46:34 2019 +0900 perf probe: Fix to probe a function which has no entry pc [ Upstream commit 5d16dbcc311d91267ddb45c6da4f187be320ecee ] Fix 'perf probe' to probe a function which has no entry pc or low pc but only has ranges attribute. probe_point_search_cb() uses dwarf_entrypc() to get the probe address, but that doesn't work for the function DIE which has only ranges attribute. Use die_entrypc() instead. Without this fix: # perf probe -k ../build-x86_64/vmlinux -D clear_tasks_mm_cpumask:0 Probe point 'clear_tasks_mm_cpumask' not found. Error: Failed to add events. With this: # perf probe -k ../build-x86_64/vmlinux -D clear_tasks_mm_cpumask:0 p:probe/clear_tasks_mm_cpumask clear_tasks_mm_cpumask+0 Committer testing: Before: [root@quaco ~]# perf probe clear_tasks_mm_cpumask:0 Probe point 'clear_tasks_mm_cpumask' not found. Error: Failed to add events. [root@quaco ~]# After: [root@quaco ~]# perf probe clear_tasks_mm_cpumask:0 Added new event: probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask) You can now use it in all perf tools, such as: perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1 [root@quaco ~]# Using it with 'perf trace': [root@quaco ~]# perf trace -e probe:clear_tasks_mm_cpumask Doesn't seem to be used in x86_64: $ find . -name "*.c" | xargs grep clear_tasks_mm_cpumask ./kernel/cpu.c: * clear_tasks_mm_cpumask - Safely clear tasks' mm_cpumask for a CPU ./kernel/cpu.c:void clear_tasks_mm_cpumask(int cpu) ./arch/xtensa/kernel/smp.c: clear_tasks_mm_cpumask(cpu); ./arch/csky/kernel/smp.c: clear_tasks_mm_cpumask(cpu); ./arch/sh/kernel/smp.c: clear_tasks_mm_cpumask(cpu); ./arch/arm/kernel/smp.c: clear_tasks_mm_cpumask(cpu); ./arch/powerpc/mm/nohash/mmu_context.c: clear_tasks_mm_cpumask(cpu); $ find . -name "*.h" | xargs grep clear_tasks_mm_cpumask ./include/linux/cpu.h:void clear_tasks_mm_cpumask(int cpu); $ find . -name "*.S" | xargs grep clear_tasks_mm_cpumask $ Fixes: e1ecbbc3fa83 ("perf probe: Fix to handle optimized not-inlined functions") Reported-by: Arnaldo Carvalho de Melo Tested-by: Arnaldo Carvalho de Melo Signed-off-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157199319438.8075.4695576954550638618.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 47326a4f9ca11c24c93585a9edf266e710a08856 Author: James Clark Date: Mon Oct 28 11:34:01 2019 +0000 libsubcmd: Use -O0 with DEBUG=1 [ Upstream commit 22bd8f1b5a1dd168ba4eba27cb17643a11012f5d ] When a 'make DEBUG=1' build is done, the command parser is still built with -O6 and is hard to step through, fix it making it use -O0 in that case. Signed-off-by: James Clark Cc: Adrian Hunter Cc: Ian Rogers Cc: Jiri Olsa Cc: Josh Poimboeuf Cc: Namhyung Kim Cc: nd Link: http://lore.kernel.org/lkml/20191028113340.4282-1-james.clark@arm.com [ split from a larger patch ] Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3be8c5caa51c184b36d45cd21e360f26f5ce1235 Author: Masami Hiramatsu Date: Fri Oct 25 17:47:01 2019 +0900 perf probe: Fix to show inlined function callsite without entry_pc [ Upstream commit 18e21eb671dc87a4f0546ba505a89ea93598a634 ] Fix 'perf probe --line' option to show inlined function callsite lines even if the function DIE has only ranges. Without this: # perf probe -L amd_put_event_constraints ... 2 { 3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw)) __amd_put_nb_event_constraints(cpuc, event); 5 } With this patch: # perf probe -L amd_put_event_constraints ... 2 { 3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw)) 4 __amd_put_nb_event_constraints(cpuc, event); 5 } Committer testing: Before: [root@quaco ~]# perf probe -L amd_put_event_constraints 0 static void amd_put_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event) 2 { 3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw)) __amd_put_nb_event_constraints(cpuc, event); 5 } PMU_FORMAT_ATTR(event, "config:0-7,32-35"); PMU_FORMAT_ATTR(umask, "config:8-15" ); [root@quaco ~]# After: [root@quaco ~]# perf probe -L amd_put_event_constraints 0 static void amd_put_event_constraints(struct cpu_hw_events *cpuc, struct perf_event *event) 2 { 3 if (amd_has_nb(cpuc) && amd_is_nb_event(&event->hw)) 4 __amd_put_nb_event_constraints(cpuc, event); 5 } PMU_FORMAT_ATTR(event, "config:0-7,32-35"); PMU_FORMAT_ATTR(umask, "config:8-15" ); [root@quaco ~]# perf probe amd_put_event_constraints:4 Added new event: probe:amd_put_event_constraints (on amd_put_event_constraints:4) You can now use it in all perf tools, such as: perf record -e probe:amd_put_event_constraints -aR sleep 1 [root@quaco ~]# [root@quaco ~]# perf probe -l probe:amd_put_event_constraints (on amd_put_event_constraints:4@arch/x86/events/amd/core.c) probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c) [root@quaco ~]# Using it: [root@quaco ~]# perf trace -e probe:* ^C[root@quaco ~]# Ok, Intel system here... :-) Fixes: 4cc9cec636e7 ("perf probe: Introduce lines walker interface") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157199322107.8075.12659099000567865708.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit b61ffc949cd4d90536ec382e0df3970483673cd2 Author: Masami Hiramatsu Date: Fri Oct 25 17:47:10 2019 +0900 perf probe: Fix to show ranges of variables in functions without entry_pc [ Upstream commit af04dd2f8ebaa8fbd46f698714acbf43da14da45 ] Fix to show ranges of variables (--range and --vars option) in functions which DIE has only ranges but no entry_pc attribute. Without this fix: # perf probe --range -V clear_tasks_mm_cpumask Available variables at clear_tasks_mm_cpumask @ (No matched variables) With this fix: # perf probe --range -V clear_tasks_mm_cpumask Available variables at clear_tasks_mm_cpumask @ [VAL] int cpu @ Committer testing: Before: [root@quaco ~]# perf probe --range -V clear_tasks_mm_cpumask Available variables at clear_tasks_mm_cpumask @ (No matched variables) [root@quaco ~]# After: [root@quaco ~]# perf probe --range -V clear_tasks_mm_cpumask Available variables at clear_tasks_mm_cpumask @ [VAL] int cpu @ [root@quaco ~]# Using it: [root@quaco ~]# perf probe clear_tasks_mm_cpumask cpu Added new event: probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask with cpu) You can now use it in all perf tools, such as: perf record -e probe:clear_tasks_mm_cpumask -aR sleep 1 [root@quaco ~]# perf probe -l probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c with cpu) [root@quaco ~]# [root@quaco ~]# perf trace -e probe:*cpumask ^C[root@quaco ~]# Fixes: 349e8d261131 ("perf probe: Add --range option to show a variable's location range") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157199323018.8075.8179744380479673672.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit ec93c02198de8cfbf96efb66c3ba458957c814af Author: Masami Hiramatsu Date: Fri Oct 25 17:46:43 2019 +0900 perf probe: Fix to probe an inline function which has no entry pc [ Upstream commit eb6933b29d20bf2c3053883d409a53f462c1a3ac ] Fix perf probe to probe an inlne function which has no entry pc or low pc but only has ranges attribute. This seems very rare case, but I could find a few examples, as same as probe_point_search_cb(), use die_entrypc() to get the entry address in probe_point_inline_cb() too. Without this patch: # perf probe -D __amd_put_nb_event_constraints Failed to get entry address of __amd_put_nb_event_constraints. Probe point '__amd_put_nb_event_constraints' not found. Error: Failed to add events. With this patch: # perf probe -D __amd_put_nb_event_constraints p:probe/__amd_put_nb_event_constraints amd_put_event_constraints+43 Committer testing: Before: [root@quaco ~]# perf probe -D __amd_put_nb_event_constraints Failed to get entry address of __amd_put_nb_event_constraints. Probe point '__amd_put_nb_event_constraints' not found. Error: Failed to add events. [root@quaco ~]# After: [root@quaco ~]# perf probe -D __amd_put_nb_event_constraints p:probe/__amd_put_nb_event_constraints _text+33789 [root@quaco ~]# Fixes: 4ea42b181434 ("perf: Add perf probe subcommand, a kprobe-event setup helper") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157199320336.8075.16189530425277588587.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 8c5d03e73d6b2f23f40c306e18608d214220401f Author: Masami Hiramatsu Date: Thu Oct 24 18:12:45 2019 +0900 perf probe: Walk function lines in lexical blocks [ Upstream commit acb6a7047ac2146b723fef69ee1ab6b7143546bf ] Since some inlined functions are in lexical blocks of given function, we have to recursively walk through the DIE tree. Without this fix, perf-probe -L can miss the inlined functions which is in a lexical block (like if (..) { func() } case.) However, even though, to walk the lines in a given function, we don't need to follow the children DIE of inlined functions because those do not have any lines in the specified function. We need to walk though whole trees only if we walk all lines in a given file, because an inlined function can include another inlined function in the same file. Fixes: b0e9cb2802d4 ("perf probe: Fix to search nested inlined functions in CU") Signed-off-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157190836514.1859.15996864849678136353.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 033176a6a814a020f48dfe4b0aa233dbbdbf8456 Author: Yunfeng Ye Date: Wed Oct 16 21:50:17 2019 +0800 perf jevents: Fix resource leak in process_mapfile() and main() [ Upstream commit 1785fbb73896dbd9d27a406f0d73047df42db710 ] There are memory leaks and file descriptor resource leaks in process_mapfile() and main(). Fix this by adding free(), fclose() and free_arch_std_events() on the error paths. Fixes: 80eeb67fe577 ("perf jevents: Program to convert JSON file") Fixes: 3f056b66647b ("perf jevents: Make build fail on JSON parse error") Fixes: e9d32c1bf0cd ("perf vendor events: Add support for arch standard events") Signed-off-by: Yunfeng Ye Cc: Alexander Shishkin Cc: Andi Kleen Cc: Feilong Lin Cc: Hu Shiyuan Cc: Jiri Olsa Cc: John Garry Cc: Kan Liang Cc: Luke Mujica Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Zenghui Yu Link: http://lore.kernel.org/lkml/d7907042-ec9c-2bef-25b4-810e14602f89@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit cdbeab129c5a8213a100e9c636f86cea2db79879 Author: Masami Hiramatsu Date: Fri Oct 25 17:46:52 2019 +0900 perf probe: Fix to list probe event with correct line number [ Upstream commit 3895534dd78f0fd4d3f9e05ee52b9cdd444a743e ] Since debuginfo__find_probe_point() uses dwarf_entrypc() for finding the entry address of the function on which a probe is, it will fail when the function DIE has only ranges attribute. To fix this issue, use die_entrypc() instead of dwarf_entrypc(). Without this fix, perf probe -l shows incorrect offset: # perf probe -l probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask+18446744071579263632@work/linux/linux/kernel/cpu.c) probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask+18446744071579263752@work/linux/linux/kernel/cpu.c) With this: # perf probe -l probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@work/linux/linux/kernel/cpu.c) probe:clear_tasks_mm_cpumask_1 (on clear_tasks_mm_cpumask:21@work/linux/linux/kernel/cpu.c) Committer testing: Before: [root@quaco ~]# perf probe -l probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask+18446744071579765152@kernel/cpu.c) [root@quaco ~]# After: [root@quaco ~]# perf probe -l probe:clear_tasks_mm_cpumask (on clear_tasks_mm_cpumask@kernel/cpu.c) [root@quaco ~]# Fixes: 1d46ea2a6a40 ("perf probe: Fix listing incorrect line number with inline function") Signed-off-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157199321227.8075.14655572419136993015.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 67eef43dbb5e4dba963c6fefea0490e743c5b711 Author: Leo Yan Date: Mon Oct 21 15:48:08 2019 +0800 perf cs-etm: Fix definition of macro TO_CS_QUEUE_NR [ Upstream commit 9d604aad4bb022e848dec80d6fe5f73fe87061a2 ] Macro TO_CS_QUEUE_NR definition has a typo, which uses 'trace_id_chan' as its parameter, this doesn't match with its definition body which uses 'trace_chan_id'. So renames the parameter to 'trace_chan_id'. It's luck to have a local variable 'trace_chan_id' in the function cs_etm__setup_queue(), even we wrongly define the macro TO_CS_QUEUE_NR, the local variable 'trace_chan_id' is used rather than the macro's parameter 'trace_id_chan'; so the compiler doesn't complain for this before. After renaming the parameter, it leads to a compiling error due cs_etm__setup_queue() has no variable 'trace_id_chan'. This patch uses the variable 'trace_chan_id' for the macro so that fixes the compiling error. Signed-off-by: Leo Yan Reviewed-by: Mathieu Poirier Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Suzuki Poulouse Cc: coresight ml Cc: linux-arm-kernel@lists.infradead.org Link: http://lore.kernel.org/lkml/20191021074808.25795-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit bb3e5a47261a86db37392a5372cb0f1727515daa Author: Masami Hiramatsu Date: Thu Oct 24 18:12:36 2019 +0900 perf probe: Fix to find range-only function instance [ Upstream commit b77afa1f810f37bd8a36cb1318178dfe2d7af6b6 ] Fix die_is_func_instance() to find range-only function instance. In some case, a function instance can be made without any low PC or entry PC, but only with address ranges by optimization. (e.g. cold text partially in "text.unlikely" section) To find such function instance, we have to check the range attribute too. Fixes: e1ecbbc3fa83 ("perf probe: Fix to handle optimized not-inlined functions") Signed-off-by: Masami Hiramatsu Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/157190835669.1859.8368628035930950596.stgit@devnote2 Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9757e692411d74e41ed274fcd2ab89ec9d8e1b52 Author: Ping-Ke Shih Date: Tue Nov 5 10:18:38 2019 +0800 rtlwifi: fix memory leak in rtl92c_set_fw_rsvdpagepkt() [ Upstream commit 5174f1e41074b5186608badc2e89441d021e8c08 ] This leak was found by testing the EDIMAX EW-7612 on Raspberry Pi 3B+ with Linux 5.4-rc5 (multi_v7_defconfig + rtlwifi + kmemleak) and noticed a single memory leak during probe: unreferenced object 0xec13ee40 (size 176): comm "kworker/u8:1", pid 36, jiffies 4294939321 (age 5580.790s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __netdev_alloc_skb+0x9c/0x164 [<863dfa6e>] rtl92c_set_fw_rsvdpagepkt+0x254/0x340 [rtl8192c_common] [<9572be0d>] rtl92cu_set_hw_reg+0xf48/0xfa4 [rtl8192cu] [<116df4d8>] rtl_op_bss_info_changed+0x234/0x96c [rtlwifi] [<8933575f>] ieee80211_bss_info_change_notify+0xb8/0x264 [mac80211] [] ieee80211_assoc_success+0x934/0x1798 [mac80211] [] ieee80211_rx_mgmt_assoc_resp+0x174/0x314 [mac80211] [<5974629e>] ieee80211_sta_rx_queued_mgmt+0x3f4/0x7f0 [mac80211] [] ieee80211_iface_work+0x208/0x318 [mac80211] [] process_one_work+0x22c/0x564 [] worker_thread+0x44/0x5d8 [<82c7b073>] kthread+0x150/0x154 [] ret_from_fork+0x14/0x2c [<794dff30>] 0x0 It is because 8192cu doesn't implement usb_cmd_send_packet(), and this patch just frees the skb within the function to resolve memleak problem by now. Since 8192cu doesn't turn on fwctrl_lps that needs to download command packet for firmware via the function, applying this patch doesn't affect driver behavior. Reported-by: Stefan Wahren Signed-off-by: Ping-Ke Shih Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 2eb7ab5e756c903fc86c9d596f9bda46ebb79941 Author: Sharat Masetty Date: Wed Nov 6 17:19:23 2019 +0530 drm: msm: a6xx: fix debug bus register configuration [ Upstream commit 7f4009c4bbea4438b50f3b12d1c57da3f5cd8db3 ] Fix the cx debugbus related register configuration, to collect accurate bus data during gpu snapshot. This helps with complete snapshot dump and also complete proper GPU recovery. Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state") Reviewed-by: Rob Clark Signed-off-by: Sharat Masetty Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/339165 Signed-off-by: Sasha Levin commit 7613870e2501e618770fd602a46d9fae317236e1 Author: Kamal Heib Date: Mon Oct 28 17:59:28 2019 +0200 RDMA/core: Fix return code when modify_port isn't supported [ Upstream commit 55bfe905fa97633438c13fb029aed85371d85480 ] Improve return code from ib_modify_port() by doing the following: - Use "-EOPNOTSUPP" instead "-ENOSYS" which is the proper return code - Allow only fake IB_PORT_CM_SUP manipulation for RoCE providers that didn't implement the modify_port callback, otherwise return "-EOPNOTSUPP" Fixes: 61e0962d5221 ("IB: Avoid ib_modify_port() failure for RoCE devices") Link: https://lore.kernel.org/r/20191028155931.1114-2-kamalheib1@gmail.com Signed-off-by: Kamal Heib Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit d3362d67bbc5886ca21a204fc2ff5560ac321204 Author: Takashi Iwai Date: Wed Nov 6 16:42:57 2019 +0100 ALSA: timer: Limit max amount of slave instances [ Upstream commit fdea53fe5de532969a332d6e5e727f2ad8bf084d ] The fuzzer tries to open the timer instances as much as possible, and this may cause a system hiccup easily. We've already introduced the cap for the max number of available instances for the h/w timers, and we should put such a limit also to the slave timers, too. This patch introduces the limit to the multiple opened slave timers. The upper limit is hard-coded to 1000 for now, which should suffice for any practical usages up to now. Link: https://lore.kernel.org/r/20191106154257.5853-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit cc492872180a5c58ac4166ca650d80468db97ba3 Author: Pan Bian Date: Wed Nov 6 10:36:09 2019 +0800 spi: img-spfi: fix potential double release [ Upstream commit e9a8ba9769a0e354341bc6cc01b98aadcea1dfe9 ] The channels spfi->tx_ch and spfi->rx_ch are not set to NULL after they are released. As a result, they will be released again, either on the error handling branch in the same function or in the corresponding remove function, i.e. img_spfi_remove(). This patch fixes the bug by setting the two members to NULL. Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/1573007769-20131-1-git-send-email-bianpan2016@163.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 197803ca31017f4fe52336a2a220796d0deb647a Author: Manish Chopra Date: Mon Nov 4 21:51:11 2019 -0800 bnx2x: Fix PF-VF communication over multi-cos queues. [ Upstream commit dc5a3d79c345871439ffe72550b604fcde9770e1 ] PF driver doesn't enable tx-switching for all cos queues/clients, which causes packets drop from PF to VF. Fix this by enabling tx-switching on all cos queues/clients. Signed-off-by: Manish Chopra Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6431e1fb7b6ca5496aecedfce3a18c7ead236231 Author: Thor Thayer Date: Tue Nov 5 14:22:10 2019 -0600 spi: dw: Fix Designware SPI loopback [ Upstream commit 1403cfa69d310781f9548951c97725c67ffcf613 ] The SPI_LOOP is set in spi->mode but not propagated to the register. A previous patch removed the bit during a cleanup. Fixes: e1bc204894ea ("spi: dw: fix potential variable assignment error") Signed-off-by: Thor Thayer Link: https://lore.kernel.org/r/1572985330-5525-1-git-send-email-thor.thayer@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 12d8deb5213ea8a566e9c4b463233e92abaded04 Author: Hans Verkuil Date: Sat Nov 2 14:35:41 2019 -0300 media: vivid: media_device_cleanup was called too early [ Upstream commit 8ffd573c25e5fac1daeeffc592e2ed6bc6a3d947 ] Running the contrib/test/test-media script in v4l-utils with the vivid argument will cause this kernel warning: [ 104.748720] videodev: v4l2_release [ 104.748731] ------------[ cut here ]------------ [ 104.748750] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [ 104.748790] WARNING: CPU: 6 PID: 1823 at kernel/locking/mutex.c:938 __mutex_lock+0x919/0xc10 [ 104.748800] Modules linked in: rc_cec vivid v4l2_tpg videobuf2_dma_contig cec rc_core v4l2_dv_timings videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc vmw_balloon vmw_vmci button vmwgfx [ 104.748845] CPU: 6 PID: 1823 Comm: sleep Not tainted 5.4.0-rc1-test-no #150 [ 104.748853] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/29/2019 [ 104.748867] RIP: 0010:__mutex_lock+0x919/0xc10 [ 104.748878] Code: 59 83 e8 9a fc 16 ff 44 8b 05 23 61 38 01 45 85 c0 0f 85 ef f7 ff ff 48 c7 c6 a0 1f 87 82 48 c7 c7 a0 1e 87 82 e8 cd bb f7 fe <0f> 0b e9 d5 f7 ff ff f6 c3 04 0f 84 3b fd ff ff 49 89 df 41 83 e7 [ 104.748886] RSP: 0018:ffff88811a357b80 EFLAGS: 00010286 [ 104.748895] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 104.748902] RDX: 0000000000000003 RSI: 0000000000000004 RDI: ffffed102346af62 [ 104.748910] RBP: ffff88811a357cf0 R08: ffffffff81217c91 R09: fffffbfff061c271 [ 104.748917] R10: fffffbfff061c270 R11: ffffffff830e1383 R12: ffff8881a46103c0 [ 104.748924] R13: 0000000000000000 R14: ffff8881a4614f90 R15: ffff8881a46153d0 [ 104.748933] FS: 0000000000000000(0000) GS:ffff8881b6780000(0000) knlGS:0000000000000000 [ 104.748940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 104.748949] CR2: 00007f163fc9ca20 CR3: 0000000003013004 CR4: 00000000001606e0 [ 104.749036] Call Trace: [ 104.749051] ? _raw_spin_unlock+0x1f/0x30 [ 104.749067] ? llist_add_batch+0x33/0x50 [ 104.749081] ? tick_nohz_tick_stopped+0x19/0x30 [ 104.749130] ? v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749143] ? mutex_lock_io_nested+0xb80/0xb80 [ 104.749153] ? vprintk_emit+0xf2/0x220 [ 104.749191] ? vivid_req_validate+0x40/0x40 [vivid] [ 104.749201] ? printk+0xad/0xde [ 104.749211] ? kmsg_dump_rewind_nolock+0x54/0x54 [ 104.749226] ? locks_remove_file+0x78/0x2b0 [ 104.749248] ? __fsnotify_update_child_dentry_flags.part.0+0x170/0x170 [ 104.749281] ? vivid_req_validate+0x40/0x40 [vivid] [ 104.749321] ? v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749361] v4l2_release.cold+0x6c/0xd6 [videodev] [ 104.749378] __fput+0x15a/0x390 [ 104.749393] task_work_run+0xb2/0xe0 [ 104.749407] do_exit+0x4d0/0x1200 [ 104.749422] ? do_user_addr_fault+0x367/0x610 [ 104.749431] ? release_task+0x990/0x990 [ 104.749449] ? rwsem_spin_on_owner+0x170/0x170 [ 104.749463] ? vmacache_find+0xb2/0x100 [ 104.749476] do_group_exit+0x85/0x130 [ 104.749487] __x64_sys_exit_group+0x23/0x30 [ 104.749500] do_syscall_64+0x5e/0x1c0 [ 104.749511] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 104.749520] RIP: 0033:0x7f163fc5c9d6 [ 104.749536] Code: Bad RIP value. [ 104.749543] RSP: 002b:00007ffe6f3bec58 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [ 104.749553] RAX: ffffffffffffffda RBX: 00007f163fd4d760 RCX: 00007f163fc5c9d6 [ 104.749560] RDX: 0000000000000000 RSI: 000000000000003c RDI: 0000000000000000 [ 104.749567] RBP: 0000000000000000 R08: 00000000000000e7 R09: ffffffffffffff80 [ 104.749574] R10: 00007ffe6f3beb24 R11: 0000000000000246 R12: 00007f163fd4d760 [ 104.749581] R13: 0000000000000002 R14: 00007f163fd56428 R15: 0000000000000000 [ 104.749597] ---[ end trace 66f20f73fc0daf79 ]--- This is caused by media_device_cleanup() which destroys v4l2_dev->mdev->req_queue_mutex. But v4l2_release() tries to lock that mutex after media_device_cleanup() is called. By moving media_device_cleanup() to the v4l2_device's release function it is guaranteed that the mutex is valid whenever v4l2_release is called. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit fc766aec029666376e0f196a39437ae4c562812c Author: Ranjani Sridharan Date: Mon Nov 4 14:48:12 2019 -0800 ASoC: SOF: topology: set trigger order for FE DAI link [ Upstream commit 5eee2b3f60065a2530d13f28e771be48b989eb4c ] Set trigger order for FE DAI links to SND_SOC_DPCM_TRIGGER_POST to trigger the BE DAI's before the FE DAI's. This prevents the xruns seen on playback pipelines using the link DMA. Signed-off-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191104224812.3393-3-ranjani.sridharan@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3667802808bec02e0762ef95a4058d17281a79a3 Author: Sebastian Reichel Date: Tue Oct 29 11:42:31 2019 +0000 nvmem: core: fix nvmem_cell_write inline function [ Upstream commit 9b8303fc6efa724bd6a90656434fbde2cc6ceb2c ] nvmem_cell_write's buf argument uses different types based on the configuration of CONFIG_NVMEM. The function prototype for enabled NVMEM uses 'void *' type, but the static dummy function for disabled NVMEM uses 'const char *' instead. Fix the different behaviour by always expecting a 'void *' typed buf argument. Fixes: 7a78a7f7695b ("power: reset: nvmem-reboot-mode: use NVMEM as reboot mode write interface") Reported-by: kbuild test robot Cc: Han Nandor Cc: Srinivas Kandagatla Cc: linux-kernel@vger.kernel.org Signed-off-by: Sebastian Reichel Reviewed-By: Han Nandor Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20191029114240.14905-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 052644a373ad797171bf00cdd746e04650f844c8 Author: Lucas Stach Date: Tue Oct 29 11:42:35 2019 +0000 nvmem: imx-ocotp: reset error status on probe [ Upstream commit c33c585f1b3a99d53920bdac614aca461d8db06f ] If software running before the OCOTP driver is loaded left the controller with the error status pending, the driver will never be able to complete the read timing setup. Reset the error status on probe to make sure the controller is in usable state. Signed-off-by: Lucas Stach Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20191029114240.14905-6-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 548f67fb8c361d49d4603e331bf5549f067de7ce Author: Fabio Estevam Date: Mon Oct 28 14:13:13 2019 -0300 media: staging/imx: Use a shorter name for driver [ Upstream commit ce22c6f242b6d7b5e0318da2c92b5b00b5bbc698 ] Currently v4l2-compliance tool returns the following output: Compliance test for imx-media-captu device /dev/video0: Driver Info: Driver name : imx-media-captu Card type : imx-media-capture ... The driver name string is limited to 16 characters, so provide a shorter name so that we can have a better output. While at it, use the same shorter name for driver and card. Signed-off-by: Fabio Estevam Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 46fab2db2002151c37ce4992c9036e316a23e9fa Author: Max Gurtovoy Date: Sun Oct 13 19:57:35 2019 +0300 nvme: introduce "Command Aborted By host" status code [ Upstream commit 2dc3947b53f573e8a75ea9cbec5588df88ca502e ] Fix the status code of canceled requests initiated by the host according to TP4028 (Status Code 0x371): "Command Aborted By host: The command was aborted as a result of host action (e.g., the host disconnected the Fabric connection)." Also in a multipath environment, unless otherwise specified, errors of this type (path related) should be retried using a different path, if one is available. Signed-off-by: Max Gurtovoy Reviewed-by: Christoph Hellwig Signed-off-by: Keith Busch Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 6e7a164f18e930be72dabb0c8caf3195474e27e0 Author: Vandana BN Date: Tue Oct 22 04:51:40 2019 -0300 media: v4l2-core: fix touch support in v4l_g_fmt [ Upstream commit 545b618cfb5cadacd00c25066b9a36540e5ca9e9 ] v4l_s_fmt, for VFL_TYPE_TOUCH, sets unneeded members of the v4l2_pix_format structure to default values.This was missing in v4l_g_fmt, which would lead to failures in v4l2-compliance tests. Signed-off-by: Vandana BN Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 96d7c3cb33c591070d067b048129a4ddd9fb9346 Author: Kangjie Lu Date: Fri Oct 18 01:47:00 2019 -0300 media: rcar_drif: fix a memory disclosure [ Upstream commit d39083234c60519724c6ed59509a2129fd2aed41 ] "f->fmt.sdr.reserved" is uninitialized. As other peer drivers like msi2500 and airspy do, the fix initializes it to avoid memory disclosures. Signed-off-by: Kangjie Lu Reviewed-by: Geert Uytterhoeven Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bf76b8a26544b59aad663c83cfe075df77fda75d Author: Ondrej Jirman Date: Fri Nov 1 17:41:51 2019 +0100 cpufreq: sun50i: Fix CPU speed bin detection [ Upstream commit c23734487fb44ee16c1b007ba72d793c085e4ec4 ] I have observed failures to boot on Orange Pi 3, because this driver determined that my SoC is from the normal bin, but my SoC only works reliably with the OPP values for the slowest bin. By querying H6 owners, it was found that e-fuse values found in the wild are in the range of 1-3, value of 7 was not reported, yet. From this and from unused defines in BSP code, it can be assumed that meaning of efuse values on H6 actually is: - 1 = slowest bin - 2 = normal bin - 3 = fastest bin Vendor code actually treats 0 and 2 as invalid efuse values, but later treats all invalid values as a normal bin. This looks like a mistake in bin detection code, that was plastered over by a hack in cpufreq code, so let's not repeat it here. It probably only works because there are no SoCs in the wild with efuse value of 0, and fast bin SoCs are made to use normal bin OPP tables, which is also safe. Let's play it safe and interpret 0 as the slowest bin, but fix detection of other bins to match this research. More research will be done before actual OPP tables are merged. Fixes: f328584f7bff ("cpufreq: Add sun50i nvmem based CPU scaling driver") Acked-by: Maxime Ripard Signed-off-by: Ondrej Jirman Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin commit 8f3d1245a1046130ab7ecfa6b52baac1fe4b7734 Author: Manjunath Patil Date: Sat Oct 5 08:20:03 2019 -0700 ixgbe: protect TX timestamping from API misuse [ Upstream commit 07066d9dc3d2326fbad8f7b0cb0120cff7b7dedb ] HW timestamping can only be requested for a packet if the NIC is first setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the ixgbe driver still allowed TX packets to request HW timestamping. In this situation, we see 'clearing Tx Timestamp hang' noise in the log. Fix this by checking that the NIC is configured for HW TX timestamping before accepting a HW TX timestamping request. Similar-to: commit 26bd4e2db06b ("igb: protect TX timestamping from API misuse") commit 0a6f2f05a2f5 ("igb: Fix a test with HWTSTAMP_TX_ON") Signed-off-by: Manjunath Patil Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit d8073aa69d61592892100869fe9fbb951b5bf87f Author: Ben Dooks (Codethink) Date: Tue Oct 22 16:11:54 2019 +0100 pinctrl: amd: fix __iomem annotation in amd_gpio_irq_handler() [ Upstream commit 10ff58aa3c2e2a093b6ad615a7e3d8bb0dc613e5 ] The regs pointer in amd_gpio_irq_handler() should have __iomem on it, so add that to fix the following sparse warnings: drivers/pinctrl/pinctrl-amd.c:555:14: warning: incorrect type in assignment (different address spaces) drivers/pinctrl/pinctrl-amd.c:555:14: expected unsigned int [usertype] *regs drivers/pinctrl/pinctrl-amd.c:555:14: got void [noderef] *base drivers/pinctrl/pinctrl-amd.c:563:34: warning: incorrect type in argument 1 (different address spaces) drivers/pinctrl/pinctrl-amd.c:563:34: expected void const volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:563:34: got unsigned int [usertype] * drivers/pinctrl/pinctrl-amd.c:580:34: warning: incorrect type in argument 1 (different address spaces) drivers/pinctrl/pinctrl-amd.c:580:34: expected void const volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:580:34: got unsigned int [usertype] * drivers/pinctrl/pinctrl-amd.c:587:25: warning: incorrect type in argument 2 (different address spaces) drivers/pinctrl/pinctrl-amd.c:587:25: expected void volatile [noderef] *addr drivers/pinctrl/pinctrl-amd.c:587:25: got unsigned int [usertype] * Signed-off-by: Ben Dooks (Codethink) Link: https://lore.kernel.org/r/20191022151154.5986-1-ben.dooks@codethink.co.uk Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 75c41a267b9977e0075052c39134b89a195be963 Author: Rajendra Nayak Date: Mon Oct 21 19:45:07 2019 +0530 pinctrl: qcom: sc7180: Add missing tile info in SDC_QDSD_PINGROUP/UFS_RESET [ Upstream commit 81898a44f288607cb3b11a42aed6efb646891c19 ] The SDC_QDSD_PINGROUP/UFS_RESET macros are missing the .tile info needed to calculate the right register offsets. Adding them here and also adjusting the offsets accordingly. Fixes: f2ae04c45b1a ("pinctrl: qcom: Add SC7180 pinctrl driver") Reported-by: Veerabhadrarao Badiganti Signed-off-by: Rajendra Nayak Link: https://lore.kernel.org/r/20191021141507.24066-1-rnayak@codeaurora.org Reviewed-by: Bjorn Andersson Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit d98020a3fddd027f154b7adc12c6c9f9aa4f0216 Author: Pierre-Louis Bossart Date: Fri Nov 1 12:30:39 2019 -0500 ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF dependency [ Upstream commit f9ad75468453b019b92c5296e6a04bf7c37f49e4 ] updated solution to the problem reported with randconfig: CONFIG_SND_SOC_SOF_IMX depends on CONFIG_SND_SOC_SOF, but is in turn referenced by the sof-of-dev driver. This creates a reverse dependency that manifests in a link error when CONFIG_SND_SOC_SOF_OF is built-in but CONFIG_SND_SOC_SOF_IMX=m: sound/soc/sof/sof-of-dev.o:(.data+0x118): undefined reference to `sof_imx8_ops' use def_trisate to propagate the right settings without select. Fixes: f4df4e4042b0 ("ASoC: SOF: imx8: Fix COMPILE_TEST error") Fixes: 202acc565a1f ("ASoC: SOF: imx: Add i.MX8 HW support") Suggested-by: Arnd Bergmann Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191101173045.27099-6-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b257b8a12828c5172ca8c10a3756c6fc7e2a14a2 Author: Chuhong Yuan Date: Fri Nov 1 20:17:45 2019 +0800 spi: sifive: disable clk when probe fails and remove [ Upstream commit a725272bda77e61c1b4de85c7b0c875b2ea639b6 ] The driver forgets to disable and unprepare clk when probe fails and remove. Add the calls to fix the problem. Signed-off-by: Chuhong Yuan Reviewed-by: Palmer Dabbelt Link: https://lore.kernel.org/r/20191101121745.13413-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 07d0760b43f116c08a2663cbe3dc6ec92acd0b7a Author: Takashi Iwai Date: Mon Nov 4 11:11:15 2019 +0100 ALSA: pcm: Fix missing check of the new non-cached buffer type [ Upstream commit 6111fd2370eecae9f11bfdc08ba097e0b51fcfd3 ] The check for the mmap support via hw_support_mmap() function misses the case where the device is with SNDRV_DMA_TYPE_DEV_UC, which should have been treated equally as SNDRV_DMA_TYPE_DEV. Let's fix it. Note that this bug doesn't hit any practical problem, because SNDRV_DMA_TYPE_DEV_UC is used only for x86-specific drivers (snd-hda-intel and snd-intel8x0) for the specific platforms that need the non-cached buffers. And, on such platforms, hw_support_mmap() already returns true in anyway. That's the reason I didn't put Cc-to-stable mark here. This is only for any theoretical future extension. Fixes: 425da159707b ("ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*") Fixes: 42e748a0b325 ("ALSA: memalloc: Add non-cached buffer type") Link: https://lore.kernel.org/r/20191104101115.27311-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ec48a3d82718e9b32d9284dcda09e87641d15a38 Author: Luiz Augusto von Dentz Date: Sun Nov 3 23:58:15 2019 +0200 Bluetooth: Fix advertising duplicated flags [ Upstream commit 6012b9346d8959194c239fd60a62dfec98d43048 ] Instances may have flags set as part of its data in which case the code should not attempt to add it again otherwise it can cause duplication: < HCI Command: LE Set Extended Advertising Data (0x08|0x0037) plen 35 Handle: 0x00 Operation: Complete extended advertising data (0x03) Fragment preference: Minimize fragmentation (0x01) Data length: 0x06 Flags: 0x04 BR/EDR Not Supported Flags: 0x06 LE General Discoverable Mode BR/EDR Not Supported Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Johan Hedberg Signed-off-by: Sasha Levin commit 8f2570572e0e52026d09bbbe18e81bf2985ca92d Author: Toke Høiland-Jørgensen Date: Sat Nov 2 12:09:37 2019 +0100 libbpf: Fix error handling in bpf_map__reuse_fd() [ Upstream commit d1b4574a4b86565325ef2e545eda8dfc9aa07c60 ] bpf_map__reuse_fd() was calling close() in the error path before returning an error value based on errno. However, close can change errno, so that can lead to potentially misleading error messages. Instead, explicitly store errno in the err variable before each goto. Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/157269297769.394725.12634985106772698611.stgit@toke.dk Signed-off-by: Sasha Levin commit 8679dce8c662e1c72230332812a283b23d34a9a7 Author: Alexandru Ardelean Date: Wed Oct 23 11:26:34 2019 +0300 iio: dln2-adc: fix iio_triggered_buffer_postenable() position [ Upstream commit a7bddfe2dfce1d8859422124abe1964e0ecd386e ] The iio_triggered_buffer_postenable() hook should be called first to attach the poll function. The iio_triggered_buffer_predisable() hook is called last (as is it should). This change moves iio_triggered_buffer_postenable() to be called first. It adds iio_triggered_buffer_predisable() on the error paths of the postenable hook. For the predisable hook, some code-paths have been changed to make sure that the iio_triggered_buffer_predisable() hook gets called in case there is an error before it. Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 86b2eb94b0fc535a62f67666bab8fc4cb81a886c Author: Takashi Sakamoto Date: Fri Nov 1 22:13:21 2019 +0900 ALSA: bebob: expand sleep just after breaking connections for protocol version 1 [ Upstream commit d3eabe939aee3ffd5b133766a932629a9746298c ] As long as I investigated, some devices with BeBoB protocol version 1 can be freezed during several hundreds milliseconds after breaking connections. When accessing during the freezed time, any transaction is corrupted. In the worst case, the device is going to reboot. I can see this issue in: * Roland FA-66 * M-Audio FireWire Solo This commit expands sleep just after breaking connections to avoid the freezed time as much as possible. I note that the freeze/reboot behaviour is similar to below models: * Focusrite Saffire Pro 10 I/O * Focusrite Saffire Pro 26 I/O The above models certainly reboot after breaking connections. Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e9cd798d6300a14e48ef46bbfa1b5bcf5d97c87c Author: Geert Uytterhoeven Date: Thu Oct 24 15:13:08 2019 +0200 pinctrl: sh-pfc: sh7734: Fix duplicate TCLK1_B [ Upstream commit 884caadad128efad8e00c1cdc3177bc8912ee8ec ] The definitions for bit field [19:18] of the Peripheral Function Select Register 3 were accidentally copied from bit field [20], leading to duplicates for the TCLK1_B function, and missing TCLK0, CAN_CLK_B, and ET0_ETXD4 functions. Fix this by adding the missing GPIO_FN_CAN_CLK_B and GPIO_FN_ET0_ETXD4 enum values, and correcting the functions. Reported-by: Ben Dooks Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20191024131308.16659-1-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 39a1c83595cb38cdc326fe0eeb3f218264ffcb99 Author: Vlad Buslov Date: Wed Sep 11 21:14:54 2019 +0300 net/mlx5e: Verify that rule has at least one fwd/drop action [ Upstream commit ae2741e2b6ce2bf1b656b1152c4ef147ff35b096 ] Currently, mlx5 tc layer doesn't verify that rule has at least one forward or drop action which leads to following firmware syndrome when user tries to offload such action: [ 1824.860501] mlx5_core 0000:81:00.0: mlx5_cmd_check:753:(pid 29458): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x144b7a) Add check at the end of parse_tc_fdb_actions() that verifies that resulting attribute has action fwd or drop flag set. Signed-off-by: Vlad Buslov Reviewed-by: Paul Blakey Reviewed-by: Roi Dayan Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 1fca505614091c9a0b95968cd7f8485732f53bfc Author: Darrick J. Wong Date: Wed Oct 30 20:29:48 2019 -0700 loop: fix no-unmap write-zeroes request behavior [ Upstream commit efcfec579f6139528c9e6925eca2bc4a36da65c6 ] Currently, if the loop device receives a WRITE_ZEROES request, it asks the underlying filesystem to punch out the range. This behavior is correct if unmapping is allowed. However, a NOUNMAP request means that the caller doesn't want us to free the storage backing the range, so punching out the range is incorrect behavior. To satisfy a NOUNMAP | WRITE_ZEROES request, loop should ask the underlying filesystem to FALLOC_FL_ZERO_RANGE, which is (according to the fallocate documentation) required to ensure that the entire range is backed by real storage, which suffices for our purposes. Fixes: 19372e2769179dd ("loop: implement REQ_OP_WRITE_ZEROES") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f545fda258606e8a864896eb3654e3b52ca9bb54 Author: John Garry Date: Wed Oct 16 18:19:52 2019 +0800 libata: Ensure ata_port probe has completed before detach [ Upstream commit 130f4caf145c3562108b245a576db30b916199d2 ] With CONFIG_DEBUG_TEST_DRIVER_REMOVE set, we may find the following WARN: [ 23.452574] ------------[ cut here ]------------ [ 23.457190] WARNING: CPU: 59 PID: 1 at drivers/ata/libata-core.c:6676 ata_host_detach+0x15c/0x168 [ 23.466047] Modules linked in: [ 23.469092] CPU: 59 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00010-g5b83fd27752b-dirty #296 [ 23.477776] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019 [ 23.486286] pstate: a0c00009 (NzCv daif +PAN +UAO) [ 23.491065] pc : ata_host_detach+0x15c/0x168 [ 23.495322] lr : ata_host_detach+0x88/0x168 [ 23.499491] sp : ffff800011cabb50 [ 23.502792] x29: ffff800011cabb50 x28: 0000000000000007 [ 23.508091] x27: ffff80001137f068 x26: ffff8000112c0c28 [ 23.513390] x25: 0000000000003848 x24: ffff0023ea185300 [ 23.518689] x23: 0000000000000001 x22: 00000000000014c0 [ 23.523987] x21: 0000000000013740 x20: ffff0023bdc20000 [ 23.529286] x19: 0000000000000000 x18: 0000000000000004 [ 23.534584] x17: 0000000000000001 x16: 00000000000000f0 [ 23.539883] x15: ffff0023eac13790 x14: ffff0023eb76c408 [ 23.545181] x13: 0000000000000000 x12: ffff0023eac13790 [ 23.550480] x11: ffff0023eb76c228 x10: 0000000000000000 [ 23.555779] x9 : ffff0023eac13798 x8 : 0000000040000000 [ 23.561077] x7 : 0000000000000002 x6 : 0000000000000001 [ 23.566376] x5 : 0000000000000002 x4 : 0000000000000000 [ 23.571674] x3 : ffff0023bf08a0bc x2 : 0000000000000000 [ 23.576972] x1 : 3099674201f72700 x0 : 0000000000400284 [ 23.582272] Call trace: [ 23.584706] ata_host_detach+0x15c/0x168 [ 23.588616] ata_pci_remove_one+0x10/0x18 [ 23.592615] ahci_remove_one+0x20/0x40 [ 23.596356] pci_device_remove+0x3c/0xe0 [ 23.600267] really_probe+0xdc/0x3e0 [ 23.603830] driver_probe_device+0x58/0x100 [ 23.608000] device_driver_attach+0x6c/0x90 [ 23.612169] __driver_attach+0x84/0xc8 [ 23.615908] bus_for_each_dev+0x74/0xc8 [ 23.619730] driver_attach+0x20/0x28 [ 23.623292] bus_add_driver+0x148/0x1f0 [ 23.627115] driver_register+0x60/0x110 [ 23.630938] __pci_register_driver+0x40/0x48 [ 23.635199] ahci_pci_driver_init+0x20/0x28 [ 23.639372] do_one_initcall+0x5c/0x1b0 [ 23.643199] kernel_init_freeable+0x1a4/0x24c [ 23.647546] kernel_init+0x10/0x108 [ 23.651023] ret_from_fork+0x10/0x18 [ 23.654590] ---[ end trace 634a14b675b71c13 ]--- With KASAN also enabled, we may also get many use-after-free reports. The issue is that when CONFIG_DEBUG_TEST_DRIVER_REMOVE is set, we may attempt to detach the ata_port before it has been probed. This is because the ata_ports are async probed, meaning that there is no guarantee that the ata_port has probed prior to detach. When the ata_port does probe in this scenario, we get all sorts of issues as the detach may have already happened. Fix by ensuring synchronisation with async_synchronize_full(). We could alternatively use the cookie returned from the ata_port probe async_schedule() call, but that means managing the cookie, so more complicated. Signed-off-by: John Garry Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 4a8a3a255e1ef80312c3e9d3c0bca91b6393d956 Author: Yunsheng Lin Date: Thu Oct 31 19:23:17 2019 +0800 net: hns3: add struct netdev_queue debug info for TX timeout [ Upstream commit 647522a5ef6401dcdb8ec417421e43fb21910167 ] When there is a TX timeout, we can tell if the driver or stack has stopped the queue by looking at state field, and when has the last packet transmited by looking at trans_start field. So this patch prints these two field in the hns3_get_tx_timeo_queue_info(). Signed-off-by: Yunsheng Lin Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0eba140ccdb7a4c0f8e93cc012bf1d2e20018ff6 Author: Gerald Schaefer Date: Tue Oct 22 14:38:08 2019 +0200 s390/mm: add mm_pxd_folded() checks to pxd_free() [ Upstream commit 2416cefc504ba8ae9b17e3e6b40afc72708f96be ] Unlike pxd_free_tlb(), the pxd_free() functions do not check for folded page tables. This is not an issue so far, as those functions will actually never be called, since no code will reach them when page tables are folded. In order to avoid future issues, and to make the s390 code more similar to other architectures, add mm_pxd_folded() checks, similar to how it is done in pxd_free_tlb(). This was found by testing a patch from from Anshuman Khandual, which is currently discussed on LKML ("mm/debug: Add tests validating architecture page table helpers"). Signed-off-by: Gerald Schaefer Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit ca635fee8091b191ebfad648eac3895f5aca7e50 Author: Ilya Leoshkevich Date: Wed Oct 30 14:20:32 2019 +0100 s390: add error handling to perf_callchain_kernel [ Upstream commit effb83ccc83a97dbbe5214f4c443522719f05f3a ] perf_callchain_kernel stops neither when it encounters a garbage address, nor when it runs out of space. Fix both issues using x86 version as an inspiration. Signed-off-by: Ilya Leoshkevich Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 647c625d5695c6a5a61c905d206a3c875763997c Author: Heiko Carstens Date: Tue Oct 29 14:09:47 2019 +0100 s390/time: ensure get_clock_monotonic() returns monotonic values [ Upstream commit 011620688a71f2f1fe9901dbc2479a7c01053196 ] The current implementation of get_clock_monotonic() leaves it up to the caller to call the function with preemption disabled. The only core kernel caller (sched_clock) however does not disable preemption. In order to make sure that all callers of this function see monotonic values handle disabling preemption within the function itself. Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 8d42643c6c0efc6137ae09e5e4eda1e13bce7410 Author: Stephan Gerhold Date: Tue Oct 8 13:52:08 2019 +0200 phy: qcom-usb-hs: Fix extcon double register after power cycle [ Upstream commit 64f86b9978449ff05bfa6c64b4c5439e21e9c80b ] Commit f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API") switched from extcon_register_notifier() to the resource-managed API, i.e. devm_extcon_register_notifier(). This is problematic in this case, because the extcon notifier is dynamically registered/unregistered whenever the PHY is powered on/off. The resource-managed API does not unregister the notifier until the driver is removed, so as soon as the PHY is power cycled, attempting to register the notifier again results in: double register detected WARNING: CPU: 1 PID: 182 at kernel/notifier.c:26 notifier_chain_register+0x74/0xa0 Call trace: ... extcon_register_notifier+0x74/0xb8 devm_extcon_register_notifier+0x54/0xb8 qcom_usb_hs_phy_power_on+0x1fc/0x208 ... ... and USB stops working after plugging the cable out and in another time. The easiest way to fix this is to make a partial revert of commit f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API") and avoid using the resource-managed API in this case. Fixes: f0b5c2c96370 ("phy: qcom-usb-hs: Replace the extcon API") Signed-off-by: Stephan Gerhold Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit f915c462bb7fdf9a21fc02b3098079e22deef85f Author: Biju Das Date: Wed Oct 9 17:12:49 2019 +0100 phy: renesas: phy-rcar-gen2: Fix the array off by one warning [ Upstream commit c9baab38fe0e28762d0d67611cbe2aef0fb3fc72 ] Fix the below smatch warning by adding variable check rather than the hardcoded value. warn: array off by one? 'data->select_value[channel_num]' Reported-by: Dan Carpenter Signed-off-by: Biju Das Reviewed-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Reviewed-by: Ulrich Hecht Reviewed-by: Yoshihiro Shimoda Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit de21343511493a7562848b06df8cb21b9112342c Author: Mao Wenan Date: Sat Oct 26 10:21:39 2019 +0800 net: dsa: LAN9303: select REGMAP when LAN9303 enable [ Upstream commit b6989d248a2d13f02895bae1a9321b3bbccc0283 ] When NET_DSA_SMSC_LAN9303=y and NET_DSA_SMSC_LAN9303_MDIO=y, below errors can be seen: drivers/net/dsa/lan9303_mdio.c:87:23: error: REGMAP_ENDIAN_LITTLE undeclared here (not in a function) .reg_format_endian = REGMAP_ENDIAN_LITTLE, drivers/net/dsa/lan9303_mdio.c:93:3: error: const struct regmap_config has no member named reg_read .reg_read = lan9303_mdio_read, It should select REGMAP in config NET_DSA_SMSC_LAN9303. Fixes: dc7005831523 ("net: dsa: LAN9303: add MDIO managed mode support") Signed-off-by: Mao Wenan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7c810f4d0c600d0c47d20016c4355dd5989ccd40 Author: Thierry Reding Date: Mon Oct 28 13:37:12 2019 +0100 gpu: host1x: Allocate gather copy for host1x [ Upstream commit b78e70c04c149299bd210759d7c7af7c86b89ca8 ] Currently when the gather buffers are copied, they are copied to a buffer that is allocated for the host1x client that wants to execute the command streams in the buffers. However, the gather buffers will be read by the host1x device, which causes SMMU faults if the DMA API is backed by an IOMMU. Fix this by allocating the gather buffer copy for the host1x device, which makes sure that it will be mapped into the host1x's IOVA space if the DMA API is backed by an IOMMU. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 3a57f8d90185d7d04dfd96da357e87c73cbdc165 Author: Adham Abozaeid Date: Mon Oct 28 18:40:26 2019 +0000 staging: wilc1000: check if device is initialzied before changing vif [ Upstream commit 6df6f3849bb8f317bf2d52711aacea4292237ede ] When killing hostapd, the interface is closed which deinitializes the device, then change virtual interface is called. This change checks if the device is initialized before sending the interface change command to the device Signed-off-by: Adham Abozaeid Link: https://lore.kernel.org/r/20191028184019.31194-1-adham.abozaeid@microchip.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1e457b63c763078bbaf2facb99cec11a83502b53 Author: Bart Van Assche Date: Fri Oct 25 15:58:30 2019 -0700 RDMA/core: Set DMA parameters correctly [ Upstream commit c9121262d57b8a3be4f08073546436ba0128ca6a ] The dma_set_max_seg_size() call in setup_dma_device() does not have any effect since device->dev.dma_parms is NULL. Fix this by initializing device->dev.dma_parms first. Link: https://lore.kernel.org/r/20191025225830.257535-5-bvanassche@acm.org Fixes: d10bcf947a3e ("RDMA/umem: Combine contiguous PAGE_SIZE regions in SGEs") Signed-off-by: Bart Van Assche Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 0d1065b54cedd7ecb0d04048ec9155e8077eea50 Author: Michal Kalderon Date: Sun Oct 27 22:04:48 2019 +0200 RDMA/qedr: Fix srqs xarray initialization [ Upstream commit 73ab512f720298aabe23b34110e3f6a8545b0ba5 ] There was a missing initialization for the srqs xarray. SRQs xarray can also be called from irq context when searching for an element and uses the xa_XXX_irq apis, therefore should be initialized with IRQ flags. Fixes: 9fd15987ed27 ("qedr: Convert srqidr to XArray") Link: https://lore.kernel.org/r/20191027200451.28187-2-michal.kalderon@marvell.com Signed-off-by: Ariel Elior Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 415f3ae6912d0d25ee6257e8ffc5a61293b61e9c Author: Colin Ian King Date: Thu Oct 24 14:10:34 2019 +0100 RDMA/hns: Fix memory leak on 'context' on error return path [ Upstream commit 994195e1537074f56df216a9309f6e366cb35b67 ] Currently, the error return path when the call to function dev->dfx->query_cqc_info fails will leak object 'context'. Fix this by making the error return path via 'err' return return codes rather than -EMSGSIZE, set ret appropriately for all error return paths and for the memory leak now return via 'err' rather than just returning without freeing context. Link: https://lore.kernel.org/r/20191024131034.19989-1-colin.king@canonical.com Addresses-Coverity: ("Resource leak") Fixes: e1c9a0dc2939 ("RDMA/hns: Dump detailed driver-specific CQ") Signed-off-by: Colin Ian King Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 24b758dcd569b00c2c9adfcb0da19a9af124342e Author: Michal Kalderon Date: Sun Oct 27 22:04:51 2019 +0200 RDMA/qedr: Fix memory leak in user qp and mr [ Upstream commit 24e412c1e00ebfe73619e6b88cbc26c2c7d41b85 ] User QPs pbl's weren't freed properly. MR pbls weren't freed properly. Fixes: e0290cce6ac0 ("qedr: Add support for memory registeration verbs") Link: https://lore.kernel.org/r/20191027200451.28187-5-michal.kalderon@marvell.com Signed-off-by: Ariel Elior Signed-off-by: Michal Kalderon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 598b8394790ba21bbe573caa799fb421aa941d33 Author: Hans de Goede Date: Sat Oct 26 22:24:34 2019 +0200 ACPI: button: Add DMI quirk for Medion Akoya E2215T [ Upstream commit 932e1ba486117de2fcea3df27ad8218ad6c11470 ] The Medion Akoya E2215T's ACPI _LID implementation is quite broken: 1. For notifications it uses an ActiveLow Edge GpioInt, rather then an ActiveBoth one, meaning that the device is only notified when the lid is closed, not when it is opened. 2. Matching with this its _LID method simply always returns 0 (closed) In order for the Linux LID code to work properly with this implementation, the lid_init_state selection needs to be set to ACPI_BUTTON_LID_INIT_OPEN. This commit adds a DMI quirk for this. Reviewed-by: Andy Shevchenko Signed-off-by: Hans de Goede Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin commit 60e315db411a808f4524accbe4e2c956ed3ac5bb Author: Lingling Xu Date: Mon Oct 28 18:10:30 2019 +0800 spi: sprd: adi: Add missing lock protection when rebooting [ Upstream commit 91ea1d70607e374b014b4b9bea771ce661f9f64b ] When rebooting the system, we should lock the watchdog after configuration to make sure the watchdog can reboot the system successfully. Signed-off-by: Lingling Xu Signed-off-by: Baolin Wang Link: https://lore.kernel.org/r/7b04711127434555e3a1a86bc6be99860cd86668.1572257085.git.baolin.wang@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 39303579ebc44edbb872334595e6979b4cc16e28 Author: Peter Zijlstra Date: Mon Oct 21 15:11:49 2019 +0200 ubsan, x86: Annotate and allow __ubsan_handle_shift_out_of_bounds() in uaccess regions [ Upstream commit 9a50dcaf0416a43e1fe411dc61a99c8333c90119 ] The new check_zeroed_user() function uses variable shifts inside of a user_access_begin()/user_access_end() section and that results in GCC emitting __ubsan_handle_shift_out_of_bounds() calls, even though through value range analysis it would be able to see that the UB in question is impossible. Annotate and whitelist this UBSAN function; continued use of user_access_begin()/user_access_end() will undoubtedly result in further uses of function. Reported-by: Randy Dunlap Tested-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Acked-by: Randy Dunlap Acked-by: Christian Brauner Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Stephen Rothwell Cc: Thomas Gleixner Cc: cyphar@cyphar.com Cc: keescook@chromium.org Cc: linux@rasmusvillemoes.dk Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper") Link: https://lkml.kernel.org/r/20191021131149.GA19358@hirez.programming.kicks-ass.net Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 3ee93c6fb7bd85f36f68273bd8ff5c61c6465c03 Author: Dmitry Osipenko Date: Fri Oct 25 03:22:39 2019 +0300 regulator: core: Release coupled_rdevs on regulator_init_coupling() error [ Upstream commit 26c2c997aa1a6c5522f6619910ba025e53e69763 ] This patch fixes memory leak which should happen if regulator's coupling fails to initialize. Fixes: d8ca7d184b33 ("regulator: core: Introduce API for regulators coupling customization") Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20191025002240.25288-1-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e0d2d181ff6327ec7f787344c113e2356d1dabcb Author: Thierry Reding Date: Wed Jul 24 17:06:17 2019 +0200 drm/tegra: sor: Use correct SOR index on Tegra210 [ Upstream commit 24e64f86da40e68c5f58af08796110f147b12193 ] The device tree bindings for the Tegra210 SOR don't require the controller instance to be defined, since the instance can be derived from the compatible string. The index is never used on Tegra210, so we got away with it not getting set. However, subsequent patches will change that, so make sure the proper index is used. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit a1951630d6103223596c42d2ac17c0437b9434b1 Author: Grygorii Strashko Date: Wed Oct 23 17:48:45 2019 +0300 net: phy: dp83867: enable robust auto-mdix [ Upstream commit 5a7f08c2abb0efc9d17aff2fc75d6d3b85e622e4 ] The link detection timeouts can be observed (or link might not be detected at all) when dp83867 PHY is configured in manual mode (speed/duplex). CFG3[9] Robust Auto-MDIX option allows to significantly improve link detection in case dp83867 is configured in manual mode and reduce link detection time. As per DM: "If link partners are configured to operational modes that are not supported by normal Auto MDI/MDIX mode (like Auto-Neg versus Force 100Base-TX or Force 100Base-TX versus Force 100Base-TX), this Robust Auto MDI/MDIX mode allows MDI/MDIX resolution and prevents deadlock." Hence, enable this option by default as there are no known reasons not to do so. Signed-off-by: Grygorii Strashko Reviewed-by: Andrew Lunn Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8438388755d132a93964015e7f34f6f462c411a5 Author: Jaroslaw Gawin Date: Fri Sep 20 02:17:17 2019 -0700 i40e: Wrong 'Advertised FEC modes' after set FEC to AUTO [ Upstream commit e42b7e9cefca9dd008cbafffca97285cf264f72d ] Fix display of parameters "Configured FEC encodings:" and "Advertised FEC modes:" in ethtool. Implemented by setting proper FEC bits in “advertising” bitmask of link_modes struct and “fec” bitmask in ethtool_fecparam struct. Without this patch wrong FEC settings can be shown. Signed-off-by: Jaroslaw Gawin Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 674ad72c47935980dada8e57fcecd50ebbe06b47 Author: Anthony Koo Date: Fri Sep 27 10:52:15 2019 -0400 drm/amd/display: correctly populate dpp refclk in fpga [ Upstream commit 952f6c4b5d72d40f93f3deb61239290b357d434e ] [Why] In diags environment we are not programming the DPP DTO correctly. [How] Populate the dpp refclk in dccg so it can be used to correctly program DPP DTO. Signed-off-by: Anthony Koo Reviewed-by: Tony Cheng Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 00b0f7d9d4a317b0bee32ceb26d68148b3fd08f2 Author: Nicholas Nunley Date: Fri Sep 20 02:17:21 2019 -0700 i40e: initialize ITRN registers with correct values [ Upstream commit 998e5166e604fd37afe94352f7b8c2d816b11049 ] Since commit 92418fb14750 ("i40e/i40evf: Use usec value instead of reg value for ITR defines") the driver tracks the interrupt throttling intervals in single usec units, although the actual ITRN/ITR0 registers are programmed in 2 usec units. Most register programming flows in the driver correctly handle the conversion, although it is currently not applied when the registers are initialized to their default values. Most of the time this doesn't present a problem since the default values are usually immediately overwritten through the standard adaptive throttling mechanism, or updated manually by the user, but if adaptive throttling is disabled and the interval values are left alone then the incorrect value will persist. Since the intended default interval of 50 usecs (vs. 100 usecs as programmed) performs better for most traffic workloads, this can lead to performance regressions. This patch adds the correct conversion when writing the initial values to the ITRN registers. Signed-off-by: Nicholas Nunley Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 12d29ebf6baa876c4de5ebc0c23ddec0787482b0 Author: Zhan liu Date: Thu Oct 17 14:55:56 2019 -0400 drm/amd/display: setting the DIG_MODE to the correct value. [ Upstream commit 967a3b85bac91c55eff740e61bf270c2732f48b2 ] [Why] This patch is for fixing Navi14 HDMI display pink screen issue. [How] Call stream->link->link_enc->funcs->setup twice. This is setting the DIG_MODE to the correct value after having been overridden by the call to transmitter control. Signed-off-by: Zhan Liu Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ed3b3838130d702d266cc0e72564c9cf686d329f Author: Yunfeng Ye Date: Mon Oct 21 19:31:21 2019 +0800 arm64: psci: Reduce the waiting time for cpu_psci_cpu_kill() [ Upstream commit bfcef4ab1d7ee8921bc322109b1692036cc6cbe0 ] In cases like suspend-to-disk and suspend-to-ram, a large number of CPU cores need to be shut down. At present, the CPU hotplug operation is serialised, and the CPU cores can only be shut down one by one. In this process, if PSCI affinity_info() does not return LEVEL_OFF quickly, cpu_psci_cpu_kill() needs to wait for 10ms. If hundreds of CPU cores need to be shut down, it will take a long time. Normally, there is no need to wait 10ms in cpu_psci_cpu_kill(). So change the wait interval from 10 ms to max 1 ms and use usleep_range() instead of msleep() for more accurate timer. In addition, reducing the time interval will increase the messages output, so remove the "Retry ..." message, instead, track time and output to the the sucessful message. Signed-off-by: Yunfeng Ye Reviewed-by: Sudeep Holla Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 36b4080a3fc0b35693a2cbfb156de7c6e2c35fde Author: Yazen Ghannam Date: Tue Oct 22 20:35:14 2019 +0000 EDAC/amd64: Set grain per DIMM [ Upstream commit 466503d6b1b33be46ab87c6090f0ade6c6011cbc ] The following commit introduced a warning on error reports without a non-zero grain value. 3724ace582d9 ("EDAC/mc: Fix grain_bits calculation") The amd64_edac_mod module does not provide a value, so the warning will be given on the first reported memory error. Set the grain per DIMM to cacheline size (64 bytes). This is the current recommendation. Fixes: 3724ace582d9 ("EDAC/mc: Fix grain_bits calculation") Signed-off-by: Yazen Ghannam Signed-off-by: Borislav Petkov Cc: "linux-edac@vger.kernel.org" Cc: James Morse Cc: Mauro Carvalho Chehab Cc: Robert Richter Cc: Tony Luck Link: https://lkml.kernel.org/r/20191022203448.13962-7-Yazen.Ghannam@amd.com Signed-off-by: Sasha Levin commit 5a90861ed65672371bf04d5453a1faeaacbefef5 Author: Steven Price Date: Fri Oct 25 11:51:56 2019 +0100 drm: Don't free jobs in wait_event_interruptible() [ Upstream commit 588b9828f0744ca13555c4a35cd0251ac8ad8ad2 ] drm_sched_cleanup_jobs() attempts to free finished jobs, however because it is called as the condition of wait_event_interruptible() it must not sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep. Instead let's rename drm_sched_cleanup_jobs() to drm_sched_get_cleanup_job() and simply return a job for processing if there is one. The caller can then call the free_job() callback outside the wait_event_interruptible() where sleeping is possible before re-checking and returning to sleep if necessary. Tested-by: Christian Gmeiner Fixes: 5918045c4ed4 ("drm/scheduler: rework job destruction") Signed-off-by: Steven Price Reviewed-by: Christian König Signed-off-by: Christian König Link: https://patchwork.freedesktop.org/patch/337652/ Signed-off-by: Sasha Levin commit 735f82e9f08e54adccad92e90ab95952b717208e Author: Guoqing Jiang Date: Thu Sep 26 13:53:50 2019 +0200 md/bitmap: avoid race window between md_bitmap_resize and bitmap_file_clear_bit [ Upstream commit fadcbd2901a0f7c8721f3bdb69eac95c272dc8ed ] We need to move "spin_lock_irq(&bitmap->counts.lock)" before unmap previous storage, otherwise panic like belows could happen as follows. [ 902.353802] sdl: detected capacity change from 1077936128 to 3221225472 [ 902.616948] general protection fault: 0000 [#1] SMP [snip] [ 902.618588] CPU: 12 PID: 33698 Comm: md0_raid1 Tainted: G O 4.14.144-1-pserver #4.14.144-1.1~deb10 [ 902.618870] Hardware name: Supermicro SBA-7142G-T4/BHQGE, BIOS 3.00 10/24/2012 [ 902.619120] task: ffff9ae1860fc600 task.stack: ffffb52e4c704000 [ 902.619301] RIP: 0010:bitmap_file_clear_bit+0x90/0xd0 [md_mod] [ 902.619464] RSP: 0018:ffffb52e4c707d28 EFLAGS: 00010087 [ 902.619626] RAX: ffe8008b0d061000 RBX: ffff9ad078c87300 RCX: 0000000000000000 [ 902.619792] RDX: ffff9ad986341868 RSI: 0000000000000803 RDI: ffff9ad078c87300 [ 902.619986] RBP: ffff9ad0ed7a8000 R08: 0000000000000000 R09: 0000000000000000 [ 902.620154] R10: ffffb52e4c707ec0 R11: ffff9ad987d1ed44 R12: ffff9ad0ed7a8360 [ 902.620320] R13: 0000000000000003 R14: 0000000000060000 R15: 0000000000000800 [ 902.620487] FS: 0000000000000000(0000) GS:ffff9ad987d00000(0000) knlGS:0000000000000000 [ 902.620738] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 902.620901] CR2: 000055ff12aecec0 CR3: 0000001005207000 CR4: 00000000000406e0 [ 902.621068] Call Trace: [ 902.621256] bitmap_daemon_work+0x2dd/0x360 [md_mod] [ 902.621429] ? find_pers+0x70/0x70 [md_mod] [ 902.621597] md_check_recovery+0x51/0x540 [md_mod] [ 902.621762] raid1d+0x5c/0xeb0 [raid1] [ 902.621939] ? try_to_del_timer_sync+0x4d/0x80 [ 902.622102] ? del_timer_sync+0x35/0x40 [ 902.622265] ? schedule_timeout+0x177/0x360 [ 902.622453] ? call_timer_fn+0x130/0x130 [ 902.622623] ? find_pers+0x70/0x70 [md_mod] [ 902.622794] ? md_thread+0x94/0x150 [md_mod] [ 902.622959] md_thread+0x94/0x150 [md_mod] [ 902.623121] ? wait_woken+0x80/0x80 [ 902.623280] kthread+0x119/0x130 [ 902.623437] ? kthread_create_on_node+0x60/0x60 [ 902.623600] ret_from_fork+0x22/0x40 [ 902.624225] RIP: bitmap_file_clear_bit+0x90/0xd0 [md_mod] RSP: ffffb52e4c707d28 Because mdadm was running on another cpu to do resize, so bitmap_resize was called to replace bitmap as below shows. PID: 38801 TASK: ffff9ad074a90e00 CPU: 0 COMMAND: "mdadm" [exception RIP: queued_spin_lock_slowpath+56] [snip] -- -- #5 [ffffb52e60f17c58] queued_spin_lock_slowpath at ffffffff9c0b27b8 #6 [ffffb52e60f17c58] bitmap_resize at ffffffffc0399877 [md_mod] #7 [ffffb52e60f17d30] raid1_resize at ffffffffc0285bf9 [raid1] #8 [ffffb52e60f17d50] update_size at ffffffffc038a31a [md_mod] #9 [ffffb52e60f17d70] md_ioctl at ffffffffc0395ca4 [md_mod] And the procedure to keep resize bitmap safe is allocate new storage space, then quiesce, copy bits, replace bitmap, and re-start. However the daemon (bitmap_daemon_work) could happen even the array is quiesced, which means when bitmap_file_clear_bit is triggered by raid1d, then it thinks it should be fine to access store->filemap since counts->lock is held, but resize could change the storage without the protection of the lock. Cc: Jack Wang Cc: NeilBrown Signed-off-by: Guoqing Jiang Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit b94aedcd8cd65d021e1dcccf39f9ee8cda8c7324 Author: Dan Carpenter Date: Thu Oct 17 12:18:32 2019 +0300 staging: wilc1000: potential corruption in wilc_parse_join_bss_param() [ Upstream commit d59dc92f1bccd5acde793aebdbb4f7121cf3f9af ] The "rates_len" value needs to be capped so that the memcpy() doesn't copy beyond the end of the array. Fixes: c5c77ba18ea6 ("staging: wilc1000: Add SDIO/SPI 802.11 driver") Signed-off-by: Dan Carpenter Reviewed-by: Adham Abozaeid Link: https://lore.kernel.org/r/20191017091832.GB31278@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 696b50bbf68df5afc0e6e7a3f2325a9bc61f811f Author: Yufen Yu Date: Wed Oct 16 16:00:03 2019 +0800 md: no longer compare spare disk superblock events in super_load [ Upstream commit 6a5cb53aaa4ef515ddeffa04ce18b771121127b4 ] We have a test case as follow: mdadm -CR /dev/md1 -l 1 -n 4 /dev/sd[a-d] \ --assume-clean --bitmap=internal mdadm -S /dev/md1 mdadm -A /dev/md1 /dev/sd[b-c] --run --force mdadm --zero /dev/sda mdadm /dev/md1 -a /dev/sda echo offline > /sys/block/sdc/device/state echo offline > /sys/block/sdb/device/state sleep 5 mdadm -S /dev/md1 echo running > /sys/block/sdb/device/state echo running > /sys/block/sdc/device/state mdadm -A /dev/md1 /dev/sd[a-c] --run --force When we readd /dev/sda to the array, it started to do recovery. After offline the other two disks in md1, the recovery have been interrupted and superblock update info cannot be written to the offline disks. While the spare disk (/dev/sda) can continue to update superblock info. After stopping the array and assemble it, we found the array run fail, with the follow kernel message: [ 172.986064] md: kicking non-fresh sdb from array! [ 173.004210] md: kicking non-fresh sdc from array! [ 173.022383] md/raid1:md1: active with 0 out of 4 mirrors [ 173.022406] md1: failed to create bitmap (-5) [ 173.023466] md: md1 stopped. Since both sdb and sdc have the value of 'sb->events' smaller than that in sda, they have been kicked from the array. However, the only remained disk sda is in 'spare' state before stop and it cannot be added to conf->mirrors[] array. In the end, raid array assemble and run fail. In fact, we can use the older disk sdb or sdc to assemble the array. That means we should not choose the 'spare' disk as the fresh disk in analyze_sbs(). To fix the problem, we do not compare superblock events when it is a spare disk, as same as validate_super. Signed-off-by: Yufen Yu Signed-off-by: Song Liu Signed-off-by: Sasha Levin commit 6c6a03baece97469b2d041ebbc1f27b40d294a2d Author: Sakari Ailus Date: Fri Oct 11 08:16:02 2019 -0300 media: smiapp: Register sensor after enabling runtime PM on the device [ Upstream commit 90c9e4a4dba9f4de331372e745fb1991c1faa598 ] Earlier it was possible that the parts of the driver that assumed runtime PM was enabled were being called before runtime PM was enabled in the driver's probe function. So enable runtime PM before registering the sub-device. Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b349a5897cf53955678e0bc7e099fc31fbebc821 Author: Jae Hyun Yoo Date: Thu Sep 26 19:27:43 2019 -0300 media: aspeed: clear garbage interrupts [ Upstream commit 65d270acb2d662c3346793663ac3a759eb4491b8 ] CAPTURE_COMPLETE and FRAME_COMPLETE interrupts come even when these are disabled in the VE_INTERRUPT_CTRL register and eventually this behavior causes disabling irq itself like below: [10055.108784] irq 23: nobody cared (try booting with the "irqpoll" option) [10055.115525] CPU: 0 PID: 331 Comm: swampd Tainted: G W 5.3.0-4fde000-dirty-d683e2e #1 [10055.124565] Hardware name: Generic DT based system [10055.129355] Backtrace: [10055.131854] [<80107d7c>] (dump_backtrace) from [<80107fb0>] (show_stack+0x20/0x24) [10055.139431] r7:00000017 r6:00000001 r5:00000000 r4:9d51dc00 [10055.145120] [<80107f90>] (show_stack) from [<8074bf50>] (dump_stack+0x20/0x28) [10055.152361] [<8074bf30>] (dump_stack) from [<80150ffc>] (__report_bad_irq+0x40/0xc0) [10055.160109] [<80150fbc>] (__report_bad_irq) from [<80150f2c>] (note_interrupt+0x23c/0x294) [10055.168374] r9:015b6e60 r8:00000000 r7:00000017 r6:00000001 r5:00000000 r4:9d51dc00 [10055.176136] [<80150cf0>] (note_interrupt) from [<8014df1c>] (handle_irq_event_percpu+0x88/0x98) [10055.184835] r10:7eff7910 r9:015b6e60 r8:00000000 r7:9d417600 r6:00000001 r5:00000002 [10055.192657] r4:9d51dc00 r3:00000000 [10055.196248] [<8014de94>] (handle_irq_event_percpu) from [<8014df64>] (handle_irq_event+0x38/0x4c) [10055.205113] r5:80b56d50 r4:9d51dc00 [10055.208697] [<8014df2c>] (handle_irq_event) from [<80151f1c>] (handle_level_irq+0xbc/0x12c) [10055.217037] r5:80b56d50 r4:9d51dc00 [10055.220623] [<80151e60>] (handle_level_irq) from [<8014d4b8>] (generic_handle_irq+0x30/0x44) [10055.229052] r5:80b56d50 r4:00000017 [10055.232648] [<8014d488>] (generic_handle_irq) from [<8014d524>] (__handle_domain_irq+0x58/0xb4) [10055.241356] [<8014d4cc>] (__handle_domain_irq) from [<801021e4>] (avic_handle_irq+0x68/0x70) [10055.249797] r9:015b6e60 r8:00c5387d r7:00c5387d r6:ffffffff r5:9dd33fb0 r4:9d402380 [10055.257539] [<8010217c>] (avic_handle_irq) from [<80101e34>] (__irq_usr+0x54/0x80) [10055.265105] Exception stack(0x9dd33fb0 to 0x9dd33ff8) [10055.270152] 3fa0: 015d0530 00000000 00000000 015d0538 [10055.278328] 3fc0: 015d0530 015b6e60 00000000 00000000 0052c5d0 015b6e60 7eff7910 7eff7918 [10055.286496] 3fe0: 76ce5614 7eff7908 0050e2f4 76a3a08c 20000010 ffffffff [10055.293104] r5:20000010 r4:76a3a08c [10055.296673] handlers: [10055.298967] [<79f218a5>] irq_default_primary_handler threaded [<1de88514>] aspeed_video_irq [10055.307344] Disabling IRQ #23 To fix this issue, this commit makes the interrupt handler clear these garbage interrupts. This driver enables and uses only COMP_COMPLETE interrupt instead for frame handling. Signed-off-by: Jae Hyun Yoo Reviewed-by: Eddie James Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b4605db4bab6e45df0002f8b4358bc983d5729bb Author: Chuhong Yuan Date: Tue Oct 15 10:59:15 2019 -0300 media: imx7-mipi-csis: Add a check for devm_regulator_get [ Upstream commit a0219deefe9ee5006a28d48522f76b217d198c51 ] devm_regulator_get may return an error but mipi_csis_phy_init misses a check for it. This may lead to problems when regulator_set_voltage uses the unchecked pointer. This patch adds a check for devm_regulator_get to avoid potential risk. Signed-off-by: Chuhong Yuan Reviewed-by: Rui Miguel Silva Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 1a8c277e8d95c0f3f8579f94e4f35a90251f0fb2 Author: Chuhong Yuan Date: Thu Oct 17 22:46:56 2019 -0300 media: st-mipid02: add a check for devm_gpiod_get_optional [ Upstream commit 61c03b631b74a38ab53753f3ee971a55886d4843 ] mipid02_probe misses a check for devm_gpiod_get_optional and may miss the failure. Add a check to fix the problem. Signed-off-by: Chuhong Yuan Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 57171e52b492dd517284b5c330b96528a89c3ccd Author: Benoit Parrot Date: Wed Oct 9 09:35:10 2019 -0300 media: ov5640: Make 2592x1944 mode only available at 15 fps [ Upstream commit 981e445454531c9d5ac5d3fa8c0f1bd55262d001 ] The sensor data sheet clearly state that 2592x1944 only works at 15 fps make sure we don't try to miss configure the pll out of acceptable range. Signed-off-by: Benoit Parrot Reviewed-by: Jacopo Mondi Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 60b4128cde2c917255db121e2d878a8258117f4f Author: Ricardo Ribalda Delgado Date: Mon Oct 7 10:28:51 2019 -0300 media: ad5820: Define entity function [ Upstream commit 801ef7c4919efba6b96b5aed1e72844ca69e26d3 ] Without this patch, media_device_register_entity throws a warning: dev_warn(mdev->dev, "Entity type for entity %s was not initialized!\n", entity->name); Signed-off-by: Ricardo Ribalda Delgado Acked-by: Pavel Machek Reviewed-by: Laurent Pinchart Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 08ba731d670a785481d5df6428a5d20fb267e692 Author: Janusz Krzysztofik Date: Sun Oct 13 09:50:45 2019 -0300 media: ov6650: Fix stored frame interval not in sync with hardware [ Upstream commit 57822068dd120386b98891cb151dc20107b63ba7 ] The driver stores a frame interval value supposed to be in line with hardware state in a device private structure. Since the driver initial submission, the respective field of the structure has never been initialised on device probe. Moreover, if updated from .s_frame_interval(), a new value is stored before it is applied on hardware. If an error occurs during device update, the stored value may no longer reflect hardware state and consecutive calls to .g_frame_interval() may return incorrect information. Assuming a failed update of the device means its actual state hasn't changed, update the frame interval field of the device private structure with a new value only after it is successfully applied on hardware so it always reflects actual hardware state to the extent possible. Also, initialise the field with hardware default frame interval on device probe. Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 5c786ed035269f530e92eac6e7e53f5d43c2e270 Author: Lyude Paul Date: Wed Jul 3 18:35:37 2019 -0400 drm/nouveau: Don't grab runtime PM refs for HPD IRQs [ Upstream commit 09e530657e1c982d3dbc5e4302bf9207950c3d0a ] In order for suspend/resume reprobing to work, we need to be able to perform sideband communications during suspend/resume, along with runtime PM suspend/resume. In order to do so, we also need to make sure that nouveau doesn't bother grabbing a runtime PM reference to do so, since otherwise we'll start deadlocking runtime PM again. Note that we weren't able to do this before, because of the DP MST helpers processing UP requests from topologies in the same context as drm_dp_mst_hpd_irq() which would have caused us to open ourselves up to receiving hotplug events and deadlocking with runtime suspend/resume. Now that those requests are handled asynchronously, this change should be completely safe. Cc: Juston Li Cc: Imre Deak Cc: Ville Syrjälä Cc: Harry Wentland Cc: Daniel Vetter Reviewed-by: Ben Skeggs Reviewed-by: Sean Paul Signed-off-by: Lyude Paul Link: https://patchwork.freedesktop.org/patch/msgid/20191022023641.8026-10-lyude@redhat.com Signed-off-by: Sasha Levin commit 1d1d6ea16da2fd36f27da36386ed7793c707fd29 Author: Jae Hyun Yoo Date: Fri Sep 13 15:11:05 2019 -0300 media: aspeed: set hsync and vsync polarities to normal before starting mode detection [ Upstream commit 5b3f3c41c5c791c1c22cd91655e7ef4b2a1dff7c ] Sometimes it detects a weird resolution such as 1024x287 when the actual resolution is 1024x768. To resolve such an issue, this commit adds clearing for hsync and vsync polarity register bits at the beginning of the first mode detection. This is recommended in the datasheet. Signed-off-by: Jae Hyun Yoo Reviewed-by: Eddie James Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit ce9071fa5a0984f97723b608030c020eb0ae4b1b Author: Paul Kocialkowski Date: Tue Oct 22 12:26:50 2019 -0300 media: cedrus: Fix undefined shift with a SHIFT_AND_MASK_BITS macro [ Upstream commit 06eff2150d4db991ca236f3d05a9dc0101475aea ] We need to shift and mask values at different occasions to fill up cedrus registers. This was done using macros that don't explicitly treat arguments as unsigned, leading to possibly undefined behavior. Introduce the SHIFT_AND_MASK_BITS macro and use it where possible. In cases where it doesn't apply as-is, explicitly cast to unsigned instead. This macro should be moved to include/linux/bits.h eventually. Signed-off-by: Paul Kocialkowski Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0f88da95b10a291ec972a6920210e63ff94947f8 Author: Thomas Gleixner Date: Thu Oct 17 12:19:01 2019 +0200 x86/ioapic: Prevent inconsistent state when moving an interrupt [ Upstream commit df4393424af3fbdcd5c404077176082a8ce459c4 ] There is an issue with threaded interrupts which are marked ONESHOT and using the fasteoi handler: if (IS_ONESHOT()) mask_irq(); .... cond_unmask_eoi_irq() chip->irq_eoi(); if (setaffinity_pending) { mask_ioapic(); ... move_affinity(); unmask_ioapic(); } So if setaffinity is pending the interrupt will be moved and then unconditionally unmasked at the ioapic level, which is wrong in two aspects: 1) It should be kept masked up to the point where the threaded handler finished. 2) The physical chip state and the software masked state are inconsistent Guard both the mask and the unmask with a check for the software masked state. If the line is marked masked then the ioapic line is also masked, so both mask_ioapic() and unmask_ioapic() can be skipped safely. Signed-off-by: Thomas Gleixner Cc: Andy Shevchenko Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sebastian Siewior Fixes: 3aa551c9b4c4 ("genirq: add threaded interrupt handler support") Link: https://lkml.kernel.org/r/20191017101938.321393687@linutronix.de Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit b642ced2cad496c32ae1f62b85fc395391190820 Author: Corey Minyard Date: Mon Oct 14 10:35:56 2019 -0500 ipmi: Don't allow device module unload when in use [ Upstream commit cbb79863fc3175ed5ac506465948b02a893a8235 ] If something has the IPMI driver open, don't allow the device module to be unloaded. Before it would unload and the user would get errors on use. This change is made on user request, and it makes it consistent with the I2C driver, which has the same behavior. It does change things a little bit with respect to kernel users. If the ACPI or IPMI watchdog (or any other kernel user) has created a user, then the device module cannot be unloaded. Before it could be unloaded, This does not affect hot-plug. If the device goes away (it's on something removable that is removed or is hot-removed via sysfs) then it still behaves as it did before. Reported-by: tony camuso Signed-off-by: Corey Minyard Tested-by: tony camuso Signed-off-by: Sasha Levin commit 630a6a913e3a48f4890f8b9d912cd8217af59f19 Author: Bernard Metzler Date: Fri Oct 4 14:53:56 2019 +0200 RDMA/siw: Fix SQ/RQ drain logic [ Upstream commit cf049bb31f7101d9672eaf97ade4fdd5171ddf26 ] Storage ULPs (e.g. iSER & NVMeOF) use ib_drain_qp() to drain QP/CQ. Current SIW's own drain routines do not properly wait until all SQ/RQ elements are completed and reaped from the CQ. This may cause touch after free issues. New logic relies on generic __ib_drain_sq()/__ib_drain_rq() posting a final work request, which SIW immediately flushes to CQ. Fixes: 303ae1cdfdf7 ("rdma/siw: application interface") Link: https://lore.kernel.org/r/20191004125356.20673-1-bmt@zurich.ibm.com Signed-off-by: Krishnamraju Eraparaju Signed-off-by: Bernard Metzler Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 9d8b296f8f22dc18db634f1cc4ac3eb579977fda Author: Chris Chiu Date: Wed Oct 16 09:54:08 2019 +0800 rtl8xxxu: fix RTL8723BU connection failure issue after warm reboot [ Upstream commit 0eeb91ade90ce06d2fa1e2fcb55e3316b64c203c ] The RTL8723BU has problems connecting to AP after each warm reboot. Sometimes it returns no scan result, and in most cases, it fails the authentication for unknown reason. However, it works totally fine after cold reboot. Compare the value of register SYS_CR and SYS_CLK_MAC_CLK_ENABLE for cold reboot and warm reboot, the registers imply that the MAC is already powered and thus some procedures are skipped during driver initialization. Double checked the vendor driver, it reads the SYS_CR and SYS_CLK_MAC_CLK_ENABLE also but doesn't skip any during initialization based on them. This commit only tells the RTL8723BU to do full initialization without checking MAC status. Signed-off-by: Chris Chiu Signed-off-by: Jes Sorensen Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 0e8be3f402e2b4ba341e95737df243bbbd606f89 Author: Kuninori Morimoto Date: Tue Oct 15 12:59:38 2019 +0900 ASoC: soc-pcm: fixup dpcm_prune_paths() loop continue [ Upstream commit bed646dc3f7bcec91178c278deaf969cce0700a8 ] dpcm_prune_paths() is checking widget at 2 parts. (A) is for CPU, (B) is for Codec. If we focus to (A) part, continue at (a) is for (1) loop. But, if we focus to (B) part, continue at (b) is for (2) loop, not for (1). This is bug. This patch fixup this issue. static int dpcm_prune_paths(...) { ... (1) for_each_dpcm_be(fe, stream, dpcm) { ... ^ widget = dai_get_widget(...); | (A) if (widget && widget_in_list(...)) | (a) continue; v ^ (2) for_each_rtd_codec_dai(...) { | widget = dai_get_widget(...); (B) | if (widget && widget_in_list(...)) v (b) continue; } ... Fixes: 2e5894d73789 ("ASoC: pcm: Add support for DAI multicodec") Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87blui64mf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9d1cdde7f629dc6e7f2f5a087e844946b022fa7c Author: Kangjie Lu Date: Thu Oct 17 23:41:50 2019 -0500 drm/gma500: fix memory disclosures due to uninitialized bytes [ Upstream commit ec3b7b6eb8c90b52f61adff11b6db7a8db34de19 ] "clock" may be copied to "best_clock". Initializing best_clock is not sufficient. The fix initializes clock as well to avoid memory disclosures and informaiton leaks. Signed-off-by: Kangjie Lu Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20191018044150.1899-1-kjlu@umn.edu Signed-off-by: Sasha Levin commit 123c46d7326f7ff4fd5f54a10d4c07d67cd0ca52 Author: Weihang Li Date: Wed Sep 4 11:14:42 2019 +0800 RDMA/hns: Fix wrong parameters when initial mtt of srq->idx_que [ Upstream commit e8a07de57ea4ca7c2d604871c52826e66899fc70 ] The parameters npages used to initial mtt of srq->idx_que shouldn't be same with srq's. And page_shift should be calculated from idx_buf_pg_sz. This patch fixes above issues and use field named npage and page_shift in hns_roce_buf instead of two temporary variables to let us use them anywhere. Fixes: 18df508c7970 ("RDMA/hns: Remove if-else judgment statements for creating srq") Signed-off-by: Weihang Li Link: https://lore.kernel.org/r/1567566885-23088-3-git-send-email-liweihang@hisilicon.com Signed-off-by: Doug Ledford Signed-off-by: Sasha Levin commit ac3c43145dc876e9af31ca63aa47057c8b575691 Author: Jian Shen Date: Sat Oct 19 16:03:56 2019 +0800 net: hns3: log and clear hardware error after reset complete [ Upstream commit 4fdd0bca6152aa201898454e63cbb255a18ae6e9 ] When device is resetting, the CMDQ service may be stopped until reset completed. If a new RAS error occurs at this moment, it will no be able to clear the RAS source. This patch fixes it by clear the RAS source after reset complete. Signed-off-by: Jian Shen Signed-off-by: Huazhong Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f60b5fd207e351dcf05f28e4425ba8aab2cbf074 Author: Andrii Nakryiko Date: Sun Oct 20 20:39:00 2019 -0700 selftests/bpf: Make a copy of subtest name [ Upstream commit f90415e9600c5227131531c0ed11514a2d3bbe62 ] test_progs never created a copy of subtest name, rather just stored pointer to whatever string test provided. This is bad as that string might be freed or modified by the end of subtest. Fix this by creating a copy of given subtest name when subtest starts. Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191021033902.3856966-6-andriin@fb.com Signed-off-by: Sasha Levin commit dbb6e6f052d72c23aaf4771797e43ca5111f1edf Author: Leo Yan Date: Fri Oct 18 16:55:31 2019 +0800 perf tests: Disable bp_signal testing for arm64 [ Upstream commit 6a5f3d94cb69a185b921cb92c39888dc31009acb ] As there are several discussions for enabling perf breakpoint signal testing on arm64 platform: arm64 needs to rely on single-step to execute the breakpointed instruction and then reinstall the breakpoint exception handler. But if we hook the breakpoint with a signal, the signal handler will do the stepping rather than the breakpointed instruction, this causes infinite loops as below: Kernel space | Userspace ---------------------------------|-------------------------------- | __test_function() -> hit | breakpoint breakpoint_handler() | `-> user_enable_single_step() | do_signal() | | sig_handler() -> Step one | instruction and | trap to kernel single_step_handler() | `-> reinstall_suspended_bps() | | __test_function() -> hit | breakpoint again and | repeat up flow infinitely As Will Deacon mentioned [1]: "that we require the overflow handler to do the stepping on arm/arm64, which is relied upon by GDB/ptrace. The hw_breakpoint code is a complete disaster so my preference would be to rip out the perf part and just implement something directly in ptrace, but it's a pretty horrible job". Though Will commented this on arm architecture, but the comment also can apply on arm64 architecture. For complete information, I searched online and found a few years back, Wang Nan sent one patch 'arm64: Store breakpoint single step state into pstate' [2]; the patch tried to resolve this issue by avoiding single stepping in signal handler and defer to enable the signal stepping when return to __test_function(). The fixing was not merged due to the concern for missing to handle different usage cases. Based on the info, the most feasible way is to skip Perf breakpoint signal testing for arm64 and this could avoid the duplicate investigation efforts when people see the failure. This patch skips this case on arm64 platform, which is same with arm architecture. [1] https://lkml.org/lkml/2018/11/15/205 [2] https://lkml.org/lkml/2015/12/23/477 Signed-off-by: Leo Yan Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Brajeswar Ghosh Cc: Florian Fainelli Cc: Jiri Olsa Cc: Mark Rutland Cc: Michael Petlan Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Song Liu Cc: Souptick Joarder Cc: Will Deacon Link: http://lore.kernel.org/lkml/20191018085531.6348-3-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 07ce121158d3c84b8559077f4f6073586b5da825 Author: Tony Lindgren Date: Wed Oct 16 15:30:04 2019 -0700 power: supply: cpcap-battery: Check voltage before orderly_poweroff [ Upstream commit 639c1524da3b273d20c42ff2387d08eb4b12e903 ] We can get the low voltage interrupt trigger sometimes way too early, maybe because of CPU load spikes. This causes orderly_poweroff() be called too easily. Let's check the voltage before orderly_poweroff in case it was not yet a permanent condition. We will be getting more interrupts anyways if the condition persists. Let's also show the measured voltages for low battery and battery empty warnings since we have them. Cc: Merlijn Wajer Cc: Pavel Machek Signed-off-by: Tony Lindgren Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 699aab8bb6653874ba75eb3742d0469028cd18de Author: Chuhong Yuan Date: Wed Oct 16 22:25:40 2019 +0800 staging: iio: ad9834: add a check for devm_clk_get [ Upstream commit a96de139301385e5992768c0f60240ddfbb33325 ] ad9834_probe misses a check for devm_clk_get and may cause problems. Add a check like what ad9832 does to fix it. Signed-off-by: Chuhong Yuan Reviewed-by: Dan Carpenter Reviewed-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 5e1d763c3843b8f32acd87992c6378242cd64707 Author: Kevin Wang Date: Wed Oct 16 10:51:32 2019 +0800 drm/amdgpu: fix amdgpu trace event print string format error [ Upstream commit 2c2fdb8bca290c439e383cfb6857b0c65e528964 ] the trace event print string format error. (use integer type to handle string) before: amdgpu_test_kev-1556 [002] 138.508781: amdgpu_cs_ioctl: sched_job=8, timeline=gfx_0.0.0, context=177, seqno=1, ring_name=ffff94d01c207bf0, num_ibs=2 after: amdgpu_test_kev-1506 [004] 370.703783: amdgpu_cs_ioctl: sched_job=12, timeline=gfx_0.0.0, context=234, seqno=2, ring_name=gfx_0.0.0, num_ibs=1 change trace event list: 1.amdgpu_cs_ioctl 2.amdgpu_sched_run_job 3.amdgpu_ib_pipe_sync Signed-off-by: Kevin Wang Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit ff79af99f55e6c1f356db321cfb6d42ec3953e9e Author: joseph gravenor Date: Mon Jul 8 13:41:01 2019 -0400 drm/amd/display: fix header for RN clk mgr [ Upstream commit cd83fa1ea9b9431cf1d57ac4179a11bc4393a5b6 ] [why] Should always MP0_BASE for any register definition from MP per-IP header files. I belive the reason the linux version of MP1_BASE works is The 0th element of the 0th table of that is identical to the corrisponding value of MP0_BASE in the renoir offset header file. The reason we should only use MP0_BASE is There is only one set of per-IP headers MP that includes all register definitions related to SMU IP block. This IP includes MP0, MP1, MP2 and an ecryption engine that can be used only by MP0. As a result all register definitions from MP file should be based only on MP0_BASE data. [How] Change MP1_BASE to MP0_BASE Signed-off-by: joseph gravenor Acked-by: Bhawanpreet Lakha Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d4b13a10044b68e64b2849d1de1cb937b6c60bdd Author: Dmytro Laktyushkin Date: Wed Oct 2 15:19:41 2019 -0400 drm/amd/display: enable hostvm based on roimmu active for dcn2.1 [ Upstream commit 48d92e8eda3d9b61978377e7539bfc5958e850cf ] Enabling hostvm when ROIMMU is not active seems to break GPUVM. This fixes the issue by not enabling hostvm if ROIMMU is not activated. Signed-off-by: Dmytro Laktyushkin Acked-by: Bhawanpreet Lakha Reviewed-by: Roman Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 8f3ce0fa825d77c8e4b37a8ba95959c771a09eac Author: Benjamin Berg Date: Wed Oct 9 17:54:24 2019 +0200 x86/mce: Lower throttling MCE messages' priority to warning [ Upstream commit 9c3bafaa1fd88e4dd2dba3735a1f1abb0f2c7bb7 ] On modern CPUs it is quite normal that the temperature limits are reached and the CPU is throttled. In fact, often the thermal design is not sufficient to cool the CPU at full load and limits can quickly be reached when a burst in load happens. This will even happen with technologies like RAPL limitting the long term power consumption of the package. Also, these limits are "softer", as Srinivas explains: "CPU temperature doesn't have to hit max(TjMax) to get these warnings. OEMs ha[ve] an ability to program a threshold where a thermal interrupt can be generated. In some systems the offset is 20C+ (Read only value). In recent systems, there is another offset on top of it which can be programmed by OS, once some agent can adjust power limits dynamically. By default this is set to low by the firmware, which I guess the prime motivation of Benjamin to submit the patch." So these messages do not usually indicate a hardware issue (e.g. insufficient cooling). Log them as warnings to avoid confusion about their severity. [ bp: Massage commit mesage. ] Signed-off-by: Benjamin Berg Signed-off-by: Borislav Petkov Reviewed-by: Hans de Goede Tested-by: Christian Kellner Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-edac Cc: Peter Zijlstra Cc: Srinivas Pandruvada Cc: Thomas Gleixner Cc: Tony Luck Cc: x86-ml Link: https://lkml.kernel.org/r/20191009155424.249277-1-bberg@redhat.com Signed-off-by: Sasha Levin commit f1838da73cccb238b8be4ef464fce0168dc7ba84 Author: Song Liu Date: Mon Oct 14 10:12:23 2019 -0700 bpf/stackmap: Fix deadlock with rq_lock in bpf_get_stack() [ Upstream commit eac9153f2b584c702cea02c1f1a57d85aa9aea42 ] bpf stackmap with build-id lookup (BPF_F_STACK_BUILD_ID) can trigger A-A deadlock on rq_lock(): rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [...] Call Trace: try_to_wake_up+0x1ad/0x590 wake_up_q+0x54/0x80 rwsem_wake+0x8a/0xb0 bpf_get_stack+0x13c/0x150 bpf_prog_fbdaf42eded9fe46_on_event+0x5e3/0x1000 bpf_overflow_handler+0x60/0x100 __perf_event_overflow+0x4f/0xf0 perf_swevent_overflow+0x99/0xc0 ___perf_sw_event+0xe7/0x120 __schedule+0x47d/0x620 schedule+0x29/0x90 futex_wait_queue_me+0xb9/0x110 futex_wait+0x139/0x230 do_futex+0x2ac/0xa50 __x64_sys_futex+0x13c/0x180 do_syscall_64+0x42/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 This can be reproduced by: 1. Start a multi-thread program that does parallel mmap() and malloc(); 2. taskset the program to 2 CPUs; 3. Attach bpf program to trace_sched_switch and gather stackmap with build-id, e.g. with trace.py from bcc tools: trace.py -U -p -s t:sched:sched_switch A sample reproducer is attached at the end. This could also trigger deadlock with other locks that are nested with rq_lock. Fix this by checking whether irqs are disabled. Since rq_lock and all other nested locks are irq safe, it is safe to do up_read() when irqs are not disable. If the irqs are disabled, postpone up_read() in irq_work. Fixes: 615755a77b24 ("bpf: extend stackmap to save binary_build_id+offset instead of address") Signed-off-by: Song Liu Signed-off-by: Alexei Starovoitov Cc: Peter Zijlstra Cc: Alexei Starovoitov Cc: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191014171223.357174-1-songliubraving@fb.com Reproducer: ============================ 8< ============================ char *filename; void *worker(void *p) { void *ptr; int fd; char *pptr; fd = open(filename, O_RDONLY); if (fd < 0) return NULL; while (1) { struct timespec ts = {0, 1000 + rand() % 2000}; ptr = mmap(NULL, 4096 * 64, PROT_READ, MAP_PRIVATE, fd, 0); usleep(1); if (ptr == MAP_FAILED) { printf("failed to mmap\n"); break; } munmap(ptr, 4096 * 64); usleep(1); pptr = malloc(1); usleep(1); pptr[0] = 1; usleep(1); free(pptr); usleep(1); nanosleep(&ts, NULL); } close(fd); return NULL; } int main(int argc, char *argv[]) { void *ptr; int i; pthread_t threads[THREAD_COUNT]; if (argc < 2) return 0; filename = argv[1]; for (i = 0; i < THREAD_COUNT; i++) { if (pthread_create(threads + i, NULL, worker, NULL)) { fprintf(stderr, "Error creating thread\n"); return 0; } } for (i = 0; i < THREAD_COUNT; i++) pthread_join(threads[i], NULL); return 0; } ============================ 8< ============================ Signed-off-by: Sasha Levin commit 8d1b41437fa87ee7c5daae871fc8a722275fb09e Author: Mattijs Korpershoek Date: Wed Oct 16 20:20:39 2019 -0700 Bluetooth: hci_core: fix init for HCI_USER_CHANNEL [ Upstream commit eb8c101e28496888a0dcfe16ab86a1bee369e820 ] During the setup() stage, HCI device drivers expect the chip to acknowledge its setup() completion via vendor specific frames. If userspace opens() such HCI device in HCI_USER_CHANNEL [1] mode, the vendor specific frames are never tranmitted to the driver, as they are filtered in hci_rx_work(). Allow HCI devices which operate in HCI_USER_CHANNEL mode to receive frames if the HCI device is is HCI_INIT state. [1] https://www.spinics.net/lists/linux-bluetooth/msg37345.html Fixes: 23500189d7e0 ("Bluetooth: Introduce new HCI socket channel for user operation") Signed-off-by: Mattijs Korpershoek Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 3d236696495b15906a63b45fb3ce59ca33c8c9aa Author: Szymon Janc Date: Wed Oct 2 14:22:43 2019 +0200 Bluetooth: Workaround directed advertising bug in Broadcom controllers [ Upstream commit 4c371bb95cf06ded80df0e6139fdd77cee1d9a94 ] It appears that some Broadcom controllers (eg BCM20702A0) reject LE Set Advertising Parameters command if advertising intervals provided are not within range for undirected and low duty directed advertising. Workaround this bug by populating min and max intervals with 'valid' values. < HCI Command: LE Set Advertising Parameters (0x08|0x0006) plen 15 Min advertising interval: 0.000 msec (0x0000) Max advertising interval: 0.000 msec (0x0000) Type: Connectable directed - ADV_DIRECT_IND (high duty cycle) (0x01) Own address type: Public (0x00) Direct address type: Random (0x01) Direct address: E2:F0:7B:9F:DC:F4 (Static) Channel map: 37, 38, 39 (0x07) Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00) > HCI Event: Command Complete (0x0e) plen 4 LE Set Advertising Parameters (0x08|0x0006) ncmd 1 Status: Invalid HCI Command Parameters (0x12) Signed-off-by: Szymon Janc Tested-by: Sören Beye Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 3b27a67c78445bf70baef2c48bef0d0813071700 Author: Ben Dooks (Codethink) Date: Wed Oct 16 12:39:43 2019 +0100 Bluetooth: missed cpu_to_le16 conversion in hci_init4_req [ Upstream commit 727ea61a5028f8ac96f75ab34cb1b56e63fd9227 ] It looks like in hci_init4_req() the request is being initialised from cpu-endian data but the packet is specified to be little-endian. This causes an warning from sparse due to __le16 to u16 conversion. Fix this by using cpu_to_le16() on the two fields in the packet. net/bluetooth/hci_core.c:845:27: warning: incorrect type in assignment (different base types) net/bluetooth/hci_core.c:845:27: expected restricted __le16 [usertype] tx_len net/bluetooth/hci_core.c:845:27: got unsigned short [usertype] le_max_tx_len net/bluetooth/hci_core.c:846:28: warning: incorrect type in assignment (different base types) net/bluetooth/hci_core.c:846:28: expected restricted __le16 [usertype] tx_time net/bluetooth/hci_core.c:846:28: got unsigned short [usertype] le_max_tx_time Signed-off-by: Ben Dooks Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit 68c6909eb65bf9fe42a84a775b06f6593512cee9 Author: Arnd Bergmann Date: Wed Sep 18 21:59:02 2019 +0200 Bluetooth: btusb: avoid unused function warning [ Upstream commit 42d22098127d6384f789107f59caae87d7520fc4 ] The btusb_rtl_cmd_timeout() function is used inside of an ifdef, leading to a warning when this part is hidden from the compiler: drivers/bluetooth/btusb.c:530:13: error: unused function 'btusb_rtl_cmd_timeout' [-Werror,-Wunused-function] Use an IS_ENABLED() check instead so the compiler can see the code and then discard it silently. Fixes: d7ef0d1e3968 ("Bluetooth: btusb: Use cmd_timeout to reset Realtek device") Signed-off-by: Arnd Bergmann Signed-off-by: Marcel Holtmann Signed-off-by: Sasha Levin commit e57ff9fb690010a96bd88f2def9db1a16e55a38a Author: Miquel Raynal Date: Fri Oct 11 16:43:42 2019 +0200 iio: adc: max1027: Reset the device at probe time [ Upstream commit db033831b4f5589f9fcbadb837614a7c4eac0308 ] All the registers are configured by the driver, let's reset the chip at probe time, avoiding any conflict with a possible earlier configuration. Signed-off-by: Miquel Raynal Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit a6d47415fcd9472e2f02da9d2194a88845751031 Author: Le Ma Date: Fri Oct 11 18:37:49 2019 +0800 drm/amd/powerplay: avoid disabling ECC if RAS is enabled for VEGA20 [ Upstream commit df9331e561dab0a451cbd6a679ee88a95f306fd6 ] Program THM_BACO_CNTL.SOC_DOMAIN_IDLE=1 will tell VBIOS to disable ECC when BACO exit. This can save BACO exit time by PSP on none-ECC SKU. Drop the setting for ECC supported SKU. Signed-off-by: Le Ma Reviewed-by: Alex Deucher Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 48df48dc17b475c3664bc91f77f6641688b671d0 Author: Ingo Rohloff Date: Fri Oct 11 13:55:18 2019 +0200 usb: usbfs: Suppress problematic bind and unbind uevents. [ Upstream commit abb0b3d96a1f9407dd66831ae33985a386d4200d ] commit 1455cf8dbfd0 ("driver core: emit uevents when device is bound to a driver") added bind and unbind uevents when a driver is bound or unbound to a physical device. For USB devices which are handled via the generic usbfs layer (via libusb for example), this is problematic: Each time a user space program calls ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr); and then later ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr); The kernel will now produce a bind or unbind event, which does not really contain any useful information. This allows a user space program to run a DoS attack against programs which listen to uevents (in particular systemd/eudev/upowerd): A malicious user space program just has to call in a tight loop ioctl(usb_fd, USBDEVFS_CLAIMINTERFACE, &usb_intf_nr); ioctl(usb_fd, USBDEVFS_RELEASEINTERFACE, &usb_intf_nr); With this loop the malicious user space program floods the kernel and all programs listening to uevents with tons of bind and unbind events. This patch suppresses uevents for ioctls USBDEVFS_CLAIMINTERFACE and USBDEVFS_RELEASEINTERFACE. Signed-off-by: Ingo Rohloff Link: https://lore.kernel.org/r/20191011115518.2801-1-ingo.rohloff@lauterbach.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2fa6c5b18a88c610b17b2d58879d4b0f79e80599 Author: John Garry Date: Wed Sep 4 23:54:41 2019 +0800 perf vendor events arm64: Fix Hisi hip08 DDRC PMU eventname [ Upstream commit 84b0975f4853ba32d2d9b3c19ffa2b947f023fb3 ] The "EventName" for the DDRC precharge command event is incorrect, so fix it. Fixes: 57cc732479ba ("perf jevents: Add support for Hisi hip08 DDRC PMU aliasing") Signed-off-by: John Garry Reviewed-by: Shaokun Zhang Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Will Deacon Cc: linuxarm@huawei.com Link: http://lore.kernel.org/lkml/1567612484-195727-2-git-send-email-john.garry@huawei.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 5bd1406c516c8be8f53e9cd0774d3321ab3f5242 Author: Leo Yan Date: Fri Oct 11 17:19:42 2019 +0800 perf test: Avoid infinite loop for task exit case [ Upstream commit 791ce9c48c79210d2ffcdbe69421e7783b32921f ] When executing the task exit testing case, perf gets stuck in an endless loop this case and doesn't return back on Arm64 Juno board. After digging into this issue, since Juno board has Arm's big.LITTLE CPUs, thus the PMUs are not compatible between the big CPUs and little CPUs. This leads to a PMU event that cannot be enabled properly when the traced task is migrated from one variant's CPU to another variant. Finally, the test case runs into infinite loop for cannot read out any event data after return from polling. Eventually, we need to work out formal solution to allow PMU events can be freely migrated from one CPU variant to another, but this is a difficult task and a different topic. This patch tries to fix the Perf test case to avoid infinite loop, when the testing detects 1000 times retrying for reading empty events, it will directly bail out and return failure. This allows the Perf tool can continue its other test cases. Signed-off-by: Leo Yan Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/20191011091942.29841-2-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 9c1e7f59004d1cb67269eda8fee89b3f6f0ad69a Author: Jin Yao Date: Fri Oct 11 10:21:22 2019 +0800 perf report: Add warning when libunwind not compiled in [ Upstream commit 800d3f561659b5436f8c57e7c26dd1f6928b5615 ] We received a user report that call-graph DWARF mode was enabled in 'perf record' but 'perf report' didn't unwind the callstack correctly. The reason was, libunwind was not compiled in. We can use 'perf -vv' to check the compiled libraries but it would be valuable to report a warning to user directly (especially valuable for a perf newbie). The warning is: Warning: Please install libunwind development packages during the perf build. Both TUI and stdio are supported. Signed-off-by: Jin Yao Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Kan Liang Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20191011022122.26369-1-yao.jin@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 56596e13ecd292b2a28dbf96f9052a088a1ce845 Author: Leo Yan Date: Fri Oct 11 17:19:41 2019 +0800 perf test: Report failure for mmap events [ Upstream commit 6add129c5d9210ada25217abc130df0b7096ee02 ] When fail to mmap events in task exit case, it misses to set 'err' to -1; thus the testing will not report failure for it. This patch sets 'err' to -1 when fails to mmap events, thus Perf tool can report correct result. Fixes: d723a55096b8 ("perf test: Add test case for checking number of EXIT events") Signed-off-by: Leo Yan Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Link: http://lore.kernel.org/lkml/20191011091942.29841-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 48a5bcb24993295b198ee1dcbb3787585aee4a0d Author: Daniel Kurtz Date: Tue Oct 8 18:21:45 2019 +0800 drm/bridge: dw-hdmi: Restore audio when setting a mode [ Upstream commit fadfee3f9d8f114435a8a3e9f83a227600d89de7 ] When setting a new display mode, dw_hdmi_setup() calls dw_hdmi_enable_video_path(), which disables all hdmi clocks, including the audio clock. We should only (re-)enable the audio clock if audio was already enabled when setting the new mode. Without this patch, on RK3288, there will be HDMI audio on some monitors if i2s was played to headphone when the monitor was plugged. ACER H277HU and ASUS PB278 are two of the monitors showing this issue. Signed-off-by: Cheng-Yi Chiang Signed-off-by: Daniel Kurtz Signed-off-by: Yakir Yang Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20191008102145.55134-1-cychiang@chromium.org Signed-off-by: Sasha Levin commit 541833aa22eb2b80b2e6fdfb98bdf94b5b70b002 Author: Ping-Ke Shih Date: Tue Oct 8 16:21:00 2019 +0800 rtw88: coex: Set 4 slot mode for A2DP [ Upstream commit 12078aae453556a88fb46777b7cc5fc97f867b7c ] With shallow buffer size, certain BT devices have active A2DP flow control to fill buffer frequently. If the slot is not at BT side, data can't be sent successfully to BT devices, and will cause audio glitch. To resolve this issue, this commit splits TUs into 4-slots instead of 2-slot for all of the A2DP related coexistence strategies. That makes BT have higher opportunity to fill the A2DP buffer in time, and the audio quality could be more stable and smooth. Signed-off-by: Ping-Ke Shih Signed-off-by: Yan-Hsuan Chuang Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 01792265fbe1fc4a2dc99b3c26fa151a07ba07dd Author: Bjorn Andersson Date: Fri Oct 11 11:28:17 2019 -0700 ath10k: Correct error handling of dma_map_single() [ Upstream commit d43810b2c1808ac865aa1a2a2c291644bf95345c ] The return value of dma_map_single() should be checked for errors using dma_mapping_error() and the skb has been dequeued so it needs to be freed. This was found when enabling CONFIG_DMA_API_DEBUG and it warned about the missing dma_mapping_error() call. Fixes: 1807da49733e ("ath10k: wmi: add management tx by reference support over wmi") Reported-by: Niklas Cassel Signed-off-by: Bjorn Andersson Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit a823d762a57519adeb33f5f12f761d636e42d32e Author: Sami Tolvanen Date: Fri Sep 13 14:14:02 2019 -0700 x86/mm: Use the correct function type for native_set_fixmap() [ Upstream commit f53e2cd0b8ab7d9e390414470bdbd830f660133f ] We call native_set_fixmap indirectly through the function pointer struct pv_mmu_ops::set_fixmap, which expects the first parameter to be 'unsigned' instead of 'enum fixed_addresses'. This patch changes the function type for native_set_fixmap to match the pointer, which fixes indirect call mismatches with Control-Flow Integrity (CFI) checking. Signed-off-by: Sami Tolvanen Reviewed-by: Kees Cook Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Dave Hansen Cc: H . Peter Anvin Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20190913211402.193018-1-samitolvanen@google.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 556ec7a240067cf2cb51495a160127d8eea6d9c0 Author: Julian Parkin Date: Thu Aug 29 17:06:05 2019 -0400 drm/amd/display: Program DWB watermarks from correct state [ Upstream commit edb922b022c0c94805c4ffad202b3edff83d76f0 ] [Why] When diags adds a DWB via a stream update, we calculate MMHUBBUB paramaters, but dc->current_state has not yet been updated when the DWB programming happens. This leads to overflow on high bandwidth tests since the incorrect MMHUBBUB arbitration parameters are programmed. [How] Pass the updated context down to the (enable|update)_writeback functions so that they can use the correct watermarks when programming MMHUBBUB. Signed-off-by: Julian Parkin Reviewed-by: Dmytro Laktyushkin Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 5f5fdf612efb8fc3629d220058dccf5385ecdce3 Author: Stephan Gerhold Date: Thu Oct 10 17:47:20 2019 +0200 extcon: sm5502: Reset registers during initialization [ Upstream commit 6942635032cfd3e003e980d2dfa4e6323a3ce145 ] On some devices (e.g. Samsung Galaxy A5 (2015)), the bootloader seems to keep interrupts enabled for SM5502 when booting Linux. Changing the cable state (i.e. plugging in a cable) - until the driver is loaded - will therefore produce an interrupt that is never read. In this situation, the cable state will be stuck forever on the initial state because SM5502 stops sending interrupts. This can be avoided by clearing those pending interrupts after the driver has been loaded. One way to do this is to reset all registers to default state by writing to SM5502_REG_RESET. This ensures that we start from a clean state, with all interrupts disabled. Suggested-by: Chanwoo Choi Signed-off-by: Stephan Gerhold Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit 0d93c2907b1aa2f2bffef02d3ef933a8f8524314 Author: David Galiffi Date: Fri Sep 20 20:20:23 2019 -0400 drm/amd/display: Fix dongle_caps containing stale information. [ Upstream commit dd998291dbe92106d8c4a7581c409b356928d711 ] [WHY] During detection: function: get_active_converter_info populates link->dpcd_caps.dongle_caps only when dpcd_rev >= DPCD_REV_11 and DWN_STRM_PORTX_TYPE is DOWN_STREAM_DETAILED_HDMI or DOWN_STREAM_DETAILED_DP_PLUS_PLUS. Otherwise, it is not cleared, and stale information remains. During mode validation: function: dp_active_dongle_validate_timing reads link->dpcd_caps.dongle_caps->dongle_type to determine the maximum pixel clock to support. This information is now stale and no longer valid. [HOW] dp_active_dongle_validate_timing should be using link->dpcd_caps->dongle_type instead. Signed-off-by: David Galiffi Reviewed-by: Jun Lei Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit e79138ba8e0ec84f3ab5daa4761e4d534bbc682d Author: Sami Tolvanen Date: Tue Oct 8 15:40:45 2019 -0700 syscalls/x86: Use the correct function type in SYSCALL_DEFINE0 [ Upstream commit 8661d769ab77c675b5eb6c3351a372b9fbc1bf40 ] Although a syscall defined using SYSCALL_DEFINE0 doesn't accept parameters, use the correct function type to avoid type mismatches with Control-Flow Integrity (CFI) checking. Signed-off-by: Sami Tolvanen Acked-by: Andy Lutomirski Cc: Borislav Petkov Cc: H . Peter Anvin Cc: Kees Cook Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: https://lkml.kernel.org/r/20191008224049.115427-2-samitolvanen@google.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit c1790be4e0a8d5fe979424180bb4b71dba461901 Author: Vitaly Prosyak Date: Mon Sep 16 17:04:33 2019 -0500 drm/amd/display: add new active dongle to existent w/a [ Upstream commit 566b4252fe9da9582dde008c5e9c3eb7c136e348 ] [Why & How] Dongle 0x00E04C power down all internal circuits including AUX communication preventing reading DPCD table. Encoder will skip DP RX power down on disable output to keep receiver powered all the time. Signed-off-by: Vitaly Prosyak Reviewed-by: Charlene Liu Acked-by: Bhawanpreet Lakha Acked-by: Vitaly Prosyak Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit bf83687bac170848ee7324eba7c3678952d9e035 Author: Benoit Parrot Date: Mon Oct 7 12:09:59 2019 -0300 media: ti-vpe: vpe: fix a v4l2-compliance failure about invalid sizeimage [ Upstream commit 0bac73adea4df8d34048b38f6ff24dc3e73e90b6 ] v4l2-compliance fails with this message: fail: v4l2-test-formats.cpp(463): !pfmt.sizeimage fail: v4l2-test-formats.cpp(736): \ Video Capture Multiplanar is valid, \ but TRY_FMT failed to return a format test VIDIOC_TRY_FMT: FAIL This failure is causd by the driver failing to handle out range 'bytesperline' values from user space applications. VPDMA hardware is limited to 64k line stride (16 bytes aligned, so 65520 bytes). So make sure the provided or calculated 'bytesperline' is smaller than the maximum value. Signed-off-by: Benoit Parrot Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 722b60b6fae84e162f69a9dc6e15f079286c3071 Author: Josip Pavic Date: Thu Sep 12 15:40:08 2019 -0400 drm/amd/display: wait for set pipe mcp command completion [ Upstream commit 15caeabc5787c15babad7ee444afe9c26df1c8b3 ] [Why] When the driver sends a pipe set command to the DMCU FW, it does not wait for the command to complete. This can lead to unpredictable behavior if, for example, the driver were to request a pipe disable to the FW via MCP, then power down some hardware before the firmware has completed processing the command. [How] Wait for the DMCU FW to finish processing set pipe commands Signed-off-by: Josip Pavic Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2dc436de7ad6aa1025d0c78eefac4aa7ececc44a Author: Aric Cyr Date: Wed Sep 11 16:17:08 2019 -0400 drm/amd/display: Properly round nominal frequency for SPD [ Upstream commit c59802313e84bede954235b3a5dd0dd5325f49c5 ] [Why] Some displays rely on the SPD verticle frequency maximum value. Must round the calculated refresh rate to the nearest integer. [How] Round the nominal calculated refresh rate to the nearest whole integer. Signed-off-by: Aric Cyr Reviewed-by: Anthony Koo Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 4754e8234e06393d98d95c4188e6661ed0b1da5a Author: Benoit Parrot Date: Mon Oct 7 12:10:01 2019 -0300 media: ti-vpe: vpe: ensure buffers are cleaned up properly in abort cases [ Upstream commit cf6acb73b050e98b5cc435fae0e8ae0157520410 ] v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(691): ret == 0 fail: v4l2-test-buffers.cpp(974): captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL This caused the following Kernel Warning: WARNING: CPU: 0 PID: 961 at drivers/media/v4l2-core/videobuf2-core.c:1658 __vb2_queue_cancel+0x174/0x1d8 ... CPU: 0 PID: 961 Comm: v4l2-compliance Not tainted 4.14.62-01720-g20ecd717e87a #6 Hardware name: Generic DRA72X (Flattened Device Tree) Backtrace: [] (dump_backtrace) from [] (show_stack+0x18/0x1c) r7:00000009 r6:60070013 r5:00000000 r4:c1053824 [] (show_stack) from [] (dump_stack+0x90/0xa4) [] (dump_stack) from [] (__warn+0xec/0x104) r7:00000009 r6:c0c0ad50 r5:00000000 r4:00000000 [] (__warn) from [] (warn_slowpath_null+0x28/0x30) r9:00000008 r8:00000000 r7:eced4808 r6:edbc9bac r5:eced4844 r4:eced4808 [] (warn_slowpath_null) from [] (__vb2_queue_cancel+0x174/0x1d8) [] (__vb2_queue_cancel) from [] (vb2_core_queue_release+0x20/0x40) r10:ecc7bd70 r9:00000008 r8:00000000 r7:edb73010 r6:edbc9bac r5:eced4844 r4:eced4808 r3:00000004 [] (vb2_core_queue_release) from [] (vb2_queue_release+0x10/0x14) r5:edbc9810 r4:eced4800 [] (vb2_queue_release) from [] (v4l2_m2m_ctx_release+0x1c/0x30) [] (v4l2_m2m_ctx_release) from [] (vpe_release+0x74/0xb0 [ti_vpe]) r5:edbc9810 r4:ed67a400 [] (vpe_release [ti_vpe]) from [] (v4l2_release+0x3c/0x80) r7:edb73010 r6:ed176aa0 r5:edbc9868 r4:ed5119c0 [] (v4l2_release) from [] (__fput+0x8c/0x1dc) r5:ecc7bd70 r4:ed5119c0 [] (__fput) from [] (____fput+0x10/0x14) r10:00000000 r9:ed5119c0 r8:ece392d0 r7:c1059544 r6:ece38d80 r5:ece392b4 r4:00000000 [] (____fput) from [] (task_work_run+0x98/0xb8) [] (task_work_run) from [] (do_exit+0x170/0xa80) r9:ece351fc r8:00000000 r7:ecde3f58 r6:ffffe000 r5:ece351c0 r4:ece38d80 [] (do_exit) from [] (do_group_exit+0x48/0xc4) r7:000000f8 [] (do_group_exit) from [] (__wake_up_parent+0x0/0x28) r7:000000f8 r6:b6c6a798 r5:00000001 r4:00000001 [] (SyS_exit_group) from [] (ret_fast_syscall+0x0/0x4c) These warnings are caused by buffers which not properly cleaned up/release during an abort use case. In the abort cases the VPDMA desc buffers would still be mapped and the in-flight VB2 buffers would not be released properly causing a kernel warning from being generated by the videobuf2-core level. Signed-off-by: Benoit Parrot Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 32fa026d243e21399efb5b79d6c72b4ece93b50d Author: Benoit Parrot Date: Mon Oct 7 12:09:56 2019 -0300 media: ti-vpe: vpe: fix a v4l2-compliance failure causing a kernel panic [ Upstream commit a37980ac5be29b83da67bf7d571c6bd9f90f8e45 ] v4l2-compliance fails with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. test VIDIOC_TRY_FMT: FAIL This causes the following kernel panic: Unable to handle kernel paging request at virtual address 56595561 pgd = ecd80e00 *pgd=00000000 Internal error: Oops: 205 [#1] PREEMPT SMP ARM ... CPU: 0 PID: 930 Comm: v4l2-compliance Not tainted \ 4.14.62-01715-gc8cd67f49a19 #1 Hardware name: Generic DRA72X (Flattened Device Tree) task: ece44d80 task.stack: ecc6e000 PC is at __vpe_try_fmt+0x18c/0x2a8 [ti_vpe] LR is at 0x8 Because the driver fails to properly check the 'num_planes' values for proper ranges it ends up accessing out of bound data causing the kernel panic. Since this driver only handle single or dual plane pixel format, make sure the provided value does not exceed 2 planes. Signed-off-by: Benoit Parrot Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e1b2773c22cefd374c25d006a2151ea0c8ec7946 Author: Benoit Parrot Date: Mon Oct 7 12:09:58 2019 -0300 media: ti-vpe: vpe: Make sure YUYV is set as default format [ Upstream commit e20b248051ca0f90d84b4d9378e4780bc31f16c6 ] v4l2-compliance fails with this message: fail: v4l2-test-formats.cpp(672): \ Video Capture Multiplanar: TRY_FMT(G_FMT) != G_FMT fail: v4l2-test-formats.cpp(672): \ Video Output Multiplanar: TRY_FMT(G_FMT) != G_FMT ... test VIDIOC_TRY_FMT: FAIL The default pixel format was setup as pointing to a specific offset in the vpe_formats table assuming it was pointing to the V4L2_PIX_FMT_YUYV entry. This became false after the addition on the NV21 format (see above commid-id) So instead of hard-coding an offset which might change over time we need to use a lookup helper instead so we know the default will always be what we intended. Signed-off-by: Benoit Parrot Fixes: 40cc823f7005 ("media: ti-vpe: Add support for NV21 format") Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 24f8db4153492607c1975a3d168d00fda0b635ea Author: Benoit Parrot Date: Mon Oct 7 12:10:00 2019 -0300 media: ti-vpe: vpe: fix a v4l2-compliance failure about frame sequence number [ Upstream commit 2444846c0dbfa4ead21b621e4300ec32c90fbf38 ] v4l2-compliance fails with this message: fail: v4l2-test-buffers.cpp(294): \ (int)g_sequence() < seq.last_seq + 1 fail: v4l2-test-buffers.cpp(740): \ buf.check(m2m_q, last_m2m_seq) fail: v4l2-test-buffers.cpp(974): \ captureBufs(node, q, m2m_q, frame_count, true) test MMAP: FAIL The driver is failing to update the source frame sequence number in the vb2 buffer object. Only the destination frame sequence was being updated. This is only a reporting issue if the user space app actually cares about the frame sequence number. But it is fixed nonetheless. Signed-off-by: Benoit Parrot Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e2898767d6fb0162c9d4b74f24ad465921024cc4 Author: Benoit Parrot Date: Mon Oct 7 12:09:57 2019 -0300 media: ti-vpe: vpe: fix a v4l2-compliance warning about invalid pixel format [ Upstream commit 06bec72b250b2cb3ba96fa45c2b8e0fb83745517 ] v4l2-compliance warns with this message: warn: v4l2-test-formats.cpp(717): \ TRY_FMT cannot handle an invalid pixelformat. warn: v4l2-test-formats.cpp(718): \ This may or may not be a problem. For more information see: warn: v4l2-test-formats.cpp(719): \ http://www.mail-archive.com/linux-media@vger.kernel.org/msg56550.html ... test VIDIOC_TRY_FMT: FAIL We need to make sure that the returns a valid pixel format in all instance. Based on the v4l2 framework convention drivers must return a valid pixel format when the requested pixel format is either invalid or not supported. Signed-off-by: Benoit Parrot Reviewed-by: Tomi Valkeinen Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 33ec87948eab930440c4cf68896c2fb7f3238285 Author: Benoit Parrot Date: Mon Oct 7 12:09:50 2019 -0300 media: ti-vpe: vpe: Fix Motion Vector vpdma stride [ Upstream commit 102af9b9922f658f705a4b0deaccabac409131bf ] commit 3dc2046ca78b ("[media] media: ti-vpe: vpe: allow use of user specified stride") and commit da4414eaed15 ("[media] media: ti-vpe: vpdma: add support for user specified stride") resulted in the Motion Vector stride to be the same as the image stride. This caused memory corruption in the output image as mentioned in commit 00db969964c8 ("[media] media: ti-vpe: vpe: Fix line stride for output motion vector"). Fixes: 3dc2046ca78b ("[media] media: ti-vpe: vpe: allow use of user specified stride") Fixes: da4414eaed15 ("[media] media: ti-vpe: vpdma: add support for user specified stride") Signed-off-by: Benoit Parrot Acked-by: Nikhil Devshatwar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8be87bf0639b3dfd79814d5e56c291ba09fb8288 Author: Kai Vehmanen Date: Tue Oct 8 11:44:35 2019 -0500 ASoC: SOF: enable sync_write in hdac_bus [ Upstream commit f3416e7144f5d4ba0fc5dcef6ebfff891266c46a ] Align SOF HDA implementation with snd-hda-intel driver and enable sync_write flag for all supported Intel platforms in SOF. When set, a sync is issued after each verb write. Sync after write has helped to overcome intermittent delays in system resume flow on Intel Coffee Lake systems, and most recently probe errors related to the HDMI codec on Ice Lake systems. Matches the snd-hda-intel driver change done in commit 2756d9143aa5 ("ALSA: hda - Fix intermittent CORB/RIRB stall on Intel chips"). Signed-off-by: Kai Vehmanen Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191008164443.1358-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 6083bbaee80f6bc4e489c3648db9a23175b0c4a9 Author: Srinivas Kandagatla Date: Wed Oct 9 15:41:20 2019 +0100 misc: fastrpc: fix memory leak from miscdev->name [ Upstream commit 2d10d2d170723e9278282458a6704552dcb77eac ] Fix a memory leak in miscdev->name by using devm_variant Orignally reported by kmemleak: [] kmemleak_alloc+0x50/0x84 [] __kmalloc_track_caller+0xe8/0x168 [] kvasprintf+0x78/0x100 [] kasprintf+0x50/0x74 [] fastrpc_rpmsg_probe+0xd8/0x20c [] rpmsg_dev_probe+0xa8/0x148 [] really_probe+0x208/0x248 [] driver_probe_device+0x98/0xc0 [] __device_attach_driver+0x9c/0xac [] bus_for_each_drv+0x60/0x8c [] __device_attach+0x8c/0x100 [] device_initial_probe+0x20/0x28 [] bus_probe_device+0x34/0x7c [] device_add+0x420/0x498 [] device_register+0x24/0x2c Signed-off-by: Srinivas Kandagatla Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20191009144123.24583-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 900497700460c9031e11066a2c64a4812d5154ae Author: Ard Biesheuvel Date: Wed Oct 2 09:54:48 2019 +0200 crypto: aegis128/simd - build 32-bit ARM for v8 architecture explicitly [ Upstream commit 830536770f968ab33ece123b317e252c269098db ] Now that the Clang compiler has taken it upon itself to police the compiler command line, and reject combinations for arguments it views as incompatible, the AEGIS128 no longer builds correctly, and errors out like this: clang-10: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] So let's switch to armv8-a instead, which matches the crypto-neon-fp-armv8 FPU profile we specify. Since neither were actually supported by GCC versions before 4.8, let's tighten the Kconfig dependencies as well so we won't run into errors when building with an ancient compiler. Signed-off-by: Ard Biesheuvel Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Reviewed-by: Nick Desaulniers Tested-by: Nick Desaulniers Reported-by: Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 313400a9676758881b11ecf871f918385d2eedfd Author: Arnd Bergmann Date: Mon Sep 30 14:14:33 2019 +0200 crypto: inside-secure - Fix a maybe-uninitialized warning [ Upstream commit 74e6bd472b6d9e80ec9972989d8991736fe46c51 ] A previous fixup avoided an unused variable warning but replaced it with a slightly scarier warning: drivers/crypto/inside-secure/safexcel.c:1100:6: error: variable 'irq' is used uninitialized whenever 'if' condition is false [-Werror,-Wsometimes-uninitialized] This is harmless as it is impossible to get into this case, but the compiler has no way of knowing that. Add an explicit error handling case to make it obvious to both compilers and humans reading the source. Fixes: 212ef6f29e5b ("crypto: inside-secure - Fix unused variable warning when CONFIG_PCI=n") Signed-off-by: Arnd Bergmann Acked-by: Pascal van Leeuwen Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 8120c9b4692b753d07c05fbf89c297efd54a66eb Author: Christophe JAILLET Date: Sun Sep 22 04:41:23 2019 -0300 media: cx88: Fix some error handling path in 'cx8800_initdev()' [ Upstream commit e1444e9b0424c70def6352580762d660af50e03f ] A call to 'pci_disable_device()' is missing in the error handling path. In some cases, a call to 'free_irq()' may also be missing. Reorder the error handling path, add some new labels and fix the 2 issues mentionned above. This way, the error handling path in more in line with 'cx8800_finidev()' (i.e. the remove function) Signed-off-by: Christophe JAILLET Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit abed9c5a2e929dd24bba356c7aa4cdcc9993b636 Author: Hangbin Liu Date: Wed Oct 9 20:18:28 2019 +0800 team: call RCU read lock when walking the port_list [ Upstream commit c17e26ddc79596230834345be80fcad6c619e9ec ] Before reading the team port list, we need to acquire the RCU read lock. Also change list_for_each_entry() to list_for_each_entry_rcu(). v2: repost the patch to net-next and remove fixes flag as this is a cosmetic change. Suggested-by: Paolo Abeni Signed-off-by: Hangbin Liu Acked-by: Paolo Abeni Acked-by: Jiri Pirko Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 2674c57c3bba13dc3a9ec1da9fa3e3bfe9f0435b Author: Ursula Braun Date: Wed Oct 9 10:07:45 2019 +0200 net/smc: increase device refcount for added link group [ Upstream commit b3cb53c05f20c5b4026a36a7bbd3010d1f3e0a55 ] SMCD link groups belong to certain ISM-devices and SMCR link group links belong to certain IB-devices. Increase the refcount for these devices, as long as corresponding link groups exist. Signed-off-by: Ursula Braun Signed-off-by: Karsten Graul Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 68b4c10813b4b1cfff2e2c80a79a187a97548d3f Author: Ilya Maximets Date: Wed Oct 9 18:49:29 2019 +0200 libbpf: Fix passing uninitialized bytes to setsockopt [ Upstream commit 25bfef430e960e695403b5d9c8dcc11b9f5d62be ] 'struct xdp_umem_reg' has 4 bytes of padding at the end that makes valgrind complain about passing uninitialized stack memory to the syscall: Syscall param socketcall.setsockopt() points to uninitialised byte(s) at 0x4E7AB7E: setsockopt (in /usr/lib64/libc-2.29.so) by 0x4BDE035: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:172) Uninitialised value was created by a stack allocation at 0x4BDDEBA: xsk_umem__create@@LIBBPF_0.0.4 (xsk.c:140) Padding bytes appeared after introducing of a new 'flags' field. memset() is required to clear them. Fixes: 10d30e301732 ("libbpf: add flags to umem config") Signed-off-by: Ilya Maximets Signed-off-by: Alexei Starovoitov Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20191009164929.17242-1-i.maximets@ovn.org Signed-off-by: Sasha Levin commit f97e8686e64798bbe71381cf5afa00093ae48972 Author: Andrii Nakryiko Date: Tue Oct 8 16:10:06 2019 -0700 libbpf: Fix struct end padding in btf_dump [ Upstream commit b4099769f3321a8d258a47a8b4b9d278dad28a73 ] Fix a case where explicit padding at the end of a struct is necessary due to non-standart alignment requirements of fields (which BTF doesn't capture explicitly). Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion") Reported-by: John Fastabend Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Tested-by: John Fastabend Link: https://lore.kernel.org/bpf/20191008231009.2991130-2-andriin@fb.com Signed-off-by: Sasha Levin commit 8ff8178124e244646050db5455fee0c4bd0380bb Author: Andrii Nakryiko Date: Tue Oct 8 16:10:08 2019 -0700 selftests/bpf: Fix btf_dump padding test case [ Upstream commit 76790c7c66ccc8695afc75e73f54c0ca86267ed2 ] Existing padding test case for btf_dump has a good test that was supposed to test padding generation at the end of a struct, but its expected output was specified incorrectly. Fix this. Fixes: 2d2a3ad872f8 ("selftests/bpf: add btf_dump BTF-to-C conversion tests") Reported-by: John Fastabend Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191008231009.2991130-4-andriin@fb.com Signed-off-by: Sasha Levin commit d30249bae5e1b73faff11d7453801549b6fa3174 Author: Rodrigo Siqueira Date: Wed Oct 2 11:05:16 2019 -0300 drm/drm_vblank: Change EINVAL by the correct errno [ Upstream commit aed6105b28b10613f16c0bfe97525fe5a23338df ] For historical reasons, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace to make detailed verification of any problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL, which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, drm_crtc_get_sequence_ioctl and drm_crtc_queue_sequence_ioctl, also returns EINVAL if vblank is not supported; this patch also changes the return value to EOPNOTSUPP in these functions. Lastly, these functions are invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined: * Drm-hwcomposer * Kwin * Sway * Wlroots * Wayland * Weston * Mutter * Xorg (67 different drivers) For each repository the verification happened in three steps: * Update the main branch * Look for any occurrence of "drmCrtcQueueSequence", "drmCrtcGetSequence", and "drmWaitVBlank" with the command git grep -n "STRING". * Look in the git history of the project with the command git log -S None of the above projects validate the use of EINVAL when using drmWaitVBlank(), which make safe, at least for these projects, to change the return values. On the other hand, mesa and xserver project uses drmCrtcQueueSequence() and drmCrtcGetSequence(); this change is harmless for both projects. Change since V5 (Pekka Paalanen): - Check if the change also affects Mutter Change since V4 (Daniel): - Also return EOPNOTSUPP in drm_crtc_[get|queue]_sequence_ioctl Change since V3: - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) Change since V2: Daniel Vetter and Chris Wilson - Replace ENOTTY by EOPNOTSUPP - Return EINVAL if the parameters are wrong Cc: Keith Packard Cc: Maarten Lankhorst Cc: Ville Syrjälä Cc: Chris Wilson Cc: Daniel Vetter Cc: Pekka Paalanen Signed-off-by: Rodrigo Siqueira Reviewed-by: Daniel Vetter Acked-by: Pekka Paalanen Link: https://patchwork.freedesktop.org/patch/msgid/20191002140516.adeyj3htylimmlmg@smtp.gmail.com Signed-off-by: Sasha Levin commit 01b987532b79828ca67efb63eeec2bf07f3099df Author: Navid Emamdoost Date: Fri Oct 4 15:16:48 2019 -0500 mwifiex: pcie: Fix memory leak in mwifiex_pcie_init_evt_ring [ Upstream commit d10dcb615c8e29d403a24d35f8310a7a53e3050c ] In mwifiex_pcie_init_evt_ring, a new skb is allocated which should be released if mwifiex_map_pci_memory() fails. The release for skb and card->evtbd_ring_vbase is added. Fixes: 0732484b47b5 ("mwifiex: separate ring initialization and ring creation routines") Signed-off-by: Navid Emamdoost Acked-by: Ganapathi Bhat Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d754a529a8be55f009c6679d772c472c1632cd5b Author: Paul Burton Date: Tue Oct 1 21:53:38 2019 +0000 MIPS: futex: Emit Loongson3 sync workarounds within asm [ Upstream commit 3c1d3f0979721a39dd2980c97466127ce65aa130 ] Generate the sync instructions required to workaround Loongson3 LL/SC errata within inline asm blocks, which feels a little safer than doing it from C where strictly speaking the compiler would be well within its rights to insert a memory access between the separate asm statements we previously had, containing sync & ll instructions respectively. Signed-off-by: Paul Burton Cc: linux-mips@vger.kernel.org Cc: Huacai Chen Cc: Jiaxun Yang Cc: linux-kernel@vger.kernel.org Signed-off-by: Sasha Levin commit be30e550a54c4b088a0b6f4e1ac4b27b72decd41 Author: Oak Zeng Date: Fri Oct 4 09:28:21 2019 -0500 drm/amdkfd: Fix MQD size calculation [ Upstream commit 40a9592a26608e16f7545a068ea4165e1869f629 ] On device initialization, a chunk of GTT memory is pre-allocated for HIQ and all SDMA queues mqd. The size of this allocation was wrong. The correct sdma engine number should be PCIe-optimized SDMA engine number plus xgmi SDMA engine number. Reported-by: Jonathan Kim Signed-off-by: Jonathan Kim Signed-off-by: Oak Zeng Reviewed-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 466e2d02e45daf7390cbbf6b5f349980245c3faa Author: Bart Van Assche Date: Mon Sep 30 16:00:41 2019 -0700 block: Fix writeback throttling W=1 compiler warnings [ Upstream commit 1d200e9d6f635ae894993a7d0f1b9e0b6e522e3b ] Fix the following compiler warnings: In file included from ./include/linux/bitmap.h:9, from ./include/linux/cpumask.h:12, from ./arch/x86/include/asm/cpumask.h:5, from ./arch/x86/include/asm/msr.h:11, from ./arch/x86/include/asm/processor.h:21, from ./arch/x86/include/asm/cpufeature.h:5, from ./arch/x86/include/asm/thread_info.h:53, from ./include/linux/thread_info.h:38, from ./arch/x86/include/asm/preempt.h:7, from ./include/linux/preempt.h:78, from ./include/linux/spinlock.h:51, from ./include/linux/mmzone.h:8, from ./include/linux/gfp.h:6, from ./include/linux/mm.h:10, from ./include/linux/bvec.h:13, from ./include/linux/blk_types.h:10, from block/blk-wbt.c:23: In function 'strncpy', inlined from 'perf_trace_wbt_stat' at ./include/trace/events/wbt.h:15:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_lat' at ./include/trace/events/wbt.h:58:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_step' at ./include/trace/events/wbt.h:87:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'perf_trace_wbt_timer' at ./include/trace/events/wbt.h:126:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_stat' at ./include/trace/events/wbt.h:15:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_lat' at ./include/trace/events/wbt.h:58:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_timer' at ./include/trace/events/wbt.h:126:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In function 'strncpy', inlined from 'trace_event_raw_event_wbt_step' at ./include/trace/events/wbt.h:87:1: ./include/linux/string.h:260:9: warning: '__builtin_strncpy' specified bound 32 equals destination size [-Wstringop-truncation] return __builtin_strncpy(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Cc: Johannes Thumshirn Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism"; v4.10). Signed-off-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit fa2f23e6a883b20673da93a2368aca71490badb9 Author: Daniel T. Lee Date: Sat Oct 5 17:25:07 2019 +0900 samples: pktgen: fix proc_cmd command result check logic [ Upstream commit 3cad8f911575191fb3b81d8ed0e061e30f922223 ] Currently, proc_cmd is used to dispatch command to 'pg_ctrl', 'pg_thread', 'pg_set'. proc_cmd is designed to check command result with grep the "Result:", but this might fail since this string is only shown in 'pg_thread' and 'pg_set'. This commit fixes this logic by grep-ing the "Result:" string only when the command is not for 'pg_ctrl'. For clarity of an execution flow, 'errexit' flag has been set. To cleanup pktgen on exit, trap has been added for EXIT signal. Signed-off-by: Daniel T. Lee Acked-by: Jesper Dangaard Brouer Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f2a96101c5d2e7ea439517774fad1e2f6109333b Author: Matthias Kaehlcke Date: Wed Oct 2 12:44:06 2019 -0700 drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller [ Upstream commit bee447e224b2645911c5d06e35dc90d8433fcef6 ] The DDC/CI protocol involves sending a multi-byte request to the display via I2C, which is typically followed by a multi-byte response. The internal I2C controller only allows single byte reads/writes or reads of 8 sequential bytes, hence DDC/CI is not supported when the internal I2C controller is used. The I2C transfers complete without errors, however the data in the response is garbage. Abort transfers to/from slave address 0x37 (DDC) with -EOPNOTSUPP, to make it evident that the communication is failing. Signed-off-by: Matthias Kaehlcke Reviewed-by: Douglas Anderson Reviewed-by: Sean Paul Acked-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20191002124354.v2.1.I709dfec496f5f0b44a7b61dcd4937924da8d8382@changeid Signed-off-by: Sasha Levin commit d3cac7d030ef7114708da4d377e63b8f8fdd7273 Author: Neil Armstrong Date: Fri Oct 4 11:47:19 2019 -0300 media: meson/ao-cec: move cec_notifier_cec_adap_register after hw setup [ Upstream commit 3e84a18a259e1df35e5b549ab92ec3baf82ff010 ] When probed after the HDMI notifier, calling cec_notifier_cec_adap_register() calls the enable() adapter callback, but the HW is not yet set up. Moving cec_notifier_cec_adap_register() right before cec_register_adapter() fixes the following crash: Ignoring spurious kernel translation fault at virtual address 0000000000000008 [...] Hardware name: Khadas VIM (DT) [...] pc : __do_kernel_fault+0xdc/0x120 lr : __do_kernel_fault+0xdc/0x120 [...] Call trace: __do_kernel_fault+0xdc/0x120 do_page_fault+0x180/0x458 do_translation_fault+0x64/0x70 do_mem_abort+0x3c/0x98 el1_da+0x20/0x94 meson_ao_cec_adap_enable+0x30/0x218 [ao_cec] __cec_s_phys_addr+0x184/0x270 cec_s_phys_addr+0x44/0x60 cec_notifier_cec_adap_register+0x68/0x90 meson_ao_cec_probe+0xb0/0x288 [ao_cec] [...] el0_svc_compat+0x8/0x10 Reported-by: Christian Hewitt Suggested-by: Hans Verkuil Fixes: 20958f9d5c48 ("media: meson/ao-cec: use cec_notifier_cec_adap_(un)register") Signed-off-by: Neil Armstrong Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6db9b02e75426c031e254b12d32c35a9dca0a87f Author: Hans Verkuil Date: Tue Oct 1 04:56:38 2019 -0300 media: cec-funcs.h: add status_req checks [ Upstream commit 9b211f9c5a0b67afc435b86f75d78273b97db1c5 ] The CEC_MSG_GIVE_DECK_STATUS and CEC_MSG_GIVE_TUNER_DEVICE_STATUS commands both have a status_req argument: ON, OFF, ONCE. If ON or ONCE, then the follower will reply with a STATUS message. Either once or whenever the status changes (status_req == ON). If status_req == OFF, then it will stop sending continuous status updates, but the follower will *not* send a STATUS message in that case. This means that if status_req == OFF, then msg->reply should be 0 as well since no reply is expected in that case. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 6ca12b7e229e4a40596b4388c15acca1d2c4b726 Author: Yang Yingliang Date: Tue Sep 24 06:49:04 2019 -0300 media: flexcop-usb: fix NULL-ptr deref in flexcop_usb_transfer_init() [ Upstream commit 649cd16c438f51d4cd777e71ca1f47f6e0c5e65d ] If usb_set_interface() failed, iface->cur_altsetting will not be assigned and it will be used in flexcop_usb_transfer_init() It may lead a NULL pointer dereference. Check usb_set_interface() return value in flexcop_usb_init() and return failed to avoid using this NULL pointer. Signed-off-by: Yang Yingliang Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit dde38b5cf1ef4091abdf6615dfb485de499adde6 Author: Alan Stern Date: Fri Sep 6 16:57:22 2019 -0400 tools/memory-model: Fix data race detection for unordered store and load [ Upstream commit daebf24a8e8c6064cba3a330db9fe9376a137d2c ] Currently the Linux Kernel Memory Model gives an incorrect response for the following litmus test: C plain-WWC {} P0(int *x) { WRITE_ONCE(*x, 2); } P1(int *x, int *y) { int r1; int r2; int r3; r1 = READ_ONCE(*x); if (r1 == 2) { smp_rmb(); r2 = *x; } smp_rmb(); r3 = READ_ONCE(*x); WRITE_ONCE(*y, r3 - 1); } P2(int *x, int *y) { int r4; r4 = READ_ONCE(*y); if (r4 > 0) WRITE_ONCE(*x, 1); } exists (x=2 /\ 1:r2=2 /\ 2:r4=1) The memory model says that the plain read of *x in P1 races with the WRITE_ONCE(*x) in P2. The problem is that we have a write W and a read R related by neither fre or rfe, but rather W ->coe W' ->rfe R, where W' is an intermediate write (the WRITE_ONCE() in P0). In this situation there is no particular ordering between W and R, so either a wr-vis link from W to R or an rw-xbstar link from R to W would prove that the accesses aren't concurrent. But the LKMM only looks for a wr-vis link, which is equivalent to assuming that W must execute before R. This is not necessarily true on non-multicopy-atomic systems, as the WWC pattern demonstrates. This patch changes the LKMM to accept either a wr-vis or a reverse rw-xbstar link as a proof of non-concurrency. Signed-off-by: Alan Stern Acked-by: Andrea Parri Signed-off-by: Paul E. McKenney Signed-off-by: Sasha Levin commit 913b33a280b455b0af451cafc02900d03bf30ad7 Author: Yizhuo Date: Thu Oct 3 10:58:13 2019 -0700 regulator: max8907: Fix the usage of uninitialized variable in max8907_regulator_probe() [ Upstream commit 472b39c3d1bba0616eb0e9a8fa3ad0f56927c7d7 ] Inside function max8907_regulator_probe(), variable val could be uninitialized if regmap_read() fails. However, val is used later in the if statement to decide the content written to "pmic", which is potentially unsafe. Signed-off-by: Yizhuo Link: https://lore.kernel.org/r/20191003175813.16415-1-yzhai003@ucr.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 697183da67c6d7e70b146dd127abd8c485284786 Author: Tony Lindgren Date: Sat Sep 14 14:02:56 2019 -0700 hwrng: omap3-rom - Call clk_disable_unprepare() on exit only if not idled [ Upstream commit eaecce12f5f0d2c35d278e41e1bc4522393861ab ] When unloading omap3-rom-rng, we'll get the following: WARNING: CPU: 0 PID: 100 at drivers/clk/clk.c:948 clk_core_disable This is because the clock may be already disabled by omap3_rom_rng_idle(). Let's fix the issue by checking for rng_idle on exit. Cc: Aaro Koskinen Cc: Adam Ford Cc: Pali Rohár Cc: Sebastian Reichel Cc: Tero Kristo Fixes: 1c6b7c2108bd ("hwrng: OMAP3 ROM Random Number Generator support") Signed-off-by: Tony Lindgren Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit de5d03f64048e98427ad1d1f45622434f7b9acc3 Author: Ard Biesheuvel Date: Fri Sep 13 19:36:18 2019 +0100 crypto: aegis128-neon - use Clang compatible cflags for ARM [ Upstream commit 2eb2d198bd6cd0083a5363ce66272fb34a19928f ] The next version of Clang will start policing compiler command line options, and will reject combinations of -march and -mfpu that it thinks are incompatible. This results in errors like clang-10: warning: ignoring extension 'crypto' because the 'armv7-a' architecture does not support it [-Winvalid-command-line-argument] /tmp/aegis128-neon-inner-5ee428.s: Assembler messages: /tmp/aegis128-neon-inner-5ee428.s:73: Error: selected processor does not support `aese.8 q2,q14' in ARM mode when buiding the SIMD aegis128 code for 32-bit ARM, given that the 'armv7-a' -march argument is considered to be compatible with the ARM crypto extensions. Instead, we should use armv8-a, which does allow the crypto extensions to be enabled. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit c9b5983b02ae5923b68b8ea11f358a1158b06009 Author: Veeraiyan Chidambaram Date: Wed Sep 11 15:15:56 2019 +0200 usb: renesas_usbhs: add suspend event support in gadget mode [ Upstream commit 39abcc84846bbc0538f13c190b6a9c7e36890cd2 ] When R-Car Gen3 USB 2.0 is in Gadget mode, if host is detached an interrupt will be generated and Suspended state bit is set in interrupt status register. Interrupt handler will call driver->suspend(composite_suspend) if suspended state bit is set. composite_suspend will call ffs_func_suspend which will post FUNCTIONFS_SUSPEND and will be consumed by user space application via /dev/ep0. To be able to detect host detach, extend the DVSQ_MASK to cover the Suspended bit of the DVSQ[2:0] bitfield from the Interrupt Status Register 0 (INTSTS0) register and perform appropriate action in the DVST interrupt handler (usbhsg_irq_dev_state). Without this commit, disconnection of the phone from R-Car-H3 ES2.0 Salvator-X CN9 port is not recognized and reverse role switch does not happen. If phone is connected again it does not enumerate. With this commit, disconnection will be recognized and reverse role switch will happen by a user space application. If phone is connected again it will enumerate properly and will become visible in the output of 'lsusb'. Signed-off-by: Veeraiyan Chidambaram Signed-off-by: Eugeniu Rosca Reviewed-by: Yoshihiro Shimoda Tested-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1568207756-22325-3-git-send-email-external.veeraiyan.c@de.adit-jv.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 0a75fea2ef4514b9643334a7935b4809ec03bd2b Author: Raul E Rangel Date: Thu Oct 3 14:24:44 2019 -0600 drm/amd/display: fix struct init in update_bounding_box [ Upstream commit 960b6f4f2d2e96d5f7ffe2854e0040b46cafbd36 ] dcn20_resource.c:2636:9: error: missing braces around initializer [-Werror=missing-braces] struct _vcs_dpi_voltage_scaling_st calculated_states[MAX_CLOCK_LIMIT_STATES] = {0}; ^ Fixes: 7ed4e6352c16f ("drm/amd/display: Add DCN2 HW Sequencer and Resource") Signed-off-by: Raul E Rangel Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 76452980982b1d30f4fc329256444b67144d71ce Author: Ping-Ke Shih Date: Wed Oct 2 14:35:30 2019 +0800 rtw88: fix NSS of hw_cap [ Upstream commit 4f5bb7ff8b8d4bafd91243fc969ed240e67aa1ca ] 8822C is a 2x2 11ac chip, and then NSS must be less or equal to 2. However, current nss of hw cap is 3, likes hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=3 This commit adds constraint to make sure NSS <= rf_path_num, and result looks like hw cap: hci=0x0f, bw=0x07, ptcl=0x03, ant_num=7, nss=2 Fixes: e3037485c68e ("rtw88: new Realtek 802.11ac driver") Signed-off-by: Ping-Ke Shih Signed-off-by: Yan-Hsuan Chuang Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 849600bba283dce70311d1662b383a4b98070e38 Author: Stanimir Varbanov Date: Tue Sep 17 09:02:26 2019 -0300 media: venus: Fix occasionally failures to suspend [ Upstream commit 8dbebb2bd01e6f36e9a215dcde99ace70408f2c8 ] Failure to suspend (venus_suspend_3xx) happens when the system is fresh booted and loading venus driver. This happens once and after reload the venus driver modules the problem disrepair. Fix the failure by skipping the check for WFI and IDLE bits if PC_READY is on in control status register. Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 21a92d3bd04a5deaa328a038cdda9dcf59e0c0ad Author: Anthony Koo Date: Thu Aug 29 10:49:12 2019 -0400 drm/amd/display: set minimum abm backlight level [ Upstream commit 2ad0cdf9e2e9e079af34af681863fa638f2ee212 ] [Why] A lot of the time, the backlight characteristic curve maps min backlight to a non-zero value. But there are cases where we want the curve to intersect at 0. In this scenario even if OS never asks to set 0% backlight, the ABM reduction can result in backlight being lowered close to 0. This particularly can cause problems in some LED drivers, and in general just looks like backlight is completely off. [How] Add default cap to disallow backlight from dropping below 1% even after ABM reduction is applied. Signed-off-by: Anthony Koo Reviewed-by: Aric Cyr Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit d182d1e468b1acbdf5a6577df0a799457abff0cc Author: Ivan Khoronzhuk Date: Wed Oct 2 15:04:04 2019 +0300 selftests/bpf: Correct path to include msg + path [ Upstream commit c588146378962786ddeec817f7736a53298a7b01 ] The "path" buf is supposed to contain path + printf msg up to 24 bytes. It will be cut anyway, but compiler generates truncation warns like: " samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c: In function ‘setup_cgroup_environment’: samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:52:34: warning: ‘/cgroup.controllers’ directive output may be truncated writing 19 bytes into a region of size between 1 and 4097 [-Wformat-truncation=] snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path); ^~~~~~~~~~~~~~~~~~~ samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:52:2: note: ‘snprintf’ output between 20 and 4116 bytes into a destination of size 4097 snprintf(path, sizeof(path), "%s/cgroup.controllers", cgroup_path); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:72:34: warning: ‘/cgroup.subtree_control’ directive output may be truncated writing 23 bytes into a region of size between 1 and 4097 [-Wformat-truncation=] snprintf(path, sizeof(path), "%s/cgroup.subtree_control", ^~~~~~~~~~~~~~~~~~~~~~~ cgroup_path); samples/bpf/../../tools/testing/selftests/bpf/cgroup_helpers.c:72:2: note: ‘snprintf’ output between 24 and 4120 bytes into a destination of size 4097 snprintf(path, sizeof(path), "%s/cgroup.subtree_control", cgroup_path); " In order to avoid warns, lets decrease buf size for cgroup workdir on 24 bytes with assumption to include also "/cgroup.subtree_control" to the address. The cut will never happen anyway. Signed-off-by: Ivan Khoronzhuk Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20191002120404.26962-3-ivan.khoronzhuk@linaro.org Signed-off-by: Sasha Levin commit 3a1a19100414f73d56fc91851f17023c957cab60 Author: chen gong Date: Mon Sep 23 15:02:56 2019 +0800 drm/amd/powerplay: A workaround to GPU RESET on APU [ Upstream commit 068ad870bbd8f4f2c5b2fd4977a4f3330c9988f4 ] Changes to function "smu_suspend" in amdgpu_smu.c is a workaround. We should get real information about if baco is enabled or not, while we always consider APU SMU feature as enabled in current code. I know APU do not support baco mode for GPU reset, so I use "adev->flags" to skip function "smu_feature_is_enabled". Signed-off-by: chen gong Reviewed-by: Aaron Liu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 53048788d62c9373a8206858ee837f590395c892 Author: Arnd Bergmann Date: Tue Oct 1 16:23:34 2019 +0200 x86/math-emu: Check __copy_from_user() result [ Upstream commit e6b44ce1925a8329a937c57f0d60ba0d9bb5d226 ] The new __must_check annotation on __copy_from_user() successfully identified some code that has lacked the check since at least linux-2.1.73: arch/x86/math-emu/reg_ld_str.c:88:2: error: ignoring return value of \ function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]         __copy_from_user(sti_ptr, s, 10);         ^~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~ arch/x86/math-emu/reg_ld_str.c:1129:2: error: ignoring return value of \ function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]         __copy_from_user(register_base + offset, s, other);         ^~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ arch/x86/math-emu/reg_ld_str.c:1131:3: error: ignoring return value of \ function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result]                 __copy_from_user(register_base, s + other, offset);                 ^~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In addition, the get_user()/put_user() helpers do not enforce a return value check, but actually still require one. These have been missing for even longer. Change the internal wrappers around get_user()/put_user() to force a signal and add a corresponding wrapper around __copy_from_user() to check all such cases. [ bp: Break long lines. ] Fixes: 257e458057e5 ("Import 2.1.73") Fixes: 9dd819a15162 ("uaccess: add missing __must_check attributes") Signed-off-by: Arnd Bergmann Signed-off-by: Borislav Petkov Reviewed-by: Kees Cook Cc: "H. Peter Anvin" Cc: Bill Metzenthen Cc: Ingo Molnar Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20191001142344.1274185-1-arnd@arndb.de Signed-off-by: Sasha Levin commit fbeec1d0e552662539a1b72e2530a7006bd677fa Author: Allen Pais Date: Wed Sep 18 22:00:31 2019 +0530 drm/amdkfd: fix a potential NULL pointer dereference (v2) [ Upstream commit 81de29d842ccb776c0f77aa3e2b11b07fff0c0e2 ] alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. v2 (Felix Kuehling): * Fix compile error (kfifo_free instead of fifo_free) * Return proper error code Signed-off-by: Allen Pais Reviewed-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 3516e9d1ef00977854a51693ced49617e7341e96 Author: Jagan Teki Date: Thu Oct 3 12:15:21 2019 +0530 drm/sun4i: dsi: Fix TCON DRQ set bits [ Upstream commit 7ac6269968826f9cad61b501bb613cc5cadb7229 ] The LCD timing definitions between Linux DRM vs Allwinner are different, below diagram shows this clear differences. Active Front Sync Back Region Porch Porch <-----------------------><----------------><--------------><--------------> //////////////////////| ////////////////////// | ////////////////////// |.................. ................ ________________ <----- [hv]display -----> <------------- [hv]sync_start ------------> <--------------------- [hv]sync_end ----------------------> <-------------------------------- [hv]total ------------------------------> <----- lcd_[xy] --------> <- lcd_[hv]spw -> <---------- lcd_[hv]bp ---------> <-------------------------------- lcd_[hv]t ------------------------------> The DSI driver misinterpreted the hbp term from the BSP code to refer only to the backporch, when in fact it was backporch + sync. Thus the driver incorrectly used the horizontal front porch plus sync in its calculation of the DRQ set bit value, when it should not have included the sync timing. Including additional sync timings leads to flip_done timed out as: WARNING: CPU: 0 PID: 31 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0 [CRTC:46:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted 5.1.0-next-20190514-00026-g01f0c75b902d-dirty #13 Hardware name: Allwinner sun8i Family Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x84/0x98) [] (dump_stack) from [] (__warn+0xfc/0x114) [] (__warn) from [] (warn_slowpath_fmt+0x44/0x68) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x298/0x2a0) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (drm_atomic_helper_commit_tail_rpm+0x5c/0x6c) [] (drm_atomic_helper_commit_tail_rpm) from [] (commit_tail+0x40/0x6c) [] (commit_tail) from [] (drm_atomic_helper_commit+0xbc/0x128) [] (drm_atomic_helper_commit) from [] (restore_fbdev_mode_atomic+0x1cc/0x1dc) [] (restore_fbdev_mode_atomic) from [] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) [] (drm_fb_helper_restore_fbdev_mode_unlocked) from [] (drm_fb_helper_set_par+0x30/0x54) [] (drm_fb_helper_set_par) from [] (fbcon_init+0x560/0x5ac) [] (fbcon_init) from [] (visual_init+0xbc/0x104) [] (visual_init) from [] (do_bind_con_driver+0x1b0/0x390) [] (do_bind_con_driver) from [] (do_take_over_console+0x13c/0x1c4) [] (do_take_over_console) from [] (do_fbcon_takeover+0x74/0xcc) [] (do_fbcon_takeover) from [] (notifier_call_chain+0x44/0x84) [] (notifier_call_chain) from [] (__blocking_notifier_call_chain+0x48/0x60) [] (__blocking_notifier_call_chain) from [] (blocking_notifier_call_chain+0x18/0x20) [] (blocking_notifier_call_chain) from [] (register_framebuffer+0x1e0/0x2f8) [] (register_framebuffer) from [] (__drm_fb_helper_initial_config_and_unlock+0x2fc/0x50c) [] (__drm_fb_helper_initial_config_and_unlock) from [] (drm_fbdev_client_hotplug+0xe8/0x1b8) [] (drm_fbdev_client_hotplug) from [] (drm_fbdev_generic_setup+0x88/0x118) [] (drm_fbdev_generic_setup) from [] (sun4i_drv_bind+0x128/0x160) [] (sun4i_drv_bind) from [] (try_to_bring_up_master+0x164/0x1a0) [] (try_to_bring_up_master) from [] (__component_add+0x94/0x140) [] (__component_add) from [] (sun6i_dsi_probe+0x144/0x234) [] (sun6i_dsi_probe) from [] (platform_drv_probe+0x48/0x9c) [] (platform_drv_probe) from [] (really_probe+0x1dc/0x2c8) [] (really_probe) from [] (driver_probe_device+0x60/0x160) [] (driver_probe_device) from [] (bus_for_each_drv+0x74/0xb8) [] (bus_for_each_drv) from [] (__device_attach+0xd0/0x13c) [] (__device_attach) from [] (bus_probe_device+0x84/0x8c) [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x90) [] (deferred_probe_work_func) from [] (process_one_work+0x204/0x420) [] (process_one_work) from [] (worker_thread+0x274/0x5a0) [] (worker_thread) from [] (kthread+0x11c/0x14c) [] (kthread) from [] (ret_from_fork+0x14/0x2c) Exception stack(0xde539fb0 to 0xde539ff8) 9fa0: 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---[ end trace b57eb1e5c64c6b8b ]--- random: fast init done [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:46:crtc-0] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:48:DSI-1] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:30:plane-0] flip_done timed out With the terms(as described in above diagram) fixed, the panel displays correctly without any timeouts. Tested-by: Merlijn Wajer Signed-off-by: Jagan Teki Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20191003064527.15128-2-jagan@amarulasolutions.com Signed-off-by: Sasha Levin commit f739a699db7d5a5cf39ca3ce2c84e4fe4a8f4c5d Author: Will Deacon Date: Wed Oct 2 13:42:06 2019 +0100 pinctrl: devicetree: Avoid taking direct reference to device name string [ Upstream commit be4c60b563edee3712d392aaeb0943a768df7023 ] When populating the pinctrl mapping table entries for a device, the 'dev_name' field for each entry is initialised to point directly at the string returned by 'dev_name()' for the device and subsequently used by 'create_pinctrl()' when looking up the mappings for the device being probed. This is unreliable in the presence of calls to 'dev_set_name()', which may reallocate the device name string leaving the pinctrl mappings with a dangling reference. This then leads to a use-after-free every time the name is dereferenced by a device probe: | BUG: KASAN: invalid-access in strcmp+0x20/0x64 | Read of size 1 at addr 13ffffc153494b00 by task modprobe/590 | Pointer tag: [13], memory tag: [fe] | | Call trace: | __kasan_report+0x16c/0x1dc | kasan_report+0x10/0x18 | check_memory_region | __hwasan_load1_noabort+0x4c/0x54 | strcmp+0x20/0x64 | create_pinctrl+0x18c/0x7f4 | pinctrl_get+0x90/0x114 | devm_pinctrl_get+0x44/0x98 | pinctrl_bind_pins+0x5c/0x450 | really_probe+0x1c8/0x9a4 | driver_probe_device+0x120/0x1d8 Follow the example of sysfs, and duplicate the device name string before stashing it away in the pinctrl mapping entries. Cc: Linus Walleij Reported-by: Elena Petrova Tested-by: Elena Petrova Signed-off-by: Will Deacon Link: https://lore.kernel.org/r/20191002124206.22928-1-will@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 19378ed7eb3a7649dc62502a776b6b3eb3054066 Author: Nikola Cornij Date: Wed Aug 28 18:30:43 2019 -0400 drm/amd/display: Set number of pipes to 1 if the second pipe was disabled [ Upstream commit 2fef0faa1cdc5d41ce3ef83f7b8f7e7ecb02d700 ] [why] Some ODM-related register settings are inconsistently updated by VBIOS, causing the state in DC to be invalid, which would then end up crashing in certain use-cases (such as disable/enable device). [how] Check the enabled status of the second pipe when determining the number of OPTC sources. If the second pipe is disabled, set the number of sources to 1 regardless of other settings (that may not be updated correctly). Signed-off-by: Nikola Cornij Reviewed-by: Dmytro Laktyushkin Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f780e4ace1eda3caaa21b80cbf3abd7152c9d563 Author: Shuah Khan Date: Tue Sep 17 13:35:09 2019 -0300 media: vimc: Fix gpf in rmmod path when stream is active [ Upstream commit d7fb5c361c2a2666d20e044206e1756bc8e87df2 ] If vimc module is removed while streaming is in progress, sensor subdev unregister runs into general protection fault when it tries to unregister media entities. This is a common subdev problem related to releasing pads from v4l2_device_unregister_subdev() before calling unregister. Unregister references pads during unregistering subdev. The sd release handler is the right place for releasing all sd resources including pads. The release handlers currently release all resources except the pads. Fix v4l2_device_unregister_subdev() not release pads and release pads from the sd_int_op release handlers. kernel: [ 4136.715839] general protection fault: 0000 [#1] SMP PTI kernel: [ 4136.715847] CPU: 2 PID: 1972 Comm: bash Not tainted 5.3.0-rc2+ #4 kernel: [ 4136.715850] Hardware name: Dell Inc. OptiPlex 790/0HY9JP, BIOS A18 09/24/2013 kernel: [ 4136.715858] RIP: 0010:media_gobj_destroy.part.16+0x1f/0x60 kernel: [ 4136.715863] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 89 fe 48 89 e5 53 48 89 fb 48 c7 c7 00 7f cf b0 e8 24 fa ff ff 48 8b 03 <48> 83 80 a0 00 00 00 01 48 8b 43 18 48 8b 53 10 48 89 42 08 48 89 kernel: [ 4136.715866] RSP: 0018:ffff9b2248fe3cb0 EFLAGS: 00010246 kernel: [ 4136.715870] RAX: bcf2bfbfa0d63c2f RBX: ffff88c3eb37e9c0 RCX: 00000000802a0018 kernel: [ 4136.715873] RDX: ffff88c3e4f6a078 RSI: ffff88c3eb37e9c0 RDI: ffffffffb0cf7f00 kernel: [ 4136.715876] RBP: ffff9b2248fe3cb8 R08: 0000000001000002 R09: ffffffffb0492b00 kernel: [ 4136.715879] R10: ffff9b2248fe3c28 R11: 0000000000000001 R12: 0000000000000038 kernel: [ 4136.715881] R13: ffffffffc09a1628 R14: ffff88c3e4f6a028 R15: fffffffffffffff2 kernel: [ 4136.715885] FS: 00007f8389647740(0000) GS:ffff88c465500000(0000) knlGS:0000000000000000 kernel: [ 4136.715888] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: [ 4136.715891] CR2: 000055d008f80fd8 CR3: 00000001996ec005 CR4: 00000000000606e0 kernel: [ 4136.715894] Call Trace: kernel: [ 4136.715903] media_gobj_destroy+0x14/0x20 kernel: [ 4136.715908] __media_device_unregister_entity+0xb3/0xe0 kernel: [ 4136.715915] media_device_unregister_entity+0x30/0x40 kernel: [ 4136.715920] v4l2_device_unregister_subdev+0xa8/0xe0 kernel: [ 4136.715928] vimc_ent_sd_unregister+0x1e/0x30 [vimc] kernel: [ 4136.715933] vimc_sen_rm+0x16/0x20 [vimc] kernel: [ 4136.715938] vimc_remove+0x3e/0xa0 [vimc] kernel: [ 4136.715945] platform_drv_remove+0x25/0x50 kernel: [ 4136.715951] device_release_driver_internal+0xe0/0x1b0 kernel: [ 4136.715956] device_driver_detach+0x14/0x20 kernel: [ 4136.715960] unbind_store+0xd1/0x130 kernel: [ 4136.715965] drv_attr_store+0x27/0x40 kernel: [ 4136.715971] sysfs_kf_write+0x48/0x60 kernel: [ 4136.715976] kernfs_fop_write+0x128/0x1b0 kernel: [ 4136.715982] __vfs_write+0x1b/0x40 kernel: [ 4136.715987] vfs_write+0xc3/0x1d0 kernel: [ 4136.715993] ksys_write+0xaa/0xe0 kernel: [ 4136.715999] __x64_sys_write+0x1a/0x20 kernel: [ 4136.716005] do_syscall_64+0x5a/0x130 kernel: [ 4136.716010] entry_SYSCALL_64_after_hwframe+0x4 Signed-off-by: Shuah Khan Acked-by: Helen Koike Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 4b1bbce9c330dd7e1d88f04e5a001ed17c8f7a1f Author: Ben Greear Date: Tue Oct 17 17:03:12 2017 -0700 ath10k: fix offchannel tx failure when no ath10k_mac_tx_frm_has_freq [ Upstream commit cc6df017e55764ffef9819dd9554053182535ffd ] Offchannel management frames were failing: [18099.253732] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18102.293686] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18105.333653] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18108.373712] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3780 [18111.413687] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18114.453726] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 [18117.493773] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e36c0 [18120.533631] ath10k_pci 0000:01:00.0: timed out waiting for offchannel skb cf0e3f00 This bug appears to have been added between 4.0 (which works for us), and 4.4, which does not work. I think this is because the tx-offchannel logic gets in a loop when ath10k_mac_tx_frm_has_freq(ar) is false, so pkt is never actually sent to the firmware for transmit. This patch fixes the problem on 4.9 for me, and now HS20 clients can work again with my firmware. Antonio: tested with 10.4-3.5.3-00057 on QCA4019 and QCA9888 Signed-off-by: Ben Greear Tested-by: Antonio Quartulli [kvalo@codeaurora.org: improve commit log, remove unneeded parenthesis] Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 3d0f01ba35974641ce22c769f13811bdd6313c27 Author: Loic Poulain Date: Wed Sep 11 11:45:59 2019 -0300 media: venus: core: Fix msm8996 frequency table [ Upstream commit c690435ed07901737e5c007a65ec59f53b33eb71 ] In downstream driver, there are two frequency tables defined, one for the encoder and one for the decoder: /* Encoders / <972000 490000000 0x55555555>, / 4k UHD @ 30 / <489600 320000000 0x55555555>, / 1080p @ 60 / <244800 150000000 0x55555555>, / 1080p @ 30 / <108000 75000000 0x55555555>, / 720p @ 30 */ /* Decoders / <1944000 490000000 0xffffffff>, / 4k UHD @ 60 / < 972000 320000000 0xffffffff>, / 4k UHD @ 30 / < 489600 150000000 0xffffffff>, / 1080p @ 60 / < 244800 75000000 0xffffffff>; / 1080p @ 30 */ It shows that encoder always needs a higher clock than decoder. In current venus driver, the unified frequency table is aligned with the downstream decoder table which causes performance issues in encoding scenarios. Fix that by aligning frequency table on worst case (encoding). Signed-off-by: Loic Poulain Signed-off-by: Stanimir Varbanov Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d6bf6a5e904f2728fd9e86a925e7186be96dc717 Author: Nathan Chancellor Date: Fri Sep 27 09:26:42 2019 -0700 tools/power/cpupower: Fix initializer override in hsw_ext_cstates [ Upstream commit 7e5705c635ecfccde559ebbbe1eaf05b5cc60529 ] When building cpupower with clang, the following warning appears: utils/idle_monitor/hsw_ext_idle.c:42:16: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] .desc = N_("Processor Package C2"), ^~~~~~~~~~~~~~~~~~~~~~ ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_' #define N_(String) gettext_noop(String) ^~~~~~ ./utils/helpers/helpers.h:23:30: note: expanded from macro 'gettext_noop' #define gettext_noop(String) String ^~~~~~ utils/idle_monitor/hsw_ext_idle.c:41:16: note: previous initialization is here .desc = N_("Processor Package C9"), ^~~~~~~~~~~~~~~~~~~~~~ ./utils/helpers/helpers.h:25:33: note: expanded from macro 'N_' #define N_(String) gettext_noop(String) ^~~~~~ ./utils/helpers/helpers.h:23:30: note: expanded from macro 'gettext_noop' #define gettext_noop(String) String ^~~~~~ 1 warning generated. This appears to be a copy and paste or merge mistake because the name and id fields both have PC9 in them, not PC2. Remove the second assignment to fix the warning. Fixes: 7ee767b69b68 ("cpupower: Add Haswell family 0x45 specific idle monitor to show PC8,9,10 states") Link: https://github.com/ClangBuiltLinux/linux/issues/718 Signed-off-by: Nathan Chancellor Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 7853f665fbf0e2daf666bbb5ac19cd063f4ed21a Author: Janusz Krzysztofik Date: Tue Sep 3 17:11:44 2019 -0300 media: ov6650: Fix stored crop rectangle not in sync with hardware [ Upstream commit 1463b371aff0682c70141f7521db13cc4bbf3016 ] The driver stores crop rectangle settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, crop rectangle width and height settings are not updated correctly when rectangle offset settings are applied on hardware. If an error occurs while the device is updated, the stored settings my no longer reflect hardware state and consecutive calls to .get_selection() as well as .get/set_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informamtion on active frame format returned by .get/set_fmt() is used. Assuming a failed update of the device means its actual settings haven't changed, update crop rectangle width and height settings stored in the device private structure correctly while the rectangle offset is successfully applied on hardware so the stored values always reflect actual hardware state to the extent possible. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 11e2bcfabe5373a828d99bdba839e2a65f4390a1 Author: Janusz Krzysztofik Date: Tue Sep 3 17:11:43 2019 -0300 media: ov6650: Fix stored frame format not in sync with hardware [ Upstream commit 3143b459de4cdcce67b36827476c966e93c1cf01 ] The driver stores frame format settings supposed to be in line with hardware state in a device private structure. Since the driver initial submission, those settings are updated before they are actually applied on hardware. If an error occurs on device update, the stored settings my not reflect hardware state anymore and consecutive calls to .get_fmt() may return incorrect information. That in turn may affect ability of a bridge device to use correct DMA transfer settings if such incorrect informmation on active frame format returned by .get_fmt() is used. Assuming a failed device update means its state hasn't changed, update frame format related settings stored in the device private structure only after they are successfully applied so the stored values always reflect hardware state as closely as possible. Fixes: 2f6e2404799a ("[media] SoC Camera: add driver for OV6650 sensor") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 00e42271263a6c0cfc9130532226632d6e57d65f Author: Benoit Parrot Date: Mon Sep 30 10:06:43 2019 -0300 media: i2c: ov2659: Fix missing 720p register config [ Upstream commit 9d669fbfca20e6035ead814e55d9ef1a6b500540 ] The initial registers sequence is only loaded at probe time. Afterward only the resolution and format specific register are modified. Care must be taken to make sure registers modified by one resolution setting are reverted back when another resolution is programmed. This was not done properly for the 720p case. Signed-off-by: Benoit Parrot Acked-by: Lad, Prabhakar Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 58090ce579676e52a85a708158e063beb42f435d Author: Janusz Krzysztofik Date: Tue Sep 3 17:11:38 2019 -0300 media: ov6650: Fix crop rectangle alignment not passed back [ Upstream commit 7b188d6ba27a131e7934a51a14ece331c0491f18 ] Commit 4f996594ceaf ("[media] v4l2: make vidioc_s_crop const") introduced a writable copy of constified user requested crop rectangle in order to be able to perform hardware alignments on it. Later on, commit 10d5509c8d50 ("[media] v4l2: remove g/s_crop from video ops") replaced s_crop() video operation using that const argument with set_selection() pad operation which had a corresponding argument not constified, however the original behavior of the driver was not restored. Since that time, any hardware alignment applied on a user requested crop rectangle is not passed back to the user calling .set_selection() as it should be. Fix the issue by dropping the copy and replacing all references to it with references to the crop rectangle embedded in the user argument. Fixes: 10d5509c8d50 ("[media] v4l2: remove g/s_crop from video ops") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 8caa2ee295df46fed0231fd89aabcbaa7bf80722 Author: Benoit Parrot Date: Mon Sep 30 10:06:40 2019 -0300 media: i2c: ov2659: fix s_stream return value [ Upstream commit 85c4043f1d403c222d481dfc91846227d66663fb ] In ov2659_s_stream() return value for invoked function should be checked and propagated. Signed-off-by: Benoit Parrot Acked-by: Lad, Prabhakar Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit e88e1d28beb37948dddfe80514eb1c163d9cb343 Author: Janusz Krzysztofik Date: Tue Sep 3 17:11:37 2019 -0300 media: ov6650: Fix control handler not freed on init error [ Upstream commit c404af950d14b71bfbf574a752b6c29d726baaba ] Since commit afd9690c72c3 ("[media] ov6650: convert to the control framework"), if an error occurs during initialization of a control handler, resources possibly allocated to the handler are not freed before device initialiaton is aborted. Fix it. Fixes: afd9690c72c3 ("[media] ov6650: convert to the control framework") Signed-off-by: Janusz Krzysztofik Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit bad7c2c5db63f3856bc7dc6d208254519ee2a1ea Author: YueHaibing Date: Tue Sep 3 09:09:45 2019 -0300 media: max2175: Fix build error without CONFIG_REGMAP_I2C [ Upstream commit 36756fbff1e4a31d71d262ae6a04a20b38efa874 ] If CONFIG_REGMAP_I2C is not set, building fails: drivers/media/i2c/max2175.o: In function `max2175_probe': max2175.c:(.text+0x1404): undefined reference to `__devm_regmap_init_i2c' Select REGMAP_I2C to fix this. Reported-by: Hulk Robot Fixes: b47b79d8a231 ("[media] media: i2c: max2175: Add MAX2175 support") Signed-off-by: YueHaibing Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 0f6b1bdbec72a28a08ab11a11007db8fcca970b5 Author: Kefeng Wang Date: Sun Sep 8 01:12:54 2019 -0300 media: vim2m: Fix BUG_ON in vim2m_device_release() [ Upstream commit 2455d417c03aa0cbafed04c46cbb354643238318 ] If v4l2_m2m_init() fails, m2m_dev pointer will be set ERR_PTR(-ENOMEM), then kfree m2m_dev will trigger BUG_ON, see below, fix it by setting m2m_dev to NULL. vim2m vim2m.0: Failed to init mem2mem device ------------[ cut here ]------------ kernel BUG at mm/slub.c:3944! invalid opcode: 0000 [#1] SMP PTI CPU: 11 PID: 9061 Comm: insmod Tainted: G E 5.2.0-rc2 #81 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:kfree+0x11a/0x160 Call Trace: vim2m_device_release+0x3f/0x50 [vim2m] device_release+0x27/0x80 kobject_release+0x68/0x190 vim2m_probe+0x20f/0x280 [vim2m] platform_drv_probe+0x37/0x90 really_probe+0xef/0x3d0 driver_probe_device+0x110/0x120 device_driver_attach+0x4f/0x60 __driver_attach+0x9a/0x140 ? device_driver_attach+0x60/0x60 bus_for_each_dev+0x76/0xc0 ? klist_add_tail+0x57/0x70 bus_add_driver+0x141/0x210 driver_register+0x5b/0xe0 vim2m_init+0x29/0x1000 [vim2m] do_one_initcall+0x46/0x1f4 ? __slab_alloc+0x1c/0x30 ? kmem_cache_alloc_trace+0x167/0x1b0 do_init_module+0x5b/0x21f load_module+0x1add/0x1fb0 ? __do_sys_finit_module+0xe9/0x110 __do_sys_finit_module+0xe9/0x110 do_syscall_64+0x5b/0x1c0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: ea6c7e34f3b2 ("media: vim2m: replace devm_kzalloc by kzalloc") Reported-by: Hulk Robot Cc: Laurent Pinchart Signed-off-by: Kefeng Wang Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3066c2aaadb6276e46a21a2295ffcbf7a2f7b1c8 Author: Jernej Skrabec Date: Thu Sep 12 15:55:55 2019 -0300 media: vim2m: Fix abort issue [ Upstream commit c362f77a243bfd1daec21b6c36491c061ee2f31b ] Currently, if start streaming -> stop streaming -> start streaming sequence is executed, driver will end job prematurely, if ctx->translen is higher than 1, because "aborting" flag is still set from previous stop streaming command. Fix that by clearing "aborting" flag in start streaming handler. Fixes: 96d8eab5d0a1 ("V4L/DVB: [v5,2/2] v4l: Add a mem-to-mem videobuf framework test device") Signed-off-by: Jernej Skrabec Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 7fcebd2721a8be40abd0abc4cff9fa3249fb07e5 Author: Christophe JAILLET Date: Sat Aug 31 03:42:58 2019 -0300 media: seco-cec: Add a missing 'release_region()' in an error handling path [ Upstream commit a9cc4cbcdfd378b65fd4e398800cfa14e3855042 ] At the beginning of the probe function, we have a call to 'request_muxed_region(BRA_SMB_BASE_ADDR, 7, "CEC00001")()' A corresponding 'release_region()' is performed in the remove function but is lacking in the error handling path. Add it. Fixes: b03c2fb97adc ("media: add SECO cec driver") Signed-off-by: Christophe JAILLET Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 3450dd47043707f88c0046d2b56018cfe1555c28 Author: Hans Verkuil Date: Fri Aug 30 06:26:22 2019 -0300 media: cedrus: fill in bus_info for media device [ Upstream commit ae0688f659adb17ae6ae5710c886b20b5406e5c4 ] Fixes this compliance warning: $ v4l2-compliance -m0 v4l2-compliance SHA: b514d615166bdc0901a4c71261b87db31e89f464, 32 bits Compliance test for cedrus device /dev/media0: Media Driver Info: Driver name : cedrus Model : cedrus Serial : Bus info : Media version : 5.3.0 Hardware revision: 0x00000000 (0) Driver version : 5.3.0 Required ioctls: warn: v4l2-test-media.cpp(51): empty bus_info test MEDIA_IOC_DEVICE_INFO: OK Signed-off-by: Hans Verkuil Reviewed-by: Jernej Skrabec Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 95206abb46b72b780a6e82cbef70a9f8c116b41f Author: Benoit Parrot Date: Fri Sep 20 14:05:48 2019 -0300 media: am437x-vpfe: Setting STD to current value is not an error [ Upstream commit 13aa21cfe92ce9ebb51824029d89f19c33f81419 ] VIDIOC_S_STD should not return an error if the value is identical to the current one. This error was highlighted by the v4l2-compliance test. Signed-off-by: Benoit Parrot Acked-by: Lad Prabhakar Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit d7bb7d20a8bac687c16838f2b7b5629d595512d1 Author: Navid Emamdoost Date: Mon Sep 30 15:52:40 2019 -0500 spi: gpio: prevent memory leak in spi_gpio_probe [ Upstream commit d3b0ffa1d75d5305ebe34735598993afbb8a869d ] In spi_gpio_probe an SPI master is allocated via spi_alloc_master, but this controller should be released if devm_add_action_or_reset fails, otherwise memory leaks. In order to avoid leak spi_contriller_put must be called in case of failure for devm_add_action_or_reset. Fixes: 8b797490b4db ("spi: gpio: Make sure spi_master_put() is called in every error path") Signed-off-by: Navid Emamdoost Link: https://lore.kernel.org/r/20190930205241.5483-1-navid.emamdoost@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3e9ffd6a39907d79f568c9336e34056700291b30 Author: Mihail Atanassov Date: Tue Oct 1 14:21:40 2019 +0000 drm/komeda: Workaround for broken FLIP_COMPLETE timestamps [ Upstream commit f59769c52cd7d158df53487ec2936f5592073340 ] When initially turning a crtc on, drm_reset_vblank_timestamp will set the vblank timestamp to 0 for any driver that doesn't provide a ->get_vblank_timestamp() hook. Unfortunately, the FLIP_COMPLETE event depends on that timestamp, and the only way to regenerate a valid one is to have vblank interrupts enabled and have a valid in-ISR call to drm_crtc_handle_vblank. Additionally, if the user doesn't request vblanks but _does_ request FLIP_COMPLETE events, we still don't have a good timestamp: it'll be the same stamp as the last vblank one. Work around the issue by always enabling vblanks when the CRTC is on. Reducing the amount of time that PL0 has to be unmasked would be nice to fix at a later time. Changes since v1 [https://patchwork.freedesktop.org/patch/331727/]: - moved drm_crtc_vblank_put call to the ->atomic_disable() hook Cc: Daniel Vetter Cc: Liviu Dudau Signed-off-by: Mihail Atanassov Reviewed-by: James Qian Wang (Arm Technology China) Signed-off-by: Ayan kumar halder Link: https://patchwork.freedesktop.org/patch/msgid/20191001142121.13939-1-mihail.atanassov@arm.com Signed-off-by: Sasha Levin commit 7971a6e124ddfc9502af4b4e22299126fa7f83bb Author: Max Gurtovoy Date: Wed Sep 25 00:03:47 2019 +0300 IB/iser: bound protection_sg size by data_sg size [ Upstream commit 7718cf03c3ce4b6ebd90107643ccd01c952a1fce ] In case we don't set the sg_prot_tablesize, the scsi layer assign the default size (65535 entries). We should limit this size since we should take into consideration the underlaying device capability. This cap is considered when calculating the sg_tablesize. Otherwise, for example, we can get that /sys/block/sdb/queue/max_segments is 128 and /sys/block/sdb/queue/max_integrity_segments is 65535. Link: https://lore.kernel.org/r/1569359027-10987-1-git-send-email-maxg@mellanox.com Signed-off-by: Max Gurtovoy Reviewed-by: Sagi Grimberg Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 8ebd637dd9d8ad0cbb013bd97c379bb2547b830a Author: Anilkumar Kolli Date: Thu Sep 26 19:07:01 2019 +0530 ath10k: fix backtrace on coredump [ Upstream commit d98ddae85a4a57124f87960047b1b6419312147f ] In a multiradio board with one QCA9984 and one AR9987 after enabling the crashdump with module parameter coredump_mask=7, below backtrace is seen. vmalloc: allocation failure: 0 bytes kworker/u4:0: page allocation failure: order:0, mode:0x80d2 CPU: 0 PID: 6 Comm: kworker/u4:0 Not tainted 3.14.77 #130 Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core] (unwind_backtrace) from [] (show_stack+0x10/0x14) (dump_stack+0x80/0xa0) (warn_alloc_failed+0xd0/0xfc) (__vmalloc_node_range+0x1b4/0x1d8) (__vmalloc_node+0x34/0x40) (vzalloc+0x24/0x30) (ath10k_coredump_register+0x6c/0x88 [ath10k_core]) (ath10k_core_register_work+0x350/0xb34 [ath10k_core]) (process_one_work+0x20c/0x32c) (worker_thread+0x228/0x360) This is due to ath10k_hw_mem_layout is not defined for AR9987. For coredump undefined hw ramdump_size is 0. Check for the ramdump_size before allocation memory. Tested on: AR9987, QCA9984 FW version: 10.4-3.9.0.2-00044 Signed-off-by: Anilkumar Kolli Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 88b434d53a56680301ef2164e17377baf70ec25b Author: Geert Uytterhoeven Date: Wed Sep 4 14:16:58 2019 +0200 Revert "pinctrl: sh-pfc: r8a77990: Fix MOD_SEL1 bit31 when using SIM0_D" [ Upstream commit 7666dfd533d4c55733037775d47a8e3551b341a2 ] This reverts commit e167d723e1a472d252e5c4baf823b77ce5543b05. According to the R-Car Gen3 Hardware Manual Errata for Rev 1.00 of Aug 24, 2018, the SEL_SIMCARD_{0,1} definition was to be deleted. However, this errata merely fixed an accidental double definition in the Hardware User's Manual Rev. 1.00. The real definition is still present in later revisions of the manual (Rev. 1.50 and Rev. 2.00). Hence revert the commit to recover the definition. Based on a patch in the BSP by Takeshi Kihara . Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20190904121658.2617-4-geert+renesas@glider.be Signed-off-by: Sasha Levin commit a6bcd13cc4d4bb8201c746562a83f50545b51644 Author: Geert Uytterhoeven Date: Wed Sep 4 14:16:57 2019 +0200 Revert "pinctrl: sh-pfc: r8a77990: Fix MOD_SEL1 bit30 when using SSI_SCK2 and SSI_WS2" [ Upstream commit 3672bc7093434621c83299ef27ea3b3225a67600 ] This reverts commit e87882eb9be10b2b9e28156922c2a47d877f5db4. According to the R-Car Gen3 Hardware Manual Errata for Rev 1.00 of Aug 24, 2018, the SEL_SSI2_{0,1} definition was to be deleted. However, this errata merely fixed an accidental double definition in the Hardware User's Manual Rev. 1.00. The real definition is still present in later revisions of the manual (Rev. 1.50 and Rev. 2.00). Hence revert the commit to recover the definition. Based on a patch in the BSP by Takeshi Kihara . Signed-off-by: Geert Uytterhoeven Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20190904121658.2617-3-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 6ab523073f222e2e3a4545cbe436ef94a33bffff Author: Allen Pais Date: Wed Sep 18 22:05:00 2019 +0530 libertas: fix a potential NULL pointer dereference [ Upstream commit 7da413a18583baaf35dd4a8eb414fa410367d7f2 ] alloc_workqueue is not checked for errors and as a result, a potential NULL dereference could occur. Signed-off-by: Allen Pais Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 39a974f8970268e7a02933e5cd6fab3e2dd8228e Author: Navid Emamdoost Date: Tue Sep 24 20:20:21 2019 -0500 rtlwifi: prevent memory leak in rtl_usb_probe [ Upstream commit 3f93616951138a598d930dcaec40f2bfd9ce43bb ] In rtl_usb_probe if allocation for usb_data fails the allocated hw should be released. In addition the allocated rtlpriv->usb_data should be released on error handling path. Signed-off-by: Navid Emamdoost Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit d8c47cad1263e77b2b68ad5f8067aa40b5407ee5 Author: Connor Kuehl Date: Thu Sep 26 08:03:17 2019 -0700 staging: rtl8188eu: fix possible null dereference [ Upstream commit 228241944a48113470d3c3b46c88ba7fbe0a274b ] Inside a nested 'else' block at the beginning of this function is a call that assigns 'psta' to the return value of 'rtw_get_stainfo()'. If 'rtw_get_stainfo()' returns NULL and the flow of control reaches the 'else if' where 'psta' is dereferenced, then we will dereference a NULL pointer. Fix this by checking if 'psta' is not NULL before reading its 'psta->qos_option' data member. Addresses-Coverity: ("Dereference null return value") Signed-off-by: Connor Kuehl Acked-by: Larry Finger Link: https://lore.kernel.org/r/20190926150317.5894-1-connor.kuehl@canonical.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 29d575fe1786efe12d60554bc96c0bd5ecae74e6 Author: Navid Emamdoost Date: Thu Sep 19 21:51:33 2019 -0500 staging: rtl8192u: fix multiple memory leaks on error path [ Upstream commit ca312438cf176a16d4b89350cade8789ba8d7133 ] In rtl8192_tx on error handling path allocated urbs and also skb should be released. Signed-off-by: Navid Emamdoost Link: https://lore.kernel.org/r/20190920025137.29407-1-navid.emamdoost@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f2331974af2ffe69975bebfa787eb70c55665e83 Author: Neil Armstrong Date: Wed Aug 28 15:23:11 2019 +0200 drm/meson: vclk: use the correct G12A frac max value [ Upstream commit d56276a13c2b9ea287b9fc7cc78bed4c43b286f9 ] When calculating the HDMI PLL settings for a DMT mode PHY frequency, use the correct max fractional PLL value for G12A VPU. With this fix, we can finally setup the 1024x768-60 mode. Fixes: 202b9808f8ed ("drm/meson: Add G12A Video Clock setup") Signed-off-by: Neil Armstrong Reviewed-by: Kevin Hilman Link: https://patchwork.freedesktop.org/patch/msgid/20190828132311.23881-1-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit a3a547e8df75d71634f9de8a6da2245d8a203ded Author: Lukasz Majewski Date: Wed Sep 25 11:11:42 2019 +0200 spi: Add call to spi_slave_abort() function when spidev driver is released [ Upstream commit 9f918a728cf86b2757b6a7025e1f46824bfe3155 ] This change is necessary for spidev devices (e.g. /dev/spidev3.0) working in the slave mode (like NXP's dspi driver for Vybrid SoC). When SPI HW works in this mode - the master is responsible for providing CS and CLK signals. However, when some fault happens - like for example distortion on SPI lines - the SPI Linux driver needs a chance to recover from this abnormal situation and prepare itself for next (correct) transmission. This change doesn't pose any threat on drivers working in master mode as spi_slave_abort() function checks if SPI slave mode is supported. Signed-off-by: Lukasz Majewski Link: https://lore.kernel.org/r/20190924110547.14770-2-lukma@denx.de Signed-off-by: Mark Brown Reported-by: kbuild test robot Link: https://lore.kernel.org/r/20190925091143.15468-2-lukma@denx.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c0dcfa7f8ead06a0e54b3ee625e05d675f9d58e7 Author: Hauke Mehrtens Date: Sun Aug 18 21:09:20 2019 +0200 ath10k: Check if station exists before forwarding tx airtime report [ Upstream commit b10f32672946ad638a430cc4289029b7acf8e979 ] It looks like the FW on QCA9984 already reports the tx airtimes before the station is added to the peer entry. The peer entry is created in ath10k_peer_map_event() just with the vdev_id and the ethaddr, but not with a station entry, this is added later in ath10k_peer_create() in callbacks from mac80211. When there is no sta added to the peer entry, this function fails because it calls ieee80211_sta_register_airtime() with NULL. This was reported in OpenWrt some time ago: https://bugs.openwrt.org/index.php?do=details&task_id=2414 This commit should fix this crash: [ 75.991714] Unable to handle kernel paging request at virtual address fffff9e8 [ 75.991756] pgd = c0204000 [ 75.997955] [fffff9e8] *pgd=5fdfd861, *pte=00000000, *ppte=00000000 [ 76.000537] Internal error: Oops: 37 [#1] SMP ARM [ 76.006686] Modules linked in: pppoe ppp_async ath10k_pci ath10k_core ath pptp pppox ppp_mppe ppp_generic mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY usbserial slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt compat chaoskey fuse sch_cake sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32 [ 76.059974] cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6t_NPT ip6t_MASQUERADE nf_nat_masquerade_ipv6 nf_nat nf_conntrack nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos ip_gre gre ifb sit tunnel4 ip_tunnel tun vfat fat hfsplus cifs nls_utf8 nls_iso8859_15 nls_iso8859_1 nls_cp850 nls_cp437 nls_cp1250 sha1_generic md5 md4 [ 76.130634] usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_of_simple ohci_platform ohci_hcd phy_qcom_dwc3 ahci ehci_platform sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 exfat crc32c_generic [ 76.154772] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.132 #0 [ 76.177001] Hardware name: Generic DT based system [ 76.182990] task: c0b06d80 task.stack: c0b00000 [ 76.187832] PC is at ieee80211_sta_register_airtime+0x24/0x148 [mac80211] [ 76.192211] LR is at ath10k_htt_t2h_msg_handler+0x678/0x10f4 [ath10k_core] [ 76.199052] pc : [] lr : [] psr: a0000113 [ 76.205820] sp : c0b01d54 ip : 00000002 fp : bf869c0c [ 76.211981] r10: 0000003c r9 : dbdca138 r8 : 00060002 [ 76.217192] r7 : 00000000 r6 : dabe1150 r5 : 00000000 r4 : dbdc95c0 [ 76.222401] r3 : 00000000 r2 : 00060002 r1 : 00000000 r0 : 00000000 [ 76.229003] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 76.235509] Control: 10c5787d Table: 5c94006a DAC: 00000051 [ 76.242716] Process swapper/0 (pid: 0, stack limit = 0xc0b00210) [ 76.248446] Stack: (0xc0b01d54 to 0xc0b02000) [ 76.254532] 1d40: dbdc95c0 00000000 dabe1150 [ 76.258808] 1d60: 00000001 dabe1150 dbdca138 0000003c bf869c0c bf83e8b0 00000002 c0314b10 [ 76.266969] 1d80: dbdc9c70 00000001 00000001 dabe114c 00010000 00000000 dbdcd724 bf88f3d8 [ 76.275126] 1da0: c0310d28 db393c00 dbdc95c0 00000000 c0b01dd0 c07fb4c4 dbdcd724 00000001 [ 76.283286] 1dc0: 00000022 bf88b09c db393c00 00000022 c0b01dd0 c0b01dd0 00000000 dbdcc5c0 [ 76.291445] 1de0: bf88f04c dbdcd654 dbdcd71c dbdc95c0 00000014 dbdcd724 dbdcc5c0 00000005 [ 76.299605] 1e00: 0004b400 bf85c360 00000000 bf87101c c0b01e24 00000006 00000000 dbdc95c0 [ 76.307764] 1e20: 00000001 00000040 0000012c c0b01e80 1cf51000 bf85c448 dbdcd440 dbdc95c0 [ 76.315925] 1e40: dbdca440 ffffa880 00000040 bf88cb68 dbdcd440 00000001 00000040 ffffa880 [ 76.324084] 1e60: c0b02d00 c06d72e0 dd990080 c0a3f080 c0b255dc c0b047e4 c090afac c090e80c [ 76.332244] 1e80: c0b01e80 c0b01e80 c0b01e88 c0b01e88 dd4cc200 00000000 00000003 c0b0208c [ 76.340405] 1ea0: c0b02080 40000003 ffffe000 00000100 c0b02080 c03015c8 00000000 00000001 [ 76.348564] 1ec0: dd408000 c0a38210 c0b2c7c0 0000000a ffffa880 c0b02d00 c07fb764 00200102 [ 76.356723] 1ee0: dd4cc268 c0a3e414 00000000 00000000 00000001 dd408000 de803000 00000000 [ 76.364883] 1f00: 00000000 c03247cc c0a3e414 c0368f1c c0b03f60 c0b153cc de80200c de802000 [ 76.373042] 1f20: c0b01f48 c0301488 c0308630 60000013 ffffffff c0b01f7c 00000000 c0b00000 [ 76.381204] 1f40: 00000000 c030c08c 00000001 00000000 00000000 c0315180 ffffe000 c0b03cc0 [ 76.389363] 1f60: c0b03c70 00000000 00000000 c0a2da28 00000000 00000000 c0b01f90 c0b01f98 [ 76.397522] 1f80: c030862c c0308630 60000013 ffffffff 00000051 00000000 ffffe000 c035dd18 [ 76.405681] 1fa0: 000000bf c0b03c40 00000000 c0b2c000 dddfce80 c035e060 c0b2c040 c0a00cf4 [ 76.413842] 1fc0: ffffffff ffffffff 00000000 c0a0067c c0a2da28 00000000 00000000 c0b2c1d4 [ 76.422001] 1fe0: c0b03c5c c0a2da24 c0b07ee0 4220406a 512f04d0 4220807c 00000000 00000000 [ 76.430335] [] (ieee80211_sta_register_airtime [mac80211]) from [<00000002>] (0x2) [ 76.438314] Code: e1cd81f0 e1a08002 e1cda1f8 e58de020 (e5102618) [ 76.446965] ---[ end trace 227a38ade964d642 ]--- Fixes: bb31b7cb106c ("ath10k: report tx airtime provided by fw") Signed-off-by: Hauke Mehrtens Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 67a0b5676c3ef2cff151535b395709d7bc379e24 Author: Martin Tsai Date: Thu Aug 22 10:02:13 2019 +0800 drm/amd/display: Handle virtual signal type in disable_link() [ Upstream commit 616f5b65f1c02d3d6ae370644670d14c57de2fd8 ] [Why] The new implementation changed the behavior to allow process setMode to DAL when DAL returns empty mode query for unplugged display. This will trigger additional disable_link(). When unplug HDMI from MST dock, driver will update stream->signal to "Virtual". disable_link() will call disable_output() if the signal type is not DP and induce other displays on MST dock show black screen. [How] Don't need to process disable_output() if the signal type is virtual. Signed-off-by: Martin Tsai Reviewed-by: Charlene Liu Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 56997f310d75c0099ef93d9abafd874496db9020 Author: Wenwen Wang Date: Thu Aug 15 16:04:31 2019 -0500 ath10k: add cleanup in ath10k_sta_state() [ Upstream commit 334f5b61a6f29834e881923b98d1e27e5ce9620d ] If 'sta->tdls' is false, no cleanup is executed, leading to memory/resource leaks, e.g., 'arsta->tx_stats'. To fix this issue, perform cleanup before go to the 'exit' label. Signed-off-by: Wenwen Wang Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit b099752b3b40fd84fa47fd874bf0f068cc99931f Author: Mikita Lipski Date: Fri Aug 23 13:26:24 2019 -0400 drm/amd/display: Rebuild mapped resources after pipe split [ Upstream commit 387596ef2859c37d564ce15abddbc9063a132e2c ] [why] The issue is specific for linux, as on timings such as 8K@60 or 4K@144 DSC should be working in combination with ODM Combine in order to ensure that we can run those timings. The validation for those timings was passing, but when pipe split was happening second pipe wasn't being programmed. [how] Rebuild mapped resources if we split stream for ODM. Signed-off-by: Mikita Lipski Acked-by: Leo Li Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit fce002f1c6905d7ab8a4d024ed8ce2e539217f61 Author: Christian König Date: Mon Sep 16 10:20:47 2019 -0500 drm/ttm: return -EBUSY on pipelining with no_gpu_wait (v2) [ Upstream commit 3084cf46cf8110826a42de8c8ef30e8fa48974c2 ] Setting the no_gpu_wait flag means that the allocate BO must be available immediately and we can't wait for any GPU operation to finish. v2: squash in mem leak fix, rebase Signed-off-by: Christian König Acked-by: Felix Kuehling Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit f8555732634cc184a77955ee144734d0c1df1e23 Author: Christian König Date: Mon Sep 9 13:57:32 2019 +0200 drm/amdgpu: grab the id mgr lock while accessing passid_mapping [ Upstream commit 6817bf283b2b851095825ec7f0e9f10398e09125 ] Need to make sure that we actually dropping the right fence. Could be done with RCU as well, but to complicated for a fix. Signed-off-by: Christian König Reviewed-by: Chunming Zhou Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 2c8bf64335c3a56944d35e8bb54f7008e800c74e Author: Jack Zhang Date: Tue Sep 10 12:29:14 2019 +0800 drm/amdgpu/sriov: add ring_stop before ring_create in psp v11 code [ Upstream commit 51c0f58e9f6af3a387d14608033e6796a7ad90ee ] psp v11 code missed ring stop in ring create function(VMR) while psp v3.1 code had the code. This will cause VM destroy1 fail and psp ring create fail. For SIOV-VF, ring_stop should not be deleted in ring_create function. Signed-off-by: Jack Zhang Reviewed-by: Feifei Xu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 240e9c97ba46bfe67460997dff44ba3538e44c74 Author: Krzysztof Wilczynski Date: Fri Sep 13 22:24:13 2019 +0200 iio: light: bh1750: Resolve compiler warning and make code more readable [ Upstream commit f552fde983d378e7339f9ea74a25f918563bf0d3 ] Separate the declaration of struct bh1750_chip_info from definition of bh1750_chip_info_tbl[] in a single statement as it makes the code hard to read, and with the extra newline it makes it look as if the bh1750_chip_info_tbl[] had no explicit type. This change also resolves the following compiler warning about the unusual position of the static keyword that can be seen when building with warnings enabled (W=1): drivers/iio/light/bh1750.c:64:1: warning: ‘static’ is not at beginning of declaration [-Wold-style-declaration] Related to commit 3a11fbb037a1 ("iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors"). Signed-off-by: Krzysztof Wilczynski Acked-by: Uwe Kleine-König Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 2eea45428923cba09359b09c4b38da567e1ac835 Author: Andrea Merello Date: Mon Sep 9 14:58:17 2019 +0200 iio: max31856: add missing of_node and parent references to iio_dev [ Upstream commit 505ea3ada665c466d0064b11b6e611b7f995517d ] Adding missing indio_dev->dev.of_node references so that, in case multiple max31856 are present, users can get some clues to being able to distinguish each of them. While at it, add also the missing parent reference. Signed-off-by: Andrea Merello Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit e00f6837a71fcf8e6c2af79487186126aac41437 Author: Jaehyun Chung Date: Mon Aug 19 16:45:05 2019 -0400 drm/amd/display: OTC underflow fix [ Upstream commit 785908cf19c9eb4803f6bf9c0a7447dc3661d5c3 ] [Why] Underflow occurs on some display setups(repro'd on 3x4K HDR) on boot, mode set, and hot-plugs with. Underflow occurs because mem clk is not set high after disabling pstate switching. This behaviour occurs because some calculations assumed displays were synchronized. [How] Add a condition to check if timing sync is disabled so that synchronized vblank can be set to false. Signed-off-by: Jaehyun Chung Reviewed-by: Alvin Lee Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 776b372fbb1b19186c40015319a2c74293211046 Author: Brian Masney Date: Wed Aug 14 20:48:46 2019 -0400 drm/bridge: analogix-anx78xx: silence -EPROBE_DEFER warnings [ Upstream commit 2708e876272d89bbbff811d12834adbeef85f022 ] Silence two warning messages that occur due to -EPROBE_DEFER errors to help cleanup the system boot log. Signed-off-by: Brian Masney Reviewed-by: Linus Walleij Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20190815004854.19860-4-masneyb@onstation.org Signed-off-by: Sasha Levin commit c872b45f161513a19809c3c69920ff782d848846 Author: Jing Zhou Date: Thu Aug 22 14:26:33 2019 +0800 drm/amd/display: verify stream link before link test [ Upstream commit b131932215c993ea5adf8192d1de2e8d6b23048d ] [Why] DP1.2 LL CTS test failure. [How] The failure is caused by not verify stream link is equal to link, only check stream and link is not null. Signed-off-by: Jing Zhou Reviewed-by: Wenjing Liu Acked-by: Bhawanpreet Lakha Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit cf3c92fa23aae772c65893f3ab99fe18bd58a188 Author: Daniel Vetter Date: Wed Sep 4 16:39:42 2019 +0200 drm: Use EOPNOTSUPP, not ENOTSUPP [ Upstream commit c7581a414d28413c1dd6d116d44859b5a52e0950 ] - it's what we recommend in our docs: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values - it's the overwhelmingly used error code for "operation not supported", at least in drm core (slightly less so in drivers): $ git grep EOPNOTSUPP -- drivers/gpu/drm/*c | wc -l 83 $ git grep ENOTSUPP -- drivers/gpu/drm/*c | wc -l 5 - include/linux/errno.h makes it fairly clear that these are for nfsv3 (plus they also have error codes above 512, which is the block with some special behaviour ...) /* Defined for the NFSv3 protocol */ If the above isn't reflecting current practice, then I guess we should at least update the docs. Noralf commented: Ben Hutchings made this comment[1] in a thread about use of ENOTSUPP in drivers: glibc's strerror() returns these strings for ENOTSUPP and EOPNOTSUPP respectively: "Unknown error 524" "Operation not supported" So at least for errors returned to userspace EOPNOTSUPP makes sense. José asked: > Hopefully this will not break any userspace None of the functions in drm_edid.c affected by this reach userspace, it's all driver internal. Same for the mipi function, that error code should be handled by drivers. Drivers are supposed to remap "the hw is on fire" to EIO when reporting up to userspace, but I think if a driver sees this it would be a driver bug. v2: Augment commit message with comments from Noralf and José Reviewed-by: José Roberto de Souza Acked-by: Noralf Trønnes Cc: José Roberto de Souza Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Alex Deucher Cc: Andres Rodriguez Cc: Noralf Trønnes Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190904143942.31756-1-daniel.vetter@ffwll.ch Signed-off-by: Sasha Levin commit 300cc98b7c376a43b3839f9dc46db18645260c85 Author: Dariusz Marcinkiewicz Date: Wed Aug 28 14:34:15 2019 +0200 drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register [ Upstream commit 71137bfd98973efb7b762ba168df077b87b34311 ] Use the new cec_notifier_conn_(un)register() functions to (un)register the notifier for the HDMI connector, and fill in the cec_connector_info. Changes since v7: - err_runtime_disable -> err_rpm_disable Changes since v2: - removed unnecessary call to invalidate phys address before deregistering the notifier, - use cec_notifier_phys_addr_invalidate instead of setting invalid address on a notifier. Signed-off-by: Dariusz Marcinkiewicz Tested-by: Hans Verkuil [hverkuil-cisco@xs4all.nl: use 'if (!hdata->notifier)' instead of '== NULL'] Signed-off-by: Hans Verkuil Link: https://patchwork.freedesktop.org/patch/msgid/20190828123415.139441-1-darekm@google.com Signed-off-by: Sasha Levin commit b554d2b7c4228a0e6da9b88c6ba4f8ae674624d6 Author: Laurent Pinchart Date: Fri Aug 23 22:32:42 2019 +0300 drm/panel: Add missing drm_panel_init() in panel drivers [ Upstream commit 65abbda8ed7ca48c8807d6b04a77431b438fa659 ] Panels must be initialised with drm_panel_init(). Add the missing function call in the panel-raspberrypi-touchscreen.c and panel-sitronix-st7789v.c drivers. Signed-off-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190823193245.23876-2-laurent.pinchart@ideasonboard.com Signed-off-by: Sasha Levin commit 80dfd8756987cca72180fec2600a87ea49ada1bf Author: Dan Carpenter Date: Wed Aug 21 10:24:56 2019 +0300 drm/mipi-dbi: fix a loop in debugfs code [ Upstream commit d72cf01f410aa09868d98b672f3f92328c96b32d ] This code will likely crash if we try to do a zero byte write. The code looks like this: /* strip trailing whitespace */ for (i = count - 1; i > 0; i--) if (isspace(buf[i])) ... We're writing zero bytes so count = 0. You would think that "count - 1" would be negative one, but because "i" is unsigned it is a large positive numer instead. The "i > 0" condition is true and the "buf[i]" access will be out of bounds. The fix is to make "i" signed and now everything works as expected. The upper bound of "count" is capped in __kernel_write() at MAX_RW_COUNT so we don't have to worry about it being higher than INT_MAX. Fixes: 02dd95fe3169 ("drm/tinydrm: Add MIPI DBI support") Signed-off-by: Dan Carpenter [noralf: Adjust title] Signed-off-by: Noralf Trønnes Link: https://patchwork.freedesktop.org/patch/msgid/20190821072456.GJ26957@mwanda Signed-off-by: Sasha Levin commit 5a7caa22e68b0cddfacfe063ba37c45d1f05579a Author: Sean Paul Date: Thu Aug 29 12:52:19 2019 -0400 drm: mst: Fix query_payload ack reply struct [ Upstream commit 268de6530aa18fe5773062367fd119f0045f6e88 ] Spec says[1] Allocated_PBN is 16 bits [1]- DisplayPort 1.2 Spec, Section 2.11.9.8, Table 2-98 Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Lyude Paul Cc: Todd Previte Cc: Dave Airlie Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul Signed-off-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190829165223.129662-1-sean@poorly.run Signed-off-by: Sasha Levin commit e6733ec8948475c4b62574e452135dc629294d75 Author: Gerd Hoffmann Date: Thu Aug 29 12:32:45 2019 +0200 drm/virtio: switch virtio_gpu_wait_ioctl() to gem helper. [ Upstream commit 29cf12394c0565d7eb1685bf0c1b4749aa6a8b66 ] Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl(). This also makes the ioctl run lockless. v9: fix return value. v5: handle lookup failure. v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT. Signed-off-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20190829103301.3539-3-kraxel@redhat.com Signed-off-by: Sasha Levin commit 622d3f4d8324600782b02db700754623fa56eae6 Author: Dariusz Marcinkiewicz Date: Fri Aug 23 13:24:25 2019 +0200 drm/vc4/vc4_hdmi: fill in connector info [ Upstream commit 66c2dee4ae10a2d841c40b9dd9c7141eb23eee76 ] Fill in the connector info, allowing userspace to associate the CEC device with the drm connector. Tested on a Raspberry Pi 3B. Signed-off-by: Dariusz Marcinkiewicz Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Acked-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20190823112427.42394-2-hverkuil-cisco@xs4all.nl Signed-off-by: Sasha Levin commit d14d3ad6ba2010d1c7bfdb6d26ac6ea0cdb5be4a Author: Takashi Iwai Date: Fri Dec 13 09:51:11 2019 +0100 ALSA: hda/ca0132 - Fix work handling in delayed HP detection commit 42fb6b1d41eb5905d77c06cad2e87b70289bdb76 upstream. CA0132 has the delayed HP jack detection code that is invoked from the unsol handler, but it does a few weird things: it contains the cancel of a work inside the work handler, and yet it misses the cancel-sync call at (runtime-)suspend. This patch addresses those issues. Fixes: 15c2b3cc09a3 ("ALSA: hda/ca0132 - Fix possible workqueue stall") Cc: Link: https://lore.kernel.org/r/20191213085111.22855-4-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 6598721676c376fbdea5a1433ea31f791cf1f4f1 Author: Takashi Iwai Date: Fri Dec 13 09:51:10 2019 +0100 ALSA: hda/ca0132 - Avoid endless loop commit cb04fc3b6b076f67d228a0b7d096c69ad486c09c upstream. Introduce a timeout to dspio_clear_response_queue() so that it won't be caught in an endless loop even if the hardware doesn't respond properly. Fixes: a73d511c4867 ("ALSA: hda/ca0132: Add unsol handler for DSP and jack detection") Cc: Link: https://lore.kernel.org/r/20191213085111.22855-3-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 302dc1aeb9672cc53d80ebb36cef725717ebf197 Author: Takashi Iwai Date: Fri Dec 13 09:51:09 2019 +0100 ALSA: hda/ca0132 - Keep power on during processing DSP response commit 377bc0cfabce0244632dada19060839ced4e6949 upstream. We need to keep power on while processing the DSP response via unsol event. Each snd_hda_codec_read() call does the power management, so it should work normally, but still it's safer to keep the power up for the whole function. Fixes: a73d511c4867 ("ALSA: hda/ca0132: Add unsol handler for DSP and jack detection") Cc: Link: https://lore.kernel.org/r/20191213085111.22855-2-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 396dbcfeea63060a2f2bbe595f657360fb253584 Author: Takashi Iwai Date: Wed Dec 11 16:57:42 2019 +0100 ALSA: pcm: Avoid possible info leaks from PCM stream buffers commit add9d56d7b3781532208afbff5509d7382fb6efe upstream. The current PCM code doesn't initialize explicitly the buffers allocated for PCM streams, hence it might leak some uninitialized kernel data or previous stream contents by mmapping or reading the buffer before actually starting the stream. Since this is a common problem, this patch simply adds the clearance of the buffer data at hw_params callback. Although this does only zero-clear no matter which format is used, which doesn't mean the silence for some formats, but it should be OK because the intention is just to clear the previous data on the buffer. Reported-by: Lionel Koenig Cc: Link: https://lore.kernel.org/r/20191211155742.3213-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit 7062bab77a04abd0eab60f461d36e765349e2af9 Author: Filipe Manana Date: Fri Dec 6 12:27:39 2019 +0000 Btrfs: fix removal logic of the tree mod log that leads to use-after-free issues commit 6609fee8897ac475378388238456c84298bff802 upstream. When a tree mod log user no longer needs to use the tree it calls btrfs_put_tree_mod_seq() to remove itself from the list of users and delete all no longer used elements of the tree's red black tree, which should be all elements with a sequence number less then our equals to the caller's sequence number. However the logic is broken because it can delete and free elements from the red black tree that have a sequence number greater then the caller's sequence number: 1) At a point in time we have sequence numbers 1, 2, 3 and 4 in the tree mod log; 2) The task which got assigned the sequence number 1 calls btrfs_put_tree_mod_seq(); 3) Sequence number 1 is deleted from the list of sequence numbers; 4) The current minimum sequence number is computed to be the sequence number 2; 5) A task using sequence number 2 is at tree_mod_log_rewind() and gets a pointer to one of its elements from the red black tree through a call to tree_mod_log_search(); 6) The task with sequence number 1 iterates the red black tree of tree modification elements and deletes (and frees) all elements with a sequence number less then or equals to 2 (the computed minimum sequence number) - it ends up only leaving elements with sequence numbers of 3 and 4; 7) The task with sequence number 2 now uses the pointer to its element, already freed by the other task, at __tree_mod_log_rewind(), resulting in a use-after-free issue. When CONFIG_DEBUG_PAGEALLOC=y it produces a trace like the following: [16804.546854] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI [16804.547451] CPU: 0 PID: 28257 Comm: pool Tainted: G W 5.4.0-rc8-btrfs-next-51 #1 [16804.548059] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014 [16804.548666] RIP: 0010:rb_next+0x16/0x50 (...) [16804.550581] RSP: 0018:ffffb948418ef9b0 EFLAGS: 00010202 [16804.551227] RAX: 6b6b6b6b6b6b6b6b RBX: ffff90e0247f6600 RCX: 6b6b6b6b6b6b6b6b [16804.551873] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff90e0247f6600 [16804.552504] RBP: ffff90dffe0d4688 R08: 0000000000000001 R09: 0000000000000000 [16804.553136] R10: ffff90dffa4a0040 R11: 0000000000000000 R12: 000000000000002e [16804.553768] R13: ffff90e0247f6600 R14: 0000000000001663 R15: ffff90dff77862b8 [16804.554399] FS: 00007f4b197ae700(0000) GS:ffff90e036a00000(0000) knlGS:0000000000000000 [16804.555039] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [16804.555683] CR2: 00007f4b10022000 CR3: 00000002060e2004 CR4: 00000000003606f0 [16804.556336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [16804.556968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [16804.557583] Call Trace: [16804.558207] __tree_mod_log_rewind+0xbf/0x280 [btrfs] [16804.558835] btrfs_search_old_slot+0x105/0xd00 [btrfs] [16804.559468] resolve_indirect_refs+0x1eb/0xc70 [btrfs] [16804.560087] ? free_extent_buffer.part.19+0x5a/0xc0 [btrfs] [16804.560700] find_parent_nodes+0x388/0x1120 [btrfs] [16804.561310] btrfs_check_shared+0x115/0x1c0 [btrfs] [16804.561916] ? extent_fiemap+0x59d/0x6d0 [btrfs] [16804.562518] extent_fiemap+0x59d/0x6d0 [btrfs] [16804.563112] ? __might_fault+0x11/0x90 [16804.563706] do_vfs_ioctl+0x45a/0x700 [16804.564299] ksys_ioctl+0x70/0x80 [16804.564885] ? trace_hardirqs_off_thunk+0x1a/0x20 [16804.565461] __x64_sys_ioctl+0x16/0x20 [16804.566020] do_syscall_64+0x5c/0x250 [16804.566580] entry_SYSCALL_64_after_hwframe+0x49/0xbe [16804.567153] RIP: 0033:0x7f4b1ba2add7 (...) [16804.568907] RSP: 002b:00007f4b197adc88 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [16804.569513] RAX: ffffffffffffffda RBX: 00007f4b100210d8 RCX: 00007f4b1ba2add7 [16804.570133] RDX: 00007f4b100210d8 RSI: 00000000c020660b RDI: 0000000000000003 [16804.570726] RBP: 000055de05a6cfe0 R08: 0000000000000000 R09: 00007f4b197add44 [16804.571314] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f4b197add48 [16804.571905] R13: 00007f4b197add40 R14: 00007f4b100210d0 R15: 00007f4b197add50 (...) [16804.575623] ---[ end trace 87317359aad4ba50 ]--- Fix this by making btrfs_put_tree_mod_seq() skip deletion of elements that have a sequence number equals to the computed minimum sequence number, and not just elements with a sequence number greater then that minimum. Fixes: bd989ba359f2ac ("Btrfs: add tree modification log functions") CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 785c7ecae1b4a0d7bb4abbf355598337493fefd2 Author: Josef Bacik Date: Fri Dec 6 11:39:00 2019 -0500 btrfs: handle ENOENT in btrfs_uuid_tree_iterate commit 714cd3e8cba6841220dce9063a7388a81de03825 upstream. If we get an -ENOENT back from btrfs_uuid_iter_rem when iterating the uuid tree we'll just continue and do btrfs_next_item(). However we've done a btrfs_release_path() at this point and no longer have a valid path. So increment the key and go back and do a normal search. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 15b1de9197d01a1cafc0b652ec0ec3dc2d1b7bb5 Author: Josef Bacik Date: Fri Dec 6 09:37:18 2019 -0500 btrfs: do not leak reloc root if we fail to read the fs root commit ca1aa2818a53875cfdd175fb5e9a2984e997cce9 upstream. If we fail to read the fs root corresponding with a reloc root we'll just break out and free the reloc roots. But we remove our current reloc_root from this list higher up, which means we'll leak this reloc_root. Fix this by adding ourselves back to the reloc_roots list so we are properly cleaned up. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f597f873ae0ed4c58a043c6d9bcfd7f5a04beca5 Author: Josef Bacik Date: Fri Dec 6 09:37:17 2019 -0500 btrfs: skip log replay on orphaned roots commit 9bc574de590510eff899c3ca8dbaf013566b5efe upstream. My fsstress modifications coupled with generic/475 uncovered a failure to mount and replay the log if we hit a orphaned root. We do not want to replay the log for an orphan root, but it's completely legitimate to have an orphaned root with a log attached. Fix this by simply skipping replaying the log. We still need to pin it's root node so that we do not overwrite it while replaying other logs, as we re-read the log root at every stage of the replay. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Signed-off-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit c1db18e292d30191d141246445cd471a7b25af65 Author: Josef Bacik Date: Fri Dec 6 09:37:15 2019 -0500 btrfs: abort transaction after failed inode updates in create_subvol commit c7e54b5102bf3614cadb9ca32d7be73bad6cecf0 upstream. We can just abort the transaction here, and in fact do that for every other failure in this function except these two cases. CC: stable@vger.kernel.org # 4.4+ Reviewed-by: Filipe Manana Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit f7e039d108f9857417884b951fbc750fbfc9ef8b Author: Anand Jain Date: Thu Dec 5 19:39:07 2019 +0800 btrfs: send: remove WARN_ON for readonly mount commit fbd542971aa1e9ec33212afe1d9b4f1106cd85a1 upstream. We log warning if root::orphan_cleanup_state is not set to ORPHAN_CLEANUP_DONE in btrfs_ioctl_send(). However if the filesystem is mounted as readonly we skip the orphan item cleanup during the lookup and root::orphan_cleanup_state remains at the init state 0 instead of ORPHAN_CLEANUP_DONE (2). So during send in btrfs_ioctl_send() we hit the warning as below. WARN_ON(send_root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE); WARNING: CPU: 0 PID: 2616 at /Volumes/ws/btrfs-devel/fs/btrfs/send.c:7090 btrfs_ioctl_send+0xb2f/0x18c0 [btrfs] :: RIP: 0010:btrfs_ioctl_send+0xb2f/0x18c0 [btrfs] :: Call Trace: :: _btrfs_ioctl_send+0x7b/0x110 [btrfs] btrfs_ioctl+0x150a/0x2b00 [btrfs] :: do_vfs_ioctl+0xa9/0x620 ? __fget+0xac/0xe0 ksys_ioctl+0x60/0x90 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x49/0x130 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reproducer: mkfs.btrfs -fq /dev/sdb mount /dev/sdb /btrfs btrfs subvolume create /btrfs/sv1 btrfs subvolume snapshot -r /btrfs/sv1 /btrfs/ss1 umount /btrfs mount -o ro /dev/sdb /btrfs btrfs send /btrfs/ss1 -f /tmp/f The warning exists because having orphan inodes could confuse send and cause it to fail or produce incorrect streams. The two cases that would cause such send failures, which are already fixed are: 1) Inodes that were unlinked - these are orphanized and remain with a link count of 0. These caused send operations to fail because it expected to always find at least one path for an inode. However this is no longer a problem since send is now able to deal with such inodes since commit 46b2f4590aab ("Btrfs: fix send failure when root has deleted files still open") and treats them as having been completely removed (the state after an orphan cleanup is performed). 2) Inodes that were in the process of being truncated. These resulted in send not knowing about the truncation and potentially issue write operations full of zeroes for the range from the new file size to the old file size. This is no longer a problem because we no longer create orphan items for truncation since commit f7e9e8fc792f ("Btrfs: stop creating orphan items for truncate"). As such before these commits, the WARN_ON here provided a clue in case something went wrong. Instead of being a warning against the root::orphan_cleanup_state value, it could have been more accurate by checking if there were actually any orphan items, and then issue a warning only if any exists, but that would be more expensive to check. Since orphanized inodes no longer cause problems for send, just remove the warning. Reported-by: Christoph Anton Mitterer Link: https://lore.kernel.org/linux-btrfs/21cb5e8d059f6e1496a903fa7bfc0a297e2f5370.camel@scientia.net/ CC: stable@vger.kernel.org # 4.19+ Suggested-by: Filipe Manana Reviewed-by: Filipe Manana Signed-off-by: Anand Jain Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit ee98e130b40b179de37c93344a905dbd71772e2c Author: Filipe Manana Date: Thu Dec 5 16:58:30 2019 +0000 Btrfs: fix missing data checksums after replaying a log tree commit 40e046acbd2f369cfbf93c3413639c66514cec2d upstream. When logging a file that has shared extents (reflinked with other files or with itself), we can end up logging multiple checksum items that cover overlapping ranges. This confuses the search for checksums at log replay time causing some checksums to never be added to the fs/subvolume tree. Consider the following example of a file that shares the same extent at offsets 0 and 256Kb: [ bytenr 13893632, offset 64Kb, len 64Kb ] 0 64Kb [ bytenr 13631488, offset 64Kb, len 192Kb ] 64Kb 256Kb [ bytenr 13893632, offset 0, len 256Kb ] 256Kb 512Kb When logging the inode, at tree-log.c:copy_items(), when processing the file extent item at offset 0, we log a checksum item covering the range 13959168 to 14024704, which corresponds to 13893632 + 64Kb and 13893632 + 64Kb + 64Kb, respectively. Later when processing the extent item at offset 256K, we log the checksums for the range from 13893632 to 14155776 (which corresponds to 13893632 + 256Kb). These checksums get merged with the checksum item for the range from 13631488 to 13893632 (13631488 + 256Kb), logged by a previous fsync. So after this we get the two following checksum items in the log tree: (...) item 6 key (EXTENT_CSUM EXTENT_CSUM 13631488) itemoff 3095 itemsize 512 range start 13631488 end 14155776 length 524288 item 7 key (EXTENT_CSUM EXTENT_CSUM 13959168) itemoff 3031 itemsize 64 range start 13959168 end 14024704 length 65536 The first one covers the range from the second one, they overlap. So far this does not cause a problem after replaying the log, because when replaying the file extent item for offset 256K, we copy all the checksums for the extent 13893632 from the log tree to the fs/subvolume tree, since searching for an checksum item for bytenr 13893632 leaves us at the first checksum item, which covers the whole range of the extent. However if we write 64Kb to file offset 256Kb for example, we will not be able to find and copy the checksums for the last 128Kb of the extent at bytenr 13893632, referenced by the file range 384Kb to 512Kb. After writing 64Kb into file offset 256Kb we get the following extent layout for our file: [ bytenr 13893632, offset 64K, len 64Kb ] 0 64Kb [ bytenr 13631488, offset 64Kb, len 192Kb ] 64Kb 256Kb [ bytenr 14155776, offset 0, len 64Kb ] 256Kb 320Kb [ bytenr 13893632, offset 64Kb, len 192Kb ] 320Kb 512Kb After fsync'ing the file, if we have a power failure and then mount the filesystem to replay the log, the following happens: 1) When replaying the file extent item for file offset 320Kb, we lookup for the checksums for the extent range from 13959168 (13893632 + 64Kb) to 14155776 (13893632 + 256Kb), through a call to btrfs_lookup_csums_range(); 2) btrfs_lookup_csums_range() finds the checksum item that starts precisely at offset 13959168 (item 7 in the log tree, shown before); 3) However that checksum item only covers 64Kb of data, and not 192Kb of data; 4) As a result only the checksums for the first 64Kb of data referenced by the file extent item are found and copied to the fs/subvolume tree. The remaining 128Kb of data, file range 384Kb to 512Kb, doesn't get the corresponding data checksums found and copied to the fs/subvolume tree. 5) After replaying the log userspace will not be able to read the file range from 384Kb to 512Kb, because the checksums are missing and resulting in an -EIO error. The following steps reproduce this scenario: $ mkfs.btrfs -f /dev/sdc $ mount /dev/sdc /mnt/sdc $ xfs_io -f -c "pwrite -S 0xa3 0 256K" /mnt/sdc/foobar $ xfs_io -c "fsync" /mnt/sdc/foobar $ xfs_io -c "pwrite -S 0xc7 256K 256K" /mnt/sdc/foobar $ xfs_io -c "reflink /mnt/sdc/foobar 320K 0 64K" /mnt/sdc/foobar $ xfs_io -c "fsync" /mnt/sdc/foobar $ xfs_io -c "pwrite -S 0xe5 256K 64K" /mnt/sdc/foobar $ xfs_io -c "fsync" /mnt/sdc/foobar $ mount /dev/sdc /mnt/sdc $ md5sum /mnt/sdc/foobar md5sum: /mnt/sdc/foobar: Input/output error $ dmesg | tail [165305.003464] BTRFS info (device sdc): no csum found for inode 257 start 401408 [165305.004014] BTRFS info (device sdc): no csum found for inode 257 start 405504 [165305.004559] BTRFS info (device sdc): no csum found for inode 257 start 409600 [165305.005101] BTRFS info (device sdc): no csum found for inode 257 start 413696 [165305.005627] BTRFS info (device sdc): no csum found for inode 257 start 417792 [165305.006134] BTRFS info (device sdc): no csum found for inode 257 start 421888 [165305.006625] BTRFS info (device sdc): no csum found for inode 257 start 425984 [165305.007278] BTRFS info (device sdc): no csum found for inode 257 start 430080 [165305.008248] BTRFS warning (device sdc): csum failed root 5 ino 257 off 393216 csum 0x1337385e expected csum 0x00000000 mirror 1 [165305.009550] BTRFS warning (device sdc): csum failed root 5 ino 257 off 393216 csum 0x1337385e expected csum 0x00000000 mirror 1 Fix this simply by deleting first any checksums, from the log tree, for the range of the extent we are logging at copy_items(). This ensures we do not get checksum items in the log tree that have overlapping ranges. This is a long time issue that has been present since we have the clone (and deduplication) ioctl, and can happen both when an extent is shared between different files and within the same file. A test case for fstests follows soon. CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit aed46bbd426c2809287390263720a7cf5de52085 Author: Dan Carpenter Date: Tue Dec 3 14:24:58 2019 +0300 btrfs: return error pointer from alloc_test_extent_buffer commit b6293c821ea8fa2a631a2112cd86cd435effeb8b upstream. Callers of alloc_test_extent_buffer have not correctly interpreted the return value as error pointer, as alloc_test_extent_buffer should behave as alloc_extent_buffer. The self-tests were unaffected but btrfs_find_create_tree_block could call both functions and that would cause problems up in the call chain. Fixes: faa2dbf004e8 ("Btrfs: add sanity tests for new qgroup accounting code") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Dan Carpenter Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 2bfffc24dafe6d3d50b7df881f6af969a24c5050 Author: Filipe Manana Date: Mon Dec 2 11:01:03 2019 +0000 Btrfs: make tree checker detect checksum items with overlapping ranges commit ad1d8c439978ede77cbf73cbdd11bafe810421a5 upstream. Having checksum items, either on the checksums tree or in a log tree, that represent ranges that overlap each other is a sign of a corruption. Such case confuses the checksum lookup code and can result in not being able to find checksums or find stale checksums. So add a check for such case. This is motivated by a recent fix for a case where a log tree had checksum items covering ranges that overlap each other due to extent cloning, and resulted in missing checksums after replaying the log tree. It also helps detect past issues such as stale and outdated checksums due to overlapping, commit 27b9a8122ff71a ("Btrfs: fix csum tree corruption, duplicate and outdated checksums"). CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit e3fb5bb7eb584be6dedb8b22d4d2f0495374b071 Author: Josef Bacik Date: Tue Nov 19 13:59:35 2019 -0500 btrfs: do not call synchronize_srcu() in inode_tree_del commit f72ff01df9cf5db25c76674cac16605992d15467 upstream. Testing with the new fsstress uncovered a pretty nasty deadlock with lookup and snapshot deletion. Process A unlink -> final iput -> inode_tree_del -> synchronize_srcu(subvol_srcu) Process B btrfs_lookup <- srcu_read_lock() acquired here -> btrfs_iget -> find inode that has I_FREEING set -> __wait_on_freeing_inode() We're holding the srcu_read_lock() while doing the iget in order to make sure our fs root doesn't go away, and then we are waiting for the inode to finish freeing. However because the free'ing process is doing a synchronize_srcu() we deadlock. Fix this by dropping the synchronize_srcu() in inode_tree_del(). We don't need people to stop accessing the fs root at this point, we're only adding our empty root to the dead roots list. A larger much more invasive fix is forthcoming to address how we deal with fs roots, but this fixes the immediate problem. Fixes: 76dda93c6ae2 ("Btrfs: add snapshot/subvolume destroy ioctl") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit 831140602a555d5fa8d27f706c4ad3f432c1b2b1 Author: Josef Bacik Date: Tue Nov 19 13:59:20 2019 -0500 btrfs: don't double lock the subvol_sem for rename exchange commit 943eb3bf25f4a7b745dd799e031be276aa104d82 upstream. If we're rename exchanging two subvols we'll try to lock this lock twice, which is bad. Just lock once if either of the ino's are subvols. Fixes: cdd1fedf8261 ("btrfs: add support for RENAME_EXCHANGE and RENAME_WHITEOUT") CC: stable@vger.kernel.org # 4.4+ Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman commit aceca7b13f445298e1cccf31e37ea2a8be597898 Author: Stephan Gerhold Date: Mon Dec 9 19:53:43 2019 +0100 NFC: nxp-nci: Fix probing without ACPI [ Upstream commit 868afbaca1e2a7923e48b5e8c07be34660525db5 ] devm_acpi_dev_add_driver_gpios() returns -ENXIO if CONFIG_ACPI is disabled (e.g. on device tree platforms). In this case, nxp-nci will silently fail to probe. The other NFC drivers only log a debug message if devm_acpi_dev_add_driver_gpios() fails. Do the same in nxp-nci to fix this problem. Fixes: ad0acfd69add ("NFC: nxp-nci: Get rid of code duplication in ->probe()") Cc: Andy Shevchenko Signed-off-by: Stephan Gerhold Acked-by: Andy Shevchenko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 32730c21e4b2fa31c51829411774602d5da3f01a Author: Florian Fainelli Date: Fri Dec 13 12:00:27 2019 -0800 net: dsa: b53: Fix egress flooding settings [ Upstream commit 63cc54a6f0736a432b04308a74677ab0ba8a58ee ] There were several issues with 53568438e381 ("net: dsa: b53: Add support for port_egress_floods callback") that resulted in breaking connectivity for standalone ports: - both user and CPU ports must allow unicast and multicast forwarding by default otherwise this just flat out breaks connectivity for standalone DSA ports - IP multicast is treated similarly as multicast, but has separate control registers - the UC, MC and IPMC lookup failure register offsets were wrong, and instead used bit values that are meaningful for the B53_IP_MULTICAST_CTRL register Fixes: 53568438e381 ("net: dsa: b53: Add support for port_egress_floods callback") Signed-off-by: Florian Fainelli Reviewed-by: Vivien Didelot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit bfdbfd28f76028b960458d107dc4ae9240c928b3 Author: Padmanabhan Rajanbabu Date: Thu Dec 19 15:47:01 2019 +0530 net: stmmac: platform: Fix MDIO init for platforms without PHY [ Upstream commit d3e014ec7d5ebe9644b5486bc530b91e62bbf624 ] The current implementation of "stmmac_dt_phy" function initializes the MDIO platform bus data, even in the absence of PHY. This fix will skip MDIO initialization if there is no PHY present. Fixes: 7437127 ("net: stmmac: Convert to phylink and remove phylib logic") Acked-by: Jayati Sahu Signed-off-by: Sriram Dash Signed-off-by: Padmanabhan Rajanbabu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e78db79a59e2dfd4f32d22845ad3f84b88e4c6a0 Author: Grygorii Strashko Date: Mon Dec 9 13:19:24 2019 +0200 net: ethernet: ti: davinci_cpdma: fix warning "device driver frees DMA memory with different size" [ Upstream commit 8a2b22203f8596729c54eba221b4044351bfe167 ] The TI CPSW(s) driver produces warning with DMA API debug options enabled: WARNING: CPU: 0 PID: 1033 at kernel/dma/debug.c:1025 check_unmap+0x4a8/0x968 DMA-API: cpsw 48484000.ethernet: device driver frees DMA memory with different size [device address=0x00000000abc6aa02] [map size=64 bytes] [unmap size=42 bytes] CPU: 0 PID: 1033 Comm: ping Not tainted 5.3.0-dirty #41 Hardware name: Generic DRA72X (Flattened Device Tree) [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0xd8/0x110) [] (dump_stack) from [] (__warn+0xe0/0x10c) [] (__warn) from [] (warn_slowpath_fmt+0x44/0x6c) [] (warn_slowpath_fmt) from [] (check_unmap+0x4a8/0x968) [] (check_unmap) from [] (debug_dma_unmap_page+0x80/0x90) [] (debug_dma_unmap_page) from [] (__cpdma_chan_free+0x114/0x16c) [] (__cpdma_chan_free) from [] (__cpdma_chan_process+0x158/0x17c) [] (__cpdma_chan_process) from [] (cpdma_chan_process+0x3c/0x5c) [] (cpdma_chan_process) from [] (cpsw_tx_mq_poll+0x48/0x94) [] (cpsw_tx_mq_poll) from [] (net_rx_action+0x108/0x4e4) [] (net_rx_action) from [] (__do_softirq+0xec/0x598) [] (__do_softirq) from [] (do_softirq.part.4+0x68/0x74) [] (do_softirq.part.4) from [] (__local_bh_enable_ip+0x124/0x17c) [] (__local_bh_enable_ip) from [] (ip_finish_output2+0x294/0xb7c) [] (ip_finish_output2) from [] (ip_output+0x210/0x364) [] (ip_output) from [] (ip_send_skb+0x1c/0xf8) [] (ip_send_skb) from [] (raw_sendmsg+0x9a8/0xc74) [] (raw_sendmsg) from [] (sock_sendmsg+0x14/0x24) [] (sock_sendmsg) from [] (__sys_sendto+0xbc/0x100) [] (__sys_sendto) from [] (__sys_trace_return+0x0/0x14) Exception stack(0xea9a7fa8 to 0xea9a7ff0) ... The reason is that cpdma_chan_submit_si() now stores original buffer length (sw_len) in CPDMA descriptor instead of adjusted buffer length (hw_len) used to map the buffer. Hence, fix an issue by passing correct buffer length in CPDMA descriptor. Cc: Ivan Khoronzhuk Fixes: 6670acacd59e ("net: ethernet: ti: davinci_cpdma: add dma mapped submit") Signed-off-by: Grygorii Strashko Reviewed-by: Ivan Khoronzhuk Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 83094ebc2f31b4e76f9bbd9cfc41d5853f0d98f2 Author: Ido Schimmel Date: Mon Dec 9 08:55:20 2019 +0200 mlxsw: spectrum_router: Remove unlikely user-triggerable warning [ Upstream commit 62201c00c4679ad8f0730d6d925a5d23651dfad2 ] In case the driver vetoes the addition of an IPv6 multipath route, the IPv6 stack will emit delete notifications for the sibling routes that were already added to the FIB trie. Since these siblings are not present in hardware, a warning will be generated. Have the driver ignore notifications for routes it does not have. Fixes: ebee3cad835f ("ipv6: Add IPv6 multipath notifications for add / replace") Signed-off-by: Ido Schimmel Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 95b211b24811938f51926457eaeca2583b63ac90 Author: Ioana Ciornei Date: Mon Dec 16 17:32:30 2019 +0200 dpaa2-ptp: fix double free of the ptp_qoriq IRQ [ Upstream commit daa6eb5a149519583c8a8cb31945f06417d21902 ] Upon reusing the ptp_qoriq driver, the ptp_qoriq_free() function was used on the remove path to free any allocated resources. The ptp_qoriq IRQ is among these resources that are freed in ptp_qoriq_free() even though it is also a managed one (allocated using devm_request_threaded_irq). Drop the resource managed version of requesting the IRQ in order to not trigger a double free of the interrupt as below: [ 226.731005] Trying to free already-free IRQ 126 [ 226.735533] WARNING: CPU: 6 PID: 749 at kernel/irq/manage.c:1707 __free_irq+0x9c/0x2b8 [ 226.743435] Modules linked in: [ 226.746480] CPU: 6 PID: 749 Comm: bash Tainted: G W 5.4.0-03629-gfd7102c32b2c-dirty #912 [ 226.755857] Hardware name: NXP Layerscape LX2160ARDB (DT) [ 226.761244] pstate: 40000085 (nZcv daIf -PAN -UAO) [ 226.766022] pc : __free_irq+0x9c/0x2b8 [ 226.769758] lr : __free_irq+0x9c/0x2b8 [ 226.773493] sp : ffff8000125039f0 (...) [ 226.856275] Call trace: [ 226.858710] __free_irq+0x9c/0x2b8 [ 226.862098] free_irq+0x30/0x70 [ 226.865229] devm_irq_release+0x14/0x20 [ 226.869054] release_nodes+0x1b0/0x220 [ 226.872790] devres_release_all+0x34/0x50 [ 226.876790] device_release_driver_internal+0x100/0x1c0 Fixes: d346c9e86d86 ("dpaa2-ptp: reuse ptp_qoriq driver") Cc: Yangbo Lu Signed-off-by: Ioana Ciornei Reviewed-by: Yangbo Lu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 5c09590982943253de7c84aa4d760eec4454bf2b Author: Arthur Kiyanovski Date: Thu Dec 19 17:40:56 2019 +0200 net: ena: fix issues in setting interrupt moderation params in ethtool [ Upstream commit 41c53caa5a61ebc9221b71cc37f4a90549f1121d ] Issue 1: -------- Reproduction steps: 1. sudo ethtool -C eth0 rx-usecs 128 2. sudo ethtool -C eth0 adaptive-rx on 3. sudo ethtool -C eth0 adaptive-rx off 4. ethtool -c eth0 expected output: rx-usecs 128 actual output: rx-usecs 0 Reason for issue: In stage 3, ethtool userspace calls first the ena_get_coalesce() handler to get the current value of all properties, and then the ena_set_coalesce() handler. When ena_get_coalesce() is called the adaptive interrupt moderation is still on. There is an if in the code that returns the rx_coalesce_usecs only if the adaptive interrupt moderation is off. And since it is still on, rx_coalesce_usecs is not set, meaning it stays 0. Solution to issue: Remove this if static interrupt moderation intervals have nothing to do with dynamic ones. Issue 2: -------- Reproduction steps: 1. sudo ethtool -C eth0 adaptive-rx on 2. sudo ethtool -C eth0 rx-usecs 128 3. ethtool -c eth0 expected output: rx-usecs 128 actual output: rx-usecs 0 Reason for issue: In stage 2, when ena_set_coalesce() is called, the handler tests if rx adaptive interrupt moderation is on, and if it is, it returns before getting to the part in the function that sets the rx non-adaptive interrupt moderation interval. Solution to issue: Remove the return from the function when rx adaptive interrupt moderation is on. Also cleaned up the fixed code in ena_set_coalesce by grouping together adaptive interrupt moderation toggling, and using && instead of nested ifs. Fixes: b3db86dc4b82 ("net: ena: reimplement set/get_coalesce()") Fixes: 0eda847953d8 ("net: ena: fix retrieval of nonadaptive interrupt moderation intervals") Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Arthur Kiyanovski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4d1393cfca4a7e56d2db9b5278179d08d340a2d1 Author: Arthur Kiyanovski Date: Thu Dec 19 17:40:55 2019 +0200 net: ena: fix default tx interrupt moderation interval [ Upstream commit 05785adf6e570a068adf0502b61fe2b521d7f0ca ] Current default non-adaptive tx interrupt moderation interval is 196 us. This value is too high and might cause the tx queue to fill up. In this commit we set the default non-adaptive tx interrupt moderation interval to 64 us in order to: 1. Reduce the probability of the queue filling-up (when compared to the current default value of 196 us). 2. Reduce unnecessary tx interrupt overhead (which happens if we set the default tx interval to 0). We determined experimentally that 64 us is an optimal value that reduces interrupt rate by more than 20% without affecting performance. Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)") Signed-off-by: Arthur Kiyanovski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 7d07f8cd260436a7a661b4f8773bcc9e88ab3a24 Author: Eric Dumazet Date: Sat Dec 7 14:10:34 2019 -0800 bonding: fix bond_neigh_init() [ Upstream commit 9e99bfefdbce2e23ef37487a3bcb4adf90a791d1 ] 1) syzbot reported an uninit-value in bond_neigh_setup() [1] bond_neigh_setup() uses a temporary on-stack 'struct neigh_parms parms', but only clears parms.neigh_setup field. A stacked bonding device would then enter bond_neigh_setup() and read garbage from parms->dev. If we get really unlucky and garbage is matching @dev, then we could recurse and eventually crash. Let's make sure the whole structure is cleared to avoid surprises. 2) bond_neigh_setup() can be called while another cpu manipulates the master device, removing or adding a slave. We need at least rcu protection to prevent use-after-free. Note: Prior code does not support a stack of bonding devices, this patch does not attempt to fix this, and leave a comment instead. [1] BUG: KMSAN: uninit-value in bond_neigh_setup+0xa4/0x110 drivers/net/bonding/bond_main.c:3655 CPU: 0 PID: 11256 Comm: syz-executor.0 Not tainted 5.4.0-rc8-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+0x128/0x220 mm/kmsan/kmsan_report.c:108 __msan_warning+0x57/0xa0 mm/kmsan/kmsan_instr.c:245 bond_neigh_setup+0xa4/0x110 drivers/net/bonding/bond_main.c:3655 bond_neigh_init+0x216/0x4b0 drivers/net/bonding/bond_main.c:3626 ___neigh_create+0x169e/0x2c40 net/core/neighbour.c:613 __neigh_create+0xbd/0xd0 net/core/neighbour.c:674 ip6_finish_output2+0x149a/0x2670 net/ipv6/ip6_output.c:113 __ip6_finish_output+0x83d/0x8f0 net/ipv6/ip6_output.c:142 ip6_finish_output+0x2db/0x420 net/ipv6/ip6_output.c:152 NF_HOOK_COND include/linux/netfilter.h:294 [inline] ip6_output+0x5d3/0x720 net/ipv6/ip6_output.c:175 dst_output include/net/dst.h:436 [inline] NF_HOOK include/linux/netfilter.h:305 [inline] mld_sendpack+0xebd/0x13d0 net/ipv6/mcast.c:1682 mld_send_cr net/ipv6/mcast.c:1978 [inline] mld_ifc_timer_expire+0x116b/0x1680 net/ipv6/mcast.c:2477 call_timer_fn+0x232/0x530 kernel/time/timer.c:1404 expire_timers kernel/time/timer.c:1449 [inline] __run_timers+0xd60/0x1270 kernel/time/timer.c:1773 run_timer_softirq+0x2d/0x50 kernel/time/timer.c:1786 __do_softirq+0x4a1/0x83a kernel/softirq.c:293 invoke_softirq kernel/softirq.c:375 [inline] irq_exit+0x230/0x280 kernel/softirq.c:416 exiting_irq+0xe/0x10 arch/x86/include/asm/apic.h:536 smp_apic_timer_interrupt+0x48/0x70 arch/x86/kernel/apic/apic.c:1138 apic_timer_interrupt+0x2e/0x40 arch/x86/entry/entry_64.S:835 RIP: 0010:kmsan_free_page+0x18d/0x1c0 mm/kmsan/kmsan_shadow.c:439 Code: 4c 89 ff 44 89 f6 e8 82 0d ee ff 65 ff 0d 9f 26 3b 60 65 8b 05 98 26 3b 60 85 c0 75 24 e8 5b f6 35 ff 4c 89 6d d0 ff 75 d0 9d <48> 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 0b 0f 0b 0f 0b 0f RSP: 0018:ffffb328034af818 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000000 RBX: ffffe2d7471f8360 RCX: 0000000000000000 RDX: ffffffffadea7000 RSI: 0000000000000004 RDI: ffff93496fcda104 RBP: ffffb328034af850 R08: ffff934a47e86d00 R09: ffff93496fc41900 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000246 R14: 0000000000000000 R15: ffffe2d7472225c0 free_pages_prepare mm/page_alloc.c:1138 [inline] free_pcp_prepare mm/page_alloc.c:1230 [inline] free_unref_page_prepare+0x1d9/0x770 mm/page_alloc.c:3025 free_unref_page mm/page_alloc.c:3074 [inline] free_the_page mm/page_alloc.c:4832 [inline] __free_pages+0x154/0x230 mm/page_alloc.c:4840 __vunmap+0xdac/0xf20 mm/vmalloc.c:2277 __vfree mm/vmalloc.c:2325 [inline] vfree+0x7c/0x170 mm/vmalloc.c:2355 copy_entries_to_user net/ipv6/netfilter/ip6_tables.c:883 [inline] get_entries net/ipv6/netfilter/ip6_tables.c:1041 [inline] do_ip6t_get_ctl+0xfa4/0x1030 net/ipv6/netfilter/ip6_tables.c:1709 nf_sockopt net/netfilter/nf_sockopt.c:104 [inline] nf_getsockopt+0x481/0x4e0 net/netfilter/nf_sockopt.c:122 ipv6_getsockopt+0x264/0x510 net/ipv6/ipv6_sockglue.c:1400 tcp_getsockopt+0x1c6/0x1f0 net/ipv4/tcp.c:3688 sock_common_getsockopt+0x13f/0x180 net/core/sock.c:3110 __sys_getsockopt+0x533/0x7b0 net/socket.c:2129 __do_sys_getsockopt net/socket.c:2144 [inline] __se_sys_getsockopt+0xe1/0x100 net/socket.c:2141 __x64_sys_getsockopt+0x62/0x80 net/socket.c:2141 do_syscall_64+0xb6/0x160 arch/x86/entry/common.c:291 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45d20a Code: b8 34 01 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 8d 8b fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 0f 83 6a 8b fb ff c3 66 0f 1f 84 00 00 00 00 00 RSP: 002b:0000000000a6f618 EFLAGS: 00000212 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 0000000000a6f640 RCX: 000000000045d20a RDX: 0000000000000041 RSI: 0000000000000029 RDI: 0000000000000003 RBP: 0000000000717cc0 R08: 0000000000a6f63c R09: 0000000000004000 R10: 0000000000a6f740 R11: 0000000000000212 R12: 0000000000000003 R13: 0000000000000000 R14: 0000000000000029 R15: 0000000000715b00 Local variable description: ----parms@bond_neigh_init Variable was created at: bond_neigh_init+0x8c/0x4b0 drivers/net/bonding/bond_main.c:3617 bond_neigh_init+0x8c/0x4b0 drivers/net/bonding/bond_main.c:3617 Fixes: 9918d5bf329d ("bonding: modify only neigh_parms owned by us") Fixes: 234bcf8a499e ("net/bonding: correctly proxy slave neigh param setup ndo function") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Jay Vosburgh Cc: Veaceslav Falico Cc: Andy Gospodarek Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a073350c5f3b0b0b3c58e42ccd886fd6450575a9 Author: Eric Dumazet Date: Sat Dec 7 12:23:21 2019 -0800 neighbour: remove neigh_cleanup() method [ Upstream commit f394722fb0d0f701119368959d7cd0ecbc46363a ] neigh_cleanup() has not been used for seven years, and was a wrong design. Messing with shared pointer in bond_neigh_init() without proper memory barriers would at least trigger syzbot complains eventually. It is time to remove this stuff. Fixes: b63b70d87741 ("IPoIB: Use a private hash table for path lookup in xmit path") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 37a56610e96d71d976d989ed70a5a4fc9d07f66a Author: Ido Schimmel Date: Mon Dec 9 08:56:34 2019 +0200 selftests: forwarding: Delete IPv6 address at the end [ Upstream commit 65cb13986229cec02635a1ecbcd1e2dd18353201 ] When creating the second host in h2_create(), two addresses are assigned to the interface, but only one is deleted. When running the test twice in a row the following error is observed: $ ./router_bridge_vlan.sh TEST: ping [ OK ] TEST: ping6 [ OK ] TEST: vlan [ OK ] $ ./router_bridge_vlan.sh RTNETLINK answers: File exists TEST: ping [ OK ] TEST: ping6 [ OK ] TEST: vlan [ OK ] Fix this by deleting the address during cleanup. Fixes: 5b1e7f9ebd56 ("selftests: forwarding: Test routed bridge interface") Signed-off-by: Ido Schimmel Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cbf89ebfc053edebaedb266cb1d54b642ce0318b Author: Xin Long Date: Mon Dec 9 13:45:54 2019 +0800 sctp: fully initialize v4 addr in some functions [ Upstream commit b6f3320b1d5267e7b583a6d0c88dda518101740c ] Syzbot found a crash: BUG: KMSAN: uninit-value in crc32_body lib/crc32.c:112 [inline] BUG: KMSAN: uninit-value in crc32_le_generic lib/crc32.c:179 [inline] BUG: KMSAN: uninit-value in __crc32c_le_base+0x4fa/0xd30 lib/crc32.c:202 Call Trace: crc32_body lib/crc32.c:112 [inline] crc32_le_generic lib/crc32.c:179 [inline] __crc32c_le_base+0x4fa/0xd30 lib/crc32.c:202 chksum_update+0xb2/0x110 crypto/crc32c_generic.c:90 crypto_shash_update+0x4c5/0x530 crypto/shash.c:107 crc32c+0x150/0x220 lib/libcrc32c.c:47 sctp_csum_update+0x89/0xa0 include/net/sctp/checksum.h:36 __skb_checksum+0x1297/0x12a0 net/core/skbuff.c:2640 sctp_compute_cksum include/net/sctp/checksum.h:59 [inline] sctp_packet_pack net/sctp/output.c:528 [inline] sctp_packet_transmit+0x40fb/0x4250 net/sctp/output.c:597 sctp_outq_flush_transports net/sctp/outqueue.c:1146 [inline] sctp_outq_flush+0x1823/0x5d80 net/sctp/outqueue.c:1194 sctp_outq_uncork+0xd0/0xf0 net/sctp/outqueue.c:757 sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1781 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1184 [inline] sctp_do_sm+0x8fe1/0x9720 net/sctp/sm_sideeffect.c:1155 sctp_primitive_REQUESTHEARTBEAT+0x175/0x1a0 net/sctp/primitive.c:185 sctp_apply_peer_addr_params+0x212/0x1d40 net/sctp/socket.c:2433 sctp_setsockopt_peer_addr_params net/sctp/socket.c:2686 [inline] sctp_setsockopt+0x189bb/0x19090 net/sctp/socket.c:4672 The issue was caused by transport->ipaddr set with uninit addr param, which was passed by: sctp_transport_init net/sctp/transport.c:47 [inline] sctp_transport_new+0x248/0xa00 net/sctp/transport.c:100 sctp_assoc_add_peer+0x5ba/0x2030 net/sctp/associola.c:611 sctp_process_param net/sctp/sm_make_chunk.c:2524 [inline] where 'addr' is set by sctp_v4_from_addr_param(), and it doesn't initialize the padding of addr->v4. Later when calling sctp_make_heartbeat(), hbinfo.daddr(=transport->ipaddr) will become the part of skb, and the issue occurs. This patch is to fix it by initializing the padding of addr->v4 in sctp_v4_from_addr_param(), as well as other functions that do the similar thing, and these functions shouldn't trust that the caller initializes the memory, as Marcelo suggested. Reported-by: syzbot+6dcbfea81cd3d4dd0b02@syzkaller.appspotmail.com Signed-off-by: Xin Long Acked-by: Neil Horman Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 62870e2a06467a52090373b18ddea073a6486401 Author: Marcelo Ricardo Leitner Date: Mon Dec 16 22:01:16 2019 -0300 sctp: fix memleak on err handling of stream initialization [ Upstream commit 951c6db954a1adefab492f6da805decacabbd1a7 ] syzbot reported a memory leak when an allocation fails within genradix_prealloc() for output streams. That's because genradix_prealloc() leaves initialized members initialized when the issue happens and SCTP stack will abort the current initialization but without cleaning up such members. The fix here is to always call genradix_free() when genradix_prealloc() fails, for output and also input streams, as it suffers from the same issue. Reported-by: syzbot+772d9e36c490b18d51d1@syzkaller.appspotmail.com Fixes: 2075e50caf5e ("sctp: convert to genradix") Signed-off-by: Marcelo Ricardo Leitner Tested-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b315f8a6da442954d7d92dd1bc67587e09e39bf2 Author: Manish Chopra Date: Thu Dec 12 06:49:28 2019 -0800 qede: Fix multicast mac configuration [ Upstream commit 0af67e49b018e7280a4227bfe7b6005bc9d3e442 ] Driver doesn't accommodate the configuration for max number of multicast mac addresses, in such particular case it leaves the device with improper/invalid multicast configuration state, causing connectivity issues (in lacp bonding like scenarios). Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 96f07a21c054ee1558d947860b13df1a679daf4b Author: Manish Chopra Date: Thu Dec 19 10:35:16 2019 -0800 qede: Disable hardware gro when xdp prog is installed [ Upstream commit 4c8dc00503db24deaf0b89dddfa84b7cba7cd4ce ] commit 18c602dee472 ("qede: Use NETIF_F_GRO_HW.") introduced a regression in driver that when xdp program is installed on qede device, device's aggregation feature (hardware GRO) is not getting disabled, which is unexpected with xdp. Fixes: 18c602dee472 ("qede: Use NETIF_F_GRO_HW.") Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Reviewed-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit cfa681271c347a089ef9104c17400978fef7a9e9 Author: John Hurley Date: Tue Dec 17 11:28:56 2019 +0000 nfp: flower: fix stats id allocation [ Upstream commit 39f14c00b13c47186739a4cbc7a16e04d7fdbb60 ] As flower rules are added, they are given a stats ID based on the number of rules that can be supported in firmware. Only after the initial allocation of all available IDs does the driver begin to reuse those that have been released. The initial allocation of IDs was modified to account for multiple memory units on the offloaded device. However, this introduced a bug whereby the counter that controls the IDs could be decremented before the ID was assigned (where it is further decremented). This means that the stats ID could be assigned as -1/0xfffffff which is out of range. Fix this by only decrementing the main counter after the current ID has been assigned. Fixes: 467322e2627f ("nfp: flower: support multiple memory units for filter offloads") Signed-off-by: John Hurley Reviewed-by: Jakub Kicinski Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit eaf60f6e25943848992bc893b0d15a0c113403d7 Author: Cristian Birsan Date: Thu Dec 12 13:52:47 2019 +0200 net: usb: lan78xx: Fix suspend/resume PHY register access error [ Upstream commit 20032b63586ac6c28c936dff696981159913a13f ] Lan78xx driver accesses the PHY registers through MDIO bus over USB connection. When performing a suspend/resume, the PHY registers can be accessed before the USB connection is resumed. This will generate an error and will prevent the device to resume correctly. This patch adds the dependency between the MDIO bus and USB device to allow correct handling of suspend/resume. Fixes: ce85e13ad6ef ("lan78xx: Update to use phylib instead of mii_if_info.") Signed-off-by: Cristian Birsan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fd2dab111303e506a27e9804bfcaf04341cddd15 Author: Jouni Hogander Date: Tue Dec 17 13:46:34 2019 +0200 net-sysfs: Call dev_hold always in rx_queue_add_kobject [ Upstream commit ddd9b5e3e765d8ed5a35786a6cb00111713fe161 ] Dev_hold has to be called always in rx_queue_add_kobject. Otherwise usage count drops below 0 in case of failure in kobject_init_and_add. Fixes: b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") Reported-by: syzbot Cc: Tetsuo Handa Cc: David Miller Cc: Lukas Bulwahn Signed-off-by: Jouni Hogander Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3b1924a607cb015cc929b3ced215d3ca61f1062d Author: Ben Hutchings Date: Tue Dec 17 01:57:40 2019 +0000 net: qlogic: Fix error paths in ql_alloc_large_buffers() [ Upstream commit cad46039e4c99812db067c8ac22a864960e7acc4 ] ql_alloc_large_buffers() has the usual RX buffer allocation loop where it allocates skbs and maps them for DMA. It also treats failure as a fatal error. There are (at least) three bugs in the error paths: 1. ql_free_large_buffers() assumes that the lrg_buf[] entry for the first buffer that couldn't be allocated will have .skb == NULL. But the qla_buf[] array is not zero-initialised. 2. ql_free_large_buffers() DMA-unmaps all skbs in lrg_buf[]. This is incorrect for the last allocated skb, if DMA mapping failed. 3. Commit 1acb8f2a7a9f ("net: qlogic: Fix memory leak in ql_alloc_large_buffers") added a direct call to dev_kfree_skb_any() after the skb is recorded in lrg_buf[], so ql_free_large_buffers() will double-free it. The bugs are somewhat inter-twined, so fix them all at once: * Clear each entry in qla_buf[] before attempting to allocate an skb for it. This goes half-way to fixing bug 1. * Set the .skb field only after the skb is DMA-mapped. This fixes the rest. Fixes: 1357bfcf7106 ("qla3xxx: Dynamically size the rx buffer queue ...") Fixes: 0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() ...") Fixes: 1acb8f2a7a9f ("net: qlogic: Fix memory leak in ql_alloc_large_buffers") Signed-off-by: Ben Hutchings Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 12cb21121028c19a020fdc97c81b7e841ef31bb0 Author: Russell King Date: Thu Dec 19 23:24:52 2019 +0000 net: phy: ensure that phy IDs are correctly typed [ Upstream commit 7d49a32a66d2215c5b3bf9bc67c9036ea9904111 ] PHY IDs are 32-bit unsigned quantities. Ensure that they are always treated as such, and not passed around as "int"s. Fixes: 13d0ab6750b2 ("net: phy: check return code when requesting PHY driver module") Signed-off-by: Russell King Reviewed-by: Florian Fainelli Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 65084e27a170642f4bbd39b5677d425d332b72e3 Author: Jia-Ju Bai Date: Wed Dec 18 17:21:55 2019 +0800 net: nfc: nci: fix a possible sleep-in-atomic-context bug in nci_uart_tty_receive() [ Upstream commit b7ac893652cafadcf669f78452329727e4e255cc ] The kernel may sleep while holding a spinlock. The function call path (from bottom to top) in Linux 4.19 is: net/nfc/nci/uart.c, 349: nci_skb_alloc in nci_uart_default_recv_buf net/nfc/nci/uart.c, 255: (FUNC_PTR)nci_uart_default_recv_buf in nci_uart_tty_receive net/nfc/nci/uart.c, 254: spin_lock in nci_uart_tty_receive nci_skb_alloc(GFP_KERNEL) can sleep at runtime. (FUNC_PTR) means a function pointer is called. To fix this bug, GFP_KERNEL is replaced with GFP_ATOMIC for nci_skb_alloc(). This bug is found by a static analysis tool STCheck written by myself. Signed-off-by: Jia-Ju Bai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit e32473a7f768070f42286ecf8199a6287af936c3 Author: Jiangfeng Xiao Date: Thu Dec 19 10:08:07 2019 +0800 net: hisilicon: Fix a BUG trigered by wrong bytes_compl [ Upstream commit 90b3b339364c76baa2436445401ea9ade040c216 ] When doing stress test, we get the following trace: kernel BUG at lib/dynamic_queue_limits.c:26! Internal error: Oops - BUG: 0 [#1] SMP ARM Modules linked in: hip04_eth CPU: 0 PID: 2003 Comm: tDblStackPcap0 Tainted: G O L 4.4.197 #1 Hardware name: Hisilicon A15 task: c3637668 task.stack: de3bc000 PC is at dql_completed+0x18/0x154 LR is at hip04_tx_reclaim+0x110/0x174 [hip04_eth] pc : [] lr : [] psr: 800f0313 sp : de3bdc2c ip : 00000000 fp : c020fb10 r10: 00000000 r9 : c39b4224 r8 : 00000001 r7 : 00000046 r6 : c39b4000 r5 : 0078f392 r4 : 0078f392 r3 : 00000047 r2 : 00000000 r1 : 00000046 r0 : df5d5c80 Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 32c5387d Table: 1e189b80 DAC: 55555555 Process tDblStackPcap0 (pid: 2003, stack limit = 0xde3bc190) Stack: (0xde3bdc2c to 0xde3be000) [] (dql_completed) from [] (hip04_tx_reclaim+0x110/0x174 [hip04_eth]) [] (hip04_tx_reclaim [hip04_eth]) from [] (hip04_rx_poll+0x20/0x388 [hip04_eth]) [] (hip04_rx_poll [hip04_eth]) from [] (net_rx_action+0x120/0x374) [] (net_rx_action) from [] (__do_softirq+0x218/0x318) [] (__do_softirq) from [] (irq_exit+0x88/0xac) [] (irq_exit) from [] (msa_irq_exit+0x11c/0x1d4) [] (msa_irq_exit) from [] (__handle_domain_irq+0x110/0x148) [] (__handle_domain_irq) from [] (gic_handle_irq+0xd4/0x118) [] (gic_handle_irq) from [] (__irq_svc+0x40/0x58) Exception stack(0xde3bdde0 to 0xde3bde28) dde0: 00000000 00008001 c3637668 00000000 00000000 a00f0213 dd3627a0 c0af6380 de00: c086d380 a00f0213 c0a22a50 de3bde6c 00000002 de3bde30 c0558138 c055813c de20: 600f0213 ffffffff [] (__irq_svc) from [] (_raw_spin_unlock_irqrestore+0x44/0x54) Kernel panic - not syncing: Fatal exception in interrupt Pre-modification code: int hip04_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev) { [...] [1] priv->tx_head = TX_NEXT(tx_head); [2] count++; [3] netdev_sent_queue(ndev, skb->len); [...] } An rx interrupt occurs if hip04_mac_start_xmit just executes to the line 2, tx_head has been updated, but corresponding 'skb->len' has not been added to dql_queue. And then hip04_mac_interrupt->__napi_schedule->hip04_rx_poll->hip04_tx_reclaim In hip04_tx_reclaim, because tx_head has been updated, bytes_compl will plus an additional "skb-> len" which has not been added to dql_queue. And then trigger the BUG_ON(bytes_compl > num_queued - dql->num_completed). To solve the problem described above, we put "netdev_sent_queue(ndev, skb->len);" before "priv->tx_head = TX_NEXT(tx_head);" Fixes: a41ea46a9a12 ("net: hisilicon: new hip04 ethernet driver") Signed-off-by: Jiangfeng Xiao Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 3740ae3cb4aceb451db75bc825cdc82f2e82e9b1 Author: Navid Emamdoost Date: Sat Dec 14 19:10:44 2019 -0600 net: gemini: Fix memory leak in gmac_setup_txqs [ Upstream commit f37f710353677639bc5d37ee785335994adf2529 ] In the implementation of gmac_setup_txqs() the allocated desc_ring is leaked if TX queue base is not aligned. Release it via dma_free_coherent. Fixes: 4d5ae32f5e1e ("net: ethernet: Add a driver for Gemini gigabit ethernet") Signed-off-by: Navid Emamdoost Reviewed-by: Linus Walleij Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f0465803facbf70f88e4dac8db2166a00da896c8 Author: Geert Uytterhoeven Date: Fri Dec 20 14:31:40 2019 +0100 net: dst: Force 4-byte alignment of dst_metrics [ Upstream commit 258a980d1ec23e2c786e9536a7dd260bea74bae6 ] When storing a pointer to a dst_metrics structure in dst_entry._metrics, two flags are added in the least significant bits of the pointer value. Hence this assumes all pointers to dst_metrics structures have at least 4-byte alignment. However, on m68k, the minimum alignment of 32-bit values is 2 bytes, not 4 bytes. Hence in some kernel builds, dst_default_metrics may be only 2-byte aligned, leading to obscure boot warnings like: WARNING: CPU: 0 PID: 7 at lib/refcount.c:28 refcount_warn_saturate+0x44/0x9a refcount_t: underflow; use-after-free. Modules linked in: CPU: 0 PID: 7 Comm: ksoftirqd/0 Tainted: G W 5.5.0-rc2-atari-01448-g114a1a1038af891d-dirty #261 Stack from 10835e6c: 10835e6c 0038134f 00023fa6 00394b0f 0000001c 00000009 00321560 00023fea 00394b0f 0000001c 001a70f8 00000009 00000000 10835eb4 00000001 00000000 04208040 0000000a 00394b4a 10835ed4 00043aa8 001a70f8 00394b0f 0000001c 00000009 00394b4a 0026aba8 003215a4 00000003 00000000 0026d5a8 00000001 003215a4 003a4361 003238d6 000001f0 00000000 003215a4 10aa3b00 00025e84 003ddb00 10834000 002416a8 10aa3b00 00000000 00000080 000aa038 0004854a Call Trace: [<00023fa6>] __warn+0xb2/0xb4 [<00023fea>] warn_slowpath_fmt+0x42/0x64 [<001a70f8>] refcount_warn_saturate+0x44/0x9a [<00043aa8>] printk+0x0/0x18 [<001a70f8>] refcount_warn_saturate+0x44/0x9a [<0026aba8>] refcount_sub_and_test.constprop.73+0x38/0x3e [<0026d5a8>] ipv4_dst_destroy+0x5e/0x7e [<00025e84>] __local_bh_enable_ip+0x0/0x8e [<002416a8>] dst_destroy+0x40/0xae Fix this by forcing 4-byte alignment of all dst_metrics structures. Fixes: e5fd387ad5b30ca3 ("ipv6: do not overwrite inetpeer metrics prematurely") Signed-off-by: Geert Uytterhoeven Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 1868166948b8f2ed2e3d5b53e7feec70231d158e Author: Russell King Date: Thu Dec 19 23:24:47 2019 +0000 mod_devicetable: fix PHY module format [ Upstream commit d2ed49cf6c13e379c5819aa5ac20e1f9674ebc89 ] When a PHY is probed, if the top bit is set, we end up requesting a module with the string "mdio:-10101110000000100101000101010001" - the top bit is printed to a signed -1 value. This leads to the module not being loaded. Fix the module format string and the macro generating the values for it to ensure that we only print unsigned types and the top bit is always 0/1. We correctly end up with "mdio:10101110000000100101000101010001". Fixes: 8626d3b43280 ("phylib: Support phy module autoloading") Reviewed-by: Andrew Lunn Signed-off-by: Russell King Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0cb8ada291917c1e6e20384d89bb4147e8a427fd Author: Chuhong Yuan Date: Tue Dec 10 00:22:07 2019 +0800 fjes: fix missed check in fjes_acpi_add [ Upstream commit a288f105a03a7e0e629a8da2b31f34ebf0343ee2 ] fjes_acpi_add() misses a check for platform_device_register_simple(). Add a check to fix it. Fixes: 658d439b2292 ("fjes: Introduce FUJITSU Extended Socket Network Device driver") Signed-off-by: Chuhong Yuan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 772f76457932305e63e2b796228158b842830022 Author: Mao Wenan Date: Mon Dec 9 21:31:25 2019 +0800 af_packet: set defaule value for tmo [ Upstream commit b43d1f9f7067c6759b1051e8ecb84e82cef569fe ] There is softlockup when using TPACKET_V3: ... NMI watchdog: BUG: soft lockup - CPU#2 stuck for 60010ms! (__irq_svc) from [] (_raw_spin_unlock_irqrestore+0x44/0x54) (_raw_spin_unlock_irqrestore) from [] (mod_timer+0x210/0x25c) (mod_timer) from [] (prb_retire_rx_blk_timer_expired+0x68/0x11c) (prb_retire_rx_blk_timer_expired) from [] (call_timer_fn+0x90/0x17c) (call_timer_fn) from [] (run_timer_softirq+0x2d4/0x2fc) (run_timer_softirq) from [] (__do_softirq+0x218/0x318) (__do_softirq) from [] (irq_exit+0x88/0xac) (irq_exit) from [] (msa_irq_exit+0x11c/0x1d4) (msa_irq_exit) from [] (handle_IPI+0x650/0x7f4) (handle_IPI) from [] (gic_handle_irq+0x108/0x118) (gic_handle_irq) from [] (__irq_usr+0x44/0x5c) ... If __ethtool_get_link_ksettings() is failed in prb_calc_retire_blk_tmo(), msec and tmo will be zero, so tov_in_jiffies is zero and the timer expire for retire_blk_timer is turn to mod_timer(&pkc->retire_blk_timer, jiffies + 0), which will trigger cpu usage of softirq is 100%. Fixes: f6fb8f100b80 ("af-packet: TPACKET_V3 flexible buffer implementation.") Tested-by: Xiao Jiangfeng Signed-off-by: Mao Wenan Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman