Skip site navigation (1)Skip section navigation (2)
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>