On 3/11/2014 5:00 PM, Bart Van Assche wrote:
On 03/11/14 15:48, Sagi Grimberg wrote:
But I think this lock can be taken conditionally. I mean in the
sunny-day scenario we don't expect
srp_terminate_io to race with srp_post_send. That can happen only when
rport state transitions
to FAIL_FAST right? and also in some strange case when the rport is in
state RUNNING but the
sdev is offline and queuecommand is not even invoked. Do you think that
acquiring the target->lock
in case rport state is FAST_FAIL suffices?
That would be tricky to implement since the rport state can change after
having checked it and while srp_post_send() is in progress.
Yes I agree, Just another comment before I give up on this.
State FAIL_FAST must come *after* stated BLOCKED. Do you think that
taking the lock
once the rport transitions to state BLOCKED suffices? I'm aiming to
avoid this lock in
the sunny-day flow. Taking this lock always to protect against some
error flow
that might occur feels somewhat wrong to me.
Sagi.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
