Small patch to multicast code...

[Bruce M. Simpson]

gnn at FreeBSD.org wrote:
> I gather you mean that a fast link on which also we're looping back
> the packet will be an issue?  Since this packet is only going into the
> simloop() routine.
>   

We end up calling if_simloop() from a few "interesting" places, in 
particular the kernel PIM packet handler.

In this particular case we're going to take a full mbuf chain copy every 
time we send a packet which needs to be looped back to userland.

>   
> I was actually hoping, as the person who last hacked this code, that
> you might have a suggestion as to a "right" fix.  
>   

It's been a while since I've done any in-depth FreeBSD work other than 
hacking on the IGMPv3 snap, and my time is largely tied up with other 
work these days, sadly.

It doesn't seem right to my mind that we need to make a full copy of an 
mbuf chain with m_dup() to workaround this kind of problem.

Whilst it may suffice for a band-aid workaround, we may see mbuf pool 
fragmentation as packet rates go up.

However we are now in a "new world order" where mbuf chains may be very 
tied to the device where they've originated or to where they're going. 
It isn't clear to me where this kind of intrusion is happening.

In the case of ip_mloopback(), somehow we are stomping on a read-only 
copy of an mbuf chain. The use of m_copy() with m_pullup() there is fine 
according to the documented uses of mbuf(9), although as Luigi pointed 
out, most likely we need to look at the upper-layer protocol too, e.g. 
where UDP checksums are also being offloaded.

Some of the code in the IGMPv3 branch actually reworks how loopback 
happens i.e. the preference is not to loop back wherever possible 
because of the locking implications. Check the bms_netdev branch history 
for more info.

cheers
BMS