Re: ext4_lazyinit_thread: 'ret' may be used uninitialized in thisfunction
From: Lukas Czerner
Date: Tue Nov 02 2010 - 15:19:31 EST
On Tue, 2 Nov 2010, kevin granade wrote:
> On Tue, Nov 2, 2010 at 1:29 PM, Ted Ts'o <tytso@xxxxxxx> wrote:
> >
> > On Mon, Nov 01, 2010 at 04:27:26PM +0100, Lukas Czerner wrote:
> > >
> > > thank you for noticing this, because I actually do not see the warning
> > > (I wonder why...), but it is definitely a bug, so the trivial patch below
> > > should fix that.
> >
> > This is a slightly less trivial fix that eliminates the need for the
> > "ret" variable entirely.
> >
> > - Ted
> >
> > commit e048924538f0c62d18306e2fea0e22dac0140f6e
> > Author: Theodore Ts'o <tytso@xxxxxxx>
> > Date: Tue Nov 2 14:19:30 2010 -0400
> >
> > ext4: "ret" may be used uninitialized in ext4_lazyinit_thread()
> >
> > Newer GCC's reported the following build warning:
> >
> > fs/ext4/super.c: In function 'ext4_lazyinit_thread':
> > fs/ext4/super.c:2702: warning: 'ret' may be used uninitialized in this function
> >
> > Fix it by removing the need for the ret variable in the first place.
> >
> > Signed-off-by: "Lukas Czerner" <lczerner@xxxxxxxxxx>
> > Reported-by: "Stefan Richter" <stefanr@xxxxxxxxxxxxxxxxx>
> > Signed-off-by: "Theodore Ts'o" <tytso@xxxxxxx>
> >
> > diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> > index 8d1d942..4d7ef31 100644
> > --- a/fs/ext4/super.c
> > +++ b/fs/ext4/super.c
> > @@ -2699,7 +2699,6 @@ static int ext4_lazyinit_thread(void *arg)
> > struct ext4_li_request *elr;
> > unsigned long next_wakeup;
> > DEFINE_WAIT(wait);
> > - int ret;
> >
> > BUG_ON(NULL == eli);
> >
> > @@ -2723,13 +2722,12 @@ cont_thread:
> > elr = list_entry(pos, struct ext4_li_request,
> > lr_request);
> >
> > - if (time_after_eq(jiffies, elr->lr_next_sched))
> > - ret = ext4_run_li_request(elr);
> > -
> > - if (ret) {
> > - ret = 0;
> > - ext4_remove_li_request(elr);
> > - continue;
> > + if (time_after_eq(jiffies, elr->lr_next_sched)) {
> > + if (ext4_run_li_request(elr) != 0) {
> > + /* error, remove the lazy_init job */
> > + ext4_remove_li_request(elr);
> > + continue;
> > + }
> > }
> >
> > if (time_before(elr->lr_next_sched, next_wakeup))
>
> What do you think about this option for the second hunk? (not anything-tested)
>
> @@ -2723,13 +2722,11 @@ cont_thread:
> elr = list_entry(pos, struct ext4_li_request,
> lr_request);
> - if (time_after_eq(jiffies, elr->lr_next_sched))
> - ret = ext4_run_li_request(elr);
> -
> - if (ret) {
> - ret = 0;
> - ext4_remove_li_request(elr);
> - continue;
> + if (time_after_eq(jiffies, elr->lr_next_sched) &&
> + ext4_run_li_request(elr) != 0) {
> + /* error, remove the lazy_init job */
> + ext4_remove_li_request(elr);
> + continue;
> }
>
> if (time_before(elr->lr_next_sched, next_wakeup))
> --
>
> Though obviously it's a pretty subjective style issue.
> Kevin Granade
Hmm this relies on the fact that if the first part of the condition
would not be true, the second part (after and) would never be invoked,
however I am not really sure that we can rely on that on every
architecture, or can we ?
>
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
>
Thanks!
-Lukas