lkml.org 
[lkml]   [2010]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ext4_lazyinit_thread: 'ret' may be used uninitialized in this function
    On Tue, 2 Nov 2010, kevin granade wrote:

    > On Tue, Nov 2, 2010 at 1:29 PM, Ted Ts'o <tytso@mit.edu> 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@mit.edu>
    > > 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@redhat.com>
    > >    Reported-by: "Stefan Richter" <stefanr@s5r6.in-berlin.de>
    > >    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
    > >
    > > 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@vger.kernel.org
    > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
    > > Please read the FAQ at  http://www.tux.org/lkml/
    >

    Thanks!

    -Lukas
    \
     
     \ /
      Last update: 2010-11-02 20:21    [W:0.056 / U:30.048 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site