July 2025 - Kernel - mailweb.openeuler.org

[PATCH OLK-6.6 0/6] hns3: Fix debugfs inconsistency and optimize driver code (stack usage, timer init, readability)
by huangdonghua 11 Jul '25

11 Jul '25

This patchset fixes debugfs query inconsistencies and optimizes the hns3 driver by reducing stack usage, improving timer initialization, and enhancing array handling readability. These changes improve the reliability and maintainability of the hns3 networking driver. Arnd Bergmann (1): net: hns3: reduce stack usage in hclge_dbg_dump_tm_pri() Hao Lan (1): net: hns3: Resolved the issue that the debugfs query result is inconsistent. Jian Shen (1): net: hns3: initialize reset_timer before hclgevf_misc_irq_init() Zhang Zekun (1): net: hns3: Use ARRAY_SIZE() to improve readability huangdonghua (2): Revert "net: hns3: initialize reset_timer before hclgevf_misc_irq_init()" Revert "net: hns3: Resolved the issue that the debugfs query result is inconsistent." drivers/net/ethernet/hisilicon/hns3/hnae3.h | 3 - .../ethernet/hisilicon/hns3/hns3_debugfs.c | 98 ++++++------------- .../hisilicon/hns3/hns3pf/hclge_debugfs.c | 21 ++-- .../hisilicon/hns3/hns3vf/hclgevf_main.c | 2 + .../hisilicon/hns3/hns3vf/hclgevf_regs.c | 8 +- 5 files changed, 51 insertions(+), 81 deletions(-) -- 2.33.0

2 7

[PATCH 01/23] Revert "net: hns3: initialize reset_timer before hclgevf_misc_irq_init()"
by huangdonghua 11 Jul '25

11 Jul '25

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICHMW9 ---------------------------------------------------------------------- This reverts commit 9e4dbb8ada72a05c2a7547b351b41ceec287be07. Fixes: 9e4dbb8ada72 ("net: hns3: initialize reset_timer before hclgevf_misc_irq_init()") Signed-off-by: Donghua Huang <huangdonghua3(a)h-partners.com> --- drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c index e49eef9aa3fe..b41fc70e147c 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c @@ -2398,7 +2398,6 @@ static void hclgevf_state_init(struct hclgevf_dev *hdev) clear_bit(HCLGEVF_STATE_RST_FAIL, &hdev->state); INIT_DELAYED_WORK(&hdev->service_task, hclgevf_service_task); - timer_setup(&hdev->reset_timer, hclgevf_reset_timer, 0); mutex_init(&hdev->mbx_resp.mbx_mutex); sema_init(&hdev->reset_sem, 1); @@ -3103,6 +3102,7 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev) HCLGEVF_DRIVER_NAME); hclgevf_task_schedule(hdev, round_jiffies_relative(HZ)); + timer_setup(&hdev->reset_timer, hclgevf_reset_timer, 0); return 0; -- 2.33.0

1 5

[PATCH OLK-6.6] drm: phytium: fix NULL dereference issue in drm_gem_object_free
by Li Chen 11 Jul '25

11 Jul '25

