- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] net: yt6801: add link info for yt6801
by Frank_Sae 09 Mar '26

09 Mar '26

yt6801 inclusion category: bugfix bugzilla: https://https://atomgit.com/openeuler/kernel/issues/7229 -------------------------------------------------------------------- add link info for yt6801 to fix that the link info is not update on os installation. Signed-off-by: Frank_Sae <Frank.Sae(a)motor-comm.com> --- .../ethernet/motorcomm/yt6801/yt6801_main.c | 90 +++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c index 01eed3ace..cb54329ef 100644 --- a/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c +++ b/drivers/net/ethernet/motorcomm/yt6801/yt6801_main.c @@ -27,6 +27,95 @@ const struct net_device_ops *fxgmac_get_netdev_ops(void); static void fxgmac_napi_enable(struct fxgmac_pdata *priv); +const struct ethtool_ops *fxgmac_get_ethtool_ops(void); + +#define MII_SPEC_STATUS 0x11 /* PHY specific status */ +#define FXGMAC_EPHY_LINK_STATUS BIT(10) +#define PHY_MII_SPEC_DUPLEX BIT(13) + +static int fxgmac_get_link_ksettings(struct net_device *netdev, + struct ethtool_link_ksettings *cmd) +{ + struct fxgmac_pdata *pdata = netdev_priv(netdev); + struct phy_device *phydev = netdev->phydev; + u32 duplex, regval, link_status; + u32 adv = 0xFFFFFFFF; + + ethtool_link_ksettings_zero_link_mode(cmd, supported); + ethtool_link_ksettings_zero_link_mode(cmd, advertising); + + /* set the supported link speeds */ + ethtool_link_ksettings_add_link_mode(cmd, supported, 1000baseT_Full); + ethtool_link_ksettings_add_link_mode(cmd, supported, 100baseT_Full); + ethtool_link_ksettings_add_link_mode(cmd, supported, 100baseT_Half); + ethtool_link_ksettings_add_link_mode(cmd, supported, 10baseT_Full); + ethtool_link_ksettings_add_link_mode(cmd, supported, 10baseT_Half); + + /* Indicate pause support */ + ethtool_link_ksettings_add_link_mode(cmd, supported, Pause); + ethtool_link_ksettings_add_link_mode(cmd, supported, Asym_Pause); + + regval = phy_read(phydev, MII_ADVERTISE); + + if (field_get(ADVERTISE_PAUSE_CAP, regval)) + ethtool_link_ksettings_add_link_mode(cmd, advertising, Pause); + + if (field_get(ADVERTISE_PAUSE_ASYM, regval)) + ethtool_link_ksettings_add_link_mode(cmd, advertising, Asym_Pause); + + ethtool_link_ksettings_add_link_mode(cmd, supported, MII); + cmd->base.port = PORT_MII; + + ethtool_link_ksettings_add_link_mode(cmd, supported, Autoneg); + regval = phy_read(phydev, MII_BMCR); + + regval = field_get(BMCR_ANENABLE, regval); + if (regval) { + ethtool_link_ksettings_add_link_mode(cmd, advertising, Autoneg); + + regval = phy_read(phydev, MII_ADVERTISE); + + if (adv & ADVERTISE_10HALF) + ethtool_link_ksettings_add_link_mode(cmd, advertising, 10baseT_Half); + if (adv & ADVERTISE_10FULL) + ethtool_link_ksettings_add_link_mode(cmd, advertising, 10baseT_Full); + if (adv & ADVERTISE_100HALF) + ethtool_link_ksettings_add_link_mode(cmd, advertising, 100baseT_Half); + if (adv & ADVERTISE_100FULL) + ethtool_link_ksettings_add_link_mode(cmd, advertising, 100baseT_Full); + + adv = phy_read(phydev, MII_CTRL1000); + + if (adv & ADVERTISE_1000FULL) + ethtool_link_ksettings_add_link_mode(cmd, advertising, 1000baseT_Full); + } + + cmd->base.autoneg = 1; + + regval = phy_read(phydev, MII_SPEC_STATUS); + + link_status = field_get(FXGMAC_EPHY_LINK_STATUS, regval); + if (link_status) { + duplex = field_get(PHY_MII_SPEC_DUPLEX, regval); + cmd->base.duplex = duplex; + cmd->base.speed = pdata->mac_speed; + } else { + cmd->base.duplex = DUPLEX_UNKNOWN; + cmd->base.speed = SPEED_UNKNOWN; + } + + return 0; +} + +static const struct ethtool_ops fxgmac_ethtool_ops = { + .get_link = ethtool_op_get_link, + .get_link_ksettings = fxgmac_get_link_ksettings, +}; + +const struct ethtool_ops *fxgmac_get_ethtool_ops(void) +{ + return &fxgmac_ethtool_ops; +} #define PHY_WR_CONFIG(reg_offset) (0x8000205 + ((reg_offset) * 0x10000)) static int fxgmac_phy_write_reg(struct fxgmac_pdata *priv, u32 reg_id, u32 data) @@ -1899,6 +1988,7 @@ static int fxgmac_init(struct fxgmac_pdata *priv, bool save_private_reg) FXGMAC_JUMBO_PACKET_MTU + (ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN); ndev->netdev_ops = fxgmac_get_netdev_ops();/* Set device operations */ + ndev->ethtool_ops = fxgmac_get_ethtool_ops();/* Set device operations */ /* Set device features */ if (priv->hw_feat.tso) { -- 2.34.1

