linux-toradex.git, branch v2.6.32.1

Linux 2.6.32.1

2009-12-14T17:47:25+00:00

ext4: Fix potential fiemap deadlock (mmap_sem vs. i_data_sem)

2009-12-14T17:45:28+00:00

(cherry picked from commit fab3a549e204172236779f502eccb4f9bf0dc87d)

Fix the following potential circular locking dependency between
mm->mmap_sem and ei->i_data_sem:

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.32-04115-gec044c5 #37
    -------------------------------------------------------
    ureadahead/1855 is trying to acquire lock:
     (&mm->mmap_sem){++++++}, at: [] might_fault+0x5c/0xac

    but task is already holding lock:
     (&ei->i_data_sem){++++..}, at: [] ext4_fiemap+0x11b/0x159

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&ei->i_data_sem){++++..}:
           [] __lock_acquire+0xb67/0xd0f
           [] lock_acquire+0xdc/0x102
           [] down_read+0x51/0x84
           [] ext4_get_blocks+0x50/0x2a5
           [] ext4_get_block+0xab/0xef
           [] do_mpage_readpage+0x198/0x48d
           [] mpage_readpages+0xd0/0x114
           [] ext4_readpages+0x1d/0x1f
           [] __do_page_cache_readahead+0x12f/0x1bc
           [] ra_submit+0x21/0x25
           [] filemap_fault+0x19f/0x32c
           [] __do_fault+0x55/0x3a2
           [] handle_mm_fault+0x327/0x734
           [] do_page_fault+0x292/0x2aa
           [] page_fault+0x25/0x30
           [] clear_user+0x38/0x3c
           [] padzero+0x20/0x31
           [] load_elf_binary+0x8bc/0x17ed
           [] search_binary_handler+0xc2/0x259
           [] load_script+0x1b8/0x1cc
           [] search_binary_handler+0xc2/0x259
           [] do_execve+0x1ce/0x2cf
           [] sys_execve+0x43/0x5a
           [] stub_execve+0x6a/0xc0

    -> #0 (&mm->mmap_sem){++++++}:
           [] __lock_acquire+0xa11/0xd0f
           [] lock_acquire+0xdc/0x102
           [] might_fault+0x89/0xac
           [] fiemap_fill_next_extent+0x95/0xda
           [] ext4_ext_fiemap_cb+0x138/0x157
           [] ext4_ext_walk_space+0x178/0x1f1
           [] ext4_fiemap+0x13c/0x159
           [] do_vfs_ioctl+0x348/0x4d6
           [] sys_ioctl+0x56/0x79
           [] system_call_fastpath+0x16/0x1b

    other info that might help us debug this:

    1 lock held by ureadahead/1855:
     #0:  (&ei->i_data_sem){++++..}, at: [] ext4_fiemap+0x11b/0x159

    stack backtrace:
    Pid: 1855, comm: ureadahead Not tainted 2.6.32-04115-gec044c5 #37
    Call Trace:
     [] print_circular_bug+0xa8/0xb7
     [] __lock_acquire+0xa11/0xd0f
     [] ? sched_clock+0x9/0xd
     [] lock_acquire+0xdc/0x102
     [] ? might_fault+0x5c/0xac
     [] might_fault+0x89/0xac
     [] ? might_fault+0x5c/0xac
     [] ? __kmalloc+0x13b/0x18c
     [] fiemap_fill_next_extent+0x95/0xda
     [] ext4_ext_fiemap_cb+0x138/0x157
     [] ? ext4_ext_fiemap_cb+0x0/0x157
     [] ext4_ext_walk_space+0x178/0x1f1
     [] ext4_fiemap+0x13c/0x159
     [] ? might_fault+0x5c/0xac
     [] do_vfs_ioctl+0x348/0x4d6
     [] ? __up_read+0x8d/0x95
     [] ? retint_swapgs+0x13/0x1b
     [] sys_ioctl+0x56/0x79
     [] system_call_fastpath+0x16/0x1b

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

ext4: Fix insufficient checks in EXT4_IOC_MOVE_EXT

2009-12-14T17:45:26+00:00

