sparc64 hang with zfs v28

Pawel Jakub Dawidek pjd at FreeBSD.org
Thu Mar 24 13:22:44 UTC 2011


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.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-sparc64/attachments/20110324/80e7d98d/attachment.pgp


More information about the freebsd-sparc64 mailing list