--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Eric Dumazet <edumazet@google.com>
+Date: Wed, 24 Apr 2019 08:04:05 -0700
+Subject: ipv4: add sanity checks in ipv4_link_failure()
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 20ff83f10f113c88d0bb74589389b05250994c16 ]
+
+Before calling __ip_options_compile(), we need to ensure the network
+header is a an IPv4 one, and that it is already pulled in skb->head.
+
+RAW sockets going through a tunnel can end up calling ipv4_link_failure()
+with total garbage in the skb, or arbitrary lengthes.
+
+syzbot report :
+
+BUG: KASAN: stack-out-of-bounds in memcpy include/linux/string.h:355 [inline]
+BUG: KASAN: stack-out-of-bounds in __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
+Write of size 69 at addr ffff888096abf068 by task syz-executor.4/9204
+
+CPU: 0 PID: 9204 Comm: syz-executor.4 Not tainted 5.1.0-rc5+ #77
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0x172/0x1f0 lib/dump_stack.c:113
+ print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
+ kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
+ check_memory_region_inline mm/kasan/generic.c:185 [inline]
+ check_memory_region+0x123/0x190 mm/kasan/generic.c:191
+ memcpy+0x38/0x50 mm/kasan/common.c:133
+ memcpy include/linux/string.h:355 [inline]
+ __ip_options_echo+0x294/0x1120 net/ipv4/ip_options.c:123
+ __icmp_send+0x725/0x1400 net/ipv4/icmp.c:695
+ ipv4_link_failure+0x29f/0x550 net/ipv4/route.c:1204
+ dst_link_failure include/net/dst.h:427 [inline]
+ vti6_xmit net/ipv6/ip6_vti.c:514 [inline]
+ vti6_tnl_xmit+0x10d4/0x1c0c net/ipv6/ip6_vti.c:553
+ __netdev_start_xmit include/linux/netdevice.h:4414 [inline]
+ netdev_start_xmit include/linux/netdevice.h:4423 [inline]
+ xmit_one net/core/dev.c:3292 [inline]
+ dev_hard_start_xmit+0x1b2/0x980 net/core/dev.c:3308
+ __dev_queue_xmit+0x271d/0x3060 net/core/dev.c:3878
+ dev_queue_xmit+0x18/0x20 net/core/dev.c:3911
+ neigh_direct_output+0x16/0x20 net/core/neighbour.c:1527
+ neigh_output include/net/neighbour.h:508 [inline]
+ ip_finish_output2+0x949/0x1740 net/ipv4/ip_output.c:229
+ ip_finish_output+0x73c/0xd50 net/ipv4/ip_output.c:317
+ NF_HOOK_COND include/linux/netfilter.h:278 [inline]
+ ip_output+0x21f/0x670 net/ipv4/ip_output.c:405
+ dst_output include/net/dst.h:444 [inline]
+ NF_HOOK include/linux/netfilter.h:289 [inline]
+ raw_send_hdrinc net/ipv4/raw.c:432 [inline]
+ raw_sendmsg+0x1d2b/0x2f20 net/ipv4/raw.c:663
+ inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
+ sock_sendmsg_nosec net/socket.c:651 [inline]
+ sock_sendmsg+0xdd/0x130 net/socket.c:661
+ sock_write_iter+0x27c/0x3e0 net/socket.c:988
+ call_write_iter include/linux/fs.h:1866 [inline]
+ new_sync_write+0x4c7/0x760 fs/read_write.c:474
+ __vfs_write+0xe4/0x110 fs/read_write.c:487
+ vfs_write+0x20c/0x580 fs/read_write.c:549
+ ksys_write+0x14f/0x2d0 fs/read_write.c:599
+ __do_sys_write fs/read_write.c:611 [inline]
+ __se_sys_write fs/read_write.c:608 [inline]
+ __x64_sys_write+0x73/0xb0 fs/read_write.c:608
+ do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+RIP: 0033:0x458c29
+Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
+RSP: 002b:00007f293b44bc78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000458c29
+RDX: 0000000000000014 RSI: 00000000200002c0 RDI: 0000000000000003
+RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
+R10: 0000000000000000 R11: 0000000000000246 R12: 00007f293b44c6d4
+R13: 00000000004c8623 R14: 00000000004ded68 R15: 00000000ffffffff
+
+The buggy address belongs to the page:
+page:ffffea00025aafc0 count:0 mapcount:0 mapping:0000000000000000 index:0x0
+flags: 0x1fffc0000000000()
+raw: 01fffc0000000000 0000000000000000 ffffffff025a0101 0000000000000000
+raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
+page dumped because: kasan: bad access detected
+
+Memory state around the buggy address:
+ ffff888096abef80: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 f2
+ ffff888096abf000: f2 f2 f2 f2 00 00 00 00 00 00 00 00 00 00 00 00
+>ffff888096abf080: 00 00 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00
+ ^
+ ffff888096abf100: 00 00 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00
+ ffff888096abf180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+
+Fixes: ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Stephen Suryaputra <ssuryaextr@gmail.com>
+Acked-by: Willem de Bruijn <willemb@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv4/route.c | 34 ++++++++++++++++++++++++----------
+ 1 file changed, 24 insertions(+), 10 deletions(-)
+
+--- a/net/ipv4/route.c
++++ b/net/ipv4/route.c
+@@ -1185,25 +1185,39 @@ static struct dst_entry *ipv4_dst_check(
+ return dst;
+ }
+
+-static void ipv4_link_failure(struct sk_buff *skb)
++static void ipv4_send_dest_unreach(struct sk_buff *skb)
+ {
+ struct ip_options opt;
+- struct rtable *rt;
+ int res;
+
+ /* Recompile ip options since IPCB may not be valid anymore.
++ * Also check we have a reasonable ipv4 header.
+ */
+- memset(&opt, 0, sizeof(opt));
+- opt.optlen = ip_hdr(skb)->ihl*4 - sizeof(struct iphdr);
+-
+- rcu_read_lock();
+- res = __ip_options_compile(dev_net(skb->dev), &opt, skb, NULL);
+- rcu_read_unlock();
+-
+- if (res)
++ if (!pskb_network_may_pull(skb, sizeof(struct iphdr)) ||
++ ip_hdr(skb)->version != 4 || ip_hdr(skb)->ihl < 5)
+ return;
+
++ memset(&opt, 0, sizeof(opt));
++ if (ip_hdr(skb)->ihl > 5) {
++ if (!pskb_network_may_pull(skb, ip_hdr(skb)->ihl * 4))
++ return;
++ opt.optlen = ip_hdr(skb)->ihl * 4 - sizeof(struct iphdr);
++
++ rcu_read_lock();
++ res = __ip_options_compile(dev_net(skb->dev), &opt, skb, NULL);
++ rcu_read_unlock();
++
++ if (res)
++ return;
++ }
+ __icmp_send(skb, ICMP_DEST_UNREACH, ICMP_HOST_UNREACH, 0, &opt);
++}
++
++static void ipv4_link_failure(struct sk_buff *skb)
++{
++ struct rtable *rt;
++
++ ipv4_send_dest_unreach(skb);
+
+ rt = skb_rtable(skb);
+ if (rt)
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+Date: Tue, 16 Apr 2019 09:47:24 +0800
+Subject: ipv4: set the tcp_min_rtt_wlen range from 0 to one day
+
+From: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+
+[ Upstream commit 19fad20d15a6494f47f85d869f00b11343ee5c78 ]
+
+There is a UBSAN report as below:
+UBSAN: Undefined behaviour in net/ipv4/tcp_input.c:2877:56
+signed integer overflow:
+2147483647 * 1000 cannot be represented in type 'int'
+CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.1.0-rc4-00058-g582549e #1
+Call Trace:
+ <IRQ>
+ dump_stack+0x8c/0xba
+ ubsan_epilogue+0x11/0x60
+ handle_overflow+0x12d/0x170
+ ? ttwu_do_wakeup+0x21/0x320
+ __ubsan_handle_mul_overflow+0x12/0x20
+ tcp_ack_update_rtt+0x76c/0x780
+ tcp_clean_rtx_queue+0x499/0x14d0
+ tcp_ack+0x69e/0x1240
+ ? __wake_up_sync_key+0x2c/0x50
+ ? update_group_capacity+0x50/0x680
+ tcp_rcv_established+0x4e2/0xe10
+ tcp_v4_do_rcv+0x22b/0x420
+ tcp_v4_rcv+0xfe8/0x1190
+ ip_protocol_deliver_rcu+0x36/0x180
+ ip_local_deliver+0x15b/0x1a0
+ ip_rcv+0xac/0xd0
+ __netif_receive_skb_one_core+0x7f/0xb0
+ __netif_receive_skb+0x33/0xc0
+ netif_receive_skb_internal+0x84/0x1c0
+ napi_gro_receive+0x2a0/0x300
+ receive_buf+0x3d4/0x2350
+ ? detach_buf_split+0x159/0x390
+ virtnet_poll+0x198/0x840
+ ? reweight_entity+0x243/0x4b0
+ net_rx_action+0x25c/0x770
+ __do_softirq+0x19b/0x66d
+ irq_exit+0x1eb/0x230
+ do_IRQ+0x7a/0x150
+ common_interrupt+0xf/0xf
+ </IRQ>
+
+It can be reproduced by:
+ echo 2147483647 > /proc/sys/net/ipv4/tcp_min_rtt_wlen
+
+Fixes: f672258391b42 ("tcp: track min RTT using windowed min-filter")
+Signed-off-by: ZhangXiaoxu <zhangxiaoxu5@huawei.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/networking/ip-sysctl.txt | 1 +
+ net/ipv4/sysctl_net_ipv4.c | 5 ++++-
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+--- a/Documentation/networking/ip-sysctl.txt
++++ b/Documentation/networking/ip-sysctl.txt
+@@ -410,6 +410,7 @@ tcp_min_rtt_wlen - INTEGER
+ minimum RTT when it is moved to a longer path (e.g., due to traffic
+ engineering). A longer window makes the filter more resistant to RTT
+ inflations such as transient congestion. The unit is seconds.
++ Possible values: 0 - 86400 (1 day)
+ Default: 300
+
+ tcp_moderate_rcvbuf - BOOLEAN
+--- a/net/ipv4/sysctl_net_ipv4.c
++++ b/net/ipv4/sysctl_net_ipv4.c
+@@ -49,6 +49,7 @@ static int ip_ping_group_range_min[] = {
+ static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
+ static int comp_sack_nr_max = 255;
+ static u32 u32_max_div_HZ = UINT_MAX / HZ;
++static int one_day_secs = 24 * 3600;
+
+ /* obsolete */
+ static int sysctl_tcp_low_latency __read_mostly;
+@@ -1140,7 +1141,9 @@ static struct ctl_table ipv4_net_table[]
+ .data = &init_net.ipv4.sysctl_tcp_min_rtt_wlen,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+- .proc_handler = proc_dointvec
++ .proc_handler = proc_dointvec_minmax,
++ .extra1 = &zero,
++ .extra2 = &one_day_secs
+ },
+ {
+ .procname = "tcp_autocorking",
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Ido Schimmel <idosch@mellanox.com>
+Date: Thu, 18 Apr 2019 07:14:14 +0000
+Subject: mlxsw: pci: Reincrease PCI reset timeout
+
+From: Ido Schimmel <idosch@mellanox.com>
+
+[ Upstream commit 1ab3030193d25878b3b1409060e1e0a879800c95 ]
+
+During driver initialization the driver sends a reset to the device and
+waits for the firmware to signal that it is ready to continue.
+
+Commit d2f372ba0914 ("mlxsw: pci: Increase PCI SW reset timeout")
+increased the timeout to 13 seconds due to longer PHY calibration in
+Spectrum-2 compared to Spectrum-1.
+
+Recently it became apparent that this timeout is too short and therefore
+this patch increases it again to a safer limit that will be reduced in
+the future.
+
+Fixes: c3ab435466d5 ("mlxsw: spectrum: Extend to support Spectrum-2 ASIC")
+Fixes: d2f372ba0914 ("mlxsw: pci: Increase PCI SW reset timeout")
+Signed-off-by: Ido Schimmel <idosch@mellanox.com>
+Acked-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
++++ b/drivers/net/ethernet/mellanox/mlxsw/pci_hw.h
+@@ -27,7 +27,7 @@
+
+ #define MLXSW_PCI_SW_RESET 0xF0010
+ #define MLXSW_PCI_SW_RESET_RST_BIT BIT(0)
+-#define MLXSW_PCI_SW_RESET_TIMEOUT_MSECS 13000
++#define MLXSW_PCI_SW_RESET_TIMEOUT_MSECS 20000
+ #define MLXSW_PCI_SW_RESET_WAIT_MSECS 100
+ #define MLXSW_PCI_FW_READY 0xA1844
+ #define MLXSW_PCI_FW_READY_MASK 0xFFFF
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Amit Cohen <amitc@mellanox.com>
+Date: Thu, 18 Apr 2019 07:14:16 +0000
+Subject: mlxsw: spectrum: Fix autoneg status in ethtool
+
+From: Amit Cohen <amitc@mellanox.com>
+
+[ Upstream commit 151f0dddbbfe4c35c9c5b64873115aafd436af9d ]
+
+If link is down and autoneg is set to on/off, the status in ethtool does
+not change.
+
+The reason is when the link is down the function returns with zero
+before changing autoneg value.
+
+Move the checking of link state (up/down) to be performed after setting
+autoneg value, in order to be sure that autoneg will change in any case.
+
+Fixes: 56ade8fe3fe1 ("mlxsw: spectrum: Add initial support for Spectrum ASIC")
+Signed-off-by: Amit Cohen <amitc@mellanox.com>
+Signed-off-by: Ido Schimmel <idosch@mellanox.com>
+Acked-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+@@ -2504,11 +2504,11 @@ mlxsw_sp_port_set_link_ksettings(struct
+ if (err)
+ return err;
+
++ mlxsw_sp_port->link.autoneg = autoneg;
++
+ if (!netif_running(dev))
+ return 0;
+
+- mlxsw_sp_port->link.autoneg = autoneg;
+-
+ mlxsw_sp_port_admin_status_set(mlxsw_sp_port, false);
+ mlxsw_sp_port_admin_status_set(mlxsw_sp_port, true);
+
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Petr Machata <petrm@mellanox.com>
+Date: Thu, 18 Apr 2019 07:14:13 +0000
+Subject: mlxsw: spectrum: Put MC TCs into DWRR mode
+
+From: Petr Machata <petrm@mellanox.com>
+
+[ Upstream commit f476b3f809fa02f47af6333ed63715058c3fc348 ]
+
+Both Spectrum-1 and Spectrum-2 chips are currently configured such that
+pairs of TC n (which is used for UC traffic) and TC n+8 (which is used
+for MC traffic) are feeding into the same subgroup. Strict
+prioritization is configured between the two TCs, and by enabling
+MC-aware mode on the switch, the lower-numbered (UC) TCs are favored
+over the higher-numbered (MC) TCs.
+
+On Spectrum-2 however, there is an issue in configuration of the
+MC-aware mode. As a result, MC traffic is prioritized over UC traffic.
+To work around the issue, configure the MC TCs with DWRR mode (while
+keeping the UC TCs in strict mode).
+
+With this patch, the multicast-unicast arbitration results in the same
+behavior on both Spectrum-1 and Spectrum-2 chips.
+
+Fixes: 7b8195306694 ("mlxsw: spectrum: Configure MC-aware mode on mlxsw ports")
+Signed-off-by: Petr Machata <petrm@mellanox.com>
+Signed-off-by: Ido Schimmel <idosch@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+@@ -2783,7 +2783,7 @@ static int mlxsw_sp_port_ets_init(struct
+ err = mlxsw_sp_port_ets_set(mlxsw_sp_port,
+ MLXSW_REG_QEEC_HIERARCY_TC,
+ i + 8, i,
+- false, 0);
++ true, 100);
+ if (err)
+ return err;
+ }
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Jun Xiao <xiaojun2@hisilicon.com>
+Date: Tue, 23 Apr 2019 00:48:57 +0800
+Subject: net: hns: Fix WARNING when hns modules installed
+
+From: Jun Xiao <xiaojun2@hisilicon.com>
+
+Commit dfdf26babc98 upstream
+
+this patch need merge to 4.19.y stable kernel
+
+Fix Conflict:already fixed the confilct dfdf26babc98 with Yonglong Liu
+
+stable candidate:user cannot connect to the internet via hns dev
+by default setting without this patch
+
+we have already verified this patch on kunpeng916 platform,
+and it works well.
+
+Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
+Signed-off-by: Jun Xiao <xiaojun2@hisilicon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/hisilicon/hns/hns_enet.c | 15 ++++++---------
+ 1 file changed, 6 insertions(+), 9 deletions(-)
+
+--- a/drivers/net/ethernet/hisilicon/hns/hns_enet.c
++++ b/drivers/net/ethernet/hisilicon/hns/hns_enet.c
+@@ -1169,6 +1169,12 @@ int hns_nic_init_phy(struct net_device *
+ if (!h->phy_dev)
+ return 0;
+
++ phy_dev->supported &= h->if_support;
++ phy_dev->advertising = phy_dev->supported;
++
++ if (h->phy_if == PHY_INTERFACE_MODE_XGMII)
++ phy_dev->autoneg = false;
++
+ if (h->phy_if != PHY_INTERFACE_MODE_XGMII) {
+ phy_dev->dev_flags = 0;
+
+@@ -1180,15 +1186,6 @@ int hns_nic_init_phy(struct net_device *
+ if (unlikely(ret))
+ return -ENODEV;
+
+- phy_dev->supported &= h->if_support;
+- phy_dev->advertising = phy_dev->supported;
+-
+- if (h->phy_if == PHY_INTERFACE_MODE_XGMII)
+- phy_dev->autoneg = false;
+-
+- if (h->phy_if == PHY_INTERFACE_MODE_SGMII)
+- phy_stop(phy_dev);
+-
+ return 0;
+ }
+
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Erez Alfasi <ereza@mellanox.com>
+Date: Thu, 11 Apr 2019 10:41:03 +0300
+Subject: net/mlx5e: ethtool, Remove unsupported SFP EEPROM high pages query
+
+From: Erez Alfasi <ereza@mellanox.com>
+
+[ Upstream commit ace329f4ab3ba434be2adf618073c752d083b524 ]
+
+Querying EEPROM high pages data for SFP module is currently
+not supported by our driver and yet queried, resulting in
+invalid FW queries.
+
+Set the EEPROM ethtool data length to 256 for SFP module will
+limit the reading for page 0 only and prevent invalid FW queries.
+
+Fixes: bb64143eee8c ("net/mlx5e: Add ethtool support for dump module EEPROM")
+Signed-off-by: Erez Alfasi <ereza@mellanox.com>
+Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 2 +-
+ drivers/net/ethernet/mellanox/mlx5/core/port.c | 4 ----
+ 2 files changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c
+@@ -1317,7 +1317,7 @@ static int mlx5e_get_module_info(struct
+ break;
+ case MLX5_MODULE_ID_SFP:
+ modinfo->type = ETH_MODULE_SFF_8472;
+- modinfo->eeprom_len = ETH_MODULE_SFF_8472_LEN;
++ modinfo->eeprom_len = MLX5_EEPROM_PAGE_LENGTH;
+ break;
+ default:
+ netdev_err(priv->netdev, "%s: cable type not recognized:0x%x\n",
+--- a/drivers/net/ethernet/mellanox/mlx5/core/port.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/port.c
+@@ -404,10 +404,6 @@ int mlx5_query_module_eeprom(struct mlx5
+ size -= offset + size - MLX5_EEPROM_PAGE_LENGTH;
+
+ i2c_addr = MLX5_I2C_ADDR_LOW;
+- if (offset >= MLX5_EEPROM_PAGE_LENGTH) {
+- i2c_addr = MLX5_I2C_ADDR_HIGH;
+- offset -= MLX5_EEPROM_PAGE_LENGTH;
+- }
+
+ MLX5_SET(mcia_reg, in, l, 0);
+ MLX5_SET(mcia_reg, in, module, module_num);
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Maxim Mikityanskiy <maximmi@mellanox.com>
+Date: Mon, 8 Apr 2019 15:12:45 +0300
+Subject: net/mlx5e: Fix the max MTU check in case of XDP
+
+From: Maxim Mikityanskiy <maximmi@mellanox.com>
+
+[ Upstream commit d460c2718906252a2a69bc6f89b537071f792e6e ]
+
+MLX5E_XDP_MAX_MTU was calculated incorrectly. It didn't account for
+NET_IP_ALIGN and MLX5E_HW2SW_MTU, and it also misused MLX5_SKB_FRAG_SZ.
+This commit fixes the calculations and adds a brief explanation for the
+formula used.
+
+Fixes: a26a5bdf3ee2d ("net/mlx5e: Restrict the combination of large MTU and XDP")
+Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
+Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 20 ++++++++++++++++++++
+ drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h | 3 +--
+ drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 5 +++--
+ 3 files changed, 24 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+@@ -33,6 +33,26 @@
+ #include <linux/bpf_trace.h>
+ #include "en/xdp.h"
+
++int mlx5e_xdp_max_mtu(struct mlx5e_params *params)
++{
++ int hr = NET_IP_ALIGN + XDP_PACKET_HEADROOM;
++
++ /* Let S := SKB_DATA_ALIGN(sizeof(struct skb_shared_info)).
++ * The condition checked in mlx5e_rx_is_linear_skb is:
++ * SKB_DATA_ALIGN(sw_mtu + hard_mtu + hr) + S <= PAGE_SIZE (1)
++ * (Note that hw_mtu == sw_mtu + hard_mtu.)
++ * What is returned from this function is:
++ * max_mtu = PAGE_SIZE - S - hr - hard_mtu (2)
++ * After assigning sw_mtu := max_mtu, the left side of (1) turns to
++ * SKB_DATA_ALIGN(PAGE_SIZE - S) + S, which is equal to PAGE_SIZE,
++ * because both PAGE_SIZE and S are already aligned. Any number greater
++ * than max_mtu would make the left side of (1) greater than PAGE_SIZE,
++ * so max_mtu is the maximum MTU allowed.
++ */
++
++ return MLX5E_HW2SW_MTU(params, SKB_MAX_HEAD(hr));
++}
++
+ static inline bool
+ mlx5e_xmit_xdp_buff(struct mlx5e_xdpsq *sq, struct mlx5e_dma_info *di,
+ struct xdp_buff *xdp)
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.h
+@@ -34,12 +34,11 @@
+
+ #include "en.h"
+
+-#define MLX5E_XDP_MAX_MTU ((int)(PAGE_SIZE - \
+- MLX5_SKB_FRAG_SZ(XDP_PACKET_HEADROOM)))
+ #define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
+ #define MLX5E_XDP_TX_DS_COUNT \
+ ((sizeof(struct mlx5e_tx_wqe) / MLX5_SEND_WQE_DS) + 1 /* SG DS */)
+
++int mlx5e_xdp_max_mtu(struct mlx5e_params *params);
+ bool mlx5e_xdp_handle(struct mlx5e_rq *rq, struct mlx5e_dma_info *di,
+ void *va, u16 *rx_headroom, u32 *len);
+ bool mlx5e_poll_xdpsq_cq(struct mlx5e_cq *cq);
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+@@ -3761,7 +3761,7 @@ int mlx5e_change_mtu(struct net_device *
+ if (params->xdp_prog &&
+ !mlx5e_rx_is_linear_skb(priv->mdev, &new_channels.params)) {
+ netdev_err(netdev, "MTU(%d) > %d is not allowed while XDP enabled\n",
+- new_mtu, MLX5E_XDP_MAX_MTU);
++ new_mtu, mlx5e_xdp_max_mtu(params));
+ err = -EINVAL;
+ goto out;
+ }
+@@ -4227,7 +4227,8 @@ static int mlx5e_xdp_allowed(struct mlx5
+
+ if (!mlx5e_rx_is_linear_skb(priv->mdev, &new_channels.params)) {
+ netdev_warn(netdev, "XDP is not allowed with MTU(%d) > %d\n",
+- new_channels.params.sw_mtu, MLX5E_XDP_MAX_MTU);
++ new_channels.params.sw_mtu,
++ mlx5e_xdp_max_mtu(&new_channels.params));
+ return -EINVAL;
+ }
+
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Maxim Mikityanskiy <maximmi@mellanox.com>
+Date: Fri, 15 Mar 2019 16:41:43 +0200
+Subject: net/mlx5e: Fix use-after-free after xdp_return_frame
+
+From: Maxim Mikityanskiy <maximmi@mellanox.com>
+
+[ Upstream commit 12fc512f5741443a03adde2ead20724da8ad550a ]
+
+xdp_return_frame releases the frame. It leads to releasing the page, so
+it's not allowed to access xdpi.xdpf->len after that, because xdpi.xdpf
+is at xdp->data_hard_start after convert_to_xdp_frame. This patch moves
+the memory access to precede the return of the frame.
+
+Fixes: 58b99ee3e3ebe ("net/mlx5e: Add support for XDP_REDIRECT in device-out side")
+Signed-off-by: Maxim Mikityanskiy <maximmi@mellanox.com>
+Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+@@ -227,9 +227,9 @@ bool mlx5e_poll_xdpsq_cq(struct mlx5e_cq
+ sqcc++;
+
+ if (is_redirect) {
+- xdp_return_frame(xdpi->xdpf);
+ dma_unmap_single(sq->pdev, xdpi->dma_addr,
+ xdpi->xdpf->len, DMA_TO_DEVICE);
++ xdp_return_frame(xdpi->xdpf);
+ } else {
+ /* Recycle RX page */
+ mlx5e_page_release(rq, &xdpi->di, true);
+@@ -263,9 +263,9 @@ void mlx5e_free_xdpsq_descs(struct mlx5e
+ sq->cc++;
+
+ if (is_redirect) {
+- xdp_return_frame(xdpi->xdpf);
+ dma_unmap_single(sq->pdev, xdpi->dma_addr,
+ xdpi->xdpf->len, DMA_TO_DEVICE);
++ xdp_return_frame(xdpi->xdpf);
+ } else {
+ /* Recycle RX page */
+ mlx5e_page_release(rq, &xdpi->di, false);
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Zhu Yanjun <yanjun.zhu@oracle.com>
+Date: Wed, 24 Apr 2019 02:56:42 -0400
+Subject: net: rds: exchange of 8K and 1M pool
+
+From: Zhu Yanjun <yanjun.zhu@oracle.com>
+
+[ Upstream commit 4b9fc7146249a6e0e3175d0acc033fdcd2bfcb17 ]
+
+Before the commit 490ea5967b0d ("RDS: IB: move FMR code to its own file"),
+when the dirty_count is greater than 9/10 of max_items of 8K pool,
+1M pool is used, Vice versa. After the commit 490ea5967b0d ("RDS: IB: move
+FMR code to its own file"), the above is removed. When we make the
+following tests.
+
+Server:
+ rds-stress -r 1.1.1.16 -D 1M
+
+Client:
+ rds-stress -r 1.1.1.14 -s 1.1.1.16 -D 1M
+
+The following will appear.
+"
+connecting to 1.1.1.16:4000
+negotiated options, tasks will start in 2 seconds
+Starting up..header from 1.1.1.166:4001 to id 4001 bogus
+..
+tsks tx/s rx/s tx+rx K/s mbi K/s mbo K/s tx us/c rtt us
+cpu %
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+ 1 0 0 0.00 0.00 0.00 0.00 0.00 -1.00
+...
+"
+So this exchange between 8K and 1M pool is added back.
+
+Fixes: commit 490ea5967b0d ("RDS: IB: move FMR code to its own file")
+Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
+Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rds/ib_fmr.c | 11 +++++++++++
+ net/rds/ib_rdma.c | 3 ---
+ 2 files changed, 11 insertions(+), 3 deletions(-)
+
+--- a/net/rds/ib_fmr.c
++++ b/net/rds/ib_fmr.c
+@@ -44,6 +44,17 @@ struct rds_ib_mr *rds_ib_alloc_fmr(struc
+ else
+ pool = rds_ibdev->mr_1m_pool;
+
++ if (atomic_read(&pool->dirty_count) >= pool->max_items / 10)
++ queue_delayed_work(rds_ib_mr_wq, &pool->flush_worker, 10);
++
++ /* Switch pools if one of the pool is reaching upper limit */
++ if (atomic_read(&pool->dirty_count) >= pool->max_items * 9 / 10) {
++ if (pool->pool_type == RDS_IB_MR_8K_POOL)
++ pool = rds_ibdev->mr_1m_pool;
++ else
++ pool = rds_ibdev->mr_8k_pool;
++ }
++
+ ibmr = rds_ib_try_reuse_ibmr(pool);
+ if (ibmr)
+ return ibmr;
+--- a/net/rds/ib_rdma.c
++++ b/net/rds/ib_rdma.c
+@@ -454,9 +454,6 @@ struct rds_ib_mr *rds_ib_try_reuse_ibmr(
+ struct rds_ib_mr *ibmr = NULL;
+ int iter = 0;
+
+- if (atomic_read(&pool->dirty_count) >= pool->max_items_soft / 10)
+- queue_delayed_work(rds_ib_mr_wq, &pool->flush_worker, 10);
+-
+ while (1) {
+ ibmr = rds_ib_reuse_mr(pool);
+ if (ibmr)
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Eric Dumazet <edumazet@google.com>
+Date: Wed, 24 Apr 2019 05:35:00 -0700
+Subject: net/rose: fix unbound loop in rose_loopback_timer()
+
+From: Eric Dumazet <edumazet@google.com>
+
+[ Upstream commit 0453c682459583910d611a96de928f4442205493 ]
+
+This patch adds a limit on the number of skbs that fuzzers can queue
+into loopback_queue. 1000 packets for rose loopback seems more than enough.
+
+Then, since we now have multiple cpus in most linux hosts,
+we also need to limit the number of skbs rose_loopback_timer()
+can dequeue at each round.
+
+rose_loopback_queue() can be drop-monitor friendly, calling
+consume_skb() or kfree_skb() appropriately.
+
+Finally, use mod_timer() instead of del_timer() + add_timer()
+
+syzbot report was :
+
+rcu: INFO: rcu_preempt self-detected stall on CPU
+rcu: 0-...!: (10499 ticks this GP) idle=536/1/0x4000000000000002 softirq=103291/103291 fqs=34
+rcu: (t=10500 jiffies g=140321 q=323)
+rcu: rcu_preempt kthread starved for 10426 jiffies! g140321 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=1
+rcu: RCU grace-period kthread stack dump:
+rcu_preempt I29168 10 2 0x80000000
+Call Trace:
+ context_switch kernel/sched/core.c:2877 [inline]
+ __schedule+0x813/0x1cc0 kernel/sched/core.c:3518
+ schedule+0x92/0x180 kernel/sched/core.c:3562
+ schedule_timeout+0x4db/0xfd0 kernel/time/timer.c:1803
+ rcu_gp_fqs_loop kernel/rcu/tree.c:1971 [inline]
+ rcu_gp_kthread+0x962/0x17b0 kernel/rcu/tree.c:2128
+ kthread+0x357/0x430 kernel/kthread.c:253
+ ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
+NMI backtrace for cpu 0
+CPU: 0 PID: 7632 Comm: kworker/0:4 Not tainted 5.1.0-rc5+ #172
+Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
+Workqueue: events iterate_cleanup_work
+Call Trace:
+ <IRQ>
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0x172/0x1f0 lib/dump_stack.c:113
+ nmi_cpu_backtrace.cold+0x63/0xa4 lib/nmi_backtrace.c:101
+ nmi_trigger_cpumask_backtrace+0x1be/0x236 lib/nmi_backtrace.c:62
+ arch_trigger_cpumask_backtrace+0x14/0x20 arch/x86/kernel/apic/hw_nmi.c:38
+ trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]
+ rcu_dump_cpu_stacks+0x183/0x1cf kernel/rcu/tree.c:1223
+ print_cpu_stall kernel/rcu/tree.c:1360 [inline]
+ check_cpu_stall kernel/rcu/tree.c:1434 [inline]
+ rcu_pending kernel/rcu/tree.c:3103 [inline]
+ rcu_sched_clock_irq.cold+0x500/0xa4a kernel/rcu/tree.c:2544
+ update_process_times+0x32/0x80 kernel/time/timer.c:1635
+ tick_sched_handle+0xa2/0x190 kernel/time/tick-sched.c:161
+ tick_sched_timer+0x47/0x130 kernel/time/tick-sched.c:1271
+ __run_hrtimer kernel/time/hrtimer.c:1389 [inline]
+ __hrtimer_run_queues+0x33e/0xde0 kernel/time/hrtimer.c:1451
+ hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1509
+ local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1035 [inline]
+ smp_apic_timer_interrupt+0x120/0x570 arch/x86/kernel/apic/apic.c:1060
+ apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:807
+RIP: 0010:__sanitizer_cov_trace_pc+0x0/0x50 kernel/kcov.c:95
+Code: 89 25 b4 6e ec 08 41 bc f4 ff ff ff e8 cd 5d ea ff 48 c7 05 9e 6e ec 08 00 00 00 00 e9 a4 e9 ff ff 90 90 90 90 90 90 90 90 90 <55> 48 89 e5 48 8b 75 08 65 48 8b 04 25 00 ee 01 00 65 8b 15 c8 60
+RSP: 0018:ffff8880ae807ce0 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13
+RAX: ffff88806fd40640 RBX: dffffc0000000000 RCX: ffffffff863fbc56
+RDX: 0000000000000100 RSI: ffffffff863fbc1d RDI: ffff88808cf94228
+RBP: ffff8880ae807d10 R08: ffff88806fd40640 R09: ffffed1015d00f8b
+R10: ffffed1015d00f8a R11: 0000000000000003 R12: ffff88808cf941c0
+R13: 00000000fffff034 R14: ffff8882166cd840 R15: 0000000000000000
+ rose_loopback_timer+0x30d/0x3f0 net/rose/rose_loopback.c:91
+ call_timer_fn+0x190/0x720 kernel/time/timer.c:1325
+ expire_timers kernel/time/timer.c:1362 [inline]
+ __run_timers kernel/time/timer.c:1681 [inline]
+ __run_timers kernel/time/timer.c:1649 [inline]
+ run_timer_softirq+0x652/0x1700 kernel/time/timer.c:1694
+ __do_softirq+0x266/0x95a kernel/softirq.c:293
+ do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1027
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rose/rose_loopback.c | 27 ++++++++++++++++-----------
+ 1 file changed, 16 insertions(+), 11 deletions(-)
+
+--- a/net/rose/rose_loopback.c
++++ b/net/rose/rose_loopback.c
+@@ -16,6 +16,7 @@
+ #include <linux/init.h>
+
+ static struct sk_buff_head loopback_queue;
++#define ROSE_LOOPBACK_LIMIT 1000
+ static struct timer_list loopback_timer;
+
+ static void rose_set_loopback_timer(void);
+@@ -35,29 +36,27 @@ static int rose_loopback_running(void)
+
+ int rose_loopback_queue(struct sk_buff *skb, struct rose_neigh *neigh)
+ {
+- struct sk_buff *skbn;
++ struct sk_buff *skbn = NULL;
+
+- skbn = skb_clone(skb, GFP_ATOMIC);
++ if (skb_queue_len(&loopback_queue) < ROSE_LOOPBACK_LIMIT)
++ skbn = skb_clone(skb, GFP_ATOMIC);
+
+- kfree_skb(skb);
+-
+- if (skbn != NULL) {
++ if (skbn) {
++ consume_skb(skb);
+ skb_queue_tail(&loopback_queue, skbn);
+
+ if (!rose_loopback_running())
+ rose_set_loopback_timer();
++ } else {
++ kfree_skb(skb);
+ }
+
+ return 1;
+ }
+
+-
+ static void rose_set_loopback_timer(void)
+ {
+- del_timer(&loopback_timer);
+-
+- loopback_timer.expires = jiffies + 10;
+- add_timer(&loopback_timer);
++ mod_timer(&loopback_timer, jiffies + 10);
+ }
+
+ static void rose_loopback_timer(struct timer_list *unused)
+@@ -68,8 +67,12 @@ static void rose_loopback_timer(struct t
+ struct sock *sk;
+ unsigned short frametype;
+ unsigned int lci_i, lci_o;
++ int count;
+
+- while ((skb = skb_dequeue(&loopback_queue)) != NULL) {
++ for (count = 0; count < ROSE_LOOPBACK_LIMIT; count++) {
++ skb = skb_dequeue(&loopback_queue);
++ if (!skb)
++ return;
+ if (skb->len < ROSE_MIN_LEN) {
+ kfree_skb(skb);
+ continue;
+@@ -106,6 +109,8 @@ static void rose_loopback_timer(struct t
+ kfree_skb(skb);
+ }
+ }
++ if (!skb_queue_empty(&loopback_queue))
++ mod_timer(&loopback_timer, jiffies + 1);
+ }
+
+ void __exit rose_loopback_clear(void)
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Vinod Koul <vkoul@kernel.org>
+Date: Mon, 22 Apr 2019 15:15:32 +0530
+Subject: net: stmmac: move stmmac_check_ether_addr() to driver probe
+
+From: Vinod Koul <vkoul@kernel.org>
+
+[ Upstream commit b561af36b1841088552464cdc3f6371d92f17710 ]
+
+stmmac_check_ether_addr() checks the MAC address and assigns one in
+driver open(). In many cases when we create slave netdevice, the dev
+addr is inherited from master but the master dev addr maybe NULL at
+that time, so move this call to driver probe so that address is
+always valid.
+
+Signed-off-by: Xiaofei Shen <xiaofeis@codeaurora.org>
+Tested-by: Xiaofei Shen <xiaofeis@codeaurora.org>
+Signed-off-by: Sneh Shah <snehshah@codeaurora.org>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+@@ -2595,8 +2595,6 @@ static int stmmac_open(struct net_device
+ u32 chan;
+ int ret;
+
+- stmmac_check_ether_addr(priv);
+-
+ if (priv->hw->pcs != STMMAC_PCS_RGMII &&
+ priv->hw->pcs != STMMAC_PCS_TBI &&
+ priv->hw->pcs != STMMAC_PCS_RTBI) {
+@@ -4296,6 +4294,8 @@ int stmmac_dvr_probe(struct device *devi
+ if (ret)
+ goto error_hw_init;
+
++ stmmac_check_ether_addr(priv);
++
+ /* Configure real RX and TX queues */
+ netif_set_real_num_rx_queues(ndev, priv->plat->rx_queues_to_use);
+ netif_set_real_num_tx_queues(ndev, priv->plat->tx_queues_to_use);
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+Date: Fri, 19 Apr 2019 16:51:38 -0700
+Subject: net/tls: avoid potential deadlock in tls_set_device_offload_rx()
+
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+
+[ Upstream commit 62ef81d5632634d5e310ed25b9b940b2b6612b46 ]
+
+If device supports offload, but offload fails tls_set_device_offload_rx()
+will call tls_sw_free_resources_rx() which (unhelpfully) releases
+and reacquires the socket lock.
+
+For a small fix release and reacquire the device_offload_lock.
+
+Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
+Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
+Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tls/tls_device.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/net/tls/tls_device.c
++++ b/net/tls/tls_device.c
+@@ -874,7 +874,9 @@ int tls_set_device_offload_rx(struct soc
+ goto release_netdev;
+
+ free_sw_resources:
++ up_read(&device_offload_lock);
+ tls_sw_free_resources_rx(sk);
++ down_read(&device_offload_lock);
+ release_ctx:
+ ctx->priv_ctx_rx = NULL;
+ release_netdev:
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+Date: Fri, 19 Apr 2019 16:52:19 -0700
+Subject: net/tls: don't leak IV and record seq when offload fails
+
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+
+[ Upstream commit 12c7686111326148b4b5db189130522a4ad1be4a ]
+
+When device refuses the offload in tls_set_device_offload_rx()
+it calls tls_sw_free_resources_rx() to clean up software context
+state.
+
+Unfortunately, tls_sw_free_resources_rx() does not free all
+the state tls_set_sw_offload() allocated - it leaks IV and
+sequence number buffers. All other code paths which lead to
+tls_sw_release_resources_rx() (which tls_sw_free_resources_rx()
+calls) free those right before the call.
+
+Avoid the leak by moving freeing of iv and rec_seq into
+tls_sw_release_resources_rx().
+
+Fixes: 4799ac81e52a ("tls: Add rx inline crypto offload")
+Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
+Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tls/tls_device.c | 2 --
+ net/tls/tls_main.c | 5 +----
+ net/tls/tls_sw.c | 3 +++
+ 3 files changed, 4 insertions(+), 6 deletions(-)
+
+--- a/net/tls/tls_device.c
++++ b/net/tls/tls_device.c
+@@ -911,8 +911,6 @@ void tls_device_offload_cleanup_rx(struc
+ }
+ out:
+ up_read(&device_offload_lock);
+- kfree(tls_ctx->rx.rec_seq);
+- kfree(tls_ctx->rx.iv);
+ tls_sw_release_resources_rx(sk);
+ }
+
+--- a/net/tls/tls_main.c
++++ b/net/tls/tls_main.c
+@@ -290,11 +290,8 @@ static void tls_sk_proto_close(struct so
+ tls_sw_free_resources_tx(sk);
+ }
+
+- if (ctx->rx_conf == TLS_SW) {
+- kfree(ctx->rx.rec_seq);
+- kfree(ctx->rx.iv);
++ if (ctx->rx_conf == TLS_SW)
+ tls_sw_free_resources_rx(sk);
+- }
+
+ #ifdef CONFIG_TLS_DEVICE
+ if (ctx->rx_conf == TLS_HW)
+--- a/net/tls/tls_sw.c
++++ b/net/tls/tls_sw.c
+@@ -1118,6 +1118,9 @@ void tls_sw_release_resources_rx(struct
+ struct tls_context *tls_ctx = tls_get_ctx(sk);
+ struct tls_sw_context_rx *ctx = tls_sw_ctx_rx(tls_ctx);
+
++ kfree(tls_ctx->rx.rec_seq);
++ kfree(tls_ctx->rx.iv);
++
+ if (ctx->aead_recv) {
+ kfree_skb(ctx->recv_pkt);
+ ctx->recv_pkt = NULL;
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+Date: Wed, 17 Apr 2019 10:51:19 -0700
+Subject: net/tls: fix refcount adjustment in fallback
+
+From: Jakub Kicinski <jakub.kicinski@netronome.com>
+
+[ Upstream commit 9188d5ca454fd665145904267e726e9e8d122f5c ]
+
+Unlike atomic_add(), refcount_add() does not deal well
+with a negative argument. TLS fallback code reallocates
+the skb and is very likely to shrink the truesize, leading to:
+
+[ 189.513254] WARNING: CPU: 5 PID: 0 at lib/refcount.c:81 refcount_add_not_zero_checked+0x15c/0x180
+ Call Trace:
+ refcount_add_checked+0x6/0x40
+ tls_enc_skb+0xb93/0x13e0 [tls]
+
+Once wmem_allocated count saturates the application can no longer
+send data on the socket. This is similar to Eric's fixes for GSO,
+TCP:
+commit 7ec318feeed1 ("tcp: gso: avoid refcount_t warning from tcp_gso_segment()")
+and UDP:
+commit 575b65bc5bff ("udp: avoid refcount_t saturation in __udp_gso_segment()").
+
+Unlike the GSO case, for TLS fallback it's likely that the skb has
+shrunk, so the "likely" annotation is the other way around (likely
+branch being "sub").
+
+Fixes: e8f69799810c ("net/tls: Add generic NIC offload infrastructure")
+Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
+Reviewed-by: John Hurley <john.hurley@netronome.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/tls/tls_device_fallback.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+--- a/net/tls/tls_device_fallback.c
++++ b/net/tls/tls_device_fallback.c
+@@ -193,6 +193,9 @@ static void update_chksum(struct sk_buff
+
+ static void complete_skb(struct sk_buff *nskb, struct sk_buff *skb, int headln)
+ {
++ struct sock *sk = skb->sk;
++ int delta;
++
+ skb_copy_header(nskb, skb);
+
+ skb_put(nskb, skb->len);
+@@ -200,11 +203,15 @@ static void complete_skb(struct sk_buff
+ update_chksum(nskb, headln);
+
+ nskb->destructor = skb->destructor;
+- nskb->sk = skb->sk;
++ nskb->sk = sk;
+ skb->destructor = NULL;
+ skb->sk = NULL;
+- refcount_add(nskb->truesize - skb->truesize,
+- &nskb->sk->sk_wmem_alloc);
++
++ delta = nskb->truesize - skb->truesize;
++ if (likely(delta < 0))
++ WARN_ON_ONCE(refcount_sub_and_test(-delta, &sk->sk_wmem_alloc));
++ else if (delta)
++ refcount_add(delta, &sk->sk_wmem_alloc);
+ }
+
+ /* This function may be called after the user socket is already
x86-retpolines-disable-switch-jump-tables-when-retpolines-are-enabled.patch
mm-fix-warning-in-insert_pfn.patch
x86-fpu-don-t-export-__kernel_fpu_-begin-end.patch
+ipv4-add-sanity-checks-in-ipv4_link_failure.patch
+ipv4-set-the-tcp_min_rtt_wlen-range-from-0-to-one-day.patch
+mlxsw-spectrum-fix-autoneg-status-in-ethtool.patch
+net-mlx5e-ethtool-remove-unsupported-sfp-eeprom-high-pages-query.patch
+net-rds-exchange-of-8k-and-1m-pool.patch
+net-rose-fix-unbound-loop-in-rose_loopback_timer.patch
+net-stmmac-move-stmmac_check_ether_addr-to-driver-probe.patch
+net-tls-fix-refcount-adjustment-in-fallback.patch
+stmmac-pci-adjust-iot2000-matching.patch
+team-fix-possible-recursive-locking-when-add-slaves.patch
+net-hns-fix-warning-when-hns-modules-installed.patch
+mlxsw-pci-reincrease-pci-reset-timeout.patch
+mlxsw-spectrum-put-mc-tcs-into-dwrr-mode.patch
+net-mlx5e-fix-the-max-mtu-check-in-case-of-xdp.patch
+net-mlx5e-fix-use-after-free-after-xdp_return_frame.patch
+net-tls-avoid-potential-deadlock-in-tls_set_device_offload_rx.patch
+net-tls-don-t-leak-iv-and-record-seq-when-offload-fails.patch
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Su Bao Cheng <baocheng.su@siemens.com>
+Date: Thu, 18 Apr 2019 11:14:56 +0200
+Subject: stmmac: pci: Adjust IOT2000 matching
+
+From: Su Bao Cheng <baocheng.su@siemens.com>
+
+[ Upstream commit e0c1d14a1a3211dccf0540a6703ffbd5d2a75bdb ]
+
+Since there are more IOT2040 variants with identical hardware but
+different asset tags, the asset tag matching should be adjusted to
+support them.
+
+For the board name "SIMATIC IOT2000", currently there are 2 types of
+hardware, IOT2020 and IOT2040. The IOT2020 is identified by its unique
+asset tag. Match on it first. If we then match on the board name only,
+we will catch all IOT2040 variants. In the future there will be no other
+devices with the "SIMATIC IOT2000" DMI board name but different
+hardware.
+
+Signed-off-by: Su Bao Cheng <baocheng.su@siemens.com>
+Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+@@ -159,6 +159,12 @@ static const struct dmi_system_id quark_
+ },
+ .driver_data = (void *)&galileo_stmmac_dmi_data,
+ },
++ /*
++ * There are 2 types of SIMATIC IOT2000: IOT20202 and IOT2040.
++ * The asset tag "6ES7647-0AA00-0YA2" is only for IOT2020 which
++ * has only one pci network device while other asset tags are
++ * for IOT2040 which has two.
++ */
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+@@ -170,8 +176,6 @@ static const struct dmi_system_id quark_
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_BOARD_NAME, "SIMATIC IOT2000"),
+- DMI_EXACT_MATCH(DMI_BOARD_ASSET_TAG,
+- "6ES7647-0AA00-1YA2"),
+ },
+ .driver_data = (void *)&iot2040_stmmac_dmi_data,
+ },
--- /dev/null
+From foo@baz Tue 30 Apr 2019 09:52:45 AM CEST
+From: Hangbin Liu <liuhangbin@gmail.com>
+Date: Fri, 19 Apr 2019 14:31:00 +0800
+Subject: team: fix possible recursive locking when add slaves
+
+From: Hangbin Liu <liuhangbin@gmail.com>
+
+[ Upstream commit 925b0c841e066b488cc3a60272472b2c56300704 ]
+
+If we add a bond device which is already the master of the team interface,
+we will hold the team->lock in team_add_slave() first and then request the
+lock in team_set_mac_address() again. The functions are called like:
+
+- team_add_slave()
+ - team_port_add()
+ - team_port_enter()
+ - team_modeop_port_enter()
+ - __set_port_dev_addr()
+ - dev_set_mac_address()
+ - bond_set_mac_address()
+ - dev_set_mac_address()
+ - team_set_mac_address
+
+Although team_upper_dev_link() would check the upper devices but it is
+called too late. Fix it by adding a checking before processing the slave.
+
+v2: Do not split the string in netdev_err()
+
+Fixes: 3d249d4ca7d0 ("net: introduce ethernet teaming device")
+Acked-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/team/team.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/net/team/team.c
++++ b/drivers/net/team/team.c
+@@ -1160,6 +1160,13 @@ static int team_port_add(struct team *te
+ return -EINVAL;
+ }
+
++ if (netdev_has_upper_dev(dev, port_dev)) {
++ NL_SET_ERR_MSG(extack, "Device is already an upper device of the team interface");
++ netdev_err(dev, "Device %s is already an upper device of the team interface\n",
++ portname);
++ return -EBUSY;
++ }
++
+ if (port_dev->features & NETIF_F_VLAN_CHALLENGED &&
+ vlan_uses_dev(dev)) {
+ NL_SET_ERR_MSG(extack, "Device is VLAN challenged and team device has VLAN set up");
projects / thirdparty / kernel / stable-queue.git / commitdiff
