Re: [PATCH] btrfs: fix build warning

2016-03-22 Thread David Sterba
On Tue, Mar 22, 2016 at 10:39:59AM +0100, Geert Uytterhoeven wrote:
> On Tue, Feb 16, 2016 at 9:02 AM, Sudip Mukherjee
>  wrote:
> > We were getting build warning about:
> > fs/btrfs/extent-tree.c:7021:34: warning: ‘used_bg’ may be used
> > uninitialized in this function
> >
> > It is not a valid warning as used_bg is never used uninitilized since
> > locked is initially false so we can never be in the section where
> > 'used_bg' is used. But gcc is not able to understand that and we can
> > initialize it while declaring to silence the warning.
> >
> > Signed-off-by: Sudip Mukherjee 
> 
> FWIW, I've posted an alternative patch that killed the silly locked variable
> a while ago.
> "[PATCH] Btrfs: Refactor btrfs_lock_cluster() to kill compiler warning"
> https://lkml.org/lkml/2014/6/22/96

The cleanup looks great, thanks, patch picked.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] btrfs: fix build warning

2016-03-22 Thread Geert Uytterhoeven
On Tue, Feb 16, 2016 at 9:02 AM, Sudip Mukherjee
 wrote:
> We were getting build warning about:
> fs/btrfs/extent-tree.c:7021:34: warning: ‘used_bg’ may be used
> uninitialized in this function
>
> It is not a valid warning as used_bg is never used uninitilized since
> locked is initially false so we can never be in the section where
> 'used_bg' is used. But gcc is not able to understand that and we can
> initialize it while declaring to silence the warning.
>
> Signed-off-by: Sudip Mukherjee 

FWIW, I've posted an alternative patch that killed the silly locked variable
a while ago.
"[PATCH] Btrfs: Refactor btrfs_lock_cluster() to kill compiler warning"
https://lkml.org/lkml/2014/6/22/96

> ---
>  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 e2287c7..f24e4c3 100644
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -7018,7 +7018,7 @@ btrfs_lock_cluster(struct btrfs_block_group_cache 
> *block_group,
>struct btrfs_free_cluster *cluster,
>int delalloc)
>  {
> -   struct btrfs_block_group_cache *used_bg;
> +   struct btrfs_block_group_cache *used_bg = NULL;
> bool locked = false;
>  again:
> spin_lock(>refill_lock);
> --
> 1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] btrfs: fix build warning

2016-02-16 Thread Sudip Mukherjee
We were getting build warning about:
fs/btrfs/extent-tree.c:7021:34: warning: ‘used_bg’ may be used
uninitialized in this function

It is not a valid warning as used_bg is never used uninitilized since
locked is initially false so we can never be in the section where
'used_bg' is used. But gcc is not able to understand that and we can
initialize it while declaring to silence the warning.

Signed-off-by: Sudip Mukherjee 
---
 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 e2287c7..f24e4c3 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -7018,7 +7018,7 @@ btrfs_lock_cluster(struct btrfs_block_group_cache 
*block_group,
   struct btrfs_free_cluster *cluster,
   int delalloc)
 {
-   struct btrfs_block_group_cache *used_bg;
+   struct btrfs_block_group_cache *used_bg = NULL;
bool locked = false;
 again:
spin_lock(>refill_lock);
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html