mm: zcache: fix locking sequence

Deadlock is observed in zcache reclaim paths due to
different locking sequence.

Core#0:				    Core#1:
 |spin_bug()                         |do_raw_write_lock()
 |do_raw_spin_lock()                 |_raw_write_lock_irqsave()
 |_raw_spin_lock_irqsave()           |zcache_rbnode_isolate()
 |zcache_flush_inode()               |zcache_load_delete_zaddr()
 |__cleancache_invalidate_inode()    |zcache_evict_zpage()
 |truncate_inode_pages_range()       |zbud_reclaim_page()
 |truncate_inode_pages()             |zcache_scan()
 |truncate_inode_pages_final()       |shrink_slab_node()
 |ext4_evict_inode()                 |shrink_slab()
 |evict()                            |try_to_free_pages()
 |dispose_list()                     |__alloc_pages_nodemask()
 |prune_icache_sb()                  |alloc_kmem_pages_node()
 |super_cache_scan()                 |copy_process.part.52()
 |shrink_slab_node()                 |do_fork()
 |shrink_slab()                      |sys_clone()
 |kswapd_shrink_zone.constprop       |el0_svc()
 |balance_pgdat()
 |kswapd()
 |kthread()
 |ret_from_fork()

The deadlock happens because alternate sequence are
followed while taking
 zpool->rb_lock  (protects zpool rb tree), and
 rbnode->ra_lock (protects radix tree maintained by rbtree node)

Fix the sequence of locks being taken to avoid deadlock.

Change-Id: I32db23268f63eb8eb5aee30e4462c190e2e02f48
Signed-off-by: Shiraz Hashim <shashim@codeaurora.org>