From: Li Chen <chenl311(a)chinatelecom.cn> driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICGG2A ---------------------------------------------------------------------- Syzkaller crashed kernel in drm path. The root cause is that phytium_drm_gem_object_funcs is not assigned before phytium_gem_create_object enters the failed_dma_alloc label. Let's fix this issue by assigning the function earlier. Below is the crash log: ``` [ 9042.703078] [drm:phytium_gem_create_object [phytium_dc_drm]] *ERROR* fail to allocate vram buffer with size 3de4000 [ 9042.717862] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 9042.727173] fuse: Unknown parameter '0xffffffffffffffff<r00000000000000000000' [ 9042.730383] Mem abort info: [ 9042.745443] ESR = 0x0000000096000006 [ 9042.745446] EC = 0x25: DABT (current EL), IL = 32 bits [ 9042.745448] SET = 0, FnV = 0 [ 9042.745450] EA = 0, S1PTW = 0 [ 9042.745451] FSC = 0x06: level 2 translation fault [ 9042.745453] Data abort info: [ 9042.745455] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 9042.745457] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 9042.745459] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 9042.745462] user pgtable: 4k pages, 48-bit VAs, pgdp=00003000894ca000 [ 9042.745464] [0000000000000000] pgd=08003000894cb403, p4d=08003000894cb403, pud=0800300085320403, pmd=0000000000000000 [ 9042.830042] Internal error: Oops: 0000000096000006 [#1] SMP [ 9042.838310] Modules linked in: cramfs camellia_generic serpent_generic blowfish_generic blowfish_common cast5_generic cast_common des_generic libdes rmd160 tcp_bic unix_diag ansi_cprng tcp_dctcp ppp_synctty ip_set_hash_ip n_hdlc cmac pps_ldisc n_gsm nfnetlink_log slcan tcp_diag nfnetlink_cthelper atm nfsd auth_rpcgss nfs_acl twofish_generic twofish_common ccm md4 ppp_async msdos nfs lockd grace fscache crc32_generic netfs smc_diag tcp_westwood smc nfnetlink_osf vfio_iommu_type1 vfio vhost_vsock iommufd squashfs ib_core gfs2 snd_timer snd soundcore uhid nfnetlink_cttimeout pppoe ip_vs cuse can_bcm loop can_raw can vsock_loopback inet_diag vmw_vsock_virtio_transport_common vhost_net vhost ieee802154_socket vsock cfg80211 uinput ieee802154 vhost_iotlb pptp crypto_user l2tp_ppp pppox sctp ppp_generic slhc af_key ip6_vti ip_vti ipip sit geneve macvtap tap ipvlan macvlan hsr xfrm_interface xfrm6_tunnel tunnel4 wireguard libchacha20poly1305 chacha_neon poly1305_neon libcurve25519_generic libchacha nlmon team vcan can_dev tun [ 9042.838608] xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype nft_compat nf_tables overlay nfnetlink_queue authenc echainiv cls_matchall esp6 l2tp_ip6 l2tp_eth l2tp_ip l2tp_netlink l2tp_core br_netfilter sch_etf sch_fq dccp_ipv6 dccp_ipv4 dccp sch_ingress act_mirred cls_basic veth bonding tls esp4_offload esp4 psample macsec vxlan ip6_udp_tunnel udp_tunnel vrf 8021q garp mrp ip6_gre ip6_tunnel tunnel6 ip_gre ip_tunnel gre cls_u32 sch_htb dummy binfmt_misc bridge stp llc rfkill ip_set libcrc32c sunrpc vfat fat ipmi_si ipmi_devintf phytium_dc_drm ses enclosure ipmi_msghandler drm_display_helper scsi_transport_sas cec drm_kms_helper cppc_cpufreq sg drm fuse nfnetlink ext4 mbcache jbd2 sd_mod t10_pi crc64_rocksoft_generic crc64_rocksoft crc64 crct10dif_ce ghash_ce sm4_ce_gcm sm4_ce_ccm sm4_ce sm4_ce_cipher sm4 sm3_ce sha3_ce sha512_ce ahci sha512_arm64 sha2_ce libahci sha256_arm64 ice sha1_ce igb sbsa_gwdt libata megaraid_sas i2c_algo_bit i2c_core [ 9042.958095] dm_mirror dm_region_hash dm_log dm_multipath dm_mod aes_neon_bs aes_neon_blk aes_ce_blk aes_ce_cipher [last unloaded: nf_tables] [ 9043.094331] CPU: 39 PID: 127275 Comm: syz-executor.3 Kdump: loaded Not tainted 6.6.0-0001.rc3.ctl4.aarch64 #1 [ 9043.108430] Hardware name: vclusters VSFT5000 B/VSFT5000 B, BIOS KL4.2A.RC.D.170.240314.D.DX 03/14/2024 18:01:48 [ 9043.122832] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 9043.132983] pc : drm_gem_object_free+0xc/0x40 [drm] [ 9043.140480] lr : phytium_gem_create_object+0x2ac/0x338 [phytium_dc_drm] [ 9043.150238] sp : ffff80009cd83bd0 [ 9043.155639] x29: ffff80009cd83bd0 x28: 00000000000000b2 x27: ffff80009cd83ce8 [ 9043.166023] x26: 0000000000000020 x25: 0000000000000020 x24: ffff80007b4b2d78 [ 9043.176292] x23: ffff00ff8de5b000 x22: 0000000003de4000 x21: 0000000000000000 [ 9043.186548] x20: ffff00ff8df94c80 x19: fffffffffffffff4 x18: ffffffffffffffff [ 9043.196768] x17: 6f74206c69616620 x16: 2a524f5252452a20 x15: 5d5d6d72645f6364 [ 9043.207193] x14: 5f6d756974796870 x13: 205d353732373231 x12: 545b5d3837303330 [ 9043.217647] x11: 00000000ffff7fff x10: ffff80008223b900 x9 : ffff80007b5cdcb4 [ 9043.228070] x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 00000000002bffa8 [ 9043.238522] x5 : ffff80008345bd08 x4 : 0000000000000000 x3 : 0000000000000000 [ 9043.248718] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff200014f5b800 [ 9043.258874] Call trace: [ 9043.263132] drm_gem_object_free+0xc/0x40 [drm] [ 9043.270239] phytium_gem_dumb_create+0x60/0x160 [phytium_dc_drm] [ 9043.279194] drm_mode_create_dumb_ioctl+0x98/0xc0 [drm] [ 9043.287188] drm_ioctl_kernel+0xdc/0x188 [drm] [ 9043.294188] drm_ioctl+0x274/0x540 [drm] [ 9043.300456] __arm64_sys_ioctl+0xb4/0x100 [ 9043.306777] invoke_syscall+0x50/0x128 [ 9043.312774] el0_svc_common.constprop.0+0xc8/0xf0 [ 9043.319953] do_el0_svc+0x24/0x38 [ 9043.325324] el0_svc+0x44/0x1b8 [ 9043.330517] el0t_64_sync_handler+0x100/0x130 [ 9043.337369] el0t_64_sync+0x188/0x190 [ 9043.343315] Code: ffff00ff aa1e03e9 952fe875 f940a001 (f9400021) [ 9043.352351] SMP: stopping secondary CPUs [ 9043.412513] Starting crashdump kernel... [ 9044.001381] Bye! ``` Disassembler drm_gem_object_free: ``` 0xffff80007b437398 <drm_gem_object_free>: mov x9, x30 0xffff80007b43739c <drm_gem_object_free+4>: bl 0xffff800080031570 <ftrace_caller> 0xffff80007b4373a0 <drm_gem_object_free+8>: ldr x1, [x0, #320] 0xffff80007b4373a4 <drm_gem_object_free+12>: ldr x1, [x1] 0xffff80007b4373a8 <drm_gem_object_free+16>: cbz x1, 0xffff80007b4373c8 <drm_gem_object_free+48> 0xffff80007b4373ac <drm_gem_object_free+20>: paciasp 0xffff80007b4373b0 <drm_gem_object_free+24>: stp x29, x30, [sp, #-16]! 0xffff80007b4373b4 <drm_gem_object_free+28>: mov x29, sp 0xffff80007b4373b8 <drm_gem_object_free+32>: blr x1 0xffff80007b4373bc <drm_gem_object_free+36>: ldp x29, x30, [sp], #16 0xffff80007b4373c0 <drm_gem_object_free+40>: autiasp 0xffff80007b4373c4 <drm_gem_object_free+44>: ret 0xffff80007b4373c8 <drm_gem_object_free+48>: brk #0x800 0xffff80007b4373cc <drm_gem_object_free+52>: ret 0xffff80007b4373d0 <drm_gem_object_free+56>: .inst 0x865baea8 ; undefined 0xffff80007b4373d4 <drm_gem_object_free+60>: .inst 0xffff00ff ; undefined ``` ldr x1, [x1] <-- trapping instruction Signed-off-by: Li Chen <chenl311(a)chinatelecom.cn> Reviewed-by: Bin Lai <laib2(a)chinatelecom.cn> Reviewed-by: Shuo Li <lishuo(a)phytium.com.cn> --- drivers/gpu/drm/phytium/phytium_gem.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/phytium/phytium_gem.c b/drivers/gpu/drm/phytium/phytium_gem.c index 2cbbcd9fbd112..95b6b0360c065 100644 --- a/drivers/gpu/drm/phytium/phytium_gem.c +++ b/drivers/gpu/drm/phytium/phytium_gem.c @@ -432,6 +432,8 @@ struct phytium_gem_object *phytium_gem_create_object(struct drm_device *dev, uns goto failed_object_init; } + phytium_gem_obj->base.funcs = &phytium_drm_gem_object_funcs; + if (priv->support_memory_type & (MEMORY_TYPE_VRAM_WC | MEMORY_TYPE_VRAM_DEVICE)) { ret = phytium_memory_pool_alloc(priv, &phytium_gem_obj->vaddr, &phytium_gem_obj->phys_addr, size); @@ -475,8 +477,6 @@ struct phytium_gem_object *phytium_gem_create_object(struct drm_device *dev, uns goto failed_dma_alloc; } - phytium_gem_obj->base.funcs = &phytium_drm_gem_object_funcs; - phytium_gem_obj->size = size; list_add_tail(&phytium_gem_obj->list, &priv->gem_list_head); DRM_DEBUG_KMS("phytium_gem_obj iova:0x%pa size:0x%lx\n", -- 2.49.0

