<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs/jbd2/checkpoint.c, branch v4.5</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>jbd2: fix checkpoint list cleanup</title>
<updated>2015-10-18T02:35:09+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.com</email>
</author>
<published>2015-10-18T02:35:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=33d14975e5ac469963d5d63856b61698ad0bff07'/>
<id>33d14975e5ac469963d5d63856b61698ad0bff07</id>
<content type='text'>
Unlike comments and expectation of callers journal_clean_one_cp_list()
returned 1 not only if it freed the transaction but also if it freed
some buffers in the transaction. That could make
__jbd2_journal_clean_checkpoint_list() skip processing
t_checkpoint_io_list and continue with processing the next transaction.
This is mostly a cosmetic issue since the only result is we can
sometimes free less memory than we could. But it's still worth fixing.
Fix journal_clean_one_cp_list() to return 1 only if the transaction was
really freed.

Fixes: 50849db32a9f529235a84bcc84a6b8e631b1d0ec
Signed-off-by: Jan Kara &lt;jack@suse.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Unlike comments and expectation of callers journal_clean_one_cp_list()
returned 1 not only if it freed the transaction but also if it freed
some buffers in the transaction. That could make
__jbd2_journal_clean_checkpoint_list() skip processing
t_checkpoint_io_list and continue with processing the next transaction.
This is mostly a cosmetic issue since the only result is we can
sometimes free less memory than we could. But it's still worth fixing.
Fix journal_clean_one_cp_list() to return 1 only if the transaction was
really freed.

Fixes: 50849db32a9f529235a84bcc84a6b8e631b1d0ec
Signed-off-by: Jan Kara &lt;jack@suse.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: avoid infinite loop when destroying aborted journal</title>
<updated>2015-07-28T18:57:14+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.com</email>
</author>
<published>2015-07-28T18:57:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=841df7df196237ea63233f0f9eaa41db53afd70f'/>
<id>841df7df196237ea63233f0f9eaa41db53afd70f</id>
<content type='text'>
Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal
superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
when the journal is aborted. That makes logic in
jbd2_log_do_checkpoint() bail out which is fine, except that
jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
a progress in cleaning the journal. Without it jbd2_journal_destroy()
just loops in an infinite loop.

Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
jbd2_log_do_checkpoint() fails with error.

Reported-by: Eryu Guan &lt;guaneryu@gmail.com&gt;
Tested-by: Eryu Guan &lt;guaneryu@gmail.com&gt;
Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a
Signed-off-by: Jan Kara &lt;jack@suse.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 6f6a6fda2945 "jbd2: fix ocfs2 corrupt when updating journal
superblock fails" changed jbd2_cleanup_journal_tail() to return EIO
when the journal is aborted. That makes logic in
jbd2_log_do_checkpoint() bail out which is fine, except that
jbd2_journal_destroy() expects jbd2_log_do_checkpoint() to always make
a progress in cleaning the journal. Without it jbd2_journal_destroy()
just loops in an infinite loop.

Fix jbd2_journal_destroy() to cleanup journal checkpoint lists of
jbd2_log_do_checkpoint() fails with error.

Reported-by: Eryu Guan &lt;guaneryu@gmail.com&gt;
Tested-by: Eryu Guan &lt;guaneryu@gmail.com&gt;
Fixes: 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a
Signed-off-by: Jan Kara &lt;jack@suse.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: fix ocfs2 corrupt when updating journal superblock fails</title>
<updated>2015-06-15T18:36:01+00:00</updated>
<author>
<name>Joseph Qi</name>
<email>joseph.qi@huawei.com</email>
</author>
<published>2015-06-15T18:36:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a'/>
<id>6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a</id>
<content type='text'>
If updating journal superblock fails after journal data has been
flushed, the error is omitted and this will mislead the caller as a
normal case.  In ocfs2, the checkpoint will be treated successfully
and the other node can get the lock to update. Since the sb_start is
still pointing to the old log block, it will rewrite the journal data
during journal recovery by the other node. Thus the new updates will
be overwritten and ocfs2 corrupts.  So in above case we have to return
the error, and ocfs2_commit_cache will take care of the error and
prevent the other node to do update first.  And only after recovering
journal it can do the new updates.