2 1

[PATCH OLK-5.10] ksmbd: fix use-after-free in kerberos authentication
by Yongjian Sun 09 Mar '26

09 Mar '26

From: Sean Heelan <seanheelan(a)gmail.com> mainline inclusion from mainline-v6.15-rc5 commit e86e9134e1d1c90a960dd57f59ce574d27b9a124 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/10609 CVE: CVE-2025-37778 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbd_free_user. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbd_free_user but before sess->user is set to NULL. Cc: stable(a)vger.kernel.org Signed-off-by: Sean Heelan <seanheelan(a)gmail.com> Acked-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Conflicts: fs/smb/server/smb2pdu.c fs/ksmbd/smb2pdu.c fs/smb/server/auth.c fs/ksmbd/auth.c [mainline commit 38c8a9a52082 changed the file name] [mainline commit 1e440d5b25b7 still has issues] Signed-off-by: Yongjian Sun <sunyongjian1(a)huawei.com> --- fs/ksmbd/auth.c | 14 +++++++++++++- fs/ksmbd/smb2pdu.c | 3 --- 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/fs/ksmbd/auth.c b/fs/ksmbd/auth.c index d8dabd19823f..c5916064b85e 100644 --- a/fs/ksmbd/auth.c +++ b/fs/ksmbd/auth.c @@ -514,7 +514,19 @@ int ksmbd_krb5_authenticate(struct ksmbd_session *sess, char *in_blob, retval = -ENOMEM; goto out; } - sess->user = user; + + if (!sess->user) { + /* First successful authentication */ + sess->user = user; + } else { + if (!ksmbd_compare_user(sess->user, user)) { + ksmbd_debug(AUTH, "different user tried to reuse session\n"); + retval = -EPERM; + ksmbd_free_user(user); + goto out; + } + ksmbd_free_user(user); + } memcpy(sess->sess_key, resp->payload, resp->session_key_len); memcpy(out_blob, resp->payload + resp->session_key_len, diff --git a/fs/ksmbd/smb2pdu.c b/fs/ksmbd/smb2pdu.c index 13f2a81d3621..1588867b4e71 100644 --- a/fs/ksmbd/smb2pdu.c +++ b/fs/ksmbd/smb2pdu.c @@ -1612,9 +1612,6 @@ static int krb5_authenticate(struct ksmbd_work *work, if (prev_sess_id && prev_sess_id != sess->id) destroy_previous_session(conn, sess->user, prev_sess_id); - if (sess->state == SMB2_SESSION_VALID) - ksmbd_free_user(sess->user); - retval = ksmbd_krb5_authenticate(sess, in_blob, in_len, out_blob, &out_len); if (retval) { -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] PCI: Fix pci_slot_trylock() error handling
by Ziming Du 09 Mar '26

09 Mar '26

From: Jinhui Guo <guojinhui.liam(a)bytedance.com> mainline inclusion from mainline-v7.0-rc1 commit 9368d1ee62829b08aa31836b3ca003803caf0b72 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8599 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in pci_slot_trylock(), but it forgets to remove the corresponding pci_dev_unlock() when pci_bus_trylock() fails. Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } } After a4e772898f8b the bridge-device lock is no longer taken, but the pci_dev_unlock(dev) on the failure path was left in place, leading to the bug. This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread. Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure path. [Same patch later posted by Keith at https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] Fixes: a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()") Signed-off-by: Jinhui Guo <guojinhui.liam(a)bytedance.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Cc: stable(a)vger.kernel.org Link: https://patch.msgid.link/20251212145528.2555-1-guojinhui.liam@bytedance.com Signed-off-by: Ziming Du <duziming2(a)huawei.com> --- drivers/pci/pci.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index b93605616d4e4..fbef3c37f37fa 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -5144,10 +5144,8 @@ static int pci_slot_trylock(struct pci_slot *slot) if (!dev->slot || dev->slot != slot) continue; if (dev->subordinate) { - if (!pci_bus_trylock(dev->subordinate)) { - pci_dev_unlock(dev); + if (!pci_bus_trylock(dev->subordinate)) goto unlock; - } } else if (!pci_dev_trylock(dev)) goto unlock; } -- 2.43.0

