> My main interest is always the upstream (Linus) kernel, however the RPC
> client in the CentOS 6.3 kernel does actually contain a lot of code that
> was recently backported from upstream. As such, it is definitely of
> interest to figure out corner case bugs so that we can compare to
> upstream...
Ok, great. I will try this version of the patch as well. However, when just
thinking about this, I'm concerned that the race still exists, but is just less
likely to manifest.
I imagine something like this happening. I assume there is some reason this
can't happen that I'm not seeing? These are functions from linus's current
git, not the CentOS 6.3 code:
thread 1 thread 2
-------- --------
__rpc_execute __rpc_execute
... ...
call_reserve
xprt_reserve
xprt_lock_and_alloc_slot
xprt_lock_write
xprt_reserve_xprt
...
xprt_release_write
call_reserve
xprt_reserve
xprt_lock_and_alloc_slot
xprt_lock_write
xprt_reserve_xprt
rpc_sleep_on_priority
__rpc_sleep_on_priority
__rpc_add_wait_queue
__rpc_add_wait_queue_priority
(Now on the sending wait queue)
xs_tcp_release_xprt
xprt_release_xprt
xprt_clear_locked
__xprt_lock_write_next
rpc_wake_up_first
__rpc_find_next_queued
__rpc_find_next_queued_priority
...
(has now pulled thread 2 off the wait queue)
out_of_line_wait_on_bit
(receive SIGKILL)
rpc_wait_bit_killable
rpc_exit
rpc_exit_task
rpc_release_task
(doesn't release xprt b/c he isn't listed in snd_task yet)
(returns from __rpc_execute)
__xprt_lock_write_func
(thread 2 now has the transport locked)
rpc_wake_up_task_queue_locked
__rpc_remove_wait_queue
__rpc_remove_wait_queue_priority
(continues on, potentially exiting early,
potentially blocking the next time it needs the transport)
With the patch we're discussing, it would fix the case where thread 2 is
breaking out of the FSM loop after having been given the transport lock. But
what about the above. Is there something else synchronizing things?
In my testing so far with my (not quite right) amended v3 of the patch, the
timing has become such that I was having trouble reproducing the problem while
attempting to instrument things with systemtap. However, without systemtap
running, I'm still able to reproduce the hang pretty easily.
--
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