1 0

[PATCH OLK-6.6] drm/amd/display: Fix && vs || typos
by Xinyu Zheng 11 Jul '25

11 Jul '25

From: Dan Carpenter <dan.carpenter(a)linaro.org> mainline inclusion from mainline-v6.8-rc5 commit 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMKW Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- These ANDs should be ORs or it will lead to a NULL dereference. Fixes: 45716b01839a ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'") Fixes: 2de9bab01e39 ("drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'") Reviewed-by: Anthony Koo <anthony.koo(a)amd.com> Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c [lc: adjust context] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c index 840dfd237247..990374857d9a 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c @@ -211,7 +211,7 @@ void dcn21_set_pipe(struct pipe_ctx *pipe_ctx) struct dmcu *dmcu = pipe_ctx->stream->ctx->dc->res_pool->dmcu; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return; otg_inst = tg->inst; @@ -245,7 +245,7 @@ bool dcn21_set_backlight_level(struct pipe_ctx *pipe_ctx, struct panel_cntl *panel_cntl = pipe_ctx->stream->link->panel_cntl; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return false; otg_inst = tg->inst; -- 2.34.1

2 1

[PATCH OLK-6.6] tty: serial: uartlite: register uart driver in init
by Yi Yang 11 Jul '25

11 Jul '25

