From: Trond Myklebust <trondmy@hammerspace.com>
To: "aglo@umich.edu" <aglo@umich.edu>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH] SUNRPC: Don't retry using the same source port if connection failed
Date: Sat, 30 Sep 2023 02:57:28 +0000 [thread overview]
Message-ID: <c32aec7b2a8b226a1617ff9755b7b5ce64ad3114.camel@hammerspace.com> (raw)
In-Reply-To: <CAN-5tyF9rKdu0D-7nUFQtq1BWQABb+mdY3sLrDY1-sU_Q2p8fA@mail.gmail.com>
On Thu, 2023-09-28 at 10:58 -0400, Olga Kornievskaia wrote:
> On Wed, Sep 27, 2023 at 3:35 PM <trondmy@kernel.org> wrote:
> >
> > From: Trond Myklebust <trond.myklebust@hammerspace.com>
> >
> > If the TCP connection attempt fails without ever establishing a
> > connection, then assume the problem may be the server is rejecting
> > us
> > due to port reuse.
>
> Doesn't this break 4.0 replay cache? Seems too general to assume that
> any unsuccessful SYN was due to a server reboot and it's ok for the
> client to change the port.
This is where things get interesting. Yes, if we change the port
number, then it will almost certainly break NFSv3 and NFSv4.0 replay
caching on the server.
However the problem is that once we get stuck in the situation where we
cannot connect, then each new connection attempt is just causing the
server's TCP layer to push back and recall that the connection from
this port was closed.
IOW: the problem is that once we're in this situation, we cannot easily
exit without doing one of the following. Either we have to
1. Change the port number, so that the TCP layer allows us to
connect.
2. Or.. Wait for long enough that the TCP layer has forgotten
altogether about the previous connection.
The problem is that option (2) is subject to livelock, and so has a
potential infinite time out. I've seen this livelock in action, and I'm
not seeing a solution that has predictable results.
So unless there is a solution for the problems in (2), I don't see how
we can avoid defaulting to option (1) at some point, in which case the
only question is "when do we switch ports?".
>
> >
> > Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> > ---
> > net/sunrpc/xprtsock.c | 10 +++++++++-
> > 1 file changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
> > index 71848ab90d13..1a96777f0ed5 100644
> > --- a/net/sunrpc/xprtsock.c
> > +++ b/net/sunrpc/xprtsock.c
> > @@ -62,6 +62,7 @@
> > #include "sunrpc.h"
> >
> > static void xs_close(struct rpc_xprt *xprt);
> > +static void xs_reset_srcport(struct sock_xprt *transport);
> > static void xs_set_srcport(struct sock_xprt *transport, struct
> > socket *sock);
> > static void xs_tcp_set_socket_timeouts(struct rpc_xprt *xprt,
> > struct socket *sock);
> > @@ -1565,8 +1566,10 @@ static void xs_tcp_state_change(struct sock
> > *sk)
> > break;
> > case TCP_CLOSE:
> > if (test_and_clear_bit(XPRT_SOCK_CONNECTING,
> > - &transport->sock_state))
> > + &transport->sock_state)) {
> > + xs_reset_srcport(transport);
> > xprt_clear_connecting(xprt);
> > + }
> > clear_bit(XPRT_CLOSING, &xprt->state);
> > /* Trigger the socket release */
> > xs_run_error_worker(transport,
> > XPRT_SOCK_WAKE_DISCONNECT);
> > @@ -1722,6 +1725,11 @@ static void xs_set_port(struct rpc_xprt
> > *xprt, unsigned short port)
> > xs_update_peer_port(xprt);
> > }
> >
> > +static void xs_reset_srcport(struct sock_xprt *transport)
> > +{
> > + transport->srcport = 0;
> > +}
> > +
> > static void xs_set_srcport(struct sock_xprt *transport, struct
> > socket *sock)
> > {
> > if (transport->srcport == 0 && transport->xprt.reuseport)
> > --
> > 2.41.0
> >
--
Trond Myklebust Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
next prev parent reply other threads:[~2023-09-30 2:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-27 19:27 [PATCH] SUNRPC: Don't retry using the same source port if connection failed trondmy
2023-09-28 14:58 ` Olga Kornievskaia
2023-09-30 2:57 ` Trond Myklebust [this message]
2023-09-30 22:36 ` Olga Kornievskaia
2023-09-30 23:06 ` Trond Myklebust
2023-10-03 14:44 ` Olga Kornievskaia
2023-10-03 15:12 ` Jeff Layton
2023-10-03 15:28 ` Olga Kornievskaia
2023-10-03 15:32 ` Chuck Lever III
2023-10-03 15:54 ` Olga Kornievskaia
2023-10-03 15:58 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c32aec7b2a8b226a1617ff9755b7b5ce64ad3114.camel@hammerspace.com \
--to=trondmy@hammerspace.com \
--cc=aglo@umich.edu \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).