aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/generate_rust_target.rs
diff options
context:
space:
mode:
authorPeter Zijlstra <[email protected]>2025-09-16 21:02:41 +0000
committerPeter Zijlstra <[email protected]>2025-09-25 07:51:50 +0000
commit4ae8d9aa9f9dc7137ea5e564d79c5aa5af1bc45c (patch)
treeee3a49e04d70d79beb5ac3bb93e39adde655af30 /scripts/generate_rust_target.rs
parentLinux 6.17-rc6 (diff)
downloadkernel-4ae8d9aa9f9dc7137ea5e564d79c5aa5af1bc45c.tar.gz
kernel-4ae8d9aa9f9dc7137ea5e564d79c5aa5af1bc45c.zip
sched/deadline: Fix dl_server getting stuck
John found it was easy to hit lockup warnings when running locktorture on a 2 CPU VM, which he bisected down to: commit cccb45d7c429 ("sched/deadline: Less agressive dl_server handling"). While debugging it seems there is a chance where we end up with the dl_server dequeued, with dl_se->dl_server_active. This causes dl_server_start() to return without enqueueing the dl_server, thus it fails to run when RT tasks starve the cpu. When this happens, dl_server_timer() catches the '!dl_se->server_has_tasks(dl_se)' case, which then calls replenish_dl_entity() and dl_server_stopped() and finally return HRTIMER_NO_RESTART. This ends in no new timer and also no enqueue, leaving the dl_server 'dead', allowing starvation. What should have happened is for the bandwidth timer to start the zero-laxity timer, which in turn would enqueue the dl_server and cause dl_se->server_pick_task() to be called -- which will stop the dl_server if no fair tasks are observed for a whole period. IOW, it is totally irrelevant if there are fair tasks at the moment of bandwidth refresh. This removes all dl_se->server_has_tasks() users, so remove the whole thing. Fixes: cccb45d7c4295 ("sched/deadline: Less agressive dl_server handling") Reported-by: John Stultz <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Signed-off-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: John Stultz <[email protected]>
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions