mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 55 participants
  • 22179 discussions
[openeuler:OLK-6.6 3544/3544] drivers/video/fbdev/ls2k500sfb.c:143:27: sparse: sparse: incorrect type in assignment (different address spaces)
by kernel test robot 24 Dec '25

24 Dec '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: c098fa18c07cc52100a52db8fd0c2900461888c9 commit: 8248d42b7c5f4338a54f26d8efebec8614b43466 [3544/3544] fbdev: add ls2k500sfb driver for ls2k500 bmc. config: x86_64-randconfig-r121-20251215 (https://download.01.org/0day-ci/archive/20251224/202512240049.8n7uFL15-lkp@…) compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251224/202512240049.8n7uFL15-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/202512240049.8n7uFL15-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/video/fbdev/ls2k500sfb.c:143:27: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected void *static p @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:143:27: sparse: expected void *static p drivers/video/fbdev/ls2k500sfb.c:143:27: sparse: got void [noderef] __iomem * >> drivers/video/fbdev/ls2k500sfb.c:145:30: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void *static p @@ drivers/video/fbdev/ls2k500sfb.c:145:30: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:145:30: sparse: got void *static p >> drivers/video/fbdev/ls2k500sfb.c:199:36: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got void *static p @@ drivers/video/fbdev/ls2k500sfb.c:199:36: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:199:36: sparse: got void *static p >> drivers/video/fbdev/ls2k500sfb.c:201:37: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got void * @@ drivers/video/fbdev/ls2k500sfb.c:201:37: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:201:37: sparse: got void * >> drivers/video/fbdev/ls2k500sfb.c:254:13: sparse: sparse: symbol 'ls2k500sfb_interrupt' was not declared. Should it be static? >> drivers/video/fbdev/ls2k500sfb.c:456:28: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const volatile [noderef] __iomem *addr @@ got char *preg @@ drivers/video/fbdev/ls2k500sfb.c:456:28: sparse: expected void const volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:456:28: sparse: got char *preg >> drivers/video/fbdev/ls2k500sfb.c:457:32: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void volatile [noderef] __iomem *addr @@ got char *preg @@ drivers/video/fbdev/ls2k500sfb.c:457:32: sparse: expected void volatile [noderef] __iomem *addr drivers/video/fbdev/ls2k500sfb.c:457:32: sparse: got char *preg >> drivers/video/fbdev/ls2k500sfb.c:569:19: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char *penv @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:569:19: sparse: expected char *penv drivers/video/fbdev/ls2k500sfb.c:569:19: sparse: got void [noderef] __iomem * >> drivers/video/fbdev/ls2k500sfb.c:570:19: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char *preg @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:570:19: sparse: expected char *preg drivers/video/fbdev/ls2k500sfb.c:570:19: sparse: got void [noderef] __iomem * drivers/video/fbdev/ls2k500sfb.c:671:14: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected char *penv @@ got void [noderef] __iomem * @@ drivers/video/fbdev/ls2k500sfb.c:671:14: sparse: expected char *penv drivers/video/fbdev/ls2k500sfb.c:671:14: sparse: got void [noderef] __iomem * vim +143 drivers/video/fbdev/ls2k500sfb.c 113 114 static void ls2k500sfb_events_fn(struct work_struct *work) 115 { 116 struct ls2k500sfb_struct *priv = container_of(work, struct ls2k500sfb_struct, work); 117 struct pci_dev *pdev = priv->dev; 118 struct pci_dev *ppdev = pdev->bus->self; 119 uint32_t i, d, timeout, retry = 0; 120 static const uint32_t index[] = { 121 0x10, 0x14, 0x18, 0x1c, 0x20, 0x24, 0x30, 0x3c, 0x54, 0x58, 0x78, 0x7c, 0x80, 4 122 }; 123 124 static uint32_t data[sizeof(index) / 4]; 125 static const uint32_t cindex[] = { 0x10, 0x3c, 4 }; 126 127 static uint32_t cdata[sizeof(cindex) / 4]; 128 static uint32_t d80c, d71c, ctrl; 129 static void *p; 130 131 if (!priv->running) { 132 for (i = 0; i < ARRAY_SIZE(index); i++) 133 pci_read_config_dword(ppdev, index[i], &data[i]); 134 for (i = 0; i < ARRAY_SIZE(cindex); i++) 135 pci_read_config_dword(pdev, cindex[i], &cdata[i]); 136 if (ppdev->vendor == 0x14) { 137 pci_read_config_dword(ppdev, 0x80c, &d80c); 138 d80c = (d80c & ~(3 << 17)) | (1 << 17); 139 140 pci_read_config_dword(ppdev, 0x71c, &d71c); 141 d71c |= 1 << 26; 142 > 143 p = pci_iomap(ppdev, 0, 0x100); 144 } > 145 ctrl = readl(p); 146 return; 147 } 148 local_bh_disable(); 149 pciebreak_smp_send_stop(100); 150 wmb(); /* flush all write before we disable pcie window */ 151 pci_write_config_dword(ppdev, 0x18, 0); 152 pci_write_config_dword(ppdev, 0x1c, 0); 153 pci_write_config_dword(ppdev, 0x20, 0); 154 atomic_set(&waiting_for_pciebreak_ipi, 0); 155 wmb(); /* flush all write after change pcie window */ 156 local_bh_enable(); 157 if (ppdev->vendor == 0x14) { 158 timeout = 10000; 159 while (timeout) { 160 pci_read_config_dword(ppdev, 0x10, &d); 161 d &= ~0xf; 162 if (!d) 163 break; 164 mdelay(1); 165 timeout--; 166 }; 167 if (!timeout) 168 pr_info("bar not clear 0\n"); 169 170 pci_read_config_dword(ppdev, 0x0, &d); 171 pr_info("pcie port deviceid=0x%x recover begin\n", d); 172 retrain: 173 while (1) { 174 pci_write_config_dword(ppdev, index[0], data[0]); 175 pci_read_config_dword(ppdev, index[0], &d); 176 d &= ~0xf; 177 if (d) 178 break; 179 mdelay(1); 180 } 181 182 while (1) { 183 for (i = 0; i < ARRAY_SIZE(index); i++) { 184 if (index[i] != 0x18 && index[i] != 0x1c && index[i] != 0x20) 185 pci_write_config_dword(ppdev, index[i], data[i]); 186 } 187 pci_write_config_dword(ppdev, 0x80c, d80c); 188 pci_write_config_dword(ppdev, 0x71c, d71c); 189 190 pci_read_config_dword(ppdev, 0x10, &d); 191 d &= ~0xf; 192 if (d) 193 break; 194 mdelay(1); 195 } 196 197 timeout = 10000; 198 > 199 writel(ctrl | 0x8, p); 200 while (1) { > 201 d = readl(p + 0xc); 202 if ((d & 0x11) == 0x11) { 203 break; 204 } else if (!timeout) { 205 pr_info("pcie train failed status=0x%x\n", d); 206 goto out; 207 } 208 mdelay(1); 209 timeout--; 210 } 211 212 213 pr_info("pcie recovered done\n"); 214 215 if (!retry) { 216 /*wait u-boot ddr config */ 217 set_current_state(TASK_UNINTERRUPTIBLE); 218 schedule_timeout(HZ*resetbootwait); 219 set_current_state(TASK_RUNNING); 220 pci_read_config_dword(ppdev, 0x10, &d); 221 d &= ~0xf; 222 if (!d) { 223 retry = 1; 224 goto retrain; 225 } 226 } 227 } else { 228 set_current_state(TASK_UNINTERRUPTIBLE); 229 schedule_timeout(HZ*resetbootwait); 230 set_current_state(TASK_RUNNING); 231 } 232 local_bh_disable(); 233 pciebreak_smp_send_stop(10000); 234 wmb(); /* flush all write before we update pcie window */ 235 for (i = 0; i < ARRAY_SIZE(index); i++) 236 pci_write_config_dword(ppdev, index[i], data[i]); 237 238 for (i = 0; i < ARRAY_SIZE(cindex); i++) 239 pci_write_config_dword(pdev, cindex[i], cdata[i]); 240 atomic_set(&waiting_for_pciebreak_ipi, 0); 241 wmb(); /* flush all write after we update pcie window */ 242 local_bh_enable(); 243 244 245 pr_info("redraw console\n"); 246 247 saved_console = fg_console; 248 switch_console(fg_console > 0?fg_console - 1 : fg_console + 1); 249 queue_delayed_work(priv->wq, &priv->redraw_work, HZ); 250 out: 251 priv->running = 0; 252 } 253 > 254 irqreturn_t ls2k500sfb_interrupt(int irq, void *arg) 255 { 256 struct ls2k500sfb_struct *priv = arg; 257 struct pci_dev *pdev = priv->dev; 258 259 if (irq == pdev->irq) 260 pr_info("ls2k500sfb pcie interrupt\n"); 261 else 262 pr_info("ls2k500sfb gpio interrupt\n"); 263 if (system_state != SYSTEM_RUNNING) 264 return IRQ_HANDLED; 265 266 if (!priv->running) { 267 if (!resetdelay || time_after(jiffies, priv->reset_time + resetdelay * HZ)) { 268 priv->running = 1; 269 queue_work(priv->wq, &priv->work); 270 } 271 priv->reset_time = jiffies; 272 } 273 return IRQ_HANDLED; 274 } 275 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-6.6 2/2] drivers/crypto/ccp/hygon/hct.c:2175:30: sparse: sparse: symbol 'hct_noiommu_fops' was not declared. Should it be static?
by kernel test robot 23 Dec '25

