All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] btrfs: fix uninitialized ret in ref-verify
@ 2019-10-02 14:03 Josef Bacik
  2019-10-02 16:21 ` David Sterba
  2019-10-02 16:31 ` Colin Ian King
  0 siblings, 2 replies; 3+ messages in thread
From: Josef Bacik @ 2019-10-02 14:03 UTC (permalink / raw)
  To: linux-btrfs, kernel-team; +Cc: Colin Ian King

Coverity caught a case where we could return with a uninitialized value
in ret in process_leaf.  This is actually pretty likely because we could
very easily run into a block group item key and have a garbage value in
ret and think there was an errror.  Fix this by initializing ret to 0.

Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/ref-verify.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c
index e87cbdad02a3..b57f3618e58e 100644
--- a/fs/btrfs/ref-verify.c
+++ b/fs/btrfs/ref-verify.c
@@ -500,7 +500,7 @@ static int process_leaf(struct btrfs_root *root,
 	struct btrfs_extent_data_ref *dref;
 	struct btrfs_shared_data_ref *sref;
 	u32 count;
-	int i = 0, tree_block_level = 0, ret;
+	int i = 0, tree_block_level = 0, ret = 0;
 	struct btrfs_key key;
 	int nritems = btrfs_header_nritems(leaf);
 
-- 
2.21.0


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] btrfs: fix uninitialized ret in ref-verify
  2019-10-02 14:03 [PATCH] btrfs: fix uninitialized ret in ref-verify Josef Bacik
@ 2019-10-02 16:21 ` David Sterba
  2019-10-02 16:31 ` Colin Ian King
  1 sibling, 0 replies; 3+ messages in thread
From: David Sterba @ 2019-10-02 16:21 UTC (permalink / raw)
  To: Josef Bacik; +Cc: linux-btrfs, kernel-team, Colin Ian King

On Wed, Oct 02, 2019 at 10:03:36AM -0400, Josef Bacik wrote:
> Coverity caught a case where we could return with a uninitialized value
> in ret in process_leaf.  This is actually pretty likely because we could
> very easily run into a block group item key and have a garbage value in
> ret and think there was an errror.  Fix this by initializing ret to 0.
> 
> Reported-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Reviewed-by: David Sterba <dsterba@suse.com>

Added to misc-next, thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] btrfs: fix uninitialized ret in ref-verify
  2019-10-02 14:03 [PATCH] btrfs: fix uninitialized ret in ref-verify Josef Bacik
  2019-10-02 16:21 ` David Sterba
@ 2019-10-02 16:31 ` Colin Ian King
  1 sibling, 0 replies; 3+ messages in thread
From: Colin Ian King @ 2019-10-02 16:31 UTC (permalink / raw)
  To: Josef Bacik, linux-btrfs, kernel-team

On 02/10/2019 15:03, Josef Bacik wrote:
> Coverity caught a case where we could return with a uninitialized value
> in ret in process_leaf.  This is actually pretty likely because we could
> very easily run into a block group item key and have a garbage value in
> ret and think there was an errror.  Fix this by initializing ret to 0.
> 
> Reported-by: Colin Ian King <colin.king@canonical.com>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
>  fs/btrfs/ref-verify.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c
> index e87cbdad02a3..b57f3618e58e 100644
> --- a/fs/btrfs/ref-verify.c
> +++ b/fs/btrfs/ref-verify.c
> @@ -500,7 +500,7 @@ static int process_leaf(struct btrfs_root *root,
>  	struct btrfs_extent_data_ref *dref;
>  	struct btrfs_shared_data_ref *sref;
>  	u32 count;
> -	int i = 0, tree_block_level = 0, ret;
> +	int i = 0, tree_block_level = 0, ret = 0;
>  	struct btrfs_key key;
>  	int nritems = btrfs_header_nritems(leaf);
>  
> 
Thanks Josef.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-10-02 16:31 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-02 14:03 [PATCH] btrfs: fix uninitialized ret in ref-verify Josef Bacik
2019-10-02 16:21 ` David Sterba
2019-10-02 16:31 ` Colin Ian King

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.