linux-stable.git/fs/ext4/resize.c, branch linux-3.9.y

ext4: fix corruption when online resizing a fs with 1K block size

2013-07-21T00:16:06+00:00

commit 6ca792edc13c409e8d4eb9001e048264c6a2eb64 upstream.

Subtracting the number of the first data block places the superblock
backups one block too early, corrupting the file system. When the block
size is larger than 1K, the first data block is 0, so the subtraction
has no effect and no corruption occurs.

Signed-off-by: Maarten ter Huurne 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman

ext4: add check for inodes_count overflow in new resize ioctl

2013-05-11T14:18:22+00:00

commit 3f8a6411fbada1fa482276591e037f3b1adcf55b upstream.

Addresses-Red-Hat-Bugzilla: #913245

Reported-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Carlos Maiolino 
Signed-off-by: Lingzhu Xiang 
Signed-off-by: Greg Kroah-Hartman

ext4: fix online resizing for ext3-compat file systems

2013-05-08T03:33:14+00:00

commit c5c72d814cf0f650010337c73638b25e6d14d2d4 upstream.

Commit fb0a387dcdc restricts block allocations for indirect-mapped
files to block groups less than s_blockfile_groups.  However, the
online resizing code wasn't setting s_blockfile_groups, so the newly
added block groups were not available for non-extent mapped files.

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

ext4: use atomic64_t for the per-flexbg free_clusters count

2013-03-12T03:39:59+00:00

A user who was using a 8TB+ file system and with a very large flexbg
size (> 65536) could cause the atomic_t used in the struct flex_groups
to overflow.  This was detected by PaX security patchset:

http://forums.grsecurity.net/viewtopic.php?f=3&t=3289&p=12551#p12551

This bug was introduced in commit 9f24e4208f7e, so it's been around
since 2.6.30.  :-(

Fix this by using an atomic64_t for struct orlav_stats's
free_clusters.

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Lukas Czerner 
Cc: stable@vger.kernel.org

ext4: convert number of blocks to clusters properly

2013-03-02T22:18:58+00:00

We're using macro EXT4_B2C() to convert number of blocks to number of
clusters for bigalloc file systems.  However, we should be using
EXT4_NUM_B2C().

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org

ext4: pass context information to jbd2__journal_start()

2013-02-09T02:59:22+00:00

So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.

The recommended way for finding the longer-running handles is:

   T=/sys/kernel/debug/tracing
   EVENT=$T/events/jbd2/jbd2_handle_stats
   echo "interval > 5" > $EVENT/filter
   echo 1 > $EVENT/enable

   ./run-my-fs-benchmark

   cat $T/trace > /tmp/problem-handles

This will list handles that were active for longer than 20ms.  Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation.  Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:

postmark-2917  [000] ....   196.435786: jbd2_handle_stats: dev 254,32 
   tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
   dirtied_blocks 0

Signed-off-by: "Theodore Ts'o"

ext4: trigger the lazy inode table initialization after resize

2013-01-13T13:41:45+00:00

After we have finished extending the file system, we need to trigger a
the lazy inode table thread to zero out the inode tables.

Signed-off-by: "Theodore Ts'o"

ext4: use unlikely to improve the efficiency of the kernel

2013-01-12T21:28:47+00:00

Because the function 'sb_getblk' seldomly fails to return NULL
value,it will be better to use 'unlikely' to optimize it.

Signed-off-by: Wang Shilong 
Signed-off-by: "Theodore Ts'o"

ext4: return ENOMEM if sb_getblk() fails

2013-01-12T21:19:36+00:00

The only reason for sb_getblk() failing is if it can't allocate the
buffer_head.  So ENOMEM is more appropriate than EIO.  In addition,
make sure that the file system is marked as being inconsistent if
sb_getblk() fails.

Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org

ext4: remove ext4_handle_release_buffer()

2012-11-08T16:22:46+00:00

ext4_handle_release_buffer() was intended to remove journal
write access from a buffer, but it doesn't actually do anything
at all other than add a BUFFER_TRACE point, but it's not reliably
used for that either.  Remove all the associated dead code.

Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Carlos Maiolino