diff options
author | Tejun Heo <tj@kernel.org> | 2008-09-24 16:22:23 -0500 |
---|---|---|
committer | Eric Van Hensbergen <ericvh@ericvh-desktop.austin.ibm.com> | 2008-09-24 16:22:23 -0500 |
commit | 7dc5d24be06a5ed874af035d52a083a7b61ef1bd (patch) | |
tree | 74f8e59f6a32ffc099dca3eb1eed9d6e6b58b616 /net/dccp/ackvec.c | |
parent | 72029fe85d8d060b3f966f2dbc36b3c75b5a6532 (diff) |
9p-trans_fd: fix trans_fd::p9_conn_destroy()
p9_conn_destroy() first kills all current requests by calling
p9_conn_cancel(), then waits for the request list to be cleared by
waiting on p9_conn->equeue. After that, polling is stopped and the
trans is destroyed. This sequence has a few problems.
* Read and write works were never cancelled and the p9_conn can be
destroyed while the works are running as r/w works remove requests
from the list and dereference the p9_conn from them.
* The list emptiness wait using p9_conn->equeue wouldn't trigger
because p9_conn_cancel() always clears all the lists and the only
way the wait can be triggered is to have another task to issue a
request between the slim window between p9_conn_cancel() and the
wait, which isn't safe under the current implementation with or
without the wait.
This patch fixes the problem by first stopping poll, which can
schedule r/w works, first and cancle r/w works which guarantees that
r/w works are not and will not run from that point and then calling
p9_conn_cancel() and do the rest of destruction.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Eric Van Hensbergen <ericvh@gmail.com>
Diffstat (limited to 'net/dccp/ackvec.c')
0 files changed, 0 insertions, 0 deletions