<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs, branch v3.12-rc5</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>vfs: allow O_PATH file descriptors for fstatfs()</title>
<updated>2013-10-12T20:12:31+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-09-30T15:35:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9d05746e7b16d8565dddbe3200faa1e669d23bbf'/>
<id>9d05746e7b16d8565dddbe3200faa1e669d23bbf</id>
<content type='text'>
Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.

There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()".  See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.

Reported-and-tested-by: ольга крыжановская &lt;olga.kryzhanovska@gmail.com&gt;
Acked-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: stable@kernel.org	# O_PATH introduced in 3.0+
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Olga reported that file descriptors opened with O_PATH do not work with
fstatfs(), found during further development of ksh93's thread support.

There is no reason to not allow O_PATH file descriptors here (fstatfs is
very much a path operation), so use "fdget_raw()".  See commit
55815f70147d ("vfs: make O_PATH file descriptors usable for 'fstat()'")
for a very similar issue reported for fstat() by the same team.

Reported-and-tested-by: ольга крыжановская &lt;olga.kryzhanovska@gmail.com&gt;
Acked-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: stable@kernel.org	# O_PATH introduced in 3.0+
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4</title>
<updated>2013-10-12T19:55:15+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-10-12T19:55:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=be5090da4abb68caa69ac62ae5253ac540aa829a'/>
<id>be5090da4abb68caa69ac62ae5253ac540aa829a</id>
<content type='text'>
Pull ext4 bugfixes from Ted Ts'o:
 "A bug fix and performance regression fix for ext4"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: fix memory leak in xattr
  ext4: fix performance regression in writeback of random writes
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ext4 bugfixes from Ted Ts'o:
 "A bug fix and performance regression fix for ext4"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: fix memory leak in xattr
  ext4: fix performance regression in writeback of random writes
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs</title>
<updated>2013-10-12T19:54:24+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-10-12T19:54:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d64dab903fb3abb42ef2a3fc2d8aa064105e5dca'/>
<id>d64dab903fb3abb42ef2a3fc2d8aa064105e5dca</id>
<content type='text'>
Pull btrfs fixes from Chris Mason:
 "We've got more bug fixes in my for-linus branch:

  One of these fixes another corner of the compression oops from last
  time.  Miao nailed down some problems with concurrent snapshot
  deletion and drive balancing.

  I kept out one of his patches for more testing, but these are all
  stable"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: fix oops caused by the space balance and dead roots
  Btrfs: insert orphan roots into fs radix tree
  Btrfs: limit delalloc pages outside of find_delalloc_range
  Btrfs: use right root when checking for hash collision
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull btrfs fixes from Chris Mason:
 "We've got more bug fixes in my for-linus branch:

  One of these fixes another corner of the compression oops from last
  time.  Miao nailed down some problems with concurrent snapshot
  deletion and drive balancing.

  I kept out one of his patches for more testing, but these are all
  stable"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
  Btrfs: fix oops caused by the space balance and dead roots
  Btrfs: insert orphan roots into fs radix tree
  Btrfs: limit delalloc pages outside of find_delalloc_range
  Btrfs: use right root when checking for hash collision
</pre>
</div>
</content>
</entry>
<entry>
<title>ext4: fix memory leak in xattr</title>
<updated>2013-10-12T18:39:49+00:00</updated>
<author>
<name>Dave Jones</name>
<email>davej@redhat.com</email>
</author>
<published>2013-10-11T00:05:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6e4ea8e33b2057b85d75175dd89b93f5e26de3bc'/>
<id>6e4ea8e33b2057b85d75175dd89b93f5e26de3bc</id>
<content type='text'>
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations.  If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.

Spotted with Coverity.

[ Fixed by tytso to set is and bs to NULL after freeing these
  pointers, in case in the retry loop we later end up triggering an
  error causing a jump to cleanup, at which point we could have a double
  free bug. -- Ted ]

Signed-off-by: Dave Jones &lt;davej@fedoraproject.org&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Reviewed-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Cc: stable@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If we take the 2nd retry path in ext4_expand_extra_isize_ea, we
potentionally return from the function without having freed these
allocations.  If we don't do the return, we over-write the previous
allocation pointers, so we leak either way.

Spotted with Coverity.

[ Fixed by tytso to set is and bs to NULL after freeing these
  pointers, in case in the retry loop we later end up triggering an
  error causing a jump to cleanup, at which point we could have a double
  free bug. -- Ted ]

Signed-off-by: Dave Jones &lt;davej@fedoraproject.org&gt;
Signed-off-by: "Theodore Ts'o" &lt;tytso@mit.edu&gt;
Reviewed-by: Eric Sandeen &lt;sandeen@redhat.com&gt;
Cc: stable@vger.kernel.org
</pre>
</div>
</content>
</entry>
<entry>
<title>Btrfs: fix oops caused by the space balance and dead roots</title>
<updated>2013-10-11T01:31:02+00:00</updated>
<author>
<name>Miao Xie</name>
<email>miaox@cn.fujitsu.com</email>
</author>
<published>2013-09-25T13:47:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c00869f1ae6a8fa49802d5e60d843b7051a112ec'/>
<id>c00869f1ae6a8fa49802d5e60d843b7051a112ec</id>
<content type='text'>
When doing space balance and subvolume destroy at the same time, we met
the following oops:

