Bug 238012 - ipsec(4): Loading kernel module panic: vnet_ipcompstat_init
Summary: ipsec(4): Loading kernel module panic: vnet_ipcompstat_init
Status: Closed DUPLICATE of bug 230857
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: i386 Any
: --- Affects Some People
Assignee: Bjoern A. Zeeb
URL:
Keywords: crash, needs-qa, patch, vimage
Depends on:
Blocks:
 
Reported: 2019-05-21 04:41 UTC by Li-Wen Hsu
Modified: 2019-06-08 17:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Li-Wen Hsu freebsd_committer 2019-05-21 04:41:34 UTC
FreeBSD/i386 (Amnesiac) (ttyu0)                                                                    
                                                                                             
FreeBSD 13.0-CURRENT r348007 GENERIC                                                  
                                                                                                         
root@:~ # kldload ipsec

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x1cfe645c
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0x19aa417a
stack pointer           = 0x28:0x1a822858
frame pointer           = 0x28:0x1a82285c
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 778 (kldload)
trap number             = 12
panic: page fault
cpuid = 0
time = 1558407144
KDB: stack backtrace:
db_trace_self_wrapper(69,10c84e00,1576b09,10c84e00,1a822674,...) at db_trace_self_wrapper+0x2a/frame 0x1a822640
kdb_backtrace(e,0,0,1a822818,1a822818,...) at kdb_backtrace+0x2e/frame 0x1a8226a0
vpanic(1576b09,1a8226e4,1a8226e4,1a822718,1515116,...) at vpanic+0x121/frame 0x1a8226c4
panic(1576b09,1601ef9,2de5000,2,1cfe645c,...) at panic+0x14/frame 0x1a8226d8
trap_fatal(10000,0,1bcd388,1ef7e28,2de9cd8,...) at trap_fatal+0x356/frame 0x1a822718
trap_pfault(1cfe645c) at trap_pfault+0x51/frame 0x1a822754
trap(1a822818,8,28,28,53f6040,...) at trap+0x3c0/frame 0x1a82280c
calltrap() at 0xffc0316d/frame 0x1a82280c
--- trap 0xc, eip = 0x19aa417a, esp = 0x1a822858, ebp = 0x1a82285c ---
vnet_ipcompstat_init(0) at vnet_ipcompstat_init+0x2a/frame 0x1a82285c
vnet_register_sysinit(19aa7ba0) at vnet_register_sysinit+0xe1/frame 0x1a822874
linker_load_module(0,0,1a822a90) at linker_load_module+0xa84/frame 0x1a822a7c
kern_kldload(1a745a80,5448000,1a822ab8) at kern_kldload+0xca/frame 0x1a822aa4
sys_kldload(1a745a80,1a745d08) at sys_kldload+0x50/frame 0x1a822ac8
syscall(1a822ba8,3b,3b,3b,1,...) at syscall+0x2b4/frame 0x1a822b9c
Xint0x80_syscall() at 0xffc033b7/frame 0x1a822b9c
--- syscall (304, FreeBSD ELF32, sys_kldload), eip = 0x20490f9f, esp = 0xffbfe7d0, ebp = 0xffbfed0c ---
ipe6_cookie() at 0x20490f9f
KDB: enter: panic
[ thread pid 778 tid 100103 ]
Stopped at      kdb_enter+0x35: movl    $0,kdb_why
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-05-21 04:49:07 UTC
Thank you for the report Li-Wen

Is this a recent regression?
Comment 2 Bjoern A. Zeeb freebsd_committer 2019-05-21 19:52:14 UTC
Can you try this one and let me know if it helps?

diff --git a/sys/netipsec/xform_ipcomp.c b/sys/netipsec/xform_ipcomp.c
index df09eb36cfa..553283db2ae 100644
--- a/sys/netipsec/xform_ipcomp.c
+++ b/sys/netipsec/xform_ipcomp.c
@@ -774,3 +774,18 @@ SYSINIT(ipcomp_xform_init, SI_SUB_PROTO_DOMAIN, SI_ORDER_MIDDLE,
     ipcomp_attach, NULL);
 SYSUNINIT(ipcomp_xform_uninit, SI_SUB_PROTO_DOMAIN, SI_ORDER_MIDDLE,
     ipcomp_detach, NULL);
+
+#ifdef VIMAGE
+#if defined(__i386__)
+/*
+ * XXX This is a hack to work around an absolute relocation outside
+ * set_vnet by one (on the stop symbol) for carpstats.  Add a dummy variable
+ * to the end of the file in the hope that the linker will just keep the
+ * order (as it seems to do at the moment).  It is understood to be fragile.
+ * See PR 230857 for a longer discussion of the problem and the referenced
+ * review for possible alternate solutions.  Each is a hack; we just need
+ * the least intrusive one for the next release.
+ */
+VNET_DEFINE(char, xform_ipcomp_zzz) = 0xde;
+#endif
+#endif
Comment 3 Li-Wen Hsu freebsd_committer 2019-05-22 03:04:36 UTC
Kubilay, I don't think so. This is found because we recently need to load ipsec(4) after r347410 removed it from GENERIC.  It might be related to bug230857.


