November 2025 - Devel - NFS Ganesha List Archives

[XS] Change in ...nfs-ganesha[next]: clang-forgat client_mgr.c
by Frank Filz (GerritHub) 07 Nov '25

07 Nov '25

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226025?usp=email ) Change subject: clang-forgat client_mgr.c ...................................................................... clang-forgat client_mgr.c Change-Id: Iabe857e15b3eca5f2fe6781f1e75967d0c04b837 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/support/client_mgr.c 1 file changed, 2 insertions(+), 2 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/25/1226025/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226025?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Iabe857e15b3eca5f2fe6781f1e75967d0c04b837 Gerrit-Change-Number: 1226025 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>

1 0

[XS] Change in ...nfs-ganesha[next]: V9.1
by Frank Filz (GerritHub) 07 Nov '25

07 Nov '25

Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226024?usp=email ) Change subject: V9.1 ...................................................................... V9.1 Change-Id: I532586faa4d69973498232c674925e09ff59e3f7 Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> --- M src/CMakeLists.txt 1 file changed, 1 insertion(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/24/1226024/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226024?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I532586faa4d69973498232c674925e09ff59e3f7 Gerrit-Change-Number: 1226024 Gerrit-PatchSet: 1 Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>

1 0

Re: Clarification on delegation behavior for same-client conflicting OPEN
by Jeff Layton 05 Nov '25

05 Nov '25

On Thu, 2025-10-30 at 17:35 +0000, Suhas Athani via Devel wrote: > > Hello NFS community, > > We’re seeking clarification on server behavior for OPEN delegations when the same client issues a potentially conflicting OPEN on a file for which it already holds a delegation. > > Context and RFC references > > * > RFC 8881(10.4 Open Delegation) > - > “There must be no current OPEN conflicting with the requested delegation.” > - > “There should be no current delegation that conflicts with the delegation being requested.” > > * > RFC 8881(10.4.1 Open Delegation and Data Caching) > - > For delegation handling, READs/WRITEs without OPEN are treated as the functional equivalents of a corresponding type of OPEN, and the server “can use the client ID associated with the current session to determine if the operation has been done by the holder of the delegation (in which case, no recall is necessary) or by another client (in which case, the delegation must be recalled and I/O not proceed until the delegation is returned or revoked).” > > * > Historical reference: RFC 5661 (obsoleted by RFC 8881) carries the same sections 10.4 and 10.4.1 > Questions > 1) Same-client conflicting OPEN: > > * > If a client holds an OPEN_DELEGATE_READ on a file and then the same client issues an OPEN that requires write access (or otherwise conflicts), should the server: > * > > > > > - > Allow the OPEN to complete immediately without recalling the delegation (i.e., no recall necessary for same-client), per RFC 8881 10.4.1; or > > * > Recall the delegation anyway and delay the operation until DELEGRETURN? The Linux NFS server allows the open to complete, which I think has been the consensus around this point in earlier discussions. Basically, activity from the holder of a delegation is not considered "conflicting". That client presumably knows about any changes and can update its cache accordingly, so we don't need to recall the delegation in this case. > 2) OPEN_DELEGATE_WRITE symmetry: > > * > If a client holds an OPEN_DELEGATE_WRITE and then the same client issues an OPEN that requires read access (or otherwise changes share access/deny modes), should the server similarly allow the operation to proceed without recall, or recall and delay? WRITE delegations should probably have been called READ_WRITE. The Linux NFS server and the spec treat them as a superset of a READ delegation. So, opening the file for READ when you hold a WRITE deleg is not considered conflicting activity. > 3) Any updates since RFC 5661: > > * > Are there clarifications or consensus updates in RFC 8881 (vs. RFC 5661) or later documents that alter expected behavior in the same-client case? > > > Thank you in advance for your time and insights. Looking forward to your guidance and clarification on these points. > > Regards, > Suhas Athani > NFS-ganesha Team > > > > > _______________________________________________ > Devel mailing list -- devel(a)lists.nfs-ganesha.org > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org -- Jeff Layton <jlayton(a)poochiereds.net>

