- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] perf/x86/intel: Fix KASAN global-out-of-bounds warning
by Luo Gengkun 25 Dec '25

25 Dec '25

From: Dapeng Mi <dapeng1.mi(a)linux.intel.com> mainline inclusion from mainline-v6.18-rc4 commit 0ba6502ce167fc3d598c08c2cc3b4ed7ca5aa251 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11639 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- When running "perf mem record" command on CWF, the below KASAN global-out-of-bounds warning is seen. ================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 Call Trace: kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80 The issue is caused by below code in __grt_latency_data(). The code tries to access x86_hybrid_pmu structure which doesn't exist on non-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big) So add is_hybrid() check before calling this WARN_ON_ONCE to fix the global-out-of-bounds access issue. Fixes: 090262439f66 ("perf/x86/intel: Rename model-specific pebs_latency_data functions") Reported-by: Xudong Hao <xudong.hao(a)intel.com> Signed-off-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Zide Chen <zide.chen(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251028064214.1451968-1-dapeng1.mi@linux.intel.com Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/intel/ds.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index 3010a90a339a..c313aee99d9a 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -304,7 +304,8 @@ static u64 __grt_latency_data(struct perf_event *event, u64 status, { u64 val; - WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big); + WARN_ON_ONCE(is_hybrid() && + hybrid_pmu(event->pmu)->pmu_type == hybrid_big); dse &= PERF_PEBS_DATA_SOURCE_GRT_MASK; val = hybrid_var(event->pmu, pebs_data_source)[dse]; -- 2.34.1

2 1

[PATCH OLK-6.6] mm: migrate: add dma copy offloading for hugetlb
by Zeng Heng 25 Dec '25

25 Dec '25

