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>
 <CAD15GZe1__nJ6SfAr1zs4Vq4za9D=FP__SotyS37RVh=2OWu-g@mail.gmail.com>
 <CAD15GZdCYTr0Xfn1-n-aXf5FxLDR-zrYR2TutHk_4RRbP6+pVA@mail.gmail.com> <14F384C7-1900-408F-9289-05173A8C1BC1@oracle.com>
In-Reply-To: <14F384C7-1900-408F-9289-05173A8C1BC1@oracle.com>
From:   Jan Kasiak <j.kasiak@gmail.com>
Date:   Wed, 27 Jul 2022 13:20:13 -0400
Message-ID: <CAD15GZfOqca-jBN11o2b6iVeWU5hFXXB6oj55wYEWWgwK6VKdA@mail.gmail.com>
Subject: Re: NLM 4 Infinite Loop Bug
To:     Chuck Lever III <chuck.lever@oracle.com>
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Chuck,

I created 3 bugs:

https://bugzilla.linux-nfs.org/show_bug.cgi?id=390
For the original issue I reported with FREE_ALL
because I'm not sure if its fully fixed.

https://bugzilla.linux-nfs.org/show_bug.cgi?id=391
For scenario A

https://bugzilla.linux-nfs.org/show_bug.cgi?id=392
For scenario B/C because they are very similar

Thanks,
-Jan

On Tue, Jul 26, 2022 at 1:34 PM Chuck Lever III <chuck.lever@oracle.com> wrote:
>
> Hello Jan-
>
> > On Jul 26, 2022, at 1:16 PM, Jan Kasiak <j.kasiak@gmail.com> wrote:
> >
> > Hi all,
> >
> > Even after applying the above two patches, I have discovered a new set
> > of NLM 4 requests that break lockd.
> >
> > Unfortunately, I don't have enough experience to suggest a fix, but
> > would be glad to test anyone's attempt.
> >
> > All requests are non-blocking.
> >
> > Scenario A
> > =========
> > lock(offset=UINT64_MAX, len=100) - GRANTED
> > free_all() - never finishes and lockd thread is stuck busy looping
> >
> > Scenario B
> > ========
> > lock(svid=1, offset=UINT64_MAX, len=100) - GRANTED
> >
> > test(svid=2, offset=UINT64_MAX, len=50) - DENIED
> > correct, holder offset, len are (UINT64_MAX, 100)
> >
> > test(svid=2, offset=75, len=10) - DENIED
> > wrong, because holder (offset, len) are wrong (UINT64_MAX, 100),
> > because the above
> > lock overflows during comparison to (49, 50)
> >
> > Scenario C
> > ========
> > lock(svid=1, offset=UINT64_MAX, len=100) - GRANTED
> >
> > test(svid=2, offset=UINT64_MAX, len=50) - DENIED
> > correct, holder offset, len are (UINT64_MAX, 100)
> >
> > unlock(svid=1, offset=UINT64_MAX, len=50) - GRANTED
> > weird, because it has now created a lock at (offset=UINT64_MAX + 50, len=50)
> > not sure what the correct behavior should be here - FBIG error?
> >
> > test(svid=2, offset=75, len=10) - DENIED
> > wrong, because holder offset, len are wrong (49, 50), because the above
> > unlock has overflowed the offset
>
> Thanks for testing.
>
> May I ask that you file these as three separate bugs here:
>
> https://bugzilla.linux-nfs.org/
>
>
>
> --
> Chuck Lever
>
>
>