- Kernel - mailweb.openeuler.org

[PATCH openEuler-1.0-LTS] perf: Fix sample vs do_exit()
by Luo Gengkun 07 Jul '25

07 Jul '25

From: Peter Zijlstra <peterz(a)infradead.org> mainline inclusion from mainline-v6.16-rc3 commit 4f6fc782128355931527cefe3eb45338abd8ab39 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICKFAS Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4f6fc782128355931527cefe3eb45338abd8ab39 ] Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways. The crash further shows perf trying to do a user stack sample while in exit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the address space it is trying to access. It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons. Flip this order by moving up where we stop perf in do_exit(). Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USER to abort when the current task does not have an mm (exit_mm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem. Fixes: c5ebcedb566e ("perf: Add ability to attach user stack dump to sample") Reported-by: Baisheng Gao <baisheng.gao(a)unisoc.com> Suggested-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20250605110815.GQ39944@noisy.programming.kicks-as… Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/events/core.c | 7 +++++++ kernel/exit.c | 17 +++++++++-------- 2 files changed, 16 insertions(+), 8 deletions(-) diff --git a/kernel/events/core.c b/kernel/events/core.c index b7f4aaedb5ff..ff875ddf4aeb 100644 --- a/kernel/events/core.c +++ b/kernel/events/core.c @@ -6101,6 +6101,10 @@ perf_sample_ustack_size(u16 stack_size, u16 header_size, if (!regs) return 0; + /* No mm, no stack, no dump. */ + if (!current->mm) + return 0; + /* * Check if we fit in with the requested stack size into the: * - TASK_SIZE @@ -6563,6 +6567,9 @@ perf_callchain(struct perf_event *event, struct pt_regs *regs) const u32 max_stack = event->attr.sample_max_stack; struct perf_callchain_entry *callchain; + if (!current->mm) + user = false; + if (!kernel && !user) return &__empty_callchain; diff --git a/kernel/exit.c b/kernel/exit.c index 2a32d32bdc03..358a635743ac 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -783,6 +783,15 @@ void __noreturn do_exit(long code) tsk->exit_code = code; taskstats_exit(tsk, group_dead); + /* + * Since sampling can touch ->mm, make sure to stop everything before we + * tear it down. + * + * Also flushes inherited counters to the parent - before the parent + * gets woken up by child-exit notifications. + */ + perf_event_exit_task(tsk); + exit_mm(); if (group_dead) @@ -799,14 +808,6 @@ void __noreturn do_exit(long code) exit_task_work(tsk); exit_thread(tsk); - /* - * Flush inherited counters to the parent - before the parent - * gets woken up by child-exit notifications. - * - * because of cgroup mode, must be called before cgroup_exit() - */ - perf_event_exit_task(tsk); - sched_autogroup_exit_task(tsk); cgroup_exit(tsk); -- 2.34.1

2 1

[PATCH OLK-6.6] drivers/rapidio/rio_cm.c: prevent possible heap overwrite
by Xiaomeng Zhang 07 Jul '25

07 Jul '25

From: Andrew Morton <akpm(a)linux-foundation.org> mainline inclusion from mainline-v6.16-rc2 commit 50695153d7ddde3b1696dbf0085be0033bf3ddb3 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICIW6W CVE: CVE-2025-38090 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In riocm_cdev_ioctl(RIO_CM_CHAN_SEND) -> cm_chan_msg_send() -> riocm_ch_send() cm_chan_msg_send() checks that userspace didn't send too much data but riocm_ch_send() failed to check that userspace sent sufficient data. The result is that riocm_ch_send() can write to fields in the rio_ch_chan_hdr which were outside the bounds of the space which cm_chan_msg_send() allocated. Address this by teaching riocm_ch_send() to check that the entire rio_ch_chan_hdr was copied in from userspace. Reported-by: maher azz <maherazz04(a)gmail.com> Cc: Matt Porter <mporter(a)kernel.crashing.org> Cc: Alexandre Bounine <alex.bou9(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com> --- drivers/rapidio/rio_cm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/rapidio/rio_cm.c b/drivers/rapidio/rio_cm.c index 49f8d111e546..897642e62068 100644 --- a/drivers/rapidio/rio_cm.c +++ b/drivers/rapidio/rio_cm.c @@ -787,6 +787,9 @@ static int riocm_ch_send(u16 ch_id, void *buf, int len) if (buf == NULL || ch_id == 0 || len == 0 || len > RIO_MAX_MSG_SIZE) return -EINVAL; + if (len < sizeof(struct rio_ch_chan_hdr)) + return -EINVAL; /* insufficient data from user */ + ch = riocm_get_channel(ch_id); if (!ch) { riocm_error("%s(%d) ch_%d not found", current->comm, -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS 0/2] sch_htb: Fix CVE-2025-37932
by Dong Chenchen 07 Jul '25

07 Jul '25

Fix CVE-2025-37932 in sch_htb Cong Wang (2): sch_htb: make htb_qlen_notify() idempotent sch_htb: make htb_deactivate() idempotent net/sched/sch_htb.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) -- 2.25.1

2 3

[PATCH OLK-6.6] net_sched: red: fix a race in __red_change()
by Luo Gengkun 07 Jul '25

07 Jul '25

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.94 commit 2a71924ca4af59ffc00f0444732b6cd54b153d0e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICJT90 CVE: CVE-2025-38108 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 85a3e0ede38450ea3053b8c45d28cf55208409b8 ] Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 0c8d13ac9607 ("net: sched: red: delay destroying child qdisc on replace") Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Suggested-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20250611111515.1983366-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- net/sched/sch_red.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c index 16277b6a0238..3c6b4460cf2c 100644 --- a/net/sched/sch_red.c +++ b/net/sched/sch_red.c @@ -283,7 +283,7 @@ static int __red_change(struct Qdisc *sch, struct nlattr **tb, q->userbits = userbits; q->limit = ctl->limit; if (child) { - qdisc_tree_flush_backlog(q->qdisc); + qdisc_purge_queue(q->qdisc); old_child = q->qdisc; q->qdisc = child; } -- 2.34.1

2 1

[PATCH OLK-5.10] net_sched: red: fix a race in __red_change()
by Luo Gengkun 07 Jul '25

07 Jul '25

From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v5.10.239 commit a1bf6a4e9264a685b0e642994031f9c5aad72414 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICJT90 CVE: CVE-2025-38108 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 85a3e0ede38450ea3053b8c45d28cf55208409b8 ] Gerrard Tai reported a race condition in RED, whenever SFQ perturb timer fires at the wrong time. The race is as follows: CPU 0 CPU 1 [1]: lock root [2]: qdisc_tree_flush_backlog() [3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() | [4]: qdisc_put() This can be abused to underflow a parent's qlen. Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog() should fix the race, because all packets will be purged from the qdisc before releasing the lock. Fixes: 0c8d13ac9607 ("net: sched: red: delay destroying child qdisc on replace") Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Suggested-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Link: https://patch.msgid.link/20250611111515.1983366-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- net/sched/sch_red.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c index 935d90874b1b..1b69b7b90d85 100644 --- a/net/sched/sch_red.c +++ b/net/sched/sch_red.c @@ -283,7 +283,7 @@ static int __red_change(struct Qdisc *sch, struct nlattr **tb, q->userbits = userbits; q->limit = ctl->limit; if (child) { - qdisc_tree_flush_backlog(q->qdisc); + qdisc_purge_queue(q->qdisc); old_child = q->qdisc; q->qdisc = child; } -- 2.34.1

2 1

[PATCH OLK-6.6 0/1] Fix CVE-2025-38182
by Hongbo Li 07 Jul '25

07 Jul '25

Fix CVE-2025-38182. Ronnie Sahlberg (1): ublk: santizize the arguments from userspace when adding a device drivers/block/ublk_drv.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.34.1

2 2

[PATCH OLK-6.6 v2] mm: respect mmap hint address when aligning for THP
by Tong Tiangen 07 Jul '25

07 Jul '25

From: Kalesh Singh <kaleshsingh(a)google.com> mainline inclusion from mainline-v6.13-rc2 commit 249608ee47132cab3b1adacd9e463548f57bd316 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICK7OL Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") updated __get_unmapped_area() to align the start address for the VMA to a PMD boundary if CONFIG_TRANSPARENT_HUGEPAGE=y. It does this by effectively looking up a region that is of size, request_size + PMD_SIZE, and aligning up the start to a PMD boundary. Commit 4ef9ad19e176 ("mm: huge_memory: don't force huge page alignment on 32 bit") opted out of this for 32bit due to regressions in mmap base randomization. Commit d4148aeab412 ("mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes") restricted this to only mmap sizes that are multiples of the PMD_SIZE due to reported regressions in some performance benchmarks -- which seemed mostly due to the reduced spatial locality of related mappings due to the forced PMD-alignment. Another unintended side effect has emerged: When a user specifies an mmap hint address, the THP alignment logic modifies the behavior, potentially ignoring the hint even if a sufficiently large gap exists at the requested hint location. Example Scenario: Consider the following simplified virtual address (VA) space: ... 0x200000-0x400000 --- VMA A 0x400000-0x600000 --- Hole 0x600000-0x800000 --- VMA B ... A call to mmap() with hint=0x400000 and len=0x200000 behaves differently: - Before THP alignment: The requested region (size 0x200000) fits into the gap at 0x400000, so the hint is respected. - After alignment: The logic searches for a region of size 0x400000 (len + PMD_SIZE) starting at 0x400000. This search fails due to the mapping at 0x600000 (VMA B), and the hint is ignored, falling back to arch_get_unmapped_area[_topdown](). In general the hint is effectively ignored, if there is any existing mapping in the below range: [mmap_hint + mmap_size, mmap_hint + mmap_size + PMD_SIZE) This changes the semantics of mmap hint; from ""Respect the hint if a sufficiently large gap exists at the requested location" to "Respect the hint only if an additional PMD-sized gap exists beyond the requested size". This has performance implications for allocators that allocate their heap using mmap but try to keep it "as contiguous as possible" by using the end of the exisiting heap as the address hint. With the new behavior it's more likely to get a much less contiguous heap, adding extra fragmentation and performance overhead. To restore the expected behavior; don't use thp_get_unmapped_area_vmflags() when the user provided a hint address, for anonymous mappings. Note: As Yang Shi pointed out: the issue still remains for filesystems which are using thp_get_unmapped_area() for their get_unmapped_area() op. It is unclear what worklaods will regress for if we ignore THP alignment when the hint address is provided for such file backed mappings -- so this fix will be handled separately. Link: https://lkml.kernel.org/r/20241118214650.3667577-1-kaleshsingh@google.com Fixes: efa7df3e3bb5 ("mm: align larger anonymous mappings on THP boundaries") Signed-off-by: Kalesh Singh <kaleshsingh(a)google.com> Reviewed-by: Rik van Riel <riel(a)surriel.com> Reviewed-by: Vlastimil Babka <vbabka(a)suse.cz> Reviewed-by: David Hildenbrand <david(a)redhat.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Yang Shi <yang(a)os.amperecomputing.com> Cc: Rik van Riel <riel(a)surriel.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Minchan Kim <minchan(a)kernel.org> Cc: Hans Boehm <hboehm(a)google.com> Cc: Lokesh Gidra <lokeshgidra(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/mmap.c [context conflict: 8a0fe564bb2e ("mm: use get_unmapped_area_vmflags()") not merged.] Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> --- v2: fix commit message checkformat. mm/mmap.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/mmap.c b/mm/mmap.c index 59f410c03f2b..32799ed58022 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1899,7 +1899,8 @@ get_unmapped_area(struct file *file, unsigned long addr, unsigned long len, * so use shmem's get_unmapped_area in case it can be huge. */ get_area = shmem_get_unmapped_area; - } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) { + } else if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE) + && !addr) { /* no hint */ /* Ensures that larger anonymous mappings are THP aligned. */ get_area = thp_get_unmapped_area; } -- 2.25.1

