This is a note to let you know that I've just added the patch titled
PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()
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:
pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.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 Sun Mar 18 16:55:33 CET 2018
From: Prarit Bhargava <prarit(a)redhat.com>
Date: Thu, 26 Jan 2017 14:07:47 -0500
Subject: PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown()
From: Prarit Bhargava <prarit(a)redhat.com>
[ Upstream commit fda78d7a0ead144f4b2cdb582dcba47911f4952c ]
The pci_bus_type .shutdown method, pci_device_shutdown(), is called from
device_shutdown() in the kernel restart and shutdown paths.
Previously, pci_device_shutdown() called pci_msi_shutdown() and
pci_msix_shutdown(). This disables MSI and MSI-X, which causes the device
to fall back to raising interrupts via INTx. But the driver is still bound
to the device, it doesn't know about this change, and it likely doesn't
have an INTx handler, so these INTx interrupts cause "nobody cared"
warnings like this:
irq 16: nobody cared (try booting with the "irqpoll" option)
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.2-1.el7_UNSUPPORTED.x86_64 #1
Hardware name: Hewlett-Packard HP Z820 Workstation/158B, BIOS J63 v03.90 06/
...
The MSI disabling code was added by d52877c7b1af ("pci/irq: let
pci_device_shutdown to call pci_msi_shutdown v2") because a driver left MSI
enabled and kdump failed because the kexeced kernel wasn't prepared to
receive the MSI interrupts.
Subsequent commits 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even
if kernel doesn't support MSI") and e80e7edc55ba ("PCI/MSI: Initialize MSI
capability for all architectures") changed the kexeced kernel to disable
all MSIs itself so it no longer depends on the crashed kernel to clean up
after itself.
Stop disabling MSI/MSI-X in pci_device_shutdown(). This resolves the
"nobody cared" unhandled IRQ issue above. It also allows PCI serial
devices, which may rely on the MSI interrupts, to continue outputting
messages during reboot/shutdown.
[bhelgaas: changelog, drop pci_msi_shutdown() and pci_msix_shutdown() calls
altogether]
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=187351
Signed-off-by: Prarit Bhargava <prarit(a)redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
CC: Alex Williamson <alex.williamson(a)redhat.com>
CC: David Arcari <darcari(a)redhat.com>
CC: Myron Stowe <mstowe(a)redhat.com>
CC: Lukas Wunner <lukas(a)wunner.de>
CC: Keith Busch <keith.busch(a)intel.com>
CC: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/pci-driver.c | 2 --
1 file changed, 2 deletions(-)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -463,8 +463,6 @@ static void pci_device_shutdown(struct d
if (drv && drv->shutdown)
drv->shutdown(pci_dev);
- pci_msi_shutdown(pci_dev);
- pci_msix_shutdown(pci_dev);
/*
* If this is a kexec reboot, turn off Bus Master bit on the
Patches currently in stable-queue which might be from prarit(a)redhat.com are
queue-4.9/pci-msi-stop-disabling-msi-msi-x-in-pci_device_shutdown.patch
This is a note to let you know that I've just added the patch titled
PCI: hv: Properly handle PCI bus remove
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:
pci-hv-properly-handle-pci-bus-remove.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 Sun Mar 18 16:55:33 CET 2018
From: Long Li <longli(a)microsoft.com>
Date: Thu, 23 Mar 2017 14:58:10 -0700
Subject: PCI: hv: Properly handle PCI bus remove
From: Long Li <longli(a)microsoft.com>
[ Upstream commit d3a78d8bf759d8848339dcc367c4c1678b57a08b ]
hv_pci_devices_present() is called in hv_pci_remove() when we remove a PCI
device from the host, e.g., by disabling SR-IOV on a device. In
hv_pci_remove(), the bus is already removed before the call, so we don't
need to rescan the bus in the workqueue scheduled from
hv_pci_devices_present().
By introducing bus state hv_pcibus_removed, we can avoid this situation.
Reported-by: Xiaofeng Wang <xiaofwan(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-hyperv.c | 20 +++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -351,6 +351,7 @@ enum hv_pcibus_state {
hv_pcibus_init = 0,
hv_pcibus_probed,
hv_pcibus_installed,
+ hv_pcibus_removed,
hv_pcibus_maximum
};
@@ -1489,13 +1490,24 @@ static void pci_devices_present_work(str
put_pcichild(hpdev, hv_pcidev_ref_initial);
}
- /* Tell the core to rescan bus because there may have been changes. */
- if (hbus->state == hv_pcibus_installed) {
+ switch(hbus->state) {
+ case hv_pcibus_installed:
+ /*
+ * Tell the core to rescan bus
+ * because there may have been changes.
+ */
pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
- } else {
+ break;
+
+ case hv_pcibus_init:
+ case hv_pcibus_probed:
survey_child_resources(hbus);
+ break;
+
+ default:
+ break;
}
up(&hbus->enum_sem);
@@ -2170,6 +2182,7 @@ static int hv_pci_probe(struct hv_device
hbus = kzalloc(sizeof(*hbus), GFP_KERNEL);
if (!hbus)
return -ENOMEM;
+ hbus->state = hv_pcibus_init;
/*
* The PCI bus "domain" is what is called "segment" in ACPI and
@@ -2312,6 +2325,7 @@ static int hv_pci_remove(struct hv_devic
pci_stop_root_bus(hbus->pci_bus);
pci_remove_root_bus(hbus->pci_bus);
pci_unlock_rescan_remove();
+ hbus->state = hv_pcibus_removed;
}
ret = hv_send_resources_released(hdev);
Patches currently in stable-queue which might be from longli(a)microsoft.com are
queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch
queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch
This is a note to let you know that I've just added the patch titled
PCI: hv: Lock PCI bus on device eject
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:
pci-hv-lock-pci-bus-on-device-eject.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 Sun Mar 18 16:55:33 CET 2018
From: Long Li <longli(a)microsoft.com>
Date: Thu, 23 Mar 2017 14:58:32 -0700
Subject: PCI: hv: Lock PCI bus on device eject
From: Long Li <longli(a)microsoft.com>
[ Upstream commit 414428c5da1c71986727c2fa5cdf1ed071e398d7 ]
A PCI_EJECT message can arrive at the same time we are calling
pci_scan_child_bus() in the workqueue for the previous PCI_BUS_RELATIONS
message or in create_root_hv_pci_bus(). In this case we could potentially
modify the bus from multiple places.
Properly lock the bus access.
Thanks Dexuan Cui <decui(a)microsoft.com> for pointing out the race condition
in create_root_hv_pci_bus().
Reported-by: Xiaofeng Wang <xiaofwan(a)redhat.com>
Signed-off-by: Long Li <longli(a)microsoft.com>
Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com>
Acked-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/host/pci-hyperv.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/pci/host/pci-hyperv.c
+++ b/drivers/pci/host/pci-hyperv.c
@@ -1206,9 +1206,11 @@ static int create_root_hv_pci_bus(struct
hbus->pci_bus->msi = &hbus->msi_chip;
hbus->pci_bus->msi->dev = &hbus->hdev->device;
+ pci_lock_rescan_remove();
pci_scan_child_bus(hbus->pci_bus);
pci_bus_assign_resources(hbus->pci_bus);
pci_bus_add_devices(hbus->pci_bus);
+ pci_unlock_rescan_remove();
hbus->state = hv_pcibus_installed;
return 0;
}
@@ -1597,8 +1599,10 @@ static void hv_eject_device_work(struct
pdev = pci_get_domain_bus_and_slot(hpdev->hbus->sysdata.domain, 0,
wslot);
if (pdev) {
+ pci_lock_rescan_remove();
pci_stop_and_remove_bus_device(pdev);
pci_dev_put(pdev);
+ pci_unlock_rescan_remove();
}
memset(&ctxt, 0, sizeof(ctxt));
Patches currently in stable-queue which might be from longli(a)microsoft.com are
queue-4.9/pci-hv-lock-pci-bus-on-device-eject.patch
queue-4.9/pci-hv-properly-handle-pci-bus-remove.patch
This is a note to let you know that I've just added the patch titled
PCI: Apply Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices
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:
pci-apply-cavium-acs-quirk-only-to-cn81xx-cn83xx-cn88xx-devices.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 Sun Mar 18 16:55:33 CET 2018
From: Manish Jaggi <mjaggi(a)caviumnetworks.com>
Date: Thu, 30 Mar 2017 18:47:14 -0500
Subject: PCI: Apply Cavium ACS quirk only to CN81xx/CN83xx/CN88xx devices
From: Manish Jaggi <mjaggi(a)caviumnetworks.com>
[ Upstream commit b77d537d00d08fcf0bf641cd3491dd7df0ad1475 ]
Only apply the Cavium ACS quirk to devices with ID in the range
0xa000-0xa0ff. These are the on-chip PCI devices for CN81xx/CN83xx/CN88xx.
Fixes: b404bcfbf035 ("PCI: Add ACS quirk for all Cavium devices")
Reported-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Manish Jaggi <mjaggi(a)cavium.com>
Acked-by: David Daney <david.daney(a)cavium.com>
Acked-by: Alex Williamson <alex.williamson(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/pci/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4104,6 +4104,9 @@ static int pci_quirk_cavium_acs(struct p
*/
acs_flags &= ~(PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_SV | PCI_ACS_UF);
+ if (!((dev->device >= 0xa000) && (dev->device <= 0xa0ff)))
+ return -ENOTTY;
+
return acs_flags ? 0 : 1;
}
Patches currently in stable-queue which might be from mjaggi(a)caviumnetworks.com are
queue-4.9/pci-apply-cavium-acs-quirk-only-to-cn81xx-cn83xx-cn88xx-devices.patch
This is a note to let you know that I've just added the patch titled
omapfb: dss: Handle return errors in dss_init_ports()
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:
omapfb-dss-handle-return-errors-in-dss_init_ports.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 Sun Mar 18 16:55:33 CET 2018
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Date: Mon, 20 Mar 2017 18:30:59 +0100
Subject: omapfb: dss: Handle return errors in dss_init_ports()
From: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
[ Upstream commit 0348aaa34412e24ebe622a2b1b013e68d6ae5412 ]
dss_init_ports() is not handling return errors from dpi_init_port() and
sdi_init_port(). It is also always returning 0 currently which results in
part of error handling code in dss_bind() being unused.
Fix dss_init_ports() to handle return errors from dpi_init_port() and
sdi_init_port().
Signed-off-by: Arvind Yadav <arvind.yadav.cs(a)gmail.com>
Cc: tomi.valkeinen(a)ti.com
[b.zolnierkie: fail early on errors, minor fixups]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/video/fbdev/omap2/omapfb/dss/dss.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -941,11 +941,13 @@ static int dss_init_features(struct plat
return 0;
}
+static void dss_uninit_ports(struct platform_device *pdev);
+
static int dss_init_ports(struct platform_device *pdev)
{
struct device_node *parent = pdev->dev.of_node;
struct device_node *port;
- int r;
+ int r, ret = 0;
if (parent == NULL)
return 0;
@@ -972,17 +974,21 @@ static int dss_init_ports(struct platfor
switch (port_type) {
case OMAP_DISPLAY_TYPE_DPI:
- dpi_init_port(pdev, port);
+ ret = dpi_init_port(pdev, port);
break;
case OMAP_DISPLAY_TYPE_SDI:
- sdi_init_port(pdev, port);
+ ret = sdi_init_port(pdev, port);
break;
default:
break;
}
- } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+ } while (!ret &&
+ (port = omapdss_of_get_next_port(parent, port)) != NULL);
- return 0;
+ if (ret)
+ dss_uninit_ports(pdev);
+
+ return ret;
}
static void dss_uninit_ports(struct platform_device *pdev)
Patches currently in stable-queue which might be from arvind.yadav.cs(a)gmail.com are
queue-4.9/omapfb-dss-handle-return-errors-in-dss_init_ports.patch
This is a note to let you know that I've just added the patch titled
of: fix of_device_get_modalias returned length when truncating buffers
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:
of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.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 Sun Mar 18 16:55:33 CET 2018
From: Rob Herring <robh(a)kernel.org>
Date: Mon, 16 Jan 2017 14:28:39 -0600
Subject: of: fix of_device_get_modalias returned length when truncating buffers
From: Rob Herring <robh(a)kernel.org>
[ Upstream commit bcf54d5385abaea9c8026aae6f4eeb348671a52d ]
If the length of the modalias is greater than the buffer size, then the
modalias is truncated. However the untruncated length is returned which
will cause an error. Fix this to return the truncated length. If an error
in the case was desired, then then we should just return -ENOMEM.
The reality is no device will ever have 4KB of compatible strings to hit
this case.
Signed-off-by: Rob Herring <robh(a)kernel.org>
Cc: Frank Rowand <frowand.list(a)gmail.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/of/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -223,7 +223,7 @@ ssize_t of_device_get_modalias(struct de
str[i] = '_';
}
- return tsize;
+ return repend;
}
EXPORT_SYMBOL_GPL(of_device_get_modalias);
Patches currently in stable-queue which might be from robh(a)kernel.org are
queue-4.9/of-fix-of_device_get_modalias-returned-length-when-truncating-buffers.patch
This is a note to let you know that I've just added the patch titled
NFC: pn533: change order of free_irq and dev unregistration
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:
nfc-pn533-change-order-of-free_irq-and-dev-unregistration.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 Sun Mar 18 16:55:33 CET 2018
From: Andrey Rusalin <arusalin(a)dev.rtsoft.ru>
Date: Wed, 28 Dec 2016 20:10:57 +0300
Subject: NFC: pn533: change order of free_irq and dev unregistration
From: Andrey Rusalin <arusalin(a)dev.rtsoft.ru>
[ Upstream commit 068a496c4525c638ffab56449d905b88ef97fe32 ]
Change order of free_irq and dev unregistration.
It fixes situation when device already unregistered and
an interrupt happens and nobody can handle it.
Signed-off-by: Andrey Rusalin <arusalin(a)dev.rtsoft.ru>
Signed-off-by: Samuel Ortiz <sameo(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nfc/pn533/i2c.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/nfc/pn533/i2c.c
+++ b/drivers/nfc/pn533/i2c.c
@@ -242,10 +242,10 @@ static int pn533_i2c_remove(struct i2c_c
dev_dbg(&client->dev, "%s\n", __func__);
- pn533_unregister_device(phy->priv);
-
free_irq(client->irq, phy);
+ pn533_unregister_device(phy->priv);
+
return 0;
}
Patches currently in stable-queue which might be from arusalin(a)dev.rtsoft.ru are
queue-4.9/nfc-pn533-change-order-of-free_irq-and-dev-unregistration.patch
This is a note to let you know that I've just added the patch titled
NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
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:
nfc-nfcmrvl-include-unaligned.h-instead-of-access_ok.h.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 Sun Mar 18 16:55:33 CET 2018
From: Tobias Klauser <tklauser(a)distanz.ch>
Date: Wed, 26 Oct 2016 11:00:12 +0200
Subject: NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
From: Tobias Klauser <tklauser(a)distanz.ch>
[ Upstream commit d916d923724d59cde99ee588f15eec59dd863bbd ]
Including linux/unaligned/access_ok.h causes the allmodconfig build on
ia64 (and maybe others) to fail with the following warnings:
include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'
include/linux/unaligned/access_ok.h:12:19: error: redefinition of 'get_unaligned_le32'
include/linux/unaligned/access_ok.h:17:19: error: redefinition of 'get_unaligned_le64'
include/linux/unaligned/access_ok.h:22:19: error: redefinition of 'get_unaligned_be16'
include/linux/unaligned/access_ok.h:27:19: error: redefinition of 'get_unaligned_be32'
include/linux/unaligned/access_ok.h:32:19: error: redefinition of 'get_unaligned_be64'
include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_le64'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be16'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be32'
include/linux/unaligned/access_ok.h:42:20: error: redefinition of 'put_unaligned_be64'
Fix these by including asm/unaligned.h instead and leave it up to the
architecture to decide how to implement unaligned accesses.
Fixes: 3194c6870158 ("NFC: nfcmrvl: add firmware download support")
Reported-by: kbuild test robot <fengguang.wu(a)intel.com>
Link: https://lkml.org/lkml/2016/10/22/247
Cc: Vincent Cuissard <cuissard(a)marvell.com>
Signed-off-by: Tobias Klauser <tklauser(a)distanz.ch>
Signed-off-by: Samuel Ortiz <sameo(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nfc/nfcmrvl/fw_dnld.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/nfc/nfcmrvl/fw_dnld.c
+++ b/drivers/nfc/nfcmrvl/fw_dnld.c
@@ -17,7 +17,7 @@
*/
#include <linux/module.h>
-#include <linux/unaligned/access_ok.h>
+#include <asm/unaligned.h>
#include <linux/firmware.h>
#include <linux/nfc.h>
#include <net/nfc/nci.h>
Patches currently in stable-queue which might be from tklauser(a)distanz.ch are
queue-4.9/nfc-nfcmrvl-include-unaligned.h-instead-of-access_ok.h.patch
This is a note to let you know that I've just added the patch titled
NFC: nfcmrvl: double free on error path
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:
nfc-nfcmrvl-double-free-on-error-path.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 Sun Mar 18 16:55:33 CET 2018
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 8 Mar 2017 08:22:37 +0300
Subject: NFC: nfcmrvl: double free on error path
From: Dan Carpenter <dan.carpenter(a)oracle.com>
[ Upstream commit ca42fb9e52d155547e6cf18cf26bce3e1a6af4ea ]
The nci_spi_send() function calls kfree_skb(skb) on both error and
success so this extra kfree_skb() is a double free.
Fixes: caf6e49bf6d0 ("NFC: nfcmrvl: add spi driver")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Samuel Ortiz <sameo(a)linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/nfc/nfcmrvl/spi.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- a/drivers/nfc/nfcmrvl/spi.c
+++ b/drivers/nfc/nfcmrvl/spi.c
@@ -96,10 +96,9 @@ static int nfcmrvl_spi_nci_send(struct n
/* Send the SPI packet */
err = nci_spi_send(drv_data->nci_spi, &drv_data->handshake_completion,
skb);
- if (err != 0) {
+ if (err)
nfc_err(priv->dev, "spi_send failed %d", err);
- kfree_skb(skb);
- }
+
return err;
}
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.9/media-cpia2-fix-a-couple-off-by-one-bugs.patch
queue-4.9/nfc-nfcmrvl-double-free-on-error-path.patch
queue-4.9/asoc-nuc900-fix-a-loop-timeout-test.patch
This is a note to let you know that I've just added the patch titled
netem: apply correct delay when rate throttling
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:
netem-apply-correct-delay-when-rate-throttling.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 Sun Mar 18 16:55:33 CET 2018
From: Nik Unger <njunger(a)uwaterloo.ca>
Date: Mon, 13 Mar 2017 10:16:58 -0700
Subject: netem: apply correct delay when rate throttling
From: Nik Unger <njunger(a)uwaterloo.ca>
[ Upstream commit 5080f39e8c72e01cf37e8359023e7018e2a4901e ]
I recently reported on the netem list that iperf network benchmarks
show unexpected results when a bandwidth throttling rate has been
configured for netem. Specifically:
1) The measured link bandwidth *increases* when a higher delay is added
2) The measured link bandwidth appears higher than the specified limit
3) The measured link bandwidth for the same very slow settings varies significantly across
machines
The issue can be reproduced by using tc to configure netem with a
512kbit rate and various (none, 1us, 50ms, 100ms, 200ms) delays on a
veth pair between network namespaces, and then using iperf (or any
other network benchmarking tool) to test throughput. Complete detailed
instructions are in the original email chain here:
https://lists.linuxfoundation.org/pipermail/netem/2017-February/001672.html
There appear to be two underlying bugs causing these effects:
- The first issue causes long delays when the rate is slow and no
delay is configured (e.g., "rate 512kbit"). This is because SKBs are
not orphaned when no delay is configured, so orphaning does not
occur until *after* the rate-induced delay has been applied. For
this reason, adding a tiny delay (e.g., "rate 512kbit delay 1us")
dramatically increases the measured bandwidth.
- The second issue is that rate-induced delays are not correctly
applied, allowing SKB delays to occur in parallel. The indended
approach is to compute the delay for an SKB and to add this delay to
the end of the current queue. However, the code does not detect
existing SKBs in the queue due to improperly testing sch->q.qlen,
which is nonzero even when packets exist only in the
rbtree. Consequently, new SKBs do not wait for the current queue to
empty. When packet delays vary significantly (e.g., if packet sizes
are different), then this also causes unintended reordering.
I modified the code to expect a delay (and orphan the SKB) when a rate
is configured. I also added some defensive tests that correctly find
the latest scheduled delivery time, even if it is (unexpectedly) for a
packet in sch->q. I have tested these changes on the latest kernel
(4.11.0-rc1+) and the iperf / ping test results are as expected.
Signed-off-by: Nik Unger <njunger(a)uwaterloo.ca>
Signed-off-by: Stephen Hemminger <stephen(a)networkplumber.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/sched/sch_netem.c | 26 ++++++++++++++++++--------
1 file changed, 18 insertions(+), 8 deletions(-)
--- a/net/sched/sch_netem.c
+++ b/net/sched/sch_netem.c
@@ -462,7 +462,7 @@ static int netem_enqueue(struct sk_buff
/* If a delay is expected, orphan the skb. (orphaning usually takes
* place at TX completion time, so _before_ the link transit delay)
*/
- if (q->latency || q->jitter)
+ if (q->latency || q->jitter || q->rate)
skb_orphan_partial(skb);
/*
@@ -530,21 +530,31 @@ static int netem_enqueue(struct sk_buff
now = psched_get_time();
if (q->rate) {
- struct sk_buff *last;
+ struct netem_skb_cb *last = NULL;
+
+ if (sch->q.tail)
+ last = netem_skb_cb(sch->q.tail);
+ if (q->t_root.rb_node) {
+ struct sk_buff *t_skb;
+ struct netem_skb_cb *t_last;
+
+ t_skb = netem_rb_to_skb(rb_last(&q->t_root));
+ t_last = netem_skb_cb(t_skb);
+ if (!last ||
+ t_last->time_to_send > last->time_to_send) {
+ last = t_last;
+ }
+ }
- if (sch->q.qlen)
- last = sch->q.tail;
- else
- last = netem_rb_to_skb(rb_last(&q->t_root));
if (last) {
/*
* Last packet in queue is reference point (now),
* calculate this time bonus and subtract
* from delay.
*/
- delay -= netem_skb_cb(last)->time_to_send - now;
+ delay -= last->time_to_send - now;
delay = max_t(psched_tdiff_t, 0, delay);
- now = netem_skb_cb(last)->time_to_send;
+ now = last->time_to_send;
}
delay += packet_len_2_sched_time(qdisc_pkt_len(skb), q);
Patches currently in stable-queue which might be from njunger(a)uwaterloo.ca are
queue-4.9/netem-apply-correct-delay-when-rate-throttling.patch