Date: Sat, 29 Jun 2013 18:49:16 +0200 From: Martin Matuska <mm@FreeBSD.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Kristof Provost <kristof@sigsegv.be>, current@freebsd.org Subject: Re: zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS? Message-ID: <51CF100C.2010902@FreeBSD.org> In-Reply-To: <20130629170024.0000145b@unknown> References: <20130612223024.00003980@unknown> <E9E313A1-AEA5-4926-86A2-6CEF0E7EB388@freebsd.org> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mm@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51CF100C.2010902>