Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1355674 > unrolled thread

[patch] kexec: potetially using uninitialized variable

Started byDan Carpenter <dan.carpenter@oracle.com>
First post2016-03-11 09:10 +0100
Last post2016-03-14 12:30 +0100
Articles 7 — 4 participants

Back to article view | Back to linux.kernel

Contents

  [patch] kexec: potetially using uninitialized variable Dan Carpenter <dan.carpenter@oracle.com> - 2016-03-11 09:10 +0100
    Re: [patch] kexec: potetially using uninitialized variable Xunlei Pang <xpang@redhat.com> - 2016-03-11 10:00 +0100
      Re: [patch] kexec: potetially using uninitialized variable Dan Carpenter <dan.carpenter@oracle.com> - 2016-03-11 10:20 +0100
        Re: [patch] kexec: potetially using uninitialized variable walter harms <wharms@bfs.de> - 2016-03-11 10:50 +0100
          Re: [patch] kexec: potetially using uninitialized variable Minfei Huang <mnfhuang@gmail.com> - 2016-03-11 16:40 +0100
            Re: [patch] kexec: potetially using uninitialized variable Dan Carpenter <dan.carpenter@oracle.com> - 2016-03-14 12:00 +0100
              Re: [patch] kexec: potetially using uninitialized variable Minfei Huang <mnfhuang@gmail.com> - 2016-03-14 12:30 +0100

#1355674 — [patch] kexec: potetially using uninitialized variable

FromDan Carpenter <dan.carpenter@oracle.com>
Date2016-03-11 09:10 +0100
Subject[patch] kexec: potetially using uninitialized variable
Message-ID<rbqj0-3fw-3@gated-at.bofh.it>
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 <dan.carpenter@oracle.com>

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;

[toc] | [next] | [standalone]

#1355731

FromXunlei Pang <xpang@redhat.com>
Date2016-03-11 10:00 +0100
Message-ID<rbr5r-3zy-59@gated-at.bofh.it>
In reply to#1355674
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 <dan.carpenter@oracle.com>
>
> 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.

Regards,
Xunlei

[toc] | [prev] | [next] | [standalone]

#1355748

FromDan Carpenter <dan.carpenter@oracle.com>
Date2016-03-11 10:20 +0100
Message-ID<rbroJ-3VO-7@gated-at.bofh.it>
In reply to#1355731
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 <dan.carpenter@oracle.com>
> >
> > 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.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1355769

Fromwalter harms <wharms@bfs.de>
Date2016-03-11 10:50 +0100
Message-ID<rbrRN-489-13@gated-at.bofh.it>
In reply to#1355748

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 <dan.carpenter@oracle.com>
>>>
>>> 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

[toc] | [prev] | [next] | [standalone]

#1355983

FromMinfei Huang <mnfhuang@gmail.com>
Date2016-03-11 16:40 +0100
Message-ID<rbxkt-8dl-5@gated-at.bofh.it>
In reply to#1355769
On 03/11/16 at 10:47am, walter harms wrote:
> 
> 
> 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 <dan.carpenter@oracle.com>
> >>>
> >>> 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.

Hi, All.

I think we can modify the logic a bit to make code simple. Thus gcc will
not complain about any more, and the logic is earier.

Following is a draft patch.

diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index 007b791..7144e3b 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -887,7 +887,7 @@ static int kexec_apply_relocations(struct kimage *image)
 		if (sechdrs[i].sh_type == SHT_RELA)
 			ret = arch_kexec_apply_relocations_add(pi->ehdr,
 							       sechdrs, i);
-		else if (sechdrs[i].sh_type == SHT_REL)
+		else
 			ret = arch_kexec_apply_relocations(pi->ehdr,
 							   sechdrs, i);
 		if (ret)


> 
> just my 2 cents,
> 
> re,
>  wh
> 
>

[toc] | [prev] | [next] | [standalone]

#1357153

FromDan Carpenter <dan.carpenter@oracle.com>
Date2016-03-14 12:00 +0100
Message-ID<rcyoa-2Ex-19@gated-at.bofh.it>
In reply to#1355983
On Fri, Mar 11, 2016 at 11:38:19PM +0800, Minfei Huang wrote:
> I think we can modify the logic a bit to make code simple. Thus gcc will
> not complain about any more, and the logic is earier.

This is a Smatch warning, not a GCC warning.  If you think the new code
is clearer, that's fine but don't just silence the warning to please
Smatch.  I'm pretty sure I can silence this warning in Smatch.

regards,
dan carpenter

[toc] | [prev] | [next] | [standalone]

#1357168

FromMinfei Huang <mnfhuang@gmail.com>
Date2016-03-14 12:30 +0100
Message-ID<rcyRc-35C-3@gated-at.bofh.it>
In reply to#1357153
On 03/14/16 at 01:58pm, Dan Carpenter wrote:
> On Fri, Mar 11, 2016 at 11:38:19PM +0800, Minfei Huang wrote:
> > I think we can modify the logic a bit to make code simple. Thus gcc will
> > not complain about any more, and the logic is earier.
> 
> This is a Smatch warning, not a GCC warning.  If you think the new code
> is clearer, that's fine but don't just silence the warning to please
> Smatch.  I'm pretty sure I can silence this warning in Smatch.
> 
> regards,
> dan carpenter
> 

Hi, Dan.

If not a GCC warning, I'm fine to fix it in Smatch, since the code logic
is clear enough.

Thanks
Minfei

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web