From: Greg Kroah-Hartman Date: Wed, 26 Feb 2020 10:58:02 +0000 (+0100) Subject: 5.5-stable patches X-Git-Tag: v4.4.215~60 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=601a29ceeb15e25d338ad46b17cabb7ea2165e00;p=thirdparty%2Fkernel%2Fstable-queue.git 5.5-stable patches added patches: drm-amdgpu-gfx10-disable-gfxoff-when-reading-rlc-clock.patch drm-amdgpu-gfx9-disable-gfxoff-when-reading-rlc-clock.patch drm-amdgpu-soc15-fix-xclk-for-raven.patch drm-i915-update-drm-i915-bug-filing-url.patch drm-i915-wean-off-drm_pci_alloc-drm_pci_free.patch drm-nouveau-kms-gv100-re-set-lut-after-clearing-for-modesets.patch lib-stackdepot.c-fix-global-out-of-bounds-in-stack_slabs.patch mm-avoid-creating-virtual-address-aliases-in-brk-mmap-mremap.patch mm-sparsemem-pfn_to_page-is-not-valid-yet-on-sparsemem.patch mm-vmscan.c-don-t-round-up-scan-size-for-online-memory-cgroup.patch --- diff --git a/queue-5.5/drm-amdgpu-gfx10-disable-gfxoff-when-reading-rlc-clock.patch b/queue-5.5/drm-amdgpu-gfx10-disable-gfxoff-when-reading-rlc-clock.patch new file mode 100644 index 00000000000..6c574625e87 --- /dev/null +++ b/queue-5.5/drm-amdgpu-gfx10-disable-gfxoff-when-reading-rlc-clock.patch @@ -0,0 +1,37 @@ +From b08c3ed609aabc4e76e74edc4404f0c26279d7ed Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 12 Feb 2020 08:52:32 -0500 +Subject: drm/amdgpu/gfx10: disable gfxoff when reading rlc clock + +From: Alex Deucher + +commit b08c3ed609aabc4e76e74edc4404f0c26279d7ed upstream. + +Otherwise we readback all ones. Fixes rlc counter +readback while gfxoff is active. + +Reviewed-by: Xiaojie Yuan +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c +@@ -3909,11 +3909,13 @@ static uint64_t gfx_v10_0_get_gpu_clock_ + { + uint64_t clock; + ++ amdgpu_gfx_off_ctrl(adev, false); + mutex_lock(&adev->gfx.gpu_clock_mutex); + WREG32_SOC15(GC, 0, mmRLC_CAPTURE_GPU_CLOCK_COUNT, 1); + clock = (uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_LSB) | + ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL); + mutex_unlock(&adev->gfx.gpu_clock_mutex); ++ amdgpu_gfx_off_ctrl(adev, true); + return clock; + } + diff --git a/queue-5.5/drm-amdgpu-gfx9-disable-gfxoff-when-reading-rlc-clock.patch b/queue-5.5/drm-amdgpu-gfx9-disable-gfxoff-when-reading-rlc-clock.patch new file mode 100644 index 00000000000..b4597258cea --- /dev/null +++ b/queue-5.5/drm-amdgpu-gfx9-disable-gfxoff-when-reading-rlc-clock.patch @@ -0,0 +1,39 @@ +From 120cf959308e1bda984e40a9edd25ee2d6262efd Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 12 Feb 2020 08:51:29 -0500 +Subject: drm/amdgpu/gfx9: disable gfxoff when reading rlc clock + +From: Alex Deucher + +commit 120cf959308e1bda984e40a9edd25ee2d6262efd upstream. + +Otherwise we readback all ones. Fixes rlc counter +readback while gfxoff is active. + +Reviewed-by: Xiaojie Yuan +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c ++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c +@@ -3852,6 +3852,7 @@ static uint64_t gfx_v9_0_get_gpu_clock_c + { + uint64_t clock; + ++ amdgpu_gfx_off_ctrl(adev, false); + mutex_lock(&adev->gfx.gpu_clock_mutex); + if (adev->asic_type == CHIP_VEGA10 && amdgpu_sriov_runtime(adev)) { + uint32_t tmp, lsb, msb, i = 0; +@@ -3870,6 +3871,7 @@ static uint64_t gfx_v9_0_get_gpu_clock_c + ((uint64_t)RREG32_SOC15(GC, 0, mmRLC_GPU_CLOCK_COUNT_MSB) << 32ULL); + } + mutex_unlock(&adev->gfx.gpu_clock_mutex); ++ amdgpu_gfx_off_ctrl(adev, true); + return clock; + } + diff --git a/queue-5.5/drm-amdgpu-soc15-fix-xclk-for-raven.patch b/queue-5.5/drm-amdgpu-soc15-fix-xclk-for-raven.patch new file mode 100644 index 00000000000..53a3d74ebdb --- /dev/null +++ b/queue-5.5/drm-amdgpu-soc15-fix-xclk-for-raven.patch @@ -0,0 +1,37 @@ +From c657b936ea98630ef5ba4f130ab1ad5c534d0165 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Wed, 12 Feb 2020 01:46:16 -0500 +Subject: drm/amdgpu/soc15: fix xclk for raven + +From: Alex Deucher + +commit c657b936ea98630ef5ba4f130ab1ad5c534d0165 upstream. + +It's 25 Mhz (refclk / 4). This fixes the interpretation +of the rlc clock counter. + +Acked-by: Evan Quan +Signed-off-by: Alex Deucher +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/amd/amdgpu/soc15.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/amdgpu/soc15.c ++++ b/drivers/gpu/drm/amd/amdgpu/soc15.c +@@ -270,7 +270,12 @@ static u32 soc15_get_config_memsize(stru + + static u32 soc15_get_xclk(struct amdgpu_device *adev) + { +- return adev->clock.spll.reference_freq; ++ u32 reference_clock = adev->clock.spll.reference_freq; ++ ++ if (adev->asic_type == CHIP_RAVEN) ++ return reference_clock / 4; ++ ++ return reference_clock; + } + + diff --git a/queue-5.5/drm-i915-update-drm-i915-bug-filing-url.patch b/queue-5.5/drm-i915-update-drm-i915-bug-filing-url.patch new file mode 100644 index 00000000000..6eb20dc36a0 --- /dev/null +++ b/queue-5.5/drm-i915-update-drm-i915-bug-filing-url.patch @@ -0,0 +1,65 @@ +From 7ddc7005a0aa2f43a826b71f5d6bd7d4b90f8f2a Mon Sep 17 00:00:00 2001 +From: Jani Nikula +Date: Wed, 12 Feb 2020 18:04:34 +0200 +Subject: drm/i915: Update drm/i915 bug filing URL + +From: Jani Nikula + +commit 7ddc7005a0aa2f43a826b71f5d6bd7d4b90f8f2a upstream. + +We've moved from bugzilla to gitlab. + +Cc: stable@vger.kernel.org +Reviewed-by: Chris Wilson +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/20200212160434.6437-2-jani.nikula@intel.com +(cherry picked from commit ddae4d7af0bbe3b2051f1603459a8b24e9a19324) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/Kconfig | 5 ++--- + drivers/gpu/drm/i915/i915_gpu_error.c | 3 ++- + drivers/gpu/drm/i915/i915_utils.c | 5 ++--- + 3 files changed, 6 insertions(+), 7 deletions(-) + +--- a/drivers/gpu/drm/i915/Kconfig ++++ b/drivers/gpu/drm/i915/Kconfig +@@ -75,9 +75,8 @@ config DRM_I915_CAPTURE_ERROR + help + This option enables capturing the GPU state when a hang is detected. + This information is vital for triaging hangs and assists in debugging. +- Please report any hang to +- https://bugs.freedesktop.org/enter_bug.cgi?product=DRI +- for triaging. ++ Please report any hang for triaging according to: ++ https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs + + If in doubt, say "Y". + +--- a/drivers/gpu/drm/i915/i915_gpu_error.c ++++ b/drivers/gpu/drm/i915/i915_gpu_error.c +@@ -1820,7 +1820,8 @@ void i915_capture_error_state(struct drm + if (!xchg(&warned, true) && + ktime_get_real_seconds() - DRIVER_TIMESTAMP < DAY_AS_SECONDS(180)) { + pr_info("GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.\n"); +- pr_info("Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel\n"); ++ pr_info("Please file a _new_ bug report at https://gitlab.freedesktop.org/drm/intel/issues/new.\n"); ++ pr_info("Please see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details.\n"); + pr_info("drm/i915 developers can then reassign to the right component if it's not a kernel issue.\n"); + pr_info("The GPU crash dump is required to analyze GPU hangs, so please always attach it.\n"); + pr_info("GPU crash dump saved to /sys/class/drm/card%d/error\n", +--- a/drivers/gpu/drm/i915/i915_utils.c ++++ b/drivers/gpu/drm/i915/i915_utils.c +@@ -8,9 +8,8 @@ + #include "i915_drv.h" + #include "i915_utils.h" + +-#define FDO_BUG_URL "https://bugs.freedesktop.org/enter_bug.cgi?product=DRI" +-#define FDO_BUG_MSG "Please file a bug at " FDO_BUG_URL " against DRM/Intel " \ +- "providing the dmesg log by booting with drm.debug=0xf" ++#define FDO_BUG_URL "https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs" ++#define FDO_BUG_MSG "Please file a bug on drm/i915; see " FDO_BUG_URL " for details." + + void + __i915_printk(struct drm_i915_private *dev_priv, const char *level, diff --git a/queue-5.5/drm-i915-wean-off-drm_pci_alloc-drm_pci_free.patch b/queue-5.5/drm-i915-wean-off-drm_pci_alloc-drm_pci_free.patch new file mode 100644 index 00000000000..fe54453dcaf --- /dev/null +++ b/queue-5.5/drm-i915-wean-off-drm_pci_alloc-drm_pci_free.patch @@ -0,0 +1,257 @@ +From aa3146193ae25d0fe4b96d815169a135db2e8f01 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Sun, 2 Feb 2020 15:39:34 +0000 +Subject: drm/i915: Wean off drm_pci_alloc/drm_pci_free + +From: Chris Wilson + +commit aa3146193ae25d0fe4b96d815169a135db2e8f01 upstream. + +drm_pci_alloc and drm_pci_free are just very thin wrappers around +dma_alloc_coherent, with a note that we should be removing them. +Furthermore since + +commit de09d31dd38a50fdce106c15abd68432eebbd014 +Author: Kirill A. Shutemov +Date: Fri Jan 15 16:51:42 2016 -0800 + + page-flags: define PG_reserved behavior on compound pages + + As far as I can see there's no users of PG_reserved on compound pages. + Let's use PF_NO_COMPOUND here. + +drm_pci_alloc has been declared broken since it mixes GFP_COMP and +SetPageReserved. Avoid this conflict by weaning ourselves off using the +abstraction and using the dma functions directly. + +Reported-by: Taketo Kabe +Closes: https://gitlab.freedesktop.org/drm/intel/issues/1027 +Fixes: de09d31dd38a ("page-flags: define PG_reserved behavior on compound pages") +Signed-off-by: Chris Wilson +Cc: # v4.5+ +Reviewed-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20200202153934.3899472-1-chris@chris-wilson.co.uk +(cherry picked from commit c6790dc22312f592c1434577258b31c48c72d52a) +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/display/intel_display.c | 2 + drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_phys.c | 98 +++++++++++------------ + drivers/gpu/drm/i915/i915_gem.c | 8 - + 4 files changed, 55 insertions(+), 56 deletions(-) + +--- a/drivers/gpu/drm/i915/display/intel_display.c ++++ b/drivers/gpu/drm/i915/display/intel_display.c +@@ -10731,7 +10731,7 @@ static u32 intel_cursor_base(const struc + u32 base; + + if (INTEL_INFO(dev_priv)->display.cursor_needs_physical) +- base = obj->phys_handle->busaddr; ++ base = sg_dma_address(obj->mm.pages->sgl); + else + base = intel_plane_ggtt_offset(plane_state); + +--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h ++++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h +@@ -260,9 +260,6 @@ struct drm_i915_gem_object { + + void *gvt_info; + }; +- +- /** for phys allocated objects */ +- struct drm_dma_handle *phys_handle; + }; + + static inline struct drm_i915_gem_object * +--- a/drivers/gpu/drm/i915/gem/i915_gem_phys.c ++++ b/drivers/gpu/drm/i915/gem/i915_gem_phys.c +@@ -22,88 +22,87 @@ + static int i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj) + { + struct address_space *mapping = obj->base.filp->f_mapping; +- struct drm_dma_handle *phys; +- struct sg_table *st; + struct scatterlist *sg; +- char *vaddr; ++ struct sg_table *st; ++ dma_addr_t dma; ++ void *vaddr; ++ void *dst; + int i; +- int err; + + if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj))) + return -EINVAL; + +- /* Always aligning to the object size, allows a single allocation ++ /* ++ * Always aligning to the object size, allows a single allocation + * to handle all possible callers, and given typical object sizes, + * the alignment of the buddy allocation will naturally match. + */ +- phys = drm_pci_alloc(obj->base.dev, +- roundup_pow_of_two(obj->base.size), +- roundup_pow_of_two(obj->base.size)); +- if (!phys) ++ vaddr = dma_alloc_coherent(&obj->base.dev->pdev->dev, ++ roundup_pow_of_two(obj->base.size), ++ &dma, GFP_KERNEL); ++ if (!vaddr) + return -ENOMEM; + +- vaddr = phys->vaddr; ++ st = kmalloc(sizeof(*st), GFP_KERNEL); ++ if (!st) ++ goto err_pci; ++ ++ if (sg_alloc_table(st, 1, GFP_KERNEL)) ++ goto err_st; ++ ++ sg = st->sgl; ++ sg->offset = 0; ++ sg->length = obj->base.size; ++ ++ sg_assign_page(sg, (struct page *)vaddr); ++ sg_dma_address(sg) = dma; ++ sg_dma_len(sg) = obj->base.size; ++ ++ dst = vaddr; + for (i = 0; i < obj->base.size / PAGE_SIZE; i++) { + struct page *page; +- char *src; ++ void *src; + + page = shmem_read_mapping_page(mapping, i); +- if (IS_ERR(page)) { +- err = PTR_ERR(page); +- goto err_phys; +- } ++ if (IS_ERR(page)) ++ goto err_st; + + src = kmap_atomic(page); +- memcpy(vaddr, src, PAGE_SIZE); +- drm_clflush_virt_range(vaddr, PAGE_SIZE); ++ memcpy(dst, src, PAGE_SIZE); ++ drm_clflush_virt_range(dst, PAGE_SIZE); + kunmap_atomic(src); + + put_page(page); +- vaddr += PAGE_SIZE; ++ dst += PAGE_SIZE; + } + + intel_gt_chipset_flush(&to_i915(obj->base.dev)->gt); + +- st = kmalloc(sizeof(*st), GFP_KERNEL); +- if (!st) { +- err = -ENOMEM; +- goto err_phys; +- } +- +- if (sg_alloc_table(st, 1, GFP_KERNEL)) { +- kfree(st); +- err = -ENOMEM; +- goto err_phys; +- } +- +- sg = st->sgl; +- sg->offset = 0; +- sg->length = obj->base.size; +- +- sg_dma_address(sg) = phys->busaddr; +- sg_dma_len(sg) = obj->base.size; +- +- obj->phys_handle = phys; +- + __i915_gem_object_set_pages(obj, st, sg->length); + + return 0; + +-err_phys: +- drm_pci_free(obj->base.dev, phys); +- +- return err; ++err_st: ++ kfree(st); ++err_pci: ++ dma_free_coherent(&obj->base.dev->pdev->dev, ++ roundup_pow_of_two(obj->base.size), ++ vaddr, dma); ++ return -ENOMEM; + } + + static void + i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj, + struct sg_table *pages) + { ++ dma_addr_t dma = sg_dma_address(pages->sgl); ++ void *vaddr = sg_page(pages->sgl); ++ + __i915_gem_object_release_shmem(obj, pages, false); + + if (obj->mm.dirty) { + struct address_space *mapping = obj->base.filp->f_mapping; +- char *vaddr = obj->phys_handle->vaddr; ++ void *src = vaddr; + int i; + + for (i = 0; i < obj->base.size / PAGE_SIZE; i++) { +@@ -115,15 +114,16 @@ i915_gem_object_put_pages_phys(struct dr + continue; + + dst = kmap_atomic(page); +- drm_clflush_virt_range(vaddr, PAGE_SIZE); +- memcpy(dst, vaddr, PAGE_SIZE); ++ drm_clflush_virt_range(src, PAGE_SIZE); ++ memcpy(dst, src, PAGE_SIZE); + kunmap_atomic(dst); + + set_page_dirty(page); + if (obj->mm.madv == I915_MADV_WILLNEED) + mark_page_accessed(page); + put_page(page); +- vaddr += PAGE_SIZE; ++ ++ src += PAGE_SIZE; + } + obj->mm.dirty = false; + } +@@ -131,7 +131,9 @@ i915_gem_object_put_pages_phys(struct dr + sg_free_table(pages); + kfree(pages); + +- drm_pci_free(obj->base.dev, obj->phys_handle); ++ dma_free_coherent(&obj->base.dev->pdev->dev, ++ roundup_pow_of_two(obj->base.size), ++ vaddr, dma); + } + + static void phys_release(struct drm_i915_gem_object *obj) +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -154,7 +154,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem + struct drm_i915_gem_pwrite *args, + struct drm_file *file) + { +- void *vaddr = obj->phys_handle->vaddr + args->offset; ++ void *vaddr = sg_page(obj->mm.pages->sgl) + args->offset; + char __user *user_data = u64_to_user_ptr(args->data_ptr); + + /* +@@ -800,10 +800,10 @@ i915_gem_pwrite_ioctl(struct drm_device + ret = i915_gem_gtt_pwrite_fast(obj, args); + + if (ret == -EFAULT || ret == -ENOSPC) { +- if (obj->phys_handle) +- ret = i915_gem_phys_pwrite(obj, args, file); +- else ++ if (i915_gem_object_has_struct_page(obj)) + ret = i915_gem_shmem_pwrite(obj, args); ++ else ++ ret = i915_gem_phys_pwrite(obj, args, file); + } + + i915_gem_object_unpin_pages(obj); diff --git a/queue-5.5/drm-nouveau-kms-gv100-re-set-lut-after-clearing-for-modesets.patch b/queue-5.5/drm-nouveau-kms-gv100-re-set-lut-after-clearing-for-modesets.patch new file mode 100644 index 00000000000..01e86fe09ea --- /dev/null +++ b/queue-5.5/drm-nouveau-kms-gv100-re-set-lut-after-clearing-for-modesets.patch @@ -0,0 +1,43 @@ +From f287d3d19769b1d22cba4e51fa0487f2697713c9 Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Wed, 12 Feb 2020 18:11:49 -0500 +Subject: drm/nouveau/kms/gv100-: Re-set LUT after clearing for modesets + +From: Lyude Paul + +commit f287d3d19769b1d22cba4e51fa0487f2697713c9 upstream. + +While certain modeset operations on gv100+ need us to temporarily +disable the LUT, we make the mistake of sometimes neglecting to +reprogram the LUT after such modesets. In particular, moving a head from +one encoder to another seems to trigger this quite often. GV100+ is very +picky about having a LUT in most scenarios, so this causes the display +engine to hang with the following error code: + +disp: chid 1 stat 00005080 reason 5 [INVALID_STATE] mthd 0200 data +00000001 code 0000002d) + +So, fix this by always re-programming the LUT if we're clearing it in a +state where the wndw is still visible, and has a XLUT handle programmed. + +Signed-off-by: Lyude Paul +Fixes: facaed62b4cb ("drm/nouveau/kms/gv100: initial support") +Cc: # v4.18+ +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/dispnv50/wndw.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c ++++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c +@@ -451,6 +451,8 @@ nv50_wndw_atomic_check(struct drm_plane + asyw->clr.ntfy = armw->ntfy.handle != 0; + asyw->clr.sema = armw->sema.handle != 0; + asyw->clr.xlut = armw->xlut.handle != 0; ++ if (asyw->clr.xlut && asyw->visible) ++ asyw->set.xlut = asyw->xlut.handle != 0; + asyw->clr.csc = armw->csc.valid; + if (wndw->func->image_clr) + asyw->clr.image = armw->image.handle[0] != 0; diff --git a/queue-5.5/lib-stackdepot.c-fix-global-out-of-bounds-in-stack_slabs.patch b/queue-5.5/lib-stackdepot.c-fix-global-out-of-bounds-in-stack_slabs.patch new file mode 100644 index 00000000000..a38231513c2 --- /dev/null +++ b/queue-5.5/lib-stackdepot.c-fix-global-out-of-bounds-in-stack_slabs.patch @@ -0,0 +1,58 @@ +From 305e519ce48e935702c32241f07d393c3c8fed3e Mon Sep 17 00:00:00 2001 +From: Alexander Potapenko +Date: Thu, 20 Feb 2020 20:04:30 -0800 +Subject: lib/stackdepot.c: fix global out-of-bounds in stack_slabs + +From: Alexander Potapenko + +commit 305e519ce48e935702c32241f07d393c3c8fed3e upstream. + +Walter Wu has reported a potential case in which init_stack_slab() is +called after stack_slabs[STACK_ALLOC_MAX_SLABS - 1] has already been +initialized. In that case init_stack_slab() will overwrite +stack_slabs[STACK_ALLOC_MAX_SLABS], which may result in a memory +corruption. + +Link: http://lkml.kernel.org/r/20200218102950.260263-1-glider@google.com +Fixes: cd11016e5f521 ("mm, kasan: stackdepot implementation. Enable stackdepot for SLAB") +Signed-off-by: Alexander Potapenko +Reported-by: Walter Wu +Cc: Dmitry Vyukov +Cc: Matthias Brugger +Cc: Thomas Gleixner +Cc: Josh Poimboeuf +Cc: Kate Stewart +Cc: Greg Kroah-Hartman +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + lib/stackdepot.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +--- a/lib/stackdepot.c ++++ b/lib/stackdepot.c +@@ -83,15 +83,19 @@ static bool init_stack_slab(void **preal + return true; + if (stack_slabs[depot_index] == NULL) { + stack_slabs[depot_index] = *prealloc; ++ *prealloc = NULL; + } else { +- stack_slabs[depot_index + 1] = *prealloc; ++ /* If this is the last depot slab, do not touch the next one. */ ++ if (depot_index + 1 < STACK_ALLOC_MAX_SLABS) { ++ stack_slabs[depot_index + 1] = *prealloc; ++ *prealloc = NULL; ++ } + /* + * This smp_store_release pairs with smp_load_acquire() from + * |next_slab_inited| above and in stack_depot_save(). + */ + smp_store_release(&next_slab_inited, 1); + } +- *prealloc = NULL; + return true; + } + diff --git a/queue-5.5/mm-avoid-creating-virtual-address-aliases-in-brk-mmap-mremap.patch b/queue-5.5/mm-avoid-creating-virtual-address-aliases-in-brk-mmap-mremap.patch new file mode 100644 index 00000000000..2dc9f77bc96 --- /dev/null +++ b/queue-5.5/mm-avoid-creating-virtual-address-aliases-in-brk-mmap-mremap.patch @@ -0,0 +1,92 @@ +From dcde237319e626d1ec3c9d8b7613032f0fd4663a Mon Sep 17 00:00:00 2001 +From: Catalin Marinas +Date: Wed, 19 Feb 2020 12:31:56 +0000 +Subject: mm: Avoid creating virtual address aliases in brk()/mmap()/mremap() + +From: Catalin Marinas + +commit dcde237319e626d1ec3c9d8b7613032f0fd4663a upstream. + +Currently the arm64 kernel ignores the top address byte passed to brk(), +mmap() and mremap(). When the user is not aware of the 56-bit address +limit or relies on the kernel to return an error, untagging such +pointers has the potential to create address aliases in user-space. +Passing a tagged address to munmap(), madvise() is permitted since the +tagged pointer is expected to be inside an existing mapping. + +The current behaviour breaks the existing glibc malloc() implementation +which relies on brk() with an address beyond 56-bit to be rejected by +the kernel. + +Remove untagging in the above functions by partially reverting commit +ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk"). In +addition, update the arm64 tagged-address-abi.rst document accordingly. + +Link: https://bugzilla.redhat.com/1797052 +Fixes: ce18d171cb73 ("mm: untag user pointers in mmap/munmap/mremap/brk") +Cc: # 5.4.x- +Cc: Florian Weimer +Reviewed-by: Andrew Morton +Reported-by: Victor Stinner +Acked-by: Will Deacon +Acked-by: Andrey Konovalov +Signed-off-by: Catalin Marinas +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/arm64/tagged-address-abi.rst | 11 +++++++++-- + mm/mmap.c | 4 ---- + mm/mremap.c | 1 - + 3 files changed, 9 insertions(+), 7 deletions(-) + +--- a/Documentation/arm64/tagged-address-abi.rst ++++ b/Documentation/arm64/tagged-address-abi.rst +@@ -44,8 +44,15 @@ The AArch64 Tagged Address ABI has two s + how the user addresses are used by the kernel: + + 1. User addresses not accessed by the kernel but used for address space +- management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use +- of valid tagged pointers in this context is always allowed. ++ management (e.g. ``mprotect()``, ``madvise()``). The use of valid ++ tagged pointers in this context is allowed with the exception of ++ ``brk()``, ``mmap()`` and the ``new_address`` argument to ++ ``mremap()`` as these have the potential to alias with existing ++ user addresses. ++ ++ NOTE: This behaviour changed in v5.6 and so some earlier kernels may ++ incorrectly accept valid tagged pointers for the ``brk()``, ++ ``mmap()`` and ``mremap()`` system calls. + + 2. User addresses accessed by the kernel (e.g. ``write()``). This ABI + relaxation is disabled by default and the application thread needs to +--- a/mm/mmap.c ++++ b/mm/mmap.c +@@ -195,8 +195,6 @@ SYSCALL_DEFINE1(brk, unsigned long, brk) + bool downgraded = false; + LIST_HEAD(uf); + +- brk = untagged_addr(brk); +- + if (down_write_killable(&mm->mmap_sem)) + return -EINTR; + +@@ -1561,8 +1559,6 @@ unsigned long ksys_mmap_pgoff(unsigned l + struct file *file = NULL; + unsigned long retval; + +- addr = untagged_addr(addr); +- + if (!(flags & MAP_ANONYMOUS)) { + audit_mmap_fd(fd, flags); + file = fget(fd); +--- a/mm/mremap.c ++++ b/mm/mremap.c +@@ -607,7 +607,6 @@ SYSCALL_DEFINE5(mremap, unsigned long, a + LIST_HEAD(uf_unmap); + + addr = untagged_addr(addr); +- new_addr = untagged_addr(new_addr); + + if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE)) + return ret; diff --git a/queue-5.5/mm-sparsemem-pfn_to_page-is-not-valid-yet-on-sparsemem.patch b/queue-5.5/mm-sparsemem-pfn_to_page-is-not-valid-yet-on-sparsemem.patch new file mode 100644 index 00000000000..7e559863f6d --- /dev/null +++ b/queue-5.5/mm-sparsemem-pfn_to_page-is-not-valid-yet-on-sparsemem.patch @@ -0,0 +1,91 @@ +From 18e19f195cd888f65643a77a0c6aee8f5be6439a Mon Sep 17 00:00:00 2001 +From: Wei Yang +Date: Thu, 20 Feb 2020 20:04:27 -0800 +Subject: mm/sparsemem: pfn_to_page is not valid yet on SPARSEMEM + +From: Wei Yang + +commit 18e19f195cd888f65643a77a0c6aee8f5be6439a upstream. + +When we use SPARSEMEM instead of SPARSEMEM_VMEMMAP, pfn_to_page() +doesn't work before sparse_init_one_section() is called. + +This leads to a crash when hotplug memory: + + BUG: unable to handle page fault for address: 0000000006400000 + #PF: supervisor write access in kernel mode + #PF: error_code(0x0002) - not-present page + PGD 0 P4D 0 + Oops: 0002 [#1] SMP PTI + CPU: 3 PID: 221 Comm: kworker/u16:1 Tainted: G W 5.5.0-next-20200205+ #343 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 + Workqueue: kacpi_hotplug acpi_hotplug_work_fn + RIP: 0010:__memset+0x24/0x30 + Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3 + RSP: 0018:ffffb43ac0373c80 EFLAGS: 00010a87 + RAX: ffffffffffffffff RBX: ffff8a1518800000 RCX: 0000000000050000 + RDX: 0000000000000000 RSI: 00000000000000ff RDI: 0000000006400000 + RBP: 0000000000140000 R08: 0000000000100000 R09: 0000000006400000 + R10: 0000000000000000 R11: 0000000000000002 R12: 0000000000000000 + R13: 0000000000000028 R14: 0000000000000000 R15: ffff8a153ffd9280 + FS: 0000000000000000(0000) GS:ffff8a153ab00000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000000006400000 CR3: 0000000136fca000 CR4: 00000000000006e0 + DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 + DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 + Call Trace: + sparse_add_section+0x1c9/0x26a + __add_pages+0xbf/0x150 + add_pages+0x12/0x60 + add_memory_resource+0xc8/0x210 + __add_memory+0x62/0xb0 + acpi_memory_device_add+0x13f/0x300 + acpi_bus_attach+0xf6/0x200 + acpi_bus_scan+0x43/0x90 + acpi_device_hotplug+0x275/0x3d0 + acpi_hotplug_work_fn+0x1a/0x30 + process_one_work+0x1a7/0x370 + worker_thread+0x30/0x380 + kthread+0x112/0x130 + ret_from_fork+0x35/0x40 + +We should use memmap as it did. + +On x86 the impact is limited to x86_32 builds, or x86_64 configurations +that override the default setting for SPARSEMEM_VMEMMAP. + +Other memory hotplug archs (arm64, ia64, and ppc) also default to +SPARSEMEM_VMEMMAP=y. + +[dan.j.williams@intel.com: changelog update] +{rppt@linux.ibm.com: changelog update] +Link: http://lkml.kernel.org/r/20200219030454.4844-1-bhe@redhat.com +Fixes: ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug") +Signed-off-by: Wei Yang +Signed-off-by: Baoquan He +Acked-by: David Hildenbrand +Reviewed-by: Baoquan He +Reviewed-by: Dan Williams +Acked-by: Michal Hocko +Cc: Mike Rapoport +Cc: Oscar Salvador +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/sparse.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/mm/sparse.c ++++ b/mm/sparse.c +@@ -886,7 +886,7 @@ int __meminit sparse_add_section(int nid + * Poison uninitialized struct pages in order to catch invalid flags + * combinations. + */ +- page_init_poison(pfn_to_page(start_pfn), sizeof(struct page) * nr_pages); ++ page_init_poison(memmap, sizeof(struct page) * nr_pages); + + ms = __nr_to_section(section_nr); + set_section_nid(section_nr, nid); diff --git a/queue-5.5/mm-vmscan.c-don-t-round-up-scan-size-for-online-memory-cgroup.patch b/queue-5.5/mm-vmscan.c-don-t-round-up-scan-size-for-online-memory-cgroup.patch new file mode 100644 index 00000000000..38cd316f135 --- /dev/null +++ b/queue-5.5/mm-vmscan.c-don-t-round-up-scan-size-for-online-memory-cgroup.patch @@ -0,0 +1,86 @@ +From 76073c646f5f4999d763f471df9e38a5a912d70d Mon Sep 17 00:00:00 2001 +From: Gavin Shan +Date: Thu, 20 Feb 2020 20:04:24 -0800 +Subject: mm/vmscan.c: don't round up scan size for online memory cgroup + +From: Gavin Shan + +commit 76073c646f5f4999d763f471df9e38a5a912d70d upstream. + +Commit 68600f623d69 ("mm: don't miss the last page because of round-off +error") makes the scan size round up to @denominator regardless of the +memory cgroup's state, online or offline. This affects the overall +reclaiming behavior: the corresponding LRU list is eligible for +reclaiming only when its size logically right shifted by @sc->priority +is bigger than zero in the former formula. + +For example, the inactive anonymous LRU list should have at least 0x4000 +pages to be eligible for reclaiming when we have 60/12 for +swappiness/priority and without taking scan/rotation ratio into account. + +After the roundup is applied, the inactive anonymous LRU list becomes +eligible for reclaiming when its size is bigger than or equal to 0x1000 +in the same condition. + + (0x4000 >> 12) * 60 / (60 + 140 + 1) = 1 + ((0x1000 >> 12) * 60) + 200) / (60 + 140 + 1) = 1 + +aarch64 has 512MB huge page size when the base page size is 64KB. The +memory cgroup that has a huge page is always eligible for reclaiming in +that case. + +The reclaiming is likely to stop after the huge page is reclaimed, +meaing the further iteration on @sc->priority and the silbing and child +memory cgroups will be skipped. The overall behaviour has been changed. +This fixes the issue by applying the roundup to offlined memory cgroups +only, to give more preference to reclaim memory from offlined memory +cgroup. It sounds reasonable as those memory is unlikedly to be used by +anyone. + +The issue was found by starting up 8 VMs on a Ampere Mustang machine, +which has 8 CPUs and 16 GB memory. Each VM is given with 2 vCPUs and +2GB memory. It took 264 seconds for all VMs to be completely up and +784MB swap is consumed after that. With this patch applied, it took 236 +seconds and 60MB swap to do same thing. So there is 10% performance +improvement for my case. Note that KSM is disable while THP is enabled +in the testing. + + total used free shared buff/cache available + Mem: 16196 10065 2049 16 4081 3749 + Swap: 8175 784 7391 + total used free shared buff/cache available + Mem: 16196 11324 3656 24 1215 2936 + Swap: 8175 60 8115 + +Link: http://lkml.kernel.org/r/20200211024514.8730-1-gshan@redhat.com +Fixes: 68600f623d69 ("mm: don't miss the last page because of round-off error") +Signed-off-by: Gavin Shan +Acked-by: Roman Gushchin +Cc: [4.20+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmscan.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -2429,10 +2429,13 @@ out: + /* + * Scan types proportional to swappiness and + * their relative recent reclaim efficiency. +- * Make sure we don't miss the last page +- * because of a round-off error. ++ * Make sure we don't miss the last page on ++ * the offlined memory cgroups because of a ++ * round-off error. + */ +- scan = DIV64_U64_ROUND_UP(scan * fraction[file], ++ scan = mem_cgroup_online(memcg) ? ++ div64_u64(scan * fraction[file], denominator) : ++ DIV64_U64_ROUND_UP(scan * fraction[file], + denominator); + break; + case SCAN_FILE: diff --git a/queue-5.5/series b/queue-5.5/series index 4e9ebd2f1a4..9ca64c3720d 100644 --- a/queue-5.5/series +++ b/queue-5.5/series @@ -73,3 +73,13 @@ revert-ipc-sem-remove-uneeded-sem_undo_list-lock-usage-in-exit_sem.patch mm-memcontrol.c-lost-css_put-in-memcg_expand_shrinker_maps.patch nvme-multipath-fix-memory-leak-with-ana_log_buf.patch genirq-irqdomain-make-sure-all-irq-domain-flags-are-distinct.patch +mm-vmscan.c-don-t-round-up-scan-size-for-online-memory-cgroup.patch +mm-sparsemem-pfn_to_page-is-not-valid-yet-on-sparsemem.patch +lib-stackdepot.c-fix-global-out-of-bounds-in-stack_slabs.patch +mm-avoid-creating-virtual-address-aliases-in-brk-mmap-mremap.patch +drm-amdgpu-soc15-fix-xclk-for-raven.patch +drm-amdgpu-gfx9-disable-gfxoff-when-reading-rlc-clock.patch +drm-amdgpu-gfx10-disable-gfxoff-when-reading-rlc-clock.patch +drm-nouveau-kms-gv100-re-set-lut-after-clearing-for-modesets.patch +drm-i915-wean-off-drm_pci_alloc-drm_pci_free.patch +drm-i915-update-drm-i915-bug-filing-url.patch