LU-1303 build: bump warning on LOD/OSP workarounds

There are a number of generated compile warnings in the code
that need to be fixed due to LOD/OSP workarounds that need to
be removed.  I've bumped the version check to version 2.3.55,
to give the LOD/OSP patches a chance to land.

Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
Change-Id: I41356848d7f1d0699bb0f01cb9302012ff386bc4
Reviewed-on: http://review.whamcloud.com/3741
Tested-by: Hudson
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-1735 ptlrpc: only set jobid if not already set

The ptlrpc_set_add_req->lustre_get_jobid->cfs_access_process_vm()
callpath locks mm->mmap_sem to fetch environment variables, but if
this could deadlock in case of MMAP IO, which also holds mmap_sem.
If the mmap_sem is already held for write, just don't set the jobid.
This will make jobid stats inconsistent for mmap IO, but avoids a
lot of complexity or race conditions in the code otherwise.

If the caller already has fetched the jobid and saved it for this
inode in the OSC layer, so we don't need to fetch and reset the
pd_jobid field at all in this case.  This avoids doing extra work
to fetch the jobid if it is not needed, and avoids storing it
temporarily on the stack when it won't be used.

Signed-off-by: Andreas Dilger <adilger@whamcloud.com>
Change-Id: I22c3d5c1755c1d6aab666a769df38218b954650a
Reviewed-on: http://review.whamcloud.com/3604
Reviewed-by: Jinshan Xiong <jinshan.xiong@whamcloud.com>
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Niu Yawei <niu@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-1763 test: enable jobstats by default

Enable jobstats in the auto-test by default.

Signed-off-by: Niu Yawei <niu@whamcloud.com>
Change-Id: I03bd22b144f4372922c6dc67511d09a91d17b8e4
Reviewed-on: http://review.whamcloud.com/3718
Tested-by: Hudson
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
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>