23 Dec '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: c098fa18c07cc52100a52db8fd0c2900461888c9 commit: 6e2db6d2859f5c41ff51b696235dc3971f4bcd22 [2/2] hct: supporting memory encryption in host and wb set in vm config: x86_64-randconfig-123-20251223 (https://download.01.org/0day-ci/archive/20251223/202512232326.ySrpmNr0-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251223/202512232326.ySrpmNr0-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/202512232326.ySrpmNr0-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) drivers/crypto/ccp/hygon/hct.c:246:18: sparse: sparse: symbol 'hct_mdev_type' was not declared. Should it be static? drivers/crypto/ccp/hygon/hct.c:250:18: sparse: sparse: symbol 'hct_mdev_types' was not declared. Should it be static? drivers/crypto/ccp/hygon/hct.c:472:23: sparse: sparse: cast to restricted __le32 drivers/crypto/ccp/hygon/hct.c:1217:20: sparse: sparse: symbol 'hct_mdev_driver' was not declared. Should it be static? drivers/crypto/ccp/hygon/hct.c:1346:13: sparse: sparse: symbol 'hct_pin_memory' was not declared. Should it be static? drivers/crypto/ccp/hygon/hct.c:2080:6: sparse: sparse: symbol 'hct_noiommu_set_memory_wb' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/hct.c:2175:30: sparse: sparse: symbol 'hct_noiommu_fops' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/hct.c:2180:19: sparse: sparse: symbol 'hct_noiommu_misc' was not declared. Should it be static? vim +/hct_noiommu_fops +2175 drivers/crypto/ccp/hygon/hct.c 2174 > 2175 const struct file_operations hct_noiommu_fops = { 2176 .owner = THIS_MODULE, 2177 .unlocked_ioctl = hct_noiommu_ioctl, 2178 }; 2179 > 2180 struct miscdevice hct_noiommu_misc = { 2181 .minor = MISC_DYNAMIC_MINOR, 2182 .name = "hct_noiommu", 2183 .fops = &hct_noiommu_fops, 2184 }; 2185 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[openeuler:OLK-6.6 2/2] drivers/crypto/ccp/hygon/hct.c:233:18: sparse: sparse: symbol 'hct_mdev_type' was not declared. Should it be static?
by kernel test robot 23 Dec '25

