On Sun, Nov 04, 2007 at 10:32:09AM -0500, Greg Troxel wrote:
>   So, if I've got it right, fr_fastroute gets a handle on the packet
>   with its length in host order, sets it to network order for the call
>   to the output routine, and then sets it back to host order, just in
>   case the caller of fr_fastroute wants to do something else with the
>   packet (e.g., in the dup-to case, I assume).  Then the gif soft
>   interrupt handler is invoked, and outputs on the real network
>   interface an encapsulated packet with its length in the host's byte
>   order.
> 
> As you note, there has long been a notion that length is in host order
> at some times and not others, and I'd go at this by documenting the
> rules in as many places as you can, checking in comments.  But, I think
> what might be going on is an assumption that once the call from the
> output routine returns that it's safe to modify the mbuf again.  It
> seems pretty dicey to be doing swap/call/swap when the mbuf is shared
> data structure.  So, making a copy probably is the safe approach, and
> I'm not sure what's necessary to get to safe and efficient.

Touching the mbuf at all after it has been passed to if_output sounds
really wrong. Look at ether_output which frees the mbuf at the end. The
caller of fr_fastroute really should not be doing anything with it. For
dup-to, there is a call to M_DUPLICATE in fr_check.