Re: [RFC PATCH 01/20] sched: Add task enqueue/dequeue trace points
From: sashiko-bot@kernel.org
Date: 2026-08-31 09:32:31
Also in:
bpf
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] The `sched_enqueue_tp` tracepoint is invoked before the scheduler class has actually enqueued the task, resulting in trace consumers observing stale task state. -- commit cd98b289fdbaccae680f140f19c0e9bd5dd972b6 Author: Nam Cao [off-list ref] sched: Add task enqueue/dequeue trace points This commit adds tracepoints into the scheduler's enqueue and dequeue paths to allow tracing task scheduling events.
quoted hunk ↗ jump to hunk
diff --git a/kernel/sched/core.c b/kernel/sched/core.c index f78275192036b..8561ca324943a 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c
[ ... ]
quoted hunk ↗ jump to hunk
@@ -2181,6 +2183,9 @@ unsigned long get_wchan(struct task_struct *p) void enqueue_task(struct rq *rq, struct task_struct *p, int flags) { + if (trace_sched_enqueue_tp_enabled() && !(flags & ENQUEUE_DELAYED)) + trace_sched_enqueue_tp(p, cpu_of(rq)); +
[Severity: Medium] Because this tracepoint is placed at the beginning of the function, prior to p->sched_class->enqueue_task(), will trace consumers observe stale task state? For example, it seems that when the tracepoint triggers here, metrics like se.vruntime have not yet been denormalized for the new runqueue, the EEVDF se.deadline has not been recomputed, and on_rq is still 0. Does it make sense to move this after the class-specific enqueue operation completes, mirroring how dequeue_task() handles this by emitting trace_sched_dequeue_tp() after calling p->sched_class->dequeue_task()?
if (!(flags & ENQUEUE_NOCLOCK)) update_rq_clock(rq);
-- Sashiko AI review · https://sashiko.dev/#/patchset/20260831090524.106845-1-gmonaco@redhat.com?part=1