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:34:33 +0000 (12:34 -0400)
commitc91a5d046ea52ca232eba22efd6127a4ee70b44f
tree0cb69c9cad6bd356e5b71555475a0b709dd325cb
parentd6ea0df49ea8f821bed42ab59aa09d6d656d9bb8
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