- Linux-stable-mirror - lists.linaro.org

Patch "s390/dasd: fix wrongly assigned configuration data" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled s390/dasd: fix wrongly assigned configuration data to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: s390-dasd-fix-wrongly-assigned-configuration-data.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Stefan Haberland <sth(a)linux.vnet.ibm.com> Date: Wed, 6 Dec 2017 10:30:39 +0100 Subject: s390/dasd: fix wrongly assigned configuration data From: Stefan Haberland <sth(a)linux.vnet.ibm.com> [ Upstream commit 8a9bd4f8ebc6800bfc0596e28631ff6809a2f615 ] We store per path and per device configuration data to identify the path or device correctly. The per path configuration data might get mixed up if the original request gets into error recovery and is started with a random path mask. This would lead to a wrong identification of a path in case of a CUIR event for example. Fix by copying the path mask from the original request to the error recovery request in case it is a path verification request. Signed-off-by: Stefan Haberland <sth(a)linux.vnet.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner(a)linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/s390/block/dasd_3990_erp.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/drivers/s390/block/dasd_3990_erp.c +++ b/drivers/s390/block/dasd_3990_erp.c @@ -2755,6 +2755,16 @@ dasd_3990_erp_action(struct dasd_ccw_req erp = dasd_3990_erp_handle_match_erp(cqr, erp); } + + /* + * For path verification work we need to stick with the path that was + * originally chosen so that the per path configuration data is + * assigned correctly. + */ + if (test_bit(DASD_CQR_VERIFY_PATH, &erp->flags) && cqr->lpm) { + erp->lpm = cqr->lpm; + } + if (device->features & DASD_FEATURE_ERPLOG) { /* print current erp_chain */ dev_err(&device->cdev->dev, Patches currently in stable-queue which might be from sth(a)linux.vnet.ibm.com are queue-4.9/s390-dasd-fix-wrongly-assigned-configuration-data.patch

7 years, 9 months

1
0
0 0

Patch "nvme: check hw sectors before setting chunk sectors" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme: check hw sectors before setting chunk sectors to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nvme-check-hw-sectors-before-setting-chunk-sectors.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Keith Busch <keith.busch(a)intel.com> Date: Thu, 14 Dec 2017 11:20:14 -0700 Subject: nvme: check hw sectors before setting chunk sectors From: Keith Busch <keith.busch(a)intel.com> [ Upstream commit 249159c5f15812140fa216f9997d799ac0023a1f ] Some devices with IDs matching the "stripe" quirk don't actually have this quirk, and don't have an MDTS value. When MDTS is not set, the driver sets the max sectors to UINT_MAX, which is not a power of 2, hitting a BUG_ON from blk_queue_chunk_sectors. This patch skips setting chunk sectors for such devices. Signed-off-by: Keith Busch <keith.busch(a)intel.com> Reviewed-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -1204,7 +1204,8 @@ static void nvme_set_queue_limits(struct blk_queue_max_hw_sectors(q, ctrl->max_hw_sectors); blk_queue_max_segments(q, min_t(u32, max_segments, USHRT_MAX)); } - if (ctrl->quirks & NVME_QUIRK_STRIPE_SIZE) + if ((ctrl->quirks & NVME_QUIRK_STRIPE_SIZE) && + is_power_of_2(ctrl->max_hw_sectors)) blk_queue_chunk_sectors(q, ctrl->max_hw_sectors); blk_queue_virt_boundary(q, ctrl->page_size - 1); if (ctrl->vwc & NVME_CTRL_VWC_PRESENT) Patches currently in stable-queue which might be from keith.busch(a)intel.com are queue-4.9/nvme-check-hw-sectors-before-setting-chunk-sectors.patch

7 years, 9 months

1
0
0 0

Patch "nl80211: Check for the required netlink attribute presence" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nl80211: Check for the required netlink attribute presence to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nl80211-check-for-the-required-netlink-attribute-presence.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Hao Chen <flank3rsky(a)gmail.com> Date: Wed, 3 Jan 2018 11:00:31 +0800 Subject: nl80211: Check for the required netlink attribute presence From: Hao Chen <flank3rsky(a)gmail.com> [ Upstream commit 3ea15452ee85754f70f3b9fa1f23165ef2e77ba7 ] nl80211_nan_add_func() does not check if the required attribute NL80211_NAN_FUNC_FOLLOW_UP_DEST is present when processing NL80211_CMD_ADD_NAN_FUNCTION request. This request can be issued by users with CAP_NET_ADMIN privilege and may result in NULL dereference and a system crash. Add a check for the required attribute presence. Signed-off-by: Hao Chen <flank3rsky(a)gmail.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/wireless/nl80211.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -10777,7 +10777,8 @@ static int nl80211_nan_add_func(struct s break; case NL80211_NAN_FUNC_FOLLOW_UP: if (!tb[NL80211_NAN_FUNC_FOLLOW_UP_ID] || - !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID]) { + !tb[NL80211_NAN_FUNC_FOLLOW_UP_REQ_ID] || + !tb[NL80211_NAN_FUNC_FOLLOW_UP_DEST]) { err = -EINVAL; goto out; } Patches currently in stable-queue which might be from flank3rsky(a)gmail.com are queue-4.9/nl80211-check-for-the-required-netlink-attribute-presence.patch

7 years, 9 months

1
0
0 0

Patch "net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-usb-qmi_wwan-add-telit-me910-pid-0x1101-support.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Daniele Palmas <dnlplm(a)gmail.com> Date: Thu, 14 Dec 2017 16:56:14 +0100 Subject: net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support From: Daniele Palmas <dnlplm(a)gmail.com> [ Upstream commit c647c0d62c82eb3ddf78a0d8b3d58819d9f552aa ] This patch adds support for Telit ME910 PID 0x1101. Signed-off-by: Daniele Palmas <dnlplm(a)gmail.com> Acked-by: Bjørn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -914,6 +914,7 @@ static const struct usb_device_id produc {QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */ {QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */ {QMI_FIXED_INTF(0x1bc7, 0x1100, 3)}, /* Telit ME910 */ + {QMI_FIXED_INTF(0x1bc7, 0x1101, 3)}, /* Telit ME910 dual modem */ {QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */ {QMI_FIXED_INTF(0x1bc7, 0x1201, 2)}, /* Telit LE920 */ {QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)}, /* XS Stick W100-2 from 4G Systems */ Patches currently in stable-queue which might be from dnlplm(a)gmail.com are queue-4.9/net-usb-qmi_wwan-add-telit-me910-pid-0x1101-support.patch

7 years, 9 months

1
0
0 0

Patch "NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-usb-qmi_wwan-add-support-for-yuga-clm920-nc5-pid-0x9625.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: "SZ Lin (林上智)" <sz.lin(a)moxa.com> Date: Fri, 29 Dec 2017 17:02:17 +0800 Subject: NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625 From: "SZ Lin (林上智)" <sz.lin(a)moxa.com> [ Upstream commit bd30ffc414e55194ed6149fad69a145550cb7c18 ] This patch adds support for PID 0x9625 of YUGA CLM920-NC5. YUGA CLM920-NC5 needs to enable QMI_WWAN_QUIRK_DTR before QMI operation. qmicli -d /dev/cdc-wdm0 -p --dms-get-revision [/dev/cdc-wdm0] Device revision retrieved: Revision: 'CLM920_NC5-V1 1 [Oct 23 2016 19:00:00]' Signed-off-by: SZ Lin (林上智) <sz.lin(a)moxa.com> Acked-by: Bjørn Mork <bjorn(a)mork.no> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/qmi_wwan.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/net/usb/qmi_wwan.c +++ b/drivers/net/usb/qmi_wwan.c @@ -805,6 +805,7 @@ static const struct usb_device_id produc {QMI_FIXED_INTF(0x05c6, 0x9084, 4)}, {QMI_FIXED_INTF(0x05c6, 0x920d, 0)}, {QMI_FIXED_INTF(0x05c6, 0x920d, 5)}, + {QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */ {QMI_FIXED_INTF(0x0846, 0x68a2, 8)}, {QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */ {QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */ Patches currently in stable-queue which might be from sz.lin(a)moxa.com are queue-4.9/net-usb-qmi_wwan-add-support-for-yuga-clm920-nc5-pid-0x9625.patch

7 years, 9 months

1
0
0 0

Patch "net: stmmac: Fix TX timestamp calculation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: stmmac: Fix TX timestamp calculation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-stmmac-fix-tx-timestamp-calculation.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Fredrik Hallenberg <megahallon(a)gmail.com> Date: Mon, 18 Dec 2017 23:33:59 +0100 Subject: net: stmmac: Fix TX timestamp calculation From: Fredrik Hallenberg <megahallon(a)gmail.com> [ Upstream commit 200922c93f008e03ddc804c6dacdf26ca1ba86d7 ] When using GMAC4 the value written in PTP_SSIR should be shifted however the shifted value is also used in subsequent calculations which results in a bad timestamp value. Signed-off-by: Fredrik Hallenberg <megahallon(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c @@ -38,6 +38,7 @@ static u32 stmmac_config_sub_second_incr { u32 value = readl(ioaddr + PTP_TCR); unsigned long data; + u32 reg_value; /* For GMAC3.x, 4.x versions, convert the ptp_clock to nano second * formula = (1/ptp_clock) * 1000000000 @@ -54,10 +55,11 @@ static u32 stmmac_config_sub_second_incr data &= PTP_SSIR_SSINC_MASK; + reg_value = data; if (gmac4) - data = data << GMAC4_PTP_SSIR_SSINC_SHIFT; + reg_value <<= GMAC4_PTP_SSIR_SSINC_SHIFT; - writel(data, ioaddr + PTP_SSIR); + writel(reg_value, ioaddr + PTP_SSIR); return data; } Patches currently in stable-queue which might be from megahallon(a)gmail.com are queue-4.9/net-stmmac-fix-tx-timestamp-calculation.patch

7 years, 9 months

1
0
0 0

Patch "net: phy: xgene: disable clk on error paths" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: phy: xgene: disable clk on error paths to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-phy-xgene-disable-clk-on-error-paths.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Date: Sat, 16 Dec 2017 00:52:39 +0300 Subject: net: phy: xgene: disable clk on error paths From: Alexey Khoroshilov <khoroshilov(a)ispras.ru> [ Upstream commit ab14436065c8066c265540312742390d6d07ddd2 ] There are several error paths in xgene_mdio_probe(), where clk is left undisabled. The patch fixes them. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/mdio-xgene.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- a/drivers/net/phy/mdio-xgene.c +++ b/drivers/net/phy/mdio-xgene.c @@ -197,8 +197,11 @@ static int xgene_mdio_reset(struct xgene } ret = xgene_enet_ecc_init(pdata); - if (ret) + if (ret) { + if (pdata->dev->of_node) + clk_disable_unprepare(pdata->clk); return ret; + } xgene_gmac_reset(pdata); return 0; @@ -364,8 +367,10 @@ static int xgene_mdio_probe(struct platf return ret; mdio_bus = mdiobus_alloc(); - if (!mdio_bus) - return -ENOMEM; + if (!mdio_bus) { + ret = -ENOMEM; + goto out_clk; + } mdio_bus->name = "APM X-Gene MDIO bus"; @@ -394,7 +399,7 @@ static int xgene_mdio_probe(struct platf mdio_bus->phy_mask = ~0; ret = mdiobus_register(mdio_bus); if (ret) - goto out; + goto out_mdiobus; acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_HANDLE(dev), 1, acpi_register_phy, NULL, mdio_bus, NULL); @@ -402,16 +407,20 @@ static int xgene_mdio_probe(struct platf } if (ret) - goto out; + goto out_mdiobus; pdata->mdio_bus = mdio_bus; xgene_mdio_status = true; return 0; -out: +out_mdiobus: mdiobus_free(mdio_bus); +out_clk: + if (dev->of_node) + clk_disable_unprepare(pdata->clk); + return ret; } Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are queue-4.9/net-phy-xgene-disable-clk-on-error-paths.patch

7 years, 9 months

1
0
0 0

Patch "net: mediatek: setup proper state for disabled GMAC on the default" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: mediatek: setup proper state for disabled GMAC on the default to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-mediatek-setup-proper-state-for-disabled-gmac-on-the-default.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Sean Wang <sean.wang(a)mediatek.com> Date: Mon, 18 Dec 2017 17:00:17 +0800 Subject: net: mediatek: setup proper state for disabled GMAC on the default From: Sean Wang <sean.wang(a)mediatek.com> [ Upstream commit 7352e252b5bf40d59342494a70354a2d436fd0cd ] The current solution would setup fixed and force link of 1Gbps to the both GMAC on the default. However, The GMAC should always be put to link down state when the GMAC is disabled on certain target boards. Otherwise, the driver possibly receives unexpected data from the floating hardware connection through the unused GMAC. Although the driver had been added certain protection in RX path to get rid of such kind of unexpected data sent to the upper stack. Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c +++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c @@ -1842,11 +1842,12 @@ static int mtk_hw_init(struct mtk_eth *e /* set GE2 TUNE */ regmap_write(eth->pctl, GPIO_BIAS_CTRL, 0x0); - /* GE1, Force 1000M/FD, FC ON */ - mtk_w32(eth, MAC_MCR_FIXED_LINK, MTK_MAC_MCR(0)); - - /* GE2, Force 1000M/FD, FC ON */ - mtk_w32(eth, MAC_MCR_FIXED_LINK, MTK_MAC_MCR(1)); + /* Set linkdown as the default for each GMAC. Its own MCR would be set + * up with the more appropriate value when mtk_phy_link_adjust call is + * being invoked. + */ + for (i = 0; i < MTK_MAC_COUNT; i++) + mtk_w32(eth, 0, MTK_MAC_MCR(i)); /* Enable RX VLan Offloading */ mtk_w32(eth, 1, MTK_CDMP_EG_CTRL); Patches currently in stable-queue which might be from sean.wang(a)mediatek.com are queue-4.9/net-mediatek-setup-proper-state-for-disabled-gmac-on-the-default.patch

7 years, 9 months

1
0
0 0

Patch "net: gianfar_ptp: move set_fipers() to spinlock protecting area" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: gianfar_ptp: move set_fipers() to spinlock protecting area to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Yangbo Lu <yangbo.lu(a)nxp.com> Date: Tue, 9 Jan 2018 11:02:33 +0800 Subject: net: gianfar_ptp: move set_fipers() to spinlock protecting area From: Yangbo Lu <yangbo.lu(a)nxp.com> [ Upstream commit 11d827a993a969c3c6ec56758ff63a44ba19b466 ] set_fipers() calling should be protected by spinlock in case that any interrupt breaks related registers setting and the function we expect. This patch is to move set_fipers() to spinlock protecting area in ptp_gianfar_adjtime(). Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com> Acked-by: Richard Cochran <richardcochran(a)gmail.com> Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/net/ethernet/freescale/gianfar_ptp.c +++ b/drivers/net/ethernet/freescale/gianfar_ptp.c @@ -314,11 +314,10 @@ static int ptp_gianfar_adjtime(struct pt now = tmr_cnt_read(etsects); now += delta; tmr_cnt_write(etsects, now); + set_fipers(etsects); spin_unlock_irqrestore(&etsects->lock, flags); - set_fipers(etsects); - return 0; } Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are queue-4.9/net-gianfar_ptp-move-set_fipers-to-spinlock-protecting-area.patch

7 years, 9 months

1
0
0 0

Patch "net: arc_emac: fix arc_emac_rx() error paths" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled net: arc_emac: fix arc_emac_rx() error paths to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: net-arc_emac-fix-arc_emac_rx-error-paths.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Alexander Kochetkov <al.kochet(a)gmail.com> Date: Fri, 15 Dec 2017 20:20:06 +0300 Subject: net: arc_emac: fix arc_emac_rx() error paths From: Alexander Kochetkov <al.kochet(a)gmail.com> [ Upstream commit e688822d035b494071ecbadcccbd6f3325fb0f59 ] arc_emac_rx() has some issues found by code review. In case netdev_alloc_skb_ip_align() or dma_map_single() failure rx fifo entry will not be returned to EMAC. In case dma_map_single() failure previously allocated skb became lost to driver. At the same time address of newly allocated skb will not be provided to EMAC. Signed-off-by: Alexander Kochetkov <al.kochet(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++++++++++--------------- 1 file changed, 31 insertions(+), 22 deletions(-) --- a/drivers/net/ethernet/arc/emac_main.c +++ b/drivers/net/ethernet/arc/emac_main.c @@ -210,39 +210,48 @@ static int arc_emac_rx(struct net_device continue; } - pktlen = info & LEN_MASK; - stats->rx_packets++; - stats->rx_bytes += pktlen; - skb = rx_buff->skb; - skb_put(skb, pktlen); - skb->dev = ndev; - skb->protocol = eth_type_trans(skb, ndev); - - dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr), - dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE); - - /* Prepare the BD for next cycle */ - rx_buff->skb = netdev_alloc_skb_ip_align(ndev, - EMAC_BUFFER_SIZE); - if (unlikely(!rx_buff->skb)) { + /* Prepare the BD for next cycle. netif_receive_skb() + * only if new skb was allocated and mapped to avoid holes + * in the RX fifo. + */ + skb = netdev_alloc_skb_ip_align(ndev, EMAC_BUFFER_SIZE); + if (unlikely(!skb)) { + if (net_ratelimit()) + netdev_err(ndev, "cannot allocate skb\n"); + /* Return ownership to EMAC */ + rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE); stats->rx_errors++; - /* Because receive_skb is below, increment rx_dropped */ stats->rx_dropped++; continue; } - /* receive_skb only if new skb was allocated to avoid holes */ - netif_receive_skb(skb); - - addr = dma_map_single(&ndev->dev, (void *)rx_buff->skb->data, + addr = dma_map_single(&ndev->dev, (void *)skb->data, EMAC_BUFFER_SIZE, DMA_FROM_DEVICE); if (dma_mapping_error(&ndev->dev, addr)) { if (net_ratelimit()) - netdev_err(ndev, "cannot dma map\n"); - dev_kfree_skb(rx_buff->skb); + netdev_err(ndev, "cannot map dma buffer\n"); + dev_kfree_skb(skb); + /* Return ownership to EMAC */ + rxbd->info = cpu_to_le32(FOR_EMAC | EMAC_BUFFER_SIZE); stats->rx_errors++; + stats->rx_dropped++; continue; } + + /* unmap previosly mapped skb */ + dma_unmap_single(&ndev->dev, dma_unmap_addr(rx_buff, addr), + dma_unmap_len(rx_buff, len), DMA_FROM_DEVICE); + + pktlen = info & LEN_MASK; + stats->rx_packets++; + stats->rx_bytes += pktlen; + skb_put(rx_buff->skb, pktlen); + rx_buff->skb->dev = ndev; + rx_buff->skb->protocol = eth_type_trans(rx_buff->skb, ndev); + + netif_receive_skb(rx_buff->skb); + + rx_buff->skb = skb; dma_unmap_addr_set(rx_buff, addr, addr); dma_unmap_len_set(rx_buff, len, EMAC_BUFFER_SIZE); Patches currently in stable-queue which might be from al.kochet(a)gmail.com are queue-4.9/net-arc_emac-fix-arc_emac_rx-error-paths.patch

7 years, 9 months

1
0
0 0

Patch "mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Sascha Hauer <s.hauer(a)pengutronix.de> Date: Tue, 5 Dec 2017 11:51:40 +0100 Subject: mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM From: Sascha Hauer <s.hauer(a)pengutronix.de> [ Upstream commit fdf2e821052958a114618a95ab18a300d0b080cb ] When erased subpages are read then the BCH decoder returns STATUS_ERASED if they are all empty, or STATUS_UNCORRECTABLE if there are bitflips. When there are bitflips, we have to set these bits again to show the upper layers a completely erased page. When a bitflip happens in the exact byte where the bad block marker is, then this byte is swapped with another byte in block_mark_swapping(). The correction code then detects a bitflip in another subpage and no longer corrects the bitflip where it really happens. Correct this behaviour by calling block_mark_swapping() after the bitflips have been corrected. In our case UBIFS failed with this bug because it expects erased pages to be really empty: UBIFS error (pid 187): ubifs_scan: corrupt empty space at LEB 36:118735 UBIFS error (pid 187): ubifs_scanned_corruption: corruption at LEB 36:118735 UBIFS error (pid 187): ubifs_scanned_corruption: first 8192 bytes from LEB 36:118735 UBIFS error (pid 187): ubifs_scan: LEB 36 scanning failed UBIFS error (pid 187): do_commit: commit failed, error -117 Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> Reviewed-by: Richard Weinberger <richard(a)nod.at> Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/mtd/nand/gpmi-nand/gpmi-nand.c +++ b/drivers/mtd/nand/gpmi-nand/gpmi-nand.c @@ -1059,9 +1059,6 @@ static int gpmi_ecc_read_page(struct mtd return ret; } - /* handle the block mark swapping */ - block_mark_swapping(this, payload_virt, auxiliary_virt); - /* Loop over status bytes, accumulating ECC status. */ status = auxiliary_virt + nfc_geo->auxiliary_status_offset; @@ -1150,6 +1147,9 @@ static int gpmi_ecc_read_page(struct mtd max_bitflips = max_t(unsigned int, max_bitflips, *status); } + /* handle the block mark swapping */ + block_mark_swapping(this, buf, auxiliary_virt); + if (oob_required) { /* * It's time to deliver the OOB bytes. See gpmi_ecc_read_oob() Patches currently in stable-queue which might be from s.hauer(a)pengutronix.de are queue-4.9/mtd-nand-gpmi-fix-failure-when-a-erased-page-has-a-bitflip-at-bbm.patch

7 years, 9 months

1
0
0 0

Patch "mtd: nand: brcmnand: Zero bitflip is not an error" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mtd: nand: brcmnand: Zero bitflip is not an error to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mtd-nand-brcmnand-zero-bitflip-is-not-an-error.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Albert Hsieh <wen.hsieh(a)broadcom.com> Date: Mon, 20 Nov 2017 11:26:26 +0800 Subject: mtd: nand: brcmnand: Zero bitflip is not an error From: Albert Hsieh <wen.hsieh(a)broadcom.com> [ Upstream commit e44b9a9c135727f3410e029910275f40681dc8bc ] A negative return value of brcmstb_nand_verify_erased_page() indicates a real bitflip error of an erased page, and other return values (>= 0) show the corrected bitflip number. Zero return value means no bitflip, but the current driver code treats it as an error, and eventually leads to falsely reported ECC error. Fixes: 02b88eea9f9c ("mtd: brcmnand: Add check for erased page bitflip") Signed-off-by: Albert Hsieh <wen.hsieh(a)broadcom.com> Acked-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> Signed-off-by: Richard Weinberger <richard(a)nod.at> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mtd/nand/brcmnand/brcmnand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/mtd/nand/brcmnand/brcmnand.c +++ b/drivers/mtd/nand/brcmnand/brcmnand.c @@ -1763,7 +1763,7 @@ try_dmaread: err = brcmstb_nand_verify_erased_page(mtd, chip, buf, addr); /* erased page bitflips corrected */ - if (err > 0) + if (err >= 0) return err; } Patches currently in stable-queue which might be from wen.hsieh(a)broadcom.com are queue-4.9/mtd-nand-brcmnand-zero-bitflip-is-not-an-error.patch

7 years, 9 months

1
0
0 0

Patch "mdio-sun4i: Fix a memory leak" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mdio-sun4i: Fix a memory leak to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mdio-sun4i-fix-a-memory-leak.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Sat, 6 Jan 2018 09:00:09 +0100 Subject: mdio-sun4i: Fix a memory leak From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 56c0290202ab94a2f2780c449395d4ae8495fab4 ] If the probing of the regulator is deferred, the memory allocated by 'mdiobus_alloc_size()' will be leaking. It should be freed before the next call to 'sun4i_mdio_probe()' which will reallocate it. Fixes: 4bdcb1dd9feb ("net: Add MDIO bus driver for the Allwinner EMAC") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/phy/mdio-sun4i.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/phy/mdio-sun4i.c +++ b/drivers/net/phy/mdio-sun4i.c @@ -118,8 +118,10 @@ static int sun4i_mdio_probe(struct platf data->regulator = devm_regulator_get(&pdev->dev, "phy"); if (IS_ERR(data->regulator)) { - if (PTR_ERR(data->regulator) == -EPROBE_DEFER) - return -EPROBE_DEFER; + if (PTR_ERR(data->regulator) == -EPROBE_DEFER) { + ret = -EPROBE_DEFER; + goto err_out_free_mdiobus; + } dev_info(&pdev->dev, "no regulator found\n"); data->regulator = NULL; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/mdio-sun4i-fix-a-memory-leak.patch

7 years, 9 months

1
0
0 0

Patch "macvlan: Fix one possible double free" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled macvlan: Fix one possible double free to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: macvlan-fix-one-possible-double-free.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Gao Feng <gfree.wind(a)vip.163.com> Date: Tue, 26 Dec 2017 21:44:32 +0800 Subject: macvlan: Fix one possible double free From: Gao Feng <gfree.wind(a)vip.163.com> [ Upstream commit d02fd6e7d2933ede6478a15f9e4ce8a93845824e ] Because the macvlan_uninit would free the macvlan port, so there is one double free case in macvlan_common_newlink. When the macvlan port is just created, then register_netdevice or netdev_upper_dev_link failed and they would invoke macvlan_uninit. Then it would reach the macvlan_port_destroy which triggers the double free. Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/macvlan.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -1377,9 +1377,14 @@ int macvlan_common_newlink(struct net *s return 0; unregister_netdev: + /* macvlan_uninit would free the macvlan port */ unregister_netdevice(dev); + return err; destroy_macvlan_port: - if (create) + /* the macvlan port may be freed by macvlan_uninit when fail to register. + * so we destroy the macvlan port only when it's valid. + */ + if (create && macvlan_port_get_rtnl(dev)) macvlan_port_destroy(port->dev); return err; } Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are queue-4.9/macvlan-fix-one-possible-double-free.patch

7 years, 9 months

1
0
0 0

Patch "mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Jia-Ju Bai <baijiaju1990(a)163.com> Date: Tue, 12 Dec 2017 17:26:36 +0800 Subject: mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl From: Jia-Ju Bai <baijiaju1990(a)163.com> [ Upstream commit 162bd5e5fd921785077b5862d8f2ffabe2fe11e5 ] The driver may sleep under a spinlock. The function call path is: hwsim_get_radio_nl (acquire the spinlock) nlmsg_new(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool(DSAC) and checked by my code review. Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/mac80211_hwsim.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/wireless/mac80211_hwsim.c +++ b/drivers/net/wireless/mac80211_hwsim.c @@ -3154,7 +3154,7 @@ static int hwsim_get_radio_nl(struct sk_ if (!net_eq(wiphy_net(data->hw->wiphy), genl_info_net(info))) continue; - skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL); + skb = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_ATOMIC); if (!skb) { res = -ENOMEM; goto out_err; Patches currently in stable-queue which might be from baijiaju1990(a)163.com are queue-4.9/mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch

7 years, 9 months

1
0
0 0

Patch "mac80211: mesh: drop frames appearing to be from us" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: mesh: drop frames appearing to be from us to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-mesh-drop-frames-appearing-to-be-from-us.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Johannes Berg <johannes.berg(a)intel.com> Date: Thu, 4 Jan 2018 15:51:53 +0100 Subject: mac80211: mesh: drop frames appearing to be from us From: Johannes Berg <johannes.berg(a)intel.com> [ Upstream commit 736a80bbfda709fb3631f5f62056f250a38e5804 ] If there are multiple mesh stations with the same MAC address, they will both get confused and start throwing warnings. Obviously in this case nothing can actually work anyway, so just drop frames that look like they're from ourselves early on. Reported-by: Gui Iribarren <gui(a)altermundi.net> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/rx.c | 2 ++ 1 file changed, 2 insertions(+) --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3611,6 +3611,8 @@ static bool ieee80211_accept_frame(struc } return true; case NL80211_IFTYPE_MESH_POINT: + if (ether_addr_equal(sdata->vif.addr, hdr->addr2)) + return false; if (multicast) return true; return ether_addr_equal(sdata->vif.addr, hdr->addr1); Patches currently in stable-queue which might be from johannes.berg(a)intel.com are queue-4.9/mac80211_hwsim-fix-a-possible-sleep-in-atomic-bug-in-hwsim_get_radio_nl.patch queue-4.9/nl80211-check-for-the-required-netlink-attribute-presence.patch queue-4.9/mac80211-mesh-drop-frames-appearing-to-be-from-us.patch

7 years, 9 months

1
0
0 0

Patch "lib/mpi: Fix umul_ppmm() for MIPS64r6" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lib/mpi: Fix umul_ppmm() for MIPS64r6 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lib-mpi-fix-umul_ppmm-for-mips64r6.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: James Hogan <jhogan(a)kernel.org> Date: Tue, 5 Dec 2017 23:31:35 +0000 Subject: lib/mpi: Fix umul_ppmm() for MIPS64r6 From: James Hogan <jhogan(a)kernel.org> [ Upstream commit bbc25bee37d2b32cf3a1fab9195b6da3a185614a ] Current MIPS64r6 toolchains aren't able to generate efficient DMULU/DMUHU based code for the C implementation of umul_ppmm(), which performs an unsigned 64 x 64 bit multiply and returns the upper and lower 64-bit halves of the 128-bit result. Instead it widens the 64-bit inputs to 128-bits and emits a __multi3 intrinsic call to perform a 128 x 128 multiply. This is both inefficient, and it results in a link error since we don't include __multi3 in MIPS linux. For example commit 90a53e4432b1 ("cfg80211: implement regdb signature checking") merged in v4.15-rc1 recently broke the 64r6_defconfig and 64r6el_defconfig builds by indirectly selecting MPILIB. The same build errors can be reproduced on older kernels by enabling e.g. CRYPTO_RSA: lib/mpi/generic_mpih-mul1.o: In function `mpihelp_mul_1': lib/mpi/generic_mpih-mul1.c:50: undefined reference to `__multi3' lib/mpi/generic_mpih-mul2.o: In function `mpihelp_addmul_1': lib/mpi/generic_mpih-mul2.c:49: undefined reference to `__multi3' lib/mpi/generic_mpih-mul3.o: In function `mpihelp_submul_1': lib/mpi/generic_mpih-mul3.c:49: undefined reference to `__multi3' lib/mpi/mpih-div.o In function `mpihelp_divrem': lib/mpi/mpih-div.c:205: undefined reference to `__multi3' lib/mpi/mpih-div.c:142: undefined reference to `__multi3' Therefore add an efficient MIPS64r6 implementation of umul_ppmm() using inline assembly and the DMULU/DMUHU instructions, to prevent __multi3 calls being emitted. Fixes: 7fd08ca58ae6 ("MIPS: Add build support for the MIPS R6 ISA") Signed-off-by: James Hogan <jhogan(a)kernel.org> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: "David S. Miller" <davem(a)davemloft.net> Cc: linux-mips(a)linux-mips.org Cc: linux-crypto(a)vger.kernel.org Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/mpi/longlong.h | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/lib/mpi/longlong.h +++ b/lib/mpi/longlong.h @@ -671,7 +671,23 @@ do { \ ************** MIPS/64 ************** ***************************************/ #if (defined(__mips) && __mips >= 3) && W_TYPE_SIZE == 64 -#if (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4) +#if defined(__mips_isa_rev) && __mips_isa_rev >= 6 +/* + * GCC ends up emitting a __multi3 intrinsic call for MIPS64r6 with the plain C + * code below, so we special case MIPS64r6 until the compiler can do better. + */ +#define umul_ppmm(w1, w0, u, v) \ +do { \ + __asm__ ("dmulu %0,%1,%2" \ + : "=d" ((UDItype)(w0)) \ + : "d" ((UDItype)(u)), \ + "d" ((UDItype)(v))); \ + __asm__ ("dmuhu %0,%1,%2" \ + : "=d" ((UDItype)(w1)) \ + : "d" ((UDItype)(u)), \ + "d" ((UDItype)(v))); \ +} while (0) +#elif (__GNUC__ >= 5) || (__GNUC__ >= 4 && __GNUC_MINOR__ >= 4) #define umul_ppmm(w1, w0, u, v) \ do { \ typedef unsigned int __ll_UTItype __attribute__((mode(TI))); \ Patches currently in stable-queue which might be from jhogan(a)kernel.org are queue-4.9/lib-mpi-fix-umul_ppmm-for-mips64r6.patch

7 years, 9 months

1
0
0 0

Patch "ipv6: icmp6: Allow icmp messages to be looped back" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipv6: icmp6: Allow icmp messages to be looped back to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipv6-icmp6-allow-icmp-messages-to-be-looped-back.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Brendan McGrath <redmcg(a)redmandi.dyndns.org> Date: Wed, 13 Dec 2017 22:14:57 +1100 Subject: ipv6: icmp6: Allow icmp messages to be looped back From: Brendan McGrath <redmcg(a)redmandi.dyndns.org> [ Upstream commit 588753f1eb18978512b1c9b85fddb457d46f9033 ] One example of when an ICMPv6 packet is required to be looped back is when a host acts as both a Multicast Listener and a Multicast Router. A Multicast Router will listen on address ff02::16 for MLDv2 messages. Currently, MLDv2 messages originating from a Multicast Listener running on the same host as the Multicast Router are not being delivered to the Multicast Router. This is due to dst.input being assigned the default value of dst_discard. This results in the packet being looped back but discarded before being delivered to the Multicast Router. This patch sets dst.input to ip6_input to ensure a looped back packet is delivered to the Multicast Router. Signed-off-by: Brendan McGrath <redmcg(a)redmandi.dyndns.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/route.c | 1 + 1 file changed, 1 insertion(+) --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -1651,6 +1651,7 @@ struct dst_entry *icmp6_dst_alloc(struct } rt->dst.flags |= DST_HOST; + rt->dst.input = ip6_input; rt->dst.output = ip6_output; atomic_set(&rt->dst.__refcnt, 1); rt->rt6i_gateway = fl6->daddr; Patches currently in stable-queue which might be from redmcg(a)redmandi.dyndns.org are queue-4.9/ipv6-icmp6-allow-icmp-messages-to-be-looped-back.patch

7 years, 9 months

1
0
0 0

Patch "led: core: Fix brightness setting when setting delay_off=0" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled led: core: Fix brightness setting when setting delay_off=0 to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: led-core-fix-brightness-setting-when-setting-delay_off-0.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Matthieu CASTET <matthieu.castet(a)parrot.com> Date: Tue, 12 Dec 2017 11:10:44 +0100 Subject: led: core: Fix brightness setting when setting delay_off=0 From: Matthieu CASTET <matthieu.castet(a)parrot.com> [ Upstream commit 2b83ff96f51d0b039c4561b9f95c824d7bddb85c ] With the current code, the following sequence won't work : echo timer > trigger echo 0 > delay_off * at this point we call ** led_delay_off_store ** led_blink_set --- drivers/leds/led-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/leds/led-core.c +++ b/drivers/leds/led-core.c @@ -186,7 +186,7 @@ void led_blink_set(struct led_classdev * unsigned long *delay_on, unsigned long *delay_off) { - del_timer_sync(&led_cdev->blink_timer); + led_stop_software_blink(led_cdev); led_cdev->flags &= ~LED_BLINK_ONESHOT; led_cdev->flags &= ~LED_BLINK_ONESHOT_STOP; Patches currently in stable-queue which might be from matthieu.castet(a)parrot.com are queue-4.9/led-core-fix-brightness-setting-when-setting-delay_off-0.patch

7 years, 9 months

1
0
0 0

Patch "ip6_tunnel: get the min mtu properly in ip6_tnl_xmit" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ip6_tunnel: get the min mtu properly in ip6_tnl_xmit to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Xin Long <lucien.xin(a)gmail.com> Date: Mon, 18 Dec 2017 14:26:21 +0800 Subject: ip6_tunnel: get the min mtu properly in ip6_tnl_xmit From: Xin Long <lucien.xin(a)gmail.com> [ Upstream commit c9fefa08190fc879fb2e681035d7774e0a8c5170 ] Now it's using IPV6_MIN_MTU as the min mtu in ip6_tnl_xmit, but IPV6_MIN_MTU actually only works when the inner packet is ipv6. With IPV6_MIN_MTU for ipv4 packets, the new pmtu for inner dst couldn't be set less than 1280. It would cause tx_err and the packet to be dropped when the outer dst pmtu is close to 1280. Jianlin found it by running ipv4 traffic with the topo: (client) gre6 <---> eth1 (route) eth2 <---> gre6 (server) After changing eth2 mtu to 1300, the performance became very low, or the connection was even broken. The issue also affects ip4ip6 and ip6ip6 tunnels. So if the inner packet is ipv4, 576 should be considered as the min mtu. Note that for ip4ip6 and ip6ip6 tunnels, the inner packet can only be ipv4 or ipv6, but for gre6 tunnel, it may also be ARP. This patch using 576 as the min mtu for non-ipv6 packet works for all those cases. Reported-by: Jianlin Shi <jishi(a)redhat.com> Signed-off-by: Xin Long <lucien.xin(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/ipv6/ip6_tunnel.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1127,8 +1127,13 @@ route_lookup: max_headroom += 8; mtu -= 8; } - if (mtu < IPV6_MIN_MTU) - mtu = IPV6_MIN_MTU; + if (skb->protocol == htons(ETH_P_IPV6)) { + if (mtu < IPV6_MIN_MTU) + mtu = IPV6_MIN_MTU; + } else if (mtu < 576) { + mtu = 576; + } + if (skb_dst(skb) && !t->parms.collect_md) skb_dst(skb)->ops->update_pmtu(skb_dst(skb), NULL, skb, mtu); if (skb->len - t->tun_hlen - eth_hlen > mtu && !skb_is_gso(skb)) { Patches currently in stable-queue which might be from lucien.xin(a)gmail.com are queue-4.9/ip6_tunnel-get-the-min-mtu-properly-in-ip6_tnl_xmit.patch

7 years, 9 months

1
0
0 0

Patch "IB/mlx5: Fix mlx5_ib_alloc_mr error flow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx5: Fix mlx5_ib_alloc_mr error flow to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Nitzan Carmi <nitzanc(a)mellanox.com> Date: Tue, 26 Dec 2017 11:20:20 +0200 Subject: IB/mlx5: Fix mlx5_ib_alloc_mr error flow From: Nitzan Carmi <nitzanc(a)mellanox.com> [ Upstream commit 45e6ae7ef21b907dacb18da62d5787d74a31d860 ] ibmr.device is being set only after ib_alloc_mr() is (successfully) complete. Therefore, in case mlx5_core_create_mkey() return with error, the error flow calls mlx5_free_priv_descs() which uses ibmr.device (which doesn't exist yet), causing a NULL dereference oops. To fix this, the IB device should be set in the mr struct earlier stage (e.g. prior to calling mlx5_core_create_mkey()). Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API") Signed-off-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx5/mr.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -1648,6 +1648,7 @@ struct ib_mr *mlx5_ib_alloc_mr(struct ib MLX5_SET(mkc, mkc, access_mode, mr->access_mode); MLX5_SET(mkc, mkc, umr_en, 1); + mr->ibmr.device = pd->device; err = mlx5_core_create_mkey(dev->mdev, &mr->mmkey, in, inlen); if (err) goto err_destroy_psv; Patches currently in stable-queue which might be from nitzanc(a)mellanox.com are queue-4.9/ib-mlx5-fix-mlx5_ib_alloc_mr-error-flow.patch queue-4.9/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch

7 years, 9 months

1
0
0 0

Patch "IB/mlx4: Fix mlx4_ib_alloc_mr error flow" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/mlx4: Fix mlx4_ib_alloc_mr error flow to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Leon Romanovsky <leonro(a)mellanox.com> Date: Sun, 31 Dec 2017 15:33:14 +0200 Subject: IB/mlx4: Fix mlx4_ib_alloc_mr error flow From: Leon Romanovsky <leonro(a)mellanox.com> [ Upstream commit 5a371cf87e145b86efd32007e46146e78c1eff6d ] ibmr.device is being set only after ib_alloc_mr() is successfully complete. Therefore, in case imlx4_mr_enable() returns with error, the error flow unwinder calls to mlx4_free_priv_pages(), which uses ibmr.device. Such usage causes to NULL dereference oops and to fix it, the IB device should be set in the mr struct earlier stage (e.g. prior to calling mlx4_free_priv_pages()). Fixes: 1b2cd0fc673c ("IB/mlx4: Support the new memory registration API") Signed-off-by: Nitzan Carmi <nitzanc(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/hw/mlx4/mr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/infiniband/hw/mlx4/mr.c +++ b/drivers/infiniband/hw/mlx4/mr.c @@ -406,7 +406,6 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib goto err_free_mr; mr->max_pages = max_num_sg; - err = mlx4_mr_enable(dev->dev, &mr->mmr); if (err) goto err_free_pl; @@ -417,6 +416,7 @@ struct ib_mr *mlx4_ib_alloc_mr(struct ib return &mr->ibmr; err_free_pl: + mr->ibmr.device = pd->device; mlx4_free_priv_pages(mr); err_free_mr: (void) mlx4_mr_free(dev->dev, &mr->mmr); Patches currently in stable-queue which might be from leonro(a)mellanox.com are queue-4.9/ib-mlx4-fix-mlx4_ib_alloc_mr-error-flow.patch

7 years, 9 months

1
0
0 0

Patch "IB/ipoib: Fix race condition in neigh creation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled IB/ipoib: Fix race condition in neigh creation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ib-ipoib-fix-race-condition-in-neigh-creation.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Erez Shitrit <erezsh(a)mellanox.com> Date: Sun, 31 Dec 2017 15:33:15 +0200 Subject: IB/ipoib: Fix race condition in neigh creation From: Erez Shitrit <erezsh(a)mellanox.com> [ Upstream commit 16ba3defb8bd01a9464ba4820a487f5b196b455b ] When using enhanced mode for IPoIB, two threads may execute xmit in parallel to two different TX queues while the target is the same. In this case, both of them will add the same neighbor to the path's neigh link list and we might see the following message: list_add double add: new=ffff88024767a348, prev=ffff88024767a348... WARNING: lib/list_debug.c:31__list_add_valid+0x4e/0x70 ipoib_start_xmit+0x477/0x680 [ib_ipoib] dev_hard_start_xmit+0xb9/0x3e0 sch_direct_xmit+0xf9/0x250 __qdisc_run+0x176/0x5d0 __dev_queue_xmit+0x1f5/0xb10 __dev_queue_xmit+0x55/0xb10 Analysis: Two SKB are scheduled to be transmitted from two cores. In ipoib_start_xmit, both gets NULL when calling ipoib_neigh_get. Two calls to neigh_add_path are made. One thread takes the spin-lock and calls ipoib_neigh_alloc which creates the neigh structure, then (after the __path_find) the neigh is added to the path's neigh link list. When the second thread enters the critical section it also calls ipoib_neigh_alloc but in this case it gets the already allocated ipoib_neigh structure, which is already linked to the path's neigh link list and adds it again to the list. Which beside of triggering the list, it creates a loop in the linked list. This loop leads to endless loop inside path_rec_completion. Solution: Check list_empty(&neigh->list) before adding to the list. Add a similar fix in "ipoib_multicast.c::ipoib_mcast_send" Fixes: b63b70d87741 ('IPoIB: Use a private hash table for path lookup in xmit path') Signed-off-by: Erez Shitrit <erezsh(a)mellanox.com> Reviewed-by: Alex Vesker <valex(a)mellanox.com> Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 ++++++++++++++++++------- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 ++++- 2 files changed, 22 insertions(+), 8 deletions(-) --- a/drivers/infiniband/ulp/ipoib/ipoib_main.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_main.c @@ -919,8 +919,8 @@ static int path_rec_start(struct net_dev return 0; } -static void neigh_add_path(struct sk_buff *skb, u8 *daddr, - struct net_device *dev) +static struct ipoib_neigh *neigh_add_path(struct sk_buff *skb, u8 *daddr, + struct net_device *dev) { struct ipoib_dev_priv *priv = netdev_priv(dev); struct ipoib_path *path; @@ -933,7 +933,15 @@ static void neigh_add_path(struct sk_buf spin_unlock_irqrestore(&priv->lock, flags); ++dev->stats.tx_dropped; dev_kfree_skb_any(skb); - return; + return NULL; + } + + /* To avoid race condition, make sure that the + * neigh will be added only once. + */ + if (unlikely(!list_empty(&neigh->list))) { + spin_unlock_irqrestore(&priv->lock, flags); + return neigh; } path = __path_find(dev, daddr + 4); @@ -971,7 +979,7 @@ static void neigh_add_path(struct sk_buf spin_unlock_irqrestore(&priv->lock, flags); ipoib_send(dev, skb, path->ah, IPOIB_QPN(daddr)); ipoib_neigh_put(neigh); - return; + return NULL; } } else { neigh->ah = NULL; @@ -988,7 +996,7 @@ static void neigh_add_path(struct sk_buf spin_unlock_irqrestore(&priv->lock, flags); ipoib_neigh_put(neigh); - return; + return NULL; err_path: ipoib_neigh_free(neigh); @@ -998,6 +1006,8 @@ err_drop: spin_unlock_irqrestore(&priv->lock, flags); ipoib_neigh_put(neigh); + + return NULL; } static void unicast_arp_send(struct sk_buff *skb, struct net_device *dev, @@ -1103,8 +1113,9 @@ static int ipoib_start_xmit(struct sk_bu case htons(ETH_P_TIPC): neigh = ipoib_neigh_get(dev, phdr->hwaddr); if (unlikely(!neigh)) { - neigh_add_path(skb, phdr->hwaddr, dev); - return NETDEV_TX_OK; + neigh = neigh_add_path(skb, phdr->hwaddr, dev); + if (likely(!neigh)) + return NETDEV_TX_OK; } break; case htons(ETH_P_ARP): --- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c @@ -818,7 +818,10 @@ void ipoib_mcast_send(struct net_device spin_lock_irqsave(&priv->lock, flags); if (!neigh) { neigh = ipoib_neigh_alloc(daddr, dev); - if (neigh) { + /* Make sure that the neigh will be added only + * once to mcast list. + */ + if (neigh && list_empty(&neigh->list)) { kref_get(&mcast->ah->ref); neigh->ah = mcast->ah; list_add_tail(&neigh->list, &mcast->neigh_list); Patches currently in stable-queue which might be from erezsh(a)mellanox.com are queue-4.9/ib-ipoib-fix-race-condition-in-neigh-creation.patch

7 years, 9 months

1
0
0 0

Patch "i40e/i40evf: Account for frags split over multiple descriptors in check linearize" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled i40e/i40evf: Account for frags split over multiple descriptors in check linearize to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Wed Feb 28 16:13:29 CET 2018 From: Alexander Duyck <alexander.h.duyck(a)intel.com> Date: Fri, 8 Dec 2017 10:55:04 -0800 Subject: i40e/i40evf: Account for frags split over multiple descriptors in check linearize From: Alexander Duyck <alexander.h.duyck(a)intel.com> [ Upstream commit 248de22e638f10bd5bfc7624a357f940f66ba137 ] The original code for __i40e_chk_linearize didn't take into account the fact that if a fragment is 16K in size or larger it has to be split over 2 descriptors and the smaller of those 2 descriptors will be on the trailing edge of the transmit. As a result we can get into situations where we didn't catch requests that could result in a Tx hang. This patch takes care of that by subtracting the length of all but the trailing edge of the stale fragment before we test for sum. By doing this we can guarantee that we have all cases covered, including the case of a fragment that spans multiple descriptors. We don't need to worry about checking the inner portions of this since 12K is the maximum aligned DMA size and that is larger than any MSS will ever be since the MTU limit for jumbos is something on the order of 9K. Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 +++++++++++++++++++++++--- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 +++++++++++++++++++++++--- 2 files changed, 46 insertions(+), 6 deletions(-) --- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c @@ -2670,10 +2670,30 @@ bool __i40e_chk_linearize(struct sk_buff /* Walk through fragments adding latest fragment, testing it, and * then removing stale fragments from the sum. */ - stale = &skb_shinfo(skb)->frags[0]; - for (;;) { + for (stale = &skb_shinfo(skb)->frags[0];; stale++) { + int stale_size = skb_frag_size(stale); + sum += skb_frag_size(frag++); + /* The stale fragment may present us with a smaller + * descriptor than the actual fragment size. To account + * for that we need to remove all the data on the front and + * figure out what the remainder would be in the last + * descriptor associated with the fragment. + */ + if (stale_size > I40E_MAX_DATA_PER_TXD) { + int align_pad = -(stale->page_offset) & + (I40E_MAX_READ_REQ_SIZE - 1); + + sum -= align_pad; + stale_size -= align_pad; + + do { + sum -= I40E_MAX_DATA_PER_TXD_ALIGNED; + stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED; + } while (stale_size > I40E_MAX_DATA_PER_TXD); + } + /* if sum is negative we failed to make sufficient progress */ if (sum < 0) return true; @@ -2681,7 +2701,7 @@ bool __i40e_chk_linearize(struct sk_buff if (!nr_frags--) break; - sum -= skb_frag_size(stale++); + sum -= stale_size; } return false; --- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c +++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c @@ -1872,10 +1872,30 @@ bool __i40evf_chk_linearize(struct sk_bu /* Walk through fragments adding latest fragment, testing it, and * then removing stale fragments from the sum. */ - stale = &skb_shinfo(skb)->frags[0]; - for (;;) { + for (stale = &skb_shinfo(skb)->frags[0];; stale++) { + int stale_size = skb_frag_size(stale); + sum += skb_frag_size(frag++); + /* The stale fragment may present us with a smaller + * descriptor than the actual fragment size. To account + * for that we need to remove all the data on the front and + * figure out what the remainder would be in the last + * descriptor associated with the fragment. + */ + if (stale_size > I40E_MAX_DATA_PER_TXD) { + int align_pad = -(stale->page_offset) & + (I40E_MAX_READ_REQ_SIZE - 1); + + sum -= align_pad; + stale_size -= align_pad; + + do { + sum -= I40E_MAX_DATA_PER_TXD_ALIGNED; + stale_size -= I40E_MAX_DATA_PER_TXD_ALIGNED; + } while (stale_size > I40E_MAX_DATA_PER_TXD); + } + /* if sum is negative we failed to make sufficient progress */ if (sum < 0) return true; @@ -1883,7 +1903,7 @@ bool __i40evf_chk_linearize(struct sk_bu if (!nr_frags--) break; - sum -= skb_frag_size(stale++); + sum -= stale_size; } return false; Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are queue-4.9/i40e-i40evf-account-for-frags-split-over-multiple-descriptors-in-check-linearize.patch

7 years, 9 months

1
0
0 0

[GIT PULL] commits for Linux 4.9

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.9 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 331b057d4f3ccf2290e6e651b5728db81e9249c6: Linux 4.9.80 (2018-02-03 17:05:43 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-4.9-23022018 for you to fetch changes up to c7d6e7d081e1943667564c44312888076817af54: net: gianfar_ptp: move set_fipers() to spinlock protecting area (2018-02-03 12:53:00 -0500) - ---------------------------------------------------------------- for-greg-4.9-23022018 - ---------------------------------------------------------------- Abhijeet Kumar (1): ASoC: nau8825: fix issue that pop noise when start capture Al Viro (1): sget(): handle failures of register_shrinker() Albert Hsieh (1): mtd: nand: brcmnand: Zero bitflip is not an error Alexander Duyck (1): i40e/i40evf: Account for frags split over multiple descriptors in check linearize Alexander Kochetkov (1): net: arc_emac: fix arc_emac_rx() error paths Alexey Khoroshilov (1): net: phy: xgene: disable clk on error paths Aliaksei Karaliou (2): xfs: quota: fix missed destroy of qi_tree_lock xfs: quota: check result of register_shrinker() Andreas Platschek (1): dmaengine: fsl-edma: disable clks on all error paths Arnaldo Carvalho de Melo (1): x86/asm: Allow again using asm.h when building for the 'bpf' clang target Arnd Bergmann (1): ARM: dts: ls1021a: fix incorrect clock references Brendan McGrath (1): ipv6: icmp6: Allow icmp messages to be looped back Cathy Avery (1): scsi: storvsc: Fix scsi_cmd error assignments in storvsc_handle_error Christophe JAILLET (1): mdio-sun4i: Fix a memory leak Chunyan Zhang (1): ARM: 8731/1: Fix csum_partial_copy_from_user() stack mismatch Daniele Palmas (1): net: usb: qmi_wwan: add Telit ME910 PID 0x1101 support Eduardo Otubo (1): xen-netfront: enable device after manual module load Erez Shitrit (1): IB/ipoib: Fix race condition in neigh creation Felix Janda (1): uapi libc compat: add fallback for unsupported libcs Fredrik Hallenberg (1): net: stmmac: Fix TX timestamp calculation Gao Feng (1): macvlan: Fix one possible double free Guenter Roeck (1): genirq: Guard handle_bad_irq log messages Guilherme G. Piccoli (1): bnx2x: Improve reliability in case of nested PCI errors Hao Chen (1): nl80211: Check for the required netlink attribute presence James Hogan (1): lib/mpi: Fix umul_ppmm() for MIPS64r6 Jia-Ju Bai (1): mac80211_hwsim: Fix a possible sleep-in-atomic bug in hwsim_get_radio_nl Johannes Berg (1): mac80211: mesh: drop frames appearing to be from us Karol Herbst (1): drm/nouveau/pci: do a msi rearm on init Keith Busch (1): nvme: check hw sectors before setting chunk sectors Leon Romanovsky (1): IB/mlx4: Fix mlx4_ib_alloc_mr error flow Luu An Phu (1): can: flex_can: Correct the checking for frame length in flexcan_start_xmit() Marcelo Ricardo Leitner (1): sctp: make use of pre-calculated len Matthieu CASTET (1): led: core: Fix brightness setting when setting delay_off=0 Nitzan Carmi (1): IB/mlx5: Fix mlx5_ib_alloc_mr error flow Radu Pirea (1): spi: atmel: fixed spin_lock usage inside atmel_spi_remove Ross Lagerwall (2): xen/gntdev: Fix off-by-one error when unmapping with holes xen/gntdev: Fix partial gntdev_mmap() cleanup SZ Lin (林上智) (1): NET: usb: qmi_wwan: add support for YUGA CLM920-NC5 PID 0x9625 Sascha Hauer (1): mtd: nand: gpmi: Fix failure when a erased page has a bitflip at BBM Sean Wang (1): net: mediatek: setup proper state for disabled GMAC on the default Sergei Shtylyov (1): SolutionEngine771x: fix Ether platform data Siva Reddy Kallam (2): tg3: Add workaround to restrict 5762 MRRS to 2048 tg3: Enable PHY reset in MTU change path for 5720 Stefan Haberland (1): s390/dasd: fix wrongly assigned configuration data Tetsuo Handa (1): mm,vmscan: Make unregister_shrinker() no-op if register_shrinker() failed. Tommi Rantala (2): tipc: error path leak fixes in tipc_enable_bearer() tipc: fix tipc_mon_delete() oops in tipc_enable_bearer() error path Tushar Dave (1): e1000: fix disabling already-disabled warning Venkat Duvvuru (1): bnxt_en: Fix the 'Invalid VF' id check in bnxt_vf_ndo_prep routine. Xin Long (1): ip6_tunnel: get the min mtu properly in ip6_tnl_xmit Xiongwei Song (1): drm/ttm: check the return value of kzalloc Yangbo Lu (1): net: gianfar_ptp: move set_fipers() to spinlock protecting area arch/arm/boot/dts/ls1021a-qds.dts | 2 +- arch/arm/boot/dts/ls1021a-twr.dts | 2 +- arch/arm/lib/csumpartialcopyuser.S | 4 ++ arch/sh/boards/mach-se/770x/setup.c | 10 +++- arch/x86/include/asm/asm.h | 2 + drivers/dma/fsl-edma.c | 28 +++++------ drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c | 7 +++ drivers/gpu/drm/ttm/ttm_page_alloc.c | 2 + drivers/infiniband/hw/mlx4/mr.c | 2 +- drivers/infiniband/hw/mlx5/mr.c | 1 + drivers/infiniband/ulp/ipoib/ipoib_main.c | 25 +++++++--- drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 5 +- drivers/leds/led-core.c | 2 +- drivers/mtd/nand/brcmnand/brcmnand.c | 2 +- drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 6 +-- drivers/net/can/flexcan.c | 2 +- drivers/net/ethernet/arc/emac_main.c | 53 ++++++++++++--------- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 4 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 14 +++++- drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +- drivers/net/ethernet/broadcom/tg3.c | 13 ++++- drivers/net/ethernet/broadcom/tg3.h | 4 ++ drivers/net/ethernet/freescale/gianfar_ptp.c | 3 +- drivers/net/ethernet/intel/e1000/e1000.h | 3 +- drivers/net/ethernet/intel/e1000/e1000_main.c | 27 +++++++++-- drivers/net/ethernet/intel/i40e/i40e_txrx.c | 26 ++++++++-- drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 26 ++++++++-- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 11 +++-- .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 6 ++- drivers/net/macvlan.c | 7 ++- drivers/net/phy/mdio-sun4i.c | 6 ++- drivers/net/phy/mdio-xgene.c | 21 ++++++--- drivers/net/usb/qmi_wwan.c | 2 + drivers/net/wireless/mac80211_hwsim.c | 2 +- drivers/net/xen-netfront.c | 1 + drivers/nvme/host/core.c | 3 +- drivers/s390/block/dasd_3990_erp.c | 10 ++++ drivers/scsi/storvsc_drv.c | 3 +- drivers/spi/spi-atmel.c | 2 +- drivers/xen/gntdev.c | 8 ++-- fs/super.c | 6 ++- fs/xfs/xfs_qm.c | 46 +++++++++++------- include/uapi/linux/libc-compat.h | 55 +++++++++++++++++++++- kernel/irq/debug.h | 5 ++ lib/mpi/longlong.h | 18 ++++++- mm/vmscan.c | 3 ++ net/ipv6/ip6_tunnel.c | 9 +++- net/ipv6/route.c | 1 + net/mac80211/rx.c | 2 + net/sctp/socket.c | 16 ++++--- net/tipc/bearer.c | 5 +- net/tipc/monitor.c | 6 ++- net/wireless/nl80211.c | 3 +- sound/soc/codecs/nau8825.c | 1 + 54 files changed, 407 insertions(+), 128 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJakgpcAAoJEN6mb/eXdyzcYeQP/2MlZj2rqiRlWcjceq3kn899 1yFsScoCH/7HqJbOP3gyfT4S+SbXjs55vCYNbKynNeXUFqG7mPk/h1VQxo06qiao oBdhegFByKYr3HkY4BJopPssmofecHi2JT7e1P1Ow+eqIxCQECl5txjkb/oa0t+1 NMbCju60uQlgPtUc/m5qCICzzERKecJPGb5v9xrZ69bEXgfv7+6v9V6F2PsC0SRR tCkuRrQuOyI7y9S8UcL0ECb98mTVVwqNs48VG1yGpt5mSyopgDprdJJvlw0jOzhk 7XtX8eTtxkEt8rs4RSH+aSQxwmFVVWpbGo3fmZLyhIeEQVBLiXcjtT1sRvrPQyXM n68Oy06s8QOXrtRTGE1w3DpfRkB0d2LUeEX7oqpuoOG/ypqunjmHn1E5StDXEH7S xx7fXMkZWplCnFADRWKkAIRkutc1ISbnOI9u+79eQPQu55KBeW3HxX0jxcgQFUb+ qIhzUQM/r94P93xvGSOVMArt8Q+a1RIG1QnH+LdMRCQsQon6QIlokdBpRsQtVHUX vosYNk4kWChL2fF9C8jat0QUZzaqtqiyCKZK2wCDMQPUx7ERyL3wFLkWK/c/LSYk V22R6dGvfRyM+ifug00dZBuP4MTlLFhuQ+Q04afiqC9J1IjM6cXFDbucYmWLrwAr ktgD88//umVLWN6qsizR =Un5c -----END PGP SIGNATURE-----

7 years, 9 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror