--- /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
+@@ -5835,68 +5835,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 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
+@@ -804,8 +804,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
+@@ -817,9 +817,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 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
+@@ -1421,7 +1421,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 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
+@@ -400,6 +400,7 @@ KBUILD_AFLAGS_MODULE := -DMODULE
+ KBUILD_CFLAGS_MODULE := -DMODULE
+ KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds
+ GCC_PLUGINS_CFLAGS :=
++CLANG_FLAGS :=
+
+ # Read KERNELRELEASE from include/config/kernel.release (if it exists)
+ KERNELRELEASE = $(shell cat include/config/kernel.release 2> /dev/null)
+@@ -506,7 +507,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 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
+@@ -1864,8 +1864,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 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
+@@ -382,6 +382,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;
+@@ -446,12 +460,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
+@@ -266,6 +266,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.
+ */
+@@ -313,8 +315,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;
+ }
+
ipc-mqueue.c-only-perform-resource-calculation-if-us.patch
x86-kvm-don-t-call-kvm_spurious_fault-from-.fixup.patch
x86-boot-remove-multiple-copy-of-static-function-san.patch
+kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch
+btrfs-fix-incremental-send-failure-after-deduplication.patch
+mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch
+gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch
+selinux-fix-memory-leak-in-policydb_init.patch
+s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch
+drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch
+xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch
+ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.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
+@@ -365,8 +365,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
