Windows: cm_FindVolumeByName refactoring
authorJeffrey Altman <jaltman@your-file-system.com>
Wed, 31 Oct 2012 13:53:57 +0000 (09:53 -0400)
committerJeffrey Altman <jaltman@your-file-system.com>
Wed, 31 Oct 2012 22:17:15 +0000 (15:17 -0700)
commitb0283d5f17aafecf258479d6691682af3baaa0fd
tree87cae862a0cce607d9d370fdd7415bf0c8efcc15
parentd914034d4c5fd48fb89b1380da24984a520bae33
Windows: cm_FindVolumeByName refactoring

The cm_volume allocation within cm_FindVolumeByName() was racy.
Given how locks were obtained and dropped it was possible for two
threads to both determine that a cm_volume_t object needed to be
allocated.  It might even have been possible for two threads to
attempt to allocate the same object.

This refactoring ensures that if a volume cannot be found under
a read lock that a second search is performed under the write lock
in case the object had in fact been allocated during the transition.

Once it is determined that an allocation is required, the cm_volumeLock
is not dropped until the object has been built and inserted into the
name hash table.   This ensures that two threads cannot attempt to
allocate a cm_volume object for the same volume group.

InterlockedIncrement is used to manage the cm_data volume count.

Change-Id: I64c07cbc0f7968c5580478ff33214f67088072f8
Reviewed-on: http://gerrit.openafs.org/8346
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@your-file-system.com>
Tested-by: Jeffrey Altman <jaltman@your-file-system.com>
src/WINNT/afsd/cm_volume.c