linux-stable.git/fs/btrfs/relocation.c, branch linux-3.16.y

btrfs: do not leak reloc root if we fail to read the fs root

2020-04-28T18:03:00+00:00

commit ca1aa2818a53875cfdd175fb5e9a2984e997cce9 upstream.

If we fail to read the fs root corresponding with a reloc root we'll
just break out and free the reloc roots.  But we remove our current
reloc_root from this list higher up, which means we'll leak this
reloc_root.  Fix this by adding ourselves back to the reloc_roots list
so we are properly cleaned up.

Reviewed-by: Filipe Manana 
Reviewed-by: Johannes Thumshirn 
Signed-off-by: Josef Bacik 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Ben Hutchings

btrfs: relocation: set trans to be NULL after ending transaction

2019-02-11T17:54:10+00:00

commit 42a657f57628402c73237547f0134e083e2f6764 upstream.

The function relocate_block_group calls btrfs_end_transaction to release
trans when update_backref_cache returns 1, and then continues the loop
body. If btrfs_block_rsv_refill fails this time, it will jump out the
loop and the freed trans will be accessed. This may result in a
use-after-free bug. The patch assigns NULL to trans after trans is
released so that it will not be accessed.

Fixes: 0647bf564f1 ("Btrfs: improve forever loop when doing balance relocation")
Reviewed-by: Qu Wenruo 
Signed-off-by: Pan Bian 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings

btrfs: relocation: Only remove reloc rb_trees if reloc control has been initialized

2018-09-25T22:47:32+00:00

commit 389305b2aa68723c754f88d9dbd268a400e10664 upstream.

Invalid reloc tree can cause kernel NULL pointer dereference when btrfs
does some cleanup of the reloc roots.

It turns out that fs_info::reloc_ctl can be NULL in
btrfs_recover_relocation() as we allocate relocation control after all
reloc roots have been verified.
So when we hit: note, we haven't called set_reloc_control() thus
fs_info::reloc_ctl is still NULL.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199833
Reported-by: Xu Wen 
Signed-off-by: Qu Wenruo 
Tested-by: Gu Jinxiang 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Ben Hutchings

Btrfs: fix build_backref_tree issue with multiple shared blocks

2014-10-30T16:40:09+00:00

commit bbe9051441effce51c9a533d2c56440df64db2d7 upstream.

Marc Merlin sent me a broken fs image months ago where it would blow up in the
upper->checked BUG_ON() in build_backref_tree.  This is because we had a
scenario like this

block a -- level 4 (not shared)
   |
block b -- level 3 (reloc block, shared)
   |
block c -- level 2 (not shared)
   |
block d -- level 1 (shared)
   |
block e -- level 0 (shared)

We go to build a backref tree for block e, we notice block d is shared and add
it to the list of blocks to lookup it's backrefs for.  Now when we loop around
we will check edges for the block, so we will see we looked up block c last
time.  So we lookup block d and then see that the block that points to it is
block c and we can just skip that edge since we've already been up this path.
The problem is because we clear need_check when we see block d (as it is shared)
we never add block b as needing to be checked.  And because block c is in our
path already we bail out before we walk up to block b and add it to the backref
check list.

To fix this we need to reset need_check if we trip over a block that doesn't
need to be checked.  This will make sure that any subsequent blocks in the path
as we're walking up afterwards are added to the list to be processed.  With this
patch I can now mount Marc's fs image and it'll complete the balance without
panicing.  Thanks,

Reported-by: Marc MERLIN 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason 
Signed-off-by: Greg Kroah-Hartman

Btrfs: cleanup error handling in build_backref_tree

2014-10-30T16:40:09+00:00

commit 75bfb9aff45e44625260f52a5fd581b92ace3e62 upstream.

When balance panics it tends to panic in the

BUG_ON(!upper->checked);

test, because it means it couldn't build the backref tree properly.  This is
annoying to users and frankly a recoverable error, nothing in this function is
actually fatal since it is just an in-memory building of the backrefs for a
given bytenr.  So go through and change all the BUG_ON()'s to ASSERT()'s, and
fix the BUG_ON(!upper->checked) thing to just return an error.

This patch also fixes the error handling so it tears down the work we've done
properly.  This code was horribly broken since we always just panic'ed instead
of actually erroring out, so it needed to be completely re-worked.  With this
patch my broken image no longer panics when I mount it.  Thanks,

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

btrfs: remove stale newlines from log messages

2014-06-10T00:20:53+00:00

I've noticed an extra line after "use no compression", but search
revealed much more in messages of more critical levels and rare errors.

Signed-off-by: David Sterba 
Signed-off-by: Chris Mason

Btrfs: use bitfield instead of integer data type for the some variants in btrfs_root

2014-06-10T00:20:40+00:00

Signed-off-by: Miao Xie 
Signed-off-by: Wang Shilong 
Signed-off-by: Chris Mason

Btrfs: do not reset last_snapshot after relocation

2014-04-07T00:34:35+00:00

This was done to allow NO_COW to continue to be NO_COW after relocation but it
is not right.  When relocating we will convert blocks to FULL_BACKREF that we
relocate.  We can leave some of these full backref blocks behind if they are not
cow'ed out during the relocation, like if we fail the relocation with ENOSPC and
then just drop the reloc tree.  Then when we go to cow the block again we won't
lookup the extent flags because we won't think there has been a snapshot
recently which means we will do our normal ref drop thing instead of adding back
a tree ref and dropping the shared ref.  This will cause btrfs_free_extent to
blow up because it can't find the ref we are trying to free.  This was found
with my ref verifying tool.  Thanks,

Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason

Btrfs: don't flush all delalloc inodes when we doesn't get s_umount lock

2014-03-10T19:17:27+00:00

We needn't flush all delalloc inodes when we doesn't get s_umount lock,
or we would make the tasks wait for a long time.

Signed-off-by: Miao Xie 
Signed-off-by: Josef Bacik

Btrfs: fix an oops when we fail to relocate tree blocks

2014-01-28T21:20:14+00:00

During balance test, we hit an oops:
[ 2013.841551] kernel BUG at fs/btrfs/relocation.c:1174!

The problem is that if we fail to relocate tree blocks, we should
update backref cache, otherwise, some pending nodes are not updated
while snapshot check @cache->last_trans is within one transaction
and won't update it and then oops happen.

Signed-off-by: Wang Shilong 
Signed-off-by: Josef Bacik 
Signed-off-by: Chris Mason