rx: Convert rxinit_status to rx_IsRunning() 61/12761/5
authorAndrew Deason <adeason@sinenomine.net>
Thu, 2 Nov 2017 21:41:52 +0000 (16:41 -0500)
committerBenjamin Kaduk <kaduk@mit.edu>
Fri, 28 Sep 2018 13:49:36 +0000 (09:49 -0400)
commit5ced6025b9f11fadbdf2e092bf40cc87499ed277
tree04e035051c12daf4a90176d9a4d3719f34831e15
parent00aa9200be86b187c903503e56b2af55639ea2b8
rx: Convert rxinit_status to rx_IsRunning()

Currently, all rx code examines the atomic rxinit_status to determine
if rx is running (that is, if rx_InitHost has been called, and
rx_Finalize/shutdown_rx hasn't been called). This is used in rx.c to
see if we're redundantly calling our setup/teardown functions, and
outside of rx.c in a couple of places to see if rx-related resources
have been initialized.

The usage of rxinit_status is a little confusing, since setting bit 0
indicates that rx is not running, and clearing bit 0 indicates rx is
running. Since using rxinit_status requires atomic functions, this
makes code checking or setting rxinit_status a little verbose, and it
can be hard to see what it is checking for. (For example, does
'if (!rx_atomic_test_and_clear_bit(&rxinit_status, 0))' succeed when
rx running, or when rx is not running?)

The current usage of rxinit_status in rx_InitHost also does not handle
initialization errors correctly. rx_InitHost clears rxinit_status near
the beginning of the function, but does not set rxinit_status if an
error is encountered. This means that any code that checks
rxinit_status (such as another rx_InitHost call) will think that rx
was initialized successfully, but various resources aren't actually
setup. This can cause segfaults and other errors as the code tries to
actually use rx.

This can easily be seen in bosserver, if bosserver is started up while
the local host/port is in use by someone else. bosserver will try to
rx_InitHost, which will fail, and then we'll try to rx_InitHost again,
which will immediately succeed without doing any init. We then
segfault quickly afterwards as we try to use unitialized rx resources.

To fix all of this, refactor code using rxinit_status to use a new
function, called rx_IsRunning(), to make it a little clearer what
we're checking for. We also re-introduce the LOCK_RX_INIT locks to
prevent functions like rx_InitHost and rx_Finalize from running in
parallel.

Note that non-init/shutdown code (such as rx_upcall or rx_GetIFInfo)
does not need to wait for LOCK_RX_INIT to check if rx is running or
not. These functions only care if rx is currently setup enough to be
used, so we can immediately return a 'yes' or 'no' answer. That is, if
rx_InitHost is in the middle of running, rx_IsRunning returns 0, since
some resouces may not be fully initialized.

Change-Id: Ia14a6a725c9662b9db0adef48c33b48a93ffe051
Reviewed-on: https://gerrit.openafs.org/12761
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
src/rx/DARWIN/rx_knet.c
src/rx/rx.c
src/rx/rx_internal.h
src/rx/rx_user.c