lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 2 Nov 2010 13:46:23 -0500
From:	kevin granade <kevin.granade@...il.com>
To:	"Ted Ts'o" <tytso@....edu>, Lukas Czerner <lczerner@...hat.com>,
	Stefan Richter <stefanr@...6.in-berlin.de>,
	linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: ext4_lazyinit_thread: 'ret' may be used uninitialized in this function

On Tue, Nov 2, 2010 at 1:29 PM, Ted Ts'o <tytso@....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@....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@...hat.com>
>    Reported-by: "Stefan Richter" <stefanr@...6.in-berlin.de>
>    Signed-off-by: "Theodore Ts'o" <tytso@....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

> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