On 3/25/21 4:32 AM, Gulam Mohamed wrote: > Description > =========== > 1. This Kernel panic could be due to a timing issue when there is a > race between the sync thread and the initiator was processing of > a login response from the target. The session re-open can be invoked > from two places: > a. Sessions sync thread when the iscsid restart > b. From iscsid through iscsi error handler > 2. The session reopen sequence is as follows in user-space > a. Disconnect the connection > b. Then send the stop connection request to the kernel > which releases the connection (releases the socket) > c. Queues the reopen for 2 seconds delay > d. Once the delay expires, create the TCP connection again by > calling the connect() call > e. Poll for the connection > f. When poll is successful i.e when the TCP connection is > established, it performs: > i. Creation of session and connection data structures > ii. Bind the connection to the session. This is the place > where we assign the sock to tcp_sw_conn->sock > iii. Sets parameters like target name, persistent address > iv. Creates the login pdu > v. Sends the login pdu to kernel > vi. Returns to the main loop to process further events. > The kernel then sends the login request over to the > target node > g. Once login response with success is received, it enters full > feature phase and sets the negotiable parameters like > max_recv_data_length,max_transmit_length, data_digest etc. > 3. While setting the negotiable parameters by calling > "iscsi_session_set_neg_params()", kernel panicked as sock was NULL > > What happened here is > --------------------- > 1. Before initiator received the login response mentioned in above > point 2.f.v, another reopen request was sent from the error > handler/sync session for the same session, as the initiator utils > was in main loop to process further events (as mentioned in point > 2.f.vi above). > 2. While processing this reopen, it stopped the connection which > released the socket and queued this connection and at this point > of time the login response was received for the earlier one > > Fix > --- > 1. Add new connection state ISCSI_CONN_BOUND in "enum iscsi_connection > _state" > 2. Set the connection state value to ISCSI_CONN_DOWN upon > iscsi_if_ep_disconnect() and iscsi_if_stop_conn() > 3. Set the connection state to the newly created value ISCSI_CONN_BOUND > after bind connection (transport->bind_conn()) > 4. In iscsi_set_param, return -ENOTCONN if the connection state is not > either ISCSI_CONN_BOUND or ISCSI_CONN_UP > > Signed-off-by: Gulam Mohamed <gulam.mohamed@xxxxxxxxxx> > Reviewed-by: Mike Christie <michael.christie@xxxxxxxxxx>
