linux-ext4 - Re: "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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 1 Nov 2013 10:35:56 +0800
From:	Zheng Liu <gnehzuil.liu@...il.com>
To:	"Dilger, Andreas" <andreas.dilger@...el.com>
Cc:	"tytso@....edu" <tytso@....edu>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: "make check" broken on maint branch?

Hi Andreas,

On Thu, Oct 31, 2013 at 09:35:25PM +0000, Dilger, Andreas wrote:
> 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?

Yes, I also can see these problems.

Thanks,
                                                - Zheng
--
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