Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/external/cddl/osnet/dist/uts/common/fs/zfs



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



Home | Main Index | Thread Index | Old Index