All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Tinguely <tinguely@sgi.com>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: xfs@oss.sgi.com
Subject: Re: xfs errors while unlinking filenames with hash collisions
Date: Thu, 27 Mar 2014 08:14:06 -0500	[thread overview]
Message-ID: <5334241E.9060708@sgi.com> (raw)
In-Reply-To: <20140327074156.GJ29498@order.stressinduktion.org>

On 03/27/14 02:41, Hannes Frederic Sowa wrote:
> Hello!
>
> I wanted to break some network stack hashing, but while running the test
> against my local xfs filesystem I got corruptions in rmdir:
>
> [ 3856.245843] XFS (vda1): Internal error xfs_trans_cancel at line 966 of file fs/xfs/xfs_trans.c.  Caller 0xffffffffa01186bc
> [ 3856.249049] CPU: 1 PID: 866 Comm: rm Not tainted 3.13.6-200.fc20.x86_64 #1
> [ 3856.250966] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 3856.252615]  000000000000000c ffff8800d23a7d68 ffffffff8168730c ffff8800cf5462b8
> [ 3856.254823]  ffff8800d23a7d80 ffffffffa00d00cb ffffffffa01186bc ffff8800d23a7da8
> [ 3856.257241]  ffffffffa00e5459 ffff8800d9ac3400 ffff8800d23a7e30 ffff8800371b6800
> [ 3856.259420] Call Trace:
> [ 3856.260172]  [<ffffffff8168730c>] dump_stack+0x45/0x56
> [ 3856.261717]  [<ffffffffa00d00cb>] xfs_error_report+0x3b/0x40 [xfs]
> [ 3856.263472]  [<ffffffffa01186bc>] ? xfs_remove+0x1ac/0x370 [xfs]
> [ 3856.270838]  [<ffffffffa00e5459>] xfs_trans_cancel+0xd9/0x100 [xfs]
> [ 3856.272783]  [<ffffffffa01186bc>] xfs_remove+0x1ac/0x370 [xfs]
> [ 3856.274531]  [<ffffffffa00db40b>] xfs_vn_unlink+0x4b/0x90 [xfs]
> [ 3856.276286]  [<ffffffff811c61b8>] vfs_rmdir+0xa8/0x100
> [ 3856.277821]  [<ffffffff811c638d>] do_rmdir+0x17d/0x1d0
> [ 3856.281021]  [<ffffffff811ba7fe>] ? ____fput+0xe/0x10
> [ 3856.285261]  [<ffffffff8108c11c>] ? task_work_run+0xac/0xe0
> [ 3856.286952]  [<ffffffff81013a31>] ? do_notify_resume+0x61/0xa0
> [ 3856.288693]  [<ffffffff811c9a65>] SyS_unlinkat+0x25/0x40
> [ 3856.290407]  [<ffffffff816962e9>] system_call_fastpath+0x16/0x1b
> [ 3856.292685] XFS (vda1): xfs_do_force_shutdown(0x8) called from line 967 of file fs/xfs/xfs_trans.c.  Return address = 0xffffffffa00e5472
> [ 3856.627330] XFS (vda1): Corruption of in-memory data detected.  Shutting down filesystem
> [ 3856.627332] XFS (vda1): Please umount the filesystem and rectify the problem(s)
>
> I also tested this on a current linux net-next kernel, which is 3.14.0-rc6.
>
> If I run the test code below in an directory for a while and after that
> try to unlink the files in it (rm -rf testdir), I get above splat. Even
> after running xfs_repair I cannot remove the directory. The system is
> pretty unusable after that if this is done on a root filesystem.
>
> I quickly extracted this simple test case below. It does not generate
> perfect collisions, but they are enough to trigger the above described
> problem.
>
> Thanks,
>
>    Hannes
>

Have you tried to run a xfs_repair on the filesystem after the reboot?

Do you fill the filesystem with the test or just part way?

--Mark.

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

  reply	other threads:[~2014-03-27 13:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27  7:41 xfs errors while unlinking filenames with hash collisions Hannes Frederic Sowa
2014-03-27 13:14 ` Mark Tinguely [this message]
2014-03-27 13:23   ` Hannes Frederic Sowa
2014-03-27 13:34     ` Mark Tinguely
2014-03-27 14:05       ` Hannes Frederic Sowa
2014-03-27 15:15         ` Mark Tinguely
2014-03-27 15:24           ` Hannes Frederic Sowa
2014-03-27 20:36             ` Mark Tinguely
2014-03-27 20:57             ` Mark Tinguely
2014-03-27 21:15               ` Hannes Frederic Sowa
2014-03-27 21:20                 ` Mark Tinguely
2014-04-01 18:49 ` [PATCH xfstests] tests for file hash collisions on xfs filesystems Hannes Frederic Sowa
2014-04-01 18:56   ` Mark Tinguely
2014-04-01 23:03   ` [PATCH v2 xfstests] add tests for unlinking directories with hash collisions Hannes Frederic Sowa
2014-04-02 12:34     ` [PATCH v3 " Hannes Frederic Sowa
2014-04-02 13:07       ` Mark Tinguely

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=5334241E.9060708@sgi.com \
    --to=tinguely@sgi.com \
    --cc=hannes@stressinduktion.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 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.