linux-toradex.git/fs, branch v3.15.6

f2fs: check bdi->dirty_exceeded when trying to skip data writes

2014-07-17T23:23:19+00:00

commit 2743f865543c0c4a5e12fc13edb2bf89a6e9687c upstream.

If we don't check the current backing device status, balance_dirty_pages can
fall into infinite pausing routine.

This can be occurred when a lot of directories make a small number of dirty
dentry pages including files.

Reported-by: Brian Chadwick 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Greg Kroah-Hartman

f2fs: adjust free mem size to flush dentry blocks

2014-07-17T23:23:19+00:00

commit 6fb03f3a40805a412c9b285010ffdc2e7563f81b upstream.

If so many dirty dentry blocks are cached, not reached to the flush condition,
we should fall into livelock in balance_dirty_pages.
So, let's consider the mem size for the condition.

Signed-off-by: Jaegeuk Kim 
Signed-off-by: Greg Kroah-Hartman

kernfs: introduce kernfs_pin_sb()

2014-07-17T23:23:19+00:00

commit 4e26445faad366d67d7723622bf6a60a6f0f5993 upstream.

kernfs_pin_sb() tries to get a refcnt of the superblock.

This will be used by cgroupfs.

v2:
- make kernfs_pin_sb() return the superblock.
- drop kernfs_drop_sb().

tj: Updated the comment a bit.

[ This is a prerequisite for a bugfix. ]
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

kernfs: implement kernfs_root->supers list

2014-07-17T23:23:19+00:00

commit 7d568a8383bbb9c1f5167781075906acb2bb1550 upstream.

Currently, there's no way to find out which super_blocks are
associated with a given kernfs_root.  Let's implement it - the planned
inotify extension to kernfs_notify() needs it.

Make kernfs_super_info point back to the super_block and chain it at
kernfs_root->supers.

Signed-off-by: Tejun Heo 
[lizf: Backported to 3.15: Adjust context]
Signed-off-by: Li Zefan 
Signed-off-by: Greg Kroah-Hartman

ext4: fix a potential deadlock in __ext4_es_shrink()

2014-07-17T23:23:16+00:00

commit 3f1f9b851311a76226140b55b1ea22111234a7c2 upstream.

This fixes the following lockdep complaint:

[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G           O
-------------------------------------------------------
kworker/u24:0/4356 is trying to acquire lock:
 (&(&sbi->s_es_lru_lock)->rlock){+.+.-.}, at: [] __ext4_es_shrink+0x4f/0x2e0

but task is already holding lock:
 (&ei->i_es_lock){++++-.}, at: [] ext4_es_insert_extent+0x71/0x180

which lock already depends on the new lock.

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&ei->i_es_lock);
                               lock(&(&sbi->s_es_lru_lock)->rlock);
                               lock(&ei->i_es_lock);
  lock(&(&sbi->s_es_lru_lock)->rlock);

 *** DEADLOCK ***

6 locks held by kworker/u24:0/4356:
 #0:  ("writeback"){.+.+.+}, at: [] process_one_work+0x180/0x560
 #1:  ((&(&wb->dwork)->work)){+.+.+.}, at: [] process_one_work+0x180/0x560
 #2:  (&type->s_umount_key#22){++++++}, at: [] grab_super_passive+0x44/0x90
 #3:  (jbd2_handle){+.+...}, at: [] start_this_handle+0x189/0x5f0
 #4:  (&ei->i_data_sem){++++..}, at: [] ext4_map_blocks+0x132/0x550
 #5:  (&ei->i_es_lock){++++-.}, at: [] ext4_es_insert_extent+0x71/0x180

stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G           O   3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
 ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007
 ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568
 ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930
Call Trace:
 [] dump_stack+0x4e/0x68
 [] print_circular_bug+0x1fb/0x20c
 [] __lock_acquire+0x163e/0x1d00
 [] ? retint_restore_args+0xe/0xe
 [] ? __slab_alloc+0x4a8/0x4ce
 [] ? __ext4_es_shrink+0x4f/0x2e0
 [] lock_acquire+0x87/0x120
 [] ? __ext4_es_shrink+0x4f/0x2e0
 [] ? ext4_es_free_extent+0x5d/0x70
 [] _raw_spin_lock+0x39/0x50
 [] ? __ext4_es_shrink+0x4f/0x2e0
 [] ? kmem_cache_alloc+0x18b/0x1a0
 [] __ext4_es_shrink+0x4f/0x2e0
 [] ext4_es_insert_extent+0xc8/0x180
 [] ext4_map_blocks+0x1c4/0x550
 [] ext4_writepages+0x6d4/0xd00
	...

Reported-by: Minchan Kim 
Signed-off-by: Theodore Ts'o 
Reported-by: Minchan Kim 
Cc: Zheng Liu 
Signed-off-by: Greg Kroah-Hartman

ext4: revert commit which was causing fs corruption after journal replays

2014-07-17T23:23:16+00:00

commit f9ae9cf5d72b3926ca48ea60e15bdbb840f42372 upstream.

Commit 007649375f6af2 ("ext4: initialize multi-block allocator before
checking block descriptors") causes the block group descriptor's count
of the number of free blocks to become inconsistent with the number of
free blocks in the allocation bitmap.  This is a harmless form of fs
corruption, but it causes the kernel to potentially remount the file
system read-only, or to panic, depending on the file systems's error
behavior.

Thanks to Eric Whitney for his tireless work to reproduce and to find
the guilty commit.

Fixes: 007649375f6af2 ("ext4: initialize multi-block allocator before checking block descriptors"

Reported-by: David Jander 
Reported-by: Matteo Croce 
Tested-by: Eric Whitney 
Suggested-by: Eric Whitney 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: disable synchronous transaction batching if max_batch_time==0

2014-07-17T23:23:16+00:00

commit 5dd214248f94d430d70e9230bda72f2654ac88a8 upstream.

The mount manpage says of the max_batch_time option,

	This optimization can be turned off entirely
	by setting max_batch_time to 0.

But the code doesn't do that.  So fix the code to do
that.

Signed-off-by: Eric Sandeen 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()

2014-07-17T23:23:15+00:00

commit 94d4c066a4ff170a2671b1a9b153febbf36796f6 upstream.

We are spending a lot of time explaining to users what this error
means.  Let's try to improve the message to avoid this problem.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman

ext4: clarify error count warning messages

2014-07-17T23:23:15+00:00

commit ae0f78de2c43b6fadd007c231a352b13b5be8ed2 upstream.

Make it clear that values printed are times, and that it is error
since last fsck. Also add note about fsck version required.

Signed-off-by: Pavel Machek 
Signed-off-by: Theodore Ts'o 
Reviewed-by: Andreas Dilger 
Signed-off-by: Greg Kroah-Hartman

ext4: fix unjournalled bg descriptor while initializing inode bitmap

2014-07-17T23:23:15+00:00

commit 61c219f5814277ecb71d64cb30297028d6665979 upstream.

The first time that we allocate from an uninitialized inode allocation
bitmap, if the block allocation bitmap is also uninitalized, we need
to get write access to the block group descriptor before we start
modifying the block group descriptor flags and updating the free block
count, etc.  Otherwise, there is the potential of a bad journal
checksum (if journal checksums are enabled), and of the file system
becoming inconsistent if we crash at exactly the wrong time.

Signed-off-by: Theodore Ts'o 
Signed-off-by: Greg Kroah-Hartman