(cherry picked from commit 4a58579b9e4e2a35d57e6c9c8483e52f6f1b7fd6)

This patch fixes three problems in the handling of the
EXT4_IOC_MOVE_EXT ioctl:

1. In current EXT4_IOC_MOVE_EXT, there are read access mode checks for
original and donor files, but they allow the illegal write access to
donor file, since donor file is overwritten by original file data.  To
fix this problem, change access mode checks of original (r->r/w) and
donor (r->w) files.

2.  Disallow the use of donor files that have a setuid or setgid bits.

3.  Call mnt_want_write() and mnt_drop_write() before and after
ext4_move_extents() calling to get write access to a mount.

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

ext4: Wait for proper transaction commit on fsync

2009-12-14T17:45:25+00:00

(cherry picked from commit b436b9bef84de6893e86346d8fbf7104bc520645)

We cannot rely on buffer dirty bits during fsync because pdflush can come
before fsync is called and clear dirty bits without forcing a transaction
commit. What we do is that we track which transaction has last changed
the inode and which transaction last changed allocation and force it to
disk on fsync.

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

ext4: fix incorrect block reservation on quota transfer.

2009-12-14T17:45:23+00:00

(cherry picked from commit 194074acacebc169ded90a4657193f5180015051)

Inside ->setattr() call both ATTR_UID and ATTR_GID may be valid
This means that we may end-up with transferring all quotas. Add
we have to reserve QUOTA_DEL_BLOCKS for all quotas, as we do in
case of QUOTA_INIT_BLOCKS.

Signed-off-by: Dmitry Monakhov 
Reviewed-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: quota macros cleanup

2009-12-14T17:45:22+00:00

(cherry picked from commit 5aca07eb7d8f14d90c740834d15ca15277f4820c)

Currently all quota block reservation macros contains hard-coded "2"
aka MAXQUOTAS value. This is no good because in some places it is not
obvious to understand what does this digit represent. Let's introduce
new macro with self descriptive name.

Signed-off-by: Dmitry Monakhov 
Acked-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: ext4_get_reserved_space() must return bytes instead of blocks

2009-12-14T17:45:21+00:00

(cherry picked from commit 8aa6790f876e81f5a2211fe1711a5fe3fe2d7b20)

Signed-off-by: Dmitry Monakhov 
Reviewed-by: Eric Sandeen 
Acked-by: Mingming Cao 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: remove blocks from inode prealloc list on failure

2009-12-14T17:45:16+00:00

(cherry picked from commit b844167edc7fcafda9623955c05e4c1b3c32ebc7)

This fixes a leak of blocks in an inode prealloc list if device failures
cause ext4_mb_mark_diskspace_used() to fail.

Signed-off-by: Curt Wohlgemuth 
Acked-by: Aneesh Kumar K.V 
Signed-off-by: "Theodore Ts'o" 
Signed-off-by: Greg Kroah-Hartman

ext4: wait for log to commit when umounting

2009-12-14T17:45:14+00:00

(cherry picked from commit d4edac314e9ad0b21ba20ba8bc61b61f186f79e1)

There is a potential race when a transaction is committing right when
the file system is being umounting.  This could reduce in a race
because EXT4_SB(sb)->s_group_info could be freed in ext4_put_super
before the commit code calls a callback so the mballoc code can
release freed blocks in the transaction, resulting in a panic trying
to access the freed s_group_info.

The fix is to wait for the transaction to finish committing before we
shutdown the multiblock allocator.

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

ext4: Avoid data / filesystem corruption when write fails to copy data

2009-12-14T17:45:13+00:00

(cherry picked from commit b9a4207d5e911b938f73079a83cc2ae10524ec7f)

When ext4_write_begin fails after allocating some blocks or
generic_perform_write fails to copy data to write, we truncate blocks
already instantiated beyond i_size.  Although these blocks were never
inside i_size, we have to truncate the pagecache of these blocks so
that corresponding buffers get unmapped.  Otherwise subsequent
__block_prepare_write (called because we are retrying the write) will
find the buffers mapped, not call ->get_block, and thus the page will
be backed by already freed blocks leading to filesystem and data
corruption.

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