<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs, branch v3.16-rc5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4</title>
<updated>2014-07-13T20:14:55+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-07-13T20:14:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=18b34d9a7a085ba8f9cafa6a0d002e2cbac87c1f'/>
<id>18b34d9a7a085ba8f9cafa6a0d002e2cbac87c1f</id>
<content type='text'>
Pull ext4 bugfixes from Ted Ts'o:
 "More bug fixes for ext4 -- most importantly, a fix for a bug
  introduced in 3.15 that can end up triggering a file system corruption
  error after a journal replay.

  It shouldn't lead to any actual data corruption, but it is scary and
  can force file systems to be remounted read-only, etc"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: fix potential null pointer dereference in ext4_free_inode
  ext4: fix a potential deadlock in __ext4_es_shrink()
  ext4: revert commit which was causing fs corruption after journal replays
  ext4: disable synchronous transaction batching if max_batch_time==0
  ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
  ext4: clarify error count warning messages
  ext4: fix unjournalled bg descriptor while initializing inode bitmap
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ext4 bugfixes from Ted Ts'o:
 "More bug fixes for ext4 -- most importantly, a fix for a bug
  introduced in 3.15 that can end up triggering a file system corruption
  error after a journal replay.

  It shouldn't lead to any actual data corruption, but it is scary and
  can force file systems to be remounted read-only, etc"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: fix potential null pointer dereference in ext4_free_inode
  ext4: fix a potential deadlock in __ext4_es_shrink()
  ext4: revert commit which was causing fs corruption after journal replays
  ext4: disable synchronous transaction batching if max_batch_time==0
  ext4: clarify ext4_error message in ext4_mb_generate_buddy_error()
  ext4: clarify error count warning messages
  ext4: fix unjournalled bg descriptor while initializing inode bitmap
</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: fix potential null pointer dereference in ext4_free_inode</title>
<updated>2014-07-12T20:11:42+00:00</updated>
<author>
<name>Namjae Jeon</name>
<email>namjae.jeon@samsung.com</email>
</author>
<published>2014-07-12T20:11:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bf40c92635d63fcc574c52649f7cda13e0418ac1'/>
<id>bf40c92635d63fcc574c52649f7cda13e0418ac1</id>
<content type='text'>
Fix potential null pointer dereferencing problem caused by e43bb4e612
("ext4: decrement free clusters/inodes counters when block group declared bad")

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Namjae Jeon &lt;namjae.jeon@samsung.com&gt;
Signed-off-by: Ashish Sangwan &lt;a.sangwan@samsung.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Lukas Czerner &lt;lczerner@redhat.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix potential null pointer dereferencing problem caused by e43bb4e612
("ext4: decrement free clusters/inodes counters when block group declared bad")

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Namjae Jeon &lt;namjae.jeon@samsung.com&gt;
Signed-off-by: Ashish Sangwan &lt;a.sangwan@samsung.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reviewed-by: Lukas Czerner &lt;lczerner@redhat.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: fix a potential deadlock in __ext4_es_shrink()</title>
<updated>2014-07-12T19:32:24+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-07-12T19:32:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3f1f9b851311a76226140b55b1ea22111234a7c2'/>
<id>3f1f9b851311a76226140b55b1ea22111234a7c2</id>
<content type='text'>
This fixes the following lockdep complaint:

[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G           O  
-------------------------------------------------------
kworker/u24:0/4356 is trying to acquire lock:
 (&amp;(&amp;sbi-&gt;s_es_lru_lock)-&gt;rlock){+.+.-.}, at: [&lt;ffffffff81285fff&gt;] __ext4_es_shrink+0x4f/0x2e0

but task is already holding lock:
 (&amp;ei-&gt;i_es_lock){++++-.}, at: [&lt;ffffffff81286961&gt;] ext4_es_insert_extent+0x71/0x180

which lock already depends on the new lock.

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;ei-&gt;i_es_lock);
                               lock(&amp;(&amp;sbi-&gt;s_es_lru_lock)-&gt;rlock);
                               lock(&amp;ei-&gt;i_es_lock);
  lock(&amp;(&amp;sbi-&gt;s_es_lru_lock)-&gt;rlock);

 *** DEADLOCK ***

6 locks held by kworker/u24:0/4356:
 #0:  ("writeback"){.+.+.+}, at: [&lt;ffffffff81071d00&gt;] process_one_work+0x180/0x560
 #1:  ((&amp;(&amp;wb-&gt;dwork)-&gt;work)){+.+.+.}, at: [&lt;ffffffff81071d00&gt;] process_one_work+0x180/0x560
 #2:  (&amp;type-&gt;s_umount_key#22){++++++}, at: [&lt;ffffffff811a9c74&gt;] grab_super_passive+0x44/0x90
 #3:  (jbd2_handle){+.+...}, at: [&lt;ffffffff812979f9&gt;] start_this_handle+0x189/0x5f0
 #4:  (&amp;ei-&gt;i_data_sem){++++..}, at: [&lt;ffffffff81247062&gt;] ext4_map_blocks+0x132/0x550
 #5:  (&amp;ei-&gt;i_es_lock){++++-.}, at: [&lt;ffffffff81286961&gt;] ext4_es_insert_extent+0x71/0x180

stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G           O   3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
 ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007
 ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568
 ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930
Call Trace:
 [&lt;ffffffff815df0bb&gt;] dump_stack+0x4e/0x68
 [&lt;ffffffff815db3dd&gt;] print_circular_bug+0x1fb/0x20c
 [&lt;ffffffff810a7a3e&gt;] __lock_acquire+0x163e/0x1d00
 [&lt;ffffffff815e89dc&gt;] ? retint_restore_args+0xe/0xe
 [&lt;ffffffff815ddc7b&gt;] ? __slab_alloc+0x4a8/0x4ce
 [&lt;ffffffff81285fff&gt;] ? __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff810a8707&gt;] lock_acquire+0x87/0x120
 [&lt;ffffffff81285fff&gt;] ? __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff8128592d&gt;] ? ext4_es_free_extent+0x5d/0x70
 [&lt;ffffffff815e6f09&gt;] _raw_spin_lock+0x39/0x50
 [&lt;ffffffff81285fff&gt;] ? __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff8119760b&gt;] ? kmem_cache_alloc+0x18b/0x1a0
 [&lt;ffffffff81285fff&gt;] __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff812869b8&gt;] ext4_es_insert_extent+0xc8/0x180
 [&lt;ffffffff812470f4&gt;] ext4_map_blocks+0x1c4/0x550
 [&lt;ffffffff8124c4c4&gt;] ext4_writepages+0x6d4/0xd00
	...

Reported-by: Minchan Kim &lt;minchan@kernel.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reported-by: Minchan Kim &lt;minchan@kernel.org&gt;
Cc: stable@vger.kernel.org
Cc: Zheng Liu &lt;gnehzuil.liu@gmail.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes the following lockdep complaint:

[ INFO: possible circular locking dependency detected ]
3.16.0-rc2-mm1+ #7 Tainted: G           O  
-------------------------------------------------------
kworker/u24:0/4356 is trying to acquire lock:
 (&amp;(&amp;sbi-&gt;s_es_lru_lock)-&gt;rlock){+.+.-.}, at: [&lt;ffffffff81285fff&gt;] __ext4_es_shrink+0x4f/0x2e0

but task is already holding lock:
 (&amp;ei-&gt;i_es_lock){++++-.}, at: [&lt;ffffffff81286961&gt;] ext4_es_insert_extent+0x71/0x180

which lock already depends on the new lock.

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&amp;ei-&gt;i_es_lock);
                               lock(&amp;(&amp;sbi-&gt;s_es_lru_lock)-&gt;rlock);
                               lock(&amp;ei-&gt;i_es_lock);
  lock(&amp;(&amp;sbi-&gt;s_es_lru_lock)-&gt;rlock);

 *** DEADLOCK ***

