configfs: Fix race between configfs_readdir() and configfs_d_iput()

upstream id: 24307aa1

configfs_readdir() will use the existing inode numbers of inodes in the
dcache, but it makes them up for attribute files that aren't currently
instantiated.  There is a race where a closing attribute file can be
tearing down at the same time as configfs_readdir() is trying to get its
inode number.

We want to get the inode number of open attribute files, because they
should match while instantiated.  We can't lock down the transition
where dentry->d_inode is set to NULL, so we just check for NULL there.
We can, however, ensure that an inode we find isn't iput() in
configfs_d_iput() until after we've accessed it.

Signed-off-by: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
configfs: fix race between dentry put and lookup

upstream commit: 76ae281f6

A race window in configfs, it starts from one dentry is UNHASHED and end
before configfs_d_iput is called.  In this window, if a lookup happen,
since the original dentry was UNHASHED, so a new dentry will be
allocated, and then in configfs_attach_attr(), sd->s_dentry will be
updated to the new dentry.  Then in configfs_d_iput(),
BUG_ON(sd->s_dentry != dentry) will be triggered and system panic.

sys_open:                     sys_close:
 ...                           fput
                                dput
                                 dentry_kill
                                  __d_drop <--- dentry unhashed here,
                                           but sd->dentry still point
                                           to this dentry.

 lookup_real
  configfs_lookup
   configfs_attach_attr---> update sd->s_dentry
                            to new allocated dentry here.

                                   d_kill
                                     configfs_d_iput <--- BUG_ON(sd->s_dentry != dentry)
                                                     triggered here.

To fix it, change configfs_d_iput to not update sd->s_dentry if
sd->s_count > 2, that means there are another dentry is using the sd
beside the one that is going to be put.  Use configfs_dirent_lock in
configfs_attach_attr to sync with configfs_d_iput.

With the following steps, you can reproduce the bug.

1. enable ocfs2, this will mount configfs at /sys/kernel/config and
   fill configure in it.

2. run the following script.
	while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done &
	while [ 1 ]; do cat /sys/kernel/config/cluster/$your_cluster_name/idle_timeout_ms > /dev/null; done &

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Merge pull request #35 from taoma-tm/configfs_fix

Configfs fix
Fix a issue which causes subtree based dir quota not to work.

Returning a positive value on success from ext3_subtree_xattr_read() in file
cache building stage would cause a bad inode pointer lays in NULL page, which
in turn crashes the kernel.

Fix it by return 0 on success.

Signed-off-by: Huang Le <le.hl@alibaba-inc.com>
tcp friends

TCP/IP loopback socket pair stack bypass, based on an idea by, and
rough upstream patch from, David Miller <davem@davemloft.net> called
"friends", the data structure modifcations and connection scheme are
reused with extensive data-path changes.

A new sysctl, net.ipv4.tcp_friends, is added:
  0: disable friends and use the stock data path.
  1: enable friends and bypass the stack data path, the default.

Note, when friends is enabled any loopback interpose, e.g. tcpdump,
will only see the TCP/IP packets during connection establishment and
finish, all data bypasses the stack and instead is delivered to the
destination socket directly.

Testing done on a 4 socket 2.2GHz "Quad-Core AMD Opteron(tm) Processor
8354 CPU" based system, netperf results for a single connection show
increased TCP_STREAM throughput, increased TCP_RR and TCP_CRR transaction
rate for most message sizes vs baseline and comparable to AF_UNIX.

Significant increase (up to 5x) in aggregate throughput for multiple
netperf runs (STREAM 32KB I/O x N) is seen.

Some results:

Default netperf: netperf
                 netperf -t STREAM_STREAM
                 netperf -t STREAM_STREAM -- -s 51882 -m 16384 -M 87380
                 netperf

         Baseline  AF_UNIX      AF_UNIX           Friends
         Mbits/S   Mbits/S      Mbits/S           Mbits/S
           6860       714   8%    9444 138% 1323%  10576 154% 1481% 112%

Note, for the AF_UNIX (STREAM_STREAM) test 2 results are listed, 1st
with no options but as the defaults for AF_UNIX sockets are much lower
performaning a 2nd set of runs with a socket buffer size and send/recv
buffer sizes equivalent to AF_INET (TCP_STREAM) are done.

Note, all subsequent AF_UNIX (STREAM_STREAM, STREAM_RR) tests are done
with "-s 51882" such that the same total effective socket buffering is
used as for the AF_INET runs defaults (16384+NNNNN/2).

STREAM 32KB I/O x N: netperf -l 100 -t TCP_STREAM -- -m 32K -M 32K
                     netperf -l 100 -t STREAM_STREAM -- -s 51882 -m 32K -M 32K
                     netperf -l 100 -t TCP_STREAM -- -m 32K -M 32K

          Baseline  AF_UNIX      Friends
   N  COC Mbits/S   Mbits/S      Mbits/S
   1   -    8616      9416 109%   11116 129% 118%
   2   -   15419     17076 111%   20267 131% 119%
  16   2   59497    303029 509%  347349 584% 115%
  32   4   54223    273637 505%  272891 503% 100%
 256  32   58244     85476 147%  273696 470% 320%
 512  64   58745     87402 149%  260837 444% 298%
