Thank you Bill. Hope we can get it back ported to V2.5 as well.
Regards, Malahal.
On Fri, Sep 1, 2017 at 4:15 PM, William Allen Simpson <
william.allen.simp...@gmail.com> wrote:
> On 8/31/17 5:42 PM, William Allen Simpson wrote:
>
>> On 8/31/17 12:17 PM, Pradeep wrote:
>>
>>> Thanks Dan and Bill
On 8/31/17 5:42 PM, William Allen Simpson wrote:
On 8/31/17 12:17 PM, Pradeep wrote:
Thanks Dan and Bill for the quick response. As Dan suggested, is moving
svc_rqst_xprt_register() to the end of svc_vc_rendezvous() the right fix?
Partly. Also needs checking the error return.
https://git
On 8/31/17 12:17 PM, Pradeep wrote:
Thanks Dan and Bill for the quick response. As Dan suggested, is moving
svc_rqst_xprt_register() to the end of svc_vc_rendezvous() the right fix?
Partly. Also needs checking the error return.
https://github.com/linuxbox2/ntirpc/commit/28d3e96d4a72968052
Bill's testing a fix now. Hopefully we can get it in this week.
Daniel
On 08/31/2017 12:17 PM, Pradeep wrote:
Thanks Dan and Bill for the quick response. As Dan suggested, is moving
svc_rqst_xprt_register() to the end
of svc_vc_rendezvous()
the
right
fix?
On Thu, Aug 31, 2017 at 8:30
Thanks Dan and Bill for the quick response. As Dan suggested, is moving
svc_rqst_xprt_register() to the end
of svc_vc_rendezvous()
the
right
fix?
On Thu, Aug 31, 2017 at 8:30 AM, William Allen Simpson <
william.allen.simp...@gmail.com> wrote:
> On 8/31/17 9:14 AM, Daniel Gryniewicz wrote:
On 8/31/17 9:14 AM, Daniel Gryniewicz wrote:
On 08/30/2017 10:06 PM, Pradeep wrote:
Hi all,
I'm hitting a crash in TIRPC with Ganesha 2.6-dev.5. It appears to me that
there is a race between a incoming RPC message on a new xprt (for which
accept() was done on the FD) and TIRPC setting the pro
On 08/30/2017 10:06 PM, Pradeep wrote:
Hi all,
I'm hitting a crash in TIRPC with Ganesha 2.6-dev.5. It appears to me
that there is a race between a incoming RPC message on a new xprt (for
which accept() was done on the FD) and TIRPC setting the process_cb on
the new xprt.
We set the xprt->x
Hi all,
I'm hitting a crash in TIRPC with Ganesha 2.6-dev.5. It appears to me that
there is a race between a incoming RPC message on a new xprt (for which
accept() was done on the FD) and TIRPC setting the process_cb on the new
xprt.
We set the xprt->xp_dispatch.process_cb() from the rendezvous f
