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 <[email protected]> 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. > 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 [ ... ] > @@ -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/[email protected]?part=1
