[NFS-Ganesha-Devel] Re: For NLM UNLOCK - connection to rpc.statd not getting closed

Hi Daniel, Thank you for the patch. Wondering if you got a chance to see the last mail? If the code change in the shared link don't look appropriate please suggest another fix for this issue. Thank you. Thanks, Madhu Thorat IBM-India Software Labs, Pune. Inactive hide details for "Madhu P Punjabi" ---04/24/2019 12:42:35 AM---Hi Daniel,"Madhu P Punjabi" ---04/24/2019 12:42:35 AM---Hi Daniel, From: "Madhu P Punjabi" <madhu.punjabi(a)in.ibm.com&gt; To: dang(a)redhat.com Cc: devel(a)lists.nfs-ganesha.org Date: 04/24/2019 12:42 AM Subject: [NFS-Ganesha-Devel] Re: For NLM UNLOCK - connection to rpc.statd not getting closed ------------------------------------------------------------------------ Hi Daniel, Thank you for the patch. I tried using it but the connection to rpc.statd remains open. Do you intend to use the flag 'CLNT_FLAG_LOCAL' something like in the following link ? On using it like this the connection gets closed in clnt_vc_destroy(). Please check the changes. Thank you. _https://paste.fedoraproject.org/paste/YNfYhK5xJxjp2SS8StWKvg_ Thanks, Madhu Thorat. ----- Original message ----- From: Daniel Gryniewicz <dang(a)redhat.com&gt; To: devel(a)lists.nfs-ganesha.org Cc: Subject: [NFS-Ganesha-Devel] Re: For NLM UNLOCK - connection to rpc.statd not getting closed Date: Tue, Apr 23, 2019 8:21 PM Can you try with this patch applied to ntirpc? Daniel On 4/22/19 4:42 AM, Madhu Thorat wrote: > Hi, > > Not sure if my previous mail was sent, hence re-sending the mail. > > 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 Pune. > > _______________________________________________ > Devel mailing list -- devel(a)lists.nfs-ganesha.org > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org > _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org