From owner-freebsd-sparc64@FreeBSD.ORG Thu Mar 24 13:35:28 2011 Return-Path: Delivered-To: freebsd-sparc64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A8A8106566C; Thu, 24 Mar 2011 13:35:28 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id 3617B8FC21; Thu, 24 Mar 2011 13:35:27 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LIK00402DR3MX00@smtpauth1.wiscmail.wisc.edu>; Thu, 24 Mar 2011 08:35:27 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.65.155]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0LIK00KLZDR1B520@smtpauth1.wiscmail.wisc.edu>; Thu, 24 Mar 2011 08:35:26 -0500 (CDT) Date: Thu, 24 Mar 2011 08:35:23 -0500 From: Nathan Whitehorn In-reply-to: <20110324132228.GD8326@garage.freebsd.pl> To: Pawel Jakub Dawidek Message-id: <4D8B489B.8010204@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.65.155 X-Spam-PmxInfo: Server=avs-13, Version=5.6.0.2009776, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.24.132125, SenderIP=76.210.65.155 References: <20110310185423.GA50419@alchemy.franken.de> <20110319152838.GA8594@alchemy.franken.de> <20110321175632.GA19345@darkthrone.kvedulv.de> <20110321175933.GD2086@garage.freebsd.pl> <20110322191117.GH15528@alchemy.franken.de> <20110323232411.GC82490@darkthrone.kvedulv.de> <4D8B08E1.5060008@FreeBSD.org> <20110324111628.GO15528@alchemy.franken.de> <20110324132228.GD8326@garage.freebsd.pl> User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110305 Thunderbird/3.1.9 Cc: freebsd-sparc64@FreeBSD.org, Roger Hammerstein , Martin Matuska , Marius Strobl Subject: Re: sparc64 hang with zfs v28 X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 13:35:28 -0000 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