Dale Richardson created YUNIKORN-3415:
-----------------------------------------
Summary: Node.String() reads guarded fields without the lock and
cannot take it
Key: YUNIKORN-3415
URL: https://issues.apache.org/jira/browse/YUNIKORN-3415
Project: Apache YuniKorn
Issue Type: Bug
Components: core - scheduler
Reporter: Dale Richardson
{{Node.String()}} formats {{schedulable}}, {{totalResource}},
{{allocatedResource}} and {{len(allocations)}}, all guarded by the node lock,
without holding it. It cannot simply take the read lock: {{Node.Reserve}} holds
the node write lock when it calls {{newReservation}}, whose nil-guard logs
{{zap.Stringer("node", node)}}, so an {{RLock}} inside {{String()}} would
self-deadlock there, while {{Application.reserveInternal}} reaches the same log
line with no node lock and races the writers.
Confirmed with the race detector three ways on the fork fix branch
({{SetSchedulable}}, an allocation insert, and a resource update, each against
a concurrent format call). The reads are log-only, so the practical effect is
torn values in a log line and a race-detector failure in CI.
Fix: build the string from the construction-time identity only ({{NodeID}},
{{Partition}}), keeping the old output as a prefix so log greps still match;
the mutable values are already logged as explicit zap fields from lock-holding
code. This changes the log line, which reviewers should know. A fix exists on
the tigerquoll fork ({{fix/node-stringer-race}}, PR #17 there) and will be
filed once this has a number.
Marker: {{Node.String}} in {{node.go}} carries this JIRA; the fix removes it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
