- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] i2c: lpi2c: Avoid calling clk_get_rate during transfer
by dinglongwei 22 Oct '24

22 Oct '24

From: Alexander Stein <alexander.stein(a)ew.tq-group.com> stable inclusion from stable-v6.9.7 commit 2b42e9587a7a9c7b824e0feb92958f258263963e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACT5O CVE: CVE-2024-40965 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4268254a39484fc11ba991ae148bacbe75d9cc0a ] Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well. Signed-off-by: Alexander Stein <alexander.stein(a)ew.tq-group.com> Reviewed-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Reviewed-by: Andi Shyti <andi.shyti(a)kernel.org> Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/i2c/busses/i2c-imx-lpi2c.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c index 678b30e90492..14473c223cfa 100644 --- a/drivers/i2c/busses/i2c-imx-lpi2c.c +++ b/drivers/i2c/busses/i2c-imx-lpi2c.c @@ -99,6 +99,7 @@ struct lpi2c_imx_struct { __u8 *rx_buf; __u8 *tx_buf; struct completion complete; + unsigned long rate_per; unsigned int msglen; unsigned int delivered; unsigned int block_data; @@ -207,9 +208,7 @@ static int lpi2c_imx_config(struct lpi2c_imx_struct *lpi2c_imx) lpi2c_imx_set_mode(lpi2c_imx); - clk_rate = clk_get_rate(lpi2c_imx->clks[0].clk); - if (!clk_rate) - return -EINVAL; + clk_rate = lpi2c_imx->rate_per; if (lpi2c_imx->mode == HS || lpi2c_imx->mode == ULTRA_FAST) filt = 0; @@ -590,6 +589,20 @@ static int lpi2c_imx_probe(struct platform_device *pdev) if (ret) return ret; + /* + * Lock the parent clock rate to avoid getting parent clock upon + * each transfer + */ + ret = devm_clk_rate_exclusive_get(&pdev->dev, lpi2c_imx->clks[0].clk); + if (ret) + return dev_err_probe(&pdev->dev, ret, + "can't lock I2C peripheral clock rate\n"); + + lpi2c_imx->rate_per = clk_get_rate(lpi2c_imx->clks[0].clk); + if (!lpi2c_imx->rate_per) + return dev_err_probe(&pdev->dev, -EINVAL, + "can't get I2C peripheral clock rate\n"); + pm_runtime_set_autosuspend_delay(&pdev->dev, I2C_PM_TIMEOUT); pm_runtime_use_autosuspend(&pdev->dev); pm_runtime_get_noresume(&pdev->dev); -- 2.17.1

2 1

[PATCH OLK-5.10] soc: qcom: cmd-db: Map shared memory as WC, not WB
by dinglongwei 22 Oct '24

22 Oct '24

From: Volodymyr Babchuk <Volodymyr_Babchuk(a)epam.com> stable inclusion from stable-v5.10.225 commit f5a5a5a0e95f36e2792d48e6e4b64e665eb01374 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAR5ZD CVE: CVE-2024-46689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f9bb896eab221618927ae6a2f1d566567999839d upstream. Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Cc: stable(a)vger.kernel.org # 5.4+ Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk(a)epam.com> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # sc7180 WoA in EL2 Signed-off-by: Maulik Shah <quic_mkshah(a)quicinc.com> Tested-by: Pavankumar Kondeti <quic_pkondeti(a)quicinc.com> Reviewed-by: Caleb Connolly <caleb.connolly(a)linaro.org> Link: https://lore.kernel.org/r/20240718-cmd_db_uncached-v2-1-f6cf53164c90@quicin… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/soc/qcom/cmd-db.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c index fc5610603b17..006bb28e2a6e 100644 --- a/drivers/soc/qcom/cmd-db.c +++ b/drivers/soc/qcom/cmd-db.c @@ -319,7 +319,7 @@ static int cmd_db_dev_probe(struct platform_device *pdev) return -EINVAL; } - cmd_db_header = memremap(rmem->base, rmem->size, MEMREMAP_WB); + cmd_db_header = memremap(rmem->base, rmem->size, MEMREMAP_WC); if (!cmd_db_header) { ret = -ENOMEM; cmd_db_header = NULL; -- 2.17.1

2 1

[PATCH OLK-6.6] btrfs: fix race setting file private on concurrent lseek using same fd
by Yifan Qiao 22 Oct '24

22 Oct '24

From: Filipe Manana <fdmanana(a)suse.com> stable inclusion from stable-v6.6.54 commit f56a6d9c267ec7fa558ede7755551c047b1034cd category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAYQS2 CVE: CVE-2024-47741 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 7ee85f5515e86a4e2a2f51969795920733912bad ] When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future. Fixes: 3c32c7212f16 ("btrfs: use cached state when looking for delalloc ranges with lseek") CC: stable(a)vger.kernel.org # 6.6+ Reviewed-by: Josef Bacik <josef(a)toxicpanda.com> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: ZhangPeng <zhangpeng362(a)huawei.com> Conflicts: fs/btrfs/btrfs_inode.h [Context differences.] Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/btrfs/btrfs_inode.h | 1 + fs/btrfs/ctree.h | 2 ++ fs/btrfs/file.c | 34 +++++++++++++++++++++++++++++++--- 3 files changed, 34 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/btrfs_inode.h b/fs/btrfs/btrfs_inode.h index bda1fdbba666..58c2c863e24c 100644 --- a/fs/btrfs/btrfs_inode.h +++ b/fs/btrfs/btrfs_inode.h @@ -84,6 +84,7 @@ struct btrfs_inode { * the log or not (last_trans, last_sub_trans, last_log_commit, * logged_trans), to access/update new_delalloc_bytes and to update the * VFS' inode number of bytes used. + * Also protects setting struct file::private_data. */ spinlock_t lock; diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h index 06333a74d6c4..f7bb4c34b984 100644 --- a/fs/btrfs/ctree.h +++ b/fs/btrfs/ctree.h @@ -445,6 +445,8 @@ struct btrfs_file_private { void *filldir_buf; u64 last_index; struct extent_state *llseek_cached_state; + /* Task that allocated this structure. */ + struct task_struct *owner_task; }; static inline u32 BTRFS_LEAF_DATA_SIZE(const struct btrfs_fs_info *info) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index 15fd8c00f4c0..fc6c91773bc8 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -3481,7 +3481,7 @@ static bool find_desired_extent_in_hole(struct btrfs_inode *inode, int whence, static loff_t find_desired_extent(struct file *file, loff_t offset, int whence) { struct btrfs_inode *inode = BTRFS_I(file->f_mapping->host); - struct btrfs_file_private *private = file->private_data; + struct btrfs_file_private *private; struct btrfs_fs_info *fs_info = inode->root->fs_info; struct extent_state *cached_state = NULL; struct extent_state **delalloc_cached_state; @@ -3509,7 +3509,19 @@ static loff_t find_desired_extent(struct file *file, loff_t offset, int whence) inode_get_bytes(&inode->vfs_inode) == i_size) return i_size; - if (!private) { + spin_lock(&inode->lock); + private = file->private_data; + spin_unlock(&inode->lock); + + if (private && private->owner_task != current) { + /* + * Not allocated by us, don't use it as its cached state is used + * by the task that allocated it and we don't want neither to + * mess with it nor get incorrect results because it reflects an + * invalid state for the current task. + */ + private = NULL; + } else if (!private) { private = kzalloc(sizeof(*private), GFP_KERNEL); /* * No worries if memory allocation failed. @@ -3517,7 +3529,23 @@ static loff_t find_desired_extent(struct file *file, loff_t offset, int whence) * lseek SEEK_HOLE/DATA calls to a file when there's delalloc, * so everything will still be correct. */ - file->private_data = private; + if (private) { + bool free = false; + + private->owner_task = current; + + spin_lock(&inode->lock); + if (file->private_data) + free = true; + else + file->private_data = private; + spin_unlock(&inode->lock); + + if (free) { + kfree(private); + private = NULL; + } + } } if (private) -- 2.39.2

