[S] Change in ...nfs-ganesha[next]: Validate CLAIM_DELEGATE* stateids in open4_claim_deleg()
by Suhas Athani (GerritHub)
Suhas Athani has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226434?usp=email )
Change subject: Validate CLAIM_DELEGATE* stateids in open4_claim_deleg()
......................................................................
Validate CLAIM_DELEGATE* stateids in open4_claim_deleg()
- Replace the old “FIXME: vet stateid here” path with a call
to nfs4_Check_Stateid, using STATEID_NO_SPECIAL.
- Reject claims whose stateid is missing or not a delegation
(STATE_TYPE_DELEG) and add a debug log for that case.
- Preserve the full‑debug logging of the matching delegation
and make sure we drop the state reference unconditionally.
This ensures CLAIM_DELEGATE_CUR/CLAIM_DELEG_CUR_FH opens only
succeed when the client presents a live delegation stateid tied
to the correct file, preventing stale or unrelated stateids from
being accepted.
Change-Id: I1f4dc7ddab74a99dedc6dee86c120c1e27af5a73
Signed-off-by: Suhas Athani <Suhas.Athani(a)ibm.com>
---
M src/Protocols/NFS/nfs4_op_open.c
1 file changed, 25 insertions(+), 17 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/34/1226434/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226434?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: I1f4dc7ddab74a99dedc6dee86c120c1e27af5a73
Gerrit-Change-Number: 1226434
Gerrit-PatchSet: 1
Gerrit-Owner: Suhas Athani <Suhas.Athani(a)ibm.com>
1 week
[M] Change in ...nfs-ganesha[next]: Monitoring: Add duplicated metrics with "nfs_" prefix alongside exist...
by Name of user not set (GerritHub)
sragraha(a)redhat.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226403?usp=email )
Change subject: Monitoring: Add duplicated metrics with "nfs_" prefix alongside existing ones for one release
......................................................................
Monitoring: Add duplicated metrics with "nfs_" prefix alongside existing ones for one release
This change introduces duplicated metrics that are identical to existing ones
but prefixed with "nfs_". This approach allows users to familiarize themselves
with the new metric naming convention without removing the original metrics.
The duplication is intended as a temporary measure for the current release.
In a future release, the "nfs_" prefixing will be applied directly at metric
registration, and the duplicated metrics will be removed.
Change-Id: I92954188fc7bd96c21c9116579f20a51883f72b6
Signed-off-by: Sreedhar Agraharam <sragraha(a)redhat.com>
---
M src/monitoring/prometheus_exposer.cc
1 file changed, 49 insertions(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/03/1226403/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226403?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: I92954188fc7bd96c21c9116579f20a51883f72b6
Gerrit-Change-Number: 1226403
Gerrit-PatchSet: 1
Gerrit-Owner: sragraha(a)redhat.com
1 week, 1 day
[S] Change in ...nfs-ganesha[next]: Fix race condition in clientid expiration during compound operations
by Nikhil Adhau (GerritHub)
Nikhil Adhau has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226374?usp=email )
Change subject: Fix race condition in clientid expiration during compound operations
......................................................................
Fix race condition in clientid expiration during compound operations
Add reference counting for data->preserved_clientid to prevent the
clientid structure from being freed while still in use during NFSv4
compound operations.
The crash occurred when a clientid expired while a compound
operation was still using it, causing update_lease_simple() to
acquire a mutex on a freed clientid structure.
Change-Id: I85a17cfe87bc3bd8dc325191da085a17fc18389c
Signed-off-by: Nikhil Adhau <nikhiladhau999(a)gmail.com>
---
M src/Protocols/NFS/nfs4_Compound.c
M src/Protocols/NFS/nfs4_op_bind_conn.c
M src/Protocols/NFS/nfs4_op_sequence.c
M src/SAL/nfs4_state_id.c
4 files changed, 26 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/74/1226374/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1226374?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: I85a17cfe87bc3bd8dc325191da085a17fc18389c
Gerrit-Change-Number: 1226374
Gerrit-PatchSet: 1
Gerrit-Owner: Nikhil Adhau <nikhiladhau999(a)gmail.com>
1 week, 1 day
Announce Push of V9.1
by Frank Filz
Branch next
Tag:V9.1
Other Merge Highlights
* nfs3/reopen: Retry open if failed with EPERM
* Modify Enable_UDP config option to take NLM option
* Fix IP address comparison for client manager
* Modify cmp_sockaddr() to use nearly identical sockaddr_cmpf()
* Add cid_confirmed_saved to nfs_client_id_t
* SAL: Allow IP based recovery from RecovDir
* Logging: Use consistent logging components in recovery_fs.c
* FSAL_GLUSTER: Fix crash on rm with GlusterFS 6.0 and NFSv3
* Use PTHREAD_MUTEX macros for mutex operations
* Fix data race in TCP DRC recycle queue length (CID 583557).
* Remove redundant null check for session->clientid_record
* Fix rpm build error for GPFS FSAL
* Fix crash in NFS3 read when read_count is zero
* Fix Coverity issues: CID 583547, 542655, 509140
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
5a8357fca Frank S. Filz V9.1
8488f6908 VidyaThumukunta Fix Coverity issues: CID 583547, 542655, 509140
6c1515687 xueqian.hu Fix crash in NFS3 read when read_count is zero
69ba2c3dc Sachin Punadikar Fix rpm build error for GPFS FSAL
9e902ded5 Suhas Athani Remove redundant null check for
session->clientid_record
09c3e4387 Suhas Athani Fix data race in TCP DRC recycle queue length (CID
583557).
c88a3c4b5 Suhas Athani Use PTHREAD_MUTEX macros for mutex operations
84ee40fbc Dillon Peng FSAL_GLUSTER: Fix crash on rm with GlusterFS 6.0 and
NFSv3
335d93c79 Peter Schwenke Logging: Use consistent logging components in
recovery_fs.c
b05ac8795 Peter Schwenke SAL: Allow IP based recovery from RecovDir
ea85a5481 Peter Schwenke Add cid_confirmed_saved to nfs_client_id_t
c014341e9 Peter Schwenke Modify cmp_sockaddr() to use nearly identical
sockaddr_cmpf()
ba2844c5f Peter Schwenke Fix IP address comparison for client manager
003c018ea Peter Schwenke Modify Enable_UDP config option to take NLM option
a2558144d Mohammed Rafi KC nfs3/reopen: Retry open if failed with EPERM
2 weeks
Re: Clarification on delegation behavior for same-client conflicting OPEN
by Jeff Layton
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>
2 weeks, 2 days
subscribe
by Dipankar Roy
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.
2 weeks, 2 days
