From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.7]) (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 5214D1A6835 for ; Tue, 23 Jun 2026 03:03:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782183787; cv=none; b=sPTg3FjA1EBKYuXgkS2XTkIZYdLPhZjDEXFFFS2PC9N+6gNrMejgaby9feX3JgUZ5AOAJb3YTZ/fxUS90ve7VqmKYQlT/SVG9X++2j0KBR6eoZjW+99pnP3chgdIdf8pv3KWo41q+U7sFeYmfliHiuuMOBmvSekyGPatq5xtXIE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782183787; c=relaxed/simple; bh=hNUl8ebqbiuNExGHxkW3pCIeCMstpa/g8g0XqF0Wj1w=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=bULL1F5nVR3P2ZFUc4xYuOMjBWNXuAIwuIqWTbiqxuG9ZCRrcbxr1aHLPaasSlCoCb6JGCc+yFWYk5xR8hZndOVk4DY2mCRMpImSW9if3/tEwNuj7YYhyrNFNRYt7CSpWuQayXr4n5M9gmS4jd1CS8upcUdGAw8C4jSklyP6onI= 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=B3uM5zle; arc=none smtp.client-ip=192.198.163.7 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="B3uM5zle" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1782183785; x=1813719785; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=hNUl8ebqbiuNExGHxkW3pCIeCMstpa/g8g0XqF0Wj1w=; b=B3uM5zleA0RL680B1bvA1/rYXt0KMU3nws6O44zsVvfbfswzWXi9J0SA n6HYBx+fYz/IQguxf1dagMgMECTCB8VFrHaz0kpu8I65rIT75oYkePWS0 pOXoVWlFjxhjvlJpV0vaPRyQeuvJ4KdTGOzDyNlFpntmpUD8MhmI3makm 8SrN7Feg9AXytx/uFa7V2U02mrNzb6LoDWONURmBvm4KZx4PWgoNTjBOZ 1J8pqcdhm0Nx3OQ8Ibv8KCrNbS5GQ+o50D4Y17Lw7YHh8DFOsIh4k9sWY PrAcxNtUhcE+pGmqdfUMRBkv98u8HhF1N0B1VXdfn5UTI2LywB6s2qJqP Q==; X-CSE-ConnectionGUID: WEztHJ0wRBa7hjR9qxbUvA== X-CSE-MsgGUID: soLrRug8RSq02dzH7Z0dxQ== X-IronPort-AV: E=McAfee;i="6800,10657,11825"; a="108463606" X-IronPort-AV: E=Sophos;i="6.24,219,1774335600"; d="scan'208";a="108463606" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by fmvoesa101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Jun 2026 20:03:05 -0700 X-CSE-ConnectionGUID: 4BxaVh9jTEymSyap0UBwAw== X-CSE-MsgGUID: aethsatbTG25NJ5zf4tORg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.24,219,1774335600"; d="scan'208";a="249524314" Received: from ubuntu.bj.intel.com ([10.238.152.72]) by orviesa009.jf.intel.com with ESMTP; 22 Jun 2026 20:03:02 -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 v2] x86/sgx: Fix RCU Tasks stalls in EPC sanitization loop Date: Tue, 23 Jun 2026 11:03:29 +0800 Message-Id: <20260623030329.2786571-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"). 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. - Change the subject of this patch to fitness function. --- 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_rcu_qs(); } list_splice(&dirty, dirty_page_list); -- 2.32.0