This is a note to let you know that I've just added the patch titled
net: hns3: fix a bug when alloc new buffer
to the 4.14-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-hns3-fix-a-bug-when-alloc-new-buffer.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Mon, 23 Oct 2017 19:51:01 +0800
Subject: net: hns3: fix a bug when alloc new buffer
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit b9077428ec5569aacb2952d8a2ffb51c8988d3c2 ]
When alloce new buffer to HW, should unmap the old buffer first.
This old code map the old buffer but not unmap the old buffer,
this patch fixes it.
Fixes: 76ad4f0 (net: hns3: Add support of HNS3 Ethernet Driver for hip08 SoC)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hns3_enet.c
@@ -1586,7 +1586,7 @@ out_buffer_fail:
static void hns3_replace_buffer(struct hns3_enet_ring *ring, int i,
struct hns3_desc_cb *res_cb)
{
- hns3_map_buffer(ring, &ring->desc_cb[i]);
+ hns3_unmap_buffer(ring, &ring->desc_cb[i]);
ring->desc_cb[i] = *res_cb;
ring->desc[i].addr = cpu_to_le64(ring->desc_cb[i].dma);
}
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
This is a note to let you know that I've just added the patch titled
net: hns3: fix a bug in hclge_uninit_client_instance
to the 4.14-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-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Tue, 24 Oct 2017 21:02:11 +0800
Subject: net: hns3: fix a bug in hclge_uninit_client_instance
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit a17dcf3f0124698d1120da71574bf4c339e5a368 ]
HNS3 driver initialize hdev->roce_client and vport->roce.client in
hclge_init_client_instance, and need set hdev->roce_client and
vport->roce.client NULL.
If do not set them NULL when uninit, it will fail in the scene:
insmod hns3.ko, hns-roce.ko, hns-roce-hw-v3.ko successfully, but
rmmod hns3.ko after rmmod hns-roce-hw-v2.ko and hns-roce.ko.
This patch fixes the issue.
Fixes: 46a3df9 (net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -4007,13 +4007,19 @@ static void hclge_uninit_client_instance
for (i = 0; i < hdev->num_vmdq_vport + 1; i++) {
vport = &hdev->vport[i];
- if (hdev->roce_client)
+ if (hdev->roce_client) {
hdev->roce_client->ops->uninit_instance(&vport->roce,
0);
+ hdev->roce_client = NULL;
+ vport->roce.client = NULL;
+ }
if (client->type == HNAE3_CLIENT_ROCE)
return;
- if (client->ops->uninit_instance)
+ if (client->ops->uninit_instance) {
client->ops->uninit_instance(&vport->nic, 0);
+ hdev->nic_client = NULL;
+ vport->nic.client = NULL;
+ }
}
}
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
This is a note to let you know that I've just added the patch titled
net: hns3: add nic_client check when initialize roce base information
to the 4.14-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-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Lipeng <lipeng321(a)huawei.com>
Date: Tue, 24 Oct 2017 21:02:10 +0800
Subject: net: hns3: add nic_client check when initialize roce base information
From: Lipeng <lipeng321(a)huawei.com>
[ Upstream commit 3a46f34d20d453f09defb76b11a567647939c0aa ]
Roce driver works base on HNS3 driver.If insmod Roce driver before
NIC driver there is a error because do not check nic_client. This patch
adds nic_client check when initialize roce base information.
Fixes: 46a3df9 (net: hns3: Add HNS3 Acceleration Engine & Compatibility Layer Support)
Signed-off-by: Lipeng <lipeng321(a)huawei.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3981,7 +3981,7 @@ static int hclge_init_client_instance(st
vport->roce.client = client;
}
- if (hdev->roce_client) {
+ if (hdev->roce_client && hdev->nic_client) {
ret = hclge_init_roce_base_info(vport);
if (ret)
goto err;
Patches currently in stable-queue which might be from lipeng321(a)huawei.com are
queue-4.14/net-hns3-fix-the-tx-rx-ring.queue_index-in-hns3_ring_get_cfg.patch
queue-4.14/net-hns3-fix-the-bug-when-map-buffer-fail.patch
queue-4.14/net-hns3-fix-a-bug-when-alloc-new-buffer.patch
queue-4.14/net-hns3-fix-the-bug-of-hns3_set_txbd_baseinfo.patch
queue-4.14/net-hns3-fix-a-bug-in-hclge_uninit_client_instance.patch
queue-4.14/net-hns3-fix-a-misuse-to-devm_free_irq.patch
queue-4.14/net-hns3-fix-for-getting-advertised_caps-in-hns3_get_link_ksettings.patch
queue-4.14/net-hns3-add-nic_client-check-when-initialize-roce-base-information.patch
This is a note to let you know that I've just added the patch titled
net: dsa: lan9303: Do not disable switch fabric port 0 at .probe
to the 4.14-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-dsa-lan9303-do-not-disable-switch-fabric-port-0-at-.probe.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Egil Hjelmeland <privat(a)egil-hjelmeland.no>
Date: Tue, 24 Oct 2017 17:14:10 +0200
Subject: net: dsa: lan9303: Do not disable switch fabric port 0 at .probe
From: Egil Hjelmeland <privat(a)egil-hjelmeland.no>
[ Upstream commit 3c91b0c1de8d013490bbc41ce9ee8810ea5baddd ]
Make the LAN9303 work when lan9303_probe() is called twice.
For some unknown reason the LAN9303 switch fail to forward data when switch
fabric port 0 TX is disabled during probe. (Write of LAN9303_MAC_TX_CFG_0
in lan9303_disable_processing_port().)
In that situation the switch fabric seem to receive frames, because the ALR
is learning addresses. But no frames are transmitted on any of the ports.
In our system lan9303_probe() is called twice, first time
dsa_register_switch() return -EPROBE_DEFER. As an experiment, modified the
code to skip writing LAN9303_MAC_TX_CFG_0, port 0 during the first probe.
Then the switch works as expected.
Resolve the problem by not calling lan9303_disable_processing_port() on
port 0 during probe. Ports 1 and 2 are still disabled.
Although unsatisfying that the exact failure mechanism is not known,
the patch should not cause any harm.
Signed-off-by: Egil Hjelmeland <privat(a)egil-hjelmeland.no>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/dsa/lan9303-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -569,7 +569,7 @@ static int lan9303_disable_processing(st
{
int p;
- for (p = 0; p < LAN9303_NUM_PORTS; p++) {
+ for (p = 1; p < LAN9303_NUM_PORTS; p++) {
int ret = lan9303_disable_processing_port(chip, p);
if (ret)
Patches currently in stable-queue which might be from privat(a)egil-hjelmeland.no are
queue-4.14/net-dsa-lan9303-do-not-disable-switch-fabric-port-0-at-.probe.patch
This is a note to let you know that I've just added the patch titled
mtd: spi-nor: stm32-quadspi: Fix uninitialized error return code
to the 4.14-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-spi-nor-stm32-quadspi-fix-uninitialized-error-return-code.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
Date: Thu, 26 Oct 2017 17:12:33 +0200
Subject: mtd: spi-nor: stm32-quadspi: Fix uninitialized error return code
From: Geert Uytterhoeven <geert(a)linux-m68k.org>
[ Upstream commit 05521bd3d117704a1458eb4d0c3ae821858658f2 ]
With gcc 4.1.2:
drivers/mtd/spi-nor/stm32-quadspi.c: In function ‘stm32_qspi_tx_poll’:
drivers/mtd/spi-nor/stm32-quadspi.c:230: warning: ‘ret’ may be used uninitialized in this function
Indeed, if stm32_qspi_cmd.len is zero, ret will be uninitialized.
This length is passed from outside the driver using the
spi_nor.{read,write}{,_reg}() callbacks.
Several functions in drivers/mtd/spi-nor/spi-nor.c (e.g. write_enable(),
write_disable(), and erase_chip()) call spi_nor.write_reg() with a zero
length.
Fix this by returning an explicit zero on success.
Fixes: 0d43d7ab277a048c ("mtd: spi-nor: add driver for STM32 quad spi flash controller")
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
Acked-by: Ludovic Barre <ludovic.barre(a)st.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen(a)wedev4u.fr>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mtd/spi-nor/stm32-quadspi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/mtd/spi-nor/stm32-quadspi.c
+++ b/drivers/mtd/spi-nor/stm32-quadspi.c
@@ -240,12 +240,12 @@ static int stm32_qspi_tx_poll(struct stm
STM32_QSPI_FIFO_TIMEOUT_US);
if (ret) {
dev_err(qspi->dev, "fifo timeout (stat:%#x)\n", sr);
- break;
+ return ret;
}
tx_fifo(buf++, qspi->io_base + QUADSPI_DR);
}
- return ret;
+ return 0;
}
static int stm32_qspi_tx_mm(struct stm32_qspi *qspi,
Patches currently in stable-queue which might be from geert(a)linux-m68k.org are
queue-4.14/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
queue-4.14/mtd-spi-nor-stm32-quadspi-fix-uninitialized-error-return-code.patch
This is a note to let you know that I've just added the patch titled
mm: Handle 0 flags in _calc_vm_trans() macro
to the 4.14-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:
mm-handle-0-flags-in-_calc_vm_trans-macro.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Jan Kara <jack(a)suse.cz>
Date: Fri, 3 Nov 2017 12:21:21 +0100
Subject: mm: Handle 0 flags in _calc_vm_trans() macro
From: Jan Kara <jack(a)suse.cz>
[ Upstream commit 592e254502041f953e84d091eae2c68cba04c10b ]
_calc_vm_trans() does not handle the situation when some of the passed
flags are 0 (which can happen if these VM flags do not make sense for
the architecture). Improve the _calc_vm_trans() macro to return 0 in
such situation. Since all passed flags are constant, this does not add
any runtime overhead.
Signed-off-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Dan Williams <dan.j.williams(a)intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/linux/mman.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/include/linux/mman.h
+++ b/include/linux/mman.h
@@ -64,8 +64,9 @@ static inline bool arch_validate_prot(un
* ("bit1" and "bit2" must be single bits)
*/
#define _calc_vm_trans(x, bit1, bit2) \
+ ((!(bit1) || !(bit2)) ? 0 : \
((bit1) <= (bit2) ? ((x) & (bit1)) * ((bit2) / (bit1)) \
- : ((x) & (bit1)) / ((bit1) / (bit2)))
+ : ((x) & (bit1)) / ((bit1) / (bit2))))
/*
* Combine the mmap "prot" argument into "vm_flags" used internally.
Patches currently in stable-queue which might be from jack(a)suse.cz are
queue-4.14/mm-handle-0-flags-in-_calc_vm_trans-macro.patch
queue-4.14/udf-avoid-overflow-when-session-starts-at-large-offset.patch
This is a note to let you know that I've just added the patch titled
mlxsw: spectrum: Fix error return code in mlxsw_sp_port_create()
to the 4.14-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:
mlxsw-spectrum-fix-error-return-code-in-mlxsw_sp_port_create.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Wei Yongjun <weiyongjun1(a)huawei.com>
Date: Mon, 6 Nov 2017 11:11:28 +0000
Subject: mlxsw: spectrum: Fix error return code in mlxsw_sp_port_create()
From: Wei Yongjun <weiyongjun1(a)huawei.com>
[ Upstream commit d86fd113ebbb37726ef7c7cc6fd6d5ce377455d6 ]
Fix to return a negative error code from the VID create error handling
case instead of 0, as done elsewhere in this function.
Fixes: c57529e1d5d8 ("mlxsw: spectrum: Replace vPorts with Port-VLAN")
Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com>
Reviewed-by: Ido Schimmel <idosch(a)mellanox.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -2974,6 +2974,7 @@ static int mlxsw_sp_port_create(struct m
if (IS_ERR(mlxsw_sp_port_vlan)) {
dev_err(mlxsw_sp->bus_info->dev, "Port %d: Failed to create VID 1\n",
mlxsw_sp_port->local_port);
+ err = PTR_ERR(mlxsw_sp_port_vlan);
goto err_port_vlan_get;
}
Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are
queue-4.14/nullb-fix-error-return-code-in-null_init.patch
queue-4.14/mlxsw-spectrum-fix-error-return-code-in-mlxsw_sp_port_create.patch
This is a note to let you know that I've just added the patch titled
misc: pci_endpoint_test: Fix failure path return values in probe
to the 4.14-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:
misc-pci_endpoint_test-fix-failure-path-return-values-in-probe.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Kishon Vijay Abraham I <kishon(a)ti.com>
Date: Wed, 11 Oct 2017 14:14:36 +0530
Subject: misc: pci_endpoint_test: Fix failure path return values in probe
From: Kishon Vijay Abraham I <kishon(a)ti.com>
[ Upstream commit 80068c93688f6143100859c4856f895801c1a1d9 ]
Return value of pci_endpoint_test_probe is not set properly in a couple of
failure cases. Fix it here.
Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/pci_endpoint_test.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -533,6 +533,7 @@ static int pci_endpoint_test_probe(struc
test->base = test->bar[test_reg_bar];
if (!test->base) {
+ err = -ENOMEM;
dev_err(dev, "Cannot perform PCI test without BAR%d\n",
test_reg_bar);
goto err_iounmap;
@@ -542,6 +543,7 @@ static int pci_endpoint_test_probe(struc
id = ida_simple_get(&pci_endpoint_test_ida, 0, 0, GFP_KERNEL);
if (id < 0) {
+ err = id;
dev_err(dev, "unable to get id\n");
goto err_iounmap;
}
Patches currently in stable-queue which might be from kishon(a)ti.com are
queue-4.14/misc-pci_endpoint_test-fix-failure-path-return-values-in-probe.patch
This is a note to let you know that I've just added the patch titled
misc: pci_endpoint_test: Avoid triggering a BUG()
to the 4.14-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:
misc-pci_endpoint_test-avoid-triggering-a-bug.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Sat, 30 Sep 2017 11:16:51 +0300
Subject: misc: pci_endpoint_test: Avoid triggering a BUG()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit 846df244ebefbc9f7b91e9ae7a5e5a2e69fb4772 ]
If you call ida_simple_remove(&pci_endpoint_test_ida, id) with a
negative "id" then it triggers an immediate BUG_ON(). Let's not allow
that.
Fixes: 2c156ac71c6b ("misc: Add host side PCI driver for PCI test function device")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/misc/pci_endpoint_test.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -590,6 +590,8 @@ static void pci_endpoint_test_remove(str
if (sscanf(misc_device->name, DRV_MODULE_NAME ".%d", &id) != 1)
return;
+ if (id < 0)
+ return;
misc_deregister(&test->miscdev);
ida_simple_remove(&pci_endpoint_test_ida, id);
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.14/scsi-bfa-integer-overflow-in-debugfs.patch
queue-4.14/fbdev-controlfb-add-missing-modes-to-fix-out-of-bounds-access.patch
queue-4.14/misc-pci_endpoint_test-avoid-triggering-a-bug.patch
This is a note to let you know that I've just added the patch titled
mfd: mxs-lradc: Fix error handling in mxs_lradc_probe()
to the 4.14-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:
mfd-mxs-lradc-fix-error-handling-in-mxs_lradc_probe.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Date: Sat, 14 Oct 2017 01:06:56 +0300
Subject: mfd: mxs-lradc: Fix error handling in mxs_lradc_probe()
From: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
[ Upstream commit 362741a21a5c4b9ee31e75ce28d63c6d238a745c ]
There is the only path, where mxs_lradc_probe() leaves clk undisabled,
since it does return instead of goto err_clk.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov(a)ispras.ru>
Signed-off-by: Lee Jones <lee.jones(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/mfd/mxs-lradc.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/mfd/mxs-lradc.c
+++ b/drivers/mfd/mxs-lradc.c
@@ -196,8 +196,10 @@ static int mxs_lradc_probe(struct platfo
platform_set_drvdata(pdev, lradc);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res)
- return -ENOMEM;
+ if (!res) {
+ ret = -ENOMEM;
+ goto err_clk;
+ }
switch (lradc->soc) {
case IMX23_LRADC:
Patches currently in stable-queue which might be from khoroshilov(a)ispras.ru are
queue-4.14/mfd-mxs-lradc-fix-error-handling-in-mxs_lradc_probe.patch
This is a note to let you know that I've just added the patch titled
media: usbtv: fix brightness and contrast controls
to the 4.14-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:
media-usbtv-fix-brightness-and-contrast-controls.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Adam Sampson <ats(a)offog.org>
Date: Tue, 24 Oct 2017 16:14:46 -0400
Subject: media: usbtv: fix brightness and contrast controls
From: Adam Sampson <ats(a)offog.org>
[ Upstream commit b3168c87c0492661badc3e908f977d79e7738a41 ]
Because the brightness and contrast controls share a register,
usbtv_s_ctrl needs to read the existing values for both controls before
inserting the new value. However, the code accidentally wrote to the
registers (from an uninitialised stack array), rather than reading them.
The user-visible effect of this was that adjusting the brightness would
also set the contrast to a random value, and vice versa -- so it wasn't
possible to correctly adjust the brightness of usbtv's video output.
Tested with an "EasyDAY" UTV007 device.
Fixes: c53a846c48f2 ("usbtv: add video controls")
Signed-off-by: Adam Sampson <ats(a)offog.org>
Reviewed-by: Lubomir Rintel <lkundrak(a)v3.sk>
Signed-off-by: Hans Verkuil <hans.verkuil(a)cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/usb/usbtv/usbtv-video.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -718,8 +718,8 @@ static int usbtv_s_ctrl(struct v4l2_ctrl
*/
if (ctrl->id == V4L2_CID_BRIGHTNESS || ctrl->id == V4L2_CID_CONTRAST) {
ret = usb_control_msg(usbtv->udev,
- usb_sndctrlpipe(usbtv->udev, 0), USBTV_CONTROL_REG,
- USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
+ usb_rcvctrlpipe(usbtv->udev, 0), USBTV_CONTROL_REG,
+ USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, USBTV_BASE + 0x0244, (void *)data, 3, 0);
if (ret < 0)
goto error;
Patches currently in stable-queue which might be from ats(a)offog.org are
queue-4.14/media-usbtv-fix-brightness-and-contrast-controls.patch
This is a note to let you know that I've just added the patch titled
media: camss-vfe: always initialize reg at vfe_set_xbar_cfg()
to the 4.14-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:
media-camss-vfe-always-initialize-reg-at-vfe_set_xbar_cfg.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Date: Wed, 1 Nov 2017 08:09:59 -0400
Subject: media: camss-vfe: always initialize reg at vfe_set_xbar_cfg()
From: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
[ Upstream commit 9917fbcfa20ab987d6381fd0365665e5c1402d75 ]
if output->wm_num is bigger than 2, the value for reg is
not initialized, as warned by smatch:
drivers/media/platform/qcom/camss-8x16/camss-vfe.c:633 vfe_set_xbar_cfg() error: uninitialized symbol 'reg'.
drivers/media/platform/qcom/camss-8x16/camss-vfe.c:637 vfe_set_xbar_cfg() error: uninitialized symbol 'reg'.
That shouldn't happen in practice, so add a logic that will
break the loop if i > 1, fixing the warnings.
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Acked-by: Todor Tomov <todor.tomov(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
@@ -622,6 +622,9 @@ static void vfe_set_xbar_cfg(struct vfe_
reg = VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN;
if (p == V4L2_PIX_FMT_NV12 || p == V4L2_PIX_FMT_NV16)
reg |= VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA;
+ } else {
+ /* On current devices output->wm_num is always <= 2 */
+ break;
}
if (output->wm_idx[i] % 2 == 1)
Patches currently in stable-queue which might be from mchehab(a)s-opensource.com are
queue-4.14/media-usbtv-fix-brightness-and-contrast-controls.patch
queue-4.14/media-camss-vfe-always-initialize-reg-at-vfe_set_xbar_cfg.patch
This is a note to let you know that I've just added the patch titled
md-cluster: fix wrong condition check in raid1_write_request
to the 4.14-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:
md-cluster-fix-wrong-condition-check-in-raid1_write_request.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Guoqing Jiang <gqjiang(a)suse.com>
Date: Fri, 29 Sep 2017 09:16:43 +0800
Subject: md-cluster: fix wrong condition check in raid1_write_request
From: Guoqing Jiang <gqjiang(a)suse.com>
[ Upstream commit 385f4d7f946b08f36f68b0a28e95a319925b6b62 ]
The check used here is to avoid conflict between write and
resync, however we used the wrong logic, it should be the
inverse of the checking inside "if".
Fixes: 589a1c4 ("Suspend writes in RAID1 if within range")
Signed-off-by: Guoqing Jiang <gqjiang(a)suse.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/raid1.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -1309,12 +1309,12 @@ static void raid1_write_request(struct m
sigset_t full, old;
prepare_to_wait(&conf->wait_barrier,
&w, TASK_INTERRUPTIBLE);
- if (bio_end_sector(bio) <= mddev->suspend_lo ||
- bio->bi_iter.bi_sector >= mddev->suspend_hi ||
- (mddev_is_clustered(mddev) &&
+ if ((bio_end_sector(bio) <= mddev->suspend_lo ||
+ bio->bi_iter.bi_sector >= mddev->suspend_hi) &&
+ (!mddev_is_clustered(mddev) ||
!md_cluster_ops->area_resyncing(mddev, WRITE,
- bio->bi_iter.bi_sector,
- bio_end_sector(bio))))
+ bio->bi_iter.bi_sector,
+ bio_end_sector(bio))))
break;
sigfillset(&full);
sigprocmask(SIG_BLOCK, &full, &old);
Patches currently in stable-queue which might be from gqjiang(a)suse.com are
queue-4.14/badblocks-fix-wrong-return-value-in-badblocks_set-if-badblocks-are-disabled.patch
queue-4.14/md-cluster-fix-wrong-condition-check-in-raid1_write_request.patch
This is a note to let you know that I've just added the patch titled
macvlan: Only deliver one copy of the frame to the macvlan interface
to the 4.14-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-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
Date: Fri, 13 Oct 2017 13:40:24 -0700
Subject: macvlan: Only deliver one copy of the frame to the macvlan interface
From: Alexander Duyck <alexander.h.duyck(a)intel.com>
[ Upstream commit dd6b9c2c332b40f142740d1b11fb77c653ff98ea ]
This patch intoduces a slight adjustment for macvlan to address the fact
that in source mode I was seeing two copies of any packet addressed to the
macvlan interface being delivered where there should have been only one.
The issue appears to be that one copy was delivered based on the source MAC
address and then the second copy was being delivered based on the
destination MAC address. To fix it I am just treating a unicast address
match as though it is not a match since source based macvlan isn't supposed
to be matching based on the destination MAC anyway.
Fixes: 79cf79abce71 ("macvlan: add source mode")
Signed-off-by: Alexander Duyck <alexander.h.duyck(a)intel.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/macvlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -480,7 +480,7 @@ static rx_handler_result_t macvlan_handl
struct macvlan_dev, list);
else
vlan = macvlan_hash_lookup(port, eth->h_dest);
- if (vlan == NULL)
+ if (!vlan || vlan->mode == MACVLAN_MODE_SOURCE)
return RX_HANDLER_PASS;
dev = vlan->dev;
Patches currently in stable-queue which might be from alexander.h.duyck(a)intel.com are
queue-4.14/macvlan-only-deliver-one-copy-of-the-frame-to-the-macvlan-interface.patch
This is a note to let you know that I've just added the patch titled
liquidio: fix kernel panic in VF driver
to the 4.14-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:
liquidio-fix-kernel-panic-in-vf-driver.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Felix Manlunas <felix.manlunas(a)cavium.com>
Date: Thu, 26 Oct 2017 16:46:36 -0700
Subject: liquidio: fix kernel panic in VF driver
From: Felix Manlunas <felix.manlunas(a)cavium.com>
[ Upstream commit aa28667cfbe4ff6f14454dda210b1f2e485f99b5 ]
Doing ifconfig down on VF driver in the middle of receiving line rate
traffic causes a kernel panic:
LiquidIO_VF 0000:02:00.3: should not come here should not get rx when poll mode = 0 for vf
BUG: unable to handle kernel NULL pointer dereference at (null)
.
.
.
Call Trace:
<IRQ>
? tasklet_action+0x102/0x120
__do_softirq+0x91/0x292
irq_exit+0xb6/0xc0
do_IRQ+0x4f/0xd0
common_interrupt+0x93/0x93
</IRQ>
RIP: 0010:cpuidle_enter_state+0x142/0x2f0
RSP: 0018:ffffffffa6403e20 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff59
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000001f
RDX: 0000000000000000 RSI: 000000002ab7519f RDI: 0000000000000000
RBP: ffffffffa6403e58 R08: 0000000000000084 R09: 0000000000000018
R10: ffffffffa6403df0 R11: 00000000000003c7 R12: 0000000000000003
R13: ffffd27ebd806800 R14: ffffffffa64d40d8 R15: 0000007be072823f
cpuidle_enter+0x17/0x20
call_cpuidle+0x23/0x40
do_idle+0x18c/0x1f0
cpu_startup_entry+0x64/0x70
rest_init+0xa5/0xb0
start_kernel+0x45e/0x46b
x86_64_start_reservations+0x24/0x26
x86_64_start_kernel+0x6f/0x72
secondary_startup_64+0xa5/0xa5
Code: Bad RIP value.
RIP: (null) RSP: ffff9246ed003f28
CR2: 0000000000000000
---[ end trace 92731e80f31b7d7d ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: 0x24000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Fatal exception in interrupt
Reason is: in the function assigned to net_device_ops->ndo_stop, the steps
for bringing down the interface are done in the wrong order. The step that
notifies the NIC firmware to stop forwarding packets to host is done too
late. Fix it by moving that step to the beginning.
Signed-off-by: Felix Manlunas <felix.manlunas(a)cavium.com>
Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi(a)cavium.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/cavium/liquidio/lio_vf_main.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_main.c
@@ -1289,6 +1289,9 @@ static int liquidio_stop(struct net_devi
struct octeon_device *oct = lio->oct_dev;
struct napi_struct *napi, *n;
+ /* tell Octeon to stop forwarding packets to host */
+ send_rx_ctrl_cmd(lio, 0);
+
if (oct->props[lio->ifidx].napi_enabled) {
list_for_each_entry_safe(napi, n, &netdev->napi_list, dev_list)
napi_disable(napi);
@@ -1306,9 +1309,6 @@ static int liquidio_stop(struct net_devi
netif_carrier_off(netdev);
lio->link_changes++;
- /* tell Octeon to stop forwarding packets to host */
- send_rx_ctrl_cmd(lio, 0);
-
ifstate_reset(lio, LIO_IFSTATE_RUNNING);
txqs_stop(netdev);
Patches currently in stable-queue which might be from felix.manlunas(a)cavium.com are
queue-4.14/liquidio-fix-kernel-panic-in-vf-driver.patch
This is a note to let you know that I've just added the patch titled
lightnvm: pblk: use right flag for GC allocation
to the 4.14-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:
lightnvm-pblk-use-right-flag-for-gc-allocation.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Javier González <javier(a)cnexlabs.com>
Date: Fri, 13 Oct 2017 14:46:02 +0200
Subject: lightnvm: pblk: use right flag for GC allocation
From: Javier González <javier(a)cnexlabs.com>
[ Upstream commit 7d327a9ed6c4dca341ebf99012e0a6b80a3050e6 ]
The data buffer for the GC path allocates virtual memory through
vmalloc. When this change was introduced, a flag signaling kmalloc'ed
memory was wrongly introduced. Use the right flag when creating a bio
from this buffer.
Fixes: de54e703a422 ("lightnvm: pblk: use vmalloc for GC data buffer")
Signed-off-by: Javier González <javier(a)cnexlabs.com>
Signed-off-by: Matias Bjørling <m(a)bjorling.me>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/lightnvm/pblk-read.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -499,7 +499,7 @@ int pblk_submit_read_gc(struct pblk *pbl
data_len = (*secs_to_gc) * geo->sec_size;
bio = pblk_bio_map_addr(pblk, data, *secs_to_gc, data_len,
- PBLK_KMALLOC_META, GFP_KERNEL);
+ PBLK_VMALLOC_META, GFP_KERNEL);
if (IS_ERR(bio)) {
pr_err("pblk: could not allocate GC bio (%lu)\n", PTR_ERR(bio));
goto err_free_dma;
@@ -519,7 +519,7 @@ int pblk_submit_read_gc(struct pblk *pbl
if (ret) {
bio_endio(bio);
pr_err("pblk: GC read request failed\n");
- goto err_free_dma;
+ goto err_free_bio;
}
if (!wait_for_completion_io_timeout(&wait,
@@ -541,10 +541,13 @@ int pblk_submit_read_gc(struct pblk *pbl
atomic_long_sub(*secs_to_gc, &pblk->inflight_reads);
#endif
+ bio_put(bio);
out:
nvm_dev_dma_free(dev->parent, rqd.meta_list, rqd.dma_meta_list);
return NVM_IO_OK;
+err_free_bio:
+ bio_put(bio);
err_free_dma:
nvm_dev_dma_free(dev->parent, rqd.meta_list, rqd.dma_meta_list);
return NVM_IO_ERR;
Patches currently in stable-queue which might be from javier(a)cnexlabs.com are
queue-4.14/lightnvm-pblk-fix-min-size-for-page-mempool.patch
queue-4.14/lightnvm-pblk-use-right-flag-for-gc-allocation.patch
queue-4.14/lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
queue-4.14/lightnvm-pblk-initialize-debug-stat-counter.patch
This is a note to let you know that I've just added the patch titled
lightnvm: pblk: protect line bitmap while submitting meta io
to the 4.14-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:
lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Rakesh Pandit <rakesh(a)tuxera.com>
Date: Fri, 13 Oct 2017 14:45:56 +0200
Subject: lightnvm: pblk: protect line bitmap while submitting meta io
From: Rakesh Pandit <rakesh(a)tuxera.com>
[ Upstream commit e57903fd972a398b7140d0bc055714e13a0e58c5 ]
It seems pblk_dealloc_page would race against pblk_alloc_pages for
line bitmap for sector allocation.The chances are very low but might
as well protect the bitmap properly.
Signed-off-by: Rakesh Pandit <rakesh(a)tuxera.com>
Reviewed-by: Javier González <javier(a)cnexlabs.com>
Signed-off-by: Matias Bjørling <m(a)bjorling.me>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/lightnvm/pblk-core.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/lightnvm/pblk-core.c
+++ b/drivers/lightnvm/pblk-core.c
@@ -486,12 +486,14 @@ void pblk_dealloc_page(struct pblk *pblk
u64 addr;
int i;
+ spin_lock(&line->lock);
addr = find_next_zero_bit(line->map_bitmap,
pblk->lm.sec_per_line, line->cur_sec);
line->cur_sec = addr - nr_secs;
for (i = 0; i < nr_secs; i++, line->cur_sec--)
WARN_ON(!test_and_clear_bit(line->cur_sec, line->map_bitmap));
+ spin_unlock(&line->lock);
}
u64 __pblk_alloc_page(struct pblk *pblk, struct pblk_line *line, int nr_secs)
Patches currently in stable-queue which might be from rakesh(a)tuxera.com are
queue-4.14/lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
queue-4.14/lightnvm-pblk-fix-changing-gc-group-list-for-a-line.patch
This is a note to let you know that I've just added the patch titled
lightnvm: pblk: prevent gc kicks when gc is not operational
to the 4.14-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:
lightnvm-pblk-prevent-gc-kicks-when-gc-is-not-operational.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Hans Holmberg <hans.holmberg(a)cnexlabs.com>
Date: Fri, 13 Oct 2017 14:46:34 +0200
Subject: lightnvm: pblk: prevent gc kicks when gc is not operational
From: Hans Holmberg <hans.holmberg(a)cnexlabs.com>
[ Upstream commit 3e3a5b8ebd5d3b1d68facc58b0674a2564653222 ]
GC can be kicked after it has been shut down when closing the last
line during exit, resulting in accesses to freed structures.
Make sure that GC is not triggered while it is not operational.
Also make sure that GC won't be re-activated during exit when
running on another processor by using timer_del_sync.
Signed-off-by: Hans Holmberg <hans.holmberg(a)cnexlabs.com>
Signed-off-by: Matias Bjørling <m(a)bjorling.me>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/lightnvm/pblk-gc.c | 9 +++++----
drivers/lightnvm/pblk-init.c | 1 +
2 files changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/lightnvm/pblk-gc.c
+++ b/drivers/lightnvm/pblk-gc.c
@@ -486,10 +486,10 @@ void pblk_gc_should_start(struct pblk *p
{
struct pblk_gc *gc = &pblk->gc;
- if (gc->gc_enabled && !gc->gc_active)
+ if (gc->gc_enabled && !gc->gc_active) {
pblk_gc_start(pblk);
-
- pblk_gc_kick(pblk);
+ pblk_gc_kick(pblk);
+ }
}
/*
@@ -628,7 +628,8 @@ void pblk_gc_exit(struct pblk *pblk)
flush_workqueue(gc->gc_reader_wq);
flush_workqueue(gc->gc_line_reader_wq);
- del_timer(&gc->gc_timer);
+ gc->gc_enabled = 0;
+ del_timer_sync(&gc->gc_timer);
pblk_gc_stop(pblk, 1);
if (gc->gc_ts)
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -923,6 +923,7 @@ static void *pblk_init(struct nvm_tgt_de
pblk->dev = dev;
pblk->disk = tdisk;
pblk->state = PBLK_STATE_RUNNING;
+ pblk->gc.gc_enabled = 0;
spin_lock_init(&pblk->trans_lock);
spin_lock_init(&pblk->lock);
Patches currently in stable-queue which might be from hans.holmberg(a)cnexlabs.com are
queue-4.14/lightnvm-pblk-prevent-gc-kicks-when-gc-is-not-operational.patch
This is a note to let you know that I've just added the patch titled
lightnvm: pblk: initialize debug stat counter
to the 4.14-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:
lightnvm-pblk-initialize-debug-stat-counter.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Javier González <javier(a)cnexlabs.com>
Date: Fri, 13 Oct 2017 14:46:01 +0200
Subject: lightnvm: pblk: initialize debug stat counter
From: Javier González <javier(a)cnexlabs.com>
[ Upstream commit a1121176ff757e3c073490a69608ea0b18a00ec1 ]
Initialize the stat counter for garbage collected reads.
Fixes: a4bd217b43268 ("lightnvm: physical block device (pblk) target")
Signed-off-by: Javier González <javier(a)cnexlabs.com>
Signed-off-by: Matias Bjørling <m(a)bjorling.me>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/lightnvm/pblk-init.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -945,6 +945,7 @@ static void *pblk_init(struct nvm_tgt_de
atomic_long_set(&pblk->recov_writes, 0);
atomic_long_set(&pblk->recov_writes, 0);
atomic_long_set(&pblk->recov_gc_writes, 0);
+ atomic_long_set(&pblk->recov_gc_reads, 0);
#endif
atomic_long_set(&pblk->read_failed, 0);
Patches currently in stable-queue which might be from javier(a)cnexlabs.com are
queue-4.14/lightnvm-pblk-fix-min-size-for-page-mempool.patch
queue-4.14/lightnvm-pblk-use-right-flag-for-gc-allocation.patch
queue-4.14/lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
queue-4.14/lightnvm-pblk-initialize-debug-stat-counter.patch
This is a note to let you know that I've just added the patch titled
lightnvm: pblk: fix min size for page mempool
to the 4.14-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:
lightnvm-pblk-fix-min-size-for-page-mempool.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Javier González <javier(a)cnexlabs.com>
Date: Fri, 13 Oct 2017 14:46:06 +0200
Subject: lightnvm: pblk: fix min size for page mempool
From: Javier González <javier(a)cnexlabs.com>
[ Upstream commit bd432417681a224d9fa4a9d43be7d4edc82135b2 ]
pblk uses an internal page mempool for allocating pages on internal
bios. The main two users of this memory pool are partial reads (reads
with some sectors in cache and some on media) and padded writes, which
need to add dummy pages to an existing bio already containing valid
data (and with a large enough bioset allocated). In both cases, the
maximum number of pages per bio is defined by the maximum number of
physical sectors supported by the underlying device.
This patch fixes a bad mempool allocation, where the min_nr of elements
on the pool was fixed (to 16), which is lower than the maximum number
of sectors supported by NVMe (as of the time for this patch). Instead,
use the maximum number of allowed sectors reported by the device.
Reported-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Javier González <javier(a)cnexlabs.com>
Signed-off-by: Matias Bjørling <m(a)bjorling.me>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/lightnvm/pblk-core.c | 6 +++---
drivers/lightnvm/pblk-init.c | 15 ++++++++-------
drivers/lightnvm/pblk-read.c | 2 +-
drivers/lightnvm/pblk.h | 2 +-
4 files changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/lightnvm/pblk-core.c
+++ b/drivers/lightnvm/pblk-core.c
@@ -193,7 +193,7 @@ void pblk_bio_free_pages(struct pblk *pb
bio_advance(bio, off * PBLK_EXPOSED_PAGE_SIZE);
for (i = off; i < nr_pages + off; i++) {
bv = bio->bi_io_vec[i];
- mempool_free(bv.bv_page, pblk->page_pool);
+ mempool_free(bv.bv_page, pblk->page_bio_pool);
}
}
@@ -205,14 +205,14 @@ int pblk_bio_add_pages(struct pblk *pblk
int i, ret;
for (i = 0; i < nr_pages; i++) {
- page = mempool_alloc(pblk->page_pool, flags);
+ page = mempool_alloc(pblk->page_bio_pool, flags);
if (!page)
goto err;
ret = bio_add_pc_page(q, bio, page, PBLK_EXPOSED_PAGE_SIZE, 0);
if (ret != PBLK_EXPOSED_PAGE_SIZE) {
pr_err("pblk: could not add page to bio\n");
- mempool_free(page, pblk->page_pool);
+ mempool_free(page, pblk->page_bio_pool);
goto err;
}
}
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -132,7 +132,6 @@ static int pblk_rwb_init(struct pblk *pb
}
/* Minimum pages needed within a lun */
-#define PAGE_POOL_SIZE 16
#define ADDR_POOL_SIZE 64
static int pblk_set_ppaf(struct pblk *pblk)
@@ -247,14 +246,16 @@ static int pblk_core_init(struct pblk *p
if (pblk_init_global_caches(pblk))
return -ENOMEM;
- pblk->page_pool = mempool_create_page_pool(PAGE_POOL_SIZE, 0);
- if (!pblk->page_pool)
+ /* internal bios can be at most the sectors signaled by the device. */
+ pblk->page_bio_pool = mempool_create_page_pool(nvm_max_phys_sects(dev),
+ 0);
+ if (!pblk->page_bio_pool)
return -ENOMEM;
pblk->line_ws_pool = mempool_create_slab_pool(PBLK_WS_POOL_SIZE,
pblk_blk_ws_cache);
if (!pblk->line_ws_pool)
- goto free_page_pool;
+ goto free_page_bio_pool;
pblk->rec_pool = mempool_create_slab_pool(geo->nr_luns, pblk_rec_cache);
if (!pblk->rec_pool)
@@ -309,8 +310,8 @@ free_rec_pool:
mempool_destroy(pblk->rec_pool);
free_blk_ws_pool:
mempool_destroy(pblk->line_ws_pool);
-free_page_pool:
- mempool_destroy(pblk->page_pool);
+free_page_bio_pool:
+ mempool_destroy(pblk->page_bio_pool);
return -ENOMEM;
}
@@ -322,7 +323,7 @@ static void pblk_core_free(struct pblk *
if (pblk->bb_wq)
destroy_workqueue(pblk->bb_wq);
- mempool_destroy(pblk->page_pool);
+ mempool_destroy(pblk->page_bio_pool);
mempool_destroy(pblk->line_ws_pool);
mempool_destroy(pblk->rec_pool);
mempool_destroy(pblk->g_rq_pool);
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -238,7 +238,7 @@ static int pblk_fill_partial_read_bio(st
kunmap_atomic(src_p);
kunmap_atomic(dst_p);
- mempool_free(src_bv.bv_page, pblk->page_pool);
+ mempool_free(src_bv.bv_page, pblk->page_bio_pool);
hole = find_next_zero_bit(read_bitmap, nr_secs, hole + 1);
} while (hole < nr_secs);
--- a/drivers/lightnvm/pblk.h
+++ b/drivers/lightnvm/pblk.h
@@ -618,7 +618,7 @@ struct pblk {
struct list_head compl_list;
- mempool_t *page_pool;
+ mempool_t *page_bio_pool;
mempool_t *line_ws_pool;
mempool_t *rec_pool;
mempool_t *g_rq_pool;
Patches currently in stable-queue which might be from javier(a)cnexlabs.com are
queue-4.14/lightnvm-pblk-fix-min-size-for-page-mempool.patch
queue-4.14/lightnvm-pblk-use-right-flag-for-gc-allocation.patch
queue-4.14/lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
queue-4.14/lightnvm-pblk-initialize-debug-stat-counter.patch
This is a note to let you know that I've just added the patch titled
lightnvm: pblk: fix changing GC group list for a line
to the 4.14-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:
lightnvm-pblk-fix-changing-gc-group-list-for-a-line.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:29:00 CET 2017
From: Rakesh Pandit <rakesh(a)tuxera.com>
Date: Fri, 13 Oct 2017 14:46:28 +0200
Subject: lightnvm: pblk: fix changing GC group list for a line
From: Rakesh Pandit <rakesh(a)tuxera.com>
[ Upstream commit 27b978725d895e704aab44b99242a0514485d798 ]
pblk_line_gc_list seems to had a bug since the introduction of pblk in
getting GC list for a line. In b20ba1bc7 while redesigning the GC
algorithm, the naming for the GC thresholds was altered, but the
values for high_thrs and mid_thrs were not. The result is that when
moving to the GC lists, the mid threshold is never evaluated.
Fixes: a4bd217b4("lightnvm: physical block device (pblk) target")
Signed-off-by: Rakesh Pandit <rakesh(a)tuxera.com>
Signed-off-by: Matias Bjørling <m(a)bjorling.me>
Signed-off-by: Jens Axboe <axboe(a)kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/lightnvm/pblk-init.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/lightnvm/pblk-init.c
+++ b/drivers/lightnvm/pblk-init.c
@@ -681,8 +681,8 @@ static int pblk_lines_init(struct pblk *
lm->blk_bitmap_len = BITS_TO_LONGS(geo->nr_luns) * sizeof(long);
lm->sec_bitmap_len = BITS_TO_LONGS(lm->sec_per_line) * sizeof(long);
lm->lun_bitmap_len = BITS_TO_LONGS(geo->nr_luns) * sizeof(long);
- lm->high_thrs = lm->sec_per_line / 2;
- lm->mid_thrs = lm->sec_per_line / 4;
+ lm->mid_thrs = lm->sec_per_line / 2;
+ lm->high_thrs = lm->sec_per_line / 4;
lm->meta_distance = (geo->nr_luns / 2) * pblk->min_write_pgs;
/* Calculate necessary pages for smeta. See comment over struct
Patches currently in stable-queue which might be from rakesh(a)tuxera.com are
queue-4.14/lightnvm-pblk-protect-line-bitmap-while-submitting-meta-io.patch
queue-4.14/lightnvm-pblk-fix-changing-gc-group-list-for-a-line.patch
This is a note to let you know that I've just added the patch titled
l2tp: cleanup l2tp_tunnel_delete calls
to the 4.14-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:
l2tp-cleanup-l2tp_tunnel_delete-calls.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Jiri Slaby <jslaby(a)suse.cz>
Date: Wed, 25 Oct 2017 15:57:55 +0200
Subject: l2tp: cleanup l2tp_tunnel_delete calls
From: Jiri Slaby <jslaby(a)suse.cz>
[ Upstream commit 4dc12ffeaeac939097a3f55c881d3dc3523dff0c ]
l2tp_tunnel_delete does not return anything since commit 62b982eeb458
("l2tp: fix race condition in l2tp_tunnel_delete"). But call sites of
l2tp_tunnel_delete still do casts to void to avoid unused return value
warnings.
Kill these now useless casts.
Signed-off-by: Jiri Slaby <jslaby(a)suse.cz>
Cc: Sabrina Dubroca <sd(a)queasysnail.net>
Cc: Guillaume Nault <g.nault(a)alphalink.fr>
Cc: David S. Miller <davem(a)davemloft.net>
Cc: netdev(a)vger.kernel.org
Acked-by: Guillaume Nault <g.nault(a)alphalink.fr>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/l2tp/l2tp_core.c | 2 +-
net/l2tp/l2tp_netlink.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -1891,7 +1891,7 @@ static __net_exit void l2tp_exit_net(str
rcu_read_lock_bh();
list_for_each_entry_rcu(tunnel, &pn->l2tp_tunnel_list, list) {
- (void)l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
}
rcu_read_unlock_bh();
--- a/net/l2tp/l2tp_netlink.c
+++ b/net/l2tp/l2tp_netlink.c
@@ -282,7 +282,7 @@ static int l2tp_nl_cmd_tunnel_delete(str
l2tp_tunnel_notify(&l2tp_nl_family, info,
tunnel, L2TP_CMD_TUNNEL_DELETE);
- (void) l2tp_tunnel_delete(tunnel);
+ l2tp_tunnel_delete(tunnel);
l2tp_tunnel_dec_refcount(tunnel);
Patches currently in stable-queue which might be from jslaby(a)suse.cz are
queue-4.14/l2tp-cleanup-l2tp_tunnel_delete-calls.patch
This is a note to let you know that I've just added the patch titled
KVM: nVMX: Fix EPT switching advertising
to the 4.14-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:
kvm-nvmx-fix-ept-switching-advertising.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
Date: Thu, 19 Oct 2017 07:00:34 +0800
Subject: KVM: nVMX: Fix EPT switching advertising
From: Wanpeng Li <wanpeng.li(a)hotmail.com>
[ Upstream commit 575b3a2cb439b03fd603ea77c73c76f3ed237596 ]
I can use vmxcap tool to observe "EPTP Switching yes" even if EPT is not
exposed to L1.
EPT switching is advertised unconditionally since it is emulated, however,
it can be treated as an extended feature for EPT and it should not be
advertised if EPT itself is not exposed. This patch fixes it.
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Cc: Paolo Bonzini <pbonzini(a)redhat.com>
Cc: Radim Krčmář <rkrcmar(a)redhat.com>
Cc: Jim Mattson <jmattson(a)google.com>
Signed-off-by: Wanpeng Li <wanpeng.li(a)hotmail.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2845,8 +2845,9 @@ static void nested_vmx_setup_ctls_msrs(s
* Advertise EPTP switching unconditionally
* since we emulate it
*/
- vmx->nested.nested_vmx_vmfunc_controls =
- VMX_VMFUNC_EPTP_SWITCHING;
+ if (enable_ept)
+ vmx->nested.nested_vmx_vmfunc_controls =
+ VMX_VMFUNC_EPTP_SWITCHING;
}
/*
Patches currently in stable-queue which might be from wanpeng.li(a)hotmail.com are
queue-4.14/kvm-nvmx-fix-ept-switching-advertising.patch
This is a note to let you know that I've just added the patch titled
iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
to the 4.14-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:
iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: tangwenji <tang.wenji(a)zte.com.cn>
Date: Fri, 15 Sep 2017 16:03:13 +0800
Subject: iscsi-target: fix memory leak in lio_target_tiqn_addtpg()
From: tangwenji <tang.wenji(a)zte.com.cn>
[ Upstream commit 12d5a43b2dffb6cd28062b4e19024f7982393288 ]
tpg must free when call core_tpg_register() return fail
Signed-off-by: tangwenji <tang.wenji(a)zte.com.cn>
Signed-off-by: Nicholas Bellinger <nab(a)linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/target/iscsi/iscsi_target_configfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/target/iscsi/iscsi_target_configfs.c
+++ b/drivers/target/iscsi/iscsi_target_configfs.c
@@ -1123,7 +1123,7 @@ static struct se_portal_group *lio_targe
ret = core_tpg_register(wwn, &tpg->tpg_se_tpg, SCSI_PROTOCOL_ISCSI);
if (ret < 0)
- return NULL;
+ goto free_out;
ret = iscsit_tpg_add_portal_group(tiqn, tpg);
if (ret != 0)
@@ -1135,6 +1135,7 @@ static struct se_portal_group *lio_targe
return &tpg->tpg_se_tpg;
out:
core_tpg_deregister(&tpg->tpg_se_tpg);
+free_out:
kfree(tpg);
return NULL;
}
Patches currently in stable-queue which might be from tang.wenji(a)zte.com.cn are
queue-4.14/target-fix-condition-return-in-core_pr_dump_initiator_port.patch
queue-4.14/iscsi-target-fix-memory-leak-in-lio_target_tiqn_addtpg.patch
This is a note to let you know that I've just added the patch titled
ipv4: ipv4_default_advmss() should use route mtu
to the 4.14-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:
ipv4-ipv4_default_advmss-should-use-route-mtu.patch
and it can be found in the queue-4.14 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 Mon Dec 18 13:28:59 CET 2017
From: Eric Dumazet <edumazet(a)google.com>
Date: Wed, 18 Oct 2017 17:02:03 -0700
Subject: ipv4: ipv4_default_advmss() should use route mtu
From: Eric Dumazet <edumazet(a)google.com>
[ Upstream commit 164a5e7ad531e181334a3d3f03d0d5ad20d6faea ]
ipv4_default_advmss() incorrectly uses the device MTU instead
of the route provided one. IPv6 has the proper behavior,
lets harmonize the two protocols.
Signed-off-by: Eric Dumazet <edumazet(a)google.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1254,7 +1254,7 @@ static void set_class_tag(struct rtable
static unsigned int ipv4_default_advmss(const struct dst_entry *dst)
{
unsigned int header_size = sizeof(struct tcphdr) + sizeof(struct iphdr);
- unsigned int advmss = max_t(unsigned int, dst->dev->mtu - header_size,
+ unsigned int advmss = max_t(unsigned int, ipv4_mtu(dst) - header_size,
ip_rt_min_advmss);
return min(advmss, IPV4_MAX_PMTU - header_size);
Patches currently in stable-queue which might be from edumazet(a)google.com are
queue-4.14/ipv4-ipv4_default_advmss-should-use-route-mtu.patch