Re: 6.0BETA3 panic in ip_output (vlan/RIP related?)

On Sat, Sep 03, 2005 at 08:19:28PM +0100, Robert Watson wrote:
> 
> I believe I've chatted with Gleb about this some, but want to confirm that 
> I understand the problem here: this occurs when an interface is removed 
> while IP multicast membership is still present for multicast groups on the 
> interface.  When the multicast socket is closed, then the kernel panics 
> because it has a now invalid cached pointer to the interface structure 
> (now freed), which cases an assertion failure because the mutex code 
> detects that it is operating on an invalid mutex.

I have exactly the same notion of the issue.

> So it sounds like we need to figure out how the multicast code should 
> behave on interface removal -- I wonder what other operating systems do 
> here?  Do they simply invalidate current membership related with the 
> interface, or do they leave the multicast sockets in a state such that if 
> the interface comes back, the memberships are re-bound?

The idea of keeping such "orphaned" multicast sockets around seems
to come from the way we deal with ordinary, unicast, sockets, whose
local address has been deleted: such sockets just wait for the
address to be re-assigned to some interface in the system (a different
one, perhaps.)

However, multicast group membership is bound to a specific interface
by design.  Therefore I fail to see how we can revive it on a
different, newly created, interface even if it may have the same
name and type as the old one used to have.  E.g., a dial-up user
disconnects, ppp0 is destroyed; is ppp0 to appear when another user
connects the same as the old instance of ppp0?  And here is the
opposite case: you replace a PCMCIA Ethernet card in your notebook
with another one of a different hardware type; how can the system
tell that the old and new interfaces are virtually the same?  I'm
afraid that the system should lose its multicast group membership
on a destroyed interface because there will be no such interface
in the system again.

In the case of routing daemons, which are among the major consumers
of IP multicast, such a daemon will notice this or some other
interface re-appearing and join groups it needs on it again.  Other
multicast software can just fail upon its interface departure, or
wait until an interface with an IP address known to the software
re-appears.  I'm afraid we cannot hide this in the kernel because,
in general, an IP address alone is insufficient to determine an
interface to join a multicast group on in the presence of "unnumbered"
interfaces.

-- 
Yar