linux-toradex.git/fs/ext4, branch v3.0.71

ext4: fix the wrong number of the allocated blocks in ext4_split_extent()

2013-03-28T19:06:03+00:00

commit 3a2256702e47f68f921dfad41b1764d05c572329 upstream.

This commit fixes a wrong return value of the number of the allocated
blocks in ext4_split_extent.  When the length of blocks we want to
allocate is greater than the length of the current extent, we return a
wrong number.  Let's see what happens in the following case when we
call ext4_split_extent().

  map: [48, 72]
  ex:  [32, 64, u]

'ex' will be split into two parts:
  ex1: [32, 47, u]
  ex2: [48, 64, w]

'map->m_len' is returned from this function, and the value is 24.  But
the real length is 16.  So it should be fixed.

Meanwhile in this commit we use right length of the allocated blocks
when get_reserved_cluster_alloc in ext4_ext_handle_uninitialized_extents
is called.

Signed-off-by: Zheng Liu 
Signed-off-by: "Theodore Ts'o" 
Cc: Dmitry Monakhov 
Signed-off-by: Greg Kroah-Hartman

ext4: fix race in ext4_mb_add_n_trim()

2013-03-03T22:09:05+00:00

commit f1167009711032b0d747ec89a632a626c901a1ad upstream.

In ext4_mb_add_n_trim(), lg_prealloc_lock should be taken when
changing the lg_prealloc_list.

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

ext4: add missing kfree() on error return path in add_new_gdb()

2013-02-28T14:32:25+00:00

commit c49bafa3842751b8955a962859f42d307673d75d upstream.

We added some more error handling in b40971426a "ext4: add error
checking to calls to ext4_handle_dirty_metadata()".  But we need to
call kfree() as well to avoid a memory leak.

Signed-off-by: Dan Carpenter 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Jeff Mahoney 
Signed-off-by: Greg Kroah-Hartman

ext4: Free resources in some error path in ext4_fill_super

2013-02-28T14:32:25+00:00

commit dcf2d804ed6ffe5e942b909ed5e5b74628be6ee4 upstream.

Some of the error path in ext4_fill_super don't release the
resouces properly. So this patch just try to release them
in the right way.

Signed-off-by: Tao Ma 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Jeff Mahoney 
Signed-off-by: Greg Kroah-Hartman

ext4: init pagevec in ext4_da_block_invalidatepages

2013-01-21T19:44:59+00:00

commit 66bea92c69477a75a5d37b9bfed5773c92a3c4b4 upstream.

ext4_da_block_invalidatepages is missing a pagevec_init(),
which means that pvec->cold contains random garbage.

This affects whether the page goes to the front or
back of the LRU when ->cold makes it to
free_hot_cold_page()

Reviewed-by: Lukas Czerner 
Reviewed-by: Carlos Maiolino 
Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: CAI Qian 
Signed-off-by: Greg Kroah-Hartman

ext4: lock i_mutex when truncating orphan inodes

2013-01-17T16:43:57+00:00

commit 721e3eba21e43532e438652dd8f1fcdfce3187e7 upstream.

Commit c278531d39 added a warning when ext4_flush_unwritten_io() is
called without i_mutex being taken.  It had previously not been taken
during orphan cleanup since races weren't possible at that point in
the mount process, but as a result of this c278531d39, we will now see
a kernel WARN_ON in this case.  Take the i_mutex in
ext4_orphan_cleanup() to suppress this warning.

Reported-by: Alexander Beregalov 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Zheng Liu 
Signed-off-by: Greg Kroah-Hartman

ext4: do not try to write superblock on ro remount w/o journal

2013-01-17T16:43:57+00:00

commit d096ad0f79a782935d2e06ae8fb235e8c5397775 upstream.

When a journal-less ext4 filesystem is mounted on a read-only block
device (blockdev --setro will do), each remount (for other, unrelated,
flags, like suid=>nosuid etc) results in a series of scary messages
from kernel telling about I/O errors on the device.

This is becauese of the following code ext4_remount():

       if (sbi->s_journal == NULL)
                ext4_commit_super(sb, 1);

at the end of remount procedure, which forces writing (flushing) of
a superblock regardless whenever it is dirty or not, if the filesystem
is readonly or not, and whenever the device itself is readonly or not.

We only need call ext4_commit_super when the file system had been
previously mounted read/write.

Thanks to Eric Sandeen for help in diagnosing this issue.

Signed-off-By: Michael Tokarev 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: fix extent tree corruption caused by hole punch

2013-01-17T16:43:57+00:00

commit c36575e663e302dbaa4d16b9c72d2c9a913a9aef upstream.

When depth of extent tree is greater than 1, logical start value of
interior node is not correctly updated in ext4_ext_rm_idx.

Signed-off-by: Forrest Liu 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Ashish Sangwan 
Signed-off-by: Greg Kroah-Hartman

ext4: fix memory leak in ext4_xattr_set_acl()'s error path

2013-01-17T16:43:55+00:00

commit 24ec19b0ae83a385ad9c55520716da671274b96c upstream.

In ext4_xattr_set_acl(), if ext4_journal_start() returns an error,
posix_acl_release() will not be called for 'acl' which may result in a
memory leak.

This patch fixes that.

Reviewed-by: Lukas Czerner 
Signed-off-by: Eugene Shatokhin 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: fix fdatasync() for files with only i_size changes

2012-10-12T20:28:10+00:00

commit b71fc079b5d8f42b2a52743c8d2f1d35d655b1c5 upstream.

Code tracking when transaction needs to be committed on fdatasync(2) forgets
to handle a situation when only inode's i_size is changed. Thus in such
situations fdatasync(2) doesn't force transaction with new i_size to disk
and that can result in wrong i_size after a crash.

Fix the issue by updating inode's i_datasync_tid whenever its size is
updated.

Reported-by: Kristian Nielsen 
Signed-off-by: Jan Kara 
Signed-off-by: Greg Kroah-Hartman