2 1

[PATCH OLK-5.10] [Backport] sched/rt: Skip currently executing CPU in rto_next_cpu()
by Chen Jinghuang 09 Mar '26

09 Mar '26

mainline inclusion from mainline-v7.0-rc1 commit 94894c9c477e53bcea052e075c53f89df3d2a33e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Suggested-by: K Prateek Nayak <kprateek.nayak(a)amd.com> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Reviewed-by: Valentin Schneider <vschneid(a)redhat.com> Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- kernel/sched/rt.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index ddbc857a28b8..dbc3a40a68fa 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -2013,6 +2013,7 @@ static void push_rt_tasks(struct rq *rq) */ static int rto_next_cpu(struct root_domain *rd) { + int this_cpu = smp_processor_id(); int next; int cpu; @@ -2036,6 +2037,10 @@ static int rto_next_cpu(struct root_domain *rd) rd->rto_cpu = cpu; + /* Do not send IPI to self */ + if (cpu == this_cpu) + continue; + if (cpu < nr_cpu_ids) return cpu; -- 2.34.1

2 1

[PATCH OLK-6.6] arm64/mpam: Fix warning of schedule state in resctrl_arch_mon_ctx_alloc()
by Zeng Heng 09 Mar '26

09 Mar '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8686 ------------------ resctrl_arch_mon_ctx_alloc() triggers a scheduling state warning when calling kmalloc() while the task is in a non-running state: do not call blocking ops when !TASK_RUNNING; state=1 set at prepare_to_wait WARNING: CPU: 78 PID: 12592 at kernel/sched/core.c:10584 _might_sleep Call trace: _might_sleep+0x1cc/0xf8 _kmalloc_cache_alloc_node+0x3a0/0x4e0 kmalloc_trace+0x44/0x120 resctrl_arch_mon_ctx_alloc+0xf0/0x178 mon_event_read+0xa0/0x308 mkdir_mondata_subdir+0x24c/0x330 mkdir_mondata_all+0x17c/0x248 rdt_get_tree+0x2e8/0x680 vfs_get_tree+0x5c/0x190 do_new_mount+0x27c/0x408 path_mount+0x2ac/0x448 arm64_sys_mount+0x1d4/0x228 Refactor the call sequence in resctrl_arch_mon_ctx_alloc() and ensure the allocation is performed in TASK_RUNNING state to avoid schedule state corrupted. Fixes: 9119da143939 ("arm_mpam: resctrl: Allow resctrl to allocate monitors") Signed-off-by: Zeng Heng <zengheng4(a)huawei.com> --- drivers/platform/mpam/mpam_resctrl.c | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/platform/mpam/mpam_resctrl.c b/drivers/platform/mpam/mpam_resctrl.c index 9950cc4eebf4..a33957651732 100644 --- a/drivers/platform/mpam/mpam_resctrl.c +++ b/drivers/platform/mpam/mpam_resctrl.c @@ -388,32 +388,30 @@ struct rdt_resource *resctrl_arch_get_resource(enum resctrl_res_level l) return &mpam_resctrl_exports[l].resctrl_res; } -static void *resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, - int evtid) +static u32 resctrl_arch_mon_ctx_alloc_no_wait(struct rdt_resource *r, + int evtid) { - u32 *ret = kmalloc(sizeof(*ret), GFP_KERNEL); - - if (!ret) - return ERR_PTR(-ENOMEM); - - *ret = __mon_is_rmid_idx; - return ret; + return __mon_is_rmid_idx; } void *resctrl_arch_mon_ctx_alloc(struct rdt_resource *r, int evtid) { DEFINE_WAIT(wait); - void *ret; + u32 *ret; + + ret = kmalloc(sizeof(*ret), GFP_KERNEL); + if (!ret) + return ERR_PTR(-ENOMEM); might_sleep(); do { prepare_to_wait(&resctrl_mon_ctx_waiters, &wait, TASK_INTERRUPTIBLE); - ret = resctrl_arch_mon_ctx_alloc_no_wait(r, evtid); - if (PTR_ERR(ret) == -ENOSPC) + *ret = resctrl_arch_mon_ctx_alloc_no_wait(r, evtid); + if (*ret == -ENOSPC) schedule(); - } while (PTR_ERR(ret) == -ENOSPC && !signal_pending(current)); + } while (*ret == -ENOSPC && !signal_pending(current)); finish_wait(&resctrl_mon_ctx_waiters, &wait); return ret; -- 2.25.1

2 1

[PATCH OLK-6.6 0/2] Fix TLBI broadcast optimization loss and incorrect dvmbm handling
by Tian Zheng 09 Mar '26

09 Mar '26

Fix 1 In the TLBI broadcast-optimization feature, the SYS_LSUDVM_CTRL_EL2 register controls whether the feature is enabled. When LPI low-power mode is enabled, this register is cleared as the pCPU powers down into LPI mode, causing the TLBI broadcast optimization to stop working. The fix saves and restores this control register in the callbacks for entering and exiting LPI mode. Fix 2 The current TLBI broadcast-optimization logic only supports normal VMs. If the feature is enabled globally, VMs that are not yet adapted for it, such as CCA will use an incorrect TLBI broadcast bitmap, which can cause a panic in CCA VMs. The fix moves the actual enable/disable of the dvmbm functionality into the vcpu load and vcpu put functions. Tian Zheng (2): KVM: arm64: Fix TLBI optimization broken in LPI mode KVM: arm64: Fix CCA guest panic when dvmbm is enabled arch/arm64/kvm/arm.c | 6 ++++++ arch/arm64/kvm/hisilicon/hisi_virt.c | 8 +++----- arch/arm64/kvm/hisilicon/hisi_virt.h | 19 +++++++++++++++++++ 3 files changed, 28 insertions(+), 5 deletions(-) -- 2.33.0

1 2

[PATCH OLK-5.10] SUNRPC: Ensure the transport backchannel association
by Dong Chenchen 09 Mar '26

09 Mar '26

From: Benjamin Coddington <bcodding(a)redhat.com> mainline inclusion from mainline-v5.12-rc6 commit 98b5cee37389b899de044bc4aac56e6ff33dbd4d category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8655 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If the server sends CB_ calls on a connection that is not associated with the backchannel, refuse to process the call and shut down the connection. This avoids a NULL dereference crash in xprt_complete_bc_request(). There's not much more we can do in this situation unless we want to look into allowing all connections to be associated with the fore and back channel. Signed-off-by: Benjamin Coddington <bcodding(a)redhat.com> Signed-off-by: Trond Myklebust <trond.myklebust(a)hammerspace.com> Signed-off-by: Dong Chenchen <dongchenchen2(a)huawei.com> --- net/sunrpc/xprtsock.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c index 1ef469ddea89..a6580946ab69 100644 --- a/net/sunrpc/xprtsock.c +++ b/net/sunrpc/xprtsock.c @@ -558,6 +558,10 @@ xs_read_stream_call(struct sock_xprt *transport, struct msghdr *msg, int flags) struct rpc_rqst *req; ssize_t ret; + /* Is this transport associated with the backchannel? */ + if (!xprt->bc_serv) + return -ESHUTDOWN; + /* Look up and lock the request corresponding to the given XID */ req = xprt_lookup_bc_request(xprt, transport->recv.xid); if (!req) { -- 2.25.1

2 1

[PATCH OLK-5.10] [Backport] procfs: fix missing RCU protection when reading real_parent in do_task_stat()
by Chen Jinghuang 09 Mar '26

09 Mar '26

From: Jinliang Zheng <alexjlzheng(a)tencent.com> stable inclusion from stable-v5.10.252 commit fefa0fcd78be465b7ad4c497fa6ec90d64194c04 category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8688 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Cc: David Hildenbrand <david(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: ruippan <ruippan(a)tencent.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/proc/array.c [context conflict] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index d5fed9281863..6bb4c81ba66e 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -510,7 +510,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } sid = task_session_nr_ns(task, ns); - ppid = task_tgid_nr_ns(task->real_parent, ns); + ppid = task_ppid_nr_ns(task, ns); pgid = task_pgrp_nr_ns(task, ns); unlock_task_sighand(task, &flags); -- 2.34.1

2 1

[PATCH OLK-6.6] [Backport] procfs: fix missing RCU protection when reading real_parent in do_task_stat()
by Chen Jinghuang 09 Mar '26

09 Mar '26

From: Jinliang Zheng <alexjlzheng(a)tencent.com> stable inclusion from stable-v6.6.128 commit 0e64bd46a04a4fd61279aca9f53a664e9e5f7e7e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8688 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 76149d53502cf17ef3ae454ff384551236fba867 ] When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. Link: https://lkml.kernel.org/r/20260128083007.3173016-1-alexjlzheng@tencent.com Fixes: 06fffb1267c9 ("do_task_stat: don't take rcu_read_lock()") Signed-off-by: Jinliang Zheng <alexjlzheng(a)tencent.com> Acked-by: Oleg Nesterov <oleg(a)redhat.com> Cc: David Hildenbrand <david(a)kernel.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Mateusz Guzik <mjguzik(a)gmail.com> Cc: ruippan <ruippan(a)tencent.com> Cc: Usama Arif <usamaarif642(a)gmail.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: fs/proc/array.c [Context Conflicts] Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- fs/proc/array.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/proc/array.c b/fs/proc/array.c index 6a4b0a850dce..288f19956e04 100644 --- a/fs/proc/array.c +++ b/fs/proc/array.c @@ -544,7 +544,7 @@ static int do_task_stat(struct seq_file *m, struct pid_namespace *ns, } sid = task_session_nr_ns(task, ns); - ppid = task_tgid_nr_ns(task->real_parent, ns); + ppid = task_ppid_nr_ns(task, ns); pgid = task_pgrp_nr_ns(task, ns); unlock_task_sighand(task, &flags); -- 2.34.1

