<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs, branch v3.12-rc4</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs</title>
<updated>2013-10-05T19:17:24+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-10-05T19:17:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e62063d69911886a5a92c719d262a2a87e1e5b60'/>
<id>e62063d69911886a5a92c719d262a2a87e1e5b60</id>
<content type='text'>
Pull btrfs fixes from Chris Mason:
 "This is a small collection of fixes, including a regression fix from
  Liu Bo that solves rare crashes with compression on.

  I've merged my for-linus up to 3.12-rc3 because the top commit is only
  meant for 3.12.  The rest of the fixes are also available in my master
  branch on top of my last 3.11 based pull"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: Fix crash due to not allocating integrity data for a bioset
  Btrfs: fix a use-after-free bug in btrfs_dev_replace_finishing
  Btrfs: eliminate races in worker stopping code
  Btrfs: fix crash of compressed writes
  Btrfs: fix transid verify errors when recovering log tree
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull btrfs fixes from Chris Mason:
 "This is a small collection of fixes, including a regression fix from
  Liu Bo that solves rare crashes with compression on.

  I've merged my for-linus up to 3.12-rc3 because the top commit is only
  meant for 3.12.  The rest of the fixes are also available in my master
  branch on top of my last 3.11 based pull"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  btrfs: Fix crash due to not allocating integrity data for a bioset
  Btrfs: fix a use-after-free bug in btrfs_dev_replace_finishing
  Btrfs: eliminate races in worker stopping code
  Btrfs: fix crash of compressed writes
  Btrfs: fix transid verify errors when recovering log tree
</pre>
</div>
</content>
</entry>
<entry>
<title>btrfs: Fix crash due to not allocating integrity data for a bioset</title>
<updated>2013-10-05T14:52:10+00:00</updated>
<author>
<name>Darrick J. Wong</name>
<email>darrick.wong@oracle.com</email>
</author>
<published>2013-09-20T03:37:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b208c2f7ceafacbc44f13d1b5a9fbada98226183'/>
<id>b208c2f7ceafacbc44f13d1b5a9fbada98226183</id>
<content type='text'>
When btrfs creates a bioset, we must also allocate the integrity data pool.
Otherwise btrfs will crash when it tries to submit a bio to a checksumming
disk:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
 IP: [&lt;ffffffff8111e28a&gt;] mempool_alloc+0x4a/0x150
 PGD 2305e4067 PUD 23063d067 PMD 0
 Oops: 0000 [#1] PREEMPT SMP
 Modules linked in: btrfs scsi_debug xfs ext4 jbd2 ext3 jbd mbcache
sch_fq_codel eeprom lpc_ich mfd_core nfsd exportfs auth_rpcgss af_packet
raid6_pq xor zlib_deflate libcrc32c [last unloaded: scsi_debug]
 CPU: 1 PID: 4486 Comm: mount Not tainted 3.12.0-rc1-mcsum #2
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 task: ffff8802451c9720 ti: ffff880230698000 task.ti: ffff880230698000
 RIP: 0010:[&lt;ffffffff8111e28a&gt;]  [&lt;ffffffff8111e28a&gt;] mempool_alloc+0x4a/0x150
 RSP: 0018:ffff880230699688  EFLAGS: 00010286
 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000005f8445
 RDX: 0000000000000001 RSI: 0000000000000010 RDI: 0000000000000000
 RBP: ffff8802306996f8 R08: 0000000000011200 R09: 0000000000000008
 R10: 0000000000000020 R11: ffff88009d6e8000 R12: 0000000000011210
 R13: 0000000000000030 R14: ffff8802306996b8 R15: ffff8802451c9720
 FS:  00007f25b8a16800(0000) GS:ffff88024fc80000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000018 CR3: 0000000230576000 CR4: 00000000000007e0
 Stack:
  ffff8802451c9720 0000000000000002 ffffffff81a97100 0000000000281250
  ffffffff81a96480 ffff88024fc99150 ffff880228d18200 0000000000000000
  0000000000000000 0000000000000040 ffff880230e8c2e8 ffff8802459dc900
 Call Trace:
  [&lt;ffffffff811b2208&gt;] bio_integrity_alloc+0x48/0x1b0
  [&lt;ffffffff811b26fc&gt;] bio_integrity_prep+0xac/0x360
  [&lt;ffffffff8111e298&gt;] ? mempool_alloc+0x58/0x150
  [&lt;ffffffffa03e8041&gt;] ? alloc_extent_state+0x31/0x110 [btrfs]
  [&lt;ffffffff81241579&gt;] blk_queue_bio+0x1c9/0x460
  [&lt;ffffffff8123e58a&gt;] generic_make_request+0xca/0x100
  [&lt;ffffffff8123e639&gt;] submit_bio+0x79/0x160
  [&lt;ffffffffa03f865e&gt;] btrfs_map_bio+0x48e/0x5b0 [btrfs]
  [&lt;ffffffffa03c821a&gt;] btree_submit_bio_hook+0xda/0x110 [btrfs]
  [&lt;ffffffffa03e7eba&gt;] submit_one_bio+0x6a/0xa0 [btrfs]
  [&lt;ffffffffa03ef450&gt;] read_extent_buffer_pages+0x250/0x310 [btrfs]
  [&lt;ffffffff8125eef6&gt;] ? __radix_tree_preload+0x66/0xf0
  [&lt;ffffffff8125f1c5&gt;] ? radix_tree_insert+0x95/0x260
  [&lt;ffffffffa03c66f6&gt;] btree_read_extent_buffer_pages.constprop.128+0xb6/0x120
[btrfs]
  [&lt;ffffffffa03c8c1a&gt;] read_tree_block+0x3a/0x60 [btrfs]
  [&lt;ffffffffa03caefd&gt;] open_ctree+0x139d/0x2030 [btrfs]
  [&lt;ffffffffa03a282a&gt;] btrfs_mount+0x53a/0x7d0 [btrfs]
  [&lt;ffffffff8113ab0b&gt;] ? pcpu_alloc+0x8eb/0x9f0
  [&lt;ffffffff81167305&gt;] ? __kmalloc_track_caller+0x35/0x1e0
  [&lt;ffffffff81176ba0&gt;] mount_fs+0x20/0xd0
  [&lt;ffffffff81191096&gt;] vfs_kern_mount+0x76/0x120
  [&lt;ffffffff81193320&gt;] do_mount+0x200/0xa40
  [&lt;ffffffff81135cdb&gt;] ? strndup_user+0x5b/0x80
  [&lt;ffffffff81193bf0&gt;] SyS_mount+0x90/0xe0
  [&lt;ffffffff8156d31d&gt;] system_call_fastpath+0x1a/0x1f
 Code: 4c 8d 75 a8 4c 89 6d e8 45 89 e0 4c 8d 6f 30 48 89 5d d8 41 83 e0 af 48
89 fb 49 83 c6 18 4c 89 7d f8 65 4c 8b 3c 25 c0 b8 00 00 &lt;48&gt; 8b 73 18 44 89 c7
44 89 45 98 ff 53 20 48 85 c0 48 89 c2 74
 RIP  [&lt;ffffffff8111e28a&gt;] mempool_alloc+0x4a/0x150
  RSP &lt;ffff880230699688&gt;
 CR2: 0000000000000018
 ---[ end trace 7a96042017ed21e2 ]---

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
Signed-off-by: Chris Mason &lt;chris.mason@fusionio.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When btrfs creates a bioset, we must also allocate the integrity data pool.
Otherwise btrfs will crash when it tries to submit a bio to a checksumming
disk:

 BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
 IP: [&lt;ffffffff8111e28a&gt;] mempool_alloc+0x4a/0x150
 PGD 2305e4067 PUD 23063d067 PMD 0
 Oops: 0000 [#1] PREEMPT SMP
 Modules linked in: btrfs scsi_debug xfs ext4 jbd2 ext3 jbd mbcache
sch_fq_codel eeprom lpc_ich mfd_core nfsd exportfs auth_rpcgss af_packet
raid6_pq xor zlib_deflate libcrc32c [last unloaded: scsi_debug]
 CPU: 1 PID: 4486 Comm: mount Not tainted 3.12.0-rc1-mcsum #2
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
 task: ffff8802451c9720 ti: ffff880230698000 task.ti: ffff880230698000
 RIP: 0010:[&lt;ffffffff8111e28a&gt;]  [&lt;ffffffff8111e28a&gt;] mempool_alloc+0x4a/0x150
 RSP: 0018:ffff880230699688  EFLAGS: 00010286
 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000005f8445
 RDX: 0000000000000001 RSI: 0000000000000010 RDI: 0000000000000000
 RBP: ffff8802306996f8 R08: 0000000000011200 R09: 0000000000000008
 R10: 0000000000000020 R11: ffff88009d6e8000 R12: 0000000000011210
 R13: 0000000000000030 R14: ffff8802306996b8 R15: ffff8802451c9720
 FS:  00007f25b8a16800(0000) GS:ffff88024fc80000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
 CR2: 0000000000000018 CR3: 0000000230576000 CR4: 00000000000007e0
 Stack:
  ffff8802451c9720 0000000000000002 ffffffff81a97100 0000000000281250
  ffffffff81a96480 ffff88024fc99150 ffff880228d18200 0000000000000000
  0000000000000000 0000000000000040 ffff880230e8c2e8 ffff8802459dc900
 Call Trace:
  [&lt;ffffffff811b2208&gt;] bio_integrity_alloc+0x48/0x1b0
  [&lt;ffffffff811b26fc&gt;] bio_integrity_prep+0xac/0x360
  [&lt;ffffffff8111e298&gt;] ? mempool_alloc+0x58/0x150
  [&lt;ffffffffa03e8041&gt;] ? alloc_extent_state+0x31/0x110 [btrfs]
  [&lt;ffffffff81241579&gt;] blk_queue_bio+0x1c9/0x460
  [&lt;ffffffff8123e58a&gt;] generic_make_request+0xca/0x100
  [&lt;ffffffff8123e639&gt;] submit_bio+0x79/0x160
  [&lt;ffffffffa03f865e&gt;] btrfs_map_bio+0x48e/0x5b0 [btrfs]
  [&lt;ffffffffa03c821a&gt;] btree_submit_bio_hook+0xda/0x110 [btrfs]
  [&lt;ffffffffa03e7eba&gt;] submit_one_bio+0x6a/0xa0 [btrfs]
  [&lt;ffffffffa03ef450&gt;] read_extent_buffer_pages+0x250/0x310 [btrfs]
  [&lt;ffffffff8125eef6&gt;] ? __radix_tree_preload+0x66/0xf0
  [&lt;ffffffff8125f1c5&gt;] ? radix_tree_insert+0x95/0x260
  [&lt;ffffffffa03c66f6&gt;] btree_read_extent_buffer_pages.constprop.128+0xb6/0x120
[btrfs]
  [&lt;ffffffffa03c8c1a&gt;] read_tree_block+0x3a/0x60 [btrfs]
  [&lt;ffffffffa03caefd&gt;] open_ctree+0x139d/0x2030 [btrfs]
  [&lt;ffffffffa03a282a&gt;] btrfs_mount+0x53a/0x7d0 [btrfs]
  [&lt;ffffffff8113ab0b&gt;] ? pcpu_alloc+0x8eb/0x9f0
  [&lt;ffffffff81167305&gt;] ? __kmalloc_track_caller+0x35/0x1e0
  [&lt;ffffffff81176ba0&gt;] mount_fs+0x20/0xd0
  [&lt;ffffffff81191096&gt;] vfs_kern_mount+0x76/0x120
  [&lt;ffffffff81193320&gt;] do_mount+0x200/0xa40
  [&lt;ffffffff81135cdb&gt;] ? strndup_user+0x5b/0x80
  [&lt;ffffffff81193bf0&gt;] SyS_mount+0x90/0xe0
  [&lt;ffffffff8156d31d&gt;] system_call_fastpath+0x1a/0x1f
 Code: 4c 8d 75 a8 4c 89 6d e8 45 89 e0 4c 8d 6f 30 48 89 5d d8 41 83 e0 af 48
89 fb 49 83 c6 18 4c 89 7d f8 65 4c 8b 3c 25 c0 b8 00 00 &lt;48&gt; 8b 73 18 44 89 c7
44 89 45 98 ff 53 20 48 85 c0 48 89 c2 74
 RIP  [&lt;ffffffff8111e28a&gt;] mempool_alloc+0x4a/0x150
  RSP &lt;ffff880230699688&gt;
 CR2: 0000000000000018
 ---[ end trace 7a96042017ed21e2 ]---

Signed-off-by: Darrick J. Wong &lt;darrick.wong@oracle.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
Signed-off-by: Chris Mason &lt;chris.mason@fusionio.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' into for-linus-3.12</title>
<updated>2013-10-05T14:51:32+00:00</updated>
<author>
<name>Chris Mason</name>
<email>chris.mason@fusionio.com</email>
</author>
<published>2013-10-05T14:51:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1329dfc8bb8932976844438cd5e757c720d6f1ff'/>
<id>1329dfc8bb8932976844438cd5e757c720d6f1ff</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.samba.org/sfrench/cifs-2.6</title>
<updated>2013-10-05T03:50:16+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-10-05T03:50:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a5c984cc2986c3ed88615fec01e433f9019ff011'/>
<id>a5c984cc2986c3ed88615fec01e433f9019ff011</id>
<content type='text'>
Pull CIFS fixes from Steve French:
 "Small set of cifs fixes.  Most important is Jeff's fix that works
  around disconnection problems which can be caused by simultaneous use
  of user space tools (starting a long running smbclient backup then
  doing a cifs kernel mount) or multiple cifs mounts through a NAT, and
  Jim's fix to deal with reexport of cifs share.

  I expect to send two more cifs fixes next week (being tested now) -
  fixes to address an SMB2 unmount hang when server dies and a fix for
  cifs symlink handling of Windows "NFS" symlinks"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  [CIFS] update cifs.ko version
  [CIFS] Remove ext2 flags that have been moved to fs.h
  [CIFS] Provide sane values for nlink
  cifs: stop trying to use virtual circuits
  CIFS: FS-Cache: Uncache unread pages in cifs_readpages() before freeing them
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull CIFS fixes from Steve French:
 "Small set of cifs fixes.  Most important is Jeff's fix that works
  around disconnection problems which can be caused by simultaneous use
  of user space tools (starting a long running smbclient backup then
  doing a cifs kernel mount) or multiple cifs mounts through a NAT, and
  Jim's fix to deal with reexport of cifs share.

  I expect to send two more cifs fixes next week (being tested now) -
  fixes to address an SMB2 unmount hang when server dies and a fix for
  cifs symlink handling of Windows "NFS" symlinks"

* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
  [CIFS] update cifs.ko version
  [CIFS] Remove ext2 flags that have been moved to fs.h
  [CIFS] Provide sane values for nlink
  cifs: stop trying to use virtual circuits
  CIFS: FS-Cache: Uncache unread pages in cifs_readpages() before freeing them
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'xfs-for-linus-v3.12-rc4' of git://oss.sgi.com/xfs/xfs</title>
<updated>2013-10-04T21:47:22+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-10-04T21:47:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3dbecf0aa9692cffbb71313a380c0ecc606c5920'/>
<id>3dbecf0aa9692cffbb71313a380c0ecc606c5920</id>
<content type='text'>
Pull xfs bugfixes from Ben Myers:
 "There are lockdep annotations for project quotas, a fix for dirent
  dtype support on v4 filesystems, a fix for a memory leak in recovery,
  and a fix for the build error that resulted from it.  D'oh"

* tag 'xfs-for-linus-v3.12-rc4' of git://oss.sgi.com/xfs/xfs:
  xfs: Use kmem_free() instead of free()
  xfs: fix memory leak in xlog_recover_add_to_trans
  xfs: dirent dtype presence is dependent on directory magic numbers
  xfs: lockdep needs to know about 3 dquot-deep nesting
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull xfs bugfixes from Ben Myers:
 "There are lockdep annotations for project quotas, a fix for dirent
  dtype support on v4 filesystems, a fix for a memory leak in recovery,
  and a fix for the build error that resulted from it.  D'oh"

* tag 'xfs-for-linus-v3.12-rc4' of git://oss.sgi.com/xfs/xfs:
  xfs: Use kmem_free() instead of free()
  xfs: fix memory leak in xlog_recover_add_to_trans
  xfs: dirent dtype presence is dependent on directory magic numbers
  xfs: lockdep needs to know about 3 dquot-deep nesting
</pre>
</div>
</content>
</entry>
<entry>
<title>Btrfs: fix a use-after-free bug in btrfs_dev_replace_finishing</title>
<updated>2013-10-04T20:02:14+00:00</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2013-10-02T17:41:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1357272fc7deeebb7b3c5d1a071562edc273cdaf'/>
<id>1357272fc7deeebb7b3c5d1a071562edc273cdaf</id>
<content type='text'>
free_device rcu callback, scheduled from btrfs_rm_dev_replace_srcdev,
can be processed before btrfs_scratch_superblock is called, which would
result in a use-after-free on btrfs_device contents.  Fix this by
zeroing the superblock before the rcu callback is registered.

Cc: Stefan Behrens &lt;sbehrens@giantdisaster.de&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
free_device rcu callback, scheduled from btrfs_rm_dev_replace_srcdev,
can be processed before btrfs_scratch_superblock is called, which would
result in a use-after-free on btrfs_device contents.  Fix this by
zeroing the superblock before the rcu callback is registered.

Cc: Stefan Behrens &lt;sbehrens@giantdisaster.de&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Btrfs: eliminate races in worker stopping code</title>
<updated>2013-10-04T20:02:13+00:00</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2013-10-02T16:39:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=964fb15acfcd672ac691f04879b71f07ccc21e0c'/>
<id>964fb15acfcd672ac691f04879b71f07ccc21e0c</id>
<content type='text'>
The current implementation of worker threads in Btrfs has races in
worker stopping code, which cause all kinds of panics and lockups when
running btrfs/011 xfstest in a loop.  The problem is that
btrfs_stop_workers is unsynchronized with respect to check_idle_worker,
check_busy_worker and __btrfs_start_workers.

E.g., check_idle_worker race flow:

       btrfs_stop_workers():            check_idle_worker(aworker):
- grabs the lock
- splices the idle list into the
  working list
- removes the first worker from the
  working list
- releases the lock to wait for
  its kthread's completion
                                  - grabs the lock
                                  - if aworker is on the working list,
                                    moves aworker from the working list
                                    to the idle list
                                  - releases the lock
- grabs the lock
- puts the worker
- removes the second worker from the
  working list
                              ......
        btrfs_stop_workers returns, aworker is on the idle list
                 FS is umounted, memory is freed
                              ......
              aworker is waken up, fireworks ensue

With this applied, I wasn't able to trigger the problem in 48 hours,
whereas previously I could reliably reproduce at least one of these
races within an hour.

Reported-by: David Sterba &lt;dsterba@suse.cz&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The current implementation of worker threads in Btrfs has races in
worker stopping code, which cause all kinds of panics and lockups when
running btrfs/011 xfstest in a loop.  The problem is that
btrfs_stop_workers is unsynchronized with respect to check_idle_worker,
check_busy_worker and __btrfs_start_workers.

E.g., check_idle_worker race flow:

       btrfs_stop_workers():            check_idle_worker(aworker):
- grabs the lock
- splices the idle list into the
  working list
- removes the first worker from the
  working list
- releases the lock to wait for
  its kthread's completion
                                  - grabs the lock
                                  - if aworker is on the working list,
                                    moves aworker from the working list
                                    to the idle list
                                  - releases the lock
- grabs the lock
- puts the worker
- removes the second worker from the
  working list
                              ......
        btrfs_stop_workers returns, aworker is on the idle list
                 FS is umounted, memory is freed
                              ......
              aworker is waken up, fireworks ensue

With this applied, I wasn't able to trigger the problem in 48 hours,
whereas previously I could reliably reproduce at least one of these
races within an hour.

Reported-by: David Sterba &lt;dsterba@suse.cz&gt;
Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Btrfs: fix crash of compressed writes</title>
<updated>2013-10-04T20:02:11+00:00</updated>
<author>
<name>Liu Bo</name>
<email>bo.li.liu@oracle.com</email>
</author>
<published>2013-10-01T15:49:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=385fe0bede52a45cd960f30c7eb8d20ad8e1e05b'/>
<id>385fe0bede52a45cd960f30c7eb8d20ad8e1e05b</id>
<content type='text'>
The crash[1] is found by xfstests/generic/208 with "-o compress",
it's not reproduced everytime, but it does panic.

The bug is quite interesting, it's actually introduced by a recent commit
(573aecafca1cf7a974231b759197a1aebcf39c2a,
Btrfs: actually limit the size of delalloc range).

Btrfs implements delay allocation, so during writeback, we
(1) get a page A and lock it
(2) search the state tree for delalloc bytes and lock all pages within the range
(3) process the delalloc range, including find disk space and create
    ordered extent and so on.
(4) submit the page A.

It runs well in normal cases, but if we're in a racy case, eg.
buffered compressed writes and aio-dio writes,
sometimes we may fail to lock all pages in the 'delalloc' range,
in which case, we need to fall back to search the state tree again with
a smaller range limit(max_bytes = PAGE_CACHE_SIZE - offset).

The mentioned commit has a side effect, that is, in the fallback case,
we can find delalloc bytes before the index of the page we already have locked,
so we're in the case of (delalloc_end &lt;= *start) and return with (found &gt; 0).

This ends with not locking delalloc pages but making -&gt;writepage still
process them, and the crash happens.

This fixes it by just thinking that we find nothing and returning to caller
as the caller knows how to deal with it properly.

[1]:
------------[ cut here ]------------
kernel BUG at mm/page-writeback.c:2170!
[...]
CPU: 2 PID: 11755 Comm: btrfs-delalloc- Tainted: G           O 3.11.0+ #8
[...]
RIP: 0010:[&lt;ffffffff810f5093&gt;]  [&lt;ffffffff810f5093&gt;] clear_page_dirty_for_io+0x1e/0x83
[...]
[ 4934.248731] Stack:
[ 4934.248731]  ffff8801477e5dc8 ffffea00049b9f00 ffff8801869f9ce8 ffffffffa02b841a
[ 4934.248731]  0000000000000000 0000000000000000 0000000000000fff 0000000000000620
[ 4934.248731]  ffff88018db59c78 ffffea0005da8d40 ffffffffa02ff860 00000001810016c0
[ 4934.248731] Call Trace:
[ 4934.248731]  [&lt;ffffffffa02b841a&gt;] extent_range_clear_dirty_for_io+0xcf/0xf5 [btrfs]
[ 4934.248731]  [&lt;ffffffffa02a8889&gt;] compress_file_range+0x1dc/0x4cb [btrfs]
[ 4934.248731]  [&lt;ffffffff8104f7af&gt;] ? detach_if_pending+0x22/0x4b
[ 4934.248731]  [&lt;ffffffffa02a8bad&gt;] async_cow_start+0x35/0x53 [btrfs]
[ 4934.248731]  [&lt;ffffffffa02c694b&gt;] worker_loop+0x14b/0x48c [btrfs]
[ 4934.248731]  [&lt;ffffffffa02c6800&gt;] ? btrfs_queue_worker+0x25c/0x25c [btrfs]
[ 4934.248731]  [&lt;ffffffff810608f5&gt;] kthread+0x8d/0x95
[ 4934.248731]  [&lt;ffffffff81060868&gt;] ? kthread_freezable_should_stop+0x43/0x43
[ 4934.248731]  [&lt;ffffffff814fe09c&gt;] ret_from_fork+0x7c/0xb0
[ 4934.248731]  [&lt;ffffffff81060868&gt;] ? kthread_freezable_should_stop+0x43/0x43
[ 4934.248731] Code: ff 85 c0 0f 94 c0 0f b6 c0 59 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 2c de 00 00 49 89 c4 48 8b 03 a8 01 75 02 &lt;0f&gt; 0b 4d 85 e4 74 52 49 8b 84 24 80 00 00 00 f6 40 20 01 75 44
[ 4934.248731] RIP  [&lt;ffffffff810f5093&gt;] clear_page_dirty_for_io+0x1e/0x83
[ 4934.248731]  RSP &lt;ffff8801869f9c48&gt;
[ 4934.280307] ---[ end trace 36f06d3f8750236a ]---

Signed-off-by: Liu Bo &lt;bo.li.liu@oracle.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The crash[1] is found by xfstests/generic/208 with "-o compress",
it's not reproduced everytime, but it does panic.

The bug is quite interesting, it's actually introduced by a recent commit
(573aecafca1cf7a974231b759197a1aebcf39c2a,
Btrfs: actually limit the size of delalloc range).

Btrfs implements delay allocation, so during writeback, we
(1) get a page A and lock it
(2) search the state tree for delalloc bytes and lock all pages within the range
(3) process the delalloc range, including find disk space and create
    ordered extent and so on.
(4) submit the page A.

It runs well in normal cases, but if we're in a racy case, eg.
buffered compressed writes and aio-dio writes,
sometimes we may fail to lock all pages in the 'delalloc' range,
in which case, we need to fall back to search the state tree again with
a smaller range limit(max_bytes = PAGE_CACHE_SIZE - offset).

The mentioned commit has a side effect, that is, in the fallback case,
we can find delalloc bytes before the index of the page we already have locked,
so we're in the case of (delalloc_end &lt;= *start) and return with (found &gt; 0).

This ends with not locking delalloc pages but making -&gt;writepage still
process them, and the crash happens.

This fixes it by just thinking that we find nothing and returning to caller
as the caller knows how to deal with it properly.

[1]:
------------[ cut here ]------------
kernel BUG at mm/page-writeback.c:2170!
[...]
CPU: 2 PID: 11755 Comm: btrfs-delalloc- Tainted: G           O 3.11.0+ #8
[...]
RIP: 0010:[&lt;ffffffff810f5093&gt;]  [&lt;ffffffff810f5093&gt;] clear_page_dirty_for_io+0x1e/0x83
[...]
[ 4934.248731] Stack:
[ 4934.248731]  ffff8801477e5dc8 ffffea00049b9f00 ffff8801869f9ce8 ffffffffa02b841a
[ 4934.248731]  0000000000000000 0000000000000000 0000000000000fff 0000000000000620
[ 4934.248731]  ffff88018db59c78 ffffea0005da8d40 ffffffffa02ff860 00000001810016c0
[ 4934.248731] Call Trace:
[ 4934.248731]  [&lt;ffffffffa02b841a&gt;] extent_range_clear_dirty_for_io+0xcf/0xf5 [btrfs]
[ 4934.248731]  [&lt;ffffffffa02a8889&gt;] compress_file_range+0x1dc/0x4cb [btrfs]
[ 4934.248731]  [&lt;ffffffff8104f7af&gt;] ? detach_if_pending+0x22/0x4b
[ 4934.248731]  [&lt;ffffffffa02a8bad&gt;] async_cow_start+0x35/0x53 [btrfs]
[ 4934.248731]  [&lt;ffffffffa02c694b&gt;] worker_loop+0x14b/0x48c [btrfs]
[ 4934.248731]  [&lt;ffffffffa02c6800&gt;] ? btrfs_queue_worker+0x25c/0x25c [btrfs]
[ 4934.248731]  [&lt;ffffffff810608f5&gt;] kthread+0x8d/0x95
[ 4934.248731]  [&lt;ffffffff81060868&gt;] ? kthread_freezable_should_stop+0x43/0x43
[ 4934.248731]  [&lt;ffffffff814fe09c&gt;] ret_from_fork+0x7c/0xb0
[ 4934.248731]  [&lt;ffffffff81060868&gt;] ? kthread_freezable_should_stop+0x43/0x43
[ 4934.248731] Code: ff 85 c0 0f 94 c0 0f b6 c0 59 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 41 54 53 48 89 fb e8 2c de 00 00 49 89 c4 48 8b 03 a8 01 75 02 &lt;0f&gt; 0b 4d 85 e4 74 52 49 8b 84 24 80 00 00 00 f6 40 20 01 75 44
[ 4934.248731] RIP  [&lt;ffffffff810f5093&gt;] clear_page_dirty_for_io+0x1e/0x83
[ 4934.248731]  RSP &lt;ffff8801869f9c48&gt;
[ 4934.280307] ---[ end trace 36f06d3f8750236a ]---

Signed-off-by: Liu Bo &lt;bo.li.liu@oracle.com&gt;
Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Btrfs: fix transid verify errors when recovering log tree</title>
<updated>2013-10-04T20:02:09+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>jbacik@fusionio.com</email>
</author>
<published>2013-09-30T18:10:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=60e7cd3a4ba6049ef590921e84454e6cfd9e2589'/>
<id>60e7cd3a4ba6049ef590921e84454e6cfd9e2589</id>
<content type='text'>
If we crash with a log, remount and recover that log, and then crash before we
can commit another transaction we will get transid verify errors on the next
mount.  This is because we were not zero'ing out the log when we committed the
transaction after recovery.  This is ok as long as we commit another transaction
at some point in the future, but if you abort or something else goes wrong you
can end up in this weird state because the recovery stuff says that the tree log
should have a generation+1 of the super generation, which won't be the case of
the transaction that was started for recovery.  Fix this by removing the check
and _always_ zero out the log portion of the super when we commit a transaction.
This fixes the transid verify issues I was seeing with my force errors tests.
Thanks,

Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we crash with a log, remount and recover that log, and then crash before we
can commit another transaction we will get transid verify errors on the next
mount.  This is because we were not zero'ing out the log when we committed the
transaction after recovery.  This is ok as long as we commit another transaction
at some point in the future, but if you abort or something else goes wrong you
can end up in this weird state because the recovery stuff says that the tree log
should have a generation+1 of the super generation, which won't be the case of
the transaction that was started for recovery.  Fix this by removing the check
and _always_ zero out the log portion of the super when we commit a transaction.
This fixes the transid verify issues I was seeing with my force errors tests.
Thanks,

Signed-off-by: Josef Bacik &lt;jbacik@fusionio.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>xfs: Use kmem_free() instead of free()</title>
<updated>2013-10-04T18:56:12+00:00</updated>
<author>
<name>Thierry Reding</name>
<email>thierry.reding@gmail.com</email>
</author>
<published>2013-10-01T14:47:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b2a42f78ab475f4730300b0e9568bc3b2587d112'/>
<id>b2a42f78ab475f4730300b0e9568bc3b2587d112</id>
<content type='text'>
This fixes a build failure caused by calling the free() function which
does not exist in the Linux kernel.

Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Mark Tinguely &lt;tinguely@sgi.com&gt;
Signed-off-by: Ben Myers &lt;bpm@sgi.com&gt;

(cherry picked from commit aaaae98022efa4f3c31042f1fdf9e7a0c5f04663)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes a build failure caused by calling the free() function which
does not exist in the Linux kernel.

Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Reviewed-by: Mark Tinguely &lt;tinguely@sgi.com&gt;
Signed-off-by: Ben Myers &lt;bpm@sgi.com&gt;

(cherry picked from commit aaaae98022efa4f3c31042f1fdf9e7a0c5f04663)
</pre>
</div>
</content>
</entry>
</feed>
