lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Mon, 12 Feb 2018 09:14:33 +0300
From:   Alexey Lyashkov <alexey.lyashkov@...il.com>
To:     Ts'o Theodore <tytso@....edu>
Cc:     linux-ext4 <linux-ext4@...r.kernel.org>
Subject: probably bug in block allocator

Hi ext4 developers,

I looked into problem with long time allocations with large FS and found a some strange in
commit
commit 40ae3487628235e5f1eb27542cca0cdb6e5dbe16
Author: Theodore Ts'o <tytso@....edu>
Date:   Mon Feb 4 15:08:40 2013 -0500

    ext4: optimize mballoc for large allocations
..
it have a chunk
@@ -1884,15 +1884,19 @@ static int ext4_mb_good_group(struct ext4_allocation_context *ac,
        case 0:
                BUG_ON(ac->ac_2order == 0);

-               if (grp->bb_largest_free_order < ac->ac_2order)
-                       return 0;
-
                /* Avoid using the first bg of a flexgroup for data files */
                if ((ac->ac_flags & EXT4_MB_HINT_DATA) &&
                    (flex_size >= EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME) &&
                    ((group % flex_size) == 0))
                        return 0;

+               if ((ac->ac_2order > ac->ac_sb->s_blocksize_bits+1) ||
+                   (free / fragments) >= ac->ac_g_ex.fe_len) <<<< (0)
+                       return 1;
+
+               if (grp->bb_largest_free_order < ac->ac_2order)
+                       return 0;
+
                return 1;
        case 1:
                if ((free / fragments) >= ac->ac_g_ex.fe_len) (1)


..
ac_g_ex isn’t changed between loops, free/fragments is also don’t changed.

i this case loop(1) is useless as same condition as used in loop (0), but it’s will eats a some time with large number a group.
In this case - i think loop(1) can be cut and save a some time with scanning a groups.

Theo, what you think about that change ?


Alex


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