--- /dev/null
+From b08c3ed609aabc4e76e74edc4404f0c26279d7ed Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 12 Feb 2020 08:52:32 -0500
+Subject: drm/amdgpu/gfx10: disable gfxoff when reading rlc clock
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit b08c3ed609aabc4e76e74edc4404f0c26279d7ed upstream.
+
+Otherwise we readback all ones. Fixes rlc counter
+readback while gfxoff is active.
+
+Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -3977,11 +3977,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;
+ }
+
--- /dev/null
+From 120cf959308e1bda984e40a9edd25ee2d6262efd Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 12 Feb 2020 08:51:29 -0500
+Subject: drm/amdgpu/gfx9: disable gfxoff when reading rlc clock
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit 120cf959308e1bda984e40a9edd25ee2d6262efd upstream.
+
+Otherwise we readback all ones. Fixes rlc counter
+readback while gfxoff is active.
+
+Reviewed-by: Xiaojie Yuan <xiaojie.yuan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -4080,11 +4080,13 @@ 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);
+ 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;
+ }
+
--- /dev/null
+From c657b936ea98630ef5ba4f130ab1ad5c534d0165 Mon Sep 17 00:00:00 2001
+From: Alex Deucher <alexander.deucher@amd.com>
+Date: Wed, 12 Feb 2020 01:46:16 -0500
+Subject: drm/amdgpu/soc15: fix xclk for raven
+
+From: Alex Deucher <alexander.deucher@amd.com>
+
+commit c657b936ea98630ef5ba4f130ab1ad5c534d0165 upstream.
+
+It's 25 Mhz (refclk / 4). This fixes the interpretation
+of the rlc clock counter.
+
+Acked-by: Evan Quan <evan.quan@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -267,7 +267,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;
+ }
+
+
--- /dev/null
+From 7ddc7005a0aa2f43a826b71f5d6bd7d4b90f8f2a Mon Sep 17 00:00:00 2001
+From: Jani Nikula <jani.nikula@intel.com>
+Date: Wed, 12 Feb 2020 18:04:34 +0200
+Subject: drm/i915: Update drm/i915 bug filing URL
+
+From: Jani Nikula <jani.nikula@intel.com>
+
+commit 7ddc7005a0aa2f43a826b71f5d6bd7d4b90f8f2a upstream.
+
+We've moved from bugzilla to gitlab.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20200212160434.6437-2-jani.nikula@intel.com
+(cherry picked from commit ddae4d7af0bbe3b2051f1603459a8b24e9a19324)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -1768,7 +1768,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,
--- /dev/null
+From aa3146193ae25d0fe4b96d815169a135db2e8f01 Mon Sep 17 00:00:00 2001
+From: Chris Wilson <chris@chris-wilson.co.uk>
+Date: Sun, 2 Feb 2020 15:39:34 +0000
+Subject: drm/i915: Wean off drm_pci_alloc/drm_pci_free
+
+From: Chris Wilson <chris@chris-wilson.co.uk>
+
+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 <kirill.shutemov@linux.intel.com>
+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 <chris@chris-wilson.co.uk>
+Cc: <stable@vger.kernel.org> # v4.5+
+Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
+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 <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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
+@@ -10510,7 +10510,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
+@@ -240,9 +240,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
+@@ -21,88 +21,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++) {
+@@ -114,15 +113,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;
+ }
+@@ -130,7 +130,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
+@@ -136,7 +136,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);
+
+ /*
+@@ -802,10 +802,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);
--- /dev/null
+From f287d3d19769b1d22cba4e51fa0487f2697713c9 Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Wed, 12 Feb 2020 18:11:49 -0500
+Subject: drm/nouveau/kms/gv100-: Re-set LUT after clearing for modesets
+
+From: Lyude Paul <lyude@redhat.com>
+
+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 <lyude@redhat.com>
+Fixes: facaed62b4cb ("drm/nouveau/kms/gv100: initial support")
+Cc: <stable@vger.kernel.org> # v4.18+
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 305e519ce48e935702c32241f07d393c3c8fed3e Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Thu, 20 Feb 2020 20:04:30 -0800
+Subject: lib/stackdepot.c: fix global out-of-bounds in stack_slabs
+
+From: Alexander Potapenko <glider@google.com>
+
+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 <glider@google.com>
+Reported-by: Walter Wu <walter-zh.wu@mediatek.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Matthias Brugger <matthias.bgg@gmail.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Josh Poimboeuf <jpoimboe@redhat.com>
+Cc: Kate Stewart <kstewart@linuxfoundation.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
--- /dev/null
+From dcde237319e626d1ec3c9d8b7613032f0fd4663a Mon Sep 17 00:00:00 2001
+From: Catalin Marinas <catalin.marinas@arm.com>
+Date: Wed, 19 Feb 2020 12:31:56 +0000
+Subject: mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()
+
+From: Catalin Marinas <catalin.marinas@arm.com>
+
+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: <stable@vger.kernel.org> # 5.4.x-
+Cc: Florian Weimer <fweimer@redhat.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Reported-by: Victor Stinner <vstinner@redhat.com>
+Acked-by: Will Deacon <will@kernel.org>
+Acked-by: Andrey Konovalov <andreyknvl@google.com>
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+
+@@ -1583,8 +1581,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;
--- /dev/null
+From 18e19f195cd888f65643a77a0c6aee8f5be6439a Mon Sep 17 00:00:00 2001
+From: Wei Yang <richardw.yang@linux.intel.com>
+Date: Thu, 20 Feb 2020 20:04:27 -0800
+Subject: mm/sparsemem: pfn_to_page is not valid yet on SPARSEMEM
+
+From: Wei Yang <richardw.yang@linux.intel.com>
+
+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 <f3> 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 <richardw.yang@linux.intel.com>
+Signed-off-by: Baoquan He <bhe@redhat.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Baoquan He <bhe@redhat.com>
+Reviewed-by: Dan Williams <dan.j.williams@intel.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Mike Rapoport <rppt@linux.ibm.com>
+Cc: Oscar Salvador <osalvador@suse.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/sparse.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/sparse.c
++++ b/mm/sparse.c
+@@ -884,7 +884,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);
--- /dev/null
+From 76073c646f5f4999d763f471df9e38a5a912d70d Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gshan@redhat.com>
+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 <gshan@redhat.com>
+
+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 <gshan@redhat.com>
+Acked-by: Roman Gushchin <guro@fb.com>
+Cc: <stable@vger.kernel.org> [4.20+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/vmscan.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/mm/vmscan.c
++++ b/mm/vmscan.c
+@@ -2530,10 +2530,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:
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
projects / thirdparty / kernel / stable-queue.git / commitdiff
