From 640230d76b089a5cda0fe50a8a59354785c10aee Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 5 Aug 2019 07:17:30 +0200 Subject: [PATCH] 5.2-stable patches added patches: btrfs-fix-incremental-send-failure-after-deduplication.patch btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch dax-fix-missed-wakeup-in-put_unlocked_entry.patch drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch gpiolib-preserve-desc-flags-when-setting-state.patch ib-hfi1-fix-spectre-v1-vulnerability.patch kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch kconfig-clear-written-flag-to-avoid-data-loss.patch mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch mmc-mmc_spi-enable-stable-writes.patch tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch --- ...tal-send-failure-after-deduplication.patch | 180 +++++++++++ ...s-corruption-after-transaction-abort.patch | 142 +++++++++ ...-missed-wakeup-in-put_unlocked_entry.patch | 38 +++ ...y-release-vcpi-slots-on-mode-changes.patch | 89 ++++++ ...ndant-ftrace_graph_notrace_addr-test.patch | 57 ++++ ...on-null-descs-if-gpiolib-is-disabled.patch | 297 ++++++++++++++++++ ...equesting-of-an-active-low-lineevent.patch | 70 +++++ ...eserve-desc-flags-when-setting-state.patch | 49 +++ ...ib-hfi1-fix-spectre-v1-vulnerability.patch | 48 +++ ..._flags-correctly-in-the-top-makefile.patch | 57 ++++ ....-.cmd-files-only-when-targets-exist.patch | 41 +++ ...lear-written-flag-to-avoid-data-loss.patch | 52 +++ ...occasional-hang-after-tuning-on-emmc.patch | 62 ++++ ...ix-the-missing-pm_runtime_put_noidle.patch | 38 +++ ...-mx-sdio-fix-misuse-of-genmask-macro.patch | 34 ++ .../mmc-mmc_spi-enable-stable-writes.patch | 59 ++++ queue-5.2/series | 17 + ...eference-on-chip-register-error-path.patch | 97 ++++++ 18 files changed, 1427 insertions(+) create mode 100644 queue-5.2/btrfs-fix-incremental-send-failure-after-deduplication.patch create mode 100644 queue-5.2/btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch create mode 100644 queue-5.2/dax-fix-missed-wakeup-in-put_unlocked_entry.patch create mode 100644 queue-5.2/drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch create mode 100644 queue-5.2/fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch create mode 100644 queue-5.2/gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch create mode 100644 queue-5.2/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch create mode 100644 queue-5.2/gpiolib-preserve-desc-flags-when-setting-state.patch create mode 100644 queue-5.2/ib-hfi1-fix-spectre-v1-vulnerability.patch create mode 100644 queue-5.2/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch create mode 100644 queue-5.2/kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch create mode 100644 queue-5.2/kconfig-clear-written-flag-to-avoid-data-loss.patch create mode 100644 queue-5.2/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch create mode 100644 queue-5.2/mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch create mode 100644 queue-5.2/mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch create mode 100644 queue-5.2/mmc-mmc_spi-enable-stable-writes.patch create mode 100644 queue-5.2/tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch diff --git a/queue-5.2/btrfs-fix-incremental-send-failure-after-deduplication.patch b/queue-5.2/btrfs-fix-incremental-send-failure-after-deduplication.patch new file mode 100644 index 00000000000..2d6e9738d2f --- /dev/null +++ b/queue-5.2/btrfs-fix-incremental-send-failure-after-deduplication.patch @@ -0,0 +1,180 @@ +From b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 17 Jul 2019 13:23:39 +0100 +Subject: Btrfs: fix incremental send failure after deduplication + +From: Filipe Manana + +commit b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 upstream. + +When doing an incremental send operation we can fail if we previously did +deduplication operations against a file that exists in both snapshots. In +that case we will fail the send operation with -EIO and print a message +to dmesg/syslog like the following: + + BTRFS error (device sdc): Send: inconsistent snapshot, found updated \ + extent for inode 257 without updated inode item, send root is 258, \ + parent root is 257 + +This requires that we deduplicate to the same file in both snapshots for +the same amount of times on each snapshot. The issue happens because a +deduplication only updates the iversion of an inode and does not update +any other field of the inode, therefore if we deduplicate the file on +each snapshot for the same amount of time, the inode will have the same +iversion value (stored as the "sequence" field on the inode item) on both +snapshots, therefore it will be seen as unchanged between in the send +snapshot while there are new/updated/deleted extent items when comparing +to the parent snapshot. This makes the send operation return -EIO and +print an error message. + +Example reproducer: + + $ mkfs.btrfs -f /dev/sdb + $ mount /dev/sdb /mnt + + # Create our first file. The first half of the file has several 64Kb + # extents while the second half as a single 512Kb extent. + $ xfs_io -f -s -c "pwrite -S 0xb8 -b 64K 0 512K" /mnt/foo + $ xfs_io -c "pwrite -S 0xb8 512K 512K" /mnt/foo + + # Create the base snapshot and the parent send stream from it. + $ btrfs subvolume snapshot -r /mnt /mnt/mysnap1 + $ btrfs send -f /tmp/1.snap /mnt/mysnap1 + + # Create our second file, that has exactly the same data as the first + # file. + $ xfs_io -f -c "pwrite -S 0xb8 0 1M" /mnt/bar + + # Create the second snapshot, used for the incremental send, before + # doing the file deduplication. + $ btrfs subvolume snapshot -r /mnt /mnt/mysnap2 + + # Now before creating the incremental send stream: + # + # 1) Deduplicate into a subrange of file foo in snapshot mysnap1. This + # will drop several extent items and add a new one, also updating + # the inode's iversion (sequence field in inode item) by 1, but not + # any other field of the inode; + # + # 2) Deduplicate into a different subrange of file foo in snapshot + # mysnap2. This will replace an extent item with a new one, also + # updating the inode's iversion by 1 but not any other field of the + # inode. + # + # After these two deduplication operations, the inode items, for file + # foo, are identical in both snapshots, but we have different extent + # items for this inode in both snapshots. We want to check this doesn't + # cause send to fail with an error or produce an incorrect stream. + + $ xfs_io -r -c "dedupe /mnt/bar 0 0 512K" /mnt/mysnap1/foo + $ xfs_io -r -c "dedupe /mnt/bar 512K 512K 512K" /mnt/mysnap2/foo + + # Create the incremental send stream. + $ btrfs send -p /mnt/mysnap1 -f /tmp/2.snap /mnt/mysnap2 + ERROR: send ioctl failed with -5: Input/output error + +This issue started happening back in 2015 when deduplication was updated +to not update the inode's ctime and mtime and update only the iversion. +Back then we would hit a BUG_ON() in send, but later in 2016 send was +updated to return -EIO and print the error message instead of doing the +BUG_ON(). + +A test case for fstests follows soon. + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203933 +Fixes: 1c919a5e13702c ("btrfs: don't update mtime/ctime on deduped inodes") +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/send.c | 77 ++++++++++---------------------------------------------- + 1 file changed, 15 insertions(+), 62 deletions(-) + +--- a/fs/btrfs/send.c ++++ b/fs/btrfs/send.c +@@ -6322,68 +6322,21 @@ static int changed_extent(struct send_ct + { + int ret = 0; + +- if (sctx->cur_ino != sctx->cmp_key->objectid) { +- +- if (result == BTRFS_COMPARE_TREE_CHANGED) { +- struct extent_buffer *leaf_l; +- struct extent_buffer *leaf_r; +- struct btrfs_file_extent_item *ei_l; +- struct btrfs_file_extent_item *ei_r; +- +- leaf_l = sctx->left_path->nodes[0]; +- leaf_r = sctx->right_path->nodes[0]; +- ei_l = btrfs_item_ptr(leaf_l, +- sctx->left_path->slots[0], +- struct btrfs_file_extent_item); +- ei_r = btrfs_item_ptr(leaf_r, +- sctx->right_path->slots[0], +- struct btrfs_file_extent_item); +- +- /* +- * We may have found an extent item that has changed +- * only its disk_bytenr field and the corresponding +- * inode item was not updated. This case happens due to +- * very specific timings during relocation when a leaf +- * that contains file extent items is COWed while +- * relocation is ongoing and its in the stage where it +- * updates data pointers. So when this happens we can +- * safely ignore it since we know it's the same extent, +- * but just at different logical and physical locations +- * (when an extent is fully replaced with a new one, we +- * know the generation number must have changed too, +- * since snapshot creation implies committing the current +- * transaction, and the inode item must have been updated +- * as well). +- * This replacement of the disk_bytenr happens at +- * relocation.c:replace_file_extents() through +- * relocation.c:btrfs_reloc_cow_block(). +- */ +- if (btrfs_file_extent_generation(leaf_l, ei_l) == +- btrfs_file_extent_generation(leaf_r, ei_r) && +- btrfs_file_extent_ram_bytes(leaf_l, ei_l) == +- btrfs_file_extent_ram_bytes(leaf_r, ei_r) && +- btrfs_file_extent_compression(leaf_l, ei_l) == +- btrfs_file_extent_compression(leaf_r, ei_r) && +- btrfs_file_extent_encryption(leaf_l, ei_l) == +- btrfs_file_extent_encryption(leaf_r, ei_r) && +- btrfs_file_extent_other_encoding(leaf_l, ei_l) == +- btrfs_file_extent_other_encoding(leaf_r, ei_r) && +- btrfs_file_extent_type(leaf_l, ei_l) == +- btrfs_file_extent_type(leaf_r, ei_r) && +- btrfs_file_extent_disk_bytenr(leaf_l, ei_l) != +- btrfs_file_extent_disk_bytenr(leaf_r, ei_r) && +- btrfs_file_extent_disk_num_bytes(leaf_l, ei_l) == +- btrfs_file_extent_disk_num_bytes(leaf_r, ei_r) && +- btrfs_file_extent_offset(leaf_l, ei_l) == +- btrfs_file_extent_offset(leaf_r, ei_r) && +- btrfs_file_extent_num_bytes(leaf_l, ei_l) == +- btrfs_file_extent_num_bytes(leaf_r, ei_r)) +- return 0; +- } +- +- inconsistent_snapshot_error(sctx, result, "extent"); +- return -EIO; +- } ++ /* ++ * We have found an extent item that changed without the inode item ++ * having changed. This can happen either after relocation (where the ++ * disk_bytenr of an extent item is replaced at ++ * relocation.c:replace_file_extents()) or after deduplication into a ++ * file in both the parent and send snapshots (where an extent item can ++ * get modified or replaced with a new one). Note that deduplication ++ * updates the inode item, but it only changes the iversion (sequence ++ * field in the inode item) of the inode, so if a file is deduplicated ++ * the same amount of times in both the parent and send snapshots, its ++ * iversion becames the same in both snapshots, whence the inode item is ++ * the same on both snapshots. ++ */ ++ if (sctx->cur_ino != sctx->cmp_key->objectid) ++ return 0; + + if (!sctx->cur_inode_new_gen && !sctx->cur_inode_deleted) { + if (result != BTRFS_COMPARE_TREE_DELETED) diff --git a/queue-5.2/btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch b/queue-5.2/btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch new file mode 100644 index 00000000000..7ac84c2fba1 --- /dev/null +++ b/queue-5.2/btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch @@ -0,0 +1,142 @@ +From cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Thu, 25 Jul 2019 11:27:04 +0100 +Subject: Btrfs: fix race leading to fs corruption after transaction abort + +From: Filipe Manana + +commit cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 upstream. + +When one transaction is finishing its commit, it is possible for another +transaction to start and enter its initial commit phase as well. If the +first ends up getting aborted, we have a small time window where the second +transaction commit does not notice that the previous transaction aborted +and ends up committing, writing a superblock that points to btrees that +reference extent buffers (nodes and leafs) that were not persisted to disk. +The consequence is that after mounting the filesystem again, we will be +unable to load some btree nodes/leafs, either because the content on disk +is either garbage (or just zeroes) or corresponds to the old content of a +previouly COWed or deleted node/leaf, resulting in the well known error +messages "parent transid verify failed on ...". +The following sequence diagram illustrates how this can happen. + + CPU 1 CPU 2 + + + + btrfs_commit_transaction() + (...) + --> sets transaction state to + TRANS_STATE_UNBLOCKED + --> sets fs_info->running_transaction + to NULL + + (...) + btrfs_start_transaction() + start_transaction() + wait_current_trans() + --> returns immediately + because + fs_info->running_transaction + is NULL + join_transaction() + --> creates transaction N + 1 + --> sets + fs_info->running_transaction + to transaction N + 1 + --> adds transaction N + 1 to + the fs_info->trans_list list + --> returns transaction handle + pointing to the new + transaction N + 1 + (...) + + btrfs_sync_file() + btrfs_start_transaction() + --> returns handle to + transaction N + 1 + (...) + + btrfs_write_and_wait_transaction() + --> writeback of some extent + buffer fails, returns an + error + btrfs_handle_fs_error() + --> sets BTRFS_FS_STATE_ERROR in + fs_info->fs_state + --> jumps to label "scrub_continue" + cleanup_transaction() + btrfs_abort_transaction(N) + --> sets BTRFS_FS_STATE_TRANS_ABORTED + flag in fs_info->fs_state + --> sets aborted field in the + transaction and transaction + handle structures, for + transaction N only + --> removes transaction from the + list fs_info->trans_list + btrfs_commit_transaction(N + 1) + --> transaction N + 1 was not + aborted, so it proceeds + (...) + --> sets the transaction's state + to TRANS_STATE_COMMIT_START + --> does not find the previous + transaction (N) in the + fs_info->trans_list, so it + doesn't know that transaction + was aborted, and the commit + of transaction N + 1 proceeds + (...) + --> sets transaction N + 1 state + to TRANS_STATE_UNBLOCKED + btrfs_write_and_wait_transaction() + --> succeeds writing all extent + buffers created in the + transaction N + 1 + write_all_supers() + --> succeeds + --> we now have a superblock on + disk that points to trees + that refer to at least one + extent buffer that was + never persisted + +So fix this by updating the transaction commit path to check if the flag +BTRFS_FS_STATE_TRANS_ABORTED is set on fs_info->fs_state if after setting +the transaction to the TRANS_STATE_COMMIT_START we do not find any previous +transaction in the fs_info->trans_list. If the flag is set, just fail the +transaction commit with -EROFS, as we do in other places. The exact error +code for the previous transaction abort was already logged and reported. + +Fixes: 49b25e0540904b ("btrfs: enhance transaction abort infrastructure") +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/transaction.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/fs/btrfs/transaction.c ++++ b/fs/btrfs/transaction.c +@@ -2019,6 +2019,16 @@ int btrfs_commit_transaction(struct btrf + } + } else { + spin_unlock(&fs_info->trans_lock); ++ /* ++ * The previous transaction was aborted and was already removed ++ * from the list of transactions at fs_info->trans_list. So we ++ * abort to prevent writing a new superblock that reflects a ++ * corrupt state (pointing to trees with unwritten nodes/leafs). ++ */ ++ if (test_bit(BTRFS_FS_STATE_TRANS_ABORTED, &fs_info->fs_state)) { ++ ret = -EROFS; ++ goto cleanup_transaction; ++ } + } + + extwriter_counter_dec(cur_trans, trans->type); diff --git a/queue-5.2/dax-fix-missed-wakeup-in-put_unlocked_entry.patch b/queue-5.2/dax-fix-missed-wakeup-in-put_unlocked_entry.patch new file mode 100644 index 00000000000..d08aa676a38 --- /dev/null +++ b/queue-5.2/dax-fix-missed-wakeup-in-put_unlocked_entry.patch @@ -0,0 +1,38 @@ +From 61c30c98ef17e5a330d7bb8494b78b3d6dffe9b8 Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Mon, 29 Jul 2019 13:57:49 +0200 +Subject: dax: Fix missed wakeup in put_unlocked_entry() + +From: Jan Kara + +commit 61c30c98ef17e5a330d7bb8494b78b3d6dffe9b8 upstream. + +The condition checking whether put_unlocked_entry() needs to wake up +following waiter got broken by commit 23c84eb78375 ("dax: Fix missed +wakeup with PMD faults"). We need to wake the waiter whenever the passed +entry is valid (i.e., non-NULL and not special conflict entry). This +could lead to processes never being woken up when waiting for entry +lock. Fix the condition. + +Cc: +Link: http://lore.kernel.org/r/20190729120228.GC17833@quack2.suse.cz +Fixes: 23c84eb78375 ("dax: Fix missed wakeup with PMD faults") +Signed-off-by: Jan Kara +Signed-off-by: Dan Williams +Signed-off-by: Greg Kroah-Hartman + +--- + fs/dax.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/dax.c ++++ b/fs/dax.c +@@ -267,7 +267,7 @@ static void wait_entry_unlocked(struct x + static void put_unlocked_entry(struct xa_state *xas, void *entry) + { + /* If we were the only waiter woken, wake the next one */ +- if (entry && dax_is_conflict(entry)) ++ if (entry && !dax_is_conflict(entry)) + dax_wake_entry(xas, entry, false); + } + diff --git a/queue-5.2/drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch b/queue-5.2/drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch new file mode 100644 index 00000000000..7231d503951 --- /dev/null +++ b/queue-5.2/drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch @@ -0,0 +1,89 @@ +From 412e85b605315fd129a849599cf4a5a7959573a8 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Thu, 1 Aug 2019 18:02:15 -0400 +Subject: drm/nouveau: Only release VCPI slots on mode changes + +From: Lyude Paul + +commit 412e85b605315fd129a849599cf4a5a7959573a8 upstream. + +Looks like a regression got introduced into nv50_mstc_atomic_check() +that somehow didn't get found until now. If userspace changes +crtc_state->active to false but leaves the CRTC enabled, we end up +calling drm_dp_atomic_find_vcpi_slots() using the PBN calculated in +asyh->dp.pbn. However, if the display is inactive we end up calculating +a PBN of 0, which inadvertently causes us to have an allocation of 0. +>From there, if userspace then disables the CRTC afterwards we end up +accidentally attempting to free the VCPI twice: + +WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 +drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] +RIP: 0010:drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] +Call Trace: + drm_atomic_helper_check_modeset+0x3f3/0xa60 [drm_kms_helper] + ? drm_atomic_check_only+0x43/0x780 [drm] + drm_atomic_helper_check+0x15/0x90 [drm_kms_helper] + nv50_disp_atomic_check+0x83/0x1d0 [nouveau] + drm_atomic_check_only+0x54d/0x780 [drm] + ? drm_atomic_set_crtc_for_connector+0xec/0x100 [drm] + drm_atomic_commit+0x13/0x50 [drm] + drm_atomic_helper_set_config+0x81/0x90 [drm_kms_helper] + drm_mode_setcrtc+0x194/0x6a0 [drm] + ? vprintk_emit+0x16a/0x230 + ? drm_ioctl+0x163/0x390 [drm] + ? drm_mode_getcrtc+0x180/0x180 [drm] + drm_ioctl_kernel+0xaa/0xf0 [drm] + drm_ioctl+0x208/0x390 [drm] + ? drm_mode_getcrtc+0x180/0x180 [drm] + nouveau_drm_ioctl+0x63/0xb0 [nouveau] + do_vfs_ioctl+0x405/0x660 + ? recalc_sigpending+0x17/0x50 + ? _copy_from_user+0x37/0x60 + ksys_ioctl+0x5e/0x90 + ? exit_to_usermode_loop+0x92/0xe0 + __x64_sys_ioctl+0x16/0x20 + do_syscall_64+0x59/0x190 + entry_SYSCALL_64_after_hwframe+0x44/0xa9 +WARNING: CPU: 0 PID: 1484 at drivers/gpu/drm/drm_dp_mst_topology.c:3336 +drm_dp_atomic_release_vcpi_slots+0x87/0xb0 [drm_kms_helper] +---[ end trace 4c395c0c51b1f88d ]--- +[drm:drm_dp_atomic_release_vcpi_slots [drm_kms_helper]] *ERROR* no VCPI for +[MST PORT:00000000e288eb7d] found in mst state 000000008e642070 + +So, fix this by doing what we probably should have done from the start: only +call drm_dp_atomic_find_vcpi_slots() when crtc_state->mode_changed is set, so +that VCPI allocations remain for as long as the CRTC is enabled. + +Signed-off-by: Lyude Paul +Fixes: 232c9eec417a ("drm/nouveau: Use atomic VCPI helpers for MST") +Cc: Lyude Paul +Cc: Ben Skeggs +Cc: Daniel Vetter +Cc: David Airlie +Cc: Jerry Zuo +Cc: Harry Wentland +Cc: Juston Li +Cc: Karol Herbst +Cc: Laurent Pinchart +Cc: Ilia Mirkin +Cc: # v5.1+ +Acked-by: Ben Skeggs +Signed-off-by: Dave Airlie +Link: https://patchwork.freedesktop.org/patch/msgid/20190801220216.15323-1-lyude@redhat.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c ++++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c +@@ -775,7 +775,7 @@ nv50_msto_atomic_check(struct drm_encode + drm_dp_calc_pbn_mode(crtc_state->adjusted_mode.clock, + connector->display_info.bpc * 3); + +- if (drm_atomic_crtc_needs_modeset(crtc_state)) { ++ if (crtc_state->mode_changed) { + slots = drm_dp_atomic_find_vcpi_slots(state, &mstm->mgr, + mstc->port, + asyh->dp.pbn); diff --git a/queue-5.2/fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch b/queue-5.2/fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch new file mode 100644 index 00000000000..c356061f5ea --- /dev/null +++ b/queue-5.2/fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch @@ -0,0 +1,57 @@ +From 6c77221df96177da0520847ce91e33f539fb8b2d Mon Sep 17 00:00:00 2001 +From: Changbin Du +Date: Tue, 30 Jul 2019 22:08:50 +0800 +Subject: fgraph: Remove redundant ftrace_graph_notrace_addr() test + +From: Changbin Du + +commit 6c77221df96177da0520847ce91e33f539fb8b2d upstream. + +We already have tested it before. The second one should be removed. +With this change, the performance should have little improvement. + +Link: http://lkml.kernel.org/r/20190730140850.7927-1-changbin.du@gmail.com + +Cc: stable@vger.kernel.org +Fixes: 9cd2992f2d6c ("fgraph: Have set_graph_notrace only affect function_graph tracer") +Signed-off-by: Changbin Du +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/trace/trace_functions_graph.c | 17 +++++++---------- + 1 file changed, 7 insertions(+), 10 deletions(-) + +--- a/kernel/trace/trace_functions_graph.c ++++ b/kernel/trace/trace_functions_graph.c +@@ -137,6 +137,13 @@ int trace_graph_entry(struct ftrace_grap + if (trace_recursion_test(TRACE_GRAPH_NOTRACE_BIT)) + return 0; + ++ /* ++ * Do not trace a function if it's filtered by set_graph_notrace. ++ * Make the index of ret stack negative to indicate that it should ++ * ignore further functions. But it needs its own ret stack entry ++ * to recover the original index in order to continue tracing after ++ * returning from the function. ++ */ + if (ftrace_graph_notrace_addr(trace->func)) { + trace_recursion_set(TRACE_GRAPH_NOTRACE_BIT); + /* +@@ -156,16 +163,6 @@ int trace_graph_entry(struct ftrace_grap + return 0; + + /* +- * Do not trace a function if it's filtered by set_graph_notrace. +- * Make the index of ret stack negative to indicate that it should +- * ignore further functions. But it needs its own ret stack entry +- * to recover the original index in order to continue tracing after +- * returning from the function. +- */ +- if (ftrace_graph_notrace_addr(trace->func)) +- return 1; +- +- /* + * Stop here if tracing_threshold is set. We only write function return + * events to the ring buffer. + */ diff --git a/queue-5.2/gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch b/queue-5.2/gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch new file mode 100644 index 00000000000..6d6232d914b --- /dev/null +++ b/queue-5.2/gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch @@ -0,0 +1,297 @@ +From ffe0bbabb0cffceceae07484fde1ec2a63b1537c Mon Sep 17 00:00:00 2001 +From: Bartosz Golaszewski +Date: Mon, 8 Jul 2019 10:23:43 +0200 +Subject: gpio: don't WARN() on NULL descs if gpiolib is disabled + +From: Bartosz Golaszewski + +commit ffe0bbabb0cffceceae07484fde1ec2a63b1537c upstream. + +If gpiolib is disabled, we use the inline stubs from gpio/consumer.h +instead of regular definitions of GPIO API. The stubs for 'optional' +variants of gpiod_get routines return NULL in this case as if the +relevant GPIO wasn't found. This is correct so far. + +Calling other (non-gpio_get) stubs from this header triggers a warning +because the GPIO descriptor couldn't have been requested. The warning +however is unconditional (WARN_ON(1)) and is emitted even if the passed +descriptor pointer is NULL. + +We don't want to force the users of 'optional' gpio_get to check the +returned pointer before calling e.g. gpiod_set_value() so let's only +WARN on non-NULL descriptors. + +Cc: stable@vger.kernel.org +Reported-by: Claus H. Stovgaard +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman + +--- + include/linux/gpio/consumer.h | 64 +++++++++++++++++++++--------------------- + 1 file changed, 32 insertions(+), 32 deletions(-) + +--- a/include/linux/gpio/consumer.h ++++ b/include/linux/gpio/consumer.h +@@ -247,7 +247,7 @@ static inline void gpiod_put(struct gpio + might_sleep(); + + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + + static inline void devm_gpiod_unhinge(struct device *dev, +@@ -256,7 +256,7 @@ static inline void devm_gpiod_unhinge(st + might_sleep(); + + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + + static inline void gpiod_put_array(struct gpio_descs *descs) +@@ -264,7 +264,7 @@ static inline void gpiod_put_array(struc + might_sleep(); + + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(descs); + } + + static inline struct gpio_desc *__must_check +@@ -317,7 +317,7 @@ static inline void devm_gpiod_put(struct + might_sleep(); + + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + + static inline void devm_gpiod_put_array(struct device *dev, +@@ -326,32 +326,32 @@ static inline void devm_gpiod_put_array( + might_sleep(); + + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(descs); + } + + + static inline int gpiod_get_direction(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -ENOSYS; + } + static inline int gpiod_direction_input(struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -ENOSYS; + } + static inline int gpiod_direction_output(struct gpio_desc *desc, int value) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -ENOSYS; + } + static inline int gpiod_direction_output_raw(struct gpio_desc *desc, int value) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -ENOSYS; + } + +@@ -359,7 +359,7 @@ static inline int gpiod_direction_output + static inline int gpiod_get_value(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return 0; + } + static inline int gpiod_get_array_value(unsigned int array_size, +@@ -368,13 +368,13 @@ static inline int gpiod_get_array_value( + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + static inline void gpiod_set_value(struct gpio_desc *desc, int value) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + static inline int gpiod_set_array_value(unsigned int array_size, + struct gpio_desc **desc_array, +@@ -382,13 +382,13 @@ static inline int gpiod_set_array_value( + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + static inline int gpiod_get_raw_value(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return 0; + } + static inline int gpiod_get_raw_array_value(unsigned int array_size, +@@ -397,13 +397,13 @@ static inline int gpiod_get_raw_array_va + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + static inline void gpiod_set_raw_value(struct gpio_desc *desc, int value) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + static inline int gpiod_set_raw_array_value(unsigned int array_size, + struct gpio_desc **desc_array, +@@ -411,14 +411,14 @@ static inline int gpiod_set_raw_array_va + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + + static inline int gpiod_get_value_cansleep(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return 0; + } + static inline int gpiod_get_array_value_cansleep(unsigned int array_size, +@@ -427,13 +427,13 @@ static inline int gpiod_get_array_value_ + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + static inline void gpiod_set_value_cansleep(struct gpio_desc *desc, int value) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + static inline int gpiod_set_array_value_cansleep(unsigned int array_size, + struct gpio_desc **desc_array, +@@ -441,13 +441,13 @@ static inline int gpiod_set_array_value_ + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + static inline int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return 0; + } + static inline int gpiod_get_raw_array_value_cansleep(unsigned int array_size, +@@ -456,14 +456,14 @@ static inline int gpiod_get_raw_array_va + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + static inline void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, + int value) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + } + static inline int gpiod_set_raw_array_value_cansleep(unsigned int array_size, + struct gpio_desc **desc_array, +@@ -471,41 +471,41 @@ static inline int gpiod_set_raw_array_va + unsigned long *value_bitmap) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc_array); + return 0; + } + + static inline int gpiod_set_debounce(struct gpio_desc *desc, unsigned debounce) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -ENOSYS; + } + + static inline int gpiod_set_transitory(struct gpio_desc *desc, bool transitory) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -ENOSYS; + } + + static inline int gpiod_is_active_low(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return 0; + } + static inline int gpiod_cansleep(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return 0; + } + + static inline int gpiod_to_irq(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -EINVAL; + } + +@@ -513,7 +513,7 @@ static inline int gpiod_set_consumer_nam + const char *name) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -EINVAL; + } + +@@ -525,7 +525,7 @@ static inline struct gpio_desc *gpio_to_ + static inline int desc_to_gpio(const struct gpio_desc *desc) + { + /* GPIO can never have been requested */ +- WARN_ON(1); ++ WARN_ON(desc); + return -EINVAL; + } + diff --git a/queue-5.2/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch b/queue-5.2/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch new file mode 100644 index 00000000000..52dcdecc894 --- /dev/null +++ b/queue-5.2/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch @@ -0,0 +1,70 @@ +From 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 Mon Sep 17 00:00:00 2001 +From: Michael Wu +Date: Mon, 8 Jul 2019 13:23:08 +0800 +Subject: gpiolib: fix incorrect IRQ requesting of an active-low lineevent + +From: Michael Wu + +commit 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 upstream. + +When a pin is active-low, logical trigger edge should be inverted to match +the same interrupt opportunity. + +For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in +ACTIVE_LOW case, the button pushed triggers rising edge. For user space the +IRQ requesting doesn't need to do any modification except to configuring +GPIOHANDLE_REQUEST_ACTIVE_LOW. + +For example, we want to catch the event when the button is pushed. The +button on the original board drives level to be low when it is pushed, and +drives level to be high when it is released. + +In user space we can do: + + req.handleflags = GPIOHANDLE_REQUEST_INPUT; + req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; + + while (1) { + read(fd, &dat, sizeof(dat)); + if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE) + printf("button pushed\n"); + } + +Run the same logic on another board which the polarity of the button is +inverted; it drives level to be high when pushed, and level to be low when +released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW: + + req.handleflags = GPIOHANDLE_REQUEST_INPUT | + GPIOHANDLE_REQUEST_ACTIVE_LOW; + req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; + +At the result, there are no any events caught when the button is pushed. +By the way, button releasing will emit a "falling" event. The timing of +"falling" catching is not expected. + +Cc: stable@vger.kernel.org +Signed-off-by: Michael Wu +Tested-by: Bartosz Golaszewski +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -956,9 +956,11 @@ static int lineevent_create(struct gpio_ + } + + if (eflags & GPIOEVENT_REQUEST_RISING_EDGE) +- irqflags |= IRQF_TRIGGER_RISING; ++ irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ? ++ IRQF_TRIGGER_FALLING : IRQF_TRIGGER_RISING; + if (eflags & GPIOEVENT_REQUEST_FALLING_EDGE) +- irqflags |= IRQF_TRIGGER_FALLING; ++ irqflags |= test_bit(FLAG_ACTIVE_LOW, &desc->flags) ? ++ IRQF_TRIGGER_RISING : IRQF_TRIGGER_FALLING; + irqflags |= IRQF_ONESHOT; + + INIT_KFIFO(le->events); diff --git a/queue-5.2/gpiolib-preserve-desc-flags-when-setting-state.patch b/queue-5.2/gpiolib-preserve-desc-flags-when-setting-state.patch new file mode 100644 index 00000000000..9f3bdd8fb54 --- /dev/null +++ b/queue-5.2/gpiolib-preserve-desc-flags-when-setting-state.patch @@ -0,0 +1,49 @@ +From d95da993383c78f7efd25957ba3af23af4b1c613 Mon Sep 17 00:00:00 2001 +From: Chris Packham +Date: Mon, 8 Jul 2019 08:35:58 +1200 +Subject: gpiolib: Preserve desc->flags when setting state + +From: Chris Packham + +commit d95da993383c78f7efd25957ba3af23af4b1c613 upstream. + +desc->flags may already have values set by of_gpiochip_add() so make +sure that this isn't undone when setting the initial direction. + +Cc: stable@vger.kernel.org +Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") +Signed-off-by: Chris Packham +Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesis.co.nz +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpiolib.c | 17 +++++++++++------ + 1 file changed, 11 insertions(+), 6 deletions(-) + +--- a/drivers/gpio/gpiolib.c ++++ b/drivers/gpio/gpiolib.c +@@ -1392,12 +1392,17 @@ int gpiochip_add_data_with_key(struct gp + for (i = 0; i < chip->ngpio; i++) { + struct gpio_desc *desc = &gdev->descs[i]; + +- if (chip->get_direction && gpiochip_line_is_valid(chip, i)) +- desc->flags = !chip->get_direction(chip, i) ? +- (1 << FLAG_IS_OUT) : 0; +- else +- desc->flags = !chip->direction_input ? +- (1 << FLAG_IS_OUT) : 0; ++ if (chip->get_direction && gpiochip_line_is_valid(chip, i)) { ++ if (!chip->get_direction(chip, i)) ++ set_bit(FLAG_IS_OUT, &desc->flags); ++ else ++ clear_bit(FLAG_IS_OUT, &desc->flags); ++ } else { ++ if (!chip->direction_input) ++ set_bit(FLAG_IS_OUT, &desc->flags); ++ else ++ clear_bit(FLAG_IS_OUT, &desc->flags); ++ } + } + + acpi_gpiochip_add(chip); diff --git a/queue-5.2/ib-hfi1-fix-spectre-v1-vulnerability.patch b/queue-5.2/ib-hfi1-fix-spectre-v1-vulnerability.patch new file mode 100644 index 00000000000..c743547e3c0 --- /dev/null +++ b/queue-5.2/ib-hfi1-fix-spectre-v1-vulnerability.patch @@ -0,0 +1,48 @@ +From 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Wed, 31 Jul 2019 12:54:28 -0500 +Subject: IB/hfi1: Fix Spectre v1 vulnerability + +From: Gustavo A. R. Silva + +commit 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e upstream. + +sl is controlled by user-space, hence leading to a potential +exploitation of the Spectre variant 1 vulnerability. + +Fix this by sanitizing sl before using it to index ibp->sl_to_sc. + +Notice that given that speculation windows are large, the policy is +to kill the speculation on the first load and not worry if it can be +completed with a dependent load/store [1]. + +[1] https://lore.kernel.org/lkml/20180423164740.GY17484@dhcp22.suse.cz/ + +Cc: stable@vger.kernel.org +Signed-off-by: Gustavo A. R. Silva +Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/hfi1/verbs.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/infiniband/hw/hfi1/verbs.c ++++ b/drivers/infiniband/hw/hfi1/verbs.c +@@ -54,6 +54,7 @@ + #include + #include + #include ++#include + + #include "hfi.h" + #include "common.h" +@@ -1536,6 +1537,7 @@ static int hfi1_check_ah(struct ib_devic + sl = rdma_ah_get_sl(ah_attr); + if (sl >= ARRAY_SIZE(ibp->sl_to_sc)) + return -EINVAL; ++ sl = array_index_nospec(sl, ARRAY_SIZE(ibp->sl_to_sc)); + + sc5 = ibp->sl_to_sc[sl]; + if (sc_to_vlt(dd, sc5) > num_vls && sc_to_vlt(dd, sc5) != 0xf) diff --git a/queue-5.2/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch b/queue-5.2/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch new file mode 100644 index 00000000000..f1d992b7122 --- /dev/null +++ b/queue-5.2/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch @@ -0,0 +1,57 @@ +From 5241ab4cf42d3a93b933b55d3d53f43049081fa1 Mon Sep 17 00:00:00 2001 +From: Masahiro Yamada +Date: Mon, 29 Jul 2019 18:15:17 +0900 +Subject: kbuild: initialize CLANG_FLAGS correctly in the top Makefile + +From: Masahiro Yamada + +commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream. + +CLANG_FLAGS is initialized by the following line: + + CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%)) + +..., which is run only when CROSS_COMPILE is set. + +Some build targets (bindeb-pkg etc.) recurse to the top Makefile. + +When you build the kernel with Clang but without CROSS_COMPILE, +the same compiler flags such as -no-integrated-as are accumulated +into CLANG_FLAGS. + +If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg', +Kbuild will recompile everything needlessly due to the build command +change. + +Fix this by correctly initializing CLANG_FLAGS. + +Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") +Cc: # v5.0+ +Signed-off-by: Masahiro Yamada +Reviewed-by: Nathan Chancellor +Acked-by: Nick Desaulniers +Signed-off-by: Greg Kroah-Hartman + +--- + Makefile | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/Makefile ++++ b/Makefile +@@ -467,6 +467,7 @@ KBUILD_CFLAGS_MODULE := -DMODULE + KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds + KBUILD_LDFLAGS := + GCC_PLUGINS_CFLAGS := ++CLANG_FLAGS := + + export ARCH SRCARCH CONFIG_SHELL HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC + export CPP AR NM STRIP OBJCOPY OBJDUMP PAHOLE KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS +@@ -519,7 +520,7 @@ endif + + ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),) + ifneq ($(CROSS_COMPILE),) +-CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%)) ++CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) + GCC_TOOLCHAIN_DIR := $(dir $(shell which $(CROSS_COMPILE)elfedit)) + CLANG_FLAGS += --prefix=$(GCC_TOOLCHAIN_DIR) + GCC_TOOLCHAIN := $(realpath $(GCC_TOOLCHAIN_DIR)/..) diff --git a/queue-5.2/kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch b/queue-5.2/kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch new file mode 100644 index 00000000000..5f67228c9f1 --- /dev/null +++ b/queue-5.2/kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch @@ -0,0 +1,41 @@ +From 944cfe9be1fbbec73bab2f7e77fe2e8f9c72970f Mon Sep 17 00:00:00 2001 +From: Masahiro Yamada +Date: Wed, 31 Jul 2019 00:58:59 +0900 +Subject: kbuild: modpost: include .*.cmd files only when targets exist + +From: Masahiro Yamada + +commit 944cfe9be1fbbec73bab2f7e77fe2e8f9c72970f upstream. + +If a build rule fails, the .DELETE_ON_ERROR special target removes the +target, but does nothing for the .*.cmd file, which might be corrupted. +So, .*.cmd files should be included only when the corresponding targets +exist. + +Commit 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd +files") missed to fix up this file. + +Fixes: 392885ee82d3 ("kbuild: let fixdep directly write to .*.cmd") +Cc: # v5.0+ +Signed-off-by: Masahiro Yamada +Signed-off-by: Greg Kroah-Hartman + +--- + scripts/Makefile.modpost | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/scripts/Makefile.modpost ++++ b/scripts/Makefile.modpost +@@ -142,10 +142,8 @@ FORCE: + # optimization, we don't need to read them if the target does not + # exist, we will rebuild anyway in that case. + +-cmd_files := $(wildcard $(foreach f,$(sort $(targets)),$(dir $(f)).$(notdir $(f)).cmd)) ++existing-targets := $(wildcard $(sort $(targets))) + +-ifneq ($(cmd_files),) +- include $(cmd_files) +-endif ++-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd) + + .PHONY: $(PHONY) diff --git a/queue-5.2/kconfig-clear-written-flag-to-avoid-data-loss.patch b/queue-5.2/kconfig-clear-written-flag-to-avoid-data-loss.patch new file mode 100644 index 00000000000..d219ebc9b2a --- /dev/null +++ b/queue-5.2/kconfig-clear-written-flag-to-avoid-data-loss.patch @@ -0,0 +1,52 @@ +From 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce Mon Sep 17 00:00:00 2001 +From: "M. Vefa Bicakci" +Date: Sat, 3 Aug 2019 06:02:12 -0400 +Subject: kconfig: Clear "written" flag to avoid data loss + +From: M. Vefa Bicakci + +commit 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce upstream. + +Prior to this commit, starting nconfig, xconfig or gconfig, and saving +the .config file more than once caused data loss, where a .config file +that contained only comments would be written to disk starting from the +second save operation. + +This bug manifests itself because the SYMBOL_WRITTEN flag is never +cleared after the first call to conf_write, and subsequent calls to +conf_write then skip all of the configuration symbols due to the +SYMBOL_WRITTEN flag being set. + +This commit resolves this issue by clearing the SYMBOL_WRITTEN flag +from all symbols before conf_write returns. + +Fixes: 8e2442a5f86e ("kconfig: fix missing choice values in auto.conf") +Cc: linux-stable # 4.19+ +Signed-off-by: M. Vefa Bicakci +Signed-off-by: Masahiro Yamada +Signed-off-by: Greg Kroah-Hartman + +--- + scripts/kconfig/confdata.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/scripts/kconfig/confdata.c ++++ b/scripts/kconfig/confdata.c +@@ -867,6 +867,7 @@ int conf_write(const char *name) + const char *str; + char tmpname[PATH_MAX + 1], oldname[PATH_MAX + 1]; + char *env; ++ int i; + bool need_newline = false; + + if (!name) +@@ -949,6 +950,9 @@ next: + } + fclose(out); + ++ for_all_symbols(i, sym) ++ sym->flags &= ~SYMBOL_WRITTEN; ++ + if (*tmpname) { + if (is_same(name, tmpname)) { + conf_message("No change to %s", name); diff --git a/queue-5.2/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch b/queue-5.2/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch new file mode 100644 index 00000000000..ff835a54258 --- /dev/null +++ b/queue-5.2/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch @@ -0,0 +1,62 @@ +From ba2d139b02ba684c6c101de42fed782d6cd2b997 Mon Sep 17 00:00:00 2001 +From: Douglas Anderson +Date: Mon, 8 Jul 2019 12:56:13 -0700 +Subject: mmc: dw_mmc: Fix occasional hang after tuning on eMMC + +From: Douglas Anderson + +commit ba2d139b02ba684c6c101de42fed782d6cd2b997 upstream. + +In commit 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after +response errors.") we fixed a tuning-induced hang that I saw when +stress testing tuning on certain SD cards. I won't re-hash that whole +commit, but the summary is that as a normal part of tuning you need to +deal with transfer errors and there were cases where these transfer +errors was putting my system into a bad state causing all future +transfers to fail. That commit fixed handling of the transfer errors +for me. + +In downstream Chrome OS my fix landed and had the same behavior for +all SD/MMC commands. However, it looks like when the commit landed +upstream we limited it to only SD tuning commands. Presumably this +was to try to get around problems that Alim Akhtar reported on exynos +[1]. + +Unfortunately while stress testing reboots (and suspend/resume) on +some rk3288-based Chromebooks I found the same problem on the eMMC on +some of my Chromebooks (the ones with Hynix eMMC). Since the eMMC +tuning command is different (MMC_SEND_TUNING_BLOCK_HS200 +vs. MMC_SEND_TUNING_BLOCK) we were basically getting back into the +same situation. + +I'm hoping that whatever problems exynos was having in the past are +somehow magically fixed now and we can make the behavior the same for +all commands. + +[1] https://lkml.kernel.org/r/CAGOxZ53WfNbaMe0_AM0qBqU47kAfgmPBVZC8K8Y-_J3mDMqW4A@mail.gmail.com + +Fixes: 46d179525a1f ("mmc: dw_mmc: Wait for data transfer after response errors.") +Signed-off-by: Douglas Anderson +Cc: Marek Szyprowski +Cc: Alim Akhtar +Cc: Enric Balletbo i Serra +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/dw_mmc.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/mmc/host/dw_mmc.c ++++ b/drivers/mmc/host/dw_mmc.c +@@ -2034,8 +2034,7 @@ static void dw_mci_tasklet_func(unsigned + * delayed. Allowing the transfer to take place + * avoids races and keeps things simple. + */ +- if ((err != -ETIMEDOUT) && +- (cmd->opcode == MMC_SEND_TUNING_BLOCK)) { ++ if (err != -ETIMEDOUT) { + state = STATE_SENDING_DATA; + continue; + } diff --git a/queue-5.2/mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch b/queue-5.2/mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch new file mode 100644 index 00000000000..86d5c14f57f --- /dev/null +++ b/queue-5.2/mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch @@ -0,0 +1,38 @@ +From fc62113b32c95906b3ea8ba42e91014c7d0c6fa6 Mon Sep 17 00:00:00 2001 +From: Baolin Wang +Date: Mon, 15 Jul 2019 18:00:14 +0800 +Subject: mmc: host: sdhci-sprd: Fix the missing pm_runtime_put_noidle() + +From: Baolin Wang + +commit fc62113b32c95906b3ea8ba42e91014c7d0c6fa6 upstream. + +When the SD host controller tries to probe again due to the derferred +probe mechanism, it will always keep the SD host device as runtime +resume state due to missing the runtime put operation in error path +last time. + +Thus add the pm_runtime_put_noidle() in error path to make the PM runtime +counter balance, which can make the SD host device's PM runtime work well. + +Signed-off-by: Baolin Wang +Acked-by: Adrian Hunter +Fixes: fb8bd90f83c4 ("mmc: sdhci-sprd: Add Spreadtrum's initial host controller") +Cc: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/host/sdhci-sprd.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/mmc/host/sdhci-sprd.c ++++ b/drivers/mmc/host/sdhci-sprd.c +@@ -405,6 +405,7 @@ err_cleanup_host: + sdhci_cleanup_host(host); + + pm_runtime_disable: ++ pm_runtime_put_noidle(&pdev->dev); + pm_runtime_disable(&pdev->dev); + pm_runtime_set_suspended(&pdev->dev); + diff --git a/queue-5.2/mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch b/queue-5.2/mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch new file mode 100644 index 00000000000..6b9eefb724e --- /dev/null +++ b/queue-5.2/mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch @@ -0,0 +1,34 @@ +From 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 Mon Sep 17 00:00:00 2001 +From: Joe Perches +Date: Tue, 9 Jul 2019 22:04:19 -0700 +Subject: mmc: meson-mx-sdio: Fix misuse of GENMASK macro + +From: Joe Perches + +commit 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 upstream. + +Arguments are supposed to be ordered high then low. + +Signed-off-by: Joe Perches +Reviewed-by: Neil Armstrong +Fixes: ed80a13bb4c4 ("mmc: meson-mx-sdio: Add a driver for the Amlogic +Meson8 and Meson8b SoCs") +Cc: stable@vger.kernel.org +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 +@@ -73,7 +73,7 @@ + #define MESON_MX_SDIO_IRQC_IF_CONFIG_MASK GENMASK(7, 6) + #define MESON_MX_SDIO_IRQC_FORCE_DATA_CLK BIT(8) + #define MESON_MX_SDIO_IRQC_FORCE_DATA_CMD BIT(9) +- #define MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK GENMASK(10, 13) ++ #define MESON_MX_SDIO_IRQC_FORCE_DATA_DAT_MASK GENMASK(13, 10) + #define MESON_MX_SDIO_IRQC_SOFT_RESET BIT(15) + #define MESON_MX_SDIO_IRQC_FORCE_HALT BIT(30) + #define MESON_MX_SDIO_IRQC_HALT_HOLE BIT(31) diff --git a/queue-5.2/mmc-mmc_spi-enable-stable-writes.patch b/queue-5.2/mmc-mmc_spi-enable-stable-writes.patch new file mode 100644 index 00000000000..abab5ed57e3 --- /dev/null +++ b/queue-5.2/mmc-mmc_spi-enable-stable-writes.patch @@ -0,0 +1,59 @@ +From 3a6ffb3c8c3274a39dc8f2514526e645c5d21753 Mon Sep 17 00:00:00 2001 +From: Andreas Koop +Date: Mon, 22 Jul 2019 12:03:06 +0800 +Subject: mmc: mmc_spi: Enable stable writes + +From: Andreas Koop + +commit 3a6ffb3c8c3274a39dc8f2514526e645c5d21753 upstream. + +While using the mmc_spi driver occasionally errors like this popped up: + +mmcblk0: error -84 transferring data end_request: I/O error, dev mmcblk0, sector 581756 + +I looked on the Internet for occurrences of the same problem and came +across a helpful post [1]. It includes source code to reproduce the bug. +There is also an analysis about the cause. During transmission data in the +supplied buffer is being modified. Thus the previously calculated checksum +is not correct anymore. + +After some digging I found out that device drivers are supposed to report +they need stable writes. To fix this I set the appropriate flag at queue +initialization if CRC checksumming is enabled for that SPI host. + +[1] +https://groups.google.com/forum/#!msg/sim1/gLlzWeXGFr8/KevXinUXfc8J + +Signed-off-by: Andreas Koop +[shihpo: Rebase on top of v5.3-rc1] +Signed-off-by: ShihPo Hung +Cc: Paul Walmsley +CC: stable@vger.kernel.org +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/queue.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/mmc/core/queue.c ++++ b/drivers/mmc/core/queue.c +@@ -10,6 +10,7 @@ + #include + #include + #include ++#include + + #include + #include +@@ -430,6 +431,10 @@ int mmc_init_queue(struct mmc_queue *mq, + goto free_tag_set; + } + ++ if (mmc_host_is_spi(host) && host->use_spi_crc) ++ mq->queue->backing_dev_info->capabilities |= ++ BDI_CAP_STABLE_WRITES; ++ + mq->queue->queuedata = mq; + blk_queue_rq_timeout(mq->queue, 60 * HZ); + diff --git a/queue-5.2/series b/queue-5.2/series index dbced896f2f..3fddb382244 100644 --- a/queue-5.2/series +++ b/queue-5.2/series @@ -72,3 +72,20 @@ bpf-disable-gcc-fgcse-optimization-for-___bpf_prog_r.patch drm-nouveau-fix-memory-leak-in-nouveau_conn_reset.patch dma-direct-correct-the-physical-addr-in-dma_direct_s.patch drm-nouveau-dmem-missing-mutex_lock-in-error-path.patch +kconfig-clear-written-flag-to-avoid-data-loss.patch +kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch +kbuild-modpost-include-.-.cmd-files-only-when-targets-exist.patch +tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch +btrfs-fix-incremental-send-failure-after-deduplication.patch +btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch +dax-fix-missed-wakeup-in-put_unlocked_entry.patch +fgraph-remove-redundant-ftrace_graph_notrace_addr-test.patch +mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch +mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch +mmc-host-sdhci-sprd-fix-the-missing-pm_runtime_put_noidle.patch +mmc-mmc_spi-enable-stable-writes.patch +gpiolib-preserve-desc-flags-when-setting-state.patch +gpio-don-t-warn-on-null-descs-if-gpiolib-is-disabled.patch +gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch +ib-hfi1-fix-spectre-v1-vulnerability.patch +drm-nouveau-only-release-vcpi-slots-on-mode-changes.patch diff --git a/queue-5.2/tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch b/queue-5.2/tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch new file mode 100644 index 00000000000..3a761b506bb --- /dev/null +++ b/queue-5.2/tpm-fix-null-pointer-dereference-on-chip-register-error-path.patch @@ -0,0 +1,97 @@ +From 1e5ac6300a07ceecfc70a893ebef3352be21e6f8 Mon Sep 17 00:00:00 2001 +From: Milan Broz +Date: Thu, 4 Jul 2019 09:26:15 +0200 +Subject: tpm: Fix null pointer dereference on chip register error path + +From: Milan Broz + +commit 1e5ac6300a07ceecfc70a893ebef3352be21e6f8 upstream. + +If clk_enable is not defined and chip initialization +is canceled code hits null dereference. + +Easily reproducible with vTPM init fail: + swtpm chardev --tpmstate dir=nonexistent_dir --tpm2 --vtpm-proxy + +BUG: kernel NULL pointer dereference, address: 00000000 +... +Call Trace: + tpm_chip_start+0x9d/0xa0 [tpm] + tpm_chip_register+0x10/0x1a0 [tpm] + vtpm_proxy_work+0x11/0x30 [tpm_vtpm_proxy] + process_one_work+0x214/0x5a0 + worker_thread+0x134/0x3e0 + ? process_one_work+0x5a0/0x5a0 + kthread+0xd4/0x100 + ? process_one_work+0x5a0/0x5a0 + ? kthread_park+0x90/0x90 + ret_from_fork+0x19/0x24 + +Fixes: 719b7d81f204 ("tpm: introduce tpm_chip_start() and tpm_chip_stop()") +Cc: stable@vger.kernel.org # v5.1+ +Signed-off-by: Milan Broz +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/char/tpm/tpm-chip.c | 23 ++++++++++++++++------- + 1 file changed, 16 insertions(+), 7 deletions(-) + +--- a/drivers/char/tpm/tpm-chip.c ++++ b/drivers/char/tpm/tpm-chip.c +@@ -77,6 +77,18 @@ static int tpm_go_idle(struct tpm_chip * + return chip->ops->go_idle(chip); + } + ++static void tpm_clk_enable(struct tpm_chip *chip) ++{ ++ if (chip->ops->clk_enable) ++ chip->ops->clk_enable(chip, true); ++} ++ ++static void tpm_clk_disable(struct tpm_chip *chip) ++{ ++ if (chip->ops->clk_enable) ++ chip->ops->clk_enable(chip, false); ++} ++ + /** + * tpm_chip_start() - power on the TPM + * @chip: a TPM chip to use +@@ -89,13 +101,12 @@ int tpm_chip_start(struct tpm_chip *chip + { + int ret; + +- if (chip->ops->clk_enable) +- chip->ops->clk_enable(chip, true); ++ tpm_clk_enable(chip); + + if (chip->locality == -1) { + ret = tpm_request_locality(chip); + if (ret) { +- chip->ops->clk_enable(chip, false); ++ tpm_clk_disable(chip); + return ret; + } + } +@@ -103,8 +114,7 @@ int tpm_chip_start(struct tpm_chip *chip + ret = tpm_cmd_ready(chip); + if (ret) { + tpm_relinquish_locality(chip); +- if (chip->ops->clk_enable) +- chip->ops->clk_enable(chip, false); ++ tpm_clk_disable(chip); + return ret; + } + +@@ -124,8 +134,7 @@ void tpm_chip_stop(struct tpm_chip *chip + { + tpm_go_idle(chip); + tpm_relinquish_locality(chip); +- if (chip->ops->clk_enable) +- chip->ops->clk_enable(chip, false); ++ tpm_clk_disable(chip); + } + EXPORT_SYMBOL_GPL(tpm_chip_stop); + -- 2.47.3