From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/2] SUNRPC: Ensure that call_connect times out correctly
Date: Tue, 18 Mar 2014 14:47:21 -0400 [thread overview]
Message-ID: <532894B9.6090606@RedHat.com> (raw)
In-Reply-To: <53288146.4010601@RedHat.com>
On 03/18/2014 01:24 PM, Steve Dickson wrote:
>> The trunking code's handling of ETIMEDOUT has been there since Linux 3.7
>> > and hasn’t changed, so I really don’t see how it can have worked at one time before 3.12.
> Maybe it been broken that long.... :-)
>
> But here is the obvious loop that stop that hangs a mount forever:
>
> #8 [ffff88007a22b7e8] rpc_call_sync at ffffffffa0220210 [sunrpc]
> #9 [ffff88007a22b840] nfs4_proc_setclientid at ffffffffa0505c49 [nfsv4]
> #10 [ffff88007a22b988] nfs40_discover_server_trunking at ffffffffa0514489 [nfsv4]
> #11 [ffff88007a22b9d0] nfs4_discover_server_trunking at ffffffffa0516f2d [nfsv4]
> #12 [ffff88007a22ba28] nfs4_init_client at ffffffffa051e9a4 [nfsv4]
> #13 [ffff88007a22bb20] nfs_get_client at ffffffffa04bd6ba [nfs]
> #14 [ffff88007a22bb80] nfs4_set_client at ffffffffa051dfb0 [nfsv4]
> #15 [ffff88007a22bc00] nfs4_create_server at ffffffffa051f4ce [nfsv4]
> #16 [ffff88007a22bc88] nfs4_remote_mount at ffffffffa051790e [nfsv4]
> #17 [ffff88007a22bcb0] mount_fs at ffffffff811b3dd9
>
> The SETCLIENT times out
> NFS call setclientid auth=UNIX, 'Linux NFSv4.0 10.19.60.77/10.19.60.33 tcp'
> NFS reply setclientid: -110
>
> The nfs4_discover_server_trunking() retries
> NFS: nfs4_discover_server_trunking after status -110, retrying
>
> The happens when there server is down and so the connections
> fail with ECONNREFUSED:
> RPC: 2 call_connect_status (status -111)
>
> The mount system call never times out in which it did in the past.
>
> So who do I get the system call to time out again?
I'm thinking the problem here is the ECONNREFUSED is never
being passed up to the trunking code. The major timeout
in call_timeout() turns the ECONNREFUSED into a ETIMEDOUT
So the trunking code never know the server is refusing
the connection...
Why are ECONNREFUSED masked into ETIMEDOUTs? Should the
ECONNREFUSED passed up?
steved.
>
> steved.
next prev parent reply other threads:[~2014-03-18 18:47 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-17 18:40 [PATCH 1/2] SUNRPC: Ensure that call_connect times out correctly Trond Myklebust
2014-03-17 18:40 ` [PATCH 2/2] SUNRPC: Ensure that call_bind " Trond Myklebust
2014-03-18 19:02 ` Steve Dickson
2014-03-18 15:47 ` [PATCH 1/2] SUNRPC: Ensure that call_connect " Steve Dickson
2014-03-18 15:58 ` Trond Myklebust
2014-03-18 17:24 ` Steve Dickson
2014-03-18 18:45 ` Trond Myklebust
2014-03-18 19:00 ` Steve Dickson
2014-03-18 19:50 ` Trond Myklebust
2014-03-19 12:39 ` Steve Dickson
2014-03-19 12:52 ` Trond Myklebust
2014-03-19 14:07 ` Steve Dickson
2014-03-19 15:04 ` Trond Myklebust
2014-03-19 17:10 ` Steve Dickson
2014-03-19 17:29 ` Trond Myklebust
2014-03-19 18:22 ` Steve Dickson
2014-03-19 19:41 ` Trond Myklebust
2014-03-20 14:12 ` Steve Dickson
2014-03-20 15:19 ` Steve Dickson
2014-03-18 18:47 ` Steve Dickson [this message]
2014-03-18 18:48 ` Steve Dickson
2014-04-14 16:25 ` Jeff Layton
2014-04-14 16:57 ` Trond Myklebust
2014-04-14 17:32 ` 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=532894B9.6090606@RedHat.com \
--to=steved@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=trond.myklebust@primarydata.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.