From: Jeff Layton <jlay...@redhat.com>

There are two calls to do_delegation in the current code, but only one
is still "live". The other is commented out.

The live one will only be called if support_ex returns false. That will
result in the ->lock_op being called to request a delegation.

Most non-support_ex FSALs have a lock op that will always return an
error. The exception is ZFS which always returns success. That seems
quite suspicious, and may be resulting in ganesha handing out
delegations when it shouldn't.

Have ZFS check whether the request is for a delegation, and have it
return ENOTSUP if it is.

Signed-off-by: Jeff Layton <jlay...@redhat.com>
---
 src/FSAL/FSAL_ZFS/file.c | 2 ++
 1 file changed, 2 insertions(+)

Full disclosure: I don't have a way to build this currently. It's just
something I noticed while going over the current delegation handling
code.

diff --git a/src/FSAL/FSAL_ZFS/file.c b/src/FSAL/FSAL_ZFS/file.c
index a8b0b24f7bb6..f497c39b4431 100644
--- a/src/FSAL/FSAL_ZFS/file.c
+++ b/src/FSAL/FSAL_ZFS/file.c
@@ -219,5 +219,7 @@ fsal_status_t tank_lock_op(struct fsal_obj_handle *obj_hdl,
                           fsal_lock_param_t *request_lock,
                           fsal_lock_param_t *conflicting_lock)
 {
+       if (request_lock->lock_sle_type == FSAL_LEASE_LOCK)
+               return fsalstat(ERR_FSAL_NOTSUPP, ENOTSUP);
        return fsalstat(ERR_FSAL_NO_ERROR, 0);
 }
-- 
2.13.3


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel

Reply via email to