linux-stable.git/fs/jbd2, branch v3.12.2

jbd2: Fix endian mixing problems in the checksumming code

2013-08-28T18:59:58+00:00

In the jbd2 checksumming code, explicitly declare separate variables with
endianness information so that we don't get confused and screw things up again.
Also fixes sparse warnings.

Signed-off-by: Darrick J. Wong 
Signed-off-by: "Theodore Ts'o"

jbd2: invalidate handle if jbd2_journal_restart() fails

2013-07-01T12:12:41+00:00

If jbd2_journal_restart() fails the handle will have been disconnected
from the current transaction.  In this situation, the handle must not
be used for for any jbd2 function other than jbd2_journal_stop().
Enforce this with by treating a handle which has a NULL transaction
pointer as an aborted handle, and issue a kernel warning if
jbd2_journal_extent(), jbd2_journal_get_write_access(),
jbd2_journal_dirty_metadata(), etc. is called with an invalid handle.

This commit also fixes a bug where jbd2_journal_stop() would trip over
a kernel jbd2 assertion check when trying to free an invalid handle.

Also move the responsibility of setting current->journal_info to
start_this_handle(), simplifying the three users of this function.

Signed-off-by: "Theodore Ts'o" 
Reported-by: Younger Liu 
Cc: Jan Kara

jbd2: fix theoretical race in jbd2__journal_restart

2013-07-01T12:12:40+00:00

Once we decrement transaction->t_updates, if this is the last handle
holding the transaction from closing, and once we release the
t_handle_lock spinlock, it's possible for the transaction to commit
and be released.  In practice with normal kernels, this probably won't
happen, since the commit happens in a separate kernel thread and it's
unlikely this could all happen within the space of a few CPU cycles.

On the other hand, with a real-time kernel, this could potentially
happen, so save the tid found in transaction->t_tid before we release
t_handle_lock.  It would require an insane configuration, such as one
where the jbd2 thread was set to a very high real-time priority,
perhaps because a high priority real-time thread is trying to read or
write to a file system.  But some people who use real-time kernels
have been known to do insane things, including controlling
laser-wielding industrial robots.  :-)

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

jbd2: move superblock checksum calculation to jbd2_write_superblock()

2013-07-01T12:12:38+00:00

Some of the functions which modify the jbd2 superblock were not
updating the checksum before calling jbd2_write_superblock().  Move
the call to jbd2_superblock_csum_set() to jbd2_write_superblock(), so
that the checksum is calculated consistently.

Signed-off-by: "Theodore Ts'o" 
Cc: Darrick J. Wong 
Cc: stable@vger.kernel.org

jbd2: remove debug dependency on debug_fs and update Kconfig help text

2013-06-13T03:07:51+00:00

