"nfs4_discover_server_trunking unhandled error" on Ctrl-C
diff mbox

Message ID 1497443353.6752.5.camel@redhat.com
State New
Headers show

Commit Message

Jeff Layton June 14, 2017, 12:29 p.m. UTC
That warning has been around for a long time. We're running the server
trunking check and caught a signal in the middle of it. It's harmless,
AFAICT.

Should we merge a patch like this (untested) one, just to silence it? It
really is an expected situation that we needn't warn anyone about:


On Tue, 2017-06-13 at 21:22 +0200, Mkrtchyan, Tigran wrote:
> Hi Olga,
> 
> this is 4.12.-rc4.  I will check packet capture tomorrow, however, I am pretty sure that
> this is client internal interrupt processing.
> 
> Tigran.
> 
> ----- Original Message -----
> > From: "Olga Kornievskaia" <aglo@umich.edu>
> > To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> > Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Andy Adamson" <andros@netapp.com>
> > Sent: Tuesday, June 13, 2017 6:21:01 PM
> > Subject: Re: "nfs4_discover_server_trunking unhandled error" on Ctrl-C
> > On Tue, Jun 13, 2017 at 9:31 AM, Mkrtchyan, Tigran
> > <tigran.mkrtchyan@desy.de> wrote:
> > > 
> > > If I hit Ctrl-C during mount, then I see following message in the log file:
> > > 
> > >  NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO
> > > 
> > > 
> > > produced at nfs4state.c:2533. Is this expected behavior?
> > 
> > What kernel version (or upstream commit) is that? Is this
> > reproducible? Anything on the network trace that server returns that
> > could explain an error it doesn't expect. Also I'm thinking that
> > nfs_wait_client_init_complete() could be interrupted by ctrl-c and
> > return ERESTARTSYS and that could translate to "unhanded error".
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Chuck Lever June 14, 2017, 2:09 p.m. UTC | #1
> On Jun 14, 2017, at 8:29 AM, Jeff Layton <jlayton@redhat.com> wrote:
> 
> That warning has been around for a long time. We're running the server
> trunking check and caught a signal in the middle of it. It's harmless,
> AFAICT.
> 
> Should we merge a patch like this (untested) one, just to silence it? It
> really is an expected situation that we needn't warn anyone about:
> 
> diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
> index b34de036501b..ae9a9ad2894d 100644
> --- a/fs/nfs/nfs4state.c
> +++ b/fs/nfs/nfs4state.c
> @@ -2182,6 +2182,9 @@ int nfs4_discover_server_trunking(struct nfs_client *clp,
>                                 * in nfs4_exchange_id */
>                status = -EKEYEXPIRED;
>                break;
> +       case -ERESTARTSYS:
> +               status = -EINTR;
> +               break;
>        default:
>                pr_warn("NFS: %s unhandled error %d. Exiting with error EIO\n",
>                                __func__, status);

I agree that this message is noise in this case, and the patch
looks sane.


> On Tue, 2017-06-13 at 21:22 +0200, Mkrtchyan, Tigran wrote:
>> Hi Olga,
>> 
>> this is 4.12.-rc4.  I will check packet capture tomorrow, however, I am pretty sure that
>> this is client internal interrupt processing.
>> 
>> Tigran.
>> 
>> ----- Original Message -----
>>> From: "Olga Kornievskaia" <aglo@umich.edu>
>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
>>> Cc: "linux-nfs" <linux-nfs@vger.kernel.org>, "Andy Adamson" <andros@netapp.com>
>>> Sent: Tuesday, June 13, 2017 6:21:01 PM
>>> Subject: Re: "nfs4_discover_server_trunking unhandled error" on Ctrl-C
>>> On Tue, Jun 13, 2017 at 9:31 AM, Mkrtchyan, Tigran
>>> <tigran.mkrtchyan@desy.de> wrote:
>>>> 
>>>> If I hit Ctrl-C during mount, then I see following message in the log file:
>>>> 
>>>> NFS: nfs4_discover_server_trunking unhandled error -512. Exiting with error EIO
>>>> 
>>>> 
>>>> produced at nfs4state.c:2533. Is this expected behavior?
>>> 
>>> What kernel version (or upstream commit) is that? Is this
>>> reproducible? Anything on the network trace that server returns that
>>> could explain an error it doesn't expect. Also I'm thinking that
>>> nfs_wait_client_init_complete() could be interrupted by ctrl-c and
>>> return ERESTARTSYS and that could translate to "unhanded error".
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Chuck Lever



--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch
diff mbox

diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index b34de036501b..ae9a9ad2894d 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -2182,6 +2182,9 @@  int nfs4_discover_server_trunking(struct nfs_client *clp,
                                 * in nfs4_exchange_id */
                status = -EKEYEXPIRED;
                break;
+       case -ERESTARTSYS:
+               status = -EINTR;
+               break;
        default:
                pr_warn("NFS: %s unhandled error %d. Exiting with error EIO\n",
                                __func__, status);