--- /dev/null
+From f6033c5e333238f299c3ae03fac8cc1365b23b77 Mon Sep 17 00:00:00 2001
+From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+Date: Tue, 21 Apr 2020 10:54:11 +0800
+Subject: btrfs: fix block group leak when removing fails
+
+From: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+
+commit f6033c5e333238f299c3ae03fac8cc1365b23b77 upstream.
+
+btrfs_remove_block_group() invokes btrfs_lookup_block_group(), which
+returns a local reference of the block group that contains the given
+bytenr to "block_group" with increased refcount.
+
+When btrfs_remove_block_group() returns, "block_group" becomes invalid,
+so the refcount should be decreased to keep refcount balanced.
+
+The reference counting issue happens in several exception handling paths
+of btrfs_remove_block_group(). When those error scenarios occur such as
+btrfs_alloc_path() returns NULL, the function forgets to decrease its
+refcnt increased by btrfs_lookup_block_group() and will cause a refcnt
+leak.
+
+Fix this issue by jumping to "out_put_group" label and calling
+btrfs_put_block_group() when those error scenarios occur.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
+Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/extent-tree.c | 16 ++++++++++------
+ 1 file changed, 10 insertions(+), 6 deletions(-)
+
+--- a/fs/btrfs/extent-tree.c
++++ b/fs/btrfs/extent-tree.c
+@@ -10286,7 +10286,7 @@ int btrfs_remove_block_group(struct btrf
+ path = btrfs_alloc_path();
+ if (!path) {
+ ret = -ENOMEM;
+- goto out;
++ goto out_put_group;
+ }
+
+ /*
+@@ -10323,7 +10323,7 @@ int btrfs_remove_block_group(struct btrf
+ ret = btrfs_orphan_add(trans, BTRFS_I(inode));
+ if (ret) {
+ btrfs_add_delayed_iput(inode);
+- goto out;
++ goto out_put_group;
+ }
+ clear_nlink(inode);
+ /* One for the block groups ref */
+@@ -10346,13 +10346,13 @@ int btrfs_remove_block_group(struct btrf
+
+ ret = btrfs_search_slot(trans, tree_root, &key, path, -1, 1);
+ if (ret < 0)
+- goto out;
++ goto out_put_group;
+ if (ret > 0)
+ btrfs_release_path(path);
+ if (ret == 0) {
+ ret = btrfs_del_item(trans, tree_root, path);
+ if (ret)
+- goto out;
++ goto out_put_group;
+ btrfs_release_path(path);
+ }
+
+@@ -10494,9 +10494,9 @@ int btrfs_remove_block_group(struct btrf
+
+ ret = remove_block_group_free_space(trans, block_group);
+ if (ret)
+- goto out;
++ goto out_put_group;
+
+- btrfs_put_block_group(block_group);
++ /* Once for the block groups rbtree */
+ btrfs_put_block_group(block_group);
+
+ ret = btrfs_search_slot(trans, root, &key, path, -1, 1);
+@@ -10524,6 +10524,10 @@ int btrfs_remove_block_group(struct btrf
+ /* once for the tree */
+ free_extent_map(em);
+ }
++
++out_put_group:
++ /* Once for the lookup reference */
++ btrfs_put_block_group(block_group);
+ out:
+ btrfs_free_path(path);
+ return ret;
--- /dev/null
+From f135cea30de5f74d5bfb5116682073841fb4af8f Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 23 Apr 2020 16:30:53 +0100
+Subject: btrfs: fix partial loss of prealloc extent past i_size after fsync
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit f135cea30de5f74d5bfb5116682073841fb4af8f upstream.
+
+When we have an inode with a prealloc extent that starts at an offset
+lower than the i_size and there is another prealloc extent that starts at
+an offset beyond i_size, we can end up losing part of the first prealloc
+extent (the part that starts at i_size) and have an implicit hole if we
+fsync the file and then have a power failure.
+
+Consider the following example with comments explaining how and why it
+happens.
+
+ $ mkfs.btrfs -f /dev/sdb
+ $ mount /dev/sdb /mnt
+
+ # Create our test file with 2 consecutive prealloc extents, each with a
+ # size of 128Kb, and covering the range from 0 to 256Kb, with a file
+ # size of 0.
+ $ xfs_io -f -c "falloc -k 0 128K" /mnt/foo
+ $ xfs_io -c "falloc -k 128K 128K" /mnt/foo
+
+ # Fsync the file to record both extents in the log tree.
+ $ xfs_io -c "fsync" /mnt/foo
+
+ # Now do a redudant extent allocation for the range from 0 to 64Kb.
+ # This will merely increase the file size from 0 to 64Kb. Instead we
+ # could also do a truncate to set the file size to 64Kb.
+ $ xfs_io -c "falloc 0 64K" /mnt/foo
+
+ # Fsync the file, so we update the inode item in the log tree with the
+ # new file size (64Kb). This also ends up setting the number of bytes
+ # for the first prealloc extent to 64Kb. This is done by the truncation
+ # at btrfs_log_prealloc_extents().
+ # This means that if a power failure happens after this, a write into
+ # the file range 64Kb to 128Kb will not use the prealloc extent and
+ # will result in allocation of a new extent.
+ $ xfs_io -c "fsync" /mnt/foo
+
+ # Now set the file size to 256K with a truncate and then fsync the file.
+ # Since no changes happened to the extents, the fsync only updates the
+ # i_size in the inode item at the log tree. This results in an implicit
+ # hole for the file range from 64Kb to 128Kb, something which fsck will
+ # complain when not using the NO_HOLES feature if we replay the log
+ # after a power failure.
+ $ xfs_io -c "truncate 256K" -c "fsync" /mnt/foo
+
+So instead of always truncating the log to the inode's current i_size at
+btrfs_log_prealloc_extents(), check first if there's a prealloc extent
+that starts at an offset lower than the i_size and with a length that
+crosses the i_size - if there is one, just make sure we truncate to a
+size that corresponds to the end offset of that prealloc extent, so
+that we don't lose the part of that extent that starts at i_size if a
+power failure happens.
+
+A test case for fstests follows soon.
+
+Fixes: 31d11b83b96f ("Btrfs: fix duplicate extents after fsync of file with prealloc extents")
+CC: stable@vger.kernel.org # 4.14+
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/tree-log.c | 43 ++++++++++++++++++++++++++++++++++++++++---
+ 1 file changed, 40 insertions(+), 3 deletions(-)
+
+--- a/fs/btrfs/tree-log.c
++++ b/fs/btrfs/tree-log.c
+@@ -4182,6 +4182,9 @@ static int btrfs_log_prealloc_extents(st
+ const u64 ino = btrfs_ino(inode);
+ struct btrfs_path *dst_path = NULL;
+ bool dropped_extents = false;
++ u64 truncate_offset = i_size;
++ struct extent_buffer *leaf;
++ int slot;
+ int ins_nr = 0;
+ int start_slot;
+ int ret;
+@@ -4196,9 +4199,43 @@ static int btrfs_log_prealloc_extents(st
+ if (ret < 0)
+ goto out;
+
++ /*
++ * We must check if there is a prealloc extent that starts before the
++ * i_size and crosses the i_size boundary. This is to ensure later we
++ * truncate down to the end of that extent and not to the i_size, as
++ * otherwise we end up losing part of the prealloc extent after a log
++ * replay and with an implicit hole if there is another prealloc extent
++ * that starts at an offset beyond i_size.
++ */
++ ret = btrfs_previous_item(root, path, ino, BTRFS_EXTENT_DATA_KEY);
++ if (ret < 0)
++ goto out;
++
++ if (ret == 0) {
++ struct btrfs_file_extent_item *ei;
++
++ leaf = path->nodes[0];
++ slot = path->slots[0];
++ ei = btrfs_item_ptr(leaf, slot, struct btrfs_file_extent_item);
++
++ if (btrfs_file_extent_type(leaf, ei) ==
++ BTRFS_FILE_EXTENT_PREALLOC) {
++ u64 extent_end;
++
++ btrfs_item_key_to_cpu(leaf, &key, slot);
++ extent_end = key.offset +
++ btrfs_file_extent_num_bytes(leaf, ei);
++
++ if (extent_end > i_size)
++ truncate_offset = extent_end;
++ }
++ } else {
++ ret = 0;
++ }
++
+ while (true) {
+- struct extent_buffer *leaf = path->nodes[0];
+- int slot = path->slots[0];
++ leaf = path->nodes[0];
++ slot = path->slots[0];
+
+ if (slot >= btrfs_header_nritems(leaf)) {
+ if (ins_nr > 0) {
+@@ -4236,7 +4273,7 @@ static int btrfs_log_prealloc_extents(st
+ ret = btrfs_truncate_inode_items(trans,
+ root->log_root,
+ &inode->vfs_inode,
+- i_size,
++ truncate_offset,
+ BTRFS_EXTENT_DATA_KEY);
+ } while (ret == -EAGAIN);
+ if (ret)
--- /dev/null
+From fcc99734d1d4ced30167eb02e17f656735cb9928 Mon Sep 17 00:00:00 2001
+From: Qu Wenruo <wqu@suse.com>
+Date: Mon, 27 Apr 2020 14:50:14 +0800
+Subject: btrfs: transaction: Avoid deadlock due to bad initialization timing of fs_info::journal_info
+
+From: Qu Wenruo <wqu@suse.com>
+
+commit fcc99734d1d4ced30167eb02e17f656735cb9928 upstream.
+
+[BUG]
+One run of btrfs/063 triggered the following lockdep warning:
+ ============================================
+ WARNING: possible recursive locking detected
+ 5.6.0-rc7-custom+ #48 Not tainted
+ --------------------------------------------
+ kworker/u24:0/7 is trying to acquire lock:
+ ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
+
+ but task is already holding lock:
+ ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
+
+ other info that might help us debug this:
+ Possible unsafe locking scenario:
+
+ CPU0
+ ----
+ lock(sb_internal#2);
+ lock(sb_internal#2);
+
+ *** DEADLOCK ***
+
+ May be due to missing lock nesting notation
+
+ 4 locks held by kworker/u24:0/7:
+ #0: ffff88817b495948 ((wq_completion)btrfs-endio-write){+.+.}, at: process_one_work+0x557/0xb80
+ #1: ffff888189ea7db8 ((work_completion)(&work->normal_work)){+.+.}, at: process_one_work+0x557/0xb80
+ #2: ffff88817d3a46e0 (sb_internal#2){.+.+}, at: start_transaction+0x66c/0x890 [btrfs]
+ #3: ffff888174ca4da8 (&fs_info->reloc_mutex){+.+.}, at: btrfs_record_root_in_trans+0x83/0xd0 [btrfs]
+
+ stack backtrace:
+ CPU: 0 PID: 7 Comm: kworker/u24:0 Not tainted 5.6.0-rc7-custom+ #48
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+ Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]
+ Call Trace:
+ dump_stack+0xc2/0x11a
+ __lock_acquire.cold+0xce/0x214
+ lock_acquire+0xe6/0x210
+ __sb_start_write+0x14e/0x290
+ start_transaction+0x66c/0x890 [btrfs]
+ btrfs_join_transaction+0x1d/0x20 [btrfs]
+ find_free_extent+0x1504/0x1a50 [btrfs]
+ btrfs_reserve_extent+0xd5/0x1f0 [btrfs]
+ btrfs_alloc_tree_block+0x1ac/0x570 [btrfs]
+ btrfs_copy_root+0x213/0x580 [btrfs]
+ create_reloc_root+0x3bd/0x470 [btrfs]
+ btrfs_init_reloc_root+0x2d2/0x310 [btrfs]
+ record_root_in_trans+0x191/0x1d0 [btrfs]
+ btrfs_record_root_in_trans+0x90/0xd0 [btrfs]
+ start_transaction+0x16e/0x890 [btrfs]
+ btrfs_join_transaction+0x1d/0x20 [btrfs]
+ btrfs_finish_ordered_io+0x55d/0xcd0 [btrfs]
+ finish_ordered_fn+0x15/0x20 [btrfs]
+ btrfs_work_helper+0x116/0x9a0 [btrfs]
+ process_one_work+0x632/0xb80
+ worker_thread+0x80/0x690
+ kthread+0x1a3/0x1f0
+ ret_from_fork+0x27/0x50
+
+It's pretty hard to reproduce, only one hit so far.
+
+[CAUSE]
+This is because we're calling btrfs_join_transaction() without re-using
+the current running one:
+
+btrfs_finish_ordered_io()
+|- btrfs_join_transaction() <<< Call #1
+ |- btrfs_record_root_in_trans()
+ |- btrfs_reserve_extent()
+ |- btrfs_join_transaction() <<< Call #2
+
+Normally such btrfs_join_transaction() call should re-use the existing
+one, without trying to re-start a transaction.
+
+But the problem is, in btrfs_join_transaction() call #1, we call
+btrfs_record_root_in_trans() before initializing current::journal_info.
+
+And in btrfs_join_transaction() call #2, we're relying on
+current::journal_info to avoid such deadlock.
+
+[FIX]
+Call btrfs_record_root_in_trans() after we have initialized
+current::journal_info.
+
+CC: stable@vger.kernel.org # 4.4+
+Signed-off-by: Qu Wenruo <wqu@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/transaction.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/fs/btrfs/transaction.c
++++ b/fs/btrfs/transaction.c
+@@ -572,10 +572,19 @@ again:
+ }
+
+ got_it:
+- btrfs_record_root_in_trans(h, root);
+-
+ if (!current->journal_info)
+ current->journal_info = h;
++
++ /*
++ * btrfs_record_root_in_trans() needs to alloc new extents, and may
++ * call btrfs_join_transaction() while we're also starting a
++ * transaction.
++ *
++ * Thus it need to be called after current->journal_info initialized,
++ * or we can deadlock.
++ */
++ btrfs_record_root_in_trans(h, root);
++
+ return h;
+
+ join_fail:
--- /dev/null
+From 6292b8efe32e6be408af364132f09572aed14382 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 23 Apr 2020 18:17:43 +0300
+Subject: drm/edid: Fix off-by-one in DispID DTD pixel clock
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 6292b8efe32e6be408af364132f09572aed14382 upstream.
+
+The DispID DTD pixel clock is documented as:
+"00 00 00 h → FF FF FF h | Pixel clock ÷ 10,000 0.01 → 167,772.16 Mega Pixels per Sec"
+Which seems to imply that we to add one to the raw value.
+
+Reality seems to agree as there are tiled displays in the wild
+which currently show a 10kHz difference in the pixel clock
+between the tiles (one tile gets its mode from the base EDID,
+the other from the DispID block).
+
+Cc: stable@vger.kernel.org
+References: https://gitlab.freedesktop.org/drm/intel/-/issues/27
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200423151743.18767-1-ville.syrjala@linux.intel.com
+Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/drm_edid.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/drm_edid.c
++++ b/drivers/gpu/drm/drm_edid.c
+@@ -4706,7 +4706,7 @@ static struct drm_display_mode *drm_mode
+ struct drm_display_mode *mode;
+ unsigned pixel_clock = (timings->pixel_clock[0] |
+ (timings->pixel_clock[1] << 8) |
+- (timings->pixel_clock[2] << 16));
++ (timings->pixel_clock[2] << 16)) + 1;
+ unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
+ unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
+ unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) + 1;
--- /dev/null
+From 85e9b88af1e6164f19ec71381efd5e2bcfc17620 Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Mon, 27 Apr 2020 08:32:46 +0300
+Subject: drm/qxl: qxl_release leak in qxl_draw_dirty_fb()
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit 85e9b88af1e6164f19ec71381efd5e2bcfc17620 upstream.
+
+ret should be changed to release allocated struct qxl_release
+
+Cc: stable@vger.kernel.org
+Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/22cfd55f-07c8-95d0-a2f7-191b7153c3d4@virtuozzo.com
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/qxl/qxl_draw.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/qxl/qxl_draw.c
++++ b/drivers/gpu/drm/qxl/qxl_draw.c
+@@ -348,9 +348,10 @@ void qxl_draw_dirty_fb(struct qxl_device
+ goto out_release_backoff;
+
+ rects = drawable_set_clipping(qdev, num_clips, clips_bo);
+- if (!rects)
++ if (!rects) {
++ ret = -EINVAL;
+ goto out_release_backoff;
+-
++ }
+ drawable = (struct qxl_drawable *)qxl_release_map(qdev, release);
+
+ drawable->clip.type = SPICE_CLIP_TYPE_RECTS;
--- /dev/null
+From a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Mon, 27 Apr 2020 08:32:51 +0300
+Subject: drm/qxl: qxl_release leak in qxl_hw_surface_alloc()
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit a65aa9c3676ffccb21361d52fcfedd5b5ff387d7 upstream.
+
+Cc: stable@vger.kernel.org
+Fixes: 8002db6336dd ("qxl: convert qxl driver to proper use for reservations")
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/2e5a13ae-9ab2-5401-aa4d-03d5f5593423@virtuozzo.com
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/qxl/qxl_cmd.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/qxl/qxl_cmd.c
++++ b/drivers/gpu/drm/qxl/qxl_cmd.c
+@@ -472,9 +472,10 @@ int qxl_hw_surface_alloc(struct qxl_devi
+ return ret;
+
+ ret = qxl_release_reserve_list(release, true);
+- if (ret)
++ if (ret) {
++ qxl_release_free(qdev, release);
+ return ret;
+-
++ }
+ cmd = (struct qxl_surface_cmd *)qxl_release_map(qdev, release);
+ cmd->type = QXL_SURFACE_CMD_CREATE;
+ cmd->flags = QXL_SURF_FLAG_KEEP_DATA;
--- /dev/null
+From 933db73351d359f74b14f4af095808260aff11f9 Mon Sep 17 00:00:00 2001
+From: Vasily Averin <vvs@virtuozzo.com>
+Date: Wed, 29 Apr 2020 12:01:24 +0300
+Subject: drm/qxl: qxl_release use after free
+
+From: Vasily Averin <vvs@virtuozzo.com>
+
+commit 933db73351d359f74b14f4af095808260aff11f9 upstream.
+
+qxl_release should not be accesses after qxl_push_*_ring_release() calls:
+userspace driver can process submitted command quickly, move qxl_release
+into release_ring, generate interrupt and trigger garbage collector.
+
+It can lead to crashes in qxl driver or trigger memory corruption
+in some kmalloc-192 slab object
+
+Gerd Hoffmann proposes to swap the qxl_release_fence_buffer_objects() +
+qxl_push_{cursor,command}_ring_release() calls to close that race window.
+
+cc: stable@vger.kernel.org
+Fixes: f64122c1f6ad ("drm: add new QXL driver. (v1.4)")
+Signed-off-by: Vasily Averin <vvs@virtuozzo.com>
+Link: http://patchwork.freedesktop.org/patch/msgid/fa17b338-66ae-f299-68fe-8d32419d9071@virtuozzo.com
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/qxl/qxl_cmd.c | 5 ++---
+ drivers/gpu/drm/qxl/qxl_display.c | 6 +++---
+ drivers/gpu/drm/qxl/qxl_draw.c | 2 +-
+ drivers/gpu/drm/qxl/qxl_ioctl.c | 5 +----
+ 4 files changed, 7 insertions(+), 11 deletions(-)
+
+--- a/drivers/gpu/drm/qxl/qxl_cmd.c
++++ b/drivers/gpu/drm/qxl/qxl_cmd.c
+@@ -501,8 +501,8 @@ int qxl_hw_surface_alloc(struct qxl_devi
+ /* no need to add a release to the fence for this surface bo,
+ since it is only released when we ask to destroy the surface
+ and it would never signal otherwise */
+- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
+ qxl_release_fence_buffer_objects(release);
++ qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
+
+ surf->hw_surf_alloc = true;
+ spin_lock(&qdev->surf_id_idr_lock);
+@@ -544,9 +544,8 @@ int qxl_hw_surface_dealloc(struct qxl_de
+ cmd->surface_id = id;
+ qxl_release_unmap(qdev, release, &cmd->release_info);
+
+- qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
+-
+ qxl_release_fence_buffer_objects(release);
++ qxl_push_command_ring_release(qdev, release, QXL_CMD_SURFACE, false);
+
+ return 0;
+ }
+--- a/drivers/gpu/drm/qxl/qxl_display.c
++++ b/drivers/gpu/drm/qxl/qxl_display.c
+@@ -532,8 +532,8 @@ static int qxl_primary_apply_cursor(stru
+ cmd->u.set.visible = 1;
+ qxl_release_unmap(qdev, release, &cmd->release_info);
+
+- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
+ qxl_release_fence_buffer_objects(release);
++ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
+
+ return ret;
+
+@@ -694,8 +694,8 @@ static void qxl_cursor_atomic_update(str
+ cmd->u.position.y = plane->state->crtc_y + fb->hot_y;
+
+ qxl_release_unmap(qdev, release, &cmd->release_info);
+- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
+ qxl_release_fence_buffer_objects(release);
++ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
+
+ if (old_cursor_bo)
+ qxl_bo_unref(&old_cursor_bo);
+@@ -740,8 +740,8 @@ static void qxl_cursor_atomic_disable(st
+ cmd->type = QXL_CURSOR_HIDE;
+ qxl_release_unmap(qdev, release, &cmd->release_info);
+
+- qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
+ qxl_release_fence_buffer_objects(release);
++ qxl_push_cursor_ring_release(qdev, release, QXL_CMD_CURSOR, false);
+ }
+
+ static int qxl_plane_prepare_fb(struct drm_plane *plane,
+--- a/drivers/gpu/drm/qxl/qxl_draw.c
++++ b/drivers/gpu/drm/qxl/qxl_draw.c
+@@ -382,8 +382,8 @@ void qxl_draw_dirty_fb(struct qxl_device
+ }
+ qxl_bo_kunmap(clips_bo);
+
+- qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
+ qxl_release_fence_buffer_objects(release);
++ qxl_push_command_ring_release(qdev, release, QXL_CMD_DRAW, false);
+
+ out_release_backoff:
+ if (ret)
+--- a/drivers/gpu/drm/qxl/qxl_ioctl.c
++++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
+@@ -257,11 +257,8 @@ static int qxl_process_single_command(st
+ apply_surf_reloc(qdev, &reloc_info[i]);
+ }
+
++ qxl_release_fence_buffer_objects(release);
+ ret = qxl_push_command_ring_release(qdev, release, cmd->type, true);
+- if (ret)
+- qxl_release_backoff_reserve_list(release);
+- else
+- qxl_release_fence_buffer_objects(release);
+
+ out_free_bos:
+ out_free_release:
--- /dev/null
+From b1ac62a7ac386d76968af5f374a4a7a82a35fe31 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Mon, 13 Apr 2020 16:27:27 -0700
+Subject: mmc: cqhci: Avoid false "cqhci: CQE stuck on" by not open-coding timeout loop
+
+From: Douglas Anderson <dianders@chromium.org>
+
+commit b1ac62a7ac386d76968af5f374a4a7a82a35fe31 upstream.
+
+Open-coding a timeout loop invariably leads to errors with handling
+the timeout properly in one corner case or another. In the case of
+cqhci we might report "CQE stuck on" even if it wasn't stuck on.
+You'd just need this sequence of events to happen in cqhci_off():
+
+1. Call ktime_get().
+2. Something happens to interrupt the CPU for > 100 us (context switch
+ or interrupt).
+3. Check time and; set "timed_out" to true since > 100 us.
+4. Read CQHCI_CTL.
+5. Both "reg & CQHCI_HALT" and "timed_out" are true, so break.
+6. Since "timed_out" is true, falsely print the error message.
+
+Rather than fixing the polling loop, use readx_poll_timeout() like
+many people do. This has been time tested to handle the corner cases.
+
+Fixes: a4080225f51d ("mmc: cqhci: support for command queue enabled host")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d030c6af8e0@changeid
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/cqhci.c | 21 ++++++++++-----------
+ 1 file changed, 10 insertions(+), 11 deletions(-)
+
+--- a/drivers/mmc/host/cqhci.c
++++ b/drivers/mmc/host/cqhci.c
+@@ -13,6 +13,7 @@
+ #include <linux/delay.h>
+ #include <linux/highmem.h>
+ #include <linux/io.h>
++#include <linux/iopoll.h>
+ #include <linux/module.h>
+ #include <linux/dma-mapping.h>
+ #include <linux/slab.h>
+@@ -351,12 +352,16 @@ static int cqhci_enable(struct mmc_host
+ /* CQHCI is idle and should halt immediately, so set a small timeout */
+ #define CQHCI_OFF_TIMEOUT 100
+
++static u32 cqhci_read_ctl(struct cqhci_host *cq_host)
++{
++ return cqhci_readl(cq_host, CQHCI_CTL);
++}
++
+ static void cqhci_off(struct mmc_host *mmc)
+ {
+ struct cqhci_host *cq_host = mmc->cqe_private;
+- ktime_t timeout;
+- bool timed_out;
+ u32 reg;
++ int err;
+
+ if (!cq_host->enabled || !mmc->cqe_on || cq_host->recovery_halt)
+ return;
+@@ -366,15 +371,9 @@ static void cqhci_off(struct mmc_host *m
+
+ cqhci_writel(cq_host, CQHCI_HALT, CQHCI_CTL);
+
+- timeout = ktime_add_us(ktime_get(), CQHCI_OFF_TIMEOUT);
+- while (1) {
+- timed_out = ktime_compare(ktime_get(), timeout) > 0;
+- reg = cqhci_readl(cq_host, CQHCI_CTL);
+- if ((reg & CQHCI_HALT) || timed_out)
+- break;
+- }
+-
+- if (timed_out)
++ err = readx_poll_timeout(cqhci_read_ctl, cq_host, reg,
++ reg & CQHCI_HALT, 0, CQHCI_OFF_TIMEOUT);
++ if (err < 0)
+ pr_err("%s: cqhci: CQE stuck on\n", mmc_hostname(mmc));
+ else
+ pr_debug("%s: cqhci: CQE off\n", mmc_hostname(mmc));
--- /dev/null
+From ddca1092c4324c89cf692b5efe655aa251864b51 Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Thu, 16 Apr 2020 20:35:13 +0200
+Subject: mmc: meson-mx-sdio: remove the broken ->card_busy() op
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+commit ddca1092c4324c89cf692b5efe655aa251864b51 upstream.
+
+The recent commit 0d84c3e6a5b2 ("mmc: core: Convert to
+mmc_poll_for_busy() for erase/trim/discard") makes use of the
+->card_busy() op for SD cards. This uncovered that the ->card_busy() op
+in the Meson SDIO driver was never working right:
+while polling the busy status with ->card_busy()
+meson_mx_mmc_card_busy() reads only one of the two MESON_MX_SDIO_IRQC
+register values 0x1f001f10 or 0x1f003f10. This translates to "three out
+of four DAT lines are HIGH" and "all four DAT lines are HIGH", which
+is interpreted as "the card is busy".
+
+It turns out that no situation can be observed where all four DAT lines
+are LOW, meaning the card is not busy anymore. Upon further research the
+3.10 vendor driver for this controller does not implement the
+->card_busy() op.
+
+Remove the ->card_busy() op from the meson-mx-sdio driver since it is
+not working. At the time of writing this patch it is not clear what's
+needed to make the ->card_busy() implementation work with this specific
+controller hardware. For all use-cases which have previously worked the
+MMC_CAP_WAIT_WHILE_BUSY flag is now taking over, even if we don't have
+a ->card_busy() op anymore.
+
+Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/meson-mx-sdio.c | 9 ---------
+ 1 file changed, 9 deletions(-)
+
+--- a/drivers/mmc/host/meson-mx-sdio.c
++++ b/drivers/mmc/host/meson-mx-sdio.c
+@@ -360,14 +360,6 @@ static void meson_mx_mmc_request(struct
+ meson_mx_mmc_start_cmd(mmc, mrq->cmd);
+ }
+
+-static int meson_mx_mmc_card_busy(struct mmc_host *mmc)
+-{
+- struct meson_mx_mmc_host *host = mmc_priv(mmc);
+- u32 irqc = readl(host->base + MESON_MX_SDIO_IRQC);
+-
+- return !!(irqc & MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK);
+-}
+-
+ static void meson_mx_mmc_read_response(struct mmc_host *mmc,
+ struct mmc_command *cmd)
+ {
+@@ -509,7 +501,6 @@ static void meson_mx_mmc_timeout(struct
+ static struct mmc_host_ops meson_mx_mmc_ops = {
+ .request = meson_mx_mmc_request,
+ .set_ios = meson_mx_mmc_set_ios,
+- .card_busy = meson_mx_mmc_card_busy,
+ .get_cd = mmc_gpio_get_cd,
+ .get_ro = mmc_gpio_get_ro,
+ };
--- /dev/null
+From e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb Mon Sep 17 00:00:00 2001
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Date: Thu, 16 Apr 2020 20:35:12 +0200
+Subject: mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY
+
+From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+
+commit e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb upstream.
+
+The Meson SDIO controller uses the DAT0 lane for hardware busy
+detection. Set MMC_CAP_WAIT_WHILE_BUSY accordingly. This fixes
+the following error observed with Linux 5.7 (pre-rc-1):
+ mmc1: Card stuck being busy! __mmc_poll_for_busy
+ blk_update_request: I/O error, dev mmcblk1, sector 17111080 op
+ 0x3:(DISCARD) flags 0x0 phys_seg 1 prio class 0
+
+Fixes: ed80a13bb4c4c9 ("mmc: meson-mx-sdio: Add a driver for the Amlogic Meson8 and Meson8b SoCs")
+Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200416183513.993763-2-martin.blumenstingl@googlemail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/meson-mx-sdio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/meson-mx-sdio.c
++++ b/drivers/mmc/host/meson-mx-sdio.c
+@@ -573,7 +573,7 @@ static int meson_mx_mmc_add_host(struct
+ mmc->f_max = clk_round_rate(host->cfg_div_clk,
+ clk_get_rate(host->parent_clk));
+
+- mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23;
++ mmc->caps |= MMC_CAP_ERASE | MMC_CAP_CMD23 | MMC_CAP_WAIT_WHILE_BUSY;
+ mmc->ops = &meson_mx_mmc_ops;
+
+ ret = mmc_of_parse(mmc);
--- /dev/null
+From 9d8cb58691f85cef687512262acb2c7109ee4868 Mon Sep 17 00:00:00 2001
+From: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
+Date: Mon, 20 Apr 2020 11:50:23 +0530
+Subject: mmc: sdhci-msm: Enable host capabilities pertains to R1b response
+
+From: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
+
+commit 9d8cb58691f85cef687512262acb2c7109ee4868 upstream.
+
+MSM sd host controller is capable of HW busy detection of device busy
+signaling over DAT0 line. And it requires the R1B response for commands
+that have this response associated with them.
+
+So set the below two host capabilities for qcom SDHC.
+ - MMC_CAP_WAIT_WHILE_BUSY
+ - MMC_CAP_NEED_RSP_BUSY
+
+Recent development of the mmc core in regards to this, revealed this as
+being a potential bug, hence the stable tag.
+
+Cc: <stable@vger.kernel.org> # v4.19+
+Signed-off-by: Veerabhadrarao Badiganti <vbadigan@codeaurora.org>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-msm.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-msm.c
++++ b/drivers/mmc/host/sdhci-msm.c
+@@ -1909,6 +1909,8 @@ static int sdhci_msm_probe(struct platfo
+ goto clk_disable;
+ }
+
++ msm_host->mmc->caps |= MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_NEED_RSP_BUSY;
++
+ pm_runtime_get_noresume(&pdev->dev);
+ pm_runtime_set_active(&pdev->dev);
+ pm_runtime_enable(&pdev->dev);
--- /dev/null
+From 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Wed, 22 Apr 2020 14:16:29 +0300
+Subject: mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a upstream.
+
+BIOS writers have begun the practice of setting 40 ohm eMMC driver strength
+even though the eMMC may not support it, on the assumption that the kernel
+will validate the value against the eMMC (Extended CSD DRIVER_STRENGTH
+[offset 197]) and revert to the default 50 ohm value if 40 ohm is invalid.
+
+This is done to avoid changing the value for different boards.
+
+Putting aside the merits of this approach, it is clear the eMMC's mask
+of supported driver strengths is more reliable than the value provided
+by BIOS. Add validation accordingly.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Fixes: 51ced59cc02e ("mmc: sdhci-pci: Use ACPI DSM to get driver strength for some Intel devices")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20200422111629.4899-1-adrian.hunter@intel.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-pci-core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-pci-core.c
++++ b/drivers/mmc/host/sdhci-pci-core.c
+@@ -556,6 +556,9 @@ static int intel_select_drive_strength(s
+ struct sdhci_pci_slot *slot = sdhci_priv(host);
+ struct intel_host *intel_host = sdhci_pci_priv(slot);
+
++ if (!(mmc_driver_type_mask(intel_host->drv_strength) & card_drv))
++ return 0;
++
+ return intel_host->drv_strength;
+ }
+
--- /dev/null
+From bb32e1987bc55ce1db400faf47d85891da3c9b9f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marek=20Beh=C3=BAn?= <marek.behun@nic.cz>
+Date: Mon, 20 Apr 2020 10:04:44 +0200
+Subject: mmc: sdhci-xenon: fix annoying 1.8V regulator warning
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Marek Behún <marek.behun@nic.cz>
+
+commit bb32e1987bc55ce1db400faf47d85891da3c9b9f upstream.
+
+For some reason the Host Control2 register of the Xenon SDHCI controller
+sometimes reports the bit representing 1.8V signaling as 0 when read
+after it was written as 1. Subsequent read reports 1.
+
+This causes the sdhci_start_signal_voltage_switch function to report
+ 1.8V regulator output did not become stable
+
+When CONFIG_PM is enabled, the host is suspended and resumend many
+times, and in each resume the switch to 1.8V is called, and so the
+kernel log reports this message annoyingly often.
+
+Do an empty read of the Host Control2 register in Xenon's
+.voltage_switch method to circumvent this.
+
+This patch fixes this particular problem on Turris MOX.
+
+Signed-off-by: Marek Behún <marek.behun@nic.cz>
+Fixes: 8d876bf472db ("mmc: sdhci-xenon: wait 5ms after set 1.8V...")
+Cc: stable@vger.kernel.org # v4.16+
+Link: https://lore.kernel.org/r/20200420080444.25242-1-marek.behun@nic.cz
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-xenon.c | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/drivers/mmc/host/sdhci-xenon.c
++++ b/drivers/mmc/host/sdhci-xenon.c
+@@ -238,6 +238,16 @@ static void xenon_voltage_switch(struct
+ {
+ /* Wait for 5ms after set 1.8V signal enable bit */
+ usleep_range(5000, 5500);
++
++ /*
++ * For some reason the controller's Host Control2 register reports
++ * the bit representing 1.8V signaling as 0 when read after it was
++ * written as 1. Subsequent read reports 1.
++ *
++ * Since this may cause some issues, do an empty read of the Host
++ * Control2 register here to circumvent this.
++ */
++ sdhci_readw(host, SDHCI_HOST_CONTROL2);
+ }
+
+ static const struct sdhci_ops sdhci_xenon_ops = {
+drm-edid-fix-off-by-one-in-dispid-dtd-pixel-clock.patch
+drm-qxl-qxl_release-leak-in-qxl_draw_dirty_fb.patch
+drm-qxl-qxl_release-leak-in-qxl_hw_surface_alloc.patch
+drm-qxl-qxl_release-use-after-free.patch
+btrfs-fix-block-group-leak-when-removing-fails.patch
+btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch
+btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch
+mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch
+mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch
+mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch
+mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch
+mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch
+mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
