svn commit: r191367 - head/sys/net

[Bruce Simpson]

Robert Watson wrote:
> ...
> (3) Some consumers of ifnets need to be taught to register the ifnet 
> removal
>     event and properly detach themselves.  For example, DUMMYNET is a
>     well-known component that likes to hold onto mbufs for a long time,
>     increasing the chances of the "oh, my ifnet is gone" race.  Rather 
> than
>     trying to refcount from each mbuf, which would add excessive 
> overhead, I
>     think the answer is to modify these consumers to detect ifnet 
> removal and
>     GC all the mbufs that refer to it.  For example, DUMMYNET should 
> probably
>     walk all its queues and m_freem() packets refering to the dying 
> ifnet.
>
> I'm not familiar with the workings of SSM, but my feeling is that it 
> probably needs to take the (3) approach rather than (2) -- rather than 
> preventing the ifnet from going away until a socket closes, it should 
> detect that the ifnet is going away and take appropriate remedial 
> action.  Possibly it should detect when a similarly configured ifnet 
> re-appears and consider attaching to that, but it will most likely be 
> a different instance of struct ifnet, and there are semantic 
> considerations.

SSM isn't high traffic -- it actually reduces the chattiness of IGMP by 
implementing per-interface output queues and state change report merges. 
Same for MLDv2 in IPv6. Timeliness and stability are what counts, it's 
control plane, not data plane. At the moment it mostly does (3) by doing 
an ifindex lookup in the netisr dispatch callback before calling 
ip_output().

Of course if ip_output() were to look before it leapt, the book keeping 
involved would go away. I have to stash the vimage context and ifindex 
in the queued mbuf packet headers to implement this.

Now that Giant is nuked, the netisr could be eliminated and the ifnet 
rlock taken as it is before dispatching an entire chain. I only 
implemented a netisr to allow the code to be back-ported, however I 
don't care about back-porting any more -- it's too much effort and the 
time/funding budget doesn't justify that amount of work.

cheers
BMS