From owner-freebsd-current@FreeBSD.ORG Sat Jun 29 16:49:22 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D0A4D992 for ; Sat, 29 Jun 2013 16:49:22 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (mail.vx.sk [IPv6:2a01:4f8:150:6101::4]) by mx1.freebsd.org (Postfix) with ESMTP id 94F2F1CDB for ; Sat, 29 Jun 2013 16:49:22 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.2]) by mail.vx.sk (Postfix) with ESMTP id C44983515A; Sat, 29 Jun 2013 18:49:18 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk by core.vx.sk (amavisd-new, unix socket) with LMTP id 0ijnS01fR5yZ; Sat, 29 Jun 2013 18:49:17 +0200 (CEST) Received: from [10.9.8.1] (chello085216226145.chello.sk [85.216.226.145]) by mail.vx.sk (Postfix) with ESMTPSA id 57F063514E; Sat, 29 Jun 2013 18:49:17 +0200 (CEST) Message-ID: <51CF100C.2010902@FreeBSD.org> Date: Sat, 29 Jun 2013 18:49:16 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Alexander Leidinger Subject: Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS? References: <20130612223024.00003980@unknown> <20130614230702.00006aa0@unknown> <20130624101517.GA9630@thebe.jupiter.sigsegv.be> <20130624220801.0000492c@unknown> <20130627215832.GA9470@thebe.jupiter.sigsegv.be> <20130629120122.000041c7@unknown> <51CECCDB.7040904@FreeBSD.org> <20130629170024.0000145b@unknown> In-Reply-To: <20130629170024.0000145b@unknown> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kristof Provost , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 16:49:22 -0000 This was an obvious error by me - I forgot to register zfs_ioc_jail and zfs_ioc_unjail using the new functions. Amazing noone noticed this by now until it got merged down to stable/8. In addition, I see no need to log these operations to the zpool history as they cause no on-disk changes, so I have disabled logging for these calls. Please test the patch from current in r252380. http://svnweb.freebsd.org/base?view=revision&revision=252380 On 29.6.2013 17:00, Alexander Leidinger wrote: > On Sat, 29 Jun 2013 14:02:35 +0200 > Martin Matuska wrote: > >> some input would be great (at least the panic message - ideally from a >> debug kernel). > The bt in the minidump is useless, but I made a bt directly > in the kernel debugger: > ---snip--- > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x0 > fault code = supervisor read instruction, page not present > instruction pointer = 0x20:0x0 > stack pointer = 0x28:0xffffff839e79d930 > frame pointer = 0x28:0xffffff839e79d9e0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2183 (zfs) > > db> bt > Tracing pid 2356 > uart_sab82532_class() at 0 > devfs_ioctl_f() at devfs_ioctl_f+0xf0 > kern_ioctl() at kern_ioctl+0x1d7 > sys_ioctl() at sys_ioctl+0x142 > ---snip--- > > The test case is easy, create a dataset for a jail, add something like > this to /etc/devfs.rules: > ---snip--- > [devfsrules_unhide_zfs=12] > add path zfs unhide > > [devfsrules_jail_withzfs=17] > add include $devfsrules_hide_all > add include $devfsrules_unhide_basic > add include $devfsrules_unhide_login > add include $devfsrules_unhide_zfs > ---snip--- > > Attach the dataset to the jail and see the box panicing on the use of > the zfs command in the jail (maybe you don't even need to attach the > dataset to the jail, maybe just the above devfs stuff is enough). > > The default jail scripts don't attach a ZFS dataset to a jail, the > corresponding ezjail-script code is > > # Attach ZFS-datasets to the jail > for zfs in ${ezjail_zfs_datasets}; do > /sbin/zfs jail ${ezjail_id} ${zfs} || echo -n "Error: ${zfs} could not be configured" > done > > Bye, > Alexander. > -- Martin Matuska FreeBSD committer http://blog.vx.sk