kernel panic

Matthew Dillon dillon at
Fri Dec 28 12:02:48 PST 2007

:Since ifa_addr is points at the correct memory position but rest of
:the pointers are 'deadc0de', the on-list dead in_ifaddr may go through
:following code and become dead:
:    if (scrub) {
:        ia->ia_ifa.ifa_addr =3D (struct sockaddr *)&oldaddr;
:        in_ifscrub(ifp, ia);
:        ia->ia_ifa.ifa_addr =3D (struct sockaddr *)&ia->ia_addr;
:    }
:I think in_ifscrub() killed the last reference, but this code path is
:rarely stressed:
:1) From SIOCSIFADDR, which is not used by ifconfig(8) or vkernel(7)
:2) From sppp_set_ip_addr(), is it used on the panic system?
:Best Regards,

    I think you are on to something here.  The more I look at that code,
    not only in_ifscrub() but just in_ifinit() generally, particularly
    the fact that the ia is manipulated both inside and outside the
    serializer, the more it looks wrong.

    There seem to be a ton of places where the ia can be freed.  Frankly
    the code paths are almost unreadable to me but I am guessing it is
    a call to IFAFREE() somewhere in that mess that is causing the problem.
    (see IFAFREE() in net/if_var.h line 44).

    The ia is supposed to be protected by a reference count in the ia
    structure.  The governing route table entry uses a mirror flag RTF_UP
    to mean the same thing.  When an interface goes down RTM_DELETE is
    called and RTF_UP is cleared in the route entry (net/route.c line 808),
    but the IFA_ROUTE flag in the ia itself should not be cleared except
    by the interface code.

    I think what is happening is that the ref count that IFAFREE() depends
    on is not being properly incremented or decremented somewhere.  There
    is either an extra IFAFREE() call being made, or an IFAREF() call is
    not being made where it should be.

    I don't know where the missing call is but it is either in the route
    table code mismatching an IFAREF/IFAFREE (based I think on the RTF_UP
    flag but I don't know for sure), or the interface code mismatching an


More information about the Bugs mailing list