Bjoern,

r348059 + patch in the comment 2:

root@:~ # kldload ipsec

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x21d4d45c
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0x1cc1417a
stack pointer           = 0x28:0x18aec858
frame pointer           = 0x28:0x18aec85c
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 672 (kldload)
trap number             = 12
panic: page fault
cpuid = 0
time = 1558493875
KDB: stack backtrace:
db_trace_self_wrapper(69,71ebe00,1576b89,71ebe00,18aec674,...) at db_trace_self_wrapper+0x2a/frame 0x18aec640                                                                                     
kdb_backtrace(2,0,0,18aec818,18aec818,...) at kdb_backtrace+0x2e/frame 0x18aec6a0
vpanic(1576b89,18aec6e4,18aec6e4,18aec718,1515136,...) at vpanic+0x121/frame 0x18aec6c4
panic(1576b89,1601f79,2de5000,2,21d4d45c,...) at panic+0x14/frame 0x18aec6d8
trap_fatal(10000,0,1bcd388,1ef8198,2de9cd8,...) at trap_fatal+0x356/frame 0x18aec718
trap_pfault(21d4d45c) at trap_pfault+0x51/frame 0x18aec754
trap(18aec818,8,28,28,6ffb040,...) at trap+0x3c0/frame 0x18aec80c
calltrap() at 0xffc0316d/frame 0x18aec80c
--- trap 0xc, eip = 0x1cc1417a, esp = 0x18aec858, ebp = 0x18aec85c ---
vnet_ipcompstat_init(0) at vnet_ipcompstat_init+0x2a/frame 0x18aec85c
vnet_register_sysinit(1cc17ba0) at vnet_register_sysinit+0xe1/frame 0x18aec874
linker_load_module(0,0,18aeca90) at linker_load_module+0xa84/frame 0x18aeca7c
kern_kldload(1c695380,7048800,18aecab8) at kern_kldload+0xca/frame 0x18aecaa4
sys_kldload(1c695380,1c695608) at sys_kldload+0x50/frame 0x18aecac8
syscall(18aecba8,3b,3b,3b,1,...) at syscall+0x2b4/frame 0x18aecb9c
Xint0x80_syscall() at 0xffc033b7/frame 0x18aecb9c
--- syscall (304, FreeBSD ELF32, sys_kldload), eip = 0x20490f9f, esp = 0xffbfe7d0, ebp = 0xffbfed0c ---                                                                                           
ipe6_cookie() at 0x20490f9f
KDB: enter: panic
[ thread pid 672 tid 100084 ]
Stopped at      kdb_enter+0x35: movl    $0,kdb_why
db>
Comment 4 Bjoern A. Zeeb freebsd_committer 2019-05-22 14:43:05 UTC
Ok,

I tried this one and that currently does the trick for me after recompiling my kernel with all modules and installing it (full build).


diff --git a/sys/netipsec/xform_ipcomp.c b/sys/netipsec/xform_ipcomp.c
index df09eb36cfa..0bbeed1f678 100644
--- a/sys/netipsec/xform_ipcomp.c
+++ b/sys/netipsec/xform_ipcomp.c
@@ -87,6 +87,22 @@ SYSCTL_VNET_PCPUSTAT(_net_inet_ipcomp, IPSECCTL_STATS, stats,
     struct ipcompstat, ipcompstat,
     "IPCOMP statistics (struct ipcompstat, netipsec/ipcomp_var.h");

+
+#ifdef VIMAGE
+#if defined(__i386__)
+/*
+ * XXX This is a hack to work around an absolute relocation outside
+ * set_vnet by one (on the stop symbol) for carpstats.  Add a dummy variable
+ * to the end of the file in the hope that the linker will just keep the
+ * order (as it seems to do at the moment).  It is understood to be fragile.
+ * See PR 230857 for a longer discussion of the problem and the referenced
+ * review for possible alternate solutions.  Each is a hack; we just need
+ * the least intrusive one for the next release.
+ */
+VNET_DEFINE(char, zzz_xform_ipcomp) = 0xde;
+#endif
+#endif
+
 static int ipcomp_input_cb(struct cryptop *crp);
 static int ipcomp_output_cb(struct cryptop *crp);
Comment 5 Li-Wen Hsu freebsd_committer 2019-05-22 16:55:35 UTC
Talked to bz@ and found that our build environment are different: 12 works but 13 doesn't.  It's a more general problem related to code generation and he will look into this more. :)
Comment 6 Bjoern A. Zeeb freebsd_committer 2019-06-08 17:45:51 UTC

*** This bug has been marked as a duplicate of bug 230857 ***