2 1

[PATCH OLK-6.6] octeon_ep: Fix host hang issue during device reboot
by Cai Xinchen 07 Jul '25

07 Jul '25

From: Sathesh B Edara <sedara(a)marvell.com> stable inclusion from stable-v6.6.90 commit 7e1ca1bed3f66e00377f7d2147be390144924276 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IC991M CVE: CVE-2025-37933 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 34f42736b325287a7b2ce37e415838f539767bda ] When the host loses heartbeat messages from the device, the driver calls the device-specific ndo_stop function, which frees the resources. If the driver is unloaded in this scenario, it calls ndo_stop again, attempting to free resources that have already been freed, leading to a host hang issue. To resolve this, dev_close should be called instead of the device-specific stop function.dev_close internally calls ndo_stop to stop the network interface and performs additional cleanup tasks. During the driver unload process, if the device is already down, ndo_stop is not called. Fixes: 5cb96c29aa0e ("octeon_ep: add heartbeat monitor") Signed-off-by: Sathesh B Edara <sedara(a)marvell.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250429114624.19104-1-sedara@marvell.com Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- drivers/net/ethernet/marvell/octeon_ep/octep_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c index 6f1fe7e283d4..7a30095b3486 100644 --- a/drivers/net/ethernet/marvell/octeon_ep/octep_main.c +++ b/drivers/net/ethernet/marvell/octeon_ep/octep_main.c @@ -917,7 +917,7 @@ static void octep_hb_timeout_task(struct work_struct *work) miss_cnt); rtnl_lock(); if (netif_running(oct->netdev)) - octep_stop(oct->netdev); + dev_close(oct->netdev); rtnl_unlock(); } -- 2.34.1

