on 29/07/2009 17:36 Andriy Gapon said the following: > on 29/07/2009 17:10 Thomas Backman said the following: > [snip] >> (kgdb) fr 11 > [snip] >> (kgdb) p *sx >> $8 = {lock_object = {lo_name = 0xffffffff80b5634c "zp->z_lock", lo_flags >> = 40894464 [0x2700000, btw], lo_data = 0, lo_witness = 0x0}, >> sx_lock = 6} >> >> ... as you might notice, I'm mostly clueless as to what I'm doing here. :o >> Hope that helps (a bit), though. > > Yes, it does and a lot. > sx_lock = 6 means that this sx lock is destroyed: > #define SX_LOCK_DESTROYED \ > (SX_LOCK_SHARED_WAITERS | SX_LOCK_EXCLUSIVE_WAITERS) > > And lo_name tells that this is zp->z_lock. > This lock is destroyed in zfs_znode_cache_destructor. > Not enough knowledge for me to proceed further. So I guess that this is a case when zfs_znode_delete() was called on znode that was still referenced from some vnode. When the vnode gets reclaimed we get this problem. Could you please examine vp in frame 15 or 16? -- Andriy GaponReceived on Wed Jul 29 2009 - 14:02:25 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC