freebsd stable - Aug 2018 - VNET related kernel panic on jail startup with epairs on 11-STABLE

On 8/3/18, Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net>
wrote:
> On 3 Aug 2018, at 18:48, Oliver Pinter wrote:
>
>> Hi all!
>>
>> One of out users observed an VNET related kernel panic with epairs in
>> a jail. Seems like some of the
>
> Well would be great for a start to (a) email virtualisation@ as well,
> (b) include a panic message, backtrace or other related information to
> deduce anything about the possible bug, (c) and not to conflate it with
> another totally unrelated MFC request.
>
> So what makes you think it?s related to tcp fast open?
Every required detail is in HardenedBSD's github issue, but I copy the
kernel panic here:

Aug  2 17:52:00 test2 syslogd: kernel boot file is /boot/kernel/kernel
Aug  2 17:52:00 test2 kernel: [205] epair3314a: promiscuous mode enabled
Aug  2 17:52:00 test2 kernel: [205] panic: lock 0xfffffe00078e8fd8 is
not initialized
Aug  2 17:52:00 test2 kernel: [205] cpuid = 0
Aug  2 17:52:00 test2 kernel: [205] __HardenedBSD_version = 1100056
__FreeBSD_version = 1102501
Aug  2 17:52:00 test2 kernel: [205] version = FreeBSD 11.2-STABLE-HBSD
#0 : Thu Aug  2 02:27:22 CEST 2018
Aug  2 17:52:00 test2 kernel: [205]     root at
hb67:/?/obj/?/src/11/sys/VerKnowSys
Aug  2 17:52:00 test2 kernel: [205] KDB: stack backtrace:
Aug  2 17:52:00 test2 kernel: [205] db_trace_self_wrapper() at
db_trace_self_wrapper+0x2b/frame 0xfffffe011fbed750
Aug  2 17:52:00 test2 kernel: [205] vpanic() at vpanic+0x17c/frame
0xfffffe011fbed7b0
Aug  2 17:52:00 test2 kernel: [205] doadump() at doadump/frame
0xfffffe011fbed830
Aug  2 17:52:00 test2 kernel: [205] lock_destroy() at
lock_destroy+0x32/frame 0xfffffe011fbed850
Aug  2 17:52:00 test2 kernel: [205] rm_destroy() at
rm_destroy+0x33/frame 0xfffffe011fbed870
Aug  2 17:52:00 test2 kernel: [205] tcp_fastopen_destroy() at
tcp_fastopen_destroy+0x44/frame 0xfffffe011fbed890
Aug  2 17:52:00 test2 kernel: [205] tcp_destroy() at
tcp_destroy+0x10e/frame 0xfffffe011fbed8c0
Aug  2 17:52:00 test2 kernel: [205] vnet_destroy() at
vnet_destroy+0x12c/frame 0xfffffe011fbed8f0
Aug  2 17:52:00 test2 kernel: [205] prison_deref() at
prison_deref+0x29d/frame 0xfffffe011fbed930
Aug  2 17:52:00 test2 kernel: [205] sys_jail_remove() at
sys_jail_remove+0x28a/frame 0xfffffe011fbed980
Aug  2 17:52:00 test2 kernel: [205] amd64_syscall() at
amd64_syscall+0x6ae/frame 0xfffffe011fbedab0
Aug  2 17:52:00 test2 kernel: [205] fast_syscall_common() at
fast_syscall_common+0x101/frame 0xfffffe011fbedab0
Aug  2 17:52:00 test2 kernel: [205] --- syscall (508, FreeBSD ELF64,
sys_jail_remove), rip = 0x507a3545dba, rsp = 0x68533a501528, rbp 0x68533a5015a0
---
Aug  2 17:52:00 test2 kernel: [205] KDB: enter: panic
>
>
> /bz
>

On 3 Aug 2018, at 20:42, Oliver Pinter wrote:
> On 8/3/18, Bjoern A. Zeeb <bzeeb-lists at lists.zabbadoz.net> wrote:
>> On 3 Aug 2018, at 18:48, Oliver Pinter wrote:
>>
>>> Hi all!
>>>
>>> One of out users observed an VNET related kernel panic with epairs 
>>> in
>>> a jail. Seems like some of the
>>
>> Well would be great for a start to (a) email virtualisation@ as well,
>> (b) include a panic message, backtrace or other related information 
>> to
>> deduce anything about the possible bug, (c) and not to conflate it 
>> with
>> another totally unrelated MFC request.
>>
>> So what makes you think it?s related to tcp fast open?
>
> Every required detail is in HardenedBSD's github issue, but I copy the
> kernel panic here:
Ah sorry my bad;  the issue said ZFS in the subject and I thought it 
refers to something else.

Thanks! Looking at the backtrace it seems it is happening on teardown 
and not on startup but indeed in the fast open code and that PR 216613 
indeed fixed this in head, good :)  Hope Patrick will do the mfc for 
you.

/bz