From 36c05ec11a4435dfd70c4c8dbe145afd99d1bb37 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sun, 19 Jan 2020 16:45:16 +0100 Subject: [PATCH] 4.19-stable patches added patches: arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch btrfs-do-not-delete-mismatched-root-refs.patch btrfs-fix-invalid-removal-of-root-ref.patch btrfs-fix-memory-leak-in-qgroup-accounting.patch drm-i915-add-missing-include-file-linux-math64.h.patch mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch net-stmmac-enable-16kb-buffer-size.patch perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch usb-core-hub-improved-device-recognition-on-remote-wakeup.patch x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch x86-efistub-disable-paging-at-mixed-mode-entry.patch x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch x86-resctrl-fix-potential-memory-leak.patch --- ...mipi-use-1.5-version-of-i.core-mx6dl.patch | 45 ++++++++ ...libri-imx7s-256mb-nand-flash-support.patch | 31 ++++++ ...s-do-not-delete-mismatched-root-refs.patch | 45 ++++++++ ...trfs-fix-invalid-removal-of-root-ref.patch | 89 ++++++++++++++++ ...fix-memory-leak-in-qgroup-accounting.patch | 80 ++++++++++++++ ...-missing-include-file-linux-math64.h.patch | 39 +++++++ ...eue-only-if-memcg-workqueue-is-valid.patch | 85 +++++++++++++++ ...division-by-zero-in-wb_min_max_ratio.patch | 79 ++++++++++++++ ...47bit-hint-address-and-pmd-alignment.patch | 74 +++++++++++++ ...-16kb-buffer-must-be-16-byte-aligned.patch | 34 ++++++ .../net-stmmac-enable-16kb-buffer-size.patch | 34 ++++++ ...consistency-in-hists__for_each-macro.patch | 45 ++++++++ ...-dimensions-as-switch-perf-data-file.patch | 69 ++++++++++++ ...ective-credentials-in-ptrace_has_cap.patch | 100 ++++++++++++++++++ queue-4.19/series | 19 ++++ ...-device-recognition-on-remote-wakeup.patch | 65 ++++++++++++ ...ng-of-sme-sev-features-is-maintained.patch | 41 +++++++ ...b-disable-paging-at-mixed-mode-entry.patch | 46 ++++++++ ...ix-an-imbalance-in-domain_remove_cpu.patch | 75 +++++++++++++ ...86-resctrl-fix-potential-memory-leak.patch | 54 ++++++++++ 20 files changed, 1149 insertions(+) create mode 100644 queue-4.19/arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch create mode 100644 queue-4.19/arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch create mode 100644 queue-4.19/btrfs-do-not-delete-mismatched-root-refs.patch create mode 100644 queue-4.19/btrfs-fix-invalid-removal-of-root-ref.patch create mode 100644 queue-4.19/btrfs-fix-memory-leak-in-qgroup-accounting.patch create mode 100644 queue-4.19/drm-i915-add-missing-include-file-linux-math64.h.patch create mode 100644 queue-4.19/mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch create mode 100644 queue-4.19/mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch create mode 100644 queue-4.19/mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch create mode 100644 queue-4.19/net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch create mode 100644 queue-4.19/net-stmmac-enable-16kb-buffer-size.patch create mode 100644 queue-4.19/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch create mode 100644 queue-4.19/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch create mode 100644 queue-4.19/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch create mode 100644 queue-4.19/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch create mode 100644 queue-4.19/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch create mode 100644 queue-4.19/x86-efistub-disable-paging-at-mixed-mode-entry.patch create mode 100644 queue-4.19/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch create mode 100644 queue-4.19/x86-resctrl-fix-potential-memory-leak.patch diff --git a/queue-4.19/arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch b/queue-4.19/arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch new file mode 100644 index 00000000000..5cfeef751f7 --- /dev/null +++ b/queue-4.19/arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch @@ -0,0 +1,45 @@ +From 4a132f60808ae3a751e107a373f8572012352d3c Mon Sep 17 00:00:00 2001 +From: Jagan Teki +Date: Mon, 30 Dec 2019 17:30:19 +0530 +Subject: ARM: dts: imx6q-icore-mipi: Use 1.5 version of i.Core MX6DL + +From: Jagan Teki + +commit 4a132f60808ae3a751e107a373f8572012352d3c upstream. + +The EDIMM STARTER KIT i.Core 1.5 MIPI Evaluation is based on +the 1.5 version of the i.Core MX6 cpu module. The 1.5 version +differs from the original one for a few details, including the +ethernet PHY interface clock provider. + +With this commit, the ethernet interface works properly: +SMSC LAN8710/LAN8720 2188000.ethernet-1:00: attached PHY driver + +While before using the 1.5 version, ethernet failed to startup +do to un-clocked PHY interface: +fec 2188000.ethernet eth0: could not attach to PHY + +Similar fix has merged for i.Core MX6Q but missed to update for DL. + +Fixes: a8039f2dd089 ("ARM: dts: imx6dl: Add Engicam i.CoreM6 1.5 Quad/Dual MIPI starter kit support") +Cc: Jacopo Mondi +Signed-off-by: Michael Trimarchi +Signed-off-by: Jagan Teki +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/imx6dl-icore-mipi.dts | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/boot/dts/imx6dl-icore-mipi.dts ++++ b/arch/arm/boot/dts/imx6dl-icore-mipi.dts +@@ -8,7 +8,7 @@ + /dts-v1/; + + #include "imx6dl.dtsi" +-#include "imx6qdl-icore.dtsi" ++#include "imx6qdl-icore-1.5.dtsi" + + / { + model = "Engicam i.CoreM6 DualLite/Solo MIPI Starter Kit"; diff --git a/queue-4.19/arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch b/queue-4.19/arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch new file mode 100644 index 00000000000..9c33926ba69 --- /dev/null +++ b/queue-4.19/arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch @@ -0,0 +1,31 @@ +From 4b0b97e651ecf29f20248420b52b6864fbd40bc2 Mon Sep 17 00:00:00 2001 +From: Marcel Ziswiler +Date: Wed, 8 Jan 2020 17:12:31 +0100 +Subject: ARM: dts: imx7: Fix Toradex Colibri iMX7S 256MB NAND flash support + +From: Marcel Ziswiler + +commit 4b0b97e651ecf29f20248420b52b6864fbd40bc2 upstream. + +Turns out when introducing the eMMC version the gpmi node required for +NAND flash support got enabled exclusively on Colibri iMX7D 512MB. + +Fixes: f928a4a377e4 ("ARM: dts: imx7: add Toradex Colibri iMX7D 1GB (eMMC) support") +Signed-off-by: Marcel Ziswiler +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/imx7s-colibri.dtsi | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/arch/arm/boot/dts/imx7s-colibri.dtsi ++++ b/arch/arm/boot/dts/imx7s-colibri.dtsi +@@ -49,3 +49,7 @@ + reg = <0x80000000 0x10000000>; + }; + }; ++ ++&gpmi { ++ status = "okay"; ++}; diff --git a/queue-4.19/btrfs-do-not-delete-mismatched-root-refs.patch b/queue-4.19/btrfs-do-not-delete-mismatched-root-refs.patch new file mode 100644 index 00000000000..0879038a5e1 --- /dev/null +++ b/queue-4.19/btrfs-do-not-delete-mismatched-root-refs.patch @@ -0,0 +1,45 @@ +From 423a716cd7be16fb08690760691befe3be97d3fc Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 18 Dec 2019 17:20:29 -0500 +Subject: btrfs: do not delete mismatched root refs + +From: Josef Bacik + +commit 423a716cd7be16fb08690760691befe3be97d3fc upstream. + +btrfs_del_root_ref() will simply WARN_ON() if the ref doesn't match in +any way, and then continue to delete the reference. This shouldn't +happen, we have these values because there's more to the reference than +the original root and the sub root. If any of these checks fail, return +-ENOENT. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/root-tree.c | 10 ++++++---- + 1 file changed, 6 insertions(+), 4 deletions(-) + +--- a/fs/btrfs/root-tree.c ++++ b/fs/btrfs/root-tree.c +@@ -370,11 +370,13 @@ again: + leaf = path->nodes[0]; + ref = btrfs_item_ptr(leaf, path->slots[0], + struct btrfs_root_ref); +- +- WARN_ON(btrfs_root_ref_dirid(leaf, ref) != dirid); +- WARN_ON(btrfs_root_ref_name_len(leaf, ref) != name_len); + ptr = (unsigned long)(ref + 1); +- WARN_ON(memcmp_extent_buffer(leaf, name, ptr, name_len)); ++ if ((btrfs_root_ref_dirid(leaf, ref) != dirid) || ++ (btrfs_root_ref_name_len(leaf, ref) != name_len) || ++ memcmp_extent_buffer(leaf, name, ptr, name_len)) { ++ err = -ENOENT; ++ goto out; ++ } + *sequence = btrfs_root_ref_sequence(leaf, ref); + + ret = btrfs_del_item(trans, tree_root, path); diff --git a/queue-4.19/btrfs-fix-invalid-removal-of-root-ref.patch b/queue-4.19/btrfs-fix-invalid-removal-of-root-ref.patch new file mode 100644 index 00000000000..143142afd99 --- /dev/null +++ b/queue-4.19/btrfs-fix-invalid-removal-of-root-ref.patch @@ -0,0 +1,89 @@ +From d49d3287e74ffe55ae7430d1e795e5f9bf7359ea Mon Sep 17 00:00:00 2001 +From: Josef Bacik +Date: Wed, 18 Dec 2019 17:20:28 -0500 +Subject: btrfs: fix invalid removal of root ref + +From: Josef Bacik + +commit d49d3287e74ffe55ae7430d1e795e5f9bf7359ea upstream. + +If we have the following sequence of events + + btrfs sub create A + btrfs sub create A/B + btrfs sub snap A C + mkdir C/foo + mv A/B C/foo + rm -rf * + +We will end up with a transaction abort. + +The reason for this is because we create a root ref for B pointing to A. +When we create a snapshot of C we still have B in our tree, but because +the root ref points to A and not C we will make it appear to be empty. + +The problem happens when we move B into C. This removes the root ref +for B pointing to A and adds a ref of B pointing to C. When we rmdir C +we'll see that we have a ref to our root and remove the root ref, +despite not actually matching our reference name. + +Now btrfs_del_root_ref() allowing this to work is a bug as well, however +we know that this inode does not actually point to a root ref in the +first place, so we shouldn't be calling btrfs_del_root_ref() in the +first place and instead simply look up our dir index for this item and +do the rest of the removal. + +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Josef Bacik +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/inode.c | 27 +++++++++++++++++++-------- + 1 file changed, 19 insertions(+), 8 deletions(-) + +--- a/fs/btrfs/inode.c ++++ b/fs/btrfs/inode.c +@@ -4156,13 +4156,16 @@ static int btrfs_unlink_subvol(struct bt + } + btrfs_release_path(path); + +- ret = btrfs_del_root_ref(trans, objectid, root->root_key.objectid, +- dir_ino, &index, name, name_len); +- if (ret < 0) { +- if (ret != -ENOENT) { +- btrfs_abort_transaction(trans, ret); +- goto out; +- } ++ /* ++ * This is a placeholder inode for a subvolume we didn't have a ++ * reference to at the time of the snapshot creation. In the meantime ++ * we could have renamed the real subvol link into our snapshot, so ++ * depending on btrfs_del_root_ref to return -ENOENT here is incorret. ++ * Instead simply lookup the dir_index_item for this entry so we can ++ * remove it. Otherwise we know we have a ref to the root and we can ++ * call btrfs_del_root_ref, and it _shouldn't_ fail. ++ */ ++ if (btrfs_ino(inode) == BTRFS_EMPTY_SUBVOL_DIR_OBJECTID) { + di = btrfs_search_dir_index_item(root, path, dir_ino, + name, name_len); + if (IS_ERR_OR_NULL(di)) { +@@ -4177,8 +4180,16 @@ static int btrfs_unlink_subvol(struct bt + leaf = path->nodes[0]; + btrfs_item_key_to_cpu(leaf, &key, path->slots[0]); + index = key.offset; ++ btrfs_release_path(path); ++ } else { ++ ret = btrfs_del_root_ref(trans, objectid, ++ root->root_key.objectid, dir_ino, ++ &index, name, name_len); ++ if (ret) { ++ btrfs_abort_transaction(trans, ret); ++ goto out; ++ } + } +- btrfs_release_path(path); + + ret = btrfs_delete_delayed_dir_index(trans, BTRFS_I(dir), index); + if (ret) { diff --git a/queue-4.19/btrfs-fix-memory-leak-in-qgroup-accounting.patch b/queue-4.19/btrfs-fix-memory-leak-in-qgroup-accounting.patch new file mode 100644 index 00000000000..c278ba20e29 --- /dev/null +++ b/queue-4.19/btrfs-fix-memory-leak-in-qgroup-accounting.patch @@ -0,0 +1,80 @@ +From 26ef8493e1ab771cb01d27defca2fa1315dc3980 Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Wed, 8 Jan 2020 21:07:32 +0900 +Subject: btrfs: fix memory leak in qgroup accounting + +From: Johannes Thumshirn + +commit 26ef8493e1ab771cb01d27defca2fa1315dc3980 upstream. + +When running xfstests on the current btrfs I get the following splat from +kmemleak: + +unreferenced object 0xffff88821b2404e0 (size 32): + comm "kworker/u4:7", pid 26663, jiffies 4295283698 (age 8.776s) + hex dump (first 32 bytes): + 01 00 00 00 00 00 00 00 10 ff fd 26 82 88 ff ff ...........&.... + 10 ff fd 26 82 88 ff ff 20 ff fd 26 82 88 ff ff ...&.... ..&.... + backtrace: + [<00000000f94fd43f>] ulist_alloc+0x25/0x60 [btrfs] + [<00000000fd023d99>] btrfs_find_all_roots_safe+0x41/0x100 [btrfs] + [<000000008f17bd32>] btrfs_find_all_roots+0x52/0x70 [btrfs] + [<00000000b7660afb>] btrfs_qgroup_rescan_worker+0x343/0x680 [btrfs] + [<0000000058e66778>] btrfs_work_helper+0xac/0x1e0 [btrfs] + [<00000000f0188930>] process_one_work+0x1cf/0x350 + [<00000000af5f2f8e>] worker_thread+0x28/0x3c0 + [<00000000b55a1add>] kthread+0x109/0x120 + [<00000000f88cbd17>] ret_from_fork+0x35/0x40 + +This corresponds to: + + (gdb) l *(btrfs_find_all_roots_safe+0x41) + 0x8d7e1 is in btrfs_find_all_roots_safe (fs/btrfs/backref.c:1413). + 1408 + 1409 tmp = ulist_alloc(GFP_NOFS); + 1410 if (!tmp) + 1411 return -ENOMEM; + 1412 *roots = ulist_alloc(GFP_NOFS); + 1413 if (!*roots) { + 1414 ulist_free(tmp); + 1415 return -ENOMEM; + 1416 } + 1417 + +Following the lifetime of the allocated 'roots' ulist, it gets freed +again in btrfs_qgroup_account_extent(). + +But this does not happen if the function is called with the +'BTRFS_FS_QUOTA_ENABLED' flag cleared, then btrfs_qgroup_account_extent() +does a short leave and directly returns. + +Instead of directly returning we should jump to the 'out_free' in order to +free all resources as expected. + +CC: stable@vger.kernel.org # 4.14+ +Reviewed-by: Qu Wenruo +Signed-off-by: Johannes Thumshirn +[ add comment ] +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/qgroup.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/fs/btrfs/qgroup.c ++++ b/fs/btrfs/qgroup.c +@@ -2055,8 +2055,12 @@ int btrfs_qgroup_account_extent(struct b + u64 nr_old_roots = 0; + int ret = 0; + ++ /* ++ * If quotas get disabled meanwhile, the resouces need to be freed and ++ * we can't just exit here. ++ */ + if (!test_bit(BTRFS_FS_QUOTA_ENABLED, &fs_info->flags)) +- return 0; ++ goto out_free; + + if (new_roots) { + if (!maybe_fs_roots(new_roots)) diff --git a/queue-4.19/drm-i915-add-missing-include-file-linux-math64.h.patch b/queue-4.19/drm-i915-add-missing-include-file-linux-math64.h.patch new file mode 100644 index 00000000000..3aae3d0710e --- /dev/null +++ b/queue-4.19/drm-i915-add-missing-include-file-linux-math64.h.patch @@ -0,0 +1,39 @@ +From ea38aa2ea5b0969776f0a47f174ce928a22be803 Mon Sep 17 00:00:00 2001 +From: YueHaibing +Date: Tue, 7 Jan 2020 21:50:14 +0800 +Subject: drm/i915: Add missing include file + +From: YueHaibing + +commit ea38aa2ea5b0969776f0a47f174ce928a22be803 upstream. + +Fix build error: +./drivers/gpu/drm/i915/selftests/i915_random.h: In function i915_prandom_u32_max_state: +./drivers/gpu/drm/i915/selftests/i915_random.h:48:23: error: + implicit declaration of function mul_u32_u32; did you mean mul_u64_u32_div? [-Werror=implicit-function-declaration] + return upper_32_bits(mul_u32_u32(prandom_u32_state(state), ep_ro)); + +Reported-by: Hulk Robot +Fixes: 7ce5b6850b47 ("drm/i915/selftests: Use mul_u32_u32() for 32b x 32b -> 64b result") +Signed-off-by: YueHaibing +Reviewed-by: Chris Wilson +Signed-off-by: Chris Wilson +Link: https://patchwork.freedesktop.org/patch/msgid/20200107135014.36472-1-yuehaibing@huawei.com +(cherry picked from commit 62bf5465b26d1f502430b9c654be7d16bf2e242d) +Signed-off-by: Joonas Lahtinen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/selftests/i915_random.h | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpu/drm/i915/selftests/i915_random.h ++++ b/drivers/gpu/drm/i915/selftests/i915_random.h +@@ -25,6 +25,7 @@ + #ifndef __I915_SELFTESTS_RANDOM_H__ + #define __I915_SELFTESTS_RANDOM_H__ + ++#include + #include + + #include "../i915_selftest.h" diff --git a/queue-4.19/mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch b/queue-4.19/mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch new file mode 100644 index 00000000000..095530b10ee --- /dev/null +++ b/queue-4.19/mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch @@ -0,0 +1,85 @@ +From 2fe20210fc5f5e62644678b8f927c49f2c6f42a7 Mon Sep 17 00:00:00 2001 +From: Adrian Huang +Date: Mon, 13 Jan 2020 16:29:32 -0800 +Subject: mm: memcg/slab: call flush_memcg_workqueue() only if memcg workqueue is valid + +From: Adrian Huang + +commit 2fe20210fc5f5e62644678b8f927c49f2c6f42a7 upstream. + +When booting with amd_iommu=off, the following WARNING message +appears: + + AMD-Vi: AMD IOMMU disabled on kernel command-line + ------------[ cut here ]------------ + WARNING: CPU: 0 PID: 0 at kernel/workqueue.c:2772 flush_workqueue+0x42e/0x450 + Modules linked in: + CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.5.0-rc3-amd-iommu #6 + Hardware name: Lenovo ThinkSystem SR655-2S/7D2WRCZ000, BIOS D8E101L-1.00 12/05/2019 + RIP: 0010:flush_workqueue+0x42e/0x450 + Code: ff 0f 0b e9 7a fd ff ff 4d 89 ef e9 33 fe ff ff 0f 0b e9 7f fd ff ff 0f 0b e9 bc fd ff ff 0f 0b e9 a8 fd ff ff e8 52 2c fe ff <0f> 0b 31 d2 48 c7 c6 e0 88 c5 95 48 c7 c7 d8 ad f0 95 e8 19 f5 04 + Call Trace: + kmem_cache_destroy+0x69/0x260 + iommu_go_to_state+0x40c/0x5ab + amd_iommu_prepare+0x16/0x2a + irq_remapping_prepare+0x36/0x5f + enable_IR_x2apic+0x21/0x172 + default_setup_apic_routing+0x12/0x6f + apic_intr_mode_init+0x1a1/0x1f1 + x86_late_time_init+0x17/0x1c + start_kernel+0x480/0x53f + secondary_startup_64+0xb6/0xc0 + ---[ end trace 30894107c3749449 ]--- + x2apic: IRQ remapping doesn't support X2APIC mode + x2apic disabled + +The warning is caused by the calling of 'kmem_cache_destroy()' +in free_iommu_resources(). Here is the call path: + + free_iommu_resources + kmem_cache_destroy + flush_memcg_workqueue + flush_workqueue + +The root cause is that the IOMMU subsystem runs before the workqueue +subsystem, which the variable 'wq_online' is still 'false'. This leads +to the statement 'if (WARN_ON(!wq_online))' in flush_workqueue() is +'true'. + +Since the variable 'memcg_kmem_cache_wq' is not allocated during the +time, it is unnecessary to call flush_memcg_workqueue(). This prevents +the WARNING message triggered by flush_workqueue(). + +Link: http://lkml.kernel.org/r/20200103085503.1665-1-ahuang12@lenovo.com +Fixes: 92ee383f6daab ("mm: fix race between kmem_cache destroy, create and deactivate") +Signed-off-by: Adrian Huang +Reported-by: Xiaochun Lee +Reviewed-by: Shakeel Butt +Cc: Joerg Roedel +Cc: Christoph Lameter +Cc: Pekka Enberg +Cc: David Rientjes +Cc: Joonsoo Kim +Cc: Michal Hocko +Cc: Johannes Weiner +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/slab_common.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/mm/slab_common.c ++++ b/mm/slab_common.c +@@ -850,7 +850,8 @@ static void flush_memcg_workqueue(struct + * deactivates the memcg kmem_caches through workqueue. Make sure all + * previous workitems on workqueue are processed. + */ +- flush_workqueue(memcg_kmem_cache_wq); ++ if (likely(memcg_kmem_cache_wq)) ++ flush_workqueue(memcg_kmem_cache_wq); + } + #else + static inline int shutdown_memcg_caches(struct kmem_cache *s) diff --git a/queue-4.19/mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch b/queue-4.19/mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch new file mode 100644 index 00000000000..59b9a1b7e7b --- /dev/null +++ b/queue-4.19/mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch @@ -0,0 +1,79 @@ +From 6d9e8c651dd979aa666bee15f086745f3ea9c4b3 Mon Sep 17 00:00:00 2001 +From: Wen Yang +Date: Mon, 13 Jan 2020 16:29:23 -0800 +Subject: mm/page-writeback.c: avoid potential division by zero in wb_min_max_ratio() + +From: Wen Yang + +commit 6d9e8c651dd979aa666bee15f086745f3ea9c4b3 upstream. + +Patch series "use div64_ul() instead of div_u64() if the divisor is +unsigned long". + +We were first inspired by commit b0ab99e7736a ("sched: Fix possible divide +by zero in avg_atom () calculation"), then refer to the recently analyzed +mm code, we found this suspicious place. + + 201 if (min) { + 202 min *= this_bw; + 203 do_div(min, tot_bw); + 204 } + +And we also disassembled and confirmed it: + + /usr/src/debug/kernel-4.9.168-016.ali3000/linux-4.9.168-016.ali3000.alios7.x86_64/mm/page-writeback.c: 201 + 0xffffffff811c37da <__wb_calc_thresh+234>: xor %r10d,%r10d + 0xffffffff811c37dd <__wb_calc_thresh+237>: test %rax,%rax + 0xffffffff811c37e0 <__wb_calc_thresh+240>: je 0xffffffff811c3800 <__wb_calc_thresh+272> + /usr/src/debug/kernel-4.9.168-016.ali3000/linux-4.9.168-016.ali3000.alios7.x86_64/mm/page-writeback.c: 202 + 0xffffffff811c37e2 <__wb_calc_thresh+242>: imul %r8,%rax + /usr/src/debug/kernel-4.9.168-016.ali3000/linux-4.9.168-016.ali3000.alios7.x86_64/mm/page-writeback.c: 203 + 0xffffffff811c37e6 <__wb_calc_thresh+246>: mov %r9d,%r10d ---> truncates it to 32 bits here + 0xffffffff811c37e9 <__wb_calc_thresh+249>: xor %edx,%edx + 0xffffffff811c37eb <__wb_calc_thresh+251>: div %r10 + 0xffffffff811c37ee <__wb_calc_thresh+254>: imul %rbx,%rax + 0xffffffff811c37f2 <__wb_calc_thresh+258>: shr $0x2,%rax + 0xffffffff811c37f6 <__wb_calc_thresh+262>: mul %rcx + 0xffffffff811c37f9 <__wb_calc_thresh+265>: shr $0x2,%rdx + 0xffffffff811c37fd <__wb_calc_thresh+269>: mov %rdx,%r10 + +This series uses div64_ul() instead of div_u64() if the divisor is +unsigned long, to avoid truncation to 32-bit on 64-bit platforms. + +This patch (of 3): + +The variables 'min' and 'max' are unsigned long and do_div truncates +them to 32 bits, which means it can test non-zero and be truncated to +zero for division. Fix this issue by using div64_ul() instead. + +Link: http://lkml.kernel.org/r/20200102081442.8273-2-wenyang@linux.alibaba.com +Fixes: 693108a8a667 ("writeback: make bdi->min/max_ratio handling cgroup writeback aware") +Signed-off-by: Wen Yang +Reviewed-by: Andrew Morton +Cc: Qian Cai +Cc: Tejun Heo +Cc: Jens Axboe +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/page-writeback.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/mm/page-writeback.c ++++ b/mm/page-writeback.c +@@ -200,11 +200,11 @@ static void wb_min_max_ratio(struct bdi_ + if (this_bw < tot_bw) { + if (min) { + min *= this_bw; +- do_div(min, tot_bw); ++ min = div64_ul(min, tot_bw); + } + if (max < 100) { + max *= this_bw; +- do_div(max, tot_bw); ++ max = div64_ul(max, tot_bw); + } + } + diff --git a/queue-4.19/mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch b/queue-4.19/mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch new file mode 100644 index 00000000000..fda2b6fbe6a --- /dev/null +++ b/queue-4.19/mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch @@ -0,0 +1,74 @@ +From 991589974d9c9ecb24ee3799ec8c415c730598a2 Mon Sep 17 00:00:00 2001 +From: "Kirill A. Shutemov" +Date: Mon, 13 Jan 2020 16:29:13 -0800 +Subject: mm/shmem.c: thp, shmem: fix conflict of above-47bit hint address and PMD alignment + +From: Kirill A. Shutemov + +commit 991589974d9c9ecb24ee3799ec8c415c730598a2 upstream. + +Shmem/tmpfs tries to provide THP-friendly mappings if huge pages are +enabled. But it doesn't work well with above-47bit hint address. + +Normally, the kernel doesn't create userspace mappings above 47-bit, +even if the machine allows this (such as with 5-level paging on x86-64). +Not all user space is ready to handle wide addresses. It's known that +at least some JIT compilers use higher bits in pointers to encode their +information. + +Userspace can ask for allocation from full address space by specifying +hint address (with or without MAP_FIXED) above 47-bits. If the +application doesn't need a particular address, but wants to allocate +from whole address space it can specify -1 as a hint address. + +Unfortunately, this trick breaks THP alignment in shmem/tmp: +shmem_get_unmapped_area() would not try to allocate PMD-aligned area if +*any* hint address specified. + +This can be fixed by requesting the aligned area if the we failed to +allocated at user-specified hint address. The request with inflated +length will also take the user-specified hint address. This way we will +not lose an allocation request from the full address space. + +[kirill@shutemov.name: fold in a fixup] + Link: http://lkml.kernel.org/r/20191223231309.t6bh5hkbmokihpfu@box +Link: http://lkml.kernel.org/r/20191220142548.7118-3-kirill.shutemov@linux.intel.com +Fixes: b569bab78d8d ("x86/mm: Prepare to expose larger address space to userspace") +Signed-off-by: Kirill A. Shutemov +Cc: "Willhalm, Thomas" +Cc: Dan Williams +Cc: "Bruggeman, Otto G" +Cc: "Aneesh Kumar K . V" +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/shmem.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +--- a/mm/shmem.c ++++ b/mm/shmem.c +@@ -2072,9 +2072,10 @@ unsigned long shmem_get_unmapped_area(st + /* + * Our priority is to support MAP_SHARED mapped hugely; + * and support MAP_PRIVATE mapped hugely too, until it is COWed. +- * But if caller specified an address hint, respect that as before. ++ * But if caller specified an address hint and we allocated area there ++ * successfully, respect that as before. + */ +- if (uaddr) ++ if (uaddr == addr) + return addr; + + if (shmem_huge != SHMEM_HUGE_FORCE) { +@@ -2108,7 +2109,7 @@ unsigned long shmem_get_unmapped_area(st + if (inflated_len < len) + return addr; + +- inflated_addr = get_area(NULL, 0, inflated_len, 0, flags); ++ inflated_addr = get_area(NULL, uaddr, inflated_len, 0, flags); + if (IS_ERR_VALUE(inflated_addr)) + return addr; + if (inflated_addr & ~PAGE_MASK) diff --git a/queue-4.19/net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch b/queue-4.19/net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch new file mode 100644 index 00000000000..dd50c515da9 --- /dev/null +++ b/queue-4.19/net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch @@ -0,0 +1,34 @@ +From 8605131747e7e1fd8f6c9f97a00287aae2b2c640 Mon Sep 17 00:00:00 2001 +From: Jose Abreu +Date: Wed, 18 Dec 2019 11:17:41 +0100 +Subject: net: stmmac: 16KB buffer must be 16 byte aligned + +From: Jose Abreu + +commit 8605131747e7e1fd8f6c9f97a00287aae2b2c640 upstream. + +The 16KB RX Buffer must also be 16 byte aligned. Fix it. + +Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver") +Signed-off-by: Jose Abreu +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/stmicro/stmmac/common.h | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/common.h ++++ b/drivers/net/ethernet/stmicro/stmmac/common.h +@@ -363,9 +363,8 @@ struct dma_features { + unsigned int frpes; + }; + +-/* GMAC TX FIFO is 8K, Rx FIFO is 16K */ +-#define BUF_SIZE_16KiB 16384 +-/* RX Buffer size must be < 8191 and multiple of 4/8/16 bytes */ ++/* RX Buffer size must be multiple of 4/8/16 bytes */ ++#define BUF_SIZE_16KiB 16368 + #define BUF_SIZE_8KiB 8188 + #define BUF_SIZE_4KiB 4096 + #define BUF_SIZE_2KiB 2048 diff --git a/queue-4.19/net-stmmac-enable-16kb-buffer-size.patch b/queue-4.19/net-stmmac-enable-16kb-buffer-size.patch new file mode 100644 index 00000000000..15c81682148 --- /dev/null +++ b/queue-4.19/net-stmmac-enable-16kb-buffer-size.patch @@ -0,0 +1,34 @@ +From b2f3a481c4cd62f78391b836b64c0a6e72b503d2 Mon Sep 17 00:00:00 2001 +From: Jose Abreu +Date: Wed, 18 Dec 2019 11:17:42 +0100 +Subject: net: stmmac: Enable 16KB buffer size + +From: Jose Abreu + +commit b2f3a481c4cd62f78391b836b64c0a6e72b503d2 upstream. + +XGMAC supports maximum MTU that can go to 16KB. Lets add this check in +the calculation of RX buffer size. + +Fixes: 7ac6653a085b ("stmmac: Move the STMicroelectronics driver") +Signed-off-by: Jose Abreu +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c ++++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +@@ -1082,7 +1082,9 @@ static int stmmac_set_bfsize(int mtu, in + { + int ret = bufsize; + +- if (mtu >= BUF_SIZE_4KiB) ++ if (mtu >= BUF_SIZE_8KiB) ++ ret = BUF_SIZE_16KiB; ++ else if (mtu >= BUF_SIZE_4KiB) + ret = BUF_SIZE_8KiB; + else if (mtu >= BUF_SIZE_2KiB) + ret = BUF_SIZE_4KiB; diff --git a/queue-4.19/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch b/queue-4.19/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch new file mode 100644 index 00000000000..c5627bd7b45 --- /dev/null +++ b/queue-4.19/perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch @@ -0,0 +1,45 @@ +From 55347ec340af401437680fd0e88df6739a967f9f Mon Sep 17 00:00:00 2001 +From: Yuya Fujita +Date: Thu, 19 Dec 2019 08:08:32 +0000 +Subject: perf hists: Fix variable name's inconsistency in hists__for_each() macro + +From: Yuya Fujita + +commit 55347ec340af401437680fd0e88df6739a967f9f upstream. + +Variable names are inconsistent in hists__for_each macro(). + +Due to this inconsistency, the macro replaces its second argument with +"fmt" regardless of its original name. + +So far it works because only "fmt" is passed to the second argument. +However, this behavior is not expected and should be fixed. + +Fixes: f0786af536bb ("perf hists: Introduce hists__for_each_format macro") +Fixes: aa6f50af822a ("perf hists: Introduce hists__for_each_sort_list macro") +Signed-off-by: Yuya Fujita +Acked-by: Jiri Olsa +Cc: Peter Zijlstra +Link: http://lore.kernel.org/lkml/OSAPR01MB1588E1C47AC22043175DE1B2E8520@OSAPR01MB1588.jpnprd01.prod.outlook.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/util/hist.h | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/tools/perf/util/hist.h ++++ b/tools/perf/util/hist.h +@@ -324,10 +324,10 @@ static inline void perf_hpp__prepend_sor + list_for_each_entry_safe(format, tmp, &(_list)->sorts, sort_list) + + #define hists__for_each_format(hists, format) \ +- perf_hpp_list__for_each_format((hists)->hpp_list, fmt) ++ perf_hpp_list__for_each_format((hists)->hpp_list, format) + + #define hists__for_each_sort_list(hists, format) \ +- perf_hpp_list__for_each_sort_list((hists)->hpp_list, fmt) ++ perf_hpp_list__for_each_sort_list((hists)->hpp_list, format) + + extern struct perf_hpp_fmt perf_hpp__format[]; + diff --git a/queue-4.19/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch b/queue-4.19/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch new file mode 100644 index 00000000000..47f38bd99f4 --- /dev/null +++ b/queue-4.19/perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch @@ -0,0 +1,69 @@ +From 0feba17bd7ee3b7e03d141f119049dcc23efa94e Mon Sep 17 00:00:00 2001 +From: Jin Yao +Date: Fri, 20 Dec 2019 09:37:19 +0800 +Subject: perf report: Fix incorrectly added dimensions as switch perf data file + +From: Jin Yao + +commit 0feba17bd7ee3b7e03d141f119049dcc23efa94e upstream. + +We observed an issue that was some extra columns displayed after switching +perf data file in browser. The steps to reproduce: + +1. perf record -a -e cycles,instructions -- sleep 3 +2. perf report --group +3. In browser, we use hotkey 's' to switch to another perf.data +4. Now in browser, the extra columns 'Self' and 'Children' are displayed. + +The issue is setup_sorting() executed again after repeat path, so dimensions +are added again. + +This patch checks the last key returned from __cmd_report(). If it's +K_SWITCH_INPUT_DATA, skips the setup_sorting(). + +Fixes: ad0de0971b7f ("perf report: Enable the runtime switching of perf data file") +Signed-off-by: Jin Yao +Tested-by: Arnaldo Carvalho de Melo +Acked-by: Jiri Olsa +Cc: Alexander Shishkin +Cc: Andi Kleen +Cc: Feng Tang +Cc: Jin Yao +Cc: Kan Liang +Cc: Peter Zijlstra +Link: http://lore.kernel.org/lkml/20191220013722.20592-1-yao.jin@linux.intel.com +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/builtin-report.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/tools/perf/builtin-report.c ++++ b/tools/perf/builtin-report.c +@@ -961,6 +961,7 @@ int cmd_report(int argc, const char **ar + struct stat st; + bool has_br_stack = false; + int branch_mode = -1; ++ int last_key = 0; + bool branch_call_mode = false; + #define CALLCHAIN_DEFAULT_OPT "graph,0.5,caller,function,percent" + const char report_callchain_help[] = "Display call graph (stack chain/backtrace):\n\n" +@@ -1292,7 +1293,8 @@ repeat: + else + use_browser = 0; + +- if (setup_sorting(session->evlist) < 0) { ++ if ((last_key != K_SWITCH_INPUT_DATA) && ++ (setup_sorting(session->evlist) < 0)) { + if (sort_order) + parse_options_usage(report_usage, options, "s", 1); + if (field_order) +@@ -1390,6 +1392,7 @@ repeat: + ret = __cmd_report(&report); + if (ret == K_SWITCH_INPUT_DATA) { + perf_session__delete(session); ++ last_key = K_SWITCH_INPUT_DATA; + goto repeat; + } else + ret = 0; diff --git a/queue-4.19/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch b/queue-4.19/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch new file mode 100644 index 00000000000..1222ae4171e --- /dev/null +++ b/queue-4.19/ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch @@ -0,0 +1,100 @@ +From 6b3ad6649a4c75504edeba242d3fd36b3096a57f Mon Sep 17 00:00:00 2001 +From: Christian Brauner +Date: Wed, 15 Jan 2020 14:42:34 +0100 +Subject: ptrace: reintroduce usage of subjective credentials in ptrace_has_cap() + +From: Christian Brauner + +commit 6b3ad6649a4c75504edeba242d3fd36b3096a57f upstream. + +Commit 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat") +introduced the ability to opt out of audit messages for accesses to various +proc files since they are not violations of policy. While doing so it +somehow switched the check from ns_capable() to +has_ns_capability{_noaudit}(). That means it switched from checking the +subjective credentials of the task to using the objective credentials. This +is wrong since. ptrace_has_cap() is currently only used in +ptrace_may_access() And is used to check whether the calling task (subject) +has the CAP_SYS_PTRACE capability in the provided user namespace to operate +on the target task (object). According to the cred.h comments this would +mean the subjective credentials of the calling task need to be used. +This switches ptrace_has_cap() to use security_capable(). Because we only +call ptrace_has_cap() in ptrace_may_access() and in there we already have a +stable reference to the calling task's creds under rcu_read_lock() there's +no need to go through another series of dereferences and rcu locking done +in ns_capable{_noaudit}(). + +As one example where this might be particularly problematic, Jann pointed +out that in combination with the upcoming IORING_OP_OPENAT feature, this +bug might allow unprivileged users to bypass the capability checks while +asynchronously opening files like /proc/*/mem, because the capability +checks for this would be performed against kernel credentials. + +To illustrate on the former point about this being exploitable: When +io_uring creates a new context it records the subjective credentials of the +caller. Later on, when it starts to do work it creates a kernel thread and +registers a callback. The callback runs with kernel creds for +ktask->real_cred and ktask->cred. To prevent this from becoming a +full-blown 0-day io_uring will call override_cred() and override +ktask->cred with the subjective credentials of the creator of the io_uring +instance. With ptrace_has_cap() currently looking at ktask->real_cred this +override will be ineffective and the caller will be able to open arbitray +proc files as mentioned above. +Luckily, this is currently not exploitable but will turn into a 0-day once +IORING_OP_OPENAT{2} land in v5.6. Fix it now! + +Cc: Oleg Nesterov +Cc: Eric Paris +Cc: stable@vger.kernel.org +Reviewed-by: Kees Cook +Reviewed-by: Serge Hallyn +Reviewed-by: Jann Horn +Fixes: 69f594a38967 ("ptrace: do not audit capability check when outputing /proc/pid/stat") +Signed-off-by: Christian Brauner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/ptrace.c | 15 ++++++++++----- + 1 file changed, 10 insertions(+), 5 deletions(-) + +--- a/kernel/ptrace.c ++++ b/kernel/ptrace.c +@@ -258,12 +258,17 @@ static int ptrace_check_attach(struct ta + return ret; + } + +-static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode) ++static bool ptrace_has_cap(const struct cred *cred, struct user_namespace *ns, ++ unsigned int mode) + { ++ int ret; ++ + if (mode & PTRACE_MODE_NOAUDIT) +- return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE); ++ ret = security_capable(cred, ns, CAP_SYS_PTRACE, CAP_OPT_NOAUDIT); + else +- return has_ns_capability(current, ns, CAP_SYS_PTRACE); ++ ret = security_capable(cred, ns, CAP_SYS_PTRACE, CAP_OPT_NONE); ++ ++ return ret == 0; + } + + /* Returns 0 on success, -errno on denial. */ +@@ -315,7 +320,7 @@ static int __ptrace_may_access(struct ta + gid_eq(caller_gid, tcred->sgid) && + gid_eq(caller_gid, tcred->gid)) + goto ok; +- if (ptrace_has_cap(tcred->user_ns, mode)) ++ if (ptrace_has_cap(cred, tcred->user_ns, mode)) + goto ok; + rcu_read_unlock(); + return -EPERM; +@@ -334,7 +339,7 @@ ok: + mm = task->mm; + if (mm && + ((get_dumpable(mm) != SUID_DUMP_USER) && +- !ptrace_has_cap(mm->user_ns, mode))) ++ !ptrace_has_cap(cred, mm->user_ns, mode))) + return -EPERM; + + return security_ptrace_access_check(task, mode); diff --git a/queue-4.19/series b/queue-4.19/series index a52161862a4..a875029854d 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -27,3 +27,22 @@ arm64-dts-allwinner-a64-olinuxino-fix-sdio-supply-regulator.patch fix-built-in-early-load-intel-microcode-alignment.patch block-fix-an-integer-overflow-in-logical-block-size.patch arm-dts-am571x-idk-fix-gpios-property-to-have-the-correct-gpio-number.patch +ptrace-reintroduce-usage-of-subjective-credentials-in-ptrace_has_cap.patch +usb-core-hub-improved-device-recognition-on-remote-wakeup.patch +x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch +x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch +x86-efistub-disable-paging-at-mixed-mode-entry.patch +drm-i915-add-missing-include-file-linux-math64.h.patch +x86-resctrl-fix-potential-memory-leak.patch +perf-hists-fix-variable-name-s-inconsistency-in-hists__for_each-macro.patch +perf-report-fix-incorrectly-added-dimensions-as-switch-perf-data-file.patch +mm-shmem.c-thp-shmem-fix-conflict-of-above-47bit-hint-address-and-pmd-alignment.patch +mm-memcg-slab-call-flush_memcg_workqueue-only-if-memcg-workqueue-is-valid.patch +btrfs-fix-invalid-removal-of-root-ref.patch +btrfs-do-not-delete-mismatched-root-refs.patch +btrfs-fix-memory-leak-in-qgroup-accounting.patch +mm-page-writeback.c-avoid-potential-division-by-zero-in-wb_min_max_ratio.patch +arm-dts-imx6q-icore-mipi-use-1.5-version-of-i.core-mx6dl.patch +arm-dts-imx7-fix-toradex-colibri-imx7s-256mb-nand-flash-support.patch +net-stmmac-16kb-buffer-must-be-16-byte-aligned.patch +net-stmmac-enable-16kb-buffer-size.patch diff --git a/queue-4.19/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch b/queue-4.19/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch new file mode 100644 index 00000000000..4f07ac63200 --- /dev/null +++ b/queue-4.19/usb-core-hub-improved-device-recognition-on-remote-wakeup.patch @@ -0,0 +1,65 @@ +From 9c06ac4c83df6d6fbdbf7488fbad822b4002ba19 Mon Sep 17 00:00:00 2001 +From: Keiya Nobuta +Date: Thu, 9 Jan 2020 14:14:48 +0900 +Subject: usb: core: hub: Improved device recognition on remote wakeup + +From: Keiya Nobuta + +commit 9c06ac4c83df6d6fbdbf7488fbad822b4002ba19 upstream. + +If hub_activate() is called before D+ has stabilized after remote +wakeup, the following situation might occur: + + __ ___________________ + / \ / +D+ __/ \__/ + +Hub _______________________________ + | ^ ^ ^ + | | | | +Host _____v__|___|___________|______ + | | | | + | | | \-- Interrupt Transfer (*3) + | | \-- ClearPortFeature (*2) + | \-- GetPortStatus (*1) + \-- Host detects remote wakeup + +- D+ goes high, Host starts running by remote wakeup +- D+ is not stable, goes low +- Host requests GetPortStatus at (*1) and gets the following hub status: + - Current Connect Status bit is 0 + - Connect Status Change bit is 1 +- D+ stabilizes, goes high +- Host requests ClearPortFeature and thus Connect Status Change bit is + cleared at (*2) +- After waiting 100 ms, Host starts the Interrupt Transfer at (*3) +- Since the Connect Status Change bit is 0, Hub returns NAK. + +In this case, port_event() is not called in hub_event() and Host cannot +recognize device. To solve this issue, flag change_bits even if only +Connect Status Change bit is 1 when got in the first GetPortStatus. + +This issue occurs rarely because it only if D+ changes during a very +short time between GetPortStatus and ClearPortFeature. However, it is +fatal if it occurs in embedded system. + +Signed-off-by: Keiya Nobuta +Cc: stable +Acked-by: Alan Stern +Link: https://lore.kernel.org/r/20200109051448.28150-1-nobuta.keiya@fujitsu.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/hub.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -1165,6 +1165,7 @@ static void hub_activate(struct usb_hub + * PORT_OVER_CURRENT is not. So check for any of them. + */ + if (udev || (portstatus & USB_PORT_STAT_CONNECTION) || ++ (portchange & USB_PORT_STAT_C_CONNECTION) || + (portstatus & USB_PORT_STAT_OVERCURRENT) || + (portchange & USB_PORT_STAT_C_OVERCURRENT)) + set_bit(port1, hub->change_bits); diff --git a/queue-4.19/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch b/queue-4.19/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch new file mode 100644 index 00000000000..bc39eb8b4c7 --- /dev/null +++ b/queue-4.19/x86-cpu-amd-ensure-clearing-of-sme-sev-features-is-maintained.patch @@ -0,0 +1,41 @@ +From a006483b2f97af685f0e60f3a547c9ad4c9b9e94 Mon Sep 17 00:00:00 2001 +From: Tom Lendacky +Date: Wed, 15 Jan 2020 16:05:16 -0600 +Subject: x86/CPU/AMD: Ensure clearing of SME/SEV features is maintained + +From: Tom Lendacky + +commit a006483b2f97af685f0e60f3a547c9ad4c9b9e94 upstream. + +If the SME and SEV features are present via CPUID, but memory encryption +support is not enabled (MSR 0xC001_0010[23]), the feature flags are cleared +using clear_cpu_cap(). However, if get_cpu_cap() is later called, these +feature flags will be reset back to present, which is not desired. + +Change from using clear_cpu_cap() to setup_clear_cpu_cap() so that the +clearing of the flags is maintained. + +Signed-off-by: Tom Lendacky +Signed-off-by: Borislav Petkov +Cc: # 4.16.x- +Link: https://lkml.kernel.org/r/226de90a703c3c0be5a49565047905ac4e94e8f3.1579125915.git.thomas.lendacky@amd.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/amd.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -609,9 +609,9 @@ static void early_detect_mem_encrypt(str + return; + + clear_all: +- clear_cpu_cap(c, X86_FEATURE_SME); ++ setup_clear_cpu_cap(X86_FEATURE_SME); + clear_sev: +- clear_cpu_cap(c, X86_FEATURE_SEV); ++ setup_clear_cpu_cap(X86_FEATURE_SEV); + } + } + diff --git a/queue-4.19/x86-efistub-disable-paging-at-mixed-mode-entry.patch b/queue-4.19/x86-efistub-disable-paging-at-mixed-mode-entry.patch new file mode 100644 index 00000000000..83485f7e3e7 --- /dev/null +++ b/queue-4.19/x86-efistub-disable-paging-at-mixed-mode-entry.patch @@ -0,0 +1,46 @@ +From 4911ee401b7ceff8f38e0ac597cbf503d71e690c Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Tue, 24 Dec 2019 14:29:09 +0100 +Subject: x86/efistub: Disable paging at mixed mode entry + +From: Ard Biesheuvel + +commit 4911ee401b7ceff8f38e0ac597cbf503d71e690c upstream. + +The EFI mixed mode entry code goes through the ordinary startup_32() +routine before jumping into the kernel's EFI boot code in 64-bit +mode. The 32-bit startup code must be entered with paging disabled, +but this is not documented as a requirement for the EFI handover +protocol, and so we should disable paging explicitly when entering +the kernel from 32-bit EFI firmware. + +Signed-off-by: Ard Biesheuvel +Cc: +Cc: Arvind Sankar +Cc: Hans de Goede +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: linux-efi@vger.kernel.org +Link: https://lkml.kernel.org/r/20191224132909.102540-4-ardb@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/boot/compressed/head_64.S | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/arch/x86/boot/compressed/head_64.S ++++ b/arch/x86/boot/compressed/head_64.S +@@ -244,6 +244,11 @@ ENTRY(efi32_stub_entry) + leal efi32_config(%ebp), %eax + movl %eax, efi_config(%ebp) + ++ /* Disable paging */ ++ movl %cr0, %eax ++ btrl $X86_CR0_PG_BIT, %eax ++ movl %eax, %cr0 ++ + jmp startup_32 + ENDPROC(efi32_stub_entry) + #endif diff --git a/queue-4.19/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch b/queue-4.19/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch new file mode 100644 index 00000000000..ad735bbb53c --- /dev/null +++ b/queue-4.19/x86-resctrl-fix-an-imbalance-in-domain_remove_cpu.patch @@ -0,0 +1,75 @@ +From e278af89f1ba0a9ef20947db6afc2c9afa37e85b Mon Sep 17 00:00:00 2001 +From: Qian Cai +Date: Tue, 10 Dec 2019 22:30:42 -0500 +Subject: x86/resctrl: Fix an imbalance in domain_remove_cpu() + +From: Qian Cai + +commit e278af89f1ba0a9ef20947db6afc2c9afa37e85b upstream. + +A system that supports resource monitoring may have multiple resources +while not all of these resources are capable of monitoring. Monitoring +related state is initialized only for resources that are capable of +monitoring and correspondingly this state should subsequently only be +removed from these resources that are capable of monitoring. + +domain_add_cpu() calls domain_setup_mon_state() only when r->mon_capable +is true where it will initialize d->mbm_over. However, +domain_remove_cpu() calls cancel_delayed_work(&d->mbm_over) without +checking r->mon_capable resulting in an attempt to cancel d->mbm_over on +all resources, even those that never initialized d->mbm_over because +they are not capable of monitoring. Hence, it triggers a debugobjects +warning when offlining CPUs because those timer debugobjects are never +initialized: + + ODEBUG: assert_init not available (active state 0) object type: + timer_list hint: 0x0 + WARNING: CPU: 143 PID: 789 at lib/debugobjects.c:484 + debug_print_object + Hardware name: HP Synergy 680 Gen9/Synergy 680 Gen9 Compute Module, BIOS I40 05/23/2018 + RIP: 0010:debug_print_object + Call Trace: + debug_object_assert_init + del_timer + try_to_grab_pending + cancel_delayed_work + resctrl_offline_cpu + cpuhp_invoke_callback + cpuhp_thread_fun + smpboot_thread_fn + kthread + ret_from_fork + +Fixes: e33026831bdb ("x86/intel_rdt/mbm: Handle counter overflow") +Signed-off-by: Qian Cai +Signed-off-by: Borislav Petkov +Acked-by: Reinette Chatre +Cc: Fenghua Yu +Cc: "H. Peter Anvin" +Cc: Ingo Molnar +Cc: john.stultz@linaro.org +Cc: sboyd@kernel.org +Cc: +Cc: Thomas Gleixner +Cc: tj@kernel.org +Cc: Tony Luck +Cc: Vikas Shivappa +Cc: x86-ml +Link: https://lkml.kernel.org/r/20191211033042.2188-1-cai@lca.pw +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/intel_rdt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/intel_rdt.c ++++ b/arch/x86/kernel/cpu/intel_rdt.c +@@ -595,7 +595,7 @@ static void domain_remove_cpu(int cpu, s + if (static_branch_unlikely(&rdt_mon_enable_key)) + rmdir_mondata_subdir_allrdtgrp(r, d->id); + list_del(&d->list); +- if (is_mbm_enabled()) ++ if (r->mon_capable && is_mbm_enabled()) + cancel_delayed_work(&d->mbm_over); + if (is_llc_occupancy_enabled() && has_busy_rmid(r, d)) { + /* diff --git a/queue-4.19/x86-resctrl-fix-potential-memory-leak.patch b/queue-4.19/x86-resctrl-fix-potential-memory-leak.patch new file mode 100644 index 00000000000..02112f1fc5d --- /dev/null +++ b/queue-4.19/x86-resctrl-fix-potential-memory-leak.patch @@ -0,0 +1,54 @@ +From ab6a2114433a3b5b555983dcb9b752a85255f04b Mon Sep 17 00:00:00 2001 +From: Shakeel Butt +Date: Thu, 2 Jan 2020 08:58:44 -0800 +Subject: x86/resctrl: Fix potential memory leak + +From: Shakeel Butt + +commit ab6a2114433a3b5b555983dcb9b752a85255f04b upstream. + +set_cache_qos_cfg() is leaking memory when the given level is not +RDT_RESOURCE_L3 or RDT_RESOURCE_L2. At the moment, this function is +called with only valid levels but move the allocation after the valid +level checks in order to make it more robust and future proof. + + [ bp: Massage commit message. ] + +Fixes: 99adde9b370de ("x86/intel_rdt: Enable L2 CDP in MSR IA32_L2_QOS_CFG") +Signed-off-by: Shakeel Butt +Signed-off-by: Borislav Petkov +Cc: Fenghua Yu +Cc: "H. Peter Anvin" +Cc: Ingo Molnar +Cc: Reinette Chatre +Cc: Thomas Gleixner +Cc: x86-ml +Link: https://lkml.kernel.org/r/20200102165844.133133-1-shakeelb@google.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c ++++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +@@ -1749,9 +1749,6 @@ static int set_cache_qos_cfg(int level, + struct rdt_domain *d; + int cpu; + +- if (!zalloc_cpumask_var(&cpu_mask, GFP_KERNEL)) +- return -ENOMEM; +- + if (level == RDT_RESOURCE_L3) + update = l3_qos_cfg_update; + else if (level == RDT_RESOURCE_L2) +@@ -1759,6 +1756,9 @@ static int set_cache_qos_cfg(int level, + else + return -EINVAL; + ++ if (!zalloc_cpumask_var(&cpu_mask, GFP_KERNEL)) ++ return -ENOMEM; ++ + r_l = &rdt_resources_all[level]; + list_for_each_entry(d, &r_l->domains, list) { + /* Pick one CPU from each domain instance to update MSR */ -- 2.47.3