The issue discussion mail can be found at:
https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html
http://comments.gmane.org/gmane.comp.file-systems.ext4/48841

[ Fixed bug in patch which allowed a non-negative error return from
  jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
  was causing xfstests ext4/306 to fail. -- Ted ]

Reported-by: Yiwen Jiang &lt;jiangyiwen@huawei.com&gt;
Signed-off-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Tested-by: Yiwen Jiang &lt;jiangyiwen@huawei.com&gt;
Cc: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If updating journal superblock fails after journal data has been
flushed, the error is omitted and this will mislead the caller as a
normal case.  In ocfs2, the checkpoint will be treated successfully
and the other node can get the lock to update. Since the sb_start is
still pointing to the old log block, it will rewrite the journal data
during journal recovery by the other node. Thus the new updates will
be overwritten and ocfs2 corrupts.  So in above case we have to return
the error, and ocfs2_commit_cache will take care of the error and
prevent the other node to do update first.  And only after recovering
journal it can do the new updates.

The issue discussion mail can be found at:
https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html
http://comments.gmane.org/gmane.comp.file-systems.ext4/48841

[ Fixed bug in patch which allowed a non-negative error return from
  jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
  was causing xfstests ext4/306 to fail. -- Ted ]

Reported-by: Yiwen Jiang &lt;jiangyiwen@huawei.com&gt;
Signed-off-by: Joseph Qi &lt;joseph.qi@huawei.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Tested-by: Yiwen Jiang &lt;jiangyiwen@huawei.com&gt;
Cc: Junxiao Bi &lt;junxiao.bi@oracle.com&gt;
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: use GFP_NOFS in jbd2_cleanup_journal_tail()</title>
<updated>2015-06-15T04:18:02+00:00</updated>
<author>
<name>Dmitry Monakhov</name>
<email>dmonakhov@openvz.org</email>
</author>
<published>2015-06-15T04:18:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b4f1afcd068f6e533230dfed00782cd8a907f96b'/>
<id>b4f1afcd068f6e533230dfed00782cd8a907f96b</id>
<content type='text'>
jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start()
So allocations should be done with GFP_NOFS

[Full stack trace snipped from 3.10-rh7]
[&lt;ffffffff815c4bd4&gt;] dump_stack+0x19/0x1b
[&lt;ffffffff8105dba1&gt;] warn_slowpath_common+0x61/0x80
[&lt;ffffffff8105dcca&gt;] warn_slowpath_null+0x1a/0x20
[&lt;ffffffff815c2142&gt;] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17
[&lt;ffffffff8119c045&gt;] kmem_cache_alloc+0x55/0x210
[&lt;ffffffff811477f5&gt;] ? mempool_alloc_slab+0x15/0x20
[&lt;ffffffff811477f5&gt;] mempool_alloc_slab+0x15/0x20
[&lt;ffffffff81147939&gt;] mempool_alloc+0x69/0x170
[&lt;ffffffff815cb69e&gt;] ? _raw_spin_unlock_irq+0xe/0x20
[&lt;ffffffff8109160d&gt;] ? finish_task_switch+0x5d/0x150
[&lt;ffffffff811f1a8e&gt;] bio_alloc_bioset+0x1be/0x2e0
[&lt;ffffffff8127ee49&gt;] blkdev_issue_flush+0x99/0x120
[&lt;ffffffffa019a733&gt;] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] --&gt;GFP_KERNEL
[&lt;ffffffffa019aca1&gt;] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2]
[&lt;ffffffffa019afc7&gt;] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2]
[&lt;ffffffffa01952d8&gt;] start_this_handle+0x2d8/0x550 [jbd2]
[&lt;ffffffff811b02a9&gt;] ? __memcg_kmem_put_cache+0x29/0x30
[&lt;ffffffff8119c120&gt;] ? kmem_cache_alloc+0x130/0x210
[&lt;ffffffffa019573a&gt;] jbd2__journal_start+0xba/0x190 [jbd2]
[&lt;ffffffff811532ce&gt;] ? lru_cache_add+0xe/0x10
[&lt;ffffffffa01c9549&gt;] ? ext4_da_write_begin+0xf9/0x330 [ext4]
[&lt;ffffffffa01f2c77&gt;] __ext4_journal_start_sb+0x77/0x160 [ext4]
[&lt;ffffffffa01c9549&gt;] ext4_da_write_begin+0xf9/0x330 [ext4]
[&lt;ffffffff811446ec&gt;] generic_file_buffered_write_iter+0x10c/0x270
[&lt;ffffffff81146918&gt;] __generic_file_write_iter+0x178/0x390
[&lt;ffffffff81146c6b&gt;] __generic_file_aio_write+0x8b/0xb0
[&lt;ffffffff81146ced&gt;] generic_file_aio_write+0x5d/0xc0
[&lt;ffffffffa01bf289&gt;] ext4_file_write+0xa9/0x450 [ext4]
[&lt;ffffffff811c31d9&gt;] ? pipe_read+0x379/0x4f0
[&lt;ffffffff811b93f0&gt;] do_sync_write+0x90/0xe0
[&lt;ffffffff811b9b6d&gt;] vfs_write+0xbd/0x1e0
[&lt;ffffffff811ba5b8&gt;] SyS_write+0x58/0xb0
[&lt;ffffffff815d4799&gt;] system_call_fastpath+0x16/0x1b

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
jbd2_cleanup_journal_tail() can be invoked by jbd2__journal_start()
So allocations should be done with GFP_NOFS

