]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
Fixes for 5.7
authorSasha Levin <sashal@kernel.org>
Mon, 22 Jun 2020 22:44:13 +0000 (18:44 -0400)
committerSasha Levin <sashal@kernel.org>
Mon, 22 Jun 2020 22:44:13 +0000 (18:44 -0400)
Signed-off-by: Sasha Levin <sashal@kernel.org>
queue-5.7/drm-dp_mst-increase-act-retry-timeout-to-3s.patch [new file with mode: 0644]
queue-5.7/ext4-avoid-race-conditions-when-remounting-with-opti.patch [new file with mode: 0644]
queue-5.7/series

diff --git a/queue-5.7/drm-dp_mst-increase-act-retry-timeout-to-3s.patch b/queue-5.7/drm-dp_mst-increase-act-retry-timeout-to-3s.patch
new file mode 100644 (file)
index 0000000..61d373a
--- /dev/null
@@ -0,0 +1,135 @@
+From d351ebd787e2f7a9df89e29fcafea9aa3f99871e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 3 Apr 2020 15:47:15 -0400
+Subject: drm/dp_mst: Increase ACT retry timeout to 3s
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Lyude Paul <lyude@redhat.com>
+
+[ Upstream commit 873a95e0d59ac06901ae261dda0b7165ffd002b8 ]
+
+Currently we only poll for an ACT up to 30 times, with a busy-wait delay
+of 100µs between each attempt - giving us a timeout of 2900µs. While
+this might seem sensible, it would appear that in certain scenarios it
+can take dramatically longer then that for us to receive an ACT. On one
+of the EVGA MST hubs that I have available, I observed said hub
+sometimes taking longer then a second before signalling the ACT. These
+delays mostly seem to occur when previous sideband messages we've sent
+are NAKd by the hub, however it wouldn't be particularly surprising if
+it's possible to reproduce times like this simply by introducing branch
+devices with large LCTs since payload allocations have to take effect on
+every downstream device up to the payload's target.
+
+So, instead of just retrying 30 times we poll for the ACT for up to 3ms,
+and additionally use usleep_range() to avoid a very long and rude
+busy-wait. Note that the previous retry count of 30 appears to have been
+arbitrarily chosen, as I can't find any mention of a recommended timeout
+or retry count for ACTs in the DisplayPort 2.0 specification. This also
+goes for the range we were previously using for udelay(), although I
+suspect that was just copied from the recommended delay for link
+training on SST devices.
+
+Changes since v1:
+* Use readx_poll_timeout() instead of open-coding timeout loop - Sean
+  Paul
+Changes since v2:
+* Increase poll interval to 200us - Sean Paul
+* Print status in hex when we timeout waiting for ACT - Sean Paul
+
+Signed-off-by: Lyude Paul <lyude@redhat.com>
+Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
+Cc: Sean Paul <sean@poorly.run>
+Cc: <stable@vger.kernel.org> # v3.17+
+Reviewed-by: Sean Paul <sean@poorly.run>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/drm_dp_mst_topology.c | 54 ++++++++++++++++-----------
+ 1 file changed, 32 insertions(+), 22 deletions(-)
+
+diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c
+index b521f64172893..abb1f358ec6df 100644
+--- a/drivers/gpu/drm/drm_dp_mst_topology.c
++++ b/drivers/gpu/drm/drm_dp_mst_topology.c
+@@ -27,6 +27,7 @@
+ #include <linux/kernel.h>
+ #include <linux/sched.h>
+ #include <linux/seq_file.h>
++#include <linux/iopoll.h>
+ #if IS_ENABLED(CONFIG_DRM_DEBUG_DP_MST_TOPOLOGY_REFS)
+ #include <linux/stacktrace.h>
+@@ -4448,6 +4449,17 @@ static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
+       return ret;
+ }
++static int do_get_act_status(struct drm_dp_aux *aux)
++{
++      int ret;
++      u8 status;
++
++      ret = drm_dp_dpcd_readb(aux, DP_PAYLOAD_TABLE_UPDATE_STATUS, &status);
++      if (ret < 0)
++              return ret;
++
++      return status;
++}
+ /**
+  * drm_dp_check_act_status() - Check ACT handled status.
+@@ -4457,30 +4469,28 @@ static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr,
+  */
+ int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr)
+ {
+-      int count = 0, ret;
+-      u8 status;
+-
+-      do {
+-              ret = drm_dp_dpcd_readb(mgr->aux,
+-                                      DP_PAYLOAD_TABLE_UPDATE_STATUS,
+-                                      &status);
+-              if (ret < 0) {
+-                      DRM_DEBUG_KMS("failed to read payload table status %d\n",
+-                                    ret);
+-                      return ret;
+-              }
+-
+-              if (status & DP_PAYLOAD_ACT_HANDLED)
+-                      break;
+-              count++;
+-              udelay(100);
+-      } while (count < 30);
+-
+-      if (!(status & DP_PAYLOAD_ACT_HANDLED)) {
+-              DRM_DEBUG_KMS("failed to get ACT bit %d after %d retries\n",
+-                            status, count);
++      /*
++       * There doesn't seem to be any recommended retry count or timeout in
++       * the MST specification. Since some hubs have been observed to take
++       * over 1 second to update their payload allocations under certain
++       * conditions, we use a rather large timeout value.
++       */
++      const int timeout_ms = 3000;
++      int ret, status;
++
++      ret = readx_poll_timeout(do_get_act_status, mgr->aux, status,
++                               status & DP_PAYLOAD_ACT_HANDLED || status < 0,
++                               200, timeout_ms * USEC_PER_MSEC);
++      if (ret < 0 && status >= 0) {
++              DRM_DEBUG_KMS("Failed to get ACT after %dms, last status: %02x\n",
++                            timeout_ms, status);
+               return -EINVAL;
++      } else if (status < 0) {
++              DRM_DEBUG_KMS("Failed to read payload table status: %d\n",
++                            status);
++              return status;
+       }
++
+       return 0;
+ }
+ EXPORT_SYMBOL(drm_dp_check_act_status);
+-- 
+2.25.1
+
diff --git a/queue-5.7/ext4-avoid-race-conditions-when-remounting-with-opti.patch b/queue-5.7/ext4-avoid-race-conditions-when-remounting-with-opti.patch
new file mode 100644 (file)
index 0000000..b30d3c1
--- /dev/null
@@ -0,0 +1,75 @@
+From 6c2e8cacfacdd20f266df49f143fe7359c8306f7 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 10 Jun 2020 11:16:37 -0400
+Subject: ext4: avoid race conditions when remounting with options that change
+ dax
+
+From: Theodore Ts'o <tytso@mit.edu>
+
+[ Upstream commit 829b37b8cddb1db75c1b7905505b90e593b15db1 ]
+
+Trying to change dax mount options when remounting could allow mount
+options to be enabled for a small amount of time, and then the mount
+option change would be reverted.
+
+In the case of "mount -o remount,dax", this can cause a race where
+files would temporarily treated as DAX --- and then not.
+
+Cc: stable@kernel.org
+Reported-by: syzbot+bca9799bf129256190da@syzkaller.appspotmail.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/ext4/super.c | 22 ++++++++++------------
+ 1 file changed, 10 insertions(+), 12 deletions(-)
+
+diff --git a/fs/ext4/super.c b/fs/ext4/super.c
+index d23afd6c909de..7318ca71b69eb 100644
+--- a/fs/ext4/super.c
++++ b/fs/ext4/super.c
+@@ -2080,6 +2080,16 @@ static int handle_mount_opt(struct super_block *sb, char *opt, int token,
+ #endif
+       } else if (token == Opt_dax) {
+ #ifdef CONFIG_FS_DAX
++              if (is_remount && test_opt(sb, DAX)) {
++                      ext4_msg(sb, KERN_ERR, "can't mount with "
++                              "both data=journal and dax");
++                      return -1;
++              }
++              if (is_remount && !(sbi->s_mount_opt & EXT4_MOUNT_DAX)) {
++                      ext4_msg(sb, KERN_ERR, "can't change "
++                                      "dax mount option while remounting");
++                      return -1;
++              }
+               ext4_msg(sb, KERN_WARNING,
+               "DAX enabled. Warning: EXPERIMENTAL, use at your own risk");
+               sbi->s_mount_opt |= m->mount_opt;
+@@ -5407,12 +5417,6 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
+                       err = -EINVAL;
+                       goto restore_opts;
+               }
+-              if (test_opt(sb, DAX)) {
+-                      ext4_msg(sb, KERN_ERR, "can't mount with "
+-                               "both data=journal and dax");
+-                      err = -EINVAL;
+-                      goto restore_opts;
+-              }
+       } else if (test_opt(sb, DATA_FLAGS) == EXT4_MOUNT_ORDERED_DATA) {
+               if (test_opt(sb, JOURNAL_ASYNC_COMMIT)) {
+                       ext4_msg(sb, KERN_ERR, "can't mount with "
+@@ -5428,12 +5432,6 @@ static int ext4_remount(struct super_block *sb, int *flags, char *data)
+               goto restore_opts;
+       }
+-      if ((sbi->s_mount_opt ^ old_opts.s_mount_opt) & EXT4_MOUNT_DAX) {
+-              ext4_msg(sb, KERN_WARNING, "warning: refusing change of "
+-                      "dax flag with busy inodes while remounting");
+-              sbi->s_mount_opt ^= EXT4_MOUNT_DAX;
+-      }
+-
+       if (sbi->s_mount_flags & EXT4_MF_FS_ABORTED)
+               ext4_abort(sb, EXT4_ERR_ESHUTDOWN, "Abort forced by user");
+-- 
+2.25.1
+
index 97a77f09510b50021e7dd8cdf1ebcd8ae8dd40e2..5b0b3b80da1cbc4fd09468dc4e0659639956a91e 100644 (file)
@@ -435,3 +435,5 @@ io_uring-add-memory-barrier-to-synchronize-io_kiocb-s-result-and-iopoll_complete
 io_uring-acquire-mm-for-task_work-for-sqpoll.patch
 io_uring-reap-poll-completions-while-waiting-for-refs-to-drop-on-exit.patch
 io_uring-fix-possible-race-condition-against-req_f_need_cleanup.patch
+ext4-avoid-race-conditions-when-remounting-with-opti.patch
+drm-dp_mst-increase-act-retry-timeout-to-3s.patch