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
netpoll: Don't stop br_add_if because of netpoll.

Don't stop br_add_if and bonding if there are at least one
device support netpoll. Now even if br_netpoll_enable returns
error, we will go with success.

also, initilize np->dev_name so that we can print out the error
dev name if netpoll is not support.ed

Signed-off-by: Tao Ma <boyu.mt@taobao.com>
kmsg_dump: enable kmsg_dump by default.

netoops is triggered by kmsg_dump. But now we don't output
anything in default. So this patch make default to be yes
so that we can trigger netoops in case of kernel panic.

Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Merge pull request #40 from taoma-tm/netoops_support

Netoops support
Fix the issue of being unable to compile ipmi_si/ipmi_msghandler as module

The RH 6.4 tree introduced some changes to ipmi which created loop dependence
between ipmi_si and ipmi_msghandler, and in turn broke them from compiling as
modules.  However, our AliOS env are still sticking to 5u7 or 6u2 which needs
these 2 modules.

Fix it by some code moving and symbol exporting in these 2 modules.

Signed-off-by: Huang Le <le.hl@alibaba-inc.com>
Remove the obsolete link file.

Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Merge pull request #42 from 4tar/dev

Fix the issue of being unable to compile ipmi_si/ipmi_msghandler as module
Update KGTP version to 20131220.