]> git.michaelhowe.org Git - packages/o/openafs.git/commit
viced: Keep H_LOCK while locking host in h_Alloc_r
authorAndrew Deason <adeason@sinenomine.net>
Tue, 20 Dec 2011 22:44:42 +0000 (17:44 -0500)
committerDerrick Brashear <shadow@dementix.org>
Thu, 23 Feb 2012 01:45:54 +0000 (17:45 -0800)
commit26a22e65eabbb077f0d2d0c98017bbec5ce4c533
tree992c7695bb7b9e5fbfd174dd20013b4f9432a239
parent3edb993a8dd92ea7edb0fb13c7d5391604e9cdc1
viced: Keep H_LOCK while locking host in h_Alloc_r

Currently in h_Alloc_r, we h_Lock_r the host, so we have it locked on
return. However, h_Lock_r drops the host glock, which is bad in this
situation since we have already added the host to the global hash
table, so other threads may see it. This can mean that by the time
h_Alloc_r returns, the returned host may have HOSTDELETED set, and/or
the addresses associated with the host may be completely different.

h_Alloc_r's caller, h_GetHost_r, seems to assume that the host is
still associated with the address of the passed-in connection. When
this is not true, this can result in the host structure getting into a
strange state, such as the primary addr/port may not be hashed. The
host may also have HOSTDELETED set, in which case we're not supposed
to be dealing with it at all.

To avoid these problems, lock host->lock directly in h_Alloc_r,
without going through h_Lock_r and dropping H_LOCK. Also do it as one
of the first things we do to initialize the host, just to make sure
that if anybody else happens to see the host, it is locked by us when
they do.

Reviewed-on: http://gerrit.openafs.org/6389
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
(cherry picked from commit d6f977830c164ee079c68101595c28ff1847f88f)

Change-Id: Ib0916f3a92c4a34555ee3fa2880dec10041bf047
Reviewed-on: http://gerrit.openafs.org/6754
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Derrick Brashear <shadow@dementix.org>
src/viced/host.c