April 2019 - Devel - Nfs Ganesha List Archives

For NLM UNLOCK - connection to rpc.statd not getting closed

by Madhu P Punjabi

Hi, I used the latest ganesha code and ran the following test from a NFSv3 client in a script: ct=0 while [ $ct -lt 4096 ]; do flock -x mylock echo 1 >> myfile let ct=$ct+1 done After running for 1000+ times the client got error "No locks available" ganesha.log had the following trace: ganesha.nfsd-9328[svc_103] nsm_connect :NLM :CRIT :connect to statd failed: RPC: Unknown protocol /var/log/messages showed "Too many open files" message. It looks like for NLM LOCK requests connection to rpc.statd were created but not closed for NLM UNLOCK request. After analyzing the code, it seems this happens because for NLM LOCK request the 'xprt->xp_refcnt' is ref'ed twice. But while handling NLM UNLOCK request the 'xprt->xp_refcnt' is un-ref'ed only once, and thus svc_vc_destroy_it() doesn't get called and connection to rpc.statd is not closed. More details about the code analysis is below. Can you please check about this issue ? Thank you. I am not sure why are we incrementing 'xprt-> xp_refcnt' twice in svc_xprt_lookup() ? For NLM LOCK request the code path is: -------------------------------------------------------------- nlm4_Lock() -> ...... -> nsm_connect() -> ....... -> makefd_xprt() -> svc_xprt_lookup() 137 SVCXPRT * 138 svc_xprt_lookup(int fd, svc_xprt_setup_t setup) 139 { ...... ...... 173 (*setup)(&xprt); /* zalloc, xp_refcnt = 1 */ --> leads to call to svc_vc_xprt_setup() 174 xprt->xp_fd = fd; 175 xprt->xp_flags = SVC_XPRT_FLAG_INITIAL; 176 177 /* Get ref for caller */ 178 SVC_REF(xprt, SVC_REF_FLAG_NONE); Here, at line 173 function svc_vc_xprt_setup() is called which sets 'xprt-> xp_refcnt = 1' Then at line 178, SVC_REF increments 'xprt->xp_refcnt' by 1. Thus, when handling NLM LOCK request 'xprt->xp_refcnt = 2' is set. For NLM UNLOCK request the code path is: ------------------------------------------------------------------- nlm4_Unlock() -> ...... -> nsm_disconnect -> ..... -> clnt_vc_destroy() -> svc_release_it() 410 static inline void svc_release_it(SVCXPRT *xprt, u_int flags, 411 const char *tag, const int line) 412 { 413 int32_t refs = atomic_dec_int32_t(&xprt->xp_refcnt); ...... ...... 425 if (likely(refs > 0)) { 426 /* normal case */ 427 return; 428 } 429 430 /* enforce once-only semantic, trace others */ 431 xp_flags = atomic_postset_uint16_t_bits(&xprt->xp_flags, 432 SVC_XPRT_FLAG_RELEASING); ...... 439 /* Releasing last reference */ 440 (*(xprt)->xp_ops->xp_destroy)(xprt, flags, tag, line); Here, at line 413 'xprt->xp_refcnt' gets decremented and becomes 'xprt-> xp_refcnt = 1'. But as 'xprt->xp_refcnt != 0' the function returns from line 427. And thus it doesn't proceed with closure of connection. Thanks, Madhu Thorat IBM-India Software Labs, Pune.

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: Fix NLM owner refcount leak in state_lock()

by Malahal (GerritHub)

Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451515 Change subject: Fix NLM owner refcount leak in state_lock() ...................................................................... Fix NLM owner refcount leak in state_lock() We copy conflict for blocking and non-blocking locks in state_lock(). We do send STATE_LOCK_CONFLICT for non-blocking calls where the caller releases the hold on the owner. We send STATE_LOCK_BLOCKED for blocked locks, so we need to release the hold in state_lock() itself. Change-Id: I7eb7c7a72d9f748f97573327ef6f17406a16b494 Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com> --- M src/SAL/state_lock.c 1 file changed, 8 insertions(+), 0 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/15/451515/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451515 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I7eb7c7a72d9f748f97573327ef6f17406a16b494 Gerrit-Change-Number: 451515 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal <malahal(a)gmail.com> Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: Fix memory leak for RPCSEC_GSS

by Sachin Punadikar (GerritHub)

