--- /dev/null
+From b3d6121eaeb22aee8a02f46706745b1968cc0292 Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Mon, 30 Sep 2024 13:04:48 +0100
+Subject: arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+commit b3d6121eaeb22aee8a02f46706745b1968cc0292 upstream.
+
+The Kconfig logic to select HAVE_DYNAMIC_FTRACE_WITH_ARGS is incorrect,
+and HAVE_DYNAMIC_FTRACE_WITH_ARGS may be selected when it is not
+supported by the combination of clang and GNU LD, resulting in link-time
+errors:
+
+ aarch64-linux-gnu-ld: .init.data has both ordered [`__patchable_function_entries' in init/main.o] and unordered [`.meminit.data' in mm/sparse.o] sections
+ aarch64-linux-gnu-ld: final link failed: bad value
+
+... which can be seen when building with CC=clang using a binutils
+version older than 2.36.
+
+We originally fixed that in commit:
+
+ 45bd8951806eb5e8 ("arm64: Improve HAVE_DYNAMIC_FTRACE_WITH_REGS selection for clang")
+
+... by splitting the "select HAVE_DYNAMIC_FTRACE_WITH_ARGS" statement
+into separete CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS and
+GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS options which individually select
+HAVE_DYNAMIC_FTRACE_WITH_ARGS.
+
+Subsequently we accidentally re-introduced the common "select
+HAVE_DYNAMIC_FTRACE_WITH_ARGS" statement in commit:
+
+ 26299b3f6ba26bfc ("ftrace: arm64: move from REGS to ARGS")
+
+... then we removed it again in commit:
+
+ 68a63a412d18bd2e ("arm64: Fix build with CC=clang, CONFIG_FTRACE=y and CONFIG_STACK_TRACER=y")
+
+... then we accidentally re-introduced it again in commit:
+
+ 2aa6ac03516d078c ("arm64: ftrace: Add direct call support")
+
+Fix this for the third time by keeping the unified select statement and
+making this depend onf either GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS or
+CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS. This is more consistent with
+usual style and less likely to go wrong in future.
+
+Fixes: 2aa6ac03516d ("arm64: ftrace: Add direct call support")
+Cc: <stable@vger.kernel.org> # 6.4.x
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Link: https://lore.kernel.org/r/20240930120448.3352564-1-mark.rutland@arm.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/Kconfig | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/arch/arm64/Kconfig
++++ b/arch/arm64/Kconfig
+@@ -191,7 +191,8 @@ config ARM64
+ select HAVE_DMA_CONTIGUOUS
+ select HAVE_DYNAMIC_FTRACE
+ select HAVE_DYNAMIC_FTRACE_WITH_ARGS \
+- if $(cc-option,-fpatchable-function-entry=2)
++ if (GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS || \
++ CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS)
+ select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS \
+ if DYNAMIC_FTRACE_WITH_ARGS && DYNAMIC_FTRACE_WITH_CALL_OPS
+ select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
+@@ -262,12 +263,10 @@ config CLANG_SUPPORTS_DYNAMIC_FTRACE_WIT
+ def_bool CC_IS_CLANG
+ # https://github.com/ClangBuiltLinux/linux/issues/1507
+ depends on AS_IS_GNU || (AS_IS_LLVM && (LD_IS_LLD || LD_VERSION >= 23600))
+- select HAVE_DYNAMIC_FTRACE_WITH_ARGS
+
+ config GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS
+ def_bool CC_IS_GCC
+ depends on $(cc-option,-fpatchable-function-entry=2)
+- select HAVE_DYNAMIC_FTRACE_WITH_ARGS
+
+ config 64BIT
+ def_bool y
--- /dev/null
+From 3eddb108abe3de6723cc4b77e8558ce1b3047987 Mon Sep 17 00:00:00 2001
+From: Easwar Hariharan <eahariha@linux.microsoft.com>
+Date: Thu, 3 Oct 2024 22:52:35 +0000
+Subject: arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386
+
+From: Easwar Hariharan <eahariha@linux.microsoft.com>
+
+commit 3eddb108abe3de6723cc4b77e8558ce1b3047987 upstream.
+
+Add the Microsoft Azure Cobalt 100 CPU to the list of CPUs suffering
+from erratum 3194386 added in commit 75b3c43eab59 ("arm64: errata:
+Expand speculative SSBS workaround")
+
+CC: Mark Rutland <mark.rutland@arm.com>
+CC: James More <james.morse@arm.com>
+CC: Will Deacon <will@kernel.org>
+CC: stable@vger.kernel.org # 6.6+
+Signed-off-by: Easwar Hariharan <eahariha@linux.microsoft.com>
+Link: https://lore.kernel.org/r/20241003225239.321774-1-eahariha@linux.microsoft.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/arch/arm64/silicon-errata.rst | 2 ++
+ arch/arm64/kernel/cpu_errata.c | 1 +
+ 2 files changed, 3 insertions(+)
+
+--- a/Documentation/arch/arm64/silicon-errata.rst
++++ b/Documentation/arch/arm64/silicon-errata.rst
+@@ -280,3 +280,5 @@ stable kernels.
+ +----------------+-----------------+-----------------+-----------------------------+
+ | Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
+ +----------------+-----------------+-----------------+-----------------------------+
++| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 |
+++----------------+-----------------+-----------------+-----------------------------+
+--- a/arch/arm64/kernel/cpu_errata.c
++++ b/arch/arm64/kernel/cpu_errata.c
+@@ -463,6 +463,7 @@ static const struct midr_range erratum_s
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X3),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X4),
+ MIDR_ALL_VERSIONS(MIDR_CORTEX_X925),
++ MIDR_ALL_VERSIONS(MIDR_MICROSOFT_AZURE_COBALT_100),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N1),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N2),
+ MIDR_ALL_VERSIONS(MIDR_NEOVERSE_V1),
--- /dev/null
+From e794b7b9b92977365c693760a259f8eef940c536 Mon Sep 17 00:00:00 2001
+From: Ma Ke <make24@iscas.ac.cn>
+Date: Thu, 8 Aug 2024 14:13:36 +0800
+Subject: drm: omapdrm: Add missing check for alloc_ordered_workqueue
+
+From: Ma Ke <make24@iscas.ac.cn>
+
+commit e794b7b9b92977365c693760a259f8eef940c536 upstream.
+
+As it may return NULL pointer and cause NULL pointer dereference. Add check
+for the return value of alloc_ordered_workqueue.
+
+Cc: stable@vger.kernel.org
+Fixes: 2f95bc6d324a ("drm: omapdrm: Perform initialization/cleanup at probe/remove time")
+Signed-off-by: Ma Ke <make24@iscas.ac.cn>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240808061336.2796729-1-make24@iscas.ac.cn
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/omapdrm/omap_drv.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/gpu/drm/omapdrm/omap_drv.c
++++ b/drivers/gpu/drm/omapdrm/omap_drv.c
+@@ -695,6 +695,10 @@ static int omapdrm_init(struct omap_drm_
+ soc = soc_device_match(omapdrm_soc_devices);
+ priv->omaprev = soc ? (uintptr_t)soc->data : 0;
+ priv->wq = alloc_ordered_workqueue("omapdrm", 0);
++ if (!priv->wq) {
++ ret = -ENOMEM;
++ goto err_alloc_workqueue;
++ }
+
+ mutex_init(&priv->list_lock);
+ INIT_LIST_HEAD(&priv->obj_list);
+@@ -753,6 +757,7 @@ err_gem_deinit:
+ drm_mode_config_cleanup(ddev);
+ omap_gem_deinit(ddev);
+ destroy_workqueue(priv->wq);
++err_alloc_workqueue:
+ omap_disconnect_pipelines(ddev);
+ drm_dev_put(ddev);
+ return ret;
--- /dev/null
+From 6b44aa559d6c7f4ea591ef9d2352a7250138d62a Mon Sep 17 00:00:00 2001
+From: Val Packett <val@packett.cool>
+Date: Mon, 24 Jun 2024 17:40:48 -0300
+Subject: drm/rockchip: vop: clear DMA stop bit on RK3066
+
+From: Val Packett <val@packett.cool>
+
+commit 6b44aa559d6c7f4ea591ef9d2352a7250138d62a upstream.
+
+The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame
+and needs the driver to acknowledge that by clearing the bit.
+
+Unless we clear it "between" frames, the RGB output only shows noise
+instead of the picture. atomic_flush is the place for it that least
+affects other code (doing it on vblank would require converting all
+other usages of the reg_lock to spin_(un)lock_irq, which would affect
+performance for everyone).
+
+This seems to be a redundant synchronization mechanism that was removed
+in later iterations of the VOP hardware block.
+
+Fixes: f4a6de855eae ("drm: rockchip: vop: add rk3066 vop definitions")
+Cc: stable@vger.kernel.org
+Signed-off-by: Val Packett <val@packett.cool>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240624204054.5524-2-val@packett.cool
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 ++++
+ drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 1 +
+ drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
+ 3 files changed, 6 insertions(+)
+
+--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
++++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+@@ -1566,6 +1566,10 @@ static void vop_crtc_atomic_flush(struct
+ VOP_AFBC_SET(vop, enable, s->enable_afbc);
+ vop_cfg_done(vop);
+
++ /* Ack the DMA transfer of the previous frame (RK3066). */
++ if (VOP_HAS_REG(vop, common, dma_stop))
++ VOP_REG_SET(vop, common, dma_stop, 0);
++
+ spin_unlock(&vop->reg_lock);
+
+ /*
+--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
++++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.h
+@@ -122,6 +122,7 @@ struct vop_common {
+ struct vop_reg lut_buffer_index;
+ struct vop_reg gate_en;
+ struct vop_reg mmu_en;
++ struct vop_reg dma_stop;
+ struct vop_reg out_mode;
+ struct vop_reg standby;
+ };
+--- a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
++++ b/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
+@@ -435,6 +435,7 @@ static const struct vop_output rk3066_ou
+ };
+
+ static const struct vop_common rk3066_common = {
++ .dma_stop = VOP_REG(RK3066_SYS_CTRL0, 0x1, 0),
+ .standby = VOP_REG(RK3066_SYS_CTRL0, 0x1, 1),
+ .out_mode = VOP_REG(RK3066_DSP_CTRL0, 0xf, 0),
+ .cfg_done = VOP_REG(RK3066_REG_CFG_DONE, 0x1, 0),
--- /dev/null
+From d2b537b3e533f28e0d97293fe9293161fe8cd137 Mon Sep 17 00:00:00 2001
+From: Yuezhang Mo <Yuezhang.Mo@sony.com>
+Date: Tue, 3 Sep 2024 15:01:09 +0800
+Subject: exfat: fix memory leak in exfat_load_bitmap()
+
+From: Yuezhang Mo <Yuezhang.Mo@sony.com>
+
+commit d2b537b3e533f28e0d97293fe9293161fe8cd137 upstream.
+
+If the first directory entry in the root directory is not a bitmap
+directory entry, 'bh' will not be released and reassigned, which
+will cause a memory leak.
+
+Fixes: 1e49a94cf707 ("exfat: add bitmap operations")
+Cc: stable@vger.kernel.org
+Signed-off-by: Yuezhang Mo <Yuezhang.Mo@sony.com>
+Reviewed-by: Aoyama Wataru <wataru.aoyama@sony.com>
+Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/exfat/balloc.c | 10 +++++-----
+ 1 file changed, 5 insertions(+), 5 deletions(-)
+
+--- a/fs/exfat/balloc.c
++++ b/fs/exfat/balloc.c
+@@ -110,11 +110,8 @@ int exfat_load_bitmap(struct super_block
+ return -EIO;
+
+ type = exfat_get_entry_type(ep);
+- if (type == TYPE_UNUSED)
+- break;
+- if (type != TYPE_BITMAP)
+- continue;
+- if (ep->dentry.bitmap.flags == 0x0) {
++ if (type == TYPE_BITMAP &&
++ ep->dentry.bitmap.flags == 0x0) {
+ int err;
+
+ err = exfat_allocate_bitmap(sb, ep);
+@@ -122,6 +119,9 @@ int exfat_load_bitmap(struct super_block
+ return err;
+ }
+ brelse(bh);
++
++ if (type == TYPE_UNUSED)
++ return -EINVAL;
+ }
+
+ if (exfat_get_next_cluster(sb, &clu.dir))
--- /dev/null
+From 61850725779709369c7e907ae8c7c75dc7cec4f3 Mon Sep 17 00:00:00 2001
+From: Kaixin Wang <kxwang23@m.fudan.edu.cn>
+Date: Sun, 15 Sep 2024 00:39:33 +0800
+Subject: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition
+
+From: Kaixin Wang <kxwang23@m.fudan.edu.cn>
+
+commit 61850725779709369c7e907ae8c7c75dc7cec4f3 upstream.
+
+In the svc_i3c_master_probe function, &master->hj_work is bound with
+svc_i3c_master_hj_work, &master->ibi_work is bound with
+svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the
+hj_work, svc_i3c_master_irq_handler can start the ibi_work.
+
+If we remove the module which will call svc_i3c_master_remove to
+make cleanup, it will free master->base through i3c_master_unregister
+while the work mentioned above will be used. The sequence of operations
+that may lead to a UAF bug is as follows:
+
+CPU0 CPU1
+
+ | svc_i3c_master_hj_work
+svc_i3c_master_remove |
+i3c_master_unregister(&master->base)|
+device_unregister(&master->dev) |
+device_release |
+//free master->base |
+ | i3c_master_do_daa(&master->base)
+ | //use master->base
+
+Fix it by ensuring that the work is canceled before proceeding with the
+cleanup in svc_i3c_master_remove.
+
+Fixes: 0f74f8b6675c ("i3c: Make i3c_master_unregister() return void")
+Cc: stable@vger.kernel.org
+Signed-off-by: Kaixin Wang <kxwang23@m.fudan.edu.cn>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Link: https://lore.kernel.org/stable/20240914154030.180-1-kxwang23%40m.fudan.edu.cn
+Link: https://lore.kernel.org/r/20240914163932.253-1-kxwang23@m.fudan.edu.cn
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/i3c/master/svc-i3c-master.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/i3c/master/svc-i3c-master.c
++++ b/drivers/i3c/master/svc-i3c-master.c
+@@ -1697,6 +1697,7 @@ static void svc_i3c_master_remove(struct
+ {
+ struct svc_i3c_master *master = platform_get_drvdata(pdev);
+
++ cancel_work_sync(&master->hj_work);
+ i3c_master_unregister(&master->base);
+
+ pm_runtime_dont_use_autosuspend(&pdev->dev);
--- /dev/null
+From f0e3c14802515f60a47e6ef347ea59c2733402aa Mon Sep 17 00:00:00 2001
+From: Kemeng Shi <shikemeng@huaweicloud.com>
+Date: Thu, 1 Aug 2024 09:38:08 +0800
+Subject: jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit
+
+From: Kemeng Shi <shikemeng@huaweicloud.com>
+
+commit f0e3c14802515f60a47e6ef347ea59c2733402aa upstream.
+
+Use tid_geq to compare tids to work over sequence number wraps.
+
+Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Zhang Yi <yi.zhang@huawei.com>
+Cc: stable@kernel.org
+Link: https://patch.msgid.link/20240801013815.2393869-2-shikemeng@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jbd2/journal.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/jbd2/journal.c
++++ b/fs/jbd2/journal.c
+@@ -725,7 +725,7 @@ int jbd2_fc_begin_commit(journal_t *jour
+ return -EINVAL;
+
+ write_lock(&journal->j_state_lock);
+- if (tid <= journal->j_commit_sequence) {
++ if (tid_geq(journal->j_commit_sequence, tid)) {
+ write_unlock(&journal->j_state_lock);
+ return -EALREADY;
+ }
--- /dev/null
+From f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a Mon Sep 17 00:00:00 2001
+From: Baokun Li <libaokun1@huawei.com>
+Date: Thu, 18 Jul 2024 19:53:36 +0800
+Subject: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error
+
+From: Baokun Li <libaokun1@huawei.com>
+
+commit f5cacdc6f2bb2a9bf214469dd7112b43dd2dd68a upstream.
+
+In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()
+to recover some journal space. But if an error occurs while executing
+jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free
+space right away, we try other branches, and if j_committing_transaction
+is NULL (i.e., the tid is 0), we will get the following complain:
+
+============================================
+JBD2: I/O error when updating journal superblock for sdd-8.
+__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available
+__jbd2_log_wait_for_space: no way to get more journal space in sdd-8
+------------[ cut here ]------------
+WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0
+Modules linked in:
+CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1
+RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0
+Call Trace:
+ <TASK>
+ add_transaction_credits+0x5d1/0x5e0
+ start_this_handle+0x1ef/0x6a0
+ jbd2__journal_start+0x18b/0x340
+ ext4_dirty_inode+0x5d/0xb0
+ __mark_inode_dirty+0xe4/0x5d0
+ generic_update_time+0x60/0x70
+[...]
+============================================
+
+So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to
+clean up at the moment, continue to try to reclaim free space in other ways.
+
+Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corrupt
+when updating journal superblock fails") to make jbd2_cleanup_journal_tail
+return the correct error code.
+
+Fixes: 8c3f25d8950c ("jbd2: don't give up looking for space so easily in __jbd2_log_wait_for_space")
+Cc: stable@kernel.org
+Signed-off-by: Baokun Li <libaokun1@huawei.com>
+Reviewed-by: Jan Kara <jack@suse.cz>
+Link: https://patch.msgid.link/20240718115336.2554501-1-libaokun@huaweicloud.com
+Signed-off-by: Theodore Ts'o <tytso@mit.edu>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/jbd2/checkpoint.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/fs/jbd2/checkpoint.c
++++ b/fs/jbd2/checkpoint.c
+@@ -89,8 +89,11 @@ __releases(&journal->j_state_lock)
+ write_unlock(&journal->j_state_lock);
+ if (chkpt) {
+ jbd2_log_do_checkpoint(journal);
+- } else if (jbd2_cleanup_journal_tail(journal) == 0) {
+- /* We were able to recover space; yay! */
++ } else if (jbd2_cleanup_journal_tail(journal) <= 0) {
++ /*
++ * We were able to recover space or the
++ * journal was aborted due to an error.
++ */
+ ;
+ } else if (has_transaction) {
+ /*
--- /dev/null
+From 1a83a716ec233990e1fd5b6fbb1200ade63bf450 Mon Sep 17 00:00:00 2001
+From: Danilo Krummrich <dakr@kernel.org>
+Date: Tue, 13 Aug 2024 00:34:34 +0200
+Subject: mm: krealloc: consider spare memory for __GFP_ZERO
+
+From: Danilo Krummrich <dakr@kernel.org>
+
+commit 1a83a716ec233990e1fd5b6fbb1200ade63bf450 upstream.
+
+As long as krealloc() is called with __GFP_ZERO consistently, starting
+with the initial memory allocation, __GFP_ZERO should be fully honored.
+
+However, if for an existing allocation krealloc() is called with a
+decreased size, it is not ensured that the spare portion the allocation is
+zeroed. Thus, if krealloc() is subsequently called with a larger size
+again, __GFP_ZERO can't be fully honored, since we don't know the previous
+size, but only the bucket size.
+
+Example:
+
+ buf = kzalloc(64, GFP_KERNEL);
+ memset(buf, 0xff, 64);
+
+ buf = krealloc(buf, 48, GFP_KERNEL | __GFP_ZERO);
+
+ /* After this call the last 16 bytes are still 0xff. */
+ buf = krealloc(buf, 64, GFP_KERNEL | __GFP_ZERO);
+
+Fix this, by explicitly setting spare memory to zero, when shrinking an
+allocation with __GFP_ZERO flag set or init_on_alloc enabled.
+
+Link: https://lkml.kernel.org/r/20240812223707.32049-1-dakr@kernel.org
+Signed-off-by: Danilo Krummrich <dakr@kernel.org>
+Acked-by: Vlastimil Babka <vbabka@suse.cz>
+Acked-by: David Rientjes <rientjes@google.com>
+Cc: Christoph Lameter <cl@linux.com>
+Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>
+Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
+Cc: Pekka Enberg <penberg@kernel.org>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/slab_common.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/mm/slab_common.c
++++ b/mm/slab_common.c
+@@ -1388,6 +1388,13 @@ __do_krealloc(const void *p, size_t new_
+
+ /* If the object still fits, repoison it precisely. */
+ if (ks >= new_size) {
++ /* Zero out spare memory. */
++ if (want_init_on_alloc(flags)) {
++ kasan_disable_current();
++ memset((void *)p + new_size, 0, ks - new_size);
++ kasan_enable_current();
++ }
++
+ p = kasan_krealloc((void *)p, new_size, flags);
+ return (void *)p;
+ }
--- /dev/null
+From 45bb63ed20e02ae146336412889fe5450316a84f Mon Sep 17 00:00:00 2001
+From: NeilBrown <neilb@suse.de>
+Date: Mon, 9 Sep 2024 15:06:36 +1000
+Subject: nfsd: fix delegation_blocked() to block correctly for at least 30 seconds
+
+From: NeilBrown <neilb@suse.de>
+
+commit 45bb63ed20e02ae146336412889fe5450316a84f upstream.
+
+The pair of bloom filtered used by delegation_blocked() was intended to
+block delegations on given filehandles for between 30 and 60 seconds. A
+new filehandle would be recorded in the "new" bit set. That would then
+be switch to the "old" bit set between 0 and 30 seconds later, and it
+would remain as the "old" bit set for 30 seconds.
+
+Unfortunately the code intended to clear the old bit set once it reached
+30 seconds old, preparing it to be the next new bit set, instead cleared
+the *new* bit set before switching it to be the old bit set. This means
+that the "old" bit set is always empty and delegations are blocked
+between 0 and 30 seconds.
+
+This patch updates bd->new before clearing the set with that index,
+instead of afterwards.
+
+Reported-by: Olga Kornievskaia <okorniev@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 6282cd565553 ("NFSD: Don't hand out delegations for 30 seconds after recalling them.")
+Signed-off-by: NeilBrown <neilb@suse.de>
+Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4state.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -1087,7 +1087,8 @@ static void nfs4_free_deleg(struct nfs4_
+ * When a delegation is recalled, the filehandle is stored in the "new"
+ * filter.
+ * Every 30 seconds we swap the filters and clear the "new" one,
+- * unless both are empty of course.
++ * unless both are empty of course. This results in delegations for a
++ * given filehandle being blocked for between 30 and 60 seconds.
+ *
+ * Each filter is 256 bits. We hash the filehandle to 32bit and use the
+ * low 3 bytes as hash-table indices.
+@@ -1116,9 +1117,9 @@ static int delegation_blocked(struct knf
+ if (ktime_get_seconds() - bd->swap_time > 30) {
+ bd->entries -= bd->old_entries;
+ bd->old_entries = bd->entries;
++ bd->new = 1-bd->new;
+ memset(bd->set[bd->new], 0,
+ sizeof(bd->set[0]));
+- bd->new = 1-bd->new;
+ bd->swap_time = ktime_get_seconds();
+ }
+ spin_unlock(&blocked_delegations_lock);
--- /dev/null
+From 202f39039a11402dcbcd5fece8d9fa6be83f49ae Mon Sep 17 00:00:00 2001
+From: Chuck Lever <chuck.lever@oracle.com>
+Date: Sun, 11 Aug 2024 13:11:07 -0400
+Subject: NFSD: Fix NFSv4's PUTPUBFH operation
+
+From: Chuck Lever <chuck.lever@oracle.com>
+
+commit 202f39039a11402dcbcd5fece8d9fa6be83f49ae upstream.
+
+According to RFC 8881, all minor versions of NFSv4 support PUTPUBFH.
+
+Replace the XDR decoder for PUTPUBFH with a "noop" since we no
+longer want the minorversion check, and PUTPUBFH has no arguments to
+decode. (Ideally nfsd4_decode_noop should really be called
+nfsd4_decode_void).
+
+PUTPUBFH should now behave just like PUTROOTFH.
+
+Reported-by: Cedric Blancher <cedric.blancher@gmail.com>
+Fixes: e1a90ebd8b23 ("NFSD: Combine decode operations for v4 and v4.1")
+Cc: Dan Shelton <dan.f.shelton@gmail.com>
+Cc: Roland Mainz <roland.mainz@nrubsig.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/nfs4xdr.c | 10 +---------
+ 1 file changed, 1 insertion(+), 9 deletions(-)
+
+--- a/fs/nfsd/nfs4xdr.c
++++ b/fs/nfsd/nfs4xdr.c
+@@ -1246,14 +1246,6 @@ nfsd4_decode_putfh(struct nfsd4_compound
+ }
+
+ static __be32
+-nfsd4_decode_putpubfh(struct nfsd4_compoundargs *argp, union nfsd4_op_u *p)
+-{
+- if (argp->minorversion == 0)
+- return nfs_ok;
+- return nfserr_notsupp;
+-}
+-
+-static __be32
+ nfsd4_decode_read(struct nfsd4_compoundargs *argp, union nfsd4_op_u *u)
+ {
+ struct nfsd4_read *read = &u->read;
+@@ -2345,7 +2337,7 @@ static const nfsd4_dec nfsd4_dec_ops[] =
+ [OP_OPEN_CONFIRM] = nfsd4_decode_open_confirm,
+ [OP_OPEN_DOWNGRADE] = nfsd4_decode_open_downgrade,
+ [OP_PUTFH] = nfsd4_decode_putfh,
+- [OP_PUTPUBFH] = nfsd4_decode_putpubfh,
++ [OP_PUTPUBFH] = nfsd4_decode_noop,
+ [OP_PUTROOTFH] = nfsd4_decode_noop,
+ [OP_READ] = nfsd4_decode_read,
+ [OP_READDIR] = nfsd4_decode_readdir,
--- /dev/null
+From 340e61e44c1d2a15c42ec72ade9195ad525fd048 Mon Sep 17 00:00:00 2001
+From: Li Lingfeng <lilingfeng3@huawei.com>
+Date: Sat, 17 Aug 2024 14:27:13 +0800
+Subject: nfsd: map the EBADMSG to nfserr_io to avoid warning
+
+From: Li Lingfeng <lilingfeng3@huawei.com>
+
+commit 340e61e44c1d2a15c42ec72ade9195ad525fd048 upstream.
+
+Ext4 will throw -EBADMSG through ext4_readdir when a checksum error
+occurs, resulting in the following WARNING.
+
+Fix it by mapping EBADMSG to nfserr_io.
+
+nfsd_buffered_readdir
+ iterate_dir // -EBADMSG -74
+ ext4_readdir // .iterate_shared
+ ext4_dx_readdir
+ ext4_htree_fill_tree
+ htree_dirblock_to_tree
+ ext4_read_dirblock
+ __ext4_read_dirblock
+ ext4_dirblock_csum_verify
+ warn_no_space_for_csum
+ __warn_no_space_for_csum
+ return ERR_PTR(-EFSBADCRC) // -EBADMSG -74
+ nfserrno // WARNING
+
+[ 161.115610] ------------[ cut here ]------------
+[ 161.116465] nfsd: non-standard errno: -74
+[ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0
+[ 161.118596] Modules linked in:
+[ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138
+[ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe
+mu.org 04/01/2014
+[ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0
+[ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6
+ 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33
+[ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286
+[ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
+[ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a
+[ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827
+[ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021
+[ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8
+[ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000
+[ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0
+[ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 161.141519] PKRU: 55555554
+[ 161.142076] Call Trace:
+[ 161.142575] ? __warn+0x9b/0x140
+[ 161.143229] ? nfserrno+0x9d/0xd0
+[ 161.143872] ? report_bug+0x125/0x150
+[ 161.144595] ? handle_bug+0x41/0x90
+[ 161.145284] ? exc_invalid_op+0x14/0x70
+[ 161.146009] ? asm_exc_invalid_op+0x12/0x20
+[ 161.146816] ? nfserrno+0x9d/0xd0
+[ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0
+[ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380
+[ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0
+[ 161.150093] ? wait_for_concurrent_writes+0x170/0x170
+[ 161.151004] ? generic_file_llseek_size+0x48/0x160
+[ 161.151895] nfsd_readdir+0x132/0x190
+[ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380
+[ 161.153516] ? nfsd_unlink+0x380/0x380
+[ 161.154256] ? override_creds+0x45/0x60
+[ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0
+[ 161.155850] ? nfsd4_encode_readlink+0x210/0x210
+[ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0
+[ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0
+[ 161.158494] ? lock_downgrade+0x90/0x90
+[ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10
+[ 161.160092] nfsd4_encode_operation+0x15a/0x440
+[ 161.160959] nfsd4_proc_compound+0x718/0xe90
+[ 161.161818] nfsd_dispatch+0x18e/0x2c0
+[ 161.162586] svc_process_common+0x786/0xc50
+[ 161.163403] ? nfsd_svc+0x380/0x380
+[ 161.164137] ? svc_printk+0x160/0x160
+[ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380
+[ 161.165808] ? nfsd_svc+0x380/0x380
+[ 161.166523] ? rcu_is_watching+0x23/0x40
+[ 161.167309] svc_process+0x1a5/0x200
+[ 161.168019] nfsd+0x1f5/0x380
+[ 161.168663] ? nfsd_shutdown_threads+0x260/0x260
+[ 161.169554] kthread+0x1c4/0x210
+[ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80
+[ 161.171246] ret_from_fork+0x1f/0x30
+
+Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
+Reviewed-by: Jeff Layton <jlayton@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfsd/vfs.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/nfsd/vfs.c
++++ b/fs/nfsd/vfs.c
+@@ -101,6 +101,7 @@ nfserrno (int errno)
+ { nfserr_io, -EUCLEAN },
+ { nfserr_perm, -ENOKEY },
+ { nfserr_no_grace, -ENOGRACE},
++ { nfserr_io, -EBADMSG },
+ };
+ int i;
+
--- /dev/null
+From 35fccce29feb3706f649726d410122dd81b92c18 Mon Sep 17 00:00:00 2001
+From: Joseph Qi <joseph.qi@linux.alibaba.com>
+Date: Wed, 4 Sep 2024 15:10:03 +0800
+Subject: ocfs2: cancel dqi_sync_work before freeing oinfo
+
+From: Joseph Qi <joseph.qi@linux.alibaba.com>
+
+commit 35fccce29feb3706f649726d410122dd81b92c18 upstream.
+
+ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the
+end, if error occurs after successfully reading global quota, it will
+trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:
+
+ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c
+
+This reports that there is an active delayed work when freeing oinfo in
+error handling, so cancel dqi_sync_work first. BTW, return status instead
+of -1 when .read_file_info fails.
+
+Link: https://syzkaller.appspot.com/bug?extid=f7af59df5d6b25f0febd
+Link: https://lkml.kernel.org/r/20240904071004.2067695-1-joseph.qi@linux.alibaba.com
+Fixes: 171bf93ce11f ("ocfs2: Periodic quota syncing")
+Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reviewed-by: Heming Zhao <heming.zhao@suse.com>
+Reported-by: syzbot+f7af59df5d6b25f0febd@syzkaller.appspotmail.com
+Tested-by: syzbot+f7af59df5d6b25f0febd@syzkaller.appspotmail.com
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/quota_local.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/ocfs2/quota_local.c
++++ b/fs/ocfs2/quota_local.c
+@@ -689,7 +689,7 @@ static int ocfs2_local_read_info(struct
+ int status;
+ struct buffer_head *bh = NULL;
+ struct ocfs2_quota_recovery *rec;
+- int locked = 0;
++ int locked = 0, global_read = 0;
+
+ info->dqi_max_spc_limit = 0x7fffffffffffffffLL;
+ info->dqi_max_ino_limit = 0x7fffffffffffffffLL;
+@@ -697,6 +697,7 @@ static int ocfs2_local_read_info(struct
+ if (!oinfo) {
+ mlog(ML_ERROR, "failed to allocate memory for ocfs2 quota"
+ " info.");
++ status = -ENOMEM;
+ goto out_err;
+ }
+ info->dqi_priv = oinfo;
+@@ -709,6 +710,7 @@ static int ocfs2_local_read_info(struct
+ status = ocfs2_global_read_info(sb, type);
+ if (status < 0)
+ goto out_err;
++ global_read = 1;
+
+ status = ocfs2_inode_lock(lqinode, &oinfo->dqi_lqi_bh, 1);
+ if (status < 0) {
+@@ -779,10 +781,12 @@ out_err:
+ if (locked)
+ ocfs2_inode_unlock(lqinode, 1);
+ ocfs2_release_local_quota_bitmaps(&oinfo->dqi_chunk);
++ if (global_read)
++ cancel_delayed_work_sync(&oinfo->dqi_sync_work);
+ kfree(oinfo);
+ }
+ brelse(bh);
+- return -1;
++ return status;
+ }
+
+ /* Write local info to quota file */
--- /dev/null
+From 5784d9fcfd43bd853654bb80c87ef293b9e8e80a Mon Sep 17 00:00:00 2001
+From: Julian Sun <sunjunchao2870@gmail.com>
+Date: Mon, 2 Sep 2024 11:08:44 +0800
+Subject: ocfs2: fix null-ptr-deref when journal load failed.
+
+From: Julian Sun <sunjunchao2870@gmail.com>
+
+commit 5784d9fcfd43bd853654bb80c87ef293b9e8e80a upstream.
+
+During the mounting process, if journal_reset() fails because of too short
+journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer.
+Subsequently, ocfs2_journal_shutdown() calls
+jbd2_journal_flush()->jbd2_cleanup_journal_tail()->
+__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()
+->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer
+dereference error.
+
+To resolve this issue, we should check the JBD2_LOADED flag to ensure the
+journal was properly loaded. Additionally, use journal instead of
+osb->journal directly to simplify the code.
+
+Link: https://syzkaller.appspot.com/bug?extid=05b9b39d8bdfe1a0861f
+Link: https://lkml.kernel.org/r/20240902030844.422725-1-sunjunchao2870@gmail.com
+Fixes: f6f50e28f0cb ("jbd2: Fail to load a journal if it is too short")
+Signed-off-by: Julian Sun <sunjunchao2870@gmail.com>
+Reported-by: syzbot+05b9b39d8bdfe1a0861f@syzkaller.appspotmail.com
+Suggested-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/journal.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/fs/ocfs2/journal.c
++++ b/fs/ocfs2/journal.c
+@@ -1055,7 +1055,7 @@ void ocfs2_journal_shutdown(struct ocfs2
+ if (!igrab(inode))
+ BUG();
+
+- num_running_trans = atomic_read(&(osb->journal->j_num_trans));
++ num_running_trans = atomic_read(&(journal->j_num_trans));
+ trace_ocfs2_journal_shutdown(num_running_trans);
+
+ /* Do a commit_cache here. It will flush our journal, *and*
+@@ -1074,9 +1074,10 @@ void ocfs2_journal_shutdown(struct ocfs2
+ osb->commit_task = NULL;
+ }
+
+- BUG_ON(atomic_read(&(osb->journal->j_num_trans)) != 0);
++ BUG_ON(atomic_read(&(journal->j_num_trans)) != 0);
+
+- if (ocfs2_mount_local(osb)) {
++ if (ocfs2_mount_local(osb) &&
++ (journal->j_journal->j_flags & JBD2_LOADED)) {
+ jbd2_journal_lock_updates(journal->j_journal);
+ status = jbd2_journal_flush(journal->j_journal, 0);
+ jbd2_journal_unlock_updates(journal->j_journal);
--- /dev/null
+From 33b525cef4cff49e216e4133cc48452e11c0391e Mon Sep 17 00:00:00 2001
+From: Lizhi Xu <lizhi.xu@windriver.com>
+Date: Mon, 2 Sep 2024 10:36:36 +0800
+Subject: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate
+
+From: Lizhi Xu <lizhi.xu@windriver.com>
+
+commit 33b525cef4cff49e216e4133cc48452e11c0391e upstream.
+
+When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger
+NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if
+bh is NULL.
+
+Link: https://lkml.kernel.org/r/20240902023636.1843422-3-joseph.qi@linux.alibaba.com
+Fixes: cf76c78595ca ("ocfs2: don't put and assigning null to bh allocated outside")
+Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
+Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reported-by: Heming Zhao <heming.zhao@suse.com>
+Suggested-by: Heming Zhao <heming.zhao@suse.com>
+Cc: <stable@vger.kernel.org> [4.20+]
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/buffer_head_io.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/ocfs2/buffer_head_io.c
++++ b/fs/ocfs2/buffer_head_io.c
+@@ -388,7 +388,8 @@ read_failure:
+ /* Always set the buffer in the cache, even if it was
+ * a forced read, or read-ahead which hasn't yet
+ * completed. */
+- ocfs2_set_buffer_uptodate(ci, bh);
++ if (bh)
++ ocfs2_set_buffer_uptodate(ci, bh);
+ }
+ ocfs2_metadata_cache_io_unlock(ci);
+
--- /dev/null
+From dfe6c5692fb525e5e90cefe306ee0dffae13d35f Mon Sep 17 00:00:00 2001
+From: Heming Zhao <heming.zhao@suse.com>
+Date: Fri, 19 Jul 2024 19:43:10 +0800
+Subject: ocfs2: fix the la space leak when unmounting an ocfs2 volume
+
+From: Heming Zhao <heming.zhao@suse.com>
+
+commit dfe6c5692fb525e5e90cefe306ee0dffae13d35f upstream.
+
+This bug has existed since the initial OCFS2 code. The code logic in
+ocfs2_sync_local_to_main() is wrong, as it ignores the last contiguous
+free bits, which causes an OCFS2 volume to lose the last free clusters of
+LA window on each umount command.
+
+Link: https://lkml.kernel.org/r/20240719114310.14245-1-heming.zhao@suse.com
+Signed-off-by: Heming Zhao <heming.zhao@suse.com>
+Reviewed-by: Su Yue <glass.su@suse.com>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: Heming Zhao <heming.zhao@suse.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/localalloc.c | 19 +++++++++++++++++++
+ 1 file changed, 19 insertions(+)
+
+--- a/fs/ocfs2/localalloc.c
++++ b/fs/ocfs2/localalloc.c
+@@ -1008,6 +1008,25 @@ static int ocfs2_sync_local_to_main(stru
+ start = bit_off + 1;
+ }
+
++ /* clear the contiguous bits until the end boundary */
++ if (count) {
++ blkno = la_start_blk +
++ ocfs2_clusters_to_blocks(osb->sb,
++ start - count);
++
++ trace_ocfs2_sync_local_to_main_free(
++ count, start - count,
++ (unsigned long long)la_start_blk,
++ (unsigned long long)blkno);
++
++ status = ocfs2_release_clusters(handle,
++ main_bm_inode,
++ main_bm_bh, blkno,
++ count);
++ if (status < 0)
++ mlog_errno(status);
++ }
++
+ bail:
+ if (status)
+ mlog_errno(status);
--- /dev/null
+From 2af148ef8549a12f8025286b8825c2833ee6bcb8 Mon Sep 17 00:00:00 2001
+From: Joseph Qi <joseph.qi@linux.alibaba.com>
+Date: Wed, 25 Sep 2024 17:06:00 +0800
+Subject: ocfs2: fix uninit-value in ocfs2_get_block()
+
+From: Joseph Qi <joseph.qi@linux.alibaba.com>
+
+commit 2af148ef8549a12f8025286b8825c2833ee6bcb8 upstream.
+
+syzbot reported an uninit-value BUG:
+
+BUG: KMSAN: uninit-value in ocfs2_get_block+0xed2/0x2710 fs/ocfs2/aops.c:159
+ocfs2_get_block+0xed2/0x2710 fs/ocfs2/aops.c:159
+do_mpage_readpage+0xc45/0x2780 fs/mpage.c:225
+mpage_readahead+0x43f/0x840 fs/mpage.c:374
+ocfs2_readahead+0x269/0x320 fs/ocfs2/aops.c:381
+read_pages+0x193/0x1110 mm/readahead.c:160
+page_cache_ra_unbounded+0x901/0x9f0 mm/readahead.c:273
+do_page_cache_ra mm/readahead.c:303 [inline]
+force_page_cache_ra+0x3b1/0x4b0 mm/readahead.c:332
+force_page_cache_readahead mm/internal.h:347 [inline]
+generic_fadvise+0x6b0/0xa90 mm/fadvise.c:106
+vfs_fadvise mm/fadvise.c:185 [inline]
+ksys_fadvise64_64 mm/fadvise.c:199 [inline]
+__do_sys_fadvise64 mm/fadvise.c:214 [inline]
+__se_sys_fadvise64 mm/fadvise.c:212 [inline]
+__x64_sys_fadvise64+0x1fb/0x3a0 mm/fadvise.c:212
+x64_sys_call+0xe11/0x3ba0
+arch/x86/include/generated/asm/syscalls_64.h:222
+do_syscall_x64 arch/x86/entry/common.c:52 [inline]
+do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
+entry_SYSCALL_64_after_hwframe+0x77/0x7f
+
+This is because when ocfs2_extent_map_get_blocks() fails, p_blkno is
+uninitialized. So the error log will trigger the above uninit-value
+access.
+
+The error log is out-of-date since get_blocks() was removed long time ago.
+And the error code will be logged in ocfs2_extent_map_get_blocks() once
+ocfs2_get_cluster() fails, so fix this by only logging inode and block.
+
+Link: https://syzkaller.appspot.com/bug?extid=9709e73bae885b05314b
+Link: https://lkml.kernel.org/r/20240925090600.3643376-1-joseph.qi@linux.alibaba.com
+Fixes: ccd979bdbce9 ("[PATCH] OCFS2: The Second Oracle Cluster Filesystem")
+Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reported-by: syzbot+9709e73bae885b05314b@syzkaller.appspotmail.com
+Tested-by: syzbot+9709e73bae885b05314b@syzkaller.appspotmail.com
+Cc: Heming Zhao <heming.zhao@suse.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/aops.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/fs/ocfs2/aops.c
++++ b/fs/ocfs2/aops.c
+@@ -156,9 +156,8 @@ int ocfs2_get_block(struct inode *inode,
+ err = ocfs2_extent_map_get_blocks(inode, iblock, &p_blkno, &count,
+ &ext_flags);
+ if (err) {
+- mlog(ML_ERROR, "Error %d from get_blocks(0x%p, %llu, 1, "
+- "%llu, NULL)\n", err, inode, (unsigned long long)iblock,
+- (unsigned long long)p_blkno);
++ mlog(ML_ERROR, "get_blocks() failed, inode: 0x%p, "
++ "block: %llu\n", inode, (unsigned long long)iblock);
+ goto bail;
+ }
+
--- /dev/null
+From c03a82b4a0c935774afa01fd6d128b444fd930a1 Mon Sep 17 00:00:00 2001
+From: Lizhi Xu <lizhi.xu@windriver.com>
+Date: Mon, 2 Sep 2024 10:36:35 +0800
+Subject: ocfs2: remove unreasonable unlock in ocfs2_read_blocks
+
+From: Lizhi Xu <lizhi.xu@windriver.com>
+
+commit c03a82b4a0c935774afa01fd6d128b444fd930a1 upstream.
+
+Patch series "Misc fixes for ocfs2_read_blocks", v5.
+
+This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix
+the issue reported by syzbot, which detects bad unlock balance in
+ocfs2_read_blocks(). The second patch fixes an issue reported by Heming
+Zhao when reviewing above fix.
+
+
+This patch (of 2):
+
+There was a lock release before exiting, so remove the unreasonable unlock.
+
+Link: https://lkml.kernel.org/r/20240902023636.1843422-1-joseph.qi@linux.alibaba.com
+Link: https://lkml.kernel.org/r/20240902023636.1843422-2-joseph.qi@linux.alibaba.com
+Fixes: cf76c78595ca ("ocfs2: don't put and assigning null to bh allocated outside")
+Signed-off-by: Lizhi Xu <lizhi.xu@windriver.com>
+Signed-off-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reviewed-by: Heming Zhao <heming.zhao@suse.com>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Reported-by: syzbot+ab134185af9ef88dfed5@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=ab134185af9ef88dfed5
+Tested-by: syzbot+ab134185af9ef88dfed5@syzkaller.appspotmail.com
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org> [4.20+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/buffer_head_io.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/fs/ocfs2/buffer_head_io.c
++++ b/fs/ocfs2/buffer_head_io.c
+@@ -235,7 +235,6 @@ int ocfs2_read_blocks(struct ocfs2_cachi
+ if (bhs[i] == NULL) {
+ bhs[i] = sb_getblk(sb, block++);
+ if (bhs[i] == NULL) {
+- ocfs2_metadata_cache_io_unlock(ci);
+ status = -ENOMEM;
+ mlog_errno(status);
+ /* Don't forget to put previous bh! */
--- /dev/null
+From 5ca60b86f57a4d9648f68418a725b3a7de2816b0 Mon Sep 17 00:00:00 2001
+From: Gautham Ananthakrishna <gautham.ananthakrishna@oracle.com>
+Date: Wed, 18 Sep 2024 06:38:44 +0000
+Subject: ocfs2: reserve space for inline xattr before attaching reflink tree
+
+From: Gautham Ananthakrishna <gautham.ananthakrishna@oracle.com>
+
+commit 5ca60b86f57a4d9648f68418a725b3a7de2816b0 upstream.
+
+One of our customers reported a crash and a corrupted ocfs2 filesystem.
+The crash was due to the detection of corruption. Upon troubleshooting,
+the fsck -fn output showed the below corruption
+
+[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,
+but fsck believes the largest valid value is 227. Clamp the next record value? n
+
+The stat output from the debugfs.ocfs2 showed the following corruption
+where the "Next Free Rec:" had overshot the "Count:" in the root metadata
+block.
+
+ Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856)
+ FS Generation: 904309833 (0x35e6ac49)
+ CRC32: 00000000 ECC: 0000
+ Type: Regular Attr: 0x0 Flags: Valid
+ Dynamic Features: (0x16) HasXattr InlineXattr Refcounted
+ Extended Attributes Block: 0 Extended Attributes Inline Size: 256
+ User: 0 (root) Group: 0 (root) Size: 281320357888
+ Links: 1 Clusters: 141738
+ ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024
+ atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024
+ mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024
+ dtime: 0x0 -- Wed Dec 31 17:00:00 1969
+ Refcount Block: 2777346
+ Last Extblk: 2886943 Orphan Slot: 0
+ Sub Alloc Slot: 0 Sub Alloc Bit: 14
+ Tree Depth: 1 Count: 227 Next Free Rec: 230
+ ## Offset Clusters Block#
+ 0 0 2310 2776351
+ 1 2310 2139 2777375
+ 2 4449 1221 2778399
+ 3 5670 731 2779423
+ 4 6401 566 2780447
+ ....... .... .......
+ ....... .... .......
+
+The issue was in the reflink workfow while reserving space for inline
+xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the
+time this function is called the reflink tree is already recreated at the
+destination inode from the source inode. At this point, this function
+reserves space for inline xattrs at the destination inode without even
+checking if there is space at the root metadata block. It simply reduces
+the l_count from 243 to 227 thereby making space of 256 bytes for inline
+xattr whereas the inode already has extents beyond this index (in this
+case up to 230), thereby causing corruption.
+
+The fix for this is to reserve space for inline metadata at the destination
+inode before the reflink tree gets recreated. The customer has verified the
+fix.
+
+Link: https://lkml.kernel.org/r/20240918063844.1830332-1-gautham.ananthakrishna@oracle.com
+Fixes: ef962df057aa ("ocfs2: xattr: fix inlined xattr reflink")
+Signed-off-by: Gautham Ananthakrishna <gautham.ananthakrishna@oracle.com>
+Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Changwei Ge <gechangwei@live.cn>
+Cc: Gang He <ghe@suse.com>
+Cc: Jun Piao <piaojun@huawei.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ocfs2/refcounttree.c | 26 ++++++++++++++++++++++++--
+ fs/ocfs2/xattr.c | 11 +----------
+ 2 files changed, 25 insertions(+), 12 deletions(-)
+
+--- a/fs/ocfs2/refcounttree.c
++++ b/fs/ocfs2/refcounttree.c
+@@ -25,6 +25,7 @@
+ #include "namei.h"
+ #include "ocfs2_trace.h"
+ #include "file.h"
++#include "symlink.h"
+
+ #include <linux/bio.h>
+ #include <linux/blkdev.h>
+@@ -4155,8 +4156,9 @@ static int __ocfs2_reflink(struct dentry
+ int ret;
+ struct inode *inode = d_inode(old_dentry);
+ struct buffer_head *new_bh = NULL;
++ struct ocfs2_inode_info *oi = OCFS2_I(inode);
+
+- if (OCFS2_I(inode)->ip_flags & OCFS2_INODE_SYSTEM_FILE) {
++ if (oi->ip_flags & OCFS2_INODE_SYSTEM_FILE) {
+ ret = -EINVAL;
+ mlog_errno(ret);
+ goto out;
+@@ -4182,6 +4184,26 @@ static int __ocfs2_reflink(struct dentry
+ goto out_unlock;
+ }
+
++ if ((oi->ip_dyn_features & OCFS2_HAS_XATTR_FL) &&
++ (oi->ip_dyn_features & OCFS2_INLINE_XATTR_FL)) {
++ /*
++ * Adjust extent record count to reserve space for extended attribute.
++ * Inline data count had been adjusted in ocfs2_duplicate_inline_data().
++ */
++ struct ocfs2_inode_info *new_oi = OCFS2_I(new_inode);
++
++ if (!(new_oi->ip_dyn_features & OCFS2_INLINE_DATA_FL) &&
++ !(ocfs2_inode_is_fast_symlink(new_inode))) {
++ struct ocfs2_dinode *new_di = (struct ocfs2_dinode *)new_bh->b_data;
++ struct ocfs2_dinode *old_di = (struct ocfs2_dinode *)old_bh->b_data;
++ struct ocfs2_extent_list *el = &new_di->id2.i_list;
++ int inline_size = le16_to_cpu(old_di->i_xattr_inline_size);
++
++ le16_add_cpu(&el->l_count, -(inline_size /
++ sizeof(struct ocfs2_extent_rec)));
++ }
++ }
++
+ ret = ocfs2_create_reflink_node(inode, old_bh,
+ new_inode, new_bh, preserve);
+ if (ret) {
+@@ -4189,7 +4211,7 @@ static int __ocfs2_reflink(struct dentry
+ goto inode_unlock;
+ }
+
+- if (OCFS2_I(inode)->ip_dyn_features & OCFS2_HAS_XATTR_FL) {
++ if (oi->ip_dyn_features & OCFS2_HAS_XATTR_FL) {
+ ret = ocfs2_reflink_xattrs(inode, old_bh,
+ new_inode, new_bh,
+ preserve);
+--- a/fs/ocfs2/xattr.c
++++ b/fs/ocfs2/xattr.c
+@@ -6520,16 +6520,7 @@ static int ocfs2_reflink_xattr_inline(st
+ }
+
+ new_oi = OCFS2_I(args->new_inode);
+- /*
+- * Adjust extent record count to reserve space for extended attribute.
+- * Inline data count had been adjusted in ocfs2_duplicate_inline_data().
+- */
+- if (!(new_oi->ip_dyn_features & OCFS2_INLINE_DATA_FL) &&
+- !(ocfs2_inode_is_fast_symlink(args->new_inode))) {
+- struct ocfs2_extent_list *el = &new_di->id2.i_list;
+- le16_add_cpu(&el->l_count, -(inline_size /
+- sizeof(struct ocfs2_extent_rec)));
+- }
++
+ spin_lock(&new_oi->ip_lock);
+ new_oi->ip_dyn_features |= OCFS2_HAS_XATTR_FL | OCFS2_INLINE_XATTR_FL;
+ new_di->i_dyn_features = cpu_to_le16(new_oi->ip_dyn_features);
--- /dev/null
+From 000f6d588a8f3d128f89351058dc04d38e54a327 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Thomas=20Wei=C3=9Fschuh?= <thomas.weissschuh@linutronix.de>
+Date: Thu, 5 Sep 2024 09:46:01 +0200
+Subject: of: address: Report error on resource bounds overflow
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+
+commit 000f6d588a8f3d128f89351058dc04d38e54a327 upstream.
+
+The members "start" and "end" of struct resource are of type
+"resource_size_t" which can be 32bit wide.
+Values read from OF however are always 64bit wide.
+Avoid silently truncating the value and instead return an error value.
+
+This can happen on real systems when the DT was created for a
+PAE-enabled kernel and a non-PAE kernel is actually running.
+For example with an arm defconfig and "qemu-system-arm -M virt".
+
+Link: https://bugs.launchpad.net/qemu/+bug/1790975
+Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
+Tested-by: Nam Cao <namcao@linutronix.de>
+Reviewed-by: Nam Cao <namcao@linutronix.de>
+Link: https://lore.kernel.org/r/20240905-of-resource-overflow-v1-1-0cd8bb92cc1f@linutronix.de
+Cc: stable@vger.kernel.org
+Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/of/address.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/of/address.c
++++ b/drivers/of/address.c
+@@ -8,6 +8,7 @@
+ #include <linux/logic_pio.h>
+ #include <linux/module.h>
+ #include <linux/of_address.h>
++#include <linux/overflow.h>
+ #include <linux/pci.h>
+ #include <linux/pci_regs.h>
+ #include <linux/sizes.h>
+@@ -1142,7 +1143,11 @@ static int __of_address_to_resource(stru
+ if (of_mmio_is_nonposted(dev))
+ flags |= IORESOURCE_MEM_NONPOSTED;
+
++ if (overflows_type(taddr, r->start))
++ return -EOVERFLOW;
+ r->start = taddr;
++ if (overflows_type(taddr + size - 1, r->end))
++ return -EOVERFLOW;
+ r->end = taddr + size - 1;
+ r->flags = flags;
+ r->name = name ? name : dev->full_name;
--- /dev/null
+From db8e81132cf051843c9a59b46fa5a071c45baeb3 Mon Sep 17 00:00:00 2001
+From: Andrew Jones <ajones@ventanamicro.com>
+Date: Sat, 17 Aug 2024 09:41:08 +0200
+Subject: of/irq: Support #msi-cells=<0> in of_msi_get_domain
+
+From: Andrew Jones <ajones@ventanamicro.com>
+
+commit db8e81132cf051843c9a59b46fa5a071c45baeb3 upstream.
+
+An 'msi-parent' property with a single entry and no accompanying
+'#msi-cells' property is considered the legacy definition as opposed
+to its definition after being expanded with commit 126b16e2ad98
+("Docs: dt: add generic MSI bindings"). However, the legacy
+definition is completely compatible with the current definition and,
+since of_phandle_iterator_next() tolerates missing and present-but-
+zero *cells properties since commit e42ee61017f5 ("of: Let
+of_for_each_phandle fallback to non-negative cell_count"), there's no
+need anymore to special case the legacy definition in
+of_msi_get_domain().
+
+Indeed, special casing has turned out to be harmful, because, as of
+commit 7c025238b47a ("dt-bindings: irqchip: Describe the IMX MU block
+as a MSI controller"), MSI controller DT bindings have started
+specifying '#msi-cells' as a required property (even when the value
+must be zero) as an effort to make the bindings more explicit. But,
+since the special casing of 'msi-parent' only uses the existence of
+'#msi-cells' for its heuristic, and not whether or not it's also
+nonzero, the legacy path is not taken. Furthermore, the path to
+support the new, broader definition isn't taken either since that
+path has been restricted to the platform-msi bus.
+
+But, neither the definition of 'msi-parent' nor the definition of
+'#msi-cells' is platform-msi-specific (the platform-msi bus was just
+the first bus that needed '#msi-cells'), so remove both the special
+casing and the restriction. The code removal also requires changing
+to of_parse_phandle_with_optional_args() in order to ensure the
+legacy (but compatible) use of 'msi-parent' remains supported. This
+not only simplifies the code but also resolves an issue with PCI
+devices finding their MSI controllers on riscv, as the riscv,imsics
+binding requires '#msi-cells=<0>'.
+
+Signed-off-by: Andrew Jones <ajones@ventanamicro.com>
+Link: https://lore.kernel.org/r/20240817074107.31153-2-ajones@ventanamicro.com
+Cc: stable@vger.kernel.org
+Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/of/irq.c | 34 +++++++---------------------------
+ 1 file changed, 7 insertions(+), 27 deletions(-)
+
+--- a/drivers/of/irq.c
++++ b/drivers/of/irq.c
+@@ -716,8 +716,7 @@ struct irq_domain *of_msi_map_get_device
+ * @np: device node for @dev
+ * @token: bus type for this domain
+ *
+- * Parse the msi-parent property (both the simple and the complex
+- * versions), and returns the corresponding MSI domain.
++ * Parse the msi-parent property and returns the corresponding MSI domain.
+ *
+ * Returns: the MSI domain for this device (or NULL on failure).
+ */
+@@ -725,33 +724,14 @@ struct irq_domain *of_msi_get_domain(str
+ struct device_node *np,
+ enum irq_domain_bus_token token)
+ {
+- struct device_node *msi_np;
++ struct of_phandle_iterator it;
+ struct irq_domain *d;
++ int err;
+
+- /* Check for a single msi-parent property */
+- msi_np = of_parse_phandle(np, "msi-parent", 0);
+- if (msi_np && !of_property_read_bool(msi_np, "#msi-cells")) {
+- d = irq_find_matching_host(msi_np, token);
+- if (!d)
+- of_node_put(msi_np);
+- return d;
+- }
+-
+- if (token == DOMAIN_BUS_PLATFORM_MSI) {
+- /* Check for the complex msi-parent version */
+- struct of_phandle_args args;
+- int index = 0;
+-
+- while (!of_parse_phandle_with_args(np, "msi-parent",
+- "#msi-cells",
+- index, &args)) {
+- d = irq_find_matching_host(args.np, token);
+- if (d)
+- return d;
+-
+- of_node_put(args.np);
+- index++;
+- }
++ of_for_each_phandle(&it, err, np, "msi-parent", "#msi-cells", 0) {
++ d = irq_find_matching_host(it.node, token);
++ if (d)
++ return d;
+ }
+
+ return NULL;
--- /dev/null
+From 5d698966fa7b452035c44c937d704910bf3440dd Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@kernel.org>
+Date: Sun, 8 Sep 2024 20:51:17 +0200
+Subject: parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards
+
+From: Helge Deller <deller@kernel.org>
+
+commit 5d698966fa7b452035c44c937d704910bf3440dd upstream.
+
+When userspace allocates memory with mmap() in order to be used for stack,
+allow this memory region to automatically expand upwards up until the
+current maximum process stack size.
+The fault handler checks if the VM_GROWSUP bit is set in the vm_flags field
+of a memory area before it allows it to expand.
+This patch modifies the parisc specific code only.
+A RFC for a generic patch to modify mmap() for all architectures was sent
+to the mailing list but did not get enough Acks.
+
+Reported-by: Camm Maguire <camm@maguirefamily.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v5.10+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/include/asm/mman.h | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/arch/parisc/include/asm/mman.h
++++ b/arch/parisc/include/asm/mman.h
+@@ -11,4 +11,18 @@ static inline bool arch_memory_deny_writ
+ }
+ #define arch_memory_deny_write_exec_supported arch_memory_deny_write_exec_supported
+
++static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags)
++{
++ /*
++ * The stack on parisc grows upwards, so if userspace requests memory
++ * for a stack, mark it with VM_GROWSUP so that the stack expansion in
++ * the fault handler will work.
++ */
++ if (flags & MAP_STACK)
++ return VM_GROWSUP;
++
++ return 0;
++}
++#define arch_calc_vm_flag_bits(flags) arch_calc_vm_flag_bits(flags)
++
+ #endif /* __ASM_MMAN_H__ */
--- /dev/null
+From d24449864da5838936669618356b0e30ca2999c3 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@kernel.org>
+Date: Sun, 8 Sep 2024 00:40:38 +0200
+Subject: parisc: Fix 64-bit userspace syscall path
+
+From: Helge Deller <deller@kernel.org>
+
+commit d24449864da5838936669618356b0e30ca2999c3 upstream.
+
+Currently the glibc isn't yet ported to 64-bit for hppa, so
+there is no usable userspace available yet.
+But it's possible to manually build a static 64-bit binary
+and run that for testing. One such 64-bit test program is
+available at http://ftp.parisc-linux.org/src/64bit.tar.gz
+and it shows various issues with the existing 64-bit syscall
+path in the kernel.
+This patch fixes those issues.
+
+Signed-off-by: Helge Deller <deller@gmx.de>
+Cc: stable@vger.kernel.org # v4.19+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/parisc/kernel/syscall.S | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+--- a/arch/parisc/kernel/syscall.S
++++ b/arch/parisc/kernel/syscall.S
+@@ -243,10 +243,10 @@ linux_gateway_entry:
+
+ #ifdef CONFIG_64BIT
+ ldil L%sys_call_table, %r1
+- or,= %r2,%r2,%r2
+- addil L%(sys_call_table64-sys_call_table), %r1
++ or,ev %r2,%r2,%r2
++ ldil L%sys_call_table64, %r1
+ ldo R%sys_call_table(%r1), %r19
+- or,= %r2,%r2,%r2
++ or,ev %r2,%r2,%r2
+ ldo R%sys_call_table64(%r1), %r19
+ #else
+ load32 sys_call_table, %r19
+@@ -379,10 +379,10 @@ tracesys_next:
+ extrd,u %r19,63,1,%r2 /* W hidden in bottom bit */
+
+ ldil L%sys_call_table, %r1
+- or,= %r2,%r2,%r2
+- addil L%(sys_call_table64-sys_call_table), %r1
++ or,ev %r2,%r2,%r2
++ ldil L%sys_call_table64, %r1
+ ldo R%sys_call_table(%r1), %r19
+- or,= %r2,%r2,%r2
++ or,ev %r2,%r2,%r2
+ ldo R%sys_call_table64(%r1), %r19
+ #else
+ load32 sys_call_table, %r19
+@@ -1327,6 +1327,8 @@ ENTRY(sys_call_table)
+ END(sys_call_table)
+
+ #ifdef CONFIG_64BIT
++#undef __SYSCALL_WITH_COMPAT
++#define __SYSCALL_WITH_COMPAT(nr, native, compat) __SYSCALL(nr, native)
+ .align 8
+ ENTRY(sys_call_table64)
+ #include <asm/syscall_table_64.h> /* 64-bit syscalls */
--- /dev/null
+From f31b256994acec6929306dfa86ac29716e7503d6 Mon Sep 17 00:00:00 2001
+From: Helge Deller <deller@gmx.de>
+Date: Sat, 7 Sep 2024 18:28:11 +0200
+Subject: parisc: Fix stack start for ADDR_NO_RANDOMIZE personality
+
+From: Helge Deller <deller@gmx.de>
+
+commit f31b256994acec6929306dfa86ac29716e7503d6 upstream.
+
+Fix the stack start address calculation for the parisc architecture in
+setup_arg_pages() when address randomization is disabled. When the
+ADDR_NO_RANDOMIZE process personality is disabled there is no need to add
+additional space for the stack.
+Note that this patch touches code inside an #ifdef CONFIG_STACK_GROWSUP hunk,
+which is why only the parisc architecture is affected since it's the
+only Linux architecture where the stack grows upwards.
+
+Without this patch you will find the stack in the middle of some
+mapped libaries and suddenly limited to 6MB instead of 8MB:
+
+root@parisc:~# setarch -R /bin/bash -c "cat /proc/self/maps"
+00010000-00019000 r-xp 00000000 08:05 1182034 /usr/bin/cat
+00019000-0001a000 rwxp 00009000 08:05 1182034 /usr/bin/cat
+0001a000-0003b000 rwxp 00000000 00:00 0 [heap]
+f90c4000-f9283000 r-xp 00000000 08:05 1573004 /usr/lib/hppa-linux-gnu/libc.so.6
+f9283000-f9285000 r--p 001bf000 08:05 1573004 /usr/lib/hppa-linux-gnu/libc.so.6
+f9285000-f928a000 rwxp 001c1000 08:05 1573004 /usr/lib/hppa-linux-gnu/libc.so.6
+f928a000-f9294000 rwxp 00000000 00:00 0
+f9301000-f9323000 rwxp 00000000 00:00 0 [stack]
+f98b4000-f98e4000 r-xp 00000000 08:05 1572869 /usr/lib/hppa-linux-gnu/ld.so.1
+f98e4000-f98e5000 r--p 00030000 08:05 1572869 /usr/lib/hppa-linux-gnu/ld.so.1
+f98e5000-f98e9000 rwxp 00031000 08:05 1572869 /usr/lib/hppa-linux-gnu/ld.so.1
+f9ad8000-f9b00000 rw-p 00000000 00:00 0
+f9b00000-f9b01000 r-xp 00000000 00:00 0 [vdso]
+
+With the patch the stack gets correctly mapped at the end
+of the process memory map:
+
+root@panama:~# setarch -R /bin/bash -c "cat /proc/self/maps"
+00010000-00019000 r-xp 00000000 08:13 16385582 /usr/bin/cat
+00019000-0001a000 rwxp 00009000 08:13 16385582 /usr/bin/cat
+0001a000-0003b000 rwxp 00000000 00:00 0 [heap]
+fef29000-ff0eb000 r-xp 00000000 08:13 16122400 /usr/lib/hppa-linux-gnu/libc.so.6
+ff0eb000-ff0ed000 r--p 001c2000 08:13 16122400 /usr/lib/hppa-linux-gnu/libc.so.6
+ff0ed000-ff0f2000 rwxp 001c4000 08:13 16122400 /usr/lib/hppa-linux-gnu/libc.so.6
+ff0f2000-ff0fc000 rwxp 00000000 00:00 0
+ff4b4000-ff4e4000 r-xp 00000000 08:13 16121913 /usr/lib/hppa-linux-gnu/ld.so.1
+ff4e4000-ff4e6000 r--p 00030000 08:13 16121913 /usr/lib/hppa-linux-gnu/ld.so.1
+ff4e6000-ff4ea000 rwxp 00032000 08:13 16121913 /usr/lib/hppa-linux-gnu/ld.so.1
+ff6d7000-ff6ff000 rw-p 00000000 00:00 0
+ff6ff000-ff700000 r-xp 00000000 00:00 0 [vdso]
+ff700000-ff722000 rwxp 00000000 00:00 0 [stack]
+
+Reported-by: Camm Maguire <camm@maguirefamily.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Fixes: d045c77c1a69 ("parisc,metag: Fix crashes due to stack randomization on stack-grows-upwards architectures")
+Fixes: 17d9822d4b4c ("parisc: Consider stack randomization for mmap base only when necessary")
+Cc: stable@vger.kernel.org # v5.2+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/exec.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/exec.c
++++ b/fs/exec.c
+@@ -770,7 +770,8 @@ int setup_arg_pages(struct linux_binprm
+ stack_base = calc_max_stack_size(stack_base);
+
+ /* Add space for stack randomization. */
+- stack_base += (STACK_RND_MASK << PAGE_SHIFT);
++ if (current->flags & PF_RANDOMIZE)
++ stack_base += (STACK_RND_MASK << PAGE_SHIFT);
+
+ /* Make sure we didn't let the argument array grow too large. */
+ if (vma->vm_end - vma->vm_start > stack_base)
--- /dev/null
+From ac01c8c4246546fd8340a232f3ada1921dc0ee48 Mon Sep 17 00:00:00 2001
+From: Matt Fleming <matt@readmodwrite.com>
+Date: Thu, 15 Aug 2024 15:22:12 +0100
+Subject: perf hist: Update hist symbol when updating maps
+
+From: Matt Fleming <matt@readmodwrite.com>
+
+commit ac01c8c4246546fd8340a232f3ada1921dc0ee48 upstream.
+
+AddressSanitizer found a use-after-free bug in the symbol code which
+manifested as 'perf top' segfaulting.
+
+ ==1238389==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b00c48844b at pc 0x5650d8035961 bp 0x7f751aaecc90 sp 0x7f751aaecc80
+ READ of size 1 at 0x60b00c48844b thread T193
+ #0 0x5650d8035960 in _sort__sym_cmp util/sort.c:310
+ #1 0x5650d8043744 in hist_entry__cmp util/hist.c:1286
+ #2 0x5650d8043951 in hists__findnew_entry util/hist.c:614
+ #3 0x5650d804568f in __hists__add_entry util/hist.c:754
+ #4 0x5650d8045bf9 in hists__add_entry util/hist.c:772
+ #5 0x5650d8045df1 in iter_add_single_normal_entry util/hist.c:997
+ #6 0x5650d8043326 in hist_entry_iter__add util/hist.c:1242
+ #7 0x5650d7ceeefe in perf_event__process_sample /home/matt/src/linux/tools/perf/builtin-top.c:845
+ #8 0x5650d7ceeefe in deliver_event /home/matt/src/linux/tools/perf/builtin-top.c:1208
+ #9 0x5650d7fdb51b in do_flush util/ordered-events.c:245
+ #10 0x5650d7fdb51b in __ordered_events__flush util/ordered-events.c:324
+ #11 0x5650d7ced743 in process_thread /home/matt/src/linux/tools/perf/builtin-top.c:1120
+ #12 0x7f757ef1f133 in start_thread nptl/pthread_create.c:442
+ #13 0x7f757ef9f7db in clone3 ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
+
+When updating hist maps it's also necessary to update the hist symbol
+reference because the old one gets freed in map__put().
+
+While this bug was probably introduced with 5c24b67aae72f54c ("perf
+tools: Replace map->referenced & maps->removed_maps with map->refcnt"),
+the symbol objects were leaked until c087e9480cf33672 ("perf machine:
+Fix refcount usage when processing PERF_RECORD_KSYMBOL") was merged so
+the bug was masked.
+
+Fixes: c087e9480cf33672 ("perf machine: Fix refcount usage when processing PERF_RECORD_KSYMBOL")
+Reported-by: Yunzhao Li <yunzhao@cloudflare.com>
+Signed-off-by: Matt Fleming (Cloudflare) <matt@readmodwrite.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: kernel-team@cloudflare.com
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Riccardo Mancini <rickyman7@gmail.com>
+Cc: stable@vger.kernel.org # v5.13+
+Link: https://lore.kernel.org/r/20240815142212.3834625-1-matt@readmodwrite.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/perf/util/hist.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/tools/perf/util/hist.c
++++ b/tools/perf/util/hist.c
+@@ -638,6 +638,11 @@ static struct hist_entry *hists__findnew
+ * the history counter to increment.
+ */
+ if (he->ms.map != entry->ms.map) {
++ if (he->ms.sym) {
++ u64 addr = he->ms.sym->start;
++ he->ms.sym = map__find_symbol(entry->ms.map, addr);
++ }
++
+ map__put(he->ms.map);
+ he->ms.map = map__get(entry->ms.map);
+ }
--- /dev/null
+From 00dc514612fe98cfa117193b9df28f15e7c9db9c Mon Sep 17 00:00:00 2001
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+Date: Thu, 22 Aug 2024 14:13:49 -0300
+Subject: perf python: Disable -Wno-cast-function-type-mismatch if present on clang
+
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+
+commit 00dc514612fe98cfa117193b9df28f15e7c9db9c upstream.
+
+The -Wcast-function-type-mismatch option was introduced in clang 19 and
+its enabled by default, since we use -Werror, and python bindings do
+casts that are valid but trips this warning, disable it if present.
+
+Closes: https://lore.kernel.org/all/CA+icZUXoJ6BS3GMhJHV3aZWyb5Cz2haFneX0C5pUMUUhG-UVKQ@mail.gmail.com
+Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
+Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Nathan Chancellor <nathan@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: stable@vger.kernel.org # To allow building with the upcoming clang 19
+Link: https://lore.kernel.org/lkml/CA+icZUVtHn8X1Tb_Y__c-WswsO0K8U9uy3r2MzKXwTA5THtL7w@mail.gmail.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/perf/util/setup.py | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/tools/perf/util/setup.py
++++ b/tools/perf/util/setup.py
+@@ -63,6 +63,8 @@ cflags = getenv('CFLAGS', '').split()
+ cflags += ['-fno-strict-aliasing', '-Wno-write-strings', '-Wno-unused-parameter', '-Wno-redundant-decls', '-DPYTHON_PERF' ]
+ if cc_is_clang:
+ cflags += ["-Wno-unused-command-line-argument" ]
++ if clang_has_option("-Wno-cast-function-type-mismatch"):
++ cflags += ["-Wno-cast-function-type-mismatch" ]
+ else:
+ cflags += ['-Wno-cast-function-type' ]
+
--- /dev/null
+From 4a3b99bc04e501b816db78f70064e26a01257910 Mon Sep 17 00:00:00 2001
+From: Long Li <longli@microsoft.com>
+Date: Fri, 30 Aug 2024 08:16:33 -0700
+Subject: RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page
+
+From: Long Li <longli@microsoft.com>
+
+commit 4a3b99bc04e501b816db78f70064e26a01257910 upstream.
+
+When mapping doorbell page from user-mode, the driver should use the system
+page size as this memory is allocated via mmap() from user-mode.
+
+Cc: stable@vger.kernel.org
+Fixes: 0266a177631d ("RDMA/mana_ib: Add a driver for Microsoft Azure Network Adapter")
+Signed-off-by: Long Li <longli@microsoft.com>
+Link: https://patch.msgid.link/1725030993-16213-2-git-send-email-longli@linuxonhyperv.com
+Signed-off-by: Leon Romanovsky <leon@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/infiniband/hw/mana/main.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/infiniband/hw/mana/main.c
++++ b/drivers/infiniband/hw/mana/main.c
+@@ -460,13 +460,13 @@ int mana_ib_mmap(struct ib_ucontext *ibc
+ PAGE_SHIFT;
+ prot = pgprot_writecombine(vma->vm_page_prot);
+
+- ret = rdma_user_mmap_io(ibcontext, vma, pfn, gc->db_page_size, prot,
++ ret = rdma_user_mmap_io(ibcontext, vma, pfn, PAGE_SIZE, prot,
+ NULL);
+ if (ret)
+ ibdev_dbg(ibdev, "can't rdma_user_mmap_io ret %d\n", ret);
+ else
+- ibdev_dbg(ibdev, "mapped I/O pfn 0x%llx page_size %u, ret %d\n",
+- pfn, gc->db_page_size, ret);
++ ibdev_dbg(ibdev, "mapped I/O pfn 0x%llx page_size %lu, ret %d\n",
++ pfn, PAGE_SIZE, ret);
+
+ return ret;
+ }
--- /dev/null
+From b4afe4183ec77f230851ea139d91e5cf2644c68b Mon Sep 17 00:00:00 2001
+From: Huang Ying <ying.huang@intel.com>
+Date: Fri, 6 Sep 2024 11:07:11 +0800
+Subject: resource: fix region_intersects() vs add_memory_driver_managed()
+
+From: Huang Ying <ying.huang@intel.com>
+
+commit b4afe4183ec77f230851ea139d91e5cf2644c68b upstream.
+
+On a system with CXL memory, the resource tree (/proc/iomem) related to
+CXL memory may look like something as follows.
+
+490000000-50fffffff : CXL Window 0
+ 490000000-50fffffff : region0
+ 490000000-50fffffff : dax0.0
+ 490000000-50fffffff : System RAM (kmem)
+
+Because drivers/dax/kmem.c calls add_memory_driver_managed() during
+onlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXL
+Window X". This confuses region_intersects(), which expects all "System
+RAM" resources to be at the top level of iomem_resource. This can lead to
+bugs.
+
+For example, when the following command line is executed to write some
+memory in CXL memory range via /dev/mem,
+
+ $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1
+ dd: error writing '/dev/mem': Bad address
+ 1+0 records in
+ 0+0 records out
+ 0 bytes copied, 0.0283507 s, 0.0 kB/s
+
+the command fails as expected. However, the error code is wrong. It
+should be "Operation not permitted" instead of "Bad address". More
+seriously, the /dev/mem permission checking in devmem_is_allowed() passes
+incorrectly. Although the accessing is prevented later because ioremap()
+isn't allowed to map system RAM, it is a potential security issue. During
+command executing, the following warning is reported in the kernel log for
+calling ioremap() on system RAM.
+
+ ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff
+ WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d
+ Call Trace:
+ memremap+0xcb/0x184
+ xlate_dev_mem_ptr+0x25/0x2f
+ write_mem+0x94/0xfb
+ vfs_write+0x128/0x26d
+ ksys_write+0xac/0xfe
+ do_syscall_64+0x9a/0xfd
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+
+The details of command execution process are as follows. In the above
+resource tree, "System RAM" is a descendant of "CXL Window 0" instead of a
+top level resource. So, region_intersects() will report no System RAM
+resources in the CXL memory region incorrectly, because it only checks the
+top level resources. Consequently, devmem_is_allowed() will return 1
+(allow access via /dev/mem) for CXL memory region incorrectly.
+Fortunately, ioremap() doesn't allow to map System RAM and reject the
+access.
+
+So, region_intersects() needs to be fixed to work correctly with the
+resource tree with "System RAM" not at top level as above. To fix it, if
+we found a unmatched resource in the top level, we will continue to search
+matched resources in its descendant resources. So, we will not miss any
+matched resources in resource tree anymore.
+
+In the new implementation, an example resource tree
+
+|------------- "CXL Window 0" ------------|
+|-- "System RAM" --|
+
+will behave similar as the following fake resource tree for
+region_intersects(, IORESOURCE_SYSTEM_RAM, ),
+
+|-- "System RAM" --||-- "CXL Window 0a" --|
+
+Where "CXL Window 0a" is part of the original "CXL Window 0" that
+isn't covered by "System RAM".
+
+Link: https://lkml.kernel.org/r/20240906030713.204292-2-ying.huang@intel.com
+Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use like normal RAM")
+Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Davidlohr Bueso <dave@stgolabs.net>
+Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
+Cc: Dave Jiang <dave.jiang@intel.com>
+Cc: Alison Schofield <alison.schofield@intel.com>
+Cc: Vishal Verma <vishal.l.verma@intel.com>
+Cc: Ira Weiny <ira.weiny@intel.com>
+Cc: Alistair Popple <apopple@nvidia.com>
+Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Baoquan He <bhe@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>
+---
+ kernel/resource.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++--------
+ 1 file changed, 50 insertions(+), 8 deletions(-)
+
+--- a/kernel/resource.c
++++ b/kernel/resource.c
+@@ -493,20 +493,62 @@ static int __region_intersects(struct re
+ size_t size, unsigned long flags,
+ unsigned long desc)
+ {
+- struct resource res;
++ resource_size_t ostart, oend;
+ int type = 0; int other = 0;
+- struct resource *p;
++ struct resource *p, *dp;
++ bool is_type, covered;
++ struct resource res;
+
+ res.start = start;
+ res.end = start + size - 1;
+
+ for (p = parent->child; p ; p = p->sibling) {
+- bool is_type = (((p->flags & flags) == flags) &&
+- ((desc == IORES_DESC_NONE) ||
+- (desc == p->desc)));
+-
+- if (resource_overlaps(p, &res))
+- is_type ? type++ : other++;
++ if (!resource_overlaps(p, &res))
++ continue;
++ is_type = (p->flags & flags) == flags &&
++ (desc == IORES_DESC_NONE || desc == p->desc);
++ if (is_type) {
++ type++;
++ continue;
++ }
++ /*
++ * Continue to search in descendant resources as if the
++ * matched descendant resources cover some ranges of 'p'.
++ *
++ * |------------- "CXL Window 0" ------------|
++ * |-- "System RAM" --|
++ *
++ * will behave similar as the following fake resource
++ * tree when searching "System RAM".
++ *
++ * |-- "System RAM" --||-- "CXL Window 0a" --|
++ */
++ covered = false;
++ ostart = max(res.start, p->start);
++ oend = min(res.end, p->end);
++ for_each_resource(p, dp, false) {
++ if (!resource_overlaps(dp, &res))
++ continue;
++ is_type = (dp->flags & flags) == flags &&
++ (desc == IORES_DESC_NONE || desc == dp->desc);
++ if (is_type) {
++ type++;
++ /*
++ * Range from 'ostart' to 'dp->start'
++ * isn't covered by matched resource.
++ */
++ if (dp->start > ostart)
++ break;
++ if (dp->end >= oend) {
++ covered = true;
++ break;
++ }
++ /* Remove covered range */
++ ostart = max(ostart, dp->end + 1);
++ }
++ }
++ if (!covered)
++ other++;
+ }
+
+ if (type == 0)
--- /dev/null
+From 5c178472af247c7b50f962495bb7462ba453b9fb Mon Sep 17 00:00:00 2001
+From: Jisheng Zhang <jszhang@kernel.org>
+Date: Sat, 6 Jul 2024 01:02:10 +0800
+Subject: riscv: define ILLEGAL_POINTER_VALUE for 64bit
+
+From: Jisheng Zhang <jszhang@kernel.org>
+
+commit 5c178472af247c7b50f962495bb7462ba453b9fb upstream.
+
+This is used in poison.h for poison pointer offset. Based on current
+SV39, SV48 and SV57 vm layout, 0xdead000000000000 is a proper value
+that is not mappable, this can avoid potentially turning an oops to
+an expolit.
+
+Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
+Fixes: fbe934d69eb7 ("RISC-V: Build Infrastructure")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240705170210.3236-1-jszhang@kernel.org
+Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/riscv/Kconfig | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/arch/riscv/Kconfig
++++ b/arch/riscv/Kconfig
+@@ -259,6 +259,11 @@ config GENERIC_HWEIGHT
+ config FIX_EARLYCON_MEM
+ def_bool MMU
+
++config ILLEGAL_POINTER_VALUE
++ hex
++ default 0 if 32BIT
++ default 0xdead000000000000 if 64BIT
++
+ config PGTABLE_LEVELS
+ int
+ default 5 if 64BIT
ext4-fix-fast-commit-inode-enqueueing-during-a-full-journal-commit.patch
ext4-use-handle-to-mark-fc-as-ineligible-in-__track_dentry_update.patch
ext4-mark-fc-as-ineligible-using-an-handle-in-ext4_xattr_set.patch
+parisc-fix-64-bit-userspace-syscall-path.patch
+parisc-allow-mmap-map_stack-memory-to-automatically-expand-upwards.patch
+parisc-fix-stack-start-for-addr_no_randomize-personality.patch
+drm-rockchip-vop-clear-dma-stop-bit-on-rk3066.patch
+of-address-report-error-on-resource-bounds-overflow.patch
+of-irq-support-msi-cells-0-in-of_msi_get_domain.patch
+drm-omapdrm-add-missing-check-for-alloc_ordered_workqueue.patch
+resource-fix-region_intersects-vs-add_memory_driver_managed.patch
+jbd2-stop-waiting-for-space-when-jbd2_cleanup_journal_tail-returns-error.patch
+jbd2-correctly-compare-tids-with-tid_geq-function-in-jbd2_fc_begin_commit.patch
+mm-krealloc-consider-spare-memory-for-__gfp_zero.patch
+ocfs2-fix-the-la-space-leak-when-unmounting-an-ocfs2-volume.patch
+ocfs2-fix-uninit-value-in-ocfs2_get_block.patch
+ocfs2-reserve-space-for-inline-xattr-before-attaching-reflink-tree.patch
+ocfs2-cancel-dqi_sync_work-before-freeing-oinfo.patch
+ocfs2-remove-unreasonable-unlock-in-ocfs2_read_blocks.patch
+ocfs2-fix-null-ptr-deref-when-journal-load-failed.patch
+ocfs2-fix-possible-null-ptr-deref-in-ocfs2_set_buffer_uptodate.patch
+arm64-fix-selection-of-have_dynamic_ftrace_with_args.patch
+arm64-subscribe-microsoft-azure-cobalt-100-to-erratum-3194386.patch
+riscv-define-illegal_pointer_value-for-64bit.patch
+exfat-fix-memory-leak-in-exfat_load_bitmap.patch
+perf-python-disable-wno-cast-function-type-mismatch-if-present-on-clang.patch
+perf-hist-update-hist-symbol-when-updating-maps.patch
+nfsd-fix-delegation_blocked-to-block-correctly-for-at-least-30-seconds.patch
+nfsd-map-the-ebadmsg-to-nfserr_io-to-avoid-warning.patch
+nfsd-fix-nfsv4-s-putpubfh-operation.patch
+i3c-master-svc-fix-use-after-free-vulnerability-in-svc_i3c_master-driver-due-to-race-condition.patch
+rdma-mana_ib-use-the-correct-page-size-for-mapping-user-mode-doorbell-page.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
