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.Received on Wed May 16 2012 - 13:58:11 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:27 UTC