[Top] [All Lists]

Re: New xfstests generic/308 causes XFS hang (high CPU use), at least on

To: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Subject: Re: New xfstests generic/308 causes XFS hang (high CPU use), at least on 32-bit
From: Jeff Liu <jeff.liu@xxxxxxxxxx>
Date: Fri, 12 Apr 2013 14:51:09 +0800
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <51656D47.9010806@xxxxxxxxx>
References: <51656D47.9010806@xxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
Hi Michael,

On 04/10/2013 09:46 PM, Michael L. Semon wrote:
> Hi!  On my 32-bit Pentium III PC, xfstests generic/308 uses xfs_io, and 
> that xfs_io hangs the XFS file system without causing a crash.  In other 
> words, the FS cannot be umounted, xfs_io can't be killed, and shutdown 
> is handled by magic SysRq keys.  In this time, there is about 90% CPU 
> usage from xfs_io (top) but zero disk I/O (iostat).
> The PC uses kernel 3.8-rc4 + Dave's CRC v4 patches + J. Liu's bitness patch.
I think this is a bug for x86 only and it is irrelevant to above patches(You 
have also
mentioned in another email).

AFAICS, it is caused by the 2nd test case in 308, i.e.
# Write to the block after the extent just created
offset=$(((2**32 - 1) * $block_size))
$XFS_IO_PROG -f -c "pwrite $offset $block_size" -c fsync $testfile 
>>$seqres.full 2>&1

Run xfs_io with the given huge offset is enough to reproduce this issue(don't 
need to specify
the 'fsync' option), it will hang at page write back stage soon.

As we performs buffered io writes, the code execute path should go through:

In this case, the given offset is larger than s_maxbytes on 32-bit machine. I 
think we should not be
allowed to create this file at all according to the following check up at 
        if (likely(!isblk)) {
                if (unlikely(*pos >= inode->i_sb->s_maxbytes)) {
                        if (*count || *pos > inode->i_sb->s_maxbytes) {
                                return -EFBIG;
                        /* zero-length writes at ->s_maxbytes are OK */

However, at xfs_max_file_offset(), we figure out s_maxbytes to (__uint64_t) 
range, it violated the MAX_LFS_FILESIZE limits,
so the file can be created but will failed at page write back phase after a 
little while, just like the comments for MAX_LFS_FILESIZE:

/* Page cache limit. The filesystems should put that into their s_maxbytes 
   limits, otherwise bad things can happen in VM. */
#define MAX_LFS_FILESIZE        (((loff_t)PAGE_CACHE_SIZE << 

I'll try to fix it later.


<Prev in Thread] Current Thread [Next in Thread>