On Wed, Nov 22, 2006 at 08:35:44AM -0700, Mark Maybee wrote: > Pawel Jakub Dawidek wrote: [...] > >Bascially it first recorded that db_mtx is locked before z_lock and the > >backtrace above is from where is it locked in an different order. > Um, I think you have that backwards: normally we obtain the z_lock > first, then obtain the db_mtx; but in the above stack, we are obtaining > the z_lock *after* we hold the db_mtx.
Grr, yes you are right, sorry. > >I think it is harmless, because znode is not visible at this point and > >can't be referenced, which means deadlock is not possible here, right? > Yea, I think this is OK. The z_lock is being used here to prevent a > race with the force-unmount code in zfs_inactive(). In that code path > we are not going to try to obtain the db_mtx while holding the z_lock. I had another one, can you analize it? lock order reversal: 1st 0xc44b9b00 zfs:dbuf (zfs:dbuf) @ /zoo/pjd/zfstest/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dbuf.c:1644 2nd 0xc45be898 zfs:dbufs (zfs:dbufs) @ /zoo/pjd/zfstest/sys/modules/zfs/../../contrib/opensolaris/uts/common/fs/zfs/dnode_sync.c:357 KDB: stack backtrace: db_trace_self_wrapper(c05ee0fe) at db_trace_self_wrapper+0x25 kdb_backtrace(0,ffffffff,c065f538,c065f5b0,c061e82c,...) at kdb_backtrace+0x29 witness_checkorder(c45be898,9,c4113f3c,165) at witness_checkorder+0x586 _sx_xlock(c45be898,c4113f3c,165,c41249e0,0,...) at _sx_xlock+0x6e dnode_evict_dbufs(c45be730,0,c4406b40,0,c45be730,...) at dnode_evict_dbufs+0x39 dmu_objset_evict_dbufs(e6258bd0,0,4,c397c000,c40d9918,...) at dmu_objset_evict_dbufs+0x131 dmu_objset_evict(c397c200,c397c000,c397c600,c397c200,e6258c04,...) at dmu_objset_evict+0xb1 dsl_dataset_evict(c44b9ac4,c397c200,e6258c1c,c40aed02,c44b9ac4,...) at dsl_dataset_evict+0x4e dbuf_evict_user(c44b9ac4,c40ab3ee,1,0,e6258c2c,...) at dbuf_evict_user+0x4e dbuf_rele(c44b9ac4,c397c200,e6258c50,c40c7c5c,c397c200,...) at dbuf_rele+0x72 dsl_dataset_sync(c397c200,c3bfea80,0,c397c200,e6258c54,...) at dsl_dataset_sync+0x44 dsl_pool_sync(c397c600,148,0,c061e82c,c397c6ac,...) at dsl_pool_sync+0x78 spa_sync(c37ef000,148,0,149,0,...) at spa_sync+0x2a2 txg_sync_thread(c397c600,e6258d38) at txg_sync_thread+0x1df fork_exit(c40d9918,c397c600,e6258d38) at fork_exit+0xac fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe6258d6c, ebp = 0 --- The backtrace is from where lock order is different than the first recorded. -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-code/attachments/20061122/5f1562c9/attachment.bin>
