fs/btrfs/ioctl.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
After the introduction of btrfs_search_backwards(), the directory
traversal state in btrfs_search_path_in_tree() is fully maintained via
struct btrfs_key. The local variable 'dirid' is no longer used to control
the search and the assignment
dirid = key.objectid;
has no observable effect and is dead code.
Also initialize ret at declaration and remove a redundant
"ret = 0;" before out:.
Remove the unused assignment to avoid confusion and silence static
analysis warnings.
No functional change.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Evgenii Burenchev <eburenchev@orionsoft.ru>
---
fs/btrfs/ioctl.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index a6cc2d3b414c..d85e6a92538e 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -1648,7 +1648,7 @@ static noinline int btrfs_search_path_in_tree(struct btrfs_fs_info *info,
struct btrfs_root *root;
struct btrfs_key key;
char *ptr;
- int ret = -1;
+ int ret = 0;
int slot;
int len;
int total_len = 0;
@@ -1708,11 +1708,9 @@ static noinline int btrfs_search_path_in_tree(struct btrfs_fs_info *info,
btrfs_release_path(path);
key.objectid = key.offset;
key.offset = (u64)-1;
- dirid = key.objectid;
}
memmove(name, ptr, total_len);
name[total_len] = '\0';
- ret = 0;
out:
btrfs_put_root(root);
return ret;
--
2.43.0
On Thu, Feb 19, 2026 at 05:55:32PM +0000, Burenchev Evgenii wrote: > After the introduction of btrfs_search_backwards(), the directory > traversal state in btrfs_search_path_in_tree() is fully maintained via > struct btrfs_key. The local variable 'dirid' is no longer used to control > the search and the assignment > > dirid = key.objectid; > > has no observable effect and is dead code. > Can you please split the patch to 1) remove the dirid assignment (v1 of this patch) and 2) the return cleanup? It's two changes, the dead code is trivial, but the return code should match some pattern we're using. Sometimes the explicit 'ret = 0' is there to make it clear there's no stale error code being propagated out of the function, but in this case I don't se a reason for it. Thanks.
© 2016 - 2026 Red Hat, Inc.