On Mon, 14 Feb 2011 12:50:40 +0100 Bart Van Assche <bvanassche@xxxxxxx> wrote: > - send_rsp() sends back an SRP response with req_lim_delta = 1 before > srp_iu_put() is invoked. I think this is a race condition: it can > happen that the SRP initiator has received an SRP_RSP and sends a new > SRP_CMD before srp_iu_put() was invoked. On a heavily loaded system > that can trigger a queue overflow in the target. Yeah, we had better to handle such case better. But I don't think that we hit a critical event such as crash, memory corruption, etc, with the current code. In such case, srp_iu_get return NULL, so the target ignores the request, then eventually the initiator recovers. Probably, we should set the queue size to INITIAL_SRP_LIMIT + 1. > - As anyone can see in the driver code (and as specified in the PAPR) > management datagrams (MADs) fall outside the SRP credit mechanism. > Hence not reserving one credit (assuming that the initiator makes sure > there is at most one outstanding MAD) for MAD can - at least in theory > - trigger a queue overflow. I think that MAD is used only before the initiator starts real I/Os. So I don't think that we can hit this issue in reality. Thanks, -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
