<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/fs/jbd2/checkpoint.c, branch v4.0.6</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: 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>
<entry>
<title>jbd2: fold __process_buffer() into jbd2_log_do_checkpoint()</title>
<updated>2014-09-02T01:19:01+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-09-02T01:19:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=be1158cc615fd723552f0d9912087423c7cadda5'/>
<id>be1158cc615fd723552f0d9912087423c7cadda5</id>
<content type='text'>
__process_buffer() is only called by jbd2_log_do_checkpoint(), and it
had a very complex locking protocol where it would be called with the
j_list_lock, and sometimes exit with the lock held (if the return code
was 0), or release the lock.

This was confusing both to humans and to smatch (which erronously
complained that the lock was taken twice).

Folding __process_buffer() to the caller allows us to simplify the
control flow, making the resulting function easier to read and reason
about, and dropping the compiled size of fs/jbd2/checkpoint.c by 150
bytes (over 4% of the text size).

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
__process_buffer() is only called by jbd2_log_do_checkpoint(), and it
had a very complex locking protocol where it would be called with the
j_list_lock, and sometimes exit with the lock held (if the return code
was 0), or release the lock.

This was confusing both to humans and to smatch (which erronously
complained that the lock was taken twice).

Folding __process_buffer() to the caller allows us to simplify the
control flow, making the resulting function easier to read and reason
about, and dropping the compiled size of fs/jbd2/checkpoint.c by 150
bytes (over 4% of the text size).

Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: drop checkpoint mutex when waiting in __jbd2_log_wait_for_space()</title>
<updated>2013-06-13T02:47:35+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2013-06-13T02:47:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0ef54180e0187117062939202b96faf04c8673bc'/>
<id>0ef54180e0187117062939202b96faf04c8673bc</id>
<content type='text'>
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:
 [&lt;ffffffff8172dc34&gt;] schedule+0x24/0x70
 [&lt;ffffffff81225b5d&gt;] jbd2_log_wait_commit+0xbd/0x140
 [&lt;ffffffff81060390&gt;] ? __init_waitqueue_head+0x50/0x50
 [&lt;ffffffff81223635&gt;] jbd2_log_do_checkpoint+0xf5/0x520
 [&lt;ffffffff81223b09&gt;] __jbd2_log_wait_for_space+0xa9/0x1f0
 [&lt;ffffffff8121dc40&gt;] start_this_handle.isra.10+0x2e0/0x530
 [&lt;ffffffff81060390&gt;] ? __init_waitqueue_head+0x50/0x50
 [&lt;ffffffff8121e0a3&gt;] jbd2__journal_start+0xc3/0x110
 [&lt;ffffffff811de7ce&gt;] ? ext4_rmdir+0x6e/0x230
 [&lt;ffffffff8121e0fe&gt;] jbd2_journal_start+0xe/0x10
 [&lt;ffffffff811f308b&gt;] ext4_journal_start_sb+0x5b/0x160
 [&lt;ffffffff811de7ce&gt;] ext4_rmdir+0x6e/0x230
 [&lt;ffffffff811435c5&gt;] vfs_rmdir+0xd5/0x140
 [&lt;ffffffff8114370f&gt;] do_rmdir+0xdf/0x120
 [&lt;ffffffff8105c6b4&gt;] ? task_work_run+0x44/0x80
 [&lt;ffffffff81002889&gt;] ? do_notify_resume+0x89/0x100
 [&lt;ffffffff817361ae&gt;] ? int_signal+0x12/0x17
 [&lt;ffffffff81145d85&gt;] sys_unlinkat+0x25/0x40
 [&lt;ffffffff81735f22&gt;] 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 &lt;paul.gortmaker@windriver.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>
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:
 [&lt;ffffffff8172dc34&gt;] schedule+0x24/0x70
 [&lt;ffffffff81225b5d&gt;] jbd2_log_wait_commit+0xbd/0x140
 [&lt;ffffffff81060390&gt;] ? __init_waitqueue_head+0x50/0x50
 [&lt;ffffffff81223635&gt;] jbd2_log_do_checkpoint+0xf5/0x520
 [&lt;ffffffff81223b09&gt;] __jbd2_log_wait_for_space+0xa9/0x1f0
 [&lt;ffffffff8121dc40&gt;] start_this_handle.isra.10+0x2e0/0x530
 [&lt;ffffffff81060390&gt;] ? __init_waitqueue_head+0x50/0x50
 [&lt;ffffffff8121e0a3&gt;] jbd2__journal_start+0xc3/0x110
 [&lt;ffffffff811de7ce&gt;] ? ext4_rmdir+0x6e/0x230
 [&lt;ffffffff8121e0fe&gt;] jbd2_journal_start+0xe/0x10
 [&lt;ffffffff811f308b&gt;] ext4_journal_start_sb+0x5b/0x160
 [&lt;ffffffff811de7ce&gt;] ext4_rmdir+0x6e/0x230
 [&lt;ffffffff811435c5&gt;] vfs_rmdir+0xd5/0x140
 [&lt;ffffffff8114370f&gt;] do_rmdir+0xdf/0x120
 [&lt;ffffffff8105c6b4&gt;] ? task_work_run+0x44/0x80
 [&lt;ffffffff81002889&gt;] ? do_notify_resume+0x89/0x100
 [&lt;ffffffff817361ae&gt;] ? int_signal+0x12/0x17
 [&lt;ffffffff81145d85&gt;] sys_unlinkat+0x25/0x40
 [&lt;ffffffff81735f22&gt;] 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 &lt;paul.gortmaker@windriver.com&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>jbd2: remove unused waitqueues</title>
