On 03/03/2016 06:09 PM, Chris Leech wrote:
> When requests are being failed it's important to abort the TCP
> connection rather than let TCP wait and attempt a graceful shutdown.
> 
> That can be accomplished by setting the SO_LINGER socket option with a
> linger time of 0 to drop queued data and close the connection with a RST
> instead of a FIN.
> 
> Signed-off-by: Chris Leech <cle...@redhat.com>
> ---
>  usr/io.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/usr/io.c b/usr/io.c
> index f552e1e..48b233c 100644
> --- a/usr/io.c
> +++ b/usr/io.c
> @@ -391,9 +391,24 @@ iscsi_io_tcp_poll(iscsi_conn_t *conn, int timeout_ms)
>  void
>  iscsi_io_tcp_disconnect(iscsi_conn_t *conn)
>  {
> +     struct linger so_linger = { .l_onoff = 1, .l_linger = 0 };
> +
>       if (conn->socket_fd >= 0) {
>               log_debug(1, "disconnecting conn %p, fd %d", conn,
>                        conn->socket_fd);
> +
> +             /* If the state is not IN_LOGOUT, this isn't a clean shutdown
> +              * and there's some sort of error handling going on. In that
> +              * case, set a 0 SO_LINGER to force an abortive close (RST) and
> +              * free whatever is sitting in the TCP transmit queue. This is
> +              * done to prevent stale data from being sent should the
> +              * network connection be restored before TCP times out.
> +              */
> +             if (conn->state != ISCSI_CONN_STATE_IN_LOGOUT) {
> +                     setsockopt(conn->socket_fd, SOL_SOCKET, SO_LINGER,
> +                                &so_linger, sizeof(so_linger));
> +             }
> +
>               close(conn->socket_fd);
>               conn->socket_fd = -1;
>       }
> 

Nice.

For maybe a slightly different problem, but hoping I get lucky and your
patch fixes it too, I thought the network layer was still accessing
pages that we tried to send and was causing a oops. I get the part where
with your patch the network layer will not try to send data anymore, but
I guess I am asking if the network layer could still be doing some sort
of delayed cleanup process after close() has returned?

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to