2 1

[PATCH openEuler-22.03-LTS-SP1] soc: qcom: cmd-db: Map shared memory as WC, not WB
by dinglongwei 22 Oct '24

22 Oct '24

From: Volodymyr Babchuk <Volodymyr_Babchuk(a)epam.com> stable inclusion from stable-v5.10.225 commit f5a5a5a0e95f36e2792d48e6e4b64e665eb01374 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAR5ZD CVE: CVE-2024-46689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f9bb896eab221618927ae6a2f1d566567999839d upstream. Linux does not write into cmd-db region. This region of memory is write protected by XPU. XPU may sometime falsely detect clean cache eviction as "write" into the write protected region leading to secure interrupt which causes an endless loop somewhere in Trust Zone. The only reason it is working right now is because Qualcomm Hypervisor maps the same region as Non-Cacheable memory in Stage 2 translation tables. The issue manifests if we want to use another hypervisor (like Xen or KVM), which does not know anything about those specific mappings. Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WC removes dependency on correct mappings in Stage 2 tables. This patch fixes the issue by updating the mapping to MEMREMAP_WC. I tested this on SA8155P with Xen. Fixes: 312416d9171a ("drivers: qcom: add command DB driver") Cc: stable(a)vger.kernel.org # 5.4+ Signed-off-by: Volodymyr Babchuk <volodymyr_babchuk(a)epam.com> Tested-by: Nikita Travkin <nikita(a)trvn.ru> # sc7180 WoA in EL2 Signed-off-by: Maulik Shah <quic_mkshah(a)quicinc.com> Tested-by: Pavankumar Kondeti <quic_pkondeti(a)quicinc.com> Reviewed-by: Caleb Connolly <caleb.connolly(a)linaro.org> Link: https://lore.kernel.org/r/20240718-cmd_db_uncached-v2-1-f6cf53164c90@quicin… Signed-off-by: Bjorn Andersson <andersson(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/soc/qcom/cmd-db.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/cmd-db.c b/drivers/soc/qcom/cmd-db.c index fc5610603b17..006bb28e2a6e 100644 --- a/drivers/soc/qcom/cmd-db.c +++ b/drivers/soc/qcom/cmd-db.c @@ -319,7 +319,7 @@ static int cmd_db_dev_probe(struct platform_device *pdev) return -EINVAL; } - cmd_db_header = memremap(rmem->base, rmem->size, MEMREMAP_WB); + cmd_db_header = memremap(rmem->base, rmem->size, MEMREMAP_WC); if (!cmd_db_header) { ret = -ENOMEM; cmd_db_header = NULL; -- 2.17.1

