From: Greg Kroah-Hartman Date: Wed, 24 Jul 2019 14:30:05 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.2.3~8 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=953241a6665819c69a9a8ec78d27e78e61e7e8d4;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: blk-iolatency-clear-use_delay-when-io.latency-is-set-to-zero.patch blk-throttle-fix-zero-wait-time-for-iops-throttled-group.patch blkcg-update-blkcg_print_stat-to-handle-larger-outputs.patch 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 --- diff --git a/queue-4.19/blk-iolatency-clear-use_delay-when-io.latency-is-set-to-zero.patch b/queue-4.19/blk-iolatency-clear-use_delay-when-io.latency-is-set-to-zero.patch new file mode 100644 index 00000000000..23caa94bdd6 --- /dev/null +++ b/queue-4.19/blk-iolatency-clear-use_delay-when-io.latency-is-set-to-zero.patch @@ -0,0 +1,39 @@ +From 5de0073fcd50cc1f150895a7bb04d3cf8067b1d7 Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Thu, 13 Jun 2019 15:30:37 -0700 +Subject: blk-iolatency: clear use_delay when io.latency is set to zero + +From: Tejun Heo + +commit 5de0073fcd50cc1f150895a7bb04d3cf8067b1d7 upstream. + +If use_delay was non-zero when the latency target of a cgroup was set +to zero, it will stay stuck until io.latency is enabled on the cgroup +again. This keeps readahead disabled for the cgroup impacting +performance negatively. + +Signed-off-by: Tejun Heo +Cc: Josef Bacik +Fixes: d70675121546 ("block: introduce blk-iolatency io controller") +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/blk-iolatency.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/block/blk-iolatency.c ++++ b/block/blk-iolatency.c +@@ -746,8 +746,10 @@ static int iolatency_set_min_lat_nsec(st + + if (!oldval && val) + return 1; +- if (oldval && !val) ++ if (oldval && !val) { ++ blkcg_clear_delay(blkg); + return -1; ++ } + return 0; + } + diff --git a/queue-4.19/blk-throttle-fix-zero-wait-time-for-iops-throttled-group.patch b/queue-4.19/blk-throttle-fix-zero-wait-time-for-iops-throttled-group.patch new file mode 100644 index 00000000000..7786f11bed4 --- /dev/null +++ b/queue-4.19/blk-throttle-fix-zero-wait-time-for-iops-throttled-group.patch @@ -0,0 +1,46 @@ +From 3a10f999ffd464d01c5a05592a15470a3c4bbc36 Mon Sep 17 00:00:00 2001 +From: Konstantin Khlebnikov +Date: Mon, 8 Jul 2019 18:29:57 +0300 +Subject: blk-throttle: fix zero wait time for iops throttled group + +From: Konstantin Khlebnikov + +commit 3a10f999ffd464d01c5a05592a15470a3c4bbc36 upstream. + +After commit 991f61fe7e1d ("Blk-throttle: reduce tail io latency when +iops limit is enforced") wait time could be zero even if group is +throttled and cannot issue requests right now. As a result +throtl_select_dispatch() turns into busy-loop under irq-safe queue +spinlock. + +Fix is simple: always round up target time to the next throttle slice. + +Fixes: 991f61fe7e1d ("Blk-throttle: reduce tail io latency when iops limit is enforced") +Signed-off-by: Konstantin Khlebnikov +Cc: stable@vger.kernel.org # v4.19+ +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/blk-throttle.c | 9 +++------ + 1 file changed, 3 insertions(+), 6 deletions(-) + +--- a/block/blk-throttle.c ++++ b/block/blk-throttle.c +@@ -892,13 +892,10 @@ static bool tg_with_in_iops_limit(struct + unsigned long jiffy_elapsed, jiffy_wait, jiffy_elapsed_rnd; + u64 tmp; + +- jiffy_elapsed = jiffy_elapsed_rnd = jiffies - tg->slice_start[rw]; ++ jiffy_elapsed = jiffies - tg->slice_start[rw]; + +- /* Slice has just started. Consider one slice interval */ +- if (!jiffy_elapsed) +- jiffy_elapsed_rnd = tg->td->throtl_slice; +- +- jiffy_elapsed_rnd = roundup(jiffy_elapsed_rnd, tg->td->throtl_slice); ++ /* Round up to the next throttle slice, wait time must be nonzero */ ++ jiffy_elapsed_rnd = roundup(jiffy_elapsed + 1, tg->td->throtl_slice); + + /* + * jiffy_elapsed_rnd should not be a big value as minimum iops can be diff --git a/queue-4.19/blkcg-update-blkcg_print_stat-to-handle-larger-outputs.patch b/queue-4.19/blkcg-update-blkcg_print_stat-to-handle-larger-outputs.patch new file mode 100644 index 00000000000..6f5defb65c7 --- /dev/null +++ b/queue-4.19/blkcg-update-blkcg_print_stat-to-handle-larger-outputs.patch @@ -0,0 +1,44 @@ +From f539da82f2158916e154d206054e0efd5df7ab61 Mon Sep 17 00:00:00 2001 +From: Tejun Heo +Date: Thu, 13 Jun 2019 15:30:38 -0700 +Subject: blkcg: update blkcg_print_stat() to handle larger outputs + +From: Tejun Heo + +commit f539da82f2158916e154d206054e0efd5df7ab61 upstream. + +Depending on the number of devices, blkcg stats can go over the +default seqfile buf size. seqfile normally retries with a larger +buffer but since the ->pd_stat() addition, blkcg_print_stat() doesn't +tell seqfile that overflow has happened and the output gets printed +truncated. Fix it by calling seq_commit() w/ -1 on possible +overflows. + +Signed-off-by: Tejun Heo +Fixes: 903d23f0a354 ("blk-cgroup: allow controllers to output their own stats") +Cc: stable@vger.kernel.org # v4.19+ +Cc: Josef Bacik +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + block/blk-cgroup.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/block/blk-cgroup.c ++++ b/block/blk-cgroup.c +@@ -1016,8 +1016,12 @@ static int blkcg_print_stat(struct seq_f + } + next: + if (has_stats) { +- off += scnprintf(buf+off, size-off, "\n"); +- seq_commit(sf, off); ++ if (off < size - 1) { ++ off += scnprintf(buf+off, size-off, "\n"); ++ seq_commit(sf, off); ++ } else { ++ seq_commit(sf, -1); ++ } + } + } + diff --git a/queue-4.19/dm-bufio-fix-deadlock-with-loop-device.patch b/queue-4.19/dm-bufio-fix-deadlock-with-loop-device.patch new file mode 100644 index 00000000000..324ff8e2133 --- /dev/null +++ b/queue-4.19/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 +@@ -1602,9 +1602,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.19/dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch b/queue-4.19/dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch new file mode 100644 index 00000000000..52a5b47e0a8 --- /dev/null +++ b/queue-4.19/dt-bindings-allow-up-to-four-clocks-for-orion-mdio.patch @@ -0,0 +1,34 @@ +From 80785f5a22e9073e2ded5958feb7f220e066d17b Mon Sep 17 00:00:00 2001 +From: Josua Mayer +Date: Tue, 9 Jul 2019 15:00:58 +0200 +Subject: dt-bindings: allow up to four clocks for orion-mdio + +From: Josua Mayer + +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 +Signed-off-by: Josua Mayer +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + 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.19/net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch b/queue-4.19/net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch new file mode 100644 index 00000000000..babc9d57451 --- /dev/null +++ b/queue-4.19/net-mvmdio-allow-up-to-four-clocks-to-be-specified-for-orion-mdio.patch @@ -0,0 +1,39 @@ +From 4aabed699c400810981d3dda170f05fa4d782905 Mon Sep 17 00:00:00 2001 +From: Josua Mayer +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 + +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 +Signed-off-by: Josua Mayer +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.19/series b/queue-4.19/series index 1bf46de5255..b7fd946e987 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -262,3 +262,10 @@ mtd-rawnand-mtk-correct-low-level-time-calculation-of-r-w-cycle.patch mtd-spinand-read-returns-badly-if-the-last-page-has-bitflips.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 +blk-throttle-fix-zero-wait-time-for-iops-throttled-group.patch +blk-iolatency-clear-use_delay-when-io.latency-is-set-to-zero.patch +blkcg-update-blkcg_print_stat-to-handle-larger-outputs.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.19/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch b/queue-4.19/usb-handle-usb3-remote-wakeup-for-lpm-enabled-devices-correctly.patch new file mode 100644 index 00000000000..6d348db5749 --- /dev/null +++ b/queue-4.19/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 +@@ -3575,6 +3575,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; +@@ -3584,9 +3585,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; + } +