lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <tencent_54D61D94E2D80E1FEED30E4CA24E2807D607@qq.com>
Date: Mon,  6 Jan 2025 16:34:40 +0800
From: wujing <realwujing@...com>
To: realwujing@...com,
	mingo@...hat.com,
	peterz@...radead.org
Cc: linux-kernel@...r.kernel.org,
	QiLiang Yuan <yuanql9@...natelecom.cn>
Subject: [PATCH] sched/fair: Fix ksmd and kthreadd running on isolated CPU0 on arm64 systems

This bug can be reproduced on Kunpeng arm64 and Phytium arm physical machines,
as well as in virtual machine environments:

1. Check the number of CPUs on the system:
   nproc --all
   96

2. Add the parameter isolcpus=0-85 to the grub configuration,
update grub, and reboot.

3. Check the ksmd process:

   ps aux | grep -i ksmd
   root      502  0.0  0.0      0     0 ?        S    10:00   0:00 [ksmd]

   ps -o pid,psr,comm -p 502
   PID PSR COMMAND
   502   0 ksmd

4. Check the kthreadd process:

   ps aux | grep -i kthreadd
   root        2  0.0  0.0      0     0 ?        S    10:00   0:00 [kthreadd]

   ps -o pid,psr,comm -p 2
   PID PSR COMMAND
     2   0 kthreadd

>From the output above, it can be seen that both ksmd and kthreadd are still
running on CPU0, which is unreasonable since CPU0 has been isolated.

Signed-off-by: wujing <realwujing@...com>
Signed-off-by: QiLiang Yuan <yuanql9@...natelecom.cn>
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 0950cabfc1d0..454021ff70a1 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6211,7 +6211,7 @@ static int select_idle_cpu(struct task_struct *p, struct sched_domain *sd, int t
 
 	this_sd = rcu_dereference(*this_cpu_ptr(&sd_llc));
 	if (!this_sd)
-		return -1;
+		return housekeeping_any_cpu(HK_FLAG_DOMAIN);
 
 	/*
 	 * Due to large variance we need a large fuzz factor; hackbench in
-- 
2.39.5


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