[S] Change in ...nfs-ganesha[next]: Provide a def_fsal_ops entry for fsal_enable_delegations.
by Jason Woodward (GerritHub)
Jason Woodward has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1228841?usp=email )
Change subject: Provide a def_fsal_ops entry for fsal_enable_delegations.
......................................................................
Provide a def_fsal_ops entry for fsal_enable_delegations.
```
Thread 17 "ganesha.nfsd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xffffd3ffdf40 (LWP 8095)]
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x0000fffff7e417ac in fsal_update_cfg_commit (node=<optimized out>, link_mem=<optimized out>, self_struct=<optimized out>, err_type=0xfffff7f84c40 <err_type>) at /nfs-ganesha/src/support/exports.c:944
...
(gdb) p probe_exp->fsal_export->sub_export->fsal->m_ops
$6 = {..., fsal_enable_delegations = 0x0, ...}
```
Change-Id: I7177087ae3fa6f52b08954e25be09d270f0966bd
Signed-off-by: Jason Woodward <jawoodwa(a)microsoft.com>
---
M src/FSAL/default_methods.c
1 file changed, 13 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/41/1228841/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1228841?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: I7177087ae3fa6f52b08954e25be09d270f0966bd
Gerrit-Change-Number: 1228841
Gerrit-PatchSet: 1
Gerrit-Owner: Jason Woodward <jawoodwa(a)microsoft.com>
2 months
[S] Change in ...nfs-ganesha[next]: CONFIG : Fix possible corruption in LIST processing
by Sachin Punadikar (GerritHub)
Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1228768?usp=email )
Change subject: CONFIG : Fix possible corruption in LIST processing
......................................................................
CONFIG : Fix possible corruption in LIST processing
While parsing LIST and ENUM types, we are not clearing the existing
values with mask. This may lead to having corrupt values for Squash.
Corrected the code to have unconditional clearing.
Change-Id: Ic91906183ad7d3d8ddd4fc73c0bf640d776b78c6
Signed-off-by: Sachin Punadikar <sachin.punadikar(a)ibm.com>
---
M src/config_parsing/config_parsing.c
1 file changed, 4 insertions(+), 10 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/68/1228768/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1228768?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: Ic91906183ad7d3d8ddd4fc73c0bf640d776b78c6
Gerrit-Change-Number: 1228768
Gerrit-PatchSet: 1
Gerrit-Owner: Sachin Punadikar <sachin.punadikar(a)ibm.com>
2 months
[M] Change in ...nfs-ganesha[next]: FSAL_CEPH: Avoid OPEN_DOWNGRADE hang by fixing async deleg recall han...
by Suhas Athani (GerritHub)
Suhas Athani has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1228678?usp=email )
Change subject: FSAL_CEPH: Avoid OPEN_DOWNGRADE hang by fixing async deleg recall handling.
......................................................................
FSAL_CEPH: Avoid OPEN_DOWNGRADE hang by fixing async deleg
recall handling.
Fix a hang in NFS-Ganesha when using CephFS backend where
OPEN_DOWNGRADE hangs due to a deadlock in delegation recall
processing.
The fix involves ensuring ceph_ll_delegation is called to
acknowledge delegation recall, but doing so asynchronously
to avoid a recursive lock assertion failure in libcephfs.
Change-Id: I4fd814d7f0226cf2ced08a3a5d25c580ba6aa7b9
Signed-off-by: Suhas Athani <Suhas.Athani(a)ibm.com>
---
M src/FSAL/FSAL_CEPH/handle.c
M src/FSAL/FSAL_CEPH/internal.h
2 files changed, 83 insertions(+), 1 deletion(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/78/1228678/1
--
To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/1228678?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: I4fd814d7f0226cf2ced08a3a5d25c580ba6aa7b9
Gerrit-Change-Number: 1228678
Gerrit-PatchSet: 1
Gerrit-Owner: Suhas Athani <Suhas.Athani(a)ibm.com>
2 months
Re: Fwd: Memory-Leak in nfs-ganesha
by Kaleb Keithley
Yeah, my first thought was he was reporting a new bug, so I forwarded it.
Then I dug a little deeper.
He sent the mail to the ganesha maintainer's list in Fedora, but he's
actually using packages from the CentOS Storage SIG.
I suspect what he is really asking is for the patch to be added and respin
the build in the storage SIG.
On Mon, Jan 5, 2026 at 7:19 PM Peter Schwenke <pschwenke(a)ddn.com> wrote:
> Thanks for looking at that. This has already been fixed in commit
> f2a445eb34 in the "next" branch.
>
> You can apply that to your 5.9 branch.
>
> --
> Best Regards
> ...Peter Schwenke
> ------------------------------
> *From:* Kaleb Keithley via Devel <devel(a)lists.nfs-ganesha.org>
> *Sent:* Tuesday, 6 January 2026 05:27
> *To:* Ganesha-devel <devel(a)lists.nfs-ganesha.org>
> *Subject:* [NFS-Ganesha-Devel] Fwd: Memory-Leak in nfs-ganesha
>
>
>
> ---------- Forwarded message ---------
> From: *Lars Knipschild* <laknipschild(a)uni-osnabrueck.de>
> Date: Mon, Jan 5, 2026 at 10:34 AM
> Subject: Memory-Leak in nfs-ganesha
> To: <nfs-ganesha-maintainers(a)fedoraproject.org>
>
>
> Dear libntirpc-maintainers,
>
> thanks a lot for maintaining this package!
>
> We use CEPH+Ganesha (5.9-1 from CentOS Storage Sig)+HAProxy
> (Proxy-Protocol).
>
> With this setup we observed unusual growth of memory usage in ganesha.nfsd.
> We traced this issue back a memory leak in
> nfs4_op_getxattr (src/Protocols/NFS/nfs4_op_xattr.c, line 83):
>
> gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
>
> This block of 1025 bytes is only freed if the function succeeds. In our
> case (libceph) the function call
> obj_handle->obj_ops->getxattrs (line 98) returns an error ( -61
> (-ENODATA)) if there are no xattrs for the respective file.
>
> Some client activity (gocryptfs+rsync) caused lots of getxattrs-calls
> leading to ~40MB/min memory-growth.
>
>
> To solve the problem I prepared the following patch, that we tested
> during December:
>
> [lars@vmwnh SOURCES]$ cat ganesha_xattr_memleak.patch
> diff -Naru nfs-ganesha-5.9_orig/src/Protocols/NFS/nfs4_op_xattr.c
> nfs-ganesha-5.9/src/Protocols/NFS/nfs4_op_xattr.c
> --- nfs-ganesha-5.9_orig/src/Protocols/NFS/nfs4_op_xattr.c 2025-12-08
> 14:36:49.778825846 +0100
> +++ nfs-ganesha-5.9/src/Protocols/NFS/nfs4_op_xattr.c 2025-12-08
> 14:51:43.666539343 +0100
> @@ -79,9 +79,6 @@
> res_GETXATTR4->GETXATTR4res_u.resok4.gxr_value.utf8string_len = 0;
> res_GETXATTR4->GETXATTR4res_u.resok4.gxr_value.utf8string_val = NULL;
>
> - gxr_value.utf8string_len = XATTR_VALUE_SIZE;
> - gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
> -
> /* Do basic checks on a filehandle */
> res_GETXATTR4->status = nfs4_sanity_check_FH(data, NO_FILE_TYPE,
> false);
>
> @@ -95,16 +92,19 @@
> return NFS_REQ_ERROR;
> }
>
> + gxr_value.utf8string_len = XATTR_VALUE_SIZE;
> + gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
> +
> fsal_status = obj_handle->obj_ops->getxattrs(obj_handle,
> &arg_GETXATTR4->gxa_name,
> &gxr_value);
> if (FSAL_IS_ERROR(fsal_status)) {
> + gsh_free(gxr_value.utf8string_val);
> if (fsal_status.major == ERR_FSAL_XATTR2BIG) {
> LogDebug(COMPONENT_NFS_V4,
> "FSAL buffer len %d too small",
> XATTR_VALUE_SIZE);
> /* Get size of xattr value */
> - gsh_free(gxr_value.utf8string_val);
> gxr_value.utf8string_len = 0;
> gxr_value.utf8string_val = NULL;
> fsal_status = obj_handle->obj_ops->getxattrs(obj_handle,
> @@ -128,6 +128,7 @@
> &gxr_value);
>
> if (FSAL_IS_ERROR(fsal_status)) {
> + gsh_free(gxr_value.utf8string_val);
> res_GETXATTR4->status = nfs4_Errno_state(
> state_error_convert(fsal_status));
> return NFS_REQ_ERROR;
>
> This patch is quite similar to
>
> https://github.com/nfs-ganesha/nfs-ganesha/commit/c8c6b8d8c03ac746c7d7e96...
> .
>
> Have a nice day!
>
> Best
> Lars
>
>
> --
> Dr. Lars Knipschild | Universität Osnabrück - Rechenzentrum |
> High-Performance-Computing Koordinator | lars(a)uos.de | 0541 969 2316
>
>
>
> --
>
> Kaleb
>
--
Kaleb
2 months
Re: Fwd: Memory-Leak in nfs-ganesha
by Peter Schwenke
Sorry. Wrong hash tag. I grabbed the one from our cherry pick
c8c6b8d8c03ac746c7d7e96eb01e99a080f8153d
--
Best Regards
...Peter Schwenke
________________________________
From: Peter Schwenke via Devel <devel(a)lists.nfs-ganesha.org>
Sent: Tuesday, 6 January 2026 10:45
To: Ganesha-devel <devel(a)lists.nfs-ganesha.org>; Kaleb Keithley <kkeithle(a)redhat.com>
Subject: [NFS-Ganesha-Devel] Re: Fwd: Memory-Leak in nfs-ganesha
Thanks for looking at that. This has already been fixed in commit f2a445eb34 in the "next" branch.
You can apply that to your 5.9 branch.
--
Best Regards
...Peter Schwenke
________________________________
From: Kaleb Keithley via Devel <devel(a)lists.nfs-ganesha.org>
Sent: Tuesday, 6 January 2026 05:27
To: Ganesha-devel <devel(a)lists.nfs-ganesha.org>
Subject: [NFS-Ganesha-Devel] Fwd: Memory-Leak in nfs-ganesha
---------- Forwarded message ---------
From: Lars Knipschild <laknipschild(a)uni-osnabrueck.de<mailto:laknipschild@uni-osnabrueck.de>>
Date: Mon, Jan 5, 2026 at 10:34 AM
Subject: Memory-Leak in nfs-ganesha
To: <nfs-ganesha-maintainers(a)fedoraproject.org<mailto:nfs-ganesha-maintainers@fedoraproject.org>>
Dear libntirpc-maintainers,
thanks a lot for maintaining this package!
We use CEPH+Ganesha (5.9-1 from CentOS Storage Sig)+HAProxy
(Proxy-Protocol).
With this setup we observed unusual growth of memory usage in ganesha.nfsd.
We traced this issue back a memory leak in
nfs4_op_getxattr (src/Protocols/NFS/nfs4_op_xattr.c, line 83):
gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
This block of 1025 bytes is only freed if the function succeeds. In our
case (libceph) the function call
obj_handle->obj_ops->getxattrs (line 98) returns an error ( -61
(-ENODATA)) if there are no xattrs for the respective file.
Some client activity (gocryptfs+rsync) caused lots of getxattrs-calls
leading to ~40MB/min memory-growth.
To solve the problem I prepared the following patch, that we tested
during December:
[lars@vmwnh SOURCES]$ cat ganesha_xattr_memleak.patch
diff -Naru nfs-ganesha-5.9_orig/src/Protocols/NFS/nfs4_op_xattr.c
nfs-ganesha-5.9/src/Protocols/NFS/nfs4_op_xattr.c
--- nfs-ganesha-5.9_orig/src/Protocols/NFS/nfs4_op_xattr.c 2025-12-08
14:36:49.778825846 +0100
+++ nfs-ganesha-5.9/src/Protocols/NFS/nfs4_op_xattr.c 2025-12-08
14:51:43.666539343 +0100
@@ -79,9 +79,6 @@
res_GETXATTR4->GETXATTR4res_u.resok4.gxr_value.utf8string_len = 0;
res_GETXATTR4->GETXATTR4res_u.resok4.gxr_value.utf8string_val = NULL;
- gxr_value.utf8string_len = XATTR_VALUE_SIZE;
- gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
-
/* Do basic checks on a filehandle */
res_GETXATTR4->status = nfs4_sanity_check_FH(data, NO_FILE_TYPE,
false);
@@ -95,16 +92,19 @@
return NFS_REQ_ERROR;
}
+ gxr_value.utf8string_len = XATTR_VALUE_SIZE;
+ gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
+
fsal_status = obj_handle->obj_ops->getxattrs(obj_handle,
&arg_GETXATTR4->gxa_name,
&gxr_value);
if (FSAL_IS_ERROR(fsal_status)) {
+ gsh_free(gxr_value.utf8string_val);
if (fsal_status.major == ERR_FSAL_XATTR2BIG) {
LogDebug(COMPONENT_NFS_V4,
"FSAL buffer len %d too small",
XATTR_VALUE_SIZE);
/* Get size of xattr value */
- gsh_free(gxr_value.utf8string_val);
gxr_value.utf8string_len = 0;
gxr_value.utf8string_val = NULL;
fsal_status = obj_handle->obj_ops->getxattrs(obj_handle,
@@ -128,6 +128,7 @@
&gxr_value);
if (FSAL_IS_ERROR(fsal_status)) {
+ gsh_free(gxr_value.utf8string_val);
res_GETXATTR4->status = nfs4_Errno_state(
state_error_convert(fsal_status));
return NFS_REQ_ERROR;
This patch is quite similar to
https://github.com/nfs-ganesha/nfs-ganesha/commit/c8c6b8d8c03ac746c7d7e96....
Have a nice day!
Best
Lars
--
Dr. Lars Knipschild | Universität Osnabrück - Rechenzentrum |
High-Performance-Computing Koordinator | lars(a)uos.de<mailto:lars@uos.de> | 0541 969 2316
--
Kaleb
2 months
Fwd: Memory-Leak in nfs-ganesha
by Kaleb Keithley
---------- Forwarded message ---------
From: Lars Knipschild <laknipschild(a)uni-osnabrueck.de>
Date: Mon, Jan 5, 2026 at 10:34 AM
Subject: Memory-Leak in nfs-ganesha
To: <nfs-ganesha-maintainers(a)fedoraproject.org>
Dear libntirpc-maintainers,
thanks a lot for maintaining this package!
We use CEPH+Ganesha (5.9-1 from CentOS Storage Sig)+HAProxy
(Proxy-Protocol).
With this setup we observed unusual growth of memory usage in ganesha.nfsd.
We traced this issue back a memory leak in
nfs4_op_getxattr (src/Protocols/NFS/nfs4_op_xattr.c, line 83):
gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
This block of 1025 bytes is only freed if the function succeeds. In our
case (libceph) the function call
obj_handle->obj_ops->getxattrs (line 98) returns an error ( -61
(-ENODATA)) if there are no xattrs for the respective file.
Some client activity (gocryptfs+rsync) caused lots of getxattrs-calls
leading to ~40MB/min memory-growth.
To solve the problem I prepared the following patch, that we tested
during December:
[lars@vmwnh SOURCES]$ cat ganesha_xattr_memleak.patch
diff -Naru nfs-ganesha-5.9_orig/src/Protocols/NFS/nfs4_op_xattr.c
nfs-ganesha-5.9/src/Protocols/NFS/nfs4_op_xattr.c
--- nfs-ganesha-5.9_orig/src/Protocols/NFS/nfs4_op_xattr.c 2025-12-08
14:36:49.778825846 +0100
+++ nfs-ganesha-5.9/src/Protocols/NFS/nfs4_op_xattr.c 2025-12-08
14:51:43.666539343 +0100
@@ -79,9 +79,6 @@
res_GETXATTR4->GETXATTR4res_u.resok4.gxr_value.utf8string_len = 0;
res_GETXATTR4->GETXATTR4res_u.resok4.gxr_value.utf8string_val = NULL;
- gxr_value.utf8string_len = XATTR_VALUE_SIZE;
- gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
-
/* Do basic checks on a filehandle */
res_GETXATTR4->status = nfs4_sanity_check_FH(data, NO_FILE_TYPE,
false);
@@ -95,16 +92,19 @@
return NFS_REQ_ERROR;
}
+ gxr_value.utf8string_len = XATTR_VALUE_SIZE;
+ gxr_value.utf8string_val = gsh_malloc(gxr_value.utf8string_len + 1);
+
fsal_status = obj_handle->obj_ops->getxattrs(obj_handle,
&arg_GETXATTR4->gxa_name,
&gxr_value);
if (FSAL_IS_ERROR(fsal_status)) {
+ gsh_free(gxr_value.utf8string_val);
if (fsal_status.major == ERR_FSAL_XATTR2BIG) {
LogDebug(COMPONENT_NFS_V4,
"FSAL buffer len %d too small",
XATTR_VALUE_SIZE);
/* Get size of xattr value */
- gsh_free(gxr_value.utf8string_val);
gxr_value.utf8string_len = 0;
gxr_value.utf8string_val = NULL;
fsal_status = obj_handle->obj_ops->getxattrs(obj_handle,
@@ -128,6 +128,7 @@
&gxr_value);
if (FSAL_IS_ERROR(fsal_status)) {
+ gsh_free(gxr_value.utf8string_val);
res_GETXATTR4->status = nfs4_Errno_state(
state_error_convert(fsal_status));
return NFS_REQ_ERROR;
This patch is quite similar to
https://github.com/nfs-ganesha/nfs-ganesha/commit/c8c6b8d8c03ac746c7d7e96...
.
Have a nice day!
Best
Lars
--
Dr. Lars Knipschild | Universität Osnabrück - Rechenzentrum |
High-Performance-Computing Koordinator | lars(a)uos.de | 0541 969 2316
--
Kaleb
2 months