Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAD15GZd=sxsXiNmuN-FpRk3E_cKRF_CTLqxd5XJ4KhtON4XkPQ@mail.gmail.com>
In-Reply-To: <CAD15GZd=sxsXiNmuN-FpRk3E_cKRF_CTLqxd5XJ4KhtON4XkPQ@mail.gmail.com>
From:   Jan Kasiak <j.kasiak@gmail.com>
Date:   Wed, 20 Jul 2022 16:01:42 -0400
Message-ID: <CAD15GZe1__nJ6SfAr1zs4Vq4za9D=FP__SotyS37RVh=2OWu-g@mail.gmail.com>
Subject: Re: NLM 4 Infinite Loop Bug
To:     linux-nfs@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Applying two commits from the Linux master branch seems to have fixed
the problem:

aec158242b87a43d83322e99bc71ab4428e5ab79
1197eb5906a5464dbaea24cac296dfc38499cc00

-Jan

On Wed, Jul 20, 2022 at 2:46 PM Jan Kasiak <j.kasiak@gmail.com> wrote:
>
> Hi all,
>
> I'm writing my own NFS client, and while trying to test it, I've come
> across a way to get the lockd thread into an infinite loop and stop
> accepting any new requests.
>
> Kernel Version: Linux ubuntu-jammy 5.15.0-41-generic
>
> The client is a python program, and it does not run rpcbind, NLM, etc...
>
> I issue an NM_LOCK (procedure 22) request with block set to false, and
> get a GRANTED reply.
>
> I then issue a FREE_ALL (procedure 23) request, and the lockd thread
> gets stuck in nlm_traverse_locks - it matches the host, calls
> nlm_unlock_files, and then jumps to the again label, and repeats this
> loop forever.
>
> It's not clear to me who is supposed to unset the host from the lock?
> Any pointers as to why there is a jump to again?
>
> Thanks,
> -Jan