zfs kernel panic, known incompatibilities with clang & CPUTYPE/COPTFLAGS?
Martin Matuska
mm at FreeBSD.org
Sat Jun 29 16:49:22 UTC 2013
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 at 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
More information about the freebsd-current
mailing list