2 1

[PATCH openEuler-22.03-LTS-SP1] media: imon: fix access to invalid resource for the second interface
by dinglongwei 22 Oct '24

22 Oct '24

From: Takashi Iwai <tiwai(a)suse.de> stable inclusion from stable-v5.10.202 commit 0f5068519f89d928d6c51100e4b274479123829f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9R4N0 CVE: CVE-2023-52754 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a1766a4fd83befa0b34d932d532e7ebb7fab1fa7 ] imon driver probes two USB interfaces, and at the probe of the second interface, the driver assumes blindly that the first interface got bound with the same imon driver. It's usually true, but it's still possible that the first interface is bound with another driver via a malformed descriptor. Then it may lead to a memory corruption, as spotted by syzkaller; imon driver accesses the data from drvdata as struct imon_context object although it's a completely different one that was assigned by another driver. This patch adds a sanity check -- whether the first interface is really bound with the imon driver or not -- for avoiding the problem above at the probe time. Reported-by: syzbot+59875ffef5cb9c9b29e9(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/000000000000a838aa0603cc74d6@google.com/ Tested-by: Ricardo B. Marliere <ricardo(a)marliere.net> Link: https://lore.kernel.org/r/20230922005152.163640-1-ricardo@marliere.net Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/media/rc/imon.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c index bc9ac6002e25..75e23e21c07e 100644 --- a/drivers/media/rc/imon.c +++ b/drivers/media/rc/imon.c @@ -2430,6 +2430,12 @@ static int imon_probe(struct usb_interface *interface, goto fail; } + if (first_if->dev.driver != interface->dev.driver) { + dev_err(&interface->dev, "inconsistent driver matching\n"); + ret = -EINVAL; + goto fail; + } + if (ifnum == 0) { ictx = imon_init_intf0(interface, id); if (!ictx) { -- 2.17.1

2 1

[PATCH OLK-6.6] bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()
by Pu Lehui 22 Oct '24

22 Oct '24

From: Oleg Nesterov <oleg(a)redhat.com> stable inclusion from stable-v6.6.54 commit 790c630ab0e7d7aba6d186581d4627c09fce60f3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYPJ9 CVE: CVE-2024-47675 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 5fe6e308abaea082c20fbf2aa5df8e14495622cf upstream. If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list. Fixes: 89ae89f53d20 ("bpf: Add multi uprobe link") Closes: https://lore.kernel.org/all/000000000000382d39061f59f2dd@google.com/ Reported-by: syzbot+f7a1c2c2711e4a780f19(a)syzkaller.appspotmail.com Signed-off-by: Oleg Nesterov <oleg(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Acked-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Jiri Olsa <jolsa(a)kernel.org> Tested-by: syzbot+f7a1c2c2711e4a780f19(a)syzkaller.appspotmail.com Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240813152524.GA7292@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/trace/bpf_trace.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c index cc29bf49f715..61e05b2bb384 100644 --- a/kernel/trace/bpf_trace.c +++ b/kernel/trace/bpf_trace.c @@ -3283,17 +3283,20 @@ int bpf_uprobe_multi_link_attach(const union bpf_attr *attr, struct bpf_prog *pr uprobes[i].ref_ctr_offset, &uprobes[i].consumer); if (err) { - bpf_uprobe_unregister(&path, uprobes, i); - goto error_free; + link->cnt = i; + goto error_unregister; } } err = bpf_link_prime(&link->link, &link_primer); if (err) - goto error_free; + goto error_unregister; return bpf_link_settle(&link_primer); +error_unregister: + bpf_uprobe_unregister(&path, uprobes, link->cnt); + error_free: kvfree(uprobes); kfree(link); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS v2 0/8] ACPI&PCI LTS patches 2024.10
by Xiongfeng Wang 22 Oct '24

