Bug 236864 - sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic
Summary: sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-29 00:53 UTC by Enji Cooper
Modified: 2019-04-01 13:48 UTC (History)
4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer freebsd_triage 2019-03-29 00:53:45 UTC 
From https://ci.freebsd.org/job/FreeBSD-head-amd64-test/10671/console :

sys/netpfil/pf/ioctl/validation:addtables  ->  
16:58:03 
16:58:03 Fatal trap 9: general protection fault while in kernel mode
16:58:03 cpuid = 0; apic id = 00
16:58:03 instruction pointer	= 0x20:0xffffffff80cc8c75
16:58:03 stack pointer	        = 0x28:0xfffffe0030faf740
16:58:03 frame pointer	        = 0x28:0xfffffe0030faf740
16:58:03 code segment		= base rx0, limit 0xfffff, type 0x1b
16:58:03 			= DPL 0, pres 1, long 1, def32 0, gran 1
16:58:03 processor eflags	= interrupt enabled, resume, IOPL = 0
16:58:03 current process		= 23278 (ifconfig)
16:58:03 trap number		= 9
16:58:03 panic: general protection fault
16:58:03 cpuid = 0
16:58:03 time = 1553817482
16:58:03 KDB: stack backtrace:
16:58:03 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0030faf450
16:58:03 vpanic() at vpanic+0x19d/frame 0xfffffe0030faf4a0
16:58:03 panic() at panic+0x43/frame 0xfffffe0030faf500
16:58:03 trap_fatal() at trap_fatal+0x394/frame 0xfffffe0030faf560
16:58:03 trap() at trap+0x6c/frame 0xfffffe0030faf670
16:58:03 calltrap() at calltrap+0x8/frame 0xfffffe0030faf670
16:58:03 --- trap 0x9, rip = 0xffffffff80cc8c75, rsp = 0xfffffe0030faf740, rbp = 0xfffffe0030faf740 ---
16:58:03 strncmp() at strncmp+0x15/frame 0xfffffe0030faf740
16:58:03 ifunit_ref() at ifunit_ref+0x51/frame 0xfffffe0030faf780
16:58:03 ifioctl() at ifioctl+0x508/frame 0xfffffe0030faf850
16:58:03 kern_ioctl() at kern_ioctl+0x28a/frame 0xfffffe0030faf8c0
16:58:03 sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe0030faf990
16:58:03 amd64_syscall() at amd64_syscall+0x276/frame 0xfffffe0030fafab0
16:58:03 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0030fafab0
16:58:03 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004842ca, rsp = 0x7fffffffe448, rbp = 0x7fffffffe4b0 ---
Comment 1 Li-Wen Hsu freebsd_committer freebsd_triage 2019-03-29 04:37:20 UTC 
hmm, the commit r345660 doesn't seem to be related to this test, and the next run this case passed.  We need to find a reliable way to reproduce this panic.
Comment 2 Kristof Provost freebsd_committer freebsd_triage 2019-03-29 16:15:44 UTC 
It appears to be reproducible by running the pf tests (/usr/tests/sys/netpfil/pf, not just the ioctl tests) in a loop.

The backtrace suggests this is a generic issue with setting up or tearing down interfaces rather than something specific to pf though.

This panics in ifunit_ref(), because while we're iterating the list of interfaces (and have the NET_EPOCH held) we run into a freed interface:

#16 0xffffffff80cdcce1 in ifunit_ref (name=0xfffffe009dfae7e0 "epair0b") at /usr/src/sys/net/if.c:2422
2422                    if (strncmp(name, ifp->if_xname, IFNAMSIZ) == 0 &&
(kgdb) p name
$1 = 0xfffffe009dfae7e0 "epair0b"
(kgdb) p ifp
$2 = (struct ifnet *) 0xdeadc0dedeadc0de

I'd assume that means some other part of the code has free()d the interface without going through the appropriate 'wait until the epoch is over' callback.