Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751255AbcCKJsV (ORCPT ); Fri, 11 Mar 2016 04:48:21 -0500 Received: from mx01-fr.bfs.de ([193.174.231.67]:51218 "EHLO mx01-fr.bfs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750744AbcCKJsO (ORCPT ); Fri, 11 Mar 2016 04:48:14 -0500 Message-ID: <56E2944E.3030204@bfs.de> Date: Fri, 11 Mar 2016 10:47:58 +0100 From: walter harms Reply-To: wharms@bfs.de User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.16) Gecko/20101125 SUSE/3.0.11 Thunderbird/3.0.11 MIME-Version: 1.0 To: Dan Carpenter CC: xlpang@redhat.com, Andrew Morton , Vivek Goyal , Dave Young , Ingo Molnar , Toshi Kani , Mimi Zohar , Minfei Huang , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Subject: Re: [patch] kexec: potetially using uninitialized variable References: <20160311080747.GA31887@mwanda> <56E2875B.8010909@redhat.com> <20160311091919.GD5273@mwanda> In-Reply-To: <20160311091919.GD5273@mwanda> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1490 Lines: 52 Am 11.03.2016 10:19, schrieb Dan Carpenter: > On Fri, Mar 11, 2016 at 04:52:43PM +0800, Xunlei Pang wrote: >> Hi Dan, >> >> On 2016/03/11 at 16:07, Dan Carpenter wrote: >>> At the end of the function we check if "ret" has a negative error code, >>> but it seems possible that it is uninitialized. >>> >>> Fixes: 12db5562e035 ('kexec: load and relocate purgatory at kernel load time') >>> Signed-off-by: Dan Carpenter >>> >>> diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c >>> index 503bc2d..63d1af3 100644 >>> --- a/kernel/kexec_file.c >>> +++ b/kernel/kexec_file.c >>> @@ -795,7 +795,7 @@ out: >>> >>> static int kexec_apply_relocations(struct kimage *image) >>> { >>> - int i, ret; >>> + int i, ret = 0; >>> struct purgatory_info *pi = &image->purgatory_info; >>> Elf_Shdr *sechdrs = pi->sechdrs; >>> >> >> Look further, there is a condition at the beginning of the for loop: >> >> >> if (sechdrs[i].sh_type != SHT_RELA && >> sechdrs[i].sh_type != SHT_REL) >> continue; >> >> So, I think that's ok, but I don't konw if GCC is smart enough not to throw warnings. > > Ah, right... > > This wasn't a GCC warning. GCC misses a lot of uninitialized variable > bugs so I'm doing this with Smatch. > > Anyway, I'll patch this up in Smatch to not warn about this. > I am not so sure about this. the point should be that the reviewer can read it easily not if gcc complains or not. just my 2 cents, re, wh