LU-5579 ldlm: re-sent enqueue vs lock destroy race

Upon lock enqueue re-send, lock is pinned by ldlm_handle_enqueue0,
however it may race with client eviction or even lock cancel (if
a reply for the original RPC finally reached the client) and the
lock cannot be found by cookie anymore:

ASSERTION( lock != NULL ) failed: Invalid lock handle

Signed-off-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
Change-Id: I9d8156bf78a1b83ac22ffaa1148feb43bef37b1a
Xyratex-bug-id: MRP-2094
Reviewed-on: http://review.whamcloud.com/11839
Tested-by: Jenkins
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5530 mdt: Properly match open lock and unlock

It seems that when request resend with a corresponding lock match is
in play (thanks to large striping + llnl patch for the client to send
small requests only), after all the suffering and fixing coming from
LU-2827, here is another casualty in in open/lease locking.
mdt_reint_open() and mdt_open_by_fid_lock() might match the lock
on resend and not call mdt_object_open_lock(), yet call
mdt_object_open_unlock() before exit.
Since mdt_object_open_lock/unlock also plays with a semaphore,
hilarity ensues usually most visible as a rw_sem lockup
in mdt_object_open_lock.

This patch adds tracking whenever we actually called mdt_object_open_lock
or not and only calls mdt_object_open_unlock if we did.

Change-Id: I73c529229acec98cac4ad73f7b487e759ad9a763
Signed-off-by: Oleg Drokin <oleg.drokin@intel.com>
Reviewed-on: http://review.whamcloud.com/11841
Tested-by: Jenkins
Reviewed-by: Jinshan Xiong <jinshan.xiong@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: James Simmons <uja.ornl@gmail.com>
Reviewed-by: Faccini Bruno <bruno.faccini@intel.com>
LU-4839 utils: fix bandwidth ctl in lhsmtool

Use nanosleep for bandwidth control because usleep fails
for times of a second or longer (usleep(2) EINVAL return value). Add
loop in case sleep is woken by signal.

Signed-off-by: Nathaniel Clark <nathaniel.l.clark@intel.com>
Change-Id: Ib58676b878678eb399bf58bb9873d8fb411b3316
Reviewed-on: http://review.whamcloud.com/12093
Tested-by: Jenkins
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: James Nunez <james.a.nunez@intel.com>
Reviewed-by: Andreas Dilger <andreas.dilger@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-4943 obdclass: detach MGC dev on error

lustre_start_mgc() creates MGC device, if error happens later on
ll_fill_super(), this device is still attached, and later mount
fails by keep complaining that the MGC device's already in the
client node.

It turns out that the device was referenced by mgc config llog data
which is arranged in the mgc lock requeue thread re-trying to get its
mgc lock, and in normal case, this llog reference only released in
mgc_blocking_ast() when the system is umount.

This patch make mgc_precleanup() to wake up requeue thread to handle
the config llog data.

This patch also makes mgc_setup() wait for mgc_requeue_thread() start
before moving on.

Signed-off-by: Bobi Jam <bobijam.xu@intel.com>
Change-Id: I83df8c68c1dbe4ef4ee879e04ab20df46fea9062
Reviewed-on: http://review.whamcloud.com/10129
Tested-by: Jenkins
Reviewed-by: Niu Yawei <yawei.niu@intel.com>
Reviewed-by: Ryan Haasken <haasken@cray.com>
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-5573 obdclass: strengthen against concurrent server mounts

This patch is an add-on to previous fix for LU-5299, against same
issues/races scenarios during concurrent server devices mounts.

Signed-off-by: Bruno Faccini <bruno.faccini@intel.com>
Change-Id: Ib12332e9758f4a64fb8d7bdf60464100b4fd6c00
Reviewed-on: http://review.whamcloud.com/12114
Tested-by: Jenkins
Tested-by: Maloo <hpdd-maloo@intel.com>
Reviewed-by: Bobi Jam <bobijam@gmail.com>
Reviewed-by: Mike Pershin <mike.pershin@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
New tag 2.6.54

Change-Id: Ie342c882a0d7034fc129df4ad973c78ddba6ba13