Hello;
On 05/12/12 17:49, Mateusz Guzik wrote:
Gave this a spin and found what looks like a deadlock:
http://people.freebsd.org/~pho/stress/log/ext2fs.txt
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:
http://student.agh.edu.pl/~mjguzik/patches/ext2fs_rmdir-deadlock.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):
http://student.agh.edu.pl/~mjguzik/patches/ext2fs_lookup-relookup.patch
It is indeed extremely useful that UFS and ext2fs are so similar.
The two bugfixes were committed as revision 235508, thanks!
Pedro.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
