phdeniel/nfs-ganesha — Issue #16: Connectathon lock test#2 fails on 'next' and 'master'
Author: phdeniel
Created: 2011-11-03 09:49:27+00:00
State: open

On the 3.1-rc4 client, connectathon "lock" test suite fails with this message on stderr:

Testing native post-LFS locking

Creating parent/child synchronization pipes.

Test #1 - Test regions of an unlocked file.
Parent: 1.1 - F_TEST [ 0, 1] PASSED.
Parent: 1.2 - F_TEST [ 0, ENDING] PASSED.
Parent: 1.3 - F_TEST [ 0,7fffffffffffffff] PASSED.
Parent: 1.4 - F_TEST [ 1, 1] PASSED.
Parent: 1.5 - F_TEST [ 1, ENDING] PASSED.
Parent: 1.6 - F_TEST [ 1,7fffffffffffffff] PASSED.
Parent: 1.7 - F_TEST [7fffffffffffffff, 1] PASSED.
Parent: 1.8 - F_TEST [7fffffffffffffff, ENDING] PASSED.
Parent: 1.9 - F_TEST [7fffffffffffffff,7fffffffffffffff] PASSED.

Test #2 - Try to lock the whole file.
Parent: 2.0 - F_TLOCK [ 0, ENDING] FAILED!
Parent: **** Expected success, returned errno=37...
Parent: **** Probably implementation error.

** PARENT pass 1 results: 9/9 pass, 0/0 warn, 1/1 fail (pass/total).

** CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total).

Here the value '37' corresponds to POSIX errno = ENOLCK (no record locks available). On the server side, wireshark shows that the server receives several compound whose content is (OP4_PUTFH, OP4_LOCKT). The LOCKT is called in WRITE_LT mode with various offset (from 0, 1 to7fffffffffffffff) and length=ffffffffffffffff (which means "whole file" as far as I remember).
On the cthon04 side, program called in tlock whose source is tlock.c . The error comes from this line:

open_testfile(OPENFLAGS, OPENMODES);
test(2, 0, F_TLOCK, (off_t)0, (off_t)END, PASS, FATAL);
childfree(0);

Error 37 is probably produced at line tlock.c:846, in function 'test' (which is a wrapper for calling fcntl)

test(num, sec, func, offset, length, pass, fail)
/* ... I cut the declaration line to save space in this mail... */
{
struct flock request;
int result = PASS;
int fcntlcmd;

lockf2fcntl(func, &request.l_type, &fcntlcmd);
request.l_whence = 0;
request.l_start = offset;
request.l_len = length;

if (fcntl(testfd, fcntlcmd, &request) < 0)
result = errno;
else if (func == F_TEST && request.l_type != F_UNLCK)
result = denied_err;
report(num, sec, tfunstr(func), offset, length, pass, result,
fail);
}

The server itself returns no error as far as I have seen (all compound have NFS4_OK status).
This is reproducible 100% of the time on my testbed.
It's important to notice that this issue exists on 'master' too with exactly the same symptoms. I believe the bug is probably located in the NFSv4.0 locks implementation (at the protocol level), not at the state management level.
This first issue is not the regression I was speaking about, it's kind of "preservation of formerly existing bugs" :-) (an old bug that is still there).