linux.git/fs/btrfs/relocation.c, branch v4.19

btrfs: btrfs_iget never returns an is_bad_inode inode

2018-08-06T11:13:02+00:00

Just get rid of pointless checks.

Signed-off-by: Al Viro 
Reviewed-by: Nikolay Borisov 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: qgroup: Drop root parameter from btrfs_qgroup_trace_subtree

2018-08-06T11:12:52+00:00

The fs_info can be fetched from the transaction handle directly.

Signed-off-by: Lu Fengqi 
Signed-off-by: David Sterba

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

2018-08-06T11:12:42+00:00

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

btrfs: annotate unlikely branches after V0 extent type removal

2018-08-06T11:12:41+00:00

The v0 extent type checks are the right case for the unlikely
annotations as we don't expect to ever see them, so let's give the
compiler some hint.

Reviewed-by: Nikolay Borisov 
Signed-off-by: David Sterba

btrfs: Add graceful handling of V0 extents

2018-08-06T11:12:41+00:00

Following the removal of the v0 handling code let's be courteous and
print an error message when such extents are handled. In the cases
where we have a transaction just abort it, otherwise just call
btrfs_handle_fs_error. Both cases result in the FS being re-mounted RO.

In case the error handling would be too intrusive, leave the BUG_ON in
place, like extent_data_ref_count, other proper handling would catch
that earlier.

Signed-off-by: Nikolay Borisov 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: Remove V0 extent support

2018-08-06T11:12:41+00:00

The v0 compat code was introduced in commit 5d4f98a28c7d
("Btrfs: Mixed back reference  (FORWARD ROLLING FORMAT CHANGE)") 9
years ago, which was merged in 2.6.31. This means that the code is
there to support filesystems which are _VERY_ old and if you are using
btrfs on such an old kernel, you have much bigger problems. This coupled
with the fact that no one is likely testing/maintining this code likely
means it has bugs lurking. All things considered I think 43 kernel
releases later it's high time this remnant of the past got removed.

This patch removes all code wrapped in #ifdefs but leaves the BUG_ONs in case
we have a v0 with no support intact as a sort of safety-net.

Signed-off-by: Nikolay Borisov 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: return EUCLEAN if extent_inline_ref type is invalid

2018-08-06T11:12:40+00:00

If type of extent_inline_ref found is not expected, filesystem may have
been corrupted, should return EUCLEAN instead of EINVAL.

Signed-off-by: Su Yue 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: Remove fs_info from btrfs_force_chunk_alloc

2018-08-06T11:12:38+00:00

It can be referenced from the passed transaction handle.

Signed-off-by: Nikolay Borisov 
Reviewed-by: Qu Wenruo 
Signed-off-by: David Sterba

btrfs: Remove fs_info from btrfs_inc_block_group_ro

2018-08-06T11:12:37+00:00

It can be referenced from the passed bg cache.

Signed-off-by: Nikolay Borisov 
Reviewed-by: Qu Wenruo 
Signed-off-by: David Sterba

btrfs: fix describe_relocation when printing unknown flags

2018-05-28T16:24:11+00:00

Looks like the original idea was to print the hex of the flags which is
not coded with their flag name. So use the current buf pointer bp
instead of buf.

Reaching the uknown flags should never happen, it's there just in case.

Fixes: ebce0e01b930b ("btrfs: make block group flags in balance printks human-readable")
Signed-off-by: Anand Jain 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba