linux-toradex.git/fs/ext4, branch v2.6.34.11

ext4: fix credits computing for indirect mapped files

2012-03-14T14:57:08+00:00

commit 5b41395fcc0265fc9f193aef9df39ce49d64677c upstream.

When writing a contiguous set of blocks, two indirect blocks could be
needed depending on how the blocks are aligned, so we need to increase
the number of credits needed by one.

[ Also fixed a another bug which could further underestimate the
  number of journal credits needed by 1; the code was using integer
  division instead of DIV_ROUND_UP() -- tytso]

Signed-off-by: Yongqiang Yang 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker

ext4: Fix remaining racy updates of EXT4_I(inode)->i_flags

2011-01-06T23:08:01+00:00

commit 84a8dce2710cc425089a2b92acc354d4fbb5788d upstream.

A few functions were still modifying i_flags in a racy manner.

Signed-off-by: Dmitry Monakhov 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker

ext4: fix freeze deadlock under IO

2011-01-06T23:07:38+00:00

commit 437f88cc031ffe7f37f3e705367f4fe1f4be8b0f upstream.
[The 6b0310fb below references the mainline version of what
has also been cherry picked into this 34-stable branch]

Commit 6b0310fbf087ad6 caused a regression resulting in deadlocks
when freezing a filesystem which had active IO; the vfs_check_frozen
level (SB_FREEZE_WRITE) did not let the freeze-related IO syncing
through.  Duh.

Changing the test to FREEZE_TRANS should let the normal freeze
syncing get through the fs, but still block any transactions from
starting once the fs is completely frozen.

I tested this by running fsstress in the background while periodically
snapshotting the fs and running fsck on the result.  I ran into
occasional deadlocks, but different ones.  I think this is a
fine fix for the problem at hand, and the other deadlocky things
will need more investigation.

Reported-by: Phillip Susi 
Signed-off-by: Eric Sandeen 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker

ext4: Make fsync sync new parent directories in no-journal mode

2011-01-06T23:07:38+00:00

commit 14ece1028b3ed53ffec1b1213ffc6acaf79ad77c upstream.

Add a new ext4 state to tell us when a file has been newly created; use
that state in ext4_sync_file in no-journal mode to tell us when we need
to sync the parent directory as well as the inode and data itself.  This
fixes a problem in which a panic or power failure may lose the entire
file even when using fsync, since the parent directory entry is lost.

Addresses-Google-Bug: #2480057

Signed-off-by: Frank Mayhar 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker

ext4: Fix compat EXT4_IOC_ADD_GROUP

2011-01-06T23:07:37+00:00

commit 4d92dc0f00a775dc2e1267b0e00befb783902fe7 upstream.

struct ext4_new_group_input needs to be converted because u64 has
only 32-bit alignment on some 32-bit architectures, notably i386.

Signed-off-by: Ben Hutchings 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker

ext4: Conditionally define compat ioctl numbers

2011-01-06T23:07:37+00:00

commit 899ad0cea6ad7ff4ba24b16318edbc3cbbe03fad upstream.

It is unnecessary, and in general impossible, to define the compat
ioctl numbers except when building the filesystem with CONFIG_COMPAT
defined.

Signed-off-by: Ben Hutchings 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker

ext4: restart ext4_ext_remove_space() after transaction restart

2011-01-06T23:07:37+00:00

commit 0617b83fa239db9743a18ce6cc0e556f4d0fd567 upstream.

If i_data_sem was internally dropped due to transaction restart, it is
necessary to restart path look-up because extents tree was possibly
modified by ext4_get_block().

https://bugzilla.kernel.org/show_bug.cgi?id=15827

Signed-off-by: Dmitry Monakhov 
Signed-off-by: "Theodore Ts'o" 
Acked-by: Jan Kara 
Signed-off-by: Paul Gortmaker

ext4: Clear the EXT4_EOFBLOCKS_FL flag only when warranted

2011-01-06T23:07:37+00:00

commit 786ec7915e530936b9eb2e3d12274145cab7aa7d upstream.

Dimitry Monakhov discovered an edge case where it was possible for the
EXT4_EOFBLOCKS_FL flag could get cleared unnecessarily.  This is true;
I have a test case that can be exercised via downloading and
decompressing the file:

wget ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-testcases/eofblocks-fl-test-case.img.bz2
bunzip2 eofblocks-fl-test-case.img
dd if=/dev/zero of=eofblocks-fl-test-case.img bs=1k seek=17925 bs=1k count=1 conv=notrunc

However, triggering it in real life is highly unlikely since it
requires an extremely fragmented sparse file with a hole in exactly
the right place in the extent tree.  (It actually took quite a bit of
work to generate this test case.)  Still, it's nice to get even
extreme corner cases to be correct, so this patch makes sure that we
don't clear the EXT4_EOFBLOCKS_FL incorrectly even in this corner
case.

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

ext4: Avoid crashing on NULL ptr dereference on a filesystem error

2011-01-06T23:07:37+00:00

commit f70f362b4a6fe47c239dbfb3efc0cc2c10e4f09c upstream.

If the EOFBLOCK_FL flag is set when it should not be and the inode is
zero length, then eh_entries is zero, and ex is NULL, so dereferencing
ex to print ex->ee_block causes a kernel OOPS in
ext4_ext_map_blocks().

On top of that, the error message which is printed isn't very helpful.
So we fix this by printing something more explanatory which doesn't
involve trying to print ex->ee_block.

Addresses-Google-Bug: #2655740

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

ext4: Use bitops to read/modify i_flags in struct ext4_inode_info

2011-01-06T23:07:36+00:00

commit 12e9b892002d9af057655d35b44db8ee9243b0dc upstream.

At several places we modify EXT4_I(inode)->i_flags without holding
i_mutex (ext4_do_update_inode, ...). These modifications are racy and
we can lose updates to i_flags. So convert handling of i_flags to use
bitops which are atomic.

https://bugzilla.kernel.org/show_bug.cgi?id=15792

Signed-off-by: Dmitry Monakhov 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Paul Gortmaker