[Date Prev][Date Next]
Re: (ITS#6104) race condition with cancel operation
>> Bitflags should be unnecessary as such, just need a set of values.
>> Though it wouldn't hurt if they were chosen so one could use bit
>> operations to reduce checks for "o_abandon == A or B". "Suppress
>> response" value mentioned in ITS#6138 also needed, maybe that must be a
>> bitflag when combined with Cancel stuff.
> Yes, it still seems some bitflags will be more appropriate.
As long as we decide which flag combinations are (not) valid. Problem
with "unrestricted" bitflags compared to a list of values is that they
allow and thus require support for flag combinations we have no real
need to support.
>> syncprov_op_abandon() holds&si->si_ops_mutex when setting
>> so->s_op->o_abandon. Does it need that? The function needs to
>> grab op->o_conn->c_mutex when called as Cancel, but must not do
>> that while holding&si->si_ops_mutex since Abandon grabs the
>> locks in the opposite order.
> syncprov_op_abandon() can remove ops from the list, so yes, it must
> hold si_ops_mutex.
Right, but does it need si_ops_mutex while setting o_abandon? Cancel
could remove the op, unlock si_ops_mutex, lock c_mutex, update
o_abandon. Alternative: Lock c_mutex first (that must be safe since
Abandon is doing it anyway), then lock si_ops_mutex. So it's not
a critical difference, just that a lock must be held a bit longer.