Hi,

as you may know (we may have met at Bake-A-Thon), I am working on 
NFS-Ganesha, a NFS server running in userspace. I currently face an 
issue when running cthon04 test suite, during the "lock step".
Client is linux 3.1.0-rc4, server is nfs-ganesha compiled with FSAL_VFS 
support. Server is mounted via command "mount 
-overs=4.minorversion=1,lock <server>:<path> /mnt"

During the test#2 in "lock" tests, I got the following error:

    Creating parent/child synchronization pipes.

    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: 0/0 pass, 0/0 warn, 1/1 fail (pass/total).

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


I made a wireshark capture of the packet (see attachement). Apparently, 
the client does 2 compounds, one for OP4_OPEN and a second to call 
OP4_OPEN_CONFIRM.

On the client side, the "locl/locklfs" binary fails when calling lockf() 
(this is not the first time it calls it, it has been done in test#1 
which passed successfully). Error return is ENOLCK (posix error #37).
I enabled the kernel's debug message by using the command 'echo 32767 > 
/proc/sys/sunrpc/nfs_debug' (complete log in attachement, reduced to 
what is related to lock#2). Grepping 'NFS' in this shows this:

    Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/523265
    ct=2 info=0x27e7f)
    Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/523265),
    mask=0x1, res=0
    Dec  5 13:31:08 aury63 kernel: NFS: nfs_lookup_revalidate(/rep) is valid
    Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/544895
    ct=1 info=0x27e7f)
    Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544895),
    mask=0x1, res=0
    Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544895),
    mask=0x1, res=0
    Dec  5 13:31:08 aury63 kernel: NFS: atomic_lookup(0:16/544895),
    lockfile2908
    Dec  5 13:31:08 aury63 kernel: decode_attr_pnfstype: bitmap is 0
    Dec  5 13:31:08 aury63 kernel: nfs4_schedule_state_renewal:
    requeueing work. Lease period = 80
    Dec  5 13:31:08 aury63 kernel: --> nfs_put_client({2})
    Dec  5 13:31:08 aury63 kernel: <-- nfs4_setup_sequence status=0
    Dec  5 13:31:08 aury63 kernel: NFS: nfs_update_inode(0:16/544895
    ct=1 info=0x27e67)
    Dec  5 13:31:08 aury63 kernel: NFS: change_attr change on server for
    file 0:16/544895
    Dec  5 13:31:08 aury63 kernel: NFS: mtime change on server for file
    0:16/544895
    Dec  5 13:31:08 aury63 kernel: NFS: nfs_fhget(0:16/544930 ct=1)
    Dec  5 13:31:08 aury63 kernel: NFS: open file(rep/lockfile2908)
    Dec  5 13:31:08 aury63 kernel: NFS: permission(0:16/544930),
    mask=0x26, res=0
    Dec  5 13:31:08 aury63 kernel: NFS: lock(rep/lockfile2908, t=1,
    fl=1, r=0:9223372036854775807)

I can see no reason why ENOLCK is returned. This is clearly a bug on the 
server handside (within nfs-ganesha) but I have to know what the client 
is doing here to have a clearer idea.
I ran the same test using NFSv4.1 and NFSv3+NLMv4, things go perfectly 
OK with no failure.

Can someone help me ?

    Regards

       Philippe