23 Dec '25
tree: https://gitee.com/openeuler/kernel.git OLK-6.6 head: c098fa18c07cc52100a52db8fd0c2900461888c9 commit: c74ae2c5da57becf3f41c596d79b3dd30fa1baa6 [2/2] hct: add mediated ccp driver support for hygon crypto technology. config: x86_64-randconfig-123-20251223 (https://download.01.org/0day-ci/archive/20251223/202512232143.LPloCdRW-lkp@…) compiler: gcc-14 (Debian 14.2.0-19) 14.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251223/202512232143.LPloCdRW-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/202512232143.LPloCdRW-lkp@intel.com/ sparse warnings: (new ones prefixed by >>) >> drivers/crypto/ccp/hygon/hct.c:233:18: sparse: sparse: symbol 'hct_mdev_type' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/hct.c:237:18: sparse: sparse: symbol 'hct_mdev_types' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/hct.c:459:23: sparse: sparse: cast to restricted __le32 >> drivers/crypto/ccp/hygon/hct.c:1204:20: sparse: sparse: symbol 'hct_mdev_driver' was not declared. Should it be static? >> drivers/crypto/ccp/hygon/hct.c:1333:13: sparse: sparse: symbol 'hct_pin_memory' was not declared. Should it be static? vim +/hct_mdev_type +233 drivers/crypto/ccp/hygon/hct.c 232 > 233 struct mdev_type hct_mdev_type = { 234 .sysfs_name = "1", 235 .pretty_name = "hct mdev type" 236 }; > 237 struct mdev_type *hct_mdev_types[] = { 238 &hct_mdev_type 239 }; 240 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
1 0
0 0
[PATCH OLK-6.6] ftrace: Fix softlockup in ftrace_module_enable
by Tengda Wu 23 Dec '25

