From 97a233da2613ab5d3569abaada3869dc80783181 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 5 Aug 2019 07:39:45 +0200 Subject: [PATCH] 4.9-stable patches added patches: btrfs-fix-incremental-send-failure-after-deduplication.patch drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.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 --- ...tal-send-failure-after-deduplication.patch | 180 ++++++++++++++++++ ..._pmu-fix-failure-path-in-pm-notifier.patch | 36 ++++ ...equesting-of-an-active-low-lineevent.patch | 70 +++++++ ...be-aligned-with-the-hw-specification.patch | 39 ++++ ..._flags-correctly-in-the-top-makefile.patch | 57 ++++++ ...occasional-hang-after-tuning-on-emmc.patch | 62 ++++++ ...fter-read-unit-address-configuration.patch | 73 +++++++ ...nux-fix-memory-leak-in-policydb_init.patch | 47 +++++ queue-4.9/series | 9 + ...alling-xen_destroy_contiguous_region.patch | 44 +++++ 10 files changed, 617 insertions(+) create mode 100644 queue-4.9/btrfs-fix-incremental-send-failure-after-deduplication.patch create mode 100644 queue-4.9/drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch create mode 100644 queue-4.9/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch create mode 100644 queue-4.9/ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch create mode 100644 queue-4.9/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch create mode 100644 queue-4.9/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch create mode 100644 queue-4.9/s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch create mode 100644 queue-4.9/selinux-fix-memory-leak-in-policydb_init.patch create mode 100644 queue-4.9/xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch diff --git a/queue-4.9/btrfs-fix-incremental-send-failure-after-deduplication.patch b/queue-4.9/btrfs-fix-incremental-send-failure-after-deduplication.patch new file mode 100644 index 00000000000..33ed0f78f41 --- /dev/null +++ b/queue-4.9/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 +@@ -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) diff --git a/queue-4.9/drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch b/queue-4.9/drivers-perf-arm_pmu-fix-failure-path-in-pm-notifier.patch new file mode 100644 index 00000000000..96bf77a1e41 --- /dev/null +++ b/queue-4.9/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 +@@ -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: diff --git a/queue-4.9/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch b/queue-4.9/gpiolib-fix-incorrect-irq-requesting-of-an-active-low-lineevent.patch new file mode 100644 index 00000000000..24dcab48048 --- /dev/null +++ b/queue-4.9/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 +@@ -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; + diff --git a/queue-4.9/ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch b/queue-4.9/ib-mlx5-fix-rss-toeplitz-setup-to-be-aligned-with-the-hw-specification.patch new file mode 100644 index 00000000000..3e1e36132dd --- /dev/null +++ b/queue-4.9/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 +@@ -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; + } diff --git a/queue-4.9/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch b/queue-4.9/kbuild-initialize-clang_flags-correctly-in-the-top-makefile.patch new file mode 100644 index 00000000000..0684213bb4a --- /dev/null +++ b/queue-4.9/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 +@@ -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)/..) diff --git a/queue-4.9/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch b/queue-4.9/mmc-dw_mmc-fix-occasional-hang-after-tuning-on-emmc.patch new file mode 100644 index 00000000000..abd7ad75a5e --- /dev/null +++ b/queue-4.9/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 +@@ -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; + } diff --git a/queue-4.9/s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch b/queue-4.9/s390-dasd-fix-endless-loop-after-read-unit-address-configuration.patch new file mode 100644 index 00000000000..f613cb762fa --- /dev/null +++ b/queue-4.9/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 +@@ -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); diff --git a/queue-4.9/selinux-fix-memory-leak-in-policydb_init.patch b/queue-4.9/selinux-fix-memory-leak-in-policydb_init.patch new file mode 100644 index 00000000000..3fb4ad11fe5 --- /dev/null +++ b/queue-4.9/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 +@@ -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; + } + diff --git a/queue-4.9/series b/queue-4.9/series index 94fd62831e7..a1cf112b95a 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -23,3 +23,12 @@ drivers-rapidio-devices-rio_mport_cdev.c-nul-termina.patch 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 diff --git a/queue-4.9/xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch b/queue-4.9/xen-swiotlb-fix-condition-for-calling-xen_destroy_contiguous_region.patch new file mode 100644 index 00000000000..ab0ba7c85c7 --- /dev/null +++ b/queue-4.9/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 +@@ -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); -- 2.47.3