On Thu, 21 Oct 2010 07:40:28 +1100
Neil Brown <neilb@xxxxxxx> wrote:
> >
> > Then what happens is that xs_tcp_send_request gets called again to try
> > to resend the packet. In the EHOSTUNREACH case, that returns
> > EHOSTUNREACH which eventually causes an rpc_exit with that error. In
> > the ENETUNREACH case that returns EPIPE, which makes the state machine
> > move next to call_bind and the whole thing starts over again.
>
> This confuses me. Why would xs_tcp_send_request (aka ->send_request) get
> called before the connect has succeeded? Can you make sense of that?
>
It confuses me too. I suspect that this may actually be a bug...
So EINPROGRESS makes the connect_worker task clear the connecting bit
and return. Eventually, the EHOSTUNREACH error is reported to
xs_error_report. That function does this:
xprt_wake_pending_tasks(xprt, -EAGAIN);
The task that was waiting on the connect_worker is then woken up.
call_connect_status does this:
if (status >= 0 || status == -EAGAIN) {
clnt->cl_stats->netreconn++;
task->tk_action = call_transmit;
return;
}
...and we end up in call_transmit without the socket being connected.
So I understand how this happened, but I don't really understand the
design of the connect mechanism well enough to know whether this is
by design or not.
--
Jeff Layton <jlayton@xxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
