Dale Richardson created YUNIKORN-3428:
-----------------------------------------
Summary: Application.taskMap read without the lock from String()
and AreAllTasksTerminated
Key: YUNIKORN-3428
URL: https://issues.apache.org/jira/browse/YUNIKORN-3428
Project: Apache YuniKorn
Issue Type: Bug
Components: shim - kubernetes
Reporter: Dale Richardson
Two methods on the shim's {{Application}} read {{taskMap}} without the
application lock while {{addTask}} (pod informer) and {{removeTask}}
(dispatcher) write it under the lock.
{{AreAllTasksTerminated}} ranges over the map. One caller,
{{flushReleaseableTasks}}, already holds the lock; the other,
{{KubernetesShim.schedule}}, holds nothing and calls it once per tick for every
Failed application. A pod arriving for such an application at that moment is a
concurrent map iteration and write, which the runtime treats as fatal. The
window is narrow but the consequence is the scheduler exiting.
{{String()}} reads {{len(app.taskMap)}}. Its one in-tree caller formats it
inside an FSM callback under the write lock, so it cannot take the lock itself;
any future {{%v}} of an application from an unlocked goroutine is a data race
on the length (benign torn int, but a {{-race}} failure).
Fix: split {{AreAllTasksTerminated}} into a locked public variant and the
unlocked internal one, as {{GetPlaceHolderTasks}} / {{getPlaceHolderTasks}}
already do; make {{String()}} print construction-time fields only, or take the
count through a locked accessor from callers that do not hold the lock.
Marker: two sites in {{application.go}} carry this JIRA; the fix removes them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
