linux-ext4 - probably bug in block allocator

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <6B41BA7B-1BF4-471E-AA3B-D4CEFB7335B8@gmail.com>
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