lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 1 Feb 2023 10:38:16 +0800
From:   Qu Wenruo <quwenruo.btrfs@....com>
To:     ye.xingchen@....com.cn, clm@...com
Cc:     josef@...icpanda.com, dsterba@...e.com,
        linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Btrfs: fix compile error about uninitialized variable



On 2023/2/1 10:22, ye.xingchen@....com.cn wrote:
> From: Minghao Chi <chi.minghao@....com.cn>
> 
> fs/btrfs/tree-log.c:6166:6: note: 'last_range_start' was declared here
> fs/btrfs/volumes.c:2598:27: note: 'seed_devices' was declared here
> fs/btrfs/send.c:1909:13: error: 'right_gen' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Have you really dig into the code?

When @right_gen is not initialized, we have @right_ret assigned to -ENOENT.

Thus all later code checking @right_gen would not be executed, and this 
is a false alert.

You should explain this is a false alert first.

Secondly it's easy to just stick a "= 0" to whatever compiler complains 
in this case, but since it's a false alert, you really need to explain 
your compiler version to see if it's really better to fix in the code 
other than your compiler.

> 
> Signed-off-by: Minghao Chi <chi.minghao@....com.cn>
> Signed-off-by: ye xingchen <ye.xingchen@....com.cn>
> ---
>   fs/btrfs/send.c     | 2 +-
>   fs/btrfs/tree-log.c | 2 +-
>   fs/btrfs/volumes.c  | 2 +-
>   3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
> index c3146ce84156..3c9f2d30065d 100644
> --- a/fs/btrfs/send.c
> +++ b/fs/btrfs/send.c
> @@ -1875,7 +1875,7 @@ static int get_cur_inode_state(struct send_ctx *sctx, u64 ino, u64 gen,
>   	int left_ret;
>   	int right_ret;
>   	u64 left_gen;
> -	u64 right_gen;
> +	u64 right_gen = 0;
>   	struct btrfs_inode_info info;
> 
>   	ret = get_inode_info(sctx->send_root, ino, &info);
> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
> index 200cea6e49e5..b91fa398b814 100644
> --- a/fs/btrfs/tree-log.c
> +++ b/fs/btrfs/tree-log.c
> @@ -6163,7 +6163,7 @@ static int log_delayed_deletions_incremental(struct btrfs_trans_handle *trans,
>   {
>   	struct btrfs_root *log = inode->root->log_root;
>   	const struct btrfs_delayed_item *curr;
> -	u64 last_range_start;
> +	u64 last_range_start = 0;
>   	u64 last_range_end = 0;
>   	struct btrfs_key key;
> 
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 83cb2db43779..1298569cf8b5 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -2595,7 +2595,7 @@ int btrfs_init_new_device(struct btrfs_fs_info *fs_info, const char *device_path
>   	struct block_device *bdev;
>   	struct super_block *sb = fs_info->sb;
>   	struct btrfs_fs_devices *fs_devices = fs_info->fs_devices;
> -	struct btrfs_fs_devices *seed_devices;
> +	struct btrfs_fs_devices *seed_devices = NULL;
>   	u64 orig_super_total_bytes;
>   	u64 orig_super_num_devices;
>   	int ret = 0;

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