From: Tengda Wu <wutengda@huaweicloud.com> maillist inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8522 Reference: https://lore.kernel.org/all/20260209093101.1623454-1-wutengda@huaweicloud.co... -------------------------------- A soft lockup may occur when accessing trace file via lseek while tracing is active and a large offset is provided. The call trace is shown below: watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [poc:141] CPU: 3 UID: 0 PID: 141 Comm: poc Not tainted 6.19.0 #1 PREEMPT(none) Call Trace: ring_buffer_iter_peek peek_next_entry __find_next_entry trace_find_next_entry_inc s_next traverse.part.0 seq_lseek tracing_lseek __x64_sys_lseek do_syscall_64 entry_SYSCALL_64_after_hwframe The root cause is that the lseek implementation for trace files is based on seq_lseek, which contains a loop that repeatedly calls show() and next() functions until the position reaches the target offset. Since no scheduling point is set within this loop, a large offset can cause the CPU to be stuck in the loop for an extended period, triggering the soft lockup detector. Fixed by adding cond_resched() in s_next(). Fixes: bc0c38d139ec ("ftrace: latency tracer infrastructure") Signed-off-by: Tengda Wu <wutengda2@huawei.com> --- kernel/trace/trace.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 6c5a503987e7..631a9d263e57 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -3678,6 +3678,8 @@ static void *s_next(struct seq_file *m, void *v, loff_t *pos) iter->pos = *pos; + cond_resched(); + return ent; } -- 2.34.1