All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Liu <jeff.liu@oracle.com>
To: "Michael L. Semon" <mlsemon35@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: New xfstests generic/308 causes XFS hang (high CPU use), at least on 32-bit
Date: Fri, 12 Apr 2013 14:51:09 +0800	[thread overview]
Message-ID: <5167AEDD.2050708@oracle.com> (raw)
In-Reply-To: <51656D47.9010806@gmail.com>

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:
xfs_buffered_aio_write
  xfs_file_aio_write_checks
    generic_write_checks

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 generic_write_checks():
        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. */
#if BITS_PER_LONG==32
#define MAX_LFS_FILESIZE        (((loff_t)PAGE_CACHE_SIZE << (BITS_PER_LONG-1))-1) 

I'll try to fix it later.

Thanks,
-Jeff

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

      parent reply	other threads:[~2013-04-12  6:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10 13:46 New xfstests generic/308 causes XFS hang (high CPU use), at least on 32-bit Michael L. Semon
2013-04-10 14:06 ` Michael L. Semon
2013-04-10 14:18   ` Rich Johnston
2013-04-10 14:31     ` Michael L. Semon
2013-04-12  6:51 ` Jeff Liu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5167AEDD.2050708@oracle.com \
    --to=jeff.liu@oracle.com \
    --cc=mlsemon35@gmail.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.