sparc64 hang with zfs v28

[Martin Matuska]

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

Dňa 24.03.2011 00:24, Michael Moll  wrote / napísal(a):
> Hi All,
> 
> On Tue, Mar 22, 2011 at 08:11:17PM +0100, Marius Strobl wrote:
> 
>> Uhm, looks like r219089 changed some xcopy{in,out}() into
>> ddi_copy{in,out}(), i.e. copy{in,out}() into bcopy(), which
>> is just wrong for copying in data in from/out to userspace.
>> However, looking at the other uses of ddi_copy{in,out}() it
>> generally seems that ddi_copy{in,out}() should be defined to
>> copy{in,out}(). With the attached patch at least my simple
>> test cases works again.
> 
> That looks good, I will test more tomorrow but when netbooting I can
> import a zpool now. The only thing is that when upgrading the kernel and
> using the old world it still hangs:
> http://space.kvedulv.de/zfs_v28/at.txt
> 
> zfs_ioctl_compat_post() is probably the problematic function.
> 
> Regards