Re: [PATCH v3] sched/stats: Fix run_delay over-count for migrated sched_delayed tasks

[albin_yang]

Hi Peter,

Just a gentle ping in case this got buried -- it's been a few weeks since v3.
Happy to change whatever you think is needed.

To recap: proxy exec does seem to have the same re-arm problem, but I don't
think t->is_blocked can gate it -- in ttwu_runnable() the real wakeup enqueue
sits inside the if (p->is_blocked) branch, while is_blocked is cleared
afterwards in ttwu_do_wakeup(), so !is_blocked would suppress the very re-arm
this patch relies on. And I don't think task_is_blocked() can replace
se.sched_delayed either, since a delayed sleeper has no blocked_on.

One more point: the bug predates proxy exec -- DELAY_DEQUEUE landed in v6.12,
proxy exec only in v6.17. Coupling the fix with task_is_blocked() would tie it
to infrastructure absent before v6.17, so it could no longer be backported
as-is to the v6.12.y..v6.16.y trees where the over-count happens.

So I'd suggest taking this patch as-is (delayed dequeue only) and handling the
proxy exec side separately; if you'd rather cover both here, I'm happy to send
a v4 with !sched_delayed && !task_is_blocked(), though I'd want to reproduce
the proxy case first and re-check Prateek's Tested-by -- just let me know.

Thanks,
Wei Yang