From 9c35677b50bec59d675b2e7ce9ed6df3dd8e2cef Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 4 May 2020 10:19:16 +0200 Subject: [PATCH] 5.4-stable patches added patches: btrfs-fix-block-group-leak-when-removing-fails.patch btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch btrfs-fix-transaction-leak-in-btrfs_recover_relocation.patch btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch crypto-caam-fix-the-address-of-the-last-entry-of-s-g.patch mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch --- ...block-group-leak-when-removing-fails.patch | 95 ++++++++++++ ...alloc-extent-past-i_size-after-fsync.patch | 139 ++++++++++++++++++ ...ion-leak-in-btrfs_recover_relocation.patch | 46 ++++++ ...ation-timing-of-fs_info-journal_info.patch | 127 ++++++++++++++++ ...the-address-of-the-last-entry-of-s-g.patch | 109 ++++++++++++++ ...k-on-by-not-open-coding-timeout-loop.patch | 85 +++++++++++ ...-sdio-remove-the-broken-card_busy-op.patch | 67 +++++++++ ...-mx-sdio-set-mmc_cap_wait_while_busy.patch | 38 +++++ ...apabilities-pertains-to-r1b-response.patch | 42 ++++++ ...r-strength-for-byt-based-controllers.patch | 43 ++++++ ...-fix-annoying-1.8v-regulator-warning.patch | 58 ++++++++ queue-5.4/series | 11 ++ 12 files changed, 860 insertions(+) create mode 100644 queue-5.4/btrfs-fix-block-group-leak-when-removing-fails.patch create mode 100644 queue-5.4/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch create mode 100644 queue-5.4/btrfs-fix-transaction-leak-in-btrfs_recover_relocation.patch create mode 100644 queue-5.4/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch create mode 100644 queue-5.4/crypto-caam-fix-the-address-of-the-last-entry-of-s-g.patch create mode 100644 queue-5.4/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch create mode 100644 queue-5.4/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch create mode 100644 queue-5.4/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch create mode 100644 queue-5.4/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch create mode 100644 queue-5.4/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch create mode 100644 queue-5.4/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch diff --git a/queue-5.4/btrfs-fix-block-group-leak-when-removing-fails.patch b/queue-5.4/btrfs-fix-block-group-leak-when-removing-fails.patch new file mode 100644 index 00000000000..e8660762adc --- /dev/null +++ b/queue-5.4/btrfs-fix-block-group-leak-when-removing-fails.patch @@ -0,0 +1,95 @@ +From f6033c5e333238f299c3ae03fac8cc1365b23b77 Mon Sep 17 00:00:00 2001 +From: Xiyu Yang +Date: Tue, 21 Apr 2020 10:54:11 +0800 +Subject: btrfs: fix block group leak when removing fails + +From: Xiyu Yang + +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 +Signed-off-by: Xin Tan +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/block-group.c | 16 ++++++++++------ + 1 file changed, 10 insertions(+), 6 deletions(-) + +--- a/fs/btrfs/block-group.c ++++ b/fs/btrfs/block-group.c +@@ -910,7 +910,7 @@ int btrfs_remove_block_group(struct btrf + path = btrfs_alloc_path(); + if (!path) { + ret = -ENOMEM; +- goto out; ++ goto out_put_group; + } + + /* +@@ -948,7 +948,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 */ +@@ -971,13 +971,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); + } + +@@ -1094,9 +1094,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); +@@ -1119,6 +1119,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: + if (remove_rsv) + btrfs_delayed_refs_rsv_release(fs_info, 1); diff --git a/queue-5.4/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch b/queue-5.4/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch new file mode 100644 index 00000000000..82e95e8babd --- /dev/null +++ b/queue-5.4/btrfs-fix-partial-loss-of-prealloc-extent-past-i_size-after-fsync.patch @@ -0,0 +1,139 @@ +From f135cea30de5f74d5bfb5116682073841fb4af8f Mon Sep 17 00:00:00 2001 +From: Filipe Manana +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 + +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 +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -4242,6 +4242,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; +@@ -4256,9 +4259,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) { +@@ -4296,7 +4333,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) diff --git a/queue-5.4/btrfs-fix-transaction-leak-in-btrfs_recover_relocation.patch b/queue-5.4/btrfs-fix-transaction-leak-in-btrfs_recover_relocation.patch new file mode 100644 index 00000000000..932b92cf7de --- /dev/null +++ b/queue-5.4/btrfs-fix-transaction-leak-in-btrfs_recover_relocation.patch @@ -0,0 +1,46 @@ +From 1402d17dfd9657be0da8458b2079d03c2d61c86a Mon Sep 17 00:00:00 2001 +From: Xiyu Yang +Date: Mon, 20 Apr 2020 13:39:39 +0800 +Subject: btrfs: fix transaction leak in btrfs_recover_relocation + +From: Xiyu Yang + +commit 1402d17dfd9657be0da8458b2079d03c2d61c86a upstream. + +btrfs_recover_relocation() invokes btrfs_join_transaction(), which joins +a btrfs_trans_handle object into transactions and returns a reference of +it with increased refcount to "trans". + +When btrfs_recover_relocation() returns, "trans" becomes invalid, so the +refcount should be decreased to keep refcount balanced. + +The reference counting issue happens in one exception handling path of +btrfs_recover_relocation(). When read_fs_root() failed, the refcnt +increased by btrfs_join_transaction() is not decreased, causing a refcnt +leak. + +Fix this issue by calling btrfs_end_transaction() on this error path +when read_fs_root() failed. + +Fixes: 79787eaab461 ("btrfs: replace many BUG_ONs with proper error handling") +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Filipe Manana +Signed-off-by: Xiyu Yang +Signed-off-by: Xin Tan +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/relocation.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/btrfs/relocation.c ++++ b/fs/btrfs/relocation.c +@@ -4605,6 +4605,7 @@ int btrfs_recover_relocation(struct btrf + if (IS_ERR(fs_root)) { + err = PTR_ERR(fs_root); + list_add_tail(&reloc_root->root_list, &reloc_roots); ++ btrfs_end_transaction(trans); + goto out_unset; + } + diff --git a/queue-5.4/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch b/queue-5.4/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch new file mode 100644 index 00000000000..721e931813f --- /dev/null +++ b/queue-5.4/btrfs-transaction-avoid-deadlock-due-to-bad-initialization-timing-of-fs_info-journal_info.patch @@ -0,0 +1,127 @@ +From fcc99734d1d4ced30167eb02e17f656735cb9928 Mon Sep 17 00:00:00 2001 +From: Qu Wenruo +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 + +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 +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/transaction.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +--- a/fs/btrfs/transaction.c ++++ b/fs/btrfs/transaction.c +@@ -590,10 +590,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: diff --git a/queue-5.4/crypto-caam-fix-the-address-of-the-last-entry-of-s-g.patch b/queue-5.4/crypto-caam-fix-the-address-of-the-last-entry-of-s-g.patch new file mode 100644 index 00000000000..e6a3f859af6 --- /dev/null +++ b/queue-5.4/crypto-caam-fix-the-address-of-the-last-entry-of-s-g.patch @@ -0,0 +1,109 @@ +From 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d Mon Sep 17 00:00:00 2001 +From: Iuliana Prodan +Date: Tue, 7 Apr 2020 18:58:45 +0300 +Subject: crypto: caam - fix the address of the last entry of S/G +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Iuliana Prodan + +commit 55b3209acbb01cb02b1ee6b1afe80d83b1aab36d upstream. + +For skcipher algorithms, the input, output HW S/G tables +look like this: [IV, src][dst, IV] +Now, we can have 2 conditions here: +- there is no IV; +- src and dst are equal (in-place encryption) and scattered +and the error is an "off-by-one" in the HW S/G table. + +This issue was seen with KASAN: +BUG: KASAN: slab-out-of-bounds in skcipher_edesc_alloc+0x95c/0x1018 + +Read of size 4 at addr ffff000022a02958 by task cryptomgr_test/321 + +CPU: 2 PID: 321 Comm: cryptomgr_test Not tainted +5.6.0-rc1-00165-ge4ef8383-dirty #4 +Hardware name: LS1046A RDB Board (DT) +Call trace: + dump_backtrace+0x0/0x260 + show_stack+0x14/0x20 + dump_stack+0xe8/0x144 + print_address_description.isra.11+0x64/0x348 + __kasan_report+0x11c/0x230 + kasan_report+0xc/0x18 + __asan_load4+0x90/0xb0 + skcipher_edesc_alloc+0x95c/0x1018 + skcipher_encrypt+0x84/0x150 + crypto_skcipher_encrypt+0x50/0x68 + test_skcipher_vec_cfg+0x4d4/0xc10 + test_skcipher_vec+0x178/0x1d8 + alg_test_skcipher+0xec/0x230 + alg_test.part.44+0x114/0x4a0 + alg_test+0x1c/0x60 + cryptomgr_test+0x34/0x58 + kthread+0x1b8/0x1c0 + ret_from_fork+0x10/0x18 + +Allocated by task 321: + save_stack+0x24/0xb0 + __kasan_kmalloc.isra.10+0xc4/0xe0 + kasan_kmalloc+0xc/0x18 + __kmalloc+0x178/0x2b8 + skcipher_edesc_alloc+0x21c/0x1018 + skcipher_encrypt+0x84/0x150 + crypto_skcipher_encrypt+0x50/0x68 + test_skcipher_vec_cfg+0x4d4/0xc10 + test_skcipher_vec+0x178/0x1d8 + alg_test_skcipher+0xec/0x230 + alg_test.part.44+0x114/0x4a0 + alg_test+0x1c/0x60 + cryptomgr_test+0x34/0x58 + kthread+0x1b8/0x1c0 + ret_from_fork+0x10/0x18 + +Freed by task 0: +(stack is not available) + +The buggy address belongs to the object at ffff000022a02800 + which belongs to the cache dma-kmalloc-512 of size 512 +The buggy address is located 344 bytes inside of + 512-byte region [ffff000022a02800, ffff000022a02a00) +The buggy address belongs to the page: +page:fffffe00006a8000 refcount:1 mapcount:0 mapping:ffff00093200c400 +index:0x0 compound_mapcount: 0 +flags: 0xffff00000010200(slab|head) +raw: 0ffff00000010200 dead000000000100 dead000000000122 ffff00093200c400 +raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 +page dumped because: kasan: bad access detected + +Memory state around the buggy address: + ffff000022a02800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 + ffff000022a02880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 +>ffff000022a02900: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc + ^ + ffff000022a02980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + ffff000022a02a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc + +Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support") +Cc: # v5.3+ +Signed-off-by: Iuliana Prodan +Reviewed-by: Horia Geantă +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/caam/caamalg.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/crypto/caam/caamalg.c ++++ b/drivers/crypto/caam/caamalg.c +@@ -1810,7 +1810,7 @@ static struct skcipher_edesc *skcipher_e + + if (ivsize || mapped_dst_nents > 1) + sg_to_sec4_set_last(edesc->sec4_sg + dst_sg_idx + +- mapped_dst_nents); ++ mapped_dst_nents - 1 + !!ivsize); + + if (sec4_sg_bytes) { + edesc->sec4_sg_dma = dma_map_single(jrdev, edesc->sec4_sg, diff --git a/queue-5.4/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch b/queue-5.4/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch new file mode 100644 index 00000000000..4f6d56658af --- /dev/null +++ b/queue-5.4/mmc-cqhci-avoid-false-cqhci-cqe-stuck-on-by-not-open-coding-timeout-loop.patch @@ -0,0 +1,85 @@ +From b1ac62a7ac386d76968af5f374a4a7a82a35fe31 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +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 + +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 +Acked-by: Adrian Hunter +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200413162717.1.Idece266f5c8793193b57a1ddb1066d030c6af8e0@changeid +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -5,6 +5,7 @@ + #include + #include + #include ++#include + #include + #include + #include +@@ -343,12 +344,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; +@@ -358,15 +363,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)); diff --git a/queue-5.4/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch b/queue-5.4/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch new file mode 100644 index 00000000000..f815fc25467 --- /dev/null +++ b/queue-5.4/mmc-meson-mx-sdio-remove-the-broken-card_busy-op.patch @@ -0,0 +1,67 @@ +From ddca1092c4324c89cf692b5efe655aa251864b51 Mon Sep 17 00:00:00 2001 +From: Martin Blumenstingl +Date: Thu, 16 Apr 2020 20:35:13 +0200 +Subject: mmc: meson-mx-sdio: remove the broken ->card_busy() op + +From: Martin Blumenstingl + +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 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200416183513.993763-3-martin.blumenstingl@googlemail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -357,14 +357,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) + { +@@ -506,7 +498,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, + }; diff --git a/queue-5.4/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch b/queue-5.4/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch new file mode 100644 index 00000000000..94f7f00cd5f --- /dev/null +++ b/queue-5.4/mmc-meson-mx-sdio-set-mmc_cap_wait_while_busy.patch @@ -0,0 +1,38 @@ +From e53b868b3cf5beeaa2f851ec6740112bf4d6a8cb Mon Sep 17 00:00:00 2001 +From: Martin Blumenstingl +Date: Thu, 16 Apr 2020 20:35:12 +0200 +Subject: mmc: meson-mx-sdio: Set MMC_CAP_WAIT_WHILE_BUSY + +From: Martin Blumenstingl + +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 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20200416183513.993763-2-martin.blumenstingl@googlemail.com +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -570,7 +570,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); diff --git a/queue-5.4/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch b/queue-5.4/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch new file mode 100644 index 00000000000..87b87642a71 --- /dev/null +++ b/queue-5.4/mmc-sdhci-msm-enable-host-capabilities-pertains-to-r1b-response.patch @@ -0,0 +1,42 @@ +From 9d8cb58691f85cef687512262acb2c7109ee4868 Mon Sep 17 00:00:00 2001 +From: Veerabhadrarao Badiganti +Date: Mon, 20 Apr 2020 11:50:23 +0530 +Subject: mmc: sdhci-msm: Enable host capabilities pertains to R1b response + +From: Veerabhadrarao Badiganti + +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: # v4.19+ +Signed-off-by: Veerabhadrarao Badiganti +Acked-by: Adrian Hunter +Link: https://lore.kernel.org/r/1587363626-20413-2-git-send-email-vbadigan@codeaurora.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -1944,6 +1944,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); diff --git a/queue-5.4/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch b/queue-5.4/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch new file mode 100644 index 00000000000..0cf49c362d4 --- /dev/null +++ b/queue-5.4/mmc-sdhci-pci-fix-emmc-driver-strength-for-byt-based-controllers.patch @@ -0,0 +1,43 @@ +From 1a8eb6b373c2af6533c13d1ea11f504e5010ed9a Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Wed, 22 Apr 2020 14:16:29 +0300 +Subject: mmc: sdhci-pci: Fix eMMC driver strength for BYT-based controllers + +From: Adrian Hunter + +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 +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -601,6 +601,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; + } + diff --git a/queue-5.4/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch b/queue-5.4/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch new file mode 100644 index 00000000000..3413dbb3da8 --- /dev/null +++ b/queue-5.4/mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch @@ -0,0 +1,58 @@ +From bb32e1987bc55ce1db400faf47d85891da3c9b9f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Beh=C3=BAn?= +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 + +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 +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -235,6 +235,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 = { diff --git a/queue-5.4/series b/queue-5.4/series index d600046f85d..fbe382620a8 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -5,3 +5,14 @@ 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 nfsv4.1-fix-handling-of-backchannel-binding-in-bind_conn_to_session.patch +btrfs-fix-transaction-leak-in-btrfs_recover_relocation.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 +crypto-caam-fix-the-address-of-the-last-entry-of-s-g.patch -- 2.47.3