sparc64 hang with zfs v28

[Martin Matuska]

I agree to the patch, that is exactly what I was missing in the v15
compat code.

Too bad that I don't have a sparc64 to test these things out and get
smarter. I am investigating now if its possible to emulate it with qemu.

Dňa 24.03.2011 12:16, Marius Strobl  wrote / napísal(a):
> 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
>