Bug 227785 - ip_mroute: empty ef->progtab[i].name page fault while in kernel mode
Summary: ip_mroute: empty ef->progtab[i].name page fault while in kernel mode
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2018-04-26 09:25 UTC by Eitan Adler
Modified: 2019-11-18 00:01 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Eitan Adler freebsd_committer freebsd_triage 2018-04-26 09:25:15 UTC
How to reproduce:

kldload ip_mroute 

Unread portion of the kernel message buffer:
[341188] Fatal trap 12: page fault while in kernel mode
[341188] cpuid = 17; apic id = 11
[341188] fault virtual address  = 0x0
[341188] fault code             = supervisor read data, page not present
[341188] instruction pointer    = 0x20:0xffffffff80c50cd0
[341188] stack pointer          = 0x28:0xfffffe00a741c440
[341188] frame pointer          = 0x28:0xfffffe00a741c440
[341188] code segment           = base rx0, limit 0xfffff, type 0x1b
[341188]                        = DPL 0, pres 1, long 1, def32 0, gran 1
[341188] processor eflags       = interrupt enabled, resume, IOPL = 0
[341188] current process                = 31597 (kldload)

__curthread () at ./machine/pcpu.h:230
230             __asm("movq %%gs:%1,%0" : "=r" (td)

(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:230
#1  doadump (textdump=0x1) at /usr/src/sys/kern/kern_shutdown.c:361
#2  0xffffffff80434f4c in db_fncall_generic (addr=<optimized out>, rv=<optimized out>, nargs=<optimized out>, args=<optimized out>) at /usr/src/sys/ddb/db_command.c:609
#3  db_fncall (dummy1=<optimized out>, dummy2=<optimized out>, dummy3=<optimized out>, dummy4=<optimized out>) at /usr/src/sys/ddb/db_command.c:657
#4  0xffffffff80434a99 in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=<optimized out>) at /usr/src/sys/ddb/db_command.c:481
#5  0xffffffff80434814 in db_command_loop () at /usr/src/sys/ddb/db_command.c:534
#6  0xffffffff80437a3f in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:250
#7  0xffffffff80babf53 in kdb_trap (type=0xc, code=0x0, tf=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:697
#8  0xffffffff81025170 in trap_fatal (frame=0xfffffe00a741c380, eva=0x0) at /usr/src/sys/amd64/amd64/trap.c:815
#9  0xffffffff81025282 in trap_pfault (frame=0xfffffe00a741c380, usermode=<optimized out>) at /usr/src/sys/amd64/amd64/trap.c:664
#10 0xffffffff81024a72 in trap (frame=0xfffffe00a741c380) at /usr/src/sys/amd64/amd64/trap.c:413
#11 <signal handler called>
#12 strncmp (s1=0x0, s2=0xffffffff812562ea "set_", n=0x4) at /usr/src/sys/libkern/strncmp.c:44
#13 0xffffffff8114f214 in link_elf_lookup_set (lf=0xfffff8003930c800, name=0xffffffff83bacc82 "sdt_providers_set", startp=0xfffffe00a741c4a0, stopp=0xfffffe00a741c4a8, countp=0x0) at /usr/src/sys/kern/link_elf_obj.c:1265
#14 0xffffffff83bac5e9 in sdt_kld_unload_try (arg=<optimized out>, lf=0xfffff8003930cc00, error=0xfffffe00a741c504) at /usr/src/sys/cddl/dev/sdt/sdt.c:314
#15 0xffffffff80b3712b in linker_file_unload (file=0xfffff8003930c800, flags=0x1) at /usr/src/sys/kern/kern_linker.c:656
#16 0xffffffff8114d76f in link_elf_load_file (cls=<optimized out>, filename=<optimized out>, result=<optimized out>) at /usr/src/sys/kern/link_elf_obj.c:1002
#17 0xffffffff80b36a2c in LINKER_LOAD_FILE (cls=0xffffffff81b7dc80 <link_elf_class>, result=0x0, filename=<optimized out>) at ./linker_if.h:180
#18 linker_load_file (filename=<optimized out>, result=<optimized out>) at /usr/src/sys/kern/kern_linker.c:447
#19 linker_load_module (kldname=<optimized out>, modname=0x0, parent=0x0, verinfo=<optimized out>, lfpp=0xfffffe00a741c918) at /usr/src/sys/kern/kern_linker.c:2092
#20 0xffffffff80b38361 in kern_kldload (td=<optimized out>, file=<optimized out>, fileid=0xfffffe00a741c964) at /usr/src/sys/kern/kern_linker.c:1071
#21 0xffffffff80b3848b in sys_kldload (td=0xfffff800461cc560, uap=<optimized out>) at /usr/src/sys/kern/kern_linker.c:1097
#22 0xffffffff8102606b in syscallenter (td=0xfffff800461cc560) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:134
#23 amd64_syscall (td=0xfffff800461cc560, traced=0x0) at /usr/src/sys/amd64/amd64/trap.c:936
#24 <signal handler called>
#25 0x00000008002cfd8a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffffffd468

(kgdb) frame 12
Stack level 12, frame at 0xfffffe00a741c450:
 rip = 0xffffffff80c50cd0 in strncmp (/usr/src/sys/libkern/strncmp.c:44); saved rip = 0xffffffff8114f214
 called by frame at 0xfffffe00a741c4a0, caller of frame at 0xfffffe00a741c440
 source language c.
 Arglist at 0xfffffe00a741c440, args: s1=0x0, s2=0xffffffff812562ea "set_", n=0x4
 Locals at 0xfffffe00a741c440, Previous frame's sp is 0xfffffe00a741c450
 Saved registers:
  rbp at 0xfffffe00a741c440, rip at 0xfffffe00a741c448
s1 = 0x0
s2 = 0xffffffff812562ea "set_"
n = 0x4
No locals.

(kgdb) list
1260            void **start, **stop;
1261            int i, count;
1263            /* Relative to section number */
1264            for (i = 0; i < ef->nprogtab; i++) {
1265                    if ((strncmp(ef->progtab[i].name, "set_", 4) == 0) &&
1266                        strcmp(ef->progtab[i].name + 4, name) == 0) {
1267                            start  = (void **)ef->progtab[i].addr;
1268                            stop = (void **)((char *)ef->progtab[i].addr +
1269                                ef->progtab[i].size);

(kgdb) p ef->progtab[i]
$8 = {
  addr = 0x0,
  size = 0x0,
  flags = 0x0,
  sec = 0x0,
  name = 0x0

further details here: https://reviews.freebsd.org/P173
Comment 1 Bjoern A. Zeeb freebsd_committer 2019-11-17 22:16:30 UTC
Do you know if this was a temporary problem?
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2019-11-17 23:35:09 UTC
It was reproducible when I reported this. My machine is not currently in a healthy state and I can't test at all right now.
Comment 3 Bjoern A. Zeeb freebsd_committer 2019-11-17 23:44:25 UTC
Given the code has changed before 12.0-R and people recently did load ip_mroute and your problem more like was in SDT code anyway, I wonder if we should close this for now and it can be re-opened if it happens again by someone?

I only found it because I was looking for an ip_mroute VNET issue.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2019-11-18 00:01:08 UTC
I trust your judgment.