From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90DD02475D9 for ; Wed, 15 Jan 2025 12:32:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.190 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736944366; cv=none; b=shldMuhbEl0TVkzeiRiK6NwX5binLyAy3GJ5n76KTvJ4edzlUM4/uz2QQxtQ7IgvtzWjq3KmXrKTAeU6K5RBy9xrtSysL8JfgOjFG4BFdFmEYIqXjEGna2FjDK1Xx0L9bsphnzk58acxLkbYCGherwqAdco0sXNHDrHvoDu3gKc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736944366; c=relaxed/simple; bh=vNLpRLdL3FIYAy1+h/jdXVqLXIl8Rs5ufmMWW9rAyVI=; h=From:Subject:To:CC:Message-ID:Date:MIME-Version:Content-Type; b=ZmGSZTthImQG3VL19W1HeAsFs1w9kxjMFZRijRZKWExlhdybZDDClvSxWG+vt4nF3BWlt6Iv1rDkfzup5qBMiGoPEmGgr9BoQ8cLWS4BszaS5+SzuCVD74mwr9ExSqbVzGI2mMKkQcTyrktFgjQMFOOmcLoJI8KpfXSPFESbDC4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; arc=none smtp.client-ip=45.249.212.190 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Received: from mail.maildlp.com (unknown [172.19.88.163]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4YY51N2D3wz22lFl; Wed, 15 Jan 2025 20:30:16 +0800 (CST) Received: from kwepemh200008.china.huawei.com (unknown [7.202.181.115]) by mail.maildlp.com (Postfix) with ESMTPS id 03DA7180042; Wed, 15 Jan 2025 20:32:39 +0800 (CST) Received: from [10.174.176.125] (10.174.176.125) by kwepemh200008.china.huawei.com (7.202.181.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 15 Jan 2025 20:32:37 +0800 From: Kunkun Jiang Subject: [Question] Call trace occurs occasionally when a rollback is performed upon CPU online timeout To: Catalin Marinas , Will Deacon , Mark Rutland , Jonathan Cameron , Gavin Shan , James Morse , Jean-Philippe Brucker , Jinjie Ruan , Douglas Anderson , Puranjay Mohan , Luchunhua CC: "moderated list:ARM SMMU DRIVERS" , open list , "wanghaibin.wang@huawei.com" , Zenghui Yu , Message-ID: <8ec1a40a-61a6-d8f3-074d-6cc8697f261d@huawei.com> Date: Wed, 15 Jan 2025 20:32:37 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To kwepemh200008.china.huawei.com (7.202.181.115) Hi all, I have a question about CPU online/offline. In the following test scenario, various tasks(iperf,fio,sve,...) are executed in a VM with 6 vCPUs. At the same time, repeat online/offline operations on two of the vCPUs through /sys/devices/system/cpu/cpuX/online. After running for many hours,some calltrace will appear in the guest. The first, WARN_ON_ONCE(test_bit(KTHREAD_SHOULD_PARK, &kthread->flags)) is triggered. > Call trace: > kthread_park+0xd0/0xdc > takedown_cpu+0x4c/0x140 > cpuhp_invoke_callback+0x160/0x6e0 > _cpu_up+0x1a4/0x200 > cpu_up+0xbc/0x100 > cpu_device_up+0x20/0x30 > cpu_subsys_online+0x4c/0xb0 > device_online+0x7c/0xa0 > online_store+0xd0/0xe0 > dev_attr_store+0x20/0x34 > sysfs_kf_write+0x4c/0x5c > kernfs_fop_write_iter+0x130/0x1c0 > new_sync_write+0xec/0x18c > vfs_write+0x214/0x2ac > ksys_write+0x70/0xfc > __arm64_sys_write+0x24/0x30 > invoke_syscall+0x50/0x11c > el0_svc_common.constprop.0+0x68/0x164 > do_el0_svc+0x34/0xcc > el0_svc+0x20/0x30 > el0_sync_handler+0xb8/0xc0 > el0_sync+0x160/0x180 The second, BUG_ON(!irqs_disabled() && !IS_ENABLED(CONFIG_PREEMPT_RT)) is triggered. > Call trace: > irq_work_run_list+0x64/0x70 > smpcfd_dying_cpu+0x24/0x34 > cpuhp_invoke_callback+0x160/0x6e0 > _cpu_up+0x1a4/0x200 > cpu_up+0xbc/0x100 > cpu_device_up+0x20/0x30 > cpu_subsys_online+0x4c/0xb0 > device_online+0x7c/0xa0 > online_store+0xd0/0xe0 > dev_attr_store+0x20/0x34 > sysfs_kf_write+0x4c/0x5c > kernfs_fop_write_iter+0x130/0x1c0 > new_sync_write+0xec/0x18c > vfs_write+0x214/0x2ac > ksys_write+0x70/0xfc > __arm64_sys_write+0x24/0x30 > invoke_syscall+0x50/0x11c > el0_svc_common.constprop.0+0x68/0x164 > do_el0_svc+0x34/0xcc > el0_svc+0x20/0x30 > el0_sync_handler+0xb8/0xc0 > el0_sync+0x160/0x180 According to my analysis, the root cause of the question is because the vCPU online times out, but in fact the vCPU was successfully online. Rollback is performed due to timeout. During the rollback, the secondary_start_kernel is still executing, resulting in the above call trace. So is this a bug? If so, how should it be repaired? The reason for the timeout has not been found. It is suspected that it is caused by excessive task pressure. If you have other ideas, please point them out. Thanks, Kunkun Jiang