IB/srp: Make receive buffer handling more robust
authorBart Van Assche <bvanassche@acm.org>
Fri, 30 Jul 2010 10:59:05 +0000 (10:59 +0000)
committerRoland Dreier <rolandd@cisco.com>
Wed, 4 Aug 2010 18:47:39 +0000 (11:47 -0700)
commitc996bb47bb419b7c2f75499e11750142775e5da9
tree8eadd7bb19484cc69fff17a218171f36085978ab
parent7a7008110b94dfaa90db4b0cc5b0c3f964c80506
IB/srp: Make receive buffer handling more robust

The current strategy in ib_srp for posting receive buffers is:

 * Post one buffer after channel establishment.
 * Post one buffer before sending an SRP_CMD or SRP_TSK_MGMT to the target.

As a result, only the first non-SRP_RSP information unit from the
target will be processed.  If that first information unit is an
SRP_T_LOGOUT, it will be processed.  On the other hand, if the
initiator receives an SRP_CRED_REQ or SRP_AER_REQ before it receives a
SRP_T_LOGOUT, the SRP_T_LOGOUT won't be processed.

We can fix this inconsistency by changing the strategy for posting
receive buffers to:

 * Post all receive buffers after channel establishment.
 * After a receive buffer has been consumed and processed, post it again.

A side effect is that the ib_post_recv() call is moved out of the SCSI
command processing path.  Since __srp_post_recv() is not called
directly any more, get rid of it and move the code directly into
srp_post_recv().  Also, move srp_post_recv() up in the file to avoid a
forward declaration.

Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
Acked-by: David Dillow <dave@thedillows.org>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
drivers/infiniband/ulp/srp/ib_srp.c