23 Dec '25
From: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> stable inclusion from stable-v6.6.119 commit e81e6d6d99b16dae11adbeda5c996317942a940c category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11609 CVE: CVE-2025-68173 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4099b98203d6b33d990586542fa5beee408032a3 ] A soft lockup was observed when loading amdgpu module. If a module has a lot of tracable functions, multiple calls to kallsyms_lookup can spend too much time in RCU critical section and with disabled preemption, causing kernel panic. This is the same issue that was fixed in commit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARY kernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() to ftrace_graph_set_hash()"). Fix it the same way by adding cond_resched() in ftrace_module_enable. Link: https://lore.kernel.org/aMQD9_lxYmphT-up@vova-pc Signed-off-by: Vladimir Riabchun <ferr.lambarginio(a)gmail.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Tengda Wu <wutengda2(a)huawei.com> --- kernel/trace/ftrace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c index 15785a729a0c..398992597685 100644 --- a/kernel/trace/ftrace.c +++ b/kernel/trace/ftrace.c @@ -6873,6 +6873,8 @@ void ftrace_module_enable(struct module *mod) if (!within_module(rec->ip, mod)) break; + cond_resched(); + /* Weak functions should still be ignored */ if (!test_for_valid_rec(rec)) { /* Clear all other flags. Should not be enabled anyway */ -- 2.34.1
2 1
0 0
[PATCH] [Backport] nvmet-fc: avoid scheduling association deletion twice
by Chen Jinghuang 23 Dec '25

23 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
1 0
0 0
[PATCH OLK-6.6 v2] bpf: account for current allocated stack depth in widen_imprecise_scalars()
by Pu Lehui 23 Dec '25

23 Dec '25
From: Eduard Zingerman <eddyz87(a)gmail.com> stable inclusion from stable-v6.6.117 commit 64b12dca2b0abcb5fc0542887d18b926ea5cf711 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11581 CVE: CVE-2025-68208 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b0c8e6d3d866b6a7f73877f71968dbffd27b7785 ] The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st); Where prev_st is an ancestor of the queued_st in the explored states tree. This ancestor is not guaranteed to have same allocated stack depth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loop Here, for a second 'foo' call prev_st->allocated_stack is 128, while queued_st->allocated_stack is much smaller. widen_imprecise_scalars() needs to take this into account and avoid accessing bpf_verifier_state->frame[*]->stack out of bounds. Fixes: 2793a8b015f7 ("bpf: exact states comparison for iterator convergence checks") Reported-by: Emil Tsalapatis <emil(a)etsalapatis.com> Signed-off-by: Eduard Zingerman <eddyz87(a)gmail.com> Link: https://lore.kernel.org/r/20251114025730.772723-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/bpf/verifier.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index 26086c893dfb..ce1f5a9bdd9a 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -7918,7 +7918,7 @@ static int widen_imprecise_scalars(struct bpf_verifier_env *env, struct bpf_verifier_state *cur) { struct bpf_func_state *fold, *fcur; - int i, fr; + int i, fr, num_slots; reset_idmap_scratch(env); for (fr = old->curframe; fr >= 0; fr--) { @@ -7931,7 +7931,9 @@ static int widen_imprecise_scalars(struct bpf_verifier_env *env, &fcur->regs[i], &env->idmap_scratch); - for (i = 0; i < fold->allocated_stack / BPF_REG_SIZE; i++) { + num_slots = min(fold->allocated_stack / BPF_REG_SIZE, + fcur->allocated_stack / BPF_REG_SIZE); + for (i = 0; i < num_slots; i++) { if (!is_spilled_reg(&fold->stack[i]) || !is_spilled_reg(&fcur->stack[i])) continue; -- 2.34.1
2 1
0 0
[PATCH OLK-6.6 v2] bpf: Add bpf_prog_run_data_pointers()
by Pu Lehui 23 Dec '25

