On 07/27/2009 06:22 AM, Hannes Reinecke wrote:
> The network core will call state_change() callback
> prior to the data_ready() callback, which might cause
> us to lose a connection state change.
> So we have to evaluate the socket state at the end
> of the data_ready() callback, too.
>
> Signed-off-by: Hannes Reinecke<h...@suse.de>
> ---
>   drivers/scsi/iscsi_tcp.c |   13 +++++++++++++
>   1 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index f02ddf8..7ca52b3 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -117,6 +117,19 @@ static void iscsi_sw_tcp_data_ready(struct sock *sk, int 
> flag)
>       rd_desc.count = 1;
>       tcp_read_sock(sk,&rd_desc, iscsi_sw_tcp_recv);
>
> +     /*
> +      * We might have missed a dropped connection
> +      * from state_change() callback, evaluate now.
> +      */
> +     if ((sk->sk_state == TCP_CLOSE_WAIT ||
> +          sk->sk_state == TCP_CLOSE)&&

Need a space before the &&.

> +         !atomic_read(&sk->sk_rmem_alloc)) {


Did you copy this from the iscsi_sw_tcp_state_change check or from 
somewhere else? Do you know what the sk_rmem_alloc check is for?

I ask because I was looking at this the other day when I was trying to 
figure out why when the target closes the connection we sometimes do not 
figure it out right away and could not figure out why that sk_rmem_alloc 
check was there. I have noticed that the state changes and sk_rmem_alloc 
is greater than zero, so in iscsi_sw_tcp_state_change we end up not 
dropping the session. This then delays handling of the problem until a 
nop or scsi cmd times out and we figure out the connection is bad 
through that route.

Can the state hit WAIT or CLOSE and sk_rmem_alloc be greater than zero 
and we can end up going on successfully? Or do we check that value 
because it would leak mem if non-zero or something like that?

If we need it or not, I would just put the check in some new function or 
macro.



> +             ISCSI_SW_TCP_DBG(conn, "iscsi_tcp_data_ready: "
> +                              "TCP_CLOSE|TCP_CLOSE_WAIT\n");
> +             iscsi_conn_failure(conn, ISCSI_ERR_CONN_FAILED);
> +     }
> +
> +
>       read_unlock(&sk->sk_callback_lock);
>
>       /* If we had to (atomically) map a highmem page,


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to