- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] perf/x86/intel/uncore: Skip discovery table for offline dies
by Luo Gengkun 07 May '26

07 May '26

From: Zide Chen <zide.chen(a)intel.com> stable inclusion from stable-v6.6.136 commit cfab2c817d2e7e0bee98d66850246ce842ed5f18 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14628 CVE: CVE-2026-43079 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 7b568e9eba2fad89a696f22f0413d44cf4a1f892 ] This warning can be triggered if NUMA is disabled and the system boots with fewer CPUs than the number of CPUs in die 0. WARNING: CPU: 9 PID: 7257 at uncore.c:1157 uncore_pci_pmu_register+0x136/0x160 [intel_uncore] Currently, the discovery table continues to be parsed even if all CPUs in the associated die are offline. This can lead to an array overflow at "pmu->boxes[die] = box" in uncore_pci_pmu_register(), which may trigger the warning above or cause other issues. Fixes: edae1f06c2cd ("perf/x86/intel/uncore: Parse uncore discovery tables") Reported-by: Steve Wahl <steve.wahl(a)hpe.com> Signed-off-by: Zide Chen <zide.chen(a)intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> Tested-by: Steve Wahl <steve.wahl(a)hpe.com> Link: https://patch.msgid.link/20260313174050.171704-3-zide.chen@intel.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/intel/uncore_discovery.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/uncore_discovery.c b/arch/x86/events/intel/uncore_discovery.c index a543a54fd714..6765f31479c5 100644 --- a/arch/x86/events/intel/uncore_discovery.c +++ b/arch/x86/events/intel/uncore_discovery.c @@ -382,7 +382,7 @@ static bool intel_uncore_has_discovery_tables_pci(int *ignore) (val & UNCORE_DISCOVERY_DVSEC2_BIR_MASK) * UNCORE_DISCOVERY_BIR_STEP; die = get_device_die_id(dev); - if (die < 0) + if ((die < 0) || (die >= uncore_max_dies())) continue; parse_discovery_table(dev, die, bar_offset, &parsed, ignore); -- 2.34.1

2 1

[PATCH OLK-6.6] pstore: ram_core: fix incorrect success return when vmap() fails
by Luo Gengkun 07 May '26

07 May '26

From: Ruipeng Qi <ruipengqi3(a)gmail.com> stable inclusion from stable-v6.6.128 commit 1da904e84de608907662ad8a51ba9c571d61e003 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14671 CVE: CVE-2026-43124 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit 05363abc7625cf18c96e67f50673cd07f11da5e9 ] In persistent_ram_vmap(), vmap() may return NULL on failure. If offset is non-zero, adding offset_in_page(start) causes the function to return a non-NULL pointer even though the mapping failed. persistent_ram_buffer_map() therefore incorrectly returns success. Subsequent access to prz->buffer may dereference an invalid address and cause crashes. Add proper NULL checking for vmap() failures. Signed-off-by: Ruipeng Qi <ruipengqi3(a)gmail.com> Link: https://patch.msgid.link/20260203020358.3315299-1-ruipengqi3@gmail.com Signed-off-by: Kees Cook <kees(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- fs/pstore/ram_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c index c9eaacdec37e..7b6d6378a3b8 100644 --- a/fs/pstore/ram_core.c +++ b/fs/pstore/ram_core.c @@ -457,6 +457,13 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size, vaddr = vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot); kfree(pages); + /* + * vmap() may fail and return NULL. Do not add the offset in this + * case, otherwise a NULL mapping would appear successful. + */ + if (!vaddr) + return NULL; + /* * Since vmap() uses page granularity, we must add the offset * into the page here, to get the byte granularity address -- 2.34.1

2 1

[PATCH OLK-6.6] mm: memcontrol: don't throttle dying tasks on memory.high
by Jinjiang Tu 07 May '26

07 May '26

