Skip to contentSkip to conversation

Btrfs: do not overwrite error return value in scrub progress ioctl

PATCH Superseded [email protected] 4 participants 4 messages Dec 14, 2018 – Jan 2, 2019 Btrfs file system

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Btrfs: do not overwrite error return value in scrub progress ioctl

From: Filipe Manana <[email protected]>

If the call to btrfs_scrub_progress() failed we would overwrite the error returned to user space with -EFAULT if the call to copy_to_user() failed as well. Fix that by calling copy_to_user() only if btrfs_scrub_progress() returned success.

---
 fs/btrfs/ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/ioctl.c +1 -1
index 01d18e1a393e..76848214a39f 100644
@@ -4331,7 +4331,7 @@ static long btrfs_ioctl_scrub_progress(struct btrfs_fs_info *fs_info,
 
 	ret = btrfs_scrub_progress(fs_info, sa->devid, &sa->progress);
 
-	if (copy_to_user(arg, sa, sizeof(*sa)))
+	if (ret == 0 && copy_to_user(arg, sa, sizeof(*sa)))
 		ret = -EFAULT;
 
 	kfree(sa);
Signature · 1 line
2.11.0
Reviewed-by on v1 1/1
#1 lore raw
Quoted 17 lines · On 14.12.18 г. 21:45 ч., [email protected] wrote:

From: Filipe Manana <[email protected]>

If the call to btrfs_scrub_progress() failed we would overwrite the error returned to user space with -EFAULT if the call to copy_to_user() failed as well. Fix that by calling copy_to_user() only if btrfs_scrub_progress() returned success.

---
 fs/btrfs/ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/ioctl.c +0 -0
index 01d18e1a393e..76848214a39f 100644

fs/btrfs/ioctl.c static long btrfs_ioctl_scrub_progress(struct btrfs_fs_info *fs_info, · line 4334

Quoted 5 lines
fs/btrfs/ioctl.c +1 -1
@@ -4331,7 +4331,7 @@ static long btrfs_ioctl_scrub_progress(struct btrfs_fs_info *fs_info,
 
 	ret = btrfs_scrub_progress(fs_info, sa->devid, &sa->progress);
 
-	if (copy_to_user(arg, sa, sizeof(*sa)))
+	if (ret == 0 && copy_to_user(arg, sa, sizeof(*sa)))

While this is ok it's a bit counter intuitive considering the code convention. Because you predicate the execution of copy_to_user on the ret value of btrfs_scrub_progress in the same if. Perhaps,

if (ret)
return ret;

if (copy_to_user)
return -EFAULT

Same feedback applies to your other patches, but I'm fine if you leave it as is so:

Quoted 4 lines
fs/btrfs/ioctl.c +0 -0
 		ret = -EFAULT;
 
 	kfree(sa);
#2 lore raw
Quoted 33 lines · Nikolay Borisov
Quoted 17 lines · On 14.12.18 г. 21:45 ч., [email protected] wrote:

From: Filipe Manana <[email protected]>

If the call to btrfs_scrub_progress() failed we would overwrite the error returned to user space with -EFAULT if the call to copy_to_user() failed as well. Fix that by calling copy_to_user() only if btrfs_scrub_progress() returned success.

---
 fs/btrfs/ioctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/ioctl.c +0 -0
index 01d18e1a393e..76848214a39f 100644

fs/btrfs/ioctl.c static long btrfs_ioctl_scrub_progress(struct btrfs_fs_info *fs_info, · line 4334

Quoted 5 lines
fs/btrfs/ioctl.c +1 -1
@@ -4331,7 +4331,7 @@ static long btrfs_ioctl_scrub_progress(struct btrfs_fs_info *fs_info,
 
 	ret = btrfs_scrub_progress(fs_info, sa->devid, &sa->progress);
 
-	if (copy_to_user(arg, sa, sizeof(*sa)))
+	if (ret == 0 && copy_to_user(arg, sa, sizeof(*sa)))

While this is ok it's a bit counter intuitive considering the code convention. Because you predicate the execution of copy_to_user on the ret value of btrfs_scrub_progress in the same if. Perhaps,

if (ret)
return ret;

Quoted 6 lines

if (copy_to_user)
return -EFAULT

Same feedback applies to your other patches, but I'm fine if you leave it as is so:

I've checked how common is "if (ret == 0 && copy_to_user...)" and there are several instances. The additional condition is quite short so the copy_to_user call is not lost in the noise, so I'm ok with the proposed style. I would not even mind to unify other calls that do not follow some common pattern eg. in btrfs_ioctl_set_received_subvol or btrfs_ioctl_get_fslabel.

Reviewed-by on v1 1/1
#3 lore raw
In reply to [email protected]
Quoted 8 lines · On 12/15/2018 03:45 AM, [email protected] wrote:

From: Filipe Manana <[email protected]>

If the call to btrfs_scrub_progress() failed we would overwrite the error returned to user space with -EFAULT if the call to copy_to_user() failed as well. Fix that by calling copy_to_user() only if btrfs_scrub_progress() returned success.

Quoted 18 lines
---
  fs/btrfs/ioctl.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/ioctl.c +1 -1
index 01d18e1a393e..76848214a39f 100644
@@ -4331,7 +4331,7 @@ static long btrfs_ioctl_scrub_progress(struct btrfs_fs_info *fs_info,
 
  	ret = btrfs_scrub_progress(fs_info, sa->devid, &sa->progress);
 
-	if (copy_to_user(arg, sa, sizeof(*sa)))
+	if (ret == 0 && copy_to_user(arg, sa, sizeof(*sa)))
  		ret = -EFAULT;
 
  	kfree(sa);