[jira] [Resolved] (YUNIKORN-3430) registerNodesInternal releases and retakes the context lock around the wait group

["Wilfred Spiegelenburg (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/YUNIKORN-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wilfred Spiegelenburg resolved YUNIKORN-3430.
---------------------------------------------
    Resolution: Won't Do

Gone over this again in the code and this should not be changed.

The only time multiple nodes are processed is during the initialisation of the cache on startup. At that point there is nothing scheduling and no other changes being made to the cache. There is no possibility that the node state changed as described as it is the same node object.

During normal processing each node is processed separately. All actions on nodes are serialised on the core side. The registration of a node only happens for a new node and the node is marked unschedulable by default. That change will only be made after the registration has completed successfully.

The cached node object is leading even if that changes while processing.

> registerNodesInternal releases and retakes the context lock around the wait group
> ---------------------------------------------------------------------------------
>
>                 Key: YUNIKORN-3430
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-3430
>             Project: Apache YuniKorn
>          Issue Type: Sub-task
>          Components: shim - kubernetes
>            Reporter: Dale Richardson
>            Assignee: jimmycmlin
>            Priority: Minor
>
> {{Context.registerNodesInternal}} is documented as requiring the context write lock, yet it unlocks and re-locks {{ctx.lock}} around its wait for the core's node-accepted events, splitting the caller's critical section in two. {{updateNodeInternal}} continues after the call with adopted-pod registration and {{enableNode}} on state it established before the gap, and the wait has no timeout (YUNIKORN-3239 saw it last 53 minutes).
> No corruption has been shown; the hazard is that nothing re-validates the invariants after the wait, and the analyser has to exclude the whole function from checking.
> Fix: build the request under the lock, release, send and wait, then re-take the lock to apply the results, instead of unlocking inside the callee.
> Marker: {{registerNodesInternal}} in {{context.go}} carries a function-level {{+checklocksignore}} for this JIRA; the fix removes it.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: dev-help@yunikorn.apache.org