According to my reading, either 0 or INT64_MAX should work fine, since locking beyond the end of the file is fine. Daniel On 04/25/2018 05:22 AM, Malahal Naineni wrote:

knfsd seems to send EINVAL based on a quick look at the code. Assuming it as end of file (0) may work, but will have to check if all cthon tests pass!

On Wed, Apr 25, 2018 at 4:26 AM, Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com>> wrote:

In NFS v4 and NLM, the lock length type is uint64_t. In many of our supported filesystems, lock length is defined as off_t or off64_t which are signed quantities.____

__ __

The Windows NFS v3 client at least has demonstrated issuing a lock length of UINT64_MAX.____

__ __

FSAL_GPFS returns an error if lock length is greater than LONG_MAX.____

__ __

FSAL_GLUSTER and FSAL_VFS stuff the value into an off64_t, and then complains about lock length being less than zero.____

__ __

I’m not sure about the other FSALs.____

__ __

Returning an error ends up making Windows applications not work which is not ideal.____

__ __

I think it might be best if inside the FSAL, we just quietly reduce lock length to a valid value, though I don’t know if that should be:____

__ __

0 – indicating end of file____

INT64_MAX – largest possible length____

INT64_MAX – offset – so end of lock doesn’t exceed INT64_MAX____

____

Does anyone have any thoughts?____

__ __

Frank____

_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org>

_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org