From: Jakub Lewalski <jakub.lewalski(a)nokia.com> stable inclusion from stable-v6.6.96 commit 8e958d10dd0ce5ae674cce460db5c9ca3f25243b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/ICL7YU CVE: CVE-2025-38262 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 6bd697b5fc39fd24e2aa418c7b7d14469f550a93 ] When two instances of uart devices are probing, a concurrency race can occur. If one thread calls uart_register_driver function, which first allocates and assigns memory to 'uart_state' member of uart_driver structure, the other instance can bypass uart driver registration and call ulite_assign. This calls uart_add_one_port, which expects the uart driver to be fully initialized. This leads to a kernel panic due to a null pointer dereference: [ 8.143581] BUG: kernel NULL pointer dereference, address: 00000000000002b8 [ 8.156982] #PF: supervisor write access in kernel mode [ 8.156984] #PF: error_code(0x0002) - not-present page [ 8.156986] PGD 0 P4D 0 ... [ 8.180668] RIP: 0010:mutex_lock+0x19/0x30 [ 8.188624] Call Trace: [ 8.188629] ? __die_body.cold+0x1a/0x1f [ 8.195260] ? page_fault_oops+0x15c/0x290 [ 8.209183] ? __irq_resolve_mapping+0x47/0x80 [ 8.209187] ? exc_page_fault+0x64/0x140 [ 8.209190] ? asm_exc_page_fault+0x22/0x30 [ 8.209196] ? mutex_lock+0x19/0x30 [ 8.223116] uart_add_one_port+0x60/0x440 [ 8.223122] ? proc_tty_register_driver+0x43/0x50 [ 8.223126] ? tty_register_driver+0x1ca/0x1e0 [ 8.246250] ulite_probe+0x357/0x4b0 [uartlite] To prevent it, move uart driver registration in to init function. This will ensure that uart_driver is always registered when probe function is called. Signed-off-by: Jakub Lewalski <jakub.lewalski(a)nokia.com> Signed-off-by: Elodie Decerle <elodie.decerle(a)nokia.com> Link: https://lore.kernel.org/r/20250331160732.2042-1-elodie.decerle@nokia.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yi Yang <yiyang13(a)huawei.com> --- drivers/tty/serial/uartlite.c | 25 ++++++++++++------------- 1 file changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c index b225a78f6175..9f39bafa7fa9 100644 --- a/drivers/tty/serial/uartlite.c +++ b/drivers/tty/serial/uartlite.c @@ -872,16 +872,6 @@ static int ulite_probe(struct platform_device *pdev) pm_runtime_set_active(&pdev->dev); pm_runtime_enable(&pdev->dev); - if (!ulite_uart_driver.state) { - dev_dbg(&pdev->dev, "uartlite: calling uart_register_driver()\n"); - ret = uart_register_driver(&ulite_uart_driver); - if (ret < 0) { - dev_err(&pdev->dev, "Failed to register driver\n"); - clk_disable_unprepare(pdata->clk); - return ret; - } - } - ret = ulite_assign(&pdev->dev, id, res->start, irq, pdata); pm_runtime_mark_last_busy(&pdev->dev); @@ -922,16 +912,25 @@ static struct platform_driver ulite_platform_driver = { static int __init ulite_init(void) { + int ret; + + pr_debug("uartlite: calling uart_register_driver()\n"); + ret = uart_register_driver(&ulite_uart_driver); + if (ret) + return ret; pr_debug("uartlite: calling platform_driver_register()\n"); - return platform_driver_register(&ulite_platform_driver); + ret = platform_driver_register(&ulite_platform_driver); + if (ret) + uart_unregister_driver(&ulite_uart_driver); + + return ret; } static void __exit ulite_exit(void) { platform_driver_unregister(&ulite_platform_driver); - if (ulite_uart_driver.state) - uart_unregister_driver(&ulite_uart_driver); + uart_unregister_driver(&ulite_uart_driver); } module_init(ulite_init); -- 2.25.1

