linux-ext4 - Re: [ext4:dev 16/18] fs/ext4/extents.c:3299:21: warning: 'abut_ex' may be used uninitialized in this function

Open Source and information security mailing list archives

Date:	Thu, 4 Apr 2013 10:48:51 +0200 (CEST)
From:	Lukáš Czerner <lczerner@...hat.com>
To:	kbuild test robot <fengguang.wu@...el.com>
cc:	Lukas Czerner <lczerner@...hat.com>,
	"Theodore Ts'o" <tytso@....edu>, kbuild-all@...org,
	linux-ext4@...r.kernel.org
Subject: Re: [ext4:dev 16/18] fs/ext4/extents.c:3299:21: warning: 'abut_ex'
 may be used uninitialized in this function

On Thu, 4 Apr 2013, kbuild test robot wrote:

> Date: Thu, 04 Apr 2013 12:28:29 +0800
> From: kbuild test robot <fengguang.wu@...el.com>
> To: Lukas Czerner <lczerner@...hat.com>
> Cc: Theodore Ts'o <tytso@....edu>, kbuild-all@...org
> Subject: [ext4:dev 16/18] fs/ext4/extents.c:3299:21: warning: 'abut_ex' may be
>      used uninitialized in this function
> 
> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
> head:   f78ee70db40040e6f38a5134527d4760254d6683
> commit: bc2d9db48c95ec6c9c5ecc97ddc61343d751f219 [16/18] ext4: Transfer initialized block to right neighbor if possible
> config: i386-randconfig-x005-0404 (attached as .config)
> 
> Note: it may well be a FALSE warning. FWIW you are at least aware of it now.

This one is false warning, because we only have allocated set if
abut_ex is initialized as well. But I wonder if it's worth to
silence the warning just by initializing abut_ex to NULL ?

Thanks!
-Lukas

> 
> All warnings:
> 
>    fs/ext4/extents.c: In function 'ext4_ext_map_blocks':
> >> fs/ext4/extents.c:3299:21: warning: 'abut_ex' may be used uninitialized in this function [-Wmaybe-uninitialized]
>    fs/ext4/extents.c:3156:27: note: 'abut_ex' was declared here
> 
> vim +/abut_ex +3299 fs/ext4/extents.c
> 
>   3283				ext4_ext_store_pblock(abut_ex, next_pblk - map_len);
>   3284				ex->ee_len = cpu_to_le16(ee_len - map_len);
>   3285				ext4_ext_mark_uninitialized(ex); /* Restore the flag */
>   3286	
>   3287				/* Extend abut_ex by 'map_len' blocks */
>   3288				abut_ex->ee_len = cpu_to_le16(next_len + map_len);
>   3289	
>   3290				/* Result: number of initialized blocks past m_lblk */
>   3291				allocated = map_len;
>   3292			}
>   3293		}
>   3294		if (allocated) {
>   3295			/* Mark the block containing both extents as dirty */
>   3296			ext4_ext_dirty(handle, inode, path + depth);
>   3297	
>   3298			/* Update path to point to the right extent */
> > 3299			path[depth].p_ext = abut_ex;
>   3300			goto out;
>   3301		} else
>   3302			allocated = ee_len - (map->m_lblk - ee_block);
>   3303	
>   3304		WARN_ON(map->m_lblk < ee_block);
>   3305		/*
>   3306		 * It is safe to convert extent to initialized via explicit
>   3307		 * zeroout only if extent is fully insde i_size or new_size.
> 
> ---
> 0-DAY kernel build testing backend              Open Source Technology Center
> http://lists.01.org/mailman/listinfo/kbuild                 Intel Corporation
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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