Chuck Silvers wrote:
> I looked into this, the problem is a race between VOP_REVOKE() and VOP_IOCTL().
> there's another thread in the dump doing:
> 
> #0  0xca62b948 in ?? ()
> #1  0xc02a151b in bpendtsleep ()
> #2  0xc02cd007 in biowait ()
> #3  0xc022eaf3 in ffs_update ()
> #4  0xc02dd39c in VOP_UPDATE ()
> #5  0xc025b7c3 in ufs_reclaim ()
> #6  0xc0243b39 in ffs_reclaim ()
> #7  0xc02dd08c in VOP_RECLAIM ()
> #8  0xc02d2557 in vclean ()
> #9  0xc02d2972 in vgonel ()
> #10 0xc02de417 in genfs_revoke ()
> #11 0xc02dcd80 in VOP_REVOKE ()
> #12 0xc028d338 in exit1 ()
> #13 0xc029c7d2 in postsig ()
> #14 0xc0339ba0 in syscall_plain ()
> 
> 
> vclean() frees the vp->v_specinfo data (and clears the pointer) before
> calling VOP_RECLAIM(), which can sleep.  VOP_IOCTL() doesn't take any lock
> before trying to dereference the (NULL, in this case) pointer.

I've heard that in OSX 10.4, the VOP locking protocol has been redone so it
actually works properly.  Maybe we should look at using their protocol.

-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this message.