Whamcloud - gitweb
LU-1721 ptlrpc: AT race in drop request
authorLiang Zhen <liang@whamcloud.com>
Wed, 8 Aug 2012 08:12:03 +0000 (16:12 +0800)
committerOleg Drokin <green@whamcloud.com>
Wed, 22 Aug 2012 16:22:51 +0000 (12:22 -0400)
commit1aae6c8cc1b9cee1113e7b1aeb32fcfba2968bf6
tree21809b86e903b37416dbee7cc483d6cf503dc42d
parentbfd4acbe0b197fdc6f6a040ee1360cdc56ceef07
LU-1721 ptlrpc: AT race in drop request

It's introduced in by commit 07b8db220e48782369f48d86213c5d404a628ded
which makes ptlrpc_server_drop_request() not to hold at_lock for
checking req::rq_at_linked.
This change might race with ptlrpc_at_check_timed() if:

1) thread-1: call ptlrpc_at_check_timed() and remove the request from
   paa_reqs_array, before it set req::rq_at_linked to zero...
2) thread-2: call ptlrpc_server_drop_request() to release the last
   refcount, and it found req::rq_at_linked is non-zero, so it
   entered the condition "if (req->rq_at_linked) {...}"
3) thread-1: set req::rq_at_linked to zero
4) thread-2: take at_lock, and hit the assetion
   LASSERT(!cfs_list_empty(&req->rq_timed_list)) because thread-1 has
   already removed req::rq_at_linked from paa_reqs_array in step 1)

This patch fixed this issue and did some code cleanup.

Signed-off-by: Liang Zhen <liang@whamcloud.com>
Change-Id: If4469637a5f9d63c9253a9f4c4cac0bcd7f8b46e
Reviewed-on: http://review.whamcloud.com/3564
Tested-by: Hudson
Reviewed-by: wangdi <di.wang@whamcloud.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
lustre/ptlrpc/service.c