LU-2258 mount: solve races between evict and umount

There are two race conditions between evict and umount.

1) The one is that obd_export_evict_by_xxx() can touch a lustre hash
which has already been finalized but not unregistered yet.

2) The other is that the class_decref() in lprocfs_wr_evict_client()
can call lprocfs_remove() via osc_cleanup() while having _lprocfs_lock
already. That's why this case ends up in a deadlock.

This patch solve these problems with the below solutions.
- see if obd_nid_hash and obd_uuid_hash is still available when
  evicting.
- move class_incref() to below LPROCFS_EXIT() and class_decref()
  before LPROCFS_ENTRY() in order to avoid dead-locking

Signed-off-by: Hiroya Nozaki <nozaki.hiroya@jp.fujitsu.com>
Change-Id: I2cc19a88ffd6a230ab115bc1e4b9d31fbbbb4615
Reviewed-on: http://review.whamcloud.com/4444
Tested-by: Hudson
Reviewed-by: Lai Siyao <laisiyao@whamcloud.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Jinshan Xiong <jinshan.xiong@whamcloud.com>
Reviewed-by: Oleg Drokin <green@whamcloud.com>
LU-2282 obdclass: Slightly increase the size of lu_keys[]

After an "FSTYPE=ldiskfs sh llmount.sh" on a single-node setup, all
the thirty-two slots in lu_keys[] will be consumed.  For example,

  Slot         Key Address       Owner
  ------------------------------------------
  lu_keys[0]   ffffffffa0a4bd00  obdclass
  lu_keys[1]   ffffffffa0a4fac0  obdclass
  lu_keys[2]   ffffffffa0a4d4a0  obdclass
  lu_keys[3]   ffffffffa0a58900  obdclass
  lu_keys[4]   ffffffffa0a4fd80  obdclass
  lu_keys[5]   ffffffffa0a2d940  obdclass
  lu_keys[6]   ffffffffa0c34260  ptlrpc
  lu_keys[7]   ffffffffa05577a0  fld
  lu_keys[8]   ffffffffa0131240  fid
  lu_keys[9]   ffffffffa0692140  osc
  lu_keys[10]  ffffffffa0692180  osc
  lu_keys[11]  ffffffffa074a320  lov
  lu_keys[12]  ffffffffa074a360  lov
  lu_keys[13]  ffffffffa07d3860  obdecho
  lu_keys[14]  ffffffffa07d38a0  obdecho
  lu_keys[15]  ffffffffa0819140  lquota
  lu_keys[16]  ffffffffa0822460  lquota
  lu_keys[17]  ffffffffa081c280  lquota
  lu_keys[18]  ffffffffa0afbd60  mgs
  lu_keys[19]  ffffffffa0d00fa0  mdd
  lu_keys[20]  ffffffffa0d01c20  mdd
  lu_keys[21]  ffffffffa0d00f60  mdd
  lu_keys[22]  ffffffffa0dd56a0  osd_ldiskfs
  lu_keys[23]  ffffffffa0e6bf40  mdt
  lu_keys[24]  ffffffffa0ecb6c0  lod
  lu_keys[25]  ffffffffa08576c0  osp
  lu_keys[26]  ffffffffa0857700  osp
  lu_keys[27]  ffffffffa0f17200  ofd
  lu_keys[28]  ffffffffa0fd48e0  lustre
  lu_keys[29]  ffffffffa0fd4920  lustre
  lu_keys[30]  ffffffffa0fd64e0  lustre
  lu_keys[31]  ffffffffa0fd6520  lustre

Loading osd_zfs.ko at this point, which is necessary under certain
debugging/testing circumstances, will get ENFILE from
lu_context_key_register().  To make developing on single-node setups
easier while minimizing new array iterating overhead, this patch
increases the size of lu_keys[] by eight words.

A couple of additional things were considered too.  First, the number
of keys may be reducible.  For instance, the md_ucred and md_capainfo
keys in mdd might be merged into the mdd_thread_info key, at a quick
glance.  However, the amount of change is not small.  The other thing
is that lu_keys[] could be dynamically allocated and grown on demand.
But additional locking is required when synchronizing
lu_context::lc_value[]s with lu_keys[].

Change-Id: I211bdb8af524a79f99b11f73e7260572459ccb17
Signed-off-by: Li Wei <wei.g.li@intel.com>
Reviewed-on: http://review.whamcloud.com/4476
Tested-by: Hudson
Reviewed-by: Alex Zhuravlev <bzzz@whamcloud.com>
Tested-by: Maloo <whamcloud.maloo@gmail.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
Reviewed-by: Mike Pershin <tappro@whamcloud.com>