linux-toradex.git/fs/btrfs, branch v4.0.6

Btrfs: fix regression in raid level conversion

2015-06-23T00:03:37+00:00

commit 153c35b6cccc0c72de9fae06c8e2c8b2c47d79d4 upstream.

Commit 2f0810880f082fa8ba66ab2c33b02e4ff9770a5e changed
btrfs_set_block_group_ro to avoid trying to allocate new chunks with the
new raid profile during conversion.  This fixed failures when there was
no space on the drive to allocate a new chunk, but the metadata
reserves were sufficient to continue the conversion.

But this ended up causing a regression when the drive had plenty of
space to allocate new chunks, mostly because reduce_alloc_profile isn't
using the new raid profile.

Fixing btrfs_reduce_alloc_profile is a bigger patch.  For now, do a
partial revert of 2f0810880, and don't error out if we hit ENOSPC.

Signed-off-by: Chris Mason 
Tested-by: Dave Sterba 
Reported-by: Holger Hoffstaette 
[adapted for stable kernel branch, v4.0.5]
Signed-off-by: David Sterba 
Signed-off-by: Greg Kroah-Hartman

Btrfs: fix uninit variable in clone ioctl

2015-06-23T00:03:37+00:00

commit de249e66a73d696666281cd812087979c6fae552 upstream.

Commit 0d97a64e0 creates a new variable but doesn't always set it up.
This puts it back to the original method (key.offset + 1) for the cases
not covered by Filipe's new logic.

Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: fix range cloning when same inode used as source and destination

2015-06-23T00:03:36+00:00

commit df858e76723ace61342b118aa4302bd09de4e386 upstream.

While searching for extents to clone we might find one where we only use
a part of it coming from its tail. If our destination inode is the same
the source inode, we end up removing the tail part of the extent item and
insert after a new one that point to the same extent with an adjusted
key file offset and data offset. After this we search for the next extent
item in the fs/subvol tree with a key that has an offset incremented by
one. But this second search leaves us at the new extent item we inserted
previously, and since that extent item has a non-zero data offset, it
it can make us call btrfs_drop_extents with an empty range (start == end)
which causes the following warning:

[23978.537119] WARNING: CPU: 6 PID: 16251 at fs/btrfs/file.c:550 btrfs_drop_extent_cache+0x43/0x385 [btrfs]()
(...)
[23978.557266] Call Trace:
[23978.557978]  [] dump_stack+0x4c/0x65
[23978.559191]  [] warn_slowpath_common+0xa1/0xbb
[23978.560699]  [] ? btrfs_drop_extent_cache+0x43/0x385 [btrfs]
[23978.562389]  [] warn_slowpath_null+0x1a/0x1c
[23978.563613]  [] btrfs_drop_extent_cache+0x43/0x385 [btrfs]
[23978.565103]  [] ? time_hardirqs_off+0x15/0x28
[23978.566294]  [] ? trace_hardirqs_off+0xd/0xf
[23978.567438]  [] __btrfs_drop_extents+0x6b/0x9e1 [btrfs]
[23978.568702]  [] ? trace_hardirqs_on+0xd/0xf
[23978.569763]  [] ? ____cache_alloc+0x69/0x2eb
[23978.570817]  [] ? virt_to_head_page+0x9/0x36
[23978.571872]  [] ? cache_alloc_debugcheck_after.isra.42+0x16c/0x1cb
[23978.573466]  [] ? kmemleak_alloc_recursive.constprop.52+0x16/0x18
[23978.574962]  [] btrfs_drop_extents+0x66/0x7f [btrfs]
[23978.576179]  [] btrfs_clone+0x516/0xaf5 [btrfs]
[23978.577311]  [] ? lock_extent_range+0x7b/0xcd [btrfs]
[23978.578520]  [] btrfs_ioctl_clone+0x28e/0x39f [btrfs]
[23978.580282]  [] btrfs_ioctl+0xb51/0x219a [btrfs]
(...)
[23978.591887] ---[ end trace 988ec2a653d03ed3 ]---

Then we attempt to insert a new extent item with a key that already
exists, which makes btrfs_insert_empty_item return -EEXIST resulting in
abortion of the current transaction:

[23978.594355] WARNING: CPU: 6 PID: 16251 at fs/btrfs/super.c:260 __btrfs_abort_transaction+0x52/0x114 [btrfs]()
(...)
[23978.622589] Call Trace:
[23978.623181]  [] dump_stack+0x4c/0x65
[23978.624359]  [] warn_slowpath_common+0xa1/0xbb
[23978.625573]  [] ? __btrfs_abort_transaction+0x52/0x114 [btrfs]
[23978.626971]  [] warn_slowpath_fmt+0x46/0x48
[23978.628003]  [] ? vprintk_default+0x1d/0x1f
[23978.629138]  [] __btrfs_abort_transaction+0x52/0x114 [btrfs]
[23978.630528]  [] btrfs_clone+0x7fc/0xaf5 [btrfs]
[23978.631635]  [] ? lock_extent_range+0x7b/0xcd [btrfs]
[23978.632886]  [] btrfs_ioctl_clone+0x28e/0x39f [btrfs]
[23978.634119]  [] btrfs_ioctl+0xb51/0x219a [btrfs]
(...)
[23978.647714] ---[ end trace 988ec2a653d03ed4 ]---

This is wrong because we should not process the extent item that we just
inserted previously, and instead process the extent item that follows it
in the tree

For example for the test case I wrote for fstests:

   bs=$((64 * 1024))
   mkfs.btrfs -f -l $bs -O ^no-holes /dev/sdc
   mount /dev/sdc /mnt

   xfs_io -f -c "pwrite -S 0xaa $(($bs * 2)) $(($bs * 2))" /mnt/foo

   $CLONER_PROG -s $((3 * $bs)) -d $((267 * $bs)) -l 0 /mnt/foo /mnt/foo
   $CLONER_PROG -s $((217 * $bs)) -d $((95 * $bs)) -l 0 /mnt/foo /mnt/foo

The second clone call fails with -EEXIST, because when we process the
first extent item (offset 262144), we drop part of it (counting from the
end) and then insert a new extent item with a key greater then the key we
found. The next time we search the tree we search for a key with offset
262144 + 1, which leaves us at the new extent item we have just inserted
but we think it refers to an extent that we need to clone.

Fix this by ensuring the next search key uses an offset corresponding to
the offset of the key we found previously plus the data length of the
corresponding extent item. This ensures we skip new extent items that we
inserted and works for the case of implicit holes too (NO_HOLES feature).

A test case for fstests follows soon.

Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

btrfs: cleanup orphans while looking up default subvolume

2015-06-23T00:03:36+00:00

commit 727b9784b6085c99c2f836bf4fcc2848dc9cf904 upstream.

Orphans in the fs tree are cleaned up via open_ctree and subvolume
orphans are cleaned via btrfs_lookup_dentry -- except when a default
subvolume is in use.  The name for the default subvolume uses a manual
lookup that doesn't trigger orphan cleanup and needs to trigger it
manually as well. This doesn't apply to the remount case since the
subvolumes are cleaned up by walking the root radix tree.

Signed-off-by: Jeff Mahoney 
Reviewed-by: David Sterba 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

btrfs: incorrect handling for fiemap_fill_next_extent return

2015-06-23T00:03:36+00:00

commit 26e726afe01c1c82072cf23a5ed89ce25f39d9f2 upstream.

fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was
the last extent that will fit in user array. If 1 is returned, the return
value may eventually returned to user space, which should not happen, according
to manpage of ioctl.

Signed-off-by: Chengyu Song 
Reviewed-by: David Sterba 
Reviewed-by: Liu Bo 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: send, don't leave without decrementing clone root's send_progress

2015-06-23T00:03:36+00:00

commit 2f1f465ae6da244099af55c066e5355abd8ff620 upstream.

If the clone root was not readonly or the dead flag was set on it, we were
leaving without decrementing the root's send_progress counter (and before
we just incremented it). If a concurrent snapshot deletion was in progress
and ended up being aborted, it would be impossible to later attempt to
delete again the snapshot, since the root's send_in_progress counter could
never go back to 0.

We were also setting clone_sources_to_rollback to i + 1 too early - if we
bailed out because the clone root we got is not readonly or flagged as dead
we ended up later derreferencing a null pointer because we didn't assign
the clone root to sctx->clone_roots[i].root:

		for (i = 0; sctx && i < clone_sources_to_rollback; i++)
			btrfs_root_dec_send_in_progress(
					sctx->clone_roots[i].root);

So just don't increment the send_in_progress counter if the root is readonly
or flagged as dead.

Signed-off-by: Filipe Manana 
Reviewed-by: David Sterba 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: send, add missing check for dead clone root

2015-06-23T00:03:36+00:00

commit 5cc2b17e80cf5770f2e585c2d90fd8af1b901258 upstream.

After we locked the root's root item, a concurrent snapshot deletion
call might have set the dead flag on it. So check if the dead flag
is set and abort if it is, just like we do for the parent root.

Signed-off-by: Filipe Manana 
Reviewed-by: David Sterba 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: fix racy system chunk allocation when setting block group ro

2015-06-06T15:20:52+00:00

commit a96295965b600f2dc6ad661c4803c86e87db3d7b upstream.

If while setting a block group read-only we end up allocating a system
chunk, through check_system_chunk(), we were not doing it while holding
the chunk mutex which is a problem if a concurrent chunk allocation is
happening, through do_chunk_alloc(), as it means both block groups can
end up using the same logical addresses and physical regions in the
device(s). So make sure we hold the chunk mutex.

Fixes: 2f0810880f08 ("btrfs: delete chunk allocation attemp when
                      setting block group ro")

Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

btrfs: unlock i_mutex after attempting to delete subvolume during send

2015-05-13T12:14:27+00:00

commit 909e26dce3f7600f5e293ac0522c28790a0c8c9c upstream.

Whenever the check for a send in progress introduced in commit
521e0546c970 (btrfs: protect snapshots from deleting during send) is
hit, we return without unlocking inode->i_mutex. This is easy to see
with lockdep enabled:

[  +0.000059] ================================================
[  +0.000028] [ BUG: lock held when returning to user space! ]
[  +0.000029] 4.0.0-rc5-00096-g3c435c1 #93 Not tainted
[  +0.000026] ------------------------------------------------
[  +0.000029] btrfs/211 is leaving the kernel with locks still held!
[  +0.000029] 1 lock held by btrfs/211:
[  +0.000023]  #0:  (&type->i_mutex_dir_key){+.+.+.}, at: [] btrfs_ioctl_snap_destroy+0x2df/0x7a0

Make sure we unlock it in the error path.

Reviewed-by: Filipe Manana 
Reviewed-by: David Sterba 
Signed-off-by: Omar Sandoval 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: fix inode eviction infinite loop after extent_same ioctl

2015-05-06T20:03:38+00:00

commit 113e8283869b9855c8b999796aadd506bbac155f upstream.

If we pass a length of 0 to the extent_same ioctl, we end up locking an
extent range with a start offset greater then its end offset (if the
destination file's offset is greater than zero). This results in a warning
from extent_io.c:insert_state through the following call chain:

  btrfs_extent_same()
    btrfs_double_lock()
      lock_extent_range()
        lock_extent(inode->io_tree, offset, offset + len - 1)
          lock_extent_bits()
            __set_extent_bit()
              insert_state()
                --> WARN_ON(end < start)

This leads to an infinite loop when evicting the inode. This is the same
problem that my previous patch titled
"Btrfs: fix inode eviction infinite loop after cloning into it" addressed
but for the extent_same ioctl instead of the clone ioctl.

Signed-off-by: Filipe Manana 
Reviewed-by: Omar Sandoval 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman