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(a)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(a)lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org <mailto:devel-leave@lists.nfs-ganesha.org> _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org