Sachin Punadikar has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451513 Change subject: Fix memory leak for RPCSEC_GSS ...................................................................... Fix memory leak for RPCSEC_GSS Release the gss buffers, after comparing the nfs creds. Change-Id: If06a05d8e74dc1c87ce4670e80e33923444e28d4 Signed-off-by: Sachin Punadikar <psachin(a)in.ibm.com> --- M src/support/nfs_creds.c 1 file changed, 7 insertions(+), 1 deletion(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/13/451513/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451513 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: If06a05d8e74dc1c87ce4670e80e33923444e28d4 Gerrit-Change-Number: 451513 Gerrit-PatchSet: 1 Gerrit-Owner: Sachin Punadikar <psachin(a)in.ibm.com> Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

Announce Push of V2.8-dev.26

by Frank Filz

Branch next Tag:V2.8-dev.26 Release Highlights * FSAL_CEPH: use a unique uuid string per export * Free NLM block data when not used Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: efba0d1 Frank S. Filz V2.8-dev.26 30d5c21 Malahal Naineni Free NLM block data when not used 40cf129 Jeff Layton FSAL_CEPH: use a unique uuid string per export

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: Add 'expire_time_parent' parameter and refill parent handle if expired

by Madhu Thorat (GerritHub)

Madhu Thorat has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451444 Change subject: Add 'expire_time_parent' parameter and refill parent handle if expired ...................................................................... Add 'expire_time_parent' parameter and refill parent handle if expired If the underlying file system doesn't give sufficient information in an upcall to notify about parent change for a DIRECTORY then the parent handle won't get updated for an entry. This may cause problem when parent handle is used. This change intends to help with this problem by providing a new parameter 'expire_time_parent' to let a FSAL set expiration time for parent handle. The default value is 'expire_time_parent=-1', which means ganesha won't expire parent handle. If a FSAL sets 'expire_time_parent' to any other value then whenever we try to get parent handle, we check if the current parent handle has expired by checking the current time with 'expire_time_parent'. In case it has expired then if required a lookup is made for the parent and the parent handle is updated. NOTE: Can we have the parameter 'expire_time_parent' in some other structure, other than fsal_staticfsinfo_t, like in 'struct mdcache_parameter' or have it as a macro. The intention to have new parameter 'expire_time_parent' in fsal_staticfsinfo_t was to let FSAL decide if it wants the parent handle to expire in case it cannot rely on the file system to give an upcall about parent change for a DIRECTORY. Didn't keep it in 'struct mdcache_parameter' or have it as a macro as in that case parent handle would be updated even when a file system is reliably sending upcall for parent update. Change-Id: I76a022139c08052817f1f29ddcf77ce4d7d51b3f Signed-off-by: Madhu Thorat <madhu.punjabi(a)in.ibm.com> --- M src/FSAL/FSAL_CEPH/main.c M src/FSAL/FSAL_GLUSTER/main.c M src/FSAL/FSAL_GPFS/main.c M src/FSAL/FSAL_MEM/mem_main.c M src/FSAL/FSAL_PROXY/main.c M src/FSAL/FSAL_PSEUDO/main.c M src/FSAL/FSAL_RGW/main.c M src/FSAL/FSAL_VFS/panfs/main.c M src/FSAL/FSAL_VFS/vfs/main-c.in.cmake M src/FSAL/FSAL_VFS/xfs/main.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_export.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_int.h M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_main.c M src/FSAL/Stackable_FSALs/FSAL_NULL/export.c M src/FSAL/Stackable_FSALs/FSAL_NULL/main.c M src/FSAL/commonlib.c M src/FSAL/default_methods.c M src/FSAL/fsal_config.c M src/include/FSAL/fsal_config.h M src/include/fsal_api.h M src/include/fsal_types.h 22 files changed, 156 insertions(+), 13 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/44/451444/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451444 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I76a022139c08052817f1f29ddcf77ce4d7d51b3f Gerrit-Change-Number: 451444 Gerrit-PatchSet: 1 Gerrit-Owner: Madhu Thorat <madhu.punjabi(a)in.ibm.com> Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: MDCACHE - Force clean all chunks before reusing an MDCACHE entry.

by Name of user not set (GerritHub)

pradeepthomas(a)gmail.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451311 Change subject: MDCACHE - Force clean all chunks before reusing an MDCACHE entry. ...................................................................... MDCACHE - Force clean all chunks before reusing an MDCACHE entry. The background thread drops qlock and reacquire it when cleaning up chunks. This could probably race with reuse of parent entry and end up having stale parent pointer. So force clean chunks before parents can be reused. Signed-off-by: Pradeep <pradeepthomas(a)gmail.com> Change-Id: I76846aa6c5a626eb14ca1c3bafc6054bf08a3e42 --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_avl.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.h 4 files changed, 33 insertions(+), 20 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/11/451311/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451311 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I76846aa6c5a626eb14ca1c3bafc6054bf08a3e42 Gerrit-Change-Number: 451311 Gerrit-PatchSet: 1 Gerrit-Owner: pradeepthomas(a)gmail.com Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: [WIP] Free NLM block data when not used

by Malahal (GerritHub)

Malahal has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451270 Change subject: [WIP] Free NLM block data when not used ...................................................................... [WIP] Free NLM block data when not used We allocate NLM block data but don't use in many cases leading to memory leak. Change-Id: Idfc4bdf869c7603b2ec206b736724443c83372ea Signed-off-by: Malahal Naineni <malahal(a)us.ibm.com> --- M src/Protocols/NLM/nlm_Lock.c 1 file changed, 15 insertions(+), 6 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/70/451270/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451270 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: Idfc4bdf869c7603b2ec206b736724443c83372ea Gerrit-Change-Number: 451270 Gerrit-PatchSet: 1 Gerrit-Owner: Malahal <malahal(a)gmail.com> Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: FSAL_CEPH: use a unique uuid string per export

by Jeff Layton (GerritHub)

Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451201 Change subject: FSAL_CEPH: use a unique uuid string per export ...................................................................... FSAL_CEPH: use a unique uuid string per export If you set up two exports on the same cephfs, they will currently conflict with one another during reclaim. Fix this by using a unique UUID per export. Change-Id: I64e19061612f76f653541939699f701ad4601925 Reported-by: bbk <bbk(a)nocloud.ch> Signed-off-by: Jeff Layton <jlayton(a)redhat.com> --- M src/FSAL/FSAL_CEPH/main.c 1 file changed, 6 insertions(+), 4 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/01/451201/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/451201 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I64e19061612f76f653541939699f701ad4601925 Gerrit-Change-Number: 451201 Gerrit-PatchSet: 1 Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com> Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

Announce Push of V2.8-dev.25

by Frank Filz

Branch next Tag:V2.8-dev.25 Release Highlights * Return ERR_FSAL_SYMLINK when trying to OPEN a SYMLINK * [GPFS] Don't fail getattrs() if getting fs_locations fails * Modify strmaxcpy definition to be more graceful! * Convert strncpy calls to a safer strlcpy Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com> Contents: 1825ea3 Frank S. Filz V2.8-dev.25 63ca2ca Malahal Naineni Convert strncpy calls to a safer strlcpy 93cb479 Malahal Naineni Modify strmaxcpy definition to be more graceful! fbe910d Madhu Thorat [GPFS] Don't fail getattrs() if getting fs_locations fails 8b8ffa7 Madhu Thorat Return ERR_FSAL_SYMLINK when trying to OPEN a SYMLINK

5 years, 8 months

1
0
0 / 0

Change in ...nfs-ganesha[next]: MDCACHE - Hold qlock when cleaning up chunks.

by Name of user not set (GerritHub)

pradeepthomas(a)gmail.com has uploaded this change for review. ( https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/450825 Change subject: MDCACHE - Hold qlock when cleaning up chunks. ...................................................................... MDCACHE - Hold qlock when cleaning up chunks. The background thread drops qlock and reacquire it when cleaning up chunks. This could probably race with reuse of parent entry and end up having stale parent pointer. Signed-off-by: Pradeep <pradeepthomas(a)gmail.com> Change-Id: I9ebf01777d533962e121cd805fa87ffe39baa3be --- M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c 1 file changed, 14 insertions(+), 8 deletions(-) git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/25/450825/1 -- To view, visit https://review.gerrithub.io/c/ffilz/nfs-ganesha/+/450825 To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings Gerrit-Project: ffilz/nfs-ganesha Gerrit-Branch: next Gerrit-Change-Id: I9ebf01777d533962e121cd805fa87ffe39baa3be Gerrit-Change-Number: 450825 Gerrit-PatchSet: 1 Gerrit-Owner: pradeepthomas(a)gmail.com Gerrit-MessageType: newchange

5 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

Devel April 2019