From: Greg Kroah-Hartman Date: Mon, 3 Jul 2017 11:28:24 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v3.18.60~20 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=9d3a5f1f8ba57dde98f28c937ff5470cd07b94da;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: amd-xgbe-check-xgbe_init-return-code.patch documentation-devicetree-change-the-mediatek-ethernet-compatible-string.patch drm-amdgpu-check-ring-being-ready-before-using.patch drm-etnaviv-trick-drm_mm-into-giving-out-a-low-iova.patch ibmveth-add-a-proper-check-for-the-availability-of-the-checksum-features.patch ip6_tunnel-must-reload-ipv6h-in-ip6ip6_tnl_xmit.patch iwlwifi-fix-kernel-crash-when-unregistering-thermal-zone.patch kernel-panic.c-add-missing-n.patch mlxsw-spectrum_router-correctly-reallocate-adjacency-entries.patch net-dsa-check-return-value-of-phy_connect_direct.patch net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch perf-x86-intel-uncore-fix-hardcoded-socket-0-assumption-in-the-haswell-init-code.patch platform-x86-ideapad-laptop-handle-acpi-event-1.patch scsi-virtio_scsi-reject-commands-when-virtqueue-is-broken.patch swiotlb-xen-update-dev_addr-after-swapping-pages.patch vfio-spapr-fail-tce_iommu_attach_group-when-iommu_data-is-null.patch virtio_console-fix-a-crash-in-config_work_handler.patch virtio_net-fix-page_size-64k.patch vxlan-do-not-age-static-remote-mac-entries.patch xen-netfront-fix-rx-stall-during-network-stress-and-oom.patch --- diff --git a/queue-4.9/amd-xgbe-check-xgbe_init-return-code.patch b/queue-4.9/amd-xgbe-check-xgbe_init-return-code.patch new file mode 100644 index 00000000000..81f98b14588 --- /dev/null +++ b/queue-4.9/amd-xgbe-check-xgbe_init-return-code.patch @@ -0,0 +1,51 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: "Lendacky, Thomas" +Date: Fri, 20 Jan 2017 12:14:13 -0600 +Subject: amd-xgbe: Check xgbe_init() return code + +From: "Lendacky, Thomas" + + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-4.9/documentation-devicetree-change-the-mediatek-ethernet-compatible-string.patch b/queue-4.9/documentation-devicetree-change-the-mediatek-ethernet-compatible-string.patch new file mode 100644 index 00000000000..10228421955 --- /dev/null +++ b/queue-4.9/documentation-devicetree-change-the-mediatek-ethernet-compatible-string.patch @@ -0,0 +1,41 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: John Crispin +Date: Wed, 25 Jan 2017 09:20:54 +0100 +Subject: Documentation: devicetree: change the mediatek ethernet compatible string + +From: John Crispin + + +[ 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 +Signed-off-by: John Crispin +Reviewed-by: Matthias Brugger +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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. diff --git a/queue-4.9/drm-amdgpu-check-ring-being-ready-before-using.patch b/queue-4.9/drm-amdgpu-check-ring-being-ready-before-using.patch new file mode 100644 index 00000000000..315803c398c --- /dev/null +++ b/queue-4.9/drm-amdgpu-check-ring-being-ready-before-using.patch @@ -0,0 +1,46 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Ding Pixel +Date: Wed, 18 Jan 2017 17:26:38 +0800 +Subject: drm/amdgpu: check ring being ready before using + +From: Ding Pixel + + +[ 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 +Reviewed-by: Christian König +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-4.9/drm-etnaviv-trick-drm_mm-into-giving-out-a-low-iova.patch b/queue-4.9/drm-etnaviv-trick-drm_mm-into-giving-out-a-low-iova.patch new file mode 100644 index 00000000000..78f8e676173 --- /dev/null +++ b/queue-4.9/drm-etnaviv-trick-drm_mm-into-giving-out-a-low-iova.patch @@ -0,0 +1,43 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Lucas Stach +Date: Mon, 12 Dec 2016 16:15:17 +0100 +Subject: drm/etnaviv: trick drm_mm into giving out a low IOVA + +From: Lucas Stach + + +[ 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 +Reviewed-by: Wladimir van der Laan +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-4.9/ibmveth-add-a-proper-check-for-the-availability-of-the-checksum-features.patch b/queue-4.9/ibmveth-add-a-proper-check-for-the-availability-of-the-checksum-features.patch new file mode 100644 index 00000000000..3b940291b14 --- /dev/null +++ b/queue-4.9/ibmveth-add-a-proper-check-for-the-availability-of-the-checksum-features.patch @@ -0,0 +1,51 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Thomas Huth +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 + + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-4.9/ip6_tunnel-must-reload-ipv6h-in-ip6ip6_tnl_xmit.patch b/queue-4.9/ip6_tunnel-must-reload-ipv6h-in-ip6ip6_tnl_xmit.patch new file mode 100644 index 00000000000..904bd7d4946 --- /dev/null +++ b/queue-4.9/ip6_tunnel-must-reload-ipv6h-in-ip6ip6_tnl_xmit.patch @@ -0,0 +1,48 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Eric Dumazet +Date: Mon, 23 Jan 2017 16:43:05 -0800 +Subject: ip6_tunnel: must reload ipv6h in ip6ip6_tnl_xmit() + +From: Eric Dumazet + + +[ 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 +Cc: Dmitry Kozlov +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-4.9/iwlwifi-fix-kernel-crash-when-unregistering-thermal-zone.patch b/queue-4.9/iwlwifi-fix-kernel-crash-when-unregistering-thermal-zone.patch new file mode 100644 index 00000000000..fdb757778b4 --- /dev/null +++ b/queue-4.9/iwlwifi-fix-kernel-crash-when-unregistering-thermal-zone.patch @@ -0,0 +1,55 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Jens Axboe +Date: Tue, 17 Jan 2017 14:22:24 -0800 +Subject: iwlwifi: fix kernel crash when unregistering thermal zone + +From: Jens Axboe + + +[ 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 +Signed-off-by: Kalle Valo +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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 */ + diff --git a/queue-4.9/kernel-panic.c-add-missing-n.patch b/queue-4.9/kernel-panic.c-add-missing-n.patch new file mode 100644 index 00000000000..178831b6695 --- /dev/null +++ b/queue-4.9/kernel-panic.c-add-missing-n.patch @@ -0,0 +1,34 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Jiri Slaby +Date: Tue, 24 Jan 2017 15:18:29 -0800 +Subject: kernel/panic.c: add missing \n + +From: Jiri Slaby + + +[ 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 +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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(); diff --git a/queue-4.9/mlxsw-spectrum_router-correctly-reallocate-adjacency-entries.patch b/queue-4.9/mlxsw-spectrum_router-correctly-reallocate-adjacency-entries.patch new file mode 100644 index 00000000000..9afa9b6adbd --- /dev/null +++ b/queue-4.9/mlxsw-spectrum_router-correctly-reallocate-adjacency-entries.patch @@ -0,0 +1,71 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Ido Schimmel +Date: Mon, 23 Jan 2017 11:11:42 +0100 +Subject: mlxsw: spectrum_router: Correctly reallocate adjacency entries + +From: Ido Schimmel + + +[ 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 +Signed-off-by: Jiri Pirko +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-4.9/net-dsa-check-return-value-of-phy_connect_direct.patch b/queue-4.9/net-dsa-check-return-value-of-phy_connect_direct.patch new file mode 100644 index 00000000000..3a426a7d75f --- /dev/null +++ b/queue-4.9/net-dsa-check-return-value-of-phy_connect_direct.patch @@ -0,0 +1,53 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Florian Fainelli +Date: Fri, 20 Jan 2017 16:05:05 -0800 +Subject: net: dsa: Check return value of phy_connect_direct() + +From: Florian Fainelli + + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-4.9/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch b/queue-4.9/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch new file mode 100644 index 00000000000..88bd2c9f417 --- /dev/null +++ b/queue-4.9/net-sctp-fix-array-overrun-read-on-sctp_timer_tbl.patch @@ -0,0 +1,36 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Colin Ian King +Date: Fri, 20 Jan 2017 13:01:57 +0000 +Subject: net: sctp: fix array overrun read on sctp_timer_tbl + +From: Colin Ian King + + +[ 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 +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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"; + } diff --git a/queue-4.9/perf-x86-intel-uncore-fix-hardcoded-socket-0-assumption-in-the-haswell-init-code.patch b/queue-4.9/perf-x86-intel-uncore-fix-hardcoded-socket-0-assumption-in-the-haswell-init-code.patch new file mode 100644 index 00000000000..ead2145f9d5 --- /dev/null +++ b/queue-4.9/perf-x86-intel-uncore-fix-hardcoded-socket-0-assumption-in-the-haswell-init-code.patch @@ -0,0 +1,57 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Prarit Bhargava +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 + + +[ 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 +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Borislav Petkov +Cc: H. Peter Anvin +Cc: Harish Chegondi +Cc: Jiri Olsa +Cc: Kan Liang +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Thomas Gleixner +Cc: Vince Weaver +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 +Signed-off-by: Thomas Gleixner +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-4.9/platform-x86-ideapad-laptop-handle-acpi-event-1.patch b/queue-4.9/platform-x86-ideapad-laptop-handle-acpi-event-1.patch new file mode 100644 index 00000000000..369dd218b9b --- /dev/null +++ b/queue-4.9/platform-x86-ideapad-laptop-handle-acpi-event-1.patch @@ -0,0 +1,40 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Zach Ploskey +Date: Sun, 22 Jan 2017 00:47:19 -0800 +Subject: platform/x86: ideapad-laptop: handle ACPI event 1 + +From: Zach Ploskey + + +[ 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 +Signed-off-by: Andy Shevchenko +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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: diff --git a/queue-4.9/scsi-virtio_scsi-reject-commands-when-virtqueue-is-broken.patch b/queue-4.9/scsi-virtio_scsi-reject-commands-when-virtqueue-is-broken.patch new file mode 100644 index 00000000000..7a9d35829f9 --- /dev/null +++ b/queue-4.9/scsi-virtio_scsi-reject-commands-when-virtqueue-is-broken.patch @@ -0,0 +1,105 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Eric Farman +Date: Fri, 13 Jan 2017 12:48:06 -0500 +Subject: scsi: virtio_scsi: Reject commands when virtqueue is broken + +From: Eric Farman + + +[ 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 +Reviewed-by: Fam Zheng +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-4.9/series b/queue-4.9/series index c385522a84c..396c8ffc367 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -79,3 +79,23 @@ objtool-fix-iret-s-opcode.patch 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 diff --git a/queue-4.9/swiotlb-xen-update-dev_addr-after-swapping-pages.patch b/queue-4.9/swiotlb-xen-update-dev_addr-after-swapping-pages.patch new file mode 100644 index 00000000000..5f967a099a7 --- /dev/null +++ b/queue-4.9/swiotlb-xen-update-dev_addr-after-swapping-pages.patch @@ -0,0 +1,65 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Stefano Stabellini +Date: Thu, 19 Jan 2017 10:39:09 -0800 +Subject: swiotlb-xen: update dev_addr after swapping pages + +From: Stefano Stabellini + + +[ 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 +Signed-off-by: Pooya Keshavarzi +Tested-by: Pooya Keshavarzi +Reviewed-by: Boris Ostrovsky +Signed-off-by: Konrad Rzeszutek Wilk +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-4.9/vfio-spapr-fail-tce_iommu_attach_group-when-iommu_data-is-null.patch b/queue-4.9/vfio-spapr-fail-tce_iommu_attach_group-when-iommu_data-is-null.patch new file mode 100644 index 00000000000..5991c34213c --- /dev/null +++ b/queue-4.9/vfio-spapr-fail-tce_iommu_attach_group-when-iommu_data-is-null.patch @@ -0,0 +1,79 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Greg Kurz +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 + + +[ 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 +[ 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 2fa90000 419e0114 e9090020 +[ 116.298914] ---[ end trace 1e10b0ced08b9120 ]--- + +This patch fixes the oops. + +Reported-by: Vaibhav Jain +Signed-off-by: Greg Kurz +Signed-off-by: Alex Williamson +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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 || diff --git a/queue-4.9/virtio_console-fix-a-crash-in-config_work_handler.patch b/queue-4.9/virtio_console-fix-a-crash-in-config_work_handler.patch new file mode 100644 index 00000000000..3ff8a83eb87 --- /dev/null +++ b/queue-4.9/virtio_console-fix-a-crash-in-config_work_handler.patch @@ -0,0 +1,41 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: "G. Campana" +Date: Thu, 19 Jan 2017 23:37:46 +0200 +Subject: virtio_console: fix a crash in config_work_handler + +From: "G. Campana" + + +[ 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 +Reviewed-by: Amit Shah +Signed-off-by: Michael S. Tsirkin +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-4.9/virtio_net-fix-page_size-64k.patch b/queue-4.9/virtio_net-fix-page_size-64k.patch new file mode 100644 index 00000000000..64b1f18417f --- /dev/null +++ b/queue-4.9/virtio_net-fix-page_size-64k.patch @@ -0,0 +1,45 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: "Michael S. Tsirkin" +Date: Mon, 23 Jan 2017 21:37:52 +0200 +Subject: virtio_net: fix PAGE_SIZE > 64k + +From: "Michael S. Tsirkin" + + +[ 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 +Signed-off-by: Michael S. Tsirkin +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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" + diff --git a/queue-4.9/vxlan-do-not-age-static-remote-mac-entries.patch b/queue-4.9/vxlan-do-not-age-static-remote-mac-entries.patch new file mode 100644 index 00000000000..97a71e8480e --- /dev/null +++ b/queue-4.9/vxlan-do-not-age-static-remote-mac-entries.patch @@ -0,0 +1,34 @@ +From foo@baz Mon Jul 3 13:22:04 CEST 2017 +From: Balakrishnan Raman +Date: Mon, 23 Jan 2017 20:44:33 -0800 +Subject: vxlan: do not age static remote mac entries + +From: Balakrishnan Raman + + +[ 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 +Signed-off-by: Roopa Prabhu +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-4.9/xen-netfront-fix-rx-stall-during-network-stress-and-oom.patch b/queue-4.9/xen-netfront-fix-rx-stall-during-network-stress-and-oom.patch new file mode 100644 index 00000000000..d3b58ecbd4b --- /dev/null +++ b/queue-4.9/xen-netfront-fix-rx-stall-during-network-stress-and-oom.patch @@ -0,0 +1,44 @@ +From foo@baz Mon Jul 3 13:09:02 CEST 2017 +From: Vineeth Remanan Pillai +Date: Thu, 19 Jan 2017 08:35:39 -0800 +Subject: xen-netfront: Fix Rx stall during network stress and OOM + +From: Vineeth Remanan Pillai + + +[ 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 +Reviewed-by: Juergen Gross +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }