On 3/29/22 11:03, Mike Christie wrote:
When userspace restarts during boot or upgrades it won't know about the offload driver's endpoint and connection mappings. iscsid will start by cleaning up the old session by doing a stop_conn call. Later if we are able to create a new connection, we cleanup the old endpoint during the binding stage. The problem is that if we do stop_conn before doing the ep_disconnect call offload drivers can still be executing IO. We then might free tasks from the under the card/driver. This moves the ep_disconnect call to before we do the stop_conn call for this case. It will then work and look like a normal recovery/cleanup procedure from the driver's point of view. Signed-off-by: Mike Christie <michael.christie@xxxxxxxxxx> --- drivers/scsi/scsi_transport_iscsi.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/scsi/scsi_transport_iscsi.c b/drivers/scsi/scsi_transport_iscsi.c index 4e10457e3ab9..4aee0441e624 100644 --- a/drivers/scsi/scsi_transport_iscsi.c +++ b/drivers/scsi/scsi_transport_iscsi.c @@ -2260,6 +2260,15 @@ static int iscsi_if_stop_conn(struct iscsi_transport *transport, * Figure out if it was the kernel or userspace initiating this. */ if (!test_and_set_bit(ISCSI_CLS_CONN_BIT_CLEANUP, &conn->flags)) { + if (conn->ep) { + /* + * For offload, when iscsid is restarted it + * won't know about existing endpoints. We + * clean it up here for userspace. + */ + iscsi_ep_disconnect(conn, true); + } + iscsi_stop_conn(conn, flag); } else { ISCSI_DBG_TRANS_CONN(conn, @@ -3704,16 +3713,6 @@ static int iscsi_if_transport_conn(struct iscsi_transport *transport,switch (nlh->nlmsg_type) {case ISCSI_UEVENT_BIND_CONN: - if (conn->ep) { - /* - * For offload boot support where iscsid is restarted - * during the pivot root stage, the ep will be intact - * here when the new iscsid instance starts up and - * reconnects. - */ - iscsi_ep_disconnect(conn, true); - } - session = iscsi_session_lookup(ev->u.b_conn.sid); if (!session) { err = -EINVAL;
Reviewed-by: Lee Duncan <lduncan@xxxxxxxx>
