--- /dev/null
+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
+
--- /dev/null
+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
+