Re: "nfs4_discover_server_trunking unhandled error" on Ctrl-C

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Jun 14, 2017, at 8:29 AM, Jeff Layton <jlayton@xxxxxxxxxx> 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@xxxxxxxxx>
>>> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@xxxxxxx>
>>> Cc: "linux-nfs" <linux-nfs@xxxxxxxxxxxxxxx>, "Andy Adamson" <andros@xxxxxxxxxx>
>>> 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@xxxxxxx> 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@xxxxxxxxxxxxxxx
>>> 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@xxxxxxxxxxxxxxx
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> -- 
> 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

--
Chuck Lever



--
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



[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux