--- /dev/null
+From d2ceea0eb6e17bb37d8b85cb4c16797c0d683d1c Mon Sep 17 00:00:00 2001
+From: Danilo Krummrich <dakr@redhat.com>
+Date: Thu, 26 Jan 2023 01:28:44 +0100
+Subject: dma-buf: actually set signaling bit for private stub fences
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Danilo Krummrich <dakr@redhat.com>
+
+commit d2ceea0eb6e17bb37d8b85cb4c16797c0d683d1c upstream.
+
+In dma_fence_allocate_private_stub() set the signaling bit of the newly
+allocated private stub fence rather than the signaling bit of the
+shared dma_fence_stub.
+
+Cc: <stable@vger.kernel.org> # v6.1
+Fixes: c85d00d4fd8b ("dma-buf: set signaling bit for the stub fence")
+Reviewed-by: Christian König <christian.koenig@amd.com>
+Signed-off-by: Danilo Krummrich <dakr@redhat.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230126002844.339593-1-dakr@redhat.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/dma-buf/dma-fence.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
+index 406b4e26f538..0de0482cd36e 100644
+--- a/drivers/dma-buf/dma-fence.c
++++ b/drivers/dma-buf/dma-fence.c
+@@ -167,7 +167,7 @@ struct dma_fence *dma_fence_allocate_private_stub(void)
+ 0, 0);
+
+ set_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT,
+- &dma_fence_stub.flags);
++ &fence->flags);
+
+ dma_fence_signal(fence);
+
+--
+2.39.1
+
--- /dev/null
+From 5048fa1ebf89d03cf0ceca13fab8f800399e9ee3 Mon Sep 17 00:00:00 2001
+From: Mario Limonciello <mario.limonciello@amd.com>
+Date: Mon, 30 Jan 2023 10:16:06 -0600
+Subject: drm/amd: Fix initialization for nbio 4.3.0
+
+From: Mario Limonciello <mario.limonciello@amd.com>
+
+commit 5048fa1ebf89d03cf0ceca13fab8f800399e9ee3 upstream.
+
+A mistake has been made on some boards with NBIO 4.3.0 where some
+NBIO registers aren't properly set by the hardware.
+
+Ensure that they're set during initialization.
+
+Cc: Natikar Basavaraj <Basavaraj.Natikar@amd.com>
+Tested-by: Satyanarayana ReddyTVN <Satyanarayana.ReddyTVN@amd.com>
+Tested-by: Rutvij Gajjar <Rutvij.Gajjar@amd.com>
+Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
+Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org # 6.1.x
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c b/drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c
+index 15eb3658d70e..09fdcd20cb91 100644
+--- a/drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c
++++ b/drivers/gpu/drm/amd/amdgpu/nbio_v4_3.c
+@@ -337,7 +337,13 @@ const struct nbio_hdp_flush_reg nbio_v4_3_hdp_flush_reg = {
+
+ static void nbio_v4_3_init_registers(struct amdgpu_device *adev)
+ {
+- return;
++ if (adev->ip_versions[NBIO_HWIP][0] == IP_VERSION(4, 3, 0)) {
++ uint32_t data;
++
++ data = RREG32_SOC15(NBIO, 0, regRCC_DEV0_EPF2_STRAP2);
++ data &= ~RCC_DEV0_EPF2_STRAP2__STRAP_NO_SOFT_RESET_DEV0_F2_MASK;
++ WREG32_SOC15(NBIO, 0, regRCC_DEV0_EPF2_STRAP2, data);
++ }
+ }
+
+ static u32 nbio_v4_3_get_rom_offset(struct amdgpu_device *adev)
+--
+2.39.1
+
--- /dev/null
+From 1538709c9f1c207d30afd95ea41b3aeb973f67e7 Mon Sep 17 00:00:00 2001
+From: Tim Huang <tim.huang@amd.com>
+Date: Sat, 21 Jan 2023 10:35:04 +0800
+Subject: drm/amd/pm: drop unneeded dpm features disablement for SMU 13.0.4/11
+
+From: Tim Huang <tim.huang@amd.com>
+
+commit 1538709c9f1c207d30afd95ea41b3aeb973f67e7 upstream.
+
+PMFW will handle the features disablement properly for gpu reset case,
+driver involvement may cause some unexpected issues.
+
+Cc: stable@vger.kernel.org # 6.1
+Signed-off-by: Tim Huang <tim.huang@amd.com>
+Reviewed-by: Yifan Zhang <yifan1.zhang@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
++++ b/drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c
+@@ -1499,6 +1499,20 @@ static int smu_disable_dpms(struct smu_c
+ }
+
+ /*
++ * For SMU 13.0.4/11, PMFW will handle the features disablement properly
++ * for gpu reset case. Driver involvement is unnecessary.
++ */
++ if (amdgpu_in_reset(adev)) {
++ switch (adev->ip_versions[MP1_HWIP][0]) {
++ case IP_VERSION(13, 0, 4):
++ case IP_VERSION(13, 0, 11):
++ return 0;
++ default:
++ break;
++ }
++ }
++
++ /*
+ * For gpu reset, runpm and hibernation through BACO,
+ * BACO feature has to be kept enabled.
+ */
--- /dev/null
+From ed8e793c65e4c6633e8577e40d574da8a56d2e0f Mon Sep 17 00:00:00 2001
+From: Graham Sider <Graham.Sider@amd.com>
+Date: Mon, 16 Jan 2023 10:43:11 -0500
+Subject: drm/amdgpu: update wave data type to 3 for gfx11
+
+From: Graham Sider <Graham.Sider@amd.com>
+
+commit ed8e793c65e4c6633e8577e40d574da8a56d2e0f upstream.
+
+SQ_WAVE_INST_DW0 isn't present on gfx11 compared to gfx10, so update
+wave data type to signify a difference.
+
+Signed-off-by: Graham Sider <Graham.Sider@amd.com>
+Reviewed-by: Mukul Joshi <Mukul.Joshi@amd.com>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Cc: stable@vger.kernel.org # 6.1.x
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+index b9b57a66e113..66eb102cd88f 100644
+--- a/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
++++ b/drivers/gpu/drm/amd/amdgpu/gfx_v11_0.c
+@@ -790,8 +790,8 @@ static void gfx_v11_0_read_wave_data(struct amdgpu_device *adev, uint32_t simd,
+ * zero here */
+ WARN_ON(simd != 0);
+
+- /* type 2 wave data */
+- dst[(*no_fields)++] = 2;
++ /* type 3 wave data */
++ dst[(*no_fields)++] = 3;
+ dst[(*no_fields)++] = wave_read_ind(adev, wave, ixSQ_WAVE_STATUS);
+ dst[(*no_fields)++] = wave_read_ind(adev, wave, ixSQ_WAVE_PC_LO);
+ dst[(*no_fields)++] = wave_read_ind(adev, wave, ixSQ_WAVE_PC_HI);
+--
+2.39.1
+
--- /dev/null
+From 41d419382ec7e257e54b7b6ff0d3623aafb1316d Mon Sep 17 00:00:00 2001
+From: Rob Clark <robdclark@chromium.org>
+Date: Thu, 19 Jan 2023 09:32:58 -0800
+Subject: drm/i915: Avoid potential vm use-after-free
+
+From: Rob Clark <robdclark@chromium.org>
+
+commit 41d419382ec7e257e54b7b6ff0d3623aafb1316d upstream.
+
+Adding the vm to the vm_xa table makes it visible to userspace, which
+could try to race with us to close the vm. So we need to take our extra
+reference before putting it in the table.
+
+Signed-off-by: Rob Clark <robdclark@chromium.org>
+Reviewed-by: Matthew Auld <matthew.auld@intel.com>
+Fixes: 9ec8795e7d91 ("drm/i915: Drop __rcu from gem_context->vm")
+Cc: <stable@vger.kernel.org> # v5.16+
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230119173321.2825472-1-robdclark@gmail.com
+(cherry picked from commit 99343c46d4e2b34c285d3d5f68ff04274c2f9fb4)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +++++++++++---
+ 1 file changed, 11 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
+index 6250de9b9196..e4b78ab4773b 100644
+--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
+@@ -1861,11 +1861,19 @@ static int get_ppgtt(struct drm_i915_file_private *file_priv,
+ vm = ctx->vm;
+ GEM_BUG_ON(!vm);
+
++ /*
++ * Get a reference for the allocated handle. Once the handle is
++ * visible in the vm_xa table, userspace could try to close it
++ * from under our feet, so we need to hold the extra reference
++ * first.
++ */
++ i915_vm_get(vm);
++
+ err = xa_alloc(&file_priv->vm_xa, &id, vm, xa_limit_32b, GFP_KERNEL);
+- if (err)
++ if (err) {
++ i915_vm_put(vm);
+ return err;
+-
+- i915_vm_get(vm);
++ }
+
+ GEM_BUG_ON(id == 0); /* reserved for invalid/unassigned ppgtt */
+ args->value = id;
+--
+2.39.1
+
--- /dev/null
+From 7057a8f126f14f14b040faecfa220fd27c6c2f85 Mon Sep 17 00:00:00 2001
+From: Rob Clark <robdclark@chromium.org>
+Date: Fri, 27 Jan 2023 12:05:31 -0800
+Subject: drm/i915: Fix potential bit_17 double-free
+
+From: Rob Clark <robdclark@chromium.org>
+
+commit 7057a8f126f14f14b040faecfa220fd27c6c2f85 upstream.
+
+A userspace with multiple threads racing I915_GEM_SET_TILING to set the
+tiling to I915_TILING_NONE could trigger a double free of the bit_17
+bitmask. (Or conversely leak memory on the transition to tiled.) Move
+allocation/free'ing of the bitmask within the section protected by the
+obj lock.
+
+Signed-off-by: Rob Clark <robdclark@chromium.org>
+Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
+Cc: <stable@vger.kernel.org> # v5.5+
+[tursulin: Correct fixes tag and added cc stable.]
+Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20230127200550.3531984-1-robdclark@gmail.com
+(cherry picked from commit 10e0cbaaf1104f449d695c80bcacf930dcd3c42e)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 9 +++++----
+ 1 file changed, 5 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
++++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
+@@ -305,10 +305,6 @@ i915_gem_object_set_tiling(struct drm_i9
+ spin_unlock(&obj->vma.lock);
+
+ obj->tiling_and_stride = tiling | stride;
+- i915_gem_object_unlock(obj);
+-
+- /* Force the fence to be reacquired for GTT access */
+- i915_gem_object_release_mmap_gtt(obj);
+
+ /* Try to preallocate memory required to save swizzling on put-pages */
+ if (i915_gem_object_needs_bit17_swizzle(obj)) {
+@@ -321,6 +317,11 @@ i915_gem_object_set_tiling(struct drm_i9
+ obj->bit_17 = NULL;
+ }
+
++ i915_gem_object_unlock(obj);
++
++ /* Force the fence to be reacquired for GTT access */
++ i915_gem_object_release_mmap_gtt(obj);
++
+ return 0;
+ }
+
--- /dev/null
+From 60ce26d10e5850f33cc76fce52f5377045e75a15 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= <ilpo.jarvinen@linux.intel.com>
+Date: Wed, 14 Dec 2022 16:49:52 +0200
+Subject: fpga: m10bmc-sec: Fix probe rollback
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+
+commit 60ce26d10e5850f33cc76fce52f5377045e75a15 upstream.
+
+Handle probe error rollbacks properly to avoid leaks.
+
+Fixes: 5cd339b370e2 ("fpga: m10bmc-sec: add max10 secure update functions")
+Reviewed-by: Matthew Gerlach <matthew.gerlach@linux.intel.com>
+Reviewed-by: Russ Weight <russell.h.weight@intel.com>
+Reviewed-by: Marco Pagani <marpagan@redhat.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Cc: stable@vger.kernel.org
+Acked-by: Xu Yilun <yilun.xu@intel.com>
+Link: https://lore.kernel.org/r/20221214144952.8392-1-ilpo.jarvinen@linux.intel.com
+Signed-off-by: Xu Yilun <yilun.xu@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/fpga/intel-m10-bmc-sec-update.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
+index 79d48852825e..03f1bd81c434 100644
+--- a/drivers/fpga/intel-m10-bmc-sec-update.c
++++ b/drivers/fpga/intel-m10-bmc-sec-update.c
+@@ -574,20 +574,27 @@ static int m10bmc_sec_probe(struct platform_device *pdev)
+ len = scnprintf(buf, SEC_UPDATE_LEN_MAX, "secure-update%d",
+ sec->fw_name_id);
+ sec->fw_name = kmemdup_nul(buf, len, GFP_KERNEL);
+- if (!sec->fw_name)
+- return -ENOMEM;
++ if (!sec->fw_name) {
++ ret = -ENOMEM;
++ goto fw_name_fail;
++ }
+
+ fwl = firmware_upload_register(THIS_MODULE, sec->dev, sec->fw_name,
+ &m10bmc_ops, sec);
+ if (IS_ERR(fwl)) {
+ dev_err(sec->dev, "Firmware Upload driver failed to start\n");
+- kfree(sec->fw_name);
+- xa_erase(&fw_upload_xa, sec->fw_name_id);
+- return PTR_ERR(fwl);
++ ret = PTR_ERR(fwl);
++ goto fw_uploader_fail;
+ }
+
+ sec->fwl = fwl;
+ return 0;
++
++fw_uploader_fail:
++ kfree(sec->fw_name);
++fw_name_fail:
++ xa_erase(&fw_upload_xa, sec->fw_name_id);
++ return ret;
+ }
+
+ static int m10bmc_sec_remove(struct platform_device *pdev)
+--
+2.39.1
+
--- /dev/null
+From 65ea840afd508194b0ee903256162aa87e46ec30 Mon Sep 17 00:00:00 2001
+From: Zheng Yongjun <zhengyongjun3@huawei.com>
+Date: Sat, 26 Nov 2022 07:14:30 +0000
+Subject: fpga: stratix10-soc: Fix return value check in s10_ops_write_init()
+
+From: Zheng Yongjun <zhengyongjun3@huawei.com>
+
+commit 65ea840afd508194b0ee903256162aa87e46ec30 upstream.
+
+In case of error, the function stratix10_svc_allocate_memory()
+returns ERR_PTR() and never returns NULL. The NULL test in the
+return value check should be replaced with IS_ERR().
+
+Fixes: e7eef1d7633a ("fpga: add intel stratix10 soc fpga manager driver")
+Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
+Reviewed-by: Russ Weight <russell.h.weight@intel.com>
+Cc: stable@vger.kernel.org
+Acked-by: Xu Yilun <yilun.xu@intel.com>
+Link: https://lore.kernel.org/r/20221126071430.19540-1-zhengyongjun3@huawei.com
+Signed-off-by: Xu Yilun <yilun.xu@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/fpga/stratix10-soc.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/fpga/stratix10-soc.c
++++ b/drivers/fpga/stratix10-soc.c
+@@ -213,9 +213,9 @@ static int s10_ops_write_init(struct fpg
+ /* Allocate buffers from the service layer's pool. */
+ for (i = 0; i < NUM_SVC_BUFS; i++) {
+ kbuf = stratix10_svc_allocate_memory(priv->chan, SVC_BUF_SIZE);
+- if (!kbuf) {
++ if (IS_ERR(kbuf)) {
+ s10_free_buffers(mgr);
+- ret = -ENOMEM;
++ ret = PTR_ERR(kbuf);
+ goto init_done;
+ }
+
--- /dev/null
+From 88d7b12068b95731c280af8ce88e8ee9561f96de Mon Sep 17 00:00:00 2001
+From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
+Date: Thu, 26 Jan 2023 20:07:27 +0000
+Subject: highmem: round down the address passed to kunmap_flush_on_unmap()
+
+From: Matthew Wilcox (Oracle) <willy@infradead.org>
+
+commit 88d7b12068b95731c280af8ce88e8ee9561f96de upstream.
+
+We already round down the address in kunmap_local_indexed() which is the
+other implementation of __kunmap_local(). The only implementation of
+kunmap_flush_on_unmap() is PA-RISC which is expecting a page-aligned
+address. This may be causing PA-RISC to be flushing the wrong addresses
+currently.
+
+Link: https://lkml.kernel.org/r/20230126200727.1680362-1-willy@infradead.org
+Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
+Fixes: 298fa1ad5571 ("highmem: Provide generic variant of kmap_atomic*")
+Reviewed-by: Ira Weiny <ira.weiny@intel.com>
+Cc: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Helge Deller <deller@gmx.de>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Andrey Konovalov <andreyknvl@gmail.com>
+Cc: Bagas Sanjaya <bagasdotme@gmail.com>
+Cc: David Sterba <dsterba@suse.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Cc: Tony Luck <tony.luck@intel.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/linux/highmem-internal.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/include/linux/highmem-internal.h
++++ b/include/linux/highmem-internal.h
+@@ -200,7 +200,7 @@ static inline void *kmap_local_pfn(unsig
+ static inline void __kunmap_local(const void *addr)
+ {
+ #ifdef ARCH_HAS_FLUSH_ON_KUNMAP
+- kunmap_flush_on_unmap(addr);
++ kunmap_flush_on_unmap(PTR_ALIGN_DOWN(addr, PAGE_SIZE));
+ #endif
+ }
+
+@@ -227,7 +227,7 @@ static inline void *kmap_atomic_pfn(unsi
+ static inline void __kunmap_atomic(const void *addr)
+ {
+ #ifdef ARCH_HAS_FLUSH_ON_KUNMAP
+- kunmap_flush_on_unmap(addr);
++ kunmap_flush_on_unmap(PTR_ALIGN_DOWN(addr, PAGE_SIZE));
+ #endif
+ pagefault_enable();
+ if (IS_ENABLED(CONFIG_PREEMPT_RT))
--- /dev/null
+From 6f28a2613497fc587e347afa99fa2c52230678a7 Mon Sep 17 00:00:00 2001
+From: James Morse <james.morse@arm.com>
+Date: Tue, 17 Jan 2023 15:16:32 +0000
+Subject: ia64: fix build error due to switch case label appearing next to declaration
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: James Morse <james.morse@arm.com>
+
+commit 6f28a2613497fc587e347afa99fa2c52230678a7 upstream.
+
+Since commit aa06a9bd8533 ("ia64: fix clock_getres(CLOCK_MONOTONIC) to
+report ITC frequency"), gcc 10.1.0 fails to build ia64 with the gnomic:
+| ../arch/ia64/kernel/sys_ia64.c: In function 'ia64_clock_getres':
+| ../arch/ia64/kernel/sys_ia64.c:189:3: error: a label can only be part of a statement and a declaration is not a statement
+| 189 | s64 tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
+
+This line appears immediately after a case label in a switch.
+
+Move the declarations out of the case, to the top of the function.
+
+Link: https://lkml.kernel.org/r/20230117151632.393836-1-james.morse@arm.com
+Fixes: aa06a9bd8533 ("ia64: fix clock_getres(CLOCK_MONOTONIC) to report ITC frequency")
+Signed-off-by: James Morse <james.morse@arm.com>
+Reviewed-by: Sergei Trofimovich <slyich@gmail.com>
+Cc: Émeric Maschino <emeric.maschino@gmail.com>
+Cc: matoro <matoro_mailinglist_kernel@matoro.tk>
+Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/ia64/kernel/sys_ia64.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/arch/ia64/kernel/sys_ia64.c b/arch/ia64/kernel/sys_ia64.c
+index f6a502e8f02c..6e948d015332 100644
+--- a/arch/ia64/kernel/sys_ia64.c
++++ b/arch/ia64/kernel/sys_ia64.c
+@@ -170,6 +170,9 @@ ia64_mremap (unsigned long addr, unsigned long old_len, unsigned long new_len, u
+ asmlinkage long
+ ia64_clock_getres(const clockid_t which_clock, struct __kernel_timespec __user *tp)
+ {
++ struct timespec64 rtn_tp;
++ s64 tick_ns;
++
+ /*
+ * ia64's clock_gettime() syscall is implemented as a vdso call
+ * fsys_clock_gettime(). Currently it handles only
+@@ -185,8 +188,8 @@ ia64_clock_getres(const clockid_t which_clock, struct __kernel_timespec __user *
+ switch (which_clock) {
+ case CLOCK_REALTIME:
+ case CLOCK_MONOTONIC:
+- s64 tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
+- struct timespec64 rtn_tp = ns_to_timespec64(tick_ns);
++ tick_ns = DIV_ROUND_UP(NSEC_PER_SEC, local_cpu_data->itc_freq);
++ rtn_tp = ns_to_timespec64(tick_ns);
+ return put_timespec64(&rtn_tp, tp);
+ }
+
+--
+2.39.1
+
--- /dev/null
+From 7327e8111adb315423035fb5233533016dfd3f2e Mon Sep 17 00:00:00 2001
+From: Liam Howlett <liam.howlett@oracle.com>
+Date: Wed, 11 Jan 2023 20:02:07 +0000
+Subject: maple_tree: fix mas_empty_area_rev() lower bound validation
+
+From: Liam Howlett <liam.howlett@oracle.com>
+
+commit 7327e8111adb315423035fb5233533016dfd3f2e upstream.
+
+mas_empty_area_rev() was not correctly validating the start of a gap
+against the lower limit. This could lead to the range starting lower than
+the requested minimum.
+
+Fix the issue by better validating a gap once one is found.
+
+This commit also adds tests to the maple tree test suite for this issue
+and tests the mas_empty_area() function for similar bound checking.
+
+Link: https://lkml.kernel.org/r/20230111200136.1851322-1-Liam.Howlett@oracle.com
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=216911
+Fixes: 54a611b60590 ("Maple Tree: add new data structure")
+Signed-off-by: Liam R. Howlett <Liam.Howlett@oracle.com>
+Reported-by: <amanieu@gmail.com>
+ Link: https://lore.kernel.org/linux-mm/0b9f5425-08d4-8013-aa4c-e620c3b10bb2@leemhuis.info/
+Tested-by: Holger Hoffsttte <holger@applied-asynchrony.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ lib/maple_tree.c | 17 ++++-----
+ lib/test_maple_tree.c | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++
+ 2 files changed, 97 insertions(+), 9 deletions(-)
+
+--- a/lib/maple_tree.c
++++ b/lib/maple_tree.c
+@@ -4883,7 +4883,7 @@ static bool mas_rev_awalk(struct ma_stat
+ unsigned long *pivots, *gaps;
+ void __rcu **slots;
+ unsigned long gap = 0;
+- unsigned long max, min, index;
++ unsigned long max, min;
+ unsigned char offset;
+
+ if (unlikely(mas_is_err(mas)))
+@@ -4905,8 +4905,7 @@ static bool mas_rev_awalk(struct ma_stat
+ min = mas_safe_min(mas, pivots, --offset);
+
+ max = mas_safe_pivot(mas, pivots, offset, type);
+- index = mas->index;
+- while (index <= max) {
++ while (mas->index <= max) {
+ gap = 0;
+ if (gaps)
+ gap = gaps[offset];
+@@ -4937,10 +4936,8 @@ static bool mas_rev_awalk(struct ma_stat
+ min = mas_safe_min(mas, pivots, offset);
+ }
+
+- if (unlikely(index > max)) {
+- mas_set_err(mas, -EBUSY);
+- return false;
+- }
++ if (unlikely((mas->index > max) || (size - 1 > max - mas->index)))
++ goto no_space;
+
+ if (unlikely(ma_is_leaf(type))) {
+ mas->offset = offset;
+@@ -4957,9 +4954,11 @@ static bool mas_rev_awalk(struct ma_stat
+ return false;
+
+ ascend:
+- if (mte_is_root(mas->node))
+- mas_set_err(mas, -EBUSY);
++ if (!mte_is_root(mas->node))
++ return false;
+
++no_space:
++ mas_set_err(mas, -EBUSY);
+ return false;
+ }
+
+--- a/lib/test_maple_tree.c
++++ b/lib/test_maple_tree.c
+@@ -2517,6 +2517,91 @@ static noinline void check_bnode_min_spa
+ mt_set_non_kernel(0);
+ }
+
++static noinline void check_empty_area_window(struct maple_tree *mt)
++{
++ unsigned long i, nr_entries = 20;
++ MA_STATE(mas, mt, 0, 0);
++
++ for (i = 1; i <= nr_entries; i++)
++ mtree_store_range(mt, i*10, i*10 + 9,
++ xa_mk_value(i), GFP_KERNEL);
++
++ /* Create another hole besides the one at 0 */
++ mtree_store_range(mt, 160, 169, NULL, GFP_KERNEL);
++
++ /* Check lower bounds that don't fit */
++ rcu_read_lock();
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 5, 90, 10) != -EBUSY);
++
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 6, 90, 5) != -EBUSY);
++
++ /* Check lower bound that does fit */
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 5, 90, 5) != 0);
++ MT_BUG_ON(mt, mas.index != 5);
++ MT_BUG_ON(mt, mas.last != 9);
++ rcu_read_unlock();
++
++ /* Check one gap that doesn't fit and one that does */
++ rcu_read_lock();
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 5, 217, 9) != 0);
++ MT_BUG_ON(mt, mas.index != 161);
++ MT_BUG_ON(mt, mas.last != 169);
++
++ /* Check one gap that does fit above the min */
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 100, 218, 3) != 0);
++ MT_BUG_ON(mt, mas.index != 216);
++ MT_BUG_ON(mt, mas.last != 218);
++
++ /* Check size that doesn't fit any gap */
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 100, 218, 16) != -EBUSY);
++
++ /*
++ * Check size that doesn't fit the lower end of the window but
++ * does fit the gap
++ */
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 167, 200, 4) != -EBUSY);
++
++ /*
++ * Check size that doesn't fit the upper end of the window but
++ * does fit the gap
++ */
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area_rev(&mas, 100, 162, 4) != -EBUSY);
++
++ /* Check mas_empty_area forward */
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area(&mas, 0, 100, 9) != 0);
++ MT_BUG_ON(mt, mas.index != 0);
++ MT_BUG_ON(mt, mas.last != 8);
++
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area(&mas, 0, 100, 4) != 0);
++ MT_BUG_ON(mt, mas.index != 0);
++ MT_BUG_ON(mt, mas.last != 3);
++
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area(&mas, 0, 100, 11) != -EBUSY);
++
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area(&mas, 5, 100, 6) != -EBUSY);
++
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area(&mas, 0, 8, 10) != -EBUSY);
++
++ mas_reset(&mas);
++ mas_empty_area(&mas, 100, 165, 3);
++
++ mas_reset(&mas);
++ MT_BUG_ON(mt, mas_empty_area(&mas, 100, 163, 6) != -EBUSY);
++ rcu_read_unlock();
++}
++
+ static DEFINE_MTREE(tree);
+ static int maple_tree_seed(void)
+ {
+@@ -2765,6 +2850,10 @@ static int maple_tree_seed(void)
+ check_bnode_min_spanning(&tree);
+ mtree_destroy(&tree);
+
++ mt_init_flags(&tree, MT_FLAGS_ALLOC_RANGE);
++ check_empty_area_window(&tree);
++ mtree_destroy(&tree);
++
+ #if defined(BENCH)
+ skip:
+ #endif
--- /dev/null
+From 73bdf65ea74857d7fb2ec3067a3cec0e261b1462 Mon Sep 17 00:00:00 2001
+From: Mike Kravetz <mike.kravetz@oracle.com>
+Date: Thu, 26 Jan 2023 14:27:21 -0800
+Subject: migrate: hugetlb: check for hugetlb shared PMD in node migration
+
+From: Mike Kravetz <mike.kravetz@oracle.com>
+
+commit 73bdf65ea74857d7fb2ec3067a3cec0e261b1462 upstream.
+
+migrate_pages/mempolicy semantics state that CAP_SYS_NICE is required to
+move pages shared with another process to a different node. page_mapcount
+> 1 is being used to determine if a hugetlb page is shared. However, a
+hugetlb page will have a mapcount of 1 if mapped by multiple processes via
+a shared PMD. As a result, hugetlb pages shared by multiple processes and
+mapped with a shared PMD can be moved by a process without CAP_SYS_NICE.
+
+To fix, check for a shared PMD if mapcount is 1. If a shared PMD is found
+consider the page shared.
+
+Link: https://lkml.kernel.org/r/20230126222721.222195-3-mike.kravetz@oracle.com
+Fixes: e2d8cf405525 ("migrate: add hugepage migration code to migrate_pages()")
+Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
+Acked-by: Peter Xu <peterx@redhat.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: James Houghton <jthoughton@google.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Muchun Song <songmuchun@bytedance.com>
+Cc: Naoya Horiguchi <naoya.horiguchi@linux.dev>
+Cc: Vishal Moola (Oracle) <vishal.moola@gmail.com>
+Cc: Yang Shi <shy828301@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mempolicy.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/mm/mempolicy.c
++++ b/mm/mempolicy.c
+@@ -600,7 +600,8 @@ static int queue_pages_hugetlb(pte_t *pt
+
+ /* With MPOL_MF_MOVE, we migrate only unshared hugepage. */
+ if (flags & (MPOL_MF_MOVE_ALL) ||
+- (flags & MPOL_MF_MOVE && page_mapcount(page) == 1)) {
++ (flags & MPOL_MF_MOVE && page_mapcount(page) == 1 &&
++ !hugetlb_pmd_shared(pte))) {
+ if (isolate_hugetlb(page, qp->pagelist) &&
+ (flags & MPOL_MF_STRICT))
+ /*
--- /dev/null
+From 023f47a8250c6bdb4aebe744db4bf7f73414028b Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Wed, 11 Jan 2023 14:33:51 +0100
+Subject: mm/khugepaged: fix ->anon_vma race
+
+From: Jann Horn <jannh@google.com>
+
+commit 023f47a8250c6bdb4aebe744db4bf7f73414028b upstream.
+
+If an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires
+it to be locked.
+
+Page table traversal is allowed under any one of the mmap lock, the
+anon_vma lock (if the VMA is associated with an anon_vma), and the
+mapping lock (if the VMA is associated with a mapping); and so to be
+able to remove page tables, we must hold all three of them.
+retract_page_tables() bails out if an ->anon_vma is attached, but does
+this check before holding the mmap lock (as the comment above the check
+explains).
+
+If we racily merged an existing ->anon_vma (shared with a child
+process) from a neighboring VMA, subsequent rmap traversals on pages
+belonging to the child will be able to see the page tables that we are
+concurrently removing while assuming that nothing else can access them.
+
+Repeat the ->anon_vma check once we hold the mmap lock to ensure that
+there really is no concurrent page table access.
+
+Hitting this bug causes a lockdep warning in collapse_and_free_pmd(),
+in the line "lockdep_assert_held_write(&vma->anon_vma->root->rwsem)".
+It can also lead to use-after-free access.
+
+Link: https://lore.kernel.org/linux-mm/CAG48ez3434wZBKFFbdx4M9j6eUwSUVPd4dxhzW_k_POneSDF+A@mail.gmail.com/
+Link: https://lkml.kernel.org/r/20230111133351.807024-1-jannh@google.com
+Fixes: f3f0e1d2150b ("khugepaged: add support of collapse for tmpfs/shmem pages")
+Signed-off-by: Jann Horn <jannh@google.com>
+Reported-by: Zach O'Keefe <zokeefe@google.com>
+Acked-by: Kirill A. Shutemov <kirill.shutemov@intel.linux.com>
+Reviewed-by: Yang Shi <shy828301@gmail.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/khugepaged.c | 14 +++++++++++++-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+--- a/mm/khugepaged.c
++++ b/mm/khugepaged.c
+@@ -1649,7 +1649,7 @@ static int retract_page_tables(struct ad
+ * has higher cost too. It would also probably require locking
+ * the anon_vma.
+ */
+- if (vma->anon_vma) {
++ if (READ_ONCE(vma->anon_vma)) {
+ result = SCAN_PAGE_ANON;
+ goto next;
+ }
+@@ -1678,6 +1678,18 @@ static int retract_page_tables(struct ad
+ if ((cc->is_khugepaged || is_target) &&
+ mmap_write_trylock(mm)) {
+ /*
++ * Re-check whether we have an ->anon_vma, because
++ * collapse_and_free_pmd() requires that either no
++ * ->anon_vma exists or the anon_vma is locked.
++ * We already checked ->anon_vma above, but that check
++ * is racy because ->anon_vma can be populated under the
++ * mmap lock in read mode.
++ */
++ if (vma->anon_vma) {
++ result = SCAN_PAGE_ANON;
++ goto unlock_next;
++ }
++ /*
+ * When a vma is registered with uffd-wp, we can't
+ * recycle the pmd pgtable because there can be pte
+ * markers installed. Skip it only, so the rest mm/vma
--- /dev/null
+From edb5d0cf5525357652aff6eacd9850b8ced07143 Mon Sep 17 00:00:00 2001
+From: Zach O'Keefe <zokeefe@google.com>
+Date: Wed, 25 Jan 2023 14:53:58 -0800
+Subject: mm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups
+
+From: Zach O'Keefe <zokeefe@google.com>
+
+commit edb5d0cf5525357652aff6eacd9850b8ced07143 upstream.
+
+In commit 34488399fa08 ("mm/madvise: add file and shmem support to
+MADV_COLLAPSE") we make the following change to find_pmd_or_thp_or_none():
+
+ - if (!pmd_present(pmde))
+ - return SCAN_PMD_NULL;
+ + if (pmd_none(pmde))
+ + return SCAN_PMD_NONE;
+
+This was for-use by MADV_COLLAPSE file/shmem codepaths, where
+MADV_COLLAPSE might identify a pte-mapped hugepage, only to have
+khugepaged race-in, free the pte table, and clear the pmd. Such codepaths
+include:
+
+A) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER
+ already in the pagecache.
+B) In retract_page_tables(), if we fail to grab mmap_lock for the target
+ mm/address.
+
+In these cases, collapse_pte_mapped_thp() really does expect a none (not
+just !present) pmd, and we want to suitably identify that case separate
+from the case where no pmd is found, or it's a bad-pmd (of course, many
+things could happen once we drop mmap_lock, and the pmd could plausibly
+undergo multiple transitions due to intervening fault, split, etc).
+Regardless, the code is prepared install a huge-pmd only when the existing
+pmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.
+
+However, the commit introduces a logical hole; namely, that we've allowed
+!none- && !huge- && !bad-pmds to be classified as genuine
+pte-table-mapping-pmds. One such example that could leak through are swap
+entries. The pmd values aren't checked again before use in
+pte_offset_map_lock(), which is expecting nothing less than a genuine
+pte-table-mapping-pmd.
+
+We want to put back the !pmd_present() check (below the pmd_none() check),
+but need to be careful to deal with subtleties in pmd transitions and
+treatments by various arch.
+
+The issue is that __split_huge_pmd_locked() temporarily clears the present
+bit (or otherwise marks the entry as invalid), but pmd_present() and
+pmd_trans_huge() still need to return true while the pmd is in this
+transitory state. For example, x86's pmd_present() also checks the
+_PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also
+checks a PMD_PRESENT_INVALID bit.
+
+Covering all 4 cases for x86 (all checks done on the same pmd value):
+
+1) pmd_present() && pmd_trans_huge()
+ All we actually know here is that the PSE bit is set. Either:
+ a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE
+ is set.
+ => huge-pmd
+ b) We are currently racing with __split_huge_page(). The danger here
+ is that we proceed as-if we have a huge-pmd, but really we are
+ looking at a pte-mapping-pmd. So, what is the risk of this
+ danger?
+
+ The only relevant path is:
+
+ madvise_collapse() -> collapse_pte_mapped_thp()
+
+ Where we might just incorrectly report back "success", when really
+ the memory isn't pmd-backed. This is fine, since split could
+ happen immediately after (actually) successful madvise_collapse().
+ So, it should be safe to just assume huge-pmd here.
+
+2) pmd_present() && !pmd_trans_huge()
+ Either:
+ a) PSE not set and either PRESENT or PROTNONE is.
+ => pte-table-mapping pmd (or PROT_NONE)
+ b) devmap. This routine can be called immediately after
+ unlocking/locking mmap_lock -- or called with no locks held (see
+ khugepaged_scan_mm_slot()), so previous VMA checks have since been
+ invalidated.
+
+3) !pmd_present() && pmd_trans_huge()
+ Not possible.
+
+4) !pmd_present() && !pmd_trans_huge()
+ Neither PRESENT nor PROTNONE set
+ => not present
+
+I've checked all archs that implement pmd_trans_huge() (arm64, riscv,
+powerpc, longarch, x86, mips, s390) and this logic roughly translates
+(though devmap treatment is unique to x86 and powerpc, and (3) doesn't
+necessarily hold in general -- but that doesn't matter since
+!pmd_present() always takes failure path).
+
+Also, add a comment above find_pmd_or_thp_or_none() to help future
+travelers reason about the validity of the code; namely, the possible
+mutations that might happen out from under us, depending on how mmap_lock
+is held (if at all).
+
+Link: https://lkml.kernel.org/r/20230125225358.2576151-1-zokeefe@google.com
+Fixes: 34488399fa08 ("mm/madvise: add file and shmem support to MADV_COLLAPSE")
+Signed-off-by: Zach O'Keefe <zokeefe@google.com>
+Reported-by: Hugh Dickins <hughd@google.com>
+Reviewed-by: Yang Shi <shy828301@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/khugepaged.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/mm/khugepaged.c b/mm/khugepaged.c
+index 935aa8b71d1c..90acfea40c13 100644
+--- a/mm/khugepaged.c
++++ b/mm/khugepaged.c
+@@ -847,6 +847,10 @@ static int hugepage_vma_revalidate(struct mm_struct *mm, unsigned long address,
+ return SCAN_SUCCEED;
+ }
+
++/*
++ * See pmd_trans_unstable() for how the result may change out from
++ * underneath us, even if we hold mmap_lock in read.
++ */
+ static int find_pmd_or_thp_or_none(struct mm_struct *mm,
+ unsigned long address,
+ pmd_t **pmd)
+@@ -865,8 +869,12 @@ static int find_pmd_or_thp_or_none(struct mm_struct *mm,
+ #endif
+ if (pmd_none(pmde))
+ return SCAN_PMD_NONE;
++ if (!pmd_present(pmde))
++ return SCAN_PMD_NULL;
+ if (pmd_trans_huge(pmde))
+ return SCAN_PMD_MAPPED;
++ if (pmd_devmap(pmde))
++ return SCAN_PMD_NULL;
+ if (pmd_bad(pmde))
+ return SCAN_PMD_NULL;
+ return SCAN_SUCCEED;
+--
+2.39.1
+
--- /dev/null
+From d014cd7c1c358edc3ea82ebf327a036a42ed0164 Mon Sep 17 00:00:00 2001
+From: Vlastimil Babka <vbabka@suse.cz>
+Date: Tue, 17 Jan 2023 11:19:39 +0100
+Subject: mm, mremap: fix mremap() expanding for vma's with vm_ops->close()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Vlastimil Babka <vbabka@suse.cz>
+
+commit d014cd7c1c358edc3ea82ebf327a036a42ed0164 upstream.
+
+Fabian has reported another regression in 6.1 due to ca3d76b0aa80 ("mm:
+add merging after mremap resize"). The problem is that vma_merge() can
+fail when vma has a vm_ops->close() method, causing is_mergeable_vma()
+test to be negative. This was happening for vma mapping a file from
+fuse-overlayfs, which does have the method. But when we are simply
+expanding the vma, we never remove it due to the "merge" with the added
+area, so the test should not prevent the expansion.
+
+As a quick fix, check for such vmas and expand them using vma_adjust()
+directly as was done before commit ca3d76b0aa80. For a more robust long
+term solution we should try to limit the check for vma_ops->close only to
+cases that actually result in vma removal, so that no merge would be
+prevented unnecessarily.
+
+[akpm@linux-foundation.org: fix indenting whitespace, reflow comment]
+Link: https://lkml.kernel.org/r/20230117101939.9753-1-vbabka@suse.cz
+Fixes: ca3d76b0aa80 ("mm: add merging after mremap resize")
+Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+Reported-by: Fabian Vogt <fvogt@suse.com>
+ Link: https://bugzilla.suse.com/show_bug.cgi?id=1206359#c35
+Tested-by: Fabian Vogt <fvogt@suse.com>
+Cc: Jakub Matěna <matenajakub@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/mremap.c | 25 +++++++++++++++++++------
+ 1 file changed, 19 insertions(+), 6 deletions(-)
+
+diff --git a/mm/mremap.c b/mm/mremap.c
+index fe587c5d6591..930f65c315c0 100644
+--- a/mm/mremap.c
++++ b/mm/mremap.c
+@@ -1027,16 +1027,29 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
+ }
+
+ /*
+- * Function vma_merge() is called on the extension we are adding to
+- * the already existing vma, vma_merge() will merge this extension with
+- * the already existing vma (expand operation itself) and possibly also
+- * with the next vma if it becomes adjacent to the expanded vma and
+- * otherwise compatible.
++ * Function vma_merge() is called on the extension we
++ * are adding to the already existing vma, vma_merge()
++ * will merge this extension with the already existing
++ * vma (expand operation itself) and possibly also with
++ * the next vma if it becomes adjacent to the expanded
++ * vma and otherwise compatible.
++ *
++ * However, vma_merge() can currently fail due to
++ * is_mergeable_vma() check for vm_ops->close (see the
++ * comment there). Yet this should not prevent vma
++ * expanding, so perform a simple expand for such vma.
++ * Ideally the check for close op should be only done
++ * when a vma would be actually removed due to a merge.
+ */
+- vma = vma_merge(mm, vma, extension_start, extension_end,
++ if (!vma->vm_ops || !vma->vm_ops->close) {
++ vma = vma_merge(mm, vma, extension_start, extension_end,
+ vma->vm_flags, vma->anon_vma, vma->vm_file,
+ extension_pgoff, vma_policy(vma),
+ vma->vm_userfaultfd_ctx, anon_vma_name(vma));
++ } else if (vma_adjust(vma, vma->vm_start, addr + new_len,
++ vma->vm_pgoff, NULL)) {
++ vma = NULL;
++ }
+ if (!vma) {
+ vm_unacct_memory(pages);
+ ret = -ENOMEM;
+--
+2.39.1
+
--- /dev/null
+From 7717fc1a12f88701573f9ed897cc4f6699c661e3 Mon Sep 17 00:00:00 2001
+From: Longlong Xia <xialonglong1@huawei.com>
+Date: Sat, 28 Jan 2023 09:47:57 +0000
+Subject: mm/swapfile: add cond_resched() in get_swap_pages()
+
+From: Longlong Xia <xialonglong1@huawei.com>
+
+commit 7717fc1a12f88701573f9ed897cc4f6699c661e3 upstream.
+
+The softlockup still occurs in get_swap_pages() under memory pressure. 64
+CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram
+device is 50MB with same priority as si. Use the stress-ng tool to
+increase memory pressure, causing the system to oom frequently.
+
+The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens
+of thousands of times to find available space (extreme case:
+cond_resched() is not called in scan_swap_map_slots()). Let's add
+cond_resched() into get_swap_pages() when failed to find available space
+to avoid softlockup.
+
+Link: https://lkml.kernel.org/r/20230128094757.1060525-1-xialonglong1@huawei.com
+Signed-off-by: Longlong Xia <xialonglong1@huawei.com>
+Reviewed-by: "Huang, Ying" <ying.huang@intel.com>
+Cc: Chen Wandun <chenwandun@huawei.com>
+Cc: Huang Ying <ying.huang@intel.com>
+Cc: Kefeng Wang <wangkefeng.wang@huawei.com>
+Cc: Nanyong Sun <sunnanyong@huawei.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/swapfile.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/mm/swapfile.c
++++ b/mm/swapfile.c
+@@ -1101,6 +1101,7 @@ start_over:
+ goto check_out;
+ pr_debug("scan_swap_map of si %d failed to find offset\n",
+ si->type);
++ cond_resched();
+
+ spin_lock(&swap_avail_lock);
+ nextsi:
--- /dev/null
+From 49d6d7fb631345b0f2957a7c4be24ad63903150f Mon Sep 17 00:00:00 2001
+From: Peter Xu <peterx@redhat.com>
+Date: Wed, 14 Dec 2022 15:04:52 -0500
+Subject: mm/uffd: fix pte marker when fork() without fork event
+
+From: Peter Xu <peterx@redhat.com>
+
+commit 49d6d7fb631345b0f2957a7c4be24ad63903150f upstream.
+
+Patch series "mm: Fixes on pte markers".
+
+Patch 1 resolves the syzkiller report from Pengfei.
+
+Patch 2 further harden pte markers when used with the recent swapin error
+markers. The major case is we should persist a swapin error marker after
+fork(), so child shouldn't read a corrupted page.
+
+
+This patch (of 2):
+
+When fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may
+have it and has pte marker installed. The warning is improper along with
+the comment. The right thing is to inherit the pte marker when needed, or
+keep the dst pte empty.
+
+A vague guess is this happened by an accident when there's the prior patch
+to introduce src/dst vma into this helper during the uffd-wp feature got
+developed and I probably messed up in the rebase, since if we replace
+dst_vma with src_vma the warning & comment it all makes sense too.
+
+Hugetlb did exactly the right here (copy_hugetlb_page_range()). Fix the
+general path.
+
+Reproducer:
+
+https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c
+
+Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808
+
+Link: https://lkml.kernel.org/r/20221214200453.1772655-1-peterx@redhat.com
+Link: https://lkml.kernel.org/r/20221214200453.1772655-2-peterx@redhat.com
+Fixes: c56d1b62cce8 ("mm/shmem: handle uffd-wp during fork()")
+Signed-off-by: Peter Xu <peterx@redhat.com>
+Reported-by: Pengfei Xu <pengfei.xu@intel.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: Miaohe Lin <linmiaohe@huawei.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: "Huang, Ying" <ying.huang@intel.com>
+Cc: Nadav Amit <nadav.amit@gmail.com>
+Cc: <stable@vger.kernel.org> # 5.19+
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory.c | 8 ++------
+ 1 file changed, 2 insertions(+), 6 deletions(-)
+
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@ -875,12 +875,8 @@ copy_nonpresent_pte(struct mm_struct *ds
+ return -EBUSY;
+ return -ENOENT;
+ } else if (is_pte_marker_entry(entry)) {
+- /*
+- * We're copying the pgtable should only because dst_vma has
+- * uffd-wp enabled, do sanity check.
+- */
+- WARN_ON_ONCE(!userfaultfd_wp(dst_vma));
+- set_pte_at(dst_mm, addr, dst_pte, pte);
++ if (userfaultfd_wp(dst_vma))
++ set_pte_at(dst_mm, addr, dst_pte, pte);
+ return 0;
+ }
+ if (!userfaultfd_wp(dst_vma))
--- /dev/null
+From 3f6c02fa712bd453871877fe1d1969625617471e Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marex@denx.de>
+Date: Fri, 20 Jan 2023 17:03:32 +0100
+Subject: serial: stm32: Merge hard IRQ and threaded IRQ handling into single IRQ handler
+
+From: Marek Vasut <marex@denx.de>
+
+commit 3f6c02fa712bd453871877fe1d1969625617471e upstream.
+
+Requesting an interrupt with IRQF_ONESHOT will run the primary handler
+in the hard-IRQ context even in the force-threaded mode. The
+force-threaded mode is used by PREEMPT_RT in order to avoid acquiring
+sleeping locks (spinlock_t) in hard-IRQ context. This combination
+makes it impossible and leads to "sleeping while atomic" warnings.
+
+Use one interrupt handler for both handlers (primary and secondary)
+and drop the IRQF_ONESHOT flag which is not needed.
+
+Fixes: e359b4411c283 ("serial: stm32: fix threaded interrupt handling")
+Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Tested-by: Valentin Caron <valentin.caron@foss.st.com> # V3
+Signed-off-by: Marek Vasut <marex@denx.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20230120160332.57930-1-marex@denx.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/stm32-usart.c | 33 +++++----------------------------
+ 1 file changed, 5 insertions(+), 28 deletions(-)
+
+--- a/drivers/tty/serial/stm32-usart.c
++++ b/drivers/tty/serial/stm32-usart.c
+@@ -798,25 +798,11 @@ static irqreturn_t stm32_usart_interrupt
+ spin_unlock(&port->lock);
+ }
+
+- if (stm32_usart_rx_dma_enabled(port))
+- return IRQ_WAKE_THREAD;
+- else
+- return IRQ_HANDLED;
+-}
+-
+-static irqreturn_t stm32_usart_threaded_interrupt(int irq, void *ptr)
+-{
+- struct uart_port *port = ptr;
+- struct tty_port *tport = &port->state->port;
+- struct stm32_port *stm32_port = to_stm32_port(port);
+- unsigned int size;
+- unsigned long flags;
+-
+ /* Receiver timeout irq for DMA RX */
+- if (!stm32_port->throttled) {
+- spin_lock_irqsave(&port->lock, flags);
++ if (stm32_usart_rx_dma_enabled(port) && !stm32_port->throttled) {
++ spin_lock(&port->lock);
+ size = stm32_usart_receive_chars(port, false);
+- uart_unlock_and_check_sysrq_irqrestore(port, flags);
++ uart_unlock_and_check_sysrq(port);
+ if (size)
+ tty_flip_buffer_push(tport);
+ }
+@@ -1016,10 +1002,8 @@ static int stm32_usart_startup(struct ua
+ u32 val;
+ int ret;
+
+- ret = request_threaded_irq(port->irq, stm32_usart_interrupt,
+- stm32_usart_threaded_interrupt,
+- IRQF_ONESHOT | IRQF_NO_SUSPEND,
+- name, port);
++ ret = request_irq(port->irq, stm32_usart_interrupt,
++ IRQF_NO_SUSPEND, name, port);
+ if (ret)
+ return ret;
+
+@@ -1602,13 +1586,6 @@ static int stm32_usart_of_dma_rx_probe(s
+ struct dma_slave_config config;
+ int ret;
+
+- /*
+- * Using DMA and threaded handler for the console could lead to
+- * deadlocks.
+- */
+- if (uart_console(port))
+- return -ENODEV;
+-
+ stm32port->rx_buf = dma_alloc_coherent(dev, RX_BUF_L,
+ &stm32port->rx_dma_buf,
+ GFP_KERNEL);
kernel-irq-irqdomain.c-fix-memory-leak-with-using-debugfs_lookup.patch
hv-hv_balloon-fix-memory-leak-with-using-debugfs_lookup.patch
x86-debug-fix-stack-recursion-caused-by-wrongly-ordered-dr7-accesses.patch
+fpga-m10bmc-sec-fix-probe-rollback.patch
+fpga-stratix10-soc-fix-return-value-check-in-s10_ops_write_init.patch
+mm-uffd-fix-pte-marker-when-fork-without-fork-event.patch
+mm-swapfile-add-cond_resched-in-get_swap_pages.patch
+mm-khugepaged-fix-anon_vma-race.patch
+mm-mremap-fix-mremap-expanding-for-vma-s-with-vm_ops-close.patch
+mm-madv_collapse-catch-none-huge-bad-pmd-lookups.patch
+highmem-round-down-the-address-passed-to-kunmap_flush_on_unmap.patch
+ia64-fix-build-error-due-to-switch-case-label-appearing-next-to-declaration.patch
+squashfs-fix-handling-and-sanity-checking-of-xattr_ids-count.patch
+maple_tree-fix-mas_empty_area_rev-lower-bound-validation.patch
+migrate-hugetlb-check-for-hugetlb-shared-pmd-in-node-migration.patch
+dma-buf-actually-set-signaling-bit-for-private-stub-fences.patch
+serial-stm32-merge-hard-irq-and-threaded-irq-handling-into-single-irq-handler.patch
+drm-i915-avoid-potential-vm-use-after-free.patch
+drm-i915-fix-potential-bit_17-double-free.patch
+drm-amd-fix-initialization-for-nbio-4.3.0.patch
+drm-amd-pm-drop-unneeded-dpm-features-disablement-for-smu-13.0.4-11.patch
+drm-amdgpu-update-wave-data-type-to-3-for-gfx11.patch
--- /dev/null
+From f65c4bbbd682b0877b669828b4e033b8d5d0a2dc Mon Sep 17 00:00:00 2001
+From: Phillip Lougher <phillip@squashfs.org.uk>
+Date: Fri, 27 Jan 2023 06:18:42 +0000
+Subject: Squashfs: fix handling and sanity checking of xattr_ids count
+
+From: Phillip Lougher <phillip@squashfs.org.uk>
+
+commit f65c4bbbd682b0877b669828b4e033b8d5d0a2dc upstream.
+
+A Sysbot [1] corrupted filesystem exposes two flaws in the handling and
+sanity checking of the xattr_ids count in the filesystem. Both of these
+flaws cause computation overflow due to incorrect typing.
+
+In the corrupted filesystem the xattr_ids value is 4294967071, which
+stored in a signed variable becomes the negative number -225.
+
+Flaw 1 (64-bit systems only):
+
+The signed integer xattr_ids variable causes sign extension.
+
+This causes variable overflow in the SQUASHFS_XATTR_*(A) macros. The
+variable is first multiplied by sizeof(struct squashfs_xattr_id) where the
+type of the sizeof operator is "unsigned long".
+
+On a 64-bit system this is 64-bits in size, and causes the negative number
+to be sign extended and widened to 64-bits and then become unsigned. This
+produces the very large number 18446744073709548016 or 2^64 - 3600. This
+number when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and
+divided by SQUASHFS_METADATA_SIZE overflows and produces a length of 0
+(stored in len).
+
+Flaw 2 (32-bit systems only):
+
+On a 32-bit system the integer variable is not widened by the unsigned
+long type of the sizeof operator (32-bits), and the signedness of the
+variable has no effect due it always being treated as unsigned.
+
+The above corrupted xattr_ids value of 4294967071, when multiplied
+overflows and produces the number 4294963696 or 2^32 - 3400. This number
+when rounded up by SQUASHFS_METADATA_SIZE - 1 (8191 bytes) and divided by
+SQUASHFS_METADATA_SIZE overflows again and produces a length of 0.
+
+The effect of the 0 length computation:
+
+In conjunction with the corrupted xattr_ids field, the filesystem also has
+a corrupted xattr_table_start value, where it matches the end of
+filesystem value of 850.
+
+This causes the following sanity check code to fail because the
+incorrectly computed len of 0 matches the incorrect size of the table
+reported by the superblock (0 bytes).
+
+ len = SQUASHFS_XATTR_BLOCK_BYTES(*xattr_ids);
+ indexes = SQUASHFS_XATTR_BLOCKS(*xattr_ids);
+
+ /*
+ * The computed size of the index table (len bytes) should exactly
+ * match the table start and end points
+ */
+ start = table_start + sizeof(*id_table);
+ end = msblk->bytes_used;
+
+ if (len != (end - start))
+ return ERR_PTR(-EINVAL);
+
+Changing the xattr_ids variable to be "usigned int" fixes the flaw on a
+64-bit system. This relies on the fact the computation is widened by the
+unsigned long type of the sizeof operator.
+
+Casting the variable to u64 in the above macro fixes this flaw on a 32-bit
+system.
+
+It also means 64-bit systems do not implicitly rely on the type of the
+sizeof operator to widen the computation.
+
+[1] https://lore.kernel.org/lkml/000000000000cd44f005f1a0f17f@google.com/
+
+Link: https://lkml.kernel.org/r/20230127061842.10965-1-phillip@squashfs.org.uk
+Fixes: 506220d2ba21 ("squashfs: add more sanity checks in xattr id lookup")
+Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
+Reported-by: <syzbot+082fa4af80a5bb1a9843@syzkaller.appspotmail.com>
+Cc: Alexey Khoroshilov <khoroshilov@ispras.ru>
+Cc: Fedor Pchelkin <pchelkin@ispras.ru>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/squashfs/squashfs_fs.h | 2 +-
+ fs/squashfs/squashfs_fs_sb.h | 2 +-
+ fs/squashfs/xattr.h | 4 ++--
+ fs/squashfs/xattr_id.c | 2 +-
+ 4 files changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/squashfs/squashfs_fs.h
++++ b/fs/squashfs/squashfs_fs.h
+@@ -183,7 +183,7 @@ static inline int squashfs_block_size(__
+ #define SQUASHFS_ID_BLOCK_BYTES(A) (SQUASHFS_ID_BLOCKS(A) *\
+ sizeof(u64))
+ /* xattr id lookup table defines */
+-#define SQUASHFS_XATTR_BYTES(A) ((A) * sizeof(struct squashfs_xattr_id))
++#define SQUASHFS_XATTR_BYTES(A) (((u64) (A)) * sizeof(struct squashfs_xattr_id))
+
+ #define SQUASHFS_XATTR_BLOCK(A) (SQUASHFS_XATTR_BYTES(A) / \
+ SQUASHFS_METADATA_SIZE)
+--- a/fs/squashfs/squashfs_fs_sb.h
++++ b/fs/squashfs/squashfs_fs_sb.h
+@@ -63,7 +63,7 @@ struct squashfs_sb_info {
+ long long bytes_used;
+ unsigned int inodes;
+ unsigned int fragments;
+- int xattr_ids;
++ unsigned int xattr_ids;
+ unsigned int ids;
+ bool panic_on_errors;
+ };
+--- a/fs/squashfs/xattr.h
++++ b/fs/squashfs/xattr.h
+@@ -10,12 +10,12 @@
+
+ #ifdef CONFIG_SQUASHFS_XATTR
+ extern __le64 *squashfs_read_xattr_id_table(struct super_block *, u64,
+- u64 *, int *);
++ u64 *, unsigned int *);
+ extern int squashfs_xattr_lookup(struct super_block *, unsigned int, int *,
+ unsigned int *, unsigned long long *);
+ #else
+ static inline __le64 *squashfs_read_xattr_id_table(struct super_block *sb,
+- u64 start, u64 *xattr_table_start, int *xattr_ids)
++ u64 start, u64 *xattr_table_start, unsigned int *xattr_ids)
+ {
+ struct squashfs_xattr_id_table *id_table;
+
+--- a/fs/squashfs/xattr_id.c
++++ b/fs/squashfs/xattr_id.c
+@@ -56,7 +56,7 @@ int squashfs_xattr_lookup(struct super_b
+ * Read uncompressed xattr id lookup table indexes from disk into memory
+ */
+ __le64 *squashfs_read_xattr_id_table(struct super_block *sb, u64 table_start,
+- u64 *xattr_table_start, int *xattr_ids)
++ u64 *xattr_table_start, unsigned int *xattr_ids)
+ {
+ struct squashfs_sb_info *msblk = sb->s_fs_info;
+ unsigned int len, indexes;
projects / thirdparty / kernel / stable-queue.git / commitdiff