From: Tong Tiangen <tongtiangen(a)huawei.com> hulk inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/7837 ------------------------------- Large memory migration imposes significant overhead on the CPU. This patch introduces enhancements to the page migration by offloading the copy to UDMA hardware which based on the DMA engine framework, and a new migration mode has been introduced, If DMA migration fails, it will fall back to CPU migration. DMA migration supports both asynchronous and synchronous modes for subsequent debugging purposes. Signed-off-by: Tong Tiangen <tongtiangen(a)huawei.com> Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- arch/arm64/configs/openeuler_defconfig | 1 + arch/x86/configs/openeuler_defconfig | 1 + include/linux/migrate_mode.h | 7 ++ include/linux/mm.h | 8 ++ mm/Kconfig | 12 +++ mm/Makefile | 1 + mm/migrate.c | 9 ++ mm/migrate_dma.c | 143 +++++++++++++++++++++++++ 8 files changed, 182 insertions(+) create mode 100644 mm/migrate_dma.c diff --git a/arch/arm64/configs/openeuler_defconfig b/arch/arm64/configs/openeuler_defconfig index c25ac4ff6c2f..08af29cf2776 100644 --- a/arch/arm64/configs/openeuler_defconfig +++ b/arch/arm64/configs/openeuler_defconfig @@ -1186,6 +1186,7 @@ CONFIG_COMPACTION=y CONFIG_COMPACT_UNEVICTABLE_DEFAULT=1 CONFIG_PAGE_REPORTING=y CONFIG_MIGRATION=y +CONFIG_MIGRATE_PAGES_DMA_OFFLOADING=y CONFIG_DEVICE_MIGRATION=y CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_ARCH_ENABLE_THP_MIGRATION=y diff --git a/arch/x86/configs/openeuler_defconfig b/arch/x86/configs/openeuler_defconfig index 612ef34a6c73..7d9ce1496e18 100644 --- a/arch/x86/configs/openeuler_defconfig +++ b/arch/x86/configs/openeuler_defconfig @@ -1147,6 +1147,7 @@ CONFIG_COMPACTION=y CONFIG_COMPACT_UNEVICTABLE_DEFAULT=1 CONFIG_PAGE_REPORTING=y CONFIG_MIGRATION=y +# CONFIG_MIGRATE_PAGES_DMA_OFFLOADING is not set CONFIG_DEVICE_MIGRATION=y CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y CONFIG_ARCH_ENABLE_THP_MIGRATION=y diff --git a/include/linux/migrate_mode.h b/include/linux/migrate_mode.h index 0f577f932bb4..5283e62b7d1b 100644 --- a/include/linux/migrate_mode.h +++ b/include/linux/migrate_mode.h @@ -19,6 +19,13 @@ enum migrate_mode { MIGRATE_SYNC_NO_COPY, }; +/* + * Actually the macro MIGRATE_ASYNC_DMA_OFFLOADING definition should be + * placed within enum migrate_mode, but for KABI compatibility, it is + * defined here alone. + */ +#define MIGRATE_ASYNC_DMA_OFFLOADING (10) + enum migrate_reason { MR_COMPACTION, MR_MEMORY_FAILURE, diff --git a/include/linux/mm.h b/include/linux/mm.h index c0040a2014c4..036822cb1b9d 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1330,6 +1330,14 @@ void put_pages_list(struct list_head *pages); void split_page(struct page *page, unsigned int order); void folio_copy(struct folio *dst, struct folio *src); int folio_mc_copy(struct folio *dst, struct folio *src); +#ifdef CONFIG_MIGRATE_PAGES_DMA_OFFLOADING +int folio_dma_copy(struct folio *dst, struct folio *src); +#else +static inline int folio_dma_copy(struct folio *dst, struct folio *src) +{ + return -ENODEV; +} +#endif unsigned long nr_free_buffer_pages(void); diff --git a/mm/Kconfig b/mm/Kconfig index 4eb0642b71e5..12438e8dff88 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -696,6 +696,18 @@ config MIGRATION pages as migration can relocate pages to satisfy a huge page allocation instead of reclaiming. +config MIGRATE_PAGES_DMA_OFFLOADING + bool "Support to use DMA channels for page migration" + depends on DMA_ENGINE + depends on MIGRATION + default y + help + This config enhances page migration by introducing a new mode + that offloads copy operations to UB-DMA hardware based on the + DMA engine framework, with automatic fallback to CPU migration + if DMA migration fails. DMA migration supports both asynchronous + and synchronous modes to facilitate debugging. + config DEVICE_MIGRATION def_bool MIGRATION && ZONE_DEVICE diff --git a/mm/Makefile b/mm/Makefile index e45cdeda47b7..dd81f8c33e03 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -92,6 +92,7 @@ obj-$(CONFIG_FAILSLAB) += failslab.o obj-$(CONFIG_FAIL_PAGE_ALLOC) += fail_page_alloc.o obj-$(CONFIG_MEMTEST) += memtest.o obj-$(CONFIG_MIGRATION) += migrate.o +obj-$(CONFIG_MIGRATE_PAGES_DMA_OFFLOADING) += migrate_dma.o obj-$(CONFIG_NUMA) += memory-tiers.o obj-$(CONFIG_DEVICE_MIGRATION) += migrate_device.o obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o diff --git a/mm/migrate.c b/mm/migrate.c index 148e55fab012..216f45c9570f 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -583,6 +583,15 @@ static int folio_migrate_mc_copy(struct folio *dst, struct folio *src, if (mode == MIGRATE_SYNC_NO_COPY) return 0; + if (mode == MIGRATE_ASYNC_DMA_OFFLOADING) { + if (folio_test_hugetlb(src) || + folio_test_pmd_mappable(src)) { + /* if dma offloading fail, fallback */ + if (!folio_dma_copy(dst, src)) + return 0; + } + } + return folio_mc_copy(dst, src); } diff --git a/mm/migrate_dma.c b/mm/migrate_dma.c new file mode 100644 index 000000000000..796cd9a5477e --- /dev/null +++ b/mm/migrate_dma.c @@ -0,0 +1,143 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Support to use DMA channels for page migration. + * + * Copyright (C) 2025 Huawei Limited + */ + +#define pr_fmt(fmt) "migrate_dma: " fmt + +#include <linux/dmaengine.h> +#include <linux/dma-mapping.h> + +/* DMA channel track its transfers done */ +struct dma_channel_work { + struct dma_chan *chan; + enum dma_status status; + struct completion done; +}; + +static void folios_dma_copy_completion_callback(void *param, + const struct dmaengine_result *result) +{ + struct dma_channel_work *chan_work = param; + + if (result) { + enum dmaengine_tx_result dma_res = result->result; + + if (dma_res == DMA_TRANS_NOERROR) + chan_work->status = DMA_COMPLETE; + else + chan_work->status = DMA_ERROR; + } + + complete(&chan_work->done); +} + +static int process_folio_dma_transfer(struct dma_channel_work *chan_work, + struct folio *src, struct folio *dst) +{ + struct dma_chan *chan = chan_work->chan; + struct device *dev = dmaengine_get_dma_device(chan); + enum dma_ctrl_flags flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT; + struct dma_async_tx_descriptor *tx; + dma_addr_t src_handle, dst_handle; + size_t size = folio_size(src); + int ret; + + src_handle = dma_map_page(dev, &src->page, 0, size, DMA_TO_DEVICE); + if (dma_mapping_error(dev, src_handle)) { + dev_err(dev, "map dma src page error.\n"); + return -ENOMEM; + } + + dst_handle = dma_map_page(dev, &dst->page, 0, size, DMA_FROM_DEVICE); + if (dma_mapping_error(dev, dst_handle)) { + dev_err(dev, "map dma dst page error.\n"); + ret = -ENOMEM; + goto out_unmap; + } + + tx = dmaengine_prep_dma_memcpy(chan, dst_handle, src_handle, + size, flags); + if (unlikely(!tx)) { + dev_err(dev, "prep dma memcpy error.\n"); + ret = -EBUSY; + goto out_unmap_all; + } + + tx->callback_result = folios_dma_copy_completion_callback; + tx->callback_param = chan_work; + init_completion(&chan_work->done); + chan_work->status = DMA_ERROR; + + if (dma_submit_error(dmaengine_submit(tx))) { + dev_err(dev, "dma submit error.\n"); + ret = -EINVAL; + goto out_unmap_all; + } + + dma_async_issue_pending(chan); + if (!wait_for_completion_timeout(&chan_work->done, + msecs_to_jiffies(1000))) { + ret = -ETIMEDOUT; + goto out_unmap_all; + } + + ret = (chan_work->status == DMA_COMPLETE) ? 0 : -EPROTO; + +out_unmap_all: + dma_unmap_page(dev, dst_handle, size, DMA_FROM_DEVICE); +out_unmap: + dma_unmap_page(dev, src_handle, size, DMA_TO_DEVICE); + + return ret; +} + +static bool folio_dma_chan_filter(struct dma_chan *chan, void *param) +{ + return !strcmp(dev_name(chan->device->dev), "ub_dma_device"); +} + +int folio_dma_copy(struct folio *dst, struct folio *src) +{ + struct dma_channel_work *chan_work; + struct dma_slave_config dma_cfg; + struct dma_chan *chan; + dma_cap_mask_t mask; + int ret = -ENODEV; + + dma_cap_zero(mask); + dma_cap_set(DMA_MEMCPY, mask); + chan = dma_request_channel(mask, folio_dma_chan_filter, NULL); + if (!chan) { + pr_err("failed to allocate dma channel.\n"); + return ret; + } + + memset(&dma_cfg, 0, sizeof(dma_cfg)); + dma_cfg.direction = DMA_MEM_TO_MEM; + ret = dmaengine_slave_config(chan, &dma_cfg); + if (ret) { + pr_err("failed to config dma channel.\n"); + goto out_release; + } + + chan_work = kmalloc(sizeof(*chan_work), GFP_KERNEL); + if (unlikely(!chan_work)) { + pr_err("failed to allocate memory for chan work.\n"); + goto out_release; + } + + chan_work->chan = chan; + ret = process_folio_dma_transfer(chan_work, src, dst); + if (unlikely(ret)) + pr_err("failed to process folio dma transfer.\n"); + + kfree(chan_work); +out_release: + dma_release_channel(chan); + + return ret; +} +EXPORT_SYMBOL(folio_dma_copy); -- 2.25.1

2 1

[PATCH OLK-6.6] bpf: Free special fields when update [lru_,]percpu_hash maps
by Luo Gengkun 25 Dec '25

25 Dec '25

From: Leon Hwang <leon.hwang(a)linux.dev> mainline inclusion from mainline-v6.19-rc1 commit 6af6e49a76c9af7d42eb923703e7648cb2bf401a category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12705 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- As [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missing calls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause the memory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until the map gets freed. Fix this by calling 'bpf_obj_free_fields()' after 'copy_map_value[,_long]()' in 'pcpu_copy_value()'. Fixes: 65334e64a493 ("bpf: Support kptrs in percpu hashmap and percpu LRU hashmap") Signed-off-by: Leon Hwang <leon.hwang(a)linux.dev> Acked-by: Yonghong Song <yonghong.song(a)linux.dev> Link: https://lore.kernel.org/r/20251105151407.12723-2-leon.hwang@linux.dev Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- kernel/bpf/hashtab.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index fdc74aeaa164..46e833e5666b 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -957,15 +957,21 @@ static void free_htab_elem(struct bpf_htab *htab, struct htab_elem *l) static void pcpu_copy_value(struct bpf_htab *htab, void __percpu *pptr, void *value, bool onallcpus) { + void *ptr; + if (!onallcpus) { /* copy true value_size bytes */ - copy_map_value(&htab->map, this_cpu_ptr(pptr), value); + ptr = this_cpu_ptr(pptr); + copy_map_value(&htab->map, ptr, value); + bpf_obj_free_fields(htab->map.record, ptr); } else { u32 size = round_up(htab->map.value_size, 8); int off = 0, cpu; for_each_possible_cpu(cpu) { - copy_map_value_long(&htab->map, per_cpu_ptr(pptr, cpu), value + off); + ptr = per_cpu_ptr(pptr, cpu); + copy_map_value_long(&htab->map, ptr, value + off); + bpf_obj_free_fields(htab->map.record, ptr); off += size; } } -- 2.34.1

2 1

[openeuler:openEuler-1.0-LTS 1942/1942] drivers/net/ethernet/microchip/lan743x_ptp.c:985:6: warning: no previous prototype for function 'lan743x_ptp_set_sync_ts_insert'
by kernel test robot 25 Dec '25

25 Dec '25

Hi Bryan, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4e9c55920995d70b3e88b60c69753df54b03fdf4 commit: 07624df1c9efd4b7f2f6762581587c590b03c7a2 [1942/1942] lan743x: lan743x: Add PTP support config: x86_64-randconfig-071-20251213 (https://download.01.org/0day-ci/archive/20251225/202512250737.MecjkLdA-lkp@…) compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 1335a05ab8bc8339ce24be3a9da89d8c3f4e0571) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251225/202512250737.MecjkLdA-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512250737.MecjkLdA-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from <built-in>:2: In file included from include/linux/compiler_types.h:78: include/linux/compiler-clang.h:25:9: warning: '__SANITIZE_ADDRESS__' macro redefined [-Wmacro-redefined] 25 | #define __SANITIZE_ADDRESS__ | ^ <built-in>:353:9: note: previous definition is here 353 | #define __SANITIZE_ADDRESS__ 1 | ^ drivers/net/ethernet/microchip/lan743x_ptp.c:781:28: error: no member named 'ptp_clock' in 'struct lan743x_ptp' 781 | ptp_schedule_worker(ptp->ptp_clock, 0); | ~~~ ^ drivers/net/ethernet/microchip/lan743x_ptp.c:879:6: warning: unused variable 'ret' [-Wunused-variable] 879 | int ret = -ENODEV; | ^~~ >> drivers/net/ethernet/microchip/lan743x_ptp.c:985:6: warning: no previous prototype for function 'lan743x_ptp_set_sync_ts_insert' [-Wmissing-prototypes] 985 | void lan743x_ptp_set_sync_ts_insert(struct lan743x_adapter *adapter, | ^ drivers/net/ethernet/microchip/lan743x_ptp.c:985:1: note: declare 'static' if the function is not intended to be used outside of this translation unit 985 | void lan743x_ptp_set_sync_ts_insert(struct lan743x_adapter *adapter, | ^ | static 3 warnings and 1 error generated. vim +/lan743x_ptp_set_sync_ts_insert +985 drivers/net/ethernet/microchip/lan743x_ptp.c 984 > 985 void lan743x_ptp_set_sync_ts_insert(struct lan743x_adapter *adapter, 986 bool ts_insert_enable) 987 { 988 u32 ptp_tx_mod = lan743x_csr_read(adapter, PTP_TX_MOD); 989 990 if (ts_insert_enable) 991 ptp_tx_mod |= PTP_TX_MOD_TX_PTP_SYNC_TS_INSERT_; 992 else 993 ptp_tx_mod &= ~PTP_TX_MOD_TX_PTP_SYNC_TS_INSERT_; 994 995 lan743x_csr_write(adapter, PTP_TX_MOD, ptp_tx_mod); 996 } 997 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 3406/3406] kernel/cgroup/cgroup.c:6734: warning: Function parameter or member 'fd' not described in 'cgroup_get_from_fd_v2'
by kernel test robot 25 Dec '25

25 Dec '25

Hi Liu, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: 56fee14453059f894b018d08071826d47e634800 [3406/3406] cgroup: make cgroup_bpf_prog_attach work when cgroup2 is not mounted config: arm64-randconfig-003-20251211 (https://download.01.org/0day-ci/archive/20251225/202512250139.hi51ZBjo-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251225/202512250139.hi51ZBjo-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512250139.hi51ZBjo-lkp@intel.com/ All warnings (new ones prefixed by >>): kernel/cgroup/cgroup.c:6217: warning: Function parameter or member 'f' not described in 'cgroup_get_from_file' kernel/cgroup/cgroup.c:6369: warning: Function parameter or member 'kargs' not described in 'cgroup_can_fork' kernel/cgroup/cgroup.c:6430: warning: Function parameter or member 'kargs' not described in 'cgroup_post_fork' kernel/cgroup/cgroup.c:6716: warning: Function parameter or member 'fd' not described in 'cgroup_get_from_fd' >> kernel/cgroup/cgroup.c:6734: warning: Function parameter or member 'fd' not described in 'cgroup_get_from_fd_v2' vim +6734 kernel/cgroup/cgroup.c 6729 6730 /** 6731 * same with cgroup_get_from_fd, only add cgrp_dfl_visible check 6732 */ 6733 struct cgroup *cgroup_get_from_fd_v2(int fd) > 6734 { 6735 struct cgroup *cgrp = cgroup_v1v2_get_from_fd(fd); 6736 6737 if (IS_ERR(cgrp)) 6738 return ERR_CAST(cgrp); 6739 6740 if (!cgroup_on_dfl(cgrp)) { 6741 cgroup_put(cgrp); 6742 if (cgrp_dfl_visible) 6743 return ERR_PTR(-EBADF); 6744 6745 cgrp = &cgrp_dfl_root.cgrp; 6746 cgroup_get(cgrp); 6747 } 6748 return cgrp; 6749 } 6750 EXPORT_SYMBOL_GPL(cgroup_get_from_fd_v2); 6751 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openeuler:OLK-5.10 3406/3406] kernel/task_work.c:84: warning: Function parameter or member 'data' not described in 'task_work_cancel_match'
by kernel test robot 25 Dec '25

25 Dec '25

Hi Jens, FYI, the error/warning still remains. tree: https://gitee.com/openeuler/kernel.git OLK-5.10 head: 1588d318a9e388d05b6cf5e2a63134c8beb6a355 commit: 8802b2dc61376ea4727dba6630f81697da540e85 [3406/3406] task_work: add helper for more targeted task_work canceling config: arm64-randconfig-003-20251211 (https://download.01.org/0day-ci/archive/20251225/202512250050.7RnKXs39-lkp@…) compiler: aarch64-linux-gcc (GCC) 14.3.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251225/202512250050.7RnKXs39-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512250050.7RnKXs39-lkp@intel.com/ All warnings (new ones prefixed by >>): >> kernel/task_work.c:84: warning: Function parameter or member 'data' not described in 'task_work_cancel_match' vim +84 kernel/task_work.c e73f8959af0439 Oleg Nesterov 2012-05-11 71 892f6668f3a708 Oleg Nesterov 2013-09-11 72 /** 8802b2dc61376e Jens Axboe 2023-02-28 73 * task_work_cancel_match - cancel a pending work added by task_work_add() 892f6668f3a708 Oleg Nesterov 2013-09-11 74 * @task: the task which should execute the work 8802b2dc61376e Jens Axboe 2023-02-28 75 * @match: match function to call 892f6668f3a708 Oleg Nesterov 2013-09-11 76 * 892f6668f3a708 Oleg Nesterov 2013-09-11 77 * RETURNS: 892f6668f3a708 Oleg Nesterov 2013-09-11 78 * The found work or NULL if not found. 892f6668f3a708 Oleg Nesterov 2013-09-11 79 */ 67d1214551e800 Al Viro 2012-06-27 80 struct callback_head * 8802b2dc61376e Jens Axboe 2023-02-28 81 task_work_cancel_match(struct task_struct *task, 8802b2dc61376e Jens Axboe 2023-02-28 82 bool (*match)(struct callback_head *, void *data), 8802b2dc61376e Jens Axboe 2023-02-28 83 void *data) e73f8959af0439 Oleg Nesterov 2012-05-11 @84 { ac3d0da8f3290b Oleg Nesterov 2012-08-26 85 struct callback_head **pprev = &task->task_works; 205e550a0fb469 Oleg Nesterov 2013-09-11 86 struct callback_head *work; e73f8959af0439 Oleg Nesterov 2012-05-11 87 unsigned long flags; 61e96496d3c949 Oleg Nesterov 2016-08-02 88 61e96496d3c949 Oleg Nesterov 2016-08-02 89 if (likely(!task->task_works)) 61e96496d3c949 Oleg Nesterov 2016-08-02 90 return NULL; ac3d0da8f3290b Oleg Nesterov 2012-08-26 91 /* ac3d0da8f3290b Oleg Nesterov 2012-08-26 92 * If cmpxchg() fails we continue without updating pprev. ac3d0da8f3290b Oleg Nesterov 2012-08-26 93 * Either we raced with task_work_add() which added the ac3d0da8f3290b Oleg Nesterov 2012-08-26 94 * new entry before this work, we will find it again. Or 9da33de62431c7 Oleg Nesterov 2012-08-26 95 * we raced with task_work_run(), *pprev == NULL/exited. ac3d0da8f3290b Oleg Nesterov 2012-08-26 96 */ e73f8959af0439 Oleg Nesterov 2012-05-11 97 raw_spin_lock_irqsave(&task->pi_lock, flags); 506458efaf153c Will Deacon 2017-10-24 98 while ((work = READ_ONCE(*pprev))) { 8802b2dc61376e Jens Axboe 2023-02-28 99 if (!match(work, data)) ac3d0da8f3290b Oleg Nesterov 2012-08-26 100 pprev = &work->next; ac3d0da8f3290b Oleg Nesterov 2012-08-26 101 else if (cmpxchg(pprev, work, work->next) == work) 158e1645e07f3e Al Viro 2012-06-27 102 break; 158e1645e07f3e Al Viro 2012-06-27 103 } e73f8959af0439 Oleg Nesterov 2012-05-11 104 raw_spin_unlock_irqrestore(&task->pi_lock, flags); ac3d0da8f3290b Oleg Nesterov 2012-08-26 105 ac3d0da8f3290b Oleg Nesterov 2012-08-26 106 return work; e73f8959af0439 Oleg Nesterov 2012-05-11 107 } e73f8959af0439 Oleg Nesterov 2012-05-11 108 :::::: The code at line 84 was first introduced by commit :::::: e73f8959af0439d114847eab5a8a5ce48f1217c4 task_work_add: generic process-context callbacks :::::: TO: Oleg Nesterov <oleg(a)redhat.com> :::::: CC: Al Viro <viro(a)zeniv.linux.org.uk> -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] [Backport] nvmet-fc: avoid scheduling association deletion twice
by Chen Jinghuang 24 Dec '25

24 Dec '25

From: Daniel Wagner <wagi(a)kernel.org> stable inclusion from stable-v6.6.117 commit 601ed47b2363c24d948d7bac0c23abc8bd459570 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11412 CVE: CVE-2025-40343 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit f2537be4f8421f6495edfa0bc284d722f253841d ] When forcefully shutting down a port via the configfs interface, nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and then nvmet_disable_port(). Both functions will eventually schedule all remaining associations for deletion. The current implementation checks whether an association is about to be removed, but only after the work item has already been scheduled. As a result, it is possible for the first scheduled work item to free all resources, and then for the same work item to be scheduled again for deletion. Because the association list is an RCU list, it is not possible to take a lock and remove the list entry directly, so it cannot be looked up again. Instead, a flag (terminating) must be used to determine whether the association is already in the process of being deleted. Reported-by: Shinichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Closes: https://lore.kernel.org/all/rsdinhafrtlguauhesmrrzkybpnvwantwmyfq2ih5areggh… Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Daniel Wagner <wagi(a)kernel.org> Signed-off-by: Keith Busch <kbusch(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- drivers/nvme/target/fc.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/nvme/target/fc.c b/drivers/nvme/target/fc.c index a15e764bae35..188b9f1bdaca 100644 --- a/drivers/nvme/target/fc.c +++ b/drivers/nvme/target/fc.c @@ -1090,6 +1090,14 @@ nvmet_fc_delete_assoc_work(struct work_struct *work) static void nvmet_fc_schedule_delete_assoc(struct nvmet_fc_tgt_assoc *assoc) { + int terminating; + + terminating = atomic_xchg(&assoc->terminating, 1); + + /* if already terminating, do nothing */ + if (terminating) + return; + nvmet_fc_tgtport_get(assoc->tgtport); if (!queue_work(nvmet_wq, &assoc->del_work)) nvmet_fc_tgtport_put(assoc->tgtport); @@ -1209,13 +1217,7 @@ nvmet_fc_delete_target_assoc(struct nvmet_fc_tgt_assoc *assoc) { struct nvmet_fc_tgtport *tgtport = assoc->tgtport; unsigned long flags; - int i, terminating; - - terminating = atomic_xchg(&assoc->terminating, 1); - - /* if already terminating, do nothing */ - if (terminating) - return; + int i; spin_lock_irqsave(&tgtport->lock, flags); list_del_rcu(&assoc->a_list); -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] md/raid10: fix null-ptr-deref in raid10_sync_request
by Zheng Qixing 24 Dec '25

24 Dec '25

From: Li Nan <linan122(a)huawei.com> stable inclusion from stable-v4.19.283 commit 38d33593260536840b49fd1dcac9aedfd14a9d42 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDBOQL CVE: CVE-2023-53832 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ commit a405c6f0229526160aa3f177f65e20c86fce84c5 upstream. init_resync() inits mempool and sets conf->have_replacemnt at the beginning of sync, close_sync() frees the mempool when sync is completed. After [1] recovery might be skipped and init_resync() is called but close_sync() is not. null-ptr-deref occurs with r10bio->dev[i].repl_bio. The following is one way to reproduce the issue. 1) create a array, wait for resync to complete, mddev->recovery_cp is set to MaxSector. 2) recovery is woken and it is skipped. conf->have_replacement is set to 0 in init_resync(). close_sync() not called. 3) some io errors and rdev A is set to WantReplacement. 4) a new device is added and set to A's replacement. 5) recovery is woken, A have replacement, but conf->have_replacemnt is 0. r10bio->dev[i].repl_bio will not be alloced and null-ptr-deref occurs. Fix it by not calling init_resync() if recovery skipped. [1] commit 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled") Fixes: 7e83ccbecd60 ("md/raid10: Allow skipping recovery when clean arrays are assembled") Cc: stable(a)vger.kernel.org Signed-off-by: Li Nan <linan122(a)huawei.com> Signed-off-by: Song Liu <song(a)kernel.org> Link: https://lore.kernel.org/r/20230222041000.3341651-3-linan666@huaweicloud.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/md/raid10.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index 5f0a20174979..67493be59f7f 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -2989,10 +2989,6 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, sector_t chunk_mask = conf->geo.chunk_mask; int page_idx = 0; - if (!mempool_initialized(&conf->r10buf_pool)) - if (init_resync(conf)) - return 0; - /* * Allow skipping a full rebuild for incremental assembly * of a clean array, like RAID1 does. @@ -3008,6 +3004,10 @@ static sector_t raid10_sync_request(struct mddev *mddev, sector_t sector_nr, return mddev->dev_sectors - sector_nr; } + if (!mempool_initialized(&conf->r10buf_pool)) + if (init_resync(conf)) + return 0; + skipped: max_sector = mddev->dev_sectors; if (test_bit(MD_RECOVERY_SYNC, &mddev->recovery) || -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] scsi: sg: Do not sleep in atomic context
by Zheng Qixing 24 Dec '25

