Franks,
This patch that clears state_owner only after the call to close2 fixes my
problem.
Marc.
diff --git a/src/SAL/nfs4_state.c b/src/SAL/nfs4_state.c
index 842c2bf..dadd790 100644
--- a/src/SAL/nfs4_state.c
+++ b/src/SAL/nfs4_state.c
@@ -380,7 +380,6 @@ void state_del_locked(state_t *state)
PTHREAD_MUTEX_lock(&state->state_mutex);
glist_del(&state->state_owner_list);
- state->state_owner = NULL;
/* If we are dropping the last open state from an open
* owner, we will want to retain a refcount and let the
@@ -463,6 +462,7 @@ void state_del_locked(state_t *state)
PTHREAD_MUTEX_lock(&state->state_mutex);
glist_del(&state->state_export_list);
state->state_export = NULL;
+ state->state_owner = NULL;
PTHREAD_MUTEX_unlock(&state->state_mutex);
PTHREAD_RWLOCK_unlock(&export->lock);
put_gsh_export(export);
From: Marc Eshel/Almaden/IBM@IBMUS
To: "Frank Filz" <ffilz...@mindspring.com>
Cc: nfs-ganesha-devel@lists.sourceforge.net
Date: 08/18/2016 09:21 AM
Subject: Re: [Nfs-ganesha-devel] multi fd support
Using NFSv4 I get read lock on the same file from two different NFS
clients. The server get the two locks using the two different owners
(state), when I unlock the lock on one client that results in closing the
file I get fsal_close() with no owner id so I am forced to release all
locks which is wrong.
Marc.
From: "Frank Filz" <ffilz...@mindspring.com>
To: Marc Eshel/Almaden/IBM@IBMUS
Cc: <nfs-ganesha-devel@lists.sourceforge.net>
Date: 08/17/2016 10:04 PM
Subject: RE: multi fd support
> Hi Frank,
> Don't we need fsal_close() to call close2() ?
> We need the owner so we can release only the locks for this fd before
> closing it.
> Marc.
With support_ex enabled, fsal_close is only called when the
fsal_obj_handle
is being disposed of or when the LRU thread is closing open file
descriptors
(which will now only be those open file descriptors not associated with
state), and it's purpose is only to close the global/anonymous file
descriptor. There should be no locks associated with the global file
descriptor.
A few notes for you:
1. Not having a delegation aware FSAL to work on, I did not explore all
the
implications of delegations with support_ex. A delegation probably should
inherit the file descriptor from the initial open state, but maybe it
needs
it's own.
2. For NFS v4 locks, the support_ex API SHOULD allow you to just have an
open file descriptor associated with the open state and not have to have
one
per lock state (per lock owner) since your locks already have owners
associated without having to have separate file descriptors. For NFS v3
locks of course there is no way (currently) to tie to an open state (even
if
there is an NLM_SHARE from the same process). I would like to eventually
look for ties and create them if possible. Of course if it benefits you to
have an open fd per lock owner, that's fine too. And actually, you can
even
fall back to using the global file descriptor (and note that now the FSAL
actually gets to control when that's opened or closed).
3. I'm not sure you caught that you need to protect the global file
descriptor with the fsal_obj_handle->lock since the content_lock is no
more...
I'm on vacation the rest of the week so I may not be able to respond until
next week.
Frank
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
------------------------------------------------------------------------------
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
