| Message ID | 1497443353.6752.5.camel@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> 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
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);