--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
+Date: Fri, 20 Jan 2017 12:14:13 -0600
+Subject: amd-xgbe: Check xgbe_init() return code
+
+From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
+
+
+[ Upstream commit 738f7f647371ff4cfc9646c99dba5b58ad142db3 ]
+
+The xgbe_init() routine returns a return code indicating success or
+failure, but the return code is not checked. Add code to xgbe_init()
+to issue a message when failures are seen and add code to check the
+xgbe_init() return code.
+
+Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/amd/xgbe/xgbe-dev.c | 4 +++-
+ drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 4 +++-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
++++ b/drivers/net/ethernet/amd/xgbe/xgbe-dev.c
+@@ -2825,8 +2825,10 @@ static int xgbe_init(struct xgbe_prv_dat
+
+ /* Flush Tx queues */
+ ret = xgbe_flush_tx_queues(pdata);
+- if (ret)
++ if (ret) {
++ netdev_err(pdata->netdev, "error flushing TX queues\n");
+ return ret;
++ }
+
+ /*
+ * Initialize DMA related features
+--- a/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
++++ b/drivers/net/ethernet/amd/xgbe/xgbe-drv.c
+@@ -877,7 +877,9 @@ static int xgbe_start(struct xgbe_prv_da
+
+ DBGPR("-->xgbe_start\n");
+
+- hw_if->init(pdata);
++ ret = hw_if->init(pdata);
++ if (ret)
++ return ret;
+
+ ret = phy_if->phy_start(pdata);
+ if (ret)
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: John Crispin <john@phrozen.org>
+Date: Wed, 25 Jan 2017 09:20:54 +0100
+Subject: Documentation: devicetree: change the mediatek ethernet compatible string
+
+From: John Crispin <john@phrozen.org>
+
+
+[ Upstream commit 61976fff20f92aceecc3670f6168bfc57a79e047 ]
+
+When the binding was defined, I was not aware that mt2701 was an earlier
+version of the SoC. For sake of consistency, the ethernet driver should
+use mt2701 inside the compat string as this is the earliest SoC with the
+ethernet core.
+
+The ethernet driver is currently of no real use until we finish and
+upstream the DSA driver. There are no users of this binding yet. It should
+be safe to fix this now before it is too late and we need to provide
+backward compatibility for the mt7623-eth compat string.
+
+Reported-by: Sean Wang <sean.wang@mediatek.com>
+Signed-off-by: John Crispin <john@phrozen.org>
+Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/net/mediatek-net.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/net/mediatek-net.txt
++++ b/Documentation/devicetree/bindings/net/mediatek-net.txt
+@@ -7,7 +7,7 @@ have dual GMAC each represented by a chi
+ * Ethernet controller node
+
+ Required properties:
+-- compatible: Should be "mediatek,mt7623-eth"
++- compatible: Should be "mediatek,mt2701-eth"
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain the three frame engines interrupts in numeric
+ order. These are fe_int0, fe_int1 and fe_int2.
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Ding Pixel <pding@amd.com>
+Date: Wed, 18 Jan 2017 17:26:38 +0800
+Subject: drm/amdgpu: check ring being ready before using
+
+From: Ding Pixel <pding@amd.com>
+
+
+[ Upstream commit c5f21c9f878b8dcd54d0b9739c025ca73cb4c091 ]
+
+Return success when the ring is properly initialized, otherwise return
+failure.
+
+Tonga SRIOV VF doesn't have UVD and VCE engines, the initialization of
+these IPs is bypassed. The system crashes if application submit IB to
+their rings which are not ready to use. It could be a common issue if
+IP having ring buffer is disabled for some reason on specific ASIC, so
+it should check the ring being ready to use.
+
+Bug: amdgpu_test crashes system on Tonga VF.
+
+Signed-off-by: Ding Pixel <Pixel.Ding@amd.com>
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+@@ -83,6 +83,13 @@ int amdgpu_cs_get_ring(struct amdgpu_dev
+ }
+ break;
+ }
++
++ if (!(*out_ring && (*out_ring)->adev)) {
++ DRM_ERROR("Ring %d is not initialized on IP %d\n",
++ ring, ip_type);
++ return -EINVAL;
++ }
++
+ return 0;
+ }
+
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Mon, 12 Dec 2016 16:15:17 +0100
+Subject: drm/etnaviv: trick drm_mm into giving out a low IOVA
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+
+[ Upstream commit 3546fb0cdac25a79c89d87020566fab52b92867d ]
+
+After rollover of the IOVA space, we want to get a low IOVA address,
+otherwise the the games we play by remembering the last IOVA are
+pointless. When we search for a free hole with DRM_MM_SEARCH_DEFAULT,
+drm_mm will pop the next entry from the free holes stack, which will
+likely be a high IOVA. By using DRM_MM_SEARCH_BELOW we can trick
+drm_mm into reversing the search and provide us with a low IOVA.
+
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Reviewed-by: Wladimir van der Laan <laanwj@gmail.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
++++ b/drivers/gpu/drm/etnaviv/etnaviv_mmu.c
+@@ -116,9 +116,14 @@ static int etnaviv_iommu_find_iova(struc
+ struct list_head list;
+ bool found;
+
++ /*
++ * XXX: The DRM_MM_SEARCH_BELOW is really a hack to trick
++ * drm_mm into giving out a low IOVA after address space
++ * rollover. This needs a proper fix.
++ */
+ ret = drm_mm_insert_node_in_range(&mmu->mm, node,
+ size, 0, mmu->last_iova, ~0UL,
+- DRM_MM_SEARCH_DEFAULT);
++ mmu->last_iova ? DRM_MM_SEARCH_DEFAULT : DRM_MM_SEARCH_BELOW);
+
+ if (ret != -ENOSPC)
+ break;
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Thomas Huth <thuth@redhat.com>
+Date: Tue, 24 Jan 2017 07:28:41 +0100
+Subject: ibmveth: Add a proper check for the availability of the checksum features
+
+From: Thomas Huth <thuth@redhat.com>
+
+
+[ Upstream commit 23d28a859fb847fd7fcfbd31acb3b160abb5d6ae ]
+
+When using the ibmveth driver in a KVM/QEMU based VM, it currently
+always prints out a scary error message like this when it is started:
+
+ ibmveth 71000003 (unregistered net_device): unable to change
+ checksum offload settings. 1 rc=-2 ret_attr=71000003
+
+This happens because the driver always tries to enable the checksum
+offloading without checking for the availability of this feature first.
+QEMU does not support checksum offloading for the spapr-vlan device,
+thus we always get the error message here.
+According to the LoPAPR specification, the "ibm,illan-options" property
+of the corresponding device tree node should be checked first to see
+whether the H_ILLAN_ATTRIUBTES hypercall and thus the checksum offloading
+feature is available. Thus let's do this in the ibmveth driver, too, so
+that the error message is really only limited to cases where something
+goes wrong, and does not occur if the feature is just missing.
+
+Signed-off-by: Thomas Huth <thuth@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/ibm/ibmveth.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/ibm/ibmveth.c
++++ b/drivers/net/ethernet/ibm/ibmveth.c
+@@ -1604,8 +1604,11 @@ static int ibmveth_probe(struct vio_dev
+ netdev->netdev_ops = &ibmveth_netdev_ops;
+ netdev->ethtool_ops = &netdev_ethtool_ops;
+ SET_NETDEV_DEV(netdev, &dev->dev);
+- netdev->hw_features = NETIF_F_SG | NETIF_F_RXCSUM |
+- NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM;
++ netdev->hw_features = NETIF_F_SG;
++ if (vio_get_attribute(dev, "ibm,illan-options", NULL) != NULL) {
++ netdev->hw_features |= NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
++ NETIF_F_RXCSUM;
++ }
+
+ netdev->features |= netdev->hw_features;
+
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Eric Dumazet <edumazet@google.com>
+Date: Mon, 23 Jan 2017 16:43:05 -0800
+Subject: ip6_tunnel: must reload ipv6h in ip6ip6_tnl_xmit()
+
+From: Eric Dumazet <edumazet@google.com>
+
+
+[ Upstream commit 21b995a9cb093fff33ec91d7cb3822b882a90a1e ]
+
+Since ip6_tnl_parse_tlv_enc_lim() can call pskb_may_pull(),
+we must reload any pointer that was related to skb->head
+(or skb->data), or risk use after free.
+
+Fixes: c12b395a4664 ("gre: Support GRE over IPv6")
+Signed-off-by: Eric Dumazet <edumazet@google.com>
+Cc: Dmitry Kozlov <xeb@mail.ru>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/ip6_gre.c | 3 +++
+ net/ipv6/ip6_tunnel.c | 2 ++
+ 2 files changed, 5 insertions(+)
+
+--- a/net/ipv6/ip6_gre.c
++++ b/net/ipv6/ip6_gre.c
+@@ -582,6 +582,9 @@ static inline int ip6gre_xmit_ipv6(struc
+ return -1;
+
+ offset = ip6_tnl_parse_tlv_enc_lim(skb, skb_network_header(skb));
++ /* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head */
++ ipv6h = ipv6_hdr(skb);
++
+ if (offset > 0) {
+ struct ipv6_tlv_tnl_enc_lim *tel;
+ tel = (struct ipv6_tlv_tnl_enc_lim *)&skb_network_header(skb)[offset];
+--- a/net/ipv6/ip6_tunnel.c
++++ b/net/ipv6/ip6_tunnel.c
+@@ -1313,6 +1313,8 @@ ip6ip6_tnl_xmit(struct sk_buff *skb, str
+ fl6.flowlabel = key->label;
+ } else {
+ offset = ip6_tnl_parse_tlv_enc_lim(skb, skb_network_header(skb));
++ /* ip6_tnl_parse_tlv_enc_lim() might have reallocated skb->head */
++ ipv6h = ipv6_hdr(skb);
+ if (offset > 0) {
+ struct ipv6_tlv_tnl_enc_lim *tel;
+
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Jens Axboe <axboe@kernel.dk>
+Date: Tue, 17 Jan 2017 14:22:24 -0800
+Subject: iwlwifi: fix kernel crash when unregistering thermal zone
+
+From: Jens Axboe <axboe@kernel.dk>
+
+
+[ Upstream commit 92549cdc288f47f3a98cf80ac5890c91f5876a06 ]
+
+A recent firmware change seems to have enabled thermal zones on the
+iwlwifi driver. Unfortunately, my device fails when registering the
+thermal zone. This doesn't stop the driver from attempting to unregister
+the thermal zone at unload time, triggering a NULL pointer deference in
+strlen() off the thermal_zone_device_unregister() path.
+
+Don't unregister if name is NULL, for that case we failed registering.
+Do the same for the cooling zone.
+
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/wireless/intel/iwlwifi/mvm/tt.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
++++ b/drivers/net/wireless/intel/iwlwifi/mvm/tt.c
+@@ -843,8 +843,10 @@ static void iwl_mvm_thermal_zone_unregis
+ return;
+
+ IWL_DEBUG_TEMP(mvm, "Thermal zone device unregister\n");
+- thermal_zone_device_unregister(mvm->tz_device.tzone);
+- mvm->tz_device.tzone = NULL;
++ if (mvm->tz_device.tzone) {
++ thermal_zone_device_unregister(mvm->tz_device.tzone);
++ mvm->tz_device.tzone = NULL;
++ }
+ }
+
+ static void iwl_mvm_cooling_device_unregister(struct iwl_mvm *mvm)
+@@ -853,8 +855,10 @@ static void iwl_mvm_cooling_device_unreg
+ return;
+
+ IWL_DEBUG_TEMP(mvm, "Cooling device unregister\n");
+- thermal_cooling_device_unregister(mvm->cooling_dev.cdev);
+- mvm->cooling_dev.cdev = NULL;
++ if (mvm->cooling_dev.cdev) {
++ thermal_cooling_device_unregister(mvm->cooling_dev.cdev);
++ mvm->cooling_dev.cdev = NULL;
++ }
+ }
+ #endif /* CONFIG_THERMAL */
+
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Jiri Slaby <jslaby@suse.cz>
+Date: Tue, 24 Jan 2017 15:18:29 -0800
+Subject: kernel/panic.c: add missing \n
+
+From: Jiri Slaby <jslaby@suse.cz>
+
+
+[ Upstream commit ff7a28a074ccbea999dadbb58c46212cf90984c6 ]
+
+When a system panics, the "Rebooting in X seconds.." message is never
+printed because it lacks a new line. Fix it.
+
+Link: http://lkml.kernel.org/r/20170119114751.2724-1-jslaby@suse.cz
+Signed-off-by: Jiri Slaby <jslaby@suse.cz>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/panic.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/kernel/panic.c
++++ b/kernel/panic.c
+@@ -249,7 +249,7 @@ void panic(const char *fmt, ...)
+ * Delay timeout seconds before rebooting the machine.
+ * We can't use the "normal" timers since we just panicked.
+ */
+- pr_emerg("Rebooting in %d seconds..", panic_timeout);
++ pr_emerg("Rebooting in %d seconds..\n", panic_timeout);
+
+ for (i = 0; i < panic_timeout * 1000; i += PANIC_TIMER_STEP) {
+ touch_nmi_watchdog();
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Ido Schimmel <idosch@mellanox.com>
+Date: Mon, 23 Jan 2017 11:11:42 +0100
+Subject: mlxsw: spectrum_router: Correctly reallocate adjacency entries
+
+From: Ido Schimmel <idosch@mellanox.com>
+
+
+[ Upstream commit a59b7e0246774e28193126fe7fdbbd0ae9c67dcc ]
+
+mlxsw_sp_nexthop_group_mac_update() is called in one of two cases:
+
+1) When the MAC of a nexthop needs to be updated
+2) When the size of a nexthop group has changed
+
+In the second case the adjacency entries for the nexthop group need to
+be reallocated from the adjacency table. In this case we must write to
+the entries the MAC addresses of all the nexthops that should be
+offloaded and not only those whose MAC changed. Otherwise, these entries
+would be filled with garbage data, resulting in packet loss.
+
+Fixes: a7ff87acd995 ("mlxsw: spectrum_router: Implement next-hop routing")
+Signed-off-by: Ido Schimmel <idosch@mellanox.com>
+Signed-off-by: Jiri Pirko <jiri@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
++++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c
+@@ -1178,7 +1178,8 @@ static int mlxsw_sp_nexthop_mac_update(s
+
+ static int
+ mlxsw_sp_nexthop_group_mac_update(struct mlxsw_sp *mlxsw_sp,
+- struct mlxsw_sp_nexthop_group *nh_grp)
++ struct mlxsw_sp_nexthop_group *nh_grp,
++ bool reallocate)
+ {
+ u32 adj_index = nh_grp->adj_index; /* base */
+ struct mlxsw_sp_nexthop *nh;
+@@ -1193,7 +1194,7 @@ mlxsw_sp_nexthop_group_mac_update(struct
+ continue;
+ }
+
+- if (nh->update) {
++ if (nh->update || reallocate) {
+ err = mlxsw_sp_nexthop_mac_update(mlxsw_sp,
+ adj_index, nh);
+ if (err)
+@@ -1254,7 +1255,8 @@ mlxsw_sp_nexthop_group_refresh(struct ml
+ /* Nothing was added or removed, so no need to reallocate. Just
+ * update MAC on existing adjacency indexes.
+ */
+- err = mlxsw_sp_nexthop_group_mac_update(mlxsw_sp, nh_grp);
++ err = mlxsw_sp_nexthop_group_mac_update(mlxsw_sp, nh_grp,
++ false);
+ if (err) {
+ dev_warn(mlxsw_sp->bus_info->dev, "Failed to update neigh MAC in adjacency table.\n");
+ goto set_trap;
+@@ -1282,7 +1284,7 @@ mlxsw_sp_nexthop_group_refresh(struct ml
+ nh_grp->adj_index_valid = 1;
+ nh_grp->adj_index = adj_index;
+ nh_grp->ecmp_size = ecmp_size;
+- err = mlxsw_sp_nexthop_group_mac_update(mlxsw_sp, nh_grp);
++ err = mlxsw_sp_nexthop_group_mac_update(mlxsw_sp, nh_grp, true);
+ if (err) {
+ dev_warn(mlxsw_sp->bus_info->dev, "Failed to update neigh MAC in adjacency table.\n");
+ goto set_trap;
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Florian Fainelli <f.fainelli@gmail.com>
+Date: Fri, 20 Jan 2017 16:05:05 -0800
+Subject: net: dsa: Check return value of phy_connect_direct()
+
+From: Florian Fainelli <f.fainelli@gmail.com>
+
+
+[ Upstream commit 4078b76cac68e50ccf1f76a74e7d3d5788aec3fe ]
+
+We need to check the return value of phy_connect_direct() in
+dsa_slave_phy_connect() otherwise we may be continuing the
+initialization of a slave network device with a PHY that already
+attached somewhere else and which will soon be in error because the PHY
+device is in error.
+
+The conditions for such an error to occur are that we have a port of our
+switch that is not disabled, and has the same port number as a PHY
+address (say both 5) that can be probed using the DSA slave MII bus. We
+end-up having this slave network device find a PHY at the same address
+as our port number, and we try to attach to it.
+
+A slave network (e.g: port 0) has already attached to our PHY device,
+and we try to re-attach it with a different network device, but since we
+ignore the error we would end-up initializating incorrect device
+references by the time the slave network interface is opened.
+
+The code has been (re)organized several times, making it hard to provide
+an exact Fixes tag, this is a bugfix nonetheless.
+
+Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/dsa/slave.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/net/dsa/slave.c
++++ b/net/dsa/slave.c
+@@ -1103,10 +1103,8 @@ static int dsa_slave_phy_connect(struct
+ /* Use already configured phy mode */
+ if (p->phy_interface == PHY_INTERFACE_MODE_NA)
+ p->phy_interface = p->phy->interface;
+- phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
+- p->phy_interface);
+-
+- return 0;
++ return phy_connect_direct(slave_dev, p->phy, dsa_slave_adjust_link,
++ p->phy_interface);
+ }
+
+ static int dsa_slave_phy_setup(struct dsa_slave_priv *p,
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Colin Ian King <colin.king@canonical.com>
+Date: Fri, 20 Jan 2017 13:01:57 +0000
+Subject: net: sctp: fix array overrun read on sctp_timer_tbl
+
+From: Colin Ian King <colin.king@canonical.com>
+
+
+[ Upstream commit 0e73fc9a56f22f2eec4d2b2910c649f7af67b74d ]
+
+The comparison on the timeout can lead to an array overrun
+read on sctp_timer_tbl because of an off-by-one error. Fix
+this by using < instead of <= and also compare to the array
+size rather than SCTP_EVENT_TIMEOUT_MAX.
+
+Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
+
+Signed-off-by: Colin Ian King <colin.king@canonical.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sctp/debug.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/sctp/debug.c
++++ b/net/sctp/debug.c
+@@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[
+ /* Lookup timer debug name. */
+ const char *sctp_tname(const sctp_subtype_t id)
+ {
+- if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
++ if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
+ return sctp_timer_tbl[id.timeout];
+ return "unknown_timer";
+ }
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Prarit Bhargava <prarit@redhat.com>
+Date: Thu, 5 Jan 2017 10:09:25 -0500
+Subject: perf/x86/intel/uncore: Fix hardcoded socket 0 assumption in the Haswell init code
+
+From: Prarit Bhargava <prarit@redhat.com>
+
+
+[ Upstream commit 6d6daa20945f3f598e56e18d1f926c08754f5801 ]
+
+hswep_uncore_cpu_init() uses a hardcoded physical package id 0 for the boot
+cpu. This works as long as the boot CPU is actually on the physical package
+0, which is normaly the case after power on / reboot.
+
+But it fails with a NULL pointer dereference when a kdump kernel is started
+on a secondary socket which has a different physical package id because the
+locigal package translation for physical package 0 does not exist.
+
+Use the logical package id of the boot cpu instead of hard coded 0.
+
+[ tglx: Rewrote changelog once more ]
+
+Fixes: cf6d445f6897 ("perf/x86/uncore: Track packages, not per CPU data")
+Signed-off-by: Prarit Bhargava <prarit@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Borislav Petkov <bp@suse.de>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Harish Chegondi <harish.chegondi@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Kan Liang <kan.liang@intel.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Cc: stable@vger.kernel.org
+Link: http://lkml.kernel.org/r/1483628965-2890-1-git-send-email-prarit@redhat.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/intel/uncore_snbep.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/events/intel/uncore_snbep.c
++++ b/arch/x86/events/intel/uncore_snbep.c
+@@ -2686,7 +2686,7 @@ static struct intel_uncore_type *hswep_m
+
+ void hswep_uncore_cpu_init(void)
+ {
+- int pkg = topology_phys_to_logical_pkg(0);
++ int pkg = boot_cpu_data.logical_proc_id;
+
+ if (hswep_uncore_cbox.num_boxes > boot_cpu_data.x86_max_cores)
+ hswep_uncore_cbox.num_boxes = boot_cpu_data.x86_max_cores;
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Zach Ploskey <zach@ploskey.com>
+Date: Sun, 22 Jan 2017 00:47:19 -0800
+Subject: platform/x86: ideapad-laptop: handle ACPI event 1
+
+From: Zach Ploskey <zach@ploskey.com>
+
+
+[ Upstream commit cfee5d63767b2e7997c1f36420d008abbe61565c ]
+
+On Ideapad laptops, ACPI event 1 is currently not handled. Many models
+log "ideapad_laptop: Unknown event: 1" every 20 seconds or so while
+running on battery power. Some convertible laptops receive this event
+when switching in and out of tablet mode.
+
+This adds and additional case for event 1 in ideapad_acpi_notify to call
+ideapad_input_report(priv, vpc_bit), so that the event is reported to
+userspace and we avoid unnecessary logging.
+
+Fixes bug #107481 (https://bugzilla.kernel.org/show_bug.cgi?id=107481)
+Fixes bug #65751 (https://bugzilla.kernel.org/show_bug.cgi?id=65751)
+
+Signed-off-by: Zach Ploskey <zach@ploskey.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/ideapad-laptop.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/platform/x86/ideapad-laptop.c
++++ b/drivers/platform/x86/ideapad-laptop.c
+@@ -813,6 +813,7 @@ static void ideapad_acpi_notify(acpi_han
+ case 8:
+ case 7:
+ case 6:
++ case 1:
+ ideapad_input_report(priv, vpc_bit);
+ break;
+ case 5:
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Eric Farman <farman@linux.vnet.ibm.com>
+Date: Fri, 13 Jan 2017 12:48:06 -0500
+Subject: scsi: virtio_scsi: Reject commands when virtqueue is broken
+
+From: Eric Farman <farman@linux.vnet.ibm.com>
+
+
+[ Upstream commit 773c7220e22d193e5667c352fcbf8d47eefc817f ]
+
+In the case of a graceful set of detaches, where the virtio-scsi-ccw
+disk is removed from the guest prior to the controller, the guest
+behaves quite normally. Specifically, the detach gets us into
+sd_sync_cache to issue a Synchronize Cache(10) command, which
+immediately fails (and is retried a couple of times) because the device
+has been removed. Later, the removal of the controller sees two CRWs
+presented, but there's no further indication of the removal from the
+guest viewpoint.
+
+ [ 17.217458] sd 0:0:0:0: [sda] Synchronizing SCSI cache
+ [ 17.219257] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
+ [ 21.449400] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
+ [ 21.449406] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
+
+However, on s390, the SCSI disks can be removed "by surprise" when an
+entire controller (host) is removed and all associated disks are removed
+via the loop in scsi_forget_host. The same call to sd_sync_cache is
+made, but because the controller has already been removed, the
+Synchronize Cache(10) command is neither issued (and then failed) nor
+rejected.
+
+That the I/O isn't returned means the guest cannot have other devices
+added nor removed, and other tasks (such as shutdown or reboot) issued
+by the guest will not complete either. The virtio ring has already been
+marked as broken (via virtio_break_device in virtio_ccw_remove), but we
+still attempt to queue the command only to have it remain there. The
+calling sequence provides a bit of distinction for us:
+
+ virtscsi_queuecommand()
+ -> virtscsi_kick_cmd()
+ -> virtscsi_add_cmd()
+ -> virtqueue_add_sgs()
+ -> virtqueue_add()
+ if success
+ return 0
+ elseif vq->broken or vring_mapping_error()
+ return -EIO
+ else
+ return -ENOSPC
+
+A return of ENOSPC is generally a temporary condition, so returning
+"host busy" from virtscsi_queuecommand makes sense here, to have it
+redriven in a moment or two. But the EIO return code is more of a
+permanent error and so it would be wise to return the I/O itself and
+allow the calling thread to finish gracefully. The result is these four
+kernel messages in the guest (the fourth one does not occur prior to
+this patch):
+
+ [ 22.921562] crw_info : CRW reports slct=0, oflw=0, chn=1, rsc=3, anc=0, erc=4, rsid=2
+ [ 22.921580] crw_info : CRW reports slct=0, oflw=0, chn=0, rsc=3, anc=0, erc=4, rsid=0
+ [ 22.921978] sd 0:0:0:0: [sda] Synchronizing SCSI cache
+ [ 22.921993] sd 0:0:0:0: [sda] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
+
+I opted to fill in the same response data that is returned from the more
+graceful device detach, where the disk device is removed prior to the
+controller device.
+
+Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
+Reviewed-by: Fam Zheng <famz@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/scsi/virtio_scsi.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/drivers/scsi/virtio_scsi.c
++++ b/drivers/scsi/virtio_scsi.c
+@@ -534,7 +534,9 @@ static int virtscsi_queuecommand(struct
+ {
+ struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
+ struct virtio_scsi_cmd *cmd = scsi_cmd_priv(sc);
++ unsigned long flags;
+ int req_size;
++ int ret;
+
+ BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
+
+@@ -562,8 +564,15 @@ static int virtscsi_queuecommand(struct
+ req_size = sizeof(cmd->req.cmd);
+ }
+
+- if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd)) != 0)
++ ret = virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd));
++ if (ret == -EIO) {
++ cmd->resp.cmd.response = VIRTIO_SCSI_S_BAD_TARGET;
++ spin_lock_irqsave(&req_vq->vq_lock, flags);
++ virtscsi_complete_cmd(vscsi, cmd);
++ spin_unlock_irqrestore(&req_vq->vq_lock, flags);
++ } else if (ret != 0) {
+ return SCSI_MLQUEUE_HOST_BUSY;
++ }
+ return 0;
+ }
+
gianfar-do-not-reuse-pages-from-emergency-reserve.patch
btrfs-fix-deadlock-between-direct-io-and-fast-fsync.patch
btrfs-fix-truncate-down-when-no_holes-feature-is-enabled.patch
+virtio_console-fix-a-crash-in-config_work_handler.patch
+swiotlb-xen-update-dev_addr-after-swapping-pages.patch
+net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch
+xen-netfront-fix-rx-stall-during-network-stress-and-oom.patch
+scsi-virtio_scsi-reject-commands-when-virtqueue-is-broken.patch
+iwlwifi-fix-kernel-crash-when-unregistering-thermal-zone.patch
+platform-x86-ideapad-laptop-handle-acpi-event-1.patch
+amd-xgbe-check-xgbe_init-return-code.patch
+net-dsa-check-return-value-of-phy_connect_direct.patch
+drm-amdgpu-check-ring-being-ready-before-using.patch
+vfio-spapr-fail-tce_iommu_attach_group-when-iommu_data-is-null.patch
+mlxsw-spectrum_router-correctly-reallocate-adjacency-entries.patch
+virtio_net-fix-page_size-64k.patch
+ip6_tunnel-must-reload-ipv6h-in-ip6ip6_tnl_xmit.patch
+vxlan-do-not-age-static-remote-mac-entries.patch
+ibmveth-add-a-proper-check-for-the-availability-of-the-checksum-features.patch
+kernel-panic.c-add-missing-n.patch
+documentation-devicetree-change-the-mediatek-ethernet-compatible-string.patch
+drm-etnaviv-trick-drm_mm-into-giving-out-a-low-iova.patch
+perf-x86-intel-uncore-fix-hardcoded-socket-0-assumption-in-the-haswell-init-code.patch
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Stefano Stabellini <sstabellini@kernel.org>
+Date: Thu, 19 Jan 2017 10:39:09 -0800
+Subject: swiotlb-xen: update dev_addr after swapping pages
+
+From: Stefano Stabellini <sstabellini@kernel.org>
+
+
+[ Upstream commit f1225ee4c8fcf09afaa199b8b1f0450f38b8cd11 ]
+
+In xen_swiotlb_map_page and xen_swiotlb_map_sg_attrs, if the original
+page is not suitable, we swap it for another page from the swiotlb
+pool.
+
+In these cases, we don't update the previously calculated dma address
+for the page before calling xen_dma_map_page. Thus, we end up calling
+xen_dma_map_page passing the wrong dev_addr, resulting in
+xen_dma_map_page mistakenly assuming that the page is foreign when it is
+local.
+
+Fix the bug by updating dev_addr appropriately.
+
+This change has no effect on x86, because xen_dma_map_page is a stub
+there.
+
+Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
+Signed-off-by: Pooya Keshavarzi <Pooya.Keshavarzi@de.bosch.com>
+Tested-by: Pooya Keshavarzi <Pooya.Keshavarzi@de.bosch.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/xen/swiotlb-xen.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/xen/swiotlb-xen.c
++++ b/drivers/xen/swiotlb-xen.c
+@@ -409,9 +409,9 @@ dma_addr_t xen_swiotlb_map_page(struct d
+ if (map == SWIOTLB_MAP_ERROR)
+ return DMA_ERROR_CODE;
+
++ dev_addr = xen_phys_to_bus(map);
+ xen_dma_map_page(dev, pfn_to_page(map >> PAGE_SHIFT),
+ dev_addr, map & ~PAGE_MASK, size, dir, attrs);
+- dev_addr = xen_phys_to_bus(map);
+
+ /*
+ * Ensure that the address returned is DMA'ble
+@@ -567,13 +567,14 @@ xen_swiotlb_map_sg_attrs(struct device *
+ sg_dma_len(sgl) = 0;
+ return 0;
+ }
++ dev_addr = xen_phys_to_bus(map);
+ xen_dma_map_page(hwdev, pfn_to_page(map >> PAGE_SHIFT),
+ dev_addr,
+ map & ~PAGE_MASK,
+ sg->length,
+ dir,
+ attrs);
+- sg->dma_address = xen_phys_to_bus(map);
++ sg->dma_address = dev_addr;
+ } else {
+ /* we are not interested in the dma_addr returned by
+ * xen_dma_map_page, only in the potential cache flushes executed
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Greg Kurz <groug@kaod.org>
+Date: Tue, 24 Jan 2017 17:50:26 +0100
+Subject: vfio/spapr: fail tce_iommu_attach_group() when iommu_data is null
+
+From: Greg Kurz <groug@kaod.org>
+
+
+[ Upstream commit bd00fdf198e2da475a2f4265a83686ab42d998a8 ]
+
+The recently added mediated VFIO driver doesn't know about powerpc iommu.
+It thus doesn't register a struct iommu_table_group in the iommu group
+upon device creation. The iommu_data pointer hence remains null.
+
+This causes a kernel oops when userspace tries to set the iommu type of a
+container associated with a mediated device to VFIO_SPAPR_TCE_v2_IOMMU.
+
+[ 82.585440] mtty mtty: MDEV: Registered
+[ 87.655522] iommu: Adding device 83b8f4f2-509f-382f-3c1e-e6bfe0fa1001 to group 10
+[ 87.655527] vfio_mdev 83b8f4f2-509f-382f-3c1e-e6bfe0fa1001: MDEV: group_id = 10
+[ 116.297184] Unable to handle kernel paging request for data at address 0x00000030
+[ 116.297389] Faulting instruction address: 0xd000000007870524
+[ 116.297465] Oops: Kernel access of bad area, sig: 11 [#1]
+[ 116.297611] SMP NR_CPUS=2048
+[ 116.297611] NUMA
+[ 116.297627] PowerNV
+...
+[ 116.297954] CPU: 33 PID: 7067 Comm: qemu-system-ppc Not tainted 4.10.0-rc5-mdev-test #8
+[ 116.297993] task: c000000e7718b680 task.stack: c000000e77214000
+[ 116.298025] NIP: d000000007870524 LR: d000000007870518 CTR: 0000000000000000
+[ 116.298064] REGS: c000000e77217990 TRAP: 0300 Not tainted (4.10.0-rc5-mdev-test)
+[ 116.298103] MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
+[ 116.298107] CR: 84004444 XER: 00000000
+[ 116.298154] CFAR: c00000000000888c DAR: 0000000000000030 DSISR: 40000000 SOFTE: 1
+ GPR00: d000000007870518 c000000e77217c10 d00000000787b0ed c000000eed2103c0
+ GPR04: 0000000000000000 0000000000000000 c000000eed2103e0 0000000f24320000
+ GPR08: 0000000000000104 0000000000000001 0000000000000000 d0000000078729b0
+ GPR12: c00000000025b7e0 c00000000fe08400 0000000000000001 000001002d31d100
+ GPR16: 000001002c22c850 00003ffff315c750 0000000043145680 0000000043141bc0
+ GPR20: ffffffffffffffed fffffffffffff000 0000000020003b65 d000000007706018
+ GPR24: c000000f16cf0d98 d000000007706000 c000000003f42980 c000000003f42980
+ GPR28: c000000f1575ac00 c000000003f429c8 0000000000000000 c000000eed2103c0
+[ 116.298504] NIP [d000000007870524] tce_iommu_attach_group+0x10c/0x360 [vfio_iommu_spapr_tce]
+[ 116.298555] LR [d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce]
+[ 116.298601] Call Trace:
+[ 116.298610] [c000000e77217c10] [d000000007870518] tce_iommu_attach_group+0x100/0x360 [vfio_iommu_spapr_tce] (unreliable)
+[ 116.298671] [c000000e77217cb0] [d0000000077033a0] vfio_fops_unl_ioctl+0x278/0x3e0 [vfio]
+[ 116.298713] [c000000e77217d40] [c0000000002a3ebc] do_vfs_ioctl+0xcc/0x8b0
+[ 116.298745] [c000000e77217de0] [c0000000002a4700] SyS_ioctl+0x60/0xc0
+[ 116.298782] [c000000e77217e30] [c00000000000b220] system_call+0x38/0xfc
+[ 116.298812] Instruction dump:
+[ 116.298828] 7d3f4b78 409effc8 3d220000 e9298020 3c800140 38a00018 608480c0 e8690028
+[ 116.298869] 4800249d e8410018 7c7f1b79 41820230 <e93e0030> 2fa90000 419e0114 e9090020
+[ 116.298914] ---[ end trace 1e10b0ced08b9120 ]---
+
+This patch fixes the oops.
+
+Reported-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
+Signed-off-by: Greg Kurz <groug@kaod.org>
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/vfio/vfio_iommu_spapr_tce.c
++++ b/drivers/vfio/vfio_iommu_spapr_tce.c
+@@ -1292,6 +1292,10 @@ static int tce_iommu_attach_group(void *
+ /* pr_debug("tce_vfio: Attaching group #%u to iommu %p\n",
+ iommu_group_id(iommu_group), iommu_group); */
+ table_group = iommu_group_get_iommudata(iommu_group);
++ if (!table_group) {
++ ret = -ENODEV;
++ goto unlock_exit;
++ }
+
+ if (tce_groups_attached(container) && (!table_group->ops ||
+ !table_group->ops->take_ownership ||
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: "G. Campana" <gcampana@quarkslab.com>
+Date: Thu, 19 Jan 2017 23:37:46 +0200
+Subject: virtio_console: fix a crash in config_work_handler
+
+From: "G. Campana" <gcampana@quarkslab.com>
+
+
+[ Upstream commit 8379cadf71c3ee8173a1c6fc1ea7762a9638c047 ]
+
+Using control_work instead of config_work as the 3rd argument to
+container_of results in an invalid portdev pointer. Indeed, the work
+structure is initialized as below:
+
+ INIT_WORK(&portdev->config_work, &config_work_handler);
+
+It leads to a crash when portdev->vdev is dereferenced later. This
+bug
+is triggered when the guest uses a virtio-console without multiport
+feature and receives a config_changed virtio interrupt.
+
+Signed-off-by: G. Campana <gcampana@quarkslab.com>
+Reviewed-by: Amit Shah <amit.shah@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/virtio_console.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/virtio_console.c
++++ b/drivers/char/virtio_console.c
+@@ -1870,7 +1870,7 @@ static void config_work_handler(struct w
+ {
+ struct ports_device *portdev;
+
+- portdev = container_of(work, struct ports_device, control_work);
++ portdev = container_of(work, struct ports_device, config_work);
+ if (!use_multiport(portdev)) {
+ struct virtio_device *vdev;
+ struct port *port;
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: "Michael S. Tsirkin" <mst@redhat.com>
+Date: Mon, 23 Jan 2017 21:37:52 +0200
+Subject: virtio_net: fix PAGE_SIZE > 64k
+
+From: "Michael S. Tsirkin" <mst@redhat.com>
+
+
+[ Upstream commit d0fa28f00052391b5df328f502fbbdd4444938b7 ]
+
+I don't have any guests with PAGE_SIZE > 64k but the
+code seems to be clearly broken in that case
+as PAGE_SIZE / MERGEABLE_BUFFER_ALIGN will need
+more than 8 bit and so the code in mergeable_ctx_to_buf_address
+does not give us the actual true size.
+
+Cc: John Fastabend <john.fastabend@gmail.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/virtio_net.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/virtio_net.c
++++ b/drivers/net/virtio_net.c
+@@ -47,8 +47,16 @@ module_param(gso, bool, 0444);
+ */
+ DECLARE_EWMA(pkt_len, 1, 64)
+
++/* With mergeable buffers we align buffer address and use the low bits to
++ * encode its true size. Buffer size is up to 1 page so we need to align to
++ * square root of page size to ensure we reserve enough bits to encode the true
++ * size.
++ */
++#define MERGEABLE_BUFFER_MIN_ALIGN_SHIFT ((PAGE_SHIFT + 1) / 2)
++
+ /* Minimum alignment for mergeable packet buffers. */
+-#define MERGEABLE_BUFFER_ALIGN max(L1_CACHE_BYTES, 256)
++#define MERGEABLE_BUFFER_ALIGN max(L1_CACHE_BYTES, \
++ 1 << MERGEABLE_BUFFER_MIN_ALIGN_SHIFT)
+
+ #define VIRTNET_DRIVER_VERSION "1.0.0"
+
--- /dev/null
+From foo@baz Mon Jul 3 13:22:04 CEST 2017
+From: Balakrishnan Raman <ramanb@cumulusnetworks.com>
+Date: Mon, 23 Jan 2017 20:44:33 -0800
+Subject: vxlan: do not age static remote mac entries
+
+From: Balakrishnan Raman <ramanb@cumulusnetworks.com>
+
+
+[ Upstream commit efb5f68f32995c146944a9d4257c3cf8eae2c4a1 ]
+
+Mac aging is applicable only for dynamically learnt remote mac
+entries. Check for user configured static remote mac entries
+and skip aging.
+
+Signed-off-by: Balakrishnan Raman <ramanb@cumulusnetworks.com>
+Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/vxlan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/vxlan.c
++++ b/drivers/net/vxlan.c
+@@ -2285,7 +2285,7 @@ static void vxlan_cleanup(unsigned long
+ = container_of(p, struct vxlan_fdb, hlist);
+ unsigned long timeout;
+
+- if (f->state & NUD_PERMANENT)
++ if (f->state & (NUD_PERMANENT | NUD_NOARP))
+ continue;
+
+ timeout = f->used + vxlan->cfg.age_interval * HZ;
--- /dev/null
+From foo@baz Mon Jul 3 13:09:02 CEST 2017
+From: Vineeth Remanan Pillai <vineethp@amazon.com>
+Date: Thu, 19 Jan 2017 08:35:39 -0800
+Subject: xen-netfront: Fix Rx stall during network stress and OOM
+
+From: Vineeth Remanan Pillai <vineethp@amazon.com>
+
+
+[ Upstream commit 90c311b0eeead647b708a723dbdde1eda3dcad05 ]
+
+During an OOM scenario, request slots could not be created as skb
+allocation fails. So the netback cannot pass in packets and netfront
+wrongly assumes that there is no more work to be done and it disables
+polling. This causes Rx to stall.
+
+The issue is with the retry logic which schedules the timer if the
+created slots are less than NET_RX_SLOTS_MIN. The count of new request
+slots to be pushed are calculated as a difference between new req_prod
+and rsp_cons which could be more than the actual slots, if there are
+unconsumed responses.
+
+The fix is to calculate the count of newly created slots as the
+difference between new req_prod and old req_prod.
+
+Signed-off-by: Vineeth Remanan Pillai <vineethp@amazon.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/xen-netfront.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/xen-netfront.c
++++ b/drivers/net/xen-netfront.c
+@@ -321,7 +321,7 @@ static void xennet_alloc_rx_buffers(stru
+ queue->rx.req_prod_pvt = req_prod;
+
+ /* Not enough requests? Try again later. */
+- if (req_prod - queue->rx.rsp_cons < NET_RX_SLOTS_MIN) {
++ if (req_prod - queue->rx.sring->req_prod < NET_RX_SLOTS_MIN) {
+ mod_timer(&queue->rx_refill_timer, jiffies + (HZ/10));
+ return;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
