litmus-rt.git/fs/ext4, branch tracing-devel

ext4: partial revert to fix double brelse WARNING()

2009-11-08T20:45:44+00:00

This is a partial revert of commit 6487a9d (only the changes made to
fs/ext4/namei.c), since it is causing the following brelse()
double-free warning when running fsstress on a file system with 1k
blocksize and we run into a block allocation failure while converting
a single-block directory to a multi-block hash-tree indexed directory.

WARNING: at fs/buffer.c:1197 __brelse+0x2e/0x33()
Hardware name: 
VFS: brelse: Trying to free free buffer
Modules linked in:
Pid: 2226, comm: jbd2/sdd-8 Not tainted 2.6.32-rc6-00577-g0003f55 #101
Call Trace:
 [] warn_slowpath_common+0x65/0x95
 [] warn_slowpath_fmt+0x29/0x2c
 [] __brelse+0x2e/0x33
 [] jbd2_journal_refile_buffer+0x67/0x6c
 [] jbd2_journal_commit_transaction+0x319/0x14d8
 [] ? try_to_del_timer_sync+0x58/0x60
 [] ? sched_clock_cpu+0x12a/0x13e
 [] ? trace_hardirqs_off+0xb/0xd
 [] ? cpu_clock+0x3f/0x5b
 [] ? lock_release_holdtime+0x36/0x137
 [] ? _spin_unlock_irqrestore+0x44/0x51
 [] ? trace_hardirqs_on_caller+0x103/0x124
 [] ? trace_hardirqs_on+0xb/0xd
 [] ? try_to_del_timer_sync+0x58/0x60
 [] kjournald2+0x11a/0x310
 [] ? autoremove_wake_function+0x0/0x38
 [] ? kjournald2+0x0/0x310
 [] kthread+0x66/0x6b
 [] ? kthread+0x0/0x6b
 [] kernel_thread_helper+0x7/0x10
---[ end trace 5579351b86af61e3 ]---

Commit 6487a9d was an attempt some buffer head leaks in an ENOSPC
error path, but in some cases it actually results in an excess ENOSPC,
as shown above.  Fixing this means cleaning up who is responsible for
releasing the buffer heads from the callee to the caller of
add_dirent_to_buf().

Since that's a relatively complex change, and we're late in the rcX
development cycle, I'm reverting this now, and holding back a more
complete fix until after 2.6.32 ships.  We've lived with this
buffer_head leak on ENOSPC in ext3 and ext4 for a very long time; a
few more months won't kill us.

Signed-off-by: "Theodore Ts'o" 
Cc: Curt Wohlgemuth

ext4: Fix return value of ext4_split_unwritten_extents() to fix direct I/O

2009-11-06T09:01:23+00:00

To prepare for a direct I/O write, we need to split the unwritten
extents before submitting the I/O.  When no extents needed to be
split, ext4_split_unwritten_extents() was incorrectly returning 0
instead of the size of uninitialized extents. This bug caused the
wrong return value sent back to VFS code when it gets called from
async IO path, leading to an unnecessary fall back to buffered IO.

This bug also hid the fact that the check to see whether or not a
split would be necessary was incorrect; we can only skip splitting the
extent if the write completely covers the uninitialized extent.

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

ext4: code clean up for dio fallocate handling

2009-11-03T19:44:54+00:00

The ext4_debug() call in ext4_end_io_dio() should be moved after the
check to make sure that io_end is non-NULL.

The comment above ext4_get_block_dio_write() ("Maximum number of
blocks...") is a duplicate; the original and correct comment is above
the #define DIO_MAX_BLOCKS up above.

Based on review comments from Curt Wohlgemuth.

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

ext4: skip conversion of uninit extents after direct IO if there isn't any

2009-11-10T15:48:04+00:00

At the end of direct I/O operation, ext4_ext_direct_IO() always called
ext4_convert_unwritten_extents(), regardless of whether there were any
unwritten extents involved in the I/O or not.

This commit adds a state flag so that ext4_ext_direct_IO() only calls
ext4_convert_unwritten_extents() when necessary.

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

ext4: fix ext4_ext_direct_IO()'s return value after converting uninit extents

2009-11-10T15:48:08+00:00

After a direct I/O request covering an uninitalized extent (i.e.,
created using the fallocate system call) or a hole in a file, ext4
will convert the uninitialized extent so it is marked as initialized
by calling ext4_convert_unwritten_extents().  This function returns
zero on success.

This return value was getting returned by ext4_direct_IO(); however
the file system's direct_IO function is supposed to return the number
of bytes read or written on a success.  By returning zero, it confused
the direct I/O code into falling back to buffered I/O unnecessarily.

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

ext4: discard preallocation when restarting a transaction during truncate

2009-11-02T23:50:49+00:00

When restart a transaction during a truncate operation, we drop and
reacquire i_data_sem.  After reacquiring i_data_sem, we need to
discard any inode-based preallocation that might have been grabbed
while we released i_data_sem (for example, if pdflush is allocating
blocks and racing against the truncate).

Signed-off-by: Aneesh Kumar K.V 
Signed-off-by: "Theodore Ts'o"

Revert "ext4: Remove journal_checksum mount option and enable it by default"

2009-11-02T18:15:27+00:00

This reverts commit d0646f7b636d067d715fab52a2ba9c6f0f46b0d7, as
requested by Eric Sandeen.

It can basically cause an ext4 filesystem to miss recovery (and thus get
mounted with errors) if the journal checksum does not match.

Quoth Eric:

   "My hand-wavy hunch about what is happening is that we're finding a
    bad checksum on the last partially-written transaction, which is
    not surprising, but if we have a wrapped log and we're doing the
    initial scan for head/tail, and we abort scanning on that bad
    checksum, then we are essentially running an unrecovered filesystem.

    But that's hand-wavy and I need to go look at the code.

    We lived without journal checksums on by default until now, and at
    this point they're doing more harm than good, so we should revert
    the default-changing commit until we can fix it and do some good
    power-fail testing with the fixes in place."

See

	http://bugzilla.kernel.org/show_bug.cgi?id=14354

for all the gory details.

Requested-by: Eric Sandeen 
Cc: Theodore Tso 
Cc: Alexey Fisher 
Cc: Maxim Levitsky 
Cc: Aneesh Kumar K.V 
Cc: Mathias Burén 
Signed-off-by: Linus Torvalds

Merge branch 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4

2009-10-03T18:24:19+00:00

* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  [PATCH] ext4: retry failed direct IO allocations
  ext4: Fix build warning in ext4_dirty_inode()
  ext4: drop ext4dev compat
  ext4: fix a BUG_ON crash by checking that page has buffers attached to it

[PATCH] ext4: retry failed direct IO allocations

2009-10-03T01:20:55+00:00

On a 256M filesystem, doing this in a loop:

        xfs_io -F -f -d -c 'pwrite 0 64m' test
        rm -f test

eventually leads to ENOSPC.  (the xfs_io command does a
64m direct IO write to the file "test")

As with other block allocation callers, it looks like we need to
potentially retry the allocations on the initial ENOSPC.

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

ext4: Fix build warning in ext4_dirty_inode()

2009-10-03T01:08:32+00:00

This fixes the following warning:

fs/ext4/inode.c: In function 'ext4_dirty_inode':
fs/ext4/inode.c:5615: warning: unused variable 'current_handle'

We remove the jbd_debug() statement which does use current_handle, as
it's not terribly important in the grand scheme of things.

Thanks to Stephen Rothwell for pointing this out.

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