linux-toradex.git/fs/ext4/ext4_jbd2.c, branch v3.14.8

ext4: call ext4_error_inode() if jbd2_journal_dirty_metadata() fails

2013-12-02T14:31:36+00:00

While it's true that errors can only happen if there is a bug in
jbd2_journal_dirty_metadata(), if a bug does happen, we need to halt
the kernel or remount the file system read-only in order to avoid
further data loss.  The ext4_journal_abort_handle() function doesn't
do any of this, and while it's likely that this call (since it doesn't
adjust refcounts) will likely result in the file system eventually
deadlocking since the current transaction will never be able to close,
it's much cleaner to call let ext4's error handling system deal with
this situation.

There's a separate bug here which is that if certain jbd2 errors
errors occur and file system is mounted errors=continue, the file
system will probably eventually end grind to a halt as described
above.  But things have been this way in a long time, and usually when
we have these sorts of errors it's pretty much a disaster --- and
that's why the jbd2 layer aggressively retries memory allocations,
which is the most likely cause of these jbd2 errors.

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Jan Kara 
Cc: stable@vger.kernel.org

jbd2: Fix use after free after error in jbd2_journal_dirty_metadata()

2013-08-12T13:53:28+00:00

When jbd2_journal_dirty_metadata() returns error,
__ext4_handle_dirty_metadata() stops the handle. However callers of this
function do not count with that fact and still happily used now freed
handle. This use after free can result in various issues but very likely
we oops soon.

The motivation of adding __ext4_journal_stop() into
__ext4_handle_dirty_metadata() in commit 9ea7a0df seems to be only to
improve error reporting. So replace __ext4_journal_stop() with
ext4_journal_abort_handle() which was there before that commit and add
WARN_ON_ONCE() to dump stack to provide useful information.

Reported-by: Sage Weil 
Signed-off-by: Jan Kara 
Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org	# 3.2+

ext4: provide wrappers for transaction reservation calls

2013-06-04T16:37:50+00:00

Reviewed-by: Zheng Liu 
Signed-off-by: Jan Kara 
Signed-off-by: "Theodore Ts'o"

jbd2: transaction reservation support

2013-06-04T16:35:11+00:00

In some cases we cannot start a transaction because of locking
constraints and passing started transaction into those places is not
handy either because we could block transaction commit for too long.
Transaction reservation is designed to solve these issues.  It
reserves a handle with given number of credits in the journal and the
handle can be later attached to the running transaction without
blocking on commit or checkpointing.  Reserved handles do not block
transaction commit in any way, they only reduce maximum size of the
running transaction (because we have to always be prepared to
accomodate request for attaching reserved handle).

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

ext4: mark metadata blocks using bh flags

2013-04-21T20:45:54+00:00

This allows metadata writebacks which are issued via block device
writeback to be sent with the current write request flags.

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

ext4: add might_sleep() annotations

2013-04-04T02:00:52+00:00

Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Lukas Czerner

ext4: pass context information to jbd2__journal_start()

2013-02-09T02:59:22+00:00

So we can better understand what bits of ext4 are responsible for
long-running jbd2 handles, use jbd2__journal_start() so we can pass
context information for logging purposes.

The recommended way for finding the longer-running handles is:

   T=/sys/kernel/debug/tracing
   EVENT=$T/events/jbd2/jbd2_handle_stats
   echo "interval > 5" > $EVENT/filter
   echo 1 > $EVENT/enable

   ./run-my-fs-benchmark

   cat $T/trace > /tmp/problem-handles

This will list handles that were active for longer than 20ms.  Having
longer-running handles is bad, because a commit started at the wrong
time could stall for those 20+ milliseconds, which could delay an
fsync() or an O_SYNC operation.  Here is an example line from the
trace file describing a handle which lived on for 311 jiffies, or over
1.2 seconds:

postmark-2917  [000] ....   196.435786: jbd2_handle_stats: dev 254,32 
   tid 570 type 2 line_no 2541 interval 311 sync 0 requested_blocks 1
   dirtied_blocks 0

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

ext4: move the jbd2 wrapper functions out of super.c

2013-02-08T18:00:31+00:00

Move the jbd2 wrapper functions which start and stop handles out of
super.c, where they don't really logically belong, and into
ext4_jbd2.c.

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

ext4: fix metadata checksum calculation for the superblock

2012-10-10T05:06:58+00:00

The function ext4_handle_dirty_super() was calculating the superblock
on the wrong block data.  As a result, when the superblock is modified
while it is mounted (most commonly, when inodes are added or removed
from the orphan list), the superblock checksum would be wrong.  We
didn't notice because the superblock *was* being correctly calculated
in ext4_commit_super(), and this would get called when the file system
was unmounted.  So the problem only became obvious if the system
crashed while the file system was mounted.

Fix this by removing the poorly designed function signature for
ext4_superblock_csum_set(); if it only took a single argument, the
pointer to a struct superblock, the ambiguity which caused this
mistake would have been impossible.

Reported-by: George Spelvin 
Signed-off-by: "Theodore Ts'o" 
Cc: stable@vger.kernel.org

ext4: remove unnecessary argument from __ext4_handle_dirty_metadata()

2012-07-23T00:37:31+00:00

The '__ext4_handle_dirty_metadata()' does not need the 'now' argument
anymore and we can kill it.

Signed-off-by: Artem Bityutskiy 
Signed-off-by: "Theodore Ts'o" 
Reviewed-by: Jan Kara