Garrett D'Amore wrote:
I had a similar thought after looking at the code. (Although one
potential difference is what happens on putbq... I've not given that any
consideration as of yet.)
There is no input service procedure in ip.
Is IP itself careful never to internally generate or modify a message
that winds up leaving it in an "unaligned" (or non-contiguous IP header)
state? E.g. what about IP tunnels? I've not looked at this carefully
yet, but I'd love to have the input of an expert in the code.
None that go through ip_input() that I know of.
IP tunnels are currently implemented as a separate STREAMS module (tun),
so input from tunnels goes through the regular ip_rput() path. In the
future, with Clearview, IP tunnels will be implemented as a GLDv3 driver,
so things will go through dls/ip_input(). This case isn't really special
before or after Clearview.
If this risks complicating the fix at hand, however, why not file a
separate RFE? Fix the unaligned access in the dls soft ring code now (as
that fix is rather urgent), then one could go back and massage the IP
input path later (as that's less urgent, and not a bug).
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
