md: fix deadlock of fusion-io driver

We have changed flashcache to be request based and it works with intel
SSD very well.

But when we are testing request-based flashcache with fusionio, it
reports deadlock, as below.

	[ 1298.800369] EXT4-fs (sdb3): mounted filesystem with ordered data mode. Opts:
	[ 1491.080532] flashcache: flashcache-1.0 initialized
	[ 1491.106647] device-mapper: flashcache: flashcache_writeback_create:
	md_blocks = 75996, md_sectors = 607968
	[ 1491.106649]
	[ 1491.106653] device-mapper: flashcache: Allocate 303976KB (16B per)
	mem for 19454464-entry cache(capacity:76290MB, associativity:512,
	block size:8 sectors(4KB))
	[ 1491.866838] flashcache-dbg: cachedev check - cachedev cachedev
	[ 1781.859573] EXT3-fs error (device dm-0): ext3_check_descriptors:
	Block bitmap for group 336 not in group (block 0)!
	[ 1781.984347] EXT3-fs (dm-0): error: group descriptors corrupted
	[ 1893.404937] kjournald starting.  Commit interval 5 seconds
	[ 1893.405209] EXT3-fs (dm-0): using internal journal
	[ 1893.405215] EXT3-fs (dm-0): mounted filesystem with ordered data mode
	[ 2155.839163] kjournald starting.  Commit interval 5 seconds
	[ 2155.839440] EXT3-fs (dm-0): using internal journal
	[ 2155.839447] EXT3-fs (dm-0): mounted filesystem with ordered data mode
	[ 2301.180750] BUG: soft lockup - CPU#2 stuck for 67s! [events/2:69]
	[ 2301.252911] Modules linked in: ext3 jbd flashcache ipmi_devintf
	ipmi_si ipmi_msghandler cpufreq_ondemand acpi_cpufreq freq_table mperf
	bonding ipv6 sg ses enclosure iomemory_vsl(P)(U) bnx2 microcode
	serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac
	edac_core shpchp ext4 mbcache jbd2 megaraid_sas pata_acpi ata_generic
	ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
	scsi_wait_scan]
	[ 2301.252943] CPU 2
	[ 2301.252944] Modules linked in: ext3 jbd flashcache ipmi_devintf
	ipmi_si ipmi_msghandler cpufreq_ondemand acpi_cpufreq freq_table mperf
	bonding ipv6 sg ses enclosure iomemory_vsl(P)(U) bnx2 microcode
	serio_raw i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support i7core_edac
	edac_core shpchp ext4 mbcache jbd2 megaraid_sas pata_acpi ata_generic
	ata_piix dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
	scsi_wait_scan]
	[ 2301.252970]
	[ 2301.252973] Pid: 69, comm: events/2 Tainted: P
	----------------   2.6.32-220.23.1.tb1017.el6.x86_64 #1 Huawei
	Technologies Co., Ltd. Tecal RH2285          /BC11BTSA
	[ 2301.252979] RIP: 0010:[<ffffffff814e126e>]  [<ffffffff814e126e>]
	_spin_lock+0x1e/0x30
	[ 2301.252989] RSP: 0018:ffff880630223890  EFLAGS: 00000297
	[ 2301.252991] RAX: 0000000000003dd1 RBX: ffff880630223890 RCX: ff00000012a9c74b
	[ 2301.252994] RDX: 0000000000003dd0 RSI: ffff880625aab100 RDI: ffff8806245b86a0
	[ 2301.252996] RBP: ffffffff8100bc0e R08: 000000000000c3a1 R09: 0000000000000270
	[ 2301.252999] R10: 0000000000145214 R11: 00000000000e329c R12: 0000000000011200
	[ 2301.253001] R13: 0000000000000000 R14: ffff88062ea00430 R15: ffff88062ea00430
	[ 2301.253005] FS:  0000000000000000(0000) GS:ffff88003e640000(0000)
	knlGS:0000000000000000
	[ 2301.253007] CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
	[ 2301.253010] CR2: 00007f5e3eb7f000 CR3: 000000062be6d000 CR4: 00000000000006e0
	[ 2301.253013] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
	[ 2301.253015] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
	[ 2301.253018] Process events/2 (pid: 69, threadinfo ffff880630222000,
	task ffff8806301fc100)
	[ 2301.253020] Stack:
	[ 2301.276734]  ffff8806302238b0 ffffffffa016e156 0000000012a0c74b
	ffff8806245b8010
	[ 2301.276739] <0> ffff880625aab100 ffffffffa0199b57 ffff880625aad548
	ffff8806245b8000
	[ 2301.276745] <0> ffff8806245b9328 0000000012a0c74b 0000000000000008
	0000000000000000
	[ 2301.276751] Call Trace:
	[ 2301.305639]  [<ffffffffa016e156>] ? fusion_spin_lock+0x16/0x30 [iomemory_vsl]
	[ 2301.305664]  [<ffffffffa0199b57>] ?
	ifio_8df23.5841b92c33a683151729df762dd2cc1e217.3.1.5.126+0x27/0x180
	[iomemory_vsl]
	[ 2301.305687]  [<ffffffffa01889a1>] ?
	ifio_b0dc1.a0eaaacade448681428f7bad8c5562c6f00.3.1.5.126+0x361/0x5a0
	[iomemory_vsl]
	[ 2301.305705]  [<ffffffffa0171a9d>] ? kfio_do_request+0x16d/0x450
	[iomemory_vsl]
	[ 2301.305714]  [<ffffffff81231c51>] ? elv_insert+0xd1/0x1a0
	[ 2301.305720]  [<ffffffff812381c5>] ? __generic_unplug_device+0x35/0x40
	[ 2301.305725]  [<ffffffff8123adb0>] ? __make_request+0x160/0x590
	[ 2301.305730]  [<ffffffff81248a3c>] ? blk_throtl_bio+0x23c/0x680
	[ 2301.305747]  [<ffffffffa01718f7>] ?
	kfio_rq_make_request_fn+0x47/0x80 [iomemory_vsl]
	[ 2301.305753]  [<ffffffff8123a67f>] ? generic_make_request+0x2af/0x5c0
	[ 2301.305756]  [<ffffffff8123aa1f>] ? submit_bio+0x8f/0x120
	[ 2301.305760]  [<ffffffff8123aa1f>] ? submit_bio+0x8f/0x120
	[ 2301.305771]  [<ffffffffa0009f5e>] ? dispatch_io+0x2be/0x340 [dm_mod]
	[ 2301.305780]  [<ffffffffa0009a30>] ? bvec_get_page+0x0/0x30 [dm_mod]
	[ 2301.305787]  [<ffffffffa0009a60>] ? bvec_next_page+0x0/0x10 [dm_mod]
	[ 2301.305794]  [<ffffffffa000a21c>] ? dm_io+0xbc/0x1b0 [dm_mod]
	[ 2301.305801]  [<ffffffffa0009a30>] ? bvec_get_page+0x0/0x30 [dm_mod]
	[ 2301.305808]  [<ffffffffa0009a60>] ? bvec_next_page+0x0/0x10 [dm_mod]
	[ 2301.305815]  [<ffffffffa0327726>] ? dm_io_async_bvec+0x76/0xf0 [flashcache]
	[ 2301.305820]  [<ffffffffa03271e0>] ?
	flashcache_md_write_callback+0x0/0x30 [flashcache]
	[ 2301.305829]  [<ffffffff81122f3e>] ? __get_free_pages+0xe/0x50
	[ 2301.305834]  [<ffffffffa0327dae>] ?
	flashcache_md_write_kickoff+0x1fe/0x260 [flashcache]
	[ 2301.305841]  [<ffffffffa032a720>] ? pop+0x50/0x70 [flashcache]
	[ 2301.305847]  [<ffffffffa03299d0>] ?
	flashcache_md_write_done+0x0/0x5b0 [flashcache]
	[ 2301.305852]  [<ffffffffa0327bb0>] ?
	flashcache_md_write_kickoff+0x0/0x260 [flashcache]
	[ 2301.305859]  [<ffffffffa032a770>] ? do_work+0x0/0x70 [flashcache]
	[ 2301.305864]  [<ffffffffa032a75e>] ? process_jobs+0x1e/0x30 [flashcache]
	[ 2301.305870]  [<ffffffffa032a7b2>] ? do_work+0x42/0x70 [flashcache]
	[ 2301.305877]  [<ffffffff8108b8f0>] ? worker_thread+0x170/0x2a0
	[ 2301.305884]  [<ffffffff81091230>] ? autoremove_wake_function+0x0/0x40
	[ 2301.305888]  [<ffffffff8108b780>] ? worker_thread+0x0/0x2a0
	[ 2301.305892]  [<ffffffff81090ec6>] ? kthread+0x96/0xa0
	[ 2301.305898]  [<ffffffff8100c14a>] ? child_rip+0xa/0x20
	[ 2301.305901]  [<ffffffff81090e30>] ? kthread+0x0/0xa0
	[ 2301.305905]  [<ffffffff8100c140>] ? child_rip+0x0/0x20
	[ 2301.305907] Code:
	[ 2301.306555] BUG: soft lockup - CPU#4 stuck for 67s! [events/4:71]

