On Thu, Oct 29, 2009 at 11:58:32PM +0100, Adam Hamsik wrote: > > On Oct,Thursday 29 2009, at 8:15 PM, David Laight wrote: > > >On Wed, Oct 28, 2009 at 11:44:51PM +0000, Adam Hamsik wrote: > >>Module Name: src > >>Committed By: haad > >>Date: Wed Oct 28 23:44:51 UTC 2009 > >> > >>Modified Files: > >> src/external/cddl/osnet/dist/uts/common/fs/zfs: zfs_vnops.c > >>zfs_znode.c > >> > >>Log Message: > >>Add workaround about zfs vnode reclaiming deadlock by checking if > >>we don't > >>ehld ZFS_MUTEX_OBJ already. If we can lock OBJ_MUTEX deffer > >>execution of > >>zfs_zinactive to taskq. Code was inspired by FreeBSD > >>zfs_freebsd_reclaim. > > > >This doesn't sound right at all ... > > > >If the 'If we can lock OBJ_MUTEX' test is a try_mutex_enter() then > >it may fail because another lwp owns it ... > >I hope it is only the checkin comment that is inverted! > > There are 3 option which can happen > > 1) Our lwp already holds mutex > 2) mutex is not held at all > 3) Another LWP holds it > > In case 1 we can call reclaim vnode, in case 2 we lock it with > try_mutex_enter and reclaim it and in case 3 we use taskq for > reclaiming of vnode. This is reclaiming in response to someone trying to get a cleaned vnode, correct? If so, we should just change the reclaim API and return something like EBUSY. If it's just cleaning to clean, then having a taskq do it is fine. Where you able to look at the repository at macosforge.org before it shut down? I think that would show a take at solving similar issues. Take care, Bill
Attachment:
pgp2iiXmGYjmY.pgp
Description: PGP signature