Lee Duncan <LDuncan@xxxxxxxx> writes: > On 12/9/19 10:20 AM, Gabriel Krisman Bertazi wrote: >> From: Bharath Ravi <rbharath@xxxxxxxxxx> >> >> Connection failure processing depends on a daemon being present to (at >> least) stop the connection and start recovery. This is a problem on a >> multipath scenario, where if the daemon failed for whatever reason, the >> SCSI path is never marked as down, multipath won't perform the >> failover and IO to the device will be forever waiting for that >> connection to come back. >> >> This patch implements an optional feature in the iscsi module, to >> perform the connection failure inside the kernel. This way, the >> failover can happen and pending IO can continue even if the daemon is >> dead. Once the daemon comes alive again, it can perform recovery >> procedures if applicable. > > > I don't suppose you've tested how this plays with the daemon, when present? Hello, Yes, I did. It seemed to work properly over TCP. The stop calls are serialized by the rx_mutex, whoever gets it first, gets the job done. The second should return immediately since the socket is no longer there. What am I missing? -- Gabriel Krisman Bertazi
