Peter,
When is PREEMPT_NONE going to be removed? If that's going into 7.0, I want to stop accepting these scattered cond_resched() additions. -- Steve On Mon, 9 Feb 2026 17:31:01 +0800 Tengda Wu <[email protected]> wrote: > 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 <[email protected]> > --- > kernel/trace/trace.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c > index 8bd4ec08fb36..3afe148ef683 100644 > --- a/kernel/trace/trace.c > +++ b/kernel/trace/trace.c > @@ -3928,6 +3928,8 @@ static void *s_next(struct seq_file *m, void *v, loff_t > *pos) > > iter->pos = *pos; > > + cond_resched(); > + > return ent; > } >
