Seigo Tanimura wrote:
> In ip_output(), imo->imo_multicast_ifp points to the removed
> interface, which is passed to IN_LOOKUP_MULTI() to cause a panic. This
> problem also occurs when we attempt to delete a multicast address from
> a removed interface. if_delmulti() derefers an ifp to the removed
> interface, ending up with a panic. The problem does not occur for
> unicast.
> is a
> workround patch. The idea is to track all of the active ifps, confirm
> an ifp to be active prior to dereferencing it, and free orphaned
> ifmultiaddrs attached to a removed ifp. It would be much more elegant
> if we could clean up the multicast information related to a removed
> interface, though.

Warner Losh pointed out to me:

> Tanimura-san did contribute patches.  This problem isn't a race at the
> eject, but rather the network layer incompletely cleaning up after a
> device has gone away.

This is, of course, exactly the problem you're looking at.  There are 
several of these cached ifp's hanging around, all causing problems.

Robert Watson and I had a nice discussion about how to approach that
problem a while back.  I've since gotten busy and forgotten about it,
as has he (apparently).

The quick (-ish) fix I came up with is to double all those cache ifp's
all over the code, and always check the first pointer for a null
reference before diving off through it.  The disadvantage is the check
and dereference on every access, the advantage is being able to
nullify one pointer in the interface take-down and automagically have
all the cached references die.  You would leak a single pointer for
every interface detach, unless you did reference counting or something
like that.

The full solution would be to implement ifs a full objects, and to 
always check the state of the interface before trying to exercise an 
associated function.  It's an ugly problem with no real simple solutions 
(in C).

            "Where am I, and what am I doing in this handbasket?"

Wes Peters                                                         Softweyr LLC
[EMAIL PROTECTED]                                 

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to