All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Miao <jun.miao@intel.com>
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	[thread overview]
Message-ID: <20260623030329.2786571-1-jun.miao@intel.com> (raw)

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 <i2bp1g0g0m0i8406er0g1zX2>.
[    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] <TASK>
[  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] </TASK>

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 <challvy.tee@gmail.com>
Link: https://github.com/systemd/systemd/issues/40423
Fixes: e7e0545299d8 ("x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections")
Tested-by: Challvy Tee <challvy.tee@gmail.com>
Suggested-by: Kai Huang <kai.huang@intel.com>
Co-developed-by: Fan Du <fan.du@intel.com>
Signed-off-by: Fan Du <fan.du@intel.com>
Signed-off-by: Jun Miao <jun.miao@intel.com>

---
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


             reply	other threads:[~2026-06-23  3:03 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-23  3:03 Jun Miao [this message]
2026-08-18  6:06 ` [PATCH v2] x86/sgx: Fix RCU Tasks stalls in EPC sanitization loop kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260623030329.2786571-1-jun.miao@intel.com \
    --to=jun.miao@intel.com \
    --cc=challvy.tee@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=fan.du@intel.com \
    --cc=jarkko@kernel.org \
    --cc=kai.huang@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=qiang.zhang@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.