From 1289c881d200567f3762a629ee726da4d57663cf Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 24 Jul 2019 16:29:27 +0200 Subject: [PATCH] 4.9-stable patches added patches: dm-bufio-fix-deadlock-with-loop-device.patch usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch --- ...-bufio-fix-deadlock-with-loop-device.patch | 47 +++++++++++++++ queue-4.9/series | 2 + ...up-for-lpm-enabled-devices-correctly.patch | 59 +++++++++++++++++++ 3 files changed, 108 insertions(+) create mode 100644 queue-4.9/dm-bufio-fix-deadlock-with-loop-device.patch create mode 100644 queue-4.9/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch diff --git a/queue-4.9/dm-bufio-fix-deadlock-with-loop-device.patch b/queue-4.9/dm-bufio-fix-deadlock-with-loop-device.patch new file mode 100644 index 00000000000..3585917ac9a --- /dev/null +++ b/queue-4.9/dm-bufio-fix-deadlock-with-loop-device.patch @@ -0,0 +1,47 @@ +From bd293d071ffe65e645b4d8104f9d8fe15ea13862 Mon Sep 17 00:00:00 2001 +From: Junxiao Bi +Date: Tue, 9 Jul 2019 17:17:19 -0700 +Subject: dm bufio: fix deadlock with loop device + +From: Junxiao Bi + +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 +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1585,9 +1585,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.9/series b/queue-4.9/series index de19aea973b..29789e55250 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -121,3 +121,5 @@ 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 +dm-bufio-fix-deadlock-with-loop-device.patch diff --git a/queue-4.9/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch b/queue-4.9/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch new file mode 100644 index 00000000000..b35936e23ae --- /dev/null +++ b/queue-4.9/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch @@ -0,0 +1,59 @@ +From e244c4699f859cf7149b0781b1894c7996a8a1df Mon Sep 17 00:00:00 2001 +From: "Lee, Chiasheng" +Date: Thu, 20 Jun 2019 10:56:04 +0300 +Subject: usb: Handle USB3 remote wakeup for LPM enabled devices correctly + +From: Lee, Chiasheng + +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: # v4.13+ +Signed-off-by: Lee, Chiasheng +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -3535,6 +3535,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; +@@ -3544,9 +3545,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; + } + -- 2.47.3