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

ext4: init pagevec in ext4_da_block_invalidatepages

2013-01-21T19:44:34+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: release buffer in failed path in dx_probe()

2013-01-17T16:46:23+00:00

commit 0ecaef0644973e9006fdbc6974301047aaff9bc6 upstream.

If checksum fails, we should also release the buffer
read from previous iteration.

Signed-off-by: Guo Chao 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: "Darrick J. Wong" 
Signed-off-by: Greg Kroah-Hartman

ext4: avoid hang when mounting non-journal filesystems with orphan list

2013-01-17T16:46:23+00:00

commit 0e9a9a1ad619e7e987815d20262d36a2f95717ca upstream.

When trying to mount a file system which does not contain a journal,
but which does have a orphan list containing an inode which needs to
be truncated, the mount call with hang forever in
ext4_orphan_cleanup() because ext4_orphan_del() will return
immediately without removing the inode from the orphan list, leading
to an uninterruptible loop in kernel code which will busy out one of
the CPU's on the system.

This can be trivially reproduced by trying to mount the file system
found in tests/f_orphan_extents_inode/image.gz from the e2fsprogs
source tree.  If a malicious user were to put this on a USB stick, and
mount it on a Linux desktop which has automatic mounts enabled, this
could be considered a potential denial of service attack.  (Not a big
deal in practice, but professional paranoids worry about such things,
and have even been known to allocate CVE numbers for such problems.)

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

ext4: lock i_mutex when truncating orphan inodes

2013-01-17T16:46:23+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:46:23+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: check dioread_nolock on remount

2013-01-17T16:46:23+00:00

commit 261cb20cb2f0737a247aaf08dff7eb065e3e5b66 upstream.

Currently we allow enabling dioread_nolock mount option on remount for
filesystems where blocksize < PAGE_CACHE_SIZE.  This isn't really
supported so fix the bug by moving the check for blocksize !=
PAGE_CACHE_SIZE into parse_options(). Change the original PAGE_SIZE to
PAGE_CACHE_SIZE along the way because that's what we are really
interested in.

Signed-off-by: Jan Kara 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Eric Sandeen 
Signed-off-by: Greg Kroah-Hartman

ext4: fix extent tree corruption caused by hole punch

2013-01-17T16:46:22+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 possible use after free with metadata csum

2013-01-17T16:45:59+00:00

commit aeb1e5d69a5be592e86a926be73efb38c55af404 upstream.

Commit fa77dcfafeaa introduces block bitmap checksum calculation into
ext4_new_inode() in the case that block group was uninitialized.
However we brelse() the bitmap buffer before we attempt to checksum it
so we have no guarantee that the buffer is still there.

Fix this by releasing the buffer after the possible checksum
computation.

Signed-off-by: Lukas Czerner 
Signed-off-by: "Theodore Ts'o" 
Acked-by: Darrick J. Wong 
Signed-off-by: Greg Kroah-Hartman

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

2013-01-17T16:45:59+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 unjournaled inode bitmap modification

2012-10-29T02:24:57+00:00

commit 119c0d4460b001e44b41dcf73dc6ee794b98bd31 changed
ext4_new_inode() such that the inode bitmap was being modified
outside a transaction, which could lead to corruption, and was
discovered when journal_checksum found a bad checksum in the
journal during log replay.

Nix ran into this when using the journal_async_commit mount
option, which enables journal checksumming.  The ensuing
journal replay failures due to the bad checksums led to
filesystem corruption reported as the now infamous
"Apparent serious progressive ext4 data corruption bug"

[ Changed by tytso to only call ext4_journal_get_write_access() only
  when we're fairly certain that we're going to allocate the inode. ]

I've tested this by mounting with journal_checksum and
running fsstress then dropping power; I've also tested by
hacking DM to create snapshots w/o first quiescing, which
allows me to test journal replay repeatedly w/o actually
power-cycling the box.  Without the patch I hit a journal
checksum error every time.  With this fix it survives
many iterations.

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