kernel BUG at fs/btrfs/relocation.c:2247!
RIP: 0010: [&lt;ffffffffa04cec16&gt;] prepare_to_merge+0x154/0x1f0 [btrfs]
Call Trace:
 [&lt;ffffffffa04b5ab7&gt;] relocate_block_group+0x466/0x4e6 [btrfs]
 [&lt;ffffffffa04b5c7a&gt;] btrfs_relocate_block_group+0x143/0x275 [btrfs]
 [&lt;ffffffffa0495c56&gt;] btrfs_relocate_chunk.isra.27+0x5c/0x5a2 [btrfs]
 [&lt;ffffffffa0459871&gt;] ? btrfs_item_key_to_cpu+0x15/0x31 [btrfs]
 [&lt;ffffffffa048b46a&gt;] ? btrfs_get_token_64+0x7e/0xcd [btrfs]
 [&lt;ffffffffa04a3467&gt;] ? btrfs_tree_read_unlock_blocking+0xb2/0xb7 [btrfs]
 [&lt;ffffffffa049907d&gt;] btrfs_balance+0x9c7/0xb6f [btrfs]
 [&lt;ffffffffa049ef84&gt;] btrfs_ioctl_balance+0x234/0x2ac [btrfs]
 [&lt;ffffffffa04a1e8e&gt;] btrfs_ioctl+0xd87/0x1ef9 [btrfs]
 [&lt;ffffffff81122f53&gt;] ? path_openat+0x234/0x4db
 [&lt;ffffffff813c3b78&gt;] ? __do_page_fault+0x31d/0x391
 [&lt;ffffffff810f8ab6&gt;] ? vma_link+0x74/0x94
 [&lt;ffffffff811250f5&gt;] vfs_ioctl+0x1d/0x39
 [&lt;ffffffff811258c8&gt;] do_vfs_ioctl+0x32d/0x3e2
 [&lt;ffffffff811259d4&gt;] SyS_ioctl+0x57/0x83
 [&lt;ffffffff813c3bfa&gt;] ? do_page_fault+0xe/0x10
 [&lt;ffffffff813c73c2&gt;] system_call_fastpath+0x16/0x1b

It is because we returned the error number if the reference of the root was 0
when doing space relocation. It was not right here, because though the root
was dead(refs == 0), but the space it held still need be relocated, or we
could not remove the block group. So in this case, we should return the root
no matter it is dead or not.

Signed-off-by: Miao Xie &lt;miaox@cn.fujitsu.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 doing space balance and subvolume destroy at the same time, we met
the following oops:

kernel BUG at fs/btrfs/relocation.c:2247!
RIP: 0010: [&lt;ffffffffa04cec16&gt;] prepare_to_merge+0x154/0x1f0 [btrfs]
Call Trace:
 [&lt;ffffffffa04b5ab7&gt;] relocate_block_group+0x466/0x4e6 [btrfs]
 [&lt;ffffffffa04b5c7a&gt;] btrfs_relocate_block_group+0x143/0x275 [btrfs]
 [&lt;ffffffffa0495c56&gt;] btrfs_relocate_chunk.isra.27+0x5c/0x5a2 [btrfs]
 [&lt;ffffffffa0459871&gt;] ? btrfs_item_key_to_cpu+0x15/0x31 [btrfs]
 [&lt;ffffffffa048b46a&gt;] ? btrfs_get_token_64+0x7e/0xcd [btrfs]
 [&lt;ffffffffa04a3467&gt;] ? btrfs_tree_read_unlock_blocking+0xb2/0xb7 [btrfs]
 [&lt;ffffffffa049907d&gt;] btrfs_balance+0x9c7/0xb6f [btrfs]
 [&lt;ffffffffa049ef84&gt;] btrfs_ioctl_balance+0x234/0x2ac [btrfs]
 [&lt;ffffffffa04a1e8e&gt;] btrfs_ioctl+0xd87/0x1ef9 [btrfs]
 [&lt;ffffffff81122f53&gt;] ? path_openat+0x234/0x4db
 [&lt;ffffffff813c3b78&gt;] ? __do_page_fault+0x31d/0x391
 [&lt;ffffffff810f8ab6&gt;] ? vma_link+0x74/0x94
 [&lt;ffffffff811250f5&gt;] vfs_ioctl+0x1d/0x39
 [&lt;ffffffff811258c8&gt;] do_vfs_ioctl+0x32d/0x3e2
 [&lt;ffffffff811259d4&gt;] SyS_ioctl+0x57/0x83
 [&lt;ffffffff813c3bfa&gt;] ? do_page_fault+0xe/0x10
 [&lt;ffffffff813c73c2&gt;] system_call_fastpath+0x16/0x1b