[Full stack trace snipped from 3.10-rh7]
[&lt;ffffffff815c4bd4&gt;] dump_stack+0x19/0x1b
[&lt;ffffffff8105dba1&gt;] warn_slowpath_common+0x61/0x80
[&lt;ffffffff8105dcca&gt;] warn_slowpath_null+0x1a/0x20
[&lt;ffffffff815c2142&gt;] slab_pre_alloc_hook.isra.31.part.32+0x15/0x17
[&lt;ffffffff8119c045&gt;] kmem_cache_alloc+0x55/0x210
[&lt;ffffffff811477f5&gt;] ? mempool_alloc_slab+0x15/0x20
[&lt;ffffffff811477f5&gt;] mempool_alloc_slab+0x15/0x20
[&lt;ffffffff81147939&gt;] mempool_alloc+0x69/0x170
[&lt;ffffffff815cb69e&gt;] ? _raw_spin_unlock_irq+0xe/0x20
[&lt;ffffffff8109160d&gt;] ? finish_task_switch+0x5d/0x150
[&lt;ffffffff811f1a8e&gt;] bio_alloc_bioset+0x1be/0x2e0
[&lt;ffffffff8127ee49&gt;] blkdev_issue_flush+0x99/0x120
[&lt;ffffffffa019a733&gt;] jbd2_cleanup_journal_tail+0x93/0xa0 [jbd2] --&gt;GFP_KERNEL
[&lt;ffffffffa019aca1&gt;] jbd2_log_do_checkpoint+0x221/0x4a0 [jbd2]
[&lt;ffffffffa019afc7&gt;] __jbd2_log_wait_for_space+0xa7/0x1e0 [jbd2]
[&lt;ffffffffa01952d8&gt;] start_this_handle+0x2d8/0x550 [jbd2]
[&lt;ffffffff811b02a9&gt;] ? __memcg_kmem_put_cache+0x29/0x30
[&lt;ffffffff8119c120&gt;] ? kmem_cache_alloc+0x130/0x210
[&lt;ffffffffa019573a&gt;] jbd2__journal_start+0xba/0x190 [jbd2]
[&lt;ffffffff811532ce&gt;] ? lru_cache_add+0xe/0x10
[&lt;ffffffffa01c9549&gt;] ? ext4_da_write_begin+0xf9/0x330 [ext4]
[&lt;ffffffffa01f2c77&gt;] __ext4_journal_start_sb+0x77/0x160 [ext4]
[&lt;ffffffffa01c9549&gt;] ext4_da_write_begin+0xf9/0x330 [ext4]
[&lt;ffffffff811446ec&gt;] generic_file_buffered_write_iter+0x10c/0x270
[&lt;ffffffff81146918&gt;] __generic_file_write_iter+0x178/0x390
[&lt;ffffffff81146c6b&gt;] __generic_file_aio_write+0x8b/0xb0
[&lt;ffffffff81146ced&gt;] generic_file_aio_write+0x5d/0xc0
[&lt;ffffffffa01bf289&gt;] ext4_file_write+0xa9/0x450 [ext4]
[&lt;ffffffff811c31d9&gt;] ? pipe_read+0x379/0x4f0
[&lt;ffffffff811b93f0&gt;] do_sync_write+0x90/0xe0
[&lt;ffffffff811b9b6d&gt;] vfs_write+0xbd/0x1e0
[&lt;ffffffff811ba5b8&gt;] SyS_write+0x58/0xb0
[&lt;ffffffff815d4799&gt;] system_call_fastpath+0x16/0x1b

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: simplify calling convention around __jbd2_journal_clean_checkpoint_list</title>
<updated>2014-09-18T04:58:12+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2014-09-18T04:58:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=50849db32a9f529235a84bcc84a6b8e631b1d0ec'/>
<id>50849db32a9f529235a84bcc84a6b8e631b1d0ec</id>
<content type='text'>
__jbd2_journal_clean_checkpoint_list() returns number of buffers it
freed but noone was using the value so just stop doing that. This
also allows for simplifying the calling convention for
journal_clean_once_cp_list().

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__jbd2_journal_clean_checkpoint_list() returns number of buffers it
freed but noone was using the value so just stop doing that. This
also allows for simplifying the calling convention for
journal_clean_once_cp_list().

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: avoid pointless scanning of checkpoint lists</title>
<updated>2014-09-18T04:42:16+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2014-09-18T04:42:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cc97f1a7c7eed970e674b84be0e68f479c80228d'/>
<id>cc97f1a7c7eed970e674b84be0e68f479c80228d</id>
<content type='text'>
Yuanhan has reported that when he is running fsync(2) heavy workload
creating new files over ramdisk, significant amount of time is spent in
__jbd2_journal_clean_checkpoint_list() trying to clean old transactions
(but they cannot be cleaned up because flusher hasn't yet checkpointed
those buffers). The workload can be generated by:
  fs_mark -d /fs/ram0/1 -D 2 -N 2560 -n 1000000 -L 1 -S 1 -s 4096

