panic, seems related to r234386
pfg at FreeBSD.org
Wed May 16 15:58:11 UTC 2012
On 05/12/12 17:49, Mateusz Guzik wrote:
>>>> Gave this a spin and found what looks like a deadlock:
>>>> Not a new problem, it would seem. Same issue with 8.3-PRERELEASE r232656M.
>>> pid 2680 (fts) holds lock for vnode cb4be414 and tries to lock cc0ac15c
>>> pid 2581 (openat) holds lock for vnode cc0ac15c and tries to lock cb4be414
>>> openat calls rmdir foo/bar and ext2_rmdir unlocks and tries to lock
>>> again foo's vnode.
>>> This is fairly easly reproducible with concurrently running mkdir and fts
>>> testcase programs that are provided by stress2.
>>> I'll try to come up with a patch by the end of the week.
> Easier way to reproduce: mkdir from stress2 and "while true; do find /mnt>
> /dev/null; done" on another terminal.
> Assuming foo/bar directory tree, deadlock happens during removal of bar
> with simultaneous lookup of .. in bar.
> Proposed trivial patch:
> If the lock cannot be acquired immediately unlocks 'bar' vnode and then
> locks both vnodes in order.
> After patching this I ran into another issue - wrong vnode type panics
> from cache_enter_time after calls by ext2_lookup. (It takes some time to
> reproduce this, testcase as before.)
> It looks like ext2_lookup is actually adapted version of ufs_lookup and
> lacks some bugfixes present in current ufs_lookup. I believe those
> bugfixes address this bug.
> Here is my attempt to fix the problem (based on ufs_lookup changes):
It is indeed extremely useful that UFS and ext2fs are so similar.
The two bugfixes were committed as revision 235508, thanks!
More information about the freebsd-current