23 Dec '25
From: Eric Dumazet <edumazet(a)google.com> stable inclusion from stable-v6.6.117 commit baa61dcaa50b7141048c8d2aede7fe9ed8f21d11 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/11594 CVE: CVE-2025-68200 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 4ef92743625818932b9c320152b58274c05e5053 ] syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end. Fixes: ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block") Reported-by: syzbot <syzkaller(a)googlegroups.com> Closes: https://lore.kernel.org/netdev/6913437c.a70a0220.22f260.013b.GAE@google.com/ Signed-off-by: Eric Dumazet <edumazet(a)google.com> Signed-off-by: Martin KaFai Lau <martin.lau(a)kernel.org> Reviewed-by: Victor Nogueira <victor(a)mojatatu.com> Acked-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Link: https://patch.msgid.link/20251112125516.1563021-1-edumazet@google.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: net/sched/act_bpf.c net/sched/cls_bpf.c [ctx conflicts] Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- include/linux/filter.h | 20 ++++++++++++++++++++ net/sched/act_bpf.c | 6 ++---- net/sched/cls_bpf.c | 6 ++---- 3 files changed, 24 insertions(+), 8 deletions(-) diff --git a/include/linux/filter.h b/include/linux/filter.h index a7c0caa8b7ad..4ae423d8533f 100644 --- a/include/linux/filter.h +++ b/include/linux/filter.h @@ -685,6 +685,26 @@ static inline void bpf_compute_data_pointers(struct sk_buff *skb) cb->data_end = skb->data + skb_headlen(skb); } +static inline int bpf_prog_run_data_pointers( + const struct bpf_prog *prog, + struct sk_buff *skb) +{ + struct bpf_skb_data_end *cb = (struct bpf_skb_data_end *)skb->cb; + void *save_data_meta, *save_data_end; + int res; + + save_data_meta = cb->data_meta; + save_data_end = cb->data_end; + + bpf_compute_data_pointers(skb); + res = bpf_prog_run(prog, skb); + + cb->data_meta = save_data_meta; + cb->data_end = save_data_end; + + return res; +} + /* Similar to bpf_compute_data_pointers(), except that save orginal * data in cb->data and cb->meta_data for restore. */ diff --git a/net/sched/act_bpf.c b/net/sched/act_bpf.c index b0455fda7d0b..223cc157312a 100644 --- a/net/sched/act_bpf.c +++ b/net/sched/act_bpf.c @@ -47,12 +47,10 @@ TC_INDIRECT_SCOPE int tcf_bpf_act(struct sk_buff *skb, filter = rcu_dereference(prog->filter); if (at_ingress) { __skb_push(skb, skb->mac_len); - bpf_compute_data_pointers(skb); - filter_res = bpf_prog_run(filter, skb); + filter_res = bpf_prog_run_data_pointers(filter, skb); __skb_pull(skb, skb->mac_len); } else { - bpf_compute_data_pointers(skb); - filter_res = bpf_prog_run(filter, skb); + filter_res = bpf_prog_run_data_pointers(filter, skb); } if (unlikely(!skb->tstamp && skb->mono_delivery_time)) skb->mono_delivery_time = 0; diff --git a/net/sched/cls_bpf.c b/net/sched/cls_bpf.c index 382c7a71f81f..05f718dd09a6 100644 --- a/net/sched/cls_bpf.c +++ b/net/sched/cls_bpf.c @@ -97,12 +97,10 @@ TC_INDIRECT_SCOPE int cls_bpf_classify(struct sk_buff *skb, } else if (at_ingress) { /* It is safe to push/pull even if skb_shared() */ __skb_push(skb, skb->mac_len); - bpf_compute_data_pointers(skb); - filter_res = bpf_prog_run(prog->filter, skb); + filter_res = bpf_prog_run_data_pointers(prog->filter, skb); __skb_pull(skb, skb->mac_len); } else { - bpf_compute_data_pointers(skb); - filter_res = bpf_prog_run(prog->filter, skb); + filter_res = bpf_prog_run_data_pointers(prog->filter, skb); } if (unlikely(!skb->tstamp && skb->mono_delivery_time)) skb->mono_delivery_time = 0; -- 2.34.1
2 1
0 0
[PATCH OLK-6.6] [Backport] nvmet-fc: avoid scheduling association deletion twice
by Chen Jinghuang 23 Dec '25