Reduce the amount of scanning by stopping to scan the transaction list
once we find a transaction that cannot be checkpointed. Note that this
way of cleaning is still enough to keep freeing space in the journal
after fully checkpointed transactions.

Reported-and-tested-by: Yuanhan Liu &lt;yuanhan.liu@linux.intel.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Yuanhan has reported that when he is running fsync(2) heavy workload
creating new files over ramdisk, significant amount of time is spent in
__jbd2_journal_clean_checkpoint_list() trying to clean old transactions
(but they cannot be cleaned up because flusher hasn't yet checkpointed
those buffers). The workload can be generated by:
  fs_mark -d /fs/ram0/1 -D 2 -N 2560 -n 1000000 -L 1 -S 1 -s 4096

Reduce the amount of scanning by stopping to scan the transaction list
once we find a transaction that cannot be checkpointed. Note that this
way of cleaning is still enough to keep freeing space in the journal
after fully checkpointed transactions.

Reported-and-tested-by: Yuanhan Liu &lt;yuanhan.liu@linux.intel.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: jbd2_log_wait_for_space improve error detetcion</title>
<updated>2014-09-16T18:50:50+00:00</updated>
<author>
<name>Dmitry Monakhov</name>
<email>dmonakhov@openvz.org</email>
</author>
<published>2014-09-16T18:50:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1245799f752fa817a030b3b4448466e83ee7d61d'/>
<id>1245799f752fa817a030b3b4448466e83ee7d61d</id>
<content type='text'>
If EIO happens after we have dropped j_state_lock, we won't notice
that the journal has been aborted.  So it is reasonable to move this
check after we have grabbed the j_checkpoint_mutex and re-grabbed the
j_state_lock.  This patch helps to prevent false positive complain
after EIO.