3 2

subscribe
by Dipankar Roy 05 Nov '25

05 Nov '25

This e-mail message and all attachments transmitted with it may contain privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message, all attachments and all copies and backups thereof.

1 0

[M] Change in ...nfs-ganesha[next]: Update delegation conflict detection logic in state_deleg_conflict_im...
by Suhas Athani (GerritHub) 05 Nov '25

05 Nov '25

Suhas Athani has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225729?usp=email ) Change subject: Update delegation conflict detection logic in state_deleg_conflict_impl() ...................................................................... Update delegation conflict detection logic in state_deleg_conflict_impl() The implementation distinguishes between same-client and cross-client operations by comparing client IDs. - Same-client operations: Return false (no conflict, no recall needed). - Cross-client operations: Return true (conflict detected, trigger recall via `async_delegrecall()`). Skip calling fsal_reopen2() if the request is from the same client that is holding the delegation to avoid recall from cephfs. Change-Id: Iac6b28944c691d4c22227b88969f9371db5fcab3 Signed-off-by: Suhas Athani <Suhas.Athani(a)ibm.com> --- M src/Protocols/NFS/nfs4_op_open.c M src/SAL/state_deleg.c 2 files changed, 104 insertions(+), 20 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/29/1225729/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225729?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Iac6b28944c691d4c22227b88969f9371db5fcab3 Gerrit-Change-Number: 1225729 Gerrit-PatchSet: 1 Gerrit-Owner: Suhas Athani <Suhas.Athani(a)ibm.com>

1 0

[S] Change in ...nfs-ganesha[next]: Logging: Use consistent logging components in recovery_fs.c
by Peter Schwenke (GerritHub) 04 Nov '25

04 Nov '25

Peter Schwenke has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225715?usp=email ) Change subject: Logging: Use consistent logging components in recovery_fs.c ...................................................................... Logging: Use consistent logging components in recovery_fs.c Consistently use COMPONENT_CLIENTID for logging. Change-Id: I6481628a1400435ed7efa72ae83e3deb08f8e794 Signed-off-by: Peter Schwenke <pschwenke(a)ddn.com> --- M src/SAL/recovery/recovery_fs.c 1 file changed, 7 insertions(+), 7 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/15/1225715/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225715?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I6481628a1400435ed7efa72ae83e3deb08f8e794 Gerrit-Change-Number: 1225715 Gerrit-PatchSet: 1 Gerrit-Owner: Peter Schwenke <pschwenke(a)ddn.com>

1 0

[XS] Change in ...nfs-ganesha[next]: Fix null pointer dereference in SEQUENCE op
by Suhas Athani (GerritHub) 04 Nov '25

04 Nov '25

Suhas Athani has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225683?usp=email ) Change subject: Fix null pointer dereference in SEQUENCE op ...................................................................... Fix null pointer dereference in SEQUENCE op Add null check for session->clientid_record before calling nfs_rpc_get_chan() to prevent NULL pointer dereference. - nfs_rpc_get_chan(session->clientid_record, 0) is called without checking if session->clientid_record is NULL. - nfs_rpc_get_chan() immediately dereferences the clientid parameter (accesses clientid->cid_minorversion), causing a NULL pointer dereference if session->clientid_record is NULL. - Line 315 later checks for NULL, but this is too late. Change-Id: I48c7e052acfe7845ae25e96928b81d12b8a9af0b Signed-off-by: Suhas Athani <Suhas.Athani(a)ibm.com> --- M src/Protocols/NFS/nfs4_op_sequence.c 1 file changed, 3 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/83/1225683/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225683?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I48c7e052acfe7845ae25e96928b81d12b8a9af0b Gerrit-Change-Number: 1225683 Gerrit-PatchSet: 1 Gerrit-Owner: Suhas Athani <Suhas.Athani(a)ibm.com>

1 0

[S] Change in ...nfs-ganesha[next]: Use PTHREAD_MUTEX macros for mutex operations
by Suhas Athani (GerritHub) 04 Nov '25

04 Nov '25

