If recv() returns EAGAIN, then svc_vc_recv() returns without rearming the
epoll_fd. How does it get back to svc_vc_recv() again?
On Wed, Jan 24, 2018 at 9:26 PM, Pradeep <pradeeptho...@gmail.com> wrote:
> Hello,
>
> I seem to be hitting a corner case where ganesha (2.6-rc2) does not
> respond to a RENEW request from 4.0 client. Enabled the debug logs and
> noticed that NFS layer has not seen the RENEW request (I can see it in
> tcpdump).
>
> I collected netstat output periodically and found that there is a time
> window of ~60 sec where the receive buffer size remains the same. This
> means the RPC layer somehow missed a 'recv' call. Now if I enable debug on
> TIRPC, I can't reproduce the issue. Any pointers to potential races where I
> could enable selective prints would be helpful.
>
> svc_rqst_epoll_event() resets SVC_XPRT_FLAG_ADDED. Is it possible for
> another thread to svc_rqst_rearm_events()? In that case if
> svc_rqst_epoll_event() could reset the flag set by svc_rqst_rearm_events
> and complete the current receive before the other thread could call
> epoll_ctl(), right?
>
> Thanks,
> Pradeep
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Nfs-ganesha-devel mailing list
Nfs-ganesha-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