#DMESG:
__jbd2_log_wait_for_space: needed 8448 blocks and only had 8386 space available
__jbd2_log_wait_for_space: no way to get more journal space in ram1-8
------------[ cut here ]------------
WARNING: CPU: 15 PID: 6739 at fs/jbd2/checkpoint.c:168 __jbd2_log_wait_for_space+0x188/0x200()
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 15 PID: 6739 Comm: fsstress Tainted: G        W      3.17.0-rc2-00429-g684de57 #139
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
 00000000000000a8 ffff88077aaab878 ffffffff815c1a8c 00000000000000a8
 0000000000000000 ffff88077aaab8b8 ffffffff8106ce8c ffff88077aaab898
 ffff8807c57e6000 ffff8807c57e6028 0000000000002100 ffff8807c57e62f0
Call Trace:
 [&lt;ffffffff815c1a8c&gt;] dump_stack+0x51/0x6d
 [&lt;ffffffff8106ce8c&gt;] warn_slowpath_common+0x8c/0xc0
 [&lt;ffffffff8106ceda&gt;] warn_slowpath_null+0x1a/0x20
 [&lt;ffffffff812419f8&gt;] __jbd2_log_wait_for_space+0x188/0x200
 [&lt;ffffffff8123be9a&gt;] start_this_handle+0x4da/0x7b0
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810aba87&gt;] ? lockdep_init_map+0xe7/0x180
 [&lt;ffffffff8123c5bc&gt;] jbd2__journal_start+0xdc/0x1d0
 [&lt;ffffffff811f2414&gt;] ? __ext4_new_inode+0x7f4/0x1330
 [&lt;ffffffff81222a38&gt;] __ext4_journal_start_sb+0xf8/0x110
 [&lt;ffffffff811f2414&gt;] __ext4_new_inode+0x7f4/0x1330
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff812025bb&gt;] ext4_create+0x8b/0x150
 [&lt;ffffffff8117fe3b&gt;] vfs_create+0x7b/0xb0
 [&lt;ffffffff8118097b&gt;] do_last+0x7db/0xcf0
 [&lt;ffffffff8117e31d&gt;] ? inode_permission+0x4d/0x50
 [&lt;ffffffff811845d2&gt;] path_openat+0x242/0x590
 [&lt;ffffffff81191a76&gt;] ? __alloc_fd+0x36/0x140
 [&lt;ffffffff81184a6a&gt;] do_filp_open+0x4a/0xb0
 [&lt;ffffffff81191b61&gt;] ? __alloc_fd+0x121/0x140
 [&lt;ffffffff81172f20&gt;] do_sys_open+0x170/0x220
 [&lt;ffffffff8117300e&gt;] SyS_open+0x1e/0x20
 [&lt;ffffffff811715d6&gt;] SyS_creat+0x16/0x20
 [&lt;ffffffff815c7e12&gt;] system_call_fastpath+0x16/0x1b
---[ end trace cd71c831f82059db ]---

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If EIO happens after we have dropped j_state_lock, we won't notice
that the journal has been aborted.  So it is reasonable to move this
check after we have grabbed the j_checkpoint_mutex and re-grabbed the
j_state_lock.  This patch helps to prevent false positive complain
after EIO.

#DMESG:
__jbd2_log_wait_for_space: needed 8448 blocks and only had 8386 space available
__jbd2_log_wait_for_space: no way to get more journal space in ram1-8
------------[ cut here ]------------
WARNING: CPU: 15 PID: 6739 at fs/jbd2/checkpoint.c:168 __jbd2_log_wait_for_space+0x188/0x200()
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 15 PID: 6739 Comm: fsstress Tainted: G        W      3.17.0-rc2-00429-g684de57 #139
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
 00000000000000a8 ffff88077aaab878 ffffffff815c1a8c 00000000000000a8
 0000000000000000 ffff88077aaab8b8 ffffffff8106ce8c ffff88077aaab898
 ffff8807c57e6000 ffff8807c57e6028 0000000000002100 ffff8807c57e62f0
