Re: LOR + panic in scope6.c

From: Bjoern A. Zeeb <bzeeb-lists_at_lists.zabbadoz.net>
Date: Tue, 9 Aug 2005 15:28:54 +0000 (UTC)
On Tue, 9 Aug 2005, John Baldwin wrote:

> On Tuesday 09 August 2005 07:40 am, Bjoern A. Zeeb wrote:
> > Hi,
> >
> > HEAD as of yesterday + rwatson mega-commit from today.
> >
> > lock order reversal
> >  1st 0xffffff0000ad6bf0 if_afdata (if_afdata) _at_ sys/netinet6/scope6.c:415
> >  2nd 0xffffffff8081dd30 user map (user map) _at_ sys/vm/vm_map.c:2997
> > KDB: stack backtrace:
> >
> > --- trap 0xc, rip = 0xffffffff804990a0, rsp = 0xffffffff809dc3f0, rbp =
> > 0xffffffff809dc430 --- in6_setscope() at in6_setscope+0x50
> > in6_ifdetach() at in6_ifdetach+0x24a
> > if_detach() at if_detach+0x39
> > ether_ifdetach() at ether_ifdetach+0x35
> > sk_attach() at sk_attach+0x51a
> >
> > Fatal trap 12: page fault while in kernel mode
> > fault virtual address   = 0x18
> > fault code              = supervisor read, page not present
> > instruction pointer     = 0x8:0xffffffff804990a0
> > stack pointer           = 0x10:0xffffffff809dc3f0
> > frame pointer           = 0x10:0xffffffff809dc430
> > code segment            = base 0x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, long 1, def32 0, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 0 (swapper)
> > [thread pid 0 tid 0 ]
> > Stopped at      in6_setscope+0x50:      movq    0x18(%rax),%r13
> >
> > (gdb) l *0xffffffff804990a0
> > 0xffffffff804990a0 is in in6_setscope (sys/netinet6/scope6.c:417).
> > 412             u_int32_t zoneid = 0;
> > 413             struct scope6_id *sid;
> > 414
> > 415             IF_AFDATA_LOCK(ifp);
> > 416
> > 417             sid = SID(ifp);
> > 418
> > 419     #ifdef DIAGNOSTIC
> > 420             if (sid == NULL) { /* should not happen */
> > 421                     panic("in6_setscope: scope array is NULL");
>
> Well, SID is a macro that expands this to:
>
> 	sid = ifp->if_afdata[AF_INET6]->scope6_id
>
> If if_afdata[AF_INET6] has already been freed that could be the problem.
> It might have never been non-null either I guess.  You can try having
> in6_setscope() bail if ifp->if_afdata[AF_INET6] is NULL.

I will. I think I found another problem with attach/detach in sk.
Might be a double free.
The above seems to happen in the "No PHY found" case (which I fixed
already locally and everything went away).

I will further investigate. The LOR might as well be bogus because of
the trap.

-- 
Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
Received on Tue Aug 09 2005 - 13:30:10 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:41 UTC