Change:
test/integration/volumescheduling triggered a race condition when run with . From No race detected. , or testing with /sig scheduling master n/a No response No response No response No response
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc was merged instead of to fix a similar problem.
Read: Write:
cc (although I think he's OOO) Are you planning to work on a fix, Patrick, or should we find a volunteer?
I don't know how to fix this except via additional locking for that field (e.g. via ), so I wasn't planning to work on this myself because someone else might have a better idea.
Yes, sorry I'm on vacation and unfortunately I'm not sure when I'm back to work because the is blocking all flights from the vacation place. If no one else has time/a good idea for a quick bug fix, given we're close to the release, can we change the feature gate of the scheduling hint to alpha/disabled by default? And then run done() in the gate, where causing data race. That should be one of easy fixes to resolve issue in the default scheduler.
I had an idea: if we add to , then the code which currently needs to go through the pod pointer no longer needs that pointer. I'll give that a try. /assign
Or even simpler, replace with . It must be the same value, and is immutable in .
That would fix this particular race. But also passes to various other functions which also read the pointer. If using that pointer is unsafe, then those other functions also need to be fixed somehow. is this code safe?
That should be safe because of this: I'm not understanding what's different
Oh right, a Pod update would still change what's in the "assumed cache". I guess this is not a regression then.
So if makes a copy that isn't shared with anything, why is the event handler able to write into that same copy?
The write is done for a PodInfo found in the backoff queue:
Could it be that one of the steps in put the into the backoff queue because of a failure, then the event occurred, and then the code running after incorrectly used the which it no longer owns exclusively? If yes, then the proposed fix in is correct and complete. FWIW, I've tested it in and there are no more race reports. I'm just cautious because "no race report" does not mean "no races"...
Hmm, that theory doesn't pan out.: was only called in case of a success, so it's still unclear to me why that instance can be in the backoff queue.
It's not, and maybe that's the bug. already calls . So we shouldn't call again if there was a failure during binding. There should probably be an here:
/assign I want to help fix it
Oh, right, there's no after .
I appreciate your enthusiasm, but... This issue was already assigned to me. I did the work of finding the issue, reporting it, and analyzing the problem. The remaining work is to create a proper PR (good description and commit message with an explanation of the change, not just "fixes xyz") and to test that the race is indeed gone. Can we agree on letting me finish what I started and focus on that I just created? I verified that this particular commit fixes the race ().
sorry for that. I have close my pr
/unassign

Discussion:
status := sched.bindingCycle(bindingCycleCtx, state, fwk, scheduleResult, assumedPodInfo, start, podsToActivate) if !status.IsSuccess() { sched.handleBindingCycleError(bindingCycleCtx, state, fwk, assumedPodInfo, start, scheduleResult, status) <ins> return </ins> } // Usually, DonePod is called inside the scheduling queue, // but in this case, we need to call it here because this Pod won't go back to the scheduling queue.