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.
>
> http://people.FreeBSD.org/~tanimura/patches/mcastif.diff.gz 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] http://softweyr.com/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
