linux.git/fs/btrfs/backref.c, branch v3.19

Btrfs: correctly get tree level in tree_backref_for_extent

2015-01-02T19:47:56+00:00

If we are using skinny metadata, the block's tree level is in the offset
of the key and not in a btrfs_tree_block_info structure following the
extent item (it doesn't exist). Therefore fix it.

Besides returning the correct level in the tree, this also prevents reading
past the leaf's end in the case where the extent item is the last item in
the leaf (eb) and it has only 1 inline reference - this is because
sizeof(struct btrfs_tree_block_info) is greater than
sizeof(struct btrfs_extent_inline_ref).

Got it while running a scrub which produced the following warning:

    BTRFS: checksum error at logical 42123264 on dev /dev/sde, sector 15840: metadata node (level 24) in tree 5

Signed-off-by: Filipe Manana 
Reviewed-by: Satoru Takeuchi 
Signed-off-by: Chris Mason

btrfs: remove parameter blocksize from read_tree_block

2014-10-02T15:14:50+00:00

We know the tree block size, no need to pass it around.

Signed-off-by: David Sterba

Btrfs: make fiemap not blow when you have lots of snapshots

2014-09-17T20:38:24+00:00

We have been iterating all references for each extent we have in a file when we
do fiemap to see if it is shared.  This is fine when you have a few clones or a
few snapshots, but when you have 5k snapshots suddenly fiemap just sits there
and stares at you.  So add btrfs_check_shared which will use the backref walking
code but will short circuit as soon as it finds a root or inode that doesn't
match the one we currently have.  This makes fiemap on my testbox go from
looking at me blankly for a day to spitting out actual output in a reasonable
amount of time.  Thanks,

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

btrfs: use nodesize everywhere, kill leafsize

2014-09-17T20:37:14+00:00

The nodesize and leafsize were never of different values. Unify the
usage and make nodesize the one. Cleanup the redundant checks and
helpers.

Shaves a few bytes from .text:

  text    data     bss     dec     hex filename
852418   24560   23112  900090   dbbfa btrfs.ko.before
851074   24584   23112  898770   db6d2 btrfs.ko.after

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

btrfs: kill the key type accessor helpers

2014-09-17T20:37:12+00:00

btrfs_set_key_type and btrfs_key_type are used inconsistently along with
open coded variants. Other members of btrfs_key are accessed directly
without any helpers anyway.

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

Btrfs: Fix memory corruption by ulist_add_merge() on 32bit arch

2014-08-15T14:43:19+00:00

We've got bug reports that btrfs crashes when quota is enabled on
32bit kernel, typically with the Oops like below:
 BUG: unable to handle kernel NULL pointer dereference at 00000004
 IP: [] find_parent_nodes+0x360/0x1380 [btrfs]
 *pde = 00000000
 Oops: 0000 [#1] SMP
 CPU: 0 PID: 151 Comm: kworker/u8:2 Tainted: G S      W 3.15.2-1.gd43d97e-default #1
 Workqueue: btrfs-qgroup-rescan normal_work_helper [btrfs]
 task: f1478130 ti: f147c000 task.ti: f147c000
 EIP: 0060:[] EFLAGS: 00010213 CPU: 0
 EIP is at find_parent_nodes+0x360/0x1380 [btrfs]
 EAX: f147dda8 EBX: f147ddb0 ECX: 00000011 EDX: 00000000
 ESI: 00000000 EDI: f147dda4 EBP: f147ddf8 ESP: f147dd38
  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
 CR0: 8005003b CR2: 00000004 CR3: 00bf3000 CR4: 00000690
 Stack:
  00000000 00000000 f147dda4 00000050 00000001 00000000 00000001 00000050
  00000001 00000000 d3059000 00000001 00000022 000000a8 00000000 00000000
  00000000 000000a1 00000000 00000000 00000001 00000000 00000000 11800000
 Call Trace:
  [] __btrfs_find_all_roots+0x9d/0xf0 [btrfs]
  [] btrfs_qgroup_rescan_worker+0x401/0x760 [btrfs]
  [] normal_work_helper+0xc8/0x270 [btrfs]
  [] process_one_work+0x11b/0x390
  [] worker_thread+0x101/0x340
  [] kthread+0x9b/0xb0
  [] ret_from_kernel_thread+0x21/0x30
  [] kthread_create_on_node+0x110/0x110

This indicates a NULL corruption in prefs_delayed list.  The further
investigation and bisection pointed that the call of ulist_add_merge()
results in the corruption.

ulist_add_merge() takes u64 as aux and writes a 64bit value into
old_aux.  The callers of this function in backref.c, however, pass a
pointer of a pointer to old_aux.  That is, the function overwrites
64bit value on 32bit pointer.  This caused a NULL in the adjacent
variable, in this case, prefs_delayed.

Here is a quick attempt to band-aid over this: a new function,
ulist_add_merge_ptr() is introduced to pass/store properly a pointer
value instead of u64.  There are still ugly void ** cast remaining
in the callers because void ** cannot be taken implicitly.  But, it's
safer than explicit cast to u64, anyway.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=887046
Cc:  [v3.11+]
Signed-off-by: Takashi Iwai 
Signed-off-by: Chris Mason

Btrfs: read lock extent buffer while walking backrefs

2014-08-15T14:43:13+00:00

Before processing the extent buffer, acquire a read lock on it, so
that we're safe against concurrent updates on the extent buffer.

Signed-off-by: Filipe Manana 
Signed-off-by: Chris Mason

Btrfs: fix scrub_print_warning to handle skinny metadata extents

2014-06-10T00:21:17+00:00

The skinny extents are intepreted incorrectly in scrub_print_warning(),
and end up hitting the BUG() in btrfs_extent_inline_ref_size.

Reported-by: Konstantinos Skarlatos 
Signed-off-by: Liu Bo 
Signed-off-by: Chris Mason

Btrfs: use right type to get real comparison

2014-06-10T00:21:15+00:00

We want to make sure the point is still within the extent item, not to verify
the memory it's pointing to.

Signed-off-by: Liu Bo 
Signed-off-by: Chris Mason

Btrfs: don't check nodes for extent items

2014-06-10T00:21:14+00:00

The backref code was looking at nodes as well as leaves when we tried to
populate extent item entries.  This is not good, and although we go away with it
for the most part because we'd skip where disk_bytenr != random_memory,
sometimes random_memory would match and suddenly boom.  This fixes that problem.
Thanks,

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