linux-toradex.git/fs, 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

aio: fix serial draining in exit_aio()

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

commit dc48e56d761610da4ea1088d1bea0a030b8e3e43 upstream.

exit_aio() currently serializes killing io contexts. Each context
killing ends up having to do percpu_ref_kill(), which in turns has
to wait for an RCU grace period. This can take a long time, depending
on the number of contexts. And there's no point in doing them serially,
when we could be waiting for all of them in one fell swoop.

This patches makes my fio thread offload test case exit 0.2s instead
of almost 6s.

Reviewed-by: Jeff Moyer 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman

fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings

2015-06-06T15:21:09+00:00

commit 2b1d3ae940acd11be44c6eced5873d47c2e00ffa upstream.

load_elf_binary() returns `retval', not `error'.

Fixes: a87938b2e246b81b4fb ("fs/binfmt_elf.c: fix bug in loading of PIE binaries")
Reported-by: James Hogan 
Cc: Michael Davidson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

vfs: read file_handle only once in handle_to_path

2015-06-06T15:21:09+00:00

commit 161f873b89136eb1e69477c847d5a5033239d9ba upstream.

We used to read file_handle twice.  Once to get the amount of extra
bytes, and once to fetch the entire structure.

This may be problematic since we do size verifications only after the
first read, so if the number of extra bytes changes in userspace between
the first and second calls, we'll have an incoherent view of
file_handle.

Instead, read the constant size once, and copy that over to the final
structure without having to re-read it again.

Signed-off-by: Sasha Levin 
Cc: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman