|Summary:||panic: page fault on rtsock.c|
|Component:||kern||Assignee:||freebsd-net mailing list <net>|
|Severity:||Affects Many People||CC:||ae, eugen, lenzi.sergio, markj|
Description lenzi.sergio 2019-03-28 15:28:43 UTC
The system panics on /usr/src/sys/net/rtsock.c:839 and all references to ifp->if_addr->ifa_addr the pointer ifp->if_addr is invalid. some race condition occurs that releases the ifp->if_addr and when the code tries to read the next pointer a page fault occurs.... sometimes it happens in /usr/src/sys/net/rtsock.c:1581 too how to reproduce: setup (1) a freebsd 12 or 13 as a ppp-in server (man ppp) using the setup in the example at http://www.k1.com.br/crash/ppp, than go to another freebsd and using the ppptun.conf, connect to the (1) using the command ppp -ddial ppptun after several connects and disconnects, the (1) panics... sometimes the simple route get "any ppp address" is enough to panic the system. The resulting debug files of the panic is in the http://www.k1.com.br/crash
Comment 1 Eugene Grosbein 2019-03-30 11:48:05 UTC
Please specify exact revisions of FreeBSD you are using as very similar problem was fixed not long ago. CC'ing ae@ just in case it's new.
Comment 2 Andrey V. Elsukov 2019-03-30 12:51:35 UTC
(In reply to Eugene Grosbein from comment #1) > Please specify exact revisions of FreeBSD you are using as very similar > problem was fixed not long ago. > > CC'ing ae@ just in case it's new. It is CURRENT, you can see revision for each dump in core.txt. I don't think this problem was fixed. I suspect the problem occurs when tun(4) interfaces are going down. There are two sorts of panic, one is in nd6_dad_timer(), second is in route_output(). It seems in both cases ifnet pointer is already freed.
Comment 3 Andrey V. Elsukov 2019-03-30 13:43:11 UTC
Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc0e6 fault code = supervisor read data, page not present instruction pointer = 0x20:0x10554cb stack pointer = 0x28:0x13ef3ba0 frame pointer = 0x28:0x13ef3c04 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 = 12 (swi4: clock (0)) trap number = 12 panic: page fault cpuid = 0 time = 1553520118 KDB: stack backtrace: db_trace_self_wrapper(ccc1c1,1,ac27dc0,13ef39bc,b4dd91,...) at db_trace_self_wrapper+0x2a/frame 0x13ef3990 kdb_backtrace(e,0,0,13ef3b60,13ef3b60,...) at kdb_backtrace+0x2e/frame 0x13ef39f0 vpanic(1243776,13ef3a34,13ef3a34,13ef3a68,11ef956,...) at vpanic+0x121/frame 0x13ef3a14 panic(1243776,12b225a,2695000,0,deadc0e6,...) at panic+0x14/frame 0x13ef3a28 trap_fatal(15dc000,13ef3b60,13ef3a9c,e556d2,265dc000,...) at trap_fatal+0x356/frame 0x13ef3a68 trap_pfault(deadc0e6) at trap_pfault+0x35/frame 0x13ef3a9c trap(13ef3b60,8,28,28,ad9b400,...) at trap+0x3c0/frame 0x13ef3b54 calltrap() at 0xffc0316d/frame 0x13ef3b54 --- trap 0xc, eip = 0x10554cb, esp = 0x13ef3ba0, ebp = 0x13ef3c04 --- nd6_dad_timer(1d1fe980) at nd6_dad_timer+0x5b/frame 0x13ef3c04 softclock_call_cc(0) at softclock_call_cc+0x122/frame 0x13ef3c68 softclock(1868640) at softclock+0x6f/frame 0x13ef3c84 ithread_loop(adfbf20,13ef3ce8) at ithread_loop+0x156/frame 0x13ef3cb4 fork_exit(dfc5c0,adfbf20,13ef3ce8,0,0,...) at fork_exit+0x6c/frame 0x13ef3cd4 fork_trampoline() at 0xffc033ca/frame 0x13ef3cd4 --- trap 0, eip = 0, esp = 0x13ef3d20, ebp = 0 --- (null)() at 0 This panic seems happens due to bad pointer dereference in: if (ND_IFINFO(ifp)->flags & ND6_IFF_IFDISABLED) The difference between 0xdeadc0e6 and 0xdeadc0de is 8. So, for i386 it seems it corresponds to offsetof(struct in6_ifextra, nd_ifinfo). And #define ND_IFINFO(ifp) \ nd6_dad_stop(struct ifaddr *ifa)(((struct in6_ifextra *)(ifp)->if_afdata[AF_INET6])->nd_ifinfo) Can you show the content of *dp and *ifp for 8 frame for vmcore.4? I.e. (kgdb) f 8 p *dp p *ifp