6 locks held by kworker/u24:0/4356:
 #0:  ("writeback"){.+.+.+}, at: [&lt;ffffffff81071d00&gt;] process_one_work+0x180/0x560
 #1:  ((&amp;(&amp;wb-&gt;dwork)-&gt;work)){+.+.+.}, at: [&lt;ffffffff81071d00&gt;] process_one_work+0x180/0x560
 #2:  (&amp;type-&gt;s_umount_key#22){++++++}, at: [&lt;ffffffff811a9c74&gt;] grab_super_passive+0x44/0x90
 #3:  (jbd2_handle){+.+...}, at: [&lt;ffffffff812979f9&gt;] start_this_handle+0x189/0x5f0
 #4:  (&amp;ei-&gt;i_data_sem){++++..}, at: [&lt;ffffffff81247062&gt;] ext4_map_blocks+0x132/0x550
 #5:  (&amp;ei-&gt;i_es_lock){++++-.}, at: [&lt;ffffffff81286961&gt;] ext4_es_insert_extent+0x71/0x180

stack backtrace:
CPU: 0 PID: 4356 Comm: kworker/u24:0 Tainted: G           O   3.16.0-rc2-mm1+ #7
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Workqueue: writeback bdi_writeback_workfn (flush-253:0)
 ffffffff8213dce0 ffff880014b07538 ffffffff815df0bb 0000000000000007
 ffffffff8213e040 ffff880014b07588 ffffffff815db3dd ffff880014b07568
 ffff880014b07610 ffff88003b868930 ffff88003b868908 ffff88003b868930
Call Trace:
 [&lt;ffffffff815df0bb&gt;] dump_stack+0x4e/0x68
 [&lt;ffffffff815db3dd&gt;] print_circular_bug+0x1fb/0x20c
 [&lt;ffffffff810a7a3e&gt;] __lock_acquire+0x163e/0x1d00
 [&lt;ffffffff815e89dc&gt;] ? retint_restore_args+0xe/0xe
 [&lt;ffffffff815ddc7b&gt;] ? __slab_alloc+0x4a8/0x4ce
 [&lt;ffffffff81285fff&gt;] ? __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff810a8707&gt;] lock_acquire+0x87/0x120
 [&lt;ffffffff81285fff&gt;] ? __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff8128592d&gt;] ? ext4_es_free_extent+0x5d/0x70
 [&lt;ffffffff815e6f09&gt;] _raw_spin_lock+0x39/0x50
 [&lt;ffffffff81285fff&gt;] ? __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff8119760b&gt;] ? kmem_cache_alloc+0x18b/0x1a0
 [&lt;ffffffff81285fff&gt;] __ext4_es_shrink+0x4f/0x2e0
 [&lt;ffffffff812869b8&gt;] ext4_es_insert_extent+0xc8/0x180
 [&lt;ffffffff812470f4&gt;] ext4_map_blocks+0x1c4/0x550
 [&lt;ffffffff8124c4c4&gt;] ext4_writepages+0x6d4/0xd00
	...

Reported-by: Minchan Kim &lt;minchan@kernel.org&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;
Reported-by: Minchan Kim &lt;minchan@kernel.org&gt;
Cc: stable@vger.kernel.org
Cc: Zheng Liu &lt;gnehzuil.liu@gmail.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-3.16' of git://linux-nfs.org/~bfields/linux</title>
<updated>2014-07-11T22:10:04+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-07-11T22:10:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=bae78dc25993f62194ee53da67b14e3d5007c6c4'/>
<id>bae78dc25993f62194ee53da67b14e3d5007c6c4</id>
<content type='text'>
Pull nfsd bugfix from Bruce Fields:
 "Another xdr encoding regression that may cause incorrect encoding on
  failures of certain readdirs"

* 'for-3.16' of git://linux-nfs.org/~bfields/linux:
  nfsd: Fix bad reserving space for encoding rdattr_error
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull nfsd bugfix from Bruce Fields:
 "Another xdr encoding regression that may cause incorrect encoding on
  failures of certain readdirs"

* 'for-3.16' of git://linux-nfs.org/~bfields/linux:
  nfsd: Fix bad reserving space for encoding rdattr_error
</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: revert commit which was causing fs corruption after journal replays</title>
<updated>2014-07-11T17:55:40+00:00</updated>
<author>
<name>Theodore Ts'o</name>
<email>tytso@mit.edu</email>
</author>
<published>2014-07-11T17:55:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=f9ae9cf5d72b3926ca48ea60e15bdbb840f42372'/>
<id>f9ae9cf5d72b3926ca48ea60e15bdbb840f42372</id>
<content type='text'>
Commit 007649375f6af2 ("ext4: initialize multi-block allocator before
checking block descriptors") causes the block group descriptor's count
of the number of free blocks to become inconsistent with the number of
free blocks in the allocation bitmap.  This is a harmless form of fs
corruption, but it causes the kernel to potentially remount the file
system read-only, or to panic, depending on the file systems's error
behavior.

Thanks to Eric Whitney for his tireless work to reproduce and to find
the guilty commit.

Fixes: 007649375f6af2 ("ext4: initialize multi-block allocator before checking block descriptors"

Cc: stable@vger.kernel.org  # 3.15
Reported-by: David Jander &lt;david@protonic.nl&gt;
Reported-by: Matteo Croce &lt;technoboy85@gmail.com&gt;
Tested-by: Eric Whitney &lt;enwlinux@gmail.com&gt;
Suggested-by: Eric Whitney &lt;enwlinux@gmail.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 007649375f6af2 ("ext4: initialize multi-block allocator before
checking block descriptors") causes the block group descriptor's count
of the number of free blocks to become inconsistent with the number of
free blocks in the allocation bitmap.  This is a harmless form of fs
corruption, but it causes the kernel to potentially remount the file
system read-only, or to panic, depending on the file systems's error
behavior.

Thanks to Eric Whitney for his tireless work to reproduce and to find
the guilty commit.

Fixes: 007649375f6af2 ("ext4: initialize multi-block allocator before checking block descriptors"

Cc: stable@vger.kernel.org  # 3.15
Reported-by: David Jander &lt;david@protonic.nl&gt;
Reported-by: Matteo Croce &lt;technoboy85@gmail.com&gt;
Tested-by: Eric Whitney &lt;enwlinux@gmail.com&gt;
Suggested-by: Eric Whitney &lt;enwlinux@gmail.com&gt;
Signed-off-by: Theodore Ts'o &lt;tytso@mit.edu&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup</title>
<updated>2014-07-10T18:38:23+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-07-10T18:38:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=40f6123737d45b94ae0e4c89252a695ba6794e59'/>
<id>40f6123737d45b94ae0e4c89252a695ba6794e59</id>
<content type='text'>
Pull cgroup fixes from Tejun Heo:
 "Mostly fixes for the fallouts from the recent cgroup core changes.

  The decoupled nature of cgroup dynamic hierarchy management
  (hierarchies are created dynamically on mount but may or may not be
  reused once unmounted depending on remaining usages) led to more
  ugliness being added to kernfs.

  Hopefully, this is the last of it"

* 'for-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cpuset: break kernfs active protection in cpuset_write_resmask()
  cgroup: fix a race between cgroup_mount() and cgroup_kill_sb()
  kernfs: introduce kernfs_pin_sb()
  cgroup: fix mount failure in a corner case
  cpuset,mempolicy: fix sleeping function called from invalid context
  cgroup: fix broken css_has_online_children()
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull cgroup fixes from Tejun Heo:
 "Mostly fixes for the fallouts from the recent cgroup core changes.

  The decoupled nature of cgroup dynamic hierarchy management
  (hierarchies are created dynamically on mount but may or may not be
  reused once unmounted depending on remaining usages) led to more
  ugliness being added to kernfs.

  Hopefully, this is the last of it"

* 'for-3.16-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cpuset: break kernfs active protection in cpuset_write_resmask()
  cgroup: fix a race between cgroup_mount() and cgroup_kill_sb()
  kernfs: introduce kernfs_pin_sb()
  cgroup: fix mount failure in a corner case
  cpuset,mempolicy: fix sleeping function called from invalid context
  cgroup: fix broken css_has_online_children()
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'f2fs-fixes-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs</title>
<updated>2014-07-09T16:46:58+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2014-07-09T16:46:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=191d385f253a317ed905b06137b48e5990e700cf'/>
<id>191d385f253a317ed905b06137b48e5990e700cf</id>
<content type='text'>
Pull f2fs bugfixes from Jaegeuk Kim:
 "This includes a couple of bug fixes found by xfstests.  In addition,
  one critical bug was reported by Brian Chadwick, which is falling into
  the infinite loop in balance_dirty_pages.  And it turned out due to
  the IO merging policy in f2fs, which was newly merged in 3.16.

   - fix normal and recovery path for fallocated regions
   - fix error case mishandling
   - recover renamed fsync inodes correctly
   - fix to get out of infinite loops in balance_dirty_pages
   - fix kernel NULL pointer error"

* tag 'f2fs-fixes-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs:
  f2fs: avoid to access NULL pointer in issue_flush_thread
  f2fs: check bdi-&gt;dirty_exceeded when trying to skip data writes
  f2fs: do checkpoint for the renamed inode
  f2fs: release new entry page correctly in error path of f2fs_rename
  f2fs: fix error path in init_inode_metadata
  f2fs: check lower bound nid value in check_nid_range
  f2fs: remove unused variables in f2fs_sm_info
  f2fs: fix not to allocate unnecessary blocks during fallocate
  f2fs: recover fallocated data and its i_size together
  f2fs: fix to report newly allocate region as extent
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull f2fs bugfixes from Jaegeuk Kim:
 "This includes a couple of bug fixes found by xfstests.  In addition,
  one critical bug was reported by Brian Chadwick, which is falling into
  the infinite loop in balance_dirty_pages.  And it turned out due to
  the IO merging policy in f2fs, which was newly merged in 3.16.

   - fix normal and recovery path for fallocated regions
   - fix error case mishandling
   - recover renamed fsync inodes correctly
   - fix to get out of infinite loops in balance_dirty_pages
   - fix kernel NULL pointer error"

* tag 'f2fs-fixes-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs:
  f2fs: avoid to access NULL pointer in issue_flush_thread
  f2fs: check bdi-&gt;dirty_exceeded when trying to skip data writes
  f2fs: do checkpoint for the renamed inode
  f2fs: release new entry page correctly in error path of f2fs_rename
  f2fs: fix error path in init_inode_metadata
  f2fs: check lower bound nid value in check_nid_range
  f2fs: remove unused variables in f2fs_sm_info
  f2fs: fix not to allocate unnecessary blocks during fallocate
  f2fs: recover fallocated data and its i_size together
  f2fs: fix to report newly allocate region as extent
</pre>
</div>
</content>
</entry>
<entry>
<title>f2fs: avoid to access NULL pointer in issue_flush_thread</title>
<updated>2014-07-09T12:59:55+00:00</updated>
<author>
<name>Chao Yu</name>
<email>chao2.yu@samsung.com</email>
</author>
<published>2014-07-07T01:39:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=50e1f8d22199b557337b3d1ec8520e4c5aa5c76e'/>
<id>50e1f8d22199b557337b3d1ec8520e4c5aa5c76e</id>
<content type='text'>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75861

Denis 2014-05-10 11:28:59 UTC reported:
"F2FS-fs (mmcblk0p28): mounting..
 Unable to handle kernel NULL pointer dereference at virtual address 00000018
 ...
 [&lt;c0a2f678&gt;] (_raw_spin_lock+0x3c/0x70) from [&lt;c03a0330&gt;] (issue_flush_thread+0x50/0x17c)
 [&lt;c03a0330&gt;] (issue_flush_thread+0x50/0x17c) from [&lt;c01b4064&gt;] (kthread+0x98/0xa4)
 [&lt;c01b4064&gt;] (kthread+0x98/0xa4) from [&lt;c0108060&gt;] (kernel_thread_exit+0x0/0x8)"

This patch assign cmd_control_info in sm_info before issue_flush_thread is being
created, so this make sure that issue flush thread will have no chance to access
invalid info in fcc.

Signed-off-by: Chao Yu &lt;chao2.yu@samsung.com&gt;
Reviewed-by: Gu Zheng &lt;guz.fnst@cn.fujitsu.com&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=75861

Denis 2014-05-10 11:28:59 UTC reported:
"F2FS-fs (mmcblk0p28): mounting..
 Unable to handle kernel NULL pointer dereference at virtual address 00000018
 ...
 [&lt;c0a2f678&gt;] (_raw_spin_lock+0x3c/0x70) from [&lt;c03a0330&gt;] (issue_flush_thread+0x50/0x17c)
 [&lt;c03a0330&gt;] (issue_flush_thread+0x50/0x17c) from [&lt;c01b4064&gt;] (kthread+0x98/0xa4)
 [&lt;c01b4064&gt;] (kthread+0x98/0xa4) from [&lt;c0108060&gt;] (kernel_thread_exit+0x0/0x8)"

This patch assign cmd_control_info in sm_info before issue_flush_thread is being
created, so this make sure that issue flush thread will have no chance to access
invalid info in fcc.

Signed-off-by: Chao Yu &lt;chao2.yu@samsung.com&gt;
Reviewed-by: Gu Zheng &lt;guz.fnst@cn.fujitsu.com&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>f2fs: check bdi-&gt;dirty_exceeded when trying to skip data writes</title>
<updated>2014-07-09T12:59:45+00:00</updated>
<author>
<name>Jaegeuk Kim</name>
<email>jaegeuk@kernel.org</email>
</author>
<published>2014-06-27T16:00:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2743f865543c0c4a5e12fc13edb2bf89a6e9687c'/>
<id>2743f865543c0c4a5e12fc13edb2bf89a6e9687c</id>
<content type='text'>
If we don't check the current backing device status, balance_dirty_pages can
fall into infinite pausing routine.

This can be occurred when a lot of directories make a small number of dirty
dentry pages including files.

Reported-by: Brian Chadwick &lt;brianchad@westnet.com.au&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we don't check the current backing device status, balance_dirty_pages can
fall into infinite pausing routine.

This can be occurred when a lot of directories make a small number of dirty
dentry pages including files.

Reported-by: Brian Chadwick &lt;brianchad@westnet.com.au&gt;
Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>f2fs: do checkpoint for the renamed inode</title>
<updated>2014-07-09T12:59:31+00:00</updated>
<author>
<name>Jaegeuk Kim</name>
<email>jaegeuk@kernel.org</email>
</author>
<published>2014-06-30T09:09:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b2c0829912493df596706a1a036c67beb1bd6ff5'/>
<id>b2c0829912493df596706a1a036c67beb1bd6ff5</id>
<content type='text'>
If an inode is renamed, it should be registered as file_lost_pino to conduct
checkpoint at f2fs_sync_file.
Otherwise, the inode cannot be recovered due to no dent_mark in the following
scenario.

Note that, this scenario is from xfstests/322.

1. create "a"
2. fsync "a"
3. rename "a" to "b"
4. fsync "b"
5. Sudden power-cut

After recovery is done, "b" should be seen.
However, the result shows "a", since the recovery procedure does not enter
recover_dentry due to no dent_mark.

The reason is like below.
- The nid of "a" is checkpointed during #2, f2fs_sync_file.
- The inode page for "b" produced by #3 is written without dent_mark by
sync_node_pages.

So, this patch fixes this bug by assinging file_lost_pino to the "a"'s inode.
If the pino is lost, f2fs_sync_file conducts checkpoint, and then recovers
the latest pino and its dentry information for further recovery.

Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If an inode is renamed, it should be registered as file_lost_pino to conduct
checkpoint at f2fs_sync_file.
Otherwise, the inode cannot be recovered due to no dent_mark in the following
scenario.

Note that, this scenario is from xfstests/322.

1. create "a"
2. fsync "a"
3. rename "a" to "b"
4. fsync "b"
5. Sudden power-cut

After recovery is done, "b" should be seen.
However, the result shows "a", since the recovery procedure does not enter
recover_dentry due to no dent_mark.

The reason is like below.
- The nid of "a" is checkpointed during #2, f2fs_sync_file.
- The inode page for "b" produced by #3 is written without dent_mark by
sync_node_pages.

So, this patch fixes this bug by assinging file_lost_pino to the "a"'s inode.
If the pino is lost, f2fs_sync_file conducts checkpoint, and then recovers
the latest pino and its dentry information for further recovery.

Signed-off-by: Jaegeuk Kim &lt;jaegeuk@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