23 Dec '25
From: Daniel Wagner <wagi(a)kernel.org> stable inclusion from stable-v6.6.117 commit 601ed47b2363c24d948d7bac0c23abc8bd459570 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDBQL1 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
0 0
[PATCH OLK-5.10] scsi/hiraid: Support New Raid feature
by LinKun 23 Dec '25

23 Dec '25
From: 岳智超 <yuezhichao1(a)h-partners.com> driver inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/8290 CVE: NA -------------------------------- Add thread irq for io queue Signed-off-by: 岳智超 <yuezhichao1(a)h-partners.com> --- drivers/scsi/hisi_raid/hiraid.h | 1 + drivers/scsi/hisi_raid/hiraid_main.c | 60 ++++++++++++++++++++++++++-- 2 files changed, 58 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/hisi_raid/hiraid.h b/drivers/scsi/hisi_raid/hiraid.h index 04b2e25..b786066 100644 --- a/drivers/scsi/hisi_raid/hiraid.h +++ b/drivers/scsi/hisi_raid/hiraid.h @@ -686,6 +686,7 @@ struct hiraid_queue { atomic_t inflight; void *sense_buffer_virt; dma_addr_t sense_buffer_phy; + s32 pci_irq; struct dma_pool *prp_small_pool; }; diff --git a/drivers/scsi/hisi_raid/hiraid_main.c b/drivers/scsi/hisi_raid/hiraid_main.c index 2f33339..ee5cb10 100644 --- a/drivers/scsi/hisi_raid/hiraid_main.c +++ b/drivers/scsi/hisi_raid/hiraid_main.c @@ -107,6 +107,13 @@ static u32 log_debug_switch; module_param(log_debug_switch, uint, 0644); MODULE_PARM_DESC(log_debug_switch, "set log state, default zero for switch off"); +static bool threaded_irq = true; +module_param(threaded_irq, bool, 0444); +MODULE_PARM_DESC(threaded_irq, "use threaded irq for io queue, default on"); + +static u32 poll_delay_min = 9; +static u32 poll_delay_max = 19; + static int extra_pool_num_set(const char *val, const struct kernel_param *kp) { u8 n = 0; @@ -152,7 +159,7 @@ static struct workqueue_struct *work_queue; __func__, ##__VA_ARGS__); \ } while (0) -#define HIRAID_DRV_VERSION "1.1.0.1" +#define HIRAID_DRV_VERSION "1.1.0.2" #define ADMIN_TIMEOUT (admin_tmout * HZ) #define USRCMD_TIMEOUT (180 * HZ) @@ -1305,6 +1312,7 @@ static int hiraid_alloc_queue(struct hiraid_dev *hdev, u16 qid, u16 depth) hiraidq->q_depth = depth; hiraidq->qid = qid; hiraidq->cq_vector = -1; + hiraidq->pci_irq = -1; hdev->queue_count++; return 0; @@ -1631,6 +1639,39 @@ static irqreturn_t hiraid_handle_irq(int irq, void *data) return ret; } +static irqreturn_t hiraid_io_poll(int irq, void *data) +{ + struct hiraid_queue *hiraidq = data; + irqreturn_t ret = IRQ_NONE; + u16 start, end; + + do { + spin_lock(&hiraidq->cq_lock); + hiraid_process_cq(hiraidq, &start, &end, -1); + hiraidq->last_cq_head = hiraidq->cq_head; + spin_unlock(&hiraidq->cq_lock); + + if (start != end) { + hiraid_complete_cqes(hiraidq, start, end); + ret = IRQ_HANDLED; + } + usleep_range(poll_delay_min, poll_delay_max); + } while (start != end); + enable_irq(hiraidq->pci_irq); + return ret; +} + +static irqreturn_t hiraid_io_irq(int irq, void *data) +{ + struct hiraid_queue *q = data; + + if (hiraid_cqe_pending(q)) { + disable_irq_nosync(q->pci_irq); + return IRQ_WAKE_THREAD; + } + return IRQ_NONE; +} + static int hiraid_setup_admin_queue(struct hiraid_dev *hdev) { struct hiraid_queue *adminq = &hdev->queues[0]; @@ -1666,9 +1707,11 @@ static int hiraid_setup_admin_queue(struct hiraid_dev *hdev) adminq, "hiraid%d_q%d", hdev->instance, adminq->qid); if (ret) { adminq->cq_vector = -1; + adminq->pci_irq = -1; return ret; } + adminq->pci_irq = pci_irq_vector(hdev->pdev, adminq->cq_vector); hiraid_init_queue(adminq, 0); dev_info(hdev->dev, "setup admin queue success, queuecount[%d] online[%d] pagesize[%d]\n", @@ -1937,14 +1980,23 @@ static int hiraid_create_queue(struct hiraid_queue *hiraidq, u16 qid) goto delete_cq; hiraidq->cq_vector = cq_vector; - ret = pci_request_irq(hdev->pdev, cq_vector, hiraid_handle_irq, NULL, - hiraidq, "hiraid%d_q%d", hdev->instance, qid); + + if (threaded_irq) + ret = pci_request_irq(hdev->pdev, cq_vector, hiraid_io_irq, + hiraid_io_poll, hiraidq, "hiraid%d_q%d", + hdev->instance, qid); + else + ret = pci_request_irq(hdev->pdev, cq_vector, hiraid_handle_irq, + NULL, hiraidq, "hiraid%d_q%d", + hdev->instance, qid); if (ret) { hiraidq->cq_vector = -1; + hiraidq->pci_irq = -1; dev_err(hdev->dev, "request queue[%d] irq failed\n", qid); goto delete_sq; } + hiraidq->pci_irq = pci_irq_vector(hdev->pdev, hiraidq->cq_vector); hiraid_init_queue(hiraidq, qid); return 0; @@ -2094,10 +2146,12 @@ static int hiraid_setup_io_queues(struct hiraid_dev *hdev) adminq, "hiraid%d_q%d", hdev->instance, adminq->qid); if (ret) { dev_err(hdev->dev, "request admin irq failed\n"); + adminq->pci_irq = -1; adminq->cq_vector = -1; return ret; } + adminq->pci_irq = pci_irq_vector(hdev->pdev, adminq->cq_vector); hdev->online_queues++; for (i = hdev->queue_count; i <= hdev->max_qid; i++) { -- 2.45.1.windows.1
2 1
0 0
[PATCH OLK-6.6 0/1] iommu: set the default iommu-dma mode as non-strict
by Qinxin Xia 23 Dec '25

23 Dec '25
driver inclusion category: feature bugzilla: https://atomgit.com/openeuler/kernel/issues/8292 ---------------------------------------------------------------------- The non-strict smmu mode has significant performance gains and can resolve the nvme soft lockup problem. We enable it by default. Currently, many peripherals are faster than before. For example, the top speed of the older netcard is 10Gb/s, and now it's more than 25Gb/s. But when iommu page-table mapping enabled, it's hard to reach the top speed in strict mode, because of frequently map and unmap operations. In order to keep abreast of the times, I think it's better to set non-strict as default. Below it's our iperf performance data of 25Gb netcard: strict mode: 18-20 Gb/s non-strict mode: 23.5 Gb/s Qinxin Xia (1): iommu: set the default iommu-dma mode as non-strict Documentation/admin-guide/kernel-parameters.txt | 2 +- arch/arm64/configs/openeuler_defconfig | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.33.0
2 2
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • ...
  • 2218
  • Older →

HyperKitty Powered by HyperKitty