From 76185d876687b4db939ae121479eaae1b0726be5 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 3 Dec 2018 10:13:28 +0100 Subject: [PATCH] 4.19-stable patches added patches: lan743x-enable-driver-to-work-with-lan7431.patch lan743x-fix-return-value-for-lan743x_tx_napi_poll.patch net-dim-update-dim-start-sample-after-each-dim-iteration.patch net-don-t-keep-lonely-packets-forever-in-the-gro-hash.patch net-gemini-fix-copy-paste-error.patch net-phy-add-workaround-for-issue-where-phy-driver-doesn-t-bind-to-the-device.patch net-skb_scrub_packet-scrub-offload_fwd_mark.patch net-thunderx-set-tso_hdrs-pointer-to-null-in-nicvf_free_snd_queue.patch net-thunderx-set-xdp_prog-to-null-if-bpf_prog_add-fails.patch packet-copy-user-buffers-before-orphan-or-clone.patch rapidio-rionet-do-not-free-skb-before-reading-its-length.patch s390-qeth-fix-length-check-in-snmp-processing.patch tcp-defer-sack-compression-after-dupthresh.patch tipc-fix-lockdep-warning-during-node-delete.patch usbnet-ipheth-fix-potential-recvmsg-bug-and-recvmsg-bug-2.patch virtio-net-disable-guest-csum-during-xdp-set.patch virtio-net-fail-xdp-set-if-guest-csum-is-negotiated.patch --- ...x-enable-driver-to-work-with-lan7431.patch | 48 +++++ ...eturn-value-for-lan743x_tx_napi_poll.patch | 69 +++++++ ...tart-sample-after-each-dim-iteration.patch | 51 ++++++ ...nely-packets-forever-in-the-gro-hash.patch | 55 ++++++ .../net-gemini-fix-copy-paste-error.patch | 31 ++++ ...hy-driver-doesn-t-bind-to-the-device.patch | 51 ++++++ ..._scrub_packet-scrub-offload_fwd_mark.patch | 50 ++++++ ...nter-to-null-in-nicvf_free_snd_queue.patch | 97 ++++++++++ ...p_prog-to-null-if-bpf_prog_add-fails.patch | 56 ++++++ ...-user-buffers-before-orphan-or-clone.patch | 100 +++++++++++ ...t-free-skb-before-reading-its-length.patch | 33 ++++ ...-fix-length-check-in-snmp-processing.patch | 88 +++++++++ queue-4.19/series | 17 ++ ...fer-sack-compression-after-dupthresh.patch | 124 +++++++++++++ ...x-lockdep-warning-during-node-delete.patch | 115 ++++++++++++ ...ential-recvmsg-bug-and-recvmsg-bug-2.patch | 168 ++++++++++++++++++ ...et-disable-guest-csum-during-xdp-set.patch | 64 +++++++ ...-xdp-set-if-guest-csum-is-negotiated.patch | 39 ++++ 18 files changed, 1256 insertions(+) create mode 100644 queue-4.19/lan743x-enable-driver-to-work-with-lan7431.patch create mode 100644 queue-4.19/lan743x-fix-return-value-for-lan743x_tx_napi_poll.patch create mode 100644 queue-4.19/net-dim-update-dim-start-sample-after-each-dim-iteration.patch create mode 100644 queue-4.19/net-don-t-keep-lonely-packets-forever-in-the-gro-hash.patch create mode 100644 queue-4.19/net-gemini-fix-copy-paste-error.patch create mode 100644 queue-4.19/net-phy-add-workaround-for-issue-where-phy-driver-doesn-t-bind-to-the-device.patch create mode 100644 queue-4.19/net-skb_scrub_packet-scrub-offload_fwd_mark.patch create mode 100644 queue-4.19/net-thunderx-set-tso_hdrs-pointer-to-null-in-nicvf_free_snd_queue.patch create mode 100644 queue-4.19/net-thunderx-set-xdp_prog-to-null-if-bpf_prog_add-fails.patch create mode 100644 queue-4.19/packet-copy-user-buffers-before-orphan-or-clone.patch create mode 100644 queue-4.19/rapidio-rionet-do-not-free-skb-before-reading-its-length.patch create mode 100644 queue-4.19/s390-qeth-fix-length-check-in-snmp-processing.patch create mode 100644 queue-4.19/tcp-defer-sack-compression-after-dupthresh.patch create mode 100644 queue-4.19/tipc-fix-lockdep-warning-during-node-delete.patch create mode 100644 queue-4.19/usbnet-ipheth-fix-potential-recvmsg-bug-and-recvmsg-bug-2.patch create mode 100644 queue-4.19/virtio-net-disable-guest-csum-during-xdp-set.patch create mode 100644 queue-4.19/virtio-net-fail-xdp-set-if-guest-csum-is-negotiated.patch diff --git a/queue-4.19/lan743x-enable-driver-to-work-with-lan7431.patch b/queue-4.19/lan743x-enable-driver-to-work-with-lan7431.patch new file mode 100644 index 00000000000..1e193e60c2c --- /dev/null +++ b/queue-4.19/lan743x-enable-driver-to-work-with-lan7431.patch @@ -0,0 +1,48 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Bryan Whitehead +Date: Mon, 26 Nov 2018 12:27:10 -0500 +Subject: lan743x: Enable driver to work with LAN7431 + +From: Bryan Whitehead + +[ Upstream commit 4df5ce9bc03e47d05f400e64aa32a82ec4cef419 ] + +This driver was designed to work with both LAN7430 and LAN7431. +The only difference between the two is the LAN7431 has support +for external phy. + +This change adds LAN7431 to the list of recognized devices +supported by this driver. + +Updates for v2: + changed 'fixes' tag to match defined format + +fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") +Signed-off-by: Bryan Whitehead +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microchip/lan743x_main.c | 1 + + drivers/net/ethernet/microchip/lan743x_main.h | 1 + + 2 files changed, 2 insertions(+) + +--- a/drivers/net/ethernet/microchip/lan743x_main.c ++++ b/drivers/net/ethernet/microchip/lan743x_main.c +@@ -3020,6 +3020,7 @@ static const struct dev_pm_ops lan743x_p + + static const struct pci_device_id lan743x_pcidev_tbl[] = { + { PCI_DEVICE(PCI_VENDOR_ID_SMSC, PCI_DEVICE_ID_SMSC_LAN7430) }, ++ { PCI_DEVICE(PCI_VENDOR_ID_SMSC, PCI_DEVICE_ID_SMSC_LAN7431) }, + { 0, } + }; + +--- a/drivers/net/ethernet/microchip/lan743x_main.h ++++ b/drivers/net/ethernet/microchip/lan743x_main.h +@@ -548,6 +548,7 @@ struct lan743x_adapter; + /* SMSC acquired EFAR late 1990's, MCHP acquired SMSC 2012 */ + #define PCI_VENDOR_ID_SMSC PCI_VENDOR_ID_EFAR + #define PCI_DEVICE_ID_SMSC_LAN7430 (0x7430) ++#define PCI_DEVICE_ID_SMSC_LAN7431 (0x7431) + + #define PCI_CONFIG_LENGTH (0x1000) + diff --git a/queue-4.19/lan743x-fix-return-value-for-lan743x_tx_napi_poll.patch b/queue-4.19/lan743x-fix-return-value-for-lan743x_tx_napi_poll.patch new file mode 100644 index 00000000000..0ac9b6bf8a4 --- /dev/null +++ b/queue-4.19/lan743x-fix-return-value-for-lan743x_tx_napi_poll.patch @@ -0,0 +1,69 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Bryan Whitehead +Date: Mon, 26 Nov 2018 12:04:57 -0500 +Subject: lan743x: fix return value for lan743x_tx_napi_poll + +From: Bryan Whitehead + +[ Upstream commit cc5922054131f9abefdc0622ae64fc55e6b2671d ] + +The lan743x driver, when under heavy traffic load, has been noticed +to sometimes hang, or cause a kernel panic. + +Debugging reveals that the TX napi poll routine was returning +the wrong value, 'weight'. Most other drivers return 0. +And call napi_complete, instead of napi_complete_done. + +Additionally when creating the tx napi poll routine. +Changed netif_napi_add, to netif_tx_napi_add. + +Updates for v3: + changed 'fixes' tag to match defined format + +Updates for v2: +use napi_complete, instead of napi_complete_done in + lan743x_tx_napi_poll +use netif_tx_napi_add, instead of netif_napi_add for + registration of tx napi poll routine + +fixes: 23f0703c125b ("lan743x: Add main source files for new lan743x driver") +Signed-off-by: Bryan Whitehead +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/microchip/lan743x_main.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/drivers/net/ethernet/microchip/lan743x_main.c ++++ b/drivers/net/ethernet/microchip/lan743x_main.c +@@ -1675,7 +1675,7 @@ static int lan743x_tx_napi_poll(struct n + netif_wake_queue(adapter->netdev); + } + +- if (!napi_complete_done(napi, weight)) ++ if (!napi_complete(napi)) + goto done; + + /* enable isr */ +@@ -1684,7 +1684,7 @@ static int lan743x_tx_napi_poll(struct n + lan743x_csr_read(adapter, INT_STS); + + done: +- return weight; ++ return 0; + } + + static void lan743x_tx_ring_cleanup(struct lan743x_tx *tx) +@@ -1873,9 +1873,9 @@ static int lan743x_tx_open(struct lan743 + tx->vector_flags = lan743x_intr_get_vector_flags(adapter, + INT_BIT_DMA_TX_ + (tx->channel_number)); +- netif_napi_add(adapter->netdev, +- &tx->napi, lan743x_tx_napi_poll, +- tx->ring_size - 1); ++ netif_tx_napi_add(adapter->netdev, ++ &tx->napi, lan743x_tx_napi_poll, ++ tx->ring_size - 1); + napi_enable(&tx->napi); + + data = 0; diff --git a/queue-4.19/net-dim-update-dim-start-sample-after-each-dim-iteration.patch b/queue-4.19/net-dim-update-dim-start-sample-after-each-dim-iteration.patch new file mode 100644 index 00000000000..c4b73296d39 --- /dev/null +++ b/queue-4.19/net-dim-update-dim-start-sample-after-each-dim-iteration.patch @@ -0,0 +1,51 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Tal Gilboa +Date: Wed, 21 Nov 2018 16:28:23 +0200 +Subject: net/dim: Update DIM start sample after each DIM iteration + +From: Tal Gilboa + +[ Upstream commit 0211dda68a4f6531923a2f72d8e8959207f59fba ] + +On every iteration of net_dim, the algorithm may choose to +check for the system state by comparing current data sample +with previous data sample. After each of these comparison, +regardless of the action taken, the sample used as baseline +is needed to be updated. + +This patch fixes a bug that causes DIM to take wrong decisions, +due to never updating the baseline sample for comparison between +iterations. This way, DIM always compares current sample with +zeros. + +Although this is a functional fix, it also improves and stabilizes +performance as the algorithm works properly now. + +Performance: +Tested single UDP TX stream with pktgen: +samples/pktgen/pktgen_sample03_burst_single_flow.sh -i p4p2 -d 1.1.1.1 +-m 24:8a:07:88:26:8b -f 3 -b 128 + +ConnectX-5 100GbE packet rate improved from 15-19Mpps to 19-20Mpps. +Also, toggling between profiles is less frequent with the fix. + +Fixes: 8115b750dbcb ("net/dim: use struct net_dim_sample as arg to net_dim") +Signed-off-by: Tal Gilboa +Reviewed-by: Tariq Toukan +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/net_dim.h | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/include/linux/net_dim.h ++++ b/include/linux/net_dim.h +@@ -406,6 +406,8 @@ static inline void net_dim(struct net_di + } + /* fall through */ + case NET_DIM_START_MEASURE: ++ net_dim_sample(end_sample.event_ctr, end_sample.pkt_ctr, end_sample.byte_ctr, ++ &dim->start_sample); + dim->state = NET_DIM_MEASURE_IN_PROGRESS; + break; + case NET_DIM_APPLY_NEW_PROFILE: diff --git a/queue-4.19/net-don-t-keep-lonely-packets-forever-in-the-gro-hash.patch b/queue-4.19/net-don-t-keep-lonely-packets-forever-in-the-gro-hash.patch new file mode 100644 index 00000000000..57ca031b68a --- /dev/null +++ b/queue-4.19/net-don-t-keep-lonely-packets-forever-in-the-gro-hash.patch @@ -0,0 +1,55 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Paolo Abeni +Date: Wed, 21 Nov 2018 18:21:35 +0100 +Subject: net: don't keep lonely packets forever in the gro hash + +From: Paolo Abeni + +[ Upstream commit 605108acfe6233b72e2f803aa1cb59a2af3001ca ] + +Eric noted that with UDP GRO and NAPI timeout, we could keep a single +UDP packet inside the GRO hash forever, if the related NAPI instance +calls napi_gro_complete() at an higher frequency than the NAPI timeout. +Willem noted that even TCP packets could be trapped there, till the +next retransmission. +This patch tries to address the issue, flushing the old packets - +those with a NAPI_GRO_CB age before the current jiffy - before scheduling +the NAPI timeout. The rationale is that such a timeout should be +well below a jiffy and we are not flushing packets eligible for sane GRO. + +v1 -> v2: + - clarified the commit message and comment + +RFC -> v1: + - added 'Fixes tags', cleaned-up the wording. + +Reported-by: Eric Dumazet +Fixes: 3b47d30396ba ("net: gro: add a per device gro flush timer") +Signed-off-by: Paolo Abeni +Acked-by: Willem de Bruijn +Acked-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/core/dev.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/net/core/dev.c ++++ b/net/core/dev.c +@@ -5945,11 +5945,14 @@ bool napi_complete_done(struct napi_stru + if (work_done) + timeout = n->dev->gro_flush_timeout; + ++ /* When the NAPI instance uses a timeout and keeps postponing ++ * it, we need to bound somehow the time packets are kept in ++ * the GRO layer ++ */ ++ napi_gro_flush(n, !!timeout); + if (timeout) + hrtimer_start(&n->timer, ns_to_ktime(timeout), + HRTIMER_MODE_REL_PINNED); +- else +- napi_gro_flush(n, false); + } + if (unlikely(!list_empty(&n->poll_list))) { + /* If n->poll_list is not empty, we need to mask irqs */ diff --git a/queue-4.19/net-gemini-fix-copy-paste-error.patch b/queue-4.19/net-gemini-fix-copy-paste-error.patch new file mode 100644 index 00000000000..8e500a79926 --- /dev/null +++ b/queue-4.19/net-gemini-fix-copy-paste-error.patch @@ -0,0 +1,31 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Andreas Fiedler +Date: Sat, 24 Nov 2018 00:16:34 +0100 +Subject: net: gemini: Fix copy/paste error + +From: Andreas Fiedler + +[ Upstream commit 07093b76476903f820d83d56c3040e656fb4d9e3 ] + +The TX stats should be started with the tx_stats_syncp, +there seems to be a copy/paste error in the driver. + +Signed-off-by: Andreas Fiedler +Signed-off-by: Linus Walleij +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/cortina/gemini.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/ethernet/cortina/gemini.c ++++ b/drivers/net/ethernet/cortina/gemini.c +@@ -661,7 +661,7 @@ static void gmac_clean_txq(struct net_de + + u64_stats_update_begin(&port->tx_stats_syncp); + port->tx_frag_stats[nfrags]++; +- u64_stats_update_end(&port->ir_stats_syncp); ++ u64_stats_update_end(&port->tx_stats_syncp); + } + } + diff --git a/queue-4.19/net-phy-add-workaround-for-issue-where-phy-driver-doesn-t-bind-to-the-device.patch b/queue-4.19/net-phy-add-workaround-for-issue-where-phy-driver-doesn-t-bind-to-the-device.patch new file mode 100644 index 00000000000..40297e0344c --- /dev/null +++ b/queue-4.19/net-phy-add-workaround-for-issue-where-phy-driver-doesn-t-bind-to-the-device.patch @@ -0,0 +1,51 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Heiner Kallweit +Date: Fri, 23 Nov 2018 19:41:29 +0100 +Subject: net: phy: add workaround for issue where PHY driver doesn't bind to the device + +From: Heiner Kallweit + +[ Upstream commit c85ddecae6e5e82ca3ae6f20c63f1d865e2ff5ea ] + +After switching the r8169 driver to use phylib some user reported that +their network is broken. This was caused by the genphy PHY driver being +used instead of the dedicated PHY driver for the RTL8211B. Users +reported that loading the Realtek PHY driver module upfront fixes the +issue. See also this mail thread: +https://marc.info/?t=154279781800003&r=1&w=2 +The issue is quite weird and the root cause seems to be somewhere in +the base driver core. The patch works around the issue and may be +removed once the actual issue is fixed. + +The Fixes tag refers to the first reported occurrence of the issue. +The issue itself may have been existing much longer and it may affect +users of other network chips as well. Users typically will recognize +this issue only if their PHY stops working when being used with the +genphy driver. + +Fixes: f1e911d5d0df ("r8169: add basic phylib support") +Signed-off-by: Heiner Kallweit +Reviewed-by: Andrew Lunn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/phy/phy_device.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/drivers/net/phy/phy_device.c ++++ b/drivers/net/phy/phy_device.c +@@ -1930,6 +1930,14 @@ int phy_driver_register(struct phy_drive + new_driver->mdiodrv.driver.remove = phy_remove; + new_driver->mdiodrv.driver.owner = owner; + ++ /* The following works around an issue where the PHY driver doesn't bind ++ * to the device, resulting in the genphy driver being used instead of ++ * the dedicated driver. The root cause of the issue isn't known yet ++ * and seems to be in the base driver core. Once this is fixed we may ++ * remove this workaround. ++ */ ++ new_driver->mdiodrv.driver.probe_type = PROBE_FORCE_SYNCHRONOUS; ++ + retval = driver_register(&new_driver->mdiodrv.driver); + if (retval) { + pr_err("%s: Error %d in registering driver\n", diff --git a/queue-4.19/net-skb_scrub_packet-scrub-offload_fwd_mark.patch b/queue-4.19/net-skb_scrub_packet-scrub-offload_fwd_mark.patch new file mode 100644 index 00000000000..d6e9691b84d --- /dev/null +++ b/queue-4.19/net-skb_scrub_packet-scrub-offload_fwd_mark.patch @@ -0,0 +1,50 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Petr Machata +Date: Tue, 20 Nov 2018 11:39:56 +0000 +Subject: net: skb_scrub_packet(): Scrub offload_fwd_mark + +From: Petr Machata + +[ Upstream commit b5dd186d10ba59e6b5ba60e42b3b083df56df6f3 ] + +When a packet is trapped and the corresponding SKB marked as +already-forwarded, it retains this marking even after it is forwarded +across veth links into another bridge. There, since it ingresses the +bridge over veth, which doesn't have offload_fwd_mark, it triggers a +warning in nbp_switchdev_frame_mark(). + +Then nbp_switchdev_allowed_egress() decides not to allow egress from +this bridge through another veth, because the SKB is already marked, and +the mark (of 0) of course matches. Thus the packet is incorrectly +blocked. + +Solve by resetting offload_fwd_mark() in skb_scrub_packet(). That +function is called from tunnels and also from veth, and thus catches the +cases where traffic is forwarded between bridges and transformed in a +way that invalidates the marking. + +Fixes: 6bc506b4fb06 ("bridge: switchdev: Add forward mark support for stacked devices") +Fixes: abf4bb6b63d0 ("skbuff: Add the offload_mr_fwd_mark field") +Signed-off-by: Petr Machata +Suggested-by: Ido Schimmel +Acked-by: Jiri Pirko +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/core/skbuff.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/net/core/skbuff.c ++++ b/net/core/skbuff.c +@@ -4912,6 +4912,11 @@ void skb_scrub_packet(struct sk_buff *sk + nf_reset(skb); + nf_reset_trace(skb); + ++#ifdef CONFIG_NET_SWITCHDEV ++ skb->offload_fwd_mark = 0; ++ skb->offload_mr_fwd_mark = 0; ++#endif ++ + if (!xnet) + return; + diff --git a/queue-4.19/net-thunderx-set-tso_hdrs-pointer-to-null-in-nicvf_free_snd_queue.patch b/queue-4.19/net-thunderx-set-tso_hdrs-pointer-to-null-in-nicvf_free_snd_queue.patch new file mode 100644 index 00000000000..438a7aea8d4 --- /dev/null +++ b/queue-4.19/net-thunderx-set-tso_hdrs-pointer-to-null-in-nicvf_free_snd_queue.patch @@ -0,0 +1,97 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Lorenzo Bianconi +Date: Fri, 23 Nov 2018 18:28:01 +0100 +Subject: net: thunderx: set tso_hdrs pointer to NULL in nicvf_free_snd_queue + +From: Lorenzo Bianconi + +[ Upstream commit ef2a7cf1d8831535b8991459567b385661eb4a36 ] + +Reset snd_queue tso_hdrs pointer to NULL in nicvf_free_snd_queue routine +since it is used to check if tso dma descriptor queue has been previously +allocated. The issue can be triggered with the following reproducer: + +$ip link set dev enP2p1s0v0 xdpdrv obj xdp_dummy.o +$ip link set dev enP2p1s0v0 xdpdrv off + +[ 341.467649] WARNING: CPU: 74 PID: 2158 at mm/vmalloc.c:1511 __vunmap+0x98/0xe0 +[ 341.515010] Hardware name: GIGABYTE H270-T70/MT70-HD0, BIOS T49 02/02/2018 +[ 341.521874] pstate: 60400005 (nZCv daif +PAN -UAO) +[ 341.526654] pc : __vunmap+0x98/0xe0 +[ 341.530132] lr : __vunmap+0x98/0xe0 +[ 341.533609] sp : ffff00001c5db860 +[ 341.536913] x29: ffff00001c5db860 x28: 0000000000020000 +[ 341.542214] x27: ffff810feb5090b0 x26: ffff000017e57000 +[ 341.547515] x25: 0000000000000000 x24: 00000000fbd00000 +[ 341.552816] x23: 0000000000000000 x22: ffff810feb5090b0 +[ 341.558117] x21: 0000000000000000 x20: 0000000000000000 +[ 341.563418] x19: ffff000017e57000 x18: 0000000000000000 +[ 341.568719] x17: 0000000000000000 x16: 0000000000000000 +[ 341.574020] x15: 0000000000000010 x14: ffffffffffffffff +[ 341.579321] x13: ffff00008985eb27 x12: ffff00000985eb2f +[ 341.584622] x11: ffff0000096b3000 x10: ffff00001c5db510 +[ 341.589923] x9 : 00000000ffffffd0 x8 : ffff0000086868e8 +[ 341.595224] x7 : 3430303030303030 x6 : 00000000000006ef +[ 341.600525] x5 : 00000000003fffff x4 : 0000000000000000 +[ 341.605825] x3 : 0000000000000000 x2 : ffffffffffffffff +[ 341.611126] x1 : ffff0000096b3728 x0 : 0000000000000038 +[ 341.616428] Call trace: +[ 341.618866] __vunmap+0x98/0xe0 +[ 341.621997] vunmap+0x3c/0x50 +[ 341.624961] arch_dma_free+0x68/0xa0 +[ 341.628534] dma_direct_free+0x50/0x80 +[ 341.632285] nicvf_free_resources+0x160/0x2d8 [nicvf] +[ 341.637327] nicvf_config_data_transfer+0x174/0x5e8 [nicvf] +[ 341.642890] nicvf_stop+0x298/0x340 [nicvf] +[ 341.647066] __dev_close_many+0x9c/0x108 +[ 341.650977] dev_close_many+0xa4/0x158 +[ 341.654720] rollback_registered_many+0x140/0x530 +[ 341.659414] rollback_registered+0x54/0x80 +[ 341.663499] unregister_netdevice_queue+0x9c/0xe8 +[ 341.668192] unregister_netdev+0x28/0x38 +[ 341.672106] nicvf_remove+0xa4/0xa8 [nicvf] +[ 341.676280] nicvf_shutdown+0x20/0x30 [nicvf] +[ 341.680630] pci_device_shutdown+0x44/0x88 +[ 341.684720] device_shutdown+0x144/0x250 +[ 341.688640] kernel_restart_prepare+0x44/0x50 +[ 341.692986] kernel_restart+0x20/0x68 +[ 341.696638] __se_sys_reboot+0x210/0x238 +[ 341.700550] __arm64_sys_reboot+0x24/0x30 +[ 341.704555] el0_svc_handler+0x94/0x110 +[ 341.708382] el0_svc+0x8/0xc +[ 341.711252] ---[ end trace 3f4019c8439959c9 ]--- +[ 341.715874] page:ffff7e0003ef4000 count:0 mapcount:0 mapping:0000000000000000 index:0x4 +[ 341.723872] flags: 0x1fffe000000000() +[ 341.727527] raw: 001fffe000000000 ffff7e0003f1a008 ffff7e0003ef4048 0000000000000000 +[ 341.735263] raw: 0000000000000004 0000000000000000 00000000ffffffff 0000000000000000 +[ 341.742994] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) + +where xdp_dummy.c is a simple bpf program that forwards the incoming +frames to the network stack (available here: +https://github.com/altoor/xdp_walkthrough_examples/blob/master/sample_1/xdp_dummy.c) + +Fixes: 05c773f52b96 ("net: thunderx: Add basic XDP support") +Fixes: 4863dea3fab0 ("net: Adding support for Cavium ThunderX network controller") +Signed-off-by: Lorenzo Bianconi +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/cavium/thunder/nicvf_queues.c ++++ b/drivers/net/ethernet/cavium/thunder/nicvf_queues.c +@@ -585,10 +585,12 @@ static void nicvf_free_snd_queue(struct + if (!sq->dmem.base) + return; + +- if (sq->tso_hdrs) ++ if (sq->tso_hdrs) { + dma_free_coherent(&nic->pdev->dev, + sq->dmem.q_len * TSO_HEADER_SIZE, + sq->tso_hdrs, sq->tso_hdrs_phys); ++ sq->tso_hdrs = NULL; ++ } + + /* Free pending skbs in the queue */ + smp_rmb(); diff --git a/queue-4.19/net-thunderx-set-xdp_prog-to-null-if-bpf_prog_add-fails.patch b/queue-4.19/net-thunderx-set-xdp_prog-to-null-if-bpf_prog_add-fails.patch new file mode 100644 index 00000000000..96798d2d6d6 --- /dev/null +++ b/queue-4.19/net-thunderx-set-xdp_prog-to-null-if-bpf_prog_add-fails.patch @@ -0,0 +1,56 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Lorenzo Bianconi +Date: Wed, 21 Nov 2018 16:32:10 +0100 +Subject: net: thunderx: set xdp_prog to NULL if bpf_prog_add fails + +From: Lorenzo Bianconi + +[ Upstream commit 6d0f60b0f8588fd4380ea5df9601e12fddd55ce2 ] + +Set xdp_prog pointer to NULL if bpf_prog_add fails since that routine +reports the error code instead of NULL in case of failure and xdp_prog +pointer value is used in the driver to verify if XDP is currently +enabled. +Moreover report the error code to userspace if nicvf_xdp_setup fails + +Fixes: 05c773f52b96 ("net: thunderx: Add basic XDP support") +Signed-off-by: Lorenzo Bianconi +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/ethernet/cavium/thunder/nicvf_main.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c ++++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c +@@ -1784,6 +1784,7 @@ static int nicvf_xdp_setup(struct nicvf + bool if_up = netif_running(nic->netdev); + struct bpf_prog *old_prog; + bool bpf_attached = false; ++ int ret = 0; + + /* For now just support only the usual MTU sized frames */ + if (prog && (dev->mtu > 1500)) { +@@ -1817,8 +1818,12 @@ static int nicvf_xdp_setup(struct nicvf + if (nic->xdp_prog) { + /* Attach BPF program */ + nic->xdp_prog = bpf_prog_add(nic->xdp_prog, nic->rx_queues - 1); +- if (!IS_ERR(nic->xdp_prog)) ++ if (!IS_ERR(nic->xdp_prog)) { + bpf_attached = true; ++ } else { ++ ret = PTR_ERR(nic->xdp_prog); ++ nic->xdp_prog = NULL; ++ } + } + + /* Calculate Tx queues needed for XDP and network stack */ +@@ -1830,7 +1835,7 @@ static int nicvf_xdp_setup(struct nicvf + netif_trans_update(nic->netdev); + } + +- return 0; ++ return ret; + } + + static int nicvf_xdp(struct net_device *netdev, struct netdev_bpf *xdp) diff --git a/queue-4.19/packet-copy-user-buffers-before-orphan-or-clone.patch b/queue-4.19/packet-copy-user-buffers-before-orphan-or-clone.patch new file mode 100644 index 00000000000..340f0b00cf9 --- /dev/null +++ b/queue-4.19/packet-copy-user-buffers-before-orphan-or-clone.patch @@ -0,0 +1,100 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Willem de Bruijn +Date: Tue, 20 Nov 2018 13:00:18 -0500 +Subject: packet: copy user buffers before orphan or clone + +From: Willem de Bruijn + +[ Upstream commit 5cd8d46ea1562be80063f53c7c6a5f40224de623 ] + +tpacket_snd sends packets with user pages linked into skb frags. It +notifies that pages can be reused when the skb is released by setting +skb->destructor to tpacket_destruct_skb. + +This can cause data corruption if the skb is orphaned (e.g., on +transmit through veth) or cloned (e.g., on mirror to another psock). + +Create a kernel-private copy of data in these cases, same as tun/tap +zerocopy transmission. Reuse that infrastructure: mark the skb as +SKBTX_ZEROCOPY_FRAG, which will trigger copy in skb_orphan_frags(_rx). + +Unlike other zerocopy packets, do not set shinfo destructor_arg to +struct ubuf_info. tpacket_destruct_skb already uses that ptr to notify +when the original skb is released and a timestamp is recorded. Do not +change this timestamp behavior. The ubuf_info->callback is not needed +anyway, as no zerocopy notification is expected. + +Mark destructor_arg as not-a-uarg by setting the lower bit to 1. The +resulting value is not a valid ubuf_info pointer, nor a valid +tpacket_snd frame address. Add skb_zcopy_.._nouarg helpers for this. + +The fix relies on features introduced in commit 52267790ef52 ("sock: +add MSG_ZEROCOPY"), so can be backported as is only to 4.14. + +Tested with from `./in_netns.sh ./txring_overwrite` from +http://github.com/wdebruij/kerneltools/tests + +Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") +Reported-by: Anand H. Krishnan +Signed-off-by: Willem de Bruijn +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/skbuff.h | 18 +++++++++++++++++- + net/packet/af_packet.c | 4 ++-- + 2 files changed, 19 insertions(+), 3 deletions(-) + +--- a/include/linux/skbuff.h ++++ b/include/linux/skbuff.h +@@ -1311,6 +1311,22 @@ static inline void skb_zcopy_set(struct + } + } + ++static inline void skb_zcopy_set_nouarg(struct sk_buff *skb, void *val) ++{ ++ skb_shinfo(skb)->destructor_arg = (void *)((uintptr_t) val | 0x1UL); ++ skb_shinfo(skb)->tx_flags |= SKBTX_ZEROCOPY_FRAG; ++} ++ ++static inline bool skb_zcopy_is_nouarg(struct sk_buff *skb) ++{ ++ return (uintptr_t) skb_shinfo(skb)->destructor_arg & 0x1UL; ++} ++ ++static inline void *skb_zcopy_get_nouarg(struct sk_buff *skb) ++{ ++ return (void *)((uintptr_t) skb_shinfo(skb)->destructor_arg & ~0x1UL); ++} ++ + /* Release a reference on a zerocopy structure */ + static inline void skb_zcopy_clear(struct sk_buff *skb, bool zerocopy) + { +@@ -1320,7 +1336,7 @@ static inline void skb_zcopy_clear(struc + if (uarg->callback == sock_zerocopy_callback) { + uarg->zerocopy = uarg->zerocopy && zerocopy; + sock_zerocopy_put(uarg); +- } else { ++ } else if (!skb_zcopy_is_nouarg(skb)) { + uarg->callback(uarg, zerocopy); + } + +--- a/net/packet/af_packet.c ++++ b/net/packet/af_packet.c +@@ -2394,7 +2394,7 @@ static void tpacket_destruct_skb(struct + void *ph; + __u32 ts; + +- ph = skb_shinfo(skb)->destructor_arg; ++ ph = skb_zcopy_get_nouarg(skb); + packet_dec_pending(&po->tx_ring); + + ts = __packet_set_timestamp(po, ph, skb); +@@ -2461,7 +2461,7 @@ static int tpacket_fill_skb(struct packe + skb->mark = po->sk.sk_mark; + skb->tstamp = sockc->transmit_time; + sock_tx_timestamp(&po->sk, sockc->tsflags, &skb_shinfo(skb)->tx_flags); +- skb_shinfo(skb)->destructor_arg = ph.raw; ++ skb_zcopy_set_nouarg(skb, ph.raw); + + skb_reserve(skb, hlen); + skb_reset_network_header(skb); diff --git a/queue-4.19/rapidio-rionet-do-not-free-skb-before-reading-its-length.patch b/queue-4.19/rapidio-rionet-do-not-free-skb-before-reading-its-length.patch new file mode 100644 index 00000000000..a27d048f526 --- /dev/null +++ b/queue-4.19/rapidio-rionet-do-not-free-skb-before-reading-its-length.patch @@ -0,0 +1,33 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Pan Bian +Date: Wed, 28 Nov 2018 14:53:19 +0800 +Subject: rapidio/rionet: do not free skb before reading its length + +From: Pan Bian + +[ Upstream commit cfc435198f53a6fa1f656d98466b24967ff457d0 ] + +skb is freed via dev_kfree_skb_any, however, skb->len is read then. This +may result in a use-after-free bug. + +Fixes: e6161d64263 ("rapidio/rionet: rework driver initialization and removal") +Signed-off-by: Pan Bian +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/rionet.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/net/rionet.c ++++ b/drivers/net/rionet.c +@@ -216,9 +216,9 @@ static int rionet_start_xmit(struct sk_b + * it just report sending a packet to the target + * (without actual packet transfer). + */ +- dev_kfree_skb_any(skb); + ndev->stats.tx_packets++; + ndev->stats.tx_bytes += skb->len; ++ dev_kfree_skb_any(skb); + } + } + diff --git a/queue-4.19/s390-qeth-fix-length-check-in-snmp-processing.patch b/queue-4.19/s390-qeth-fix-length-check-in-snmp-processing.patch new file mode 100644 index 00000000000..1b4c07dcb06 --- /dev/null +++ b/queue-4.19/s390-qeth-fix-length-check-in-snmp-processing.patch @@ -0,0 +1,88 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Julian Wiedmann +Date: Wed, 28 Nov 2018 16:20:50 +0100 +Subject: s390/qeth: fix length check in SNMP processing + +From: Julian Wiedmann + +[ Upstream commit 9a764c1e59684c0358e16ccaafd870629f2cfe67 ] + +The response for a SNMP request can consist of multiple parts, which +the cmd callback stages into a kernel buffer until all parts have been +received. If the callback detects that the staging buffer provides +insufficient space, it bails out with error. +This processing is buggy for the first part of the response - while it +initially checks for a length of 'data_len', it later copies an +additional amount of 'offsetof(struct qeth_snmp_cmd, data)' bytes. + +Fix the calculation of 'data_len' for the first part of the response. +This also nicely cleans up the memcpy code. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Julian Wiedmann +Reviewed-by: Ursula Braun +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/s390/net/qeth_core_main.c | 27 ++++++++++++--------------- + 1 file changed, 12 insertions(+), 15 deletions(-) + +--- a/drivers/s390/net/qeth_core_main.c ++++ b/drivers/s390/net/qeth_core_main.c +@@ -4524,8 +4524,8 @@ static int qeth_snmp_command_cb(struct q + { + struct qeth_ipa_cmd *cmd; + struct qeth_arp_query_info *qinfo; +- struct qeth_snmp_cmd *snmp; + unsigned char *data; ++ void *snmp_data; + __u16 data_len; + + QETH_CARD_TEXT(card, 3, "snpcmdcb"); +@@ -4533,7 +4533,6 @@ static int qeth_snmp_command_cb(struct q + cmd = (struct qeth_ipa_cmd *) sdata; + data = (unsigned char *)((char *)cmd - reply->offset); + qinfo = (struct qeth_arp_query_info *) reply->param; +- snmp = &cmd->data.setadapterparms.data.snmp; + + if (cmd->hdr.return_code) { + QETH_CARD_TEXT_(card, 4, "scer1%x", cmd->hdr.return_code); +@@ -4546,10 +4545,15 @@ static int qeth_snmp_command_cb(struct q + return 0; + } + data_len = *((__u16 *)QETH_IPA_PDU_LEN_PDU1(data)); +- if (cmd->data.setadapterparms.hdr.seq_no == 1) +- data_len -= (__u16)((char *)&snmp->data - (char *)cmd); +- else +- data_len -= (__u16)((char *)&snmp->request - (char *)cmd); ++ if (cmd->data.setadapterparms.hdr.seq_no == 1) { ++ snmp_data = &cmd->data.setadapterparms.data.snmp; ++ data_len -= offsetof(struct qeth_ipa_cmd, ++ data.setadapterparms.data.snmp); ++ } else { ++ snmp_data = &cmd->data.setadapterparms.data.snmp.request; ++ data_len -= offsetof(struct qeth_ipa_cmd, ++ data.setadapterparms.data.snmp.request); ++ } + + /* check if there is enough room in userspace */ + if ((qinfo->udata_len - qinfo->udata_offset) < data_len) { +@@ -4562,16 +4566,9 @@ static int qeth_snmp_command_cb(struct q + QETH_CARD_TEXT_(card, 4, "sseqn%i", + cmd->data.setadapterparms.hdr.seq_no); + /*copy entries to user buffer*/ +- if (cmd->data.setadapterparms.hdr.seq_no == 1) { +- memcpy(qinfo->udata + qinfo->udata_offset, +- (char *)snmp, +- data_len + offsetof(struct qeth_snmp_cmd, data)); +- qinfo->udata_offset += offsetof(struct qeth_snmp_cmd, data); +- } else { +- memcpy(qinfo->udata + qinfo->udata_offset, +- (char *)&snmp->request, data_len); +- } ++ memcpy(qinfo->udata + qinfo->udata_offset, snmp_data, data_len); + qinfo->udata_offset += data_len; ++ + /* check if all replies received ... */ + QETH_CARD_TEXT_(card, 4, "srtot%i", + cmd->data.setadapterparms.hdr.used_total); diff --git a/queue-4.19/series b/queue-4.19/series index 181684e82e8..30b4cbf2269 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -7,3 +7,20 @@ mm-khugepaged-collapse_shmem-remember-to-clear-holes.patch mm-khugepaged-minor-reorderings-in-collapse_shmem.patch mm-khugepaged-collapse_shmem-without-freezing-new_pa.patch mm-khugepaged-collapse_shmem-do-not-crash-on-compoun.patch +lan743x-enable-driver-to-work-with-lan7431.patch +lan743x-fix-return-value-for-lan743x_tx_napi_poll.patch +net-don-t-keep-lonely-packets-forever-in-the-gro-hash.patch +net-gemini-fix-copy-paste-error.patch +net-thunderx-set-tso_hdrs-pointer-to-null-in-nicvf_free_snd_queue.patch +packet-copy-user-buffers-before-orphan-or-clone.patch +rapidio-rionet-do-not-free-skb-before-reading-its-length.patch +s390-qeth-fix-length-check-in-snmp-processing.patch +usbnet-ipheth-fix-potential-recvmsg-bug-and-recvmsg-bug-2.patch +net-thunderx-set-xdp_prog-to-null-if-bpf_prog_add-fails.patch +net-skb_scrub_packet-scrub-offload_fwd_mark.patch +virtio-net-disable-guest-csum-during-xdp-set.patch +virtio-net-fail-xdp-set-if-guest-csum-is-negotiated.patch +net-dim-update-dim-start-sample-after-each-dim-iteration.patch +tcp-defer-sack-compression-after-dupthresh.patch +net-phy-add-workaround-for-issue-where-phy-driver-doesn-t-bind-to-the-device.patch +tipc-fix-lockdep-warning-during-node-delete.patch diff --git a/queue-4.19/tcp-defer-sack-compression-after-dupthresh.patch b/queue-4.19/tcp-defer-sack-compression-after-dupthresh.patch new file mode 100644 index 00000000000..9732670b714 --- /dev/null +++ b/queue-4.19/tcp-defer-sack-compression-after-dupthresh.patch @@ -0,0 +1,124 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Eric Dumazet +Date: Tue, 20 Nov 2018 05:53:59 -0800 +Subject: tcp: defer SACK compression after DupThresh + +From: Eric Dumazet + +[ Upstream commit 86de5921a3d5dd246df661e09bdd0a6131b39ae3 ] + +Jean-Louis reported a TCP regression and bisected to recent SACK +compression. + +After a loss episode (receiver not able to keep up and dropping +packets because its backlog is full), linux TCP stack is sending +a single SACK (DUPACK). + +Sender waits a full RTO timer before recovering losses. + +While RFC 6675 says in section 5, "Algorithm Details", + + (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true -- + indicating at least three segments have arrived above the current + cumulative acknowledgment point, which is taken to indicate loss + -- go to step (4). +... + (4) Invoke fast retransmit and enter loss recovery as follows: + +there are old TCP stacks not implementing this strategy, and +still counting the dupacks before starting fast retransmit. + +While these stacks probably perform poorly when receivers implement +LRO/GRO, we should be a little more gentle to them. + +This patch makes sure we do not enable SACK compression unless +3 dupacks have been sent since last rcv_nxt update. + +Ideally we should even rearm the timer to send one or two +more DUPACK if no more packets are coming, but that will +be work aiming for linux-4.21. + +Many thanks to Jean-Louis for bisecting the issue, providing +packet captures and testing this patch. + +Fixes: 5d9f4262b7ea ("tcp: add SACK compression") +Reported-by: Jean-Louis Dupond +Tested-by: Jean-Louis Dupond +Signed-off-by: Eric Dumazet +Acked-by: Neal Cardwell +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + include/linux/tcp.h | 1 + + net/ipv4/tcp_input.c | 14 ++++++++++++-- + net/ipv4/tcp_output.c | 6 +++--- + net/ipv4/tcp_timer.c | 2 +- + 4 files changed, 17 insertions(+), 6 deletions(-) + +--- a/include/linux/tcp.h ++++ b/include/linux/tcp.h +@@ -196,6 +196,7 @@ struct tcp_sock { + u32 rcv_tstamp; /* timestamp of last received ACK (for keepalives) */ + u32 lsndtime; /* timestamp of last sent data packet (for restart window) */ + u32 last_oow_ack_time; /* timestamp of last out-of-window ACK */ ++ u32 compressed_ack_rcv_nxt; + + u32 tsoffset; /* timestamp offset */ + +--- a/net/ipv4/tcp_input.c ++++ b/net/ipv4/tcp_input.c +@@ -4276,7 +4276,7 @@ static void tcp_sack_new_ofo_skb(struct + * If the sack array is full, forget about the last one. + */ + if (this_sack >= TCP_NUM_SACKS) { +- if (tp->compressed_ack) ++ if (tp->compressed_ack > TCP_FASTRETRANS_THRESH) + tcp_send_ack(sk); + this_sack--; + tp->rx_opt.num_sacks--; +@@ -5196,7 +5196,17 @@ send_now: + if (!tcp_is_sack(tp) || + tp->compressed_ack >= sock_net(sk)->ipv4.sysctl_tcp_comp_sack_nr) + goto send_now; +- tp->compressed_ack++; ++ ++ if (tp->compressed_ack_rcv_nxt != tp->rcv_nxt) { ++ tp->compressed_ack_rcv_nxt = tp->rcv_nxt; ++ if (tp->compressed_ack > TCP_FASTRETRANS_THRESH) ++ NET_ADD_STATS(sock_net(sk), LINUX_MIB_TCPACKCOMPRESSED, ++ tp->compressed_ack - TCP_FASTRETRANS_THRESH); ++ tp->compressed_ack = 0; ++ } ++ ++ if (++tp->compressed_ack <= TCP_FASTRETRANS_THRESH) ++ goto send_now; + + if (hrtimer_is_queued(&tp->compressed_ack_timer)) + return; +--- a/net/ipv4/tcp_output.c ++++ b/net/ipv4/tcp_output.c +@@ -165,10 +165,10 @@ static inline void tcp_event_ack_sent(st + { + struct tcp_sock *tp = tcp_sk(sk); + +- if (unlikely(tp->compressed_ack)) { ++ if (unlikely(tp->compressed_ack > TCP_FASTRETRANS_THRESH)) { + NET_ADD_STATS(sock_net(sk), LINUX_MIB_TCPACKCOMPRESSED, +- tp->compressed_ack); +- tp->compressed_ack = 0; ++ tp->compressed_ack - TCP_FASTRETRANS_THRESH); ++ tp->compressed_ack = TCP_FASTRETRANS_THRESH; + if (hrtimer_try_to_cancel(&tp->compressed_ack_timer) == 1) + __sock_put(sk); + } +--- a/net/ipv4/tcp_timer.c ++++ b/net/ipv4/tcp_timer.c +@@ -740,7 +740,7 @@ static enum hrtimer_restart tcp_compress + + bh_lock_sock(sk); + if (!sock_owned_by_user(sk)) { +- if (tp->compressed_ack) ++ if (tp->compressed_ack > TCP_FASTRETRANS_THRESH) + tcp_send_ack(sk); + } else { + if (!test_and_set_bit(TCP_DELACK_TIMER_DEFERRED, diff --git a/queue-4.19/tipc-fix-lockdep-warning-during-node-delete.patch b/queue-4.19/tipc-fix-lockdep-warning-during-node-delete.patch new file mode 100644 index 00000000000..9947443dfae --- /dev/null +++ b/queue-4.19/tipc-fix-lockdep-warning-during-node-delete.patch @@ -0,0 +1,115 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Jon Maloy +Date: Mon, 26 Nov 2018 12:26:14 -0500 +Subject: tipc: fix lockdep warning during node delete + +From: Jon Maloy + +[ Upstream commit ec835f891232d7763dea9da0358f31e24ca6dfb7 ] + +We see the following lockdep warning: + +[ 2284.078521] ====================================================== +[ 2284.078604] WARNING: possible circular locking dependency detected +[ 2284.078604] 4.19.0+ #42 Tainted: G E +[ 2284.078604] ------------------------------------------------------ +[ 2284.078604] rmmod/254 is trying to acquire lock: +[ 2284.078604] 00000000acd94e28 ((&n->timer)#2){+.-.}, at: del_timer_sync+0x5/0xa0 +[ 2284.078604] +[ 2284.078604] but task is already holding lock: +[ 2284.078604] 00000000f997afc0 (&(&tn->node_list_lock)->rlock){+.-.}, at: tipc_node_stop+0xac/0x190 [tipc] +[ 2284.078604] +[ 2284.078604] which lock already depends on the new lock. +[ 2284.078604] +[ 2284.078604] +[ 2284.078604] the existing dependency chain (in reverse order) is: +[ 2284.078604] +[ 2284.078604] -> #1 (&(&tn->node_list_lock)->rlock){+.-.}: +[ 2284.078604] tipc_node_timeout+0x20a/0x330 [tipc] +[ 2284.078604] call_timer_fn+0xa1/0x280 +[ 2284.078604] run_timer_softirq+0x1f2/0x4d0 +[ 2284.078604] __do_softirq+0xfc/0x413 +[ 2284.078604] irq_exit+0xb5/0xc0 +[ 2284.078604] smp_apic_timer_interrupt+0xac/0x210 +[ 2284.078604] apic_timer_interrupt+0xf/0x20 +[ 2284.078604] default_idle+0x1c/0x140 +[ 2284.078604] do_idle+0x1bc/0x280 +[ 2284.078604] cpu_startup_entry+0x19/0x20 +[ 2284.078604] start_secondary+0x187/0x1c0 +[ 2284.078604] secondary_startup_64+0xa4/0xb0 +[ 2284.078604] +[ 2284.078604] -> #0 ((&n->timer)#2){+.-.}: +[ 2284.078604] del_timer_sync+0x34/0xa0 +[ 2284.078604] tipc_node_delete+0x1a/0x40 [tipc] +[ 2284.078604] tipc_node_stop+0xcb/0x190 [tipc] +[ 2284.078604] tipc_net_stop+0x154/0x170 [tipc] +[ 2284.078604] tipc_exit_net+0x16/0x30 [tipc] +[ 2284.078604] ops_exit_list.isra.8+0x36/0x70 +[ 2284.078604] unregister_pernet_operations+0x87/0xd0 +[ 2284.078604] unregister_pernet_subsys+0x1d/0x30 +[ 2284.078604] tipc_exit+0x11/0x6f2 [tipc] +[ 2284.078604] __x64_sys_delete_module+0x1df/0x240 +[ 2284.078604] do_syscall_64+0x66/0x460 +[ 2284.078604] entry_SYSCALL_64_after_hwframe+0x49/0xbe +[ 2284.078604] +[ 2284.078604] other info that might help us debug this: +[ 2284.078604] +[ 2284.078604] Possible unsafe locking scenario: +[ 2284.078604] +[ 2284.078604] CPU0 CPU1 +[ 2284.078604] ---- ---- +[ 2284.078604] lock(&(&tn->node_list_lock)->rlock); +[ 2284.078604] lock((&n->timer)#2); +[ 2284.078604] lock(&(&tn->node_list_lock)->rlock); +[ 2284.078604] lock((&n->timer)#2); +[ 2284.078604] +[ 2284.078604] *** DEADLOCK *** +[ 2284.078604] +[ 2284.078604] 3 locks held by rmmod/254: +[ 2284.078604] #0: 000000003368be9b (pernet_ops_rwsem){+.+.}, at: unregister_pernet_subsys+0x15/0x30 +[ 2284.078604] #1: 0000000046ed9c86 (rtnl_mutex){+.+.}, at: tipc_net_stop+0x144/0x170 [tipc] +[ 2284.078604] #2: 00000000f997afc0 (&(&tn->node_list_lock)->rlock){+.-.}, at: tipc_node_stop+0xac/0x19 +[...} + +The reason is that the node timer handler sometimes needs to delete a +node which has been disconnected for too long. To do this, it grabs +the lock 'node_list_lock', which may at the same time be held by the +generic node cleanup function, tipc_node_stop(), during module removal. +Since the latter is calling del_timer_sync() inside the same lock, we +have a potential deadlock. + +We fix this letting the timer cleanup function use spin_trylock() +instead of just spin_lock(), and when it fails to grab the lock it +just returns so that the timer handler can terminate its execution. +This is safe to do, since tipc_node_stop() anyway is about to +delete both the timer and the node instance. + +Fixes: 6a939f365bdb ("tipc: Auto removal of peer down node instance") +Acked-by: Ying Xue +Signed-off-by: Jon Maloy +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + net/tipc/node.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/net/tipc/node.c ++++ b/net/tipc/node.c +@@ -584,12 +584,15 @@ static void tipc_node_clear_links(struc + /* tipc_node_cleanup - delete nodes that does not + * have active links for NODE_CLEANUP_AFTER time + */ +-static int tipc_node_cleanup(struct tipc_node *peer) ++static bool tipc_node_cleanup(struct tipc_node *peer) + { + struct tipc_net *tn = tipc_net(peer->net); + bool deleted = false; + +- spin_lock_bh(&tn->node_list_lock); ++ /* If lock held by tipc_node_stop() the node will be deleted anyway */ ++ if (!spin_trylock_bh(&tn->node_list_lock)) ++ return false; ++ + tipc_node_write_lock(peer); + + if (!node_is_up(peer) && time_after(jiffies, peer->delete_at)) { diff --git a/queue-4.19/usbnet-ipheth-fix-potential-recvmsg-bug-and-recvmsg-bug-2.patch b/queue-4.19/usbnet-ipheth-fix-potential-recvmsg-bug-and-recvmsg-bug-2.patch new file mode 100644 index 00000000000..117e3b2455c --- /dev/null +++ b/queue-4.19/usbnet-ipheth-fix-potential-recvmsg-bug-and-recvmsg-bug-2.patch @@ -0,0 +1,168 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Bernd Eckstein <3erndeckstein@gmail.com> +Date: Fri, 23 Nov 2018 13:51:26 +0100 +Subject: usbnet: ipheth: fix potential recvmsg bug and recvmsg bug 2 + +From: Bernd Eckstein <3erndeckstein@gmail.com> + +[ Upstream commit 45611c61dd503454b2edae00aabe1e429ec49ebe ] + +The bug is not easily reproducable, as it may occur very infrequently +(we had machines with 20minutes heavy downloading before it occurred) +However, on a virual machine (VMWare on Windows 10 host) it occurred +pretty frequently (1-2 seconds after a speedtest was started) + +dev->tx_skb mab be freed via dev_kfree_skb_irq on a callback +before it is set. + +This causes the following problems: +- double free of the skb or potential memory leak +- in dmesg: 'recvmsg bug' and 'recvmsg bug 2' and eventually + general protection fault + +Example dmesg output: +[ 134.841986] ------------[ cut here ]------------ +[ 134.841987] recvmsg bug: copied 9C24A555 seq 9C24B557 rcvnxt 9C25A6B3 fl 0 +[ 134.841993] WARNING: CPU: 7 PID: 2629 at /build/linux-hwe-On9fm7/linux-hwe-4.15.0/net/ipv4/tcp.c:1865 tcp_recvmsg+0x44d/0xab0 +[ 134.841994] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi +[ 134.842046] CPU: 7 PID: 2629 Comm: python Tainted: G W OE 4.15.0-34-generic #37~16.04.1-Ubuntu +[ 134.842046] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 +[ 134.842048] RIP: 0010:tcp_recvmsg+0x44d/0xab0 +[ 134.842048] RSP: 0018:ffffa6630422bcc8 EFLAGS: 00010286 +[ 134.842049] RAX: 0000000000000000 RBX: ffff997616f4f200 RCX: 0000000000000006 +[ 134.842049] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff9976257d6490 +[ 134.842050] RBP: ffffa6630422bd98 R08: 0000000000000001 R09: 000000000004bba4 +[ 134.842050] R10: 0000000001e00c6f R11: 000000000004bba4 R12: ffff99760dee3000 +[ 134.842051] R13: 0000000000000000 R14: ffff99760dee3514 R15: 0000000000000000 +[ 134.842051] FS: 00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000 +[ 134.842052] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 134.842053] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0 +[ 134.842055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 134.842055] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 134.842057] Call Trace: +[ 134.842060] ? aa_sk_perm+0x53/0x1a0 +[ 134.842064] inet_recvmsg+0x51/0xc0 +[ 134.842066] sock_recvmsg+0x43/0x50 +[ 134.842070] SYSC_recvfrom+0xe4/0x160 +[ 134.842072] ? __schedule+0x3de/0x8b0 +[ 134.842075] ? ktime_get_ts64+0x4c/0xf0 +[ 134.842079] SyS_recvfrom+0xe/0x10 +[ 134.842082] do_syscall_64+0x73/0x130 +[ 134.842086] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 +[ 134.842086] RIP: 0033:0x7fe331f5a81d +[ 134.842088] RSP: 002b:00007ffe8da98398 EFLAGS: 00000246 ORIG_RAX: 000000000000002d +[ 134.842090] RAX: ffffffffffffffda RBX: ffffffffffffffff RCX: 00007fe331f5a81d +[ 134.842094] RDX: 00000000000003fb RSI: 0000000001e00874 RDI: 0000000000000003 +[ 134.842095] RBP: 00007fe32f642c70 R08: 0000000000000000 R09: 0000000000000000 +[ 134.842097] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe332347698 +[ 134.842099] R13: 0000000001b7e0a0 R14: 0000000001e00874 R15: 0000000000000000 +[ 134.842103] Code: 24 fd ff ff e9 cc fe ff ff 48 89 d8 41 8b 8c 24 10 05 00 00 44 8b 45 80 48 c7 c7 08 bd 59 8b 48 89 85 68 ff ff ff e8 b3 c4 7d ff <0f> 0b 48 8b 85 68 ff ff ff e9 e9 fe ff ff 41 8b 8c 24 10 05 00 +[ 134.842126] ---[ end trace b7138fc08c83147f ]--- +[ 134.842144] general protection fault: 0000 [#1] SMP PTI +[ 134.842145] Modules linked in: ipheth(OE) kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd vmw_balloon intel_rapl_perf joydev input_leds serio_raw vmw_vsock_vmci_transport vsock shpchp i2c_piix4 mac_hid binfmt_misc vmw_vmci parport_pc ppdev lp parport autofs4 vmw_pvscsi vmxnet3 hid_generic usbhid hid vmwgfx ttm drm_kms_helper syscopyarea sysfillrect mptspi mptscsih sysimgblt ahci psmouse fb_sys_fops pata_acpi mptbase libahci e1000 drm scsi_transport_spi +[ 134.842161] CPU: 7 PID: 2629 Comm: python Tainted: G W OE 4.15.0-34-generic #37~16.04.1-Ubuntu +[ 134.842162] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017 +[ 134.842164] RIP: 0010:tcp_close+0x2c6/0x440 +[ 134.842165] RSP: 0018:ffffa6630422bde8 EFLAGS: 00010202 +[ 134.842167] RAX: 0000000000000000 RBX: ffff99760dee3000 RCX: 0000000180400034 +[ 134.842168] RDX: 5c4afd407207a6c4 RSI: ffffe868495bd300 RDI: ffff997616f4f200 +[ 134.842169] RBP: ffffa6630422be08 R08: 0000000016f4d401 R09: 0000000180400034 +[ 134.842169] R10: ffffa6630422bd98 R11: 0000000000000000 R12: 000000000000600c +[ 134.842170] R13: 0000000000000000 R14: ffff99760dee30c8 R15: ffff9975bd44fe00 +[ 134.842171] FS: 00007fe332347700(0000) GS:ffff9976257c0000(0000) knlGS:0000000000000000 +[ 134.842173] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 134.842174] CR2: 0000000001e41000 CR3: 000000020e9b4006 CR4: 00000000003606e0 +[ 134.842177] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 134.842178] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 134.842179] Call Trace: +[ 134.842181] inet_release+0x42/0x70 +[ 134.842183] __sock_release+0x42/0xb0 +[ 134.842184] sock_close+0x15/0x20 +[ 134.842187] __fput+0xea/0x220 +[ 134.842189] ____fput+0xe/0x10 +[ 134.842191] task_work_run+0x8a/0xb0 +[ 134.842193] exit_to_usermode_loop+0xc4/0xd0 +[ 134.842195] do_syscall_64+0xf4/0x130 +[ 134.842197] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 +[ 134.842197] RIP: 0033:0x7fe331f5a560 +[ 134.842198] RSP: 002b:00007ffe8da982e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000003 +[ 134.842200] RAX: 0000000000000000 RBX: 00007fe32f642c70 RCX: 00007fe331f5a560 +[ 134.842201] RDX: 00000000008f5320 RSI: 0000000001cd4b50 RDI: 0000000000000003 +[ 134.842202] RBP: 00007fe32f6500f8 R08: 000000000000003c R09: 00000000009343c0 +[ 134.842203] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe32f6500d0 +[ 134.842204] R13: 00000000008f5320 R14: 00000000008f5320 R15: 0000000001cd4770 +[ 134.842205] Code: c8 00 00 00 45 31 e4 49 39 fe 75 4d eb 50 83 ab d8 00 00 00 01 48 8b 17 48 8b 47 08 48 c7 07 00 00 00 00 48 c7 47 08 00 00 00 00 <48> 89 42 08 48 89 10 0f b6 57 34 8b 47 2c 2b 47 28 83 e2 01 80 +[ 134.842226] RIP: tcp_close+0x2c6/0x440 RSP: ffffa6630422bde8 +[ 134.842227] ---[ end trace b7138fc08c831480 ]--- + +The proposed patch eliminates a potential racing condition. +Before, usb_submit_urb was called and _after_ that, the skb was attached +(dev->tx_skb). So, on a callback it was possible, however unlikely that the +skb was freed before it was set. That way (because dev->tx_skb was not set +to NULL after it was freed), it could happen that a skb from a earlier +transmission was freed a second time (and the skb we should have freed did +not get freed at all) + +Now we free the skb directly in ipheth_tx(). It is not passed to the +callback anymore, eliminating the posibility of a double free of the same +skb. Depending on the retval of usb_submit_urb() we use dev_kfree_skb_any() +respectively dev_consume_skb_any() to free the skb. + +Signed-off-by: Oliver Zweigle +Signed-off-by: Bernd Eckstein <3ernd.Eckstein@gmail.com> +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/ipheth.c | 10 ++++------ + 1 file changed, 4 insertions(+), 6 deletions(-) + +--- a/drivers/net/usb/ipheth.c ++++ b/drivers/net/usb/ipheth.c +@@ -140,7 +140,6 @@ struct ipheth_device { + struct usb_device *udev; + struct usb_interface *intf; + struct net_device *net; +- struct sk_buff *tx_skb; + struct urb *tx_urb; + struct urb *rx_urb; + unsigned char *tx_buf; +@@ -230,6 +229,7 @@ static void ipheth_rcvbulk_callback(stru + case -ENOENT: + case -ECONNRESET: + case -ESHUTDOWN: ++ case -EPROTO: + return; + case 0: + break; +@@ -281,7 +281,6 @@ static void ipheth_sndbulk_callback(stru + dev_err(&dev->intf->dev, "%s: urb status: %d\n", + __func__, status); + +- dev_kfree_skb_irq(dev->tx_skb); + if (status == 0) + netif_wake_queue(dev->net); + else +@@ -423,7 +422,7 @@ static int ipheth_tx(struct sk_buff *skb + if (skb->len > IPHETH_BUF_SIZE) { + WARN(1, "%s: skb too large: %d bytes\n", __func__, skb->len); + dev->net->stats.tx_dropped++; +- dev_kfree_skb_irq(skb); ++ dev_kfree_skb_any(skb); + return NETDEV_TX_OK; + } + +@@ -443,12 +442,11 @@ static int ipheth_tx(struct sk_buff *skb + dev_err(&dev->intf->dev, "%s: usb_submit_urb: %d\n", + __func__, retval); + dev->net->stats.tx_errors++; +- dev_kfree_skb_irq(skb); ++ dev_kfree_skb_any(skb); + } else { +- dev->tx_skb = skb; +- + dev->net->stats.tx_packets++; + dev->net->stats.tx_bytes += skb->len; ++ dev_consume_skb_any(skb); + netif_stop_queue(net); + } + diff --git a/queue-4.19/virtio-net-disable-guest-csum-during-xdp-set.patch b/queue-4.19/virtio-net-disable-guest-csum-during-xdp-set.patch new file mode 100644 index 00000000000..766afd2d02c --- /dev/null +++ b/queue-4.19/virtio-net-disable-guest-csum-during-xdp-set.patch @@ -0,0 +1,64 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Jason Wang +Date: Thu, 22 Nov 2018 14:36:30 +0800 +Subject: virtio-net: disable guest csum during XDP set + +From: Jason Wang + +[ Upstream commit e59ff2c49ae16e1d179de679aca81405829aee6c ] + +We don't disable VIRTIO_NET_F_GUEST_CSUM if XDP was set. This means we +can receive partial csumed packets with metadata kept in the +vnet_hdr. This may have several side effects: + +- It could be overridden by header adjustment, thus is might be not + correct after XDP processing. +- There's no way to pass such metadata information through + XDP_REDIRECT to another driver. +- XDP does not support checksum offload right now. + +So simply disable guest csum if possible in this the case of XDP. + +Fixes: 3f93522ffab2d ("virtio-net: switch off offloads on demand if possible on XDP set") +Reported-by: Jesper Dangaard Brouer +Cc: Jesper Dangaard Brouer +Cc: Pavel Popa +Cc: David Ahern +Signed-off-by: Jason Wang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/virtio_net.c | 8 ++------ + 1 file changed, 2 insertions(+), 6 deletions(-) + +--- a/drivers/net/virtio_net.c ++++ b/drivers/net/virtio_net.c +@@ -70,7 +70,8 @@ static const unsigned long guest_offload + VIRTIO_NET_F_GUEST_TSO4, + VIRTIO_NET_F_GUEST_TSO6, + VIRTIO_NET_F_GUEST_ECN, +- VIRTIO_NET_F_GUEST_UFO ++ VIRTIO_NET_F_GUEST_UFO, ++ VIRTIO_NET_F_GUEST_CSUM + }; + + struct virtnet_stat_desc { +@@ -2285,9 +2286,6 @@ static int virtnet_clear_guest_offloads( + if (!vi->guest_offloads) + return 0; + +- if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM)) +- offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM; +- + return virtnet_set_guest_offloads(vi, offloads); + } + +@@ -2297,8 +2295,6 @@ static int virtnet_restore_guest_offload + + if (!vi->guest_offloads) + return 0; +- if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM)) +- offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM; + + return virtnet_set_guest_offloads(vi, offloads); + } diff --git a/queue-4.19/virtio-net-fail-xdp-set-if-guest-csum-is-negotiated.patch b/queue-4.19/virtio-net-fail-xdp-set-if-guest-csum-is-negotiated.patch new file mode 100644 index 00000000000..84d93c052bf --- /dev/null +++ b/queue-4.19/virtio-net-fail-xdp-set-if-guest-csum-is-negotiated.patch @@ -0,0 +1,39 @@ +From foo@baz Mon Dec 3 10:10:43 CET 2018 +From: Jason Wang +Date: Thu, 22 Nov 2018 14:36:31 +0800 +Subject: virtio-net: fail XDP set if guest csum is negotiated + +From: Jason Wang + +[ Upstream commit 18ba58e1c234ea1a2d9835ac8c1735d965ce4640 ] + +We don't support partial csumed packet since its metadata will be lost +or incorrect during XDP processing. So fail the XDP set if guest_csum +feature is negotiated. + +Fixes: f600b6905015 ("virtio_net: Add XDP support") +Reported-by: Jesper Dangaard Brouer +Cc: Jesper Dangaard Brouer +Cc: Pavel Popa +Cc: David Ahern +Signed-off-by: Jason Wang +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/virtio_net.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/net/virtio_net.c ++++ b/drivers/net/virtio_net.c +@@ -2312,8 +2312,9 @@ static int virtnet_xdp_set(struct net_de + && (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO4) || + virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_TSO6) || + virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_ECN) || +- virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_UFO))) { +- NL_SET_ERR_MSG_MOD(extack, "Can't set XDP while host is implementing LRO, disable LRO first"); ++ virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_UFO) || ++ virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))) { ++ NL_SET_ERR_MSG_MOD(extack, "Can't set XDP while host is implementing LRO/CSUM, disable LRO/CSUM first"); + return -EOPNOTSUPP; + } + -- 2.47.3