public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: "Roger Willcocks" <roger@filmlight.ltd.uk>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: xfstests testcase 111: Infinite xfs_bulkstat bad-inode loop casefrom Roger Willcocks
Date: Mon, 22 Dec 2008 20:28:59 -0000	[thread overview]
Message-ID: <C73606AC84514BE3B733F818ACCD281B@BODDINGTON> (raw)
In-Reply-To: 20081222165848.GA17075@infradead.org

> Hi Roger,
>
> I believe the xfstests case 111 is based on a report by you.  Do you
> remember what was going on there?  From a look at the testcase it
> overwrites an inode cluster and then tries to bulkstat them.  This works
> fine with a non-debug kernel, but due to debug kernels panicing it fails
> there.
>
> Do you remember what the testcase was looking for?  I suspect we should
> just not run it for debug kernels, but I'd like to know more about it
> so we can add comments describing it.
>
> Cheers,
> Christoph
>

Hi Christoph,

here are the relevant extracts from our in-house bugzilla (bug 3675). Since 
the problem only occurs when the disk is corrupted, I don't see any problem 
with skipping the test on debug kernels.

** 2006-02-01

xfs_fsr can get into a state where one processor spends 100% of its time
looping in the kernel. The application can't be killed. 'top' shows it using
50% CPU (i.e. all of one of the two processors).

oprofile reveals that one processor spends about 2/3 of its time in xfs.ko. 
It
looks like the offending syscall is xfs_bulkstat.

** 2006-02-03

Looks like xfs_itobp (map inode number to disk buffer) detects a corrupted
inode (bad magic number). That causes a break out of a loop in xfs_bulkstat,
skipping setting the teminating condition of a containing loop.

I'll file a bug report with SGI.

** 2006-02-03

SGI say 'Ayup, I think you're right'-

http://marc.theaimsgroup.com/?t=113889680200006

** 2006-02-07

A bad inode magic number can cause the xfs_bulkstat syscall to get stuck
looping in the kernel.

To reproduce: (don't try this at home folks!) -

mkfs.xfs /dev/sda
mount filesystem and create 1000 or so files (I copied a handy 313-byte 
file).
run this program:

---------
#include <sys/types.h>
#include <unistd.h>
#include <fcntl.h>

char buffer[32768];

void nuke()
{
        int i;
        for (i = 2048; i < 32768-1; i++)
                if (buffer[i] == 'I' && buffer[i+1] == 'N')
                        buffer[i] = buffer[i+1] = 'X';
}


                                      int main(int argc, char* argv[])
{
        int f = open("/dev/sda", O_RDWR);
        if (lseek(f, 32768, SEEK_SET) < 0) perror("lseek");
        if (read(f, buffer, 32768) != 32768) perror("read");
        nuke();
        if (lseek(f, 32768, SEEK_SET) < 0) perror("lseek");
        if (write(f, buffer, 32768) != 32768) perror("write");
        close(f);
}
---------

mount the disk and run xfs_fsr. It immediately gets stuck in a kernel loop.

** 2006-02-08

SGI have added a corresponding regression test to the xfs_cmds package

http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/111?rev=1.1

--
Roger

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

  reply	other threads:[~2008-12-22 20:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-22 16:58 xfstests testcase 111: Infinite xfs_bulkstat bad-inode loop case from Roger Willcocks Christoph Hellwig
2008-12-22 20:28 ` Roger Willcocks [this message]
2008-12-22 20:50   ` xfstests testcase 111: Infinite xfs_bulkstat bad-inode loop casefrom " Christoph Hellwig

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=C73606AC84514BE3B733F818ACCD281B@BODDINGTON \
    --to=roger@filmlight.ltd.uk \
    --cc=hch@infradead.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox