sparc64 hang with zfs v28

[Nathan Whitehorn]

On 03/24/11 08:22, Pawel Jakub Dawidek wrote:
> On Thu, Mar 24, 2011 at 12:16:28PM +0100, Marius Strobl wrote:
>> 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 ...
> Because on x86 you use copyin(9)/copyout(9) if you are polite. There is
> nothing that enforce this. I'm happy we have sparc64 to trigger such
> bugs.

These blew up powerpc too.

Background for the archives: On x86, when user processes call into the 
kernel, they share an address space, so you actually can memcpy() 
straight to a user address and have it work. (This is also why the 
various kernel NULL-pointer bugs caused security problems) On some other 
architectures, address space is not shared, and copyin/out() does 
something more complicated, and trying just to memcpy() data causes 
things to blow up horribly.
-Nathan