1600 200   83161    158915 191%  383947 462% 242%

COC = Cpu Over Commit ratio (16 core platform)

Stream: netperf -l 100 -t TCP_STREAM
        netperf -l 100 -t STREAM_STREAM -- -s 51882
        netperf -l 100 -t TCP_STREAM

netperf  Baseline  AF_UNIX      Friends
-m/-M N  Mbits/S   Mbits/S      Mbits/S
  64       1020       445  44%     515  50% 116%
  1K       4881      4340  89%    5070 104% 117%
  8K       5933      8387 141%    9770 165% 116%
 32K       8168      9538 117%   11067 135% 116%
 64K       9116      9774 107%   11515 126% 118%
128K       9053     10044 111%   13082 145% 130%
256K       9642     10351 107%   13470 140% 130%
512K      10050     10142 101%   13327 133% 131%
  1M       8640      9843 114%   12201 141% 124%
 16M       7179      9619 134%   11316 158% 118%

Rr: netperf -l 100 -t TCP_RR
    netperf -l 100 -t STREAM_RR -- -s 51882 -m 16384 -M 87380
    netperf -l 100 -t TCP_RR

netperf  Baseline  AF_UNIX      Friends
-r N,N   Trans./S  Trans./S     Trans./S
  64      47913     99681 208%   98225 205%  99%
  1K      44045     92327 210%   91608 208%  99%
  8K      26732     33201 124%   33025 124%  99%
 32K      10903     11972 110%   13574 124% 113%
 64K       7113      6718  94%    7176 101% 107%
128K       4191      3431  82%    3695  88% 108%
256K       2324      1937  83%    2147  92% 111%
512K        958      1056 110%    1202 125% 114%
  1M        404       508 126%     497 123%  98%
 16M       26.1      34.1 131%    32.9 126%  96%

Crr: netperf -l 100 -t TCP_CRR
     netperf -l 100 -t TCP_CRR

netperf  Baseline  AF_UNIX      Friends
  -r N   Trans./S  Trans./S     Trans./S
  64      14690         -        18191 124%   -
  1K      14258         -        17492 123%   -
  8K      11535         -        14012 121%   -
 32K       7035         -         8974 128%   -
 64K       4312         -         5654 131%   -
128K       2252         -         3179 141%   -
256K       1237         -         2008 162%   -
512K       17.5*        -         1079   ?    -
  1M       4.93*        -          458   ?    -
 16M       8.29*        -         32.5   ?    -

Note, "-" denotes test not supported for transport.
      "*" denotes test results reported without statistical confidence.
      "?" denotes results not comparable.

SPLICE 32KB I/O:

Source
 Sink   Baseline  Friends
 FSFS   Mbits/S   Mbits/S
 ----     8042     10810 134%
 Z---     7071      9773 138%
 --N-     8039     10820 135%
 Z-N-     7902      9796 124%
 -S--    17326     37496 216%
 ZS--     9008      9573 106%
 -SN-    16154     36269 225%
 ZSN-     9531      9640 101%
 ---S     8466      9933 117%
 Z--S     8000      9453 118%
 --NS    12783     11379  89%
 Z-NS    11055      9489  86%
 -S-S    12741     24380 191%
 ZS-S     8097     10242 126%
 -SNS    16657     30954 186%
 ZSNS    12108     12763 105%

Note, "Z" source File /dev/zero, "-" source user memory
      "N" sink File /dev/null, "-" sink user memory
      "S" Splice on, "-" Splice off

Note from Tao Ma:
1. rebase to 2.6.32-358.14.1
2. fix a bug when syncookies are used.

Signed-off-by: Bruce \"Brutus\" Curtis <brutus@google.com>
Signed-off-by: Li Yu <bingtian.ly@taobao.com>
Signed-off-by: Zhu Yanhai <gaoyang.zyh@taobao.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Merge pull request #37 from taoma-tm/tcp_friends

tcp friends
Merge pull request #36 from 4tar/dev

Fix a issue which causes subtree based dir quota not to work.

