Skip to contentSkip to conversation

passing positive numbers to ERR_PTR()

PATCH New Dan Carpenter 2 participants 2 messages Feb 8, 2012 Btrfs file system

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

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
index 633c701..98f6bf10 100644
@@ -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