Bug 219250
| Summary: | panic: in6_ifattach_linklocal: ia == NULL (assigning ipv6 addresses) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Reshad Patuck <reshadpatuck1> | ||||
| Component: | kern | Assignee: | Eric van Gyzen <vangyzen> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | bz, net, vangyzen | ||||
| Priority: | --- | Keywords: | crash, ipv6 | ||||
| Version: | CURRENT | Flags: | koobs:
mfc-stable12+
koobs: mfc-stable11+ |
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| URL: | https://reviews.freebsd.org/D17898 | ||||||
| Attachments: |
|
||||||
As an attempt for a workaround I disabled automatically adding IPv6 addresses to epairs when they come up in the jails. I did this by setting the sysctl net.inet6.ip6.auto_linklocal=0 This time when I did ifconfig epair0b up in the jail, it did not automatically assign an IPv6 address. Running the same test crashed with a new panic possibly with pf state teardown. I have submitted bug #219251 for that panic. Something removed an IPv6 link-local interface address immediately after it was added. I don't know how this happened. However, it is clear that there is no thread synchronization to prevent this scenario and guarantee the assertion. This function (or its caller) really needs some kind of synchronization. Write-locking the if_addr_lock, which protects the interface's list of addresses, seems like a good choice, but I haven't tested that. I'm removing [VIMAGE] from the title, since this can be triggered without VIMAGE. A commit references this bug: Author: vangyzen Date: Thu Nov 8 19:50:23 UTC 2018 New revision: 340257 URL: https://svnweb.freebsd.org/changeset/base/340257 Log: in6_ifattach_linklocal: handle immediate removal of the new LLA If another thread immediately removes the link-local address added by in6_update_ifa(), in6ifa_ifpforlinklocal() can return NULL, so the following assertion (or dereference) is wrong. Remove the assertion, and handle NULL somewhat better than panicking. This matches all of the other callers of in6_update_ifa(). PR: 219250 Reviewed by: bz, dab (both an earlier version) MFC after: 1 week Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D17898 Changes: head/sys/netinet6/in6_ifattach.c A commit references this bug: Author: vangyzen Date: Tue Nov 27 19:40:07 UTC 2018 New revision: 341086 URL: https://svnweb.freebsd.org/changeset/base/341086 Log: MFC r340257 in6_ifattach_linklocal: handle immediate removal of the new LLA If another thread immediately removes the link-local address added by in6_update_ifa(), in6ifa_ifpforlinklocal() can return NULL, so the following assertion (or dereference) is wrong. Remove the assertion, and handle NULL somewhat better than panicking. This matches all of the other callers of in6_update_ifa(). PR: 219250 Reviewed by: bz, dab (both an earlier version) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D17898 Changes: _U stable/12/ stable/12/sys/netinet6/in6_ifattach.c A commit references this bug: Author: vangyzen Date: Tue Nov 27 19:40:18 UTC 2018 New revision: 341087 URL: https://svnweb.freebsd.org/changeset/base/341087 Log: MFC r340257 in6_ifattach_linklocal: handle immediate removal of the new LLA If another thread immediately removes the link-local address added by in6_update_ifa(), in6ifa_ifpforlinklocal() can return NULL, so the following assertion (or dereference) is wrong. Remove the assertion, and handle NULL somewhat better than panicking. This matches all of the other callers of in6_update_ifa(). PR: 219250 Reviewed by: bz, dab (both an earlier version) Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D17898 Changes: _U stable/11/ stable/11/sys/netinet6/in6_ifattach.c |
Created attachment 182557 [details] core.txt file for the panic Hey, While ruining some tests with about 20 vnet jails with pf and netgraph I get this panic. I have attached the core.txt for the panic to this post. From what I can understand there sees to be some issue assigning ipv6 addresses to epairs in the vnet jail. Please let me know if there is any other information or something else I can help with. Kernel version r318025 --- panic: in6_ifattach_linklocal: ia == NULL, ifp=0xfffff801b9828000 --- (kgdb) backtrace #0 __curthread () at ./machine/pcpu.h:232 #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:318 #2 0xffffffff803a308b in db_dump (dummy=<optimized out>, dummy2=<error reading variable: access outside bounds of object referenced via synthetic pointer>, dummy3=<unavailable>, dummy4=<unavailable>) at /usr/src/sys/ddb/db_command.c:546 #3 0xffffffff803a2e7f in db_command (last_cmdp=<optimized out>, cmd_table=<optimized out>, dopager=<optimized out>) at /usr/src/sys/ddb/db_command.c:453 #4 0xffffffff803a2bb4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:506 #5 0xffffffff803a5c7f in db_trap (type=<optimized out>, code=<optimized out>) at /usr/src/sys/ddb/db_main.c:248 #6 0xffffffff80a95673 in kdb_trap (type=3, code=-61456, tf=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:654 #7 0xffffffff80ef0de6 in trap (frame=0xfffffe1043e13310) at /usr/src/sys/amd64/amd64/trap.c:537 #8 <signal handler called> #9 kdb_enter (why=0xffffffff8145adfd "panic", msg=<optimized out>) at /usr/src/sys/kern/subr_kdb.c:444 #10 0xffffffff80a533f9 in vpanic (fmt=<optimized out>, ap=0xfffffe1043e134a0) at /usr/src/sys/kern/kern_shutdown.c:772 #11 0xffffffff80a53236 in kassert_panic (fmt=0xffffffff8149b825 "%s: ia == NULL, ifp=%p") at /usr/src/sys/kern/kern_shutdown.c:669 #12 0xffffffff80c7805b in in6_ifattach_linklocal (ifp=<optimized out>, altifp=<optimized out>) at /usr/src/sys/netinet6/in6_ifattach.c:505 #13 in6_ifattach (ifp=0xfffff801b9828000, altifp=<optimized out>) at /usr/src/sys/netinet6/in6_ifattach.c:747 #14 0xffffffff80b462ea in if_route (flag=1, fam=0, ifp=<optimized out>) at /usr/src/sys/net/if.c:2148 #15 if_up (ifp=0xfffff801b9828000) at /usr/src/sys/net/if.c:2233 #16 0xffffffff80b47f93 in ifhwioctl (cmd=<optimized out>, ifp=<optimized out>, td=0xfffff8002d117000, data=<optimized out>) at /usr/src/sys/net/if.c:2452 #17 ifioctl (so=<optimized out>, cmd=<optimized out>, data=<optimized out>, td=<optimized out>) at /usr/src/sys/net/if.c:2821 #18 0xffffffff80aba11d in fo_ioctl (fp=<optimized out>, com=2149607696, active_cred=<optimized out>, td=<optimized out>, data=<optimized out>) at /usr/src/sys/sys/file.h:323 #19 kern_ioctl (td=<optimized out>, fd=<optimized out>, com=<optimized out>, data=0xfffffe1043e132d0 "") at /usr/src/sys/kern/sys_generic.c:836 #20 0xffffffff80ab9ddf in sys_ioctl (td=<optimized out>, uap=0xfffffe1043e13930) at /usr/src/sys/kern/sys_generic.c:745 #21 0xffffffff80ef2059 in syscallenter (td=0xfffff8002d117000, sa=<optimized out>) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:136 #22 amd64_syscall (td=0xfffff8002d117000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:902 #23 <signal handler called> #24 0x0000000800fd9dfa in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffdd88 ---