After, Jens Axboe give this fix.

Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Robin Dong <sanbai@taobao.com>
flashcache: add new blkio_policy_type to support quota of flashcache

We add a new type of blkio policy "blkio_policy_flashcache" to record cgroup
information when using flashcache.

Every LRU list in flashcache will be divided into different group which
is maneged by 'struct flashcache_group'.

For example, we use four processes to run in differetnt four cgroups -- group1,
group2, group3, group4 -- to read/write flashcache, then every LRU of
flashcache wil be divided into four sub-LRU, and every sub-LRU is managed by
'struct flascache_group'

Signed-off-by: Robin Dong <sanbai@taobao.com>
flashcache: implement the cache alloc policy between different cgroup

Process running in different cgroup will get different cache space. In
the begginning, all the cache belongs to 'root group' in flashcache,
after running for a while, the flashcache will alloc cache to different
"flashcache_group" by their cgroup weight.

Because flashcache doesn't have a uniq large LRU list, so we only divide
these many small LRU lists into different "flashcache_grou".

Signed-off-by: Robin Dong <sanbai@taobao.com>
flashcache: add policy to reclaim cache space

If weight of a cgroup changed or be deleted, we will reclaim its cache space
and give back to 'root group'.

Signed-off-by: Robin Dong <sanbai@taobao.com>
flashcache: add statistics to show cache space in different cgroup

Add "flashcache_blocks" to show different cgroups usage of cache space
in flashcache.

Use
	cat /proc/flashcache/sdx+sdy/flashcache_blocks

to display.

Signed-off-by: Robin Dong <sanbai@taobao.com>
flashcache: reclaim its cache if a cgroup is destroyed

When destroy a cgroup, all the cache space belonged to it will
be reclaim to 'root group' and will be gived to other cgroup when
they need.

Signed-off-by: Robin Dong <sanbai@taobao.com>