Hello Jan- > On Jul 26, 2022, at 1:16 PM, Jan Kasiak <j.kasiak@xxxxxxxxx> 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
