xfstests, bad generic tests 009 and 308

[Dave Chinner]

On Fri, Sep 18, 2015 at 06:38:38PM +0200, Angelo Dureghello wrote:
> Hi all,
> 
> working on arm (32bit arch), kernel 4.1.6.

Is this a new platform?

Also, we need to know what compiler you are using, because we know
that certain versions of gcc miscompile XFS kernel code on arm
(4.6, 4.7 and certain versions of 4.8 are suspect) due to a
combination of compiler mis-optimisations and kernel bugs in the
arm 64 bit division asm implementation.

As such, it would be worthwhile trying gcc-4.9 and a 4.3-rc1 kernel
to see if the problems still occur.

> Looking to find the reason of some bad results on xfstests,
> 
> -tests/generic/009
> ------------------
> i get several "all holes" messages
> 
> generic/009    [  842.949643] run fstests generic/009 at 2015-09-18
> 15:29:36
>  - output mismatch (see
> /home/angelo/xfstests/results//generic/009.out.bad)
>     --- tests/generic/009.out    2015-09-17 10:54:06.689071257 +0000
>     +++ /home/angelo/xfstests/results//generic/009.out.bad
> 2015-09-18 15:29:41.412784177 +0000
>     @@ -1,79 +1,45 @@
>      QA output created by 009
>          1. into a hole
>     -0: [0..7]: hole
>     -1: [8..23]: unwritten
>     -2: [24..39]: hole
>     +0: [0..39]: hole
>      daa100df6e6711906b61c9ab5aa16032
> 
> also some other tests are giving the same bad notices.

Can you attach the entire
/home/angelo/xfstests/results//generic/009.out.bad file? I'm not
sure which of the tests this output comes from, so I need to
confirm which specific operations are resulting in errors.

> -tests/generic/308
> ------------------
> 
> I have now: CONFIG_LBDAF=y
> 
> In my target device this test creates a 16 Terabytes file 308.tempfile
> 
> -rw------- 1 root root  17592186044415 Sep 18 09:40 testfile.308
> 
> While "df" is not complaining about:
> 
> /dev/mmcblk0p5   8378368   45252   8333116   1% /media/p5
> 
> and next rm -f on it hands the cpu to 95%, forever.
> 
> This issue seems known from a long time, as it has been discussed in
> the thread:
> 
> http://oss.sgi.com/archives/xfs/2013-04/msg00273.html
> 
> I was wondering if there was any special reason why the Jeff patch has
> never been finally applied.

MAX_LFS_FILESIZE on 32 bits is 8TB, whereas xfs supports 16TB file
size on 32 bit systems. The specific issue this test fixed was
committed in commit 8695d27 ("xfs: fix infinite loop at
xfs_vm_writepage on 32bit system")

http://oss.sgi.com/archives/xfs/2014-05/msg00447.html

And, as you may notice now, generic/308 is the test case for the
exact problem the above commit fixed. 

Can you find out exactly where the CPU is looping? sysrq-l will
help, as will running 'perf top -U -g' to show you the hot code
paths, and so on.

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com