2 1

[PATCH OLK-6.6] [Backport] sched/rt: Skip currently executing CPU in rto_next_cpu()
by Chen Jinghuang 09 Mar '26

09 Mar '26

mainline inclusion from mainline-v7.0-rc1 commit 94894c9c477e53bcea052e075c53f89df3d2a33e category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8689 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- [ Upstream commit 94894c9c477e53bcea052e075c53f89df3d2a33e ] CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed). However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts. The trigging scenario is as follows: cpu0 cpu1 cpu2 pull_rt_task tell_cpu_to_push <------------irq_work_queue_on rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios. Fixes: 4bdced5c9a29 ("sched/rt: Simplify the IPI based RT balancing logic") Suggested-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Suggested-by: K Prateek Nayak <kprateek.nayak(a)amd.com> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Reviewed-by: Valentin Schneider <vschneid(a)redhat.com> Link: https://patch.msgid.link/20260122012533.673768-1-chenjinghuang2@huawei.com Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- kernel/sched/rt.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index 549b9ecfda7d..48d53bf0161b 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -2231,6 +2231,7 @@ static void push_rt_tasks(struct rq *rq) */ static int rto_next_cpu(struct root_domain *rd) { + int this_cpu = smp_processor_id(); int next; int cpu; @@ -2254,6 +2255,10 @@ static int rto_next_cpu(struct root_domain *rd) rd->rto_cpu = cpu; + /* Do not send IPI to self */ + if (cpu == this_cpu) + continue; + if (cpu < nr_cpu_ids) return cpu; -- 2.34.1

2 1