Hi Daniel,
 
Thank you. This patch works for me too, have reviewed the patch.

Thanks,
Madhu Thorat
IBM-India Software Labs, Pune.
 
 
----- Original message -----
From: Daniel Gryniewicz <dang@redhat.com>
To: Madhu P Punjabi <madhu.punjabi@in.ibm.com>
Cc: devel@lists.nfs-ganesha.org
Subject: Re: [NFS-Ganesha-Devel] Re: For NLM UNLOCK - connection to rpc.statd not getting closed
Date: Tue, Apr 30, 2019 10:35 PM
 
This fixes it for me.  Can you test and review?

https://github.com/nfs-ganesha/ntirpc/pull/173

Daniel

On 4/29/19 7:11 AM, Madhu P Punjabi wrote:
> 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@in.ibm.com>
> To: dang@redhat.com
> Cc: devel@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://urldefense.proofpoint.com/v2/url?u=https-3A__paste.fedoraproject.org_paste_YNfYhK5xJxjp2SS8StWKvg-5F&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=Ch_5f06F5GEar9uQ84DlHKBgkld0mDICs-Bv0rPh-z4&m=QO-9Go1ZbX0rum1lCQYhDplXppl3LRzU1RCBbuIzgJM&s=Ce_JTv_nJshZG-rC5TYQ_1bTDQ98SawWiuulywNjRg0&e=
>
> Thanks,
> Madhu Thorat.
>
>
> ----- Original message -----
> From: Daniel Gryniewicz <dang@redhat.com>
> To: devel@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@lists.nfs-ganesha.org
>  > To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
>  >
>
>
> _______________________________________________
> Devel mailing list -- devel@lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
>
> _______________________________________________
> Devel mailing list -- devel@lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
>
>
>