sparc64 hang with zfs v28

Marius Strobl marius at alchemy.franken.de
Thu Mar 24 11:16:31 UTC 2011


On Thu, Mar 24, 2011 at 10:03:29AM +0100, Martin Matuska wrote:
> zfs_ioctl_compat_post() calls depending on the ioctl
> zfs_ioctl_compat_fix_stats() or zfs_ioctl_compat_pool_get_props()
> 
> Both functions unpack the "zc->zc_nvlist_dst" into "nv" at the very
> beginning and I might be missing something here (works very well on
> i386/amd64) or there might be a problem elsewhere.
> 
> nvlist_unpack() from libnvpair (nvpair.c) calls nvlist_xunpack(),
> issuing a nvlist_xalloc(), followerd by a nvlist_common() in
> NVS_OP_DECODE mode - that's where it dies.
> nvlist_common() deals directly with endianess.
> 
> sys/cddl/contrib/opensolaris/common/zfs/zfs_ioctl_compat.c
> sys/cddl/contrib/opensolaris/common/nvpair/nvpair.c
> 

The code in zfs_ioctl_compat.c just completely misses the copyin()/
copyout() dance. The following patch should fix this, but is compile-
tested only so far:
http://people.freebsd.org/~marius/zfs_ioctl_compat.c.diff
Which still is to be used together with:
http://people.freebsd.org/~marius/sunddi.h.diff

I'm puzzled as to why these bugs don't cause havoc on x86 ...

Marius



More information about the freebsd-sparc64 mailing list