passing positive numbers to ERR_PTR()
Hi Jan,
Smatch complains when you pass positive numbers to ERR_PTR(). There is a warning triggered in iref_to_path().
fs/btrfs/backref.c +920 iref_to_path()
918
919 if (ret)
920 return ERR_PTR(ret);
^^^"ret" can be either a negative error code, zero, or one here.
921
I looked at the code, but couldn't tell if it was intentional or not. It really is pretty unusual to do that, so maybe there should be a comment or something.
regards,
dan carpenter
PATCH 1/1 Btrfs: avoid positive number with ERR_PTR
inode_ref_info() returns 1 when the element wasn't found and < 0 on error, just like btrfs_search_slot(). In iref_to_path() it's an error when the inode ref can't be found, thus we return ERR_PTR(ret) in that case. In order to avoid ERR_PTR(1), we now set ret to -ENOENT in that case.
---
Quoted 1 line · Dan Carpenter
I looked at the code, but couldn't tell if it was intentional or not.
It wasn't :-)
Thank you,
-Jan
--- fs/btrfs/backref.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)
---
fs/btrfs/backref.c +2 -0
@@ -892,6 +892,8 @@ static char *iref_to_path(struct btrfs_root *fs_root, struct btrfs_path *path,if (eb != eb_in)free_extent_buffer (eb); ret =inode_ref_info (parent,0 , fs_root, path, &found_key); +if (ret >0 ) + ret = -ENOENT ;if (ret)break ; next_inum = found_key.offset;
Signature · 1 line
1.7.3.4