It is because we returned the error number if the reference of the root was 0
when doing space relocation. It was not right here, because though the root
was dead(refs == 0), but the space it held still need be relocated, or we
could not remove the block group. So in this case, we should return the root
no matter it is dead or not.

Signed-off-by: Miao Xie &lt;miaox@cn.fujitsu.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>Btrfs: insert orphan roots into fs radix tree</title>
<updated>2013-10-11T01:30:53+00:00</updated>
<author>
<name>Miao Xie</name>
<email>miaox@cn.fujitsu.com</email>
</author>
<published>2013-09-25T13:47:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=14927d95464956ffe8af4278331a6bfea94ab780'/>
<id>14927d95464956ffe8af4278331a6bfea94ab780</id>
<content type='text'>
Now we don't drop all the deleted snapshots/subvolumes before the space
balance. It means we have to relocate the space which is held by the dead
snapshots/subvolumes. So we must into them into fs radix tree, or we would
forget to commit the change of them when doing transaction commit, and it
would corrupt the metadata.

Signed-off-by: Miao Xie &lt;miaox@cn.fujitsu.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>
Now we don't drop all the deleted snapshots/subvolumes before the space
balance. It means we have to relocate the space which is held by the dead
snapshots/subvolumes. So we must into them into fs radix tree, or we would
forget to commit the change of them when doing transaction commit, and it
would corrupt the metadata.

Signed-off-by: Miao Xie &lt;miaox@cn.fujitsu.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>Btrfs: limit delalloc pages outside of find_delalloc_range</title>
<updated>2013-10-11T01:27:56+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>jbacik@fusionio.com</email>
</author>
<published>2013-10-08T02:11:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=7bf811a595a895b7a886dcf218d0d34f97df76dc'/>
<id>7bf811a595a895b7a886dcf218d0d34f97df76dc</id>
<content type='text'>
Liu fixed part of this problem and unfortunately I steered him in slightly the
wrong direction and so didn't completely fix the problem.  The problem is we
limit the size of the delalloc range we are looking for to max bytes and then we
try to lock that range.  If we fail to lock the pages in that range we will
shrink the max bytes to a single page and re loop.  However if our first page is
inside of the delalloc range then we will end up limiting the end of the range
to a period before our first page.  This is illustrated below

[0 -------- delalloc range --------- 256mb]
                                  [page]

So find_delalloc_range will return with delalloc_start as 0 and end as 128mb,
and then we will notice that delalloc_start &lt; *start and adjust it up, but not
adjust delalloc_end up, so things go sideways.  To fix this we need to not limit
the max bytes in find_delalloc_range, but in find_lock_delalloc_range and that
way we don't end up with this confusion.  Thanks,

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>
Liu fixed part of this problem and unfortunately I steered him in slightly the
wrong direction and so didn't completely fix the problem.  The problem is we
limit the size of the delalloc range we are looking for to max bytes and then we
try to lock that range.  If we fail to lock the pages in that range we will
shrink the max bytes to a single page and re loop.  However if our first page is
inside of the delalloc range then we will end up limiting the end of the range
to a period before our first page.  This is illustrated below

[0 -------- delalloc range --------- 256mb]
                                  [page]

So find_delalloc_range will return with delalloc_start as 0 and end as 128mb,
and then we will notice that delalloc_start &lt; *start and adjust it up, but not
adjust delalloc_end up, so things go sideways.  To fix this we need to not limit
the max bytes in find_delalloc_range, but in find_lock_delalloc_range and that
way we don't end up with this confusion.  Thanks,

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>Btrfs: use right root when checking for hash collision</title>
<updated>2013-10-11T01:27:45+00:00</updated>
<author>
<name>Josef Bacik</name>
<email>jbacik@fusionio.com</email>
</author>
<published>2013-10-09T16:24:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4871c1588f92c6c13f4713a7009f25f217055807'/>
<id>4871c1588f92c6c13f4713a7009f25f217055807</id>
<content type='text'>
btrfs_rename was using the root of the old dir instead of the root of the new
dir when checking for a hash collision, so if you tried to move a file into a
subvol it would freak out because it would see the file you are trying to move
in its current root.  This fixes the bug where this would fail

btrfs subvol create test1
btrfs subvol create test2
mv test1 test2.

Thanks to Chris Murphy for catching this,

Cc: stable@vger.kernel.org
Reported-by: Chris Murphy &lt;lists@colorremedies.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>
btrfs_rename was using the root of the old dir instead of the root of the new
dir when checking for a hash collision, so if you tried to move a file into a
subvol it would freak out because it would see the file you are trying to move
in its current root.  This fixes the bug where this would fail

btrfs subvol create test1
btrfs subvol create test2
mv test1 test2.

Thanks to Chris Murphy for catching this,

Cc: stable@vger.kernel.org
Reported-by: Chris Murphy &lt;lists@colorremedies.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' 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>
</feed>
