From a12d7650f72353721e101e29685a2432a89e1489 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 17 Feb 2020 20:20:54 +0100 Subject: [PATCH] 5.4-stable patches added patches: arm-npcm-bring-back-gpiolib-support.patch arm64-ssbs-fix-context-switch-when-ssbs-is-present-on-all-cpus.patch btrfs-fix-race-between-shrinking-truncate-and-fiemap.patch btrfs-fix-race-between-using-extent-maps-and-merging-them.patch btrfs-log-message-when-rw-remount-is-attempted-with-unclean-tree-log.patch btrfs-print-message-when-tree-log-replay-starts.patch btrfs-ref-verify-fix-memory-leaks.patch cifs-make-sure-we-do-not-overflow-the-max-ea-buffer-size.patch drm-panfrost-make-sure-the-shrinker-does-not-reclaim-referenced-bos.patch drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch edac-mc-fix-use-after-free-and-memleaks-during-device-removal.patch edac-sysfs-remove-csrow-objects-on-errors.patch ext4-add-cond_resched-to-ext4_protect_reserved_inode.patch ext4-don-t-assume-that-mmp_nodename-bdevname-have-nul.patch ext4-fix-checksum-errors-with-indexed-dirs.patch ext4-fix-support-for-inode-sizes-1024-bytes.patch ext4-improve-explanation-of-a-mount-failure-caused-by-a-misconfigured-kernel.patch gpio-xilinx-fix-bug-where-the-wrong-gpio-register-is-written-to.patch kvm-nvmx-use-correct-root-level-for-nested-ept-shadow-page-tables.patch perf-x86-amd-add-missing-l2-misses-event-spec-to-amd-family-17h-s-event-map.patch s390-pkey-fix-missing-length-of-protected-key-on-return.patch s390-uv-fix-handling-of-length-extensions.patch xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch --- .../arm-npcm-bring-back-gpiolib-support.patch | 35 +++++ ...tch-when-ssbs-is-present-on-all-cpus.patch | 46 ++++++ ...etween-shrinking-truncate-and-fiemap.patch | 112 ++++++++++++++ ...n-using-extent-maps-and-merging-them.patch | 128 ++++++++++++++++ ...t-is-attempted-with-unclean-tree-log.patch | 37 +++++ ...-message-when-tree-log-replay-starts.patch | 34 +++++ .../btrfs-ref-verify-fix-memory-leaks.patch | 66 ++++++++ ...-not-overflow-the-max-ea-buffer-size.patch | 77 ++++++++++ ...nker-does-not-reclaim-referenced-bos.patch | 82 ++++++++++ ...e-after-free-race-in-vgem_gem_create.patch | 72 +++++++++ ...e-and-memleaks-during-device-removal.patch | 144 ++++++++++++++++++ ...sysfs-remove-csrow-objects-on-errors.patch | 41 +++++ ...sched-to-ext4_protect_reserved_inode.patch | 64 ++++++++ ...-that-mmp_nodename-bdevname-have-nul.patch | 58 +++++++ ...ix-checksum-errors-with-indexed-dirs.patch | 125 +++++++++++++++ ...x-support-for-inode-sizes-1024-bytes.patch | 72 +++++++++ ...ure-caused-by-a-misconfigured-kernel.patch | 55 +++++++ ...he-wrong-gpio-register-is-written-to.patch | 48 ++++++ ...el-for-nested-ept-shadow-page-tables.patch | 37 +++++ ...t-spec-to-amd-family-17h-s-event-map.patch | 74 +++++++++ ...ng-length-of-protected-key-on-return.patch | 38 +++++ ...uv-fix-handling-of-length-extensions.patch | 39 +++++ queue-5.4/series | 23 +++ ...catter-gather-list-mapping-imbalance.patch | 67 ++++++++ 24 files changed, 1574 insertions(+) create mode 100644 queue-5.4/arm-npcm-bring-back-gpiolib-support.patch create mode 100644 queue-5.4/arm64-ssbs-fix-context-switch-when-ssbs-is-present-on-all-cpus.patch create mode 100644 queue-5.4/btrfs-fix-race-between-shrinking-truncate-and-fiemap.patch create mode 100644 queue-5.4/btrfs-fix-race-between-using-extent-maps-and-merging-them.patch create mode 100644 queue-5.4/btrfs-log-message-when-rw-remount-is-attempted-with-unclean-tree-log.patch create mode 100644 queue-5.4/btrfs-print-message-when-tree-log-replay-starts.patch create mode 100644 queue-5.4/btrfs-ref-verify-fix-memory-leaks.patch create mode 100644 queue-5.4/cifs-make-sure-we-do-not-overflow-the-max-ea-buffer-size.patch create mode 100644 queue-5.4/drm-panfrost-make-sure-the-shrinker-does-not-reclaim-referenced-bos.patch create mode 100644 queue-5.4/drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch create mode 100644 queue-5.4/edac-mc-fix-use-after-free-and-memleaks-during-device-removal.patch create mode 100644 queue-5.4/edac-sysfs-remove-csrow-objects-on-errors.patch create mode 100644 queue-5.4/ext4-add-cond_resched-to-ext4_protect_reserved_inode.patch create mode 100644 queue-5.4/ext4-don-t-assume-that-mmp_nodename-bdevname-have-nul.patch create mode 100644 queue-5.4/ext4-fix-checksum-errors-with-indexed-dirs.patch create mode 100644 queue-5.4/ext4-fix-support-for-inode-sizes-1024-bytes.patch create mode 100644 queue-5.4/ext4-improve-explanation-of-a-mount-failure-caused-by-a-misconfigured-kernel.patch create mode 100644 queue-5.4/gpio-xilinx-fix-bug-where-the-wrong-gpio-register-is-written-to.patch create mode 100644 queue-5.4/kvm-nvmx-use-correct-root-level-for-nested-ept-shadow-page-tables.patch create mode 100644 queue-5.4/perf-x86-amd-add-missing-l2-misses-event-spec-to-amd-family-17h-s-event-map.patch create mode 100644 queue-5.4/s390-pkey-fix-missing-length-of-protected-key-on-return.patch create mode 100644 queue-5.4/s390-uv-fix-handling-of-length-extensions.patch create mode 100644 queue-5.4/xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch diff --git a/queue-5.4/arm-npcm-bring-back-gpiolib-support.patch b/queue-5.4/arm-npcm-bring-back-gpiolib-support.patch new file mode 100644 index 00000000000..1cc32066c69 --- /dev/null +++ b/queue-5.4/arm-npcm-bring-back-gpiolib-support.patch @@ -0,0 +1,35 @@ +From e383e871ab54f073c2a798a9e0bde7f1d0528de8 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Thu, 30 Jan 2020 20:55:24 +0100 +Subject: ARM: npcm: Bring back GPIOLIB support + +From: Krzysztof Kozlowski + +commit e383e871ab54f073c2a798a9e0bde7f1d0528de8 upstream. + +The CONFIG_ARCH_REQUIRE_GPIOLIB is gone since commit 65053e1a7743 +("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB") and all platforms +should explicitly select GPIOLIB to have it. + +Link: https://lore.kernel.org/r/20200130195525.4525-1-krzk@kernel.org +Cc: +Fixes: 65053e1a7743 ("gpio: delete ARCH_[WANTS_OPTIONAL|REQUIRE]_GPIOLIB") +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Olof Johansson +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-npcm/Kconfig | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/mach-npcm/Kconfig ++++ b/arch/arm/mach-npcm/Kconfig +@@ -11,7 +11,7 @@ config ARCH_NPCM7XX + depends on ARCH_MULTI_V7 + select PINCTRL_NPCM7XX + select NPCM7XX_TIMER +- select ARCH_REQUIRE_GPIOLIB ++ select GPIOLIB + select CACHE_L2X0 + select ARM_GIC + select HAVE_ARM_TWD if SMP diff --git a/queue-5.4/arm64-ssbs-fix-context-switch-when-ssbs-is-present-on-all-cpus.patch b/queue-5.4/arm64-ssbs-fix-context-switch-when-ssbs-is-present-on-all-cpus.patch new file mode 100644 index 00000000000..b63ff3dab17 --- /dev/null +++ b/queue-5.4/arm64-ssbs-fix-context-switch-when-ssbs-is-present-on-all-cpus.patch @@ -0,0 +1,46 @@ +From fca3d33d8ad61eb53eca3ee4cac476d1e31b9008 Mon Sep 17 00:00:00 2001 +From: Will Deacon +Date: Thu, 6 Feb 2020 10:42:58 +0000 +Subject: arm64: ssbs: Fix context-switch when SSBS is present on all CPUs + +From: Will Deacon + +commit fca3d33d8ad61eb53eca3ee4cac476d1e31b9008 upstream. + +When all CPUs in the system implement the SSBS extension, the SSBS field +in PSTATE is the definitive indication of the mitigation state. Further, +when the CPUs implement the SSBS manipulation instructions (advertised +to userspace via an HWCAP), EL0 can toggle the SSBS field directly and +so we cannot rely on any shadow state such as TIF_SSBD at all. + +Avoid forcing the SSBS field in context-switch on such a system, and +simply rely on the PSTATE register instead. + +Cc: +Cc: Catalin Marinas +Cc: Srinivas Ramana +Fixes: cbdf8a189a66 ("arm64: Force SSBS on context switch") +Reviewed-by: Marc Zyngier +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm64/kernel/process.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/arch/arm64/kernel/process.c ++++ b/arch/arm64/kernel/process.c +@@ -466,6 +466,13 @@ static void ssbs_thread_switch(struct ta + if (unlikely(next->flags & PF_KTHREAD)) + return; + ++ /* ++ * If all CPUs implement the SSBS extension, then we just need to ++ * context-switch the PSTATE field. ++ */ ++ if (cpu_have_feature(cpu_feature(SSBS))) ++ return; ++ + /* If the mitigation is enabled, then we leave SSBS clear. */ + if ((arm64_get_ssbd_state() == ARM64_SSBD_FORCE_ENABLE) || + test_tsk_thread_flag(next, TIF_SSBD)) diff --git a/queue-5.4/btrfs-fix-race-between-shrinking-truncate-and-fiemap.patch b/queue-5.4/btrfs-fix-race-between-shrinking-truncate-and-fiemap.patch new file mode 100644 index 00000000000..6052e54382e --- /dev/null +++ b/queue-5.4/btrfs-fix-race-between-shrinking-truncate-and-fiemap.patch @@ -0,0 +1,112 @@ +From 28553fa992cb28be6a65566681aac6cafabb4f2d Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Fri, 7 Feb 2020 12:23:09 +0000 +Subject: Btrfs: fix race between shrinking truncate and fiemap + +From: Filipe Manana + +commit 28553fa992cb28be6a65566681aac6cafabb4f2d upstream. + +When there is a fiemap executing in parallel with a shrinking truncate +we can end up in a situation where we have extent maps for which we no +longer have corresponding file extent items. This is generally harmless +and at the moment the only consequences are missing file extent items +representing holes after we expand the file size again after the +truncate operation removed the prealloc extent items, and stale +information for future fiemap calls (reporting extents that no longer +exist or may have been reallocated to other files for example). + +Consider the following example: + +1) Our inode has a size of 128KiB, one 128KiB extent at file offset 0 + and a 1MiB prealloc extent at file offset 128KiB; + +2) Task A starts doing a shrinking truncate of our inode to reduce it to + a size of 64KiB. Before it searches the subvolume tree for file + extent items to delete, it drops all the extent maps in the range + from 64KiB to (u64)-1 by calling btrfs_drop_extent_cache(); + +3) Task B starts doing a fiemap against our inode. When looking up for + the inode's extent maps in the range from 128KiB to (u64)-1, it + doesn't find any in the inode's extent map tree, since they were + removed by task A. Because it didn't find any in the extent map + tree, it scans the inode's subvolume tree for file extent items, and + it finds the 1MiB prealloc extent at file offset 128KiB, then it + creates an extent map based on that file extent item and adds it to + inode's extent map tree (this ends up being done by + btrfs_get_extent() <- btrfs_get_extent_fiemap() <- + get_extent_skip_holes()); + +4) Task A then drops the prealloc extent at file offset 128KiB and + shrinks the 128KiB extent file offset 0 to a length of 64KiB. The + truncation operation finishes and we end up with an extent map + representing a 1MiB prealloc extent at file offset 128KiB, despite we + don't have any more that extent; + +After this the two types of problems we have are: + +1) Future calls to fiemap always report that a 1MiB prealloc extent + exists at file offset 128KiB. This is stale information, no longer + correct; + +2) If the size of the file is increased, by a truncate operation that + increases the file size or by a write into a file offset > 64KiB for + example, we end up not inserting file extent items to represent holes + for any range between 128KiB and 128KiB + 1MiB, since the hole + expansion function, btrfs_cont_expand() will skip hole insertion for + any range for which an extent map exists that represents a prealloc + extent. This causes fsck to complain about missing file extent items + when not using the NO_HOLES feature. + +The second issue could be often triggered by test case generic/561 from +fstests, which runs fsstress and duperemove in parallel, and duperemove +does frequent fiemap calls. + +Essentially the problems happens because fiemap does not acquire the +inode's lock while truncate does, and fiemap locks the file range in the +inode's iotree while truncate does not. So fix the issue by making +btrfs_truncate_inode_items() lock the file range from the new file size +to (u64)-1, so that it serializes with fiemap. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/inode.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -4663,6 +4663,8 @@ int btrfs_truncate_inode_items(struct bt + u64 bytes_deleted = 0; + bool be_nice = false; + bool should_throttle = false; ++ const u64 lock_start = ALIGN_DOWN(new_size, fs_info->sectorsize); ++ struct extent_state *cached_state = NULL; + + BUG_ON(new_size > 0 && min_type != BTRFS_EXTENT_DATA_KEY); + +@@ -4679,6 +4681,9 @@ int btrfs_truncate_inode_items(struct bt + return -ENOMEM; + path->reada = READA_BACK; + ++ lock_extent_bits(&BTRFS_I(inode)->io_tree, lock_start, (u64)-1, ++ &cached_state); ++ + /* + * We want to drop from the next block forward in case this new size is + * not block aligned since we will be keeping the last block of the +@@ -4945,6 +4950,9 @@ out: + btrfs_ordered_update_i_size(inode, last_size, NULL); + } + ++ unlock_extent_cached(&BTRFS_I(inode)->io_tree, lock_start, (u64)-1, ++ &cached_state); ++ + btrfs_free_path(path); + return ret; + } diff --git a/queue-5.4/btrfs-fix-race-between-using-extent-maps-and-merging-them.patch b/queue-5.4/btrfs-fix-race-between-using-extent-maps-and-merging-them.patch new file mode 100644 index 00000000000..ffbe04adb29 --- /dev/null +++ b/queue-5.4/btrfs-fix-race-between-using-extent-maps-and-merging-them.patch @@ -0,0 +1,128 @@ +From ac05ca913e9f3871126d61da275bfe8516ff01ca Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Fri, 31 Jan 2020 14:06:07 +0000 +Subject: Btrfs: fix race between using extent maps and merging them + +From: Filipe Manana + +commit ac05ca913e9f3871126d61da275bfe8516ff01ca upstream. + +We have a few cases where we allow an extent map that is in an extent map +tree to be merged with other extents in the tree. Such cases include the +unpinning of an extent after the respective ordered extent completed or +after logging an extent during a fast fsync. This can lead to subtle and +dangerous problems because when doing the merge some other task might be +using the same extent map and as consequence see an inconsistent state of +the extent map - for example sees the new length but has seen the old start +offset. + +With luck this triggers a BUG_ON(), and not some silent bug, such as the +following one in __do_readpage(): + + $ cat -n fs/btrfs/extent_io.c + 3061 static int __do_readpage(struct extent_io_tree *tree, + 3062 struct page *page, + (...) + 3127 em = __get_extent_map(inode, page, pg_offset, cur, + 3128 end - cur + 1, get_extent, em_cached); + 3129 if (IS_ERR_OR_NULL(em)) { + 3130 SetPageError(page); + 3131 unlock_extent(tree, cur, end); + 3132 break; + 3133 } + 3134 extent_offset = cur - em->start; + 3135 BUG_ON(extent_map_end(em) <= cur); + (...) + +Consider the following example scenario, where we end up hitting the +BUG_ON() in __do_readpage(). + +We have an inode with a size of 8KiB and 2 extent maps: + + extent A: file offset 0, length 4KiB, disk_bytenr = X, persisted on disk by + a previous transaction + + extent B: file offset 4KiB, length 4KiB, disk_bytenr = X + 4KiB, not yet + persisted but writeback started for it already. The extent map + is pinned since there's writeback and an ordered extent in + progress, so it can not be merged with extent map A yet + +The following sequence of steps leads to the BUG_ON(): + +1) The ordered extent for extent B completes, the respective page gets its + writeback bit cleared and the extent map is unpinned, at that point it + is not yet merged with extent map A because it's in the list of modified + extents; + +2) Due to memory pressure, or some other reason, the MM subsystem releases + the page corresponding to extent B - btrfs_releasepage() is called and + returns 1, meaning the page can be released as it's not dirty, not under + writeback anymore and the extent range is not locked in the inode's + iotree. However the extent map is not released, either because we are + not in a context that allows memory allocations to block or because the + inode's size is smaller than 16MiB - in this case our inode has a size + of 8KiB; + +3) Task B needs to read extent B and ends up __do_readpage() through the + btrfs_readpage() callback. At __do_readpage() it gets a reference to + extent map B; + +4) Task A, doing a fast fsync, calls clear_em_loggin() against extent map B + while holding the write lock on the inode's extent map tree - this + results in try_merge_map() being called and since it's possible to merge + extent map B with extent map A now (the extent map B was removed from + the list of modified extents), the merging begins - it sets extent map + B's start offset to 0 (was 4KiB), but before it increments the map's + length to 8KiB (4kb + 4KiB), task A is at: + + BUG_ON(extent_map_end(em) <= cur); + + The call to extent_map_end() sees the extent map has a start of 0 + and a length still at 4KiB, so it returns 4KiB and 'cur' is 4KiB, so + the BUG_ON() is triggered. + +So it's dangerous to modify an extent map that is in the tree, because some +other task might have got a reference to it before and still using it, and +needs to see a consistent map while using it. Generally this is very rare +since most paths that lookup and use extent maps also have the file range +locked in the inode's iotree. The fsync path is pretty much the only +exception where we don't do it to avoid serialization with concurrent +reads. + +Fix this by not allowing an extent map do be merged if if it's being used +by tasks other then the one attempting to merge the extent map (when the +reference count of the extent map is greater than 2). + +Reported-by: ryusuke1925 +Reported-by: Koki Mitani +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=206211 +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Josef Bacik +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/extent_map.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +--- a/fs/btrfs/extent_map.c ++++ b/fs/btrfs/extent_map.c +@@ -233,6 +233,17 @@ static void try_merge_map(struct extent_ + struct extent_map *merge = NULL; + struct rb_node *rb; + ++ /* ++ * We can't modify an extent map that is in the tree and that is being ++ * used by another task, as it can cause that other task to see it in ++ * inconsistent state during the merging. We always have 1 reference for ++ * the tree and 1 for this task (which is unpinning the extent map or ++ * clearing the logging flag), so anything > 2 means it's being used by ++ * other tasks too. ++ */ ++ if (refcount_read(&em->refs) > 2) ++ return; ++ + if (em->start != 0) { + rb = rb_prev(&em->rb_node); + if (rb) diff --git a/queue-5.4/btrfs-log-message-when-rw-remount-is-attempted-with-unclean-tree-log.patch b/queue-5.4/btrfs-log-message-when-rw-remount-is-attempted-with-unclean-tree-log.patch new file mode 100644 index 00000000000..2ad5e28f88c --- /dev/null +++ b/queue-5.4/btrfs-log-message-when-rw-remount-is-attempted-with-unclean-tree-log.patch @@ -0,0 +1,37 @@ +From 10a3a3edc5b89a8cd095bc63495fb1e0f42047d9 Mon Sep 17 00:00:00 2001 +From: David Sterba +Date: Wed, 5 Feb 2020 17:12:28 +0100 +Subject: btrfs: log message when rw remount is attempted with unclean tree-log + +From: David Sterba + +commit 10a3a3edc5b89a8cd095bc63495fb1e0f42047d9 upstream. + +A remount to a read-write filesystem is not safe when there's tree-log +to be replayed. Files that could be opened until now might be affected +by the changes in the tree-log. + +A regular mount is needed to replay the log so the filesystem presents +the consistent view with the pending changes included. + +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Anand Jain +Reviewed-by: Johannes Thumshirn +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/super.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/fs/btrfs/super.c ++++ b/fs/btrfs/super.c +@@ -1804,6 +1804,8 @@ static int btrfs_remount(struct super_bl + } + + if (btrfs_super_log_root(fs_info->super_copy) != 0) { ++ btrfs_warn(fs_info, ++ "mount required to replay tree-log, cannot remount read-write"); + ret = -EINVAL; + goto restore; + } diff --git a/queue-5.4/btrfs-print-message-when-tree-log-replay-starts.patch b/queue-5.4/btrfs-print-message-when-tree-log-replay-starts.patch new file mode 100644 index 00000000000..b883c17935f --- /dev/null +++ b/queue-5.4/btrfs-print-message-when-tree-log-replay-starts.patch @@ -0,0 +1,34 @@ +From e8294f2f6aa6208ed0923aa6d70cea3be178309a Mon Sep 17 00:00:00 2001 +From: David Sterba +Date: Wed, 5 Feb 2020 17:12:16 +0100 +Subject: btrfs: print message when tree-log replay starts + +From: David Sterba + +commit e8294f2f6aa6208ed0923aa6d70cea3be178309a upstream. + +There's no logged information about tree-log replay although this is +something that points to previous unclean unmount. Other filesystems +report that as well. + +Suggested-by: Chris Murphy +CC: stable@vger.kernel.org # 4.4+ +Reviewed-by: Anand Jain +Reviewed-by: Johannes Thumshirn +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/disk-io.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/btrfs/disk-io.c ++++ b/fs/btrfs/disk-io.c +@@ -3167,6 +3167,7 @@ retry_root_backup: + /* do not make disk changes in broken FS or nologreplay is given */ + if (btrfs_super_log_root(disk_super) != 0 && + !btrfs_test_opt(fs_info, NOLOGREPLAY)) { ++ btrfs_info(fs_info, "start tree-log replay"); + ret = btrfs_replay_log(fs_info, fs_devices); + if (ret) { + err = ret; diff --git a/queue-5.4/btrfs-ref-verify-fix-memory-leaks.patch b/queue-5.4/btrfs-ref-verify-fix-memory-leaks.patch new file mode 100644 index 00000000000..d56555c4f7c --- /dev/null +++ b/queue-5.4/btrfs-ref-verify-fix-memory-leaks.patch @@ -0,0 +1,66 @@ +From f311ade3a7adf31658ed882aaab9f9879fdccef7 Mon Sep 17 00:00:00 2001 +From: Wenwen Wang +Date: Sat, 1 Feb 2020 20:38:38 +0000 +Subject: btrfs: ref-verify: fix memory leaks + +From: Wenwen Wang + +commit f311ade3a7adf31658ed882aaab9f9879fdccef7 upstream. + +In btrfs_ref_tree_mod(), 'ref' and 'ra' are allocated through kzalloc() and +kmalloc(), respectively. In the following code, if an error occurs, the +execution will be redirected to 'out' or 'out_unlock' and the function will +be exited. However, on some of the paths, 'ref' and 'ra' are not +deallocated, leading to memory leaks. For example, if 'action' is +BTRFS_ADD_DELAYED_EXTENT, add_block_entry() will be invoked. If the return +value indicates an error, the execution will be redirected to 'out'. But, +'ref' is not deallocated on this path, causing a memory leak. + +To fix the above issues, deallocate both 'ref' and 'ra' before exiting from +the function when an error is encountered. + +CC: stable@vger.kernel.org # 4.15+ +Signed-off-by: Wenwen Wang +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/ref-verify.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/fs/btrfs/ref-verify.c ++++ b/fs/btrfs/ref-verify.c +@@ -744,6 +744,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i + */ + be = add_block_entry(fs_info, bytenr, num_bytes, ref_root); + if (IS_ERR(be)) { ++ kfree(ref); + kfree(ra); + ret = PTR_ERR(be); + goto out; +@@ -757,6 +758,8 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i + "re-allocated a block that still has references to it!"); + dump_block_entry(fs_info, be); + dump_ref_action(fs_info, ra); ++ kfree(ref); ++ kfree(ra); + goto out_unlock; + } + +@@ -819,6 +822,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i + "dropping a ref for a existing root that doesn't have a ref on the block"); + dump_block_entry(fs_info, be); + dump_ref_action(fs_info, ra); ++ kfree(ref); + kfree(ra); + goto out_unlock; + } +@@ -834,6 +838,7 @@ int btrfs_ref_tree_mod(struct btrfs_fs_i + "attempting to add another ref for an existing ref on a tree block"); + dump_block_entry(fs_info, be); + dump_ref_action(fs_info, ra); ++ kfree(ref); + kfree(ra); + goto out_unlock; + } diff --git a/queue-5.4/cifs-make-sure-we-do-not-overflow-the-max-ea-buffer-size.patch b/queue-5.4/cifs-make-sure-we-do-not-overflow-the-max-ea-buffer-size.patch new file mode 100644 index 00000000000..65e8c31178c --- /dev/null +++ b/queue-5.4/cifs-make-sure-we-do-not-overflow-the-max-ea-buffer-size.patch @@ -0,0 +1,77 @@ +From 85db6b7ae65f33be4bb44f1c28261a3faa126437 Mon Sep 17 00:00:00 2001 +From: Ronnie Sahlberg +Date: Thu, 13 Feb 2020 12:14:47 +1000 +Subject: cifs: make sure we do not overflow the max EA buffer size + +From: Ronnie Sahlberg + +commit 85db6b7ae65f33be4bb44f1c28261a3faa126437 upstream. + +RHBZ: 1752437 + +Before we add a new EA we should check that this will not overflow +the maximum buffer we have available to read the EAs back. +Otherwise we can get into a situation where the EAs are so big that +we can not read them back to the client and thus we can not list EAs +anymore or delete them. + +Signed-off-by: Ronnie Sahlberg +Signed-off-by: Steve French +CC: Stable +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cifs/smb2ops.c | 35 ++++++++++++++++++++++++++++++++++- + 1 file changed, 34 insertions(+), 1 deletion(-) + +--- a/fs/cifs/smb2ops.c ++++ b/fs/cifs/smb2ops.c +@@ -1087,7 +1087,8 @@ smb2_set_ea(const unsigned int xid, stru + void *data[1]; + struct smb2_file_full_ea_info *ea = NULL; + struct kvec close_iov[1]; +- int rc; ++ struct smb2_query_info_rsp *rsp; ++ int rc, used_len = 0; + + if (smb3_encryption_required(tcon)) + flags |= CIFS_TRANSFORM_REQ; +@@ -1110,6 +1111,38 @@ smb2_set_ea(const unsigned int xid, stru + cifs_sb); + if (rc == -ENODATA) + goto sea_exit; ++ } else { ++ /* If we are adding a attribute we should first check ++ * if there will be enough space available to store ++ * the new EA. If not we should not add it since we ++ * would not be able to even read the EAs back. ++ */ ++ rc = smb2_query_info_compound(xid, tcon, utf16_path, ++ FILE_READ_EA, ++ FILE_FULL_EA_INFORMATION, ++ SMB2_O_INFO_FILE, ++ CIFSMaxBufSize - ++ MAX_SMB2_CREATE_RESPONSE_SIZE - ++ MAX_SMB2_CLOSE_RESPONSE_SIZE, ++ &rsp_iov[1], &resp_buftype[1], cifs_sb); ++ if (rc == 0) { ++ rsp = (struct smb2_query_info_rsp *)rsp_iov[1].iov_base; ++ used_len = le32_to_cpu(rsp->OutputBufferLength); ++ } ++ free_rsp_buf(resp_buftype[1], rsp_iov[1].iov_base); ++ resp_buftype[1] = CIFS_NO_BUFFER; ++ memset(&rsp_iov[1], 0, sizeof(rsp_iov[1])); ++ rc = 0; ++ ++ /* Use a fudge factor of 256 bytes in case we collide ++ * with a different set_EAs command. ++ */ ++ if(CIFSMaxBufSize - MAX_SMB2_CREATE_RESPONSE_SIZE - ++ MAX_SMB2_CLOSE_RESPONSE_SIZE - 256 < ++ used_len + ea_name_len + ea_value_len + 1) { ++ rc = -ENOSPC; ++ goto sea_exit; ++ } + } + } + diff --git a/queue-5.4/drm-panfrost-make-sure-the-shrinker-does-not-reclaim-referenced-bos.patch b/queue-5.4/drm-panfrost-make-sure-the-shrinker-does-not-reclaim-referenced-bos.patch new file mode 100644 index 00000000000..69f4e975bc2 --- /dev/null +++ b/queue-5.4/drm-panfrost-make-sure-the-shrinker-does-not-reclaim-referenced-bos.patch @@ -0,0 +1,82 @@ +From 7e0cf7e9936c4358b0863357b90aa12afe6489da Mon Sep 17 00:00:00 2001 +From: Boris Brezillon +Date: Fri, 29 Nov 2019 14:59:08 +0100 +Subject: drm/panfrost: Make sure the shrinker does not reclaim referenced BOs + +From: Boris Brezillon + +commit 7e0cf7e9936c4358b0863357b90aa12afe6489da upstream. + +Userspace might tag a BO purgeable while it's still referenced by GPU +jobs. We need to make sure the shrinker does not purge such BOs until +all jobs referencing it are finished. + +Fixes: 013b65101315 ("drm/panfrost: Add madvise and shrinker support") +Cc: +Signed-off-by: Boris Brezillon +Reviewed-by: Steven Price +Signed-off-by: Rob Herring +Link: https://patchwork.freedesktop.org/patch/msgid/20191129135908.2439529-9-boris.brezillon@collabora.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/panfrost/panfrost_drv.c | 1 + + drivers/gpu/drm/panfrost/panfrost_gem.h | 6 ++++++ + drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c | 3 +++ + drivers/gpu/drm/panfrost/panfrost_job.c | 7 ++++++- + 4 files changed, 16 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/panfrost/panfrost_drv.c ++++ b/drivers/gpu/drm/panfrost/panfrost_drv.c +@@ -166,6 +166,7 @@ panfrost_lookup_bos(struct drm_device *d + break; + } + ++ atomic_inc(&bo->gpu_usecount); + job->mappings[i] = mapping; + } + +--- a/drivers/gpu/drm/panfrost/panfrost_gem.h ++++ b/drivers/gpu/drm/panfrost/panfrost_gem.h +@@ -30,6 +30,12 @@ struct panfrost_gem_object { + struct mutex lock; + } mappings; + ++ /* ++ * Count the number of jobs referencing this BO so we don't let the ++ * shrinker reclaim this object prematurely. ++ */ ++ atomic_t gpu_usecount; ++ + bool noexec :1; + bool is_heap :1; + }; +--- a/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c ++++ b/drivers/gpu/drm/panfrost/panfrost_gem_shrinker.c +@@ -41,6 +41,9 @@ static bool panfrost_gem_purge(struct dr + struct drm_gem_shmem_object *shmem = to_drm_gem_shmem_obj(obj); + struct panfrost_gem_object *bo = to_panfrost_bo(obj); + ++ if (atomic_read(&bo->gpu_usecount)) ++ return false; ++ + if (!mutex_trylock(&shmem->pages_lock)) + return false; + +--- a/drivers/gpu/drm/panfrost/panfrost_job.c ++++ b/drivers/gpu/drm/panfrost/panfrost_job.c +@@ -270,8 +270,13 @@ static void panfrost_job_cleanup(struct + dma_fence_put(job->render_done_fence); + + if (job->mappings) { +- for (i = 0; i < job->bo_count; i++) ++ for (i = 0; i < job->bo_count; i++) { ++ if (!job->mappings[i]) ++ break; ++ ++ atomic_dec(&job->mappings[i]->obj->gpu_usecount); + panfrost_gem_mapping_put(job->mappings[i]); ++ } + kvfree(job->mappings); + } + diff --git a/queue-5.4/drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch b/queue-5.4/drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch new file mode 100644 index 00000000000..301a30ebb37 --- /dev/null +++ b/queue-5.4/drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch @@ -0,0 +1,72 @@ +From 4b848f20eda5974020f043ca14bacf7a7e634fc8 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Sun, 2 Feb 2020 14:21:33 +0100 +Subject: drm/vgem: Close use-after-free race in vgem_gem_create + +From: Daniel Vetter + +commit 4b848f20eda5974020f043ca14bacf7a7e634fc8 upstream. + +There's two references floating around here (for the object reference, +not the handle_count reference, that's a different thing): + +- The temporary reference held by vgem_gem_create, acquired by + creating the object and released by calling + drm_gem_object_put_unlocked. + +- The reference held by the object handle, created by + drm_gem_handle_create. This one generally outlives the function, + except if a 2nd thread races with a GEM_CLOSE ioctl call. + +So usually everything is correct, except in that race case, where the +access to gem_object->size could be looking at freed data already. +Which again isn't a real problem (userspace shot its feet off already +with the race, we could return garbage), but maybe someone can exploit +this as an information leak. + +Cc: Dan Carpenter +Cc: Hillf Danton +Reported-by: syzbot+0dc4444774d419e916c8@syzkaller.appspotmail.com +Cc: stable@vger.kernel.org +Cc: Emil Velikov +Cc: Daniel Vetter +Cc: Sean Paul +Cc: Chris Wilson +Cc: Eric Anholt +Cc: Sam Ravnborg +Cc: Rob Clark +Reviewed-by: Chris Wilson +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20200202132133.1891846-1-daniel.vetter@ffwll.ch +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/vgem/vgem_drv.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/vgem/vgem_drv.c ++++ b/drivers/gpu/drm/vgem/vgem_drv.c +@@ -196,9 +196,10 @@ static struct drm_gem_object *vgem_gem_c + return ERR_CAST(obj); + + ret = drm_gem_handle_create(file, &obj->base, handle); +- drm_gem_object_put_unlocked(&obj->base); +- if (ret) ++ if (ret) { ++ drm_gem_object_put_unlocked(&obj->base); + return ERR_PTR(ret); ++ } + + return &obj->base; + } +@@ -221,7 +222,9 @@ static int vgem_gem_dumb_create(struct d + args->size = gem_object->size; + args->pitch = pitch; + +- DRM_DEBUG("Created object of size %lld\n", size); ++ drm_gem_object_put_unlocked(gem_object); ++ ++ DRM_DEBUG("Created object of size %llu\n", args->size); + + return 0; + } diff --git a/queue-5.4/edac-mc-fix-use-after-free-and-memleaks-during-device-removal.patch b/queue-5.4/edac-mc-fix-use-after-free-and-memleaks-during-device-removal.patch new file mode 100644 index 00000000000..13c7e126d4e --- /dev/null +++ b/queue-5.4/edac-mc-fix-use-after-free-and-memleaks-during-device-removal.patch @@ -0,0 +1,144 @@ +From 216aa145aaf379a50b17afc812db71d893bd6683 Mon Sep 17 00:00:00 2001 +From: Robert Richter +Date: Wed, 12 Feb 2020 18:25:18 +0100 +Subject: EDAC/mc: Fix use-after-free and memleaks during device removal + +From: Robert Richter + +commit 216aa145aaf379a50b17afc812db71d893bd6683 upstream. + +A test kernel with the options DEBUG_TEST_DRIVER_REMOVE, KASAN and +DEBUG_KMEMLEAK set, revealed several issues when removing an mci device: + +1) Use-after-free: + +On 27.11.19 17:07:33, John Garry wrote: +> [ 22.104498] BUG: KASAN: use-after-free in +> edac_remove_sysfs_mci_device+0x148/0x180 + +The use-after-free is caused by the mci_for_each_dimm() macro called in +edac_remove_sysfs_mci_device(). The iterator was introduced with + + c498afaf7df8 ("EDAC: Introduce an mci_for_each_dimm() iterator"). + +The iterator loop calls device_unregister(&dimm->dev), which removes +the sysfs entry of the device, but also frees the dimm struct in +dimm_attr_release(). When incrementing the loop in mci_for_each_dimm(), +the dimm struct is accessed again, after having been freed already. + +The fix is to free all the mci device's subsequent dimm and csrow +objects at a later point, in _edac_mc_free(), when the mci device itself +is being freed. + +This keeps the data structures intact and the mci device can be +fully used until its removal. The change allows the safe usage of +mci_for_each_dimm() to release dimm devices from sysfs. + +2) Memory leaks: + +Following memory leaks have been detected: + + # grep edac /sys/kernel/debug/kmemleak | sort | uniq -c + 1 [<000000003c0f58f9>] edac_mc_alloc+0x3bc/0x9d0 # mci->csrows + 16 [<00000000bb932dc0>] edac_mc_alloc+0x49c/0x9d0 # csr->channels + 16 [<00000000e2734dba>] edac_mc_alloc+0x518/0x9d0 # csr->channels[chn] + 1 [<00000000eb040168>] edac_mc_alloc+0x5c8/0x9d0 # mci->dimms + 34 [<00000000ef737c29>] ghes_edac_register+0x1c8/0x3f8 # see edac_mc_alloc() + +All leaks are from memory allocated by edac_mc_alloc(). + +Note: The test above shows that edac_mc_alloc() was called here from +ghes_edac_register(), thus both functions show up in the stack trace +but the module causing the leaks is edac_mc. The comments with the data +structures involved were made manually by analyzing the objdump. + +The data structures listed above and created by edac_mc_alloc() are +not properly removed during device removal, which is done in +edac_mc_free(). + +There are two paths implemented to remove the device depending on device +registration, _edac_mc_free() is called if the device is not registered +and edac_unregister_sysfs() otherwise. + +The implemenations differ. For the sysfs case, the mci device removal +lacks the removal of subsequent data structures (csrows, channels, +dimms). This causes the memory leaks (see mci_attr_release()). + + [ bp: Massage commit message. ] + +Fixes: c498afaf7df8 ("EDAC: Introduce an mci_for_each_dimm() iterator") +Fixes: faa2ad09c01c ("edac_mc: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs.") +Fixes: 7a623c039075 ("edac: rewrite the sysfs code to use struct device") +Reported-by: John Garry +Signed-off-by: Robert Richter +Signed-off-by: Borislav Petkov +Tested-by: John Garry +Cc: +Link: https://lkml.kernel.org/r/20200212120340.4764-3-rrichter@marvell.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/edac/edac_mc.c | 12 +++--------- + drivers/edac/edac_mc_sysfs.c | 15 +++------------ + 2 files changed, 6 insertions(+), 21 deletions(-) + +--- a/drivers/edac/edac_mc.c ++++ b/drivers/edac/edac_mc.c +@@ -503,16 +503,10 @@ void edac_mc_free(struct mem_ctl_info *m + { + edac_dbg(1, "\n"); + +- /* If we're not yet registered with sysfs free only what was allocated +- * in edac_mc_alloc(). +- */ +- if (!device_is_registered(&mci->dev)) { +- _edac_mc_free(mci); +- return; +- } ++ if (device_is_registered(&mci->dev)) ++ edac_unregister_sysfs(mci); + +- /* the mci instance is freed here, when the sysfs object is dropped */ +- edac_unregister_sysfs(mci); ++ _edac_mc_free(mci); + } + EXPORT_SYMBOL_GPL(edac_mc_free); + +--- a/drivers/edac/edac_mc_sysfs.c ++++ b/drivers/edac/edac_mc_sysfs.c +@@ -276,10 +276,7 @@ static const struct attribute_group *csr + + static void csrow_attr_release(struct device *dev) + { +- struct csrow_info *csrow = container_of(dev, struct csrow_info, dev); +- +- edac_dbg(1, "device %s released\n", dev_name(dev)); +- kfree(csrow); ++ /* release device with _edac_mc_free() */ + } + + static const struct device_type csrow_attr_type = { +@@ -619,10 +616,7 @@ static const struct attribute_group *dim + + static void dimm_attr_release(struct device *dev) + { +- struct dimm_info *dimm = container_of(dev, struct dimm_info, dev); +- +- edac_dbg(1, "device %s released\n", dev_name(dev)); +- kfree(dimm); ++ /* release device with _edac_mc_free() */ + } + + static const struct device_type dimm_attr_type = { +@@ -905,10 +899,7 @@ static const struct attribute_group *mci + + static void mci_attr_release(struct device *dev) + { +- struct mem_ctl_info *mci = container_of(dev, struct mem_ctl_info, dev); +- +- edac_dbg(1, "device %s released\n", dev_name(dev)); +- kfree(mci); ++ /* release device with _edac_mc_free() */ + } + + static const struct device_type mci_attr_type = { diff --git a/queue-5.4/edac-sysfs-remove-csrow-objects-on-errors.patch b/queue-5.4/edac-sysfs-remove-csrow-objects-on-errors.patch new file mode 100644 index 00000000000..bcd7ef962d8 --- /dev/null +++ b/queue-5.4/edac-sysfs-remove-csrow-objects-on-errors.patch @@ -0,0 +1,41 @@ +From 4d59588c09f2a2daedad2a544d4d1b602ab3a8af Mon Sep 17 00:00:00 2001 +From: Robert Richter +Date: Wed, 12 Feb 2020 13:03:39 +0100 +Subject: EDAC/sysfs: Remove csrow objects on errors + +From: Robert Richter + +commit 4d59588c09f2a2daedad2a544d4d1b602ab3a8af upstream. + +All created csrow objects must be removed in the error path of +edac_create_csrow_objects(). The objects have been added as devices. + +They need to be removed by doing a device_del() *and* put_device() call +to also free their memory. The missing put_device() leaves a memory +leak. Use device_unregister() instead of device_del() which properly +unregisters the device doing both. + +Fixes: 7adc05d2dc3a ("EDAC/sysfs: Drop device references properly") +Signed-off-by: Robert Richter +Signed-off-by: Borislav Petkov +Tested-by: John Garry +Cc: +Link: https://lkml.kernel.org/r/20200212120340.4764-4-rrichter@marvell.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/edac/edac_mc_sysfs.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/edac/edac_mc_sysfs.c ++++ b/drivers/edac/edac_mc_sysfs.c +@@ -447,8 +447,7 @@ error: + csrow = mci->csrows[i]; + if (!nr_pages_per_csrow(csrow)) + continue; +- +- device_del(&mci->csrows[i]->dev); ++ device_unregister(&mci->csrows[i]->dev); + } + + return err; diff --git a/queue-5.4/ext4-add-cond_resched-to-ext4_protect_reserved_inode.patch b/queue-5.4/ext4-add-cond_resched-to-ext4_protect_reserved_inode.patch new file mode 100644 index 00000000000..9473487daa1 --- /dev/null +++ b/queue-5.4/ext4-add-cond_resched-to-ext4_protect_reserved_inode.patch @@ -0,0 +1,64 @@ +From af133ade9a40794a37104ecbcc2827c0ea373a3c Mon Sep 17 00:00:00 2001 +From: Shijie Luo +Date: Mon, 10 Feb 2020 20:17:52 -0500 +Subject: ext4: add cond_resched() to ext4_protect_reserved_inode + +From: Shijie Luo + +commit af133ade9a40794a37104ecbcc2827c0ea373a3c upstream. + +When journal size is set too big by "mkfs.ext4 -J size=", or when +we mount a crafted image to make journal inode->i_size too big, +the loop, "while (i < num)", holds cpu too long. This could cause +soft lockup. + +[ 529.357541] Call trace: +[ 529.357551] dump_backtrace+0x0/0x198 +[ 529.357555] show_stack+0x24/0x30 +[ 529.357562] dump_stack+0xa4/0xcc +[ 529.357568] watchdog_timer_fn+0x300/0x3e8 +[ 529.357574] __hrtimer_run_queues+0x114/0x358 +[ 529.357576] hrtimer_interrupt+0x104/0x2d8 +[ 529.357580] arch_timer_handler_virt+0x38/0x58 +[ 529.357584] handle_percpu_devid_irq+0x90/0x248 +[ 529.357588] generic_handle_irq+0x34/0x50 +[ 529.357590] __handle_domain_irq+0x68/0xc0 +[ 529.357593] gic_handle_irq+0x6c/0x150 +[ 529.357595] el1_irq+0xb8/0x140 +[ 529.357599] __ll_sc_atomic_add_return_acquire+0x14/0x20 +[ 529.357668] ext4_map_blocks+0x64/0x5c0 [ext4] +[ 529.357693] ext4_setup_system_zone+0x330/0x458 [ext4] +[ 529.357717] ext4_fill_super+0x2170/0x2ba8 [ext4] +[ 529.357722] mount_bdev+0x1a8/0x1e8 +[ 529.357746] ext4_mount+0x44/0x58 [ext4] +[ 529.357748] mount_fs+0x50/0x170 +[ 529.357752] vfs_kern_mount.part.9+0x54/0x188 +[ 529.357755] do_mount+0x5ac/0xd78 +[ 529.357758] ksys_mount+0x9c/0x118 +[ 529.357760] __arm64_sys_mount+0x28/0x38 +[ 529.357764] el0_svc_common+0x78/0x130 +[ 529.357766] el0_svc_handler+0x38/0x78 +[ 529.357769] el0_svc+0x8/0xc +[ 541.356516] watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [mount:18674] + +Link: https://lore.kernel.org/r/20200211011752.29242-1-luoshijie1@huawei.com +Reviewed-by: Jan Kara +Signed-off-by: Shijie Luo +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/block_validity.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/ext4/block_validity.c ++++ b/fs/ext4/block_validity.c +@@ -203,6 +203,7 @@ static int ext4_protect_reserved_inode(s + return PTR_ERR(inode); + num = (inode->i_size + sb->s_blocksize - 1) >> sb->s_blocksize_bits; + while (i < num) { ++ cond_resched(); + map.m_lblk = i; + map.m_len = num - i; + n = ext4_map_blocks(NULL, inode, &map, 0); diff --git a/queue-5.4/ext4-don-t-assume-that-mmp_nodename-bdevname-have-nul.patch b/queue-5.4/ext4-don-t-assume-that-mmp_nodename-bdevname-have-nul.patch new file mode 100644 index 00000000000..931d990df6f --- /dev/null +++ b/queue-5.4/ext4-don-t-assume-that-mmp_nodename-bdevname-have-nul.patch @@ -0,0 +1,58 @@ +From 14c9ca0583eee8df285d68a0e6ec71053efd2228 Mon Sep 17 00:00:00 2001 +From: Andreas Dilger +Date: Sun, 26 Jan 2020 15:03:34 -0700 +Subject: ext4: don't assume that mmp_nodename/bdevname have NUL + +From: Andreas Dilger + +commit 14c9ca0583eee8df285d68a0e6ec71053efd2228 upstream. + +Don't assume that the mmp_nodename and mmp_bdevname strings are NUL +terminated, since they are filled in by snprintf(), which is not +guaranteed to do so. + +Link: https://lore.kernel.org/r/1580076215-1048-1-git-send-email-adilger@dilger.ca +Signed-off-by: Andreas Dilger +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/mmp.c | 12 +++++++----- + 1 file changed, 7 insertions(+), 5 deletions(-) + +--- a/fs/ext4/mmp.c ++++ b/fs/ext4/mmp.c +@@ -120,10 +120,10 @@ void __dump_mmp_msg(struct super_block * + { + __ext4_warning(sb, function, line, "%s", msg); + __ext4_warning(sb, function, line, +- "MMP failure info: last update time: %llu, last update " +- "node: %s, last update device: %s", +- (long long unsigned int) le64_to_cpu(mmp->mmp_time), +- mmp->mmp_nodename, mmp->mmp_bdevname); ++ "MMP failure info: last update time: %llu, last update node: %.*s, last update device: %.*s", ++ (unsigned long long)le64_to_cpu(mmp->mmp_time), ++ (int)sizeof(mmp->mmp_nodename), mmp->mmp_nodename, ++ (int)sizeof(mmp->mmp_bdevname), mmp->mmp_bdevname); + } + + /* +@@ -154,6 +154,7 @@ static int kmmpd(void *data) + mmp_check_interval = max(EXT4_MMP_CHECK_MULT * mmp_update_interval, + EXT4_MMP_MIN_CHECK_INTERVAL); + mmp->mmp_check_interval = cpu_to_le16(mmp_check_interval); ++ BUILD_BUG_ON(sizeof(mmp->mmp_bdevname) < BDEVNAME_SIZE); + bdevname(bh->b_bdev, mmp->mmp_bdevname); + + memcpy(mmp->mmp_nodename, init_utsname()->nodename, +@@ -375,7 +376,8 @@ skip: + /* + * Start a kernel thread to update the MMP block periodically. + */ +- EXT4_SB(sb)->s_mmp_tsk = kthread_run(kmmpd, mmpd_data, "kmmpd-%s", ++ EXT4_SB(sb)->s_mmp_tsk = kthread_run(kmmpd, mmpd_data, "kmmpd-%.*s", ++ (int)sizeof(mmp->mmp_bdevname), + bdevname(bh->b_bdev, + mmp->mmp_bdevname)); + if (IS_ERR(EXT4_SB(sb)->s_mmp_tsk)) { diff --git a/queue-5.4/ext4-fix-checksum-errors-with-indexed-dirs.patch b/queue-5.4/ext4-fix-checksum-errors-with-indexed-dirs.patch new file mode 100644 index 00000000000..6b5bf500286 --- /dev/null +++ b/queue-5.4/ext4-fix-checksum-errors-with-indexed-dirs.patch @@ -0,0 +1,125 @@ +From 48a34311953d921235f4d7bbd2111690d2e469cf Mon Sep 17 00:00:00 2001 +From: Jan Kara +Date: Mon, 10 Feb 2020 15:43:16 +0100 +Subject: ext4: fix checksum errors with indexed dirs + +From: Jan Kara + +commit 48a34311953d921235f4d7bbd2111690d2e469cf upstream. + +DIR_INDEX has been introduced as a compat ext4 feature. That means that +even kernels / tools that don't understand the feature may modify the +filesystem. This works because for kernels not understanding indexed dir +format, internal htree nodes appear just as empty directory entries. +Index dir aware kernels then check the htree structure is still +consistent before using the data. This all worked reasonably well until +metadata checksums were introduced. The problem is that these +effectively made DIR_INDEX only ro-compatible because internal htree +nodes store checksums in a different place than normal directory blocks. +Thus any modification ignorant to DIR_INDEX (or just clearing +EXT4_INDEX_FL from the inode) will effectively cause checksum mismatch +and trigger kernel errors. So we have to be more careful when dealing +with indexed directories on filesystems with checksumming enabled. + +1) We just disallow loading any directory inodes with EXT4_INDEX_FL when +DIR_INDEX is not enabled. This is harsh but it should be very rare (it +means someone disabled DIR_INDEX on existing filesystem and didn't run +e2fsck), e2fsck can fix the problem, and we don't want to answer the +difficult question: "Should we rather corrupt the directory more or +should we ignore that DIR_INDEX feature is not set?" + +2) When we find out htree structure is corrupted (but the filesystem and +the directory should in support htrees), we continue just ignoring htree +information for reading but we refuse to add new entries to the +directory to avoid corrupting it more. + +Link: https://lore.kernel.org/r/20200210144316.22081-1-jack@suse.cz +Fixes: dbe89444042a ("ext4: Calculate and verify checksums for htree nodes") +Reviewed-by: Andreas Dilger +Signed-off-by: Jan Kara +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/dir.c | 14 ++++++++------ + fs/ext4/ext4.h | 5 ++++- + fs/ext4/inode.c | 12 ++++++++++++ + fs/ext4/namei.c | 7 +++++++ + 4 files changed, 31 insertions(+), 7 deletions(-) + +--- a/fs/ext4/dir.c ++++ b/fs/ext4/dir.c +@@ -130,12 +130,14 @@ static int ext4_readdir(struct file *fil + if (err != ERR_BAD_DX_DIR) { + return err; + } +- /* +- * We don't set the inode dirty flag since it's not +- * critical that it get flushed back to the disk. +- */ +- ext4_clear_inode_flag(file_inode(file), +- EXT4_INODE_INDEX); ++ /* Can we just clear INDEX flag to ignore htree information? */ ++ if (!ext4_has_metadata_csum(sb)) { ++ /* ++ * We don't set the inode dirty flag since it's not ++ * critical that it gets flushed back to the disk. ++ */ ++ ext4_clear_inode_flag(inode, EXT4_INODE_INDEX); ++ } + } + + if (ext4_has_inline_data(inode)) { +--- a/fs/ext4/ext4.h ++++ b/fs/ext4/ext4.h +@@ -2476,8 +2476,11 @@ void ext4_insert_dentry(struct inode *in + struct ext4_filename *fname); + static inline void ext4_update_dx_flag(struct inode *inode) + { +- if (!ext4_has_feature_dir_index(inode->i_sb)) ++ if (!ext4_has_feature_dir_index(inode->i_sb)) { ++ /* ext4_iget() should have caught this... */ ++ WARN_ON_ONCE(ext4_has_feature_metadata_csum(inode->i_sb)); + ext4_clear_inode_flag(inode, EXT4_INODE_INDEX); ++ } + } + static const unsigned char ext4_filetype_table[] = { + DT_UNKNOWN, DT_REG, DT_DIR, DT_CHR, DT_BLK, DT_FIFO, DT_SOCK, DT_LNK +--- a/fs/ext4/inode.c ++++ b/fs/ext4/inode.c +@@ -4972,6 +4972,18 @@ struct inode *__ext4_iget(struct super_b + ret = -EFSCORRUPTED; + goto bad_inode; + } ++ /* ++ * If dir_index is not enabled but there's dir with INDEX flag set, ++ * we'd normally treat htree data as empty space. But with metadata ++ * checksumming that corrupts checksums so forbid that. ++ */ ++ if (!ext4_has_feature_dir_index(sb) && ext4_has_metadata_csum(sb) && ++ ext4_test_inode_flag(inode, EXT4_INODE_INDEX)) { ++ ext4_error_inode(inode, function, line, 0, ++ "iget: Dir with htree data on filesystem without dir_index feature."); ++ ret = -EFSCORRUPTED; ++ goto bad_inode; ++ } + ei->i_disksize = inode->i_size; + #ifdef CONFIG_QUOTA + ei->i_reserved_quota = 0; +--- a/fs/ext4/namei.c ++++ b/fs/ext4/namei.c +@@ -2205,6 +2205,13 @@ static int ext4_add_entry(handle_t *hand + retval = ext4_dx_add_entry(handle, &fname, dir, inode); + if (!retval || (retval != ERR_BAD_DX_DIR)) + goto out; ++ /* Can we just ignore htree data? */ ++ if (ext4_has_metadata_csum(sb)) { ++ EXT4_ERROR_INODE(dir, ++ "Directory has corrupted htree index."); ++ retval = -EFSCORRUPTED; ++ goto out; ++ } + ext4_clear_inode_flag(dir, EXT4_INODE_INDEX); + dx_fallback++; + ext4_mark_inode_dirty(handle, dir); diff --git a/queue-5.4/ext4-fix-support-for-inode-sizes-1024-bytes.patch b/queue-5.4/ext4-fix-support-for-inode-sizes-1024-bytes.patch new file mode 100644 index 00000000000..da5dc7f3f56 --- /dev/null +++ b/queue-5.4/ext4-fix-support-for-inode-sizes-1024-bytes.patch @@ -0,0 +1,72 @@ +From 4f97a68192bd33b9963b400759cef0ca5963af00 Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Thu, 6 Feb 2020 17:35:01 -0500 +Subject: ext4: fix support for inode sizes > 1024 bytes + +From: Theodore Ts'o + +commit 4f97a68192bd33b9963b400759cef0ca5963af00 upstream. + +A recent commit, 9803387c55f7 ("ext4: validate the +debug_want_extra_isize mount option at parse time"), moved mount-time +checks around. One of those changes moved the inode size check before +the blocksize variable was set to the blocksize of the file system. +After 9803387c55f7 was set to the minimum allowable blocksize, which +in practice on most systems would be 1024 bytes. This cuased file +systems with inode sizes larger than 1024 bytes to be rejected with a +message: + +EXT4-fs (sdXX): unsupported inode size: 4096 + +Fixes: 9803387c55f7 ("ext4: validate the debug_want_extra_isize mount option at parse time") +Link: https://lore.kernel.org/r/20200206225252.GA3673@mit.edu +Reported-by: Herbert Poetzl +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/super.c | 18 ++++++++++-------- + 1 file changed, 10 insertions(+), 8 deletions(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -3765,6 +3765,15 @@ static int ext4_fill_super(struct super_ + */ + sbi->s_li_wait_mult = EXT4_DEF_LI_WAIT_MULT; + ++ blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size); ++ if (blocksize < EXT4_MIN_BLOCK_SIZE || ++ blocksize > EXT4_MAX_BLOCK_SIZE) { ++ ext4_msg(sb, KERN_ERR, ++ "Unsupported filesystem blocksize %d (%d log_block_size)", ++ blocksize, le32_to_cpu(es->s_log_block_size)); ++ goto failed_mount; ++ } ++ + if (le32_to_cpu(es->s_rev_level) == EXT4_GOOD_OLD_REV) { + sbi->s_inode_size = EXT4_GOOD_OLD_INODE_SIZE; + sbi->s_first_ino = EXT4_GOOD_OLD_FIRST_INO; +@@ -3782,6 +3791,7 @@ static int ext4_fill_super(struct super_ + ext4_msg(sb, KERN_ERR, + "unsupported inode size: %d", + sbi->s_inode_size); ++ ext4_msg(sb, KERN_ERR, "blocksize: %d", blocksize); + goto failed_mount; + } + /* +@@ -3985,14 +3995,6 @@ static int ext4_fill_super(struct super_ + if (!ext4_feature_set_ok(sb, (sb_rdonly(sb)))) + goto failed_mount; + +- blocksize = BLOCK_SIZE << le32_to_cpu(es->s_log_block_size); +- if (blocksize < EXT4_MIN_BLOCK_SIZE || +- blocksize > EXT4_MAX_BLOCK_SIZE) { +- ext4_msg(sb, KERN_ERR, +- "Unsupported filesystem blocksize %d (%d log_block_size)", +- blocksize, le32_to_cpu(es->s_log_block_size)); +- goto failed_mount; +- } + if (le32_to_cpu(es->s_log_block_size) > + (EXT4_MAX_BLOCK_LOG_SIZE - EXT4_MIN_BLOCK_LOG_SIZE)) { + ext4_msg(sb, KERN_ERR, diff --git a/queue-5.4/ext4-improve-explanation-of-a-mount-failure-caused-by-a-misconfigured-kernel.patch b/queue-5.4/ext4-improve-explanation-of-a-mount-failure-caused-by-a-misconfigured-kernel.patch new file mode 100644 index 00000000000..ffbd7b73aab --- /dev/null +++ b/queue-5.4/ext4-improve-explanation-of-a-mount-failure-caused-by-a-misconfigured-kernel.patch @@ -0,0 +1,55 @@ +From d65d87a07476aa17df2dcb3ad18c22c154315bec Mon Sep 17 00:00:00 2001 +From: Theodore Ts'o +Date: Fri, 14 Feb 2020 18:11:19 -0500 +Subject: ext4: improve explanation of a mount failure caused by a misconfigured kernel + +From: Theodore Ts'o + +commit d65d87a07476aa17df2dcb3ad18c22c154315bec upstream. + +If CONFIG_QFMT_V2 is not enabled, but CONFIG_QUOTA is enabled, when a +user tries to mount a file system with the quota or project quota +enabled, the kernel will emit a very confusing messsage: + + EXT4-fs warning (device vdc): ext4_enable_quotas:5914: Failed to enable quota tracking (type=0, err=-3). Please run e2fsck to fix. + EXT4-fs (vdc): mount failed + +We will now report an explanatory message indicating which kernel +configuration options have to be enabled, to avoid customer/sysadmin +confusion. + +Link: https://lore.kernel.org/r/20200215012738.565735-1-tytso@mit.edu +Google-Bug-Id: 149093531 +Fixes: 7c319d328505b778 ("ext4: make quota as first class supported feature") +Signed-off-by: Theodore Ts'o +Cc: stable@kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + fs/ext4/super.c | 14 ++++---------- + 1 file changed, 4 insertions(+), 10 deletions(-) + +--- a/fs/ext4/super.c ++++ b/fs/ext4/super.c +@@ -2961,17 +2961,11 @@ static int ext4_feature_set_ok(struct su + return 0; + } + +-#ifndef CONFIG_QUOTA +- if (ext4_has_feature_quota(sb) && !readonly) { ++#if !defined(CONFIG_QUOTA) || !defined(CONFIG_QFMT_V2) ++ if (!readonly && (ext4_has_feature_quota(sb) || ++ ext4_has_feature_project(sb))) { + ext4_msg(sb, KERN_ERR, +- "Filesystem with quota feature cannot be mounted RDWR " +- "without CONFIG_QUOTA"); +- return 0; +- } +- if (ext4_has_feature_project(sb) && !readonly) { +- ext4_msg(sb, KERN_ERR, +- "Filesystem with project quota feature cannot be mounted RDWR " +- "without CONFIG_QUOTA"); ++ "The kernel was not built with CONFIG_QUOTA and CONFIG_QFMT_V2"); + return 0; + } + #endif /* CONFIG_QUOTA */ diff --git a/queue-5.4/gpio-xilinx-fix-bug-where-the-wrong-gpio-register-is-written-to.patch b/queue-5.4/gpio-xilinx-fix-bug-where-the-wrong-gpio-register-is-written-to.patch new file mode 100644 index 00000000000..43a24a78b80 --- /dev/null +++ b/queue-5.4/gpio-xilinx-fix-bug-where-the-wrong-gpio-register-is-written-to.patch @@ -0,0 +1,48 @@ +From c3afa804c58e5c30ac63858b527fffadc88bce82 Mon Sep 17 00:00:00 2001 +From: Paul Thomas +Date: Sat, 25 Jan 2020 17:14:10 -0500 +Subject: gpio: xilinx: Fix bug where the wrong GPIO register is written to + +From: Paul Thomas + +commit c3afa804c58e5c30ac63858b527fffadc88bce82 upstream. + +Care is taken with "index", however with the current version +the actual xgpio_writereg is using index for data but +xgpio_regoffset(chip, i) for the offset. And since i is already +incremented it is incorrect. This patch fixes it so that index +is used for the offset too. + +Cc: stable@vger.kernel.org +Signed-off-by: Paul Thomas +Link: https://lore.kernel.org/r/20200125221410.8022-1-pthomas8589@gmail.com +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpio/gpio-xilinx.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/gpio/gpio-xilinx.c ++++ b/drivers/gpio/gpio-xilinx.c +@@ -147,9 +147,10 @@ static void xgpio_set_multiple(struct gp + for (i = 0; i < gc->ngpio; i++) { + if (*mask == 0) + break; ++ /* Once finished with an index write it out to the register */ + if (index != xgpio_index(chip, i)) { + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET + +- xgpio_regoffset(chip, i), ++ index * XGPIO_CHANNEL_OFFSET, + chip->gpio_state[index]); + spin_unlock_irqrestore(&chip->gpio_lock[index], flags); + index = xgpio_index(chip, i); +@@ -165,7 +166,7 @@ static void xgpio_set_multiple(struct gp + } + + xgpio_writereg(chip->regs + XGPIO_DATA_OFFSET + +- xgpio_regoffset(chip, i), chip->gpio_state[index]); ++ index * XGPIO_CHANNEL_OFFSET, chip->gpio_state[index]); + + spin_unlock_irqrestore(&chip->gpio_lock[index], flags); + } diff --git a/queue-5.4/kvm-nvmx-use-correct-root-level-for-nested-ept-shadow-page-tables.patch b/queue-5.4/kvm-nvmx-use-correct-root-level-for-nested-ept-shadow-page-tables.patch new file mode 100644 index 00000000000..0ddae72332f --- /dev/null +++ b/queue-5.4/kvm-nvmx-use-correct-root-level-for-nested-ept-shadow-page-tables.patch @@ -0,0 +1,37 @@ +From 148d735eb55d32848c3379e460ce365f2c1cbe4b Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Fri, 7 Feb 2020 09:37:41 -0800 +Subject: KVM: nVMX: Use correct root level for nested EPT shadow page tables + +From: Sean Christopherson + +commit 148d735eb55d32848c3379e460ce365f2c1cbe4b upstream. + +Hardcode the EPT page-walk level for L2 to be 4 levels, as KVM's MMU +currently also hardcodes the page walk level for nested EPT to be 4 +levels. The L2 guest is all but guaranteed to soft hang on its first +instruction when L1 is using EPT, as KVM will construct 4-level page +tables and then tell hardware to use 5-level page tables. + +Fixes: 855feb673640 ("KVM: MMU: Add 5 level EPT & Shadow page table support.") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx/vmx.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/x86/kvm/vmx/vmx.c ++++ b/arch/x86/kvm/vmx/vmx.c +@@ -2975,6 +2975,9 @@ void vmx_set_cr0(struct kvm_vcpu *vcpu, + + static int get_ept_level(struct kvm_vcpu *vcpu) + { ++ /* Nested EPT currently only supports 4-level walks. */ ++ if (is_guest_mode(vcpu) && nested_cpu_has_ept(get_vmcs12(vcpu))) ++ return 4; + if (cpu_has_vmx_ept_5levels() && (cpuid_maxphyaddr(vcpu) > 48)) + return 5; + return 4; diff --git a/queue-5.4/perf-x86-amd-add-missing-l2-misses-event-spec-to-amd-family-17h-s-event-map.patch b/queue-5.4/perf-x86-amd-add-missing-l2-misses-event-spec-to-amd-family-17h-s-event-map.patch new file mode 100644 index 00000000000..bf7d6d1ef8e --- /dev/null +++ b/queue-5.4/perf-x86-amd-add-missing-l2-misses-event-spec-to-amd-family-17h-s-event-map.patch @@ -0,0 +1,74 @@ +From 25d387287cf0330abf2aad761ce6eee67326a355 Mon Sep 17 00:00:00 2001 +From: Kim Phillips +Date: Tue, 21 Jan 2020 11:12:31 -0600 +Subject: perf/x86/amd: Add missing L2 misses event spec to AMD Family 17h's event map + +From: Kim Phillips + +commit 25d387287cf0330abf2aad761ce6eee67326a355 upstream. + +Commit 3fe3331bb285 ("perf/x86/amd: Add event map for AMD Family 17h"), +claimed L2 misses were unsupported, due to them not being found in its +referenced documentation, whose link has now moved [1]. + +That old documentation listed PMCx064 unit mask bit 3 as: + + "LsRdBlkC: LS Read Block C S L X Change to X Miss." + +and bit 0 as: + + "IcFillMiss: IC Fill Miss" + +We now have new public documentation [2] with improved descriptions, that +clearly indicate what events those unit mask bits represent: + +Bit 3 now clearly states: + + "LsRdBlkC: Data Cache Req Miss in L2 (all types)" + +and bit 0 is: + + "IcFillMiss: Instruction Cache Req Miss in L2." + +So we can now add support for L2 misses in perf's genericised events as +PMCx064 with both the above unit masks. + +[1] The commit's original documentation reference, "Processor Programming + Reference (PPR) for AMD Family 17h Model 01h, Revision B1 Processors", + originally available here: + + https://www.amd.com/system/files/TechDocs/54945_PPR_Family_17h_Models_00h-0Fh.pdf + + is now available here: + + https://developer.amd.com/wordpress/media/2017/11/54945_PPR_Family_17h_Models_00h-0Fh.pdf + +[2] "Processor Programming Reference (PPR) for Family 17h Model 31h, + Revision B0 Processors", available here: + + https://developer.amd.com/wp-content/resources/55803_0.54-PUB.pdf + +Fixes: 3fe3331bb285 ("perf/x86/amd: Add event map for AMD Family 17h") +Reported-by: Babu Moger +Signed-off-by: Kim Phillips +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Ingo Molnar +Tested-by: Babu Moger +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20200121171232.28839-1-kim.phillips@amd.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/amd/core.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/events/amd/core.c ++++ b/arch/x86/events/amd/core.c +@@ -246,6 +246,7 @@ static const u64 amd_f17h_perfmon_event_ + [PERF_COUNT_HW_CPU_CYCLES] = 0x0076, + [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0, + [PERF_COUNT_HW_CACHE_REFERENCES] = 0xff60, ++ [PERF_COUNT_HW_CACHE_MISSES] = 0x0964, + [PERF_COUNT_HW_BRANCH_INSTRUCTIONS] = 0x00c2, + [PERF_COUNT_HW_BRANCH_MISSES] = 0x00c3, + [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = 0x0287, diff --git a/queue-5.4/s390-pkey-fix-missing-length-of-protected-key-on-return.patch b/queue-5.4/s390-pkey-fix-missing-length-of-protected-key-on-return.patch new file mode 100644 index 00000000000..8bf995b7777 --- /dev/null +++ b/queue-5.4/s390-pkey-fix-missing-length-of-protected-key-on-return.patch @@ -0,0 +1,38 @@ +From aab73d278d49c718b722ff5052e16c9cddf144d4 Mon Sep 17 00:00:00 2001 +From: Harald Freudenberger +Date: Fri, 31 Jan 2020 12:08:31 +0100 +Subject: s390/pkey: fix missing length of protected key on return + +From: Harald Freudenberger + +commit aab73d278d49c718b722ff5052e16c9cddf144d4 upstream. + +The pkey ioctl call PKEY_SEC2PROTK updates a struct pkey_protkey +on return. The protected key is stored in, the protected key type +is stored in but the len information was not updated. This patch +now fixes this and so the len field gets an update to refrect +the actual size of the protected key value returned. + +Fixes: efc598e6c8a9 ("s390/zcrypt: move cca misc functions to new code file") +Cc: Stable +Signed-off-by: Harald Freudenberger +Reported-by: Christian Rund +Suggested-by: Ingo Franzki +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/crypto/pkey_api.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/s390/crypto/pkey_api.c ++++ b/drivers/s390/crypto/pkey_api.c +@@ -794,7 +794,7 @@ static long pkey_unlocked_ioctl(struct f + return -EFAULT; + rc = cca_sec2protkey(ksp.cardnr, ksp.domain, + ksp.seckey.seckey, ksp.protkey.protkey, +- NULL, &ksp.protkey.type); ++ &ksp.protkey.len, &ksp.protkey.type); + DEBUG_DBG("%s cca_sec2protkey()=%d\n", __func__, rc); + if (rc) + break; diff --git a/queue-5.4/s390-uv-fix-handling-of-length-extensions.patch b/queue-5.4/s390-uv-fix-handling-of-length-extensions.patch new file mode 100644 index 00000000000..c39ca152eff --- /dev/null +++ b/queue-5.4/s390-uv-fix-handling-of-length-extensions.patch @@ -0,0 +1,39 @@ +From 27dc0700c3be7c681cea03c5230b93d02f623492 Mon Sep 17 00:00:00 2001 +From: Christian Borntraeger +Date: Mon, 10 Feb 2020 11:27:37 -0500 +Subject: s390/uv: Fix handling of length extensions + +From: Christian Borntraeger + +commit 27dc0700c3be7c681cea03c5230b93d02f623492 upstream. + +The query parameter block might contain additional information and can +be extended in the future. If the size of the block does not suffice we +get an error code of rc=0x100. The buffer will contain all information +up to the specified size and the hypervisor/guest simply do not need the +additional information as they do not know about the new data. That +means that we can (and must) accept rc=0x100 as success. + +Cc: stable@vger.kernel.org +Reviewed-by: Cornelia Huck +Fixes: 5abb9351dfd9 ("s390/uv: introduce guest side ultravisor code") +Signed-off-by: Christian Borntraeger +Signed-off-by: Vasily Gorbik +Signed-off-by: Greg Kroah-Hartman + +--- + arch/s390/boot/uv.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/s390/boot/uv.c ++++ b/arch/s390/boot/uv.c +@@ -15,7 +15,8 @@ void uv_query_info(void) + if (!test_facility(158)) + return; + +- if (uv_call(0, (uint64_t)&uvcb)) ++ /* rc==0x100 means that there is additional data we do not process */ ++ if (uv_call(0, (uint64_t)&uvcb) && uvcb.header.rc != 0x100) + return; + + if (test_bit_inv(BIT_UVC_CMD_SET_SHARED_ACCESS, (unsigned long *)uvcb.inst_calls_list) && diff --git a/queue-5.4/series b/queue-5.4/series index 1a0580eb369..569fd8f3134 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -11,3 +11,26 @@ acpica-introduce-acpi_any_gpe_status_set.patch acpi-pm-s2idle-prevent-spurious-scis-from-waking-up-the-system.patch alsa-usb-audio-sound-usb-usb-true-false-for-bool-return-type.patch alsa-usb-audio-add-clock-validity-quirk-for-denon-mc7000-mcx8000.patch +ext4-don-t-assume-that-mmp_nodename-bdevname-have-nul.patch +ext4-fix-support-for-inode-sizes-1024-bytes.patch +ext4-fix-checksum-errors-with-indexed-dirs.patch +ext4-add-cond_resched-to-ext4_protect_reserved_inode.patch +ext4-improve-explanation-of-a-mount-failure-caused-by-a-misconfigured-kernel.patch +btrfs-fix-race-between-using-extent-maps-and-merging-them.patch +btrfs-ref-verify-fix-memory-leaks.patch +btrfs-print-message-when-tree-log-replay-starts.patch +btrfs-log-message-when-rw-remount-is-attempted-with-unclean-tree-log.patch +btrfs-fix-race-between-shrinking-truncate-and-fiemap.patch +arm-npcm-bring-back-gpiolib-support.patch +gpio-xilinx-fix-bug-where-the-wrong-gpio-register-is-written-to.patch +arm64-ssbs-fix-context-switch-when-ssbs-is-present-on-all-cpus.patch +xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch +cifs-make-sure-we-do-not-overflow-the-max-ea-buffer-size.patch +edac-sysfs-remove-csrow-objects-on-errors.patch +edac-mc-fix-use-after-free-and-memleaks-during-device-removal.patch +kvm-nvmx-use-correct-root-level-for-nested-ept-shadow-page-tables.patch +perf-x86-amd-add-missing-l2-misses-event-spec-to-amd-family-17h-s-event-map.patch +s390-pkey-fix-missing-length-of-protected-key-on-return.patch +s390-uv-fix-handling-of-length-extensions.patch +drm-vgem-close-use-after-free-race-in-vgem_gem_create.patch +drm-panfrost-make-sure-the-shrinker-does-not-reclaim-referenced-bos.patch diff --git a/queue-5.4/xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch b/queue-5.4/xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch new file mode 100644 index 00000000000..556c24763c8 --- /dev/null +++ b/queue-5.4/xprtrdma-fix-dma-scatter-gather-list-mapping-imbalance.patch @@ -0,0 +1,67 @@ +From ca1c671302825182629d3c1a60363cee6f5455bb Mon Sep 17 00:00:00 2001 +From: Chuck Lever +Date: Wed, 12 Feb 2020 11:12:30 -0500 +Subject: xprtrdma: Fix DMA scatter-gather list mapping imbalance + +From: Chuck Lever + +commit ca1c671302825182629d3c1a60363cee6f5455bb upstream. + +The @nents value that was passed to ib_dma_map_sg() has to be passed +to the matching ib_dma_unmap_sg() call. If ib_dma_map_sg() choses to +concatenate sg entries, it will return a different nents value than +it was passed. + +The bug was exposed by recent changes to the AMD IOMMU driver, which +enabled sg entry concatenation. + +Looking all the way back to commit 4143f34e01e9 ("xprtrdma: Port to +new memory registration API") and reviewing other kernel ULPs, it's +not clear that the frwr_map() logic was ever correct for this case. + +Reported-by: Andre Tomt +Suggested-by: Robin Murphy +Signed-off-by: Chuck Lever +Cc: stable@vger.kernel.org +Reviewed-by: Jason Gunthorpe +Signed-off-by: Anna Schumaker +Signed-off-by: Greg Kroah-Hartman + +--- + net/sunrpc/xprtrdma/frwr_ops.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/net/sunrpc/xprtrdma/frwr_ops.c ++++ b/net/sunrpc/xprtrdma/frwr_ops.c +@@ -326,8 +326,8 @@ struct rpcrdma_mr_seg *frwr_map(struct r + { + struct rpcrdma_ia *ia = &r_xprt->rx_ia; + struct ib_reg_wr *reg_wr; ++ int i, n, dma_nents; + struct ib_mr *ibmr; +- int i, n; + u8 key; + + if (nsegs > ia->ri_max_frwr_depth) +@@ -351,15 +351,16 @@ struct rpcrdma_mr_seg *frwr_map(struct r + break; + } + mr->mr_dir = rpcrdma_data_dir(writing); ++ mr->mr_nents = i; + +- mr->mr_nents = +- ib_dma_map_sg(ia->ri_id->device, mr->mr_sg, i, mr->mr_dir); +- if (!mr->mr_nents) ++ dma_nents = ib_dma_map_sg(ia->ri_id->device, mr->mr_sg, mr->mr_nents, ++ mr->mr_dir); ++ if (!dma_nents) + goto out_dmamap_err; + + ibmr = mr->frwr.fr_mr; +- n = ib_map_mr_sg(ibmr, mr->mr_sg, mr->mr_nents, NULL, PAGE_SIZE); +- if (unlikely(n != mr->mr_nents)) ++ n = ib_map_mr_sg(ibmr, mr->mr_sg, dma_nents, NULL, PAGE_SIZE); ++ if (n != dma_nents) + goto out_mapmr_err; + + ibmr->iova &= 0x00000000ffffffff; -- 2.47.3