2 1

[PATCH OLK-6.6] arm64/mpam: Fix L2 monitor issue under CDP mode
by Zeng Heng 07 Jul '25

07 Jul '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IC30P1 -------------------------------- The L2 monitor counters always reset to 0 under CDP working mode. This occurs because the L2 monitor employs cumulative statistics, and monitors a single partid within each statistical cycle. After completing the configuration for the new partid monitoring, the monitor instance starts a new monitoring cycle and resets the counter to zero. Since MPAM implements the CDP feature by allocating two partids, switching the monitor's target partid during a monitoring cycle falsely triggers a "new control group" assumption, leading to erroneous counter resets. To resolve this, use the real partid % num_mon to ensure distinct monitor instances track different partids under the CDP control group, preventing unintended resets. Fixes: 556688623b2b ("fs/resctrl: Create l2 cache monitors") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 42 ++++++++++------------------ 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 8de4aae95253..c3f9f0c2a94c 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -309,19 +309,8 @@ static void *resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, if (!ret) return ERR_PTR(-ENOMEM); - switch (evtid) { - case QOS_L3_OCCUP_EVENT_ID: - case QOS_L3_MBM_LOCAL_EVENT_ID: - case QOS_L3_MBM_TOTAL_EVENT_ID: - case QOS_L2_OCCUP_EVENT_ID: - case QOS_L2_MBM_CORE_EVENT_ID: - *ret = __mon_is_rmid_idx; - return ret; - - default: - kfree(ret); - return ERR_PTR(-EOPNOTSUPP); - } + *ret = __mon_is_rmid_idx; + return ret; } void *resctrl_arch_mon_ctx_alloc(struct rdt_resource *r, int evtid) @@ -371,7 +360,6 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, struct mon_cfg cfg; struct mpam_resctrl_dom *dom; struct mpam_resctrl_res *res; - u32 mon = *(u32 *)arch_mon_ctx; enum mpam_device_features type; resctrl_arch_rmid_read_context_check(); @@ -392,20 +380,15 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, return -EINVAL; } - cfg.mon = mon; - if (cfg.mon == USE_RMID_IDX) { - /* - * The number of mbwu monitors can't support free run mode, - * adapt the remainder of rmid to the num_mon as compromise. - */ - res = container_of(r, struct mpam_resctrl_res, resctrl_res); - if (type == mpam_feat_msmon_mbwu) - num_mon = res->class->props.num_mbwu_mon; - else - num_mon = res->class->props.num_csu_mon; - - cfg.mon = closid % num_mon; - } + /* + * The number of mbwu monitors can't support free run mode, + * adapt the remainder of rmid to the num_mon as compromise. + */ + res = container_of(r, struct mpam_resctrl_res, resctrl_res); + if (type == mpam_feat_msmon_mbwu) + num_mon = res->class->props.num_mbwu_mon; + else + num_mon = res->class->props.num_csu_mon; cfg.match_pmg = true; cfg.pmg = rmid; @@ -413,11 +396,13 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, if (cdp_enabled) { cfg.partid = resctrl_get_config_index(closid, CDP_DATA); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); if (err) return err; cfg.partid = resctrl_get_config_index(closid, CDP_CODE); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, &cdp_val); if (!err) { pr_debug("read monitor rmid %u %s:%u CODE/DATA: %lld/%lld\n", @@ -427,6 +412,7 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, } } else { cfg.partid = closid; + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); } -- 2.25.1