2 1

[PATCH OLK-5.10 v2] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 1ff7bddaac37 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 0831821d04c4..2222e1d2c648 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2213,8 +2213,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-6.6 v2] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 3c02fff414d4 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 6d9da768604d..9200e13cf97e 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2315,8 +2315,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-6.6] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 3c02fff414d4 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 6d9da768604d..9200e13cf97e 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2315,8 +2315,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-5.10] hrtimers: Update new CPU's next event in hrtimers_cpu_dying()
by Yipeng Zou 11 Jul '25

11 Jul '25

From: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMXT -------------------------------- When testing softirq based hrtimers on an ARM32 board, with high resolution mode and nohz are both inactive, softirq based hrtimers failed to trigger when moved away from an offline CPU. The flowpath is as follows. CPU0 CPU1 softirq based hrtimers are queued offline CPU1 move hrtimers to CPU0 in hrtimers_cpu_dying() send IPI to CPU0 to retrigger next event 'softirq_expires_next' is KTIME_MAX call retrigger_next_event() highres and nohz is inactive,just return 'softirq_expires_next' is not updated hrtimer softirq is never triggered Some softirq based hrtimers are queued on CPU1. Then we offline CPU1. hrtimers_cpu_dying() moves hrtimers from CPU1 to CPU0, and then it send a IPI to CPU0 to let CPU0 call retrigger_next_event(). But high resolution mode and nohz are both inactive. So retrigger_next_event() just returned. 'softirq_expires_next' is never updated and remains KTIME_MAX. So hrtimer softirq is never raised. To fix this issue, we call hrtimer_update_next_event() in hrtimers_cpu_dying() to update 'softirq_expires_next' for the new CPU. It also update hardirq hrtimer's next event, but it should have no bad effect. Fixes: 1ff7bddaac37 ("hrtimers: Push pending hrtimers away from outgoing CPU earlier") Signed-off-by: Xiongfeng Wang <wangxiongfeng2(a)huawei.com> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- kernel/time/hrtimer.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c index 0831821d04c4..2222e1d2c648 100644 --- a/kernel/time/hrtimer.c +++ b/kernel/time/hrtimer.c @@ -2213,8 +2213,11 @@ int hrtimers_cpu_dying(unsigned int dying_cpu) /* * The migration might have changed the first expiring softirq * timer on this CPU. Update it. + * We also need to update 'softirq_expires_next' here, because it will + * not be updated in retrigger_next_event() if high resolution mode + * and nohz are both inactive. */ - __hrtimer_get_next_event(new_base, HRTIMER_ACTIVE_SOFT); + hrtimer_update_next_event(new_base); /* Tell the other CPU to retrigger the next event */ smp_call_function_single(ncpu, retrigger_next_event, NULL, 0); -- 2.34.1

