Robert Latham wrote:
On Fri, Mar 31, 2006 at 01:21:26PM +0200, Phil Carns wrote:
flow-cancel-complete.patch:
--------------------------
I don't know that this is ever triggered, but this patch addresses a
possible bug in the flow protocol. After the cancellation function is
called, the flow protocol should immediately check to see if the flow
has been marked as complete. It is possible that the flow will change
state during that function.
Hi Phil
I don't know the flow code very well, so can you tell me how the flow
can change state while the flow_data->parent->flow_mutex is held?
thanks
==rob
Sure thing.
In general the flow protcol has only a handful of entry points that are
actually driven by something external: the _post() function, the
_callback_wrapper() functions, and the _cancel() function are the main
ones. Each of those functions therefore grabs a mutex lock to prevent
some other external entity from modifying the flow while it operates.
However, each of those entry point functions themselves may then call a
sequence of other internal functions that assume that someone is holding
the lock. These internal functions most of the time are of the
_callback_fn() variety. In the _cancel() case, the internal function of
note is handle_io_error(). These internal functions are the real
workers that change the state of the flow, always assuming that a parent
function holds the lock. Therefore in general it is actually the case
that you grab a lock and then call a subroutine that you expect to
change the state for you while you hold the lock.
In the particular case that this patch addresses, _cancel() function is
really just kind of a wrapper function that grabs the mutex and then
lets handle_io_error() drive the work. However, it was the one case out
of all of those entry point functions that doesn't check to see if the
flow has been completed after calling an internal function (see
_callback_wrapper() for examples that do the right thing). I'm also not
even 100% sure it is possible for the handle_io_error() function by
itself to reach the completed state on the first try, but we may as well
handle it just in case :)
-Phil
_______________________________________________
Pvfs2-developers mailing list
[email protected]
http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
