From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 1E89426056C for ; Tue, 23 Jun 2026 03:20:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782184811; cv=none; b=ObxdTT5innhh6eCVcGCsEoN3G1nyFrOTKIAnEHncaa3DtLzzAwOBJUy0M+KylgFsWHawQ+Y0M4nb22QLXIxLj3Do8OAnBkZdiohpD+a9s2wr+m2yKJ6yJxde5+QPLhmZDW0tyH3hQ+IFLMroZ5DpSEuPTzW69LpAlBOnjXCT9Y4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782184811; c=relaxed/simple; bh=1RvaVERXQ2y3X1vkivhOepw0YL4c7w4BYSBqeH4gJfo=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=FKo/lU9EjuUFyaUTJOHRiHgiu6z9bbR0l7lqhfjXojfRjc8dcQgSKyynb2fC4vynQVvwqIwrGeSlIdevLBmz4JmM1HESXovsUFvIvY+398j/hrlUMIRpQ9Hmx8BhdY5/uNoM+B9o3xfqYHqEpRyd4T0ycQWmKGmxtv26qKiM2AU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JDvcU24K; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JDvcU24K" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782184810; x=1813720810; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=1RvaVERXQ2y3X1vkivhOepw0YL4c7w4BYSBqeH4gJfo=; b=JDvcU24KYN7r/YbDuguDKjwhxn2ZwomPrJi+McfiCxw6tiRKdFPjSld+ 2i1rnQC+YyM5xIjacCAvh2Rm9NGvP3ceZQtVgL17GWsK44ghULPPSOL9K M+VPP3ITQGFUmyoCNLEWEIDy5L28y5xZIDwhmoFzYV+IqRTF/KJSJlne+ QtbTzf//0odtRZ3bmeu+6AzMVC9/OxhaMPyzgviAwprrqRWtmQKePH97L po28L3aCaoLDKktMWY0c4BV5n7mep/GufwsMq1uatc86X+Q2Ami1edQFR GpFwB/BgbhHuptD4qXNAlAUa0jAfFRXl/6DQRiofizndewkiP1+tZ0s1h w==; X-CSE-ConnectionGUID: QmssB4wzTvKO2DzgUVwvVA== X-CSE-MsgGUID: m58AatoqS56hyKL374oVQA== X-IronPort-AV: E=McAfee;i="6800,10657,11825"; a="82924778" X-IronPort-AV: E=Sophos;i="6.24,220,1774335600"; d="scan'208";a="82924778" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2026 20:20:09 -0700 X-CSE-ConnectionGUID: kwlT0p7BQN6eMSAuQT78WA== X-CSE-MsgGUID: 2aTovI6AQfmlFwLb7K8WPQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,220,1774335600"; d="scan'208";a="253286880" Received: from ubuntu.bj.intel.com ([10.238.152.72]) by orviesa003.jf.intel.com with ESMTP; 22 Jun 2026 20:20:07 -0700 From: Jun Miao To: jarkko@kernel.org, dave.hansen@linux.intel.com Cc: kai.huang@intel.com, challvy.tee@gmail.com, fan.du@intel.com, jun.miao@intel.com, linux-kernel@vger.kernel.org, qiang.zhang@linux.dev Subject: [PATCH v3] x86/sgx: Fix RCU Tasks stalls in EPC sanitization loop Date: Tue, 23 Jun 2026 11:20:34 +0800 Message-Id: <20260623032034.2819324-1-jun.miao@intel.com> X-Mailer: git-send-email 2.32.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Large EPC configurations can spend a significant amount of time sanitizing EPC pages during SGX initialization. The sanitization loop invokes cond_resched() while processing pages, but if the scheduler does not request rescheduling, the CPU may remain in the kernel for an extended period without reporting a quiescent state to RCU Tasks. cond_resched() only schedules when rescheduling is needed and does not guarantee a quiescent state for RCU Tasks. Replace it with cond_resched_rcu_qs(), which explicitly reports an RCU Tasks quiescent state even when no context switch occurs. Kai suggested that, this is a common problem at the scheduler and RCU layer, but not specific to SGX. More detail please see: bde6c3aa9930 ("rcu: Provide cond_resched_rcu_qs() to force quiescent states in long loops"). cee439398933 ("rcu: Rename cond_resched_rcu_qs() to cond_resched_tasks_rcu_qs()") Without this patch, instead, virtual machines (VMs) experience a long OS boot times: [ 4.110549] systemd[1]: Detected architecture x86-64. [ 4.115279] systemd[1]: Hostname set to . [ 4.115554] systemd[1]: Installed transient /etc/machine-id file. [ 14.262158] rcu_tasks_wait_gp: rcu_tasks grace period number 1 (since boot) is 10087 jiffies old. [ 14.374158] rcu_tasks_wait_gp: rcu_tasks grace period number 1 (since boot) is 40199 jiffies old. [ 134.806157] rcu_tasks_wait_gp: rcu_tasks grace period number 1 (since boot) is 130631 jiffies old. [ 248.086158] INFO: task systemd:1 blocked for more than 122 seconds. [ 248.086491] Not tainted 6.8.0-90-generic #91-Ubuntu [ 248.086739] 'echo 0 > /proc/sys/kernel/hung_task_timeout_secs' disables this message. [ 248.086993] task:systemd state:D stack:0 pid:1 tpid:1 ppid:0 flags:0x00000002 [ 248.087274] Call Trace: [ 248.087434] [ 248.087557] __schedule+0x27c/0x6b0 [ 248.087770] schedule+0x33/0x110 [ 248.087939] schedule_timeout+0x157/0x170 [ 248.088120] wait_for_completion+0x88/0x150 [ 248.088304] __wait_rcu_gp+0x17e/0x190 [ 248.088481] synchronize_rcu_tasks_generic+0x64/0x60 [ 248.088672] ? __pfx_call_rcu_tasks+0x10/0x10 [ 248.088858] ? __pfx_wakeme_after_rcu+0x10/0x10 [ 248.089047] synchronize_rcu_tasks+0x15/0x20 [ 248.089260] register_ftrace_direct+0x31f/0x350 [ 248.089445] ? __pfx_bpf_lsm_file_open+0x10/0x10 [ 248.089629] bpf_trampoline_update+0x469/0x650 [ 248.089814] ? 0xffffffffffffffff [ 248.089988] ? 0xffffffffffffffff [ 248.090153] __bpf_trampoline_link_prog+0x10d/0x330 [ 248.090339] bpf_trampoline_link_prog+0x33/0x60 [ 248.090518] bpf_tracing_prog_attach+0x3c5/0x5f0 [ 248.090699] link_create+0x1a5/0x280 [ 248.090886] ? security_bpf+0x3c/0x70 [ 248.091101] __sys_bpf+0x4ae/0x10 [ 248.091312] __x64_sys_bpf+0x1a/0x30 [ 248.091477] x64_sys_call+0x199/0x250 [ 248.091647] do_syscall_64+0x7f/0x180 [ 248.091818] ? arch_exit_to_user_mode_prepare.isa.0+0x1a/0x60 [ 248.092022] ? irqentry_exit_to_user_mode+0x38/0x1e0 [ 248.092246] ? irqentry_exit+0x43/0x50 [ 248.092401] entry_SYSCALL_64_after_hwframe+0x78/0x80 [ 248.092590] RIP: 0033:0x7b53e592728d [ 248.092756] RSP: 002b:00007ffdaa9d696 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ 248.092856] RAX: ffffffffffffffda RBX: 00007ffdaa9d696 RCX: 00007b53e592728d [ 248.092956] RDX: 0000000000000000 RSI: 00007ffdaa9d696 RDI: 0000000000000001 [ 248.093056] RBP: 00007ffdaa9d696 R08: 00007b53e5a03a8 R09: 00007ffdaa9d696 [ 248.093156] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 [ 248.093256] R13: 0000000000000000 R14: 00005d81ed2cfd0 R15: 00005d81ed2b7ec0 [ 248.093406] After this patch test Results: Before fixed: boot time ~50s (with rcu_tasks grace period stall) After fixed: boot time ~10.7s (systemd-analyze: 724ms kernel + 1.575s initrd + 8.481s userspace = 10.782s) Reported-by: Challvy Tee Link: https://github.com/systemd/systemd/issues/40423 Fixes: e7e0545299d8 ("x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections") Tested-by: Challvy Tee Suggested-by: Kai Huang Co-developed-by: Fan Du Signed-off-by: Fan Du Signed-off-by: Jun Miao --- v1 -> v2: - Clarify the RCU Tasks stall root cause. - Use cond_resched_rcu_qs() following the Kai`s suggestion. v2 -> v3: - cee439398933 ("rcu: Rename cond_resched_rcu_qs() to cond_resched_tasks_rcu_qs()") --- arch/x86/kernel/cpu/sgx/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c index 4505f808af5e..7ba3d0a5a05d 100644 --- a/arch/x86/kernel/cpu/sgx/main.c +++ b/arch/x86/kernel/cpu/sgx/main.c @@ -106,7 +106,7 @@ static unsigned long __sgx_sanitize_pages(struct list_head *dirty_page_list) left_dirty++; } - cond_resched(); + cond_resched_tasks_rcu_qs(); } list_splice(&dirty, dirty_page_list); -- 2.32.0