linux-ext4 - "make check" broken on maint branch?

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]

Date:	Thu, 31 Oct 2013 21:35:25 +0000
From:	"Dilger, Andreas" <andreas.dilger@...el.com>
To:	"tytso@....edu" <tytso@....edu>
CC:	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: "make check" broken on maint branch?

It seems that the current e2fsprogs "maint" branch has broken tests?
At least on two different systems I tried this on had the same problem:

  r_64bit_big_expand: very large fs growth using ext4 w/64bit: failed
  r_bigalloc_big_expand: ext4 with bigalloc: failed
  r_ext4_big_expand: very large fs growth using ext4: failed

The test logs show:

  /tmp/e2fsprogs-tmp.VitAZy: 13/32768 files (7.7% non-contiguous),
6870/131072 blocks
  ../resize/resize2fs -d 31 /tmp/e2fsprogs-tmp.VitAZy 2T
  resize2fs 1.42.8 (20-Jun-2013)
  The containing partition (or device) is only 131072 (4k) blocks.
  You requested a new size of 536870912 blocks.

I tried to add in a "truncate -s $SIZE_2 $TMPFILE", but it complains that
it
isn't able to truncate the file in /tmp to 2TB:

  truncating `/tmp/e2fsprogs-tmp.OGxb09' at 2199023255552 bytes: File too
large

Testing manually, it seems I'm not allowed to create a file in tmpfs larger
than 256GB.  How large does this file need to be for this test to be valid?

I'm also seeing a consistent test failure in f_extent_oobounds on ONE of
the
two systems, though I can't see why the results are inconsistent since they
have the same GCC, glibc and almost the same kernel (RHEL
2.6.32-358.11.1.el6
and 2.6.32-279.5.1.el6, not that it should make any difference).

  more f_extent*.failed
  --- f_extent_oobounds/expect.1  2013-10-31 20:01:06.299616314 +0000
  +++ f_extent_oobounds.1.log     2013-10-31 21:16:21.008616804 +0000
  @@ -1,24 +1,20 @@
   Pass 1: Checking inodes, blocks, and sizes
  -Inode 12, end of extent exceeds allowed value
  -       (logical block 15, physical block 200, len 30)
  -Clear? yes
  -
  -Inode 12, i_blocks is 154, should be 94.  Fix? yes
  +Inode 12, i_blocks is 154, should be 0.  Fix? yes

This is still true after "make distclean" and rebuilding the whole tree.
It seems that e2fsck isn't detecting the new PR_1_EXTENT_END_OUT_OF_BOUNDS
problem on this system for some reason?  Usually this kind of inconsistency
is due to some uninitialized stack variable being used that is different
on the two systems.

Anyone else seen these problems, or do I need to dig in further?

Cheers, Andreas
-- 
Andreas Dilger

Lustre Software Architect
Intel High Performance Data Division

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