linux-ext4 - xfstests test #74 failure

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-next>] [day] [month] [year] [list]

Message-ID: <20110828235437.GA12187@thunk.org>
Date:	Sun, 28 Aug 2011 19:54:37 -0400
From:	Ted Ts'o <tytso@....edu>
To:	linux-ext4@...r.kernel.org
Subject: xfstests test #74 failure

Has anyone else noticed failures with xfstests #74?  What I'm finding
is that if compile the fstest program so that it is statically linked,
I can't get it to fail:

candygram:~/xfstests# ldd /vdb/fstest.static 
		      not a dynamic executable

However ,if it is dynamically linked withthe system C library, it
works just fine:

candygram:~/xfstests# ldd /vdb/fstest.dyn
		      linux-gate.so.1 =>  (0xffffe000)
		      libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb765d000)
		      /lib/ld-linux.so.2 (0xb77bc000)

The failure case looks like this.  If it doesn't fail the first time,
it almost certainly will fail the second time the command is repeated.
(And when I run test #74, it usually fails during the 2nd fstest
invocation, which adds a -m option to command line below, but the -m
doesn't seem necessary to cause the failure; what seems to be
important is running fstest the second time.)

candygram:~/xfstests# /vdb/fstest.dyn -n 3 -F -l 10 -f 5 -s 31457280 -b 512 -p /vdb/fstest.2875.2
num_children=3 file_size=31457280 num_files=5 loop_count=10 block_size=512
mmap=0 sync=0 prealloc=0
Total data size 471.9 Mbyte
Child 2 cleaning /vdb/fstest.2875.2/child2
Child 1 cleaning /vdb/fstest.2875.2/child1
Child 0 cleaning /vdb/fstest.2875.2/child0
Child 1 loop 0
Child 0 loop 0
Child 2 loop 0
Child 0 loop 1
Child 1 loop 1
Child 2 loop 1
Corruption in child 0 fnum 3 at offset 22327432
Correct:   5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c 5c [ 1344.124844] fstest.dyn used greatest stack depth: 5436 bytes left
5c 5c 5c 
Incorrect: 07 f2 ba 78 49 d0 a3 18 bd e5 c7 02 28 99 c5 4c 07 f2 ba 78 Corruption length: 0

Child exited with status 1
Child 2 loop 2
Child 1 loop 2
Child 1 loop 3
Child 2 loop 3
Child 1 loop 4

The exact same command-line works fine if I use statically linked
binary (fstest.dyn).  It also seems to work fine if I double the
amount of memory in my VM (from 1024 to 2048 megs).  At this point I'm
not sure whether it's a bug in fstest, or in ext4.  It is reproducible with 4k block size, 1k
block size, 4k/nodelalloc/noextents, nojournal mode. 

I'm using the libc6 in Debian unstable, version 2.13-18, both when
compiling and the shared library runtime.

If it's an ext4 bug, it's not a recent regression; I can replicate
this with v3.1-rc3, v3.0, 2.6.39, and 2.6.38.  However, I can *not*
replicate this with ext3, so this smells like an ext4 bug.  I have
absolutely no idea why linking dynamically vs. statically would make a
difference, though....

					- Ted
--
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