[Pkg-vsquare-devel] Bug#776248: fuseext2: CPU at 100% when mounting ext4 fs with block size > 4K

[Christoph Biedl]

severity 776248 important
thanks

Jaroslav Mikulík wrote...

> Filesystem is mounted without errors, but when any operation (i.e. ls -l) on
> mount point cause 100% of 1 CPU core and there is no expected output from
> operation.

At first, here are two simpler reproducers:

    fallocate --length 1M /tmp/ext4-reprod.img
    mkfs.ext4 -g 256 /tmp/ext4-reprod.img 
    fuseext2 /tmp/ext4-reprod.img /tmp/mountpoint

Or even simpler: Any image as long as it's bigger than 32 Mibyte (take
or give a few):

    fallocate --length 32M /tmp/ext4-reprod.img
    mkfs.ext4 /tmp/ext4-reprod.img 

Running "ls" still works, but midnight commander on the mountpoint
results in the behaviour described before (tested on amd64).

This is not a result of the block size per se but roughly on the "Block
count" to "Blocks per group" ratio (use tune2fs -l to see the actual
values). If it exceeds the value of 2, you're in trouble. In your
example, it is 256.

The bug is in test_root in op_statfs.c as called by ext2_group_spare.
It's called several times with 3, 5, 7 as b, and a for all numbers
from two up to the value mentioned above (s_groups_count, computed in
line 85). Or not at all if that value is just zero or one.

However, test_root is never left if called with (2, 3), or any other
(a, b) where a < b. Integer wraparound might end the loop but that's
undefined behaviour, and gcc optimizes it into an endless loop
instead, on amd64:

  4053a5:       83 ff 02                cmp    $0x2,%edi
  4053a8:       75 06                   jne    4053b0 <ext2_group_spare+0x10>
  4053aa:       eb fe                   jmp    4053aa <ext2_group_spare+0xa>

Note the compiler inlined test_root into ext2_group_spare, thus had
additional information for optimization at hand. You can unbreak the
code by adding a debug print statement into test_root, but this just
hides the underlying problem.

No idea how to fix this since I have no clue what the code is supposed
to do.

Severity raised so a fix might be delivered through a stable point
release. In my personal opinion it should be even higher since today's
ext filesystems are usually ext4 and larger that 32 Mibytes. For all
these, the package is completely unusable.


Aside, the ext2_bg_num_gdb invocation (and other) casts "unsigned long
long" into "int". This gives my quite a bad feeling.

    Christoph
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-vsquare-devel/attachments/20151125/03a84687/attachment.sig>