From: Greg Kroah-Hartman Date: Mon, 5 Aug 2019 05:40:32 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.4.188~16 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=46088ca704a3c8f0cab3898e81bf9be738ec1ef0;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: alsa-hda-fix-1-minute-detection-delay-when-i915-module-is-not-available.patch arm64-compat-allow-single-byte-watchpoints-on-all-addresses.patch arm64-cpufeature-fix-feature-comparison-for-ctr_el0.-cwg-erg.patch btrfs-fix-incremental-send-failure-after-deduplication.patch btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch cgroup-kselftest-relax-fs_spec-checks.patch drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch ib-hfi1-check-for-error-on-call-to-alloc_rsm_map_table.patch ib-hfi1-fix-spectre-v1-vulnerability.patch ib-mlx5-fix-clean_mr-to-work-in-the-expected-order.patch ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch ib-mlx5-fix-unreg_umr-to-ignore-the-mkey-state.patch ib-mlx5-move-mrs-to-a-kernel-pd-when-freeing-them-to-the-mr-cache.patch ib-mlx5-use-direct-mkey-destroy-command-upon-umr-unreg-failure.patch kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch kconfig-clear-written-flag-to-avoid-data-loss.patch mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch mtd-rawnand-micron-handle-on-die-ecc-off-devices-correctly.patch nbd-replace-kill_bdev-with-__invalidate_device-again.patch parisc-fix-build-of-compressed-kernel-even-with-debug-enabled.patch s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch selinux-fix-memory-leak-in-policydb_init.patch xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch --- diff --git a/queue-4.19/alsa-hda-fix-1-minute-detection-delay-when-i915-module-is-not-available.patch b/queue-4.19/alsa-hda-fix-1-minute-detection-delay-when-i915-module-is-not-available.patch new file mode 100644 index 00000000000..96e755735e7 --- /dev/null +++ b/queue-4.19/alsa-hda-fix-1-minute-detection-delay-when-i915-module-is-not-available.patch @@ -0,0 +1,52 @@ +From 74bf71ed792ab0f64631cc65ccdb54c356c36d45 Mon Sep 17 00:00:00 2001 +From: Samuel Thibault +Date: Fri, 26 Jul 2019 23:47:02 +0200 +Subject: ALSA: hda: Fix 1-minute detection delay when i915 module is not available + +From: Samuel Thibault + +commit 74bf71ed792ab0f64631cc65ccdb54c356c36d45 upstream. + +Distribution installation images such as Debian include different sets +of modules which can be downloaded dynamically. Such images may notably +include the hda sound modules but not the i915 DRM module, even if the +latter was enabled at build time, as reported on +https://bugs.debian.org/931507 + +In such a case hdac_i915 would be linked in and try to load the i915 +module, fail since it is not there, but still wait for a whole minute +before giving up binding with it. + +This fixes such as case by only waiting for the binding if the module +was properly loaded (or module support is disabled, in which case i915 +is already compiled-in anyway). + +Fixes: f9b54e1961c7 ("ALSA: hda/i915: Allow delayed i915 audio component binding") +Signed-off-by: Samuel Thibault +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/hda/hdac_i915.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/sound/hda/hdac_i915.c ++++ b/sound/hda/hdac_i915.c +@@ -143,10 +143,12 @@ int snd_hdac_i915_init(struct hdac_bus * + if (!acomp) + return -ENODEV; + if (!acomp->ops) { +- request_module("i915"); +- /* 60s timeout */ +- wait_for_completion_timeout(&bind_complete, +- msecs_to_jiffies(60 * 1000)); ++ if (!IS_ENABLED(CONFIG_MODULES) || ++ !request_module("i915")) { ++ /* 60s timeout */ ++ wait_for_completion_timeout(&bind_complete, ++ msecs_to_jiffies(60 * 1000)); ++ } + } + if (!acomp->ops) { + dev_info(bus->dev, "couldn't bind with audio component\n"); diff --git a/queue-4.19/arm64-compat-allow-single-byte-watchpoints-on-all-addresses.patch b/queue-4.19/arm64-compat-allow-single-byte-watchpoints-on-all-addresses.patch new file mode 100644 index 00000000000..d161617ace8 --- /dev/null +++ b/queue-4.19/arm64-compat-allow-single-byte-watchpoints-on-all-addresses.patch @@ -0,0 +1,42 @@ +From 849adec41203ac5837c40c2d7e08490ffdef3c2c Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Mon, 29 Jul 2019 11:06:17 +0100 +Subject: arm64: compat: Allow single-byte watchpoints on all addresses + +From: Will Deacon + +commit 849adec41203ac5837c40c2d7e08490ffdef3c2c upstream. + +Commit d968d2b801d8 ("ARM: 7497/1: hw_breakpoint: allow single-byte +watchpoints on all addresses") changed the validation requirements for +hardware watchpoints on arch/arm/. Update our compat layer to implement +the same relaxation. + +Cc: +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kernel/hw_breakpoint.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/arch/arm64/kernel/hw_breakpoint.c ++++ b/arch/arm64/kernel/hw_breakpoint.c +@@ -547,13 +547,14 @@ int hw_breakpoint_arch_parse(struct perf + /* Aligned */ + break; + case 1: +- /* Allow single byte watchpoint. */ +- if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1) +- break; + case 2: + /* Allow halfword watchpoints and breakpoints. */ + if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2) + break; ++ case 3: ++ /* Allow single byte watchpoint. */ ++ if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1) ++ break; + default: + return -EINVAL; + } diff --git a/queue-4.19/arm64-cpufeature-fix-feature-comparison-for-ctr_el0.-cwg-erg.patch b/queue-4.19/arm64-cpufeature-fix-feature-comparison-for-ctr_el0.-cwg-erg.patch new file mode 100644 index 00000000000..34df10e47e2 --- /dev/null +++ b/queue-4.19/arm64-cpufeature-fix-feature-comparison-for-ctr_el0.-cwg-erg.patch @@ -0,0 +1,70 @@ +From 147b9635e6347104b91f48ca9dca61eb0fbf2a54 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Tue, 30 Jul 2019 15:40:20 +0100 +Subject: arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG} + +From: Will Deacon + +commit 147b9635e6347104b91f48ca9dca61eb0fbf2a54 upstream. + +If CTR_EL0.{CWG,ERG} are 0b0000 then they must be interpreted to have +their architecturally maximum values, which defeats the use of +FTR_HIGHER_SAFE when sanitising CPU ID registers on heterogeneous +machines. + +Introduce FTR_HIGHER_OR_ZERO_SAFE so that these fields effectively +saturate at zero. + +Fixes: 3c739b571084 ("arm64: Keep track of CPU feature registers") +Cc: # 4.4.x- +Reviewed-by: Suzuki K Poulose +Acked-by: Mark Rutland +Signed-off-by: Will Deacon +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/include/asm/cpufeature.h | 7 ++++--- + arch/arm64/kernel/cpufeature.c | 8 ++++++-- + 2 files changed, 10 insertions(+), 5 deletions(-) + +--- a/arch/arm64/include/asm/cpufeature.h ++++ b/arch/arm64/include/asm/cpufeature.h +@@ -45,9 +45,10 @@ + */ + + enum ftr_type { +- FTR_EXACT, /* Use a predefined safe value */ +- FTR_LOWER_SAFE, /* Smaller value is safe */ +- FTR_HIGHER_SAFE,/* Bigger value is safe */ ++ FTR_EXACT, /* Use a predefined safe value */ ++ FTR_LOWER_SAFE, /* Smaller value is safe */ ++ FTR_HIGHER_SAFE, /* Bigger value is safe */ ++ FTR_HIGHER_OR_ZERO_SAFE, /* Bigger value is safe, but 0 is biggest */ + }; + + #define FTR_STRICT true /* SANITY check strict matching required */ +--- a/arch/arm64/kernel/cpufeature.c ++++ b/arch/arm64/kernel/cpufeature.c +@@ -206,8 +206,8 @@ static const struct arm64_ftr_bits ftr_c + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_EXACT, 31, 1, 1), /* RES1 */ + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DIC_SHIFT, 1, 1), + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_IDC_SHIFT, 1, 1), +- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, CTR_CWG_SHIFT, 4, 0), +- ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_SAFE, CTR_ERG_SHIFT, 4, 0), ++ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, CTR_CWG_SHIFT, 4, 0), ++ ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_HIGHER_OR_ZERO_SAFE, CTR_ERG_SHIFT, 4, 0), + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, CTR_DMINLINE_SHIFT, 4, 1), + /* + * Linux can handle differing I-cache policies. Userspace JITs will +@@ -449,6 +449,10 @@ static s64 arm64_ftr_safe_value(const st + case FTR_LOWER_SAFE: + ret = new < cur ? new : cur; + break; ++ case FTR_HIGHER_OR_ZERO_SAFE: ++ if (!cur || !new) ++ break; ++ /* Fallthrough */ + case FTR_HIGHER_SAFE: + ret = new > cur ? new : cur; + break; diff --git a/queue-4.19/btrfs-fix-incremental-send-failure-after-deduplication.patch b/queue-4.19/btrfs-fix-incremental-send-failure-after-deduplication.patch new file mode 100644 index 00000000000..a04019e286b --- /dev/null +++ b/queue-4.19/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 +@@ -6272,68 +6272,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-4.19/btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch b/queue-4.19/btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch new file mode 100644 index 00000000000..50c56adef90 --- /dev/null +++ b/queue-4.19/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 +@@ -2027,6 +2027,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-4.19/cgroup-kselftest-relax-fs_spec-checks.patch b/queue-4.19/cgroup-kselftest-relax-fs_spec-checks.patch new file mode 100644 index 00000000000..cf734f1c105 --- /dev/null +++ b/queue-4.19/cgroup-kselftest-relax-fs_spec-checks.patch @@ -0,0 +1,49 @@ +From b59b1baab789eacdde809135542e3d4f256f6878 Mon Sep 17 00:00:00 2001 +From: Chris Down +Date: Fri, 2 Aug 2019 21:49:15 -0700 +Subject: cgroup: kselftest: relax fs_spec checks + +From: Chris Down + +commit b59b1baab789eacdde809135542e3d4f256f6878 upstream. + +On my laptop most memcg kselftests were being skipped because it claimed +cgroup v2 hierarchy wasn't mounted, but this isn't correct. Instead, it +seems current systemd HEAD mounts it with the name "cgroup2" instead of +"cgroup": + + % grep cgroup /proc/mounts + cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0 + +I can't think of a reason to need to check fs_spec explicitly +since it's arbitrary, so we can just rely on fs_vfstype. + +After these changes, `make TARGETS=cgroup kselftest` actually runs the +cgroup v2 tests in more cases. + +Link: http://lkml.kernel.org/r/20190723210737.GA487@chrisdown.name +Signed-off-by: Chris Down +Cc: Johannes Weiner +Cc: Tejun Heo +Cc: Roman Gushchin +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + tools/testing/selftests/cgroup/cgroup_util.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/tools/testing/selftests/cgroup/cgroup_util.c ++++ b/tools/testing/selftests/cgroup/cgroup_util.c +@@ -181,8 +181,7 @@ int cg_find_unified_root(char *root, siz + strtok(NULL, delim); + strtok(NULL, delim); + +- if (strcmp(fs, "cgroup") == 0 && +- strcmp(type, "cgroup2") == 0) { ++ if (strcmp(type, "cgroup2") == 0) { + strncpy(root, mount, len); + return 0; + } diff --git a/queue-4.19/drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch b/queue-4.19/drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch new file mode 100644 index 00000000000..98543c12e3c --- /dev/null +++ b/queue-4.19/drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch @@ -0,0 +1,36 @@ +From 0d7fd70f26039bd4b33444ca47f0e69ce3ae0354 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Mon, 29 Jul 2019 11:43:48 +0100 +Subject: drivers/perf: arm_pmu: Fix failure path in PM notifier + +From: Will Deacon + +commit 0d7fd70f26039bd4b33444ca47f0e69ce3ae0354 upstream. + +Handling of the CPU_PM_ENTER_FAILED transition in the Arm PMU PM +notifier code incorrectly skips restoration of the counters. Fix the +logic so that CPU_PM_ENTER_FAILED follows the same path as CPU_PM_EXIT. + +Cc: +Fixes: da4e4f18afe0f372 ("drivers/perf: arm_pmu: implement CPU_PM notifier") +Reported-by: Anders Roxell +Acked-by: Lorenzo Pieralisi +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/perf/arm_pmu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/perf/arm_pmu.c ++++ b/drivers/perf/arm_pmu.c +@@ -730,8 +730,8 @@ static int cpu_pm_pmu_notify(struct noti + cpu_pm_pmu_setup(armpmu, cmd); + break; + case CPU_PM_EXIT: +- cpu_pm_pmu_setup(armpmu, cmd); + case CPU_PM_ENTER_FAILED: ++ cpu_pm_pmu_setup(armpmu, cmd); + armpmu->start(armpmu); + break; + default: diff --git a/queue-4.19/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch b/queue-4.19/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch new file mode 100644 index 00000000000..382aec5abc8 --- /dev/null +++ b/queue-4.19/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 +@@ -946,9 +946,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; + irqflags |= IRQF_SHARED; + diff --git a/queue-4.19/ib-hfi1-check-for-error-on-call-to-alloc_rsm_map_table.patch b/queue-4.19/ib-hfi1-check-for-error-on-call-to-alloc_rsm_map_table.patch new file mode 100644 index 00000000000..11f28826913 --- /dev/null +++ b/queue-4.19/ib-hfi1-check-for-error-on-call-to-alloc_rsm_map_table.patch @@ -0,0 +1,66 @@ +From cd48a82087231fdba0e77521102386c6ed0168d6 Mon Sep 17 00:00:00 2001 +From: John Fleck +Date: Mon, 15 Jul 2019 12:45:21 -0400 +Subject: IB/hfi1: Check for error on call to alloc_rsm_map_table + +From: John Fleck + +commit cd48a82087231fdba0e77521102386c6ed0168d6 upstream. + +The call to alloc_rsm_map_table does not check if the kmalloc fails. +Check for a NULL on alloc, and bail if it fails. + +Fixes: 372cc85a13c9 ("IB/hfi1: Extract RSM map table init from QOS") +Link: https://lore.kernel.org/r/20190715164521.74174.27047.stgit@awfm-01.aw.intel.com +Cc: +Reviewed-by: Mike Marciniszyn +Signed-off-by: John Fleck +Signed-off-by: Mike Marciniszyn +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/hfi1/chip.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/drivers/infiniband/hw/hfi1/chip.c ++++ b/drivers/infiniband/hw/hfi1/chip.c +@@ -14586,7 +14586,7 @@ void hfi1_deinit_vnic_rsm(struct hfi1_de + clear_rcvctrl(dd, RCV_CTRL_RCV_RSM_ENABLE_SMASK); + } + +-static void init_rxe(struct hfi1_devdata *dd) ++static int init_rxe(struct hfi1_devdata *dd) + { + struct rsm_map_table *rmt; + u64 val; +@@ -14595,6 +14595,9 @@ static void init_rxe(struct hfi1_devdata + write_csr(dd, RCV_ERR_MASK, ~0ull); + + rmt = alloc_rsm_map_table(dd); ++ if (!rmt) ++ return -ENOMEM; ++ + /* set up QOS, including the QPN map table */ + init_qos(dd, rmt); + init_user_fecn_handling(dd, rmt); +@@ -14621,6 +14624,7 @@ static void init_rxe(struct hfi1_devdata + val |= ((4ull & RCV_BYPASS_HDR_SIZE_MASK) << + RCV_BYPASS_HDR_SIZE_SHIFT); + write_csr(dd, RCV_BYPASS, val); ++ return 0; + } + + static void init_other(struct hfi1_devdata *dd) +@@ -15163,7 +15167,10 @@ struct hfi1_devdata *hfi1_init_dd(struct + goto bail_cleanup; + + /* set initial RXE CSRs */ +- init_rxe(dd); ++ ret = init_rxe(dd); ++ if (ret) ++ goto bail_cleanup; ++ + /* set initial TXE CSRs */ + init_txe(dd); + /* set initial non-RXE, non-TXE CSRs */ diff --git a/queue-4.19/ib-hfi1-fix-spectre-v1-vulnerability.patch b/queue-4.19/ib-hfi1-fix-spectre-v1-vulnerability.patch new file mode 100644 index 00000000000..82b06ad1bb3 --- /dev/null +++ b/queue-4.19/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" +@@ -1596,6 +1597,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-4.19/ib-mlx5-fix-clean_mr-to-work-in-the-expected-order.patch b/queue-4.19/ib-mlx5-fix-clean_mr-to-work-in-the-expected-order.patch new file mode 100644 index 00000000000..9537759a16c --- /dev/null +++ b/queue-4.19/ib-mlx5-fix-clean_mr-to-work-in-the-expected-order.patch @@ -0,0 +1,45 @@ +From b9332dad987018745a0c0bb718d12dacfa760489 Mon Sep 17 00:00:00 2001 +From: Yishai Hadas +Date: Tue, 23 Jul 2019 09:57:28 +0300 +Subject: IB/mlx5: Fix clean_mr() to work in the expected order + +From: Yishai Hadas + +commit b9332dad987018745a0c0bb718d12dacfa760489 upstream. + +Any dma map underlying the MR should only be freed once the MR is fenced +at the hardware. + +As of the above we first destroy the MKEY and just after that can safely +call to dma_unmap_single(). + +Link: https://lore.kernel.org/r/20190723065733.4899-6-leon@kernel.org +Cc: # 4.3 +Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API") +Signed-off-by: Yishai Hadas +Reviewed-by: Artemy Kovalyov +Signed-off-by: Leon Romanovsky +Reviewed-by: Jason Gunthorpe +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/mlx5/mr.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -1620,10 +1620,10 @@ static void clean_mr(struct mlx5_ib_dev + mr->sig = NULL; + } + +- mlx5_free_priv_descs(mr); +- +- if (!allocated_from_cache) ++ if (!allocated_from_cache) { + destroy_mkey(dev, mr); ++ mlx5_free_priv_descs(mr); ++ } + } + + static void dereg_mr(struct mlx5_ib_dev *dev, struct mlx5_ib_mr *mr) diff --git a/queue-4.19/ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch b/queue-4.19/ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch new file mode 100644 index 00000000000..7e48ceec19e --- /dev/null +++ b/queue-4.19/ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch @@ -0,0 +1,39 @@ +From b7165bd0d6cbb93732559be6ea8774653b204480 Mon Sep 17 00:00:00 2001 +From: Yishai Hadas +Date: Tue, 23 Jul 2019 09:57:29 +0300 +Subject: IB/mlx5: Fix RSS Toeplitz setup to be aligned with the HW specification + +From: Yishai Hadas + +commit b7165bd0d6cbb93732559be6ea8774653b204480 upstream. + +The specification for the Toeplitz function doesn't require to set the key +explicitly to be symmetric. In case a symmetric functionality is required +a symmetric key can be simply used. + +Wrongly forcing the algorithm to symmetric causes the wrong packet +distribution and a performance degradation. + +Link: https://lore.kernel.org/r/20190723065733.4899-7-leon@kernel.org +Cc: # 4.7 +Fixes: 28d6137008b2 ("IB/mlx5: Add RSS QP support") +Signed-off-by: Yishai Hadas +Reviewed-by: Alex Vainman +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/mlx5/qp.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx5/qp.c ++++ b/drivers/infiniband/hw/mlx5/qp.c +@@ -1501,7 +1501,6 @@ static int create_rss_raw_qp_tir(struct + } + + MLX5_SET(tirc, tirc, rx_hash_fn, MLX5_RX_HASH_FN_TOEPLITZ); +- MLX5_SET(tirc, tirc, rx_hash_symmetric, 1); + memcpy(rss_key, ucmd.rx_hash_key, len); + break; + } diff --git a/queue-4.19/ib-mlx5-fix-unreg_umr-to-ignore-the-mkey-state.patch b/queue-4.19/ib-mlx5-fix-unreg_umr-to-ignore-the-mkey-state.patch new file mode 100644 index 00000000000..300bf35e9b1 --- /dev/null +++ b/queue-4.19/ib-mlx5-fix-unreg_umr-to-ignore-the-mkey-state.patch @@ -0,0 +1,76 @@ +From 6a053953739d23694474a5f9c81d1a30093da81a Mon Sep 17 00:00:00 2001 +From: Yishai Hadas +Date: Tue, 23 Jul 2019 09:57:25 +0300 +Subject: IB/mlx5: Fix unreg_umr to ignore the mkey state + +From: Yishai Hadas + +commit 6a053953739d23694474a5f9c81d1a30093da81a upstream. + +Fix unreg_umr to ignore the mkey state and do not fail if was freed. This +prevents a case that a user space application already changed the mkey +state to free and then the UMR operation will fail leaving the mkey in an +inappropriate state. + +Link: https://lore.kernel.org/r/20190723065733.4899-3-leon@kernel.org +Cc: # 3.19 +Fixes: 968e78dd9644 ("IB/mlx5: Enhance UMR support to allow partial page table update") +Signed-off-by: Yishai Hadas +Reviewed-by: Artemy Kovalyov +Signed-off-by: Leon Romanovsky +Reviewed-by: Jason Gunthorpe +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + + drivers/infiniband/hw/mlx5/mr.c | 4 ++-- + drivers/infiniband/hw/mlx5/qp.c | 12 ++++++++---- + 3 files changed, 11 insertions(+), 6 deletions(-) + +--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h ++++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h +@@ -467,6 +467,7 @@ struct mlx5_umr_wr { + u64 length; + int access_flags; + u32 mkey; ++ u8 ignore_free_state:1; + }; + + static inline const struct mlx5_umr_wr *umr_wr(const struct ib_send_wr *wr) +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -1407,10 +1407,10 @@ static int unreg_umr(struct mlx5_ib_dev + if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) + return 0; + +- umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR | +- MLX5_IB_SEND_UMR_FAIL_IF_FREE; ++ umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR; + umrwr.wr.opcode = MLX5_IB_WR_UMR; + umrwr.mkey = mr->mmkey.key; ++ umrwr.ignore_free_state = 1; + + return mlx5_ib_post_send_wait(dev, &umrwr); + } +--- a/drivers/infiniband/hw/mlx5/qp.c ++++ b/drivers/infiniband/hw/mlx5/qp.c +@@ -3717,10 +3717,14 @@ static int set_reg_umr_segment(struct ml + + memset(umr, 0, sizeof(*umr)); + +- if (wr->send_flags & MLX5_IB_SEND_UMR_FAIL_IF_FREE) +- umr->flags = MLX5_UMR_CHECK_FREE; /* fail if free */ +- else +- umr->flags = MLX5_UMR_CHECK_NOT_FREE; /* fail if not free */ ++ if (!umrwr->ignore_free_state) { ++ if (wr->send_flags & MLX5_IB_SEND_UMR_FAIL_IF_FREE) ++ /* fail if free */ ++ umr->flags = MLX5_UMR_CHECK_FREE; ++ else ++ /* fail if not free */ ++ umr->flags = MLX5_UMR_CHECK_NOT_FREE; ++ } + + umr->xlt_octowords = cpu_to_be16(get_xlt_octo(umrwr->xlt_size)); + if (wr->send_flags & MLX5_IB_SEND_UMR_UPDATE_XLT) { diff --git a/queue-4.19/ib-mlx5-move-mrs-to-a-kernel-pd-when-freeing-them-to-the-mr-cache.patch b/queue-4.19/ib-mlx5-move-mrs-to-a-kernel-pd-when-freeing-them-to-the-mr-cache.patch new file mode 100644 index 00000000000..47497e4a23a --- /dev/null +++ b/queue-4.19/ib-mlx5-move-mrs-to-a-kernel-pd-when-freeing-them-to-the-mr-cache.patch @@ -0,0 +1,47 @@ +From 9ec4483a3f0f71a228a5933bc040441322bfb090 Mon Sep 17 00:00:00 2001 +From: Yishai Hadas +Date: Tue, 23 Jul 2019 09:57:27 +0300 +Subject: IB/mlx5: Move MRs to a kernel PD when freeing them to the MR cache + +From: Yishai Hadas + +commit 9ec4483a3f0f71a228a5933bc040441322bfb090 upstream. + +Fix unreg_umr to move the MR to a kernel owned PD (i.e. the UMR PD) which +can't be accessed by userspace. + +This ensures that nothing can continue to access the MR once it has been +placed in the kernels cache for reuse. + +MRs in the cache continue to have their HW state, including DMA tables, +present. Even though the MR has been invalidated, changing the PD provides +an additional layer of protection against use of the MR. + +Link: https://lore.kernel.org/r/20190723065733.4899-5-leon@kernel.org +Cc: # 3.10 +Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") +Signed-off-by: Yishai Hadas +Reviewed-by: Artemy Kovalyov +Signed-off-by: Leon Romanovsky +Reviewed-by: Jason Gunthorpe +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/mlx5/mr.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -1410,8 +1410,10 @@ static int unreg_umr(struct mlx5_ib_dev + if (mdev->state == MLX5_DEVICE_STATE_INTERNAL_ERROR) + return 0; + +- umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR; ++ umrwr.wr.send_flags = MLX5_IB_SEND_UMR_DISABLE_MR | ++ MLX5_IB_SEND_UMR_UPDATE_PD_ACCESS; + umrwr.wr.opcode = MLX5_IB_WR_UMR; ++ umrwr.pd = dev->umrc.pd; + umrwr.mkey = mr->mmkey.key; + umrwr.ignore_free_state = 1; + diff --git a/queue-4.19/ib-mlx5-use-direct-mkey-destroy-command-upon-umr-unreg-failure.patch b/queue-4.19/ib-mlx5-use-direct-mkey-destroy-command-upon-umr-unreg-failure.patch new file mode 100644 index 00000000000..3fbf53cafae --- /dev/null +++ b/queue-4.19/ib-mlx5-use-direct-mkey-destroy-command-upon-umr-unreg-failure.patch @@ -0,0 +1,59 @@ +From afd1417404fba6dbfa6c0a8e5763bd348da682e4 Mon Sep 17 00:00:00 2001 +From: Yishai Hadas +Date: Tue, 23 Jul 2019 09:57:26 +0300 +Subject: IB/mlx5: Use direct mkey destroy command upon UMR unreg failure + +From: Yishai Hadas + +commit afd1417404fba6dbfa6c0a8e5763bd348da682e4 upstream. + +Use a direct firmware command to destroy the mkey in case the unreg UMR +operation has failed. + +This prevents a case that a mkey will leak out from the cache post a +failure to be destroyed by a UMR WR. + +In case the MR cache limit didn't reach a call to add another entry to the +cache instead of the destroyed one is issued. + +In addition, replaced a warn message to WARN_ON() as this flow is fatal +and can't happen unless some bug around. + +Link: https://lore.kernel.org/r/20190723065733.4899-4-leon@kernel.org +Cc: # 4.10 +Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib") +Signed-off-by: Yishai Hadas +Reviewed-by: Artemy Kovalyov +Signed-off-by: Leon Romanovsky +Reviewed-by: Jason Gunthorpe +Signed-off-by: Jason Gunthorpe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/hw/mlx5/mr.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -548,13 +548,16 @@ void mlx5_mr_cache_free(struct mlx5_ib_d + return; + + c = order2idx(dev, mr->order); +- if (c < 0 || c >= MAX_MR_CACHE_ENTRIES) { +- mlx5_ib_warn(dev, "order %d, cache index %d\n", mr->order, c); +- return; +- } ++ WARN_ON(c < 0 || c >= MAX_MR_CACHE_ENTRIES); + +- if (unreg_umr(dev, mr)) ++ if (unreg_umr(dev, mr)) { ++ mr->allocated_from_cache = false; ++ destroy_mkey(dev, mr); ++ ent = &cache->ent[c]; ++ if (ent->cur < ent->limit) ++ queue_work(cache->wq, &ent->work); + return; ++ } + + ent = &cache->ent[c]; + spin_lock_irq(&ent->lock); diff --git a/queue-4.19/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch b/queue-4.19/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch new file mode 100644 index 00000000000..9a8eae393f5 --- /dev/null +++ b/queue-4.19/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 +@@ -430,6 +430,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 KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS +@@ -482,7 +483,7 @@ endif + + ifeq ($(cc-name),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-4.19/kconfig-clear-written-flag-to-avoid-data-loss.patch b/queue-4.19/kconfig-clear-written-flag-to-avoid-data-loss.patch new file mode 100644 index 00000000000..a02ca739556 --- /dev/null +++ b/queue-4.19/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 +@@ -784,6 +784,7 @@ int conf_write(const char *name) + const char *str; + char dirname[PATH_MAX+1], tmpname[PATH_MAX+22], newname[PATH_MAX+8]; + char *env; ++ int i; + + dirname[0] = 0; + if (name && name[0]) { +@@ -860,6 +861,9 @@ next: + } + fclose(out); + ++ for_all_symbols(i, sym) ++ sym->flags &= ~SYMBOL_WRITTEN; ++ + if (*tmpname) { + strcat(dirname, basename); + strcat(dirname, ".old"); diff --git a/queue-4.19/mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch b/queue-4.19/mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch new file mode 100644 index 00000000000..47e157d8224 --- /dev/null +++ b/queue-4.19/mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch @@ -0,0 +1,61 @@ +From fa1e512fac717f34e7c12d7a384c46e90a647392 Mon Sep 17 00:00:00 2001 +From: Yang Shi +Date: Fri, 2 Aug 2019 21:48:44 -0700 +Subject: mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker + +From: Yang Shi + +commit fa1e512fac717f34e7c12d7a384c46e90a647392 upstream. + +Shakeel Butt reported premature oom on kernel with +"cgroup_disable=memory" since mem_cgroup_is_root() returns false even +though memcg is actually NULL. The drop_caches is also broken. + +It is because commit aeed1d325d42 ("mm/vmscan.c: generalize +shrink_slab() calls in shrink_node()") removed the !memcg check before +!mem_cgroup_is_root(). And, surprisingly root memcg is allocated even +though memory cgroup is disabled by kernel boot parameter. + +Add mem_cgroup_disabled() check to make reclaimer work as expected. + +Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.alibaba.com +Fixes: aeed1d325d42 ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()") +Signed-off-by: Yang Shi +Reported-by: Shakeel Butt +Reviewed-by: Shakeel Butt +Reviewed-by: Kirill Tkhai +Acked-by: Michal Hocko +Cc: Jan Hadrava +Cc: Vladimir Davydov +Cc: Johannes Weiner +Cc: Roman Gushchin +Cc: Hugh Dickins +Cc: Qian Cai +Cc: Kirill A. Shutemov +Cc: [4.19+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmscan.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -670,7 +670,14 @@ static unsigned long shrink_slab(gfp_t g + unsigned long ret, freed = 0; + struct shrinker *shrinker; + +- if (!mem_cgroup_is_root(memcg)) ++ /* ++ * The root memcg might be allocated even though memcg is disabled ++ * via "cgroup_disable=memory" boot parameter. This could make ++ * mem_cgroup_is_root() return false, then just run memcg slab ++ * shrink, but skip global shrink. This may result in premature ++ * oom. ++ */ ++ if (!mem_cgroup_disabled() && !mem_cgroup_is_root(memcg)) + return shrink_slab_memcg(gfp_mask, nid, memcg, priority); + + if (!down_read_trylock(&shrinker_rwsem)) diff --git a/queue-4.19/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch b/queue-4.19/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch new file mode 100644 index 00000000000..6b14ec82a80 --- /dev/null +++ b/queue-4.19/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 +@@ -2038,8 +2038,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-4.19/mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch b/queue-4.19/mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch new file mode 100644 index 00000000000..a27fe545e14 --- /dev/null +++ b/queue-4.19/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 +@@ -76,7 +76,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-4.19/mtd-rawnand-micron-handle-on-die-ecc-off-devices-correctly.patch b/queue-4.19/mtd-rawnand-micron-handle-on-die-ecc-off-devices-correctly.patch new file mode 100644 index 00000000000..c7d14e18500 --- /dev/null +++ b/queue-4.19/mtd-rawnand-micron-handle-on-die-ecc-off-devices-correctly.patch @@ -0,0 +1,70 @@ +From 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c Mon Sep 17 00:00:00 2001 +From: Marco Felsch +Date: Tue, 30 Jul 2019 15:44:07 +0200 +Subject: mtd: rawnand: micron: handle on-die "ECC-off" devices correctly + +From: Marco Felsch + +commit 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c upstream. + +Some devices are not supposed to support on-die ECC but experience +shows that internal ECC machinery can actually be enabled through the +"SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter +Tables" returns that it is not. + +Currently, the driver checks the "READ ID Parameter" field directly +after having enabled the feature. If the check fails it returns +immediately but leaves the ECC on. When using buggy chips like +MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will +go through the on-die ECC, confusing the host controller which is +supposed to be the one handling correction. + +To address this in a common way we need to turn off the on-die ECC +directly after reading the "READ ID Parameter" and before checking the +"ECC status". + +Cc: stable@vger.kernel.org +Fixes: dbc44edbf833 ("mtd: rawnand: micron: Fix on-die ECC detection logic") +Signed-off-by: Marco Felsch +Reviewed-by: Boris Brezillon +Signed-off-by: Miquel Raynal +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mtd/nand/raw/nand_micron.c | 14 +++++++++++--- + 1 file changed, 11 insertions(+), 3 deletions(-) + +--- a/drivers/mtd/nand/raw/nand_micron.c ++++ b/drivers/mtd/nand/raw/nand_micron.c +@@ -400,6 +400,14 @@ static int micron_supports_on_die_ecc(st + (chip->id.data[4] & MICRON_ID_INTERNAL_ECC_MASK) != 0x2) + return MICRON_ON_DIE_UNSUPPORTED; + ++ /* ++ * It seems that there are devices which do not support ECC officially. ++ * At least the MT29F2G08ABAGA / MT29F2G08ABBGA devices supports ++ * enabling the ECC feature but don't reflect that to the READ_ID table. ++ * So we have to guarantee that we disable the ECC feature directly ++ * after we did the READ_ID table command. Later we can evaluate the ++ * ECC_ENABLE support. ++ */ + ret = micron_nand_on_die_ecc_setup(chip, true); + if (ret) + return MICRON_ON_DIE_UNSUPPORTED; +@@ -408,13 +416,13 @@ static int micron_supports_on_die_ecc(st + if (ret) + return MICRON_ON_DIE_UNSUPPORTED; + +- if (!(id[4] & MICRON_ID_ECC_ENABLED)) +- return MICRON_ON_DIE_UNSUPPORTED; +- + ret = micron_nand_on_die_ecc_setup(chip, false); + if (ret) + return MICRON_ON_DIE_UNSUPPORTED; + ++ if (!(id[4] & MICRON_ID_ECC_ENABLED)) ++ return MICRON_ON_DIE_UNSUPPORTED; ++ + ret = nand_readid_op(chip, 0, id, sizeof(id)); + if (ret) + return MICRON_ON_DIE_UNSUPPORTED; diff --git a/queue-4.19/nbd-replace-kill_bdev-with-__invalidate_device-again.patch b/queue-4.19/nbd-replace-kill_bdev-with-__invalidate_device-again.patch new file mode 100644 index 00000000000..a58683a4b4a --- /dev/null +++ b/queue-4.19/nbd-replace-kill_bdev-with-__invalidate_device-again.patch @@ -0,0 +1,74 @@ +From 2b5c8f0063e4b263cf2de82029798183cf85c320 Mon Sep 17 00:00:00 2001 +From: Munehisa Kamata +Date: Wed, 31 Jul 2019 20:13:10 +0800 +Subject: nbd: replace kill_bdev() with __invalidate_device() again + +From: Munehisa Kamata + +commit 2b5c8f0063e4b263cf2de82029798183cf85c320 upstream. + +Commit abbbdf12497d ("replace kill_bdev() with __invalidate_device()") +once did this, but 29eaadc03649 ("nbd: stop using the bdev everywhere") +resurrected kill_bdev() and it has been there since then. So buffer_head +mappings still get killed on a server disconnection, and we can still +hit the BUG_ON on a filesystem on the top of the nbd device. + + EXT4-fs (nbd0): mounted filesystem with ordered data mode. Opts: (null) + block nbd0: Receive control failed (result -32) + block nbd0: shutting down sockets + print_req_error: I/O error, dev nbd0, sector 66264 flags 3000 + EXT4-fs warning (device nbd0): htree_dirblock_to_tree:979: inode #2: lblock 0: comm ls: error -5 reading directory block + print_req_error: I/O error, dev nbd0, sector 2264 flags 3000 + EXT4-fs error (device nbd0): __ext4_get_inode_loc:4690: inode #2: block 283: comm ls: unable to read itable block + EXT4-fs error (device nbd0) in ext4_reserve_inode_write:5894: IO failure + ------------[ cut here ]------------ + kernel BUG at fs/buffer.c:3057! + invalid opcode: 0000 [#1] SMP PTI + CPU: 7 PID: 40045 Comm: jbd2/nbd0-8 Not tainted 5.1.0-rc3+ #4 + Hardware name: Amazon EC2 m5.12xlarge/, BIOS 1.0 10/16/2017 + RIP: 0010:submit_bh_wbc+0x18b/0x190 + ... + Call Trace: + jbd2_write_superblock+0xf1/0x230 [jbd2] + ? account_entity_enqueue+0xc5/0xf0 + jbd2_journal_update_sb_log_tail+0x94/0xe0 [jbd2] + jbd2_journal_commit_transaction+0x12f/0x1d20 [jbd2] + ? __switch_to_asm+0x40/0x70 + ... + ? lock_timer_base+0x67/0x80 + kjournald2+0x121/0x360 [jbd2] + ? remove_wait_queue+0x60/0x60 + kthread+0xf8/0x130 + ? commit_timeout+0x10/0x10 [jbd2] + ? kthread_bind+0x10/0x10 + ret_from_fork+0x35/0x40 + +With __invalidate_device(), I no longer hit the BUG_ON with sync or +unmount on the disconnected device. + +Fixes: 29eaadc03649 ("nbd: stop using the bdev everywhere") +Cc: linux-block@vger.kernel.org +Cc: Ratna Manoj Bolla +Cc: nbd@other.debian.org +Cc: stable@vger.kernel.org +Cc: David Woodhouse +Reviewed-by: Josef Bacik +Signed-off-by: Munehisa Kamata +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/block/nbd.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/block/nbd.c ++++ b/drivers/block/nbd.c +@@ -1218,7 +1218,7 @@ static void nbd_clear_sock_ioctl(struct + struct block_device *bdev) + { + sock_shutdown(nbd); +- kill_bdev(bdev); ++ __invalidate_device(bdev, true); + nbd_bdev_reset(bdev); + if (test_and_clear_bit(NBD_HAS_CONFIG_REF, + &nbd->config->runtime_flags)) diff --git a/queue-4.19/parisc-fix-build-of-compressed-kernel-even-with-debug-enabled.patch b/queue-4.19/parisc-fix-build-of-compressed-kernel-even-with-debug-enabled.patch new file mode 100644 index 00000000000..c6f405fb3ae --- /dev/null +++ b/queue-4.19/parisc-fix-build-of-compressed-kernel-even-with-debug-enabled.patch @@ -0,0 +1,36 @@ +From 3fe6c873af2f2247544debdbe51ec29f690a2ccf Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Thu, 1 Aug 2019 13:33:39 +0200 +Subject: parisc: Fix build of compressed kernel even with debug enabled + +From: Helge Deller + +commit 3fe6c873af2f2247544debdbe51ec29f690a2ccf upstream. + +With debug info enabled (CONFIG_DEBUG_INFO=y) the resulting vmlinux may get +that huge that we need to increase the start addresss for the decompression +text section otherwise one will face a linker error. + +Reported-by: Sven Schnelle +Tested-by: Sven Schnelle +Cc: stable@vger.kernel.org # v4.14+ +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman + +--- + arch/parisc/boot/compressed/vmlinux.lds.S | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/parisc/boot/compressed/vmlinux.lds.S ++++ b/arch/parisc/boot/compressed/vmlinux.lds.S +@@ -42,8 +42,8 @@ SECTIONS + #endif + _startcode_end = .; + +- /* bootloader code and data starts behind area of extracted kernel */ +- . = (SZ_end - SZparisc_kernel_start + KERNEL_BINARY_TEXT_START); ++ /* bootloader code and data starts at least behind area of extracted kernel */ ++ . = MAX(ABSOLUTE(.), (SZ_end - SZparisc_kernel_start + KERNEL_BINARY_TEXT_START)); + + /* align on next page boundary */ + . = ALIGN(4096); diff --git a/queue-4.19/s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch b/queue-4.19/s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch new file mode 100644 index 00000000000..80ab9045725 --- /dev/null +++ b/queue-4.19/s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch @@ -0,0 +1,73 @@ +From 41995342b40c418a47603e1321256d2c4a2ed0fb Mon Sep 17 00:00:00 2001 +From: Stefan Haberland +Date: Thu, 1 Aug 2019 13:06:30 +0200 +Subject: s390/dasd: fix endless loop after read unit address configuration + +From: Stefan Haberland + +commit 41995342b40c418a47603e1321256d2c4a2ed0fb upstream. + +After getting a storage server event that causes the DASD device driver +to update its unit address configuration during a device shutdown there is +the possibility of an endless loop in the device driver. + +In the system log there will be ongoing DASD error messages with RC: -19. + +The reason is that the loop starting the ruac request only terminates when +the retry counter is decreased to 0. But in the sleep_on function there are +early exit paths that do not decrease the retry counter. + +Prevent an endless loop by handling those cases separately. + +Remove the unnecessary do..while loop since the sleep_on function takes +care of retries by itself. + +Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1") +Cc: stable@vger.kernel.org # 2.6.25+ +Signed-off-by: Stefan Haberland +Reviewed-by: Jan Hoeppner +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/block/dasd_alias.c | 22 ++++++++++++++++------ + 1 file changed, 16 insertions(+), 6 deletions(-) + +--- a/drivers/s390/block/dasd_alias.c ++++ b/drivers/s390/block/dasd_alias.c +@@ -383,6 +383,20 @@ suborder_not_supported(struct dasd_ccw_r + char msg_format; + char msg_no; + ++ /* ++ * intrc values ENODEV, ENOLINK and EPERM ++ * will be optained from sleep_on to indicate that no ++ * IO operation can be started ++ */ ++ if (cqr->intrc == -ENODEV) ++ return 1; ++ ++ if (cqr->intrc == -ENOLINK) ++ return 1; ++ ++ if (cqr->intrc == -EPERM) ++ return 1; ++ + sense = dasd_get_sense(&cqr->irb); + if (!sense) + return 0; +@@ -447,12 +461,8 @@ static int read_unit_address_configurati + lcu->flags &= ~NEED_UAC_UPDATE; + spin_unlock_irqrestore(&lcu->lock, flags); + +- do { +- rc = dasd_sleep_on(cqr); +- if (rc && suborder_not_supported(cqr)) +- return -EOPNOTSUPP; +- } while (rc && (cqr->retries > 0)); +- if (rc) { ++ rc = dasd_sleep_on(cqr); ++ if (rc && !suborder_not_supported(cqr)) { + spin_lock_irqsave(&lcu->lock, flags); + lcu->flags |= NEED_UAC_UPDATE; + spin_unlock_irqrestore(&lcu->lock, flags); diff --git a/queue-4.19/selinux-fix-memory-leak-in-policydb_init.patch b/queue-4.19/selinux-fix-memory-leak-in-policydb_init.patch new file mode 100644 index 00000000000..5c728308a37 --- /dev/null +++ b/queue-4.19/selinux-fix-memory-leak-in-policydb_init.patch @@ -0,0 +1,47 @@ +From 45385237f65aeee73641f1ef737d7273905a233f Mon Sep 17 00:00:00 2001 +From: Ondrej Mosnacek +Date: Thu, 25 Jul 2019 12:52:43 +0200 +Subject: selinux: fix memory leak in policydb_init() + +From: Ondrej Mosnacek + +commit 45385237f65aeee73641f1ef737d7273905a233f upstream. + +Since roles_init() adds some entries to the role hash table, we need to +destroy also its keys/values on error, otherwise we get a memory leak in +the error path. + +Cc: +Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Ondrej Mosnacek +Signed-off-by: Paul Moore +Signed-off-by: Greg Kroah-Hartman + +--- + security/selinux/ss/policydb.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/security/selinux/ss/policydb.c ++++ b/security/selinux/ss/policydb.c +@@ -275,6 +275,8 @@ static int rangetr_cmp(struct hashtab *h + return v; + } + ++static int (*destroy_f[SYM_NUM]) (void *key, void *datum, void *datap); ++ + /* + * Initialize a policy database structure. + */ +@@ -322,8 +324,10 @@ static int policydb_init(struct policydb + out: + hashtab_destroy(p->filename_trans); + hashtab_destroy(p->range_tr); +- for (i = 0; i < SYM_NUM; i++) ++ for (i = 0; i < SYM_NUM; i++) { ++ hashtab_map(p->symtab[i].table, destroy_f[i], NULL); + hashtab_destroy(p->symtab[i].table); ++ } + return rc; + } + diff --git a/queue-4.19/series b/queue-4.19/series index 61a4dd03683..b3ff9545f62 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -39,3 +39,29 @@ x86-kvm-don-t-call-kvm_spurious_fault-from-.fixup.patch x86-paravirt-fix-callee-saved-function-elf-sizes.patch x86-boot-remove-multiple-copy-of-static-function-san.patch drm-nouveau-fix-memory-leak-in-nouveau_conn_reset.patch +kconfig-clear-written-flag-to-avoid-data-loss.patch +kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch +btrfs-fix-incremental-send-failure-after-deduplication.patch +btrfs-fix-race-leading-to-fs-corruption-after-transaction-abort.patch +mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch +mmc-meson-mx-sdio-fix-misuse-of-genmask-macro.patch +gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch +ib-hfi1-fix-spectre-v1-vulnerability.patch +mtd-rawnand-micron-handle-on-die-ecc-off-devices-correctly.patch +selinux-fix-memory-leak-in-policydb_init.patch +alsa-hda-fix-1-minute-detection-delay-when-i915-module-is-not-available.patch +mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch +s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch +cgroup-kselftest-relax-fs_spec-checks.patch +parisc-fix-build-of-compressed-kernel-even-with-debug-enabled.patch +drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch +arm64-compat-allow-single-byte-watchpoints-on-all-addresses.patch +arm64-cpufeature-fix-feature-comparison-for-ctr_el0.-cwg-erg.patch +nbd-replace-kill_bdev-with-__invalidate_device-again.patch +xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch +ib-mlx5-fix-unreg_umr-to-ignore-the-mkey-state.patch +ib-mlx5-use-direct-mkey-destroy-command-upon-umr-unreg-failure.patch +ib-mlx5-move-mrs-to-a-kernel-pd-when-freeing-them-to-the-mr-cache.patch +ib-mlx5-fix-clean_mr-to-work-in-the-expected-order.patch +ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch +ib-hfi1-check-for-error-on-call-to-alloc_rsm_map_table.patch diff --git a/queue-4.19/xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch b/queue-4.19/xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch new file mode 100644 index 00000000000..5ea4209cf9a --- /dev/null +++ b/queue-4.19/xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch @@ -0,0 +1,44 @@ +From 50f6393f9654c561df4cdcf8e6cfba7260143601 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Fri, 14 Jun 2019 07:46:02 +0200 +Subject: xen/swiotlb: fix condition for calling xen_destroy_contiguous_region() + +From: Juergen Gross + +commit 50f6393f9654c561df4cdcf8e6cfba7260143601 upstream. + +The condition in xen_swiotlb_free_coherent() for deciding whether to +call xen_destroy_contiguous_region() is wrong: in case the region to +be freed is not contiguous calling xen_destroy_contiguous_region() is +the wrong thing to do: it would result in inconsistent mappings of +multiple PFNs to the same MFN. This will lead to various strange +crashes or data corruption. + +Instead of calling xen_destroy_contiguous_region() in that case a +warning should be issued as that situation should never occur. + +Cc: stable@vger.kernel.org +Signed-off-by: Juergen Gross +Reviewed-by: Boris Ostrovsky +Reviewed-by: Jan Beulich +Acked-by: Konrad Rzeszutek Wilk +Signed-off-by: Juergen Gross +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/xen/swiotlb-xen.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/xen/swiotlb-xen.c ++++ b/drivers/xen/swiotlb-xen.c +@@ -357,8 +357,8 @@ xen_swiotlb_free_coherent(struct device + /* Convert the size to actually allocated. */ + size = 1UL << (order + XEN_PAGE_SHIFT); + +- if (((dev_addr + size - 1 <= dma_mask)) || +- range_straddles_page_boundary(phys, size)) ++ if (!WARN_ON((dev_addr + size - 1 > dma_mask) || ++ range_straddles_page_boundary(phys, size))) + xen_destroy_contiguous_region(phys, order); + + xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);