[Note from Zheng Liu]
The lesson from this is that never touch the code which has running on thousands of servers. :(
memcg: add drop_caches interface

We drop caches by traversing memcg's local lru to invalidate pages. Now it
only supports drop file caches, since slab is not accounted in memcg under
this version.

Signed-off-by: Sha Zhengju <handai.szj@taobao.com>
Add gitignore.

Signed-off-by: Tao Ma <boyu.mt@taobao.com>
ext4: fix potential deadlock in ext4_nonda_switch()

In ext4_nonda_switch(), if the file system is getting full we used to
call writeback_inodes_sb_if_idle().  The problem is that we can be
holding i_mutex already, and this causes a potential deadlock when
writeback_inodes_sb_if_idle() when it tries to take s_umount.  (See
lockdep output below).

As it turns out we don't need need to hold s_umount; the fact that we
are in the middle of the write(2) system call will keep the superblock
pinned.  Unfortunately writeback_inodes_sb() checks to make sure
s_umount is taken, and the VFS uses a different mechanism for making
sure the file system doesn't get unmounted out from under us.  The
simplest way of dealing with this is to just simply grab s_umount
using a trylock, and skip kicking the writeback flusher thread in the
very unlikely case that we can't take a read lock on s_umount without
blocking.

Also, we now check the cirteria for kicking the writeback thread
before we decide to whether to fall back to non-delayed writeback, so
if there are any outstanding delayed allocation writes, we try to get
them resolved as soon as possible.

   [ INFO: possible circular locking dependency detected ]
   3.6.0-rc1-00042-gce894ca #367 Not tainted
   -------------------------------------------------------
   dd/8298 is trying to acquire lock:
    (&type->s_umount_key#18){++++..}, at: [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46

   but task is already holding lock:
    (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3

   which lock already depends on the new lock.

   2 locks held by dd/8298:
    #0:  (sb_writers#2){.+.+.+}, at: [<c01ddcc5>] generic_file_aio_write+0x56/0xd3
    #1:  (&sb->s_type->i_mutex_key#8){+.+...}, at: [<c01ddcce>] generic_file_aio_write+0x5f/0xd3

   stack backtrace:
   Pid: 8298, comm: dd Not tainted 3.6.0-rc1-00042-gce894ca #367
   Call Trace:
    [<c015b79c>] ? console_unlock+0x345/0x372
    [<c06d62a1>] print_circular_bug+0x190/0x19d
    [<c019906c>] __lock_acquire+0x86d/0xb6c
    [<c01999db>] ? mark_held_locks+0x5c/0x7b
    [<c0199724>] lock_acquire+0x66/0xb9
    [<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
    [<c06db935>] down_read+0x28/0x58
    [<c02277d4>] ? writeback_inodes_sb_if_idle+0x28/0x46
    [<c02277d4>] writeback_inodes_sb_if_idle+0x28/0x46
    [<c026f3b2>] ext4_nonda_switch+0xe1/0xf4
    [<c0271ece>] ext4_da_write_begin+0x27/0x193
    [<c01dcdb0>] generic_file_buffered_write+0xc8/0x1bb
    [<c01ddc47>] __generic_file_aio_write+0x1dd/0x205
    [<c01ddce7>] generic_file_aio_write+0x78/0xd3
    [<c026d336>] ext4_file_write+0x480/0x4a6
    [<c0198c1d>] ? __lock_acquire+0x41e/0xb6c
    [<c0180944>] ? sched_clock_cpu+0x11a/0x13e
    [<c01967e9>] ? trace_hardirqs_off+0xb/0xd
    [<c018099f>] ? local_clock+0x37/0x4e
    [<c0209f2c>] do_sync_write+0x67/0x9d
    [<c0209ec5>] ? wait_on_retry_sync_kiocb+0x44/0x44
    [<c020a7b9>] vfs_write+0x7b/0xe6
    [<c020a9a6>] sys_write+0x3b/0x64
    [<c06dd4bd>] syscall_call+0x7/0xb

Reference: 00d4e7362ed01987183e9528295de3213031309c
Patch-in-mainline: v3.6-rc1-40-g00d4e73
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Cc: stable@vger.kernel.org
ext4: undo ext4_calc_metadata_amount if we fail to claim space

The function ext4_calc_metadata_amount() has side effects, although
it's not obvious from its function name.  So if we fail to claim
space, regardless of whether we retry to claim the space again, or
return an error, we need to undo these side effects.

Otherwise we can end up incorrectly calculating the number of metadata
blocks needed for the operation, which was responsible for an xfstests
failure for test #271 when using an ext2 file system with delalloc
enabled.

Reference: 03179fe92318e7934c180d96f12eff2cb36ef7b6
Patch-in-mainline: v3.5-rc5-23-g03179fe92318
Reported-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Cc: stable@vger.kernel.org
ext4: Fix deadlock when writing in ENOSPC conditions

Akira-san has been reporting rare deadlocks of his machine when running
xfstests test 269 on ext4 filesystem. The problem turned out to be in
ext4_da_reserve_metadata() and ext4_da_reserve_space() which called
ext4_should_retry_alloc() while holding i_data_sem. Since
ext4_should_retry_alloc() can force a transaction commit, this is a
lock ordering violation and leads to deadlocks.

Fix the problem by just removing the retry loops. These functions should
just report ENOSPC to the caller (e.g. ext4_da_write_begin()) and that
function must take care of retrying after dropping all necessary locks.

Reported-and-tested-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
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>
Merge pull request #38 from RobinDong/dev

add quota for flashcache
Allow 8021q device to be created in no-root network namespace