From: Johannes Weiner <hannes(a)cmpxchg.org> mainline inclusion from mainline-v6.8-rc3 commit 63fd327016fdfca6f2fa27eba3496bd079eb8ed3 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/9095 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- While investigating hosts with high cgroup memory pressures, Tejun found culprit zombie tasks that had were holding on to a lot of memory, had SIGKILL pending, but were stuck in memory.high reclaim. In the past, we used to always force-charge allocations from tasks that were exiting in order to accelerate them dying and freeing up their rss. This changed for memory.max in a4ebf1b6ca1e ("memcg: prohibit unconditional exceeding the limit of dying tasks"); it noted that this can cause (userspace inducable) containment failures, so it added a mandatory reclaim and OOM kill cycle before forcing charges. At the time, memory.high enforcement was handled in the userspace return path, which isn't reached by dying tasks, and so memory.high was still never enforced by dying tasks. When c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges") added synchronous reclaim for memory.high, it added unconditional memory.high enforcement for dying tasks as well. The callstack shows that this path is where the zombie is stuck in. We need to accelerate dying tasks getting past memory.high, but we cannot do it quite the same way as we do for memory.max: memory.max is enforced strictly, and tasks aren't allowed to move past it without FIRST reclaiming and OOM killing if necessary. This ensures very small levels of excess. With memory.high, though, enforcement happens lazily after the charge, and OOM killing is never triggered. A lot of concurrent threads could have pushed, or could actively be pushing, the cgroup into excess. The dying task will enter reclaim on every allocation attempt, with little hope of restoring balance. To fix this, skip synchronous memory.high enforcement on dying tasks altogether again. Update memory.high path documentation while at it. [hannes(a)cmpxchg.org: also handle tasks are being killed during the reclaim] Link: https://lkml.kernel.org/r/20240111192807.GA424308@cmpxchg.org Link: https://lkml.kernel.org/r/20240111132902.389862-1-hannes@cmpxchg.org Fixes: c9afe31ec443 ("memcg: synchronously enforce memory.high for large overcharges") Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Reported-by: Tejun Heo <tj(a)kernel.org> Reviewed-by: Yosry Ahmed <yosryahmed(a)google.com> Acked-by: Shakeel Butt <shakeelb(a)google.com> Acked-by: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Dan Schatzberg <schatzberg.dan(a)gmail.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Muchun Song <muchun.song(a)linux.dev> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/memcontrol.c [hulk feature: 'fine grained stall' causes conflicts] Signed-off-by: Chen Ridong <chenridong(a)huawei.com> Signed-off-by: Jinjiang Tu <tujinjiang(a)huawei.com> --- mm/memcontrol.c | 29 +++++++++++++++++++++++++---- 1 file changed, 25 insertions(+), 4 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ac2b4b1060fd..46411dead693 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2769,8 +2769,9 @@ static unsigned long calculate_high_delay(struct mem_cgroup *memcg, } /* - * Scheduled by try_charge() to be executed from the userland return path - * and reclaims memory over the high limit. + * Reclaims memory over the high limit. Called directly from + * try_charge() (context permitting), as well as from the userland + * return path where reclaim is always able to block. */ void mem_cgroup_handle_over_high(gfp_t gfp_mask) { @@ -2789,6 +2790,17 @@ void mem_cgroup_handle_over_high(gfp_t gfp_mask) current->memcg_nr_pages_over_high = 0; retry_reclaim: + /* + * Bail if the task is already exiting. Unlike memory.max, + * memory.high enforcement isn't as strict, and there is no + * OOM killer involved, which means the excess could already + * be much bigger (and still growing) than it could for + * memory.max; the dying task could get stuck in fruitless + * reclaim for a long time, which isn't desirable. + */ + if (task_is_dying()) + goto out; + /* * The allocating task should reclaim at least the batch size, but for * subsequent retries we only want to do what's necessary to prevent oom @@ -2839,6 +2851,9 @@ void mem_cgroup_handle_over_high(gfp_t gfp_mask) } /* + * Reclaim didn't manage to push usage below the limit, slow + * this allocating task down. + * * If we exit early, we're guaranteed to die (since * schedule_timeout_killable sets TASK_KILLABLE). This means we don't * need to account for any ill-begotten jiffies to pay them off later. @@ -3049,11 +3064,17 @@ static int try_charge_memcg(struct mem_cgroup *memcg, gfp_t gfp_mask, } } while ((memcg = parent_mem_cgroup(memcg))); + /* + * Reclaim is set up above to be called from the userland + * return path. But also attempt synchronous reclaim to avoid + * excessive overrun while the task is still inside the + * kernel. If this is successful, the return path will see it + * when it rechecks the overage and simply bail out. + */ if (current->memcg_nr_pages_over_high > MEMCG_CHARGE_BATCH && !(current->flags & PF_MEMALLOC) && - gfpflags_allow_blocking(gfp_mask)) { + gfpflags_allow_blocking(gfp_mask)) mem_cgroup_handle_over_high(gfp_mask); - } return 0; } -- 2.43.0

2 1

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14179 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14179 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6 v9 0/2] kvm: arm64: Transition from CPU Type to MIDR Register for Virtualization Feature Detection
by liqiqi 07 May '26

07 May '26

