diff mbox

[07/22] btrfs: don't leak ret from do_chunk_alloc

Message ID 20180719145006.17532-7-josef@toxicpanda.com (mailing list archive)
State New, archived
Headers show

Commit Message

Josef Bacik July 19, 2018, 2:49 p.m. UTC
If we're trying to make a data reservation and we have to allocate a
data chunk we could leak ret == 1, as do_chunk_alloc() will return 1 if
it allocated a chunk.  Since the end of the function is the success path
just return 0.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/extent-tree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Nikolay Borisov July 19, 2018, 3:43 p.m. UTC | #1
On 19.07.2018 17:49, Josef Bacik wrote:
> If we're trying to make a data reservation and we have to allocate a
> data chunk we could leak ret == 1, as do_chunk_alloc() will return 1 if
> it allocated a chunk.  Since the end of the function is the success path
> just return 0.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Reviewed-by: Nikolay Borisov <nborisov@suse.com>

The logic flow in this function is a steaming pile of turd and is in
dire need of refactoring...
> ---
>  fs/btrfs/extent-tree.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
> index 523bc197c40b..6de9a180abdd 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -4360,7 +4360,7 @@ int btrfs_alloc_data_chunk_ondemand(struct btrfs_inode *inode, u64 bytes)
>  				      data_sinfo->flags, bytes, 1);
>  	spin_unlock(&data_sinfo->lock);
>  
> -	return ret;
> +	return 0;
>  }
>  
>  int btrfs_check_data_free_space(struct inode *inode,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Sterba July 24, 2018, 11:24 a.m. UTC | #2
On Thu, Jul 19, 2018 at 06:43:39PM +0300, Nikolay Borisov wrote:
> 
> 
> On 19.07.2018 17:49, Josef Bacik wrote:
> > If we're trying to make a data reservation and we have to allocate a
> > data chunk we could leak ret == 1, as do_chunk_alloc() will return 1 if
> > it allocated a chunk.  Since the end of the function is the success path
> > just return 0.
> > 
> > Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> 
> Reviewed-by: Nikolay Borisov <nborisov@suse.com>
> 
> The logic flow in this function is a steaming pile of turd and is in
> dire need of refactoring...

Agreed, fixing the default return code seems like the right fix now,
compared to untangling the gotos. Patch added to misc-next.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 523bc197c40b..6de9a180abdd 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -4360,7 +4360,7 @@  int btrfs_alloc_data_chunk_ondemand(struct btrfs_inode *inode, u64 bytes)
 				      data_sinfo->flags, bytes, 1);
 	spin_unlock(&data_sinfo->lock);
 
-	return ret;
+	return 0;
 }
 
 int btrfs_check_data_free_space(struct inode *inode,