Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <0aee01d63d91$1f104300$5d30c900$@gmail.com> <7E441550-FCCF-492E-BACB-271A42D4A6C4@oracle.com>
 <119601d63f43$9d55e860$d801b920$@gmail.com>
In-Reply-To: <119601d63f43$9d55e860$d801b920$@gmail.com>
From:   James Pearson <jcpearson@gmail.com>
Date:   Wed, 24 Jun 2020 09:54:26 +0100
Message-ID: <CAK3fRr-cV_0c-sHhA2rMswrHEcLrkNfHs-=ejHRS8-j8zzObhA@mail.gmail.com>
Subject: Re: NFSv4.0: client stuck looping on RENEW + NFSERR_STALE_CLIENTID
To:     Robert Milkowski <rmilkowski@gmail.com>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk

On Wed, 10 Jun 2020 at 17:24, Robert Milkowski <rmilkowski@gmail.com> wrote:
>
> >
> > The usual course of action for bugs in distributor kernels is to work
> > directly with the distributor. Upstream developers don't generally have
> > access to or expertise with those code bases. 7.3 is an older kernel,
> > and it's possible that upstream has addressed this issue and CentOS has
> > pulled that fix into a newer release.
> >
>
>
> I was hoping someone here might get back with "hey, this has been fixed by
> commit...".
> We also did see it on centos 7.6
>
> I will try to get it re-produce it and once I can then I'll try to reproduce
> it against upstream.

I haven't been monitoring this list recently - but we are still having
the same problem with CentOS 7.7 clients and Isilon filers

I've just 'fixed' one client with the issue in the way you described
earlier in this thread by looking for a process in nfs4_state_manager
via a stack trace - killing that pid with -9 and all the stuck mount
pops back to life

Have you reported this issue via the Redhat Bugzilla?

Thanks

James Pearson