This is a note to let you know that I've just added the patch titled
can: peak/pci: fix potential bug when probe() fails
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:
can-peak-pci-fix-potential-bug-when-probe-fails.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 5c2cb02edf79ad79d9b8d07c6d52243a948c4c9f Mon Sep 17 00:00:00 2001
From: Stephane Grosjean <s.grosjean(a)peak-system.com>
Date: Thu, 23 Nov 2017 15:44:35 +0100
Subject: can: peak/pci: fix potential bug when probe() fails
From: Stephane Grosjean <s.grosjean(a)peak-system.com>
commit 5c2cb02edf79ad79d9b8d07c6d52243a948c4c9f upstream.
PCI/PCIe drivers for PEAK-System CAN/CAN-FD interfaces do some access to the
PCI config during probing. In case one of these accesses fails, a POSITIVE
PCIBIOS_xxx error code is returned back. This POSITIVE error code MUST be
converted into a NEGATIVE errno for the probe() function to indicate it
failed. Using the pcibios_err_to_errno() function, we make sure that the
return code will always be negative.
Signed-off-by: Stephane Grosjean <s.grosjean(a)peak-system.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/peak_canfd/peak_pciefd_main.c | 5 ++++-
drivers/net/can/sja1000/peak_pci.c | 5 ++++-
2 files changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/net/can/peak_canfd/peak_pciefd_main.c
+++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c
@@ -825,7 +825,10 @@ err_release_regions:
err_disable_pci:
pci_disable_device(pdev);
- return err;
+ /* pci_xxx_config_word() return positive PCIBIOS_xxx error codes while
+ * the probe() function must return a negative errno in case of failure
+ * (err is unchanged if negative) */
+ return pcibios_err_to_errno(err);
}
/* free the board structure object, as well as its resources: */
--- a/drivers/net/can/sja1000/peak_pci.c
+++ b/drivers/net/can/sja1000/peak_pci.c
@@ -717,7 +717,10 @@ failure_release_regions:
failure_disable_pci:
pci_disable_device(pdev);
- return err;
+ /* pci_xxx_config_word() return positive PCIBIOS_xxx error codes while
+ * the probe() function must return a negative errno in case of failure
+ * (err is unchanged if negative) */
+ return pcibios_err_to_errno(err);
}
static void peak_pci_remove(struct pci_dev *pdev)
Patches currently in stable-queue which might be from s.grosjean(a)peak-system.com are
queue-4.14/can-peak-pcie_fd-fix-potential-bug-in-restarting-tx-queue.patch
queue-4.14/can-peak-pci-fix-potential-bug-when-probe-fails.patch
This is a note to let you know that I've just added the patch titled
can: mcba_usb: fix device disconnect 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:
can-mcba_usb-fix-device-disconnect-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 1cb35a33a28394fd711bb26ddf3a564f4e9d9125 Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Mon, 27 Nov 2017 15:49:16 -0800
Subject: can: mcba_usb: fix device disconnect bug
From: Martin Kelly <mkelly(a)xevo.com>
commit 1cb35a33a28394fd711bb26ddf3a564f4e9d9125 upstream.
Currently, when you disconnect the device, the driver infinitely
resubmits all URBs, so you see:
Rx URB aborted (-32)
in an infinite loop.
Fix this by catching -EPIPE (what we get in urb->status when the device
disconnects) and not resubmitting.
With this patch, I can plug and unplug many times and the driver
recovers correctly.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/mcba_usb.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/can/usb/mcba_usb.c
+++ b/drivers/net/can/usb/mcba_usb.c
@@ -592,6 +592,7 @@ static void mcba_usb_read_bulk_callback(
break;
case -ENOENT:
+ case -EPIPE:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch
queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch
This is a note to let you know that I've just added the patch titled
can: mcba_usb: cancel urb on -EPROTO
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:
can-mcba_usb-cancel-urb-on-eproto.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 c7f33023308f3142433b7379718af5f0c2c322a6 Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 10:34:03 -0800
Subject: can: mcba_usb: cancel urb on -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit c7f33023308f3142433b7379718af5f0c2c322a6 upstream.
When we unplug the device, we can see both -EPIPE and -EPROTO depending
on exact timing and what system we run on. If we continue to resubmit
URBs, they will immediately fail, and they can cause stalls, especially
on slower CPUs.
Fix this by not resubmitting on -EPROTO, as we already do on -EPIPE.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/mcba_usb.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/can/usb/mcba_usb.c
+++ b/drivers/net/can/usb/mcba_usb.c
@@ -593,6 +593,7 @@ static void mcba_usb_read_bulk_callback(
case -ENOENT:
case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch
queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: ratelimit errors if incomplete messages are received
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:
can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.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 8bd13bd522ff7dfa0eb371921aeb417155f7a3be Mon Sep 17 00:00:00 2001
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Date: Tue, 21 Nov 2017 08:22:28 +0100
Subject: can: kvaser_usb: ratelimit errors if incomplete messages are received
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
commit 8bd13bd522ff7dfa0eb371921aeb417155f7a3be upstream.
Avoid flooding the kernel log with "Formate error", if incomplete message
are received.
Signed-off-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -609,8 +609,8 @@ static int kvaser_usb_wait_msg(const str
}
if (pos + tmp->len > actual_len) {
- dev_err(dev->udev->dev.parent,
- "Format error\n");
+ dev_err_ratelimited(dev->udev->dev.parent,
+ "Format error\n");
break;
}
@@ -1353,7 +1353,8 @@ static void kvaser_usb_read_bulk_callbac
}
if (pos + msg->len > urb->actual_length) {
- dev_err(dev->udev->dev.parent, "Format error\n");
+ dev_err_ratelimited(dev->udev->dev.parent,
+ "Format error\n");
break;
}
Patches currently in stable-queue which might be from jimmyassarsson(a)gmail.com are
queue-4.14/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-4.14/can-kvaser_usb-free-buf-in-error-paths.patch
queue-4.14/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: free buf in error paths
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:
can-kvaser_usb-free-buf-in-error-paths.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 435019b48033138581a6171093b181fc6b4d3d30 Mon Sep 17 00:00:00 2001
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Date: Tue, 21 Nov 2017 08:22:26 +0100
Subject: can: kvaser_usb: free buf in error paths
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
commit 435019b48033138581a6171093b181fc6b4d3d30 upstream.
The allocated buffer was not freed if usb_submit_urb() failed.
Signed-off-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -813,6 +813,7 @@ static int kvaser_usb_simple_msg_async(s
if (err) {
netdev_err(netdev, "Error transmitting URB\n");
usb_unanchor_urb(urb);
+ kfree(buf);
usb_free_urb(urb);
return err;
}
@@ -1768,6 +1769,7 @@ static netdev_tx_t kvaser_usb_start_xmit
spin_unlock_irqrestore(&priv->tx_contexts_lock, flags);
usb_unanchor_urb(urb);
+ kfree(buf);
stats->tx_dropped++;
Patches currently in stable-queue which might be from jimmyassarsson(a)gmail.com are
queue-4.14/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-4.14/can-kvaser_usb-free-buf-in-error-paths.patch
queue-4.14/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()
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:
can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.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 e84f44eb5523401faeb9cc1c97895b68e3cfb78d Mon Sep 17 00:00:00 2001
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Date: Tue, 21 Nov 2017 08:22:27 +0100
Subject: can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
commit e84f44eb5523401faeb9cc1c97895b68e3cfb78d upstream.
The conditon in the while-loop becomes true when actual_length is less than
2 (MSG_HEADER_LEN). In best case we end up with a former, already
dispatched msg, that got msg->len greater than actual_length. This will
result in a "Format error" error printout.
Problem seen when unplugging a Kvaser USB device connected to a vbox guest.
warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
Signed-off-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1334,7 +1334,7 @@ static void kvaser_usb_read_bulk_callbac
goto resubmit_urb;
}
- while (pos <= urb->actual_length - MSG_HEADER_LEN) {
+ while (pos <= (int)(urb->actual_length - MSG_HEADER_LEN)) {
msg = urb->transfer_buffer + pos;
/* The Kvaser firmware can only read and write messages that
Patches currently in stable-queue which might be from jimmyassarsson(a)gmail.com are
queue-4.14/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-4.14/can-kvaser_usb-free-buf-in-error-paths.patch
queue-4.14/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
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:
can-kvaser_usb-cancel-urb-on-epipe-and-eproto.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 6aa8d5945502baf4687d80de59b7ac865e9e666b Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:49 -0800
Subject: can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit 6aa8d5945502baf4687d80de59b7ac865e9e666b upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -1326,6 +1326,8 @@ static void kvaser_usb_read_bulk_callbac
case 0:
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
default:
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch
queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch
This is a note to let you know that I've just added the patch titled
can: flexcan: fix VF610 state transition issue
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:
can-flexcan-fix-vf610-state-transition-issue.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 29c64b17a0bc72232acc45e9533221d88a262efb Mon Sep 17 00:00:00 2001
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
Date: Mon, 27 Nov 2017 09:18:21 +0100
Subject: can: flexcan: fix VF610 state transition issue
From: Marc Kleine-Budde <mkl(a)pengutronix.de>
commit 29c64b17a0bc72232acc45e9533221d88a262efb upstream.
Enable FLEXCAN_QUIRK_BROKEN_PERR_STATE for VF610 to report correct state
transitions.
Tested-by: Mirza Krak <mirza.krak(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/flexcan.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/drivers/net/can/flexcan.c
+++ b/drivers/net/can/flexcan.c
@@ -189,7 +189,7 @@
* MX35 FlexCAN2 03.00.00.00 no no ? no no
* MX53 FlexCAN2 03.00.00.00 yes no no no no
* MX6s FlexCAN3 10.00.12.00 yes yes no no yes
- * VF610 FlexCAN3 ? no yes ? yes yes?
+ * VF610 FlexCAN3 ? no yes no yes yes?
*
* Some SOCs do not have the RX_WARN & TX_WARN interrupt line connected.
*/
@@ -297,7 +297,8 @@ static const struct flexcan_devtype_data
static const struct flexcan_devtype_data fsl_vf610_devtype_data = {
.quirks = FLEXCAN_QUIRK_DISABLE_RXFG | FLEXCAN_QUIRK_ENABLE_EACEN_RRS |
- FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP,
+ FLEXCAN_QUIRK_DISABLE_MECR | FLEXCAN_QUIRK_USE_OFF_TIMESTAMP |
+ FLEXCAN_QUIRK_BROKEN_PERR_STATE,
};
static const struct can_bittiming_const flexcan_bittiming_const = {
Patches currently in stable-queue which might be from mkl(a)pengutronix.de are
queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch
queue-4.14/can-peak-pcie_fd-fix-potential-bug-in-restarting-tx-queue.patch
queue-4.14/can-flexcan-fix-vf610-state-transition-issue.patch
queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-ti_hecc-fix-napi-poll-return-value-for-repoll.patch
queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch
queue-4.14/can-peak-pci-fix-potential-bug-when-probe-fails.patch
queue-4.14/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-4.14/can-kvaser_usb-free-buf-in-error-paths.patch
queue-4.14/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: esd_usb2: cancel urb on -EPIPE and -EPROTO
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:
can-esd_usb2-cancel-urb-on-epipe-and-eproto.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 7a31ced3de06e9878e4f9c3abe8f87d9344d8144 Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:48 -0800
Subject: can: esd_usb2: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit 7a31ced3de06e9878e4f9c3abe8f87d9344d8144 upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/esd_usb2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/esd_usb2.c
+++ b/drivers/net/can/usb/esd_usb2.c
@@ -393,6 +393,8 @@ static void esd_usb2_read_bulk_callback(
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch
queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch
This is a note to let you know that I've just added the patch titled
can: ems_usb: cancel urb on -EPIPE and -EPROTO
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:
can-ems_usb-cancel-urb-on-epipe-and-eproto.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 bd352e1adfe0d02d3ea7c8e3fb19183dc317e679 Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:47 -0800
Subject: can: ems_usb: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit bd352e1adfe0d02d3ea7c8e3fb19183dc317e679 upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/ems_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -288,6 +288,8 @@ static void ems_usb_read_interrupt_callb
case -ECONNRESET: /* unlink */
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-4.14/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-fix-device-disconnect-bug.patch
queue-4.14/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
queue-4.14/can-mcba_usb-cancel-urb-on-eproto.patch
This is a note to let you know that I've just added the patch titled
can: usb_8dev: cancel urb on -EPIPE and -EPROTO
to the 3.18-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:
can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
and it can be found in the queue-3.18 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 12147edc434c9e4c7c2f5fee2e5519b2e5ac34ce Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:50 -0800
Subject: can: usb_8dev: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit 12147edc434c9e4c7c2f5fee2e5519b2e5ac34ce upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/usb_8dev.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/usb_8dev.c
+++ b/drivers/net/can/usb/usb_8dev.c
@@ -527,6 +527,8 @@ static void usb_8dev_read_bulk_callback(
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-3.18/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: ratelimit errors if incomplete messages are received
to the 3.18-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:
can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
and it can be found in the queue-3.18 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 8bd13bd522ff7dfa0eb371921aeb417155f7a3be Mon Sep 17 00:00:00 2001
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Date: Tue, 21 Nov 2017 08:22:28 +0100
Subject: can: kvaser_usb: ratelimit errors if incomplete messages are received
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
commit 8bd13bd522ff7dfa0eb371921aeb417155f7a3be upstream.
Avoid flooding the kernel log with "Formate error", if incomplete message
are received.
Signed-off-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -415,8 +415,8 @@ static int kvaser_usb_wait_msg(const str
}
if (pos + tmp->len > actual_len) {
- dev_err(dev->udev->dev.parent,
- "Format error\n");
+ dev_err_ratelimited(dev->udev->dev.parent,
+ "Format error\n");
break;
}
@@ -1007,7 +1007,8 @@ static void kvaser_usb_read_bulk_callbac
}
if (pos + msg->len > urb->actual_length) {
- dev_err(dev->udev->dev.parent, "Format error\n");
+ dev_err_ratelimited(dev->udev->dev.parent,
+ "Format error\n");
break;
}
Patches currently in stable-queue which might be from jimmyassarsson(a)gmail.com are
queue-3.18/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-3.18/can-kvaser_usb-free-buf-in-error-paths.patch
queue-3.18/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: free buf in error paths
to the 3.18-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:
can-kvaser_usb-free-buf-in-error-paths.patch
and it can be found in the queue-3.18 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 435019b48033138581a6171093b181fc6b4d3d30 Mon Sep 17 00:00:00 2001
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Date: Tue, 21 Nov 2017 08:22:26 +0100
Subject: can: kvaser_usb: free buf in error paths
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
commit 435019b48033138581a6171093b181fc6b4d3d30 upstream.
The allocated buffer was not freed if usb_submit_urb() failed.
Signed-off-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -602,6 +602,7 @@ static int kvaser_usb_simple_msg_async(s
if (err) {
netdev_err(netdev, "Error transmitting URB\n");
usb_unanchor_urb(urb);
+ kfree(buf);
usb_free_urb(urb);
kfree(buf);
return err;
@@ -1385,6 +1386,7 @@ static netdev_tx_t kvaser_usb_start_xmit
atomic_dec(&priv->active_tx_urbs);
usb_unanchor_urb(urb);
+ kfree(buf);
stats->tx_dropped++;
Patches currently in stable-queue which might be from jimmyassarsson(a)gmail.com are
queue-3.18/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-3.18/can-kvaser_usb-free-buf-in-error-paths.patch
queue-3.18/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()
to the 3.18-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:
can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
and it can be found in the queue-3.18 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 e84f44eb5523401faeb9cc1c97895b68e3cfb78d Mon Sep 17 00:00:00 2001
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Date: Tue, 21 Nov 2017 08:22:27 +0100
Subject: can: kvaser_usb: Fix comparison bug in kvaser_usb_read_bulk_callback()
From: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
commit e84f44eb5523401faeb9cc1c97895b68e3cfb78d upstream.
The conditon in the while-loop becomes true when actual_length is less than
2 (MSG_HEADER_LEN). In best case we end up with a former, already
dispatched msg, that got msg->len greater than actual_length. This will
result in a "Format error" error printout.
Problem seen when unplugging a Kvaser USB device connected to a vbox guest.
warning: comparison between signed and unsigned integer expressions
[-Wsign-compare]
Signed-off-by: Jimmy Assarsson <jimmyassarsson(a)gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -989,7 +989,7 @@ static void kvaser_usb_read_bulk_callbac
goto resubmit_urb;
}
- while (pos <= urb->actual_length - MSG_HEADER_LEN) {
+ while (pos <= (int)(urb->actual_length - MSG_HEADER_LEN)) {
msg = urb->transfer_buffer + pos;
/* The Kvaser firmware can only read and write messages that
Patches currently in stable-queue which might be from jimmyassarsson(a)gmail.com are
queue-3.18/can-kvaser_usb-ratelimit-errors-if-incomplete-messages-are-received.patch
queue-3.18/can-kvaser_usb-free-buf-in-error-paths.patch
queue-3.18/can-kvaser_usb-fix-comparison-bug-in-kvaser_usb_read_bulk_callback.patch
This is a note to let you know that I've just added the patch titled
can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
to the 3.18-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:
can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
and it can be found in the queue-3.18 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 6aa8d5945502baf4687d80de59b7ac865e9e666b Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:49 -0800
Subject: can: kvaser_usb: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit 6aa8d5945502baf4687d80de59b7ac865e9e666b upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/kvaser_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/kvaser_usb.c
+++ b/drivers/net/can/usb/kvaser_usb.c
@@ -981,6 +981,8 @@ static void kvaser_usb_read_bulk_callbac
case 0:
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
default:
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-3.18/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
This is a note to let you know that I've just added the patch titled
can: esd_usb2: cancel urb on -EPIPE and -EPROTO
to the 3.18-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:
can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
and it can be found in the queue-3.18 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 7a31ced3de06e9878e4f9c3abe8f87d9344d8144 Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:48 -0800
Subject: can: esd_usb2: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit 7a31ced3de06e9878e4f9c3abe8f87d9344d8144 upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/esd_usb2.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/esd_usb2.c
+++ b/drivers/net/can/usb/esd_usb2.c
@@ -395,6 +395,8 @@ static void esd_usb2_read_bulk_callback(
break;
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-3.18/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
This is a note to let you know that I've just added the patch titled
can: ems_usb: cancel urb on -EPIPE and -EPROTO
to the 3.18-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:
can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
and it can be found in the queue-3.18 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 bd352e1adfe0d02d3ea7c8e3fb19183dc317e679 Mon Sep 17 00:00:00 2001
From: Martin Kelly <mkelly(a)xevo.com>
Date: Tue, 5 Dec 2017 11:15:47 -0800
Subject: can: ems_usb: cancel urb on -EPIPE and -EPROTO
From: Martin Kelly <mkelly(a)xevo.com>
commit bd352e1adfe0d02d3ea7c8e3fb19183dc317e679 upstream.
In mcba_usb, we have observed that when you unplug the device, the driver will
endlessly resubmit failing URBs, which can cause CPU stalls. This issue
is fixed in mcba_usb by catching the codes seen on device disconnect
(-EPIPE and -EPROTO).
This driver also resubmits in the case of -EPIPE and -EPROTO, so fix it
in the same way.
Signed-off-by: Martin Kelly <mkelly(a)xevo.com>
Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/can/usb/ems_usb.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/net/can/usb/ems_usb.c
+++ b/drivers/net/can/usb/ems_usb.c
@@ -290,6 +290,8 @@ static void ems_usb_read_interrupt_callb
case -ECONNRESET: /* unlink */
case -ENOENT:
+ case -EPIPE:
+ case -EPROTO:
case -ESHUTDOWN:
return;
Patches currently in stable-queue which might be from mkelly(a)xevo.com are
queue-3.18/can-ems_usb-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-esd_usb2-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-usb_8dev-cancel-urb-on-epipe-and-eproto.patch
queue-3.18/can-kvaser_usb-cancel-urb-on-epipe-and-eproto.patch
The patch below was submitted to be applied to the 4.14-stable tree.
I fail to see how this patch meets the stable kernel rules as found at
Documentation/process/stable-kernel-rules.rst.
I could be totally wrong, and if so, please respond to
<stable(a)vger.kernel.org> and let me know why this patch should be
applied. Otherwise, it is now dropped from my patch queues, never to be
seen again.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From 23f1b8d938c861ee0bbb786162f7ce0685f722ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= <marcandre.lureau(a)redhat.com>
Date: Mon, 20 Nov 2017 10:55:15 +0100
Subject: [PATCH] fw_cfg: fix driver remove
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
On driver remove(), all objects created during probe() should be
removed, but sysfs qemu_fw_cfg/rev file was left. Also reorder
functions to match probe() error cleanup code.
Cc: stable(a)vger.kernel.org
Signed-off-by: Marc-André Lureau <marcandre.lureau(a)redhat.com>
Signed-off-by: Michael S. Tsirkin <mst(a)redhat.com>
diff --git a/drivers/firmware/qemu_fw_cfg.c b/drivers/firmware/qemu_fw_cfg.c
index 5cfe39f7a45f..deb483064f53 100644
--- a/drivers/firmware/qemu_fw_cfg.c
+++ b/drivers/firmware/qemu_fw_cfg.c
@@ -582,9 +582,10 @@ static int fw_cfg_sysfs_remove(struct platform_device *pdev)
{
pr_debug("fw_cfg: unloading.\n");
fw_cfg_sysfs_cache_cleanup();
+ sysfs_remove_file(fw_cfg_top_ko, &fw_cfg_rev_attr.attr);
+ fw_cfg_io_cleanup();
fw_cfg_kset_unregister_recursive(fw_cfg_fname_kset);
fw_cfg_kobj_cleanup(fw_cfg_sel_ko);
- fw_cfg_io_cleanup();
return 0;
}
The patch below does not apply to the 4.9-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From a3acc696085e112733d191a77b106e67a4fa110b Mon Sep 17 00:00:00 2001
From: John Keeping <john(a)metanate.com>
Date: Mon, 27 Nov 2017 18:15:40 +0000
Subject: [PATCH] usb: f_fs: Force Reserved1=1 in OS_DESC_EXT_COMPAT
The specification says that the Reserved1 field in OS_DESC_EXT_COMPAT
must have the value "1", but when this feature was first implemented we
rejected any non-zero values.
This was adjusted to accept all non-zero values (while now rejecting
zero) in commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on
reserved1 of OS_DESC_EXT_COMPAT"), but that breaks any userspace
programs that worked previously by returning EINVAL when Reserved1 == 0
which was previously the only value that succeeded!
If we just set the field to "1" ourselves, both old and new userspace
programs continue to work correctly and, as a bonus, old programs are
now compliant with the specification without having to fix anything
themselves.
Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: John Keeping <john(a)metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index 9aa457b53e01..b6cf5ab5a0a1 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2282,9 +2282,18 @@ static int __ffs_data_do_os_desc(enum ffs_os_desc_type type,
int i;
if (len < sizeof(*d) ||
- d->bFirstInterfaceNumber >= ffs->interfaces_count ||
- !d->Reserved1)
+ d->bFirstInterfaceNumber >= ffs->interfaces_count)
return -EINVAL;
+ if (d->Reserved1 != 1) {
+ /*
+ * According to the spec, Reserved1 must be set to 1
+ * but older kernels incorrectly rejected non-zero
+ * values. We fix it here to avoid returning EINVAL
+ * in response to values we used to accept.
+ */
+ pr_debug("usb_ext_compat_desc::Reserved1 forced to 1\n");
+ d->Reserved1 = 1;
+ }
for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i)
if (d->Reserved2[i])
return -EINVAL;
This is a note to let you know that I've just added the patch titled
locking/refcounts: Do not force refcount_t usage as GPL-only export
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:
locking-refcounts-do-not-force-refcount_t-usage-as-gpl-only-export.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 b562c171cf011d297059bd0265742eb5fab0ad2f Mon Sep 17 00:00:00 2001
From: Kees Cook <keescook(a)chromium.org>
Date: Mon, 4 Dec 2017 17:24:54 -0800
Subject: locking/refcounts: Do not force refcount_t usage as GPL-only export
From: Kees Cook <keescook(a)chromium.org>
commit b562c171cf011d297059bd0265742eb5fab0ad2f upstream.
The refcount_t protection on x86 was not intended to use the stricter
GPL export. This adjusts the linkage again to avoid a regression in
the availability of the refcount API.
Reported-by: Dave Airlie <airlied(a)gmail.com>
Fixes: 7a46ec0e2f48 ("locking/refcounts, x86/asm: Implement fast refcount overflow protection")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Ivan Kozik <ivan(a)ludios.org>
Cc: Thomas Backlund <tmb(a)mageia.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/mm/extable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/x86/mm/extable.c
+++ b/arch/x86/mm/extable.c
@@ -82,7 +82,7 @@ bool ex_handler_refcount(const struct ex
return true;
}
-EXPORT_SYMBOL_GPL(ex_handler_refcount);
+EXPORT_SYMBOL(ex_handler_refcount);
/*
* Handler for when we fail to restore a task's FPU state. We should never get
Patches currently in stable-queue which might be from keescook(a)chromium.org are
queue-4.14/locking-refcounts-x86-asm-use-unique-.text-section-for-refcount-exceptions.patch
queue-4.14/locking-refcounts-x86-asm-enable-config_arch_has_refcount.patch
queue-4.14/locking-refcounts-do-not-force-refcount_t-usage-as-gpl-only-export.patch
From: Michal Hocko <mhocko(a)suse.com>
David Rientjes has reported the following memory corruption while the
oom reaper tries to unmap the victims address space
BUG: Bad page map in process oom_reaper pte:6353826300000000 pmd:00000000
addr:00007f50cab1d000 vm_flags:08100073 anon_vma:ffff9eea335603f0 mapping: (null) index:7f50cab1d
file: (null) fault: (null) mmap: (null) readpage: (null)
CPU: 2 PID: 1001 Comm: oom_reaper
Call Trace:
[<ffffffffa4bd967d>] dump_stack+0x4d/0x70
[<ffffffffa4a03558>] unmap_page_range+0x1068/0x1130
[<ffffffffa4a2e07f>] __oom_reap_task_mm+0xd5/0x16b
[<ffffffffa4a2e226>] oom_reaper+0xff/0x14c
[<ffffffffa48d6ad1>] kthread+0xc1/0xe0
Tetsuo Handa has noticed that the synchronization inside exit_mmap is
insufficient. We only synchronize with the oom reaper if tsk_is_oom_victim
which is not true if the final __mmput is called from a different context
than the oom victim exit path. This can trivially happen from context of
any task which has grabbed mm reference (e.g. to read /proc/<pid>/ file
which requires mm etc.). The race would look like this
oom_reaper oom_victim task
mmget_not_zero
do_exit
mmput
__oom_reap_task_mm mmput
__mmput
exit_mmap
remove_vma
unmap_page_range
Fix this issue by providing a new mm_is_oom_victim() helper which operates
on the mm struct rather than a task. Any context which operates on a remote
mm struct should use this helper in place of tsk_is_oom_victim. The flag is
set in mark_oom_victim and never cleared so it is stable in the exit_mmap
path.
Changes since v1
- set MMF_OOM_SKIP in exit_mmap only for the oom mm as suggested by
Tetsuo because there is no reason to set the flag unless we are
synchronizing with the oom reaper.
- do not modify values of other MMF_ flags and add MMF_OOM_VICTIM
as the last one as requested by David Rientjes because they have
"automated tools that look at specific bits in mm->flags and it would
be nice to not have them be inconsistent between kernel versions.
Not absolutely required, but nice to avoid"
Reported-by: David Rientjes <rientjes(a)google.com>
Debugged-by: Tetsuo Handa <penguin-kernel(a)I-love.SAKURA.ne.jp>
Fixes: 212925802454 ("mm: oom: let oom_reap_task and exit_mmap run concurrently")
Cc: stable # 4.14
Acked-by: David Rientjes <rientjes(a)google.com>
Signed-off-by: Michal Hocko <mhocko(a)suse.com>
---
Hi,
this patch fixes issue reported by David [1][2].
[1] http://lkml.kernel.org/r/alpine.DEB.2.10.1712051824050.91099@chino.kir.corp…
[2] http://lkml.kernel.org/r/alpine.DEB.2.10.1712071315570.135101@chino.kir.cor…
include/linux/oom.h | 9 +++++++++
include/linux/sched/coredump.h | 1 +
mm/mmap.c | 10 +++++-----
mm/oom_kill.c | 4 +++-
4 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/include/linux/oom.h b/include/linux/oom.h
index 27cd36b762b5..c4139e79771d 100644
--- a/include/linux/oom.h
+++ b/include/linux/oom.h
@@ -77,6 +77,15 @@ static inline bool tsk_is_oom_victim(struct task_struct * tsk)
return tsk->signal->oom_mm;
}
+/*
+ * Use this helper if tsk->mm != mm and the victim mm needs a special
+ * handling. This is guaranteed to stay true after once set.
+ */
+static inline bool mm_is_oom_victim(struct mm_struct *mm)
+{
+ return test_bit(MMF_OOM_VICTIM, &mm->flags);
+}
+
/*
* Checks whether a page fault on the given mm is still reliable.
* This is no longer true if the oom reaper started to reap the
diff --git a/include/linux/sched/coredump.h b/include/linux/sched/coredump.h
index 9c8847395b5e..ec912d01126f 100644
--- a/include/linux/sched/coredump.h
+++ b/include/linux/sched/coredump.h
@@ -70,6 +70,7 @@ static inline int get_dumpable(struct mm_struct *mm)
#define MMF_UNSTABLE 22 /* mm is unstable for copy_from_user */
#define MMF_HUGE_ZERO_PAGE 23 /* mm has ever used the global huge zero page */
#define MMF_DISABLE_THP 24 /* disable THP for all VMAs */
+#define MMF_OOM_VICTIM 25 /* mm is the oom victim */
#define MMF_DISABLE_THP_MASK (1 << MMF_DISABLE_THP)
#define MMF_INIT_MASK (MMF_DUMPABLE_MASK | MMF_DUMP_FILTER_MASK |\
diff --git a/mm/mmap.c b/mm/mmap.c
index 476e810cf100..0de87a376aaa 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -3004,20 +3004,20 @@ void exit_mmap(struct mm_struct *mm)
/* Use -1 here to ensure all VMAs in the mm are unmapped */
unmap_vmas(&tlb, vma, 0, -1);
- set_bit(MMF_OOM_SKIP, &mm->flags);
- if (unlikely(tsk_is_oom_victim(current))) {
+ if (unlikely(mm_is_oom_victim(mm))) {
/*
* Wait for oom_reap_task() to stop working on this
* mm. Because MMF_OOM_SKIP is already set before
* calling down_read(), oom_reap_task() will not run
* on this "mm" post up_write().
*
- * tsk_is_oom_victim() cannot be set from under us
- * either because current->mm is already set to NULL
+ * mm_is_oom_victim() cannot be set from under us
+ * either because victim->mm is already set to NULL
* under task_lock before calling mmput and oom_mm is
- * set not NULL by the OOM killer only if current->mm
+ * set not NULL by the OOM killer only if victim->mm
* is found not NULL while holding the task_lock.
*/
+ set_bit(MMF_OOM_SKIP, &mm->flags);
down_write(&mm->mmap_sem);
up_write(&mm->mmap_sem);
}
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 3b0d0fed8480..e4d290b6804b 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -666,8 +666,10 @@ static void mark_oom_victim(struct task_struct *tsk)
return;
/* oom_mm is bound to the signal struct life time. */
- if (!cmpxchg(&tsk->signal->oom_mm, NULL, mm))
+ if (!cmpxchg(&tsk->signal->oom_mm, NULL, mm)) {
mmgrab(tsk->signal->oom_mm);
+ set_bit(MMF_OOM_VICTIM, &mm->flags);
+ }
/*
* Make sure that the task is woken up from uninterruptible sleep
--
2.15.0