Currently, there are two methods for determining whether a chip supports specific virtualization features: 1. Reading the chip's CPU type from BIOS 2. Reading the value of the MIDR register The issue with the first method is that each time a new chip is introduced, the new CPU type must be defined, which leads to poor code portability and maintainability. Therefore, the second method has been adopted to replace the first. This approach eliminates the dependency on CPU type by using the MIDR register. liqiqi (2): kvm: arm64: Add MIDR definitions and use MIDR to determine whether features are supported kvm: arm64: Remove cpu_type definition and it's related interfaces arch/arm64/include/asm/cputype.h | 6 ++ arch/arm64/kvm/arm.c | 1 - arch/arm64/kvm/hisilicon/hisi_virt.c | 115 ++++----------------------- arch/arm64/kvm/hisilicon/hisi_virt.h | 12 --- 4 files changed, 21 insertions(+), 113 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: https://atomgit.com/src-openeuler/kernel/issues/14179 bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6] dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()
by Zhang Yuwei 07 May '26

07 May '26

From: Tuo Li <islituo(a)gmail.com> mainline inclusion from mainline-v7.0-rc6 commit e1c9866173c5f8521f2d0768547a01508cb9ff27 category: bugfix bugzilla: NA Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- At the end of this function, d is the traversal cursor of flist, but the code completes found instead. This can lead to issues such as NULL pointer dereferences, double completion, or descriptor leaks. Fix this by completing d instead of found in the final list_for_each_entry_safe() loop. Fixes: aa8d18becc0c ("dmaengine: idxd: add callback support for iaa crypto") Signed-off-by: Tuo Li <islituo(a)gmail.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Link: https://patch.msgid.link/20260106032428.162445-1-islituo@gmail.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Conflicts: drivers/dma/idxd/submit.c [Context Conflicts] Signed-off-by: Lin Ruifeng <linruifeng4(a)huawei.com> --- drivers/dma/idxd/submit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/idxd/submit.c b/drivers/dma/idxd/submit.c index 817a564413b0..111e9dd8ebda 100644 --- a/drivers/dma/idxd/submit.c +++ b/drivers/dma/idxd/submit.c @@ -138,7 +138,7 @@ static void llist_abort_desc(struct idxd_wq *wq, struct idxd_irq_entry *ie, */ list_for_each_entry_safe(d, t, &flist, list) { list_del_init(&d->list); - idxd_dma_complete_txd(found, IDXD_COMPLETE_ABORT, true, + idxd_dma_complete_txd(d, IDXD_COMPLETE_ABORT, true, NULL, NULL); } } -- 2.22.0

2 1

[PATCH OLK-6.6 0/2] support mempool and NUMA.remote for 64KB page
by Jinjiang Tu 07 May '26

07 May '26

support mempool and NUMA.remote for 64KB page. Jinjiang Tu (2): mm/pfn_range_alloc: add support for CONFIG_ARM64_64K_PAGES mm/numa_remote: remove depends on ARM64_4K_PAGES arch/arm64/mm/Kconfig | 1 + arch/arm64/mm/pfn_range_alloc.c | 31 ++++++++++++++++++++++++------- drivers/base/Kconfig | 2 +- 3 files changed, 26 insertions(+), 8 deletions(-) -- 2.43.0

2 3

[PATCH OLK-6.6] PCI: endpoint: pci-epf-vntb: Stop cmd_handler work in epf_ntb_epc_cleanup
by Hongtao Zhang 06 May '26

06 May '26

From: Koichiro Den <den(a)valinux.co.jp> stable inclusion from stable-v6.12.83 commit 6773cc24c004930903a57761132c1e7728907f8f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/14339 CVE: CVE-2026-31595 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit d799984233a50abd2667a7d17a9a710a3f10ebe2 upstream. Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down. Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epf_ntb_cmd_handler+0x54/0x200 [pci_epf_vntb] (P) process_one_work+0x154/0x3b0 worker_thread+0x2c8/0x400 kthread+0x148/0x210 ret_from_fork+0x10/0x20 Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den <den(a)valinux.co.jp> Signed-off-by: Manivannan Sadhasivam <mani(a)kernel.org> Reviewed-by: Frank Li <Frank.Li(a)nxp.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20260226084142.2226875-4-den@valinux.co.jp Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zhang Hongtao <zhanghongtao35(a)huawei.com> --- drivers/pci/endpoint/functions/pci-epf-vntb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/endpoint/functions/pci-epf-vntb.c b/drivers/pci/endpoint/functions/pci-epf-vntb.c index 33c3f9b980e68..990c27a2cd8d7 100644 --- a/drivers/pci/endpoint/functions/pci-epf-vntb.c +++ b/drivers/pci/endpoint/functions/pci-epf-vntb.c @@ -810,6 +810,7 @@ static int epf_ntb_epc_init(struct epf_ntb *ntb) */ static void epf_ntb_epc_cleanup(struct epf_ntb *ntb) { + disable_delayed_work_sync(&ntb->cmd_handler); epf_ntb_mw_bar_clear(ntb, ntb->num_mws); epf_ntb_db_bar_clear(ntb); epf_ntb_config_sspad_bar_clear(ntb); -- 2.43.0

2 1