LU-1602 ldlm: Fix flock deadlock detection race

Deadlock isn't detected if 2 threads are trying to
grant 2 locks which deadlock on each other.
They call ldlm_flock_deadlock() simultaneously
and deadlock ins't detected.

The soulition is to add lock to blocking list before
calling ldlm_flock_deadlock()

Xyratex-bug-id: MRP-412
Signed-off-by: Andriy Skulysh <Andriy_Skulysh@xyratex.com>
Reviewed-by: Vitaly Fertman <vitaly_fertman@xyratex.com>
Reviewed-by: Bruce Korb <bruce_korb@xyratex.com>
Change-Id: I437c8b40a58de14bbac3da39d98d0f03d0f2e064
Reviewed-on: http://review.whamcloud.com/3277
Tested-by: Hudson
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Keith Mannthey <keith.mannthey@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
LU-3504 ldlm: Don't alloc kmem when holding resource lr_lock

This change fixes a regression introduced by the following commit:
    commit 2c7a41a5c5958d36fa839ea91f3e63375cbd90fc
    Author: Vitaly Fertman <vitaly_fertman@xyratex.com>
    Date:   Tue Jun 26 01:47:50 2012 +0400
        LU-1157 ldlm: replace waiting flock lists by hashes

This commit introduced the possibility of a dead-lock which
can occur on MDS handling 1st FLock request for an export,
owning resource lr_lock spin-lock from lock_res_and_lock()
the kmem allocation of the new hashing stuff for FLocks is
not done atomic and thus can resched() allowing competitor
threads to spin forever on all available CPUs.

The fix is to move the kmem alloc before granting lr_lock.

Signed-off-by: Bruno Faccini <bruno.faccini@intel.com>
Change-Id: Ie68f93746626dc7f62994de0912596859ad9e8d5
Patch-Set: 1