possible race condition for multiattach in Unity driver

[Eric Harney]

Reviewing the Unity driver for multiattach functionality...

I believe there's a race condition possible in terminate_connection here:
https://git.openstack.org/cgit/openstack/cinder/tree/cinder/volume/drivers/dell_emc/unity/adapter.py?h=13.0.4#n413

Since there is no locking around initialize_connection and terminate_connection, odd things could happen resulting in some in-use volumes being disconnected, I think.

1) Volume A starts terminate_connection, sets is_multiattach_to_host to True
2) Volume B starts initialize_connection, gets at least partly connected
3) Volume A gets into _detach_and_delete_host and tears down Volume B's connection unexpectedly.

Can someone who maintains the Unity driver look into this?

[Yong Huang (yonghuang)]

Hi Eric,

Actually there is a lock around initialize_connection and terminate_connection. _create_host_and_attach called by initialize_connection and _detach_and_delete_host called by terminate_connection share this lock:

def _create_host_and_attach(self, host_name, lun_or_snap):
 @utils.lock_if(self.to_lock_host, '{lock_name}')
 def _lock_helper(lock_name):
  ...
 return _lock_helper('{unity}-{host}'.format(unity=self.client.host, host=host_name))

def _detach_and_delete_host(self, host_name, lun_or_snap, is_multiattach_to_host=False):
 @utils.lock_if(self.to_lock_host, '{lock_name}')
 def _lock_helper(lock_name):
  ...
 return _lock_helper('{unity}-{host}'.format(unity=self.client.host, host=host_name))

So the Volume B attach should not be impacted by Volume A detach.

And if is_multiattach_to_host is True, self.client.detach(host, lun_or_snap) and self.client.delete_host_wo_lock(host) will not be called in _detach_and_delete_host since the volume still attached to some instances.

So I think the race condition you mentioned may not happen.