2 1

[PATCH OLK-6.6] arm64/mpam: Fix L2 monitor issue under CDP mode
by Zeng Heng 07 Jul '25

07 Jul '25

The L2 monitor counters always reset to 0 under CDP working mode. This occurs because the L2 monitor employs cumulative statistics, and monitors a single partid within each statistical cycle. After completing the configuration for the new partid monitoring, the monitor instance starts a new monitoring cycle and resets the counter to zero. Since MPAM implements the CDP feature by allocating two partids, switching the monitor's target partid during a monitoring cycle falsely triggers a "new control group" assumption, leading to erroneous counter resets. To resolve this, use the real partid % num_mon to ensure distinct monitor instances track different partids under the CDP control group, preventing unintended resets. Fixes: 585d757fc15c ("fs/resctrl: Create l2 cache monitors") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 42 ++++++++++------------------ 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 8de4aae95253..c3f9f0c2a94c 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -309,19 +309,8 @@ static void *resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, if (!ret) return ERR_PTR(-ENOMEM); - switch (evtid) { - case QOS_L3_OCCUP_EVENT_ID: - case QOS_L3_MBM_LOCAL_EVENT_ID: - case QOS_L3_MBM_TOTAL_EVENT_ID: - case QOS_L2_OCCUP_EVENT_ID: - case QOS_L2_MBM_CORE_EVENT_ID: - *ret = __mon_is_rmid_idx; - return ret; - - default: - kfree(ret); - return ERR_PTR(-EOPNOTSUPP); - } + *ret = __mon_is_rmid_idx; + return ret; } void *resctrl_arch_mon_ctx_alloc(struct rdt_resource *r, int evtid) @@ -371,7 +360,6 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, struct mon_cfg cfg; struct mpam_resctrl_dom *dom; struct mpam_resctrl_res *res; - u32 mon = *(u32 *)arch_mon_ctx; enum mpam_device_features type; resctrl_arch_rmid_read_context_check(); @@ -392,20 +380,15 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, return -EINVAL; } - cfg.mon = mon; - if (cfg.mon == USE_RMID_IDX) { - /* - * The number of mbwu monitors can't support free run mode, - * adapt the remainder of rmid to the num_mon as compromise. - */ - res = container_of(r, struct mpam_resctrl_res, resctrl_res); - if (type == mpam_feat_msmon_mbwu) - num_mon = res->class->props.num_mbwu_mon; - else - num_mon = res->class->props.num_csu_mon; - - cfg.mon = closid % num_mon; - } + /* + * The number of mbwu monitors can't support free run mode, + * adapt the remainder of rmid to the num_mon as compromise. + */ + res = container_of(r, struct mpam_resctrl_res, resctrl_res); + if (type == mpam_feat_msmon_mbwu) + num_mon = res->class->props.num_mbwu_mon; + else + num_mon = res->class->props.num_csu_mon; cfg.match_pmg = true; cfg.pmg = rmid; @@ -413,11 +396,13 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, if (cdp_enabled) { cfg.partid = resctrl_get_config_index(closid, CDP_DATA); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); if (err) return err; cfg.partid = resctrl_get_config_index(closid, CDP_CODE); + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, &cdp_val); if (!err) { pr_debug("read monitor rmid %u %s:%u CODE/DATA: %lld/%lld\n", @@ -427,6 +412,7 @@ int resctrl_arch_rmid_read(struct rdt_resource *r, struct rdt_domain *d, } } else { cfg.partid = closid; + cfg.mon = cfg.partid % num_mon; err = mpam_msmon_read(dom->comp, &cfg, type, val); } -- 2.25.1

2 1