> The lock is associated with the rpc_task. Threads can normally only > access an rpc_task when it is on a wait queue (while holding the wait > queue lock) unless they are given ownership of the rpc_task. > > IOW: the scenario you describe should not be possible, since it relies > on thread 1 assigning the lock to the rpc_task after it has been removed > from the wait queue. Hrm. I guess I'm in over my head here. Apologoies if I'm just asking silly bumbling questions. You can start ignoring me at any time. :) I was talking about setting (or leaving set) the XPRT_LOCKED bit in rpc_xprt->state. By "assigning the lock" I really just mean that thread 1 leaves XPRT_LOCKED set in rpc_xprt->state and sets rpc_xprt->snd_task to thread 2. > If you are recompiling the kernel, perhaps you can also add in a patch > to rpc_show_tasks() to display the current value of > clnt->cl_xprt->snd_task? Sure. This is what 'echo 0 > /proc/sys/sunrpc/rpc_debug' shows after the hang (with my extra prints): # cat /proc/kmsg ... <6>client: ffff88082b6c9c00, xprt: ffff880824aef800, snd_task: ffff881029c63ec0 <6>client: ffff88082b6c9e00, xprt: ffff880824aef800, snd_task: ffff881029c63ec0 <6>-pid- flgs status -client- --rqstp- -timeout ---ops-- <6>18091 0080 -11 ffff88082b6c9e00 (null) ffff0770ns3 ACCESS a:call_reserveresult q:xprt_sending <6>client: ffff88082a244600, xprt: ffff88082a343000, snd_task: (null) <6>client: ffff880829181600, xprt: ffff88082a343000, snd_task: (null) <6>client: ffff880828170200, xprt: ffff880824aef800, snd_task: ffff881029c63ec0 -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
