[Bug 259440] iSCSI initiator: Review for robustness (was: panic: isc->receive_pdu != NULL)
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 259440] iSCSI initiator: panic: isc->receive_pdu != NULL"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 26 Oct 2021 18:26:11 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259440 John Baldwin <jhb@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jhb@FreeBSD.org --- Comment #3 from John Baldwin <jhb@FreeBSD.org> --- Note that in my testing (and in Chelsio's internal QA) the initiator has generally been found to be fairly robust for many failure modes. I do think one panic I've seen is that there might be some cases (bad header CRC?) where it can try to abort the connection without freeing the current WIP PDU but due to data already in flight on the socket it tries to process another PDU and trips over the WIP PDU. In fact, I think that's the panic you got here. I think at one point I made it just bail here locally rather than the assertion failure for this case. That's the only panic I have run into when using the software target or initiator though. Something like this: diff --git a/sys/dev/iscsi/icl_soft.c b/sys/dev/iscsi/icl_soft.c index 45d2e53d8db0..3566aa07c7c7 100644 --- a/sys/dev/iscsi/icl_soft.c +++ b/sys/dev/iscsi/icl_soft.c @@ -577,8 +577,12 @@ icl_conn_receive_pdu(struct icl_soft_conn *isc, struct mbuf **r, size_t *rs) bool more_needed; if (isc->receive_state == ICL_CONN_STATE_BHS) { - KASSERT(isc->receive_pdu == NULL, - ("isc->receive_pdu != NULL")); + if (isc->receive_pdu != NULL) { + ICL_DEBUG("dropping PDU received after error"); + icl_conn_fail(ic); + return (NULL); + } + request = icl_soft_conn_new_pdu(ic, M_NOWAIT); if (request == NULL) { ICL_DEBUG("failed to allocate PDU; " -- You are receiving this mail because: You are the assignee for the bug.