Skip to content

Fix race in scheduler integration tests #132451

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

macsko
Copy link
Member

@macsko macsko commented Jun 23, 2025

What type of PR is this?

/kind cleanup

What this PR does / why we need it:

There is an almost impossible data race in kube-scheduler that can be detected using built-in go test race detector. If pod gets updated (Update method of PriorityQueue is called - here) and then pod is popped from the queue, processed by the scheduling cycle and then handled in failure handler (here), the race occurs. See more detailed description here: #132043 (comment).

This PR moves deletion from unschedulablePods right after the pod is moved to the backoffQ (similarly to the activeQ). This allows to remove deletion from unschedulablePods from Update method, removing the data race.

Moreover, preemptionDoneChannels in TestAsyncPreemption is covered by the lock to prevent race in the test code itself.

Which issue(s) this PR is related to:

Fixes #132025

Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added release-note-none Denotes a PR that doesn't merit a release note. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels Jun 23, 2025
@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added needs-priority Indicates a PR lacks a `priority/foo` label and requires one. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Jun 23, 2025
@k8s-ci-robot k8s-ci-robot requested review from denkensk and dom4ha June 23, 2025 07:59
@k8s-ci-robot k8s-ci-robot added sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. area/test sig/testing Categorizes an issue or PR as relevant to SIG Testing. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Jun 23, 2025
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: macsko

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@macsko
Copy link
Member Author

macsko commented Jun 23, 2025

/cc @dom4ha @sanposhiho

@sanposhiho
Copy link
Member

/cc @googs1025

can you take a look for a first reviewing path

@k8s-ci-robot k8s-ci-robot requested a review from googs1025 June 23, 2025 22:48
@@ -1017,7 +1019,6 @@ func (p *PriorityQueue) Update(logger klog.Logger, oldPod, newPod *v1.Pod) {
queue := p.requeuePodWithQueueingStrategy(logger, pInfo, hint, evt.Label())
if queue != unschedulablePods {
logger.V(5).Info("Pod moved to an internal scheduling queue because the Pod is updated", "pod", klog.KObj(newPod), "event", evt.Label(), "queue", queue)
p.unschedulablePods.delete(pInfo.Pod, gated)
Copy link
Member

@googs1025 googs1025 Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Not sure if this is correct) According to the description, but when I looked at the source code 🤔 , I found that the Update method still seems to call the moveToBackoffQ method. Will this have any impact?

This PR moves deletion from unschedulablePods right after the pod is moved to the backoffQ (similarly to the activeQ). This allows to remove deletion from unschedulablePods from Update method, removing the data race.

if isPodUpdated(oldPod, newPod) {
// Pod might have completed its backoff time while being in unschedulablePods,
// so we should check isPodBackingoff before moving the pod to backoffQ.
if p.backoffQ.isPodBackingoff(pInfo) {
if added := p.moveToBackoffQ(logger, pInfo, framework.EventUnscheduledPodUpdate.Label()); added {
p.unschedulablePods.delete(pInfo.Pod, gated)
if p.isPopFromBackoffQEnabled {
p.activeQ.broadcast()
}
}
return
}

Copy link
Member Author

@macsko macsko Jun 24, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update calls moveToBackoffQ through requeuePodWithQueueingStrategy as well. However, moving the deletion from unschedulablePods right after adding the pod to the backoffQ, mitigates the race risk.

I also noticed that I forgot to remove the line 1034, I updated the PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

got this. thanks 😄

@macsko macsko force-pushed the fix_race_in_scheduler_integration_tests branch from 14c646f to 018c7f7 Compare June 24, 2025 14:39
@sanposhiho
Copy link
Member

/hold

for merging it after my (or dom4ha's) approval

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jun 25, 2025
@macsko macsko force-pushed the fix_race_in_scheduler_integration_tests branch from 018c7f7 to 1024b21 Compare June 30, 2025 13:05
@dom4ha
Copy link
Member

dom4ha commented Jun 30, 2025

The change itself looks good.
It's not clear to me why we need to update the pod Info in error handler at all. Shouldn't we wait for update instead?
I'd also think about removing pods from queues at the beginning of Update to prevent from poping out not updated pod version (pop does not block on PriorityQueue lock)

@macsko
Copy link
Member Author

macsko commented Jul 1, 2025

It's not clear to me why we need to update the pod Info in error handler at all.

I agree that we need to take a look at the update part of the scheduling queue, likely in a new issue (I'll create it).

I'd also think about removing pods from queues at the beginning of Update to prevent from poping out not updated pod version (pop does not block on PriorityQueue lock)

Or just take activeQ's and backoffQ's locks for a part of the Update func.

@dom4ha
Copy link
Member

dom4ha commented Jul 1, 2025

Or just take activeQ's and backoffQ's locks for a part of the Update func.

Right, that might be equivalent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note-none Denotes a PR that doesn't merit a release note. sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

scheduler handleSchedulingFailure: DATA RACE
5 participants