commit 9d61432efb21c224b710f397809f3a4fef281f9c Author: Greg Kroah-Hartman Date: Sun Jan 12 12:21:53 2020 +0100 Linux 5.4.11 commit 7cbdf96cda1fbffb17ec26ea65e1fe63c9aed430 Author: Qi Zhou Date: Sat Jan 4 11:02:01 2020 +0000 usb: missing parentheses in USE_NEW_SCHEME commit 1530f6f5f5806b2abbf2a9276c0db313ae9a0e09 upstream. According to bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") the kernel will try the old enumeration scheme first for high speed devices. This can happen when a high speed device is plugged in. But due to missing parentheses in the USE_NEW_SCHEME define, this logic can get messed up and the incorrect result happens. Acked-by: Alan Stern Signed-off-by: Qi Zhou Link: https://lore.kernel.org/r/ht4mtag8ZP-HKEhD0KkJhcFnVlOFV8N8eNjJVRD9pDkkLUNhmEo8_cL_sl7xy9mdajdH-T8J3TFQsjvoYQT61NFjQXy469Ed_BbBw_x4S1E=@protonmail.com [ fixup changelog text - gregkh] Cc: stable Fixes: bd0e6c9614b9 ("usb: hub: try old enumeration scheme first for high speed devices") Signed-off-by: Greg Kroah-Hartman commit 093d658a06cd1831c629ceeee207572895c1a872 Author: Daniele Palmas Date: Fri Dec 13 14:56:15 2019 +0100 USB: serial: option: add Telit ME910G1 0x110a composition commit 0d3010fa442429f8780976758719af05592ff19f upstream. This patch adds the following Telit ME910G1 composition: 0x110a: tty, tty, tty, rmnet Signed-off-by: Daniele Palmas Cc: stable Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman commit 578289f8476c3044f73ff15e138bfca555567ffe Author: Johan Hovold Date: Thu Dec 19 17:10:16 2019 +0100 USB: core: fix check for duplicate endpoints commit 3e4f8e21c4f27bcf30a48486b9dcc269512b79ff upstream. Amend the endpoint-descriptor sanity checks to detect all duplicate endpoint addresses in a configuration. Commit 0a8fd1346254 ("USB: fix problems with duplicate endpoint addresses") added a check for duplicate endpoint addresses within a single alternate setting, but did not look for duplicate addresses in other interfaces. The current check would also not detect all duplicate addresses when one endpoint is as a (bi-directional) control endpoint. This specifically avoids overwriting the endpoint entries in struct usb_device when enabling a duplicate endpoint, something which could potentially lead to crashes or leaks, for example, when endpoints are later disabled. Cc: stable Signed-off-by: Johan Hovold Acked-by: Alan Stern Link: https://lore.kernel.org/r/20191219161016.6695-1-johan@kernel.org Signed-off-by: Greg Kroah-Hartman commit 158cbd970b0efc501c2a5cb64bd6a879bf61fc39 Author: Thinh Nguyen Date: Fri Dec 13 18:40:45 2019 -0800 usb: dwc3: gadget: Fix request complete check commit ea0d762775e20aaff7909a3f0866ff1688b1c618 upstream. We can only check for IN direction if the request had completed. For OUT direction, it's perfectly fine that the host can send less than the setup length. Let's return true fall all cases of OUT direction. Fixes: e0c42ce590fe ("usb: dwc3: gadget: simplify IOC handling") Cc: stable@vger.kernel.org Signed-off-by: Thinh Nguyen Link: https://lore.kernel.org/r/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.com Signed-off-by: Greg Kroah-Hartman commit edac9ecdf48da11fbc9ba944a1e9a7d5987e9c35 Author: Erez Shitrit Date: Mon Nov 25 10:26:24 2019 +0200 net/mlx5: DR, Init lists that are used in rule's member [ Upstream commit df55c5586e5185f890192a6802dc5b46fddd3606 ] Whenever adding new member of rule object we attach it to 2 lists, These 2 lists should be initialized first. Fixes: 41d07074154c ("net/mlx5: DR, Expose steering rule functionality") Signed-off-by: Erez Shitrit Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit caef8a716245726ede87417113db03f045fc1989 Author: Eli Cohen Date: Wed Dec 11 09:17:40 2019 +0200 net/mlx5e: Fix hairpin RSS table size [ Upstream commit 6412bb396a63f28de994b1480edf8e4caf4aa494 ] Set hairpin table size to the corret size, based on the groups that would be created in it. Groups are laid out on the table such that a group occupies a range of entries in the table. This implies that the group ranges should have correspondence to the table they are laid upon. The patch cited below made group 1's size to grow hence causing overflow of group range laid on the table. Fixes: a795d8db2a6d ("net/mlx5e: Support RSS for IP-in-IP and IPv6 tunneled packets") Signed-off-by: Eli Cohen Signed-off-by: Mark Bloch Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit c48a78c083e6e25801d3af67a18ed9552c883bf5 Author: Yevgeny Kliteynik Date: Mon Dec 23 16:16:31 2019 +0200 net/mlx5: DR, No need for atomic refcount for internal SW steering resources [ Upstream commit 4ce380ca477507e2f413584cdd99e1698d6682d6 ] No need for an atomic refcounter for the STE and hashtables. These are internal SW steering resources and they are always under domain mutex. This also fixes the following refcount error: refcount_t: addition on 0; use-after-free. WARNING: CPU: 9 PID: 3527 at lib/refcount.c:25 refcount_warn_saturate+0x81/0xe0 Call Trace: dr_table_init_nic+0x10d/0x110 [mlx5_core] mlx5dr_table_create+0xb4/0x230 [mlx5_core] mlx5_cmd_dr_create_flow_table+0x39/0x120 [mlx5_core] __mlx5_create_flow_table+0x221/0x5f0 [mlx5_core] esw_create_offloads_fdb_tables+0x180/0x5a0 [mlx5_core] ... Fixes: 26d688e33f88 ("net/mlx5: DR, Add Steering entry (STE) utilities") Signed-off-by: Yevgeny Kliteynik Reviewed-by: Alex Vesker Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit 0c3990776fca7349acf560049de6aaa18a6e56ba Author: Eran Ben Elisha Date: Wed Dec 4 14:34:18 2019 +0200 net/mlx5e: Always print health reporter message to dmesg [ Upstream commit 99cda45426c9a2c59bb2f7cb886a405440282455 ] In case a reporter exists, error message is logged only to the devlink tracer. The devlink tracer is a visibility utility only, which user can choose not to monitor. After cited patch, 3rd party monitoring tools that tracks these error message will no longer find them in dmesg, causing a regression. With this patch, error messages are also logged into the dmesg. Fixes: c50de4af1d63 ("net/mlx5e: Generalize tx reporter's functionality") Signed-off-by: Eran Ben Elisha Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit a51aa28f46763f79cfa1fd8ffc5e45c1967e3550 Author: Baruch Siach Date: Thu Dec 19 11:48:22 2019 +0200 net: dsa: mv88e6xxx: force cmode write on 6141/6341 [ Upstream commit f7a48b68abd9b20ce1ac6298aaaa3c4d158271dd ] mv88e6xxx_port_set_cmode() relies on cmode stored in struct mv88e6xxx_port to skip cmode update when the requested value matches the cached value. It turns out that mv88e6xxx_port_hidden_write() might change the port cmode setting as a side effect, so we can't rely on the cached value to determine that cmode update in not necessary. Force cmode update in mv88e6341_port_set_cmode(), to make serdes configuration work again. Other mv88e6xxx_port_set_cmode() callers keep the current behaviour. This fixes serdes configuration of the 6141 switch on SolidRun Clearfog GT-8K. Fixes: 7a3007d22e8 ("net: dsa: mv88e6xxx: fully support SERDES on Topaz family") Reported-by: Denis Odintsov Signed-off-by: Baruch Siach Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 0ce3f9f1fdea65ada400c2c45f76a719c5b9f4a4 Author: Michael Guralnik Date: Wed Nov 20 11:43:49 2019 +0200 net/mlx5: Move devlink registration before interfaces load [ Upstream commit a6f3b62386a02c1e94bfa22c543f82d63f5e631b ] Register devlink before interfaces are added. This will allow interfaces to use devlink while initalizing. For example, call mlx5_is_roce_enabled. Fixes: aba25279c100 ("net/mlx5e: Add TX reporter support") Signed-off-by: Michael Guralnik Signed-off-by: Saeed Mahameed Signed-off-by: Greg Kroah-Hartman commit f479506e5164cb9eff4c60531bd48026dd433e4a Author: Stephen Boyd Date: Fri Jan 3 16:19:21 2020 -0800 macb: Don't unregister clks unconditionally [ Upstream commit d89091a4930ee0d80bee3e259a98513f3a2543ec ] The only clk init function in this driver that register a clk is fu540_c000_clk_init(), and thus we need to unregister the clk when this driver is removed on that platform. Other init functions, for example macb_clk_init(), don't register clks and therefore we shouldn't unregister the clks when this driver is removed. Convert this registration path to devm so it gets auto-unregistered when this driver is removed and drop the clk_unregister() calls in driver remove (and error paths) so that we don't erroneously remove a clk from the system that isn't registered by this driver. Otherwise we get strange crashes with a use-after-free when the devm_clk_get() call in macb_clk_init() calls clk_put() on a clk pointer that has become invalid because it is freed in clk_unregister(). Cc: Nicolas Ferre Cc: Yash Shah Reported-by: Guenter Roeck Fixes: c218ad559020 ("macb: Add support for SiFive FU540-C000") Signed-off-by: Stephen Boyd Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 25037e4b197bf04a9c8467b9ce1d76aefc8fa703 Author: Eric Dumazet Date: Tue Jan 7 01:42:25 2020 -0800 vlan: vlan_changelink() should propagate errors [ Upstream commit eb8ef2a3c50092bb018077c047b8dba1ce0e78e3 ] Both vlan_dev_change_flags() and vlan_dev_set_egress_priority() can return an error. vlan_changelink() should not ignore them. Fixes: 07b5b17e157b ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 196a9a408c3eb8f590f0f7088cafe80c7c1564e7 Author: Eric Dumazet Date: Tue Jan 7 01:42:24 2020 -0800 vlan: fix memory leak in vlan_dev_set_egress_priority [ Upstream commit 9bbd917e0bec9aebdbd0c8dbc966caec15eb33e9 ] There are few cases where the ndo_uninit() handler might be not called if an error happens while device is initialized. Since vlan_newlink() calls vlan_changelink() before trying to register the netdevice, we need to make sure vlan_dev_uninit() has been called at least once, or we might leak allocated memory. BUG: memory leak unreferenced object 0xffff888122a206c0 (size 32): comm "syz-executor511", pid 7124, jiffies 4294950399 (age 32.240s) hex dump (first 32 bytes): 00 00 00 00 00 00 61 73 00 00 00 00 00 00 00 00 ......as........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000000eb3bb85>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] [<000000000eb3bb85>] slab_post_alloc_hook mm/slab.h:586 [inline] [<000000000eb3bb85>] slab_alloc mm/slab.c:3320 [inline] [<000000000eb3bb85>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3549 [<000000007b99f620>] kmalloc include/linux/slab.h:556 [inline] [<000000007b99f620>] vlan_dev_set_egress_priority+0xcc/0x150 net/8021q/vlan_dev.c:194 [<000000007b0cb745>] vlan_changelink+0xd6/0x140 net/8021q/vlan_netlink.c:126 [<0000000065aba83a>] vlan_newlink+0x135/0x200 net/8021q/vlan_netlink.c:181 [<00000000fb5dd7a2>] __rtnl_newlink+0x89a/0xb80 net/core/rtnetlink.c:3305 [<00000000ae4273a1>] rtnl_newlink+0x4e/0x80 net/core/rtnetlink.c:3363 [<00000000decab39f>] rtnetlink_rcv_msg+0x178/0x4b0 net/core/rtnetlink.c:5424 [<00000000accba4ee>] netlink_rcv_skb+0x61/0x170 net/netlink/af_netlink.c:2477 [<00000000319fe20f>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 [<00000000d51938dc>] netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] [<00000000d51938dc>] netlink_unicast+0x223/0x310 net/netlink/af_netlink.c:1328 [<00000000e539ac79>] netlink_sendmsg+0x2c0/0x570 net/netlink/af_netlink.c:1917 [<000000006250c27e>] sock_sendmsg_nosec net/socket.c:639 [inline] [<000000006250c27e>] sock_sendmsg+0x54/0x70 net/socket.c:659 [<00000000e2a156d1>] ____sys_sendmsg+0x2d0/0x300 net/socket.c:2330 [<000000008c87466e>] ___sys_sendmsg+0x8a/0xd0 net/socket.c:2384 [<00000000110e3054>] __sys_sendmsg+0x80/0xf0 net/socket.c:2417 [<00000000d71077c8>] __do_sys_sendmsg net/socket.c:2426 [inline] [<00000000d71077c8>] __se_sys_sendmsg net/socket.c:2424 [inline] [<00000000d71077c8>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2424 Fixe: 07b5b17e157b ("[VLAN]: Use rtnl_link API") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit c6e324d0cbb2e3096290ce7329039d76a3c18dfb Author: Petr Machata Date: Mon Jan 6 18:01:56 2020 +0000 net: sch_prio: When ungrafting, replace with FIFO [ Upstream commit 240ce7f6428ff5188b9eedc066e1e4d645b8635f ] When a child Qdisc is removed from one of the PRIO Qdisc's bands, it is replaced unconditionally by a NOOP qdisc. As a result, any traffic hitting that band gets dropped. That is incorrect--no Qdisc was explicitly added when PRIO was created, and after removal, none should have to be added either. Fix PRIO by first attempting to create a default Qdisc and only falling back to noop when that fails. This pattern of attempting to create an invisible FIFO, using NOOP only as a fallback, is also seen in other Qdiscs. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Petr Machata Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit f39007afe7f02a9a6619e848e20611ecf2260f67 Author: Petr Machata Date: Mon Jan 6 18:01:55 2020 +0000 mlxsw: spectrum_qdisc: Ignore grafting of invisible FIFO [ Upstream commit 3971a535b839489e4ea31796cc086e6ce616318c ] The following patch will change PRIO to replace a removed Qdisc with an invisible FIFO, instead of NOOP. mlxsw will see this replacement due to the graft message that is generated. But because FIFO does not issue its own REPLACE message, when the graft operation takes place, the Qdisc that mlxsw tracks under the indicated band is still the old one. The child handle (0:0) therefore does not match, and mlxsw rejects the graft operation, which leads to an extack message: Warning: Offloading graft operation failed. Fix by ignoring the invisible children in the PRIO graft handler. The DESTROY message of the removed Qdisc is going to follow shortly and handle the removal. Fixes: 32dc5efc6cb4 ("mlxsw: spectrum: qdiscs: prio: Handle graft command") Signed-off-by: Petr Machata Acked-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit a44ed37804e5bc491180e1257a935e4c95234a50 Author: Hangbin Liu Date: Thu Jan 2 17:23:45 2020 +0800 vxlan: fix tos value before xmit [ Upstream commit 71130f29979c7c7956b040673e6b9d5643003176 ] Before ip_tunnel_ecn_encap() and udp_tunnel_xmit_skb() we should filter tos value by RT_TOS() instead of using config tos directly. vxlan_get_route() would filter the tos to fl4.flowi4_tos but we didn't return it back, as geneve_get_v4_rt() did. So we have to use RT_TOS() directly in function ip_tunnel_ecn_encap(). Fixes: 206aaafcd279 ("VXLAN: Use IP Tunnels tunnel ENC encap API") Fixes: 1400615d64cf ("vxlan: allow setting ipv6 traffic class") Signed-off-by: Hangbin Liu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 68fe2b265a674fe479f09762a1c6ffa74e25cd43 Author: Pengcheng Yang Date: Mon Dec 30 17:54:41 2019 +0800 tcp: fix "old stuff" D-SACK causing SACK to be treated as D-SACK [ Upstream commit c9655008e7845bcfdaac10a1ed8554ec167aea88 ] When we receive a D-SACK, where the sequence number satisfies: undo_marker <= start_seq < end_seq <= prior_snd_una we consider this is a valid D-SACK and tcp_is_sackblock_valid() returns true, then this D-SACK is discarded as "old stuff", but the variable first_sack_index is not marked as negative in tcp_sacktag_write_queue(). If this D-SACK also carries a SACK that needs to be processed (for example, the previous SACK segment was lost), this SACK will be treated as a D-SACK in the following processing of tcp_sacktag_write_queue(), which will eventually lead to incorrect updates of undo_retrans and reordering. Fixes: fd6dad616d4f ("[TCP]: Earlier SACK block verification & simplify access to them") Signed-off-by: Pengcheng Yang Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 50027f1c78abced651d03e2a0d88b7caa2b9a0c2 Author: Xin Long Date: Sat Jan 4 14:15:02 2020 +0800 sctp: free cmd->obj.chunk for the unprocessed SCTP_CMD_REPLY [ Upstream commit be7a7729207797476b6666f046d765bdf9630407 ] This patch is to fix a memleak caused by no place to free cmd->obj.chunk for the unprocessed SCTP_CMD_REPLY. This issue occurs when failing to process a cmd while there're still SCTP_CMD_REPLY cmds on the cmd seq with an allocated chunk in cmd->obj.chunk. So fix it by freeing cmd->obj.chunk for each SCTP_CMD_REPLY cmd left on the cmd seq when any cmd returns error. While at it, also remove 'nomem' label. Reported-by: syzbot+107c4aff5f392bf1517f@syzkaller.appspotmail.com Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Xin Long Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 2895cea2889ae20fec5372e11b8343468f166ef7 Author: Wen Yang Date: Thu Jan 2 17:21:43 2020 +0800 sch_cake: avoid possible divide by zero in cake_enqueue() [ Upstream commit 68aab823c223646fab311f8a6581994facee66a0 ] The variables 'window_interval' is u64 and do_div() truncates it to 32 bits, which means it can test non-zero and be truncated to zero for division. The unit of window_interval is nanoseconds, so its lower 32-bit is relatively easy to exceed. Fix this issue by using div64_u64() instead. Fixes: 7298de9cd725 ("sch_cake: Add ingress mode") Signed-off-by: Wen Yang Cc: Kevin Darbyshire-Bryant Cc: Toke Høiland-Jørgensen Cc: David S. Miller Cc: Cong Wang Cc: cake@lists.bufferbloat.net Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by: Toke Høiland-Jørgensen Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8b9c77a59f9ee35a0b076e3db9009ba96d5b8395 Author: Eric Dumazet Date: Mon Jan 6 06:10:39 2020 -0800 pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM [ Upstream commit d9e15a2733067c9328fb56d98fe8e574fa19ec31 ] As diagnosed by Florian : If TCA_FQ_QUANTUM is set to 0x80000000, fq_deueue() can loop forever in : if (f->credit <= 0) { f->credit += q->quantum; goto begin; } ... because f->credit is either 0 or -2147483648. Let's limit TCA_FQ_QUANTUM to no more than 1 << 20 : This max value should limit risks of breaking user setups while fixing this bug. Fixes: afe4fd062416 ("pkt_sched: fq: Fair Queue packet scheduler") Signed-off-by: Eric Dumazet Diagnosed-by: Florian Westphal Reported-by: syzbot+dc9071cc5a85950bdfce@syzkaller.appspotmail.com Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 72cd84ea52407323b241571691b2426fb25c41ef Author: Eric Dumazet Date: Tue Jan 7 10:57:01 2020 -0800 net: usb: lan78xx: fix possible skb leak [ Upstream commit 47240ba0cd09bb6fe6db9889582048324999dfa4 ] If skb_linearize() fails, we need to free the skb. TSO makes skb bigger, and this bug might be the reason Raspberry Pi 3B+ users had to disable TSO. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Eric Dumazet Reported-by: RENARD Pierre-Francois Cc: Stefan Wahren Cc: Woojung Huh Cc: Microchip Linux Driver Support Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 4e30ea665d9b708711294e9deebfeff15f90a1de Author: Jose Abreu Date: Tue Jan 7 13:35:42 2020 +0100 net: stmmac: Fixed link does not need MDIO Bus [ Upstream commit da29f2d84bd10234df570b7f07cbd0166e738230 ] When using fixed link we don't need the MDIO bus support. Reported-by: Heiko Stuebner Reported-by: kernelci.org bot Fixes: d3e014ec7d5e ("net: stmmac: platform: Fix MDIO init for platforms without PHY") Signed-off-by: Jose Abreu Acked-by: Sriram Dash Tested-by: Patrice Chotard Tested-by: Heiko Stuebner Acked-by: Neil Armstrong Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli # Lamobo R1 (fixed-link + MDIO sub node for roboswitch). Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 97e090055954e74491feca36702ba9250a0f05af Author: Chen-Yu Tsai Date: Mon Jan 6 11:09:22 2020 +0800 net: stmmac: dwmac-sunxi: Allow all RGMII modes [ Upstream commit 52cc73e5404c7ba0cbfc50cb4c265108c84b3d5a ] Allow all the RGMII modes to be used. This would allow us to represent the hardware better in the device tree with RGMII_ID where in most cases the PHY's internal delay for both RX and TX are used. Fixes: af0bd4e9ba80 ("net: stmmac: sunxi platform extensions for GMAC in Allwinner A20 SoC's") Signed-off-by: Chen-Yu Tsai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 8fa024288d6eabfb61a52a5d7811737b2fc7aa3b Author: Chen-Yu Tsai Date: Mon Jan 6 11:09:45 2020 +0800 net: stmmac: dwmac-sun8i: Allow all RGMII modes [ Upstream commit f1239d8aa84dad8fe4b6cc1356f40fc8e842db47 ] Allow all the RGMII modes to be used. This would allow us to represent the hardware better in the device tree with RGMII_ID where in most cases the PHY's internal delay for both RX and TX are used. Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i") Signed-off-by: Chen-Yu Tsai Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 330ba6035be7b38c5c7a4f5e5c63007a21a5c226 Author: Andrew Lunn Date: Thu Jan 2 15:33:34 2020 +0100 net: freescale: fec: Fix ethtool -d runtime PM [ Upstream commit c72a0bc0aa19f49160330a65ab77184b5b7d131b ] In order to dump the FECs registers the clocks have to be ticking, otherwise a data abort occurs. Add calls to runtime PM so they are enabled and later disabled. Fixes: e8fcfcd5684a ("net: fec: optimize the clock management to save power") Reported-by: Chris Healy Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit d9ffa1062adf8fb92fcc0ddb165facd42b9e68a2 Author: Andrew Lunn Date: Sat Jan 4 23:14:51 2020 +0100 net: dsa: mv88e6xxx: Preserve priority when setting CPU port. [ Upstream commit d8dc2c9676e614ef62f54a155b50076888c8a29a ] The 6390 family uses an extended register to set the port connected to the CPU. The lower 5 bits indicate the port, the upper three bits are the priority of the frames as they pass through the switch, what egress queue they should use, etc. Since frames being set to the CPU are typically management frames, BPDU, IGMP, ARP, etc set the priority to 7, the reset default, and the highest. Fixes: 33641994a676 ("net: dsa: mv88e6xxx: Monitor and Management tables") Signed-off-by: Andrew Lunn Tested-by: Chris Healy Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 74165c1ca31d58c1749bda5726661bd817eaa7d1 Author: Eric Dumazet Date: Mon Jan 6 12:30:48 2020 -0800 macvlan: do not assume mac_header is set in macvlan_broadcast() [ Upstream commit 96cc4b69581db68efc9749ef32e9cf8e0160c509 ] Use of eth_hdr() in tx path is error prone. Many drivers call skb_reset_mac_header() before using it, but others do not. Commit 6d1ccff62780 ("net: reset mac header in dev_start_xmit()") attempted to fix this generically, but commit d346a3fae3ff ("packet: introduce PACKET_QDISC_BYPASS socket option") brought back the macvlan bug. Lets add a new helper, so that tx paths no longer have to call skb_reset_mac_header() only to get a pointer to skb->data. Hopefully we will be able to revert 6d1ccff62780 ("net: reset mac header in dev_start_xmit()") and save few cycles in transmit fast path. BUG: KASAN: use-after-free in __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline] BUG: KASAN: use-after-free in mc_hash drivers/net/macvlan.c:251 [inline] BUG: KASAN: use-after-free in macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277 Read of size 4 at addr ffff8880a4932401 by task syz-executor947/9579 CPU: 0 PID: 9579 Comm: syz-executor947 Not tainted 5.5.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 kasan_report+0x12/0x20 mm/kasan/common.c:639 __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:145 __get_unaligned_cpu32 include/linux/unaligned/packed_struct.h:19 [inline] mc_hash drivers/net/macvlan.c:251 [inline] macvlan_broadcast+0x547/0x620 drivers/net/macvlan.c:277 macvlan_queue_xmit drivers/net/macvlan.c:520 [inline] macvlan_start_xmit+0x402/0x77f drivers/net/macvlan.c:559 __netdev_start_xmit include/linux/netdevice.h:4447 [inline] netdev_start_xmit include/linux/netdevice.h:4461 [inline] dev_direct_xmit+0x419/0x630 net/core/dev.c:4079 packet_direct_xmit+0x1a9/0x250 net/packet/af_packet.c:240 packet_snd net/packet/af_packet.c:2966 [inline] packet_sendmsg+0x260d/0x6220 net/packet/af_packet.c:2991 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 __sys_sendto+0x262/0x380 net/socket.c:1985 __do_sys_sendto net/socket.c:1997 [inline] __se_sys_sendto net/socket.c:1993 [inline] __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1993 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x442639 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 5b 10 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007ffc13549e08 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000442639 RDX: 000000000000000e RSI: 0000000020000080 RDI: 0000000000000003 RBP: 0000000000000004 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000403bb0 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 9389: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc mm/kasan/common.c:513 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:486 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:527 __do_kmalloc mm/slab.c:3656 [inline] __kmalloc+0x163/0x770 mm/slab.c:3665 kmalloc include/linux/slab.h:561 [inline] tomoyo_realpath_from_path+0xc5/0x660 security/tomoyo/realpath.c:252 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822 tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129 security_inode_getattr+0xf2/0x150 security/security.c:1222 vfs_getattr+0x25/0x70 fs/stat.c:115 vfs_statx_fd+0x71/0xc0 fs/stat.c:145 vfs_fstat include/linux/fs.h:3265 [inline] __do_sys_newfstat+0x9b/0x120 fs/stat.c:378 __se_sys_newfstat fs/stat.c:375 [inline] __x64_sys_newfstat+0x54/0x80 fs/stat.c:375 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 9389: save_stack+0x23/0x90 mm/kasan/common.c:72 set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:335 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:474 kasan_slab_free+0xe/0x10 mm/kasan/common.c:483 __cache_free mm/slab.c:3426 [inline] kfree+0x10a/0x2c0 mm/slab.c:3757 tomoyo_realpath_from_path+0x1a7/0x660 security/tomoyo/realpath.c:289 tomoyo_get_realpath security/tomoyo/file.c:151 [inline] tomoyo_path_perm+0x230/0x430 security/tomoyo/file.c:822 tomoyo_inode_getattr+0x1d/0x30 security/tomoyo/tomoyo.c:129 security_inode_getattr+0xf2/0x150 security/security.c:1222 vfs_getattr+0x25/0x70 fs/stat.c:115 vfs_statx_fd+0x71/0xc0 fs/stat.c:145 vfs_fstat include/linux/fs.h:3265 [inline] __do_sys_newfstat+0x9b/0x120 fs/stat.c:378 __se_sys_newfstat fs/stat.c:375 [inline] __x64_sys_newfstat+0x54/0x80 fs/stat.c:375 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at ffff8880a4932000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 1025 bytes inside of 4096-byte region [ffff8880a4932000, ffff8880a4933000) The buggy address belongs to the page: page:ffffea0002924c80 refcount:1 mapcount:0 mapping:ffff8880aa402000 index:0x0 compound_mapcount: 0 raw: 00fffe0000010200 ffffea0002846208 ffffea00028f3888 ffff8880aa402000 raw: 0000000000000000 ffff8880a4932000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880a4932300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4932380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880a4932400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880a4932480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880a4932500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: b863ceb7ddce ("[NET]: Add macvlan driver") Signed-off-by: Eric Dumazet Reported-by: syzbot Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ae026afaf5e68885ca3a2d95bbab0b289eba088d Author: Eric Dumazet Date: Mon Jan 6 06:45:37 2020 -0800 gtp: fix bad unlock balance in gtp_encap_enable_socket [ Upstream commit 90d72256addff9e5f8ad645e8f632750dd1f8935 ] WARNING: bad unlock balance detected! 5.5.0-rc5-syzkaller #0 Not tainted ------------------------------------- syz-executor921/9688 is trying to release lock (sk_lock-AF_INET6) at: [] gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830 but there are no more locks to release! other info that might help us debug this: 2 locks held by syz-executor921/9688: #0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnl_lock net/core/rtnetlink.c:72 [inline] #0: ffffffff8a4d8840 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x405/0xaf0 net/core/rtnetlink.c:5421 #1: ffff88809304b560 (slock-AF_INET6){+...}, at: spin_lock_bh include/linux/spinlock.h:343 [inline] #1: ffff88809304b560 (slock-AF_INET6){+...}, at: release_sock+0x20/0x1c0 net/core/sock.c:2951 stack backtrace: CPU: 0 PID: 9688 Comm: syz-executor921 Not tainted 5.5.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x197/0x210 lib/dump_stack.c:118 print_unlock_imbalance_bug kernel/locking/lockdep.c:4008 [inline] print_unlock_imbalance_bug.cold+0x114/0x123 kernel/locking/lockdep.c:3984 __lock_release kernel/locking/lockdep.c:4242 [inline] lock_release+0x5f2/0x960 kernel/locking/lockdep.c:4503 sock_release_ownership include/net/sock.h:1496 [inline] release_sock+0x17c/0x1c0 net/core/sock.c:2961 gtp_encap_enable_socket+0x146/0x400 drivers/net/gtp.c:830 gtp_encap_enable drivers/net/gtp.c:852 [inline] gtp_newlink+0x9fc/0xc60 drivers/net/gtp.c:666 __rtnl_newlink+0x109e/0x1790 net/core/rtnetlink.c:3305 rtnl_newlink+0x69/0xa0 net/core/rtnetlink.c:3363 rtnetlink_rcv_msg+0x45e/0xaf0 net/core/rtnetlink.c:5424 netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477 rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5442 netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline] netlink_unicast+0x58c/0x7d0 net/netlink/af_netlink.c:1328 netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1917 sock_sendmsg_nosec net/socket.c:639 [inline] sock_sendmsg+0xd7/0x130 net/socket.c:659 ____sys_sendmsg+0x753/0x880 net/socket.c:2330 ___sys_sendmsg+0x100/0x170 net/socket.c:2384 __sys_sendmsg+0x105/0x1d0 net/socket.c:2417 __do_sys_sendmsg net/socket.c:2426 [inline] __se_sys_sendmsg net/socket.c:2424 [inline] __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2424 do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x445d49 Code: e8 bc b7 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 2b 12 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:00007f8019074db8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000006dac38 RCX: 0000000000445d49 RDX: 0000000000000000 RSI: 0000000020000180 RDI: 0000000000000003 RBP: 00000000006dac30 R08: 0000000000000004 R09: 0000000000000000 R10: 0000000000000008 R11: 0000000000000246 R12: 00000000006dac3c R13: 00007ffea687f6bf R14: 00007f80190759c0 R15: 20c49ba5e353f7cf Fixes: e198987e7dd7 ("gtp: fix suspicious RCU usage") Signed-off-by: Eric Dumazet Reported-by: syzbot Cc: Taehee Yoo Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit b301cb2f19d081bd8e136e9c6466737d76031d44 Author: Steven Rostedt (VMware) Date: Mon Dec 2 16:25:27 2019 -0500 tracing: Do not create directories if lockdown is in affect commit a356646a56857c2e5ad875beec734d7145ecd49a upstream. If lockdown is disabling tracing on boot up, it prevents the tracing files from even bering created. But when that happens, there's several places that will give a warning that the files were not created as that is usually a sign of a bug. Add in strategic locations where a check is made to see if tracing is disabled by lockdown, and if it is, do not go further, and fail silently (but print that tracing is disabled by lockdown, without doing a WARN_ON()). Cc: Matthew Garrett Fixes: 17911ff38aa5 ("tracing: Add locked_down checks to the open calls of files created for tracefs") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 8b8cd873c727b8aa3e809d1d071b82f3f1968a53 Author: Hangbin Liu Date: Fri Dec 20 15:08:06 2019 +0800 selftests: pmtu: fix init mtu value in description [ Upstream commit 152044775d0b9a9ed9509caed40efcba2677951d ] There is no a_r3, a_r4 in the testing topology. It should be b_r1, b_r2. Also b_r1 mtu is 1400 and b_r2 mtu is 1500. Fixes: e44e428f59e4 ("selftests: pmtu: add basic IPv4 and IPv6 PMTU tests") Signed-off-by: Hangbin Liu Acked-by: Stefano Brivio Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f08f00f1ca3b912d64902c8cfea5e7059242602e Author: Haiyang Zhang Date: Thu Dec 19 18:28:10 2019 -0800 hv_netvsc: Fix unwanted rx_table reset [ Upstream commit b0689faa8efc5a3391402d7ae93bd373b7248e51 ] In existing code, the receive indirection table, rx_table, is in struct rndis_device, which will be reset when changing MTU, ringparam, etc. User configured receive indirection table values will be lost. To fix this, move rx_table to struct net_device_context, and check netif_is_rxfh_configured(), so rx_table will be set to default only if no user configured value. Fixes: ff4a44199012 ("netvsc: allow get/set of RSS indirection table") Signed-off-by: Haiyang Zhang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5485d62cf5fd2bfc1a4820d9432f7ba4b44e50fe Author: Chan Shu Tak, Alex Date: Thu Dec 19 14:16:18 2019 +0800 llc2: Fix return statement of llc_stat_ev_rx_null_dsap_xid_c (and _test_c) [ Upstream commit af1c0e4e00f3cc76cb136ebf2e2c04e8b6446285 ] When a frame with NULL DSAP is received, llc_station_rcv is called. In turn, llc_stat_ev_rx_null_dsap_xid_c is called to check if it is a NULL XID frame. The return statement of llc_stat_ev_rx_null_dsap_xid_c returns 1 when the incoming frame is not a NULL XID frame and 0 otherwise. Hence, a NULL XID response is returned unexpectedly, e.g. when the incoming frame is a NULL TEST command. To fix the error, simply remove the conditional operator. A similar error in llc_stat_ev_rx_null_dsap_test_c is also fixed. Signed-off-by: Chan Shu Tak, Alex Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 7a5f6b322e9d470ef1ab6c39f3dba7dc70716ceb Author: Julian Wiedmann Date: Wed Dec 18 16:32:28 2019 +0100 s390/qeth: don't return -ENOTSUPP to userspace [ Upstream commit 39bdbf3e648d801596498a5a625fbc9fc1c0002f ] ENOTSUPP is not uapi, use EOPNOTSUPP instead. Fixes: d66cb37e9664 ("qeth: Add new priority queueing options") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4a92d697ce5bbfc60d9a5025d14a282e9e058b9e Author: Julian Wiedmann Date: Wed Dec 18 16:32:27 2019 +0100 s390/qeth: fix promiscuous mode after reset [ Upstream commit 0f399305cd31e5c813086eaa264f7f47e205c10e ] When managing the promiscuous mode during an RX modeset, qeth caches the current HW state to avoid repeated programming of the same state on each modeset. But while tearing down a device, we forget to clear the cached state. So when the device is later set online again, the initial RX modeset doesn't program the promiscuous mode since we believe it is already enabled. Fix this by clearing the cached state in the tear-down path. Note that for the SBP variant of promiscuous mode, this accidentally works right now because we unconditionally restore the SBP role while re-initializing. Fixes: 4a71df50047f ("qeth: new qeth device driver") Signed-off-by: Julian Wiedmann Reviewed-by: Alexandra Winter Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b652dba24cbe41a4fa7417a5979f8ee1961e126b Author: Julian Wiedmann Date: Wed Dec 18 16:32:26 2019 +0100 s390/qeth: handle error due to unsupported transport mode [ Upstream commit 2e3d7fa5d29b7ab649fdf8f9533ae0c0888a7fac ] Along with z/VM NICs, there's additional device types that only support a specific transport mode (eg. external-bridged IQD). Identify the corresponding error code, and raise a fitting error message so that the user knows to adjust their device configuration. On top of that also fix the subsequent error path, so that the rejected cmd doesn't need to wait for a timeout but gets cancelled straight away. Fixes: 4a71df50047f ("qeth: new qeth device driver") Signed-off-by: Julian Wiedmann Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit dba0d9caa65957aac590d5f76b82ffc3d4d83d1a Author: David Jeffery Date: Tue Dec 17 11:00:24 2019 -0500 sbitmap: only queue kyber's wait callback if not already active [ Upstream commit df034c93f15ee71df231ff9fe311d27ff08a2a52 ] Under heavy loads where the kyber I/O scheduler hits the token limits for its scheduling domains, kyber can become stuck. When active requests complete, kyber may not be woken up leaving the I/O requests in kyber stuck. This stuck state is due to a race condition with kyber and the sbitmap functions it uses to run a callback when enough requests have completed. The running of a sbt_wait callback can race with the attempt to insert the sbt_wait. Since sbitmap_del_wait_queue removes the sbt_wait from the list first then sets the sbq field to NULL, kyber can see the item as not on a list but the call to sbitmap_add_wait_queue will see sbq as non-NULL. This results in the sbt_wait being inserted onto the wait list but ws_active doesn't get incremented. So the sbitmap queue does not know there is a waiter on a wait list. Since sbitmap doesn't think there is a waiter, kyber may never be informed that there are domain tokens available and the I/O never advances. With the sbt_wait on a wait list, kyber believes it has an active waiter so cannot insert a new waiter when reaching the domain's full state. This race can be fixed by only adding the sbt_wait to the queue if the sbq field is NULL. If sbq is not NULL, there is already an action active which will trigger the re-running of kyber. Let it run and add the sbt_wait to the wait list if still needing to wait. Reviewed-by: Omar Sandoval Signed-off-by: David Jeffery Reported-by: John Pittman Tested-by: John Pittman Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e14620987e614db83994451d03c94ecba42ef56c Author: Helge Deller Date: Fri Dec 20 21:00:19 2019 +0100 parisc: Fix compiler warnings in debug_core.c [ Upstream commit 75cf9797006a3a9f29a3a25c1febd6842a4a9eb2 ] Fix this compiler warning: kernel/debug/debug_core.c: In function ‘kgdb_cpu_enter’: arch/parisc/include/asm/cmpxchg.h:48:3: warning: value computed is not used [-Wunused-value] 48 | ((__typeof__(*(ptr)))__xchg((unsigned long)(x), (ptr), sizeof(*(ptr)))) arch/parisc/include/asm/atomic.h:78:30: note: in expansion of macro ‘xchg’ 78 | #define atomic_xchg(v, new) (xchg(&((v)->counter), new)) | ^~~~ kernel/debug/debug_core.c:596:4: note: in expansion of macro ‘atomic_xchg’ 596 | atomic_xchg(&kgdb_active, cpu); | ^~~~~~~~~~~ Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 3a1cba8768aeb7681bb48c820344f89c4d786e2f Author: Yang Yingliang Date: Wed Dec 18 16:44:04 2019 +0800 block: fix memleak when __blk_rq_map_user_iov() is failed [ Upstream commit 3b7995a98ad76da5597b488fa84aa5a56d43b608 ] When I doing fuzzy test, get the memleak report: BUG: memory leak unreferenced object 0xffff88837af80000 (size 4096): comm "memleak", pid 3557, jiffies 4294817681 (age 112.499s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 20 00 00 00 10 01 00 00 00 00 00 00 01 00 00 00 ............... backtrace: [<000000001c894df8>] bio_alloc_bioset+0x393/0x590 [<000000008b139a3c>] bio_copy_user_iov+0x300/0xcd0 [<00000000a998bd8c>] blk_rq_map_user_iov+0x2f1/0x5f0 [<000000005ceb7f05>] blk_rq_map_user+0xf2/0x160 [<000000006454da92>] sg_common_write.isra.21+0x1094/0x1870 [<00000000064bb208>] sg_write.part.25+0x5d9/0x950 [<000000004fc670f6>] sg_write+0x5f/0x8c [<00000000b0d05c7b>] __vfs_write+0x7c/0x100 [<000000008e177714>] vfs_write+0x1c3/0x500 [<0000000087d23f34>] ksys_write+0xf9/0x200 [<000000002c8dbc9d>] do_syscall_64+0x9f/0x4f0 [<00000000678d8e9a>] entry_SYSCALL_64_after_hwframe+0x49/0xbe If __blk_rq_map_user_iov() is failed in blk_rq_map_user_iov(), the bio(s) which is allocated before this failing will leak. The refcount of the bio(s) is init to 1 and increased to 2 by calling bio_get(), but __blk_rq_unmap_user() only decrease it to 1, so the bio cannot be freed. Fix it by calling blk_rq_unmap_user(). Reviewed-by: Bob Liu Reported-by: Hulk Robot Signed-off-by: Yang Yingliang Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ee6f0605e0c8b73a5d6f0322f1e0902d6d9625c6 Author: Stefan Haberland Date: Thu Dec 19 09:43:51 2019 +0100 s390/dasd: fix memleak in path handling error case [ Upstream commit 00b39f698a4f1ee897227cace2e3937fc4412270 ] If for whatever reason the dasd_eckd_check_characteristics() function exits after at least some paths have their configuration data allocated those data is never freed again. In the error case the device->private pointer is set to NULL and dasd_eckd_uncheck_device() will exit without freeing the path data because of this NULL pointer. Fix by calling dasd_eckd_clear_conf_data() for error cases. Also use dasd_eckd_clear_conf_data() in dasd_eckd_uncheck_device() to avoid code duplication. Reported-by: Qian Cai Reviewed-by: Jan Hoeppner Signed-off-by: Stefan Haberland Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e8b2bace0af6b50b40ca41932485c09eb9c39db2 Author: Jan Höppner Date: Thu Dec 19 09:43:50 2019 +0100 s390/dasd/cio: Interpret ccw_device_get_mdc return value correctly [ Upstream commit dd4b3c83b9efac10d48a94c61372119fc555a077 ] The max data count (mdc) is an unsigned 16-bit integer value as per AR documentation and is received via ccw_device_get_mdc() for a specific path mask from the CIO layer. The function itself also always returns a positive mdc value or 0 in case mdc isn't supported or couldn't be determined. Though, the comment for this function describes a negative return value to indicate failures. As a result, the DASD device driver interprets the return value of ccw_device_get_mdc() incorrectly. The error case is essentially a dead code path. To fix this behaviour, check explicitly for a return value of 0 and change the comment for ccw_device_get_mdc() accordingly. This fix merely enables the error code path in the DASD functions get_fcx_max_data() and verify_fcx_max_data(). The actual functionality stays the same and is still correct. Reviewed-by: Cornelia Huck Signed-off-by: Jan Höppner Acked-by: Peter Oberparleiter Reviewed-by: Stefan Haberland Signed-off-by: Stefan Haberland Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit f7cc2f988f35c214b0895cbc012ad78aaab11c0e Author: Bart Van Assche Date: Tue Dec 17 16:24:35 2019 -0800 block: Fix a lockdep complaint triggered by request queue flushing [ Upstream commit b3c6a59975415bde29cfd76ff1ab008edbf614a9 ] Avoid that running test nvme/012 from the blktests suite triggers the following false positive lockdep complaint: ============================================ WARNING: possible recursive locking detected 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841 Not tainted -------------------------------------------- ksoftirqd/1/16 is trying to acquire lock: 000000000282032e (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0 but task is already holding lock: 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&fq->mq_flush_lock)->rlock); lock(&(&fq->mq_flush_lock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by ksoftirqd/1/16: #0: 00000000cbadcbc2 (&(&fq->mq_flush_lock)->rlock){..-.}, at: flush_end_io+0x4e/0x1d0 stack backtrace: CPU: 1 PID: 16 Comm: ksoftirqd/1 Not tainted 5.0.0-rc3-xfstests-00015-g1236f7d60242 #841 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_stack+0x67/0x90 __lock_acquire.cold.45+0x2b4/0x313 lock_acquire+0x98/0x160 _raw_spin_lock_irqsave+0x3b/0x80 flush_end_io+0x4e/0x1d0 blk_mq_complete_request+0x76/0x110 nvmet_req_complete+0x15/0x110 [nvmet] nvmet_bio_done+0x27/0x50 [nvmet] blk_update_request+0xd7/0x2d0 blk_mq_end_request+0x1a/0x100 blk_flush_complete_seq+0xe5/0x350 flush_end_io+0x12f/0x1d0 blk_done_softirq+0x9f/0xd0 __do_softirq+0xca/0x440 run_ksoftirqd+0x24/0x50 smpboot_thread_fn+0x113/0x1e0 kthread+0x121/0x140 ret_from_fork+0x3a/0x50 Cc: Christoph Hellwig Cc: Ming Lei Cc: Hannes Reinecke Signed-off-by: Bart Van Assche Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 43b0b3300980b63f425dab1da22eb7bc2f8a9531 Author: Wei Li Date: Fri Dec 20 17:17:10 2019 +0800 arm64: cpu_errata: Add Hisilicon TSV110 to spectre-v2 safe list [ Upstream commit aa638cfe3e7358122a15cb1d295b622aae69e006 ] HiSilicon Taishan v110 CPUs didn't implement CSV2 field of the ID_AA64PFR0_EL1, but spectre-v2 is mitigated by hardware, so whitelist the MIDR in the safe list. Signed-off-by: Wei Li [hanjun: re-write the commit log] Signed-off-by: Hanjun Guo Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 542dc09cc5ce146d2b1636e3c9e9a012555a6c49 Author: Enrico Weigelt, metux IT consult Date: Thu Dec 12 12:23:48 2019 +0100 platform/x86: pcengines-apuv2: fix simswap GPIO assignment [ Upstream commit d4ac8f83dafec205c5db9b86b21587fba43bc017 ] The mapping entry has to hold the GPIO line index instead of controller's register number. Fixes: 5037d4ddda31 ("platform/x86: pcengines-apuv2: wire up simswitch gpio as led") Signed-off-by: Enrico Weigelt, metux IT consult Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit 47b957faa931a34186714a84b9206476b1a53ebf Author: Maxim Mikityanskiy Date: Tue Dec 17 16:20:47 2019 +0000 net/ixgbe: Fix concurrency issues between config flow and XSK [ Upstream commit c0fdccfd226a1424683d3000d9e08384391210a2 ] Use synchronize_rcu to wait until the XSK wakeup function finishes before destroying the resources it uses: 1. ixgbe_down already calls synchronize_rcu after setting __IXGBE_DOWN. 2. After switching the XDP program, call synchronize_rcu to let ixgbe_xsk_wakeup exit before the XDP program is freed. 3. Changing the number of channels brings the interface down. 4. Disabling UMEM sets __IXGBE_TX_DISABLED before closing hardware resources and resetting xsk_umem. Check that bit in ixgbe_xsk_wakeup to avoid using the XDP ring when it's already destroyed. synchronize_rcu is called from ixgbe_txrx_ring_disable. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-5-maximmi@mellanox.com Signed-off-by: Sasha Levin commit 4f5954a9258311468eb1afb7a60e4e9c1e4f4a19 Author: Maxim Mikityanskiy Date: Tue Dec 17 16:20:45 2019 +0000 net/i40e: Fix concurrency issues between config flow and XSK [ Upstream commit b3873a5be757b44d51af542a50a6f2a3b6f95284 ] Use synchronize_rcu to wait until the XSK wakeup function finishes before destroying the resources it uses: 1. i40e_down already calls synchronize_rcu. On i40e_down either __I40E_VSI_DOWN or __I40E_CONFIG_BUSY is set. Check the latter in i40e_xsk_wakeup (the former is already checked there). 2. After switching the XDP program, call synchronize_rcu to let i40e_xsk_wakeup exit before the XDP program is freed. 3. Changing the number of channels brings the interface down (see i40e_prep_for_reset and i40e_pf_quiesce_all_vsi). 4. Disabling UMEM sets __I40E_CONFIG_BUSY, too. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-4-maximmi@mellanox.com Signed-off-by: Sasha Levin commit df620e3d7d72f8f6d876adcb80fbb8cbd6cdf2fe Author: Maxim Mikityanskiy Date: Tue Dec 17 16:20:44 2019 +0000 net/mlx5e: Fix concurrency issues between config flow and XSK [ Upstream commit 9cf88808ad6a0f1e958e00abd9a081295fe6da0c ] After disabling resources necessary for XSK (the XDP program, channels, XSK queues), use synchronize_rcu to wait until the XSK wakeup function finishes, before freeing the resources. Suspend XSK wakeups during switching channels. If the XDP program is being removed, synchronize_rcu before closing the old channels to allow XSK wakeup to complete. Signed-off-by: Maxim Mikityanskiy Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-3-maximmi@mellanox.com Signed-off-by: Sasha Levin commit 96dee90a9d089992a74b46524776754750c99053 Author: Maxim Mikityanskiy Date: Tue Dec 17 16:20:42 2019 +0000 xsk: Add rcu_read_lock around the XSK wakeup [ Upstream commit 06870682087b58398671e8cdc896cd62314c4399 ] The XSK wakeup callback in drivers makes some sanity checks before triggering NAPI. However, some configuration changes may occur during this function that affect the result of those checks. For example, the interface can go down, and all the resources will be destroyed after the checks in the wakeup function, but before it attempts to use these resources. Wrap this callback in rcu_read_lock to allow driver to synchronize_rcu before actually destroying the resources. xsk_wakeup is a new function that encapsulates calling ndo_xsk_wakeup wrapped into the RCU lock. After this commit, xsk_poll starts using xsk_wakeup and checks xs->zc instead of ndo_xsk_wakeup != NULL to decide ndo_xsk_wakeup should be called. It also fixes a bug introduced with the need_wakeup feature: a non-zero-copy socket may be used with a driver supporting zero-copy, and in this case ndo_xsk_wakeup should not be called, so the xs->zc check is the correct one. Fixes: 77cd0d7b3f25 ("xsk: add support for need_wakeup flag in AF_XDP rings") Signed-off-by: Maxim Mikityanskiy Signed-off-by: Björn Töpel Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20191217162023.16011-2-maximmi@mellanox.com Signed-off-by: Sasha Levin commit adbc8231cec9a4e83310d329fb6037feed53bbb1 Author: Pavel Tatashin Date: Wed Dec 4 10:40:38 2019 -0500 tpm/tpm_ftpm_tee: add shutdown call back [ Upstream commit 1760eb689ed68c6746744aff2092bff57c78d907 ] Add shutdown call back to close existing session with fTPM TA to support kexec scenario. Add parentheses to function names in comments as specified in kdoc. Signed-off-by: Thirupathaiah Annapureddy Signed-off-by: Pavel Tatashin Reviewed-by: Jarkko Sakkinen Tested-by: Sasha Levin Signed-off-by: Jarkko Sakkinen Signed-off-by: Sasha Levin commit 2ad182a9d06e6eaa1f32dc77f252d5e7460dc532 Author: Chuhong Yuan Date: Mon Nov 18 19:39:55 2019 +0800 drm/exynos: gsc: add missed component_del [ Upstream commit 84c92365b20a44c363b95390ea00dfbdd786f031 ] The driver forgets to call component_del in remove to match component_add in probe. Add the missed call to fix it. Signed-off-by: Chuhong Yuan Signed-off-by: Inki Dae Signed-off-by: Sasha Levin commit 4d0f70fca09fd0fc5deca739392967526b786f73 Author: Christian Borntraeger Date: Wed Dec 18 09:34:57 2019 +0100 s390/purgatory: do not build purgatory with kcov, kasan and friends [ Upstream commit c23587c92f6e3260fe3b82bb75b38aa2553b9468 ] the purgatory must not rely on functions from the "old" kernel, so we must disable kasan and friends. We also need to have a separate copy of string.c as the default does not build memcmp with KASAN. Reported-by: kbuild test robot Signed-off-by: Christian Borntraeger Reviewed-by: Vasily Gorbik Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 32bbdcf8ea6a7db7b6b4da4db552eebf1619f07f Author: Jose Abreu Date: Wed Dec 18 11:17:43 2019 +0100 net: stmmac: Always arm TX Timer at end of transmission start [ Upstream commit 4772f26db8d1fb568c4862c538344a1b5fb52081 ] If TX Coalesce timer is enabled we should always arm it, otherwise we may hit the case where an interrupt is missed and the TX Queue will timeout. Arming the timer does not necessarly mean it will run the tx_clean() because this function is wrapped around NAPI launcher. Fixes: 9125cdd1be11 ("stmmac: add the initial tx coalesce schema") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2a49cb266bf9d83d5b28cc96c8287aa15d386af9 Author: Jose Abreu Date: Wed Dec 18 11:17:40 2019 +0100 net: stmmac: RX buffer size must be 16 byte aligned [ Upstream commit 8d558f0294fe92e04af192e221d0d0f6a180ee7b ] We need to align the RX buffer size to at least 16 byte so that IP doesn't mis-behave. This is required by HW. Changes from v2: - Align UP and not DOWN (David) Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a762cc03c0c35d1a7bcb3d414885bcabd1d3fef0 Author: Jose Abreu Date: Wed Dec 18 11:17:39 2019 +0100 net: stmmac: xgmac: Clear previous RX buffer size [ Upstream commit 11d55fd9975f8e46a0e5e19c14899544e81e1e15 ] When switching between buffer sizes we need to clear the previous value. Fixes: d6ddfacd95c7 ("net: stmmac: Add DMA related callbacks for XGMAC2") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f05252d5399536545a88f39e1b283a94b561fbb5 Author: Jose Abreu Date: Wed Dec 18 11:17:37 2019 +0100 net: stmmac: Do not accept invalid MTU values [ Upstream commit eaf4fac478077d4ed57cbca2c044c4b58a96bd98 ] The maximum MTU value is determined by the maximum size of TX FIFO so that a full packet can fit in the FIFO. Add a check for this in the MTU change callback. Also check if provided and rounded MTU does not passes the maximum limit of 16K. Changes from v2: - Align MTU before checking if its valid Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d2e7895b53bc246bb29edf5439c03bf00bf7c064 Author: Jose Abreu Date: Wed Dec 18 11:17:36 2019 +0100 net: stmmac: Determine earlier the size of RX buffer [ Upstream commit 5d626c879e238be9585bd59a61eb606c9408178a ] Split Header feature needs to know the size of RX buffer but current code is determining it too late. Fix this by moving the RX buffer computation to earlier stage. Changes from v2: - Do not try to align already aligned buffer size Fixes: 67afd6d1cfdf ("net: stmmac: Add Split Header support and enable it in XGMAC cores") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 82f8be03f811db982a8686e31ec3a58bf5f44b6a Author: Jose Abreu Date: Wed Dec 18 11:17:35 2019 +0100 net: stmmac: selftests: Needs to check the number of Multicast regs [ Upstream commit 08c965430869ed423921bd9058ae59f75207feb6 ] When running the MC and UC filter tests we setup a multicast address that its expected to be blocked. If the number of available multicast registers is zero, driver will always pass the multicast packets which will fail the test. Check if available multicast addresses is enough before running the tests. Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support") Signed-off-by: Jose Abreu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2071f6b8cefba73211f9783625a2dde6008f1b0f Author: Olof Johansson Date: Wed Dec 18 09:56:21 2019 -0800 clk: Move clk_core_reparent_orphans() under CONFIG_OF [ Upstream commit c771256ee7a03d3fb3c0443319ae6249c455849d ] A recent addition exposed a helper that is only used for CONFIG_OF. Move it into the CONFIG_OF zone in this file to make the compiler stop warning about an unused function. Fixes: 66d9506440bb ("clk: walk orphan list on clock provider registration") Signed-off-by: Olof Johansson Link: https://lkml.kernel.org/r/20191217082501.424892072D@mail.kernel.org [sboyd@kernel.org: "Simply" move the function instead] Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 002352747481b28287e0285fe95b31206391460c Author: Pavel Begunkov Date: Wed Dec 18 19:53:45 2019 +0300 io_uring: don't wait when under-submitting [ Upstream commit 7c504e65206a4379ff38fe41d21b32b6c2c3e53e ] There is no reliable way to submit and wait in a single syscall, as io_submit_sqes() may under-consume sqes (in case of an early error). Then it will wait for not-yet-submitted requests, deadlocking the user in most cases. Don't wait/poll if can't submit all sqes Signed-off-by: Pavel Begunkov Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2d26e06cb1be3384a16ba8fba9c9b7ee22bba22a Author: Robin Murphy Date: Mon Dec 9 19:47:25 2019 +0000 iommu/dma: Relax locking in iommu_dma_prepare_msi() [ Upstream commit c18647900ec864d401ba09b3bbd5b34f331f8d26 ] Since commit ece6e6f0218b ("iommu/dma-iommu: Split iommu_dma_map_msi_msg() in two parts"), iommu_dma_prepare_msi() should no longer have to worry about preempting itself, nor being called in atomic context at all. Thus we can downgrade the IRQ-safe locking to a simple mutex to avoid angering the new might_sleep() check in iommu_map(). Reported-by: Qian Cai Tested-by: Jean-Philippe Brucker Signed-off-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit 88184162e9c0677757b7a97b03bcd0ebde8a7cf5 Author: Hanjun Guo Date: Wed Dec 11 14:43:06 2019 +0800 perf/smmuv3: Remove the leftover put_cpu() in error path [ Upstream commit 8ae4bcf4821c18a8fbfa0b2c1df26c1085e9d923 ] In smmu_pmu_probe(), there is put_cpu() in the error path, which is wrong because we use raw_smp_processor_id() to get the cpu ID, not get_cpu(), remove it. While we are at it, kill 'out_cpuhp_err' altogether and just return err if we fail to add the hotplug instance. Acked-by: Robin Murphy Acked-by: Will Deacon Signed-off-by: Hanjun Guo Signed-off-by: Catalin Marinas Signed-off-by: Sasha Levin commit 2d300cb3bda8e64b9553dbdad7124922a055fe53 Author: Eric Sandeen Date: Fri Dec 6 10:55:59 2019 -0600 fs: call fsnotify_sb_delete after evict_inodes [ Upstream commit 1edc8eb2e93130e36ac74ac9c80913815a57d413 ] When a filesystem is unmounted, we currently call fsnotify_sb_delete() before evict_inodes(), which means that fsnotify_unmount_inodes() must iterate over all inodes on the superblock looking for any inodes with watches. This is inefficient and can lead to livelocks as it iterates over many unwatched inodes. At this point, SB_ACTIVE is gone and dropping refcount to zero kicks the inode out out immediately, so anything processed by fsnotify_sb_delete / fsnotify_unmount_inodes gets evicted in that loop. After that, the call to evict_inodes will evict everything else with a zero refcount. This should speed things up overall, and avoid livelocks in fsnotify_unmount_inodes(). Signed-off-by: Eric Sandeen Reviewed-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 16b730a459ca744cd7d3d33954caaa43da8cb3a2 Author: Eric Sandeen Date: Fri Dec 6 10:54:23 2019 -0600 fs: avoid softlockups in s_inodes iterators [ Upstream commit 04646aebd30b99f2cfa0182435a2ec252fcb16d0 ] Anything that walks all inodes on sb->s_inodes list without rescheduling risks softlockups. Previous efforts were made in 2 functions, see: c27d82f fs/drop_caches.c: avoid softlockups in drop_pagecache_sb() ac05fbb inode: don't softlockup when evicting inodes but there hasn't been an audit of all walkers, so do that now. This also consistently moves the cond_resched() calls to the bottom of each loop in cases where it already exists. One loop remains: remove_dquot_ref(), because I'm not quite sure how to deal with that one w/o taking the i_lock. Signed-off-by: Eric Sandeen Reviewed-by: Jan Kara Signed-off-by: Al Viro Signed-off-by: Sasha Levin commit 2ac95310fe5896cae413e4ae06b3af21645979d9 Author: Roman Penyaev Date: Tue Dec 17 16:54:07 2019 +0100 block: end bio with BLK_STS_AGAIN in case of non-mq devs and REQ_NOWAIT [ Upstream commit c58c1f83436b501d45d4050fd1296d71a9760bcb ] Non-mq devs do not honor REQ_NOWAIT so give a chance to the caller to repeat request gracefully on -EAGAIN error. The problem is well reproduced using io_uring: mkfs.ext4 /dev/ram0 mount /dev/ram0 /mnt # Preallocate a file dd if=/dev/zero of=/mnt/file bs=1M count=1 # Start fio with io_uring and get -EIO fio --rw=write --ioengine=io_uring --size=1M --direct=1 --name=job --filename=/mnt/file Signed-off-by: Roman Penyaev Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit e36491f117d1b5a439e1c347bded57844650dab5 Author: zhong jiang Date: Fri Dec 13 20:16:18 2019 +0800 usb: typec: fusb302: Fix an undefined reference to 'extcon_get_state' [ Upstream commit 547fc228755d79af648898187e7831a825d4f42c ] Fixes the following compile error: drivers/usb/typec/tcpm/fusb302.o: In function `tcpm_get_current_limit': fusb302.c:(.text+0x3ee): undefined reference to `extcon_get_state' fusb302.c:(.text+0x422): undefined reference to `extcon_get_state' fusb302.c:(.text+0x450): undefined reference to `extcon_get_state' fusb302.c:(.text+0x48c): undefined reference to `extcon_get_state' drivers/usb/typec/tcpm/fusb302.o: In function `fusb302_probe': fusb302.c:(.text+0x980): undefined reference to `extcon_get_extcon_dev' make: *** [vmlinux] Error 1 It is because EXTCON is build as a module, but FUSB302 is not. Suggested-by: Heikki Krogerus Signed-off-by: zhong jiang Acked-by: Heikki Krogerus Reviewed-by: Guenter Roeck Link: https://lore.kernel.org/r/1576239378-50795-1-git-send-email-zhongjiang@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 4e38135180004cf68190242ea795ba8d19898b42 Author: Johannes Weiner Date: Tue Dec 3 13:35:24 2019 -0500 psi: Fix a division error in psi poll() [ Upstream commit c3466952ca1514158d7c16c9cfc48c27d5c5dc0f ] The psi window size is a u64 an can be up to 10 seconds right now, which exceeds the lower 32 bits of the variable. We currently use div_u64 for it, which is meant only for 32-bit divisors. The result is garbage pressure sampling values and even potential div0 crashes. Use div64_u64. Signed-off-by: Johannes Weiner Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Suren Baghdasaryan Cc: Jingfeng Xie Link: https://lkml.kernel.org/r/20191203183524.41378-3-hannes@cmpxchg.org Signed-off-by: Sasha Levin commit 74e2bdcb7d16fcfb7ddbda615a91094abc727114 Author: Johannes Weiner Date: Tue Dec 3 13:35:23 2019 -0500 sched/psi: Fix sampling error and rare div0 crashes with cgroups and high uptime [ Upstream commit 3dfbe25c27eab7c90c8a7e97b4c354a9d24dd985 ] Jingfeng reports rare div0 crashes in psi on systems with some uptime: [58914.066423] divide error: 0000 [#1] SMP [58914.070416] Modules linked in: ipmi_poweroff ipmi_watchdog toa overlay fuse tcp_diag inet_diag binfmt_misc aisqos(O) aisqos_hotfixes(O) [58914.083158] CPU: 94 PID: 140364 Comm: kworker/94:2 Tainted: G W OE K 4.9.151-015.ali3000.alios7.x86_64 #1 [58914.093722] Hardware name: Alibaba Alibaba Cloud ECS/Alibaba Cloud ECS, BIOS 3.23.34 02/14/2019 [58914.102728] Workqueue: events psi_update_work [58914.107258] task: ffff8879da83c280 task.stack: ffffc90059dcc000 [58914.113336] RIP: 0010:[] [] psi_update_stats+0x1c1/0x330 [58914.122183] RSP: 0018:ffffc90059dcfd60 EFLAGS: 00010246 [58914.127650] RAX: 0000000000000000 RBX: ffff8858fe98be50 RCX: 000000007744d640 [58914.134947] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00003594f700648e [58914.142243] RBP: ffffc90059dcfdf8 R08: 0000359500000000 R09: 0000000000000000 [58914.149538] R10: 0000000000000000 R11: 0000000000000000 R12: 0000359500000000 [58914.156837] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8858fe98bd78 [58914.164136] FS: 0000000000000000(0000) GS:ffff887f7f380000(0000) knlGS:0000000000000000 [58914.172529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [58914.178467] CR2: 00007f2240452090 CR3: 0000005d5d258000 CR4: 00000000007606f0 [58914.185765] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [58914.193061] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [58914.200360] PKRU: 55555554 [58914.203221] Stack: [58914.205383] ffff8858fe98bd48 00000000000002f0 0000002e81036d09 ffffc90059dcfde8 [58914.213168] ffff8858fe98bec8 0000000000000000 0000000000000000 0000000000000000 [58914.220951] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [58914.228734] Call Trace: [58914.231337] [] psi_update_work+0x22/0x60 [58914.237067] [] process_one_work+0x189/0x420 [58914.243063] [] worker_thread+0x4e/0x4b0 [58914.248701] [] ? process_one_work+0x420/0x420 [58914.254869] [] kthread+0xe6/0x100 [58914.259994] [] ? kthread_park+0x60/0x60 [58914.265640] [] ret_from_fork+0x39/0x50 [58914.271193] Code: 41 29 c3 4d 39 dc 4d 0f 42 dc <49> f7 f1 48 8b 13 48 89 c7 48 c1 [58914.279691] RIP [] psi_update_stats+0x1c1/0x330 The crashing instruction is trying to divide the observed stall time by the sampling period. The period, stored in R8, is not 0, but we are dividing by the lower 32 bits only, which are all 0 in this instance. We could switch to a 64-bit division, but the period shouldn't be that big in the first place. It's the time between the last update and the next scheduled one, and so should always be around 2s and comfortably fit into 32 bits. The bug is in the initialization of new cgroups: we schedule the first sampling event in a cgroup as an offset of sched_clock(), but fail to initialize the last_update timestamp, and it defaults to 0. That results in a bogusly large sampling period the first time we run the sampling code, and consequently we underreport pressure for the first 2s of a cgroup's life. But worse, if sched_clock() is sufficiently advanced on the system, and the user gets unlucky, the period's lower 32 bits can all be 0 and the sampling division will crash. Fix this by initializing the last update timestamp to the creation time of the cgroup, thus correctly marking the start of the first pressure sampling period in a new cgroup. Reported-by: Jingfeng Xie Signed-off-by: Johannes Weiner Signed-off-by: Peter Zijlstra (Intel) Cc: Suren Baghdasaryan Link: https://lkml.kernel.org/r/20191203183524.41378-2-hannes@cmpxchg.org Signed-off-by: Sasha Levin commit 0ce2b3ecdcb8cfa06499f62981a3e52cb1fee980 Author: Alexander Shishkin Date: Tue Dec 10 12:51:01 2019 +0200 perf/x86/intel: Fix PT PMI handling [ Upstream commit 92ca7da4bdc24d63bb0bcd241c11441ddb63b80a ] Commit: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") skips the PT/LBR exclusivity check on CPUs where PT and LBRs coexist, but also inadvertently skips the active_events bump for PT in that case, which is a bug. If there aren't any hardware events at the same time as PT, the PMI handler will ignore PT PMIs, as active_events reads zero in that case, resulting in the "Uhhuh" spurious NMI warning and PT data loss. Fix this by always increasing active_events for PT events. Fixes: ccbebba4c6bf ("perf/x86/intel/pt: Bypass PT vs. LBR exclusivity if the core supports it") Reported-by: Vitaly Slobodskoy Signed-off-by: Alexander Shishkin Signed-off-by: Peter Zijlstra (Intel) Acked-by: Alexey Budankov Cc: Jiri Olsa Cc: Ingo Molnar Cc: Arnaldo Carvalho de Melo Link: https://lkml.kernel.org/r/20191210105101.77210-1-alexander.shishkin@linux.intel.com Signed-off-by: Sasha Levin commit 1997c9c22275dd0c3bd40305a187fa94f6d4b300 Author: Peter Zijlstra Date: Fri Dec 6 12:50:16 2019 +0100 perf/x86: Fix potential out-of-bounds access [ Upstream commit 1e69a0efc0bd0e02b8327e7186fbb4a81878ea0b ] UBSAN reported out-of-bound accesses for x86_pmu.event_map(), it's arguments should be < x86_pmu.max_events. Make sure all users observe this constraint. Reported-by: Meelis Roos Signed-off-by: Peter Zijlstra (Intel) Tested-by: Meelis Roos Signed-off-by: Sasha Levin commit 142c711f66a387dd14eed31dbf91bf64d2d90c2a Author: Enrico Weigelt, metux IT consult Date: Mon Dec 16 21:07:19 2019 +0100 scripts: package: mkdebian: add missing rsync dependency [ Upstream commit a11391b6f50689adb22c65df783e09143fafb794 ] We've missed the dependency to rsync, so build fails on minimal containers. Fixes: 59b2bd05f5f4 ("kbuild: add 'headers' target to build up uapi headers in usr/include") Signed-off-by: Enrico Weigelt, metux IT consult Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit ba7c39e92b3caa915fd1bf2e730a44cb51e3c6e3 Author: Thomas Hebb Date: Mon Dec 9 00:19:17 2019 -0800 kconfig: don't crash on NULL expressions in expr_eq() [ Upstream commit 272a72103012862e3a24ea06635253ead0b6e808 ] NULL expressions are taken to always be true, as implemented by the expr_is_yes() macro and by several other functions in expr.c. As such, they ought to be valid inputs to expr_eq(), which compares two expressions. Signed-off-by: Thomas Hebb Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit c65eddfef6699490ee7dc299755412e34a5218d3 Author: Xiaotao Yin Date: Tue Dec 10 12:27:04 2019 +0800 iommu/iova: Init the struct iova to fix the possible memleak [ Upstream commit 472d26df5e8075eda677b6be730e0fbf434ff2a8 ] During ethernet(Marvell octeontx2) set ring buffer test: ethtool -G eth1 rx tx following kmemleak will happen sometimes: unreferenced object 0xffff000b85421340 (size 64): comm "ethtool", pid 867, jiffies 4295323539 (age 550.500s) hex dump (first 64 bytes): 80 13 42 85 0b 00 ff ff ff ff ff ff ff ff ff ff ..B............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ ff ff ff ff ff ff ff ff 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: [<000000001b204ddf>] kmem_cache_alloc+0x1b0/0x350 [<00000000d9ef2e50>] alloc_iova+0x3c/0x168 [<00000000ea30f99d>] alloc_iova_fast+0x7c/0x2d8 [<00000000b8bb2f1f>] iommu_dma_alloc_iova.isra.0+0x12c/0x138 [<000000002f1a43b5>] __iommu_dma_map+0x8c/0xf8 [<00000000ecde7899>] iommu_dma_map_page+0x98/0xf8 [<0000000082004e59>] otx2_alloc_rbuf+0xf4/0x158 [<000000002b107f6b>] otx2_rq_aura_pool_init+0x110/0x270 [<00000000c3d563c7>] otx2_open+0x15c/0x734 [<00000000a2f5f3a8>] otx2_dev_open+0x3c/0x68 [<00000000456a98b5>] otx2_set_ringparam+0x1ac/0x1d4 [<00000000f2fbb819>] dev_ethtool+0xb84/0x2028 [<0000000069b67c5a>] dev_ioctl+0x248/0x3a0 [<00000000af38663a>] sock_ioctl+0x280/0x638 [<000000002582384c>] do_vfs_ioctl+0x8b0/0xa80 [<000000004e1a2c02>] ksys_ioctl+0x84/0xb8 The reason: When alloc_iova_mem() without initial with Zero, sometimes fpn_lo will equal to IOVA_ANCHOR by chance, so when return with -ENOMEM(iova32_full) from __alloc_and_insert_iova_range(), the new_iova will not be freed in free_iova_mem(). Fixes: bb68b2fbfbd6 ("iommu/iova: Add rbtree anchor node") Signed-off-by: Xiaotao Yin Reviewed-by: Robin Murphy Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin commit ba90ce119dd4368b3c4effc2f38061b049791ae5 Author: Brendan Higgins Date: Wed Dec 11 11:27:41 2019 -0800 staging: axis-fifo: add unspecified HAS_IOMEM dependency [ Upstream commit d3aa8de6b5d0853c43c616586b4e232aa1fa7de9 ] Currently CONFIG_XIL_AXIS_FIFO=y implicitly depends on CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get the following build error: ld: drivers/staging/axis-fifo/axis-fifo.o: in function `axis_fifo_probe': drivers/staging/axis-fifo/axis-fifo.c:809: undefined reference to `devm_ioremap_resource' Fix the build error by adding the unspecified dependency. Reported-by: Brendan Higgins Signed-off-by: Brendan Higgins Link: https://lore.kernel.org/r/20191211192742.95699-7-brendanhiggins@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 90fe4a970886de4c9c23237d11103d9b5e19f1c6 Author: Alexandre Belloni Date: Thu Nov 28 11:25:31 2019 +0100 clk: at91: fix possible deadlock [ Upstream commit 6956eb33abb5deab2cd916b4c31226b57736bc3c ] Lockdep warns about a possible circular locking dependency because using syscon_node_to_regmap() will make the created regmap get and enable the first clock it can parse from the device tree. This clock is not needed to access the registers and should not be enabled at that time. Use the recently introduced device_node_to_regmap to solve that as it looks up the regmap in the same list but doesn't care about the clocks. Reported-by: Michał Mirosław Signed-off-by: Alexandre Belloni Link: https://lkml.kernel.org/r/20191128102531.817549-1-alexandre.belloni@bootlin.com Tested-by: Michał Mirosław Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 9e713aa4c15c9cbb39aa4994cb61ef5584ad97e8 Author: Michael Walle Date: Wed Dec 11 20:57:30 2019 +0100 spi: nxp-fspi: Ensure width is respected in spi-mem operations [ Upstream commit 007773e16a6f3f49d1439554078c3ba8af131998 ] Make use of a core helper to ensure the desired width is respected when calling spi-mem operators. Otherwise only the SPI controller will be matched with the flash chip, which might lead to wrong widths. Also consider the width specified by the user in the device tree. Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Signed-off-by: Michael Walle Link: https://lore.kernel.org/r/20191211195730.26794-1-michael@walle.cc Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit d3054d709a15db19cdfbaee10328abaa30adb7ce Author: Andreas Kemnade Date: Wed Dec 11 23:16:00 2019 +0100 regulator: rn5t618: fix module aliases [ Upstream commit 62a1923cc8fe095912e6213ed5de27abbf1de77e ] platform device aliases were missing, preventing autoloading of module. Fixes: 811b700630ff ("regulator: rn5t618: add driver for Ricoh RN5T618 regulators") Signed-off-by: Andreas Kemnade Link: https://lore.kernel.org/r/20191211221600.29438-1-andreas@kemnade.info Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f684cc7c1350c8ff5ef01bfa94ef9e2eb6c1bd32 Author: Shengjiu Wang Date: Wed Dec 11 19:57:22 2019 +0800 ASoC: wm8962: fix lambda value [ Upstream commit 556672d75ff486e0b6786056da624131679e0576 ] According to user manual, it is required that FLL_LAMBDA > 0 in all cases (Integer and Franctional modes). Fixes: 9a76f1ff6e29 ("ASoC: Add initial WM8962 CODEC driver") Signed-off-by: Shengjiu Wang Acked-by: Charles Keepax Link: https://lore.kernel.org/r/1576065442-19763-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 705c7e53702d7eb239b0c27ee0ce20bc44314b6d Author: Aditya Pakki Date: Sun Dec 15 09:34:08 2019 -0600 rfkill: Fix incorrect check to avoid NULL pointer dereference [ Upstream commit 6fc232db9e8cd50b9b83534de9cd91ace711b2d7 ] In rfkill_register, the struct rfkill pointer is first derefernced and then checked for NULL. This patch removes the BUG_ON and returns an error to the caller in case rfkill is NULL. Signed-off-by: Aditya Pakki Link: https://lore.kernel.org/r/20191215153409.21696-1-pakki001@umn.edu Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit e7e87cfaba3844219d16820d8e08b1b4123c18db Author: Sven Schnelle Date: Sun Dec 15 20:09:27 2019 +0100 parisc: add missing __init annotation [ Upstream commit aeea5eae4fd54e94d820ed17ea3b238160be723e ] compilation failed with: MODPOST vmlinux.o WARNING: vmlinux.o(.text.unlikely+0xa0c): Section mismatch in reference from the function walk_lower_bus() to the function .init.text:walk_native_bus() The function walk_lower_bus() references the function __init walk_native_bus(). This is often because walk_lower_bus lacks a __init annotation or the annotation of walk_native_bus is wrong. FATAL: modpost: Section mismatches detected. Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow them. make[2]: *** [/home/svens/linux/parisc-linux/src/scripts/Makefile.modpost:64: __modpost] Error 1 make[1]: *** [/home/svens/linux/parisc-linux/src/Makefile:1077: vmlinux] Error 2 make[1]: Leaving directory '/home/svens/linux/parisc-linux/build' make: *** [Makefile:179: sub-make] Error 2 Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 78f37522052b6eda56e6168138288c540c9f432f Author: Sven Schnelle Date: Sun Dec 15 20:10:39 2019 +0100 parisc: fix compilation when KEXEC=n and KEXEC_FILE=y [ Upstream commit e16260c21f87b16a33ae8ecac9e8c79f3a8b89bd ] Fix compilation when the CONFIG_KEXEC_FILE=y and CONFIG_KEXEC=n. Reported-by: kbuild test robot Signed-off-by: Sven Schnelle Signed-off-by: Helge Deller Signed-off-by: Sasha Levin commit 27fc4a9e4aa7806ae14617e57dc4f3feb8e75f53 Author: Cristian Birsan Date: Fri Dec 13 18:33:11 2019 +0200 net: usb: lan78xx: Fix error message format specifier [ Upstream commit 858ce8ca62ea1530f2779d0e3f934b0176e663c3 ] Display the return code as decimal integer. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Cristian Birsan Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit db1c0da0a0e2798e5b4ad26a61ba40e4a20715b7 Author: Vishal Kulkarni Date: Fri Dec 13 06:39:39 2019 +0530 cxgb4: Fix kernel panic while accessing sge_info [ Upstream commit 479a0d1376f6d97c60871442911f1394d4446a25 ] The sge_info debugfs collects offload queue info even when offload capability is disabled and leads to panic. [ 144.139871] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 144.139874] CR2: 0000000000000000 CR3: 000000082d456005 CR4: 00000000001606e0 [ 144.139876] Call Trace: [ 144.139887] sge_queue_start+0x12/0x30 [cxgb4] [ 144.139897] seq_read+0x1d4/0x3d0 [ 144.139906] full_proxy_read+0x50/0x70 [ 144.139913] vfs_read+0x89/0x140 [ 144.139916] ksys_read+0x55/0xd0 [ 144.139924] do_syscall_64+0x5b/0x1d0 [ 144.139933] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 144.139936] RIP: 0033:0x7f4b01493990 Fix this crash by skipping the offload queue access in sge_qinfo when offload capability is disabled Signed-off-by: Herat Ramani Signed-off-by: Vishal Kulkarni Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit fc1e815943c36234279547159c02869cacdd06a8 Author: Manish Chopra Date: Wed Dec 11 09:59:56 2019 -0800 bnx2x: Fix logic to get total no. of PFs per engine [ Upstream commit ee699f89bdbaa19c399804504241b5c531b48888 ] Driver doesn't calculate total number of PFs configured on a given engine correctly which messed up resources in the PFs loaded on that engine, leading driver to exceed configuration of resources (like vlan filters etc.) beyond the limit per engine, which ended up with asserts from the firmware. Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 97d9e8620f57f28f415b23ad88b97c87b6d53390 Author: Manish Chopra Date: Wed Dec 11 09:59:55 2019 -0800 bnx2x: Do not handle requests from VFs after parity [ Upstream commit 7113f796bbbced2470cd6d7379d50d7a7a78bf34 ] Parity error from the hardware will cause PF to lose the state of their VFs due to PF's internal reload and hardware reset following the parity error. Restrict any configuration request from the VFs after the parity as it could cause unexpected hardware behavior, only way for VFs to recover would be to trigger FLR on VFs and reload them. Signed-off-by: Manish Chopra Signed-off-by: Ariel Elior Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin commit 9125da9fe96af0fa83082ee1f563881bc87999c3 Author: Chen Wandun Date: Tue Dec 10 19:06:56 2019 +0800 habanalabs: remove variable 'val' set but not used [ Upstream commit 68a1fdf2451f38b4ada0607eb6e1303f8a02e0b7 ] Fixes gcc '-Wunused-but-set-variable' warning: drivers/misc/habanalabs/goya/goya.c: In function goya_pldm_init_cpu: drivers/misc/habanalabs/goya/goya.c:2195:6: warning: variable val set but not used [-Wunused-but-set-variable] drivers/misc/habanalabs/goya/goya.c: In function goya_hw_init: drivers/misc/habanalabs/goya/goya.c:2505:6: warning: variable val set but not used [-Wunused-but-set-variable] Fixes: 9494a8dd8d22 ("habanalabs: add h/w queues module") Signed-off-by: Chen Wandun Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 8a91214266164fc718ed476f024b847bf6b0cb33 Author: Oded Gabbay Date: Tue Dec 3 10:12:10 2019 +0200 habanalabs: rate limit error msg on waiting for CS [ Upstream commit 018e0e3594f7dcd029d258e368c485e742fa9cdb ] In case a user submits a CS, and the submission fails, and the user doesn't check the return value and instead use the error return value as a valid sequence number of a CS and ask to wait on it, the driver will print an error and return an error code for that wait. The real problem happens if now the user ignores the error of the wait, and try to wait again and again. This can lead to a flood of error messages from the driver and even soft lockup event. Signed-off-by: Oded Gabbay Reviewed-by: Tomer Tayar Signed-off-by: Sasha Levin commit 8d503ecf71548da5381151fa197cc091b141cc53 Author: Lorenz Bauer Date: Fri Dec 13 18:08:17 2019 +0000 bpf: Clear skb->tstamp in bpf_redirect when necessary [ Upstream commit 5133498f4ad1123a5ffd4c08df6431dab882cc32 ] Redirecting a packet from ingress to egress by using bpf_redirect breaks if the egress interface has an fq qdisc installed. This is the same problem as fixed in 'commit 8203e2d844d3 ("net: clear skb->tstamp in forwarding paths") Clear skb->tstamp when redirecting into the egress path. Fixes: 80b14dee2bea ("net: Add a new socket option for a future transmit time.") Fixes: fb420d5d91c1 ("tcp/fq: move back to CLOCK_MONOTONIC") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Reviewed-by: Eric Dumazet Link: https://lore.kernel.org/bpf/20191213180817.2510-1-lmb@cloudflare.com Signed-off-by: Sasha Levin commit 2da53ec72f763476b074748fca00d8e91ae345e1 Author: Frederic Barrat Date: Mon Dec 9 11:55:13 2019 +0100 ocxl: Fix potential memory leak on context creation [ Upstream commit 913e73c77d48aeeb50c16450a653dca9c71ae2e2 ] If we couldn't fully init a context, we were leaking memory. Fixes: b9721d275cc2 ("ocxl: Allow external drivers to use OpenCAPI contexts") Signed-off-by: Frederic Barrat Acked-by: Andrew Donnellan Reviewed-by: Greg Kurz Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191209105513.8566-1-fbarrat@linux.ibm.com Signed-off-by: Sasha Levin commit 989f4be351a9d3a068c1c223f62bbed7c26cae4f Author: Filipe Manana Date: Thu Dec 5 16:58:41 2019 +0000 Btrfs: fix hole extent items with a zero size after range cloning [ Upstream commit 147271e35ba267506dde6550f58ccf8d287db3ef ] Normally when cloning a file range if we find an implicit hole at the end of the range we assume it is because the NO_HOLES feature is enabled. However that is not always the case. One well known case [1] is when we have a power failure after mixing buffered and direct IO writes against the same file. In such cases we need to punch a hole in the destination file, and if the NO_HOLES feature is not enabled, we need to insert explicit file extent items to represent the hole. After commit 690a5dbfc51315 ("Btrfs: fix ENOSPC errors, leading to transaction aborts, when cloning extents"), we started to insert file extent items representing the hole with an item size of 0, which is invalid and should be 53 bytes (the size of a btrfs_file_extent_item structure), resulting in all sorts of corruptions and invalid memory accesses. This is detected by the tree checker when we attempt to write a leaf to disk. The problem can be sporadically triggered by test case generic/561 from fstests. That test case does not exercise power failure and creates a new filesystem when it starts, so it does not use a filesystem created by any previous test that tests power failure. However the test does both buffered and direct IO writes (through fsstress) and it's precisely that which is creating the implicit holes in files. That happens even before the commit mentioned earlier. I need to investigate why we get those implicit holes to check if there is a real problem or not. For now this change fixes the regression of introducing file extent items with an item size of 0 bytes. Fix the issue by calling btrfs_punch_hole_range() without passing a btrfs_clone_extent_info structure, which ensures file extent items are inserted to represent the hole with a correct item size. We were passing a btrfs_clone_extent_info with a value of 0 for its 'item_size' field, which was causing the insertion of file extent items with an item size of 0. [1] https://www.spinics.net/lists/linux-btrfs/msg75350.html Reported-by: David Sterba Fixes: 690a5dbfc51315 ("Btrfs: fix ENOSPC errors, leading to transaction aborts, when cloning extents") Signed-off-by: Filipe Manana Reviewed-by: Josef Bacik Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit dfa25a8dc11db9f6d459024c0bcc9d454e757578 Author: Josef Bacik Date: Tue Nov 19 13:59:00 2019 -0500 btrfs: handle error in btrfs_cache_block_group [ Upstream commit db8fe64f9ce61d1d89d3c3c34d111a43afb9f053 ] We have a BUG_ON(ret < 0) in find_free_extent from btrfs_cache_block_group. If we fail to allocate our ctl we'll just panic, which is not good. Instead just go on to another block group. If we fail to find a block group we don't want to return ENOSPC, because really we got a ENOMEM and that's the root of the problem. Save our return from btrfs_cache_block_group(), and then if we still fail to make our allocation return that ret so we get the right error back. Tested with inject-error.py from bcc. Reviewed-by: Johannes Thumshirn Signed-off-by: Josef Bacik Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit a7ed0553b7fb535964e1113223e4bc9e1909ac00 Author: Jason A. Donenfeld Date: Mon Dec 23 14:31:47 2019 +0100 powerpc/spinlocks: Include correct header for static key commit 6da3eced8c5f3b03340b0c395bacd552c4d52411 upstream. Recently, the spinlock implementation grew a static key optimization, but the jump_label.h header include was left out, leading to build errors: linux/arch/powerpc/include/asm/spinlock.h:44:7: error: implicit declaration of function ‘static_branch_unlikely’ 44 | if (!static_branch_unlikely(&shared_processor)) This commit adds the missing header. mpe: The build break is only seen with CONFIG_JUMP_LABEL=n. Fixes: 656c21d6af5d ("powerpc/shared: Use static key to detect shared processor") Signed-off-by: Jason A. Donenfeld Reviewed-by: Srikar Dronamraju Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191223133147.129983-1-Jason@zx2c4.com Cc: Srikar Dronamraju Signed-off-by: Greg Kroah-Hartman commit 1e8a2bfed0009165d6d8adb525563b5467564937 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 e167468cc4a79898f17db6daa8468a680be26e87 Author: Filipe Manana Date: Thu Dec 5 16:57:39 2019 +0000 Btrfs: fix cloning range with a hole when using the NO_HOLES feature [ Upstream commit fcb970581dd900675c4371c2b688a57924a8368c ] When using the NO_HOLES feature if we clone a range that contains a hole and a temporary ENOSPC happens while dropping extents from the target inode's range, we can end up failing and aborting the transaction with -EEXIST or with a corrupt file extent item, that has a length greater than it should and overlaps with other extents. For example when cloning the following range from inode A to inode B: Inode A: extent A1 extent A2 [ ----------- ] [ hole, implicit, 4MB length ] [ ------------- ] 0 1MB 5MB 6MB Range to clone: [1MB, 6MB) Inode B: extent B1 extent B2 extent B3 extent B4 [ ---------- ] [ --------- ] [ ---------- ] [ ---------- ] 0 1MB 1MB 2MB 2MB 5MB 5MB 6MB Target range: [1MB, 6MB) (same as source, to make it easier to explain) The following can happen: 1) btrfs_punch_hole_range() gets -ENOSPC from __btrfs_drop_extents(); 2) At that point, 'cur_offset' is set to 1MB and __btrfs_drop_extents() set 'drop_end' to 2MB, meaning it was able to drop only extent B2; 3) We then compute 'clone_len' as 'drop_end' - 'cur_offset' = 2MB - 1MB = 1MB; 4) We then attempt to insert a file extent item at inode B with a file offset of 5MB, which is the value of clone_info->file_offset. This fails with error -EEXIST because there's already an extent at that offset (extent B4); 5) We abort the current transaction with -EEXIST and return that error to user space as well. Another example, for extent corruption: Inode A: extent A1 extent A2 [ ----------- ] [ hole, implicit, 10MB length ] [ ------------- ] 0 1MB 11MB 12MB Inode B: extent B1 extent B2 [ ----------- ] [ --------- ] [ ----------------------------- ] 0 1MB 1MB 5MB 5MB 12MB Target range: [1MB, 12MB) (same as source, to make it easier to explain) 1) btrfs_punch_hole_range() gets -ENOSPC from __btrfs_drop_extents(); 2) At that point, 'cur_offset' is set to 1MB and __btrfs_drop_extents() set 'drop_end' to 5MB, meaning it was able to drop only extent B2; 3) We then compute 'clone_len' as 'drop_end' - 'cur_offset' = 5MB - 1MB = 4MB; 4) We then insert a file extent item at inode B with a file offset of 11MB which is the value of clone_info->file_offset, and a length of 4MB (the value of 'clone_len'). So we get 2 extents items with ranges that overlap and an extent length of 4MB, larger then the extent A2 from inode A (1MB length); 5) After that we end the transaction, balance the btree dirty pages and then start another or join the previous transaction. It might happen that the transaction which inserted the incorrect extent was committed by another task so we end up with extent corruption if a power failure happens. So fix this by making sure we attempt to insert the extent to clone at the destination inode only if we are past dropping the sub-range that corresponds to a hole. Fixes: 690a5dbfc51315 ("Btrfs: fix ENOSPC errors, leading to transaction aborts, when cloning extents") Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 7312543371d38df8d69d4e4b02321e84ac7dc1f0 Author: Nikolay Borisov Date: Mon Nov 18 14:16:44 2019 +0200 btrfs: Fix error messages in qgroup_rescan_init [ Upstream commit 37d02592f11bb76e4ab1dcaa5b8a2a0715403207 ] The branch of qgroup_rescan_init which is executed from the mount path prints wrong errors messages. The textual print out in case BTRFS_QGROUP_STATUS_FLAG_RESCAN/BTRFS_QGROUP_STATUS_FLAG_ON are not set are transposed. Fix it by exchanging their place. Signed-off-by: Nikolay Borisov Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Sasha Levin commit 673e43cf490cb8094c0c5830cd2b18b67cfa56df Author: Mike Rapoport Date: Wed Dec 4 14:35:24 2019 +0200 powerpc: Ensure that swiotlb buffer is allocated from low memory [ Upstream commit 8fabc623238e68b3ac63c0dd1657bf86c1fa33af ] Some powerpc platforms (e.g. 85xx) limit DMA-able memory way below 4G. If a system has more physical memory than this limit, the swiotlb buffer is not addressable because it is allocated from memblock using top-down mode. Force memblock to bottom-up mode before calling swiotlb_init() to ensure that the swiotlb buffer is DMA-able. Reported-by: Christian Zigotzky Signed-off-by: Mike Rapoport Reviewed-by: Christoph Hellwig Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20191204123524.22919-1-rppt@kernel.org Signed-off-by: Sasha Levin commit 0ef6ac6c122c9adcd0f8f1740824e8e5eeeaec04 Author: Alexandre Torgue Date: Wed Dec 4 15:41:06 2019 +0100 pinctrl: pinmux: fix a possible null pointer in pinmux_can_be_used_for_gpio [ Upstream commit 6ba2fd391ac58c1a26874f10c3054a1ea4aca2d0 ] This commit adds a check on ops pointer to avoid a kernel panic when ops->strict is used. Indeed, on some pinctrl driver (at least for pinctrl-stmfx) the pinmux ops is not implemented. Let's assume than gpio can be used in this case. Fixes: 472a61e777fe ("pinctrl/gpio: Take MUX usage into account") Signed-off-by: Alexandre Torgue Link: https://lore.kernel.org/r/20191204144106.10876-1-alexandre.torgue@st.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 2d68f35b7bcf77a4fbb34b683e291d0d01cba50c Author: Stefan Bühler Date: Tue Nov 26 11:05:44 2019 +0100 cfg80211: fix double-free after changing network namespace [ Upstream commit 56cb31e185adb61f930743a9b70e700a43625386 ] If wdev->wext.keys was initialized it didn't get reset to NULL on unregister (and it doesn't get set in cfg80211_init_wdev either), but wdev is reused if unregister was triggered through cfg80211_switch_netns. The next unregister (for whatever reason) will try to free wdev->wext.keys again. Signed-off-by: Stefan Bühler Link: https://lore.kernel.org/r/20191126100543.782023-1-stefan.buehler@tik.uni-stuttgart.de Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit a6fdd8858cd2050b4501033f05a5278ba1b24e05 Author: Fredrik Olofsson Date: Tue Nov 19 14:34:51 2019 +0100 mac80211: fix TID field in monitor mode transmit [ Upstream commit 753ffad3d6243303994227854d951ff5c70fa9e0 ] Fix overwriting of the qos_ctrl.tid field for encrypted frames injected on a monitor interface. While qos_ctrl.tid is not encrypted, it's used as an input into the encryption algorithm so it's protected, and thus cannot be modified after encryption. For injected frames, the encryption may already have been done in userspace, so we cannot change any fields. Before passing the frame to the driver, the qos_ctrl.tid field is updated from skb->priority. Prior to dbd50a851c50 skb->priority was updated in ieee80211_select_queue_80211(), but this function is no longer always called. Update skb->priority in ieee80211_monitor_start_xmit() so that the value is stored, and when later code 'modifies' the TID it really sets it to the same value as before, preserving the encryption. Fixes: dbd50a851c50 ("mac80211: only allocate one queue when using iTXQs") Signed-off-by: Fredrik Olofsson Link: https://lore.kernel.org/r/20191119133451.14711-1-fredrik.olofsson@anyfinetworks.com [rewrite commit message based on our discussion] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit b34dd7eb39af330a4b064bbad15e4b0c6f86a8af Author: Jerome Brunet Date: Tue Dec 3 09:08:05 2019 +0100 clk: walk orphan list on clock provider registration [ Upstream commit 66d9506440bb05289eb4867059e7b8c6ed209717 ] So far, we walked the orphan list every time a new clock was registered in CCF. This was fine since the clocks were only referenced by name. Now that the clock can be referenced through DT, it is not enough: * Controller A register first a reference clocks from controller B through DT. * Controller B register all its clocks then register the provider. Each time controller B registers a new clock, the orphan list is walked but it can't match since the provider is registered yet. When the provider is finally registered, the orphan list is not walked unless another clock is registered afterward. This can lead to situation where some clocks remain orphaned even if the parent is available. Walking the orphan list on provider registration solves the problem. Reported-by: Jian Hu Fixes: fc0c209c147f ("clk: Allow parents to be specified without string names") Signed-off-by: Jerome Brunet Link: https://lkml.kernel.org/r/20191203080805.104628-1-jbrunet@baylibre.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6a64fb7d278ffc4baf4f93b61cec1b6cd59512ae Author: Tony Lindgren Date: Thu Dec 12 08:20:10 2019 -0800 bus: ti-sysc: Fix missing reset delay handling [ Upstream commit e709ed70d122e94cb426b1e1f905829eae19a009 ] We have dts property for "ti,sysc-delay-us", and we're using it, but the wait after OCP softreset only happens if devices are probed in legacy mode. Let's add a delay after writing the OCP softreset when specified. Fixes: e0db94fe87da ("bus: ti-sysc: Make OCP reset work for sysstatus and sysconfig reset bits") Cc: Keerthy Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit d05d4ad89d8e0c2d737c1e88ab9dfc51d2d1ebee Author: Andrew Jeffery Date: Mon Dec 2 15:31:10 2019 +1030 pinctrl: aspeed-g6: Fix LPC/eSPI mux configuration [ Upstream commit eb45f2110b036e4e35d3f3aaee1c2ccf49d92425 ] Early revisions of the AST2600 datasheet are conflicted about the state of the LPC/eSPI strapping bit (SCU510[6]). Conversations with ASPEED determined that the reference pinmux configuration tables were in error and the SCU documentation contained the correct configuration. Update the driver to reflect the state described in the SCU documentation. Fixes: 2eda1cdec49f ("pinctrl: aspeed: Add AST2600 pinmux support") Signed-off-by: Andrew Jeffery Link: https://lore.kernel.org/r/20191202050110.15340-1-andrew@aj.id.au Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 12f1c5fa3e17d6948a552e1f56ad908363360fa7 Author: Leonard Crestez Date: Tue Dec 10 19:34:20 2019 +0200 ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS [ Upstream commit 46db63abb79524209c15c683feccfba116746757 ] This is currently off and that's not desirable: default imx config is meant to be generally useful for development and debugging. Running git bisect between v5.4 and v5.5-rc1 finds this started from commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") Explicit CONFIG_DEBUG_FS=y was earlier removed by commit c29d541f590c ("ARM: imx_v6_v7_defconfig: Remove unneeded options") A very similar fix was required before: commit 7e9eb6268809 ("ARM: imx_v6_v7_defconfig: Explicitly restore CONFIG_DEBUG_FS") Signed-off-by: Leonard Crestez Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 2ee64f2c308bd55d88f1adf6c4d47fc73c6610f6 Author: Michael Walle Date: Wed Dec 11 18:11:45 2019 +0100 arm64: dts: ls1028a: fix reboot node [ Upstream commit 3f0fb37b22b460e3dec62bee284932881574acb9 ] The reboot register isn't located inside the DCFG controller, but in its own RST controller. Fix it. Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC") Signed-off-by: Michael Walle Acked-by: Li Yang Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 865d218756beb75ff7dacf7e7367ecc723bf6471 Author: Daniel T. Lee Date: Thu Dec 5 17:01:14 2019 +0900 samples: bpf: fix syscall_tp due to unused syscall [ Upstream commit fe3300897cbfd76c6cb825776e5ac0ca50a91ca4 ] Currently, open() is called from the user program and it calls the syscall 'sys_openat', not the 'sys_open'. This leads to an error of the program of user side, due to the fact that the counter maps are zero since no function such 'sys_open' is called. This commit adds the kernel bpf program which are attached to the tracepoint 'sys_enter_openat' and 'sys_enter_openat'. Fixes: 1da236b6be963 ("bpf: add a test case for syscalls/sys_{enter|exit}_* tracepoints") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin commit f687855ab9095c26809b512a2057042822f9088b Author: Daniel T. Lee Date: Thu Dec 5 17:01:13 2019 +0900 samples: bpf: Replace symbol compare of trace_event [ Upstream commit bba1b2a890253528c45aa66cf856f289a215bfbc ] Previously, when this sample is added, commit 1c47910ef8013 ("samples/bpf: add perf_event+bpf example"), a symbol 'sys_read' and 'sys_write' has been used without no prefixes. But currently there are no exact symbols with these under kallsyms and this leads to failure. This commit changes exact compare to substring compare to keep compatible with exact symbol or prefixed symbol. Fixes: 1c47910ef8013 ("samples/bpf: add perf_event+bpf example") Signed-off-by: Daniel T. Lee Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191205080114.19766-2-danieltimlee@gmail.com Signed-off-by: Sasha Levin commit 8ded82da8f9efc466f7f5940fa36b570cb540de9 Author: SeongJae Park Date: Mon Dec 2 12:42:21 2019 +0100 kselftest: Support old perl versions [ Upstream commit 4eac734486fd431e0756cc5e929f140911a36a53 ] On an old perl such as v5.10.1, `kselftest/prefix.pl` gives below error message: Can't locate object method "autoflush" via package "IO::Handle" at kselftest/prefix.pl line 10. This commit fixes the error by explicitly specifying the use of the `IO::Handle` package. Signed-off-by: SeongJae Park Acked-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 277df4ca18da0ab0e2e83c476dde2c8f74177c41 Author: SeongJae Park Date: Mon Dec 2 12:42:20 2019 +0100 kselftest/runner: Print new line in print of timeout log [ Upstream commit d187801d1a46519d2a322f879f7c8f85c685372e ] If a timeout failure occurs, kselftest kills the test process and prints the timeout log. If the test process has killed while printing a log that ends with new line, the timeout log can be printed in middle of the test process output so that it can be seems like a comment, as below: # test_process_log not ok 3 selftests: timers: nsleep-lat # TIMEOUT This commit avoids such problem by printing one more line before the TIMEOUT failure log. Signed-off-by: SeongJae Park Acked-by: Kees Cook Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 66ae15854332c20397fcc82c4002e799bd57bb97 Author: Tomi Valkeinen Date: Thu Nov 14 11:39:48 2019 +0200 ARM: dts: am437x-gp/epos-evm: fix panel compatible [ Upstream commit c6b16761c6908d3dc167a0a566578b4b0b972905 ] The LCD panel on AM4 GP EVMs and ePOS boards seems to be osd070t1718-19ts. The current dts files say osd057T0559-34ts. Possibly the panel has changed since the early EVMs, or there has been a mistake with the panel type. Update the DT files accordingly. Acked-by: Laurent Pinchart Signed-off-by: Tomi Valkeinen Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit e5b874829a9e9f229c962572675d259a431a5757 Author: Vignesh Raghavendra Date: Wed Dec 11 21:22:16 2019 +0530 spi: spi-ti-qspi: Fix a bug when accessing non default CS [ Upstream commit c52c91bb9aa6bd8c38dbf9776158e33038aedd43 ] When switching ChipSelect from default CS0 to any other CS, driver fails to update the bits in system control module register that control which CS is mapped for MMIO access. This causes reads to fail when driver tries to access QSPI flash on CS1/2/3. Fix this by updating appropriate bits whenever active CS changes. Reported-by: Andreas Dannenberg Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20191211155216.30212-1-vigneshr@ti.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 432bc6cbe187067c7a746b4d1e2c600e1af1b51f Author: Michael Petlan Date: Sun Dec 8 17:20:56 2019 +0100 perf header: Fix false warning when there are no duplicate cache entries [ Upstream commit 28707826877f84bce0977845ea529cbdd08e4e8d ] Before this patch, perf expected that there might be NPROC*4 unique cache entries at max, however, it also expected that some of them would be shared and/or of the same size, thus the final number of entries would be reduced to be lower than NPROC*4. In case the number of entries hadn't been reduced (was NPROC*4), the warning was printed. However, some systems might have unusual cache topology, such as the following two-processor KVM guest: cpu level shared_cpu_list size 0 1 0 32K 0 1 0 64K 0 2 0 512K 0 3 0 8192K 1 1 1 32K 1 1 1 64K 1 2 1 512K 1 3 1 8192K This KVM guest has 8 (NPROC*4) unique cache entries, which used to make perf printing the message, although there actually aren't "way too many cpu caches". v2: Removing unused argument. v3: Unifying the way we obtain number of cpus. v4: Removed '& UINT_MAX' construct which is redundant. Signed-off-by: Michael Petlan Acked-by: Jiri Olsa LPU-Reference: 20191208162056.20772-1-mpetlan@redhat.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 3635b27cc05888af1aa44e1cd67d2933884019be Author: Kajol Jain Date: Wed Nov 20 14:10:59 2019 +0530 perf metricgroup: Fix printing event names of metric group with multiple events [ Upstream commit eb573e746b9d4f0921dcb2449be3df41dae3caea ] Commit f01642e4912b ("perf metricgroup: Support multiple events for metricgroup") introduced support for multiple events in a metric group. But with the current upstream, metric events names are not printed properly In power9 platform: command:# ./perf stat --metric-only -M translation -C 0 -I 1000 sleep 2 1.000208486 2.000368863 2.001400558 Similarly in skylake platform: command:./perf stat --metric-only -M Power -I 1000 1.000579994 2.002189493 With current upstream version, issue is with event name comparison logic in find_evsel_group(). Current logic is to compare events belonging to a metric group to the events in perf_evlist. Since the break statement is missing in the loop used for comparison between metric group and perf_evlist events, the loop continues to execute even after getting a pattern match, and end up in discarding the matches. Incase of single metric event belongs to metric group, its working fine, because in case of single event once it compare all events it reaches to end of perf_evlist. Example for single metric event in power9 platform: command:# ./perf stat --metric-only -M branches_per_inst -I 1000 sleep 1 1.000094653 0.2 1.001337059 0.0 This patch fixes the issue by making sure once we found all events belongs to that metric event matched in find_evsel_group(), we successfully break from that loop by adding corresponding condition. With this patch: In power9 platform: command:# ./perf stat --metric-only -M translation -C 0 -I 1000 sleep 2 result:# time derat_4k_miss_rate_percent derat_4k_miss_ratio derat_miss_ratio derat_64k_miss_rate_percent derat_64k_miss_ratio dslb_miss_rate_percent islb_miss_rate_percent 1.000135672 0.0 0.3 1.0 0.0 0.2 0.0 0.0 2.000380617 0.0 0.0 0.0 0.0 0.0 0.0 0.0 command:# ./perf stat --metric-only -M Power -I 1000 Similarly in skylake platform: result:# time Turbo_Utilization C3_Core_Residency C6_Core_Residency C7_Core_Residency C2_Pkg_Residency C3_Pkg_Residency C6_Pkg_Residency C7_Pkg_Residency 1.000563580 0.3 0.0 2.6 44.2 21.9 0.0 0.0 0.0 2.002235027 0.4 0.0 2.7 43.0 20.7 0.0 0.0 0.0 Committer testing: Before: [root@seventh ~]# perf stat --metric-only -M Power -I 1000 # time 1.000383223 2.001168182 3.001968545 4.002741200 5.003442022 ^C 5.777687244 [root@seventh ~]# After the patch: [root@seventh ~]# perf stat --metric-only -M Power -I 1000 # time Turbo_Utilization C3_Core_Residency C6_Core_Residency C7_Core_Residency C2_Pkg_Residency C3_Pkg_Residency C6_Pkg_Residency C7_Pkg_Residency 1.000406577 0.4 0.1 1.4 97.0 0.0 0.0 0.0 0.0 2.001481572 0.3 0.0 0.6 97.9 0.0 0.0 0.0 0.0 3.002332585 0.2 0.0 1.0 97.5 0.0 0.0 0.0 0.0 4.003196624 0.2 0.0 0.3 98.6 0.0 0.0 0.0 0.0 5.004063851 0.3 0.0 0.7 97.7 0.0 0.0 0.0 0.0 ^C 5.471260276 0.2 0.0 0.5 49.3 0.0 0.0 0.0 0.0 [root@seventh ~]# [root@seventh ~]# dmesg | grep -i skylake [ 0.187807] Performance Events: PEBS fmt3+, Skylake events, 32-deep LBR, full-width counters, Intel PMU driver. [root@seventh ~]# Fixes: f01642e4912b ("perf metricgroup: Support multiple events for metricgroup") Signed-off-by: Kajol Jain Reviewed-by: Ravi Bangoria Tested-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: Andi Kleen Cc: Anju T Sudhakar Cc: Jin Yao Cc: Jiri Olsa Cc: Kan Liang Cc: Madhavan Srinivasan Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/20191120084059.24458-1-kjain@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 83cc18a0c29774295eb240e20d7e5b251536b527 Author: Toke Høiland-Jørgensen Date: Tue Dec 10 19:14:12 2019 +0100 bpftool: Don't crash on missing jited insns or ksyms [ Upstream commit 5b79bcdf03628a3a9ee04d9cd5fabcf61a8e20be ] When the kptr_restrict sysctl is set, the kernel can fail to return jited_ksyms or jited_prog_insns, but still have positive values in nr_jited_ksyms and jited_prog_len. This causes bpftool to crash when trying to dump the program because it only checks the len fields not the actual pointers to the instructions and ksyms. Fix this by adding the missing checks. Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool") Fixes: f84192ee00b7 ("tools: bpftool: resolve calls without using imm field") Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20191210181412.151226-1-toke@redhat.com Signed-off-by: Sasha Levin commit 10c343face62a56d5da1d517faf42faf3e7beec5 Author: Paul Chaignon Date: Mon Dec 9 19:52:52 2019 +0100 bpf, mips: Limit to 33 tail calls [ Upstream commit e49e6f6db04e915dccb494ae10fa14888fea6f89 ] All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in MIPS' JIT compiler to allow 33 tail calls. Fixes: b6bd53f9c4e8 ("MIPS: Add missing file for eBPF JIT.") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/b8eb2caac1c25453c539248e56ca22f74b5316af.1575916815.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin commit f1977a3a58bc214240626763df9850a064003648 Author: Paul Chaignon Date: Mon Dec 9 19:52:07 2019 +0100 bpf, riscv: Limit to 33 tail calls [ Upstream commit 96bc4432f5ade1045521f3b247f516b1478166bd ] All BPF JIT compilers except RISC-V's and MIPS' enforce a 33-tail calls limit at runtime. In addition, a test was recently added, in tailcalls2, to check this limit. This patch updates the tail call limit in RISC-V's JIT compiler to allow 33 tail calls. I tested it using the above selftest on an emulated RISCV64. Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Reported-by: Mahshid Khezri Signed-off-by: Paul Chaignon Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/966fe384383bf23a0ee1efe8d7291c78a3fb832b.1575916815.git.paul.chaignon@gmail.com Signed-off-by: Sasha Levin commit 741ec5c1ef011ff5f4c2b3ff280b0c0604001fd9 Author: Michael Walle Date: Tue Dec 10 00:43:46 2019 +0100 arm64: dts: ls1028a: fix typo in TMU calibration data [ Upstream commit 961f8209c8d5ef5d33da42e6656d7c8179899da0 ] The temperature sensor may jump backwards because there is a wrong calibration value. Both values have to be monotonically increasing. Fix it. This was tested on a custom board. Fixes: 571cebfe8e2b ("arm64: dts: ls1028a: Add Thermal Monitor Unit node") Signed-off-by: Michael Walle Acked-by: Tang Yuantian Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit e879b75eec52c759ef497ded33088e0c6997284a Author: Stefan Wahren Date: Sat Nov 30 13:31:13 2019 +0100 ARM: dts: bcm283x: Fix critical trip point [ Upstream commit 30e647a764d446723a7e0fb08d209e0104f16173 ] During definition of the CPU thermal zone of BCM283x SoC family there was a misunderstanding of the meaning "criticial trip point" and the thermal throttling range of the VideoCore firmware. The latter one takes effect when the core temperature is at least 85 degree celsius or higher So the current critical trip point doesn't make sense, because the thermal shutdown appears before the firmware has a chance to throttle the ARM core(s). Fix these unwanted shutdowns by increasing the critical trip point to a value which shouldn't be reached with working thermal throttling. Fixes: 0fe4d2181cc4 ("ARM: dts: bcm283x: Add CPU thermal zone with 1 trip point") Signed-off-by: Stefan Wahren Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 946b6c30604b2ea5768cdc426f1a5063b35206a0 Author: Tony Lindgren Date: Mon Dec 9 13:41:17 2019 -0800 ARM: omap2plus_defconfig: Add back DEBUG_FS [ Upstream commit e00b59d30506dc9ef91caf2f3c584209cc9f61e4 ] Commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") removed select for DEBUG_FS but we still need it at least for enabling deeper idle states for the SoCs. Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit b2266c53cfcd7d3d4e20a2b4141e57224252838d Author: Mans Rullgard Date: Sun Dec 1 17:07:06 2019 +0000 ARM: dts: am335x-sancloud-bbe: fix phy mode [ Upstream commit c842b8c4ff9859f750447f3ca08f64b2ed23cebc ] The phy mode should be rgmii-id. For some reason, it used to work with rgmii-txid but doesn't any more. Signed-off-by: Mans Rullgard Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit 78935af22861ba4774ebff8bf33d866d476f5ab8 Author: Curtis Malainey Date: Mon Dec 9 18:48:52 2019 -0600 ASoC: SOF: Intel: split cht and byt debug window sizes [ Upstream commit f84337c3fb8ff4d533ccbed0d2db4e8587d0ff58 ] Turns out SSP 3-5 are only available on cht, to avoid dumping on undefined registers let's split the definition. Signed-off-by: Curtis Malainey Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191210004854.16845-7-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9d71c76a16e414018b0674cfc2db11610cabd6a0 Author: Karol Trzcinski Date: Mon Dec 9 18:48:48 2019 -0600 ASoC: SOF: loader: snd_sof_fw_parse_ext_data log warning on unknown header [ Upstream commit 8edc95667646a75f0fc97e08ecb180581fdff300 ] Added warning log when found some unknown FW boot ext header, to improve debuggability. Signed-off-by: Karol Trzcinski Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191210004854.16845-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c75fe29eb11328412fc1347b062af55d46bcead6 Author: Dragos Tarcatu Date: Mon Dec 9 18:39:39 2019 -0600 ASoC: topology: Check return value for soc_tplg_pcm_create() [ Upstream commit a3039aef52d9ffeb67e9211899cd3e8a2953a01f ] The return value of soc_tplg_pcm_create() is currently not checked in soc_tplg_pcm_elems_load(). If an error is to occur there, the topology ignores it and continues loading. Fix that by checking the status and rejecting the topology on error. Reviewed-by: Ranjani Sridharan Signed-off-by: Dragos Tarcatu Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191210003939.15752-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 805afc15c685d07c7a60b695debd079dff937d92 Author: Dragos Tarcatu Date: Mon Dec 9 18:39:38 2019 -0600 ASoC: topology: Check return value for snd_soc_add_dai_link() [ Upstream commit 76d2703649321c296df7ec0dafd50add96215de4 ] snd_soc_add_dai_link() might fail. This situation occurs for instance in a very specific use case where a PCM device and a Back End DAI link are given identical names in the topology. When this happens, soc_new_pcm_runtime() fails and then snd_soc_add_dai_link() returns -ENOMEM when called from soc_tplg_fe_link_create(). Because of that, the link will not get added into the card list, so any attempt to remove it later ends up in a panic. Fix that by checking the return status and free the memory in case of an error. Reviewed-by: Ranjani Sridharan Signed-off-by: Dragos Tarcatu Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191210003939.15752-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit dcdf7b574272850e574647758c6f2da6e8f174d6 Author: Geert Uytterhoeven Date: Wed Nov 20 15:59:26 2019 +0100 reset: Do not register resource data for missing resets [ Upstream commit db23808615e29d9a04f96806cac56f78b0fee0ef ] When an optional reset is not present, __devm_reset_control_get() and devm_reset_control_array_get() still register resource data to release the non-existing reset on cleanup, which is futile. Fix this by skipping NULL reset control pointers. Signed-off-by: Geert Uytterhoeven Signed-off-by: Philipp Zabel Signed-off-by: Sasha Levin commit ec32cd3673e777ab470a84d35292cdf552d30917 Author: Chuhong Yuan Date: Fri Dec 6 15:55:00 2019 +0800 spi: spi-cavium-thunderx: Add missing pci_release_regions() [ Upstream commit a841e2853e1afecc2ee692b8cc5bff606bc84e4c ] The driver forgets to call pci_release_regions() in probe failure and remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan Link: https://lore.kernel.org/r/20191206075500.18525-1-hslester96@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 188d62a085cecc7c19054515a9d57f5f5d335ee6 Author: Florian Fainelli Date: Fri Dec 6 10:19:09 2019 -0800 ARM: dts: Cygnus: Fix MDIO node address/size cells [ Upstream commit fac2c2da3596d77c343988bb0d41a8c533b2e73c ] The MDIO node on Cygnus had an reversed #address-cells and #size-cells properties, correct those. Fixes: 40c26d3af60a ("ARM: dts: Cygnus: Add the ethernet switch and ethernet PHY") Reported-by: Simon Horman Reviewed-by: Ray Jui Reviewed-by: Simon Horman Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 110440a0eb4e340a0f353f9df86783aa4365f899 Author: Marek Szyprowski Date: Fri Dec 6 13:47:21 2019 +0100 ARM: exynos_defconfig: Restore debugfs support [ Upstream commit a2315d3aea5976acd919d3d3fcf82f752562c25b ] Commit 9f532d26c75c ("ARM: exynos_defconfig: Trim and reorganize with savedefconfig") removed explicit enable line for CONFIG_DEBUG_FS, because that feature has been selected by other enabled options: CONFIG_TRACING, which in turn had been selected by CONFIG_PERF_EVENTS and CONFIG_PROVE_LOCKING. In meantime, commit 0e4a459f56c3 ("tracing: Remove unnecessary DEBUG_FS dependency") removed the dependency between CONFIG_DEBUG_FS and CONFIG_TRACING, so CONFIG_DEBUG_FS is no longer enabled in default builds. Enable it again explicitly, as debugfs support is essential for various automated testing tools. Signed-off-by: Marek Szyprowski Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin commit 5ce520cd3856461d8bb6884c38641c232b3e38f6 Author: Masami Hiramatsu Date: Thu Dec 5 21:21:16 2019 +0900 selftests: safesetid: Fix Makefile to set correct test program [ Upstream commit 8ef1ec0ca32c6f8a87f5b4c24b1db26da67c5609 ] Fix Makefile to set safesetid-test.sh to TEST_PROGS instead of non existing run_tests.sh. Without this fix, I got following error. ---- TAP version 13 1..1 # selftests: safesetid: run_tests.sh # Warning: file run_tests.sh is missing! not ok 1 selftests: safesetid: run_tests.sh ---- Fixes: c67e8ec03f3f ("LSM: SafeSetID: add selftest") Signed-off-by: Masami Hiramatsu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit d275f2a0a7d3cdd8f24a94652f1e91c3ebd3dac0 Author: Masami Hiramatsu Date: Thu Dec 5 21:21:07 2019 +0900 selftests: safesetid: Check the return value of setuid/setgid [ Upstream commit 295c4e21cf27ac9af542140e3e797df9e0cf7b5f ] Check the return value of setuid() and setgid(). This fixes the following warnings and improves test result. safesetid-test.c: In function ‘main’: safesetid-test.c:294:2: warning: ignoring return value of ‘setuid’, declared with attribute warn_unused_result [-Wunused-result] setuid(NO_POLICY_USER); ^~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c:295:2: warning: ignoring return value of ‘setgid’, declared with attribute warn_unused_result [-Wunused-result] setgid(NO_POLICY_USER); ^~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c:309:2: warning: ignoring return value of ‘setuid’, declared with attribute warn_unused_result [-Wunused-result] setuid(RESTRICTED_PARENT); ^~~~~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c:310:2: warning: ignoring return value of ‘setgid’, declared with attribute warn_unused_result [-Wunused-result] setgid(RESTRICTED_PARENT); ^~~~~~~~~~~~~~~~~~~~~~~~~ safesetid-test.c: In function ‘test_setuid’: safesetid-test.c:216:3: warning: ignoring return value of ‘setuid’, declared with attribute warn_unused_result [-Wunused-result] setuid(child_uid); ^~~~~~~~~~~~~~~~~ Fixes: c67e8ec03f3f ("LSM: SafeSetID: add selftest") Signed-off-by: Masami Hiramatsu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 9872b15ef0c6ada3d30a6832149f1ba7d76e5053 Author: Masami Hiramatsu Date: Thu Dec 5 21:20:58 2019 +0900 selftests: safesetid: Move link library to LDLIBS [ Upstream commit be12252212fa3dfed6e75112865095c484c0ce87 ] Move -lcap to LDLIBS from CFLAGS because it is a library to be linked. Without this, safesetid failed to build with link error as below. ---- /usr/bin/ld: /tmp/ccL8rZHT.o: in function `drop_caps': safesetid-test.c:(.text+0xe7): undefined reference to `cap_get_proc' /usr/bin/ld: safesetid-test.c:(.text+0x107): undefined reference to `cap_set_flag' /usr/bin/ld: safesetid-test.c:(.text+0x10f): undefined reference to `cap_set_proc' /usr/bin/ld: safesetid-test.c:(.text+0x117): undefined reference to `cap_free' /usr/bin/ld: safesetid-test.c:(.text+0x136): undefined reference to `cap_clear' collect2: error: ld returned 1 exit status ---- Fixes: c67e8ec03f3f ("LSM: SafeSetID: add selftest") Signed-off-by: Masami Hiramatsu Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit f6a1ef25281050df26714be48088a6a03c0f202c Author: Masami Hiramatsu Date: Tue Nov 26 17:34:42 2019 +0900 selftests/ftrace: Fix multiple kprobe testcase [ Upstream commit 5cc6c8d4a99d0ee4d5466498e258e593df1d3eb6 ] Fix multiple kprobe event testcase to work it correctly. There are 2 bugfixes. - Since `wc -l FILE` returns not only line number but also FILE filename, following "if" statement always failed. Fix this bug by replacing it with 'cat FILE | wc -l' - Since "while do-done loop" block with pipeline becomes a subshell, $N local variable is not update outside of the loop. Fix this bug by using actual target number (256) instead of $N. Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c9f08701e6af02c54822674131c3f1067a20ada0 Author: Masami Hiramatsu Date: Tue Nov 26 17:34:33 2019 +0900 selftests/ftrace: Do not to use absolute debugfs path [ Upstream commit ba1b9c5048e43716921abe3a1db19cebebf4a5f5 ] Use relative path to trigger file instead of absolute debugfs path, because if the user uses tracefs instead of debugfs, it can be mounted at /sys/kernel/tracing. Anyway, since the ftracetest is designed to be run at the tracing directory, user doesn't need to use absolute path. Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 343651f56049aa2e89041c19d9c38014d2a90338 Author: Masami Hiramatsu Date: Wed Nov 27 08:42:21 2019 +0900 selftests/ftrace: Fix ftrace test cases to check unsupported [ Upstream commit 25deae098e748d8d36bc35129a66734b8f6925c9 ] Since dynamic function tracer can be disabled, set_ftrace_filter can be disappeared. Test cases which depends on it, must check whether the set_ftrace_filter exists or not before testing and if not, return as unsupported. Also, if the function tracer itself is disabled, we can not set "function" to current_tracer. Test cases must check it before testing, and return as unsupported. Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 612ca49074ff91e94e0fde92956c950cb39ba735 Author: Masami Hiramatsu Date: Tue Nov 26 17:34:16 2019 +0900 selftests/ftrace: Fix to check the existence of set_ftrace_filter [ Upstream commit fd1baf6ca2ea3550ea47f2bb0bdcf34ec764a779 ] If we run ftracetest on the kernel with CONFIG_DYNAMIC_FTRACE=n, there is no set_ftrace_filter and all test cases are failed, because reset_ftrace_filter() returns an error. Let's check whether set_ftrace_filter exists in reset_ftrace_filter() and clean up only set_ftrace_notrace in initialize_ftrace(). Signed-off-by: Masami Hiramatsu Reviewed-by: Steven Rostedt (VMware) Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit a5991e6a3338f7e9d0916cee62f83b1c7ad7808f Author: Florian Fainelli Date: Thu Dec 5 16:01:20 2019 -0800 ARM: dts: BCM5301X: Fix MDIO node address/size cells [ Upstream commit 093c3f94e922d83a734fc4da08cc5814990f32c6 ] The MDIO node on BCM5301X had an reversed #address-cells and #size-cells properties, correct those, silencing checker warnings: .../linux/arch/arm/boot/dts/bcm4708-asus-rt-ac56u.dt.yaml: mdio@18003000: #address-cells:0:0: 1 was expected Reported-by: Simon Horman Fixes: 23f1eca6d59b ("ARM: dts: BCM5301X: Specify MDIO bus in the DT") Signed-off-by: Florian Fainelli Signed-off-by: Sasha Levin commit 36d08a41d23f060b45d2db01bd5e72d156445b65 Author: Pablo Neira Ayuso Date: Fri Dec 6 22:49:58 2019 +0100 netfilter: nf_tables_offload: return EOPNOTSUPP if rule specifies no actions [ Upstream commit 81ec61074bcf68acfcb2820cda3ff9d9984419c7 ] If the rule only specifies the matching side, return EOPNOTSUPP. Otherwise, the front-end relies on the drivers to reject this rule. Fixes: c9626a2cbdb2 ("netfilter: nf_tables: add hardware offload support") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 7aa02b48875f274563346d5a6097aa784360d73b Author: Pablo Neira Ayuso Date: Fri Dec 6 22:25:55 2019 +0100 netfilter: nf_tables: skip module reference count bump on object updates [ Upstream commit fd57d0cbe187e93f63777d36e9f49293311d417f ] Use __nft_obj_type_get() instead, otherwise there is a module reference counter leak. Fixes: d62d0ba97b58 ("netfilter: nf_tables: Introduce stateful object update operation") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 2c5fc884f888cc0d7f7285bca443d3d6d0efdcaa Author: Pablo Neira Ayuso Date: Fri Dec 6 22:09:14 2019 +0100 netfilter: nf_tables: validate NFT_DATA_VALUE after nft_data_init() [ Upstream commit 0d2c96af797ba149e559c5875c0151384ab6dd14 ] Userspace might bogusly sent NFT_DATA_VERDICT in several netlink attributes that assume NFT_DATA_VALUE. Moreover, make sure that error path invokes nft_data_release() to decrement the reference count on the chain object. Fixes: 96518518cc41 ("netfilter: add nftables") Fixes: 0f3cd9b36977 ("netfilter: nf_tables: add range expression") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 5be1c364b046e530f369100a4966ab0b03a8e266 Author: Pablo Neira Ayuso Date: Fri Dec 6 21:55:20 2019 +0100 netfilter: nf_tables: validate NFT_SET_ELEM_INTERVAL_END [ Upstream commit bffc124b6fe37d0ae9b428d104efb426403bb5c9 ] Only NFTA_SET_ELEM_KEY and NFTA_SET_ELEM_FLAGS make sense for elements whose NFT_SET_ELEM_INTERVAL_END flag is set on. Fixes: 96518518cc41 ("netfilter: add nftables") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 495258074da3f91cac67abd94a296b91b82d6e53 Author: Pablo Neira Ayuso Date: Fri Dec 6 20:23:29 2019 +0100 netfilter: nft_set_rbtree: bogus lookup/get on consecutive elements in named sets [ Upstream commit db3b665dd77b34e34df00e17d7b299c98fcfb2c5 ] The existing rbtree implementation might store consecutive elements where the closing element and the opening element might overlap, eg. [ a, a+1) [ a+1, a+2) This patch removes the optimization for non-anonymous sets in the exact matching case, where it is assumed to stop searching in case that the closing element is found. Instead, invalidate candidate interval and keep looking further in the tree. The lookup/get operation might return false, while there is an element in the rbtree. Moreover, the get operation returns true as if a+2 would be in the tree. This happens with named sets after several set updates. The existing lookup optimization (that only works for the anonymous sets) might not reach the opening [ a+1,... element if the closing ...,a+1) is found in first place when walking over the rbtree. Hence, walking the full tree in that case is needed. This patch fixes the lookup and get operations. Fixes: e701001e7cbe ("netfilter: nft_rbtree: allow adjacent intervals with dynamic updates") Fixes: ba0e4d9917b4 ("netfilter: nf_tables: get set elements via netlink") Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 17a7f9d865304997e8bc25eae3e915e83e70e3fa Author: Phil Sutter Date: Thu Dec 5 13:35:11 2019 +0100 netfilter: uapi: Avoid undefined left-shift in xt_sctp.h [ Upstream commit 164166558aacea01b99c8c8ffb710d930405ba69 ] With 'bytes(__u32)' being 32, a left-shift of 31 may happen which is undefined for the signed 32-bit value 1. Avoid this by declaring 1 as unsigned. Signed-off-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 324172d2adcce8d2b927c0d667ca4da6f88bbb92 Author: Sudeep Holla Date: Wed Nov 27 15:56:40 2019 +0000 ARM: vexpress: Set-up shared OPP table instead of individual for each CPU [ Upstream commit 2a76352ad2cc6b78e58f737714879cc860903802 ] Currently we add individual copy of same OPP table for each CPU within the cluster. This is redundant and doesn't reflect the reality. We can't use core cpumask to set policy->cpus in ve_spc_cpufreq_init() anymore as it gets called via cpuhp_cpufreq_online()->cpufreq_online() ->cpufreq_driver->init() and the cpumask gets updated upon CPU hotplug operations. It also may cause issues when the vexpress_spc_cpufreq driver is built as a module. Since ve_spc_clk_init is built-in device initcall, we should be able to use the same topology_core_cpumask to set the opp sharing cpumask via dev_pm_opp_set_sharing_cpus and use the same later in the driver via dev_pm_opp_get_sharing_cpus. Cc: Liviu Dudau Cc: Lorenzo Pieralisi Acked-by: Viresh Kumar Tested-by: Dietmar Eggemann Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit c57292b68a13a5645b04011baf19771fd4b9ab1a Author: Stefan Roese Date: Tue Nov 5 14:04:56 2019 +0100 ARM: dts: imx6ul: imx6ul-14x14-evk.dtsi: Fix SPI NOR probing [ Upstream commit 0aeb1f2b74f3402e9cdb7c0b8e2c369c9767301e ] Without this "jedec,spi-nor" compatible property, probing of the SPI NOR does not work on the NXP i.MX6ULL EVK. Fix this by adding this compatible property to the DT. Fixes: 7d77b8505aa9 ("ARM: dts: imx6ull: fix the imx6ull-14x14-evk configuration") Signed-off-by: Stefan Roese Reviewed-by: Fabio Estevam Reviewed-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 6ddac305e0b79d29f7a4e55e720e2a44a2ce5824 Author: Andy Shevchenko Date: Fri Dec 6 16:55:42 2019 +0000 efi/earlycon: Remap entire framebuffer after page initialization [ Upstream commit b418d660bb9798d2249ac6a46c844389ef50b6a5 ] When commit: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") moved the x86 specific EFI earlyprintk implementation to a shared location, it also tweaked the behaviour. In particular, it dropped a trick with full framebuffer remapping after page initialization, leading to two regressions: 1) very slow scrolling after page initialization, 2) kernel hang when the 'keep_bootcon' command line argument is passed. Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow behavior to the early boot stages, presumably due to eliminating heavy map()/unmap() operations per each pixel line on the screen. [ ardb: ensure efifb is unmapped again unless keep_bootcon is in effect. ] [ mingo: speling fixes. ] Signed-off-by: Andy Shevchenko Signed-off-by: Ard Biesheuvel Cc: Arvind Sankar Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Link: https://lkml.kernel.org/r/20191206165542.31469-7-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit a431b8d768460bbf03554634ba20974f03905b97 Author: Arvind Sankar Date: Fri Dec 6 16:55:40 2019 +0000 efi/gop: Fix memory leak in __gop_query32/64() [ Upstream commit ff397be685e410a59c34b21ce0c55d4daa466bb7 ] efi_graphics_output_protocol::query_mode() returns info in callee-allocated memory which must be freed by the caller, which we aren't doing. We don't actually need to call query_mode() in order to obtain the info for the current graphics mode, which is already there in gop->mode->info, so just access it directly in the setup_gop32/64() functions. Also nothing uses the size of the info structure, so don't update the passed-in size (which is the size of the gop_handle table in bytes) unnecessarily. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-5-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 60bb249c737620923fa9704aa8f96d9f4c1a72c0 Author: Arvind Sankar Date: Fri Dec 6 16:55:39 2019 +0000 efi/gop: Return EFI_SUCCESS if a usable GOP was found [ Upstream commit dbd89c303b4420f6cdb689fd398349fc83b059dd ] If we've found a usable instance of the Graphics Output Protocol (GOP) with a framebuffer, it is possible that one of the later EFI calls fails while checking if any support console output. In this case status may be an EFI error code even though we found a usable GOP. Fix this by explicitly return EFI_SUCCESS if a usable GOP has been located. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-4-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 8c73e052ae3fccae6e012b350519e417f18183f5 Author: Arvind Sankar Date: Fri Dec 6 16:55:38 2019 +0000 efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs [ Upstream commit 6fc3cec30dfeee7d3c5db8154016aff9d65503c5 ] If we don't find a usable instance of the Graphics Output Protocol (GOP) because none of them have a framebuffer (i.e. they were all PIXEL_BLT_ONLY), but all the EFI calls succeeded, we will return EFI_SUCCESS even though we didn't find a usable GOP. Fix this by explicitly returning EFI_NOT_FOUND if no usable GOPs are found, allowing the caller to probe for UGA instead. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-3-ardb@kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit b72860fb43498ca03f08d83adcaa2af77f7703b0 Author: Florian Westphal Date: Mon Dec 2 18:35:40 2019 +0100 selftests: netfilter: use randomized netns names [ Upstream commit 5a2e6af81807d4616f9839ad0ae7d1313b45c64d ] Using ns0, ns1, etc. isn't a good idea, they might exist already. Use a random suffix. Also, older nft versions don't support "-" as alias for stdin, so use /dev/stdin instead. Signed-off-by: Florian Westphal Acked-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 89b5e38e7065cfc9c50ce97483d0aa49fdcf2e12 Author: Hans de Goede Date: Tue Dec 3 23:14:42 2019 +0100 ASoC: Intel: bytcr_rt5640: Update quirk for Teclast X89 [ Upstream commit 7eccc05c7101f34cc36afe9405d15de6d4099fb4 ] When the Teclast X89 quirk was added we did not have jack-detection support yet. Note the over-current detection limit is set to 2mA instead of the usual 1.5mA because this tablet tends to give false-positive button-presses when it is set to 1.5mA. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20191203221442.2657-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 77c771269c5fa0e1cf3a9c16b5b36826b598f8c3 Author: Dave Young Date: Wed Dec 4 15:52:33 2019 +0800 x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage [ Upstream commit af164898482817a1d487964b68f3c21bae7a1beb ] Michael Weiser reported that he got this error during a kexec rebooting: esrt: Unsupported ESRT version 2904149718861218184. The ESRT memory stays in EFI boot services data, and it was reserved in kernel via efi_mem_reserve(). The initial purpose of the reservation is to reuse the EFI boot services data across kexec reboot. For example the BGRT image data and some ESRT memory like Michael reported. But although the memory is reserved it is not updated in the X86 E820 table, and kexec_file_load() iterates system RAM in the IO resource list to find places for kernel, initramfs and other stuff. In Michael's case the kexec loaded initramfs overwrote the ESRT memory and then the failure happened. Since kexec_file_load() depends on the E820 table being updated, just fix this by updating the reserved EFI boot services memory as reserved type in E820. Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are bypassed in the reservation code path because they are assumed as reserved. But the reservation is still needed for multiple kexec reboots, and it is the only possible case we come here thus just drop the code chunk, then everything works without side effects. On my machine the ESRT memory sits in an EFI runtime data range, it does not trigger the problem, but I successfully tested with BGRT instead. both kexec_load() and kexec_file_load() work and kdump works as well. [ mingo: Edited the changelog. ] Reported-by: Michael Weiser Tested-by: Michael Weiser Signed-off-by: Dave Young Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Eric W. Biederman Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: kexec@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191204075233.GA10520@dhcp-128-65.nay.redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 91a0261630a91811f26403483eafe72a04a0435d Author: Wen Yang Date: Sun Dec 1 11:02:50 2019 +0800 regulator: core: fix regulator_register() error paths to properly release rdev [ Upstream commit a3cde9534ebdafe18a9bbab208df724c57e6c8e8 ] There are several issues with the error handling code of the regulator_register() function: ret = device_register(&rdev->dev); if (ret != 0) { put_device(&rdev->dev); --> rdev released goto unset_supplies; } ... unset_supplies: ... unset_regulator_supplies(rdev); --> use-after-free ... clean: if (dangling_of_gpiod) gpiod_put(config->ena_gpiod); kfree(rdev); --> double free We add a variable to record the failure of device_register() and move put_device() down a bit to avoid the above issues. Fixes: c438b9d01736 ("regulator: core: Move registration of regulator device") Signed-off-by: Wen Yang Cc: Liam Girdwood Cc: Mark Brown Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191201030250.38074-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0fb18176a69d03fad44cd80e6684e3410a0bd448 Author: Sudip Mukherjee Date: Fri Nov 15 11:36:10 2019 +0000 libtraceevent: Copy pkg-config file to output folder when using O= [ Upstream commit 15b3904f8e884e0d34d5f09906cf6526d0b889a2 ] When we use 'O=' with make to build libtraceevent in a separate folder it still copies 'libtraceevent.pc' to its source folder. Modify the Makefile so that it uses the output folder to copy the pkg-config file and install from there. Signed-off-by: Sudipm Mukherjee Reviewed-by: Steven Rostedt (VMware) Cc: linux-trace-devel@vger.kernel.org Link: http://lore.kernel.org/lkml/20191115113610.21493-2-sudipm.mukherjee@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 181888b6f1081a45e73d84d5131c1d04eb1a69e1 Author: Sudip Mukherjee Date: Fri Nov 15 11:36:09 2019 +0000 libtraceevent: Fix lib installation with O= [ Upstream commit 587db8ebdac2c5eb3a8851e16b26f2e2711ab797 ] When we use 'O=' with make to build libtraceevent in a separate folder it fails to install libtraceevent.a and libtraceevent.so.1.1.0 with the error: INSTALL /home/sudip/linux/obj-trace/libtraceevent.a INSTALL /home/sudip/linux/obj-trace/libtraceevent.so.1.1.0 cp: cannot stat 'libtraceevent.a': No such file or directory Makefile:225: recipe for target 'install_lib' failed make: *** [install_lib] Error 1 I used the command: make O=../../../obj-trace DESTDIR=~/test prefix==/usr install It turns out libtraceevent Makefile, even though it builds in a separate folder, searches for libtraceevent.a and libtraceevent.so.1.1.0 in its source folder. So, add the 'OUTPUT' prefix to the source path so that 'make' looks for the files in the correct place. Signed-off-by: Sudipm Mukherjee Reviewed-by: Steven Rostedt (VMware) Cc: linux-trace-devel@vger.kernel.org Link: http://lore.kernel.org/lkml/20191115113610.21493-1-sudipm.mukherjee@gmail.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 389c0f743f9629392d119a11da780054456e9c49 Author: qize wang Date: Fri Nov 29 18:10:54 2019 +0800 mwifiex: Fix heap overflow in mmwifiex_process_tdls_action_frame() [ Upstream commit 1e58252e334dc3f3756f424a157d1b7484464c40 ] mwifiex_process_tdls_action_frame() without checking the incoming tdls infomation element's vality before use it, this may cause multi heap buffer overflows. Fix them by putting vality check before use it. IE is TLV struct, but ht_cap and ht_oper aren’t TLV struct. the origin marvell driver code is wrong: memcpy(&sta_ptr->tdls_cap.ht_oper, pos,.... memcpy((u8 *)&sta_ptr->tdls_cap.ht_capb, pos,... Fix the bug by changing pos(the address of IE) to pos+2 ( the address of IE value ). Signed-off-by: qize wang Signed-off-by: Kalle Valo Signed-off-by: Sasha Levin commit 478c08d77e4031d12bf006951bcb5674a9c8f070 Author: wenxu Date: Wed Nov 13 12:21:07 2019 +0800 netfilter: nf_tables_offload: Check for the NETDEV_UNREGISTER event [ Upstream commit d1f4c966475c6dd2545c6625022cb24e878bee11 ] Check for the NETDEV_UNREGISTER event from the nft_offload_netdev_event function, which is the event that actually triggers the clean up. Fixes: 06d392cbe3db ("netfilter: nf_tables_offload: remove rules when the device unregisters") Signed-off-by: wenxu Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit 191e884476e6285bc2fc9a4257da11912150fa98 Author: Kai-Heng Feng Date: Fri Nov 29 14:23:03 2019 +0800 x86/intel: Disable HPET on Intel Ice Lake platforms [ Upstream commit e0748539e3d594dd26f0d27a270f14720b22a406 ] Like CFL and CFL-H, ICL SoC has skewed HPET timer once it hits PC10. So let's disable HPET on ICL. 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-2-kai.heng.feng@canonical.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 9443b8c7211085cc34d0b6e5047be7ad752b5e0a Author: Florian Westphal Date: Fri Nov 15 12:39:23 2019 +0100 netfilter: ctnetlink: netns exit must wait for callbacks [ Upstream commit 18a110b022a5c02e7dc9f6109d0bd93e58ac6ebb ] Curtis Taylor and Jon Maxwell reported and debugged a crash on 3.10 based kernel. Crash occurs in ctnetlink_conntrack_events because net->nfnl socket is NULL. The nfnl socket was set to NULL by netns destruction running on another cpu. The exiting network namespace calls the relevant destructors in the following order: 1. ctnetlink_net_exit_batch This nulls out the event callback pointer in struct netns. 2. nfnetlink_net_exit_batch This nulls net->nfnl socket and frees it. 3. nf_conntrack_cleanup_net_list This removes all remaining conntrack entries. This is order is correct. The only explanation for the crash so ar is: cpu1: conntrack is dying, eviction occurs: -> nf_ct_delete() -> nf_conntrack_event_report \ -> nf_conntrack_eventmask_report -> notify->fcn() (== ctnetlink_conntrack_events). cpu1: a. fetches rcu protected pointer to obtain ctnetlink event callback. b. gets interrupted. cpu2: runs netns exit handlers: a runs ctnetlink destructor, event cb pointer set to NULL. b runs nfnetlink destructor, nfnl socket is closed and set to NULL. cpu1: c. resumes and trips over NULL net->nfnl. Problem appears to be that ctnetlink_net_exit_batch only prevents future callers of nf_conntrack_eventmask_report() from obtaining the callback. It doesn't wait of other cpus that might have already obtained the callbacks address. I don't see anything in upstream kernels that would prevent similar crash: We need to wait for all cpus to have exited the event callback. Fixes: 9592a5c01e79dbc59eb56fa ("netfilter: ctnetlink: netns support") Signed-off-by: Florian Westphal Signed-off-by: Pablo Neira Ayuso Signed-off-by: Sasha Levin commit c120c3dbeb76305235c8e557f84d9e2d7d0f5933 Author: Marco Elver Date: Wed Nov 20 16:57:15 2019 +0100 locking/spinlock/debug: Fix various data races [ Upstream commit 1a365e822372ba24c9da0822bc583894f6f3d821 ] This fixes various data races in spinlock_debug. By testing with KCSAN, it is observable that the console gets spammed with data races reports, suggesting these are extremely frequent. Example data race report: read to 0xffff8ab24f403c48 of 4 bytes by task 221 on cpu 2: debug_spin_lock_before kernel/locking/spinlock_debug.c:85 [inline] do_raw_spin_lock+0x9b/0x210 kernel/locking/spinlock_debug.c:112 __raw_spin_lock include/linux/spinlock_api_smp.h:143 [inline] _raw_spin_lock+0x39/0x40 kernel/locking/spinlock.c:151 spin_lock include/linux/spinlock.h:338 [inline] get_partial_node.isra.0.part.0+0x32/0x2f0 mm/slub.c:1873 get_partial_node mm/slub.c:1870 [inline] write to 0xffff8ab24f403c48 of 4 bytes by task 167 on cpu 3: debug_spin_unlock kernel/locking/spinlock_debug.c:103 [inline] do_raw_spin_unlock+0xc9/0x1a0 kernel/locking/spinlock_debug.c:138 __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:159 [inline] _raw_spin_unlock_irqrestore+0x2d/0x50 kernel/locking/spinlock.c:191 spin_unlock_irqrestore include/linux/spinlock.h:393 [inline] free_debug_processing+0x1b3/0x210 mm/slub.c:1214 __slab_free+0x292/0x400 mm/slub.c:2864 As a side-effect, with KCSAN, this eventually locks up the console, most likely due to deadlock, e.g. .. -> printk lock -> spinlock_debug -> KCSAN detects data race -> kcsan_print_report() -> printk lock -> deadlock. This fix will 1) avoid the data races, and 2) allow using lock debugging together with KCSAN. Reported-by: Qian Cai Signed-off-by: Marco Elver Cc: Andrew Morton Cc: Linus Torvalds Cc: Paul E. McKenney Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Will Deacon Link: https://lkml.kernel.org/r/20191120155715.28089-1-elver@google.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin commit 5a2d941e7a737999952e5bd37f99e34988fd22e5 Author: Linus Walleij Date: Thu Nov 28 09:37:18 2019 +0100 spi: fsl: Handle the single hardwired chipselect case [ Upstream commit 7251953d784baf7e5416afabe030a0e81de1a938 ] The Freescale MPC8xxx had a special quirk for handling a single hardwired chipselect, the case when we're using neither GPIO nor native chip select: when inspecting the device tree and finding zero "cs-gpios" on the device node the code would assume we have a single hardwired chipselect that leaves the device always selected. This quirk is not handled by the new core code, so we need to check the "cs-gpios" explicitly in the driver and set pdata->max_chipselect = 1 which will later fall through to the SPI master ->num_chipselect. Make sure not to assign the chip select handler in this case: there is no handling needed since the chip is always selected, and this is what the old code did as well. Cc: Christophe Leroy Reported-by: Christophe Leroy Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Linus Walleij Tested-by: Christophe Leroy (No tested the Link: https://lore.kernel.org/r/20191128083718.39177-3-linus.walleij@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b8ec95e4b983566d0a03994258489bd560bd51e4 Author: Linus Walleij Date: Thu Nov 28 09:37:17 2019 +0100 gpio: Handle counting of Freescale chipselects [ Upstream commit 71b8f600b034c7f5780f6fb311dabfe331c64feb ] We have a special quirk to handle the Freescale nonstandard SPI chipselect GPIOs in the gpiolib-of.c file, but it currently only handles the case where the GPIOs are actually requested (gpiod_*get()). We also need to handle that the SPI core attempts to count the GPIOs before use, and that needs a similar quirk in the OF part of the library. Cc: Christophe Leroy Reported-by: Christophe Leroy Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Linus Walleij Tested-by: Christophe Leroy Link: https://lore.kernel.org/r/20191128083718.39177-2-linus.walleij@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9d646e70f6deb5ca2b1a3e0c530205c076fd2a85 Author: Linus Walleij Date: Thu Nov 28 09:37:16 2019 +0100 spi: fsl: Fix GPIO descriptor support [ Upstream commit f106904968e2a075e64653b9b79dda9f0f070ab5 ] This makes the driver actually support looking up GPIO descriptor. A coding mistake in the initial descriptor support patch was that it was failing to turn on the very feature it was implementing. Mea culpa. Cc: Christophe Leroy Reported-by: Christophe Leroy Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Linus Walleij Tested-by: Christophe Leroy Link: https://lore.kernel.org/r/20191128083718.39177-1-linus.walleij@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit efd10b11717cb1599172f07391e525cc63d6b20a Author: Tzung-Bi Shih Date: Fri Nov 22 15:31:14 2019 +0800 ASoC: max98090: fix possible race conditions [ Upstream commit 45dfbf56975994822cce00b7475732a49f8aefed ] max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races: Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked. max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1). In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work. max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2). In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work. There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution. Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits. Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec. Adopts option B which is the better solution overall. Signed-off-by: Tzung-Bi Shih Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 8d333a5d262f564cb83b7c6e0b0b67231241fc78 Author: Wen Yang Date: Sun Nov 24 22:58:35 2019 +0800 regulator: fix use after free issue [ Upstream commit 4affd79a125ac91e6a53be843ea3960a8fc00cbb ] This is caused by dereferencing 'rdev' after put_device() in the _regulator_get()/_regulator_put() functions. This patch just moves the put_device() down a bit to avoid the issue. Signed-off-by: Wen Yang Cc: Liam Girdwood Cc: Mark Brown Cc: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20191124145835.25999-1-wenyang@linux.alibaba.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 10597f80ebddae8d2089e6abad54f8155106b5f4 Author: Jarkko Nikula Date: Mon Nov 25 14:51:59 2019 +0200 spi: pxa2xx: Add support for Intel Jasper Lake [ Upstream commit 9c7315c9fca5de203538163cf42699bb10328902 ] LPSS SPI on Intel Jasper Lake is compatible with Intel Ice Lake which follows Intel Cannon Lake. Add PCI IDs of Jasper Lake. Signed-off-by: Jarkko Nikula Link: https://lore.kernel.org/r/20191125125159.15404-1-jarkko.nikula@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 42ba2aded448a79133720eeec2db432dee5cc312 Author: Shuming Fan Date: Mon Nov 25 17:19:40 2019 +0800 ASoC: rt5682: fix i2c arbitration lost issue [ Upstream commit bc094709de0192a756c6946a7c89c543243ae609 ] This patch modified the HW initial setting to fix i2c arbitration lost issue. Signed-off-by: Shuming Fan Link: https://lore.kernel.org/r/20191125091940.11953-1-shumingf@realtek.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b2eccb43aa1b2da075373a26b978f1253bee2b50 Author: Daniel Borkmann Date: Mon Jan 6 22:51:57 2020 +0100 bpf: Fix passing modified ctx to ld/abs/ind instruction commit 6d4f151acf9a4f6fab09b615f246c717ddedcf0c upstream. Anatoly has been fuzzing with kBdysch harness and reported a KASAN slab oob in one of the outcomes: [...] [ 77.359642] BUG: KASAN: slab-out-of-bounds in bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.360463] Read of size 4 at addr ffff8880679bac68 by task bpf/406 [ 77.361119] [ 77.361289] CPU: 2 PID: 406 Comm: bpf Not tainted 5.5.0-rc2-xfstests-00157-g2187f215eba #1 [ 77.362134] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 77.362984] Call Trace: [ 77.363249] dump_stack+0x97/0xe0 [ 77.363603] print_address_description.constprop.0+0x1d/0x220 [ 77.364251] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365030] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.365860] __kasan_report.cold+0x37/0x7b [ 77.366365] ? bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.366940] kasan_report+0xe/0x20 [ 77.367295] bpf_skb_load_helper_8_no_cache+0x71/0x130 [ 77.367821] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.368278] ? mark_lock+0xa3/0x9b0 [ 77.368641] ? kvm_sched_clock_read+0x14/0x30 [ 77.369096] ? sched_clock+0x5/0x10 [ 77.369460] ? sched_clock_cpu+0x18/0x110 [ 77.369876] ? bpf_skb_load_helper_8+0xf0/0xf0 [ 77.370330] ___bpf_prog_run+0x16c0/0x28f0 [ 77.370755] __bpf_prog_run32+0x83/0xc0 [ 77.371153] ? __bpf_prog_run64+0xc0/0xc0 [ 77.371568] ? match_held_lock+0x1b/0x230 [ 77.371984] ? rcu_read_lock_held+0xa1/0xb0 [ 77.372416] ? rcu_is_watching+0x34/0x50 [ 77.372826] sk_filter_trim_cap+0x17c/0x4d0 [ 77.373259] ? sock_kzfree_s+0x40/0x40 [ 77.373648] ? __get_filter+0x150/0x150 [ 77.374059] ? skb_copy_datagram_from_iter+0x80/0x280 [ 77.374581] ? do_raw_spin_unlock+0xa5/0x140 [ 77.375025] unix_dgram_sendmsg+0x33a/0xa70 [ 77.375459] ? do_raw_spin_lock+0x1d0/0x1d0 [ 77.375893] ? unix_peer_get+0xa0/0xa0 [ 77.376287] ? __fget_light+0xa4/0xf0 [ 77.376670] __sys_sendto+0x265/0x280 [ 77.377056] ? __ia32_sys_getpeername+0x50/0x50 [ 77.377523] ? lock_downgrade+0x350/0x350 [ 77.377940] ? __sys_setsockopt+0x2a6/0x2c0 [ 77.378374] ? sock_read_iter+0x240/0x240 [ 77.378789] ? __sys_socketpair+0x22a/0x300 [ 77.379221] ? __ia32_sys_socket+0x50/0x50 [ 77.379649] ? mark_held_locks+0x1d/0x90 [ 77.380059] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 77.380536] __x64_sys_sendto+0x74/0x90 [ 77.380938] do_syscall_64+0x68/0x2a0 [ 77.381324] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 77.381878] RIP: 0033:0x44c070 [...] After further debugging, turns out while in case of other helper functions we disallow passing modified ctx, the special case of ld/abs/ind instruction which has similar semantics (except r6 being the ctx argument) is missing such check. Modified ctx is impossible here as bpf_skb_load_helper_8_no_cache() and others are expecting skb fields in original position, hence, add check_ctx_reg() to reject any modified ctx. Issue was first introduced back in f1174f77b50c ("bpf/verifier: rework value tracking"). Fixes: f1174f77b50c ("bpf/verifier: rework value tracking") Reported-by: Anatoly Trosinenko Signed-off-by: Daniel Borkmann Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200106215157.3553-1-daniel@iogearbox.net Signed-off-by: Greg Kroah-Hartman commit 61e861528ec14a0faa07e8152906aeefe7204236 Author: Andrey Konovalov Date: Mon Oct 21 16:20:59 2019 +0200 USB: dummy-hcd: use usb_urb_dir_in instead of usb_pipein commit 6dabeb891c001c592645df2f477fed9f5d959987 upstream. Commit fea3409112a9 ("USB: add direction bit to urb->transfer_flags") has added a usb_urb_dir_in() helper function that can be used to determine the direction of the URB. With that patch USB_DIR_IN control requests with wLength == 0 are considered out requests by real USB HCDs. This patch changes dummy-hcd to use the usb_urb_dir_in() helper to match that behavior. Signed-off-by: Andrey Konovalov Link: https://lore.kernel.org/r/4ae9e68ebca02f08a93ac61fe065057c9a01f0a8.1571667489.git.andreyknvl@google.com Signed-off-by: Greg Kroah-Hartman