Call Trace:
 [&lt;ffffffff815c1a8c&gt;] dump_stack+0x51/0x6d
 [&lt;ffffffff8106ce8c&gt;] warn_slowpath_common+0x8c/0xc0
 [&lt;ffffffff8106ceda&gt;] warn_slowpath_null+0x1a/0x20
 [&lt;ffffffff812419f8&gt;] __jbd2_log_wait_for_space+0x188/0x200
 [&lt;ffffffff8123be9a&gt;] start_this_handle+0x4da/0x7b0
 [&lt;ffffffff810990e5&gt;] ? local_clock+0x25/0x30
 [&lt;ffffffff810aba87&gt;] ? lockdep_init_map+0xe7/0x180
 [&lt;ffffffff8123c5bc&gt;] jbd2__journal_start+0xdc/0x1d0
 [&lt;ffffffff811f2414&gt;] ? __ext4_new_inode+0x7f4/0x1330
 [&lt;ffffffff81222a38&gt;] __ext4_journal_start_sb+0xf8/0x110
 [&lt;ffffffff811f2414&gt;] __ext4_new_inode+0x7f4/0x1330
 [&lt;ffffffff810ac359&gt;] ? lock_release_holdtime+0x29/0x190
 [&lt;ffffffff812025bb&gt;] ext4_create+0x8b/0x150
 [&lt;ffffffff8117fe3b&gt;] vfs_create+0x7b/0xb0
 [&lt;ffffffff8118097b&gt;] do_last+0x7db/0xcf0
 [&lt;ffffffff8117e31d&gt;] ? inode_permission+0x4d/0x50
 [&lt;ffffffff811845d2&gt;] path_openat+0x242/0x590
 [&lt;ffffffff81191a76&gt;] ? __alloc_fd+0x36/0x140
 [&lt;ffffffff81184a6a&gt;] do_filp_open+0x4a/0xb0
 [&lt;ffffffff81191b61&gt;] ? __alloc_fd+0x121/0x140
 [&lt;ffffffff81172f20&gt;] do_sys_open+0x170/0x220
 [&lt;ffffffff8117300e&gt;] SyS_open+0x1e/0x20
 [&lt;ffffffff811715d6&gt;] SyS_creat+0x16/0x20
 [&lt;ffffffff815c7e12&gt;] system_call_fastpath+0x16/0x1b
---[ end trace cd71c831f82059db ]---

Signed-off-by: Dmitry Monakhov &lt;dmonakhov@openvz.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: optimize jbd2_log_do_checkpoint() a bit</title>
<updated>2014-09-04T22:09:29+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2014-09-04T22:09:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0e5ecf0a762627b949141df1d83094a9b0eb54a8'/>
<id>0e5ecf0a762627b949141df1d83094a9b0eb54a8</id>
<content type='text'>
When we discover written out buffer in transaction checkpoint list we
don't have to recheck validity of a transaction. Either this is the
last buffer in a transaction - and then we are done - or this isn't
and then we can just take another buffer from the checkpoint list
without dropping j_list_lock.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we discover written out buffer in transaction checkpoint list we
don't have to recheck validity of a transaction. Either this is the
last buffer in a transaction - and then we are done - or this isn't
and then we can just take another buffer from the checkpoint list
without dropping j_list_lock.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: don't call get_bh() before calling __jbd2_journal_remove_checkpoint()</title>
<updated>2014-09-04T22:09:22+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-09-04T22:09:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=dc6e8d669cf5cb3ff84707c372c0a2a8a5e80845'/>
<id>dc6e8d669cf5cb3ff84707c372c0a2a8a5e80845</id>
<content type='text'>
The __jbd2_journal_remove_checkpoint() doesn't require an elevated
b_count; indeed, until the jh structure gets released by the call to
jbd2_journal_put_journal_head(), the bh's b_count is elevated by
virtue of the existence of the jh structure.

Suggested-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The __jbd2_journal_remove_checkpoint() doesn't require an elevated
b_count; indeed, until the jh structure gets released by the call to
jbd2_journal_put_journal_head(), the bh's b_count is elevated by
virtue of the existence of the jh structure.

Suggested-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: fold __wait_cp_io into jbd2_log_do_checkpoint()</title>
<updated>2014-09-02T01:26:09+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-09-02T01:26:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=88fe1acb5bedfcba5f42fcdf165493ee587ba643'/>
<id>88fe1acb5bedfcba5f42fcdf165493ee587ba643</id>
<content type='text'>
__wait_cp_io() is only called by jbd2_log_do_checkpoint().  Fold it in
to make it a bit easier to understand.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__wait_cp_io() is only called by jbd2_log_do_checkpoint().  Fold it in
to make it a bit easier to understand.

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
</feed>
