linux-toradex.git/fs/jbd2/checkpoint.c, branch v3.6.5

jbd2: remove bh_state lock from checkpointing code

2012-03-14T02:45:25+00:00

All accesses to checkpointing entries in journal_head are protected
by j_list_lock. Thus __jbd2_journal_remove_checkpoint() doesn't really
need bh_state lock.

Also the only part of journal head that the rest of checkpointing code
needs to check is jh->b_transaction which is safe to read under
j_list_lock.

So we can safely remove bh_state lock from all of checkpointing code which
makes it considerably prettier.

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

jbd2: fix BH_JWrite setting in checkpointing code

2012-03-14T02:24:54+00:00

BH_JWrite bit should be set when buffer is written to the journal. So
checkpointing shouldn't set this bit when writing out buffer. This didn't
cause any observable bug since BH_JWrite bit is used only for debugging
purposes but it's good to have this consistent.

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

jbd2: issue cache flush after checkpointing even with internal journal

2012-03-14T02:22:54+00:00

When we reach jbd2_cleanup_journal_tail(), there is no guarantee that
checkpointed buffers are on a stable storage - especially if buffers were
written out by jbd2_log_do_checkpoint(), they are likely to be only in disk's
caches. Thus when we update journal superblock effectively removing old
transaction from journal, this write of superblock can get to stable storage
before those checkpointed buffers which can result in filesystem corruption
after a crash. Thus we must unconditionally issue a cache flush before we
update journal superblock in these cases.

A similar problem can also occur if journal superblock is written only in
disk's caches, other transaction starts reusing space of the transaction
cleaned from the log and power failure happens. Subsequent journal replay would
still try to replay the old transaction but some of it's blocks may be already
overwritten by the new transaction. For this reason we must use WRITE_FUA when
updating log tail and we must first write new log tail to disk and update
in-memory information only after that.

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

jbd2: split updating of journal superblock and marking journal empty

2012-03-13T19:41:04+00:00

There are three case of updating journal superblock. In the first case, we want
to mark journal as empty (setting s_sequence to 0), in the second case we want
to update log tail, in the third case we want to update s_errno. Split these
cases into separate functions. It makes the code slightly more straightforward
and later patches will make the distinction even more important.

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

jbd2: allocate transaction from separate slab cache

2012-02-20T22:53:02+00:00

There is normally only a handful of these active at any one time, but
putting them in a separate slab cache makes debugging memory
corruption problems easier.  Manish Katiyar also wanted this make it
easier to test memory failure scenarios in the jbd2 layer.

Cc: Manish Katiyar 
Signed-off-by: Yongqiang Yang 
Signed-off-by: "Theodore Ts'o"

jbd2: add drop_transaction/update_superblock_end tracepoints

2012-02-20T22:53:01+00:00

This patch adds trace_jbd2_drop_transaction and
trace_jbd2_update_superblock_end because there are similar tracepoints
in jbd and they are needed in jbd2 as well.

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

treewide: Fix comment and string typo 'bufer'

2011-12-06T08:53:40+00:00

Signed-off-by: Paul Bolle 
Signed-off-by: Jiri Kosina

jbd2: use WRITE_SYNC in journal checkpoint

2011-06-27T16:36:29+00:00

In journal checkpoint, we write the buffer and wait for its finish.
But in cfq, the async queue has a very low priority, and in our test,
if there are too many sync queues and every queue is filled up with
requests, the write request will be delayed for quite a long time and
all the tasks which are waiting for journal space will end with errors like:

INFO: task attr_set:3816 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
attr_set      D ffff880028393480     0  3816      1 0x00000000
 ffff8802073fbae8 0000000000000086 ffff8802140847c8 ffff8800283934e8
 ffff8802073fb9d8 ffffffff8103e456 ffff8802140847b8 ffff8801ed728080
 ffff8801db4bc080 ffff8801ed728450 ffff880028393480 0000000000000002
Call Trace:
 [] ? __dequeue_entity+0x33/0x38
 [] ? need_resched+0x23/0x2d
 [] ? thread_return+0xa2/0xbc
 [] ? jbd2_journal_dirty_metadata+0x116/0x126 [jbd2]
 [] ? jbd2_journal_dirty_metadata+0x116/0x126 [jbd2]
 [] __mutex_lock_common+0x14e/0x1a9
 [] ? brelse+0x13/0x15 [ext4]
 [] __mutex_lock_slowpath+0x19/0x1b
 [] mutex_lock+0x1b/0x32
 [] __jbd2_journal_insert_checkpoint+0xe3/0x20c [jbd2]
 [] start_this_handle+0x438/0x527 [jbd2]
 [] ? autoremove_wake_function+0x0/0x3e
 [] jbd2_journal_start+0xa1/0xcc [jbd2]
 [] ext4_journal_start_sb+0x57/0x81 [ext4]
 [] ext4_xattr_set+0x6c/0xe3 [ext4]
 [] ext4_xattr_user_set+0x42/0x4b [ext4]
 [] generic_setxattr+0x6b/0x76
 [] __vfs_setxattr_noperm+0x47/0xc0
 [] vfs_setxattr+0x7f/0x9a
 [] setxattr+0xb5/0xe8
 [] ? do_filp_open+0x571/0xa6e
 [] sys_fsetxattr+0x6b/0x91
 [] system_call_fastpath+0x16/0x1b

So this patch tries to use WRITE_SYNC in __flush_batch so that the request will
be moved into sync queue and handled by cfq timely. We also use the new plug,
sot that all the WRITE_SYNC requests can be given as a whole when we unplug it.

Signed-off-by: Tao Ma 
Signed-off-by: "Theodore Ts'o" 
Cc: Jan Kara 
Reported-by: Robin Dong

jbd2: Fix oops in jbd2_journal_remove_journal_head()

2011-06-13T19:38:22+00:00

jbd2_journal_remove_journal_head() can oops when trying to access
journal_head returned by bh2jh(). This is caused for example by the
following race:

	TASK1					TASK2
  jbd2_journal_commit_transaction()
    ...
    processing t_forget list
      __jbd2_journal_refile_buffer(jh);
      if (!jh->b_transaction) {
        jbd_unlock_bh_state(bh);
					jbd2_journal_try_to_free_buffers()
					  jbd2_journal_grab_journal_head(bh)
					  jbd_lock_bh_state(bh)
					  __journal_try_to_free_buffer()
					  jbd2_journal_put_journal_head(jh)
        jbd2_journal_remove_journal_head(bh);

jbd2_journal_put_journal_head() in TASK2 sees that b_jcount == 0 and
buffer is not part of any transaction and thus frees journal_head
before TASK1 gets to doing so. Note that even buffer_head can be
released by try_to_free_buffers() after
jbd2_journal_put_journal_head() which adds even larger opportunity for
oops (but I didn't see this happen in reality).

Fix the problem by making transactions hold their own journal_head
reference (in b_jcount). That way we don't have to remove journal_head
explicitely via jbd2_journal_remove_journal_head() and instead just
remove journal_head when b_jcount drops to zero. The result of this is
that [__]jbd2_journal_refile_buffer(),
[__]jbd2_journal_unfile_buffer(), and
__jdb2_journal_remove_checkpoint() can free journal_head which needs
modification of a few callers. Also we have to be careful because once
journal_head is removed, buffer_head might be freed as well. So we
have to get our own buffer_head reference where it matters.

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

Merge branch 'next' into upstream-merge

2010-10-28T03:44:47+00:00

Conflicts:
	fs/ext4/inode.c
	fs/ext4/mballoc.c
	include/trace/events/ext4.h