Crash at zfs_vnop_reclaim

Using 'manyfiles' testcase, can generate a panic fairly easily.

<pre>
sudo kextload /target/zfs.kext
/usr/sbin/mkfile 100m /tmp/foobar
/target/zpool create foobar /tmp/foobar
sleep 1
for i in 0 1 2 3 4 5 6 7 8 9 ; do for j in 0 1 2 3 4 5 6 7 8 9 ; do /target/zfs 
create foobar/zfs-$i-
$j; done; done
cd /Volumes/foobar
for i in zfs-*-9; do /target/zfs set compression=on foobar/$i; done
for i in zfs-5-*; do cp -R 
/System/Library/Frameworks/AppleShareClient.framework $i; done
</pre>

This occurs at:

#4  0x343b28d6 in zfs_vnop_reclaim (ap=0x35347c64) at .../mac-
zfs/usr/src/uts/common/fs/zfs/zfs_vnops.c:4419
4419        zfsvfs_t *zfsvfs = zp->z_zfsvfs;

http://github.com/alblue/mac-
zfs/blob/maczfs_72/usr/src/uts/common/fs/zfs/zfs_vnops.c#L4419

Upon closer inspection in a debugger, the zp is null at this point. This 
ultimately comes from:

http://developer.apple.com/mac/library/documentation/Darwin/Reference/KernelIOKi
tFramewo
rk/vnode_h/index.html#//apple_ref/c/func/vnode_fsnode

which gives back the fs-specific data from the vnode. so the problem seems to 
be that we don't 
have any ZFS data with the vnode handed to us at that time (why?) which then 
triggers the panic.

Original issue reported on code.google.com by alex.ble...@gmail.com on 8 Mar 2010 at 12:37

BjoKaSH / maczfs-archive

Crash at zfs_vnop_reclaim #39