Windows: cm_GetSCache avoid holding cm_scacheLock
authorJeffrey Altman <jaltman@your-file-system.com>
Sat, 12 Nov 2011 22:32:06 +0000 (17:32 -0500)
committerJeffrey Altman <jaltman@secure-endpoints.com>
Sun, 13 Nov 2011 01:54:45 +0000 (17:54 -0800)
commit5c59d1b500ae4ba5223184fbfe18837891ea30c3
treee94e5bfae244a841cf891bf4755502f6d8573269
parenteb3c9f783b9488181c57ef949e3feddcb02d381a
Windows: cm_GetSCache avoid holding cm_scacheLock

cm_GetSCache used to hold cm_scacheLock write-locked from
start to finish except that it didn't.  There were several
places where cm_scacheLock was dropped and reacquired due
to lock ordering requirements.  Unfortunately, this has
two problems. First, the function isn't very fast in the
most common case since cm_scacheLock is write-locked for
the search for an existing FID.  Second, there is a race
that results when cm_GetNewSCache() drops the cm_scacheLock.

To make things faster, use a read-lock for the common case.

To avoid the race, if the FID cannot be located, call
cm_GetNewSCache() first and then obtain the cell and volume
information.  Then perform a second lookup for the FID while
holding cm_scacheLock write-locked.  If we lost the race or
there was an error obtaining the cell and volume info, put
the new cm_scache_t back onto the end of the LRU queue.

Change-Id: Idb94275d23c160ee0a2dc8fdcfd0f09506ecb2d3
Reviewed-on: http://gerrit.openafs.org/6003
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Jeffrey Altman <jaltman@secure-endpoints.com>
Tested-by: Jeffrey Altman <jaltman@secure-endpoints.com>
src/WINNT/afsd/cm_scache.c
src/WINNT/afsd/cm_scache.h