commit 8dc0fcbcfa97bdeb514fa229125791a467e0e319 Author: Greg Kroah-Hartman Date: Sat Jan 23 16:04:06 2021 +0100 Linux 5.10.10 Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20210122135735.652681690@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit 3fe6036663603240b6bd5c7c91cec1db5b10ae80 Author: Michael Hennerich Date: Thu Jan 14 17:42:17 2021 +0200 spi: cadence: cache reference clock rate during probe commit 4d163ad79b155c71bf30366dc38f8d2502f78844 upstream. The issue is that using SPI from a callback under the CCF lock will deadlock, since this code uses clk_get_rate(). Fixes: c474b38665463 ("spi: Add driver for Cadence SPI controller") Signed-off-by: Michael Hennerich Signed-off-by: Alexandru Ardelean Link: https://lore.kernel.org/r/20210114154217.51996-1-alexandru.ardelean@analog.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit da02e4ca8a297293e73449e9d187ba02a7667c43 Author: Christophe Leroy Date: Thu Jan 14 13:09:37 2021 +0000 spi: fsl: Fix driver breakage when SPI_CS_HIGH is not set in spi->mode commit 7a2da5d7960a64ee923fe3e31f01a1101052c66f upstream. Commit 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") broke fsl spi driver. As now we fully rely on gpiolib for handling the polarity of chip selects, the driver shall not alter the GPIO value anymore when SPI_CS_HIGH is not set in spi->mode. Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy Link: https://lore.kernel.org/r/6b51cc2bfbca70d3e9b9da7b7aa4c7a9d793ca0e.1610629002.git.christophe.leroy@csgroup.eu Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 04ed7f1da638fac5ad8ae64a11cec39395d98683 Author: Ayush Sawal Date: Tue Jan 12 11:06:00 2021 +0530 cxgb4/chtls: Fix tid stuck due to wrong update of qid commit 8ad2a970d2010add3963e7219eb50367ab3fa4eb upstream. TID stuck is seen when there is a race in CPL_PASS_ACCEPT_RPL/CPL_ABORT_REQ and abort is arriving before the accept reply, which sets the queue number. In this case HW ends up sending CPL_ABORT_RPL_RSS to an incorrect ingress queue. V1->V2: - Removed the unused variable len in chtls_set_quiesce_ctrl(). V2->V3: - As kfree_skb() has a check for null skb, so removed this check before calling kfree_skb() in func chtls_send_reset(). Fixes: cc35c88ae4db ("crypto : chtls - CPL handler definition") Signed-off-by: Rohit Maheshwari Signed-off-by: Ayush Sawal Link: https://lore.kernel.org/r/20210112053600.24590-1-ayush.sawal@chelsio.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d0b97c8cd63e37e6d4dc9fefd6381b09f6c31a67 Author: Vladimir Oltean Date: Tue Jan 12 01:09:43 2021 +0200 net: dsa: unbind all switches from tree when DSA master unbinds commit 07b90056cb15ff9877dca0d8f1b6583d1051f724 upstream. Currently the following happens when a DSA master driver unbinds while there are DSA switches attached to it: $ echo 0000:00:00.5 > /sys/bus/pci/drivers/mscc_felix/unbind ------------[ cut here ]------------ WARNING: CPU: 0 PID: 392 at net/core/dev.c:9507 Call trace: rollback_registered_many+0x5fc/0x688 unregister_netdevice_queue+0x98/0x120 dsa_slave_destroy+0x4c/0x88 dsa_port_teardown.part.16+0x78/0xb0 dsa_tree_teardown_switches+0x58/0xc0 dsa_unregister_switch+0x104/0x1b8 felix_pci_remove+0x24/0x48 pci_device_remove+0x48/0xf0 device_release_driver_internal+0x118/0x1e8 device_driver_detach+0x28/0x38 unbind_store+0xd0/0x100 Located at the above location is this WARN_ON: /* Notifier chain MUST detach us all upper devices. */ WARN_ON(netdev_has_any_upper_dev(dev)); Other stacked interfaces, like VLAN, do indeed listen for NETDEV_UNREGISTER on the real_dev and also unregister themselves at that time, which is clearly the behavior that rollback_registered_many expects. But DSA interfaces are not VLAN. They have backing hardware (platform devices, PCI devices, MDIO, SPI etc) which have a life cycle of their own and we can't just trigger an unregister from the DSA framework when we receive a netdev notifier that the master unregisters. Luckily, there is something we can do, and that is to inform the driver core that we have a runtime dependency to the DSA master interface's device, and create a device link where that is the supplier and we are the consumer. Having this device link will make the DSA switch unbind before the DSA master unbinds, which is enough to avoid the WARN_ON from rollback_registered_many. Note that even before the blamed commit, DSA did nothing intelligent when the master interface got unregistered either. See the discussion here: https://lore.kernel.org/netdev/20200505210253.20311-1-f.fainelli@gmail.com/ But this time, at least the WARN_ON is loud enough that the upper_dev_link commit can be blamed. The advantage with this approach vs dev_hold(master) in the attached link is that the latter is not meant for long term reference counting. With dev_hold, the only thing that will happen is that when the user attempts an unbind of the DSA master, netdev_wait_allrefs will keep waiting and waiting, due to DSA keeping the refcount forever. DSA would not access freed memory corresponding to the master interface, but the unbind would still result in a freeze. Whereas with device links, graceful teardown is ensured. It even works with cascaded DSA trees. $ echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind [ 1818.797546] device swp0 left promiscuous mode [ 1819.301112] sja1105 spi2.0: Link is Down [ 1819.307981] DSA: tree 1 torn down [ 1819.312408] device eno2 left promiscuous mode [ 1819.656803] mscc_felix 0000:00:00.5: Link is Down [ 1819.667194] DSA: tree 0 torn down [ 1819.711557] fsl_enetc 0000:00:00.2 eno2: Link is Down This approach allows us to keep the DSA framework absolutely unchanged, and the driver core will just know to unbind us first when the master goes away - as opposed to the large (and probably impossible) rework required if attempting to listen for NETDEV_UNREGISTER. As per the documentation at Documentation/driver-api/device_link.rst, specifying the DL_FLAG_AUTOREMOVE_CONSUMER flag causes the device link to be automatically purged when the consumer fails to probe or later unbinds. So we don't need to keep the consumer_link variable in struct dsa_switch. Fixes: 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20210111230943.3701806-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6423b2193794f2988f37c31c6e03ccfddecf6f58 Author: Lorenzo Bianconi Date: Sat Dec 26 10:39:08 2020 +0100 mac80211: check if atf has been disabled in __ieee80211_schedule_txq commit c13cf5c159660451c8fbdc37efb998b198e1d305 upstream. Check if atf has been disabled in __ieee80211_schedule_txq() in order to avoid a given sta is always put to the beginning of the active_txqs list and never moved to the end since deficit is not decremented in ieee80211_sta_register_airtime() Fixes: b4809e9484da1 ("mac80211: Add airtime accounting and scheduling to TXQs") Signed-off-by: Lorenzo Bianconi Acked-by: Toke Høiland-Jørgensen Link: https://lore.kernel.org/r/93889406c50f1416214c079ca0b8c9faecc5143e.1608975195.git.lorenzo@kernel.org Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a00432fa4cb9c022c74303c70080267e6a93d624 Author: Felix Fietkau Date: Fri Dec 18 20:15:25 2020 +0100 mac80211: do not drop tx nulldata packets on encrypted links commit 2463ec86cd0338a2c2edbfb0b9d50c52ff76ff43 upstream. ieee80211_tx_h_select_key drops any non-mgmt packets without a key when encryption is used. This is wrong for nulldata packets that can't be encrypted and are sent out for probing clients and indicating 4-address mode. Reported-by: Sebastian Gottschall Fixes: a0761a301746 ("mac80211: drop data frames without key on encrypted links") Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20201218191525.1168-1-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit a6d508c63573de7682305910cee05ceda28b778a Author: Antonio Borneo Date: Tue Sep 22 09:42:53 2020 +0200 drm/panel: otm8009a: allow using non-continuous dsi clock commit 880ee3b7615e7cc087f659cb80ce22f5db56f9a2 upstream. The panel is able to work when dsi clock is non-continuous, thus the system power consumption can be reduced using such feature. Add MIPI_DSI_CLOCK_NON_CONTINUOUS to panel's mode_flags. Changes in v2: - Added my signed-off Signed-off-by: Antonio Borneo Signed-off-by: Yannick Fertre Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200922074253.28810-1-yannick.fertre@st.com Cc: "Alex G." Signed-off-by: Greg Kroah-Hartman commit fd21e00c5e0b0b9333e8cc26ab188f360447eb6d Author: Qinglang Miao Date: Wed Jan 13 15:31:00 2021 +0800 can: mcp251xfd: mcp251xfd_handle_rxif_one(): fix wrong NULL pointer check [ Upstream commit ca4c6ebeeb50112f5178f14bfb6d9e8ddf148545 ] If alloc_canfd_skb() returns NULL, 'cfg' is an uninitialized variable, so we should check 'skb' rather than 'cfd' after calling alloc_canfd_skb(priv->ndev, &cfd). Fixes: 55e5b97f003e ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Signed-off-by: Qinglang Miao Reviewed-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20210113073100.79552-1-miaoqinglang@huawei.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Greg Kroah-Hartman commit 65accf0324bf68af1d0500d3478dc981047d1463 Author: Seb Laveze Date: Tue Jan 12 15:01:22 2021 +0100 net: stmmac: use __napi_schedule() for PREEMPT_RT [ Upstream commit 1f02efd1bb35bee95feed6aab46d1217f29d555b ] Use of __napi_schedule_irqoff() is not safe with PREEMPT_RT in which hard interrupts are not disabled while running the threaded interrupt. Using __napi_schedule() works for both PREEMPT_RT and mainline Linux, just at the cost of an additional check if interrupts are disabled for mainline (since they are already disabled). Similar to the fix done for enetc commit 215602a8d212 ("enetc: use napi_schedule to be compatible with PREEMPT_RT") Signed-off-by: Seb Laveze Link: https://lore.kernel.org/r/20210112140121.1487619-1-sebastien.laveze@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 6f3fe96a69565c96d95ea20e72c02bf9761c4b03 Author: David Howells Date: Tue Jan 12 15:23:51 2021 +0000 rxrpc: Fix handling of an unsupported token type in rxrpc_read() [ Upstream commit d52e419ac8b50c8bef41b398ed13528e75d7ad48 ] Clang static analysis reports the following: net/rxrpc/key.c:657:11: warning: Assigned value is garbage or undefined toksize = toksizes[tok++]; ^ ~~~~~~~~~~~~~~~ rxrpc_read() contains two consecutive loops. The first loop calculates the token sizes and stores the results in toksizes[] and the second one uses the array. When there is an error in identifying the token in the first loop, the token is skipped, no change is made to the toksizes[] array. When the same error happens in the second loop, the token is not skipped. This will cause the toksizes[] array to be out of step and will overrun past the calculated sizes. Fix this by making both loops log a message and return an error in this case. This should only happen if a new token type is incompletely implemented, so it should normally be impossible to trigger this. Fixes: 9a059cd5ca7d ("rxrpc: Downgrade the BUG() for unsupported token type in rxrpc_read()") Reported-by: Tom Rix Signed-off-by: David Howells Reviewed-by: Tom Rix Link: https://lore.kernel.org/r/161046503122.2445787.16714129930607546635.stgit@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 2bfb953aeebf39d32f159450d69278b4c9c856dd Author: Vladimir Oltean Date: Tue Jan 12 02:48:31 2021 +0200 net: dsa: clear devlink port type before unregistering slave netdevs [ Upstream commit 91158e1680b164c8d101144ca916a3dca10c3e17 ] Florian reported a use-after-free bug in devlink_nl_port_fill found with KASAN: (devlink_nl_port_fill) (devlink_port_notify) (devlink_port_unregister) (dsa_switch_teardown.part.3) (dsa_tree_teardown_switches) (dsa_unregister_switch) (bcm_sf2_sw_remove) (platform_remove) (device_release_driver_internal) (device_links_unbind_consumers) (device_release_driver_internal) (device_driver_detach) (unbind_store) Allocated by task 31: alloc_netdev_mqs+0x5c/0x50c dsa_slave_create+0x110/0x9c8 dsa_register_switch+0xdb0/0x13a4 b53_switch_register+0x47c/0x6dc bcm_sf2_sw_probe+0xaa4/0xc98 platform_probe+0x90/0xf4 really_probe+0x184/0x728 driver_probe_device+0xa4/0x278 __device_attach_driver+0xe8/0x148 bus_for_each_drv+0x108/0x158 Freed by task 249: free_netdev+0x170/0x194 dsa_slave_destroy+0xac/0xb0 dsa_port_teardown.part.2+0xa0/0xb4 dsa_tree_teardown_switches+0x50/0xc4 dsa_unregister_switch+0x124/0x250 bcm_sf2_sw_remove+0x98/0x13c platform_remove+0x44/0x5c device_release_driver_internal+0x150/0x254 device_links_unbind_consumers+0xf8/0x12c device_release_driver_internal+0x84/0x254 device_driver_detach+0x30/0x34 unbind_store+0x90/0x134 What happens is that devlink_port_unregister emits a netlink DEVLINK_CMD_PORT_DEL message which associates the devlink port that is getting unregistered with the ifindex of its corresponding net_device. Only trouble is, the net_device has already been unregistered. It looks like we can stub out the search for a corresponding net_device if we clear the devlink_port's type. This looks like a bit of a hack, but also seems to be the reason why the devlink_port_type_clear function exists in the first place. Fixes: 3122433eb533 ("net: dsa: Register devlink ports before calling DSA driver setup()") Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli Tested-by: Florian fainelli Reported-by: Florian Fainelli Link: https://lore.kernel.org/r/20210112004831.3778323-1-olteanv@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c469b23d1b541cbdd6831b468acd4bfb849180c6 Author: Marco Felsch Date: Mon Jan 11 09:59:32 2021 +0100 net: phy: smsc: fix clk error handling [ Upstream commit a18caa97b1bda0a3d126a7be165ddcfc56c2dde6 ] Commit bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in support") added the phy clk support. The commit already checks if clk_get_optional() throw an error but instead of returning the error it ignores it. Fixes: bedd8d78aba3 ("net: phy: smsc: LAN8710/20: add phy refclk in support") Suggested-by: Jakub Kicinski Signed-off-by: Marco Felsch Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210111085932.28680-1-m.felsch@pengutronix.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit ad2175c9fb27b5e0c6fef08143d94129c86a153b Author: Geert Uytterhoeven Date: Tue Jan 5 16:15:16 2021 +0100 dt-bindings: net: renesas,etheravb: RZ/G2H needs tx-internal-delay-ps [ Upstream commit f97844f9c518172f813b7ece18a9956b1f70c1bb ] The merge resolution of the interaction of commits 307eea32b202864c ("dt-bindings: net: renesas,ravb: Add support for r8a774e1 SoC") and d7adf6331189cbe9 ("dt-bindings: net: renesas,etheravb: Convert to json-schema") missed that "tx-internal-delay-ps" should be a required property on RZ/G2H. Fixes: 8b0308fe319b8002 ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20210105151516.1540653-1-geert+renesas@glider.be Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 024158d3b5715e830bf4b51c4452132937c8f1e8 Author: Eric Dumazet Date: Wed Jan 13 08:18:19 2021 -0800 net: avoid 32 x truesize under-estimation for tiny skbs [ Upstream commit 3226b158e67cfaa677fd180152bfb28989cb2fac ] Both virtio net and napi_get_frags() allocate skbs with a very small skb->head While using page fragments instead of a kmalloc backed skb->head might give a small performance improvement in some cases, there is a huge risk of under estimating memory usage. For both GOOD_COPY_LEN and GRO_MAX_HEAD, we can fit at least 32 allocations per page (order-3 page in x86), or even 64 on PowerPC We have been tracking OOM issues on GKE hosts hitting tcp_mem limits but consuming far more memory for TCP buffers than instructed in tcp_mem[2] Even if we force napi_alloc_skb() to only use order-0 pages, the issue would still be there on arches with PAGE_SIZE >= 32768 This patch makes sure that small skb head are kmalloc backed, so that other objects in the slab page can be reused instead of being held as long as skbs are sitting in socket queues. Note that we might in the future use the sk_buff napi cache, instead of going through a more expensive __alloc_skb() Another idea would be to use separate page sizes depending on the allocated length (to never have more than 4 frags per page) I would like to thank Greg Thelen for his precious help on this matter, analysing crash dumps is always a time consuming task. Fixes: fd11a83dd363 ("net: Pull out core bits of __netdev_alloc_skb and add __napi_alloc_skb") Signed-off-by: Eric Dumazet Cc: Paolo Abeni Cc: Greg Thelen Reviewed-by: Alexander Duyck Acked-by: Michael S. Tsirkin Link: https://lore.kernel.org/r/20210113161819.1155526-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 72cfe5b07e856cf21a6c721a9a1357ef2a87eaff Author: Yannick Vignon Date: Wed Jan 13 14:15:57 2021 +0100 net: stmmac: fix taprio configuration when base_time is in the past [ Upstream commit fe28c53ed71d463e187748b6b10e1130dd72ceeb ] The Synopsys TSN MAC supports Qbv base times in the past, but only up to a certain limit. As a result, a taprio qdisc configuration with a small base time (for example when treating the base time as a simple phase offset) is not applied by the hardware and silently ignored. This was observed on an NXP i.MX8MPlus device, but likely affects all TSN-variants of the MAC. Fix the issue by making sure the base time is in the future, pushing it by an integer amount of cycle times if needed. (a similar check is already done in several other taprio implementations, see for example drivers/net/ethernet/intel/igc/igc_tsn.c#L116 or drivers/net/dsa/sja1105/sja1105_ptp.h#L39). Fixes: b60189e0392f ("net: stmmac: Integrate EST with TAPRIO scheduler API") Signed-off-by: Yannick Vignon Link: https://lore.kernel.org/r/20210113131557.24651-2-yannick.vignon@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 34f782b9d0dc748e2770c1bc118a5aadc8c19831 Author: Yannick Vignon Date: Wed Jan 13 14:15:56 2021 +0100 net: stmmac: fix taprio schedule configuration [ Upstream commit b76889ff51bfee318bea15891420e5aefd2833a0 ] When configuring a 802.1Qbv schedule through the tc taprio qdisc on an NXP i.MX8MPlus device, the effective cycle time differed from the requested one by N*96ns, with N number of entries in the Qbv Gate Control List. This is because the driver was adding a 96ns margin to each interval of the GCL, apparently to account for the IPG. The problem was observed on NXP i.MX8MPlus devices but likely affected all devices relying on the same configuration callback (dwmac 4.00, 4.10, 5.10 variants). Fix the issue by removing the margins, and simply setup the MAC with the provided cycle time value. This is the behavior expected by the user-space API, as altering the Qbv schedule timings would break standards conformance. This is also the behavior of several other Ethernet MAC implementations supporting taprio, including the dwxgmac variant of stmmac. Fixes: 504723af0d85 ("net: stmmac: Add basic EST support for GMAC5+") Signed-off-by: Yannick Vignon Link: https://lore.kernel.org/r/20210113131557.24651-1-yannick.vignon@oss.nxp.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 00442a962152ffc1052dcdbd3c8e01c9ad396ec2 Author: Jakub Kicinski Date: Wed Jan 13 17:29:47 2021 -0800 net: sit: unregister_netdevice on newlink's error path [ Upstream commit 47e4bb147a96f1c9b4e7691e7e994e53838bfff8 ] We need to unregister the netdevice if config failed. .ndo_uninit takes care of most of the heavy lifting. This was uncovered by recent commit c269a24ce057 ("net: make free_netdev() more lenient with unregistering devices"). Previously the partially-initialized device would be left in the system. Reported-and-tested-by: syzbot+2393580080a2da190f04@syzkaller.appspotmail.com Fixes: e2f1f072db8d ("sit: allow to configure 6rd tunnels via netlink") Acked-by: Nicolas Dichtel Link: https://lore.kernel.org/r/20210114012947.2515313-1-kuba@kernel.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5ae7725043250a61589f426ef454b1fb8e7be808 Author: David Wu Date: Wed Jan 13 11:41:09 2021 +0800 net: stmmac: Fixed mtu channged by cache aligned [ Upstream commit 5b55299eed78538cc4746e50ee97103a1643249c ] Since the original mtu is not used when the mtu is updated, the mtu is aligned with cache, this will get an incorrect. For example, if you want to configure the mtu to be 1500, but mtu 1536 is configured in fact. Fixed: eaf4fac478077 ("net: stmmac: Do not accept invalid MTU values") Signed-off-by: David Wu Link: https://lore.kernel.org/r/20210113034109.27865-1-david.wu@rock-chips.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 741690db7a357743545e0fa83310bdb1152ecaac Author: Cristian Dumitrescu Date: Mon Jan 11 18:11:38 2021 +0000 i40e: fix potential NULL pointer dereferencing [ Upstream commit 7128c834d30e6b2cf649f14d8fc274941786d0e1 ] Currently, the function i40e_construct_skb_zc only frees the input xdp buffer when the output skb is successfully built. On error, the function i40e_clean_rx_irq_zc does not commit anything for the current packet descriptor and simply exits the packet descriptor processing loop, with the plan to restart the processing of this descriptor on the next invocation. Therefore, on error the ring next-to-clean pointer should not advance, the xdp i.e. *bi buffer should not be freed and the current buffer info should not be invalidated by setting *bi to NULL. Therefore, the *bi should only be set to NULL when the function i40e_construct_skb_zc is successful, otherwise a NULL *bi will be dereferenced when the work for the current descriptor is eventually restarted. Fixes: 3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL") Signed-off-by: Cristian Dumitrescu Acked-by: Björn Töpel Link: https://lore.kernel.org/r/20210111181138.49757-1-cristian.dumitrescu@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7c85d8e7ebd29d0720a9caba76d4debbceefd8a9 Author: Baptiste Lepers Date: Tue Jan 12 15:59:15 2021 +0000 rxrpc: Call state should be read with READ_ONCE() under some circumstances [ Upstream commit a95d25dd7b94a5ba18246da09b4218f132fed60e ] The call state may be changed at any time by the data-ready routine in response to received packets, so if the call state is to be read and acted upon several times in a function, READ_ONCE() must be used unless the call state lock is held. As it happens, we used READ_ONCE() to read the state a few lines above the unmarked read in rxrpc_input_data(), so use that value rather than re-reading it. Fixes: a158bdd3247b ("rxrpc: Fix call timeouts") Signed-off-by: Baptiste Lepers Signed-off-by: David Howells Link: https://lore.kernel.org/r/161046715522.2450566.488819910256264150.stgit@warthog.procyon.org.uk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1e5a4c74b555e9b41236f406e2a43b0534af029c Author: Petr Machata Date: Mon Jan 11 18:07:07 2021 +0100 net: dcb: Accept RTM_GETDCB messages carrying set-like DCB commands [ Upstream commit df85bc140a4d6cbaa78d8e9c35154e1a2f0622c7 ] In commit 826f328e2b7e ("net: dcb: Validate netlink message in DCB handler"), Linux started rejecting RTM_GETDCB netlink messages if they contained a set-like DCB_CMD_ command. The reason was that privileges were only verified for RTM_SETDCB messages, but the value that determined the action to be taken is the command, not the message type. And validation of message type against the DCB command was the obvious missing piece. Unfortunately it turns out that mlnx_qos, a somewhat widely deployed tool for configuration of DCB, accesses the DCB set-like APIs through RTM_GETDCB. Therefore do not bounce the discrepancy between message type and command. Instead, in addition to validating privileges based on the actual message type, validate them also based on the expected message type. This closes the loophole of allowing DCB configuration on non-admin accounts, while maintaining backward compatibility. Fixes: 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and ixgbe driver") Fixes: 826f328e2b7e ("net: dcb: Validate netlink message in DCB handler") Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/a3edcfda0825f2aa2591801c5232f2bbf2d8a554.1610384801.git.me@pmachata.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit dbdca9d9b7ca909744928450edf563452301e65a Author: Petr Machata Date: Tue Dec 22 22:49:44 2020 +0100 net: dcb: Validate netlink message in DCB handler [ Upstream commit 826f328e2b7e8854dd42ea44e6519cd75018e7b1 ] DCB uses the same handler function for both RTM_GETDCB and RTM_SETDCB messages. dcb_doit() bounces RTM_SETDCB mesasges if the user does not have the CAP_NET_ADMIN capability. However, the operation to be performed is not decided from the DCB message type, but from the DCB command. Thus DCB_CMD_*_GET commands are used for reading DCB objects, the corresponding SET and DEL commands are used for manipulation. The assumption is that set-like commands will be sent via an RTM_SETDCB message, and get-like ones via RTM_GETDCB. However, this assumption is not enforced. It is therefore possible to manipulate DCB objects without CAP_NET_ADMIN capability by sending the corresponding command in an RTM_GETDCB message. That is a bug. Fix it by validating the type of the request message against the type used for the response. Fixes: 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and ixgbe driver") Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/a2a9b88418f3a58ef211b718f2970128ef9e3793.1608673640.git.me@pmachata.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 26413630f4f6495dc28ad57e6031f55912d1bcc7 Author: Willem de Bruijn Date: Sat Jan 9 17:18:34 2021 -0500 esp: avoid unneeded kmap_atomic call [ Upstream commit 9bd6b629c39e3fa9e14243a6d8820492be1a5b2e ] esp(6)_output_head uses skb_page_frag_refill to allocate a buffer for the esp trailer. It accesses the page with kmap_atomic to handle highmem. But skb_page_frag_refill can return compound pages, of which kmap_atomic only maps the first underlying page. skb_page_frag_refill does not return highmem, because flag __GFP_HIGHMEM is not set. ESP uses it in the same manner as TCP. That also does not call kmap_atomic, but directly uses page_address, in skb_copy_to_page_nocache. Do the same for ESP. This issue has become easier to trigger with recent kmap local debugging feature CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP. Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Willem de Bruijn Acked-by: Steffen Klassert Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3c64191cad985df173532c8e666eca31028afd81 Author: Andrey Zhizhikin Date: Fri Jan 8 09:58:39 2021 +0000 rndis_host: set proper input size for OID_GEN_PHYSICAL_MEDIUM request [ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ] MSFT ActiveSync implementation requires that the size of the response for incoming query is to be provided in the request input length. Failure to set the input size proper results in failed request transfer, where the ActiveSync counterpart reports the NDIS_STATUS_INVALID_LENGTH (0xC0010014L) error. Set the input size for OID_GEN_PHYSICAL_MEDIUM query to the expected size of the response in order for the ActiveSync to properly respond to the request. Fixes: 039ee17d1baa ("rndis_host: Add RNDIS physical medium checking into generic_rndis_bind()") Signed-off-by: Andrey Zhizhikin Link: https://lore.kernel.org/r/20210108095839.3335-1-andrey.zhizhikin@leica-geosystems.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit f999ca8c5fc5c7c87f837c13ba4998d7a2777855 Author: Stefan Chulski Date: Sun Jan 10 21:23:02 2021 +0200 net: mvpp2: Remove Pause and Asym_Pause support [ Upstream commit 6f83802a1a06e74eafbdbc9b52c05516d3083d02 ] Packet Processor hardware not connected to MAC flow control unit and cannot support TX flow control. This patch disable flow control support. Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Stefan Chulski Acked-by: Marcin Wojtas Link: https://lore.kernel.org/r/1610306582-16641-1-git-send-email-stefanc@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 82f72e41b797e94810b471a89c3d299ed90c9485 Author: Vadim Pasternak Date: Fri Jan 8 16:52:10 2021 +0200 mlxsw: core: Increase critical threshold for ASIC thermal zone [ Upstream commit b06ca3d5a43ca2dd806f7688a17e8e7e0619a80a ] Increase critical threshold for ASIC thermal zone from 110C to 140C according to the system hardware requirements. All the supported ASICs (Spectrum-1, Spectrum-2, Spectrum-3) could be still operational with ASIC temperature below 140C. With the old critical threshold value system can perform unjustified shutdown. All the systems equipped with the above ASICs implement thermal protection mechanism at firmware level and firmware could decide to perform system thermal shutdown in case the temperature is below 140C. So with the new threshold system will not meltdown, while thermal operating range will be aligned with hardware abilities. Fixes: 41e760841d26 ("mlxsw: core: Replace thermal temperature trips with defines") Fixes: a50c1e35650b ("mlxsw: core: Implement thermal zone") Signed-off-by: Vadim Pasternak Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d2bfbfcc550554ab72ac7bf6d27f376baa947844 Author: Vadim Pasternak Date: Fri Jan 8 16:52:09 2021 +0200 mlxsw: core: Add validation of transceiver temperature thresholds [ Upstream commit 57726ebe2733891c9f59105eff028735f73d05fb ] Validate thresholds to avoid a single failure due to some transceiver unreliability. Ignore the last readouts in case warning temperature is above alarm temperature, since it can cause unexpected thermal shutdown. Stay with the previous values and refresh threshold within the next iteration. This is a rare scenario, but it was observed at a customer site. Fixes: 6a79507cfe94 ("mlxsw: core: Extend thermal module with per QSFP module thermal zones") Signed-off-by: Vadim Pasternak Reviewed-by: Jiri Pirko Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 60b8b4e6310b7dfc551ba68e8639eeaf70a0b2dd Author: Hoang Le Date: Fri Jan 8 14:13:37 2021 +0700 tipc: fix NULL deref in tipc_link_xmit() [ Upstream commit b77413446408fdd256599daf00d5be72b5f3e7c6 ] The buffer list can have zero skb as following path: tipc_named_node_up()->tipc_node_xmit()->tipc_link_xmit(), so we need to check the list before casting an &sk_buff. Fault report: [] tipc: Bulk publication failure [] general protection fault, probably for non-canonical [#1] PREEMPT [...] [] KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf] [] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 5.10.0-rc4+ #2 [] Hardware name: Bochs ..., BIOS Bochs 01/01/2011 [] RIP: 0010:tipc_link_xmit+0xc1/0x2180 [] Code: 24 b8 00 00 00 00 4d 39 ec 4c 0f 44 e8 e8 d7 0a 10 f9 48 [...] [] RSP: 0018:ffffc90000006ea0 EFLAGS: 00010202 [] RAX: dffffc0000000000 RBX: ffff8880224da000 RCX: 1ffff11003d3cc0d [] RDX: 0000000000000019 RSI: ffffffff886007b9 RDI: 00000000000000c8 [] RBP: ffffc90000007018 R08: 0000000000000001 R09: fffff52000000ded [] R10: 0000000000000003 R11: fffff52000000dec R12: ffffc90000007148 [] R13: 0000000000000000 R14: 0000000000000000 R15: ffffc90000007018 [] FS: 0000000000000000(0000) GS:ffff888037400000(0000) knlGS:000[...] [] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [] CR2: 00007fffd2db5000 CR3: 000000002b08f000 CR4: 00000000000006f0 Fixes: af9b028e270fd ("tipc: make media xmit call outside node spinlock context") Acked-by: Jon Maloy Signed-off-by: Hoang Le Link: https://lore.kernel.org/r/20210108071337.3598-1-hoang.h.le@dektech.com.au Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit bbcb4746a6a3300e11a8a710b9bbb5c2a31258cc Author: Aya Levin Date: Thu Jan 7 15:50:18 2021 +0200 net: ipv6: Validate GSO SKB before finish IPv6 processing [ Upstream commit b210de4f8c97d57de051e805686248ec4c6cfc52 ] There are cases where GSO segment's length exceeds the egress MTU: - Forwarding of a TCP GRO skb, when DF flag is not set. - Forwarding of an skb that arrived on a virtualisation interface (virtio-net/vhost/tap) with TSO/GSO size set by other network stack. - Local GSO skb transmitted on an NETIF_F_TSO tunnel stacked over an interface with a smaller MTU. - Arriving GRO skb (or GSO skb in a virtualised environment) that is bridged to a NETIF_F_TSO tunnel stacked over an interface with an insufficient MTU. If so: - Consume the SKB and its segments. - Issue an ICMP packet with 'Packet Too Big' message containing the MTU, allowing the source host to reduce its Path MTU appropriately. Note: These cases are handled in the same manner in IPv4 output finish. This patch aligns the behavior of IPv6 and the one of IPv4. Fixes: 9e50849054a4 ("netfilter: ipv6: move POSTROUTING invocation before fragmentation") Signed-off-by: Aya Levin Reviewed-by: Tariq Toukan Link: https://lore.kernel.org/r/1610027418-30438-1-git-send-email-ayal@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 5a61d9f573dabc529c975b6642011b1de111b721 Author: Manish Chopra Date: Thu Jan 7 02:15:20 2021 -0800 netxen_nic: fix MSI/MSI-x interrupts [ Upstream commit a2bc221b972db91e4be1970e776e98f16aa87904 ] For all PCI functions on the netxen_nic adapter, interrupt mode (INTx or MSI) configuration is dependent on what has been configured by the PCI function zero in the shared interrupt register, as these adapters do not support mixed mode interrupts among the functions of a given adapter. Logic for setting MSI/MSI-x interrupt mode in the shared interrupt register based on PCI function id zero check is not appropriate for all family of netxen adapters, as for some of the netxen family adapters PCI function zero is not really meant to be probed/loaded in the host but rather just act as a management function on the device, which caused all the other PCI functions on the adapter to always use legacy interrupt (INTx) mode instead of choosing MSI/MSI-x interrupt mode. This patch replaces that check with port number so that for all type of adapters driver attempts for MSI/MSI-x interrupt modes. Fixes: b37eb210c076 ("netxen_nic: Avoid mixed mode interrupts") Signed-off-by: Manish Chopra Signed-off-by: Igor Russkikh Link: https://lore.kernel.org/r/20210107101520.6735-1-manishc@marvell.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 4b97ce051ffe21dcc0e09418bb3ab4ba018ee87b Author: Baptiste Lepers Date: Thu Jan 7 16:11:10 2021 +1100 udp: Prevent reuseport_select_sock from reading uninitialized socks [ Upstream commit fd2ddef043592e7de80af53f47fa46fd3573086e ] reuse->socks[] is modified concurrently by reuseport_add_sock. To prevent reading values that have not been fully initialized, only read the array up until the last known safe index instead of incorrectly re-reading the last index of the array. Fixes: acdcecc61285f ("udp: correct reuseport selection with connected sockets") Signed-off-by: Baptiste Lepers Acked-by: Willem de Bruijn Link: https://lore.kernel.org/r/20210107051110.12247-1-baptiste.lepers@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 24cd3317418955fd9489e4e7e9c2b643691b270b Author: Dongseok Yi Date: Fri Jan 8 11:28:38 2021 +0900 net: fix use-after-free when UDP GRO with shared fraglist [ Upstream commit 53475c5dd856212e91538a9501162e821cc1f791 ] skbs in fraglist could be shared by a BPF filter loaded at TC. If TC writes, it will call skb_ensure_writable -> pskb_expand_head to create a private linear section for the head_skb. And then call skb_clone_fraglist -> skb_get on each skb in the fraglist. skb_segment_list overwrites part of the skb linear section of each fragment itself. Even after skb_clone, the frag_skbs share their linear section with their clone in PF_PACKET. Both sk_receive_queue of PF_PACKET and PF_INET (or PF_INET6) can have a link for the same frag_skbs chain. If a new skb (not frags) is queued to one of the sk_receive_queue, multiple ptypes can see and release this. It causes use-after-free. [ 4443.426215] ------------[ cut here ]------------ [ 4443.426222] refcount_t: underflow; use-after-free. [ 4443.426291] WARNING: CPU: 7 PID: 28161 at lib/refcount.c:190 refcount_dec_and_test_checked+0xa4/0xc8 [ 4443.426726] pstate: 60400005 (nZCv daif +PAN -UAO) [ 4443.426732] pc : refcount_dec_and_test_checked+0xa4/0xc8 [ 4443.426737] lr : refcount_dec_and_test_checked+0xa0/0xc8 [ 4443.426808] Call trace: [ 4443.426813] refcount_dec_and_test_checked+0xa4/0xc8 [ 4443.426823] skb_release_data+0x144/0x264 [ 4443.426828] kfree_skb+0x58/0xc4 [ 4443.426832] skb_queue_purge+0x64/0x9c [ 4443.426844] packet_set_ring+0x5f0/0x820 [ 4443.426849] packet_setsockopt+0x5a4/0xcd0 [ 4443.426853] __sys_setsockopt+0x188/0x278 [ 4443.426858] __arm64_sys_setsockopt+0x28/0x38 [ 4443.426869] el0_svc_common+0xf0/0x1d0 [ 4443.426873] el0_svc_handler+0x74/0x98 [ 4443.426880] el0_svc+0x8/0xc Fixes: 3a1296a38d0c (net: Support GRO/GSO fraglist chaining.) Signed-off-by: Dongseok Yi Acked-by: Willem de Bruijn Acked-by: Daniel Borkmann Link: https://lore.kernel.org/r/1610072918-174177-1-git-send-email-dseok.yi@samsung.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 7d5c389742195481500834dd48bee0b25879ce36 Author: Stephan Gerhold Date: Wed Jan 6 11:07:55 2021 +0100 net: ipa: modem: add missing SET_NETDEV_DEV() for proper sysfs links [ Upstream commit afba9dc1f3a5390475006061c0bdc5ad4915878e ] At the moment it is quite hard to identify the network interface provided by IPA in userspace components: The network interface is created as virtual device, without any link to the IPA device. The interface name ("rmnet_ipa%d") is the only indication that the network interface belongs to IPA, but this is not very reliable. Add SET_NETDEV_DEV() to associate the network interface with the IPA parent device. This allows userspace services like ModemManager to properly identify that this network interface is provided by IPA and belongs to the modem. Cc: Alex Elder Fixes: a646d6ec9098 ("soc: qcom: ipa: modem and microcontroller") Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20210106100755.56800-1-stephan@gerhold.net Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 31ad07292553de318f682120e2a9a683d15a7e15 Author: Mircea Cirjaliu Date: Tue Jan 19 21:53:18 2021 +0100 bpf: Fix helper bpf_map_peek_elem_proto pointing to wrong callback commit 301a33d51880619d0c5a581b5a48d3a5248fa84b upstream. I assume this was obtained by copy/paste. Point it to bpf_map_peek_elem() instead of bpf_map_pop_elem(). In practice it may have been less likely hit when under JIT given shielded via 84430d4232c3 ("bpf, verifier: avoid retpoline for map push/pop/peek operation"). Fixes: f1a2e44a3aec ("bpf: add queue and stack maps") Signed-off-by: Mircea Cirjaliu Signed-off-by: Daniel Borkmann Cc: Mauricio Vasquez Link: https://lore.kernel.org/bpf/AM7PR02MB6082663DFDCCE8DA7A6DD6B1BBA30@AM7PR02MB6082.eurprd02.prod.outlook.com Signed-off-by: Greg Kroah-Hartman commit de661caaee07fab787c4fdb7062d100273c38d80 Author: Gilad Reti Date: Wed Jan 13 07:38:07 2021 +0200 bpf: Support PTR_TO_MEM{,_OR_NULL} register spilling commit 744ea4e3885eccb6d332a06fae9eb7420a622c0f upstream. Add support for pointer to mem register spilling, to allow the verifier to track pointers to valid memory addresses. Such pointers are returned for example by a successful call of the bpf_ringbuf_reserve helper. The patch was partially contributed by CyberArk Software, Inc. Fixes: 457f44363a88 ("bpf: Implement BPF ring buffer and verifier support for it") Suggested-by: Yonghong Song Signed-off-by: Gilad Reti Signed-off-by: Alexei Starovoitov Acked-by: KP Singh Link: https://lore.kernel.org/bpf/20210113053810.13518-1-gilad.reti@gmail.com Signed-off-by: Greg Kroah-Hartman commit 3ed29995c281762df98cccf86afbddbfb6a918ef Author: Stanislav Fomichev Date: Tue Jan 12 08:28:29 2021 -0800 bpf: Don't leak memory in bpf getsockopt when optlen == 0 commit 4be34f3d0731b38a1b24566b37fbb39500aaf3a2 upstream. optlen == 0 indicates that the kernel should ignore BPF buffer and use the original one from the user. We, however, forget to free the temporary buffer that we've allocated for BPF. Fixes: d8fe449a9c51 ("bpf: Don't return EINVAL from {get,set}sockopt when optlen > PAGE_SIZE") Reported-by: Martin KaFai Lau Signed-off-by: Stanislav Fomichev Signed-off-by: Daniel Borkmann Acked-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20210112162829.775079-1-sdf@google.com Signed-off-by: Greg Kroah-Hartman commit fdcaa4af5e70e2d984c9620a09e9dade067f2620 Author: J. Bruce Fields Date: Mon Jan 11 16:01:29 2021 -0500 nfsd4: readdirplus shouldn't return parent of export commit 51b2ee7d006a736a9126e8111d1f24e4fd0afaa6 upstream. If you export a subdirectory of a filesystem, a READDIRPLUS on the root of that export will return the filehandle of the parent with the ".." entry. The filehandle is optional, so let's just not return the filehandle for ".." if we're at the root of an export. Note that once the client learns one filehandle outside of the export, they can trivially access the rest of the export using further lookups. However, it is also not very difficult to guess filehandles outside of the export. So exporting a subdirectory of a filesystem should considered equivalent to providing access to the entire filesystem. To avoid confusion, we recommend only exporting entire filesystems. Reported-by: Youjipeng Signed-off-by: J. Bruce Fields Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever Signed-off-by: Greg Kroah-Hartman commit 90bd4a0cf5ddabf9249c6f92731fcba8c462a6ca Author: Tianjia Zhang Date: Tue Jan 19 00:13:19 2021 +0000 X.509: Fix crash caused by NULL pointer commit 7178a107f5ea7bdb1cc23073234f0ded0ef90ec7 upstream. On the following call path, `sig->pkey_algo` is not assigned in asymmetric_key_verify_signature(), which causes runtime crash in public_key_verify_signature(). keyctl_pkey_verify asymmetric_key_verify_signature verify_signature public_key_verify_signature This patch simply check this situation and fixes the crash caused by NULL pointer. Fixes: 215525639631 ("X.509: support OSCCA SM2-with-SM3 certificate verification") Reported-by: Tobias Markus Signed-off-by: Tianjia Zhang Signed-off-by: David Howells Reviewed-and-tested-by: Toke Høiland-Jørgensen Tested-by: João Fonseca Acked-by: Jarkko Sakkinen Cc: stable@vger.kernel.org # v5.10+ Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit 5f52a8a71b62418d62c736e5aa68aaba0a8da918 Author: Daniel Borkmann Date: Wed Jan 20 00:24:24 2021 +0100 bpf: Fix signed_{sub,add32}_overflows type handling commit bc895e8b2a64e502fbba72748d59618272052a8b upstream. Fix incorrect signed_{sub,add32}_overflows() input types (and a related buggy comment). It looks like this might have slipped in via copy/paste issue, also given prior to 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") the signature of signed_sub_overflows() had s64 a and s64 b as its input args whereas now they are truncated to s32. Thus restore proper types. Also, the case of signed_add32_overflows() is not consistent to signed_sub32_overflows(). Both have s32 as inputs, therefore align the former. Fixes: 3f50f132d840 ("bpf: Verifier, do explicit ALU32 bounds tracking") Reported-by: De4dCr0w Signed-off-by: Daniel Borkmann Reviewed-by: John Fastabend Acked-by: Alexei Starovoitov Signed-off-by: Greg Kroah-Hartman commit 99ea120383b19feb1737c787dc1c8b35ce630fc5 Author: Alex Deucher Date: Mon Jan 4 11:24:20 2021 -0500 drm/amdgpu/display: drop DCN support for aarch64 commit c241ed2f0ea549c18cff62a3708b43846b84dae3 upstream. From Ard: "Simply disabling -mgeneral-regs-only left and right is risky, given that the standard AArch64 ABI permits the use of FP/SIMD registers anywhere, and GCC is known to use SIMD registers for spilling, and may invent other uses of the FP/SIMD register file that have nothing to do with the floating point code in question. Note that putting kernel_neon_begin() and kernel_neon_end() around the code that does use FP is not sufficient here, the problem is in all the other code that may be emitted with references to SIMD registers in it. So the only way to do this properly is to put all floating point code in a separate compilation unit, and only compile that unit with -mgeneral-regs-only." Disable support until the code can be properly refactored to support this properly on aarch64. Acked-by: Will Deacon Reported-by: Ard Biesheuvel Signed-off-by: Alex Deucher [ardb: backport to v5.10 by reverting c38d444e44badc55 instead] Acked-by: Alex Deucher # v5.10 backport Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman commit 4473923b6674aeddb57c586939dd705cb499131b Author: Dexuan Cui Date: Sat Jan 16 14:31:36 2021 -0800 x86/hyperv: Initialize clockevents after LAPIC is initialized [ Upstream commit fff7b5e6ee63c5d20406a131b260c619cdd24fd1 ] With commit 4df4cb9e99f8, the Hyper-V direct-mode STIMER is actually initialized before LAPIC is initialized: see apic_intr_mode_init() x86_platform.apic_post_init() hyperv_init() hv_stimer_alloc() apic_bsp_setup() setup_local_APIC() setup_local_APIC() temporarily disables LAPIC, initializes it and re-eanble it. The direct-mode STIMER depends on LAPIC, and when it's registered, it can be programmed immediately and the timer can fire very soon: hv_stimer_init clockevents_config_and_register clockevents_register_device tick_check_new_device tick_setup_device tick_setup_periodic(), tick_setup_oneshot() clockevents_program_event When the timer fires in the hypervisor, if the LAPIC is in the disabled state, new versions of Hyper-V ignore the event and don't inject the timer interrupt into the VM, and hence the VM hangs when it boots. Note: when the VM starts/reboots, the LAPIC is pre-enabled by the firmware, so the window of LAPIC being temporarily disabled is pretty small, and the issue can only happen once out of 100~200 reboots for a 40-vCPU VM on one dev host, and on another host the issue doesn't reproduce after 2000 reboots. The issue is more noticeable for kdump/kexec, because the LAPIC is disabled by the first kernel, and stays disabled until the kdump/kexec kernel enables it. This is especially an issue to a Generation-2 VM (for which Hyper-V doesn't emulate the PIT timer) when CONFIG_HZ=1000 (rather than CONFIG_HZ=250) is used. Fix the issue by moving hv_stimer_alloc() to a later place where the LAPIC timer is initialized. Fixes: 4df4cb9e99f8 ("x86/hyperv: Initialize clockevents earlier in CPU onlining") Signed-off-by: Dexuan Cui Reviewed-by: Michael Kelley Link: https://lore.kernel.org/r/20210116223136.13892-1-decui@microsoft.com Signed-off-by: Wei Liu Signed-off-by: Sasha Levin commit 1200a5bc687191b80a654d5c74b9e6c0e9334a59 Author: Andrei Matei Date: Tue Nov 24 22:52:55 2020 -0500 bpf: Fix selftest compilation on clang 11 commit fb3558127cb62ba2dea9e3d0efa1bb1d7e5eee2a upstream. Before this patch, profiler.inc.h wouldn't compile with clang-11 (before the __builtin_preserve_enum_value LLVM builtin was introduced in https://reviews.llvm.org/D83242). Another test that uses this builtin (test_core_enumval) is conditionally skipped if the compiler is too old. In that spirit, this patch inhibits part of populate_cgroup_info(), which needs this CO-RE builtin. The selftests build again on clang-11. The affected test (the profiler test) doesn't pass on clang-11 because it's missing https://reviews.llvm.org/D85570, but at least the test suite as a whole compiles. The test's expected failure is already called out in the README. Signed-off-by: Andrei Matei Signed-off-by: Daniel Borkmann Tested-by: Florian Lehner Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20201125035255.17970-1-andreimatei1@gmail.com Cc: Lorenz Bauer Signed-off-by: Greg Kroah-Hartman commit 57dc19a9d60d859589cdba12353aa237bd06df38 Author: Greg Kroah-Hartman Date: Wed Jan 20 11:48:09 2021 +0100 Revert "kconfig: remove 'kvmconfig' and 'xenconfig' shorthands" This reverts commit 17a08680ab6a6c057949cb48c352933e09ea377a which is commit 9bba03d4473df0b707224d4d2067b62d1e1e2a77 upstream. As Pavel says at Link: https://lore.kernel.org/r/20210119182837.GA18123@duo.ucw.cz I don't believe this is suitable for stable. And he's right. It is "after" 5.10.0, but we want to keep these targets for all of the 5.10.y series. Reported-by: Pavel Machek Cc: Masahiro Yamada Cc: Sasha Levin Signed-off-by: Greg Kroah-Hartman