Re: [PATCH] IB/srp: Fix initiator lockup

[Bart Van Assche <bart.vanassche-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Wed, Jan 6, 2010 at 10:37 PM, Roland Dreier <rdreier-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org> wrote:
>
>  > When the SRP initiator is communicating with an SRP target under load it can
>  > happen that the SRP initiator locks up. The communication pattern that causes
>  > the lockup is as follows:
>  > * SRP initiator sends (req_lim - 2) SRP_CMD requests to the target.
>  > * The REQUEST LIMIT DELTA field of each SRP_RSP response is zero.
>  > * The target sends an SRP_CRED_REQ information unit with non-zero REQUEST
>  >   LIMIT DELTA.
>  >
>  > The above communication pattern brings the initiator in the following state:
>  > * srp_queuecommand() always returns SCSI_MLQUEUE_HOST_BUSY.
>  > * The per-session variable zero_req_lim keeps increasing.
>  > The initiator never leaves this state because it ignores SRP_CRED_REQ
>  > information units.
>
> This is all a bit obfuscated.  The problem is that the initiator runs
> out of credits and stops sending commands; because we don't process
> SRP_CRED_REQ messages from the target, we never get more credits.
>
> I'm wondering why this took so long to come up?  Does SCST send
> SRP_CRED_REQ only under unusual circumstances?  Also I'm wondering why
> the "Unhandled SRP opcode" message didn't show up in the kernel log and
> help debug this?

It was only recently that I had the time to analyze this issue in
depth and that I added SRP_CRED_REQ support in SCST (checked in that
support about one week ago). Before SRP_CRED_REQ support was added in
SCST, the SRP initiator could not log the "Unhandled SRP opcode"
message because it did not receive any unhandled SRP opcodes.

>  > +    for (i = 0; i < ARRAY_SIZE(target->txp_ring); ++i)
>  > +            srp_free_iu(target->srp_host, target->txp_ring[i]);
>
> Not sure I understand why we need two TX rings -- why can't we just have
> one bigger TX ring that handles both requests and responses?

At the time I added the second TX ring it wasn't yet clear to me that
one single TX ring would work too. I'll merge both TX rings.

Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html