<updated>2013-06-04T16:24:11+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2013-06-04T16:24:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f29fad72105287e6899d9128a9d494514f220e77'/>
<id>f29fad72105287e6899d9128a9d494514f220e77</id>
<content type='text'>
j_wait_logspace and j_wait_checkpoint are unused.  Remove them.

Reviewed-by: Zheng Liu &lt;wenqing.lz@taobao.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>
j_wait_logspace and j_wait_checkpoint are unused.  Remove them.

Reviewed-by: Zheng Liu &lt;wenqing.lz@taobao.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: cleanup needed free block estimates when starting a transaction</title>
<updated>2013-06-04T16:12:57+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2013-06-04T16:12:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=76c39904561004ac8675f858a290129e439d5168'/>
<id>76c39904561004ac8675f858a290129e439d5168</id>
<content type='text'>
__jbd2_log_space_left() and jbd_space_needed() were kind of odd.
jbd_space_needed() accounted also credits needed for currently
committing transaction while it didn't account for credits needed for
control blocks.  __jbd2_log_space_left() then accounted for control
blocks as a fraction of free space.  Since results of these two
functions are always only compared against each other, this works
correct but is somewhat strange.  Move the estimates so that
jbd_space_needed() returns number of blocks needed for a transaction
including control blocks and __jbd2_log_space_left() returns free
space in the journal (with the committing transaction already
subtracted).  Rename functions to jbd2_log_space_left() and
jbd2_space_needed() while we are changing them.

Reviewed-by: Zheng Liu &lt;wenqing.lz@taobao.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>
__jbd2_log_space_left() and jbd_space_needed() were kind of odd.
jbd_space_needed() accounted also credits needed for currently
committing transaction while it didn't account for credits needed for
control blocks.  __jbd2_log_space_left() then accounted for control
blocks as a fraction of free space.  Since results of these two
functions are always only compared against each other, this works
correct but is somewhat strange.  Move the estimates so that
jbd_space_needed() returns number of blocks needed for a transaction
including control blocks and __jbd2_log_space_left() returns free
space in the journal (with the committing transaction already
subtracted).  Rename functions to jbd2_log_space_left() and
jbd2_space_needed() while we are changing them.

Reviewed-by: Zheng Liu &lt;wenqing.lz@taobao.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>
</feed>
