udp6: Page fault panics
Andrey V. Elsukov
bu7cher at yandex.ru
Mon Sep 17 08:18:19 UTC 2018
On 16.09.2018 03:04, Larry Rosenman wrote:
> vpanic() at vpanic+0x1a3/frame 0xfffffe00ca17c150
> panic() at panic+0x43/frame 0xfffffe00ca17c1b0
> trap_fatal() at trap_fatal+0x35f/frame 0xfffffe00ca17c200
> trap_pfault() at trap_pfault+0x49/frame 0xfffffe00ca17c260
> trap() at trap+0x2ba/frame 0xfffffe00ca17c370
> calltrap() at calltrap+0x8/frame 0xfffffe00ca17c370
> --- trap 0xc, rip = 0xffffffff80631428, rsp = 0xfffffe00ca17c440, rbp = 0xfffffe00ca17c480 ---
> selectroute() at selectroute+0x198/frame 0xfffffe00ca17c480
> in6_selectroute_fib() at in6_selectroute_fib+0xf/frame 0xfffffe00ca17c4a0
> ip6_output() at ip6_output+0xfd7/frame 0xfffffe00ca17c710
(kgdb) l *selectroute+0x198
0xffffffff80de14c8 is in selectroute
(/home/devel/freebsd/base/head/sys/netinet6/in6_src.c:736).
731 * Use a cached route if it exists and is valid, else try to allocate
732 * a new one. Note that we should check the address family of the
733 * cached destination, in case of sharing the cache with IPv4.
734 */
735 if (ro) {
736 if (ro->ro_rt &&
737 (!(ro->ro_rt->rt_flags & RTF_UP) ||
738 ((struct sockaddr *)(&ro->ro_dst))->sa_family != AF_INET6 ||
739 !IN6_ARE_ADDR_EQUAL(&satosin6(&ro->ro_dst)->sin6_addr,
740 dst))) {
> calltrap() at calltrap+0x8/frame 0xfffffe00c9d863e0
> --- trap 0xc, rip = 0xffffffff80636b2b, rsp = 0xfffffe00c9d864b0, rbp = 0xfffffe00c9d86710 ---
> ip6_output() at ip6_output+0xeeb/frame 0xfffffe00c9d86710
> udp6_send() at udp6_send+0x720/frame 0xfffffe00c9d868d0
(kgdb) l *ip6_output+0xeeb
0xffffffff80de75bb is in ip6_output
(/home/devel/freebsd/base/head/sys/netinet6/ip6_output.c:531).
526 */
527 if (inp) {
528 ro->ro_dst.sin6_family = AF_INET6;
529 RT_VALIDATE((struct route *)ro, &inp->inp_rt_cookie, fibnum);
530 }
531 if (ro->ro_rt && fwd_tag == NULL && (ro->ro_rt->rt_flags & RTF_UP) &&
532 ro->ro_dst.sin6_family == AF_INET6 &&
533 IN6_ARE_ADDR_EQUAL(&ro->ro_dst.sin6_addr, &ip6->ip6_dst)) {
534 rt = ro->ro_rt;
535 ifp = ro->ro_rt->rt_ifp;
It looks like Ryan's assumption is correct and panics happen due to
several threads use the same PCB and then route cache invalidation happens.
https://lists.freebsd.org/pipermail/freebsd-net/2018-September/051563.html
But IPv6 path also needs similar patch.
--
WBR, Andrey V. Elsukov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20180917/e992e1a6/attachment.sig>
More information about the freebsd-current
mailing list