Theodore Ts'o 2b405bfa84 ext4: fix data=journal fast mount/umount hang
In data=journal mode, if we unmount the file system before a
transaction has a chance to complete, when the journal inode is being
evicted, we can end up calling into jbd2_log_wait_commit() for the
last transaction, after the journalling machinery has been shut down.

Arguably we should adjust ext4_should_journal_data() to return FALSE
for the journal inode, but the only place it matters is
ext4_evict_inode(), and so to save a bit of CPU time, and to make the
patch much more obviously correct by inspection(tm), we'll fix it by
explicitly not trying to waiting for a journal commit when we are
evicting the journal inode, since it's guaranteed to never succeed in
this case.

This can be easily replicated via: 

     mount -t ext4 -o data=journal /dev/vdb /vdb ; umount /vdb

------------[ cut here ]------------
WARNING: at /usr/projects/linux/ext4/fs/jbd2/journal.c:542 __jbd2_log_start_commit+0xba/0xcd()
Hardware name: Bochs
JBD2: bad log_start_commit: 3005630206 3005630206 0 0
Modules linked in:
Pid: 2909, comm: umount Not tainted 3.8.0-rc3 #1020
Call Trace:
 [<c015c0ef>] warn_slowpath_common+0x68/0x7d
 [<c02b7e7d>] ? __jbd2_log_start_commit+0xba/0xcd
 [<c015c177>] warn_slowpath_fmt+0x2b/0x2f
 [<c02b7e7d>] __jbd2_log_start_commit+0xba/0xcd
 [<c02b8075>] jbd2_log_start_commit+0x24/0x34
 [<c0279ed5>] ext4_evict_inode+0x71/0x2e3
 [<c021f0ec>] evict+0x94/0x135
 [<c021f9aa>] iput+0x10a/0x110
 [<c02b7836>] jbd2_journal_destroy+0x190/0x1ce
 [<c0175284>] ? bit_waitqueue+0x50/0x50
 [<c028d23f>] ext4_put_super+0x52/0x294
 [<c020efe3>] generic_shutdown_super+0x48/0xb4
 [<c020f071>] kill_block_super+0x22/0x60
 [<c020f3e0>] deactivate_locked_super+0x22/0x49
 [<c020f5d6>] deactivate_super+0x30/0x33
 [<c0222795>] mntput_no_expire+0x107/0x10c
 [<c02233a7>] sys_umount+0x2cf/0x2e0
 [<c02233ca>] sys_oldumount+0x12/0x14
 [<c08096b8>] syscall_call+0x7/0xb
---[ end trace 6a954cc790501c1f ]---
jbd2_log_wait_commit: error: j_commit_request=-1289337090, tid=0

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: stable@vger.kernel.org
2013-03-20 09:42:11 -04:00
..
2012-12-20 14:00:01 -05:00
2012-12-20 14:00:01 -05:00
2012-12-20 14:00:01 -05:00
2012-11-16 11:20:42 -06:00
2013-01-03 11:41:43 -08:00
2012-12-20 17:40:20 -08:00
2012-12-20 14:00:01 -05:00
2012-12-20 18:40:00 -05:00
2012-12-20 18:40:52 -05:00
2012-12-20 18:40:53 -05:00
2012-12-20 18:40:53 -05:00
2012-12-20 18:40:54 -05:00
2012-12-20 18:40:54 -05:00
2012-12-20 18:40:55 -05:00
2012-12-20 14:00:01 -05:00
2012-12-20 14:00:01 -05:00
2013-01-03 15:57:14 -08:00
2012-07-14 16:34:47 +04:00
2012-12-20 14:00:01 -05:00
2012-12-20 14:00:01 -05:00
2012-12-17 17:15:26 -08:00
2012-12-20 14:00:01 -05:00
2012-10-22 08:50:37 +03:00
2012-10-29 09:00:57 -07:00
2012-10-09 15:52:31 +09:00
2013-01-03 15:57:16 -08:00
2012-11-28 21:49:02 -05:00
2012-12-20 18:46:29 -05:00
2012-10-09 18:35:22 -04:00
2012-12-11 13:43:42 +09:00
2012-09-26 21:08:52 -04:00
2012-12-17 17:15:27 -08:00
2013-01-06 20:58:13 -08:00
2012-12-20 18:50:01 -05:00
2012-10-09 23:33:39 -04:00