24 Dec '25

From: Bart Van Assche <bvanassche(a)acm.org> mainline inclusion from mainline-v6.18-rc7 commit 90449f2d1e1f020835cba5417234636937dd657e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDATPD CVE: CVE-2025-40259 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ------------------ sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled. Reported-by: syzbot+c01f8e6e73f20459912e(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google… Cc: Hannes Reinecke <hare(a)suse.de> Cc: stable(a)vger.kernel.org Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/scsi/sg.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index 7c9c63be214d..4698b79a62ff 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -2208,9 +2208,17 @@ sg_remove_sfp_usercontext(struct work_struct *work) write_lock_irqsave(&sfp->rq_list_lock, iflags); while (!list_empty(&sfp->rq_list)) { srp = list_first_entry(&sfp->rq_list, Sg_request, entry); - sg_finish_rem_req(srp); list_del(&srp->entry); + write_unlock_irqrestore(&sfp->rq_list_lock, iflags); + + sg_finish_rem_req(srp); + /* + * sg_rq_end_io() uses srp->parentfp. Hence, only clear + * srp->parentfp after blk_mq_free_request() has been called. + */ srp->parentfp = NULL; + + write_lock_irqsave(&sfp->rq_list_lock, iflags); } write_unlock_irqrestore(&sfp->rq_list_lock, iflags); -- 2.39.2

2 1

[PATCH OLK-5.10] scsi: sg: Do not sleep in atomic context
by Zheng Qixing 24 Dec '25

24 Dec '25

From: Bart Van Assche <bvanassche(a)acm.org> stable inclusion from stable-v5.10.247 commit db6ac8703ab2b473e1ec845f57f6dd961a388d9f category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDATPD CVE: CVE-2025-40259 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ------------------ commit 90449f2d1e1f020835cba5417234636937dd657e upstream. sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled. Reported-by: syzbot+c01f8e6e73f20459912e(a)syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google… Cc: Hannes Reinecke <hare(a)suse.de> Cc: stable(a)vger.kernel.org Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Zheng Qixing <zhengqixing(a)huawei.com> --- drivers/scsi/sg.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c index fbd973b184bb..98baa9cd46bf 100644 --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -2235,9 +2235,17 @@ sg_remove_sfp_usercontext(struct work_struct *work) write_lock_irqsave(&sfp->rq_list_lock, iflags); while (!list_empty(&sfp->rq_list)) { srp = list_first_entry(&sfp->rq_list, Sg_request, entry); - sg_finish_rem_req(srp); list_del(&srp->entry); + write_unlock_irqrestore(&sfp->rq_list_lock, iflags); + + sg_finish_rem_req(srp); + /* + * sg_rq_end_io() uses srp->parentfp. Hence, only clear + * srp->parentfp after blk_mq_free_request() has been called. + */ srp->parentfp = NULL; + + write_lock_irqsave(&sfp->rq_list_lock, iflags); } write_unlock_irqrestore(&sfp->rq_list_lock, iflags); -- 2.39.2

2 1