]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.14-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 24 Jul 2019 14:29:46 +0000 (16:29 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 24 Jul 2019 14:29:46 +0000 (16:29 +0200)
added patches:
dm-bufio-fix-deadlock-with-loop-device.patch
dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch
net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch
usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch

queue-4.14/dm-bufio-fix-deadlock-with-loop-device.patch [new file with mode: 0644]
queue-4.14/dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch [new file with mode: 0644]
queue-4.14/net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch [new file with mode: 0644]
queue-4.14/series
queue-4.14/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch [new file with mode: 0644]

diff --git a/queue-4.14/dm-bufio-fix-deadlock-with-loop-device.patch b/queue-4.14/dm-bufio-fix-deadlock-with-loop-device.patch
new file mode 100644 (file)
index 0000000..c2e90ee
--- /dev/null
@@ -0,0 +1,47 @@
+From bd293d071ffe65e645b4d8104f9d8fe15ea13862 Mon Sep 17 00:00:00 2001
+From: Junxiao Bi <junxiao.bi@oracle.com>
+Date: Tue, 9 Jul 2019 17:17:19 -0700
+Subject: dm bufio: fix deadlock with loop device
+
+From: Junxiao Bi <junxiao.bi@oracle.com>
+
+commit bd293d071ffe65e645b4d8104f9d8fe15ea13862 upstream.
+
+When thin-volume is built on loop device, if available memory is low,
+the following deadlock can be triggered:
+
+One process P1 allocates memory with GFP_FS flag, direct alloc fails,
+memory reclaim invokes memory shrinker in dm_bufio, dm_bufio_shrink_scan()
+runs, mutex dm_bufio_client->lock is acquired, then P1 waits for dm_buffer
+IO to complete in __try_evict_buffer().
+
+But this IO may never complete if issued to an underlying loop device
+that forwards it using direct-IO, which allocates memory using
+GFP_KERNEL (see: do_blockdev_direct_IO()).  If allocation fails, memory
+reclaim will invoke memory shrinker in dm_bufio, dm_bufio_shrink_scan()
+will be invoked, and since the mutex is already held by P1 the loop
+thread will hang, and IO will never complete.  Resulting in ABBA
+deadlock.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-bufio.c |    4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/drivers/md/dm-bufio.c
++++ b/drivers/md/dm-bufio.c
+@@ -1630,9 +1630,7 @@ dm_bufio_shrink_scan(struct shrinker *sh
+       unsigned long freed;
+       c = container_of(shrink, struct dm_bufio_client, shrinker);
+-      if (sc->gfp_mask & __GFP_FS)
+-              dm_bufio_lock(c);
+-      else if (!dm_bufio_trylock(c))
++      if (!dm_bufio_trylock(c))
+               return SHRINK_STOP;
+       freed  = __scan(c, sc->nr_to_scan, sc->gfp_mask);
diff --git a/queue-4.14/dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch b/queue-4.14/dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch
new file mode 100644 (file)
index 0000000..52a5b47
--- /dev/null
@@ -0,0 +1,34 @@
+From 80785f5a22e9073e2ded5958feb7f220e066d17b Mon Sep 17 00:00:00 2001
+From: Josua Mayer <josua@solid-run.com>
+Date: Tue, 9 Jul 2019 15:00:58 +0200
+Subject: dt-bindings: allow up to four clocks for orion-mdio
+
+From: Josua Mayer <josua@solid-run.com>
+
+commit 80785f5a22e9073e2ded5958feb7f220e066d17b upstream.
+
+Armada 8040 needs four clocks to be enabled for MDIO accesses to work.
+Update the binding to allow the extra clock to be specified.
+
+Cc: stable@vger.kernel.org
+Fixes: 6d6a331f44a1 ("dt-bindings: allow up to three clocks for orion-mdio")
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Josua Mayer <josua@solid-run.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/devicetree/bindings/net/marvell-orion-mdio.txt |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
++++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
+@@ -16,7 +16,7 @@ Required properties:
+ Optional properties:
+ - interrupts: interrupt line number for the SMI error/done interrupt
+-- clocks: phandle for up to three required clocks for the MDIO instance
++- clocks: phandle for up to four required clocks for the MDIO instance
+ The child nodes of the MDIO driver are the individual PHY devices
+ connected to this MDIO bus. They must have a "reg" property given the
diff --git a/queue-4.14/net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch b/queue-4.14/net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch
new file mode 100644 (file)
index 0000000..babc9d5
--- /dev/null
@@ -0,0 +1,39 @@
+From 4aabed699c400810981d3dda170f05fa4d782905 Mon Sep 17 00:00:00 2001
+From: Josua Mayer <josua@solid-run.com>
+Date: Tue, 9 Jul 2019 15:00:59 +0200
+Subject: net: mvmdio: allow up to four clocks to be specified for orion-mdio
+
+From: Josua Mayer <josua@solid-run.com>
+
+commit 4aabed699c400810981d3dda170f05fa4d782905 upstream.
+
+Allow up to four clocks to be specified and enabled for the orion-mdio
+interface, which are required by the Armada 8k and defined in
+armada-cp110.dtsi.
+
+Fixes a hang in probing the mvmdio driver that was encountered on the
+Clearfog GT 8K with all drivers built as modules, but also affects other
+boards such as the MacchiatoBIN.
+
+Cc: stable@vger.kernel.org
+Fixes: 96cb43423822 ("net: mvmdio: allow up to three clocks to be specified for orion-mdio")
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Josua Mayer <josua@solid-run.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/marvell/mvmdio.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/marvell/mvmdio.c
++++ b/drivers/net/ethernet/marvell/mvmdio.c
+@@ -64,7 +64,7 @@
+ struct orion_mdio_dev {
+       void __iomem *regs;
+-      struct clk *clk[3];
++      struct clk *clk[4];
+       /*
+        * If we have access to the error interrupt pin (which is
+        * somewhat misnamed as it not only reflects internal errors
index b28a769002791f68ae49436f3fd481d993deee06..9673d8584ab336818ca169a2659178f15d55d517 100644 (file)
@@ -172,3 +172,7 @@ powerpc-watchpoint-restore-nv-gprs-while-returning-from-exception.patch
 ecryptfs-fix-a-couple-type-promotion-bugs.patch
 intel_th-msu-fix-single-mode-with-disabled-iommu.patch
 bluetooth-add-smp-workaround-microsoft-surface-precision-mouse-bug.patch
+usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch
+net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch
+dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch
+dm-bufio-fix-deadlock-with-loop-device.patch
diff --git a/queue-4.14/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch b/queue-4.14/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch
new file mode 100644 (file)
index 0000000..5f95064
--- /dev/null
@@ -0,0 +1,59 @@
+From e244c4699f859cf7149b0781b1894c7996a8a1df Mon Sep 17 00:00:00 2001
+From: "Lee, Chiasheng" <chiasheng.lee@intel.com>
+Date: Thu, 20 Jun 2019 10:56:04 +0300
+Subject: usb: Handle USB3 remote wakeup for LPM enabled devices correctly
+
+From: Lee, Chiasheng <chiasheng.lee@intel.com>
+
+commit e244c4699f859cf7149b0781b1894c7996a8a1df upstream.
+
+With Link Power Management (LPM) enabled USB3 links transition to low
+power U1/U2 link states from U0 state automatically.
+
+Current hub code detects USB3 remote wakeups by checking if the software
+state still shows suspended, but the link has transitioned from suspended
+U3 to enabled U0 state.
+
+As it takes some time before the hub thread reads the port link state
+after a USB3 wake notification, the link may have transitioned from U0
+to U1/U2, and wake is not detected by hub code.
+
+Fix this by handling U1/U2 states in the same way as U0 in USB3 wakeup
+handling
+
+This patch should be added to stable kernels since 4.13 where LPM was
+kept enabled during suspend/resume
+
+Cc: <stable@vger.kernel.org> # v4.13+
+Signed-off-by: Lee, Chiasheng <chiasheng.lee@intel.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/usb/core/hub.c |    7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -3532,6 +3532,7 @@ static int hub_handle_remote_wakeup(stru
+       struct usb_device *hdev;
+       struct usb_device *udev;
+       int connect_change = 0;
++      u16 link_state;
+       int ret;
+       hdev = hub->hdev;
+@@ -3541,9 +3542,11 @@ static int hub_handle_remote_wakeup(stru
+                       return 0;
+               usb_clear_port_feature(hdev, port, USB_PORT_FEAT_C_SUSPEND);
+       } else {
++              link_state = portstatus & USB_PORT_STAT_LINK_STATE;
+               if (!udev || udev->state != USB_STATE_SUSPENDED ||
+-                               (portstatus & USB_PORT_STAT_LINK_STATE) !=
+-                               USB_SS_PORT_LS_U0)
++                              (link_state != USB_SS_PORT_LS_U0 &&
++                               link_state != USB_SS_PORT_LS_U1 &&
++                               link_state != USB_SS_PORT_LS_U2))
+                       return 0;
+       }