22 Oct '24

Haibo Xu (1): arm64: ACPI: NUMA: initialize all values of acpi_early_node_map to NUMA_NO_NODE Jonathan Cameron (2): ACPI: processor: Return an error if acpi_processor_get_info() fails in processor_add() ACPI: processor: Fix memory leaks in error paths of processor_add() Justin Stitt (2): ntp: Clamp maxerror and esterror to operating range ntp: Safeguard against time_constant overflow Phil Chang (1): hrtimer: Prevent queuing of hrtimer without a function callback Xiongfeng Wang (1): Revert "ntp: Avoid undefined behaviour in second_overflow()" Zqiang (1): smp: Add missing destroy_work_on_stack() call in smp_call_on_cpu() arch/arm64/kernel/acpi_numa.c | 2 +- drivers/acpi/acpi_processor.c | 15 ++++++++------- kernel/smp.c | 1 + kernel/time/hrtimer.c | 2 ++ kernel/time/ntp.c | 11 ++++------- 5 files changed, 16 insertions(+), 15 deletions(-) -- 2.20.1

2 9

[PATCH OLK-5.10 0/2] CVE-2024-46822
by Heyuan Wang 22 Oct '24

22 Oct '24

From: wangheyuan <wangheyuan2(a)h-partners.com> James Morse (1): arm64: acpi: Move get_cpu_for_acpi_id() to a header Jonathan Cameron (1): arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry arch/arm64/include/asm/acpi.h | 12 ++++++++++++ arch/arm64/kernel/acpi_numa.c | 11 ----------- 2 files changed, 12 insertions(+), 11 deletions(-) -- 2.25.1

2 3

[PATCH openEuler-22.03-LTS-SP1 0/2] CVE-2024-46822
by Heyuan Wang 22 Oct '24

22 Oct '24

From: wangheyuan <wangheyuan2(a)h-partners.com> James Morse (1): arm64: acpi: Move get_cpu_for_acpi_id() to a header Jonathan Cameron (1): arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry arch/arm64/include/asm/acpi.h | 12 ++++++++++++ arch/arm64/kernel/acpi_numa.c | 11 ----------- 2 files changed, 12 insertions(+), 11 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] drivers/perf: Fix ali_drw_pmu driver interrupt status clearing
by Luo Gengkun 22 Oct '24

22 Oct '24

From: Jing Zhang <renyu.zj(a)linux.alibaba.com> mainline inclusion from mainline-v6.12-rc1 commit a3dd920977dccc453c550260c4b7605b280b79c3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYQRS CVE: CVE-2024-47731 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it. Fixes: cf7b61073e45 ("drivers/perf: add DDR Sub-System Driveway PMU driver for Yitian 710 SoC") Signed-off-by: Jing Zhang <renyu.zj(a)linux.alibaba.com> Reviewed-by: Shuai Xue <xueshuai(a)linux.alibaba.com> Acked-by: Mark Rutland <mark.rutland(a)arm.com> Link: https://lore.kernel.org/r/1724297611-20686-1-git-send-email-renyu.zj@linux.… Signed-off-by: Will Deacon <will(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun(a)huaweicloud.com> --- drivers/perf/alibaba_uncore_drw_pmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/perf/alibaba_uncore_drw_pmu.c b/drivers/perf/alibaba_uncore_drw_pmu.c index 19d459a36be5..818ce4424d34 100644 --- a/drivers/perf/alibaba_uncore_drw_pmu.c +++ b/drivers/perf/alibaba_uncore_drw_pmu.c @@ -408,7 +408,7 @@ static irqreturn_t ali_drw_pmu_isr(int irq_num, void *data) } /* clear common counter intr status */ - clr_status = FIELD_PREP(ALI_DRW_PMCOM_CNT_OV_INTR_MASK, 1); + clr_status = FIELD_PREP(ALI_DRW_PMCOM_CNT_OV_INTR_MASK, status); writel(clr_status, drw_pmu->cfg_base + ALI_DRW_PMU_OV_INTR_CLR); } -- 2.34.1

2 1