runtime_vm: Avoid possible deadlock on UpdateContainerStatus()

StartContainer() function will hold the opLock, while a goroutine will
be waiting for the container to terminate. Once it happens, the
goroutine would update the container status, calling then
UpdateContainerStatus() which will try to get the opLock and,
consequently, a deadlock will happen.

In order to avoid such situation, let's create the
updateContainerStatus() helper, which actually does status update but
does not try to get the opLock, leaving it up to the caller to do so.

This new helper will be used from both StartContainer() and
UpdateContainerStatus() functions.

Signed-off-by: Fabiano Fidêncio <[email protected]>

internal/oci/runtime_vm.go

@@ -255,7 +255,7 @@ func (r *runtimeVM) StartContainer(c *Container) error {
 	go func() {
 		_, err := r.wait(r.ctx, c.ID(), "")
 		if err == nil {
-			if err1 := r.UpdateContainerStatus(c); err1 != nil {
+			if err1 := r.updateContainerStatus(c); err1 != nil {
 				logrus.Warningf("error updating container status %v", err1)
 			}
 		} else {
@@ -579,6 +579,16 @@ func (r *runtimeVM) UpdateContainerStatus(c *Container) error {
 	c.opLock.Lock()
 	defer c.opLock.Unlock()
 
+	return r.updateContainerStatus(c)
+}
+
+// updateContainerStatus is a UpdateContainerStatus helper, which actually does the container's
+// status refresh.
+// It does **not** Lock the container, thus it's the caller responsibility to do so, when needed.
+func (r *runtimeVM) updateContainerStatus(c *Container) error {
+	logrus.Debug("runtimeVM.updateContainerStatus() start")
+	defer logrus.Debug("runtimeVM.updateContainerStatus() end")
+
 	// This can happen on restore, for example if we switch the runtime type
 	// for a container from "oci" to "vm" for the same runtime.
 	if r.task == nil {