Mike Christie wrote:
> The nice thing about iscsi is that the RFC is only a 200 pages (less if
> you do not count the indexes and graphs). For libfc, I have been trying
> to figure out what is going wrong with the abort transmission and I
> think I found in the depths of fc-fs.
>
> In fc_fcp.c, we seem to only call exch_done if sp->seq_ptr is set.
> However in fc_seq_exch_abort we seem to want to start a new sequence for
> the abort. I think if there is an open sequence are we supposed to send
> the abort with the SEQ_ID and SEQ_CNT like in 13.3.2.3.2 of fc-ls:
>
Ah ignore that. This should not happen, because we are holding the pkt
lock the whole time right? I thought the fc_fcp_send_data and the abort
function could race.
..... snip
> but I think we have a bug in
> the code in the implementation. Because we are trying to use a new
> sequence by reusing ep->seq, it seems like if ep->seq was being used for
> a seq then we are going to hit the warn on because the state is not yet
> completed:
>
> struct fc_seq *fc_seq_start_next(struct fc_seq *sp)
> {
> struct fc_exch *ep = fc_seq_exch(sp);
>
> spin_lock_bh(&ep->ex_lock);
> WARN_ON((ep->esb_stat & ESB_ST_COMPLETE) != 0);
>
> Is that right?
And ignore this and the other mail about it. It is actually the opposite
right? If the recv path is completing the exchange while fc_exch_abort
is calling fc_seq_start_next we could race and we do not want to warn.
We just would want to handle it gracefully. The exchange cleanup changes
we talked about already should probably be able to handle this right.
So nevermind. I guess it will be handled later.
_______________________________________________
devel mailing list
[email protected]
http://www.open-fcoe.org/mailman/listinfo/devel