2 1

[PATCH OLK-6.6] drm/amd/display: Fix && vs || typos
by Xinyu Zheng 11 Jul '25

11 Jul '25

From: Dan Carpenter <dan.carpenter(a)linaro.org> mainline inclusion from mainline-v6.8-rc5 commit 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/ICLMKW Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- These ANDs should be ORs or it will lead to a NULL dereference. Fixes: 45716b01839a ("drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'") Fixes: 2de9bab01e39 ("drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'") Reviewed-by: Anthony Koo <anthony.koo(a)amd.com> Signed-off-by: Dan Carpenter <dan.carpenter(a)linaro.org> Signed-off-by: Hamza Mahfooz <hamza.mahfooz(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Conflicts: drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c drivers/gpu/drm/amd/display/dc/hwss/dcn21/dcn21_hwseq.c [lc: adjust context] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c index 840dfd237247..990374857d9a 100644 --- a/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/dcn21/dcn21_hwseq.c @@ -211,7 +211,7 @@ void dcn21_set_pipe(struct pipe_ctx *pipe_ctx) struct dmcu *dmcu = pipe_ctx->stream->ctx->dc->res_pool->dmcu; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return; otg_inst = tg->inst; @@ -245,7 +245,7 @@ bool dcn21_set_backlight_level(struct pipe_ctx *pipe_ctx, struct panel_cntl *panel_cntl = pipe_ctx->stream->link->panel_cntl; uint32_t otg_inst; - if (!abm && !tg && !panel_cntl) + if (!abm || !tg || !panel_cntl) return false; otg_inst = tg->inst; -- 2.34.1

2 1