Suhas Athani has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225681?usp=email ) Change subject: Use PTHREAD_MUTEX macros for mutex operations ...................................................................... Use PTHREAD_MUTEX macros for mutex operations Replace pthread_mutex_lock()/pthread_mutex_unlock() with PTHREAD_MUTEX_lock()/PTHREAD_MUTEX_unlock() macros to check return values and match the codebase pattern. Affected functions: - is_stateid_revoked() - mark_sessions_have_revoked_delegations() - add_to_revoked_delegations() - remove_revoked_stateid() The macros automatically check return values and abort on errors, resolving Coverities - 638313, 638311, 638309, 638308, 638306, 638305, 638300, and 638297. Change-Id: I875b2c42ab06add9e6b929773cecfa180e250f47 Signed-off-by: Suhas Athani <Suhas.Athani(a)ibm.com> --- M src/SAL/state_deleg.c 1 file changed, 8 insertions(+), 8 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/81/1225681/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225681?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I875b2c42ab06add9e6b929773cecfa180e250f47 Gerrit-Change-Number: 1225681 Gerrit-PatchSet: 1 Gerrit-Owner: Suhas Athani <Suhas.Athani(a)ibm.com>

1 0

[L] Change in ...nfs-ganesha[next]: SAL: Allow IP based recovery from RecovDir
by Peter Schwenke (GerritHub) 04 Nov '25

04 Nov '25

Peter Schwenke has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225678?usp=email ) Change subject: SAL: Allow IP based recovery from RecovDir ...................................................................... SAL: Allow IP based recovery from RecovDir Currently, for clustered systems the CLIDs are created in RecoveryRoot/RecovDir/nodeX/xxxxx The CLIDs for recovery are read from RecoveryRoot/aa.bb.cc.dd where aa,bb,cc,dd is an IP address. This requires the node management software to copy and delete the CLIDs. The approach here allows the CLIDs to exists in RecoveryRoot/RecovDir/ip_IP_ADDRESS_STRING where IP_ADDRESS_STRING is an address the Ganesha instance is listening on. The format is either IPv6 or IPv4. The CLIDs are created in that directory and takeover events will read from that directory. Change-Id: Iac47a84e5c6559d37b9005e8b208bf5f4874dbbc Signed-off-by: Peter Schwenke <pschwenke(a)ddn.com> --- M src/SAL/nfs4_recovery.c M src/SAL/recovery/recovery_fs.c 2 files changed, 276 insertions(+), 35 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/78/1225678/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225678?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Iac47a84e5c6559d37b9005e8b208bf5f4874dbbc Gerrit-Change-Number: 1225678 Gerrit-PatchSet: 1 Gerrit-Owner: Peter Schwenke <pschwenke(a)ddn.com>

1 0

[XS] Change in ...nfs-ganesha[next]: Add cid_confirmed_saved to nfs_client_id_t
by Peter Schwenke (GerritHub) 04 Nov '25

04 Nov '25

Peter Schwenke has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225677?usp=email ) Change subject: Add cid_confirmed_saved to nfs_client_id_t ...................................................................... Add cid_confirmed_saved to nfs_client_id_t This is in preparation for the Virtual IP Based recovery. This required to be able to cleanup NFSv4.0 CLIDs on umount for the IP based in-situ reclaim. The indicator for being able to cleanup the CLID in fs_rm_clid() is that the client ID is in the confirmed state. We only want the CLID to be removed when the file system is no longer used by any of the nodes i.e. unmounted. Change-Id: I7ab4a74cacaf4fb2b5054352f69c7d5de3a1daee Signed-off-by: Peter Schwenke <pschwenke(a)ddn.com> --- M src/SAL/nfs4_clientid.c M src/include/sal_data.h 2 files changed, 4 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/77/1225677/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1225677?usp=email To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings?usp=email Gerrit-MessageType: newchange Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I7ab4a74cacaf4fb2b5054352f69c7d5de3a1daee Gerrit-Change-Number: 1225677 Gerrit-PatchSet: 1 Gerrit-Owner: Peter Schwenke <pschwenke(a)ddn.com>

1 0