linux.git/fs/btrfs/ref-verify.c, branch v5.13

btrfs: ref-verify: use 'inline void' keyword ordering

2021-03-02T15:55:40+00:00

Fix build warnings of function signature when CONFIG_STACKTRACE is not
enabled by reordering the 'inline' and 'void' keywords.

../fs/btrfs/ref-verify.c:221:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
 static void inline __save_stack_trace(struct ref_action *ra)
../fs/btrfs/ref-verify.c:225:1: warning: ‘inline’ is not at beginning of declaration [-Wold-style-declaration]
 static void inline __print_stack_trace(struct btrfs_fs_info *fs_info,

Signed-off-by: Randy Dunlap 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: ref-verify: make sure owner is set for all refs

2021-02-08T21:58:50+00:00

I noticed that shared ref entries in ref-verify didn't have the proper
owner set, which caused me to think there was something seriously wrong.
However the problem is if we have a parent we simply weren't filling out
the owner part of the reference, even though we have it.

Fix this by making sure we set all the proper fields when we modify a
reference, this way we'll have the proper owner if a problem happens and
we don't waste time thinking we're updating the wrong level.

Signed-off-by: Josef Bacik 
Signed-off-by: David Sterba

btrfs: ref-verify: pass down tree block level when building refs

2021-02-08T21:58:50+00:00

I noticed that sometimes I would have the wrong level printed out with
ref-verify while testing some error injection related problems.  This is
because we only get the level from the main extent item, but our
references could go off the current leaf into another, and at that point
we lose our level.

Fix this by keeping track of the last tree block level that we found,
the same way we keep track of our bytenr and num_bytes, in case we
happen to wander into another leaf while still processing the references
for a bytenr.

Signed-off-by: Josef Bacik 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: use btrfs_read_node_slot in walk_down_tree

2020-12-08T14:54:06+00:00

We're open-coding btrfs_read_node_slot() here, replace with the helper.

Reviewed-by: Filipe Manana 
Signed-off-by: Josef Bacik 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: locking: remove all the blocking helpers

2020-12-08T14:54:01+00:00

Now that we're using a rw_semaphore we no longer need to indicate if a
lock is blocking or not, nor do we need to flip the entire path from
blocking to spinning.  Remove these helpers and all the places they are
called.

Signed-off-by: Josef Bacik 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: remove unnecessary casts in printk

2020-12-08T14:53:52+00:00

Long time ago the explicit casts were necessary for u64 but we don't
need it.  Remove casts where the type matches, leaving only cases that
cast sector_t or loff_t.

Reviewed-by: Josef Bacik 
Signed-off-by: David Sterba

btrfs: ref-verify: fix memory leak in btrfs_ref_tree_mod

2020-11-05T12:03:39+00:00

There is one error handling path that does not free ref, which may cause
a minor memory leak.

CC: stable@vger.kernel.org # 4.19+
Reviewed-by: Josef Bacik 
Signed-off-by: Dinghao Liu 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: ref-verify: fix memory leak in add_block_entry

2020-07-27T10:55:43+00:00

clang static analysis flags this error

fs/btrfs/ref-verify.c:290:3: warning: Potential leak of memory pointed to by 're' [unix.Malloc]
                kfree(be);
                ^~~~~

The problem is in this block of code:

	if (root_objectid) {
		struct root_entry *exist_re;

		exist_re = insert_root_entry(&exist->roots, re);
		if (exist_re)
			kfree(re);
	}

There is no 'else' block freeing when root_objectid is 0. Add the
missing kfree to the else branch.

Fixes: fd708b81d972 ("Btrfs: add a extent ref verify tool")
CC: stable@vger.kernel.org # 4.19+
Signed-off-by: Tom Rix 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: convert comments to fallthrough annotations

2020-07-02T08:18:30+00:00

Convert fall through comments to the pseudo-keyword which is now the
preferred way.

Signed-off-by: Marcos Paulo de Souza 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba

btrfs: fix ref-verify to catch operations on 0 ref extents

2020-03-23T16:01:56+00:00

While debugging I noticed I wasn't getting ref verify errors before
everything blew up.  Turns out it's because we don't warn when we try to
add a normal ref via btrfs_inc_ref() if the block entry exists but has 0
references.  This is incorrect, we should never be doing anything other
than adding a new extent once a block entry drops to 0 references.

Signed-off-by: Josef Bacik 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba