I'm trying to make sense of the error recovery (for everything,
because it intersects with RDMA). Walking through the
dispatcher code, I've found (again) something that makes no
sense to me. Straightening the code for comprehension:
thr_decode_rpc_request()
...
DISP_RLOCK(xprt);
...
if (!SVC_GETARGS(xprt, ...){
...
DISP_SLOCK2(xprt);
svcerr_decode(xprt, ...);
DISP_SUNLOCK(xprt);
...
}
...
finish:
stat = SVC_STAT(xprt);
DISP_RUNLOCK(xprt);
===
DISP_SLOCK2 expands as:
/* For the special case of SLOCK taken from a dispatcher thread */
#define DISP_SLOCK2(x) \
do { \
if (!slocked) { \
if (!(rlocked && ((x)->xp_type == XPRT_UDP))) { \
SVC_LOCK((x), XP_LOCK_SEND, __func__, \
__LINE__); \
} \
slocked = true; \
} \
} while (0)
In this case, !slocked is true, but rlocked is true and
((x)->xp_type == XPRT_UDP) is false (for RDMA) -- so the
SVC_LOCK() occurs.
We get no lock for UDP, but we get re-locks for all others
(TCP, SCTP, RDMA, VSOCK).
I'm pretty sure this isn't what was intended. There's no
reason to lock here at all for TCP, because the function
called -- libntirpc/src/svc.c svcerr_decode() -- is
explicitly labeled MT safe.
For RDMA, I've eliminated the locking code (in the ops), so
nothing happens....
Is there any reason to lock for SCTP or VSOCK?
Is the test backwards? Is there a reason to lock for UDP?
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Nfs-ganesha-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
