xfs
[Top] [All Lists]

Re: [PATCH v3 xfstests] add tests for unlinking directories with hash co

To: Hannes Frederic Sowa <hannes@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH v3 xfstests] add tests for unlinking directories with hash collisions
From: Mark Tinguely <tinguely@xxxxxxx>
Date: Wed, 02 Apr 2014 08:07:41 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140402123442.GF16157@xxxxxxxxxxxxxxxxxxxxxxxxx>
References: <20140327074156.GJ29498@xxxxxxxxxxxxxxxxxxxxxxxxx> <20140401184903.GA13434@xxxxxxxxxxxxxxxxxxxxxxxxx> <20140401230309.GC16157@xxxxxxxxxxxxxxxxxxxxxxxxx> <20140402123442.GF16157@xxxxxxxxxxxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120122 Thunderbird/9.0
On 04/02/14 07:34, Hannes Frederic Sowa wrote:
This tests creates several directories that have the same small (8)
group of hashes to ensure the hash ordering of file and directories
are preserved.

Sample backtrace this test tries to prevent in future:

[ 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)

With help from Mark Tinguely, thanks very much!

Cc: Dave Chinner<david@xxxxxxxxxxxxx>
Cc: Mark Tinguely<tinguely@xxxxxxx>
Signed-off-by: Hannes Frederic Sowa<hannes@xxxxxxxxxxxxxxxxxxx>
---
Changelog:

v2)
* first serious proposal

v3)
* reduced number of possible generated hashes to 8 and thus lowered the number 
of
   generated files to 10_000 which still generate the corruption in all of my
   10 tests. This speeds up the test considerable. Maybe we can add
   quick to the group description now?
* updated changelog

Also:
When testing this program with reduced number of generated hashes and
huge amount of test files, xfs_repair needs a considerable amount of
time to check the directory (I aborted it). I guess this is because the
hash tables get flattened to linked lists.

I don't know if there are other runtime explosions in other parts of
the code (maybe in the kernel).  I suggest to add a random perturbation
to the hash function, which unluckily seems to be included into the
superblock then, too.

Please have a look!

Thanks,

   Hannes

Tested-by: Mark Tinguely <tinguely@xxxxxxx>

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