<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/nilfs2, branch v2.6.30</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>nilfs2: fix bh leak in nilfs_cpfile_delete_checkpoints function</title>
<updated>2009-05-30T13:07:50+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-05-30T12:50:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=62013ab5d5df297a01ae5863b5c26d758ec0af7f'/>
<id>62013ab5d5df297a01ae5863b5c26d758ec0af7f</id>
<content type='text'>
The nilfs_cpfile_delete_checkpoints() wrongly skips brelse() for the
header block of checkpoint file in case of errors.  This fixes the
leak bug.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The nilfs_cpfile_delete_checkpoints() wrongly skips brelse() for the
header block of checkpoint file in case of errors.  This fixes the
leak bug.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix memory leak in nilfs_ioctl_clean_segments</title>
<updated>2009-05-22T11:49:04+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-05-22T11:36:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d5046853634a8d73f28bad3cf68d182c4a99035d'/>
<id>d5046853634a8d73f28bad3cf68d182c4a99035d</id>
<content type='text'>
This fixes a new memory leak problem in garbage collection.  The
problem was brought by the bugfix patch ("nilfs2: fix lock order
reversal in nilfs_clean_segments ioctl").

Thanks to Kentaro Suzuki for finding this problem.

Reported-by: Kentaro Suzuki &lt;k_suzuki@ms.sylc.co.jp&gt;
Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a new memory leak problem in garbage collection.  The
problem was brought by the bugfix patch ("nilfs2: fix lock order
reversal in nilfs_clean_segments ioctl").

Thanks to Kentaro Suzuki for finding this problem.

Reported-by: Kentaro Suzuki &lt;k_suzuki@ms.sylc.co.jp&gt;
Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: check size of array structured data exchanged via ioctls</title>
<updated>2009-05-11T16:48:54+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-05-11T14:24:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=83aca8f480fcd2d9748301a5d060cf947dc75b94'/>
<id>83aca8f480fcd2d9748301a5d060cf947dc75b94</id>
<content type='text'>
Although some ioctls of nilfs2 exchange data in the form of indirectly
referenced array, some of them lack size check on the array elements.

This inserts the missing checks and rejects requests if data of ioctl
does not have a valid format.

We usually don't have to check size of structures that we associated
with ioctl commands because the size is tested implicitly for
identifying ioctl command; the checks this patch adds are for the
cases where the implicit check is not applied.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Although some ioctls of nilfs2 exchange data in the form of indirectly
referenced array, some of them lack size check on the array elements.

This inserts the missing checks and rejects requests if data of ioctl
does not have a valid format.

We usually don't have to check size of structures that we associated
with ioctl commands because the size is tested implicitly for
identifying ioctl command; the checks this patch adds are for the
cases where the implicit check is not applied.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix lock order reversal in nilfs_clean_segments ioctl</title>
<updated>2009-05-11T05:54:41+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-05-10T13:41:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4f6b828837b4e3836f2c9ac2f0eab9773b6c1327'/>
<id>4f6b828837b4e3836f2c9ac2f0eab9773b6c1327</id>
<content type='text'>
This is a companion patch to ("nilfs2: fix possible circular locking
for get information ioctls").

This corrects lock order reversal between mm-&gt;mmap_sem and
nilfs-&gt;ns_segctor_sem in nilfs_clean_segments() which was detected by
lockdep check:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.30-rc3-nilfs-00003-g360bdc1 #7
 -------------------------------------------------------
 mmap/5294 is trying to acquire lock:
  (&amp;nilfs-&gt;ns_segctor_sem){++++.+}, at: [&lt;d0d0e846&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]

 but task is already holding lock:
  (&amp;mm-&gt;mmap_sem){++++++}, at: [&lt;c043700a&gt;] do_page_fault+0x1d8/0x30a

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;mm-&gt;mmap_sem){++++++}:
        [&lt;c01470a5&gt;] __lock_acquire+0x1066/0x13b0
        [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
        [&lt;c01836bc&gt;] might_fault+0x68/0x88
        [&lt;c023c61d&gt;] copy_from_user+0x2a/0x111
        [&lt;d0d120d0&gt;] nilfs_ioctl_prepare_clean_segments+0x1d/0xf1 [nilfs2]
        [&lt;d0d0e2aa&gt;] nilfs_clean_segments+0x6d/0x1b9 [nilfs2]
        [&lt;d0d11f68&gt;] nilfs_ioctl+0x2ad/0x318 [nilfs2]
        [&lt;c01a3be7&gt;] vfs_ioctl+0x22/0x69
        [&lt;c01a408e&gt;] do_vfs_ioctl+0x460/0x499
        [&lt;c01a4107&gt;] sys_ioctl+0x40/0x5a
        [&lt;c01031a4&gt;] sysenter_do_call+0x12/0x38
        [&lt;ffffffff&gt;] 0xffffffff

 -&gt; #0 (&amp;nilfs-&gt;ns_segctor_sem){++++.+}:
        [&lt;c0146e0b&gt;] __lock_acquire+0xdcc/0x13b0
        [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
        [&lt;c0433f1d&gt;] down_read+0x2a/0x3e
        [&lt;d0d0e846&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
        [&lt;d0cfe0e5&gt;] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
        [&lt;c0183b0b&gt;] __do_fault+0x165/0x376
        [&lt;c01855cd&gt;] handle_mm_fault+0x287/0x5d1
        [&lt;c043712d&gt;] do_page_fault+0x2fb/0x30a
        [&lt;c0435462&gt;] error_code+0x72/0x78
        [&lt;ffffffff&gt;] 0xffffffff

where nilfs_clean_segments() holds:

  nilfs-&gt;ns_segctor_sem -&gt; copy_from_user()
                             --&gt; page fault -&gt; mm-&gt;mmap_sem

And, page fault path may hold:

  page fault -&gt; mm-&gt;mmap_sem
         --&gt; nilfs_page_mkwrite() -&gt; nilfs-&gt;ns_segctor_sem

Even though nilfs_clean_segments() does not perform write access on
given user pages, it may cause deadlock because nilfs-&gt;ns_segctor_sem
is shared per device and mm-&gt;mmap_sem can be shared with other tasks.

To avoid this problem, this patch moves all calls of copy_from_user()
outside the nilfs-&gt;ns_segctor_sem lock in the ioctl.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a companion patch to ("nilfs2: fix possible circular locking
for get information ioctls").

This corrects lock order reversal between mm-&gt;mmap_sem and
nilfs-&gt;ns_segctor_sem in nilfs_clean_segments() which was detected by
lockdep check:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.30-rc3-nilfs-00003-g360bdc1 #7
 -------------------------------------------------------
 mmap/5294 is trying to acquire lock:
  (&amp;nilfs-&gt;ns_segctor_sem){++++.+}, at: [&lt;d0d0e846&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]

 but task is already holding lock:
  (&amp;mm-&gt;mmap_sem){++++++}, at: [&lt;c043700a&gt;] do_page_fault+0x1d8/0x30a

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;mm-&gt;mmap_sem){++++++}:
        [&lt;c01470a5&gt;] __lock_acquire+0x1066/0x13b0
        [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
        [&lt;c01836bc&gt;] might_fault+0x68/0x88
        [&lt;c023c61d&gt;] copy_from_user+0x2a/0x111
        [&lt;d0d120d0&gt;] nilfs_ioctl_prepare_clean_segments+0x1d/0xf1 [nilfs2]
        [&lt;d0d0e2aa&gt;] nilfs_clean_segments+0x6d/0x1b9 [nilfs2]
        [&lt;d0d11f68&gt;] nilfs_ioctl+0x2ad/0x318 [nilfs2]
        [&lt;c01a3be7&gt;] vfs_ioctl+0x22/0x69
        [&lt;c01a408e&gt;] do_vfs_ioctl+0x460/0x499
        [&lt;c01a4107&gt;] sys_ioctl+0x40/0x5a
        [&lt;c01031a4&gt;] sysenter_do_call+0x12/0x38
        [&lt;ffffffff&gt;] 0xffffffff

 -&gt; #0 (&amp;nilfs-&gt;ns_segctor_sem){++++.+}:
        [&lt;c0146e0b&gt;] __lock_acquire+0xdcc/0x13b0
        [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
        [&lt;c0433f1d&gt;] down_read+0x2a/0x3e
        [&lt;d0d0e846&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
        [&lt;d0cfe0e5&gt;] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
        [&lt;c0183b0b&gt;] __do_fault+0x165/0x376
        [&lt;c01855cd&gt;] handle_mm_fault+0x287/0x5d1
        [&lt;c043712d&gt;] do_page_fault+0x2fb/0x30a
        [&lt;c0435462&gt;] error_code+0x72/0x78
        [&lt;ffffffff&gt;] 0xffffffff

where nilfs_clean_segments() holds:

  nilfs-&gt;ns_segctor_sem -&gt; copy_from_user()
                             --&gt; page fault -&gt; mm-&gt;mmap_sem

And, page fault path may hold:

  page fault -&gt; mm-&gt;mmap_sem
         --&gt; nilfs_page_mkwrite() -&gt; nilfs-&gt;ns_segctor_sem

Even though nilfs_clean_segments() does not perform write access on
given user pages, it may cause deadlock because nilfs-&gt;ns_segctor_sem
is shared per device and mm-&gt;mmap_sem can be shared with other tasks.

To avoid this problem, this patch moves all calls of copy_from_user()
outside the nilfs-&gt;ns_segctor_sem lock in the ioctl.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix possible circular locking for get information ioctls</title>
<updated>2009-05-11T03:57:46+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-04-29T17:21:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=47eb6b9c8fa963c9f49967ad1d9d7ec947d15b68'/>
<id>47eb6b9c8fa963c9f49967ad1d9d7ec947d15b68</id>
<content type='text'>
This is one of two patches which are to correct possible circular
locking between mm-&gt;mmap_sem and nilfs-&gt;ns_segctor_sem.

The problem was detected by lockdep check as follows:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.30-rc3-nilfs-00002-g3552613 #6
 -------------------------------------------------------
 mmap/5418 is trying to acquire lock:
 (&amp;nilfs-&gt;ns_segctor_sem){++++.+}, at: [&lt;d0d0e852&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]

 but task is already holding lock:
 (&amp;mm-&gt;mmap_sem){++++++}, at: [&lt;c043700a&gt;] do_page_fault+0x1d8/0x30a

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;mm-&gt;mmap_sem){++++++}:
 [&lt;c01470a5&gt;] __lock_acquire+0x1066/0x13b0
 [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
 [&lt;c01836bc&gt;] might_fault+0x68/0x88
 [&lt;c023c730&gt;] copy_to_user+0x2c/0xfc
 [&lt;d0d11b4f&gt;] nilfs_ioctl_wrap_copy+0x103/0x160 [nilfs2]
 [&lt;d0d11fa9&gt;] nilfs_ioctl+0x30a/0x3b0 [nilfs2]
 [&lt;c01a3be7&gt;] vfs_ioctl+0x22/0x69
 [&lt;c01a408e&gt;] do_vfs_ioctl+0x460/0x499
 [&lt;c01a4107&gt;] sys_ioctl+0x40/0x5a
 [&lt;c01031a4&gt;] sysenter_do_call+0x12/0x38
 [&lt;ffffffff&gt;] 0xffffffff

 -&gt; #0 (&amp;nilfs-&gt;ns_segctor_sem){++++.+}:
 [&lt;c0146e0b&gt;] __lock_acquire+0xdcc/0x13b0
 [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
 [&lt;c0433f1d&gt;] down_read+0x2a/0x3e
 [&lt;d0d0e852&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;d0cfe0e5&gt;] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
 [&lt;c0183b0b&gt;] __do_fault+0x165/0x376
 [&lt;c01855cd&gt;] handle_mm_fault+0x287/0x5d1
 [&lt;c043712d&gt;] do_page_fault+0x2fb/0x30a
 [&lt;c0435462&gt;] error_code+0x72/0x78
 [&lt;ffffffff&gt;] 0xffffffff

 other info that might help us debug this:

 1 lock held by mmap/5418:
 #0:  (&amp;mm-&gt;mmap_sem){++++++}, at: [&lt;c043700a&gt;] do_page_fault+0x1d8/0x30a

 stack backtrace:
 Pid: 5418, comm: mmap Not tainted 2.6.30-rc3-nilfs-00002-g3552613 #6
 Call Trace:
 [&lt;c0432145&gt;] ? printk+0xf/0x12
 [&lt;c0145c48&gt;] print_circular_bug_tail+0xaa/0xb5
 [&lt;c0146e0b&gt;] __lock_acquire+0xdcc/0x13b0
 [&lt;d0d10149&gt;] ? nilfs_sufile_get_stat+0x1e/0x105 [nilfs2]
 [&lt;c013b59a&gt;] ? up_read+0x16/0x2c
 [&lt;d0d10225&gt;] ? nilfs_sufile_get_stat+0xfa/0x105 [nilfs2]
 [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
 [&lt;d0d0e852&gt;] ? nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;c0433f1d&gt;] down_read+0x2a/0x3e
 [&lt;d0d0e852&gt;] ? nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;d0d0e852&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;d0cfe0e5&gt;] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
 [&lt;c0183b0b&gt;] __do_fault+0x165/0x376
 [&lt;c01855cd&gt;] handle_mm_fault+0x287/0x5d1
 [&lt;c043700a&gt;] ? do_page_fault+0x1d8/0x30a
 [&lt;c013b54f&gt;] ? down_read_trylock+0x39/0x43
 [&lt;c043712d&gt;] do_page_fault+0x2fb/0x30a
 [&lt;c0436e32&gt;] ? do_page_fault+0x0/0x30a
 [&lt;c0435462&gt;] error_code+0x72/0x78
 [&lt;c0436e32&gt;] ? do_page_fault+0x0/0x30a

This makes the lock granularity of nilfs-&gt;ns_segctor_sem finer than
that of the mmap semaphore for ioctl commands except
nilfs_clean_segments().

The successive patch ("nilfs2: fix lock order reversal in
nilfs_clean_segments ioctl") is required to fully resolve the problem.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is one of two patches which are to correct possible circular
locking between mm-&gt;mmap_sem and nilfs-&gt;ns_segctor_sem.

The problem was detected by lockdep check as follows:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.30-rc3-nilfs-00002-g3552613 #6
 -------------------------------------------------------
 mmap/5418 is trying to acquire lock:
 (&amp;nilfs-&gt;ns_segctor_sem){++++.+}, at: [&lt;d0d0e852&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]

 but task is already holding lock:
 (&amp;mm-&gt;mmap_sem){++++++}, at: [&lt;c043700a&gt;] do_page_fault+0x1d8/0x30a

 which lock already depends on the new lock.

 the existing dependency chain (in reverse order) is:

 -&gt; #1 (&amp;mm-&gt;mmap_sem){++++++}:
 [&lt;c01470a5&gt;] __lock_acquire+0x1066/0x13b0
 [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
 [&lt;c01836bc&gt;] might_fault+0x68/0x88
 [&lt;c023c730&gt;] copy_to_user+0x2c/0xfc
 [&lt;d0d11b4f&gt;] nilfs_ioctl_wrap_copy+0x103/0x160 [nilfs2]
 [&lt;d0d11fa9&gt;] nilfs_ioctl+0x30a/0x3b0 [nilfs2]
 [&lt;c01a3be7&gt;] vfs_ioctl+0x22/0x69
 [&lt;c01a408e&gt;] do_vfs_ioctl+0x460/0x499
 [&lt;c01a4107&gt;] sys_ioctl+0x40/0x5a
 [&lt;c01031a4&gt;] sysenter_do_call+0x12/0x38
 [&lt;ffffffff&gt;] 0xffffffff

 -&gt; #0 (&amp;nilfs-&gt;ns_segctor_sem){++++.+}:
 [&lt;c0146e0b&gt;] __lock_acquire+0xdcc/0x13b0
 [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
 [&lt;c0433f1d&gt;] down_read+0x2a/0x3e
 [&lt;d0d0e852&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;d0cfe0e5&gt;] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
 [&lt;c0183b0b&gt;] __do_fault+0x165/0x376
 [&lt;c01855cd&gt;] handle_mm_fault+0x287/0x5d1
 [&lt;c043712d&gt;] do_page_fault+0x2fb/0x30a
 [&lt;c0435462&gt;] error_code+0x72/0x78
 [&lt;ffffffff&gt;] 0xffffffff

 other info that might help us debug this:

 1 lock held by mmap/5418:
 #0:  (&amp;mm-&gt;mmap_sem){++++++}, at: [&lt;c043700a&gt;] do_page_fault+0x1d8/0x30a

 stack backtrace:
 Pid: 5418, comm: mmap Not tainted 2.6.30-rc3-nilfs-00002-g3552613 #6
 Call Trace:
 [&lt;c0432145&gt;] ? printk+0xf/0x12
 [&lt;c0145c48&gt;] print_circular_bug_tail+0xaa/0xb5
 [&lt;c0146e0b&gt;] __lock_acquire+0xdcc/0x13b0
 [&lt;d0d10149&gt;] ? nilfs_sufile_get_stat+0x1e/0x105 [nilfs2]
 [&lt;c013b59a&gt;] ? up_read+0x16/0x2c
 [&lt;d0d10225&gt;] ? nilfs_sufile_get_stat+0xfa/0x105 [nilfs2]
 [&lt;c01474a9&gt;] lock_acquire+0xba/0xdd
 [&lt;d0d0e852&gt;] ? nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;c0433f1d&gt;] down_read+0x2a/0x3e
 [&lt;d0d0e852&gt;] ? nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;d0d0e852&gt;] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
 [&lt;d0cfe0e5&gt;] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
 [&lt;c0183b0b&gt;] __do_fault+0x165/0x376
 [&lt;c01855cd&gt;] handle_mm_fault+0x287/0x5d1
 [&lt;c043700a&gt;] ? do_page_fault+0x1d8/0x30a
 [&lt;c013b54f&gt;] ? down_read_trylock+0x39/0x43
 [&lt;c043712d&gt;] do_page_fault+0x2fb/0x30a
 [&lt;c0436e32&gt;] ? do_page_fault+0x0/0x30a
 [&lt;c0435462&gt;] error_code+0x72/0x78
 [&lt;c0436e32&gt;] ? do_page_fault+0x0/0x30a

This makes the lock granularity of nilfs-&gt;ns_segctor_sem finer than
that of the mmap semaphore for ioctl commands except
nilfs_clean_segments().

The successive patch ("nilfs2: fix lock order reversal in
nilfs_clean_segments ioctl") is required to fully resolve the problem.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: ensure to clear dirty state when deleting metadata file block</title>
<updated>2009-05-10T08:04:42+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-05-05T12:52:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=843382370ec614768ac13582405f93635cf3637c'/>
<id>843382370ec614768ac13582405f93635cf3637c</id>
<content type='text'>
This would fix the following failure during GC:

 nilfs_cpfile_delete_checkpoints: cannot delete block
 NILFS: GC failed during preparation: cannot delete checkpoints: err=-2

The problem was caused by a break in state consistency between page
cache and btree; the above block was removed from the btree but the
page buffering the block was remaining in the page cache in dirty
state.

This resolves the inconsistency by ensuring to clear dirty state of
the page buffering the deleted block.

Reported-by: David Arendt &lt;admin@prnet.org&gt;
Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This would fix the following failure during GC:

 nilfs_cpfile_delete_checkpoints: cannot delete block
 NILFS: GC failed during preparation: cannot delete checkpoints: err=-2

The problem was caused by a break in state consistency between page
cache and btree; the above block was removed from the btree but the
page buffering the block was remaining in the page cache in dirty
state.

This resolves the inconsistency by ensuring to clear dirty state of
the page buffering the deleted block.

Reported-by: David Arendt &lt;admin@prnet.org&gt;
Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix circular locking dependency of writer mutex</title>
<updated>2009-05-09T04:36:57+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-04-28T12:04:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=201913ed746c7724a40d33ee5a0b6a1fd2ef3193'/>
<id>201913ed746c7724a40d33ee5a0b6a1fd2ef3193</id>
<content type='text'>
This fixes the following circular locking dependency problem:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.30-rc3 #5
 -------------------------------------------------------
 segctord/3895 is trying to acquire lock:
  (&amp;nilfs-&gt;ns_writer_mutex){+.+...}, at: [&lt;d0d02172&gt;]
   nilfs_mdt_get_block+0x89/0x20f [nilfs2]

 but task is already holding lock:
  (&amp;bmap-&gt;b_sem){++++..}, at: [&lt;d0d02d99&gt;]
   nilfs_bmap_propagate+0x14/0x2e [nilfs2]

 which lock already depends on the new lock.

The bugfix is done by replacing call sites of nilfs_get_writer() which
are never called from read-only context with direct dereferencing of
pointer to a writable FS-instance.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the following circular locking dependency problem:

 =======================================================
 [ INFO: possible circular locking dependency detected ]
 2.6.30-rc3 #5
 -------------------------------------------------------
 segctord/3895 is trying to acquire lock:
  (&amp;nilfs-&gt;ns_writer_mutex){+.+...}, at: [&lt;d0d02172&gt;]
   nilfs_mdt_get_block+0x89/0x20f [nilfs2]

 but task is already holding lock:
  (&amp;bmap-&gt;b_sem){++++..}, at: [&lt;d0d02d99&gt;]
   nilfs_bmap_propagate+0x14/0x2e [nilfs2]

 which lock already depends on the new lock.

The bugfix is done by replacing call sites of nilfs_get_writer() which
are never called from read-only context with direct dereferencing of
pointer to a writable FS-instance.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix possible recovery failure due to block creation without writer</title>
<updated>2009-05-09T04:36:56+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-04-28T14:38:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=85c2a74fabadfc561b75fbd7decc6bcbfe873d57'/>
<id>85c2a74fabadfc561b75fbd7decc6bcbfe873d57</id>
<content type='text'>
Some function calls in nilfs_prepare_segment_for_recovery() may fail
because they can create blocks on meta data files without configuring
a writable FS-instance.  Concretely, nilfs_mdt_create_block() routine
of meta data files will fail in that case.

This fixes the problem by temporarily attaching a writable FS-instace
during the function is called.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some function calls in nilfs_prepare_segment_for_recovery() may fail
because they can create blocks on meta data files without configuring
a writable FS-instance.  Concretely, nilfs_mdt_create_block() routine
of meta data files will fail in that case.

This fixes the problem by temporarily attaching a writable FS-instace
during the function is called.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: fix possible mismatch of sufile counters on recovery</title>
<updated>2009-04-13T00:53:52+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-04-05T09:30:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c85399c2da8b86de8f6877980294fa1a4a88a5a4'/>
<id>c85399c2da8b86de8f6877980294fa1a4a88a5a4</id>
<content type='text'>
On-disk counters ndirtysegs and ncleansegs of sufile, can go wrong
after roll-forward recovery because
nilfs_prepare_segment_for_recovery() function marks segments dirty
without adjusting value of these counters.

This fixes the problem by adding a function to sufile which does the
operation adjusting the counters, and by letting the recovery function
use it.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
On-disk counters ndirtysegs and ncleansegs of sufile, can go wrong
after roll-forward recovery because
nilfs_prepare_segment_for_recovery() function marks segments dirty
without adjusting value of these counters.

This fixes the problem by adding a function to sufile which does the
operation adjusting the counters, and by letting the recovery function
use it.

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nilfs2: segment usage file cleanups</title>
<updated>2009-04-13T00:53:51+00:00</updated>
<author>
<name>Ryusuke Konishi</name>
<email>konishi.ryusuke@lab.ntt.co.jp</email>
</author>
<published>2009-04-05T09:24:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a703018f7bbec8109419318f5d51f235fdce5155'/>
<id>a703018f7bbec8109419318f5d51f235fdce5155</id>
<content type='text'>
This will simplify sufile.c by sharing common code which repeatedly
appears in routines updating a segment usage entry; a wrapper function
nilfs_sufile_update() is introduced for the purpose, and counter
modifications are integrated to a new function
nilfs_sufile_mod_counter().

This is a preparation for the successive bugfix patch ("nilfs2: fix
possible mismatch of sufile counters on recovery").

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This will simplify sufile.c by sharing common code which repeatedly
appears in routines updating a segment usage entry; a wrapper function
nilfs_sufile_update() is introduced for the purpose, and counter
modifications are integrated to a new function
nilfs_sufile_mod_counter().

This is a preparation for the successive bugfix patch ("nilfs2: fix
possible mismatch of sufile counters on recovery").

Signed-off-by: Ryusuke Konishi &lt;konishi.ryusuke@lab.ntt.co.jp&gt;
</pre>
</div>
</content>
</entry>
</feed>