Commit b6e96d0067d8 ("jbd2: use module parameters instead of debugfs
for jbd_debug") removed any need for a dependency on DEBUG_FS.  It
also moved the /sys variables out from underneath the typical debugfs
mount point.  Delete the dependency and update the /sys path to where
the debug settings are currently.

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

jbd2: use a single printk for jbd_debug()

2013-06-13T03:04:04+00:00

Since the jbd_debug() is implemented with two separate printk()
calls, it can lead to corrupted and misleading debug output like
the following (see lines marked with "*"):

[  290.339362] (fs/jbd2/journal.c, 203): kjournald2: kjournald2 wakes
[  290.339365] (fs/jbd2/journal.c, 155): kjournald2: commit_sequence=42103, commit_request=42104
[  290.339369] (fs/jbd2/journal.c, 158): kjournald2: OK, requests differ
[* 290.339376] (fs/jbd2/journal.c, 648): jbd2_log_wait_commit:
[* 290.339379] (fs/jbd2/commit.c, 370): jbd2_journal_commit_transaction: JBD2: want 42104, j_commit_sequence=42103
[* 290.339382] JBD2: starting commit of transaction 42104
[  290.339410] (fs/jbd2/revoke.c, 566): jbd2_journal_write_revoke_records: Wrote 0 revoke records
[  290.376555] (fs/jbd2/commit.c, 1088): jbd2_journal_commit_transaction: JBD2: commit 42104 complete, head 42079

i.e. the debug output from log_wait_commit and journal_commit_transaction
have become interleaved.  The output should have been:

(fs/jbd2/journal.c, 648): jbd2_log_wait_commit: JBD2: want 42104, j_commit_sequence=42103
(fs/jbd2/commit.c, 370): jbd2_journal_commit_transaction: JBD2: starting commit of transaction 42104

It is expected that this is not easy to replicate -- I was only able
to cause it on preempt-rt kernels, and even then only under heavy
I/O load.

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

jbd2: fix duplicate debug label for phase 2

2013-06-13T02:56:35+00:00

Currently we see this output:

  $git grep phase fs/jbd2
  fs/jbd2/commit.c:       jbd_debug(3, "JBD2: commit phase 1\n");
  fs/jbd2/commit.c:       jbd_debug(3, "JBD2: commit phase 2\n");
  fs/jbd2/commit.c:       jbd_debug(3, "JBD2: commit phase 2\n");
  fs/jbd2/commit.c:       jbd_debug(3, "JBD2: commit phase 3\n");
  fs/jbd2/commit.c:       jbd_debug(3, "JBD2: commit phase 4\n");
  [...]

There is clearly a duplicate label for phase 2, and they are
both active (i.e. not in #if ... #else block).  Rename them to
be "2a" and "2b" so the debug output is unambiguous.

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

jbd2: drop checkpoint mutex when waiting in __jbd2_log_wait_for_space()

2013-06-13T02:47:35+00:00

While trying to debug an an issue under extreme I/O loading
on preempt-rt kernels, the following backtrace was observed
via SysRQ output:

rm              D ffff8802203afbc0  4600  4878   4748 0x00000000
 ffff8802217bfb78 0000000000000082 ffff88021fc2bb80 ffff88021fc2bb80
 ffff88021fc2bb80 ffff8802217bffd8 ffff8802217bffd8 ffff8802217bffd8
 ffff88021f1d4c80 ffff88021fc2bb80 ffff8802217bfb88 ffff88022437b000
Call Trace:
 [] schedule+0x24/0x70
 [] jbd2_log_wait_commit+0xbd/0x140
 [] ? __init_waitqueue_head+0x50/0x50
 [] jbd2_log_do_checkpoint+0xf5/0x520
 [] __jbd2_log_wait_for_space+0xa9/0x1f0
 [] start_this_handle.isra.10+0x2e0/0x530
 [] ? __init_waitqueue_head+0x50/0x50
 [] jbd2__journal_start+0xc3/0x110
 [] ? ext4_rmdir+0x6e/0x230
 [] jbd2_journal_start+0xe/0x10
 [] ext4_journal_start_sb+0x5b/0x160
 [] ext4_rmdir+0x6e/0x230
 [] vfs_rmdir+0xd5/0x140
 [] do_rmdir+0xdf/0x120
 [] ? task_work_run+0x44/0x80
 [] ? do_notify_resume+0x89/0x100
 [] ? int_signal+0x12/0x17
 [] sys_unlinkat+0x25/0x40
 [] system_call_fastpath+0x16/0x1b

What is interesting here, is that we call log_wait_commit, from
within wait_for_space, but we are still holding the checkpoint_mutex
as it surrounds mostly the whole of wait_for_space.  And then, as we
are waiting, journal_commit_transaction can run, and if the JBD2_FLUSHED
bit is set, then we will also try to take the same checkpoint_mutex.

It seems that we need to drop the checkpoint_mutex while sitting in
jbd2_log_wait_commit, if we want to guarantee that progress can be made
by jbd2_journal_commit_transaction().  There does not seem to be
anything preempt-rt specific about this, other then perhaps increasing
the odds of it happening.

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

jbd2: relocate assert after state lock in journal_commit_transaction()

2013-06-13T02:46:35+00:00

The state lock is taken after we are doing an assert on the state
value, not before.  So we might in fact be doing an assert on a
transient value.  Ensure the state check is within the scope of
the state lock being taken.

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

jbd2: optimize jbd2_journal_force_commit

2013-06-13T02:24:07+00:00

Current implementation of jbd2_journal_force_commit() is suboptimal because
result in empty and useless commits. But callers just want to force and wait
any unfinished commits. We already have jbd2_journal_force_commit_nested()
which does exactly what we want, except we are guaranteed that we do not hold
journal transaction open.

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