| Message ID | 20201030114620.GB3251003@mwanda |
|---|---|
| State | Awaiting Upstream |
| Headers | show |
| Series | ext4: silence an uninitialized variable warning | expand |
On Fri, Oct 30, 2020 at 02:46:20PM +0300, Dan Carpenter wrote: > Smatch complains that "i" can be uninitialized if we don't enter the > loop. I don't know if it's possible but we may as well silence this > warning. Thanks, applied. I changed the patch so that i gets initialized to sb->s_blocksize instead of 0. The only way the for loop could be skipped entirely, leaving i initialized, is if the in-memory data structures, in particular the bh->b_data for the on-disk superblock has gotten corrupted enough that calculated value of group is >= to ext4_get_groups_count(sb). In that case, we want to exit immediately without allocating a block, and if i is left to sb->s_blocksize, that will cause the function to bail out right after the skipped for loop. - Ted
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index 85abbfb98cbe..9e8faf851c59 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -5167,7 +5167,7 @@ static ext4_fsblk_t ext4_mb_new_blocks_simple(handle_t *handle, struct super_block *sb = ar->inode->i_sb; ext4_group_t group; ext4_grpblk_t blkoff; - int i; + int i = 0; ext4_fsblk_t goal, block; struct ext4_super_block *es = EXT4_SB(sb)->s_es;
Smatch complains that "i" can be uninitialized if we don't enter the loop. I don't know if it's possible but we may as well silence this warning. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> --- fs/ext4/mballoc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)