8 a.m.
What I was thinking of was going through the rbtree in svc_xprt_fd and
checking the xp_ops in them to see which function set they have. One of
them should be the svc_dg_rendezvous* functions, which would be the main
UDP listener. It also has pktinfo in xp_pktinfo, which might help.
It's xp_fd can be cross referenced with netstat output, and we're
primarily interested in it's xp_refcnt field.
svc_xprt_fd is a global, so it should be accessible from any stack in
ntirpc.
Daniel
On 1/17/21 7:24 PM, anirban.chalcogen(a)gmail.com wrote:
Hi Daniel or Frank,
We spoke about this issue on weekly call just over a week ago. I remember Daniel's
advice on that call was to dig into the Ganesha core dump and try to extract the
communication channel for each fd from the svc_rqst_epoll_loop() calls and verify that the
UDP listen socket for NFS is being epoll'd on. I'm not sure however, the data is
present in that stack that would actually allow us to make that call.
(gdb) bt full
#0 0x00007f3c46616eb3 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x00007f3c4876f04c in svc_rqst_epoll_loop (sr_rec=0x4ae8c10) at
/<redacted>/libntirpc/src/svc_rqst.c:1013
cc = 0x7f3c46d13eb4 <pthread_cond_timedwait@(a)GLIBC_2.3.2+516>
n = 0x0
ts = {tv_sec = 2750901, tv_nsec = 954488941}
timeout_ms = 29000
expire_ms = -1544065341
n_events = 32572
__func__ = "svc_rqst_epoll_loop"
#2 0x00007f3c4876f199 in svc_rqst_run_task (wpe=0x4ae8c10) at
/<redacted>libntirpc/src/svc_rqst.c:1065
sr_rec = 0x4ae8c10
finished = false
__func__ = "svc_rqst_run_task"
#3 0x00007f3c48777dca in work_pool_thread (arg=0x7f3c300008c0) at
/<redacted>/libntirpc/src/work_pool.c:181
wpt = 0x7f3c300008c0
pool = 0x7f3c48993940 <svc_work_pool>
have = 0x0
ts = {tv_sec = 1608803814, tv_nsec = 833467718}
rc = 0
spawn = false
__func__ = "work_pool_thread"
#4 0x00007f3c46d0fea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#5 0x00007f3c466168dd in clone () from /lib64/libc.so.6
No symbol table info available.
I am assuming that you would need to chenck the xp_type member in the SVCXPRT structure?
However, the members of the latter are lost in the stack since during rearm, we obtain the
sr_rec as follows:
int
svc_rqst_rearm_events(SVCXPRT *xprt)
{
struct rpc_dplx_rec *rec = REC_XPRT(xprt);
struct svc_rqst_rec *sr_rec = (struct svc_rqst_rec *)rec->ev_p;
Here, ev_p is a pointer and it seems to me we will not be able to obtain rec from *sr_rec
with a container_of() kind macro since ev_p is not being referenced. Do you have another
way to ascertain if the FDs polled have the UDP descriptor in them?
Thanks,
Anirban
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org