--- /dev/null
+From 74bf71ed792ab0f64631cc65ccdb54c356c36d45 Mon Sep 17 00:00:00 2001
+From: Samuel Thibault <samuel.thibault@ens-lyon.org>
+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 <samuel.thibault@ens-lyon.org>
+
+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 <samuel.thibault@ens-lyon.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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");
--- /dev/null
+From 849adec41203ac5837c40c2d7e08490ffdef3c2c Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Mon, 29 Jul 2019 11:06:17 +0100
+Subject: arm64: compat: Allow single-byte watchpoints on all addresses
+
+From: Will Deacon <will@kernel.org>
+
+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: <stable@vger.kernel.org>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 147b9635e6347104b91f48ca9dca61eb0fbf2a54 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Tue, 30 Jul 2019 15:40:20 +0100
+Subject: arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG}
+
+From: Will Deacon <will@kernel.org>
+
+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: <stable@vger.kernel.org> # 4.4.x-
+Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From b4f9a1a87a48c255bb90d8a6c3d555a1abb88130 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Wed, 17 Jul 2019 13:23:39 +0100
+Subject: Btrfs: fix incremental send failure after deduplication
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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 <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From cb2d3daddbfb6318d170e79aac1f7d5e4d49f0d7 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Thu, 25 Jul 2019 11:27:04 +0100
+Subject: Btrfs: fix race leading to fs corruption after transaction abort
+
+From: Filipe Manana <fdmanana@suse.com>
+
+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
+
+ <at transaction N>
+
+ 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 <josef@toxicpanda.com>
+Signed-off-by: Filipe Manana <fdmanana@suse.com>
+Reviewed-by: David Sterba <dsterba@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/btrfs/transaction.c | 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);
--- /dev/null
+From b59b1baab789eacdde809135542e3d4f256f6878 Mon Sep 17 00:00:00 2001
+From: Chris Down <chris@chrisdown.name>
+Date: Fri, 2 Aug 2019 21:49:15 -0700
+Subject: cgroup: kselftest: relax fs_spec checks
+
+From: Chris Down <chris@chrisdown.name>
+
+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 <chris@chrisdown.name>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Roman Gushchin <guro@fb.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 0d7fd70f26039bd4b33444ca47f0e69ce3ae0354 Mon Sep 17 00:00:00 2001
+From: Will Deacon <will@kernel.org>
+Date: Mon, 29 Jul 2019 11:43:48 +0100
+Subject: drivers/perf: arm_pmu: Fix failure path in PM notifier
+
+From: Will Deacon <will@kernel.org>
+
+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: <stable@vger.kernel.org>
+Fixes: da4e4f18afe0f372 ("drivers/perf: arm_pmu: implement CPU_PM notifier")
+Reported-by: Anders Roxell <anders.roxell@linaro.org>
+Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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:
--- /dev/null
+From 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 Mon Sep 17 00:00:00 2001
+From: Michael Wu <michael.wu@vatics.com>
+Date: Mon, 8 Jul 2019 13:23:08 +0800
+Subject: gpiolib: fix incorrect IRQ requesting of an active-low lineevent
+
+From: Michael Wu <michael.wu@vatics.com>
+
+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 <michael.wu@vatics.com>
+Tested-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From cd48a82087231fdba0e77521102386c6ed0168d6 Mon Sep 17 00:00:00 2001
+From: John Fleck <john.fleck@intel.com>
+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 <john.fleck@intel.com>
+
+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: <stable@vger.kernel.org>
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: John Fleck <john.fleck@intel.com>
+Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From 6497d0a9c53df6e98b25e2b79f2295d7caa47b6e Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Wed, 31 Jul 2019 12:54:28 -0500
+Subject: IB/hfi1: Fix Spectre v1 vulnerability
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+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 <gustavo@embeddedor.com>
+Link: https://lore.kernel.org/r/20190731175428.GA16736@embeddedor
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 <linux/mm.h>
+ #include <linux/vmalloc.h>
+ #include <rdma/opa_addr.h>
++#include <linux/nospec.h>
+
+ #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)
--- /dev/null
+From b9332dad987018745a0c0bb718d12dacfa760489 Mon Sep 17 00:00:00 2001
+From: Yishai Hadas <yishaih@mellanox.com>
+Date: Tue, 23 Jul 2019 09:57:28 +0300
+Subject: IB/mlx5: Fix clean_mr() to work in the expected order
+
+From: Yishai Hadas <yishaih@mellanox.com>
+
+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: <stable@vger.kernel.org> # 4.3
+Fixes: 8a187ee52b04 ("IB/mlx5: Support the new memory registration API")
+Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
+Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From b7165bd0d6cbb93732559be6ea8774653b204480 Mon Sep 17 00:00:00 2001
+From: Yishai Hadas <yishaih@mellanox.com>
+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 <yishaih@mellanox.com>
+
+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: <stable@vger.kernel.org> # 4.7
+Fixes: 28d6137008b2 ("IB/mlx5: Add RSS QP support")
+Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
+Reviewed-by: Alex Vainman <alexv@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 6a053953739d23694474a5f9c81d1a30093da81a Mon Sep 17 00:00:00 2001
+From: Yishai Hadas <yishaih@mellanox.com>
+Date: Tue, 23 Jul 2019 09:57:25 +0300
+Subject: IB/mlx5: Fix unreg_umr to ignore the mkey state
+
+From: Yishai Hadas <yishaih@mellanox.com>
+
+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: <stable@vger.kernel.org> # 3.19
+Fixes: 968e78dd9644 ("IB/mlx5: Enhance UMR support to allow partial page table update")
+Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
+Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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) {
--- /dev/null
+From 9ec4483a3f0f71a228a5933bc040441322bfb090 Mon Sep 17 00:00:00 2001
+From: Yishai Hadas <yishaih@mellanox.com>
+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 <yishaih@mellanox.com>
+
+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: <stable@vger.kernel.org> # 3.10
+Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
+Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
+Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
--- /dev/null
+From afd1417404fba6dbfa6c0a8e5763bd348da682e4 Mon Sep 17 00:00:00 2001
+From: Yishai Hadas <yishaih@mellanox.com>
+Date: Tue, 23 Jul 2019 09:57:26 +0300
+Subject: IB/mlx5: Use direct mkey destroy command upon UMR unreg failure
+
+From: Yishai Hadas <yishaih@mellanox.com>
+
+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: <stable@vger.kernel.org> # 4.10
+Fixes: 49780d42dfc9 ("IB/mlx5: Expose MR cache for mlx5_ib")
+Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
+Reviewed-by: Artemy Kovalyov <artemyko@mellanox.com>
+Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
+Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 5241ab4cf42d3a93b933b55d3d53f43049081fa1 Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+Date: Mon, 29 Jul 2019 18:15:17 +0900
+Subject: kbuild: initialize CLANG_FLAGS correctly in the top Makefile
+
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+
+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: <stable@vger.kernel.org> # v5.0+
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
+Acked-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)/..)
--- /dev/null
+From 0c5b6c28ed68becb692b43eae5e44d5aa7e160ce Mon Sep 17 00:00:00 2001
+From: "M. Vefa Bicakci" <m.v.b@runbox.com>
+Date: Sat, 3 Aug 2019 06:02:12 -0400
+Subject: kconfig: Clear "written" flag to avoid data loss
+
+From: M. Vefa Bicakci <m.v.b@runbox.com>
+
+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 <stable@vger.kernel.org> # 4.19+
+Signed-off-by: M. Vefa Bicakci <m.v.b@runbox.com>
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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");
--- /dev/null
+From fa1e512fac717f34e7c12d7a384c46e90a647392 Mon Sep 17 00:00:00 2001
+From: Yang Shi <yang.shi@linux.alibaba.com>
+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 <yang.shi@linux.alibaba.com>
+
+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 <yang.shi@linux.alibaba.com>
+Reported-by: Shakeel Butt <shakeelb@google.com>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Jan Hadrava <had@kam.mff.cuni.cz>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Roman Gushchin <guro@fb.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Qian Cai <cai@lca.pw>
+Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: <stable@vger.kernel.org> [4.19+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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))
--- /dev/null
+From ba2d139b02ba684c6c101de42fed782d6cd2b997 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Mon, 8 Jul 2019 12:56:13 -0700
+Subject: mmc: dw_mmc: Fix occasional hang after tuning on eMMC
+
+From: Douglas Anderson <dianders@chromium.org>
+
+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 <dianders@chromium.org>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Alim Akhtar <alim.akhtar@gmail.com>
+Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 Mon Sep 17 00:00:00 2001
+From: Joe Perches <joe@perches.com>
+Date: Tue, 9 Jul 2019 22:04:19 -0700
+Subject: mmc: meson-mx-sdio: Fix misuse of GENMASK macro
+
+From: Joe Perches <joe@perches.com>
+
+commit 665e985c2f41bebc3e6cee7e04c36a44afbc58f7 upstream.
+
+Arguments are supposed to be ordered high then low.
+
+Signed-off-by: Joe Perches <joe@perches.com>
+Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
+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 <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/meson-mx-sdio.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/meson-mx-sdio.c
++++ b/drivers/mmc/host/meson-mx-sdio.c
+@@ -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)
--- /dev/null
+From 8493b2a06fc5b77ef5c579dc32b12761f7b7a84c Mon Sep 17 00:00:00 2001
+From: Marco Felsch <m.felsch@pengutronix.de>
+Date: Tue, 30 Jul 2019 15:44:07 +0200
+Subject: mtd: rawnand: micron: handle on-die "ECC-off" devices correctly
+
+From: Marco Felsch <m.felsch@pengutronix.de>
+
+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 <m.felsch@pengutronix.de>
+Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
+Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 2b5c8f0063e4b263cf2de82029798183cf85c320 Mon Sep 17 00:00:00 2001
+From: Munehisa Kamata <kamatam@amazon.com>
+Date: Wed, 31 Jul 2019 20:13:10 +0800
+Subject: nbd: replace kill_bdev() with __invalidate_device() again
+
+From: Munehisa Kamata <kamatam@amazon.com>
+
+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 <manoj.br@gmail.com>
+Cc: nbd@other.debian.org
+Cc: stable@vger.kernel.org
+Cc: David Woodhouse <dwmw@amazon.com>
+Reviewed-by: Josef Bacik <josef@toxicpanda.com>
+Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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))
--- /dev/null
+From 3fe6c873af2f2247544debdbe51ec29f690a2ccf Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Thu, 1 Aug 2019 13:33:39 +0200
+Subject: parisc: Fix build of compressed kernel even with debug enabled
+
+From: Helge Deller <deller@gmx.de>
+
+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 <svens@stackframe.org>
+Tested-by: Sven Schnelle <svens@stackframe.org>
+Cc: stable@vger.kernel.org # v4.14+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 41995342b40c418a47603e1321256d2c4a2ed0fb Mon Sep 17 00:00:00 2001
+From: Stefan Haberland <sth@linux.ibm.com>
+Date: Thu, 1 Aug 2019 13:06:30 +0200
+Subject: s390/dasd: fix endless loop after read unit address configuration
+
+From: Stefan Haberland <sth@linux.ibm.com>
+
+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 <sth@linux.ibm.com>
+Reviewed-by: Jan Hoeppner <hoeppner@linux.ibm.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 45385237f65aeee73641f1ef737d7273905a233f Mon Sep 17 00:00:00 2001
+From: Ondrej Mosnacek <omosnace@redhat.com>
+Date: Thu, 25 Jul 2019 12:52:43 +0200
+Subject: selinux: fix memory leak in policydb_init()
+
+From: Ondrej Mosnacek <omosnace@redhat.com>
+
+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: <stable@vger.kernel.org>
+Reported-by: syzbot+fee3a14d4cdf92646287@syzkaller.appspotmail.com
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
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
--- /dev/null
+From 50f6393f9654c561df4cdcf8e6cfba7260143601 Mon Sep 17 00:00:00 2001
+From: Juergen Gross <jgross@suse.com>
+Date: Fri, 14 Jun 2019 07:46:02 +0200
+Subject: xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
+
+From: Juergen Gross <jgross@suse.com>
+
+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 <jgross@suse.com>
+Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Reviewed-by: Jan Beulich <jbeulich@suse.com>
+Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
projects / thirdparty / kernel / stable-queue.git / commitdiff
